[asterisk-dev] [Code Review] 3625: media_formats: Update most of core (main/*.c)

Corey Farrell reviewboard at asterisk.org
Fri Jun 20 12:35:01 CDT 2014 


> On June 19, 2014, 3:56 p.m., Matt Jordan wrote:
> > /team/group/media_formats-reviewed/main/data.c, lines 3122-3126
> > <https://reviewboard.asterisk.org/r/3625/diff/1/?file=59757#file59757line3122>
> >
> >     Is/was fr_len used anywhere else?
> 
> Corey Farrell wrote:
>     fr_len is still referenced from res_rtp_asterisk in the call to ast_smoother_new().  It was previously set by format_list_add_static and the code that added celt/silk.
> 
> Matt Jordan wrote:
>     Hum hum hm. ast_smoother_new wants the number of bytes that a frame produced for that format should have.
>     
>     Shouldn't that be ast_format_get_sample_rate(fmt)/ast_format_get_default_ms(fmt)?
> 
> Corey Farrell wrote:
>     Nope.  sample_rate is number of samples per second, default ms is milliseconds per frame.  Your equation for ulaw would be 8000/20 = 400, but fr_len for ulaw was 80.
> 
> Matt Jordan wrote:
>     Drat. Unless Josh has an idea on how else to get this value, I'd guess that we have to add it back.
> 
> Joshua Colp wrote:
>     Hum, we have to add it back but let's actually name it something sane. "Frame length" is a bit overloaded. Format data size?
> 
> Corey Farrell wrote:
>     How about ast_codec->frame_bytes?  I believe this belongs to codec not format.  I think data_size is ambiguous.  Without reading the comments or just knowing you would question if the size is bytes or bits, and if the period is a frame, sample, or second.  I like self-documenting code.
>     
>     Also are we changing the name used for ast_data_add_int?  I don't personally use any of the features from this file so I don't know how important backwards compatibility is.
> 
> Matt Jordan wrote:
>     Moment of completely honesty: the 'data' stuff is a little broken. I remember playing around with it back in Asterisk 10 and finding that it seg faulted more often than not when exporting data out of app_voicemail (granted, it is app_voicemail).
>     
>     Even if that weren't the case, I'm not sure I agree with the idea that exporting raw data structures out of Asterisk is the best way to expose things to external consumers in the first place. Sure, I suppose it is interesting to see what all the values of an ast_channel structure are: but ... what do you do with it? It feels like an interesting intellectual exercise that ended up complicating a lot of the Asterisk core.
>     
>     Maybe I'm missing something about the Data retrieval API and its intended purpose, but I've yet to find (a) a user of Asterisk who uses it; or (b) what it is super useful for.
>     
>

I agree completely.  I feel that the data retrieval API only serves to burn clock cycles and add risk through out the code base.  On the other hand it's a feature that has been exposed to end users, so I assume it needs to be updated.  I have no objection to saying "codecs are no longer exposed via data.c API" - if I'm told to do so.

I'd like to delete main/data.c and every block of code that uses it to make copies of data that is never used.  This would be based on my idea that unneeded complexity == unneeded risk. Unfortunately data.c was not deprecated in Asterisk 12, so I assume the most we can do is mark it deprecated for Asterisk 13 and scheduled for removal from Asterisk 14.  This feels like a discussion unrelated to media formats API, so if we are to pursue it maybe start a new thread on asterisk-dev.  A posting to asterisk-users might also be good, to seek out asterisk users who think they need the data retrieval API.


- Corey


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3625/#review12220
-----------------------------------------------------------


On June 19, 2014, 4:31 p.m., Corey Farrell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3625/
> -----------------------------------------------------------
> 
> (Updated June 19, 2014, 4:31 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Updates to allow most of the Asterisk core to compile.  I've excluded main/channel.c, main/dsp.c and main/rtp_engine.c.  Changes to those files will be posted separate since I feel they are more complex and likely to have more error's.  If any of the files included in this review fit that description let me know and I will split them off.
> 
> This change does not include any replacement for calls to ast_format_is_slinear(), and adds it back to the header (but does not implement).  So ast_format_is_slinear hasn't been fixed, just deferred to become a link error.
> 
> The modifications to chan_phone are to allow what I believe to be a comparability function to be in the correct namespace to be implemented in format_compatibility.c.
> 
> 
> Diffs
> -----
> 
>   /team/group/media_formats-reviewed/main/stasis_channels.c 416235 
>   /team/group/media_formats-reviewed/main/sounds_index.c 416235 
>   /team/group/media_formats-reviewed/main/sorcery.c 416235 
>   /team/group/media_formats-reviewed/main/slinfactory.c 416235 
>   /team/group/media_formats-reviewed/main/media_index.c 416235 
>   /team/group/media_formats-reviewed/main/manager.c 416235 
>   /team/group/media_formats-reviewed/main/indications.c 416235 
>   /team/group/media_formats-reviewed/main/image.c 416235 
>   /team/group/media_formats-reviewed/main/frame.c 416235 
>   /team/group/media_formats-reviewed/main/format_pref.c 416235 
>   /team/group/media_formats-reviewed/main/format_compatibility.c 416235 
>   /team/group/media_formats-reviewed/main/format.c 416235 
>   /team/group/media_formats-reviewed/main/file.c 416235 
>   /team/group/media_formats-reviewed/main/dial.c 416235 
>   /team/group/media_formats-reviewed/main/data.c 416235 
>   /team/group/media_formats-reviewed/main/core_unreal.c 416235 
>   /team/group/media_formats-reviewed/main/core_local.c 416235 
>   /team/group/media_formats-reviewed/main/codec.c 416235 
>   /team/group/media_formats-reviewed/include/asterisk/slinfactory.h 416235 
>   /team/group/media_formats-reviewed/include/asterisk/rtp_engine.h 416235 
>   /team/group/media_formats-reviewed/include/asterisk/format_pref.h 416235 
>   /team/group/media_formats-reviewed/include/asterisk/format_compatibility.h 416235 
>   /team/group/media_formats-reviewed/include/asterisk/format_cache.h 416235 
>   /team/group/media_formats-reviewed/include/asterisk/format.h 416235 
>   /team/group/media_formats-reviewed/include/asterisk/file.h 416235 
>   /team/group/media_formats-reviewed/channels/chan_phone.c 416235 
> 
> Diff: https://reviewboard.asterisk.org/r/3625/diff/
> 
> 
> Testing
> -------
> 
> Compiled.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140620/56c32f8f/attachment.html>

More information about the asterisk-dev mailing list