[vlc-devel] [PATCH] provide the display format from the demuxer to the vout to respect cropping

[Steve Lhomme]

On Mon, Mar 9, 2015 at 6:49 PM, Jean-Baptiste Kempf <jb at videolan.org> wrote:
> On 09 Mar, Steve Lhomme wrote :
>> On Mon, Mar 9, 2015 at 6:32 PM, Jean-Baptiste Kempf <jb at videolan.org> wrote:
>> > On 09 Mar, Steve Lhomme wrote :
>> >> And I explained each time why there is information missing at the vout
>> >> level.
>> >
>> > Can't we forward the info from the demux fmt to the codec step, and use
>> > those values, if the codec does not override them (aka, i_x, i_y = 0 ) ?
>>
>> First of all, this is codec specific. Does libvpx support it ? libmpeg
>> ? libjpeg ? Do they support offsets by 1 pixel or do they have to be
>> rounded ? Does it disable hardware acceleration and/or implies some
>> swscale down the data path ?
>
> I speak about visible_width, I don't see what the issue for any codec to
> support any value.

No, that's the first think I tried. If that's the one you're talking about
http://git.videolan.org/?p=vlc.git;a=blob;f=src/input/decoder.c;hb=HEAD#l2050

It creates green(ish) areas. That's when I started looking at what the
codec feeds the vout to see why it fails. I couldn't find a way around
this without providing more info to the vout. If the decoder can be
made responsible to crop some pixels by itself, that could be one way
to do it. But it's probably going to be an exception more than the
rule.

I think that's what courmisch meant when saying top-left cropping is
not well handled.

>> And what if the codec already overrides the display dimensions (which
>> is the case in #13982) ? Is it going to handle its own internal
>> preference or the one we try to force it to ?
>
> Well, we need to decide, but muxer > codec or the other way around.
>
>> That's a lot of uncertainty IMO. I don't know all the code enough. But
>> on the other hand I provide something that will work regardless of the
>> codec and vout used, for any size. Apart from Direct2D, all vout seem
>> to handle cropping properly and internally (no swscale).
>
> Direct2D, you can consider it dropped.
> Especially with the new Direct3D11 output, that should be valid for
> WinRT and Windows 10+

I vote for dropping it.