GNOME Bugzilla – Bug 729317
audioencoder: error when transcoding ogg vorbis to matroska flac audio with ges
Last modified: 2018-11-03 11:29:58 UTC
Created attachment 275525 [details] 8 second 440 Hz sine wave with 44.1 kHz sample rate, generated by Audacity When a ogg audio clip is placed twice the following error happens: $ ges-launch-1.0 --outputuri output.mkv --track-types audio --format video/x-matroska:audio/x-flac,channels=1,rate=44100 /tmp/sine.ogg 0 5 /tmp/sine.ogg 5 5 Adding clip file:///tmp/sine.ogg inpoint:0:00:00.000000000 duration:0:00:05.000000000 Adding clip file:///tmp/sine.ogg inpoint:0:00:05.000000000 duration:0:00:05.000000000 ERROR from element flacenc0: received more encoded samples 4608 than provided 1388 Debugging info: gstaudioencoder.c(882): gst_audio_encoder_finish_frame (): /GESPipeline:gespipeline0/GstEncodeBin:internal-encodebin/GstFlacEnc:flacenc0 Note the error does not happen if the clip is just used once.
Perhaps this is related to bz#729314 or bz#729315 which are triggered with this input ogg file.
$ ges-launch-1.0 --outputuri /tmp/output.mkv --track-types audio --format video/x-matroska:audio/x-flac,channels=1,rate=44100 /tmp/sine.ogg 0 5 /tmp/sine.ogg 5 5 Adding clip file:///tmp/sine.ogg inpoint:0:00:00.000000000 duration:0:00:05.000000000 Adding clip file:///tmp/sine.ogg inpoint:0:00:05.000000000 duration:0:00:05.000000000 **osition: 0:00:04.806530612 duration: 0:00:10.000000000/> ERROR:gstaudioencoder.c:745:gst_audio_encoder_finish_frame: code should not be reached Aborted (core dumped) Seems to be the same as you get. I also get this with the patches to fix sample accurate transcoding, so this is a different issue it seems (or one that needs further fixing anyway).
flacenc gets data till it receives a NULL buffer to drain it. It never gets an EOS/stop after that, but more data, and it's not prepared for that, and continues outputting data where it was before, and the base class isn't prepared for that. A NULL buffer is meant for draining, but flacenc only supports that at EOS. Is it a valid behavior from the base class to drain without restarting ? If so, then flacenc will need to tear down the libFLAC encoder and restart it as it doesn't seem to include a reset function.
It seems it is valid behavior, so I will patch flacenc to support this according to the base class' expectations.
This is rather annoying, actually. There seems to be no way to tell libFLAC to write the data for any samples it currently has queued, and destroying and recreating the encoder state will also write metadata headers, which we do not want here. I guess one way out might be to detect those headers in the write callback and not write them out, but that seems very hack and possibly unsafe if libFLAC decides to write different headers than for the previous run (I've no idea if it can, though it seems fairly improbably given we use the same settings as before). And might not be easy if libFLAC writes those headers in arbitrarily sized write calls. Maintainers, would such a hack be acceptable ?
After playing a bit with it, intercepting seeks and writes to avoid header rewriting and new headers for the new encoder does not actually work, and timing would be wrong when using fixed size blocks, as the leftover samples from the drain coming from the base class would only fit part of the block time. So I think after all the fix for this bug should be at a higher level, maybe GES, and not try to drain flacenc.
What is the reason why it is draining?
That's when one of the inputs EOSes.
Created attachment 278277 [details] [review] do not reset encoder on continuous segment change I have no idea what I'm doing here, but this seems to fix the issue, at the cost of seeming iffy. Not resetting the adapter will let the base class keep memory of those samples it pushed earlier, and thus not balk when the derived class calls _finish_frame later with an encoded frame containing samples from both before and after the new segment. Since there is a reset already done on flush-stop, this should only be changed in continuous changes, so hopefully not break anything, but I don't know enough to be certain of that. The resulting file is 25 seconds though, rather than the 13 seconds I'd be expecting, if my understanding of what the command line is meant to do is correct. Same when using wav as output, so not a flac issue anyway.
Should we move that bug to -base against AudioEncoder baseclass as it looks like this is where the issue stands right? (btw I tested again today and it *does* still fail)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/119.