The VideoLAN Forums

I have these large ASF files - about 5 Gig - and VLC picks them up and says they are 10 minutes long.

I can ask VLC to convert them and it'll do it - and produce a 10 minute file.

These files are produced by my webcam management software. Each 5Gig file represents about 3 hours of camera time.

That software does not allow speedy scanning of these files, which, of course, I need.

I felt sure VLC would do it. But no. There's something wrong with these files. They work fine in the software that produces them and they are taken up by any software that should take them up and processed - partially. This 10minute thing is quite common.

Can the VLC community point to where the problem is and what I might be able to do about it?

Are you sure 5GB asf files are valid?

Well I'm no expert but I think so.

According to the spec the FileSize field is 64 bit.

I got the Windows Media ASF View and tried to use it. It immediately gave me two error messages:


The Source File: 09_32_14.asf 9,967,251 KB

The error messages:
First:
object data size (170105543662467326155) is greater than available data (8591587102) by

17010554353875739053 bytes.

===========================================
Second:

Failure (E_UNEXPECTED - "Catastrophic failure") parsing file at position 1614877554 (8591587126 remaining)
==========================================

And it then runs on and does its best and reports the EOF as being at that place: 1614877554.

It then lists the number of data packets as 1 275 601

and tells me the packet size is 8000.

1 275 601 x 8000 = 10 204 808 000 which would be the correct size for the file.

So within itself the file has something causing a 'catastrophic failure'.

I'll find a byte level editor and see if I can see what's there.

And I'll look at some other files and see if they all have this problem.

Looks like it quite definitely isn't anything wrong with VideoLan - as of course we all knew would be the case

It is something wrong with the software that writes the file.

regards,

ab

I have the same problem with large ASF files.

My workaround: Convert to a .mp4 file, keeping the orignal video and audio tracks (and not transcoding any new ones). This goes very fast, as it's only re-containering the file. The result should play in its entirety, with seeking and other trick play features working correctly.

Well thanks, I'll try that - if I can... I've been saying part of my whole prob here is that I can't get anything to accept the whole file to convert it... and I couldn't even get asfbin or asftools or whatever to accept it to fix it: one of them refused point blank - header missing critical info - and the other took it in and thought it was only 10min long.

What do you use to convert yours?

What do you use to convert yours?

VLC. Media->Convert/Save. Select appropriate profile; in my case it's H.264 + AAC. Or, if needed, set up one of your own. Edit the profile so Encapsulation is MP4/MOV, Video codec page shows Keep original ... checked, but Video is unchecked. Do similarly for Audio codec. Press Save, choose an output file name with .mp4 extension, Uncheck Display the output, press Start.

You should see the current time count past the (incorrect) ending time, all the way to the actual end of the program. There will then be a delay (several minutes) while the file is indexed. When the time indicators go blank (and activity on your hard drive stops), the .mp4 file is ready for playback.

Aaah, sooo........

Thanks for taking the trouble to spell it out for me. I completely missed the point. Sounds like a good one, alright, I will jump right into it soon as I get a chance....

Thank you again...



p.s. a few hours later.... YES! I checked it out. Processed a 4G file which VLC and various other things saw at just 5 minutes where really it should have been 2hr 45min.

The above process created an MP4 which I can hurtle backward and forward through with the slider at will. Took some time to do it and a bit confusing at the end... I wasn't sure it was finished, the advice 'streaming' remained there in the window with nothing to indicate that I saw that it was finished.

But fine with me. I'm very pleased with that result. I need to learn more about multimedia files. I want to know why this happens. You say just a 'container' - well in that case if it plays okay in one container but not in another then the fault must lie in the containers and they must be doing the processing of the file or part of it, enough to screw it up sometimes. Right?

Or is it that the container defines things the reading software needs to know to properly read the file? And some folks are not writing proper containers and that causes some software to either render the file incorrectly or refuse to attempt it (as asfbin did, I think) ?

But in that case, thinks I, how could VLC change the container and write a valid container if it didn't have a valid description in the previous container?

By just reading the raw file, perhaps, and extracting certain basic info which is all that the mp4 container requires to know?

But if that were the case why would some software give up on the file (like asfbin or whatever it was) and not resort to reading the 'raw' file itself, and supplying missing parameters..... ?

My thinking goes round and round and gets to no conclusion..... one day perhaps.......