Quoting Michael Niedermayer (2023-03-15 00:00:06) > On Sat, Mar 11, 2023 at 11:54:52AM +0100, Anton Khirnov wrote: > > These fields are supposed to store information about the packet the > > frame was decoded from, specifically the byte offset it was stored at > > and its size. > > > > However, > > - the fields are highly ad-hoc - there is no strong reason why > > specifically those (and not any other) packet properties should have a > > dedicated field in AVFrame; unlike e.g. the timestamps, there is no > > fundamental link between coded packet offset/size and decoded frames > > - they only make sense for frames produced by decoding demuxed packets, > > and even then it is not always the case that the encoded data was > > stored in the file as a contiguous sequence of bytes (in order for pos > > to be well-defined) > > > - pkt_pos was added without much explanation, apparently to allow > > passthrough of this information through lavfi in order to handle byte > > seeking in ffplay. That is now implemented using arbitrary user data > > passthrough in AVFrame.opaque_ref. > > One intended use i remember was that errors are detected after decoding, > be that bitstream, metadata, aspect ratio, yuv type, ... > while the location of the error is in the source file around the packets > position. pkt_pos allows one to patch errors in the source file without > remuxing
That is still possible, as shown in patches 2 and 4. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
