View Full Version : >h.264< ?
Joe Fenton
10th September 2003, 20:49
I used VP3 for a while on my Mac. That is, until 3ivX 4.0.4 and DivX 5.0.x arrived for the Mac. Now I don't use VP3 anymore. :)
unmei
11th September 2003, 17:13
[VSS forum, sept. 10]
[mikecyn] VSS Support wrote:
The project have NOT died, it is just on it's way to the public
We can't publish the codec for free due to obvious reasons, there are still some commercial and marketing problems not solved yet...
i guess they will focus on DSP chips and stuff, including video conferencing/cellulars etc but a VfW codec will sure appear someday ..and if it's not VSS, there are more companies into MPEG AVC so once it gets used commerially the interest in free versions will sure increase and i don't think all the ppl working on Xvid will stop coding once xvid 1.0 is all shiny and perfect :D
superdump
11th September 2003, 23:20
I don't think _any_ of the people working on XviD will leave the project when version 1.0 has been released. From talking to a couple of the devs they have plenty of ideas for 1.1 already.
MfA
12th September 2003, 00:26
Working on xvid can be done in bite size chunks ... unless someone like Michael (either one) stands up and makes a useable first attempt at H264 I dont see many developers flocking to it.
If I was a betting man I would put my money on Michael Niedermayer producing the first usefull H264 codec with FFMPEG.
unmei
12th September 2003, 14:53
oh well thanks for the enlightment ;) but i was rather thinking about AVC inside xvid as this point was once discussed, but i don't remeber the outcome of the discussion (or the part of it i could follow on doom9). Was it bashed as impossible or is there still a chance (in 1.1 or anytime later) ?
deXtoRious
14th September 2003, 11:34
So, is there ANY working h264 codec out there? I tried VSS, but it doesn't deliver any better quality than divx.
Tommy Carrot
14th September 2003, 15:38
Originally posted by deXtoRious
So, is there ANY working h264 codec out there? I tried VSS, but it doesn't deliver any better quality than divx.
No there is no usable free h.264 codec. Unfortunately, all project has stopped the development, maybe because h.264 is too complex.
deXtoRious
14th September 2003, 17:15
Damn :(
superdump
14th September 2003, 18:59
VSS performed excellently (the best of all current codecs IMO) on a Futurama (cartoon) episode I tested it on. However, it was very slow. It did decode in realtime on my athlon xp 1600+ but it was using some 65-85% CPU time at a resolution around 576x432 iirc.
deXtoRious
14th September 2003, 20:05
What? It's encoding was as fast as Divx5, but the quality was a bit worse for me. Are we using different versions?
Selur
14th September 2003, 20:09
maybe one of you is speaking of the h264 codec of vsoft and the other is speaking of the vss codec ;)
http://www.vsofts.com/codec/h264_download.html
and
http://www.vsofts.com/codec/codec_download.html
Cu Selur
deXtoRious
14th September 2003, 20:15
I guess so :)
Will try that one now.
superdump
15th September 2003, 00:09
I was talking about the VSS H.264 codec when used in the slowest/best mode possible. It didn't perform so well on normal video content iirc.
Joe Fenton
2nd October 2003, 06:50
I just updated the codec to the latest reference code, 7.3. However, I get the same problem on my system with it as I do with the older version from RareWares - it causes an access violation. I noticed that some people mention they get this as well. Perhaps it's something to do with Windows XP, which is what I run.
In the meantime, perhaps someone daring could try out the codec to see if it even works at all. According to VirtualDubMod's stack trace, it seems to do about 9 frames, then gives an access violation in the EnterCritical function. Very weird.
I'll see if I can't track down the bug, but it could take awhile.
http://www.citlink.net/~jlfenton/hdot264/
Edit: nothing here currently while debugging in progress.
Selur
3rd October 2003, 00:17
when I try to encode with it, it just closes VirtualDubMod without any errormessage. (OS= Win2k pro SP4)
Cu Selur
charact3r
3rd October 2003, 11:17
Originally posted by Joe Fenton
I just updated the codec to the latest reference code, 7.3. However, I get the same problem on my system with it as I do with the older version from RareWares - it causes an access violation. I noticed that some people mention they get this as well. Perhaps it's something to do with Windows XP, which is what I run.Joe,
If you take a look on CVS now you'll see I've updated to JM7.3. I didn't use your source as I actually started this work before I saw your post.
I don't get access violations - perhaps we could try to work out why this is happening.
My next aim is to have a foolproof VfW codec whilst maintaining as few changes from the JM branch as possible. I still want to use the encoder.cfg method of configuration as this gives fullest compatibility and is not too painful.
Things to fix:
* Access violation crash
* Seeking (perhaps we can just re-instantiate the decoder at every keyframe).
I also want to remove all unnecessary xvid files from the tree. At the moment, the entire xvid source is there! It's only being used for VfW wrapper and colorspace conversion. Have there been any recent developments in xvid colorspace conversion that we should incorporate?
Edit: update - I do get an access violation crash now, after several hours of encoding and 557 frames! It happens in the xvid VfW wrapper when DRV_CLOSE is receivedwith a bad handle from the VCM - I can't think of any reason why this would happen - any ideas?
Joe Fenton
3rd October 2003, 23:20
Originally posted by charact3r
Joe,
If you take a look on CVS now you'll see I've updated to JM7.3. I didn't use your source as I actually started this work before I saw your post.
I don't get access violations - perhaps we could try to work out why this is happening.
My next aim is to have a foolproof VfW codec whilst maintaining as few changes from the JM branch as possible. I still want to use the encoder.cfg method of configuration as this gives fullest compatibility and is not too painful.
Things to fix:
* Access violation crash
* Seeking (perhaps we can just re-instantiate the decoder at every keyframe).
That's cool. I'll try it out to see if it acts the same as mine and the older version.
Originally posted by charact3r
I also want to remove all unnecessary xvid files from the tree. At the moment, the entire xvid source is there! It's only being used for VfW wrapper and colorspace conversion. Have there been any recent developments in xvid colorspace conversion that we should incorporate?
Edit: update - I do get an access violation crash now, after several hours of encoding and 557 frames! It happens in the xvid VfW wrapper when DRV_CLOSE is received with a bad handle from the VCM - I can't think of any reason why this would happen - any ideas?
I noticed all the xvid stuff. :) I had to install NASM to get it to compile since it wants all that xvid assembly before it'll put the codec together. I'm not aware of any changes in the colorspace code, but I don't keep that close an eye on changes in that portion of the xvid codec. I know the xvid team wants to have h.264 as the advanced coding profile of xvid, so maybe it would be better to try to work hdot264 into xvid as a selectable mode rather than remove all the xvid stuff. This could then be worked into the xvid cvs. Maybe I'll look into that and also implementing a real config dialog box.
I don't know what would cause that right off the bat. I'll look into it a little as I imagine you are. Maybe someone here who has run into it will give us the benefit of their experience.
Joe Fenton
3rd October 2003, 23:56
Originally posted by charact3r
Joe,
If you take a look on CVS now you'll see I've updated to JM7.3. I didn't use your source as I actually started this work before I saw your post.
Uh - I just got the latest CVS and this is straight from the lencod.c file:
#define JM "5"
#define VERSION "5.0g"
I deleted my hdot264 folder and refetched the hdot264 module, then checked it against the web browser version of the CVS. You still don't have the 7.3 version up unless it's moved to another repository.
Edit: Okay, it finally showed in the repository. Weird how long it took to update.
Joe Fenton
4th October 2003, 09:43
I compiled your latest code. Did you know the hdot264enc.dsp is missing all the file refs? I used mine and it compiled okay.
However, your code acts differently. It gives a divide by zero error in h264enc while passing the start message to video compressor VideoSequenceCompressor.cpp 267.
Wilbert
5th October 2003, 00:46
Sorry for asking a stupid question. Do you need to convert the avi to yuv first, before encoding with h264?
I compiled avi2yuv, which can be found here:
http://www.ifp.uiuc.edu/~lqian/Research/Software/body_software.html
But if I type "avi2yuv raw.avi" in a dos-prompt it says:
Usage: avi2yuv avi_file template first count
What additional switches do I need?
charact3r
5th October 2003, 20:12
hdot264 contains source code for a basic VfW codec. That means that you can just select compression as "hdot264" in vdub and save as an AVI file that is encoded usign H.264.
No need to manually convert to YUV.
Wilbert
5th October 2003, 20:47
Ok, thanks. Does that imply that the following line in encoder.cfg is ignored:
InputFile = "foreman_part_qcif.yuv" # Input sequence, YUV 4:2:0
Or do you have to put the name of the avi file you want to encode? Do you also have to change this line:
InputHeaderLength = 0
charact3r
5th October 2003, 21:04
These fields are ignored. I confess to not fully understanding the meanings of all the fields in encoder.cfg, so some settings might not work.
Btw, if anyone has something they want or need to commit to hdot264 CVS, just tell your sourceforge ID and I'll set it up for you.
deXtoRious
8th October 2003, 20:37
@all
Well, has anybody compiled a working version?
Could anyone host the binaries?
Joe Fenton
9th October 2003, 06:17
It doesn't work on my XP SP1 system. I get a different error from my code than from the official hdot264, but they both still fail. You can get both my binary and my compile of the cvs here:
http://www.citlink.net/~jlfenton/hdot264/
hdot264-73alt.zip is my conversion of hdot264 to 7.3 before I learned that charact3r had updated it himself. I'm not going to be an official host, I'm just making some compiles available while testing.
By the way, I have gotten an error with all versions of the code, even the older versions some people had working for them.
Wilbert
9th October 2003, 11:10
I got two binaries. One from Rarewarez, and I forgot where I got the other. In both cases vdub crashes when I start the encoding (no error message, it just hangs). My system: W2k SP4.
Latexxx
9th October 2003, 20:57
Originally posted by Wilbert
I got two binaries. One from Rarewarez, and I forgot where I got the other. In both cases vdub crashes when I start the encoding (no error message, it just hangs). My system: W2k SP4.
Afterall it's Rarewares not Rarewarez. ;) :D
Joe Fenton
9th October 2003, 21:43
Interesting... anyone with a WNT variety (NT/2K/XP) actually get it to work? My XP system doesn't and the previous dude's 2K system doesn't either. Maybe it's just 9x systems that work with it.
It'd be nice to narrow this down a bit.
MetaHiro
11th October 2003, 01:17
If you read the encoder.cfg you'll see where to edit it to give it an input file. (some weird .yuv format it seems) I still have yet to find anything that makes a .yuv container file :P
karl_lillevold
11th October 2003, 01:28
it's not really a weird YUV format, it's just raw I420, i.e. YV12 with the U and V planes swapped. This is the most common video format for the standardization reference codecs.
"raw" = no container, just the Y plane, then the U plane, then the V plane, one frame after another. You could get to such a file format, but using the Helix YUV Codecs (http://forum.doom9.org/showthread.php?s=&threadid=56972), to "compress" any AVI file to I420 in VirtualDub, then a simple tool to extract the raw video data from the AVI file. For instance avi2raw.exe (http://www.lillevold.com/files/avi2raw.zip).
justin
11th October 2003, 02:29
Originally posted by Joe Fenton
I know the xvid team wants to have h.264 as the advanced coding profile of xvid, so maybe it would be better to try to work hdot264 into xvid as a selectable mode rather than remove all the xvid stuff. This could then be worked into the xvid cvs. Maybe I'll look into that and also implementing a real config dialog box.
I don't know what would cause that right off the bat. I'll look into it a little as I imagine you are. Maybe someone here who has run into it will give us the benefit of their experience.Xvid Xvid! (points to Xvid) :) They need H264 in their code.... Then we only need one codec for MPEG4, Xvid!
Joe Fenton
11th October 2003, 04:13
Originally posted by MetaHiro
If you read the encoder.cfg you'll see where to edit it to give it an input file. (some weird .yuv format it seems) I still have yet to find anything that makes a .yuv container file :P
That's unused by the codec. It takes the yuv frames from the api a frame at a time. Some of the fields have no use under the codec as data is passed in a different manner. They are left over from the original h.264 code that was patched into the xvid codec.
You should just select hdot264 in VDub's compression config like you would xvid or divx. The frames will be passed and processed into what the codec wants automatically.
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.