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 <marth64@proxyid.net> 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