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 39 40 41 42 43

Inventive Software
4th December 2007, 06:56
For the record, interlacing appears to be fine and dandy. Have had no problems since updating ffdshow. :D

Suggestion: what about a switch to make x264 adapt between SAD and SATD for frames? SATD is more costly in terms of time, but from what people have shown, it seems to be not worth the enormous speed loss. Easy frames can be SAD, complex ones SATD, or however would be most efficient to implement it. Ideally, it'd be another option in the fpel-cmp switch, on top of "sad" and "satd", you'd have "adaptive". If Hadamard was included, it could use all 3 if you weren't picky! The only comparison I can draw is the one used in WMV9 AP. This can use an adaptive motion search method to determine motion matching, and when enabled, it switches between SAD and Hadamard. To quote the help from WMV Powertoy 1.2.5.0:

SAD (Sum of Absolute Differences) is a faster but less accurate method than the Hadamard transform. Because Hadamard transforms are very computationally intensive, an automatic (macroblock-adaptive) mode exists which can dynamically choose between the two methods, providing a reasonable compromise between Hadamard quality and SAD performance.

Just my 2 US cents, worth less than 1 penny Sterling ATM. :p Hopefully this suggestion is more practical and it'd make it to the trunk! ;)

Dark Shikari
4th December 2007, 07:11
If Hadamard was included, it could use all 3 if you weren't picky!SATD is Hadamard.

I've tried this and in my experience it is not very worthwhile because of predictors; SATD predictors aren't very good for SAD, and vice versa. So using one after another generally results in worse results than just sticking with one for everything.

And SATD is a lot slower. Think 400-450 clock cycles for a 16x16 block, while SAD is 48.

