1. 29 Aug, 2008 1 commit
  2. 27 Aug, 2008 2 commits
  3. 13 Aug, 2008 1 commit
  4. 11 Aug, 2008 1 commit
  5. 06 Jul, 2008 2 commits
    • Rémi Denis-Courmont's avatar
      Protocol names are localized. · 870a36bb
      Rémi Denis-Courmont authored
      There are real-life cases. There may also be differences in punctuations
      and character sets. Besides the VLC core will anyway apply gettext to
      these strings, so they are translatable in any case...
    • Felix Paul Kühne's avatar
      l10n string fixes · 62ec2259
      Felix Paul Kühne authored
      Note that _protocol abbreviations_ and friends are not localisable!
  6. 05 Jul, 2008 3 commits
  7. 03 Jul, 2008 1 commit
  8. 15 Jun, 2008 2 commits
  9. 11 Jun, 2008 4 commits
  10. 31 May, 2008 1 commit
  11. 27 May, 2008 1 commit
  12. 26 May, 2008 1 commit
  13. 21 May, 2008 1 commit
  14. 08 May, 2008 1 commit
  15. 04 May, 2008 1 commit
  16. 03 May, 2008 3 commits
  17. 01 May, 2008 1 commit
  18. 14 Apr, 2008 1 commit
  19. 08 Mar, 2008 1 commit
  20. 04 Mar, 2008 3 commits
  21. 02 Mar, 2008 3 commits
  22. 28 Feb, 2008 1 commit
  23. 26 Feb, 2008 1 commit
    • 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).
  24. 28 Jan, 2008 1 commit
  25. 23 Jan, 2008 1 commit
  26. 16 Jan, 2008 1 commit
    • damienf's avatar
      vlc security: As i've seen very little improvement on that front, i've decided... · 658b4f83
      damienf 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}"