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.