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

ksnif
22nd March 2005, 10:52
:) thanks

Leo 69
25th March 2005, 17:05
Has the development stopped ?

Manao
25th March 2005, 17:10
Not at all. It just happens that Aku / Loren is away for a week. Development should resume ASAP after his return, i think.

Neo Neko
25th March 2005, 19:46
Originally posted by ksnif
Hi,

I've noticed that there is a native decoder missing from the x264 distribution. There is a decoder in the source code, but as the developers say, it is "unusable". Is there a reason for leaving the decoding side behind? is ffdshow covering all decoding needs?

I'd like to contribute to x264's development (if I'll ever find some free time). I see that the "decoder" is part of the todo list, so I could look at that (I think...). I need the standard though. Does the development team have a copy of this or is it up to me to purchase it?

regards

keep up the good work!

FFmpeg/ffdshow is pretty much covering all the decoding needs as you put it. But that should't bar you from trying. There are a few things ffdshow is not yet doing IIRC. Like automatic post processing. You can set it manually. But IIRC it is supposed to do it automatically according to flags in the bitstream.

MSlv
25th March 2005, 20:58
There hasn't been a new build for some time now. Should we blame the lack of developers? Or the new builds aren't public yet?

Sirber
25th March 2005, 21:06
code is on the SVN and the SVN is public. I'd say lack of dev :(

Manao
25th March 2005, 21:06
MSlv : look my answer two posts up.

Neo Neko : what you call automatic postprocessing is in fact adding the noise removed by the encoding during the decoding. It just has been normalized, it is part of the high profile, and it needs the encoder to analyse that noise during the encoding process.

So for the moment, FFDShow / ffmpeg is up to date, since no encoders that i know of support such 'noise' flags.

Edit : up to date, in that regard, of course. It lacks interlacing and high profile support, the first one being a living nightmare, while the second is really promosing

MSlv
26th March 2005, 08:46
Originally posted by Manao
MSlv : look my answer two posts up.
Sorry. I should've payed more attention and read the posts.

So new builds should be out soon. cool.
Thanks

hpn
27th March 2005, 12:25
Nice to see the x264 development is still alive (rev.179), although the future role of akupenguin still remains a mistery, at least for me.

ksnif
27th March 2005, 18:40
Hi everyone,

I'm trying to build libx264.dll using MS VS 6. I get the following error:

../..\common/common.h(278) : error C2485: 'align' : unrecognized extended attribute

actually I get several of these errors about "align". is there something I should include/copy ? I use cygwin's nasm. Is that a problem?

thanks in advance!

Sharktooth
27th March 2005, 19:18
If you have cygwin why don't you use gcc for building x264?

ksnif
28th March 2005, 00:04
Originally posted by Sharktooth
If you have cygwin why don't you use gcc for building x264?

I'm relatively new in software development, so I'm not very familiar with the tools. I actually use the GNU tools rather than MS's ones. I'll try to compile the dll with gcc. if you have any useful tips for me that would be nice :)

...that’s kind of embarrassing. I want to contribute to x264 project and I can not seem to get the compilation state right!:rolleyes:

Sharktooth
28th March 2005, 02:25
Try with revision 180 and MSVC.
However if you look at the x264 daily builds thread you will find all the info you need to compile x264 with gcc.

ksnif
28th March 2005, 04:16
Originally posted by Sharktooth
Try with revision 180 and MSVC.
However if you look at the x264 daily builds thread you will find all the info you need to compile x264 with gcc.

Thank you Sharktooth. I never looked further down that thread. being a sticky I though it wouldn't have anything else. I've already build the dll with gcc (didn't test it though yet). I've just tried now revision 180 with MSVC but I get the same error. I must be forgetting something.

Thanks again!:)

