[haiku-development] Re: MediaPlayer in latest build
- From: David McPaul <dlmcpaul@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 17 Dec 2009 00:25:57 +1100
2009/12/16 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> David McPaul <dlmcpaul@xxxxxxxxx> wrote:
>> 2009/12/16 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
>> > David McPaul <dlmcpaul@xxxxxxxxx> wrote:
>> >> 2009/12/15 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
>> >> > Also, I want to reduce the power consumption during media replay,
>> >> > and
>> >> > batching I/Os as much as possible makes a measurable difference
>> >> > (especially for audio where you could park the disk for several
>> >> > minutes).
>> >> Try r34665. It has a measurable effect on Disk I/O for mp3
>> > > playback.
>> > Sure, but I would consider this a bit like a hack that is only
>> > really
>> > possible for this specific container (pretending to have a
>> > different
>> > chunk size only works if you control the codec as well).
>> Well we do control the codec :-)
>>
>> In this case it is easy because the mp3 decoder does not expect 1
>> frame per chunks so it has code to join chunks and scan them for
>> frame
>> headers. So changing the mp3 reader to just pass larger chunks is
>> easy.
>
> Yes, but it's also not really the way to go; if you consider a codec-
> agnostic media cut application (ie. one that does its job without
> reencoding the media data), cutting the file into chunks of arbitrary
> size does not really work well. And if reducing the number of disk I/O
> is your objective, this should then really be done using a buffered
> reader instead of solving it this way in the upper layers.
Well for mp4, mov, avi the chunk size is the only places you can cut
without re-encoding, they are supposed to be the lowest seekable and
addressable points in the file. For video this is usually a single
frame. For audio it is usually a sequence of frames but it does
depend on the encoding, I remember a file I had where the chunk size
for the audio was a single 2 byte frame :-(. There is nothing
stopping us from combining the file format chunks into larger chunks
when passing to the decoder.
You can still seek to any point in the file in order to perform a cut.
The reader is just passing a larger chunk of data to the decoder.
The decoder does have to understand that 1 chunk != 1 frame. It makes
the decoder a little more complicated. For mp3 it is easy to do as
there is only 1 stream so the block size can be whatever we want. For
others you have to follow the streams.
>> Real containers (avi, mp4, mov) generally have audio chunks that have
>> multiple audio frames anyway but even they can be small.
>>
>> But I think the issues we have with I/O are less chunk size related
>> and more seek related and that should be solved by the reader.
>
> What do you mean by seek? Disk seek or media seek?
I am not sure yet, I find with my media files that the disk I/O is
minimal but as I get closer to the end of the file it increases. I
think the audio position and the video position are getting further
apart and so each get next chunk call seeks a lot. Most files
interleave the audio/video data so this does not occur so the file
might not do this or maybe the reader is doing something wrong.
>> By the way, is there an easy way to hook into the Activity Monitor?
>
> If you would be more specific, I might even have an answer for this ;-)
If I wanted to add additional items. Like say I wanted to record
chunks per second or other stats.
--
Cheers
David
Other related posts:
