Re: [FFmpeg-devel] PATCH: Make -copyts a tri-state
On Oct 20, 2014, at 20:42, Michael Niedermayer michae...@gmx.at wrote:
On Mon, Oct 20, 2014 at 06:50:12PM -0500, Rodger Combs wrote:
On Oct 17, 2014, at 03:19, Rodger Combs rodger.co...@gmail.com wrote:
On Oct 15, 2014, at 06:00, Rodger Combs rodger.co...@gmail.com
mailto:rodger.co...@gmail.com wrote:
On Oct 15, 2014, at 05:37, Nicolas George geo...@nsup.org wrote:
Le quartidi 24 vendémiaire, an CCXXIII, Rodger Combs a écrit :
Discussed this briefly on IRC; decided this was a good idea. I'm not sure
if the commit message explains it well enough; please poke me here or on
IRC if it doesn't.
From 617b532c8a403c1cf06e60c99e9f36c787553b43 Mon Sep 17 00:00:00 2001
From: Rodger Combs rodger.co...@gmail.com
Date: Wed, 15 Oct 2014 05:00:02 -0500
Subject: [PATCH] Make copyts a tri-state, with `no` normalizing input
timestamps.
This doesn't change the default or `-copyts` behavior, but allows
`-nocopyts` to make e.g. `-ss 50` have timestamps starting at 50 seconds,
even if the input file's timestamps start at a value other than zero.
---
ffmpeg.c | 6 +++---
ffmpeg_opt.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
It looks like you forgot to update the documentation too.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Indeed I did. Here you go:
0001-Make-copyts-a-tri-state-with-no-normalizing-input-ti.patch
It occurs to me that it might be more useful in some cases to have one
master input file (the first one?) be shifted so its timestamps start at
zero, and the rest be shifted by the same amount as the master. That might
be a good argument for making this its own option, instead of making
copyts a tri-state.
I'm not particularly attached to the naming or implementation here, so
suggestions are plenty welcome :)
Upon some further testing, this seems to create some unusual and undesired
behavior in some cases, and I'm not sure exactly why. The patch is
definitely not ready, but I'd appreciate it if anyone could help work out a
better design for the feature.
My previous patch was awkward and had some unintended side-effects; this
version just adds a separate option instead of hacking -copyts.
From 88eb820b701c7eea11d60dd75faa2cefe57bbfe0 Mon Sep 17 00:00:00 2001
From: Rodger Combs rodger.co...@gmail.com
Date: Mon, 20 Oct 2014 18:31:18 -0500
Subject: [PATCH] Add -start_at_zero option.
This automatically shifts input timestamps to start at 0 instead of the
file's
starting timestamp when using -copyts.
applied
please add some documentation for this
thanks
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Documentation patch:
From 4fa599b322e5b5c172854eaf32de1ef25e9ec7f5 Mon Sep 17 00:00:00 2001
From: Rodger Combs rodger.co...@gmail.com
Date: Tue, 21 Oct 2014 01:22:16 -0500
Subject: [PATCH] doc/ffmpeg.texi: document the new -start_at_zero option
---
doc/ffmpeg.texi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 4fc7682..38dca86 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1016,6 +1016,12 @@ processing (e.g. in case the format option
@option{avoid_negative_ts}
is enabled) the output timestamps may mismatch with the input
timestamps even when this option is selected.
+@item -start_at_zero
+When used with @option{copyts}, shift input timestamps so they start at zero.
+
+This means that using e.g. @code{-ss 50} will make output timestamps start at
+50 seconds, regardless of what timestamp the input file started at.
+
@item -copytb @var{mode}
Specify how to set the encoder timebase when stream copying. @var{mode} is an
integer numeric value, and can assume one of the following values:
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: Make -copyts a tri-state
On Tue, Oct 21, 2014 at 01:23:55AM -0500, Rodger Combs wrote: On Oct 20, 2014, at 20:42, Michael Niedermayer michae...@gmx.at wrote: On Mon, Oct 20, 2014 at 06:50:12PM -0500, Rodger Combs wrote: On Oct 17, 2014, at 03:19, Rodger Combs rodger.co...@gmail.com wrote: On Oct 15, 2014, at 06:00, Rodger Combs rodger.co...@gmail.com mailto:rodger.co...@gmail.com wrote: On Oct 15, 2014, at 05:37, Nicolas George geo...@nsup.org wrote: Le quartidi 24 vendémiaire, an CCXXIII, Rodger Combs a écrit : Discussed this briefly on IRC; decided this was a good idea. I'm not sure if the commit message explains it well enough; please poke me here or on IRC if it doesn't. From 617b532c8a403c1cf06e60c99e9f36c787553b43 Mon Sep 17 00:00:00 2001 From: Rodger Combs rodger.co...@gmail.com Date: Wed, 15 Oct 2014 05:00:02 -0500 Subject: [PATCH] Make copyts a tri-state, with `no` normalizing input timestamps. This doesn't change the default or `-copyts` behavior, but allows `-nocopyts` to make e.g. `-ss 50` have timestamps starting at 50 seconds, even if the input file's timestamps start at a value other than zero. --- ffmpeg.c | 6 +++--- ffmpeg_opt.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) It looks like you forgot to update the documentation too. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Indeed I did. Here you go: 0001-Make-copyts-a-tri-state-with-no-normalizing-input-ti.patch It occurs to me that it might be more useful in some cases to have one master input file (the first one?) be shifted so its timestamps start at zero, and the rest be shifted by the same amount as the master. That might be a good argument for making this its own option, instead of making copyts a tri-state. I'm not particularly attached to the naming or implementation here, so suggestions are plenty welcome :) Upon some further testing, this seems to create some unusual and undesired behavior in some cases, and I'm not sure exactly why. The patch is definitely not ready, but I'd appreciate it if anyone could help work out a better design for the feature. My previous patch was awkward and had some unintended side-effects; this version just adds a separate option instead of hacking -copyts. From 88eb820b701c7eea11d60dd75faa2cefe57bbfe0 Mon Sep 17 00:00:00 2001 From: Rodger Combs rodger.co...@gmail.com Date: Mon, 20 Oct 2014 18:31:18 -0500 Subject: [PATCH] Add -start_at_zero option. This automatically shifts input timestamps to start at 0 instead of the file's starting timestamp when using -copyts. applied please add some documentation for this thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Documentation patch: From 4fa599b322e5b5c172854eaf32de1ef25e9ec7f5 Mon Sep 17 00:00:00 2001 From: Rodger Combs rodger.co...@gmail.com Date: Tue, 21 Oct 2014 01:22:16 -0500 Subject: [PATCH] doc/ffmpeg.texi: document the new -start_at_zero option applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: Make -copyts a tri-state
On Oct 17, 2014, at 03:19, Rodger Combs rodger.co...@gmail.com wrote:
On Oct 15, 2014, at 06:00, Rodger Combs rodger.co...@gmail.com
mailto:rodger.co...@gmail.com wrote:
On Oct 15, 2014, at 05:37, Nicolas George geo...@nsup.org wrote:
Le quartidi 24 vendémiaire, an CCXXIII, Rodger Combs a écrit :
Discussed this briefly on IRC; decided this was a good idea. I'm not sure
if the commit message explains it well enough; please poke me here or on
IRC if it doesn't.
From 617b532c8a403c1cf06e60c99e9f36c787553b43 Mon Sep 17 00:00:00 2001
From: Rodger Combs rodger.co...@gmail.com
Date: Wed, 15 Oct 2014 05:00:02 -0500
Subject: [PATCH] Make copyts a tri-state, with `no` normalizing input
timestamps.
This doesn't change the default or `-copyts` behavior, but allows
`-nocopyts` to make e.g. `-ss 50` have timestamps starting at 50 seconds,
even if the input file's timestamps start at a value other than zero.
---
ffmpeg.c | 6 +++---
ffmpeg_opt.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
It looks like you forgot to update the documentation too.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Indeed I did. Here you go:
0001-Make-copyts-a-tri-state-with-no-normalizing-input-ti.patch
It occurs to me that it might be more useful in some cases to have one
master input file (the first one?) be shifted so its timestamps start at
zero, and the rest be shifted by the same amount as the master. That might
be a good argument for making this its own option, instead of making copyts
a tri-state.
I'm not particularly attached to the naming or implementation here, so
suggestions are plenty welcome :)
Upon some further testing, this seems to create some unusual and undesired
behavior in some cases, and I'm not sure exactly why. The patch is definitely
not ready, but I'd appreciate it if anyone could help work out a better
design for the feature.
My previous patch was awkward and had some unintended side-effects; this
version just adds a separate option instead of hacking -copyts.
From 88eb820b701c7eea11d60dd75faa2cefe57bbfe0 Mon Sep 17 00:00:00 2001
From: Rodger Combs rodger.co...@gmail.com
Date: Mon, 20 Oct 2014 18:31:18 -0500
Subject: [PATCH] Add -start_at_zero option.
This automatically shifts input timestamps to start at 0 instead of the file's
starting timestamp when using -copyts.
---
ffmpeg_opt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index c518ae1..13152d0 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -91,6 +91,7 @@ int do_benchmark_all = 0;
int do_hex_dump = 0;
int do_pkt_dump = 0;
int copy_ts = 0;
+int start_at_zero = 0;
int copy_tb = -1;
int debug_ts = 0;
int exit_on_error = 0;
@@ -921,7 +922,7 @@ static int open_input_file(OptionsContext *o, const char
*filename)
f-start_time = o-start_time;
f-recording_time = o-recording_time;
f-input_ts_offset = o-input_ts_offset;
-f-ts_offset = o-input_ts_offset - (copy_ts ? 0 : timestamp);
+f-ts_offset = o-input_ts_offset - (copy_ts ? (start_at_zero
ic-start_time != AV_NOPTS_VALUE ? ic-start_time : 0) : timestamp);
f-nb_streams = ic-nb_streams;
f-rate_emu = o-rate_emu;
f-accurate_seek = o-accurate_seek;
@@ -2840,6 +2841,8 @@ const OptionDef options[] = {
audio drift threshold, threshold },
{ copyts, OPT_BOOL | OPT_EXPERT, {
copy_ts },
copy timestamps },
+{ start_at_zero, OPT_BOOL | OPT_EXPERT, {
start_at_zero },
+shift input timestamps to start at 0 when using copyts },
{ copytb, HAS_ARG | OPT_INT | OPT_EXPERT, {
copy_tb },
copy input stream time base when stream copying, mode },
{ shortest, OPT_BOOL | OPT_EXPERT | OPT_OFFSET |
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: Make -copyts a tri-state
On Mon, Oct 20, 2014 at 06:50:12PM -0500, Rodger Combs wrote: On Oct 17, 2014, at 03:19, Rodger Combs rodger.co...@gmail.com wrote: On Oct 15, 2014, at 06:00, Rodger Combs rodger.co...@gmail.com mailto:rodger.co...@gmail.com wrote: On Oct 15, 2014, at 05:37, Nicolas George geo...@nsup.org wrote: Le quartidi 24 vendémiaire, an CCXXIII, Rodger Combs a écrit : Discussed this briefly on IRC; decided this was a good idea. I'm not sure if the commit message explains it well enough; please poke me here or on IRC if it doesn't. From 617b532c8a403c1cf06e60c99e9f36c787553b43 Mon Sep 17 00:00:00 2001 From: Rodger Combs rodger.co...@gmail.com Date: Wed, 15 Oct 2014 05:00:02 -0500 Subject: [PATCH] Make copyts a tri-state, with `no` normalizing input timestamps. This doesn't change the default or `-copyts` behavior, but allows `-nocopyts` to make e.g. `-ss 50` have timestamps starting at 50 seconds, even if the input file's timestamps start at a value other than zero. --- ffmpeg.c | 6 +++--- ffmpeg_opt.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) It looks like you forgot to update the documentation too. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Indeed I did. Here you go: 0001-Make-copyts-a-tri-state-with-no-normalizing-input-ti.patch It occurs to me that it might be more useful in some cases to have one master input file (the first one?) be shifted so its timestamps start at zero, and the rest be shifted by the same amount as the master. That might be a good argument for making this its own option, instead of making copyts a tri-state. I'm not particularly attached to the naming or implementation here, so suggestions are plenty welcome :) Upon some further testing, this seems to create some unusual and undesired behavior in some cases, and I'm not sure exactly why. The patch is definitely not ready, but I'd appreciate it if anyone could help work out a better design for the feature. My previous patch was awkward and had some unintended side-effects; this version just adds a separate option instead of hacking -copyts. From 88eb820b701c7eea11d60dd75faa2cefe57bbfe0 Mon Sep 17 00:00:00 2001 From: Rodger Combs rodger.co...@gmail.com Date: Mon, 20 Oct 2014 18:31:18 -0500 Subject: [PATCH] Add -start_at_zero option. This automatically shifts input timestamps to start at 0 instead of the file's starting timestamp when using -copyts. applied please add some documentation for this thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: Make -copyts a tri-state
On Oct 15, 2014, at 06:00, Rodger Combs rodger.co...@gmail.com wrote: On Oct 15, 2014, at 05:37, Nicolas George geo...@nsup.org wrote: Le quartidi 24 vendémiaire, an CCXXIII, Rodger Combs a écrit : Discussed this briefly on IRC; decided this was a good idea. I'm not sure if the commit message explains it well enough; please poke me here or on IRC if it doesn't. From 617b532c8a403c1cf06e60c99e9f36c787553b43 Mon Sep 17 00:00:00 2001 From: Rodger Combs rodger.co...@gmail.com Date: Wed, 15 Oct 2014 05:00:02 -0500 Subject: [PATCH] Make copyts a tri-state, with `no` normalizing input timestamps. This doesn't change the default or `-copyts` behavior, but allows `-nocopyts` to make e.g. `-ss 50` have timestamps starting at 50 seconds, even if the input file's timestamps start at a value other than zero. --- ffmpeg.c | 6 +++--- ffmpeg_opt.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) It looks like you forgot to update the documentation too. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Indeed I did. Here you go: 0001-Make-copyts-a-tri-state-with-no-normalizing-input-ti.patch It occurs to me that it might be more useful in some cases to have one master input file (the first one?) be shifted so its timestamps start at zero, and the rest be shifted by the same amount as the master. That might be a good argument for making this its own option, instead of making copyts a tri-state. I'm not particularly attached to the naming or implementation here, so suggestions are plenty welcome :) Upon some further testing, this seems to create some unusual and undesired behavior in some cases, and I'm not sure exactly why. The patch is definitely not ready, but I'd appreciate it if anyone could help work out a better design for the feature. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] PATCH: Make -copyts a tri-state
Discussed this briefly on IRC; decided this was a good idea. I'm not sure if the commit message explains it well enough; please poke me here or on IRC if it doesn't. 0001-Make-copyts-a-tri-state-with-no-normalizing-input-ti.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: Make -copyts a tri-state
Le quartidi 24 vendémiaire, an CCXXIII, Rodger Combs a écrit : Discussed this briefly on IRC; decided this was a good idea. I'm not sure if the commit message explains it well enough; please poke me here or on IRC if it doesn't. From 617b532c8a403c1cf06e60c99e9f36c787553b43 Mon Sep 17 00:00:00 2001 From: Rodger Combs rodger.co...@gmail.com Date: Wed, 15 Oct 2014 05:00:02 -0500 Subject: [PATCH] Make copyts a tri-state, with `no` normalizing input timestamps. This doesn't change the default or `-copyts` behavior, but allows `-nocopyts` to make e.g. `-ss 50` have timestamps starting at 50 seconds, even if the input file's timestamps start at a value other than zero. --- ffmpeg.c | 6 +++--- ffmpeg_opt.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) It looks like you forgot to update the documentation too. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: Make -copyts a tri-state
On Oct 15, 2014, at 05:34, Rodger Combs rodger.co...@gmail.com wrote: Discussed this briefly on IRC; decided this was a good idea. I'm not sure if the commit message explains it well enough; please poke me here or on IRC if it doesn't. 0001-Make-copyts-a-tri-state-with-no-normalizing-input-ti.patch AND clearly I was too tired when writing this. I read the wrong value altogether. Here we go: 0001-Make-copyts-a-tri-state-with-no-normalizing-input-ti.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: Make -copyts a tri-state
On Oct 15, 2014, at 05:37, Nicolas George geo...@nsup.org wrote: Le quartidi 24 vendémiaire, an CCXXIII, Rodger Combs a écrit : Discussed this briefly on IRC; decided this was a good idea. I'm not sure if the commit message explains it well enough; please poke me here or on IRC if it doesn't. From 617b532c8a403c1cf06e60c99e9f36c787553b43 Mon Sep 17 00:00:00 2001 From: Rodger Combs rodger.co...@gmail.com Date: Wed, 15 Oct 2014 05:00:02 -0500 Subject: [PATCH] Make copyts a tri-state, with `no` normalizing input timestamps. This doesn't change the default or `-copyts` behavior, but allows `-nocopyts` to make e.g. `-ss 50` have timestamps starting at 50 seconds, even if the input file's timestamps start at a value other than zero. --- ffmpeg.c | 6 +++--- ffmpeg_opt.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) It looks like you forgot to update the documentation too. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Indeed I did. Here you go: 0001-Make-copyts-a-tri-state-with-no-normalizing-input-ti.patch Description: Binary data It occurs to me that it might be more useful in some cases to have one master input file (the first one?) be shifted so its timestamps start at zero, and the rest be shifted by the same amount as the master. That might be a good argument for making this its own option, instead of making copyts a tri-state. I'm not particularly attached to the naming or implementation here, so suggestions are plenty welcome :) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