XolocoTuxmaster
23rd December 2007, 01:36
Hi everybody, I'm in OpenSUSE 10.3 Linux and I have just installed x264 via YaST. It's alright, but I have no AVIS input support, so I installed also via YaST x264-devel and libx264-57. I'm new in programming and I don't know what to do now (I'm used to have a compiling readme). These are the installed packages file list

x264-devel-0.57.702-7.1 - x264 Headers and library

/usr/include/x264.h
/usr/include/x264_gtk.h
/usr/include/x264_gtk_enum.h
/usr/lib/libx264.a
/usr/lib/libx264.so
/usr/lib/libx264gtk.a
/usr/lib/libx264gtk.so


libx264-57-0.57.702-7.1 - x264 Share library, Major Version $57

/usr/lib/libx264.so.57
/usr/lib/libx264gtk.so

Can anyone tell me please how to compile x264 using this files with AVIS support?

Dark Shikari
23rd December 2007, 02:09
Hi everybody, I'm in OpenSUSE 10.3 Linux and I have just installed x264 via YaST. It's alright, but I have no AVIS input support, so I installed also via YaST x264-devel and libx264-57. I'm new in programming and I don't know what to do now (I'm used to have a compiling readme). These are the installed packages file list

x264-devel-0.57.702-7.1 - x264 Headers and library

/usr/include/x264.h
/usr/include/x264_gtk.h
/usr/include/x264_gtk_enum.h
/usr/lib/libx264.a
/usr/lib/libx264.so
/usr/lib/libx264gtk.a
/usr/lib/libx264gtk.so


libx264-57-0.57.702-7.1 - x264 Share library, Major Version $57

/usr/lib/libx264.so.57
/usr/lib/libx264gtk.so

Can anyone tell me please how to compile x264 using this files with AVIS support?Avisynth is Windows/WINE-only.

XolocoTuxmaster
23rd December 2007, 10:47
In sourceforge.net they say I can compile it for linux

http://avisynth2.cvs.sourceforge.net/*checkout*/avisynth2/avisynth/docs/html/index.html?revision=1.1.2.4&pathrev=avisynth_3_0

By they way, is avisynth the only way to have avis support in Linux? I've heard there were other ways like MPJPEGtools or something...

J_Darnley
23rd December 2007, 13:00
I am no expert but as far as I know, x264 cannot use AviSynth 3 on any OS. You can only access the avisynth 2 from Windows or Wine as it is a dll which needs to be loaded. You can use any cmd line program in Wine and then pipe the output into a native x264. Some you could use are avs2yuv (which was made just for this), ffmpeg and mencoder if you can pipe its output (I've never used it).

XolocoTuxmaster
23rd December 2007, 15:14
I'm very intrested in ffmpeg output piping. If anyone knows how to do it please tell me

Dark Shikari
23rd December 2007, 16:45
You can also use a FIFO... output mplayer/mencoder/ffmpeg in raw YV12 to a FIFO, and then use that as the input for x264.

XolocoTuxmaster
23rd December 2007, 17:17
yes J_Darnley has already suggested using a pipe/fifo, but I don't know how to do it. What I've tried is

mkfifo video.yuv

ffmpeg video.264 video.yuv & x264 -options video.yuv

Someone in this forum used these lines and said they worked

mkfifo -m 660 dvd.y4m
ffmpeg -i vts_01_0.vob -f yuv4mpegpipe - > dvd.y4m &
x264 -o dvd1.264 dvd.y4m

but when I use that I get the the pipe and the x264 file both with 0 Kb size, and ffmpeg just says

Input #0, h264, from 'video.264':
Duration: N/A, bitrate: N/A
Stream #0.0: Video: h264, yuv420p, 1920x1080 [PAR 0:1 DAR 0:1], 23.98 fps(r)
Output #0, yuv4mpegpipe, to 'pipe:':
Stream #0.0: Video: rawvideo, yuv420p, 1920x1080 [PAR 0:1 DAR 0:1], q=2-31, 200 kb/s, 23.98 fps(c)
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop encoding

But CPU doenst seem to be working

My output file is video.y4m while ffmpeg says "pipe", I don't know if that matters

I would thank If someone gave me the lines I have to use to pipe with ffmpeg

J_Darnley
23rd December 2007, 18:42
If you use raw YV12 (yuv420) in a file or a pipe/fifo then you need to specify the frame dimensions. If you use a y4m file or fifo then x264 will read the frame dimensions from from the file/fifo.

What are the exact command lines you are using? I guess you can omite the exact encoding options if you provide the input and output parts. Also, your PAR/DAR seems to very wrong. Have you tried avs2yuv? The couple of times I have used x264 and a pipe have used:

ffmpeg -benchmark -threads 2 -i "D:\AviSynth\fotr\fotr_final.avs" -vcodec copy -f rawvideo - -acodec vorbis -aq 50 -y "D:\AviSynth\fotr\fotr_audio.ogg" | x264 --encoding-options --output "D:\AviSynth\fotr\fotr_video.mkv" - 704x288

XolocoTuxmaster
23rd December 2007, 19:05
Said nothing, all solved.

dbmaxpayne
27th February 2008, 22:23
hey, is there any way to use my ATI HD3870 to hardware accelerate the encoding process of x264?

Ranguvar
27th February 2008, 22:37
Not so far, AFAIK. If you use FFT3DFilter in your Avisynth script, you can swap that out for FFT3DGPU, which runs off the graphics card. Also, nVidia's PureVideo decoder will decode MPEG-2 video and possibly others off the GPU. 99% positive it will work with other cards besides nVidia's. But no x264 GPU encoding.

nm
27th February 2008, 22:48
Also, nVidia's PureVideo decoder will decode MPEG-2 video and possibly others off the GPU. 99% positive it will work with other cards besides nVidia's.
No need to buy PureVideo decoder for that. These cards provide hardware decoding of MPEG-2, VC-1 and H.264 through DXVA(2) with any compatible DirectShow filter/player (such as MPC Home Cinema).

Ranguvar
28th February 2008, 00:13
No need to buy PureVideo decoder for that. These cards provide hardware decoding of MPEG-2, VC-1 and H.264 through DXVA(2) with any compatible DirectShow filter/player (such as MPC Home Cinema).
Ah, really? Could you please enlighten me on how to do that? Getting a 9600GT tomorrow, and even though I'll also have a quad core, it's nice to take the load off the CPU.

nm
28th February 2008, 00:19
Sorry, can't tell you much more since I don't use Windows myself. I guess it should "just work" with Cyberlink's decoder (from latest PowerDVD versions). MPC HC's DXVA support is under development, but I've heard it already works with some cards and streams.

burfadel
28th February 2008, 00:27
A month without a new build! A well deserved holiday for akupenguin/dark shikari or hard at work making big interesting changes?!

Ranguvar
28th February 2008, 06:18
Well, I know DS has been working :p Check out Xvid and x264's variance adaptive quantization, among other things.

Ranguvar
29th February 2008, 00:02
Sorry, can't tell you much more since I don't use Windows myself. I guess it should "just work" with Cyberlink's decoder (from latest PowerDVD versions). MPC HC's DXVA support is under development, but I've heard it already works with some cards and streams.
Alright, thanks... just use it in GraphEdit right? I wonder if PureVideo has one I can use that's even better.

gizmo27
17th March 2008, 11:10
Who are the of x264 cli codec authors ?

nm
17th March 2008, 12:31
Take a look at the AUTHORS file from x264 source code tree:
http://git.videolan.org/?p=x264.git;a=blob_plain;f=AUTHORS;hb=HEAD

gizmo27
17th March 2008, 13:35
Thanks a lot

SpAwN_gUy
17th March 2008, 15:59
Who are the of x264 cli codec authors ? they are :)

Rodger
30th March 2008, 23:11
May I ask where to find 64bit realeases?

I just got vista64bit installed and everything is working nice and smoothly, but MeGui....but thatīs another thing.
Now Iīm collection all my applications in 64bit "editions".

Henrikx
31st March 2008, 08:51
Till x264 core:58 r798 17e5dac all was ok. I was able to compile all versions. But today : /usr/bin/ld: soname: No such file: No such file or directory
collect2: ld gab 1 als Ende-Status zurück
make: *** [libx264.so.59] Fehler 1

Ubuntu 7.10.

Audionut
31st March 2008, 10:21
May I ask where to find 64bit realeases?

I just got vista64bit installed and everything is working nice and smoothly, but MeGui....but thatīs another thing.
Now Iīm collection all my applications in 64bit "editions".

http://members.optusnet.com.au/squid_80/

Henrikx
31st March 2008, 10:58
Now with x264 core:59 r806 457ce6a i can compile again. THX

akupenguin
31st March 2008, 11:38
http://members.optusnet.com.au/squid_80/
But that x264 build is more than a year old. The latest version will not build on win64 until someone updates the asm, because I don't have a win64 box and thus didn't support that when reorganizing everything to merge 32bit and 64bit versions.

squid_80
31st March 2008, 14:16
I stopped building when Cef started. If someone sends me the .asm(s) that won't build/run on win64 I'll try and get it working.

Rodger
31st March 2008, 15:02
But that x264 build is more than a year old. The latest version will not build on win64 until someone updates the asm, because I don't have a win64 box and thus didn't support that when reorganizing everything to merge 32bit and 64bit versions.

By the way...I compared some "old" 64bit versions with newest 32bit versions. You canīt stop developement ;)
The newer 32bit versions pulverized the older 64bit versions :rolleyes:

Correct me if Iīm wrong...the main work is done by x264 so it would help to have everything in 64bit but there would be no big bottleneck if there is missing something "in the line".

But as much as I can see....damn...the world is sleeping on 64bit Code! Seems the world is STILL not ready for 64bit.
There is still a long way until 64bit is preferred to 32bit.

Prettz
1st April 2008, 21:06
Initial review of the instructions to be included in SSE5 (http://developer.amd.com/sse5.jsp). Note that I'm only discussing the functionality, I have no idea of the speeds of the instructions yet. There were some SSSE3 instructions that looked interesting, and reduced the instruction count of some functions, but when run on a Core2 turned out to be much slower than the equivalent multiple SSE2 instructions.

First, discard all the floating-point instructions, because video codecs don't use floating-point.

PCMOV: generally useful anywhere the scalar version of the algorithm has branches, e.g. deblocking.
PCOM*: might save a MOV or a negation over PCMP*, if one wants a predicate other than EQ or LE.
PPERM: zigzag scan in 1 instruction.
PHADD*: useful in all the pixel comparison functions. (but I said the same of SSSE3's PHADD* ...)
PMADCSSWD: SSD and SSIM.
That's pretty cool. But will Intel accept it? They never implemented 3DNow!, after all.

aku, do you believe any of x264's asm routines would benefit noticeably from the extra XMM registers you get in 64-bit mode?

Dark Shikari
1st April 2008, 21:53
aku, do you believe any of x264's asm routines would benefit noticeably from the extra XMM registers you get in 64-bit mode?"Would"?

Have you looked at common/x86/dct-64.asm lately? ;)

Prettz
2nd April 2008, 15:42
"Would"?

Have you looked at common/x86/dct-64.asm lately? ;)
Nope. I take it then that they can really put those extra registers to good use?

burfadel
2nd April 2008, 16:03
By the way...I compared some "old" 64bit versions with newest 32bit versions. You canīt stop developement ;)
The newer 32bit versions pulverized the older 64bit versions :rolleyes:

Correct me if Iīm wrong...the main work is done by x264 so it would help to have everything in 64bit but there would be no big bottleneck if there is missing something "in the line".

But as much as I can see....damn...the world is sleeping on 64bit Code! Seems the world is STILL not ready for 64bit.
There is still a long way until 64bit is preferred to 32bit.

Well everything in the line has to be 64 bit, Microsoft did this as a security measure I believe. I guess you mean missed as in development wise?

lexor
2nd April 2008, 16:33
But as much as I can see....damn...the world is sleeping on 64bit Code! Seems the world is STILL not ready for 64bit.
There is still a long way until 64bit is preferred to 32bit.
I think it's hard to justify a large investment of time into writing 64bit x264 code, simply because as you can see from change logs not only is 32bit enough, they keep periodically going over stable code to reduce variables from 32bit to 16 and 8 bit integers.

Dark Shikari
2nd April 2008, 16:53
I think it's hard to justify a large investment of time into writing 64bit x264 code, simply because as you can see from change logs not only is 32bit enough, they keep periodically going over stable code to reduce variables from 32bit to 16 and 8 bit integers.Actually, reducing those variable sizes makes the code faster on 64-bit because you can more easily copy many variables at once by using 64-bit registers. That's the main reason its done (other than to save L1 cache size).

