1. 13 Jan, 2021 1 commit
    • Jan Schmidt's avatar
      baseparse: Don't return more data than asked for in pull_range() · 867bfb84
      Jan Schmidt authored
      Even when pulling a new 64KB buffer from upstream, don't return
      more data than was asked for in the pull_range() method and then
      return less later, as that confused subclasses like h264parse.
      Add a unit test that when a subclass asks for more data, it always
      receives a larger buffer on the next iteration, never less.
      Fixes #530
      Part-of: <!733>
  2. 06 Jun, 2020 2 commits
    • Jan Schmidt's avatar
      baseparse: Fix upstream read caching · 177d0fa1
      Jan Schmidt authored
      When running in pull mode (for e.g. mp3 reading),
      baseparse currently reads 64KB from upstream, then mp3parse
      consumes typically around 417/418 bytes of it. Then
      on the next loop, it will read a full fresh 64KB again,
      which is a big waste.
      Fix the read loop to use the available cache buffer first
      before going for more data, until the cache drops to < 1KB.
      Fixes #518
    • Jan Schmidt's avatar
      baseparse: Fix typo · 0f91868e
      Jan Schmidt authored
  3. 15 Feb, 2020 2 commits
  4. 20 Mar, 2019 1 commit
  5. 28 Nov, 2018 1 commit
    • KimTaeSoo's avatar
      baseparse: Use buffer from short reads instead of pulling again · bf1979e5
      KimTaeSoo authored
      baseparse internally uses a 64kb buffer for pulling data from upstream.
      If a 64kb pull is failing with a short read, it would previously pull
      again the requested size.
      Doing so is not only inefficient but also seems to cause problems with
      some elements (rawvideoparse) where the second pull would fail with EOS.
      Short reads are only allowed in GStreamer at EOS.
      Closes gstreamer/gstreamer#294
  6. 31 Aug, 2018 1 commit
  7. 24 Jun, 2018 1 commit
  8. 05 Jun, 2018 1 commit
    • Edward Hervey's avatar
      baseparse: Ensure seqnum consistency · d34f0460
      Edward Hervey authored
      We need all relevant events of a segment to have consistent seqnum:
      If we are push-based and create a new segment, use the same seqnum
      as the upstream event.
      If we are pull-based, use the seqnum of that newly created segment
      event everywhere
  9. 30 May, 2018 1 commit
  10. 13 Apr, 2018 1 commit
  11. 22 Feb, 2018 3 commits
  12. 25 Aug, 2017 1 commit
    • Tim-Philipp Müller's avatar
      baseparse: fix taglist update spam · 39e21bb6
      Tim-Philipp Müller authored
      We would constantly re-post the taglist because
      posted_avg_rate only gets set to avg_bitrate if
      parse->priv->post_avg_bitrate is true, so if it's
      false the posted rate will always differ from the
      current average rate and we'd queue an update,
      which leads to us spamming downstream and the
      application with taglist updates.
      Fix this by only queuing an update if the average
      rate will actually be posted.
      These taglists updates could cause expensive
      operations on the application side, e.g. in Totem.
  13. 22 Jun, 2017 1 commit
  14. 20 Jun, 2017 1 commit
  15. 22 Mar, 2017 1 commit
  16. 27 Jan, 2017 1 commit
  17. 26 Jan, 2017 1 commit
    • Julien Isorce's avatar
      baseparse: correctly handle non-flush seek · b2c05cac
      Julien Isorce authored
      Otherwise when seeking/looping to the start when reaching the end,
      the sink waits for the duration of the stream. So the user hears
      nothing for the duration of the stream before it actually loop again.
      See example attached to the bug for that.
      Existing test:
      gst-plugins-good/tests/icles/test-segment-seeks foo.flac
      Without the patch the user hears a crack/cut at each seek.
  18. 28 Dec, 2016 1 commit
  19. 15 Nov, 2016 2 commits
    • Jan Schmidt's avatar
      baseparse: Fix previous commit · 2e579a7c
      Jan Schmidt authored
      Check the correct segment format value.
      parse->segment.format is the format we're outputting in,
      not the upstream format. Use parse->priv->upstream_format instead,
      and make sure it's set in pull mode.
    • Jan Schmidt's avatar
      baseparse: Restrict query/convert responses when demuxing · d81c0aec
      Jan Schmidt authored
      If the parser is not parsing a raw elementary stream, restrict
      the position, duration and conversion query replies to
      things we can sensibly answer about - especially don't do
      random conversions to/from bytes.
  20. 10 Nov, 2016 2 commits
  21. 02 Nov, 2016 1 commit
  22. 01 Nov, 2016 1 commit
    • Tim-Philipp Müller's avatar
      baseparse: fix draining with less data than min frame size available · 2e278aeb
      Tim-Philipp Müller authored
      baseparse would pass whatever is left in the adapter to the
      subclass when draining, even if it's less than the minimum
      frame size required. This is bogus, baseparse should just
      discard that data then. The original intention of that code
      seems to have been that if we have more data available than
      the minimum required we should pass all of the data available
      and not just the minimum required, which does make sense, so
      we'll continue to do that in the case that more data is available.
      Fixes assertions in rawvideoparse on EOS after not-negotiated with
      fakesrc sizetype=random ! queue ! rawvideoparse format=rgb ! appsink caps=video/x-raw,format=I420
  23. 27 Aug, 2016 1 commit
  24. 05 Jul, 2016 1 commit
  25. 04 Jul, 2016 1 commit
  26. 07 Jun, 2016 1 commit
  27. 20 Apr, 2016 1 commit
  28. 15 Apr, 2016 1 commit
  29. 14 Mar, 2016 1 commit
  30. 04 Feb, 2016 1 commit
    • Tim-Philipp Müller's avatar
      baseparse: fix stray discont flag set on outgoing buffers in push mode · 78a832eb
      Tim-Philipp Müller authored
      We have no guarantees about what flags are set on buffers we take
      out of the GstAdapter. If we push out multiple buffers from the
      first input buffer (which will have discont set), only the first
      buffer we push out should be flagged as discont, not all of the
      buffers produced from that first initial input buffer.
      Fixes issue where the first few mp3 frames/seconds of data in push
      mode were skipped or garbled in some cases, and the discont flags
      would also trip up decoders which were getting drained/flushed for
      every buffer. This was a regression introduced in 1.6 apparently.
  31. 29 Jan, 2016 1 commit
  32. 08 Dec, 2015 1 commit
  33. 19 Nov, 2015 2 commits