Mosaic example using gstreamer on 8168 (EZSDK version 5_04_00_11)

Frank,

Please provide the stream resolution for the sample streams and EZSDK version used in your test setup

Ansari,

the EZSDK version is 05_04_00_11

The stream resolution is 1280x720@24

FYI Each 720p H.264 decoder instance needs approx 7.5 MB internal memory which is allocated from the memory segment VIDEO_M3_INT_HEAP_CACHED (pls refer to the firmware loader file $(EXSDK)/board-support/media-controller-utils_2_05_00_17/src/firmware_loader/memsegdef_default.c). The default size of this segment is 24 MB, which can support upto three 720p decoder instances. With the default memory setup you will be able to run upto three 720p instances.You have to increase the memory VIDEO_M3_INT_HEAP_CACHED to approx 30 MB to run 4 channel 720p h264 streams

 You need to modify the memsegdef_default.c. The default EZSDK memory map is given in this wiki http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map . The memory sections given in green colour in the wiki can be modified via firmware loader module and the pre-built firmware binaries can be used as it is. I've attached a sample modified firmware loader memsegdef_default.c file where I've reduced the CMEM and DSP_ALG_HEAP segment sizes and increased the VIDEO_M3_INT_HEAP_CACHED size from 24 MB to 30 MB.  Following are the steps

1. Re-build the firmware loader after modifying the memsegdef_default.c with the command  "make media-controller-utils" from the top level EZSDK directory
2. firmware loader binary firmware_loader_a8host_debug.xv5T will be generated at board-support/media-controller-utils_2_05_00_17/lib/firmware_loader/bin/ti814x-evm
3. Rename the firmware loader binary to firmware_loader
4. Replace the existing firmware_loader with the new firmware_loader binary in the target filesystem at /usr/bin
5. Re boot the board and test the usecase
   
   

Regards

Ansari

Ansari,

thanks for your answer.

After doing all your steps there is another error message.

gst-launch omx_videomixer port-index=0 name=mix ! 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.
request pad!!
creating pad with name:sink_00
pad class init!!
Setting sink pad:0
request pad done ret!!
request pad!!
creating pad with name:sink_01
Setting sink pad:1
request pad done ret!!
request pad!!
creating pad with name:sink_02
Setting sink pad:2
request pad done ret!!
request pad!!
creating pad with name:sink_03
Setting sink pad:3
request pad done ret!!
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink0: Cannot identify device '/dev/video1'.
Additional debug info:
v4l2_calls.c(493): gst_v4l2_open (): /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink0:
system error: No such file or directory
Setting pipeline to NULL ...
Freeing pipeline ...

Br
Frank

Huber,

Are you able to run a single channel with the command

"gst-launch omx_videomixer port-index=0 name=mix ! v4l2sink userpointer=true filesrc location=sample_1.h264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! mix."

Huber,

Looks like V4l2 in not enabled in your setup. Please try the following commands

1. Boot the board and log in as "root"
2. cd /usr/share/ti/ti-media-controller-utils
3. cp load-hd-v4l2-firmware.sh /etc/init.d/load-hd-firmware.sh ( load-hd-v4l2-firmware.sh enables v4l2)
4. type "sync"
5. Restart the board
6. Type "echo 0 > /sys/devices/platform/vpss/graphics0/enabled"
7. Run the gstpipe line

The detailed steps are available in DM816x_EZ_Software_Developers_Guide.pdf under "docs" section Look for the sections "How to change from OMX to V4L2 firmware for capture/display"

Ansari,

thanks for your answer.

After your recommended steps there is a mosaic visible.
But only the first frame of the videos. The videos are not playing (looks like paused).

Same when I start one video only.

the printouts are now:

