PVR (Personal Video Recorder) for QNX

Anyone interested in a PVR for QNX6 solution? I’m investigating chips
and boards…

This will most likely be a “free for non-commercial” venture, with
commercial applications (security camera, for example) being a licensed
product…

Cheers,
-RK


Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Hello Robert,

our company has developed a MPEG-2 video system, called “VidCtrl”.
It contains components for real-time encoding, streaming and decoding,

  • and of course recording features.

Please, have a look at our industrial solution
http://www.bitctrl.com/produkte/vidctrl/ueberblick.htm

At this time we are preparing a low cost solution for private use. The name
of this product is “VidCtrl Light Kit”. It contains several components of
VidCtrl: a PCI encoder card (half size), streaming software and the BitCtrl
Player (MPEG-2 decoder). The software is running under QNX 6.2.

We will place the product sheet on the WEB site next week. The price for
the Kit is 595,- ? plus delivery costs (and VAT in Germany).

Perhaps, our stuff helps you to design the PVR.

Regards
Dr. G. Geigemüller

BitCtrl Systems GmbH
http://www.bitctrl.com
info@bitctrl.de



“Robert Krten” <nospam84@parse.com> schrieb im Newsbeitrag
news:b3j6b6$1ug$1@inn.qnx.com

Anyone interested in a PVR for QNX6 solution? I’m investigating chips
and boards…

This will most likely be a “free for non-commercial” venture, with
commercial applications (security camera, for example) being a licensed
product…

Cheers,
-RK


Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.

Hello Robert, others,

“Robert Krten” <nospam84@parse.com> wrote in message
news:b3j6b6$1ug$1@inn.qnx.com

Anyone interested in a PVR for QNX6 solution? I’m investigating chips
and boards…

This will most likely be a “free for non-commercial” venture, with
commercial applications (security camera, for example) being a licensed
product…

Regarding your investigation for chips & boards: Are you seeking to

defer encoding to hardware or to the CPU?

In the first case, the VIA Mini-ITX Eden platform is extremely
cost-effective,
more specifically the EPIA M-6000 platform which can be passively cooled
(a must for PVR). Add a low-noise harddisk and a hardware coding card.

I’m interested in working along.

Leon.

Leon Woestenberg <leon.woestenberg@gmx.net> wrote:

Hello Robert, others,

“Robert Krten” <> nospam84@parse.com> > wrote in message
news:b3j6b6$1ug$> 1@inn.qnx.com> …
Anyone interested in a PVR for QNX6 solution? I’m investigating chips
and boards…

This will most likely be a “free for non-commercial” venture, with
commercial applications (security camera, for example) being a licensed
product…

Regarding your investigation for chips & boards: Are you seeking to
defer encoding to hardware or to the CPU?

In the first case, the VIA Mini-ITX Eden platform is extremely
cost-effective,
more specifically the EPIA M-6000 platform which can be passively cooled
(a must for PVR). Add a low-noise harddisk and a hardware coding card.

I’m interested in working along.

I’m looking to do the encoding in hardware if possible.
Can you point me to some URLs for the chip mentioned above? I’ve been
searching high and low for chips that a) are available b) have documentation
(NDA is ok), and c) ones that have a PCI solution already implemented.
I’m really trying to avoid making my own hardware :slight_smile:

Cheers,
-RK

\

Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

I read that Hauppauge (However you spell it.) has a PCI card that does
full MPEG conversion. MS put a spec for a “Media Center PC” and one of the
requirements was the TV card had to do it all in hardware, the article I saw
(I think it was in Maximum PC or CPU magazine.) specifically called out
Hauppauge as a vendor of compliant cards. I’m not sure there are any other
common vendors that were fully hardware compliant. ATI’s 9XXX All in
wonders don’t do it, but they are REALLY NICE cards and include RF remote
which is REALLY nice for a PVR. Photon could really use better support for
modern graphics cards, it would be nice to offload more rendering to the
hardware so it doesn’t take valueable processor time.

“Robert Krten” <nospam84@parse.com> wrote in message
news:b4h30k$m17$1@inn.qnx.com

Leon Woestenberg <> leon.woestenberg@gmx.net> > wrote:
Hello Robert, others,

