[FFmpeg-devel] [PATCH 14/24] fftools/ffmpeg_mux: move bitstream filtering to the muxer thread

[James Almer]

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.