bug in libavfilter for standard crop/pad syntax

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

bug in libavfilter for standard crop/pad syntax

vdmsss
Hello.

        Hopefully some libavfilter developers will be listening: when ffmpeg  
is compiled with --enable-libavfilter the old syntax of -cropleft ... -
padleft ... is broken. I have been trying to understand why. Line 233  
from libavfilter/diffs/04_ffmpeg_filters.diff is clearly wrong:

> +        snprintf(crop_args, 255, "%d:%d:%d:%d", ost->topBand, ost-
> >topBand, codec->height - frame_topBand, codec->width-  
> frame_bottomBand);

The first topBand there must be leftBand, but I think there might be  
more: I am not sure I understand entirely the intentions behind the  
formula, but shouldn't

        codec->height - frame_topBand

be

        codec->height - (frame_padtop + frame_padbottom)

and symmetrically for codec->width? Is that right?


--
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: bug in libavfilter for standard crop/pad syntax

Vitor Sessak
Hi

vdmsss wrote:
> Hello.
>
> Hopefully some libavfilter developers will be listening: when ffmpeg

You could be more sure of been listened by a libavfilter developer by
making a patch and sending it to ffmpeg-soc mailing list.

> is compiled with --enable-libavfilter the old syntax of -cropleft ... -
> padleft ... is broken. I have been trying to understand why. Line 233  

Fixed, thanks for testing.

-Vitor

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: bug in libavfilter for standard crop/pad syntax

vdmsss
Hi Vitor,

On 8 Jan 2008, at 06:22, Vitor wrote:
> Hi
>
> vdmsss wrote:
>> Hello.
>>
>> Hopefully some libavfilter developers will be listening: when ffmpeg
>
> You could be more sure of been listened by a libavfilter developer by
> making a patch and sending it to ffmpeg-soc mailing list.

I I could not make a patch because I wasn't sure of my fix. In  
particular, the code I suggested did not fix -padright: running with "-
padleft x -padtop y -padbottom z -padrigtht t" yields a frame of the  
right geometry but with only three black bands, -padright t is ignored.

Also, using -pad... with png output fails and produces a lot of  
errors, due to the condition on pix_fmt in av_picture_pad(...), and I  
don't know if that is a bug or something intrinsic.

>> is compiled with --enable-libavfilter the old syntax of -
>> cropleft ... -
>> padleft ... is broken. I have been trying to understand why. Line 233
>
> Fixed, thanks for testing.

