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

filesystem.writeBinaryFile() appears to not work on Array Buffers above a certain size #74

Open
dimitrinossar opened this issue May 2, 2023 · 7 comments

Comments

@dimitrinossar
Copy link

Hi, I'm writing a small project to convert audio files and I've found what I think might be an issue with the writeBinaryFile API. Array Buffers that are above a certain size seem to be choking the program but it won't throw any obvious errors.

const output = ffmpeg.FS('readFile', download)
await filesystem.writeBinaryFile(`${saveLocation}/${download}`, output)

Logging the output will always return a valid uint8array regardless of the file format and lossy audio files (such as mp3) will write to the location fine and continue on with the program's control flow but larger lossless audio files (flac, wav) seem to hang endlessly on the await but importantly refuse to throw an NE_FS_FILWRER error.

To give an idea of the sizes I'm dealing with, my limited test involved an mp3 around 11MB, a flac around 32MB, and a wav around 58mb.

@skushagra9
Copy link

Hey, I am interested to work on this issue, Please assign to me

@skushagra9
Copy link

I have checked it and It doesn't gives me this error
image

@Sadaf-A
Copy link
Contributor

Sadaf-A commented Feb 23, 2024

Hi, I'm writing a small project to convert audio files and I've found what I think might be an issue with the writeBinaryFile API. Array Buffers that are above a certain size seem to be choking the program but it won't throw any obvious errors.

const output = ffmpeg.FS('readFile', download)
await filesystem.writeBinaryFile(`${saveLocation}/${download}`, output)

Logging the output will always return a valid uint8array regardless of the file format and lossy audio files (such as mp3) will write to the location fine and continue on with the program's control flow but larger lossless audio files (flac, wav) seem to hang endlessly on the await but importantly refuse to throw an NE_FS_FILWRER error.

To give an idea of the sizes I'm dealing with, my limited test involved an mp3 around 11MB, a flac around 32MB, and a wav around 58mb.

hey @dimitrinossar, are you still facing this issue? could please provide some more information like the operating system you are using? and what is the size limit after which the function stops working?

@Kanai2003
Copy link

@shalithasuranga It seems like if the file size is big then this kind of issue occurring
My approach is to divide the data into small chunks and then send it because Most modern WebSocket implementations should be able to handle 1MB of data in a single message without any issues but in this case, the size is higher than 1 MB so we need to slice it and then send it.

@Chrahuldeveloper
Copy link

hii i can slove the issue please assign it to me

@shalithasuranga
Copy link
Member

Hello, @dimitrinossar, looks like we need to implement file write streams, similar to openFile() binary read mode. Will you be able to select appendBinaryFile() as a workaround by splitting files from the app?

Note: I've removed gsoc label from this issue since it looks like a feature request to the framework core.

Thanks 🎉

@tdahlstrom
Copy link

I ran into this issue a few months back. Downloaded files somewhere between 20-30mb and greater started causing this issue. I was testing using ubuntu 22.04.

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

No branches or pull requests

7 participants