1. 18 Jan, 2021 13 commits
    • Thomas Guillem's avatar
      79b6a343
    • Thomas Guillem's avatar
      libvlc: add media_player metadata listener API · 2651bdb4
      Thomas Guillem authored
      For now, it is only used for propagating loudness measurements.
      2651bdb4
    • Thomas Guillem's avatar
      decoder: fix abort on vout failure · 283145ed
      Thomas Guillem authored
      Don't notify the format changed if the output creation failed.
      
      Regression from 0abed255
      
      Fixes #25387
      283145ed
    • Lyndon Brown's avatar
      puzzle: group in subdirectory · 09b054dd
      Lyndon Brown authored and Steve Lhomme's avatar Steve Lhomme committed
      
      Signed-off-by: Steve Lhomme's avatarSteve Lhomme <robux4@ycbcr.xyz>
      09b054dd
    • Steve Lhomme's avatar
      direct3d11: use a ID3D11Fence to tell when the rendering is done · 61dbb36e
      Steve Lhomme authored
      This is a lot more accurate and wastes a lot less time than the Query approach.
      The D3D11 Fence value is set when the GPU is done doing the previous
      (rendering) commands. Then we can wait in the CPU for this event and return when
      it's done. All decoder/filter commands seem to not have any impact so that's
      really the signal we're looking for to tell the core we're done rendering.
      
      This is only supported on newer mingw toolchains and only on Windows 10
      Creators Update, which should cover pretty much all Win10 installed machines.
      
      Better fixes #21600
      61dbb36e
    • Steve Lhomme's avatar
      direct3d11: rework the rendering wait · 42011b9f
      Steve Lhomme authored
      The core needs to know how long the rendering takes place to estimate when a
      frame needs to be dropped preemptively or not.
      
      So far we waited until the render (plus decoding and filtering?) is done before
      we allowed the picture swap to happen. Now we only wait until (almost) the swap
      date. If we still have to wait, we'll do it after the swap, hoping it will
      still happen in time.
      
      It is reversing the strict waiting (all?) commands issued to be processed,
      including all decoder threads and filters on the ID3D11DeviceContext. We no
      longer allow waiting past the display date and we do the swap when we're told.
      
      We no longer release the ID3D11DeviceContext lock either as it allows more
      commands in and makes the waiting time/performance worse.
      
      We do wait until the initial wait condition is done, if anything to silence
      some D3D11 warnings saying we wanted to wait for something but never got to the
      point it was actually finished. It also keeps the waiting in the display thread
      so it doesn't think it can do more things when it's still busy with the
      previous call. This will allow it do drop frames more accurately.
      
      A cleaner way would be to count the Display call in the time to render of the
      core, but it's not possible as in some case we wait and the work is actually
      finished and in some others we wait and the work is not finished. We can't tell
      the difference in the core.
      
      Fixes #21600
      42011b9f
    • Steve Lhomme's avatar
      transcode: use transcode_video_size_config_apply to get the encoder input format · 2ec4cd4a
      Steve Lhomme authored
      Use it via transcode_encoder_video_set_src() which does a bit more.
      
      As opposed to before we set the output dimensions as the ones from the input,
      not the other way around.
      2ec4cd4a
    • Steve Lhomme's avatar
      transcode: update the encoder input format after we know the last filter output · 9de28aa2
      Steve Lhomme authored
      This is done before the actual encoder that will be used is created.
      9de28aa2
    • Steve Lhomme's avatar
      transcode: use the transcoder config to setup the test input format · 3ff21a41
      Steve Lhomme authored
      Don't use previously set values on the output format which have no good
      significance. The format requested by the user is the combination of source
      format + user configuration.
      
      Set better encoder fmt_out values that the user configuration (which may be 0).
      3ff21a41
    • Steve Lhomme's avatar
      transcode: rework the encoding size computing · fe7b7f15
      Steve Lhomme authored
      The transcode_video_size_config_apply() and transcode_video_scale_apply() calls
      should give consistent results regardless of what width/height were previously
      set on the output video_format_t.
      
      The 16 pixels horizontal alignment was never done since the i_visible_width/height
      was always set. Now we do it on the coded values, not the visible values. In the
      end the encoder should tell which alignment it wants on the input.
      The coded size is deduced from the actual visible sizes that will be used.
      The visible width/height is still forced to the even values. Even though
      it should be up to the encoder to tell if it can't support odd dimensions.
      
      The width/height configured by the user are applied even if there's only one of
      them (fixes Chromecast rescaling), and only if there's no user scaling.
      fe7b7f15
    • Steve Lhomme's avatar
      transcode: use the final converter to apply the scaling · 4c7e81e5
      Steve Lhomme authored
      df0a715f assumed the converter would do the
      scaling, in addition to codec/chroma converters and orientation. But the code
      to do it properly was missing.
      
      We do not update the encoder source format anymore when the static/user filters
      are added. The encoder should still encode at the size requested, regardless of
      the extra filters. It may however use a different input codec/chroma if this
      one wasn't forced.
      
      The converter is always adapting between the decoder output (with the video
      context in the picture) and the encoder input.
      
      Fixes #25362
      4c7e81e5
    • Steve Lhomme's avatar
      transcode: don't reset the video encoder format to the one it was just init with · 94215c33
      Steve Lhomme authored
      transcode_encoder_update_format_in() sets the encoder->fmt_in but the encoder
      was created a few lines above with encoder_tested_fmt_in.
      94215c33
    • Steve Lhomme's avatar
      image: remove always true test · ff95a0e1
      Steve Lhomme authored
      At this stage the whole p_enc->fmt_out.video is initialized to 0 so the test
      will always pass. Later the p_enc->fmt_out.video width/height is even set to
      the input values.
      ff95a0e1
  2. 17 Jan, 2021 1 commit
  3. 15 Jan, 2021 3 commits
  4. 14 Jan, 2021 23 commits