You are here: Home » Topic » allow ssc-ffmpeg to respect ssc_codectypes

allow ssc-ffmpeg to respect ssc_codectypes

This topic contains 3 replies, has 1 voice, and was last updated by  rpedde 13 years, 1 month ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #715

    joshk

    http://triplehelix.org/~joshk/ssc-ffmpeg.diff

    Here is a crude patch that allows ssc-ffmpeg to respect ssc_codectypes and only allow codectype strings that are a subset of “flac,alac,ogg,wma” (as I understand it these are the only formats that ssc-ffmpeg supports.)

    I think it is not well documented that this restriction is hardcoded in and I received this Debian bug for it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394082

    A better long term solution would be for this to get handled on the plugin management side, where all the plugins announce what formats they support, and have mt-daapd itself do this work.

    #7001

    rpedde
    Participant

    @joshk wrote:

    http://triplehelix.org/~joshk/ssc-ffmpeg.diff

    Here is a crude patch that allows ssc-ffmpeg to respect ssc_codectypes and only allow codectype strings that are a subset of “flac,alac,ogg,wma” (as I understand it these are the only formats that ssc-ffmpeg supports.)

    I think it is not well documented that this restriction is hardcoded in and I received this Debian bug for it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394082

    A better long term solution would be for this to get handled on the plugin management side, where all the plugins announce what formats they support, and have mt-daapd itself do this work.

    I get what you are doing here, but the ssc_codectypes is to tell the server what the ssc_script transcoder will transcode. The codec types set in the plugins are to tell the server what conversions it *can* do, and the server should choose to use them based on whether or not it thinks that the client should be transcoded to (plugin_ssc_should_transcode).

    In an ideal world, it would know to transcode flac to itunes, but not rhythmbox, etc. Several problems with that, though… one being that some clients don’t give a real user-agent, they say they are iTunes. Another problem is that what codecs the client will accept natively vary depending on what plugins the client has loaded.

    I accept a header called accept-codecs that lists the codecs the client will natively play, but only the soundbridge sends it.

    Probably could make a “never_transcode” configure option or something.

    That might be the best. Still going to have problems with mixed clients, though. No real way to avoid that, I don’t think.

    BTW — you are the debian maintainer? Anything I can do to help? I’ve taken the debian folder out of the source tarball, which I’ve been meaning to do for a long time.

    I assume you stripped the mdns stuff out? If macosforge would come back up, I’d update the mdns to the bsd licenced stuff, but it’s been down for something like the last month.

    I need to get a native avahi module, too.

    Anyway, if there is something I could do to make your job easier, let me know. You can email me at [email protected].

    — Ron

    #7002

    joshk

    @rpedde wrote:

    I get what you are doing here, but the ssc_codectypes is to tell the server what the ssc_script transcoder will transcode. The codec types set in the plugins are to tell the server what conversions it *can* do, and the server should choose to use them based on whether or not it thinks that the client should be transcoded to (plugin_ssc_should_transcode).

    Okay. Maybe the option should be renamed, and/or the help for it in the sample configuration file amended. I too misunderstood the purpose of the option. The current one doesn’t note that ssc_codectypes is only relevant to ssc-script. Perhaps there should be a special config section for plugin configuration?

    Probably could make a “never_transcode” configure option or something.

    I like this.

    That might be the best. Still going to have problems with mixed clients, though. No real way to avoid that, I don’t think.

    Yes, I think the submitter of the Debian bug ultimately wanted to do (he wanted to stream to amarok.)

    BTW — you are the debian maintainer? Anything I can do to help? I’ve taken the debian folder out of the source tarball, which I’ve been meaning to do for a long time.

    Yup. I could’ve sworn I sent you an email about it, but it must have gotten lost in the sea of bits..

    I assume you stripped the mdns stuff out? If macosforge would come back up, I’d update the mdns to the bsd licenced stuff, but it’s been down for something like the last month.

    I need to get a native avahi module, too.

    Yes. The debian build uses avahi’s howl compatibility layer.

    Thanks for your detailed reply 🙂

    #7003

    rpedde
    Participant

    Probably could make a “never_transcode” configure option or something.

    general/never_transcode is now a comma separated list of codectypes (not extensions) to NOT transcode, no matter whether there are plugins loaded to handle it.

    Changeset is here, or will be when svn syncs. Should merge relatively painlessly to r1379, although line offsets might be outside fuzz limits in plugin.c.

    — Ron

Viewing 4 posts - 1 through 4 (of 4 total)

The forum ‘Feature Requests’ is closed to new topics and replies.