Log in

View Full Version : Color loss when encoding AVI lossless to h264


Nixeus
11th May 2013, 11:28
Hello, i'm trying to encode an AVI file compressed with CamStudio Lossless codec in MP4 with Megui/x264.
My avi file appear to be in RGB24, and when i want to compress it in MP4, Megui convert it to YV12.

The file result is darker than the original. I would like to avoid this, in oder to have the same color apparence.

Here is the file before:
http://img14.imageshack.us/img14/8438/beforeuv.png

Here is the file after :
http://img834.imageshack.us/img834/9933/aftermp.png

Anyone could help me please ?

Thanks a lot :)

Best regards,

Nixeus

ChiDragon
11th May 2013, 19:24
http://en.wikipedia.org/wiki/Chroma_subsampling

You would need to convert to Y'CbCr 4:4:4 to keep all of the color information of the original. This will limit playback of your output to software decoders on computers.

Nixeus
12th May 2013, 10:25
So, when i record new video, it will be better to use an other codec, like lagarith lossless in YV12 ?

Keiyakusha
12th May 2013, 13:38
it will be better to use an other codec, like lagarith lossless in YV12 ?
No, it won't be better. The only option is not to use YV12 or live with this color bleeding.

Nixeus
12th May 2013, 13:50
So, if you need to record your screen in order to share the video with html playing, what is the right way ?

If i encod my avi with h264 4:4:4, colors are right....but i don't succeed to play this with html5 and the video markup.

If i convert the color, i can play in html5 but...the color are not the same.

i'm a bit lost :\

LoRd_MuldeR
12th May 2013, 13:55
It's not possible, easily.

In order to avoid color subsampling, you need either RGB data or Y'CbCr data without subsampling (i.e. YUV 4:4:4 (http://en.wikipedia.org/wiki/Chroma_subsampling#Sampling_systems_and_ratios)), which both is not available in consumer video formats :(

Pretty much everything available to consumers is YUV 4:2:0. It's been like that since the early MPEG-2 days...

H.264 does support YUV 4:4:4, but only in the "High 4:4:4" profile, which has zero support in hardware decoders (except for "professional" devices) and very limited support in software decoders.

The H.264 decoder from ffmpeg/libavcodec does support the "High 4:4:4" profile just fine nowadays, but you simply are not in control which decoder the web-browser will use :rolleyes:

(I think for the web you would even have to stick with "Main" profile, if compatibility is a concern)

Nixeus
12th May 2013, 14:37
Thanks or the explanation, so, the best is to record my screen with a lossless codec in YV12 ?

LoRd_MuldeR
12th May 2013, 14:48
Well, record or deliver?

Recording in a lossless format is a good idea, so you don't have any loss there yet. You will have the loss in the final encoding step. Also, in this step you can capture RGB or YUV 4:4:4, as the output is used as intermediate data only.

Though, what you are going to deliver on the web-site probably needs to be re-encoded to some lossy format, preferably H.264 these days, which implies a conversion to YUV 4:2:0 for the reasons explained above.

Nixeus
12th May 2013, 15:08
Recorder !
In fact i don't understand why 4:4:4 is so....different and not supported by a lot of devices.

I want a simple thing : record my desktop in order to present a software.

If i encode with the MAIN profil the white color are a bit darkered and the blue is not the same ( if you look at the "client" label on the screenshot) .I would like to avoid this, and be able to share this with htlm video feature, thats'all :)

Nevertheless, on my video color are simply, so, why the blue is different ?

Keiyakusha
12th May 2013, 15:15
Nixeus
This is oversimplified response, but if you want this video to be shown on the WEB you CAN'T have colors as on 1st screenshot.

Edit: And WHY it is different was already answered multiple times. Read this thread starting from post by ChiDragon.

osgZach
14th May 2013, 13:41
If you want to record PC footage, you are going to have to suffer through the color loss. Unless you have some really fancy hardware, or filtering scripts / know-how to do a proper downsampling of the color and make corrections, etc.. Which is more trouble than its worth most of the time.

If you are recording something you intend to archive, then by all means record in Lagarith RGB 4:4:4 and keep it stored that way. Because if this is something you will distribute for years you can always go back and use the lossless source down the road, to create a new H264 or w/e codec we're using then, when devices finally support more color formats.

On a lesser note, if you are simply recording desktop activities to show off stuff and the clip is disposable. You may be better served encoding to Lagarith in YV12 - it will take a lot less of a hit on your CPU / Performance during recording.
/rant
I don't think anyone knows what Youtube really uses, other than that they have some stupid and convoluted system that almost always re-encodes uploaded videos (even if they would play fine) with some custom settings and locked to 30 FPS.

At most they probably support High Profile 4.1 for something like 1080p (or 3D?) content. But in general Main Profile, I guess, is intended to be the minimum industry standard for compatability and thus everyone encodes for the lowest common denominator to reach as many potential customers / consumers as possible.

It's really sad that we have no real mass-appeal video hosting like Youtube and similar sites, that supports modern features for videos such as support for different FPS video files, VFR video files, 4:4:4 color (seriously at least support 4:2:2!). Youtube supporters like to argue about reaching the most people and making sure everything works on every device, which I get to a certain extent.. But it should not be that hard to support a fall-back compatability encode, while allowing more advanced stuff for 480p/720p/1080p etc. if the device reports it can handle playback.

