You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

I noticed the grid also contains a feed labeled CLOUD_WIRED, which I'd been assuming was for NexDef. But it looks like Boxee directly accesses that feed for playback in 720p. Here's a Boxee info log indicating as much:

The thing to note about that is that this log is from my Linux box, which is NOT running the NexDef plugin at all. Moreover, the MLB.TV app for Boxee does not appear to package a separate version of it. And in any case, you'll note that the Boxee player uses ffmpeg for playback. So whatever Boxee is doing to "get at" the streams, mplayer should be able to handle it.

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.

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.

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:

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.

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:

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.)

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.

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.

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 .