Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[glynor]

These two recent threads, and my related testing, got me thinking:

http://yabb.jriver.com/interact/index.php?topic=95687.0
http://yabb.jriver.com/interact/index.php?topic=95478.0

The audio playback within the embedded browser is annoying in more ways than just the bug described in the first of those two linked threads.

Basically, MC doesn't "know" something is playing, so it behaves oddly.  Of course, the DSP has no effect because it doesn't think anything is playing.  And, if you switch away from the web page (to Playing Now, for instance) playback stops.

Perhaps more irritatingly, Internal Volume control also doesn't work.  If you have MC's audio path set up as I do (and as I think most JRiver folks would recommend: WASAPI Exclusive Mode with Internal Volume control) playback in the embedded browser completely locks you out of volume control from within the UI.  You have to use the Windows system volume control or manually switch MC out of internal volume mode.  For me, this is even more irritating on my HTPC because I also lose volume control with my remote (my remote sends volume commands to MC when MC is in the foreground, and since Internal Volume doesn't work, I'm locked out with my remote).

So... I really never use the embedded browser playback for anything.  To me, that is "broken".  But, it got me thinking, especially in light of all of the streaming discussions going on around here.  It doesn't have to be this way, I don't think.  You have the pieces.  On Windows, at least.  I see two things you could do that would make playback from within the embedded browser go from a clunky thing that makes me say why to a pretty slick feature:

* Send embedded Web Browser content to Playing Now.

Playing Now can display web content using the embedded web browser.  But, when you go to any of the Connected Media items and play something with the embedded browser, it "plays" right there where you are in Connected Media.  Why not load this into Playing Now (perhaps with a prompt) if you can't natively handle the content within the Player?  That will feel more natural, and it would be handy because MC wouldn't stop playback while you browse around and do other stuff.  It should be even able to keep playing in the Display Action Window, right?  What about Display View?

I don't care how you do the UI on this really.  Maybe a on-mouse-hover "send to Playing Now" item that appears when you use the embedded browser?  Maybe it always applies to Connected Media items?  Maybe it asks you with the current "playback catcher" dialog and prompts whenever it sees anything remotely audio-visual like in the browser?  Maybe it asks you when you try to navigate away from the Connected Media page inside MC (with Always, Never, etc controls of course)?

* Use the fancy new WDM Driver for audio routing.

If the WDM driver is enabled and working, and I can play audio through MC's engine from Firefox or Chrome or whatever, then why the heck can't the embedded browser in MC do this all the time?

