Kodi Community Forum

Full Version: 10-bit h264 (Hi10) Support?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
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
So after a few months on hiatus, I decided to have a look at the current XBMC nightlies and prepared a new build based on 0f6fb94fc7 dated 2012-11-02. Download here.

This build includes the following patches (source included with the download):

  1. Re-enable frame based multithreading
    Since my previous patch doesn't work on the current tree anymore and while I had SOME free time, I had not A LOT of it, I decided to go for a quick&dirty approach similar to jpsdr's suggestion. If you want to enable full multithreading, you'll have to turn off DXVA2 in the video options when using this build.

  2. My OGM-packed-bitstream patch that none of the devs seems to care about...
    Fixes choppy playback of certain OGMs that contain MPEG4 (Xvid/Divx) streams with packed bitstream encoding. Probably also fixes playback for other files with incorrect frame timestamps.

  3. Fix DXVA rendering by turning off 10/16bit rendering
    Unfortunately, elupus' Play10bit patch broke DXVA rendering for Hi10P files, giving you a pitch black screen instead. I have no idea whether this might be specific to Intel GPUs (I'm using G45), but apparently DXVA scaling/rendering won't work with 10/16bit color spaces (YUV420P10/YUV420P16). Even more unfortunately, the available color formats are defined in CWinRenderer:TonguereInit(), way before it's known whether DXVA rendering is actually chosen or not (CWinRenderer::Configure()). So I disabled rendering these color formats by default - or rather, as soon as there is a chance that DXVA rendering might be chosen. While I was at it, I also fixed a typo in elupus' commit.

  4. Force DXVA scaling for HD content to fix framedrop issues
    Same as in my previous build. My Intel G45 is simply too slow to render Full HD content using pixel shaders without occasional frame drops (resp. a lot, if scaling is involved). So I'm reverting to DXVA rendering for all HD content.
Note: Just like in my previous build, you can turn off the latter two features with the following advancedsettings.xml option and choosing PS or SW rendering in the video options:
Code:
<advancedsettings>
  <video>
    <forcedxvarenderer>false</forcedxvarenderer>
  </video>
</advancedsettings>
However, non-DXVA rendering after DXVA decoding appears to be broken currently, so XBMC will crash unless you turn off DXVA decoding as well. I suppose you have this turned off anyway to get full multithreading support ;-)
Quote:My OGM-packed-bitstream patch that none of the devs seems to care about...

It's really easy for things to get lost in the shuffle. Have you used github before and know how to do a pull request? It's a lot more likely to get seen there.
(2012-11-03, 01:48)Shine Wrote: [ -> ]Fix DXVA rendering by turning off 10/16bit rendering
Unfortunately, elupus' Play10bit patch broke DXVA rendering for Hi10P files, giving you a pitch black screen instead. I have no idea whether this might be specific to Intel GPUs (I'm using G45), but apparently DXVA scaling/rendering won't work with 10/16bit color spaces (YUV420P10/YUV420P16). Even more unfortunately, the available color formats are defined in CWinRenderer:TonguereInit(), way before it's known whether DXVA rendering is actually chosen or not (CWinRenderer::Configure()). So I disabled rendering these color formats by default - or rather, as soon as there is a chance that DXVA rendering might be chosen. While I was at it, I also fixed a typo in elupus' commit.

Nope. My AMD gpu has pitch black video too. Audio seems fine. Turning of DXVA results in 15 fps video blackback (at most) and choppy audio. It's a shame because I know my system can handle these files, only not in xbmc.

Edit:
Tried your build, hi10p plays, but with a LOT of framedrops. It seems ffmpeg isn't quite capable op hi10p (yet). Lav filters in mpc-hc has zero frame drops.
Thanks for the updated build, it works very well here.
hi10 playback seems to be broken in recent Frodo betas.
(2012-12-05, 12:40)Roman_V_M Wrote: [ -> ]hi10 playback seems to be broken in recent Frodo betas.

Still works fine for me in beta2.
Hi10 Seems broken for me in OSX. Frodo beta 1 and 2
Just saying it doesn't work won't help us. Outside of myself, it's very doubtful that other XBMC team members are going to have H10P videos, and they're working fine for me on Beta 2 in Mac OS X 10.8.

We need more details, like does it show a black screen but with audio? Does it play with video artifacts (smudging)? Does nothing happen at all when you play the file? Also if you guys can include what file you are trying to play (release group, episode name and number, etc) then I can test those specific files directly.
(2012-11-03, 01:48)Shine Wrote: [ -> ]Fix DXVA rendering by turning off 10/16bit rendering
While I was at it, I also fixed a typo in elupus' commit.

Witch is ? I'm interested too by this one.
I've experimented with frodo beta3 today. H10p multithreaded decoding appears to work out of the box (dxva decoding turned off). However, screen stays black when there is render method dxva selected (pixel shader does work). See Shine's comment/fix about 10/16bit rendering.
So has anyone tested Hi10 bit media on the new Frodo RC1 or RC2? and if so any problems/fixes still to be sorted?
Works great for me. I can't see any issues with it.
I've had issues with non-10bit anime (and maybe non-anime, but I cant remember the specific video) not playing correctly in Frodo RC2, I ended up switching back to Eden because of it.
I have a few framedrops, but not enough to really notice.
I've been fairly religiously upgrading OpenELEC Frodo since the unofficial builds started. I find it to be very stable and works very well on my E2140 (well, it can't handle 10-bit 1080p material, but that's an issue of CPU power). Since so much of my material is 10-bit now I've actually removed my discrete card and just use software processing for everything.

The only real problem I have with it is http://trac.xbmc.org/ticket/13286 which I've worked around by having XBMC restart when I resume from sleep.
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