[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