>h.264< ?

[Shootist]

Hi,
yesterday I read a newsline called "h.264" in a magazine. I`ve wondered me because they said, it makes mpeg1+mpeg2 files only a half/quarter of the size it would produce today. But only the hardware today is to slow. Anybody heard something else about? Or can somebody correct me if I`m wrong.

[Update]

For all who want to test the interesting new codec and maybe the future of MPEG goto Rarewares http://www.inf.ufpr.br/~rja00/ under the mpeg section

The source can be found at hdot264 page (http://hdot264.sourceforge.net/)

The project is still in very early development. So all who don`t want to test the codec may waste time because even with the fastest settings it still takes some minutes to encode a single frame. Also decoding is very buggy. But the result is amazing. All people should hope that this project gets continued because the potential is huge.


good settings for the encoder.cfg: (from Tommy Carrot, Selur)

-reference frames=1
-searchrange=8 (instead of 16)
-RDOptimization=0
-AdaptiveBlockTransforms = 0 (may result in crash, I have to set it to 2)
-NumberBFrames = 0 (disable)

decoder.cfg:
-move the file to C:\ or maybe the codec won`t find it
-set: 0 ........NAL mode
If your are still not able to decode the avi, use yuv2avi (http://forum.doom9.org/attachment.php?s=&postid=174083) to convert the yuv file to avi.


Use a low res to speed up the encoding!

@developers Please continue the good work! It`s worth doing so!

[CruNcher]

use search button above
it's an alltime discussion here ;)

[IBJr]

Originally posted by CruNcher
use search button above
it's an alltime discussion here ;)

Was that sarcasm? All I could find were threads w/ at most 20 replies.

[Tommy Carrot]

If you searching for "H.26L", you will find more matches. It's the old/development name of H.264.

[rjamorim]

http://hdot264.sourceforge.net/

[Tommy Carrot]

Originally posted by rjamorim
http://hdot264.sourceforge.net/

I'm afraid that project is dead. :(

No changes since months.

[rjamorim]

Yes, but at least the author seems to be alive.

http://www.everwicked.com/forums/showthread.php?s=&threadid=1540

[Shootist]

ok, I tried to download the source and compile it, but I`m not so familar with sourceforge`s system. is there a tool to download the source easily? (I tried WINCVS, but I had many problems with this tool)

would be cool if someone answers...

[CruNcher]

@IBJr
sorry i forgot to mention the old name H26L

@Shootist
http://bs.hhi.de/~suehring/tml/download/Unofficial/
there you can find the newest unofficial Reference Code by one of the
VCEG Memberst he is the Software Maintainer and as you can see long time no update has been done on the Reference Code it looks like their almost finish and the new Spec is going to be released soon only speculations but the evidence speaks for itsself :)
Mpeg-4 V10 AVC lays in Santas christmas bag ;)

[Shootist]

thanks a lot

[Tommy Carrot]

Be warned: The reference software is VERY slow. It ain't good for anything else than short (~100 frames long) tests.

But after the h.264 is standardized, i guess we shall see several project based upon it. Maybe Xvid2 too? :D

[Koepi]

h.264 is going to be adopted to the mpeg4 standard as "Advanced Video Coding" AVC profile.

So no need for xvid to split up - or did we call it xvid1 vs xvid0 when we started implementing Advance Simple Profile (vs. Simple Profile)?

We'll modify the GUI so you can choose the profile you want to use for encoding which enables/disables xvid's vfw controls accordingly. But let's wait for the integration/presentation of h.264 into mpeg4 first - and let's make ASP stable.

Regards
Koepi

[Tommy Carrot]

Originally posted by Koepi
h.264 is going to be adopted to the mpeg4 standard as "Advanced Video Coding" AVC profile.

So no need for xvid to split up - or did we call it xvid1 vs xvid0 when we started implementing Advance Simple Profile (vs. Simple Profile)?

We'll modify the GUI so you can choose the profile you want to use for encoding which enables/disables xvid's vfw controls accordingly. But let's wait for the integration/presentation of h.264 into mpeg4 first - and let's make ASP stable.

Regards
Koepi

Yes, but Advanced Simple Profile is just an extension to the Simple Profile. H.264 (or AVC) is an entirely different technology, it works completely differently (iirc not DCT based, multiple macroblock sizes, etc.). There would be only a few shared code-parts, so the source would be a complete mess.

But your version sounds better, i would be glad if that is possible without difficulties. :)

[-h]

The AVC profile will be a radical departure from the other profiles. I would rather see a fork into a new project (or even start from scratch with the reference source and optimize from there).

It's just that almost all the core components - the transform, quantization method, motion compensation, block sizes, frame referencing, vlc codes, block storage syntax, etc. - are different compared to the existing MPEG-4 profiles. It could be implemented inside XviD, but there'd be such small amounts of shared code it would cause a lot of headaches - about the only functions you could share between AVC and the rest would be sad16/sad8 and colorspace conversions!

Not that I wouldn't like to see it done :) I know Isibaar has been keeping an eye on the development of the standard. I haven't looked too closely at it actually, so it might have more shared parts than I'm thinking.

-h

[karl_lillevold]

You are right. There is almost nothing in common between H.264 and the old MPEG-4. Sharing a common code base does not make a lot of sense, IMHO.

[vinouz]

BTW, -h, do you and Isibaar & other xvid developpers plan to work on H264 now ?
I've been some far away from xvid project, because, at the point it was when I looked at it, I didn't feel very useful and it needed quite work in order to be fully inside the core project.
But, then, to starting a new fork, I'd greatly appreciate join your team.
I've democoded some quite long some years ago, and did a software to treat signal on my F030's DSP, so I think my skill can still be of some use here, when talking about optimisations and signal processing.
But dou you guys have new about the Hdot264 project ? Maybe it's the fork that's to join. I'm waiting the finalization of the standard, though...

Vincent

[vinouz]

BTW, I wish you all a merry X-Mas and happy new year, at least a happy christmas, as I won't be available until then.

Vincent

[-h]

There's not really any formal way to join or contribute to XviD - write some code, post it to the devel mailing list, and if it works (well) it'll probably get committed in some form. Point optimizations (such as only rewriting or creating assembly for a single function, like an RGB->YV12 conversion) are the most common and easiest bits of code to create.

I don't know of any concrete plans to work on a H.264 codec, but if it's done I know that any coding experience is welcome.

-h

[gino25]

Hdot 264 has an activity of 23%. Do this project continue his development?

[rjamorim]

Just FYI, I uploaded a build of hdot264 (http://hdot264.sourceforge.net/) to RareWares. Link is at the bottom of post.

File compiled with Intel Compiler 7.0.

Regards;

Roberto.

[Selur]

hmm,.. installed hdot264.inf, but when I want to configure it it want's to create an encoder.cfg . Which starts as empty 'txt' file,.. so could you or someone else please post some info's on how to configure the codec?

Should it be done like mentioned in this post http://sourceforge.net/forum/forum.php?thread_id=745296&forum_id=212109 about the decoder.cfg ? (I know decoder != encoder)

May be a little ReadMe distributed with the codec might be wise. :)

Thx

Cu Selur

/edit
Even if u don't configure the codec, there's a problem, it asks for an h264enc.dll, but the only dll in the zip is named hdot264.dll,...
edit/

[Mango Madness]

whoa, a binary of h.264! Even though i haven't a clue how to get the config file working or whatever it's excellent to see a compiled version. Thanks for the work and maybe some people smarter than I will shed light onto how to get it working.

[rjamorim]

Originally posted by Selur
hmm,.. installed hdot264.inf, but when I want to configure it it want's to create an encoder.cfg . Which starts as empty 'txt' file,.. so could you or someone else please post some info's on how to configure the codec?

Should it be done like mentioned in this post http://sourceforge.net/forum/forum.php?thread_id=745296&forum_id=212109 about the decoder.cfg ? (I know decoder != encoder)

May be a little ReadMe distributed with the codec might be wise. :)

Found the sample files and a readme. Will upload with the missing DLLs.

/edit
Even if u don't configure the codec, there's a problem, it asks for an h264enc.dll, but the only dll in the zip is named hdot264.dll,...
edit/

Me is dumb. I'll upload the needed DLLs ASAP.

whoa, a binary of h.264! Even though i haven't a clue how to get the config file working or whatever it's excellent to see a compiled version. Thanks for the work and maybe some people smarter than I will shed light onto how to get it working.

right click on the .inf file -> install.

I'll see if I can provide a NSIS installer soon.

Regards;

R.

[Selur]

"Found the sample files and a readme. Will upload with the missing DLLs.
Me is dumb. I'll upload the needed DLLs ASAP."
Cool, looking forward to it,.. btw. what's the xvid.inf for that's in the zip file ;) ?

Cu Selur

[rjamorim]

Uploaded. The zip file now contains hdot264.dll, h264enc.dll, installation .inf script, readme and sample config files.

No NSIS yet. Should be done this afternoon. (After I update MPEG4ip)

what's the xvid.inf for that's in the zip file?

Dunno! But it was there in the CVS, so I added that too.

Anyway I removed it in this new package, because I think it's indeed useless. If somebody misses it, please report.

Regards;

Roberto.

[Selur]

thx, for upping the files,..

/edit:
for those who are testing,.. atleast if u use avs2avi you neeg do copy the h264.dll in the same dir als av2avi.exe .
Copying it into the system32 folder might also work

If someone finds some nice settings plz post them
Thx
edit/

Cu Selur

[sillKotscha]

Originally posted by Selur
Copying it into the system32 folder might also work

moin Selur,

right click on the .inf file to install hdot264 already copys the dll into the system32 folder ;)

cheers Sill

[Selur]

oh,.. didn't notice that, okay than that's not an alternative ;)

Cu Selur

[rjamorim]

Uploded the package in a NSIS installer.

Seems to be working fine here. But please report any issues you might experience.

Regards;

Roberto.

[Mango Madness]

any special encoding programs needed? Cause neither vidomi nor virtualdub can handle it. I used the default config file but it seems the codec goes into thread deadlock (at least with virtualdub).

[Selur]

ehmm,... you have to configure the encoder.cfg, open it and you will see why,... (as far as I saw the standard encoderer.cfg only encodes 2frames ;) )

Cu Selur

[Mango Madness]

i can't even get it to encode 1 frame ;) but i did notice that option

[Ramirez]

Well,it's works for me, I'm using Vdub, and Default Encoder.cfg
The only problem is >Speed, on my machine it takes something like 5 min to encode a single frame. (XP1800)

[Selur]

and that at a resolution of 176*144 ;)

Cu Selur

[Ramirez]

I don’t quite understand this post above, was that an irony?

[rjamorim]

Originally posted by Ramirez
I don’t quite understand this post above, was that an irony?

I don't think so. Fact is, h.264 is as slow as you will get. ;)

Wait some years until you can even dream of real time encoding.

[Selur]

hups my mistake (mixed Source and Input), but don't expect too much, here some values from the standard encoder.cfg:

SourceWidth = 176
SourceHeight = 144
(though a lot of detail should be lost)

IntraPeriod = 0 # Period of I-Frames (0=only first)
QPFirstFrame = 31 # Quant. param for first frame (intra) (0-51)
QPRemainingFrame = 30 # Quant. param for remaining frames (0-51)
FrameSkip = 1 # Number of frames to be skipped in input (e.g 2 will code every third frame)
MVResolution = 0 # Motion Vector Resolution: 0: 1/4-pel, 1: 1/8-pel
UseHadamard = 1 # Hadamard transform (0=not used, 1=used)
SearchRange = 16 # Max search range
NumberReferenceFrames = 5 # Number of previous frames used for inter motion search (1-5)

Quant 30+ also doesn't soudn too good.

Cu Selur

[Tommy Carrot]

http://forum.doom9.org/showthread.php?s=&threadid=32577
is the old topic of this stuff. You can find some settings there, i was able to reach the awesome 1/3 frame/sec at 640*384. :D I just hope the VFW codec is not even slower. :)

[Mango Madness]

1 frame per 15 minutes on a duron 1.33 (133/133) w/256meg of PC133. At least i've gotten past the first frame. cheers.

[Selur]

Tommy Carrot posted on the other thread:
I've discovered the fastest mode:
-reference frames=1
-adaptive block transform=0
-searchrange=8 (instead of 16)
-RDOptimization=0

Are these the changes you did?

Cu Selur

/edit
Was anyone able to decode a file? I just tried to which caused my system to reboot,.. *gig*
edit/

[Ramirez]

I'm experiencing similar problem here, when I try
To decode an h.264 Avi file, my system simply shuts down.:eek:
I'll tray to encode a few frames later, using Tommy Carrot's Fast Settings.

[SirDavidGuy]

Looked at the source (again).

Still no ME (other than FS), making it incredibly slow. Add that to multiple reference frames and 4th/8th/16th pel algorithms used, and it's bound to go incredibly slow.

[Bulletproof]

How is the codec supposed to act when you try to use it? I think I set the config file properly, but when I try to encode a file in virtualdub it never shows the encoding panel, it just freezes the program.. unless its taking a really really really long time for the first frame, im on a 1.9ghz (actual speed) cpu.

[Mango Madness]

yeah, the FPS on my 1.33ghz duron is about .0111 or rather 15 minutes PER FRAME.

[HarryM]

I get 5 frames per minute(!) - full movie about 49 days encoding non-stop.
It's fantastic... :D
The first time I think, that PC frozen or Vdubmod crashed.

[charact3r]

I am the developer of hdot264 and would love to find out how it performs. Unfortunately I only have a 733MHz machine so encoding's particularly slow. Eventually the code will be faster (and probably completely rewritten to achieve this) but this will only happen if people find that the codec performs better than, say DivX 5 Pro or xvid.

So try encoding at a lower resolution (like 320 x 200) and try DivX 5 at the same resolution and bitrate. Suggest encoding with hdot264 first as I don't know how to get an accurate bitrate/filesize with it yet. You can then set divx 5 to have same bitrate.

For decoding, if your computer can't decode using hdot264 in real time, use vdub to convert h264 to huffyuv so that you can watch in real time and compare to DivX.

If hdot264 really is much better than DivX or xvid then I'll work on making it faster. And btw, developers very welcome :)

[Selur]

At least for me VirtualDub crashes when I try to scroll in the file I created,...
Woudl also be nice if you could give us some hints how to configure encoder and decoder cfg,...

Cu Selur

Ps.: What colorspaces does the codec support as input? (could be a reason for my file to be broken)

[charact3r]

Originally posted by Selur
At least for me VirtualDub crashes when I try to scroll in the file I created,...
The best thing to do is to dub again from h264 to an uncompressed format for ease of playback. The codec does not support seeking.
Woudl also be nice if you could give us some hints how to configure encoder and decoder cfg,...,...
These are the same files as used by the JVT software. I don't really know how to use them. Perhaps someone else can enlighten us?
Ps.: What colorspaces does the codec support as input? (could be a reason for my file to be broken)
Same as xvid (xvid code used under GPL for VfW codec).

[Selur]

Thx for the info,..

Another question:

Are the quantizer settings kind of equivalent to the one used in Xvid and go,.. ? (though the default settings of 30&31 are not the best settings for quality comparison?)

Cu Selur

/edit
Virtual Dub conversion (off the hdot264 file to huffyuv)just crashed with because of a division by Zero,.. I'll encode another file later and do some testing with it,.. (hopefully)
edit/

[charact3r]

Look at the following link for reference code (hdot264 uses jm40-ish) and for specification of h.264. I'm not sure how up-to-date the docs here are, if you find a more recent version, please put a link here.

http://bs.hhi.de/~wiegand/JVT.html

So you can read how h.264 quantisation works in the documentation. I think it's a bit more complicated than MPEG-4 quant.

edit: best thing to do is to try hdot264 with the default settings and see what bitrate it comes up with. Then try to match this bitrate with constant q divx/xvid and compare quality.

[Selur]

okay,.. will read it later,..
thx for the info

Cu Selur

edit:
" best thing to do is to try hdot264 with the default settings and see what bitrate it comes up with. Then try to match this bitrate with constant q divx/xvid and compare quality." Okay,.. I'll try that.

[gino25]

I' ve compiled a old version but the results are very impressive. Thnks to all

@charact3r
Why don' t you use a jm 50?

[Selur]

just converted a small clip (used default encoder.cfg) and copied the decoder.cfg to C:\ otherwise Virtual Dub didn't want to open the file, but whenever I now try to convert thw h264 file to HuffYUV, Xvid,.. VirtualDub crashs because of a division by zero,... :(

Cu Selur

[charact3r]

Originally posted by gino25
I' ve compiled a old version but the results are very impressive. Thnks to all

@charact3r
Why don' t you use a jm 50?
I decided not to try to keep up with the jm versions because that alone would take all my time. Also don't really want to invest too much time in hdot264 until I'm happy that it will be better than DivX and xvid.

How impressive were the results???

[vinetu]

just converted a small clip (used default encoder.cfg) and copied the decoder.cfg to C:\ otherwise Virtual Dub didn't want to open the file, but whenever I now try to convert thw h264 file to HuffYUV, Xvid,.. VirtualDub crashs because of a division by zero,...

Same here ...:(

I'm unable to see my 200 frames "rip"...
(speed -P4 @ 2.4GHz - 128x128 avi,200 frames for 4min)

[Tommy Carrot]

Originally posted by charact3r
I decided not to try to keep up with the jm versions because that alone would take all my time. Also don't really want to invest too much time in hdot264 until I'm happy that it will be better than DivX and xvid.

How impressive were the results???

You can find some opinions about h.264 on the above mentioned thread. As you can see, i was rather impressed with the quality. At mid/low/very low bitrates it is _much_ better than xvid/divx. I'm not sure about high bitrates, i've not tested the encoder under quant 20, but i guess it can stand there too. Anyway, definetaly better than the current codecs, just horribly slow, and i cannot decode it other way than converting the yuv file to avi.

BTW, with the most brutal settings, the encoding is still ~40 sec/frame:D at 720X384 on my athlonXP 1700. Something is wrong, if you get 5 min/frame. With some tweaking in the config, the encoding can easily reach the 0.3 frame/sec at that resolution.

[Tommy Carrot]

Originally posted by vinetu
Same here ...:(

I'm unable to see my 200 frames "rip"...
(speed -P4 @ 2.4GHz - 128x128 avi,200 frames for 4min)

Try to search something like yuv2avi (e.g.: in the old topic). With that, you can convert the yuv file in the target directory to uncompressed avi.

[Selur]

Thx for the tip, I'll try, here a link to the thread for others who might search:
http://forum.doom9.org/attachment.php?s=&postid=174083

/edit
yuvtoavi did the job for me => tomorrow I'll encode some test smaples with different encoder settings ;)
edit/

Cu Selur

[Alex_e_Basta]

Hi all

I compiled the CVS version from SF.net and I made some tests : Divx vs H264 and Xvid vs H264.
I encoded 20 frames from PH using Avisynth 2.5 & VDub 1.4.13.1,Quality based 100% and no B frames; my script

LoadPlugin("c:\vdub_yv12\MPEG2Dec3.dll")
mpeg2source("C:\Avisynth\Prove\PH.d2v")
trim(0,19)
crop(0,72,720,432)
BicubicResize(720,304,0,0.75)

Then I switched back to Avisynth 2.07 and I compared dimensions and psnr of all encoded clips.

Codec _________ KB ____ Psnr __ Delta KB %___ Delta PSNR (DB)

Divx Qb100% ___ 694 ___ 39.81___0.00_________ 0.00
Xvid Qb100% ___ 674 ___ 39.64__ -2.88________ -0.17
Xvid Quant=1 _ 1410 ___ 40.64__ 103.17________ 0.83
H264 10-19 ____ 538 ___ 39.87_ -22.48_________ 0.06
H264 08-17 ____ 680 ___ 40.23__ -2.02_________ 0.42

As you can see, at nearly the same psnr(H264 quant 10-19), H264 gains 22.28% in KB vs Divx and at the same dimension as Divx (H264 quant 8-17) it gains 0.42 DB of psnr.
I think that these results are very impressive either in quality or in compression and I hope the good work will continue.

Bye
Alex

[DVD__GR]

Really impressive..is it possible for the author to make it some more user friendly for us to test it??
I'm sure that many would like to test,its really usefull to get the answer if its worth it or not?:confused: :confused:

[Mango Madness]

yeah dude! extremely impressive. I hope you continue to work on the code's speed and usability for more non-technical users. Hope more developers jump on the bandwagon. This project has my full support. Cheers.

[midiguy]

oyy!!!

it takes me 15 to 20 minutes to encode one frame @ 640 x 480 in my P3 600 mhz, 128 MB PC100 SD RAM sys.:rolleyes:

[Selur]

Hmm,.. I get a pretty big .yuv outputfile (it's the output file not the avi created with virtualDub, right? ).

@Alex_e_Basta: could you plz post you encoder.cfg :) and if you changed anything in you decoder.cfg, would be cool if you could post that file too :)

Cu Selur

[vinetu]

...so at this time we cannot play-decode the "OUT_from_VDub.avi" file,but "test_rec.yuv" file only ?:(

[charact3r]

No, you should be able to play the AVI too. But the decoder is slow, and seeking may well not work (or even crash).

[Alex_e_Basta]

Hi

These are the modifications I made to Encoder.cfg

ReconFile = *none*
QPFirstFrame = 10 # Quant. param for first frame (intra) (0-51)
QPRemainingFrame = 20 # Quant. param for remaining frames (0-51)
FrameSkip = 0 # Number of frames to be skipped in input
NumberBFrames = 0 # Number of B frames inserted (0=not used)

and these to Decoder.cfg

*none* ........Output file, YUV 4:2:0 format
0 ........NAL mode (0=Telenor bitstream, 1: DPs, RTP packets, 2: Interim File)

As charact3r says, VDub correctly plays .avi generated with 4cc code H264 and no crash at all seeking the file (very slow indeed).

Ciao
Alex

[Mango Madness]

what about 2 pass?

[sam_b]

Just got round to trying this out, and I'm really quite impressed with it. Definitely worth continuing, provided speed can be significantly increased. What speed increase are you predicting with optimisation?

[-h]

Motion estimation is currently a full search. Algorithms such as PMVFAST or EPZS can run around 100 to 200 times faster with search ranges of [-16,15], and faster still for larger ranges. Since a big chunk of this implementation's time is spent in motion estimation it will probably speed it up by a good margin (maybe 8000% or more, who knows).

-h

[sam_b]

Then it definitely worth continuing. Is a full search what I think it is??!!

I'm just pleased to have a new hdot264, rududu's codec and a new ffvfw codec to play with in the space of two days. There are good things to come I think.

[Ramirez]

Originally posted by Tommy Carrot

BTW, with the most brutal settings, the encoding is still ~40 sec/frame:D at 720X384 on my athlonXP 1700. Something is wrong, if you get 5 min/frame. With some tweaking in the config, the encoding can easily reach the 0.3 frame/sec at that resolution.
Very strange, I'd really like to see your encoder/decoder cfg files, could you please post it here?

thanks

[Alex_e_Basta]

Sorry guys

I was wrong; it seems that the statement
ReconFile = "test_enc.yuv"
is mandatory in encoder.cfg, otherwise VDub ends with a crash. The output file is OK, but I think a crash isn't a good end for a program, don't you? ;)

Bye
Alex

[Bulletproof]

Maybe SMP support could really speed up the encoding process by balencing the search algorithim between cpus?

It seems VideoLocus already has a H.264 codec out, here's an excerpt from an article describing it:

"At IBC VideoLocus demonstrated the efficiency of its own optimized H.264 codec, called MPX, through a DVD quality video stream at 944 kilobit per second in a side-by-side comparison with an MPEG-2 video stream at 5.37-Mbits per second. "

That sounds pretty impressive, however it's just hype right now until mainstream people see it. We all know Microsoft tried to say that their WM9 codec was DVD quality at some ridiculous bitrate too.

"H.264 comes with a range of newly-developed encoding tools that were previously unavailable in either MPEG-2 or MPEG-4. They include a flexible breakdown of macro blocks, an ability to isolate motions more precisely, in-loop de-blocking filter and intra estimation modes, explained Oerton."

Sounds like XviD ;) .

"VideoLocus' H.264-compliant encoder algorithms run on a Pentium 4 platform with hardware acceleration coming from an add-in FPGA card. "By reducing the technology to hardware implementation, we believe that the credibility of H.264 has been elevated one notch," claimed Kevin Oerton, vice president, marketing and business development at VideoLocus."

[vinouz]

with hardware acceleration coming from an add-in FPGA card

Which means it certainly was incredibly slow anyways. FPGA get much more power as properly designed thei're specialized to this task.

Remember the C-Cube circuits (not FPGA, special circuits) to decode MPEG-1 video in the days machines couldn't affort it...

just my 2€cent
Vincent

[Selur]

just tested some small (about 100frame clips) and I have to say: WOW, this really looks good!

So plz, continue this and once this will get faster, especially decoding (I know it bugs to wait 48hrs for an encode, but not being able to watch it bugs even more, in my point of view), though faster encoding would also be nice.

Cu Selur

[charact3r]

I would welcome a discussion on how to take hdot264 forward. It seems clear now that it is worth more development, as the original developer, I don't have time to do everything.

For performance, the codec basically requires rearchitecting and probably building from scatch from the spec. This will take many months to do and the simpler tools would be done first (would take some time to get video quality up). It's proabaly best to start with the decoder.

I would like to keep the GPL/LGPL/MPL multiple license as MPL would encourage companies overtly to help development (main issue is patent clauses of GPL). GPL-only development does not prevent companies exploiting the code for free, especially with video work where algorithms and techniques are the important thing and they can't be protected by copyright. So it's best to allow as many people as possible to use the code.

Perhaps H.264 functionality could be integrated into xvid and/or ffmpeg? The multiple license would allow this.

Thoughts on the future of hdot264 are very welcome.

[sam_b]

Would you be able to use GPL code in a project with this license? If not, then I suspect large re-writes will be needed which could otherwise be taken from XviD/libavcodec etc... Oh, except libavcodec is LGPL I think. Could you reuse the motion estimation code, vfw frontend etc...?

Sorry, I'm not a coder as you can probably tell.

[charact3r]

Originally posted by sam_b
Would you be able to use GPL code in a project with this license?
Yes and no. I use GPL xvid code right now for the VFW wrapper (including colorspace conversions). But the core is 95% JVT reference software and 5% my own work (this is the part that is released under GPL+LGPL+MPL).

You are right about reusing parts of xvid. But x86 optimised ME/MC are probably the only parts that could be reused. So perhaps if these parts are incorporated into hdot264 they need to be clearly labelled as GPL only.

I don't think GPL is suited for a development whose value is in ideas and techniques rather than in the actual lines of code. GPL is not acceptable to companies because it's too restrictive on patent licensing. GPL effectively prevents companies using the code verbatim and so, instead of helping out and sharing the codebase, they just take the best ideas and write their own code (very quick and quite legal under GPL).

[Shootist]

made a little summary at the beginning of the thread...

any suggestions?

[sam_b]

Would this codec not need to be an educational implementation (a la xvid) to avoid patent infringement? Does this specify GPL?

Oh, could you throw some code milan's way and see if he could implement the decoder into ffdshow? It seems like it could be the easiest solution the decoding issue.

[ChristianHJW]

Sorry, i dont understand the speed values you guys were giving here. A 400 x 304 res AVI, encoded with good old MPEG4V2 ( its an old CAM capture from my son that i have always on my laptop HDD with me ) encodes at roughly about 2 frames / minute with my old PIII 650 Mobile ( Laptop ), 128 MB RAM PC 100 ?

How is it possible it takes you 15 minutes to encode a single frame ?

Note i have not made any changes to encoder.cfg file ... is it necessary to make any here ?


EDIT : any chance to get SMP or multithread support in the code somehow ? People like MaTTer and Acaila could maybe finish some longer movies in reasonable time, and my SMP PIII @home would finally get some work again :D .. possible ?

[ChristianHJW]

Originally posted by Selur and copied the decoder.cfg to C:\ otherwise Virtual Dub didn't want to open the file

Thanls Selur, i was about to invest time finding where to configure this when i found your post .. it seems it has to be there for the time being ;) ...

[Selur]

About speed:
On my Dual Athlon Mp 1800+ it takes me something like 1/2 a minute to encode one frame (so small tests are no problem), but some optimisations would really be nice. :)
The main thing that's bugging me is not encoding but decoding,.. (posted that earlier)

"Note i have not made any changes to encoder.cfg file ... is it necessary to make any here ?"
Hmm,..
I would say: Yes
Last time I tried decoding didn't work 'right' (green flashes and broken frames) with bframes enabled, so disabling b-frames is necesarryin my eyes ;)
(I'll do another littlte test to recheck this in about an hour)

Alex_e_Basta also posted some other modifications that might also help.

Cu Selur

Ps.: I also allways change SourceWidth and SourceHeight to the dimensions of my input. (I attached my encoder and decoder.cfg which I used on my last test)

[Shootist]

sorry but I couldn`t find an attachment...

would be cool to see setting to produce a frame in 1/2 minute because my pc is a little bit lower equipped...

[rjamorim]

Originally posted by Shootist
sorry but I couldn`t find an attachment...

I've added Selur's encode and decode configs to the installation package at RareWares. (Thanks!)

Regards;

Roberto.

[Selur]

Attachments have to be authorized by the mod of the section,..

"because my pc is a little bit lower equipped."
don't think that my settings will help,.. since my pc is pretty fast,..
but for speed inprovements you could:
lower SearchRange (maybe to 8)
lower NumberReferenceFrames (maybe to 3 or 4)
disable UseHadamard (havent tried, but what I read in the JVT draft it sounds like disabling it should speed things up, but lower quality)

Cu Selur
/edit:
Ps.: rechecked if B-Frames have to be disabled,.. seems like earlier it was a bug on my side, b-frame encodeing seems to work fine, but looks too smoothed to me with the standard quantizer setting of 29
edit/

[Tommy Carrot]

This was put on this forum a few times, but here is it again to those who couldn't read back.

So some tricks to speed up the things:

- reference frames=1 //large speed gain, little quality loss
- RDoptimization=0
- Adaptive block transform=0
- frameSkip/bframes=0

You can lower the searchrange too, but i don't think it's worth the quality loss.

And don't touch Hadamard transformation!

Note: every settings will add to the bitrate (the sum of them is about 30-40%), but the encoding is cca. 15-20 times faster. Still very slow though, about 0.3 f/s on my xp1700.

[Selur]

Thanks for the tricks,...

Cu Selur

[Alex_e_Basta]

I tried the Tommy Carrot's tricks, here some results (20 frames of PH)

orig. encoder.cfg : encoding time:____ 18m10sec dim:_ 478KB PSNR: 39.67

Ref .frames=2 ____________________ 10m12sec _____480 ________39.66
+ searchrange=8

Ref .frames=1 ____________________ 08m59sec _____484 ________39.65
+ searchrange=8

Ref .frames=1 ____________________ 02m32sec _____466 ________39.22
+ searchrange=8
+RDoptimization=0

Ref .frames=1 ____________________ 01m32sec _____490 (all frames green)
+ searchrange=8
+RDoptimization=0
+Adaptive block transform=0

The speed's gain with Adapt.block = 0 is remarkable but when I try to open the output file with VDub, all frames are green : any clue ?
RDoptimization = 0 speeds up the encoding process with an acceptable quality loss of 0.33DB.

[Shootist]

Originally posted by Tommy Carrot
This was put on this forum a few times, but here is it again to those who couldn't read back.

So some tricks to speed up the things:

- reference frames=1 //large speed gain, little quality loss
- RDoptimization=0
- Adaptive block transform=0
- frameSkip/bframes=0

You can lower the searchrange too, but i don't think it's worth the quality loss.

And don't touch Hadamard transformation!

Note: every settings will add to the bitrate (the sum of them is about 30-40%), but the encoding is cca. 15-20 times faster. Still very slow though, about 0.3 f/s on my xp1700.

Originally posted by rjamorim
I've added Selur's encode and decode configs to the installation package at RareWares. (Thanks!)

Regards;

Roberto.

Thx for posting. I only wanted to see the modification Selur made to his files.

[Shootist]

Had anyone bugs with the new nsis-installer from rarewares? I always got the error message "Video Compression Error: An unknown error occured (may be currupt data). (error code -100)".

I tried it with normal avis and avs-scripts like that:
# PLUGINS
LoadPlugin("D:\Programme\DVD-Utilities\Avisynth\avisynth2.5x_dlls\MPEG2Dec3.dll")
LoadPlugin("D:\Programme\DVD-Utilities\Avisynth\avisynth2.5x_dlls\Convolution3DYV12.dll")
#
# SOURCE
Video=Mpeg2Source("D:\Save\Der Herr der Ringe - Die Gefährten - Special Extended DVD\DVD1\vts_01.d2v")
#
# CROPPING
Video=Crop(Video,5,77,712,423)
#
# RESIZING
Video=lanczosresize(Video,640,256)
#
#Convolution 3d
#Video=Convolution3D(Video, 0, 3, 4, 3, 4, 2.8, 0)
#
# FINISH
return Video

I also changed SourceWidth = 640 and SourceHeight = 256 and used the cfg`s from Selur. tried it also disabling crop and resize but always an error. I use avs2.5 and the latest vdubmod

[azra28]

Hi,

When i try encoding with vdubmod and avisynth 2.5, my cpu usage is at 100% but after 1h(with XP1800) there's nothing I have'nt got the window with fps..

When i run encoding with vdub must I modifing sth in the encoder.cfg file?

> Sorry for my very bad english;)

[Selur]

"When i run encoding with vdub must I modifing sth in the encoder.cfg file?"
When you configure the Video Compression you should configure the encoder.cfg and save the changes.


@shootist:
are you sure your vob's are okay?


alex: try disabling bframes,.. maybe that helps ;)

