Re: [Audacity-devel] [Audacity-quality] "FFmpeg : ERROR - Couldn't write last audio frame to output file." on m4a export

[Darrell W. <dar...@gm...>]

On Sun, Jan 21, 2018 at 1:53 PM, Paul Licameli <pau...@gm...>
wrote:

> Darrell, thank you for that explanation.  So tell me if my understanding
> sounds correct:
>
>
>    - This fix is sufficient, with your newer version of FFmpeg, to cause
>    the error dialog not to appear.  It does so neither skipping a proper
>    flush, nor by simply disabling the check.
>    - PTS and DTS are parts of FFmpeg designed to treat audio/visual data
>    in more generality than audio-only Audacity really requires.  PTS and DTS
>    advance by equal amounts per frame in the special cases that matter to us.
>    - Audacity might use PTS and DTS data when importing files to discard
>    the leading time-shift correctly, even if the files being imported were not
>    exported by Audacity.  That's a possible future fix.
>    - I may be using an older FFmpeg that imposes less strict requirements
>    while encoding audio and so reported no errors.  I observe no harm but no
>    benefit either from this fix.
>
> All correct so far. But ​I tested several versions and did not get any
error dialog. So no harm, and some benefit.

>
>    - Later FFmpeg may be more sensitive to this, and reported a non-fatal
>    error when encoding the last frame which still leaves a usable exported
>    file.  So if your fix is not present, Audacity could still detect this
>    error but should not abort the export needlessly.
>    - Audacity did detect this error but only to report it to the user,
>    not to stop the export.  That seems to have been wrong in principle but in
>    this case right in practice!  (See commit
>    e1cf05671090d3219c085e9c9d3103c74b92d8f1 that I just made for other
>    reasons to check more errors and properly abort export rather than quietly
>    leaving corrupted or incomplete files when you exhaust disk. See what I did
>    at line 754 of ExportFFmpeg.cpp to specially exempt this error.)
>
> Yes, with this patch, you still retain the error check/dialog and
recovery. It's a good idea to keep this in case of future breakage with
FFmpeg or past versions we haven't tested.


>    - If Audacity does contain your fix, it would eliminate the non-fatal
>    errors, and so it would be better to abort export for detection of errors
>    (for who knows what other reasons) at that place too.
>
> Then, the question of loss of final samples.  It may be that my old FFmpeg
> has a bug that is fixed in your FFmpeg.  I observe an equal amount of loss
> with or without the fix.  Do you observe that the fix corrects the loss too
> with your version?
>

There is no correction of the loss, I think that was a fluke with the test
file I was referencing in my PR comments.

​I believe the loss of samples is failure to pad the last frame out to a
full frame. Most likely the error stems from that. The FF devs are telling
me that audio codecs tend not to like un-full frames. It makes sense as the
sample loss is all less than one frame FWICT.