Hi Patrick,
As Marius noted, the best CODEC depends on what you are going to do with the video. The MPEG gang of CODECs (from MPEG-2 on through H-264) are very good for standard playback and have a good quality/file-size ratio. All visual CODECs use spatial coding - reduction of perceptual redundancies in the 2D plane of a given frame; but another way these CODECs achieve such good ratios is by using temporal coding to reduce frame to frame redundancies. They take a GOP (Group of Pictures, not an antediluvian near-extinct political party) and make decisions about what information is important. Some frames are fully represented and other frames are coded with reference to the ones around them. This saves a lot of space, but you do not have a full representation of each frame. During normal playback this is not a problem, but if you want to mess with the playback rate it is.
If you want to do any scrubbing, varispeed or playing backwards of the video, you need a CODEC which does not use temporal compression. Photo-JPEG is in fact a very good choice in this case and if compressed at 320 X 240 you get a good balance of file-size, picture quality and processor load. JPEG 2000 should also be a good choice (supported by QuickTime and there are libraries which support it on Linux but not sure if it will play in GEM). I have used DV video with good results and this may be a good option if you need high quality playback.
However, if you have unlimited bandwidth and storage, why not just go for uncompressed D-1 video? (~30M/s) ;)
cheers, Andrew
On Fri, 30 Nov 2007, pd-list-request@iem.at wrote:
hi,
i am on linux running the very last version of gem from cvs. i am trying to find a good codec for gem. here's my basic research:
the best codec for quicktime is jpeg: transcode -i yourvideo -y mov,null -F jpeg,,jpeg_quality=70 -o gem.mov
gem cpu usage is 38% mplayer cpu usage is 27% ffplay cpu usage is 16% lqtplay cpu usage is 1% **
for avi i tried ffmpeg / mjpeg: transcode -i yourvideo -y ffmpeg,null -F mjpeg -o gem.avi
gem cpu usage is 33% mplayer cpu usage is 33% ffplay cpu usage is 22%
the really best codec around is mpeg4: transcode -i yourvideo -y ffmpeg,null -F mpeg4 -o gem.avi
gem cpu usage is: crashed** mplayer cpu usage is 16% ffplay cpu usage is 11%
- lqtplay seems to make a excellent job for decoding is own codec. would
it be possible to make a pix_qt based on the source of this player???
** anybody can test this codec? that would be my second choice... after lqtplay ported to gem...
pat
Am 02.12.2007 um 16:35 schrieb Andrew Brouse:
If you want to do any scrubbing, varispeed or playing backwards of the video, you need a CODEC which does not use temporal compression. Photo-JPEG is in fact a very good choice in this case and if
compressed at 320 X 240 you get a good balance of file-size, picture quality and processor load. JPEG 2000 should also be a good choice (supported by QuickTime and there are libraries which support it on Linux but not
sure if it will play in GEM).
hi andrew,
i wonder if the photo-jpeg compression does introduce a jitter in the
decoding speed depending on the complexity of the content. gem would
need a different time to decode each time a different frame is called.
i am working now with 1024x768 video compressed with 75% quality
photojpeg and sometimes see lags in the decoding.. but maybe it's
just my imagination.
max
On Sun, 2007-12-02 at 17:03 +0100, Max Neupert wrote:
Am 02.12.2007 um 16:35 schrieb Andrew Brouse:
If you want to do any scrubbing, varispeed or playing backwards of the video, you need a CODEC which does not use temporal compression. Photo-JPEG is in fact a very good choice in this case and if
compressed at 320 X 240 you get a good balance of file-size, picture quality and processor load. JPEG 2000 should also be a good choice (supported by QuickTime and there are libraries which support it on Linux but not
sure if it will play in GEM).hi andrew,
i wonder if the photo-jpeg compression does introduce a jitter in the
decoding speed depending on the complexity of the content. gem would
need a different time to decode each time a different frame is called. i am working now with 1024x768 video compressed with 75% quality
photojpeg and sometimes see lags in the decoding.. but maybe it's
just my imagination.
is the playback synced to gems rate or does it run on its own ('auto 1' -> [pix_film])? if the latter is the case, consider syncing the playback to gems framerate (choose the framerate of the videofile for gemwin, of course).
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hi Max,
JPEG decompression should be very fast on any modern CPU, it is however possible that at those frame sizes and 30 FPS, you may be seeing some jitter. If you are at 30 FPS, try reducing it to 15 or even 10 FPS and see what happens.
cheers, Andrew
hi andrew, list,
here is a test patch which shows quite some jitter. but jpeg
compression and uncompressed alike. i'd like to hear from some gem
pros what they think on how to minimize the jitter. also i wonder why
the movie loops not always in the same speed - do i need a
realtimemetro?
btw. this patch can be used to reduce the gem framerate automatically
if the rendering is slower than the framrerate to avoid gem locking
up the computer (thanks sven for that hint).
Am 03.12.2007 um 08:11 schrieb Andrew Brouse:
Hi Max,
JPEG decompression should be very fast on any modern CPU, it is
however possible that at those frame sizes and 30 FPS, you may be
seeing some jitter. If you are at 30 FPS, try reducing it to 15 or
even 10 FPS and see what happens.cheers, Andrew
--
On Sun, 2 Dec 2007, Max Neupert wrote:
Am 02.12.2007 um 16:35 schrieb Andrew Brouse:
If you want to do any scrubbing, varispeed or playing backwards
of the video, you need a CODEC which does not use temporal compression. Photo-JPEG is in fact a very good choice in this case and if
compressed at 320 X 240 you get a good balance of file-size, picture quality and processor load. JPEG 2000 should also be a good choice (supported by QuickTime and there are libraries which support it on Linux but
not sure if it will play in GEM).hi andrew,
i wonder if the photo-jpeg compression does introduce a jitter in
the decoding speed depending on the complexity of the content. gem
would need a different time to decode each time a different frame
is called. i am working now with 1024x768 video compressed with 75% quality
photojpeg and sometimes see lags in the decoding.. but maybe it's
just my imagination.max
-
Andrew Brouse -
Max Neupert -
Roman Haefeli