• 1
  • 26
  • 27
  • 28(current)
  • 29
  • 30
  • 48
Solved 10-bit h264 (Hi10) Support?
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 ?

Reply
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.
Reply
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 :
Image

MT version :
Image

Test with the following file (ANK-RAW BR-Rip episode 13 of Fate Zero) :
Code:
Général
Identifiant unique                       : 184074841174537091420468151215490824220 (0x8A7B865D65D2DF1B9ABEFBEE406F781C)
Nom complet                              : E:\PB_XBMC\Fate Zero - 13_Hi10P_Test.mkv
Format                                   : Matroska
Version du format                        : Version 2
Taille du fichier                        : 2,27 Gio
Durée                                    : 26mn 54s
Type de débit global                     : Variable
Débit global moyen                       : 12,1 Mb/s
Date d'encodage                          : UTC 2012-03-14 14:06:59
Application utilisée                     : mkvmerge v4.2.0 ('No Talking') 編譯於 Jul 28 2010 18:38:23
Bibliothèque utilisée                    : libebml v1.0.0 + libmatroska v1.0.0

Vidéo
ID                                       : 4
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Profil du format                         : High [email protected]
Paramètres du format, CABAC              : Oui
Paramètres du format, RefFrames          : 9 images
Type de muxing                           : Header stripping
Identifiant du codec                     : V_MPEG4/ISO/AVC
Durée                                    : 26mn 54s
Type de débit                            : Variable
Débit nominal                            : 6 000 Kbps
Débit maximum                            : 40,0 Mb/s
Largeur                                  : 1 920 pixels
Hauteur                                  : 1 080 pixels
Format à l'écran                         : 16/9
Images par seconde                       : 23,976 Im/s
Espace de couleurs                       : YUV
Sous-échantillonnage de la chrominance   : 4:2:0
Profondeur des couleurs                  : 10 bits
Type d'image                             : Progressif
Bits/(Pixel*Image)                       : 0.121
Titre                                    : ANK-Raws
Bibliothèque utilisée                    : x264 core 120 r2164+649+26 fcfb618 tMod [10-bit@all X86]
Paramètres d'encodage                    : cabac=1 / ref=10 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=11 / psy=1 / fade_compensate=0.00 / psy_rd=0.60:0.00 / mixed_ref=1 / me_range=48 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=6,3 / fast_pskip=1 / chroma_qp_offset=-2 / threads=18 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=8 / b_pyramid=1 / b_adapt=1 / b_bias=1 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=0 / bitrate=6000 / ratetol=1.0 / qcomp=0.60 / qpmin=15 / qpmax=34 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=40000 / vbv_bufsize=50000 / nal_hrd=vbr / ip_ratio=1.40 / pb_ratio=1.30 / aq=3:1.00
Langue                                   : Anglais
Default                                  : Oui
Forced                                   : Non
Coordonnées de chromaticité              : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Caractéristiques du transfert            : BT.709-5, BT.1361
Coefficients de la matrice               : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID                                       : 1
Format                                   : FLAC
Format/Info                              : Free Lossless Audio Codec
Identifiant du codec                     : A_FLAC
Durée                                    : 26mn 54s
Type de débit                            : Variable
Canaux                                   : 2 canaux
Position des cannaux                     : Front: L R
Echantillonnage                          : 48,0 KHz
Profondeur des couleurs                  : 24 bits
Bibliothèque utilisée                    : libFLAC 1.2.1 (UTC 2007-09-17)
Default                                  : Oui
Forced                                   : Non

Texte #1
ID                                       : 2
Format                                   : PGS
Type de muxing                           : zlib
Identifiant du codec                     : S_HDMV/PGS
Identifiant du codec/Info                : The same subtitle format used on BDs/HD-DVDs
Default                                  : Oui
Forced                                   : Non

Texte #2
ID                                       : 3
Format                                   : PGS
Type de muxing                           : zlib
Identifiant du codec                     : S_HDMV/PGS
Identifiant du codec/Info                : The same subtitle format used on BDs/HD-DVDs
Default                                  : Non
Forced                                   : Non

Menu
00:00:00.000                             : :Chapter 19
00:01:17.995                             : :Chapter 20
00:02:48.043                             : :Chapter 21
00:08:25.881                             : :Chapter 22
00:13:00.155                             : :Chapter 23
00:13:43.782                             : :Chapter 24
00:20:15.465                             : :Chapter 25
00:24:59.707                             : :Chapter 26
00:26:29.714                             : :Chapter 27
00:26:52.612                             : :Chapter 28

Non MT version :
Image

