Hi all, Thank you so much for taking the time to look into this, Yalda.
I'm glad that you found the changes suitable! I have looked into the memory leak with the api-dump-stream-meta-test. The test binary was not written with a continuous http stream in mind so it needs to be updated to shutdown more gracefully in cases like this. I'll work on it. What do you/y'all think should be the next steps here? If you approve https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20327, can it be merged? I have pushed a rebase of https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20327 which should make it suitable for merge now. Let me know! -- Romain Le sam. 27 sept. 2025 à 15:39, Yalda <[email protected]> a écrit : > Hello, > > Apologies for the delay. > I have been testing #20327 today with various samples (local, online) > and the api-dump-stream-meta-test tool to observe metadata changes > while listening. > > Code looks good, and to me it seems Romain addressed concerns. > I think it makes sense to drop the header packets from output on > segment change and store them as extradata. > > I do believe there might be a leak in the api-dump-stream-meta-test > tool (but not in the demuxer change, which is this patch). > > Compare (valgrind reports errors): > ``` > valgrind --leak-check=full ./api-dump-stream-meta-test > http://play.global.audio/city.ogg > ``` > vs. ffmpeg itself (clean) > ``` > valgrind --leak-check=full ./ffmpeg -i > http://play.global.audio/city.ogg -c copy -f null - > ``` > > I left a question in the PR, but no other concerns. > Note I had found the above input stream from > https://dir.xiph.org/codecs/Vorbis > > Thank you! > Yalda > _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
