[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


https://bugzilla.libav.org/show_bug.cgi?id=856

            Bug ID: 856
           Summary: Output fails to play after muxing subtitles (.flv +
                    .ass => .mkv)
           Product: Libav
           Version: 10
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: ---
         Component: libavformat
          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
displayed.

I git bisected the problem, to reveal this commit as the one introducing the
problem:

commit d9ae1031f5edbd25c8526b4cb51aba66d3bee931
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.

    Bug-id: 31
    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
occur.

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...
URL: <http://lists.libav.org/pipermail/libav-bugs/attachments/20150501/41d01c4f/attachment.html>


More information about the libav-bugs mailing list