Kodi Community Forum
Solved 10-bit h264 (Hi10) Support? - Printable Version

Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
--- Thread: Solved 10-bit h264 (Hi10) Support? (/showthread.php?tid=106051)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

RE: 10-bit h264 (Hi10) Support? - Qorlax - 2013-01-08

Lav filters uses FFmpeg Wink
FFmpeg is also multi-threaded these days. Is the FFmpeg library Frodo uses not MT yet?

RE: 10-bit h264 (Hi10) Support? - enolive - 2013-01-09

(2013-01-08, 11:43)jpsdr Wrote: For me, the Kara effects worked fine, with a build from nightly from a week ago, but with a custom allowing MT decoding, and on an [email protected]

no wonder if you are using such a monster cpu Smile. the i3 3220t is fast enough as well.

RE: 10-bit h264 (Hi10) Support? - jpsdr - 2013-01-09

(2013-01-08, 18:15)maruchan Wrote: Do you have a patch you could provide to enable multi-threaded decoding?

In my post #525 in this thread.

But, there may be more and more releases with all this kara effects. Apparently, before these kind of very advanced effects were done with AfterEffect, and OP/ED in this cases were hardcoded. It seems that very recently update of probably both VSFilter and Aegisub allow now very advanced effects which were not possible before, but with a result of huge CPU use... This is another new thing fansub teams will probably rush on !!
A "such" monster CPU... Well, as i'm watching almost animes, and i've seen during the last 15+ years how fansub teams act : Rush on any new thing without any regard of HW compatibility or anything, when i've build my PC i didn't want to have something not working in 2 years because suddenly fansub teams switched to new codec YYY, not supported by any HW player, and asking more CPU. At least, with this, i hope i'll be good for a long time.
I think the new step for animes fansub teams will probably be to switch to h265, before everyone, and years before any HW player will play it...

RE: 10-bit h264 (Hi10) Support? - boingman - 2013-01-12

(2013-01-08, 02:27)enolive Wrote: this series is what finally motivated me to replace my good old ASRock ION330-HT with a newer device. While I can cope with working around 10-Bit encodes (transcoding is easy and I've yet to find any noticable quality differences between 10Bit and 8Bit encodes), more and more Anime Fansubs are using heavy styled softsubs for OP/EDs as well as for stuff like signs etc (SAO wasn't the only series I experienced problems). This caused the ASRock to go into slow mode, making watching the stuff quite unbearable. The only way to work around that is to turn off/skip the subs or edit them yourself, which I decided not to do.

Though in this particular case, I had also posted a few days later that a newer build fixed the problems I had with Swort Art Online.

I had also mentioned the Kara effects of UTW's Kono Naka OP, which even with that newer build were still too much for my PC (i5 750 with 8 GB Ram) at that time. Will have to test if that possibly changed with a newer XBMC build and if not whether a new more powerful computer would help. I was thinking about upgrading this year, so this might be another good reason.

RE: 10-bit h264 (Hi10) Support? - Ned Scott - 2013-01-12

I've been grabbing Horrible so often that I finally caved and bought a year of Crunchyroll. Now we just need a working CR add-on.

RE: 10-bit h264 (Hi10) Support? - CharredChar - 2013-01-13

(2013-01-09, 11:17)jpsdr Wrote: I think the new step for animes fansub teams will probably be to switch to h265, before everyone, and years before any HW player will play it...

Considering there has already been hardware announced for HEVC (H.265) ... nope. Don't forget "10bit" is a H.264 codec, just a different color profile. The problem comes with the fact that profile isn't part of hardware decoders because no one buys 10bit monitors/tvs and none of the mainstream media (Blu-rays) are encoded using it.
I wouldn't doubt that these (moronic) anime groups would jump onto a pre-release H.265 codec just for another new thing to use. IIRC its how DivX came about. And to be honest I can see why as every article about it touts the same quality with half the bitrate/file size. Sounds like AAC/MP4, no? Seems everyone uses that for audio streams now for the same reason.

RE: 10-bit h264 (Hi10) Support? - momaku - 2013-01-17


I am thinking to mount a miniPC with Openelec (with XBMC-Frodo) to see films and anime. Actually, I use a PopCorn A-210, I am tired to have to recode anime to 8 bits.

My doubt is the minimum CPU required to play 10 bits in 720p or 1080p flawless. I am considering to use a Atom D2700:

Atom D2700

Would it be enough to play 1080p 10 bits? Would be enough a: Intel's NUC, ZBOX ID42 or ZBOX ID83?

Thanks in advance.

RE: 10-bit h264 (Hi10) Support? - FernetMenta - 2013-01-17

D2700 should be fine after this patch has been applied: 2064 (PR)

RE: 10-bit h264 (Hi10) Support? - momaku - 2013-01-18

(2013-01-17, 20:32)FernetMenta Wrote: D2700 should be fine after this patch has been applied: 2064 (PR)

