[GEM-dev] [ pd-gem-Bugs-2977716 ] pix_film with DS eats up cpu in W32

[SourceForge.net]

Bugs item #2977716, was opened at 2010-03-27 09:26
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2977716&group_id=64325

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: win32
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_film with DS eats up cpu in W32

Initial Comment:
When I send an [open( message to a pix_film object, if it uses DirectShow (as opposed to QuickTime) to decode the file, it starts consuming an enormous amount of cpu: around 30% of a 2.5GHz Intel Core Duo machine. Furthermore, it never stops eating that much cpu, even if you stop repdorucing the file (by setting auto to 0 and not changing the frame through the right inlet) and even if you disconnect it from the gemhead.

This happens with file encoded with various codecs: DV-PAL, H.264, Animation+, and I suspect everything else.

Note that if I open the files with QuickTime instead of DS (by appending the proper number to the open message), then this does not happen: the impact of opening the file on the CPU is minimal, almost impossible to note, and it only consumes cpu during few seconds after opening the file, and when _actually_ playing it (i.e. a gemhead connected to it and changing frame). That is, with quicktime pix_film only consumes CPU when it is supposed to, and it is much much less CPU: you can easily read 6 full-size DV-PAL files actually rendering some portion of them on the screen, and you can have a dozen of pix_film with [open(ed files without impact on CPU (or even many more, then the impact won't be on CPU but on performance in general due to the memory trashing).

This can't be normal: DirectShow is supposed to be much faster than QuickTime on Windows; also, any given media player will open a video file using DirectSHow and without eating up nearly as much cpu, especially when not playing.
There must be something wrong in GEM.



----------------------------------------------------------------------

>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-17 07:46

Message:
i think the problem might be caused by threaded reading (which is
prohibited by QuickTime, as it is not thread safe).

you can disable threaded film decoding by sending a [thread 0( message
prior to opening a new file.

----------------------------------------------------------------------

Comment By: Matteo Sisti Sette (sistisette)
Date: 2010-08-22 12:27

Message:
I'm not sure but I don't think it is related to seeking because:

- cpu consumption doesn't stop even if you don't send any frame number AND
turn off "auto", that is, if you stop at a given frame
- cpu consumption doesn't stop even after you disconnect pix_film from the
gemhead

If you remember the problem I reported in Linux, where there _is_
apparently a problem with frame-accurate seeking (but only with some
codecs, maybe only h264), cpu consumption stops when you stop sending frame
numbers to pix_film with auto turned off, and of course it stops if you
disconnect it from the gemhead.

----------------------------------------------------------------------

Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2010-08-22 11:16

Message:
i meant to say, that this is a "tough" one, rather than touching...

----------------------------------------------------------------------

Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2010-08-22 11:16

Message:
that's a touch one.
there might be a problem with Gem using frame accurate seeking for
playback, which might be handled better by QT than by DS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2977716&group_id=64325