From af3381363c8f541fc4bf7e41d0e17b9baf6cc30a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?= Date: Mon, 23 Jan 2017 15:42:53 +0100 Subject: [PATCH] lavc/h264dec: abort frame threading in some cases Fixes regression in fate-h264-attachment-631 with THREADS=8 introduced in bdbbb8f11edbf10add874508c5125c174d8939be. (2nd attempt) This restores a chunk forgotten from the previously named decode_postinit function. Note that this disables frame threading on the following FATE tests: fate-h264-conformance-cabac_mot_fld0_full fate-h264-conformance-cabac_mot_picaff0_full fate-h264-conformance-cabref3_sand_d fate-h264-conformance-cafi1_sva_c fate-h264-conformance-cama1_vtc_c fate-h264-conformance-cama2_vtc_b fate-h264-conformance-cama3_vtc_b fate-h264-conformance-capa1_toshiba_b fate-h264-conformance-capama3_sand_f fate-h264-conformance-cavlc_mot_fld0_full_b fate-h264-conformance-cavlc_mot_picaff0_full_b fate-h264-conformance-cvfi1_sony_d fate-h264-conformance-cvfi1_sva_c fate-h264-conformance-cvfi2_sony_h fate-h264-conformance-cvfi2_sva_c fate-h264-conformance-cvmapaqp3_sony_e fate-h264-conformance-cvmp_mot_fld_l30_b fate-h264-conformance-cvmp_mot_frm_l31_b fate-h264-conformance-cvnlfi1_sony_c fate-h264-conformance-cvnlfi2_sony_h fate-h264-conformance-cvpa1_toshiba_b fate-h264-conformance-fi1_sony_e fate-h264-conformance-frext-bcrm_freh10 fate-h264-conformance-frext-brcm_freh11 fate-h264-conformance-frext-brcm_freh4 fate-h264-conformance-frext-freh6 fate-h264-conformance-frext-freh7_b fate-h264-conformance-frext-frext2_panasonic_b fate-h264-conformance-frext-frext4_panasonic_a fate-h264-conformance-frext-hcaff1_hhi_b fate-h264-conformance-frext-hpcafl_bcrm_c fate-h264-conformance-frext-hpcaflnl_bcrm_c fate-h264-conformance-frext-hpcamapalq_bcrm_b fate-h264-conformance-frext-hpcvfl_bcrm_a fate-h264-conformance-frext-hpcvflnl_bcrm_a fate-h264-conformance-mr6_bt_b fate-h264-conformance-mr7_bt_b fate-h264-conformance-mr8_bt_b fate-h264-conformance-mr9_bt_b fate-h264-conformance-sharp_mp_field_1_b fate-h264-conformance-sharp_mp_field_2_b fate-h264-conformance-sharp_mp_field_3_b fate-h264-conformance-sharp_mp_paff_1r2 fate-h264-conformance-sharp_mp_paff_2r fate-h264-3386 fate-h264-mixed-nal-coding fate-h264-xavc-4389 fate-h264-attachment-631 fate-h264-skip-nokey fate-h264-skip-nointra This was already the case pre-merge commit (true for at least one frame according to av_assert0). Signed-off-by: Matthieu Bouron --- libavcodec/h264dec.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c index 665d3e46a5..14b68c19c7 100644 --- a/libavcodec/h264dec.c +++ b/libavcodec/h264dec.c @@ -680,8 +680,17 @@ again: break; if (h->current_slice == 1) { + const H264Picture *cur = h->cur_pic_ptr; + /* FIXME: if we have two PAFF fields in one packet, we can't start + * the next thread here. If we have one field per packet, we can. + * The check in decode_nal_units() is not good enough to find this + * yet, so we assume the worst for now. */ + const int abort_frame_threading = cur && + (cur->field_poc[0] == INT_MAX || cur->field_poc[1] == INT_MAX) && + ((cur->field_poc[0] == INT_MAX && cur->field_poc[1] == INT_MAX) || + h->missing_fields <= 1); if (avctx->active_thread_type & FF_THREAD_FRAME && !h->avctx->hwaccel && - i >= nals_needed && !h->setup_finished && h->cur_pic_ptr) { + i >= nals_needed && !h->setup_finished && !abort_frame_threading) { ff_thread_finish_setup(avctx); h->setup_finished = 1; } -- 2.11.0