Cu Selur

[Alex_e_Basta]

Thx Selur for your hint, but I already disabled Bframes :(
Have you tried AdaptiveBlockTransform = 0 ?

[Selur]

No, I allways left it on 2,..

You just started a 753frame long test sequence (it's a part of the 1st chapter of Lost in Space).

Cu Selur

Ps.: I'll do a small encode on another machine and see if it works for me,..

[Selur]

just tested with "AdaptiveBlockTransform = 0" and it just produced green frames,.. so seems like it's better to not touch this Setting atm. :D

Cu Selur

Ps.:
So the working speedboosts seem to be:
lowering searchrange to 8
reference frames to 1
setting RDoptimization to 0
bframes to 0
(hope everybody can confirm this)

[wing1]

encoding seems to work fine; However, playback is a problem. Did all that was mentioned here, and vdub still open an blank file->testH264.avi. Press the play(1) and it said...error decoding the 1st frame due to corrupted data.

[Selur]

Hmm may be it's not good to change all the settings, just some of them,...

I allways set bframes to 0 for testing.

Important is to have an decoder.cfg in c:\ and to set NAL mode to 0 in this file.

Cu Selur

[Shootist]

@ Selur: THX for the tip but the problem was solved when had to reinstall windows on a new harddisk because my old IBM disk was damaged. I WILL NEVER USE AN IBM DISK AGAIN.

[Selur]

*gig* happy to hear your problem is solved ;)

[chepe36]

This codec is the best i have seen.
here are 2 images to compare it to xvid.
I put extremely low bitrates (high quantizers) bucause i wanted to make the difference clear.
the method i used was to make de hdot264 file and then try to do (in the quantizer mode) an xvid file with the same filesize.

[chepe36]

Oops!. sorry about the last post but i cant attach the file

[ales19]

i tryed it out with 50 frames of the dolby aurora trailer and compared it with xvid and divx... outstanding is the first adjective that comes into mind...

QPFirstFrame = 8
QPRemainingFrame = 12
FrameSkip = 0
SearchRange = 16
NumberReferenceFrames = 4
NumberBFrames = 0

with these settings i got a picture allmost 100% identical to the original...
the xvid and divx encodes were far from similar if watched closely, even tho i used quantizer of 1 (and set the max to 2).
the stars in the background were very usefull to point out the difference in detail retained (well... at least on dark scenes)
filesizes were not too far apart even tho 50 frame samples are too little to really tell...
anyway here are the approx sizes:
divx: 1.80 Mb
h264: 1.36 Mb
xvid: 0.85 Mb
the clip was 720x480@24fps (previusly IVTCed and saved as huffyuv) and iirc i used frames from 325 to 375... took about 1.36h to encode on my celeronI 733...
btw another few things:
1) enabling 1/8 pixel freezes my VDub for some reason
2) if i try to view the h264 avi file explorer crashes (but WinXP reloads it immediately so no big deal) so as you suggested its better to work on the decoder first
EDIT: ok, changing NAL mode to 0 (Telenor bitstream) in the decoder.cfg, fixed the problem.
3) what on earth are SP Frames and where can i find a "guide" that explains each option in the encoder.cfg?

