Chopping and joining
Iain
different order.
My thoughts were to use IWMSnycReader to read teh compressed samples and
write them to several files in succession.
The clever bit (?) is to break the streams at WM_SF_CLEANPOINT samples and
ensure that the last sample in each output file and the first sample in
each output file is a cleanpoint (so when you want to swap, the put the
identified cleanpoint sample as the last sample in the first output file
AND the first sample in the next output file).
Will the work? I'm only worried because, my initial tests show that the
last sample in a file is not necessarily marked as a cleanpoint.
Iain
--
Iain Downs (DirectShow MVP)
Commercial Software Therapist
www.idcl.co.uk
Jeremy Noring
> I have a need to chop up some WMV streams and stich them back together in a
> different order.
>
> My thoughts were to use IWMSnycReader to read teh compressed samples and
> write them to several files in succession.
>
> The clever bit (?) is to break the streams at WM_SF_CLEANPOINT samples and
> ensure that the last sample in each output file and the first sample in
> each output file is a cleanpoint (so when you want to swap, the put the
> identified cleanpoint sample as the last sample in the first output file
> AND the first sample in the next output file).
>
> Will the work? I'm only worried because, my initial tests show that the
> last sample in a file is not necessarily marked as a cleanpoint.
It will work, so long as a few conditions are true:
1. The content must be the same resolution--so no joining QVGA and VGA clips
together without re-encoding
2. You'll need to swap files on a keyframe. And no--a file doesn't always
end in a keyframe. However, WMV files should always start on a keyframe.
So, when you either get to a keyframe in a file that's roughly where you want
to jump over to the next file, or you receive NS_E_NO_MORE_SAMPLES from the
sync reader, you'll want to close out that file and open a new file.
3. In rare situations where the two files have differing "extra data" (magic
four bytes in the Stream Properties Object), appending them will have very
bad results. However, this is pretty uncommon, especially for files created
with with WM*SDKs. If you're using a third party encoder, however, this
probably applies to you.
You might also look at the WMVAppend sample, which does exactly what you're
talking about but for some bizarre reason, does not use the sync reader
(about a billion times easier to use, IMO). I'd strongly recommend using the
sync reader.
Alessandro Angeli [MVP::DS/MF]
> 2. You'll need to swap files on a keyframe. And no--a
> file doesn't always end in a keyframe. However, WMV
> files should always start on a keyframe.
Unfortunately, that's not always the case: a WMV can start
with a discontinuity and all samples up to the next
cleanpoint must be discarded. This is uncommon with files
created off-line or edited with the WM tools, but it may
happen with files created or edited with third-party tools,
including the SBE.
> You might also look at the WMVAppend sample, which does
> exactly what you're talking about but for some bizarre
> reason, does not use the sync reader (about a billion
> times easier to use, IMO). I'd strongly recommend using
> the sync reader.
IIRC, the WMVAppend sample has been in the SDK since the
first release, when the WMSyncReader was still a dream.
--
// Alessandro Angeli
// MVP :: DirectShow/MediaFoundation
// a dot angeli at psynet dot net
Alessandro Angeli [MVP::DS/MF]
> I've never seen it, but I could see how third party tools
> would ignore that rule--to what end, and why, I don't
> know. It seems foolish to me.
If you are recording from a real-time source, you can't go
back in time to the last cleanpoint or wait for the next one
that may be in the "distant" future. Unless you want to
loose the other sync'ed streams as well, most notably audio,
you have to start muxing what you have and let the player
deal with the discontinuity afterwards. Moreover, the
WMWriter has only a very limited tolerance for out-of-sync
streams, so you can't mux a stream without the other, which
would also cause buffering problems at playback time.
This is also true after a data loss for whatever reason,
usually an I/O error from the media/channel.
>> IIRC, the WMVAppend sample has been in the SDK since the
>> first release, when the WMSyncReader was still a dream.
>
> Then I guess that begs the question: why hasn't it been
> re-written? =)
Don't break what works or don't waste money or don't even
remember :-)
Mikko Noromaa
>I have a need to chop up some WMV streams and stich them back together in a
> different order.
You might want to check out ASFBin at
http://www.radioactivepages.com/english/asfbin.html I have used it
successfully to cut out portions of WMV files.
--
Mikko Noromaa (mik...@excelsql.com)
- SQL in Excel, check out ExcelSQL! - see http://www.excelsql.com -
"Iain" <Ia...@idclTAKEAWAY.co.uk> wrote in message
news:h8za52mg74h1$.1d26aml4nx7vi.dlg@40tude.net...
Jeremy Noring
> If you are recording from a real-time source, you can't go
> back in time to the last cleanpoint or wait for the next one
> that may be in the "distant" future. Unless you want to
> loose the other sync'ed streams as well, most notably audio,
> you have to start muxing what you have and let the player
> deal with the discontinuity afterwards. Moreover, the
> WMWriter has only a very limited tolerance for out-of-sync
> streams, so you can't mux a stream without the other, which
> would also cause buffering problems at playback time.
>
> This is also true after a data loss for whatever reason,
> usually an I/O error from the media/channel.
Okay, that makes sense. I stand corrected.
> >> IIRC, the WMVAppend sample has been in the SDK since the
> >> first release, when the WMSyncReader was still a dream.
> >
> > Then I guess that begs the question: why hasn't it been
> > re-written? =)
>
> Don't break what works or don't waste money or don't even
> remember :-)
(sorry, I'm a stubborn, pig-headed young man. bear with me)
Given that the purpose of a "sample" is to demonstrate how to correctly
perform a given task, and the sample currently demonstrates it in a way
that's not good, I'd say it doesn't "work."
I've tried modifying the Copy and Append samples to add additional
functionality, and in both instances, ended up just starting from scratch and
using the WM Sync reader. The net result was always startling; a reduction
of hundreds of lines of code, working code, and far more future proof. So,
in a certain sense, I would have been better off had those samples not even
been provided. Given that I wasted time with them, and time is
money....well....you get the idea. :-)
The March Hare [MVP]
>>>> IIRC, the WMVAppend sample has been in the SDK since the
>>>> first release, when the WMSyncReader was still a dream.
>>>
>>> Then I guess that begs the question: why hasn't it been
>>> re-written? =)
>>
>> Don't break what works or don't waste money or don't even
>> remember :-)
>
> (sorry, I'm a stubborn, pig-headed young man. bear with me)
>
> Given that the purpose of a "sample" is to demonstrate how to correctly
> perform a given task, and the sample currently demonstrates it in a way
> that's not good, I'd say it doesn't "work."
>
> I've tried modifying the Copy and Append samples to add additional
> functionality, and in both instances, ended up just starting from scratch and
> using the WM Sync reader. The net result was always startling; a reduction
> of hundreds of lines of code, working code, and far more future proof. So,
> in a certain sense, I would have been better off had those samples not even
> been provided. Given that I wasted time with them, and time is
> money....well....you get the idea. :-)
Sounds like this is a sample that you should have on your web site (if you
don't have it already).
Alessandro Angeli [MVP::DS/MF]
> I've tried modifying the Copy and Append samples to add
> additional functionality, and in both instances, ended up
> just starting from scratch and using the WM Sync reader.
> The net result was always startling; a reduction of
> hundreds of lines of code, working code, and far more
> future proof. So, in a certain sense, I would have been
> better off had those samples not even been provided.
> Given that I wasted time with them, and time is
> money....well....you get the idea. :-)
Are you saying that most SDKs' samples are over-functional,
over-complicated, sometimes outdated and, even if they may
work as useful tools, they don't work as samples? Get in
line :-))
Iain
THis has given me a terribly Deja VU shock. I've had to look 4 times to
make sure I'm not in ...directx.video!
Thanks to all.
Jeremy - I have code going back years which predates SyncReader and it is
shit to use. I've implemented a wrapper class to hide some of the
complexities, but there are aspects of stopping the flow (e.g. an abort)
which still elude me (I mean my code works, but it was trial and error) and
it is simply horrid to have to deal with. This is my first use or
SyncReader and it is a HUGE advance.
As to the rest, I think I'm in charge of creating the WMV files so I'm not
going to worry overly about the obscurities (but thanls, Alessandro for
pointing them out!).
Samples? Not clear and overcomplex? Surely, we can't be talking about the
same Microsoft?
Dmitry Vergeles (SolveigMM)
We have such a solution in SolveigMM AVITrimmer component (with WMV support)
take a look:
http://www.solveigmm.com/?Products&id=VideoSplitter
Best Regards,
Dmitry Vergeles
Solveig Multimedia
"Iain" <Ia...@idclTAKEAWAY.co.uk> wrote in message
news:h8za52mg74h1$.1d26aml4nx7vi.dlg@40tude.net...