On Wed, Feb 1, 2017 at 1:20 PM, Paul B Mahol <one...@gmail.com> wrote:
> On 2/1/17, wm4 <nfx...@googlemail.com> wrote:
>> On Wed, 1 Feb 2017 12:12:51 +0100
>> Paul B Mahol <one...@gmail.com> wrote:
>>
>>> Signed-off-by: Paul B Mahol <one...@gmail.com>
>>> ---
>>> libavcodec/Makefile | 1 +
>>> libavcodec/allcodecs.c | 1 +
>>> libavcodec/textstdec.c | 409
>>> +++++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 411 insertions(+)
>>> create mode 100644 libavcodec/textstdec.c
>>>
>
> [...]
>
>>> +
>>> +static void decode_presentation_segment(AVCodecContext *avctx,
>>> GetByteContext *gb, AVSubtitle *sub)
>>> +{
>>> + TextSTContext *s = avctx->priv_data;
>>> + unsigned ii, palette_update_flag, region_count;
>>> + int64_t start_pts, end_pts;
>>> +
>>> + start_pts = decode_pts(gb);
>>> + end_pts = decode_pts(gb);
>>> +
>>> + sub->pts = start_pts * 100 / 9;
>>
>> I don't think this will work. You should use packet timestamps, not get
>> them from the packet contents. Otherwise we'd be back to the situation
>> with other text subtitles, which used to embed timestamps in the packet
>> data.
>>
>
> pts are stored in packet, they are not available from packet timestamp.
>
> And this succesfully converts TextST to ass format.
In-band timestamps are fragile and don't work half the time. Many
use-cases rely on reading and potentially modifying packet timestamps,
and that just doesn't work if they then get overriden by the decoder -
ie. all sorts of code would need special cases to handle this kind of
stream.
Better to have something on our end that handles them and rips out the
in-band timestamps and puts them into the AVPacket straight out of the
demuxer.
- Hendrik
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
