GLMediaPlayer Stream initialization

Does anybody know the reason for having GLMediaPlayer initialized using a URLConnection as a parameter?
I mean, further down the code only the URL string is actually used, not the actual URLConnection. Having URLConnection imposes the Java limitations on the supported  protocols while in fact it's the ffmpeg code which handles the protocols/parses the URL etc.
I have a project which requires playing live rtsp stream and couldn't do it with the original JOGL code. Had to modify the Java and some of the C code, recompile etc to make it accept just a String with the URL for the stream initialization.

Isn't it better if we replace the URLConnection parameter with a String and use the full potential of the ffmpeg, or am I missing something very obvious?

Any comments are most welcome!

On 08/06/2013 12:07 AM, Stefko [via jogamp] wrote:
> Does anybody know the reason for having GLMediaPlayer initialized using a
> URLConnection as a parameter?

Using a URL* is flexible in general,
since it also contains local file, jar etc
protocols - plus you can add your own URL handlers.

Using a URLConnection, states that a connection should have been
made already, i.e. resolved URL w/ opened stream.

Maybe this is even too much of a requirement ?

> Having URLConnection imposes the Java limitations on the
> supported  protocols while in fact it's the ffmpeg code which handles the
> protocols/parses the URL etc.

GLMediaPlayer does not consist out of our libav/ffmpeg implementation only,
i.e. the Android backend requires an URI.

An URI does not imply a resolved name and hence no connection has been made.

> I have a project which requires playing live rtsp stream and couldn't do it
> with the original JOGL code. Had to modify the Java and some of the C code,
> recompile etc to make it accept just a String with the URL for the stream
> initialization.
>
> Isn't it better if we replace the URLConnection parameter with a String and
> use the full potential of the ffmpeg, or am I missing something very obvious?

You made your point!

If we use an URI instead, we would loose the requirements
while still hinting to a 'proper' resource location protocol.

URI would also allow using the RTSP scheme/protocol
w/o requiring one to 'manually' implementing an URL handler in Java.

>
> Any comments are most welcome!

If you can provide a tested patch for us,
using an URI instead of URLConnection,
that would be great.

Otherwise you may be able to confirm that an URI
will solve this issue.

Thank you.

~Sven

Hi Sven !

Thank you very much for your quick reply !

As you point it out apparently using URI instead of simple String is a much better approach, it didn't occur to me so far.

Shame on me, but I have no knowledge of Android. But if as you say it requires just an URI, and not an active resolved connection, then again there is no use of the whole URLConnection object.

 If I can find some time I could update my version of the code to accept URI instead of plain String and will send you the source files.

I wish I could contribute more efficiently to the project but I'm afraid I'm not that good with git to provide proper patches. I'd rather give my modified source files to someone interested and more skilled who can use them properly in the source tree and possibly do some further modifications to match the coding style and philosophy of the project.
Or could just point where I made the modifications and the guys working on the code would do the rest.

BTW, on a slightly different topic, it took me some time to realize that the gluegen source I was compiling was not up to date with the latest ffmpeg binaries, so I had to dig in the ffmpeg web site for earlier bin distros to match the gluegen code. Apparently there's been some changes in C structures which prevented me to from using the latest ffmpeg compilation.

Since I'm not good at gluegen as well I can't tell how difficult it'd be to make it in sync with the current ffmpeg code, but perhaps someone could help in that direction.... if not already done, of course.

Thank you and good luck !