Bugzilla – Bug 17201
Can't stream M4A/AAC podcasts
Last modified: 2013-05-07 15:41:19 UTC
Created attachment 7262 [details] SBS Log I am running 7.6.32390 on WHS. I have a Squeezebox 3. Currently, if I try to access an m4a podcast, the Squeezebox thinks it's playing it and starts producing random crackling noise interspersed with silence. I am playing the podcasts through Mediafly, but as far as I am aware this app is just a wrapper which redirects the Squeezeserver to a file on the podcast server, so I don't think it's an issue with Mediafly. Attempting to use the podcast app to play these podcasts was even less successful in the past. A typical problematic podcast would be: http://podcast.hospitalrecords.com/H...rdsPodcast.xml It is an AAC file (with an m4a extension). I have attached a file analysis to this message. I should say that playing the podcast file locally is not problematic (faad and flac are both running and doing the transcoding). When I try to stream the file, the web interface reports that buffering goes on as it should. Then one of two things happens: either the faad process starts begins to take all the CPU time and runs for a while before quitting. During this time the SBS web interface is frozen and unfreezes when faad is gone. Or, I never see faad appear (maybe it quits immediately?) and the interface does not freeze. Either way, the playing time counter keeps running and the Squeezebox mostly produces silence, interspersed with crackles. I'm attaching a log from SBS and an analysis for the podcast file, if that is helpful.
Created attachment 7263 [details] AAC media file analysis
Following some discussion on the beta forum http://forums.slimdevices.com/showthread.php?t=87526 it turns out that the particular podcast erroneously serves its MIME type as text. However, the same problem occurs with m4a podcasts which serve the correct MIME type of audio/mp4, for example: http://media.ninjatune.net/podcast/ninja_cast_11.m4a Trying to stream this through the podcast player or as "tune in URL" either makes the SBS think it's playing it with the silence/crackling behaviour, or worse: it sometimes launches FAAD which then begins to take up 30% of CPU time while the web interface hangs until FAAD gives up.
Created attachment 7279 [details] New log file following addition to custom-convert.conf
Created attachment 7332 [details] Windows crash report for FAAD.exe
I have realised that FAAD.exe actually repeatedly *CRASHES* when I try to transcode an AAC/M4A stream off the internet (podcast, or just a URL link, BBC iPlayer somehow manages it fine). I'm attaching the crash reports that Windows Home Server offers to send to Microsoft. Hopefully they will be helpful.
Created attachment 7488 [details] Patch to Slim/Utils/Scanner/Remote.pm In its current form, an faad based solution will never be able to stream m4a/mp4 podcasts for two reason: 1. faad cannot take an URL as an input (type "F" in convert.conf) 2. if SBS streams the URL through stdin to faad (type "I" in convert.conf) - faad needs to be able to seek into the stream to handle mpeg4 headers and so it crashes as it cannot backup stdin. The changes to convert.conf will not fix these shortcoming with faad and in fact cause the crashes (i.e. faad crashes while attempting to seek stdin backwards). Attached to this post are two patches to SBS 7.7 svn 33544 files and a custom-convert.conf file. The patches enable an ffnpeg based way of streaming m4a/mp4 podcats and also being able to ffw/rew/jumpt to a time point in the stream. I haven't tested the patches & conf on OSX or Windows but I think only conf file and ffmpeg would vary according to platform so shouldn't affect a standard SBS. If the patches are applied to 7.7 - then there will be no addition or breaking of functionality as faad will still have shortcoming. If the user install ffmpeg and the custom-convert.conf file - then user will have m4a/mp4 streaming functionality. I think applying the patches to 7.7 as standard is reasonable as leaving it up to user to install ffmpeg is the same as current SBS practice wrt lame. ffmpeg is also better at handling mp4 file with other content such as video and so provide a workaround to bugs such as bug 17556. There are caveats. 1. To play m4as podcasts on Touch, native mp4 will need to be disabled. I think this will not affect AAC files and stream playback but will affect m4a/mp4 files playback. 2. Many m4a/mp4 podcast have strange MIME type associated with the context. The fixes (together with bug 17586 ) override MP3 and TXT format types if podcast has m4a/mp4 name extension. For other "standard" MIME type would need the user to add their own in custom-types.conf These patches can be applied to 7.6.* but the fix suggested in bug 17586 would need to be applied (https://bugs-archive.lyrion.org/show_bug.cgi?id=17586 ) as SBS would use "MOV" type rather than mp4.
Created attachment 7489 [details] Patch to Slim/Player/Song.pm Second part of patch to fix m4a podcast support. This patch enables seeking into transcoded streams.
Created attachment 7490 [details] Custom-convert.conf file to enable ffmpeg to do mp4 format transcoding conf file to enable ffmpeg to do transcoding including seeking into streams.
*** This bug has been confirmed by popular vote. ***
One other issue I've encountered is LMS failing to stream to SP based players directly if the content type is set to m4a instead of aac.
*** Bug 14313 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > One other issue I've encountered is LMS failing to stream to SP based > players directly if the content type is set to m4a instead of aac. Disabling transcoding MPEG4 -> AAC native resolves this for me. But that's not an option if connected directly to MySB.com. Direct cause: My SB Radio does not include 'mp4' in its list of capabilities. Despite that, the server still attempts to direct stream. (The decision made by Slim::Player::Protocols::HTTP:canDirectStream doesn't take stream format into account). Therefore the attempt fails in Slim::Player::Squeezebox2::directHeaders, as 'mp4' fails '$client->contentTypeSupported($contentType)'. Set player.streaming.direct log level to 'warning' to see a trace. Observation: If one 'fudges' the SB Radio capabilities to include 'mp4', a stream will start playing. This might be useful for MySB.com. But there still seem to be problems with pause/resume - it just doesn't resume. Attempts to seek within the track also fail. Perhaps there just shouldn't be a seek option offered. I don't know whether these are SB Radio or server issues. I tested this briefly by fudging and disabling the local transcoders. I haven't spotted the cause, and wouldn't really know where to look.
I should remark that I have applied Bryan's patches & installed his custom config file. Works well with my Debian Squeeze and a stock ffmpeg. Provided, as mentioned, that the mp4->aac direct transcoding is disabled. Media mime type being played is 'audio/mp4', with an 'm4a' file type suffix.