digitalFAQ.com Forum

digitalFAQ.com Forum (https://www.digitalfaq.com/forum/)
-   Encode, Convert for discs (https://www.digitalfaq.com/forum/video-conversion/)
-   -   Lossless transcode from HuffYUV-MT to HuffYUV? (https://www.digitalfaq.com/forum/video-conversion/12994-lossless-transcode-huffyuv.html)

kaliree 09-30-2022 09:42 PM

I'm new to using VirtualDub. I have downloaded the VirtualDub 1.9.11 zip from LS's thread as well as the HuffYUV and HuffYUV-MT codecs from the same thread. Running VirtualDub on Windows 10. I have a HuffYUV file that was encoded with HuffYUV-MT and would like to losslessly convert it to standard HuffYUV.

What is the most reliable method to perform that conversion in VirtualDub (or whatever other tool would be better suited to the task)?

Thanks!

-- merged --

I at least figured out part of it, I think. I did the following:

1. Opened the HuffYUV-MT AVI in VirtualDub
2. Options > Preferences > Threading
⁃ Set threading to “1” as that seemed to be the most efficient threading option on a modern CPU
⁃ Left color depth at default 16 bit (unsure of the input file’s depth, but the source was a home VHS recording)
⁃ Enabled 3D accel
3. Video > Video Color Depth
⁃ Left at defaults, but just realized that default is set to 24bit RGB (888). I think the input file is YUY2 4:2:2, but I’m not sure.
4. Video > Compression
⁃ Selected HuffYUV v2.1.1 - CCESP Patch v0.2.2 as the codec
⁃ Left Default configuration options for the codec
5. File > Save as AVI

The audio is PCM and was left as the default PCM. The output file does read in MediaInfo as a standard HuffYUV file now.

Should I change the color depth to YUY2 4:2:2 for the output? LordSmurf performed the capture for me about 10 years ago, so I would assume the HuffYUV files are all a standard color space as all video came from three consumer VHS video cameras from the 80’s through the 90’s, so nothing that would output in RGB to my knowledge. Any other changes to that workflow to keep it lossless?

As another somewhat related question, any thoughts on archiving the lossless masters in FFV1 as MKVs? I know HuffYUV is the standard for VHS captures and is better for an intermediate lossless format for editing and restoration work (which I plan to do), but once that is complete I'm planning to have compressed copies for watching and sharing with family, but still want to keep the masters (or at least the masters with only basic cut and splicing editing to organize the footage) archived and FFV1 sounds like it provides significantly better compression.

keaton 10-01-2022 09:18 PM

Seems like you figured this out. When I do a lossless conversion from one format to another in Virtualdub, I select Fast Recompress on the Video Menu, then select my Codec under Video -> Compression (for HuffYUV there's no configuration options to consider changing), then File -> Save As. Using Fast Recompress eliminates the Color Depth option. If the original file was 4:2:2, and you save as HuffYUV, it will remain 4:2:2. No loss of color information will occur.

I don't have any experience with FFV. I use Lagarith instead of HuffYUV for my archival files. For Lagarith, I select YUY2 mode in the Configuration options for 4:2:2 color. I'd assume, from what you say, that FFV probably compresses much better than Lagarith. All I can say is Lagarith is somewhat more efficient for storage space than HuffYUV. I guess it's a personal decision as to what codec you choose, and is based on what your requirements are. An important requirement should be that the codec is likely to be supported in whatever toolset(s) you expect to use in future. Storage space is very cheap, and has continued to become cheaper with time. Hard Drive sizes seem to double at least every few years at a similar price point. So getting maximum compression may not be as important, unless you have a very large amount of video to store.

kaliree 10-02-2022 02:47 AM

Thanks Keaton. I appreciate the input. Looks like Fast Recompress is still keeping the RGB (888) color space for the export, so the source file must have been RGB (888) as well? 24bit RGB (888) is the default output color space when I don't use Fast Recompress, which is one reason I'm questioning if that's true. I suppose that could be the color space of the source file. I thought RGB color spaces tended to lose data from analog sources like VHS.

When he gets some time, maybe Lord Smurf will chime in with his approach and if he would have used RGB (888) as the capture color space, though he probably doesn't remember a capture from a decade ago, I can still hope. 😅 At the moment I'm just trying to eliminate having video in HuffYUV-MT so I remove one more variable from the workflow and maintaining accessibility/compatibility in the future.

I agree that storage is getting cheaper all the time and I wouldn't want to lose information just to save space, hence the need for lossless conversion. However, for the purpose of cloud backups and elsewhere, saving even 10-15% over HuffYUV in server space storage costs would add up. I have about 4TB of family videos in HuffYUV. Even in the highest 7zip compression level it only save about 200-400GB of that and it is probably about a week of 24/7 work to fully compress on my current system (decompression might be better, but I haven't tested it yet).

FFV1 is obviously a much younger codec than HuffYUV and is not targeting VHS capture. It is open source, closely related to the FFMpeg project, and seems to have gained substantial ground among libraries and educational institutions as an archival format, (even meriting an article from the Library of Congress discussing its use for archiving). So, I don't think it is going anywhere, anytime soon. However, I just discovered it doesn't retain timecode or closed captioning in MKV containers (maybe not in AVI either, though I'm not clear if it is a limitation of the codec, container, or both). The closed captioning wouldn't matter for my purpose, but I wouldn't want to lose any time code metadata that was embedded during the original capture.

traal 10-02-2022 09:42 AM

Quote:

Originally Posted by kaliree (Post 86937)
any thoughts on archiving the lossless masters in FFV1 as MKVs? ... still want to keep the masters (or at least the masters with only basic cut and splicing editing to organize the footage) archived and FFV1 sounds like it provides significantly better compression.

I archive the masters untouched so if someday I realize I did the conversion wrong, I can go back to the masters and do it over again. This helps me sleep at night.

I also keep a restored, lossless ffv1+FLAC version in .mkv complete with chapter stops, ready for conversion to the latest codec of the day.

And lastly, I also keep the AviSynth script and chapters file so I can easily recreate the .mkv from the master. As my restoration skills improve, I find myself doing this from time to time.

kaliree 10-02-2022 01:42 PM

Storage for two lossless copies isn’t an option for right now, but that’s a good idea. I like how thorough your approach is. I wasn’t planning on doing chapters, I was intending to split the videos into separate, ordered files, but that’s probably a good idea to have chapters for the originals as well.

-- merged --

I'm still encountering some trouble with losslessly converting these files, so I'm hoping someone can help. I have three files using the HuffYUV-MT codec. I was able to successfully convert two of them to the standard HuffYUV codec using VirtualDub's "Fast Recompress" option. However, I have two issues:

1. The third video file is failing to convert. I attempted to convert it in VirtualDub like the other two, but repeatedly encountered an out of bounds memory error as seen in the attached screenshot. The screenshot shows the result of scanning for errors in the frames through VD, but it is the same out of bounds memory error when running the actual conversion.

--While it claims it is a memory error, it seems to be an issue with the file. VD notes it is only guessing at the actual error. I tested it with multiple copies of the file, being read from different drives (both SSD and HDD), over different I/O ports and cables. This failing video is less than half the size of the largest video that converted successfully. The file plays without issue in VD and other players (playback includes the frames VD specifically cites in the error messages).
--The error does not always occur on the same precise frame, but is within a range of about 500 frames of the frame in the attached error message, yet all of those frames will play in VD without issue.
--I am using the HuffYUV and HuffYUV-MT codecs and VD 1.9.11 that I downloaded directly from DigitalFAQ a few days ago.

---Any thoughts on how I could successfully convert this file with no data loss? Would it be worth attempting to convert to Lagarith through VD or FFV1 through ffmpeg and then to standard HuffYUV? Any concerns about data loss? I read that Lagarith uses YV12 color space and I'm not clear if that would color data loss.

2. The color space of the source files may be YUV and may be converted to RGB. I tested converting the problem file in Avidemux to see if that would be more successful. Avidemux apparently doesn't have the HuffYUV-MT codec, so it couldn't even decode the HuffYUV-MT video stream and the conversion failed. However Avidemux reported that the color space for the all of the original HuffYUV-MT files were YUV.

--I did read that "Fast Compress" should maintain the YUV color space instead of converting it to RGB like the "Full Processing" as noted in this thread and elsewhere like this thread: https://www.dvinfo.net/forum/non-lin...-mode-rgb.html

--If VD isn't changing the color space, then that seems odd that the files would be in RGB, unless the capture was performed to RGB, which would have been unwise since the conversion from YUV on the VHS to RGB would have caused (at least some) color data loss, correct?

EDIT: Some notes for context. These are irreplaceable family videos recorded on VHS in the 80's and 90's, often at SLP in the 80's—so I'm very concerned about preventing any additional quality loss beyond the initial capture. A family member disposed of the original tapes years ago, once these HuffYUV files were created as digital masters (they were professionally captured by DigitalFAQ about 10 years ago), so I don't have the option to capture from the original tapes again.

lollo2 10-05-2022 03:43 AM

1 Attachment(s)
HuffYUV v2.1.1 - CCESP Patch v0.2.2 is a hacked version of the original codec, to be compliant with Cinema Craft Encoder, an old MPEG2 encoder. Do not convert your capture to this codec, but to the original HuffYUV codec.
BTW, also the original capture should be done with the original HuffYUV codec, not the hacked multi-threading Huffyuv_MT

For conversion use last official VirtualDub version, 1.10.4

There is no reason to capture or to convert to RGB while changing codec

Lagarith can use YUV

It is not clear to me what files are RGB after your conversion

VirtualDub converts to RGB if you use a filter, not if you convert. It is perfectly capable to manipulate YUV colorspace in input and output. When not using "Fast recompress", be sure to select the following in "Video" -> "Color Depth..."
Attachment 15653

kaliree 10-05-2022 04:51 AM

Thanks lollo2. I downloaded that version of VD and HuffYUV from this thread on this site as I thought these were the most reliable and standard versions used by Lord Smurf and the team at Digital FAQ who did the captures for me:

https://www.digitalfaq.com/forum/vid...lters-pre.html

Likewise, I had not tried VD 1.10.x or VD2 as I had read in other threads that Lord Smurf noted miscellaneous issues with them and no functional advantage for most standard workflows. I didn't select HuffYUV-MT for the captures as I didn't perform the captures. That's why I'm trying to ensure that the lossless masters are all in stock HuffYUV to keep it as standardized, reliable, and widely compatible as possible without sacrificing any information.

With that said, I'll take your suggestions and try converting again using VD 1.10.4 and I'll grab HuffYUV elsewhere. VideoHelp and this site, both seem to have HuffYUV 2.1.1 as the main available version to download. What HuffYUV version are you suggesting instead? Good to know that Lagarith can use YUV and not just YV12.

I'm not sure if any of the files captured with HuffYUV-MT were originally captured as YUV. The HuffYUV-MT video file that was failing to covert and another HuffYUV-MT file that I successfully converted to HuffYUV in VD, both show up as YUV 4:2:0 in Avidemux's "Information" window. I will see if some of the others that are encoded with standard HuffYUV and with HuffYUV-MT show the same color space in Avidemux. I'm not sure if Avidemux is reporting the color space accurately. Is there a good tool to check and confirm the color space of the files? I haven't found such a tool yet, after quite a bit of searching. The converted files seem to all be RGB once converted in VD, according the VD log showing RGB (888) as the color space when using "Fast Recompress" on those files. I have not applied any filters or the like to cause VD to perform YUV > RGB conversion.

Thanks again for your response.


Here is the Avidemux output for the file that was failing to convert that I referenced above:

Code:

=====================================================
Video
=====================================================
Codec 4CC:                        HYMT
Image Size:                        720 x 480
Aspect Ratio:                        1:1 (1:1)
Frame Rate:                        29.970 fps
Average Bitrate:                n/a
Total Duration:                        01:47:00.881
Pixel format:                        YUV 4:2:0, 8-bit
Color range:                        Limited (MPEG)
Color primaries:                BT.709
Transfer characteristics:        BT.709
Color space:                        BT.709

=====================================================
Video Codec Extradata
=====================================================
Size:                                224
Extradata:                        41 18 10 00 22 43 24 25 26 27 28 2A 4B 6C 8D AE CF D0 11 08 D2 B3 B4 B5 36 75 36 35 36 37 36 37 36 35 37 55 37 56 37 56 39 38 39 57 39 38 59 38 79 38 19 42 37 59 37 59 58 77 38 97 D6 35 37 36 (+160 bytes)

=====================================================
Audio (1 active track)
=====================================================
Codec:                                PCM
Channels:                        Stereo
Bitrate:                        384000 Bps / 3072 kbps
Frequency:                        96000 Hz
Total Duration:                        01:47:00.881


EDIT: Here's some more Avidemux output for one of the standard HuffYUV files that I did not convert (unlike HuffYUV-MT, Avidemux could play this video stream without issue):

Code:


=====================================================
Video
=====================================================
Codec 4CC:                        HFYU
Image Size:                        720 x 480
Aspect Ratio:                        1:1 (1:1)
Frame Rate:                        29.970 fps
Average Bitrate:                57747 kbps
Total Duration:                        00:03:07.453
Pixel format:                        YUV 4:2:2, 8-bit
Color range:                        Limited (MPEG)
Color primaries:                BT.709
Transfer characteristics:        BT.709
Color space:                        BT.709

=====================================================
Video Codec Extradata
=====================================================
Size:                                192
Extradata:                        02 10 00 00 42 25 26 47 68 C9 0A 09 0B 0B 0C 09 0D 09 0E 09 0F 08 10 09 D1 32 31 D2 53 34 53 74 35 37 36 37 38 59 7A 38 37 38 79 3A 39 3A 59 58 39 38 37 58 39 78 59 5A 98 79 3A 39 38 37 56 35 (+128 bytes)

=====================================================
Audio (1 active track)
=====================================================
Codec:                                PCM
Channels:                        Stereo
Bitrate:                        192000 Bps / 1536 kbps
Frequency:                        48000 Hz
Total Duration:                        00:03:07.453


lollo2 10-05-2022 05:41 AM

Quote:

I had not tried VD 1.10.x or VD2 as I had read in other threads that Lord Smurf noted miscellaneous issues with them and no functional advantage for most standard workflows
That's for capture purposes, not for post-processing.

Quote:

The HuffYUV-MT video file that was failing to covert and another HuffYUV-MT file that I successfully converted to HuffYUV in VD, both show up as YUV 4:2:0 in Avidemux's "Information" window
All the captures should be YUV 4:2:2. I understand that the file that is failing in your process is YUV 4:2:0. Could you run MediaInfo on that to confirm the AviDemux report? AviDemux and other tools may have problems with hacked codecs.
BTW, 4:2:0 chroma sampling should not make the conversion to fail. There must be something else.

Edit:
Quote:

What HuffYUV version are you suggesting instead?
The original last HuffYUV v2.1.1

kaliree 10-05-2022 07:01 AM

3 Attachment(s)
Okay. Thanks for clarifying about the VD and codec versions. I'll try that out to see if I get better results. I have attached MediaInfo screenshots as requested. MediaInfo doesn't seem to read the color space until after I convert the MT files in VD.

1. The first is the problem file that won't successfully convert in VD.
2. The second is a HuffYUV-MT file that I was able to convert—but the image is prior to the conversion.
3. The third is the second file after successful conversion to standard HuffYUV.

lollo2 10-05-2022 07:47 AM

I don't know what to say. I am not familiar with HuffYUV-MT codec, and probably it's not the root cause.
If it can help this is what MediaInfo reports about one of my captures.
About your failed conversion, try another PC with more power, another VirtulDub version, original HuffYUV as final codec, etc.

Code:

General
Complete name                            : C:\Users\giuse\Videos\Acquisizioni\ufo_sIII1d_amtv_2_v2.avi
Format                                  : AVI
Format/Info                              : Audio Video Interleave
File size                                : 23.4 GiB
Duration                                : 1 h 0 min
Overall bit rate                        : 55.3 Mb/s

Video
ID                                      : 0
Format                                  : HuffYUV
Format version                          : Version 2
Codec ID                                : HFYU
Duration                                : 1 h 0 min
Bit rate                                : 51.5 Mb/s
Width                                    : 720 pixels
Height                                  : 576 pixels
Display aspect ratio                    : 5:4
Frame rate                              : 25.000 FPS
Standard                                : PAL
Color space                              : YUV
Chroma subsampling                      : 4:2:2
Bit depth                                : 8 bits
Scan type                                : Interlaced
Bits/(Pixel*Frame)                      : 4.971
Stream size                              : 21.8 GiB (93%)

Audio
ID                                      : 1
Format                                  : PCM
Format settings                          : Little / Signed
Codec ID                                : 1
Duration                                : 1 h 0 min
Bit rate mode                            : Constant
Bit rate                                : 1 536 kb/s
Channel(s)                              : 2 channels
Sampling rate                            : 48.0 kHz
Bit depth                                : 16 bits
Stream size                              : 667 MiB (3%)
Alignment                                : Aligned on interleaves


kaliree 10-05-2022 11:10 PM

5 Attachment(s)
I appreciate the help, either way. I repeated one of the successful conversion using VD 1.10.4 and the stock HuffYUV and HuffYUV-MT codecs downloaded from VideoHelp. I removed the previous versions of the codec DLL's from Windows before adding the VideHelp versions.

The conversion completed successfully once again, and once again it resulted in an RGB color space. I have attached images of the MediaInfo output comparing all three versions of the file. Going left to right in the image it is:

The original file encoded with HuffYUV-MT > The first conversion using VD 1.9.11 and DigitalFAQ's HuffYUV codecs > The second conversion using VD 1.10.4 and VideoHelp HuffYUV codecs.

Just in case anyone is seeing something I might be missing. I have included screenshots from VD 1.10.4 of the conversion log, the settings, and what the color space settings show (even though I know those aren't supposed to be relevant when using "Fast Compress" as I did).

I will be trying a conversion of the problem file next, to at least see if it converts to standard HuffYUV successfully, but I'm thinking at least some of the files that I received from the capture process were converted to RGB or captured as RGB before they were sent to me. I know I could manually change the color space, but that would just be throwing away more data if the source is already converted from YUV > RGB as I suspect, correct? RGB conversion will occur when working with filters for restoration in VD regardless, right?

EDIT: Just to verify the results, I installed MediaInfo on another OS and ran it from there on the same files, but the results were the same.

lollo2 10-06-2022 01:49 AM

Are you sure that the original captured files are RGB? I suspect not.

When using "Fast compress" VirtualDub try to match input characteristics with output codec specifications. It is possible that is failing with HuffyUV-MT.
Try to set the colorspace as in https://www.digitalfaq.com/forum/vid...html#post86993

kaliree 10-06-2022 03:30 AM

Thanks again for the advice. I can certainly do you suggested. My concern is I don’t know which option will cause color data loss as I don’t know if the original file is RGB or YUV prior to codec conversion.

How can I verify the color space of the MT file since it doesn’t seem to be reported in the metadata (or at least not that MediaInfo can detect). The source was VHS so that had to be YUV, right? I just don’t know how it was processed during the capture. I would think there would be some application or feature for checking pixels and determining the color space of a video (or at least an image), but it seems like color space just has to be guessed if it isn’t explicitly in the metadata.

I suppose I can just try both options and see if I can detect a visible difference in the transcoded file, but that may not be apparent to my untrained eye, or my displays may not be calibrated accurately enough for such an issue to be readily seen.

lollo2 10-06-2022 07:28 AM

Quote:

I don’t know if the original file is RGB or YUV prior to codec conversion.
Try to open the file with VLC or AviSynth, and check for "Tools -> Codec Information" in the first or run a simple script with the instruction Info() for the second and they will tell you.

Or post a sample of your "supposed RGB" capture and we'll check.

kaliree 10-06-2022 08:18 PM

3 Attachment(s)
VLC doesn't isn't able to decode HuffYUV-MT, so it didn't provide any codec information. I attempted to get Avisynth+ running, but apparently I'm missing some dependencies or something as I received the attached error when trying to launch AvsPmod, so I'm not sure where it is looking for the avisynth dll. I also attached the setup log for avisynth, which didn't report any errors that I'm seeing.

I've never used Avisynth. I know it does most things based on a script, but is there no GUI at all? I didn't see an exe to run. That's what led me to AvsPmod to create the script.

In any event, I'm giving up on it for today and I have just attached a short clip of one of the videos encoded in HuffYUV-MT (this is prior to converting the video to standard HuffYUV). Are you just going to evaluate the clip visually to determine the color space, or were you planning to run the sample through your own setup to pull the data from Avisynth?

kaliree 10-06-2022 08:27 PM

1 Attachment(s)
On a whim, I tried running the video in IINA on macOS and it was able to play the MT encoded file. The information on the codec isn't helpful for color space though, unfortunately. The inspector reports the color space as "unspecified". I have attached the output.

lordsmurf 10-07-2022 03:03 AM

I don't have much time to help here, however, quick few comments...

Quote:

Originally Posted by kaliree (Post 86940)
However, for the purpose of cloud backups

"Cloud" (online) backups are not good for large files, regardless of format. It's for compressed copies, a lossy backup.

Quote:

FFV1 is obviously a much younger codec than HuffYUV and is not targeting VHS capture. It is open source, closely related to the FFMpeg project, and seems to have gained substantial ground among libraries and educational institutions as an archival format, (even meriting an article from the Library of Congress discussing its use for archiving). So, I don't think it is going anywhere, anytime soon. However, I just discovered it doesn't retain timecode or closed captioning in MKV containers (maybe not in AVI either, though I'm not clear if it is a limitation of the codec, container, or both).
Don't be impressed by LoC for digital anything. They're far behind the curve, out of the loop, and too often swayed by random advice on matters (especially lobbyists, paid or not). LoC is awesome with paper documents, but sucks for digital. It's NOT a best methods, simply "a method" (sometimes viable, sometimes not really, sometimes not at all). Remember, government job pay sucks (archivists get ~$45k/year avg in DC, which is way below DC annual avg cost of living), and digital isn't a field that gets talent for low pay.

FFV1 is heavily data compressed, and that can pose issues.

Great HD lossless, terrible SD lossless (VHS, etc). SD cannot be extrapolated from HD, it always fails, be it capture cards, software, or codecs.

Quote:

Originally Posted by lollo2 (Post 86993)
HuffYUV v2.1.1 - CCESP Patch v0.2.2 is a hacked version of the original codec, to be compliant with Cinema Craft Encoder, an old MPEG2 encoder. Do not convert your capture to this codec, but to the original HuffYUV codec.
BTW, also the original capture should be done with the original HuffYUV codec, not the hacked multi-threading Huffyuv_MT

Agree. But it's not bad, the videos not ruined, had those codecs been used. There was a time and place for those codecs. The official Huffyuv lasted, those not so much. Moving forward, just don't do that again, for those still capturing.

Quote:

For conversion use last official VirtualDub version, 1.10.4
Quote:

Originally Posted by kaliree (Post 86994)
Likewise, I had not tried VD 1.10.x or VD2 as I had read in other threads that Lord Smurf noted miscellaneous issues with them and no functional advantage for most standard workflows.

VirtualDub2 is actually good at this, simple A>B conversions.

However:
- almost always terrible for capture (few exceptions)
- filters have issues, so never use it to filter
- the dev (Shekh) ignored bug reports, disappeared often; he's not been online since summer 2021; he really pissed me off, I spent lots of time gathering screen shots, video clips and other data for him as requested (sample), to support the bug report ... then nothing happened, not even an acknowledgment. What an ass. Then dev of 2 ceased entirely, as he stated in this post.

Quote:

Here is the Avidemux output for the file that was failing to convert that I referenced above:
Just note that reading may have false data.

lollo2 10-07-2022 06:02 AM

5 Attachment(s)
Quote:

I've never used Avisynth. I know it does most things based on a script, ...
I downloaded your sample, and in fact the capture is RGB32 :huh1: I do not know why.

Here the VirtualDub report and the AviSynth report:
Attachment 15670
Attachment 15671

I converted your sample from RGB32 HuffYUV_MT to YUV 4:2:2 Huffy. To do that in VirtualDub I set:
"Video" -> "Full processing mode"
"Video" -> "Color depth..." "Decompression format" to "Autoselect" and "Output format to compressor/display" to "4:2:2 YCbCr (YUY2)

The converted file is now HuffYUV YUY2 4:2:2:
Attachment 15672

You could achieve the colorspace conversion in AviSynth as well, but I see you are not familiar with it.
The RGB <-> YUV is not completely lossless, but in this case should not introduce issues.
The levels of your capture (in this small sample) are inside 16-235 range, but the blacks are a little crushed:
Attachment 15673

I do not know about the fail you have while converting one of your files.

Attached my converted files

Hushpower 12-12-2022 07:10 PM

I came across this topic when researching HYMT and noted with interest the comments re RGB with HUFF.

I have had "trouble" also with RGB in HUFFYUV. There was an extensive discussion about this starting here:

https://forum.videohelp.com/threads/...e3#post2660536

There's a lot of blurb there, but essentially every time I used HUFFYUV to capture with the earlier VDubs, I'd get RGB. I never resolved what was going on with HUFFYUV and RGB.


All times are GMT -5. The time now is 09:26 AM

Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.