The WDM driver is there (unless the user was a jerk and refused to install it).  Can't you just always hijack the audio from the embedded browser and programmatically set it to use MC's own WDM driver for output (unless it is missing or disabled or something)?  There has to be a way to set the audio output device for your embedded browser component, right?  Or, is it that crazy-pants that it forces you to use the system default or some other nonsense (and if so, I'd ask why use it at all then)?

Assuming there isn't nonsense, then you'd get DSP and all the other goodness, right?  And since it is your embedded browser, it should be more simple (relatively) to handle sync issues, and make sure that the browser doesn't do stupid things.  Certainly easier than playing nice with an external application, I'd think.

If you guys ever got around to doing these two things, or something functionally like it, I'd probably use the embedded browser a lot more.  In fact, with that, it'd be sweet to have access to way more Connected Media items.  I'd love to put my HBO Go subscription in there somehow, for example.  And there are all kinds of news sites and stuff with content that could be nice to browse around on.

[gappie]

The WDM driver is there (unless the user was a jerk and refused to install it).

really... a jerk... well well.

[glynor]

really... a jerk... well well.

Haha.  I kid.  I kid. 

[Hilton]

Highjack any audio from the internal web view to Playing now would be my first preference.

WDM playback within internal browser for display view and standard view as fallback would be second option, as long as the latency doesn't cause lipsync issues.

[imugli]

Just wondering if there's a way we can open webpages in Theater View in full screen mode? Or could this be made an option?

Case in point - youtube.com/tv - their 10ft interface that plays nicely with the chromium browser (haven't tried IE), is completely compatible with remote controls and plays great with the youtube app on people's phones.

I actually prefer this interface over Theater View Youtube, mainly because it just works and it will continue to work even as google make changes to their api seemingly from day to day, but the problem is that if it's set to open the webpage in Theater View it opens with the roller bar at the top and the video cannot be fullscreen'd (Yeah, I know it's not a word).

Exiting a fullscreen mode would simply be a matter of choosing one of the other functions on people's remotes (TV, Music, Videos etc), so I don't think that poses too much of a problem.

If I can be so bold, I'd almost say integrating this interface into MC rather than the current interface will save JR resources in the long term, as Theater View Youtube won't be so reliant on you guys constantly making updates whenever Google change the api. As it plays vevo videos fine as well, gone would be all the "Youtube not working" and "Why can't I play vevo videos?" threads.

Cheers,

J.

[glynor]

See:
http://yabb.jriver.com/interact/index.php?topic=95706.0

Gimme a +1

[imugli]

+1

[imugli]

Done.

So this has now become a two-pronged request -

Ability to "fullscreen" webpages in Theater View, in order to utilise 10ft interfaces (like youtube.com/tv) better.
Palm the sound from said webpages off back through JR WDM driver.

Thanks

:-D

[mwillems]

* Use the fancy new WDM Driver for audio routing.

If the WDM driver is enabled and working, and I can play audio through MC's engine from Firefox or Chrome or whatever, then why the heck can't the embedded browser in MC do this all the time?

The WDM driver is there (unless the user was a jerk and refused to install it).  Can't you just always hijack the audio from the embedded browser and programmatically set it to use MC's own WDM driver for output (unless it is missing or disabled or something)?  There has to be a way to set the audio output device for your embedded browser component, right?  Or, is it that crazy-pants that it forces you to use the system default or some other nonsense (and if so, I'd ask why use it at all then)?

Assuming there isn't nonsense, then you'd get DSP and all the other goodness, right?  And since it is your embedded browser, it should be more simple (relatively) to handle sync issues, and make sure that the browser doesn't do stupid things.  Certainly easier than playing nice with an external application, I'd think.

You can actually automate 95% of this right now by using zoneswitch to route audio input from the WDM to another zone.  You open web content in the integrated browser in zone A, the wdm driver engages in the background, zoneswitch engages, and the audio fromt he web content goes to zone B without stealing focus (most of the time).  So you can start netflix in the integrated browser in zone A and the audio gets passed through JRiver automagically in the background.  It's not bulletproof (it flakes and steals focus sometimes), but it's mostly automatic.

The devs could effectively make that kind of "loopback" the default behavior for browser audio in mc so that it would always feed through the WDM back into JRiver's audio chain (DSP, volume, the works) without requiring users to figure out zones + zoneswitch + the WDM driver.

[glynor]

The devs could effectively make that kind of "loopback" the default behavior for browser audio in mc so that it would always feed through the WDM back into JRiver's audio chain (DSP, volume, the works) without requiring users to figure out zones + zoneswitch + the WDM driver.

Right.  That's what I meant.  It is almost all the way there, but it is fiddly and difficult to set up.

Perhaps more important (and, I think, easier to implement) is the ability to send these pages to Playing Now, Display View, etc.  All of the Displays in MC can already handle Web Content (that's how the Track Info Display Plugins work, after all).  So, this would just let you access them from other places, and do so "from within" MC, fullscreen, and all the other ways you'd normally play Media.

Another good example of a service that has a good "10-foot" UI is Vimeo.

[Hilton]

Why not just have an external JRiver webviewer built as a chrome app that launches and closes on exit. I don't see a problem with that and it gets around so many problems.
Just write a Chrome plugin that uses MCWS and adds MC remote support or something like that.

I know we've all been tied to the "do it all in MC", but sometimes you just have to consider a new way because of the cost and risk associated with building it into MC.
Taking this approach also opens up so many other avenues that have been closed until now.

[glynor]

it gets around so many problems.

I'm not sure I understand what you're suggesting.

Browser plugins are another way to go, but I think that is more complex than supporting one browser system internally.  You'd have to support a few, at least (I don't use Chrome and have no interest in it), so that's a pile of new projects and products.  Plus, communicating with your Plugin and making sure they get in all the repositories, and supporting users installing them?

Is that what you mean?

I think it could work.  I don't know that it is a modest proposal.  And I'm not sure at all that it technically gets you around the DRM problem.

[glynor]

By the way, the two (relatively modest, I think) suggestions I'm making here are only the start of what I'd do with the system if it works and customers like it.

Down the road, you could certainly improve it with things like:

* An internally coded HTML5 Encrypted Media Extension capable player, so you can support Netflix.  This is assuming that Google doesn't eventually release the code in Chromium, of course (which could happen).  But, either way, it is a published spec, and they could do it themselves. JRiver does have DRM experience (I don't know if recently, but they sold and might-still-sell DRM systems of their own in the past).

* Awareness of common and high-profile websites like Netflix and HBO GO, providing playback controls support and stuff like that, without having to slurp up the content (which might be locked down forever) or relying on them to provide an API out of the goodness of their hearts.  It wouldn't be easy, but you could do it with lots of the services.  They're sending HTTP requests to start and stop playback, and lots of them even take a bunch of keyboard shortcuts.  You just have to map them and re-transmit them, in some cases, and hack small pieces of the web API in others.

[glynor]

Oh yeah, and I forgot one...

* Spoof yourself as a mobile browser (such as Chrome on Android) so that you get mobile versions of pages (turn-off-able on a site-by-side basis, of course).  Lots of the time the mobile web page is even more useful on a big screen than it is on a phone.  Big vertical lists of links are easy to "down arrow" your way through, and "enter" on, ala Theater View, compared to full desktop browser sites, that pretty much must be mouse-driven.

[Hilton]

By the way, the two (relatively modest, I think) suggestions I'm making here are only the start of what I'd do with the system if it works and customers like it.

Down the road, you could certainly improve it with things like:

* An internally coded HTML5 Encrypted Media Extension capable player, so you can support Netflix.  This is assuming that Google doesn't eventually release the code in Chromium, of course (which could happen).  But, either way, it is a published spec, and they could do it themselves. JRiver does have DRM experience (I don't know if recently, but they sold and might-still-sell DRM systems of their own in the past).

* Awareness of common and high-profile websites like Netflix and HBO GO, providing playback controls support and stuff like that, without having to slurp up the content (which might be locked down forever) or relying on them to provide an API out of the goodness of their hearts.  It wouldn't be easy, but you could do it with lots of the services.  They're sending HTTP requests to start and stop playback, and lots of them even take a bunch of keyboard shortcuts.  You just have to map them and re-transmit them, in some cases, and hack small pieces of the web API in others.

Yes yes yes... +1million....

Just found this which will be of much interest. Edit: incase you missed it, EME IS working in chromium for Netflix.
http://alien.slackbook.org/blog/watch-netflix-video-in-your-chromium-browser-this-time-for-real/

[Hilton]

I'm not sure I understand what you're suggesting.

Browser plugins are another way to go, but I think that is more complex than supporting one browser system internally.  You'd have to support a few, at least (I don't use Chrome and have no interest in it), so that's a pile of new projects and products.  Plus, communicating with your Plugin and making sure they get in all the repositories, and supporting users installing them?

Is that what you mean?

I think it could work.  I don't know that it is a modest proposal.  And I'm not sure at all that it technically gets you around the DRM problem.

Yes that's exactly what I mean. I posted a very good example of this the other day in the Netflix support thread.
The fact that Chromium didn't appear to support EME was the only reason I suggested external browser.

If you can do what you and I have both suggested and re-render the page in the embedded chromium browser with keyboard/remote support that would be perfect. (oh and route audio through now playing)

Check this out. Netflix HT - super early preview
This guys done some work with a chrome plugin to add keyboard navigation to Netflix. It re-renders certain things on the page and makes them navigable with keys.
Implement this plugin in chromium or something like it and your 90% there.
Add EME support to Chromium for HTML5 playback for another 5%.
Add audio from web via playingnow and MC audio engine and your done.


It works well, kind like what I mentioned above where he intercepts the website and re-renders it and adds keyboard support.
Go hard left to get the menu to pop up.
Scrolling isn't as smooth as you'd like but it works.

Forum
http://forum.kodi.tv/showthread.php?tid=207262

Chrome Extension
https://chrome.google.com/webstore/detail/netflix-ht-super-early-pr/kadcncdkgaldpfclhiahmbmdfbfdmdja

PS. you can actually use this method launching in chrome as an external browser as long as you have the plugin installed.

[Matt]

Hi.  I'm subscribing to this thread.

Honestly it sounds like you can get a lot of the way there today by using the WDM driver.  Making that easier would be great, but there are some hurdles (since we don't want to subvert audio playback on a user's system).

[raym]

Just wondering if there's a way we can open webpages in Theater View in full screen mode? Or could this be made an option?

Case in point - youtube.com/tv - their 10ft interface that plays nicely with the chromium browser (haven't tried IE), is completely compatible with remote controls and plays great with the youtube app on people's phones.

I actually prefer this interface over Theater View Youtube, mainly because it just works and it will continue to work even as google make changes to their api seemingly from day to day, but the problem is that if it's set to open the webpage in Theater View it opens with the roller bar at the top and the video cannot be fullscreen'd (Yeah, I know it's not a word).

Exiting a fullscreen mode would simply be a matter of choosing one of the other functions on people's remotes (TV, Music, Videos etc), so I don't think that poses too much of a problem.

If I can be so bold, I'd almost say integrating this interface into MC rather than the current interface will save JR resources in the long term, as Theater View Youtube won't be so reliant on you guys constantly making updates whenever Google change the api. As it plays vevo videos fine as well, gone would be all the "Youtube not working" and "Why can't I play vevo videos?" threads.

Cheers,

J.

There's a strong argument for this and you've made it well.

+2

[glynor]

I merged imugli's thread with this one, since both are essentially the same request (with my additional audio add-on request).

My main thing, the audio loopback stuff being secondary, is that I'd like to be able to get "Connected Media" web content, like YouTube, Vimeo, etc to "play" in Playing Now, Display View, the Display Action Window, and Detached Displays.

I'd also like it if the audio wasn't so weird.

Both are pretty relevant, and I think reasonably modest proposals.

[imugli]

Looks like this guy has got EME to work in Chromium on slackware. May be something in it

http://alien.slackbook.org/blog/watch-netflix-video-in-your-chromium-browser-this-time-for-real/

[Awesome Donkey]

If there's source code available to getting WidevineCDM working in Chromium, it could be possible that MC can leverage and use that to restore Netflix.

[Awesome Donkey]

Oh, here's an interesting tidbit from here.

I am the original person filing the bug: I've fixed it in the mean time. It's just a few gyp flag changes and simple modifications to the gyp files. It will take some time until I can post a clean diff but here are the things I remember:

1) build with the following gyp flags:
ffmpeg_branding='Chrome', proprietary_codecs=1, enable_pepper_cdms=1, enable_webrtc=1

2) Uncomment the version number and strings in src/third_party/widevine/cdm/widevine_cdm_common.h and change it to which ever binary version you have available. I installed the vanilla google-chrome debian package from Google and used the version string and number found in chrome://plugins/

3) in the same folder modify widevine_cdm.gyp. Change 'branding == "Chrome"' to 'branding == "Chromium" in line 10 and 88 (not sure if this is really necessary)

