On 15/10/14 12:26, Martin Storsjö wrote:
> On Tue, 14 Oct 2014, Uwe L. Korn wrote:
>
>> ---
>> libavformat/rtmpproto.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
>> index 6e90a9f..5a1e331 100644
>> --- a/libavformat/rtmpproto.c
>> +++ b/libavformat/rtmpproto.c
>> @@ -2784,6 +2784,8 @@ reconnect:
>> goto reconnect;
>> }
>>
>> + s->is_streamed = 1;
>> +
>> if (rt->is_input) {
>> int err;
>> // generate FLV header for demuxer
>> @@ -2820,6 +2822,9 @@ reconnect:
>> if ((ret = inject_fake_duration_metadata(rt)) < 0)
>> goto fail;
>> }
>> +
>> + // If the stream is recorded or we know the duration, we can
>> seek.
>> + s->is_streamed = !(!rt->live || rt->duration > 0);
>> } else {
>> rt->flv_size = 0;
>> rt->flv_data = NULL;
>> @@ -2828,7 +2833,6 @@ reconnect:
>> }
>>
>> s->max_packet_size = rt->stream->max_packet_size;
>> - s->is_streamed = 1;
>> return 0;
>>
>> fail:
>> --
>> 2.1.2
>
> No, I don't agree with this. The is_streamed flag is about whether you
> can seek in byte units (in particular, it unlocks the byte level seek
> functions within AVIOContext), and this would allow the flv demuxer to
> try weird things like "seek to the end of the file, in order to read the
> final timestamp, for figuring out the duration", which you can't. (Yes,
> normally that wouldn't happen, but e.g. if rt->live == 0 and
> rt->duration == 0, this would cause the flv demuxer to try to do such a
> seek.)I was not fully aware that this would also affect the demuxer behaviour like this. As I fixed the duration detection for samples with the previous commit I was just not seeing this behaviour. > > Perhaps a separate signal is needed for whether the time based seek is > usable? As a first step you can always check whether > AVIOContext->read_seek is non-null, but something else to disambiguate > between live and seekable rtmp might be useful. Definitely a flag would be useful, I agree that the current patch is not the right way, so consider this last one as "dropped". > > // Martin > _______________________________________________ > libav-devel mailing list > [email protected] > https://lists.libav.org/mailman/listinfo/libav-devel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
