Please reply to all recipients as I specifically requested. Begin forwarded message:
Date: Wed, 16 Aug 2017 16:10:59 +0200 From: Peter Szabo <[email protected]> To: Shlomi Fish <[email protected]> Subject: Re: fixing c++ bugs - idea I have read through some other stuff regarding to AOM AV1, which uses emscripten in a more mature way. The codec world is improving fast, and even more people involved in it. Google rewrote many codecs, and removed ffmpeg from the android stack because of reasons. (I probably jump to that stuff, and avoid ffmpeg, as it's not feasible to use it in a webpage, i was able to reduce the initial building to 7,5MB, but it's big in a webspace) There are many better technologies where you can build stuff far more easier, if we would have some layer which translate back the orginal code to C++, like exploiting the manual debugging benefit, than it would be far easier to everyone. I'm not sure what would be easier to create a debugger what chrome has got and put to the c++ side to make the technology much more accessible, or make some bridge between the two world and let debug and maintin c++ code from javascript. I thought reading the docs can be very-very possible with very small effort. For example at the moment i have passed a request to VS code also, as it's more like an editor problem, than a debugger problem. I have played with ffmpeg some years ago and realized that lots of effort is taken (i have reached a week later a javascript related decoder, when broadway and different technologies used emscripten), but to improve codecs, and figure out new ones that kind of attitude holding back, and make the video decoder world so awful with patented technologies. Ffmpeg is a good reference project, but i'm not talking to refactor or even replace ffmpeg, i'm talking to make some fancy layer, which tracks down the debug info, and when somebody changes a javascript code it will affect back the c++ code. (so it's not an llvm translation, it's a pure javascript to c++ translation, so one way llvm translation what emscripten does, and source code translation back, and build it with make, so you have debugged, fixed the bug, and it would probably of after the c++ build also using chrome profiler and debug tools and lots of stuff, what you can use anyway, there is docs of emscrypten related to it) javascript is not supposed to replace any c++ codecs, but it can help to speed up the development time, and make the algorythmical knowledge accessible to everybody There are plenty of good c++ project which hasn't been evolved and finished because lacks of man power, and that's why patented technologies like h264 makes so much trouble for decades On Wed, Aug 16, 2017 at 11:07 AM, Shlomi Fish <[email protected]> wrote: > Hi Peter! > > Please reply to all recipients. > > I have already replied to your previous post here - > https://groups.google.com/forum/#!topic/emscripten-discuss/tSTHTMiXOns - > please > read it. > > If you are so concerned about the code quality of ffmpeg, then you should > try > to do https://en.wikipedia.org/wiki/Code_refactoring - also see > https://www.joelonsoftware.com/2000/04/06/things-you- > should-never-do-part-i/ > and https://www.joelonsoftware.com/2002/01/23/rub-a-dub-dub/ . But don't > expect > Emscripten to be the silver bullet that will magically help in that. > > Regards, > > Shlomi Fish > > On Tue, 15 Aug 2017 12:48:50 -0700 (PDT) Peter Szabo > <[email protected]> wrote: > > > I have seen lot's of documents about emscripten, specifically i'm working > > with ffmpeg. > > > > Ffmepg is terribly written, very hard to read, and fix bugs on it, and > > that's why the development is pretty slow. > > Android got rid of ffmpeg at some stage, and created new decoders for > > android. > > > > Especially in the vido codec world it would be important to develop free > > scource and free to use algorithm, > > which might be far better than the heavily patented mpeg formats. > > > > i have seen -g options in emscripten, which supposed to hold the names of > > the functions etc., > > to be able to debug. > > > > Are there any functionality, that can track down the changes written in > > javascript and port back to c++? > > > > It would be a valid and good idea, so a javascript developer or anyone > can > > fix bugs even in a massive badly written ffmepg. > > Badly written as it goes back to 10 years. > > > > I think there are hundreds of projects, which would need similar > mechnaism. > > > > Some of them can be ported to javascript, but some of them is not > supposed > > to work in javascript. > > > > If the c++ code can be debugged and can be transformed back to c++ on the > > original code, > > it can empower a massive community around the word, whcih lacks of > manpower, > > as to write in c/c++ is pretty hard. > > > > -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ http://www.shlomifish.org/humour/bits/facts/Summer-Glau/ Knuth is not God! Typing “God” into Google and pressing “I’m Feeling Lucky” will not lead you to his homepage. — http://www.shlomifish.org/humour/bits/facts/Knuth/ Please reply to list if it's a mailing list post - http://shlom.in/reply . -- 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.
I have read through some other stuff regarding to AOM AV1, which uses emscripten in a more mature way.
The codec world is improving fast, and even more people involved in it.
Google rewrote many codecs, and removed ffmpeg from the android stack because of reasons. (I probably jump to that stuff, and avoid ffmpeg, as it's not feasible to use it in a webpage, i was able to reduce the initial building to 7,5MB, but it's big in a webspace)
There are many better technologies where you can build stuff far more easier, if we would have some layer which translate back the orginal code to C++, like exploiting the manual debugging benefit, than it would be far easier to everyone. I'm not sure what would be easier to create a debugger what chrome has got and put to the c++ side to make the technology much more accessible, or make some bridge between the two world and let debug and maintin c++ code from _javascript_. I thought reading the docs can be very-very possible with very small effort.
For example at the moment i have passed a request to VS code also, as it's more like an editor problem, than a debugger problem.
I have played with ffmpeg some years ago and realized that lots of effort is taken (i have reached a week later a _javascript_ related decoder, when broadway and different technologies used emscripten), but to improve codecs, and figure out new ones that kind of attitude holding back, and make the video decoder world so awful with patented technologies.
Ffmpeg is a good reference project, but i'm not talking to refactor or even replace ffmpeg, i'm talking to make some fancy layer, which tracks down the debug info, and when somebody changes a _javascript_ code it will affect back the c++ code. (so it's not an llvm translation, it's a pure _javascript_ to c++ translation, so one way llvm translation what emscripten does, and source code translation back, and build it with make, so you have debugged, fixed the bug, and it would probably of after the c++ build also using chrome profiler and debug tools and lots of stuff, what you can use anyway, there is docs of emscrypten related to it)
_javascript_ is not supposed to replace any c++ codecs, but it can help to speed up the development time, and make the algorythmical knowledge accessible to everybody
There are plenty of good c++ project which hasn't been evolved and finished because lacks of man power, and that's why patented technologies like h264 makes so much trouble for decades
On Wed, Aug 16, 2017 at 11:07 AM, Shlomi Fish <[email protected]> wrote:
Hi Peter!
Please reply to all recipients.
I have already replied to your previous post here -
https://groups.google.com/forum/#!topic/emscripten- - pleasediscuss/tSTHTMiXOns
read it.
If you are so concerned about the code quality of ffmpeg, then you should try
to do https://en.wikipedia.org/wiki/Code_refactoring - also see
https://www.joelonsoftware.com/2000/04/06/things-you- should-never-do-part-i/
and https://www.joelonsoftware.com/2002/01/23/rub-a-dub-dub/ . But don't expect
Emscripten to be the silver bullet that will magically help in that.
Regards,
Shlomi Fish
On Tue, 15 Aug 2017 12:48:50 -0700 (PDT) Peter Szabo
<[email protected]> wrote:
> I have seen lot's of documents about emscripten, specifically i'm working
> with ffmpeg.
>
> Ffmepg is terribly written, very hard to read, and fix bugs on it, and
> that's why the development is pretty slow.
> Android got rid of ffmpeg at some stage, and created new decoders for
> android.
>
> Especially in the vido codec world it would be important to develop free
> scource and free to use algorithm,
> which might be far better than the heavily patented mpeg formats.
>
> i have seen -g options in emscripten, which supposed to hold the names of
> the functions etc.,
> to be able to debug.
>
> Are there any functionality, that can track down the changes written in
> _javascript_ and port back to c++?
>
> It would be a valid and good idea, so a _javascript_ developer or anyone can
> fix bugs even in a massive badly written ffmepg.
> Badly written as it goes back to 10 years.
>
> I think there are hundreds of projects, which would need similar mechnaism.
>
> Some of them can be ported to _javascript_, but some of them is not supposed
> to work in _javascript_.
>
> If the c++ code can be debugged and can be transformed back to c++ on the
> original code,
> it can empower a massive community around the word, whcih lacks of manpower,
> as to write in c/c++ is pretty hard.
>
