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.z...@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.z...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
