Loading a local xspf playlist with relative <location> paths doesn't work in 
VideoLan (the external player on WinXP at least).

Problem is noted here:
<https://trac.videolan.org/vlc/browser/modules/demux/playlist/xspf.c#L558>

Thoughts on improving things:

I noticed that if you provide an xml:base attribute (on the <playlist> element) 
that specifies a URI (file:///path in my case) to the directory the xspf file is 
in, things works fine.

What this means is that xspf.c should invent an xml:base value if the xml:base 
attribute is not present.

To invent an xml:base value, all xspf.c needs is the path to the .xspf file as an 
absolute *uri* (not platform path). Then, you can chop off everything after the last 
"/" and use that as a base path value. Then, xspf.c's existing path code will work 
better. (../ expansion etc. still won't work though, but things will be better).

For example, if I load:

file:///c:/documents%20and%20settings/user/desktop/server/playlist.xspf

, which contains relative <location> paths, and there's no xml:base attribute set on 
the <playlist> element, xspf.c should set p_demux->p_sys->psz_base to:

file:///c:/documents%20and%20settings/user/desktop/server/

, which will make relative <location> paths get resolved better.

In short, that'd be an improvement if someone knows how to do that. Sounds trivial
for someone that knows the codebase. And, inventing an xml:base should be O.K. 
for http URIs too. But, if one is worried about that, the code could choose to only 
invent an xml:base path if the path to the loaded playlist starts with "file://".

That is all noted by the "Last, psz_base should default to the XSPF resource location 
if missing (not the current working directory)." comment in xspf.c.

Basically, in the the Demux() function, change:

p_demux->p_sys->psz_base = NULL;

to

p_demux->p_sys->psz_base = get_absolute_uri_path_to_xspf_file_dir();

Then the get_absolute_uri_path_to_xspf_file_dir function would:

1. Get the absolute platform path to the loaded xspf file.
2. Convert that path to a URI.
3. return uri.substring(0, uri.find_last_of("/"));

It's obvious that the videlan codebase already has code to convert between platform
paths and file URIS, so implementing a get_absolute_uri_path_to_xspf_file_dir()
should be a case of just calling the right functions.

If you do things that way, in the  else if( !strcmp( psz_name, "xml:base" ) ) condition,
you'll need to do:

free( p_demux->p_sys->psz_base );
before doing:
p_demux->p_sys->psz_base = strdup( psz_value );

More complicated solution:

However, what *should* really happen is that the vlc xml parser should produce DOM 
objects like browsers do with xml:base (and <a href=""></a> with 
xmlns="http://www.w3.org/1999/xhtml"). Then, you should be able to pass the parser 
a list of elements whose textContent gets treated as a URI. Then, the parser would 
produce values that are automatically resolved to full absolute URIs by *properly* 
and *completely* supporting xmlbase, URI expansion and resolving specs. ('objects'
in the restraints of C code of course.)

xspf.c should only have to work with actually URIs and there should be platform code 
that takes care of converting a platform path to a URI and a URI to a platform path.

But, doing full support seems like a lot more work. Inventing a base is much easier and 
will go a long way.