The VideoLAN Forums

I am working on transcoding a 1080p h.264 stream into multiple streams of varying resolutions. The 1080p h.264 (mpeg-ts encapsulation) stream is coming in via RTP & multicast. I am using VLC & x264 to transcode it to H.264 and 720p or 480x270 resolutions (also mpeg-ts encapsulation) and sending each resolution out via separate RTP & multicast streams. It works but when I run my test clips, the clients viewing the transcoded streams are not seeing the first 3-10 seconds of video. The amount seems to vary based on the resolution I am transcoding to with smaller resolutions seeing less of the clip (i.e. missing 10 seconds). If I monitor the source stream on the client, bypassing the transcoder, I see all of the clip. Enabling the ":sout-keep" option on the transcoder helped but it isn't enough. I am running two test clips in a loop but it happens when not looping as well. Does anyone know what causes this or how to correct it? Is it possible for VLC to do some "preroll" so the client is not missing the actual video ?

Thanks in advance for any help you can provide.

I'm having the exact same problem. I was hoping to use the Mosaic feature to bypass the problem (no blanking of first few seconds occurs when you play the videos in a mosaic panel), but the mosaic feature is highly unstable, suffers from random crashes, occasionally makes multiple windows open up on the client, doesn't properly convert the audio or loses it completely, and the frame rate is set to 50!

Most of the affected source videos were encoded in XviD/MP3, but this problem is also happening with mp4 files downloaded from archive.org.

It makes no sense. How can the beginning of the videos be properly displayed within a mosaic panel, but not when you try to do a straightforward H264 stream? It's as if the mosaic windows aren't being encoded in H264 at all. It would explain the inconsistent playback problems I'm having between my mosaic and non-mosaic tests.

I can help address the random crashing part and it might be something worth trying.

I'm using mosaic for my project, and I discovered that if my background image is the same size or smaller then the largest video feed coming in, vlc will eat up all my memory and crash.

Example: If I know my largest video feed is 320x256, I just make my background image 356 x 292 and my random crashing issues went away.

best of luck and hope that helps you get a little further along.

Okay, I've found a solution. It's not perfect, but it should reduce the problem to less than a second of corrupted video.

You'll need two instances of VLC: one to transcode the video files into a common format, and another to stream to all of the clients.

Here's a command line example of an x264/A52 stream scaled to 640x480. Note the use of the "canvas" vfilter to help lock in the aspect ratio.

<your input here> --loop --sout-keep --sout-transcode-venc x264 --sout-transcode-vcodec h264 --sout-transcode-vb 2368 --sout-x264-keyint 24 --sout-transcode-vfilter canvas --canvas-width 640 --canvas-height 480 --canvas-aspect 4:3 --canvas-padd --sout-transcode-acodec a52 --sout-transcode-ab 192 --sout-transcode-channels 2 --sout-transcode-samplerate 44100 --sout-standard-access http --sout-http-mime video/mp4 --sout-standard-mux ts --sout-standard-dst 0.0.0.0:1234 --sout '#transcode:standard'

The "--sout-x264-keyint 24" is what will cut down the loss of the few first seconds of video. But you can't use "gather" in the output because it doesn't work. At least not here.

Now here's the second instance that will read the first instance's stream, and redistribute it to the clients.

http://127.0.0.1:1234 --loop --sout-keep --sout-standard-access http --sout-http-mime video/mp4 --sout-standard-mux ts --sout-standard-dst 0.0.0.0:5678 --sout '#gather:standard'

The stream on port 5678 will now play without any interruptions whatsoever, and the break-up at the beginning of each file will last less than a second.

If you use an MPEG2 stream, there will be no interruptions whatsoever.

Some file formats may not stream properly at all. I've had a ton of problems with the files available on archive.org. I've had many MPEG2 and MP4 files not stream at all while others would stream properly.

Also, this technique will NOT work at all with Theora/Vorbis material, either from a stream or from a file. The audio is properly relayed, but not the video. I've tried to transcode an MPEG2/A52 stream to Theora/Vorbis in the second mass propagation instance, but the sound keeps going out of sync or disappear altogether.

At least the MPEG2 stream is working properly, which is what I'll be needing the most for my upcoming cable channel.

Thanks for your reply. I thought this topic had died out.

As you suggested I changed the --sout-x264-keyint (aka Max GOP Size) to 24. I also changed the --sout-x264-min-keyint (aka Min GOP size) to 3. This seems to have fixed the problem. Thank you!

When I tried running two VLC instances, one for transcoding and one for streaming, as you suggested, the video quality wasn't quite as good as just running one instance. There were periodic artifacts and jitter with two instances and none with one instance. One instance is all I need for what I'm doing so I will stick with that.

Thanks again for your help.

Do note that the second instance does absolutely no transcoding whatsoever. All it does is stitch the streams from the first instance into one continuous stream. If you've added the transcoding code from the first instance into the second instance, take it out. You don't need it.

Another detail. You don't need --sout-transcode-width and --sout-transcode-height when using the canvas filter. You can take those out (I've corrected the code in my previous post).

Now I have to deal with the bugs in the Theora/Vorbis/Ogg format. HTML5 Open Video is great in theory, but not when the audio and video go out of sync! And I need that format if I want to include my television channel's live broadcast feed on my Web site without having to pay any licensing fees! Arg!

I understood that the second instance was not doing any transcoding. The video quality was diminished using the second instance to "stitch" the stream together versus just viewing the output of the first instance.

One thing that I have noticed is that by reducing the keyint from the default of 250 to 24 has increased my processor utilization a little bit, about 5% per stream for the higher resolutions. Have you also noticed increased CPU overhead from this change?