How to watch fansubs with your mac.

[Nishi]

Originally Posted by Craymel

You should be able to disable subtitles by pressing v on your keyboard.

Not working...

[Craymel]

Originally Posted by Nishi

Not working...

Woops didn't read your post close enough thought you were using mplayer.

[Ledgem]

Originally Posted by Nishi

I'm sorry if this sounds like a total noob question...

So, I can play .mkv files just fine in QuickTime with Perian... but I can't figure out how to turn off the subtitles! There should be a way since they are soft subs, but I'm not finding any options under View menu either.

I'm on Mac OS 10.5 if that helps. I've been using gg's mkv subs. I know there are other players to watch them with, but I'm trying to stick with QuickTime so that I can export the .mkv files without the subtitles into QuickTime format to make AMVs, and I really don't want to have to go downloading raws.

Any help would be appreciated. Thanks!

I think a year or so ago I had the same issue. The solution was to upgrade to Quicktime Pro - sadly, I don't think that Quicktime alone will allow you to turn off softsubs. If you have the time, scan over some Google results to see if there's a workable solution in there. A suggested solution from the first link:

Command+j, uncheck the subtitle video track.

[Solecs]

This is a bit odd, but I suddenly can't play HD video on my macbook pro. I know for a fact my computer is capable of playing at least 720p smoothly since I watched an episode of anime that was 720p just a week ago. I've been using MplayerOSX extended and I'm suddenly getting big cpu usage spikes that didn't happen before.

