No, but I don't think that's a problem here (and it is a perfectly legitimate way to do it.)
I loaded both your test files up, examined them closely. I also made an avisynth script that loaded the lagarith one and converted it through YV12 with various chroma resampling methods, so I would know exactly what the 4:2:0 artifacts would look like in this situation. I saw no evidence of any chroma subsampling having been done at any point in the h264 clip.
Note the lack of any red bleed on the plumber's cap in the h264 encode:
http://img851.imageshack.us/img851/1239/showme.png
Natt, forget what I said, you are right. Something is wrong with my player. I opened my MKV with virtualdub and the quality was beautiful.
How do I get my player to stop outputting it at lower colorspace?
Black in the lagarith clip: RGB (2,2,2)
Black in the h264 clip after converting back to RGB24: RGB (18,18,18)
Edit: Didn't inspect the colormatrix, so no opinion either way on that.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
If you're running Windows, get the latest nightly build of Media Player Classic - Home Cinema, the latest LAV Filters, and the latest madVR. Install all of these and configure MPC-HC to use them via "External Filters" in its options (actually, "Playback" -> "Output" for madVR which is a renderer).
Natt: Oh.
I installed the latest KLite codec pack a few days ago (the 10-bit version of the super mario TAS refused to play without massive artifacts mess before) so I should have the latest versions of everything. On the external filters I added madVR, LAV splitter and LAV video decoder and set madVR on output playback settings but my output is still YV12.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Uninstall the K-Lite Codec Pack and just install those selected filters. Who knows what crazy stuff K-Lite installs?
All you need to play video is a player to handle DirectShow filters and keyboard/mouse input, a splitter to handle file input, a video decoder to decompress video codec formats, an audio decoder to decompress audio codec formats, and a renderer to display this data in realtime. What I listed in my previous post includes all the best of those things in Windows for the formats we're using (with the exception that LAV Splitter can't yet handle chapters in mkv files; need Haali Splitter for that). Nothing more is necessary, and anything more could cause unexpected problems.
By the way, you can check which filters are currently in use in MPC-HC by clicking "Play" -> "Filters". Everything listed in the resulting list is currently in use.
Basically, all I need is lots of things that take forever fetching and installing one at a time when KLCP has it all in one. No thanks. :P
Natt, how do I check if the decoder is being used?
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Santiago wrote:
Natt, how do I check if the decoder is being used?
Lex wrote:
By the way, you can check which filters are currently in use in MPC-HC by clicking "Play" -> "Filters". Everything listed in the resulting list is currently in use.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Try using LAV Video Decoder instead of ffdshow Video Decoder. Alternatively, you could try the latest version of ffdshow-tryouts. The version of ffdshow that comes with K-Lite Codec Pack might be pretty old.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Santiago wrote:
Lex wrote:
Try using LAV Video Decoder instead of ffdshow Video Decoder
How?
Lex wrote:
Install all of these and configure MPC-HC to use them via "External Filters" in its options (actually, "Playback" -> "Output" for madVR which is a renderer).
Click "Add Filter..." to add the filters you want on the external filters list. These should include LAV Video Decoder and ffdshow Video Decoder. Additionally, set LAV Video Decoder to "Prefer" and ffdshow Video Decoder to "Block".
This assumes you have already installed LAV Filters. If you haven't, you can get the installer from here. Using the installer is now recommended by the LAV Filters author, as of version 0.46.
natt could you please replace your image with just a link? Some people have more narrow monitors (like me).
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Oh cool I got it working now. See I didnt have ffdshow on my external filters list but it appeared anyway. To fix this, I got rid of madVR from external filters as well as switched back to VC9 renderless in the playback options. Now I finally have RGB in all its glory! I will try the ffdshow tryout though since MPC is not my main player and I would like to play it on other players.
Thanks everyone, and keep encoding in 10-bit, scrap the old low-quality YV12 crap!
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
If you're in Windows and you want playback quality, use the setup I suggested. Also, don't use VMR-9 (assuming that's what you meant by "VC9 renderless") because it fails at vsync and drops frames from high-framerate video, such as that found in TAS video encodes. Try EVR Sync, EVR Custom Pres., or madVR, using the latest nightly build of MPC-HC and the latest version of madVR.
No, video compression usually uses YCbCr instead of RGB.
AFAIK lossy video compression usually uses a color space in the form of a grayscale channel and separate color information because it's more lossy-friendly than the RGB color space (in other words, grayscale+color can be compressed more without the human brain noticing much difference than RGB).
However, when dealing with lossless compression, does it make a difference?
AFAIK lossy video compression usually uses a color space in the form of a grayscale channel and separate color information because it's more lossy-friendly than the RGB color space
Y is the greyscale channel and Cb and Cr are the color info.
Some other reasons:
* The sum of entropies of Y, Cb and Cr channels is usually fair amount smaller than sum of entropies of R, G and B channels (improved compression)
* YCbCr is much easier to chroma subsample than RGB.
Warp wrote:
However, when dealing with lossless compression, does it make a difference?
AFAIK, Lossless compression algorithms usually store one of:
* R, G, B
* R - G, G, B - G.
* Y, Cg, Co
The point of the last two is to try to reduce the entropy.
YCbCr is not used for lossless compression because it is not lossless to convert to and from RGB.
(Aside: wtf is up with chroma point resample? Chroma location disagreement?)
There isn't an option to set chromainplacement where it would need to be to make point chroma resample behave like you'd want. (it defaults to mpeg2 placement)
This was gone over last month on doom9, and I came up with a workaround a couple posts down.
http://forum.doom9.org/showthread.php?p=1551403#post1551403
(Aside: wtf is up with chroma point resample? Chroma location disagreement?)
There isn't an option to set chromainplacement where it would need to be to make point chroma resample behave like you'd want. (it defaults to mpeg2 placement)
This was gone over last month on doom9, and I came up with a workaround a couple posts down.
http://forum.doom9.org/showthread.php?p=1551403#post1551403
Hmmm... so if I'm understanding this correctly, the chroma location you get from pointresize yv24->yv12 is fixed to chromaloc=2 (using notation from the h264 spec)? But that's not one of the placement options in avisynth.
No matter, you'd never use point resize of chroma anyway. If I'm understanding things correctly, the simplest resizer one would actually use (average chroma values across 4 pixels) results in an effective chroma location equal to jpeg/mpeg1?
