Comment 76 for bug 520941

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