Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
4th September 2006, 23:21 | #1 | Link |
Registered User
Join Date: Oct 2003
Posts: 209
|
Speed and quality of ConvertToYUY2?
(I'm posting this here because I figure people who have looked at/written the source code would know best)
I have 3+ hours of footage to process; I'm using avisynth to splice together 30 different .AVIs into a single .avs to feed to CCE. My source is 0-255 RGB32. I've got two options:
CCE is closed source; avisynth is not. What would your professional recommendation be? Should I just let CCE do the conversion, or should I ConvertToYUY2 before feeding to CCE? Which would be faster? Which would result in better conversion quality? |
5th September 2006, 03:34 | #2 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
I'm biased, but ...
Avisynth's RGB to YUY2 routines are highly optimised fast MMX code that are mathematically exact, however there is some data loss intrinsic in going to 8 bit YUV from 8 bit RGB. Theoretically going from 8 bit RGB to 10 Bit YUV would avoid this loss, I don't know if CCE internal routines do a 10 bit conversion. Ask in the CCE forum. TMpgEnc for example works directly with 8 bit RGB data to produce 10 Bit mpeg2 streams and is slightly slower because of this. A data stream once it has been converted to 8 bit YUV should suffer no further losses in precision as long as the YUV->RGB and RGB->YUV routines are mathematically exact. i.e. all the loss of precision happens on the very first RGB to YUV conversion. So if your data has ever been 8 bit YUV in it's life then there is no issue. Using Avisynth routines will be as fast as possible and there will be no futher data loss. Note most AVI codecs actually store data internally as 8 bit YUV and convert to RGB32 for output. |
5th September 2006, 04:08 | #3 | Link |
Registered User
Join Date: Oct 2003
Posts: 209
|
Thanks very much for the explanation. And yet, I couldn't leave well enough alone, so I did a speed/quality test with both ConvertToYUY2() conversion and CCE conversion, and also with/without NTFS file compression (my RGB32 raw source compresses quite well with it). The results were surprising:
compression, avisynth conversion: 3m16s raw, avisynth conversion: 3m19s compression, CCE conversion: 3m27s raw, compression, CCE conversion: 3m24s Fastest: NTFS file compression+avisynth conversion Highest quality: CCE conversion When CCE did the colorspace conversion, it must have had the benefit of the 10-bit colorspace (I intentionally set DC bits to 10 for the test), as the following pictures show less banding in the CCE conversion: ...than in the ConvertToYUY2() conversion: The CCE conversion has 221 levels of luma (and no chroma), which is damn near perfect given the 0-255->16-235 range adjustment. The ConvertToYUY2() conversion, however, is 330 different colors, which I'm at a loss to explain except to say that it's due to rounding or truncation errors in the calculations. |
14th October 2006, 23:17 | #4 | Link |
Registered User
Join Date: Oct 2003
Posts: 209
|
Sorry to bring this thread back up, but I'm now in a situation where I need to do processing with avisynth and the conversion is most definitely losing precision in the original image. If I'm doing something wrong, please point it out to me, as the resulting loss is actually visible onscreen.
I have a UYUV source that is converted to RGB32 when I load it into our broadcast environment. In a waveform monitor, it looks like this: After the following simple pal->ntsc transcode script: Code:
AVISource("\assets\mc2\pal\arte.avi") ConvertToYUY2 TDeint(order=1,mode=1,type=0,sharp=false,AP=50,APtype=0) # Use TDeint to turn 25i into 50p Lanczos4Resize(720, 480) ConvertFPS(59.94,zone=80) SeparateFields() SelectEvery(4, 0, 3) # 4,1,2 is for odd field first; 4,0,3 is for even field first weave AddBorders(0,2,0,4) # we have to pad to 486 lines for use in our broadcast environment I've got to eliminate this loss somehow. Is the loss due to some math rounding error somewhere, or maybe the colorspace conversion matrix? Any help/suggestions are appreciated... |
14th October 2006, 23:45 | #7 | Link |
brainless
Join Date: Mar 2003
Location: Germany
Posts: 3,653
|
you may also try the different available matrices for colorspace conversions.
see the AVISynth documentation for a more detailed description.
__________________
Don't forget the 'c'! Don't PM me for technical support, please. Last edited by scharfis_brain; 14th October 2006 at 23:50. |
15th October 2006, 06:03 | #8 | Link | |
Registered User
Join Date: Oct 2003
Posts: 209
|
Quote:
In any case, I wrapped the stuff that needed YUY2 thusly: Code:
ConvertToYUY2(matrix="PC.601",interlaced=true) TDeint(order=1,mode=1,type=0,sharp=false,AP=50,APtype=0) Lanczos4Resize(720, 480) # Resize to NTSC resolution ConvertFPS(59.94,zone=80) # ChangeFPS(59.94) adds/drops fields; ConvertFPS(59.94) blends fields ConvertToRGB(matrix="PC.601",interlaced=true) |
|
15th October 2006, 10:52 | #9 | Link |
brainless
Join Date: Mar 2003
Location: Germany
Posts: 3,653
|
if you convert between yuy2 and rgb the interlaced paramter is useless, because there is no difference in vertical resolution.
the interlaced parameter is only needed if you are converting to or from YV12. btw.: we really need some higher quantised colorspaces
__________________
Don't forget the 'c'! Don't PM me for technical support, please. |
15th October 2006, 21:51 | #11 | Link |
brainless
Join Date: Mar 2003
Location: Germany
Posts: 3,653
|
don't ever feed encoders that cannot handle YV12 natively with YV12. This includes ProCoder, CCE and TMPGenc.
The only encoders I know of, that are handling YV12 the correct way are HcEnc and QuEnc.
__________________
Don't forget the 'c'! Don't PM me for technical support, please. |
18th October 2006, 02:45 | #12 | Link |
Registered User
Join Date: Oct 2003
Posts: 209
|
No, lower! Where's my YUV 4:4:4?
What I really need from avisynth are channel precisions higher than 8 bits per channel (ie. RGB24/32). I have some 10-bit HD footage I'd like to process with avisynth but am limited to doing it in the editor because avisynth cronks everything down to 8 bits per channel. Is such support in the planning stages? |
18th October 2006, 03:26 | #13 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Check out the Avisynth 2.6 pre-alpha released a month or so back. Support for YV16 (4:2:2 planar), YV24 (4:4:4), and YV12/16/24@16. The latter naming I just came up with, hope it fits. >.> No 10 or 12 bit; I'm not sure but it'd probably just retard speed, being all unaligned.
Last edited by foxyshadis; 18th October 2006 at 03:31. |
18th October 2006, 06:05 | #14 | Link | |
Registered User
Join Date: Oct 2003
Posts: 209
|
Quote:
Converting 10-bit to 8-bit it doesn't sound like a big deal, but footage that is just barely noisy becomes much noisier because you drop the 2 least significant bits... smooth gradients become posterized... all that stuff. For your own test, take a 24-bit image and convert it to 18-bit and you'll see the same types of effects. |
|
18th October 2006, 20:43 | #17 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
|
|
19th October 2006, 03:11 | #18 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
The precision will actually be 15 bits. SSE/MMX 16 bit word instructions favour the data being signed. And it will be a long way off, all the functions will need to have 15 bit versions written. In 3.0 the C code should be easy (template classes), the SSE/MMX will not.
|
Thread Tools | Search this Thread |
Display Modes | |
|
|