x264 development

[MSlv]

About b-frames.
When using them, BSPlayer refuses to play the file and gives me this error message:
"List index out of bounds (0)"
Also, the same file acts strange in videolan. It shows artefacts like this:


Same file plays fine in Media Player Classic.

[Mug Funky]

yet offer manual control where desired, including some cool combing artifact cleanup features that no one has done yet, AFAIK

this sounds interesting!

another thing i'd really love to see is a "segment re-encode" feature (maybe this is best suited to Virtualdub's interface?).

ie. you watch the movie, and note all the crappy bits. you then set I-frame (or IDR frame for AVC, i suppose) in and out points, and re-encode the bad part using the same GOP structure.

i know DVDMaestro offers this (and it's reeeeally nice to use if you've got the Spruce MPX3000 encoder card plugged in - seamless integration with the authoring app). it'd be good to see this built into an mpeg-4 solution - this would mean if your encode is undersized, it's not a problem. it also means if you're using a not-so-good encoder (WMV? Divx 3?) you can still get nice encodes if you re-do enough segments (this is exactly what the feature is for in Maestro - mpeg-2 isn't the best codec, and sometimes a client just wants so much video on a disc that the bitrates go way down).

well, this is also a pipe dream, but i'm sure lots of tweekers would find it useful (the kind who use YATTA for instance )

[Stacey Melissa]

I hadn't heard of YATTA before. Judging from its description, it sounds like it gets about halfway there for what I was wanting to do to clean up combing artifacts. I'll have to check it out. Thanks.

And since you mention setting IDR frames... part of my pipe dream includes the ability to force IDR frames at specified frames. This would be used in combination with the Nero-style chapters that have been recently integrated into mp4box. Chapter seeking would be very fast if the chapter is always set on an IDR frame. Anyway, that would be something nice to have built into x264, although not essential.

And another cool feature to have in x264 would be the ability to use different deblocking strengths for different zones. Maybe that was already planned anyway? I think I've done maybe 30 or 40 encodes of Matrix3, and no matter what x264 parameters I set, I can't get rid of that damn horrendous blocking behind Merv on his balcony. But if I could jack up the deblocking strength to, say, 6, just for that scene, then I'd consider that progress. That would at least be one possibility for improving such troublesome scenes. Other possibilities all have to do with fancy AVS wizardry, so I suppose I'll save 'em for another thread.

[Doom9]

part of my pipe dream includes the ability to force IDR frames at specified frames. This would be used in combination with the Nero-style chapters that have been recently integrated into mp4box.

Is that really necessary? After all, if the playback filter cooperates, you can easily jump to any given frame regardless of its frame type.

[Stacey Melissa]

Of course it's not necessary. It's part of my pipe dream!

What it would help with is just making chapter seeking more responsive.

[virus]

some problems here when using b-refs with revision 215... but that's likely a skipping issue so probably a long-standing one. Very weird artifacts due to exaggerate skipping, or maybe some probs with direct mode + brefs, dunno. Anyway, cmdline:

x264 -m 3 -b 3 --b-pyramid --frames 300 -q 27 -o x264-r215-brefs.mp4 ~/mplayer/main/test-2.avs

The result is available here (627 KB). Look at frames 200 and following. The mess on the woman's face is evident. Frame 230 (according to MPlayer's numbering, ffdshow's may differ) seems the worse.

I got a report (thanks to AlexW) that even decoding with JM the artifacts are there, so it's definitely an encoding issue. The quantizer of bvops is 28-29 here so nothing exceptionally low; not enough to justify such problems, at least. Similar problems happen (maybe even worse) when using -m 5 so it's not directly related to the ME type.

[bond]

Originally posted by virus
[B]some problems here when using b-refs with revision 215... but that's likely a skipping issue so probably a long-standing one. Very weird artifacts due to exaggerate skipping, or maybe some probs with direct mode + brefs, dunno.

i can confirm that i get the same problem

i saw that especially with -q 20 -b 5 --b-bias 100 --b-pyramid


btw the new --progress option rocks! would be cool if it gets enabled by default

[akupenguin]

Originally posted by virus
some problems here when using b-refs with revision 215... but that's likely a skipping issue so probably a long-standing one. Very weird artifacts due to exaggerate skipping, or maybe some probs with direct mode + brefs, dunno.

Fixed. The encoding was correct. Only the header was wrong. Old references are forgotten in encoding order, not in order of display timestamp. So when references are reordered (pyramid), having a bigger DPB than expected can change the meaning of "L0 ref 1" to mean something other than what the encoder thought. I didn't notice because only the oldest ref is affected => not very many MBs in B-frames at frameref=8 or 16.

[rushin_911]

feature request: Choosing SAR values from the vfw version...

(I know I've asked that before in this same thread, but I hadn't mentioned the vfw version specifically and at the time this feature had already been introduced in the CLI version)

[Yong]

Why don'y use the CLI x264 encoder?
It isn't hard to use than vfw and more up-to-date imho.
But still i hope x264 devs or other contributors can update this vfw

@rushin_911:
You can transmuxing the video to MKV and changing the D/SAR via MKVtoonix.

I've tried with MKVToolnix, the D/SAR is ignore by ffdsohw(or haali matroska splitter?)...
Only MPlayer is respect the MKV D/SAR value.

EDIT: nasty typo...

[Sirber]

I'm thinking about adding CLI in RealAnime, instead of only using the VFW one. Since it supports AVS, it will be easy to implement.

[rushin_911]

Originally posted by Yong
Why don'y use the CLI x264 encoder?
It isn't hard to use than vfw and more up-to-date imho.
But still i hope x264 devs or other contributors can update this vfw

@rushin_911:
You can transmuxing the video to MKV and changing the D/SAR via MKVtoonix.

