[FFmpeg-devel] [PATCHv2 8/8] avformat/img2enc: add support for specifying protocol options

[Marton Balint]

On Thu, 9 Jan 2020, Michael Niedermayer wrote:

> On Wed, Jan 01, 2020 at 08:10:06PM +0100, Marton Balint wrote:
>>
>>
>> On Tue, 31 Dec 2019, Michael Niedermayer wrote:
>>
>>> On Tue, Dec 31, 2019 at 12:37:02PM +0100, Nicolas George wrote:
>>>> Marton Balint (12019-12-28):
>>>>> v2: simplified example
>>>>>
>>>>> Signed-off-by: Marton Balint <cus at passwd.hu>
>>>>> ---
>>>>> doc/muxers.texi       | 11 +++++++++++
>>>>> libavformat/img2enc.c | 13 ++++++++++++-
>>>>> 2 files changed, 23 insertions(+), 1 deletion(-)
>>>>
>>>> image2 is not the only demuxer that opens new streams. I think a generic
>>>> solution would be preferable.
>>>
>>> i also had a slightly ungood feeling about the patch but didnt
>>> had time to think more about it. a more generic solution like with
>>> child AVClasses or something would be interresting but as said i didnt
>>> had time to think about this ...
>>
>> It looks like a big can of worms.
>>
>> In the AVFMT_NOFILE case there is no IO context, so options can only be
>> passed using avformat_write_header/avformat_init_output.
>>
>> There is no way to determine which options the protocols will use without
>> actually opening an IO context (protocol options are passed to the url_open
>> method of each protocol), so we have to store all remaining options passed
>> to avformat_write_header/avformat_init_output for possible nested IO use.
>>
>> In the normal case (non AVFMT_NOFILE) muxers can use nested contexts too, so
>> avio_open should also store the original options, all of them, because the
>> nested contexts might use different protocols. This alone is problematic,
>> because avio_open should return the unrecognized options...
>>
>> Also it might make sense to specify different IO options for nested contexts
>> than main contexts (or different options for some of the nested contexts)
>>
>> IMHO being able to specify the nested options separately is a clean
>> solution, admittedly less user friendly, but I don't see how this can work
>> automagically without some major redesign.
>
> ok, yes i agree it would need a too major redesign.

Ok, I will apply in a few days if I receive no further comments.

Thanks,
Marton