anyway, charact3r and all other developers please keep up the good work this is a really promising codec! :) :)

[Ramirez]

Finally I was able to decode a short 1000 frames clip
(thanks alot Selur for the NAL MODE=0 Tip)
The results are simply astonishing, so I thought
to share it with you guys.

Here are a few screenshots.

Screenshot-1 (http://www.redzone.co.il/vad/misc/shot01.png)
Screenshot-2 (http://www.redzone.co.il/vad/misc/shot02.png)
Screenshot-3 (http://www.redzone.co.il/vad/misc/shot03.png)

[Teegedeck]

Originally posted by ales19


divx: 1.80 Mb
h264: 1.36 Mb
xvid: 0.85 Mb


Don't mean to be nitpicking here, but shouldn't you try to reach at least comparable filesizes? The DivX clip is more than double the size of the XviD one, for example. :rolleyes:

[DVD__GR]

Can anybody make some sort of gui and finally find the best settings??

[Tommy Carrot]

Originally posted by Selur
just tested with "AdaptiveBlockTransform = 0" and it just produced green frames,.. so seems like it's better to not touch this Setting atm. :D


I don't know why is that... It never happened in my tests. I've got good results with that.

Maybe because i watch the yuv files after encoding, and not the AVI in virtualdub?:confused: I cannot test it right now, could someone try it?

[Tommy Carrot]

Originally posted by ales19
i tryed it out with 50 frames of the dolby aurora trailer and compared it with xvid and divx... outstanding is the first adjective that comes into mind...

QPFirstFrame = 8
QPRemainingFrame = 12
FrameSkip = 0
SearchRange = 16
NumberReferenceFrames = 4
NumberBFrames = 0



Don't forget, that quantizer works differently, than in the mpeg4 codecs, you cannot compare them directly. Try to match the filesizes somehow, that is the correct way. In my experiences, h.264 quantizer 25 is about xvid quantizer 6 (bitrate-wise). Of course it can be different in various cases. h.264 uses logarithmic quantizers, mpeg4 uses linear.

[Selur]

"Can anybody make some sort of gui and finally find the best settings??" Best settings for what? I and most people don't even know what best settings are, so how could I/we find them? :D

"Maybe because i watch the yuv files after encoding, and not the AVI in virtualdub? I cannot test it right now, could someone try it?"
I watch the avi's in WMP or BsPlayer ;)
But I'll do a quick encode to test with the yuv files,..

"QPFirstFrame = 8
QPRemainingFrame = 12 "
I prefer 15 and 20 => 3/4 to 1/2 half the size of Xvid quant 2, but better quality (in my eyes)
17 and 17 normaly gives me next to the same size as Xvid quant 2, but still better quality (in my eyes)

Would be cool if someone coudl test an anime encode, especially with a not lowerd number of ReferenceFrames,..

"what on earth are SP Frames and where can i find a "guide" that explains each option in the encoder.cfg?"
like posted earlier in this thread, read the Joint Work Drafts at http://bs.hhi.de/~wiegand/JVT.html to get a general 'look' into the settings.


Cu Selur

/edit:
with "AdaptiveBlockTransform = 0" yuvtoavi on the yuv file creates a playable file,...
edit/

[Alex_e_Basta]

@Teegedeck

Don't mean to be nitpicking here, but shouldn't you try to reach at least comparable filesizes? The DivX clip is more than double the size of the XviD one, for example

I think you are right, the only "scientific" way to compare different codecs is to compare clips with the same filesize or clips with the same psnr.
I noticed that the first and the last frame in an h264 encoded file are broken and the first frame is shifted by 1, so if you want to try the psnr comparison, you need to cut off this frames in your script.
My little .avs to comparison purpose.

LoadPlugin("C:\Avisynth\plugins\mpeg2dec.dll")
orig=mpeg2source("C:\Avisynth\PH.d2v").trim(0,19).crop(0,72,720,432)
encoded=avisource("c:\Avisynth\H264\PH 264 10-20 mod2.avi").trim(1,18).BicubicResize(720,432,0,0.75)
compare(encoded,orig,"","",False)

Obviously, Avisynth 2.07.

Bye
Alex

[Shootist]

OK,
now the codec runs but 2 avis were created. And I can only play the first one if the second is in the directory. The second isn`t playable. Does someone know why? Used this encoder.cfg (http://petermuschick.bei.t-online.de/doom9/encoder.cfg) and vdubmod with avs2.5.

------------------------------

what is the real file containing the video?
-test.26l
-the created avi
-test_rec.yuv

I ask this because they have all different filesizes.

------------------------------

QPFirstFrame = 25 #30# Quant. param for first frame (intra) (0-51)
QPRemainingFrame = 30 #31# Quant. param for remaining frames (0-51)

I think these settings reduce filesize much with no quality-loss.

[Selur]

it's the created avi that should be a bit larger than the .26l file but a lot smaller than the .yuv file, as far as I can tell :)

Cu Selur

[ales19]

@ Teegedeck & Tommy Carrot

i see your point and you are right in pointing this out but what i wanted to see with this test was the fidelty in image detail achived by the 3 codecs at top quality settings, i just posted the file dimensions in case someone was interested... :)
ok, i used h264 with 8 and 12 quantizers but that is because i reused a clip i did from a previous test and i re-used it because i saw that the frames were practically identical to the ones in the original clip so i thought it could go as top quality settings anyway...
my bad, ill try to express myself better next time :)
btw, why on earth does the codec have to skip frames when b-frames are enabled????
anyone tryed 1/8 pixel yet?

[Selur]

"anyone tryed 1/8 pixel yet?"
Yes, I tried, but I didn't see a difference (in encoding speed and quality, don't remember if the filesize was different, deeted the file). Though it coudl be that it only helps if you use it with lower datarates,..

Cu Selur

[Alex_e_Basta]

@Shootist
what is the real file containing the video?
-test.26l
-the created avi
-test_rec.yuv
As Selur said, the only file playable in WMP is the second of your list; the first and the third have an unknown structure (unknown to me, at least..).
All .avi generated by VDub correctly play in WMP (but don't play in Bsplayer nor in Zoomplayer).


@Selur
A little trick about green frames: if you encode a clip using AdaptiveBlockTransform = 0 in encoder.cfg, you need the same value in decoder.cfg and you'll play correctly your .avi in WMP.

Bye
Alex

[Selur]

@alex: Thx,.. doh, could have thought about that ;)

Btw.:
the test_rec.yuv can be converted into an playable avi (quiet huge) with yuvtoavi wich is one of the yuvtools (command line tool),.. see here (http://forum.doom9.org/attachment.php?s=&postid=174083) for the yuvtools

Cu Selur

[Tommy Carrot]

Originally posted by Shootist

------------------------------

what is the real file containing the video?
-test.26l
-the created avi
-test_rec.yuv

I ask this because they have all different filesizes.

------------------------------



26l file is created by the reference software (which this codec is based on)
this codec is wrapping the 26l file inside of an avi container.
yuv file is the lossless image of the 26l file, created during encoding.

I've tried decoding the output with virtualdub. It's ok, but i think the decoder is too slow, almost half to eternity to jump to a few hundred frame. Converting the yuv file is more confortable to me. :)

[Alex_e_Basta]

Thx Selur, I tried yuvtoavi, but it generates a raw RGB bitmap sequence and I can't use it to determine Psnr.
Nevertheless, as Tommy Carrot said, I can confirm that the converted file rendering is amazing and fast while .avi is very slow.

Ciao
Alex

[chepe36]

So what do you say?

To Develop or not to Dvelop? thats the Question.

Can we expect this codec for the future?

[ales19]

Originally posted by Selur
"anyone tryed 1/8 pixel yet?"
...it could be that it only helps if you use it with lower datarates,..

Cu Selur

yes, gues it does, if i manage to avoid VDub freezing ill try messing around with it to see if there are any significant differences...

an interesting thing is to convert the .yuv file back to huffyuv (which was the original format i used), the file dimensions are allways smaller, this can give you also a very rough idea of the amount of data lost (which doesnt necessarily give you an idea of the quality retained though)

so, charact3r, id say the comments push toward development of this codec, right? :D

[Selur]

@chepe36:

"To Develop or not to Dvelop? thats the Question."
No it's not like charact3r posted earlier in this thread (page 4):
It seems clear now that it is worth more development, as the original developer, I don't have time to do everything.

So the question is:
Who's able and willing to help?

Cu Selur

[charact3r]

I just put a copy of the JointFinalCommitteeDraft (the compression standard) on the hdot264 site. The URL is http://hdot264.sourceforge.net/index.html

It's pretty heavy reading. If anyone was keen they could start implementing "leaf atoms" of the code in optimised form, for example, the integer transform or loop filter and we could hack them into hdot264. This should speed things up a bit.

[shlezman]

Correct me if I'm wrong, but it seems that the hdot264 is based on a very early reference software (JM2 or so) and alot of changes were introduced to the standard since, like cancelation of ABT and 1/8 pel motion vectors and changes in the loop-filter and many other changes.

The latest unofficial software release http://bs.hhi.de/~suehring/tml/download/
includes a suggested rate-control. I didnt get the chance to examine it closely but I guess that updating the hdot264 will allow better comparison with existing codecs, thogh the latest software is not aligned with the draft so many changes will follow and maintaining the software will require alot of work.

The nice thing about the h.264 is that the baseline will probably will be free of royalties so if the open source development will continue, I must suggest focusing on that profile first (no CABAC,B frames and interlacing).

[charact3r]

Originally posted by shlezman
Correct me if I'm wrong, but it seems that the hdot264 is based on a very early reference software (JM2 or so) and alot of changes were introduced to the standard since, like cancelation of ABT and 1/8 pel motion vectors and changes in the loop-filter and many other changes.Yes, this is an issue - IIRC the reference software used for hdot264 was jm40d.zip. I found I was spending all of my time keeping up with the reference software updates. You sound like you know what you are talking about, shlezman. If you want to help integrate the latest reference software then please do. I've been so busy with work the past few weeks that I haven't had time to touch the code.

The nice thing about the h.264 is that the baseline will probably will be free of royalties so if the open source development will continue, I must suggest focusing on that profile first (no CABAC,B frames and interlacing). Agreed.

[shlezman]

The development of the h.264 is much more complex then the mpeg4 and the IIRC's are poorly designed, for that reason a long study and design is required, optimizing the reference software will become an endless work. As I wrote before, you might want to focus on a limited set of features (for example the baseline) and make a good design before getting started.

I wish I could get involved in the development, but that might cause me a slight conflict of intrests. But I'll keep track of the project and try to feedback occasionally.

[ChristianHJW]

Originally posted by shlezman I wish I could get involved in the development, but that might cause me a slight conflict of intrests. But I'll keep track of the project and try to feedback occasionally. ... you`re making us curious ?? A conflict of interests with your private Life or seen from a professional side ? Are you a codec developer ? What company ;) ?

[shlezman]

Everyone has to eat. :rolleyes:

[netchris]

This might help those who have problems using the codec with vdub like I did. You have to have the encoder.cfg in the folder c:\hdot264 OR ELSE it freezes the vdub. Playing with the settings in the encoder.cfg i have managed to get a speed of almost 1fps (480x352 size)and the video quality is still great. So far I haven't managed to play the avi output in any player (might be the wm9player causing the problems),but fortunately I can open the file in virtualdub. I have made the appropriate changes in the decoder.cfg so who knows what could be wrong :rolleyes:
To my eyes this codec produces the best results,it is in a way a "state of the art" codec. Wm9 codec is absolutely crap without postprocessing,inferior to xvid.
**************
My specs: athlonxp1600, ati9700pro, windowsxp sp1,directx9

[Tommy Carrot]

I think it would be great if someone could create this codec to a VFW frontend, and the codec wouldn't need CFGs, and wouldn't generate that much files, just the avi.

Many option from the cfg is unnecessary, because they influences the container layer, loss-handling, etc, unnecessary for this codec.

important options imo:
- I/P/B quantizers
- B frames numbers (linked with frameskip)
- RDoptimization on/off
- intraperiod
- number of reference frames
- entropy coding method
- ABT (if still in the standard)

And that's all. Searchrange will be unimportant with proper motion estimation.

I hope this would be not too problematic, because it would greatly enhance the usability.

/From what i could understood from the sources, large part of it handles the container, error handling, etc. Throwing that away would definetaly make easier the development imo./

BTW, is it true, that Adaptive Block Transforming was rejected? :confused: Why? It was an useful feature and definetaly helped to rise the compression efficiency...

[Bulletproof]

I can't seem to get a picture on decoding, I copied Selur's decoder.cfg to C:\ but when I open the created .AVI in VirtualDub I just get a bunch of black frames.

[Selur]

make Sure your the Adaptive Block Transforms, Entropy Coding and Encapsulated_NAL_Payload are the same in Decoder and Encoder and that NAL mode ist set two 0 in both files.

Cu Selur

[ales19]

Originally posted by Tommy Carrot

- ABT (if still in the standard)

BTW, is it true, that Adaptive Block Transforming was rejected? :confused: Why? It was an useful feature and definetaly helped to rise the compression efficiency...

wel, its still in the config file of the jm50c reference sw package at http://bs.hhi.de/~suehring/tml/download/
(even in the jm50g under the unofficil subdir)

[shlezman]

Originally posted by ales19
wel, its still in the config file of the jm50c reference sw package at http://bs.hhi.de/~suehring/tml/download/
(even in the jm50g under the unofficil subdir)

The ABT was removed after some new features were added and the ABT's efficiency dropped.

Yes it is still in the reference sw but the sw is a bit behind the standard itself and removing the ABT from the sw is a hell of a job, so, just dont use it :)

Anyway, the sooner the hdot264 is updated with the latest features, the more people will be exposed to the amazing improvement in video compression this new standard can offer.

Unfortunately some "closed" standards are trying to take over the video market and projects like hdot264 are extremely important to expose the open standards to the public. But that requires more involvement of free developers.

[-h]

I personally won't touch it with a ten foot pole until I see finalised standards and references up for download.

-h

[trbarry]

The MPEX-x trick is the timing to catch the almost finalized standards right before they become too expensive to get anymore.

- Tom

[-h]

Indeed. It's not hard to find the 11172 and 13818 docs via google, but 14496 hasn't "trickled down" at all yet.

Luckily, the reference code for H.264 (while still terrible in many places) is far better than what MPEG-4 had, so implementations or optimizations will be easier.

-h

[Latexxx]

The startup also said it will deliver an H.264 encoder/decoder chip that will be capable, like the decoder, of handling MPEG-2 video. Sand Video also hopes to spin a "companion chip" designed to work with a third-party MPEG-2 video decoder IC already designed into many of today's DVD players, said Peter Besen, president of Sand Video (Andover, Mass.).

The companion chip will perform real-time H.264 decoding of 1,920 x 1,080i high-definition video at 7 Mbits per second, but will not decode MPEG-2 video. The chip will be useful to system OEMs that want to develop a high-definition DVD player based on red-laser technology while preserving the critical software developed for the current-generation MPEG-2 decoder chip in their DVD players, explained Besen. The DVD Forum, an industry standards-setting body, has been looking at H.264 and several other codecs for almost a year in the process of selecting an advanced codec for high-definition DVD disks based on the next-generation HD-DVD9 format.


http://www.eet.com/semi/news/OEG20030113S0049

[Tommy Carrot]

@Charact3r:

I've found a tiny bug. The codec doesn't mark the keyframes to keyframes, only the first one. (i've set 125 to the keyframe-limit, and they are indeed keyframes, because they are much longer than the neighborous frames, but they are blue colored on Virtualdub's histogram, and the encodings are not seekable.)

If you decide to continue, please fix this.

[trbarry]

The companion chip will perform real-time H.264 decoding of 1,920 x 1,080i high- definition video at 7 Mbits per second,

Anybody played with H.264 enough to have any feel for if this is a realistic expectation for hidef TV? I don't think I'd expect to get away with it in Xvid for really good HDTV quality at this size. (nor would I want it interlaced)

- Tom

[Tommy Carrot]

Originally posted by trbarry
Anybody played with H.264 enough to have any feel for if this is a realistic expectation for hidef TV? I don't think I'd expect to get away with it in Xvid for really good HDTV quality at this size. (nor would I want it interlaced)

- Tom

I think h.264 is really better. Even the reference software's quality is usually better, and these animals are not known for going to the limit of the given technology.

[Mango Madness]

i was really pissed when i heard the HDTV specs still allowed interlacing. Anyhoo, that's beside the point. What we really need is either multiple programmers tackling the codec or a company like Divx Networks to take it under their wing. Hopefully we'll see fruition of this codec soon.

[trbarry]

I'm sort of waiting now to see what gets chosen (if anything) for the HD-DVD standard(s). That's maybe where the players will be.

But H.264 does sound pretty interesting so I hope this keeps moving along.

- Tom

[netchris]

The CVS Repository of the hdot264 sourceforge site has been updated(at last!) with some new commits.
Until a few hours ago it had 144 commits, now it has 352.
For the time being I cant load the page.
Hoping for a new binary,by someone who can compile the source .:D

[charact3r]

Originally posted by netchris
The CVS Repository of the hdot264 sourceforge site has been updated(at last!) with some new commits.Yes, that's right, I finally found some time to upgrade hdot264 to include the latest reference software. Hopefully this has not broken anything - it seems to work fine in my vdub.

I also rearranged CVS (using a branch) so that updating to future versions of the reference code should not be too hard.

Can now start on the serious stuff of optimizing the code. Features like seeking and re-entrant code (multiple instance of encoder and decoder) can wait until we get the brakes off this thing!!!

Please try it out :) And please help :)

