summaryrefslogtreecommitdiff
path: root/libavcodec/crystalhd.c
diff options
context:
space:
mode:
authorPhilip Langdale <philipl@overt.org>2016-10-15 13:30:52 -0700
committerPhilip Langdale <philipl@overt.org>2016-11-02 13:43:59 -0700
commit234d3cbf469e9feef255e229202d4b029e66e9fe (patch)
tree68385f974ff89710fa79caf6f8c4eae5fd000912 /libavcodec/crystalhd.c
parent5cb57131d3bb2422858467828a5763646f004bbe (diff)
downloadffmpeg-234d3cbf469e9feef255e229202d4b029e66e9fe.tar.gz
crystalhd: Fix up the missing first sample
Why on earth the hardware returns garbage for the first sample of a decoded picture is anyone's guess. The simplest reasonable way to patch it up is to copy the first sample of the second line. This should result in the correct chroma values (because the data was original 4:2:0 upsampled to 4:2:2) even if the luma is isn't.
Diffstat (limited to 'libavcodec/crystalhd.c')
-rw-r--r--libavcodec/crystalhd.c9
1 files changed, 9 insertions, 0 deletions
diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index 912094088a..137ed208a4 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -706,6 +706,15 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
av_log(priv->avctx, AV_LOG_VERBOSE, "CrystalHD: Copying out frame\n");
+ /*
+ * The hardware doesn't return the first sample of a picture.
+ * Ignoring why it behaves this way, it's better to copy the sample from
+ * the second line, rather than the next sample across because the chroma
+ * values should be correct (assuming the decoded video was 4:2:0, which
+ * it was).
+ */
+ *((uint32_t *)src) = *((uint32_t *)(src + sStride));
+
if (interlaced) {
int dY = 0;
int sY = 0;