akupenguin
2nd April 2008, 17:03
I think it's hard to justify a large investment of time into writing 64bit x264 code.
There is no such thing as 64bit C code. Assembly can be x86_32 or x86_64 or whatever, but C can only be portable or not. The compiler does the arch-specific optimizing.

Pyth0n
3rd May 2008, 19:29
Trying to convert a 1280x544 video to 1280x720 video by adding 88 borders up and down with megui and avs isn't working here.


When x264 does it's second pass I get this warning.
The video encodes but with a much lower bitrate.


Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 4518 --stats "E:\TEMP\Rambo.stats" --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmin 1 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 38000 --qcomp 0.5 --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "E:\TEMP\Rambo.264" "E:\TEMP\Rambo.avs" --mvrange 511 --aud --nal-hrd --sar 1:1
avis [info]: 1280x720 @ 23.98 fps (133995 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX MMX2 SSE SSE2 SSE3 3DNow
x264 [warning]: target: 4518.00 kbit/s, expected: 149.21 kbit/s, avg QP: 1.0000
x264 [warning]: try reducing target bitrate or reducing qp_min (currently 1)
x264 [info]: slice I:5584 Avg QP:31.33 size: 7997
x264 [info]: slice P:33499 Avg QP:34.82 size: 2293
x264 [info]: slice B:94912 Avg QP:36.57 size: 935
x264 [info]: mb I I16..4: 43.5% 54.6% 1.9%
x264 [info]: mb P I16..4: 7.5% 6.4% 0.2% P16..4: 13.1% 1.0% 0.2% 0.0% 0.0% skip:71.8%
x264 [info]: mb B I16..4: 0.9% 0.9% 0.0% B16..8: 18.2% 0.1% 0.1% direct: 0.1% skip:79.7%
x264 [info]: 8x8 transform intra:50.1% inter:67.8%
x264 [info]: direct mvs spatial:0.1% temporal:99.9%
x264 [info]: ref P 77.2% 15.2% 7.6%
x264 [info]: ref B 85.9% 14.1%
x264 [info]: kb/s:300.9

encoded 133995 frames, 13.56 fps, 305.39 kb/s
desired video bitrate of this job: 4518 kbit/s - obtained video bitrate (approximate): 305 kbit/s



Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 6165 --stats "E:\TEMP\Terminator 2.stats" --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmin 1 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 38000 --qcomp 0.5 --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "E:\TEMP\Terminator 2.264" "E:\TEMP\Terminator 2.avs" --mvrange 511 --aud --nal-hrd --sar 1:1
avis [info]: 1280x720 @ 23.98 fps (196499 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX MMX2 SSE SSE2 SSE3 3DNow
x264 [warning]: target: 6165.00 kbit/s, expected: 149.01 kbit/s, avg QP: 1.0000
x264 [warning]: try reducing target bitrate or reducing qp_min (currently 1)
x264 [info]: slice I:8188 Avg QP:34.65 size: 6095
x264 [info]: slice P:49127 Avg QP:37.97 size: 3158
x264 [info]: slice B:139184 Avg QP:39.88 size: 1563
x264 [info]: mb I I16..4: 45.5% 53.5% 0.9%
x264 [info]: mb P I16..4: 14.2% 14.0% 0.2% P16..4: 13.3% 1.1% 0.1% 0.0% 0.0% skip:57.1%
x264 [info]: mb B I16..4: 2.4% 2.6% 0.0% B16..8: 25.3% 0.2% 0.2% direct: 0.1% skip:69.2%
x264 [info]: 8x8 transform intra:51.0% inter:79.9%
x264 [info]: direct mvs spatial:0.1% temporal:99.9%
x264 [info]: ref P 77.7% 15.3% 7.0%
x264 [info]: ref B 87.2% 12.8%
x264 [info]: kb/s:412.6

encoded 196499 frames, 11.92 fps, 417.08 kb/s
desired video bitrate of this job: 6165 kbit/s - obtained video bitrate (approximate): 417 kbit/s

Just to check the default qp value is 10 and I tried that value too. Tried 16 thats the x264 default and them tried 1.
I also tried 7 wich worked with the sample file but not the whole movie.
Isn't and auto value for that?

It's encoding the file but with a much lower bitrate. All my other searchs the guys where trying absurd values and the program didn't even encode it.
Just can't find the solution anywhere else.

This is the first and second pass log of a sample encode.
But I get the exactly same error with the whole movie.

Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 1 --bitrate 4518 --stats "E:\TEMP\sample.stats" --level 4.1 --keyint 24 --min-keyint 1 --bframes 3 --direct auto --subme 1 --partitions none --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 38000 --qcomp 0.5 --me dia --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output NUL "E:\TEMP\sample.avs" --mvrange 511 --aud --nal-hrd --sar 1:1
avis [info]: 1280x720 @ 23.98 fps (1487 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX MMX2 SSE SSE2 SSE3 3DNow
x264 [info]: slice I:63 Avg QP:10.33 size: 12302
x264 [info]: slice P:372 Avg QP:16.10 size: 254
x264 [info]: slice B:1052 Avg QP:17.01 size: 80
x264 [info]: mb I I16..4: 96.2% 0.0% 3.8%
x264 [info]: mb P I16..4: 0.0% 0.0% 0.0% P16..4: 1.0% 0.0% 0.0% 0.0% 0.0% skip:99.0%
x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 0.2% 0.0% 0.0% direct: 0.2% skip:99.6%
x264 [info]: final ratefactor: -17.86
x264 [info]: direct mvs spatial:11.3% temporal:88.7%
x264 [info]: kb/s:123.1

encoded 1487 frames, 46.83 fps, 128.94 kb/s

Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 4518 --stats "E:\TEMP\sample.stats" --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 38000 --qcomp 0.5 --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "E:\TEMP\sample.264" "E:\TEMP\sample.avs" --mvrange 511 --aud --nal-hrd --sar 1:1
avis [info]: 1280x720 @ 23.98 fps (1487 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX MMX2 SSE SSE2 SSE3 3DNow
x264 [warning]: target: 4518.00 kbit/s, expected: 176.69 kbit/s, avg QP: 10.0000
x264 [warning]: try reducing target bitrate or reducing qp_min (currently 10)
x264 [info]: slice I:63 Avg QP:28.49 size: 20660
x264 [info]: slice P:372 Avg QP:32.34 size: 4600
x264 [info]: slice B:1052 Avg QP:34.09 size: 1962
x264 [info]: mb I I16..4: 35.9% 57.3% 6.9%
x264 [info]: mb P I16..4: 3.4% 4.6% 0.4% P16..4: 22.6% 3.3% 0.9% 0.0% 0.0% skip:64.9%
x264 [info]: mb B I16..4: 0.2% 0.3% 0.0% B16..8: 24.9% 0.5% 0.8% direct: 0.3% skip:73.0%
x264 [info]: 8x8 transform intra:56.4% inter:63.1%
x264 [info]: direct mvs spatial:11.6% temporal:88.4%
x264 [info]: ref P 82.4% 11.8% 5.8%
x264 [info]: ref B 88.8% 11.2%
x264 [info]: kb/s:654.8


When I reduce qpmin from 10 to 7 the sample works. But not the movie.
And sometimes the sample even with 7 gives the same erro.

Tried using different's builds of x264. The one from x264.nl, the one from this site and the default megui build.

LigH
16th June 2008, 07:43
Now that you switched from SVN revision numbers to GIT date-time IDs -- how do you still keep track of the revision numbers? By counting up from a known start? I see hardly any relation anymore, reading the changelog today... Would be great to have revisions included in the changelogs too.

burfadel
16th June 2008, 09:02
I believe there are a few ways to get around the 32/64 bit problem. One way is to have the filters etc run in 32 bit avisynth which serves the output to a buffer, possibly by using a filter. At the beginning lf the 32 bit avisynth script, have another filter that spawns the 64 bit modified avisynth that can load from a .cmd file (its kind of like a .bat file). The filter can then terminate. The 64 bit avisynth then serves the data from the buffer to x264 (and possibly run 64 bit filters along the way). The 64 bit avisynth script would be unique to the x64 version, using a special source filter to load the source from the buffer instead of a file. Never said it was practical, just possible!

akupenguin
16th June 2008, 09:02
Now that you switched from SVN revision numbers to GIT date-time IDs -- how do you still keep track of the revision numbers?
git-rev-list HEAD | wc -l
or perhaps
git log | perl -e '$/="\ncommit"; $i=@t=<>; for(@t){s/\n/ r$i\n/m; $i--; print}'

I have not, however, found a suitable replacement for revision ids as git commandline arguments.

LigH
16th June 2008, 10:25
:eek: You assume that I am a developer using Linux?

:o No, I just wanted to report the changes to the community... I do not usually use SVN or GIT from a command line.
__

Furthermore: Is there an official request list where people can see if a specific request was already implemented? One user of the german board just reminds on a "keyframe to IDR cut list". As long as this thread is the closest to a "wish list", it is not easy to keep tracks of wishes and solutions.

squid_80
16th June 2008, 10:27
I believe there are a few ways to get around the 32/64 bit problem.
...
Never said it was practical, just possible!
I started to implement something like this, but never finished it off. The basic idea was the same, a separate process was spawned and a shared memory pool was used to pass video frame buffers between them. I never got around to finishing it, and besides the new avsfs project makes things a lot easier - just mount the script and the raw avi file is visible to any program, 32-bit or 64-bit.

lexor
16th June 2008, 14:38
Hey guys, a while back when GSoC started, the the guy who picked up the bframes project (I believe) said he'll be keeping people up to date either on mailing list or blog (I forget which one he said). Is that happening anywhere and if yes, does anyone have direct links?

akupenguin
16th June 2008, 15:59
You assume that I am a developer using Linux?
I assume that either you're a developer using Linux or Cygwin or OSX or some other sane commandline envireonment, or you're not a developer at all and depend on someone else to provide the changelog (http://mirror01.x264.nl/x264/changelog.txt).

Inventive Software
16th June 2008, 17:34
@devs: Came across this whilst looking for some info about new GPUs, would the instructions here: http://en.wikipedia.org/wiki/ARB_%28GPU_assembly_language%29 be of any use? My programming knowledge isn't great, but you'd probably be able to see whether this'd help in porting the search routines et al to GPUs.

LigH
16th June 2008, 19:04
Wonderful! This changelog now contains revision numbers. I read the same source earlier today (when it reported only r880) and missed them...

:thanks: for adding them!

Ratio2
28th June 2008, 12:36
I encoding i-frame only
x264.exe --ref 0 --bitrate 3000 --verbose --interlaced --keyint 1 --level 4.1 --progress -o dolphins_i2.mkv dolphins_i2.avs

MediaInfo show:
Format settings, ReFrames : 1 frame
Encoding settings : cabac=1 / ref=1 / deblock=0:0:0 / analyse=0x1:0x111 / me=hex / subme=5 / rdcmp=psy / brdo=0 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=1 / nr=0 / decimate=1 / mbaff=1 / bframes=0 / keyint=1 / keyint_min=1 / scenecut=40 / rc=abr / bitrate=3000 / ratetol=1.0 / rceq='blurCplx^(1-qComp)' / qcomp=1.00 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=2:1.00

1) Why after encoding ref = 1 if theoretically ref frames not used? (each frame will be decoded directly to destination)
2) Why interlaced flag not set in mkv container?

Ranguvar
28th June 2008, 15:31
Got two guesses, might as well share them.

1.) Either it just happens to be what x264 writes in that case, perhaps some readers of this don't understand ref=0, or maybe x264 doesn't write anything at all there, and MediaInfo is just guessing. Yes, I'm grasping at straws.
2.) Perhaps there are two places an interlaced flag can be - in the container or in the H.264 stream? And x264 writes the flag to the bitstream. Or you could not set that flag and set it when using a separate muxer to Matroska.

Dark Eiri
28th June 2008, 16:58
Correct me if i'm wrong, but I guess x264 can't use 0 ref frames.