MLB.TV in Linux

daftcat · 08-18-2013, 02:02 PM

Quote:

Originally Posted by fang2415

daftcat, that sounds great on the rtmp front, glad you could identify what was going wrong.

As for -f vs -F, I completely agree that -F would be far better if it worked properly, and that innings support won't work without it.

As I mentioned, there is a workaround that can get inning support for -f-header'd streams, but boy is it a hack:

Start a stream with -f and save it to fvid.ts, then cut it off shortly after the stream gets rolling.

Then do this:

Code:

$ dd if=fvid.ts of=video_starter bs=5830 count=1

(5830 bytes seems to be the minimum that I can get to work.)

Then set the mlbviewer player line to something like this:

Code:

video_player=cat /home/fang2415/mlb/video_starter %s | mplayer -cache 10000 -

That should yield a stream that a stock mplayer installation should be able to play and seek through at least as much as the cache allows. (Of course, there might also be unsupported functionality that might save the stream to disk and make it 100% seekable...)

As I say, it's mighty ugly, but that's how I use the innings feature with a stock version of mplayer.

Maybe I'll send thegryghost an email to see if he can advise on a proper fix for mlbhls -F...

Please contact the thegryghost. This hack is not something I even want to attempt to put into mlbviewer.

daftcat · 08-18-2013, 02:11 PM

Happy Sunday!

Please update via SVN to revision 524 (or better) and test all your favorite RTMP streams.

At this point, I feel like I have fixed archived games without breaking live games. Live games seem a little sluggish to load and sometimes need to be retried. I'm not sure if that's normal for live games as I always use mlbhls but they do still work.

Check in with me and tell me what you tested and what works (non-nexdef only):

Archived video
Archived audio
Live video
Live audio

If all four are working for more than just me, I'll roll this up and update the Sourceforge link.

mkomko · 08-18-2013, 03:20 PM

Thanks daftcat. It's kind of a crapshoot, but after a lot of retries most streams seem to work.

Archived games:
Sometimes, the stream starts, but dies after a few kilobytes (usually between 30KB and 70KB) have been loaded. Message: ERROR: RTMP_ReadPacket, failed to read RTMP packet body. len:
Other times it seems to work fine. It's definitely better than before

.

Live games:
Some work, some don't. The ones working have a long player command containing FMS_CLOUD. The ones not working (e.g. WSH@ATL, FSSO-HD, 1800k) have a shorter player command not containing FMS_CLOUD and die with the message: ERROR: Closing connection: NetStream.Failed
About half the live games right now work, the others don't. It's always the same behavior.

Not working:

Code:

rtmpdump -f "LNX 10,0,22,87" -o - -r "rtmp://mlbsecurelivefs.fplive.net/mlbsecur
elive-live/mlb_c42_s1800@s22746?auth=0846afc7b9588ba115284&resource=/mlb_c42_s30
0@s22706.flv;/mlb_c42_s500@s22716.flv;/mlb_c42_s800@s22726.flv;/mlb_c42_s1200@s2
2736.flv;/mlb_c42_s1800@s22746.flv;/mlb_c42_s2400@s5851.flv;&endTime=1376857062&
contentId=29537553" -y "mlb_c42_s1800@s22746?auth=0846afc7b9588ba115284&resource
=/mlb_c42_s300@s22706.flv;/mlb_c42_s500@s22716.flv;/mlb_c42_s800@s22726.flv;/mlb
_c42_s1200@s22736.flv;/mlb_c42_s1800@s22746.flv;/mlb_c42_s2400@s5851.flv;&endTim
e=1376857062&contentId=29537553?auth=0846afc7b9588ba115284&resource=/mlb_c42_s30
0@s22706.flv;/mlb_c42_s500@s22716.flv;/mlb_c42_s800@s22726.flv;/mlb_c42_s1200@s2
2736.flv;/mlb_c42_s1800@s22746.flv;/mlb_c42_s2400@s5851.flv;&endTime=1376857062&
contentId=29537553" -a "mlbsecurelive-live" -s http://mlb.mlb.com/flash/mediapla
yer/v4/RC91/MediaPlayer4.swf?v=4 -d "mlb_c42_s1800@s22746?auth=0846afc7b9588ba11
5284&resource=/mlb_c42_s300@s22706.flv;/mlb_c42_s500@s22716.flv;/mlb_c42_s800@s2
2726.flv;/mlb_c42_s1200@s22736.flv;/mlb_c42_s1800@s22746.flv;/mlb_c42_s2400@s585
1.flv;&endTime=1376857062&contentId=29537553" -v -A 0 | mplayer...

