When can I expect the output of ffmpeg to be byte-for-byte identical across
runs given the same input and command-line flags?
When I do simple tests now I always see the same checksums, but I remember
(sorry, short on details) often seeing different results with the same commands
in the past.
How are frame numbers converted to and from decimal numbers of seconds in
ffmpeg and related tools?
For example, given a file foo.mp4 at 24fps, when I run a command like:
ffmpeg -i foo.mp4 -t 0.72 bar.mp4
0.72 is a time between frame 18 (0.70833... seconds) and frame 19 (0.75
seconds).
In
5001 (2 frames of Green)? I don't know.
Any help here is much appreciated. Thanks!
Tom
On Wed, Aug 18, 2021 at 09:26:03PM -0600, amindfv--- via ffmpeg-user wrote:
> How are frame numbers converted to and from decimal numbers of seconds in
> ffmpeg and related tools?
>
> For
While reproducing a separate issue, I came upon some strange behavior with the
-ss flag: it seems to be seeking incorrectly when used as an input option in
some cases (including while transcoding and using -accurate_seek). Here's a
reproducer:
wget 'https://0x0.st/-yD3.mp4' # this host was
=4.73x
video:103kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: 1.690069%
[aac @ 0x55e2a63d51c0] Qavg: 65536.000
On Wed, Aug 25, 2021 at 06:11:33PM +, Carl Zwanzig wrote:
> On 8/25/2021 11:01 AM, amindfv--- via ffmpeg-user wrote:
> > Is this a bug?
OS: Debian 11.2, latest ffmpeg git master.
I've got a fairly simple filtergraph that's been giving me quite a hard time in
terms of starting or staying in sync. I've boiled it down to a test case with
three input videos, two identical (i.e. the same file), which clearly shows at
least a frame o
On Fri, Jan 07, 2022 at 12:54:06AM -0800, amindfv--- via ffmpeg-user wrote:
> OS: Debian 11.2, latest ffmpeg git master.
>
> I've got a fairly simple filtergraph that's been giving me quite a hard time
> in terms of starting or staying in sync. I've boiled it down t
On Sat, Jan 08, 2022 at 08:20:46PM +, MacFH - C E Macfarlane - News wrote:
> On 08/01/2022 19:38, Simon van Bernem via ffmpeg-user wrote:
> >
> > ffmpeg -i input.mkv
> > -vf "select='1-between(t,20,25)-between(t,100,200)
> > -between(t,220,300)-between(t,400,600)-between(t,750,800)
>
With the latest git version on Debian, I try and screen record.
My system is set up for 10-bit color, which I assume is the "mapping pixmap
format" issue.
Is anyone working on - or willing to work on - adding support for this pixel
format? It would be very appreciated!
Thanks,
Tom
$ ./ffmpeg
4718592
I'd appreciate any help!
Tom
On Fri, Apr 29, 2022 at 12:47:06PM -0700, amindfv--- via ffmpeg-user wrote:
> With the latest git version on Debian, I try and screen record.
>
> My system is set up for 10-bit color, which I assume is the "mapping pixmap
> format"
On Thu, May 26, 2022 at 06:31:58PM +0200, Cecil Westerhof via ffmpeg-user wrote:
> I have to cut a part from four files and concatenate them together.
> At the moment I am doing that in the following way:
> time ffmpeg -i 00250.MTS -i Pictures/reiger.jpg
>
> It seems the focus of many members of this group isn't on actually *helping
> people*, but on policing nonsense "rules violations" or finding some way they
> can call the user an idiot.
Ironically the single reason this thread has devolved into personal attacks and
irrelevance to the original
> I also tried using the -r option to ffmpeg in various ways (on both
> input/output streams) to correct the already recorded files, but this
> seemingly did nothing at all.
It's possible you'll instead want to use "setpts", which will keep the frames
as-is but re-timestamp the frames.
Tom
__
On Sun, Oct 25, 2020 at 06:24:16PM -0400, Ted Park wrote:
> Hi,
>
> > I have been using the following command to recompact the Blu-Ray MKV files:
> >
> > ffmpeg -y -hwaccel cuvid -c:v h264_cuvid -vsync 0 -i in.mkv -map 0 -codec:v
> > h264_nvenc -codec:a copy -codec:s copy -max_muxing_queue_size 4
On Thu, Oct 29, 2020 at 10:38:58AM +0100, Reindl Harald wrote:
>
>
> Am 29.10.20 um 07:11 schrieb Edward Park:
> > Does that search the current directory with gnu find? I thought you need to
> > do find . -type ….
> >
> > I just noticed your configure script failed. I (and probably everyone els
On Mon, Nov 02, 2020 at 11:02:20AM +0100, Carlos E. R. wrote:
> On 01/11/2020 22.33, Phil Rhodes via ffmpeg-user wrote:
> > Hi Marc
> > I can only reiterate the regrets you've already received and assure you it
> > was ever thus and it's not your fault.
> > For the benefit of any new people or a
Does anyone use ffmpeg (the executable, not the library) for large video edits?
I can imagine taking an edit decision list and translating it to a giant filter
graph of trims and concats, but I haven't seen this done. Is that because it's
an awkward tool for the job? Or is there some upper limit
> > params *before* "-i" are *input params*
> > params *after* "-i" are *output params*
> >
> > that has *always* been the case at least for 15 years and so it's
> > logical that you can't place a param at a random position by common
> > sense and expect the same result
>
> Thank you, Harald. I k
On Mon, Feb 19, 2024 at 08:49:14PM +0100, Paul B Mahol wrote:
> Best to create minimal reproducible usecase with all required files to
> reproduce it
By the way, this isn't just for reporting on Trac. For most recipients of these
messages (i.e. the people subscribed here) to get anything out o
On Mon, Dec 02, 2024 at 01:08:35PM +0100, edit 'B wrote:
[...]
> What you are proposing is a way that absolutely no one uses. There is either
> a lock between projector and cam so there is a 1:1 relation, or a cam is used
> with dynamic shutter speed.
This isn't really true. Some people (espec
20 matches
Mail list logo
