x264 cli bugreports

[Juce]

Something wrong with dithering and/or colorspace conversion.I wrote a converter to circumvent the bug:/* rgb48le_to_yuv420p16le.c
Not copyrighted -- provided to the public domain
gcc -O2 -mfpmath=sse -march=native rgb48le_to_yuv420p16le.c -o rgb48le_to_yuv420p16le

http://www.itu.int/rec/R-REC-BT.709-5-200204-I/en page 19 (PDF page 21) */

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

/* Rec. 709 */
#define kb 0.0722
#define kr 0.2126

/* Rec. 601 */
//#define kb 0.114
//#define kr 0.299

#define input_depth 16
#define output_depth 16

#if input_depth > 8
#define input_datatype uint16_t
#else
#define input_datatype uint8_t
#endif

#if output_depth > 8
#define output_datatype uint16_t
#else
#define output_datatype uint8_t
#endif

// SET_BINARY_MODE() from http://www.zlib.net/zpipe.c
#if defined(MSDOS) || defined(OS2) || defined(WIN32) || defined(__CYGWIN__)
# include <fcntl.h>
# include <io.h>
# define SET_BINARY_MODE(file) setmode(fileno(file), O_BINARY)
#else
# define SET_BINARY_MODE(file)
#endif


int main(int argc, char **argv) {
SET_BINARY_MODE(stdin);
SET_BINARY_MODE(stdout);

void print_usage() {
fprintf(stderr, "\nusage: %s <width> <height>\n", argv[0]);
fprintf(stderr, " reads RGB48 from stdin\n");
fprintf(stderr, " writes 420p16 Rec. 709 (or something) to stdout\n");
fprintf(stderr, " <width> and <height> must be even\n");
}

void print_end_msg(int frames) {
fprintf(stderr, "\n%s converted %i frames\n", argv[0], frames);
}

int width, height;

if (argc != 3) { print_usage(); return 1; }
if (sscanf(argv[1], "%i", &width) != 1) { print_usage(); return 1; }
if (sscanf(argv[2], "%i", &height) != 1) { print_usage(); return 1; }
if (width % 2 || height % 2 || width < 2 || height < 2) { print_usage(); return 1; }

input_datatype *rgb_buf;
output_datatype *y_buf, *cb_buf, *cr_buf;

rgb_buf = malloc(width * 2 * sizeof(rgb_buf[0]) * 3);
y_buf = malloc(width * 2 * sizeof(y_buf[0]));
cb_buf = malloc((width / 2) * (height / 2) * sizeof(cb_buf[0]));
cr_buf = malloc((width / 2) * (height / 2) * sizeof(cr_buf[0]));

const double ry = kr * 219 * (1 << (output_depth - 8)) / ((1 << input_depth) - 1);
const double gy = (1 - kr - kb) * 219 * (1 << (output_depth - 8)) / ((1 << input_depth) - 1);
const double by = kb * 219 * (1 << (output_depth - 8)) / ((1 << input_depth) - 1);

const double ys = 16 * (1 << (output_depth - 8)) + .5;

const double rcb = -kr / ((1 - kb) * 2) * 244 * (1 << (output_depth - 8)) / (((1 << input_depth) - 1) * 4);
const double gcb = -(1 - kr - kb) / ((1 - kb) * 2) * 244 * (1 << (output_depth - 8)) / (((1 << input_depth) - 1) * 4);
const double bcb = (1 - kb) / ((1 - kb) * 2) * 244 * (1 << (output_depth - 8)) / (((1 << input_depth) - 1) * 4);

const double rcr = (1 - kr) / ((1 - kr) * 2) * 244 * (1 << (output_depth - 8)) / (((1 << input_depth) - 1) * 4);
const double gcr = -(1 - kr - kb) / ((1 - kr) * 2) * 244 * (1 << (output_depth - 8)) / (((1 << input_depth) - 1) * 4);
const double bcr = -kb / ((1 - kr) * 2) * 244 * (1 << (output_depth - 8)) / (((1 << input_depth) - 1) * 4);

const double cs = 128 * (1 << (output_depth - 8)) + .5;

int x, y, frame;

for (frame = 0; 1; frame++) {
for (y = 0; y < height; y += 2) {

// reads two rows at once
if (fread(rgb_buf, sizeof(rgb_buf[0]), width * 2 * 3, stdin) != width * 2 * 3) {
print_end_msg(frame);
return 0;
}

for (x = 0; x < width * 2; x++)
y_buf[x] = rgb_buf[x * 3 + 0] * ry + rgb_buf[x * 3 + 1] * gy + rgb_buf[x * 3 + 2] * by + ys;

if (fwrite(y_buf, sizeof(y_buf[0]), width * 2, stdout) != width * 2) {
print_end_msg(frame);
return 0;
}

for (x = 0; x < width; x += 2) {
int r, g, b;
r = rgb_buf[x * 3 + 0] + rgb_buf[x * 3 + 3] + rgb_buf[(x + width) * 3 + 0] + rgb_buf[(x + width) * 3 + 3];
g = rgb_buf[x * 3 + 1] + rgb_buf[x * 3 + 4] + rgb_buf[(x + width) * 3 + 1] + rgb_buf[(x + width) * 3 + 4];
b = rgb_buf[x * 3 + 2] + rgb_buf[x * 3 + 5] + rgb_buf[(x + width) * 3 + 2] + rgb_buf[(x + width) * 3 + 5];

cb_buf[x / 2 + (y / 2 * width / 2)] = r * rcb + g * gcb + b * bcb + cs;
cr_buf[x / 2 + (y / 2 * width / 2)] = r * rcr + g * gcr + b * bcr + cs;
}
}

if (fwrite(cb_buf, sizeof(cb_buf[0]), (width / 2) * (height / 2), stdout) != (width / 2) * (height / 2)) {
print_end_msg(frame);
return 0;
}

if (fwrite(cr_buf, sizeof(cr_buf[0]), (width / 2) * (height / 2), stdout) != (width / 2) * (height / 2)) {
print_end_msg(frame);
return 0;
}
}

return 0;
}


rgb48le_to_yuv420p16le 1280 720 < rgb48.raw | x264 - -o video3.mkv --demuxer raw --input-depth 16 --input-res 1280x720 --fps 25 --preset slow -q 0

raw [info]: 1280x720p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [info]: profile High 4:4:4 Predictive, level 3.1, bit depth 8
9 frames: 2.60 fps, 18593.07 kb/s
rgb48le_to_yuv420p16le converted 10 frames
x264 [info]: frame I:1 Avg QP: 0.00 size:135079
x264 [info]: frame P:9 Avg QP: 0.00 size: 87508
x264 [info]: mb I I16..4: 80.1% 18.7% 1.2%
x264 [info]: mb P I16..4: 3.3% 0.5% 0.0% P16..4: 66.5% 18.2% 10.5% 0.0% 0
.0% skip: 1.0%
x264 [info]: 8x8 transform intra:17.5% inter:56.4%
x264 [info]: coded y,uvDC,uvAC intra: 92.3% 87.6% 87.5% inter: 57.9% 89.9% 89.8%

x264 [info]: i16 v,h,dc,p: 28% 0% 60% 12%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 25% 1% 48% 6% 8% 5% 2% 2% 3%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 39% 12% 41% 2% 3% 1% 1% 0% 1%
x264 [info]: i8c dc,h,v,p: 52% 1% 34% 13%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 67.5% 0.0% 19.7% 7.7% 3.3% 1.8%
x264 [info]: kb/s:18452.96

encoded 10 frames, 2.55 fps, 18463.72 kb/s

Now the video looks better: http://img219.imageshack.us/img219/4241/video3e.png

[CruNcher]

is the rgb48 colorspace conversion even part of x264 or isn't it ffmpegs ?

[LoRd_MuldeR]

is the rgb48 colorspace conversion even part of x264 or isn't it ffmpegs ?

libswscale, I think.

[J_Darnley]

It is all libswscale

[fransky]

althought x264 doesn't allow to tweak aq-strength in --zones, but it doesn't give any warning or error like "you can't change aq in --zones" when such settings is given.

[Emulgator]