Working:

Code:

rtmpdump -f "LNX 10,0,22,87" -o - -r "rtmp://cp65670.live.edgefcs.net/live/mlb_c
40_s1800@s22193?auth=da.bndna2bBbPbHcQdNafcFdPc6aXaYbXcv-bsesVW-O-EqoDEoCvlpxlDt
-jbl3mdlljejdkildk9m5jbkdk9k6l8mijdl4m7lfjkj3kglakg&aifp=v0001&slist=mlb_c40_s30
0@s21053;mlb_c40_s500@s21093;mlb_c40_s800@s21133;mlb_c40_s1200@s21173;mlb_c40_s1
800@s22193;mlb_c40_s2400@s5811&ct5=18-Aug-13&ct6=[IP]&ct7=29537305:FM
S_CLOUD&ct8=1&ct1=mlb&ct3=7808471&ct4=mlb&ct9=51798b77caf441a783bacbe5960dccf6"
-y "mlb_c40_s1800@s22193?auth=da.bndna2bBbPbHcQdNafcFdPc6aXaYbXcv-bsesVW-O-EqoDE
oCvlpxlDt-jbl3mdlljejdkildk9m5jbkdk9k6l8mijdl4m7lfjkj3kglakg&aifp=v0001&slist=ml
b_c40_s300@s21053;mlb_c40_s500@s21093;mlb_c40_s800@s21133;mlb_c40_s1200@s21173;m
lb_c40_s1800@s22193;mlb_c40_s2400@s5811&ct5=18-Aug-13&ct6=[IP]&ct7=29
537305:FMS_CLOUD&ct8=1&ct1=mlb&ct3=7808471&ct4=mlb&ct9=51798b77caf441a783bacbe59
60dccf6?auth=da.bndna2bBbPbHcQdNafcFdPc6aXaYbXcv-bsesVW-O-EqoDEoCvlpxlDt-jbl3mdl
ljejdkildk9m5jbkdk9k6l8mijdl4m7lfjkj3kglakg&aifp=v0001&slist=mlb_c40_s300@s21053
;mlb_c40_s500@s21093;mlb_c40_s800@s21133;mlb_c40_s1200@s21173;mlb_c40_s1800@s221
93;mlb_c40_s2400@s5811&ct5=18-Aug-13&ct6=[IP]&ct7=29537305:FMS_CLOUD&
ct8=1&ct1=mlb&ct3=7808471&ct4=mlb&ct9=51798b77caf441a783bacbe5960dccf6" -a "live
?_fcs_vhost=cp65670.live.edgefcs.net&akmfv=1.6" -s http://mlb.mlb.com/flash/medi
aplayer/v4/RC91/MediaPlayer4.swf?v=4 -d "mlb_c40_s1800@s22193?auth=da.bndna2bBbP
bHcQdNafcFdPc6aXaYbXcv-bsesVW-O-EqoDEoCvlpxlDt-jbl3mdlljejdkildk9m5jbkdk9k6l8mij
dl4m7lfjkj3kglakg&aifp=v0001&slist=mlb_c40_s300@s21053;mlb_c40_s500@s21093;mlb_c
40_s800@s21133;mlb_c40_s1200@s21173;mlb_c40_s1800@s22193;mlb_c40_s2400@s5811&ct5
=18-Aug-13&ct6=[IP]&ct7=29537305:FMS_CLOUD&ct8=1&ct1=mlb&ct3=7808471&
ct4=mlb&ct9=51798b77caf441a783bacb

I've replaced my IP with [IP] in the second player command. Also, the second player command does not show the pipe to mplayer. I guess it just cuts off.

daftcat · 08-18-2013, 03:59 PM

Thanks for the information and the specific example. Very helpful.

I have fixed the video playback for that game and tested live and archive, video and audio, for other games.

Try this new revision 525 and let me know if any others still are not working.

Thanks!

thegryghost · 08-18-2013, 04:01 PM

