Video playback timing is wrong when recording with --on-the-fly-encoding switch

[Valdisvi]

Binary package hint: recordmydesktop

Environment:
valdis@studio:/home/bin$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04 LTS
Release: 10.04
Codename: lucid
valdis@studio:/home/bin$ uname -a
Linux studio 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:09:38 UTC 2010 x86_64 GNU/Linux

When recordmydesktop is invoked with --on-the-fly-encoding switch, recorded file is played with video running ~twice faster than normal, so when ~1/2 of file is played, video stills and audio goes till the end.

To reproduce run command:
recordmydesktop --quick-subsampling --fps 16 --channels 1 --freq 22050 --on-the-fly-encoding --buffer-size 16384

If encoding after recording is chosen, e.g. with parameters:
recordmydesktop --quick-subsampling --fps 4

Then recorded file is OK.

[Valdisvi (valdis-vitolins)]

Actually it seems not that bug, it just doesn't complain about dropped frames.
Lowering video frames per second with switch --fps4 or even --fps1 fixes that, so anybody can test how many fps his computer can handle.

[Antonio Roberts (hellocatfood)]

I don't think it's entirely true that on-the-fly encoding capability is completely down to the computer. On my computer (specs below) I can do on the fly encoding at 30fps using ffmpeg with this command: ffmpeg -r 30 -s 1366x768 -f x11grab -i :0.0 -vcodec msmpeg4v2 -qscale 2 filename.avi

Yet when I try even 24fps using recordmydesktop the resulting video fails to play properly.

I think this confirms that the problem exists in recordmydesktop

-----
My computer: Dell Studio 1555: Pentium Dual Core T4300(2.1GHz,800MHz,1MB), 4096MB 800MHz DDR2 Dual Channel, 512 MB ATI Mobility RADEON HD 4570

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Scott Norris (scottie-z)]

I also experienced this bug, but also think it may simply be due to hardware specs. On my machine, lowering the screen resolution before starting the record eliminates the problem (and, in addition, it saves me having to transcode before uploading the file somewhere).

@Antonio: I think I've read that ffmpeg is multi-threaded, whereas I'm not sure that recordmydesktop is.

[Donjan Rodic (bryonak)]

The problem for me are dropped frames too. I think there might be a performance issue with recordmydesktop, since here ffmpeg manages better as well.
With recordmydesktop on the fly encoding, I'm able to capture roughly half of my screen fluidly (1920x1200, Ivy Bridge i5).

But IMO the much bigger problem is that when recording with audio, every dropped frame causes async. You have to fiddle with the fps "blindly" and add a margin to accommodate inhomogenous load, so that you don't get a random shift in the output (especially for longer videos where on the fly encoding is essential).
Ideally, recordmydesktop would offer to force-sync audio and video, either by dropping audio frames equivalently to video (thus people realise much quicker that their hardware is not up to par) or by extending holes in the video by holding the last image, aka lagging (I think preferrable, since reduction in fps is the least distracting for the viewer).

Wondering whether I should file a new bug report for the feature request, since this one here is either WONTFIX or one of the two force-sync options mentioned.

[Donjan Rodic (bryonak)]

Just realised that we're talking about the Ubuntu package, not recordmydesktop itself... I'll file a bug either on their Launchpad or SourceForge trackers.

[Phillip Thomas (phil-pgthomas)]

Bug is present in Fedora as well. This cannot be a Ubuntu issue alone.

[Phillip Thomas (phil-pgthomas)]

My apologies for the double post, however I believe more information is in order.

When using RecordMyDesktop without on-the-fly encoding the resulting video file takes far too long to save to disk, whereas using this option results in a simply unusable file altogether, coupled with the fact that this issue is present across distributions points to the software itself being faulty, not individual distributions.