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.)
![]()
(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:
![]()
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)
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.)
(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:
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)
Last edited:
