The NexDef plugin is basically an HTTP Live Streaming client. If there's an HLS client that can decrypt the segments and reassemble the stream, I could build the mlbviewer interface to it. It sounds like boxee/xbmc team has already figured that part out. I'm downloading their code tonight. Can you post me a link for the mlb.tv xbmc/boxee plugin? Also, if you know anyone who worked on the backend, can you put me in touch with them? I don't have nearly the time I used to for mlbviewer but maybe with some guidance on their code/implementation, I could figure out a way to leverage what they have already done.

Thanks!

Would this work?

http://code.google.com/p/hls-player/

Also, I did some digging and found that Boxee "rolled their own" HLS support. There's a related wiki page here. Of note is the email address at the bottom. I would suspect that's the guy to ask about how to approach this.

Some of the XBMC developers are working on a backport of the Boxee code to XBMC. In their ticket, they imply that there is HLS support in ffmpeg, but with limitations.

The spec is here.

If you can get as far as generating an M3U8 playlist, maybe we'll get lucky and HLS-player will work? If so, maybe that project can be used to create a client that can feed to mplayer.

By the way, I don't know how to download the MLV.TB Boxee app, except from inside Boxee itself. Once it does, I have compiled .pyo files. I decompiled the one that does all the hard work, and it's here:

http://pastebin.com/PKSM9V4q

EDIT: And divingmule in the XBMC forum has figured out how to get the .m3u8 file.

I know how to get the m3u8 file, and no, hls-player doesn't work. I suspect it's because the segments are encrypted. I don't know a great deal about encryption but the base64 chunk that is returned with a findUserMedia request for the HTTP_CLOUD_WIRED stream contains both the m3u8 URL and a crypto bit which must be used in conjunction with the key and IV in the m3u8 file. Unfortunately, my best try to reproduce the correct algorithm kept failing because the base64 seed and the base64 key in the m3u8 file was not coming out to a multiple of 16. I figure this is probably due to some python programming mistake I was making. In any case, I ran out of both time and desire to pursue this project.

I have actually be in contact with a developer who has a working HLS client for mlbviewer which, with his help, has been my model for my own project. Initially, I asked him to hold off on making it public. However, Boxee's implementation as you have explained it to me made me reconsider that request. In the end, I have decided that using an HLS client rather than the (un)official autobahn.jar plugin is no more dangerous than using rtmpdump rather than flash. I believe baseball fans, mlb.tv subscribers, and mlbviewer users are more interested in watching the games they paid for rather than stealing service they didn't or deconstructing the tools for purposes other than those granted by the terms of service. I like to err on the side of caution and prudence but I think implementing our own HLS will be within the realm of acceptable use.

Stay tuned. The author of that HLS client has agreed to release it but wants some time to clean it up first. In the meantime, I'll work on the mlbviewer interface to use it so there should be little lag between his release and mlbviewer's support of it. If I find a free moment between now and then, I'll see if I can have a look at the XBMC/Boxee implementation.

I just wanted to personally say thanks for all your efforts and for sharing your wealth of knowledge.

Thank You.

A few weeks ago I checked out the nexdef2011 branch. Since I only pay for the audio feeds, I successfully listened to several games using the mlbplay.py script. However, to my surprise, after a few system updates, neither mlbplay or mlbviewer works. Here's what I get when I run:

/usr/bin/python2.7 nexdef2011/mlbplay.py a=fla

RTMPDump v2.3
(c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL
Connecting ...
INFO: Connected...
Starting download at: -0.001 kB
1.277 kB / 0.18 secmplayer: could not connect to socket
mplayer: No such file or directory
53729.738 kB / 13244.76 sec
Download complete
[flv @ 0x25da960] invalid stream
[flv @ 0x25da960] Could not find codec parameters (Video: [0][0][0][0] / 0x0000)
[flv @ 0x25da960] Estimating duration from bitrate, this may be inaccurate


Any ideas? I have mplayer version SVN-r33713-4.6.0 installed.

Hey daftcat,

could you maybe provide a quick update to be able to watch the all-star game? There is an error when opening mlbviewer, it obviously has a problem with the listings.

I think and hope it's a quick fix.
Thank you so much in advance!

I had to apply this patch to play the all star game archive. The conditional in operator requires a valid value on its left side.

Chris

Attached Files

allstar.txt (1.4 KB, 31 views)

Awesome, thanks Chris! I had a quick look but couldn't see the fix without more digging. Looks great now!

Fixed and checked in as revision 310 on the mlbviewer branch.

Thank you very much guys!
I haven't tried it out yet - I was able to use the mlbplay.py-Script to watch the ASG.

You people are great, thanks.

All-star Game fix got checked into nexdef2011 branch. Along with it came my first attempt to support a non-autobahn.jar method of watching games in HD (aka NexDef...though I hesitate to call it NexDef since we are no longer using the NexDef code developed for MLB.TV.)

A few notes:

1. First, use SVN to check out mlbtv-hls-nexdef from this link:

http://code.google.com/p/mlbtv-hls-n...ource/checkout

2. Type 'make' to build the mlbhd executable and copy it to /usr/bin (or somewhere else in your PATH.)

3. Add 'use_mlbhd=1' to your ~/.mlb/config file.

4. Manually set the speed you desire in "NEXDEF" mode using the max_bps config file setting.

Valid choices are:

128, 500, 800, 1200, 1800, 2200, 3000, 4500

Add three zeroes to get max_bps setting.

5. Either add 'use_nexdef=1' to ~/.mlb/config or use the 'n' key from within mlbviewer to enable NexDef mode.

This is a first attempt. It won't be perfect and this is the documentation so far. If you're not comfortable with using 'make' or editing the ~/.mlb/config file, please wait for me to get this stabilized or the next few revisions.

For those who want to try this out, mlbhd is an HLS client (not written by me) developed specifically for MLB.TV. It handles the parsing of the base64 nexdef URL, the m3u8 files, fetching the timestamp media files, decrypting them, and streaming them to a file or, in this case, stdout where mplayer reads from stdin. In other words, very similar to the way rtmpdump and mplayer are piped together for non-nexdef mode streams.

I'm not a mplayer or ffmpeg expert or HLS expert by any means. In most cases, I'm just stringing up some dirty python code to work with other people's code and this is no exception. The video frequently works and the streaming works well. Sometimes the audio works and sometimes it doesn't. Best to either try again or try a different speed. I find 800K works every time. Other speeds are a lottery ticket. Sometimes you get lucky. Maybe having extra eyes on this especially those of you who know more about mplayer/ffmpeg than I do will help find the missing piece.

Give it a go and good luck. Let's get some extra testing into this to get it working well enough for me to put together some proper documentation and get it ready for the rest of you.

So glad to see the MLB HLS player posted here. Since we at the XBMC forums have been playing around with it for a couple weeks, I'll share a few of my random observations for others trying it out for the first time.

• If you're trying to build mlbhd on Ubuntu, you'll probably need to do this first:
  Code:

  sudo apt-get install libcurl4-gnutls-dev libconfig-dev

• Unlike rtmpdump, mlbhd does not necessarily pull the video down in real time. It downloads the chunks as fast as it can, which means if you're grabbing a stream with a higher bitrate than your internet connection, mplayer will eventually bottom out even with a huge buffer. The author of mlbhd wrote patches for mplayer and mplayer2 to mitigate the damage caused by this phenomenon.
  
• By default, mlbhd locks the target bitrate at the highest available, or whatever you specify with the -b option. But there's an experimental "stream switching" option using the -L option. Theoretically, it should adjust the bitrate according to your connection speed, but I haven't really given it a workout yet. Even so, it's possible that mplayer might have problems with such bitrate switching (mplayer2 supposedly has better support for this).
  
• Streams fetched with mlbhd have the TV and radio audio stream embedded. You can watch the TV coverage but listen to the radio announcer using the -aid option in the mplayer command line.

Never mind.

Hi Theophile!

Thanks for getting back to me. Glad you have worked with this tool already.

So let's figure out why there is sometimes no sound. I will upload samples using dumpstream as soon as I figure out how to share a public link via sugarsync (instead of a referral URL )

I'm building mplayer2 right now from the source tarball for build-2.0.

I couldn't get past the ./init --shallow step when trying to build from git source. It exited with fatal error, something about no git repository found.

For your convenience, I have moved the mlbhd command up to the top of MLBviewer/mlbtv.py as "DEFAULT_HD_PLAYER". Through some trial and error, I have found the "-f 48" offset seems to work best (most reliably find the head of the stream.) Though sometimes I do have to wait awhile for the game part of the stream .

Let me know if you need any mplayer logs.

Thanks!