Bug 663 - Provide facility to set lame transcoding quality setting
: Provide facility to set lame transcoding quality setting
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Audio
: 5.x or older
: PC Linux (other)
: P2 enhancement (vote)
: ---
Assigned To: KDF
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-16 15:01 UTC by Stuart Hickinbottom
Modified: 2011-03-16 04:39 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments
lame quality in player settings, audio (8.95 KB, patch)
2004-11-17 10:29 UTC, KDF
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stuart Hickinbottom 2004-11-16 15:01:53 UTC
I run SlimServer on a relatively low-spec silent 500MHz x86 platform, on which
it runs well and I'm generally very happy.

When remote streaming over my ADSL uplink to work, however, lame is obviously
used to transcode to an acceptable bitrate. This works very well.

However, due to the limited power of my machine it has trouble keeping up with
the required bitrate, and occasionally I get stalls in the stream.

I've established this is because lame can't transcode fast enough in real-time.

Experimentation shows that setting the quality via '-q 9' on appropriate lame
lines lowers the overhead enough that it can easily keep up with enough for
listening via headphones at work.

To support this I have manually edited convert.conf to add '-q 9' to each lame
command, and I have modified my nightly update script to manually apply these
changes for new builds. I understand that I can instead put entries in
slimserver-convert.conf, but I would end up adding entries that pretty much
duplicated the whole contents of convert.conf as lame is mentioned in most places.

What I would like is a player-specific setting that can specify the lame quality
setting that would be used. That way, I could enter '9' for my work player and
leave it at the default for other players.

Alternatively, general-purpose "extra lame parameters" player setting would work
(I could enter "-q 9"), but this kind of explit command-line editing is usually
considered a security-risk and so may not be desirable.

Anyway, I hope you can consider this as a possible enhancement for future
versions. I'm very happy and can continue to use it very well by patching the
convert.conf file myself, but I would expect that I'm not the only person in
this situation (especially with the apparent growth of SlimServer on Link
Stations and similar puny machines).

Thanks for your time, and keep up the good work - lots of people appreciate it,
Stuart
Comment 1 KDF 2004-11-17 10:29:29 UTC
Created attachment 201 [details]
lame quality in player settings, audio

this adds the ability for a setting which appears only if the lame binary is
sucessfully found.  The setting defaults to 9 (which is the current hardcoded
value) and allows each player to have a configured quality level.
Comment 2 Stuart Hickinbottom 2004-11-17 15:11:46 UTC
That was quick!

That patch works very well indeed for me. I applied it to a 17/11 nightly
(although I had to manually apply the convert.conf patch as mine didn't have
'ape' support, I don't think), and it applied well.

I've checked the operation and it does allow me to control the quality setting
in addition to the bitrate, which is splendid and exactly what I was after.

I've not extensively tested things like whether the settings really are
per-player and whether the setting only appears when LAME is installed, but it
certainly works in the way I'm using it.

Again, many thanks.
Comment 3 KDF 2004-11-17 15:33:01 UTC
its often quick when the framework is already there.  sorry about the stuff. 
that's overhang from another feature ehancement. This will still need approval
before it will make it into a nightly build. will mark this as fixed once its in
cvs.
Comment 4 KDF 2004-11-18 20:07:44 UTC
committed to cvs 18/11/04
Comment 5 Chris Owens 2006-06-16 14:42:27 UTC
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006.  I am setting them to targets of 6.2.1 to keep them from showing up in my queries.
Comment 6 Stuart Hickinbottom 2006-06-16 14:47:58 UTC
Yes, I believe this can now be closed. Is that something you'd prefer me to do as the originator of the report?
Comment 7 Chris Owens 2008-12-18 11:53:17 UTC
Routine bug db maintenance; removing old versions which cause confusion.  I apologize for the inconvenience.