Solved Issue 10-bit h264 (Hi10) Support?

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.

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

Should we delay a release while we deal with fallout from merging up FFmpeg ? It takes two-three months of such a major change running in nightlies before I'm convinced that it is stable.

10-bit h264 will effect a very small percentage of xbmc users, should we penalize the others (pushing out a stable release) while we wait ?

Inquiring minds want to know but it's been decided to freeze for a release and deal with FFmpeg (and other things) in the next cycle.

Ned Scott Wrote:You are correct in that I choose my wording there poorly. I'm actually somewhat familiar with these high-end profiles/formats that are mainly used in professional/studio situations, though I am far from being an expert. For example, most people don't know that the Beta Cassette didn't die. It stayed alive in the professional word and even got a digital version that some still use today.

Ironically I think I may have seen some of those pass through a few weeks ago, as I work for a company involved in broadcasting

Quote:Hi10 has been around for 7 years and no one gave a hoot until this season. Why? Because someone was finally able to drum up some hype. Probably because they finally got a consumer player that decided to throw in Hi10 support (not out of demand, though).

People are downloading archive quality rips and are worried about saving some HDD space? (some of the quoted numbers by some groups about how much space is really over blown, too).

I tended to blame the increase in interest not so much on hype, but simply that it's supported by x264 now, and decoding has been incorporated into CCCP, which seems to be the rough guidepost that a lot of these groups go by loosely. I don't follow the encoding standards heavily except when it becomes necessary, but I have at least noticed that trend.

In terms of the efficiency, well I guess it depends on the encoder, the settings (and how anal they are) and the actual source material itself. It does seem to allow for smaller equivalent quality releases, or higher image quality at a given size. How much depends on whats thrown into it, but as far as it goes, this is always going to be one of the grails of video encoding, and in, perhaps even what could be a limited situation, it does seem to be making some moderate space savings.

Whilst the efficiency of the original encodes could be debated, the simple fact I've seen a few releases whilst looking into Hi10, that almost halved from the original release and yet people are reporting they look identical to the original, well I can't say that's not potential, even if it is caused by perhaps over sized originals or overt attention to things like film grain.

At the end of the day, even if you're creating archivable copies; the last thing you want to do is waste space unnecessarily (as simply put it's waste), if people didn't still want to save space we wouldn't reencode files, which we do, because we can often factor the size of the file down by 20%+ with no visible side affects.
Wasted space is still wasted space If I can have my same file playback fine, but be stored in a file format that might save me another 20%...well, I'd be tempted to do so; it's less hard drives I need to buy etc etc

I guess the true question is, for the given show/medium/whatever, is the space saving or picture quality improvement, worth the increase in CPU requirements. I suspect for some media and shows it won't, but for other sources or media it might be; but again this sort of argument is always going to have an ounce of opinion

Quote:The PS3's limitation is not because of the hardware acceleration (which does exist in the PS3) or the CPU. It's just been locked away for so long, and even now is completely undocumented for the public.

I'd always understood the reason the original model PS3 doesn't support HDA bitstream whereas the Slimline does, is because the original utilised a realtek HDMI chip which simply doesn't support the format; whereas the slim model used an updated chip, which was why I'd used it in an analogy to the hardware video decoding Could be wrong but it seemed appropriate in this sense.



To be fair it seems we're not on a too dissimilar page with thoughts on this movement, I'd also rather for everyone's sake (it makes people's lives easier), that the groups would release both formats, rather than just one; but I also see why groups are moving now there is support in various players, CCCP etc, and in this case the target relevant source media benefits from the change in encoding standard, offering good potential bitrate savings whilst still retaining equivalent picture quality and reducing other artifacts.

alexrose1uk Wrote:I'd always understood the reason the original model PS3 doesn't support HDA bitstream whereas the Slimline does, is because the original utilised a realtek HDMI chip which simply doesn't support the format; whereas the slim model used an updated chip, which was why I'd used it in an analogy to the hardware video decoding Could be wrong but it seemed appropriate in this sense.

That's a brain fart on my part. I was thinking you were talking about video hardware decoding on the PS3. I must have glossed over the words "audio" and "bitstream".

I was hoping to make a post to dive more into what is really saved with Hi10. I've already read a few posts on some other sites where a lot of drastic comparisons (just about anything above 25% file size savings) had more to do with a bad original. One site that even calls itself something like hi10anime.com or whatever was using speed sub releases to compare with Hi10 releases. Speed subbers don't just rush translations.. they rush encodings too. However I don't really have much time left today (today-ish. I sleep mid day and work at night) to look more into it or do my own testing, but it sounds like I'm probably not giving you guys as much credit as I should have, and you're all already taking the drastic claims with a gain of salt :)

Though still, a 10-25% file savings is pretty good. I certainly don't shun the additional option to save on HDD space.

If I were an encoder for a group that wanted to support Hi10 I would either do two releases at once, or just do normal h.264 HP for the TV airings, then do Hi10 for the batch and/or BD version (depending on the group, since some don't bother doing a BD version for their subs directly). That way the version best suited for saving has the small file size, while the weekly TV broadcast has the compatibility. Although I do understand that download times and ISP data caps are a concern too.

Ned Scott Wrote:If I were an encoder for a group that wanted to support Hi10 I would either do two releases at once, or just do normal h.264 HP for the TV airings, then do Hi10 for the batch and/or BD version (depending on the group, since some don't bother doing a BD version for their subs directly). That way the version best suited for saving has the small file size, while the weekly TV broadcast has the compatibility. Although I do understand that download times and ISP data caps are a concern too.

_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.

Ned Scott Wrote:

magao Wrote:BTW, we've been arguing on those forums for months as well that the infrastructure isn't ready except in a few very specific cases. In every case the response has basically been "use the exact same setup as me or STFU".

I am honestly sorry if that is how I made you feel.

Not you - I meant on the fansub sites. The response here has been more uninterested than hostile.

I might see if I can integrate the latest ffmpeg myself, but having no experience with the XBMC codebase or libffmpeg, and probably starting a new job in the next week or so ...

davilla Wrote: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.

davilla Wrote: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.

alexrose1uk Wrote: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.

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.

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).

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?