>h.264< ?

[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 ;)