[FFmpeg-devel] [PATCH] apedec: add ability to check CRC

Michael Niedermayer michael at niedermayer.cc
Thu Apr 4 12:30:56 EEST 2019


On Wed, Mar 06, 2019 at 02:47:37PM +0100, Lynne wrote:
> 6 Mar 2019, 11:22 by dev at lynne.ee:
> 
> > The CRC flag is only signalled once every few minutes but CRC is still
> > always present so the patch uses the file version instead.
> > CRC on 24-bit files wants non-padded samples so skip such files.
> > Some corrupt samples may have been output before the final check
> > depending on the -max_samples setting.
> >
> v2 attached

>  apedec.c |   26 +++++++++++++++++++++++++-
>  1 file changed, 25 insertions(+), 1 deletion(-)
> c0cc550d77927ee0349094a4976f73d0ef671ff6  0001-apedec-add-ability-to-check-CRC-v2.patch
> From 68c25bb026761eacda3c276148e2beb34e8929fd Mon Sep 17 00:00:00 2001
> From: Lynne <dev at lynne.ee>
> Date: Wed, 6 Mar 2019 11:01:01 +0000
> Subject: [PATCH v2] apedec: add ability to check CRC
> 
> The CRC flag is only signalled once every few minutes but CRC is still
> always present so the patch uses the file version instead.
> CRC on 24-bit files wants non-padded samples so skip such files.
> Some corrupt samples may have been output before the final check
> depending on the -max_samples setting.
> ---
>  libavcodec/apedec.c | 26 +++++++++++++++++++++++++-
>  1 file changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
> index 15eb416ba4..a20d884606 100644
> --- a/libavcodec/apedec.c
> +++ b/libavcodec/apedec.c
> @@ -24,6 +24,7 @@
>  
>  #include "libavutil/avassert.h"
>  #include "libavutil/channel_layout.h"
> +#include "libavutil/crc.h"
>  #include "libavutil/opt.h"
>  #include "lossless_audiodsp.h"
>  #include "avcodec.h"
> @@ -147,7 +148,8 @@ typedef struct APEContext {
>      int fset;                                ///< which filter set to use (calculated from compression level)
>      int flags;                               ///< global decoder flags
>  
> -    uint32_t CRC;                            ///< frame CRC
> +    uint32_t CRC;                            ///< signalled frame CRC
> +    uint32_t CRC_state;                      ///< accumulated CRC
>      int frameflags;                          ///< frame flags
>      APEPredictor predictor;                  ///< predictor used for final reconstruction
>  
> @@ -730,6 +732,7 @@ static int init_entropy_decoder(APEContext *ctx)
>  
>      /* Read the frame flags if they exist */
>      ctx->frameflags = 0;
> +    ctx->CRC_state = UINT32_MAX;
>      if ((ctx->fileversion > 3820) && (ctx->CRC & 0x80000000)) {
>          ctx->CRC &= ~0x80000000;
>  
> @@ -1548,6 +1551,27 @@ static int ape_decode_frame(AVCodecContext *avctx, void *data,
>  
>      s->samples -= blockstodecode;
>  
> +    if ((avctx->err_recognition & AV_EF_CRCCHECK) &&

> +        (s->fileversion >= 3900) && (s->bps < 24)) {

what about file versions other than this ? do they have no crc ?

what about othet bps ?



> +        uint32_t crc = s->CRC_state;
> +        const AVCRC *crc_tab = av_crc_get_table(AV_CRC_32_IEEE_LE);
> +        for (i = 0; i < blockstodecode; i++) {
> +            for (ch = 0; ch < s->channels; ch++) {
> +                uint8_t *smp = frame->data[ch] + (i*(s->bps >> 3));
> +                crc = av_crc(crc_tab, crc, smp, s->bps >> 3);
> +            }
> +        }
> +
> +        if (!s->samples && ((~crc >> 1) ^ s->CRC)) {

> +            av_log(avctx, AV_LOG_ERROR, "CRC mismatch! Previously decoded "
> +                   "frames may have been affected as well.\n");

What is the usecase for this ?
the implementation does only check CRC for a subset of files and it could
report them at a time different from where they occur

In practice for a user, that adds some unpredictability to this information
A file may contains CRC errors but no errors would be detected
A file may contain CRC errors but they would be shown too late
A file may contain CRC errors and they are shown at the correct time


thanks

[...]


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190404/2badbce9/attachment.sig>


More information about the ffmpeg-devel mailing list