I've tried with MKVToolnix, the D/SAR is ignore by ffdsohw(or haali matroska splitter?)...
Only MPlayer is respect the MKV D/SAR value.

EDIT: nasty typo...

Well the reason for not using the CLI version is that I´m not very familiar with the command line environment...

As for the MKVtoolnix I already use the DAR values from it when muxing into MKV, unfortunatly though it´s, as you have stated, ignored by ffdshow even when enabling overlay and also ignored by Media Player Classic (my player of preference)...

My request for the SAR values to be visible in the VFW however are for when I mux the media files created into the MP4 format.

[Yong]

@rushin_911:

@echo off
IF '%1'=='' GOTO EOF
title X264 Encoder
start /belownormal /b /w X264 -p 1 --stats "%userprofile%\desktop\X264[%~n1].log" -o nul: %1 --progress
start /belownormal /b /w X264 -p 2 --stats "%userprofile%\desktop\X264[%~n1].log" -o "%userprofile%\desktop\%~n1.mp4" %1 --progress
pause
:EOF

save the above code to "x264.bat"
u can try to add other cli option if u need like, --b-pyramid, --weightb and --subme 5.

[Yong]

can anyone play those video clip normally from VSoft's h264 free video clips download section?
http://www.vsofts.com/h264/videoclips.html
Mplayer and ffdshow hang when playing those CIF and D1 video clips...
(becareful, my computer almost freeeeeeze when playing with ffdshow )

Second, i think there may be a problem in x264 encoders
, when playing x264 encodeds with libavcodec in grayscale mode,
mplayer and ffdshow both show some random big green blocks when playing(extra, flashing green in mplayer),
but HD video clip from apple website doesn't have this kind of problem...

stupid typo again...
Ok, finally i found some playable clips from LEAD h264 free video clips , forget the buggy VSS video clips

[dude051]

Can anyone help tell me which values in the VFW are relative to the CLI values? I can pick out all but two, b-frames reduction % and bitrate variability %. I encode mainly Anime, and want to jump to the CLI version to have some of the newer options. My current setup im working with looks like:

@echo off
start /belownormal /b /w x264 -I 300 -i 30 -b 2 -A all -w --b-pyramid --no-chroma-me -p 1 --stats "X264[%~n1].log" -o nul: %1
 --progress encode.avs
start /belownormal /b /w x264 --merange 32 -I 300 -i 30 -b 2 -f 1:0 -B 1453 -r 8 -A all -w --me esa --b-pyramid --chroma-qp-offset 2 -p 2 
--stats "X264[%~n1].log" -o "encode.mp4" %1 --progress encode.avs

I've heard setting a constant quant as apose to constant bitrate is better, how would i go about guessing one close to my desired bitrate? Also... in the VFW version, does checking "fast firstpass" disable most non-needed cpu intensive things like -A , --me? And im not too sure how different h.264 works compared to XviD, but would it ever be possible to create custom matricies for x264? Although x264's quality vs. noise is alot more impressive than the older codecs, I would like to be able to work on the nasty DCT blocks that show up. Setting the deblocking filter high does not help with this.. as it helps to prevent blocks from already existing blocks. I want to try and help blocks that occur from large flat dark/low contrast areas (such as in most anime). I've searched as much on these questions as much as I wanted to... but its getting late heh.

Thanx in advance...

[Doom9]

but would it ever be possible to create custom matricies for x264?

Not until x264 supports the AVC high profile. If you have a look at bond's excellent sticky:
http://forum.doom9.org/showthread.php?s=&threadid=73022 you'll see that the AVC Main profile does not support custom quantizer matrices.

[Sagittaire]

good quality with good speed

x264.exe --bframe 2 --ref 5 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.30 --analyse "all" --weightb --progress -o x264-HDTV.mp4 HDTV.avs
x264.exe --bframe 2 --ref 5 --bitrate 2500 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.30 --analyse "all" --weightb --progress -o x264-HDTV.mp4 HDTV.avs
x264.exe --bframe 2 --ref 5 --bitrate 2500 --pass 2 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.30 --analyse "all" --weightb --progress -o x264-HDTV.mp4 HDTV.avs

"esa" is too slow and quality improuvement is really small
bpyramid don't improve quality and playback is not good

[Yong]

Originally posted by Sagittaire
...bpyramid don't improve quality and playback is not good

Should i say you are kiddding?

no b pyramid:
x264 [info]: PSNR Mean Y:42.93 U:46.83 V:46.70 Avg:43.66 Global:41.87 kb/s:604.7

b pyramid:
x264 [info]: PSNR Mean Y:42.56 U:46.74 V:46.66 Avg:43.30 Global:42.00 kb/s:601.0

EDIT: So far i haven't encountered any playback problem with b-pyramid...

[bond]

Originally posted by Yong
Ok, finally i found some playable clips from LEAD h264 free video clips

omg, what files are these...

- they use wav audio (good for the bandwidth...)
- they place avc in a bastard version of the .ogm format (not listed as video stream)
- they give the .ogm files the .avi extension
- they dont seem to like p-frames, as their streams mainly use b-frames and a few i-frames

funky

[Yong]

Originally posted by bond
omg, what files are these...

- they use wav audio (good for the bandwidth...)

yep, uncompressed 1411 kb/s PCM, they are stup1d...

- they place avc in a bastard version of the .ogm format (not listed as video stream)
- they give the .ogm files the .avi extension

OGM? Are you sure?
i see the "RIFF" in the top of file

- they dont seem to like p-frames, as their streams mainly use b-frames and a few i-frames

funky

Sure

Hey Bond, can u play the free VSS h264 video clips normally?
in my test, mplayer and ffdshow both crashed when playing