rtmpdump is creating broken files. We're still not sure if it's rtmpdump's fault or if that's the way the files are being given to rtmpdump by the server.

Can you open another ticket with ffmpeg with a 10mb sample file saved from a live stream?

I find it hard to believe that it's rtmpdump's fault (as much as I'd like to blame rtmpdump.) I also find mplayer's support for the streams (even in nexdef) somewhat embarrassing and sad. I mean we finally have seekable streams from mlb.com but try to move 10 seconds forward and back and mplayer chokes.

My offer still stands. If any of the ffmpeg developers are interested in baseball or want to test with real streams, I'd be happy to buy them a month or two of mlb.tv out of the donations I've received.

I feel a little sorry for the Windows users stuck with the flash player. If the ffmpeg fix ever gets propagated to the Windows build, I might cook up a little something for them, or at the very least, try to support mlbviewer for cygwin.

Nexdef isnt even loading properly in Flash so it is Swarmcast doing it on their end for some of the games.

Right.

The primary consumer of all the information contained in the XML's and the SOAP messages is, after all, the Flash player. So I would expect that if they are telling the Flash player the media state is MEDIA_OFF, the Flash player would actually look at that bit of information and do something with it. In this case, it's sending up Media Error messages.

The "fix" I checked in this afternoon is actually above and beyond the Flash player capabilities and functionality. This is partly why I will likely remove that fix and replace it with a config file option. MLB.com is being nice enough to tolerate us, even if they aren't actually supporting us. It would only be fair to them to play nice. I haven't checked in the config file option yet, but I'll let you know when I do.

Done.

https://roundup.ffmpeg.org/roundup/ffmpeg/issue1040

Thanks! Hopefully the fix will be as prompt as the last one! Then I can get down to figuring out why python does so poorly at managing two processes at a time (or more likely it's just the way I have it coded.)

Having some issues starting streams when the max_bps is set to 3000000. The stream will load in mplayer then freeze or alternate between full screen and window mode. Or it will close altogether. I changed the max_bps to 2200000 and the first try it loaded up ok. Not sure what this issue is but if as you say nexdef's highest bitrate is 2200k then there should be no issue changing to 2200k. Just thought I would let you know.

FYI - I ran one feed at 1200k just to see what it looked like through mplayer and man its a 100 times better than the 1200k feed on flash (windows machine). I just cant understand how the two could be so different at the same speed. I guess the flash player in windows is using a heck of lot more resources to produce the picture.

Just had a cool thought. The new version of rtmpdump supports streaming to stdout and I've already tested an mplayer pipeline like:

If we can get a fix from rtmpdump for archived games and that fix from ffmpeg for live games, I won't have to support any "dvr" code for rtmpdump or any downloading of games.

rtmpdump can be the non-premium users version of autobahn.jar.

I think when I get a chance, I'll see how the LibRTMP code differs from rtmpdump or maybe I can hack in some flow control into rtmpdump.

When it switches from full-screen to windowed mode the stream rate is switching from nexdef. Have you looked at the stream details output in the new mlbviewer? It should tell you for sure what nexdef is actually giving you.

Maybe after we get the fix for the non-premium users, we can ask mplayer if there is a way to not switch to window mode when the rate switches.

Although, I'd rather have those guys work on the seeking issues before that one.

If you run mplayer with the "-fs" option, it won't drop out of full-screen mode when the rate changes.

Ah, so that means the stream from nexdef was fluctuating for that game. Could be why I was having so many issues getting to load. Good point Theophile I will add to the the player commands.

Thanks

Right now I am enjoying my Giants against the hated Bums in baseball's "other" great rivalry (after NY-BOS). Live 3000K stream using latest from SVN. Simply beautiful and amazing. Better than TV. This thing is coming together VERY nicely.

As an aside, I was tinkering with your code and trying to get it to run on my Vista box at work today (no linux at work...and it was a slow day). After getting all the python module errors worked out (with pulse, json and such) I'm now to the point where it pops up the main screen - with what looks like a list of games - then burps with a 'not a valid socket' error. It only flashes up for a sec so I can't tell what's going on before the call stack from python comes back. Is there a way to enable more verbose logging than what python itself spits for the call stack so I can try and figure this out?

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.

A few recommendations:

1. Try this through cygwin if possible. I'm not sure how well the other pieces of mlbviewer work under native windows.

2. Get the test tools working first. Start with mlblistings.py. If that works, you know the xml code works. Move on to soapevent.py (just insert a sys.exit() call before the rtmpdump command to verify the SOAP code (e.g. suds) works under Windows. Finally you can try rtmpdump with soapevent.py or nexdef and mplayer with nexdef.py. The nice thing about the test tools is that these (while, yes, they are quite messy) are linear so you know exactly where it fails without having to make sense of the curses gui. You can also insert as many print statements into the test tools without fear of messing with/crashing the curses gui.

Let me know how far you get with the test tools. Once you've proven that a) the listings code and b) the test tools work, then getting the curses to work is simple. It worked last year.