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.
A new version of rtmpdump, 1.5, came out today. I can actually play an archived stream while I'm dumping it now. I have added my FCSubscribe patch to it (by hand ), but I can't test it until tonight.
If anyone is downloading rtmpdump, please download version 1.4 until I have tested 1.5 with mlbviewer.
Thanks for the suggestion, I'll certainly give it a whirl. I had to watch yesterday's Phillies v Marlins game on my web-book hooked to my HDTV. It was painful - best I could get out of the flash player was two bars.
Just wondering - what is the reason why streaming with mplayer via mlbviewer the feed looks wonderful, yet via the Flash Player (on Ubuntu or Windows) it's largely awful?
I'm pretty sure we have for a while...unless your talking about some super sweet new video follow. Last few SVN releases I've had video_follow=pit in my config and it's giving me the rights streams. I know this because I've decided to comment it out a couple times to get the opposing HD stream.
Yeah, video_follow works great and with the patch I checked in this morning for the empty content list bug, it should be working absolutely wonderful now. But yes, as poorboywilly pointed out, it works a little too well sometimes. ;-) Plus, I have absolutely no idea how it works if you have two video_follow teams playing each other. I imagine the last match checked would be the stream I go with.
In the next revision, whenever I get around to finishing it, I'll have video_follow override that will let you let you select streams by the call letters so you can find the HD stream if HD makes you happier than having your favorite broadcast team. ;-)
Initial testing of rtmpdump 1.5 shows basically no performance improvement over 1.4, at least in terms of live games. Archived games also still go balls-to-the-wall and crap out around 40%. The developer mentioned in the forum that he thinks the server might believe we need some processing time and backs off from sending. It would be nice if he could implement a more sane streaming speed for archived games since live games don't suffer from this limitation.
Theophile, do you think this might be another video container/ffmpeg bug we could file? I'll have soapevent.py and the rtmpdump-patches updated for rtmpdump 1.5 later tonight if you want to post another reference file to the ffmpeg team.
I suspect I'm a lot closer than I think to meeting my wishlist for this week's revision but I'm not sure if I'll get much development time tonight. Tonight's a dancing night. (I sometimes do things other than coding or watching baseball. ;-)
EDIT: Ooooh! Hold the phone. 1.5 has the ability to stream to stdout instead of a dump file. This deserves some more investigation.
+ Experimental rtmpdump video support: same as gameday audio support and same as mlbdvr except, at least for me, it's so embarassingly bad that I may just rip it out and make you non-premium users a downloader script separate from mlbviewer.
just a note. i for one am a premium subscriber, but the way nextdef keeps going down (i.e swarmcast server problems), I wouldn't mind having the standard feeds available if i need them. at times, nextdef will just shut off on me, and if I try to log in too quickly I get a concurrent login error.
like right now, i keep getting 'flash packet error' than mplayer quits. i think it has to do with mlb's server (hopefully)
just a thought
can't wait for the new svn. things are coming along so nicely
Last edited by edouble312; 04-27-2009 at 07:18 PM.
My bad on the video follow. I had a typo in my config file. :-[
As far as rtmpdump, it very well could be a container thing. When I was first testing those files, I noticed that the flv container was reporting width of 400 and height of 450. This raises the question of what exactly rtmpdump is doing. The ffmpeg guys will need to know this as well. The autobahn plugin merely gives access to the server stream with no processing. But if rtmpdump is doing any processing, such as setting container attributes or the like, that will be part of the troubleshooting chain.
just a note. i for one am a premium subscriber, but the way nextdef keeps going down (i.e swarmcast server problems), I wouldn't mind having the standard feeds available if i need them. at times, nextdef will just shut off on me, and if I try to log in too quickly I get a concurrent login error.
like right now, i keep getting 'flash packet error' than mplayer quits. i think it has to do with mlb's server (hopefully)
just a thought
can't wait for the new svn. things are coming along so nicely
Swarmcast is usually very good but it has its moments. Rtmpdump is usually pretty bad but it has its moments (archived games.)
The big difference is that swarmcast seems to be improving. I can't really say the same about rtmpdump.
A few things I plan on implementing to make swarmcast a bit better are:
+ stream selection on the fly (kind of like setting max_bps on the fly)
+ stream shifting (requesting specific streams, not just max_bps, during playback) - not sure if this will even work but it's something I'd like to test
+ jump to innings - this will be huge for me when swarmcast decides to go out on me after 7 innings (happened to me much of the weekend), I can pick up from the last inning I watched
+ true session support - login once at startup, logout once at closing, refresh cookies and keys as necessary (this should fix the concurrent login issue, though I suspect this has more to do with mixing the website with mlbviewer, e.g. trying to use two different cookies/keys)
For the last one, I could probably dump the cookies/keys if I get a "concurrent login" error so that you can start fresh again.
As for rtmpdump, well, it may never get any better than it is today with mlbdvr.py and soapevent.py.
My bad on the video follow. I had a typo in my config file. :-[
As far as rtmpdump, it very well could be a container thing. When I was first testing those files, I noticed that the flv container was reporting width of 400 and height of 450. This raises the question of what exactly rtmpdump is doing. The ffmpeg guys will need to know this as well. The autobahn plugin merely gives access to the server stream with no processing. But if rtmpdump is doing any processing, such as setting container attributes or the like, that will be part of the troubleshooting chain.
We may be able to get the XBMC guys to help with the troubleshooting since rtmpdump is based off their LibRTMP code.
I believe the stream characteristics are part of the createStream response and are printed in the debug for rtmpdump. I don't think rtmpdump is doing any real processing of the stream or the dump except when it needs to find key frames for resuming.
At least for the swarmcast streams, the characteristics are in the content description so I could print those to the screen. Right now I just print the current stream and the millisecond value but I could certainly cache a content description and match the selected stream with its description and print the stated characteristics on the screen. You can then use -dumpstream to produce an output file and see if the stated characteristics and actual characteristics are correct. I mean we could certainly use an improvement or two on mplayer/ffmpeg support of nexdef as well as rtmpdump.
I would love to see mplayer support so good that I can seek the streams without fear of putting mplayer in an errored frame loop. There have been several plays where I would have loved my own instant replay but feared losing the stream.
Anyone having issues keeping a steady stream tonight? I know nexdef is having issues because half the games on my windows machine and using flash either wont load or nexdef doesnt work for them. I get about 12 to 13 minutes of a stream with mlbviewer and mplayer. I did so a 'svn up' for mlbviewer to get the 2 fixed files and I did a 'svn checkout' for mplayer. Nothing seems to be working though as far as keeping a constant stream.
I did just reboot my machine to see if that was the issue since it was on all day. Will update if I get past 12 minutes of steady stream.
EDIT: Silly me, looks like all I needed was to reboot. All is good again in the world of Takabru.
I might get you guys some new code tonight/tomorrow morning.
I've been testing sending the control messages to nexdef which I just wanted to see if I was getting the stream I requested.
What I found was far more interesting.
First, even though I say I support up to 3000K, I only ever get the 2200K stream. I'm okay with that because it's beautiful!
But...
Tonight it's been shifting on me. I started the Royals game getting only the 600K stream and before I could groan about it too loudly, it switched up to 2200K. Then after awhile, it shifted down to 1200, and shortly shifted back up to 2200K. Mplayer seems to be doing well with the shifting and my stream is doing alright at staying up. I bet this is the same as "auto-adjust", but I wonder if the control messages are also useful for keeping the stream up.
Well, I'll finish up some code in progress tonight. It won't be everything on my wishlist but I want you guys to test with this to see if it improves your nexdef stability.
So we all know that Linux is lighter on the system requirements than Windows -- one of the most attractive qualities of Linux.
However, this year's mlb.tv offering seems to be much more resource intensive than last year, especially with the nexdef support.
So, I want to try to formulate system requirements suggestions.
Please tell me (my answers inline):
1. What specs do you have: CPU / RAM
Code:
1.5 Ghz , 1.5 Gb RAM
2. Nexdef or rtmpdump?
Code:
Nexdef til you wrestle the autobahn.jar from my dying hands. ;-)
3. Peak hours experience (7:00 - 11:00 ET?) e.g. when the majority of live games are in progress
Code:
Mostly very positive but occasional stream drops. Not enough to be super-annoying.
4. Off-peak hours experience (when the majority of the games are completed/Archived):
Code:
Almost perfect but occasional stream drop after 7 or 8 innings. Now that's annoying.
5. Overall better experience than Windows plus Flash player (if you dual boot)?
Code:
Definitely!!!
6. Preferred stream (or max_bps setting since you probably don't know yet which stream you're actually getting)
Code:
2200K - Beautiful - way better than TV :-)
The more of you who answer these questions, the better I can try to recommend minimum requirements. While I think mlbviewer plus nexdef can kick Windows butt for system requirements/performance, I don't think it's going to be a slam dunk for low end machines. That's why I'd like to get a better idea of how you experience it and what hardware you're using.
Nexdef til you wrestle the autobahn.jar from my dying hands. ;-) I like nexdef not sure how to use rtmpdump so no opinion.
3. Peak hours experience (7:00 - 11:00 ET?) e.g. when the majority of live games are in progress
Code:
Very good with mlbviewer. I do have some issues with games dropping after 10 minutes or so but I think that is nexdef and all the messing around they are doing with the code to get it to work properly with Flash on Windows.
4. Off-peak hours experience (when the majority of the games are completed/Archived):
Code:
Excellent on off-peak hours. I get full HD on my laptop with no stuttering or freezing.
5. Overall better experience than Windows plus Flash player (if you dual boot)?
Code:
Definitely!!! Oh yes, I use both on two machines just to compare and mlbviewer on linux wins hands down. The quality is far superior then flash.
6. Preferred stream (or max_bps setting since you probably don't know yet which stream you're actually getting)
Code:
I was running 2200k but I found it pixelly and blurry. I then set the max_bps=3000000 and WOW what a difference. I have HD Cable and you know I cant tell the difference between the HD cable and mlbviewer. They look exactly the same.
Overall I am totally sold on mlbviewer. It is by far superior to Flash. Great job and I cannot wait for an update with even more features.
Takabru - a satisfied customer.
Last edited by Takabru; 04-27-2009 at 11:24 PM.
Reason: Add questions
7. Do you feel like your system is sufficient for mlbviewer plus nexdef (or rtmpdump)?
Code:
For off-peak, I feel my 750x256 is almost sufficient for 800K. I think a lot of stream drop offs could be prevented with a bit more RAM.
Overall, though, I believe my 1.5 x 1.5 is sufficient for HD (at least 2200K.)
7. Do you feel like your system is sufficient for mlbviewer plus nexdef (or rtmpdump)?
Code:
My laptop is a travelmate 2300 with a 1.5ghz intel celeron cpu and 1 gig or ram. I have cable that has the potential to run up to 15Mbps, although, at peak hours its more like 5-8Mpbs. I have no issues running at max_bps of 3000000 on the laptop. Let me tell you the picture coming through is very, very close to HD. Like I said above you can barely tell the difference from my HD cable. So, I would conclude the mlbviewer plus nexdef works just fine. There are issues with nexdef itself but that is something that cannot be controlled.
I am new to all this so I am unsure what rtmpdump can bring to all this. I would need to actually use it to give an opinion.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.