[FFmpeg-devel] avcodec/amrnbdec: fix handling of NO_DATA frames

Submitted by Paul B Mahol on Feb. 21, 2017, 9:59 a.m.

Details

Message ID 20170221095900.2635-1-onemda@gmail.com
State New
Headers show

Commit Message

Paul B Mahol Feb. 21, 2017, 9:59 a.m.
Fixes #1849.

Signed-off-by: Paul B Mahol <onemda@gmail.com>
---
 libavcodec/amrnbdec.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

Comments

Carl Eugen Hoyos Feb. 21, 2017, 10:57 a.m.
2017-02-21 10:59 GMT+01:00 Paul B Mahol <onemda@gmail.com>:
> Fixes #1849.

The patch changes output for the sample from ticket #1848, is
this intended?

Carl Eugen
Paul B Mahol Feb. 21, 2017, 11:07 a.m.
On 2/21/17, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2017-02-21 10:59 GMT+01:00 Paul B Mahol <onemda@gmail.com>:
>> Fixes #1849.
>
> The patch changes output for the sample from ticket #1848, is
> this intended?

Yes.
Carl Eugen Hoyos Feb. 21, 2017, 11:18 a.m.
2017-02-21 12:07 GMT+01:00 Paul B Mahol <onemda@gmail.com>:
> On 2/21/17, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2017-02-21 10:59 GMT+01:00 Paul B Mahol <onemda@gmail.com>:
>>> Fixes #1849.
>>
>> The patch changes output for the sample from ticket #1848, is
>> this intended?
>
> Yes.

Reference decoder output sounds very different here - more
similar without the patch applied.

Carl Eugen
Paul B Mahol Feb. 21, 2017, 11:21 a.m.
On 2/21/17, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2017-02-21 12:07 GMT+01:00 Paul B Mahol <onemda@gmail.com>:
>> On 2/21/17, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>> 2017-02-21 10:59 GMT+01:00 Paul B Mahol <onemda@gmail.com>:
>>>> Fixes #1849.
>>>
>>> The patch changes output for the sample from ticket #1848, is
>>> this intended?
>>
>> Yes.
>
> Reference decoder output sounds very different here - more
> similar without the patch applied.

Similar is not good enough.
Carl Eugen Hoyos Feb. 21, 2017, 11:22 a.m.
2017-02-21 12:21 GMT+01:00 Paul B Mahol <onemda@gmail.com>:
> On 2/21/17, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2017-02-21 12:07 GMT+01:00 Paul B Mahol <onemda@gmail.com>:
>>> On 2/21/17, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>> 2017-02-21 10:59 GMT+01:00 Paul B Mahol <onemda@gmail.com>:
>>>>> Fixes #1849.
>>>>
>>>> The patch changes output for the sample from ticket #1848, is
>>>> this intended?
>>>
>>> Yes.
>>
>> Reference decoder output sounds very different here - more
>> similar without the patch applied.
>
> Similar is not good enough.

I don't disagree I just thought that worse isn't better.

Carl Eugen
Ronald S. Bultje Feb. 21, 2017, 12:47 p.m.
Hi,

On Tue, Feb 21, 2017 at 6:22 AM, Carl Eugen Hoyos <ceffmpeg@gmail.com>
wrote:

> 2017-02-21 12:21 GMT+01:00 Paul B Mahol <onemda@gmail.com>:
> > On 2/21/17, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> >> 2017-02-21 12:07 GMT+01:00 Paul B Mahol <onemda@gmail.com>:
> >>> On 2/21/17, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> >>>> 2017-02-21 10:59 GMT+01:00 Paul B Mahol <onemda@gmail.com>:
> >>>>> Fixes #1849.
> >>>>
> >>>> The patch changes output for the sample from ticket #1848, is
> >>>> this intended?
> >>>
> >>> Yes.
> >>
> >> Reference decoder output sounds very different here - more
> >> similar without the patch applied.
> >
> > Similar is not good enough.
>
> I don't disagree I just thought that worse isn't better.


For the rest of us, this isn't helpful. What differences are you seeing?
Can you send a before/after sine wave diagram to showcase relevant
differences? Or something else that isn't just "it's better!" vs. "it's
worse" without any relevant explanation of what you're talking about.

(This is a reply to both, not just Carl.)

Ronald
Carl Eugen Hoyos Feb. 21, 2017, 1:07 p.m.
2017-02-21 13:47 GMT+01:00 Ronald S. Bultje <rsbultje@gmail.com>:

> For the rest of us, this isn't helpful. What differences are you seeing?

I don't see a difference, I hear a difference.
Since this isn't mentioned in the commit message, I was wondering
if the difference is intended.

