Running multiple Gstreamer decodes on DM814x EVM

Hello,

Please, check the DM81xx Gstreamer FAQs:

http://processors.wiki.ti.com/index.php/DM81xx_Gstreamer_FAQ#How_do_I_play_video_on_lcd_connected_to_DM8148_EVM.3F

BR

Vladimir

Hello,

If you want to use LCD:

 gst-launch -v filesrc location=/usr/share/ti/data/videos/dm816x_1080p_demo.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec !  omx_scaler ! video/x-raw-yuv,width=800,height=480 ! omx_ctrl display-mode=OMX_DC_MODE_1080_60 display-device=LCD ! omx_videosink sync=false display-device=LCD

If you want to use HDMI:

gst-launch -v filesrc location=/usr/share/ti/data/videos/dm816x_1080p_demo.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! omx_scaler ! omx_ctrl display-mode=OMX_DC_MODE_1080P_60 ! omx_videosink sync=false

Best Regards,

Margarita

If you want to change the HDMI resolution to 800x480:

root@dm814x-evm:~# /etc/init.d/matrix-gui-e stop
Stopping Matrix GUI application.
root@dm814x-evm:~# /etc/init.d/pvr-init stop
Stopping PVR
root@dm814x-evm:~# echo 0 > /sys/devices/platform/vpss/display0/enabled
root@dm814x-evm:~# echo 33500,800/164/89/10,480/10/23/10,1 > /sys/devices/platform/vpss/display0/timings
root@dm814x-evm:~# echo 1 > /sys/devices/platform/vpss/display0/enabled
root@dm814x-evm:~# fbset -xres 800 -yres 480 -vxres 800 -vyres 480
root@dm814x-evm:~# /etc/init.d/matrix-gui-e start
Starting Matrix GUI application.
root@dm814x-evm:~# cat /sys/devices/platform/vpss/display0/mode
800x480@60

Best Regard

Margarita

In my experience with the DM8148 and GStreamer/OpenMAX, multiple pipelines don't seem to function.

You can do multiple simultaneous decodes, as long as you put them all in the same GStreamer instance.  The following page has a few examples of quad channel decode, all running into the video mixer, and all being displayed.

http://processors.wiki.ti.com/index.php/DM81xx_Gstreamer_Pipelines

You should just be able to copy and paste your command pipeline a second time, and hopefully the scaler and decode elements will work out.

# gst-launch filesrc location=/usr/share/ti/data/videos/dm816x_1080p_demo.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec !  omx_scaler ! 'video/x-raw-yuv,width=800,height=480' ! fakesink filesrc location=/usr/share/ti/data/videos/dm816x_1080p_demo.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec !  omx_scaler ! 'video/x-raw-yuv,width=800,height=480' ! fakesink 

Thanks Nick, probably about the only thing I didn't try yesterday!  Will give it a test today.

Anybody from TI care to comment?  Should we be able to run two parellel instances of a Gstreamer decode?

Danny

Hello Danny,

You can try this for example:

gst-launch -v filesrc location=/usr/share/ti/data/videos/dm816x_1080p_demo.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec !  omx_scaler ! 'video/x-raw-yuv,width=800,height=480'! omx_ctrl display-mode=OMX_DC_MODE_1080P_60  ! omx_videosink filesrc location=/usr/share/ti/data/videos/dm816x_1080p_demo.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec !  omx_scaler ! 'video/x-raw-yuv,width=800,height=480' ! omx_ctrl display-mode=OMX_DC_MODE_1080_60 display-device=LCD ! omx_videosink display-device=LCD

or you want to use two different pipelines ?

Best regards

Margarita

Finally got around to trying the concatenated command and it fails in exactly the same way as launching two gst-launch commands in parallel.  It looks like the OMX layer only handles one decode client at a time?

Here is the console output:

root@dm814x-evm:~# echo 0 > /sys/devices/platform/vpss/graphics0/enabled

