Skip to content
GitLab
Switch branch/tag
  1. 18 Jan, 2021 13 commits
    • Thomas Guillem's avatar
      test: media_player: test metadata listener API · 79b6a343
      Thomas Guillem authored
      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
  3. 17 Jan, 2021 1 commit
  5. 15 Jan, 2021 3 commits
  7. 14 Jan, 2021 23 commits

VideoLAN code repository instance