---
libavcodec/motion_est.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/motion_est.c b/libavcodec/motion_est.c
index d17ffe42b4..95978d95dd 100644
--- a/libavcodec/motion_est.c
+++ b/libavcodec/motion_est.c
@@ -1571,7 +1571,7 @@ void
Signed-off-by: Dima Buzdyk
---
libavcodec/hevc_parser.c | 4
libavdevice/v4l2-common.c | 3 +++
libavdevice/v4l2.c| 2 +-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 59f9a0ff3e..8f99a277a1 100644
---
Some drivers may set bytesperline if hardware use padding bytes for
alignment. In this case lavd/v4l2 will expect W*H bytes per frame, but
driver will provide Pitch*H bytes which makes v4l2 unhappy.
This change adjusts frame width to cover entire data buffer aligning
lavd/v4l2 expectations with
Am 06.11.22 um 21:57 schrieb Carl Eugen Hoyos:
Am Sa., 5. Nov. 2022 um 22:31 Uhr schrieb Nomis101 :
Support for mlpa muxing was added back in 2019:
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=808a6717e0c584738c60a109afd6d47f4973d619
But it was hidden back then behind
Should fix Coverity issue #1500329.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_fftdnoiz.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_fftdnoiz.c b/libavfilter/vf_fftdnoiz.c
index e74f40b4cb..f7200699c6 100644
---
Should fix Coverity issue #1516762.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/af_afir.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/libavfilter/af_afir.c b/libavfilter/af_afir.c
index e1fe7d6a64..910999cce7 100644
---
Should fix Coverity issue #1516765.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_fftfilt.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/libavfilter/vf_fftfilt.c b/libavfilter/vf_fftfilt.c
index 067ce7eb30..231e74fd72 100644
---
Should fix Coverity issue #1516766.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/af_surround.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/libavfilter/af_surround.c b/libavfilter/af_surround.c
index 858fed609a..969325cf6b 100644
---
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/clearvideo.c | 23 +++
> 1 file changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/clearvideo.c b/libavcodec/clearvideo.c
> index 4d6549560b..82311bc645 100644
> ---
Bump.
Is anyone interested in looking at these two patches? I’m trying to get
into ffmpeg development and it would be nice to get some experience of
the full process of getting a patch landed. I don’t have commit rights.
Thanks in advance for any feedback.
Regards,
– Neil
Neil Roberts writes:
Anton Khirnov (12022-11-09):
> I have no idea what you mean by this. What is being broken and how?
EAGAIN and REDO are different. If you make them the same, you break one
of them. Or possibly both if you are being really stupid, but at least
one.
> Maybe more context will clarify the motivation
The purpose of this new option is to enable processing of mixed content such
as TV recordings or even movies which have some cuts in telecined 24fps and
others in 30p.
Enabling it (mixed=1) will calculate a common timebase between decimated and
non-decimated content and set frame duration
Enabling the option will only decimate frames below dupthresh and output at
variable frame rate.
Signed-off-by: lovesyk
---
libavfilter/vf_decimate.c | 42 +--
1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/libavfilter/vf_decimate.c
Quoting Nicolas George (2022-11-09 11:41:32)
> Anton Khirnov (12022-11-09):
> > If your concern with busy-waiting is pointless energy consumption, then
> > the correct thing to do is change all busy-waiting devices to sleep
> > internally if AVFMT_FLAG_NONBLOCK is not specified. I just checked,
Anton Khirnov (12022-11-09):
> If your concern with busy-waiting is pointless energy consumption, then
> the correct thing to do is change all busy-waiting devices to sleep
> internally if AVFMT_FLAG_NONBLOCK is not specified. I just checked, and
> almost all of them actually do exactly this, the
I have reported the errors I encountered during the compilation process in
the Chromium-Dev Group before, and I uploaded the detailed error
information in this post.
https://groups.google.com/a/chromium.org/g/chromium-dev/c/mB7yoDsYtbs
The following is the address where I submitted CL to
Quoting Nicolas George (2022-11-09 10:38:06)
> Anton Khirnov (12022-11-09):
> > > Well, it has actionable consequences: if you treat EAGAIN like REDO you
> > > introduce a busy wait,
> > In most devices it's a sleep rather than a busy wait. And in those where
> > it isn't, it should be.
>
> I do
Anton Khirnov (12022-11-09):
> > Well, it has actionable consequences: if you treat EAGAIN like REDO you
> > introduce a busy wait,
> In most devices it's a sleep rather than a busy wait. And in those where
> it isn't, it should be.
I do not know how your sentence connects to mine.
>
Quoting Nicolas George (2022-11-09 09:21:34)
> Anton Khirnov (12022-11-08):
> > Sure, and that's about it. And as I said before - there is no way to
> > tell when a device will be ready, so this is of very limited usefulness.
>
> This is not true for many devices. Sorry to contradict you once
Paul B Mahol (12022-11-09):
> The bug is found by Jan IIRC, and fixed by not using EAGAIN return
> values in demuxer IIRC.
Then I do not know what bug you are referring to. Maybe try honing your
communication skills.
--
Nicolas George
___
On 11/9/22, Nicolas George wrote:
> Paul B Mahol (12022-11-09):
>> I'm not interested in REDO / EAGAIN differences.
>
> They delete this thread.
>
>> Can this bug be fixed at all?
>
> This bug has been fixed for seven years. I would rather we do not unfix
> it.
The bug is found by Jan IIRC, and
Paul B Mahol (12022-11-09):
> I'm not interested in REDO / EAGAIN differences.
They delete this thread.
> Can this bug be fixed at all?
This bug has been fixed for seven years. I would rather we do not unfix
it.
--
Nicolas George
___
ffmpeg-devel
On 11/9/22, Nicolas George wrote:
> Anton Khirnov (12022-11-08):
>> Sure, and that's about it. And as I said before - there is no way to
>> tell when a device will be ready, so this is of very limited usefulness.
>
> This is not true for many devices. Sorry to contradict you once again,
> but you
Anton Khirnov (12022-11-08):
> Sure, and that's about it. And as I said before - there is no way to
> tell when a device will be ready, so this is of very limited usefulness.
This is not true for many devices. Sorry to contradict you once again,
but you would know it if you had any experience
24 matches
Mail list logo
