| Message ID | 20170221095900.2635-1-onemda@gmail.com |
|---|---|
| State | New |
| Headers | show |
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
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.
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
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.
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
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
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
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
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
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; }
Fixes #1849. Signed-off-by: Paul B Mahol <onemda@gmail.com> --- libavcodec/amrnbdec.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)