CamStudio *.avi source files rendered at ridiculous framerate in Blender #44397

New Issue

Paul Chudley · 2015-04-15T11:57:18+02:00

Paul Chudley commented

2015-04-15 11:57:18 +02:00

Windows XP

Blender 32 bit version 2.68a

NOTE: After searching the net, I have seen mention of video playback being too fast, but have not seen anyone describe how to cause it repeatably. But I can.

(Also, I don't have the XP system in front of me now, and may not be able to log in to this reporting system again as I forgot the password and somehow got in anyway without a password (from a password reset email link), but it won't let me change my password without the old one (which I don't have!). Maybe this is another bug - perhaps someone can put this where it should go for me, because this is my first time here and it's not going well so far.)

Blender BUG Description:
When rendering a video from multiple source files in the sequencer, some source *.avi files render at ridiculous playback speed, so that they finish well before their allotted time, followed by a black screen until the next source clip starts.

NOTE: This happens when both these conditions are met:
a) I use a *.avi with created by CamStudio screen casting.
b) The beginning of the *.avi source clip is not part of the final render in blender. (This might be because the end of another clip obscures the start of the clip, or the clip is trimmed by Blender, so that it skips some initial frames.)

I don't have a blender file to attach for you, but I set up my video editing with a new install of blender, and then basically just followed the first 12 mins or so of this tutorial: https://www.youtube.com/watch?v=te9HFQVaSUE
...except I didn't bother with his imported key configuration - I just used Blender's defaults.

To create a reliable failing *.avi file, use CamStudio. I didn't let it record audio, and I think I used the first codec on the drop down list (I think it was Cinepak Codec by Radius), with a 30fps rate.
I recorded an area 1280x720. It doesn't matter how long the video is, but most of mine were at least tens of seconds long.

You just need two files. Put one on a higher channel (eg channel 3) and put the next one on a lower channel (eg channel 2), but position the second clip to start before the first clip has ended. Set the frame extents to cover all the footage, and render it. (I used H264, 1280x720, 29.97fps, MP4, with audio codec. I also had audio *.wav files in the sequencer, created by Sound Recorder, but I suspect this is irrelevant - though I haven't tested without them.) Playback in VLC should show it has ruined the second clip, and after the first clip ends, it will play the second at hyperspeed, followed by a black screen until the end of the video.

(I even had problems with trimming the END of a clip causing the issue, although I not certain whether at least one of these actually worked, so I won't put it in the "conditions" list - but it is worth a mention.)

I didn't have nearly as many issues with videos shot on an actual camera, in *.mov format. I did experience the issue with these, but it seemed more unpredictable. I found I could not trim them if I wanted to guarantee that things worked with no issues. Some could be trimmed, some could not.

I quickly learnt not to start any video clips prior to the ending of a video clip on a higher channel, if I didn't want my time wasted by Blender. (It was reliably wasting my time if I didn't follow that rule.)

Windows XP Blender 32 bit version 2.68a NOTE: After searching the net, I have seen mention of video playback being too fast, but have not seen anyone describe how to cause it repeatably. But I can. (Also, I don't have the XP system in front of me now, and may not be able to log in to this reporting system again as I forgot the password and somehow got in anyway without a password (from a password reset email link), but it won't let me change my password without the old one (which I don't have!). Maybe this is another bug - perhaps someone can put this where it should go for me, because this is my first time here and it's not going well so far.) Blender BUG Description: When rendering a video from multiple source files in the sequencer, some source *.avi files render at ridiculous playback speed, so that they finish well before their allotted time, followed by a black screen until the next source clip starts. NOTE: This happens when both these conditions are met: a) I use a *.avi with created by CamStudio screen casting. b) The beginning of the *.avi source clip is not part of the final render in blender. (This might be because the end of another clip obscures the start of the clip, or the clip is trimmed by Blender, so that it skips some initial frames.) I don't have a blender file to attach for you, but I set up my video editing with a new install of blender, and then basically just followed the first 12 mins or so of this tutorial: https://www.youtube.com/watch?v=te9HFQVaSUE ...except I didn't bother with his imported key configuration - I just used Blender's defaults. To create a reliable failing *.avi file, use CamStudio. I didn't let it record audio, and I think I used the first codec on the drop down list (I think it was Cinepak Codec by Radius), with a 30fps rate. I recorded an area 1280x720. It doesn't matter how long the video is, but most of mine were at least tens of seconds long. You just need two files. Put one on a higher channel (eg channel 3) and put the next one on a lower channel (eg channel 2), but position the second clip to start before the first clip has ended. Set the frame extents to cover all the footage, and render it. (I used H264, 1280x720, 29.97fps, MP4, with audio codec. I also had audio *.wav files in the sequencer, created by Sound Recorder, but I suspect this is irrelevant - though I haven't tested without them.) Playback in VLC should show it has ruined the second clip, and after the first clip ends, it will play the second at hyperspeed, followed by a black screen until the end of the video. (I even had problems with trimming the END of a clip causing the issue, although I not certain whether at least one of these actually worked, so I won't put it in the "conditions" list - but it is worth a mention.) I didn't have nearly as many issues with videos shot on an actual camera, in *.mov format. I did experience the issue with these, but it seemed more unpredictable. I found I could not trim them if I wanted to guarantee that things worked with no issues. Some could be trimmed, some could not. I quickly learnt not to start any video clips prior to the ending of a video clip on a higher channel, if I didn't want my time wasted by Blender. (It was reliably wasting my time if I didn't follow that rule.)

Paul Chudley commented

2015-04-15 11:57:18 +02:00

Changed status to: 'Open'

Paul Chudley commented

2015-04-15 11:57:18 +02:00

Added subscriber: @Bluth

Aaron Carlisle commented

2015-04-15 19:27:50 +02:00

Added subscriber: @Blendify

Aaron Carlisle commented

2015-04-15 19:27:50 +02:00

Are you seriously using blender 2.68? we are half way to 2.75 now please test with blender from here non gooseberry https://builder.blender.org/download/ also please attach a .blend or a link to were we could download it and the sorce files in the case of the VSE

Paul Chudley commented

2015-04-17 08:34:48 +02:00

You are right - I made an error with the version. I checked the XP system today and I am using 2.73a.

I also tested with your 2.74, and it still has the bug.

Here is a blend file with a video file I made today on the XP system so you can see it happening. I zipped them. Blender_2.73a_VSE_BUG_Demo.zip

You are right - I made an error with the version. I checked the XP system today and I am using 2.73a. I also tested with your 2.74, and it still has the bug. Here is a blend file with a video file I made today on the XP system so you can see it happening. I zipped them. [Blender_2.73a_VSE_BUG_Demo.zip](https://archive.blender.org/developer/F163323/Blender_2.73a_VSE_BUG_Demo.zip)

Aaron Carlisle commented

2015-04-17 15:41:00 +02:00

do you have sp3 on the xp system

Paul Chudley commented

2015-04-18 11:31:59 +02:00

I am pretty sure it does. It would be fully up to date.

Paul Chudley commented

2015-04-18 12:13:27 +02:00

I am also pretty sure this bug is not system dependent. I tested it with the same blend file and video file on a Linux Mint system, (albeit using Blender 2.69) and it behaves exactly the same.

Aaron Carlisle commented

2015-04-18 18:24:32 +02:00

Will test later

Julian Eisel commented

2015-04-24 15:59:51 +02:00

Added subscribers: @MartijnBerger, @JulianEisel

Julian Eisel commented

2015-04-24 15:59:51 +02:00

I tested this some days ago but couldn't recreate something similar. @Blendify, did you test? Could also be an XP issue so maybe @MartijnBerger can have a look?

Aaron Carlisle commented

2015-04-24 16:15:12 +02:00

not yet may be later to day

Sergey Sharybin commented

2015-05-25 21:03:29 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2015-05-25 21:03:29 +02:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2015-05-25 21:03:29 +02:00

Sergey Sharybin self-assigned this 2015-05-25 21:03:29 +02:00

Sergey Sharybin commented

2015-05-25 21:03:29 +02:00

The file is just not really compatible with FFmpeg version we're using blender. You can see this by generating timecode for the video and choosing Free Run no Gaps codec. It'll cause only frames to be loaded correctly, all the rest are failing to decode.

Workaround would be to generate timecode and use Record Run one. It seems to generate proper timing. Or alternatively, re-encode the file externally to some more common interchange format with guaranteed proper header and index frames.

Surely it's possible to improve Blender by at least generating timecodes alternatively, but this is already in out TODO list and will happen outside of the bug tracker work. So thanks for the report, but archiving it now.

The file is just not really compatible with FFmpeg version we're using blender. You can see this by generating timecode for the video and choosing Free Run no Gaps codec. It'll cause only frames to be loaded correctly, all the rest are failing to decode. Workaround would be to generate timecode and use Record Run one. It seems to generate proper timing. Or alternatively, re-encode the file externally to some more common interchange format with guaranteed proper header and index frames. Surely it's possible to improve Blender by at least generating timecodes alternatively, but this is already in out TODO list and will happen outside of the bug tracker work. So thanks for the report, but archiving it now.

Sergey Sharybin referenced this issue

2023-05-19 12:00:54 +02:00

WIP: FFmpeg: Remove timecode support #108059

Richard Antalik referenced this issue

2023-05-20 02:58:59 +02:00

WIP: FFmpeg: Remove timecode support #108059

Sign in to join this conversation.