Log in

View Full Version : x264 development


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 [28] 29 30 31 32 33 34 35 36 37 38

sr78
6th November 2005, 16:49
Sorry , I was using a VERY old version
My mistake.

thank you both for your help

Richard Berg
6th November 2005, 18:18
Yes, I have a Huff VFW codec installed, but it decodes to YUY2 of course. Maybe I can get it to work by using ffvfw and changing the output settings...

bond
6th November 2005, 18:46
Yes, I have a Huff VFW codec installed, but it decodes to YUY2 of course. Maybe I can get it to work by using ffvfw and changing the output settings...i think it should work with any vfw codec tough?

stephanV
6th November 2005, 18:59
I'm pretty sure you can only feed x264 with uncompressed YV12 AVIs, for the reason that not any other AVI seems to work.

[edit]Looking through the source code it is quite obvious that anything else but YV12 won't work.

bond
6th November 2005, 21:24
I'm pretty sure you can only feed x264 with uncompressed YV12 AVIs, for the reason that not any other AVI seems to work.

[edit]Looking through the source code it is quite obvious that anything else but YV12 won't work.good to know :)

redfordxx
6th November 2005, 23:07
I just tried to encode const quant=1
What's this problem?

Next job job15 is a video job. encoder commandline:
"x264.exe" --qp 1 --ref 4 --bframes 2 --nf --no-cabac --weightb --analyse all --8x8dct --me umh --cqmfile "C:\Program Files\x264\eqm_avc_hr.cfg" --progress --no-psnr --output "D:\_download\WMV\T2_1080-lossless.mkv" "D:\_download\WMV\T2_1080-exc.avs"
successfully set up video encoder and callbacks for job job15
----------------------------------------------------------------------------------------------------------

Log for job job15