akupenguin
28th March 2005, 06:50
Originally posted by ksnif
I'd like to contribute to x264's development (if I'll ever find some free time). I see that the "decoder" is part of the todo list, so I could look at that (I think...). I need the standard though. Does the development team have a copy of this or is it up to me to purchase it?
You can download it from ITU (http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-H.264) (Yes it's a store, but they give you 3 free recs annually (http://www.itu.int/publications/bookshop/how-to-buy.html#free))

Sagittaire
28th March 2005, 11:22
with rev 179 bref work well for me ... thanks Manao

Edit: Playback is good but quality is not better ...

bond
28th March 2005, 13:29
Originally posted by akupenguin
You can download it from ITU (http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-H.264) (Yes it's a store, but they give you 3 free recs annually (http://www.itu.int/publications/bookshop/how-to-buy.html#free)) i also link to a version of the specs in the mpeg-4 info sticky

hpn
28th March 2005, 17:25
I just got curious and downloaded the 1864049 bytes PDF recommendation approved in 2003-05, but the ITU site reports a "superseded" status for this particular version. Akupenguin, is this the document that you are using when coding x264 or there is a newer one? I can see that the "in force" version approved in 2005-03 is yet to be published. Probably the Bond's draft version linked in the sticky is even older, but the PDF is damaged and won't open so I couldn't check.

akupenguin
28th March 2005, 17:38
The newer version (that's not published yet) only differs in that it contains high profile. For x264, I use the version I linked (which is 2004-05).

ac-chan123
28th March 2005, 18:43
i have found an other h.264 implementation(decoder only).
you can find the source and the papers at :
http://www-user.tu-chemnitz.de/~mfie/stuff/SA/

maybe it gove you a new idea. The paper h264-pres.pdf is german but h264-paper.pdf is english. The source it self seams not be commened.

baer999
31st March 2005, 21:06
Oh I am so happy that the coding on the codec are still going on, I thought that it would be the end when one of the best coders went to Nero... but now there come new releases every day like a month ago ! That's great and I hope there will be some good coders which will take part in this project, I can only VB6, HTML, PHP, Delphi but I can't C++... what have I learn to, to help the project ? When I can C++ I doesn't know really much about video coding, so can anyone give me a hint ? thx

defunkt
31st March 2005, 22:18
I'm finding the following PDF's a very useful starting point...

www.vcodex.com/h264.html (http://www.vcodex.com/h264.html)

baer999
31st March 2005, 22:56
OK thx now I can see the way it goes. When I could C++ and understand the way it is going, then i could help at the coding work or is there any other part I must learn or know ?

zombi55
1st April 2005, 00:04
Hi

I have a small request to make! Could you nicely add a key "DisplayVersion" with the n° of the version (rev), the build or the core

Ty

Zombi55 :)

TripleA
2nd April 2005, 09:16
Originally posted by baer999
Oh I am so happy that the coding on the codec are still going on, I thought that it would be the end when one of the best coders went to Nero... but now there come new releases every day like a month ago ! That's great and I hope there will be some good coders which will take part in this project, I can only VB6, HTML, PHP, Delphi but I can't C++... what have I learn to, to help the project ? When I can C++ I doesn't know really much about video coding, so can anyone give me a hint ? thx

If open source projects died when one developer ceased working on them, for whatever reason, the whole concept would have ceased to exist long ago.

The very idea of open source is to facilitate transition from one generation of developers to the next with as little disturbance as possible so that good code will live on after it's abandoned by its original coder(s), for whatever reason(s).

Unlike closed source: take Xing MPEG Player as an example; this thing was written way back at the dawn of the MPEG age in 1997, yet it's still in use today in the local market around me. The reason? It works. Does its job better than anything else. Excellent code. Never to be built on because it's closed source. Sad.

As to the situation with former x264 devs, hey! look at the bright side: Nero's CODEC will soon get so much better and this will: a) provide more choices for users and b) provide some healthy competition for the open source developers.

;)

Stacey Melissa
2nd April 2005, 17:45
Is it bad when the first pass returns negative kbit and size values? I've been messing around with the qp_constant parameter in an attempt to get it reasonably close to my target bitrate on the second pass, as suggested in the mencoder command documentation.

My encoding batch file works with 1000 frame clips of the same movie (The Matrix), but returns negative kbit and size when the whole movie is encoded.

I'm using CD's March 15 AthlonXP compile of mencoder.

The mencoder commands in my encoding batch file:

mencoder "The Matrix.avs" -noaspect -aspect 16:9
-ovc x264 -o NUL: -passlogfile "The Matrix - mencoder.log"
-x264encopts pass=1:frameref=2:bframes=5:nob_pyramid:4x4mv:
deblockalpha=-1:deblockbeta=-1:log=0:noweight_b:nochroma_me:
rc_buffer_size=3600:qp_constant=16

mencoder "The Matrix.avs" -noaspect -aspect 16:9
-ovc x264 -passlogfile "The Matrix - mencoder.log"
-x264encopts pass=2:frameref=2:bframes=5:nob_pyramid:4x4mv:
deblockalpha=-1:deblockbeta=-1:log=0:noweight_b:nochroma_me:
rc_buffer_size=3600:bitrate=1800
-o "The Matrix.264" -of rawvideo


The source AVS, from which I've made several successful encodes using other mencoder params:

LoadPlugin("C:\PROGRA~1\4ceCore\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\PROGRA~1\4ceCore\AviSynthPlugins\UnDot.dll")

mpeg2source("D:\Documents and Settings\All Users\Documents\
My Videos\DVD\The Matrix\The Matrix.d2v")

trim(62,195915)

crop(0,62,720,352)

Undot()

And here's the output of my batch file, halfway through the second pass, with the weird part in italics:

Encode x264 video and AAC audio
Movie title: The Matrix
Bitrate [kbps]: 1800
Set advanced parameters? [y/n]: n

Encoding first pass ...
06:52 PM
MEncoder dev-CVS-050315-21:28-3.4.2 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon 4 /Athlon MP/XP Palomino (Family: 6, Stepping
: 2)
Detected cache-line size is 64 bytes
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

File not found: 'frameno.avi'
Failed to open frameno.avi
success: format: 0 data: 0x0 - 0x114
AVS file format detected.
VIDEO: [YV12] 720x352 12bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:38 fourcc:0x32315659 size:720x352 fps:23.98 ftime:=0.0417
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==========================================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 720 x 352 (preferred csp: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
SwScaler: using unscaled Planar YV12 -> Planar YV12 special converter
Selected video codec: [rawyv12] vfm:raw (RAW YV12)
==========================================================================
Writing AVI header...
ODML: vprp aspect is 16384:9193.
ODML: vprp aspect is 16384:9193. Trem: 0min 0mb A-V:0.000 [0:0]
ODML: Starting new RIFF chunk at 0MB.: 0min 0mb A-V:0.000 [2294:0]
ODML: Starting new RIFF chunk at 1023MB. 0min 0mb A-V:0.000 [2474:0]
Pos:8168.6s 195855f ( 0%) 5fps Trem: 0min 0mb A-V:0.000 [-1678:0]
Flushing video frames

Writing AVI index...
Fixing AVI header...
ODML: vprp aspect is 16384:9193.

Video stream: -1678.254 kbit/s (-209781 bps) size: -1713664313 bytes 8168.794
secs 195855 frames

Encoding second pass ...
06:50 AM
MEncoder dev-CVS-050315-21:28-3.4.2 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon 4 /Athlon MP/XP Palomino (Family: 6, Stepping
: 2)
Detected cache-line size is 64 bytes
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

File not found: 'frameno.avi'
Failed to open frameno.avi
success: format: 0 data: 0x0 - 0x114
AVS file format detected.
VIDEO: [YV12] 720x352 12bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:38 fourcc:0x32315659 size:720x352 fps:23.98 ftime:=0.0417
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==========================================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 720 x 352 (preferred csp: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
SwScaler: using unscaled Planar YV12 -> Planar YV12 special converter
Selected video codec: [rawyv12] vfm:raw (RAW YV12)
==========================================================================
Writing AVI header...
Pos:3337.0s 80013f ( 0%) 7fps Trem: 0min 0mb A-V:0.000 [1680:0]

Sirber
3rd April 2005, 03:26
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE
Could be that. From what I see, your Athlon XP doesn't have SSE, and your mencoder id compiled for it.

Sharktooth
3rd April 2005, 03:42
Every athlon xp have SSE.

Stacey Melissa
3rd April 2005, 04:03
I've done quite a few encodes with this build, but I've never noticed any issues with it before. In any case, the encode seems to have worked quite beautifully. So no obvious problems. Now I just wonder whether there is anything lurking beneath the surface. That, plus I wonder whether I should still work on adjusting qp_constant to get it closer to the target bitrate, given that I don't know what the real first pass bitrate turned out to be.

hellfred
3rd April 2005, 09:38
Originally posted by Sirber
Could be that. From what I see, your Athlon XP doesn't have SSE, and your mencoder id compiled for it.
If you have enough bitrate to get a bootable Linux CDRom or a linux OS installed on your system, try to boot from Linux and check mplayers output. It will then deteced the correct instruction sets for your system. IIRC SSE was disabled on win32 due to some problems with this instruction set. At least my PIII will only output SSE when booted to linux, but not to win32.

Hellfred

Manao
3rd April 2005, 09:40
Since SSE isn't used in the encoder, it won't be a problem if it's not correctly detected. The instruction sets that really matter are MMX and MMXEXT / iSSE.

Edit : sorry, i was of topic, i thought you were speaking of x264, not mencoder...

Holy
4th April 2005, 21:06
I have one question, maybe it has been answered in any way, but I could not find it:

I downloaded the latest build ( X264VFW_rev184_p3 ) and could use it via virtual dub like any divx, xvid and co. I encoded some material but did not install anything for decoding, just have the NeroDecoder for 264 content and it worked, the material starts fine on zoomplayer, but the decoding itself and the image has many many failures, moving pixels and so on. Is it because Nero doesn't decode it correctly or is it because of the very early build of this codec?

Is there any x264-only-decoder? I tried ffdshow once for snow decoding and it worked, but all the other codecs, materials and so on were influenced too much and I also don't want any decoder to come in conflict with the NeroDecoder for 264 content when it comes to Recode content.

Thanks for your help :)

Stacey Melissa
4th April 2005, 21:46
@Holy - I've had issues with Nero's filter when trying to play back x264 content from AVI. It works well in .mp4 container, though. You'll have to extract to raw .264 stream using avi2raw and then mux the raw stream into .mp4 with mp4creator. Both are part of MPEG4IP tools (http://www.aziendeassociate.it/cd.asp?dir=/mpeg4iptools). Do a search to find out how to use them.

akupenguin
4th April 2005, 23:17
Originally posted by Stacey Melissa
Is it bad when the first pass returns negative kbit and size values? I've been messing around with the qp_constant parameter in an attempt to get it reasonably close to my target bitrate on the second pass, as suggested in the mencoder command documentation.
The error is only in MEncoder's UI. It doesn't affect the operation of x264.
To see the actual bitrate, run countquant_x264 (http://students.washington.edu/lorenm/src/x264/countquant_x264.pl) on the statsfile. (Also works for vfw 1st pass)

Stacey Melissa
5th April 2005, 00:48
Thanks, akupenguin. That's just the functionality I was needing! Now I'll just have to learn a little Perl to convert it to something my Windows box can use. No biggie - the code looks quite simple, and I've been wanting to pick up some Perl for quite awhile now. :)

Sharktooth
5th April 2005, 00:55
Easier solution: download and install Active perl (http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl)

Stacey Melissa
5th April 2005, 06:23
Thanks, Sharktooth! That works even better. Looks like I'll have to increase my qp_constant a bit, because that -1678.254 kbit/s was actually a 2527.95 kbit/s first pass. :D

virus
5th April 2005, 07:01
Originally posted by akupenguin
To see the actual bitrate, run countquant_x264 (http://students.washington.edu/lorenm/src/x264/countquant_x264.pl) on the statsfile.
Thanks for this one.

But just a note:
All: 1000 avgQP:21.77 avgBits: 2513
I: 16 ( 1.6%) avgQP:18.69 avgBits:22376
P: 283 (28.3%) avgQP:20.83 avgBits: 4836
B: 701 (70.1%) avgQP:22.22 avgBits: 1122

total size: 2513611 = 2.40 MiB = 482.13 kbps @ 23.976 fps
how can 1000 frames at 2513 avgBits sum up to a total of 2.4 MB? I assume you meant bytes not bits?

Also... feature request :D
what about modifying the output this way?
total size: 2513611 bytes = 2454.70 KiB = 2.40 MiB
bitrate: 482.13 kbps @ 23.976 fps = 502.72 kbps @ 25 fps =
602.66 kbps @ 29.97 fps

(that's too little of a change to send you a patch :))

virus

akupenguin
5th April 2005, 19:07
done.

yaz
6th April 2005, 09:09
Originally posted by Sharktooth
Easier solution: download and install Active perl (http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl) sorry for the noobish interruption but ...
- what to download a/o install from there for winxp ?
- would someone make a win32 exe from it ?
- is there sg similar for xvid ? ( i would love that too)

thx
y

virus
6th April 2005, 10:07
MSYS users should be able to launch countquant_x264 by simply typing "perl countquant_x264.pl <statsfile>" at the prompt. If it doesn't work, then Perl is probably a part of MSYS-DTK (http://prdownloads.sourceforge.net/mingw/msysDTK-1.0.1.exe?download) and you'll need to install it.

MSYS-DTK is an integration to MSYS which allows to run powerful configuration scripts. It's not required for compiling x264 nor XviD 1.0.x, but apparently it's needed for XviD 1.1.x (that's why I installed it while ago). Probably other projects need it too. So if you like to build your own code, I'd definitely recommend it.

Stacey Melissa
11th April 2005, 02:17
Would there be any way to enforce a max bitrate on 2pass encodes? My Athlon XP 1800 chokes on playback when the bitrate spikes above 8500 kbps, so I'd like to be able to set that as a bitrate ceiling. That would also give more leeway to play around with the qcomp value, since I wouldn't have to worry about spikes when increasing qcomp.

Sharktooth
11th April 2005, 12:17
The VBV options are not exposed in the VFW interface :( so, i think the only way to do that is thru mencoder or the CLI.

Stacey Melissa
11th April 2005, 12:29
That doesn't bother me, since I use mencoder anyway. ;)

Sagittaire
11th April 2005, 12:30
Originally posted by Stacey Melissa
Would there be any way to enforce a max bitrate on 2pass encodes? My Athlon XP 1800 chokes on playback when the bitrate spikes above 8500 kbps, so I'd like to be able to set that as a bitrate ceiling. That would also give more leeway to play around with the qcomp value, since I wouldn't have to worry about spikes when increasing qcomp.

IMO lower variablity can solve your problem ...

Doom9
11th April 2005, 12:48
i think the only way to do that is thru mencoder or the CLI.VBV in mencoder? Gotta read that manpage again.. I have the lingering feeling that there are quite a few parameters that haven't been in there when I started coding.

Stacey Melissa
11th April 2005, 13:06
Originally posted by Sagittaire
IMO lower variablity can solve your problem ...
Yes, it would solve the bitrate spike problem if I used a lower qcomp, but it would do so at the expense of good bitrate distribution.

Originally posted by Doom9
VBV in mencoder? Gotta read that manpage again.. I have the lingering feeling that there are quite a few parameters that haven't been in there when I started coding.
I check the mencoder manpage for new options every day. It's not in there. I'd notice it if it were. :D IIRC, (no)b_pyramid was the most recent option added to the manpage.

Sharktooth
11th April 2005, 13:08
in CLI you have this:
--rcsens <integer> CBR ratecontrol sensitivity [10]
--rcbuf <integer> Size of VBV buffer [0]
--rcinitbuf <integer> Initial VBV buffer occupancy [0]
--rceq <string> Ratecontrol equation ["blurCplx^(1-qComp)"]
--qcomp <float> 0.0 => CBR, 1.0 => CQP [0.60]
--cplxblur <float> reduce fluctuations in QP (before curve compression) [20.0]

Don't know if all those options are in mencoder too...

Doom9
11th April 2005, 13:32
scenecut and b_sens wasn't there in my original manpage.

rc_init_buffer sounds very much like rcinitbuf, but in mencoder it only seems to apply to CBR, qcomp and cplxblur is there as well, rcbuf seems to correspond to rc_buffer_size but no mention that of VBV. Did somebody forget to mention that in the manpage? Except for rceq all the parameters you mentioned seem to be there, just under a different name.

celtic_druid
12th April 2005, 02:42
Last new options added to mencoder were chroma_me and chroma_qp_offset. That was 4 weeks ago.
http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/libmpcodecs/ve_x264.c