On Tue, 2019-10-01 at 15:57 -0400, Calvin Walton wrote: > On Tue, 2019-10-01 at 21:41 +0200, Carl Eugen Hoyos wrote: > > Am Di., 1. Okt. 2019 um 21:35 Uhr schrieb Raphaël Zumer < > > rzu...@tebako.net>: > > > On Tue, 2019-10-01 at 20:09 +0100, Derek Buitenhuis wrote: > > > > Why not just write zero? > > > > > > > > It's, to me, worse to leave a bogus 64-bit write to appease > > > > bugs > > > > in > > > > our > > > > own demuxer. It's confusing and misleading for any readers of > > > > the > > > > code. > > > > > > In that case I would prefer changing the initial written value to > > > 0 > > > rather than 0xFFFFFFFFFFFFFFFFULL. Writing over the unused bytes > > > twice > > > to get around an old error is a bit odd as well. > > > > That may needlessly break non-seekable output. > > Writing a 0 as the initial value is consistent with the behaviour of > libvpx. > > libvpx writes 0 initially: > https://github.com/webmproject/libvpx/blob/v1.8.1/vpxenc.c#L1191 > then updates afterwards with the length (if output is seekable): > https://github.com/webmproject/libvpx/blob/v1.8.1/vpxenc.c#L1209 > > (for reference, the ivf_write_file_header function is here: > https://github.com/webmproject/libvpx/blob/v1.8.1/ivfenc.c#L16 ) > > So we need to make sure that ffmpeg can handle 0 values in this field > regardless. >
For now I sent a patch in reply to Derek's message, which writes the length field as a 32-bit value explicitly, and zeroes out the unused bytes. But I agree that if ffmpeg cannot decode a zero length field properly, and this is how libvpx codes unseekable files, that is another problem. _______________________________________________ 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".