gst-launch omx_videomixer port-index=0 name=mix ! v4l2sink userpointer=true filesrc location=sample_1.h2
64 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! mix. filesrc lo
cation=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' ! h264
parse access-unit=true ! omx_h264dec ! mix.
request pad!!
creating pad with name:sink_00
pad class init!!
Setting sink pad:0
request pad done ret!!
request pad!!
creating pad with name:sink_01
Setting sink pad:1
request pad done ret!!
request pad!!
creating pad with name:sink_02
Setting sink pad:2
request pad done ret!!
request pad!!
creating pad with name:sink_03
Setting sink pad:3
request pad done ret!!
Setting pipeline to PAUSED ...

** (gst-launch-0.10:1395): CRITICAL **: gst_v4l2sink_sync_rotation: assertion `v4l2_ioctl (fd, VIDIOC_S_CTRL, &control) >= 0' failed

** (gst-launch-0.10:1395): CRITICAL **: gst_v4l2sink_sync_rotation: assertion `v4l2_ioctl (fd, VIDIOC_S_CTRL, &control) >= 0' failed

** (gst-launch-0.10:1395): CRITICAL **: gst_v4l2sink_sync_flip: assertion `v4l2_ioctl (fd, VIDIOC_S_CTRL, &control) >= 0' failed
Video mixer activate push!!
Pipeline is PREROLLING ...
In sink set caps:video/x-raw-yuv-strided, width=(int)1280, height=(int)720, format=(fourcc)NV12, rowstride=(int)1408, framerate=(fraction)240
00/1001, interlaced=(boolean)false
ip width:1280, ip height: 720, ip stride:1408
Starting input thread...num sink pads:4
ip zorder - starting from lowest: 0, 1, 2, 3
In sink set caps:video/x-raw-yuv-strided, width=(int)1280, height=(int)720, format=(fourcc)NV12, rowstride=(int)1408, framerate=(fraction)240
00/1001, interlaced=(boolean)false
ip width:1280, ip height: 720, ip stride:1408
In sink set caps:video/x-raw-yuv-strided, width=(int)1280, height=(int)720, format=(fourcc)NV12, rowstride=(int)1408, framerate=(fraction)240
00/1001, interlaced=(boolean)false
ip width:1280, ip height: 720, ip stride:1408
In sink set caps:video/x-raw-yuv-strided, width=(int)1280, height=(int)720, format=(fourcc)NV12, rowstride=(int)1408, framerate=(fraction)240
00/1001, interlaced=(boolean)false
ip width:1280, ip height: 720, ip stride:1408
created output caps:video/x-raw-yuv, width=(int)1280, height=(int)720, format=(fourcc)YUY2, framerate=(fraction)15/1
In src set caps:video/x-raw-yuv, width=(int)1280, height=(int)720, format=(fourcc)YUY2, framerate=(fraction)15/1
set src_setcaps  height:720, width:1280
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock

Br

Frank

Frank,

I've tried a sample 720 H.264 stream with the above pipe line and the play quality looked fine. It could be a stream specific issue.Please let me know the stream name and its online availability. Also try with a different stream

Ansari

Ansari,

the stream is available in my dropbox.

https://www.dropbox.com/sh/ukd1py4htgb3wb6/qURx8oiNvX

Let me know when you downloaded it.

Br

Frank

Ansari,

one more question.

During boot there are two i2c messages:

Usage : firmware_loader <Processor Id> <Location of Firmware> <start|stop> [-mmap <memory_map_file>] [-i2c <0|1>]

Are this messages a normal behavior?

See attached log.

5127.netra-boot-log.txt

Br
Frank

Hello Ansari,

I do get the same messages when starting the load-hd-v4l2-firmware.sh at startup.

I tried to add the -mmap /usr/share/ti/ti-media-controller-utils/mm_dm81xxbm.bin, the the firmware loader will load but the load fails (tvp7002 i2c error messages cause the system to loop forever).

The default /etc/init.d/load-hd-firmware.sh specifies a mmap file that is not present (missing underscore) and the load-hd-v4l2-firmware.sh (in /usr/share/ti/ti-media-controller-utils/) does not work when copied to /etc/init.d/load-hd-firmware.

Regards,

Lo

Frank,

I've downloaded the stream.

The i2c message is normal, the firmwares are getting loaded into two cores one after another

Regards

Ansari

Ansari,

are there any news?

Could you test the downloaded stream?

Here the situation is still the same. Starting one or four streams, the first frame is showed only.

Here are the printouts when I start one stream. Maybe you can see a hint....

gst-launch omx_videomixer port-index=0 name=mix ! v4l2sink userpointer=true filesrc location=sample_1.h2
64 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! mix.
request pad!!
creating pad with name:sink_00
pad class init!!
Setting sink pad:0
request pad done ret!!
Setting pipeline to PAUSED ...

** (gst-launch-0.10:1388): CRITICAL **: gst_v4l2sink_sync_rotation: assertion `v4l2_ioctl (fd, VIDIOC_S_CTRL, &control) >= 0' failed