edit: fixed typo

[Selur]

@rjamorim: could you provide us with a new binary for testing ;)

Thx

Cu Selur

[Mango Madness]

It is good to know things are moving forward. Binary updates will be greatly appreciated. Continue the excellent work.

[netchris]

I don't know if it is my problem only but I still can't browse the CVS.
Anyone else tried?

[-h]

I looked over the code a while ago and was struck by the notion, "this sucks." While it wasn't as suckful as the previous MPEG-4 reference distributions, the lingering smell was still there.

Do you think you'll work at point-optimizing the reference base, or eventually re-structure and re-write its entirety?

-h

[karl_lillevold]

While I am sure there is nothing left of it now, it is interesting to note that the H.264 reference code originated from a Fortran program, then called TML (Test Model Long-term) developed in its entirety by a previous colleague and good friend of mine, who can write the most amazing Fortran code (compact and fast). The code was then auto-translated to C, but then suffered from Fortran's use of multi-dimensional arrays.

This is all long gone by now, and the current reference code can be credited to a long list of people (check who wrote the CAVLC routine :) ). Its slow speed can in addition to exhaustive motion search for every block size, be attributed to that for every macroblock, every single mode is coded completely, bits counted, and then the best selected. As you all know by now, this all takes several seconds per frame, and is not quite the optimal approach from a CPU performance point of view; however, it leads to very compression efficient mode decisions most of the time.

