[vlc-devel] [PATCH 3/3] swscale: scale the aspect-ratio of the output format
remi at remlab.net
Sun Feb 23 15:44:41 CET 2014
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.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
More information about the vlc-devel