headers
Nihil | 19 Jun 2013 10:01
Picon

Bug (or bugs) in x264 rev 2334 OpenCL and one improvement proposal.

 >> What I was thinking was that on -p 2 and -p 3 videos frame structure is
 >> already known. So for example dividing encoding between CPU and GPU 
could be
 >> done taking frames from one I frame to next. CPU encodes one IPB set 
while
 >> GPU encodes another IPB set.
 >
 >You can't do that in an inter-frame video format; each frame depends
 >on the encoded versions of previous frames. If you want to do that,
 >you need to thread on a per-GOP level, which is basically equivalent
 >to splitting up the video and sending it to two entirely different
 >encoding apps -- which you can already do.

When it comes to h.264 (x264) GOP is what I was thinking of. Since my 
own video codec coding experience is over decade old and at that time 
and with the codec I was playing with IPB set was independent structure 
which could be encoded independently without problems since there wasn't 
outside references to B-frames. I know this from the fact because I 
implemented multi-threading to that codec while it was single thread 
encoder at the beginning. Goal of that implementation was to utilize all 
CPU power on dual CPU systems. It's kind of sad that there isn't dual 
CPU MoBo's in consumer space anymore. Most people can't buy Xeon etc 
dual CPU systems but dual CPU Haswell could be nice for some consumers.

Well personally I haven't looked into how to split video stream and 
direct it to two encoding application where one uses CPU and other uses 
GPU and after that combines output from those two application into one 
video stream. Frankly speaking that's not my cup of tea. When there is 
at least 3 or 4 different application doing just video stream encoding 
and adding multiplexing and synching to that, whole system gets way too
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean McGovern | 17 Jun 2013 09:42
Picon
Gravatar

[PATCH 1/2] version.sh: add resilience

---
 version.sh |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/version.sh b/version.sh
index 5466ef2..47d51b0 100755
--- a/version.sh
+++ b/version.sh
 <at>  <at>  -1,5 +1,8  <at>  <at> 
 #!/bin/bash
 [ -n "$1" ] && cd $1
+
+git_version() {
+trap 'rm -f config.git-hash' EXIT
 git rev-list HEAD | sort > config.git-hash
 LOCALVER=`wc -l config.git-hash | awk '{print $1}'`
 if [ $LOCALVER \> 1 ] ; then
 <at>  <at>  -15,10 +18,10  <at>  <at>  if [ $LOCALVER \> 1 ] ; then
     fi
     VER="$VER $(git rev-list HEAD -n 1 | cut -c 1-7)"
     echo "#define X264_VERSION \" r$VER\""
-else
-    echo "#define X264_VERSION \"\""
-    VER="x"
 fi
-rm -f config.git-hash
+}
+
+VER="x"
+[ -d .git ] && git_version || echo "#define X264_VERSION \"\""
(Continue reading)

Permalink | Reply | 5 comments |
headers
Nihil | 14 Jun 2013 09:24
Picon

Bug (or bugs) in x264 rev 2334 OpenCL and one improvement proposal.

 >>>> So which leaves adding OpenCL support on -p 2 and -p 3.
 >>>
 >>>Multi-pass encoding performs the lookahead on the first pass; the
 >>>lookahead doesn't run on the second pass, so there would be nothing
 >>>for OpenCL to do.
 >>
 >> Well this is my bad, I wasn't expressing myself clearly. What my 
improvement
 >> proposal kept in it and what I was thinking but not explaining 
obviously is
 >> following.
 >>
 >> To expand OpenCL and GPU usage for all possible work areas not just
 >> lookahead. After all OpenCL & GPU's are used for Bitcoin mining, 
password
 >> cracking, in heavy industry for making strength assessment, in
 >> supercomputers etc. So in sense like SMP work would be divided 
