Drastic Technologies Codecs

[smartel]

http://www.homedvd.ca/products/utilities/yuv-codec-download/

has anybody heard , tried or test any of theses codecs ??

i just tried a few in virtualdub , i get no drop frame a few inserted ones
but they give me BIG files 1G=1 min approx , they have a lot of options

Are they worth anything ??

General
Complete name : G:\CAPTURE\VD.00.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 1.01 GiB
Duration : 52s 753ms
Overall bit rate : 165 Mbps

Video
ID : 0
Format : YUV
Codec ID : YUY2
Codec ID/Info : YUV 4:2:2 as for UYVY but with different component ordering within the u_int32 macropixel
Duration : 52s 753ms
Bit rate : 162 Mbps
Width : 704 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:2
Compression mode : Lossless
Bits/(Pixel*Frame) : 16.000
Stream size : 1 019 MiB (98%)

[poisondeathray]

Yes I've used them , they are all uncompressed variations so filesize will always be large

[Cauptain]

DRASTIC CODEC (1:27mns)

General
Complete name : D:\CAPTURAS\VIRTUALDUB\CAPTURE-0.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 1.70 GiB
Duration : 1mn 27s
Overall bit rate : 167 Mbps

Video
ID : 0
Format : YUV
Codec ID : YUY2
Codec ID/Info : YUV 4:2:2 as for UYVY but with different component ordering within the u_int32 macropixel
Duration : 1mn 27s
Bit rate : 166 Mbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:2
Compression mode : Lossless
Bits/(Pixel*Frame) : 16.000
Stream size : 1.69 GiB (99%)

Audio
ID : 1
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : 1
Duration : 1mn 27s
Bit rate mode : Constant
Bit rate : 1 536 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz

UT VIDEO (1:52mns)

General
Complete name : D:\CAPTURAS\VIRTUALDUB\CAPTURE-1.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 893 MiB
Duration : 1mn 56s
Overall bit rate : 64.5 Mbps

Video
ID : 0
Format : YUV
Codec ID : ULY2
Codec ID/Info : Ut Video Lossless Codec
Codec ID/Hint : Ut Video
Duration : 1mn 56s
Bit rate : 63.0 Mbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:2
Compression mode : Lossless
Bits/(Pixel*Frame) : 6.079
Stream size : 872 MiB (98%)

Audio
ID : 1
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : 1
Duration : 1mn 56s
Bit rate mode : Constant
Bit rate : 1 536 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 21.2 MiB (2%)
Interleave, duration : 501 ms (15.00 video frames)

UT VIDEO is very very better in all ways...



Claudio

[MickMan]

Hi "smartel"
the Drastic Codecs are Uncompressed 8/10 Codecs, means, if you Capture with VirtualDub to YUY2 for Example, the Drastic Codecs will deliver the same Filesize. The Key Advantage is, that your Capture is at best Quality and besides VirtualDub, other NLE's can't recompress to YUY2 because the Native Windows Codec for YUY2 is Decompression only. With the Drastic Codecs you can recompress and, if selected, Intelli/Smart Rendering. Besides, the native Windows Codec "msyuv.dll" decodes to RGB24, NOT to YUY2 while the Drastic Codecs stay in the selected Color Space. I use them all the Time for Captures and Compress to MP4,MPEG or XviD when the Film is done, not before, to keeep the Original Quality.

Note to "cauptain"
The UT-Video Codec has trouble with Interlaced Material and does not work well with certain NLE's. Lagarith or the good old HuffYUV is far better as both are based on the Original HuffYUV Code. I tested the UT-Video Codecs very hard and removed them from my Systems because they caused too much trouble with Interlaced Material. HuffYUV works best in this Aspect and consumes a lot less CPU Cycles than UT-Video. The Idea of the UT-Video Codecs is not bad, but they certainly need a lot more Work to really compete with HuffYUV or Lagarith. Maybe, if you're into "Lossless" Compressen, you might want to try "MagicYUV", a Lossless 4K Codec.

Explanation of the Interlaced Problem with UT-Video:
Some NLE's can't interpret the header of the UT-Video AVI Files and what Sequence the Fields have (Top/Bottom). That's why some NLE's reject UT-Video encoded AVI's. Tested on many Systems, not only on my ones. Another Problem with UT-Video is, that the Codec does not report the correct Color Space (YV12/YUY2 etc.) that was used for compression and uses mostly RGB instead of YUV. HuffYUV reports, if YUY2 is used, correctly YUY2, not RGB.

Best Regards, MickMan.

[poisondeathray]

@MickMan, which NLE's are you having problems with ?

Many people use UT video without issues that you mention. If it's just a field order issue you can usually interpret the fields in the editor (lagarith and huffyuv are prone to this problem as well)

