Solved Issue 10-bit h264 (Hi10) Support?

(2012-04-10 22:01)Shine Wrote:  in case your files are L4.1, they may very well be sliced.

Not impossible, but very unlikely...
Slice will be probably found only on "true" Blu-Ray rip, without any re-encode.
Otherwise, if it's mkv re-encoded, very probably using x264, slices are disabled by default, and using slice will (even if it's very low) slighty reduce quality.
After, it's only my point of view.

I have an i7@870. Bambi73 version stuttered horribly with a lot of frames drop on a "high bitrate" 1080p 10bits file. This make me thought that my CPU was unable to properly decode this kind of file without mt. But, the both version of maruchan played the same file properly. I should check with media info, if parameters of x264 are shown, if it's encoded with slices or not... and try to find a 10bits 1080p file with higher bitrate.

In my case, understanding the last few posts correctly, it would be impossible for me to play Hi10P 1080p BluRay rips on my Zotac Zbox AD02.
Would the solution posed by user alexrose1uk (external player, using lav filters) give me better results ?

The mediainfo for the file i am trying to play is the following:

General
Unique ID : 245144396668702104186529024829180572207 (0xB86D17EAA7A7674ABCB1D9096A53722F)
Complete name : [UTW]_Fate_Zero_-_01_[BD][h264-1080p_FLAC][50256238].mkv
Format : Matroska
File size : 2.65 GiB
Duration : 47mn 43s
Overall bit rate : 7 953 Kbps
Movie name : Fate/Zero BD - 01: Summoning of the Heroic Spirits
Encoded date : UTC 2012-03-18 13:26:39
Writing application : mkvmerge v5.0.1 ('Es ist Sommer') built on Oct 9 2011 11:55:43
Writing library : libebml v1.2.2 + libmatroska v1.3.0
Cover : Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 10@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 47mn 43s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Scan type : Progressive
Title : H.264 1080p BD
Writing library : x264 core 120 r2164+656 2ff844c
Encoding settings : cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / fade_compensate=1.15 / psy_rd=1.04:0.13 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=6 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=35 / intra_refresh=0 / rc_lookahead=140 / rc=crf / mbtree=1 / crf=17.0 / qcomp=0.80 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.21 / aq=3:0.83
Language : Japanese
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 2
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 47mn 43s
Bit rate mode : Variable
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Title : FLAC 2.0 24-bit
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)
Language : Japanese

Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Title : Styled Subtitles
Language : English

Just watched a video streamed over gigabit Ethernet with the following specs.

Video: 1920x1038 h264 10bit ~5150 kb/s 23.976 fps
Audio: 1: Japanese FLAC 5.1 24 bit@3600 kb/s
Subtitles: 1: English soft subs (.ass)

Only frames drops that where listed in the Codec info happened after resume from a pause. CPU average was 18% with a peak of 25% using the non-MT version.

Hardware it's running on is the following:

Win 7 x64 Ult.
MSI A55M-P35 FM1 AMD A55
AMD A6-3670K Unlocked Llano 2.7GHz (clocked at 3.0GHz)
G.SKILL Ripjaws X Series 8GB DDR3 1866
2x 160GB HDD Raid 0

Only issues I've had is that the MT version would play .264 10-bit just fine but random videos in .264 8-bit would be a black screen at times, the Non-MT version doesn't have this issue. The other issue is 5.1 FLAC audio streams play fine but 6 or 7 channel FLAC streams have no sound. Not sure if this is a config part on my end (using Direct sound SPDIF optical out), a general XBMC issue (not supported?), or a bug with this particular build. Just started to look into this and searching the forums, so I haven't found an answer yet.

Just wanted to post this so people have a system comparison with these new builds.

did this version break sql for anyone else ?

(2012-04-10 17:47)astrotrain Wrote:  

(2012-04-10 14:40)mrpeterparker Wrote:  

(2012-04-06 03:18)maruchan Wrote:  Here's an updated build for everyone to try out. This is the latest from XBMC's main branch, since elupus' branch has now been merged. The '-mt' version is the same build, just with the relevant code from the a0fc63d commit removed. Compare and contrast.

XBMCSetup-20120405-fc6564d-dx.zip
XBMCSetup-20120405-fc6564d-dx-mt.zip

tried the non "mt" build right over the latest eden distro and it worked perfectly for me.!

I also tried the non Mt build and all files play fine, the only issue is Cast Details is broken as well as ass subtitles are stuck on super large setting, can't decrease the font size but everything else works great. Good work on modding the codec engine.

