[FFmpeg-devel] [PATCH] lavf/matroskaenc.c: use dyn_buf to write header elements for non-seekable outputs.
James Almer
jamrial at gmail.com
Mon Oct 10 04:45:46 EEST 2016
On 10/9/2016 10:13 PM, Neil Birkbeck wrote:
> For non-seekable output files, larger elements written in write_header
> (like larger attachments, or possibly many tags) can go over
> IO_BUFFER_SIZE meaning seeking back to write valid seek head may fail.
Ever since the CRC32 implementation, matroska files written to non
seekable output already do pretty much everything with dynamic buffers.
This behavior you mention should have been fixed by it.
>
> Fate test checksums are the same when "-write_crc32=0". Adding dyn_buf
> causes buffer to be seekable and so crc32 is written now (causing the
> diffs).
>
> Example to reproduce:
>
> mkfifo /tmp/a.fifo
> dd if=/dev/zero bs=1024 count=40 > /tmp/data
> ffmpeg -nostats -nostdin -y -f lavfi -i testsrc -vframes 1 \
> -attach /tmp/data -metadata:s:1 mimetype=test/data \
> -f matroska /tmp/a.fifo & cat /tmp/a.fifo > /tmp/a.mkv
> ffprobe /tmp/a.mkv
>
> Previously would generate file like:
> Duration: N/A, start: 0.000000, bitrate: N/A
> Stream #0:0: Video: mpeg4 (Simple Profile), yuv420p, 320x240 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 1k tbn, 25 tbc (default)
> Metadata:
> ENCODER : Lavc57.51.100 mpeg4
57.51.100?
> Stream #0:1: Video: mpeg4 (Simple Profile), none, 320x240 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 1k tbn, 25 tbc (default)
> Metadata:
> ENCODER : Lavc57.51.100 mpeg4
> Stream #0:2: Attachment: none
> Metadata:
> filename : data
> mimetype : test/data
> Stream #0:3: Attachment: none
> Metadata:
> filename : data
> mimetype : test/data
With current git head, I'm getting
Input #0, matroska,webm, from '/tmp/a.mkv':
Metadata:
ENCODER : Lavf57.51.103
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Video: mpeg4 (Simple Profile), yuv420p, 320x240 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 1k tbn, 25 tbc (default)
Metadata:
ENCODER : Lavc57.61.100 mpeg4
Stream #0:1: Attachment: none
Metadata:
filename : data
mimetype : test/data
After running your test case.
Are you sure you tested if this behavior was still present in current
git head before writing this patch? I'm asking because your pasted
output above reports an old lavc version.
More information about the ffmpeg-devel
mailing list