It avoids rebuilding cmake 3.17.0, meson 0.54.2 and nasm 2.14 at every
build, speeding up the CI.

This becomes redundant with the previous change.

The stream output is called from multiple threads without
synchronisation, notably at least one thread per ES decoder. Normally,
the stream output instance (sout_instance_t) lock will serialise all
calls to the first stream output module instance (sout_stream_t) in the
stream output chain.

This is not practical if there is also concurrency within the chain.
One notable case is when the select/duplicate module is used in filter
mode and one of the select/duplicate target is threaded, e.g.:

 #duplicate{dst=transcode{...},dst=transcode{...}}:std{...}

In that example, the standard output can be called from both transcode
filters.

To solve this, add a lock for each element in the stream output chain.
Alternatively, we could drop filter mode from select/duplicate, leaving
only the (more common) output mode where duplicate is the last element
in the chain.

strictly weak ordering was not preserved with same pts pkts
(assumed a & b were compared in stored order)

Causing corruption with non standard split IFrames as < 2^16
PES size.

refs #25380

ThreadDisplayPreparePicture() can call ThreadChangeFilters() which will reset
displayed.current (via ThreadFilterFlush) so we need to ensure we don't release
it again after a call to ThreadDisplayPreparePicture().

The code using the is_held (outside the vout thread doing things on the vout)
is still blocked by the cond_timedwait but doesn't need an extra boolean for
that.

The wait for is_held is done earlier as it's more logical to wait for outside
calls to be finished blocking the vout thread loop before actually waiting for
a deadline, which may have passed anyway. In both cases (before and now), new
calls to control_Hold() were/are blocked until control_Pop() is done.

Moving this code also mimicks better the way control_Hold/control_Release are
using is_held and the (shared) wait condition. Once the timed wait is done we
are back to a (signaled) state similar to control_Release.

Invert the values as it means the opposite.
Explain why we keep forced_awake true while there are pending mouse events in
the FIFO.

This might also be handled out of control.c. The wake could just cause the
cond_timedwait to exit but the state to ignore the deadline and keep popping
mouse states from the control FIFO could be handled in video_output.c.

As the termination may happen during ThreadDisplayPicture we also check if we
have to terminate the thread when it is done. We don't want to handle the
deadline and wait for nothing.

To terminate the thread ASAP we need to set the terminate flag (from whatever
thread) and wake up the loop if it was waiting for anything.

The control_Pop still waits for the is_held to be false, meaning other threads
doing things on the vout to be done. This was done when the vout thread loop
was just receiving VOUT_CONTROL_TERMINATE to signify the end of the thread.

The terminate state is always reported by vout_control_Pop(). So we don't wait
anymore until all mouse events are processed before the TERMINATE command is
handled.

The command array is now a mouse state array.

It doesn't push a dummy command anymore but sets an internal flag.

If the control FIFO is terminated we don't wait for new commands before
returning. There might be some pending mouse commands before the TERMINATED
command (that is now removed).

When vout_control_Dead() was called the vout thread was already dead. But
before that call happened, other threads may have been pushing commands in the
control FIFO. So this call only helped a bit.

In the end all previously enqueued commands will be ignored anyway. The control
FIFO will just be cleaned a few lines later in vout_Release().

We pass the mouse data directly to vout_control_PushMouse(). No need to know
about vout_control_cmd_Init in video_output.c. It doesn't create commands
anymore.

The numbers we read are frame numbers. There's a start and a stop frame number,
not just the start frame. The stop frame number was discarded so far as the
next start frame.
(based on http://web.archive.org/web/20070210095721/http://www.volny.cz/aberka/czech/aqt.html
and libavformat)

Alaric Senat authored 4 years ago and Steve Lhomme committed 4 years ago

Signed-off-by: Steve Lhomme <robux4@ycbcr.xyz>

By default the index contains cluster positions with an unknown timestamp. In
some cases this unknown timestamp may end up being the only one we know (yet)
for some tracks. It's not a valid timestamp and should not overwrite valid
"last DTS" we found on other tracks when finding the PCR.

In the end we always end up never sending the PCR which ends up not starting
playback, which ends up not feeding more DTS, which ends up never getting any
PCR.

Konstantin Pavlov authored 4 years ago and Alexandre Janniaux committed 4 years ago

We build cddb --without-iconv so it's not needed anyway

Signed-off-by: Alexandre Janniaux <ajanni@videolabs.io>

Don't notify the format changed if the output creation failed.

Regression from 0abed255

Fixes #25387

Lyndon Brown authored 5 years ago and Steve Lhomme committed 4 years ago

Signed-off-by: Steve Lhomme <robux4@ycbcr.xyz>

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

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

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.

This is done before the actual encoder that will be used is created.

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).

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.

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

transcode_encoder_update_format_in() sets the encoder->fmt_in but the encoder
was created a few lines above with encoder_tested_fmt_in.

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.

Dave Nicolson authored 4 years ago and Felix Paul Kühne committed 4 years ago

The video and audio checkboxes are now in alignment, to achieve this two vertical constraints were adjusted on the video codec view. This also fixes some layout issues that would appear in Xcode after making changes and as a result, a misplaced="YES" attribute has been removed.

Signed-off-by: Felix Paul Kühne <felix@feepk.net>

Lyndon Brown authored 4 years ago and Steve Lhomme committed 4 years ago

Signed-off-by: Steve Lhomme <robux4@ycbcr.xyz>

Zhao Zhili authored 4 years ago and Steve Lhomme committed 4 years ago

This is a best-effort solution. Seek may not work as expected.

Signed-off-by: Steve Lhomme <robux4@ycbcr.xyz>