Oh, and I should mention that after doing the overlays and compiling the
vid in avidemux, then passing through handbreak for some custom web-based
playing settings, the video does play correctly on the web. So whatever
this black-frame issue is, it doesn't seem to affect forward-playing the
video.
and I forgot to give my ffmpeg used to capture the video:
ffmpeg -y \
-f alsa \
-ac 2 \
-i pulse \
-f x11grab \
-r 25 \
-s 1354x768 \
-i :0.0 \
-vcodec mjpeg \
-qscale 1 \
-acodec pcm_s16le \
${1}
On Sat, Jan 28, 2012 at 11:15 AM, Richard Pickett <
[email protected]> wrote:
> Does it mean it's the original video to blame?
>>
>
> Very possible.
>
>
>> Can it be a framerate related issue?
>>
>
> Possible. Another thing I noticed just now splicing out a sample for you:
> using avidemux (because I can't figure out how to go frame-by-frame in
> cinelerra) you can start at the beginning and advance one frame at a time
> and *never* find a black frame. But if you then turn around and go back
> over the frames you just went over you'll find a black frame every 3rd or
> so frame.
>
> My very-undereducated guess would be the black frame is a non-key/i-frame,
> and avidemux is lazy and doesn't scan back through the frames to find the
> last key/i-frame and then roll forward to calculate how this frame would
> display. It just says "oh, not an i-frame, just show black".
>
> But then why cinelerra would show these blacks as it moves forward, that
> one I can't guess.
>
>
>
>>
>> If you want you can send me privately a few seconds of the problematic
>> material (using a service for attachments). I can have a look at them in
>> the weekend.
>
>
> 5M download:
>
> https://s3.amazonaws.com/fbautoresponder/video/sample.avi
>
> Thanks!
>
