Dne so 12. 9. 2020 22:35 uživatel Carl Eugen Hoyos <ceffm...@gmail.com>
napsal:
> Am Fr., 11. Sept. 2020 um 08:36 Uhr schrieb Josef Zlomek <jo...@pex.com>:
>
> This is not the requested review, I am just curious about the
> behaviour:
>
> > +static int webp_probe(const AVProbeData *p)
> > +{
> > + const uint8_t *b = p->buf;
> > +
> > + if (AV_RB32(b) == MKBETAG('R', 'I', 'F', 'F') &&
> > + AV_RB32(b + 8) == MKBETAG('W', 'E', 'B', 'P'))
> > + return AVPROBE_SCORE_MAX;
>
> What happens if you pipe several (not animated) webp images
> through your new demuxer?
> Does it behave like the existing pipe demuxer?
>
Piping several WebP images (may be non-animated or animated) is supported.
webp_probe checks if the first one is WebP so the WebP demuxer should be
used.
> +static int resync(AVFormatContext *s, int seek_to_start)
> > +{
> > + WebPDemuxContext *wdc = s->priv_data;
> > + AVIOContext *pb = s->pb;
> > + int ret;
> > + int i;
> > + uint64_t state = 0;
> > +
> > + // ensure seek back for the file header and the first chunk header
> > + if ((ret = ensure_seekback(s, 12 + 8)) < 0)
> > + return ret;
> > +
> > + for (i = 0; i < 12; i++) {
> > + state = (state << 8) | avio_r8(pb);
>
> > + if (i == 11) {
> > + if ((uint32_t) state == MKBETAG('W', 'E', 'B', 'P'))
>
> The cast looks really ugly: Why is it necessary?
>
The signature of the WebP file is the following 12 bytes: "RIFF" <uint32_t
size> "WEBP".
The state is uint64_t. At this point, the state should contain bytes 4-11
of the signature (size and "WEBP") so the code checks that the lower 32
bits are "WEBP".
Alternatively there may be "state & 0xffffffff". I used the typecast as I
have seen it somewhere else (original WebP parser).
Josef
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
