1. 11 Feb, 2019 4 commits
    • Nicolas Dufresne's avatar
      eglimage: Add some more defines · c197d900
      Nicolas Dufresne authored
      This allow building on advertised version of libdrm drm_fourcc.h files.
      Fixes #549
    • Nicolas Dufresne's avatar
      Revert "fix issue" · 9bf6fe00
      Nicolas Dufresne authored
      This reverts commit 5e0c458e.
    • yanle.zhang's avatar
      fix issue · 1de05792
      yanle.zhang authored
    • HoonHee Lee's avatar
      decodebin3: force to pushing custom stream-start when no stream-start in input stream · 8d585ffd
      HoonHee Lee authored
      This is timing issue and it could be observed as below scenario.
      1) parsebin0:src_0 is received EOS.
      2) It is marked to custom EOS and pushed it to multiqueue0:src_0.
      3) parsebin0:src_1 is received EOS and recognize ALL EOS state in multiqueue pre.
      4) It is pushed to multiqueue0:src_1 as regular EOS.
      5) Decodebin3 understand multiqueue pre and post are in ALL EOS when all drained.
      6) Decodebin3 try to send custom stream-start and final EOS to multiqueue all sinkpads.
      In normal case, we could get stored stream-start event from parsebin0:srcpads.
      But we've got NULL stream-start event and it is rarely found.
      Therefore, final EOS is propataged without custom stream-start and it is just handled
      in multiqueue's sink_event and then final EOS is not delivered to multiqueue post
      (e.g multiqueue_src_probe).
      To fallback this symptom, we make manually custom stream-start event and push before
      final EOS.
  2. 08 Feb, 2019 2 commits
  3. 06 Feb, 2019 3 commits
  4. 05 Feb, 2019 1 commit
  5. 04 Feb, 2019 1 commit
    • Guillaume Desmottes's avatar
      videodecoder: remove useless code in negotiate_default_caps() · f5a11645
      Guillaume Desmottes authored
      gst_video_decoder_negotiate_default_caps() is meant to pick a default output
      format when we need one earlier because of an incoming GAP.
      It tries to use the input caps as a base if available and fallback to a default
      format (I420 1280x720@30) for the missing fields.
      But the framerate and pixel-aspect were not explicitly passed to
      gst_video_decoder_set_output_state() which is solely relying on the input format
      as reference to get the framerate anx pixel-aspect-ratio.
      So there is no need to manually handling those two fields as
      gst_video_decoder_set_output_state() will already use the ones from
      upstream if available, and they will be ignored anyway if there are not.
      This also prevent confusing debugging output where we claim to use a
      specific framerate while actually none was set.
  6. 31 Jan, 2019 1 commit
  7. 30 Jan, 2019 3 commits
  8. 29 Jan, 2019 8 commits
    • Thibault Saunier's avatar
    • mrk501's avatar
      audioringbuffer: Fix wrong memcpy address when reordering channels · 36183597
      mrk501 authored
      When using multichannel audio data and being needed to reorder channels,
      audio data is not copied correctly because destination address of
      memcpy is wrong.
      For example, the following command
      $ gst-launch-1.0 pulsesrc ! audio/x-raw,channels=6,format=S16LE ! filesink location=test.raw
      will reproduce this issue if there is 6-ch audio input device.
      This commit fixes that.
      The detailed process of this issue is as follows:
      1. gst-launch-1.0 calls gst_pulsesrc_prepare (gst-plugins-good/ext/pulse/pulsesrc.c)
         1466 gst_pulsesrc_prepare (GstAudioSrc * asrc, GstAudioRingBufferSpec * spec)
         1467 {
         1480   {
         1481     GstAudioRingBufferSpec s = *spec;
         1482     const pa_channel_map *m;
         1484     m = pa_stream_get_channel_map (pulsesrc->stream);
         1485     gst_pulse_channel_map_to_gst (m, &s);
         1486     gst_audio_ring_buffer_set_channel_positions (GST_AUDIO_BASE_SRC
         1487         (pulsesrc)->ringbuffer, s.info.position);
         1488   }
         In my environment, after line 1485 is processed, position of spec and s are
           spec->info.position[0] = 0
           spec->info.position[1] = 1
           spec->info.position[2] = 2
           spec->info.position[3] = 6
           spec->info.position[4] = 7
           spec->info.position[5] = 8
           s.info.position[0] = 0
           s.info.position[1] = 6
           s.info.position[2] = 2
           s.info.position[3] = 1
           s.info.position[4] = 7
           s.info.position[5] = 8
         The values of spec->info.positions equal
      2. gst_audio_ring_buffer_set_channel_positions calls
      3. Arguments of gst_audio_get_channel_reorder_map are
          from = s.info.position
          to = GST_AUDIO_BASE_SRC(pulsesrc)->ringbuffer->spec->info.positions
         At the end of this function, reorder_map is set to
           reorder_map[0] = 0
           reorder_map[1] = 3
           reorder_map[2] = 2
           reorder_map[3] = 1
           reorder_map[4] = 4
           reorder_map[5] = 5
      4. Go back to gst_audio_ring_buffer_set_channel_positions and
         2065       buf->need_reorder = TRUE;
         is processed.
      5. Finally, in gst_audio_ring_buffer_read,
         1821     if (need_reorder) {
         1829           memcpy (data + i * bpf + reorder_map[j] * bps, ptr + j * bps, bps);
         is processed and makes this issue.
    • Sebastian Dröge's avatar
    • Sebastian Dröge's avatar
      rtspconnection: Handle EOF on writev() after checking for all other error conditions · 8a54cc3b
      Sebastian Dröge authored
      Otherwise we would return EOF if nothing was written in any case, even
      if this was actually a case of TIMEOUT or EWOULDBLOCK for example.
      Thanks to Edward Hervey for debugging and finding this issue.
    • Ognyan Tonchev's avatar
      rtspconnection: Fixes for corrupt RTP packets in dispatch_write() · 87a9f2b9
      Ognyan Tonchev authored
      Fixes 2 problems:
      1) Number of unmapped memories does not always match number of mmaped ones in
      2) When dispatch_write() is dispatched second time after an incomplete write,
      already set offsets will not be taken into account, thus corrupt RTP data will
      be sent.
    • Sebastian Dröge's avatar
      rtsp-connection: Make use of new GstRTSPMessage API for directly storing a... · f90dac8d
      Sebastian Dröge authored
      rtsp-connection: Make use of new GstRTSPMessage API for directly storing a body buffer and add API for writing multiple messages
      By doing so we can send a whole GstBufferList and each memory in the
      contained buffers without copying into a single memory area and with a
      single writev() call. This improves performance considerably for
      high-packet-rate streams.
      This depends on https://gitlab.gnome.org/GNOME/glib/merge_requests/333
      to be efficient, otherwise each chunk of memory is a separate write()
    • Sebastian Dröge's avatar
      rtsp-message: Add support for storing GstBuffers directly as body payload of messages · b3c0d8b8
      Sebastian Dröge authored
      This makes it unnecessary for callers to first merge together all
      memories, and it allows API like GstRTSPConnection to write them out
      without first copying all memories together or using writev()-style API
      to write multiple memories out in one go.
      Fixes gstreamer/gst-plugins-base#370
    • Andrew Gall's avatar
  9. 28 Jan, 2019 2 commits
  10. 24 Jan, 2019 1 commit
  11. 22 Jan, 2019 1 commit
  12. 21 Jan, 2019 1 commit
  13. 18 Jan, 2019 3 commits
    • Nicolas Dufresne's avatar
      Revert "alsa: Implement a DeviceProvider" · d64a4b7a
      Nicolas Dufresne authored
      This reverts commit 69c3c316.
      All devices have the same name, they are duplicated with pulseaudio one
      and the provided does not respond to HW being plugged/unplugged. I think
      it's not ready for 1.16.
    • Thibault Saunier's avatar
      alsa: Implement a DeviceProvider · 69c3c316
      Thibault Saunier authored
      Removing gstalsadeviceprobe.[ch] as it was a relique from the 0.10
    • George Kiagiadakis's avatar
      videoaggregator: remove broken rate adjustment · 358ed9f9
      George Kiagiadakis authored
      The start_time and end_time in this context have already
      been adjusted for the input's rate by converting them to running
      time above. What is needed afterwards is to compare these
      with the output's start/stop running time, which also takes
      into account the rate, so we are comparing equal things.
      Multiplying these with the output's rate here is only breaking
      this logic. In most cases the input and output rate is the same,
      so this multiplication effectively reverses the rate adjustment
      that happened while converting to running time, which is why
      we see the video playing with the original rate in tests.
      Fixes #541
  14. 17 Jan, 2019 3 commits
  15. 16 Jan, 2019 3 commits
  16. 14 Jan, 2019 3 commits