Flv does not support various channels in AAC stream format, for example
flvdemux detect an audio channels of 2(stereo) when the AAC really is 1(mono).
https://bugzilla.gnome.org/show_bug.cgi?id=797275
When a truncated FLV is provided and processed in pull mode, we
may endup trying to pull passed EOS, causing a rather confusing
warning as the pull offset is an integer overflow.
https://bugzilla.gnome.org/show_bug.cgi?id=787795
This code basically skip over codec_data with empty payload. In
this case, the codec_data variable is the size of the header for
the CODEC part of Video Tag. The remaining is supposed to be the
H.264 codec data, hence should not be empty.
https://bugzilla.gnome.org/show_bug.cgi?id=787795
The FLV header cannot be trusted to indicate video or
audio presence, as the comments already mention. Don't
delay pushing tags waiting for streams that might never
appear.
Tags are now pushed immediately after they change:
- After parsing an onMetaData script object
- After negotiating caps on a pad
https://bugzilla.gnome.org/show_bug.cgi?id=768440
In other words, gst_pad_get_current_caps should never return NULL
in a pad-added callback from the demuxer.
Added tests for the two special cases with AAC and H.264 where this
would happen every time.
https://bugzilla.gnome.org/show_bug.cgi?id=763780
Previously we were setting new caps with the same content for every H264 or
AAC codec_data we found in the stream, spamming everything and causing
renegotiations.
Instead delay creating the caps until we read the codec_data from the stream,
or fail if we get normal data before the codec_data.
AAC raw caps and H264 avc caps always need codec_data, setting caps on the pad
without them is going to make negotiation fail most of the time. Even if we
later set new caps with the codec_data, that's usually going to be too late.
https://bugzilla.gnome.org/show_bug.cgi?id=746682
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
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.
Decoder complains about "notification: Invalid mode encountered.
The stream is corrupted" though, even if it works, so there's
probably something wrong with the generated codec headers.
