[vlc-devel] Re: DV Hangs, Audio continues

Stefan de Konink skinkie at xs4all.nl
Wed Oct 19 23:49:46 CEST 2005

Vaclav Koldus wrote:
> Stefan, please could you share us your conclusions? I'm curious about
> it  too.
Yesterday I mailed with serveral authors of tools including mpeg4ip and
avidemux, I have more than basic understanding of the DV format so I
know in what direction I need to search.

What I know is that the avi container, especially the indexing makes the
files hang, but thats not the only thing. Premiere seems to store the
audio in the AVI file. Not in the DV stream as it does when exporting
back to the camera.

Basically you have the original AVI(DV(A+V) + A).
> What comes to my mind is to write a fake decoder module for VLC which 
> dumps your stream into a file before it's decoded. VLC should demux it
> for  you, even with OpenDML support, and then send it into your decoder,
> which  dumps it on disk.
I tryed this with mencoder, material from the Sony-FX1 camcorder
produced semi-good results, it played the rawvideo (thus audio+video) in
VLC, but no background music or good audio cuts because that is stored
inside the A part of the AVI file.

But I entered another domain of problems. Two girls around 15 you don't
give a Sony FX1 camcorder to toy around with, so you give them a little
less expensive DV-camcoder. This little less expesive camcoder seems to
produce probably LP audio, which is played twice as quick. I didn't find
out if this was hardware related or software related, we use the same
camera do to quick transfers to laptop on location.

After I got some results I ended up to just broadcast the next series of
programs that were available to me. And strangly they don't have any
problems at all.

My own hypothesis of this:
The material is made, the material is edited and put back in DV mode to
a recorder from premiere, so it is back on tape synced A/V. Then when
the material is actually needed it is loaded into premiere and saved to
harddisk in OpenDML but still DV-A and AVI-A are the same.

The other most likely method is that someone needed to do a quick fix,
and stored the fix directly to our external harddisk instead of
exporting it to DV. And importing it again. DV-A and AVI-A can now be
different, indexing might fail (it does actually in Mplayer) and VLC
can't keep up its good work for compensating it.

Ok, maybe a Pentium4 1.7GHz is not up to the task. Or it is, but no one
started to make some serious optimalisations -> software issue.


This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html

More information about the vlc-devel mailing list