On 11/9/2023 8:41 AM, Anton Khirnov wrote:
Quoting James Almer (2023-11-04 14:39:44)
On 11/4/2023 4:56 AM, Anton Khirnov wrote:
This will be the appropriate place for it after the rest of transcoding
is switched to a threaded architecture.
---
fftools/ffmpeg_mux.c | 112 ++++++++++++++++++++++++++-----------------
1 file changed, 67 insertions(+), 45 deletions(-)
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index 82352b7981..57fb8a8413 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -207,6 +207,67 @@ static int sync_queue_process(Muxer *mux, OutputStream
*ost, AVPacket *pkt, int
return 0;
}
+/* apply the output bitstream filters */
+static int mux_packet_filter(Muxer *mux, OutputStream *ost,
+ AVPacket *pkt, int *stream_eof)
+{
+ MuxStream *ms = ms_from_ost(ost);
+ const char *err_msg;
+ int ret = 0;
+
+ if (ms->bsf_ctx) {
+ int bsf_eof = 0;
+
+ if (pkt)
+ av_packet_rescale_ts(pkt, pkt->time_base,
ms->bsf_ctx->time_base_in);
+
+ ret = av_bsf_send_packet(ms->bsf_ctx, pkt);
+ if (ret < 0) {
Unrelated to this patch, but this should probably include a comment
about the reason we're not checking for EAGAIN, like we do for
avcodec_send_packet().
Isn't the situation pretty much the same here - seeing EAGAIN would be a
bug?
Yes, and a similar comment here is a good idea as people may use
ffmpeg.c as a reference implementation for our APIs.
_______________________________________________
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".
