On Wed, May 2, 2012 at 5:12 PM, Martin Storsjö <[email protected]> wrote:
> On Wed, 2 May 2012, Luca Barbato 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. >> >> 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. >> > > Btw, according to the librtmp sources, the same parameter is used as time > for seeking to, in recorded files, and librtmp seems to send -1000 as value > for live streams? Or is it just a different scaling used for the values? > I didn't read that part of code in librtmp. However, I read the RTMP specification and the value for live streams is -1. http://www.adobe.com/devnet/rtmp.html (page 55) So, I guess it's just a different scaling, yes. > // Martin > _______________________________________________ > 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
