AVIfile vs. DirectShow
Michael A. Covington
is available?
What's being contemplated is a special-purpose video editor, doing something
relatively simple.
Michael A. Covington
formats which have the .avi extension but are not processable with the old
AVIfile (VfW32) package.
"Michael A. Covington" <lo...@ai.uga.edu.for.address> wrote in message
news:OHECPjpA...@TK2MSFTNGP09.phx.gbl...
Alessandro Angeli [MVP::DigitalMedia]
> I think I've found my answer. Microsoft says there are
> new interleaved file formats which have the .avi
> extension but are not processable with the old AVIfile
> (VfW32) package.
Those are OpenDML AVIs (or AVI2.0, they can larger than 2/4
GB) and DV Type-1 files. Even if I think you can still use
mmIO to read/write them.
AVIFile is a set of functions to handle AVI1.0 and WAV
system streams, while mmIO is a set of functions to handle
generic RIFF files at a lower level.
DirectShow is a more general framework to perform almost any
kind of operation on virtually any kind of stream. The stock
filters provided in Windows can do part of the work that
AVIFile does, but not everything, but they can do it on
AVI2.0 and DV Type-1 files as well. DirectShow is also far
more complex to use for simple I/O and editing tasks.
--
// Alessandro Angeli
// MVP :: Digital Media
// a dot angeli at psynet dot net
Michael A. Covington
"Alessandro Angeli [MVP::DigitalMedia]" <nob...@nowhere.in.the.net> wrote in
message news:erCimevA...@TK2MSFTNGP12.phx.gbl...
> Michael A. Covington wrote:
>
>> I think I've found my answer. Microsoft says there are
>> new interleaved file formats which have the .avi
>> extension but are not processable with the old AVIfile
>> (VfW32) package.
>
> DirectShow is a more general framework to perform almost any kind of
> operation on virtually any kind of stream. The stock filters provided in
> Windows can do part of the work that AVIFile does, but not everything, but
> they can do it on AVI2.0 and DV Type-1 files as well. DirectShow is also
> far more complex to use for simple I/O and editing tasks.
Hmmm... What I am wanting to do is simple: based on choices made by the user
of my program, create an .avi file by segmenting together existing .avi
files, perhaps also chopping them up at specific points and inserting
material. The existing .avi files will be a library supplied with my
software, so I can be sure they are AVI 1.0.
That sounds like a job for AVIFile, doesn't it? Do you think there's a good
reason -- in the long run -- for using DirectShow instead? Is AVIFile going
to remain supported by Windows for the next several years or more?
Thore Karlsen [MVP DX]
<lo...@ai.uga.edu.for.address> wrote:
>>> I think I've found my answer. Microsoft says there are
>>> new interleaved file formats which have the .avi
>>> extension but are not processable with the old AVIfile
>>> (VfW32) package.
>> DirectShow is a more general framework to perform almost any kind of
>> operation on virtually any kind of stream. The stock filters provided in
>> Windows can do part of the work that AVIFile does, but not everything, but
>> they can do it on AVI2.0 and DV Type-1 files as well. DirectShow is also
>> far more complex to use for simple I/O and editing tasks.
>Hmmm... What I am wanting to do is simple: based on choices made by the user
>of my program, create an .avi file by segmenting together existing .avi
>files, perhaps also chopping them up at specific points and inserting
>material. The existing .avi files will be a library supplied with my
>software, so I can be sure they are AVI 1.0.
>
>That sounds like a job for AVIFile, doesn't it? Do you think there's a good
>reason -- in the long run -- for using DirectShow instead? Is AVIFile going
>to remain supported by Windows for the next several years or more?
This sounds like it would be easier accomplished in AVIFile than in
DirectShow. Chopping and splicing AVI files accurately in DirectShow can
be a pain. I think it will be supported for quite a while, so I wouldn't
worry too much. Perhaps there are other places in your application where
DirectShow would be a better fit, like perhaps for previewing the video
clips and such.
--
New to newsgroups? Read: http://dev.6581.com/newsgroups.html
Michael A. Covington
>>user
>>of my program, create an .avi file by segmenting together existing .avi
>>files, perhaps also chopping them up at specific points and inserting
>>material. The existing .avi files will be a library supplied with my
>>software, so I can be sure they are AVI 1.0.
>>
>>That sounds like a job for AVIFile, doesn't it? Do you think there's a
>>good
>>reason -- in the long run -- for using DirectShow instead? Is AVIFile
>>going
>>to remain supported by Windows for the next several years or more?
>
> This sounds like it would be easier accomplished in AVIFile than in
> DirectShow. Chopping and splicing AVI files accurately in DirectShow can
> be a pain.
Can you elaborate on that? What's involved in such things as:
splicing frames 1-139 (or whatever number) of first video, followed by the
whole of the second video repeated twice, followed by frames 140-205 of the
first video?
If it's only *moderately* a pain, I'll go ahead and do it. What's it like?
> I think it will be supported for quite a while, so I wouldn't
> worry too much. Perhaps there are other places in your application where
> DirectShow would be a better fit, like perhaps for previewing the video
> clips and such.
Thanks.
Thore Karlsen [MVP DX]
<lo...@ai.uga.edu.for.address> wrote:
>>>Hmmm... What I am wanting to do is simple: based on choices made by the
>>>user
>>>of my program, create an .avi file by segmenting together existing .avi
>>>files, perhaps also chopping them up at specific points and inserting
>>>material. The existing .avi files will be a library supplied with my
>>>software, so I can be sure they are AVI 1.0.
>>>
>>>That sounds like a job for AVIFile, doesn't it? Do you think there's a
>>>good
>>>reason -- in the long run -- for using DirectShow instead? Is AVIFile
>>>going
>>>to remain supported by Windows for the next several years or more?
>> This sounds like it would be easier accomplished in AVIFile than in
>> DirectShow. Chopping and splicing AVI files accurately in DirectShow can
>> be a pain.
>Can you elaborate on that? What's involved in such things as:
>splicing frames 1-139 (or whatever number) of first video, followed by the
>whole of the second video repeated twice, followed by frames 140-205 of the
>first video?
>
>If it's only *moderately* a pain, I'll go ahead and do it. What's it like?
Well, to put it this way: I've been working with DirectShow for several
years now, and I cringe at the thought of doing this in DS. I have
actually done it, but if I were to do it over again I would either use
the AVIFile API or write code to do the AVI parsing/writing myself. I
think that would be cleaner and easier.
The biggest obstacle to doing this in DS is that you have to write to
one output file, but you have to switch between multiple input files.
You also have to seek to the right frame in the input files, as well as
stop at the right frame. DirectShow just wasn't designed for this. If
you do want to do it, though, look at GMFBridge here:
http://www.gdcl.co.uk/downloads.htm
You'll need it for switching between the input files.
Michael A. Covington
"Thore Karlsen [MVP DX]" <s...@6581.com> wrote in message
news:mfo9q1l0v0f00u1q9...@4ax.com...
>>Can you elaborate on that? What's involved in such things as:
>>splicing frames 1-139 (or whatever number) of first video, followed by the
>>whole of the second video repeated twice, followed by frames 140-205 of
>>the
>>first video?
>>
>>If it's only *moderately* a pain, I'll go ahead and do it. What's it
>>like?
>
> Well, to put it this way: I've been working with DirectShow for several
> years now, and I cringe at the thought of doing this in DS. I have
> actually done it, but if I were to do it over again I would either use
> the AVIFile API or write code to do the AVI parsing/writing myself. I
> think that would be cleaner and easier.
Thanks, that is very useful. I've actually done a bit of AVI parsing
because I wanted to write a utility that would look at a directory, find all
the AVI files in it, and write out brief descriptions of them (format,
number of frames, etc.). It's not that hard.
Given that I'll be in control of the AVI files, it actually might be an
*advantage* if my program wouldn't work with (some) AVI files that
originated elsewhere.
> The biggest obstacle to doing this in DS is that you have to write to
> one output file, but you have to switch between multiple input files.
> You also have to seek to the right frame in the input files, as well as
> stop at the right frame. DirectShow just wasn't designed for this. If
> you do want to do it, though, look at GMFBridge here:
>
> http://www.gdcl.co.uk/downloads.htm
>
> You'll need it for switching between the input files.
This sounds like a very good reason for Microsoft to keep AVIfile alive for
a long time!
Any opinions from anyone else?
Many thanks!
Michael
Iain
>
> Well, to put it this way: I've been working with DirectShow for several
> years now, and I cringe at the thought of doing this in DS. I have
> actually done it, but if I were to do it over again I would either use
> the AVIFile API or write code to do the AVI parsing/writing myself. I
> think that would be cleaner and easier.
>
> The biggest obstacle to doing this in DS is that you have to write to
> one output file, but you have to switch between multiple input files.
> You also have to seek to the right frame in the input files, as well as
> stop at the right frame. DirectShow just wasn't designed for this. If
> you do want to do it, though, look at GMFBridge here:
>
> http://www.gdcl.co.uk/downloads.htm
>
> You'll need it for switching between the input files.
The other thing you could look at is 'DirectShow Editing Services' DES
which is aimed at exactly this sort of task.
However, frankly I'm with Thore on this one. DS is obscure, complex and
not overwhelmingly clearly documented. DES adds several levels of
obfuscation and has VERY few practitioners (I am NOT one of them!).
Iain
--
Iain Downs (DirectShow MVP)
Commercial Software Therapist
www.idcl.co.uk
Michael A. Covington
> which is aimed at exactly this sort of task.
>
> However, frankly I'm with Thore on this one. DS is obscure, complex and
> not overwhelmingly clearly documented. DES adds several levels of
> obfuscation and has VERY few practitioners (I am NOT one of them!).
Thanks. The bottom line is this: If AVIfile will do everything I need to
do, am I endangering the long-term future of my software by using it?
Thore Karlsen [MVP DX]
I doubt it. Microsoft has a good track record when it comes to
supporting applications that use legacy APIs.