I need to ask a question regarding HufYUV...
See this is my situation:
For encoding VOB files to AVI, I always use AutoGK because it's simple and best tool for the task. But sometimes there are situations where I have to use MeGUI for the purpose. Now, MeGUI requires a lot of settings, so what I do, is that I convert VOB file to HuffYUV file and then using AutoGK, convert that HuffYUV to AVI file.
Now, my question is,
Is the process of converting VOB to AVI using AutoGK is same as,
Converting VOB to HuffYUV (using MeGUI) and then converting HuffYUV to AVI using AutoGK?
(I read on wikipedia that HuffYUV is a lossless codec, so maybe it's like WAV file in Audio files)
I am using MeGUI to get HuffYUV file because some areas are not being cropped properly by AutoGK even if I use it's advance settings...
thanks in advance
+ Reply to Thread
Results 1 to 8 of 8
There's a problem in that. I don't know why, but MeGUI doesn't converts it. It gives error. Why it happens? It is beyond my knowledge. I have tried searching everywhere but couldn't find any solution for that.
(further, I am not so comfortable with the advance settings that we are suppose to input in MeGUI)
Decompressing VOB will get you YV12 video. That will have to be upsampled to YUY2 to be compressed by HuffYUV. Then for conversion to Xvid that YUY2 will have to be downsampled back to YV12. Those conversions may causes losses, although probably not visible in most cases. Depending on what software is used, you may even get conversion to RGB somewhere in the process. That would cause even more loss of accuracy.
thanks for the details.. So basically this process involves losses if I use VOB to HuffYUV to AVI method using MeGUI n AutoGK (although not visible always )
Right now I have converted it VOB to HuffYUV and then to AVI using the above method and the final AVI, well, looks crystal clear to me... So maybe, the losses are not visible this time???
And you want to upsample that to ten numbers. You could simply duplicate each number:
Then you want to downsample back to five numbers so you simply discard every other number:
The result is exactly the same as what you started with. So this would be a lossless operation.
If you were to view those upscaled numbers as an image you would find that it looked a little blocky because of the duplicates. So you devise an algorithm that gives smoother results. You fill the in between numbers by averaging the two numbers around it. So between the first two numbers you insert (1+3)/2, or 2. Between the next pair you insert (3+5)/2, or 4. Etc. Your smooth list of 10 numbers becomes:
Then you devise a smooth way to downsample again by averaging pair of numbers:
(1+2)/2, (3+4)/2... (9+10)/2
The result of (1+2)/2 is 1.5. But you have to save the result as an integer. You follow the rule that <.5 rounds down and >=.5 rounds up. So 1.5 rounds up to 2. The result for all the operations is:
So, although your intermediate upscaled image looked better than the image made by simple duplication, and images downscaled with your new algorithm would look smoother than images downscaled with your earlier simple decimation, none of your new list of five numbers match the original list.
jagabo, your example and way of explanation is simply great...!
So what I get it, is that I should use only one software for the encoding purpose and try to avoid this intermediate HuffYUV conversion.
But MeGUI has some problem in my computer, it doesn't converts VOB to XviD at all (tried every solution I could search for), that's why I had to go through this process of VOB to HuffYUV to AVI.
thanks once again for these details...