- 11 May, 2023 8 commits
-
-
Devin Heitmueller authored
Unlike other cases where the closed captions are embedded in the video stream as MPEG-2 userdata or H.264 SEI data, with MOV files the captions are often found on a separate "e608" subtitle track. Add support for playout of such files, leveraging the new ccfifo mechanism to ensure that they are embedded into VANC at the correct rate (since e608 packets often contain batches of multiple 608 pairs). Note this patch includes a new file named libavdevice/ccfifo.c, which allows the ccfifo functionality in libavfilter to be reused even if doing shared builds. This is the same approach used for log2_tab.c. Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Devin Heitmueller authored
THis filter can correct certain issues seen from upstream sources where the cc_count is not properly set or the CEA-608 tuples are not at the start of the payload as expected. Make use of the ccfifo to extract and immediately repack the CEA-708 side data, thereby removing any extra padding and ensuring the 608 tuples are at the front of the payload. Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Devin Heitmueller authored
Because the interlacing filter halves the effective framerate, we need to ensure that no CEA-708 data is lost as frames are merged. Make use of the new ccfifo mechanism to ensure that caption data is properly preserved as frames pass through the filter. Thanks to Thomas Mundt for review and noticing a couple of missed codepaths for injection on output. Thanks to Lance Wang for pointing out a memory leak. Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Devin Heitmueller authored
Various deinterlacing modes have the effect of doubling the framerate, and we need to ensure that the caption data isn't duplicated (or else you get double captions on-screen). Use the new ccfifo mechanism for yadif (and yadif_cuda and bwdif since they use the same yadif core) so that CEA-708 data is properly preserved through this filter. Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Devin Heitmueller authored
The existing implementation made an attempt to remove duplicate captions if increasing the framerate, but made no attempt to handle reducing the framerate, nor did it rewrite the caption payloads to have the appropriate cc_count (e.g. the cc_count needs to change from 20 to 10 when going from 1080i59 to 720p59 and vice-versa). Make use of the new ccfifo mechanism to ensure that caption data is properly preserved. Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Devin Heitmueller authored
When transcoding video that contains 708 closed captions, the caption data is tied to the frames as side data. Simply dropping or adding frames to change the framerate will result in loss of data, so the caption data needs to be preserved and reformatted. For example, without this patch converting 720p59 to 1080i59 would result in loss of 50% of the caption bytes, resulting in garbled 608 captions and 708 probably wouldn't render at all. Further, the frames that are there will have an illegal cc_count for the target framerate, so some decoders may ignore the packets entirely. Extract the 608 and 708 tuples and insert them onto queues. Then after dropping/adding frames, re-write the tuples back into the resulting frames at the appropriate rate given the target framerate. This includes both having the correct cc_count as well as clocking out the 608 pairs at the appropriate rate. Thanks to Lance Wang <lance.lmwang@gmail.com>, Anton Khirnov <anton@khirnov.net>, and Michael Niedermayer <michael@niedermayer.cc> for providing review/feedback. Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Christopher Degawa authored
Currently, the -1 (MR) preset is disallowed as it's taken as the preset option not set, and the only way to access it was through svtav1-params. Signed-off-by: Christopher Degawa <ccom@randomderp.com> Signed-off-by: James Almer <jamrial@gmail.com>
-
Andriy Utkin authored
Commit 55b81528 ("doc/filters: itemize crop examples") dropped the quotation marks from these examples, but this one remained. Quotes are actually needed to put the example into a command line or a program, but removing it here makes the example consistent with the document.
-
- 10 May, 2023 9 commits
-
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Dai, Jianhui J authored
Avoid compiling error if included by multiple sources. Signed-off-by: Jianhui Dai <jianhui.j.dai@intel.com> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
Paul B Mahol authored
Fixes NULL pointer dereference later.
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Lukáš Lalinský authored
-
- 09 May, 2023 5 commits
-
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
- 08 May, 2023 18 commits
-
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Thilo Borgmann authored
This allows for decimating large similar portions of a video while preserving small ones.
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
James Almer authored
Similar to the decoder AVOptions, this is useful to show values from options exported by the demuxer. Signed-off-by: James Almer <jamrial@gmail.com>
-
Anton Khirnov authored
Avoids the pointless overhead of transferring them to the main thread.
-
Anton Khirnov authored
The two checks using eof_reached are testing whether more input can possibly appear on this filtergraph input. InputFilterPriv.eof is the more authoritative source for this information.
-
Anton Khirnov authored
This code more properly belongs there.
-
Anton Khirnov authored
It is shorter and more efficient.
-
Anton Khirnov authored
It is not used outside of ffmpeg_filter.
-
Anton Khirnov authored
It is not used outside of ffmpeg_filter.
-
Anton Khirnov authored
It is not used outside of ffmpeg_filter.
-
Anton Khirnov authored
When an input stream terminates and no frames were successfully decoded, filtering code will currently configure the filtergraph using demuxer stream parameters. Use decoder parameters instead, which should be more reliable. Also, initialize them immediately when an input stream is bound to a filtergraph input, so that these parameters are always available (if at all) and filtering code does not need to reach into the decoder at some arbitrary later point.
-
Anton Khirnov authored
When no frames are ever seen by an encoder, encoder flush will do a last-ditch attempt to configure its source filtergraph in order to at least get the stream parameters. This involves extracting demuxer parameters from filtergraph source inputs, which is * a bad layering violation * probably unreachable, because decoders are flushed before encoders, which should call ifilter_send_eof(), which will also set these parameters; however due to complex control flow it is hard to be entirely sure this code can never be triggered Even if this code can actually be reached, it is probably better to return an error as the comment above it says.
-
Anton Khirnov authored
Replace it by simply calling choose_output() earlier.
-
Anton Khirnov authored
These two functions are a part of a single logical action - determining which, if any, output stream needs to be processed next. Keeping them separate is a historical artifact that obscures what is actually being done.
-