[Sirber]

I'm trying this codec. It's about 1 frames at each 5 seconds on a 2 GHz!!!!!

[edit]

I got a 48ko movie, but it crashes BSPlayer and explorer.exe :scared:

[Selur]

@Sirber: check the posts before, could be a problem with your decoder.cfg or encoder.cfg, I'm useing BsPlayer myself and at least for me it worked,..

Cu Selur

[charact3r]

I looked over the code a while ago and was struck by the notion, "this sucks."
It certainly does. The codec feels most at home inside a main() function and doesn't like being connected to any sort of API.

Do you think you'll work at point-optimizing the reference base, or eventually re-structure and re-write its entirety?
Yes, that was my plan, in that order.

Sirber: check the posts before, could be a problem with your decoder.cfg or encoder.cfg, I'm useing BsPlayer myself and at least for me it worked,..
decoder.cfg is not read any more. It's values are hardcoded in the sourcecode. EDIT: you may also now need to create a new encoder.cfg for the new JVT version.

I've found a tiny bug. The codec doesn't mark the keyframes to keyframes, only the first one. (i've set 125 to the keyframe-limit, and they are indeed keyframes, because they are much longer than the neighborous frames, but they are blue colored on Virtualdub's histogram, and the encodings are not seekable.)
Yes, encodings are not seekable. I keep reminding people of this :). However, while the decoder is so slow, it's quicker to dub to huffyuv and playback that at real time.

