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.

 

Go Back   Doom9's Forum > General > Audio encoding

Reply
 
Thread Tools Search this Thread Display Modes
Old 19th June 2019, 15:22   #1  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
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)
Attached Files
File Type: 7z test.7z (122.1 KB, 3 views)

Last edited by Keiyakusha; 19th June 2019 at 15:59.
Keiyakusha is offline   Reply With Quote
Old 20th June 2019, 00:37   #2  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 5,612
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, in Doom9 forums. NicAudio, BassAudio, audio decoders.
tebasuna51 is offline   Reply With Quote
Old 20th June 2019, 16:03   #3  |  Link
mkver
Registered User
 
Join Date: May 2016
Posts: 182
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.
mkver is offline   Reply With Quote
Old 20th June 2019, 19:27   #4  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
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.
Keiyakusha is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 23:15.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.