Some NLE's don't treat lossless codecs as "truly lossless" because they are not treated in the same colorspace. It's software dependent. For example, Lagarith and huffyuv have this problem as well in sony vegas. Some NLE's have a native YUV timeline e.g. newer versions of Adobe handle colorspace correctly. UT has separate fourcc's for YV12/YUY2/RGB so colorspace handling usually isn't an issue

Even "uncompressed YUV" are not always handled correctly. For most Windows NLE's the correct fourcc and plane arrangement should be UYVY not YUY2. YUY2 gets converted to RGB in some editors, but UYVY can get passed through as YUV

The main benefit of UT video is decoding speed. You can edit HD video fairly smoothly on a decent system. You can't (as easily) with lagarith or huffyuv. If you're only dealing with SD footage, it might not be an issue

[deadrats]

the Drastic Codecs are Uncompressed 8/10 Codecs

this is a contradiction in terms, a codec by definition means compressor/decompressor, if the stream is "uncompressed" then that means no codec has been used.

did you mean "lossless" instead?

[Cornucopia]

Historically, the term referred to something compressed, but it is now used generically for any encoded video stream, whether uncompressed or losslessly or lossily compressed.

And if you wanted to go another route on it, by some definitions, the term "codec" is from "encoder/decoder", by which the inclusion of uncompressed would hold true.

Scott

[MickMan]

Hi "poisondeathray",
most NLE's, that are based on the ffmpeg/ffdshow Engines are affected. The UT-Video Codec does not report the Field Order like HuffYUV for example. I've been working and programming in this Field for a long time, so i'm not a "newbie". Analyses showed, that UT-Video does not adopt to a certain Field Order. Plain Example: With HuffYUV ( 2.1.1 CCESP 0.2.5) you can Capture a NTSC 640x480 with Bottom Field First and HuffYUV will encode it this way. Fine so far. Now you leave the Resolution at 640x480 but this Time with PAL or SECAM which is Top Field First. Again, HuffYUV keeps track of the Change of Fields and decodes correctly and reports the proper Field Dominance to ANY NLE, weather it's NTSC, PAL or SECAM. At this point UT-Video fails and does not report the correct Field Order to the NLE, resulting that in some NLE's you suddenly have instead of 25 Fps 50 with out of Sync Audio. For Progressive the UT-Video is fine, no problems with the exception, that any Intelli/Smart Rendering and Proxy MUST be disabled, otherwise you can end up with a unplayable short AVI Clip. The only Solution to this Problem is to load the Profile first and on Importing a UT-Video manually, so you must set the correct Field Order, everything that HuffYUV delivers by default.

Furthermore the UT-Video Codec consumes on a 4 CPU System more CPU Load than other Lossless Codecs like HuffYUV, Lagarith or MagicYUV. The Key Advantage for HuffYUV is, that, NLE's that are based on the ffmpeg/ffdshow Engines support natively HuffYUV. Plus, unlike the native "msyuv.dll" Codec from Windows, that Reports RGB24 to any other Codec, HuffYUV reports "YUY2" NOT RGB24. Any convert in Color Space costs Quality and the "msyuv.dll" is not the best in this discipline. Believe me, i tested them all and tried a lot with UT-Video, but this Codec still needs some serious work. And NLE's that cause trouble ? VideoPad, Premiere (different Versions), Magix, Pinnacle, some Corel, just to name a few of the many. The Compression Ratio is about the same between HuffYUV and UT-Video and HuffYUV can go up to 16384x16384 (Workstation) or 8192x8192 (PC) with fluent playback while UT-Video cracks at 4096x4096 with a very jerky "Out of Sync" playback, on Workstation or PC. Please Note, this is my personal Experience and the Results of my tests i made. I certainly DON'T mean to make the UT-Video Codec look "bad", just facts, nothing else.

Hi "deadrats",
"Uncompressed" is used, when a YCbCr Colorspace is used and natively supported by the Graphics Card and that's where the Drastic Codec links to, the Hardware. The Native Windows Codec are DECOMPRESSION ONLY, NOT COMPRESSION ! If you capture a Video from your VCR or Camera with VirtualDub and you select for example "YUY2", then the Device/Card uses the internal HARDWARE and NOT any Codecs from Windows because they only DECODE. With the Drastic Codecs the Situation changes and the Capture Device will use the Drastic Codecs instead. So, what's the Advantage ? First, the Drastic Codecs support all Resolutions up to 32678x32678 on a Workstation and 8192x8192 on a PC while the native Windows Codecs end with VGA/DVD Resolutions. Second, the new native Windows Codecs are not CPU Optimized, not even MMX anymore. Color Transformations from UYVY to YUY2 and YVYU are NOT Lossless, you can try that with VirtualDub and see for yourself. VirtualDub uses internally the original code from HuffYUV to prevent Color-shifts and Loss. Same with the Intel Indeo IYUV Codec, that supports, since Vista, not just IYUV but I420 as well because Microsoft used up to XP for I420 the "msh263.drv" Codec from Netmeeting, limited to 352x288 at max. 30 Fps. This Intel Codec also transforms 12 Bit to 24 Bit and is limited in the Resolution and can be used for Compression/Decompression.

