Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
SVN revision 524: Changes to RTMP requests, possible fix for archived
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.
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.
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.
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:
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...
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?
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!
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 .
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
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?
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.
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...
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...
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...
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:
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...
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:
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...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.