New Benchmarks of the Most Recommended MKV Players

Discussion in 'iPad Apps' started by Menneisyys2, Dec 1, 2013.

  1. Menneisyys2, Dec 1, 2013
    Last edited: Dec 5, 2013

    Menneisyys2 macrumors 603

    Joined:
    Jun 7, 2011
    #1
    UPDATE (05/Dec/2013): now, with yesterday's release of Infuse 2, I'll completely rewrite this entire guide as "The MKV Bible" and make it far more verbose. You may want to wait for that article instead of reading on. Nevertheless, if you need player-specific info on MKV playback performance now, feel free to read this article below as it already has a lot of interesing info. However, don't forget that the final MKV bible will be even better. Also, in the meantime, I've published a lot of Infuse 2 benchmarks in its own thread, from page 2: see THIS I don't incorporate that information to this old article. However, in the forthcoming MKV bible, I will.

    The original article:

    I've published several comparative benchmarks of iOS multimedia players in recent years, with particular emphasis on MKV playback. For example, in THIS article, I've directly measured the power consumption of the top MKV players and in THIS one, I've published several comparative test videos of running alternative MKV players. (Please see Appendix B at the bottom on why I recommend MKV files that much.)

    [​IMG]
    (The update list of the just-released "It's Playing Pro" version 5.0.)
    It was only some 18 months ago that the first third-party players came out that did manage to play back MKV in hardware. The scene has changed a lot in the meantime: now, all major players can use hardware acceleration when playing back MKV's. As of 01/Dec/2013, of the top / most important players, it's only the current (2.1.3) version of VLC for iOS ($free) that can't – but it doesn't support any kind of hardware playback, not even those of iOS-native videos, regrettably.

    The then-available players were much-much weaker than those of today. Actually, I've reinstalled the then-current version 1.510 of AVPlayerHD ($2.99), one of the first players to support MKV hardware playback (and still one of the top players) on my iPad 1 so that I can compare it to the now-current 2.21 version. The difference was dramatic. The old version stutters a lot when playing back my new LOTR test video, while the new one only occasionally drops some frames. Other MKV-capable players like It's Playing, which was one of the most recommended players throughout 2012, have seen similar improvements.
    Let's start with power consumption.

    1. Power consumption

    As has been explained above, iOS in no way can play back MKV files natively. Third-party players need to do a lot of tricks to essentially repackage MKV files so that they become playable by the hardware. This repackaging takes CPU time, which, in turn, may cause even significant additional power consumption.

    In these tests, which uses exactly the same setup as my previous one already linked to from the initial paragraph, used an iPhone 5 running on the currently latest iOS version, 7.0.4. This also means it isn't (can't be) jailbroken. The iPhone 5 has been manufactured in early June this year; I've got it as an exchange unit after my first-batch, original iPhone 5's battery turned out to be a lemon - a very common problem with the first few million iPhone 5's. I haven't used the phone much – for calling, I still prefer Nokia's Symbian phones because of their vastly superior features like the, in cases, really useful call recording. This means the battery of the (new) phone may only have some dozens of recycles and is, therefore, pretty much representative of a new iPhone 5 and is directly comparable to my earlier results in the previous article. Actually, I've stayed with benchmarking on the iPhone 5, and not on the 5s, to keep the results directly comparable to the earlier ones.

    I've set the lowest backlight level, very low volume and Flight mode, carefully topped the battery to 100% and reset the device before every single test. While the lowest backlight level / volume isn't a representative of real-world usage, it helps in something: to make the end results of the test reflect as much CPU-related power use as possible. With higher backlight levels, the results would also depend more on the power use of the screen backlight and it wouldn't be as easy to see which of the players has a more power-intensive – that is, worse – MKV re-packaging implementation. I played back a 126-minute-long, 1.5 Gbyte Anime movie with H.264 1920*1072 video encoded at around 5 Mbps. (5 Mbps is sufficient for anime even at the vertical resolution of 1072.) The MKV also has an AAC audio and an SSA subtitle track.

    The results are as follows:

    1.1 Power consumption results (without DSP's)

    It's Playing Pro 5.0: 28%
    nPlayer 2.3: 18%
    AVPlayer 2.21: 14%
    HD Player Pro: 14%

    These are the current versions of the currently (or, with It's Playing, were in 2012) most recommended players. Note that HD Player Pro is no longer available in the AppStore; more on this later, in Appendix A.

    As you can see, the two least power-hungry players are AVPlayer and HD Player Pro. nPlayer is somewhat and It's Playing is significantly worse. Nevertheless, the latter, now, as of version 5.0, consumes significantly less power than back in the 3.x times, which is certainly good news. And it has far more fluid MKV playback support now, as we'll promptly see.

    To show the impacts of software-only decoding, I've also measured the battery level drop caused by VLC for iOS's playing back the same video:

    VLC for iOS 2.1.3: 40%

    This is almost three times more than those of AVPlayer and HD Player Pro. While VLC produces pretty fluent playback of even Full HD videos on the latest crop of iDevices (ones with A7 CPU's), it will still consume significantly more power. This is the major reason for my not recommending it for high-resolution MKV playback.

    1.2 Power consumption results with DSP's

    Back in the day, digital signal processors (DSP's for short) were introduced by It's Playing first. It was quite much a revolution: these DSP's allowed for boosting the volume and the brightness so that the video remains visible under harsh light and the audio remains audible in even a busy gym. It also supported saturation and contrast fine-tuning.

    This year, other top players followed It's Playing. Now, both AVPlayer and nPlayer support video DSP's; nPlayer also supports audio boosting. In addition, VLC also supports DSP's, including even hue changes. Please see the second half of section “2. nPlayer” of my article HERE for more info on how these DSP's compare, user interface-wise, in the latest versions of AVPlayer, nPlayer and VLC.

    Of course, I wanted to find out whether runtime, always-running DSP's cause any kind of adverse effect on the battery use. The answer is, fortunately, no.

    The tests have been conducted in exactly the same way as with the previous ones. In addition, I set 166% brightness and 200% audio boost in It's Playing Pro. In nPlayer, I also used the same audio boost and set brightness boosting to around 28 so that it delivers about the same brightness level as It's Playing. In AVPlayer, the latter figure was around +28. As AVPlayer doesn't support volume boost, I conducted its tests using 100% volume – unlike with the other two players.

    The results:

    It's Playing: 33%
    nPlayer: 18%
    AVPlayer: 14%

    That is, compared to the no-DSP figures, it's only “It's Playing” that exhibited some (not very serious) power usage increase. The other two players didn't. That is, you can safely use at least the brightness slider and, on nPlayer, audio boost, it won't decrease your battery life.

    2. Playback speed tests

    An entirely different set of tests was MKV fluidity and frame skip test. For this, I've come up with a brand new, constantly-panning 1920*800 Full HD test video encoded at around 7 Mbps and having a single 5.1 AAC audio track, from the third Lord of the Rings movie. While the vertical resolution is “only” 800 pixels and the encoding speed isn't very high either, the video is very demanding as it's constantly panning. I've made the file available HERE – feel free to download it and use it for benchmarking.

    Before showing you all the details, the results of the tests are as follows:

    - fastest player with the least framedrops: AVPlayerHD
    - nPlayer is just a bit slower, but has far more features (e.g., volume boost, excellent network access etc.)
    - for full HD decoding, VLC is plain useless on anything pre-A6 (that is, anything non-iPad 4/iPhone 5 or later). On A6, it's acceptable; on A7, it's pretty good. Apart from the increased power consumption, of course.
    - the latest, just-released version of It's Playing Pro is significantly better than 3.8/3.9 thoroughly tested and elaborated on by me earlier. Nevertheless, it still can't beat AVPlayerHD or even nPlayer when it comes to pure speed.

    The comparative videos are as follows. I used the iPad 1, 2 and 3 for most of the tests – and, once, an iPhone 5 to demonstrate the difference between VLC's decoding speed on the A5 and the A6. The iPad 1 was shot mostly in itself; the other two iPads in direct comparison to each other, side-by-side. This was possible because they are, subjectively, of exactly the same speed when playing back video; that is, my swapping the two players on the iPads, I would have got exactly the same results.

    I've deliberately chosen “old” iPad models because these tests are comparisons and the slower the hardware, the more pronounced the differences are. For shooting the tests, I exclusively used two times slowed down slow-motion videos, originally shot at 720p60. That is, two seconds in the videos correspond to one second in real life.

    With regard to the iPad 1, I only included it in the test for even more pronounced speed difference tests.

    2.1 Just-released It's Playing Pro 5.0 vs. 3.8

    http://www.youtube.com/watch?v=hG5ayXb2ix8

    iPad3 (the black iPad at the bottom) runs 5.0, iPad2 (the white at the top) 3.8. 3.8 stutters quite a bit more than 5.0.

    2.2 AVPlayerHD (iPad3) vs. nPlayer (iPad2)

    http://youtu.be/x0yhzbk0TFg

    nPlayer does have some slight (but not very annoying) framedrops, unlike the definitely smoother AVPlayer. To see the differences more pronounced, I've re-run the same tests on the much slower iPad 1; see immediately below.

    2.3 iPad 1 running AVPlayerHD and, then, nPlayer

    http://youtu.be/gRwHd3dmWak

    As you can see, AVPlayerHD indeed delivers better (less-stuttering) results. nPlayer is decidedly behind.

    2.4: iPad3: VLC, iPad2: It's Playing 5.0

    http://youtu.be/sVpiewsZhoQ

    On A5(+) CPU's, VLC is hopelessly bad. On the iPad2, It's Playing 5.0 plays back the video equally smoothly as on the iPad 3 – as has already been stated when I said there's no speed difference between the iPad 2 and 3. This, of course, also means it's even worse on even older hardware.

    Let's see some additional VLC goodies; now, on the substantially faster iPhone 5. This was because I wanted to see how more modern iDevices fare with software-only decoding:

    2.5: iPad2: HD Player Pro; iPhone 5: VLC

    http://youtu.be/KwczQqf7VW8

    On A6 CPU's, VLC delivers pretty good results with these kinds of 7 Mbps streams. However, the usual remarks / warnings about battery use are still topical.

    Another iPad 1 video, showing It's Playing version 3.8:

    2.6 iPad 1: It's Playing 3.8

    It's low-res stuttering mess. Avoid it! Unfortunately, It's Playing Pro 5.0 no longer supports iOS5 – as opposed to AVPlayerHD and nPlayer. Nevertheless, given that AVPlayerHD is significantly faster than even It's Playing Pro 5.0, you don't lose much – stick with AVPlayerHD on such old and slow iDevices!

    Finally, a native video test showing the stock Videos app of the iPad3 and iPad2 playing back the M4V remuxed version:

    http://youtu.be/1e5MBHoDFgY

    No difference at all – as was easy to predict. After all, the system is playing an iOS-native video file, which won't cause any problems, unless it's a high-framerate or/and an extremely high-bitrate one. My test video is neither.

    3. What about HDMI / VGA output?

    In my original article on AVPlayerHD's receiving MKV support, in section "AirPlay", I've explained the then-current AVPlayerHD drove the in non-mirroring mode connected AppleTV in a flawed way.

    As you already know (I've explained above), MKV playback under iOS must be tricky: the players need to quickly re-package ("remux") the original MKV files into 10-20 second-long MOV / MP4 / M4V chunks and pass those files to the hardware decoder. However, as the non-mirrored mode of the wireless AirPlay works by simply being passed a network address of where the source file is available, tis meas it'll be passed a link to the new chunk every 10-20 second. As it'll pre-buffer before starting playback, it'll not only return to the ATV home screen, but also insert a very long pause while it's buffering.

    Let me show this in practice with the in no way recommended EC Player ($2.99), which, as it hasn't really been bugfixed in the meantime, still tries to drive external AirPlay receivers in non-mirrored mode, when playing back MKV's:

    http://youtu.be/VyaG9DqsP_o

    3.1 Recording HDCP content with HDMI recorders

    A side note on how I've made the above direct ATV recoding: as the ATV requires HDCP for playback of even non-HDCP content (as is my test MKV) it receives via AirPlay, I needed to use an additional box to remove HDCP from the HDMI signal so that I can directly record it with my HDMI recorder. Otherwise, all I would have seen would have been the following:

    [​IMG]

    Because of this, I've used THIS device of mine. The stuttering you can see in the above video is caused by this gadget: it's simply not fast enough, not even when outputting 720p only.

    That is, you certainly won't want to use this gadget it to "unprotect" your copy-protected full HD movies. For recording your Android screencasts, however, it's indispensable. As you may know, if you use the HDMI (e.g., via the microHDMI port on the Nexus 10 or the SlimPort of the Nexus 4/5/7.2) to mirror the screen of the device, everything will be copy protected and in no way can be recorded. In this regard, Android's HDMI output is definitely worse than Apple's as the latter only uses protection with truly protected content playback, not when you "just" mirror the operating system's screen. To make Android screen / HDMI output recording possible, this box is excellent, as the framedrops won't be as bad as with the LOTR benchmark video playback.

    Now, back to the main subject.

    3.2 Rejoice: no such bugs in current players!

    While, except for It's Playing Pro 5.0, all the reviewed hardware playback-capable players can drive an external Apple TV with an iOS-native (mp4 / mov / m4v) file in the non-direct (non-mirrored), full-quality mode, only one of them exhibits the "tries to play back the MKV video chunks on the ATV" bug. In this regard, AVPlayer(HD) is also better than the intitially reviewed one – the current version no longer tries to output anything when playing back MKV's.

    The exception I've just mentioned is HD Player Pro. It tries to pass the URL of the video chunk to the ATV – without success. The latter will hopelessly try to fetch the video chunk until you manually force it to stop.

    That is, if you do use HD Player Pro with an external ATV to play back iOS-native files, don't forget to fully disconnect the ATV before starting to play back MKV's. And, again, no such measures need to be done with the other native ATV-capable players (AVPlayer(HD), nPlayer) – you can safely leave the iDevice connected to the ATV (in non-mirrored mode) while using these apps. iOS-native files will nicely be played back on the ATV – but nothing else (apart from the audio, of course) and definitely not the chunks of the MKV files.

    What about VLC for iOS, you may ask. As it doesn't support hardware-assisted decoding of even iOS-native (mp4 / mov / m4v) files, it in no way has a chance to pass any addresses to the ATV. Unfortunately, while It's Playing Pro 5.0, unlike VLC, does support hardware playback for iOS-native files, it does require mirrored mode to be on to, then, directly drive the ATV. Which, as with everything directly driven, will result in major framedrops and compression artifacts. As usual, you will in no way want to use any of these players in mirrored mode – it's simply useless when done wirelessly, via AirPlay.

    (cont'd below)
     
  2. Menneisyys2 thread starter macrumors 603

    Joined:
    Jun 7, 2011
    #2
    (cont'd from above)

    4. Wired HDMI / VGA output

    Note that all these apps drive TV output directly, even if you do configure them to use full HD output (both AVPlayer and It's Playing needs to be reconfigured to do so. The former, by default, drives the TV at 640*480, while the latter in an around-XGA-resolution mode).

    4.1 Lightning

    Unfortunately, all the reviewed apps can only drive the Lightning adapter in direct mode. That is, they can't pass the URL of any iOS-native file to the Lightning adapter so that it can fall back to native decoding.

    While this is in no way as bad as direct driving in wireless AirPlay mode, it still decreases the image quality. As you may recall from my (numerous) HDMI-specific articles, Lightning-based TV output, when driven directly, will only deliver 900p, that is, lower resolution as opposed to 1080p. The following two ISO 12233 crops (click for the original framegrab!) certainly show the resolution difference:


    Direct driving from third-party apps (all the reviewed ones; after upping the output resolution where needed):

    [​IMG]

    Stock Videos app:


    [​IMG]


    (click for the full-sized framegrabs)

    It seems you can only make Lightning play back otherwise iOS-native videos if you do the playback from the stock Videos app – but nothing else. This is another major problem with iOS.

    4.2 The old 30-pin adapters

    As the 30-pin adapter doesn't need to encode and, then, decode the video stream when driven directly, you won't have any problems with any kind of video. Everything will be truly Full HD, in its full quality. This also means if you have a sufficiently fast 30-pin device (e.g., A5-based iPad 2 or 3 or the iPhone 4S), you may prefer it to drive your external HDMI monitor during video playback if, otherwise, the device is able to decode the video without stuttering. "Thank" Apple for the inherent problems and quality degradation present in their Lightning adapter for that.

    5. Verdict


    Should you need the best speed and you don't need the best bitmap (e.g., DVD) subtitle support? Get AVPlayer, particularly if you have a VERY slow iDevice.

    Should you need great (albeit not the best) speed and you absolutely need bitmap (e.g., DVD) subtitle support? Get nPlayer.

    Should you need great network streaming support, even on the expense of the frame rate? Take a look at nPlayer or It's Playing Pro.

    Should you need DTS support? Hope you've purchased HD Player Pro while it was still available – see the Appendix immediately below. Otherwise, remux the file by adding a two-channel AAC audio track to it, unless your iDevice is jailbroken (then, use the jailbreak-only RushPlayer+). Remuxing is, actually, one file drag and three clicks with MKVTools or MP4Tools, as has also been explained in my today's quick tutorial HERE.

    Appendix A: What About HD Player Pro?

    If you need DTS support in your MKV files and you can't go the jailbroken / remuxing way, your best choice is HD Player Pro, which I recommended in many of my past articles. Hope you did purchase it back then...

    It's a considerably better player than the two other DTS-capable, current AppStore player I know of, VLC and CineXPlayer. (Click the links for the reviews of the latest versions of both apps, should you want to know why I don't recommend them.)

    NOTE:

    1, it's no longer available in the AppStore. It seems the developers have played the same cards as the developers of AVPlayerHD a year ago: upon receiving the DTS folks' request to eliminate DTS support, they haven't released a new, dumbed-down version of the player (without DTS support) but removed the app from the AppStore, which means

    a, earlier downloaded versions aren't overwritten (you don't need to manually save / overwrite IPA files, unlike with players that do have dumbed-down versions) and happily play DTS audio even now

    b, you can re-download the, as explained above, DTS-capable, last version from the AppStore on iDevices you've at least once directly downloaded any version of the player, before the devs had to remove the app.

    2, in iOS7, its hardware (e.g. MKV) decoding doesn't work when there's no Internet connection (for example, you enable Flight mode or don't connect to any network). Under iOS6, the player still worked just fine in Flight mode. Keep this in mind if you use it under iOS7.

    Don't be afraid of the connection, though. Upon a reader's question, on my 3G data-enabled iPhone 5 (7.0.4), I've measured its data usage (using the built-in cellular & app-specific counter functionality iOS7).

    It seems it doesn't connect to anywhere. I've tried a exiting / restarting the app / the HW-decoded video in the app but the counter stayed at 0 bytes.

    That is, it doesn't "call home" (or anywhere). It seems to be safe. It just requires an active data connection under iOS7 - probably because of a bug, as the developers couldn't update it for iOS7 without having to remove DTS support (and, consequently, screwing up their customers).

    Appendix B: Why is MKV That Important?
    MKV is the file (container) format to go for if you grab your own DVD or Blu-ray discs for later playback on iDevices, particularly when it comes to “exotic”, DVD- or Blu-ray-native audio or subtitle formats. As I do, who prefer purchasing real Blu-ray discs off, mostly, Amazon to purchasing digital-only and copy-protected movies from Apple's iTunes Store. The latter are of not only lower image and audio quality in most cases, but also lack iOS-playable extras, (in many cases) subtitles and can't even be played back in third-party players under iOS, only in the absolutely incapable, stock Videos app.
    In addition, Amazon's prices of even Blu-ray editions are pretty much on par with those of Apple. While ripping and converting can take some time, I've found that hassle minor. For example, last time I purchased the entire first season of the cult UK sci-fi series “Space: 1999” off Amazon UK for 33 UK pounds (original confirmation mail screenshot HERE), it only took me about 8-10 hours to rip all the five Blu-ray discs and, then, to downsize the videos to around 4-5 Mbps ones with burnt-in subtitles; most of the time unattended. Then, the 24-hour-long series gave me about two months of enjoyment in my free time dedicated for movies: traveling, resting after swimming or running etc. That's not much of an additional work if you take into account the vast advantages of doing your rips yourself, compared to Apple's pretty much inferior iTunes Store videos...

    Being able to play back MKV files is, consequently, very important. Unfortunately, iOS doesn't particularly like MKV files, unlike, say, Android, where they are playable even in the stock video player without major glitches - unless you need to display subtitles. (Actually, in Android version 4.3+, most of the MKV's I've tested on my Nexus 7 2013 were played just fine. It's only extremely high-bitrate ones like the standardized 40 Mbps Birds test video that resulted in some dropped frames) Not so in iOS: here, you need to turn to third-party players to do the same. In addition, it was impossible to use hardware acceleration for long to play back these files, “thanks” to Apple's very strict and, in my opinion, absolutely counter-productive, user-alienating restrictions.

    ----------

    UPDATE: Added two brand new chapters (3. and 4.); see above.
     
  3. Menneisyys2 thread starter macrumors 603

    Joined:
    Jun 7, 2011
    #3
    UPDATE:

    after talking to the nPlayer folks, I've re-tested nPlayer after changing the Settings > Video > Renderer For Hardware Decoding setting from the default OpenGL ES to Quicktime. The new setting is as follows (annotated with a red rectangle):

    [​IMG]

    This made playback as fluid as that of AVPlayerHD, even on the lowly iPad 1. (I will also publish a video showing this.)

    Unfortunately,
    - visual DSP's (brightness etc.) are not available in this mode; that is, the "Color Adjustment" menu item will be gone in the runtime settings menu. Note that the most useful and non-visual DSP, volume boosting, will remain.

    - users aren't told to switch to this mode in the app itself. I've mentioned this (users should be displayed a dialog at least once, telling them to switch to QuickTime mode for the best playback speed) to the dev; hope they'll add this to the next version.
     
  4. Menneisyys2 thread starter macrumors 603

    Joined:
    Jun 7, 2011
    #4
    A quick update: I've posted three new benchmark videos:

    The first demonstrates how much faster nPlayer is when used the QuickTime mode to play back the benchmark MKV file:

    http://youtu.be/JeqEXxjEnwE

    This is recording made on the same iPad 1 as with the benchmark video ( http://youtu.be/gRwHd3dmWak ) in the original article using the default OpenGL ES setting. The difference is night and day – always, I repeat, ALWAYS switch to QuickTime mode whenever you don't need the visual DSP's! Too bad the developers don't emphasize this in their app.

    Second, Android haters, rejoice: I've shot two videos showing the stock video player of Android playing back the video:

    http://youtu.be/M-x8rPiyVfk

    As you can see, the results are absolutely awful.

    The absolutely best Android multimedia player, MxPlayer, plays back the same MKV (in its HW+ mode) much better but it's still not as good as the more sophisticated MKV players on iOS, even on the iPad 1:

    http://youtu.be/-a0VQMwot68

    As you can see, it's still pretty stuttering.

    As with the previous benchmarks, these videos have been shot at 60 fps and slowed down by a factor of two so that framedrops can more easily be spotted.
     
  5. hipnetic macrumors 6502a

    Joined:
    Oct 5, 2010
    #5
    I'm confused about something: If you're going to go through the process of downconverting your video to decrease the filesize, why not just use Handbrake and convert it to an MP4/M4V file? Why bother leaving it as an MKV?

    In my case, I use MakeMKV to rip my Blu-ray discs and leave them at full size (I drop off audio tracks, etc. that I don't care about). Total rip time is under an hour. I would prefer not to go the extra step of downconverting them because of the added time involved, and for other reasons. If I want to serve them to a low-powered client (e.g., iPhone) I let my Plex Media Server transcode/downconvert them on-the-fly.

    I tried Infuse to see what it could do with my full-bitrate MKV files, but I've had no success. Given how large the files are, and the fact that it would be transferring them over WiFi to my iPhone 5, I'm not really surprised by that.
     
  6. Menneisyys2, Dec 5, 2013
    Last edited: Dec 5, 2013

    Menneisyys2 thread starter macrumors 603

    Joined:
    Jun 7, 2011
    #6
    I prefer keeping all the original languages' graphical (bitmap) subtitles in the file (separate, non-embedded subtitles, when at all made use, are a PITA to maintain – they easily get lost).

    While bitmap subtitles can be embedded in M4V files (via Subler - see Note 2 at the bottom), very few iOS players render these subtitles properly. (Needless to say, the stock player, while it does properly play back the audio/video, doesn't render them.) Of the desktop players, only VLC renders them; iTunes, while plays back the files (and synchronizes to the iOS stock Videos app), doesn't render subtitles and the default QuickTime completely refuses playback:

    [​IMG]

    On iOS, I've tested all the new versions of the most important iOS players and, of the bunch, only VLC for iOS rendered the subtitles properly.

    It's Playing Pro 5 and Infuse 2 both have color problems, making these pretty much unreadable. Even nPlayer has false (yellow) colors, but at least it's much more readable than that of Infuse 2. AVPlayerHD (as opposed to all the other players listed here) doesn't even properly resize the m4v-embedded subtitle bitmaps – it uses only part of the display on an iPad to display. Therefore, its character sizes are pretty low. And the colors are completely off, which makes reading even harder. (Note that I've shown some screenshots of what's wrong and right in my latest VLC & AVPlayerHD & nPlayer review.)

    All in all, it's only VLC for iOS that, currently, can be used to render these kinds of subtitles.

    However, if I do keep the subtitles in an MKV container, then, in addition to VLC for iOS, It's Playing Pro 5 and, what is most important, the up until now most recommended nPlayer will render them properly. (Unfortunately, neither Infuse 2 not AVPlayerHD render these bitmap subs.)

    Unfortunately, OCR isn't the way to go, particularly not with the rare languages (e.g., Finnish) I speak / need – there will be just too many recognition errors. (Not even English recognition is flawless, let alone small languages.) Therefore, textual subtitles rendered by even the stock Videos client is simply not the way to go.

    If you want to test these yourself, here are three files:

    The original, untouched DVD rip (MPEG-2 MKV): https://dl.dropbox.com/u/13100693/html/042012RetinaHDVideoPlayers/lupaus-ads-orig.mkv (originally linked from THIS article)

    The direct video & audio-converted H.264 MKV (see Note 1 below): https://dl.dropboxusercontent.com/u/81986513/lup-mkv-h264-vobsubsubs-createdByMKVTools.mkv

    The remuxed MKV > M4V (see Note 2): https://dl.dropboxusercontent.com/u...bsubs-createdBySubler-from-MKVToolsOutput.m4v

    NOTE 1: This is how I've created the H.264 MKV file out of the original MPEG-2 DVD rip MKV file: I used MKVTools with one-pass MPEG2 -> H.264 & stereo AC3 > stereo AAC conversion & soft muxing the subtitles. No additional steps were needed. Two-pass H.264 encoding didn't work – unlike with MP4Tools. Here's a screenshot of the settings (I've annotated the settings I've changed and the three buttons in the upper left corner; after those changes, just click Convert in the bottom right corner):

    [​IMG]

    NOTE 2: creating the M4V file with the embedded VobSubs needs the excellent Subler. (MP4Tools, another great remuxer tool from the same dev as MKVTools can't soft mux Vobsub subtitle tracks into mp4 / m4v output files – don't even try.) Just open the just-created MKV file in Subler and save it as a m4v file. Make sure that, before opening the source MKV file, you disable Settings > Advanced > VobSub to Tx3g to avoid OCR!
     
  7. H3nk387 macrumors newbie

    Joined:
    Jul 8, 2010
    #7
    Thanks for the time you put into these reviews.
    Quick question: If I'm jailbroken is Rushplayer+ generally a better player than lets say nPlayer and AVPlayerHD?
    I use a combo of iPhone 4 and iPad3 if that makes much difference. I just want to be able to play files on the device without stutter. Playing networked files isn't a big priority for me.

    Thanks!
     
  8. Menneisyys2 thread starter macrumors 603

    Joined:
    Jun 7, 2011
    #8
    Unless you need the special features of the latter two apps (volume boost of the nPlayer, visual DSP's, gesture-based navigation etc.), I'd say yes, particularly if you need DTS audio support. (Rushplayer+ supports DTS too.)
     
  9. Menneisyys2 thread starter macrumors 603

    Joined:
    Jun 7, 2011
  10. MyopicPaideia macrumors 68000

    MyopicPaideia

    Joined:
    Mar 19, 2011
    Location:
    Trollhättan, Sweden
    #10
    Ok, but what is the advantage of bitmap subs as opposed to text based subs in an .srt or .sub package??? Is it just prettier or something?? I usually remux my Blu-rays I've ripped to MKV to mp4 in a matter of a minute or two, and usually just skip doing the subs myself and find them online in the .srt format. Built in tool in the software I use (Roadmovie).
     
  11. Menneisyys2 thread starter macrumors 603

    Joined:
    Jun 7, 2011
    #11
    Well, if they're in perfect sync (not meant for, say, an uncut / extended version and vice versa), they may be indeed a much better choice.

    For rare movies / other versions, they may be entirely out of sync (or non-existent and/or having OCR errors).
     
  12. Jack Tripper macrumors member

    Joined:
    Apr 9, 2011
    #12
    Looking forward to reading the MKV Bible referenced in the OP. Any updates on that?
     
  13. Menneisyys2 thread starter macrumors 603

    Joined:
    Jun 7, 2011
    #13
    Not yet. I've been busy updating my JB tweaks and apps now that the iOS7 JB is out. Prolly in January.
     
  14. Jack Tripper macrumors member

    Joined:
    Apr 9, 2011
    #14
    Appreciate your efforts and still looking forward to reading your MKV bible.
     

Share This Page