[FFmpeg-devel] [PATCH] libavformat: libavformat: output cues for each subtitle block in MKV muxer

[John Peebles]

Is the link I provided sufficient evidence that the correct behavior is to
write one cue per subtitle block?

Maybe it would also be helpful if I gave a concrete example of why ffmpeg's
current behavior is problematic. Suppose we have 2 subtitles that both
start at timecode 1 second. The first subtitle has a duration of 1 second
and the second subtitle has a duration of 2  seconds. Now suppose I want to
seek to 2.5 seconds. The only cue data is for the first subtitle (which
does not overlap with timecode 2.5 seconds) so I will have no way of
knowing that there is a subtitle I should display.


On Sun, May 25, 2014 at 11:00 AM, John Peebles <johnpeeb at gmail.com> wrote:

> > Are you sure this is how it's supposed to work?
> The proposal for adding the CueDuration and CueRelativePosition
> elements indicates that this is the correct behavior. It says:
>
> > With the proposed
> > change a muxer could include all subtitle blocks and their duration in
> > the cues and a splitter would have all the information required to
> > display the subtitles directly after seeking.
>
> See http://lists.matroska.org/pipermail/matro
> ska-devel/2012-September/004249.html
> for the full email thread.
>
>
> On Sun, May 25, 2014 at 10:28 AM, wm4 <nfxjfg at googlemail.com> wrote:
>
>> On Sun, 25 May 2014 10:05:24 -0400
>> John Peebles <johnpeeb at gmail.com> wrote:
>>
>> > > This patch doesn't apply on FFmpeg git master.
>> > The new version attached should apply.
>> >
>> > > please do not include re-indent change into the patch
>> > done
>> >
>> > > Can you also provide a sample and command line to reproduce?
>> > Sure.
>> > (1) Download the attached same-time-script.mkv file. Note that while
>> > this file only contains a subtitle track in order to keep the file size
>> > down,
>> > the bug still happens even if there are other tracks.
>> > (2) Run ffmpeg -i same-time-script.ass -c copy -map 0 bad.mkv
>> > (3) Inspect the ebml data in bad.mkv. Notice that while there are two
>> > subtitle blocks (one for each of two different subtitles), there is
>> only a
>> > CueTrackPositions element for the first block. There should be one for
>> > each block.
>> >
>> > > Is the issue you are fixing the same as ticket #3149?
>> > No, this patch only deals with cues for subtitle tracks, not audio
>> tracks.
>> >
>>
>> Are you sure this is how it's supposed to work? The sample file you
>> posted has two cue entries for the same time. I think it should have
>> only 1 entry, pointing to the first packet. Is it documented somewhere
>> how this should work? (I know it's not in the "specification".) The
>> fact that your sample was apparently produced by mkvmerge doesn't say
>> much; redundant cues are probably ok, but the question is whether
>> they're "needed".
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>