[gstreamer-bugs] [Bug 566604] Add RTMP client support

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=566604
  GStreamer | don't know | git

--- Comment #25 from Bastien Nocera <hadess at hadess.net> 2010-06-02 14:42:47 UTC ---
(In reply to comment #24)
> (In reply to comment #21)
> > (From update of attachment 162509 [details] [details])
> > The life-cycle of the RTMP object is horrible. So just a few notes:
> 
> What do you mean? It's one object per session.

You need a backing RTMP to use RTMP_SetupURL(), and that means re-parsing the
URL everytime you disconnect/reconnect.

I would have expected a separate URL object for example.

Note that RTMP_SetupURL() modifies the passed string in place, but you don't
know whether it takes ownership of the string or not.

> > - code is from rtmpdump-2.2e
> > - upstream code was copied, as they install a *static* library with a pc file
> 
> pkg-config stuff was added to ease integration with mplayer. I suggest you use
> "make XCFLAGS=-fPIC" to build a library that can be linked into shared code,
> that's what I use for libcurl.so.
> 
> Since the API is not frozen yet, it is too soon to be discussing a shared
> library target for librtmp.

You could write that in text, and have breakage expected. Having a static
library doesn't help here.

> > - upstream code was cleaned up to compile with GStreamer's warnings on, and
> > re-indented
> 
> The code uses GNU indent style. Frankly I prefer K&R style but it is what it
> is.

I also had to do quite a few code changes (private functions not marked as
static, declarations of functions which don't take arguments not having void in
their arguments, quite a few problems with const char * vs. char *).

Let me know if you want those upstream, and I'll send you a patch.

The indentation is a GStreamer-specific requirement.

> > - RTMP_Close() can't be used more than once (it frees some internal buffers)
> 
> RTMP_Close() frees everything associated with a session. What else would you
> expect it to do?

Not the same thing I'd expect from RTMP_Free()? :)

> > - additional properties (which I removed from the old plugin), probably need
> > adding back, at least the swfURL one or the plugin would only handle rtmpe
> > support.
> 
> I believe it would be a mistake to add specific support for individual librtmp
> options to applications; the maintenance burden will be pretty significant
> since new requirements turn up pretty frequently. Better to just take advantage
> of RTMP_SetupURL() and tack on arbitrary options to the URL.

OK. I'm only familiar with the RTMP protocol from my earlier attempts, but I
agree. If it's not necessary to use additional arguments, that means it'll work
better out of the box.

> Since the curl code just does a straight dump (no seeking) it's probably not
> the best model. You should also take a look at the ffmpeg support, which
> supports seeking.
> 
> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavformat/librtmp.c;h=dd7640aaebaf94315ba153835d3daa66ea77bb81;hb=HEAD

I was looking for it yesterday and couldn't find it. Thanks.

> The XBMC patch might also be illustrative
> 
> http://trac.xbmc.org/ticket/8971

Cool.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.