I finally got my Jenkins environment (build automation) set up for building mlblive, the live CD and virtual machine version of mlbviewer. It's normally a two page HOWTO I have to grind through to make changes to the ISO image. It's much easier now to open the ISO and squashfs inside, make some changes, and re-package.

I have updated the mlblive image for 2015. It's basically just an SVN up over the last one. But it's a start. I want to explore some enhancements for it this season like either persistence or configuration import (possibly auto-import?) and definitely an auto-update feature so I don't have to upload a new image every time I want to include new commits.

If I'm really ambitious, I'll look into how to create debian dpkgs so if I make any distro/OS changes, users can patch them in instead of downloading an entirely new image. I wonder if Sourceforge has a REST API that can help me automate updating the Live CD such as querying the latest mlblive-debian-update.dpkg and automatically install it if it's newer than the version included in the image.

Basically, I want to setup the VM version once and then be able to launch mlblive like an application without having to reconfigure it every time. I'm not sure if this will be persistence or some form of configuration import (I want this more but haven't yet looked into whether it's possible.)

Anyway, so yeah, new mlblive image. Only difference is an SVN update of mlbviewer over last July's image. More improvements to mlblive coming this summer.

Noticed this today, and then got a notification from mlbtv 4hrs ago "...the new MLB.TV player is now available. There are no downloads required to experience the new in-page layout with simplified controls. Simply click a game and watch in HD from your browser."
Observations from Windows machines:
A separate window no longer opens.
Much more information in the window (scores, game status, etc)
Also is driving the video hardware harder, laptop kept overheating.

BTW, an Mlbtv game running on my android tablet, when chromecast to the TV, is NOTICEABLY higher quality than either Windows Chromecast/ wired, or Linux (Ubuntu), and both boxes are HDMI cabled. Haven't tried cygwin install yet.

In any case, does this "new player" change anything re:mlbviewer? Is it REALLY a new player, or just new content (New AND improved!)

My goal is the mlblive vm environment you are working on that doesn't require reconfiguring. Ubuntu screens, sound, & playback quality are all giving me fits tho, so I'm messing with all the alternatives. Mlblive from a CD works great, so its not you, its me...:-\

Near as I can tell the new player is just that. It's a new interface on their end but the core of the service is still the same. It seems this new player has as much effect on us as a new mplayer fork would have on non-Linux users.

That said, it sure is pretty and I will not miss the old interface. I say that now but I haven't verified whether this new interface is even available on Linux. mlblive has an older version of iceweasel and flash and thus it looks like it's being directed to the old player if you use the web player instead of mlbviewer. Did not boot up the home laptop last night.

Has anybody verified whether the new player works on Linux? It's moot since we have mlbviewer but I do like that interface.

Hey y'all. I'm finally back on Linux (thank Tux) and I need to get this installed on the new laptop. Am I seeing that I want MLBLive and not mlbviewer?

Just checked in and uploaded 2015-sf-1. Nothing was really needed to support 2015 over 2014 that I didn't even think about changing version strings and uploading a new version.

mlbivewer is still maintained.

mlblive is a Live CD / Virtual Machine version of mlbviewer. It's a Debian Wheezy image that's been customized to have mlbviewer, mlbhls, rtmpdump, and mplayer2. In addition, the XFCE interface is customized especially for mlbviewer. VirtualBox Guest Tools is also already preinstalled. With a reasonably modern machine (Core 2 Duo or better), you can boot mlblive as a virtual machine, fullscreen it, and watch a game like you were running the app natively. On my work laptop, I can go from Start->VirtualBox to watching my game in under a minute.

The biggest drawback of the live version is that you have to set the timezone and edit the ~/.mlb/config every time you boot. I have made both easy and painless in the image but it still has to be done each time. The discussion the other week was me thinking aloud about how I want to fix that. I'll probably change the image to search for a shared folder to save/read configuration from the host. But I want to also explore a way to automatically search for an update deb on each boot so that I can make the image able to refresh itself rather than having to keep uploading and downloading 1 GB images. In fact, I want this first so that the next image will hopefully be the last full one I have to upload. Everything else can be packaged as a patch dpkg.

