This kills 100 wakeups per seconds.

In principle, this avoids a possible event loss. I am not sure if the
NAV PCI handling is thread-safe here (but it's no worse than before).

We may want to factor some of that marshalling into libvlc later on.

This solves a potential event loss for close events
(especially with the RC interface)

Spotted by courmisch.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

NSMenuItems still exist when libvlc_Quit is called, and thus some items are likely not autoreleased before vlc quits. Set all representedObjects for all menu's to null so that the menuitems no longer retain any of the vlc objects.

When building the menu's, autorelease the VLCAutoGeneratedMenu's instead of retaining. The NSMenuItem will do a retain/release for the live of the object in the NSMenuItem and thus once the menu's are done using the object, their retaincount will be 0 and they will be dealloc'ed at the end of the EventLoop. (An eventloop is One run of GUI updates you might say).

fixup code handles this now.
Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Fixes following issues using MSVCRT _snprintf:
 - Failure to null terminate all strings
 - Failure to return number of characters that would've been
   printed had the buffer been sufficiently large
 - Failure to accept size = 0 (and str = NULL) to determine
   final output length.

NB, the third issue above is fixed on *some* win32 implementations,
however it is not officially documented as being so.
Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

- avoid mingw problems with %l*
- avoid using %I32 on Win32, since wince doesn't support it
- unify WIN64 and WIN32 cases.
- if malloc were to fail(!), don't allow unfiltered format string
  to get passed to *printf.
  (substitues an error message)
Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Traditionally, MSVCRT has provided vsnprintf as _vsnprintf;
to 'aid' portability/standards compliance, mingw provide a
static version of [v]snprintf that is buggy.

The bug manifests as %lx is treated as a 64bit argument not
32bit, ie consumes two 32bit parameters.  if a %s were to
follow a %lx, bad things can happen.

Solution: Be sure to use the MSVCRT version, at least it
behaves as expected

Additionally, make it a bit more obvious when vlc wrappers
are being called by other wrappers.
Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

For SD, this should allow removal of black bars form the edge of frames.
i_aspect is set to the aspect ratio of the whole frame which may be
greater than that of the clean area.  VLC should then calculate the SAR,
and eventually display a clean area sized picture that is of the correct
aspect ratio.

NB, we do actually know the SAR, but it isn't known if vlc cares at this
point.
Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

The packetizer does a far more thorough job of handling the different
timestamp representations used by vlc
Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Schroedinger now has an api that allows passing in arbitarily aligned
data units (ie, whole encapsuation units), use this rather than attempt
to chunk up the bitstream ourselves.

This new api also enables buffer tagging, where buffers may be tagged
with arbitary data that gets associated with the next picture to
commence at or after the start of the buffer.  This removes the need
for the TLBs and associated accounting.
Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>