| Message ID | 20161207180632.23815-1-derek.buitenhuis@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
2016-12-07 19:06 GMT+01:00 Derek Buitenhuis <derek.buitenhuis@gmail.com>: > This could happen when there was a frame number > gap and frame threading was used. > > This fixes #5458. Does this patch have a speed impact on valid streams? I ask because the sample stream is invalid so I thought ex falso quodlibet would apply. Carl Eugen
On 12/7/2016 6:43 PM, Carl Eugen Hoyos wrote: > 2016-12-07 19:06 GMT+01:00 Derek Buitenhuis <derek.buitenhuis@gmail.com>: >> This could happen when there was a frame number >> gap and frame threading was used. >> >> This fixes #5458. > > Does this patch have a speed impact on valid streams? > I ask because the sample stream is invalid so I thought > ex falso quodlibet would apply. No, it should only run on invalid/damaged streams. - Derek
On Wed, Dec 07, 2016 at 06:06:32PM +0000, Derek Buitenhuis wrote: > This could happen when there was a frame number gap and frame threading was used. > > This fixes #5458. > > Debugging-by: Ronald S. Bultje <rsbultje@gmail.com> > Debugging-by: Justin Ruggles <justin.ruggles@gmail.com> > Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com> > --- > This fixes a ton of samples that had frame num gaps and were decoding using large > numbers of threads. > --- > libavcodec/h264_slice.c | 3 +++ > 1 file changed, 3 insertions(+) this deadlocks on some samples ill try to find one that i can share [...]
On 12/7/2016 8:10 PM, Michael Niedermayer wrote: > this deadlocks on some samples > ill try to find one that i can share I have a vague idea maybe why, but I'd need a sample, yes. - Derek
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c index 1f2c06521e..480340b854 100644 --- a/libavcodec/h264_slice.c +++ b/libavcodec/h264_slice.c @@ -1424,6 +1424,9 @@ static int h264_field_start(H264Context *h, const H264SliceContext *sl, h->short_ref[0]->f->width == prev->f->width && h->short_ref[0]->f->height == prev->f->height && h->short_ref[0]->f->format == prev->f->format) { + ff_thread_await_progress(&prev->tf, INT_MAX, 0); + if (prev->f->interlaced_frame) + ff_thread_await_progress(&prev->tf, INT_MAX, 1); av_image_copy(h->short_ref[0]->f->data, h->short_ref[0]->f->linesize, (const uint8_t **)prev->f->data,
This could happen when there was a frame number gap and frame threading was used. This fixes #5458. Debugging-by: Ronald S. Bultje <rsbultje@gmail.com> Debugging-by: Justin Ruggles <justin.ruggles@gmail.com> Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com> --- This fixes a ton of samples that had frame num gaps and were decoding using large numbers of threads. --- libavcodec/h264_slice.c | 3 +++ 1 file changed, 3 insertions(+)