[Kdenlive-devel] "jerking" video - last twist in story?

[Dan Dennedy]

Did you explicitly choose not to copy kdenlive list for some reason?

On Friday 08 June 2007 19:03, Jan Uhlir wrote:
> 3  - avidemuxed_20070608_1.vob - interlaced (1) to interlaced TFF,
> (result: 314frames, 5.7 MB file) 
> 4 - avidemuxed_20070608_2.vob - interlaced (1) to interlaced BFF, (result:
> 314frames, 5.7 MB file) 
> 5 - avidemuxed_20070608_3.vob - progressive (2) to progressive,
> (result: 314 frames, 6.0 MB) 
> 6 - avidemuxed_20070608_4.vob - progressive (2) to interlaced TFF, (result:
> 314 frames, 6.0 MB) 

test 6 is rather nonsensical because the deinterlacing blended the 2 fields, 
but you already know that by now.

> ** Test results, HW DVD player + TV:
> 1 - Usual jittering, only half of the movie playable, 

the image is fully interlaced, but the mpeg2 stream lacks any field dominance 
setting, so it can not play every other field with the correct timing.

> it stops in the middle. Worse result then expected. 

It may have exceeded the video decoder buffer size. You can set this in the 
kdenlive/mlt encoding options:
video_rc_buffer_size=1835008

That value (taken from ffmpeg -target dvd) is a bit less than the max in order 
to be a bit on the conservative side of compatibility.

> 2 - surprise! seems to be OK. BUT 
> only half of the movie playable, it stops in the middle. This is the first
> video directly playable from Kdenlive on hardware DVD player + TV without
> usual jittering! 
> 3 - small hardly noticable jerks (missing frames? lower framerate?)

I am surprised this did not produce best results.

> 4 - Jittering pisture! This is the first  video from Avidemux I produced
> which jitters when played  on hardware DVD player + TV! 

Clearly, your source is TFF, but since mlt is not signalling a field 
dominance, avidemux has no way of knowing even if it had some automatic field 
swapping (unlikely). However, avidemux2 does have a filter you can manually 
apply.

> 5 - OK, just one jerk on the very beginning, best variant

Maybe all the smoothing aapplied during deinterlacing and transcoding makes 
this easier to decompress than #3. Just a guess, very hard to know.

> 6 - OK, small but noticable jerks (missing frames? lower framerate?)

again, nonsensical anyway

> ** Conclusion
>
> Tests proved that my picture jittering problem was caused by mishandling
> interlaced video during Kdenlive rendering. It treats TFF interlaced videos
> wrongly as BFF?

Well, mlt does attempt to get the field dominance using the ffmpeg api. 
However, it is possible that some order of operations is making that always 
yield top_field_first=0. However, then I have to look at what mlt does with 
that information. It is currently supposed to swap fields to make it bottom 
field first automatically, but that is not exactly consistent with your 
results. I can tell you for certainty that it does not use this information 
in the ffmpeg-based output component (consumer_avformat) to do interlaced 
coding and muxer signalling. I am putting on my mlt todo list to look into 
this as well as a way to preserve field ordering where possible (currently, 
it attempts to coerce everything to bottom field first).

> The workaround for now is to force Kdenlive/MTL renderer convert video
> (treat video as) to progressive by using flag progressive=1 in profile
> parameters.

I would like to add interlaced coding support to mlt. Will you help me test 
it? It won't require any change to kdenlive.