** (gst-launch-0.10:1388): CRITICAL **: gst_v4l2sink_sync_rotation: assertion `v4l2_ioctl (fd, VIDIOC_S_CTRL, &control) >= 0' failed

** (gst-launch-0.10:1388): CRITICAL **: gst_v4l2sink_sync_flip: assertion `v4l2_ioctl (fd, VIDIOC_S_CTRL, &control) >= 0' failed
Video mixer activate push!!
Pipeline is PREROLLING ...
In sink set caps:video/x-raw-yuv-strided, width=(int)1280, height=(int)720, format=(fourcc)NV12, rowstride=(int)1408, framerate=(fraction)240
00/1001, interlaced=(boolean)false
ip width:1280, ip height: 720, ip stride:1408
Starting input thread...num sink pads:1
ip zorder - starting from lowest: 0
created output caps:video/x-raw-yuv, width=(int)1280, height=(int)720, format=(fourcc)YUY2, framerate=(fraction)15/1
In src set caps:video/x-raw-yuv, width=(int)1280, height=(int)720, format=(fourcc)YUY2, framerate=(fraction)15/1
set src_setcaps  height:720, width:1280
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Caught interrupt -- handling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 1599904096963 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...


---------------------------
pressing control C after some minutes
---------------------------

!!!!!!!!!unreference all the remaining buffers!!!!!!!!!Video mixer activate push!!
paused to ready!!
setting EOS to true
Waiting for ip thread to exit..semup!!
goto leave!!
paused to ready...done!!
Setting pipelinet81xx_vidout t81xx_vidout: VIDOUT0: invalid dequeue
 to NULL ...
calling g_omx_core_deinit
Freeing pipeline ...
root@dm816x-evm:~/karnww01/frhu/netra/gst/ex80-play264#

Br

Frank

Frank,

I've downloaded the stream and able to recreate the hang issue with single stream. The stream profile shows its main profile 5.1 stream with num_ref_frame is set to 5.

The decoder needs 2*num_ref_frames + 1 to decode the stream. So if the number of output buffers for omx_h264dec is set to 11, then the pipeline is working. We are still looking into this issue.

Regards

Ansari

Frank,

In the mosaic chain, the h264dec optimal buffer requirements is 11 ( 2*num_ref_frames + 1). num_ref_frames value can be obtained from the stream SPS param. For 720p streams, the out buffer requirement ranges from 8 to 15, depending on the profile. I've made the changes to support different h264 output buffer count and attached the patch. The following chain is verified with this patch

gst-launch -v omx_videomixer name=mix ! v4l2sink userpointer=true filesrc location=sample_1.h264 ! gstperf! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec output-buffers=8 ! 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.

It is suggested always to check the "num_ref_frames" for the test streams, if its more than 5, then the h264dec output buffer count has to be updated. For ex if the num_ref_frames for a given stream is 6, then the h264dec output buffer can be updated to 12 with the following command

