RepoMirrors/ffmpeg
1
0
Fork 0
mirror of https://git.ffmpeg.org/ffmpeg.git synced 2025-02-04 05:43:16 +00:00
Code Issues Projects Releases Wiki Activity

crystalhd: Remove trust_interlaced heuristic

Browse Source 
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.
This commit is contained in:
Philip Langdale 2016-10-09 20:54:27 -07:00
parent 6cc390dd5a
commit badce88fdf
1 changed files with 4 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
libavcodec/crystalhd.c
View File

@ -561,7 +561,6 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
{ {
BC_STATUS ret; BC_STATUS ret;
BC_DTS_STATUS decoder_status = { 0, }; BC_DTS_STATUS decoder_status = { 0, };
uint8_t trust_interlaced;
uint8_t interlaced; uint8_t interlaced;
CHDContext *priv = avctx->priv_data; 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 * If we got a false negative for interlaced on the first field,
* 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,
* we will realise our mistake here when we see that the picture number is that * 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 * of the previous picture. We cannot recover the frame and should discard the
* second field to keep the correct number of output frames. * second field to keep the correct number of output frames.
@ -645,16 +622,10 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
return RET_OK; return RET_OK;
} }
interlaced = (output->PicInfo.flags & VDEC_FLAG_INTERLACED_SRC) && interlaced = output->PicInfo.flags & VDEC_FLAG_INTERLACED_SRC;
trust_interlaced;
if (!trust_interlaced && (decoder_status.picNumFlags & ~0x40000000) == 0) { av_log(avctx, AV_LOG_VERBOSE, "Interlaced state: %d\n",
av_log(avctx, AV_LOG_VERBOSE, interlaced);
"Next picture number unknown. Assuming progressive frame.\n");
}
av_log(avctx, AV_LOG_VERBOSE, "Interlaced state: %d | trust_interlaced %d\n",
interlaced, trust_interlaced);
if (priv->pic->data[0] && !priv->need_second_field) if (priv->pic->data[0] && !priv->need_second_field)
av_frame_unref(priv->pic); av_frame_unref(priv->pic);