[FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix handling of backslashes

[Oneric]

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 property
using some illustrative examples from the current thread.
(I have no idea how SMTP works in detail)

I'll respond to the new misunderstandings below in more detail if you're 
interested, but I see little point in continuing to discuss how mails are 
transferred or encoded.
Can we now start to discuss the patches themselves instead?

If you want to apply them and have trouble with getting the correct patch out
of your client (and don't want to use Patchwork's diff), let me repeat my 
previous offer:
> > If someone wants to apply the patches and has trouble with getting the patch
> > out of the mailclient I can on request resend the patch with a binary diff
> > for the reference file.

~~~~~~

On Wed, Feb 02, 2022 at 04:44:54 +0000, Soft Works wrote:
> > It CAN be applied (as I've now written twice) and
> > of course I verified this with the mail received from the list.
>
> I meant that it can be applied by everybody, including Patchwork
> and Michael.

Everybody but Patchwork can apply the mail and Patchwork's _diff_ works too.
In case any mail client acts up I already offered to resend the patch
with a binary flag for the reference file on request.

> I use git format-patch, just like many others and afaik it can't create base64
> encoded content.

It doesn't need to. When attaching a format-patch (as ffmpeg's documentation 
recommends when not using send-email) the _mail client_ is supposed to
choose and perform a suitable transfer encoding.
Depending on the mail client this can also work with the main message,
but some clients have trouble preserving everything in the main message.
(Because they assume the main body to be plain text and eg
 "normalise" line-ending, automatically break long lines, 
 remove or replace special characters, etc)

> BTW. BASE64 doesn't seem to be widely used here, [...]

Note, that I wrote send-email uses the appropriate transfer-encoding 
“automatically” not “always base64”; if there are no characters in the
message beyond US-ASCII (and mayhaps only LF line-endings), using base64
or quoted-printable is not necessary.
Whether or not mixed line-endings _require_ one of the latter two encodings
due to some SMTP limitation I do not know. It's certainly _possible_ to
preserve them this way though.
(And git send-email choose to use base64 for the second patch.)

> Interestingly, even the author of those lines is sending patches with
> Content-Transfer-Encoding: 7bit :-)

see previous.
(second patch contains bidi-marks and mixed line-endings, first neither)

> LOL - so the majority on this ML is sending patches incorrectly?

No, see second last.