On 2010-08-16 16:36, Burkhard Plaum wrote: > Hi, >> > > Hehe :) > > Of course, as the last possibility, I can declare the file as broken. And it > will be > hard to prove me wrong.
true enough. however, this is the timeline of my problem: - a user reports problems with h.264 files being incredibly slow - i don't have an h.264 files lying on my harddisk - therefore, i search the net and find the said file. - it exposes the same symptoms now i fully agree, that having the user's original file would be better for analysing (and hopefully curing) their problem. but it seems intriguing, that 2 independent h.264 show the same symptoms (unless of course my user also used the very same file...) we might try 3 other random files from the web, and if "many" of them show the symptoms, you can decide whether you simply declare all those files broken or whether we should do something about it :-) > > If you want to know all frame times in advance (and you use sample accurate > mode > anyway) you can get a frame table for that stream: > > http://hirntier.blogspot.com/2009/09/frame-tables.html > > This allows things like "find the frame, which is displayed at time x" or > "get the pts of the yth frame". thanks a lot, this is very useful information. i changed my code to use the frametable (if available). one question: what does bgav_get_frame_table() imply (e.g. in terms of system ressources)? the reason why i'm asking is, that it is often hard to know (without benchmarking), which functions will consume ressources. e.g. my frame grabbing code is threaded; in the gmerlin case, the thread calls bgav_read_frame() and gavl_video_convert(), but bgav_seek_...() is in the main thread! since with the problematic file, most time was spent in the seek, my app was not very responsive. i have no idea how to document this properly though (putting some hints into doxygen would enforce you to track changes behind the scenes manually) fgmadr IOhannes
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Gmerlin-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gmerlin-general
