- 13 Feb, 2022 40 commits
-
-
Stephen Hutchinson authored
* Field Order * Chroma Location * Color Transfer Characteristics * Color Range * Color Primaries * Matrix Coefficients The existing TFF/BFF detection is retained as a fallback for older versions of AviSynth that can't access frame properties. The other properties have no legacy equivalent to detect them. Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
-
emcodem authored
AviSynth works on frame-based video by default, which can be either progressive or interlaced. Some filters can break frames into half-height fields, at which point it considers the clip to be field-based (avs_is_field_based can be used to check for this situation). To properly detect the field order of a typical video clip, the frame needs to have been weaved back together already, so avs_is_field_based should actually report 'false' when checked. Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
It is only used by the H.264 decoder (as well as the dirac decoder, which already uses a local copy). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
It is not set any more by any user of mpegvideo/mpegpicture. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Seems to have been always unused since these functions were introduced in 1f0cd30f. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Also do the same for update_duplicate_context_after_me() in mpegvideo_enc.c. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
This piece of code has been added in an already commented-out state in commit 158c7f05. It certainly doesn't make sense now (if ever) because new_picture_ptr it used has been removed in 6571e41d (and new_picture is only used for encoding). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
They don't ever read this value. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
mpegvideo-based encoders supporting bframes implement this by opening encoders of their own to test how long the chains of bframes are supposed to be. The needed AVCodec was obtained via avcodec_find_encoder(). This is complicated, as the current encoder can be directly obtained. And it also is not guaranteed that one actually gets the current encoder or not another encoder for the same codec ID (the latter does not seem to be the case now). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Also avoid the allocation by making it part of the context. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
They are not used by the encoder at all. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
MpegEncContext is used by many different codecs and every one of these uses just a subset of its fields. If one tries to separate this and e.g. add a real MpegContext and extension structures (say MpegDecContext and MpegEncContext), one runs into two difficulties: a) Some code is shared between decoder and encoder of the same format and they therefore use the same contexts, either MpegEncContext itself or identical extensions thereof. The latter is the case for H.261 as well as WMV2. b) In case of slice threading, the generic code can only allocate and initialize the structure it knows about; right now this is an MpegEncContext. If the codec has an even more extensive structure, it is only available for the main thread's MpegEncContext. Fixing this would involve making ff_mpv_common_init() aware of the size the size of slice context to allocate and would be part of separating the main thread's context from the slice contexts in general. This commit only intends to tackle the first issue by adding a pointer to MpegEncContext that codecs can set to a common context so that the aforementioned codecs can use this context (together with the MpegEncContext) in their common code. This will allow to move fields only used by the main thread to more specialized contexts. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Danny Wu authored
Fixes ticket 9086. Since early 2021, some of YouTube's VP9 encodes have non-monotonous DTS. This makes ffmpeg fatally fail when trying to copy or encode the V9 video. ffmpeg already includes functionality to correct this, however it was disabled without explanation for VP9 stream copies in 2e6636aa This patch restores the DTS correction logic, and allows ffmpeg to correctly encode (invalid) videos produced by youtube.com. I have verified that frames are NOT being cut (so it does not re-introduce 4313). Reviwed-by: Ronald S. Bultje <rsbultje@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
-
Andreas Rheinhardt authored
This decoder does not initialize any static data in its init function. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
It performs no initialization of static data in its init function. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
It performs no initialization of static data during its init function. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Nothing with static storage duration is initialized by these codecs. Reviewed-by: Peter Ross <pross@xvid.org> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Reviewed-by: Peter Ross <pross@xvid.org> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-
Andreas Rheinhardt authored
Reviewed-by: Peter Ross <pross@xvid.org> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
-