Thanks for the info.

I'll try to apply it.

Best regards.

10-bit h264 (Hi10) Support - DeathScyther - 2013-01-24

Hello! A quick question, if I may...?

I have been using xbmc for years and loving it. Thing is, recent anime 10 bit h264 flac files introduced dropped frames for the first time on my machine (that I noticed).
Just stutters for a few seconds on specific points due to high bitrate (50 MB/s?). Tried Zoom player with madvr enabled and checked the same spot but no frame dropped. Is Zoom player using hi10p or dithering to 8-bit?

I tried playing the file with and without dxva2, pixel shaders, software; using audio out on analogue, hdmi and spdif. Same dropped frames in specific points, less or more but but always dropped.
Everything dxva compliant plays ultra smooth.

Hardware: intel core 2 quad 2.66 GHz, ATI 5670 1 GB, 4 GB RAM, Win7x64, hdmi for video render on 60 Hz monitor full hd, coaxial for 5.1 digital in AV amplifier.
file: AVC High [email protected] - 48 kHz CABAC 16 Ref Frames, 2 channels, FLAC

Is my cpu/ffdshow to blame? Is MadVR/LAV to praise?
Zoom player is on the right path to success but XBMC is already there,
Much obliged to all the developers.

RE: 10-bit h264 (Hi10) Support? - momaku - 2013-01-26

(2013-01-18, 15:42)momaku Wrote:
(2013-01-17, 20:32)FernetMenta Wrote: D2700 should be fine after this patch has been applied: 2064 (PR)

Thanks for the info.

I'll try to apply it.

Best regards.


I don't find a motherboard with Atom D2700 with all the things I want, But I found a motherboard with Atom D525 with them:


The spectifications of Atom D525;

Atom D525

Are it able to play 1080p 10 bits with the patch?

I want to be sure before send the money.

Thanks in advance.

RE: 10-bit h264 (Hi10) Support? - magao - 2013-01-27

(2013-01-17, 20:32)FernetMenta Wrote: D2700 should be fine after this patch has been applied: 2064 (PR)

Just wanted to note that this is apparently included in OpenELEC since RC1. Just tried it with RC2 and the playback improvement is amazing. I'm playing back 1080p 10-bit h.264 without dropping frames (yet) on my E2140. Just saw it with 1 core at 100% and the other at ~98% (and it dropped a single frame), so it's a little too close for comfort, but will give a lot more headroom for 720p material. As a rule, the two cores are generally within 1-2% of each other now, whereas before one was significantly more loaded than the other.

Ah - there we go. 8thSin's "A Letter to Momo" is too much for it. But it does suggest that I wouldn't need that much of an upgrade.

Hmm - still only single-threaded for 8-bit h.264 using software decoding resulting in a single core being pegged at 100% while the other is at 20% with straight Blu-Ray rips. I'm using the built-in GMA3000 graphics for a number of reasons, so VAAPI isn't feasible. I would have thought that if software decoding was explicitly being used (i.e. all hardware acceleration options disabled) multi-threaded frame decoding should be used for 8-bit as well. It seems a little bizarre that 10-bit material is playing back better than 8-bit ...

RE: 10-bit h264 (Hi10) Support? - fritsch - 2013-01-28

Happy that you like it, this was my intention. My patch only checks for hi10p content and uses multithreading for this. H264 8bit had severe bugs, when decoding multithreaded, cause of this it is disabled. If there is a hw decoder, it must be single threaded. That is the whole issue about, cause it needed so long to make a proper patch. As I looked at the code, I actually saw that there is a very hi10p specific code integrated to "disable all hw accel", so I used the same infrastructure to enable multithreading in this exact case.

we must check something like this, to make it generic for all codecs:

if( no vdpau && no xvba && no vaapi && no mac osx hw accel && no windows hw accel && ... && ...)
give the chance to activate multithreading

Btw. i have a crystal hd card for sale, that you could plug in and happily use your Atom for everything then :-)

RE: 10-bit h264 (Hi10) Support? - jpsdr - 2013-01-28

Strange. I make my own builds, using the little patch i've made (code here) since a long time now, and never noticed any issue with h264, either 10 or 8 bits, or anything else indeed.
What exactly are these "severe bugs" ?

RE: 10-bit h264 (Hi10) Support? - Shine - 2013-01-28

@fritsch: This one? I was under the impression that since your pull request still has the status "open", it's not merged yet...
The issue I have with enabling multithreading for Hi10P content only is that a lot of people with lower-powered CPUs, who for the one or other reason don't want to or can't enable hw accel, will see the behavior that magao mentioned - 8bit content playing back worse than 10bit. I would've favored a similar approach as my April one, just integrated into the code a little better than my ugly patch was.

There has recently been an update to FFMPEG ticket #604. With a little luck, with the next FFMPEG update - looking forward to XBMC 13.0 - the DXVA+MT issue might have been fixed? Keeping fingers crossed...