gst-launch -v omx_videomixer port-index=0 name=mix ! v4l2sink userpointer=true filesrc location=sample_1.h264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec output-buffers=12 ! gstperf ! mix.

Note : We are able to run upto 3 channels, there are further omx level changes required to enable four channel decode, pls let me know if this is your requirement. I'll go ahead and send you the steps required to enabled 4 channel decoding.   The following are the steps to test the patch

1. Copy the attached patch to $(EZSDK)/component-sources/gst-openmax_GST_DM81XX_00_05_00_00/patches/

2. cd to $(EZSDK)/component-sources/gst-openmax_GST_DM81XX_00_05_00_00

3. Type the command patch -p1 < patches/h264dec_outbuffer_update.patch

4. After the patch update, cd to the $(EZSDK) and type "make gstomx"

5. Copy the generated libgstomx.so ( component-sources/gst-openmax_GST_DM81XX_00_05_00_00/omx/.libs/libgstomx.so) to the target file system (target/usr/lib/gstreamer-0.10)

6. Test the mosaic usecase

Regards

Ansari

Ansari,

thanks for this patch.

Up to three channels are now running, also with the sample_1.h264 stream.

Yes we need up to 4 channels running.

Assuming you joined the telephone conference this morning.  So maybe you saw our requirements specification.

I can send this paper to you, but I will not put it in e2e. Or maybe you can ask your colleagues for this paper.

Br
Frank

Frank,

Good to see that things are working at your end.

To enable 4 channel decoding, you need to modify the omx wrapper code and the firmware loader. For firmware loader modifications, pls refer to my earlier thread http://e2e.ti.com/support/embedded/linux/f/354/p/205486/729428.aspx#729428. I've also attached a sample memsegdef_default.c in this thread. The following are the steps required for OMX wrapper modification

The following are the steps to test the patch

1. Copy the attached patch to $(EZSDK)/component-sources/omx_05_02_00_38/patches/

2. cd to $(EZSDK)/component-sources/omx_05_02_00_38

3. Type the command "patch -p1 < patches/0002-increase_buffers.patch"

4. After the patch update, cd to the $(EZSDK) and type "make omx" ( assuming "make components" is done already)

5. Copy the generated libtiomx.so.5.2 ( component-sources/omx_05_02_00_38/lib) to the target file system (targetfs/usr/lib)

