[Ffmpeg-devel] [PATCH] enable libswscale

Víctor Paesa wzrlpy
Sun Aug 27 23:23:22 CEST 2006


Hi

>>> I don't understand well if sws_scale returns any specific value to
>>> signal
>>> errors, does it?
>> I think swscale does not return errors - and sws_scale() never fails (in
>> fact, I see that the return value of sws_scale() is never checked in
>> mplayer's code), but in the "swscale emulation" code I return a negative
>> value in case of error.
>
>OK, then I will remove the checks for what sws_scale returns.
>
Here is my revision, with the check for sws_scale return values removed.

> On Fri, Aug 25, 2006 at 01:04:46AM +0200, V?ctor Paesa wrote:
>> Hi Luca,
>>
>> Luca wrote:
>> >
>> > On Wed, 2006-08-23 at 19:28 +0200, V?ctor Paesa wrote:
>> > [...]
>> >> Here is my attempt to convert vhook/null.c
>> > I had a quick look at it, and it seems to be ok (modulo the checks on
>> > sws_scale() return value).
>> > Only one question: is it really possible that the image format or
>> > dimensions dynamically change? (I see you added support for this
>> > possibility).
>> >
>>
>> I really added that support because pix_fmt, width, height exist as
>> parameters to Process(), if they wouldn't potentially change every
>> frame,
>> then passing them as parameters to Configure() should be enough.
>>
>> Changing pix_fmt seems overkill, but regarding dimensions, hmm,
>> I can read your question in two ways:
>>
>> a) It might be possible to find videos were dimensions change, I can
>> think
>> of captured DTV broadcasts, they may change size from comercials to
>> movies.
>>
>> b) Currently ffmpeg is not supporting dimensions changes, at least in
>> this
>> quick test:
>>
>> ffmpeg -f image2 -i logo%d.png -y logo%d.jpg
>>
>> The test source PNGs have different sizes, but the resulting JPEGs are
>> the
>> same size.
>>
>> But I not sure if ffmpeg was designed to support it. That looks a design
>> question.
>> Michael, could you please shed some light?
>
> some parts support changing sizes some dont, patch is welcome but changing
> size at the encoder side is only usefull for image(2) for normal encoding
> ffmpeg should rescale to a single size, at least by default

OK, I will keep on supporting changing sizes in my future patches.
I'm more familiar with the vhook code, so I'll attemp them first.

Regards,
V?ctor Paesa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg.swscale.null-vhook.2.patch
Type: application/octet-stream
Size: 4033 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20060827/75bb4f39/attachment.obj>



More information about the ffmpeg-devel mailing list