mencoder+x264

[hitbit]

I've built (with MinGW) mplayer/mencoder with the latest revision
of x264 (48). Good news: x264 it's almost twice as fast. I've tried to encode an AVI file with b-frames enabled (without cabac) but no player (mplayer, VLC, DS based players etc) seems to be able to play these files, and some of them even managed to crash my computer. There is a player that can actually play x264 with b-frames?

(for those interested, I've managed to built a quick'n'(VERY)dirty (I'm not a competent coder...) hacked version of ffmpeg with x264 encoder. (is such thing legal, at least for personal use?). Now I can encode mp4 files with AAC and h264 (no b-frames and 2-pass, though). VLC and mplayer play them, but I wonder if these files are fully standard...)

[akupenguin]

MPlayer CVS as of september 26 should be able to play H.264 with B-frames and without CABAC, and should at least not crash with CABAC. (If it still can't, file a bug report.)

Whether it's legal to use H.264 without paying for all the patents - who knows? I'll leave that to someone who cares. But there's nothing wrong with hacking ffmpeg or x264.

And why don't you support 2-pass? It's just another x264 option, doesn't require anything special in the application.

-- Akupenguin, x264 developer.

[MfA]

Contrary to popular belief any type of use of patented technology infringes, whether it be for education/research/whatever. The amount of damages if they were ever to sue you is just lower than for infringement for commercial gain.

Source-code is slightly different since it cannot be used directly and because of the freedom of speech angle, but it hasnt really been tested in courts much ... there is a possibility that even distribution of source code could be deemed contributory infringement.

Basically you should just ignore patents if you write software ... you cant avoid them, the best you can do is to make a conscious effort not to know anything about them. So if you do end up in court at least you wont have to pay tripple damages.

Or stop writing software.

[virus]

-- Akupenguin, x264 developer.
so, you're a developer... glad to have you here :)
I wonder how the current plans of development for x264 are. Last time I checked (ffdshow-20040828) there was no 2-pass RC and the 1-pass fixed quantizer mode was b0rked. IIRC this stuff has already been fixed/added, no?

What are you working on right now? What about the future? Any info would be appreciated.

cheers :)
virus

[snacky]

ffdshow not withstanding, 2-pass has been in x264 since August 28.

[Tommy Carrot]

FFdshow also contains the fixes and the 2-pass RC, the problem is that the latest build is exactly a month old. A new build would be greatly appreciated. :)

[Sirber]

The FFDShow I have (ffdshow-20040828.exe) can only encode CBR and CQ. Is there an update?

[akupenguin]

I'm currently working on rate-distortion optimization of block types, and improving 2-pass.
Future: There are lots of features that I have some idea how to add. I may or may not get around to implementing them anytime soon.

[bond]

Originally posted by akupenguin
I'm currently working on rate-distortion optimization of block types, and improving 2-pass.
Future: There are lots of features that I have some idea how to add. I may or may not get around to implementing them anytime soon. akupenguin, cool to see that you are working on x264 :)
i hope it can one time become what xvid is now: the opensource codec, that kicks other commercial implementations ass :D

[Sirber]

Originally posted by bond
i hope it can one time become what xvid is now: the opensource codec, that kicks other commercial implementations ass :D Correction: i hope it can one time become what xvid is now: the opensource codec, that kicks other commercial MPEG4 implementations ass :D

;)

[virus]

Originally posted by akupenguin
I'm currently working on rate-distortion optimization of block types, and improving 2-pass.
Nice! I need a new ffdshow build, and I need it now. :D

Future: There are lots of features that I have some idea how to add. I may or may not get around to implementing them anytime soon.
mmh, I really hope you're not alone in your efforts.
BTW a question I had for a long time, but since no x264 dev has been here recently to answer it, I guess you are the right man :)

