Crash when providing -coder ac parameter

Hi,

I've noticed that providing the -coder ac parameter causes
FFmpeg to 
segfault:
takisissaris:/usr/local/src/rw/ffmpeg$ ./ffmpeg -i 
/mnt/video/test-704x576.avi -vcodec ffv1 -coder ac
/tmp/test.avi
FFmpeg version SVN-r8548, Copyright (c) 2000-2007 Fabrice
Bellard, et al.
   configuration: --enable-gpl --enable-x11grab
   libavutil version: 49.4.0
   libavcodec version: 51.40.2
   libavformat version: 51.11.0
   built on Mar 29 2007 14:38:46, gcc: 4.1.2 (Ubuntu
4.1.2-0ubuntu4)
Input #0, avi, from '/mnt/video/test-704x576.avi':
   Duration: 00:00:04.0, start: 0.000000, bitrate: 68141
kb/s
   Stream #0.0: Video: ffvhuff, yuv420p, 704x576, 25.00
fps(r)
Segmentation fault (core dumped)

It appears that it is not a problem with the AC coder by
itself, but 
purely a parameter parsing problem.

I haven't really looked at the cause yet, but I wanted to
send the 
bugreport first, in case others would not want to miss the
joy of 
searching for it 

takisissaris:/usr/local/src/rw/ffmpeg$ gdb ./ffmpeg_g
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library
"/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) r -i /mnt/video/test-704x576.avi -vcodec ffv1 -coder
ac /tmp/test.avi
Starting program: /usr/local/src/rw/ffmpeg/ffmpeg_g -i 
/mnt/video/test-704x576.avi -vcodec ffv1 -coder ac
/tmp/test.avi
FFmpeg version SVN-r8548, Copyright (c) 2000-2007 Fabrice
Bellard, et al.
   configuration: --enable-gpl --enable-x11grab
   libavutil version: 49.4.0
   libavcodec version: 51.40.2
   libavformat version: 51.11.0
   built on Mar 29 2007 14:38:46, gcc: 4.1.2 (Ubuntu
4.1.2-0ubuntu4)
Input #0, avi, from '/mnt/video/test-704x576.avi':
   Duration: 00:00:04.0, start: 0.000000, bitrate: 68141
kb/s
   Stream #0.0: Video: ffvhuff, yuv420p, 704x576, 25.00
fps(r)

Program received signal SIGSEGV, Segmentation fault.
0xb7d14688 in strcmp () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0xb7d14688 in strcmp () from
/lib/tls/i686/cmov/libc.so.6
#1  0x0821e581 in av_set_string (obj=0x8583cb0,
name=0xbf81f6c4 "coder", 
val=0xbf81f6ca "ac") at opt.c:39
#2  0x0805922a in opt_default (opt=0xbf81f6c4
"coder", arg=0xbf81f6ca 
"ac") at ffmpeg.c:3503
#3  0x08063613 in parse_options (argc=8, argv=0xbf81d514, 
options=0x83dc080) at cmdutils.c:104
#4  0x08061384 in main (argc=8, argv=0xbf81d514) at
ffmpeg.c:3765

