Skip to content
Snippets Groups Projects
  1. Aug 28, 2013
  2. Aug 27, 2013
  3. Aug 26, 2013
  4. Aug 22, 2013
  5. Aug 21, 2013
  6. Aug 20, 2013
  7. Aug 19, 2013
  8. Aug 18, 2013
  9. Aug 16, 2013
  10. Aug 14, 2013
  11. Aug 13, 2013
    • Edward Hervey's avatar
      b4674205
    • Edward Hervey's avatar
      baseparse: Add a property to disable passthrough · 3c49b5d2
      Edward Hervey authored
      In some specific cases (like transmuxing) we want to force the element
      to actually parse all incoming data even if the element deems it is not
      necessary.
      
      This property simply ignores requests from the element to enable passthrough
      mode which results in processing always being enabled.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=705621
      3c49b5d2
    • Thiago Santos's avatar
      dataqueue: add gst_data_queue_push_force · 581c4297
      Thiago Santos authored
      Adds a variant of the _push function that doesn't check the queue limits
      before adding the new item. It is useful when pushing an element to the
      queue shouldn't lock the thread.
      
      One particular scenario is when the queue is used to serialize buffers
      and events that are going to be pushed from another thread. The
      dataqueue should have a limit on the amount of buffers to be stored to
      avoid large memory consumption, but events can be considered to have
      negligible impact on memory compared to buffers. So it is useful to be
      used to push items into the queue that contain events, even though the
      queue is already full, it shouldn't matter inserting an item that has
      no significative size.
      
      This scenario happens on adaptive elements (dashdemux / mssdemux) as
      there is a single download thread fetching buffers and putting into the
      dataqueues for the streams. This same download thread can als generate
      events in some situations as caps changes, eos or a internal control
      events. There can be a deadlock at preroll if the first buffer fetched
      is large enough to fill the dataqueue and the download thread and the
      next iteration of the download thread decides to push an event to this
      same dataqueue before fetching buffers to other streams, if this push
      locks, the pipeline will be stuck in preroll as no more buffers will be
      downloaded.
      There is a somewhat common practice in dash streams to have a single
      very large buffer for audio and one for video, so this will always
      happen as the download thread will have to push an EOS right after
      fetching the first buffer for any stream.
      
      API: gst_data_queue_push_force
      
      https://bugzilla.gnome.org/show_bug.cgi?id=705694
      581c4297
    • Sebastian Dröge's avatar
    • Tim-Philipp Müller's avatar
Loading