The playbin player was stop by vpu output error

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

The playbin player was stop by vpu output error

2,614 Views
stone_yu
Contributor I

When I play the videos by two gst-playbin elements.

the first playbin was stop by vpu output error.

 

Description

First playbin is play the mp4 file.

Then I create another playbin to play the same mp4 file.

They are work fine.

 

After that,I changed video file on the second playbin,

the first playbin was stop

 

■Procedure

step1:create a playbin to play the mp4 file ⇒ playbin1

   ※work fine.

step2:create another playbin to play the same mp4 file ⇒ playbin2

   ※work fine.

step3:change the playbin2 to play a ogv file

   ※work fine.

step4:change the playbin2 to play the mp4 file.

   ※the playbin1 is stop.

              I check the gst debug log, some vpu error is happen.

 

■log

0:00:27.644465337 0x695b4550 WARN aiurdemux aiurdemux.c:3078:aiurdemux_push_pad_buffer: Pad video push error type -5

0:00:27.644534337 0x695b4550 WARN aiurdemux aiurdemux.c:991:aiurdemux_pull_task: pausing task, reason error

0:00:27.644602337 0x695b4550 WARN aiurdemux aiurdemux.c:998:aiurdemux_pull_task:<aiurdemux0> error: streaming stopped, reason error, state 3

0:00:27.644727003 0x695b4550 INFO GST_ERROR_SYSTEM gstelement.c:1835:gst_element_message_full:<aiurdemux0> posting message: GStreamer encountered a general stream error.

0:00:27.644827337 0x695b4550 INFO GST_ERROR_SYSTEM gstelement.c:1858:gst_element_message_full:<aiurdemux0> posted error message: GStreamer encountered a general stream error.

 

Please give me same tips, thank you very much.

Original Attachment has been moved to: 20150507.zip

Labels (3)
0 Kudos
5 Replies

1,048 Views
gusarambula
NXP TechSupport
NXP TechSupport

Hello  申鹏 虞,

Did the suggestions by Takahiro helped or are you still experiencing problems?

0 Kudos

1,048 Views
takahiroyasuda
Contributor II

What videosink is used by the playbin?
If it is imxv4l2sink, replacing with overlaysink might help you;
And if overlaysink, try the other.

In my case, or HLS playing, the very same error happened in playing a specific video.
My bad pipeline was below:

souphttpsrc -- queue -- hlsdemux -- decodebin                                         +-- queue -- imxv4l2sink                                         +-- queue -- volume -- alsasink

Replacing the imxv4l2sink in the pipeline with overlaysink, the problem looks cleared (The HLS video anyhow goes through).


Honestly speaking, playbin had worked quite well on HLS video.
So I picked up overlaysink that is used in the pipeline (The playbin had introduced playsink, and finally overlaysink).

If you don't mind, why don't you try another videosink?

0 Kudos

1,048 Views
stone_yu
Contributor I

thank you for your tips.

My application FW is qt.

So this is the [QGstVideoRendererSink] in my playbin.

BDY,If I used overlaysink in the playbin, it works fine.

But once I used [QGstVideoRendererSink] ,it will be error.

0 Kudos

1,048 Views
takahiroyasuda
Contributor II

How about using another demuxer element instead?

(i.e. qtdemux, for mp4 playback pipeline)

As the log is saying, aiurdemux very looks the cause.

After the previous post, in checking the problem of my HLS playback pipeline,

I found it is likely to crash in changing bitrate;

In other words, in trying to play another video stream,

whose resolution, bitrate, or such conditions are different.

Not having verified in detail yet, but, for my HLS pipeline (with imxv4l2sink),

setting "connection-speed" property to some fixed value helped too much;

This means: I forced it to stick to the very one bitrate.

Considering this,

aiurdemux looks causing conflict or some trouble between the two different videos.

In your case, the mp4 file and the ogv file you gave.

So, passing either one of the videos to another demuxer might avoid such situation.

I don't know why it happens with imxv4l2sink and does not with overlaysink,

but it might be because imxv4l2sink would not follow the change of its input, perhaps

(In my case, even video resolution was different...).

Not sure.

0 Kudos

1,048 Views
takahiroyasuda
Contributor II

Perhaps I found something: fix your video sink's input format.

In my case of HLS, in switching bitrate, decoded raw video formats were different.

So I fixed video sink's input format to exact one, using videoscale and videoconvert.

Then, it looks working better (although it is too slow due to videoscale and videoconvert's S/W based processing).

Succeeded Pipeline (for HLS)

gst-launch-1.0 \

    --gst-debug-level=3 --gst-debug=hlsdemux:5 \

    souphttpsrc is-live=true location="$uri" \

    ! queue ! hlsdemux connection-speed=$bandwidth bitrate-limit=0 \  #(*1)

    ! decodebin name=decode \

    \

    decode. ! queue \

        ! videoscale ! videoconvert ! video/x-raw, format=UYVY, width=1920, height=1080, interlace-mode=progressive, framerate=30/1, pixel-aspect-ratio=1/1 \  #(*2)

        ! imxv4l2sink device="/dev/video19" force-aspect-ratio=false sync=true \

    decode. ! queue ! volume volume=$volume ! alsasink sync=true device="hw:1,0"

*1) hlsdemux's "bitrate-limit=0" makes it likely to switch bitrate, that causes the crash.

*2) Set the every caps properties. Properties not specified are influenced by the input (decoder's output) format.

0 Kudos