[FFmpeg-devel] [PATCH] avformat/dashenc : Fix streaming mode support for webm output

[Jeyapal, Karthick]

On 4/8/19 7:37 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
> Karthick J via ffmpeg-devel:
>> ---
>>  libavformat/dashenc.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index f8d71166d4..9dd520787f 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -1750,10 +1750,10 @@ static int dash_write_packet(AVFormatContext *s, AVPacket *pkt)
>>      }
>>  
>>      //write out the data immediately in streaming mode
>> -    if (c->streaming && os->segment_type == SEGMENT_TYPE_MP4) {
>> +    if (c->streaming) {
>>          int len = 0;
>>          uint8_t *buf = NULL;
>> -        if (!os->written_len)
>> +        if (!os->written_len && os->segment_type == SEGMENT_TYPE_MP4)
>>              write_styp(os->ctx->pb);
>>          avio_flush(os->ctx->pb);
>>          len = avio_get_dyn_buf (os->ctx->pb, &buf);
>>
> Did you test this and did it really improve latency? Because it
> shouldn't. The matroska/webm muxer always uses its own internal
> dynamic buffer for writing the current cluster, i.e. most of your
> ff_write_chained() calls that write frames don't generate output at
> all. The only difference that your patch seems to make is flushing
> os->ctx->pb, which prevents the Matroska muxer from updating the
> clusters' length fields (writing clusters as unknown-length might
> worsen compability with some clients that don't support this).
>
> It might be that you write and send the cluster header (the cluster
> EBML ID + the cluster length field (this is not the real cluster
> length, but a length denoting "unknown length"; currently, this length
> field will be overwritten with the real size lateron) a bit earlier,
> but you don't send the actual packets earlier.
Thanks for your detailed reply. You are exactly right. 
Only the header gets written with the flush. Rest of the data arrives only after segment end.
>
> If you want to decrease latency, you basically have two options:
> a) You can explicitly flush the muxer (send a NULL packet). You
> probably want to use/adapt flush_dynbuf() for this.
> b) You can generally lower the cluster size and cluster time limits of
> the used Matroska muxer. Currently large limits are used for this. The
> Matroska muxer uses way lower default values in case the output isn't
> seekable (viewed from the Matroska muxer, the output is seekable).
Thanks for providing helpful suggestions.
I tried option b). It didn't work. Matroska muxer ignores cluster time and size limits for dash video outputs.
I want to try option a), maybe at a later time. For time being I have disabled streaming for webm format, and called it out explicitly.
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242429.html

>
> - Andreas
>
> PS: The above description of the Matroska muxer is based upon current
> git head. If [1] gets accepted, there will be two changes:
> 1. At first only the EBML ID and no length field at all will be written.
> 2. When the cluster is finally written, the length field will be
> written correctly and on the lowest number of bytes possible
> (currently it is always written on eight bytes).
Sorry for the dumb question. I don't have much knowledge on webm/matroska format.
If these changes get accepted, will it make it easier for me to implement low latency in dashenc for webm.
>
> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242041.html
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".