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 <c...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to