[vlc-devel] [PATCH 3/3] swscale: scale the aspect-ratio of the output format

[Rémi Denis-Courmont]

Le samedi 22 février 2014, 16:26:24 Felix Abecassis a écrit :
> 2014-02-22 15:37 GMT+01:00 Rémi Denis-Courmont <remi at remlab.net>:
> > Well, it's good but it's not great. The transform filter should follow the
> > same padding rules as the VLC core with regards to the scan line pitch.
> > 1090 is a really bad choice; it is not even a multiple of 4, forget 16 or
> > 32.
> Well, this is different, when allocating the picture we use another
> pitch. In this case, picture->p[0].i_pitch is 1120, a multiple of 32.
> We have two levels of padding, it's quite confusing I think.
> 
> > Well ideally the filter chain would be created *before* the video output,
> > so that we create artificial format mismatches like that. But OK, patch
> > 1/3 is probably fine for the time being.
> 
> Yes, we should aim for something like that in the future. Adding a
> swscale filter in this case is terribly inefficient.
> 
> > Well I don't really care about patch 2/3. But patch 3/3 looks very wrong
> > to
> > me.
> 
> It's wrong because it's modifying the output format? Why isn't that safe?

By convention, conversion filters accept the format if they can do the 
conversion and otherwise fail. Post-processing filters can modify their input 
and output formats as they see fit. It really boils down to the assumptions 
made by the different call sites: whether they take the conversion for granted, 
or can add further conversion filters if the output format is modified.

Then again, there is b_allow_fmt_out_change, which I am not sure is properly 
intiailized in all cases.

That is clear for audio filtering, as the capabilities are different. For video 
filtering, this remains a mess (confusing developers and users alike). In 
principles, conversion fitlers have a non-zero priority, and post-processing 
filters have a zero priority.

> As I said it was done this way before, but hidden in the function call
> video_format_ScaleCropAr.

-- 
Реми Денис-Курмон
http://www.remlab.net/