[FFmpeg-devel] [PATCH] CrystalHD decoder support v2
Wed Dec 29 09:42:21 CET 2010
Philip Langdale wrote:
> + /*
> + * Despite being notionally opaque, either libcrystalhd or
> + * the hardware itself will mangle pts values that are too
> + * small or too large. The docs claim it should be in uints
> + * of 100ns. Given that we're nominally dealing with a black
> + * box on both sides, any transform we do has no guarantee of
> + * avoiding mangling but, empirically, scalling as if the
> + * reorded_opaque value is in ms seems to work.
> + */
> + uint64_t pts = avctx->reordered_opaque == AV_NOPTS_VALUE ?
> + 0 : avctx->reordered_opaque * 1000 * 100;
> + av_log(priv->avctx, AV_LOG_VERBOSE, "input \"pts\": %lu\n",
> + avctx->reordered_opaque);
this still look wrong to me, the value of "reordered_opaque" can be *anything*
It is true that it is used to transport a timestamp by e.g. ffmpeg or ffplay,
but you cannot assume that it will always be the case. The application will
expect this value to be returned reordered but not modified.
More information about the ffmpeg-devel