[FFmpeg-devel] [PATCH 2/2] lavc/dvdsub_parser: parse start and end times.

Hendrik Leppkes h.leppkes at gmail.com
Sun Jan 26 21:08:37 CET 2014


On Sun, Jan 26, 2014 at 8:44 PM, Derek Buitenhuis
<derek.buitenhuis at gmail.com> wrote:
> On 1/26/2014 6:50 PM, Nicolas George wrote:
>> I need to dig back into it to remember what it is about and what needs to be
>> done; this is not very high in my list of priorities, but I can raise it a
>> bit.
>
> OK.
>
>> If you want to take it over, do not hesitate.
>
> Maybe...
>
>> If not, maybe you can say a few words about what is said about it on
>> #matroska?
>
> [04:20] < fundies> [greg at greg-desktop 15]$ mkvextract tracks dvd.mkv 2:vobsub
> [04:20] < fundies> Error: Track 2 with the CodecID 'S_VOBSUB' is missing the "codec private" element and cannot be extracted.
> [04:20] < fundies> any way to extract the vobsubs?
>
> [...]
>
> [09:39] < Mosu> fundies: Not with mkvextract, no.
> [09:40] < Mosu> You could simply patch that part out and re-compile, of course.
>
> [...]
>
> [20:08] < fundies> Mosu, cant you just fix it upstream? Shouldn't it really be a warning not an abort mission?
> [20:11] < Mosu> fundies: Well, it's not VobSub without the CodecPrivate stuff. That's the whole .idx file of the .idx/.sub pair.
> [20:13] < Mosu> Though I wouldn't reject patches that turn this into a warning and skip writing the .idx. The warning would have to be clear why the .idx isn't created.
> [20:17] < fundies> you must be able to generate an idx from just the .sub somehow as players know what time to display the subs without them
> [20:22] < Mosu> That's not the problem; the timestamps are indeed part of the Matroska cluster/block structure. They're therefore not stored in CodecPrivate. So creating the .sub without CodecPrivate is perfectly possible. But the .idx part contains information that simply is not available in the .sub part, and if it's not present in CodecPrivate then it cannot be created. If you look at an .idx file then everything but the "timestamp:" lines is what's unique to ...
> [20:22] < Mosu> ... the .idx file, and that information is simply not recreatable. Yes, you can play the .sub without the palette information etc. But I haven't seen one legitimate file that does this.
> [20:22] < Mosu> Anyway, like I said, I'm open to patches. I just won't do it myself as I have no such files and currently no interest in spending the time on it. Sorry.
> [20:23] < fundies> I'm not a programmer so I couldn't fix it
> [20:24] < fundies> also ffmpeg always generates files like this
> [20:24] < Mosu> Then don't use ffmpeg.
> [20:24] < fundies> I have to
> [20:25] < fundies> dgindex causes desync
> [20:25] < Mosu> I've already spent eight hours coding today, and I seriously am not in the business of granting everybody's wishes. So I'm sorry, but no.
> [20:43] < Rodeo> someone should really fix ffmpeg then
> [20:43] < Daemon404> ... or even report it
> [20:43] < Rodeo> if it actually doesn't write CodecPrivate for VobSub
> [20:43] < Rodeo> yeah, that too
> [20:43] < fundies> it is reported and theres a patch
> [20:43] < Rodeo> fundies: surely you can do that, if you have a reproducible test case?
> [20:43] < fundies> but is been ignored
> [20:43] < Daemon404> fundies, link
> [20:43] < Daemon404> i will try and push it through
> [20:43] < Rodeo> ah, where is the report please
> [20:44] < fundies> h/o lemme find it
> [20:44] < wm4> ffmpeg generates what?
> [20:44] < wm4> vobsubs without codec private?
> [20:44] < Daemon404> apparently
> [20:44] < fundies> http://trac.ffmpeg.org/ticket/2035
> [20:44] < wm4> how evil
> [20:45] < wm4> oh I see
> [20:45] < wm4> remuxing from VOB
> [20:45] < Daemon404> fundies, added to my TODO for tomorrow
> [20:45] < wm4> I don't know much about this stuff, but I'm not sure if ffmpeg can even get the "codec private" from this?
> [20:45] < wm4> e.g. libdvdread returns this information separately from the mpeg stream
>
>
> [...]
>
> [20:47] < Rodeo> well, we could create a "default" palette, which might be considered better than no palette at all
>
> - Derek
>

Just my 2 cents, just judging from the ffmpeg decoder implementation:
Its actually better to let it "guess" the palette based on the encoded
frames, then to try to feed it some default palette. It can apply more
smarts based on which colors are actually used to guess the palette,
than any plain default ever could.

Of course that doesn't solve the muxing problem.


More information about the ffmpeg-devel mailing list