GNOME Bugzilla – Bug 548842
[PLUGIN-MOVE] amrwb should be moved from -bad to -ugly
Last modified: 2009-06-16 18:58:16 UTC
amrwb plugin has docs and passes the generic tests. Code is quite simillar to that in amrnb. It should be moved to -ugly for license reasons. It is free to be used for members of ETSI after following some process.
It seems I am the only one interested in it :/ This move would help to separate the parseres into new plugin and make the use baseparse (see bug #548842).
- you really should have poked people to review the code and make sure everything comforms to the plugin-moving guidelines before imo ... - at first glance (10 secs), the code currently in -bad doesn't look of particularly "good" quality to me, see e.g. segment handling - moving to baseparse should be done *before* the move imho; there's no reason to block on baseparse making it into core or -base for that (you're basically saying 'I want to move this code into -ugly and then completely rewrite it, no? :))
I poked people: https://sourceforge.net/mailarchive/message.php?msg_name=48A0048F.4020808%40hora-obscura.de also on irc. No one of the maintainers cared so far. The code is almost identical to the amrnb plugin in ugly. I do my best to keep it in sync. Having then side by side would help that people make fixes in both. Regarding baseparse. I also posted to gst-devel in vain. Imho no one even tried the amr acc parsers I attached to bug #518857 What I want is to disable the amrnbparse in ugly, the amrwbparse in bad and add amrparse for the ticket to -bad I would like to know how we can do that without breaking things (disabling the parser in ugly which should never have been there). I would just do it, because likelyhood that people are using this is small (due to plugin-dependency on the amr libs that need to be installed manualy).
I don't know what to do with the amr components. You're right that it's hard to care - I've never installed the encumbered libs nor missed the AMR elements. I'm not clear what your proposal is in the last comment exactly. Deprecate the separate amrnbparse and amrwbparse elements in bad+ugly in favour of a new combined 'amrparse' that handles both? That's what it looks like in the patch. If that's the case, I think we should just do that in bad. Since amrnbparse is technically in -ugly and therefore part of our 'ABI', we should probably leave it alone. Later, when the combined 'amrparse' is ready, we could move it all to -ugly and replace 'amrnbparse' with the new plugin, with the additional step that 'amrparse' would be registered twice - once as 'amrparse' and once as 'amrnbparse'. If it's intended to be deprecated anyway, I don't see the point of moving 'amrwbparse' to -ugly.
Okay, then lets maturize the amrparse first. Once it has we can move only amrwbdec/enc to ugly and drop the amrwbparse. The amrnbparse we can just make RANK_NONE.
sounds like a plan.
any updates on this ? What's the state of the parsers ?
The parsers are in -pad, but work fine for me (us). Should we change the RANK, so that it gets more testing? Like set the RANK for amrnbparse and amrwbparse to NONE and the RANK for amrparse to MARGINAL. Imho elements in -bad should has NONE - thats why I have not proposed that earlier.
I have no problem with elements in -bad having a rank. Clearly, since I gave resindvd one :)
Should this discussion be closed as a dupe of bug 584890?
Good point - I'll close it as obsolete.