[magao]

10-bit h264 requires moving to FFmpeg head.
10-bit h264 is there but still being worked on by FFmpeg devs.
FFmpeg head will not compile for iOS.
FFmpeg has many corner decoder cases to check, verify, fix if broke.

Thanks davilla - that's exactly the kind of information I was looking for. As far as I could tell, 10-bit support in ffmpeg was fairly complete, but I've been looking at it very much from the outside.

Should we delay a release while we wait for 10-bit h264 in FFmpeg to complete ?

Given those issues, definitely not.

I think there may have been a lot less aggravation and discussion if this had been made clear earlier. I (and others I think) were under the impression that ffmpeg 10-bit support "simply" required whatever work was necessary to integrate ffmpeg. I think I got this impression because someone successfully did the integration for mplayer2. Also there were several comments along the way to the effect that a newer version of ffmpeg would be incorporated into Eden ... so I thought I was merely pushing for something to get done earlier, rather than being an additional feature.

I might have a look at exactly what version of mplayer2 has 10-bit integrated and see what hoops they had to jump through to make it work.

[magao]

In terms of hardware requirements; I think the damage isn't going to be quite as bad as people expect unless computers are REALLY pushing it on the specification side.

To see what reasonably could be expected, this evening I threw a Hi10p 720 OP sequence through MPC-HC using LAV on an old AMD X2 3800+ machine (with subs enabled which causes higher CPU usage). It actually ran with no drops, CPU usage was a little on the high side (about 70-80%) at points but it was definately playable.

In terms of XBMC though I'm pretty sure it's limited to only using a single core for decoding - the ffmpeg-mt patches didn't land until March, and XBMC uses the February ffmpeg.

However, 10-bit was added to ffmpeg after the MT patches landed, so it's probably a fair test.

[Yappa]

Guess http://forum.xbmc.org/showpost.php?p=853...stcount=11 was too optimistic, then, considering the last few posts of the XBMC team. So no Hi10 until sometime in 2012?
The wait continues. At least I am hopeful that it's only a matter of time, in contrast to "ordered chapters", which UTW also started using. They're going all out to screw over XBMC users, it seems.

[magao]

Admittedly UTW said they're only doing ordered chapters in this one particular case due to the resultant size of the OP. Still annoying, but I can live with it (there are very few OPs that I want to watch every time anyway).

[wsippel]

I don't really know how XBMC works, but considering there is a replacement for DVDPlayer, wouldn't it make sense to throw that part out altogether and just use vanilla MPlayer or Mplayer2 instead? I honestly didn't even realize there are issues with hi10 at first, as I usually use various MPlayer frontends, and MPlayer handles hi10 just fine. XBMC is mostly about the library and interface, right?

[Ned Scott]

_ar of UTW seems to have gone for a half way position which is at least reasonable; he's stated that the 10bit release will be standard, and they'll also continue to release XVID compatibility files; however if they find the demand is still there, they will release 8bit files at a later date; although these will be post original release (likely because encoding takes time and these people must have jobs and lives away from the PC)


******

In terms of hardware requirements; I think the damage isn't going to be quite as bad as people expect unless computers are REALLY pushing it on the specification side.

To see what reasonably could be expected, this evening I threw a Hi10p 720 OP sequence through MPC-HC using LAV on an old AMD X2 3800+ machine (with subs enabled which causes higher CPU usage). It actually ran with no drops, CPU usage was a little on the high side (about 70-80%) at points but it was definately playable.

