This is disabling the subtitle area "stacking" as it forces the source
subtitle subpicture to be absolute. But absolute subpictures have absolute
coordinates inside the (unscaled) video. They are not meant to be shown
outside of the video area.
Otherwise the SPUs might be stretched based on the estimated stretch of the output.
But we're not going to stretch the video before doing the blending. So the SPU's need to
be placed as if there's no stretching.
The new ES string ID was added initially in the core for playback
scenario allowing the user to have a readable and guaranteed unique
representation of each ES.
Introducing it in stream output will allow users to specify ESes to
stream out filters with more precision than with legacy ES ID.
ES ID has the disadvantage to only be unique per demux, hence, a
multiple demux scenario often provided multiple ES with the same ID.
Strings ID are guaranteed to be unique, regardless of the number of
demuxes the input manages.
This patch only prepare the `Add` wrapper to properly split the addition
of the unique and **non-null** string to the `pf_add` callback. This is
done in that order mainly not to break bisect in the next patches that
implement the ID forwarding logic for stream out filters.
Single `module_unneed` calls aren't enough to properly close encoders as
their disable callbacks are stored independently from the module.
As a side effect, this patch fixes a double-free where the custom
`close` callback was called after the `module_unneed` call in the
encoder destroy function:
```
READ of size 8 at 0x619000050498 thread T10 (vlc-input)
#0 0x7f83c0e72a67 in CloseEncoder ../../modules/codec/x264.c:1523
#1 0x7f83d64b7613 in vlc_encoder_Destroy ../../src/input/decoder_helpers.c:176
#2 0x7f83ccb31986 in transcode_encoder_delete ../../modules/stream_out/transcode/encoder/encoder.c:55
#3 0x7f83ccb53203 in transcode_video_clean ../../modules/stream_out/transcode/video.c:405
#4 0x7f83ccb2f6ac in Del ../../modules/stream_out/transcode/transcode.c:736
#5 0x7f83d679814f in sout_StreamIdDel ../../src/stream_output/stream_output.c:707
#6 0x7f83d6791cc3 in sout_InputDelete ../../src/stream_output/stream_output.c:155
#7 ...
0x619000050498 is located 1048 bytes inside of 1072-byte region [0x619000050080,0x6190000504b0)
freed by thread T10 (vlc-input) here:
#0 0x7f83d73b6388 in __interceptor_free.part.0 (/lib64/libasan.so.8+0xb9388)
#1 0x7f83d6740fcd in vlc_objres_clear ../../src/misc/objres.c:93
#2 0x7f83d640265d in module_unneed ../../src/modules/modules.c:307
#3 0x7f83ccb3f212 in transcode_encoder_video_close ../../modules/stream_out/transcode/encoder/video.c:390
#4 0x7f83ccb331a2 in transcode_encoder_close ../../modules/stream_out/transcode/encoder/encoder.c:188
#5 0x7f83ccb53178 in transcode_video_clean ../../modules/stream_out/transcode/video.c:404
#6 0x7f83ccb2f6ac in Del ../../modules/stream_out/transcode/transcode.c:736
#7 ...
```
`SignalLeavingFrame` returning an error usually means that either the
decoder outputs an inconsistent stream timestamp-wise or that the PCR
sync algorithm had a mistake in its implementation.
Both case shouldn't ignore the error, from that point, the PCR
output should be considered flawed and PCR output from transcode
should be stopped with a proper error message.
Refs #27730
This assertion was too severe and deserve actual runtime handling.
The `pcr_helper` should just fail in case of inconsistent
input/output. This can happen in various case such as bogus encoder or
simply internal error in the `pcr_helper` code.
This patch is making sure the `pcr_helper` user can disable it in case
of failure.
Refs #27730
This patch make it possible to disable the PCR forwarding
synchronisation algorithm as it is still prone to bugs and will likely
fail on wrong encoder outputs.
The PCR forwarding is still enabled by default.
Refs #27730
Previously, we fast-forwarded the PCR values no matter what. This used
to be handy but caused plausible invalid PCR as the fast-forwarded first
PCRs values can't be checked against future encoded DTS.
This patch approach the problem by synthesizing the first PCR as
`VLC_TICK_0` to ensure no following DTS is lower and still giving a
starting point of the stream to the next modules. We also avoid
forwarding PCR values before any input is signaled to the `pcr_sync`
utility, to avoid the exact same issue talked above.
As the pcr_sync utility should not be used in that case. The pcr_helper
and pcr_sync tools are only signaled frames from tracks that are
transcoded.
This allow a normal PCR flow when transcoding effectively does nothing.
Recording the current PCR event being treated by each ES allow to
support tracks being processed far slower than the others.
A typical example is transcoding both video and audio. The video
pipeline will be significantly slower than the audio one causing PCR
events audio-side being reached and marked as "passed" in advance
relatively to the video ones.
By keeping track of the current pcr_event being treated in each ES
metadata, each track is now able to be processed independently from the
others while having the PCR output of the pcr_sync utility still valid
and consistent.
This patch also removes the previous method that was both flawed (using
the invalid `last_dts == VLC_TICK_INVALID` as a triggering condition)
and CPU intensive (crawling up the pcr_events list to check the DTS
every time).
We must check that the es recorded dts before the pcr has already been
reached by a previous frame output before decreasing the number of es
still holding a non-reached dts.
Fast-forwarding a PCR means that the pcr_sync immediately tells the API
user that he can send it in the case there is no frame currently being
watched.
This happen in three scenarios:
- The first SetPCR call is always fast-forwarded because no data
should have entered the pcr_sync yet.
- The stream has a "data-hole" and no frames enters it (most usual
case being subtitles) while PCR keeps coming. This ensure PCR values
are still forwarded even when the frame queue is empty.
- The encoder has no delay. Ie: A frame is immediately encoded and
returned. All PCR values must then be forwarded.
The last point here wasn't handled correctly due to bad implementation
and was a blocker for no-delay encoder (subtitles or some audio ones).
Now, we check if the frame input and output are on the same page before
queuing a PCR event and if it's the case, the PCR value is simply
fast-forwarded.
A following commit will add test cases for this usage.
Some encoders have different output frame count than input.
This can be true and completely valid for audio encoders for instance,
where several output frames contains the same amount of samples as the
input frame that entered the encoder. For instance:
```
+-------+ +---------+ +---+ +---+
| F | => | Encoder | => | F | -> | F |
+-------+ +---------+ +---+ +---+
```
Fixes#27336#27492#27639
Ilkka Ollakka
Steve Lhomme
Rémi Denis-Courmont
Alaric Senat
Soham Gupta
Alexandre Janniaux