What about inclusion of code from XviD into x264? I'm sure there are a number of routines that can be ported successfully. I'm specifically thinking about motion estimation and maybe stuff like the keyframe insertion algorithm, or trellis quantization, which are not so closely related to the bitstream format. Is that something that can be done and it's on the TODO list, or maybe you guys don't like to reuse code written by another project and want to develop your own framework, even if it takes more time?
(not everyone is happy working with someone else's code ;))

[akupenguin]

Originally posted by virus
Nice! I need a new ffdshow build, and I need it now. :DSorry, I don't do builds for Windows. :devil:

What about inclusion of code from XviD into x264?
I have nothing against borrowing from other projects. I don't feel that x264 is "my" code any more than any other GPL project is; I simply joined x264 and added to it, just like I've submitted code to other Open Source projects. Still, I would rather port x264 to be a part of libavcodec, instead of the other way around.

I'll look into XviD's frame type decision (at least for adaptive B-frames), but I think my scene-change detection algorithm (if not the one currently in x264) is already better.
Don't hope for too much improvement in motion estimation (other than codec-specific tweaks): The plain old EPZS diamond produces very good results. Wider searches are slow, and only slightly better.
Trellis quantization is actually very dependent on bitstream format: It's purpose is to reduce some inefficiencies in Huffman coding of DCT coefficients. But H.264 uses Arithmetic coding, which doesn't suffer the same problems.

On the other hand, a good example of something not closely tied to the format is rate-control, where we did get to re-use some existing code.

[virus]

Originally posted by akupenguin
Sorry, I don't do builds for Windows. :devil:
don't worry, the request was not for you ;)
(we already have some ppl here which output nice ffdshow builds at a very fast rate... unfortunately all the recent work on x264 is not into the latest one)

I'll look into XviD's frame type decision (at least for adaptive B-frames), but I think my scene-change detection algorithm (if not the one currently in x264) is
already better.
Fine. Personally, I like the way XviD deals with the "max interval between I-frames" by lowering frame after frame the scenechange threshold until it reaches 0 (at the frame you specify as a limit). Don't know if x264 already has that, but it's a clever way to insert an I-frame where it can actually save some bits, instead of blindly forcing an I-frame when you reach the limit.

Trellis quantization is actually very dependent on bitstream format: It's purpose is to reduce some inefficiencies in Huffman coding of DCT coefficients. But H.264 uses Arithmetic coding, which doesn't suffer the same problems.
Yeah, there's CABAC. Maybe it's better to say that trellis is dependent on the entropy coder instead of the bitstream (the original paper presented trellis for H.263+, but the implementation in MPEG-4 Visual is pretty the same).

But even if you encode arithmetic, there should be some sequences that can be encoded with a shorter average length I guess and thus maybe R/D optimization can still be applied. Maybe it's not so easy to calculate the resulting rate with CABAC though ;)
Well, mine's pure speculation anyway, I don't even know what kind of data you pass to CABAC. Does it work with triplets (run, level, last) like MPEG-4 Visual?

[akupenguin]

Originally posted by virus
I like the way XviD deals with the "max interval between I-frames" by lowering frame after frame the scenechange threshold until it reaches 0 (at the frame you specify as a limit).Yes, we do that (not the exact same formula, but the same idea.) The difference is what metric you apply that threshold to: XviD predicts motion vectors from the previous frame, and compares SAD against that threshold. x264 runs the I-frame decision after encoding the frame as P, so we know exactly how much it costs to force all blocks to be I.

But even if you encode arithmetic, there should be some sequences that can be encoded with a shorter average length I guess and thus maybe R/D optimization can still be applied. Differences:
While not really harder to calculate rate with CABAC, it is slower, because you have to run the full CABAC algorithm and keep track of pending fractional bits and backup contexts, while with VLC you can just keep a table of the lengths of the codes.
You can think of CABAC as using (run,level-1,last), with run being coded in unary. But that's misleading. It's equivalent to coding as (zero,level-1,last), with (level-1,last) omitted if zero=true. Which is in turn equivalent to coding as (level,last) with (last) omitted if level=0. Each coefficient uses a separate CABAC context, so you gain nothing from merging two runs.
VLC has to use a whole number of bits per token, so you have to choose between, say, a more accurate quantization with length rounded up, and a less accurate one with length rounded down. But CABAC can use fractional bits per token, so both choices will have accurate costs, and there's not much to R/D optimize.

And just to test my theory, I tried out XviD's trellis code. Results: 0.15% reduced bitrate at a given PSNR, and 60% increased encode time. I'm sure it could be faster, but I don't hope for better quality.

[virus]

akupenguin, thanks for taking the time to answer my questions :)
Originally posted by akupenguin
And just to test my theory, I tried out XviD's trellis code.
WHAT?!? :eek:
You managed to add trellis in just a few hours?
This means that if I ask you a question about B-frames, you would make x264 fully Main Profile compliant in just a couple of days? :D