[ales19]

any binary updates of the new sourcecode on rjamorim's site (RareWares) yet? :D

[Shootist]

nope, not yet

[Alex_e_Basta]

Hi all,
I compiled new V2 version from CVs, but the chain Avisynth 2.5a + VDub 1.4.13.1 always crash (access violation) either using the new encoder.cfg or the old one.
Reinstalling old version, all works as usual.
Any clue ?

Thx
Alex

[Selur]

"VDub 1.4.13.1" did you also try VDubMod?

Cu Selur

[DeXT]

Yes it always crashes when you try to encode with it. I'm afraid something isn't working right with the new release. BTW the CVS version doesn't compile because there are some files missing from the old jm core which are linked from the h264enc_dll project.

@Selur: VirtualDub 1.4.13.1 is in fact VirtualDubMod since this vesion number doesn't exist for the official one. ;)

[Alex_e_Basta]

Thx DeXT for your reply, I think that it's better to wait for a more stable version, don't you ?

Ciao
Alex

[rjamorim]

Originally posted by Selur
@rjamorim: could you provide us with a new binary for testing ;)

Sorry for the delay, I was at the beach. :D

Latest hdot264 uploaded to Rarewares. It's not listed in the MPEG4 page yet, due to the issues raised by DeXT. Download directly from here:

http://www.inf.ufpr.br/~rja00/files/hdot264v2.exe

Regards;

Roberto.

[rjamorim]

Originally posted by karl_lillevold
who can write the most amazing Fortran code (compact and fast).

http://spike.scu.edu.au/~barry/RealProgrammers1.html

:D


And an interesting project in Fortran:
http://members.tripod.co.jp/kitaurawa/index_e.html
(Binaries available at RareWares)

[Sirber]

any news?

[Tommy Carrot]

Originally posted by Sirber
any news?

Nothing important, just the reference encoder is updated to jm60. So it is true that Adaptive Block Transforming was removed from the spec. I still can't understand why.

[DVD__GR]

Should it affect quality ??

[Tommy Carrot]

Originally posted by DVD__GR
Should it affect quality ??

Yes, ABT reduced the bitrate quite alot.

[MfA]

You sure it has been removed from the standard? (It could be removed temporarily from the reference software for different reasons.) I would have expected to see some talk on the jvt-experts list or at the last JVT meeting for a change that big.

[karl_lillevold]

There are differing opionions as to how useful ABT is, and many simulations and visual comparisons showed little gain and bitrate improvement. I am not supporting one opinion or another, just saying that it was a very controversial issue. Only one point was agreed upon, and that was that it increased the complexity of the standard significantly, and since it was hard to show much of an improvement, it was removed after having been in just a short while.

[ales19]

Originally posted by Tommy Carrot
Nothing important, just the reference encoder is updated to jm60. So it is true that Adaptive Block Transforming was removed from the spec. I still can't understand why.

has the bug that made Virdualdub crash been removed yet?

[Tommy Carrot]

Originally posted by ales19
has the bug that made Virdualdub crash been removed yet?

The two thing has no connection to each other AFAIK. I was not referred to hdot264, just the reference software.

[shlezman]

The ABT's complexity issue was primarily hardware implementation problem. The added value of the ABT was too small compared to the "On-Chip" implementation of it, just too much math I guess.

[ales19]

Originally posted by Tommy Carrot
The two thing has no connection to each other AFAIK. I was not referred to hdot264, just the reference software.

oh, woops... i thought the jm60 code was merged in the project files.. :)

anyway, my question is still valid, has the VDub bug been removed yet?

[Tommy Carrot]

Could someone tell me, what's the point of the two entropy coder (cavlc and cabac)? As i could understand, cabac is always the better, and the complexity difference is not so great. So?

[Selur]

a little google search showed this:
CABAC offers superior coding efficiency over VLC by adapting to the changing probability distribution of symbols, by exploiting correlation between symbols, and by adaptively exploiting bit correlations using arithmetic coding. H.264 also supports Context Adaptive Variable Length Coding (CAVLC) which offers superior entropy coding over VLC without the full cost of CABAC.
see: http://www.videolocus.com/library/images/vl_tutorial.pdf

Not too sure if this helps, but as far as I remember there was some patent or copyrigth issue with cabac,..

Cu Selur

[karl_lillevold]

there are (at least) two reasons for having both CAVLC and CABAC in the standard.

1) complexity:
CABAC is an arithmetic coding scheme, CAVLC is VLC based although highly adaptive. An arithmetic coding scheme requires the decoder to perform calculations for every bit received, while a VLC scheme reads whole bit words at a time. Tests have shown that CABAC decoding requires ~4 times more CPU cycles than CAVLC decoding at similar bitrates, accounting for 35-70% of the total decode time, and even more for I frames. However, since everything else is so slow in the reference software, this complexity difference is not apparent there.

2) profiles / royalty:
CAVLC is in the Baseline profile, CABAC is in the Main profile. One hopes to make Baseline a royalty free profile (as opposed to the current MPEG-4 standard (hurrah!)), while Main will require royalties. One example in how this affected the standard is that for CAVLC we made the design decision to not use 2D run-level coding, which is patented by a company not known to be in support of a royalty free standard (ask me which company :) ).

Then you may ask, what is the compression gain from the extra complexity in CABAC? Before we added CAVLC it used to be pretty significant. Now it is much less, but very variable. One number that has been used is 8-10%. It can be as low as 1-2%, but also as high as 15-18%.

[DeXT]

Originally posted by ales19
oh, woops... i thought the jm60 code was merged in the project files.. :)

anyway, my question is still valid, has the VDub bug been removed yet? Seems the bug has been fixed in the latest build. At least I've been able to encode a short clip with it.

I put some binaries on my page. I included the latest *.cfg files tweaked according to Selur settings (however I left ABT disabled, as it was by default, and RDOpt enabled since you can't disable both, otherwise it hangs).

http://es.geocities.com/dextstuff

DeXT

[Selur]

thx for the new binary :)

Cu Selur

[ales19]

Originally posted by DeXT
Seems the bug has been fixed in the latest build. At least I've been able to encode a short clip with it.


ah, cool... btw, what was the last build's release date?

ps: thanks for the bin's

[Selur]

damn,.. the build doesn't work for me, at least with VirtualDubMod,...

DeXT what settings&tools did you use on your encode ?

Cu Selur

[rjamorim]

It doesn't work here either. (The v2 build at RareWares doesn't either, anyway)

[DeXT]

The provided encoder.cfg file works for me as it is, you just have to ensure you specify the exact same output resolution in both VDub and the cfg file, otherwise it doesn't work.

I used VirtualDubMod by directly loading a small sample VOB file someone sent to the forum, which is only 21 frames long, disabled audio output, and added a resize filter to 352x288 before encoding (it also works for larger resolutions provided you update the cfg file).

However the build is very unstable as it tends to hang if you lose the focus of the main VDub window while encoding, as an example (I just leade VDub untouched while encoding). Definitely it's not very usable as it is.

PS: the files were updated on 15-01-03 according to SF, the first v2 release I tried was from 14-01-03, which didn't work.

[Tommy Carrot]

@Selur and Karl: Thanx for the answers. ;)

[molerus]

Hi!

Has anyone compared the hdot264 codec vs the VSS 264 one??

Any comments, screen shots etc. (I would appreciate it:D).

I've tried the codec from VSS and I must admit I'm very impressed, and even the speed (about 1fps on my Duron 950, 640x480) is not so repellent. But when I downloaded the hdot264 and I saw the config file I decided not to fiddle with it. But if you folks seem to be more enthusiastic. If hdot264 is better than a VSS codec then it would be very nice if someone wrote a totorial for it (using with VDub etc.)

[Selur]

Personally I think it's to early to write a tutorial, the codec isn't developed enough and the basic steps should be clear, the only thing not so easy is to configure the encoder&decoder cfg files. However if one reads all the posts in the thread here and maybe some basics about h264, the main settings should be clear enough to use.

Cu Selur

Ps.:
@DeXT: What CPU do you have? Maybe it's the way you compiled hdot264, mybe you used some flags my Athlon doesn't support. (I rechecked the (resolution)settings, but it still doesn't work :( )

[Tommy Carrot]

Originally posted by molerus
Hi!

Has anyone compared the hdot264 codec vs the VSS 264 one??

Any comments, screen shots etc. (I would appreciate it:D).


hdot264 is basically vssh264 in 'slow' setting. (not joke)

[movmasty]

any relation between h264 and wmv9?

do they use similar techniques??

[Tommy Carrot]

Originally posted by movmasty
any relation between h264 and wmv9?

do they use similar techniques??

Judging from the artifacts, i don't think so. Realvideo9 is closer to h264.

[DeXT]

Originally posted by Selur
@DeXT: What CPU do you have? Maybe it's the way you compiled hdot264, mybe you used some flags my Athlon doesn't support. (I rechecked the (resolution)settings, but it still doesn't work :( ) I just compiled it in a P4 @ 2.4 GHz system with VCPP 6.0 + SP5 + Processor Pack, leaving the default project settings and optimization settings unchanged. The funny part is, it works like a charm on my test setup (an old K6-2 @ 450 MHz with 128 MB of RAM), but it miserably hangs on the P4 and also on an Athlon @ 800 MHz, both with 256 MB of RAM. It raises an access violation error.

However, even the hdot264v2 build from rjamorin works on this computer! So there must be some difference between these systems. Maybe a missing dll, a registry setting, who knows. Or perhaps it's just the processor or the amount of memory. Seems I'm the only one having luck with this :confused:

[DVD__GR]

It could be something with the cpu registers or the big difference between these systems is sse existence in the faster systems.maybe this got nothing to do,just an opinion..:confused:

[Sirber]

Any news, new build?

[Mango Madness]

been wondering if this thread was gonna get a bump. i've been curious as to the development, if any, with this codec and whatnot.

[deXtoRious]

I downloaded h.264v2 build and tried to encode a trailer with the default settings using FlaskMPEG but even after an hour of waiting Flask showed no progress whatsoever, not even the remaining time.

[Mango Madness]

the reason is that this codec is absurdly slow and very VERY new. It should only be used as experimental software until development progresses past the stage it's in now. When I was testing this in v1 when rarewares first hosted the build, i was getting about 1 frame every 15 minutes. This was with all the goodies and everything enabled. Down in this thread is a lot of talk about getting several frames a minute with disabling/changing some of the config options. So do some reading and try some things and tell us the results.

[molerus]

Hi!

@deXtoRious

I was encoding "Fast and Furious" for 24h on my Duron 950 :), but I waded to the end. I was "reaching" 1-2 fps. I think that after 1h you should definetely have some information from Flask. Maybe VSS doesn't work with it, try using VDub, it does.

[deXtoRious]

Thanks, I'll try using VFAPI with Vdub.

[Ramirez]

Does anybody know what's happening to the hdot.264 project
at sourceforge.net?.The project seems to be at zero activity
(again),does anybody still working on it?
It's a pity if the further development of this codec will be dumped.

[Mango Madness]

very true, this kinda stuff needs to definitely move forward. But until I can program and read mpeg 4 specs, I guess i have to sit on the sideline.

[Ramirez]

Yeah,sometimes when I'm reading up some programming stuff
posted here I'm afraid that it's might take a lifetime just
to learn the basics...:)

