[FFmpeg-devel] [PATCH] Google WebP support

[Peter Ross]

On Sun, Oct 17, 2010 at 07:03:59AM -0700, Pascal Massimino wrote:
> 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?

+static int probe(AVProbeData *p)
+{
+    if (!memcmp(p->buf, "RIFF", 4) && !memcmp(p->buf + 8, "WEBP", 4))
+        return AVPROBE_SCORE_MAX;
+
+    return 0;
+}
+
+static int read_header(AVFormatContext *s, AVFormatParameters *ap)
+{
+    AVStream *st;
+    uint32_t riff_size;
+
+    if (get_le32(s->pb) != AV_RL32("RIFF"))
+        return AVERROR(EINVAL);
+    riff_size = get_le32(s->pb);
+    if (get_le32(s->pb) != AV_RL32("WEBP"))
+        return AVERROR(EINVAL);

There is no need to check the RIFF/WEBP magic numbers twice.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101018/32653451/attachment.pgp>