[vlc-devel] [PATCH] When the demuxer sets dimensions use them rather than the codec values

[Steve Lhomme]

On Thu, Mar 5, 2015 at 4:57 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 2015-03-05 18:43, Steve Lhomme a écrit :
>>
>> On Thu, Mar 5, 2015 at 4:39 PM, Rémi Denis-Courmont <remi at remlab.net>
>> wrote:
>>>
>>> Le 2015-03-05 18:33, Steve Lhomme a écrit :
>>>>
>>>>
>>>> You mean the i_width/i_height rewriting ?
>>>
>>>
>>>
>>> Mainly but not only. If the input and output resolutions differ, then the
>>> mapping of input and output coordinates is not known. So the decoder core
>>> cannot apply the demuxer crop. Only the decoder module can do the
>>> mapping.
>>
>>
>>
>> Hence my idea to carry over the extra dimension/cropping data over to
>> the next stage, which is currently the vout.
>
>
> That would have the exact same problem. And zero benefits.


Your first assumption is false. I don't know about MP4 but in Matroska
the coordinate mapping is defined. It applies to the output format of
the codec. It doesn't have/need/should know about the internals of any
codec, what matters is what it outputs, in this case 1280x720. And
that's where the cropping happens.

By the way, although from the code it looks like most (windows)
video_output module doesn't deal (well) with cropping, the patch I
sent with a dual video_format_t passed to the vout actually works with
most of them (except for Direct2D). The patch uses the same "crop
path" as when the user selects manually the crop. Some of them even
work when changing the manual crop afterwards, some don't.

At the very least, I should be able to make top/left crop work when
manual crop works. It's similar to applying a 4:3 or 1:1 from the UI.
There should be no bleeding there.