• 1
  • 27
  • 28
  • 29(current)
  • 30
  • 31
  • 48
Solved 10-bit h264 (Hi10) Support?
I seem to be having a problem updating my library with both the -mt and non mt build. I'm using mysql to store my library info, the stock eden build allows me to properly update my video library using this setup, while these 2 builds would not properly update them. I use smb://server/share format as my source entries. Anyone having the same issues?

Note: Shine's older build seems to be updating properly, although I'm having playback issues with that build.
Reply
Forget any hw decoders doing anything but standard h264. We just got solid h264 hw decoding in the last few years and I seriously doubt that anyone doing hw decoders to care about a less than 1 percent market.

So pony up with a strong CPU and no whining about it when the fans kick in Smile
Reply
Can someone tell me if one of the latest nightlies contains the latest ffmpeg version to play Hi10p enocdes (or point me to a page where I can find some sort of changelog on latest releases.)
Reply
Yes, all the latest nightlies contain the updated FFMPEG. Keep in mind that it will only do single-threaded decoding.
Reply
(2012-04-25, 17:24)maruchan Wrote: Yes, all the latest nightlies contain the updated FFMPEG. Keep in mind that it will only do single-threaded decoding.

this is the best news since ... xbmc was created ! thank you so much for all the work ... this made my day !

btw its working like a charm on my old macbook core2duo with a crystalHD ... cpu is still very low
Reply
(2012-04-25, 18:36)lad1337 Wrote:
(2012-04-25, 17:24)maruchan Wrote: Yes, all the latest nightlies contain the updated FFMPEG. Keep in mind that it will only do single-threaded decoding.

this is the best news since ... xbmc was created ! thank you so much for all the work ... this made my day !

btw its working like a charm on my old macbook core2duo with a crystalHD ... cpu is still very low

I have to say I'm pretty happy about this too.
Reply
(2012-04-25, 17:24)maruchan Wrote: Yes, all the latest nightlies contain the updated FFMPEG. Keep in mind that it will only do single-threaded decoding.

Hm, so what's the difference to the two builds that you posted here 20 days ago?
I am currently using the mt build as my main XBMC player - also have a DSPlayer version for anime with ordered chapters - and so far I am pretty satisfied with it.
Reply
I posted two builds previously--the standard build, and the 'mt' build. The mt build allows multithreaded decoding of hi10 content, but breaks DXVA decoding; the standard build is compatible with DXVA decoding, but only decodes video in a single thread. Both allow you to play 10-bit video, but the mt build may help weaker CPUs that struggle when decoding hi10 content.

For now, the nightlies take the approach of single-threaded, DXVA support. If you have a decently powerful CPU, this will be fine. Hopefully the devs can figure out a way to get the best of both worlds, with multithreaded decoding for all non-DXVA accelerated content. From what I understand, there are some architectural issues that need to be solved first.
Reply
For now, what i think a very simple thing to do, would be to simply not disable multi-threading if DXVA is not activated in the settings.
I don't understand why dev haven't implement yet this simple thing... Sad
Reply
we figured it was so simple, we have left it to you.
Reply
That's why i've said "i think". I should have said "what's seems".
The a0fc63d patch is the following :
Code:
+  /* Only allow slice threading, since frame threading is more
+   * sensitive to changes in frame sizes, and it causes crashes
+   * during HW accell */
+  m_pCodecContext->thread_type = FF_THREAD_SLICE;

Well, maybe it could "simply" be changed by :
Code:
if ("dxva is enabled") {m_pCodecContext->thread_type = FF_THREAD_SLICE;} else {m_pCodecContext->thread_type = "value wich allow frame threading";}
As i said, it seems easy, but you're the devs, not me. I don't know, how difficult it can be to get the "dxva enabled" information in this part of the code.

Of course, if this part of the code is called only once at the startup of XBMC, it's not good because change in settings will not be taken in, but if this part of the code is called each time a file is played (at the init of DVDPlayer), well, at first glance i don't realy see any trouble.
I'm using the "-mt" version maruchan build since it's been posted, and have encounter any problem in all the files i've played for now (i've dxva disabled of course).
Reply
I think I remember reading that FFMPEG decides whether or not to use multithreaded decoding before it's decided whether or not to use hardware acceleration, so you cannot simply have a conditional "if not DXVA then multithread", because you cannot know whether or not DXVA is supported that early on.

Perhaps there's a way to default to multithreading, then wait to see if hardware acceleration is supported; if it is, re-init playback with multithreading disabled. This would come at a hit in initial playback speed, however.

As a note, if there's one thing that developers hate hearing, it's that something is "simple." Trust me, some seemingly simple things can be a huge pain in the ass to implement.
Reply
(2012-04-26, 14:51)maruchan Wrote: I think I remember reading that FFMPEG decides whether or not to use multithreaded decoding before it's decided whether or not to use hardware acceleration, so you cannot simply have a conditional "if not DXVA then multithread", because you cannot know whether or not DXVA is supported that early on.

Yes, but i'm not talking about the fact DXVA is supported, i'm talking about the fact DXVA is enabled in the UI settings. I can perfectly understand that at this stage you may still don't know if DXVA is supported, but you always know if DXVA is enabled or not in the UI settings.
This is why in the code i've wrote "dxva is enabled" and not "dxva is supported". What you're talking about is realy more complex that what i suggest.
Now, the only thing i see wich may be difficult or tricky, is to have access to this information inside the specific function this code is. If this information is easely avaible by any variable/class/structure already passed down to the function, i'm even more convinced "it's easy". If not, it may be indeed more difficult, as information must be pass down, wich indeed in that case can affect a lot of functions to modify to pass this parameter.
But i'm still convinced that it's for now the easiest (but maybe not simple Wink) way to enable multi-threading.

(2012-04-26, 14:51)maruchan Wrote: As a note, if there's one thing that developers hate hearing, it's that something is "simple." Trust me, some seemingly simple things can be a huge pain in the ass to implement.
I know, it's my little mistake and somehow "bad" english, and how i thought i would be interpreted. In my post i should have wrote "It seems (but maybe it's not) simple" and not "I think it's simple".
Reply
But even if DXVA (or other VA technologies for that matter) is enabled you'd still want to have multi-threading for videos that are not accelerated. I don't know, maybe there should be some option, e.g. in advancedsettings.xml to tell a decoder how many threads to use, like it is done in LAVFilters Video.
Reply
Nice, I will give one of teh latest nightlies a go on this system:
A6-Pack
Reply
  • 1
  • 27
  • 28
  • 29(current)
  • 30
  • 31
  • 48

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