[FFmpeg-devel] lavfi state of affairs

Vitor Sessak vitor1001
Sun Feb 8 19:10:22 CET 2009


Michael Niedermayer wrote:
> On Sun, Feb 08, 2009 at 01:39:02PM +0100, Vitor Sessak wrote:
>> Michael Niedermayer wrote:
>>> On Sat, Feb 07, 2009 at 07:19:17PM +0100, Vitor Sessak wrote:
>>>> Michael Niedermayer wrote:
>>>>> On Sat, Feb 07, 2009 at 09:13:11AM +0100, Vitor Sessak wrote:
>>>>>> Stefano Sabatini wrote:
>>>>>>> On date Friday 2009-02-06 01:24:34 +0100, Michael Niedermayer encoded:
>>>>>>>> On Thu, Feb 05, 2009 at 11:57:42PM +0100, Stefano Sabatini wrote:
>>>>>>>>> On date Thursday 2009-02-05 14:28:05 -0800, Baptiste Coudurier 
>>>>>>>>> encoded:
>>>>>>>>>> On 2/5/2009 2:02 PM, Michael Niedermayer wrote:
>>>>>>>>>>> On Thu, Feb 05, 2009 at 12:36:55PM -0800, Baptiste Coudurier 
>>>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Another big problem which I already mentioned in this thread is that
>>>>>>>>> slicification doesn't work when converting the format, for example:
>>>>>>>>> ffplay -f video4linux /dev/video -s 640x480 -vfilters  "slicify=16, 
>>>>>>>>> format=rgb32"
>>>>>>>> try with and without scaling do both fail? does rgb32 outputfail for 
>>>>>>>> all
>>>>>>>> input pixfmts?
>>>>>>> Yes I tried with all the input formats and output formats, the only
>>>>>>> one which seems to work is yuv420p.
>>>>>>  >
>>>>>>> Also things like this seems not to work
>>>>>>> ffplay -f video4linux /dev/video -vfilters  "format=rgb32, slicify=32, 
>>>>>>> format=rgb32"
>>>>>>> ffplay -f video4linux /dev/video -vfilters  "format=rgb32, slicify=32, 
>>>>>>> scale=160:120, format=rgb32"
>>>>>>> ffplay -f video4linux /dev/video -vfilters  "format=rgb32, 
>>>>>>> scale=160:120, slicify=32, format=rgb32"
>>>>>> The problem is not with slicify filter but with the scale filter. You 
>>>>>> forget the when you write
>>>>>>
>>>>>> ffplay -f video4linux /dev/video -vfilters  "format=rgb32, slicify=32, 
>>>>>> format=rgb32"
>>>>>>
>>>>>> your actual filter is either
>>>>>>
>>>>>> input -> format -> slificy -> format -> output
>>>>>>
>>>>>> or
>>>>>>
>>>>>> input -> format -> slificy -> format -> format -> output
>>>>>>
>>>>>> where the second format was added to feed the output the right pixfmt. 
>>>>>> Also, if you try any of the following:
>>>>>>
>>>>>> -vfilters "format=gray,slicify=32, format=gray, fifo"
>>>>>> -vfilters "format=rgb24,slicify=32, format=rgb24, fifo"
>>>>>> -vfilters "format=rgb32,slicify=32, format=rgb32, fifo"
>>>>>>
>>>>>> (where fifo pratically does the inverse of slicifying), it works. So it 
>>>>>> means that the slicify works fine for several formats. The problem 
>>>>>> shows up if you do
>>>>>>
>>>>>>   -vfilters "format=PIXFMT1,slicify=32, format=PIXFMT2, fifo"
>>>>>>
>>>>>> where PIXFMT1 and PIXFMT2 are two different pixfmts. For me this shows 
>>>>>> that the problem is that the scale filter do not work with slices. See 
>>>>>> also 
>>>>>> http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/2008-February/002597.html 
>>>>>> .
>>>>> could you please use unambigous command lines that do not depend on
>>>>> automatcally inserted scale filters!

