Problem is between app and codec, something goes wrong as there is even shift in the video."
In your case issues is before data hits codec. "None of the lossless codecs will alter incoming video- it encodes what it gets and this will stay lossless. So, we all must ask ourselves at this point: Could it be that VirtualDub causes this Problem, that no one ever noticed before besides me, or the Codecs MagicYUV and UtVideo ? If it would be just me with this Problem, yes, could be something wrong with my Setup and VirtualDub and the Codecs are Innocent, but others too ? Same Problem with different OSes, Machines, Setup's and other Capture Devices ? Coincidence ? Occam's razor is named after the deviser of the rule, English philosopher and theologian William of Ockham (1285?-1349?)." This rule is interpreted to mean that the simplest of two or more competing theories is preferable and that an explanation for unknown phenomena should first be attempted in terms of what is already known. "A rule in science and philosophy stating that entities should not be multiplied needlessly. "The principle in philosophy and science that assumptions introduced to explain a thing must not be multiplied beyond necessity, and hence the simplest of several hypotheses is always the best in accounting for unexplained facts." So, is it possible that there is a Error about the Fields in VirtualDub when using the Capture Mode ? And if so: For how long, if i get the same Result with Version 1.6.19 ? On the other hand, if there "is" a Error in the Field Order in VirtualDub, how come no one ever saw or noticed it before ? Millions of Users use VirtualDub since it came out and I'm the first one to discover this ? You must agree, that would be very strange, don't you think so ? Load it in VirtualDub and select the Preview Option to "Weave TFF" and let it play in VirtualDub, afterwards to "Weave BFF" and you see the difference. You can verify that easily with a proper DV Encoded Video which is always BFF for PAL and NTSC, for a long Time a reliable Standard. This is also the case for the new Interlace Filter, Odd/Even Field is the other Way around.
Honestech vidbox what software can i use manual#
VDub Manual "Field Order B" = Odd Field, Truth: Even Field (BFF) VDub Manual "Field Order A" = Even Field, Truth: Odd Field (TFF) In the Manual it says for Example that "Field Order A" (Now TFF) handles the EVEN Field (Lower Field) under "Preview-Options", which is wrong, it handles the ODD Field (Upper Field) and "Field Order B" (now BFF) the ODD Field (Upper Field) but really is the EVEN Field (Bottom Field) for Interlaced Preview Mode. I did notice in VirtualDub 1.9/1.10 that some Filters handle the Field Order wrong.
If it would be a Problem along with a exotic Software with funny Interfaces, yes, but VirtualDub ? So i ask you, where could be the Problem between VirtualDub, the different Capture Devices and the Codecs ? I practically grew up with VirtualDub but this is the first Time that i see a Codec behave like this. As i wrote earlier, i really don't know where the Problem could be and maybe Ben Roudiak Gould has a Routine in HuffYuv that takes care of this Situation when BFF is used on the Input. Win2K, XP, Win7, all with MagicYUV RC4 and UtVideo 13.3.1 along with VirtualDub gives the same results with NTSC and BFF Input, not just for me, for others too like my Friend in Florida who had the same Problem with MagicYUV. I agree, normally this should not happen but it does somehow and the only Software involved is VirtualDub, the Capture Devices and the Codecs, that's all i used for the Samples, no funny Codec Packs installed that could mess up something. I even tried VirtualDub-MPEG2 1.6.19 (ffcHandler) instead of VirtualDub 1.10.4, same Result. Used the Settings for HuffYuv as seen in the Screen Shot i posted, means, no "Swap Fields" Option enabled.
0 kommentar(er)
