[FFmpeg-devel] [PATCH 04/10] crystalhd: Remove trust_interlaced heuristic

Philip Langdale philipl at overt.org
Wed Oct 26 22:40:22 EEST 2016


It seems that without all the other 1:1 heuristics, we don't have
a fundamental problem trusting the interlaced flag on output
pictures. That's a relief.

Signed-off-by: Philip Langdale <philipl at overt.org>
---
 libavcodec/crystalhd.c | 37 ++++---------------------------------
 1 file changed, 4 insertions(+), 33 deletions(-)

diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index c1ca066..d738ddb 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -561,7 +561,6 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
 {
     BC_STATUS ret;
     BC_DTS_STATUS decoder_status = { 0, };
-    uint8_t trust_interlaced;
     uint8_t interlaced;
 
     CHDContext *priv = avctx->priv_data;
@@ -611,29 +610,7 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
     }
 
     /*
-     * For most content, we can trust the interlaced flag returned
-     * by the hardware, but sometimes we can't. These are the
-     * conditions under which we can trust the flag:
-     *
-     * 1) It's not h.264 content
-     * 2) The UNKNOWN_SRC flag is not set
-     * 3) We know we're expecting a second field
-     * 4) The hardware reports this picture and the next picture
-     *    have the same picture number.
-     *
-     * Note that there can still be interlaced content that will
-     * fail this check, if the hardware hasn't decoded the next
-     * picture or if there is a corruption in the stream. (In either
-     * case a 0 will be returned for the next picture number)
-     */
-    trust_interlaced = avctx->codec->id != AV_CODEC_ID_H264 ||
-                       !(output->PicInfo.flags & VDEC_FLAG_UNKNOWN_SRC) ||
-                       priv->need_second_field ||
-                       (decoder_status.picNumFlags & ~0x40000000) ==
-                       output->PicInfo.picture_number;
-
-    /*
-     * If we got a false negative for trust_interlaced on the first field,
+     * If we got a false negative for interlaced on the first field,
      * we will realise our mistake here when we see that the picture number is that
      * of the previous picture. We cannot recover the frame and should discard the
      * second field to keep the correct number of output frames.
@@ -645,16 +622,10 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
         return RET_OK;
     }
 
-    interlaced = (output->PicInfo.flags & VDEC_FLAG_INTERLACED_SRC) &&
-                 trust_interlaced;
-
-    if (!trust_interlaced && (decoder_status.picNumFlags & ~0x40000000) == 0) {
-        av_log(avctx, AV_LOG_VERBOSE,
-               "Next picture number unknown. Assuming progressive frame.\n");
-    }
+    interlaced = output->PicInfo.flags & VDEC_FLAG_INTERLACED_SRC;
 
-    av_log(avctx, AV_LOG_VERBOSE, "Interlaced state: %d | trust_interlaced %d\n",
-           interlaced, trust_interlaced);
+    av_log(avctx, AV_LOG_VERBOSE, "Interlaced state: %d\n",
+           interlaced);
 
     if (priv->pic->data[0] && !priv->need_second_field)
         av_frame_unref(priv->pic);
-- 
2.9.3


More information about the ffmpeg-devel mailing list