On 02/15/2017 10:09 PM, Luca Barbato wrote:
> On 15/02/2017 23:29, John Stebbins wrote:
>> ts_offset was added to cluster timecode, but then effectively subtracted
>> back off the block timecode
>> ---
>>  libavformat/matroskaenc.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
>> index e951a0f..2fe6e0e 100644
>> --- a/libavformat/matroskaenc.c
>> +++ b/libavformat/matroskaenc.c
>> @@ -1461,6 +1461,7 @@ static void mkv_write_block(AVFormatContext *s, 
>> AVIOContext *pb,
>>      uint8_t *data = NULL;
>>      int offset = 0, size = pkt->size;
>>      int64_t ts = mkv->tracks[pkt->stream_index].write_dts ? pkt->dts : 
>> pkt->pts;
>> +    ts += mkv->tracks[pkt->stream_index].ts_offset;
>>  
>>      av_log(s, AV_LOG_DEBUG, "Writing block at offset %" PRIu64 ", size %d, "
>>             "pts %" PRId64 ", dts %" PRId64 ", duration %" PRId64 ", flags 
>> %d\n",
>>
> What does it fix? should it go in stable?
>
>

When setting initial_padding for an audio stream, the timestamps are written 
incorrectly to the mkv file.
cluster timecode gets written as pts0 + ts_offset which is correct, but then 
block timecode gets written as
pts - cluster timecode which expanded is pts - (pts0 + ts_offset) .  Adding 
cluster and block tc back together
cluster tc + block tc = (pts0 + ts_offset) + (pts - (pts0 + ts_offset)) = pts
But the result should be pts + ts_offset since demux will subtract the 
CodecDelay element from pts
and set initial_padding to CodecDelay. This patch gives the correct result.

On a related subject, the code that processes avoid_negative_ts doesn't account 
for initial_padding
and results in offsetting timestamps when using an audio encoder that produces 
an initial_padding.
This offset is not technically necessary in the case of mkv since adding 
ts_offset results
in positive cluster and block timecodes.  Would it be appropriate to add an 
additional
AVFMT_AVOID_NEG_TS option that factors in initial_padding when checking for 
negative ts? This
would allow more faithful reproduction of original source timestamps when 
muxing to containers
that support it.

-- 
John      GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01  83F0 49F1 D7B2 60D4 D0F7


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to