Streaming screen:// over RTSP, transcoding?

[Fire_]

As you already know, you can't stream a screen over RTSP without transcoding:

Code: Select all

stream_out_rtp error: cannot add this stream (unsupported codec: RV32) main error: cannot create packetizer output (RV32)

So I've come to ask... what codec provides the lowest overhead while being as close to the source material as possible in terms of quality? I would not transcode if I didn't have to, but as stated before VLC doesn't allow raw data over RTSP.

Side question: Any idea why VLC crashes with these settings? With/without audio makes no difference ( crashes either way ).

Code: Select all

:sout=#transcode{vcodec=h264,vb=20480,fps=30,scale=1,acodec=mp4a,ab=192,channels=2,samplerate=44100}:rtp{sdp=rtsp://:8554/} :sout-keep

[Rémi Denis-Courmont]

It depends what you mean by overhead here. Obviously, the most correct format would be RV24, but:

• VLC does not currently support RV24 over RTP,
• RV24 has very high bandwidth requirements.

But the point is, there is really no answer to your question. It's always about tradeoffs when transcoding.

[Fire_]

Processing overhead, in this case. Bandwidth is not an issue. I'm just trying to feed a screen capture from one machine on the network to another, with the other running XSplit to add the RTSP stream as a source in it's presentation, then re-broadcast out to an RTMP server.

I read one of your posts back in 2010 that said "RV32 is a raw video format: RGB 24-bits plus 8-bits padding. VLC cannot stream that over RTP, at least not currently." This leads me to believe that rgb32/rgb24 video over RTP was to be added at some point, but it still hasn't a year and a half later. Is that idea shelved, or will it be added sometime soon? I would attempt to add it myself, but I wouldn't even know where to start.

[Rémi Denis-Courmont]

You're over-interpreting my older post. There never was a plan. Nobody wrote the patch or sponsored anyone to do so, so it did not happen so far.

[Fire_]

What would it take to add support for it?

[Rémi Denis-Courmont]

On the sending side, someone needs to write RTP packetization for raw video. It is maybe two days work? That does not really mean anything, it depends who's doing it.

For lack of native RTSP client support in VLC on the receiving side, liblive555 needs to be patched. liblive555 is not within the scope of the VideoLAN project. You'd have to check with the liblive555 author. Getting rid of liblive555 would take several months of development, so I doubt you want to go that way.