Utility/Library: Phoenix Media Streamer

[PiX64]

What are the chances of this working on android STBs? like an Pivos XIOS for example?

Might be a really cool way to throw together a SageTV Web interface that is usable via 10' gui and powered by your media streaming utility.

I may even be willing to pick up a device to help you test it out and work out the kinks.

SageTV UI in a full screen webbrowser with streaming media... awesome!

[stuckless]

Originally Posted by PiX64

What are the chances of this working on android STBs? like an Pivos XIOS for example?

Might be a really cool way to throw together a SageTV Web interface that is usable via 10' gui and powered by your media streaming utility.

I may even be willing to pick up a device to help you test it out and work out the kinks.

SageTV UI in a full screen webbrowser with streaming media... awesome!

To be honest, that would be easy to test, since this "server" in this case is just managing the VLC instance used for streaming, and VLC is doing the heavy lifting, in terms of creating an HLS stream on the fly. I suspect if the media player understood HLS streams (and I'd be surprised if it didn't) then it would just work.

I'm not sure I'd go down the Web Interface approach for android though... I've played around alot with using HTML+Javascript to build apps, mainly because I really want it to work well, but in my experience... the user experience is always lacking, and the UIs feel sluggish.

But, the existing App would work (I would suspect) on a Pivos, and I'll be looking at adding more of a "wall view" (aka netflix style view) and giving the ability to auto launch into a VFS view on startup... that way, the existing app could be used on a GoogleTV style unit, etc. I'm currently testing on a GoogleTV and my app is severely lacking

[PiX64]

Originally Posted by stuckless

To be honest, that would be easy to test, since this "server" in this case is just managing the VLC instance used for streaming, and VLC is doing the heavy lifting, in terms of creating an HLS stream on the fly. I suspect if the media player understood HLS streams (and I'd be surprised if it didn't) then it would just work.

I'm not sure I'd go down the Web Interface approach for android though... I've played around alot with using HTML+Javascript to build apps, mainly because I really want it to work well, but in my experience... the user experience is always lacking, and the UIs feel sluggish.

But, the existing App would work (I would suspect) on a Pivos, and I'll be looking at adding more of a "wall view" (aka netflix style view) and giving the ability to auto launch into a VFS view on startup... that way, the existing app could be used on a GoogleTV style unit, etc. I'm currently testing on a GoogleTV and my app is severely lacking

Sweet. You and I discussed this about a year ago prior to me starting the Plex Thing. we talked about different ways to make a fast/pretty ui that could work on android (phones / tablets / and htpc clients). If we could get this up and running, there is not limit to the number of clients a user can have in the house mainly becaseu this is all web based!

The Pivos XIOS DS runs XBMC so-so from what I have seen. It is however suppose to play media fantastically. Might be worth picking one of those up and helping you test/code in any way i can.

[rickw]

Trying to get the streaming setup and having some issues.

Setup:

• OS: Windows XP
• VLC: 2.0.5
• VLC Command (BMT): c:/program files/videolan/vlc/vlc.exe

Versions: (as reported by BMT)

• SageTV: 7.1.9.256
• Phoenix version:2.3.61
• sagex.api verson: 7.1.9.1
• Java verson: 1.6.0_07

Tried executing a media test from Chrome (Win7) with this URL

http://192.168.0.100:8080/sagex/streaming/request/cl123?mediafile=14466006&network=wifi&profile=normal

...I get the following results.

{"reply":{"error":"java.lang.NoClassDefFoundError: java/lang/ProcessBuilder$Redirect
at sagex.phoenix.remote.streaming.VLCHLSMediaProcess.start(VLCHLSMediaProcess.java:76)
at sagex.phoenix.remote.streaming.MediaStreamerManager.createRequest(MediaStreamerManager.java:58)
at sagex.phoenix.remote.streaming.PhoenixStreamingHandler.createMediaRequest(PhoenixStreamingHandler.java:104)
at sagex.phoenix.remote.streaming.PhoenixStreamingHandler.handleRequest(PhoenixStreamingHandler.java:51)at sagex.remote.SagexServlet.doPost(SagexServlet.java:60)
at sagex.remote.SagexServlet.doGet(SagexServlet.java:38)
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 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.handler.rewrite.RewriteHandler.handle(RewriteHandler.java:230)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:322)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:864)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:539)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520)\r\n",
"args":["","streaming","request","cl123"]}}

