[FFmpeg-devel] [PATCH 1/1] CrystalHD decoder support v7

Michael Niedermayer michaelni
Thu Mar 10 20:48:43 CET 2011


On Wed, Mar 09, 2011 at 10:09:00PM -0800, Philip Langdale wrote:
> The Broadcom CrystalHD decoder chips provide hardware video
> decoding for a number of video formats. It does so using a
> memory:memory interface where a compressed bitstream is fed
> in and decompressed pictures are copied out. As such, it works
> independent of any graphics hardware in the system.
> 
> Features supported in this initial version:
> * Support for Linux (using current drivers/library from git.wilsonet.com)
> * Support for 70015 hardware
> * Formats: MPEG2, MPEG4 Part 2, H.264, VC1 and DivX 3.11 (untested)
> * Progressive content
> * Non-H.264 Interlaced content
> * H.264 MBAFF content
> 
> Features missing in this initial version:
> * Support for OSX (might work - untested)
> * Support for Windows
> * Support for 70012 hardware
> * H.264 PAFF content
> 
> Signed-off-by: Philip Langdale <philipl at overt.org>
> ---
>  MAINTAINERS            |    1 +
>  configure              |   10 +
>  libavcodec/Makefile    |    1 +
>  libavcodec/allcodecs.c |    6 +
>  libavcodec/crystalhd.c |  960 ++++++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 978 insertions(+), 0 deletions(-)
>  create mode 100644 libavcodec/crystalhd.c

applied & pushed

some ideas for future work below

[...]
[...]

> +
> +/* Timeout parameter passed to DtsProcOutput() in us */
> +#define OUTPUT_PROC_TIMEOUT 50
> +/* Step between fake timestamps passed to hardware in units of 100ns */
> +#define TIMESTAMP_UNIT 100000
> +/* Initial value in us of the wait in decode() */
> +#define BASE_WAIT 10000
> +/* Increment in us to adjust wait in decode() */
> +#define WAIT_UNIT 1000

comments could be made doxygen compatible

[...]
> +
> +/*****************************************************************************
> + * OpaqueList functions
> + ****************************************************************************/
> +
> +static uint64_t opaque_list_push(CHDContext *priv, uint64_t reordered_opaque)
> +{
> +    OpaqueList *newNode = av_mallocz(sizeof (OpaqueList));
> +    if (!newNode) {
> +        av_log(priv->avctx, AV_LOG_ERROR,
> +               "Unable to allocate new node in OpaqueList.\n");
> +        return 0;
> +    }
> +    if (!priv->head) {
> +        newNode->fake_timestamp = TIMESTAMP_UNIT;
> +        priv->head              = newNode;
> +    } else {
> +        newNode->fake_timestamp = priv->tail->fake_timestamp + TIMESTAMP_UNIT;
> +        priv->tail->next        = newNode;
> +    }
> +    priv->tail = newNode;
> +    newNode->reordered_opaque = reordered_opaque;
> +
> +    return newNode->fake_timestamp;
> +}
> +
> +/*
> + * The OpaqueList is built in decode order, while elements will be removed
> + * in presentation order. If frames are reordered, this means we must be
> + * able to remove elements that are not the first element.
> + */
> +static uint64_t opaque_list_pop(CHDContext *priv, uint64_t fake_timestamp)
> +{
> +    OpaqueList *node = priv->head;
> +
> +    if (!priv->head) {
> +        av_log(priv->avctx, AV_LOG_ERROR,
> +               "CrystalHD: Attempted to query non-existent timestamps.\n");
> +        return AV_NOPTS_VALUE;
> +    }
> +
> +    /*
> +     * The first element is special-cased because we have to manipulate
> +     * the head pointer rather than the previous element in the list.
> +     */

Its normally possible to simplify link list code by using a pointer to where
the pointer is stored (aka &priv->head)

also an array might be simpler than a linked list.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110310/f92e901e/attachment.pgp>



More information about the ffmpeg-devel mailing list