From
http://forum.doom9.org/showthread.php?t=162200
(My post #12 in this thread):
______________________________________________________________________________________

So this is Scubasteve2365's error message of Scenarist BD 5.1.3 when remuxing (I assume)
compliantly encoded elementary video that has been demuxed and cut using tsMuxeR:

ERROR|MUX_SN_E_TS_UNKNOW_ERR|P:\BD Demo Vol2\Scenarist Project\ProjectName\Test Project\02.00.0000\Output\MUX\BDRE\DB\BDMV\STREAM/00031.m2ts|0|Unknown Error|TSWrapper.dll::CTSWrapper::ProcThreadMain::This program has a bug. - m_ptsOfNextGOP is empty.|

The following is the error message of my DVD-Architect Pro 5.0.and 5.2
when attempting to mux x264-encoded interlaced elementary video:

File name: STREAM/00000.m2ts
Status: TSWrapper.dll::CTSWrapper::ProcThreadMain::This program has a bug. - m_ptsOfNextGOP is empty.

Sounds familiar. The same wording, letter by letter.
Scenarist and Sony DVD-A, they both seem to use the same muxer.

(My TSWrapper.dll in both DVD-A 5.0 and 5.2 is version 2.0.0.1 (2.0.0.0001),
Product name: mux, XML 1.0.0.0001, Copyright 2005, Size 561.152 Bytes)
____________________________________________________________________________________

Can it still be that x264-encoded streams that contain interlaced flags
might miss a certain condition of embedded parameters only at their end(s) ?
(The muxing failure is exhibited on fake-interlaced x264 encodes as well.)

The OP tells that:


The video is from a commerical blu-ray release.
I take small 3 minute or so segments from blu-rays for the purposes of demoing home theater equipment.
I simply ripped the movie to harddisk,
used TSmuxer to trim the clip to the desired start/end point and then demuxed with eac3to.
Perhaps TSMuxer damaged the trimmed clip. I've read that I shouldn't use TSMuxer for this purpose
but there isn't a lot of software out there, that I've found, that will nicely trim M2TS files.


This might suggest that trimming of an already muxing-compliant .m2ts
may lead to inconsistencies of embedded stream parameters close to the stream's end(s)
and in consequence refusal by the muxer engine of Scenarist.

SONY DVD-A Pro 5.0 and 5.2. throw the same muxer fault (word by word) when muxing x264 interlaced.
Maybe the same reason? (Inconsistencies of embedded stream parameters close to the stream's end(s))

BTW, until today I got no response from sonycreativesoftware.com about this.

The muxer fault is still there with interlaced and x264 r2074, just checked today.

[mp3dom]

Have you tried to trim the clip using Scenarist CC6 or trimming at clip level rather than using TSMuxer? By the way, both Scenarist and DVDArchitect uses the Sony muxer engine.

[Emulgator]

Thanks, mp3dom. Good to hear that my guessing about the muxer was correct though.
I have no access to Scenarist BD at the moment, but Sony DVD-A Pro 5.0+5.2, Adobe Encore CS3, DVDitProHD 6.4.

I just relied on the OP's (Scubasteve2365) findings regarding Scenarist BD.
I did not perform any trimming tests at all, I was just drawing conclusions from his results.
(I edited my post now for clarification)

So it may well be the case that interlaced x264 streams will not pass Scenarist BD as well.
The successful x264 authored BDs all seem to have had progressive content then ?

[sneaker_ger]

Quote from x264bluray.com (http://www.x264bluray.com/issues-with-certain-players):
Sony DVD-A does not support interlaced files encoded with x264.

No idea if it still applies or if it's related to your issue. Maybe some dev can comment.

[Emulgator]

I actually reported this case myself to kieranrk back then.

In between I got somebody to peek at some dlls.
I have been told that TSWrapper.dll in Scenarist BD 5.2 has the same Product Name "mux",
a size of 557.056 Bytes, shows File Version 2.4.0.6, XML is Version 2.0.0.0001, Copyright 2005-2009,
so has been developed further than the version in SONY DVD-A.

And TSWrapper.dll in my almost unusable DVDitProHD 6.4 has
Product Name "mux", size 552.960 Bytes, shows File Version 1.0.1.0 and Copyright 2005.

This is the muxer story so far.

[mp3dom]

Yes, the Scenarist muxer engine comes from Sony but it's a more advanced/up to date version than what you can find in DVD-Architect. I think Scenarist shares the exact same muxer as (Sony) Blu-Print

[Chumbo]

I was doing some encoding today and noticed that x264_64.exe keeps rebuilding the index file. I'm using CLI and my input file is an MKV. If the related .ffindex file exists would it not use it? I also tried specifically using the --index and that doesn't work either. I checked the long help and could not find any specific switch that would use the existing .ffindex file so it doesn't have to reindex every time I start the command. Here's an example of my command line:"x264_64.exe" --index "mediafile.mkv.ffindex" --pass 1 --bitrate 3000 --fps 24000/1001 --vf resize:width=1280,height=720,method=bicubic --stats "mediafile.stats" --open-gop --output NUL "mediafile.mkv"Looks like I'm using this version: x264 core:116 r2044 392e762

[EDIT] Never mind on this now. Not sure why, but now it's working fine. I don't even know what I did, but my cmd file is now running the x264 command and it's not rebuilding the index.

[EDIT2] No sorry, it's not working actually, so I still need help getting the x264_64.exe to recognize the existing .ffindex file so it doesn't have to index the input file. Any help is greatly appreciated.

[MasterNobody]

IIRC you need that ffms version used for indexing (as I understand you used standalone indexer to create index-file, not x264) and compiled in x264 was exactly same (and so have same format of index-file). Also there is check that index file must be newer than file opened.

[Chumbo]

IIRC you need that ffms version used for indexing (as I understand you used standalone indexer to create index-file, not x264) and compiled in x264 was exactly same (and so have same format of index-file). Also there is check that index file must be newer than file opened.
Yes, I have a batch file that runs several processes before doing the encoding, one of which is the indexing, e.g., ffmsindex -f -m lavf "mediafile.mkv"
I used Process Monitor to see which ffms DLL was being used by the x264 executable but none show up. So I guess the ffms library is compiled into the executable? So if my standalone version of the indexer doesn't match the library used by x264_64.exe then there's no use indexing with it?

[EDIT] Okay, I figured out the best way to approach this. When I use avs files as input, I'll just index the file myself. If I use MKV files as input, I'll just let x264 create/use the index file. That works well.

[Juce]

x264 --output-csp rgb bus_cif.y4m -o bus_rgb.mkv
ffplay bus_rgb.mkv

http://img228.imageshack.us/img228/8862/busrgb.png

Is this bug in x264 or ffplay?

x264 r2106 http://x264.nl
FFmpeg git-8475ec1 32-bit Static (Latest) (2011-10-31) http://ffmpeg.zeranoe.com/builds/

[Juce]

Looks like that ffmpeg does not detect the color space: x264 bus_rgb.mkv -o video.mkv

ffms [info]: 352x288p 35:32 @ 30/1 fps (vfr)
resize [warning]: converting from yuvj444p to yuv444p
resize [warning]: converting from yuv444p to yuv420p
x264 [info]: using SAR=35/32
x264 [info]: using cpu capabilities: MMX2 SSE2 SSE3 Cache64
x264 [info]: profile High, level 1.3
x264 [info]: frame I:1 Avg QP:28.20 size: 24834
x264 [info]: frame P:75 Avg QP:27.99 size: 8971
x264 [info]: frame B:74 Avg QP:32.54 size: 2291
x264 [info]: consecutive B-frames: 1.3% 98.7% 0.0% 0.0%
x264 [info]: mb I I16..4: 1.3% 47.0% 51.8%
x264 [info]: mb P I16..4: 0.3% 1.0% 1.4% P16..4: 32.1% 31.0% 30.7% 0.0% 0
.0% skip: 3.5%
x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 38.5% 11.5% 5.5% direct:
9.5% skip:34.9% L0:31.2% L1:38.1% BI:30.7%
x264 [info]: 8x8 transform intra:40.5% inter:56.8%
x264 [info]: coded y,uvDC,uvAC intra: 86.5% 98.9% 94.6% inter: 28.3% 60.6% 53.5%

x264 [info]: i16 v,h,dc,p: 14% 70% 8% 8%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 19% 30% 6% 4% 4% 6% 6% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 28% 28% 19% 4% 5% 4% 4% 4% 5%
x264 [info]: i8c dc,h,v,p: 39% 28% 26% 8%
x264 [info]: Weighted P-Frames: Y:4.0% UV:4.0%
x264 [info]: ref P L0: 65.7% 13.8% 14.0% 6.2% 0.3%
x264 [info]: ref B L0: 93.4% 6.6%
x264 [info]: kb/s:1387.46

encoded 150 frames, 21.57 fps, 1388.58 kb/s

[Dark Shikari]

ffmpeg doesn't support planar RGB yet.

[Snowknight26]

It does now?

http://git.videolan.org/?p=ffmpeg.git;a=commit;h=1e79926f9e8bbfa2920a1d40e36d9ffcf244fe0a

[Chikuzen]

ffmpeg support planar RGB, but libav doesn't yet.
x264.exe provided by x264.nl is using libav's libraries.

edit:
sorry, i mistook.
that patch is for planar RGB to packed RGB conversion.
ffmpeg still doesn't support packed RGB to planar RGB.

[Chumbo]

I recently encoded a batch of files and then noticed some were missing. After further investigation, I noticed that those files had UTF8 characters in the file names which x264 would not recognize and blow chunks. Any chance of updating the 32/64bit executables to support UTF8 characters please? If a title has the ?, for example, I can't use this due to it being a reserved OS character, so I use the upside down ? (¿). I also tend to use the upside down exclamation point (¡) just to avoid the pitfalls of command-line processing with it.

[LoRd_MuldeR]

As far as I see, x264 uses the plain "char" type all the way. This will support Unicode just fine on Linux, as Linux uses UTF-8 all the way. Also in its API functions!

On Windows however, the local ANSI Codepage will be used for char-strings. This means: Everything that doesn't fit into the local Codepage is already "messed up" when it arrives at the "main" function.

Also, even if you use UTF-8 inside your application, functions like fopen() won't be able to deal with UTF-8 encoded strings - on Windows.


There are basically two workarounds:

(1) Use the wchar_t type with UTF-16 all the way, on the Windows platform. This means you will have to use wmain() instead of main(), wfopen() instead of fopen(), wcslen() instead of strlen() and so on.

(2) Write short wrapper functions that convert from/to UTF-16 to/from UFT-8 for the Windows platform. This way you can keep everything to the char type with UFT-8 inside your own application.


Solution (1) requires the use of platform-specific macros all over the program code. At least if you want to support Windows (wchar_t/UTF-16) as well as Linux (char/UTF-8) with the same unmodified code.

At the same time with solution (2) 99% of your code can remain unchanged, but for every API call that goes outside your own code (and uses strings), you'll have to convert back to UTF-16 - on Windows.


I have successfully applied method (2) to a bunch of Linux tools that had been ported to Windows, but without Unicode support. It usually is not a big deal and I guess the same could be done with x264...


That's my "Unicode Support" stuff, I usually hack into Linux-style C programs:
* http://pastie.org/private/hnevzpd1cu5zv04ovptjbq
* http://pastie.org/private/acu7qmfrcyvdswmwmcjaw

And this is how you would have to change the main method to make this stuff work:
* http://pastie.org/private/uwavpv4vosjckawh0whpwa


If there is any change to get Win32 Unicode support committed into x264 (and if really nobody else has done this yet), I would be happy to submit a patch.

[kemuri-_9]

What you're only really caring about is that filenames can be utf-8, not the entirety of x264.

Updating the entirety of x264 to be utf-8 on windows is largely more extensive that what LoRd_MuldeR's patches indicate....
his patch even opens up a can of worms for placing utf-8 strings into functions that heavily expect ansi strings, which is going to cause fun issues later.

I am somehow recalling a patch from one of the x264 licensees on the subject, but not sure what happened to that exactly. Guessing it was forgotten due to lack of interest.

[LoRd_MuldeR]

Well, the good thing about UTF-8 is that all ASCII characters (which includes the "control characters", such as '\n' and friends) are identical between ANSI and UTF-8.

Moreover, all UTF-8 characters, that can not be represented in plain ASCII, are coded in a way that they cannot be confused with ASCII characters. Thus all the C string functions deal properly with UTF-8.

Also keep in mind that x264 actually is using UTF-8 encoded strings on the Linux platform, since the beginning of time. AFAIK what you gent as agrv[] in your main() method is UTF-8, on Linux.

Printing out Unicode characters properly to the Windows console, may they be encoded as UTF-8 or UTF-16 or whatever, is another funny story and probably not the most important thing to worry about ;)

BTW: The code snippets above are not patches for x264, they just give the idea how a simple patch could be made. I patched like probably a dozen tools that way and it seems to work pretty well...

(Actually this is the way how LAME does handle Unicode on the Win32 platform. Looking at the LAME code gave me the initial idea on how to do it)

[kemuri-_9]

Yes, the basic ASCII characters 0 - 0x7f are generally the same across all codepages.

However, the 0x80 to 0xff characters are primarily different for each local codepage, additionally differing from what UTF-8 has for these.

This is the 'can of worms' I was referring to.

[Dark Shikari]

The patch from Pegasys was for UTF-16 support.

[LoRd_MuldeR]

If anybody cares, I have hacked together a quick UTF-8 patch for Win32.

http://img46.imageshack.us/img46/4205/cwindowssystem32cmdexe2.th.png (http://img46.imageshack.us/img46/4205/cwindowssystem32cmdexe2.png)

[Chumbo]

What you're only really caring about is that filenames can be utf-8, not the entirety of x264.
...
That's the case for me so it can process my files named with UTF8 characters.

If anybody cares, I have hacked together a quick UTF-8 patch for Win32.

http://img46.imageshack.us/img46/4205/cwindowssystem32cmdexe2.th.png (http://img46.imageshack.us/img46/4205/cwindowssystem32cmdexe2.png)
Sweet! :) Any chance of getting this into the latest dev build? I'm on 64bit so can the 64bit be patched likewise please?

[LoRd_MuldeR]

Also added a workaround for Avisynth (and FFMS2), which, as far as I know, has no way of properly passing Unicode strings.

(Updated patch in previous post)

[LoRd_MuldeR]

Added a workaround for MP4 output too. The GPAC library doesn't support Unicode either.

(Updated patch in previous post)

[LoRd_MuldeR]

Okay, FFMS2 does support Unicode/UTF-8 paths, if initialized accordingly. Unfortunately its UTF-8 support is broken for the index file, so we still need the workaround for the index file.

(Updated patch in previous post)

[kemuri-_9]

All this is only proving is that dealing with anything non-ascii is just not worth it on windows.

it's easy enough to just rename your files...

[LoRd_MuldeR]

Well, the lack of proper Unicode support may be a negligible problem for US users, but it certainly is a big annoyance for people from certain other countries :o

Not supporting Unicode is behind the times (this is not the early Nineties anymore). And adding proper UFT-8 support for Win32 is possible - with very minor code change*.

I see few reasons to not do it. The biggest problem, at the moment, is that some third-party libs, such as Avisynth and FFMS2, screw up :scared:

While I don't think there is much hope for Avisynth, FFMS2 seems to be under active development and already does support UTF-8 - just not for the index file (yet)**.

And even for those third-party libs that we can't get to work with UTF-8, we can still convert to "short" path names internally, which works most of the time.

(I know that the generation of "short" path names can be disabled by registry hack, but I'm yet to encounter such a system. And in that very rare case, we can still rename)

__________________
(*) Most code changes in the patch are actually workarounds for third-party libs, that we hopefully can get rid of (not the libs, the workarounds), as soon as those libs are fixed
(**) It's actually a MinGW-specific problem with the fstream class. The workaround is creating your own implementation of fstream that uses wfopen() internally. I have done that for a project at work already.

[Juce]

A video is bluish if a source is 48 bit per pixel PNG.

x264 r2145 (x264.nl), Windows XP 32 bit

x264 "frame%03d.png" -o testi.mkv 2> log.txt

ffms [error]: could not create index
lavf [info]: 1280x720p 0:1 @ 25/1 fps (vfr)
resize [warning]: converting from rgb48be to rgb48le
resize [warning]: converting from rgb48le to yuv420p16le
x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [info]: profile High, level 3.1
1 frames: 0.82 fps, 1240.40 kb/s
4 frames: 2.64 fps, 567.35 kb/s
7 frames: 3.73 fps, 464.89 kb/s
10 frames: 4.51 fps, 403.86 kb/s

x264 [info]: frame I:1 Avg QP:18.33 size: 5501
x264 [info]: frame P:6 Avg QP:19.39 size: 1946
x264 [info]: frame B:3 Avg QP:21.61 size: 771
x264 [info]: consecutive B-frames: 40.0% 60.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 72.6% 26.6% 0.8%
x264 [info]: mb P I16..4: 10.2% 1.2% 0.0% P16..4: 15.2% 0.7% 2.0% 0.0% 0.0% skip:70.7%
x264 [info]: mb B I16..4: 2.9% 0.4% 0.0% B16..8: 12.9% 0.4% 0.0% direct: 0.1% skip:83.3% L0:30.9% L1:68.9% BI: 0.3%
x264 [info]: 8x8 transform intra:19.8% inter:99.7%
x264 [info]: coded y,uvDC,uvAC intra: 8.0% 25.9% 1.5% inter: 2.4% 9.2% 0.0%
x264 [info]: i16 v,h,dc,p: 43% 49% 2% 6%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 2% 12% 84% 0% 0% 0% 0% 0% 0%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 14% 72% 0% 0% 0% 0% 0% 0%
x264 [info]: i8c dc,h,v,p: 49% 43% 7% 1%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 84.4% 0.6% 12.5% 2.6%
x264 [info]: ref B L0: 45.3% 54.7%
x264 [info]: kb/s:389.84

encoded 10 frames, 4.51 fps, 403.86 kb/shttp://img27.imageshack.us/img27/641/png48src.th.png (http://imageshack.us/photo/my-images/27/png48src.png/)

PNG-images: http://www.mediafire.com/file/vc5nkbnakw627y9/frames.zip

[MasterNobody]

A video is bluish if a source is 48 bit per pixel PNG.

x264 r2145 (x264.nl), Windows XP 32 bit

x264 "frame%03d.png" -o testi.mkv 2> log.txt
...
http://img27.imageshack.us/img27/641/png48src.th.png (http://imageshack.us/photo/my-images/27/png48src.png/)

PNG-images: http://www.mediafire.com/file/vc5nkbnakw627y9/frames.zip
That is bug in lavf input (ffmpeg/libav) because there are same artefacts with:
avconv -i "frame%03d.png" -vcodec huffyuv test.avi

[professor_desty_nova]

I just noticed a difference when when input is 10bit avc with the 8bit version of x264:

with x264 revision 2120 the resize warning is: "resize [warning]: converting from yuv420p10le to yuv420p"

with x264 revision 2146 the resize warning is: "resize [warning]: converting from yuv420p10le to yuv420p16le"

Is this a bug? From the warning it seems now it's converting from 10 bit to 16bit prior to encoding in the 8bit version of x264!

I don't know if it's related to this:
If the input is 8bit, both 2120 and 2146 use the same number of I,P and B-frames.
If the input is 10bit, the resulting encode of 2120 and 2146 has a different number of I, P and B-frames.

[kemuri-_9]

This is actually not a bug, the old functionality was instead a bug:

Upon receiving input from ffmpeg/libav (whether via libavformat or ffms), the input needs to be 'normalized' into something the x264cli system can recognize.

for 8bit and 16bit per channel formats, x264cli supports these naturally (for what it does support), so no conversion is actually required.
However any intermediate bit/channel formats such as 10bit/channel need to be normalized.

Previously, most, if not all, types of such formats were normalized to 8bit. This is actually a quality degradation, so it was corrected to normalize the formats to 16bit, to allow for retention of quality when passing the data into the filtering system.

using an input -> intermediate -> final (libx264) denotation,
10 -> 8 -> 10 - what is passed to libx264 is not the same quality that was originally read in, but
10 -> 16 -> 10 has the same quality, as there was no bit-depth drop below what the input has.

[professor_desty_nova]

This is actually not a bug, the old functionality was instead a bug:

Upon receiving input from ffmpeg/libav (whether via libavformat or ffms), the input needs to be 'normalized' into something the x264cli system can recognize.

for 8bit and 16bit per channel formats, x264cli supports these naturally (for what it does support), so no conversion is actually required.
However any intermediate bit/channel formats such as 10bit/channel need to be normalized.

Previously, most, if not all, types of such formats were normalized to 8bit. This is actually a quality degradation, so it was corrected to normalize the formats to 16bit, to allow for retention of quality when passing the data into the filtering system.

using an input -> intermediate -> final (libx264) denotation,
10 -> 8 -> 10 - what is passed to libx264 is not the same quality that was originally read in, but
10 -> 16 -> 10 has the same quality, as there was no bit-depth drop below what the input has.

So, if you are using the 8bit x264 binary and start with 10bit source, it now does something like 10 -> 16 ->8.

[LoRd_MuldeR]

So, if you are using the 8bit x264 binary and start with 10bit source, it now does something like 10 -> 16 ->8.

Yes, I think so.

[kemuri-_9]

So, if you are using the 8bit x264 binary and start with 10bit source, it now does something like 10 -> 16 ->8.

Yes, this is correct.

it might be expected that a
resize [warning]: converting from yuv420p16le to yuv420p
line would exist to indicate this, but the down conversion is actually handled separately from libswscale, so there is no message.

[professor_desty_nova]

So, I guess the difference I'm seeing (If the input is 10bit, the resulting encode of 2120 and 2146 has a different number of I, P and B-frames and with the same crf the 2146 file is bigger, with 8bit input it stays the same between versions) is because now the down-conversion is handled by a different part of the x264 binary, and the result that is fed to the encoder part is not the same.

[kemuri-_9]

So, I guess the difference I'm seeing (If the input is 10bit, the resulting encode of 2120 and 2146 has a different number of I, P and B-frames and with the same crf the 2146 file is bigger, with 8bit input it stays the same between versions) is because now the down-conversion is handled by a different part of the x264 binary, and the result that is fed to the encoder part is not the same.

Yes, previously you were having libswscale perform a 10->8 conversion and that's it.
Now you're having libswscale perform a 10->16 conversion and x264cli perform a 16->8 dither.

It should be noted that there is currently a development patch to fix the dithering, so after that goes in you'll likely see the output statistics change again.

[professor_desty_nova]

OK, I guess I'll wait for the fix to the dithering, since when I compared between versions 2120 and 2146, to me 2120 seemed better.

[DiKey]

Hi. May be it is not bug, but feature, but also may be it adds some pain not to only me. And I will be happy to make x264 better.
I do not know, what have matter, what does not, so I will write about all, that I do.
1. A have an interlaced video at Adobe Premiere timeline.
2. Using 'DebugMode Frameserver" it frameserving to 01.avi with YUY2 colorspace.
3. x264.exe HAVE an --tff parameter, so it knows, that video is interlaced.
4. When x264 opens this video it wrote:

==========================================
01 D:\>x264.exe --bitrate 9150 --tune film --preset slow --pass 1 --threads 8 --blu
02 ray-compat --vbv-maxrate 18000 --vbv-bufsize 18000 --level 4.1 --sar 1:1 --keyin
03 t 25 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix
04 "bt709" --ssim -o crf18_progr.264 01.avi
05 ffms [error]: could not create index
06 lavf [error]: could not find decoder for video stream
07 avs [info]: trying AVISource... succeeded
08 avs [info]: 1440x1080p 1:1 @ 25/1 fps (cfr)
09 resize [warning]: converting from yuyv422 to yuv422p
10 resize [warning]: converting from yuv422p to yuv420p
11 x264 [warning]: --ssim used with psy on: results will be invalid!
12 x264 [warning]: --tune ssim should be used if attempting to benchmark ssim!
13 x264 [info]: using SAR=1/1
14 x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
15 x264 [info]: profile Main, level 4.1
16 [0.1%] 126/95848 frames, 15.72 fps, 3530.44 kb/s, eta 1:41:30
================================================
and, of course, start to encode... (string numbers added by myself to help read this listing)

Please, look to strings 09 and 10. Here you can see, that there is converting to progressive colorspace.
And after compressing, of course, I have color artifacts because of wrong conversion.

When I make an AVS file with such strings:

AVISource("01.avi")
ConverttoYV12(interlaced=true)

and opens it with x264.exe - everything is excellent.

But I think this is not so fast, and I cannot use 64bit x264 with my 32bit Avisynth.

Thank you.

P.S. I see, that in this example, I wrote wrong SAR 1:1 (not 4:3). It is mistake of this example, and have no a real matter.
P.P.S. English is not my first language. Sorry.

[LoRd_MuldeR]

ffms [error]: could not create index
lavf [error]: could not find decoder for video stream

As far as I know, the DebugMode Frameserver will create a "fake" AVI file.

When the application tries to read that "fake" AVI file, the data is actually frame-served rather than being read from the AVI file.

Of course this can only work if the application uses VFW (Video for Windows) to read/decode the AVI file, so DebugMode Frameserver's VFW Codec can provide the actual data.

x264 does NOT use the outdated and platform-specific VFW to decompress AVI files. It can read "raw" YUV AVI files directly. And it can use its built-in FFMS2/LAVF decoder many other formats.

But reading DebugMode Frameserver "fake" AVI will not work this way - for obvious reasons.

So you will have to use a simple Avisynth script with AVISource() for this purpose. But if you use Avisynth anyway, you may be able to drop DebugMode Frameserver completely...

[MasterNobody]

DiKey
AFAIK "p" in yuv422p and yuv420p stands not for "progressive" but for "planar" colorspace. Also IIRC swscale (which is use by x264 for resize and colorspace conversion) doesn't have analog for AviSynth "interlaced=true".

[Liisachan]

When you use psy-rd in --zones, as in this simplified sample,

x264 --pass 1 --zones 50,90,psy-rd=0.4:0 --bitrate 950 --preset fast --stats "test.log" -o NUL --frames 100 "test.avs"
x264 --pass 2 --zones 50,90,psy-rd=0.4:0 --bitrate 950 --preset fast --stats "test.log" -o test.mp4 --frames 100 "test.avs"

...you'll get a warning, "lookaheadless mb-tree requires intra refresh or infinite keyint" in the second pass (apparently when the zone is first entered at frame 50 in the above sample).

It looks like this warning is coming from x264_validate_parameters in encoder.c, as:

if( (!h->param.b_intra_refresh && h->param.i_keyint_max != X264_KEYINT_MAX_INFINITE) &&
!h->param.rc.i_lookahead && h->param.rc.b_mb_tree )
{
x264_log( h, X264_LOG_WARNING, "lookaheadless mb-tree requires intra refresh or infinite keyint\n" );
h->param.rc.b_mb_tree = 0;
}


However I'm not sure why i_lookahead becomes zero here in this case. Aren't psy-rd and i_lookahead basically independent? I think this warning might be implying there's some kind of bug behind it, though I'm fully aware that I may be simply wrong...

Is the above behavior expected? If yes, can I safely ignore this warning? Or is it not recommended to change psy-rd in zones, even though doing so seems helpful in some case? I'd appreciate it if anyone can enlighten me about this. Thank you very much in advance.

- A possibly related (unanswered) post from February, 2011:
http://forum.doom9.org/showthread.php?p=1476823#post1476823

EDIT
The above happens with another combination like --zones 50,90,deblock=.... I think the warning is not important, though confusing. Tested r2164 and 2184.

EDIT2 (June 5, 2012)
I just noticed that the problem was fixed (in r2193?), after I had decided not to use this option at all.

[Dark Shikari]

--bluray-compat only limits ref to 6 in the first place. The Blu-ray spec limits the number of reference frames to 6; the level limits for 4.1 are responsible for limiting it to 4.

[Groucho2004]

IMHO it would be better if it would be the other way around, if --vbv-maxrate would overwrite --bitrate, i.e. x264 would automatically encode with --bitrate 62500 --vbv-maxrate 62500 in that case, instead of --bitrate 99999 --vbv-maxrate 99999.
I don't understand that logic. Why would I want the encoder to target a bitrate of 62500 Kbps if I specified 99999 Kbps? If the buffer fill rate has to be increased to achieve that bitrate - so be it.

[Asmodian]

Nah, you just have to know what you are doing. Do not set a bitrate that is over the maxrate of your target? It seems pretty easy and obvious to me. Certainly not worth even a little extra work for the devs. If a GUI has an issue fix the GUI.

x264 is setup for quality over compatibility. Happily it does allow you to set it for compatibility but since this is a specific use case it assumes you know what you need to restrict for compatibility. If you know you need the restriction you must know what the restriction is, right?

The crf comparison isn't valid because you don't set a bitrate and have no idea what the final bitrate might be when starting the encode. VBV is the only bitrate you specify in that case.

Oddly you seem to be all for quality over compatibility in other areas, why not for encodes? If your playback device cannot handle the encode just buy a new one.

[Dark Shikari]

Fixed in the dev tree; clamping the bitrate does probably make slightly more sense here than clamping the maxrate. In the case where x264 is given invalid settings, it should do the least surprising thing (http://en.wikipedia.org/wiki/Principle_of_least_surprise).