various desktop streaming issues

[rogerdpack]

Once again, thought I'd post here first...

I have had success streaming VLC's desktop (see http://betterlogic.com/roger/?p=3058)
Thanks!

Also during my initial trial and error testing phase, I noticed the following apparently reproducible oddities (at least for me with 1.1.0, Windows 7):

When you use 1 fps (its default), VLC as a client cannot actually watch the stream.
It keeps previously "used for streaming" ports open (which was surprising to me--shouldn't it close them when you stop streaming? [this is with "keep streaming output open" preference not checked]).
VLC as a client of the HTTP streams seems to not be able to play a stream if named like "http://localhost:8080/" it seems to just buffer forever, then finally play when the stream is closed from the server side. Naming it like "http://localhost:8080/go.mpg" streams normally. (sometimes it appears to come in as vlc, too, which was odd).
The GUI seems to not actually set the slave options correctly. When I enter specific dshow components, it only uses ":input-slave=dshow://", ignoring all my other parameters (it then uses the dshow defaults, which wasn't expected).
When you check "display locally" for streaming, it gives you the audio locally, but of the video it seems to only display the first frame.
When you attempt to stream a DVD playback, it only actually starts streaming after it progresses to the second title.
When using the default output transcoding options (h.264 + AAC) there seems to be no audio playback when played by the VLC client. Switching to mp3 seems to allow the VLC client to get the audio (Mplayer also, oddly enough, gets audio but no video--the opposite of VLC as client).
The client "hangs" on the last frame of a title when going to the next title of a streamed DVD. (server moves on, client doesn't, nor does it try to reconnect or what not).
Clearing preferences doesn't seem to reset transcoding profile changes.



I assume all of these are worth reporting? Any feedback here?

[VLC_help]

VLC cannot playback slow FPS input. Known limitation.

For display locally issue, open Tools -> Messages (set Verbosity to 2) before streaming, it will complain.

For streaming hang on title change, make sure you have sout-keep turned on.

[rogerdpack]

Ok thanks. So I assume the rest of those are trac-worthy?

As a note, here's the output when I stream to "/" (the default)
qt4 debug: Adding option: :sout=#transcode{vcodec=h264,vb=0,scale=0,acodec=mp3,ab=128,channels=2,samplerate=44100}:http{mux=ffmpeg{mux=flv},dst=:8080/}

versus when I stream to "/go.mpg"
qt4 debug: Adding option: :sout=#transcode{vcodec=h264,vb=0,scale=0,acodec=mp3,ab=128,channels=2,samplerate=44100}:http{dst=:8080/go.mpg}

Is it expected that it stream as flv based on filename?

re: display locally issue:
the output looks like http://gist.github.com/517774
There are lots of "main warning: late buffer for mux input" (even if I stream at desktop 30 fps). Anybody have any ideas there?
Anything stand out? (DVD seems to display all right).
Thanks much! Just getting into the whole VLC contributing.
-r

[VLC_help]

Filename based guessing doesn't work with all file extensions. So defining mux is the sure way to do it. Also setting video bitrate to 0 isn't needed. Also don't put h.264 video to PS container.

And to the log, you cannot encode 1680x1050 video real time. It would require too much CPU power.

[rogerdpack]

Filename based guessing doesn't work with all file extensions. So defining mux is the sure way to do it. Also setting video bitrate to 0 isn't needed. Also don't put h.264 video to PS container.

And to the log, you cannot encode 1680x1050 video real time. It would require too much CPU power.

Thanks for the response.

The options I pasted were those that were "auto generated" using the GUI's streaming defaults, though I suppose I can change them on the command line quite easily, as you note

Also I'm a newbie--I assume you mean to not send h.264 through flv?
Also, does the GUI filename based guessing, despite the fact that the transcoding profile also (already?) specifies an "Encapsulation" type (as mp4/mov)?

Is it a bug that the GUI can generate such off settings?

Thanks.

-roger

[VLC_help]

Also I'm a newbie--I assume you mean to not send h.264 through flv?

No (I haven't tested putting H.264 inside FLV with VLC). I mean that if you want to stream your desktop to internet, use smaller resolution if you want to encode the video with x264.

Also, does the GUI filename based guessing, despite the fact that the transcoding profile also (already?) specifies an "Encapsulation" type (as mp4/mov)?

Filename based guessing selects Encapsulation. But list of supported extensions isn't that long, so all formats aren't identified.

[rogerdpack]

Also, does the GUI filename based guessing, despite the fact that the transcoding profile also (already?) specifies an "Encapsulation" type (as mp4/mov)?

Filename based guessing selects Encapsulation. But list of supported extensions isn't that long, so all formats aren't identified.[/quote]

Well if it's expected then that's all right. It's just a bit surprising that the transcoding profile's encapsulation is apparently silently ignored.

Thanks!
-r

[rogerdpack]

re: display locally issue:
the output looks like http://gist.github.com/517774
There are lots of "main warning: late buffer for mux input" (even if I stream at desktop 30 fps).

It seems to display locally fine if I disable transcoding, so my guess is that even at 5 fps trying to transcode to h.264 was too cpu intensive which somehow causes it to not display locally. Probably because the fps is < 1 which apparently doesn't work with VLC [1].

In other news, my current recommendation is that "filename based guessing" for container should become a checkbox in the GUI, (so people realize it's going on). Would that be a reasonable feature request? ok to submit it to trac?

Thanks!
-r
[1] http://trac.videolan.org/vlc/ticket/214

[rogerdpack]

And to the log, you cannot encode 1680x1050 video real time. It would require too much CPU power.

Would using -–sout-transcode-threads help here? Anybody know what that does, exactly?

[VLC_help]

IIRC the x264 has automatic threading (I am not sure if that is the default option VLC uses). AFAIK transcode-threads was meant to be a generic option but it seems to be unused ATM.