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.rheinha...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".