Home of the Squeezebox™ & Transporter® network music players.
Page 4 of 4 FirstFirst ... 234
Results 31 to 38 of 38
  1. #31
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,430

    AAC in M4A container: can it be transcoded fromremote source (http)?

    > OK Got test environment working and can play Flac formats track but when
    > I set for MP3 only - the MP4 track don't play as they are being "typed"
    > as mp3


    I must have accidentally reverted tons of changes... should be better
    now. Sorry about that.

    --

    Michael

  2. #32
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    5,826
    Hi - I was thinking about the mp4 topic during my efforts to add wav/aif remote streaming and better understand transcoding process. Currently, in my patch, the 'aif aif' and 'wav wav' are rejected ( the 'xxx - pcm' rules are used) when seeking as a header must be provided. So I was thinking about doing what File.pm does, which is creating a initialAudioBlock and stitching it to the seeked audio.

    I thought it could be useful as well for 'mp4 aac' rule as it would allow mp4 streams to be streamed & seeked without using ffmpeg. Offset must be found and the mp4 header re-calculated using Andy's Audio::Scan and that new header stitched to audio accessed with a range.

    We also have the issue of the strange mp4 file where 'moov' atom is at the end but stitching & use of initialAudioBlock would solve this as well, assuming I go the 'moov' header with a ranged-GET

    Solving two problems at once.

    What do you think?
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

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

    AAC in M4A container: can it be transcoded fromremote source (http)?

    > What do you think?

    I love the plan :-). It's code I'm not too familiar with. But LMS8 is
    young and considered under development. I'm happy to experiment with it.

    --

    Michael

  4. #34
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    18,871
    Quote Originally Posted by philippe_44 View Post
    Hi - I was thinking about the mp4 topic during my efforts to add wav/aif remote streaming and better understand transcoding process. Currently, in my patch, the 'aif aif' and 'wav wav' are rejected ( the 'xxx - pcm' rules are used) when seeking as a header must be provided. So I was thinking about doing what File.pm does, which is creating a initialAudioBlock and stitching it to the seeked audio.

    I thought it could be useful as well for 'mp4 aac' rule as it would allow mp4 streams to be streamed & seeked without using ffmpeg. Offset must be found and the mp4 header re-calculated using Andy's Audio::Scan and that new header stitched to audio accessed with a range.

    We also have the issue of the strange mp4 file where 'moov' atom is at the end but stitching & use of initialAudioBlock would solve this as well, assuming I go the 'moov' header with a ranged-GET

    Solving two problems at once.

    What do you think?
    I think it is probably a good idea. I'll have to think a bit more about how MPEG-4 podcast and HLS streams will be affected by the suggested change - ideally simplified.
    For a few years, I have shied away from considering LMS changes and tended to implement stuff in Plugins as LMS seemed to be stuck on 7.9 and users wanted backward compatibility. With external issues such as https forcing upgrades and nicely packaged Pi systems - I think users find it easier and more compelling to keep LMS up to date.

    LMS changes to support new "features" can either be done via adding APIs (e.g. registered functions or "can" functions ) or adding to core LMS. Adding MP4 header support after wav header - made me consider whether the "right" approach was a more generic API extension but I don't think so. I think what Philippe has suggested is right as in the near term there will be no more "framed" audio formats (i.e. core to LMS with header handling - pcm, aiff, wav, flac, mp3, aac, ogg, mp4 ) - just a greater variety of transports & services. I think the suggested change will support different possible audio codecs in MPEG-4 and not just AAC - just need to check whether a ParseMP4Header is needed to look at the "esds" atoms or maybe this is done within Audio::Scan.

    MPEG-4 is a big standard and updated regularly. We need to be careful about which "features" will be supported or else it may overwhelm.

    The "strange" mp4 files are not "strange" but in fact the "normal" before streaming, as the files could be created in a single pass - nice for Linux type piped processes. However they do need to be supported but the advice to users could be just to run "ffmpeg" on them and fix them up (i.e. make them streamable).

    I think the suggested approach will work for the MPEG-4 formats used in files, stream & podcasts that are common with LMS. My knowledge of MPEG4 is limited. The files/podcasts usually have a single "moov" and a single "mdat" (has the audio data) . However an MPEG4 file instead a single "'moov", can have multiple "moof" atoms which are fragments and each fragment has a "mdat" - this format is in use but I cannot say where it is prevalent. Will the suggested approach work with multiple "moof" or do we worry about that later if they appear in a service ? At the moment HLS is chunk MPEG4 - lots of separate MPEG-4 files. I worry whether synced metadata in MPEG4 - most "broadcast" providers seem to have gone a "metadata separate from audio" route but that could change.

  5. #35
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    5,826
    Quote Originally Posted by mherger View Post
    > What do you think?

    I love the plan :-). It's code I'm not too familiar with. But LMS8 is
    young and considered under development. I'm happy to experiment with it.

    --

    Michael
    Quote Originally Posted by bpa View Post
    I think it is probably a good idea. I'll have to think a bit more about how MPEG-4 podcast and HLS streams will be affected by the suggested change - ideally simplified.
    For a few years, I have shied away from considering LMS changes and tended to implement stuff in Plugins as LMS seemed to be stuck on 7.9 and users wanted backward compatibility. With external issues such as https forcing upgrades and nicely packaged Pi systems - I think users find it easier and more compelling to keep LMS up to date.

    LMS changes to support new "features" can either be done via adding APIs (e.g. registered functions or "can" functions ) or adding to core LMS. Adding MP4 header support after wav header - made me consider whether the "right" approach was a more generic API extension but I don't think so. I think what Philippe has suggested is right as in the near term there will be no more "framed" audio formats (i.e. core to LMS with header handling - pcm, aiff, wav, flac, mp3, aac, ogg, mp4 ) - just a greater variety of transports & services. I think the suggested change will support different possible audio codecs in MPEG-4 and not just AAC - just need to check whether a ParseMP4Header is needed to look at the "esds" atoms or maybe this is done within Audio::Scan.
    Great, I'll start working on that and will let you know if it looks promising; First thing I'll add the header stitching for wav and aif because it's more simple and it will let me know if the whole idea is feasable "easily".
    MPEG-4 is a big standard and updated regularly. We need to be careful about which "features" will be supported or else it may overwhelm.

    The "strange" mp4 files are not "strange" but in fact the "normal" before streaming, as the files could be created in a single pass - nice for Linux type piped processes. However they do need to be supported but the advice to users could be just to run "ffmpeg" on them and fix them up (i.e. make them streamable).
    Yes, that makes sense - not very friendly for clients but that's the way things works. Reminds me of my work on MPD. It's the usual case where the standard guys (and I know that space very well in another domain) are having a lot of fun + political motivation to be very creative finding 10 different ways to do the same things ("would it be cool if we would do this as well ...") and have no pity for the client side which then suddenly have 100's of options and no support of profiles to decide which ones to implement. Easy from a server point of view, you just chose which one to use and a disaster for clients.
    I think the suggested approach will work for the MPEG-4 formats used in files, stream & podcasts that are common with LMS. My knowledge of MPEG4 is limited. The files/podcasts usually have a single "moov" and a single "mdat" (has the audio data) . However an MPEG4 file instead a single "'moov", can have multiple "moof" atoms which are fragments and each fragment has a "mdat" - this format is in use but I cannot say where it is prevalent. Will the suggested approach work with multiple "moof" or do we worry about that later if they appear in a service ? At the moment HLS is chunk MPEG4 - lots of separate MPEG-4 files. I worry whether synced metadata in MPEG4 - most "broadcast" providers seem to have gone a "metadata separate from audio" route but that could change.
    I had to deal with multiple "moof" in the YT plugin where is used with dash-mpd and that's why I started from your HLS parser and add a couple of things for the specific YT needs, but basically the protocolhandler is responsible for file decomposition and seeking. As far as LMS is concerned, it becomes a proxied stream that spits continuously ADTS frames, there is no use of Player::Protocol::HTTP, so transcoding from AAC with 'I' can be used, but seek is never involved.
    Now, if would have to re-read again the mp4 specs to see how to deal with direct mp4 that would contain multiple 'moof' in a "header managed" context, but as you say, we could start with the 'moov' case first. Maybe I'll hit a wall anyway :-)

    The other thing that has been itchy a bit is the possibility to define multiple rules for the same 'source target' pair. I've started to look into that, but that seems complicated due to the data structure TranscodingHelper expects to get from convert.conf, unfortunately, so I parked this one for now
    Last edited by philippe_44; 2020-06-11 at 11:11.
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

  6. #36
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    18,871
    Quote Originally Posted by philippe_44 View Post
    The other thing that has been itchy a bit is the possibility to define multiple rules for the same 'source target' pair. I've started to look into that, but that seems complicated due to the data structure TranscodingHelper expects to get from convert.conf, unfortunately, so I parked this one for now
    By this I think you mean the small set of capabilities (F, I & R) for which R & F are mutually exclusive and I think "I" is only a qualifier to "F" or "R" or are there cases where for example, sometime transcoder will uses URL and sometime stdin as it might depend on the capability of the transcoder (e.g. faad vs ffmpeg) ?
    It is the area where playing games with "types" and rules to get the desired result is not the best approach where clearly it is shortcoming of the rules.

    If we do decide to change the rules and their handling, and to make sure the problem is fully understood - are there other combination (e.g. re-sampling, bit rate limiting ) where the current single rule is a problem ?

  7. #37
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    5,826
    Quote Originally Posted by bpa View Post
    By this I think you mean the small set of capabilities (F, I & R) for which R & F are mutually exclusive and I think "I" is only a qualifier to "F" or "R" or are there cases where for example, sometime transcoder will uses URL and sometime stdin as it might depend on the capability of the transcoder (e.g. faad vs ffmpeg) ?
    It is the area where playing games with "types" and rules to get the desired result is not the best approach where clearly it is shortcoming of the rules.
    Yes, that's the main use case
    If we do decide to change the rules and their handling, and to make sure the problem is fully understood - are there other combination (e.g. re-sampling, bit rate limiting ) where the current single rule is a problem ?
    I was also thinking about the way to add "cost" to rules. I mean by that it seems to me that rules are evaluated in order of player's codecs. For for example, if player says "flc,pcm" in that order in its codecs list, and we play a wav file, then flc will be evaluated first and the "wav flc" rule matches perfectly. Unfortunately, this is a CPU "expensive" rule that does "[flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ | [sox] -q -t flac - -t flac -C 0 $RESAMPLE$ -". Should we explore more codecs in the player's list, we would find a "wav pcm" that costs nothing. I'm not sure yet what's the best answer as one might argue that "wav pcm" has a high network cost, so it might not be preferred. Maybe it's a rathole, maybe it should be user choice depending on their network vs server capabilities ... I don't know
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

  8. #38
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    5,826
    Quote Originally Posted by philippe_44 View Post
    Yes, that's the main use case

    I was also thinking about the way to add "cost" to rules. I mean by that it seems to me that rules are evaluated in order of player's codecs. For for example, if player says "flc,pcm" in that order in its codecs list, and we play a wav file, then flc will be evaluated first and the "wav flc" rule matches perfectly. Unfortunately, this is a CPU "expensive" rule that does "[flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ | [sox] -q -t flac - -t flac -C 0 $RESAMPLE$ -". Should we explore more codecs in the player's list, we would find a "wav pcm" that costs nothing. I'm not sure yet what's the best answer as one might argue that "wav pcm" has a high network cost, so it might not be preferred. Maybe it's a rathole, maybe it should be user choice depending on their network vs server capabilities ... I don't know
    So ... in this patch https://github.com/Logitech/slimserver/pull/367 I've added the possibility to seek through mp4 remote stream & build headers and deal with 'moov' atoms at the end. It works with direct & proxied options, try to go direct whenever it can. I've also added an MP4 to ADTS frame builder/extractor directly in Perl as faad does not work with stdin and mp4 (only aac and stdin) - I've verified and it takes a few % of CPU on my 3B+

    This other patch https://github.com/Logitech/slimserver/pull/371 adds the possibility to have multiple rules for the same transcoding pair. So you can have a "mp4 flc" rule using faad with "F(ile)" and another "mp4 flc" using ffmpeg with "(std)I(n)". This can be used in conjunction with the previous patch. We still to decide if we prefer the ffmpeg route or the built-in mP4 to aac. Or we have to leave the option open to user.

    Limitation today is that "moof"/"traf" type of files are not supported. We might in fact combine the 2 above so that LMS re-targets the format to be 'aac' and does the ADTS extraction when finding a "moov" but let the format to be 'mp4' and leaves extraction/transcoding when reaching a "moof" (thinking out of loud here)
    Last edited by philippe_44; 2020-06-21 at 18:37.
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

Posting Permissions

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