[FFmpeg-devel] Patch: CrystalHD decoder support

[Philip Langdale]

On Tue, 28 Dec 2010 11:50:07 +0100
Vladimir Pantelic <vladoman at gmail.com> wrote:

> Philip Langdale wrote:
> 
> > * I still can only get avi/wmv containered content to sync
> > correctly if I force lavf from mplayer, as opposed to native
> > demuxers - even with -nocorrect-pts.
> 
> so you do not handle reordering?

It's handled internally but that's orthogonal in the case of mplayer,
where vd_ffmpeg does not use avpkt->pts or reordered_opaque at all, so
there's never any useful timing or ordering information coming in.
Honestly, I'm not sure how it works at all. :-P

> > +static int decode(AVCodecContext *avctx, void *data, int
> > *data_size, AVPacket *avpkt) +{
> > +    BC_STATUS ret;
> > +    BC_DTS_STATUS decoder_status;
> > +    CHDContext *priv = avctx->priv_data;
> > +    HANDLE dev = priv->dev;
> > +    uint8_t input_full = 0;
> > +    int len = avpkt->size;
> > +    int rec_ret;
> > +
> > +    av_log(avctx, AV_LOG_VERBOSE, "CrystalHD: decode_frame\n");
> > +
> > +    do {
> > +        if (len) {
> > +            int32_t tx_free = (int32_t)DtsTxFreeSize(dev);
> > +            if (len<  tx_free - 1024) {
> > +                uint64_t pts = avpkt->pts == AV_NOPTS_VALUE ? 0 :
> > avpkt->pts;
> > +                ret = DtsProcInput(dev, avpkt->data, len, pts, 0);
> 
> there is a pts going into the decoder, but where does it get back
> out? I guess there is internal reordering for B frames, how is this
> handled?
> 
> your decoder should handle avctx->reordered_opaque

Thanks for pointing that out, but the results are uneven. In testing
with ffplay, avpkt->pts never contains anything useful (and maybe that's
to be expected) and for an mkv container, I get useful values in
reordered_opaque and if I pass them through the decoder, they come out
the other end intact and prove that reordering is taking place. And,
indeed, I now get properly sync'ed video in ffplay when I didn't before
(although is there a problem where it takes 10+ seconds to reach a
correct steady state). On the other hand, I tried an xvid avi and here,
only ever other frame has a meaningful reordered_opaque value, and they
are clearly not real timestamps (they appear to be frame counts and
increase by two each time), and the av sync is still a complete mess.
So, there's clearly something important still missing.

THanks,

--phil