GNOME Bugzilla – Bug 458629
[avidemux] high memory usage for many index entries
Last modified: 2009-10-07 20:51:41 UTC
Avidemux builds the index as a list and then sorts it into an array. This leads to a hight peak memory usage. Clips can easily use 20 mb for the index. So we touch 40 mb of memory before even going to playing. Imho working on the list is just fine. Seeking is not the usual usecase and going from one entry to the next is equaly fast with a sorted list.
Created attachment 92040 [details] [review] conditionaly disable index copying
Created attachment 94855 [details] [review] conditionaly disable index copying Little cleanup of the patch.
Created attachment 97890 [details] [review] conditionaly disable index copying Updated patch against cvs head. Any comments about the patch?
The patch needs updates once again, as this commit totally broke it :/ Revision 1.231 - (view) (download) (as text) (annotate) - [select for diffs] Mon Jun 2 16:09:59 2008 UTC (7 days, 21 hours ago) by wtay Branch: MAIN Changes since 1.230: +152 -48 lines Diff to previous 1.230 Patch by: Thijs Vermeir <thijsvermeir at gmail dot com> * gst/avi/gstavidemux.c: (gst_avi_demux_index_next), (gst_avi_demux_index_prev), (gst_avi_demux_index_entry_for_time), (gst_avi_demux_do_seek), (gst_avi_demux_handle_seek), (gst_avi_demux_process_next_entry): * gst/avi/gstavidemux.h: Implement reverse playback. Fixes #535300.
marking patch as obsolete
(In reply to comment #3) > Created an attachment (id=97890) [edit] > conditionaly disable index copying > Updated patch against cvs head. > Any comments about the patch? I was trying to study this patch but observed a strange part in between. at line number 85 "gst_avi_demux_index_last" function is implemented for GST_AVI_DISABLE_INDEX_ARRAY macro. But "gst_avi_demux_index_next" function implementation is missing is it ok?
(In reply to comment #3) > Created an attachment (id=97890) [edit] > conditionaly disable index copying > Updated patch against cvs head. > Any comments about the patch? I have applied the above patch on my gst-plugins-good 0.10.10 package. Earlier I was not able to play huge files like 600MB due to memory constraint. After applying this patch I am able to play 600MB files. Please let me know whether I can use this patch or will it give some other kind of defect? Why this patch is marked as obsolete here?
Manish, you could apply the patch? It was marked as obsolete, because it did not apply to CVS anymore. If you have corrected it, can you regenerate the patch and reapply? I think the idea behind the patch is still valid.
(In reply to comment #8) > Manish, you could apply the patch? It was marked as obsolete, because it did > not apply to CVS anymore. If you have corrected it, can you regenerate the > patch and reapply? I think the idea behind the patch is still valid. No! I was facing some issue while applying the patch. Right now I have taken the changes manually. I need to create a patch against the Head version to update on CVS. I will try to update it on CVS after testing.
Created attachment 137676 [details] [review] patch adaptation for plugins-good-0.10.15
Created attachment 137677 [details] [review] same patch but with .h file patched
Benjamin, using a GList instead of an array will take more memory and will be slower to parse than using an array... so I don't really understand your patch.
it's removing one copy of the entries in gst_avi_demux_massage_index function. To be honest I have only updated the obsolete patch to adapt it for plugins-good-0.10.15
Edward, the po nt of the patch is to avoid the peak memory consution that current avidemux has. It copies the list to the array and thus needs the double memory for a short moment. Also the list is not the performance bottleneck. There is one more indirection in searching. We could use a GSequence maybe to get a binary search (when the patch was made, there was no binary search in the array either).
This is now obsolete with the avidemux rewrite