[MPlayer-dev-eng] Small changes to subreader.c file

[Rich Felker]

On Sat, Oct 08, 2005 at 10:05:06AM +0200, Adam Tla??ka wrote:
> Dnia Sat, 08 Oct 2005 04:29:31 +0200, Guillaume POIRIER  
> <poirierg at gmail.com> napisa??:
> 
> >Hi,
> >
> >On 10/8/05, Rich Felker <dalias at aerifal.cx> wrote:
> >>> > This is not a bug. .srt files are text files and as such should be
> >>> > stored in (standard) unix text format. If windows/dos/mac/etc users
> >>> > want to use them they can apply the appropriate (broken) textfile
> >>> > conversions.
> >>> Is there an SRT standard?
> >>
> >>No, none of this windows-originated crap has specs. It's just a text
> >>file. And I'm totally against ever writing \r's into text files! If
> >>someone wants to put \r in there they can do it with a simple script.
> >>If you really insist we can open the file in "w" mode instead of "wb"
> >>so it gets the \r crap if you run it on windows...
> >
> >Okay, so I consider both patches undesirable, and drop them from my
> >patch tracker.
> >
> >Guillaume
> >
> >--
> >Reading doesn't hurt, really!
> >  -- Dominik 'Rathann' Mierzejewski
> So read it with care.
> I disagree with this approach completly! SRT files are originally  
> introduced by
> a SubRip Windows application so the format is known. It is Windows-like  
> text file.
> So there is no doubt then there should be "\r\n" line edings in it.
> 
> Moreover many DVD players can use this format of subtitle files. But no  
> Unix format.

You mean "divx players". We already go out of our way not to support
this crap by using the FMP4 fourcc, so I don't see how having to
convert your srt file to the broken format they expect is any worse
than having to use -ffourcc XVID or DX50...

> So doing this as a simply Unix text format is not a good solution.
> Consider this. My patch contains three additional "\r" to the mplayer code
> and there is no need to use another app to convert formats.

Consider this: I run mplayer -dumpsrt sub to work on subtitle files. I
also edit them by hand, treating them as text files, which are UNIX
text files! I do not want a bunch of ^M crap all over the file to try
to deal with. No program on unix should generate text files with this
broken crap in them.

> I am saying this again: SRT means the Windows text file format - not text  
> file format of

It's a text file. Text files should always be in the native format.

> no problem IMHO. Exporting of subtitles should produce a format which can  
> be read by other
> programs or hardware players too.

AFAIK windows players have no problem reading our files. It's only
broken hardware player (which are already broken in countless other
ways and not worth supporting) that choke.

> This is not end of course because we need to export SRT file in a proper  
> codepage.
> Now it is exported in UTF8 so some conversion is needed anyway. I am  
> working on it.

......
Even more stupidity. Text files should also always be utf8.

> IMHO export to SRT should just produce globally usable SRT file and that's  
> my goal.

By filling it with broken legacy crap like \r and "codepages"?? No
thanks.. Both of these can be done with trivial external tools if you
insist (tr/sed/iconv).

Rich