mbebenita / Broadway

A JavaScript H.264 decoder.
Other
2.73k stars 424 forks source link

Unminified js #12

Closed sterpe closed 9 years ago

sterpe commented 12 years ago

Hey Michael,

Awesome work, but noticed after forking that a couple of the js (avc-codec.js, maybe others) files were minified, Any chance we can get the unminified source into the repository? Will make it easier for others to make work on this awesome proj.

Steve

mbebenita commented 12 years ago

The sources are generated from C++ code compiled with Emscripten. The unminified sources wouldn't help you much either. - Michael

sterpe commented 12 years ago

Ah okay, was hoping to see how this would run on say an iPhone, to avoid the native device player & allow inline video, but iPhone JS engine doesn't support Float64Array and I think maybe mobile web has limited webGL support too? and probably a number of other things would crop up as well along the way. Seriously, I think this would be a game changer in the mobile space if you could get it working on smartphones.

urbenlegend commented 12 years ago

I have also done some experiments with running Broadway on mobile, and there's some browsers that support WebGL (at least on Android), but the biggest factor is performance. Mobile platforms just simply don't have the processing power yet to do this kind of stuff. I managed to get one video frame to show up before the browser froze.

sterpe commented 12 years ago

Hi Benjamin,

Thanks, I was discussing this with our video encoding specialist and he brought up the same. It's really unfortunate because Broadway is really a nifty piece of js. Mind if I ask why you were experimenting with it on mobile?

BrendanEich commented 12 years ago

Mobile devices almost all have H.264 hardware support, so there's no need for Broadway.js. Mobile GPU horsepower varies but GPUs are too general-purpose to beat custom H.264 hardware. Power utilization really can't be beat with dedicated hardware.

The point of Broadway was more to show how far JS performance has come, and to demo Emscripten. This doesn't mean we are done researching ways to map C and C++ to JS, WebGL, JS + RiverTrail, etc. But that's Research, not likely Deployed Product ;-).

/be

sterpe commented 12 years ago

Hi Brendan,

I was at the Boot2Gecko talk you gave at Bay Area Mobile (Coworking Space) a couple of months ago...I'm js lead at a premium mobile video advertising company in Mt. View, any chance I could get you in for a tech talk with us about the future of mobile web Mozilla envisions once B2G launches and how we might position ourselves to strongly support this platform out of the gate?

urbenlegend commented 12 years ago

@srterpe The main reason I am experimenting with this is because I am trying to get a low-latency live stream to browsers without using Flash. In this case, the HTML5 < video > tag is really not suitable...yet. I am mainly targeting desktop PCs, but I did a quick test of mobile just to see how it would hold up. The performance is not quite there yet, but the standards that it uses are certainly supported.

@BrendanEich Mobile devices do have accelerated H.264 support, but they're not exposed to the browser in a flexible way, not to mention that browsers have varying codec support for patent-encumbered H.264. Sure you can use < video >, which is hardware accelerated in most cases, but they're not suitable for low-latency live streaming. If there was a way to send raw H.264 data to a < video > tag via ArrayBuffers that would be totally awesome, but currently you need to do a lot of hackery to generate a .mp4 from a live stream (still a lot of issues even if you do manage to get it to work) and then feed in that .mp4 using HTTP to < video >. I would say that there is still a definitive need for Broadway.js or something like it in the mobile space. Are there any plans to support such use cases? I consider the lack of raw video stream support for < video > to be a serious issue.

BrendanEich commented 12 years ago

@srterpe: mail me at my well-known email address (either one), don't go off-topic here please.

@BenjaminXiao: you want WebRTC with h/w support as much as possible. We're working on it, so is Google (same open source, and we're pushing unencumbered formats that are good for n-way low-latency). Using Broadway as a stop-gap may help, but again: it won't be battery-friendly and many phones don't have much of a GPU. WebRTC is the solid solution.

/be

soliton4 commented 9 years ago

@sterpe @BenjaminXiao @BrendanEich maybe this interests you https://github.com/mbebenita/Broadway/pull/44

soliton4 commented 9 years ago

is there any reason to keep this issue open? is anyone still waiting for a reply? i am trying to reduce the open issues to a managable amount

sterpe commented 9 years ago

Fine to close

soliton4 commented 9 years ago

i just love to see the issue cnt go down ;)

ty