So, I've tried to reproduce the issue with the today's (8/18) Mets/Padres. I'm using mplayer2 (git from 20130428) which can fetched as a tarball here. It's using my system-wide installed ffmpeg version 1.2.1.

Starting at the top of the 2nd:

./mlbhls -B "aHR...k=" -o tmp.ts -F "20:32:04"

mplayer tmp.ts

Everything seeks just fine. Maybe you can get me a short sample of what does/doesn't work (maybe grab the lowest possible bitrate)?

I DO NOT recommend using VLC. It's been a year or so since I last tried it but it doesn't support resolution switching and didn't support VDPAU properly.

Also, double check which version of ffmpeg you're using. Wether mplayer2 is using it's own built in version or the system-wide version. Older versions of ffmpeg were not good at dealing with MPEG-TS files and this is probably where your problem lies.

Quote:

Originally Posted by fang2415

daftcat, that sounds great on the rtmp front, glad you could identify what was going wrong.

As for -f vs -F, I completely agree that -F would be far better if it worked properly, and that innings support won't work without it.

As I mentioned, there is a workaround that can get inning support for -f-header'd streams, but boy is it a hack:

Start a stream with -f and save it to fvid.ts, then cut it off shortly after the stream gets rolling.

Then do this:

Code:

$ dd if=fvid.ts of=video_starter bs=5830 count=1

(5830 bytes seems to be the minimum that I can get to work.)

Then set the mlbviewer player line to something like this:

Code:

video_player=cat /home/fang2415/mlb/video_starter %s | mplayer -cache 10000 -

That should yield a stream that a stock mplayer installation should be able to play and seek through at least as much as the cache allows. (Of course, there might also be unsupported functionality that might save the stream to disk and make it 100% seekable...)

As I say, it's mighty ugly, but that's how I use the innings feature with a stock version of mplayer.

Maybe I'll send thegryghost an email to see if he can advise on a proper fix for mlbhls -F...

mkomko · 08-18-2013, 04:14 PM

Quote:

Originally Posted by daftcat

Thanks for the information and the specific example. Very helpful.

I have fixed the video playback for that game and tested live and archive, video and audio, for other games.

Try this new revision 525 and let me know if any others still are not working.

Thanks!

Live video seems to work great now, thanks! Archived video is still a crapshoot though, but I'm guessing there is not much you can do about that, correct? Do you also have to retry many times to get some of the archived streams going or is it just me? E.g. 2013-08-17-nyamlb-bosmlb-1-Fox-HD at 1800k - it's taking a lot of tries to finally get it running. Is it the same for you?

daftcat · 08-18-2013, 04:28 PM

Quote:

Originally Posted by mkomko

Live video seems to work great now, thanks! Archived video is still a crapshoot though, but I'm guessing there is not much you can do about that, correct? Do you also have to retry many times to get some of the archived streams going or is it just me? E.g. 2013-08-17-nyamlb-bosmlb-1-Fox-HD at 1800k - it's taking a lot of tries to finally get it running. Is it the same for you?

5 for 5 trying that particular game and speed. No issues on my end.

Is there another stream giving you issues?

By the way, I really appreciate that you are telling me the exact streams. It really helps me test and investigate on my end. Thanks!

mkomko · 08-18-2013, 04:43 PM

Thanks. Very interesting...it usually takes me at least 5 to 10 tries to get it going. Sometimes even more. But at least I can get it going most of the time

.

charlie460 · 08-18-2013, 07:17 PM

Anyone else getting "Stream URL not found in reply. Stream may not be available yet." for BOS/NYY tonight?

Code:

./mlbplay.py v=bos
An error occurred locating the media URL:
Stream URL not found in reply.  Stream may not be available yet.
Traceback (most recent call last):
  File "./mlbplay.py", line 345, in <module>
    mediaUrl = m.prepareMediaStreamer(mediaUrl)
NameError: name 'mediaUrl' is not defined

Using latest svn version.

daftcat · 08-19-2013, 02:02 AM

Quote:

Originally Posted by charlie460

Anyone else getting "Stream URL not found in reply. Stream may not be available yet." for BOS/NYY tonight?

Code:

./mlbplay.py v=bos
An error occurred locating the media URL:
Stream URL not found in reply.  Stream may not be available yet.
Traceback (most recent call last):
  File "./mlbplay.py", line 345, in <module>
    mediaUrl = m.prepareMediaStreamer(mediaUrl)
NameError: name 'mediaUrl' is not defined

Using latest svn version.

NYY @ BOS was the National Blackout game tonight. Are you in US/Canada? It's possible I may have been printing the wrong error message.

For unsuccessful media requests, like the one above, mlbviewer/mlbplay will write the unsuccessful XML response received from MLB.com to the file ~/.mlb/unsuccessful-2.xml

Can you do the following for me and paste the result back here?

Code:

$ test/mediaxml.test/mediaxml.py ~/.mlb/unsuccessful-2.xml |grep -iA2 status
      auth-status:
       successStatus: None
      blackout-status:
       blackedOutStatus:
        blackout:
         #text: MLB_AWAY_TEAM_BLACKOUT
--
   status-code:
    #text: 1
   status-message:
    #text: Success Status
$

That was the last error I received (probably this morning, maybe yesterday) and it was an MLB_AWAY_TEAM_BLACKOUT (for me, A's or Giant's on the road.) If you indeed were blacked out tonight, yours will probably say something like MLB_NATIONAL_BLACKOUT.

fang2415 · 08-19-2013, 03:48 AM

Quote:

Originally Posted by thegryghost

So, I've tried to reproduce the issue with the today's (8/18) Mets/Padres. I'm using mplayer2 (git from 20130428) which can fetched as a tarball here. It's using my system-wide installed ffmpeg version 1.2.1.

Starting at the top of the 2nd:

./mlbhls -B "aHR...k=" -o tmp.ts -F "20:32:04"

mplayer tmp.ts

Everything seeks just fine. Maybe you can get me a short sample of what does/doesn't work (maybe grab the lowest possible bitrate)?

I DO NOT recommend using VLC. It's been a year or so since I last tried it but it doesn't support resolution switching and didn't support VDPAU properly.

Also, double check which version of ffmpeg you're using. Wether mplayer2 is using it's own built in version or the system-wide version. Older versions of ffmpeg were not good at dealing with MPEG-TS files and this is probably where your problem lies.

I'll try to check this when I'm home later and maybe send you a file clip, but one thing that jumps out at me is that I'm using a vanilla mplayer install from the Ubuntu repos (no mplayer2, no ffmpeg, and no patches). You're right that VLC doesn't handle resolution switching, but as long as I lock the bitrate with -L, VLC also works (plays and seeks) fine for me with the -f streams.

My thinking was that since mlbhls is obviously already able to grab streams (using -f) that a wide range of players can handle, it hopefully would be relatively easy to figure out how to make this work with -F, thereby allowing people to more easily use mlbhls with the player of their choice rather than forcing them to download and/or compile one specific player.

But of course your knowledge of mlbhls > mine, so I may well be missing some reason why that would in fact be not so easy...

thegryghost · 08-19-2013, 09:21 AM

mlbhls does nothing special to the stream. All it does is start grabbing the HLS segments, decrypts, and writes them to a file you specify. Using -f or -F is exactly the same, except with -f you're telling mlbhls to start at the beginning (segment #1) but with -F you're telling it to start somewhere that's not segment #1.

From the sounds of it, the players you're using can't handle playing/seeking MPEG-TS files that doesn't have certain information in the first X bytes of the file, most likely the PAT/PMT tables. Which is why when you prepend a few bytes from a "working" HLS stream, seeking works.

This really is a player problem. MPEG-TS is designed so that a client/player can tune in at anypoint in the stream and properly play with seeking. Most players have their own internal copy of ffmpeg (both mplayer and vlc do) and until very recently, ffmpeg didn't handle MPEG-TS files all that gracefully. I recommend mplayer2 since it forces a newer copy of ffmpeg, which can handle this stuff better.

Again, mlbhls doesn't modify the segments it gets from the server and it never will.

Quote:

Originally Posted by fang2415

I'll try to check this when I'm home later and maybe send you a file clip, but one thing that jumps out at me is that I'm using a vanilla mplayer install from the Ubuntu repos (no mplayer2, no ffmpeg, and no patches). You're right that VLC doesn't handle resolution switching, but as long as I lock the bitrate with -L, VLC also works (plays and seeks) fine for me with the -f streams.

