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)
Interpolating the timestamps from the picture numbers
does more harm than good, getting it wrong in a lot of
cases (especially reverse playback). Removing it in favour
of simply incrementing the timestamps until there's
something better
Use g_list_free_full instead of walking lists twice when freeing
them.
Remove pointless clause in gst_video_decoder_chain that doesn't
actually have any effect.
Other changes to make the code slightly more like the 0.11
version.
Move processing of the gather list into the flush_parse function.
Add a last ditch attempt to apply timestamps to outgoing buffers
when walking backwards through decoded frames. Requires that each
gathered region has at least one timestamp.
Make sure to remove decoded packets from the decode list when
they are sent - otherwise the list just grows on each cycle, with
more and more frames being decoded and then clipped away.
Break out of the processing loop early on a bad flow return to make
seeking more responsive.
Use the gst_video_decoder_clip_and_push_buf function in reverse
mode, instead of pushing all buffers arbitrarily.
A couple of small efficiency gains in the list handling, by moving
list elements directly and not reallocating, and by reversing
and concatenating the gather list instead of moving it one node
at a time.
Rename the gst_video_decoder_do_finish_frame function to
gst_video_decoder_release_frame.
