[FFmpeg-devel] [PATCH] avformat/mux: skip parameter and pts checks for data muxer

[Gyan]

On 28-04-2019 03:40 PM, Hendrik Leppkes wrote:
> On Sun, Apr 28, 2019 at 11:57 AM Michael Niedermayer
> <michael at niedermayer.cc> wrote:
>> On Sat, Apr 27, 2019 at 10:01:53AM +0530, Gyan wrote:
>>>
>>> On 27-04-2019 01:32 AM, Michael Niedermayer wrote:
>>>> On Fri, Apr 26, 2019 at 06:38:37PM +0530, Gyan wrote:
>>>>>   mux.c |    9 ++++++++-
>>>>>   1 file changed, 8 insertions(+), 1 deletion(-)
>>>>> d94a699f5dbc31a8ee8b7d1bdb33004d9cd95d46  0001-avformat-mux-skip-parameter-and-pts-checks-for-data-.patch
>>>>>  From 5ec154870d9c559037598b41736bf5b216a756e0 Mon Sep 17 00:00:00 2001
>>>>> From: Gyan Doshi <ffmpeg at gyani.pro>
>>>>> Date: Fri, 26 Apr 2019 18:31:33 +0530
>>>>> Subject: [PATCH] avformat/mux: skip parameter and pts checks for data muxer
>>>>>
>>>>> Allows to dump a malformed stream for external inspection or repair.
>>>>> ---
>>>>>   libavformat/mux.c | 9 ++++++++-
>>>>>   1 file changed, 8 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/libavformat/mux.c b/libavformat/mux.c
>>>>> index 83fe1de78f..3699b572f2 100644
>>>>> --- a/libavformat/mux.c
>>>>> +++ b/libavformat/mux.c
>>>>> @@ -290,6 +290,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>>>>           goto fail;
>>>>>       }
>>>>> +    if (!strcmp(of->name, "data"))
>>>>> +        goto bypass;
>>>>> +
>>>>>       for (i = 0; i < s->nb_streams; i++) {
>>>>>           st  = s->streams[i];
>>>>>           par = st->codecpar;
>>>>> @@ -409,6 +412,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>>>>           av_dict_set(&s->metadata, e->key, NULL, 0);
>>>>>       }
>>>>> +bypass:
>>>> I think this skips a bit more than what would make sense
>>>> (for example priv_data allocation but thats not the only odd thing)
>>>>
>>>> also iam not sure this is the ideal approuch.
>>>> I mean "I want to dump inavlid data in a data muxer for debug"
>>>> that seems a potentially valid request for other muxers too
>>>> like the image muxer producing individual files per frame and
>>>> so on
>>> What would be the ideal approach?
>> I guess the ideal approuch would be to allow the developer who needs
>> this to override the check when the muxer in use can actually saftely
>> mux it without the specific check.
>> There are for example muxers which would not function properly with
>> backward going dts or something like that
>>
> We already have a variety of flags in place, like if a muxer doesn't
> care for timestamps at all, flag it AVFMT_NOTIMESTAMPS, and have code
> that checks timestamps check for this flag. Checks based on muxer
> names seem generally always wrong.
AVFMT_NOTIMESTAMPS is somewhat overloaded. There are formats which don't 
_write_ timestamps but still have some code which looks at them e.g. 
image2 muxer or the mxf family of muxers. Some lavf code like 
compute_muxer_pkt_fields is still run even for formats with the noTS 
flag.  lavf simply ignores errors for formats with the flag set. 
However, if the dumped stream is audio with no  sample rate set, then 
init_pts will fail and so would compute. Hence the selection of muxer by 
name.

Gyan