[Kdenlive-devel] IPB frame order and possible link to my "jerking" video?

[Jan Uhlir]

Dan Dennedy. Aren't you THAT Dan Dennedy behind such projects as Kino and 
Dvgram both I use? It's an honor to talk to such guru :)

> First of all, let me explain something about MLT and its history... I would
> not even expect to generate DVD compliant output directly from kdenlive/MLT
> at this time. MLT was written firstly and with priority given to
> *uncompressed* output. 

I was quite surprised that Kdenlive rendering is such, hmm, "straightforward".
Other projects like Cinelerra, Kino use nontrivial system of external programs connected pipes for final encoding.
I don't know about Avidemux. I it uses some external tools and pipes, it does pretty undercover.

> Avidemux has placed much emphasis on encoding and output, particularly DVD
> Video.

Agree.

Avidemux seems to be a required postprocesing tool for Kdenlive :) 
No offence please J-M, I much appreciate whole Kdenlive community and work done.

>> # of frames 320 frames (12 frames missing, interesting!)
>
> Hmm.. is kdenlive adding real_time=0 to all export consumers? It should. If
> not, or to be sure, try adding real_time=0 to the export profile. Realtime
> behaviour will drop video frames when computer can not output fast enough. It
> should only be used for monitoring scenarios (playback) and turned off for
> transcoding.

You may answered my question just when I was about to write it!
I spotted some minor jerks, hardly visible,  diffrerent kind, this where "whole picture jerks".
This few missing frames would explain it perfectly.

> B-Frames in mpeg2

IBP frame order probably IS NOT responsible for my troubles as my latest experiments indicated.
Check my next post please.

But many sources suggest that this is optimal structure: IBBPBBP...BBPI om mpeg2. Like:

"...get with a common mpeg2 (IBBPBBP) video"
http://forum.doom9.org/archive/index.php/t-19436.html
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2007-April/051149.html
and many more

On the other side mencoder complaints about libavformat and presence of B frames in source.
http://lists.mplayerhq.hu/pipermail/mencoder-users/2007-January/004911.html

[cite]
...If you wish to use libavformat muxing, you must ensure that your video  stream  does not contain B frames ..
... -lavfopts i_certify_that_my_video_stream_does_not_use_b_frames
[/cite]

I'm little bit confused.

>> Kdenlive rendered, jerking video, the same clip:
>> I(31) P(18) P(12) P(08) P(06) P(06) P(06) P(06) P(06) P(06) P(04) P(04)
>
> The "(31)" after the first frame (I) indicates quantisation, and 31 is the max
> quantisation. That explains the very poor quality at the beginning, but it
> might be a bug in consumer_avformat; I do not yet know.

I had such suspicion ;)
I currently use this "hack": 
I put black frames (12 or 15, number depending on GOP size setting) as a very first frames.
Rendered video is processed through Avidemux where I cut off these black frames.
The result is OK.

J-M - what about use this hack directly in Kdenlive? i know, it's a dirty hack, but ...for a time being?



What about GOP size? 12 (often used as Google suggests) or 15 (default Kdenlive).
But it has not

Any suggestions about ME size?

Definitely I will try:
deinterlance=1 and 0
b_frames=2
real_time=0
..and report of my results.

Thank you again.

Where you get you knowledge of these advanced liavcodec/libavformat/ffmeg params? By studying code is there a comprehensive page/doc/man describing them?

Jan