Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 4 123 ... LastLast
Results 1 to 10 of 39
  1. #1
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    6,690

    transcoder order

    Something I've been asking a few times and I think I understand now. When multiple transcoding rules can be used (eg flc flc and flc pcm) and don't have a handicap (don't miss any of the optional attributes like START) then the first rule listed will win, whether it requires a transcoder or not. In other words, direct '-' rule don't win if the appear after.

    So if in my accepted codecs list, I have 'pcm,flc' then pcm will be selected although it requires a transcoder. Shouldn't we continue to explore rules until we have exhausted them or find a direct one?
    LMS 8.1.x on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

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

    transcoder order

    > So if in my accepted codecs list, I have 'pcm,flc' then pcm will be
    > selected although it requires a transcoder. Shouldn't we continue to
    > explore rules until we have exhausted them or find a direct one?


    Shouldn't the player report its capabilities in the order of preference,
    and this would address the problem, too?

    Trying to define an order of priority might become more work than is
    worth it. Has this been a problem in the 10+ years of its existence? Or
    would you only look for a direct streaming version?

    I'm not too familiar with the transcoding framework. How would
    custom-convert.conf be able to rule? Does it overwrite existing rules?

    --

    Michael

  3. #3
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,090
    Quote Originally Posted by philippe_44 View Post
    Something I've been asking a few times and I think I understand now. When multiple transcoding rules can be used (eg flc flc and flc pcm) and don't have a handicap (don't miss any of the optional attributes like START) then the first rule listed will win, whether it requires a transcoder or not. In other words, direct '-' rule don't win if the appear after.

    So if in my accepted codecs list, I have 'pcm,flc' then pcm will be selected although it requires a transcoder. Shouldn't we continue to explore rules until we have exhausted them or find a direct one?
    I never delved into transcoding code but my assumption( based on observation) was
    (i) all rules were evaluated to create a candidate list of applicable rules
    (ii) from list of successful rules, the direct rule was picked first.
    (ii) if no direct rules - this means transcoding pipeline is needed and choice of applicable rule was first Lossless (i.e. Flac, then PCM) and then Lossy (MP3)

    I don't know how "flc flc transcode" type rules fit into the scheme of things and I don't like that "transcode" rules are not listed in File Type as a rogue custom-type can override and it is hard to find without logging.

    If what you proposing is tackling the last bit ref the "transcode" - then I need to think a bit more.

  4. #4
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    6,690
    Quote Originally Posted by mherger View Post
    > So if in my accepted codecs list, I have 'pcm,flc' then pcm will be
    > selected although it requires a transcoder. Shouldn't we continue to
    > explore rules until we have exhausted them or find a direct one?


    Shouldn't the player report its capabilities in the order of preference,
    and this would address the problem, too?

    Trying to define an order of priority might become more work than is
    worth it. Has this been a problem in the 10+ years of its existence? Or
    would you only look for a direct streaming version?

    I'm not too familiar with the transcoding framework. How would
    custom-convert.conf be able to rule? Does it overwrite existing rules?

    --

    Michael
    AFAIK, the transcoding selection rule is the following (simplified version)

    - At startup, LMS builds a hash of all the conversion rules, by appending plugin's custom-convert, custom-convert, convert. The keys of that hash are "<in>-<out>-<model>|transcode|*-<mac>|* where <in> and <out> are codecs 3 letters and values are the capabilities (RESAMPLE, SEEK, BITRATE). There is a similar hash but with value of accepted inputs (STDIN, FILE, REMOTE)
    - When a player connects, it sends its list of supported codec codec1, codec2, ... <codecN>
    - To play a track, LMS has a lookup function that receives the <in> codec of the current track and builds an array with the following profiles, for *all* codecs in player's supported list
    Code:
    	<in>-<codec1>-<model>-<mac>
    	<in>-<codec1>-*-<mac>
    	<in>-<codec1>-*-<model>-*
    	<in>-<codec1>-*-*
    	<in>-<codec1>-transcode-* (if <codec1> = <in>
           ...
    	<in>-<codecN>-<model>-<mac>
    	<in>-<codecN>-*-<mac>
    	<in>-<codecN>-*-<model>-*
    	<in>-<codecN>-*-*
    	<in>-<codecN>-transcode-* (if <codecN> = <in>)
    - There is also an array of what are the "needs" for that track (SEEK, RESAMPLE) as well as array of possible input for that track (a file, stdin, an url)
    - There is an array of source LMS is capable of providing that track from (stdin, file, remote)
    - Then it iterates through that list and see if the conversion rules hash has a key for that list item. If it does, we verify that the conversion rule accepted inputs matches at least one source and then a metric is calculated for how many capabilities that rule can comply with. The process ends as soon as a matched rule has a metric of zero. Otherwise the rule with the smallest metric is selected.
    - The result is that we go from the most specific to the least specific profile and process the player's codec list in order
    - To answers @bpa's question that I saw after, the direct ('-') rule is not preferred (see below), it just happens to always have a metric of zero

    The issue I see that I observed a while ago (using my bridges) is the following: Let's say we play a simple file, no seek, no resample.
    - A typical convert.conf file has
    Code:
    flc pcm * *
    	# IFT:{START=--skip=%t}U:{END=--until=%v}
    	[flac] -dcs --force-raw-format --endian=little --sign=signed $START$ $END$ -- $FILE$
    flc flc * *
    	-
    wav flc * *
    	# IFT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=-r %d}E:{NOSTART=I}
    	[flac] -cs --totally-silent --compression-level-0 $START$ $END$ -- $FILE$ | [sox] -q -t flac - -t flac -C 0 $RESAMPLE$ -
    aif aif * *
    	-
    aif pcm * *
    	-
    wav wav * *
    	-
    wav pcm * *
    	-
    - if a player codec has "pcm,flc" and we play a flac file, then the "flc-pcm-*-* will match (as profile with pcm is tried first) and we'll do a flac decode, although the player supports flac directly. It's a waste of CPU and more important a waste of network BW
    - now, if we try to revert codec's order "flc,pcm" that would work when we play a flac file but as soon as we play a wav file, then the used rule will be "wav-flc-*-*" (as profile with flc is tried first) and we'll do a flac convert. Maybe this is fine, but maybe be not what the user intended and wanted pcm (native) format.

    I was of the impression that it would be better to

    1- try to avoid conversion unless required, so we should try first if there is a <in>-<in> rule
    2- try to use direct transfer (the '-' command) whenever possible

    With that, the "compromise" between the player's wish and the server/bandwidth would be: "let's use native track's format as a preference and if no match is found, let's use remaining codec in order".
    That would also help with the TIDAL/transcode question where plugin's protocol handler could indicate if it wants to force transcode, but it's not mandatory, see my patch https://github.com/Logitech/slimserver/pull/466 (it's just more logical, we would have a more consistent behavior). We could also iterate all rules no matter what (don't stop when metric = 0), keep the codec in order, but prefer a rule that has a direct option - not sure that this will change anything
    Last edited by philippe_44; 2020-12-03 at 20:29.
    LMS 8.1.x on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

  5. #5
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    6,690
    In fact, thinking about it again, there is simple option for the "native" format first: adding an option to the "File Types" settings (which is not very used anyway) that says "Prioritize native format" and when it is set, all I do is put at the top of the profiles list the input format.

    Code:
    	@supportedformats = Slim::Player::CapabilitiesHelper::supportedFormats($client);
    Re-order that list to put the "$type" codec (if exist) at the top. I would not make that player specific, just a general server option.
    LMS 8.1.x on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

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

    transcoder order

    > Re-order that list to put the "$type" codec (if exist) at the top. I
    > would not make that player specific, just a general server option.


    I'm fine with that. Or, rather than re-ordering, just "unshift" it to
    the top? Would that create duplicate entries (which wouldn't hurt much
    anyway)?

    --

    Michael

  7. #7
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    6,690
    Quote Originally Posted by mherger View Post
    > Re-order that list to put the "$type" codec (if exist) at the top. I
    > would not make that player specific, just a general server option.


    I'm fine with that. Or, rather than re-ordering, just "unshift" it to
    the top? Would that create duplicate entries (which wouldn't hurt much
    anyway)?

    --

    Michael
    Ok I’ll finish the PR tomorrow the by adding the Ui. I need a German translation for

    Prioritize Native Format
    Format Natif en Priorité
    LMS 8.1.x on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

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

    transcoder order

    > Ok I’ll finish the PR tomorrow the by adding the Ui. I need a German
    > translation for


    Please see what I have committed first. It's based on your PR, with the
    settings.

    > Prioritize Native Format
    > Format Natif en Priorité


    I'll be happy to add the French string :-)

    --

    Michael

  9. #9
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,090
    I need to read through Phillipe's answer slowly.

    The use case I want to check is the user/developer who has a custom-convert.conf .
    The custom conf would be processed after convert.conf and so its rules will be the latest.

    I want to check (I feel it is probably OK) are there any situation where PR might undo the effect of the custom conf.

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

    transcoder order

    > I want to check (I feel it is probably OK) are there any situation
    > where PR might undo the effect of the custom conf.


    Philippe suggested making this an option (I've enabled it by default).
    Users who want to override default behaviour could turn this off.

    --

    Michael

Posting Permissions

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