Automatic update of common submodule

From 3429ba6 to ec1c4a8

Automatic update of common submodule

From dc70203 to 3429ba6

omx: Fix spelling mistake found by lintian: s/Seperate/Separate/

Implement a new custom recursive mutex type and fix locking in callbacks so that in-context calls are allowed.

According to the OMX specification, implementations are allowed to call
callbacks in the context of their function calls. However, our callbacks
take locks and this causes deadlocks if the unerlying OMX implementation
uses this kind of in-context calls.

A solution to the problem would be a recursive mutex. However, a normal
recursive mutex does not fix the problem because it is not guaranteed
that the callbacks are called from the same thread. What we see in Broadcom's
implementation for example is:

- OMX_Foo is called
- OMX_Foo waits on a condition
- A callback is executed in a different thread
- When the callback returns, its calling function
  signals the condition that OMX_Foo waits on
- OMX_Foo wakes up and returns

The solution I came up with here is to take a second lock inside the callback,
but only if recursion is expected to happen. Therefore, all calls to OMX
functions are guarded by calls to gst_omx_rec_mutex_begin_recursion() / _end_recursion(),
which effectively tells the mutex that at this point we want to allow calls
to _recursive_lock() to succeed, although we are still holding the master lock.

omx: Add hack to disable setting roles to components.

Conflicts:

omx/gstomx.c

omxvideodec: Implement no-empty-eos-buffer hack, as in omxvideoenc.

Conflicts:

omx/gstomxvideodec.c

omxvideodec: Fix coding style in the drain-may-not-return hack code

omx: Fix trivial debug print bug

omxvideodec: Add hack for Ducati components not returning from drain

This happens on the Galaxy Nexus, and causes the pipeline to hang waiting
endlessly for a drain. The hack replaces the wait with a wait + 500ms timeout.

omx: Fix deadlock between ending a flush and the event handler

gst_omx_port_set_flushing() calls OMX_FillThisBuffer at the end of a flush
without releasing the port lock, and this can cause a deadlock with the
EventHandler. This patches fixes this by dropping the lock for the duration of
the fill buffer call.

omx: Update video encoder/decoder base classes from gst-plugins-bad

configure: Modernize autotools setup a bit

Also we now only create tar.bz2 and tar.xz tarballs.

Automatic update of common submodule

omxaudioenc: Use gst_buffer_extract() to copy the input buffer data to the OpenMAX buffer

Fix relative/absolute path glitch

Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@collabora.com>

Port to Gst 0.11

Enable building with Android's buildsystem

This change adds prelimary buildsystem hooks to
build gst-omx with the Android buildsystem. Like
the rest of GStreamer's Android hooks, the process
relies on the availability of androgenizer. A tool
developed by Collabora to automatically generate
Android.mk files from within the auto* setup.

Androgenizer is currently available at:

http://cgit.collabora.com/git/user/derek/androgenizer.git/

basevideocodec: Don't use G_TYPE_REGISTER_BOXED() yet

This would require GLib 2.26.

omxaudioenc: Add hack for encoder components that don't allow empty EOS buffers

omxvideoenc: Fix deadlock when using the EOS hack

omxvideoenc: Remove workaround for basevideocodec bug

omxvideodec: Remove workaround for basevideocodec bug

basevideo: Make GstVideoFrame a reference counted boxed object

...and also clear all existing frames when resetting the decoder or encoder.

omx: Add hack for encoder components that don't allow empty EOS buffers

omxaacenc: Generate and set codec_data on the caps for raw AAC

basevideoencoder: handle failures in start() and stop()

basevideoenc: do not try to calculate latency from an unknown framerate

It'll divide by zero, and latency is unknown for an unknown framerate.

Fixes an assert in the schroenc test.

https://bugzilla.gnome.org/show_bug.cgi?id=657419

basevideoencoder: Only make the header buffer metadata writable, not the buffer

basevideoencoder: Fix handling of force-keyunit events

omxaudioenc: Don't forward EOS events immediately but let all other events be handled by the base class

Previously this logic was inversed, which did not make any sense at all.

omxaudioenc: Use correct timestamp, duration and filled length for the EOS buffers

omxvideodec: Use correct timestamp, duration and filled length for the EOS buffers

omxvideoenc: Use correct timestamp, duration and filled length for the EOS buffers

omx: Improve debugging of buffer handling

omxvideoenc: Drop EOS events in ::finish()

The event will be forwarded downstream from the srcpad
loop function after the last buffer was generated by the
component. Forwarding it after ::finish() will use the
sinkpad streaming thread and does not guarantee that
the encoder is completely drained.

omxvideodec: Properly drop frames due to QoS

Instead of finishing them they should be passed to drop(), which
will then send QoS messages.

omxh264enc: Add support for resending headers after a forced-keyframe

basevideoencoder: Pass the all-headers field of the force-key-unit event to the subclass

basevideoencoder: Implement full support for the new force-key-unit event

Including support for the running-time and count fields.

basevideoencoder: Use new force-keyunit event API from gst-plugins-base

basevideoencoder: Adjusting padding is not required for -bad libraries

basevideoencoder: Move some fields to the private part of the instance struct

basevideoencoder: Make headers metadata writable before pushing downstream

The timestamp, duration, etc of the headers has to be changed.

basevideoencoder: Push the downstream force-keyframe event after the next keyframe

Even if the corresponding GstVideoFrame doesn't have the is_sync_point
flag set.

basevideoencoder: Don't push an upstream force-keyunit event downstream