Now that X2 skt939 chip is EASILY 5-6+ years old, one of the first dual core chips on the market; if it can handle 720p Hi10p video reasonably with a decent video decoder (admittedly on a not overloaded PC, but then loads of ***** running can bring almost anything to it's knees eventually), then I'm perhaps not as worried as I was that this'll cause major issues for people; most people except those using netbooks/media boxes should have something more capable than that machine; and it's not like everyone NEEDS to be able to run 1080p feeds.

But that's why I bring up this problem here on the XBMC forums. People who use XBMC aren't watching downloaded shows 2 feet away on their nice powerful computers. Video playing and casual internet usage is drastically moving to things like ARM processor devices and ATOM processor computers. It's an almost bizarre trend (in some perspectives) where we see the public actually moving in mass to slower machines that are simply more specialized for their tasks.

We can pump out hardware on a tiny board for $30 that will run 1080 h.264 High Profile. TVs are themselves are starting to support running applications of some kind (one day you probably won't even have a separate box for XBMC. It will just install on the TV.). They can do all of this because major content providers are planning on supporting h.264 High Profile for several years to come.

The trend is internet-based TV moving away from the computer. These anime group encoders can't seem to wrap their heads around that. The really funny part is that I think they would totally rethink this if they themselves experienced how nice it is to have an XBMC box, and if they knew how easy and inexpensive it was to set up.

[Ned Scott]

I don't really know how XBMC works, but considering there is a replacement for DVDPlayer, wouldn't it make sense to throw that part out altogether and just use vanilla MPlayer or Mplayer2 instead? I honestly didn't even realize there are issues with hi10 at first, as I usually use various MPlayer frontends, and MPlayer handles hi10 just fine. XBMC is mostly about the library and interface, right?

short answer: no. From what I understand it wouldn't make the work load any easier, it would actually increase it. Changing to a totally new internal player and making sure everything internal in XBMC works nicely with it would be a much bigger task than upgrading the ffmpeg component of DVDPlayer.

Why this actually is? I don't fully understand the technical side of it, so a dev would have to go into details about that.

[Ned Scott]

I've been talking with some people about this, and there are indeed some temp solutions out there to hold the Hi10 users over till the internal ffmpeg upgrade. I plan on throwing up a wiki page or two on the XBMC Wiki to outline. Solutions include setting up an external player on different platforms as well as possibly using the updated ffmpeg via XBMC for Linux, which can use an external ffmpeg library.

The Linux option is really great because you can throw it on a USB stick, copy all of your existing settings, and then use that USB drive to boot just about any computer into XBMC without having to change any internal files. Also, more demanding skins/codecs on older computers will run better because the linux-based OSes have far less overhead. Granted a lot of people will not want to reboot just to use XBMC, but it's a nice option if you just want to try it without having to install anything.

There could also be more than just these two solutions (external players and XBMC for linux). Hopefully in a few days we'll have some XBMC Wiki pages set up with easy to use instructions and more information. I'm going to write up a new post for a new thread here in a bit for this specific endeavor and will post back in this thread with a link there for anyone who wants to help.

[sialivi]

Lots of talk about anime and blu-ray, but one thing that seems to be left out of the discussion is consumer created content: Affordable hd camcorders that support extended gamut (xvYCC/x.v.Color) are already available. Modern TV's, graphics cards, and amplifiers with hdmi 1.3+ are all capable of handling 10-bit+ content... but xbmc doesn't. It might seem like a pointless trend to some people, but maybe I want to archive my family videos in the best possible quality. Discarding color information by using an unsuitable encoding profile is the equivalent of telling an audiophile that lossy compression is good enough.

[Ned Scott]

Lots of talk about anime and blu-ray, but one thing that seems to be left out of the discussion is consumer created content: Affordable hd camcorders that support extended gamut (xvYCC/x.v.Color) are already available. Modern TV's, graphics cards, and amplifiers with hdmi 1.3+ are all capable of handling 10-bit+ content... but xbmc doesn't. It might seem like a pointless trend to some people, but maybe I want to archive my family videos in the best possible quality. Discarding color information by using an unsuitable encoding profile is the equivalent of telling an audiophile that lossy compression is good enough.

You mean like AVCHD cameras which supports xvYCC? XBMC already supports AVCHD (ffmpeg added support for it a few years back). Just tested it right now with some video I shot on my 1080 Canon camcorder (model number escapes me, but the files are in AVCHD). XBMC does handle 10-bit content, just not the specific h.264 Hi10P profile.

You would only have a problem if you re-encoded your files to h.264 Hi10 rather than keeping them in AVCHD (which is h.264 + extras), which you wouldn't want to do if you wanted to keep them in the best possible quality.

[wsippel]

I've been talking with some people about this, and there are indeed some temp solutions out there to hold the Hi10 users over till the internal ffmpeg upgrade. I plan on throwing up a wiki page or two on the XBMC Wiki to outline. Solutions include setting up an external player on different platforms as well as possibly using the updated ffmpeg via XBMC for Linux, which can use an external ffmpeg library.

The Linux option is really great because you can throw it on a USB stick, copy all of your existing settings, and then use that USB drive to boot just about any computer into XBMC without having to change any internal files. Also, more demanding skins/codecs on older computers will run better because the linux-based OSes have far less overhead. Granted a lot of people will not want to reboot just to use XBMC, but it's a nice option if you just want to try it without having to install anything.

There could also be more than just these two solutions (external players and XBMC for linux). Hopefully in a few days we'll have some XBMC Wiki pages set up with easy to use instructions and more information. I'm going to write up a new post for a new thread here in a bit for this specific endeavor and will post back in this thread with a link there for anyone who wants to help.

Only the Linux version of XBMC supports ffmpeg drop in replacements? Odd.

[bobo1on1]

XBMC has to be compiled against a certain version of ffmpeg, because there's no standard way of installing a library and headers on windows, we can't support external ffmpeg, simply because we can't use something that doesn't exist.

[wsippel]

XBMC has to be compiled against a certain version of ffmpeg, because there's no standard way of installing a library and headers on windows, we can't support external ffmpeg, simply because we can't use something that doesn't exist.

Thanks for the clarification. Never did any Windows development, so I had absolutely no idea. So this would only work on Linux (and probably any Unix-like OS including OSX)?

Allow me a different question, then: If Unix-like operating systems support an external ffmpeg library, am I correct to assume that you use ffmpeg as is, not a fork, and simply don't want to sync the library every other day to maintain stability? In that case, wouldn't a build compiled against ffmpeg head (or libav I guess) be little to no work, but simply not fit for general consumption due to stability concerns? Or are there substantial (Windows specific) modifications to ffmpeg required?

[davilla]

Allow me a different question, then: If Unix-like operating systems support an external ffmpeg library, am I correct to assume that you use ffmpeg as is, not a fork, and simply don't want to sync the library every other day to maintain stability? In that case, wouldn't a build compiled against ffmpeg head (or libav I guess) be little to no work, but simply not fit for general consumption due to stability concerns? Or are there substantial (Windows specific) modifications to ffmpeg required?

1) your assumption is wrong...

2) Be little to no work? you have to be kidding right ? I suggest you subscribe to the ffmpeg/libav mailing lists to see what goes on.

if you are going to die if you don't get hi10, then run xbmc with an external player of your choosing and be done with it.

[magao]

possibly using the updated ffmpeg via XBMC for Linux, which can use an external ffmpeg library.

This is the approach I've been wanting to try. A wiki would really help. Once that's done I've just got to work out how to integrate it into OpenELEC ...