Incorrect Framerate?

[Luke Lutman]

I'm using flvmeta (which is fantastic!), but I'm having some issues
with the framerate property in the metadata being incorrect.

Here's what happening:

I have one source file, source.mov which is 24fps. Using Adobe Media
Encoder, I've encoded it as source_ame.flv. Using Quicktime Pro 7,
I've encoded it as source_qt7.flv. Both flvs have a keyframe distances
of 8 frames, but Quicktime Pro 7 always makes the last frame a
keyframe.

If I dump both the metadata for both files before updating, the
framerate for both is 24 fps, which is correct:

flvmeta -D -r source_ame.flv
{
'duration' => 2.958
'width' => 640
'height' => 360
'videodatarate' => 150
'framerate' => 24
'videocodecid' => 5
'canSeekToEnd' => true
}

flvmeta -D -r source_qt7.flv
{
'duration' => 2.965
'width' => 640
'height' => 360
'videodatarate' => 150
'framerate' => 24
'videocodecid' => 5
'canSeekToEnd' => true
}


If I dump the metadata for both files after updating them with
flvmeta, the framerates don't match and are both incorrect:

flvmeta --update --all-keyframes --no-lastsecond --preserve --print-
metadata --raw source_ame.flv source_ame_updated.flv
{
'hasMetadata' => true
'hasVideo' => true
'hasAudio' => false
'duration' => 2.959
'lasttimestamp' => 2.917
'lastkeyframetimestamp' => 2.667
'width' => 640
'height' => 360
'videodatarate' => 562.088120987
'framerate' => 23.9945927678
'filesize' => 219027
'videosize' => 213744
'datasize' => 4971
'metadatacreator' => 'flvmeta 1.1-r235'
'metadatadate' => Thu, 22 Sep 2011 12:30:03 -0400
'videocodecid' => 5
'canSeekToEnd' => false
'hasCuePoints' => false
'cuePoints' => [
]
'hasKeyframes' => true
'keyframes' => {
'times': [
0
0.333
0.667
1
1.333
1.667
2
2.333
2.667
]
'filepositions': [
4999
31326
56517
81291
105606
128822
151287
174284
197053
]
}
}

flvmeta --update --all-keyframes --no-lastsecond --preserve --print-
metadata --raw source_qt7.flv source_qt7_updated.flv
{
'hasMetadata' => true
'hasVideo' => true
'hasAudio' => false
'duration' => 3.031
'lasttimestamp' => 2.965
'lastkeyframetimestamp' => 2.965
'width' => 640
'height' => 360
'videodatarate' => 637.220080007
'framerate' => 23.7545364566
'filesize' => 249046
'videosize' => 248085
'datasize' => 660
'metadatacreator' => 'flvmeta 1.1-r235'
'metadatadate' => Thu, 22 Sep 2011 12:31:03 -0400
'videocodecid' => 5
'canSeekToEnd' => true
'hasCuePoints' => false
'cuePoints' => [
]
'hasKeyframes' => true
'keyframes' => {
'times': [
0
0.363
0.693
1.023
1.353
1.683
2.013
2.343
2.673
2.965
]
'filepositions': [
673
27046
50774
75503
100293
125014
149612
174988
201388
227727
]
}
}

In the metadata for source_qt7_updated.flv, you can see the extra
keyframe added by Quicktime and the framerate being quite far off
(23.754)

Looking at the source code (flvmeta.c, line 563), the framerate is
being calculated by dividing the number of frames by the duration. I
think the problem here is that this assumes that the frames are always
the same distance apart.

[Marc]

Hello !

Well, 23.99 FPS for 24 is not really far off, but the other one is a little bit more problematic.

this assumes that the frames are always the same distance apart

The framerate is basically this, the number of frames per second. I'm computing a global framerate using the file duration, and the number of frames, assuming a fixed framerate. My reasonment is that if the framerate is variable in the file, the metadata will contain an average value anyways.

Things can go awry for a specific reason. I need to know the duration of the last tag in order to compute the total file duration, since every tag has a specific timestamp indicating its starting time, but no data indicating how long the tag is supposed to "last".

There are two possibilities.

Either the last tag is audio, and audio tags last a certain time, since by nature, audio data is not instantaneous, either it's video, and then it should be zero, since a frame is a still picture, or the inverse of the framerate if we consider the frame will get displayed a non-zero amount of time before the video stops...

Currently, I admit that the last frame duration detection code is buggy, since it assumes the last frame is audio, unless the file has no audio altogether, adding the duration of the first audio tag, or the duration of the first video tag in the latter case...

Here is buraks flvmdi's take on the subject: http://www.buraks.com/captionate/helpfile/c07.html. Basically the same algorithm as mine for framerate, but only taking into account the duration of the last audio tag, probably assuming perfect synchronization.

I have a bunch of video files to experiment on, so I'll try to see what method yields the most precise result !

Thanks for the report,

Regards,

Marc