From: Dragoslav M. <fd...@mo...> - 2010-05-24 16:39:41
|
Hi, I am looking for additional information on any known legal/distribution issues regarding use of mp3parse (mpegaudioparse) and asfdemux from the "ugly" plugins collection, and aacparse and amrparse from the "bad" collection. We are currently considering using these plugins in a product. We would respect the terms of LGPL of course, but are concerned about any additional known encumbrances. In particular, the documentation for the "ugly" collection specifies that "ugly" plugins may present distribution problems ("The license on either the plug-ins or the supporting libraries might not be how we'd like. The code might be widely known to present patent problems.") I am interested in the specific reasons why mp3parse and asfdemux were placed into the "ugly" category, so we can evaluate and make the decision whether to use them. Also, are aacparse and amrparse merely of lesser quaility (and thus in "bad" collection), or are there additional distribution issues regarding those two plugins? Your help would be greatly appreciated. -Dragoslav Mitrinovic |
From: Dragoslav M. <fd...@mo...> - 2010-06-05 23:55:09
|
Hi, I am looking for additional information on any known legal/distribution issues regarding use of mp3parse (mpegaudioparse) and asfdemux from the "ugly" plugins collection, and aacparse and amrparse from the "bad" collection. We are currently considering using these plugins in a product. We would respect the terms of LGPL of course, but are concerned about any additional known encumbrances. In particular, the documentation for the "ugly" collection specifies that "ugly" plugins may present distribution problems ("The license on either the plug-ins or the supporting libraries might not be how we'd like. The code might be widely known to present patent problems.") I am interested in the specific reasons why mp3parse and asfdemux were placed into the "ugly" category, so we can evaluate and make the decision whether to use them. Also, are aacparse and amrparse merely of lesser quaility (and thus in "bad" collection), or are there additional distribution issues regarding those two plugins? Your help would be greatly appreciated. -Dragoslav Mitrinovic |
From: Michael S. <ms...@xi...> - 2010-06-06 03:58:33
|
Ultimately, anyone answering this with anything other than "consult your attorney" is... being misleading, probably. However, in addition to that, I'll explain a bit: mp3parse: This is in -ugly because it's related to mp3, which has known patent issues. I expect a qualified patent attorney would be able to tell you that it's actually fine. asfdemux: Microsoft claims patents on aspects of the ASF format. I have no idea if asfdemux infringes any of them; of the four plugins you mention this is by far the most likely to be problematic. aacparse, amrparse: like mp3parse, these relate to processing formats that have known patent issues. Again I'd expect that a detailed analysis by a patent attorney would most likely end up telling you that these are fine from that perspective. Mike On Sat, Jun 5, 2010 at 4:54 PM, Dragoslav Mitrinovic <fd...@mo...> wrote: > Hi, > > I am looking for additional information on any known > legal/distribution issues regarding use of mp3parse (mpegaudioparse) > and asfdemux from the "ugly" plugins collection, and aacparse and > amrparse from the "bad" collection. > > We are currently considering using these plugins in a product. We > would respect the terms of LGPL of course, but are concerned about any > additional known encumbrances. > > In particular, the documentation for the "ugly" collection specifies > that "ugly" plugins may present distribution problems ("The license on > either the plug-ins or the supporting libraries might not be how we'd > like. The code might be widely known to present patent problems.") I > am interested in the specific reasons why mp3parse and asfdemux were > placed into the "ugly" category, so we can evaluate and make the > decision whether to use them. > > Also, are aacparse and amrparse merely of lesser quaility (and thus in > "bad" collection), or are there additional distribution issues > regarding those two plugins? > > Your help would be greatly appreciated. > -Dragoslav Mitrinovic > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Gstreamer-embedded mailing list > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > |
From: Felipe C. <fel...@gm...> - 2010-06-06 11:38:05
|
On Sun, Jun 6, 2010 at 6:58 AM, Michael Smith <ms...@xi...> wrote: > Ultimately, anyone answering this with anything other than "consult > your attorney" is... being misleading, probably. > > However, in addition to that, I'll explain a bit: > > mp3parse: This is in -ugly because it's related to mp3, which has > known patent issues. I expect a qualified patent attorney would be > able to tell you that it's actually fine. > > asfdemux: Microsoft claims patents on aspects of the ASF format. I > have no idea if asfdemux infringes any of them; of the four plugins > you mention this is by far the most likely to be problematic. > > aacparse, amrparse: like mp3parse, these relate to processing formats > that have known patent issues. Again I'd expect that a detailed > analysis by a patent attorney would most likely end up telling you > that these are fine from that perspective. However, it's quite likely that you are going to use these with some decoders, for which you will pay the respective license for distribution. So, whatever patent the parsers "infringe", should be covered by the decoders' license. -- Felipe Contreras |
From: Dragoslav M. <fd...@mo...> - 2010-06-08 20:26:52
|
Michael, Felipe, thanks for your responses. This was very useful info. -Dragoslav Mitrinovic On Sun, Jun 6, 2010 at 6:38 AM, Felipe Contreras <fel...@gm...> wrote: > > On Sun, Jun 6, 2010 at 6:58 AM, Michael Smith <ms...@xi...> wrote: > > Ultimately, anyone answering this with anything other than "consult > > your attorney" is... being misleading, probably. > > > > However, in addition to that, I'll explain a bit: > > > > mp3parse: This is in -ugly because it's related to mp3, which has > > known patent issues. I expect a qualified patent attorney would be > > able to tell you that it's actually fine. > > > > asfdemux: Microsoft claims patents on aspects of the ASF format. I > > have no idea if asfdemux infringes any of them; of the four plugins > > you mention this is by far the most likely to be problematic. > > > > aacparse, amrparse: like mp3parse, these relate to processing formats > > that have known patent issues. Again I'd expect that a detailed > > analysis by a patent attorney would most likely end up telling you > > that these are fine from that perspective. > > However, it's quite likely that you are going to use these with some > decoders, for which you will pay the respective license for > distribution. So, whatever patent the parsers "infringe", should be > covered by the decoders' license. > > -- > Felipe Contreras |
From: ranjit r. <ran...@ya...> - 2011-03-08 06:24:15
|
Dear All, I want to get the RTCP reports.I am using the following pipeline: udpsrc ! gstrtpbin ! rtpdepay ! decoder ! display. I am setting udpsrc's port property as device port + 1.linked udpsrc's "src" pad with "recv_rtcp_sink_1" pad of gstrtpbin.tapped a buffer probe on src pad of udpsrc. my question is : in the buffer probe call back, will i get the rtcp reports on the src pad of udpsrc. in what form will these reports be? i am not using jrtplib explicilty, i read in the docs that jrtplib is required, do i need it for collecting RTCP reports? if so how to use it? please clarify my above queries.Thanks in advance,Ranjit. |
From: Felipe C. <fel...@gm...> - 2011-03-08 10:45:44
|
Wrong mailing list, this is the correct one: gst...@li... -- Felipe Contreras |