[Bogalvator]

@hitbit

Please post your exact command line to get x264 to be built into mencoder, i.e. ./configure ..... etc

I could not get configure to detect the x264 libraries when I tried with MinGW.

[akupenguin]

Originally posted by virus
You managed to add trellis in just a few hours?
This means that if I ask you a question about B-frames, you would make x264 fully Main Profile compliant in just a couple of days?
Trellis is a clever algorithm, but the implementation is pretty concise. And I could do almost a line-by-line substitution from XviD's implementation, aside from the complications of finding the length of a CABAC token. And since it didn't help and won't be included in main x264, I haven't spent the time to optimize it.
On the other hand, H.264 B-frames are nothing special conceptually, but still are a big mess of possible alternative encoding modes and lots of variables to optimize over. While I could implement a "fully compliant" B-frame encoder in a few days, it would take longer to make it effectively use all those alternatives, and even longer to develop heuristics to make it fast.
And since I've joined the FFmpeg opinion that the whole concept of B-frames and reordering is ugly, it's not high on my todo-list. OTOH, I'll have to investigate whether it's legal to use B-frames without reordering, just for the multiple predictions from the past, and avoid increasing the cost of P-frames (or avoid P-frames entirely).

[MfA]

Pity that to give up b-frames you have to give up (temporal) direct mode.

I have always missed temporal motion prediction for p-frame MV coding in h.264 (or even better meta motion compensation). Alexis Tourapis has done some work now, but that is too little too late.

[ivan_alias]

Can mencoder be used to output mp4 files? If not I guess Videolan may be the best way to take DTT sources and encode them to h.264 in an mp4 container.

Unless anyone knows of another way to do this?

[ak]

Doubtly, 'mencoder -of help' will list all available formats.

[hitbit]

mencoder can only output mpeg, avi and raw video. That's why I've tried to integrate x264 in ffmpeg, that has a huge list of output formats, including mp4. BTW, I wonder why the mencoder developers don't use libavformat muxers, since this library is already included in the program...

[bond]

avc has to be especially muxed into .mp4, i doubt that ffmpegs .mp4 support handles this! i even doubt that its mpeg-4 asp outputted .mp4 files are spec compliant

[hitbit]

avc has to be especially muxed into .mp4, i doubt that ffmpegs .mp4 support handles this! i even doubt that its mpeg-4 asp outputted .mp4 files are spec compliant

I feared that. Which is, then, a reliable way to mux AVC in .mp4?

[ak]

One can go this route:
- encode with mencoder outputing to raw h264
- mux result to mp4 using mp4creator.

Not the most prettiest way, but then again pretty much worky.

[bond]

Originally posted by hitbit
I feared that. Which is, then, a reliable way to mux AVC in .mp4?the way to store h.264 in .mp4, the spec compliant way is defined in mpeg-4 part 15 afaik

i think the latest cvs version of mp4creator can mux raw h.264 into .mp4 following this, but i never really tested it whether its really spec compliant

[BoNz1]

Originally posted by akupenguin
And since I've joined the FFmpeg opinion that the whole concept of B-frames and reordering is ugly, it's not high on my todo-list. OTOH, I'll have to investigate whether it's legal to use B-frames without reordering, just for the multiple predictions from the past, and avoid increasing the cost of P-frames (or avoid P-frames entirely).

Shame. It would be nice, if someone could provide a patch for FFmpeg to decode b-frames w/ CABAC and in-loop filtering. I mean it would be nice to at least be able to watch the Ateme encoded files in linux or windows without the help of their directshow filters. I sort of understand your position about not wanting to add b-frames to the encoder because of the amount of work it would take. But the ffmpeg position and more specifically Michael Neidermayer's position not to add support for b-frames decoding seems close to zealotry to me.

[snacky]

But the ffmpeg position and more specifically Michael Neidermayer's position not to add support for b-frames decoding seems close to zealotry to me.
You misunderstand. Nobody is opposed to putting completely working b-frame decoding in ffmpeg's h.264 decoder. It just hasn't been done yet.

