Walter Wong:
> Added the codec id S_TEXT/WEBVTT in order to bring ffmpeg generated files
> closer to the matroska spec. The list of matroska codec ids was also
> rearranged to push the old codec id (D_WEBVTT/SUBTITLES) to the bottom of
> the list so that S_TEXT/WEBVTT is the default codec id for ne
I understand. Would it be better to roll back the patch to just adding
S_TEXT/WEBVTT to list of recognized codec ids for now?
Original message From: Andreas Rheinhardt
Date: 2021-02-07 3:08 AM (GMT-05:00) To:
ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] Add mat
Walter:
> I understand. Would it be better to roll back the patch to just adding
> S_TEXT/WEBVTT to list of recognized codec ids for now?
We would need to add support for the Matroska way first.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmp
Paul B Mahol (12021-02-05):
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/vf_tile.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
LGTM.
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-
James Almer:
> Signed-off-by: James Almer
> ---
> This one must be committed after the upcoming major bump, as it changes
> the return value of an avpriv function.
>
> libavdevice/iec61883.c | 2 +-
> libavformat/dv.c | 56 --
> 2 files changed, 38
Currently, ffmpeg builds with --disable-avcodec --disable-avformat
--enable-avfilter result in a broken avfilter library due to a few
filters that require avcodec or avformat are mistakenly compiled in.
For example, see:
https://ci.appveyor.com/project/mcmtroffaes/ffmpeg-msvc-build/builds/37633531
To avoid duplicate between optname and optnamestr.
---
libavformat/libsrt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index f73e7dbfa5..557ab9e6e3 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -272,6 +272,9 @@ static int
---
libavformat/libsrt.c | 66 ++--
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 557ab9e6e3..d3c661d9d8 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -295,8 +295,8 @@ stat
Hi, good day! i'm working on mine project, it is batch scripts for
your utilities FFmpeg, on Windows os.
My repository https://github.com/brendan8c/FFMPEG_BAT
Are we can work together or dev collaboration?
I want to be part yours projects. What you think?
I'm sorry my English is weak but i studying
On Thu, 4 Feb 2021, James Almer wrote:
Signed-off-by: James Almer
---
fftools/ffplay.c | 204 +--
1 file changed, 127 insertions(+), 77 deletions(-)
Thanks for this, I see a couple of things that can be simplified, maybe it
is easier if I take ove
On 2/7/2021 9:26 AM, Marton Balint wrote:
On Thu, 4 Feb 2021, James Almer wrote:
Signed-off-by: James Almer
---
fftools/ffplay.c | 204 +--
1 file changed, 127 insertions(+), 77 deletions(-)
Thanks for this, I see a couple of things that can be si
On 2/7/2021 4:52 AM, Andreas Rheinhardt wrote:
James Almer:
Signed-off-by: James Almer
---
libavformat/wc3movie.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/libavformat/wc3movie.c b/libavformat/wc3movie.c
index 76e945d261..1fe582945a 100644
--
Marton Balint (12021-02-07):
> Also rename the parameters of the function to match with the implementation.
>
> Signed-off-by: Marton Balint
> ---
> libavdevice/timefilter.h | 15 +--
> 1 file changed, 1 insertion(+), 14 deletions(-)
Probably ok, I do not remember correcly enough.
On 2/7/2021 4:47 AM, Andreas Rheinhardt wrote:
James Almer:
Signed-off-by: James Almer
---
This one must be committed after the upcoming major bump, as it changes
the return value of an avpriv function.
libavdevice/iec61883.c | 2 +-
libavformat/dv.c | 56
The wait_start was about POLLING_TIME larger which leads to timeout
100ms late than the option setting.
---
libavformat/network.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/libavformat/network.c b/libavformat/network.c
index 0f5a575f77..7a9a4be5bb 100644
---
The wait_start was about POLLING_TIME larger which leads to timeout
100ms late than the option setting.
---
libavformat/libsrt.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index d3c661d9d8..d08634b71a 100644
--- a/l
Marton Balint (12021-02-07):
> av_gettime_relative() is using the monotonic clock therefore more suitable as
> a
> timestamp source and for relative time calculations.
>
> Probably fixes ticket #9089.
Not ok.
This is a user-visible change of behavior, we cannot do it just like
that.
Furthermor
Zhao Zhili (12021-02-07):
> The wait_start was about POLLING_TIME larger which leads to timeout
> 100ms late than the option setting.
> ---
> libavformat/libsrt.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
I see two patches with exactly identical code, except for a sing
Signed-off-by: James Almer
---
libavfilter/buffersrc.c | 38 --
1 file changed, 8 insertions(+), 30 deletions(-)
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index bf30f54177..da1cf9941e 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/
On Sun, 7 Feb 2021, 14:21 Nicolas George, wrote:
> Marton Balint (12021-02-07):
> > av_gettime_relative() is using the monotonic clock therefore more
> suitable as a
> > timestamp source and for relative time calculations.
> >
> > Probably fixes ticket #9089.
>
> Not ok.
>
> This is a user-visibl
Kieran Kunhya (12021-02-07):
> It is wrong to suggest that the clock of an IP webcam has any relation at
> all to the PC clock both absolute or relative.
It is not wrong to let users observe that their particular model of IP
webcam uses Unix timestamps and is correctly synchronized. This is a
comm
Sent from my mobile device
On Sun, 7 Feb 2021, 16:31 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > It is wrong to suggest that the clock of an IP webcam has any relation at
> > all to the PC clock both absolute or relative.
>
> It is not wrong to let users observe that their particul
Kieran Kunhya (12021-02-07):
> Give the user the option not to use the monotonic clock.
So this should be an option. Thank you very much.
> This is not possible without high end capture equipment to synchronise the
> clocks on each camera. Everything else is guesswork.
This is nonsense. The accu
Sent from my mobile device
On Sun, 7 Feb 2021, 16:55 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > Give the user the option not to use the monotonic clock.
>
> So this should be an option. Thank you very much.
Yes the montonic clock should be the default.
> This is not possible wi
Kieran Kunhya (12021-02-07):
> Yes the montonic clock should be the default.
Changing the default is acceptable to me. Probably after a transition
period.
> You misunderstand greatly. How does the clock rate of NTP magically make
> its way to the camera?
I do not know, I do not care, I am not a
On Sun, 7 Feb 2021, 17:15 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > Yes the montonic clock should be the default.
>
> Changing the default is acceptable to me. Probably after a transition
> period.
>
> > You misunderstand greatly. How does the clock rate of NTP magically make
> >
Kieran Kunhya (12021-02-07):
> You do care because different sources generated either by a PC or different
> physical cameras will drift. E.g at 25fps after one hour you might get
> 9 frames from one and 90002 or whatever frames from another etc. And of
> course the timestamps will drift slowly
Matthias Troffaes (12021-02-07):
> Currently, ffmpeg builds with --disable-avcodec --disable-avformat
> --enable-avfilter result in a broken avfilter library due to a few
> filters that require avcodec or avformat are mistakenly compiled in.
> For example, see:
>
> https://ci.appveyor.com/project/
On Sun, 7 Feb 2021, 17:29 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > You do care because different sources generated either by a PC or
> different
> > physical cameras will drift. E.g at 25fps after one hour you might get
> > 9 frames from one and 90002 or whatever frames from
Paul B Mahol (12021-02-05):
> This ensures that needed arrays are always allocated and properly initialized.
>
> Previously if code would use only avfilter_init_dict() to set options for
> filters
> it would not allocate arrays for timeline processing thus it would crash if
> user supplied enable
Kieran Kunhya (12021-02-07):
> Yes and thus you need a monotonic clock as a starting point for proper
> filtering. Ffmpeg has neither.
The kernel provides timestamps that are accurate enough. I do not
understand why you insist on the contrary in the face of facts.
Also, for a properly configured
---
libavformat/libamqp.c | 4 ++--
libavformat/network.c | 16 ++--
libavformat/network.h | 14 +-
libavformat/tcp.c | 6 --
4 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/libavformat/libamqp.c b/libavformat/libamqp.c
index c3b9c484ea..ca7d3ab70f
---
libavformat/libsrt.c | 45 +---
1 file changed, 17 insertions(+), 28 deletions(-)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index f73e7dbfa5..67e42bacc6 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -164,12 +164,14 @@ st
Sent from my mobile device
On Sun, 7 Feb 2021, 17:35 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > Yes and thus you need a monotonic clock as a starting point for proper
> > filtering. Ffmpeg has neither.
>
> The kernel provides timestamps that are accurate enough. I do not
> underst
Kieran Kunhya (12021-02-07):
> This time can jump forward or backwards. It is trivial to do this.
Not on a correctly configured system, it does not.
> The monotonic clock cannot do that.
The monotonic clock cannot synchronize from different computers.
Each has limitations the other has not, thi
On Sun, 7 Feb 2021, 18:34 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > This time can jump forward or backwards. It is trivial to do this.
>
> Not on a correctly configured system, it does not.
>
NTP is allowed to jump when it wants for example. It's not trivial for the
user to guara
Kieran Kunhya (12021-02-07):
> NTP is allowed to jump when it wants for example. It's not trivial for the
> user to guarantee this.
In practice, it does not.
> Exactly, so by default you must give the user a clock which is guaranteed
> not to jump as you don't know. If they need to synchronise be
On Sun, 31 Jan 2021, Marton Balint wrote:
There is no reason to keep it open.
Will apply the series.
Regards,
Marton
Signed-off-by: Marton Balint
---
libavformat/libsrt.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/libavformat/libsrt.c b/libavforma
On Mon, 8 Feb 2021, Zhao Zhili wrote:
---
libavformat/libsrt.c | 45 +---
1 file changed, 17 insertions(+), 28 deletions(-)
Hmm, it seems my latest srt patches conflics with this a bit, and you
will have to somewhat rebase this, sorry. On the bright si
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 19 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_exposure.c | 144 ++
4 files changed, 165 insertions(+)
create mode 100644 libavfilter/vf_exposure.c
di
Sent from my mobile device
On Sun, 7 Feb 2021, 19:21 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > NTP is allowed to jump when it wants for example. It's not trivial for
> the
> > user to guarantee this.
>
> In practice, it does not.
>
Read the docs where it explains where it can ju
Kieran Kunhya (12021-02-07):
> Your scenario is contrived. Its impossible to sync exactly between
> different machines for all the reasons I explained and you didn't
> understand.
I understand very well. What you refuse to understand is that all this
theoretical stuff does not matter. What matters
On Sun, 7 Feb 2021, 20:20 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > Your scenario is contrived. Its impossible to sync exactly between
> > different machines for all the reasons I explained and you didn't
> > understand.
>
> I understand very well. What you refuse to understand is
Kieran Kunhya (12021-02-07):
> It doesn't work in practice.
> It's why every Android phone captures video at 29.970fps ± jitter instead
> of the correct 3/1001
Good enough for most uses. Let the user decide.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
Sent from my mobile device
On Sun, 7 Feb 2021, 20:27 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > It doesn't work in practice.
> > It's why every Android phone captures video at 29.970fps ± jitter instead
> > of the correct 3/1001
>
> Good enough for most uses. Let the user deci
Kieran Kunhya (12021-02-07):
> QED that you don't understand the problem whatsoever.
This is the third time you've been rude today.
I am sorry, but it's you who do not understand what people actually
need. Most use cases do not need better precision than a few hundredth
of seconds, if that.
--
Hi,
On Tue, 26. Jan 11:23, sgerwk-at-aol@ffmpeg.org wrote:
> In my previous email the patch got mangled by the web mail interface, so I am
> sending it again. Sorry for the duplicate.
I couldn't apply this version, but previous one applied ok:
https://patchwork.ffmpeg.org/project/ffmpeg/patch
On Sat, 28. Nov 14:46, Andriy Gelman wrote:
> From: Andriy Gelman
>
> We currently use the same interrupt_callback function for both muxers
> and demuxers to break out of potential infinite loops.
>
> The function decode_interrupt_cb() checks for how many SIGINT/SIGTERM
> interrupts have been re
Fixes: OOM
Fixes:
30066/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_fuzzer-6182309126602752
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/asfdec_f.c | 2 ++
1 file changed, 2 insertions(+
The choosen value is arbitrary. I am not sure if this is a good idea
but i dont immedeately see an alternative better way, it seems either
an arbitrary limit or OOM
Fixes: OOM
Fixes:
27492/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6194970578649088
Found-by: continuous fuzzing process
The packet serial can be used instead to detect when a flush is needed.
Signed-off-by: Marton Balint
---
fftools/ffplay.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 9ff0425163..70d8548a64 100644
--
Signed-off-by: Marton Balint
---
fftools/ffplay.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 70d8548a64..0054fec076 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -589,8 +589,6 @@ static int decoder
Heavily based on a patch by James Almer.
Signed-off-by: Marton Balint
---
fftools/ffplay.c | 140 +--
1 file changed, 76 insertions(+), 64 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 0054fec076..eab156c47a 100644
--- a/fftools/
Signed-off-by: Marton Balint
---
fftools/ffplay.c | 95 +++-
1 file changed, 45 insertions(+), 50 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index eab156c47a..b9a30cdb11 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -654,26
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
---
libavformat/libamqp.c | 4 ++--
libavformat/network.c | 16 ++--
libavformat/network.h | 14 +-
libavformat/tcp.c | 6 --
4 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/libavformat/libamqp.c b/libavformat/libamqp.c
index c3b9c484ea..ca7d3ab70f
---
v2: code rebase
libavformat/libsrt.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 233e9096fa..95a20b2308 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -176,7 +176,7 @@ stati
the warning message is:
warning: missing braces around initializer [-Wmissing-braces]
Signed-off-by: Guo, Yejun
---
libavfilter/vf_pseudocolor.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_pseudocolor.c b/libavfilter/vf_pseudocolor.c
index 192839342b..3
> On Feb 8, 2021, at 2:36 AM, Marton Balint wrote:
>
>
>
> On Mon, 8 Feb 2021, Zhao Zhili wrote:
>
>> ---
>> libavformat/libsrt.c | 45 +---
>> 1 file changed, 17 insertions(+), 28 deletions(-)
>
> Hmm, it seems my latest srt patches conflics with this
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: 2021年2月2日 17:48
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] GSoC 2021
>
> Hi all
>
> Most people probably already know but just to be sure everyone knows GSoC
> 2021 is
60 matches
Mail list logo
