I did some testing with a BFF DV file that stresses interlace by bouncing a basketball in front of a checkerboard-like background. When I use (parity = tff ^ 1) the results are much worse! So, I am not confident to make that change. Maybe there is some additional special context required when it should be used.

Then, I located a TFF file to do some testing. I quickly discovered a bug in the ffmpeg plugin's image caching (caching is important for yadif, which needs to process previous and next frames for each frame). It was not properly propagating the TFF flag. There could be circumstances outside of yadif-deinterlace where it hits the cache. But this TFF clip is not good for testing the yadif deinterlacer.

Next, I wanted to see if the parity logic was somehow inverted. So, I manually converted the bouncing ball video into a TFF video to test yadif with parity=0 vs 1. (I did this by overriding the detected field order thereby kicking on the field order corrector, and verifying these activities occurring by adding some log messages.) The results with tff=1 & parity=0 are way better than parity=1.

I committed a change to MLT git to fix the field order signaling when returning cached images. However, I have no real way of knowing at this time if that is the problem you are seeing.

@yellow:
Try to download the file once again later. This is only a free acount with limitations. Under Windows IE won’t work by default, because of the second request after the security question. X7 blocks double requests.

Ok, now I did understand why to patch.
I should admit that I’m not a native Linux user. Since a few years I use it parallel to Windows where I’m very well. From month to month yet Linux becomes more and more weight. Actually my openSuse 11.3 is “out of the box”. Kdenlive, MLT and ffmpeg are Packman-based installations. I’m happy that a packet manager is finishing all for me. The next will be to “make” it manually.

@Dan:
I use Kdenlive without scaling. Thanks for this info about deinterlacing depending on resizing. It’s good to know.
It seems normalization works so simple, that I don’t get it! I won’t annoy you, but could you explain the used method a little bit preciser on an example?
Btw.. is this method the cause of the 1 pix high green line at the bottom of my final clips?

Ok, MLT is doing field order normalisazion into BFF. Independent of my both used DNxHD files (one created with –top 0 the other with 1), the output from MLT into ffmpeg/x264 should ever be BFF. Because of g.marco’s post, then my final clip should always looks bad. But it isn’t! (See my first posts, especialy #6). How is this possible?

Dan, at the moment I cannot help you with YADIF’s input flags, my first challenge is to fix the x264 lib. Tonight I can spend a lot of time for this. The first I will upload a part of my final ill clip. You can verify if we all are talking about the same problem.

I did not understand the coherence of YADIF’s input flags with my field order problem? I assume that deinterlacing is disabled in my test rows, because I did no rescaling. The bug you found in the image cache could be a sign, if the cache is also used without active YADIF! I also assume that there could be a little bit contingency! My first experiments prior to my first posts with other clips are partial showing contrarian results? Unfortunately I did no notes about the used methods/parameters. Because of that be aware of the necessary of my tip to include -top -1 into the transcoding files.

lxvidcut, I went into a lot of detail making notes while I was analyzing and testing. It does look x264 or its integration could be the problem. I found that playing in VLC with the Bob deinterlace mode is a good way to perceive field order problems. However, in a straight transcode scenario (TFF source -> no scaling/deinterlace -> MP4), I could not reproduce a problem with H.264 output here using ffmpeg 0.6 and x264 build 85.

Re: "could you explain the used method a little bit preciser on an example?"

// Get the input image, width and height
int size = owidth * oheight * bpp;
int8_t *ptr = image + owidth * bpp;
memmove( ptr, image, size - owidth * bpp );

Re: "is this method the cause of the 1 pix high green line at the bottom of my final clips?"

No

Now I did my tests once again and I've created an archive file with all in it.

http://x7.to/vai0rc
MD5SUM
6e7953d509cf775cea6af8cd8849579d gardentestclip.tar.gz
approx 324 MB

In it you'll find a text file which describes my steps, used versions and so on.
There is also included: The source m2ts file, both DNxHD proxy files, both final clips and the used kdenlive project files.
Yes, to bob it is a good method to detect field order trouble.

Btw, take notice of the "green line" in my proxy files. The final clips didn't show the line.

While I've checked the versions with zypper, I found out that i got no auto updates from packman. So MLT and libx264 are a little bit outdated at the moment. The next step is to fix it.

Last night i spend a lot of time to learn how to compile myself and avoid conflicts with the packet manager. Next I will study a little bit about git and svn.

Update: Identically results with all current packman binaries.
Btw, the green line is also present in my source clip. It depends on the used player if you see it from not till heavy (Xine, VLC, Kaffeine)

I just some testing and analysis of your files. Both t0.mkv and t1.mkv both indicate TFF, and that should not be the case since MLT is BFF only. When I render your original_t1.m2ts.mov to mpeg4 instead of x264, then the result correctly shows BFF. I am determining the _indicated_ field order by adding a printf in MLT based on the info in the libavcodec api after decoding (when it is reliable to get it). Indicating TFF when it is not is obviously going to look wrong, and it looks like g.marco's info was spot on.

The problem with patching ffmpeg is that it looks like this flag must be passed to x264 on initialization, but ffmpeg does not know until encoding a frame because it has top_field_first as an attribute on the frame.

like in other encodings in ffmpeg/libavocdec the top_field_first must be set during frame encoding.

static int X264_frame would be the right place (since per definiton, every frame could have a own field order)

patch (since top_field_first ist negated in ffmpeg i set the ! ):

--- ffmpeg-0.6/libavcodec/libx264.c 2010-04-19 23:20:20.000000000 +0200
+++ ffmpeg-0.6-new/libavcodec/libx264.c 2010-09-04 17:28:38.000000000 +0200
@@ -100,6 +100,8 @@

x4->pic.i_pts = frame->pts;
x4->pic.i_type = X264_TYPE_AUTO;
+
+ x4->params.b_tff = !frame->top_field_first;
}

if (x264_encoder_encode(x4->enc, &nal, &nnal, frame? &x4->pic: NULL, &pic_out) < 0)

i think this would be an solution, that work then for every type of field order.

g.marco, did you test that? The reason I did not think that will work is because no other x264 params are set in X264_frame(); params is only used in X264_init().

after many search and test i found:

the param b_tff can not be set with a function later.
but the instance x4 hat the param values for the frames.
set

x4->params.b_tff = !frame->top_field_first;

should work. but with some debug i found, that frame_top_field_first ist every time "1" no matter what is changed in mlt (i changed top_field_first for the producer and for the avformat consumer). The effect was: ffmpeg will get alway top_field_first as "1".

so i could not the further if this change in ffmpeg will work.

@dan
is changing the top_field_first value ov consumer the right way to set this ?

--edit:
setting the param during encode can be don with setting x4->pic.param for a frame.
but change b_tff to !top_field_first or top_field_first will no set the field flag.
it will only make a difference during encoding teh interlaced frame. must this be set to the header only, or both ?
if (frame) {
for (i = 0; i < 3; i++) {
x4->pic.img.plane[i] = frame->data[i];
x4->pic.img.i_stride[i] = frame->linesize[i];
}

x4->pic.i_pts = frame->pts;
x4->pic.i_type = X264_TYPE_AUTO;

if (x4->params.b_tff == frame->top_field_first) {
x4->params.b_tff = !frame->top_field_first;
}
}

x4->pic.param=&x4->params;

consumer_avformat.c: sets frame->top_field_first:

1354: output->top_field_first = mlt_properties_get_int( frame_properties, "top_field_first" );

I have no idea how you get that frame property to be 1. It is not supposed to be possible at this time, and some quick testing shows it always 0 here. Furthermore, we have seen that value respected in mpeg4 and mpeg2 output. So, I do not know how that gets set 1 by the time libavcodec/libx264 gets it.

after search during the code i found:
1. x264 does not allow to change the field order after init.
2. ffmpeg cannot ( because of 1.) change the field order

patching these two libs will let it work.
tested with tff video (that will be bff after melt usage) and it play perfect.

I was successful! It’s now possible for me to patch and build my own ffmpeg. Now from day to day my linux skills will get enhanced.

I know that this thread is not the correct place for building questions, but could you please check or comment my method, if I did all correct?

Install basic dev packages like gcc, make… (via meta package)
Call installed ffmpeg and write down the printout of ffmpeg’s build options (Packman build). Uninstall ffmpeg with cleanup, so that ffmpeg’s own libs like avcodecs will also uninstall.
Download ffmpeg sources from daily svn snapshot and extract to ~/src/ffmpe….
Which sources do you use?
Call ./configure script with all options from the packman build.
Install missing stuff to build like yasm over packet manager.
Install all missing devel packages like x264 over packetmanager.
make
sudo make install
save make install output to a file so that in future I’ll be able to recunstruct the modifications on my system. Is there an easy method available to build my own rpm and what should I follow to avoid trouble I future? External shared codec libs like libx264 are controlled by my packetmanager, ffmpeg from now on not.

The next step is to repat this on my productive system with patches.

Can we betoken this about we discuss here as a Bug that should be reported to the ffmpeg and/or x264 developpers? I’ve no idea about the usual way.
Dan, are you connected with them?

Btw… first of all many thanks for helping me!

yes the way for ffmpeg seems ok, if you want to have a patched ffmpeg on your system.
for x264 you need to do the same, but with latest x264 the .so version may be change, so all your program/libs that are linked against the "old" x264 are broken.

i wrote to the x264 list with that patch, if this is commited i'll write to ffmpeg to get the change there too.

if you don't want to change x264 too, simple but the x4->params.b_tff=0 to the init method in ffmpeg (but you can't encode tff video then anymore)

The short static fix is good enough at first.
On my productive sytem I've trouble with the dependencies.
I've started a new thread there:

http://www.kdenlive.org/forum/how-proceed-after-ffmpeg-patch