Re: size of DV/1394 video stream
- From: phil-news-nospam@xxxxxxxx
- Date: 27 Jun 2005 15:31:59 GMT
On Mon, 27 Jun 2005 03:02:53 -0700 Richard Crowley <rcrowley7@xxxxxxxx> wrote:
| phil-news-nospam wrote ...
|> I only need to store what I get and play it back at a specific time,
|> so
|> building an avi file won't even be needed. I'm looking at just
|> storing
|> what I get from the DV-over-firewire stream as-is, then dumping it
|> back out as-is.
|
| Conventional DV codecs essentially put the raw DV bitstream directly
| into the AVI file with a few bytes of identifiaction at the head.
Is there any documentation on the AVI part of it?
|> I don't want the overhead of having to convert the whole thing to
|> some other format first,
|
| Dunno why you would need to do that, (or think you would need to
| do that)?
There's still some lack of definitive information. The first
description I read of DV said it was UNcompressed. Now more people
agree it is 5:1 with a DCT algorithm (which can be made to give a
fixed ratio with a varying loss).
|> which means not using some other software program which only
|> converts whole files. It would be enough to be able to implement
|> still, slow, fast, and reverse.
|
| Not clear that you are not just talking about playback functionality
| which has nothing to do with the file format/codec, etc.
The playback hardware would have to be given what it understands.
Presumably what is gotten from it would be just right. But there
is the need to work with that format to some degree, e.g. to slice
frames and process audio. There may be the desire to work with it
even further in the future, such as sharing the files with NLE.
Simply storing raw DV into a file may not be what an NLE expects
if the standard is to append headers like AVI before writing the
file to computer storage.
|> Being able to marm frames and store that in an auxiliary file would
|> also be nice.
|
| What is "marm"? If you mean grabbing frames and storing as image
| files, there are several ways of doing it, and info available to write
| your own app, etc.
Typo. It should be "mark".
As long as I can see where one frame ends and another frame begins
in the DV stream, I can be sure that files always begin exactly at
a frame beginning and end. If the DV stream always begins that way
when transfer starts, that should be enough.
By marking, I would have a 2nd file that would be like a timeline
and have text listing filenames and relative frame numbers for the
playback. It could be similar to a simplistic NLE in that respect.
|> But do keep in mind this is development of software that needs to
|> know the format, not obtaining some other software that does the
|> job in a different context than what this project is.
|
| You wanna try that again? That is why AVI (and MOV, RIFF, etc.)
| file formats include codes at the beginning of the file which identifies
| which codec to use to read/decode/encode/write.
Unless I have to change format to share with an NLE, I should only
be using one format, one codec (I'm speaking of codec class, not
individual codec implemetation).
If embedding DV in AVI gives me the advantage of sharing with an NLE,
then I'd like to be able to do that. If it truly is embedding (e.g.
just slap on some headers and copy the rest), that should be fine.
If any decompression and recompression is involved, that will be a
mess because I don't want to be doing that in real time, so that would
mean either duplicating files, or having the NLE user do it by hand
first.
|> I'm quite capable of designing my own file formats as needed.
|
| There are plenty of codecs already available up to and including
| lossless compression and raw (no-compression). You haven't
| mentioned any particular requirements that would lead us to believe
| that you need a new file format/codec.
I don't have a complete picture of what is in each possible file format.
There still remains too much proprietarism in these formats.
|> But guessing how someone else designed one is not at all easy.
|> Documentation is what is needed.
|
| You don't need to guess. There is more information out there right
| now than you have time to read in the rest of your lifetime.
I've found plenty of info, but everything so far found is incomplete
in one way or another. Maybe if all of it is merged it would be a
complete picture. But a lifetime is not the timeframe I want to work
in to make this project proposal.
A free online copy of the DV specs and the AVI specs would be the quick
solution. There is no money, yet, to buy any formal documents. There
won't be unless I can make a proposal that would be accepted. But I
cannot estimate the costs involved without knowing what all really is
involved.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
.
- References:
- Re: size of DV/1394 video stream
- From: Richard Crowley
- Re: size of DV/1394 video stream
- Prev by Date: Re: size of DV/1394 video stream
- Next by Date: Re: size of DV/1394 video stream
- Previous by thread: Re: size of DV/1394 video stream
- Next by thread: Re: size of DV/1394 video stream
- Index(es):
Relevant Pages
|
Loading
