Re: jerky movements with .MTS files

On Tue, Aug 17, 2010 at 10:25 AM, Dan Dennedy <[email protected]> wrote:
> On Tue, Aug 17, 2010 at 4:29 AM, Atte Andr=E9 Jensen <[email protected]> wrot=
e:
>> 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
>

You might want to add "progressive=3D1" onto the end of that command.
Otherwise, the output will be signalled as interlaced, which it
actually would not longer be.

-- =

+-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 =