.rmvb clip plays too slow in MediaPlayer

[luroh]

hrev38854. The video track in this clip plays too slow in MP, drifts more and more out of sync with the audio track:

​http://deathstar.knuttinatoll.net/hammer/sample.rmvb (3 MB)

[streak]

checked aswell with normal full lenght rmvb movie.. video is too sloow and sound is totally desynced. sound plays fine with proper speed..

[stippi]

Yes, I've looked at this problem already. Basically the situation is this: MediaPlayer is (currently) based on the concept of a fixed video frame rate. The FFmpeg plugin extracts the frame rate information from the video stream as found in the libavformat structures. There are as many as four different places of information where the video frame rate can be represented, and all four of them are checked in a particular order. With most video container formats, this works fine, with MP4 and MKV it works perfectly, it works almost always with AVI.

FFmpeg itself however is not assuming a fixed video frame rate. Instead, each video frame is given a timestamp as extracted from the stream. This allows a variable video frame rate. Consider an animated GIF where each frame can have an indivual display duration. Some video container formats are like that, too. For example, I have an ASF test file which has totally variable frame rate.

The RMVB files from this ticket report a frame rate of 12.5 FPS. But the timestamps of each video frame will come faster than that. Playback software which ignores the frame rate and just displays each frame according to its timestamp will have no problem with this. I have planned to change the MediaPlayer engine to use this concept. It will also allow to fix out-of-sync video and audio timestamps, as seem to be common in MPEG and MPEG2 streams. Then it can just use the audio time stamps as virtual reference and lock the video to that. This is also how FFplay or VLC work internally, although they support using the video as reference clock as well (which I don't think makes sense, since audio can't be easily played faster/slower without at least resampling artifacts). When/if I still find the time for this, I cannot tell. Just so someone, who would look into this, knows what the actual problem is.

From a point of the MediaKit, the video frames and also audio frames have a valid timestamp as extracted from the streams by FFmpeg itself in the media_header structure, which can be passed to BMediaTrack::ReadFrames(). BMediaTrack::CurrentTime() is also maintained according to these timestamps rather than calculated time based on the number of frames played and the frame rate. The AudioProducer node in MediaPlayer could for example be it's own timesource, publishing drift according to calculated versus timestamped performance time, and the VideoProducer node in MediaPlayer could calculate performance time according to this timesource instead of using the system default timesource. That should fix drifting audio/video. Additionally, it could ignore it's own framerate, and just send buffers according to the timestamps in the track. Both is slightly tricky (although not much code to write) and needs throurough testing.

[luroh]

Thanks for the explanation, this is clearly complicated stuff way over my head. Still, for completeness, I'd just like to add that Ubuntu 10.04 reports a frame rate of 25 fps for the linked sample clip.

[stippi]

(In #6812) Please always search for existing tickets before opening new ones. In this case, a simple search for "rmvb" reveals that there is already a ticket for this problem, and it contains already lots of information.

[halilpk]

Haiku revision: hrev42211 not a bug. There is no problem during the play .rmvb files . System: Haiku hrev1-alpha3 on VMware workstation 8 on windows 7 32 bit

[luroh]

Replying to halilpk:

There is no problem during the play .rmvb files .

Still plays too slow here (hrev43371, gcc2). Have you really tried playing the example file I link to in the description?

[halilpk]

yes of course and there was no problem. But maybe the reason is system. I have Haiku hrev1-alpha3 on VMware workstation 8 on windows 7 32 bit

[luroh]

I can't reproduce this problem any more, gcc2 hrev43846. Closing as fixed.