Commits on Source (17)
-
To ensure less false-positive dropped frame inferences. This value is still a place-holder until I have time to implement a mechanism to ask decoders/encoders their inner-queue size.
954857f3 -
To better match its actual use-case.
30bfd8c3 -
357e232a
-
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
c14cf91e -
These add coverage for the previous commit case and will be expanded in the future. Refs #27336
74287028 -
It makes it clearer that this variable contains the DTS of input frames rather than output.
d07bfd9b -
This has become necessary to properly determine if all the frames have been output and whether to fast forward a PCR value or not.
97a66c84 -
4a737f61
-
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.
8ff9f025 -
27983e0a
-
a0d3c822
-
Wrap up the very verbose vlc_list accessor to only have to pass head around.
26991374 -
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.
33d785bb -
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).
9cf8b5bd -
Mimicking a classic audio/video transcoding scenario.
be8a27ef -
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.
aca20342 -
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.
37f12716
Showing
- modules/stream_out/transcode/pcr_helper.c 32 additions, 17 deletionsmodules/stream_out/transcode/pcr_helper.c
- modules/stream_out/transcode/pcr_helper.h 1 addition, 1 deletionmodules/stream_out/transcode/pcr_helper.h
- modules/stream_out/transcode/pcr_sync.c 32 additions, 45 deletionsmodules/stream_out/transcode/pcr_sync.c
- modules/stream_out/transcode/transcode.c 40 additions, 3 deletionsmodules/stream_out/transcode/transcode.c
- modules/stream_out/transcode/transcode.h 3 additions, 0 deletionsmodules/stream_out/transcode/transcode.h
- test/Makefile.am 3 additions, 1 deletiontest/Makefile.am
- test/modules/stream_out/pcr_sync.c 244 additions, 2 deletionstest/modules/stream_out/pcr_sync.c