id3mux and id3v2mux expect GST_TAG_ID3V2_FRAME type to be stored in a
GstSample and not a buffer, which is also needed because we can't
attach extradata/caps to buffers any more. These are private tags
no one should be poking at, and also the extra info is missing.
https://bugzilla.gnome.org/show_bug.cgi?id=707765
Mark terms such as "planar", "packed", and "palettized" as
translatable, and re-arrange strings a bit to make them
better suited for translation.
Also fix bug in yuv descriptions, one plane is packed, more
is planar (or semi-planar).
https://bugzilla.gnome.org/show_bug.cgi?id=707789
Just flushing the bus doesn't work here for some reason, so set
playbin to NULL state, which seems to clear all error state and
makes sure we do play the next playable song and don't pick up
'ghost' error messages from previous files on the bus.
Some of the fastpath function can only work with aligned widht/height
so make sure we check this as well when choosing a fastpath.
Add fastpath for I420/YV12 -> BGRx
This commit adds detection of the "dash" and "avc3" compatible brands
in qt_type_find.
Amendment 2 of ISO/IEC 14496-15 (AVC file format) is defining a new
structure for fragmented MP4 called "avc3". The principal difference
between AVC1 and AVC3 is the location of the codec initialisation
data (e.g. SPS, PPS). In AVC1 this data is placed in the initial MOOV
box (moov.trak.mdia.minf.stbl.stsd.avc1) but in AVC3 this data goes in
the first sample of every fragment (i.e. the first sample in each mdat
box). The principal reason for avc3 is to make it easier for client
implementations, because it removes the requirement to insert the
SPS+PPS in to the decoder pipeline every time there is a representation
change.
https://bugzilla.gnome.org/show_bug.cgi?id=702004
Increase the number of temporary lines that we need, it is possible that the
up and downsampling offsets are out of phase and that we need to keep some
extra lines around. Also copy the unhandled output lines for the next round
instead of overwriting them.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=706823
Windows Media Video Screen (WMV Screen) are video formats that
specilise in screencast content. This provides a correct media type
for them instead of just video/x-asf-unknown.
A successful gst_dmabuf_mem_map must always increment the mmap count.
Otherwise the first gst_dmabuf_mem_unmap will unmap the memory and all
other user will access unmapped memory.
https://bugzilla.gnome.org/show_bug.cgi?id=706680
