[FFmpeg-devel] [PATCH V3] lavc/golomb: Fix UE golomb overwrite issue.

[Michael Niedermayer]

On Thu, Jun 08, 2017 at 01:07:40PM +0100, Mark Thompson wrote:
> On 08/06/17 12:35, Michael Niedermayer wrote:
> > On Thu, Jun 08, 2017 at 11:02:30AM +0100, Mark Thompson wrote:
> >> On 08/06/17 01:29, Jun Zhao wrote:
> >>> V3: Clean the code logic base on Michael's review.
> >>> V2: Add Add set_ue_golomb_long() to support 32bits UE golomb and update the unit test.
> >>>
> >>> From 4de3e0c30af7bc1901562000eda018a6d6849292 Mon Sep 17 00:00:00 2001
> >>> From: Jun Zhao <jun.zhao at intel.com>
> >>> Date: Fri, 2 Jun 2017 15:05:49 +0800
> >>> Subject: [PATCH V3] lavc/golomb: Fix UE golomb overwrite issue.
> >>>
> >>> put_bits just support write up to 31 bits, when write 32 bit in
> >>> put_bits, it's will overwrite the bit buffer, because the default
> >>> assert level is 0, the av_assert2(n <= 31 && value < (1U << n))
> >>> in put_bits can not be trigger runtime. Add set_ue_golomb_long()
> >>> to support 32bits UE golomb.
> >>>
> >>> Signed-off-by: Jun Zhao <jun.zhao at intel.com>
> > [...]
> >>> +
> >>> +    if (i < 256)
> >>> +        put_bits(pb, ff_ue_golomb_len[i], i + 1);
> >>> +    else {
> >>> +        int e = av_log2(i + 1);
> >>> +        put_bits64(pb, 2 * e + 1, i + 1);
> >>> +    }
> >>> +}
> >>
> >> Please don't add a new function, just extend the existing one.  set_ue_golomb() is not used in any place where minor ricing is of any value, and having another function will only be confusing over which to use (or, more likely, people will always use the long version in order to avoid thinking about it just like they do with get_ue_golomb() - cf. "grep get_ue_golomb libavcodec/hevc*").
> > 
> > No question its easier to do something random than to think about
> > the range allowed by the specification.
> > But when writing data, its neccessary to comply to the specification,
> > otherwise one creates invalid streams. So theres no way around thinking
> > about the range even with just one function.
> 
> I don't understand what you're trying to say here.

Iam saying that the argument you use implies that one has to write
code quite sloppy. (that is way sloppier than we normally do)

The author has to think about what is the valid range before writing
a value in the bitstream.
You said "... people will always use the long version in order to avoid thinking about it ..."
That really is not what they can do. They have to think about what
range is valid so as to make sure they do not create invalid bitstreams


> I'm suggesting that it would be better to extend the range of values that set_ue_golomb() supports, so that it can correctly write values up to 2^32-2.
> Since this is the largest value H.264 and H.265 ever require,

> any use with those standards is known to be in-range and no further thought is needed.

as said above, thought is needed when writing things according to a
specification, so as to make sure one does not violate the
specification

The 2 options suggested if iam not missing one are

1. one function which supports the whole range
2. two functions one optimized for a small range, one for the full
range

For both cases, the user of this function must check the spec and
range for EVERY use and ensure that the values written are not
violating the relevant specification.
We do NOT need more invalid files ...

In some cases explicit checks will be needed at some earlier point
to ensure no invalid values are generated which would later be written.
In some cases no checks are needed but one still has to make sure
that is so and nothing is missing ...

Seperate of this are speed and code size aspects

If theres just one function, should that one function be "inline" ?
should maybe the code writing larger values be in a never inline
function called from it ?

inlining all this code on every call even if never used is a waste
of cpu cache, memory and so forth.
people comlpained about error messages taking up space (which are
tiny in comparission to this)


> It is possible that some other codec might want to use larger Exp-Golomb codes - if that happens then indeed more thought will be required when implementing that codec, but it shouldn't affect anyone else.


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170608/4d43add6/attachment.sig>