On Thu, Apr 04, 2024 at 13:26:55 -0500, Marth64 wrote:
> > Is \N a special sequence in ASS-speak
> \N is the special line break sequence in ASS
>
> I’m not sure of other special sequences following the \ character, I yield
> to Oneric on this question.
Standard ASS(2) a
On Mon, 19 Feb 2024 Oneric wrote:
> avcodec/webvttdec: honour bidi marks
> avcodec/{ass,webvttdec}: fix handling of backslashes
> avcodec/{ass,webvttdec}: more portable curly brace escapes
> avocdec/ass: simplify linebreaks
>
> libavcodec/as
for no reason
- ffmpeg’s attempt at escaping curly braces no longer
severly breaks in standard ASS renderers
v1 was posted over 2 years ago, would be great
if someone could finally look at this
On Mon, Feb 19, 2024 at 22:42:23 +0100, Oneric wrote:
> Changes from v3:
> - None. Just rebased
ff_ass_subtitle_header_* still used explicit CRLF linebreaks
eventhough they will get normalised to LF later since commit
7bf1b9b35769b37684dd2f18a54f01d852a540c8. Just directly use LF.
---
libavcodec/ass.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff
Unlike what the old comment suggested, standard ASS has no character
escape mechanism, but a closing curly bracket doesn't even need one.
For manual authored sub files using a full-width variant of an apropiate
font and with scaling and psacing modifiers is a common workaround.
This is not an
renderers
Oneric (4):
avcodec/webvttdec: honour bidi marks
avcodec/{ass,webvttdec}: fix handling of backslashes
avcodec/{ass,webvttdec}: more portable curly brace escapes
avocdec/ass: simplify linebreaks
libavcodec/ass.c | 47 +++---
libavcodec
Backslashes cannot be escaped by a backslash in any ASS renderer,
but unless followed by specific characters it is just printed out.
Insert a word-joiner character after a backslash to break up
active sequences without changing the visual output.
---
libavcodec/ass.c | 9 -
---
libavcodec/webvttdec.c | 2 +-
tests/ref/fate/sub-webvtt2 | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/webvttdec.c b/libavcodec/webvttdec.c
index 690f00dc47..990d150f16 100644
--- a/libavcodec/webvttdec.c
+++ b/libavcodec/webvttdec.c
@@ -39,7 +39,7 @@
a word-joiner
if there isn’t already one anyway
- added a third commit improving the handling of
curly brackets for standard ASS renderers
Oneric (4):
avcodec/webvttdec: honour bidi marks
avcodec/{ass,webvttdec}: fix handling of backslashes
avcodec/{ass,webvttdec}: more portable curly
Backslashes cannot be escaped by a backslash in any ASS renderer,
but unless followed by specific characters it is just printed out.
Insert a word-joiner character after a backslash to break up
active sequences without changing the visual output.
---
libavcodec/ass.c | 9 -
Unlike what the old comment suggested, standard ASS has no character
escape mechanism, but a closing curly bracket doesn't even need one.
For manual authored sub files using a full-width variant of an apropiate
font and with scaling and psacing modifiers is a common workaround.
This is not an
---
libavcodec/webvttdec.c | 2 +-
tests/ref/fate/sub-webvtt2 | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/webvttdec.c b/libavcodec/webvttdec.c
index 690f00dc47..990d150f16 100644
--- a/libavcodec/webvttdec.c
+++ b/libavcodec/webvttdec.c
@@ -39,7 +39,7 @@
ff_ass_subtitle_header_* still used explicit CRLF linebreaks
eventhough they will get normalised to LF later since commit
7bf1b9b35769b37684dd2f18a54f01d852a540c8. Just directly use LF.
---
libavcodec/ass.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff
On Thu, Dec 28, 2023 at 01:55:02 +0100, Oneric wrote:
> On Sun, Dec 10, 2023 at 17:37:12 +0100, Oneric wrote:
> > Changes from v1:
> > - ff_ass_bprint_text_event now only inserts a word-joiner
> >if there isn’t already one anyway
> > - added a third co
On Sun, Dec 10, 2023 at 17:37:12 +0100, Oneric wrote:
> Changes from v1:
> - ff_ass_bprint_text_event now only inserts a word-joiner
>if there isn’t already one anyway
> - added a third commit improving the handling of
>curly brackets for standard ASS renderer
Unlike what the old comment suggested, standard ASS has no character
escape mechanism, but a closing curly bracket doesn't even need one.
For manual authored sub files using a full-width variant of an apropiate
font and with scaling and psacing modifiers is a common workaround.
This is not an
Backslashes cannot be escaped by a backslash in any ASS renderer,
but unless followed by specific characters it is just printed out.
Insert a word-joiner character after a backslash to break up
active sequences without changing the visual output.
---
“”
---
libavcodec/ass.c | 9 -
---
“”
---
libavcodec/webvttdec.c | 2 +-
tests/ref/fate/sub-webvtt2 | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/webvttdec.c b/libavcodec/webvttdec.c
index 690f00dc47..990d150f16 100644
--- a/libavcodec/webvttdec.c
+++ b/libavcodec/webvttdec.c
@@ -39,7
patches to get rid of CRLF line endings)
Oneric (3):
avcodec/webvttdec: honour bidi marks
avcodec/{ass,webvttdec}: fix handling of backslashes
avcodec/{ass,webvttdec}: more portable curly brace escapes
libavcodec/ass.c | 19 +++
libavcodec/webvttdec.c | 4
On Mon, May 22, 2023 at 21:26:02 +0800, Zhao Zhili wrote:
> From: Zhao Zhili
>
> So CJK can be wrapped automatically.
>
> Signed-off-by: Zhao Zhili
> ---
> v3: Fix build error with older libass
> v2: Don't overwrite wrap automatically for native ASS
> libavfilter/version.h | 2 +-
>
On Fri, May 19, 2023 at 23:58:59 +0800, Zhao Zhili wrote:
> From: Zhao Zhili
>
> So CJK can be wrapped automatically.
>
> Signed-off-by: Zhao Zhili
> ---
> libavfilter/version.h | 2 +-
> libavfilter/vf_subtitles.c | 13 +
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
On Sun, Nov 20, 2022 at 01:15:33 +0100, Oneric wrote:
> On Sun, Nov 13, 2022 at 20:57:15 +0100, Oneric wrote:
> > This fixes colours and font selection for files converted to ASS
>
> Ping.
>
> As a reminder v1 and v2 are equivalent and patchwork is buggy and can
> thu
On Sun, Nov 13, 2022 at 20:57:15 +0100, Oneric wrote:
> This fixes colours and font selection for files converted to ASS
Ping.
As a reminder v1 and v2 are equivalent and patchwork is buggy and can
thus neither apply v1 or v2 and its results can be ignored and its patch
or diff downloads sho
On Sun, Nov 13, 2022 at 22:57:22 +0100, Oneric wrote:
> On Sun, Nov 13, 2022 at 21:01:34 +, Soft Works wrote:
> > I am unable to apply any of those patches. Neither v1 nor v2 neither
> > when downloading the series mbox or [2/3] from patchwork nor when
> > saving [2/3] fro
On Sun, Nov 13, 2022 at 21:15:04 +0100, Oneric wrote:
> To apply the third patch you may use v1 or the attached patch file.
The list also stripped the CRLF line endings from the (quoted-printable
encoded) attachments :(
Also no patchwork download has unmangled line endings anymore.
All
CRLF-requiring
patches. (But v1 or forcing base64 should still work)
To make applying easier for you, I now attached all patches bundled as an
archive to keep the list from interfering. Make sure to use --keep-cr.
All tests were done on top of 2d25f33a7ed36003de9a62c9cb165db183663d1c.
Reg
On Sun, Nov 13, 2022 at 21:27:11 +0100, Oneric wrote:
> [...] You can easily verify emails are capable of it by
> applying patch 2 yourself or using patchwork’s mbox file.
A correction: it seems since last time we discussed this, some patchwork
update has expanded the line-mangling to also
On Sun, Nov 13, 2022 at 20:15:23 +, Soft Works wrote:
>
> [...] it's not a Patchwork bug and it cannot be "fixed"
> at all in any other way than using binary diffs. The problem lies in
> the fact that it's being sent by e-mail where the different line
> endings get lost (as the spec mandates
esend
a v3 for all patches, let me know.
For the future I configured git send-email to always use base64 no matter
the content hopefully stopping the list from mangling my patches.
Oneric
From 73cacae6cb88aad4eb90c3b2b101ac1c5a6e2f69 Mon Sep 17 00:00:00 2001
From: Oneric
Date: Sat, 12 Nov 2022 18:5
The Encoding field (and the \fe tag) allows to limit font selection to
only those fonts declaring support for the specified codepage in their
OS/2's table "Code Page Character Range" field.
Particularly, Encoding=0 means only font's declaring support for "ANSI",
or rather "Latin (Western
Colour values used in ASS files without a "YCbCr Matrix" header set to
"None" are subject to colour mangling, due to how ASS was historically
conceived. A more in-depth description can be found in the documetation
inside libass' public ass_types.h header. The important part is, if this
header is
There is no v4 ASS. There are versions 1 to 4 of SSA (with only v4
being supported by softsub renderers), ASS which declares itself as v4+
or v4.00+, and the rarely used v4++/v4.00++, which isn't fully supported
by libass.
As reflected by the [V4+ Styles] section header, FFmpeg uses ASS, not
SSA
--keep-cr ... . (Or just apply v1)
v1
==
Original version sent using binary diffs for reference files.
Oneric (3):
avcodec/ass: fix comment
avcodec/ass: accurately preserve colours
avcodec/ass: specify a permissive encoding
libavcodec/ass.c | 5 +++--
tests/ref/fate/s
Thanks for taking a look!
On Sun, Nov 13, 2022 at 20:12:46 +0100, Nicolas George wrote:
> Oneric (12022-11-13):
> > [...]
> > tests/ref/fate/sub-webvtt2 | Bin 1648 -> 1668 bytes
>
> These are text files. Please fix this so that we can review the patch.
As expla
Colour values used in ASS files without a "YCbCr Matrix" header set to
"None" are subject to colour mangling, due to how ASS was historically
conceived. A more in-depth description can be found in the documetation
inside libass' public ass_types.h header. The important part is, if this
header is
The Encoding field (and the \fe tag) allows to limit font selection to
only those fonts declaring support for the specified codepage in their
OS/2's table "Code Page Character Range" field.
Particularly, Encoding=0 means only font's declaring support for "ANSI",
or rather "Latin (Western
diff since it
alone is marked as "diff eol=crlf" in .gitattributes.
Oneric (3):
avcodec/ass: fix comment
avcodec/ass: accurately preserve colours
avcodec/ass: specify a permissive encoding
libavcodec/ass.c | 5 +++--
tests/ref/fate/sub-aqtitle | Bin 32
There is no v4 ASS. There are versions 1 to 4 of SSA (with only v4
being supported by softsub renderers), ASS which declares itself as v4+
or v4.00+, and the rarely used v4++/v4.00++, which isn't fully supported
by libass.
As reflected by the [V4+ Styles] section header, FFmpeg uses ASS, not
SSA
On Sun, Oct 30, 2022 at 14:10:29 +0100, Lynne wrote:
> Sep 27, 2022, 23:06 by gustav.grus...@gmail.com:
>
> > Implements support for 2-pass CRF and 3-pass VBR by implementing
> > reading and writing of stats file, and passing the pass number on
> > to the encoder. For 3-pass VBR, the first pass
On Tue, Mar 29, 2022 at 01:31:02 +0200, Michael Niedermayer wrote:
> I intend to do a 5.0.1 release from the release/5.0 branch in the next days
> as its high time to make a new release with all the bugfixes
> so if you want to backport something please do so
How about the recent fix for
0:00 2001
From: Oneric
Date: Wed, 23 Mar 2022 20:43:54 +0100
Subject: [PATCH] avfilter/vf_subtitles: pass storage size to libass
Due to a quirk of the ASS format some tags depend on the exact storage
resolution of the video, so tell libass via ass_set_storage_size.
---
libavfilter/vf_subtit
On Mon, Mar 14, 2022 at 20:06:39 +0100, Oneric wrote:
> Due to a quirk of the ASS format some tags depend on the exact storage
> resolution of the video, so tell libass via ass_set_storage_size.
> [...]
On Mon, Mar 14, 2022 at 20:21:47 +, Soft Works wrote:
> [...]
>
> Ah,
On Mon, Mar 14, 2022 at 19:57:05 +, Soft Works wrote:
> > > ass_set_pixel_aspect() is setting settings.par and if I'm not mistaken,
> > > an existing par setting leads to the storage size setting to be ignored:
> >
> > It’s not overridden. Only the explicit PAR is currently preferd over the
>
On Mon, Mar 14, 2022 at 19:35:36 +, Soft Works wrote:
>
> I've been at the same point some time ago where I wondered why ffmpeg is
> not setting this, but then I had found that it is overridden by the call
> to ass_set_pixel_aspect().
>
> ass_set_pixel_aspect() is setting settings.par and if
Due to a quirk of the ASS format some tags depend on the exact storage
resolution of the video, so tell libass via ass_set_storage_size.
---
ass_set_storage_size exists since libass 0.10.2;
ffmpeg since 5.0 already requires 0.11.0.
This resolution dependences of ASS was already recognised when
On Sat, Feb 05, 2022 at 02:08:48 +, Soft Works wrote:
> Let's try to approach this from a different side. Which case is
> your [1/2] commit actually supposed to fix?
Escape backslashes when converting from WebVTT to not accidentally
introduce active ASS sequences and replace the wrong
On Fri, Feb 04, 2022 at 23:24:58 +, Soft Works wrote:
> You want to "pollute" gazillions of subtitle streams in the
> world from multiple subtitle formats with invisible
> characters in order to solve an escaping problem in ffmpeg?
I do not consider using characters that are explicitly
On Fri, Feb 04, 2022 at 02:30:37 +0100, Andreas Rheinhardt wrote:
> All text-based subtitles are supposed to be UTF-8 when they reach the
> decoder; if it isn't, the user has to set the appropriate -sub_charenc
> and -sub_charenc_mode.
>
> - Andreas
Thanks for the info! Then at least the UTF-8
On Fri, Feb 04, 2022 at 06:48:40 +, Soft Works wrote:
> > [two-part message removed for brevity]
>
> I've found out where the \{ and \} escaping has come from: libass
As already written in the commit-message of the first patch..
You already noticed your proposal only works with VSFilters,
On Thu, Feb 03, 2022 at 20:51:16 +, Soft Works wrote:
> I think when you inject that word-joiner as a workaround for ass
> parsing, you'll also need to make sure that it gets removed
> when encoding to other formats.
There's no way of knowing whether the word-joiner comes from
a conversion
On Wed, Feb 02, 2022 at 22:44:18 +, Soft Works wrote:
> > Sent: Wednesday, February 2, 2022 11:19 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> >
> > [claims about git and smtp: part 1]
> >
>
> [claims about git and smtp: part 2]
>
None of this relates to
It appears my previous mail has been interpreted as some sort of attack
against you; this is not the case. I am sorry for creating such a
misunderstanding.
The mail was merely meant to clear up the misconception that it would be
impossible to send mixed line-endings via mail due to some SMTP
On Tue, Feb 01, 2022 at 20:41:37 +, Soft Works wrote:
> > On Tue, Feb 01, 2022 at 19:44:24 +, Soft Works wrote:
> > > > On Sun, Jan 16, 2022 at 19:16:54 +0100, Oneric wrote:
> > > >
> > > > In case anyone is wondering why patchwor
On Tue, Feb 01, 2022 at 19:44:24 +, Soft Works wrote:
> > On Sun, Jan 16, 2022 at 19:16:54 +0100, Oneric wrote:
> >
> > In case anyone is wondering why patchwork fails to apply the second patch,
> > this is probably once again because the patch updates one of FATE's
On Sun, Jan 16, 2022 at 19:16:54 +0100, Oneric wrote:
> [PATCH 1/2] avcodec/{ass, webvttdec}: fix handling of backslashes
> libavcodec/ass.c | 5 -
> libavcodec/webvttdec.c | 2 +-
> 2 files changed, 5 insertions(+), 2 deletions(-)
> [PATCH 2/2] avcodec/webvttdec: ho
WebVTT files are required to be encoded as UTF-8 by its spec,
so just insert the bytes for UTF-8 encoded bidi-marks.
---
libavcodec/webvttdec.c | 2 +-
tests/ref/fate/sub-webvtt2 | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/webvttdec.c
Backslashes cannot be escaped by backslashes in any ASS renderer,
but unless followed by a few specific characters it is just printed
as a regular character. Insert a word-joiner character after a backslash
to break up the active sequences without changing the visual output.
Also the existing \{
On Sat, May 29, 2021 at 22:54:44 +0530, Gyan Doshi wrote:
> On 2021-05-29 22:14, Oneric wrote:
> > On Sat, May 29, 2021 at 11:53:24 +0530, Gyan Doshi wrote:
> > > Would it make sense to allow users to not load embedded fonts?
> >
> > I can't think of a reason not to
ont doesn't by chance happen to also be available
on the system or as a container-attachment, will be some, more or
less random font).
VLC always enables this unconditionally, but mplayer and mpv have an option
for this defaulting to embedded fonts enabled, but as before I don't know why
anyone
On Sun, May 02, 2021 at 23:02:02 +0200, Oneric wrote:
> ASS subtitles can have encoded fonts embedded into the subtitle file
> itself. Allow libass to load those, to render subs as intended.
> ---
> libavfilter/vf_subtitles.c | 1 +
> 1 file changed, 1 insertion(+
On Sun, May 02, 2021 at 23:02:02 +0200, Oneric wrote:
> ASS subtitles can have encoded fonts embedded into the subtitle file
> itself. Allow libass to load those, to render subs as intended.
> ---
> libavfilter/vf_subtitles.c | 1 +
> 1 file changed, 1 insertion(+)
On Sun, May 02, 2021 at 23:02:02 +0200, Oneric wrote:
> ASS subtitles can have encoded fonts embedded into the subtitle file
> itself. Allow libass to load those, to render subs as intended.
> ---
> libavfilter/vf_subtitles.c | 1 +
> 1 file changed, 1 insertion(+)
pin
ASS subtitles can have encoded fonts embedded into the subtitle file
itself. Allow libass to load those, to render subs as intended.
---
A sample file for ASS with embedded font can be at the following link.
If everything works, the 'A' will render as a quad; see image:
On Wed, Sep 09, 2020 at 15:28:05 +0200, Andreas Rheinhardt wrote:
> Oneric:
> > On Wed, Sep 09, 2020 at 01:02:04 -0500, rcombs wrote:
> >> -.mime_types= MT("image/jpeg"),
> >> +.mime_types= MT("image/jpeg", "image/jpg"),
On Wed, Sep 09, 2020 at 01:02:04 -0500, rcombs wrote:
> ---
> libavcodec/codec_desc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 3dee640360..49a00ad264 100644
> --- a/libavcodec/codec_desc.c
> +++
On Fri, Aug 21, 2020 at 14:46:53 +0200, Timo Rothenpieler wrote:
> Something like Markdown would come to mind. It should have all formatting
> tools one needs for documentation.
Imho ReStructuredText would be better suited for documentation than Markdown,
while being similarly "text-like".
is more complicated in that regard (especially with js).
While I myself am fortunate enough to not needing to rely on such a setup, I
personally know devs (not working on ffmpeg afaik) that do.
Regards
Oneric
___
ffmpeg-devel mailing list
ffmpeg-devel@ff
On Fri, Apr 17, 2020 at 03:35:44 +0200, one...@oneric.de wrote:
> On Fri, Apr 17, 2020 at 02:15:17 +0200, Oneric wrote:
> > ffmpeg does not set the 'ScaledBorderAndShadow' header for ASS
> > subtitles. This currently leads to inconsistent behaviour depending on the
> >
On Fri, Apr 17, 2020 at 03:35:44 +0200, one...@oneric.de wrote:
> On Fri, Apr 17, 2020 at 02:15:17 +0200, Oneric wrote:
> > ffmpeg does not set the 'ScaledBorderAndShadow' header for ASS
> > subtitles. This currently leads to inconsistent behaviour depending on the
> >
On Fri, Apr 17, 2020 at 03:35:44 +0200, one...@oneric.de wrote:
> From 74d3f6bd0189b0f4922404fccbefe95e1f01093d Mon Sep 17 00:00:00 2001
> From: Oneric
> Date: Fri, 17 Apr 2020 00:38:53 +0200
> Subject: [PATCH] avcodec/ass: explicitly set ScaledBorderAndShadow
> […]
> 25
On Fri, Apr 17, 2020 at 03:35:44 +0200, one...@oneric.de wrote:
> From 74d3f6bd0189b0f4922404fccbefe95e1f01093d Mon Sep 17 00:00:00 2001
> From: Oneric
> Date: Fri, 17 Apr 2020 00:38:53 +0200
> Subject: [PATCH] avcodec/ass: explicitly set ScaledBorderAndShadow
>
> ---
&
On Fri, Apr 17, 2020 at 02:15:17 +0200, Oneric wrote:
> From 51deab727958c5d64ae526f67063cdf141a01d46 Mon Sep 17 00:00:00 2001
> From: Oneric
> Date: Fri, 17 Apr 2020 00:38:53 +0200
> Subject: [PATCH] avcodec/ass: explicitly set ScaledBorderAndShadow
Sorry for the inconvenien
007.
https://github.com/TypesettingTools/Aegisub/commit/5269a2e2a1e1dab7aaf4ddde4055c8637cd413d4
>From 51deab727958c5d64ae526f67063cdf141a01d46 Mon Sep 17 00:00:00 2001
From: Oneric
Date: Fri, 17 Apr 2020 00:38:53 +0200
Subject: [PATCH] avcodec/ass: explicitly set ScaledBorderAndShadow
---
libavcodec/a
73 matches
Mail list logo
