VLC desktop streaming

Question

Edit
I stopped using VLC and switched to GMax FLV Encoder. It does a much better job IMO.

Original post
I am sending my desktop (screen) as an H264 video stream to another machine that saves it to a file using the follwoing command lines:

Sender of the stream:

vlc -I dummy
    --sout='#transcode{vcodec=h264,vb=512,scale=0.5}
            :rtp{mux=ts,dst=192.168.0.1,port=4444}'

Receiver of the stream:

vlc -I rc
    rtp://@:4444
    --sout='#std{access=file,mux=ps,dst=/home/user/output.mp4}'
    --ipv4

This works, but there are a few issues:

• The file is not playable with most players.
• VLC is able to playback the file but with some weirdness:
• => it takes about 10 seconds before the playback actually begins.
• => seeking doesn't work.

Can someone point me in the right direction on how to fix these issues?

EDIT: I made a little progress.

The initial delay in playback is because the player is waiting for a keyframe. By forcing the sender of the stream to create a new key-frame every 4 seconds I could decrease the delay:

:screen-fps=10
--sout='#transcode{vcodec=h264,venc=x264{keyint=40},vb=512,scale=0.5}
       :rtp{mux=ts,dst=192.168.0.1,port=4444}'

The seeking problem is not solved however, but I understand it a little better. The RTP stream is saved as a file in its original streaming format, which is normally not playable as a regular video file. VLC manages to play this file, but most other players don't. So I need to convert it to a regular video file. I am currently investigating whether I can do this with ffmpeg if I provide it with an SDP file for the recorded stream.

All help is welcome!

Solution

Updating your sender command line with:

venc=x264{scenecut=20,bframes=0}

And your client command line as:

vlc -I rc rtp://@:4444 --sout='#std{access=file,mux=mp4,dst=/tmp/output.mp4}' --ipv4

should fix your problems. Which players did you test?

Comments

[StackedCrooked]

Setting mux=mp4 is really helpful, it's a shame that it isn't mentioned the docs (videolan.org/doc/streaming-howto/en/ch03.html). Today I figured out that setting bframes=0 would result in a file that can be fixed with ffmpeg, but now this is also no longer needed thanks to the mux=mp4 setting. However, how does scenecut=20 help to fix my problem? Or is it just an optimization?

[StackedCrooked]

One more question: why did you leave out x264's keyint=40 setting?

[StackedCrooked]

Btw, I tested with Movie Player and GNOME Player on my Mint vbox. Both of these are now able to play my recordings thanks to the settings your provided. PS: Answer above questions and the bounty is yours.

[Derfel]

"scenecut" enable Scene-cut detection that controls how aggressively to insert extra I-frames. You can change that value from -1 (disabled) to 100. Changing this value can help the encoder to find a better location for the I-frame. I didn't need "keyint" and with larger value could lead to not precise seeks.