Good. Does -padright work? (can't test before tonite)


_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: bug in libavfilter for standard crop/pad syntax

Vitor Sessak
Hi

vdmsss wrote:

> Hi Vitor,
>
> On 8 Jan 2008, at 06:22, Vitor wrote:
>> vdmsss wrote:
>>> Hopefully some libavfilter developers will be listening: when ffmpeg
>> You could be more sure of been listened by a libavfilter developer by
>> making a patch and sending it to ffmpeg-soc mailing list.
>
> I I could not make a patch because I wasn't sure of my fix. In  
> particular, the code I suggested did not fix -padright: running with "-
> padleft x -padtop y -padbottom z -padrigtht t" yields a frame of the  
> right geometry but with only three black bands, -padright t is ignored.
>
> Also, using -pad... with png output fails and produces a lot of  
> errors, due to the condition on pix_fmt in av_picture_pad(...), and I  
> don't know if that is a bug or something intrinsic.
>
>>> is compiled with --enable-libavfilter the old syntax of -
>>> cropleft ... -
>>> padleft ... is broken. I have been trying to understand why. Line 233
>> Fixed, thanks for testing.
>
> Good. Does -padright work? (can't test before tonite)

I'll have a look at it soon (out of time these days)...

-Vitor

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: bug in libavfilter for standard crop/pad syntax

Vitor Sessak
In reply to this post by vdmsss
Hi

vdmsss wrote:

> Hi Vitor,
>
> On 8 Jan 2008, at 06:22, Vitor wrote:
>> vdmsss wrote:
>>> Hello.
>>>
>>> Hopefully some libavfilter developers will be listening: when ffmpeg
>> You could be more sure of been listened by a libavfilter developer by
>> making a patch and sending it to ffmpeg-soc mailing list.
>
> I I could not make a patch because I wasn't sure of my fix. In  
> particular, the code I suggested did not fix -padright: running with "-
> padleft x -padtop y -padbottom z -padrigtht t" yields a frame of the  
> right geometry but with only three black bands, -padright t is ignored.
>
> Also, using -pad... with png output fails and produces a lot of  
> errors, due to the condition on pix_fmt in av_picture_pad(...), and I  
> don't know if that is a bug or something intrinsic.
>
>>> is compiled with --enable-libavfilter the old syntax of -
>>> cropleft ... -
>>> padleft ... is broken. I have been trying to understand why. Line 233
>> Fixed, thanks for testing.
>
> Good. Does -padright work? (can't test before tonite)

No. -padright and -padbottom won't work for now. The problem is that
ffmpeg.c implements these two types of padding by just allocating and
zeroing a bigger frame. Since libavfilter will return a frame of the
non-padded size, it will just crash. The solution will be to implement a
crop filter...

-Vitor

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: bug in libavfilter for standard crop/pad syntax

vdmsss
On 10 Jan 2008, at 18:53, Vitor wrote:
> No. -padright and -padbottom won't work for now. The problem is that
> ffmpeg.c implements these two types of padding by just allocating and
> zeroing a bigger frame.

Yes, I have noticed that, and I understand what you mean. There is  
still something bizarre, that padbottom and padright fail in different  
ways: for padbottom the black band appears, but it crops away (covers)  
part of the frame that was supposed to stay, while for padright the  
black band simply doesn't show up. This makes me suspect that there  
might still be some bug relating to the geometry parameters. I will  
try to give a look over the weekend. (Incidentally, also padleft and  
padtop don't exactly work, because  they don't resize the frame, so  
that the bottom and the right edges are pushed out of it; but this is  
explained by your point above. The programme doesn't crash though.)

> Since libavfilter will return a frame of the
> non-padded size, it will just crash. The solution will be to  
> implement a
> crop filter...

Wait a minute, do you mean a padding/expand filter? You already have a  
crop filter, and it seems to work well... Perhaps it's not so  
difficult to adapt mplayer's vf_expand and vf_dsize...

--
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: bug in libavfilter for standard crop/pad syntax

Vitor Sessak
Hi

vdmsss wrote:
> On 10 Jan 2008, at 18:53, Vitor wrote:
>> No. -padright and -padbottom won't work for now. The problem is that
>> ffmpeg.c implements these two types of padding by just allocating and
>> zeroing a bigger frame.
>

[...]

>
> Yes, I have noticed that, and I understand what you mean. There is  
> still something bizarre, that padbottom and padright fail in different  
> ways: for padbottom the black band appears, but it crops away (covers)  
> part of the frame that was supposed to stay, while for padright the  
> black band simply doesn't show up. This makes me suspect that there  
> might still be some bug relating to the geometry parameters. I will  
> try to give a look over the weekend. (Incidentally, also padleft and  

Thanks, but if you do, don't forget to compare with a version compiled
without libavfilter support, maybe the bug is unrelated to my patch...

>> Since libavfilter will return a frame of the
>> non-padded size, it will just crash. The solution will be to  
>> implement a
>> crop filter...
>
> Wait a minute, do you mean a padding/expand filter? You already have a  

Sure, I meant padding filter... Not enough coffee :-)

> crop filter, and it seems to work well... Perhaps it's not so  
> difficult to adapt mplayer's vf_expand and vf_dsize...

I'm not sure it's worth the trouble. It should be fairly simple to write
one from scratch...

-Vitor

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user