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 <one...@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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