I started by trying to get the Android app to work, but it was always failing on the VLC Configuration. VLC.EXE would start on the server, but the app would never return from the testing VLC. (Looks to me it was expecting something from VLC.EXE that never happens)

Thanks,
Rick...

[stuckless]

Originally Posted by rickw

Trying to get the streaming setup and having some issues.

Setup:

• OS: Windows XP
• VLC: 2.0.5
• VLC Command (BMT): c:/program files/videolan/vlc/vlc.exe

Versions: (as reported by BMT)

• SageTV: 7.1.9.256
• Phoenix version:2.3.61
• sagex.api verson: 7.1.9.1
• Java verson: 1.6.0_07

Tried executing a media test from Chrome (Win7) with this URL

http://192.168.0.100:8080/sagex/streaming/request/cl123?mediafile=14466006&network=wifi&profile=normal

...I get the following results.

{"reply":{"error":"java.lang.NoClassDefFoundError: java/lang/ProcessBuilder$Redirect
at sagex.phoenix.remote.streaming.VLCHLSMediaProcess.start(VLCHLSMediaProcess.java:76)
at sagex.phoenix.remote.streaming.MediaStreamerManager.createRequest(MediaStreamerManager.java:58)
at sagex.phoenix.remote.streaming.PhoenixStreamingHandler.createMediaRequest(PhoenixStreamingHandler.java:104)
at sagex.phoenix.remote.streaming.PhoenixStreamingHandler.handleRequest(PhoenixStreamingHandler.java:51)at sagex.remote.SagexServlet.doPost(SagexServlet.java:60)
at sagex.remote.SagexServlet.doGet(SagexServlet.java:38)
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 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.handler.rewrite.RewriteHandler.handle(RewriteHandler.java:230)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:322)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:864)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:539)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520)\r\n",
"args":["","streaming","request","cl123"]}}

I started by trying to get the Android app to work, but it was always failing on the VLC Configuration. VLC.EXE would start on the server, but the app would never return from the testing VLC. (Looks to me it was expecting something from VLC.EXE that never happens)

Thanks,
Rick...

Wow... I can't believe there are this many people running Java 6 (1.6)

The VLC streamer code uses a feature in Java 7, mainly dealing with capturing output from command line programs, that I didn't really wan to re-invent in Java 6 (1.6)... So I used the API from Java 7.

I may fix this to work with Java 6 (at some point)... but it would be faster for you to just upgrade to Java 7

[rickw]

ok...so I just re-read the thread and this time noticed you required Java 7. So I installed Java 7 and now SageTV won't start. Says it can't find jvm.dll "please install Java Runtime Environment 1.4"



Is there a setting in Sage that needs to be updated with the new path to Java 7?

[Dargason]

For me, I stayed with 6 because there really wasn't any compelling reason to upgrade (and there were security concerns with Java 7) and well... everything was working fine.

Now that I have a reason to upgrade to Java 7, I have, and it's working fine.

[Fonceur]

Originally Posted by stuckless

I may fix this to work with Java 6 (at some point)...

Or use the HTTP option to bypass that capture...

[rickw]

Originally Posted by rickw

ok...so I just re-read the thread and this time noticed you required Java 7. So I installed Java 7 and now SageTV won't start. Says it can't find jvm.dll "please install Java Runtime Environment 1.4"



Is there a setting in Sage that needs to be updated with the new path to Java 7?

Ok...got it working. Had to install the an updated version of the Visual C++ redist to get the MSVCR100.dll. Guess that Java 7 needs this.

Anyway here's the download link if anyone else needs it.
http://www.microsoft.com/download/en...s.aspx?id=5555

Rick...

BTW. I hadn't upgraded Java because SageTV had been rock solid for me and didn't want to mess that up. But the idea of being able to stream to my tablet was too tempting.

[stuckless]

Originally Posted by Fonceur

Or use the HTTP option to bypass that capture...

I'm not sure I understand... I use the ProcessBuilder on java to startup the VLC instance... The "capturing" that I'm doing is reading the output stream from the process and writing it to a log file (one liner in Java 7). If this isn't done, then java buffers the output from a process and if you don't consume it... it will eventually crash java. This is solved in a couple different way... 1 is to use a StreamGobbler thread (which is what mobile web streamer uses) or 2, just tell the Process to write it's process output to a file (Java 7 feature). I opted for option 2, since I was quickly trying to get the flow working and I didn't want to manage any other threads in the process. And to be honest, there's no reason why anyone should be running Java 6... especially since Feb 2013 was the last time we'll see any updates to Java 6 (including security updates)

So, I'm not sure using the vlc built in http server (which is what I think you are suggesting) solves anythning for me, since I still need to capture the process output and write it to a log file (or discard it). Also, using the built-in vlc web server opens another issue which is forcing people to open up additional ports on their router to enable an internet passthrough to vlc stream.

[Fonceur]

Originally Posted by stuckless

The "capturing" that I'm doing is reading the output stream from the process and writing it to a log file (one liner in Java 7). If this isn't done, then java buffers the output from a process and if you don't consume it... it will eventually crash java.

I figured that using the http server, everything would be available as http messages, so that nothing would need to be captured.

I don't remember seeing any such issues when I initially supported the RTSP streaming through VLC, but maybe I just never caught up on it. I was just using a simple:

Runtime.getRuntime().exec(someVLCCommandString);

[Fonceur]

As people try to come up with the optimal command line, here's a few parameters that were useful for RTSP streaming (so ignore the RTSP specific stuff), though some might still apply for HLS... So you start with

StreamingVLCOptions = "-I dummy --one-instance --extraintf oldhttp --sout-keep --no-sout-rtp-sap --no-sout-standard-sap --rtsp-caching=5000 -f"

then append the file name. After you use

--sout \"#duplicate{dst='transcode{

and append one of those choices:

StreamingTranscodeOptions = "soverlay,ab=100,samplerate=44100,channels=2, acodec=mp4a,vcodec=h264,width=352,height=240,vfilter=\"canvas{width=352,height=240, aspect=16:9}\",fps=29,vb=200,venc=x264{vbv-bufsize=500,partitions=all,level=12,no-cabac, subme=7,threads=4,ref=2,mixed-refs=1,bframes=0,min-keyint=1,keyint=50,trellis=2, direct=auto,qcomp=0.0,qpmax=51,deinterlace}"

StreamingTranscodeOptions1 = "fps=14.98,vcodec=mp4v,vb=512,scale=1,width=352, height=240,acodec=mp4a,ab=192,channels=2,samplerate=44100,deinterlace,audio-sync";

StreamingTranscodeOptions2 = "fps=14.98,vcodec=h264,venc=x264{no-cabac,level=12,vbv-maxrate=300, vbv-bufsize=1000,keyint=75,ref=3,bframes=0},width=352,height=240,acodec=mp4a,ab=64,vb=300, samplerate=44100,audio-sync";

StreamingTranscodeOptions3 = "fps=29.97,vcodec=mp4v,vb=512,scale=1,width=352, height=240,acodec=mp4a,ab=192,channels=2,samplerate=44100,deinterlace,audio-sync";

StreamingTranscodeOptions4 = "fps=29.97,vcodec=h264,venc=x264{no-cabac,level=12,vbv-maxrate=300, vbv-bufsize=1000,keyint=75,ref=3,bframes=0},width=352,height=240,acodec=mp4a,ab=64,vb=300, samplerate=44100,audio-sync";

StreamingTranscodeOptions5 = "fps=29.97,vcodec=mp4v,vb=512,scale=1,width=576, height=384,acodec=mp4a,ab=192,channels=2,samplerate=44100,deinterlace,audio-sync";

StreamingTranscodeOptions6 = "fps=29.97, vcodec=h264,venc=x264{no-cabac,level=12,vbv-maxrate=300, vbv-bufsize=1000,keyint=75,ref=3,bframes=0},width=576,height=384,acodec=mp4a,ab=64,vb=300, samplerate=44100,audio-sync";

then it was finished by:

}:gather:rtp{sdp=rtsp://:8080/stream.sdp}'}\"

Of course by now I don't remember why a duplicate was used, but anyway you don't want to use that stuff as is, it's more about picking single option here and there if they seem relevant to you.

[stuckless]

Originally Posted by Fonceur

I figured that using the http server, everything would be available as http messages, so that nothing would need to be captured.

I don't remember seeing any such issues when I initially supported the RTSP streaming through VLC, but maybe I just never caught up on it. I was just using a simple:

Runtime.getRuntime().exec(someVLCCommandString);

From the JavaDoc

The Runtime.exec methods may not work well for special processes on certain native platforms, such as native windowing processes, daemon processes, Win16/DOS processes on Microsoft Windows, or shell scripts. The created subprocess does not have its own terminal or console. All its standard io (i.e. stdin, stdout, stderr) operations will be redirected to the parent process through three streams (Process.getOutputStream(), Process.getInputStream(), Process.getErrorStream()). The parent process uses these streams to feed input to and get output from the subprocess. Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock.

(emphasis added my me )

In my experience my "process" just seems to stop working (ie, blocks) until the ouput buffer is cleared. So, for streaming a 2hour movie... I didn't want to deal with with arbitrary "the stream just stopped, but I can see vlc is still running" type of support questions

[stuckless]

Originally Posted by Fonceur

As people try to come up with the optimal command line, here's a few parameters that were useful for RTSP streaming (so ignore the RTSP specific stuff), though some might still apply for HLS... So you start with

StreamingVLCOptions = "-I dummy --one-instance --extraintf oldhttp --sout-keep --no-sout-rtp-sap --no-sout-standard-sap --rtsp-caching=5000 -f"

then append the file name. After you use

--sout \"#duplicate{dst='transcode{

and append one of those choices:

StreamingTranscodeOptions = "soverlay,ab=100,samplerate=44100,channels=2, acodec=mp4a,vcodec=h264,width=352,height=240,vfilter=\"canvas{width=352,height=240, aspect=16:9}\",fps=29,vb=200,venc=x264{vbv-bufsize=500,partitions=all,level=12,no-cabac, subme=7,threads=4,ref=2,mixed-refs=1,bframes=0,min-keyint=1,keyint=50,trellis=2, direct=auto,qcomp=0.0,qpmax=51,deinterlace}"

StreamingTranscodeOptions1 = "fps=14.98,vcodec=mp4v,vb=512,scale=1,width=352, height=240,acodec=mp4a,ab=192,channels=2,samplerate=44100,deinterlace,audio-sync";

StreamingTranscodeOptions2 = "fps=14.98,vcodec=h264,venc=x264{no-cabac,level=12,vbv-maxrate=300, vbv-bufsize=1000,keyint=75,ref=3,bframes=0},width=352,height=240,acodec=mp4a,ab=64,vb=300, samplerate=44100,audio-sync";

StreamingTranscodeOptions3 = "fps=29.97,vcodec=mp4v,vb=512,scale=1,width=352, height=240,acodec=mp4a,ab=192,channels=2,samplerate=44100,deinterlace,audio-sync";

StreamingTranscodeOptions4 = "fps=29.97,vcodec=h264,venc=x264{no-cabac,level=12,vbv-maxrate=300, vbv-bufsize=1000,keyint=75,ref=3,bframes=0},width=352,height=240,acodec=mp4a,ab=64,vb=300, samplerate=44100,audio-sync";

StreamingTranscodeOptions5 = "fps=29.97,vcodec=mp4v,vb=512,scale=1,width=576, height=384,acodec=mp4a,ab=192,channels=2,samplerate=44100,deinterlace,audio-sync";

StreamingTranscodeOptions6 = "fps=29.97, vcodec=h264,venc=x264{no-cabac,level=12,vbv-maxrate=300, vbv-bufsize=1000,keyint=75,ref=3,bframes=0},width=576,height=384,acodec=mp4a,ab=64,vb=300, samplerate=44100,audio-sync";

then it was finished by:

}:gather:rtp{sdp=rtsp://:8080/stream.sdp}'}\"

Of course by now I don't remember why a duplicate was used, but anyway you don't want to use that stuff as is, it's more about picking single option here and there if they seem relevant to you.

Thanks I'll definately consult this once I start to add in rtsp streaming support.