>h.264< ?

[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?