On Dec 29, 2012, at 5:40 PM, Justin Ruggles <justin.rugg...@gmail.com> wrote:
> On 12/29/2012 11:00 AM, Tim W. wrote: >> On Dec 29, 2012, at 3:57 PM, Justin Ruggles <justin.rugg...@gmail.com> wrote: >> >>> On 12/28/2012 08:05 PM, Tim Walker wrote: >>>> --- >>>> libavcodec/mlp_parser.c | 9 +++++++++ >>>> libavcodec/mlpdec.c | 2 ++ >>>> 2 files changed, 11 insertions(+) >>> >>> The point of deprecating request_channels is not to remove the >>> functionality completely, but to replace it with request_channel_layout. >>> So any patch removing request_channels functionality should implement >>> request_channel_layout. It should be pretty straightforward after your >>> other patches right? >>> >>> -Justin >> >> If I'm only required to handle (m->avctx->request_channel_layout == >> s->ch_layout), yes. Which I guess would work for now. >> >> There might be some cases where we'd want to check for something "close >> enough" (e.g. 2.0/5.1/7.1 source, 3.0 requested, we'd probably want to >> decode the 5.1 substream). Not sure how to best handle that. > > The only "close enough" we need to match is when the layouts differ only > in rear vs. side surrounds. If the requested layout doesn't match any of > the substreams I don't think we need to try to guess the closest. The > user can remix on their own in that case. > > -Justin I'll do just == for now. The 'close enough' part can be done later, at which point we could decide whether to have a libavutil channel layout helper rather than implementing it in every decoder. Or do you think I should really go the extra mile in this patch already? Tim _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
