1. 28 Mar, 2008 1 commit
  2. 26 Mar, 2008 1 commit
  3. 03 Mar, 2008 4 commits
  4. 02 Mar, 2008 2 commits
  5. 26 Feb, 2008 2 commits
    • Pierre d'Herbemont's avatar
      misc/objects.c: Don't rely on vlc_object_destroy() to destroy objects, but... · a78e273e
      Pierre d'Herbemont authored
      misc/objects.c: Don't rely on vlc_object_destroy() to destroy objects, but expects vlc_object_release to do it when the refcount goes to zero.
      * Meaning, that when created objects gets a refcount to 1.
      * Destroying is instantaneous and we don't have to poll for a few secondss or so to wait until the object's refcount reach 0.
      * We now track vlc_object_t's mem leaks when libvlc_global is released (Hard error for now, so they don't get unoticed)
      * We fail hard if an object is released with a refcount of 1 without being detached from its parent and its children, to make sure such cases don't go unoticed.
      (make test or make check still pass after that one. VLC is known to leak one object when no module is loaded, this must be fixed).
    • Rémi Duraffort's avatar
      Doxygen documentation · e769bca0
      Rémi Duraffort authored
  6. 25 Feb, 2008 4 commits
  7. 28 Jan, 2008 1 commit
  8. 27 Jan, 2008 1 commit
  9. 24 Jan, 2008 3 commits
  10. 23 Jan, 2008 1 commit
  11. 16 Jan, 2008 1 commit
    • Damien Fouilleul's avatar
      vlc security: As i've seen very little improvement on that front, i've decided... · 658b4f83
      Damien Fouilleul authored
      vlc security: As i've seen very little improvement on that front, i've decided to check in my take on handling the problem of managing harmful options. I'm pretty sure this is going to be very controversial, but I think my approach is quite simple and yet very effective Anyway, my approach makes the following assumptions:
      - most vlc options are considered safe, only a handful are particularily unsafe and need be declared as such in their definition (they mostly deal with writing to an output file or URL)
      - unsafe options are only considered potentially harmful when used as an input option, ie. the ':option' format. Configuration options are always considered safe 'i.e --option' 
      - unsafe options are associated with a global security policy, which dictates how these are handled. At the moment, The policy can be either block, allow or prompt, and is set using the '--security-policy' option (which itself is considered unsafe ;)
      the policy can be set by the user at the command line or in the preferences, it curently defaults to prompt, which is the desirable state for deskop use. However, it can be overriden depending on context, for example, the activex and mozilla will force the security-policy to block regardless of preference settins.
      the code is a bit rough at the moment, but i will optimize/clean it up if the dev community this approach is worth keeping.
      try the following example, and you'll see quickly what i mean:
      ./vlc -vvv <a mrl> :sout=#transcode{vcodec=mp1v,vb=1024,acodec=mpga,ab=192}:standard{mux=ts,dst=vlc-output.ts,access=file}"
  12. 26 Dec, 2007 1 commit
  13. 24 Dec, 2007 1 commit
  14. 22 Dec, 2007 1 commit
  15. 21 Dec, 2007 1 commit
  16. 17 Dec, 2007 5 commits
  17. 16 Dec, 2007 5 commits
  18. 15 Dec, 2007 5 commits