[FFmpeg-devel] [PATCH] Google WebP support

[Pascal Massimino]

Michael, all,

On Tue, Oct 12, 2010 at 6:41 PM, Pascal Massimino <
pascal.massimino at gmail.com> wrote:

> Michael,
>
> On Tue, Oct 12, 2010 at 6:13 PM, Pascal Massimino <
> pascal.massimino at gmail.com> wrote:
>
>> Michael,
>>
>> On Tue, Oct 12, 2010 at 2:45 PM, Michael Niedermayer <michaelni at gmx.at>wrote:
>>
>>> On Tue, Oct 12, 2010 at 11:39:26PM +0200, Michael Niedermayer wrote:
>>> > On Mon, Oct 11, 2010 at 11:27:08PM -0700, Pascal Massimino wrote:
>>> H> > Michael,
>>> > >
>>> > > On Mon, Oct 11, 2010 at 4:59 AM, Michael Niedermayer <
>>> michaelni at gmx.at>wrote:
>>> > >
>>> [...]
>>> > > > there may be other ways to do it but this one seems simplest, other
>>> > > > suggestions
>>> > > > are welcome but numbered image support, per image metadata and
>>> alpha
>>> > > > obviously
>>> > > > should be possible in the design.
>>> > > >
>>> > >
>>> > > really, i don't see what img2.c is bringing as value. Since i still
>>> will
>>> > > have to do the code
>>> > > for RIFF / metadata handling (somewhere else. Possibly multiple
>>> times.). And
>>> > > the
>>> >
>>> > > use-case assumed isn't there. I don't want ./ffmpeg -i *.webp -y
>>> toto.avi to
>>> > > work
>>> >
>>> > thats ok, but i want numbered images to work. And if your
>>> implementation cannot
>>> > handle that or more correctly noone knows how to even add it on top of
>>> that
>>> > implementation while a img2 based one could handle it, then there is a
>>> problem
>>> > in your implementation.
>>>
>>> And note here iam not opposed to your implementation if you can explain
>>> how
>>> the img2 feature set could be implemented on top of it. But i feel uneasy
>>> without knowing if we are moving toward a dead end here
>>>
>>> $attached would work, except for the discussed caveat:
>>  * metadata are not handled (would just require some extra if's i guess)
>>  * it hardcodes WEBP==VP8 which may not hold for long
>>  * hardcoding the RIFF header writing is bweuuurk
>>  * i can't force gop_size to 1 at line 245. I guess it's because
>> av_codec_open()
>>    occurs later
>>
>
> scratch that. Code was at the wrong location.
> Attached, a what-should-be-correct version. But gop_size=1 still doesn't
> work.
> Added support for encoding too:
>   ./ffmpeg -i splouch%03d.webp -y OMG_so_much_splouch.avi
> but that's a lot of extra if's. And ugly.
> Could it be that image2 should map to muxers in addition to codec?
>
> skal
>
>
>
>> Still, with that patch, it seems:
>>      ./ffmpeg -i holiday_at_molokai_beach_OMG_so_much_fun.avi -g 1 -f
>> image2 -y splouch%03d.webp
>> works.
>>
>> skal
>>
>>
ping? (for webp{dec,enc,[]}.c, not img2.c)
rejected?

skal


>
>>>
>>> [...]
>>> --
>>>
>>> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>>
>>> Its not that you shouldnt use gotos but rather that you should write
>>> readable code and code with gotos often but not always is less readable
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.10 (GNU/Linux)
>>>
>>> iEYEARECAAYFAky01xEACgkQYR7HhwQLD6srPwCfY+l+p4rBRDegMHV8GgEBpPwR
>>> i3wAnRsRhhSDpCWJZo2lnejDeu/NvZCC
>>> =scCg
>>>
>>> -----END PGP SIGNATURE-----
>>>
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at mplayerhq.hu
>>> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>>>
>>
>>
>