[libav-bugs] [Bug 856] New: Output fails to play after muxing subtitles (.flv + .ass => .mkv)
bugzilla at libav.org
bugzilla at libav.org
Fri May 1 23:02:26 CEST 2015
Bug ID: 856
Summary: Output fails to play after muxing subtitles (.flv +
.ass => .mkv)
Assignee: bugzilla at libav.org
Reporter: _ at maxb.eu
I am using avconf to combine separate subtitles into a single container:
avconv -i input1.flv -i input2.ass -c:v copy -c:a copy output.mkv
I observed that after an OS upgrade, I started to see Matroska files which were
not properly playable - specifically, they would initally begin to play OK, but
at varying points into the video, the display would halt, even though the
player timestamp and progress bar would continue to progress.
In some instances, playback might eventually restart (at a later point in the
stream) if the player was left alone for a while. If an attempt to seek was
made, it would often resume video + audio playback, but subtitles would not be
I git bisected the problem, to reveal this commit as the one introducing the
Author: Luca Barbato <lu_zero at gentoo.org>
Date: Mon Jan 20 13:28:37 2014 +0100
lavf: improve handling of sparse streams when muxing
Currently ff_interleave_packet_per_dts() waits until it gets a frame for
each stream before outputting packets in interleaved order.
Sparse streams (i.e. streams with much fewer packets than the other
streams, like subtitles or audio with DTX) tend to add up latency and in
specific cases end up allocating a large amount of memory.
Emit the top packet from the packet_buffer if it has a time delta
larger than a specified threshold.
Original report of the issue and initial proposed solution by
mus.svz at gmail.com.
Signed-off-by: Anton Khirnov <anton at khirnov.net>
The bisection was interesting, as it revealed that multiple attempts to mux the
same input files would not deterministically produce an output which always
stopped playback at the same time. Rather, repeated muxing of the same input
showed there were various specific timestamps at which a pause would likely
Having read the comment in avformat.h introduced by that commit, I'd suggest
that the 'max_interleave_delta' logic introduced by the commit is faulty if one
of the streams involved is a text-based subtitle stream which can legitimately
contain no data for an extended period of time, if the video content currently
playing does not require subtitles for a while.
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libav-bugs