Re: jerky movements with .MTS files

On Tue, Aug 17, 2010 at 4:29 AM, Atte Andr=E9 Jensen <[email protected]> wrote:
> Hi
>
> I know next to nothing about video but was pleased to find that I could
> easily edit the files of my canon hf200 into a "real movie" with kino. I
> then made a DVD with mandvd, but watching the result on my 42" HD LCD tv
> was quite a disappointment, unfortunately. When there's movement in the
> video, it's quite jerly, like the movement goes a bit in the right
> direction, a tiny bit back, a bit in the right direction, a tiny bit
> back and so on. It's doesn't look like camera shake, esp since 1) the

You very well described incorrect field order in interlaced output.

> camera has image stabilizer and 2) the videos play back just great with
> the camera connected directly to the tv via hdmi.
>
> Although the result seems worse on the final dvd on the tv, there seems
> to be already traces of the problem in the .MTS.dv files made by kino
> upon import. This leads me to believe that the problem is in fact in the
> import process, handled by /usr/share/kino/scripts/import/media.sh. I

The import script makes no attempt to properly handle field order and
transcode with interlace signaling in tact. In fact, since you are
scaling down the video resolution, you do not want to mix interlace
fields during scaling interpolation.

> looked and it seems that media.sh converts the video to either 25 fps or
> 30000/1001 fps. I looked in the camera menus and the camera is set to it
> default frame rate of 50i, setting it to "pf25" (I asume this means
> non-interlaced 25 fps). A quick test suggests that setting this to
> "pf25" gets rid of the problem, but that was a really quick test, so...
>
> In any case, it doesn't help with my 400+ files already recorded on 50i.
> So, I'm looking for any advice on how to get rid of this annoying
> problem. Any thoughts or anything I should try? I could mail a
> problematic .MTS file, it that would help in tracking down the problem.

Edit media.sh. It takes one of 2 routes based on whether you have
mencoder in your path or not. If mencoder is available, then you need
to lookup mencoder options. You then need to decide whether to
deinterlace or find a field-aware scaler in mencoder (does it have
one?). If it has one, then you would also add interlaced-dct and
-motion-compensation (ildct, ilme) flags to the ffmpeg command.
However, there is still another aspect to consider: field order. There
are raw pipes used between mencoder and ffmpeg, so field order
signaling is lost. You would need to make sure it comes out of
mencoder as bottom-field-first as DV is bottom-first. If mencoder is
not available, then ffmpeg lacks many of the options you need like a
good deinterlacer, field-aware scaler, and field-order correction.

With that said, nearly all of that is automatic and built into MLT,
which is the backend to Kdenlive and OpenShot. The one thing it does
not have is a field-aware scaler. Instead, it will coerce a
deinterlace since you are changing the vertical resolution. For PAL,
the following would work:

$ melt some.mts -consumer avformat:some.dv pix_fmt=3Dyuv420p

Another thing to consider is using Avidemux or gmerlin to transcode
and process your files instead of letting import try to do the work.

> NB: I noticed that when exporting the video (at least with "YUV
> film-like") kino outputs "Stream is interlaced, bottom-field-first" in
> the terminal, dunno if this information is relevant... However using
> "YUV film-like" when exporting (to mpeg/0-DVD) doesn't remove the
> problem on the resulting dvd :-(
>
> Any input would be highly appreciated!
>
> --
> Atte
>
> http://atte.dk =A0 http://modlys.dk
>

-- =

+-DRD-+

---------------------------------------------------------------------------=
---
This SF.net email is sponsored by =


Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev =