Using gtk-recordmydesktop, I took this video that doesn't have any issue at its beginning (here I'm only focusing on a few seconds from the point both links start at). gtk-recordmydesktop yields .ogv and I converted it into mp4 command like:

HandBrakeCLI -f mp4 -i ./original.ogv -o ./converted.mp4

However, in another video that incorporates the video above as a result of editing, there starts to appear a glitch, which looks like a window at the back ground on the desktop of the computer at that time.

Question-1. Is there a way to avoid this kind of glitch happens with the video file that's already recorded?

Question-2. If the answer in Q-1 is no, are there things to avoid this to happen when I'm recording video snapshot? Since I've found gtk-recordmydesktop works the best for me I prefer to sticking to it, but I also welcome other tools if any for this purpose.

This thread seems to be discussing similar issue but no solution/workaround is reached.

Using Ubuntu Quantal, handbrake-cli 0.9.8ppa1~precise1, gtk-recordmydesktop 0.3.8-4.1ubuntu1


It looks like your video-edting software is glitchy.

recordmydesktop couldn't have caused that because the video was already made, and it was fine. The glitch thus had to have happened later in your workflow. I doubt handbrake would have done that, because it's just a humble transcoder (and it seems like the glitch-free video that we saw had also been through handbrake). The glitch had to have been introduced later, most likely by the video editing software. Try looking at that.

I was wrong. See the comments below.

| improve this answer | |
  • I disagree. I've had many issues with recordmydesktop generated ogv files before, during, and after transcoding. – RobotHumans May 16 '13 at 18:19
  • So you're saying that they can include a sort of "sleeper glitch" that doesn't affect playback until changes are made? I've never heard of that, but if it's true I would recommend trying to filter the video in a way that could "knead out" such things, like coverting to a format that's too simple for hidden data to exist before converting to the target format. – Wutaz May 16 '13 at 18:39
  • I've seen it happen when transcoding something that played fine before. I'm not sure, but I think it's related to changes in bitrate between video packets inside of the ogv container or keyframing. Either way, I've seen it first-hand. I'ld recommend ffmpeg/avconv with X11grab instead, but it doesn't fix his current video. – RobotHumans May 16 '13 at 20:20
  • I just tested the program myself and I see what you mean. I also like your solution of using avconv with x11grab as the input. As for the existing broken video, since handbrake can take it without choking, perhaps the same video could be run through handbrake multiple times or to multiple formats in the hope of eventually sanitizing it. – Wutaz May 17 '13 at 0:25
  • That could work. I seem to remember bouncing it through avi first fixing it with some quality loss but less chop and artifact. – RobotHumans May 17 '13 at 0:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.