1. 18 Feb, 2019 3 commits
    • Kristofer Bjorkstrom's avatar
      rtspconnection: Fix GError set over the top of a previous GError · 4bc906e8
      Kristofer Bjorkstrom authored
      The function fill_bytes could sometimes return a value greater than zero
      and in the same time set the GError.
      Function read_bytes calls fill_bytes in a while loop. In the special
      case above it would call fill_bytes with error already set.
      Thus resulting in "GError set over the top of a previous GError".
      Solved this by clearing GError when return value is greater than zero.
      Actions are taken depending on error type by caller of read_bytes. Eg.
      with EWOULDBLOCK gst_rtsp_source_dispatch_read will try to read the
      missing bytes again (GST_RTSP_EINTR )
    • Tim-Philipp Müller's avatar
    • Nicolas Dufresne's avatar
      tests: video: Test video format enum stability · fcaf938e
      Nicolas Dufresne authored
      It is really easy to break the API and insert a new video format in the
      middle of the enum instead of at the end. This minimal test should catch
      the most obvious errors. Ideally, this test should be updated after new
      format have been added, so that it won't allow further modification to
      the enumeration API.
  2. 16 Feb, 2019 1 commit
  3. 15 Feb, 2019 1 commit
  4. 13 Feb, 2019 1 commit
  5. 11 Feb, 2019 3 commits
  6. 08 Feb, 2019 2 commits
  7. 06 Feb, 2019 3 commits
  8. 05 Feb, 2019 1 commit
  9. 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.
  10. 31 Jan, 2019 1 commit
  11. 30 Jan, 2019 3 commits
  12. 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 #370
    • Andrew Gall's avatar
  13. 28 Jan, 2019 2 commits
  14. 24 Jan, 2019 1 commit
  15. 22 Jan, 2019 1 commit
  16. 21 Jan, 2019 1 commit
  17. 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
  18. 17 Jan, 2019 3 commits
  19. 16 Jan, 2019 1 commit