On Wed, May 2, 2012 at 5:00 PM, Luca Barbato <[email protected]> wrote:

> On 02/05/12 02:19, Samuel Pitoiset wrote:
> > On Wed, May 2, 2012 at 11:09 AM, Martin Storsjö <[email protected]>
> wrote:
> >
> >> On Wed, 2 May 2012, Samuel Pitoiset wrote:
> >>
> >>  ---
> >>> libavformat/rtmpproto.c |    5 ++++-
> >>> 1 files changed, 4 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
> >>> index 9cdb639..9a02db2 100644
> >>> --- a/libavformat/rtmpproto.c
> >>> +++ b/libavformat/rtmpproto.c
> >>> @@ -66,6 +66,7 @@ typedef struct RTMPContext {
> >>>    int           chunk_size;                 ///< size of the chunks
> RTMP
> >>> packets are divided into
> >>>    int           is_input;                   ///< input/output flag
> >>>    char          *playpath;                  ///< stream identifier to
> >>> play (with possible "mp4:" prefix)
> >>> +    int           live;                       ///< 0: recorded, -1:
> >>> live, -2: both
> >>>    char          *app;                       ///< name of application
> >>>    ClientState   state;                      ///< current state
> >>>    int           main_channel_id;            ///< an additional channel
> >>> ID which is used for some invocations
> >>> @@ -287,7 +288,7 @@ static void gen_play(URLContext *s, RTMPContext
> *rt)
> >>>
> >>>    av_log(s, AV_LOG_DEBUG, "Sending play command for '%s'\n",
> >>> rt->playpath);
> >>>    ff_rtmp_packet_create(&pkt, RTMP_VIDEO_CHANNEL, RTMP_PT_INVOKE, 0,
> >>> -                          20 + strlen(rt->playpath));
> >>> +                          32 + strlen(rt->playpath));
> >>>    pkt.extra = rt->main_channel_id;
> >>>
> >>>    p = pkt.data;
> >>> @@ -295,6 +296,7 @@ static void gen_play(URLContext *s, RTMPContext
> *rt)
> >>>    ff_amf_write_number(&p, ++rt->nb_invokes);
> >>>    ff_amf_write_null(&p);
> >>>    ff_amf_write_string(&p, rt->playpath);
> >>> +    ff_amf_write_number(&p, rt->live);
> >>>
> >>
> >> So, passing -2 here is equivalent to leaving it out, as we did before?
> (I
> >> haven't read the spec about this.)
> >
> >
> > Indeed, -2 is the default value of that parameter. In this case, the
> > subscriber first tries to play the live stream and if it's not found it
> > tries to play the recorded stream. If you pass -1, only the live stream
> is
> > played. And if you pass 0, only the recorded stream is played.
> >
> >
> >>
> >>
> >>>    ff_rtmp_packet_write(rt->**stream, &pkt, rt->chunk_size,
> >>> rt->prev_pkt[1]);
> >>>    ff_rtmp_packet_destroy(&pkt);
> >>> @@ -1050,6 +1052,7 @@ static int rtmp_write(URLContext *s, const
> uint8_t
> >>> *buf, int size)
> >>>
> >>> static const AVOption rtmp_options[] = {
> >>>    {"rtmp_app", "Name of application to connect to on the RTMP server",
> >>> OFFSET(app), AV_OPT_TYPE_STRING, {.str = NULL }, 0, 0, DEC|ENC},
> >>> +    {"rtmp_live", "Specify that the media is a live stream.",
> >>> OFFSET(live), AV_OPT_TYPE_INT, {-2}, -2, 0, DEC},
> >>>    {"rtmp_playpath", "Stream identifier to play or to publish",
> >>> OFFSET(playpath), AV_OPT_TYPE_STRING, {.str = NULL }, 0, 0, DEC|ENC},
> >>>    { NULL },
> >>>
> >>
> >> I'd like to have info about the parameter values here in the description
> >> too - users of the protocol code are more likely to read it there than
> from
> >> the code comment above.
> >>
> >> "Specify that the media is a live stream (0: recorded stream, -1: live
> > stream, -2: both)." It's better ?
> >
>
> Make AV_OPT_TYPE_CONST options so people can use mnemonics.
>

Okay.


>
> Beside that, did you test it? I hadn't compared its output to the
> librtmp one but seems that at least certain rtmp servers aren't
> responding as expected. I'll get you a bunch of test places soon.
>

Yes, I tested it a lot and it seems to works fine. Anyway, a bunch of test
would be very appreciable.

>
> lu
>
> --
>
> Luca Barbato
> Gentoo/linux
> http://dev.gentoo.org/~lu_zero
>
> _______________________________________________
> libav-devel mailing list
> [email protected]
> https://lists.libav.org/mailman/listinfo/libav-devel
>



-- 
Best regards,
Samuel Pitoiset.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to