[FFmpeg-devel] [PATCH] libavformat: add librist protocol

James Almer jamrial at gmail.com
Sun Jan 31 02:29:34 EET 2021


On 1/30/2021 8:57 PM, Marton Balint wrote:
> 
> 
> On Tue, 26 Jan 2021, Paul B Mahol wrote:
> 
>> This work is sponsored by Open Broadcast Systems.
>>
>> Signed-off-by: Paul B Mahol <onemda at gmail.com>
>> ---
>> configure               |   5 +
>> doc/protocols.texi      |  32 +++++
>> libavformat/Makefile    |   1 +
>> libavformat/librist.c   | 251 ++++++++++++++++++++++++++++++++++++++++
>> libavformat/protocols.c |   1 +
>> 5 files changed, 290 insertions(+)
>> create mode 100644 libavformat/librist.c
>>
> 
> [...]
> 
>> +typedef struct RISTContext {
>> +    const AVClass *class;
>> +
>> +    int profile;
>> +    int buffer_size;
>> +    int packet_size;
>> +    int log_level;
>> +    int encryption;
>> +    char *secret;
>> +
>> +    struct rist_logging_settings logging_settings;
>> +    struct rist_peer_config peer_config;
> 
> Can you avoid these on the stack? If librist adds new members to them, 
> this might break, and there is now API for freeing them properly.

Not against this suggestion, but it should be ok to have them in stack.
For rist_peer_config, he's calling rist_peer_config_defaults_set() first 
thing on the struct, so any new field will always be properly 
initialized by the library. And rist_logging_settings is zeroed by 
rist_logging_set() in the scenario where it allocs it, so it's the same 
as zeroing it ourselves as part of the RISTContext allocation.

Any changes to either struct should go alongside a soname bump in 
librist, too.

> 
> Thanks,
> Marton
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".



More information about the ffmpeg-devel mailing list