[FFmpeg-devel] FATE-Suite Data Test Data

Andreas Rheinhardt andreas.rheinhardt at outlook.com
Fri Dec 10 21:00:27 EET 2021


Soft Works:
> Hi,
> 
> can we add the attached file (SubRip_capability_tester2.srt) to the fate-suite data?
> 
> Compared to SubRip_capability_tester.srt, it has one line removed that would
> cause (legitimate) trailing whitespace in some ref data files.
> 
> It hasn’t been an issue so far due to a bug in the encoders which didn’t properly
> convert ASS hard-space tags (\h) and incorrectly emitted them as “\h” text.
> After fixing this, encoders to formats which don’t have a concept of “hard spaces”,
> will output \h as regular spaces, and in the case of that single source line
> that I have removed in the source file, this would lead to trailing spaces in the
> ref files.
> 
> As I don’t know how, when or whether at all this can be fixed in a way that it
> could work with patches transported via e-mail, this single line change seems
> to be the best quick solution to the problem.
> 
> Thanks,
> softworkz
> 

I don't think that this will help. Trailing whitespace should actually
only lead to a warning when applying (depending upon core.whitespace).

Your patch is broken: There is a line "\ N is a forced line break" in
the current ref file which ends with \r\n. This line is not marked as
changed in your patchfile, but it is part of the surrounding context of
a diff; and said line of context uses only \n and is therefore not
recognized.

And when I create a diff where the patch file has the proper context, it
still fails; I need to add the "--keep-cr" option to git am to make it
work. But then it works, whereas this option didn't help if the patch
file only has \n instead of \r\n.

- Andreas

PS: The intra-subtitle newlines in said files are \r\n, yet the
inter-subtitle delimiters are \n only. This inconsistency might be
considered a bug.


More information about the ffmpeg-devel mailing list