Quote:
If you have the patch, then I'm not sure what's going on because I've done enough quit/restarts and simultaneous sessions that I should have been flagged by now. But I haven't been locked out all day since I implemented the change. As for seeking, well, that's pretty much an mplayer/ffmpeg problem and not really anything to do with mlbviewer. There's nothing I can do in my code to help with that. As I said before, if it's something you want, I'd recommend either trying a new build of mplayer2 or logging a bug with mplayer2 team and including a sample file. They have fixed bugs for us in the past. |
Quote:
Quote:
|
Aha... I just tried running mlbhls manually with the last link from my .mlb/log (these links seem to work forever in spite of sign-on restrictions!). I tried both the adaptive and the fixed-rate and mplayer can play both with no problems -- sound and scanning both work just fine. I even downgraded back to mplayer 1 and it plays everything fine, except for the crashes when seeking back through a speed change. So this makes me wonder if there's something funny about the options that mlbviewer is passing to mlbhls.
Here's what I ran manually: Code:
mlbhls -B [base 64 link] -b 1200000 -f 48 -o mlb/video.ts It's way past my bedtime here so that's all I can do today, but hopefully that'll help make sense of whatever's going on... |
Quote:
http://theebuilds.googlecode.com/svn...player2/files/ You'll probably want to apply: fix_ts.patch <version>/demux_ts_h264.patch <version>/mp2_new_live_seek.patch Depending on the version of mplayer2 you're using will determine which patch to use. A couple months ago the ffmpeg guys changed their API's and broken everything that linked against it. So, depending on which ffmpeg you have installed will determine which version of mplayer2 to use. If you're using mplayer2 from svn, try the patches from "2.0_p20111126", if they don't apply I can update them. You can ignore the other patches, I use mplayer2 to drive my HTPC so they aren't relevant to playing mlb.tv streams. My mplayer2 cmd: Code:
mplayer2 -fs -vc ffh264vdpau, -vo vdpau:fps=60:deint=0:denoise=1:hqscaling=1, -livepause 6 -cache 4096 -demuxer mpegts -mc 20 <mlb.ts>" Let me know if you have any problems. |
Quote:
I'm not sure why you are restarting mlbviewer so many times. Is there something missing from the interface that would save you the restarts? That said, I have tested the following without encountering sign-on restriction: 1. Multiple mlbviewer restarts in a short period of time. 2. Multiple instances of mlbviewer. 3. Multiple start/restart of streams without quitting mlbviewer. 4. Multiple start/restart of streams separated by hours of time without restarting mlbviewer (this is mostly just to prove that session information received in the morning is still valid later in the afternoon.) |
One suggestion I might have is to remove ~/.mlb/cookie and ~/.sessionkey
Do this ONCE after your restriction has been lifted. Clearing these files on a regular basis is a surefire way to reproduce this issue as the server is, in essence, saying, "I already gave you cookies and session keys. Why do you keep asking for new ones?" |
Quote:
Daftcat, I have one further suggestion relating to this, which seems to work well. I normally watch in full-screen mode, and I have found that vlc and mplayer hang if mlbhls changes speeds when they are showing in full-screen mode rather than as a windowed display, so if I use mlbhls I use it in fixed bitrate mode. You can of course do this perfectly well with the standard stream, but the standard stream drops out once or twice a game, whereas mlbhls seems fault resistant. This can be important if you are, say, watching an archived game in extra innings which you can't select to get back into. mlbhls also of course allows you to change audio streams. What would be useful when mlbviwer is using nexdef with a fixed bitrate is to be able to use the P key to cycle through max_bps speeds, say at 400k increments. This would mean using a key other than P to switch between adaptive mode and fixed bitrate mode, but would avoid having to exit mlbviewer and amend the config file in order to change speeds. |
Quote:
|
2 Attachment(s)
Quote:
This works for my needs, but a more sophisticated approach is to display the speed instead of [--] when in nexdef fixed bitrate mode, and to be able to toggle that with the 'p' key in the same way as when using the standard streams. That would require using a different key (say the 'f' key) to toggle between fixed and adaptive modes. As the 'n' option isn't documented by the help key, I attach a patch for that also. |
Hmmm, I just got a sign-on restriction error after choosing different innings in one game and switching between standard and nexdef modes. I did not close down mlbviewer between switching innings and modes, so something else still seems to prompt MLB.TV's lock-out mechanism sometimes.
I will do more playing around. When I tried it last night the new login was working fine. |
Quote:
I'll try to avoid re-opening mlbviewer excessively, although from Chris's comment it seems like there may still be some issues... I'll test later if I can. |
I'm headed out now but just one more note before I go: I do think that the issue I'm having with the players is due to the options that mlbviewer passes to mlbhls. It looks like mlbviewer runs the following mlbhls command, and when I run it manually from the command line, I get the same behavior where my players can't play the file properly:
Code:
mlbhls -B [link] -L -s 1200000 -F 16:00:12 -o mlb/video.ts Code:
mlbhls -B [link] -L -s 1200000 -f 48 -o mlb/video.ts HTH |
Quote:
Code:
mplayer2 -lavdopts threads=1 Code:
Width/height/bit depth/chroma idc changing with threads is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. |
Quote:
Code:
svn info |
Quote:
At the moment, there is no hotkey to reload the configuration. Might be easy enough to add though. I'll look into that. |
All times are GMT -5. The time now is 06:46 AM. |