GNOME Bugzilla – Bug 618336
[mpegvideoparse] mpegvideoparse makes some streams unplayable
Last modified: 2010-12-12 22:49:05 UTC
The attached mpegts will not play with playbin never getting out of prerolling. The culprit can be tracked down the mpegvideoparse. This plays the file: gst-launch filesrc location=small.ts ! mpegtsdemux name=ts ts.audio_02a0 ! a52dec ! queue ! pulsesink ts.video_0202 ! queue ! mpeg2dec ! ffmpegcolorspace ! videorate ! queue ! xvimagesink This does not: gst-launch filesrc location=small.ts ! mpegtsdemux name=ts ts.audio_02a0 ! a52dec ! queue ! pulsesink ts.video_0202 ! queue ! mpegvideoparse ! mpeg2dec ! ffmpegcolorspace ! videorate ! queue ! xvimagesink
Created attachment 160802 [details] Test mpegts part 1 File too big for bugzilla. Concatenate these two files together.
Created attachment 160803 [details] Test mpegts part 2
I have converted some of the debugging info in mpegpacketiser into the proper form. I found that in the stream there is no timestamp when a picture packet is sent and the last timestamp was sent at the sequence header which is in another block in the packetiser. The old code would only look at timestamps for blocks which contain picture headers. I have tried refactoring the code to make it work for this case. I'm attaching two patches. One for debugging the mpegpacketiser code, the other to change the block timestamp handling. It does seem to work for me.
Created attachment 160938 [details] [review] Add debugging output in mpegpacketiser.
Created attachment 160939 [details] [review] Change timestamp handling in mpegpacketiser
Created attachment 163356 [details] [review] Change timestamp handling in mpegpacketiser This patch now applies directly to current git.
Created attachment 163357 [details] [review] Add debugging output in mpegpacketiser. This patch now applies on top of the changed timestamp handling and initialises correctly. It can probably quite easily be merged onto current git without timestamp changes.
Fixed the bug differently: mpegvideoparse: Apply previous timestamp when there isn't any newer. If the current incoming packet didn't carry a timestamp, but a previous packet had one we didn't yet use, then apply that timestamp to the next picture. Fixes: #618336 I don't like the debugging patch - it should be the other way around, with the packetiser using the mpegvideoparse category, if at all. Also, the debug should be at LOG level - a better level to use for 'high frequency events that occur during non-exception-case processing'
*** Bug 636804 has been marked as a duplicate of this bug. ***