Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
19th June 2019, 15:22 | #1 | Link |
契約者
Join Date: Jun 2008
Posts: 1,576
|
OPUS extraction with FFMPEG - length mismatch
Hey guys I need your help figuring out what is going on.
Below is a test file "test.opus" (but I see the same results with any file) https://www.dropbox.com/s/40d2kylu1p...test.opus?dl=0 Now let's make a webm out of it (ffmpeg -i test.opus -c copy test.opus.webm) Now let's extract our opus back using tho methods, mkvextract and ffmpeg (ffmpeg -i test.opus.webm -c copy test.opus.webm-ffmpeg_extracted.opus) so we get these 3 files: 1) test.opus 2) test.opus.webm-ffmpeg_extracted.opus 3) test.opus.webm-toolnix_extracted.opus now let's run opusdec on each of them (opusdec in.opus out.wav) and see the results: 1) wav PCM that is 341461 samples long 2) wav PCM that is 342408 samples long 3) wav PCM that is 341461 samples long The question is, why 2nd file never matches the original? And most importantly, how do I prevent this? Some other tests gave me ~24 samples mismatch, but this one is way off. Note that here I created webm's using ffmpeg, however if i would do it with mkvtoolnix the whole picture would be like so: ffmpeg extracts file created by ffmpeg -> length mismatch compared to reference ffmpeg extracts file created by mkvtoolnix -> mismatch compared to BOTH reference and previous result mkvtoolnix extracts both files -> both files match the reference Edit: the results are reproducible in foobar by simply playing both reference opus and muxed webm (because foobar uses ffmpeg to demux webm) Last edited by Keiyakusha; 19th June 2019 at 15:59. |
20th June 2019, 00:37 | #2 | Link |
Moderator
Join Date: Feb 2005
Location: Spain
Posts: 6,890
|
I can confirm the extra duration, seems a bug in ffmpeg. You can report it in https://trac.ffmpeg.org/
Most the times is not a big problem because add some ms, here 19, of silence at end of audio can't cause troubles.
__________________
BeHappy, AviSynth audio transcoder. |
20th June 2019, 16:03 | #3 | Link |
Registered User
Join Date: May 2016
Posts: 197
|
libavformat's ogg muxer ignores the AV_PKT_DATA_SKIP_SAMPLES side data (which in this case amounts to 947 samples (converted from 19729167ns in the Matroska source file)) that the Matroska demuxer attaches to the last packet. Yes, that's a bug.
|
20th June 2019, 19:27 | #4 | Link |
契約者
Join Date: Jun 2008
Posts: 1,576
|
I see, thanks guys. Well, it is unfortunate. Yes, the impact for simple playback is minimal, but I had to have gapless playback of the decoded stream. I thought maybe there is some kind of bitstream filter in ffmpeg that I've missed and that could magically solve the issue.
|
Thread Tools | Search this Thread |
Display Modes | |
|
|