[FFmpeg-devel] [PATCH 01/23] avformat/matroskaenc: Fix ReferenceBlock timestamp

[James Almer]

On 12/24/2019 10:00 AM, Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
>> In order to indicate that the frames in a BlockGroup are not keyframes,
>> one has to add a ReferenceBlock element containing the timestamp of a
>> reference block that has already been written. The timestamp ought to be
>> relative to the timestamp of the block it is attached to. Yet the
>> Matroska muxer used the relative timestamp of the preceding block of the
>> track, i.e. the timestamp of the preceding block relative to the
>> timestamp of the cluster containing said block (that need not be the
>> cluster containing the current block). This has been fixed.
>>
>> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at gmail.com>
>> ---
>> Unchanged since last time.
>>
>>  libavformat/matroskaenc.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
>> index ba48aae454..90400de191 100644
>> --- a/libavformat/matroskaenc.c
>> +++ b/libavformat/matroskaenc.c
>> @@ -2165,9 +2165,9 @@ static void mkv_write_block(AVFormatContext *s, AVIOContext *pb,
>>          av_free(data);
>>  
>>      if (blockid == MATROSKA_ID_BLOCK && !keyframe) {
>> -        put_ebml_sint(pb, MATROSKA_ID_BLOCKREFERENCE, track->last_timestamp);
>> +        put_ebml_sint(pb, MATROSKA_ID_BLOCKREFERENCE, track->last_timestamp - ts);
>>      }
>> -    track->last_timestamp = ts - mkv->cluster_pts;
>> +    track->last_timestamp = ts;
>>  
>>      if (discard_padding) {
>>          put_ebml_sint(pb, MATROSKA_ID_DISCARDPADDING, discard_padding);
>>
> 
> I have just found out that the webm_chunk muxer takes lots of
> liberties with our API: It does not use the typical API muxing
> functions (avformat_write_header etc.), but instead calls the function
> pointers on its own (is this even legal outside of mux.c?). webm_chunk
> has been written at a time when init and deinit did not exist yet, so
> they are never called. This wasn't really a problem until the Matroska
> muxer switched to using an explicit deinit function in 982a98a0. Now
> there is a memleak. And if this patchset got merged now, it would
> absolutely break the webm_chunk muxer, because it moves several
> allocations to the init function. So the webm_chunk muxer needs to be
> fixed first.

Who's the maintainer for it? He should be CC'd.