MLB.TV in Linux

quonset · 04-15-2009, 12:09 PM

Should the f) hack be honoring video_follow or is that impossible?

daftcat · 04-15-2009, 02:21 PM

Quote:

Originally Posted by quonset

Should the f) hack be honoring video_follow or is that impossible?

That's not impossible but a lot harder than it was last year and perhaps more work than it's worth.

Basically, there's no coverage choices in the listings, only an event-id. To get the coverage choices, we make two SOAP requests. The first one is a, "give me a menu" request. The second one is, "I'll take this one," request. Right now, I've just combined both requests in the request for media (aka the 'Enter' or 'a' key.)

For the 'f' hack, once the player starts, just switch the streams in the lower left of the DVR panel. The 'f' key is basically a temporary gap fix for live games and highlights. When both are worked back into the code, the 'f' key, like the 'z' key, will remain as an "undocumented" debug tool.

Theophile · 04-15-2009, 02:26 PM

I just went ahead and submitted a bug report to mplayer. I don't know how the handle bugs internally since there isn't a public bug tracker (like with ffmpeg), but if you want to take a look at the archive for the big reporting mailing list, it's here:

http://lists.mplayerhq.hu/pipermail/...pril/date.html

So far I'm the first person to report a bug this month. I don't know if the devs typically discuss the bugs on the list or what, but there you have it.

spektrx · 04-15-2009, 08:23 PM

