On Fri, Nov 3, 2017 at 12:38 AM, Derek Buitenhuis
wrote:
> On 11/2/2017 10:48 PM, Kieran Kunhya wrote:
>> I have tried this using the following patch but it does not work:
>> https://www.irccloud.com/pastebin/qobTcW9d/
>>
>> Nothing obviously seems wrong so I suspect
On 11/2/2017 10:48 PM, Kieran Kunhya wrote:
> I have tried this using the following patch but it does not work:
> https://www.irccloud.com/pastebin/qobTcW9d/
>
> Nothing obviously seems wrong so I suspect it's not possible to do this
> whilst reusing the code between decoder and parser.
> The old
>
> The idea would be that there would only be one uint8_t buffer and the
> 2000 entries from te pool would point into that.
> So as a larger NAL shifts through the 2000 the pointers would get
> distributed differently but the size would not grow
> Any variable size buffer the H2645NAL needs would
On 11/1/2017 1:36 AM, Michael Niedermayer wrote:
> The idea would be that there would only be one uint8_t buffer and the
> 2000 entries from te pool would point into that.
> So as a larger NAL shifts through the 2000 the pointers would get
> distributed differently but the size would not grow
>
On Tue, Oct 31, 2017 at 08:24:37PM +, Derek Buitenhuis wrote:
> On 10/31/2017 2:25 AM, Michael Niedermayer wrote:
> > (though as said, this fix is not ideal or complete, I would very much
> > prefer if this would be fixed by using a single buffer or any other
> > solution that avoids the
On Tue, 31 Oct 2017 at 22:36 Niki Bowe
wrote:
> I was going to prepare a patch, but it sounds like Kieran is going to.
> Thank you Kieran. Let me know if there's anything you want me to do, or if
> you would prefer me to do it for the experience.
>
> As for the
Thank you Kieran, Michael, Derek, and Carl.
I ran some benchmarks and the patch I provided really does have a speed
impact so I was considering alternative ways to achieve the same result.
After a little thought last week I came to the same conclusion as Michael
that a single rbsp_buffer per
>
> Am I missing something here?
>
> P.S. I see Kieran mailed the same thing as I wrote this.
>
Further to Derek's excellent explanation, I think the best way is to go
back to the old "in-place" NAL parsing code for H264.
I will prepare a patch to do this.
Kieran
On 10/31/2017 2:25 AM, Michael Niedermayer wrote:
> (though as said, this fix is not ideal or complete, I would very much
> prefer if this would be fixed by using a single buffer or any other
> solution that avoids the speedloss.)
Using a single buffer would be marginally faster, but it does
>
> This reduces memory consumption to linear from qudratic but i think
> it still can be made to allocate very large amounts of memory.
> That is with many small NAL units MAX_MBPAIR_SIZE would be allocated
> for each.in worst case.
> So this does fix the qudratic issue but not the OOM issue.
>
On Tue, 31 Oct 2017 at 02:26 Michael Niedermayer
wrote:
> On Thu, Oct 19, 2017 at 11:46:47AM -0700, Nikolas Bowe wrote:
> > Found via fuzzing.
> > /tmp/poc is a 1 MB mpegts file generated via fuzzing, where 1 packet has
> many NALUs
> > Before this change:
> > $
On Thu, Oct 19, 2017 at 11:46:47AM -0700, Nikolas Bowe wrote:
> Found via fuzzing.
> /tmp/poc is a 1 MB mpegts file generated via fuzzing, where 1 packet has many
> NALUs
> Before this change:
> $ /usr/bin/time -f "\t%M Max Resident Set Size (Kb)" ./ffprobe /tmp/poc
> 2>&1 | tail -n 1
>
On Thu, Oct 19, 2017 at 11:46:47AM -0700, Nikolas Bowe wrote:
> Found via fuzzing.
> /tmp/poc is a 1 MB mpegts file generated via fuzzing, where 1 packet has many
> NALUs
> Before this change:
> $ /usr/bin/time -f "\t%M Max Resident Set Size (Kb)" ./ffprobe /tmp/poc
> 2>&1 | tail -n 1
>
Hi
On Mon, Oct 23, 2017 at 04:43:55PM -0700, Niki Bowe wrote:
> On Thu, Oct 19, 2017 at 3:39 PM, Carl Eugen Hoyos
> wrote:
>
> > 2017-10-19 20:46 GMT+02:00 Nikolas Bowe :
> > > Found via fuzzing.
> > > /tmp/poc is a 1 MB mpegts file generated
On Tue, 31 Oct 2017 at 01:42 Kieran Kunhya wrote:
> On Tue, 24 Oct 2017 at 00:56 Carl Eugen Hoyos wrote:
>
>> 2017-10-24 1:43 GMT+02:00 Niki Bowe :
>> > On Thu, Oct 19, 2017 at 3:39 PM, Carl Eugen Hoyos
>>
On Tue, 24 Oct 2017 at 00:56 Carl Eugen Hoyos wrote:
> 2017-10-24 1:43 GMT+02:00 Niki Bowe :
> > On Thu, Oct 19, 2017 at 3:39 PM, Carl Eugen Hoyos
> > wrote:
>
> >> Does the patch have a measurable speed impact?
> >>
> > Is
2017-10-24 1:43 GMT+02:00 Niki Bowe :
> On Thu, Oct 19, 2017 at 3:39 PM, Carl Eugen Hoyos
> wrote:
>> Does the patch have a measurable speed impact?
>>
> Is there a standard set of benchmarks I can run?
>
> For typical videos the speed impact
On Thu, Oct 19, 2017 at 3:39 PM, Carl Eugen Hoyos
wrote:
> 2017-10-19 20:46 GMT+02:00 Nikolas Bowe :
> > Found via fuzzing.
> > /tmp/poc is a 1 MB mpegts file generated via fuzzing, where 1 packet has
> many NALUs
> > Before this change:
> >
2017-10-19 20:46 GMT+02:00 Nikolas Bowe :
> Found via fuzzing.
> /tmp/poc is a 1 MB mpegts file generated via fuzzing, where 1 packet has many
> NALUs
> Before this change:
> $ /usr/bin/time -f "\t%M Max Resident Set Size (Kb)" ./ffprobe /tmp/poc
> 2>&1 | tail
Found via fuzzing.
/tmp/poc is a 1 MB mpegts file generated via fuzzing, where 1 packet has many
NALUs
Before this change:
$ /usr/bin/time -f "\t%M Max Resident Set Size (Kb)" ./ffprobe /tmp/poc 2>&1
| tail -n 1
2158192 Max Resident Set Size (Kb)
After this change:
$ /usr/bin/time
20 matches
Mail list logo