On Tue, Oct 9, 2018 at 10:15 AM Derek Buitenhuis
wrote:
>
> On 08/10/2018 16:36, Derek Buitenhuis wrote:
> > If we don't copy this value first, it is seen as 0 by
> > h264_slice_header_init,
> > due to zero-allocation of the new context, triggering an old hack that
> > multiplied the denominator
On 08/10/2018 16:36, Derek Buitenhuis wrote:
> If we don't copy this value first, it is seen as 0 by h264_slice_header_init,
> due to zero-allocation of the new context, triggering an old hack that
> multiplied the denominator by 2 for files produced by old x264 versions, but
> only if more than
On 08/10/2018 19:52, Carl Eugen Hoyos wrote:
> Please also mention ticket #7083 in the commit message.
>
> Sorry for my other mail, thank you for testing again!
Added locally, thanks.
Wasn't aware of that bug; could have saved me 30 mins of printf debugging.
- Derek
2018-10-08 17:36 GMT+02:00, Derek Buitenhuis :
> If we don't copy this value first, it is seen as 0 by
> h264_slice_header_init,
> due to zero-allocation of the new context, triggering an old hack that
> multiplied the denominator by 2 for files produced by old x264 versions, but
> only if more
On 10/8/2018 3:45 PM, Derek Buitenhuis wrote:
> On 08/10/2018 19:23, Carl Eugen Hoyos wrote:
>> I cannot reproduce ticket #7475 (it says "framerate num 30 den 1"
>> no matter how many threads I use, tested with up to 8), and - more
>> related to this patch - the sample from ticket #7475 reaches
On 08/10/2018 19:23, Carl Eugen Hoyos wrote:
> I cannot reproduce ticket #7475 (it says "framerate num 30 den 1"
> no matter how many threads I use, tested with up to 8), and - more
> related to this patch - the sample from ticket #7475 reaches neither
> line 358 nor line 400 in h264_slice.c here
2018-10-08 17:36 GMT+02:00, Derek Buitenhuis :
> If we don't copy this value first, it is seen as 0 by
> h264_slice_header_init,
> due to zero-allocation of the new context, triggering an old hack that
> multiplied the denominator by 2 for files produced by old x264 versions, but
> only if more
If we don't copy this value first, it is seen as 0 by h264_slice_header_init,
due to zero-allocation of the new context, triggering an old hack that
multiplied the denominator by 2 for files produced by old x264 versions, but
only if more than one thread was used.
Fixes #7475.
Signed-off-by: