Please leave the FFmpeg revision fixed and only update it if you sure that your newer one is stable, nice and cool.

The jam-based target is removed by this commmit.

Finally upgrade the build target to a native one (in favour of a jam-based one, whose support is to be reomoved by Xcode's next release)

Regrettably, this adds yet another file where to change the VLC version

Unsure about my sanity now though.

Send as much data as the packetization AND the MTU allow

Killing a the parent within vlc_object_attach looks like an awful hack
anyway. And there was a documented race condition, in addition to the
dead lock.

This reverts all the pluses from 99e8bcdd. vlc_object_kill() takes the
structure lock internally (through vlc_list_child()), so this would
always deadlock. Besides, we cannot take any lock within the structure
lock, lest we forbid any thread from ever manipulating the objects
structure while holding a lock on any object.
AFAIK, only object reference spins and the messages bank can be locked
within the structure lock.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Use the correct type for the buffer

Add support for Cinepak, Indeo Video IV, DVC Pro 100, DVC Pro HD and Pixlet (the last one being Mac-only)

(as per RFC queue'd draft-ietf-avt-rtp-vorbis-09).
Not tested against other implementations, and some pretty bad PTS
issues. RTP only provides us with a valid PTS for the first frame in a
packet, and we don't know the length of each frame, so, hmm... I wonder
how to compute the PTS for non-first frames...

Also, we would need either an SDP parser to use Vorbis (properly) as a
dynamic payload type, or to use a proprietary static payload type and a
proprietary static RTP clock frequency.

filter. Since filter destruction is always requested by the subpicture
core itself, we already have the subpicture lock so no need to lock.

work.

compiler needs the prototype).

Signed-off-by: Rafaël Carré <funman@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Use less CPU : reduction of the number of iteration when it draws the frame. Some non-code corrections of the previous patch.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>