Sceen Recording Issue

[roflwaffle]

I've been using Camtasia Studio to carry out my screen recording tasks using its very own lossless codec, but I've noticed that, when encoding the video to a more portable format, namely H.264, the quality degrades by a significant amount. At first, I thought it was due to encoding to a lossy format. However, when I tried encoding to Huffyuv, with the output colourspace set to YV12, I got more-or-less the same result as I did with the lossy format. It seems that the loss in quality is due to the colourspace conversion going on.

This is the AviSynth script I used (using Rec.709 coefficients gives the best results):

FFmpegSource2("capture-1.avi")
ConvertToYV12(matrix="Rec709")

My question is: what can I do to improve the quality of my videos? Are there any better screen recording programs?

[DB83]

WM Capture will record the screen in either WMV or Mpeg2

[poisondeathray]

However, when I tried encoding to Huffyuv, with the output colourspace set to YV12, I got more-or-less the same result. It seems that the loss in quality is due to the colourspace conversion going on.

My question is: what can I do to improve the quality of my videos?

Do you mean the "same result" as in "poor quality" when recording huffyuv in yv12 ?

If this is the case (not a compression loss), your ONLY option is to use RGB format. You're not going to find any "portable" distribution formats for RGB. They are all huge in filesize.

Are there any better screen recording programs?

From what you've said, it's not a screen recording issue. Unless you're not describing the issue correctly

[roflwaffle]

However, when I tried encoding to Huffyuv, with the output colourspace set to YV12, I got more-or-less the same result. It seems that the loss in quality is due to the colourspace conversion going on.

My question is: what can I do to improve the quality of my videos?

Do you mean the "same result" as in "poor quality" when recording huffyuv in yv12 ?

If this is the case (not a compression loss), your ONLY option is to use RGB format. You're not going to find any "portable" distribution formats for RGB. They are all huge in filesize.

Are there any better screen recording programs?

From what you've said, it's not a screen recording issue. Unless you're not describing the issue correctly

Yes. Sorry, I've edited my post to make it clearer.

I was afraid of that .

I just thought there may be other screen recorders that output to a different colourspace, which would make the conversion more accurate. Then again, maybe it can't be helped. I'm not sure. That's why I'm asking the experts . Could there be other methods of converting to YV12 that I could try?

[poisondeathray]

No there isn't. If you're describing what you see correctly, then the only option is to stay in RGB for recording and encoding after.

Post some screenshots or samples to illustrate what you mean by "quality degradation"

There should only be slight blurring of color edges - there shouldn't be a dramatic difference... .unless there is something else going on

There are other methods of resampling chroma for the colorspace conversion, but they all have drawbacks. There isn't a good way to keep all that color information by subsampling to 4:2:0 . In avisynth 2.6, you have options to specify the chroma placement and sampling method used, but they are only marginally better or worse

[roflwaffle]

Original:
https://forum.videohelp.com/images/imgfiles/yYlq7.png

Rec709:
https://forum.videohelp.com/images/imgfiles/TPwBC.png

PC.709:
https://forum.videohelp.com/images/imgfiles/XIR53.png

Rec.601:
https://forum.videohelp.com/images/imgfiles/LAfMM.png

PC.601:
https://forum.videohelp.com/images/imgfiles/JFCOF.png

I've seen worse than this, but I can't reproduce the example. It was from a presentation. The colours would basically "glare" out with some bright text.

[poisondeathray]

In that example, the chroma is slightly shifted there (color edges aren't as crisp). You can use chromashiftsp using a subpixel shift (like 0.5) to make it "in line" . There is actually a patch to improve the shift in newer versions of 2.6 (not released yet), but if you're interested I can give you the more information

I've seen worse than this, but I can't reproduce the example. It was from a presentation. The colours would basically "glare" out with some bright text.

I suspect there is something else going on then. See if you can dig up that example.

[roflwaffle]

I tried to reproduce it.

Original:


Rec709:


PC.601:


This is what I meant by it glaring out.

Edit: Now that I look closer at the "VideoHelp.com Forum" header from the previous examples, it is happening to that as well.

There is actually a patch to improve the shift in newer versions of 2.6 (not released yet), but if you're interested I can give you the more information

Yes I'm interested.

[poisondeathray]

Yes that's from subsampled chroma . There is much less color information in YV12 4:2:0 (every 4 pixel of luma has only 1 of Cb and Cr) . There is no perfect way to keep all that information, unless you stay in RGB . It's especially evident in that example, because everything is an "edge", so you get blurring everywhere

[poisondeathray]

There is actually a patch to improve the shift in newer versions of 2.6 (not released yet), but if you're interested I can give you the more information

Yes I'm interested.

Read through this thread, especially posts by gavino . Look for the yuy2toyv12 function , and there is a different one if you use 2.58 vs. 2.6 . The directional shifts are different if you are using 2.58 vs. 2.6

http://forum.doom9.org/showthread.php?t=147629


You can also experiment with chromaresample and chromaplacement if you are using 2.6 . Sharper resizers cause more aliasing and ringing, but something like pointresize will cause blocky edges. There are dozens of resize algorithms you can choose from
http://avisynth.org/mediawiki/ConvertToYV12

e.g.
ConvertToYV12(chromaresample="spline36")


And chromashiftsp() can shift the chroma in subpixel amounts in a given direction so there is less "hanging" on the edges


The method in which you view it also makes a difference. If that player or screenshot method uses high or low quality upsampling methods, or if they use a 709 or 601 matrix (the YV12 encoded material has to be converted back to RGB for display)

The choice of renderer for display also makes a difference. For example, madvr
https://www.videohelp.com/toolsimages/madvr_1196.jpg



None of this will help much. And they all have pros & cons - the ONLY way to preserve the quality is to stay in RGB. There is just too much color information missing for YV12

[roflwaffle]

Thank you, poisondeathray.

[Gavino]

Read through this thread, especially posts by gavino . Look for the yuy2toyv12 function , and there is a different one if you use 2.58 vs. 2.6 . The directional shifts are different if you are using 2.58 vs. 2.6
http://forum.doom9.org/showthread.php?t=147629

Unfortunately, although it might help in understanding the problem (esp post #30), the thread provides no fix for the RGB to YV12 chroma shift, because that happens inside the conversion from RGB to YUY2 (in v2.58). My fixes only deal with the problems in YUY2<->YV12 conversions. At best it will fix the potential aliasing on the YUY2 to YV12 subsampling part of the conversion.

For 2.60, a similar fix could be devised for YV24->YV12 which could be used in RGB->YV12 conversion, but hopefully a new 2.60 release is imminent which will fix this internally.