This reverts commit 96e4ab18c2cf9876f6c031b9aba6282d0bd45a93.
You should have asked first. And you would have been told "no",
because it causes people on development branches to do a huge
amount of extra work.
Add xray effect. Maps luma to a negative, slightly cyan tinted, curve,
applies some light gaussian blur and multiplies it with its sobel edges. Not
sure about the name, likely to change. Probably still needs some tuning.
Tests for PAT, PMT, and NIT
Creates a new table, and populates it with descriptors.
Parses the newly created tables, and checks the data.
Creates a GstMpegTsSection from the tables, and packetize the sections.
The packetized section data is byte-wise compared to a static byte array
https://bugzilla.gnome.org/show_bug.cgi?id=723953
The thread that calls the success/failure callback can be the
same that is adding/removing the element as the IDLE probe can
happen instantly if the pad is not 'busy'.
This required moving some checks for the callback counter around
as well as removing some pad pushes from the main test thread as
they were made useless after the IDLE pad probe was fixed in core
by commit 0324358ebc
* stream-start-id is mandatory at the beginning, so add that to the
gdp headers
* caps must be sent before new segment, invert the order from legacy
0.10 code
And fix the tests as a ref is now kept for those buffers that compose
the header
Most of the tests weren't updated after the sticky events order
and stream start. Fix that and refactor those tests check that
are the same to some common functions.
Those functions still don't actually test the content but at
least now they are in a single place and can be improved
without replication
Commit 6af387cd5a made h264parse
strip a leading 0x00 byte from some output scenarios. This broke
tests as bs_to_nal test expects one more byte on the output.
Fix this by comparing the output with the expected stripped version,
too.
When outputting in AVC3 stream format, the codec_data should not
contain any SPS or PPS, because they are embedded inside the stream.
In case of avc->bytestream h264parse will push the SPS and PPS from
codec_data downstream at the start of the stream, at intervals
controlled by "config-interval" and when there is a codec_data change.
In the case of avc3->bytstream h264parse detects that there is
already SPS/PPS in the stream and sets h264parse->push_codec to FALSE.
Therefore avc3->bytstream was already supported, except for the stream
type.
In the case of bystream->avc h264parse will generate codec_data caps
from the parsed SPS/PPS in the stream. However it does not remove these
SPS/PPS from the stream. bytestream->avc3 is the same as bytestream->avc
except that the codec_data must not have any SPS/PPS in it.
|--------------+-------------+-------------------|
|stream-format | SPS in-band | SPS in codec_data |
|--------------+-------------+-------------------|
| avc | maybe | always |
|--------------+-------------+-------------------|
| avc3 | always | never |
|--------------+-------------+-------------------|
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.
https://bugzilla.gnome.org/show_bug.cgi?id=702004