MT version :
Image

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 ! Confused

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.
Reply
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 Big Grin, just install the build you want (with or without a0fc63d) and done.
Reply
(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.
Reply
Second test may be less obvious, but first is ! You can clearly see on the non MT version that one CPU has an obvious load, and on the MT version no CPU has obvious load. You can even clearly see the begining and the end of the play (the spikes).
Reply
(2012-04-13, 00:06)Shine Wrote: 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.
As ffmpeg ticket you point state something obvious : Either you do SW decoding (with mt), either you do HW decoding, but not both, it make no sense.

Unfortunately, non sliced sources will probably represent more than 99% of the files.

I think, as you said, the following should be done :
- If DXVA is enabled, force thread to slice, if DXVA is disabled, do not force thread to slice.

After, what i think is :
If someone's CPU is not powerfull enough to decode a 8bit h264 (even with mt), and must use GPU, it will never be able to play 10bit files, so for it, having finaly mt only on slice will have no effect.
If CPU is powerfull enough to play 10bit files (either without mt or only with mt), it can even more play 8bit files, so not having DXVA will finaly have no effect.

I will personnaly for now use only the mt version maruchan build (thanks), and probably stick to it and not even try nightlies if i don't see anything related to this point in the commits. Or, any updated build without the a0fc63d people may do.
Reply
For those of us that use XBMC on Linux and want Hi10 you can always build it from GIT. I did yesterday and have been testing on various Hi10 anime with no noticable problems at all. But I won't say that it is ALL stable because I haven't checked it out for that long yet. Seems promising though Smile
Reply
Would it make a difference if I upgrade my coreavc or cccp codecs?
I am running W7 X64 on a zotac zbox ad02 with amd fusion 350 cpu and ati hd 6310 apu ?

I don't know if XBMC uses external codecs to encode video, or that it only uses internal codecs...
Following this, which codecs are needed, and what settings i have to change from standard install, to enhance 10bit playback ?

Also, I am a little confused about the dxva setting in xbmc, should it be turned on or off in these latest releases ?
Reply
(2012-04-13, 10:55)s1l3nc0r Wrote: Would it make a difference if I upgrade my coreavc or cccp codecs?
No.

(2012-04-13, 10:55)s1l3nc0r Wrote: I am running W7 X64 on a zotac zbox ad02 with amd fusion 350 cpu and ati hd 6310 apu ?
This is your problem. One woud think you could take the hint from one of my previous posts.

(2012-04-13, 10:55)s1l3nc0r Wrote: Also, I am a little confused about the dxva setting in xbmc, should it be turned on or off in these latest releases ?
Turn it on and stay away from Hi10P and other codecs that require SW decoding.
Reply
If I would sell my zotac zbox ad02, what mini-pc would I need to buy to properly play Hi10p encodes ?
Reply
(2012-04-06, 03:18)maruchan Wrote: XBMCSetup-20120405-fc6564d-dx.zip
XBMCSetup-20120405-fc6564d-dx-mt.zip

Just wanted to thank for the uploaded files and add some experiences with my system.
All hi10p-files are working perfectly fine on my system now.
Tested with 720p and 1080p material from different fansub-groups (coalgirls, Haneda, ss-eclipse etc...)

CPU-Usage around 15-25%
Memory: 24-28%

My System:
Intel i3 2120 2*3,3GHz
Asrock H67
2*2GB Kingston HyperX
Vertex2 120GB (Videofiles via LAN (1Gbit)
AMD HD 6450 1GB
Windows 7 Prof. 64Bit
Last Distribution of xbmc 11 Eden
Reply
Would this config be able to play all Hi10p encodes properly?

AMD A6-3500 (Boxed, "Llano")
ASRock A75M-ITX (Retail, RAID, Gb-LAN, Sound, Mini-ITX)
Antec ISK 310-150 (Retail, 150 Watt)
Kingston HyperX 4 GB DDR3-1600 Kit (Light-Retail, KHX1600C9D3K2/4GX, Genesis, XMP)
OCZ Vertex 2 60 GB SSD
W7 X64 Ult
Reply
(2012-04-16, 12:09)s1l3nc0r Wrote: Would this config be able to play all Hi10p encodes properly?

Considering not all 10-bit encodes are created equal and there are other factors involved, it's impossible to say. For example, try Tsukimi's Acchi Kocchi episode 2 starting at 19:53 if you want to give your system a real workout. Although admittedly it's a bit of a cheat, since it's the subtitles that's causing the excessive CPU use and ground my E2140 to a complete halt (with the 8-bit version decoded via VDPAU - the 10-bit would be much worse).
Reply
(2012-04-10, 03:21)Ned Scott Wrote:
(2012-04-09, 21:19)radx Wrote: Thanks for your input!
Do you think hardware acceleration support for hi10p/1080p will be possible in future releases or do you think we will always be stuck to software decoding the stuff?

We're going to be stuck on software decode at least until the next big shift, which will likely be for h.265/HEVC, which will beat the pants off of High Profile and Hi10P. Really awesome stuff, but HEVC only just started their first draft standard and is planned for a final draft next year. Even then it will take the market a while for those hardware decoders to be wide spread, and there's no guarantee that Hi10P will also be added.

You have to remember that Hi10P isn't a new codec/profile, it's actually 8 years old. It just wasn't meant to be used in the consumer space, so no one bothered to support it in any consumer hardware. The only people using Hi10P in mass are anime fans in the last year or so, and in the big picture they make up a very small fraction of the hardware decoding market. There's no reason for companies to pump out new hardware decoding chips for Hi10P, especially with h.265/HEVC so close.

In other words, we're going to have maybe another year of this Hi10P stuff, then everyone is going to jump ship to h.265/HEVC.

Thanks for your input. I guess i will just have to upgrade my hardware and then it wont matter much really. I'd have enough CPU power either way.
Thanks for the input though. Hat off. Smile
Reply
  • 1
  • 26
  • 27
  • 28(current)
  • 29
  • 30
  • 48

Logout Mark Read Team Forum Stats Members Help
10-bit h264 (Hi10) Support?7