--width and --height not working in numerous vout (mostly Windows)

added Component::Video: Direct3D / Win32 label

It used to work in previous versions, but stopped working (I don't know exactly in which version it stopped working). I now use the 2.1.2 version and it does not work in it. The command I use is this:

"C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" --qt-minimal-view --width=400 --height=300 --autoscale --canvas-width=400 --canvas-height=300 --canvas-padd dshow:// :dshow-vdev= :dshow-adev= :live-caching=300

I think that I inserted the "--canvas-*" options trying to figure out a solution, but it didn't work either.

I hope someone can look at this bug soon because I think it would not be difficult to solve.

Resnak, do you know which version you were using before upgrading to 2.1.1?

Original author: itamar c

I'm not entirely sure which version I was using but since reporting this bug I have reverted to 2.0.8 and these settings work properly.

I've investigated the issue and it also happens on Linux. The display is initialized with the correct dimensions (DisplayNew in src/video_output/display.c) but they are quickly overwritten by two events:

Function vout_IntfReinit (called by vout_IntfInit when creating the vout), triggers the aspect ratio callback with ratio 0:0. When receiving the event in vout_SetDisplayAspect, the display will signal the AR changed because we received 0:0 instead of 1:1. We can easily discard events that will have no effect (such as 10:10 instead of 1:1) by calling vlc_ureduce and assuming SAR 1:1 if 0:0 is provided.
Similarly, vout_IntfReinit triggers the zoom callback and a 1000:1000 zoom event is sent to the vout display (vout_SetDisplayZoom). The previous zoom was 1:1 and with vlc_ureduce we can detect the ratio is the same, but this time we cannot prevent the zoom event from being triggered since it should also be triggered if we are in "display_filled" mode (i.e. autoscaling, key "o"):

 if (osys->is_display_filled ||                       
     osys->zoom.num != num || osys->zoom.den != den)
}}} 
We need the first expression in the test for the following use case: with autoscaling, if we press alt-2, resize the window with the mouse and press alt-2 again, we should go back to the window state after the first alt-2 even if the zoom ratio hasn't changed.

Because of this zoom event, I haven't found a way yet to prevent this event from discarding the initial resize specified on the command line. The question now is: why do we need to trigger the callbacks in vout_IntfInit? It seems redundant with the initialization in VoutGetDisplayCfg.

Any update on this ticket? Can I be added to the CC list?

Also #10883 (closed), #11057 (closed)

added Component::Core: Video output + 1 deleted label and removed Component::Video: Direct3D / Win32 label

Also #9543 (closed).

assigned to @Courmisch

changed milestone to %3.0 FF

If this is still relevant: the last known working version is [#9931 (closed)#comment:3 2.0.8], the first known broken version is 2.1.0. I went to download 2.0.9, but apparently there's no Windows release of it so I couldn't check.

This is still not working - testing the nightly build vlc-3.0.0-20150429-0402 on windows. Neither of these appear to do anything at all: --width, --height, --video-x, --video--y

Except video-x and y seem to work when using --no-embedded-video although of course this isn't ideal or usable to most people.

changed milestone to %4.0

changed title from --width and --height not working in 2.1.1 Windows CLI to --width and --height not working in numerous vout (mostly Windows)

This should be checked in most video outputs.

Is there any news about this bug?

I would also like to know if there is an update on this. I like to use scripts to arrange my playback windows and this bug has me stuck on VLC 2.0.8. Would love to see this get fixed.

The spurious callbacks in vout_IntfIntf will be removed eventually very soon. That will restore width and height settings.

There are however no agreements on what should happen if the user interactively changes the window size during playback. Some people expect the CLI settings to be forced at every change, but this is ugly and somewhat arbitrary. Some people expect the window to remain as it is, because it looks nicer.

The source aspect ratio changes are also a case of contention, unless both width and height are forced: should the non-forced dimension be automatically adjusted, or should there be black bars?

tl;dr: #6181 (closed) (and its many duplicates) are likely to come back at least to some extent.

There are no ways to please everyone, when different people have contradictory expectations. All expectations are individually reasonable, but they seem to add up to a inconsistent set when combined.

(The good news is that "scale" is gone, so that is one fewer variable to worry about.)

added Status::fixed label

closed

Why is this bug marked FIXED ????

I was trying to find why --width=640 --height=400 did not work and after an hour I found this 7 years old bug that is not fixed.

At least you should mark clearly in the documentation that it is broken for me as a user it'S something that I would have expected to be done at some point especially after 7 years.

mentioned in issue #18665 (closed)

Did anyone find a solution / workaround for this bug?

@PhilippHeuer

Initially I stuck with the old version that still worked (2.0.8). Seeing as this will probably never be fixed, I've since switched to mpv and couldn't be happier. Takes a little getting used to at first, but it's very flexible/customizable. There are a few options in mpv you can use depending on the desired behaviour; I use --autofit=640x360 which preserves aspect ratio.

https://mpv.io/
https://mpv.io/manual/master/#options-autofit

@Courmisch (or someone else on the dev team), this issue is still present as of version 3.0.16 (Win x64 build). Any way we can re-open this issue and get an update on it?

A bug fixed in 4.0 is still present in 3.0.16. What is your point ?

...

-- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.

@Courmisch Thatʼs right, be rude to the community members. About a bug that persists after 7 years. Like theyʼre being too impatient or something. I ran into this bug right now, and googling it brought me down this rabbit hole, and the final say on the matter is your snark, which is not helpful at all.

Perhaps English isnʼt your first language, but @jpickerell is asking the issue to be reopened so it can actually be fixed. That is his point, and I second that motion.

Smooth move, Exlax.

You are insulting the person that spent their free time actually fixing the issue, that is to say me.

The code of conduct forbids me from expressing my contempt, @briantw . If you can't understand what it means that a bug fixed in 4.0, you should abstain from despicably trolling the open-source community.

@briantw please behave and mind your tone.

The bug is fixed in 4.0, as it is mentioned on the sidebar Milestone field. So it is normal for this bug to be closed.

@Courmisch,

I do truly appreciate you volunteering of your time on the VLC Media Player project. Without folks such as yourself, VLC wouldn't be what it is today. No disrespect meant to you at all!

Since we're not sure when 4.0 is going to be released (and feel free to correct me, as I haven't looked into this for a few months), is there any chance the fix you made, that is in the future 4.0 code, could be backported into the 3.x codebase?

No.

Could it be fixed in documentation? Since this feature does not work in the current version and will never work it seems reasonable for me to mention it in the documentation.

Define "the documentation"... Where did you expect to read this?

Here, in "Window properties:" section https://wiki.videolan.org/VLC_command-line_help/ I would do it myself, but I can't see registration options.

--width and --height not working in numerous vout (mostly Windows)

Child items 0

Activity