Enabling passthorugh mode is causing multiple issue:
For nal aligned multiresoluton streams, passthrough mode
make h264parse unable to advertise the new resoultions.
Also causing issues while parsing MVC streams which have two
separate layers (base-view and non-base-view).
This fix is only a temporary workaround.
For MVC, proper fixes needed in many places:
(handle prefix nal unit, handle non-base-view slice nal extension,
fix the picture_start detection for multi-layer-mvc streams etc)
https://bugzilla.gnome.org/show_bug.cgi?id=758656
Remove calls to gst_pad_has_current_caps() which then go on to call
gst_pad_get_current_caps() as the caps can go to NULL in between. Instead just
use gst_pad_get_current_caps() and check for NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=759539
Set fallback channel layout on files with more than two
channels. Not clear where to retrieve the real layout from
or what the default layout is for AIFF files, the spec
only seems to specify some layout for up to 6 channels
and the file in question doesn't have a CHAN chunk.
https://bugzilla.gnome.org/show_bug.cgi?id=676425
This fixes a couple of issues regarding the output of (request)
per-program pads output:
We would never push out PAT sections (ok, that was one reallly stupid
mistake. I guess nobody ever uses this feature ...).
In the case where the PMT section of a program was bigger than one
packet, we would only end up pushing the last packet of that PMT. Which
obviously results in the resulting stream never containing the proper
(complete) PMT.
The problem was that the program is only started (in the base class)
after the PMT section is completely parsed. When dealing with single-program
pads, tsparse only wants to push the PMT corresponding to the requested
program (and not the other ones). tsparse did that check by looking
at the streams of the program...
... but that program doesn't exist for the first packets of the initial
PMT.
The fix is to use the base class program information (if it parsed the
PAT it already has some information, like the PMT PID for a given program)
if the program hasn't started yet.
In addition to the fact that it's a sane thing to do for multi-source
pad elements, it also avoids the situation where just using a request
pad (and not the main static pad) would result in the processing
stopping.
tsdemux is not able to handle negative playback rates.
But in mpegtsbase, the same check is not being done.
added a check to not handle negative rate while seeking unless
the same is handled upstream.
https://bugzilla.gnome.org/show_bug.cgi?id=758516
Since commit b77f8e172a the new value
assigned to mview_mode hasn't been used. That commit changed the following
"if" check to an "else if", which means the original value of mview_mode
is used.
When converting from avc to byte-stream, there will not be any codec_data
in the src caps. Remove it before the equality check to avoid sending caps
events downstream on every SPS/PPS change.
https://bugzilla.gnome.org/show_bug.cgi?id=761014
If we have a stream that contains an unchanging SPS/PPS for every video frame,
we don't need to to constantly query downstream for it's supported caps if the
current caps are compatible with the negotiated caps.
https://bugzilla.gnome.org/show_bug.cgi?id=761014
When the framesize is not specified, we try and calculate a size from
the strides and offset information. This was done with the sum of
offsets + the size of the last frame. That is just wrong method. We also
need to account for video meta that may be flipping two planes. An
example is if you convert I420 to YV12 by flipping the two last offsets.
https://bugzilla.gnome.org/show_bug.cgi?id=760270
To make parser work with image having non-standard strides, plane
offsets or with padding between images.
For now, since element doesn't check for videometa, we can't directly
push buffers when these properties are set so it convert the frame
in the pre_push_buffer method to remove any custom padding.
https://bugzilla.gnome.org/show_bug.cgi?id=760270
Allows the subclass to completely override the chosen src caps.
This is needed as videoaggregator generally has no idea exactly
what operation is being performed.
- Adds a fixate_caps vfunc for fixation
- Merges gst_video_aggregator_update_converters() into
gst_videoaggregator_update_src_caps() as we need some of its info
for proper caps handling.
- Pass the downstream caps to the update_caps vfunc
https://bugzilla.gnome.org/show_bug.cgi?id=756207
When sps data is NULL, the buffer allocated and mapped is not being freed.
In this scenario there is no need to allocate the buffer as we are supposed to return NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=761070
It's useful enough already to be used in other elements for audio aggregation,
let's give people the opportunity to use it and give it some API testing.
https://bugzilla.gnome.org/show_bug.cgi?id=760733
It's not enough to have timeout or event based VPS/SPS/PPS information
sent in RTP packets. There are some scenarios when key frames may appear
more frequently than once a second, in which case the minimum timeout
for "config-interval" of 1 second for sending VPS/SPS/PPS isn't enough.
It might also be desirable in general to make sure the VPS/SPS/PPS is
available with every keyframe (packet loss aside), so receivers can
actually pick up decoding immediately from the first keyframe if
VPS/SPS/PPS is not signaled out of band.
This commit adds the possibility to send VPS/SPS/PPS with every key frame.
This mode can be enabled by setting "config-interval" property to -1. In
this case the payloader will add VPS, SPS and PPS before every key (IDR)
frame.
https://bugzilla.gnome.org/show_bug.cgi?id=757892
The MPEG standard (ISO-13880-1) says the reserve bits need to be set
to one (2.1.64). This is causing transport streams to fail validation
on some systems.
https://bugzilla.gnome.org/show_bug.cgi?id=760127
This works usually in this place, unless the compiler optimizes things in
interesting ways in which case it causes stack corruption and crashes later.
The compiler in question here is clang with -O1, which seems to pack the stack
a bit more and causes writing to the guint as pointer to overwrite map.memory,
which then later crashes during unmapping of the memory.
While encoding the frame in ASCII mode, per component four bytes are needed
and after every 20 bytes, a \n will be added. So the calculation should be
size = size * (4 + 1 / 20). This should exclude the header being written.
Since header is also being included in the calculations, memory mishandlings
are happening.
https://bugzilla.gnome.org/show_bug.cgi?id=759520
rename gst-launch --> gst-launch-1.0
replace old elements with new elements(ffmpegcolorspace -> videoconvert, ffenc_** -> avenc_**)
fix caps in examples
https://bugzilla.gnome.org/show_bug.cgi?id=759432
The edit rate is only supposed to be the same in a source package, but there
might be multiple source packages with the same essence container. As such
just comparing the body/index SID is not sufficient.
This was completely broken before and could only work on a very constrained
set of files. After these changes it should work except for situations where
PTS != DTS, which is not handled at all in mxfdemux currently.
https://bugzilla.gnome.org/show_bug.cgi?id=759118
According to S377-1-2009c 9.2 the local tags must not be resolved from the
primer pack, which as a result means that there can't be any other tags than
statically assigned ones.
This is to support byte-stream decoder that does not remember the
PPS/SPS after a flush. This is not needed by all decoders, but is
harmless for those that do remember.
https://bugzilla.gnome.org/show_bug.cgi?id=758405
The order in which program switch must happen is:
1) drain all data on old pads (but don't push EOS)
2) add new pads (but don't push any data on them)
3) Push EOS and remove old pads
4) Start pushing data on new pads
There was one caveat in this implementation, which is that when
we activate a sparse pad (step 2) we would push a GAP event. The problem
is that, while being an event, it is actually *data*.
We therefore need to make sure pushing those GAP event is done at the step
we start pushing data.
https://bugzilla.gnome.org/show_bug.cgi?id=750402
Before we add any streams, make sure we drain all streams. This ensures
there's consistency that only "new" data will be pushed on buffers once
the new pads are added
https://bugzilla.gnome.org/show_bug.cgi?id=750402
When changing programs, the order of events needs to be the following:
* add pads from new program
* send EOS on old pads
* remove old pads
* emit 'no-more-pads'
Previously tsdemux was not doing that, and was first deactivating and
removing old pads before adding new ones.
We fix this by allowing subclasses of mpegtsbase to be able to handle
themselves the deactivation of programs. In this case tsdemux will
properly deactivate it once it has activated the new program.
https://bugzilla.gnome.org/show_bug.cgi?id=750402
The videoframe-audiolevel element acts like a synchronized audio/video "level"
element. For each video frame, it posts a level-style message containing the
RMS value of the corresponding audio frames. This element needs both video and
audio to pass through it. Furthermore, it needs a queue after its video
source.
https://bugzilla.gnome.org/show_bug.cgi?id=748259
0x04 signifies a MPEG elementary stream but according to RP2008, 0x10 should
be used for a h264 byte-stream. This also fixes compatibility of our files
with ffmpeg.
If packet->payload_unit_start_indicator is true and pointer 0, there is no
discontinuity check. Therefore there could be a previous section not complete
that need to be cleared.
https://bugzilla.gnome.org/show_bug.cgi?id=758010
The values of channel_mapping are copied by gst_codec_utils_opus_create_caps ()
but it doesn't free or take ownership of the g_new0 allocated memory. This
needs to be freed before going out of scope.
CID 1338692
buf surely isn't NULL inside the block conditional to a buffer size bigger
than (G_MAXUINT16 - 3). Plus gst_buffer_unref() checks if the buffer is
NULL and does nothing if it is.
CID 1338693
If tsdemux never receives data for a stream, the corresponding pad will never
be added and stream->active will remain FALSE. When the stream is removed, the
pad will not be unreffed and will be leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=757873
The current implementation for detecting the resolution changes
on key frames is based on vp8 bitstream alignment. Avoid this
width and height parsing for vp9 bitstream, which requires proper
frame header parsing inorder to detect the resolution change (Fixme).
https://bugzilla.gnome.org/show_bug.cgi?id=757825
It is up to the element handling the seek to send flush events
downstream, otherwise we end up with a situation where upstream
would get unexpected GST_FLOW_FLUSHING
The Onvif Streaming Specification specifies that the NTP timestamps
in the Onvif extension header indicaes the absolute UTC time associated
with the access unit. But by using running time we can not achieve that,
since a frame's running time depends on the played interval, whether a
non-flushing is done, etc. Instead we have to use the stream time.
https://bugzilla.gnome.org/show_bug.cgi?id=757688
It is now possible to update the currently used ntp-offset with a
custom serialized downstream event. The element will read the ntp-offset
property when doing the state transition from READY to PAUSED and
use that offset until it receives a "GstNtpOffset" event, which also
has a "ntp-offset" attribute in that it's structure. In case the
property is not set and no event has been received, the element will
guess the npt-offset with help of the clock. If no clock can be
retrieved, the element will error out and stop the data flow.
The same event is also used for updating the D/E-bits in the RTP
extension header. The discont flag in a buffer can be set whenver a
live/network source looses a frame, but that is not the type of
discontinuity that the onvif extension header should reflect. The
header is mainly used for playback of a track concept, in which
gaps can be present, and it's those kind of gaps that should be
highlighted with the D- and E-bits.
https://bugzilla.gnome.org/show_bug.cgi?id=757688
If a buffer or a buffer list is cached, no events serialized with the
data stream should get through. The cached buffers and events should
be purged when we stop flushing.
https://bugzilla.gnome.org/show_bug.cgi?id=757688
Otherwise those symbols can conflict with external libraries when
linking everything statically for mobile targets.
Use the gst_gm_ prefix, short for gst geometric math.
https://bugzilla.gnome.org/show_bug.cgi?id=756882
