[FFmpeg-devel] [PATCH] ffmpeg: Preserve input subtitle packet duration.

[Nicolas George]

Le sextidi 16 fructidor, an CCXX, Philip Langdale a écrit :
> And yes, it does nothing for inband timing, but that was always true -
> remember that until a few months ago, ffmpeg.c didn't propagate
> the packet duration at all, and you lost duration information if it was
> not already in-band. ie: We always relied on the fact that inband timing
> stayed inband all the way through the pipeline.

I am not sure what you mean here by "inband". After the subtitle has been
decoded, the place for the duration is AVSubtitle.end_display_time, IMHO.
And it does not need to be specifically propagated, since it is part of the
structure.

> Let's say I have an input sample that looks like this:
> 
> 00:00:03,056 --> 00:00:04,740
> 
> So it has pts 3056 and duration 1684.
> 
> These get rescaled to 1/100 values associated with the ass format
> subtitles: 306 and 168.
> 
> Then we try and construct the output sample. As we carry the pts
> value through, it uses 3056, but the current duration code takes
> the AVSubtitle value and rescales it back as 1680.
> 
> Now we've lost that 0.0004, which isn't a big deal from a user
> perception point of view, but messes up correctness, especially
> when we've got back-to-back subtitles.

I see the problem, and I can reproduce it, but I think the way you are
fixing is wrong. As far as I can see, the real problem is the SRT/SUBRIP
decoded not setting end_display_time. I just sent a pair of patch to fix
that, and it seems to fix the problem you are writing about too:

http://ffmpeg.org/pipermail/ffmpeg-devel/2012-September/130430.html
http://ffmpeg.org/pipermail/ffmpeg-devel/2012-September/130431.html

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120902/5b51d774/attachment.asc>