basevideoencoder: Add initial support for the all-headers field of the force-keyframe event

See bug #607742.

basevideodecoder: some more debug logging

basevideodecoder: add API to drop a frame and post a QoS message on the bus

https://bugzilla.gnome.org/show_bug.cgi?id=640017

API: gst_base_video_decoder_drop_frame()

docs: fix comment in gst_base_video_decoder_get_max_decode_time() docs

basevideodecoder: fix weird event list handling

Get rid of weird code that copies a list manually, taking
ownership of the elements and then frees the old list. Instead,
just take over the old list entirely. (If the intent was to
reverse the list, one could use g_list_reverse() instead).

Then, push events in the list out from last to first (since they
were prepended as they came in) instead of just pushing out the
last in the list and leaking the others.

omxaudioenc: Use audio base classes from gst-plugins-base instead of having our own copies

omxaudioenc: First set ports to flushing before waiting for the srcpad streaming thread to finish

omxvideoenc: First set ports to flushing before waiting for the srcpad streaming thread to finish

omxvideodec: First set ports to flushing before waiting for the srcpad streaming thread to finish

omx: Only disabling of a port is like flushing, enabling is like unflushing

omx: Enabling/disabling a port is also like flushing

The component returns all buffers to us and shouldn't get any
new buffers passed anymore.

omxaudioenc: Signal the drain GCond even if downstream returned an error

omxvideoenc: Signal the drain GCond even if downstream returned an error

omxvideodec: Signal the drain GCond even if downstream returned an error

basevideoencoder: Only call ::reset once in READY->PAUSED

omxaudioenc: Shutdown component in PAUSED->READY and deallocate buffers

omxvideoenc: Shutdown component in PAUSED->READY and deallocate buffers

omxvideodec: Shutdown component in PAUSED->READY and deallocate buffers

omxvideoenc: Set force_keyframe to FALSE after handling it

There's no reason why the base class should forward the event
further downstream if we already handled it and will insert a
keyframe.

omxvideodec: Always push buffers downstream, even if we didn't find a corresponding GstVideoFrame

omx: Fix debug level for flushing in wrong state from ERROR to DEBUG

It's not really an error and doesn't matter at all if flush is called
when the component is not running.

omxh264enc: Detect bytestream stream format and don't put SPS/PPS into the caps for this format

omxvideoenc: Add vfunc for handling the output frames

This can be used by subclasses to override the buffer flags
or to handle some frames differently than the default behaviour.

omxvideodec: Don't release buffers twice if dropping because of QoS

omx: Add XXX to the nOffset reset hack comment for QCOM

omxaudioenc: Make srcpad caps setting threadsafe

omxvideoenc: Make srcpad caps setting threadsafe

omxvideodec: Make srcpad caps setting threadsafe

omxaudioenc: Make the srcpad task and the sinkpad streaming thread handling threadsafe

omxaudioenc: Always flush the ports and make sure no processing is happening in ::flush

This fixes a race condition that happened when seeking
very often in a short period of time.

omxvideoenc: Always flush the ports and make sure no processing is happening in ::reset

This fixes a race condition that happened when seeking
very often in a short period of time.

omxvideoenc: Fix minor race condition when draining after upstream signalled EOS

omxaudioenc: Improve EOS handling

If downstream return UNEXPECTED we should still signal the
drain cond because nothing will trigger this again later.

omxvideoenc: Improve EOS handling

If downstream return UNEXPECTED we should still signal the
drain cond because nothing will trigger this again later.

omxaudioenc: Improve debugging of EOS and draining

omxvideoenc: Improve debugging of EOS and draining

omxvideodec: Log if acquiring buffer for EOS failed

omxvideodec: The component is not started in READY

omxaudioenc: No need to signal the drain cond when going from READY to PAUSED

Also the component is not started in READY

omxvideoenc: No need to signal the drain cond when going from READY to PAUSED

Also the component is not started in READY.

omxvideodec: Always flush the ports and make sure no processing is happening in ::reset

This fixes a race condition that happened when seeking
very often in a short period of time.

omxvideodec: Fix minor race condition when draining after upstream signalled EOS

omxvideodec: Improve EOS handling

If downstream return UNEXPECTED we should still signal the
drain cond because nothing will trigger this again later.

omxvideodec: Improve debugging of EOS and draining

omxvideodec: The component is not started already when going from READY to PAUSED

omxvideodec: No need to signal the drain cond when going from READY to PAUSED

omx: Always reset buffer flags for output ports, even in flushing/error state

omxvideodec: Improve debugging in case of QoS-related frame drops

omxvideoenc: Release the video codec stream lock before acquiring an input buffer

Otherwise the srcpad task might block on this lock and
no buffers ever become available again.

omxaudioenc: Release the audio encoder stream lock before acquiring an input buffer

Otherwise the srcpad task might block on this lock and
no buffers ever become available again.

omxvideodec: Release the video codec stream lock before acquiring an input buffer

Otherwise the srcpad task might block on this lock and
no buffers ever become available again.

omxaudioenc: Don't try to drain the component after EOS

And don't send EOS twice in any case. This most likely
will cause the component to not output it again and
is not necessary anyway.

omxvideoenc: Don't try to drain the component after EOS

And don't send EOS twice in any case. This most likely
will cause the component to not output it again and
is not necessary anyway.

omxvideodec: Don't try to drain the component after EOS

And don't send EOS twice in any case. This most likely
will cause the component to not output it again and
is not necessary anyway.

omxvideodec: Implement dropping of too late frames via QoS