Quoting Nicolas George (2023-11-09 11:47:23)
> Anton Khirnov (12023-11-09):
> > The problem with that code (and the reason this patch exists), is that
> > it depends on the order in which the frames arrive on filtergraph
> > inputs, which is not meaningful (and becomes non-deterministic with
> > threading).
>
> I can understand that. We will have to find a solution, won't we? (I
> hope you do not consider removing a feature that people have been using
> for years an option.)
I am obviously not proposing that, given the amount of patches I sent so
far to keep sub2video working.
> I can suggest this: have demuxer code emit virtual subtitles packets to
> trigger the sending of the heartbeat frames.
That's what already happens, unless I misunderstand what you mean.
Another possibility is to make the call independently of the state of
the graph, like this
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -2274,8 +2274,7 @@ void ifilter_sub2video_heartbeat(InputFilter *ifilter,
int64_t pts, AVRational t
or if we need to initialize the system, update the
overlayed subpicture and its start/end times */
sub2video_update(ifp, pts2 + 1, NULL);
-
- if (av_buffersrc_get_nb_failed_requests(ifp->filter))
+ else
sub2video_push_ref(ifp, pts2);
}
This actually seems to improve filter-overlay-dvdsub-2397, where
the first subtitle appears two frames later, which more closely matches
the subtitles timestamp stored in the file.
--
Anton Khirnov
_______________________________________________
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".