(gdb) disass $pc-32 $pc+32
Dump of assembler code from 0xb7d14668 to 0xb7d146a8:
0xb7d14668 <strchr+344>:        inc    %eax
0xb7d14669 <strchr+345>:        shr    $0x10,%ecx
0xb7d1466c <strchr+348>:        test   %cl,%cl
0xb7d1466e <strchr+350>:        je     0xb7d14675
<strchr+357>
0xb7d14670 <strchr+352>:        cmp    %dl,%cl
0xb7d14672 <strchr+354>:        je     0xb7d1464a
<strchr+314>
0xb7d14674 <strchr+356>:        inc    %eax
0xb7d14675 <strchr+357>:        pop    %edi
0xb7d14676 <strchr+358>:        ret
0xb7d14677 <_fini+454451>:      nop
0xb7d14678 <_fini+454452>:      nop
0xb7d14679 <_fini+454453>:      nop
0xb7d1467a <_fini+454454>:      nop
0xb7d1467b <_fini+454455>:      nop
0xb7d1467c <_fini+454456>:      nop
0xb7d1467d <_fini+454457>:      nop
0xb7d1467e <_fini+454458>:      nop
0xb7d1467f <_fini+454459>:      nop
0xb7d14680 <strcmp+0>:  mov    0x4(%esp),%ecx
0xb7d14684 <strcmp+4>:  mov    0x8(%esp),%edx
0xb7d14688 <strcmp+8>:  mov    (%ecx),%al
0xb7d1468a <strcmp+10>: cmp    (%edx),%al
0xb7d1468c <strcmp+12>: jne    0xb7d14697
<strcmp+23>
0xb7d1468e <strcmp+14>: inc    %ecx
0xb7d1468f <strcmp+15>: inc    %edx
0xb7d14690 <strcmp+16>: test   %al,%al
0xb7d14692 <strcmp+18>: jne    0xb7d14688
<strcmp+8>
0xb7d14694 <strcmp+20>: xor    %eax,%eax
0xb7d14696 <strcmp+22>: ret
0xb7d14697 <strcmp+23>: mov    $0x1,%eax
0xb7d1469c <strcmp+28>: mov    $0xffffffff,%ecx
0xb7d146a1 <strcmp+33>: cmovb  %ecx,%eax
0xb7d146a4 <strcmp+36>: ret
0xb7d146a5 <_fini+454497>:      nop
0xb7d146a6 <_fini+454498>:      nop
0xb7d146a7 <_fini+454499>:      nop
End of assembler dump.

 
                                (gdb) info all-registers
eax            0x0      0
ecx            0x0      0
edx            0x83f4516        138364182
ebx            0x83f4516        138364182
esp            0xbf81cbec       0xbf81cbec
ebp            0xbf81f6cc       0xbf81f6cc
esi            0x83f0970        138348912
edi            0xbf81cc7c       -1082012548
eip            0xb7d14688       0xb7d14688 <strcmp+8>
eflags         0x10246  [ PF ZF IF RF ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
st0            0        (raw 0x00000000000000000000)
st1            0        (raw 0x00000000000000000000)
st2            0        (raw 0x00000000000000000000)
st3            0        (raw 0x00000000000000000000)
st4            0        (raw 0x00000000000000000000)
st5            0        (raw 0x00000000000000000000)
st6            1        (raw 0x3fff8000000000000000)
st7            nan(0xc000000000000000)  (raw
0x7fffc000000000000000)
fctrl          0x37f    895
fstat          0x4020   16416
ftag           0xffff   65535
fiseg          0x73     115
fioff          0x821e52f        136439087
foseg          0x7b     123
fooff          0xbf81cc30       -1082012624
fop            0x675    1653
xmm0           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double =
{0x0, 0x0}, 
v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0,
0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0}, v4_int32 = {
     0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 
0x00000000000000000000000000000000}
xmm1           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double =
{0x0, 0x0}, 
v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0,
0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0}, v4_int32 = {
     0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 
0x00000000000000000000000000000000}
xmm2           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double =
{0x0, 0x0}, 
v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0,
0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0}, v4_int32 = {
     0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 
0x00000000000000000000000000000000}
xmm3           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double =
{0x0, 0x0}, 
v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0,
0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0}, v4_int32 = {
     0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 
0x00000000000000000000000000000000}
xmm4           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double =
{0x0, 0x0}, 
v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0,
0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0}, v4_int32 = {
     0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 
0x00000000000000000000000000000000}
xmm5           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double =
{0x0, 0x0}, 
v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0,
0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0}, v4_int32 = {
     0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 
0x00000000000000000000000000000000}
xmm6           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double =
{0x0, 0x0}, 
v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0,
0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0}, v4_int32 = {
     0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 
0x00000000000000000000000000000000}
xmm7           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double =
{0x0, 0x0}, 
v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0,
0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0}, v4_int32 = {
     0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 
0x00000000000000000000000000000000}
mxcsr          0x1f80   [ IM DM ZM OM UM PM ]
mm0            {uint64 = 0x0, v2_int32 = {0x0, 0x0},
v4_int16 = {0x0, 
0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}}
mm1            {uint64 = 0x0, v2_int32 = {0x0, 0x0},
v4_int16 = {0x0, 
0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}}
mm2            {uint64 = 0x0, v2_int32 = {0x0, 0x0},
v4_int16 = {0x0, 
0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}}
mm3            {uint64 = 0x0, v2_int32 = {0x0, 0x0},
v4_int16 = {0x0, 
0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}}
mm4            {uint64 = 0x0, v2_int32 = {0x0, 0x0},
v4_int16 = {0x0, 
0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}}
mm5            {uint64 = 0x0, v2_int32 = {0x0, 0x0},
v4_int16 = {0x0, 
0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}}
mm6            {uint64 = 0x8000000000000000, v2_int32 =
{0x0, 
0x80000000}, v4_int16 = {0x0, 0x0, 0x0, 0x8000}, v8_int8 =
{0x0, 0x0, 
0x0, 0x0, 0x0, 0x0, 0x0, 0x80}}
mm7            {uint64 = 0xc000000000000000, v2_int32 =
{0x0, 
0xc0000000}, v4_int16 = {0x0, 0x0, 0x0, 0xc000}, v8_int8 =
{0x0, 0x0, 
0x0, 0x0, 0x0, 0x0, 0x0, 0xc0}}

With friendly regards,
Takis
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,


> 
> I've noticed that providing the -coder ac parameter
causes FFmpeg to 
> segfault:
> takisissaris:/usr/local/src/rw/ffmpeg$ ./ffmpeg -i 
> /mnt/video/test-704x576.avi -vcodec ffv1 -coder ac
/tmp/test.avi
try -coder 1 for ac
- -coder <int> 

> It appears that it is not a problem with the AC coder
by itself, but 
> purely a parameter parsing problem.

Yes, it should be a bug anyway.

Thanks,
Limin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBRgvDckztbf7dKiuoAQJQhQf/XuWpaeNFnluZU6hXqIfyvSV0K5gt
HCE9
cJb8h9GbDrEk7ib2HKt8LzzVYujJrLuoSr1FrQ/20bJUvuSUxLzkrP2yOeT9
/nWW
dABqWCPfbJrrFwSHnGWDzUT3UVexDro1dm0VqQoWcJz9WcebblanOuYzcFvD
kCSc
+mBg4OEomlnKmiY1yGKzn3Ia+A20DmI5Et7tYU3g2FNK3HQf0bEaOCbezbNA
mLjb
fEbvAXbsH69/5qoOMHzTogPKtv8c/tNjNEweju76bnog2zwA8Ab54bqY84z6
3JMv
caD0EbJkTDyaLDDqGPd+POW4tuezy5NafngyovoVJDBj+dH/lshCGA==
=AFZH
-----END PGP SIGNATURE-----
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Hi,

> Hi,
> 
> I've noticed that providing the -coder ac parameter
causes FFmpeg to 
> segfault:
> takisissaris:/usr/local/src/rw/ffmpeg$ ./ffmpeg -i 
> /mnt/video/test-704x576.avi -vcodec ffv1 -coder ac
/tmp/test.avi
> FFmpeg version SVN-r8548, Copyright (c) 2000-2007
Fabrice Bellard, et al.
>   configuration: --enable-gpl --enable-x11grab
>   libavutil version: 49.4.0
>   libavcodec version: 51.40.2
>   libavformat version: 51.11.0
>   built on Mar 29 2007 14:38:46, gcc: 4.1.2 (Ubuntu
4.1.2-0ubuntu4)
> Input #0, avi, from '/mnt/video/test-704x576.avi':
>   Duration: 00:00:04.0, start: 0.000000, bitrate: 68141
kb/s
>   Stream #0.0: Video: ffvhuff, yuv420p, 704x576, 25.00
fps(r)
> Segmentation fault (core dumped)
> 
> It appears that it is not a problem with the AC coder
by itself, but 
> purely a parameter parsing problem.
> 
> I haven't really looked at the cause yet, but I wanted
to send the 
> bugreport first, in case others would not want to miss
the joy of 
> searching for it 
> 

Attached patch should fix the bug, please review it. After
the fix, it'll
report "unrecognized option '-coder'" which it's
caused by you input wrong
parameter. After the patch, the following "!unit
||" can be removed. Maybe
it should be another patch?

Thanks,
Limin

Index: libavcodec/opt.c
============================================================
=======
--- libavcodec/opt.c	(revision 8540)
+++ libavcodec/opt.c	(working copy)
 -35,6
+35,8 
     AVClass *c= *(AVClass**)v; //FIXME silly way of storing
AVClass
     const AVOption *o= c->option;
 
+    if( !name || !unit )
+        return NULL;
     for(;o && o->name; o++){
         if(!strcmp(o->name, name) && (!unit ||
!strcmp(o->unit, unit)) && (o->flags &
mask) == flags )
             return o;

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Hi,

Limin Wang wrote:
> Hi,
>   
>> Hi,
>>
>> I've noticed that providing the -coder ac parameter
causes FFmpeg to 
>> segfault:
>> takisissaris:/usr/local/src/rw/ffmpeg$ ./ffmpeg
-i 
>> /mnt/video/test-704x576.avi -vcodec ffv1 -coder ac
/tmp/test.avi
>> FFmpeg version SVN-r8548, Copyright (c) 2000-2007
Fabrice Bellard, et al.
>>   configuration: --enable-gpl --enable-x11grab
>>   libavutil version: 49.4.0
>>   libavcodec version: 51.40.2
>>   libavformat version: 51.11.0
>>   built on Mar 29 2007 14:38:46, gcc: 4.1.2 (Ubuntu
4.1.2-0ubuntu4)
>> Input #0, avi, from '/mnt/video/test-704x576.avi':
>>   Duration: 00:00:04.0, start: 0.000000, bitrate:
68141 kb/s
>>   Stream #0.0: Video: ffvhuff, yuv420p, 704x576,
25.00 fps(r)
>> Segmentation fault (core dumped)
>>
>> It appears that it is not a problem with the AC
coder by itself, but 
>> purely a parameter parsing problem.
>>
>> I haven't really looked at the cause yet, but I
wanted to send the 
>> bugreport first, in case others would not want to
miss the joy of 
>> searching for it 
>>
>>     
>
> Attached patch should fix the bug, please review it.
After the fix, it'll
> report "unrecognized option '-coder'" which
it's caused by you input wrong
> parameter. After the patch, the following "!unit
||" can be removed. Maybe
> it should be another patch?
>
> Thanks,
> Limin
>   
>
------------------------------------------------------------
------------
>
> Index: libavcodec/opt.c
>
============================================================
=======
> --- libavcodec/opt.c	(revision 8540)
> +++ libavcodec/opt.c	(working copy)
>  -35,6 +35,8 
>      AVClass *c= *(AVClass**)v; //FIXME silly way of
storing AVClass
>      const AVOption *o= c->option;
>  
> +    if( !name || !unit )
> +        return NULL;
>   
this will break almost every option such as flags, dct, ...
(i cant find a way to describe them)
btw, running the regression tests would surely fail on the
first line !

>      for(;o && o->name; o++){
>          if(!strcmp(o->name, name) && (!unit
|| !strcmp(o->unit, unit)) && (o->flags &
mask) == flags )
>              return o;
>   
Ben
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Hi,

Panagiotis Issaris wrote:
> Hi,
>
> I've noticed that providing the -coder ac parameter
causes FFmpeg to
> segfault:
it seems that the "duplication" of ac option
(audio channel and
arithmetic coding) causes it...
a way to fix it could be the patch attached.
I don't know if it's the proper way though...

Ben


_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Hi

On Thu, Mar 29, 2007 at 04:48:34PM +0200, Benoit Fouet
wrote:
> Hi,
> 
> Panagiotis Issaris wrote:
> > Hi,
> >
> > I've noticed that providing the -coder ac
parameter causes FFmpeg to
> > segfault:
> it seems that the "duplication" of ac option
(audio channel and
> arithmetic coding) causes it...
> a way to fix it could be the patch attached.
> I don't know if it's the proper way though...

no fix the parser so it doesnt crash, anyway i faintly
remember seeing
a patch for ac crash some time ago, wasnt it applied? didnt
it fix the
issue?

[...]
-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they
happen to say it
by chance, they would not even known they had done so. --
Xenophanes

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

On Thu, Mar 29, 2007 at 05:04:09PM +0200, Michael
Niedermayer wrote:
> no fix the parser so it doesnt crash, anyway i faintly
remember seeing
> a patch for ac crash some time ago, wasnt it applied?
didnt it fix the
> issue?

I had the same problem and wrote about it on the list
[http://lists.mplayerhq.hu/pipermail/ffmpe
g-devel/2007-March/025812.html].
However, my patch has not been applied.

-- 
Best regards,
Kamil Nowosad
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Hi,

Michael Niedermayer wrote:
> Hi
>
> On Thu, Mar 29, 2007 at 04:48:34PM +0200, Benoit Fouet
wrote:
>   
>> Hi,
>>
>> Panagiotis Issaris wrote:
>>     
>>> Hi,
>>>
>>> I've noticed that providing the -coder ac
parameter causes FFmpeg to
>>> segfault:
>>>       
>> it seems that the "duplication" of ac
option (audio channel and
>> arithmetic coding) causes it...
>> a way to fix it could be the patch attached.
>> I don't know if it's the proper way though...
>>     
>
> no fix the parser so it doesnt crash, anyway i faintly
remember seeing
> a patch for ac crash some time ago, wasnt it applied?
didnt it fix the
> issue?
>
>   
Kamil's patch fixes the issue
regression tests also passed here on my AMD64

Ben

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Hi

Michael Niedermayer wrote:
> On Thu, Mar 29, 2007 at 04:48:34PM +0200, Benoit Fouet
wrote:
>> Panagiotis Issaris wrote:
>>> I've noticed that providing the -coder ac
parameter causes FFmpeg to
>>> segfault:
>> it seems that the "duplication" of ac
option (audio channel and
>> arithmetic coding) causes it...
>> a way to fix it could be the patch attached.
>> I don't know if it's the proper way though...
> 
> no fix the parser so it doesnt crash, anyway i faintly
remember seeing
> a patch for ac crash some time ago, wasnt it applied?
didnt it fix the
> issue?
Applied and yes, it fixes the issue.

With friendly regards,
Takis
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

* Kamil Nowosad <k.nowosadstudents.mimuw.edu.pl>
[2007-03-29 18:32:45 +0200]:

> On Thu, Mar 29, 2007 at 05:04:09PM +0200, Michael
Niedermayer wrote:
> > no fix the parser so it doesnt crash, anyway i
faintly remember seeing
> > a patch for ac crash some time ago, wasnt it
applied? didnt it fix the
> > issue?
> 
> I had the same problem and wrote about it on the list
> [http://lists.mplayerhq.hu/pipermail/ffmpe
g-devel/2007-March/025812.html].
> However, my patch has not been applied.

The problem is everything is fine in the eye of the user,
but in fact, it'll
hide the fact that -coder ac haven't let ffmpeg user ac
coder as user's
expecting.


Thanks,
Limin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBRgz98Uztbf7dKiuoAQIOqgf/dWXZJPic+eDMzooeEE+UdEMSJ2fq
f+lH
f9pceiQCl/Gdsw4nQHcvNfiI3cmj9ocX7c/8NjVzVf2VBsArg0J3VUChpgS9
WvuI
i7ApRM4otF4hCTMfgE8jEV72Br5LfpQJeEIvZKaDDTR2wryYs0bHrCysy7r8
dxNS
p80w17nsT2M56FOrfkKNDYEG3zBWKhcKdphiWU0+IJVp9jGYTWhn1Y5M4Euc
ROBC
l7pmYBOrI9U6H3ms52AEkU+DOpwzumGGXHNgMU9B7IgAq6BNnxG+de+Qi0Tx
iX0s
wxDBa9cyTDF4PldlhwZit0RHzAlfysMmlW7sfpv3Q3+asna1nA+cyQ==
=gdmL
-----END PGP SIGNATURE-----
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Hi

On Fri, Mar 30, 2007 at 08:09:21PM +0800, Limin Wang wrote:
> Hi,
> 
> * Kamil Nowosad <k.nowosadstudents.mimuw.edu.pl>
[2007-03-29 18:32:45 +0200]:
> 
> > On Thu, Mar 29, 2007 at 05:04:09PM +0200, Michael
Niedermayer wrote:
> > > no fix the parser so it doesnt crash, anyway
i faintly remember seeing
> > > a patch for ac crash some time ago, wasnt it
applied? didnt it fix the
> > > issue?
> > 
> > I had the same problem and wrote about it on the
list
> > [http://lists.mplayerhq.hu/pipermail/ffmpe
g-devel/2007-March/025812.html].
> > However, my patch has not been applied.
> 
> The problem is everything is fine in the eye of the
user, but in fact, it'll
> hide the fact that -coder ac haven't let ffmpeg user ac
coder as user's
> expecting.

really? why?

i thought the new code should fail to select the audio
channels ac when
searching for the coder type and select the arithmetic coder
ac ...
havnt checked though ....

[...]
-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be
what we pretend
to be. -- Socrates

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Hi

Limin Wang wrote:
> * Kamil Nowosad <k.nowosadstudents.mimuw.edu.pl>
[2007-03-29 18:32:45 +0200]:
> 
>> On Thu, Mar 29, 2007 at 05:04:09PM +0200, Michael
Niedermayer wrote:
>>> no fix the parser so it doesnt crash, anyway i
faintly remember seeing
>>> a patch for ac crash some time ago, wasnt it
applied? didnt it fix the
>>> issue?
>> I had the same problem and wrote about it on the
list
>> [http://lists.mplayerhq.hu/pipermail/ffmpe
g-devel/2007-March/025812.html].
>> However, my patch has not been applied.
> 
> The problem is everything is fine in the eye of the
user, but in fact, it'll
> hide the fact that -coder ac haven't let ffmpeg user ac
coder as user's
> expecting.
Weird. Are you sure? I tried encoding using both
"-coder ac" and "-coder 
vlc" and it resulted in a different file size and
different performance 
(and as expected AC resulted in a smaller file size and
encoding was 
noticeably slower).

The difference in filesizes when using the lossless ffv1
codec:
Coder    Filesize
VLC      19923786
AC       19290550

With friendly regards,
Takis
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

> >The problem is everything is fine in the eye of the
user, but in fact, 
> >it'll
> >hide the fact that -coder ac haven't let ffmpeg
user ac coder as user's
> >expecting.
> Weird. Are you sure? I tried encoding using both
"-coder ac" and "-coder 
> vlc" and it resulted in a different file size and
different performance 
> (and as expected AC resulted in a smaller file size and
encoding was 
> noticeably slower).

> The difference in filesizes when using the lossless
ffv1 codec:
> Coder    Filesize
> VLC      19923786
> AC       19290550

At least, -coder expect <int> parameter, so you'll get
unknown result. I'm
testing h264 encode only.

./ffmpeg -i /usr/local/movies/sample_h264_1mbit.mp4 -pass 1
-coder ac -vcodec
mpeg2video /tmp/1.h264

#head -n 1 x264_2pass.log
#options: 352x288 fps=25/1 cabac=0 ref=1 deblock=0:0:0
analyse=0x1:0x130
me=dia subme=7 brdo=0 mixed_ref=0 me_range=4 chroma_me=0
trellis=0 8x8dct=0
cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=1 nr=0
decimate=1 mbaff=0
bframes=0 keyint=12 keyint_min=7 scenecut=0 rc=abr
bitrate=200 ratetol=20.0
rceq='tex^qComp' qcomp=0.50 qpmin=2 qpmax=31 qpstep=3
ip_ratio=1.25


Thanks,
Limin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBRg2rPEztbf7dKiuoAQLMyQf/Sxyklp7aBEN/uOOcvbygUuMCDpEa
S6ot
z3g3ZMF9//Egtly28iqFZkWV2NOCZhsNW0ErmP1vhfQ13eiiLMMwk/2eKzdF
zsGD
RztPGIyJvJRHAFmkoDzCHb5NWkdAXqxuCwXjoVCvRAG3wQQUYhC2zss5i/fm
SzSy
k5aDxDhKObBrSr+r9DCrGXOYJxbp61QlU8FAnlJy9NZoYcntgjZhkgcoBflO
ITns
t4pBSGkUh2QanEa4VEYY96LSToqUmvecNK0S/RQ9bwOTBm3vBpcENjcELk5P
A8de
DuhGpDgXrKRnBQxsbXjBpnPpkvS7GqqHTxfq4BhdcMKKrOz4Se+K4A==
=NYfD
-----END PGP SIGNATURE-----
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel