Hi everybody,

i am new to kdenlive and i will furthermore use it in future in my workflow.
After i completed my first test project i noticed after a while that there is something wrong with my final clip.
If there is heavy motion, the video begins "pumping/pulsing". If i set the deinterlace filter to a simpler method like "Linear" e.g. in VLC so i can see the "pulsing" very extreme. It seems that bottom- and topfields are interchanged? Better filters are coating the problem (e.g. Yadif).

My source is a h264 1080i50 m2ts file from Panasonic SD707 (Europe).
part of mediainfo -f output:
Frame rate : 25.000
Frame rate : 25.000 fps
Frame count : 993
Scan type : Interlaced
Scan order : TFF
Scan order : Top Field First
Interlacement : TFF
Interlacement : Top Field First

If i watch this file direct in VLC, there is no problem.

For a better performance, i do a transcode to DNxHD 1080i50 185MBit (from the presets).

If i watch the resulting .mov file in VLC, i can see the same problem still prior to the kdenlive workflow. I guess something goes wrong by the transcode step.

Part of mediainfo -f output from the DNxHD .mov file:
Frame rate mode : CFR
Frame rate mode : Constant
Frame rate : 25.000
Frame rate : 25.000 fps
Frame count : 994

The output shows nothing about scan type or order.
I'm sure it makes no sense to go ahead with this material.

Any idea?

Greetings from Munich,
Christian

System-Info: OpenSuse 11.3 64Bit. kdenlive 0.7.7.1 (all from packman repo...)

Hi once again,

I found a solution. If I add "-top 1" to the ffmpeg options, the video in the .mov file is now smooth.
Also "-top -1" works fine! It enables field order auto detection. "-top 0" produces the same bad output.

Without a parameter set it seems ffmpeg uses fix the bottom field first?

Furthermore I'm irritated by the mediainfo output. It says Constant Frames by 25 fps.
If I count each independent frame in VLC with activated linear deinterlacer, there are 50 frames present.
Now i think the .mov file is ok to go ahead with kdenlive.

Does anyone know about the mediainfo output from mov files?
Won't it be a good thing to add the "-top -1" parameter to all interlaced transcode profiles in the next kdenlive version?

Christian

Now there is the next problem! If I render a project with the fixed .mov files from my last post, the resulting H264 .mp4 file has already the interchanged field order!

I've no idea if it's possible to alter something in the render profile, so that the fields are interpreted correctly? In some other post's I've noticed that's not easy to change the field order because some kdenlive filters and transitions depends on a fix order?

Please help!

Is there an other way to transform my files so that I'll get no trouble with the fields?
I can't believe that I'm the first user having such problems or do I have a general understanding problem here?

Christian

Can't find much info on the 707 only the 700. But did you shoot in interlaced mode or progressive? And at 25 or 50 fps. Putting aside what mediainfo says.

For example I have a Canon HV30 and 550D. The HV30 shoots progressive but in two interlaced streams, called psf25. Progressive Segmented Frames, yet mediainfo and such suggest it's interlaced because of the 'i' container those two duplicate streams are in. Maybe your video is progressive?

Trying to deinterlace progressive video will cause problems, so would putting a progressive shot in a interlaced kdenlive project I'd imagine.

Hi yello,

these camcorders are all the same family. The 707 is without internal memory and HDD. You can only record to a SD Card. The 707 is the European(German) Model with 1080i50. The cam has no 1080i60 mode. You can use the camcorder also to shoot 1080p50, but this an other story and with 1080p50 I've no problems with kdenlive, mlt, ffmpeg. It works, but you need much more HDD space and CPU power.

I'am sure that my material is in 1080i Mode. Panasonic is warning you with a checkbox if you are leaving the AVCHD Standard.
How can I check, if my .m2ts Container with the H264 Stream is progressive but segmented? Is there an other tool like mediainfo?
If I play the sources with vlc with no deinterlacer, I can count 25 pictures per second and every picture has the line artifacts from the halframes. If I play with deinterlacer (Linear), I count 50 clear and differnt pictures per second. That indicates to me, that the source is realy interlaced.

Meanwhile i found out, that rendering to XVid4, Theora and MPEG4 works fine! Only H264 is not correct, but I need it for blu ray.

By the way... where are the rendering profile options documented? I haven't found something in the web.

Christian

Ok, so maybe it's a problem with the h264 encoding profile in kdenlive for an interlaced project?

re encoding profiles, I'm new to kdenlive and don't have it in front of me, so I can't really help you. :-(

After a lot renderings I cleaned up all and I've started a new series of experiments to avoid mistakes and confusion.

I have now 4 independent kdenlive projects. All with 1080i 25fps timeline. Each project has own new DNxHD .mov Files.
1st project mov's transcoded without -top parameter
2nd with -top 0 (BFF)
3rd with -top 1 (TFF)
4th with -top -1 (AUTO)
With each project I rendered first to h264 .mp4 and then to MPEG2 .mpg .

As a new result I can say that if the .mov has a correct field order, the .mp4 is wrong and the .mpg is correct.
(tested with 1st and 3rd project)

If the .mov has a wrong field order, the .mp4 is now correct and the .mpg's fields are now interchanged!
(tested with 2nd project)

Then i've found this in the ffmpeg doc:
`-ilme'
Force interlacing support in encoder (MPEG-2 and MPEG-4 only). Use this option if your input file is interlaced and you want to keep the interlaced format for minimum losses...

This parameter is used in the transcoding job to DNxHD, but it seems only MPEG2 and 4 are supported? Could this be a cause for the problems?

I don't know if this parameter is also used by the rendering job. I set the pull down box "Scanning" to "Auto" in all jobs.

This is rather confusing to follow and be able to comment on. It seems as though you want interlaced output for whatever reason. OK. MLT does automatic field order detection and normalization (when not progressive profile/output) into bottom-field-first due to some DV and SDI lineage for the original sponsor of the project and, as a result, because some filters do field-based rendering with that assumption.

I can not explain why the MP4 and MPEG-2 outputs have opposite field orders. That is surprising. Is that because only MPEG-2 format has a flag for field order? (I need to look that up.)
MLT automatically adds the ilme and idct libavcodec flags when your profile/output is not progressive.

So, it seems that Kdenlive's DNxHD transcode profiles need revision to add '-top -1'.
Contrary to the docs, I checked the code to see if DNxHD supports interlaced prior to adding those transcode profiles, and it does.
Already I have somewhat high on the MLT ToDo list a top-field-first output (but this inconsistent result with MP4 and MPEG-2 makes me concerned that it will help much).
Finally, Scanning = Auto means to use what the Project setting indicates. The stuff in the Render dialog for scanning and resolution overrides what you have in the Project settings in case you need that for certain outputs.

Hi Dan,

thanks for your answer. Yes, my prefered output should be interlaced, because the source is 50i and the final product is Blu-ray and DVD. The common specified format for these both final discs in highest resolution is only 50i. That's the reason why I avoid progressive, 25-24 fps conversions and so on. For my opinion, that's a good way for 50i sources and if I would retain the motion resulution. The standard output shoult not be suitable for PC and YouTube.

I think, there is somewhere a bug in the workflow chain? I don't know where the information about the field order is stored? Is it the codec(video) stream or the container? Are there some codecs/containers with a fixed order?

In the next days I can upload a small 50i file from my cam, so that you be able to recunstruct it if you want.

In some other posts from you and in your to do list I've noticed the feature request about the TFF in/output. You are right, that it will not help with the inconsistent result, but it's easier to change somewhere a parameter as doing the DNxHD transcode job twice! (top1 for DVD and top0 for Blu-ray) :)
But I'm sure: All codecs/containers should have the same behavior...

Christian

I had the same problems, interlaced input can be uses very well and all seems fine.
encoding to mpeg4/mpeg2 works also fine.


but encoding to x264 will always fail if you have top field first.
i made a patch for ffmpeg, to set this to TFF. i did not find a place, to take this automatic but it solves first the problems for TFF video.

in libavcodec/libx264.c put after

x4->params.b_interlaced = avctx->flags & CODEC_FLAG_INTERLACED_DCT;

this line (tff is true, but must be set to 0, maybe field order changed in mlt ??? )
x4->params.b_tff =0;

then encoded x264 video play correct (interlaced and field order ) and with 50 fps (very clean picture)

Hi together,

here is the small clip (with a low 10Mbit quality) directly out of my cam, which I promised in my last post. Sorry for the delay.

http://x7.to/ecfdf7

@g.marco:
Thanks for your post. By the way… To patch something in the sources and then compiling my “own” ffmpeg will be a great challenge for me. But I will try it out!
Isn’t there another way to solve this? Can I insert an option the rendering profile if the codec is x264 to control this from outside? What’s about the dependency of MLT’s BFF order?
For me it’s not right clearly what happens while kdenlive is rendering. How works kdenlive, MLT, ffmpeg together in detail? Especially MLT and ffmpeg? I din’t understand why it’s necessary to patch there in x264? If I compare this to the little and big endian coding of 16 Bit wave sound, every player/converter knows about the order controled by flag!

In Dan’s last post he has written “MLT does automatic field order detection and normalization … into bottom-field-first”. How does normalization work? For my opinon it’s only possible to flip the field order flag so that the fields are used in correct order inside the frame (detection by video analysis) if it was set wrong. Every i50 field has it’s own real position on a timeline. If I would change to bottom first, so I cannot simply change the order inside the frame. The result will be the “jumpy” motion.
I suppose normalization is working as follwos:
Frame 1 TF -> discard it
Frame 1 BF -> New Frame 1 BF
Frame 2 TF -> New Frame 1 TF
Frame 2 BF -> New Frame 2 BF and so on…. (Move the frame boundaries one field to the right, the final stream is one frame shorter)
Or will MLT do a high quality deinterlace to 50p and then an export from this into 50i but with BFF? (But this isn’t lossless)

I hope MLT/ffmpeg is setting the “flags” corrrect independent of the used method so that the reciever of the stream knows about the facts? But I’ve no idea about the internas of MLT and ffmpeg. What will happen if MLT is melting two interlaced streams with an opposite fieldorder together (e.g. picture in picture or while a transition)?

The next days I will play ouround with ffmpeg outside of kdenlive/MLT with interlaced material, h264 and MPEG codecs to see, if there are the same problems?

Christian

Reached download limit. :-(

Re: How works kdenlive, MLT, ffmpeg together in detail? Especially MLT and ffmpeg?

You have to read the sources; it's very complicated.

Re: How does (field order) normalization work?

Simple: if input field order and requested field order are different, move the image up or down by one line since the fields are stored together in one image. The only loss is one line of resolution. I know this works not only in theory but also because I have used MLT with SDI output and analog converter connected to an analog monitor - both NTSC and PAL. I have directly seen the ill result of incorrect field order as well as the positive result of a simple line shift. Meanwhile, MLT does use the top_field_first flag from libavcodec (there is an override not yet exposed in kdenlive). It uses it both on input and sets it when encoding (should always be to zero now due to BFF-only). But of course, it is possible that a regression was introduced.

Also, if you do anything that must scale the image in the vertical direction, MLT will automatically deinterlace because it does not have a field-aware scaler. So, a 1080i source output to DVD will cause a deinterlace before any attempt at field-order normalization. Then, the deinterlace sets the frame scanning attribute to progressive thereby preventing field-order normalization. However, I am seeing that the YADIF deinterlacer takes as inputs both a parity and a top-field-first parameter. I do not recall what parity is for, but it is related to field order, and it always set 0 currently. Hmmm, that could be a problem. Reviewing the Avisynth plugin source, that should be (tff ^ 1).
Are you causing any scaling? Are you building MLT yourself such that you can test a change?

@lxvidcut

I search also long for this option, to put this from outside to libx264.
since this option is relative new in libx264, it must be set with the code from ffmpeg (libx264.c). But as you see no line of code will set this value.

The default setting is b_tff=1. when mlt converts tff to bff (which is not a problem, if known) libx264 will render this as b_tff=1 (with the stucking video)
if ffmpeg has a option for this, is could be set from kdenlive direct. But until then there is no way for x624 files to set this (unless you patch this from hand).

mlt/ffmpeg have no problems setting this in other formats (where it works correct).

I wrote:
> However, I am seeing that the YADIF deinterlacer takes as inputs both
> a parity and a top-field-first parameter. I do not recall what parity
> is for, but it is related to field order, and it always set 0 currently.
> Hmmm, that could be a problem. Reviewing the Avisynth plugin source,
> that should be (tff ^ 1).

I just realized that for lxvidcut's clip, which is tff, that the parity parameter would evaluate to 0. So, this would not be a source of the problem.