On Fri, 24 May 2013, Sebastian Andrzej Siewior wrote:
My URL looks the following: rtmp://vod.daserste.de:8080/ardfs/mp4:videoportal/mediathek/Plusminus/c_320000/321891/format406703.mp4?&sen=Plusminus&clip=%27Al…
and the parser creates interprets this as:
app : 'ardfs/mp4:videoportal/mediathek' path: 'mp4:Plusminus/c_320000/321891/format406703?&sen=Plusminus&cl…
The application is too long, as it is only "ardfs" and as a result the playpath gets wrong. I have no idea why it looks for so many slashes because the application should end after the first slash before the mp4: string. Commit f3e3e6b5 ("Look for a fourth slash when splitting the url into app+playpath") added even another one and I have no idea why.
Well, the reason is pretty obvious - given a url like rtmp://server/a/b/c/d/e/f, there's nothing that says which part is the app and which is the playpath. So far the assumption has been to use most of the path as app, and the rest as playpath (only taking a fixed number of path segments probably because the implementation was lazy or so). And changing it back would just break one case and fix another one. The fact that you can use mp4: or mp3: as indication of where the playpath probably start is a better heuristic than what the lazy implementation so far has done, and the patch looks good to me. However, in general one can't expect the heuristic to handle every single case - if in doubt one can always pass them separately. // Martin