LibVLC 2.X vs LibVLC 3.x (64 bit versions)

[IngMan84]

Hi all,
I experienced the following regression when I updated VLC from 2.x version to 3.0.4.

Our application is a video grabber which uses LibVLC to open a video stream and to provide the frames grabbed in a shared memory, for their usage in other applications.

The video stream grabbed is described by the following SDP:

Code: Select all

v=0 o=- 37921309 1 IN IP4 192.168.1.1 s=RTSP/RTP stream from IPNC i=h264 t=0 0 a=tool:LIVE555 Streaming Media v2010.01.22 a=recvonly a=type:broadcast m=video 6016 RTP/AVP 96 c=IN IP4 224.1.1.1/255 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=000042;sprop-parameter-sets=h264

About the code: the libvlc_new function is called with the following parameters:

Code: Select all

// Don't use any interface "-I", "wx", // Don't use VLC's config "--ignore-config", / VLC components should not interact with user "--no-interact", // Skip any audio "--no-audio", // Logging "--verbose=1", // The network buffer cache (in milliseconds) "--network-caching=300"

After the libvlc_new function, we call the libvlc_media_new_path function with the SDP file given above, and finally we do:

Code: Select all

mediaPlayer = libvlc_media_player_new_from_media(media); // Setup callbacks libvlc_video_set_format_callbacks(mediaPlayer, setupVideoFormat, // Callback videoCleanup); // Callback // Fake video output interface (shared memory management) libvlc_video_set_callbacks(mediaPlayer, videoLock, // Callback videoUnlock, // Callback nullptr, this);

By means of the setupVideoFormat callback we get the frame width and height, and we force the chroma to RV24, i.e.:

Code: Select all

unsigned int setupVideoFormat(void** opaque, char* chroma, unsigned int* width, unsigned int* height, unsigned int* pitches, unsigned int* lines) { /* Stuff to copy somewhere *width and *height */ if (chroma != nullptr) { // Want to get video frame in RGB 24 bits strcpy(chroma, "RV24"); } if (pitches != nullptr) { *pitches = *width * 3; } if (lines != nullptr) { *lines = *height; } // Successfull callback return 1; }

The other callbacks do not execute something relevant for the question. So, the above code, if executed using LibVLC v.2.2.2, gives a "displaying delay" as desired, around the 300 msecs. The same code, using the same SDP, executed with LibVLC v.3.0.4, provides the video almost 300msecs later than the v.2.2.2 version (i.e. a global delay around 600msecs). Obviously, we are testing the two versions on the same hardware, on the same O.S. (Windows), with the same configuration.

Is there some new parameter in the v.3.0.4 which can help us to obtain the same delay of the v.2.2.2 version?

Thank you for the help in advance!

[Rémi Denis-Courmont]

Use of parameters in libvlc_new() is not supported. Period.

[IngMan84]

Use of parameters in libvlc_new() is not supported. Period.

Thank you for your reply. We know this, however we tried to change the parameters given to the libvlc_new(), and they still works. If we give, for instance, 2 seconds of network-caching, the new buffer length is correctly processed. Therefore, given your absolutely true sentence, I think that it is not helpful for the topic.

[Rémi Denis-Courmont]

Not supported means not supported. It may or may not work, but it's not supposed to work.

There may be plenty of reasons why the performance changed. Maybe your hardware decoding drivers are just noticeably slow to initialize or whatever. If you think there is a bug in VLC, then patch welcome.

[Jean-Baptiste Kempf]

How much slower is it?