CAINEv2

I apologize in advance if this is in the wrong category ^^;

I'm genuinely interested in hearing what kinds of playback setups people use to watch their downloaded anime. Do you prefer codec packs like CCCP or KLite, custom directshow setups, or something else entirely?

Have questions about subtitle rendering, what "10-bit" means, or why you should use a renderer that obeys colorimetry flags? Shoot!
_________________
el psy congroo

CCCP all the way.

In addition I use CoreAVC.

Having a lower end PC I loathe 10-bit h264, as it cannot be hardware decoded.  It's doubly pointless anyway, seeing as how the broadcasts are in 8-bit and it has to be dithered back down to 8-bit to be processed by the graphics card and displayed on the screen anyway.  You don't gain any extra quality by stretching the 8-bit color space over the 10-bit one, any values that result that can't translate directly back to 8-bit are compression artifacts.
_________________

Twitter | Blag | MAGFest 12 - January 2-5, 2014, at the Gaylord (National Harbor, MD)!

Original post by eckstee
Having a lower end PC I loathe 10-bit h264, as it cannot be hardware decoded.  It's doubly pointless anyway, seeing as how the broadcasts are in 8-bit and it has to be dithered back down to 8-bit to be processed by the graphics card and displayed on the screen anyway.  You don't gain any extra quality by stretching the 8-bit color space over the 10-bit one, any values that result that can't translate directly back to 8-bit are compression artifacts.

A common misconception about 10-bit encoding. The reason it is now preferred is that encoding with 10-bit precision, regardless of the source bitdepth, reduces rounding errors and increases compression.

Here is a more in depth explanation. Source: http://x264.nl/

You may want to try the LAV decoder, it's actually faster than CoreAVC at decoding 10-bit (there is, as of yet, no hardware decoding support for 10-bit). That can be found here.
_________________
el psy congroo

lol wut

10-bit refers to the number of bits per color channel of each pixel, meaning each pixel takes 30 bits to store.  In 8-bit, each pixel takes 24 bits to store.  Stretching the smaller color space over the bigger one produces no gain in quality, while actually taking more space to store the color information.

A common misconception among idiot fansubbers (or really, idiot encoders) and the people who believe everything they say blindly is that 10-bit is somehow better.  The issue here is that the original broadcast is already encoded in 8-bit.  You can't pull quality out of thin air, re-encoding something only reduces quality.  If the original broadcast were suddenly 10-bit, then using 10-bit would be worthwhile.  Except that would be prohibitively expensive to implement, because it would require everyone with a TV ever to go out and buy a new TV.

Regardless of anything I highly prefer 8-bit because it's more compatible with everything ever.  I've actually started getting stuff from CR rip groups when the only alternative is a 10-bit encode.
_________________

Twitter | Blag | MAGFest 12 - January 2-5, 2014, at the Gaylord (National Harbor, MD)!

Original post by eckstee
lol wut

10-bit refers to the number of bits per color channel of each pixel, meaning each pixel takes 30 bits to store.  In 8-bit, each pixel takes 24 bits to store.  Stretching the smaller color space over the bigger one produces no gain in quality, while actually taking more space to store the color information.

You're confusing lossless video with lossy quantization. A lossless clip does have exactly X number of bits per pixel, as each pixel has to be a perfect representation of the source. Lossy encodes, however, work with an approximated (quantized) representation of each pixel. Regardless of the source bitdepth, 10-bit video allows for fewer relative errors to the source, resulting - in an ideal situation - in improved compression of up to 20%. Think of the video as a dart board. As you increase the size of the board, you become less likely to miss your mark.

Original post by eckstee
A common misconception among idiot fansubbers (or really, idiot encoders) and the people who believe everything they say blindly is that 10-bit is somehow better.  The issue here is that the original broadcast is already encoded in 8-bit.  You can't pull quality out of thin air, re-encoding something only reduces quality.  If the original broadcast were suddenly 10-bit, then using 10-bit would be worthwhile.  Except that would be prohibitively expensive to implement, because it would require everyone with a TV ever to go out and buy a new TV.

No, you cannot pull quality out of thin air. However, given the increased compression advantages of 10-bit encoding, one can allocate more bits to detail areas, while maintaining "accepted" filesizes. Other advantages relating specifically to anime are nearly-perfect compression of single-color gradients (like bright areas of the frame, or heavily denoised clips) and improved adaptive bitrate allocation (fades, scene changes). All, again, because of the reduction in rounding errors. 8-bit video is far more prone to blocking in those situations, requiring bits to be pulled away from detail areas to compensate.

Most encoders simply aren't very good, or are unable to properly explain the advantages of 10-bit encoding. This has resulted in many a hurf durf post by fansubbers trying to convey information without knowing themselves what they're even talking about.

Original post by eckstee
Regardless of anything I highly prefer 8-bit because it's more compatible with everything ever.  I've actually started getting stuff from CR rip groups when the only alternative is a 10-bit encode.

