VideoHelp Forum

Try DVDFab and download streaming video, copy, convert or make Blu-rays,DVDs! Download free trial !
+ Reply to Thread
Results 1 to 27 of 27
Thread
  1. Member
    Join Date
    Dec 2010
    Location
    quebec
    Search Comp PM
    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%)
    Quote Quote  
  2. Yes I've used them , they are all uncompressed variations so filesize will always be large
    Quote Quote  
  3. Lone soldier Cauptain's Avatar
    Join Date
    Jan 2006
    Location
    Brazil
    Search Comp PM
    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
    Quote Quote  
  4. Member
    Join Date
    Jun 2014
    Location
    Europe
    Search Comp PM
    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.
    Quote Quote  
  5. @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
    Quote Quote  
  6. Banned
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    Originally Posted by MickMan View Post
    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?
    Quote Quote  
  7. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    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
    Quote Quote  
  8. Member
    Join Date
    Jun 2014
    Location
    Europe
    Search Comp PM
    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.
    Last edited by MickMan; 11th Jun 2014 at 15:46.
    Quote Quote  
  9. Originally Posted by MickMan View Post
    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
    Quote Quote  
  10. Member
    Join Date
    Jun 2014
    Location
    Europe
    Search Comp PM
    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.
    Quote Quote  
  11. Originally Posted by MickMan View Post
    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.
    Last edited by poisondeathray; 11th Jun 2014 at 16:38.
    Quote Quote  
  12. Member
    Join Date
    Jun 2014
    Location
    Europe
    Search Comp PM
    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.
    Quote Quote  
  13. Originally Posted by MickMan View Post
    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.
    Quote Quote  
  14. Member
    Join Date
    Jun 2014
    Location
    Europe
    Search Comp PM
    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.
    Quote Quote  
  15. Originally Posted by MickMan View Post


    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
    Quote Quote  
  16. Member
    Join Date
    Jun 2014
    Location
    Europe
    Search Comp PM
    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.
    Last edited by MickMan; 13th Jun 2014 at 15:06.
    Quote Quote  
  17. 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
    Quote Quote  
  18. Member
    Join Date
    Jun 2014
    Location
    Europe
    Search Comp PM
    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.
    Quote Quote  
  19. 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
    Quote Quote  
  20. Member
    Join Date
    Jun 2014
    Location
    Europe
    Search Comp PM
    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.
    Quote Quote  
  21. 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
    Quote Quote  
  22. Member
    Join Date
    Jun 2014
    Location
    Europe
    Search Comp PM
    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.
    Image Attached Files
    Quote Quote  
  23. 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.
    Quote Quote  
  24. 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 ?
    Quote Quote  
  25. Member
    Join Date
    Jun 2014
    Location
    Europe
    Search Comp PM
    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.
    Quote Quote  
  26. md5 checksum is the same for the original 0.2.5 huffyuv ccesp patch dll, and the dll in your zip file
    Quote Quote  
  27. Member
    Join Date
    Jun 2014
    Location
    Europe
    Search Comp PM
    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.
    Last edited by MickMan; 29th Jun 2015 at 16:23.
    Quote Quote  



Similar Threads