[MPlayer-users] how to play subtitles embedded in AVI files
inverseparadox at comcast.net
Sat May 21 03:55:57 CEST 2005
Alexander Noe' wrote:
> The Wanderer wrote:
>>> AVI-Mux GUI
>> Oh, is *that* the culprit?
> Probably. Wait till you get reports about mplayer not playing
> low-overhead-mode files ;)
Considering I've never even heard of that...
Then again, I'm not really a developer by a long shot, just an
interested and occasionally helpful bystander.
>> Depending on exactly what you mean by "allows" (i.e. how the
>> program tries to enforce the limitation), however, it's very simple
>> to avoid such a restriction; in the simplest type of enforcement,
>> it should theoretically be possible to stick the entire plain-ASCII
>> King James Bible in there if you just stick a .ssa or .srt suffix
>> on the end. If anything remotely like *that* is possible
> It is not, at least not in avi-mux gui, because it doesn't give a
> shit to the file name extension. You know, in order to split or join
> files with subtitles it has to reprocess the subtitle anyway (in case
> of SSA joining, it even has to redo the style definitions)
Okay, then I don't know what's going on, because there is *certainly* no
need to parse the subtitle file if you're just going to be inserting it
contiguous and verbatim into the AVI - which is what was done for the
only sample files I've seen so far. Since there's no need to parse the
file, there's no reason for the program to do it, and the only way it
could 'know' what format the file is in without parsing it is to rely on
the file extension. If it's in fact parsing the file *only* so as to
exclude all other formats... I don't have the least idea why anyone
would even *try* to do that.
As far as splitting and joining... shouldn't that be done with a
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
A government exists to serve its citizens, not to control them.
More information about the MPlayer-users