So yeah, things just worked with mlbviewer2014 that I haven't been thinking about mlbviewer. The live version especially making it auto-updating and persistent has me more excited.

The live version sounds pretty good but I saw the update of mlbviewer and I'll snag that. Do you still update code to update like I used to run? I can't recall what app it uses and I haven't had a chance to go back through my old posts here yet.

I have recently noticed that mpv can play HLS streams natively, see e.g. https://github.com/mpv-player/mpv/bl...am_lavf.c#L370 Would it possible to use this feature instead of mlbhls, similar to librtmp instead of rtmpdump?

I can look into it. Are there any pointers to the URL syntax required? Even though I noticed a version of vlc with ffmpeg/hls support awhile back, I don't think it simply takes the base64 chunk that mlb.tv gives us. So if I knew what mpv is expecting, it will help me formulate the player command.

I believe it's just hls://<url>, but it might also be something like hls+http:// I just tried using Python's base64 module to decode one of the URL strings and I got something reasonable, starting with http://mlblive-akc.mlb.com. I could not play that URL in mpv...not sure why.

Of course it wouldn't be that simple. It wasn't that simple with librtmp either. Just like librtmp required all those flags and args to rtmpdump to be encoded into an ffmpeg-compatible URI, I suspect that it will be a poorly documented struggle to do the same for HLS.

OK, well it would be cool to get it working, but it's no big deal since we have mlbhls. Thanks for looking into it!

Admittedly, I didn't spend very long on this, but it looks like the HLS support you found in ffmpeg is for encoding, e.g. you can make an m3u8 out of an mpeg file and stream it via HLS. I don't see any documentation pointing to using mpv/mplayer as an HLS decoder. Presumably mpv/mplayer2 should already have m3u8 support but it could be the encryption that MLBAM uses that prevents a simple drop-in replacement for mlbhls.

What you can try...

This should produce a base64 string. You can decode this in python:

This should be a couple of URLS.

For example, I tried with the live Philly game and got this:

But if you try to give that, or just the m3u8 part to mplayer2/mpv, it doesn't work. As I'm sure you have already tried. So there's probably something in there, maybe that second bit that looks like it's still base64, that would tell the application how to proceed if only someone would tell me what piece that is and the command syntax.

Like I said, though, I think the HLS support you found is encoding and not playback. If you find anything else to help me out here, let me know.

mpv definitely has HLS playback -- try some of the test URLs here: http://stackoverflow.com/a/13265943. There are some other hints it's supported: a couple github issues concerning it, and the option --hls-bitrate in the man page (last option in the network options section: http://mpv.io/manual/stable/#network).

Looking more closely at the decoded URL, I think the stuff following the m3u8 filename might be passable to mpv through the --http-header-fields option (in the same man page section). Of course it would need to be parsed and reformatted so mpv can understand. I'm not sure about the encoded token immediately after the .m3u8. I don't have time to test this right now but I'll give it a shot tomorrow.

For what it's worth, this software appears to have done similar work for a number of other live-streaming services: http://docs.livestreamer.io/

The encoded bit must be an encryption key, and indeed I've found a number of posts around the web regarding AES encrypted HLS, but I'm still not sure how to pass it to mpv/ffmpeg. Here's what I've tried:

- extracted a test base64 URI using mlbplay
- decoded it using python base64.b64decode
- removed the encryption key from the URI and replaced it with a ? so mpv can parse it
- took the encryption key (not including the | delimiters) and converted it to hex using python binascii.b2a_hex(binascii.a2b_base64(key))
- tried to pass the key to mpv using the --demuxer-lavf-cryptokey option

So my full mpv test command was

This does not work, but it does appear to be closer than before. It takes a second doing something (as if it's loading the stream), then I get these errors

and then it spews out a ton more errors like this

so it does find the stream, it just can't decrypt it.

If it was as simple as supplying a crypto key to ffmpeg we wouldn't need mlbhls. If you want to use ffmpeg/mpv to watch mlb stream natively, you'll need to patch up ffmpeg to do mlb.tv's service calls to get the actual decryption keys. The ffmpeg peeps will probably never accept your patches but at least you'll have a properly working HLS client, as opposed to my quick hack of a client.