Probable Mp3 encoding/muxing error

[koda]

Please describe the problem in as much detail as possible:
Encoding an MP4 file containing H264 and MP3 results in a file with situational broken audio:
- Quicktime will not play audio
- avplay/ffplay will not play at all
- Firefox and Chrome will play fine
This leads me to think that there were some errors in the muxing step.

What are the steps to reproduce this problem:
Open a file, set Audio codec to MP3, press Encode, then try to open the result with the above software.

What version of HandBrake you are running:
0.10.2

What operating system and version and you running (e.g. OSX 10.11, Windows 7, Ubuntu 14):
OSX 10.9.5

If there was any exception or error displayed, please copy it and paste it here:
No error from Handbrake itself, but ffplay/avplay will report "Header missing" on the mp3 stream.
If you try to demux it with ffmpeg/avconv and stremcopy the mp3, you will get several "Audio packet of size 960 (starting with 009BBEFC...) is invalid, writing it anyway." messages.

Please include the scan or encode log:
Sample file https://www.dropbox.com/s/nue55vybs3lnh ... b.mp4?dl=0

[rollin_eng]

Could you please post your logs, instructions can be found here:

viewtopic.php?f=6&t=31236

[koda]

Here http://pastebin.com/QErdaXXP

[mduell]

Try the nightly.

[koda]

related ffmpeg/libav bugs
https://bugzilla.libav.org/show_bug.cgi?id=899
https://trac.ffmpeg.org/ticket/4938#ticket

happens also on the nightly

[rollin_eng]

Your frame rate is very high, it is not compatible with the level you have chosen.

Try changing level and/or frame rate.

[JohnAStebbins]

FYI, the problem is that avplay/ffplay require that each packet start on an mp3 frame header. vlc, mpv, firefox, and chrome do not assume this and work just fine. QT may be the same issue, or not, I don't have it available to test with.

I've created a PR for HandBrake that ensures that every packet starts on an mp3 frame header. It actually simplifies code by using the libav mp3lame wrapper to do encoding. https://github.com/HandBrake/HandBrake/pull/22

[Deleted User 13735]

For the most compatibility with all players, use AAC audio with mp4.

[Ritsuka]

QuickTime doesn't support MP3 in the MP4 container. MP4 de facto formats are H.264 and AAC, if you want compatibility you should stick to these two.

[koda]

@JohnAStebbins I can test a sample with QT if you send one to me

[JohnAStebbins]

@JohnAStebbins I can test a sample with QT if you send one to me

As Ritsuka said, I'm pretty sure QT flat out doesn't support mp3 in mp4. It might work if you have Perian installed.

But here's a sample encoded with the patch to ensure that stream packets are full mp3 frames.
https://john.stebbins.name/owncloud/pub ... 50d1b8c0f4

[koda]

yeah QT does not play the audio part

VLC, Chrome and {av,ff}play play it fine,

however this time firefox stutters when playing audio

[JohnAStebbins]

however this time firefox stutters when playing audio

Are you sure that's not just a buffering issue?
Aside from having to download the entire file first, firefox plays the file just fine for me. Fedora 22 Firefox 41.0.1.
If I use the Epiphany browser instead, I get stutters, but it's definitely buffering.

Or maybe it has something to do with the fact that I didn't create the file with "faststart" enabled. So the moov atom is at the end of the file. I've replaced the file with one that has the moov at the front of the file.
https://john.stebbins.name/owncloud/pub ... 8ad72add01

[arcuser]

For the most compatibility with all players, use AAC audio with mp4.

Didn't work for me with HE FDK AAC, as per my other bug report from a week or so ago. Something up with it.

[koda]

I don't know if that's a buffering issue, I'm playing it locally so i doubt it?
Unfortunately also the second sample plays with stutters... could be an OSX thing then