[FFmpeg-devel] [PATCHv2 8/8] avformat/img2enc: add support for specifying protocol options
Marton Balint
cus at passwd.hu
Thu Jan 9 00:49:55 EET 2020
On Wed, 1 Jan 2020, 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.
Ping for this.
Thanks,
Marton
More information about the ffmpeg-devel
mailing list