[FFmpeg-devel] update data_offset field in format context

Baptiste Coudurier baptiste.coudurier
Fri Nov 7 01:03:45 CET 2008

Reimar D?ffinger wrote:
> On Thu, Nov 06, 2008 at 06:42:33PM +0100, Michael Niedermayer wrote:
>> On Thu, Nov 06, 2008 at 05:50:46PM +0200, Yoav Steinberg wrote:
>>> Currently the:
>>>          if (pb && !ic->data_offset)
>>>              ic->data_offset = url_ftell(ic->pb);
>>> in the core attempts to use the current position if it wasn't set by the 
>>> demuxer, indicating a "best guess" policy. I was attempting in the patch 
>>> to improve the guessing by employing the index entries table when available.
>> well i didnt write these 2 lines IIRC so i can nt say for sure but not every
>> piece of common code is a "best guess code"
>> one very well could see it the other way around, that its factorized code
>> from demuxers and only executed when its exactly correct.
> To my knowledge the way it is used currently it definitely is not a best
> guess, but actually it is a location in the file that the demuxer will
> be able to demux from if you just seek at the stream layer.
> It may be ugly, but I think some demuxers (mtv.c) rely on this and changing it
> is likely to break seeking.
> Though on looking at it again it seems a bit wrong, going by the
> description it should be set to pkt->pos of the first demuxed packet...

This is interesting, indeed, I was wondering if pkt->pos must be set
refering to the demuxer layer, for example in PS and TS, this would
refer to the position where you can byte seek on, and call av_read_frame
at that position (obviously this is only applicable to containers
supporting byte seeking, like PS/TS), this would mean setting pkt->pos
before the startcode of the packet.

Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no

More information about the ffmpeg-devel mailing list