[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