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.
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).
- 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).
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242041.html
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
