On 09/20/2012 03:28 PM, Luca Barbato wrote: > On 09/20/2012 04:43 PM, Justin Ruggles wrote: >> On 09/20/2012 04:04 AM, Luca Barbato wrote: >>> On 09/20/2012 12:53 AM, Justin Ruggles wrote: >>>> The first 2 frames for TwinVQ are encoder delay. >>>> --- >>>> libavformat/vqf.c | 3 +++ >>>> tests/ref/fate/vqf-demux | 2 +- >>>> 2 files changed, 4 insertions(+), 1 deletions(-) >>> >>> This information might be reported aside. >> >> The VQF changes will give the 2 delay packets negative timestamps. Don't >> know if that's what you mean... > > I'm not sure what's better, having timestamp + offset reported > separately or not.
Yeah I suppose it could be useful to also have it separate, if known. We could use AVCodecContext.delay, which is currently unused for decoding. Decoder delay is not always the same as encoder delay, so this would most likely be set by the decoder. In fact, in the case of TwinVQ, while the encoder delay is 2 frames, I don't even know if the actual decoder delay is 2 frames. For example, AAC has a decoder delay of 1024 samples, but many encoders use a larger encoder delay, which is what is reflected at the container level. -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
