View Full Version : SLOW Demuxing speeds for matroska
-=Stan=-
1st June 2003, 18:39
I was just wondering why demuxing matroska is so slooooooooow.
While OGG delivers a 500-1000 fps matroska never goes over 90 fps in direct stream copy mode .
Matroska was supposed to be meant for video editing purposes , i would definitely not use it if it performs like this in future as well ( i am not using it right now , becos of its various other limitatitions which have already been discussed) .
I really hope this thing would be temporary and sooner than later a better fps can be achieved .
OFFTOPIC : there seems to be bug as well in vdubmod . more than often it crashes when trying to select an external vorbis stream even with OGG .
EDIT :- Removed the bit about muxing .
CaptainCarrot
1st June 2003, 18:59
I get pretty much the same muxing speeds for ogm and mkv when using vdubmod.
robUx4
1st June 2003, 19:20
Same here.
Stan, what configuration do you have (CPU speed, memory amount, memory used, etc) ?
-=Stan=-
1st June 2003, 19:43
OK
My fault the problem is not actually with muxing but with demuxing .
For example try this :-
Take an OGM convert it to MKV .
This gives 500-1000 fps.
Now convert the MKV to OGM .
This gives 7-90 fps.
Another bug report for VdubMOD -
Crashes on some files muxed with OGGMUX .
ChristianHJW
1st June 2003, 22:50
Stan,
this is a known problem we have in VdubMod, there is a memory leak that eats your RAM like crazy, so it will start pretty quick, with about 100 fps and then come to the point where all the RAM is used and Windows is using the Virtuald memory ( HDD ), and that's the point when demuxing speed drops to low 10 fps, or even lower, until it finally crahes when all your virtual memory is used up.
The problem is known and also fixed, it was a problem in our library, libmatroska would take some memory and not release it again, so when its trying to read a big file by time all the usable memory gets eatne up. In the next release of vdubMod this problem will be fixed, it is already in CVS, but now we have another bug so we first have to find that until Cyrius and Belgabor can make a new release.
CaptainCarrot
11th June 2003, 11:41
I think I just found out what Stan complained about: I just tried to demux a vorbis-track from a mkv-file, and it takes AGES, vdubmod (latest one, just downloaded) estimates 40min for a 2hour-track. It's really hard to use mkv as editing-container with this performance.
Regards
ChristianHJW
11th June 2003, 12:07
Originally posted by CaptainCarrot to demux a vorbis-track from a mkv-file, and it takes AGES, vdubmod (latest one, just downloaded) estimates 40min for a 2hour-track.
:( .... are you sure you have the latest build from 10/06/03 ? If you look at the Memory usage in task manager, how much does it use ? Did you activate the switch in the new 'preferences' tree that will speed up MKV processing ?
CaptainCarrot
11th June 2003, 12:12
I have the 10/06/03-build, memmory-usage is ~8.5MB. It didn't have the
"speed up mkv-reading" switch checked, but I just switched it on and tried again, it doesn't seem to make a difference.
EDIT: I just tried to simply open the mkv-movie and save it back to mkv with direct stream copy (all streams included, no changes), and I get only 25-100fps remuxing speed mkv->mkv, estimated time ~50min for 2h movie (xvid+1ogg-track)!
Gaia
11th June 2003, 12:25
Just a little note. Latest build is 20030611 not 20030610 :)
CaptainCarrot
11th June 2003, 12:36
Originally posted by Gaia
Just a little note. Latest build is 20030611 not 20030610 :)
Latest precompiled is 20030610, "Me dumb user, me no compiling" :D
For CVS you're right, but I don't know what to do with it, and don't have the time to find out atm.
-=Stan=-
19th June 2003, 18:50
Alright this is the result with the latest CVS compile "20030611"
And Matroska demuxing still is very slooooooooow.
about 120fps .
Is it a bug or matroska's limitation , i sure hope not for the latter .
BTW , How do i use the Matroska Muxer by gabest , it seams to be a directshow implementation .
Think it might help my cause .
-=Stan=-
21st June 2003, 12:15
Finally
I found out .
It was my fault again .
Forgot to turn on the Matroska speeding option in VdubMod .
But why is it an option .
I mean why does it need to ask to speed up .
Any benefits by slowness??
Another thing , i figured out how to use Gabest's filters using Graphedit .
Switching to Matroska now from OGM .
Suiryc
21st June 2003, 13:27
Originally posted by -=Stan=-
But why is it an option .
I mean why does it need to ask to speed up .
Any benefits by slowness??
You have the choice here :
the 'old' method : slow, but requires less memory
the 'new' method : faster, but requires more memory
The main difference between the 2 methods concerns what elements in the file are saved in the index we build in memory.
Both methods build an index containing information about Clusters, Blocks and Frames in the file. The 'old' method only store the position in file (64 bits == 8 bytes) of the Clusters (depending on the tool and settings you used - see the 'time limit' preference for clusters - generally one cluster represents from 1 to 5 seconds of data). So when reading data from the file the simple way is to seek on the cluster and skip frames until the one we want (which is why this method is slow).
The 'new' method also store the position in file of each Block (generally one Block == 1 video frame) and goes directly on the block when reading data, which is why this method is faster. However this method requires at least 8 more bytes per Block. So for a 150000 frames clip (video only) this method requires at least 1.2MB more than the old method. If you have an audio stream this could be 2MB, 3MB for 2 audio streams and so on ...
ChristianHJW
21st June 2003, 13:52
Originally posted by -=Stan=- Switching to Matroska now from OGM .
:) .... the faster matroska processing needs a lot more memory, thats why it has to be turned on as an option specifically ...
Atamido
21st June 2003, 17:46
I'm pretty sure that any modern computer can spare 2-3MB of ram. You should pretty much always use this choice unless you have a special situation.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.