Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 2 12 LastLast
Results 1 to 10 of 12
  1. #1
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    17,906

    Making some natively unplayable MP4 files playable on Touch/Radio

    There are some MP4 file which when using standard LMS setting cannot be played on Touch /radio and result in the the following message in log
    Code:
    Slim::Player::Squeezebox2::statHandler (150) Error: 00:04:20:22:00:d9: Decoder does not support file format, code 0
    This problem has been noted by many users and the usual solution is to disable "native" playing. It has appeared often enough that I think it may warrant a proper solution.

    The root cause of the problem is the MPEG4 "mdat" (i.e. raw audio data) is saved in the MP4 file before the "moov" which contains metadata but also index into file. Transcoding works because faad can seek to the end of the file but streaming to Touch/Radio won't work as file is being streamed (i.e. audio data is sent before index to audio) .

    The Audio::Scan modules does detect this "mdat" before "moov" and returns a flag "leading_mdat".

    It is possible for LMS to put these files into a separate category (e.g. say mp4x and alcx instead of mp4 and alc) which has no native transcoding rules - so they will always be transcoded and "good" MP4 file will be played natively.

    I'm not that familiar with scanner stuff so I've probably missed some use cases but I think the code change to support this will be minimal - beside adding "mp4x" & "alcx" to convert,conf and types.conf (similar to "wmal" but no mimetype) - in Slim/Formats/Movies.pm - the following change to getTag routine is needed to save the leading_mdat tag
    Code:
    	$tags->{OFFSET}       = 0;
    	$tags->{RATE}         = $info->{samplerate};
    	$tags->{SIZE}         = $info->{file_size};
    	$tags->{SECS}         = $info->{song_length_ms} / 1000;
    	$tags->{BITRATE}      = $info->{avg_bitrate};
    	$tags->{DLNA_PROFILE} = $info->{dlna_profile} || undef;
    	$tags->{LEADING_MDAT} = $info->{leading_mdat} || undef;
    and adding the following to readTags in Slim/Formats.pm

    Code:
    	# Bug 2996 - check for multiple DISC tags.
    	if (ref($tags->{'DISC'}) eq 'ARRAY') {
    
    		$tags->{'DISC'} = $tags->{'DISC'}->[0];
    	}
    
    	if (-e $filepath) {
    		# cache the file size & date
    		($tags->{'FILESIZE'}, $tags->{'TIMESTAMP'}) = (stat(_))[7,9];
    	}
    
    
    	if ($tags->{'LEADING_MDAT'}) {
    		$type = 'mp4x';
    		$tags->{'CONTENT_TYPE'} = 'alcx' if ($tags->{'CONTENT_TYPE'} eq 'alc')
    	}
    
    	# Only set if we couldn't read it from the file.
    	$tags->{'CONTENT_TYPE'} ||= $type;

  2. #2
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    17,906
    Looks like I missed a a few other changes in Formats.pm - probably a few other places as well.

    Code:
    		'wmap' => 'Slim::Formats::WMA',
    		'wmal' => 'Slim::Formats::WMA',
    		'alc' => 'Slim::Formats::Movie',
    		'alcx' => 'Slim::Formats::Movie',
    		'aac' => 'Slim::Formats::Movie',
    		'mp4' => 'Slim::Formats::Movie',
    		'mp4x' => 'Slim::Formats::Movie', 
    		'sls' => 'Slim::Formats::Movie',
    		'shn' => 'Slim::Formats::Shorten',

  3. #3
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,323

    Making some natively unplayable MP4 files playableon Touch/Radio

    > The root cause of the problem is the MPEG4 "mdat" (i.e. raw audio data)
    > is saved in the MP4 file before the "moov" which contains metadata but
    > also index into file. Transcoding works because faad can seek to the
    > end of the file but streaming to Touch/Radio won't work as file is being
    > streamed (i.e. audio data is sent before index to audio) .


    Sounds reasonable. Could you please provide a pull request and a few
    sample files I could play around with?

    --

    Michael

  4. #4
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    17,906
    Quote Originally Posted by mherger View Post
    > the root cause of the problem is the mpeg4 "mdat" (i.e. Raw audio data)
    > is saved in the mp4 file before the "moov" which contains metadata but
    > also index into file. Transcoding works because faad can seek to the
    > end of the file but streaming to touch/radio won't work as file is being
    > streamed (i.e. Audio data is sent before index to audio) .


    sounds reasonable. Could you please provide a pull request and a few
    sample files i could play around with?
    ok.

  5. #5
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    17,906
    For completeness - Squeezelite and Squeezplay also cannot play the "problem" MP4 file natively.

    Squeezelite produces the following errors
    Code:
    [11:30:04.184784] ffmpeg: moov atom not found
    [11:30:04.184822] ff_decode:298 avformat_open_input: -1094995529 Invalid data found when processing input

  6. #6
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    17,906
    Quote Originally Posted by mherger View Post
    > The root cause of the problem is the MPEG4 "mdat" (i.e. raw audio data)
    > is saved in the MP4 file before the "moov" which contains metadata but
    > also index into file. Transcoding works because faad can seek to the
    > end of the file but streaming to Touch/Radio won't work as file is being
    > streamed (i.e. audio data is sent before index to audio) .


    Sounds reasonable. Could you please provide a pull request and a few
    sample files I could play around with?
    Pull request created (I hope it's ok as I don't use git)

    4 Sample files (alac &aac both fast and not fast) are in a zip file downloadable from here

    http://ge.tt/8TlZBAx2

  7. #7
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    402
    @bpa

    This looks as if it might resolve: Bug 17201: Playback MP4 (podcasts) with ffmpeg. http://bugs.slimdevices.com/show_bug.cgi?id=17201

    You posted some potential patches against that bug report which, I guess, would now become superfluous. Am I on the right track ?

  8. #8
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    17,906
    Quote Originally Posted by mrw View Post
    @bpa

    This looks as if it might resolve: Bug 17201: Playback MP4 (podcasts) with ffmpeg. http://bugs.slimdevices.com/show_bug.cgi?id=17201

    You posted some potential patches against that bug report which, I guess, would now become superfluous. Am I on the right track ?
    Personally I can't remember this bug nor my solution. It hasn't been incorporated into LMS and I haven't used it so it is definately a niche case.

    However, it is in an area which I am still looking to apply fixes.

    This thread relates to users having problems with playing some MPEG4 files. For Touch/Radio to play such MPEG4 aac/alac files the files must be streamable (i.e. index table before audio data). This thread is dealing with a fix to enable playing files and not streams. The fix enables LMS to detect which files need to be transcoded (i.e. the unstreamable files have leading mdat) and which streamable files can be sent as-is to Touch/Radio.

    The bug report deals with MP4 podcast (i.e. streams and not files as in this thread). Podcasts were initially expected to be downloaded and then played. This means some MP4 podcast are unstreamable (i.e. leading mdat) and they will never be streamable.

    LMS normally uses faad to decode aac/alac in MP4 and aac in ADTS streams but faad cannot handle URLs as input and currently LMS doesn't handle MP4 header which means LMS cannot act as an intermediary for streaming mP4 s the easy solution was to get ffnpeg to handle URLs directly.

    Having forgotten about the bug report but having written MPEG-4 handler in Perl for BBCiPlayer & MPEG-4 ts for PLayHLS - I am looking into creating a plugin which can handle streaming MPEG4 podcasts (i.e. audio/mp4) without ffmpeg - just relying on standard LMS (i.e. faad for older BS players)

    I think this will cover the main niche problems associated with MP4.

    There are still other things that could be sorted about LMS's handling of MPEG-4 files. For example, a two track file where first track is Video with just cover image and 2nd track is Audio - LMS will play this file through players but will not show anything on UIs not even paying controls - once started it cannot be stopped - it has to play out !

  9. #9
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    402
    Thank you very much for the explanation. I was on the wrong track ! I have never encountered this particular problem.

    I don't think I've encountered an MP4 podcast in long while, at least that I have noticed. I suppose that people have learned (by now) not to stream MP4's, etc, with leading mdat.

  10. #10
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    17,906
    Quote Originally Posted by mrw View Post
    Thank you very much for the explanation. I was on the wrong track ! I have never encountered this particular problem.

    I don't think I've encountered an MP4 podcast in long while, at least that I have noticed. I suppose that people have learned (by now) not to stream MP4's, etc, with leading mdat.
    There are many amateurs who create podcasts whose formats are not streamable - sometime the professional also make mistakes (or outsource to an unreliable contractor).

    Example of a podcast stream of MP4 podcasts - see if they play on your system.

    http://radiofrance-podcast.net/podcast09/rss_12283.xml

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •