Opened 8 years ago

Closed 2 years ago

#1849 closed defect (needs_more_info)

AMR NB NODATA header changes following data

Reported by: krisha Owned by:
Priority: normal Component: avcodec
Version: unspecified Keywords: amrnb
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Summary of the bug:

If you put 0x7C as header (MODE = NO_DATA) the following frames behaves weird (only header, no data bytes). In Audacity with FFmpeg v0.6.2 you hear a 'knock' and the following signal wave behaves different on zooming levels and (this might be also GUI audacity bug). In VLC 2.0.3 this 'knock' is also heard.

I attached a sample file with silence and a NO_DATA frame at file offset 0x166.

I'm not sure which versions of FFmpeg are affected, but I assume all that use the codec from libavcodec/amrnbdec.c

Attachments (1)

silence and NO_DATA.amr (1.6 KB) - added by krisha 8 years ago.

Download all attachments as: .zip

Change History (6)

Changed 8 years ago by krisha

comment:1 Changed 8 years ago by krisha

  • Summary changed from AMR NB NODATA changes to AMR NB NODATA header changes following data

comment:2 Changed 8 years ago by cehoyos

  • Keywords amrnb added

Please provide complete, uncut console output (including command line) of "ffmpeg -i input out.wav" (Please test current git head).

comment:3 Changed 8 years ago by krisha

Sorry, I just used VLC and Audacity. Output on the VLC console:

[amr @ 03ff7a60] Estimating duration from bitrate, this may be inaccurate
[amrnb @ 050b3ea0] Corrupt bitstream

If someone wants to fix it, I can compile ffmpeg and run the command. For me it's effort of some hours todo - for a developer wanting to fix it, it is just a minute (he has probably latest git head and complete environment set up already).

But to understand the bug these two lines of VLC output should be enough. Anyway more important is the waveform after, than the output.

The "Corrupt bitstream" output I think is also not right. Because Mode 15 is NO_DATA and not an invalid mode.

comment:4 Changed 8 years ago by cehoyos

The sample plays fine here (no knock), so without you describing what fails (ideally by using "ffmpeg -i input out.wav" and explaining what is wrong about out.wav) it is very unlikely that this gets fixed.

Or is the only problem you see the (possibly incorrect) error message about NO_DATA?

comment:5 Changed 2 years ago by cehoyos

  • Resolution set to needs_more_info
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.