[MPlayer-users] Containers, GMC, PSNR, and doom9
The Wanderer
inverseparadox at comcast.net
Thu May 11 08:28:16 CEST 2006
(Sorry for the delay - this is the first chance I've had to read E-mail
without a thirty-minutes-or-less deadline since the last reply, and I
didn't want to just dash off a response without the chance to think
about it.)
Alexander Noe' wrote:
> The Wanderer schrieb:
>
>> Right. That makes sense.
>>
>> I would, however, consider it preferable - and, I think, reasonable
>> - for the user to have the option to choose to do it "correctly"
>> (i.e., with headers as stored in stream headers and chunks
>> interleaved throughout the file) instead of "in the way which is
>> supported by Media Player Classic"; I understand that you do not
>> necessarily have the time to spend on random subprojects, but what
>> are the chances that you might add something like this to AVI-Mux
>> GUI?
>
> The question would then be: What would be the use of this?
The advantage would lie in the fact that it would then be possible for
someone who *wants* to do it the Right Way to do so. Currently, that is
not possible, unless the person also has the ability, time, and interest
to code the necessary muxing software - which is rather unlikely.
If you do not see how this is a noticeable advantage, then I suspect
that our views of the relative importance of principle are sufficiently
different that there's unlikely to be any chance of my convincing you.
It's still something I'd like to see, however.
> * It's highly unlikely that any hardware mpeg4 player will ever
> support such a format -> no change
Not especially relevant, IMO; hardware players are not the be-all
end-all point of such things.
> * people who don't want to use a hardware mpeg4 player can convert
> their files to mkv easily and can play mkv files easily
...have you *seen* some of the rants by the less technical against
having to install the necessary demuxers, codecs, et cetera to be able
to even *play* MKVs (or, for similar if less-related vitriol, H.264),
much less *create* them?
Not to mention that this presumes the availability of a fully compliant,
characteristic-preserving (timestamps, stream sync, et cetera) Matroska
muxer which is capable of parsing out the one-chunk subtitles from an
AVI and then separating them into the appropriate multiple chunks for
remuxing. Since you have assumed such a muxer to exist, and since I know
offhand of no programs other than the ones mentioned in this discussion
which support such one-chunk subtitles at all, I infer that (despite the
name) your own AVI-Mux GUI is capable of doing so; is this correct?
> So the only gain would be to have a nice proof-of-concept that is not
> backward compatible to existing subtitle renderers and requires a
> lot of tools to be updated, just because of a proof-of-concept.
I don't see how the existence of the implementation itself would require
that other tools be updated. Only if it begins to catch on, if people
begin to actually *use* the option (which I'll note would be a little
unlikely if they knew that it was not yet supported for playback), would
such updates be required - and then, they would in fact be appropriate.
I do have some not-especially-verbal objections to referring to it by
the term "proof-of-concept", but I'm not entirely sure how valid they
are. For the rest, see above about the importance of principle.
> IMHO, this is a real misrelation between gain and cost, especially
> considering the amount of time I could spend on it atm...
I *did* say that I understand that you do not necessarily have the time
to spend on random subprojects... I was simply asking the question.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
More information about the MPlayer-users
mailing list