My English language capabilities are not sufficient to explain "worse"
better but please test yourself and explain.

Carl Eugen
Ronald S. Bultje Feb. 21, 2017, 4:41 p.m.
Hi,

On Tue, Feb 21, 2017 at 8:07 AM, Carl Eugen Hoyos <ceffmpeg@gmail.com>
wrote:

> 2017-02-21 13:47 GMT+01:00 Ronald S. Bultje <rsbultje@gmail.com>:
> > For the rest of us, this isn't helpful. What differences are you seeing?
>
> I don't see a difference, I hear a difference.
>
[..]

> My English language capabilities are not sufficient to explain "worse"
> better


But you can decode the file before/after patch as well as with a reference
decoder and open the decoded files in a wave editor and visualize the
differences and show which is closer to reference, right?

Ronald
Carl Eugen Hoyos Feb. 21, 2017, 11:29 p.m.
2017-02-21 17:41 GMT+01:00 Ronald S. Bultje <rsbultje@gmail.com>:

>> My English language capabilities are not sufficient to explain "worse"
>> better
>
> But you can decode the file before/after patch as well as with a reference
> decoder and open the decoded files in a wave editor and visualize the
> differences and show which is closer to reference, right?

Sorry for the misunderstanding (you may be faster testing yourself then
understanding my apparently badly written emails):
This isn't about a difference only reproducible with some metric - playing
the file without the patch sounds very similar (but not identical) to the
reference decoder (that produces silent output), with the patch white
noise can be heard.

Carl Eugen

Patch hide | download patch | download mbox

diff --git a/libavcodec/amrnbdec.c b/libavcodec/amrnbdec.c
index ea299ac..e75df23 100644
--- a/libavcodec/amrnbdec.c
+++ b/libavcodec/amrnbdec.c
@@ -101,6 +101,7 @@  typedef struct AMRContext {
     AMRNBFrame                        frame; ///< decoded AMR parameters (lsf coefficients, codebook indexes, etc)
     uint8_t             bad_frame_indicator; ///< bad frame ? 1 : 0
     enum Mode                cur_frame_mode;
+    enum Mode               prev_frame_mode;
 
     int16_t     prev_lsf_r[LP_FILTER_ORDER]; ///< residual LSF vector from previous subframe
     double          lsp[4][LP_FILTER_ORDER]; ///< lsp vectors from current frame
@@ -188,6 +189,7 @@  static av_cold int amrnb_decode_init(AVCodecContext *avctx)
     ff_acelp_vectors_init(&p->acelpv_ctx);
     ff_celp_filter_init(&p->celpf_ctx);
     ff_celp_math_init(&p->celpm_ctx);
+    p->prev_frame_mode = NO_DATA;
 
     return 0;
 }
@@ -960,6 +962,7 @@  static int amrnb_decode_frame(AVCodecContext *avctx, void *data,
     float spare_vector[AMR_SUBFRAME_SIZE];   // extra stack space to hold result from anti-sparseness processing
     float synth_fixed_gain;                  // the fixed gain that synthesis should use
     const float *synth_fixed_vector;         // pointer to the fixed vector that synthesis should use
+    int consumed;
 
     /* get output buffer */
     frame->nb_samples = AMR_BLOCK_SIZE;
@@ -969,8 +972,14 @@  static int amrnb_decode_frame(AVCodecContext *avctx, void *data,
 
     p->cur_frame_mode = unpack_bitstream(p, buf, buf_size);
     if (p->cur_frame_mode == NO_DATA) {
-        av_log(avctx, AV_LOG_ERROR, "Corrupt bitstream\n");
-        return AVERROR_INVALIDDATA;
+        p->cur_frame_mode = p->prev_frame_mode;
+        if (p->cur_frame_mode == NO_DATA) {
+            av_log(avctx, AV_LOG_ERROR, "Corrupt bitstream\n");
+            return AVERROR_INVALIDDATA;
+        }
+        consumed = 1;
+    } else {
+        consumed = frame_sizes_nb[p->cur_frame_mode] + 1; // +7 for rounding and +8 for TOC
     }
     if (p->cur_frame_mode == MODE_DTX) {
         avpriv_report_missing_feature(avctx, "dtx mode");
@@ -1075,8 +1084,10 @@  static int amrnb_decode_frame(AVCodecContext *avctx, void *data,
 
     *got_frame_ptr = 1;
 
+    p->prev_frame_mode = p->cur_frame_mode;
+
     /* return the amount of bytes consumed if everything was OK */
-    return frame_sizes_nb[p->cur_frame_mode] + 1; // +7 for rounding and +8 for TOC
+    return consumed;
 }