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.
