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.
non premium user here. I would upgrade only if I'm sure that obtained video are playable with my old pc: p4 with 1G Ram and no vdpau; some of the video took around 85% of my cpu not to talk about flash player...
The major feature I care is to be able to download archived games and watch them later, being that I live in Italy and those dumbass majorleaguers don't want to play games early in the morning
Oh, yesterday mlbdvr managed to let me watch this way Reds @ Brewers, so it seems to work. If I'll have time next week I'll try and play with autobahn and my non premium account.
Try the autobahn.jar and update your mplayer to the latest version (the fix came in yesterday) and see if autobahn is an option for non-premium users. In the latest mlbviewer svn there is a nexdef.py script which acts like soapevent.py except returns the nexdef url. There is a parameter in the url (max_bps=2500000.) Search nexdef.py for max_bps and replace with 800000. Let me know if that works with your system.
Okay, so I did everything you said (it takes forever for mplayer to build on my system). Now how do I actually try to watch a game with autobahn running. Pressing enter in mlbdvr just starts dumping with rtmpdump same as before. What do I need to do?
A few quick comments, which may, or may not, help:
1) Regarding the highest bandwidth stream via NexDef. For games where MLB have no HD feed from the broadcaster, the "best" stream is indeed 800x450 res, 2200bps, but for games where they have an HD feed from the broadcaster, it is 1028x720 res, 3000bps.
2) It seems there are two http requests sent to the NexDef plugin, firstly
http://local.swarmcast.net:8001/protected/content/adaptive-live/describe/base64:<base64 string>?mlbfpk=<user id string>&refetch=true
which should return an xml file detailing which streams are available for that feed (including whether or not there is a 3000bps stream). This sometimes takes a couple of retries to succeed, but once it has succeeded the subsequent request will then work. The second http request is:
http://local.swarmcast.net:8001/protected/content/adaptive-live/base64:<base64 string>?mlbfpk=<user id string>
To this request further parameters can be added (using &<parameter name>=<parameter value>), including start_time which specifies the time in milliseconds since midnight Eastern Time from which to start the stream (this is needed for playing archive games, if omitted it starts from time now, useful for live games), encoding_group which is a list of streams to be selected from (I think that only listing one will turn off the adaptive bit, and just give you that stream), these are as listed in the xml file returned by the previous request, for example, the HD stream for the exhibition at Yankee stadium on April 4th, MLB_GAME_VIDEO_CHNNYA_HOME_20090404_MLB_FLASH_3000K_STREAM, and max_bps which you have already investigated. I think there is also an end_time which may be necessary for archive games. By the way, start time and end time are both available from the epg.xml file for that day.
The <user id string> which follows mlbfpk seems to be a unique string to identify that user, which doesn't seem to change from one time to the next. The <base64 string> is a base64 encoded string that contains a URL along these lines:
As you already have the ipid (which presumably only changes if you change your IP address), session key (which rarely changes, depending how you use it), and content id (which can be found on the multimedia page), it should be possible to construct this URL (and then base64 encode it) without having to refetch it from mlb.com. And then, if you have the user id string from a previous request, you should be able to construct the two http requests to send to NexDef without having to go through all the complicated SOAP requests.
Finally, if you wanted to be really clever, I think that start and end times of individual half innings are available from an xml file which can be deduced from the cid in the epg file.
Okay, so I did everything you said (it takes forever for mplayer to build on my system). Now how do I actually try to watch a game with autobahn running. Pressing enter in mlbdvr just starts dumping with rtmpdump same as before. What do I need to do?
Nexdef isn't in mlbdvr yet. In the test directory, there is a nexdef.py script. Edit it and search for the string max_bps=2500000 as part of a long url and change that to max_bps=800000.
You may also want to change the DEFAULT_PLAYER line at the top to:
DEFAULT_PLAYER=mplayer -autosync 30 %s
My system wasn't liking the record and play at the same time so I figured I'd just play straight off the live stream.
Lastly, and most importantly, since I haven't put much effort into figuring out nexdef, nexdef.py only works with live games. Use mlblistings.py to find the event id of an In Progress game to test with.
This weekend I'll have nexdef support integrated into mlbdvr.
If someone could give me a hand, I'm really close to having this working, but am running into one problem.
I believe I have set everything up correctly to run the program. when the archived game starts playing in mplayer, the video comes out veeery slowly. it will play a few frames, stop, play a few frames, stop etc.... If i load the stream with VLC (just open it from the mlbdvr_games folder), it plays just fine, but the picture quality is much better with mplayer. I am using the latest svn of mplayer and mlbviewer, so i'm basically stumped. any help would be great
If someone could give me a hand, I'm really close to having this working, but am running into one problem.
I believe I have set everything up correctly to run the program. when the archived game starts playing in mplayer, the video comes out veeery slowly. it will play a few frames, stop, play a few frames, stop etc.... If i load the stream with VLC (just open it from the mlbdvr_games folder), it plays just fine, but the picture quality is much better with mplayer. I am using the latest svn of mplayer and mlbviewer, so i'm basically stumped. any help would be great
As daftcat said, dumping the stream and playing it at the same time is pretty iffy.
I just dump the stream and then play it separately like you mentioned you were. That's probably your best bet right now. You can start another mplayer to view the stream instead of using vlc.
A few quick comments, which may, or may not, help:
1) Regarding the highest bandwidth stream via NexDef. For games where MLB have no HD feed from the broadcaster, the "best" stream is indeed 800x450 res, 2200bps, but for games where they have an HD feed from the broadcaster, it is 1028x720 res, 3000bps.
2) It seems there are two http requests sent to the NexDef plugin, firstly
http://local.swarmcast.net:8001/protected/content/adaptive-live/describe/base64:<base64 string>?mlbfpk=<user id string>&refetch=true
which should return an xml file detailing which streams are available for that feed (including whether or not there is a 3000bps stream). This sometimes takes a couple of retries to succeed, but once it has succeeded the subsequent request will then work. The second http request is:
http://local.swarmcast.net:8001/protected/content/adaptive-live/base64:<base64 string>?mlbfpk=<user id string>
To this request further parameters can be added (using &<parameter name>=<parameter value>), including start_time which specifies the time in milliseconds since midnight Eastern Time from which to start the stream (this is needed for playing archive games, if omitted it starts from time now, useful for live games), encoding_group which is a list of streams to be selected from (I think that only listing one will turn off the adaptive bit, and just give you that stream), these are as listed in the xml file returned by the previous request, for example, the HD stream for the exhibition at Yankee stadium on April 4th, MLB_GAME_VIDEO_CHNNYA_HOME_20090404_MLB_FLASH_3000K_STREAM, and max_bps which you have already investigated. I think there is also an end_time which may be necessary for archive games. By the way, start time and end time are both available from the epg.xml file for that day.
The <user id string> which follows mlbfpk seems to be a unique string to identify that user, which doesn't seem to change from one time to the next. The <base64 string> is a base64 encoded string that contains a URL along these lines:
As you already have the ipid (which presumably only changes if you change your IP address), session key (which rarely changes, depending how you use it), and content id (which can be found on the multimedia page), it should be possible to construct this URL (and then base64 encode it) without having to refetch it from mlb.com. And then, if you have the user id string from a previous request, you should be able to construct the two http requests to send to NexDef without having to go through all the complicated SOAP requests.
Finally, if you wanted to be really clever, I think that start and end times of individual half innings are available from an xml file which can be deduced from the cid in the epg file.
I had better add that, on further inspection, the <user id string>, mlbfpk parameter, does change occasionally, but its value is the same as the fprt cookie which appears in the login process. This also means that the http request sent to the NexDef plugin can be entriely deduced from the login process and the multimedia page.
As daftcat said, dumping the stream and playing it at the same time is pretty iffy.
I just dump the stream and then play it separately like you mentioned you were. That's probably your best bet right now. You can start another mplayer to view the stream instead of using vlc.
ok thanks, good to know I wasn't doing something wrong.
great work btw to everyone involved...
Last edited by edouble312; 04-17-2009 at 05:24 PM.
I had better add that, on further inspection, the <user id string>, mlbfpk parameter, does change occasionally, but its value is the same as the fprt cookie which appears in the login process. This also means that the http request sent to the NexDef plugin can be entriely deduced from the login process and the multimedia page.
Actually, the content-id's are only available through the SOAP request.
By multimedia page, do you mean the MLB Media Center web page? I don't and I won't parse web pages. I'll do json (for previous years), xml, and soap because those have definite structures (even if raw xml is open to a fair amount of interpretation), but I won't parse raw html (beyond looking for keywords like "logged in" or "unsuccessful".)
Besides, the entire base64 string plus the mlbfpk parameter can be retrieved from the SOAP request for the SWARMCLOUD media item. There is a lot of information in the SOAP replies and now that I've stopped being so lazy about parsing them, we're actually doing pretty good--not getting the JiBX marshalling errors anymore. In fact, I rather prefer the SOAP requests/responses to the raw xml because the WSDL/XSD defines the structure of the requests and responses quite well and suds handles all the parsing details for me.
I do appreciate the effort you put into decoding all this, though. I will have to look at that first request more carefully and the innings index to see how to implement proper throttling and seeking of live and archived games.
If we can do without rtmpdump for video, I wouldn't mind ripping all that "dvr" code out and just fork off something just for the gameday audio users until mplayer or vlc supports rtmp natively.
No problem. Follow this guide, with one exception: In the section called "Download the 'Development' Files," rather than running that huge command which probably won't work, do this instead:
Code:
sudo apt-get build-dep mplayer
This will install the development dependencies for compiling mplayer from source.
In addition, the section called "Live555" is optional, as is the last section on SMplayer.
Finally, if you're like me, you don't want two different version of mplayer on your system. If you follow the above-linked guide, it will keep the default Ubuntu build of mplayer in /usr and install the bleeding-edge version in /usr/local
If you want to replace the Ubuntu version (you do), then look at the commands in the section titled "Download and Compile the svn mplayer." Change the ./configure line to this:
THen run the 'make' command as stated. After 'make' finished but before you run 'checkinstall,' execute this command:
Code:
sudo apt-get remove mplayer mencoder
Then run 'checkinstall' as the guide says. Compiling mplayer from source will provide mplayer and mencoder in one large package, rather than splitting it between two packages like Ubuntu does by default.
For the sake of clarity, following the above instructions will make the "Download and Compile the svn mplayer" section look like this:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
