That would harm the resultant output size, potentially a fair bit, since we
should expect that the dynamic table entries are more likely to be
referenced, they should be lower in the address space.
-=R
On Fri, Oct 18, 2013 at 7:25 PM, Tatsuhiro Tsujikawa
<tatsuhiro.t@gmail.com>wrote:
> How about put static table before dynamic table. Then encoder does not
> need to track the size of the entry beyond its boundary. It still needs to
> take care reference set toggle though.
>
> Best regards,
> Tatsuhiro Tsujikawa
>
> 2013/10/19 1:53 "Martin Thomson" <martin.thomson@gmail.com>:
>
> >
> > On 18 October 2013 09:23, Roberto Peon <grmocg@gmail.com> wrote:
> > > How about an implementation considerations section where we talk about
> how
> > > implementations might leverage the spec in various scenarios?
> >
> > I think that it's more than that. An encoder doesn't have to track
> > the entire table, but they do need to track sizes if they ever intend
> > to use the static table. As long as they don't intend to reuse the
> > entries, then they don't have to keep the actual values. An encoder
> > doesn't need to track entry sizes unless they want to use the static
> > table.
> >
> > I think that's the only consequences to this for an encoder. The cost
> > to the encoder is pitifully small when compared to the work and
> > commitment required by a decoder. Just make a note of this and move
> > on.
>
>