webserver + vlc + android + streaming = error

[jrjbertram]

127.0.0.1 is the ip address for 'localhost'. In my case, I was clicking on the sage interface from the same PC.

I'm not sure yet whether the 127.0.0.1 you put into the 'sout' VLC option is the source IP address or destination IP address. I know in some streaming modes (such as UDP), VLC needs the destination address... it just starts streaming video to that IP addr as soon as you launch VLC.

In other modes (HTTP), VLC listens for a connection, then begins streaming. I'm pretty sure that the mode that Sage is using is the latter, because I saw in 'netstat -ao' that VLC was listening on those ports. Just checked the command line I posted, yep.. it's using the HTTP mode.

Also, if you use 'netstat -aob' windows will go ahead and fish out the process's name for you. Or, you can use task manager to relate the PID and process name. So if you're worried about XP services possibly colliding with ports you're trying to use for Sage/VLC, then you can check beforehand.

When Sage kicks off the VLC process, is VLC responsible for accepting the connection to the outside world, or is Sage doing that and piping data between VLC and the external connection? I've been assuming VLC is doing it.

How does the Sage webserver direct the client to the right VLC port? (Guessing that if ports 8000 and 8001 are in use for one connection, then VLC and/or Sage is going to use 8002 and 8003 for the second connection?)

- J.

[Fonceur]

Originally Posted by jrjbertram

I'm not sure yet whether the 127.0.0.1 you put into the 'sout' VLC option is the source IP address or destination IP address.

Technically that's your streaming server that you will access from another player, at least for the HTTP method. Have you been able to stream to the Android through that command line test? I only have an Android emulator, but when I pointed Safari to ip:8000 it complained about not being able to determine the size of download.bin and just refused to stream... Maybe I just need to change the access to rpt or such?

[jrjbertram]

I just started playing with VLC recently. Haven't had much luck yet with VLC + Android, but over on the VLC forums it seemed like some people had some luck.

When I put in my hard coded URL on the android phone, I was able to start downloading the mpeg stream, but since it was probably going to be something like a 100MB file, I stopped the download. Didn't have time to try to get sage to stream me a 3 second clip that'd be easier to test with.

If you figure that out, post your working VLC command line if you don't mind.

- J.

[Fonceur]

With my server at 192.168.0.102, port 8000, I can use the command:

"C:\Program Files\VideoLAN\VLC\vlc.exe" -I dummy --no-sub-autodetect-file "Troisfugitifs-512272-0.mpg" --sout "#transcode{vcodec=h264,venc=x264{no-cabac,level=12,vbv-maxrate=384,vbv-bufsize=1000,keyint=75,ref=3,bframes=0},width=320,height=180,acodec=mp4a,ab=64,vb=384}:rtp{dst=192.168.0.102,port=8000,sdp=rtsp://192.168.0.102:8000/stream.sdp,mp4a-latm}"

and in another VLC session, on the same pc or a different one, I just use rtsp://192.168.0.102:8000/stream.sdp.

I tried using that in the emulator, but Safari just does a google search, instead of using it (might need to embed it in an html file or something). Launching MediaPlayer with it crashes with an error (1, -1)/PVMFFailure, which might be an emulator issue due to not having accessing to the UPD stream with it or something.

[jrjbertram]

Android phone browsers can't take an rtsp link directly, must be in an html file as a link. Clicking on that link will then call up the medai player.

[Fonceur]

Yeah, that's what I thought I had read... After more reading, it does seem like I won't be able to stream to the emulator anyway, so much for that...

[jrjbertram]

jreichen, do you have a guide anywhere that describes how to build the webserver from source? Was kind of interested in maybe instrumenting it with prints or experimenting with changing some of the defaults encodings supported, etc. Thought it'd be "easy".

I downloaded it from sourceforge in CVS, poked around and didn't see any obvious README/BUILDING style instructions... tried just loading 'webserver' in Eclipse (Galileo, Java EE version) with 'New->Project->Java Project from Existing Ant Buildfile', selected webserver/build.xml.

