MLB.TV in Linux

Originally Posted by daftcat I'm currently testing this on an archived game and so far, the results are quite encouraging. It seems that mplayer itself performs the throttling on rtmpdump forcing rtmpdump to "dump" the stream only as fast as mplayer can consume it. The result is a steady 800K stream. I'll be testing this tonight and if it streams all the way through an archived game without crapping out, I'll check in the mlbviewer integration code and scrap mlbdvr.py.

Crap! Spoke too soon.

I hate you rtmpdump!

Wow! That's pretty sad. Gnome-system-monitor that I was using for monitoring the bandwidth takes 20% CPU just to draw those pretty real-time graphs.

VERY VERY SUPER DUPER IMPORTANT

I checked in some code tonight for very experimental rtmpdump integration with mlbviewer.py.

I think I may have broken mlbdvr.py. I'm not sure if I broke it before this commit, though. Someone let me know if mlbdvr.py works before you checkout this revision. If mlbdvr.py is broken, someone let me know the last version it worked for you and I'll have that restored in the repository.

If mlbdvr.py is working for you, then DO NOT perform an 'svn up'.

Instead, cd to a different directory and perform a checkout:

$ svn co https://mlbviewer.svn.sourceforge.net/svnroot/mlbviewer/trunk mlbviewer

This revision is written for rtmpdump version 1.5 (released on Monday) and available on sourceforge.

You'll need to install libssl-dev package to compile rtmpdump 1.5.

You don't need to apply the patches because a) it won't work, and b) I haven't thoroughly tested this code and that includes no live game testing. It may or may not work.

WHAT'S IN THIS REVISION

Version 1.5 of rtmpdump supports streaming to standard output. As a lazy man's experiment to mlbviewer integration of rtmpdump, I've modified mlbviewer and certain parts of the mlbtv.py library (which is why this is not compatible with mlbdvr.py) to create a pipeline between rtmpdump and mlbviewer.

You'll need to add:

use_nexdef=False

to your configuration file to test it. It's really only written for archived video support, though archived audio may work as well. Please test with different values for cache in the video_player command-line. This probably won't work for any player other than mplayer.

If this does work for full games without restart, here's a bonus for you. Stream seeking and pause works beautifully as long as you don't seek past your buffer or pause past rtmpdump's timeout.

I suspect this will probably work better for larger values of cache as it won't slow rtmpdump down too much. I'm also checking in a version of soapevent.py called stdout.py that is basically the same concept. If you want to experiment with different mplayer options, search for mplayer down at the bottom of the file.

In the meantime, I'm also poking around the rtmpdump code to see if there's anything I can do to it to keep it stable for a full game.

Originally Posted by daftcat VERY VERY SUPER DUPER IMPORTANT I checked in some code tonight for very experimental rtmpdump integration with mlbviewer.py. I think I may have broken mlbdvr.py. I'm not sure if I broke it before this commit, though. Someone let me know if mlbdvr.py works before you checkout this revision. If mlbdvr.py is broken, someone let me know the last version it worked for you and I'll have that restored in the repository.

Yes, it is broken for me. I sorta of guessed that was what happened and took another mlbdvr.py off of another computer from a very early version but it didn't work at all. Didn't show any archived games, etc in the listings even.

So, since I keep updated pretty well, I "think" a couple, three revision back will work using the old rtmpdump. I like rtmpdump for the archived games. It works like a champ for those.

Please tell me how to download a certain version in svn. All I know how to do is to download the whole most recent creation plus do an update.

thanks...

Originally Posted by daftcat VERY VERY SUPER DUPER IMPORTANT

Upgraded rtmpdump (now bin command is rtmpdump_x86)

mlbviewer.py is, I think, half broken. Listings show up and rtmpdump get started on game selection ( I can see its noisy output ) but no video_player is executed: last rtmpdump line regards some "sending SendPlay".

Originally Posted by Wolfvorkian Please tell me how to download a certain version in svn. All I know how to do is to download the whole most recent creation plus do an update.

$ svn co -rREV

I have it working with 170.

As a side note r170 with newer rtmpdump doesn't seem to work. ( dumping doesn't start )

Originally Posted by Onip Upgraded rtmpdump (now bin command is rtmpdump_x86) mlbviewer.py is, I think, half broken. Listings show up and rtmpdump get started on game selection ( I can see its noisy output ) but no video_player is executed: last rtmpdump line regards some "sending SendPlay".

Sorry. Looks like I will be distributing a new patch set for rtmpdump v1.5.

In the meantime, this is the change you'll need to make for rtmpdump v1.5 (part of the patches I made last time.)

In rtmp.cpp:

732c732
<   packet.AllocPacket(256); // should be enough
---
>   packet.AllocPacket(512); // should be enough

Or for those that don't read diff, change line 732 in rtmp.cpp to increase the packet size for the SendPlay command. As you may have noticed, we send a pretty large "play" string.

I just had to pick the longest game in the archives to watch last night (BOS-CLE). The last I remember I had gotten to the 4th (I think), and past 40%, which is certainly farther than I have ever gotten with a naked rtmpdump. The output from last night looks like it finished without a timeout.

I'm now watching the Dodgers-Giants game and that seems to be working pretty well. I had a terrible Internet night last night but I think mlb.com had an even worse night. I think my original theory that mplayer will act as the flow control for rtmpdump may be correct after all. This is why I released the code before I had a chance to do much testing. I want you guys to help me with the testing.

If this works and if we get an ffmpeg patch for live games, this will be huge! Not only does this mean we'll have a single program for both premium and non-premium users, but I don't have to worry about the downloading of games any more.

Originally Posted by Theophile Done. https://roundup.ffmpeg.org/roundup/ffmpeg/issue1040

It's already reproduced. Those guys are super-responsive.

Originally Posted by daftcat It's already reproduced. Those guys are super-responsive.

Yep, and they've noted that dumpvideo produces a playable stream. That wasn't even true of the autobahn stream issue. I'm thinking that, whereas the autobahn things was an h264 issue, this may be a flv issue. Methinks this will be an easy fix.

Originally Posted by Theophile Yep, and they've noted that dumpvideo produces a playable stream. That wasn't even true of the autobahn stream issue. I'm thinking that, whereas the autobahn things was an h264 issue, this may be a flv issue. Methinks this will be an easy fix.

Let's hope so because streaming rtmpdump into mplayer is very exciting and it seems to be working quite well.

I'll be very happy to support my non-premium users if I never have to write another bit of that hackish "dvr" code.

Originally Posted by daftcat I'm reading the MLB.com support forum for issues with NexDef and I have to say... I am SOOOO grateful that my users are nothing like the ungrateful a-holes that post on those forums every minute of every day. It seems if even one person shows the tiniest amount of respect, appreciation, or "it works for me", they get lynched by the rest of them and called MLB.com spies. I have the utmost respect for the mlbsupport admin (or group of admins) who continues to provide level-headed (although perhaps not the most helpful) responses day in and day out. If I had to support a bunch of jerks like that, I would have given this project up for dust months ago. The level of support and appreciation I get from you guys keeps me going. Thanks!

Sometimes it is difficult to live with the inconsistencies of flash player and the obvious work still needed there.

Its been my experience that a large number of Linux users are quite sophisticated, and that may be due to the tenuous nature associated with caution and respect for the licensing issues associated with Linux. We don't have as much leeway to complain, nor should we because Linux is truly community driven and supported. All that said, we have our members with issues too.

I've noticed that some of this discussion has been veering off into non-tech dialog. Since Linuxquestions is not a social forum, at least I don't think it is, I'd like to offer an alternative for the social aspect of the conversation. I don't want to offend the folks here so if anyone is interested in my offer, please pm me.

Thanks to all who have been working so hard in making this happen for us. Sorry I'm not able to be more active and involved, but we're better off letting me feed off you guys. ...Thanks again!

Originally Posted by Onip $ svn co -rREV I have it working with 170. As a side note r170 with newer rtmpdump doesn't seem to work. ( dumping doesn't start )

Thanks for the tip.

For those like me who aren't familiar with SVN commands, I had to use the following to revert back to a lower revision.

svn co https://mlbviewer.svn.sourceforge.net/svnroot/mlbviewer/trunk mlbviewer -r170

So I was able to "watch" a full game last night (I actually slept through most of it but rtmpdump completed without errors and I got about 88% (top of the 9th) through a game this morning (the cat probably watched most of this as I just watched the stream counters from work.)

It looks like the concept of streaming in pipeline from rtmpdump to mplayer is sound and rtmpdump is definitely a happier camper with a little flow control from mplayer. Over the next few days, I'll be testing this code more thoroughly. If it proves sane, I'm removing mlbdvr.py from the repository and replacing it integrated mlbviewer support. I will also write a downloader script based off rtmpdump and mlblistings.py since much of the code I hate in mlbdvr.py is what I did to the curses gui and the silly pretense that watching and recording in the same script is possible. After watching 800K games, I have no illusions that downloaded and saved 800K games will cut into the far superior quality iTunes downloads.

Has anyone else tried the new mlbviewer integration with rtmpdump version 1.5 (remember you'll have to increase a memory allocation in rtmp.cpp - see above)?

Have you considered distributing rtmpdump with mlbviewer? Since rtmpdump is something of a limited reach project and, AFAIK, not part of any major distro's package management system, either including it in mlbviewer or including a fetch/patch/build script would probably make things easier on the general user.

I was on my laptop today, and got r170 working just fine on Windows. I have Cygwin, and Cygwin setup allows you to install python and ncurses, I svn'ed in the source and installed suds using "python setup.py install" command, which requires "python-setuptools", which either came with Python in Cygwin or is selectable in the setup program, can't remember which. The last step (which took me a minute to recall) was to move MediaService schema and web service definition files into .mlb folder of Cygwin home, which is default C:\Documents and Settings\username".

The downside is the precompiled binaries for mplayer or vlc don't have the ffmpeg fix yet. I'm sure you could compile mplayer from source but I don't really feel like delving into that right now. On another note, autobahn.jar also works just fine on Windows.

FYI daftcat, I didn't run into any windows-specific problems with mlbviewer.