My thinking was that since mlbhls is obviously already able to grab streams (using -f) that a wide range of players can handle, it hopefully would be relatively easy to figure out how to make this work with -F, thereby allowing people to more easily use mlbhls with the player of their choice rather than forcing them to download and/or compile one specific player.

But of course your knowledge of mlbhls > mine, so I may well be missing some reason why that would in fact be not so easy...

fang2415 · 08-19-2013, 10:39 AM

Quote:

Originally Posted by thegryghost

mlbhls does nothing special to the stream. All it does is start grabbing the HLS segments, decrypts, and writes them to a file you specify. Using -f or -F is exactly the same, except with -f you're telling mlbhls to start at the beginning (segment #1) but with -F you're telling it to start somewhere that's not segment #1.

From the sounds of it, the players you're using can't handle playing/seeking MPEG-TS files that doesn't have certain information in the first X bytes of the file, most likely the PAT/PMT tables. Which is why when you prepend a few bytes from a "working" HLS stream, seeking works.

Yeah, that makes perfect sense to me, I assumed something like that was happening.

But doesn't -f20 tell mlbhls to start at segment #20? My understanding was that if segment 20 starts at, say, 20:32:00, then -f 20 and -F 20:32:00 should produce identical streams; but for some reason -f 20 grabs streams that any player can play, while -F 20:32:00 grabs streams that only mplayer2/ffmpeg can play. That was why I suspected it might be an easily fixable bug...

Is it possible that there's a table at the beginning of each segment and that -F sometimes starts in the middle of segments? (I.e., -f 20 actually starts at 20:31:51 and -f 21 starts at 20:32:34 or some such.) If so, maybe it's just that -F values starting every X seconds will get the full table (so if X is big enough, it seems like it never works)?

I'll try to test out changing the seconds value of -F and see if that controls whether mplayer/VLC can play it...

thegryghost · 08-19-2013, 11:14 AM

Using -F just calculates segment number to start on. mlbhls subtracts your '-F' value from the he start of the playlist then divides by the segment time. So, if you specified -F 20:32:00, the start of the playlsit was 20:00:00, and the individual segment time was 6 secs. mlbhls does:

20:32:00 - 20:00:00 = 32 minutes
32 * 60 = 1920 seconds
1920/6 = 320 (segment #)

So in this case, "-F 20:32:00" would be equilviant of sending -f 320. It's most likely that vlc and regular mplayer's MPEGTS probesize isn't big enough. You can play with the --tsprobe in mplayer and see what happens.

Quote:

Originally Posted by fang2415

Yeah, that makes perfect sense to me, I assumed something like that was happening.

But doesn't -f20 tell mlbhls to start at segment #20? My understanding was that if segment 20 starts at, say, 20:32:00, then -f 20 and -F 20:32:00 should produce identical streams; but for some reason -f 20 grabs streams that any player can play, while -F 20:32:00 grabs streams that only mplayer2/ffmpeg can play. That was why I suspected it might be an easily fixable bug...

Is it possible that there's a table at the beginning of each segment and that -F sometimes starts in the middle of segments? (I.e., -f 20 actually starts at 20:31:51 and -f 21 starts at 20:32:34 or some such.) If so, maybe it's just that -F values starting every X seconds will get the full table (so if X is big enough, it seems like it never works)?

I'll try to test out changing the seconds value of -F and see if that controls whether mplayer/VLC can play it...

fang2415 · 08-19-2013, 11:40 AM

Quote:

Originally Posted by thegryghost

Using -F just calculates segment number to start on. mlbhls subtracts your '-F' value from the he start of the playlist then divides by the segment time. So, if you specified -F 20:32:00, the start of the playlsit was 20:00:00, and the individual segment time was 6 secs. mlbhls does:

20:32:00 - 20:00:00 = 32 minutes
32 * 60 = 1920 seconds
1920/6 = 320 (segment #)

So in this case, "-F 20:32:00" would be equilviant of sending -f 320. It's most likely that vlc and regular mplayer's MPEGTS probesize isn't big enough. You can play with the --tsprobe in mplayer and see what happens.

Thanks, that's really helpful info. I'll have a play with that in mind and post if I find anything useful...