FFmbc 0.6-rc7 -ss -t don't output complete frames of audio

[GoogleCodeExporter]

What steps will reproduce the problem?

Encode some DV in a MOV

Split that MOV at places that should be seamless edits

ffmbc -i primary.mov -ss 2 -t 3 -acodec copy -vcodec copy 1.mov
ffmbc -i primary.mov -ss 5 -t 3 -acodec copy -vcodec copy 2.mov

Here I'm working in PAL 25 FPS 48K audio.

I would expect exactly 75 frames of video and 144000 samples of audio. I am NOT 
getting the correct number of samples of audio.

Using, for instance, "Atom Inspector" on Mac OS X I can see that in 1.mov there 
are 144384 audio samples (too many) and in 2.mov I can see that there are 
143360 audio samples (too few).


'primary.mov' file is here: 
http://commondatastorage.googleapis.com/himslm01/FFmbc/primary-2011-06_10_1617-3
7.mov
'1.mov' file is here: 
http://commondatastorage.googleapis.com/himslm01/FFmbc/1.mov
2.mov file is here: http://commondatastorage.googleapis.com/himslm01/FFmbc/2.mov

A screen capture of the differences shown in "Atom Inspector" is here: 
http://commondatastorage.googleapis.com/himslm01/FFmbc/Screen%20shot%202011-06-1
3%20at%2017.21.33.png


What version of the product are you using? On what operating system?

FFmbc 0.6-rc7 on Ubuntu GNU/Linux 10.04 64 bit

Original issue reported on code.google.com by mark.him...@gmail.com on 13 Jun 2011 at 4:23

[GoogleCodeExporter]

Attaching screen capture of the differences shown in "Atom Inspector"

Original comment by mark.him...@gmail.com on 13 Jun 2011 at 4:24

Attachments:

• [Screen shot 2011-06-13 at 17.21.33.png](https://storage.googleapis.com/google-code-attachments/ffmbc/issue-48/comment-1/Screen shot 2011-06-13 at 17.21.33.png)

[GoogleCodeExporter]

Hi Mark,

I think this has always been that way -t is not sample accurate.

Original comment by baptiste...@gmail.com on 15 Jun 2011 at 3:06

• Added labels: Type-Wish
• Removed labels: Type-Defect

[GoogleCodeExporter]

I've tried using '-ss 2 -vframes 75' instead, but that doesn't give complete 
audio frames either.

Do you know if there is any method to get complete frames of audio?

Original comment by mark.him...@gmail.com on 16 Jun 2011 at 10:28

[GoogleCodeExporter]

Humm I'm not sure what you mean by "complete frames of audio". In PCM a 
complete frame is 1 sample. If now you think duration of pcm audio frame ~= 
duration of video frame.
There is no method currently, but it is an interesting idea.

Original comment by baptiste...@gmail.com on 16 Jun 2011 at 9:54

[GoogleCodeExporter]

Haha. Yes, that is an interesting different point of view.

Coming from a background of 20 years of Video Editing, I expect a frame of 
audio to be 1920 samples long (48K sampling/25 FPS).

As a video editor, if I am using a tool that lets me extract a subclip (using 
-ss and -t or -vframes) I expect to extract complete frames of video, and the 
corresponding samples of audio that completely and exactly match the complete 
duration of the video frames.

I can see how that is not possible with, for instance, mpeg2 audio frames who's 
timestamp start and end points do not necessarily exactly map to the start and 
end point timestamps of the video frames.

But, as a video editor, I've always worked with uncompressed video.

That thought lead me to an interesting experiment, excuse me while a ramble on 
for a while:

compare:

ffmbc -i primary.mov -ss 2 -vframes 75 -vcodec copy -acodec copy 1.mov

with:

ffmbc -i primary.mov -ss 2 -vframes 75 -vcodec copy -acodec pcm_s16le 1.mov

I find that consistently (for the same input file) that -acodec copy always 
gives me audio in lumps of 1024 samples until a small part of the last video 
frame has audio, then it stops (except for -vframes 1, where you get no audio 
at all).

My example of  -vframes 75 gives me 142336 samples (according to Atom 
Inspector).

75 frames of audio is 144000 samples (48000/25*75).
74 frames of audio is 142080
but I get 142336 samples, which is 139 * 1024
As it happens, 138 * 1024 = 141312, which is less than 142080

So 142336 samples is the first multiple of 1024 that completely satisfies 
142080 samples, but is 1664 samples too few to completely fill 75 frames of 
'PAL' video.


I find that consistently (for the same input file) that -acodec pcm_s16le 
always gives me audio in similar lumps of 1024 samples offset by 639 samples 
(except for -vframes 1, where you get no audio at all).

My example of  -vframes 75 gives me 142975 samples (according to Atom 
Inspector).

75 frames of audio is 144000 samples (48000/25*75).
74 frames of audio is 142080
but I get 142975 samples, which is 139 * 1024 + 639
As it happens, 138 * 1024 + 639 = 141951, which is less than 142080

So 142975 samples is the first multiple of 1024 + 639  that completely 
satisfies 142080 sample, but is 1025 samples too few to completely fill 75 
frames of 'PAL' video.

Wow - I wasn't expecting to see either 1024 or 639 in those calculations, but 
at least 1024 makes some sense!

Now, I know 'NTSC' audio is more complex with your crazy 1001, but it is a 
predictable sequence.

Anyway - rant over ;-)

Original comment by mark.him...@gmail.com on 17 Jun 2011 at 3:08

[GoogleCodeExporter]

Mark, I understand your rant, but let me correct you on one point:

"As a video editor, if I am using a tool that lets me extract a subclip (using 
-ss and -t or -vframes) I expect to extract complete frames of video, and the 
corresponding samples of audio that completely and exactly match the complete 
duration of the video frames."

FFmbc is _not_ a video editing tool. I have to redirect you to FCP or Media 
Composer for this, -ss and -t are convience tools but in no case guarantee what 
you seem to require.

Original comment by baptiste...@gmail.com on 17 Jun 2011 at 9:25

[GoogleCodeExporter]

Original comment by baptiste...@gmail.com on 26 Jul 2011 at 10:54

• Changed state: WontFix