On Wed, 2 May 2012, 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 ?

Yes, that sounds ok to me.

// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to