[hitbit]

MPlayer CVS as of september 26 should be able to play H.264 with B-frames and without CABAC, and should at least not crash with CABAC. (If it still can't, file a bug report.)

Incidentally, even latest builds of mplayer (1/10/04) can't play
h264 with b-frames. With cabac, it flickers like hell and warn you
that you can't use b-frames with cabac. Without cabac, it plays
for some seconds and crash miserably.

To Bogalvator:
you have to compile x264, put libx264.a in mingw/lib and x264.h in mingw/include. You probably have to add this line
#include <stdarg.h>
on top of x264.h
There usually no need to add --enable-x264 in configure, because the program finds it itself.

[BoNz1]

Originally posted by snacky
You misunderstand. Nobody is opposed to putting completely working b-frame decoding in ffmpeg's h.264 decoder. It just hasn't been done yet.

No I do not misunderstand. Basically, what all the core ffmpeg developers have said is that they will not support it. They will however, accept a patch provided it is clean and not too nasty. But, honestly there are not that many developers that I know of that are actually comfortable with ffmpeg other than the core developers. So I don't see this happening any time soon. I don't know how much time and effort it would take to fully support main profile decoding in ffmpeg. It may take a lot of time, I dunno. But it can't take _that_ much time though for someone of Michael's skill. Hell, I would give him a 40GB notebook hard drive that he wanted if he would do it http://www.mplayerhq.hu/homepage/design7/donations.html It just seems to me like the core developers just want to make a statement that they hate b-frames which is just plain annoying.

[akupenguin]

Originally posted by hitbit
Incidentally, even latest builds of mplayer (1/10/04) can't play
h264 with b-frames. Without cabac, it plays for some seconds and crash miserably.
I haven't encountered such a bug. B-frames + deblocking works for me too. Want to submit a bug report with a sample file that it crashes on?

[Bogalvator]

Originally posted by hitbit

you have to compile x264, put libx264.a in mingw/lib and x264.h in mingw/include. You probably have to add this line
#include <stdarg.h>
on top of x264.h

Many many thanks hitbit, this worked a charm.

[ivan_alias]

I think this is probably the right thread..

I'm trying to convert an mpeg2 stream from DVD to x264/mp3 in avi. I'd prefer x246 and aac in mp4 but cant find a way to do that just yet.

I'm using mencoder from celtic-druid's site and I can happily do mpeg4 etc. no problem.

However x264 isnt working for me :(

here is my command line:

mencoder.exe test.mpg -oac mp3lame -ovc x264 -x264encopts qp_constant=14 -of avi -o output.avi

I'm getting this back:


C:\Documents and Settings\ade\Desktop\Downloads\mplayer2004.10.20>mencoder.exe test.mpg -oac mp3lame -ovc x264 -x264encopts qp_constant=14 -of avi -o output.avi
MEncoder dev-CVS-041020-21:23-3.4.2 (C) 2000-2004 MPlayer Team

CPU: Advanced Micro Devices Athlon MP/XP/XP-M Barton (Family: 6, Stepping: 0)
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

Reading C:/Documents and Settings/ade/Desktop/Downloads/mplayer2004.10.20/mplayer/codecs.conf: 77 audio & 181 video codecs
Reading config file C:/Documents and Settings/ade/Desktop/Downloads/mplayer2004.10.20/mplayer/mencoderfont: can't open file: C:/Documents and Settings/ade/Desktop/Downloads/mplayer2004.10.20/mplayer/font/font.desc
font: can't open file: /usr/local/share/mplayer/font/font.desc
MPEG-PS file format detected.
VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 8000.0 kbps (1000.0 kbyte/s)
[V] filefmt:2 fourcc:0x10000002 size:720x576 fps:25.00 ftime:=0.0400
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
MP3lib: init layer2&3 finished, tables done
AUDIO: 48000 Hz, 2 ch, 16 bit (0x10), ratio: 32000->192000 (256.0 kbit)
Selected audio codec: [mp3] afm:mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==========================================================================
Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
VDec: vo config request - 720 x 576 (preferred csp: Mpeg PES)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDecoder init failed :(
Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.4.0b
Selected video codec: [mpeg12] vfm:libmpeg2 (MPEG 1 or 2 (libmpeg2))
==========================================================================
Building audio filter chain for 48000Hz/2ch/16bit -> 48000Hz/2ch/16bit...
ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
VDec: vo config request - 720 x 576 (preferred csp: Planar YV12)
VDec: using Planar I420 as output csp (no 1)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.

It also says 'the selected video_out device is incompatible with this codec.

Any ideas for a working commandline for converting mpeg2 to x264?

thanks a lot

[RadicalEd]

I also get an error, using celticdruid's tbird win32 compile:mencoder.exe G:\testes\tenchi
_ffv1.avi -ovc x264 -nosound -ffourcc avc1 -passlogfile -x264encopts bitrate=100
0 keyint=300 idrint=1 frameref=10 deblockalpha=6 deblockbeta=6 qp_min=1 fullinte
r subq=5 log=3 pass=1 G:\testes\x264stats.log -o G:\testes\mencoderx264p1.avi
MEncoder dev-CVS-041022-03:26-3.4.2 (C) 2000-2004 MPlayer Team

CPU: Advanced Micro Devices Athlon Thunderbird (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

Reading C:/Tools/mplayer/mplayer/codecs.conf: 77 audio & 181 video codecs
File not found: 'frameno.avi'
Failed to open frameno.avi
Reading config file C:/Tools/mplayer/mplayer/mencoder: No such file or directory

font: can't open file: C:/Tools/mplayer/mplayer/font/font.desc
font: can't open file: /usr/local/share/mplayer/font/font.desc
success: format: 0 data: 0x0 - 0x8abda8c
AVI file format detected.
AVI_NI: No audio stream found -> no sound.
VIDEO: [FFV1] 640x480 24bpp 23.976 fps 13448.9 kbps (1641.7 kbyte/s)
[V] filefmt:3 fourcc:0x31564646 size:640x480 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: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffv1] vfm:ffmpeg (FFV1 (lossless codec))
==========================================================================
Forcing output fourcc to 31637661 [avc1]
Writing AVI header...
ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.
VDec: vo config request - 640 x 480 (preferred csp: Planar YV12)
VDec: using Planar I420 as output csp (no 4)
Movie-Aspect is undefined - no prescaling applied.
At this point mencoder crashes with the following error signature:AppName: mencoder.exe AppVer: 0.0.0.0 ModName: msvcrt.dll
ModVer: 7.0.2600.2180 Offset: 00036137

Perhaps the culprit is "Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE"?

[yaz]

Originally posted by RadicalEd
I also get an error, using celticdruid's tbird win32 compile:
At this point mencoder crashes with the following error signature:
AppName: mencoder.exe AppVer: 0.0.0.0 ModName: msvcrt.dll the same here with xp version (???)
Originally posted by RadicalEd
Perhaps the culprit is "Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE"? don't think so (my athlon xp would love that option).
to get somewhat closer i tried to encode mpeg2, divx, xvid & x264. this problem occurs only(!) with x264. i tried different sources too (vob, mpeg, avi, avis) bacause i've thought that avisynthing(ffdshow.ax) is the problem but not; no way of encoding to x264 independently of the source type.

another strange thing is that mplayer cries for some 'sdl.dll'. what's that and how can i get it ? (i've never seen this msg before)

y

[ak]

Originally posted by yaz
another strange thing is that mplayer cries for some 'sdl.dll'. what's that and how can i get it ? (i've never seen this msg before)

http://www.libsdl.org/download-1.2.php

And here's plain i686 build with runtime-cpu-detection: http://4nykey.nm.ru/bin/mencoder-cvs.exe, so it should run on PentiumPro and up.

[celtic_druid]

Hmmm, I thought that I disabled SSE.

There does/did seem to be a problem with x264 encoding. Did a fresh compile and it seems to work fine. Only did a brief test, but no more crash with default settings.

mplayer/mencoder Athlon-XP (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.22.7z)

Will try another tbird and P4 compile if I have time.

[Tommy Carrot]

Slightly offtopic, but is there anyone who could successfully encode with snow codec in mencoder? It crashes here everytime i try to use it.

[KpeX]

Originally posted by Tommy Carrot
Slightly offtopic, but is there anyone who could successfully encode with snow codec in mencoder? It crashes here everytime i try to use it. Same here, under linux, with mencoder or ffmpeg.

[hellfred]

Hy to all those that compile mplayer/mencoder themselves.
I have been doing this for quite a while now under mingw and cygwin, but I am running into problems when trying to compile x264 under MinGW. The assembler compiler nasm is missing:

Stefan@J5U7R1 ~/x264_20041020/build/cygwin
$ make
A: core/i386/dct.asm
make: nasm: Command not found
make: *** [core/i386/dct.obj] Error 127

I found some win32 builds (nasm-0.98-win32.zip) on the net and extracted them to MSYS bin (nasmw.exe and ndisasmw.exe). I had to rename nasmw.exe to nasm.exe to get it being used, but now there are syntax problems when invoking nasm:

Stefan@J5U7R1 ~/x264_20041020/build/cygwin
$ make
D: /home/Stefan/x264_20041020/build/cygwin/bin
C: core/mc.c
C: core/predict.c
D:/STEFAN/MSYS/1.0/home/Stefan/x264_20041020/core/predict.c: In function `predic t_4x4_vr':
D:/STEFAN/MSYS/1.0/home/Stefan/x264_20041020/core/predict.c:536: warning: unused variable `l3'
D:/STEFAN/MSYS/1.0/home/Stefan/x264_20041020/core/predict.c: In function `predic t_4x4_hd':
D:/STEFAN/MSYS/1.0/home/Stefan/x264_20041020/core/predict.c:569: warning: unused variable `t3'
D:/STEFAN/MSYS/1.0/home/Stefan/x264_20041020/core/predict.c: In function `predic t_4x4_vl':
D:/STEFAN/MSYS/1.0/home/Stefan/x264_20041020/core/predict.c:593: warning: unused variable `t7'
C: core/pixel.c
C: core/macroblock.c
C: core/frame.c
C: core/dct.c
C: core/cpu.c
C: core/cabac.c
C: core/common.c
C: core/mdate.c
C: core/csp.c
C: encoder/analyse.c
C: encoder/me.c
C: encoder/ratecontrol.c
C: encoder/set.c
C: encoder/macroblock.c
C: encoder/cabac.c
C: encoder/cavlc.c
C: encoder/encoder.c
C: encoder/eval.c
C: core/i386/mc-c.c
C: core/i386/dct-c.c
C: core/i386/predict.c
A: core/i386/dct.asm
nasm: no input file specified
type `nasm -h' for help
make: *** [core/i386/dct.obj] Error 1

How to get x264 compiled with the asembler code under MinGW? Or did i miss a MinGW package containing a suitable nasm.exe. Can i compile the object files under cygwin, copy them to the mingw build of x264 and link them with the other object files created by MinGWs gcc-compiler?

Hellfred

[ak]

I believe, to use snow, just like ffv1 and other experimental stuff, 'vstrict=-1' has to be added to lavcopts.

As for nasm, maybe try 'make -f Makefile.cygwin' from top dir, it should give more verbose output.

[hellfred]

Originally posted by ak
I believe, to use snow, just like ffv1 and other experimental stuff, 'vstrict=-1' has to be added to lavcopts.

As for nasm, maybe try 'make -f Makefile.cygwin' from top dir, it should give more verbose output.
The vstrict=-1 sounds reasonable, as the spezifications for snow are most probably not be finished yet and therefore vstrict=-1 should be set (strict logic of ffmpeg project)
For the Makefile.cygwin. I will compare it with the Makefile under build/cygwin. I have used that and copied the object files produced with cygwin to to the mingw bin/i386 directory. make succeeeded in building the lib and executeable, and just now i am compiling mencoder, to see if the libx264.a works correctly with the cygwin nasm objects.

Hellfred

[Bogalvator]

Hellfred, download the nasm source and compile using MinGW. Then copy the executables into the mingw\lib directory - this worked for me.

[Tommy Carrot]

Originally posted by ak
I believe, to use snow, just like ffv1 and other experimental stuff, 'vstrict=-1' has to be added to lavcopts.
Thanks, it works.

[Tommy Carrot]

Still offtopic. :D

I've played with this snow codec a bit, and forgive my enthusiasm, but i find it very great! It's still very early in the development, so there are issues/artifacts (usually miscolorization), but other than that, it's very impressive, the detail level far exceeds xvid, i would say it's on par or even a bit better than h.264. I hope Michael will continue the development, because snow has great potential to beat even h.264.

[RadicalEd]

Thanks Celtic, the new build works perfectly.

[RadicalEd]

@Tommy, where did you get information about snow's usage in mencoder? I can't seem to find any non-sourcecode documentation.

[dragongodz]

not exactl sure where this should go but since cabac and b frames mentioned in the previous page...

h264.c in ffmpeg just had this

> Allows decoding of most B-type MBs in H.264 with CABAC.
> B_Skip is still unimplemented.

thought some people here may find it of interest. :)

[BoNz1]

Originally posted by dragongodz
not exactl sure where this should go but since cabac and b frames mentioned in the previous page...

h264.c in ffmpeg just had this

> Allows decoding of most B-type MBs in H.264 with CABAC.
> B_Skip is still unimplemented.

thought some people here may find it of interest. :)

Yeah, I saw that akupenguin sent that to the mailing list a couple of days ago. Thanks :).

[hellfred]

Compiling first nasm souce code and after that x264 (using build/cygwin/Makefile) and mplayer cvs works fine using MinGW. Encoding does work, too.
Skript used for the first tests:
#!/bin/sh
#Skript to test mencoder x264encopts

#Versuch 1
#./mencoder tng.yuv -o x1_subq1.avi -ovc x264 -x264encopts qp_constant=22:fullinter:cabac=1:iframe=100:psnr:subq=1

#Versuch2 -> klappt
#./mencoder test.avi -ovc x264 -x264encopts qp_constant=22:fullinter:cabac=1:keyint=250:psnr:subq=1:deblock \
-nosound -of avi -o out.avi

#Versuch3 -> Qualität für Anime in nur einem Durchgang steigern
#./mencoder test.avi -ovc x264 -x264encopts qp_constant=22:fullinter:cabac:keyint=250:psnr:subq=2:deblock: \
deblockalpha=2:frameref=5 -nosound -of avi -o out.avi

#Versuch4 2-pass
#./mencoder test.avi -ovc x264 -x264encopts pass=1:qp_constant=22:fullinter:cabac:keyint=250:psnr: \
subq=2:deblock:deblockalpha=2:frameref=5 -nosound -of avi -o out.avi
#./mencoder test.avi -ovc x264 -x264encopts pass=2:bitrate=666:qp_min=12:qp_max=45:rc_buffer_size=5:fullinter: \
cabac:keyint=250:psnr:subq=2:deblock:deblockalpha=2:frameref=5 -nosound -of avi -o out.avi

#Versuch4a 2-pass geringere Bitrate RC mit Standartwerten + hoher Wert fur subpel-Verfeinerung
./mencoder test.avi -ovc x264 -x264encopts pass=1:qp_constant=22:fullinter:cabac:keyint=250:psnr: \
subq=4:deblock:deblockalpha=2:frameref=5 -nosound -of avi -o out.avi
./mencoder test.avi -ovc x264 -x264encopts pass=2:bitrate=450:qp_min=15:qp_max=51:qcomp=0.8:rc_buffer_size=1: \
fullinter:cabac:keyint=250:psnr:subq=4:deblock:deblockalpha=2: \
frameref=5 -nosound -of avi -o out_Versuch5.avi
Line breaks for not exeeding the width of the html page are makred with "\", and those smilies are supposed to be ": p" without the white space.
On my PIII 550MHz I get 2 fps for "Versuch2" (1 pass qp_constant=22) for a souce with resolution of 640X480 pixel under MinGW/Win98 and about double the speed on the same system/script when booting to linux.
On the PIV@3.06GHz the speed rises to about 16fps using MinGW/WinXP. Too bad that i can not install any linux distros to the haddrive of the second system.
*dreaming of 20+ fps encoding speed

Hellfred

[akupenguin]

Originally posted by hellfred
those smilies are supposed to be ": p" without the white space. You can disable smilies, you know. :p

And why are you using such a tiny rc_buffer_size ?