1. 02 Aug, 2021 3 commits
  2. 29 Jul, 2021 2 commits
  3. 28 Jul, 2021 9 commits
  4. 27 Jul, 2021 8 commits
  5. 26 Jul, 2021 3 commits
  6. 23 Jul, 2021 6 commits
    • He Junyan's avatar
      codecs: h264decoder: let print_ref_pic_list_b print the correct list name. · f9d7b708
      He Junyan authored
      The print_ref_pic_list_b now not only needs to trace the ref_pic_list_b0/1,
      but also need to trace the ref_frame_list_0_short_term. We need to pass the
      name directly to it rather than an index to refer to ref_pic_list_b0/1.
      Part-of: <!2425>
    • He Junyan's avatar
      codecs: h264dec: Fix a typo in construct_ref_field_pic_lists_b. · eef90676
      He Junyan authored
      The array sort of ref_frame_list_0_short_term has some typo. The
      typo makes this list not in the POC ascend order and generate wrong
      decoding result for interlaced streams.
      Part-of: <!2425>
    • Devarsh Thakkar's avatar
      kmssink: Fix fallback path for driver not able to scale scenario · d2a7b763
      Devarsh Thakkar authored
      When driver return error on update plane request, kmssink
      disables the scaling and retries plane update.
      While doing so kmssink was matching the source rectangle dimensions
      to the target rectangle dimensions which were calculated
      as per scaling but this is incorrect, instead what we want here is
      that target rectangle dimensions should match the source rectangle
      dimensions as scaling is disabled now and so we match result
      rectangle dimensions with source rectangle dimensions.
      While at it, also match the result rectangle coordinates for
      horizontal and vertical offsets with source rectange coordinates,
      as since there is no scaling being done so no recentering is
      Part-of: <!2415>
    • He Junyan's avatar
      videoparsers: vp9: Need to process the first frame even not key. · e9d0d19f
      He Junyan authored
      Some cut VP9 streams begin with a non key frame. The current code
      just bail out the parse_process_frame() if not a key frame. Because
      of this, we do not set the valid caps before we push the data of the
      first frame(even this first frame will be discarded by the downstream
      decoder because it is not a key frame).
      The pipeline such as:
      gst-launch-1.0 filesrc location=some.ivf ! ivfparse ! vp9parse !
        vavp9dec ! fakesink
      will get a negotiation error and the pipeline can not continue. The
      correct behaviour should be: the decoder discard the first frame and
      continue to decode later frames successfully.
      So, when the parse does not have valid stream info(should be the first
      frame case), we should continue and report caps.
      Part-of: <!2427>
    • Nirbheek Chauhan's avatar
      audiolatency: Handle audio buffers with invalid duration · 0bde6bf7
      Nirbheek Chauhan authored
      pipewiresrc outputs audio buffers without a valid duration, so we need
      to calculate it manually in that case.
      Upstream issue: pipewire/pipewire#1438
      Part-of: <!2419>
    • He Junyan's avatar
      va: h265dec: Do not assign the frame->output_buffer until output_picture. · 99636cd1
      He Junyan authored
      We may need to drop the slices such as RASL pictures with the NoRaslOutputFlag, so
      the current picture of h265decoder may be freed. We should not assign the frame->
      output_buffer too early until we really output it. Or, the later coming slices will
      allocate another picture and trigger the assert of:
        assertion 'frame->output_buffer == NULL' failed
      Part-of: <!2421>
  7. 22 Jul, 2021 2 commits
    • Edward Hervey's avatar
      tsdemux: Handle PCR-less streams · a79a756b
      Edward Hervey authored
      Some programs specify a PCR PID but don't actually store any PCR values, or are
      way too far apart.
      In order to gracefully handle those situations, we will queue up to a certain
      amount of pending buffers before deciding to give up on that PCR PID and not use
      any (i.e. using DTS/PTS values as-is)
      Fixes #1629
      Part-of: <!2422>
    • He Junyan's avatar
      va: H265: Add odd bit depth and chroma depth in get_rtformat. · 0c8d41b8
      He Junyan authored
      In H265, the stream may have odd bit depth such as 9 or 11. And
      the bit depth of luma and chroma may differ. For example, the
      stream with luma depth of 8 and chroma depth of 9 should use the
      10 bit rtformat as the decoded picture format.
      Part-of: <!2420>
  8. 21 Jul, 2021 7 commits
    • He Junyan's avatar
      codecs: h264dec: Improve the algorithm for low latency mode. · 13020562
      He Junyan authored
      In low_latency mode, try to bump the picture as soon as possible
      without the frames disorder:
      1. We can directly output the continuous non-reference frame.
      2. Consider max_num_reorder_frames, which is special useful for
         I-P mode.
      3. Consider the leading pictures with negative POC.
      4  Output small POC pictures when non-reference frame comes.
      4. Output the POC increment<=2 pictures. This is not 100% safe,
         but in practice this condition can be used.
      Part-of: <!2373>
    • He Junyan's avatar
      codecs: h264dec: Add help function of dpb_set_max_num_reorder_frames. · 573d3f5b
      He Junyan authored
      The max_num_reorder_frames can be useful for bump check. We store it
      in the DPB and no need for the decoder now.
      Part-of: <!2373>
    • He Junyan's avatar
      codecs: h264dec: Add a flag to record whether picture is reference. · be223ad3
      He Junyan authored
      The picture->ref field will change from time to time according to decoder's
      state and reference sliding window. We need another flag to record whether
      the picture is a reference picture when it is created, and this can help
      the bumping check.
      Part-of: <!2373>
    • He Junyan's avatar
      codecs: h264dec: Change the order of dpb_add and dpb_bump. · b4e38874
      He Junyan authored
      The current behavior is different from the SPEC. We should check
      and bump the DPB or drain the DPB before we insert the current
      picture into it. This may cause the output picture disorder.
      Part-of: <!2373>
    • He Junyan's avatar
      codecs: h264dec: Modify the DPB need bump check. · f1df1207
      He Junyan authored
      Accord to spec, we should not add the current picture into the DPB
      when we check whether it needs to bump, so the checks of the IDR and
      the "memory_management_control_operation equal to 5" are no needed.
      And the spec also says that the DPB only needs to bump when there is
      no empty frame buffer left(We handle the IDR cases in other places).
      We need to follow that and the max_num_reorder_frames is useless.
      We also minus 1 in has_empty_frame_buffer because the current frame
      has not been added yet.
      Part-of: <!2373>
    • He Junyan's avatar
    • He Junyan's avatar
      codecs: h264dec: Set picture to a small poc when mem_mgmt_5. · 23b15aa5
      He Junyan authored
      When current frame memory_management_control_operation equal to 5, that
      means we need to drain the dpb and the current picture act as an IDR frame.
      So it should have smaller poc than the later pictures to ensure the output
      Part-of: <!2373>