[FFmpeg-devel] [PATCH 2/2] avformat/mux: split side data before internal auto BSF

[James Almer]

On 11/4/2016 9:54 PM, Michael Niedermayer wrote:
> On Fri, Nov 04, 2016 at 07:59:48PM -0300, James Almer wrote:
>> On 11/4/2016 3:12 PM, Michael Niedermayer wrote:
>>> On Fri, Nov 04, 2016 at 12:57:39PM -0300, James Almer wrote:
>>>> On 11/4/2016 9:43 AM, Michael Niedermayer wrote:
>>>>> The bitstream filters do not work with merged in side data
>>>>>
>>>>> This leaves the input packet split if it is being split.
>>>>> It could be merged again, if thats preferred ? That would involve
>>>>> an extra malloc and memcpy though
>>>>
>>>> Since side data is being split and merged at a latter point during
>>>> av_interleaved_write_frame() and av_write_frame() calls, maybe we
>>>> could just move the relevant code before the autobsf kicks in.
>>>>
>>>> See attached patch. FATE passes and the sample from ticket 5927
>>>> works with autobsf, same as with your patch.
>>>> It doesn't change ffmpeg.c manual bsf's behavior, though. For that
>>>> your commit from yesterday is still needed.
>>>>
>>>
>>>>  mux.c |   23 ++++++++++++++---------
>>>>  1 file changed, 14 insertions(+), 9 deletions(-)
>>>> e21140de065a58aec07596fb2e16dcdfed45e920  0001-avformat-mux-split-side-data-earlier-in-av_write_fra.patch
>>>> From 44fbcbd855d259126d889e5281e64c8988e57f18 Mon Sep 17 00:00:00 2001
>>>> From: James Almer <jamrial at gmail.com>
>>>> Date: Fri, 4 Nov 2016 12:48:20 -0300
>>>> Subject: [PATCH] avformat/mux: split side data earlier in av_write_frame and
>>>>  av_interleaved_write_frame
>>>>
>>>> Similarly, merge it back before returning.
>>>>
>>>> This fixes ticket #5927.
>>>>
>>>> Signed-off-by: James Almer <jamrial at gmail.com>
>>>> ---
>>>>  libavformat/mux.c | 23 ++++++++++++++---------
>>>>  1 file changed, 14 insertions(+), 9 deletions(-)
>>>
>>> should be ok i think
>>>
>>> [...]
>>>
>>> thx
>>
>> Looking at it again, it seems correct for av_write_frame() but not for
>> av_interleaved_write_frame(), where side data is being merged right before
>> the packet gets unref'd.
>> I'm going to revert my commit and apply your patch instead. Even if i try
>> to fix my commit, it's more complexity for no apparent gain i think.
>>
>> Any objections?
> 
> no objections

Done.

Thanks, and sorry for the noise.