On 5/2/2019 7:42 AM, Moritz Barsnick wrote:
> On Wed, May 01, 2019 at 12:03:41 -0300, James Almer wrote:
>>> + if (pkt->pts != AV_NOPTS_VALUE) {
>>> + int64_t pts = av_rescale_q(pkt->pts, bsf->time_base_in,
>>> AV_TIME_BASE_Q) / ctx->speed;
>>> + int64_t now = av_gettime_relative();
>>> + int64_t sleep = pts - now + ctx->delta;
>>> + if (!ctx->inited) {
>>> + ctx->inited = 1;
>>> + sleep = 0;
>>> + ctx->delta = now - pts;
>>
>> If this is meant to be used for input, where seeking can take place,
>> wouldn't a flush() callback to set ctx->inited and ctx->delta back to 0
>> be needed?
>
> Interesting point. I suppose you mean backward seeking. Is that a valid
> use case for a bitstream filter?
The flush() callback exists to reset the bsf into its initial state
without the need to destroy and recreate the context.
For example, some decoders auto-insert certain bitstream filters that
get applied by the generic lavc code before they are feed packets, like
the vp9 decoder and some hardware based h264/hevc decoders.
avcodec_flush_buffers(), which must be called every time seeking needs
to be done in a decoding scenario, flushes both the decoder and said
bitstream filters.
I don't think we'll ever have a decoder auto inserting this bsf, but we
don't know what an API user might want to do with bitstream filters in
their own scenarios. And if the bsf keeps a state, a flush() callback is
required to reset it.
> Would it also apply to the standard filter, where I took this code from?
There doesn't seem to be any kind of flush mechanism for filters, so i
suppose in those you're expected to uninit and reinit the filter every time?
>
> I don't know, but I can try to add that, if required. Can you tell me
> how to emulate or test seeking from the command line? Would I create a
> file with backward jumps in PTS (and how)?
I guess the simplest way would be to auto insert this bsf into some
decoder (AVCodec.bsfs string), then seek using some libavcodec based
application that doesn't already decodes at realtime.
>
> I also missed to bump libavcodec version, or to at least mention it,
> BTW.
Missing changelog entry and minor version bump, yeah.
>
> Thanks,
> Moritz
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