root@dm814x-evm:~# gst-launch -v filesrc location=/usr/share/ti/data/videos/dm816x_1080p_demo.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! omx_scaler ! 'video/x-raw-yuv,width=800,height=480' ! omx_ctrl display-mode=OMX_DC_MODE_1080P_60 display-device=HDMI >     ! omx_videosink sync=false display-device=HDMI filesrc location=/usr/share/ti/data/videos/dm816x_1080p_demo.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! omx_scaler ! 'video/x-raw-yuv,width=800,height=480' ! fakesink

Assertion at Line no: 419 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/utils/hlos/knl/Linux/../../d
Assertion at Line no: 419 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/utils/hlos/knl/Linux/../../d
Assertion at Line no: 419 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/utils/hlos/knl/Linux/../../d
Assertion at Line no: 1244 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (d
Assertion at Line no: 700 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (qd
ServiceMgr_prime: MessageQ_put failed: status = 0xfffffffe
Assertion at Line no: 1244 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (d
Assertion at Line no: 700 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (qd
ServiceMgr_prime: MessageQ_put failed: status = 0xfffffffe
Assertion at Line no: 1244 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (d
Assertion at Line no: 700 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (qd
ServiceMgr_prime: MessageQ_put failed: status = 0xfffffffe
Assertion at Line no: 1244 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (d
Assertion at Line no: 700 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (qd
ServiceMgr_prime: MessageQ_put failed: status = 0xfffffffe
Assertion at Line no: 1244 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (d
Assertion at Line no: 700 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (qd
ServiceMgr_prime: MessageQ_put failed: status = 0xfffffffe
Assertion at Line no: 1244 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (d
ServiceMgr_rxThreadFxn: bind() failed with errno = 98
Assertion at Line no: 766 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (hd
Caught SIGSEGV accessing address 0xe
Spinning.  Please run 'gdb gst-launch 1838' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
Assertion at Line no: 419 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/utils/hlos/knl/Linux/../../d
Assertion at Line no: 700 in /mnt/opt/ezsdk/component-sources/syslink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (qd
ServiceMgr_stop: MessageQ_put failed: status = 0xfffffffe

Caught interrupt --

root@dm814x-evm:~# echo 1 > /sys/devices/platform/vpss/graphics0/enabled

Margarita, has this been attempted by TI?  Should it work?

Regards, Danny

Hello,

It seems you cannot run multiple instance of GST at same time.

But you can use one pipeline with two different filescr.

Best Regards,

Margarita

Your pipeline (minus the > sign that the wiki may have thrown in there after the omx_ctrl element) works on my dm8148 board here without any problem.

If the decoder *ever* fails, or a pipeline is *ever* shut down improperly when using the OMX filters, you have to reboot the board before things work again.  I've tried a few combinations of loading and unloading the firmware to bring it back to life without requiring that, but it ended up being easier to reboot.  I would try your pipeline again on a fresh boot and see if it works okay.

root@ti814x:~# gst-launch -v filesrc location=/usr/share/ti/data/videos/dm816x_1080p_demo.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! omx_scaler ! 'video/x-raw-yuv,width=800,height=480' ! omx_ctrl display-mode=OMX_DC_MODE_1080P_60 display-device=HDMI ! omx_videosink sync=false display-device=HDMI filesrc location=/usr/share/ti/data/videos/dm816x_1080p_demo.264 ! '
video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! omx_scaler ! 'video/x-raw-yuv,width=800,height=480' ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...

Nick,

OMX in EZSDK does not support multiple 'process', but within a process multiple decodes are possible. Please refer to decode_mosaic example in EZSDK 5.05.01.04 ( Its availble for download), it can have 1 to 4 decodes (option -p 1,2,3,4,) in single application. GST too has 4 decode/mosaic support.

Regards

Vimal

So if a single app creates several pipelines for decode/playback as long as it is in the same process is it possible to decode multiply src's for video?  For example if I create four instances of a pipeline using playbin2 for each can I decode all four or is there still a limitation  and it must be one pipeline with four sources?

Hello Craig,

Gstreamer:

For example if I create four instances of a pipeline using playbin2 for each can I decode all four or is there still a limitation  and it must be one pipeline with four sources?

It should be one pipeline with four file sources, you can not run four different pipelines at the same time with Gstreamer. And there is other limitation if your are using videomixer component, like resolution, fps and etc. You could check here for examples: http://processors.wiki.ti.com/index.php/DM81xx_Gstreamer_Pipelines.

Best Regards,

Margarita

So I ran the following command, it is using an mp4 with only a video track.  I sent the video-sink to fakesink.  I would have expected verbose output with the timestamps for the frames.  Using a different mp4 file with an audio track I see much more output.  How can I play a mp4 (h264) from gstreamer?  Seems there is an issue if there is no audio.

root@touchlink-405fc20845ad:/media/extra/testing# gst-launch -v playbin2 uri=fil
e:///home/root/clip.mp4 video-sink=fakesink
Setting pipeline to PAUSED ...
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0: ring-buffer-max-size = 0
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0: buffer-size = -1
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0: buffer-duration = -1
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0: use-buffering = FALSE
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0: download = FALSE
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0: uri = "file:///home/root/clip.mp4"
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0: connection-speed = 0
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0: source = (GstFileSrc) source
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstTypeFindElement:typefind.GstPad:src: caps = video/quicktime
Pipeline is PREROLLING ...
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstQTDemux:qtdemux0.GstPad:sink: caps = video/quicktime
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstMultiQueue:multiqueue0: max-size-buffers = 5
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstMultiQueue:multiqueue0: max-size-time = 0
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstMultiQueue:multiqueue0: max-size-bytes = 8388608
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstMultiQueue:multiqueue0.GstPad:sink0: caps = video/x-h264, level=(string)4, pr
ofile=(string)baseline, codec_data=(buffer)01428028ffe1000967428028da02c0f44001000468ce3c80, width=(int)704, height=(int)480, framerate=(fraction)500/47, pixel
-aspect-ratio=(fraction)1/1
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstMultiQueue:multiqueue0.GstPad:src0: caps = video/x-h264, level=(string)4, pro
file=(string)baseline, codec_data=(buffer)01428028ffe1000967428028da02c0f44001000468ce3c80, width=(int)704, height=(int)480, framerate=(fraction)500/47, pixel-
aspect-ratio=(fraction)1/1
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstH264Parse:h264parse0.GstPad:sink: caps = video/x-h264, level=(string)4, profi
le=(string)baseline, codec_data=(buffer)01428028ffe1000967428028da02c0f44001000468ce3c80, width=(int)704, height=(int)480, framerate=(fraction)500/47, pixel-as
pect-ratio=(fraction)1/1
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstMultiQueue:multiqueue0: max-size-buffers = 5
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstMultiQueue:multiqueue0: max-size-time = 0
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstMultiQueue:multiqueue0: max-size-bytes = 8388608
/GstPlayBin2:playbin20/GstInputSelector:inputselector0.GstSelectorPad:sink0: always-ok = FALSE
/GstPlayBin2:playbin20/GstInputSelector:inputselector0: active-pad = (GstSelectorPad) sink0
Recieved EOS event, press <CTRL+C> to terminate pipeline.
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
/GstPlayBin2:playbin20/GstPlaySink:playsink0/GstBin:vbin/GstBin:bin0/GstFakeSink:fakesink0: last-message = "event ******* (fakesink0:sink) E (type: 86, ) 0x1
44070"
New clock: GstSystemClock
Got EOS from element "playbin20".
Execution ended after 2574500 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstH264Parse:h264parse0.GstPad:sink: caps = NULL
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstMultiQueue:multiqueue0.GstPad:sink0: caps = NULL
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstMultiQueue:multiqueue0.GstPad:src0: caps = NULL
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstQTDemux:qtdemux0.GstPad:video_00: caps = NULL
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstQTDemux:qtdemux0.GstPad:sink: caps = NULL
/GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstTypeFindElement:typefind.GstPad:src: caps = NULL
Setting pipeline to NULL ...
Freeing pipeline ...

Hello,

Gstreamer examples: http://processors.wiki.ti.com/index.php/DM81xx_Gstreamer_Pipelines

"I would have expected verbose output with the timestamps for the frames."

You should use gstperf component. It will show you the framerate, arm-load and etc.

Example with gstperf: gst-launch filesrc location=*.mp4 ! qtdemux name=demux demux.audio_00 ! queue ! faad ! alsasink demux.video_00 ! queue ! h264parse ! omx_h264dec ! omx_scaler ! omx_ctrl display-mode=OMX_DC_MODE_1080P_60 !  gstperf  ! omx_videosink

Let me know the result.

Best Regards,

Margarita

So I don't have alsasink or audio so I have replaced the alsasink with fakesink.  I use the following commandline and  returns immediately.  However if I use a mp4 with audio I get the additional audio cap info and the commandline does not return immediately.

root@touchlink-405fc20845ad:/media/extra/testing# gst-launch filesrc location=clip.mp4 ! qtdemux name=demux demux.audio_00 ! queue ! faad ! fakesink demux.video_00 ! queue ! h264parse ! omx_h264dec ! omx_scaler ! omx_ctrl display-mode=OMX_DC_MODE_1080P_60 ! gstperf ! fakesink -v
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstQueue:queue1.GstPad:sink: caps = video/x-h264, level=(string)4, profile=(string)baseline, codec_data=(buffer)01428028ffe1000967428028
da02c0f44001000468ce3c80, width=(int)704, height=(int)480, framerate=(fraction)500/47, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstQueue:queue1.GstPad:src: caps = video/x-h264, level=(string)4, profile=(string)baseline, codec_data=(buffer)01428028ffe1000967428028d
a02c0f44001000468ce3c80, width=(int)704, height=(int)480, framerate=(fraction)500/47, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:sink: caps = video/x-h264, level=(string)4, profile=(string)baseline, codec_data=(buffer)01428028ffe10009
67428028da02c0f44001000468ce3c80, width=(int)704, height=(int)480, framerate=(fraction)500/47, pixel-aspect-ratio=(fraction)1/1
Recieved EOS event, press <CTRL+C> to terminate pipeline.
Recieved EOS event, press <CTRL+C> to terminate pipeline.
Caught interrupt -- handling interrupt.
Interrupt: Stopping pipeline ...
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstQueue:queue1.GstPad:src: caps = NULL
/GstPipeline:pipeline0/GstQueue:queue1.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstQTDemux:demux.GstPad:video_00: caps = NULL
Freeing pipeline ...

Here is the mp4 I'm having trouble with.

Hello Craig,

"I have tried running two instances of the following command and get the error messages"

-You can run only one pipeline, but with several file sources. Like this examples:

gst-launch -v filesrc location=/usr/share/ti/data/videos/dm816x_1080p_demo.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec !  omx_scaler ! 'video/x-raw-yuv,width=800,height=480'! omx_ctrl display-mode=OMX_DC_MODE_1080P_60  ! omx_videosink filesrc location=/usr/share/ti/data/videos/dm816x_1080p_demo.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec !  omx_scaler ! 'video/x-raw-yuv,width=800,height=480' ! omx_ctrl display-mode=OMX_DC_MODE_1080_60 display-device=LCD ! omx_videosink display-device=LCD

or you could use Mosaic:

Mosaic 4 decoded H.264 elementary streams from file input, each of 1280x720 size, into one video output stream of 1270x720 size
gst-launch omx_videomixer framerate=30 port-index=0 name=mix !gstperf! v4l2sink userpointer=true filesrc location=sample_1.h264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! mix. filesrc location=sample_2.h264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! mix. filesrc location=sample_3.h264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! mix. filesrc location=sample_4.h264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! mix.

-if you want to decode *.mp4 videos without audio, pipeline will be:

gst-launch -v  filesrc location=/usr/share/ti/data/videos/sample.mp4 ! qtdemux name=demux ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! omx_scaler ! omx_ctrl display-mode=OMX_DC_MODE_1080P_60 ! omx_videosink

-if you want to use playbin2:

gst-launch -v playbin2 uri=file:///home/root/sample.mp4

Could you tell me, exactly what you are trying to do?

Best Regards,

Margarita

I am leveraging the work done by Rob Clark to support Qt Mobility and eglImage surfaces to display video in qml.  The Qt Mobility uses playbin2 to playback sources.  The sample mp4 I attached above will not show any video and I have narrowed it down to a problem with h264parse not decoding properly.  It appears the NALU header is not being found.

Please try my sample mp4 to see what I am referring too.

Craig

Hello,

I tried your sample, with this pipeline:

gst-launch filesrc location=/usr/share/ti/data/videos/8117.clip.mp4 ! qtdemux name=demux ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! omx_scaler ! omx_ctrl display-mode=OMX_DC_MODE_1080P_60 ! gstperf  ! omx_videosink   
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
perf0: frames: 13     current: 12.93     average: 12.93    arm-load: 8
perf0: frames: 24     current: 10.71     average: 11.81    arm-load: 3
perf0: frames: 35     current: 10.96     average: 11.53    arm-load: 5
perf0: frames: 47     current: 11.18     average: 11.44    arm-load: 15
perf0: frames: 59     current: 11.49     average: 11.45    arm-load: 5
perf0: frames: 70     current: 10.95     average: 11.37    arm-load: 1

You can see it is playable.

Best Regards,

Margarita

I tried with gstperf and I get no output.  Did it work with playbin2, 

root@touchlink-405fc20845ad:/media/extra/testing# gst-launch filesrc location=/m
edia/extra/testing/clip.mp4 ! qtdemux name=demux ! 'video/x-h264' ! h264parse ac
cess-unit=true ! omx_h264dec ! omx_scaler ! omx_ctrl display-mode=OMX_DC_MODE_10
80P_60 ! gstperf ! omx_videosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Recieved EOS event, press <CTRL+C> to terminate pipeline.
Recieved EOS event, press <CTRL+C> to terminate pipeline.
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 2201300 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

Thanks,

Craig

Which branch of gstreamer are you running?

Hello Craig,

I'm using EZSDK 5_05_01_04.

Openmax GST Version 00.06.00.00

Best Regards,

Margarita

I figured out what the problem is.  We use Open Embedded to build everything including gstreamer and it's plugins.  The following patch was being applied from the gstreamer.ti.com repo.  0004-h264parse-Add-workaround-for-separate-codec_config-a.patch

This was breaking the mp4 playback for us and that is why it is working for you as the Packages.make.dm81xx is not applying this patch.

Thanks,

Craig

Just an FYI to anyone falling this thread.  We did get our multiply playbin2 stream video.  We leverage the ubuntu-omap gstreamer 0.10.36, patches from Rob Clark for Qt Mobility so we can use Video QML elements.

So we have been running with the patches for Qt Mobility from Rob Clark and have made some of our own patches, so far we are successful in playing four streams (Four instances of the Video Element).  One issue we are seeing is when we close down the Video windows we can get an error from syslink:

Assertion at Line no: 380 in /home/builder/autobuilds/default/openembed/touchlink.1-tmp/work/touchlink-none-linux-gnueabi/ti-syslink-2_21_01_05-r29j/syslink_2_21_01_05/
packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/utils/hlos/knl/ResTrack.c: (elem == NULL) : failed
Assertion at Line no: 380 in /home/builder/autobuilds/default/openembed/touchlink.1-tmp/work/touchlink-none-linux-gnueabi/ti-syslink-2_21_01_05-r29j/syslink_2_21_01_05/
packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/utils/hlos/knl/ResTrack.c: (elem == NULL) : failed

This is interesting as with one stream we do not seem to get this error.  Depending on the number of streams you will see the same number of Assertions above for the number of streams when we close down the Video.  I have a colleague who has posted more detail stack trace information on the ResTrack.c (Johny Bui).  

One question I have is our application is one process with up to four separate Video Elements (four streams) decoding h.264.  Is there a problem with reference counting for the OpenMax decode plugins on gstreamer?  Once we teardown we get the above error and most of the time if fails to decode/display any streams after the error.  

Thanks,

Craig

Hello,

Craig Matsuura85376 said:

Assertion at Line no: 380 in /home/builder/autobuilds/default/openembed/touchlink.1-tmp/work/touchlink-none-linux-gnueabi/ti-syslink-2_21_01_05-r29j/syslink_2_21_01_05/
packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/utils/hlos/knl/ResTrack.c: (elem == NULL) : failed
Assertion at Line no: 380 in /home/builder/autobuilds/default/openembed/touchlink.1-tmp/work/touchlink-none-linux-gnueabi/ti-syslink-2_21_01_05-r29j/syslink_2_21_01_05/
packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/utils/hlos/knl/ResTrack.c: (elem == NULL) : failed

Getting the assertion in ResTrack.c line 380, means you have either not deleted a MessageQ, a HeapBufMP, or failed to call Notify_unregister (or Notify_unregisterSingle).

Best Regards,

Margarita

Hi Margarita,

Thanks for the reply.  This is the same information given to us from Janet.  That is good info.  One additional question I have is in regards to the OpenMAX GST plugins and how they behave if multiple streams are decoded and torn down.  Are plugins usage reference counted?  Could lack of reference counting cause us to not clean up a MessageQ, HeapBufMP or unregister? Why would we see this when the pipeline is torn down?  One stream appears to not have this problem?  Do you know who wrote the openmax plugins?  I know they came from TI.

Thanks,

Craig

Hi Margarita,

So you keep saying in many of your post you can only run one pipeline.  What is the reasoning for this and what problems are you seeing when you run multiply pipelines in a process?

Thanks,

Craig

Hello Craig,

Check Vimal Jain's answer in this tread on page 1.

Best Regards,

Margarita

Vimal,

We are using code from Rob Clarks changes to Qt Mobility that uses gstreamer and a custom eglSink to display video in Qml (All this work was doen for the Ubuntu TV project and was running on an OMAP).  At one point we had problems decoding and displaying multiply Video Qml Objects (multi-playbin2, implies multi-pipelines).    However after moving off of Gstreamer 0.10.35 and using gstreamer 0.10.36 and with a later Graphics SDK that supports an eglImage and a later EZSDK (5.05.02) we are able to decode multiple streams.  This was great for our application as we are now able to move the video windows anywhere we want and also can overlay them better with our Qml application.  So, I'm still unsure if your statement is still true on multiply pipelines.   At one time multiply pipelines would not even run before making the changes above. Note the pipelines I refer to are decoding using OpenMAX plugins.  Is the issue of multiply pipelines due to the OpenMax plugins and decode, if so this appears to not be an issue for us now using a new gstreamer (0.10.36)?   I'm trying to understand why we can decode multiply streams using Qt Mobility now.  We have one last issue, below.

We have one main issue to resolve and that is with teardown of the Video Objects (pipelines).  Before updating syslink and our EZ SDK we had decode working with mutli Qml video objects (pipelines) however on teardown we would get an occasional MessageQ error, we promptly updated based on some suggests on e2e to move to a new syslink to resolve MessageQ issues and clean up when a sigterm or sigint is encountered.  Since the move we now get ResTrack.c asserts.  I have a colleague working on this particular issue with several people (Gil, Janet).   

Seems we are very close to getting multiple pipelines.  So can you explain the exact problem that EZ SDK 5.05.01.04 had and why you need to use one pipeline?  A one pipeline solution is not ideal for us.  We also have a separate DVR application using gstreamer to capture (not decode) from rtsp camera sources.  Is the issue related only decoding and using OpenMAX?  Our application will eventually encode (using the HW accel)  the incoming data and ship it out as a rtsp  or other sink.

Thanks,

Craig

Danny,

Did you ever get a response from TI on this issue?  I am using Qt Mobility and displaying multiply streams or files.  Mobility is using playbin2 and the OMX decoders.  We have seen CPU usage between 30-50% for four streams.  We had to use a newer gstreamer 0.10.36.  Our biggest issue right now is teardown.

Craig

Hi Craig,

To be honest we were just experimenting with the decoding.  Our custom board has been designed for encoding but obviously we have other ideas for custom boards for decode.

Getting the custom board up and running has proved more than troublesome enough, custom memory maps for firmwares, custom u-boot & kernel changes for our board etc etc!  We haven't had time to revisit the decode aspects...although I have been keeping an eye on this thread for the future.

Cheers,

Danny

Hi Danny,

We too have a custom board and I feel your pain.  We are decoding and plan to encode later. 

Thanks,

Craig