On Wed, 15 Jan 2020, Marton Balint wrote:
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 <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.
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.
Applied.
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".
