[Libav-user] How reliable the file position of a packet is?
nfxjfg at googlemail.com
Wed Feb 11 14:33:29 CET 2015
On Wed, 11 Feb 2015 16:15:10 +0300
Max Vlasov <max.vlasov at gmail.com> wrote:
> 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
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
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).
More information about the Libav-user