Opened 9 years ago
Last modified 9 years ago
#4998 new enhancement
SanDisk Clip Sport/Jam is buggy, support generating "simpler" mp4 files that can be played by it.
Reported by: | bat999 | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | unspecified | Keywords: | aac mov regression |
Cc: | Michael Niedermayer | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Hi
m4a files created by FFmpeg aren't supported by SanDisk Clip Sport/Jam.
I've attached 3 files.
1 nero.m4a
This plays OK.
Created with neroAacEnc version 1.5.4.0
neroAacEnc -if foo.wav -of nero.m4a
2 FFmpeg.m4a
This doesn't play.
Created with FFmpeg ffmpeg version git-2015-10-28-cceed83
FFmpeg -i foo.wav -c:a aac -strict -2 FFmpeg.m4a
3 nero2.m4a
This doesn't play either (nero file re-muxed by FFmpeg).
ffmpeg -i nero.m4a -c copy nero2.m4a
So I think that it is not FFmpeg's aac encoder that is causing the problem, but maybe the muxing into m4a by FFmpeg.
My operating system Ubuntu-12.04.
The mp3 player is Clip Jam 8GB model number SDMX26-008G-G46K
Attachments (15)
Change History (41)
by , 9 years ago
by , 9 years ago
Attachment: | FFmpeg.m4a added |
---|
by , 9 years ago
by , 9 years ago
Attachment: | mp4creator.m4a added |
---|
comment:2 by , 9 years ago
See if this works:
ffmpeg -i foo.wav -c:a aac -strict -2 -f ipod output.m4a
comment:3 by , 9 years ago
ffmpeg -i foo.wav -c:a aac -strict -2 -f ipod output.m4a
The output file won't play on the Clip Jam :-(
by , 9 years ago
Attachment: | output.m4a added |
---|
comment:4 by , 9 years ago
Hi
I did another experiment.
I converted from wav to m4a using faac-1.28.
faac -o faac.m4a foo.wav
This file plays OK.
I've attached the file.
m4a files created by FFmpeg ffmpeg version git-2015-11-13-6f520ce don't play.
by , 9 years ago
comment:5 by , 9 years ago
Hi
I did another experiment.
I converted from wav to m4a using fdkaac 0.6.2.
fdkaac -o fdkaac.m4a --bitrate-mode 3 foo.wav
This file plays OK.
I've attached the file.
by , 9 years ago
Attachment: | fdkaac.m4a added |
---|
comment:6 by , 9 years ago
Component: | undetermined → avformat |
---|---|
Keywords: | aac mov added |
Looks like a duplicate of ticket #2809 to me.
comment:7 by , 9 years ago
Hi
Yes, maybe it's the same problem.
My Sansa Clip Jam seems to also play files that have been muxed by
MP4Box - GPAC version 0.4.6-DEV-rev.
I've attached the muxed file.
ffmpeg -i foo.wav -c:a aac -strict -2 foo.aac; MP4Box -add foo.aac -new MP4Box.m4a
by , 9 years ago
Attachment: | MP4Box.m4a added |
---|
comment:8 by , 9 years ago
Hi
I've repeated the tests.
The file created and muxed by FFmpeg won't play in my Sansa Clip Jam.
The files created by neroAacEnc, faac, fdkaac, play OK.
The files created by FFmpeg and muxed by MP4Creator and MP4Box play OK.
I've extracted the moov data from all the files with AtomicParsley.
Maybe somebody can analyze this data to help determine why the FFmpeg muxed file won't play.
The files and the moov data are inside the results.tar.xz file attached.
Programs used.
FFmpeg version git-2015-11-20-9747219
neroAacEnc version 1.5.4.0
faac version 1.28
fdkaac version 0.6.2
MP4Creator version 1.6.1d
MP4Box - GPAC version 0.4.6-DEV-rev
AtomicParsley version: 0.9.6
Commands used.
ffmpeg -i foo.wav -c:a aac -strict -2 2FFmpeg.m4a
neroAacEnc -if foo.wav -of 2nero.m4a
faac -o 2faac.m4a foo.wav
fdkaac -o 2fdkaac.m4a --bitrate-mode 3 foo.wav
ffmpeg -i foo.wav -c:a aac -strict -2 foo.aac; wine mp4creator -create=foo.aac 2mp4creator.m4a
ffmpeg -i foo.wav -c:a aac -strict -2 foo.aac; MP4Box -add foo.aac -new 2MP4Box.m4a
AtomicParsley filename.m4a -T
by , 9 years ago
Attachment: | results.tar.xz added |
---|
by , 9 years ago
Attachment: | avconv.m4a added |
---|
by , 9 years ago
Attachment: | ffmpeg.m4a added |
---|
comment:9 by , 9 years ago
Hi
I've done another experiment.
With avconv...
avconv version v12_dev0-2198-g489e6ad, Copyright (c) 2000-2015 the Libav developers
built on Dec 24 2015 16:20:43 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)
avconv -i foo.wav -strict experimental -c:a aac avconv.m4a
The file plays OK in my Sansa Clip Jam.
:-)
With FFmpeg...
ffmpeg version git-2015-12-24-4707497 Copyright (c) 2000-2015 the FFmpeg developers
ffmpeg -i foo.wav -strict experimental -c:a aac ffmpeg.m4a
The file does not play in my Sansa Clip Jam.
:-(
There must be some difference between the muxer in avconv and the muxer in FFmpeg.
I've attached the two files avconv.m4a and ffmpeg.m4a.
comment:10 by , 9 years ago
Yes, the avconv file does play OK, but that's because it's a very short clip.
Only avconv m4a files <= 40 seconds duration will play in Sansa Clip Jam.
With mp4creator muxer it will play files <= 30 minutes.
So avconv isn't the solution after all.
There are many ipod options with command "ffmpeg -h muxer=ipod".
But I don't feel inclined to plough through them blindly.
Maybe the AtomicParsley -T data from the mp4creator muxed file would indicate which ipod option to try.
comment:11 by , 9 years ago
Maybe it expects the index at the beginning of the file. Try:
ffmpeg -i foo.wav -c:a aac -strict -2 -b:a 128k -ac 2 -movflags +faststart output.m4a
comment:12 by , 9 years ago
@relaxed: both ffmpeg and avconv use faststart.
@bat999: can you try the exact following:
ffmpeg -f lavfi -i sine=d=15 -y /tmp/sine.m4a ffmpeg -i /tmp/sine.m4a -c copy -skip_iods no /tmp/ff.m4a avconv -i /tmp/sine.m4a -c copy /tmp/av.m4a
...and confirms that ff.m4a
doesn't play while av.m4a
plays?
(Rationale: I'm just trying to generate too very close files in order to study the differences)
comment:13 by , 9 years ago
Oh, and can you try to use -use_editlist no
with ffmpeg? It appears we are muxing one while avconv
doesn't.
by , 9 years ago
by , 9 years ago
follow-up: 15 comment:14 by , 9 years ago
Yes, ff.m4a doesn't play and av.m4a does play.
ffmpeg -i /tmp/sine.m4a -c copy -skip_iods no -use_editlist no /tmp/ff.m4a
avconv -i /tmp/sine.m4a -c copy /tmp/av.m4a
@relaxed: I've already tried with faststart.
comment:15 by , 9 years ago
Replying to bat999:
Yes, ff.m4a doesn't play and av.m4a does play.
ffmpeg -i /tmp/sine.m4a -c copy -skip_iods no -use_editlist no /tmp/ff.m4a
avconv -i /tmp/sine.m4a -c copy /tmp/av.m4a
Interesting. So, so far the only two remaining obvious differences I can notice are that the udta
tag is slightly different, but more importantly the stco
table is completely different:
avconv:
0000000000000000| 24 ftyp (66747970) major_brand=[M4A ] minor_version=512 0000000000000018| 8 free (66726565) 0000000000000020| 233K mdat (6D646174) 000000000003a7cb| 5K moov (6D6F6F76) 000000000003a7d3| 108 mvhd (6D766864) v=0 creat=0 edit=0 ts=1000 duration=15047 000000000003a83f| 24 iods (696F6473) 000000000003a857| 5K trak (7472616B) 000000000003a85f| 92 tkhd (746B6864) v=0 creat=0 edit=0 trackID=1 duration=15047 000000000003a8bb| 5K mdia (6D646961) 000000000003a8c3| 32 mdhd (6D646864) v=0 creat=0 edit=0 ts=44100 duration=663548 000000000003a8e3| 45 hdlr (68646C72) soun 000000000003a910| 5K minf (6D696E66) 000000000003a918| 16 smhd (736D6864) 000000000003a928| 36 dinf (64696E66) 000000000003a930| 28 dref (64726566) 000000000003a94c| 5K stbl (7374626C) 000000000003a954| 106 stsd (73747364) mp4a 000000000003a9be| 32 stts (73747473) 2 entries 000000000003a9de| 28 stsc (73747363) 1 entry 000000000003a9fa| 2K stsz (7374737A) 647 entries (size=0) 000000000003b42a| 2K stco (7374636F) 647 entries 000000000003be56| 95 udta (75647461)
ffmpeg:
0000000000000000| 24 ftyp (66747970) major_brand=[M4A ] minor_version=512 0000000000000018| 8 free (66726565) 0000000000000020| 233K mdat (6D646174) 000000000003a7cb| 3K moov (6D6F6F76) 000000000003a7d3| 108 mvhd (6D766864) v=0 creat=0 edit=0 ts=1000 duration=15047 000000000003a83f| 24 iods (696F6473) 000000000003a857| 2K trak (7472616B) 000000000003a85f| 92 tkhd (746B6864) v=0 creat=0 edit=0 trackID=1 duration=15047 000000000003a8bb| 2K mdia (6D646961) 000000000003a8c3| 32 mdhd (6D646864) v=0 creat=0 edit=0 ts=44100 duration=663548 000000000003a8e3| 45 hdlr (68646C72) soun 000000000003a910| 2K minf (6D696E66) 000000000003a918| 16 smhd (736D6864) 000000000003a928| 36 dinf (64696E66) 000000000003a930| 28 dref (64726566) 000000000003a94c| 2K stbl (7374626C) 000000000003a954| 106 stsd (73747364) mp4a 000000000003a9be| 32 stts (73747473) 2 entries 000000000003a9de| 28 stsc (73747363) 1 entry 000000000003a9fa| 2K stsz (7374737A) 647 entries (size=0) 000000000003b42a| 20 stco (7374636F) 1 entry 000000000003b43e| 98 udta (75647461)
We need to investigate why our stco contains only one entry.
comment:16 by , 9 years ago
The stco
difference might be explained by fc09bf57a60d4c4a6d339b204b3282337067c06d
If you can compare before and after this commit, that would help.
comment:17 by , 9 years ago
"If you can compare before and after this commit"
I suppose that I need to compile two old versions from git.
Not sure how to do that, or which two old versions to compile.
comment:18 by , 9 years ago
Try
git checkout fc09bf57a60d4c4a6d339b204b3282337067c06d ./configure ... make ffmpeg
Then to go back one commit earlier with git reset --hard HEAD^
, rebuild, and try again.
by , 9 years ago
by , 9 years ago
Attachment: | before.m4a added |
---|
comment:19 by , 9 years ago
OK
Compiled "after" FFmpeg.
git checkout fc09bf57a60d4c4a6d339b204b3282337067c06d
Compiled "before" FFmpeg.
git checkout 4dcd1a3145dd93602b86a44ebc07d98ca2a30ab6
Created 15 second aac file with latest FFmpeg.
ffmpeg -f lavfi -i sine=d=15 15sine.aac
Muxed it with "after" FFmpeg.
ffmpeg -i 15sine.aac -c copy -bsf:a aac_adtstoasc after.m4a
Muxed it with "before" FFmpeg.
ffmpeg -i 15sine.aac -c copy -bsf:a aac_adtstoasc before.m4a
The "after.m4a" file doesn't play, the "before.m4a" file does play OK.
Your suggestion was right.
I also tested it with longer "before" m4a files.
It will only play files of <= 41 seconds duration, but probably that is a different issue.
comment:20 by , 9 years ago
Keywords: | regression added |
---|---|
Priority: | normal → important |
OK, so we indeed have a regression since 2011 in fc09bf57a60d4c4a6d339b204b3282337067c06d. Thanks for the testing. I'm marking this ticket as important.
comment:21 by , 9 years ago
is there anything invalid in the files generated after fc09bf57a60d4c4a6d339b204b3282337067c06d or is this a bug in the device playing the files ?
comment:22 by , 9 years ago
Cc: | added |
---|
follow-up: 25 comment:23 by , 9 years ago
FWIW, I have written an ISOBMFF parser in the past and in my opinion the optimisation done with fc09bf57 is correct. I looked at after.m4a in a hex editor and both the stsc and stco atoms appear to be following the ISO 14496-12 spec. My guess is on a bug in the device.
comment:24 by , 9 years ago
comment:25 by , 9 years ago
Priority: | important → normal |
---|---|
Summary: | m4a files created by FFmpeg aren't supported by SanDisk Clip Sport/Jam. → SanDisk Clip Sport/Jam is buggy, support generating "simpler" mp4 files that can be played by it. |
Type: | defect → enhancement |
Replying to stefang:
FWIW, I have written an ISOBMFF parser in the past and in my opinion the optimisation done with fc09bf57 is correct. I looked at after.m4a in a hex editor and both the stsc and stco atoms appear to be following the ISO 14496-12 spec. My guess is on a bug in the device.
ok, adjusting title and priority
Someone should report this problem to the manufactor of the device
comment:26 by , 9 years ago
"Someone should report this problem to the manufactor of the device"
I already tried that
but got nowhere ---> http://forums.sandisk.com/t5/SanDisk-Clip-Jam/Clip-Jam-won-t-play-my-aac-m4a-files/td-p/350868
It will be difficult to design a "simpler" switch for FFmpeg's muxer because the Sansa decoder will probably be proprietary.
Unless they can be shamed into submitting a patch. rofl
Up to now, the best results I have is to use mp4creator v 1.6.1e-pre with Wine.
But even this isn't so good, my Sansa will only accept these files <= 30 minutes duration.
So I have to split long aac files with FFmpeg...
ffmpeg -i foo.aac -f segment -segment_time 1800 -c copy %02d_foo.aac
Then mux them with mp4creator...
for f in *_*.aac; do wine mp4creator -create="$f" ${f%.aac}.m4a;rm "$f"; done
Perhaps there is some option to use with mp4creator to solve this 30 minute limit. Beats me.
Maybe a "simpler" switch could be designed for FFmpeg to emulate mp4creator.
If anybody out there is interested in this I will be happy to test it.
The earlier Sansa players had problems with m4a files too.
They got around it by using Rockbox, but Rockbox won't work with the Clip Sport/Jam. :-(
@xubuntu:~$ wine mp4creator -h C:\windows\system32\mp4creator.exe: option requires an argument -- h usage: C:\windows\system32\mp4creator.exe <options> <mp4-file> Options: -aac-old-file-format Use old file format with 58 bit adts headers -aac-profile=[2|4] Force AAC to mpeg2 or mpeg4 profile -allow-avi-files Allow avi files -calcH263Bitrates Calculate and add bitrate information -create=<input-file> Create track from <input-file> input files can be of type: .263 .aac .ac3 .amr .mp3 .divx .mp4v .m4v .cmp .xvid .chap -encrypt[=<track-id>] Encrypt a track, also -E -extract=<track-id> Extract a track -delete=<track-id> Delete a track -force3GPCompliance Force making the file 3GP compliant. This disables ISMA compliance. -forceH263Profile=<profile> Force using H.263 Profile <profile> (default is 0) -forceH263Level=<level> Force using H.263 level <level> (default is 10) -H263CbrTolerance=<value> Define H.263 CBR tolerance of [value] (default: 10%) -hint[=<track-id>] Create hint track, also -H -interleave Use interleaved audio payload format, also -I -list List tracks in mp4 file -make-isma-10-compliant Insert bifs and od tracks required for some ISMA players (also -i) -mpeg4-video-profile=<level> Mpeg4 video profile override -mtu=<size> Maximum Payload size for RTP packets in hint track -optimize Optimize mp4 file layout -payload=<payload> Rtp payload type (use 3119 or mpa-robust for mp3 rfc 3119 support) -rate=<fps> Video frame rate, e.g. 30 or 29.97 -qth=<height> Set a new height for QuickTime display -qtw=<width> Set a new width for QuickTime display -timescale=<ticks> Time scale (ticks per second) -use64bits Use for large files -use64bitstime Use for 64 Bit times (not QT player compatible) -variable-frame-rate Enable variable frame rate for mpeg4 video -verbose[=[1-5]] Enable debug messages -version Display version information
Hello again.
I've done another experiment.
I converted from wav to aac using FFmpeg.
ffmpeg -i foo.wav -c:a aac -strict -2 foo.aac
Then I muxed it with MP4Creator Version 1.6.1d
mp4creator -create=foo.aac mp4creator.m4a
The result file plays OK in the Clip Jam player.
I've attached it above.
So again, I think it's not FFmpeg's aac encoder that is the problem, but it's the muxing into m4a by FFmpeg.