[MPlayer-users] playlist file syntax

[James Gatt]

Reimar Döffinger wrote:

>Hi,
>  
>
>>>>The docs say that the playlist format is one file per line. So it doesn't
>>>>seem to be possible to make a playlist file that includes a playtree.
>>>>(Correct me if I'm wrong here.)  It would be useful to be able to specify,
>>>>say
>>>>
>>>>{ "song1.mp3" "song2.mp3" }
>>>>{ "song3.mp3" }
>>>>
>>>>in a playlist file.
>>>>
>>>>I've been thinking of modifying the source to expand the accepted syntax of
>>>>a playlist file.  Is this something other people would be interested in?
>>>>Any core developers want to comment on the likelihood of this patch being
>>>>accepted?
>>>>        
>>>>
>>>it won't be accepted, because it makes it impossible to play a
>>>playlist with a file named '{ "song1.mp3" "song2.mp3" }' in it!
>>>      
>>>
>>How is that useful? Do you know anyone who puts double quotes in filenames? I
>>know you *can*, but... After all, is there a way to put filenames containing
>>linefeeds into playlists? If not then there are already restrictions in the
>>filenames allowed by the playlist format over and above those of the file
>>system.
>>
>>    
>>
>>>there'd at least have to be an alternate format that you specify
>>>somehow.
>>>
>>>btw how is this useful? the only point of playtree is for assigning
>>>options to groups of files, right? otherwise a playlist is just as
>>>good...
>>>      
>>>
>>Particularly looping. It would be good to be able to specify options like
>>looping in playlists as well. Right now the playlist support is so basic that I
>>    
>>
>
>looping can also be done by adding a file multiple times...
>  
>

However, without the playtree construct you can't break out of the loop 
as no loop as such is defined.

>>don't think it offers anything more than can be achieved using a shell script
>>and just calling mplayer for each file to be played. To this end is it really
>>    
>>
>
>You can always achieve things with a script unless things that depend on
>the internal state of the program (e.g. crossfading or making the
>window stay in the same place, but those aren't possible with MPlayer
>anyway - well, with -fixed-vo a bit but not really)
>  
>

I only use mplayer for playing movies and television programmes. The one 
useful piece of continuity I want is for it to keep the TV output on and 
not re-initialise it between files. However it does not do this (yet), 
so a script does just as well for me.

>>worth defending the current playlist format against features offered by
>>non-core members?
>>    
>>
>
>Where comes the point to point out that you didn't answer the question
>what the feature you offer is. At least I didn't see it, only a proposal
>of a different playlist format.
>And by defending the current format is a way to make sure a new one isn't
>just a different piece of crap, but something really better. I guess we've had
>enough of that "let's replace that bug with another one" :-(.
>  
>

I do agree with not changing things for the sake of it, however I 
haven't yet seen what I would call a good reason for keeping the 
existing one, so if someone has good ideas for some features it wouldn't 
do any harm to listen rather than just say: "it won't be accepted, 
because it makes it impossible to play a playlist with a file named '{ 
"song1.mp3" "song2.mp3" }' in it!". (Which in itself looks like an even 
more ridiculous argument than I think was intended, unless the sarcasm 
was deliberate.)

>>I am having this rant because I've seen a lot of derogatory comments made to
>>people asking innocent and often valid questions on this list. It is foolish
>>    
>>
>
>Some people might see it as derogatory that you decide what is innocent
>or valid...
>  
>

I don't see your point. I see comments that appear to me to be innocent 
and valid, and people get flamed for writing them, like they are "lower" 
beings than the "developers". That's out of order. I know it can get a 
little bit frustrating when someone hasn't read and understood the right 
section of the manual, but in that case the right thing to do is either 
help them or shut up. I no way is it the right thing to be hostile, and 
I've seen that on this list recently. I am not going to cite examples 
because I don't want this to become personal.