“Robert Krten” <> nospam84@parse.com> > wrote in message
news:b3j6b6$1ug$> 1@inn.qnx.com> …
Anyone interested in a PVR for QNX6 solution? I’m investigating chips
and boards…

This will most likely be a “free for non-commercial” venture, with
commercial applications (security camera, for example) being a licensed
product…

Regarding your investigation for chips & boards: Are you seeking to
defer encoding to hardware or to the CPU?

In the first case, the VIA Mini-ITX Eden platform is extremely
cost-effective,
more specifically the EPIA M-6000 platform which can be passively cooled
(a must for PVR). Add a low-noise harddisk and a hardware coding card.

I’m interested in working along.

I’m looking to do the encoding in hardware if possible.
Can you point me to some URLs for the chip mentioned above? I’ve been
searching high and low for chips that a) are available b) have
documentation
(NDA is ok), and c) ones that have a PCI solution already implemented.
I’m really trying to avoid making my own hardware > :slight_smile:

Cheers,
-RK

\

Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.

Bob Smith <bobsmith@home.com> wrote:

I read that Hauppauge (However you spell it.) has a PCI card that does

I am explicitly avoiding Happauge because I called their contact guy twice,
and left three emails, and heard absolutely nothing, so I can only presume
that they are not interested in selling their products.

full MPEG conversion. MS put a spec for a “Media Center PC” and one of the
requirements was the TV card had to do it all in hardware, the article I saw
(I think it was in Maximum PC or CPU magazine.) specifically called out
Hauppauge as a vendor of compliant cards. I’m not sure there are any other
common vendors that were fully hardware compliant. ATI’s 9XXX All in
wonders don’t do it, but they are REALLY NICE cards and include RF remote
which is REALLY nice for a PVR. Photon could really use better support for
modern graphics cards, it would be nice to offload more rendering to the

For PVR I will go with a freeBSD solution due to file size limitation on
QNX…

Cheers,
-RK

hardware so it doesn’t take valueable processor time.

“Robert Krten” <> nospam84@parse.com> > wrote in message
news:b4h30k$m17$> 1@inn.qnx.com> …
Leon Woestenberg <> leon.woestenberg@gmx.net> > wrote:
Hello Robert, others,

“Robert Krten” <> nospam84@parse.com> > wrote in message
news:b3j6b6$1ug$> 1@inn.qnx.com> …
Anyone interested in a PVR for QNX6 solution? I’m investigating chips
and boards…

This will most likely be a “free for non-commercial” venture, with
commercial applications (security camera, for example) being a licensed
product…

Regarding your investigation for chips & boards: Are you seeking to
defer encoding to hardware or to the CPU?

In the first case, the VIA Mini-ITX Eden platform is extremely
cost-effective,
more specifically the EPIA M-6000 platform which can be passively cooled
(a must for PVR). Add a low-noise harddisk and a hardware coding card.

I’m interested in working along.

I’m looking to do the encoding in hardware if possible.
Can you point me to some URLs for the chip mentioned above? I’ve been
searching high and low for chips that a) are available b) have
documentation
(NDA is ok), and c) ones that have a PCI solution already implemented.
I’m really trying to avoid making my own hardware > :slight_smile:

Cheers,
-RK

\

Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.


[If replying via email, you’ll need to click on the URL that’s emailed to you
afterwards to forward the email to me – spam filters and all that]
Robert Krten, PDP minicomputer collector http://www.parse.com/~pdp8/

For PVR I will go with a freeBSD solution due to file size limitation on
QNX…

Regardless of OS, I would actually think you would want to have a very
specialized block device interface for this type of application. Basically
doing your own filesystem.

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Chris McKillop <cdm@qnx.com> wrote:

For PVR I will go with a freeBSD solution due to file size limitation on
QNX…


Regardless of OS, I would actually think you would want to have a very
specialized block device interface for this type of application. Basically
doing your own filesystem.

Why? It’s only 600kbytes/second… With lots of buffering, and sufficient
file system performance, that should be fine. Even the “top” speed of
1.2MB/s should be fine too. I like the idea of a “regular” filesystem
so that I don’t have to go through hoops to copy, rename, move, archive,
etc. files…

Cheers,
-RK


[If replying via email, you’ll need to click on the URL that’s emailed to you
afterwards to forward the email to me – spam filters and all that]
Robert Krten, PDP minicomputer collector http://www.parse.com/~pdp8/