avis [info]: 1280x544 @ 23.98 fps (212 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
x264 [error]: OVERFLOW levelcode=4251
x264 [error]: OVERFLOW levelcode=4265
x264 [error]: OVERFLOW levelcode=4365
x264 [error]: OVERFLOW levelcode=4283
x264 [error]: OVERFLOW levelcode=4363
x264 [error]: OVERFLOW levelcode=4495
x264 [error]: OVERFLOW levelcode=4447
x264 [error]: OVERFLOW levelcode=4165
x264 [error]: OVERFLOW levelcode=4299
x264 [error]: OVERFLOW levelcode=4281
x264 [error]: OVERFLOW levelcode=4201
x264 [error]: OVERFLOW levelcode=4219
x264 [error]: OVERFLOW levelcode=4553
x264 [error]: OVERFLOW levelcode=4487
x264 [error]: OVERFLOW levelcode=4327
x264 [error]: OVERFLOW levelcode=4459
x264 [error]: OVERFLOW levelcode=4343
x264 [error]: OVERFLOW levelcode=4575
x264 [error]: OVERFLOW levelcode=4331
x264 [error]: OVERFLOW levelcode=4327
x264 [error]: OVERFLOW levelcode=4143
x264 [error]: OVERFLOW levelcode=4151
x264 [error]: OVERFLOW levelcode=4201
x264 [error]: OVERFLOW levelcode=4245
x264 [error]: OVERFLOW levelcode=4263
x264 [error]: OVERFLOW levelcode=4251
x264 [error]: OVERFLOW levelcode=4111
x264 [error]: OVERFLOW levelcode=4141
x264 [error]: OVERFLOW levelcode=4151
x264 [error]: OVERFLOW levelcode=4245
x264 [error]: OVERFLOW levelcode=4359
x264 [error]: OVERFLOW levelcode=4239
x264 [error]: OVERFLOW levelcode=4277
x264 [error]: OVERFLOW levelcode=4339
x264 [error]: OVERFLOW levelcode=4309
x264 [error]: OVERFLOW levelcode=4241
x264 [error]: OVERFLOW levelcode=4449
x264 [error]: OVERFLOW levelcode=4401
x264 [error]: OVERFLOW levelcode=4113
x264 [error]: OVERFLOW levelcode=4211
x264 [error]: OVERFLOW levelcode=4307
x264 [error]: OVERFLOW levelcode=4149
x264 [error]: OVERFLOW levelcode=4297
x264 [error]: OVERFLOW levelcode=4235
x264 [info]: slice I:21 Avg QP: 0.00 size:341750
x264 [info]: slice P:172 Avg QP: 1.00 size:311998
x264 [info]: slice B:19 Avg QP: 3.00 size:233094
x264 [info]: mb I I16..4: 6.9% 14.1% 79.0%
x264 [info]: mb P I16..4: 4.8% 11.5% 41.0% P16..4: 5.6% 7.3% 16.2% 7.5% 5.3% skip: 0.7%
x264 [info]: mb B I16..4: 2.5% 7.8% 18.5% B16..8: 19.6% 14.9% 34.3% direct: 0.9% skip: 1.4%
x264 [info]: 8x8 transform intra:19.4% inter:6.5%
x264 [info]: ref P 86.4% 7.6% 3.6% 2.4%
x264 [info]: ref B 95.4% 3.1% 1.0% 0.6%
x264 [info]: kb/s:59052.7

Actual bitrate after encoding without container overhead: 59055.69

----------------------------------------------------------------------------------------------------------

akupenguin
7th November 2005, 00:05
Short reason: qp=1 + cavlc + cqm.
Short fix: don't ever use qp=1. it's way beyond perceptually transparent, but it's not really lossless, and often higher bitrate than qp=0.

Long reason:
When entropy_coding_mode_flag is equal to CAVLC and QPy is less than 10 and profile_idc is equal to 66, 77, or 88, the range of values that can be represented for the elements of cij of c is not sufficient to represent the full range of values of teh elemts dcYij of dcY that could be necessary to form a close approximation of the content of any possible source picture by the use of the Intra_16x16 macroblock type.
However, the overflow seems to occur in x264 only when CQM is used (high profile), and the standard says it should be an issue only when not using high profile, so I don't actually know what's wrong.

squid_80
7th November 2005, 00:17
I'm pretty sure you can only feed x264 with uncompressed YV12 AVIs, for the reason that not any other AVI seems to work.

[edit]Looking through the source code it is quite obvious that anything else but YV12 won't work.
Shouldn't be a problem for most people, just make an avs script with avisource and converttoyv12 (if needed).

ChronoCross
7th November 2005, 02:23
364A Crashes x264 with the HQ-Insane Profile. I've narrowed it down to the RDO Level 2. Changing it to 6 instead of 7 takes away the crash.

Quarkboy
10th November 2005, 06:43
I have a question about max refs...

I use x264 for anime encoding, and I've found significant size differences at constant quant=25 tests (with subme 7, rdo for b-frames, umh, 3 b-frames... etc...)...
about 3.6% decrease with refs=8 versus refs=4, and about 4.6% with refs 16 versus refs 4.

I haven't noticed any significant playback speed decreses with refs=16 either.

However, I'm wondering how the references are actually stored in the file? am I wasting 3 bits almost every frame by using refs=16?

Manao
10th November 2005, 06:58
The reference can change for every 8x8 block. However, you don't need 4 bits for each macroblock ( all references aren't equally used, so, for example, the most used, the first one, will be written with 2 bits ( i don't know exactly how many in fact ) ). Furthermore, cabac complicates the matter and reduces greatly the bits wasted on the reference. Finally, references can also be predicted ( a 8x8 block whose neighbours all use the nth reference will be likely to use that one too )

Quarkboy
10th November 2005, 07:13
The reference can change for every 8x8 block. However, you don't need 4 bits for each macroblock ( all references aren't equally used, so, for example, the most used, the first one, will be written with 2 bits ( i don't know exactly how many in fact ) ). Furthermore, cabac complicates the matter and reduces greatly the bits wasted on the reference. Finally, references can also be predicted ( a 8x8 block whose neighbours all use the nth reference will be likely to use that one too )

so cabac also compresses the reference info for each macroblock along with the transformed quant coefficients? good to know. Thanks for the quick answer.

akupenguin
10th November 2005, 07:34
In CAVLC, selecting the 1st ref always takes 1 bit per partition, regardless of the number of refs to choose from (except of course when there's no choice). Selecting the 2nd ref takes 1 bit if #refs=2, or 3 bits if #refs>2. The costs of the rest are independent of the number of choices. While it may be possible for x264 to make suboptimal decisions, there are no ref-related penalties inherent to the standard beyond #refs=3.
In CABAC, things are simpler (from the user's POV): costs adapt to the real usage frequencies, so there are no penalties for allowing refs that aren't needed. (They can take less than 1 bit each if predicted well)


CABAC compresses everything (except the <5byte frame header).

hpn
10th November 2005, 22:29
I guess before every first pass x264 should check if there is a "x264_2pass.log" from a previously successful encode (usually from the same source but with different options) in the same folder and delete it.

p.s. The previous log file is now deleted (overwritten) by x264_2pass.log.temp only when the first pass is successfully complete, but it could cause a problem on some rare occasions. For example I make multiple 2pass tests via .bat files and sometimes I manage to crash the encoder during the first pass after a few frames (in some extreme -t 2 -rdo --b-rdo tests with HD content), so the first pass is not finished, but the second one starts automatically and usually completes successfully because a former valid log (but made with different options) is present, so this way I get an encode without the desired parameters and what is worse, I may overlook the error in the command prompt and think everything encoded fine. To work around this I always delete the previous log manually, before starting a 2(3)pass .bat, so in case the first pass crashes I just get an error and the encoding stops:
x264 [error]: ratecontrol_init: can't open stats file
x264_encoder_open failed

_xxl
11th November 2005, 14:30
http://www.elecard.ru/movies/Olesya..._SIF_90kbps.mp4
ffdshow avc h.264 mobile
Microsoft Visual C++ Runtime Library
Assertion Failed!
Program...Media Player Classic 6.4.8.6 and Media Player 2
File libavcodec/h264.c
line 7755
EXPRESSION Pict--Data[0]
Amd XP 1600+ winXP Sp2
Tested with:
Milan's compiled fdshow-20051109.exe ICL8 and bob0r's fdshow-20051109.exe sse GCC.

Sharktooth
11th November 2005, 14:33
@drevil_xxl: it's a ffdshow problem, not a x264 problem. your post is on the wrong thread.

sr78
15th November 2005, 15:18
h264 general question (Sorry I did not find it in the ITU-T )
I know that 0x000001 is the start code for a new NAL unit.
but , since few NAL units can build uo to one frame , how does the decoder
decide that a new frame is reached (i.e - this NAL unit is from a new frame)?

thanks

bond
15th November 2005, 15:21
h264 general question (Sorry I did not find it in the ITU-T )
I know that 0x000001 is the start code for a new NAL unit.
but , since few NAL units can build uo to one frame , how does the decoder
decide that a new frame is reached (i.e - this NAL unit is from a new frame)?

thanksfor this either you use access unit delimeters or there is a flag telling whether a NAL is a new picture or part of the last one

sunilraman
17th November 2005, 01:51
hi sharktooth thanks for the win32 builds. one question, if it has not been answered already, what is your view on SSE3 optimisation in addition to 3dnow, SSE, SSE2 ?

Sharktooth
17th November 2005, 11:31
I dont think SSE3 will bring more benefits, however you may ask akupenguin (pengvado on IRC) or Alex_W coz they already had a SSE3 pixel routine code patch.

giandrea
18th November 2005, 16:16
Hello, what's this "RD mode decision for B-frames" added in the368 commit?
Any comment, test?

Sharktooth
18th November 2005, 18:41
Rate/Distortion optimization on b-frames too (when RDO is enabled -> --subme 6 or 7).
It's like b-vhq in xvid 1.1...

redfordxx
19th November 2005, 17:09
Why I have this message?
I have unrestricted level, MeGUI settings based on Sharktooth's HQ profiles...
Should I care for it?

gino25
20th November 2005, 12:06
what is GPAC? I can read this in changelog of x264.

nm
20th November 2005, 13:13
http://gpac.sourceforge.net/

bond
20th November 2005, 13:38
Why I have this message?
I have unrestricted level, MeGUI settings based on Sharktooth's HQ profiles...
Should I care for it?there is no such thing as "unrestriced level" in avc, meaning you always have to set a level

propably megui tells you that your encode breaks the highest level possible in the mentioned way?

Doom9
20th November 2005, 13:42
propably megui tells you that your encode breaks the highest level possible in the mentioned way?It's not MeGUI, that message comes directly from the encoder. It's curious that you're getting this message though. Are you sure nothing is set in the VBV fields (x264 configuration, 2nd tab)?

redfordxx
20th November 2005, 15:41
Are you sure nothing is set in the VBV fields (x264 configuration, 2nd tab)?I am making some short test encodes"x264.exe" --qp 20 --keyint 240 --ref 16 --mixed-refs --bframes 3 --b-pyramid --nf --subme 7 --b-rdo --weightb --trellis 2 --analyse all --8x8dct --me umh --progress --no-psnr --output "blox-smooth-umh-ref16-range16.mkv" "blox-smooth.avs"
avis [info]: 1280x544 @ 24.00 fps (2071 frames)
x264 [warning]: DPB size (16711680) > level limit (12582912)
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
x264 [info]: slice I:48 Avg QP:17.00 size: 5682100:00
x264 [info]: slice P:1534 Avg QP:20.00 size: 26136
x264 [info]: slice B:489 Avg QP:21.86 size: 14839
x264 [info]: mb I I16..4: 16.2% 67.2% 16.6%
x264 [info]: mb P I16..4: 17.5% 32.9% 3.6% P16..4: 27.9% 8.4% 2.8% 0.1% 0.0% skip: 6.8%
x264 [info]: mb B I16..4: 4.2% 6.7% 2.1% B16..8: 57.3% 1.7% 2.1% direct: 3.0% skip:22.9%
x264 [info]: 8x8 transform intra:60.6% inter:89.0%
x264 [info]: ref P 70.8% 10.0% 5.0% 3.1% 1.9% 1.7% 1.2% 1.5% 0.8% 0.9% 0.6% 0.7% 0.5% 0.5% 0.4% 0.4%
x264 [info]: ref B 75.0% 9.7% 4.2% 2.2% 1.9% 1.3% 1.3% 0.7% 0.8% 0.6% 0.8% 0.4% 0.3% 0.3% 0.4%
x264 [info]: kb/s:4641.5

encoded 2071 frames, 0.26 fps, 4641.64 kb/sAnother surprise. this video has 23.995fps. When I encode it to mp4, it is or "looks like" 25fps...??? After transmux to mkv, 23.995 again... Maybe FFDShow is confused?

falcon2000eg
21st November 2005, 00:28
any update for vfw?

bond
21st November 2005, 00:33
any update for vfw?whats that? :p

falcon2000eg
21st November 2005, 01:06
i think adding subme 7 ,b-rdo and Trellis in vfw will be great .
I know h.264 in avi is :devil:

Kostarum Rex Persia
21st November 2005, 01:26
I agree.Updated vfw is very good idea.

CiNcH
21st November 2005, 01:47
Not to forget Adaptive Quantization and Custom Quantization Matrices.

Or probably just a ToDo list for the VfW interface, so that it is more obvious which features are missing, maybe I find some time to include them...

bond
21st November 2005, 01:50
another option missing is the automatic formating of the users harddisc when he tries to use the vfw version of x264

i think megui is easy enough to use, to not have to go with vfw

Tommy Carrot
21st November 2005, 02:10
But megui needs .NET framework, and i certainly can understand if someone is reluctant to install that (because i am too :D), and also AFAIK it cannot output avi (you know, still the best choice for editability :)). VFW has some advantages just as some disadvantages, so if some people want to use it, let them, it's always good to have some alternatives.

falcon2000eg
21st November 2005, 02:34
Tommy Carrot
:thanks: :goodpost:

celtic_druid
21st November 2005, 04:00
Could also just remove VfW from the svn, that way no one would complain that it was out of date and everyone would be forced to use the cli.

Maybe its time to updated the x264 cli gui that was based on the VfW source? No .NET, same user interface, no VfW and no avi.

Kostarum Rex Persia
21st November 2005, 12:18
Could also just remove VfW from the svn, that way no one would complain that it was out of date and everyone would be forced to use the cli.

Maybe its time to updated the x264 cli gui that was based on the VfW source? No .NET, same user interface, no VfW and no avi.

No,no,no. :mad: That's not very good idea.I know 50 people who use x264,and no one uses CLI.Everybody like vfw.

redfordxx
21st November 2005, 12:48
No,no,no. :mad: That's not very good idea.I know 50 people who use x264,and no one uses CLI.Everybody like vfw.I started recenly with x264.
Soon I prefered MeGUI --- more options, although I didn't understood them all.
I think the interface is growing fast together with codec, so it is not absolutely well arranged. But IMHO it should be solved only after the list of features will be finished. The work on the encoder itself is more important and thanks for it.
Very important for me is the show commandline option... that way I learned the CLI.
Now I prefer CLI, it's much faster when modifying and copying jobs (saved in .BAT files) When there is an error I can restart the batch instantly (for MeGUI I have to go to the jobs directory and change the status/error flag, then restart MeGUI). You can also insert DOS commands into batch file for example x264 pass 1 ...
copy stats ...
x264 pass 3 ...
pause

You and your 50 friends should try it.
I use GUI only for experimenting.

Doom9
21st November 2005, 12:55
But megui needs .NET framework, and i certainly can understand if someone is reluctant to install thatNo, irrational fear is no excuse. I used to be like that 2.5 years ago before my first .NET installation, but I have not found a single reason not to install it since (that is if you need it of course, if you have no software there's no need for it, but insisting on non .NET software isn't healthy.. it's a well known fact that unmanaged languages, with all their advantages, are more error and security leak prone).

I've asked for AVI output in x264.exe.. current coders have no interest in that but volunteers are always welcome. And MeGUI supportx x264 in AVI, you just need to use mencoder (which has a limited x264 featureset I'm afraid).

I know 50 people who use x264,and no one uses CLI.Are those the same people that fill the container forum with issues they wouldn't have if they used a more appropriate container? I have no beef with AVI, none at all, but you should pick a container in relation of what you're going to do later on. AVC's featureset makes AVC in AVI a much less useful idea than ASP (where we have all the workarounds in place, without them it wouldn't be so convenient either unless you restrict yourself to simple profile)

@redfoxx: if you have any interface improvement ideas, please share them (in the appropriate thread though). I've asked in the past for ideas but nobody replied so far.. I'm aware that with all the new features, a rearrangement would make a lot of sense.

Manao
21st November 2005, 13:00
you just need to use mencoder (which has a limited x264 featureset I'm afraid).IIRC, Loren quickly updates mencoder when features are added to x264

Doom9
21st November 2005, 13:27
IIRC, Loren quickly updates mencoder when features are added to x264Not all the time.. just take a look at the mencoder manpage and compare it with x264.exe...

redfordxx
21st November 2005, 13:39
if you have any interface improvement ideas, please share them (in the appropriate thread though). I've asked in the past for ideas but nobody replied so far.. I'm aware that with all the new features, a rearrangement would make a lot of sense.Well I thought I better not bother developers with my personal "complains". But when there is at least some interrest, provided I will have some constructive output, I will share it (in MeGUI thread).
Only in general idea:
Except arranging and grouping controls according to logical relationships, maybe it is good also somehow to distinguish features which are pass specific and which are pass independent. In other words, after I am not satisfied with second pass, which features can I change without redoing 1st pass (and save many hours), and which feature change require new 1st pass. (of course, this is a newbie feature. These, who perfectly understand the encoder, can decide it themselves)

Sharktooth
21st November 2005, 16:03
Some time ago i was going to update the VFW interface with some of the new options.
However some of them (like zones) are a pain in the a$$ to add. Also i moved away completely from VFW since i stared including MeGUI in my builds, and have no longer interests in keeping VFW up to date.

Kostarum Rex Persia
21st November 2005, 16:52
Sharktooth,can you,please,find some motivation to implement new options in vfw codec, subme 7 ,b-rdo and Trellis,Adaptive Quantization and Custom Quantization Matrices.

Most of the world codecs use vfw interface,so I think if you stop to develop x264 vfw,that can really harm x264 popularity.Very few people like to work in MeGUI or CLI encoders.

Sagittaire
21st November 2005, 17:04
Sharktooth,can you,please,find some motivation to implement new options in vfw codec, subme 7 ,b-rdo and Trellis,Adaptive Quantization and Custom Quantization Matrices.

Most of the world codecs use vfw interface,so I think if you stop to develop x264 vfw,that can really harm x264 popularity.Very few people like to work in MeGUI or CLI encoders.

and RV10 example with producer.exe ... lol

IMO x264 with CLI is the best way for multiple Gui developpement ... and by far

H264 in avi or mkv is a very bad way ... mp4 will be compatible with SAP.

Kostarum Rex Persia
21st November 2005, 17:11
Well,it works for me.I use AVI container for x264,and I am very pleased.

Sirber
21st November 2005, 17:15
and RV10 example with producer.exe ... lol

IMO x264 with CLI is the best way for multiple Gui developpement ... and by far

H264 in avi or mkv is a very bad way ... mp4 will be compatible with SAP. :stupid:

Well,it works for me.I use AVI container for x264,and I am very pleased.
AVI is outdated as well as VFW. It's time for you to upgrade :p

dimzon
21st November 2005, 17:21
:stupid: AVI is outdated as well as VFW. It's time for you to upgrade :p
I have an idea to develop VfW encoding API successor.

easy to implement
Codec developers does not spent they time for interface and other stuff

easy to deploy
Must support XCopy deployment model and side by side execution (DirectShow is not applicable here)

easy to use
Must provide simple API able to use from VB6/Delphi/.NET/C++ etc.

Tommy Carrot
21st November 2005, 17:27
H264 in avi or mkv is a very bad way ... mp4 will be compatible with SAP.I never understood people's obsession with mp4 container. Is there any evidence that it will be widely supported by the industry? Next-gen DVD will most probably use a VOB like container, HDTV will use TS for streaming, Apple is already using AVC in MOV, and H.264 reference encoder doesn't even support mp4 output. Where is the wide support for mp4? Not to mention if you want to edit your mp4 (and mkv) videos, your hands are tied, there is no simple straightforward way to do that.