Eclipse did its initial compile.. I got 1424 errors, so something is not right. A lot of it just looks like maybe it's pointing at the wrong version of Java. I'm just doing something dumb, I'm sure.

It looks like maybe you're using cygwin for some of your make/build. What are you using for your IDE?

I did my CVS checkout into C:\cvs\sageplugins\webserver. There aren't any dependencies on directory path, are there..? Everything is relative?

I only know enough about Java and Eclipse to be dangerous, not useful, so there's probably an "oh duh" waiting to happen. I didn't see anything on the source forge site, either.

Thanks,
- J.

[Fonceur]

OK, so I can create the rtsp or http stream just fine in SageTCPServer, with plenty of configurable options... The only issue is that I'm using the Android emulator, which doesn't support multi-cast and other things like that, which means streaming (or UPnP, etc.) won't work for me, but if someone with a real device want to be the guinea pig, just send me a pm with an email where I can send you the latest taSageTV.apk file...

[jreichen]

Originally Posted by jrjbertram

Is there an easy way to dig out the vlc command lines the webserver is currently using?

Looks like you got the command line. The web server generates it from the values stored in webserver/transcode.properties.

Originally Posted by jrjbertram

Conclusion.. maybe the darwin solution I've got working is about all I'm going to get for now. But.. surely it works, because youtube can do it.

YouTube does not convert their videos in realtime. It's much easier to serve up a preconverted file.

Originally Posted by jrjbertram

Sooo... definitely had problem with my ports. The darwin server was taking TCP 8000 and 8001 for IceCast (I think). So updated that and verified 8000-8100 were unused. Verified that when I click the transcode link that VLC is launched, verfied with 'netstat -ao' that the PID listed matched VLC. Verified that the links work with Windows media player on the local host.

The port conflict shouldn't be a problem. There is a range of port numbers specified in webserver/transcode.properties and nielm's web server should keep trying ports within that range until it finds one that's not in use.

Originally Posted by jrjbertram

Still no dice. Noticed that when I launch from windows (tried with both chrome and IE) that Sage kicks off the VLC process. Noticed that when I click the link from the phone that the VLC process is not getting kicked off.

Started looking at the differences in the playlist. (Both wvx seemed to be recognized by both phone and windows, so started comparing those.) On windows, playlist looks like:

<asx Version = "3.0">
<title>Downloaded Playlist</title>
<entry>
<title>"Make" at Mon, Mar 8 10:00 AM on 32-2 KRINDT2</Title>
<ref href="http://localhost:8888/sage/public/MediaFileTranscode?MediaFileId=300316&Segment=0&mode=vlc&vc=mp4v&vb=256&ac=mp3&ab=96&scale=0.3&mux=ts&deint=1"/>
</entry>
</Asx>

On the android, the XML is the same, but the link is truncated to:

http://<ipaddr>:8888/sage/public/MediaFileTranscode?MediaFileId=300316&Segment=0&mode=vlc

(This was from clicking the same link [encoder, bit rate, playlist] on the web page.)

I tried plugging that link directly into the phone browser, and I get a jetty error as the result. Interesting part pasted in:

Exception while processing MediaFileTra java.lang.NumberFormatException: null java.lang.NumberFormatException: null at java.lang.Integer.parseInt(Unknown Source) at java.lang.Integer.parseInt(Unknown Source) at net.sf.sageplugins.webserver.MediaFileTranscodeServlet.doServletGet(MediaFileTranscodeServlet.java:110) at net.sf.sageplugins.webserver.SageServlet.doGet(SageServlet.java:86) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:389) at

Makes sense I guess -- it looks like an invalid URL.

That begs the question though.. why is the server giving the android phone a bad URL in the first place?

After looking at the web server code, it appears the android browser might be doing something to the URL behind the [wvx] link. I need to see your request logs to see what it's doing to it.

Originally Posted by jrjbertram

Does the server build the URL within the playlist based on the browser's user agent?

No

