[Libav-user] How reliable the file position of a packet is?

[wm4]

On Wed, 11 Feb 2015 16:15:10 +0300
Max Vlasov <max.vlasov at gmail.com> wrote:

> Hi,
> 
> Probably due to a urge to experiement, I implemented several ways of
> locating an existing packet in a saved index. Probably most straightforward
> is pts-based, but I tried also using file position.

Yeah, doing this based on pts can lead to problems with formats that
have pts resets, or no pts at all.

> Unfortunately I noticed at least two occasions when this didn't work:
> -  for mpg/ts files this position usually change after seek, so the same
> packet may contain a different file position when visited second time after
> seek

I don't know mpegts demuxer enough to know why this happens. Maybe it
has something to do with packet parsing ("reassembling" the ts packets
to packets expected by the decoders).

> - For mkv files two different packets may represent the same file position.

Matroska sometimes stores multiple sub-packets in one Matroska-level
packet (usually happens with audio). The demuxer separates these, but
returns the file position of the Matroska-level packet for each
sub-packet.

I don't know if this is a bug or a feature. Probably could be
considered a bug, since knowing the Matroska-level packet position is
not overly useful.

> So should I forget about this field whatsoever? But If the field exists,
> but might be so unreliable, does it exist only for the demuxer own needs?

There's definitely a lot potential for breakage. I'd special-case for
each format (whichever is the best method).