That's good, but mplayer uses ffmpeg (libavcodec) for it's video decoding (the codec we're particularly concerned about here is ffh264). So, if the ffmpeg guys fix it (and they are very quick in doing so usually), we should be good to go soon

Quote:

Originally Posted by Theophile

I just went ahead and submitted a bug report to mplayer. I don't know how the handle bugs internally since there isn't a public bug tracker (like with ffmpeg), but if you want to take a look at the archive for the big reporting mailing list, it's here:

http://lists.mplayerhq.hu/pipermail/...pril/date.html

So far I'm the first person to report a bug this month. I don't know if the devs typically discuss the bugs on the list or what, but there you have it.

daftcat · 04-15-2009, 08:23 PM

Quote:

Originally Posted by Theophile

I just went ahead and submitted a bug report to mplayer. I don't know how the handle bugs internally since there isn't a public bug tracker (like with ffmpeg), but if you want to take a look at the archive for the big reporting mailing list, it's here:

http://lists.mplayerhq.hu/pipermail/...pril/date.html

So far I'm the first person to report a bug this month. I don't know if the devs typically discuss the bugs on the list or what, but there you have it.

I don't know how they respond to bug reports but I know they are quite developers. I can usually get several to dozens of new updates daily when I do an SVN. Kind of wishful thinking every time I download a new libavcodec/libh264* update that maybe they are already aware of this and fixing it. Takes about 12 minutes to build mplayer on my system so it's worth the daily gamble if it pans out.

daftcat · 04-15-2009, 09:54 PM

Quote:

Originally Posted by daftcat

I don't know how they respond to bug reports but I know they are quite developers. I can usually get several to dozens of new updates daily when I do an SVN. Kind of wishful thinking every time I download a new libavcodec/libh264* update that maybe they are already aware of this and fixing it. Takes about 12 minutes to build mplayer on my system so it's worth the daily gamble if it pans out.

Hmmm...it takes 12 min to build mplayer and 18 min to build ffmpeg on my system. My mistake. It errored out after 18 min. I guess I'll know later tonight when I get back from dancing how long ffmpeg takes.

Weird!

Theophile · 04-15-2009, 09:59 PM

Quote:

Originally Posted by spektrx

That's good, but mplayer uses ffmpeg (libavcodec) for it's video decoding (the codec we're particularly concerned about here is ffh264). So, if the ffmpeg guys fix it (and they are very quick in doing so usually), we should be good to go soon

Yes, I learned that about 15 minutes after I filed the bug report with MPlayer. :-)

Quote:

Originally Posted by daftcat

I don't know how they respond to bug reports but I know they are quite developers. I can usually get several to dozens of new updates daily when I do an SVN. Kind of wishful thinking every time I download a new libavcodec/libh264* update that maybe they are already aware of this and fixing it. Takes about 12 minutes to build mplayer on my system so it's worth the daily gamble if it pans out.

I have heard similar things about their reputation for prompt bug squashing. Nevertheless, I find myself suffering the anticipation of an 8-year-old on Christmas Eve. I'd better go to be before I succumb to the disturbing urge to "bump" a bug report!

daftcat · 04-15-2009, 10:01 PM

So what is the elementary stream referred to in the ffmpeg bug report?

Is there a way to chop off the bad frames at the head and tail?

I'm guessing since it's reproduced, they'll likely have a fix but I'm wondering if there is a way to just skip the first keyframe and jump to the next good keyframe? Or is that the problem? The keyframes are borked?

Clue me in, if you would. I'm more of a network guy than a media guy. I can get the bits to you, but I've never cared much (until now) about what those bits are.

Theophile · 04-15-2009, 10:10 PM

Quote:

Originally Posted by daftcat

So what is the elementary stream referred to in the ffmpeg bug report?

FLV is a container. In this case, it contains h.264 video and AAC audio. These are the elementary streams. I demuxed one of the offending FLV files grabbed from the Autobahn plugin and uploaded the elementary streams (which are what I was playing back when I took the screenshot earlier). The elementary streams both play back perfectly, but they don't as originally muxed into the flv container.

Quote:

Is there a way to chop off the bad frames at the head and tail?

That's what I was wondering. I was going to play with the 'dd' command tomorrow to see if that works. I'm prety sure you can't use the mplayer/ffmpeg option to begin at a certain time location because the verbose mplayer output I get tells me the stream is not seekable.

Quote:

I'm guessing since it's reproduced, they'll likely have a fix but I'm wondering if there is a way to just skip the first keyframe and jump to the next good keyframe? Or is that the problem? The keyframes are borked?

Clue me in, if you would. I'm more of a network guy than a media guy. I can get the bits to you, but I've never cared much (until now) about what those bits are.

Knowing as little as I do about how ffmpeg works its magic, I think the problem is most likely a product of a newer flv specification. My hunch is that it's a relatively simple fix and a matter of patching ffmpeg's flv demuxer to be able to interpret the header info. At least, that's what I'm hoping.

spektrx · 04-16-2009, 05:50 AM

A simple fix indeed, they've already done it, and it's in ffmpeg's svn repository >=r18533. So, I've just grabbed it and compiled it and....

<suspense>

Mplayer plays the untouched high-def .flv stream just fine (live streaming, and pre-downloaded with '-dumpstream')! Audio/video in sync and everything, beautiful picture, and fully VDPAU-accelerated if you're so lucky as well

It's so awesome to not have to use that flash garbage, I can't even tell you...

We still get these errors to the console however:

Code:

[h264 @ 0xa568510]AVC: Consumed only 1 bytes instead of 3291
[h264 @ 0xa568510]AVC: Consumed only 1 bytes instead of 1920
[h264 @ 0xa568510]AVC: Consumed only 1 bytes instead of 4652
[h264 @ 0xa568510]AVC: Consumed only 1 bytes instead of 2275
[h264 @ 0xa568510]AVC: Consumed only 1 bytes instead of 3084
[h264 @ 0xa568510]AVC: Consumed only 1 bytes instead of 5914

But if it plays fine, I'm not that worried. Now daftcat should be able to put the finishing touches on mlbdvr integration for nexdef streams! It will also be nice to have the option of downloading these and watching them later, for those of us on the other side of the world who are asleep when games are on

The highest-quality stream is 800x450 (so, not exactly 'HD', more like 'a little better than DVD'). However, its ~2200Kbps bitrate means that it looks very nice indeed, even when upscaled to true 720p (my setup). At this bitrate, a 4-hour game would be ~3.9GiB, not too bad!

For those wanting to get this working themselves, simply update your mplayer svn, as it's got external links to the parts of ffmpeg svn repository that it uses (ie libavformat, libavcodec).

One other tip, you will find that the flv stream is still not the friendliest (for example, you'll get wildly inaccurate 'total video time'). Therefore, I suggest remuxing videos that you'll not be watching live into a friendlier format. I suggest something as follows:

Code:

ffmpeg -i input_video.flv -vcodec copy -acodec copy output_video.mkv

Of course, make sure you're using the patched ffmpeg from svn.

Quote:

Originally Posted by Theophile

FLV is a container. In this case, it contains h.264 video and AAC audio. These are the elementary streams. I demuxed one of the offending FLV files grabbed from the Autobahn plugin and uploaded the elementary streams (which are what I was playing back when I took the screenshot earlier). The elementary streams both play back perfectly, but they don't as originally muxed into the flv container.

That's what I was wondering. I was going to play with the 'dd' command tomorrow to see if that works. I'm prety sure you can't use the mplayer/ffmpeg option to begin at a certain time location because the verbose mplayer output I get tells me the stream is not seekable.

Knowing as little as I do about how ffmpeg works its magic, I think the problem is most likely a product of a newer flv specification. My hunch is that it's a relatively simple fix and a matter of patching ffmpeg's flv demuxer to be able to interpret the header info. At least, that's what I'm hoping.

Theophile · 04-16-2009, 09:09 AM

Confirmed.

Awesomeness has come to my HTPC. :-)

Theophile · 04-16-2009, 10:14 AM

You can use the -really-quiet mplayer option to silence those h264 byte consumption errors. Man this rocks. :-)

daftcat · 04-16-2009, 12:04 PM

I want to get a show of keyboards how many premium vs. non-premium subscribers I have.

If I decided to not support non-premium users but could promise you that nexdef would work under Linux including live games using mplayer, would you switch to premium or would you be upset that I failed to support non-premium?

The issue is that nexdef is producing clean video streams for live games using mplayer while rtmpdump is producing video streams of about 1 frame a second. At least that's been my initial test this morning.

POLL

1. Are you currently a premium subscriber?
2. If not, would you upgrade to premium service if you could use nexdef and mplayer with or without recording the stream first? I've tested both (record/non-record) and they both work great.

jbond56 · 04-16-2009, 12:22 PM

premium

Great work so far.

Theophile · 04-16-2009, 12:32 PM

Premium here.

I also experienced the problem with the low-res rtmpdump files. This may be another bug that ffmpeg can fix. However, I have found that I can remux the rtmpdump files on the fly using mencoder to produce proper video and audio playback. The downside is I haven't yet figured out how to keep them in sync. The other downside is that it requires two temporary files: the one being written by rtmpdump and the one being written by mencoder.

Another option:

I haven't tested it yet, but can Autobahn be used by non-premium subscribers to get the 800k feed? I have an 800k feed created by Autobahn that plays back fine without remuxing. If that's available to non-premium, we may not have a problem after all.