From: fsulima <fsulima@gmail.com>
To: Jackson Yee <jackson@gotpossum.com>
Cc: video4linux-list@redhat.com
Subject: Re: Please advise: 4channel capture device with HW compression for Linux based DVR
Date: Mon, 06 Jul 2009 04:10:24 +0400 [thread overview]
Message-ID: <4A5140F0.40909@gmail.com> (raw)
In-Reply-To: <26aa882f0907051606x9b9f63bi6a7a9d5ea7db6126@mail.gmail.com>
Thanks a huge, it is exhausting!
Please see inline.
Jackson Yee wrote:
> Yep, been down that road before myself.
>
> The truth of the matter is that slim profile, multiple port cards are
> available with Linux drivers, but they are quite expensive ($500 for
> the cheapest that I could find, although it is a very nice looking 16
> port system).
>
Oh, this is too pricy.
Are you talking only about cards with H/W encoding or about all low
profile multiple port capture cards?
> I have a mini-ITX system sitting by my television right now which I
> would love to use my new STK-1160 4-port USB adapter (marketed as
> EasyCap 4-port DVR USB) with, but unfortunately, we're still working
> out NTSC support for it. The guys using PAL and Zoneminder have
> apparently gotten it to work pretty well.
>
It appears like STK-1160 has 25/30 overall fps, so it's not quite the
same thing.
> I've never used an Atom system, but from what I understand, although
> the CPU is quite power efficient, it is also utterly crushed in
> performance by the cheapest dual-cores available today. That's why
> Nvidia's Ion platform was so attractive to people looking to do 720p
> or 1080p on their televisions - the Atom simply did not have the power
> to handle HD video. A D1 stream is much easier to work with, but
> encoding is also more processor intensive than decoding by an order of
> magnitude. You could probably do one D1 stream with MPEG4, but if you
> plan on using real-time x264 or more than one stream... I would have
> to believe that your system would be quite incapable of keeping up the
> framerate.
>
It was tricky to make ATOM decode HD, I had to employ multicore CoreAVC
decoder. Decoding of 720p was consuming about 30% of CPU time (assuming
it has 2 HT cores, each of 4 HW threads was busy 30% of time), and 1020p
was about 50-70% AFAIR. It can be outperformed by regular P4.
So my system must be definitely unsuitable for real time encoding :(
> Believe me, I would love to say that I have a solution for you since
> that would mean a solution for me as well, but the reality of the
> matter is that we are just not quite there yet on driver support for a
> multiple channel USB capture device. If you're just planning on doing
> one D1 stream at a time, the WinTV PVR USB2 has hardware encoding and
> is supported quite well. I suppose that you could hook up a couple of
> these, but whether the system could handle these USB devices is beyond
> my experience.
>
Yes, there are single channel devices with encoding, combining 4 of them
together may be less pricy, but it's odd anyway. :)
> Please let me know if you have any success with this project.
>
It looks it's not worth wasting time trying this on Atom.
I may need to consider an upgrade.
I'm considering Intel mini-itx motherboard.
http://www.mini-box.com/Intel-DG41MJ-FSB1333-Socket-775-Mini-ITX-Motherboard
The price of the upgrade looks comparable with price of HW encoding
solution, but it is more beneficial.
So, could you please say more about LP vs regular PCI capturers (W/O H/W
encoding)? Are there inexpensive LP solutions?
Regards,
F S
> Regards,
> Jackson Yee
> The Possum Company
> 540-818-4079
> me@gotpossum.com
>
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
next prev parent reply other threads:[~2009-07-06 0:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-05 11:09 Please advise: 4channel capture device with HW compression for Linux based DVR fsulima
2009-07-05 20:30 ` Jackson Yee
2009-07-05 21:41 ` fsulima
2009-07-05 23:06 ` Jackson Yee
2009-07-06 0:10 ` fsulima [this message]
2009-07-06 2:45 ` Jackson Yee
2009-07-06 20:32 ` fsulima
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A5140F0.40909@gmail.com \
--to=fsulima@gmail.com \
--cc=jackson@gotpossum.com \
--cc=video4linux-list@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox