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

In browser memory allocation #46

Open
pedrobroese opened this issue Dec 26, 2021 · 25 comments
Open

In browser memory allocation #46

pedrobroese opened this issue Dec 26, 2021 · 25 comments

Comments

@pedrobroese
Copy link

pedrobroese commented Dec 26, 2021

First of all, congrats for the great work! I am using your code in a project to analyze GPS data for go-kart and trackday. I extract the GPMF data in the browser, and used browserify to bundle the code together. I run the module as below:

data = await gpmfExtract([file object],true,progress);

The problem that started to show up lately, is that the memory the browser allocates to process a single big file (4GB mp4 file) is so big that eventually the window hangs. I've checked that the same issue happens when I process the file in https://goprotelemetryextractor.com/free/# (it allocates almos 7GB for the chrome process). Maybe this is a mp4box issue?

@JuanIrache
Copy link
Owner

It could be an mp4box issue. I'm not sure, as for larger files I use and recommend offline versions of the extractor, which use ffmpeg instead of mp4box. How large are your files?

@pedrobroese
Copy link
Author

pedrobroese commented Dec 26, 2021 via email

@pedrobroese
Copy link
Author

pedrobroese commented Dec 26, 2021 via email

@JuanIrache
Copy link
Owner

I haven't experienced problems with 4GB files on the online version of the Extractor. Except maybe on Firefox, which caused some issues in the past, but I thought they had been solved

@pedrobroese
Copy link
Author

image

@JuanIrache
Copy link
Owner

Thanks for the additional information. I will try to find the time to investigate this. If you make some progress or find something else in the meantime, please let me know

@pedrobroese
Copy link
Author

pedrobroese commented Dec 27, 2021 via email

@JuanIrache
Copy link
Owner

I haven't touched this repo in a while, but I would start by trying the following:

  • Update mp4box and see if the issue persists
  • Force the program to run in webworker and "factory" mode and see if both produce the problem (line 126 of index.js)

@pedrobroese
Copy link
Author

I haven't touched this repo in a while, but I would start by trying the following:

  • Update mp4box and see if the issue persists
  • Force the program to run in webworker and "factory" mode and see if both produce the problem (line 126 of index.js)

Ok, so I think we might have found the issue: mp4box was up to date, reinstalled it, all the same, so, nothing related to it. However, when I force the program to use the readBlock instead of the worker, the problem is gone. So, I'll try to understand the worker and then attempt to debug.

image

@tomrum
Copy link

tomrum commented Dec 30, 2021

Hi there! I’ve noticed the problem too for a while. In my experience there seems to be less issues with this library on Mac. It extracts GoPro Hero 8 4K 4GB videos and .LRV likes using Chrome browser no problem although Mac Firefox crashes regularly.

I have been using Windows 10 more recently with my website https://maps.video and have noticed that randomly the progress bar gets stuck and I think this is due to memory issues also. .LRV files being much smaller in file size seem to always work perfectly with Chrome at least, Firefox can still crash.

I have tested extracting 4GB video files on my Windows 10 laptop and a Bootcamped Windows 10 Mac. They both have the same issue on Chrome with the progress bar stopping and the extraction halting (see screenshots where it has got stuck). It seems to get stuck when the memory is high and for certain videos that it does not seem to like.

I also extract the GPMF data in the browser, and use browserify to bundle the code together. I do:

window.gpmfExtract(file, true, progress).then(function (res) {

Would really appreciate a fix if one would be made available as most my customers use Windows Chrome.

Thanks!

Windows 10 Laptop:

gpmf-extract-video-hangs

Bootcamped Mac (Windows 10):

gpmf-extract-video-hangs-windows-10-bootcamp

@JuanIrache
Copy link
Owner

I'm thinking that, if this is only happening with web workers, one quick workaround would be to set an option not to use the web worker. Not ideal, but maybe enough for now. I have implemented that in the dev branch but I won't be able to test this on Windows for a few days: https://github.com/JuanIrache/gpmf-extract/tree/dev

Happy to hear your feedback. Note that the arguments of the main function have changed. See the readme.

@tomrum
Copy link

tomrum commented Dec 30, 2021 via email

@JuanIrache
Copy link
Owner

In order to test this quickly, I've published an update here that uses the new approach: https://goprotelemetryextractor.com/free

I appreciate any feedback, especially if you currently have access to large files and the problematic systems/browsers

Thanks!

@tomrum
Copy link

tomrum commented Dec 31, 2021

I have just tested the new dev branch code by creating a new bundle and changing the gpmf function parameters but I am still getting the same problem. Sometimes the file will extract properly but a lot of the time the total system memory climbs above 80% which is when it stalls.

My windows 10 computer has 16Gb memory and I am loading 4Gb 4K videos. I tested the same problematic video file in your telemetry extractor free site several times and monitored the memory. The memory never climbed high like it does for my site https://maps.video and seemed to work perfectly.

So I have to ask what is the difference between your telemetry extractor javascript and mine? Is this a memory leak/management issue?

Thanks!

@JuanIrache
Copy link
Owner

Thank you for testing that. Are you using the useWorker:false option?

@tomrum
Copy link

tomrum commented Dec 31, 2021

Don't think so, how do I do it?

@JuanIrache
Copy link
Owner

JuanIrache commented Dec 31, 2021

gpmfExtract(file, {
          browserMode: true,
          progress: progressFunction,
          useWorker: false
        })
          .then(function (res) {
          // Do smth
})

Ideally a future version will work well with the worker too. But this might be working well for now, if the free tool gave you good results.

@tomrum
Copy link

tomrum commented Dec 31, 2021

Of course, testing now...

@tomrum
Copy link

tomrum commented Dec 31, 2021

Seems to have done the trick, memory much better now but will test more. Does this mean the videos are extracted only on the main UI thread?

Thanks!

@pedrobroese
Copy link
Author

pedrobroese commented Dec 31, 2021 via email

@JuanIrache
Copy link
Owner

Great! I will merge this.

Yes. This will only use the UI thread, so it's not ideal. I appreciate it if anyone makes progress on the worker front.

@tomrum
Copy link

tomrum commented Dec 31, 2021

Thanks. The UI is working fine on my website, Mac and Windows during extraction. (Zooming and dragging Google Map etc).

@Akxe
Copy link
Contributor

Akxe commented Apr 20, 2023

It might be time to retry. With @JuanIrache we have made changes to the parser. To my knowledge, the RAM usage should be much better now.

@jonaswitt
Copy link

Try calling

mp4boxFile.releaseUsedSamples(id, samples[samples.length - 1].number);

at the end of onSamples

resolve({ rawData, timing });

MP4Box holds on to the samples otherwise.

https://github.com/gpac/mp4box.js/blob/325741b592d910297bf609bc7c400fc76101077b/src/isofile.js#L539

@Akxe
Copy link
Contributor

Akxe commented Oct 25, 2023

If you are able to test the memory footprint, it would be great if you could test the hypothesis. Of true, please do a small PR. If you could create a test to ensure the memory is not leaking anymore, it would be also great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants