record
record copied to clipboard
llfbandit
Record to byte array(Uint8List)
I'm using web version. I can record only virtual file. Then I need finalized record and then load virtual file to byte array(Uint8List). It takes time. Although I could play and send the file already during recording. How can this process be optimized?
Currently there is no alternative. The package is not ready to include this kind of feature and it is not as simple as it sounds like.
Quick notes:
1/ Android & iOS implementations to keep features on par. I'm not sure this could be achieved (without destroying all) .
2/ how to determine the constraint to acquire data (time, data size?).
3/ implementing could lead to many issues with dataavailable event (browser impl, size of recording, . . . )
@3215466800 @kamyar75 This is not the same issue.
Anyway, the following code should do it: final bytes = await XFile(path).readAsBytes();. This is also fully compliant with web target.
@3215466800 @kamyar75 This is not the same issue. Anyway, the following code should do it:
final bytes = await XFile(path).readAsBytes();. This is also fully compliant with web target.
xfile is not support web...
Yes it does https://pub.dev/packages/cross_file
are you is record owner?
i have see the code
final blob = html.Blob(_chunks); audioUrl = html.Url.createObjectUrl(blob);
but now i want upload this radio but now i don't know how to do
Yes it does https://pub.dev/packages/cross_file
yes i install cross_file is work already thanks
So here is a working solution to to get Uint8List for web:
I have not confirmed this yet, but you should get the same result for mobile i hope
final RecordPluginWeb _recordWeb = RecordPluginWeb();
when you call stop like so: _recordWeb.stop(); it returns a path string so do this
'_recordWeb.stop().then((value) async{ final result = await http.get(Uri.parse(value)); Uint8List data = result.bodyBytes.buffer; }`
;)
@3215466800 @kamyar75 This is not the same issue. Anyway, the following code should do it:
final bytes = await XFile(path).readAsBytes();. This is also fully compliant with web target.
I can't make this work, neither the following HTTP solution:
_recordWeb.stop().then((value) async{
final result = await http.get(Uri.parse(value));
Uint8List bytes = result.bodyBytes;
}
The result is converted into NativeUint8List but it can't be uploaded through MultipartFile, while on mobile it does.
This would be great. I believe exposing the byte stream instead of the record file is much better. In my case, I'm sending short audio clips over socket without persisting. Saving data to file and reading it each time means extra ms delay I don't want and I have to delete the file each time also.
This would be great. I believe exposing the byte stream instead of the record file is much better. In my case, I'm sending short audio clips over socket without persisting. Saving data to file and reading it each time means extra ms delay I don't want and I have to delete the file each time also.
Totally agree, stream is really important to audio recording.
What I guess is that most users want the encoded output as a live stream. This will require a lot of rework to achieve this.
Many formats are not directly streamable because of two things: headers and "chunk to chunk" encoding. Here are the formats that should be available for streaming : AAC (in MP4 container) and PCM formats. Opus and vorbis certainly.
=> We can't stream an output that is re-written at different positions. So we can't simply watch the output file and provide chunks as soon they are written (it may or may not work at all on different platforms and versions).
So the way to go is to get closer to the codecs from the underlying platforms to access to the vended/valid chunks.
Here are my current leads on the subject:
On Android, with MediaCodec.
On macOS, with AVCaptureAudioDataOutput.
On iOS, maybe by reworking the code to use the pretty much same code as macOS.
On web, I don't know.
On Windows/linux, this seems to be a nogo with fmedia.
I started to document myself to allow this feature but don't be in a rush...