>> Ok, I've got a patch that works fine for almost all formats. The only 
>> problems I had was when converting to/from YUV410, GRAY8 or PAL8 and I 
>> really don't understand why. To test, since I know that vf_scale works fine 
>> for non-sliced data, I use
>>
>> ffmpeg -i in.avi -vfilters "format=rgb32, scale=256:256,format=rgb32, 
>> fifo,slicify=128, format=yuv410p, fifo" out.avi
>>
>> Where the idea is to test the sliced conversion of RGB32 -> YUV410p using a 
>> 256x256 frame.
> 
> so it works if you remove slicify ?

Yes.

> anyway, its well possible this could be a bug in the scaler but i fear i
> have no time to look into this any time soon, especially as you do not
> provide the information i asked for.

ok.

> could you please use unambigous command lines that do not depend on
> automatcally inserted scale filters!

ffmpeg -i in.avi -vfilters "format=rgb32, scale=256:256,format=rgb32, 
fifo,slicify=32, format=yuv410p, fifo" out.avi

should be independent of pretty much anything. Also changing 
s/slicify=32/slicify=256/ solves the problem (slicifying in one slice is 
a nop).

> also i need to know the following for every scale filter that occurs
> input size

256x256

> output size

same

> slice sizes

32

> input pixfmt

rgb32

> output pixfmt

yuv410p

> is the image is correct at input

Should be, dumping the memory and opening it as raw rgb should not be 
worth the time it takes.

> is the image is correct at output
 > how is the image wrong if its not correct

no, visual artifacts see bad.jpg/good.jpg

> if it works without slices

I couldn't spot any case that doesn't work without slices.

> if it works with input&output size equal

no

> if it works with input&output size different

no

> if it works with differnt scaler BILINEAR/BICUBIC

no

> all messages returned by sws and enable SWS_PRINT_INFO

uncut output:

  ./ffmpeg -i ~/ffmpeg/tests/angels2.roq -vfilters "format=rgb32, 
scale=256:256,format=rgb32, fifo,slicify=32, format=yuv410p, fifo"  -y 
/tmp/a.avi; mplayer -vo x11 /tmp/a.avi
FFmpeg version SVN-r16713, Copyright (c) 2000-2009 Fabrice Bellard, et al.
   configuration: --enable-gpl --enable-avfilter --enable-swscale
   libavutil     49.14. 0 / 49.14. 0
   libavcodec    52.11. 0 / 52.11. 0
   libavformat   52.25. 0 / 52.25. 0
   libavdevice   52. 1. 0 / 52. 1. 0
   libavfilter    0. 3. 0 /  0. 3. 0
   libswscale     0. 6. 1 /  0. 6. 1
   built on Feb  7 2009 13:44:37, gcc: 4.2.4 (Ubuntu 4.2.4-1ubuntu3)

Seems stream 0 codec frame rate differs from container frame rate: 
90000.00 (90000/1) -> 30.00 (30/1)
Input #0, RoQ, from '/home/camilla/ffmpeg/tests/angels2.roq':
   Duration: N/A, start: 0.000000, bitrate: N/A
     Stream #0.0: Video: roqvideo, yuv444p, 480x256, 30.00 tb(r)
-> format=rgb32, scale=256:256,format=rgb32, fifo,slicify=32, 
format=yuv410p, fifo
[format @ 0x88b9170]auto-inserting filter 'scale'
[format @ 0x88be990]auto-inserting filter 'scale'
[fifo @ 0x88ef990]auto-inserting filter 'scale'
SwScaler: reducing / aligning filtersize 1 -> 1
SwScaler: reducing / aligning filtersize 5 -> 4
SwScaler: reducing / aligning filtersize 1 -> 1
SwScaler: reducing / aligning filtersize 1 -> 1
[swscaler @ 0x88f11b0]BILINEAR scaler, from yuv444p to rgb32 using C
[swscaler @ 0x88f11b0]using X86-Asm scaler for horizontal scaling
[swscaler @ 0x88f11b0]using n-tap C scaler for vertical scaling (BGR)
[swscaler @ 0x88f11b0]using C YV12->BGR32 Converter
[swscaler @ 0x88f11b0]480x256 -> 480x256
SwScaler: reducing / aligning filtersize 5 -> 4
SwScaler: reducing / aligning filtersize 5 -> 4
SwScaler: reducing / aligning filtersize 1 -> 1
SwScaler: reducing / aligning filtersize 1 -> 1
[swscaler @ 0x88fc420]BILINEAR scaler, from rgb32 to rgb32 using C
[swscaler @ 0x88fc420]using X86-Asm scaler for horizontal scaling
[swscaler @ 0x88fc420]using n-tap C scaler for vertical scaling (BGR)
[swscaler @ 0x88fc420]using C YV12->BGR32 Converter
[swscaler @ 0x88fc420]480x256 -> 256x256
SwScaler: reducing / aligning filtersize 1 -> 1
SwScaler: reducing / aligning filtersize 5 -> 4
SwScaler: reducing / aligning filtersize 1 -> 1
SwScaler: reducing / aligning filtersize 9 -> 8
[swscaler @ 0x8908500]BILINEAR scaler, from rgb32 to yuv410p using C
[swscaler @ 0x8908500]using X86-Asm scaler for horizontal scaling
[swscaler @ 0x8908500]using 1-tap C "scaler" for vertical scaling (YV12 
like)
[swscaler @ 0x8908500]256x256 -> 256x256
[swscaler @ 0x8924180]using unscaled yuv410p -> yuv420p special converter
Output #0, avi, to '/tmp/a.avi':
     Stream #0.0: Video: mpeg4, yuv420p, 256x256, q=2-31, 200 kb/s, 
30.00 tb(c)
Stream mapping:
   Stream #0.0 -> #0.0
Press [q] to stop encoding
frame=  269 fps= 78 q=25.9 Lsize=     374kB time=8.97 bitrate= 341.4kbits/s


  >> Index: vf_scale.c
>> ===================================================================
>> --- vf_scale.c	(revision 4019)
>> +++ vf_scale.c	(working copy)
>> @@ -133,10 +133,26 @@
>>  {
>>      ScaleContext *scale = link->dst->priv;
>>      int outH;
>> +    int vsub, hsub;
>> +    uint8_t *data[4];
>>  
>> -    outH = sws_scale(scale->sws, link->cur_pic->data, link->cur_pic->linesize,
>> +    avcodec_get_chroma_sub_sample(link->format, &hsub, &vsub);
>> +
>> +    data[0] = link->cur_pic->data[0] + y * link->cur_pic->linesize[0];
>> +    data[3] = link->cur_pic->data[3] + y * link->cur_pic->linesize[3];
>> +
> 
>> +    if (link->format != PIX_FMT_PAL8) {
>> +        data[1] = link->cur_pic->data[1] + (y >> vsub) * link->cur_pic->linesize[1];
>> +        data[2] = link->cur_pic->data[2] + (y >> vsub) * link->cur_pic->linesize[2];
>> +    } else {
>> +        data[1] = link->cur_pic->data[1];
>> +        data[2] = link->cur_pic->data[2];
>> +    }
> 
> PAL8 is not the only format that has a palette
> a simple link->cur_pic->data[2] == NULL check might work better
> 
> except that the patch looks good

Thanks for the review. I'll fix that and commit.

-Vitor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bad.jpg
Type: image/jpeg
Size: 13693 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090208/a93c0a89/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: good.jpg
Type: image/jpeg
Size: 14410 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090208/a93c0a89/attachment-0001.jpg>



More information about the ffmpeg-devel mailing list