[FFmpeg-devel] [PATCH] lavf/matroskaenc.c: use dyn_buf to write header elements for non-seekable outputs.

Neil Birkbeck neil.birkbeck at gmail.com
Mon Oct 10 23:47:42 EEST 2016


On Sun, Oct 9, 2016 at 6:45 PM, James Almer <jamrial at gmail.com> wrote:

> 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.
>

Thanks for pointing that out. Indeed, as you say, that symptom is fixed in
head. I thought I had tested in head, although pasted output was admittedly
from an old version (doh).

There may be some value in the patch still, as the SeekHead is not written
in the given case (since the dynamic buffers for crc32 don't wrap all the
header data {seek_head, info, tracks, tags, attachments}, only the
individual elements):
+ Segment, size unknown
|+ EbmlVoid (size: 220)
|+ Segment information

With patch applied, and parsed from mkvinfo:
+ Segment, size unknown
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 149)
|+ Segment information
|+ Segment tracks

And it does allow crc32 to be written in streaming mode:

segment (47,-1) {
  seek_head (59,65) {
    crc_32: bytes(4)
    ...
  info (288,75) {
    crc_32: bytes(4)

Not sure if it is worth the additional complexity.


> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


More information about the ffmpeg-devel mailing list