From: "Daniel Cantarín" <canta@canta.com.ar>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] Politics
Date: Sat, 18 Dec 2021 12:41:18 -0300
Message-ID: <85334378-9a7c-780a-4c44-fe42c9dcf255@canta.com.ar> (raw)
In-Reply-To: <MrCjcci--3-2@lynne.ee>
> I also am not accepting a hardcoded timebase of microseconds.
> Rounding really matters for subtitles, since presenting them
> a frame early or late is unacceptable
That's simply not true.
I don't accept or deny a hardcoded microseconds timebase;
that's beyond my knowledge to judge. What I say is not true is
the other sentence: "presenting them a frame early or late is
unnaceptable".
That's a gross exaggeration, and should not be a blocker.
In my country everyone uses subtitles since decades ago, and
people cares about timing only when there's seconds of desync.
Yeah, seconds in plural: a single second most likely would be
accepted. We're talking about dozens of frames here.
Of course, I wouldn't say "innacurate is right". But I wouln't
also block other people's work using unreal standards.
Now, DRIFTING would be a different beast, and microseconds
leaks should be a serious issue for 24/7 streams. I don't see
people debating such problem, and "a sigle frame off" is a
wrong angle for talking milliseconds precision and rounding.
Also, I did some tests with softworkz code, and timings seems
working fine with production inputs. I saw several people here
talking about complex graphs with different timebases, and
changes between subtitle formats. I believe the debate would
be much less abstract if somebody could kindly put some
example here we could all test for ourselves.
I understand nobody could have a full idea of all possible
scenarios: that would be unfair to ask for. But I believe
people with observations about possible breaking use cases
would have such use cases more likely available in mind and
could share them with us.
I DID actually find problems with timings in softworkz code.
But those problems were anything like the things debated here.
You see, I've tried to use setpts and asetpts in my graphs,
yet there's no ssetpts. Other filters had the same problem.
Also, there are live-streaming muxers and codecs that does not
support subtitles. See this, for example:
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hls.c#L506
Or this:
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L1066
But I believe those issues can be handled isolated once
there's subtitle filtering implemented, so I don't consider
them part of this debate per se.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2021-12-18 15:41 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8dbfd345-c661-459e-b242-94830107eae3@www.fastmail.com>
[not found] ` <DM8P223MB0365510C72E8CFEF027FF97FBA749@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>
[not found] ` <MqpKkF_--7-2@lynne.ee>
[not found] ` <DM8P223MB0365FEDCCEFB370D20979CF5BA749@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>
[not found] ` <c2f7048d-a1b6-253e-8a50-7fdf9a34ada3@canta.com.ar>
[not found] ` <DM8P223MB036596CACBB6509CB1AE78CBBA759@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>
[not found] ` <CAPYw7P64=axtAC0-8Ux+1d+f8WEseuWk9OkhmbAnNWp-eRpq8A@mail.gmail.com>
2021-12-15 13:34 ` Soft Works
2021-12-18 10:26 ` Paul B Mahol
2021-12-18 11:34 ` Soft Works
2021-12-18 13:32 ` Lynne
2021-12-18 14:28 ` Soft Works
2021-12-18 15:16 ` Lynne
2021-12-18 15:43 ` Soft Works
2021-12-18 17:53 ` Lynne
2021-12-18 18:16 ` Daniel Cantarín
2021-12-18 18:30 ` Hendrik Leppkes
2021-12-18 18:49 ` Soft Works
2021-12-18 20:05 ` Daniel Cantarín
2021-12-18 20:41 ` Soft Works
2021-12-19 15:16 ` Michael Niedermayer
2021-12-19 18:23 ` Soft Works
2021-12-19 18:31 ` Soft Works
2021-12-20 14:49 ` Michael Niedermayer
2021-12-20 22:35 ` Soft Works
2021-12-20 23:20 ` Soft Works
2021-12-21 18:38 ` Michael Niedermayer
2021-12-22 10:23 ` Soft Works
2021-12-18 17:59 ` Daniel Cantarín
2021-12-18 15:41 ` Daniel Cantarín [this message]
2021-12-20 13:48 Daniel Cantarín
2021-12-20 14:06 Daniel Cantarín
2021-12-20 15:23 ` Michael Niedermayer
2021-12-22 13:29 ` Soft Works
2021-12-22 19:54 ` Michael Niedermayer
2021-12-22 20:17 ` Soft Works
2021-12-20 16:27 Daniel Cantarín
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85334378-9a7c-780a-4c44-fe42c9dcf255@canta.com.ar \
--to=canta@canta.com.ar \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git