The Drastic Codec transforms ANY YCbCr Format that it supports without any loss, your Colors will remain the same, no matter which YCbCr Format you use. Also, the Drastic Codec keeps the Rules of SMPTE/ISO/ITU and EBU for Broadcasting and Mastering while the native Windows Codecs are all (!) 0-255 because they are layed out for PC, NOT for Film-production. I have never seen a Producer in a Mastering Lab using a "compressed" Codec, UNLESS the Material came that Way, DNxHd, ProRes, HQX for Example. Most Material is delivered in v210, 2vuy, UYVY, YUY2, I420 and YV12 to the Mastering Labs, only at the end of Production the material gets compressed for DVD/BluRay/Television and so on, i seen it and i do it the same way since years. And Speaking of YCbCr, this is a uncompressed Format because the File Size will be the same with the Drastic Codec as if you would use the "Uncompressed YUY2" Option in VirtualDub, except, with the Drastic Codecs you can re-compress in the same Color-space you captured and have the right Levels according to SMPTE/ISO/ITU/EBU Specs, not VGA Full Range (0-255) and, not to forget, the Speed because the Drastic Codecs are fast and layed out for Intel AMD or Compatible CPU's with Optimizations including Alpha Channel.

Did i mean "Lossless" ? Yes because YCbCr (YUV) is ALWAYS Lossless, sort of "as is" when you use your Capture Device without a third Party Codec, same for RGB/4:4:4 and 4:2:2/4:2:0 Color Spaces. Further, the Drastic Codecs work with any ATI, NVidia, Intel Graphics, Matrox, Aurora, Aja/Kona, DVS and OptiBase VideoPump Card/Chip-Set.

Hi "Cornucopia"
Quote:
"...the term "codec" is from "encoder/decoder", by which the inclusion of uncompressed would hold true."

Right Say's everything

Take care Guys and thanks for the comments

Regards, MickMan.

[poisondeathray]

Hi "poisondeathray",
most NLE's, that are based on the ffmpeg/ffdshow Engines are affected.

And that's your problem. The libav version of ut video decoder is about 2-5x slower than the VFW dll. The optimizations have not made it into the main branch yet - that' s why it's so slow .

The fact is very few professional NLE's use ffmpeg in the back end. Lightworks is the only semi professional one. Blender isn't really a NLE, nor is NukeX . The other "NLEs" that use ffmpeg are really toys

so you must set the correct Field Order, everything that HuffYUV delivers by default.

I can show you conditions and examples where huffyuv fails signalling correct field order and aspect ratio by default as well . I suspect you only tested a narrow set of conditions

Furthermore the UT-Video Codec consumes on a 4 CPU System more CPU Load than other Lossless Codecs like HuffYUV, Lagarith or MagicYUV. The Key Advantage for HuffYUV is, that, NLE's that are based on the ffmpeg/ffdshow Engines support natively HuffYUV. Plus, unlike the native "msyuv.dll" Codec from Windows, that Reports RGB24 to any other Codec, HuffYUV reports "YUY2" NOT RGB24. Any convert in Color Space costs Quality and the "msyuv.dll" is not the best in this discipline. Believe me, i tested them all and tried a lot with UT-Video, but this Codec still needs some serious work. And NLE's that cause trouble ? VideoPad, Premiere (different Versions), Magix, Pinnacle, some Corel, just to name a few of the many. The Compression Ratio is about the same between HuffYUV and UT-Video and HuffYUV can go up to 16384x16384 (Workstation) or 8192x8192 (PC) with fluent playback while UT-Video cracks at 4096x4096 with a very jerky "Out of Sync" playback, on Workstation or PC. Please Note, this is my personal Experience and the Results of my tests i made. I certainly DON'T mean to make the UT-Video Codec look "bad", just facts, nothing else.

Because you're using the ffmpeg/libav based ut video decoder. It's work in progress

I strongly disagree with your Premiere observations . Premiere does not have problems with UT - in fact it is the most common recommended lossless codec to be used in the Adobe forum .

If you have to use ffmpeg based software, then yes huffyuv would be the lossless codec to use for performance, ffv1 for compression

The reason people rant and rave about ut video is because it really (was) the fastest at decoding, with VFW (windows based) NLE's . Magic YUV has taken that crown now, but hasn't been as thorougly tested yet

