[Live-devel] No ability to have directories under live555 Media Server

Ron McOuat rmcouat at smartt.com
Tue Jul 3 19:55:05 PDT 2007


The docs say the file must be in the mediaServer process directory. 
Turning on debug mode and recompiling the package reveals the reason a 
subdirectory for media is not functional. A URL of the form 
rtsp://<ip_address>/content/testx.m4e will result in 404 errors. The 
devil is the URL if it starts out as rtsp://<ip_address>/testx.m4e (no 
content subdirectory) is modified later to include the track number to 
be something of the form 
rtsp://<ip_address>/testx.m4e/track1;seq=29023;rtptime=646689728 so 
initially testx.m4e is parsed out as urlSuffix during DESCRIBE and later 
becomes urlPreSuffix for SETUP and PLAY. If the URL has a subdirectory 
then the subdirectory becomes the preSuffix in the first stage and is 
lost for the file existence tests during session creation resulting in a 
404 error and nothing futher is attempted. Tying to add subdirectories 
would mean a context sensitive parse of the URL would be needed along 
with preservation of the full file path in the session relative to the 
mediaServer directory. Also for Windows and possibly other systems the 
filesystem access would have to have path separator substitution. 
Probably I have missed aspects of this I do not yet understand.

My question - is there any interest in changing this so subdirectories 
are allowed for the mediaServer? I could look at doing this but don't 
really have a desire to support my own fork of the live555 code because 
my belief is there are significant changes and testing required which 
assuming I perform this in an acceptable way could be given back to the 
project. I tested a workaround which would be to take the hierarchical 
name and flatten it by removing the / separator and adding a symlink to 
the mediaServer directory that points to the hierarchical name and then 
use a URL referring to the media using the flattened name. This may be 
an adequate solution in my case.

Thanks for your consideration,
Ron McOuat


More information about the live-devel mailing list