Hi to all
I need a little help from you, experts :-)

I work with hi-quality screencast captured in my recording studio on WinXP using camorama; the produced screencasts use XVID video codec, the average video bit rate used is about 350 Kb/s,the fps=25,the dimension is 1438x862, audio is wav;
Usually, after i've recorded a screencast, the only thing i do is to use VirtualDub to compress in a lossy format (mp3 320 Kb/s) the audio stream and copy the video stream (so i don't re-encode the video stream).
The video quality of the obtained screencasts is absolutely EXCELLENT (i mean crystal clear)and the weight is really small, about 300 MB for an hour of video;
Unfortunately, sometimes i've the need to put a .png "picture frame" on the screencasts so i've to use kdenlive (at home on Ubuntu) to put it on and so i'm obliged to re-encode the video-stream;
The problem is that i can't get a decent quality without the exported video becoming of huge dimensions, a lot greater than the source file;
To be precise in kdenlive i use libx264 to encode the video stream and the average bit rate i aim to obtain "almost-decent" quality is about 1300Kb/s, so the new file weight becomes about 750 MB for an hour a video!!!
...now i understand that recompress with h264 an already compressed video (XVID is a lossy format i know) worsens the quality a bit but 1300 Kb/s with libx264 to match the quality of the source at 350 Kb/s with XVID isn't a bit too much????
on the other hand if i try to impose a bit rate lower than 1300 Kb/s, for example the same of the source file 350 Kb/s, the quality is absolutely unwatchable...
This happens even if i try to use the libxvid encoder in kdenlive instead that libx264, indeed it's much worst than libx264, in weight and quality...Suggestions?

This is the self-made preset i use in kdenlive to exports my screencasts:

f=avi acodec=libmp3lame ab=320k ar=44100 pix_fmt=yuv420p vcodec=libx264 qcomp=1 qdiff=4 subq=7 qmin=1 qmax=26 s=1438x862

I've extrapolated this working preset after many attempts!!! If you try to remove from this preset the parameters "qcomp=1 qdiff=4 subq=7 qmin=1 qmax=26" and put in place only the parameter b= 1300 Kb the changed preset continuos to operate but produce an avi file without the video stream!!!In ffmpeg instead isn't necessary to declare al that parameters!! Why??? Is this a kdenlive bug??
I use version 0.7.8-2 of kdenlive and version 4:0.6.1-2 of ffmpeg.
Forgive the slowness of the topic, english isn't my native language, i'm italian :-D
Thanks and a virtual beer to those who help me! :-D

I'm not an expert. Perhaps I can still give some hints.
I would try to record screencasts uncompressed (or lossless at least). On Window$ I'm using Fraps for this. The problem with re-encoding already compressed videos might be that after the first compression you get compression artifacts, and when re-compressing it the codec tries to preserve them. This is just an idea though.

Second hint, did you use dual-pass for XviD? This might slightly improve the results.

edit: Third hint: Try WebM. I found this codec very well suitable for stills. And screencasts might be close to a still.

These parameters above are ffmpeg parameters. Rendering is done in MLT, decoding and encoding in ffmpeg.

Simon

Thanks Granjow for the reply, but Camstudio has never given me problems so i'm not searching for another program to make screencasts: here in Italy we say "Never change a winning team" :-D
About to try to record uncompressed i think there's no way to do it...i mean...my screencast, recording them compressed in XVID, weigh about 1-1.5 GB ...let's figure uncompressed!! ...I am afraid they would exceed the 4 GB...and i know that beyond the 4GB a lot of problems may arise with video files
Thanks anyway! :-)
look for other solutions :-)

You did not say the resolution and framerate of the Kdenlive project. It is not just using your 1438x862@25 source clip's attributes. Quality for a specific bitrate is highly dependent on those factors. That also means it is going to scale the video because Kdenlive does not have a 1438x862 project profile, which I bet is the main reason for the quality loss. Due to the nature of the strong lines and small text in screencasts, scaling is highly detrimental.

Thanks ddennedy! you're right! i didn't know that project settings affect the result, thanks! i tought only had effect any scaling made between original and exported video, instead "wrong" project settings dimensions cause a sort of wrong pre-scaling,right? I've made a custom project preset file with 1438x862 and the quality is like night and day compared to my previous exports, thanks!...weights are stills a little bit high than the "original" XVID compressed video...but i presume this is normal...
now i've only "to understand" what PAR and what DAR i've to use for the project...to tell the truth I have experimented with different values of the latters and got the best results by setting PAR=1 DAR=1 but i want to understand why is so...i mean, original file comes from the screencast of a 16:9...should not be 16:9, instead than 1:1 , the "correct" value from a teorethical point of view? What about the PAR?
Forgive the many questions ddennedy, but i'm newbie in the video world, i've far far far more solid basis in the audio jungle because i'm a sound engineer :-D
Thanks a lot for the patience! :-)

@DDENNEDY
After some experiments i concluded that Kdenlive,read MLT as the same also happens with Openshot that also use MLT,has almost certainly something wrong in the encoding process....
even after your advice and correct settings for the project profile re-encoded videos have very low quality for the weights...
you were right on the fact that without correct project profile settings (the same of the clip 1438x862 @25 fps) kdenlive "silently" resize the video, but the gain i've got from those corrected settings are noticeable only when i export without resize the video and vanishes if i try to resize, for example if i want the exported video to be 1280x768 ,that are values proportionally related to the original 1438x862 on the other hand...
however even in the non resized exporting with correct project profile settings (the best case) obtained quality-weight ratio is really really poor compared to ffmpeg re-encoding...

i say so because i tried to re-encode the same video using both ffmpeg and kdenlive: using the same video codec, same bitrate for the re-encoding the weights of the obtained files is the same ( as it has to be...) but the quality...uhhhh...ffmpeg is crystal clear, kdenlive compared is really really really really bad, and i'm talking of a medium bit-rate of about 1000Kb/s!! a bitrate that is considered "lossless" for the ffmpeg presets!!!
I used the programs The mono spot and Avidemux to check that the ffmpeg and kdenlive re-encoded files had the same bitrate and codec (as i had set for both) and they are definitivaly the the same...in other words with xvid codec and a bitrate of 1000Kb/s results are PERFECT with ffmpeg exported video and are really really really poor for the kdenlive exported video!!!
I did two tests comparing kdenlive and ffmpeg for a not-resized export and for a resized export (at 1280 x 768) and in both cases ffmpeg is a lot (really really a lot...) better than kdenlive...
Look for yourself...

These are PNG screenshots from the NOT-RESIZED exporting:

FFMPEG (video codec : xvid , frame size= 1438x862, AverageBitRate= 1506 Kb/s , Weight= 3.6 MB , video lenght= 20 sec)

http://www.box.net/shared/r6msbq7doc

KDENLIVE (video codec : xvid , frame size= 1438x862, AverageBitRate= 1609 Kb/s , Weight= 3.9 MB , video lenght= 20 sec)

http://www.box.net/shared/c2ko5uesj2


These are instead screenshots froom the RESIZED exporting:

FFMPEG (video codec : xvid , frame size= 1280x768, AverageBitRate= 1400 Kb/s , Weight= 3.4 MB , video lenght= 20 sec)

http://www.box.net/shared/nr30hdnn4f

KDENLIVE (video codec : xvid , frame size= 1280x768, AverageBitRate= 1299 Kb/s , Weight= 3.4 MB , video lenght= 20 sec)

http://www.box.net/shared/hfv2pqh0u4

Note how kdenlive has a greater bitrate compared to ffmpeg for the non resized version and a smaller bitrate for the resized version but regardless of this is always worse than ffmpeg in quality!! ...
also look to great great quality of the ffmpeg resized version!!..so neither the bitrate nor resizing are the problems here...there must be something wrong in MLT!

Hope this can help to discover a bug or that someone explain to me where i am wrong....

Maybe there is an unintended scaling, possibly due to a rounding error in some calculation, or unintended deinterlace because it thinks your source is interlaced (you can try force progressive = 1 in advanced clip properties). I will see if I can reproduce the problem.

Regarding your custom preset and PAR and DAR. For a screencast you almost always want PAR=1/1 since most screen resolutions are square like that. Then, for DAR you do not necessarily need to conform to 16:9, and 1438x862 is not actually 16:9 (assuming PAR=1/1); so just enter 1438/862 as your DAR. It is possible a bad setting here is a contributor to the problem.

I reproduced the quality difference. I found a bug in MLT with the selection of video codec. It was falling back to the ffmpeg mpeg4 instead of using libxvid. The reason is rather technical due to with selecting a codec by its ID versus its name using the libavcodec API. Both codecs share the same ID but have different names. A fix is going into the next release.

Well,if can help i think the previous isn't the only rendering bug, try this also:
create custom h264 presets in kdenlive by copying and pasting choosing from some of the ffmpeg libx264 presets (in the ffmpeg directory usr/share/ffmpeg )...give to the custom made kdenlive presets names that refer to the ffmpeg presets from which they come (to have a reference..)
now try to re-encode a video (preferably a screencast because differences are much more evident!) with ffmpeg and kdenlive using the same h264 preset (a randomly choosen among the ones you've created) ...try with the default ffmpeg/kdenlive preset for example...look at how different are the results!!
Ffmpeg result should look much much worse in this case, because it should produce a video with much much lower bitrate than kdenlive.
Now try with another of the copied and pasted presets...same story...kdenlive produces higher bitrate videos than ffmpeg using the same preset.
I have verified this behavior with the following presets:

libx264-default
libx264-hq

With these presets instead

libx264-lossless_slow
libx264-lossless_ultrafast

results are (more or less) comparable both in terms of weights and quality, slightly in favor of kdenlive in this case.

really strange...

...on the other hand i've finally found a preset in kdenlive that produce a really really good balance between quality and weights on screencasts: a custom preset made by copying and pasting libx264-default preset from ffmpeg.With these preset the quality is really really really good, and the weight is very low (about 300 MB for an hour of video) even if i resize.
None of the h264 presets bundled in kdenlive gave me more than just-mediocre result for similar weights.
From what i said it's clear however that if you try to re-encode with this same preset (libx264-default) using ffmpeg rather than kdenlive, the results are disgusting.
Hope this helps
Ciao!

Maybe you did not pass the vpre option correctly in Kdenlive. You did not say exactly. It should be like: vcodec=libx264 vpre=default ...
(assuming melt knows correctly how to locate your presets, otherwise a full path to the preset filename is a more sure thing)

I ran a test using ffmpeg and melt. The results are nearly the same for me in quality and size. Furthermore, x264 reports for each:

ffmpeg
------
[libx264 @ 0x24041e0]frame I:4 Avg QP:22.11 size: 49174
[libx264 @ 0x24041e0]frame P:264 Avg QP:21.78 size: 2665
[libx264 @ 0x24041e0]frame B:487 Avg QP:29.51 size: 307
[libx264 @ 0x24041e0]consecutive B-frames: 13.4% 0.0% 0.8% 85.8%
[libx264 @ 0x24041e0]mb I I16..4: 54.0% 24.4% 21.6%
[libx264 @ 0x24041e0]mb P I16..4: 2.0% 0.9% 0.4% P16..4: 4.7% 1.1% 0.6% 0.0% 0.0% skip:90.3%
[libx264 @ 0x24041e0]mb B I16..4: 0.5% 0.1% 0.0% B16..8: 3.0% 0.1% 0.0% direct: 0.1% skip:96.2% L0:32.7% L1:66.2% BI: 1.1%
[libx264 @ 0x24041e0]final ratefactor: 22.16
...
[libx264 @ 0x24041e0]kb/s:166.86



melt
----
[libx264 @ 0x1fc0910]frame I:4 Avg QP:21.94 size: 49126
[libx264 @ 0x1fc0910]frame P:264 Avg QP:21.95 size: 2668
[libx264 @ 0x1fc0910]frame B:485 Avg QP:29.78 size: 305
[libx264 @ 0x1fc0910]consecutive B-frames: 13.5% 0.3% 0.8% 85.4%
[libx264 @ 0x1fc0910]mb I I16..4: 53.9% 24.6% 21.6%
[libx264 @ 0x1fc0910]mb P I16..4: 1.7% 0.9% 0.4% P16..4: 4.6% 1.1% 0.7% 0.0% 0.0% skip:90.6%
[libx264 @ 0x1fc0910]mb B I16..4: 0.4% 0.1% 0.0% B16..8: 2.9% 0.1% 0.0% direct: 0.1% skip:96.4% L0:32.3% L1:66.5% BI: 1.2%
[libx264 @ 0x1fc0910]final ratefactor: 22.03
...
[libx264 @ 0x1fc0910]kb/s:167.17

hq=1 is fine to remove. It has not done anything in libavcodec for a long time now. I leave it in because I think it looks cute - like trying to beam positive thoughts into the process.

To do qscale with libx264, use: qmin=N qmax=N

OK, I've found the crf parameter for VBR and it is ok.

My string:
f=mp4 acodec=libfaac ab=112k ac=2 ar=48000 pix_fmt=yuv420p vcodec=libx264 threads=0 crf=25 aspect=%dar vpre=veryfast

@DDENNEDY

I think you misunderstood what i wrote :-)
i've not used the "vpre" options in a custom made preset, i said that i made a custom preset copying and pasting THE CONTENT of an ffmpeg preset file; to be even more clear, you've to go to /usr/share/ffmpeg directory, open one of the contained presets with gedit or another text editor(example, open the libx264-default.ffpreset), copy THE CONTENT of the document;
then go to kdenlive, create a custom preset named with the same name of the ffmpeg preset you chose(for our example you've to name it libx264-default), paste the copied content in it, now just add to these options the missing options needed to make it work that is: f=avi vcodec=libx264 acodec=libmp3lame ar=44100 ab=256k , save this custom made preset.Done. Now try to export with kden vs ffmpeg as i said before...is more clear now?

@Bryce451

I think with the new explanation is fairly clear how to do it...however for the lazy people :-P this is the preset i use in kdenlive for my screencasts:

f=avi vcodec=libx264 acodec=libmp3lame ar=44100 ab=256k coder=1 flags=+loop cmp=+chroma partitions=+parti8x8+parti4x4+partp8x8+partb8x8 me_method=hex subq=7 me_range=16 g=250 keyint_min=25 sc_threshold=40 i_qfactor=0.71 b_strategy=1 qcomp=0.6 qmin=10 qmax=51 qdiff=4 bf=3 refs=2 directpred=1 trellis=1 flags2=+bpyramid-mixed_refs+wpred+dct8x8+fastpskip wpredp=1 rc_lookahead=20

P.S.
to have FPS=15 add the option r=15 to the preset
Done!

@Bryce451
you're wrong about the r behaviour; if r is not set in the render profile kdenlive doesn't use the project profile rate! from my experiments if you use a clip with 25fps in a project profile with fps=15 the exported video will have a rate
of 25fps, or in other words the same of the original clip.

Hello folks.
I'm used to cut and convert 25fps DVB streams (NO HD) into XViD (avi container, original resolution) using kdenlive (both 0.7.8 and svn 0.7.9).
Recently I decided to switch to mp4 (both for quality and PS3 compatibiliy). I use the standard H.264 profiles in kdenlive.


As suggested in this thread, now I tried to use vpre setting with mlt 0.6.3.

This is my profile string:
f=mp4 acodec=libfaac ab=128k b=1200k ar=48000 pix_fmt=yuv420p vcodec=libx264 vpre=veryfast aspect=%dar
(I removed hq=1, I don't know if it is useful. pix_fmt=yuv420p: I don't know if necessary)

I have very good results and the encode speed is acceptable. For the profile presets list you can run:
ls /usr/share/ffmpeg

Remember that mlt <0.6.0 requires the full path+file name: vpre=/usr/share/ffmpeg/libx264-veryfast.ffpreset

Let me know if this instructions are useful for you also. I hope I've been exhaustive and correct :)

Can you suggest me a way for VBR encoding? I've tried to use qscale param (instead of b) with vpre but atm with no luck, final bitrate is too low. I'll keep to try.

EDIT: acodec=aac for me produces bad audio. acodec=libfaac is ok
EDIT2: mlt < 0.6.2 => 0.6.0. A user reported me it works also on 0.6.0