Good news, everyone!

I spent some time digging into the weeds of MLB.tv, and I put together a couple of quick hacks that, at least with my limited testing so far, lets one use MLBviewer and mlbhls to watch games in glorious 5 megabit, 60 frame per second streams.

To make this work, changes are required to both MLBviewer and mlbhls. A patch with the MLBviewer changes is attached here:

mlbviewer.60fps.patch.txt

while the mlbhls changes have been committed to the experimental branch of my mlbhls fork on GitHub.

After applying the patch to MLBviewer and using the newly-updated mlbhls, you should be able to watch 60fps streams by setting the following settings in mlb.cfg:

min_bps=5000
max_bps=5000
use_wired_web=1
use_wired_web_60=1

The "use_wired_web_60" switch is a new one I added to enable/disable the hack that's switching things over to the 60 fps playlist. The rest should be familiar to anyone who's been using MLBviewer.

I'm not really sure what the state of 60 fps support is in media players these days, but the streams play great for me using mpv. People using other media players might have problems, so keep that in mind.

So far this is very lightly tested, and it's only doing MLB game streams, not highlights, condensed games, or any of that. For those sections that have 60 fps content it shouldn't be too hard to add those, but I wanted to get this out there now so people can try it out and bask in the glory of higher quality streams.

Feel free to chime in if something's not working right and I'll see if I can figure it out, and as always, many thanks to daftcat and all the other folks who've moved the ball forward on mlbviewer and mlbhls development.

1 members found this post helpful.

Hi!
First of all I absolutely go with the quote...!!
Second: I would like to test all this new stuff, confessing that I've always gone with the very basic version of mlbviewer, no mlbhls nor nexdef nor ...
So, what do I have to do with the patches, how do I get these new features to work? I've updated mlbviewer to the newest version with "svn up"...
Any help would be very much appreciated!

larshenric,

I was hoping that folks who are already comfortable with applying patches and building mlbhls would take a look at things first, but until that happens, you should be able to download the patch file I attached to my comment, and then put it in your mlbviewer directory and run:

and it should update the code. Then you'll need to build the updated mlbhls, which should be more or less this sequence of steps:

For the last step, you might need to adjust the path to wherever your mlbhls executable currently is.

Then add the config settings I mentioned in my post, and you should be good to go, though again, I haven't tested any of this much yet.

I would like to understand what is supposed to work. Is it the case that only the 5000K feed is at 60fps, or are the lower speeds also at the higher frame rate if use_wired_web_60 is set to 1. I say this because I do not use 5000K and at lower speeds setting use_wired_web_60 has no effect, on archived games at least. What does the 60fps playlist look like?

Yeah, it's only the 5000k stream. The name of the 60fps playlist is "master_wired60.m3u8" and the contents look like this:

Note the FRAME-RATE part is only present for the 5000k stream.

Thanks a lot for the "lesson"...!

Thanks for this. This sounds like a great addition. I'll look these over sometime this weekend and get your addition to mlbviewer merged.

OK, cool. When you do so, you should probably start with this updated patch, which uses the 60 fps hack in mlbplay.py as well as mlbviewer.py.

Attached Files

mlbviewer.60fps.v2.patch.txt (3.8 KB, 42 views)

That interesting (and helpful). Thanks.

Do you notice any improvement in picture quality with the higher frame rate?

You might also update the speeds for RTMP and HLS, which now are 450K, 800K, 1200K, 1800k, 2500K, 3500K (HLS only) and 5000K/60FPS (HLS only).

I've tested the 60 fps patch and it works well. However, it also breaks rtmp streams. Here is a simplified patch that still works for nexdef streams but leaves rtmp alone.

For any Arch users out there, I've made an AUR package including all the latest improvements: https://aur.archlinux.org/packages/mlbviewer-svn

Attached Files

mlbviewer-60fps.patch.txt (2.0 KB, 42 views)

1 members found this post helpful.

I reviewed the first 60fps patch and yes. That only works if that's all you're interested in using.

I want to move this code to mlbMediaStream and I want to do something that's been bothering me for years. I want to create a toggle for HLS stream speeds like I have for RTMP. I am sure the original reason why I hadn't done this is obsoleted by code reorganization I have done in recent years.

That said, I'm ten days away from a big deadline at work so this likely won't happen until after the 21st.

Oh wesome. You just made the change I wanted to make in your patch.

Besides wanting to implement the speed toggle, the only change I'd make to this patch is something more automatic and leave out the config option. Like if nexdef and speed >= 5000. Except check for max_bps and also adaptive setting. If adaptive, some or all bets are off and use normal streams. This is why I want to make the speed toggle. I could keep the min and max in the config for network tuning but I'd like for users to be able to select HLS speed as easy as RTMP.

I agree, there is no need for the extra config option. In fact, it looks like the new playlist also includes lower bitrate streams; only the max bitrate (5000) is actually 60 fps. Both fixed and adaptive streaming work fine for me using the new playlist. In adaptive mode it starts at low bitrate / framerate and adjusts up.

So perhaps always use the new playlist in HLS mode?

By the way, does the tuple NEXDEF_SPEEDS actually do anything anymore? As far as I can tell it is never read.

Another thought: the name "nexdef" doesn't really make sense anymore, as that plugin has gone by the wayside. Maybe rename "nexdef" -> "hls" throughout mlbviewer?

As far as I can tell, NEXDEF_SPEEDS is not actually used. I think it was meant to be the tuple to implement the speed switching in the GUI, but I never got around to it.

I agree that renaming NEXDEF to HLS makes more sense.

I'll look at all of this after work deadline in two weeks.