[shlezman]

There's another effort to optimize the JVT (H.264) reference source, you can find the first draft on
www.yahoogroups.com
the group is called jvt-remd.
I'll take a look at it myself soon.

[ales19]

Originally posted by Ramirez
Does anybody know what's happening to the hdot.264 project
at sourceforge.net?.The project seems to be at zero activity
(again),does anybody still working on it?
It's a pity if the further development of this codec will be dumped.

guess charact3r has been busy lately... as for the big coders on doom9 (such as koepi, nic, -h, and all the others) i think they are waiting for the codec specs to freeze into a final paper.

[Ramirez]

Originally posted by shlezman
There's another effort to optimize the JVT (H.264) reference source, you can find the first draft on
www.yahoogroups.com
the group is called jvt-remd.
I'll take a look at it myself soon.
By all means go ahead,I have a feeling you can give this project a great deal of boost.;)

Does charact3r know about existence of that group at Yahoogroups?, perhaps they should join forces or something.

[Tommy Carrot]

When is the deadline of the standardization?

[ales19]

Originally posted by Tommy Carrot
When is the deadline of the standardization?

i think i read it should be sometime in march iirc... but you know how these things go, they keep getting postponed, so i really dont know... :)

[ales19]

ok, the standards have been set!!! :)
time to start developing and testing :D

[Sirber]

yehoo!!!

Can't wait to compress 4 hours on a CD :D

[Atamido]

Originally posted by ales19
ok, the standards have been set!!!
Where do you see that?

[trbarry]

Rob Koenen posted on the MPEG-4 News Digest yesterday:
The good news form the MPEG meeting, which is about to end in half an hour or so, is that the text of new AVC | H.264 video codec standard is now approved. The same applies to the spectacular "High Efficiency AAC" profile.

- Tom

[ales19]

Originally posted by Pamel
Where do you see that?

trbarry just answered for me :)

[ChristianHJW]

Good !! This means we probably dont have to define a new subblock group to be able to support NALU's in matroska, and can use 5 of the 6 spare bits in block header to mark NALU priority ... we were worried they might add more of them before freezing the specs, because then we were borked with our current approach :( ...

[gino25]

In the offical site of hdot264 there is a file to download. What is that?

[deXtoRious]

what file?

[gino25]

here http://sourceforge.net/projects/hdot264/

[Sirber]

What's the new thing? A performance test?

[gino25]

do you know what is that file?

[Selur]

looks to me like the first steps of an h264 implementation,..
So if you don't want to read some sourcecode it won't be much help :)

Cu Selur

[deXtoRious]

I don't want to read it, I want to compile it and test it! ;)

[Selur]

as far as I looked on it, it doesn't look like there's much to test,.. it's just the very beginning ;)

Cu Selur

[Shootist]

I hope it will develop fast. In my opinion it has the best potential to be the next "best video codec".

[netchris]

The cvs page is being updated regularly lately.
The good thing is the source is compiled without errors, and I can encode some test clips.I can't open these clips with any media player, but they can be opened in Virtualdub, so I can have an idea of the results. It is still extremely slow, but it seems progress is being made.
Many thanks to the developers!

[CompuKid101]

The JVT team's FTP:

ftp://ftp.imtc-files.org/jvt-experts/

[Ramirez]

Just a wake up call..:rolleyes:

Shlezman, Charact3r, Anybody! what's uuuuuuuup!?
Any news in this area? :)

[Shootist]

no I think it takes some time to start the project after the specs are final

[Tommy Carrot]

Yes, but the development seems dead (again). The last code modification was 5 weeks ago.

[Shootist]

not so good news... I hope they still work offline...

[Tommy Carrot]

What are the differences between baseline and main profile? I know baseline cannot use b-frames, and uses CAVLC instead of CABAC, but any other?

BTW, baseline profile doesn't seems to me very powerful. The gain compared to mpeg4 ASP is marginal, from what i gathered.

B-frames in h.264 are very good, no psnr loss, like in mpeg4, so it helps much more. Main profile will be the real thing imo.

[Selur]

Profiles and levels
---------------------
Profiles and levels specify the conformance points. These conformance points are designed to facilitate interoperability between various applications of the H.262/AVC standard that have similar functional requirements.
A profile defines a set of coding tools or algorithms that can be used in generating a compliant bitstream,
whereas a level places constraints on certain key parameters of the bitstream.
All decoders conforming to a specific profile have to support all features in that profile. Encoders are not
required to make use of any particular set of features supported in a profile but have to provide conforming bitstreams.

In H.264/AVC, three profiles are defined ? Baseline, Main and X:

- The Baseline profile supports all features in H.264/AVC except the following two feature sets:
- Set 1: B slices, weighted prediction, CABAC, field coding and macroblock adaptive switching between frame and field coding.
- Set 2: SP and SI slices.

- The first set of features is supported by Main profile. However, Main profile does not support the FMO feature which is supported by the Baseline profile.

- Profile X supports both sets of features on top of the Baseline profile, except for CABAC and macroblock
adaptive switching between frame and field coding.

In H.264/AVC, the same set of level definitions is used with all profiles, but individual implementations may
support a different level for each supported profile. Eleven levels are defined, specifying upper limits for the
picture size (in macroblocks), the decoder-processing rate (in macroblocks per second), the size of the multipicture
buffers, the video bit-rate and the video buffer size.

source: The emerging H.264/AVC standard (http://megaera.ee.nctu.edu.tw/course/VSP03/project/H.264%20introduction.pdf)

Cu Selur

[Tommy Carrot]

Thanks!

[vinouz]

thanks too !

[chepe36]

Soooooo...

is this codec dead?

i really tought this would be the codec of the future and all that stuff... really right now i think that mpeg4 is getting to its limit.

[gino25]

Originally posted by chepe36
Soooooo...

is this codec dead?

i really tought this would be the codec of the future and all that stuff... really right now i think that mpeg4 is getting to its limit.


May be.........

[Shootist]

I really hope not. but there are also other projects trying to devellop a codec basing on h.264.

[temporance]

Originally posted by Shootist
I really hope not. but there are also other projects trying to devellop a codec basing on h.264. Oh? Got any links?
Cheers

[Shootist]

Originally posted by shlezman
There's another effort to optimize the JVT (H.264) reference source, you can find the first draft on
www.yahoogroups.com
the group is called jvt-remd.
I'll take a look at it myself soon.

maybe there are also other people trying to optimize the reference code, just google a bit or search in this thread...

[Shootist]

I think now it is really dead...

[chepe36]

Well... anyway i think its a little too early...
the specs have just been finished. and who knows maybe when Xvid is done and optimized someone will start developing this codec.

i would love to develop it but... I'm not a programer :D

I want to lear to code but im just starting and this thing needs someone with experience.

[Sirber]

VSS is developping a H264 codec, but hasn't released anything lately :(

[Dee]

http://www.mainconcept.com/ plans to release their version in Q3/2003

[Shootist]

ok, you are right that others try to do something, companies or programer in their freetime. but this codec is dead I think, or has someone heard anything new about it?

[ChristianHJW]

Subscribe to the mailing list on sf.net/projects/hdot264 and you know its not ... archives are on news.gmane.org also ( via newsreader ), gmane.comp.video.hdot264

[Shootist]

thanks a lot, I did not know about this...

[Nibor]

Any news?
(Sorry for 'bothering', but... I... have... to... aaaaaask! :p)

[Tommy Carrot]

I think we should forget hdot264 project. Right now ffmpeg project seems to be the most promising.

[Sirber]

Any URL?

[Tommy Carrot]

Originally posted by Sirber
Any URL?

The home page is here (http://ffmpeg.sourceforge.net), but it's down right now, because they are protesting agains software patents.

ffmpeg itself is hardly usable, but ffvfw and ffdshow usually contain the codecs with a little delay. So maybe soon we'll have h.264 support in ffvfw and ffdshow, that's what i meant.

[Sirber]

nice :)

[gino25]

But i haven' t understand.


Where i find a usable build of ffmpeg that include h264? does it exist?

And for decoder?

FFdshow and ffvfw will include support for h264?

[Gaia]

Originally posted by gino25
But i haven' t understand.


Where i find a usable build of ffmpeg that include h264? does it exist?

And for decoder?

FFdshow and ffvfw will include support for h264?

You can't find...because they don't exists...yet. Maybe someday...personally i don't care about h264.

[CruNcher]

@all

Some H.264 updates :)
@ IBC www.ibc.org Vanguard will show their H.264 codec wich they claim can encode/decode in realtime on the specs shown here http://www.vsofts.com/codec/h264_products.html also Nero will show their Nero Digital Productline including the Mpeg4 ASP Codec made by Ateme.

[Sirber]

still no binary...

[CruNcher]

@Sirber
it's a product you wont see a binary the reference code tests are over this i buisness now and most probably their never will be a trial version, because of the fear it could be cracked. I think they will do exactly as On2 with their VPx marketting.

[lazyn00b]

Originally posted by CruNcher
@Sirber
it's a product you wont see a binary the reference code tests are over this i buisness now and most probably their never will be a trial version, because of the fear it could be cracked. I think they will do exactly as On2 with their VPx marketting.

Apparently they have no intention of selling it, either. On their website: no shopping cart, no price, nothing. If they intend to have same business model as On2, they are doomed. When was the last time anybody anywhere watched anything encoded with On2's latest codecs, free or paid for, except for the little 30 second demo clips on their website? This is a shame because the beta versions of Vsofts' H264 codec seemed promising, although slow.

[Sirber]

lol

any compagny that fellow on2 marketing strategy will die in few days :D We should start a pool "Who ever used On2 codecs?"