[FFmpeg-devel] [PATCH] ffmpeg: add -map_channel option.

[Michael Niedermayer]

On Tue, Oct 25, 2011 at 06:30:16PM +0200, Clément Bœsch wrote:
> On Tue, Oct 25, 2011 at 05:10:26PM +0200, Michael Niedermayer wrote:
> > On Tue, Oct 25, 2011 at 04:29:28PM +0200, Clément Bœsch wrote:
> > > On Tue, Oct 25, 2011 at 03:28:36PM +0200, Clément Bœsch wrote:
> > > > On Tue, Oct 25, 2011 at 03:22:12PM +0200, Clément Bœsch wrote:
> > > > > On Tue, Oct 25, 2011 at 02:25:53PM +0200, Michael Niedermayer wrote:
> > > > > > On Tue, Oct 25, 2011 at 11:07:53AM +0200, Clément Bœsch wrote:
> > > > > > > On Mon, Oct 24, 2011 at 06:29:10PM +0200, Michael Niedermayer wrote:
> > > > > > > > On Mon, Oct 24, 2011 at 04:19:10PM +0200, Michael Niedermayer wrote:
> > > > > > > > > On Mon, Oct 24, 2011 at 02:05:55PM +0200, Clément Bœsch wrote:
> > > > > > > > > > On Wed, Oct 19, 2011 at 11:42:15PM +0200, Michael Niedermayer wrote:
> > > > > > > [...]
> > > > > > > > > > > also shouldnt rematrix be independant of the existence of a channel_map
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Well, AFAIU, the rematrix is meant to automatically set the audio gain
> > > > > > > > > > levels for each channel; the channel mapping is "incompatible" with this,
> > > > > > > > > > it's all about reordering, or maybe with another phrasing: ppl won't
> > > > > > > > > > expect the levels to change (the number of output channels being fixed by
> > > > > > > > > > the number of -map_channel and not a specific -ac option)
> > > > > > > > > 
> > > > > > > > > if your inputs represents 5.1 and your output represenst 7.0 you need
> > > > > > > > > the rematrix code
> > > > > > > > 
> > > > > > > > a better and simpler example is stereo input and mono output
> > > > > > > > 
> > > > > > > 
> > > > > > > In case of stereo → mono with map_channel, you're likely to have something
> > > > > > > like:
> > > > > > >     ffmpeg -i stereo.wav -map_channel 0.0.0 left.wav -map_channel 0.0.1 right.wav
> > > > > > 
> > > > > > i meant that we have 2 input files, one with right and one with
> > > > > > left chanel and want one mono output file.
> > > > > > 
> > > > > 
> > > > > Picking from multiple input files is unfortunately not supported ATM
> > > > > because each output stream is limited to one input stream. Do you see any
> > > > > other use case for rematrix?
> > > > > 
> > > > 
> > > > Mmh forget this, we might workaround this with the -map.
> > > > 
> > > 
> > > It won't be possible to adapt ffmpeg to this easily AFAIU, so patch
> > > re-attached adding the mention of the limitation in the documentation.
> > > 
> > > The patch is also rebased on master dropping temporarily the two resample
> > > flag patches (which might need some rework according to the other thread).
> > > 
> > > So to sum up, each output stream only has a single associated stream
> > > (source_index field), so you can't have an output stream based on multiple
> > > inputs given the current design. Using filters might be a solution, but
> > > IMHO it does not belong to the scope of this feature.
> > > 
> > > Any other suggestion welcome,
> > [...]
> > > @@ -176,7 +177,7 @@ int swr_init(SwrContext *s){
> > >      if(!s->out_ch_layout)
> > >          s->out_ch_layout= av_get_default_channel_layout(s->out.ch_count);
> > >  
> > > -    s->rematrix= s->out_ch_layout  !=s->in_ch_layout;
> > > +    s->rematrix= s->out_ch_layout != s->in_ch_layout && !s->channel_map;
> > 
> > iam still thinking this is problematic
> > consider a 5.1 input that has its channels in wrong order and the
> > user wanting stereo output, this would require remaping channels and
> > rematrixing and it would be just 1 stream->1 stream
> > 
> 
> You can't ATM mix -ac with -map_channel; the number of -map_channel
> options is used to set the channel layout. If you want to reorder and then
> downmix you actually have to do it in two rows.
> 
> Assuming the code is changed to set the channel layout using -ac if
> specified (not much trouble to deal with), another issue comes out: how do
> you make a distinction between:
> 
>   ffmepg -i INPUT_5.1 -map_channel 0.0.0 -map_channel 0.0.1 output
> 
> and:
> 
>   ffmepg -i INPUT_5.1 -map_channel 0.0.0 -map_channel 0.0.1 -ac 6 output
> 
> The first case must *not* rematrix, it's all about filtering (and
> eventually reorder) channels. Now what would be the heuristic to say we
> need to have the rematrix in the second case? I guess having "-ac" set and
> at least one -map_channel option might be one, and in that case a "force
> rematrix" flag need to be transmitted to libswr. This will enlarge the
> current patch and might introduce more issues than expected.
> 
> So as already stated, ATM -ac is ignored with -map_channel (yes, another
> limitation), but this can be changed later.
> 

> Do you think adding this rematrix feature in the initial patch is really
> worth?

I think rematrix should not be forced to be disabled in swr based on
reordering. Iam not
asking for it to be possible to be used from ffmpeg.c with reorder
initially.

Rather the API for the reordering in swr should be flexible enough to
allow both to be specified in an unambigous way. So that rematrix is
disabled when the layouts match.
Maybe there could be
input number of channels, a remaped number of channels and layout
and a output number of channels and layout.
when the layouts match no rematrix would be needed otherwise it would
be needed.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20111025/fb028c73/attachment.asc>