The only things I can think of that changed in the last week were a software update (some airport express update I had been putting off) and the fact that my battery is starting to fail (I'm running off the AC adapter right now). I don't think either of those should be causing a problem with video playback though.

Anybody else been having this problem lately? I'm guessing it's something specific to my computer though, hoping somebody might have some idea. The only other way I can think of to resolve the problem is a clean install, in case some bit of software I might have downloaded is borking it somehow. Thanks for any help.

[Ledgem]

Does it do that with all HD videos, or just one particular 720p video? When you start playing a video, open the Activity Monitor and sort by CPU utilization. Is there anything unusual using a lot?

You might want to try rebooting and see if that stabilizes anything. I'd also recommend possibly using a different player or build of MplayerOSX to see if maybe an update is slightly incompatible with the current version you're using (although I don't know; just a guess).

[Solecs]

That was quick, thanks for the reply . I just tried restarting and that doesn't seem to help any, unfortunately. I also tried using a build of mplayer compiled from a fresh source from the svn repository which was a no go too .

According to activity monitor, mplayer is the only process really using CPU time. While playing, the service "mplayer window" is showing around 90 for CPU. Looks like it's maxing out one of the cores (this is a Core Duo Macbook pro). That is for any video that is 1280x720. SD video seems to be around 30 for the most part, as far as I can tell.

It seems like the problem is mostly affecting video, since the audio comes out right. Video looks smooth enough, but it's way behind the audio. I tried fiddling with the playback speed, but all it did was speed up and slow down the audio. The video remained pretty much the same.

[sk3]

Thats a real strange problem Solecs, i never had it before. try trashing your preferences file and see if it helps just in case something got corrupt or you changed something you shouldn't

[Solecs]

Is this the preferences file in the preferences folder in the home directory? If that's the file, then it doesn't seem to be the problem either :-/.

I have discovered something interesting though. The problem seems to be mplayer. Using VLC player the files play back fine, minus softsubs. And this shows around 100% for CPU time. Alternatively, I can use Quicktime+perian which utilizes about 150%. (o,O). I never knew that quicktime ran with dual threads and all that.

It seems that for the time being I can use the QT+perian solution, though I'd like to get things sorted with mplayer since it is still my preferred player. Thanks for all the replies so far .

edit: well, QT+perian mostly works. Still looks a little choppy, and the video quality seems a bit lower I think...maybe. Watchable at least, though.

[sk3]

You are using the mplayer extended right? i still have some bugs with that version but everything works like a charm without much problems. can give you another version of mplayer made by other members that worked perfectly without much problems, so you can see if that helps.

If Perian+QT works that means mplayer is at fault, but must be some bug because you have core duo maybe. core duo and core 2 duo are suppose to play h264 720p flawlessly i think.

You could always try and change the video output options from mplayer to check for a difference too.

[Discerptor]

Is this all HD videos or only a certain one? If more than one, what codec and file container are being used for the video? If it's not encoded with x264 (i.e. it's one of Apple's trailers or something and not anime), try adding in the options

-lavdopts fast:threads=2

(or instead simply checking the "fast libavcodec" box in MPlayer OSX Extended's Video preferences if you're using that program). Also try deleting MPlayer OSX (Extended) from your computer completely and re-downloading it in case by some ridiculously low chance a file got corrupted and caused this. Finally, as a holdover until you can get your issue fixed if this is indeed x264-encoded videos you're having trouble with, use this set of options (in addition to whatever else you have):

-lavdopts fast:skiploopfilter=nonkey:threads=2

[Solecs]

As far as I can tell this is all HD videos, and all I've been trying to play is anime. All the files are in MKV format, and I assume they're encoded with x264.

Using the additional decoder options doesn't seem to have any effect, oddly. I remember using those options when trying to watch some 1080p anime a while back, and they worked pretty well despite needing to drop a few frames. The video seems unchanged in this situation though. I also gave MplayerOSX extended another download, but that doesn't seem to be the issue either.

For now I'm using quicktime+perian, and that's going ok. Still a little bit choppy, and I can't see softsubbed karaoke (not a big deal :-/). I tried VLC as well, which ran a little better, but it was causing some pretty bad video artifacts. I'm going to try compiling a new version of mplayer in the near future to see if that helps. Otherwise I'll just mess around with things until it hopefully works. Thanks for all of the advice so far.

edit: forgot to mention I tried changing the video output options like sk3 suggested, but that didn't seem to fix the issue either .

[Discerptor]

Did you make sure to uncheck the fast libavcodec box when you wrote those extra parameters? If you check the box, it overrides the lavdopts options you write into the miscellaneous box yourself if I recall correctly.

[Solecs]

I think I've figured out what the problem is and finally have a set of parameters that makes things playable again. I'm hoping somebody more knowledgeable might be able to figure out why this works and what is causing the problem.

The apparent cause is that mplayer is throwing in an extra video filter for converting the colorspace. When just trying to play a video file with no additional parameters it says something like this:

VDec: vo config request - 1280 x 720 (preferred colorspace: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
SwScaler: reducing / aligning filtersize 1 -> 4
SwScaler: reducing / aligning filtersize 1 -> 4
SwScaler: reducing / aligning filtersize 1 -> 1
SwScaler: reducing / aligning filtersize 5 -> 4
[swscaler @ 0x8016c0]BICUBIC scaler, from yuv420p to yuyv422 using MMX2
[swscaler @ 0x8016c0]using 4-tap MMX scaler for horizontal luminance scaling
[swscaler @ 0x8016c0]using 4-tap MMX scaler for horizontal chrominance scaling
[swscaler @ 0x8016c0]using n-tap MMX scaler for vertical scaling (BGR)
[swscaler @ 0x8016c0]1280x720 -> 1280x720
VO: [macosx] 1280x720 => 1280x720 Packed YUY2

So I decided to play with various parameters and ended up adding the following:

-vf ass,yuy2

The "yuy2" part supposedly forces a fast software conversion between yv12->yuy2 and the "ass" part makes it play nice with the "-ass" parameter by making mplayer render subtitles before converting the colorspace. This was still a little bit slow, so I added the "-lavdopts" parameters and I think I'm good to go. Output now says something like this:

VDec: vo config request - 1280 x 720 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [macosx] 1280x720 => 1280x720 Packed YUY2

Most of my 720p stuff now plays back about normally, it varies a little from file to file and sometimes needs some frame dropping. Additionally, CPU usage has dropped to around 75% from 90% on average for mplayer. I still have no idea why I have this problem all of the sudden, but at least it more or less works now.

[Solecs]

Apparently the problem was, in fact, the battery. I finally forked over the $100 for a new battery, and everything plays fine now. My guess is that playing the video needed more power than just the adapter could give, so it needs some power from the battery or something.

That said, using the "-vf ass,yuy2" filter still reduces cpu usage. I guess finding that out was somewhat worth all of the headache :-/. Thanks for all the suggestions while I was trying to figure this out .

[sk3]

Solecs, great to hear that your problem is solved

And by the way, the problem you had is just normal i guess. IMHO apple laptops, when running without battery, voltage and cpu frequency is reduced. I have read something about that in apple knowledge base but can't find it right now to show you.

[Solecs]

After some searching it looks like you're right, the article in question is http://support.apple.com/kb/HT2332. I wish they would have made that more readily known, would have saved me some trouble :-/.

I don't imagine it's common to run without a battery though, I just happened to have a dead battery. Otherwise I don't think I'd ever run into this, oh well. Learn something new everyday I guess .

(Though I have to wonder why they couldn't just design the computer or power adapter to be able to handle all loads...)

[fyleow]

Does anyone have the new unibody Macbook or MBP? It's suppose to have a version of Mplayer which does hardware h.264 decoding. Does this work with Perian?

[Ryoujin]

Originally Posted by fyleow

Does anyone have the new unibody Macbook or MBP? It's suppose to have a version of Mplayer which does hardware h.264 decoding. Does this work with Perian?

There are no Mac models that come bundled/pre-installed with MPlayer.

There is MPlayer Extended, you might want to check over here:

http://forums.animesuki.com/showthread.php?t=70005

Also, we might see some sort of performance boost when Snow Leopard comes out.

[Epyon9283]

Originally Posted by fyleow

Does anyone have the new unibody Macbook or MBP? It's suppose to have a version of Mplayer which does hardware h.264 decoding. Does this work with Perian?

Only Quicktime has support for hardware h264 decoding on the new macbooks AFAIK. If you install perian and it does the h264 decoding you lose the hardware acceleration.

[fyleow]

Ugh yeah, by Mplayer I meant Quicktime. Not sure how that slipped in there.

I guess that makes sense since there's no option in the Perian settings to select which h264 decoder to use.