GNOME Bugzilla – Bug 119206
mp1videoparse plugin doesnt perform its core function
Last modified: 2004-12-22 21:47:04 UTC
mp1videoparse is unable to do its main function: provide proper timestamps on the buffers.
I'm working on this right now, so... What did you have in mind? MPEG has three ways of providing timestamps: * using mux_rate (very rough) in the demuxer * using PTS, in the demuxer (the five bytes before the actual video packet) * using the time_code in the video packet. This is actually meant for display only, not for actual reading, if I understand the specs correctly. However, it's the only one that works without needing the demuxer. I prefer (2) if there's a demuxer involved, but (3) if there's no demuxer involved, obviously.
Created attachment 23559 [details] [review] see comment
Attached patch: * improves parsing. We no longer cut solely based on picture startcodes, but use gop/sequence startcodes and sequence endcodes, too. The sequence/gop are for broken streams that don't use sequence endcodes or not even sequence startcodes. The sequence endcode is a valid end-of-picture, and after that, a new sequence will start (which' header should be put in the next buffer, not the current one like happened now). * read timecode from GOP header and use that as timestamp if no PTS is given. * finetunings for (broken, but it happens a lot) streams that start halfway a sequence rather than with a sequence start (mostly streaming MPEG). Please comment. :).
Created attachment 23665 [details] [review] new one
The attached one loops over buffers so that we actually get multiple MPEG blocks out of one buffer instead of only the first (discarding the rest), this fixes green-block-playback. The rest is the same. Seems to work fine for me.
Created attachment 23716 [details] [review] 3
This one fixes small parsing bug (we always write 4 bytes too much) and the resulting potential segfault.
Added to CVS, closing this one.