The H.264/AVC/MPEG4 discussion thread

[Jekyll]

Originally Posted by Eeknay

i.e. latest CCCP, latest VLC, latest build of mplayer

Also, I would be quite interested in seeing how TCPMP performs on that machine.

[DryFire]

I suppose while we're on the topic of spu usage. I'll ask this:

How many reference frames and how many b-frames do you use in your encodes? Is B-pyramid enabled or disabled?

I've been using 8 ref and 3 b-frames w/ b-pyramid for my personal backups

[TheFluff]

Personally I use 2 b-frames and 4-5 refs, and that seems to be a pretty average value among the encoders I'm on friendly terms with. I know that most KAA encodes uses 16 refs, but that's a bit extreme IMO...

On a side notice, the CPU usage thing was discussed in Darkhold last night, and Haali posted a link to a tool that might be useful: http://haali.cs.msu.ru/mkv/timeCodec.exe

[movax]

Please note that you have to wait awhile on longer files. I suggest cutting a segment of a file to test, and then running the tool on it.

[Eeknay]

Originally Posted by DryFire

I suppose while we're on the topic of spu usage. I'll ask this:

How many reference frames and how many b-frames do you use in your encodes? Is B-pyramid enabled or disabled?

I've been using 8 ref and 3 b-frames w/ b-pyramid for my personal backups

Same as you. 8 refs, either 2 or 3 b-frames w/ b-pyramid. On PC I also turn the deblocking up to 1,1. For backups I usually leave that alone and just increase bitrate. One or two cases of backups I used 16 refs + 7-RDO2 (usually left at 5 or 6-RDO) since I was trying to aim for maximum quality on so-so sources.

[Wintermute_ryc]

Originally Posted by Ulayo

What could ever be wrong with H.264? It has superior quality over the previous mpeg4 based incarnations (xvid & divx). Plus it isn't really anymore difficult to get it to play at your computer than any other codec.

That's what I thought until for some very weird reason, my wireless G connection allows me to watch files or copy files over the air, including XVID, DIVX, MPEG, MP3s, but when it comes to H.264, it becomes very choppy.

The system plays H.264 files fine if the file is stored locally.

ffdshow dec-22 build, Athlon64 3000+, MPC.

It would be nice if someone can shed a light so that I don't need to copy files over to the laptop prior to playback ( I use laptop to output to TV ).

[Quarkboy]

Originally Posted by Eeknay

Same as you. 8 refs, either 2 or 3 b-frames w/ b-pyramid. On PC I also turn the deblocking up to 1,1. For backups I usually leave that alone and just increase bitrate. One or two cases of backups I used 16 refs + 7-RDO2 (usually left at 5 or 6-RDO) since I was trying to aim for maximum quality on so-so sources.

It differs depending on whether the source is DVD ISO's or not. For DVD sources I use 8 refs with either 3 or 4 b-frames w/b-pyramid (depending on how high motion the show is. Also, for low motion shows I'll turn it to 4 with the b-frame bias tweaked up a bit). I've done 16 refs, but it's normally not worth the nearly half over again time it takes to encode. I always use rdo 7 with mixed refs.

I think the answer is clear: More refs is better, 8 is standard "good quality", and 16 is great if you have a few days to encode .

[TheFluff]

2-pass or 3-pass? pengvado mentioned in Darkhold that he's been trying to get people to understand that 3-pass only helps in certain special cases, but that people in general are clinging to "slower is better". I used to use 3-pass for everything until I heard that - now it's about 50-50. Slower IS better, after all

[Quarkboy]

Originally Posted by TheFluff

2-pass or 3-pass? pengvado mentioned in Darkhold that he's been trying to get people to understand that 3-pass only helps in certain special cases, but that people in general are clinging to "slower is better". I used to use 3-pass for everything until I heard that - now it's about 50-50. Slower IS better, after all

2-pass, unless I'm pushing it on bitrate. For example, all the Pretty Cure's were 2-pass that I encoded except 49, which was pushing it a bit on bitrate since it was 2 minutes extra in length.

Actually, experience with that music video shows 3-pass CAN help a lot, but only when you have highly fluctuating quants, which tends not to be the case for anime.

[SSS]

Originally Posted by TheFluff

2-pass or 3-pass? pengvado mentioned in Darkhold that he's been trying to get people to understand that 3-pass only helps in certain special cases, but that people in general are clinging to "slower is better". I used to use 3-pass for everything until I heard that - now it's about 50-50. Slower IS better, after all

I still remember 3-pass encoding mode was help alot with video quality because older x264(before revision 223) using CBR(?) algo for encoding.
Untill pengvado change the encoding algo to ABR, i stop using 3-pass encode because i found out that 2-pass psnr is very near to 3 pass.
the default encoding mode now is ABR unless tweak the VBV/ratetol value.

If you guys want more slower encoding, i suggest use these x264 nth-pass options
(not recommended unless you want your CPU explode):
-r 16 -f -6:-6 -A all -m 7 -w --chroma-qp-offset 2 -p 3 --progress --b-pyramid --me esa -8 --mixed-refs -t 2 --b-rdo --bime

[Quarkboy]

Big news today:

For all you ffdshow dislikers, and, frankly, anyone who enjoys diversity, there's a new h.264 decoder on the block:
http://forum.doom9.org/showthread.ph...267#post761267

I tried this super ultra prealpha build, and it works great on all my releases . Even better, it's FAST. Faster than libavcodec, by like, 30-40% according to some.

[TheFluff]

Originally Posted by Quarkboy

Actually, experience with that music video shows 3-pass CAN help a lot, but only when you have highly fluctuating quants, which tends not to be the case for anime.

That was exactly the kind of special case it was supposed to help with.

EDIT: Tested CoreAVC with Haali's abovementioned timeCodec (null output), with the following results on ZX's SSO 09:

User: 182s, kernel: 0s, total: 182s, real: 183s, fps: 189.0, dfps: 188.2

ffdshow doesn't do quite as well:

User: 264s, kernel: 0s, total: 265s, real: 265s, fps: 130.3, dfps: 129.9

And Nero does even worse:

User: 334s, kernel: 0s, total: 335s, real: 337s, fps: 103.1, dfps: 102.5

[Quarkboy]

Originally Posted by TheFluff

That was exactly the kind of special case it was supposed to help with.

EDIT: Tested CoreAVC with Haali's abovementioned timeCodec (null output), with the following results on ZX's SSO 09:

User: 182s, kernel: 0s, total: 182s, real: 183s, fps: 189.0, dfps: 188.2

ffdshow doesn't do quite as well:

User: 264s, kernel: 0s, total: 265s, real: 265s, fps: 130.3, dfps: 129.9

And Nero does even worse:

Yup, that's the 30% faster than ffdshow they claim.

[LytHka]

Hrm, this is quite interesting. Will be on standby for any future stable release of it to test and list on AnimeSuki.

[DryFire]

I was under the impression that it was ment to become a retail product? Or did i misread the thread?

[Sylf]

As far as I know, all CoreCodec projects, including CoreAVC, are opensource, free program. I haven't found out under which license it's being released under yet.

[eglacirion]

I don't think it's opensource, b'cause according to their site.

http://corecodec.org/projects/coreavc/

CoreAVC is a complete set of decoders/encoder for the AVC/H.264 video codec. The CoreAVC decoder/encoder is released under a Closed Source License and is available to third parties that wish to license it. Email license@corecodec.com for more info.

[Quarkboy]

Anyway, I tested it out on all the h264 stuff I have, and it plays almost everything.

But, it crashes one One Piece 169 (but not 168 or less)... Anyone know if **** is using some different encoding settings for that episode?

[lamer_de]

They probably used a custom matrix, which is unsupported atm (or maybe not, according to a post by bond).

About the license:

Sharktooth... its to be determined still on if we keep it closed source or not. Reasoning is this... with TCPMP we have had 'alleged' thefts of our GPL source code and decoders that are in third party hardware/software. We have worked hard over the past three years to get were we are at now with CoreCodec/TCPMP and are going to take baby steps in protecting ANY of our projects IP.

Why invest our time to get our source code ripped off and that those doing the ripping do not comply with the GPL when we release it that way? Pretty sad since we also state that we own 100% of the code as well and offer a closed source alternative license to it, and they still OPT to steal it.

So with that being said... we are taking the cautious steps first with CoreAVC and yes, we have larger plans with our encoder like you had asked... we do plan on supporting ALL profiles and levels.

The doom9 and the corecodec thread have all the info available.

CU,
lamer_de

[Sylf]

IIRC, they switched audio from mp3 to AAC starting with that episode - but don't quote me on this. Aside from that, I'm not sure.