Remove liblame as a mandatory build requirement

[Stuart Auchterlonie]

liblame is only used by the backend for framegrabber cards which are becoming rare these day.

Change liblame from mandatory to optional and disable the framegrabber support if it's not found.

[Stuart Auchterlonie]

Other possible users of LAME

• frontend for encoding mp3's
• mythtranscode ???

[Karl Egly]

According to ​http://code.mythtv.org/cgit/mythtv/tree/mythtv/programs/mythtranscode/transcode.cpp#n453 the wiki on the HLS server is outdated and we already, although statically, have codec selection similar to the suggestions at ​https://developer.apple.com/library/IOS/technotes/tn2224/_index.html and ​https://trac.ffmpeg.org/wiki/GuidelinesHighQualityAudio

[dreamcat4 <dreamcat4@…>]

still in master branch:

​https://github.com/MythTV/mythtv/blob/master/mythtv/configure#L6020-L6022

[dreamcat4 <dreamcat4@…>]

This is an issue for FreeBSD users, since on FreeBSD platform LAME is marked as 'restricted'. Which means there is no binary pkg for LAME.

[12:29] < dreamcat4> stuarta: the problem is that LAME is restricted, so can't be distributed as a pkg [12:30] < dreamcat4> stuarta: which in turn means mythtv isn't installable as a binary pkg either [12:30] < dreamcat4> as mythtv pkg is built with lame as default option (default dependancy) [12:30] < stuarta> yep, if it'll build without it, you lose transcoding and ability to record from framegrabber cards (that is no loss tho) [12:31] < dreamcat4> stuarta: i guessed that. it isn't really important enough to warrant being excluded from pkgs [12:31] < stuarta> we have a ticket open somewhere to make it an optional dependency [12:31] < stuarta> it's not optional atm iirc [12:32] < dreamcat4> stuarta: do you mean to make it optional in freebsd port Makefile, or in mythtv srcs itself ? [12:32] < stuarta> src [12:32] < stuarta> if you don't have it installed, the configure error's out [12:33] < dreamcat4> right ok, so that's a problem for FreeBSD users who want an easy install (from binary pkgs)

[paulh]

Don't forget MythMusic also uses lame to encode tracks to mp3.

Lets not have a knee-jerk reaction to satisfy a few FreeBSD users but end up crippling Myth for everyone else.

[dreamcat4 <dreamcat4@…>]

Replying to paulh:

Lets not have a knee-jerk reaction to satisfy a few FreeBSD users but end up crippling Myth for everyone else.

Pehaps you meant to say "un-crippling" it.

Because "can build myth without lame" does not mean the same thing as "must build myth without lame". Currently myth can't build without lame. And that in turn causes some technical problem in regards to FreeBSD's pkg management system.

Of course other people involved with MythTV project may already hope to get rid of lame completely for various other reasons. But that is nothing to do with the FreeBSD user group.

[Raymond Wagner]

Where MythMusic uses LAME, does it do it directly, or does it use the existing audio encoding mechanisms in MythTV core? If the former, it would mean MythMusic (or MythTV Plugins depending on how things are broken up) would not be able to be distributed as a binary, but MythTV core would be.

[JYA]

I looked into this issue.

At this stage removing liblame isn't an option. liblame is required for all analog capture cards as well as for mythtranscode.

removing liblame compulsory requirements isn't a simple matter.

now if you want to provide a patch and in particular fully rewrite mythtranscode so it uses mkv as based container... that would be most appreciated.

[anonymous@…]

Replying to dreamcat4 <dreamcat4@…>:

This is an issue for FreeBSD users, since on FreeBSD platform LAME is marked as 'restricted'. Which means there is no binary pkg for LAME.

I would have expected that a MythTV distribution would need to be marked restricted and not distributed as a binary too due to codec patent encumbrances. While FFmpeg can be compiled without any patented codecs as I remember, I do not think the included MythTV version can be. And even if it can, I am not sure if MythTV would run. If the goal is a patent/royalty free binary distribution, there is a lot more work to consider than just LAME.

[Gary Buhrmaster <gary.buhrmaster@…>]

Replying to anonymous@…: ....

I would have expected that a MythTV distribution would need to be marked restricted and not distributed as a binary too due to codec patent encumbrances.

I will point out that most of the essential patents in the MPEG-2 pool have expired. Unfortunately, some do not expire until 2018 (in the US, other dates in other countries), and as long as any are still valid, the licensing requirements still exists as far as the the pool is concerned. As long as FRAND patents are allowed in standards without royalty free options (or agreement of non-assertion) for open source, things will continue to be interesting for those projects.

[JYA]

Where have you found that those patents have expired? would like to see some proof of that

Mozilla is even removing support for using an external, presently installed libavcodec/libavformat due to patent on h264 and AAC by various parties and instead moving to proprietary decoders from software companies with the appropriate license.

Something to do with the "straight face" test of not knowingly getting around patent infringements.

[Gary Buhrmaster <gary.buhrmaster@…>]

Replying to jyavenard:

Where have you found that those patents have expired? would like to see some proof of that

I did say most, not all, and MPEG-2, not the others. It was all the news about a year ago (when a couple of big ones expired). Anyway, the easiest reference is probably the wikipedia page ​http://en.wikipedia.org/wiki/MPEG-2 (click "show" on the patents table).

Mozilla is even removing support for using an external, presently installed libavcodec/libavformat due to patent on h264 and AAC by various parties and instead moving to proprietary decoders from software companies with the appropriate license.

Yes, H.264 and AAC have different patents/pools. For simple values, every codec (that people want to use) has someone who has claimed a patent on it. Sometimes two or more orgs (the LZW patent, for example)

Something to do with the "straight face" test of not knowingly getting around patent infringements.

Depending on the jurisdiction, and exact wording of the laws, knowingly and/or contributory infringement can result in interesting results (where interesting is never cake and ice cream). Mozilla, I am sure, took their action after due consideration of the potential risks as outlined by their Counsel.

[Stuart Auchterlonie]

Initial work done in f7ee02433363cb6ecceae2bf8da740d34769fa10

[Jean-Yves Avenard <jyavenard@…>]

In 7bc9ec23445684f5e5d08d0e1152be62faef066b/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available