This is the only remaining valid argument for 8-bit encodes. Hardware-accelerated decoding. Virtually any computer can play 1080p video at very high bitrates without a hitch, if it has a video card with h264 decoding support. The "device" compatibility argument, however, fails on account of sofsub typesetting, which can only be rendered correctly by a small number of players and directshow filters.

It's actually funny, since Crunchyroll started doing 1080p encodes those have (90% of the time) looked better than TV broadcast video. Cruncyroll is given the same HDCAM tapes that television networks broadcast off of, and Blu Rays are encoded from. Intelligent fansubbers have been re-encoding from those for a while now.


Edit: I wrote a tl;dr block-o-text on why re-encoding isn't necessarily a bad thing, but I'll save it for later as it's somewhat off topic....
_________________
el psy congroo

And for the niche that uses hardware devices (game consoles, portable devices, dedicated hardware players), there are groups that do the necessary re-encoding and hardsubbing to make it work.

I suppose if a distinct visual quality increase can be proven, that then you could compress the fuck out of it and end up with something similar to your average 8-bit release at a smaller file size.  Unfortunately, it's difficult to prove because capturing a frame from the same thing encoded both ways requires converting the 10-bit frame to 8-bit.  Image formats, as far as I know, only support up to 8 bits per color channel, and the conversion process would require losing any extra quality that 10-bit might be able to convey.

I'm rather tired of getting seconds per frame and subtitle desyncing during any scene that's more than just a static frame with people talking.  The last two shows I watched in 10-bit were very difficult to watch due to both of those things.  This new 10-bit thing may be better in some cases, but there are still quite many people for which 8-bit always was and always will be fine.

Even after I build the new computer I'm planning on building (for Guild Wars 2...), I'll still prefer hardware decoding simply because hardware will always be orders of magnitude more efficient at doing it than software ever will be.  If this 10-bit thing is going to stick then graphics chipsets really need to support it.  They might support it for display (according to the Wikipedia article Color depth, support for 30bpp color modes and beyond has been around since about 2006, but I've never heard it being used as a selling point, nor seen it on a spec sheet), but currently none support h264 decoding above 24bpp.

(btw, the 32-bit color mode is really just 24-bit color with an 8-bit alpha channel)

Now that we've had a few seasons of 10-bit releases, is there a decent file size comparison out there yet?  Most groups that migrated to 10-bit encodes also dropped 8-bit encodes, so it's really hard to put together a valid comparison.  Smaller file sizes due to being able to compress more is really the only valid argument for 10-bit, but it really needs to be a significant space difference to be worth dumping perfectly good compatibility.
_________________

Twitter | Blag | MAGFest 12 - January 2-5, 2014, at the Gaylord (National Harbor, MD)!

Original post by eckstee
I suppose if a distinct visual quality increase can be proven, that then you could compress the fuck out of it and end up with something similar to your average 8-bit release at a smaller file size.  Unfortunately, it's difficult to prove because capturing a frame from the same thing encoded both ways requires converting the 10-bit frame to 8-bit.  Image formats, as far as I know, only support up to 8 bits per color channel, and the conversion process would require losing any extra quality that 10-bit might be able to convey.

PNGs do support high bit depth. A lot of people have claimed that 10-bit video "somehow" reduces banding without any additional processing. While 10-bit accuracy does allow for smoother transitions between colors, many of these early examples are flawed in that they made comparisons using the FFDShow Video Decoder - the default option for CCCP - which dithers 10-bit video down to 8-bits before sending to the renderer.

Now, this is the great misconception regarding 10-bit video: they think it's all about displaying color. Since most people still use 6-bit TN panels, I think wide adoption of 10-bit IPS,Retina, or OLED displays is a long way off. Not to mention that only a handful of "professional" video cards can actually output 10-video. There are, in fact, very few quality gains to doing this if your encodes are from an 8-bit source. I know, this sounds contradictory to what I just said, hear me out. The 8-bit source material has no additional color information that would benefit one watching it on a 10-bit display. That being said, you can skip an extra dithering step. I've also heard compelling arguments for accuracy... but I won't get into that right now.

Ideally one would use a renderer like madvr, which doesn't apply any extra dithering, has excellent gpu-assisted scalers, and obeys color matrix flags (I'll discuss those more in-depth if someone has questions about typesetting). Some encoders feed upscaled 10-bit video to x264 (the most commonly used h264 encoder), and it is those that would benefit most from watching on a 10-bit panel. The caveat here is that, as previously mentioned, most people are going to be viewing on monitors that will have to dither the image anyway. A good rule of thumb is to never trust decoders or display setups. You can't control how people watch your encodes, so you're better off doing the dithering yourself before hand. I only use 10-bit encoding for the previously described compression and bitrate allocation advantages, feeding the encoder 8-bit processed material.

