openshot.bugs team mailing list archive

[Oliver Schonrock <520941@xxxxxxxxxxxxxxxxxx>]

Thanks for the ideas Andy.

I investigated some more. It turns that it does not appear to be frame rate this time....It turns out that melt and ffmpeg/mencoder do not agree about the frame count in my raw video files from the camera, ie there is some doubt about how many frames there actually are.
eg 
ffmpeg -i IMGA0009.MP4 -an -vcodec copy -f avi -y NUL 2>&1 | awk '/^frame=/{print $2}'   
=> 510
mencoder -nosound -ovc frameno -vc null -o /dev/null IMGA0009.MP4 2> /dev/null | awk '/Video stream:/{print $12}'
=> 510

melt -profile hdv_1080_30p IMGA0009.MP4 -consumer xml 2> /dev/null | awk 'BEGIN { FS = "[><]" } ; /property name="length/{print $3}'
=> 509

now this could potentially cause a problem in and of itself (given
ffmpeg does the final encode) although given melt is always smaller by 1
frame (I checked across about 150 clips) it might be OK..perhaps you
just can't use that last frame in openshot, which would be fine.

However for my workflow (see above)  the editing of the low-res files and then swapping the HD files into place, this caused an issue because the "shrinking" into "-fast" files using ffmpeg results in files for which all of ffmpeg/mencoder/melt agree on the frame count:
ffmpeg -i IMGA0009-fast.MP4 -an -vcodec copy -f avi -y NUL 2>&1 | awk '/^frame=/{print $2}'
=> 510
mencoder -nosound -ovc frameno -vc null -o /dev/null IMGA0009-fast.MP4 2> /dev/null | awk '/Video stream:/{print $12}'
=> 510
melt -profile hdv_1080_30p IMGA0009-fast.MP4 -consumer xml 2> /dev/null | awk 'BEGIN { FS = "[><]" } ; /property name="length/{print $3}'
=> 510

it's like the re-encoding by ffmpeg fixed the frame count in melt's
eyes.

For my workflow this means any clip on the timeline that uses the last
frame of the "-fast" files will break the timeline (ie cause fade
glitches) when I switch to full HD, because in melt's opinion that last
frame does not exist.

I am guessing that my camera is partially to blame for producing
"partially finished frames" and melt "rounds down" but ffmpeg and
mencoder "round up".

I haven't tested this yet, but I can probably fix my workflow, by
running all my full HD files through a "lossless copy" step in ffmpeg
before I start making the "-fast" files..then they will all agree in
frame count and switching between lowfi and HD should be fine.

I suspect that this route cause (ie melt having a different way of
"rounding" frame counts) may be significant for some of the other
posters on this bug. Perhaps some of you can run the above commands on
your files and see if you get disagreements of frame count as well?

Cheers

Oliver

-- 
You received this bug notification because you are a member of OpenShot
Bugs, which is subscribed to OpenShot Video Editor.
https://bugs.launchpad.net/bugs/520941

Title:
  Fade in/out glitches

Status in OpenShot Video Editor:
  In Progress

Bug description:
  Hi,

  I don't know if anyone else has experienced this, but now and again
  (not all the time) my fades in and out glitch at the outer end: before
  a fade in, the image or video appears momentarily (probably just for
  one frame) then disappears, and the fade starts normally. Similarly at
  the end, with the final frame flashing up full brightness.

  It also seems to some extent to happen on audio - it's like OpenShot
  realises a moment too late that it's not meant to be playing the
  audio, or that a fade is meant to be happening.

  Sometimes it doesn't happen, and sometimes it fixes itself...
  unfortunately not on a 'quick' project I've been doing this morning!

  Anyway. It's absolutely great work - I'm so impressed! Something as
  good as this, and non-linear (I can't understand what you can even do
  with linear editing!) is a joy to have!

  Ubuntu 8.04
  DEB 1.0.0

  Again - great application. I've already done some stuff I'm really
  pleased with!

  Cheers,

  Mike

To manage notifications about this bug go to:
https://bugs.launchpad.net/openshot/+bug/520941/+subscriptions