GNOME Bugzilla – Bug 634402
[gst-ffmpeg] timestamp problems with h.264 transportstreams?
Last modified: 2011-05-16 18:42:00 UTC
The playback of transportstreams from astra hd-channels in h.264 is not possible here with ffdec_h264. I use the following minimal pipeline "gst-launch-0.10 filesrc location=testfile.ts ! mpegtsdemux ! ffdec_h264 ! xvimagesink" and it ends up in a diashow with lots of "GST_EVENT gstevent.c:847:gst_event_new_qos: creating qos proportion 2,305689, diff 784089392, timestamp 0:00:02.019711111" and "basesink gstbasesink.c:2699:gst_base_sink_is_too_late:<xvimagesink0> warning: There may be a timestamping problem, or this computer is too slow." messages. It runs on an Intel i7 Q720 with 8GB ram and ATI5870 so i don't think that this computer is too slow. Setting "sync=false" for xvimagesink shows a smooth playback for these files. Inserting queues/parser doesn't solve it. Any hints about this? Thanks, Thomas
can you provide this testfile?
I'm not sure about attachment limits here so the upload can be found at http://rapidshare.com/files/429820993/gstreamer-h264-testfile.tar.gz. It's 1min (70MB) of 1920x1080i content. VLC plays it smooth without problems. Inserting a queue before the sink helps a little bit, but after some time the problem comes back and so i can't use this for realtime streaming in my application...
I can reproduce some problems with the latest released versions, but this seems fixed in the latest git versions. There where some recent changes in the ffmpeg plugin element to fix the timestamps (also related to h264). Can you confirm this?
No, i've tried it here with the latest git-version from 27.10.2010 - but only changed the libgstffmpeg.so and not the complete gstreamer libs. The testfile is running fine for you with the pipeline posted above?
Works fine here with playbin2. Your pipeline doesn't work so well because it does not separate synchronisation from decoding. You need to insert a small queue (3 buffers) between the sink and the decoder, like this: gst-launch-0.10 filesrc location=testfile.ts ! mpegtsdemux ! ffdec_h264 ! queue max-size-buffers=3 max-size-time=0 max-size-bytes=0 ! xvimagesink
Unfortunately I can't use a playbin because i need to build a complex pipeline manually and the queue solution doesn't work like described in comment 2. :-(
If you need more granular control over your pipeline, you could try using uridecodebin or decodebin2. But you'll still need to make sure you have the queues as mentionned by wim in comment #5
After recompiling the whole gstreamer from git it looks much better here. Thanks for the tipps! Some questions: 1) should the queue mentioned above inserted in the audio stream too? 2) if more elements are between decoder and sink where should the queue inserted (after decoder or before sink)? It works fine now for most streams, but some stops after exact 2 seconds. In my app I'm using multiqueue and so i tested it with this: "gst-launch souphttpsrc location=http://<livestreamsource> ! mpegtsdemux name=dmx multiqueue name=mq use-buffering=1 max-size-buffers=0 max-size-bytes=0 dmx. ! mq.sink0 mq.src0 ! ffdec_h264 ! queue2 max-size-buffers=3 max-size-time=0 max-size-bytes=0 ! xvimagesink dmx. ! mq.sink1 mq.src1 ! a52dec ! audioconvert ! queue2 max-size-buffers=3 max-size-time=0 max-size-bytes=0 ! alsasink" When I set "max-size-time=5000000000" it stops after 5 seconds, but i don't understand why this happens only to some streams? I've recorded some testfiles, but the problem is not reproducable with filesrc, only from souphttpsrc. Any ideas?
This isn't a bug anymore, but a support request. Please ask your question on the gst-devel mailing list