Original post by eckstee
Now that we've had a few seasons of 10-bit releases, is there a decent file size comparison out there yet?  Most groups that migrated to 10-bit encodes also dropped 8-bit encodes, so it's really hard to put together a valid comparison.  Smaller file sizes due to being able to compress more is really the only valid argument for 10-bit, but it really needs to be a significant space difference to be worth dumping perfectly good compatibility.

If we look at groups with competent encoders. Were I to do a study on the subject, I would use UTW, Underwater, and gg as examples. Commie's encodes no longer count as they intentionally bitstarve in order to get sub-200mb releases. My somewhat subjective observation over the past few seasons is that here has been an overall reduction in filesize. We likely won't see anything like 700mb Star Driver encodes again (baring shows with extreme amounts of studio-added grain, such as Jormungand). Now that more and more encoders are using CruncyRoll's video, I think we'll see even smaller and better looking releases going forward.

As far as compatibility goes, It's hard for developers to see a need for hardware assisted 10-bit decoding, as there's really no use for it right now (in their eyes). CoreCodec is working on it, and I wouldn't be surprised if they have a working decoder by the end of the year.
_________________
el psy congroo

Its really not hard to find information on the advantages 10 bit encoding has over 8 bit encoding.  Sure, many pieces of hardware can't support showing that many colors, yet, but other advantages exist.  From what I gathered looking around, it seems like on average if you use the same encoding settings, you will get a file size that is smaller by 6-8 percent when encoding into 10-bit.  However, I seem to recall seeing a much larger disparity between the two formats file sizes in my personal experience.

Also, I believe I read somewhere that some broadcasting stations have switched to 10-bit encodes (I don't know the source though).

Screenshot comparison
Source

_________________
Becoming less of a lurker...

So, on a completely different subject...

Ever since I had a computer meltdown and had to reinstall things, stuff hasn't been entirely right with my playback setup.  This applies almost exclusively to videos ganked off of YouTube (using the Firefox extension DownloadHelper, with its conversion stuff disabled, and selecting either Copy URL or Download), and only those in an MP4 container (i.e. their HD encodes).

Randomly and unpredictably, the video will stop and the last half second or so of audio will loop for a few seconds, then everything picks back up, often with a low framerate for a bit before returning to normal.  If I skip back before it happened and play it again, it doesn't happen again.

This usually only happens once, maybe twice per video regardless of length, and again, only if it's being played back on my playback setup (CCCP + CoreAVC, using MPCHC as provided by CCCP).  If I'm watching through the Flash player, it doesn't happen.  I just watched an hour-long 720p video downloaded from YouTube and it happened twice, the first time a few minutes in, and the second time about 20 minutes before the end.

Also, sometimes, but not nearly as often, the audio will just drop out entirely.  Again, this applies only to ganked YouTube videos using the MP4 container, obtained through the same method.  Seeking the file causes the audio to come back, and if I skip back to before it went out, it won't go out again.

I haven't tried anything else I have in an MP4 container, so I don't know if it's just the container, or the combination of audio/video codecs involved, or what.  Seeing how YouTube uses H264 and AAC, the same as many fansub groups, it would seem unlikely that it's the codec combination.

The fact that it's unpredictable and doesn't happen again if the relevant part of the video is replayed tells me it's probably not an encoding issue, which means it's entirely on my end of things.

Are there any settings I can adjust to reduce/eliminate this?  I don't recall ever having this issue before I had to reinstall everything.  I think it might be more of an audio issue, seeing as how I'm having other audio problems unrelated to media playback, that weren't present before reinstalling things.

Using CCCP 2011-11-11, with WinXP SP3, nVidia GeForce 8800 GT, integrated Realtek AC'97 sound card, and 2GB RAM.  I think before I reinstalled everything I was using an earlier version of CCCP, though I don't remember.
_________________

Twitter | Blag | MAGFest 12 - January 2-5, 2014, at the Gaylord (National Harbor, MD)!

@eckstee

Are you converting the videos with this extension, or muxing them into the .mp4 container? Both Flash and that container are pretty shit in general, so it could be framerate-related. Install mediainfo and paste the output (right click on file, select media info, view as text).

Also, right click when watching in MPC and list what filters are displayed under that menu. A screen of how you have Core AVC setup might help too.



_________________
el psy congroo

Original post by Tormaid
@eckstee

Are you converting the videos with this extension, or muxing them into the .mp4 container?

YouTube's 720p and 1080p encodes are already in an MP4 container, and I only ever had the issue with those encodes.

Anyway.

I examined the filter chain and noticed the issue, and making one change fixed it.  The newer version of CCCP that I installed uses the LAV Splitter instead of Haali Media Splitter (but curiously installs both of them).  As soon as I forced it to use Haali Media Splitter, the issue went away.
_________________

Twitter | Blag | MAGFest 12 - January 2-5, 2014, at the Gaylord (National Harbor, MD)!