Well, I went and also gave those two builds a go and tried several 8bit and 10bit anime files. For 8bit I disabled DXVA.
I have an Intel i5 750@2,67 MHz with 8 GB RAM.

I got frame drops with the non mt build, while the mt build seems to run perfectly with no frame drops, but with higher CPU use.

I tested for example:

1) The Opening which plays at the end of the already mentioned [UTW]_Fate_Zero_-_01_[BD][h264-1080p_FLAC][50256238].mkv 10bit file
--> No frame drops on the mt build, and like 50 frame drops with the non mt build, e.g. at the beginning of the OP when the camera is flying past under the bridge and when Saber transforms into her battle attire. It doesn't matter whether I play it with or without subtitles.

2) My "8bit frame drop test file" that I already used for past XBMC builds.
You can find it here: http://depositfiles.com/files/i7g4otyyt (32 secs of a Macross Frontier music video)
--> Very high bitrate seems to lead to tons of frame drops on old XBMC builds and the non mt build, while playing perfectly on the mt build

3) The first 2 mins of [Coalgirls]_Mobile_Suit_Gundam_Unicorn_01_(1920x1080_Blu-ray_FLAC)_[CF793FEE].mkv 10 bit
--> Seems to play fine on both builds. That first scene had many frame drops when playing it with bambi73's XBMC version and was one of the main reasons why I switched to DSPlayer at that time.

Quote:That first scene had many frame drops when playing it with bambi73's XBMC version and was one of the main reasons why I switched to DSPlayer at that time.

Did you set it up in the way described by alexrose1uk ?

Yes, I did.

Tested [ReinWeiss] Senki Zesshou Symphogear - 13 [Commie-Modified][10bit].mkv which has a scene near the end at 19m48s where the subtitles weren't displayed properly when using DSPlayer.
The subtitles are correctly displayed with both builds, but both suffer from frame drops due to the complex nature of the subtitles. If I turn the subs off, the frame drops are gone.

Here are some records of task manager.

First, results with the Macross file provided by boingman. This is a record of the whole file (you can see spikes at begining and end) :
Non MT version :


MT version :


Test with the following file (ANK-RAW BR-Rip episode 13 of Fate Zero) :

Non MT version :


MT version :


Sentence is unfortunately clear, what i was afraid of is indeed true : Allowing MT only on slice will result on no multi-threading, because except on Blu-Ray, h264 streams are not encoded with slices !

THERE IS NO MULTI-THREADING ON STANDARD VERSION

More : The "slice only" has been done to solve a compatibility problem between dvxa and mt, but i think it solves nothing, because tests were probably done with h264 streams without slices. So, there were no mt when test files were played. If a file with slices is indeed played, there is a very high probability that the compatibility problem occurs again.
At this point, unless problem is solved by a patch, the only solution i see is something in the video options, asking if you want mt software or dvxa.

What's bothering me is the total silence of elupus (i nevertheless thanks a lot for his work) on the subject !
Either he doesn't have time because of RL, either he's trying to avoid the problem doing the austruch.

The problem is likely on ffmpeg side, see ffmpeg ticket #604. So there's no easy fix for it on XBMC side. At the point where XBMC decides whether to use DXVA or not (CDVDVideoCodecFFmpeg::GetFormat), the ffmpeg context is already set up, so changing thread count (to 1) or threading mode (to slice) won't have any effect anymore.

Other sources I found suggest that the issue indeed occurs only in frame threading mode, not slice threading mode. So a0fc63d should fix it for all sources, even sliced ones - unfortunately with the downside of completely disabling mt decoding for non-sliced sources.

(2012-04-12 20:08)jpsdr Wrote:  At this point, unless problem is solved by a patch, the only solution i see is something in the video options, asking if you want mt software or dvxa.

That'd be easy to do (ie. force thread mode to slice if DXVA is enabled in the video options), but not intuitive at all for the end user. And since XBMC is in pre-alpha phase now, not even nightly builds available, there's no need for such an ugly hack. If you're masochistic enough to use pre-alpha builds from shady sources , just install the build you want (with or without a0fc63d) and done.

(2012-04-12 20:08)jpsdr Wrote:  Here are some records of task manager.

Just a suggestion for people doing this kind of test in the future - set the affinity for XBMC to just 2 real cores so it's a lot more obvious how much processing is occurring on each core. With the above test most of the MT processing is lost in the noise.

By real I mean make sure the two "processors" you select are not hyperthreads on the same core e.g. if you have a 4 core/8 thread CPU (like I suspect the above is) then make sure you don't set affinity to 0 and 1 but instead 0 and 2.