Add a method to get the offset and scale values to transform the color values of
a format to their normalized [0.0 .. 1.0] range. This is usually required as
the first step of a colorspace conversion.
Add an unpack option to specify what to do with the least significant bits of
the destination when the source format has less bits than the destination. By
default we will now copy the most significant bits of the source into the least
significant bits of the destination so that the full color range is represented.
Add an option to leave the extra destination bits 0, which may be faster and
could be compensated for in the element algorithm.
The x/y values are meant to be signed.
This bug was introduced by 76c0881549
Conflicts:
gst-libs/gst/video/video-blend.c
gst-libs/gst/video/video-blend.h
When the ringbuffer gets restarted (like in setcaps), we *will* have
to resync against the new values.
Without this we end up blindly assuming the new samples align to the
old ones.
... which is supposed to align with WAVEFORMATEX, but has confusing
names compared to the last 2 fields in the latter (and still
misses 1 field compared to the latter).
If we're in continuous mode where we'll play the entire CD from
start to finish, send a TOC event downstream so any downstream
muxers can write a TOC to indicate where the various tracks
start and end.
The DATE field may contain dates, partial dates, or dates with
time. Store the result in GST_TAG_DATE_TIME, so we can express
properly which fields are present or not, and can store the
time if there is one, and can serialise and deserialise the
tag without loss of information and without making up
information that's not there.
Instead of using short YYYY-MM-DD form we will store
long YYYY-MM-DDTHH:MM:SS+TS date and time.
According to this documentation we can do it:
http://wiki.xiph.org/VorbisComment#Date_and_time
This datetime format is needed by apps where more information
is needed. For example voice, meeting recording, etc.
https://bugzilla.gnome.org/show_bug.cgi?id=677712
Check that we have a valid output_state before attempting to use it to calculate
the duration of a buffer. It is possible that we don't have a state yet, for
example when we are dropping the first buffers.
Make sure the frame deadline was set before calculating the
max_decode_time. Fixes problems with ffmpeg skipping frames when
it doesn't need to, when the input doesn't have full timestamping
(divx in avi)
