[MPlayer-dev-eng] Small changes to subreader.c file
Adam Tlałka
atlka at pg.gda.pl
Sat Oct 8 20:22:04 CEST 2005
Dnia Sat, 08 Oct 2005 17:36:29 +0200, Rich Felker <dalias at aerifal.cx>
napisał:
> 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...
It is not a broken format - this is the SRT format as it was first designed
by SubRip creators. It is Windows text file which means CR-LF in it.
Your format is not a SRT file - it is some variation of it but not
original format.
> 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 know a few Unix programs which can edit subtitles and export SRT files
and there
are "\r\n" line endings in produced output. Jubler for example.
Next if you must edit this file with text editor then use Vim editor.
It has no problems with line endings and doesn't change original format.
In my opinion if we do generate SRT files then they should be in original
format
and encoding without need for additional processing.
> It's a text file. Text files should always be in the native format.
No, it is a SRT file which means that format is defined.
> Even more stupidity. Text files should also always be utf8.
Yes and we all need world peace.
Again - this is a SRT file not a text file. Generally I agree with utf8
usage
but this format wasn't defined as this kind of data.
> 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).
It's just a legacy format so it should be generated properly without need
for using external stuff or you should write clearly in the man page that
mplayer
doesn't produce original SRT format but just an utf8 encoded Unix text file
variation of original format. Compatibility is important or you are doing
like
MS defining your "proper" solutions.
Regards
--
Adam Tlałka mailto:atlka at pg.gda.pl ^v^ ^v^ ^v^
System & Network Administration Group ~~~~~~
Computer Center, Gdańsk University of Technology, Poland
PGP public key: finger atlka at sunrise.pg.gda.pl
More information about the MPlayer-dev-eng
mailing list