Most V4L2 ioctls like try_fmt will adjust input fields to match what the
hardware can do rather then returning -EINVAL. As is docmented here:
http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-fmt.html
EINVAL is only returned if the buffer type field is invalid or not supported.
So upon requesting V4L2_FIELD_NONE devices which can only do interlaced
mode will change the field value to e.g. V4L2_FIELD_BOTTOM as only returning
half the lines is the closest they can do to progressive modes.
In essence this means that we've failed to get a (usable) progessive mode
and should fall back to interlaced mode.
This commit adds a check for having gotten a usable field value after the first
try_fmt, to force fallback to interlaced mode even if the try_fmt succeeded,
thereby fixing get_nearest_size failing on these devices.
https://bugzilla.gnome.org/show_bug.cgi?id=735660
They may have been modified by the ioctl even if it failed. This also makes
the S_FMT fallback path try progressive first, making it consistent with the
preferred TRY_FMT path.
https://bugzilla.gnome.org/show_bug.cgi?id=735660
We return EOS after the first buffer, and GstPad will make sure now that we
won't get any other buffer afterwards until a flush happens. No need to check
for it ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=735581
FLV documentation stipulates that timestamp must start at zero.
In order to respect this rule, keep the first timestamp around
and offset the timestamp from this value. This allow for longer
recording time in presence of timestamp that does not start
at 0 already.
https://bugzilla.gnome.org/show_bug.cgi?id=731352
The tags in FLV are DTS. In audio cases, and for many video format this makes
no difference, but for AVC with B-Frames, PTS need to be computed from
composition timestamp CTS, with PTS = DTS + CTS.
https://bugzilla.gnome.org/show_bug.cgi?id=731352
The jitterbuffer shouldn't force clock-rate on its sink pad, this will cause a negotiation issue since rtpssrcdemux doesn't have the clock-rate and doesn't add it to the caps. The documentation states that the clock-rate can either be specified through the caps or through the request-pt-map signal, so we must remove clock-rate from the pad templates and we must accept the GST_EVENT_CAPS if the caps don't have the clock-rate.
https://bugzilla.gnome.org/show_bug.cgi?id=734322
udpsrc gtk-doc documentation refers to sockfd and closefd properties which has
been removed. This patch replaces those references to socket and close-socket
respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=734987
The old default timescale of 1 millisecond produces irrational
numbers for a lot of framerate/audio-packet-duration multiples.
1/1800 is a nicer number, as it tends to produce better fractions
and therefore slightly higher accuracy overall
Change the way the output framerate is calculated
to ignore the first sample (which is sometimes truncated
in my testing) and use the new gst_video_guess_framerate()
function to recognise common standard framerates better.
Remove the code that was sorting the first 20 sample
durations and then ignoring the result.
Commit 2b9493b5 broke this in two ways: a) we should only
pass duration queries in TIME format upstream (or at least
not those in DEFAULT or BYTE format), and b) we mustn't
overwrite the default value of 'res' from TRUE to FALSE
and not set it again later. This led to bogus durations
being reported for FLV playback from file, because TIME
queries would fail (as 'res' had been set to FALSE) and
parsers then do a BYTE query as fallback and try to
guesstimate something in return, which of course goes
horribly wrong since the BYTE size returned is for the
muxed file.
When changing the properties to not be in passthrough mode anymore,
we will only accept caps we can process ourselves, potentially causing
a not-negotiated error.
https://bugzilla.gnome.org/show_bug.cgi?id=720345
Must pass an action-if-not-found argument to
PKG_CHECK_MODULES or it will error out when
it can't find the module requested. Also fix
AC_CHECK_LIB usage, extra libs argument was
in the wrong place.
This makes sense in DASH reverse playback, where the upstream dashdemux
will download DASH segments in reverse order, but push their buffers
forward to qtdemux and mark each segment start as DISCONT. This needs
to be forwarded downstream to the parser/decoder, otherwise it won't work.
https://bugzilla.gnome.org/show_bug.cgi?id=734443
When writing out a trak with an edit list, make sure the
overall file duration is also updated to reflect the
lengthening of the stream.
Add some more debug to qtdemux to warn about streams that
are longer than the file and get truncated.
