Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: vdr at dbox2



Andreas Oberritter wrote:
On Fri, 2004-02-27 at 23:30, Carsten Koch wrote:
...
Note that VDR does know the file offsets of all I-frames
(that information is stored in the index.vdr file), so it
would only have to read I-frame data over the network for FF/FR.
How big is a typical I-frame?
At 10 Mbit/s and 25 I-frames per second the theoretical
maximum size would be < 50 kilobytes.
If I-frames can get larger than that, one might play back
every (Nth) I-frame twice.
Does any of that sound realistic to you?

Isn't that still picture display what you're describing? You can do that
for sure, but that's not fast forward etc. at driver level. You would
need to implement the still picture ioctl()s though.
I agree it's not fast forward etc. at driver level.
Would it really require still picture ioctls?
If I simply feed I-frames as fast as I can and if there is an
I-frame every 12 frames, would that not give 12xFF without further ado?
If the network is not fast enough, it might become less than 12xFF,
but it would still be FF.
One could do every other I-frame and get up to 24xFF, etc.
depending on the network speed, right?


Btw. it is more like 5MBit/s. It's half duplex and occupies the CPU
quite a lot unlike PCI cards capable of bus mastering.
You are right.
I just checked by doing a simple measurement:

# ls -l 001.vdr
-rw-r--r--    1 20115    100     576180191 Feb 23 22:42 001.vdr
# date;cat 001.vdr>/dev/null;date
Sat Feb 28 00:51:03 CET 2004
Sat Feb 28 01:02:44 CET 2004

That's 6.69 MBit/s under ideal circumstances.
CPU load was ~55%.
So I agree that ~ 5MBit is realistic.

Carsten.


--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.



Home | Main Index | Thread Index