Quoting Andreas Rheinhardt (2020-05-29 17:52:40)
> Ping. What is other's opinion on this matter? Notice that the current
> behaviour is suboptimal even if it is decided that the buffer should not
> be kept: It allocates 1/16 more than needed (in addition to
> AV_INPUT_BUFFER_PADDING_SIZE) that is
Andreas Rheinhardt:
> Kieran Kunhya:
>> On Fri, 16 Aug 2019 at 06:08, Andreas Rheinhardt <
>> andreas.rheinha...@gmail.com> wrote:
>>
>>> Kieran Kunhya:
On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Up until now, the H.264 parser has
Kieran Kunhya:
> On Fri, 16 Aug 2019 at 06:08, Andreas Rheinhardt <
> andreas.rheinha...@gmail.com> wrote:
>
>> Kieran Kunhya:
>>> On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt <
>>> andreas.rheinha...@gmail.com> wrote:
>>>
Up until now, the H.264 parser has allocated a new buffer for
On Fri, 16 Aug 2019 at 06:08, Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Kieran Kunhya:
> > On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt <
> > andreas.rheinha...@gmail.com> wrote:
> >
> >> Up until now, the H.264 parser has allocated a new buffer for every
> >> frame in order
Kieran Kunhya:
> On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt <
> andreas.rheinha...@gmail.com> wrote:
>
>> Up until now, the H.264 parser has allocated a new buffer for every
>> frame in order to store the unescaped RBSP in case the part of the RBSP
>> that will be unescaped contains 0x03
On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Up until now, the H.264 parser has allocated a new buffer for every
> frame in order to store the unescaped RBSP in case the part of the RBSP
> that will be unescaped contains 0x03 escape bytes. This is