4) When compiling Chromium it will complain about a missing widevine binaries folder (can't remember where it was meant to be located). Create it and copy the binaries over from chrome. It will also complain about missing widevine_cdm_version.h and/or widevine_cdm_common.h. Just copy widevine_cdm_common.h you edited above to the location expected by the build system.

5) after building, test by watching purchased video on youtube and/or netflix. If we are packaging this as open source (for debian for example), remove the widevine binaries from the out/Release folder and create another non-free package just for the widevine binaries as is being done for pepperflash.

I'm sorry for not providing a patch for this but I am travelling on a netbook with limited resources and creating a patch and testing it would take weeks of compiling.

Hope this helps!

There's probably legalities here preventing JRiver from distributing the WidevineCDM files themselves BUT what if MC could detect an installed Google Chrome on a PC then scan for the required files (in the default location for Chrome's Appdata directory) and link to them or import them? The only downside here is you guys would have to keep up with Google Chrome stable updates along with WidevineCDM plugin updates as the Chromium version has to correspond to the WidevineCDM plugin specified when building Chromium.

[Hilton]

Glad someone finally noticed the link to EME widevine  Netflix on chromium I posted yesterday!

[imugli]

Glad someone finally noticed the link to EME widevine  Netflix on chromium I posted yesterday!

Sorry Hilton. If I had have seen it I would have attributed it :-)