> why don't you just use the "new fetch" api IFIR when the original version of that code was written (back in the Oryol project https://github.com/floooh/oryol), the Fetch API might not have been implemented by all browsers yet. It probably makes sense to rewrite sokol_fetch.h to use Fetch now).
> in this case ,the content-length was unknown, so the range request is not possible, right I don't know, I hadn't considered this case. Probably needs some experimenting. The most annoying problem with XMLHttpRequest is definitely that it's not possible to query the uncompressed size of compressed downloads upfront, so it's not possible to first do a HEAD request to get the Content-Length, and allocate a buffer of the right size to receive the download, because Content-Length will be the compressed size, but the downloaded data will be uncompressed. Same with Range requests, the offset and size is provided on the compressed data, so the data chunk that's returned will be bigger then the requested size. TBH I have no idea in which scenario such a weird behaviour would ever make sense, but there are not many things in web development that make sense anyway ;) I'll actually need to look into the Fetch API if this somehow fixes the compressed vs uncompressed offset/size problem (I would be surprised if it did though). Cheers! -Floh. On Saturday, 8 January 2022 at 14:40:45 UTC+1 [email protected] wrote: > Great work, very inspired. > I am very new in the web world, but i can understand your great work. big > fan. > why don't you just use the "new fetch" api as it already support a stream, > but the "legacy XMLHttpRequest " may need to send multiple request with > range making the logic a bit complex. > also, the src "file" may not be a fix-sized video file ,it may be a > realtime live stream, in this case ,the content-length was unknown, so the > range request is not possible, right? > > I see your entire project, you really have done some great work. > appreciate. > 在2022年1月8日星期六 UTC+8 00:31:05<Floh> 写道： > >> You can read the C and Javascript source code in my sokol_fetch.h header >> for inspiration, this supports reading large data files piece by piece via >> HTTP Range requests (via XMLHttpRequest). >> >> https://github.com/floooh/sokol/blob/master/sokol_fetch.h >> >> The interesting stuff is here: >> >> >> https://github.com/floooh/sokol/blob/4ff3ed7d604c3a876146cbf2d89597d81812de22/sokol_fetch.h#L1923-L2064 >> >> The fetched data is transferred to the C side by directly copying into >> the WASM heap here (using a pointer to a pre-allocated buffer from the C >> side): >> >> >> https://github.com/floooh/sokol/blob/4ff3ed7d604c3a876146cbf2d89597d81812de22/sokol_fetch.h#L1959 >> >> It should also be possible to dynamically allocate a memory chunk in the >> WASM heap on the Javascript side, but I haven't tried that yet. For such >> things I usually look in the Emscripten SDK's 'src' directory for examples. >> >> An example for sokol_fetch.h which loads data via Range requests is here >> (this uses https://github.com/phoboslab/pl_mpeg/blob/master/pl_mpeg.h to >> decode the MPEG stream): >> >> https://floooh.github.io/sokol-html5/plmpeg-sapp.html >> >> Cheers! >> -Floh. >> >> On Friday, 7 January 2022 at 13:07:44 UTC+1 [email protected] wrote: >> >>> Hi, >>> I want to compile ffmpeg to play some H.265 video on the web, i want to >>> use fetch api(https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) >>> in js layer to fetch the media data from my server and I can get a >>> ReadableStream, but how can i get the data chunk from this stream? what's >>> the best practice, or do i have a better solution? >>> >>> BTW I've tried the native fetch api ,since the media file may be too big >>> to load into memory, i must play it piece by piece. but the native fetch >>> api couldn't implement a "data chunk stream", i have to give it up. >>> >>> Best wishes. >>> Jiaozebo >>> >> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/6a38bba2-8f03-4a45-af88-a94ef1c681f6n%40googlegroups.com.
