Hi Baptiste. I agree. This patch does cause it to fail in mov_write_header in the given example, by propagating the errors returned from mov_write_ac3_tag.
It is not always extradata related. Eg EAC3 parses the packets during muxing to build the dec3 atom. Perhaps this should be made extradata, but its not today. A definitely not extradata related example: mov_write_tmcd_tag can fail for fps reasons. Many atom writing functions can fail and return error codes, but today very little error checking exists. On Mon, Feb 4, 2019 at 5:22 PM Baptiste Coudurier < baptiste.coudur...@gmail.com> wrote: > Hi Nikolas, > > On Feb 4, 2019, at 5:02 PM, Nikolas Bowe <nbowe-at-google....@ffmpeg.org> > wrote: > > Fixes a problem where a sample entry which cannot be written correctly > appears to succeed, but produces an invalid file. > For example, this command: > ffmpeg -f lavfi -i sine=frequency=1000:duration=5 -codec:a ac3 -movflags > +empty_moov -frag_duration 5000000 /tmp/foo.mp4 > produced a file with the ac-3 sample entry, but no AC3SpecificBox (dac3) > child, which is invalid according to ETSI TS 102 366. > > > Ideally I feel that the code you fail as early as possible, so ideally > fail during “mov_write_header” if the issue is extradata related. > > […] > > — > Baptiste > > -- Nikolas Bowe | SWE | nb...@google.com | 408-565-5137 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
