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.