[Matroska-devel] What's the best way to find the desired cue point?
12makoto28 at gmail.com
Thu Mar 8 06:23:45 CET 2012
Thank you all who replied, I'm sorry for my late response.
>That sounds like a bug. Or did you mean chapters entries ?
I was talking about Cues, not Chapters.
So this behavior should be a bug or a limitation.
>You don't even need to read the Cue points before playback starts. But
>when the user wants to seek in the file, you will need to read up to
>the timecode you want (+1 element if it's not the last). You can just
>read and not cache the values. It will be slower but saves memory.
So if I get to show a frame at 12345(timecode), I'll start reading
from the beginning to a record which has bigger than 12345, and back
one record (of the track), and start decoding. Does it make sense?
If yes, my concern will be solved, thanks!
Out of curiosity, is it possible to have cues for subtitle track and
put all frames to one dedicated cluster?
I'm thinking that how hard is it to embed subtitles to an existing mkv.
2012年2月25日2:43 Steve Lhomme <slhomme at matroska.org>:
> On 25/02/2012 09:29, Moritz Bunkus wrote:
>> On Sat, Feb 25, 2012 at 09:15, Steve Lhomme<slhomme at matroska.org> wrote:
>>>> So is it ok to have multiple cue points for one cue time?
>> Then it's a bug/limitation in libmatroska. mkvmerge simply calls
>> if it thinks that a block should turn up in the cues (criteria are:
>> audio/video track?, user requests about queues, time since previous
>> cue entry etc). The cluster is rendered with
>> cluster->Render(*out, *g_kax_cues);
>> and the cues themselves at the end of the file with
>> Seems to me that AddBlockBlob() should merge cue entries with the same
>> timecode instead of always creating a new one (haven't checked
>> libmatroska's source code yet).
> Yes, it should do that. More in my TODO.
> (unless you want to do it)
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> Read Matroska-Devel on GMane:
More information about the Matroska-devel