[FFmpeg-devel] update data_offset field in format context

[Michael Niedermayer]

On Thu, Nov 06, 2008 at 04:03:45PM -0800, Baptiste Coudurier wrote:
> 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.

hmm, i think its not defined clearly what pos should point to
The existing code uses pos only for the AVFMT_GENERIC_INDEX code but
this is used only for raw formats, thus also wouldnt be affected by
it one way or another ...

One problem with PS/TS byte seeking is that video packets can be split up
into many muxer packets and muxer packets can contain many video frames.
Thus if pos where pointing to a muxer packets startcode this would lead
to a few unexpected things like that 2 keyframes can have the same
pos and byte seeking to that can return a few non key frames before the
2 key frames ...

The alternative of setting pos to the codec packet would also be usefull
for one case, that is the one of changing the codec headers in a container
agnostic way, like changing the aspect ratio ...
This though would not work reliably with PS/TS though would work with many
other containers.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081107/57188085/attachment.pgp>