H.264 status and definition

[ToiletDuck]

I was reading through some of the threads to find out more about this codec however most of the discussions were either A: by a group of people that already knew what they were talking about, or B: People who didnt seem to know anything. I would be in the later group but after reading the threads I still don't fully understand.
After looking around I am gathering that H.264 or H.26L as it was once called is a new form of codec that will allow MPEG 1/2 to be encoded up to 1/4 it's original size without loss of quality? I'm a little shaddy there. Also from what I'm gathering is that it is completely unstable and very slow? I would like to know who came up with the idea for this codec and what potential it has. Also I looked at the moonlight clips and wasn't impressed at all. If that is what the codec has to ofer I'd rather stick with xvid and RV10. Seemed like A) Blockiness everywhere, B) Choppy, and C)The color of the clips was completely off. Skin looked red and greens and blues faded out. Any comments?

[Tommy Carrot]

H.264 is the successor of the current mpeg4 standard, and otherwise known as mpeg4 AVC profile. It's technically superior, so theoretically it would bring the same quality at significantly smaller bitrate (30-50% less), but the current implementations are far from perfect (to say the least), they are very slow, unoptimized and untuned.

[ToiletDuck]

so is this being developed on a volunteer developer level like Keopi and xvid or is it more or less being pushed by the media industry?

[Tommy Carrot]

Xvid is a bad example, it's an implementation of mpeg4 advanced simple profile, so it's not a private experiment either. The same is the case with H.264: it's an industry standard, but anyone can make an implementation of it (but unfortunately noone did that so far...).

[bond]

h.264 (officially called AVC (Advanced Video Coding) in MPEG-4) is not the successor of MPEG-4, its part of it!

h.264 is not 1 codec, its an open codec standard
the difference is that other formats, like RV9/10, VP6, WMV9 are closed formats, meaning only one firm releases only 1 codec and this firm has pretty much all rights on this codec
an open standard is as the name says a standard, which everyone can follow it when creating a h.264 codec, which means there are many different h.264 codecs (there is for example also an opensource h.264 project running, but has been very quiet lately)

the big advantage of an open standard is that it leads to a strong competition, which means the codec developers always have to look to offer high quality otherwise people will simply use another h.264 codec, what is very good for us, the customers

back to MPEG-4:
more or less you can say the MPEG-4 standard defines two video encoding standards:
1) MPEG-4 part2: which we all now as DivX5, XviD, 3ivx aso...
2) MPEG-4 part10 (also called AVC|h.264), which is a superiour coding technology than "normal" mpeg-4

the h.264 technology is pretty new and therefore only a few h.264 codecs exist, which are not really tuned and very slow and dont offer the maximum quality they could (simply imagine how divx5 and xvid performed some years ago)

[temporance]

Originally posted by Tommy Carrot
H.264 is the successor of the current mpeg4 standard, and otherwise known as mpeg4 AVC profile. It's technically superior, so theoretically it would bring the same quality at significantly smaller bitrate (30-50% less), but the current implementations are far from perfect (to say the least), they are very slow, unoptimized and untuned.

I wouldn't say the current optimizations are untuned. Slow and unoptimized yes, but they are pretty well tuned, having the same type of RD opts as xvid's VHQ mode. I'm talking about the JVT encoder which is what most people have used to benchmark the standard.

Personally, I expect this standard to require in the region of 0-30% less bitrate than regular MPEG-4 (DivX or xvid). In other words, for some clips, there will be no advantage, but for others there might be a noticeable quality improvement at the same bitrate. This improvement will come at the cost of increased encoding times and high decoder CPU load (esp. at resolutions > 320x240).

Industry is very excited about this codec: IMHO it will not trounce MPEG-2 and MPEG-4 in the way that people expect it to.

[MfA]

Partly for PR reasons and partly because they will use it in the MPEG-4 container format MPEG has declared it as part of MPEG-4, but the text of the standard shares diddly squat with the old MPEG-4 visual standard. As far as the coding goes it is a defacto successor.

Please, credit where credit's due ... let's keep calling H.264 by that name :)

[P0l1m0rph1c]

Originally posted by Tommy Carrot
Xvid is a bad example, it's an implementation of mpeg4 advanced simple profile, so it's not a private experiment either. The same is the case with H.264: it's an industry standard, but anyone can make an implementation of it (but unfortunately noone did that so far...).

Ever heard of the x264 project?

[bond]

there are two opensource h.264 projects (next to the reference sources) available already:

fenrir's x264 (http://lyra.via.ecp.fr/) (as P0l1m0rph1c wrote)
hdot264 (http://sourceforge.net/projects/hdot264/) by charact3r (does anyone know if openhdot264 is closely related to hdot264 or more a different project?)

skal (http://skal.planet-d.net/coding/mpeg4codec.html) is also working on a h.264 encoder, but hasnt released any sources till now

[Tommy Carrot]

Originally posted by P0l1m0rph1c
Ever heard of the x264 project?
No. (http://forum.doom9.org/showthread.php?s=&postid=430128#post430128) :D

Seriously, it has the illness of all h.264 projects: it's very sporadically developed, inactive, i just don't have too much faith in it. And i cannot compile anything usable from it!! :devil:

[thegeby]

The European broadcasters in EBU seem to be rather miffed by the proposed MPEG-4 AVC/H.264 licencing deal. EBU Press release (http://www.ebu.ch/tech_texts/tech_text_d96-2003.pdf)
Their point is that the terms do not fit channels that broadcast to a narrow audience but that cover a large footprint. This may be an early salvo in a negotiation strategy, but is a pity anyway as there has been clear interest on the technical side to use this codec in DVB high definition broadcasts.

EBU tech people seems to prefer 720p as a future standard claiming that it can display standard signals better than interlaced HD. If Europe wants to avoid wasting bandwidth US style, this means one of the "new" codecs: H.264, WMV9, RV"X", VP6, DIVX. Could be interesting....

[bill_baroud]

i compiled ffmpeg some days ago (to have a new lib for ffdshow :whistle: )

and noticed a nice "h264" in the list of output format .... what does it mean ??
i didn't test it, but there is an h264 encoder in ffmpeg ?

[d'Oursse]

according to the doc, ffmpeg decode h264, but did not encode (see TODO in the doc directory, for example)

[el divx]

skal (http://skal.planet-d.net/coding/mpeg4codec.html) is also working on a h.264 encoder, but hasnt released any sources till now [/B]

Can then smeone from this forum/thread compile a version usable in vfw programms such as VD? Sources and documentation are available in skal's (http://skal.planet-d.net/coding/mpeg4codec.html) website. I'd do it myself, but I don't know anything about progrmming:o

[MfA]

I didnt even know about the 2010 thing ... personally I cant see anyone investing in H.264 with that kind of hostage situation looming. I foresee it languishing in the same patent limbo as MPEG-4 did if they cannot get agreements from all parties on a usefull license. If they dont m$ or on2 could have a field day if they play their cards right.

Glad to see the EBU agrees with me on interlacing at least :)

[el divx]

Shouldn't then the developers in this forum help people like fenrir and skal evolve what they already have started?!? I think that we just have to develop an h.264 codec that will create mpeg-4 avc(h.264)-compliant content without using reference code so that those jackoffs at M.P.E.G. won't be able to argue about using their patented code and develop it while they will still be trying to figure out the license to put on h.264.

[MfA]

That is not how patents work.

If Skal wanted help Im sure he would have asked for it ... hell, he never said he would open source it even.

[shlezman]

http://www.dvdforum.org/25scmtg-resolution.htm

"Provisional approval of MPEG2, WM9 (VC-9) and MPEG4 AVC(H.264) Video CODECs as mandatory for the HD DVD Video specification for playback devices, subject to (a) an update in 60 days regarding licensing terms and conditions, (b) a presentation by each of the respective licensing bodies at the next SC meeting and (c) possible elimination of any of the above CODECs at the next SC meeting. "

It seems that the DVD-Forum has chosen (for the moment) WM9 and H.264 as mandatory codecs for the upcomming HD DVD format.
Very strange decision, considering how much $ the customers will have to play for royalties and that over-compatibility .I womder how much time it will take for the industry to fully support all these formats (except MPEG2).

[MfA]

AFAIK there isnt even a single licensing body for H.264 at the moment, both vialicensing and the mpegla have their own licensing pool.

[justin]

okie, for status of the open source implementations:

skal is already finished his H264 codec. He is not sure if it will be made open source because there are other companies interested in using it commercially. It may become open source, but he's not sure yet

Hdot264 is not currently not being worked on at this moment and Fenrir's x264 is being worked on by him and I am trying to join in and help him with his codec

[MfA]

He should sell it and try to get a job out of it :)

I only know of one other guy who said he did an independent implementation in his own time, Wei Dai ... and he now works for FastVDO, which very recently started to promote their new H.264 codec with a remarkably simular description to the one Wei Dai had.

[Tommy Carrot]

Originally posted by justin

skal is already finished his H.264 codec.


Are you sure about this? I've heard nothing about it.

If he doesn't want to open the source, could he still release it in executable form, or he doesn't want to do that because of the license issues?

[el divx]

Why then can't he just mark it "for educational purposes only" like the XviD developers did with XviD? That way he wouldn't have any problems with mpeg licensing fees or anything, won't he?

[Joe Fenton]

Also: I've read the draft specs of the newcoming H264 standard (aka AVC. aka JVT. aka MPEG4 Part-10, even). It's fun and very challenging! And with very efficient coding properties. I'm currently writing a codec for it... It almost reached Baseline and Main Profile. Stay tuned.

That is all that is on Skal's web page. Any reports of an actual codec are just rumors based on this statement.

[MfA]

Joe some people might have you know ... talked to him.

el divx, yes he can ... but noone here suggested he could not release because of patents, apart from you. So this is getting a bit circular.

[SeeMoreDigital]

Has anybody else noticed that when you have Moonlights player and MainConcepts encoder (with decoder player filters) installed, the two of them don't get on!

For some reason MainConcept does not like Moonlights mpeg2dmx.ax filter... but I'm at a loss as to why an Mpeg2 filter is required in the first place.

I thought H.264 feet were firmly rooted in the Mpeg4 camp!

Cheers

[Tommy Carrot]

If i interpreted it correctly, x264 finally got VFW interface, so it can be used as a normal codec. Would someone be so kind to share with us a build from it? (I hope asking this is allowed here. :))

EDIT: Request cancelled. :p

[RadicalEd]

The last few ffdshows have had it :|

[Tommy Carrot]

Yep, but i cannot open the H.264 videos in Vdub with ffdshow. I hope using directly this codec would solve this problem.

[RadicalEd]

Originally posted by Tommy Carrot
Yep, but i cannot open the H.264 videos in Vdub with ffdshow.

?:|
Why not?

[Tommy Carrot]

Originally posted by RadicalEd
?:|
Why not?

See this (http://forum.doom9.org/showthread.php?s=&threadid=75841) thread.

[RadicalEd]

Hmm, strange. You're sure you changed the fourcc to H264 and enabled it in the VFW configuration's decoding>codecs tab?

[Tommy Carrot]

Damn, you're right, that works. I wasn't aware i have to manually enable the support for the requested codec in the VFW section too. Thanks man!

[justin]

I made a quick compile of x264, link (http://www.geocities.com/justinclaybaby/x264.htm)

no working configuration panel for the encoder, no easy to use installer or directshow decoder yet, but you can use Vanguard Software's free h264 decoder (http://www.videosoftinc.com/decoders.html) to decode it though, and just change the fourcc code of the ouput avi to vssh with abcAVI tag editor (http://www.divx-digest.com/software/abcavitags_editor.html) and you should be able to view the output

Still have to code in the dialogs, whoever those authors are, they're wierd people :p

[bond]

nice that you are working on h.264, but still i have the question why you support vfw? its outdated technology which doesnt even handle b-frames right...

[SeeMoreDigital]

Originally posted by justin
I made a quick compile of x264, link (http://www.geocities.com/justinclaybaby/x264.htm) "I cannie get the link to work... Captain Kirk"

[Tommy Carrot]

Originally posted by bond
why you support vfw? its outdated technology which doesnt even handle b-frames right...


What's the alternative? It's the only widely used API for encoding (except quicktime, but that doesn't count). The b-bframe handling is long time solved, not a real problem imo. The only real handicap is the missing VFR ability, but for most of us it's not important at all.

Someone (perhaps Avery himself?) said Dshow is not exactly suitable for editing, and i'm strongly against the native MP4 streams since the total lack of support, so only VFW left.

(I'm not not a developer, just my 2 cents :))

[Tommy Carrot]

Originally posted by justin
I made a quick compile of x264, link (http://www.geocities.com/justinclaybaby/x264.htm)

no working configuration panel for the encoder, no easy to use installer or directshow decoder yet, but you can use Vanguard Software's free h264 decoder (http://www.videosoftinc.com/decoders.html) to decode it though, and just change the fourcc code of the ouput avi to vssh with abcAVI tag editor (http://www.divx-digest.com/software/abcavitags_editor.html) and you should be able to view the output

Still have to code in the dialogs, whoever those authors are, they're wierd people :p

Thanks. My quick impressions: It's almost twice slower than the 2 weeks old x264 version inside the ffdshow encoder, but the quality is better. The quantizer scale is mixed up, quant 1 should be the best quality, 51 should be the worst. Oh, and it would be great if disabling the loop-filter would be possible in the future builds (but i guess this is why the advanced button is there :)).

[bond]

Originally posted by Tommy Carrot
What's the alternative? It's the only widely used API for encoding (except quicktime, but that doesn't count). The b-bframe handling is long time solved, not a real problem imo.not totally correct, there is a workaround avialable in virtualdub(mod) which makes b-frames work with vfw (in divx5 and xvid), but other vfw apps will not offer this workaround
therefore other companies like m$, offering a vfw version of wmv9, dont allow b-frames in their vfw codec, b-frames are only available in their wmencoder
(not to speak of that the avi container itself isnt able to handle b-frames without hacks, not to speak of other h.264 specific things, like markers)

an alternative would be a dshow encoder or even better a commandline encoder (dont understand whats wrong with this, real uses it for rv9 and it would not be that windows-centric as vfw and dshow)

but yes there definitely is the need for a better interface (hope gstreamer, or at least dshow, will become something widely usable in the future)

The only real handicap is the missing VFR ability, but for most of us it's not important at all.well simply not knowing it, or never having tested it doesnt mean that its not important ;)

Someone (perhaps Avery himself?) said Dshow is not exactly suitable for editingthe 3ivx guys say the contrary and from what avery wrote he had some very specific problems which made him drop the idea of implementing dshow, not altogether not solvable ones

and i'm strongly against the native MP4 streams since the total lack of support, so only VFW left.what is a native mp4 stream and what does it have to do with vfw?

[Tommy Carrot]

Originally posted by bond
not totally correct, there is a workaround avialable in virtualdub(mod) which makes b-frames work with vfw (in divx5 and xvid), but other vfw apps will not offer this workaround
therefore other companies like m$, offering a vfw version of wmv9, dont allow b-frames in their vfw codec, b-frames are only available in their wmencoder
(not to speak of that the avi container itself isnt able to handle b-frames without hacks, not to speak of other h.264 specific things, like markers)
Look, i didn't say the current solution is perfect, or elegant, but works without issues. And afaik those workarounds are not necessary for packed bitstreams anymore.
but yes there definitely is the need for a better interface (hope gstreamer, or at least dshow, will become something widely usable in the future)

Ok, i agree, but those are not really available right now, afaik no encoder app supports them.
what is a native mp4 stream and what does it have to do with vfw?
I mentioned that only because you always propagate using MP4 container for Mpeg4 codecs, and i had to express my disagreement. :p

[bond]

Originally posted by Tommy Carrot
Look, i didn't say the current solution is perfect, or elegant, but works without issues. And afaik those workarounds are not necessary for packed bitstreams anymore.hm not sure if packed bitstream avoids delay frames
still i doubt that the x264 vfw encoder writes packed bitstreams

I mentioned that only because you always propagate using MP4 container for Mpeg4 codecs, and i had to express my disagreement. :p hrhr
ok still vfw and mp4 dont exclude each other, you could also encode with a vfw encoder directly into mp4 (if there would exist a tool which could combine the two :D )

[SeeMoreDigital]

Originally posted by Tommy Carrot
...I mentioned that only because you always propagate using MP4 container for Mpeg4 codecs, and i had to express my disagreement. :p Your disagreement is duly noted!

Tommy, please list your grievances with the container?


Cheers

[Tommy Carrot]

Originally posted by bond
hm not sure if packed bitstream avoids delay frames
still i doubt that the x264 vfw encoder writes packed bitstreams

I though packed bitstream is exactly for avoiding delay. X264 doesn't have b-frames so far, but Videosoft's H.264 has, and it uses packed bitstream.

[Tommy Carrot]

Originally posted by SeeMoreDigital
Your disagreement is duly noted!

Tommy, please list your grievances with the container?


Not with the container, i know its superiority, but with the support for it. Until i have to use complicated methods to mux into it, and editing is impossible, i cannot see any point to use it.

[bond]

Originally posted by Tommy Carrot
I though packed bitstream is exactly for avoiding delay.hm i talked about an issue of vfw during encoding, not during decoding:
when encoding vfw uses always a 1 frame in, 1 frame out sheme, now with b-frames it gets 1 frame input but cant output 1 frame, therefore it outputs a so called "delay frame" (as it has to output something), which breaks the mpeg-4 compliance (yeah its nice ;) )
virtualdub(mod) automatically offers a workaround for this problem and detects these frames and drops them during encoding, but i doubt any other tool using vfw codecs will do this too, its a workaround nowhere specified...
vfw is simply outdated technology, not smart enough to handle b-frames on its own

X264 doesn't have b-frames so farhm according to fenrirs site b-frames are already "partially supported", whatever this means :D

but Videosoft's H.264 has, and it uses packed bitstream.where did you read this?

[Tommy Carrot]

Originally posted by bond
where did you read this?

I didn't read, i've tried. :D Packed bitstream has a peculiar characteristic in the virtualdub encoding status window which is easy to recognize: The frames in the places of b-frames are empty (dropped frames).

[Tommy Carrot]

I don't know if anyone cares, but here comes my opinions about the x264 in the latest ffdshow.

Well, the encoding speed improved a lot, more than 2x faster than the previous version, i can get about 8-12 fps on 720xXXX material, even using CABAC coder doesn't really slowing it down. The quality is improved as well, the motions are less annoying (though still not perfect), and the detail-preservation is also improved (in this regard it's already _much_ better than Xvid or any other mpeg4 codec).

Another thing: considering that this build and Justin's separated x264 build are using almost exactly the same codebase, the encoding-speed difference is huge, this is almost 5 times faster.

[ToiletDuck]

I care :cool: So let me get this strait. The new x264 codec has the same quality as xvid does now? The one i downloaded clips for a while back, while on its way, did not look so good.
Duck

[Tommy Carrot]

I would say that in certain aspects it's much better, in others it's worse. For example at the same bitrate x264 has much more details, the image is sharper (with disabled loop-filter, of course), etc. But... x264 has jumping blocks, the motion is not fluent, xvid is certainly more pleasing to the eye due to its much better ME algorithm. X264 is simply not mature yet, it still has some issues, but it also shows that H.264 has much bigger potential than mpeg4 ASP codecs.

[ToiletDuck]

Sweet. That is good to hear. I wish the jumpyness was taken care of. Any idea how long it will be till we see a usefull codec?
Duck

[Tommy Carrot]

Originally posted by ToiletDuck
Any idea how long it will be till we see a usefull codec?

I hope quite soon. :B The encoding speed is already getting to be acceptable, if the motion issues will be fixed i will permanently switch from xvid to x264.

[bond]

i still hope that the idea of using vfw will get dropped soon again, it simply doesnt handle the full feature set of what h.264 offers (for example non-adjacent references aso, not to speak of "basic" things which dont even work with mpeg-4 asp)

atm it may be an usefull solution but in the long run using vfw will mean that we cant use the full potential of what h.264 could be able to do
i still hope that we will see a nice commandline encoder with a nice gui!

[chilledoutuk]

I have been playing around with the h.264 encoder in the ffdshow for a few weeks getting good results with the latest version. One thing keeps bugging me when I analyse the encoded video in vdub keyframes only seem to be inserted when the predefined maximum distance is reached even when on 500. most codecs are very good at dedciding when to insert key frames but this seems to not be making any decisions at all.

has anyone else noticed this?

cheers

[Tommy Carrot]

Frametype-decision is not implemented yet.

[ToiletDuck]

well i'm not worried about encoding speeds. I've got a dual opteron setup and a media PC at 1.8ghz that can just go day and night. If the output is that good then the second they fix the jittering of the frames I'm sold.
Duck

[chilledoutuk]

I have found that if you uncheck all of the analyzer flags the dancing blocks on backgrounds is improved substantially.
give it a try

[ToiletDuck]

how does this adjust the quality of the output and also what equals substantially? As in normal smooth motion or still jittery?
Duck

[Tommy Carrot]

Originally posted by chilledoutuk
I have found that if you uncheck all of the analyzer flags the dancing blocks on backgrounds is improved substantially.
give it a try
Imo it improves that problem only slightly, the motions are still far from the smoothness of xvid, and the detail-level suffers a bit.

[bond]

Originally posted by Tommy Carrot
I don't know if anyone cares, but here comes my opinions about the x264 in the latest ffdshow.

Well, the encoding speed improved a lot, more than 2x faster than the previous version, i can get about 8-12 fps on 720xXXX material, even using CABAC coder doesn't really slowing it down. The quality is improved as well, the motions are less annoying (though still not perfect), and the detail-preservation is also improved (in this regard it's already _much_ better than Xvid or any other mpeg4 codec).thats my opinion too
i tried the ffdshow version myself now and i have to say x264 is
- fast, i got ~4fps (with the best xvid settings i get 7fps or so) - only this to "h.264 is slow"
- fucking damn great details, as TC said "_much_ better than xvid" (at least at 400kbps :D )

i tested the default settings (no cabac, no loop) with quant 13

considering current x264 as "preview" what h.264 could be able to do, i have to say it will clearly wipe away mpeg-4 asp or wmv9, rv9 aso...


btw: vfw has to die ;)

[ToiletDuck]

so what is it actually that makes it choppy? I don't understand. If there are 30 frames in a second and it takes each frame one by one and encodes them to the new .264 format then you should still have 30 frames for each second. So is it basically just the playback abilites that need to be played with? Would a supercomputer (Just tossing it out there) Play the files any smoother?
Duck

[Tommy Carrot]

Originally posted by ToiletDuck
so what is it actually that makes it choppy? I don't understand. If there are 30 frames in a second and it takes each frame one by one and encodes them to the new .264 format then you should still have 30 frames for each second. So is it basically just the playback abilites that need to be played with? Would a supercomputer (Just tossing it out there) Play the files any smoother?
Duck

Are you talking about the jumpy motions (sorry i could not decipher your post :))? I don't think the reason is the lack of computing power, instead it's the rawness of the codec. It's simply not tuned for quality yet. Remember opendivx? It had exactly the same behavior, it had jumpy blocks etc. Since then the quality of mpeg4 codecs improved much, and i believe this will happen with h.264 as well.

[ToiletDuck]

Is there anyway that you could send me a small test clip of something you have done? Like 20 seconds maybe? I have never seen .264 except for the Moonlight ones and they don't look the best.
Duck

[ToiletDuck]

edit

[SeeMoreDigital]

Originally posted by ToiletDuck
Is there anyway that you could send me a small test clip of something you have done? Like 20 seconds maybe? I have never seen .264 except for the Moonlight ones and they don't look the best.
Duck Yes, I would not mind seeing a small clip too!

It sounds like your efforts are really paying off. Please remind me, what container format(s) are you using?


Cheers

[Teegedeck]

Originally posted by Tommy Carrot
Are you talking about the jumpy motions (sorry i could not decipher your post :))? I don't think the reason is the lack of computing power, instead it's the rawness of the codec.
Seems a dshow problem that ATM only processing power can overcome; it looks good in VDub. The same clip that stutters on an XP-1800 plays smoothly on my A64. Same ffdshow versions, of course.

[springl]

Is overlay mixer "ticked" in configuration-->overlay-->output-->use overlay mixer?

[Tommy Carrot]

Originally posted by Teegedeck
Seems a dshow problem that ATM only processing power can overcome; it looks good in VDub. The same clip that stutters on an XP-1800 plays smoothly on my A64. Same ffdshow versions, of course.

That's strange, playing back a 720x288 video on my athlon 1700+ consumes less than 40% cpu-power, even with CABAC entropy coder.

Edit: With disabled loop filter obviously, but i don't imagine using it would make a huge performance hit.

[ToiletDuck]

@Teegedek your A64 can play any encoded .264 media smoothly like it normally should? I'm on dual opterons here. I wonder if I could :rolleyes: would be nice if there was a multithreaded player. Anywho if you can play the encoded media smoothly on your system and it looks much better than any other codec right now then I think I'm sold. I'm gonna have to start encoding everything over again in that format. Still, does anyone have test clips? The only downloadable ones I've seen aren't near as good as you guys make sound.

[Teegedeck]

Originally posted by Tommy Carrot
That's strange, playing back a 720x288 video on my athlon 1700+ consumes less than 40% cpu-power, even with CABAC entropy coder.

Edit: With disabled loop filter obviously, but i don't imagine using it would make a huge performance hit.
Well, my clip was more like 688x560. If I find some time today I'm gonna test a lower res.

@ToiletDuck; no codec should make the result look better than the original - so as long as you encode at a reasonable bitrate you won't have to encode anything again. And I doubt that ATM h.264 can look better than XviD at 2-Mbit/s with the SixOfNine matrix.

[P0l1m0rph1c]

Originally posted by SeeMoreDigital
Originally posted by ToiletDuck
Is there anyway that you could send me a small test clip of something you have done? Like 20 seconds maybe? I have never seen .264 except for the Moonlight ones and they don't look the best.
Duck

JM reference coder can also create .264...

EDIT: put wrong quote.. :eek:

[Tommy Carrot]

@ToiletDuck: the output format of x264 is .AVI, not .264. It's a VFW codec, just like xvid, you can use it the same way.

[Tommy Carrot]

Here (http://www.fw.hu/carrotland/x264.avi) is a short clip for those who are too lazy to try this codec themselves. :D

Considering that the bitrate is ridiculously low (253 kbps), i think it's pretty damn impressive, i would say that at low bitrates x264 might already be better than any other codec.

[SeeMoreDigital]

Originally posted by Tommy Carrot
Here (http://www.fw.hu/carrotland/x264.avi) is a short clip for those who are too lazy to try this codec themselves. :D Shit!

I've downloaded the file but I can't decode it. Can you direct me to the required DSdec filter please?

Sorry to be such an pain Tommy.


Cheers

[springl]

@SeeMoreDigital
ffdshow-->configuration-->codecs-->H.264-->libavcodec-->apply
enjoy :)

[SeeMoreDigital]

Originally posted by springl
@SeeMoreDigital
ffdshow-->configuration-->codecs-->H.264-->libavcodec-->apply
enjoy :) Is there a non ffdshow method?


Cheers

[springl]

If you have VSofts H.264 Video Codec installed you can try to change
4CC from h264 to vssh,it should work.

[Tommy Carrot]

Originally posted by SeeMoreDigital
Is there a non ffdshow method?


Cheers

What's wrong with ffdshow?

[SeeMoreDigital]

Originally posted by Tommy Carrot
What's wrong with ffdshow? Well, I'm using my old P3 800MHz machine to experiment with, and it would seem it does not like ffdshow all that much!

That might well be because I'm not using the correct type/version. What type/version are people using these days and I'll try again.


Cheers

[Sagittaire]

For best result with metric (PSNR & SSIM)

H264 encoding: ffdshow-20040508-p3.exe + 1 pass quant + Cabac + inloop + Hexagones ME + All Inter analyser flacs + All Intra analyser flacs + 10 refs frames

H264 decoding: H264 VSS

For H264 encoding with high bitrate and fast decoding/encoding

H264 encoding: ffdshow-20040508-p3.exe + 1 pass quant + Diamond ME + All Inter analyser flacs + All Intra analyser flacs + 2 refs frames

H264 decoding: H264 VSS

[Tommy Carrot]

@SeeMoreDigital: There is a specific P3 build from ffdshow on athos' page, you should try it, there is a slim chance it works. If not, try springl's advice.

@Sagittaire: In my experience the quality of latest version improved quite a lot, not to mention it's much faster compared to the version you used in you test.

[SeeMoreDigital]

Thanks Sagittaire, welcome back to the forum.

Of course, all the major builds are over at athos' site (http://athos.leffe.dnsalias.com/) now!

Well Tommy, I have to say I'm amazed that you can see anything like an moving image at these low bitrates. OK, it's not perfect on this slow PC but it's certainly watchable.

When you can get full moving 'video' at these bitrates, it makes you wonder how low the 'audio' will eventually go (which reminds me - I wonder what's happening with Nero's 'Parametric' audio?). I mean, we can't have the audio streams ending up bigger than the video... that would be absurd!


Cheers

[SeeMoreDigital]

Well here's a bloody weird one!

I fired up Tommy's x264.avi again in MPC, and got my usual slow motion playback. The phone rang, so I paused the encode. After about 10 mins I forgot about the paused encode and fired it up again in another MPC player (so I now have 2No MPC players running) and... would you believe it... the encode plays at the correct speed!

In fact as long as MPC is just 'open' ie: with no encode running in it. I can input Tommy's x264.avi encode, into any other media player and it plays perfectly!

What's happening here then?


Cheers

[bond]

Originally posted by Tommy Carrot
@ToiletDuck: the output format of x264 is .AVI, not .264. It's a VFW codec, just like xvid, you can use it the same way.not absolutely correct, the original codec from fenrir is a commandline encoder, which outputs .264 streams

someone else, not fenrir, added a vfw version for x264, which makes it possible to use it in virtualdub, which outputs avi

[Sagittaire]

@ Tommy Carrot

Latest version:
- Without hexagonal ME
- Without all inter and inter analyser flacs

[Nibor]

Originally posted by SeeMoreDigital
What's happening here then?
Hi, SeeMoreDigital!

I think this is because MPC ouptuts in Overlay ( anybody correct me if I'm wrong please ) per default.
And because there can be only 1 overlay output at the same time, another player will ouptut another playing file in software mode ( don't know how this is called correctly )!

When you do this, the video which plays in software mode is sometimes like if you would see that a new frame gets painted over an old one.
So e.g. at a moment the top half of the video is another frame than the bottom half, which makes the picture look 'shifted' !
You will notice that too when you watch QuickTime movies in MPC, because it can't output in Overlay so it outputs in software mode.

And now, that the x264 clip only plays fluently in software mode it means that it has difficulties to ouput in Overlay!
I don't know how this applies to ffdshow but it could be that there's a bug which is causing this.

Can anybody confirm what I wrote and maybe point to the correct expressions for Overlay / software mode? :)

- nibor -

[avih]

Tommy, this is an amazing encode :) wow

[gino25]

It' better the ffdshow-20040520-p3.exe instead of ffdshow-20040508-p3.exe ?

Because in the changelog I can read

2004-05-12 09:52 milan_cutka

* updated x264


Thank you.

P.s. Are there someone of the ffdshow/ffvfw developers that partecipate in doom9 forum?


Sorry for my english

[SeeMoreDigital]

Originally posted by gino25
Are there someone of the ffdshow/ffvfw developers that partecipate in doom9 forum? Well Athos is here. As you can see from his posts he's still very active: -

http://forum.doom9.org/search.php?s=&action=showresults&searchid=483637


Cheers

[Tommy Carrot]

Originally posted by gino25
It' better the ffdshow-20040520-p3.exe instead of ffdshow-20040508-p3.exe ?


As i said a few times: yes, the quality (not to mention the speed) of the new version is improved a lot, the image is sharper and has more details. I don't know the reason why Sagittaire uses the older build in his tests, it's inferior in every aspect.

@Avih: Yes, H.264 is very impressive at low bitrates. :) There are issues with the high quality performance yet, with disabled in-loop filter - which is a must for high quality encodes - there are artifacts and blocks. I hope that will be fixed soon, then h.264 can begin the world domination. :D

[gino25]

thank you

[SeeMoreDigital]

I've been able to play the file now, with my Xcard and view the results on my big screen.

The overall results are very impressive indeed considering the bitrate.

I notice from the encode that your're in a 25fps land. I would really like to see what this encode would look like with more pixels.

Could you by any chance generate and post an 1:1 anamorphicly cropped encode using 720x432 pixels?


Sorry to be so cheeky Tommy

[Tommy Carrot]

Originally posted by SeeMoreDigital
Could you by any chance generate and post an 1:1 anamorphicly cropped encode using 720x432 pixels?


If you would tell me how to do it, i may consider it. :)

[SeeMoreDigital]

Originally posted by Tommy Carrot
If you would tell me how to do it, i may consider it. :) Well I suppose it depends on your 'front end' encoding application (which Gspot says is VirtualDub).

So I guess as long as you keep your output setting the same as your input (ie: 1:1) and just crop away the mattes, you should arrive at 432 pixels for the height (around 4 image lines of pixels will also disappear). The width should be unaffected.


Cheers

[avih]

Tommy, i just downloaded every possible h264 implementation (x.264, ffdshow which i already have, skal's code, etc).

if i want to be able to play it, i can only encode with x.264 (/justin) without cabac. i had no luck with ffdshow with/out cabac/loop. the x.264 loop filter is good imho (at least when played in ffdshow). i'm using 20040518 iirc (i'm at work now). but overall, definately something to look forward to.

which encoder did u use? what version, and what options?

thx
avih

[Tommy Carrot]

@SeeMoreDigital: Ok, i finished it, the resolution is 720x416. I made 2 encodings.
The first (http://www.fw.hu/carrotland/x264_am2.avi) is a medium bitrate encoding, the bitrate is 505 kbps. It's slightly lesser compressed than my first clip, because with the same settings the result was very ugly.

The second (http://www.fw.hu/carrotland/x264_hiq.avi) is an attempt to make a higher quality encoding with x264 (although it's still not perfect, the image is littered with small blocks). The bitrate is 995 kbps, and the loopfilter is disabled (otherwise it would look too smooth).

@Avih: i'm using ffdshow 20040514 build for both encoding and decoding (i didn't try the latest build, but it should behave identical, because the h.264 code is unchanged). Every option works, the only restriction is that you cannot have CABAC and inter analizer flag PSUB8x8 enabled at the same time, because the result is garbled then.

[SeeMoreDigital]

Originally posted by Tommy Carrot
@SeeMoreDigital: Ok, i finished it, the resolution is 720x416. I made 2 encodings.
The first (http://www.fw.hu/carrotland/x264_am2.avi) is a medium bitrate encoding, the bitrate is 505 kbps. It's slightly lesser compressed than my first clip, because with the same settings the result was very ugly. First, please forgive me, as I'm not going to talk about the 995kbps encode!

However, given that the image pixel size is 'the size that it is' the 505kbps encode actually looks very good on my HiDef 768h 42" plasma display.

Can you confirm how you went about encoding it?
Is the source just 88 seconds long?
Is your encode a 1pass or 2pass file?
Did you just encode and upload this short clip, or has this clip been cut from a larger encode?

I have to ask because I have tried generating the same 2,019 frames, with XviD's new build (using 2 passes). And can't get anywhere close!


Cheers

[Tommy Carrot]

Originally posted by SeeMoreDigital

Is the source just 88 seconds long?
Yes, it's a fragment of a VOB-file which i keeped on my HDD long ago for codec-testing purposes.

Is your encode a 1pass or 2pass file?
x264 has only fixed quantizer mode.

Did you just encode and upload this short clip, or has this clip been cut from a larger encode?
As i said, these are just short clips, only for quality-evaluations. Using this codec for full movie encodings doesn't makes too much sense yet, because it doesn't have rate-control, and still has some issues.

[ToiletDuck]

call be newb but what must I install to make this play? I have the moonlight player but doesnt work.

[SeeMoreDigital]

Originally posted by Tommy Carrot
Yes, it's a fragment of a VOB-file which i keeped on my HDD long ago for codec-testing purposes....x264 has only fixed quantizer mode. Well then, these encodes really do go to show how good H.264 will be when it's officially released!

I have to admit I've been somewhat impressed with VP6 in 1pass mode but your H.264 encodes paint another picture! Thanks very much for satisfying my curiosity.


Cheers Tommy

[Latexxx]

Originally posted by ToiletDuck
call be newb but what must I install to make this play? I have the moonlight player but doesnt work.
Ffdshow. You need to enable h264 playback from its settings to make it play h264.

[Neo Neko]

Wow X264 is already quite good! And it is barely in it's first few working releases! If this project keeps getting work I think the next codec comparison could be a shutout! I wonder if it was incorporated into/with Xvid if that would help.

A fun little NTSC sample (http://neoneko.ath.cx/hs.mkv) for you all to play with.

[Blue_MiSfit]

holy god thats amazing... no macroblocking at less than 300 kbit full (cropped) res.

I'm scared.

What I DONT like about it is the (over) smoothing, and this wierd almost shimmering effect. However, it doesnt appear to be tied to lots of motion.

I am really imressed with the lack of haloing/blocking usually associated with low bitrate at high resolution with lots of motion.

Cant wait until h264 gets to a point where I can start using it for my backups :D

peace
~misfit

[unmei]

wowie!
thanks neo neko, your sample soo dragged me to the h.264 side. I still don't know what was the problem with me and the vanguard h.264 or that other command line encoder, but with the ffdshow h.264 encoder i finally can encode "good" samples in h.264 as well.

I don't doubt it any longer, h.264 will reach world domination. It seems to me the code by ffmpeg team is worlds apart from what the commercial ones can show - GOOD, that warms my Xvid spoiled heart.

[SeeMoreDigital]

Yep, all we need now is to see some H.264 streams in an MP4 container instead of AVI :D


Cheers

[unmei]

hmm i always thought the *.mkv extension were used for matroska files :p
But i know that is not what you meant, you want to see it it's native container..

[Sagittaire]

For H264 ffvfw tester

the best quality for you (not for speed) ...
- Best ffdshow version?
- Best H264 setting?
- Best decodeur for H264 ffvfw?

thx

[unmei]

@sagittaire
eeeek! "best"!?!
and what's with the question? does the latest ffdshow not run on your machine or do you have any other reason to think a older version could be better?

About the settings i'm unsure ..just had to experience ticking all the analyser checkboxes is no good idea, it gave hell of a block storm, so i left it at default for the following tests. Beside that, there is not so much settings to choose from. I always used cabac so i don't know how the other method would perform. For in-loop, it sometimes turned it sometimes off but i did not investigate the effect directly and there was no effect that would immediately jump at me without testing that explicitely. The max reference frames setting can savely be turned up to about 10, but i did not see a drastic increase in quality - like in-loop i did no direct tests to see its effect.
I mainly tried a bit to see what the encodes look at different quantisers and what the resulting bitrate was compared to the produced quality.

[aketon]

Hello!

Is there any site that has a compiled version of the x264 codec??? I don't want ffdshow in my machine because it has a loooots of settings to configure! What I really want is a simple directshow codec! The only one I found so far is from this site http://www.geocities.com/justinclaybaby/x264.htm ! Is it safe to use it? I read somewhere in the previous posts that it isn't as fast as the ffdshow!

Thanks for reading my post!

Sorry for my bad english! (I hope that there isn't too many mistakes)

BYE

[Tommy Carrot]

@Sagittaire: Yes, the latest (version) is the greatest. :D
In-loop filtering makes the codec behaving like RealVideo: no artifacts but smooth and blurry image. Imo it will be good for low bitrate encodings, but not for normal dvd-rips and high quality encodings.
I would recommend using CABAC (cca. 10% bitrate gain without any quality loss), and every analizer flag except inter PSUB8x8 (which cannot be decoded properly yet due to a bug in libavcodec).

[Tommy Carrot]

Originally posted by aketon
Hello!

Is there any site that has a compiled version of the x264 codec??? I don't want ffdshow in my machine because it has a loooots of settings to configure! What I really want is a simple directshow codec! The only one I found so far is from this site http://www.geocities.com/justinclaybaby/x264.htm ! Is it safe to use it? I read somewhere in the previous posts that it isn't as fast as the ffdshow!


It's much slower and not configurable at all, only works with the default settings (loop filter on, constant quant 26, etc).

edit: I just saw that there are newer versions since the one i tried, so perhaps the mentioned issues are not valid anymore.

[unmei]

currently watching:
El-Hazard ep 23
container mkv
subtitles ssa
audio HE-AAC 48kHz stereo 32kbit/s
video 688x544 ("anamporph" 4:3 by mkv), 25fps FFDshow h.264 (x264?)

h.264 settings
Q18, cabac, no in-loop, default analyser flags, 10 reference frames
encoding time 107 min on athlon XP 2600+ (heavy avisynth script)
resulting bitrate 576kbit/s

total filesize: 83.8 MB (for 19:04!)

almost plays on pentium 3 /600
uses 50% CPU on said Athlon (a Xvid with heavy B-frame/ASP stuff uses ca 35%)

Quality: i would already prefer it over a Xvid or RV encode at the same low bitrate. The pencil strokes are a bit fuzzy especially on the chin (or just places where there is a black stroke with same color on both sides). Also there some smearing/blocks/general unsharpness on the sky. It's probably known to everyone but me, anyway, it seems there is not frame-type decision at all - at least it seemed to me I frames were only inserted after the max distance was reached.

http://www.hta-bi.bfh.ch/~seilf/x264.blocksky.jpg
PNG (315kb) (http://www.hta-bi.bfh.ch/~seilf/x264.blocksky.png)

[Sagittaire]

For low bitrate inloop is an obligatory option: it's an in loop deblocker during encoding.

inloop and H264 for low bitrate it's like SBR and AAC for low bitrate ... it's obligatory. For exemple RV10 in 2 pass use Inloop quant threshold ... ;-)

[unmei]

In-loop filtering makes the codec behaving like RealVideo: no artifacts but smooth and blurry image.

So either this inloop filtering has to become much better, or it's no option for me. Even with this frame to illustrate the annoying blocks in the sky - i prefer it by far over the RealVideo characteristics.

PS:
with same comp, same h.264 settings, but just TomsMoComp and Crop in the avisynth script encoding reaches +/- 9 fps (53min compared to the 107 with all the filters used above)

[Tommy Carrot]

I've tried Justin's latest build, and the problems i mentioned before are mostly fixed, its speed, quality and functionality are similar to the ffdshow encoder, so if someone doesn't want to mess with ffdshow, he can use this standalone build instead.

[avih]

tommy, iirc, i couldn't decode .264 clips with it (u might wanna mess with the fourcc though)

[Tommy Carrot]

Originally posted by avih
tommy, iirc, i couldn't decode .264 clips with it (u might wanna mess with the fourcc though)

Yupp, i forgot to mention that you have to set the fourcc to 'h264' in the advanced tab to play it back with ffdshow.

[aketon]

After some tests I made, it seems that ffdshow has a better x264 codec than the one in the http://www.geocities.com/justinclaybaby/x264.htm ! I can 't understand why they have such a big difference in guality! Ffdshow encodes in lower bitrate it still has better quality than the other one! I encoded 1 minute of the same clip and ffdsow gave me 2 megs and the other one gave me 4.5 megs! Ffdshow created a clip 2.5 megs smaller and it still had much better quality! The other one had to many blocks moving like crazy!
Does anybody knows why did this thing happened???

[708145]

[ffdshow-x264 looks better than x264] The other one had to many blocks moving like crazy! Does anybody knows why did this thing happened???

I tested both codecs as well. Make sure to use the same options for both regarding in-loop filtering.
Also for play back, I had to convert to huff-yuv first since hi-bitrate playback of h264 was not possible on my axp1800.-(
but I guess this lost me some post processing :confused:

I'll put those clips online soon.

T0B1A5

[bond]

Originally posted by avih
tommy, iirc, i couldn't decode .264 clips with it (u might wanna mess with the fourcc though)hm, .264 are raw bitstreams, better not use this expression for h.264 streams placed in a container :)

raw bitstreams can be played using the mainconcept and moonlight filterset btw...

[aketon]

Can anyone please give a short explanation about the ffdshow's x264 options? Especially for what exactly are "CABAC" and "Max. number of reference frames"!!

Thanks!
BYE

[708145]

My shot:

CABAC: Huffman replacement using arithmetic coding. More expensive but also smaller bitstream (~10% according to some posts). I never tried without.

Max no ref frames: Each predicted frame can use data from up to this specified no. of frames. higher no. increases memory footprint of encoder and decoder, but should help compression. For comparison:
In MPEG4ASP it is 1 for p_frames and 2 for b_frames. I used values from 3 to 5. But will experiment with higher numbers soon.

bis besser,
T0B1A5

[708145]

Here is the location of some of my codec experiments.
Very slow motion scenes from phenonemon encoded with different codecs, resolutions, bitrates... well filenames speak for themselves.

http://www.ra.informatik.uni-stuttgart.de/~bergmats/clips/

bis besser,
T0B1A5

[aketon]

Thanks for the info 708145!!!

BYE

[Sagittaire]

little H264 ffdshow test:

Don't use H264 ffdshow decodeur: decodeur is incomplete. Use VSS decodeur

ffdshow-20040520

http://jfl1974.free.fr/Video/ffdshow-20040520.jpg

quant 15 without inloop (http://jfl1974.free.fr/Video/H264-ffdshow-20040520-cabac.avi): 4866 Ko

quant 15 with inloop (http://jfl1974.free.fr/Video/H264-ffdshow-20040520-cabac-inloop.avi): 4818 Ko


ffdshow-20040508

http://jfl1974.free.fr/Video/ffdshow-20040508.jpg

quant 15 without inloop (http://jfl1974.free.fr/Video/H264-ffdshow-20040508-cabac.avi): 4654 Ko

quant 15 with inloop (http://jfl1974.free.fr/Video/H264-ffdshow-20040508-cabac-inloop.avi): 4614 Ko

In lastest ffvfw version only the functions correctly decoded by ffdshow are available. H264 q15 size is comparable with XviD q4 or compressibility 50% ...

[SeeMoreDigital]

Hi Sagittaire,

There's no doubt that the encodes you've generated with ffdshow-20040520 look very good indeed.

That said, how much success have you had using lower bitrates, ie: below 700kbps?


Hi 708145,

I downloaded a couple of your encodes, including your 14.9MB clip. However, after a minute or so, it crashes all the media players I tried.


Cheers

[aketon]

Hello Sagittaire! You have very interesting clips (about quality) there! But you've done a mistake when you wrote over the second picture of the h.264 properties 20040520! You should wrote 20040508!

BYE!

[ToiletDuck]

............. Somebody uses windowsXP PLUS!

[708145]

Originally posted by SeeMoreDigital


I downloaded a couple of your encodes, including your 14.9MB clip. However, after a minute or so, it crashes all the media players I tried.



Oh, bad to hear that. :(
But as written above, I couldn't play those high bitrate clips myself directly without artifacts and dropped frames.
So I converted to huffyuv first.
I have to wait for further codec speed improvements for direct playback.


Just checked with 20040520 ffdshow playback -> no crash, no dropped frames BUT several wrong frames! maybe some blocks were skipped?


bis besser,
T0B1A5

[oddball]

Just tried a few test clips. Interesting. Blocking seems to have been changed for stepping or somesuch. Blocks tend to blend into each other. I can definitely still see the artefacts though. It's not as unpleasant as MPEG4 blocking though IMO.

Impressed? Not really. I was expecting more.

[aketon]

Xvid seems to be better than x264 right now! After some tests I've done at 300 kbps on a video with image resolution at 640x336, Xvid was a little bit better! And that was because I used b-frames! Without b-frames x264 is by far much better! I hope that they are going to implement b-frames soon in their codec!


Sorry for my bad english!

BYE!!!!!!

[CruNcher]

gee ffdshows x264 implementation is really neat much better then Vanguards at least, even with no Ratecontroll and b-frames cabac really pushes it, but yeah XviD is still more precise because of it's marvelous RC and B-frames implemantation hopefully we see alot of new enahncements to x264 ahh and their is still Skals codec hopefully to come :)

[Blue_MiSfit]

h264 seems to crumble at the feet of xvid in the following setup:

ffdshow h264 encoder 20040520
all motion comp settings enabled, 15 max ref frames
quant 10

frame 990-2990 lord of the rings return of the king
400x160 resolution (wierd I know)

xvid setup:
256kbit - 2 pass
h263
qpel
gmc
adaptive quant
bvops @ 4/1/1
sensitivity @ 15
chroma motion
chroma optimizer
trellis
vhq=4
msp=6

the file sizes were as follows:
Xvid: 1840 kb
H264: 13346 kb !!

I could (unfortunatley) not get any screenshots due to overlay problems, but I can honestly say that q10 was as high as I could compress it before it began ugly blocking and artifacting.

XviD on the other harnd scaled marvelously, and even looks better than h264

it would indeed appear that there is no rate control yet ;)
looks nice at any rate.

[gino25]

i have red that the new version of videolan has an integrate h264 codec.

Have you tried this?

[Sagittaire]

For Bitrate
quant 12 for H264 ~ quant 2 for XviD or compressibility 100%
quant 13 for H264 ~ quant 3 for XviD or compressibility 75%
quant 15 for H264 ~ quant 4 for XviD or compressibility 50%
quant 18 for H264 ~ quant 8 for XviD or compressibility 25%

quant N for XviD ~ quant N+10 for H264 in [25%-100%] compressibility interval for XviD (with H263 and HVS matrix)

quant for MPEG4 V10 (H264) or RV10 and quant for MPEG4 V2 (XviD or DivX) aren't equivalent ... and use VSS decodeur not H264 ffdshow decodeur

[Tommy Carrot]

Don't forget that the quantizers in the ffdshow are not the real quantizers, because it sets the quantizers in a 31 step slider, but h.264 has 51 separated quantizer value. You can check the real quantizers with the OSD function of the ffdshow. Justin's build sets the real quantizers.

If i remember correctly, the logic behind the h.264 quantizers is: if you increase the quantizer with 5, you'll get about half bitrate. quant+10 gives 1/4, quant+15 gives 1/8 bitrate, etc.

[skal]

Tommy:


actually, the step size is '6'.
Which means that the quality degrades *exponentially*
with QP, btw. And not linearily, like MPEG4.

Here's a (strange) drawing of QP (either MPEG4 or H264) as a
function of PSNR (for two random sequences i don't recall which
ones).

http://skal.planet-d.net/QP.gif


How to use it? Well, say you want a PSNR of 40,
then roughly, following the vertical line, it says
that QP should be 28-30 for h264 and 3-4 for MPEG4.
(no guaranty of course).

Note: Qp=26..30 will be the usual good range for h264.
Note2: you see? The QP=func(PSNR) is linear! That's the
magic taking the log (<=>PSNR) of an exponential ;)

Skal

[SeeMoreDigital]

I would love to know how good H.264 encodes would look under 2pass conditions!


Cheers

[aketon]

For me Justin's x264 seems to be bugged!
For my encodings I use ffdshow for now (as there is not any other codec that works as good as it)!
My options (for now at least) are

Quantizer 16

Generic
--------
Maximum I frame interval 300
Minimum I frame interval 1

CABAC ON
LOOP FILTER OFF


Motion estimation
------------------
Intra analyzer flags:
I4x4 ON
PSUB16x16 ON
PSUB8x8 ON

Inter analyzer flags:
I4x4 ON
PSUB16x16 ON
PSUB8x8 OFF

Max. number of reference frames 10


With these settings I have great quality for any video!

[CruNcher]

http://cruncher.mufflastig.com/XviD/samples/

here you can see what i meant with it's still not upto but as you see their is near no ringing (x264) short transforms this was done with a Q31 with x264 and 2pass 1000 kbps for the XviD b-frames ect :)
Btw both are by factor 5x compressed of the orgiginal (yada) :D took 4 times longer to achive that then the playtime goes but it's worth it ;) ahh and you will also see Noise in the XviD hehe thats source noise JUP that's why it's called Extra_Detail :)

@Skal
hmm what was your expirience with Hadamard ? i see it gives a speed bost in the H264 reference Encoder couldn't it have the same effect for XviD ?

[aketon]

I've just found out that ffdshow was the reason for not playing correctly the video created with Justin's x264 codec! When I tried to play it with VSS decoder, everything went fine! Justin's x264 seems to be a little bit faster also!!!

[Tommy Carrot]

Originally posted by aketon
I've just found out that ffdshow was the reason for not playing correctly the video created with Justin's x264 codec! When I tried to play it with VSS decoder, everything went fine! Justin's x264 seems to be a little bit faster also!!!

This was already mentioned a few times in this thread. Ffdshow cannot decode the clip properly when CABAC and Psub8x8 was used at the same time at encoding. In Justin's build Psub8x8 flag is on defaultly and cannot be switched off.

[slavickas]

Originally posted by gino25
i have red that the new version of videolan has an integrate h264 codec.

Have you tried this?

it's same x264 (because x264 main developer is one of vlc devs)
and public vlc 0.7.2 windows release i think don't have x264 compiled

[SeeMoreDigital]

Originally posted by gino25
i have red that the new version of videolan has an integrate h264 codec.

Have you tried this? Does it come with both an encoder and decoder then?


Cheers

[unmei]

blue misfit wrote
I could (unfortunatley) not get any screenshots due to overlay problems

this is how i did my screenshot:
.AVS file:
DirectShowSource("x264test.mkv")

..and opened that in VDM, shift+1 to save as png.
If there are any quality concerns about this method, please let me know. But else i hope it helps so we can see all the screenshots of interest :)

[virus]

I have a question for those of you who know the specs (I've got the draft for H.264 lying somewhere in my HD but haven't read it yet). Is it allowed to integrate an MPEG-4 Visual (Part 2) codec with H.264 functionalities?
Example: adding CABAC to XviD and produce a codec which uses a mixture of features from both Part 2 and Part 10 (using H.264 bitstream syntax of course).
In other words: is an H.264 bitstream "backward compatible", at least to some extent? The answer should be 'yes', since they're both MPEG-4, but given that H.264 is substantially different from Visual, I'm just wondering if that's the case...

[Sagittaire]

I have a question for those of you who know the specs (I've got the draft for H.264 lying somewhere in my HD but haven't read it yet). Is it allowed to integrate an MPEG-4 Visual (Part 2) codec with H.264 functionalities?
I think it's possible: for exemple MPEG4-ffvfw use inloop ...

produce a codec which uses a mixture of features from both Part 2 and Part 10
use the RV10: I think it's an intermediate codec between the MPEG4 v2 and the MPEG v10 ... ;)

[skal]

Hi Cruncher,


regarding the adequacy of SAD/SSD/HSAD,
there's two problems involved: Are you
using this metric to evaluate distortion?
or rate? Or both, weighted (RD-optim)?

Let's have a look at the easier part: rate.

Let's take a predicted intra block,
evaluate the diff between prediction and
original picture with either SAD/SSD/HSAD.
Then let's quantize this diff, and code
the residual.
Here are some curves showing the length (in
bits) of the coded residuals as a function
of the metric's value (using CAVLC, QP=10):

Using SAD:

http://skal.planet-d.net/sad.gif

Using SSD:

http://skal.planet-d.net/ssd.gif

Using HSAD:

http://skal.planet-d.net/hsad.gif


One can see that the result is pretty
equivalent: the higher the metric's value,
the harder to code. I'd favor the HSAD,
since there's less dispersion in the
expectation of the coded length. The
gaussian is sharper.
But if you are to use HSAD, you'd better
use the real H264's transform which is
close to HSAD.
Here's the function of the residual's
coded length as a function of the sum of
the levels (that is using the real H264
transform instead of SAD):

http://skal.planet-d.net/level.gif

One can see that's it's even better,
and not much costly compared to HSAD
(but more than simply using SAD,
nevertheless).

Now, all this being said, i'd recommend
to tabulate the coded bit length as a
function of SAD for cheap rate evaluation.
It's easy, the curves look like a log
curve, and it's pretty reliable for a
fast rate evaluation.



Now the harder part: what is the relation
between computed SAD and the final distortion
(once fwd transformed, quantized, dequantized,
bwd transformed)?

Well, almost none.

Or at least not much more than the
relationship between:

F(\sum_i x_i/Q) and \sum_i F(x_i/Q)

where F(x) means the fractional part of x.

[ach! this looks like dynamic systems/ergodic
theory!:]


The equality holds mainly if all the x_i are
less than Q/N!

So yes, for high quant, the SAD between
predictions and original picture is a pretty
good measure of the final distortion. This
works perfectly for a SKIP block, e.g. ;)

But otherwise, it's hard to guess what will
the final distortion be, just by looking at
the original SAD/SSD/HSAD/whatever.

bye!
Skal

[shlezman]

@ Skal
Interesting graphs, sadly the conclusions are inconclusive :)
a few quick Questions :
Any results for inter ?
Ever tried a combination of several metrices ? one metric might compensate over the other, producing a smaller variance.

[aketon]

It seems that I had a problem using avs2avi and x264 - H264/AVC codec! Whenever I am trying to encode, it gives me the follow message:
ICSeqCompressFrameStart failed : The operation completed successfully.
Do you know why I have this problem? I thing that it might be a YV12 problem! But as a MPEG4 codec it is supposed to accept YV12! There no problem when I use ffdshow!

BYE!

[skal]

@shlezman:


For inter, it's almost the same except that
you have much more prediction "mode" available
(one for each motion vector + ref +...)

I've got no definite conclusion, but i can
give you some hints:

Using only SAD as metric results in ~0.2 - 0.5 dB
loss compared to real RD-opt evaluation. This is
too much for my taste. But on the other hand, it's
more than 4x faster.

Combining several metrics is an interesting idea,
but the problem still is the same: you have
uncertainty attached the final rate evaluation,
and this can ruin the mode decision, especially
at low bitrate.

Now the top-secret trick is: use SAD to pick up
few candidate prediction modes, suitable for a
real RD-opt measure. Most of the time, doing so,
you rule out many bad modes. Combined with good
thresholding, speed-up can be consequent.

bye!
Skal

[bobololo]

Originally posted by Sagittaire
I think it's possible: for exemple MPEG4-ffvfw use inloop ...

Unfortunately, H.264 and mpeg-4 (part 2) are definitely very different and there is no mean to exploit h.264 tools in part 2 encoder.

-- bobololo

[bond]

Originally posted by virus
I have a question for those of you who know the specs (I've got the draft for H.264 lying somewhere in my HD but haven't read it yet).have a look at my mpeg-4 info sticky

Originally posted by bobololo
Unfortunately, H.264 and mpeg-4 (part 2) are definitely very different and there is no mean to exploit h.264 tools in part 2 encoder.hm afaik xvids vhq mode is a backported rate distortion from avc

[virus]

Originally posted by bond
have a look at my mpeg-4 info sticky
I did. But, besides the graph with the differences between the standards, I was unable to find a clear-cut answer to that specific question... sorry, I probably overlooked something. But I'm inclined to trust bobololo on that: you simply cannot make a "transitional" codec it seems.


hm afaik xvids vhq mode is a backported rate distortion from avc
mmhhh... I'm a bit doubtful on that :)
Not really sure that H.264 RD-Opt is _exactly_ the same as XviD VHQ.
The underlying concept may be the same, but the actual implementation may differ I think. Probably sysKin can answer much better on that.

[Manao]

hm afaik xvids vhq mode is a backported rate distortion from avcPerhaps, but nobody forbids you from doing so, because you do not change the decoding process by trying to choose the best MV / quantizer at encoding.

[bond]

Originally posted by virus
I did. But, besides the graph with the differences between the standardsi mean you asked for a draft of the h.264 standard, you will find a link to it in my sticky

[virus]

Originally posted by bond
i mean you asked for a draft of the h.264 standard, you will find a link to it in my sticky
sorry for not making that clearer before, but I said "I've got the draft (already), but haven't read it yet" (lazyness :rolleyes:, it's quite big...). Thanks for the help anyway.

[bobololo]

Originally posted by bond
have a look at my mpeg-4 info sticky

hm afaik xvids vhq mode is a backported rate distortion from avc

The Rate-Distorsion Optimisation (RDO) isn't a coding tool defined by the spec (like bframe, inloop deblocking filter, cabac, etc.). It's a process that helps the encoder to take the best decision from a coding efficiency point of view.

For instance, given a macroblock from a picture and a given quantizer step, the encoder can code it as INTRA or INTER. The RDO process evaluates that INTRA coding would require let's say 100 bits and involves a distorsion of 35 dB. Beside, when coded as INTER, the required bits is 20 and distorsion is 34.5 dB. In such case, the RDO process tells the encoder that the coding cost of INTRA is much higher than INTER's and therefore INTER coding should be choosen even its distorsion is higher.

As you can see, this process doesn't affect really the tools provided by the specs. It can be used by any encoders as soon as it need to take optimal decisions. RDO is actually is also used in high end MPEG-2 broadcast encoders. Their performance is much higher than "traditional" mpeg-2 encoders available on PC.

-- bobololo

[aketon]

What is the "Max. number of reference frames" in ffdshow that you are usually using???

[unmei]

i used 10 for some tests and 15 for others. If you enter 16 or more the box turns red so i guess you shouldn't do that.
Also i could imagine higher numbers take more processor power or memory to decode, so if you use high values and get playback problems it might be worth trying with lower numbers.

[bond]

Originally posted by aketon
What is the "Max. number of reference frames" in ffdshow that you are usually using???i assume this value defines the number of previous frames used for inter motion search, in the reference h.264 encoder its set to 5 by default (and it seems to only allow a range from 1-5)
afaik mpeg-4 asp only allows max. 1 reference, so this feature is a nice example where avc simply expands the possibilites of the tools already existing in mpeg-4 asp

[unmei]

afaik mpeg-4 asp only allows max. 1 reference

you should make that 2 in the case of B-frames i think.

[bond]

Originally posted by unmei
you should make that 2 in the case of B-frames i think. no, this has nothing to do with b-frames!

[unmei]

hmm my thought was, it looks at the past and the future neighbor P- or I- frame, but maybe i'm really completely off track ..then can you clarify what it actually is.

[virus]

Originally posted by bond
afaik mpeg-4 asp only allows max. 1 reference (not sure tough) yeah, and 2 for B-frames of course ;)
I fail to see how using 10 reference frames may help in the coding of a macroblock, though. Because 10 references = 10 motion vectors, no? That's a really big overhead, I think.
Nonetheless 2 o 3 seems (to me) reasonable, as a method to reduce the influence of noise in the prediction step.

Someone smarter than me can explain that stuff? :D

[Tommy Carrot]

I think it means that it searches for the most similar frame in the previous x frames, and chooses it as the reference frame. This ability is particularly useful at flashing, where the previous frame is highly different, but there is a frame before that which is quite similar, so the motion information can be much smaller.

[aketon]

So, nobody is sure about what "Max. number of reference frames" really is!!!:rolleyes:
Although, I believe that 10 is a very good choice!:)

[virus]

Originally posted by Tommy Carrot
I think it means that it searches for the most similar frame in the previous x frames, and chooses it as the reference frame.Well, in that case the "number of reference frames" will be 1, freely chosen and not necessarily the previous I/P frame, but still only 1. Wouldn't be better to search for your reference block in many different frames (that is, doing what you said but on a per-block basis)?

Anyway, maybe I'm mixing up the concepts of "number of frames from which you can draw reference macroblocks" and "number of macroblocks blended to form the prediction (and thus needing a MV each)" :rolleyes:

[Tommy Carrot]

Originally posted by virus
Well, in that case the "number of reference frames" will be 1, freely chosen and not necessarily the previous I/P frame, but still only 1. Wouldn't be better to search for your reference block in many different frames (that is, doing what you said but on a per-block basis)?

Anyway, maybe I'm mixing up the concepts of "number of frames from which you can draw reference macroblocks" and "number of macroblocks blended to form the prediction (and thus needing a MV each)" :rolleyes:

Nah, i think your idea would introduce a lot of overhead, so in most cases it wouldn't help at all. I think it refers to the pile of the potential frames wherefrom it can choose the closest match.

[virus]

Originally posted by Tommy Carrot
i think your idea would introduce a lot of overhead:confused:
Why? You only need to add a single number to every macroblock representation (identifying which frame contains your ref. block). Considering the amount of stuff coded for each block, like MB type, the MV (2 components, dx & dy) and the DCT coefficients (which, on a 16x16 macroblock, are 256 minus the trailing ones which are 0 in every 8x8 block), adding a single number doesn't seem a big overhead to me...

[bond]

Originally posted by aketon
So, nobody is sure about what "Max. number of reference frames" really is!!!:rolleyes: well as i said before i am 99% sure that it is the number of previous frames used for inter motion search

to answer, how this exactly works, will need a h.264 developer, like bobololo, i think :D

[shlezman]

To fix the confussion about the reference frames :

The encoder can inter-predict (motion compensate) each block (8x8) from any of the frames buffered in the frame-buffer, thus creating a very large space to predict from, compared to MPEG4 with a single frame of history.

The frame buffer consists of two parts, the short-term buffer which stores only the LAST X decoded frames and the long-term buffer can be used to buffer frames for unlimited time.

The frame buffer is defined in a very flexible manner so that many other applications can be done with it.

The larger the frame buffer is, the more memory the decoder uses. More then 4 shrt-term frames (which are the ones supported by x.264) is usually unnecessary.

[aketon]

After some tests, I am 100% sure about what "Max. number Reference Frames" really do! I made an Image Sequence of 100 frames! Then I start to blank every sixth frame! Then when I made an encode with ffdshow, the first time I used 1 Reference Frame and the second time I used 6 Reference Frames! And here are the results!

1 Reference Frame
244 kb

6 Reference Frames
146 kb

Really cool!!!! Right???????:D

[Tommy Carrot]

I made two encoding with 1 and 10 reference frames (other than that they have identical settings), and to my surprise the first encoding had smaller filesize (34,208kb vs. 35,852kb), and also the image was slightly sharper. Apparently the multiple reference frames option is not perfect in x264.

[virus]

Here's my test with "max number of ref. frames".

ffdshow-20040501 (warning, not the latest x264 revision)
500 frames, 560x304 @ 25fps, quant 13
default stuff + CABAC

max # ref. frames - bitrate:
1: 670 kbps
2: 662 kbps
3: 655 kbps
4: 654 kbps
5: 653 kbps
6: 653 kbps
7: 653 kbps
8: 653 kbps

Can you see a pattern? :D

virus

[aketon]

I've got "almost" the same strange results with virus!

I tried all the possible values for "Max. Number Of Reference Frames" in ffdsow 20040520!

CABAC ON
LOOP FILTER OFF
EVERYTHING ELSE DEFAULT

Here are the results:
100 FRAMES

REF-1
570 KB

REF-2
374 KB

REF-3
380 KB

REF-4
384 KB

REF-5
388 KB

REF-6
390 KB

REF-7
390 KB

REF-8
390 KB

REF-9
390 KB

REF-10
390 KB

Strange results! Is there anyone who can give an explanation, please???
And one more thing:

CAN ANYONE PLEASE TELL ME WHY FFDSHOW 20040520 DOESN'T ACCEPT MORE THAN 10 REFERENCE FRAMES????
EVERY TIME I TRIED TO USE VALUES LARGER THAN 10, FFDSHOW SWITCHED BACK TO 10!

[aketon]

OK! I've just done one more test:

VIDEO
----------
672x272
824 frames
25 fps

FFDSHOW SETUP
----------------------------
Quantizer 12
CABAC ON
Loop Filter OFF
All the analyzer flags ON (Inter PSUB8x8 OFF)
Maximum I frame interval 250
Minimum I frame interval 1


RESULTS:
----------------
REF-1 13.494 KB
REF-2 13.578 KB
REF-3 13.648 KB
REF-4 13.702 KB
REF-5 13.740 KB
REF-6 13.776 KB
REF-7 13.800 KB
REF-8 13.816 KB
REF-9 13.830 KB
REF-10 13.844 KB

The higher the value the bigger the filesize (this time at least)!

[aketon]

After a lot of testing, I found that 1 max. reference frame makes the encoded video not even smaller but and a little bit more detailed!!! I made too many tests just to be sure! I tried every different kind of fast motion and slow motion scenes I had and 1 max. reference frame was every time the winner! In some tests although using bigger values (from 2 to 5), I had smaller filesizes! From all the 35 tests I done with different values of reference frames, only in 3 of them, values 2 to 5 gave me better results!:confused:

[bond]

more than 1 possible references to choose from should make the codec more efficient, not worse, so it seems that x264 isnt really able atm to decide what frame to use as reference to get the best result :(

[Tommy Carrot]

Originally posted by aketon
After a lot of testing, I found that 1 max. reference frame makes the encoded video not even smaller but and a little bit more detailed!!! I made too many tests just to be sure! I tried every different kind of fast motion and slow motion scenes I had and 1 max. reference frame was every time the winner! In some tests although using bigger values (from 2 to 5), I had smaller filesizes! From all the 35 tests I done with different values of reference frames, only in 3 of them, values 2 to 5 gave me better results!:confused:

Exactly, this is what i told a few posts above yours. Something is clearly not right with x264 in this regard, so far i would recommend using 1 reference frame (with the exception of cartoons, where i believe using more reference frames is still beneficial due to the lot of repetitive image sequences).

[aketon]

Exactly, this is what i told a few post above yours. Something is clearly not right with x264 in this regard, so far i would recommend using 1 reference frame.

I totally agree with you!!!

[ToiletDuck]

After downloading a few of the samples and playing them I have no problems what-so-ever replaying them.
Duck

[bond]

according to Skal allowing more than 1 reference frames will also require more bits, as there additionally is the need for marking which frame is refered to too
the more frames allowed to choose from, the more bits required ("by using VLC it's: 1 bit if using Ref-1, 3 bits if using Ref-2,Ref-3,Ref-4, 5bits if using Ref-5 ... Ref-9, etc..."), the required bits would be smaller when using cabac i think

therefore if the bitrate savings because of using not simply the previous frame as reference is smaller than the bits needed for sending the framenumber, using this feature doesnt really make sense
this will heavily depend on the encoded content of course

[aketon]

Does anybody know why Justin's x264 builds accepts only 24 and 32 bits of color??? Shouldn't they accept YV12 color also? I am saying this because every time I choose this codec, virtualdub displays under known restrictions "Valid depths: 24 32" !!!

If anybody is going to tell me why I don't just use ffdshow, is because it hasn't got 51 quantizers to choose from!!!!:)

[ToiletDuck]

even though YV12 it isn't 12bit color is it? That would look horrible. I'd imagine it should stay at 32 bit for best results.

[RadicalEd]

Originally posted by ToiletDuck
even though YV12 it isn't 12bit color is it? That would look horrible. I'd imagine it should stay at 32 bit for best results.

You must be thinking of 12bit RGB. This is 12but YUV. Big difference :| They're actually not comparable, because all the YUV colorspaces I know of don't reduce bitdepth directly, they merely reduce chroma resolution.

[billou2k]

Yes thats right,
12bits is just an average per pixel.
Using YUV makes it possible to reduce the number of information for the colour without the eyes detecting it (normally;-) ):
Basically your picture is the sum of three layers: Y U and V.
The same goes for RGB but the difference is in the way these layers are created:
The Y is a black and white layer. This is the most visible component for the eye, that's why every pixel has a Y value (8bits=1Byte).
Then the two other layers create the colour layer. As the eye is less sensitive to spatial colour changes you can afford to have two or sometimes more pixels with the same colour value.
That's what YUV 4:2:2 or 4:1:1 or 4:2:0 stand for.

In YV12 : YUV 4:2:0, as said before each pixel as a Y value.
but then you only have 1 couple of U and V (8bits each) coding the colour component for 4 pixels (2*2) at the same time.
So if you average over these 4 pixels: you have
4*8 bits for the luminance + 2*8 bits for the colour / 4 pixels = 32+16/4=12 bits per pixel.

Working in YUV 4:2:2 (UYVY,YUY2..) is similar expect that you have a better color resolution : the U and V values are used to code the colour of 2 pixels (instead of 4 in YV12)
so in this case you use 2*8 (2 pixels with 1 value of Y for each ) + 2*8 (1 couple of U and V to code the colour of the two pixels) / 2 pixels = 16bits per pixel

Finally 32bits color means 4 times 8 bits: which means that on top of your 3 RGB /YUV layers you have an alpha layer.. and its absolutely useless for video. All video use 24bits to define a pixel at the moment.
Some new 3d video card can produce 64 or 128 bits colors for 3d rendering to improve contrast between high lighted and shadow areas but I dont think it is gonna be used for video.

(i hope it's clear:D)

[Nic]

@aketon: as you may have guessed that only refers to the RGB. Basically it means the codec won't accept 16bit RGB, etc. VDub should be more specific.

-Nic

[WaryWolf]

Nic: how are you getting along with the x264 source? i don't want to pry or rush you, i'm just wondering what you think of it and what you want to do... :)

[Nic]

Had basic 2pass code working. but off for a holiday in Vegas tomorrow morning so ya won't hear from me till around the 8th. See ya :)

[SeeMoreDigital]

Originally posted by Nic
but off for a holiday in Vegas tomorrow morning Are you off to Vegas get married, to gamble or both?

Stick some chips on the roulette table for me!


Cheers

[chenm001]

you can set fourCC to 'H264', it can be play by ffdshow
Originally posted by aketon
If anybody is going to tell me why I don't just use ffdshow, is because it hasn't got 51 quantizers to choose from!!!!:)

[billou2k]

I'm trying to get an idea of how x264 and other encoders compare to the reference encoder. Unfortunatly the only way I have to watch reference encoded videos is uncompressed yuv which takes "some" space.
Is there anyway to use an existing wrapper/decoder with the files encoded from reference encoder?

[Tommy Carrot]

Originally posted by billou2k
I'm trying to get an idea of how x264 and other encoders compare to the reference encoder. Unfortunatly the only way I have to watch reference encoded videos is uncompressed yuv which takes "some" space.
Is there anyway to use an existing wrapper/decoder with the files encoded from reference encoder?
If i remember correctly, Nic made some modification of the reference encoder, which accepts AVS as input, and outputs AVI. Unfortunately he did not release it to the public, but i suppose if you ask him nicely, he will do it. ;)

[bond]

Originally posted by Tommy Carrot
If i remember correctly, Nic made some modification of the reference encoder, which accepts AVS as input, and outputs AVI. Unfortunately he did not release it to the public, but i suppose if you ask him nicely, he will do it.guys use search!
there have been some posts about mod of the reference encoder allowing .avs input (long before nic said he will work on h.264)

Originally posted by billou2k
Unfortunatly the only way I have to watch reference encoded videos is uncompressed yuv which takes "some" space.
Is there anyway to use an existing wrapper/decoder with the files encoded from reference encoder?again, plz use search and read the mpeg-4 sticky
the reference encoder outputs plain .264 bitstreams, which can be played back in dshow with the moonlight and mainconcept filterset without a problem

[billou2k]

Sorry to look like the lazy guy who asks before searching but I did actually search before.
I've participated in the thread where the avs modified version of the reference code was discussed. That's where I said that it was crashing for me. I also replied to the person who asked me for more details by email. The reason was apparently that the AVS version crashes on interlaced content for some unknown reason.

Anyway, I have encoded several h.264 files with the JM82 but I cant find how to use the moonlight or mainconcept decoder with dshow.

I'm playing with graphedit but I dont seem to find the proper combination of filters...
I also guess that the decoders arent compatible with some option from the reference encoder so I'm trying to playback simple files but still no success yet...
Would you mind just explain shortly the way you do it?

Thanks a lot!

[bond]

Originally posted by billou2k
Anyway, I have encoded several h.264 files with the JM82 but I cant find how to use the moonlight or mainconcept decoder with dshow.dont waste time with moonlight, it plays .264 raw files, but its bloated, buggy and places a logo during playback on the picture

I'm playing with graphedit but I dont seem to find the proper combination of filters...

Would you mind just explain shortly the way you do it?hm if i remember it right moonlight always placed itself as the default used filterset after installing
what else gets used for playing .264 files if not moonlight?

[thegeby]

It looks like the EBU statement on MPEG 4 AVC licensing terms has had some effect....

New licencing terms for public service TV (http://www.mpegla.com/news/n_04-05-18_avc.pdf)

[Tommy Carrot]

Something has been borked in x264, the latest build creates bad artifacts/blocks, especially around high contrast areas. The older versions didn't have this problem, and this is not a cabac problem either, it occurs even without it. Here (http://www.fw.hu/carrotland/bugged_bridge.avi) is a short sample clip.

[Rash]

Oh yes Tommy. That sample of your looks terrible. :(

[BoNz1]

Tommy Carrot, IIRC there was a bug that was fixed with motion compensation. So, check the build date you may want to get a new build. I remember seeing artifacts like this a little while ago and I think they were fixed when I grabbed the latest sources.

[CruNcher]

i used rev 12 and saw no bugs like these mentioned ones only the problem with chens mc-c.c not compileable deleting it from the project file and everythings working :)

[movmasty]

Originally posted by bond
not totally correct, there is a workaround avialable in virtualdub(mod) which makes b-frames work with vfw (in divx5 and xvid), but other vfw apps will not offer this workaround
therefore other companies like m$, offering a vfw version of wmv9, dont allow b-frames in their vfw codec, b-frames are only available in their wmencoder
(not to speak of that the avi container itself isnt able to handle b-frames without hacks, not to speak of other h.264 specific things, like markers)

an alternative would be a dshow encoder or even better a commandline encoder (dont understand whats wrong with this, real uses it for rv9 and it would not be that windows-centric as vfw and dshow)

but yes there definitely is the need for a better interface (hope gstreamer, or at least dshow, will become something widely usable in the future) excuse me if i repeat a my old idea, why do not use the mpg container?

i mean that container that now handles mpeg 1 and 2 streams with mpg ext.

years ago there was only the mpeg1 codec, then mpeg2 was added in a separate decoder for commercial reasons(mpeg2 is not free)

so why dont add a mpeg4 decoder to handle movies coded in mpg container with mpeg4 codec????
Originally posted by Tommy Carrot

The only real handicap is the missing VFR ability, but for most of us it's not important at all.
i remember, years ago, that opening avi indeo 3.2 movies with old mainactor 1.xx,
i had the options to set a timecode for EACH INDIVIDUAL FRAMES,

this mean the ability to build a variable frame rate stream into avi,and fine tuned too,
what happened then to this ability???

[EDIT]now i see that ffdshow can save mpeg1 streams in avi container,
would have more sense to save mpeg4 in mpg container...
has an option to "store frames in external file" like "mpeg1 video stream", but isnt working.
anyone knows more about this option od ffdshow?

[movmasty]

Originally posted by bond
current downsides of AVC/H.264

If you sniff throught the available AVC implementations you will surely find out soon that there are still some problems, which have to be solved before AVC is widely usable:

- interoperability: most available implementations support different container formats atm:
.mp4: which is the native container of AVC in the MPEG-4 Standard
.mpg: which is also standardized for AVC
.264: which is the plain bitstream as output by the reference encoder for example
.avi: using AVI for AVC/H.264 is a bad idea!....
i have too see still an implementation of h264 or any other mpeg4 codec in .mpg,

where do i could find one??

[SeeMoreDigital]

Hi movmasty,

Have a look at these two Nero AVC (h.264) threads: -

http://forum.doom9.org/showthread.php?s=&threadid=81678

http://forum.doom9.org/showthread.php?s=&threadid=82036



Cheers

[movmasty]

Originally posted by SeeMoreDigital
Hi movmasty,

Have a look at these two Nero AVC (h.264) threads: -

http://forum.doom9.org/showthread.php?s=&threadid=81678

http://forum.doom9.org/showthread.php?s=&threadid=82036



Cheers
no post specified...you want me to read ALL those pages....thanks however

[SeeMoreDigital]

Sorry movmasty,

Re-reading your post it seems you are after h.264 in .mpg

For this, you need to look at MainConcept's implementation. However, it's nowhere near as good as Ahead's....

Please be aware the generic container for h.264 (and Mpeg4 SP/ASP) is .mp4


Cheers

[movmasty]

yes, but .mpg is very widely supported,

mp4...matroska...ogg vorbis....not, never been in the past at least

we always played with avi, why not mpg?

[Manao]

mp4...matroska...ogg vorbis....not, never been in the past at leastAnd ? You can play matroska on any computer, the same goes for ogm. mp4 is a little more tricky, because implementations are not yet widely distributed, but it's also possible.

Now, you want to put h264 into mpg, in order to read it everywhere. But h264 itself is even less supported than mp4, so it's useless imho.
we always played with avi, why not mpg?Because of VFW. No such interfaces exist for mpg. Avi is not a great format, but it is supported by great tools ( VirtualDub for example ), which often can only output avi files, because the VFW interface makes it easy.

[SeeMoreDigital]

When the standards for Mpeg4 (as we know and love it today) were agreed, the MP4 container was designed to be "its" container. Not AVI, MKV, OGG or even MPG.

Right from the start, the MP4 container was specifically designed for "future use" - which includes Mpeg4 AVC (aka Mpeg4 part 10).


Cheers

[movmasty]

Originally posted by Manao
And ? You can play matroska on any computer, the same goes for ogm. mp4 is a little more tricky, because implementations are not yet widely distributed, but it's also possible.

Now, you want to put h264 into mpg, in order to read it everywhere. But h264 itself is even less supported than mp4, so it's useless imho. all good video editors load mpg and can save mpg....

vdub loads mpg and can also save in mpg with an appropriate codec like YMPEG, would not be hard to make it save directly....

and then?

(ps. i said that here 3 years ago, not "now")
Originally posted by Manao
Because of VFW. No such interfaces exist for mpg. Avi is not a great format, but it is supported by great tools ( VirtualDub for example ), which often can only output avi files, because the VFW interface makes it easy.
and...mpg is cross platform very easy to manage in mac or linux too...

[stephanV]

im not sure a random mpg splitter would output H.264 anyway, so support would certainly not be guaranteed (not anymore then with mp4)... VirtualDub will most certainly not handle such files (and very likely never will, for the same reason it does not hanlde MPEG2)... it seems far more logical to support it in MP4 than in MPG... and of course, the container is only part of the issue... you need a decoder too. i guess part of implementing something new is lack of support in the beginning.

as for other containers... native support in Matroska would be nice, AVI is not too suited for it (but will do for now) and due to licensing it doesnt belong in Ogg (perhaps OGM).

[movmasty]

Originally posted by stephanV
im not sure a random mpg splitter would output H.264 anyway no, you need to make one, new mpg codec for mpeg4 as mpeg2 codec was new respect to mpeg1

[Manao]

mpg is a container, not a codec. To read / write into a container, you need a muxer / demuxer. If the container is well done, such a muxer / demuxer can be written without having knowledge of what you're muxing. ( theorically, of course, because just to keep the sync you'd need more information ).

[movmasty]

Originally posted by Manao
mpg is a container, not a codec. To read / write into a container, you need a muxer / demuxer. If the container is well done, such a muxer / demuxer can be written without having knowledge of what you're muxing. ( theorically, of course, because just to keep the sync you'd need more information ).
ok, a new mpeg4 codec for a mpg container...

[stephanV]

a new codec isnt what is needed for h.264 to work in mpg... muxers and splitters are...

[bond]

as smd pointed out already, mainconcepts encoder places h.264 into .mpg. other commercial implementations place it in .mp4 (like sorenson, nero and envivio)

Originally posted by Manao
And ? You can play matroska on any computer, the same goes for ogm. mp4 is a little more tricky, because implementations are not yet widely distributed, but it's also possible.i would say that .mp4 is more widely supported than .mkv and .ogm atm
.mp4 can be played in directshow, quicktime and realplayer already (all for free), plus there exists support for it in all the big opensource players (mplayer, vlc aso...), bringing it to as good as every platform existing (including pocketpc aso...)

read more about exisiting implementations in my mp4 faq i link to in my sig

[stephanV]

i wouldnt go that far... in fact, the tools available for matroska and ogm are in most cases far more user friendly and mp4 support is very often incomplete (although sometimes more on the decoding side)

[bond]

i talked about playback (as manao did), and regarding playback there exists perfect .mp4 support for directshow and yes, incomplete support for .mp4 in quicktime and realplayer. still there is no .mkv and .ogm support at all existing for qt and rp, so what...
also regarding .mp4 support in the big opensource players, its in no way worse or less user friendly than the support for .mkv and .ogm in these players of course

[chilledoutuk]

movmasty seems to not know what hes talking about as I cant see any possible benifet of using a old container format such as .mpg over .mp4 for mpeg-4 video streams.

In fact it will just make things more complicated becuase if somone were to make a splitter that could use the .mpg container for mpeg-4 then it would also have to take into acount all the other video technologies that also use that format such as mpeg-1 and mpeg-2 then differentiate between the different streams and then send the video to the corect dshow filter without having any compatibility problems.

Now legacy application that already exists that can play import or use video that is stored in a .mpg container would not be able to use a Mpeg-4 AVC video stream in a .mpg without making significant time consuming changes to the software, which may as well be spent on supporting the new .mp4 container format.

[movmasty]

Originally posted by chilledoutuk
movmasty seems to not know what hes talking about as I cant see any possible benifet of using a old container format such as .mpg over .mp4 for mpeg-4 video streams.

In fact it will just make things more complicated becuase if somone were to make a splitter that could use the .mpg container for mpeg-4 then it would also have to take into acount all the other video technologies that also use that format such as mpeg-1 and mpeg-2 then differentiate between the different streams and then send the video to the corect dshow filter without having any compatibility problems.

Now legacy application that already exists that can play import or use video that is stored in a .mpg container would not be able to use a Mpeg-4 AVC video stream in a .mpg without making significant time consuming changes to the software, which may as well be spent on supporting the new .mp4 container format. this makes sense, altought mpeg2 was already added in the mpg container using a different decoder, sw needed to be upgraded for this.
This is a thing to be made years ago, at the begin of divx-xvid....