.MTS editing in Kdenlive

I use the proxy function in svn via sunabs PPA with Canon DSLR h264 and it works great with mjpeg 25% size proxies but audio I just copy not transcode I found stuttering audio was not a problem with the audio stream decode but the video stream also proxies can be automatic if you set them so in the project defaults

This might not be what you want to hear, but if you had an nvidia card instead of ATI... ;-P

I'm editing avchd (.mts or h.264, whatever you call it) on a single core machine with 1,5 GB of RAM, and playback is smoove, no stuttering sound, no jumpy pictures - except for the transitions between scenes, where playback stops for about half a second or so. The trick is the VDPAU driver for nvidia cards. Ok, searching in the files is still a pain, and rendering takes ages, but hey - on this cheap piece of hardware...

Does anyone know where the bottleneck typically is when searching through avchd clips or during playback of transitions? Is is the CPU, is it the memory (or swap space), is it the data rate of the disks?

Chamo

Although kdenlive will probably happily edit any ".mts" file with h264 in it, I always recommend transcoding any non-intra-formats to mjpeg first (I frames only). Most non-linear-editors work better with intra-only-codecs (although they do not actually _need_ it).

DNxHD would be a good choice, but I find it has a few drawbacks. First of all, almost no application has support for the container it's supposed to be stored in (MXF). So you should use the "fallback" quicktime (mov) container instead. Furthermore it is really restrictive in the parameters it accepts (frame rate, resolution, quality...)

As an intermediate codec I would recommend mjpeg instead (as said) because it accepts all resolutions and quality. It needs a lossless transformation to a slightly different colour space and back when encoding to h264 again, but that's no problem. The codec leaves the frame rate to the container (as it should), so no restrictions there, either. The only disadvantage (in my opinion) is that the only containers that support mjpeg AND are widely accepted with mjpeg, are avi and mov. I don't like avi, but it's more widely accepted with mjpeg in it, than mjpeg in mov. Kdenlive probably accepts both, by the way. Also mjpeg is very easy to decode and allows you to do editing of HD material in realtime, on any not "very old" hardware.

Also my experience is that you'd better have any audio/video skewing and missing audio/video frames resolved before you start editing the material. You can do that in one run transcoding to the intermediate codec, using ffmpeg with the -async and -vsync flags.

It's my conviction that preparing for editing, editing itself and final encode should be different processes, possibly using different applications and different cpu's. For editing you'd like a machine with fairly good video AND some audio, probably on your desktop, for the other two steps, you'd rather use a server with a lot of cores, no audio or video, put away in a place where it can make as much noise as it wants.

Regarding the questions of bottlenecks in playback...

The seeking time issue on MTS is in ffmpeg libs. Well, we could do a faster seek, but not cleanly (image artifacts). An unclean manner of seeking would affect the any trimming or cutting you do on the footage since the first frame of a shot that is not the first frame of the file is a seek. I will consider making it possible to get fast unclean seeking within the editor preview and enforce the clean seeking in rendering. However, I can see the support issues that will create trying to explain the difference the artifacts to people and the assurance that render will be better. :-\

Other bottlenecks include lack of SSE-optimized code and lack of parallelism. On a dual core system, you already get some parallelism because audio/video preparation is a separate thread from output, but yeah output is light. Additional parallelism was worked on within MLT for nearly all of 2010, and it was recently merged into the git master branch for the next release:
http://sourceforge.net/news/?group_id=96039&id=296606
The new parallelism is not perfect. It requires some code refactoring to remove some locks, and all access to ffmpeg libs for demuxing/decoding still must be serial.

As HD H.264 decoding compares to Windows 7, the commercial outfits making the decoders have admittedly done a good job of leveraging the CPU and GPU. As pointed out, MLT can use NVIDIA VDPAU, but there is still some improvement that can be done there under certain circumstances. However, the poor seeking performance kinda defeats the overall goal. :-\ Also, we still have not integrated VAAPI for greater GPU support, and there are not yet any GPU-based effects.

In summary, there is lots of work but not a lot of time for the few developers there are.

@alphazo

I use Proxies with h264AVC from my Canon 550D and find it excellent, proxies can be generated automatically via Project Settings for each import, there is a time delay in generating them but so would transcoding.

Matroska is a container like .avi, .mov etc so a quick remux using ffmpeg would put the original mpeg4 into a .mkv without need to transcode. I find matroska + haali media splitter good on MS Windows to bypass Quicktime but not an issue on Linux. Don't think there's much to gain it's all handled by ffmpeg anyway.

Please read the post I added a page back.