Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
* If afc is bigger than packet, abort
* If afc doesn't contain any payload, the size shall be equal to 183
(the afc takes up all the room of the packet)
* If afc contains payload, the size shall be lower than 182
(there must be at least one byte of payload)
Previously we would just log the issue (since it's "shall" in the
specifications and not "must"), but we can also abort at this point
and consider the data as invalid.
If any of the above happen, it would anyway result in further invalid
data.
|
|
It seems to be legacy DVD LPCM ... but needs further checks
https://bugzilla.gnome.org/show_bug.cgi?id=703913
|
|
|
|
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=655622
|
|
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=704760
|
|
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=706574
|
|
Due to function decorations on Windows AC_CHECK_LIB can't be used to check for bz2.
https://bugzilla.gnome.org/show_bug.cgi?id=465924
|
|
And remove a check which was done before
|
|
The prog-map property of mpegtsmux only allows you to group pids together in a program.
The program number set in the PAT/PMT tables cannot be set explicitly.
This patch will set the program number according to the prog-map.
If a program id of 0 is given, the first vacant program number starting from 1 will be used.
https://bugzilla.gnome.org/show_bug.cgi?id=697239
|
|
|
|
|
|
While it was a great idea, various g-i based bindings don't support
GArray with entries greater than sizeof(gpointer) :(
So let's just make everybody happy by just using GPtrArray.
And since we're breaking the API, also rename the various descriptor fields
to no longer have the descriptor_ prefix.
It does cost a bit more in terms of memory/cpu usage, but makes it usable
from bindings.
|
|
It appears that the Logitech C920 sometimes drops the next
to last segment of RAW aux data contained within the MJPEG
container. H264 data that is multiplexed with in the same
container does not appear to be affected. This appears to
be a bug in the Logitech C920 firmware and uvch264src should
not error out in this case.
Sometimes it can take 24 hours of continuous streaming for
the problem to occur, but sometimes it takes only a couple
of hours.
https://bugzilla.gnome.org/show_bug.cgi?id=706276
|
|
if input is 30000/1001 ... use 24000/1001 as the output fixated framerate
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=705999
|
|
Properly fall through the cases without re-assigning the level to
the wrong value.
https://bugzilla.gnome.org/show_bug.cgi?id=706369
|
|
Store it until we know what our caps are.
|
|
|
|
|
|
|
|
Do state changes from sink to src. Fixes race condition in
pull mode test where the source will start up and push buffers
to queue/identity or aiffparse before the main thread has
managed to set them to playing yet.
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=705993
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=705993
|
|
Fix push mode by handling sink events (CAPS, SEGMENT) properly.
https://bugzilla.gnome.org/show_bug.cgi?id=705993
|
|
Also only re-issue the caps update if the part of the config that
changed is one we care about.
|
|
Spotted by gstblub@gmail.com.
https://bugzilla.gnome.org/show_bug.cgi?id=706091
|
|
For SegmentTemplate elements containing a startNumber attribute, the
`number' member of GstMediaSegments should be offset by the value of
startNumber; however, this is not currently the case. As a result, the
first URI(s) requested by the download loop will be wrong.
This commit ensures that segment numbers will be offset by startNumber
when one is present in a SegmentTemplate element.
https://bugzilla.gnome.org/show_bug.cgi?id=705661
|
|
When using a SegmentTemplate element, the timestamps of the buffers
output by dashdemux are incorrect, causing problems downstream.
The reason is that GstMediaSegment start times are calculated (in
gst_mpdparser_get_chunk_by_index) by multiplying segment index by
segment duration and then scaling the result according the `timebase'
attribute from the MPD. However, the segment duration is already a
GstClockTime (i.e., it has already been scaled according to the timebase
from the MPD and converted to a nanosecond value), so multiplying it by
the segment index will give the correct timestamp without the need for
any further scaling.
https://bugzilla.gnome.org/show_bug.cgi?id=705679
|
|
|
|
implementations
|
|
|
|
instead of random data. Reported by Marco Micheletti on
gstreamer-devel.
|
|
message->src might be a GstPad. Observed during gst-inspect-1.0 -a
|
|
|
|
Some streams had wrong values for the stream_id_extension, make sure
we only remember the valid ones.
For streams with PES_extension_field_length == 0, assume there's nothing
else.
For streams that state they have a TREF extension but don't have enough
data to store it, just assume it was produced by a non-compliant muxer
and skip the remaining data.
Only store remaining data in stream_id_extension_data instead of storing
data we already parse.
|
|
Fixes crashes due to invalid unrefs.
https://bugzilla.gnome.org/show_bug.cgi?id=705957
|
|
And remove length/data updates (we use the header size just below to
properly set them).
Based on feedback from Stas Sergeev <stsp@list.ru>
https://bugzilla.gnome.org/show_bug.cgi?id=657343
|
|
We always provided 0 as the offset and never used the returned value.
Based on feedback from Stas Sergeev <stsp@list.ru>
https://bugzilla.gnome.org/show_bug.cgi?id=657343
|
|
We only check input from the API user with g_return_*_if_fail().
Internal sanity checks should use g_assert() instead, which is
disabled by default for releases.
|
|
|
|
This prevents locking on startup when a stream only has a single buffer
for one of the streams and mssdemux decides to push an EOS event right
after it.
|