Because of the deinterlacing issues that the Vero 4K+ has with 1080i material, I recently tried playing a file that is encoded as 1080i/50 without hardware acceleration. The container is M2TS rather than MKV, and it uses the VC-1 codec, not h.264.
Not surprisingly, it doesn’t play very well 
; but, a little surprisingly, the Vero attempts to play it using only one of the four CPU cores: if you look at the CPU utilisation, only one core is pushed to 100% while the others are around 10% each.
By contrast, if you try to play a 1080p h.264 mkv file in software, all four cores are pushed to 100%.
I dare say no one will be particularly interested in investigating this, on the perfectly reasonable grounds that the file quite likely still wouldn’t play smoothly in software even with all four cores active. But if anyone wants to take a look, I’ve prepared 30-second test clip which illustrates the issue - if you give me a URL to upload it to, I will.
Logs:
http://paste.osmc.tv/adaqigipaq
MediaInfo on the file will be posted in a minute or two.
MediaInfo for my test clip:
General
ID : 1 (0x1)
Complete name : C:\Interim\vc-1 m2ts sample in 1080i_50.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 137 MiB
Duration : 29 s 920 ms
Overall bit rate mode : Variable
Overall bit rate : 38.2 Mb/s
Maximum Overall bit rate : 35.5 Mb/s
Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : VC-1
Format profile : Advanced@L3
Codec ID : 234
Duration : 29 s 920 ms
Bit rate : 34.7 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.668
Stream size : 124 MiB (90%)
Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : DTS XBR
Format/Info : Digital Theater Systems
Commercial name : DTS-HD High Resolution Audio
Codec ID : 133
Duration : 29 s 899 ms
Bit rate mode : Constant
Bit rate : 2 046 kb/s
Channel(s) : 6 channels
Channel layout : C L R Ls Rs LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : -70 ms
Stream size : 7.29 MiB (5%)
Language : English
Text
ID : 4608 (0x1200)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 27 s 118 ms
Delay relative to video : 720 ms
Language : English
ffmpeg’s VC1 decode implementation is not multi threaded; so this is to be expected.
I don’t think the ARM is fast enough to software decode VC-1.
Sam
Yeah, despite being in the same compression class ratio as H.264, VC-1 requires almost as much CPU as H.265 to decode. Even my 6-core/12-thread x86 chip shows some strain when decoding VC-1 to re-encode to H.264…there isn’t enough CPU left for the encode to provide the same speeds as I get with H.264 to H.264 re-encodes.