Re: Info on H.264
- From: Paul <nospam@xxxxxxxxxx>
- Date: Thu, 24 Jan 2008 09:39:17 -0500
On Jan 23, 8:28 pm, Paul <nos...@xxxxxxxxxx> wrote:bharath_r wrote:Hi,I would question why you'd do your "development" this way in the
I am looking for this answer for a past few days. I am trying to
develop a CCTV surveillance application. I would like to know whether
H.264 is a compression technique or a video encoding technique or is
it both? I have a DVR card that supports H.264 video compression. The
problem is that it saves the recorded videos in some proprietary
format(.vgz). Although the card came with a player i want to watch the
videos on windows media player. I wanted to know if i can read each
frame from the card and then encode and save it in a format that can
be understood by the windows media player like wmv or asf. Any help
will be highly appretiated.
first place, but it's your project.
The purpose of capturing in the VGZ, could be for two purposes.
One would be to escape from some kind of licensing fees. The
second might be, on the assumption they were offering the absolute
best compression while capturing.
If you are starting a "CCTV surveillance application", you start
by making a list of requirements. What do you want to do with the
information ? Store it on disk ? View it in real time ? What percentage
of the time are you doing those activities ? How much processing
power do you have ? Can the GPU on the video card in the computer,
be used to accelerate playback ? Could the hardware solution purchased,
offer simultaneous playback as part of its function (i.e. dump to
frame buffer via DMA). Could GraphEdit and the appropriate CODECs
be used to build a playback solution ?
It might make more sense, to use a $20 capture chip, with uncompressed
capture. By using a standard driver for the capture card, many programs
could be used to view the results, or share the data. The job of the
software, when storing to disk, would then be to select the area of
interest, and write it out to disk in an economical (compressed) format.
The format could be lossless (for best usage later), or lossy (for least
storage usage). As a software developer, your "value added" would be
finding new ways to only capture what a client wishes. The hardware
used in this case, would emphasize "capture" versus "DVR".
Selecting a capture device, that does extreme compression, but uses a
non-standard format, only makes sense if the content is only to be
handled within the tools provided by the manufacturer. You haven't
made clear in your post, exactly how this choice of capture device,
is making your project easier. Presumably the usage of a custom
DSP approach with low product volumes, leads to a high price for the
CCTV capture card.
Paul- Hide quoted text -
- Show quoted text -
Thank you all for your valuable guidance.
Regarding Pauls question 'Why do I want to develop my application like
this?'. We plan to develop a survelliance application where files are
getting recorded at a particular location and can be viewed from
multiple location without the files being physically copied to that
location. One way of doing that is by streaming the files using
Windows Streaming Server. But there are limitations on the format of
the files that can be streamed. The formats that streaming server
supports are nsc, mp3, jpg, asf, wma, wmv. So i want to convert the
file to the format supported by the Streaming Server.
I am new to this field and am still learning all the intricacies
associated. Please let me know if there is a better method of
To give an example of a box to start with, this blade video server
accepts analog cameras, and produces MJPEG and MPEG-4. On the viewing
end, their user manual says a license must be purchased for each MPEG-4
viewer (MPEG-4 is licensed and there is a license pool, which is why
they have to charge for it). But if you use MJPEG, then maybe there is
no problems with that.
Then, connect that video server to a network server. The job of the network
server, would be to archive the MJPEG, do format conversion and so on. The
network server could have multiple network interfaces, engineered as needed
for the amount of bandwidth expected from each analog to IP video server.
This web page offers information on developer tools to use with things
like the 243Q.
That company also offers the computing device on the blade card, as
a separate solution. Since it is a processor, you might also be able to
output in a different format, right at the per-camera level. The active
chip on the 243Q is the ETRAX 100LX, which is apparently only 100 MIPS
of computing power. Thus, eliminating the network server from your
architecture, would mean firmware development for the ETRAX chip
itself. (Do a wmv firmware, instead of the existing MJPEG/MPEG-4 firmware.)
But as I said previously, if I wanted to get started, and just
develop some software, I'd get a card that captures uncompressed,
has a WDM capture driver, and write my application on top of that.
That way at least, your first software job won't be to uncompress
the incoming video stream. You can concentrate on serving the
various formats you plan on developing. The WinTV Go card in my
current computer, with a BT848/BT878 type chip, would be a cheap
source of video.
The above Axis box is intended to allow a denser solution, with more
input channels. It is currently difficult (requires hardware
development), to make the best use of the tremendous bandwidth
available in a PCI Express based computer, and integrate the
whole thing into one PC. That is because I haven't seen any
dense PCI Express video capture cards - yet. I'm sure someone
in Taiwan is working on that, as all that is needed is a
PCI Express bridge chip. And those already exist.
For example, this USB card, has a PCI Express bridge chip on it,
to adapt an older PCI chip, to the new PCI bus. Bridging some
of the older video card capture designs, would then allow more
cards to be installed in a PCI Express motherboard. (The bridge
is the chip near the gold finger connector.)
- Prev by Date: Re: DV Tape Playback Problem
- Next by Date: Re: Info on H.264
- Previous by thread: Re: Info on H.264
- Next by thread: Re: Info on H.264