Even better yet, serve the standard compatability encode, and just like you have a "HD" button to watch in HD -- add an "ADV" button for "Advanced Video Features". The worst that can happen is the video stops playing because your device sucks.. Oh well, go back to the standard encode you were watching.

Granted there are a FEW sites out there which allow more advanced videos to be uploaded, without touching them and sometimes even stream them. But they are either woefully inadequate for a general Public service like Youtube provides, or they cost money and probably come with all kinds of restrictions on space/bandwidth or some such.
/rant

LoRd_MuldeR
14th May 2013, 15:29
What?

Why?

High Profile @ Level 4.0 or maybe even @ Level 4.1 should be fine, shouldn't it?

YouTube uses High Profile as well, doesn't it?

Well, FlashPlayer supports the "High Profile" of H.264. But FlashPlayer is not "the web". If you don't want to restrict your web-site to FlashPlayer (and thus to platforms with FlashPlayer support), you have to go the HTML5 route nowadays. Unfortunately, the video format for the HTML5 Video-Tag is not well-defined, as they didn't manage to agree on one format. Many browsers support H.264 here, but not all. And those who do, don't necessarily support all Profiles. They might be restricted to "Main" or even "Baseline" Profile...

http://www.html5center.info/de/index.php?title=HTML5_Browserunterst%C3%BCtzung&oldid=530#HTML5_F.C3.A4higkeit_unter_dem_Aspekt_der_Video_Unterst.C3.BCtzung

LoRd_MuldeR
14th May 2013, 15:39
In fact i don't understand why 4:4:4 is so....different and not supported by a lot of devices.

Because most devices use off-the-shelf hardware decoder chips. You cannot change those to support YUV 4:4:4, even if it would require only a small change. It's hardware. Changing the hardware to support YUV 4:4:4 would require new hardware. Also, as YUV 4:4:4 requires more memory bandwidth and stuff, it would probably make the hardware decoders more expensive. Maybe only slightly. But no company buys the slightly more expensive chips, if they don't have a good reason to do so. And there you have the typical "the chicken or the egg" problem: As long as millions of devices don't support YUV 4:4:4, nobody releases such footage. And as long as such footage isn't widely used/available, device manufactures don't care. Finally, people don't know what chroma-subsampling is. If you tell them, this screen has "4K" instead of "HD" resolution, they understand it has more pixels. And more is better, even if it's expensive. But what the heck is chroma-subsampling? People don't spend extra money to get rid of that thing they don't even understand...

ChiDragon
14th May 2013, 20:19
If your recordings are of windows rather than the full desktop, there is always the other option of recording the video with full color and then 4x upsizing it before the 4:2:0 conversion.

ImageSource("beforeuv.png")

PointResize(width*4,height*4).ConvertToYV12(chromaresample="point") #upsize to preserve original chroma at 4:2:0

ConvertToRGB().PointResize(width/4,height/4) #simulate playback at original resolution

I think that would work anyway; I don't have 2.60 installed right now. Maybe you would need control over the chroma upsample as well.

ChiDragon
15th May 2013, 00:44
4:2:0 chroma is 1/4 the size of 4:4:4 chroma, so if you 4*resolution (point) and resolution/4 (point) for those enlarge chroma samples, what do you end up with? The original chroma. In theory...

LoRd_MuldeR
16th May 2013, 12:58
4:2:0 chroma is 1/4 the size of 4:4:4 chroma, so if you 4*resolution (point) and resolution/4 (point) for those enlarge chroma samples, what do you end up with? The original chroma. In theory...

It's 1/4 the information, as each 2x2 block, i.e. 4 pixels, only gets a single chroma value, rather than giving each pixel its own chroma value.

But it should be sufficient if you upscale the video by a factor of 2x in both dimensions, which gives you a 4x redundancy. You don't need a 4x upscale, which would give you 16x redundancy.

http://upload.wikimedia.org/wikipedia/commons/thumb/f/f2/Common_chroma_subsampling_ratios.svg/320px-Common_chroma_subsampling_ratios.svg.png

Also: This trick can only work if you assume that the playback software/hardware will first convert to RGB and then downscale to the original resolution.

In case it performs the scaling in the YUV 4:2:0 domain and converts to RGB afterwards, it doesn't help at all, I think...

Nixeus
16th May 2013, 15:03
I found a simple way to display true color video on the web : Converting the video to AVI, and use AVI To SWF ( with camstudio), the SWF produced is small and whitout loss ! Color are the same.

Yes, it's flash, not HTML 5, but...i have all my colors !

Saddly that we cannot display true color on the web in HTML 5 :\

ChiDragon
16th May 2013, 18:20
^ Since SWF is designed for animations I guess that makes sense.

But it should be sufficient if you upscale the video by a factor of 2x in both dimensions, which gives you a 4x redundancy. You don't need a 4x upscale, which would give you 16x redundancy.

Indeed, but I found the darkening effect was still happening if I only did 2x.

Also: This trick can only work if you assume that the playback software/hardware will first convert to RGB and then downscale to the original resolution.


Or if it upsamples to an intermediary YUV format for scaling.