[FFmpeg-devel] base av_read_frame() function for seeking in mpegps files
Tue Jul 28 04:07:35 CEST 2009
2009/7/27 Ivan Schreter <schreter at gmx.net>
> zhentan feng wrote:
>> I am not clear why the parser return the wrong frame size when fist call
>> av_read_frame() after seek.
>> anyone explain it futher?
> I looked at the code. Consider following example: A PES packet contains
> some rest of previous frame and start of a new frame. In normal case, the
> rest of the previous frame is simply glued to the data in the buffer and
> returned as whole frame with PTS of the previous frame during processing of
> this PES packet in the parser.
> However, after a seek, parser is reset. Instead of ignoring the portion of
> previous frame, it returns it back as a frame with PTS of the current frame.
> Beginning of current frame (to which PTS actually belongs) is put into the
> buffer and when the frame is completed, it is returned back without PTS.
> So, we have one corrupted frame with the timestamp of the actual frame
> before actual frame (most probably of correct size, but I didn't check),
> which is returned without timestamp.
> Code in mpegvideo_parser.c and possibly in ff_combine_frame() must be fixed
> to take this case into account (i.e., newly-initialized parser and rest of
> old frame in the first packet received from the stream).
yes, I also meet the same problem with you. if parser is not reset after
seeking, everything run perfectly.
I also debug the code with the sample file
http://samples.mplayerhq.hu/MPEG2/dothac2.mpg for test the mpegps seek.
the sample file has 3 streams, stream_id == 0 is mpegvideo, stream_id ==1 ,2
are ac3 audio formats.
Maybe I didn't test stream_id == 0 extensively, I get correct frame size
unfortunately, when stream_id ==1 or 2, ff_aac_ac3_parser() return the
for example, as to the target timestamp:
ret: 0 st: 1 ts:231900 flags:0
the output should be :
ret: 0 st: 1 dts:129534 pts:129534 pos:1327118 size:1536 flags:1
but it is:
ret: 0 st: 1 dts:129534 pts:129534 pos:1327118 size:867 flags:1
different size returned, and this only happened on first call
av_read_frame() after seeking.
maybe audio parser also has the same problem with mpegvideo?
More information about the ffmpeg-devel