Note that threads in wasm are very high priority. Should be testable soon. On Tue, Oct 17, 2017 at 4:19 AM, Michael IV <[email protected]> wrote:
> Thanks man for this extensive info! The multi-threading is indeed the main > concern here. I am afraid that single threaded decoding will not be optimal > for my needs. I already checked Broadway.js .But it > supports only h264 base profile and yes,it is slow when it comes to decode > HD at 60 or more FPS. So I need to see how to approach this problem. > Many thanks for the info again. > > > On Tue, Oct 17, 2017 at 3:15 AM, Brion Vibber <[email protected]> wrote: > >> On Mon, Oct 16, 2017 at 2:15 PM, Michael IV <[email protected]> >> wrote: >> >>> Hi All. I need a little advice before I invest my time int this >>> adventure. I need to decode h264 streams in a browser (I don't want to use >>> HLS,MPEG DASH or other high latency techs). And I would like (ideally) to >>> use API from libavcodec,libavformat and the rest of FFMPEG libs. >>> >> >> You might want to start with https://github.com/Kagami/ffmpeg.js -- >> oriented around encoding, but the build of the libraries is the important >> part... Last I tried a couple years ago, OpenH264 also builds with >> emscripten but I haven't tested it in a while. >> >> You might also find benefit from some parts of my ogv.js WebM/Ogg player >> (no H.264 included yet due to patent concerns), in particular you may find >> yuv-canvas useful for accelerating YUV-RGB conversion and display with >> WebGL: https://github.com/brion/yuv-canvas >> >> >>> I would like to know if emscripten has any restriction which may prevent >>> me from accomplish this task. I played around with emscripten a couple of >>> years ago and today I am not really aware of its state. For example, >>> FFMPEG libs are multi-threaded (especially encoders/decoders). Does >>> emscripten >>> allow threaded C/C++ code? What are additional underwater stones I can >>> get while trying such a thing? >>> >> >> Threading with pthreads is supported on browsers with SharedArrayBuffer >> support - see https://kripken.github.io/emsc >> ripten-site/docs/porting/pthreads.html - but there are difficulties: >> * not all browsers have SharedArrayBuffer yet >> * threading not yet support for WASM builds >> * threading with asm.js builds requires re-parsing JavaScript on every >> thread, which increases memory requirements and load times >> * some browsers de-optimize threaded asm.js code, which can make it run >> slower than single-threaded builds! >> * pthreads mode is currently incompatible with the 'modular' mode used to >> make the compiled code more reusable - I have a patch >> https://github.com/kripken/emscripten/pull/5016 which may or may not >> still apply cleanly. >> >> My recommendation is to make a single-threaded build for now, and wait >> for threading to arrive in WASM before trying to deploy threaded emscripten >> code. >> >> Good luck! >> >> -- brion >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "emscripten-discuss" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/to >> pic/emscripten-discuss/Vu9mSSpWtTQ/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > 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]. > For more options, visit https://groups.google.com/d/optout. > -- 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]. For more options, visit https://groups.google.com/d/optout.