>>for the core mplayer team to believe that everyone else is incapable of coming
>>up with useful ideas and writing good code for them. If it is made too hard for
>>people to submit patches that are accepted, then mplayer development will simply
>>fork.
>>    
>>
>
>I fail to see a fork as a threat.
>Anyway, quite a few people are active a few months
>and then aren't reachable by email forever, meaning that we are stuck with
>maintaining their patches. I have little motivation for applying a
>patch when I think that it will be a pain in the a** to maintain it, no
>matter how well it may work at the moment.
>  
>

If a fork occurred and several people decided they were interested in 
improving the "other" version, then these people are a resource you have 
lost access to. It won't make the original mplayer any worse, but it 
won't help it improve either.

A patch that will be difficult to maintain is not usually the best way 
of solving the problem the patch was written for. However, quite a lot 
of the mplayer code has clearly evolved much since it was originally 
architected, and this alone can make for difficult maintenance.

>>I have some patches that fix issues and crashes I have come across in mplayer. I
>>have not submitted them because I feel in the current climate they might not be
>>welcome. This doesn't hurt *me*, as my version of mplayer no longer suffers
>>    
>>
>
>They are never not welcome. Of course if it does something that seems
>really stupid to someone you might get a flame. So what? I promise, you
>won't even feel the heat physically, not to mention really get hurt.
>Btw.: I never got into something that I consider a flame myself. So I
>also tend to think that those who do aren't really innocent...
>Much more probable is that you get ignored - I'm sure that can happen to
>you in the case of other projects just as well. MPlayer code is tricky
>in many places and people often don't feel motivated to try to
>understand what exactly a patch changes...
>  
>

Such is the beauty of open source - I can fix the bug even if nobody 
else is interested.

>>from these problems, but it hurts all other mplayer users who suffer from these
>>problems and don't know how to fix them - unless / until someone else fixes them
>>and submits a patch that will be accepted. Until the attitude on the mplayer
>>lists changes a *lot* to the better and more welcoming, this will not change.
>>    
>>
>
>I don't know how you wanted it to sound but here is what this sounds
>like to me:
>You expect others to change the way you want them to be
>before you share your improvements to their code with them?
>I certainly hope this is a misunderstanding...
>  
>

I probably didn't express that very well. Right now I feel that mplayer 
is much more "closed" than other projects I have experienced. I don't 
know how many "bad" patches the mplayer developers get from people, but 
the code itself is not clean and definitely looks like a work in 
progress. I am not knocking it - I take it as I see it, and if it suits 
my purpose then I use it.

I don't like power-hungry empire builders, especially in open-source 
projects. I understand the need for people assigned responsibility for a 
piece of code to be able to vet what goes into it, of course they have 
to do that. Every time I hear of a patch being refused I wonder "was it 
really bad?". I get the feeling that any patch I offer would be refused 
for some or other (probably very petty to me) reason - there seems to be 
a strong culture of preserving the status quo rather than moving on. 
That's just the feeling I have gained from reading the mplayer lists for 
the past few months. I hope I am wrong.

>>(This is not aimed at any one person by the way - It's certainly not aimed
>>directly to Mr. Felker's post to which I have responded.)
>>    
>>
>
>I'm undecided whether that is a good or a bad thing, but I tend to the
>latter - it's hard to defend against something that is directed at
>nothing.
>
>  
>

It is directed much more generally than to one person. I was just 
reading once more the words to describe "your idea won't be accepted by 
the gods because I've thought of a problem with it", rather than 
something perhaps a little more constructive, like a suggestion of how 
to solve both the need for improvement and backward compatibility. To be 
this negative to someone who's only offering to improve mplayer does not 
encourage me to want to put myself in that position. That is what made 
me write my original reply - the message is simple: If you are that 
negative, you will put people off, and sometimes it doesn't take much.

To all mplayer developers: I hope I have not offended anyone - that is 
not my intention. I am trying to be constructive in saying "be careful 
how you treat the people who want to help you".

Regards,
James.