Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
29th January 2004, 11:01 | #21 | Link |
Retired AviSynth Dev ;)
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
|
I will have a look at it ASAP. The CCE-patch should also be upgraded to 0.2.3! Thanks for the detailed information!
Until then stick to plain old 2.1.1!
__________________
Regards, sh0dan // VoxPod |
30th January 2004, 08:30 | #22 | Link |
Registered User
Join Date: Dec 2001
Posts: 1,219
|
@Shodan: this is coming completely out from left field, but do you think you might be able to add a special optimization for frames that are empty? i.e. solid black in every channel. I often encode overlays and such out of after effects, and its mostly just empty frames, but they still use up quite a bit of space in huffyuv, totalling a few gigabytes over a 15 or 20 minute long clip.
I've recently been using corepng for this sort of material, as it can compress the files down to about 40-50mb, as opposed to about 4-5gb with huffyuv. It's about 3-4x slower though. So anyways, I was thinking it doesn't seem like it would be so difficult to add in a special case for empty frames, so I was wondering if this might be a possibility? Another use for such a feature would be for the alpha channel. It seems strange to have the user check a box to indicate whether to use the alpha channel data. If there were an optimization in place to compress an empty channel, when people could leave the rgba box checked all the time and not have to worry about having gigabytes added to the output file. If the alpha data exists it would get compressed as normal, if it doesnt exist it would get compressed so small that its negligable. Its annoying sometimes to encode something and realize that you forgot to uncheck the rgba box, and the encode is eating a hole in your hard drive But anyways, thatnks for your work on this codec. I have been trying the reduced resolution option this past week and it is incredibly great, I can't believe no one did something like this already |
1st February 2004, 01:28 | #23 | Link |
Fascinated Lurker
Join Date: Feb 2002
Location: Durham, UK
Posts: 243
|
@sh0dan: This is completely selfish request-making from me so feel free to just flat-out refuse
HuffYUV is an invaluable codec. It's fast,it's pretty stable and it's simple. Now, I know there are all sorts of codecs out there which can do all kinds of colorspaces, delta frames and whatnot but essentially I'd like to see HuffYUV be extended enough that it's flexible but not so much that it loses its simplicity and stability. In short I'd love to see a HuffYUV that had a more wide-ranging acceptance of colorspaces. YV12 would be great, obviously, and possibly some 4:4:4 YUV too in anticipation for future avisynth capabilities - maybe with YUV+alpha support too? I think it would be great to have these colourspaces all under one roof with the simple fast compression technique that huffyuv is known for. (Oh and before you mention ffvfw I'll stress the word stability :P) |
15th February 2004, 18:44 | #26 | Link | |
Registered User
Join Date: Feb 2004
Posts: 9
|
Quote:
Well anyway, you better use 0.2.3. The only difference should be in one method, it's about initializing some datastructure differently. But this way those bytes aren't set to random values depending on your application and you can join huffyuvs made with different programms in vdub. I made this change on request by some friend. There is also a 0.2.4 that stores the interlaced flag, too. But differently than your codec does it. And since I can't remember the reason why i did it this way (not a simple bit in the extra[3] field) - i think it was to detect garbage there, but then old versions initialized that field to 0, too :) - i should remove 0.2.4. And do a 0.2.5 that stores it like your version does. This way there would be at least some compatibility... bastel ps: it's not so cool that the old berkley huffyuv site points to avisynth site now, not the new huffyuv site. pps: i guess i am hiding my huffyuv ccesp homepage too well ;) but there were never any real plans to release the patched huffyuv to the general public, the idea was that it would make its way out there or not. it was made for friends after all. |
|
19th February 2004, 15:36 | #27 | Link |
Registered User
Join Date: Dec 2002
Posts: 24
|
I encountered similar problems: it seems impossible to export from P7 using huffyuv. Tried all versions/all settings/all color models.
However, as I can only produce errors - new clue as to WHY? VD(mod) is lucky with all these huffyuv versions, so it seems a problem related to Premiere(7). @shodan (not nagging, just asking info): is there anything to be expected soon in that direction? - Otherwise, I'd have to go and buy another large HD 'cause I am stuck ;=) /sigma9 |
20th February 2004, 12:08 | #28 | Link | |
Alias fragger
Join Date: Jul 2003
Location: the Netherlands
Posts: 863
|
Quote:
|
|
11th March 2004, 03:50 | #30 | Link |
Registered User
Join Date: Jan 2004
Posts: 2
|
Read AVI HuffyUV 2.2 with Pinnacle Studio 8: How to?
Hi, someone know how to open avi files encoded with huffyuv 2.2 in pinnacle studio 8? when i try to open a file the program crash!!!
why?!? ps: in virtualdub the avi play good!! THANKS |
23rd April 2004, 07:52 | #33 | Link |
Registered User
Join Date: Apr 2003
Location: Brazil
Posts: 87
|
It works for me, and the reduced resolution is a REALLY nice thing..
I'm now using this new huffyuv instead of the old ones, BUT I can't seem to be able to open files I encoded with 'v2.1.1 - CCESP Patch v0.2.2'. My Field Threshold is the same, it should work. (I get corruped output... just like when you change the field threshold) I had to install the old huffyuv with another fourcc, and then force it using virtualdub... to finally convert to the new huffy... Anyway.. I hope you continue working on huffyuv... because It's a nice codec and I use it in all my movies. |
3rd May 2004, 03:20 | #34 | Link | |
Registered User
Join Date: Jul 2003
Location: Connecticut
Posts: 99
|
Field Threshold
I have a HUFFY field threshold question that I have been puzzling over.
Quote:
Would any of the contributers to this thread be able to shed some light on this? Thanks. Last edited by North2Polaris; 3rd May 2004 at 03:57. |
|
8th May 2004, 10:57 | #36 | Link |
Registered User
Join Date: Oct 2002
Posts: 74
|
Could anyone answer why this version of the codec is still on doom9's download page?
It IS after all b0rked and unusable for a lot of people. Just the other day a friend of mine downloaded this, encoded one thing to huffy (took many hours to encode) and then find that the encode is useless. Please reinstate 2.1.1 (with or without ccesp patch) on the download page until 2.2.x is fixed. |
14th May 2004, 23:33 | #39 | Link | |
Registered User
Join Date: Feb 2004
Posts: 9
|
Re: Field Threshold
Quote:
If you are capturing 240 lines ntsc, then it's the same as with 288 for pal and if you do 480, this is equivalent to 576 pal. The problem of the hardcoded 288 value is that if you have the funky idea of capturing, say... 288 lines with ntsc. There you need interlaced as you use data of 2 fields. It will look ugly, tho. Just capture at 240/480 and 288/576 only and you shouldn't run into problems if you leave the threshold at 288. If you work with progressive material (for example you ivtced some ntsc material or have a progressive camera), and are sure that even at 480/576 lines your video is progressive, then you can set the threshold to that value to gain better compression. huffyuv ceesp patch 0.2.4 stores the interlace setting in the file, so one can change the global setting, it does not affect the recorded files. (even tho the way it stores it is kinda akward - and I didn't even smoke something when writing that and still wonder why I did it this way. I guess 0.2.5 is necessary :P) bas |
|
15th May 2004, 00:07 | #40 | Link |
Registered User
Join Date: Jul 2003
Location: Connecticut
Posts: 99
|
HUFFY field threshold question
bas,
Thanks for your reply. Let me make my question more specific because I am still not sure about this. I am making a NTSC TV capture using BTwincap at 712x480. Do I set the HUFFY field threshold to 240 or 480 or leave it at the default of 288? Based on your reply, I should not set the field threshold to 480 because the captured video is interlaced, correct? If this is correct, then the advice on Lord Smurf's website is not correct. North |
Thread Tools | Search this Thread |
Display Modes | |
|
|