Originally Posted by jrjbertram

When Sage kicks off the VLC process, is VLC responsible for accepting the connection to the outside world, or is Sage doing that and piping data between VLC and the external connection? I've been assuming VLC is doing it.

How does the Sage webserver direct the client to the right VLC port? (Guessing that if ports 8000 and 8001 are in use for one connection, then VLC and/or Sage is going to use 8002 and 8003 for the second connection?)

The Sage webserver accepts the request from the user. It then launches the VLC process using the specified transcoding params and the first port it is able to open. That port is not served up to the client. The webserver internally connects to that port and starts copying the stream that VLC provides on that port back to the user via the HTTP response. That all happens as part of one request/response cycle. No other incoming communication occurs (for example, FF/REW). When the stream is finished or the connection to the client is broken, the webserver kills the VLC process.

[jreichen]

Originally Posted by Fonceur

Interesting findings. I was afraid I might have to add some transcoding engine directly to SageTCPServer or such... Using VLC for the heavy lifting sounds like a much better idea.

ffmpeg is another transcoding engine option but AFAIK it doesn't support rtsp.

[jreichen]

Originally Posted by jrjbertram

jreichen, do you have a guide anywhere that describes how to build the webserver from source? Was kind of interested in maybe instrumenting it with prints or experimenting with changing some of the defaults encodings supported, etc. Thought it'd be "easy".

I downloaded it from sourceforge in CVS, poked around and didn't see any obvious README/BUILDING style instructions... tried just loading 'webserver' in Eclipse (Galileo, Java EE version) with 'New->Project->Java Project from Existing Ant Buildfile', selected webserver/build.xml.

Eclipse did its initial compile.. I got 1424 errors, so something is not right. A lot of it just looks like maybe it's pointing at the wrong version of Java. I'm just doing something dumb, I'm sure.

It looks like maybe you're using cygwin for some of your make/build. What are you using for your IDE?

I did my CVS checkout into C:\cvs\sageplugins\webserver. There aren't any dependencies on directory path, are there..? Everything is relative?

I only know enough about Java and Eclipse to be dangerous, not useful, so there's probably an "oh duh" waiting to happen. I didn't see anything on the source forge site, either.

Thanks,
- J.

I don't think there's a guide for developers. It's been awhile since I did a lot of the setup so let me know if these instructions are missing something.

I use Eclipse as my IDE. To load the web server project into Eclipse, go to File -> Import, Projects from CVS. You'll need to do that for the webserver, sageutils, and sagexmlinfo projects. Follow the steps in the wizard to connect the project to CVS and pull the code down. Sourceforge has documentation about checking out for anonymous or developer access.

You also need to go to Windows -> Preferences -> Java -> Build Path -> Classpath Variables and set up a variable named SAGE_JAR that points to the Sage.jar file on your machine.

Nielm used cygwin to build the project when he used to do the builds. I created an ant script when I took over and don't use the cygwin scripts. To test the webserver, I copy the zip file for Jetty to the server then unzip it and "touch" the context file.

[Fonceur]

Originally Posted by jreichen

ffmpeg is another transcoding engine option but AFAIK it doesn't support rtsp.

Since I got the VLC part streaming, for now I will stick with it, unless we really can't get the Android devices to process those streams...

[jrjbertram]

Thanks, those instructions worked. I had to remove the NSIS part of the ant build file, since I didn't have NSIS and didn't want to build the TJWS builds. (More for others that come this way at some point in the future...)

Also, I have the two webserver war files installed side by side.. I renamed my war file to test_webserver.war and created my own test context file, updating paths in the context file as appropriate.

- J.

[jrjbertram]

@jreichen,

Got some logs that I think are showing that the file is coming over the wire with the truncated link. Gzip is now disabled, so should be easier to see now:

