MPEG transport stream, H264 decoding and playback speed

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

MPEG transport stream, H264 decoding and playback speed

John Pruitt
Hi all,

I am having an issue with the speed of playback of an MPEG transport stream. This is running on a TI 8148 EVM.

One pipeline is used to produce a test pattern, do H264 encoding, wrap it in an MPEG transport stream and then write it to a file.

A second pipeline is then used to read the file, demux the video stream, do the H264 decoding and play the video on the LCD display. The video looks ok but it is going too fast. The test pattern was generated at 30 frames a second and the output is played at 60 frames a second. The transport stream has presentation timestamps that look accurate for 30 frames a second. It was assumed that these timestamps would be used in the decode and play but it doesn't seem to be happening. Is there a parameter needed or a special element needed in order to pay attention to the timestamps and just play the frames at the same rate they were produced?

The recording pipeline and the output from "gstperf" which shows how many frames are being processed:

=================================
root@dm814x-evm:~# gst-launch videotestsrc num-buffers=600 is-live=true do-timestamp=true ! video/x-raw-yuv,format='(fourcc)NV12
',width=400,height=240,framerate=30/1 ! gstperf ! timeoverlay auto-resize="0" shaded-background=true ! omx_h264enc profile=2 for
ce-idr-period=4 bytestream=true ! mpegtsmux ! filesink location=jwp.600.30.4.idr.264.ts
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
perf0: frames: 32       current: 30.98   average: 30.98 arm-load: 16
perf0: frames: 63       current: 30.02   average: 30.50 arm-load: 79
perf0: frames: 93       current: 29.99   average: 30.33 arm-load: 80
perf0: frames: 124      current: 29.99   average: 30.25 arm-load: 81
perf0: frames: 155      current: 30.01   average: 30.20 arm-load: 79
perf0: frames: 185      current: 29.99   average: 30.17 arm-load: 80
perf0: frames: 216      current: 30.01   average: 30.14 arm-load: 80
perf0: frames: 246      current: 30.00   average: 30.13 arm-load: 80
perf0: frames: 276      current: 29.99   average: 30.11 arm-load: 85
perf0: frames: 307      current: 30.01   average: 30.10 arm-load: 82
perf0: frames: 337      current: 30.00   average: 30.09 arm-load: 79
perf0: frames: 367      current: 29.98   average: 30.08 arm-load: 77
perf0: frames: 398      current: 30.00   average: 30.08 arm-load: 77
perf0: frames: 429      current: 30.00   average: 30.07 arm-load: 77
perf0: frames: 459      current: 29.99   average: 30.07 arm-load: 78
perf0: frames: 489      current: 30.00   average: 30.06 arm-load: 79
perf0: frames: 520      current: 30.01   average: 30.06 arm-load: 77
perf0: frames: 551      current: 29.99   average: 30.06 arm-load: 74
perf0: frames: 582      current: 30.02   average: 30.05 arm-load: 79
Recieved EOS event, press <CTRL+C> to terminate pipeline.
Got EOS from element "pipeline0".
Execution ended after 19996928300 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
root@dm814x-evm:~#

=================================

The playback pipeline and output:


==================================
root@dm814x-evm:~# gst-launch filesrc location=jwp.600.30.4.idr.264.ts ! mpegtsdemux  ! queue ! h264parse access-unit=true ! omx
_h264dec  use-timestamps=true ! gstperf  ! omx_scaler ! video/x-raw-yuv,width=800,height=480 ! omx_ctrl display-mode=OMX_DC_MODE
_1080P_60 display-device=LCD ! omx_videosink sync=false display-device=LCD
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...

(gst-launch-0.10:1481): GStreamer-CRITICAL **: _gst_util_uint64_scale_int: assertion `denom > 0' failed
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
perf0: frames: 61       current: 60.59   average: 60.59 arm-load: 13
perf0: frames: 122      current: 60.25   average: 60.42 arm-load: 10
perf0: frames: 183      current: 60.26   average: 60.37 arm-load: 9
perf0: frames: 244      current: 60.26   average: 60.34 arm-load: 8
perf0: frames: 305      current: 60.26   average: 60.32 arm-load: 11
perf0: frames: 366      current: 60.26   average: 60.31 arm-load: 14
perf0: frames: 427      current: 60.26   average: 60.30 arm-load: 13
perf0: frames: 488      current: 60.26   average: 60.30 arm-load: 12
perf0: frames: 549      current: 60.26   average: 60.29 arm-load: 19
Recieved EOS event, press <CTRL+C> to terminate pipeline.
Recieved EOS event, press <CTRL+C> to terminate pipeline.
Got EOS from element "pipeline0".
Execution ended after 9703074850 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
root@dm814x-evm:~#

==================================

Any suggestions as to arguments that might fix this would be appreciated.

Thanks.

John Pruitt



_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: MPEG transport stream, H264 decoding and playback speed

Tim-Philipp Müller-2
On Thu, 2012-10-04 at 15:59 -0400, John Pruitt wrote:

Hi,

> root@dm814x-evm:~# gst-launch filesrc location=jwp.600.30.4.idr.264.ts ! mpegtsdemux  ! queue ! h264parse access-unit=true ! omx
> _h264dec  use-timestamps=true ! gstperf  ! omx_scaler ! video/x-raw-yuv,width=800,height=480 ! omx_ctrl display-mode=OMX_DC_MODE
> _1080P_60 display-device=LCD ! omx_videosink sync=false display-device=LCD

Perhaps I didn't read your post carefully enough, but just be sure:
sync=false on the sink typically disables syncing against the clock
according to the timestamps, instead outputting the data as fast as
possible. Not sure if that's on purpose or not.


> (gst-launch-0.10:1481): GStreamer-CRITICAL **: _gst_util_uint64_scale_int: assertion `denom > 0' failed

That's not good, you should investigate where that comes from and fix it
(with G_DEBUG=fatal_warnings plus a debugger).

Cheers
 -Tim

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: MPEG transport stream, H264 decoding and playback speed

John Pruitt
Thanks Tim. Using sync=true fixed the pacing issue. Still looking into the other issue.

John Pruitt

Critical Link, LLC        
315.425.4045 x287





On Thu, Oct 4, 2012 at 4:15 PM, Tim-Philipp Müller <[hidden email]> wrote:
On Thu, 2012-10-04 at 15:59 -0400, John Pruitt wrote:

Hi,

> root@dm814x-evm:~# gst-launch filesrc location=jwp.600.30.4.idr.264.ts ! mpegtsdemux  ! queue ! h264parse access-unit=true ! omx
> _h264dec  use-timestamps=true ! gstperf  ! omx_scaler ! video/x-raw-yuv,width=800,height=480 ! omx_ctrl display-mode=OMX_DC_MODE
> _1080P_60 display-device=LCD ! omx_videosink sync=false display-device=LCD

Perhaps I didn't read your post carefully enough, but just be sure:
sync=false on the sink typically disables syncing against the clock
according to the timestamps, instead outputting the data as fast as
possible. Not sure if that's on purpose or not.


> (gst-launch-0.10:1481): GStreamer-CRITICAL **: _gst_util_uint64_scale_int: assertion `denom > 0' failed

That's not good, you should investigate where that comes from and fix it
(with G_DEBUG=fatal_warnings plus a debugger).

Cheers
 -Tim

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel