What I really need is a way to pass options to avio_open2. Note that this is already done internally by avformat_open_input, so can already be done for input-containers, but I need a way to do it for output as well.
I can see a few different ways to achieve that;
Pass self.container_options. That somehow seems wrong. avio_open2 does not really deal with containers at all, just the underlying I/O-protocols.
Pass self.options to avio_open2. This would create different API:s where container_options reaches avio_open2 for InputContainer, but not for OutputContainer.
Pass self.options | self.container_options. Same problem as first, and unclear to me why we even have different option-structs if always we end up passing the union regardless?
Pass self.protocol_options alone to avio_open2. This would work, but again create an inconsistent API between InputContainer and OutputContainer where both would support practically the same arguments, but apply them differently.
At this point, I assume the reason we're passing self.options | self.container_options for InputContainer is basic case of backwards compatibility, while enabling/encouraging applications to start passing options separately? I'm guessing we'll at some point want to break that, but make it possible for applications to be rewritten first? (Otherwise, I've misunderstood the intention with container_options.)
Given the above assumption what this PR is trying to do is; Add separate options for the 3d layer of the stack (Codecs, Containers, I/O Protocols), while not breaking backwards compatibility, and ensuring that the API remains consistent across InputContainer and OutputContainer.
Given that avformat_open_input already have passed self.options | self.container_options to avio_open2, we must keep doing that, or risk breaking stuff.
Given that we want to start separating protocol_options, we now allow applications to pass it in separately, and can (at some later point) deprecate it being passed to the "wrong" layer.
On the flip-side; if we don't want to enable applications to pass protocol-options separately and explicitly, why do we want it for container-options?
WyattBlue
commented
3 months ago
Originally posted by @rawler in https://github.com/PyAV-Org/PyAV/issues/704#issuecomment-1320310595
What I really need is a way to pass options to
avio_open2. Note that this is already done internally byavformat_open_input, so can already be done for input-containers, but I need a way to do it for output as well.I can see a few different ways to achieve that;
self.container_options. That somehow seems wrong.avio_open2does not really deal with containers at all, just the underlying I/O-protocols.self.optionstoavio_open2. This would create different API:s wherecontainer_optionsreachesavio_open2for InputContainer, but not for OutputContainer.self.options | self.container_options. Same problem as first, and unclear to me why we even have different option-structs if always we end up passing the union regardless?self.protocol_optionsalone toavio_open2. This would work, but again create an inconsistent API betweenInputContainerandOutputContainerwhere both would support practically the same arguments, but apply them differently.At this point, I assume the reason we're passing
self.options | self.container_optionsforInputContaineris basic case of backwards compatibility, while enabling/encouraging applications to start passing options separately? I'm guessing we'll at some point want to break that, but make it possible for applications to be rewritten first? (Otherwise, I've misunderstood the intention withcontainer_options.)Given the above assumption what this PR is trying to do is; Add separate options for the 3d layer of the stack (Codecs, Containers, I/O Protocols), while not breaking backwards compatibility, and ensuring that the API remains consistent across
InputContainerandOutputContainer.avformat_open_inputalready have passedself.options | self.container_optionstoavio_open2, we must keep doing that, or risk breaking stuff.protocol_options, we now allow applications to pass it in separately, and can (at some later point) deprecate it being passed to the "wrong" layer.On the flip-side; if we don't want to enable applications to pass protocol-options separately and explicitly, why do we want it for container-options?