On Fri, Feb 22, 2019 at 9:56 PM Jan Ekström <jee...@gmail.com> wrote:
>
> This seems to fix use cases where the sub2video output is the only
> input to a filter chain.
>
> Additionally, this is the value to which the structure's values
> would implicitly get initialized to. The ballooning buffering case
> would not get hit by this as the value of end_pts after
> (re-)initialization would be less than INT64_MAX, thus hitting the
> sub2video AVFrame initialization logic via sub2video_update in
> sub2video_heartbeat.
> ---
> fftools/ffmpeg_filter.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 72838de1e2..536f9c9c46 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -739,7 +739,7 @@ static int sub2video_prepare(InputStream *ist,
> InputFilter *ifilter)
> if (!ist->sub2video.frame)
> return AVERROR(ENOMEM);
> ist->sub2video.last_pts = INT64_MIN;
> - ist->sub2video.end_pts = INT64_MIN;
> + ist->sub2video.end_pts = 0;
> return 0;
> }
>
> --
> 2.20.1
>
An alternative for this would be to:
1. add a flag to sub2video structure that timestamp initialization is
required, and set it as required during (re-)initializations.
2. pass heartbeat pts to sub2video_update
3. finally, in sub2video_update
} else {
pts = !ist->sub2video.timestamp_initialized ?
heartbeat_pts : ist->sub2video.end_pts;
end_pts = INT64_MAX;
num_rects = 0;
}
and ist->sub2video.timestamp_initialized = 1; at the end.
This way the sub2video logic would start with the first heartbeat's
timestamp (often zero, but not always), as opposed to the initial
value of end_pts.
Jan
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
