Advertisement
Guest User

Untitled

a guest
Jul 11th, 2012
82
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 4.80 KB | None | 0 0
  1. Thoughts on media processing libraries and C++ / C library "culture"
  2.  
  3. Its hectic ugly bad totally rediculous totally miserable for somebody who is not already a God in C++ . Its just a total waste of time , Lets start with the fastest library on linux for mpeg decoding..
  4.  
  5. Libmpg123 -> The library expects you to magically do everything for it , is written purely in non-object oriented , thread unsafe manner and expects programmer to do everything what it does is provide optimized mp3 decoding using a lot of black magic. [read source code a rant is not a place to explain that magic ]. So whats bad about it .
  6. Despite of it speed and somewhat proper documentation the library is barely programmer friendly crashes unexpected with some songs and its impossible to tell WHY [want a sample i can give u one ], Moreover its in rapid development but its documentation lacks a change guide. So developer should read the whole doxygen everytime he / she / it / they want to upgrade and then start from scratch if the mighty einstiens of mp3 decoding has changed something. Oh and the documentation has miserable errors ..
  7.  
  8. "mpg123 will automatically decode an mp3 file to signed 16 bit samples at 44100khz"
  9.  
  10. daFuq did i read , 44100 khz ? ??? 44100000 HZ !>!>!>!>!>! Holy mother of god ! and nobody has still changed it http://www.mpg123.de/api/group__mpg123__output.shtml ( goto Detailed Discription paragraph 4 )
  11.  
  12.  
  13. LibLame -> The mighty encoding library used anywhere and everywhere when somebody wants a robust mp3 encoder.. Oh and its the best quality aswell.
  14.  
  15. Issue. All the documentation is in one single API file , the website documentation is more or less written for lame executable which does make no sense when we call lame to encode frames and stuff inside a C/C++ programm.. URGHHHHHH Wastage of time and effort to read source codes of program which uses lame to do so .. its always just better to use ffmpeg that abstracts it.
  16.  
  17. Oh and dont forget lame has never got a single online tutorial for beginners if you want to use it better open the API yourself read every line of the huge file then read every line of lame.h and then you can start coding . *clap* *clap* good job
  18.  
  19.  
  20. ffmpeg ->
  21. Too much too much tooo much in a single package with nothing as documentation the websites api_examples use deprecated functions
  22. http://ffmpeg.org/doxygen/trunk/api-example_8c-source.html
  23.  
  24. decode_audio3 , encode_audio , alloc_context are all deprecated in source code.
  25.  
  26. Luckily they wrote a decoding_encoding file in the same directory but forgot to mention in the documentation that hey the api we are showing in this version is obsolate.
  27. And even in the updated version it still uses encode_audio which is deprecated since a while.
  28.  
  29. Moreover the libraries documentation is confusing as hell
  30. // from avcodec.h
  31.  
  32. * @note You might have to align the input buffer. The alignment requirements
  33. * depend on the CPU and the decoder.
  34.  
  35. What the hell ?
  36. Alignment of what ?
  37. Bits Bytes frames bufferstack WT WT WTF ?
  38.  
  39. there are large examples of confusions regarding ffmpeg but luckily there exists some people like me who are happy to take the blood sweat and tears to read the whole 4900 line avcodec.h and 2200 line avformat.h and then combine it with the knowledge we can gain from wiki / google / the dev SOS calls to make a sense of what the hell is this library trying to do.
  40.  
  41. And this is not just it !
  42.  
  43. nodejs is another brilliant example of it aswell it tells u do kiddy stuff at the documentation center for native modules and then puts you to read the postgre-sql decoder written in mighty blinding C which is a total overkill for anybody who is just learning.
  44.  
  45. Best practice for that case is to better go and read the whole v8 first experiment with it a lil bit then go and start writing kiddy modules on node.js read the source code of well documented png module for nodejs and then start writing some serious work [ and dont forget the experimentation part needs to be relatively HUGE or else you wont get a single line of code of nodepng despite being documented]
  46.  
  47.  
  48. AND MOST OF THE LIBRARY DOCUMENTATION ARE WRITTEN IN GREEK
  49. the language is so technical sometimes that its better to keep a pocket google / wikipedia to read out nearly half the information on the subject just to understand how to properly use 5 functions.
  50.  
  51.  
  52. So whats the point.
  53. Point is that idk why but C++ developers like to code a lot a lot a lot and we are thankful to them for all of the miracles they have .
  54.  
  55. BUT THESE PEOPLE NEED TO UNDERSTAND THE VALUE OF DOCUMENTATION.
  56.  
  57. A developer gets scared of what he sees and hence tries to run off !
  58.  
  59. PLEASE C++ GET A BETTER DOC STYLE
  60.  
  61. SFML is a good example of C++ doc. in C++ :D and i hope some more of these verbose ones occur !!
  62. PLEASE WE NEED MORE UPDATED AND PROPER DOCuMENTATIONS..
  63.  
  64.  
  65.  
  66. urgh
  67.  
  68. </ragequit>
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement