[vlc-devel] Getting the size of a video

[yann LE HIR]

2011/11/30 Rémi Denis-Courmont <remi at remlab.net>:
>        Hello,
>
> Le mercredi 30 novembre 2011 15:58:52 yann LE HIR, vous avez écrit :
>> libvlc_media_get_tracks_info() works fine on files but sometimes gives
>> bad data with streams (TS streams with mpeg2 video in that case).
>> However, X11 video_output module get the good size when creating the
>> window.
>
> Sure. The video output gets the picture format so that it can setup picture
> buffers correctly.
>
>> My software embed a vlc_media_player in a GTK Window (with
>> set_xwindow()). And I would like to resize the widget that displays
>> VLC when I load a file.
>
> Such a design is intrinsically broken. Some media can have multiple video
> tracks of different resolutions, simultaneously or consecutively.
>
> Even if you ignore those corner cases, there will be picture resize glitches.

Anyway, I find odd that there is no method to get the size of the
native video resolution.

>
> If you want the to set windows dimensions according to the native video
> resolution, you need to create a dedicated window provider plug-in. Only then
> you can get the correct dimension all the time, and create/resize the window
> before the pipeline starts displaying pictures.

I was afraid you'd say that.
I was trying to avoid the pain of reading/understanding all of the
video_output process, but I guess this is not an option.

>> The video_output module used in that case is xvideo, that
>> automatically resize the vlc window to the size of the xwindow given
>> and replace the size values in the config of the video output thread.
>
> The X11 plugins (XVideo, GLX, X11 and GL/EGL) all request a window of the
> correct size. They don't actually resize the window. That is the
> responsibility of the window provider.
>
>> I managed to make it work, but I had to modify the way the xvideo
>> module works, and to hack around in libvlc_video_get_size() to access
>> the private part of video output thread.
>
> You cannot do that. Besides breaking the encapsulation principle, this patch
> violates the threading model surrounding the video output thread. In other
> words, sooner or later, it will crash the process or return corrupt values.

Anyway,
thank you for your time.