On 09/20/2012 06:28 PM, Justin Ruggles wrote: > 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.
We can use avctx->delay for this now. But it shouldn't be done in the demuxer. I will update the twinvq decoder patch to make use of this. Is this patch ok then? -Justin _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