“Chris McKillop” <cdm@qnx.com> wrote in message
news:bjaj9p$pao$4@nntp.qnx.com

For PVR I will go with a freeBSD solution due to file size limitation on
QNX…


Regardless of OS, I would actually think you would want to have a very
specialized block device interface for this type of application.
Basically
doing your own filesystem.

Why? I’m doing PVR with my windows box and it works great.

chris


Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Mario Charest postmaster@127.0.0.1 wrote:

“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:bjaj9p$pao$> 4@nntp.qnx.com> …

For PVR I will go with a freeBSD solution due to file size limitation on
QNX…


Regardless of OS, I would actually think you would want to have a very
specialized block device interface for this type of application.
Basically
doing your own filesystem.


Why? I’m doing PVR with my windows box and it works great.

Multiple playback and record streams at the same time? Just curious.

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

“Chris McKillop” <cdm@qnx.com> wrote in message
news:bjelgc$i6m$1@nntp.qnx.com

Mario Charest postmaster@127.0.0.1 wrote:

“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:bjaj9p$pao$> 4@nntp.qnx.com> …

For PVR I will go with a freeBSD solution due to file size limitation
on
QNX…


Regardless of OS, I would actually think you would want to have a very
specialized block device interface for this type of application.
Basically
doing your own filesystem.


Why? I’m doing PVR with my windows box and it works great.


Multiple playback and record streams at the same time? Just curious.

Playback and record at a same time yes, but one of each only. Compression
is talking the bulk of the CPU load.

I just tried 2 playback of mpeg2 file (DVD format) and CPU load is 40% while
HD file transfer are around 3Mbytes/sec. I’m sure CPU is the bottle neck
not HD. HD can easely do 10M on multiple read/write.

But I see your point a custom FS would surely help performance, as most
custom stuff can do. But unless it’s a very high end PVR or you want to run
in on very low cost hardware I just don’t see the point.

chris


Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Playback and record at a same time yes, but one of each only. Compression
is talking the bulk of the CPU load.

I just tried 2 playback of mpeg2 file (DVD format) and CPU load is 40% while
HD file transfer are around 3Mbytes/sec. I’m sure CPU is the bottle neck
not HD. HD can easely do 10M on multiple read/write.

Oh sure - doing read-only playback will not stress the system. The issues
isn’t so much if the HD can do the seeking and reading/writing but how the
fs will do things behind your back (ie: cache flushes and such).

But I see your point a custom FS would surely help performance, as most
custom stuff can do. But unless it’s a very high end PVR or you want to run
in on very low cost hardware I just don’t see the point.

Also be able to potentially lower the CPU requirements. Plus, doing your own
storage allocation scheme would be half the fun!! :slight_smile:

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

“Chris McKillop” <cdm@qnx.com> wrote in message
news:bjgp2a$277$1@nntp.qnx.com

Playback and record at a same time yes, but one of each only.
Compression
is talking the bulk of the CPU load.

I just tried 2 playback of mpeg2 file (DVD format) and CPU load is 40%
while
HD file transfer are around 3Mbytes/sec. I’m sure CPU is the bottle
neck
not HD. HD can easely do 10M on multiple read/write.


Oh sure - doing read-only playback will not stress the system. The issues
isn’t so much if the HD can do the seeking and reading/writing but how the
fs will do things behind your back (ie: cache flushes and such).


But I see your point a custom FS would surely help performance, as most
custom stuff can do. But unless it’s a very high end PVR or you want to
run
in on very low cost hardware I just don’t see the point.


Also be able to potentially lower the CPU requirements. Plus, doing your
own
storage allocation scheme would be half the fun!! > :slight_smile:

:wink: That makes me wonder, if a program open /dev/hd0.0t78 for example and
perform read/write on it, does that goes through the cache ? I would think
not but just checking.

The original point was that QNX wasn’t supporting files over 2G, and I hope
the reason why is NOT because someone as QSSL thinks if you need to handle
files over 2Gig then that means you don’t need a “normal FS” but a custom
one :wink:

chris


Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

“Mario Charest” postmaster@127.0.0.1 wrote in message
news:bjgpfu$f7m$1@inn.qnx.com

