[haiku-bugs] Re: [Haiku] #6678: .rmvb clip plays too slow in MediaPlayer
- From: "stippi" <trac@xxxxxxxxxxxx>
- Date: Thu, 30 Sep 2010 08:27:51 -0000
#6678: .rmvb clip plays too slow in MediaPlayer
---------------------------------------+------------------------------------
Reporter: luroh | Owner: stippi
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: Applications/MediaPlayer | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Has a Patch: 0
Platform: All | Blocking:
---------------------------------------+------------------------------------
Comment (by 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.
--
Ticket URL: <http://dev.haiku-os.org/ticket/6678#comment:2>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