GET /sage/public/PlaylistGenerator?Command=generate&pltype=wvx&fntype=url&MediaFileId=300316&TranscodeOpts=mode=vlc&vc=h264&vb=96&ac=mp3&ab=32&scale=0.25&mux=ts&deint=1 HTTP/1.1
Cookie: grid_num_hours=6; grid_num_chans=999
Host: sageserver:8888
Connection: Keep-Alive
User-Agent: Mozilla/5.0 (Linux; U; Android 2.0.1; en-us; Droid Build/ESD56) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17

HTTP/1.1 200 OK
Date: Sun, 28 Mar 2010 18:40:21 GMT
Content-Type: video/x-ms-wvx
Content-Disposition: attachment; filename=playlist.wvx
Content-Length: 268
Server: Jetty(6.1.x)

<asx Version = "3.0">
<title>Downloaded Playlist</title>
<entry>
<title>"Make" at Mon, Mar 8 10:00 AM on 32-2 KRINDT2</Title>
<ref href="http://sageserver:8888/sage/public/MediaFileTranscode?MediaFileId=300316&Segment=0&mode=vlc"/>
</entry>
</Asx>

Let me know if you're looking for something specific, and I can try to send you additional dumps.

[Edit: This was clicking on the H264 128kbit deinterlaced quarter-res, Play In External Player links. Verifed the same link is generated in the M3U and PLS files as well.]

[jrjbertram]

I think I figured out what's going wrong... the URL that's being submitted is coming to the server unencoded:

From windows PC, clicking on one of the playlist links:

TranscodeOpts=mode%3Dvlc%26vc%3Dh264%26vb%3D96%26ac%3Dmp3%26ab%3D32%26scale%3D0.25%26mux%3Dts%26deint%3D1

Same link from the phone:

TranscodeOpts=mode=vlc&vc=h264&vb=96&ac=mp3&ab=32&scale=0.25&mux=ts&deint=1

The normal parsing of URL parameters would break on: "TranscodeOpts=mode=vlc&" since the ampersand after VLC is supposed to be 'escaped'/encoded properly.

So is that a phone bug or can the webserver be modified to spit out a pre-encoded URL? And how was windows (or I guess Chrome in this case) smart enough to re-encode the URL the right way?

- Josh.

[jrjbertram]

Here's what one of the links looks like when I view the source from windows/chrome:

<a href="player.html?fntype=url&amp;title=Make+-+Fire+Sculpture&amp;filename=Make-FireSculpture-35212-0.mpg&amp;MediaFileId=300316&amp;filename=TranscodedVideo.mpg&amp;TranscodeOpts=mode%3Dvlc%26vc%3Dmp2v%26vb%3D768%26ac%3Dmp2a%26ab%3D128%26scale%3D1%26mux%3Dts"

It's already pre-encoded. Crap. I bet the phone is unencoding the URL before sending it back to the server.

- J.

[jreichen]

Would you mind grabbing the corresponding entry from the most recent request log in jetty/logs so I can compare to what I have on my server?

I have an iPhone (also the WebKit browser) and the request URL is fine. It doesn't handle the playlist but that's not the concern, it's the URL format.

[jreichen]

Originally Posted by jrjbertram

It's already pre-encoded. Crap. I bet the phone is unencoding the URL before sending it back to the server.

- J.

I think you're right. I'm surprised the iPhone doesn't unencode it since they're both using the WebKit browser. Now just to find a workaround...

[jrjbertram]

Could you substitute '&' and '=' with some other character that'll survive the normal URL parameter parsing? (maybe "_" and I don't know.. "~") Then restore the proper URL here with string replace after the getParameter call?

private void ExportMediaFile(HttpServletRequest req, LinkedList<PlaylistItemInfo> playListItems, Object mediafile, int fntype) throws Exception {
        if ( mediafile == null || !SageApi.booleanApi("IsMediaFileObject",new Object[]{mediafile})) {
            log("ExportMediaFile: Not a  mediafile "+mediafile);
            return;
        }
        String transcodeOpts =req.getParameter("TranscodeOpts");

- J.

[jreichen]

Sounds like a good idea. I'll probably try something a little more unique like '_amp_' and '_eq_'.