6. Replace the original firmware loader with the modified firmware_loader in the target file system ((targetfs/usr/bin)

7. Run the 4 channel mosaic pipeline

gst-launch -v omx_videomixer name=mix ! v4l2sink userpointer=true filesrc location=sample_1.h264 ! gstperf! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec output-buffers=8 ! 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.

Hello,

this is the gstreamer command line I use, is scales up to fill the entire screen:

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

root@dm816x-evm:~# gst-launch omx_videomixer port-index=0 name=mix ! 'video/x-raw-yuv,width=1920,height=1080' ! 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.

Hello Ansari,

will the patches that you posted be included in the next SDK (5.05?) release?

Regards,

Lo

Lo,

Sure, We will plan to include the patch in the next SDK release

Regards

Ansari

Lo,

In the above pipeline the videomixer width and height are set to 1920 and 1080 respectively.  Either it's has be set as 'video/x-raw-yuv,width=1280,height=720' , or dont use the parameters, the default videomixer resolution in 1280x720

Ansari

Hello Ansari,

the pipeline I posted seems to work fine. Is there a reason I should not upscale to 1920 x 1080 this way?

Regards,

Lo

videomixer with 1920x1080 resolution is perfectly fine. There are no differences in the Video M3 and VPSS loads, except there is some additional ARM load with HD resolution

Ansari,

thanks for your answer.

With this patch gstreamer is working with 4 HD videos, when the video resolution is 1280x720.

With video resolution 1920x1080 it doesn't work.

You can test this with the video   /usr/share/ti/data/videos/dm816x_1080p_demo.264  which comes with the demo board.

The maximum is three times 1920x1080 and one time 1280x720, but four times 1920x1080 failed!

After changing    #define DOMX_CORE_COMPINFOTBL_MAXNUMBUFFS_GENERIC   (64)   to 128 it also doesn't work.

Can you please check this.

Thanks.

Br
Frank

Frank,

The sample demo stream dm816x_1080p_demo.264 is a Main profile stream with Level 0.  The corresponding internal memory requirement for this profile is approx     8.44 MB approx per channel. Please refer to H264_Decoder_HDVICP2_DataSheet.pdf ($(EZSDK/component-sources/ivahd_h264dec_01_00_00_08_production/packages/ti/sdo/codecs/h264dec/docs) for the internal memory requirements  at Memory Statistics of Media Controller section. In order to create a four channel with this stream, the internal heap memory VIDEO_M3_INT_HEAP_CACHED size has to be increased accordingly through the firmware loader. In this case a min of 33 MB is required to run a four channel 1080p.

Regards

Ansari

Ansari,

after double checking this point, 4 native HD videos (1920x1080) are still not working.

There is one file       board-support/media-controller-utils_2_05_00_17/src/firmware_loader/memsegdef_default.c    which has  VIDEO_M3_INT_HEAP_CACHED  set to 0x03000000. This is 48 MB and should be enough.

I rebuild the firmware loader, but it doesn't help.

Can you please check this issue again?
Do you have four native HD videos running with gstreamer?

Thanks.

Br
Frank

Frank,

Looks like the IPC_SR_FRAME_BUFFERS share region memory where the frame buffers are allocated is going out of memory. You can verify this by running sys_top command in a different telnet session, I've given the sys_top snapshot for the 4 channel HD usecase, the SR2 with 188MB memory  is left out out  with 18MB, which is not sufficient enough to run the HD usecase.  The IPC_SR_FRAME_BUFFERS has to be increased appropriately to run the 4 channel HD usecase

Firmware Version: UNKNOWN/INTERNAL VERSION
 0 Heap:Size 1048576    Used 510296     MaxU 510872     Free 538280     LarF 538216
Num SR :4
SRIn 0 :PhyA 0x9f700000 Virt 0x0        Size 0x200000
 SRHeap:Size 2095488    Used 19584      MaxU 21760      Free 2075904    LarF 2074624
SRIn 1 :PhyA 0x9a100000 Virt 0x0        Size 0x100000
 SRHeap:Size 1048448    Used 0          MaxU 0          Free 1048448    LarF 1048448
SRIn 2 :PhyA 0xb3d00000 Virt 0x0        Size 0xbc00000
 SRHeap:Size 197132160  Used 177745408  MaxU 187438848  Free 19386752   LarF 19386752

Regards

Ansari

Frank,

I've attached the sample firmware loader source and omx core files required to run the 4 channel HD usecase.

1. Update the firmware loader memsegdef_default.c to change the SR2 length and offset and rebuild the firmware loader
2. replace the existing firmware loader binary in the target filesystem targetfs/usr/bin.
3. Update the SR2 length and offset changes in memtbl_cfg.h ( $EZSD)/component-sources/omx_05_02_00_38/src/ti/omx/memcfg ). Please refer to http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map#Linux_applications_for_OMX  for more details0574.SR2_memorychange.zip
4. Rebuild the OMX core with the command, make omx from the top level EZSDK directory
5. Copy the generated libtiomx.so.5.2 to the target file system targetfs/usr/lib
6. Rebuild the gst omx with the command "make gstomx" from top level EZSDK directory
7. Copy the generated libgstomx.so to the target filesystem targetfs/usr/lib/\gstreamer-0.10

Regards

Ansari

Files attached

Ansari,

thanks for this new patch. Four HD streams are now working.

But there is another issue when using omx_videomixer with v4l2sink.

Starting one video _without_  v4l2sink using this command:

time gst-launch -v filesrc location=/usr/share/ti/data/videos/1920x1080_34s.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
real    0m 38.01s
user    0m 8.27s
sys     0m 2.62s

the video plays for 38 seconds. The speed of the video is "normal".

Starting one video _with_  v4l2sink using this command:

time gst-launch omx_videomixer port-index=0 name=mix ! v4l2sink userpointer=true filesrc location=/usr/share/ti/data/videos/1920x1080_34s.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! mix.
real    2m 16.02s (136s)
user    0m 7.58s
sys     0m 2.38s

the video plays for 136 seconds. The speed of the video is too slow.

This behavior has nothing to do with the patches!

Also the number of videos are independent, it happens with 1, 2, 3 or 4 videos.

When playing videos with omx_videomixer the video is always (about) 4 times too slow.

The video I use for this test has a counter inside. This can help to see this issue. You can generate this video with this command on a TI demo board:

gst-launch -v videotestsrc num-buffers=2000 ! video/x-raw-yuv, framerate=30/1, width=1920, height=1080 ! timeoverlay halign=left valign=bottom text="Stream 1 time:" shaded-background=true ! omx_h264enc ! filesink location=1920x1080_34s.264

The issue is also independent with the type of video. It happens with all tested videos.

Hope you can help me again.

Br
Frank

Frank,

Please send the log files, The log could be generated with the command

time gst-launch -v omx_videomixer port-index=0 name=mix ! gstperf  ! v4l2sink userpointer=true filesrc location=/usr/share/ti/data/videos/1920x1080_34s.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! mix.

Regards

Ansari

Ansari,

assuming you mean the console printout...

root@dm816x-evm:~# time gst-launch -v omx_videomixer port-index=0 name=mix ! gstperf  ! v4l2sink userpointer=true filesrc location=/usr/share/ti/data/videos/1920x1080_34s.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! mix.
...
...
New clock: GstSystemClock
perf0: frames: 17       current: 16.92   average: 16.92 arm-load: 3
perf0: frames: 33       current: 15.01   average: 15.94 arm-load: 10
perf0: frames: 48       current: 14.99   average: 15.63 arm-load: 11
perf0: frames: 64       current: 15.01   average: 15.47 arm-load: 6
perf0: frames: 80       current: 14.99   average: 15.37 arm-load: 16
perf0: frames: 96       current: 15.00   average: 15.31 arm-load: 14
perf0: frames: 112      current: 15.01   average: 15.26 arm-load: 7
perf0: frames: 127      current: 14.99   average: 15.23 arm-load: 11
perf0: frames: 143      current: 15.01   average: 15.21 arm-load: 11
perf0: frames: 158      current: 14.99   average: 15.19 arm-load: 12
perf0: frames: 174      current: 15.01   average: 15.17 arm-load: 11
perf0: frames: 189      current: 14.99   average: 15.15 arm-load: 11
perf0: frames: 205      current: 15.01   average: 15.14 arm-load: 13
perf0: frames: 220      current: 14.99   average: 15.13 arm-load: 9
perf0: frames: 236      current: 15.01   average: 15.12 arm-load: 6
perf0: frames: 251      current: 14.99   average: 15.12 arm-load: 11
perf0: frames: 267      current: 15.00   average: 15.11 arm-load: 13
perf0: frames: 283      current: 15.01   average: 15.10 arm-load: 9
perf0: frames: 298      current: 14.99   average: 15.10 arm-load: 12
perf0: frames: 314      current: 15.01   average: 15.09 arm-load: 13
perf0: frames: 329      current: 15.00   average: 15.09 arm-load: 17
perf0: frames: 345      current: 15.00   average: 15.08 arm-load: 8
perf0: frames: 361      current: 15.00   average: 15.08 arm-load: 11
perf0: frames: 376      current: 14.99   average: 15.08 arm-load: 9
perf0: frames: 392      current: 15.01   average: 15.07 arm-load: 13
perf0: frames: 407      current: 14.99   average: 15.07 arm-load: 11
perf0: frames: 423      current: 15.00   average: 15.07 arm-load: 11
perf0: frames: 439      current: 15.00   average: 15.07 arm-load: 16
perf0: frames: 455      current: 14.99   average: 15.06 arm-load: 9
perf0: frames: 471      current: 15.01   average: 15.06 arm-load: 46
perf0: frames: 487      current: 15.00   average: 15.06 arm-load: 97
perf0: frames: 503      current: 15.00   average: 15.06 arm-load: 24
perf0: frames: 519      current: 15.01   average: 15.06 arm-load: 13
perf0: frames: 534      current: 14.99   average: 15.05 arm-load: 13
perf0: frames: 550      current: 15.01   average: 15.05 arm-load: 14
perf0: frames: 566      current: 14.99   average: 15.05 arm-load: 16
perf0: frames: 582      current: 15.00   average: 15.05 arm-load: 7
perf0: frames: 598      current: 15.01   average: 15.05 arm-load: 9
perf0: frames: 613      current: 14.99   average: 15.05 arm-load: 13
perf0: frames: 629      current: 15.01   average: 15.05 arm-load: 11
perf0: frames: 645      current: 15.01   average: 15.05 arm-load: 14
perf0: frames: 660      current: 14.99   average: 15.04 arm-load: 13
perf0: frames: 676      current: 15.00   average: 15.04 arm-load: 13
perf0: frames: 691      current: 14.99   average: 15.04 arm-load: 12
perf0: frames: 707      current: 15.01   average: 15.04 arm-load: 5
perf0: frames: 723      current: 15.00   average: 15.04 arm-load: 10
perf0: frames: 739      current: 15.01   average: 15.04 arm-load: 14
perf0: frames: 755      current: 14.99   average: 15.04 arm-load: 10
perf0: frames: 771      current: 15.00   average: 15.04 arm-load: 14
perf0: frames: 787      current: 15.01   average: 15.04 arm-load: 9
perf0: frames: 803      current: 14.99   average: 15.04 arm-load: 14
perf0: frames: 819      current: 15.00   average: 15.04 arm-load: 8
perf0: frames: 835      current: 15.01   average: 15.03 arm-load: 8
perf0: frames: 851      current: 14.99   average: 15.03 arm-load: 11
perf0: frames: 867      current: 15.01   average: 15.03 arm-load: 12
perf0: frames: 882      current: 14.99   average: 15.03 arm-load: 9
perf0: frames: 898      current: 15.01   average: 15.03 arm-load: 11
perf0: frames: 913      current: 14.99   average: 15.03 arm-load: 13
perf0: frames: 929      current: 15.01   average: 15.03 arm-load: 11
perf0: frames: 944      current: 14.99   average: 15.03 arm-load: 7
perf0: frames: 960      current: 15.01   average: 15.03 arm-load: 7
perf0: frames: 976      current: 15.00   average: 15.03 arm-load: 9
perf0: frames: 992      current: 15.01   average: 15.03 arm-load: 8
perf0: frames: 1008     current: 14.99   average: 15.03 arm-load: 13
perf0: frames: 1024     current: 15.01   average: 15.03 arm-load: 12
perf0: frames: 1040     current: 14.99   average: 15.03 arm-load: 13
perf0: frames: 1056     current: 15.00   average: 15.03 arm-load: 8
perf0: frames: 1072     current: 15.01   average: 15.03 arm-load: 7
perf0: frames: 1088     current: 14.99   average: 15.03 arm-load: 10
perf0: frames: 1104     current: 15.00   average: 15.03 arm-load: 13
perf0: frames: 1120     current: 15.01   average: 15.03 arm-load: 14
perf0: frames: 1136     current: 14.99   average: 15.03 arm-load: 10
perf0: frames: 1151     current: 15.00   average: 15.03 arm-load: 18
perf0: frames: 1167     current: 15.01   average: 15.02 arm-load: 14
perf0: frames: 1182     current: 14.99   average: 15.02 arm-load: 8
perf0: frames: 1198     current: 15.01   average: 15.02 arm-load: 7
perf0: frames: 1213     current: 14.99   average: 15.02 arm-load: 9
perf0: frames: 1229     current: 15.00   average: 15.02 arm-load: 8
perf0: frames: 1244     current: 14.99   average: 15.02 arm-load: 12
perf0: frames: 1260     current: 15.00   average: 15.02 arm-load: 14
perf0: frames: 1276     current: 15.01   average: 15.02 arm-load: 15
perf0: frames: 1292     current: 14.99   average: 15.02 arm-load: 9
perf0: frames: 1308     current: 15.01   average: 15.02 arm-load: 9
perf0: frames: 1323     current: 14.99   average: 15.02 arm-load: 13
perf0: frames: 1339     current: 15.01   average: 15.02 arm-load: 13
perf0: frames: 1354     current: 14.99   average: 15.02 arm-load: 12
perf0: frames: 1370     current: 15.01   average: 15.02 arm-load: 9
perf0: frames: 1386     current: 15.00   average: 15.02 arm-load: 13
perf0: frames: 1401     current: 14.99   average: 15.02 arm-load: 14
perf0: frames: 1417     current: 15.01   average: 15.02 arm-load: 6
perf0: frames: 1432     current: 14.99   average: 15.02 arm-load: 5
perf0: frames: 1448     current: 15.01   average: 15.02 arm-load: 11
perf0: frames: 1463     current: 14.99   average: 15.02 arm-load: 12
perf0: frames: 1479     current: 15.00   average: 15.02 arm-load: 14
perf0: frames: 1495     current: 15.01   average: 15.02 arm-load: 14

Br
Frank

Hello Ansari,

I have some question about frame rate of videomixer.

I tried to decode 1920x1080P60 h264 file which is generated by the following pipeline:

gst-launch -v videotestsrc num-buffers=2000 ! video/x-raw-yuv, framerate=60/1, width=1920, height=1080 ! timeoverlay halign=left valign=bottom text="Stream 1 time:" shaded-background=true ! omx_h264enc ! gstperf !filesink location=1920x1080P60.h264

When I play this file with videomixer :

gst-launch omx_videomixer framerate=60 port-index=0 name=mix ! gstperf ! v4l2sink userpointer=true filesrc location=1920x1080P60_1.h264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! mix.

playback speed is normal.

perf0: frames: 62       current: 61.02   average: 61.02 arm-load: 29
perf0: frames: 123      current: 59.95   average: 60.49 arm-load: 35
perf0: frames: 184      current: 60.05   average: 60.34 arm-load: 39

Then next I play two files with videomixer:

gst-launch omx_videomixer framerate=60 port-index=0 name=mix ! gstperf ! v4l2sink userpointer=true filesrc location=1920x1080P60_1.h264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! mix. filesrc location=1920x1080P60_2.h264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! mix.

perf0: frames: 43       current: 42.71   average: 42.71 arm-load: 25
WARNING: from element /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink0: A lot of bu.
Additional debug info:
gstbasesink.c(2739): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstV4:
There may be a timestamping problem, or this computer is too slow.
perf0: frames: 86       current: 42.02   average: 42.36 arm-load: 54
perf0: frames: 129      current: 42.08   average: 42.27 arm-load: 56
WARNING: from element /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink0: A lot of bu.
Additional debug info:
gstbasesink.c(2739): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstV4:
There may be a timestamping problem, or this computer is too slow.

playback speed is slowdown to 42 fps...I dont know what happened?

Is it decoder capability issue?(only 2x1080P60, as I know HDVICP2 can decode 3x1080P60)

Any help will be appreciate!

thanks

Best regards,

Steven