Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
> -Original Message- > From: ffmpeg-devel On Behalf Of Ronald S. > Bultje > Sent: Thursday, November 9, 2023 12:38 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for VP8 > codec bitstream > > Hi, > > On Wed, Nov 8, 2023 at 10:55 AM Ronald S. Bultje wrote: > > > Hi Jianhui, > > > > On Tue, Nov 7, 2023 at 8:52 PM Dai, Jianhui J < > > jianhui.j.dai-at-intel@ffmpeg.org> wrote: > > > >> The smaller delta patch to export the variable: > >> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/DM6PR11MB268186349E > >> 600824e1577dfdb1...@dm6pr11mb2681.namprd11.prod.outlook.com/ > >> Personally, I prefer to limit the static data only in vp8.c. > >> > > > > Understood. It's going to be a dice-roll either way, and since I'm the > > maintainer, I get to pick :-). I prefer continuing with what we have > > in this version, but I'll leave it open for the majority opinion to > > overrule me for a few days before we merge this. > > > > Actually, I realize that sounds quite rude, so let me elaborate: I prefer > external > data tables (in a separate source file from the rest of the code) because > they tend > to be big and clunky and you can't really change them anyway. They are > essentially binary blob in numerical form. We use external data tables in > quite a > few parts of ffmpeg and I've grown accustomed to that design. For now, for old > codecs where nothing much changes over time, I prefer to keep it as it is. > Small > diffs means easy to trace back when stuff breaks, as a general rule. > > But I admit that all this is personal preference. There's nothing wrong with a > different approach, it's just that: different. Let's agree on a color > (green!) and > move on to shiny new objects. I fully respect all of the feedback provided during the code review. Thank you for your patience. : ) I don’t have the commit access. Appreciate to help to submit if everything goes well. > > Ronald > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
Hi, On Wed, Nov 8, 2023 at 10:55 AM Ronald S. Bultje wrote: > Hi Jianhui, > > On Tue, Nov 7, 2023 at 8:52 PM Dai, Jianhui J < > jianhui.j.dai-at-intel@ffmpeg.org> wrote: > >> The smaller delta patch to export the variable: >> https://patchwork.ffmpeg.org/project/ffmpeg/patch/dm6pr11mb268186349e600824e1577dfdb1...@dm6pr11mb2681.namprd11.prod.outlook.com/ >> Personally, I prefer to limit the static data only in vp8.c. >> > > Understood. It's going to be a dice-roll either way, and since I'm the > maintainer, I get to pick :-). I prefer continuing with what we have in > this version, but I'll leave it open for the majority opinion to overrule > me for a few days before we merge this. > Actually, I realize that sounds quite rude, so let me elaborate: I prefer external data tables (in a separate source file from the rest of the code) because they tend to be big and clunky and you can't really change them anyway. They are essentially binary blob in numerical form. We use external data tables in quite a few parts of ffmpeg and I've grown accustomed to that design. For now, for old codecs where nothing much changes over time, I prefer to keep it as it is. Small diffs means easy to trace back when stuff breaks, as a general rule. But I admit that all this is personal preference. There's nothing wrong with a different approach, it's just that: different. Let's agree on a color (green!) and move on to shiny new objects. Ronald ___ 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".
Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
Hi Jianhui, On Tue, Nov 7, 2023 at 8:52 PM Dai, Jianhui J < jianhui.j.dai-at-intel@ffmpeg.org> wrote: > The smaller delta patch to export the variable: > https://patchwork.ffmpeg.org/project/ffmpeg/patch/dm6pr11mb268186349e600824e1577dfdb1...@dm6pr11mb2681.namprd11.prod.outlook.com/ > Personally, I prefer to limit the static data only in vp8.c. > Understood. It's going to be a dice-roll either way, and since I'm the maintainer, I get to pick :-). I prefer continuing with what we have in this version, but I'll leave it open for the majority opinion to overrule me for a few days before we merge this. Do you need me to merge or do you have commit access? If you adapt the cbs patch to use this (newly) exported table, I have no further review comments. Ronald ___ 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".
Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
> -Original Message-
> From: ffmpeg-devel On Behalf Of Ronald S.
> Bultje
> Sent: Wednesday, November 8, 2023 4:26 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for VP8
> codec bitstream
>
> Hi,
>
> On Tue, Nov 7, 2023 at 12:01 AM Dai, Jianhui J < jianhui.j.dai-at-
> intel@ffmpeg.org> wrote:
>
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Ronald S. Bultje
> > > Sent: Monday, November 6, 2023 8:08 PM
> > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support
> > > for
> > > VP8 codec bitstream
> > >
> > > Hi,
> > >
> > > On Mon, Nov 6, 2023 at 7:07 AM Ronald S. Bultje
> > > wrote:
> > >
> > > > On Sun, Nov 5, 2023 at 11:13 PM Dai, Jianhui J <
> > > > jianhui.j.dai-at-intel@ffmpeg.org> wrote:
> > > >
> > > >> > > +static const uint8_t vp8_token_update_probs[4][8][3][11] = {
> > > >> >
> > > >> > It would be nice if these symbols could be re-used from the
> > > >> > existing vp8 native decoder, instead of duplicating them? Both
> > > >> > source + binary size
> > > >> are
> > > >> > relevant here.
> > > >>
> > > >> Including vp8data.h would introduce many unwanted static tables
> > > >> other than vp8_token_update_probs and increase the binary size.
> > > >> As suggested in patch v3, it is better to use local defined
> > > >> vp8_token_update_probs.
> > > >>
> > > >
> > > > I didn't mean to include vp8data.h. I mean to include a new *.h
> > > > that declares extern const uint8_t vp8_token_update_probs[][][][]
> > > > and move said table into a new *.c file. The point is to prevent
> > > > symbol
> > duplication.
> > > >
> > >
> > > And to elaborate further, in case it's unclear: the symbol move
> > > means the native VP8 decoder would include this probability table
> > > using the same
> > new
> > > mechanism also. It would no longer exist in vp8data.h.
> >
> > Right.
> > I made another change to reorganize the vp8data.[c|h] and only export
> > ` ff_vp8_dct_cat_prob` and `ff_vp8_token_default_probs`.
> > Please take a look.
> >
>
> I'm not sure it's a good idea to move all tables back into vp8.c. There's a
> reason
> we added it in a separate header file, so that "large random tables with
> numbers"
> don't obfuscate the actual source code file. Or to say it
> diffrently: you could probably have accomplished the same effect with a much
> smaller diff... That's just my opinion though. Anyone else care about any of
> this?
The smaller delta patch to export the variable:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/dm6pr11mb268186349e600824e1577dfdb1...@dm6pr11mb2681.namprd11.prod.outlook.com/
Personally, I prefer to limit the static data only in vp8.c.
>
> Ronald
> ___
> 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".
___
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".
Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
Hi,
On Tue, Nov 7, 2023 at 12:01 AM Dai, Jianhui J <
jianhui.j.dai-at-intel@ffmpeg.org> wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Ronald S. Bultje
> > Sent: Monday, November 6, 2023 8:08 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for
> > VP8 codec bitstream
> >
> > Hi,
> >
> > On Mon, Nov 6, 2023 at 7:07 AM Ronald S. Bultje
> > wrote:
> >
> > > On Sun, Nov 5, 2023 at 11:13 PM Dai, Jianhui J <
> > > jianhui.j.dai-at-intel@ffmpeg.org> wrote:
> > >
> > >> > > +static const uint8_t vp8_token_update_probs[4][8][3][11] = {
> > >> >
> > >> > It would be nice if these symbols could be re-used from the
> > >> > existing vp8 native decoder, instead of duplicating them? Both
> > >> > source + binary size
> > >> are
> > >> > relevant here.
> > >>
> > >> Including vp8data.h would introduce many unwanted static tables other
> > >> than vp8_token_update_probs and increase the binary size.
> > >> As suggested in patch v3, it is better to use local defined
> > >> vp8_token_update_probs.
> > >>
> > >
> > > I didn't mean to include vp8data.h. I mean to include a new *.h that
> > > declares extern const uint8_t vp8_token_update_probs[][][][] and move
> > > said table into a new *.c file. The point is to prevent symbol
> duplication.
> > >
> >
> > And to elaborate further, in case it's unclear: the symbol move means the
> > native VP8 decoder would include this probability table using the same
> new
> > mechanism also. It would no longer exist in vp8data.h.
>
> Right.
> I made another change to reorganize the vp8data.[c|h] and only export `
> ff_vp8_dct_cat_prob` and `ff_vp8_token_default_probs`.
> Please take a look.
>
I'm not sure it's a good idea to move all tables back into vp8.c. There's a
reason we added it in a separate header file, so that "large random tables
with numbers" don't obfuscate the actual source code file. Or to say it
diffrently: you could probably have accomplished the same effect with a
much smaller diff... That's just my opinion though. Anyone else care about
any of this?
Ronald
___
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".
Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Ronald S. Bultje
> Sent: Monday, November 6, 2023 8:08 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for
> VP8 codec bitstream
>
> Hi,
>
> On Mon, Nov 6, 2023 at 7:07 AM Ronald S. Bultje
> wrote:
>
> > On Sun, Nov 5, 2023 at 11:13 PM Dai, Jianhui J <
> > jianhui.j.dai-at-intel@ffmpeg.org> wrote:
> >
> >> > > +static const uint8_t vp8_token_update_probs[4][8][3][11] = {
> >> >
> >> > It would be nice if these symbols could be re-used from the
> >> > existing vp8 native decoder, instead of duplicating them? Both
> >> > source + binary size
> >> are
> >> > relevant here.
> >>
> >> Including vp8data.h would introduce many unwanted static tables other
> >> than vp8_token_update_probs and increase the binary size.
> >> As suggested in patch v3, it is better to use local defined
> >> vp8_token_update_probs.
> >>
> >
> > I didn't mean to include vp8data.h. I mean to include a new *.h that
> > declares extern const uint8_t vp8_token_update_probs[][][][] and move
> > said table into a new *.c file. The point is to prevent symbol duplication.
> >
>
> And to elaborate further, in case it's unclear: the symbol move means the
> native VP8 decoder would include this probability table using the same new
> mechanism also. It would no longer exist in vp8data.h.
Right.
I made another change to reorganize the vp8data.[c|h] and only export `
ff_vp8_dct_cat_prob` and `ff_vp8_token_default_probs`.
Please take a look.
https://patchwork.ffmpeg.org/project/ffmpeg/patch/dm6pr11mb2681fcca688553fa8f1a7218b1...@dm6pr11mb2681.namprd11.prod.outlook.com/
>
> Ronald
> ___
> 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".
___
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".
Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
Hi,
On Mon, Nov 6, 2023 at 7:07 AM Ronald S. Bultje wrote:
> On Sun, Nov 5, 2023 at 11:13 PM Dai, Jianhui J <
> jianhui.j.dai-at-intel@ffmpeg.org> wrote:
>
>> > > +static const uint8_t vp8_token_update_probs[4][8][3][11] = {
>> >
>> > It would be nice if these symbols could be re-used from the existing vp8
>> > native decoder, instead of duplicating them? Both source + binary size
>> are
>> > relevant here.
>>
>> Including vp8data.h would introduce many unwanted static tables other
>> than vp8_token_update_probs and increase the binary size.
>> As suggested in patch v3, it is better to use local defined
>> vp8_token_update_probs.
>>
>
> I didn't mean to include vp8data.h. I mean to include a new *.h that
> declares extern const uint8_t vp8_token_update_probs[][][][] and move said
> table into a new *.c file. The point is to prevent symbol duplication.
>
And to elaborate further, in case it's unclear: the symbol move means the
native VP8 decoder would include this probability table using the same new
mechanism also. It would no longer exist in vp8data.h.
Ronald
___
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".
Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
Hi,
On Sun, Nov 5, 2023 at 11:13 PM Dai, Jianhui J <
jianhui.j.dai-at-intel@ffmpeg.org> wrote:
> > > +static const uint8_t vp8_token_update_probs[4][8][3][11] = {
> >
> > It would be nice if these symbols could be re-used from the existing vp8
> > native decoder, instead of duplicating them? Both source + binary size
> are
> > relevant here.
>
> Including vp8data.h would introduce many unwanted static tables other than
> vp8_token_update_probs and increase the binary size.
> As suggested in patch v3, it is better to use local defined
> vp8_token_update_probs.
>
I didn't mean to include vp8data.h. I mean to include a new *.h that
declares extern const uint8_t vp8_token_update_probs[][][][] and move said
table into a new *.c file. The point is to prevent symbol duplication.
Ronald
___
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".
Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Ronald S. Bultje
> Sent: Monday, November 6, 2023 10:48 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for
> VP8 codec bitstream
>
> Hi,
>
> On Sun, Nov 5, 2023 at 7:56 PM Dai, Jianhui J < jianhui.j.dai-at-
> intel@ffmpeg.org> wrote:
>
> > This commit adds support for VP8 bitstream read methods to the cbs
> > codec. This enables the trace_headers bitstream filter to support VP8,
> > in addition to AV1, H.264, H.265, and VP9. This can be useful for
> > debugging VP8 stream issues.
> >
> > The CBS VP8 implements a simple VP8 boolean decoder using
> > GetBitContext to read the bitstream.
> >
>
> Is it possible to re-use the existing vp56rac decoder for this? Having two
> arithmetic bool decoders that do the same thing is a bit weird.
>
Thank for your commentary.
The existing RAC decoder cannot be reused here because:
1. The VPXRangeCoder is optimized for performance, that it always read one more
byte. However, it does not apply bounds checking to prevent overreads.
It was suggested to implement this simply boolean reader, in the comment of
patch v1 and v2.
2. Additionally, all CBS have to use GetBitContext to read bitstream and trace
the syntax elements.
>
> > +static const uint8_t vp8_token_update_probs[4][8][3][11] = {
> >
>
> It would be nice if these symbols could be re-used from the existing vp8
> native decoder, instead of duplicating them? Both source + binary size are
> relevant here.
Including vp8data.h would introduce many unwanted static tables other than
vp8_token_update_probs and increase the binary size.
As suggested in patch v3, it is better to use local defined
vp8_token_update_probs.
>
> I'm also wondering if - longer-term - it makes sense to try to merge some of
> these concepts back into the native decoders, objects like
> Vp8RawFameHeader, but I'm guessing that's not super-urgent...
Thanks. That can be reused in the future.
>
> Ronald
> ___
> 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".
___
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".
Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
Hi,
On Sun, Nov 5, 2023 at 7:56 PM Dai, Jianhui J <
jianhui.j.dai-at-intel@ffmpeg.org> wrote:
> This commit adds support for VP8 bitstream read methods to the cbs
> codec. This enables the trace_headers bitstream filter to support VP8,
> in addition to AV1, H.264, H.265, and VP9. This can be useful for
> debugging VP8 stream issues.
>
> The CBS VP8 implements a simple VP8 boolean decoder using GetBitContext
> to read the bitstream.
>
Is it possible to re-use the existing vp56rac decoder for this? Having two
arithmetic bool decoders that do the same thing is a bit weird.
> +static const uint8_t vp8_token_update_probs[4][8][3][11] = {
>
It would be nice if these symbols could be re-used from the existing vp8
native decoder, instead of duplicating them? Both source + binary size are
relevant here.
I'm also wondering if - longer-term - it makes sense to try to merge some
of these concepts back into the native decoders, objects like
Vp8RawFameHeader, but I'm guessing that's not super-urgent...
Ronald
___
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".
[FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
This commit adds support for VP8 bitstream read methods to the cbs
codec. This enables the trace_headers bitstream filter to support VP8,
in addition to AV1, H.264, H.265, and VP9. This can be useful for
debugging VP8 stream issues.
The CBS VP8 implements a simple VP8 boolean decoder using GetBitContext
to read the bitstream.
Only the read methods `read_unit` and `split_fragment` are implemented.
The write methods `write_unit` and `assemble_fragment` return the error
code AVERROR_PATCHWELCOME. This is because CBS VP8 write is unlikely to
be used by any applications at the moment. The write methods can be
added later if there is a real need for them.
TESTS: ffmpeg -i fate-suite/vp8/frame_size_change.webm -vcodec copy
-bsf:v trace_headers -f null -
Signed-off-by: Jianhui Dai
---
configure| 4 +-
libavcodec/Makefile | 1 +
libavcodec/cbs.c | 6 +
libavcodec/cbs_internal.h| 1 +
libavcodec/cbs_vp8.c | 548 +++
libavcodec/cbs_vp8.h | 133 +++
libavcodec/cbs_vp8_syntax_template.c | 248
7 files changed, 940 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/cbs_vp8.c
create mode 100644 libavcodec/cbs_vp8.h
create mode 100644 libavcodec/cbs_vp8_syntax_template.c
diff --git a/configure b/configure
index 7afeebebcd..8a4ea125ad 100755
--- a/configure
+++ b/configure
@@ -2471,6 +2471,7 @@ CONFIG_EXTRA="
cbs_h266
cbs_jpeg
cbs_mpeg2
+cbs_vp8
cbs_vp9
deflate_wrapper
dirac_parse
@@ -2756,6 +2757,7 @@ cbs_h265_select="cbs"
cbs_h266_select="cbs"
cbs_jpeg_select="cbs"
cbs_mpeg2_select="cbs"
+cbs_vp8_select="cbs"
cbs_vp9_select="cbs"
deflate_wrapper_deps="zlib"
dirac_parse_select="golomb"
@@ -3339,7 +3341,7 @@ h264_redundant_pps_bsf_select="cbs_h264"
hevc_metadata_bsf_select="cbs_h265"
mjpeg2jpeg_bsf_select="jpegtables"
mpeg2_metadata_bsf_select="cbs_mpeg2"
-trace_headers_bsf_select="cbs"
+trace_headers_bsf_select="cbs cbs_vp8"
vp9_metadata_bsf_select="cbs_vp9"
vvc_metadata_bsf_select="cbs_h266"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ab7fba394a..7b0f9ab550 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -81,6 +81,7 @@ OBJS-$(CONFIG_CBS_H265)+= cbs_h2645.o
cbs_sei.o h2645_parse.o
OBJS-$(CONFIG_CBS_H266)+= cbs_h2645.o cbs_sei.o h2645_parse.o
OBJS-$(CONFIG_CBS_JPEG)+= cbs_jpeg.o
OBJS-$(CONFIG_CBS_MPEG2) += cbs_mpeg2.o
+OBJS-$(CONFIG_CBS_VP8) += cbs_vp8.o
OBJS-$(CONFIG_CBS_VP9) += cbs_vp9.o
OBJS-$(CONFIG_CRYSTALHD) += crystalhd.o
OBJS-$(CONFIG_DEFLATE_WRAPPER) += zlib_wrapper.o
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index cdd7adebeb..de7b1361aa 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -50,6 +50,9 @@ static const CodedBitstreamType *const cbs_type_table[] = {
#if CONFIG_CBS_MPEG2
&ff_cbs_type_mpeg2,
#endif
+#if CONFIG_CBS_VP8
+&ff_cbs_type_vp8,
+#endif
#if CONFIG_CBS_VP9
&ff_cbs_type_vp9,
#endif
@@ -74,6 +77,9 @@ const enum AVCodecID ff_cbs_all_codec_ids[] = {
#if CONFIG_CBS_MPEG2
AV_CODEC_ID_MPEG2VIDEO,
#endif
+#if CONFIG_CBS_VP8
+AV_CODEC_ID_VP8,
+#endif
#if CONFIG_CBS_VP9
AV_CODEC_ID_VP9,
#endif
diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
index 07220f1f3e..d982262bd9 100644
--- a/libavcodec/cbs_internal.h
+++ b/libavcodec/cbs_internal.h
@@ -341,6 +341,7 @@ extern const CodedBitstreamType ff_cbs_type_h265;
extern const CodedBitstreamType ff_cbs_type_h266;
extern const CodedBitstreamType ff_cbs_type_jpeg;
extern const CodedBitstreamType ff_cbs_type_mpeg2;
+extern const CodedBitstreamType ff_cbs_type_vp8;
extern const CodedBitstreamType ff_cbs_type_vp9;
diff --git a/libavcodec/cbs_vp8.c b/libavcodec/cbs_vp8.c
new file mode 100644
index 00..79a2a9bba6
--- /dev/null
+++ b/libavcodec/cbs_vp8.c
@@ -0,0 +1,548 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avassert.h"
+
+#include "cbs.h"
+#include "cbs_internal.h"
+#include "cbs_vp8.h"
+
+#include
+
+#define DEFAULT_PROB 0x80
+
+static const uint8_t vp8_token_update_
