[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