between CPU
 >> and GPU where some of the frames are processed in CPU and others in GPU.
 >
 >I'm confused; where is your proposal? Do you have a document
 >explaining how you intend to deal specifically with the
 >synchronization and parallelism problems inherent in GPU video
 >compression and interaction with an existing CPU encoder, as well as
 >restructuring or replacing all the various algorithms for which
 >efficient GPU implementation are impossible?
 >
 >It is very easy to say that you want something extraordinary to happen
 >(e.g. "I want a billion dollars and a personal starship"), but on its
 >own not very useful without some kind of plan ("how I intend to earn a
(Continue reading)

Permalink | Reply | 1 comment |
headers
Harfe Leier | 15 Jun 2013 15:58
Picon

Add new Color Primaries, Transfer Characteristics and Matrix Coefficients

Attachment (0001-Add-new-Color-Primaries-Transfer-Characteristics-and.diff): application/octet-stream, 3138 bytes
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 4 comments |
headers
Nihil | 12 Jun 2013 09:23
Picon

Bug (or bugs) in x264 rev 2334 OpenCL and one improvement proposal.

 >> So which leaves adding OpenCL support on -p 2 and -p 3.
 >
 >Multi-pass encoding performs the lookahead on the first pass; the
 >lookahead doesn't run on the second pass, so there would be nothing
 >for OpenCL to do.

Well this is my bad, I wasn't expressing myself clearly. What my 
improvement proposal kept in it and what I was thinking but not 
explaining obviously is following.

To expand OpenCL and GPU usage for all possible work areas not just 
lookahead. After all OpenCL & GPU's are used for Bitcoin mining, 
password cracking, in heavy industry for making strength assessment, in 
supercomputers etc. So in sense like SMP work would be divided between 
CPU and GPU where some of the frames are processed in CPU and others in GPU.

How many actually do something else which needs GPU while encoding 
videos? For example me, video encoding is only thing I do at that 
moment, even --threads 8 I usually use tells something which is that CPU 
is 99% utilized but GPU utilization is 0%.

I know that there is limitations what GPU's can do and bandwidth between 
main memory and GPU memory slows things down etc etc. But I have wishful 
thinking that there is some operations which can be speed up with using 
GPU's other than just lookahead.

Anyway thank you about reading my rant and giving reasonable answers.

 >Jason
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 1 comment |
headers
董 瑞涛 | 12 Jun 2013 16:27
Picon

cross-compile libx264 failure

HI，

when I cross-compile libx264, there are some error.  I have to changed the MakeFile to proceed:

1. add a space after each $(LD) and $(AR)
2. add "-r" after each $(AR)
3. delete $ <at>  after each $(LD)

when make, I cannot use LD=/dir/powerpc-linux-ld, but only LD=/dir/powerpc-linux-gcc. Or other wise it
cannot pass.
here is the message, will someone help me?

＃./configure --enable-static --host=ppc-linux --disable-asm --prefix=/usr/local/powerpc-none-linux-gnuspe
platform:      PPC
system:        LINUX
cli:           yes
libx264:       internal
shared:        no
static:        yes
asm:           no
interlaced:    yes
avs:           avxsynth
lavf:          no
ffms:          no
gpac:          no
gpl:           yes
thread:        posix
opencl:        yes
filters:       crop select_every 
debug:         no
gprof:         no
strip:         no
PIC:           no
visualize:     no
bit depth:     8
chroma format: all

＃make CC=/usr/local/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-gcc
RANLIB=/usr/local/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-ranlib
LD=/usr/local/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-ld
AR=/usr/local/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-ar STRIP=/usr/local/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-strip

…
…
…
/usr/local/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-ld: warning: cannot find
entry symbol _start; defaulting to 10001524
x264.o: In function `print_status':
x264.c:(.text+0x184): undefined reference to `__floatdidf'
x264.c:(.text+0x1ac): undefined reference to `__floatdidf'
x264.c:(.text+0x238): undefined reference to `__divdi3'
x264.c:(.text+0x3ac): undefined reference to `__floatdidf'
x264.c:(.text+0x3f0): undefined reference to `__floatdidf'
x264.o: In function `encode':
x264.c:(.text+0x744): undefined reference to `__divdi3'
x264.c:(.text+0x750): undefined reference to `__divdi3'
x264.c:(.text+0x970): undefined reference to `__fixdfdi'
x264.c:(.text+0xa40): undefined reference to `__floatdidf'
x264.c:(.text+0xd70): undefined reference to `__floatdidf'
x264.c:(.text+0xdbc): undefined reference to `__fixdfdi'
x264.c:(.text+0xf18): undefined reference to `__floatdidf'
x264.c:(.text+0xfec): undefined reference to `__floatdidf'
x264.c:(.text+0x1030): undefined reference to `__floatdidf'
x264.c:(.text+0x126c): undefined reference to `__floatdidf'
x264.o: In function `main':
x264.c:(.text+0x3fd8): undefined reference to `__floatundidf'
x264.c:(.text+0x3ff8): undefined reference to `__floatundidf'
input/input.o: In function `x264_cli_pic_plane_size':
input.c:(.text+0x120): undefined reference to `__floatundisf'
input.c:(.text+0x128): undefined reference to `__fixunssfdi'
input.c:(.text+0x17c): undefined reference to `__floatundisf'
input.c:(.text+0x184): undefined reference to `__fixunssfdi'
input/input.o: In function `x264_cli_pic_alloc':
input.c:(.text+0x2e0): undefined reference to `__floatundisf'
input.c:(.text+0x370): undefined reference to `__fixunssfdi'
input.c:(.text+0x62c): undefined reference to `__fixunssfdi'
input/input.o: In function `x264_cli_pic_size':
input.c:(.text+0x6cc): undefined reference to `__floatundisf'
input.c:(.text+0x704): undefined reference to `__fixunssfdi'
input.c:(.text+0x7a8): undefined reference to `__fixunssfdi'
input/timecode.o: In function `try_mkv_timebase_den':
timecode.c:(.text+0x254): undefined reference to `__fixunsdfdi'
timecode.c:(.text+0x2fc): undefined reference to `__umoddi3'
input/timecode.o: In function `correct_fps':
timecode.c:(.text+0x444): undefined reference to `__floatundidf'
timecode.c:(.text+0x4a4): undefined reference to `__fixunsdfdi'
timecode.c:(.text+0x53c): undefined reference to `__floatundidf'
timecode.c:(.text+0x5ac): undefined reference to `__umoddi3'
timecode.c:(.text+0x5d4): undefined reference to `__udivdi3'
input/timecode.o: In function `open_file':
timecode.c:(.text+0xe60): undefined reference to `__floatundidf'
timecode.c:(.text+0xee0): undefined reference to `__fixunsdfdi'
timecode.c:(.text+0xf38): undefined reference to `__umoddi3'
timecode.c:(.text+0xf64): undefined reference to `__udivdi3'
timecode.c:(.text+0xf9c): undefined reference to `__floatundidf'
timecode.c:(.text+0x12b0): undefined reference to `__umoddi3'
timecode.c:(.text+0x12f4): undefined reference to `__udivdi3'
timecode.c:(.text+0x1318): undefined reference to `__udivdi3'
timecode.c:(.text+0x138c): undefined reference to `__floatundidf'
timecode.c:(.text+0x13a8): undefined reference to `__floatundidf'
timecode.c:(.text+0x1400): undefined reference to `__fixdfdi'
input/timecode.o: In function `read_frame':
timecode.c:(.text+0x1b30): undefined reference to `__floatundidf'
timecode.c:(.text+0x1b48): undefined reference to `__floatundidf'
timecode.c:(.text+0x1b88): undefined reference to `__fixdfdi'
timecode.c:(.text+0x1bb0): undefined reference to `__floatundidf'
timecode.c:(.text+0x1bc8): undefined reference to `__floatundidf'
timecode.c:(.text+0x1c24): undefined reference to `__fixdfdi'
input/raw.o: In function `open_file':
raw.c:(.text+0x21c): undefined reference to `__udivdi3'
raw.c:(.text+0x450): undefined reference to `__udivdi3'
input/y4m.o: In function `open_file':
y4m.c:(.text+0x6a4): undefined reference to `__udivdi3'
y4m.c:(.text+0x884): undefined reference to `__udivdi3'
output/matroska.o: In function `set_param':
matroska.c:(.text+0xa4): undefined reference to `__divdi3'
matroska.c:(.text+0xf8): undefined reference to `__divdi3'
matroska.c:(.text+0x11c): undefined reference to `__divdi3'
output/matroska.o: In function `close_file':
matroska.c:(.text+0x184): undefined reference to `__divdi3'
matroska.c:(.text+0x188): undefined reference to `__floatdidf'
matroska.c:(.text+0x1c0): undefined reference to `__fixdfdi'
output/matroska.o: In function `write_frame':
matroska.c:(.text+0x294): undefined reference to `__floatdidf'
matroska.c:(.text+0x2f4): undefined reference to `__fixdfdi'
output/matroska_ebml.o: In function `mk_flush_frame':
matroska_ebml.c:(.text+0x1308): undefined reference to `__divdi3'
matroska_ebml.c:(.text+0x1490): undefined reference to `__divdi3'
output/matroska_ebml.o: In function `mk_close':
matroska_ebml.c:(.text+0x1dec): undefined reference to `__floatdidf'
matroska_ebml.c:(.text+0x1e04): undefined reference to `__floatdidf'
output/flv.o: In function `write_frame':
flv.c:(.text+0xa4): undefined reference to `__floatdidf'
flv.c:(.text+0xd8): undefined reference to `__fixdfdi'
flv.c:(.text+0xf4): undefined reference to `__floatdidf'
flv.c:(.text+0x124): undefined reference to `__fixdfdi'
flv.c:(.text+0x340): undefined reference to `__divdi3'
flv.c:(.text+0x35c): undefined reference to `__floatdidf'
flv.c:(.text+0x390): undefined reference to `__fixdfdi'
flv.c:(.text+0x3e4): undefined reference to `__floatdidf'
flv.c:(.text+0x41c): undefined reference to `__fixdfdi'
flv.c:(.text+0x450): undefined reference to `__floatdidf'
flv.c:(.text+0x484): undefined reference to `__fixdfdi'
flv.c:(.text+0x510): undefined reference to `__floatdidf'
flv.c:(.text+0x54c): undefined reference to `__fixdfdi'
output/flv.o: In function `close_file':
flv.c:(.text+0xd50): undefined reference to `__floatdidf'
flv.c:(.text+0xe48): undefined reference to `__floatundidf'
flv.c:(.text+0xee4): undefined reference to `__floatundidf'
flv.c:(.text+0xfbc): undefined reference to `__floatdidf'
filters/video/select_every.o: In function `init':
select_every.c:(.text+0x4b0): undefined reference to `__udivdi3'
libx264.a(common.o): In function `x264_reduce_fraction64':
common.c:(.text+0x10c): undefined reference to `__umoddi3'
common.c:(.text+0x130): undefined reference to `__umoddi3'
common.c:(.text+0x164): undefined reference to `__udivdi3'
common.c:(.text+0x180): undefined reference to `__udivdi3'
libx264.a(set.o): In function `x264_validate_levels':
set.c:(.text+0x288): undefined reference to `__divdi3'
libx264.a(encoder.o): In function `x264_encoder_open_133':
encoder.c:(.text+0x3f84): undefined reference to `__udivdi3'
libx264.a(encoder.o): In function `x264_encoder_frame_end':
encoder.c:(.text+0x651c): undefined reference to `__floatdidf'
encoder.c:(.text+0x6594): undefined reference to `__floatdidf'
encoder.c:(.text+0x6600): undefined reference to `__floatdidf'
encoder.c:(.text+0x6668): undefined reference to `__floatdidf'
libx264.a(encoder.o): In function `x264_encoder_close':
encoder.c:(.text+0x6a94): undefined reference to `__floatdidf'
libx264.a(encoder.o):encoder.c:(.text+0x6b18): more undefined references to `__floatdidf' follow
libx264.a(set.o): In function `x264_cqm_init':
set.c:(.text+0x1120): undefined reference to `__udivdi3'
set.c:(.text+0x1164): undefined reference to `__udivdi3'
set.c:(.text+0x11a8): undefined reference to `__udivdi3'
set.c:(.text+0x11ec): undefined reference to `__udivdi3'
set.c:(.text+0x1230): undefined reference to `__udivdi3'
libx264.a(set.o):set.c:(.text+0x1274): more undefined references to `__udivdi3' follow
libx264.a(analyse.o): In function `x264_weights_analyse':
analyse.c:(.text+0x102d0): undefined reference to `__floatundisf'
analyse.c:(.text+0x102e0): undefined reference to `__floatundisf'
analyse.c:(.text+0x10358): undefined reference to `__floatundisf'
analyse.c:(.text+0x10368): undefined reference to `__floatundisf'
analyse.c:(.text+0x103d8): undefined reference to `__floatundisf'
libx264.a(analyse.o):analyse.c:(.text+0x103e8): more undefined references to `__floatundisf' follow
libx264.a(analyse.o): In function `x264_slicetype_frame_cost':
analyse.c:(.text+0x11014): undefined reference to `__udivdi3'
analyse.c:(.text+0x11460): undefined reference to `__udivdi3'
libx264.a(analyse.o): In function `x264_slicetype_analyse':
analyse.c:(.text+0x18290): undefined reference to `__floatdidf'
analyse.c:(.text+0x182d4): undefined reference to `__floatdidf'
analyse.c:(.text+0x183e0): undefined reference to `__floatdidf'
analyse.c:(.text+0x18424): undefined reference to `__floatdidf'
libx264.a(analyse.o): In function `x264_slicetype_decide':
analyse.c:(.text+0x19498): undefined reference to `__floatdidf'
libx264.a(analyse.o):analyse.c:(.text+0x19b00): more undefined references to `__floatdidf' follow
libx264.a(analyse.o): In function `x264_mb_analyse_transform_rd':
analyse.c:(.text+0x22fb0): undefined reference to `__divdi3'
libx264.a(ratecontrol.o): In function `x264_hrd_fullness':
ratecontrol.c:(.text+0x720): undefined reference to `__udivdi3'
ratecontrol.c:(.text+0x760): undefined reference to `__udivdi3'
ratecontrol.c:(.text+0x794): undefined reference to `__floatundisf'
ratecontrol.c:(.text+0x7a4): undefined reference to `__floatdisf'
ratecontrol.c:(.text+0x7d0): undefined reference to `__floatundisf'
ratecontrol.c:(.text+0x858): undefined reference to `__udivdi3'
ratecontrol.c:(.text+0x890): undefined reference to `__udivdi3'
libx264.a(ratecontrol.o): In function `x264_adaptive_quant_frame':
ratecontrol.c:(.text+0x165c): undefined reference to `__udivdi3'
ratecontrol.c:(.text+0x16d8): undefined reference to `__udivdi3'
ratecontrol.c:(.text+0x1740): undefined reference to `__udivdi3'
libx264.a(ratecontrol.o): In function `get_qscale':
ratecontrol.c:(.text+0x3634): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0x3788): undefined reference to `__floatdidf'
libx264.a(ratecontrol.o): In function `x264_ratecontrol_init_reconfigurable':
ratecontrol.c:(.text+0x3c54): undefined reference to `__fixdfdi'
libx264.a(ratecontrol.o): In function `init_pass2':
ratecontrol.c:(.text+0x430c): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0x4368): undefined reference to `__fixunsdfdi'
ratecontrol.c:(.text+0x4624): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0x4748): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0x4b9c): undefined reference to `__floatundidf'
ratecontrol.c:(.text+0x5330): undefined reference to `__fixunsdfdi'
ratecontrol.c:(.text+0x57ac): undefined reference to `__floatundidf'
ratecontrol.c:(.text+0x58d4): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0x5ccc): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0x6170): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0x62e0): undefined reference to `__fixunsdfdi'
ratecontrol.c:(.text+0x649c): undefined reference to `__fixdfdi'
ratecontrol.c:(.text+0x64cc): undefined reference to `__fixdfdi'
ratecontrol.c:(.text+0x68b4): undefined reference to `__floatdidf'
libx264.a(ratecontrol.o): In function `x264_ratecontrol_new':
ratecontrol.c:(.text+0x6ec8): undefined reference to `__udivdi3'
ratecontrol.c:(.text+0x6ee8): undefined reference to `__udivdi3'
ratecontrol.c:(.text+0x6eec): undefined reference to `__floatundidf'
libx264.a(ratecontrol.o): In function `x264_ratecontrol_end':
ratecontrol.c:(.text+0xa0b0): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0xa1ac): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0xa6d8): undefined reference to `__udivdi3'
ratecontrol.c:(.text+0xa730): undefined reference to `__floatdidf'
libx264.a(ratecontrol.o): In function `rate_estimate_qscale':
ratecontrol.c:(.text+0xa9c8): undefined reference to `__fixdfdi'
ratecontrol.c:(.text+0xaa08): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0xaaec): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0xaf38): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0xafa0): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0xb1c8): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0xb214): undefined reference to `__fixdfdi'
ratecontrol.c:(.text+0xb23c): undefined reference to `__floatundidf'
ratecontrol.c:(.text+0xb270): undefined reference to `__floatundidf'
ratecontrol.c:(.text+0xb360): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0xb3b0): undefined reference to `__fixdfdi'
libx264.a(ratecontrol.o): In function `x264_ratecontrol_start':
ratecontrol.c:(.text+0xc050): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0xc09c): undefined reference to `__divdi3'
ratecontrol.c:(.text+0xc0a0): undefined reference to `__floatdidf'
ratecontrol.c:(.text+0xc388): undefined reference to `__floatdidf'
libx264.a(macroblock.o): In function `x264_noise_reduction_update':
macroblock.c:(.text+0x1538): undefined reference to `__udivdi3'
make: *** [x264] error 1

_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 2 comments |
headers
Nihil | 11 Jun 2013 18:18
Picon

Bug (or bugs) in x264 rev 2334 OpenCL and one improvement proposal.

Thank you from answering and doing that pretty fast.

 >> x264 [error]: malloc of size 10031104 failed
 >> x264 [error]: x264_encoder_encode failed
 >
 >Your system ran out of allocateable memory when using very
 >memory-intensive x264 settings; this is not a bug in x264. If you need
 >to use settings that require more than 4GB of address space, I suggest
 >you upgrade to 64-bit x264.

I somewhat disagree here. Here's information I got with ProcessHacker.

No -p option

Peak Working Set 1,23GB
Peak Virtual Size 1,94GB
Peak Private Bytes 1,76GB

x264 [error]: malloc of size 10031104 failed
x264 [error]: x264_encoder_encode failed

-p 1

Peak Working Set 1,14GB
Peak Virtual Size 1,78GB
Peak Private Bytes 1,59GB

And the video file was same as in my original post. 1920*1200 15fps 
fraps avi which has 255 frames and size is around 467MB.

So only thing that gets close to 2GB barrier while there isn't -p option 
used is virtual size. But even if 2GB barrier is culprit I was kind of 
expecting that x264 project has defined IMAGE_FILE_LARGE_ADDRESS_AWARE 
flag to be set in 32bit Windows makefile in which case x264 could hoard 
3GB of memory in 32bit Windows systems.

Going forward from malloc fail, is OpenCL supported in -p 2 and -p 3? If 
not then that improvement comment was valid. (of course it could be 
somewhat possible that memory handling caused OpenCL message not to be 
shown with -p 2 and -p 3)

Now out of topic. I actually do have 64bit Windows 7 Pro but sadly it 
doesn't support my old trusted NIC (3Com 3C905B). So I have been waiting 
to make some bigger HW upgrades but . . .

And installing 64bit Linux well there's other reasons against that.

 >> Add commandline option for storing ffms file index. I deal with 
large static
 >> files (not using AviSynth or some such) and when doing "Nth pass" a 
lot of
 >> time is wasted. It would be nice if file index could be saved in 
same manner
 >> as x264_lookahead.clbin x264_2pass.log x264_2pass.log.mbtree files 
so file
 >> indexing needs to be done only once.

Thank you about this. From some reason my brain didn't connect this 
parameter to ffms and storing the index. Oh well everyone needs brain 
barf from time to time.

 >This is what --index does.
 >
 >Jason
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 2 comments |
headers
Leo Born | 11 Jun 2013 17:09
Picon

x264 Loss resilience features

Hi,

Does x264 encoder support loss resilience features?:

 - Flexible macroblock ordering (FMO)

 - Arbitrary slice ordering (ASO)

 - Redundant slices (RS)


Thank you. Regards,

Leo Born
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 1 comment |
headers
赵德祥 | 11 Jun 2013 21:04
Picon
Favicon

greetings

http://www.doctorhealth.tw/components/com_mailto/facebook.php?kawocdtdq795unasb.html




































































































mightyzdx
赵德祥
**********
No academic ever expects to be taken seriously by more than three other people, because really, we write for three other people in our field. -- Howard Gardner
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 0 comments |
headers
Nihil | 11 Jun 2013 10:53
Picon

Bug (or bugs) in x264 rev 2334 OpenCL and one improvement proposal.

I'm sorry that I can't provide dumps or debug traces of what happens. 
I'm also sorry about the fact that I haven't tested out every possible 
commandline variation.

I downloaded precompiled 32bit Windows executable from x264.nl.

x264 executable: 8bit-depth 32bit Windows

Test system: 32bit Windows XP, nVidia GFX 670 driver 320.18 WHQL

Test video: 1920*1200 Fraps v3.5.9.15586 AVI

Problems:

Using parameters

-p 1
-p 2
-p 3

Fast "indexing input file"

NO -p options

Slow "indexing input file"

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

-p 1 | OpenCL acceleration enabled - Works
-p 2 | OpenCL not enabled
-p 3 | OpenCL not enabled

NO -p options | OpenCL acceleration enabled - But fails

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

x264_2334.exe -I 150 -b 100 --b-adapt 2 -B 4000 -m 10 -t 2 --direct auto 
--me esa --merange 24 --partitions all --ref 16 --rc-lookahead 60 
--threads 8 --opencl --qpmin 5 --log-level debug -o test.flv test_enc.avi

ffms [info]: 1920x1200p 0:1  <at>  15/1 fps (vfr)
x264 [debug]: using mv_range_thread = 72
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce 
GTX 670
x264 [info]: profile High, level 5.1
x264 [debug]: frame=   0 QP=12.42 NAL=3 Slice:I Poc:0   I:9000 P:0 
SKIP:0    size=1023133 bytes
flv [info]: initial delay 133 ms
x264 [debug]: frame=   1 QP=15.73 NAL=2 Slice:P Poc:10  I:10   P:1756 
SKIP:7234 size=111586 bytes
x264 [debug]: frame=   2 QP=22.61 NAL=2 Slice:B Poc:6   I:6    P:1200 
SKIP:7615 size=19476 bytes
x264 [debug]: frame=   3 QP=22.41 NAL=0 Slice:B Poc:2   I:1    P:1036 
SKIP:7779 size=12854 bytes
x264 [debug]: frame=   4 QP=22.92 NAL=0 Slice:B Poc:4   I:0    P:1209 
SKIP:7549 size=10635 bytes
x264 [debug]: frame=   5 QP=22.96 NAL=0 Slice:B Poc:8   I:0    P:617 
SKIP:8092 size=7375 bytes
x264 [debug]: frame=   6 QP=15.31 NAL=2 Slice:P Poc:16  I:7    P:1687 
SKIP:7306 size=85615 bytes
x264 [debug]: frame=   7 QP=22.42 NAL=2 Slice:B Poc:14  I:0    P:980 
SKIP:7798 size=8859 bytes
x264 [debug]: frame=   8 QP=22.75 NAL=0 Slice:B Poc:12  I:3    P:1003 
SKIP:7808 size=8233 bytes
x264 [debug]: frame=   9 QP=25.37 NAL=2 Slice:P Poc:28  I:7    P:731 
SKIP:8262 size=19342 bytes
x264 [debug]: frame=  10 QP=22.77 NAL=2 Slice:B Poc:22  I:6    P:762 
SKIP:8061 size=17575 bytes
x264 [error]: malloc of size 10031104 failed
x264 [error]: x264_encoder_encode failed
x264 [info]: frame I:1     Avg QP:12.42  size:1023133
x264 [info]: frame P:3     Avg QP:18.80  size: 72181
x264 [info]: frame B:7     Avg QP:22.69  size: 12144
x264 [info]: consecutive B-frames:  6.7%  0.0% 20.0%  0.0% 33.3% 40.0% 
0.0%  0.0%  0.0%  0.0%  0.0%  0.0%  0.0%  0.0%  0.0%  0.0%  0.0%
x264 [info]: mb I  I16..4:  1.0% 36.5% 62.5%
x264 [info]: mb P  I16..4:  0.0%  0.0%  0.1%  P16..4:  7.0%  1.0%  2.9% 
  2.3%  2.1%    skip:84.5%
x264 [info]: mb B  I16..4:  0.0%  0.0%  0.0%  B16..8:  8.2%  1.4%  1.5% 
  direct: 2.1%  skip:86.8%  L0:17.7% L1:47.5% BI:34.9%
x264 [info]: final ratefactor: 26.73
x264 [info]: 8x8 transform intra:36.3% inter:5.8%
x264 [info]: direct mvs  spatial:28.6% temporal:71.4%
x264 [info]: coded y,uvDC,uvAC intra: 99.9% 99.4% 98.7% inter: 6.2% 3.8% 
3.3%
x264 [info]: i16 v,h,dc,p: 26% 33% 23% 18%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 17% 13% 10%  6%  5%  5% 
14% 18%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 13%  8% 10% 10%  9% 10% 
12% 15%
x264 [info]: i8c dc,h,v,p: 61% 16% 10% 12%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 83.1%  6.0%  5.4%  4.2%  0.7%  0.6%
x264 [info]: ref B L0: 94.3%  0.9%  4.5%  0.2%  0.2%
x264 [info]: ref B L1: 91.7%  8.3%
x264 [info]: kb/s:14451.09

aborted at input frame 101, output frame 11
encoded 11 frames, 0.90 fps, 15905.30 kb/s

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

x264_2334.exe -I 150 -b 100 --b-adapt 2 -B 4000 -m 10 -t 2 --direct auto 
--me esa --merange 24 --partitions all --ref 16 --rc-lookahead 60 
--threads 8 --opencl -p 1 --qpmin 5 --log-level debug -o test.flv 
test_enc.avi

ffms [info]: 1920x1200p 0:1  <at>  15/1 fps (vfr)
x264 [debug]: using mv_range_thread = 72
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce 
GTX 670
x264 [info]: profile Main, level 5.0
x264 [debug]: frame=   0 QP=11.98 NAL=3 Slice:I Poc:0   I:9000 P:0 
SKIP:0    size=995889 bytes
flv [info]: initial delay 133 ms
x264 [debug]: frame=   1 QP=13.11 NAL=2 Slice:P Poc:10  I:19   P:2040 
SKIP:6941 size=116963 bytes
x264 [debug]: frame=   2 QP=21.84 NAL=2 Slice:B Poc:6   I:3    P:1082 
SKIP:7915 size=21275 bytes

x264 [debug]: frame= 253 QP=38.22 NAL=0 Slice:B Poc:202 I:0    P:19 
SKIP:8981 size=169 bytes
x264 [debug]: frame= 254 QP=37.94 NAL=0 Slice:B Poc:206 I:0    P:16 
SKIP:8984 size=136 bytes
x264 [info]: frame I:2     Avg QP:21.36  size:575161
x264 [info]: frame P:122   Avg QP:33.86  size: 39450
x264 [info]: frame B:131   Avg QP:36.15  size: 16157
x264 [info]: consecutive B-frames: 27.1% 11.8% 23.5% 18.8%  5.9%  9.4% 
0.0%  0.0%  3.5%  0.0%  0.0%  0.0%  0.0%  0.0%  0.0%  0.0%  0.0%
x264 [info]: mb I  I16..4: 21.8%  0.0% 78.2%
x264 [info]: mb P  I16..4: 24.8%  0.0%  0.0%  P16..4: 40.2%  0.0%  0.0% 
  0.0%  0.0%    skip:35.0%
x264 [info]: mb B  I16..4:  7.7%  0.0%  0.0%  B16..8: 21.6%  0.0%  0.0% 
  direct: 5.5%  skip:65.3%  L0:42.3% L1:49.4% BI: 8.3%
x264 [info]: final ratefactor: 30.27
x264 [info]: direct mvs  spatial:96.2% temporal:3.8%
x264 [info]: coded y,uvDC,uvAC intra: 46.0% 44.2% 17.7% inter: 10.3% 
9.2% 0.8%
x264 [info]: i16 v,h,dc,p: 24% 26% 35% 15%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 18% 12%  9%  8%  8%  8% 
10% 12%
x264 [info]: i8c dc,h,v,p: 67% 17% 12%  3%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: kb/s:3802.26

encoded 255 frames, 13.16 fps, 3802.61 kb/s

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

Bug fix(es):

Malloc fail.

Support --opencl with all encode options -p 1, -p 2, -p 3 and no -p (-p 
2 and -p 3 not using OpenCL could be a bug or improvement proposal don't 
know which one) and with all profiles (profile Main, level 5.0 | profile 
High, level 5.1 | etc).

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

Another improvement:

Add commandline option for storing ffms file index. I deal with large 
static files (not using AviSynth or some such) and when doing "Nth pass" 
a lot of time is wasted. It would be nice if file index could be saved 
in same manner as x264_lookahead.clbin x264_2pass.log 
x264_2pass.log.mbtree files so file indexing needs to be done only once.
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 1 comment |
headers
Peter Tap | 7 Jun 2013 22:54
Picon
Favicon

link Peter Tap

_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 0 comments |

Gmane