mms:// problems

[indigobanana]

Hello, im new here!

Started using VLC over the past week or so, seems like impressive software, I have to admit... the only one i've found that acts as a media player, a streaming server and a stream capture all in one! fantastic!!

anyway on to the point...

I'm having quite a lot of troubles when using the mms:// streaming protocol... I'll start from the beginning...

I'm trying to setup an online TV broadcast-type-thing and want it so that it plays through windows media player, at least (thats why i chose mms). So this is the setup I came up with...

One instance of VideoLAN is running, with a playlist of different movie files. Each file is transcoded to DIV3 video and MP3 Audio, and is resized to 320x240, and sent to port 9733 on UDP.

I then have another instance of VideoLAN running which reads the stream on port 9733, adds a small logo in the top right of the stream and a timestamp at the bottom right, and this UDP stream is again transcoded to DIV3 video and MP3 Audio and then sent to mms:// on port 8000.

When I open this stream on another networked computer (mms://192.168.1.230:8000), using windows media player, it works for the first video file playing, but after that the video output will stop and there will be a black screen, however the audio keeps playing... If I reset the UDP > MMS stream the video appears again...

Any ideas if there is anyway around this?

Thank you,
Jamie.

[dionoea]

Try adding --sout-keep to your command line. (Btw, why do you use 2 VLC instances?)

[indigobanana]

Try adding --sout-keep to your command line. (Btw, why do you use 2 VLC instances?)

Umm well the main reason is that if I added the OSD on the first instance, if the video size is anything other than 320x240 it will get resized badly... because it renders the OSD onto the video and then resizes it... but if I apply it on the second applicaton instance it works fine because the video is already resized to 320x240.

Also on the UDP stream, there seems to be no or very little gaps inbetween playing different files (when viewed in VideoLAN), whereas there is noticable gaps inbetween files if I stream straight to MMS.

I also added --sout-keep to the command line of VLC.exe, its made no difference, the mms stream "stops" at the end of the file

in the message there are hundreds of late picture skipped messages if that means anything...

[dionoea]

You added --sout-keep on the mms server right?

[indigobanana]

Umm... on both

I changed the main link to the application to

Code: Select all

"C:\Program Files\VideoLAN\VLC\vlc.exe" --sout-keep

Sorry if im appearing a bit stupid...!
I havent tried using the command line interface before, it seems a bit complicated...

[indigobanana]

I ditched this approach, and now only have 1 instance of VLC running, and this is the stream output chain thingymabob im now using:

Code: Select all

#transcode{vcodec=DIV3,vb=128,scale=1,acodec=mp3,ab=96,channels=2}:duplicate{dst=std{access=mmsh,mux=asfh,dst=:8000}}

This is working great, now I can use quick add file to make the playlist and not change the settings on each item, however I'm still getting annoying 4~ second gaps inbetween each playlist item when streaming!! Sout-keep is on as well (I think)...

Any ideas?

[tipok]

--sout-keep - don't work propertly right now with mmsh protocol.

Streaming multiple files (different encodings/track id's) with mmsh doesn't signal the player that a new file has changed. I think that it at least needs a 'reset packet" between two adjacent files. This will trigger the client to request a new file/re-read the header and adjust its playout chain without losing the connection.

Test any *.wmv file with this commandline: vlc video1.wmv video2.wmv --loop --sout '#std{mux=asf,access=mmsh,url=:1234}' --sout-keep -vvv

Receiver end as: vlc mmsh://serverip:port -vvv

After the first movie you will see that the client detects an unknown stream-id and that the streaming server sends the next file. Because the id's of the audio/video tracks are different the client doesn't display the video.

Read more here