OpenFileMapping crashes vlc

[Belbear]

I'm trying to use the (native) Windows API function OpenFileMapping to map a shared memory block between a clx video output plugin (which will write into the memory) and another Windows process that lalls CreateFileMapping.

This works fine with a "vlc-emulator" proggy I compiled to test it out, but when I try it in the vlc plugin the call to OpenFileMapping crashes vlc in a way that leaves no traces. vlc just quits, no error messages, no console output, and the "messages" window that could give me a clue also disappears instantly.
If I skip the OpenFileMapping call, vlc runs normally (except for the error that occurs because there is no video buffer)

This is the code I use, it is called in the "Open" callback of my video output plugin:

Code: Select all

char szName[40]; sprintf(szName,"Global\\BlueMotionVlcHdr0"); HANDLE hdl = OpenFileMapping( FILE_MAP_ALL_ACCESS, // read/write access FALSE, // do not inherit the name szName); // name of mapping object

It compiles and links without even a warning.

I found no references to this function in the vlc code, except for an OpenFileMappingA function in the win32.c, but these functions only seem to emulate the real thing, so it won't work with another WIndows process on the other side.

[MichaelMc]

Is it your aim to use this IPC method in an output plugin to access the video data from an external process?

[Belbear]

Is it your aim to use this IPC method in an output plugin to access the video data from an external process?

Hi Michael!

My aim is that an external process receives video from vlc to display it. This process allocates the memory and determines the maximum buffer size. Buffer size must be possible up to 3x 1920x1080x32bpp, (around 24MB) for triple buffering. Frame rates up to 50fps (for 1280x720) or 25fps for 1920x1080.

If you know a better way to share memory between processes, i'd be glad to know. (Windows only)
I assume it won't work to just pass a pointer and buffer size to vlc using the libvlc interface?

[MichaelMc]

Is it your aim to use this IPC method in an output plugin to access the video data from an external process?

Hi Michael!

My aim is that an external process receives video from vlc to display it. This process allocates the memory and determines the maximum buffer size. Buffer size must be possible up to 3x 1920x1080x32bpp, (around 24MB) for triple buffering. Frame rates up to 50fps (for 1280x720) or 25fps for 1920x1080.

If you know a better way to share memory between processes, i'd be glad to know. (Windows only)
I assume it won't work to just pass a pointer and buffer size to vlc using the libvlc interface?

Hi Belbear,
I wrote a plugin using this very method but for much smaller external displays, so I'm not so sure how it would perform under the conditions you've outlined above. It's called svmem - Shared Video memory.
You may find the plugin here with source and a test app (VLC 1.1 only).

[Jean-Baptiste Kempf]

Is it your aim to use this IPC method in an output plugin to access the video data from an external process?

Hi Michael!

My aim is that an external process receives video from vlc to display it. This process allocates the memory and determines the maximum buffer size. Buffer size must be possible up to 3x 1920x1080x32bpp, (around 24MB) for triple buffering. Frame rates up to 50fps (for 1280x720) or 25fps for 1920x1080.

If you know a better way to share memory between processes, i'd be glad to know. (Windows only)
I assume it won't work to just pass a pointer and buffer size to vlc using the libvlc interface?

Hi Belbear,
I wrote a plugin using this very method but for much smaller external displays, so I'm not so sure how it would perform under the conditions you've outlined above. It's called svmem - Shared Video memory.
You may find the plugin here with source and a test app (VLC 1.1 only).

How is this different from the vmem ?

[Belbear]

Hi Belbear,
I wrote a plugin using this very method but for much smaller external displays, so I'm not so sure how it would perform under the conditions you've outlined above. It's called svmem - Shared Video memory.
You may find the plugin here with source and a test app (VLC 1.1 only).

Hi Michael,

Thanks for this very useful code. Looks much more like wat I need than vmem.c, which I started from.

In the meantime I solved the crash problem, stupid indirection error that got no compiler warning (a HANDLE is a void* itself )

Cannot use your code out-of-the-box however, since the synchronisation mechanism will have to work the other way around:
In pro video, the output framerate is usually genlocked to the studio master sync and cannot change, which means that the input (vlc renderer) will have to be locked to the output framerate using a double-buffer scheme. A triple-buffer scheme will have to handle "vastly different framerates" such as 30 or 60fps, i'm only doing European video.

I'm also back down to the 1.1.0-pre version now, I happened to break my 1.2.0-git branch in a way I could not fix. The make started to call it 1.2.0-git(2)
Will have to pull a fresh one from git but cannot do that here.

[Rémi Denis-Courmont]

In the current (version <= 1.1) VLC architecture, the video output cannot control the framerate (unless you're willing to discard or duplicate some pictures, that is). If you want to pace decoding, then you need to use the stream output chain, akin to what the smem plugin is doing.

[MichaelMc]

Hi Belbear,
I wrote a plugin using this very method but for much smaller external displays, so I'm not so sure how it would perform under the conditions you've outlined above. It's called svmem - Shared Video memory.
You may find the plugin here with source and a test app (VLC 1.1 only).

How is this different from the vmem ?

vmem is for same process access (address space) primarily through libvlc. svmem is designed for external process access through a Windows memory mapped file IPC method, where knowledge of libvlc is not required, and includes a rudimentary feedback mechanism for setting width, height and chroma. svmem is for the MS Windows platform only and as such uses the Windows synchronization API.
I use vmem for my own external usb connected media player and in another application svmem is used to display whatever VLC (the appl) is playing.

[Belbear]

In the current (version <= 1.1) VLC architecture, the video output cannot control the framerate (unless you're willing to discard or duplicate some pictures, that is). If you want to pace decoding, then you need to use the stream output chain, akin to what the smem plugin is doing.

Well, i'm very happy now because vlc now actually plays video in a window layer on the Bluefish444 card. Got the output plugin issues resolved mostly thanks to MichaelMc's svmem code. Many many thanks to Michael.

Phase one (proof-of-concept) is now complete, and yes, it plays full-HD 1920x1080 videos in a 1920x1080x32bpp buffer with VLC_CODEC_RGB32 chroma, having a cpu usage of "only" 60% on this quad-core system.
I must say vlc does an absolutely excellent job on resizing and chroma-converting, so doing any conversion on the side of my BlueMotion project will not be necessary. I wish to thank the entire videolan team for this excellent player.

Now I can move to phase two, using the vlclib from within my BlueMotion software to gain control over vlcplayer from there. For this test, I just ran vlcplayer from the desktop.

After that I will have to improve playback quality with a triple-buffer scheme that also deals with interlacing correctly. (playing interlaced content "natively" without de-interlacing) And hope that pace decoding will somehow be possible for genlocked output. Both are necessary to reach 100% broadcast quality.

If this works, vlc may eventually become a playout device for studio usage.
and, if there is interest in it by other vlc users, I may even write a "direct" output plugin to the Bluefish series of cards, without the need for a second process using proprietary code. The Bluefish444 SDK itself however is not GNU and therefore cannot be included in the vlc contribs. Nevertheless, Windows and even Linux versions of this SDK are available for free. (see http://www.bluefish444.com/support/oem/)

After finishing the video part comes audio output. Now i'm using the PC audio. The newest Bluefish (Epoch) cards have embedded SDI-audio capability, which would make extra audio equipment unnecessary.
And ultimately, who knows, doing capture as well (our Bluefish cards have an HD-SDI video input)