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

[Matt Jordan]

> On June 19, 2014, 2: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.

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.


- Matt


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


On June 19, 2014, 3: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, 3: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/c26ec596/attachment.html>