Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#673 closed defect (fixed)

Regression on demuxing mp3 track from an .MOV file.

Reported by: dongwon Owned by:
Priority: important Component: avformat
Version: git-master Keywords: mov mp3 regression
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: yes

Description

When I try to play the attached sample mov file, I can see the following errors and can't hear any sound.

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x2014600]error unaligned chunk.

(This happens on ffplay >= 0.6.3 including current git while 0.5.5 works well with the sample file. Also, I've checked the file with vlc and totem players and they worked fine.)

I checked the code which emits the log and found out it fails to build an index for audio stream due to the following sanity checking code. (which is introduced between 0.5.5 and 0.6.3)

ffmpeg/avformat/mov.c

           if (sc->samples_per_frame && chunk_samples % sc->samples_per_frame) {
               av_log(mov->fc, AV_LOG_ERROR, "error unaligned chunk\n");
               return;
           }

If I read the code correctly, it is using two different units regarding "sample".
In samples_per_frame, "sample" means the uncompressed samples when we say sampling rates.
(reference: "Samples per packet" - http://developer.apple.com/library/mac/#documentation/QuickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-131395)
In chunk_samples, "sample" means a unit of media data like elementary stream.
(reference: "Samples per chunk" in 'stsc' atom, http://developer.apple.com/library/mac/#documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP40000939-CH204-25691)
So, I think modulo operation between them does not make sense.

I'm setting the priority to "important" because this is a regression.

Attachments (2)

cant_hear_sound.mov (2.2 MB) - added by dongwon 5 years ago.
the original file size was 7.8MB, but I trimmed it to 2.4MB to upload. I've checked I can still reproduce the problem.
patchticket673.diff (632 bytes) - added by cehoyos 5 years ago.

Change History (10)

Changed 5 years ago by dongwon

the original file size was 7.8MB, but I trimmed it to 2.4MB to upload. I've checked I can still reproduce the problem.

comment:1 Changed 5 years ago by cehoyos

  • Keywords mp3 regression added; mp4 removed
  • Reproduced by developer set
  • Status changed from new to open

comment:2 Changed 5 years ago by cehoyos

The file plays (badly) with QuickTime?, used to play better with FFmpeg before 7e69621f / r19018.

comment:3 Changed 5 years ago by dongwon

Thanks cehoyos for tracking this.
I've checked the full media file with QuickTime? and it played the file perfectly. To download the full media file, you may want to run the following:
$ curl -O http://dl.dropbox.com/u/50514100/avc_mp3.mov

Changed 5 years ago by cehoyos

comment:4 Changed 5 years ago by cehoyos

  • Analyzed by developer set

samples_per_frame is 2304 (which is two mp3 frames), first chunk has 11520 samples, last chunk has 5760 samples which is still dividable by the size of one mp3 frames, but not samples_per_frame.

Work-around attached.

comment:5 Changed 5 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from open to closed

Should be fixed, thank you for the sample!

comment:6 Changed 5 years ago by dongwon

Hi Carl,

Thanks for tracking this issue. I've tested your change.
Audio playback issue was gone, but I still see the following error.

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x33dac80] wrong chunk count 557

Is it okay to just ignore this error message?

Could you let me know the background of checking "chunk_samples % sc->samples_per_frame"? As far as I understand, sample in "chunk_samples" means compressed sample and sample in "sc->samples_per_frame" means uncompressed sample. So, the checking doesn't make sense to me. Am I missing something?

Thanks,

comment:7 follow-up: Changed 5 years ago by cehoyos

I believe chunk_samples contains the number of (uncompressed) samples after decoding.

comment:8 in reply to: ↑ 7 Changed 5 years ago by dongwon

As you said, chunk_samples is 11520 and 5760 in the first and second iteration respectively. The sampling rate of mp3 stream of this file is 44100Hz. If chunk_samples contains the number of (uncompressed) samples after decoding, playback duration of this file should be 11520/44100 (=0.26sec) or 5760/44100 (=0.13sec), but its actual duration is 34.7 seconds. Am I still missing something?

Note: See TracTickets for help on using tickets.