omx: Fix includes to properly work with the 1.0 releases

Automatic update of common submodule

From a72faea to a942293

omx: Update port definition when changing some port setting

omx: Rename from libgstopenmax.so to ligstomx.so for consistency

omx: Add a method to send message

omx: Atomic ops are not required anymore for the reconfiguration

omx: Fix some memory leaks and suboptimal locking

omxvideoenc: Don't forget to unmap frame in error cases

omxvideoenc: Fix copying of the video frames to the OMX buffers

omxvideodec: Fix copying of the video frames from the OMX buffers

omx: Implement new approach for locking that should solve all deadlocks on RPi

No mutex is locked while calling any OpenMAX functions anymore
and everything from the OpenMAX callbacks is inserted into a message
queue and handled from outside the callbacks.

Also there's only a single mutex and condition variable per component
now for handling anything from OpenMAX callbacks and a single mutex
for keeping our component/port state sane.

omxvideodec: Set the OMX buffer nFilledLength field properly

omxrecmutex: Fix another race condition when two threads are trying to lock for recursion at the same time

omxrecmutex: Fix yet another race condition that resulted in deadlocks

omx: Fix another race condition in the recursive mutex

Between lock() and begin_recursion() it was possible for another thread to
try to do a recursive_lock(). This would block because the mutex was already
locked(), but not ready for recursive locking yet. unlock() would never
happen in the original thread because it was waiting for the other thread
to finish first.

Happened on the Raspberry Pi.

omxrecmutex: Fix a small race condition when unlocking a non-recursive lock

omx: Fix ununsed variable compiler warning

omx: No need to start the srcpad task in ::start() already

It will be started properly after the caps are set.

omxvideodec: OMX_ErrorNoMore is no error and just means we ended iteration

omx: Improve debug output

omxvideodec: Don't forget to free a GList

omxvideodec: Map OMX_COLOR_FormatYUV420PackedPlanar to I420 too

This is used on the Raspberry Pi.

omxvideodec: During negotiation of the output format make sure we use the correct OpenMAX format

omxvideodec: If negotiation fails this could also mean that the component can't do it at this point yet

omxvideodec: Improve format negotiation a bit

Don't leak caps and make sure to fixate caps.

omx: Also initialize nStep field of the OMX structures

omx: Initialize struct version with the OMX version we compiled with

omxvideodec: Extract data from the input buffer, not the codec data

omx: Use has_suffix() instead of has_prefix() for the Broadcom hack

tools: Add tool to list all components and their roles

omx: Add hack to load and initialize libbcm_host.so

Needed on the Raspberry Pi. Patch based on a patch by
George Kiagiadakis <george.kiagiadakis@collabora.com>

configure: Add configure option to pack OpenMAX structures

This is required to set to 4 for the Raspberry Pi for example.

configure: Require GStreamer 1.0.0

omx: Initialize structures to version 1.1.2

config: Add raspberry-pi configuration in a different directory

raspberry: Add a gstomx.conf for the Raspberry Pi

omx: Fix some compilation errors caused by circular includes

Automatic update of common submodule

From 6bb6951 to a72faea

omx: Fix refcount problem with frames being dropped because of decoder bugs

omx: Update to new GLib thread API

omx: Use open/close vfuncs

omx: Handle video meta correctly

omx: Port to video base classes from -base

omx: gst_element_class_set_details_simple() -> set_static_metadata()

Automatic update of common submodule

From 6c0b52c to 6bb6951

Automatic update of common submodule

From 4f962f7 to 6c0b52c

omx: fix debug statement

omx: use recursive_lock inside set_last_error(), since this function may be called from an event handler

Automatic update of common submodule

From 668acee to 4f962f7

Automatic update of common submodule

From 94ccf4c to 668acee

omx: fix plugin name for new GST_PLUGIN_DEFINE API

Automatic update of common submodule

From 98e386f to 94ccf4c

omx: Update for allocation query API changes

omx: Fix compilation after gst_pad_start_task() API changes

Automatic update of common submodule

From 03a0e57 to 98e386f

Automatic update of common submodule

From 1fab359 to 03a0e57

Automatic update of common submodule

From f1b5a96 to 1fab359

Automatic update of common submodule

From 92b7266 to f1b5a96

Automatic update of common submodule

From ec1c4a8 to 92b7266

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