[MickMan]

Hi "poisondeathray"
first, thanks for your reply. What "libav" is concerned, i don't use it nor ffmpeg or ffdshow. Premiere, well, the oldest one i tested was 1.5 and the newest one CS4 because after that, i stopped using Premiere. MagicYUV still has some problems too but to be clear at this point, both, UT-Video and MagicYUV are real good alternatives, once the rest of the Bugs are out of them. I used UT-Video WITH the VFW-DLL, not the "libav" Version. Do you know the german Forum "SlashCam" ? There is also a big Discussion about the UT-Video Codecs where Users reported many Problems with UT-Video, even with Premiere CC.

Quote:
"It's work in progress"

Are you developing the UT-Video Codec or are you somehow involved ? I tried to contact the Author of UT-Video, but so far i had no luck at this point. UT-Video has great potential but still has some annoying Issues like the Field Order and Playback Speed.

What HuffYUV concerns, the Field Order was always correct and i relate to the Version 2.1.1 CCESP Patch 0.2.5 from 2004, NOT the original 2.1.1 Version from 2002. This Version never failed me so far and aka had never Problems importing Material in any NLE i used. I tested a very wide spread of Conditions with all the Lossless Codecs in different Situations, not just a "narrow" one.

And MagicYUV has taken the Crown ? Not yet NLE's based on ffmpeg/ffdshow reject MagicYUV completely and some reject Lagarith as well. And, what you consider as "Toys" are NLE's that are widely used, that's why i tested them as well. Plus, at the end of the Day it only counts one thing, the Result, nothing else. I've seen Movies made completely with VirtualDub and AviSynth, so i really disagree with you in this Matter.

Regards, MickMan.

[poisondeathray]

Hi "poisondeathray"
first, thanks for your reply. What "libav" is concerned, i don't use it nor ffmpeg or ffdshow. Premiere, well, the oldest one i tested was 1.5 and the newest one CS4 because after that, i stopped using Premiere. MagicYUV still has some problems too but to be clear at this point, both, UT-Video and MagicYUV are real good alternatives, once the rest of the Bugs are out of them. I used UT-Video WITH the VFW-DLL, not the "libav" Version. Do you know the german Forum "SlashCam" ? There is also a big Discussion about the UT-Video Codecs where Users reported many Problems with UT-Video, even with Premiere CC.

Quote:
"It's work in progress"

Are you developing the UT-Video Codec or are you somehow involved ? I tried to contact the Author of UT-Video, but so far i had no luck at this point. UT-Video has great potential but still has some annoying Issues like the Field Order and Playback Speed.

Thanks for sharing your experiences and observations

I'm not related in any way to UT video - The developer is Japanese, and doesn't speak English to my knowledge. (And about my extensive repetoire of Japanese is limited to "sushi" or "ninja" ) . Now there are some dual language speakers at Doom9 that convey the bug reports / suggestions to the developer, but the forum is down right now

Premiere made huge changes from CS5 onward, it's basically a different beast with native YUV timeline, YUV filters. As you know , many windows based NLE's work natively in RGB, when you give them YUV lossless codecs like UT video, huffyuv etc... even if you feed them uncompressed YUV (some fourcc's can get YUV treatment, like "UYVY")

Do you know the german Forum "SlashCam" ? There is also a big Discussion about the UT-Video Codecs where Users reported many Problems with UT-Video, even with Premiere CC.

Interesting, but in German ?

UT seems very stable to me , and I personally know many users who use it without issues , and have heard about hundreds more on various forums that use it without issues either. I have nothing against huffyuv and have used it for years, but it's definitely slower

And MagicYUV has taken the Crown ? Not yet NLE's based on ffmpeg/ffdshow reject MagicYUV completely and some reject Lagarith as well.

In pure speed, it has.

ffmpeg based ones fail with magicyuv because magicyuv is VFW only thus far. ffmpeg does have lagarith decoding support, but not encoding support.

Try not to mix up ffmpeg with ffdshow - they are very different animals . Neither ffmpeg or ffdshow have support for magicyuv (yet)

And, what you consider as "Toys" are NLE's that are widely used, that's why i tested them as well. Plus, at the end of the Day it only counts one thing, the Result, nothing else. I've seen Movies made completely with VirtualDub and AviSynth, so i really disagree with you in this Matter.

Yes I'm a huge fan of avisynth and it's capabilities. Just browse some of my old posts. But let's be honest - it's far from what I would consider a usable NLE.

[MickMan]

Hi "poisondeathray",
the author of UT-Video does not speak english ? What a shame. And yes, i know the Problem with a RGB Timeline, many older NLE's are layed out for that and the newer Premiere CS5 and later, yes, many Improvements but not my Cup of Tea anymore. I love AviSynth and while we're at it, then you should know that AviSynth uses the HuffYUV Codec for converting or direct YUY2 Decoding, if the HuffYUV Codec is installed

And of course i share my Observations and Experiences, that's what a Forum is there for, right ? I just don't like Users that write something like "Oh this is Crap, this is the best and God is not GOD" and so on. I like facts and i have no Problem if somebody else tells or shows me a Solution or if i was mistaken. By reading in this Forum i soon saw that here are no "Idiots", that's why i signed up here.

But back to the Codecs: MagicYUV has also great potential. Encoding/Decoding with MagicYUV worked fine, just it "seems" it is only "Top Field First" for all HD Resolutions but sometimes i need a SD Resolution for a Client in NTSC with "Bottom Field First", impossible with MagicYUV, Lagarith or UT-Video and possible with HuffYUV. All four Codecs mentioned here are very stable, no doubt, at the Moment it's just the little Things that can be very annoying. Not to forget, once they work "properly" they can be a real alternative to other Codecs like DNxHD, ProRes or HQX.

"Lightworks" i never tried but heard a lot of good things about this NLE. Still, i really disagree that a good Movie can only be made with a "real" NLE. I mean, the ones i saw made with AviSynth and VirtualDub even made it to popular Festivals. A good Workflow is the Key for a great result. Do you remember what NLE's where used "in the good old Days" ? What Movies where made with these simple Programs ? Who would use these Programs today ? As i wrote before, the Result counts, nothing else.

Regards, MickMan.

[poisondeathray]

I love AviSynth and while we're at it, then you should know that AviSynth uses the HuffYUV Codec for converting or direct YUY2 Decoding, if the HuffYUV Codec is installed

Actually it doesn't. It's just a frameserver. It frameserves YUY2. It's true you can choose to use Huffyuv, but doesn't mean it's the native avisynth codec

But back to the Codecs: MagicYUV has also great potential. Encoding/Decoding with MagicYUV worked fine, just it "seems" it is only "Top Field First" for all HD Resolutions but sometimes i need a SD Resolution for a Client in NTSC with "Bottom Field First", impossible with MagicYUV,

The developer does speak English and posts at Doom9 (down , right now) . He seems attentive to feedback

Interlaced HD is always TFF , and all lossless codecs do not signal field order consistently, or correctly huffyuv included. If you've found a way in some NLE, you've lucked out.

"Lightworks" i never tried but heard a lot of good things about this NLE. Still, i really disagree that a good Movie can only be made with a "real" NLE. I mean, the ones i saw made with AviSynth and VirtualDub even made it to popular Festivals. A good Workflow is the Key for a great result. Do you remember what NLE's where used "in the good old Days" ? What Movies where made with these simple Programs ? Who would use these Programs today ? As i wrote before, the Result counts, nothing else.

I never said you couldn't make a good movie with avisynth only. I'm sure you can, it would just take longer. No sane person on a budget or deadlines would use avisynth for primary editing. Besides - a "good movie" is more about content, direction, acting. In some cases the actual editing choices can play a role.

Use the right tool for the job. I can hammer a nail in with a screwdriver. Yeah it might be cool and novel for some people, but a hammer usually works better. Avisynth is great at many accessory tasks, non linear editing isn't one of them

The man hours saved and tedious hair pulling of real editing make using a real NLE a no brainer. Easily 100x faster . NLE Clip organization alone will save you many hours.

[MickMan]

Hi Poisondeathray,
well, we are getting slowly there to a common agreement Okay, HuffYUV and AviSynth, the documentation clearly states, "if" HuffYUV is installed, then it will be used for YUY2, else the "msyuv.dll" from DirectX/Windows. And NLE's play a secondary Role to me. I liked your Example with the Screwdriver and Hammer, you're right and i agree with you. I just meant, that it does not take a huge packet to make a Film. In the early Days i used VirtuaDubMod, AviSynth and TMPEGEnc with the good old "Amcap" to for Capture.

It worked and stuck long with this because it was fast. My first Premiere was okay, only until i grew with my Ambitions. And now ? After trying so many NLE's i chosen MoviePack Pro Extreme from Cinegy because it leaves nothing open on the things that i want to do.

Doom9 is down ? Do you know why ? And yes i know that HD is always TFF but what i meant is, when i transfer Material for Clients from a VHS/S-VHS in NTSC to DVD then it's BFF, HuffYUV does work very well with this. Have you tried the CCESP Version of HuffYUV ?

And Footage Organization ? That is essential ! I have one Drive for Audio only, one for Video, one for Capture, one for Titles, Backgrounds, Animations, Images and Transitions i made and finally one for the Master, long live the Server ! So this is really a MUST to work fluently.

Regards, MickMan.

[poisondeathray]

Doom9 is down ? Do you know why ?

It's back up now. Not sure why it went down ...

And yes i know that HD is always TFF but what i meant is, when i transfer Material for Clients from a VHS/S-VHS in NTSC to DVD then it's BFF, HuffYUV does work very well with this. Have you tried the CCESP Version of HuffYUV ?

Yes, I 've tried it. It fails in many situations to signal BFF vs TFF or aspect ratio . I can proove it to you - it fails in vegas , premiere (those are the ones I have at home) . But it fails in many other applications as well

It's great that it works for your specific NLE in a specific situation - but be aware it doesn't work accross the board on all setups and scenarios. It fails in the same situations UT video codec and lagarith fails in regards to field order signaling .

For example if you process through avisynth to a lossless intermediate - there is no field order signalling (there is no way for huffyuv to "know" if field order is TFF or BFF) , and thus no way for the NLE to know - ie. you have to manually interpret it anyways

And Footage Organization ? That is essential ! I have one Drive for Audio only, one for Video, one for Capture, one for Titles, Backgrounds, Animations, Images and Transitions i made and finally one for the Master, long live the Server ! So this is really a MUST to work fluently.

Yes that's important, but I was also alluding to multiple shoots on multiple cameras and angles per scene, on different days. Or even consider filespanned clips that modern consumer cameras shoot (split AVCHD) - Clip organization makes it almost impossible (or very daunting) do that that in avisynth alone

[MickMan]

Hi poisondeathray,
okay, i tried different NLE's with HuffYUV and the "Field Problem". You see, the Cinegy Software detects the right Field Order with HuffYUV Captures, very reliable with PAL,SECAM and NTSC. So, i ran an older Premiere Pro 6.5, also with Field Order Detection and guess what, it faild (!), same with Ulead/Corel VideoStudio/MediaStudio, the Fields where Upside down or in the wrong Order. It seems like that Cinegy has a very good Detection in this Aspect. But you can verify this too in VirtualDub (Last Release). Simply load the Capture File and set under "Options" the Preview mode either to "Weave - TFF" or "Weave - BFF" and play the Preview. This only works if under "Preferences" the Option" Directly decode YCbCr Sources" if unchecked so the Codecs get used and not the Internal ones from VirtualDub.

I use the Drastic Codecs because i don't like the native Windows Codecs and the Internal Codecs from VirtualDub cause a "tint" if this Option is turned on if you play a Capture in VirtualDub, even with the Helix and native Windows Codecs, i tested it. I also tried the new Release of "MagicYUV" (rc3) and works great, along with the UtVideo 13.3.1 Version. Both consume about the same CPU load but UtVideo makes smaller Files than MagicYUV. I made a Capture with both Codecs, MagicYUV and UtVideo with the following Settings:

Resolution: 1024x576 (16:9)
Pixel Type: square
Frame Rate: 25 Fps
Interlaced: Top Field First
System: PAL
Color Space: YUY2 4:2:2 16 Bit
Audio: 48.000 Hz, 16 Bit, Stereo PCM

Result with MagicYUV: about 20 GB (Dynamic, Interlaced on, all other Options Default)
Result with UtVideo: about 14 GB (Median, Assume Interlaced on)
Result with HuffYUV: about 15 GB (Predict Median, Convert to YUY2 Selected)

Playback was fine with both and fluent. CPU Load was with both between 23-38 percent in Capture mode, no Frame Drops or Inserts and in Sync with the Audio. Same Capture with HuffYUV: CPU Load between 9-21 Percent (!), also, no Frame Drops or Inserts and in Sync with Audio with fluent Playback. Lagarith gave up at this point for Capture and the CPU Load was between 80-120 Percent (!) with Frame Drops. With a reduced Resolution to 768x576 Lagarith worked like the other Lossles Codecs with a high CPU Load, around 73-94 Percent.

So, my Question at this point is: Why is Cinegy detecting the right Field Order with HuffYUV and other NLE's fail ? I also ran a test with a simple 640x480 Resolution, one with PAL 25 Fps, one with NTSC 29.970 Fps with my JVC Multiformat S-VHS Deck. Codecs where MagicYUV, UtVideo and HuffYUV. Result: MoviePack Pro Extreme detected the right Field Order with HuffYUV for PAL and NTSC, not with MagicYUV or UtVideo, only if i select the Field Order manually. If you could explain this miracle to me, that would be great.

Don't get me wrong, i like UtVideo and MagicYUV very much because they both perform really great without disturbing each other, it's just this thing with the Field Order. My JVC S-VHS Deck switches to the right Field Order automatically and my Typhoon Card shows me the current Status of the Fields in the Monitor Window and switches them accordingly, PAL/SECAM -> TFF, NTSC -> BFF, definitely NOT PAL 60. This is why i am so sure about this with HuffYUV.

Regards, MickMan.

[poisondeathray]

It only works with your specific cingey capture setup and configuration - it's actually a rare situation where field order signalling actually works with huffyuv. I'd be careful to make broad based conclusions based on a few observations on 1 setup, what you have is the exception, not the rule.

But I have no idea why it detects and conveys the correct field order with that specific setup - I haven't even heard of Cingey before.

And did you test if the actual recorded huffyuv file then signals correctly in other programs ? e.g. If you're sending these off to someone else do they need Cingey or related software , or will their software actually interpret it correctly with huffyuv alone ?

Did you test the same scenarios with known BFF, TFF, and progressive content ? How about progressive content sent with interlaced signal ? You're in PAL land, but how about NTSC streams with pulldown cadences ? ie. is it reading the cadence of the content ? or is it just "guessing" ? or is the recieving software just "guessing" ?

"Playback was fine in both", but did you test latency or decoding speed? "playback is fine" just means you reached the minimum FPS without dropping below the actual FPS. That's important metric for capture, but that's not necessarily sufficient for editing smoothly. Do some random seeking with HD streams. Everything just "feels" faster with UT video, faster than huffyuv, a lot faster than lagarith. That's the low latency difference. A rough indicator of decoding speed can be done in vdub with file=>run video analysis pass and look at the FPS. And/or test maximum encoding speeds in a variety of situations

CPU usage is higher during encoding, but the CPU usage is also higher for ut video during DEcoding, because the decoding speed is higher . It's the same with any data transfer . Look at at DRAM ramdrives vs. NAND SSD's vs. HDD's. Or compare RAID0 arrays even with an offboard controller to offload the CPU load . If you plot CPU usage vs. I/O , it's a linear relationship. In general, the faster the I/O, the higher the CPU usage . Also, in general, the more compressed the format, the higher the CPU usage. Typically the latency of huffyuv (left, so fast decoding), is about 3-4x higher (ie. slower) than ut video on a quad core or better. You can measure the ms/frame latency figures . There are dozens of comparisons and test charts published that confirm this as well

[MickMan]

Hi poisondeathray,
about HuffYUV and the different TV Norms PAL/SECAM and NTSC: Tested with TFF (PAL/SECAM) and NTSC (BFF), my Typhoon Card switches the Fields to meet the standards for the used TV Norm. HuffYUV does keep somehow track of it because MoviePack Pro Extreme detected the correct Field order for PAL/SECAM and NTSC. I don't use progressive Material because it's played out back to Tape and DVD for my Clients. I never had to manually Import Material with HuffYUV, only with MagicYUV and UTVideo. Lagarith i leave out at this point because i hardly use it and if, only for YV12 progressive content for the Internet.

And you're right, HuffYUV does run in a single Thread, i was wrong about this. And yes, i did a quick test with HuffYUV at 640x480 in YUY2 wich is with PAL TFF and with NTSC BFF. Result: HuffYUV adapts to the Field Order but maybe it's because my Typhoon Card switches the Fields correctly and HuffYUV just records it how it comes in. In my Monitor Windows of my Card, i see instantly what Field Order is used when i capture and all my Multi-norm VCR's deliver the right Field Order after "Play" is pressed.

Conclusion: It "may" be that HuffYUV is using the right Field Order because my Card and VCR's do. But still this leaves one Question: If HuffYUV is capable of this, why not MagicYUV and UT-Video ? Same Setup, but wrong Field Order. Could it be because MagicYUV and UTVideo are "designed" for HD Content, which is always TFF in PAL and NTSC and simply can't use BFF ?

Quote:
" A rough indicator of decoding speed can be done in vdub with file=>run video analysis pass and look at the FPS. And/or test maximum encoding speeds in a variety of situations"
Quote end.

Yes i did and the analysis pass is between 3000-5000 Fps at my maximum resolution of 1024x576 at 25 Fps TFF (PAL 16:9) for my Typhoon Card at a 15-22 percent CPU load on both of my CPU's. (Dual Pentium 4 at 2.8 GHz each) With all the work i get it would take me Centuries to deliver the Footage back to the Clients if my System couldn't keep up.

There is no doubt that MagicYUV and UTVideo are great Codecs, fast and stable but for me these Codecs only work for PAL, not NTSC and i get Tapes from around the World from TV Stations and Broadcasting Company's in different Formats and Norms. Therefore HuffYUV works for me (only MY personal Opinion) best, for a long time now. Maybe, if MagicYUV and UTVideo consider BFF as well, I'll take another Shot at them.

Regards, MickMan.

[poisondeathray]

If HuffYUV is capable of this, why not MagicYUV and UT-Video ?

Again, I don't know how huffyuv is keeping track of the field order in that specific situation. It certainly doesn't in other situations

Maybe if you upload a few frames from a sample for BFF, TFF it might shed some clues

And you're right, HuffYUV does run in a single Thread

That version does, but there are several huffyuv variants; the mt version is multithreaded, ffvhuff is too IIRC

[MickMan]

Hi poisondeathray,
i use the HuffYUV Version 2.1.1 CCESP Patch 0.2.5 from 2004. This Version came out after the HuffYUV Version 2.2.0 (Released 2003) caused too many Problems and my Version can decode HuffYUV 2.2.0 Versions. I know the ffdshow Variant but not the "mt" Variant of HuffYUV. Did you try that "mt" Version of HuffYUV ? I can upload some Frames but i don't know what the Upload Limit is here plus i need to seek a short Sequence that is not causing any Trouble as it's Broadcast Material from Company's with Copyrights.

Regards, MickMan.

[poisondeathray]

Yes, I've tried them all at one point or another. And yes, some people have problems with certain versions. It seems you have found on that works on your particular setup without problems so stick with it . People were having some problems with colorspace issues, and certain huffyuv variants with different fourcc's causing problems

But all you care about is the field order signaling - so it doesn't matter what the actual content is, just capture something with known TFF, and known BFF. Only a a few frames is all that is necessary to analyze. The upload size here is 500MB now according to the upload box, but someone uploaded a GB file the other day

[MickMan]

Hi poisondeathray,
if you want to try my HuffYUV Version, here it is and contains the Binary for Installation and the Source Code too Windows 9x to XP 32 Bit tested only (!). I never ever had any trouble with this Version of HuffYUV, very reliable, stable and fast.

What the Color Shifts are concerned, there is a Bug in VirtualDub, since Version 1.6 (!). It's the internal Routines and build-in Codecs that need to be disabled in VirtualDub. Go to "Options - Preferences", select "AVI" and disable the Option "Directly Decode Uncompressed YCbCr (YUV) Sources". This disables the internal Codecs of VirtualDub and only the external ones get used. Another Reason for the Color Shifts with UYVY, YUY2 and YVYU is the "msyuv.dll" from Microsoft, there are some buggy Versions out and the last one that i know of, that works fine is the one from DirectX 9.04.

I prepare two short Clips in TFF and BFF with "my" HuffYUV Version and upload it here without Audio, so you can see it yourself, okay ?

Regards, MickMan.

[jagabo]

The AVI Main Header structure and the AVI Stream Header structure have no provisions for interlaced video.

http://msdn.microsoft.com/en-us/library/windows/desktop/dd318180%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/dd318183%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx

The ODML extension can signal interlaced video and the VideoYValidStartLine field of the Field Framing Information structure may allow it to signal field order.

http://www.the-labs.com/Video/odmlff2-avidef.pdf

But few programs use ODML extensions for anything more that flagging >4GB files. Maybe the cce huffyuv mod adds ODML extensions for this.

In any case it's not critical. You can keep track of the field order yourself and force it in your editor/encoder.

[poisondeathray]

Is your 2.1.1 CCESP 0.2.5 any different than the original 2.1.1 CCESP 0.2.5 mod ? ie. Has it been "modified" from the mod ?

[MickMan]

Hi poisondeathray,
no, i did not mod this Version of HuffYUV and got it from a CD that was included with a PC Magazine, not off the Web.

@jagabo
Thanks for the Links and the pdf "avidef" was very interesting. Looks like HuffYUV was programmed that way

Regards, MickMan.

[poisondeathray]

md5 checksum is the same for the original 0.2.5 huffyuv ccesp patch dll, and the dll in your zip file

[MickMan]

There are News about this "Field Order" Issue with MagicYUV and UtVideo:
Both Codecs can't handle RawVBI correctly, Microsoft removed this Feature since Windows Vista, and if a Video Device installs their own Drivers for RawVBI on such a System, then this Error comes up and the Field Order is reversed with both Codecs. Disabling RawVBI on such Systems in the Driver Configuration solves this Field Order Problem with both Codecs. On Windows 98 to XP, RawVBI is still available and implemented.

BTW: HuffYUV 2.1.1 (Original), HuffYUV 2.1.1 CCESP 0.2.5 Patch, HuffYUV-MT (Version 2.1.1 based on CCESP Patch 0.2.5) and Lagarith work fine with enabled RawVBI in Capture Device Drivers on Windows Vista to 8, in both Modes (TFF/BFF), tested. (32/64 Bit Windows Versions) The newer Devices don't support or offer RawVBI anymore because Microsoft removed it.

Regards, MickMan

P.S.: "Both Codecs" means MagicYUV and UtVideo.