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/emscripten-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/ > topic/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.