The original point was that QNX wasn’t supporting files over 2G, and I
hope
the reason why is NOT because someone as QSSL thinks if you need to handle
files over 2Gig then that means you don’t need a “normal FS” but a custom
one > :wink:

Come on Mario, you should not be inventing excuses for them. They are good
at that…
The reason is the same as why ethernet was not supported for years when
everyone around had it. And then was CD recording, and FireWire still is …
Sure, we all need custom drivers for those things…

“Igor Kovalenko” <kovalenko@attbi.com> wrote in message
news:bjgqrf$fsj$1@inn.qnx.com

“Mario Charest” postmaster@127.0.0.1 wrote in message
news:bjgpfu$f7m$> 1@inn.qnx.com> …

The original point was that QNX wasn’t supporting files over 2G, and I
hope
the reason why is NOT because someone as QSSL thinks if you need to
handle
files over 2Gig then that means you don’t need a “normal FS” but a
custom
one > :wink:


Come on Mario, you should not be inventing excuses for them.

I don’t think I was. I hoping/guessing this perticular issue is related to
some business decision, and I want to stay away from that discussion.

at that…

The reason is the same as why ethernet was not supported for years when
everyone around had it. And then was CD recording, and FireWire still is

Well that’s exactly it, I do not really know what is that reason :wink: Nor
do I want to know it as it’s none of my business.

Sure, we all need custom drivers for those things…

Chris McKillop <cdm@qnx.com> wrote:

The original point was that QNX wasn’t supporting files over 2G, and I hope
the reason why is NOT because someone as QSSL thinks if you need to handle
files over 2Gig then that means you don’t need a “normal FS” but a custom
one > :wink:

CM > Nah. AFAIK, libc supports it (64bit file offsets and the like). It just
CM > requires a new fs.

Would it take much effort to just take the existing QNX4 file system
and make the offsets 64 bits?

I’m guessing not. And it would make a lot of people happy.

:wink: > That makes me wonder, if a program open /dev/hd0.0t78 for example and
perform read/write on it, does that goes through the cache ? I would think
not but just checking.

I will let John make any comments on this subject. I really don’t know.
There might be a low-level block cache for reads.

The original point was that QNX wasn’t supporting files over 2G, and I hope
the reason why is NOT because someone as QSSL thinks if you need to handle
files over 2Gig then that means you don’t need a “normal FS” but a custom
one > :wink:

Nah. AFAIK, libc supports it (64bit file offsets and the like). It just
requires a new fs.

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Bill Caroselli <qtps@earthlink.net> wrote:

Chris McKillop <> cdm@qnx.com> > wrote:


The original point was that QNX wasn’t supporting files over 2G, and I hope
the reason why is NOT because someone as QSSL thinks if you need to handle
files over 2Gig then that means you don’t need a “normal FS” but a custom
one > :wink:


CM > Nah. AFAIK, libc supports it (64bit file offsets and the like). It just
CM > requires a new fs.

Would it take much effort to just take the existing QNX4 file system
and make the offsets 64 bits?

I’m guessing not. And it would make a lot of people happy.

Again, I don’t really know the internals and will let others comment on any
technical aspects (rather then business ones ).

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

qtps@earthlink.net sed in <bji702$h8b$1@inn.qnx.com>:

Would it take much effort to just take the existing QNX4 file system
and make the offsets 64 bits?

AFAIK qnx4 fs has only 32bits in the inode for file length,
so yes extending it will be helluva effort, and
result won’t be a qnx4 fs (qnx6 fs?)

If you have the source for fs-qnx4.so maybe it’s a cheesecake
to just redefine&recompile…

kabe

kabe@sra-tohoku.co.jp wrote:
kstcj > qtps@earthlink.net sed in <bji702$h8b$1@inn.qnx.com>:

Would it take much effort to just take the existing QNX4 file system
and make the offsets 64 bits?

kstcj > AFAIK qnx4 fs has only 32bits in the inode for file length,
kstcj > so yes extending it will be helluva effort, and
kstcj > result won’t be a qnx4 fs (qnx6 fs?)

kstcj > If you have the source for fs-qnx4.so maybe it’s a cheesecake
kstcj > to just redefine&recompile…
kstcj > –
kstcj > kabe

Agreed. It would no longer be a QNX4 fs.

Also agreed, Just re-define and recompile.