Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] StreamSink starving memory #2373

Closed
thunderstorm010 opened this issue Oct 26, 2024 · 7 comments
Closed

[Bug] StreamSink starving memory #2373

thunderstorm010 opened this issue Oct 26, 2024 · 7 comments
Labels
bug Something isn't working

Comments

@thunderstorm010
Copy link

Hi. I'm trying to stream video frames (in this example Vec) from Rust to Flutter. But frb seems to eat more and more RAM growing exponentially.

Here is my code:

pub fn stream_video(stream_sink: StreamSink<Vec<u8>>, pipeline: String) -> anyhow::Result<()> {
    gstreamer::init().unwrap();
    let element = gstreamer::parse::launch(&pipeline)?;
    let bin = element
        .downcast::<Bin>()
        .map_err(|_| anyhow::anyhow!("Failed to downcast initial element to bin"))?;
    let sink_element = bin.by_name("video-sink").ok_or(anyhow::anyhow!("Failed to find appsink named video-sink. The pipeline should always end with an appsink named video-sink"))?;
    let sink = sink_element.downcast::<gstreamer_app::AppSink>().map_err(|_| anyhow::anyhow!("Failed to map sink element to appsink. The pipeline should always end with an appsink"))?;
    bin.set_state(gstreamer::State::Playing).unwrap();
    std::thread::spawn(move || {
        loop {
            let sample = sink.pull_sample().unwrap();
            let buf = sample.buffer().unwrap().map_readable().unwrap().to_vec();
            stream_sink.add(buf).unwrap();
        }   
    });
    Ok(())
}

Notes:

  1. Removing the line with stream_sink.add results in constant memory use (aka no problem.) (I think this means the problem is not with Gstreamer)
  2. Even when I remove the dart side code handling the stream (inside the Stream.listen function), memory use continues to grow.
  3. If further information is needed, just write a comment and I will answer asap.

Thanks for everything

Copy link

welcome bot commented Oct 26, 2024

Hi! Thanks for opening your first issue here! 😄

@fzyzcjy
Copy link
Owner

fzyzcjy commented Oct 27, 2024

Hi, could you please make a minimal reproducible sample? For example, maybe

pub fn f(sink: StreamSink<Vec<u8>>) {
  loop {
    sink.add(vec![0; 1000000]);
    sleep(100ms);
  }
}

And to debug, also try to do manually trigger a (full) GC on Dart side, and see whether memory is better.

And try dart's devtool's memory part, to see what is eating a lot of memory, and why they are alive instead of GCed.

@fzyzcjy
Copy link
Owner

fzyzcjy commented Oct 27, 2024

Btw, if you want to show videos, then I guess it is great to avoid such rust-to-dart transfer, because after you transfer the bytes to Dart, indeed dart has to again transfer to its engine and display, which is quite long and slow.

One possible way may be, use https://github.com/irondash/irondash/tree/main/texture. Then the rust gstreamer frames can directly be displayed to screen, and the rest of the app can be written in Flutter.

Possibly related: #1776

@thunderstorm010
Copy link
Author

Hi, firstly thanks for your answer.

I tried irondash, and after some fiddling around I've finally got it to work. I don't have problems anymore, and also kudos to the owner of irondash as well

@fzyzcjy
Copy link
Owner

fzyzcjy commented Nov 1, 2024

Hi, happy to see it works! Btw if you see any bugs (such as the starving memory issue) with reproducible sample, feel free to ping me.

also kudos to the owner of irondash as well

cc @knopp - owner or irondash

@fzyzcjy
Copy link
Owner

fzyzcjy commented Nov 5, 2024

Close since this seems to be solved, but feel free to reopen if you have any questions!

@fzyzcjy fzyzcjy closed this as completed Nov 5, 2024
@fzyzcjy fzyzcjy added the bug Something isn't working label Nov 5, 2024
Copy link
Contributor

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new issue.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 19, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants