Kdenlive   bug tracker Home page

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000323KdenliveRenderingpublic2008-11-09 09:242010-02-04 22:56
Reporterjmpoure 
Assigned To 
PriorityhighSeverityfeatureReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformDebianOSGNU/LinuxOS VersionSID
Product Version 
Target Version0.7.2Fixed in Version 
Summary0000323: Redesign the render dialog, more intuitive way for users to understand the difference between project and rendering profiles
DescriptionThis may not be a bug, still it may be easy to understand/or fix.

Download my footage:
http://study.bulle-immobiliere.org/img/footage-hdv-canonhv20-1080-24p.ts [^]

Create a Kdenlive project with HDV 1080 25p.

Then export to Vimeo export profile.
Size is s=1280x720.

Make a screenshot of the resulting film.
See attached file. Size is 1280x540.
There are blackborder left and right.

There is clearly a PAR or DAR export problem.
Could you help me find the right ffmpeg export settings.

Maybe we need placeholders in export to pass-on parameters to ffmpeg :
maybe aspect, borders, etc ... This problem needs some analysis.

I would like to avoid messages from simple users complaining:
hey this is not the right aspect ratio.

MORE GENERALY:

There are two kinds of export needs:

* export to Website (Vimeo, Youtube, etc) with a fixed size. The aspect ratio, border, etc .. need to be set automatically. But in an easy way to avoid hard changes on code. Maybe this can be done with placeholders. I don't know if it is MLT or Kdenlive job.

* other users only need to export to various formats. See the h264 export profile for example. In this case it would be very interesting to pass-on deinterlace parameter automatically when needed.

These are two very limited changes, still IMHO it is needed.

Kind regards,
JMP
TagsNo tags attached.
Build/Install MethodManual build from SVN
Attached Filespng file icon vimeo.png [^] (663,637 bytes) 2008-11-09 09:24
png file icon empty-list.png [^] (131,252 bytes) 2008-11-12 10:54

- Relationships
related to 0000284closed Render dialog : shloud organize by codec/bitrate AND website 
related to 0000378acknowledged Render files given a fixed final file size, along with the existing fixed bitrate ones 
related to 0000381closedadministrator audio stream should not be included in rendered video if it is muted or removed (i think) 
related to 0000383acknowledged enable changing audio codec settings seperatly 
related to 0000384acknowledged upload to the internet (upon successful render) 
related to 0000438closedddennedy No ability to get dual pass mpeg2 result file as could be done with Kino's ffmpeg_dvd_dual.sh 
related to 0000430resolvedvpinon Render to image sequence 
related to 0000508closedddennedy support rendering with libdv consumer 

-  Notes
(0000969)
madsdyd (administrator)
2008-11-09 15:09

This seems to be an valid issue.

ffplay -stat reports this:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'untitled-323.mp4':
  Duration: 00:00:07.04, start: 0.000000, bitrate: 5242 kb/s
    Stream #0.0(und): Video: mpeg4, yuv420p, 1280x720 [PAR 4:3 DAR 64:27], 25.00 tb(r)
    Stream #0.1(und): Audio: aac, 44100 Hz, stereo, s16

As jmpoure states, the DAR seems weird. Visually it looks OK, but the black borders on both sides of the movie is not needed.
(0001019)
ddennedy (developer)
2008-11-10 04:54

The problem is that the profile sets the sample aspect ratio to 4/3, but with 1280x720 you want sample aspect ratio of 1/1. Setting the consumer avformat size property does not change any aspect information. So, you were asking for a 1280x720 with SAR = 4/3 instead of 1.

There are two ways to fix it. You can set sample_aspect_num=1 and sample_aspect_den=1 as a direct response to understanding this problem. However, given any 2 of: SAR, display aspect, and resolution - one can compute the missing one. Therefore, an alternative way to fix this problem, and one that perhaps looks prettier, more understandable, and more obvious to ffmpeg command line users is to set aspect=@16/9. (The "@16/9" is an MLT-ism.)
(0001023)
jmpoure (developer)
2008-11-10 08:17

kdenlive DAR (Display aspect ratio) of the source media is 16/9.
Would it be possible to pass-on a DAR placeholder from kdenlive to MLT.

Aspect would be described as %dar.

This would allow to use ANY export profile without the need to customize it.

In a previous message, I asked that %width, %height and %dar became placeholders. This is a simple feature to implement. Yet it would allow to get rig of most export problem.

Kind regards, KMP
(0001025)
jmpoure (developer)
2008-11-10 08:20
edited on: 2008-11-10 08:21

For example, we would write:

f=mp4 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=5000k s=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1 progressive=1

Also we need a placeholder to automatically deinterlace if source media is interlaced OR keep interlacing if source media is interlaced.

(0001031)
madsdyd (administrator)
2008-11-10 13:14

svn rev 2650 contains some changes that may allow this. I am not able to test them right now. jmpoure, please test - see if it is as you wished for, and works reliably for you.
(0001033)
jmpoure (developer)
2008-11-10 15:27

Thanks a lot. This is extremely usefull.
I did some preliminary changes to export profiles.

Would you mind adding some simple deinterlacing support in Kdenlive?
We could use the %interlace placesholder (or whatever you choose).

%interlace=1
Returns: ildct=1 ilme=1. I think this should work with any kind of source file, interlaced or non-interlaced.

%interlace=0
Returns : if source profile is interlaced, returns "deinterlace=1 ildct=0 ilme=0" (transformed into ffmpeg --deinterlace). If source profils has full frames, returns "ildct=0 ilme=0".

%interlace=auto
Same interlacing as source profile. Automatic! 1 if interlaced, 0 if full frame.

There is no need for an interlaced placeholder, as ffmeg will interlace from non-interlaced or interlaced source implicitely (I guess).

This will allow me to create custom profiles in P of I formats that really work.

When this is done, I can commit the last changes to export profiles.
What do you think? Feel free to choose a much simplier solution if there is any.
(0001034)
jmpoure (developer)
2008-11-10 15:28

I am waiting for your answer to do the final work in export profiles. This could take a few hours (testing needed) but I can work on this issue tonight without delaying kdenlive release further.
(0001048)
ddennedy (developer)
2008-11-10 17:21

MLT consumer_avformat automatically sets ilme and ildct depending upon whether the output is progressive or not as determined by the project profile, which can be overridden with deinterlace= or progressive= on the consumer properties.
(0001049)
jmpoure (developer)
2008-11-10 17:36
edited on: 2008-11-10 18:01

Fine!

What if the source is HV 1080i or HV 1080p and I would like to output HV720p.
This is a very common case when you want to public deinterlaced.

Is deinterlace=1 overrident when source has progressive frames?

(0001051)
jmpoure (developer)
2008-11-10 17:59
edited on: 2008-11-10 18:01

Okay, an example:

<group name="h264" renderer="avformat" type="av">
  <profile name="h264 200k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=200k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1 progressive=1" />
  <profile name="h264 400k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=400k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1 progressive=1" />
  <profile name="h264 600k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=600k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1 progressive=1" />
  <profile name="h264 800k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=800k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1 progressive=1" />
  <profile name="h264 1000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=1000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1 progressive=1" />
  <profile name="h264 2000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=2000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1 progressive=1" />
  <profile name="h264 4000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=4000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1 progressive=1" />
  <profile name="h264 6000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=6000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1 progressive=1" />
  <profile name="h264 8000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=8000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1 progressive=1" />
  <profile name="h264 10000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=384k ar=44100 vcodec=libx264 minrate=0 b=10000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1 progressive=1" />
  <profile name="h264 12000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=384k ar=44100 vcodec=libx264 minrate=0 b=12000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1 progressive=1" />
</group>

Would it be possible to add a checkbox in Kdenlive export to choose between interlace (i) and progressives frames (p).

This would allow to write export like:

<group name="h264" renderer="avformat" type="av">
  <profile name="h264 200k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=200k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 400k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=400k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 600k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=600k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 800k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=800k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 1000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=1000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 2000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=2000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 4000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=4000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 6000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=6000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 8000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=8000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 10000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=384k ar=44100 vcodec=libx264 minrate=0 b=10000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 12000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=384k ar=44100 vcodec=libx264 minrate=0 b=12000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
</group>

* If p is checked, the export adds:
progressive=1 and deinterlace=1
deinterlace is not taken in account when source has progressive frames (MLT work).

* If i is checked, the export adds:
progressive=0
mlt does the job of adding the right ffmpeg parameters.

Is this correct? Do you like this approach?

(0001052)
jmpoure (developer)
2008-11-10 18:02
edited on: 2008-11-10 18:04

In short:
* On MLT side: we need that deinterlace=1 is not taken into account by MLT when source has progressive frames.
* On Kdenlive side : add a button that allows to choose between (p) and (i) export. In the case of (p) export, this adds progressive=1 and deinterlace=1. In the case of (i) export, it adds professive=0 to the export line.

(0001053)
ddennedy (developer)
2008-11-10 18:49

> What if the source is HV 1080i or HV 1080p and I would like to output HV720p.
> This is a very common case when you want to public deinterlaced.

MLT will automatically deinterlace the 1080i source to make it conform to the 720p profile. When using avformat to encode it, it will not set ilme or ildct.

> Is deinterlace=1 overrident when source has progressive frames?

It will not deinterlace progressive frames because it does not need to. deinterlace is an alias for progressive, where the progressive property is more proper since it describes what you want, not what to do. However, deinterlace was added as an alias for its familiarity.
(0001054)
administrator (administrator)
2008-11-10 19:01

Ok, I added a "Progressive" checkbox to the render dialog. The option is automatically checked when working with a progressive format profile, but user can uncheck it.

When checked, it adds progressive=1, when unchecked, it adds progressive=0

Let me know if it works like you want
(0001055)
ddennedy (developer)
2008-11-10 19:03

> Would it be possible to add a checkbox in Kdenlive export to choose between
> interlace (i) and progressives frames (p).

So, now you have render profiles that set resolution, display aspect ratio, sample aspect ratio indirectly, and now progressiveness. You have just reproduced the MLT "profile" features minus frame rate.

How about you not change any of these in the render settings and make the user change the kdenlive project profile? Then, that way they can preview what impact this sort of change might have on their effects before rendering. kdenlive might even be able to be enhanced to automatically convert all timing when the frame rate changes.

Let me ask a question to help you understand... what criteria do you use when setting the kdenlive project profile? If you choose it based on the majority of the source material you use in your project, you have made a bad decision. You should choose what most closely matches how you expect to output it.
(0001057)
ddennedy (developer)
2008-11-10 19:13

Your users are going to be left wondering what purpose the project profile serves. At the surface, it only seems to affect the preview. If they render to a quite different profile there is a risk some of their effects will render incorrectly.
(0001058)
madsdyd (administrator)
2008-11-10 19:13

This is important to understand. I, as a user, would expect that I should set the profile to match my source, and that I would be free to render to whatever I like. In fact, I might want to render my project to a high-resolution DVD/Blueray/Whatever, and also to something low bit rate for my personal webserver or for emailing people.

I think Kdenlive should aim at handling both of these scenarios?
(0001062)
jmpoure (developer)
2008-11-10 20:50
edited on: 2008-11-10 20:55

Okay, we are going deeply into MLT/Kdenlive concept.
Thank you for the explanations Dan.

As far as I understand, a user should be able to change profile on the fly, depending on export needs. Am I right? Whaooo! MLT is very powerfull and a unique tool.

I let developper decide what's best
and go back to tuning export parameters.

Cheers, JMP

(0001068)
jmpoure (developer)
2008-11-10 21:35
edited on: 2008-11-10 21:50

While I am updating profiles, I see a simple solution to the problem.
Let us take the example of h264 export profile. It is currently:

<group name="h264" renderer="avformat" type="av">
  <profile name="h264 200k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=200k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 400k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=400k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 600k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=600k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 800k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=800k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 1000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=1000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 2000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=2000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 4000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=4000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 6000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=6000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 8000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=8000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 10000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=384k ar=44100 vcodec=libx264 minrate=0 b=10000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
  <profile name="h264 12000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=384k ar=44100 vcodec=libx264 minrate=0 b=12000k size=%widthx%height aspect=%dar mbd=2 trell=1 mv4=1" />
</group>

We could rely on profiles to define %height, %width, %dar and progressive/interlaced. Why not present a pop-up menu with all existing profiles?

(0001069)
administrator (administrator)
2008-11-10 21:45

Yes, I think we can go like that for 0.7 and rethink this profile / rendering issue for next release.
(0001070)
jmpoure (developer)
2008-11-10 21:50
edited on: 2008-11-10 21:54

I have a simple solution.

I finish. In the export to profile option, there would be a defaut "current profile" entry. Then other entries, with all MLT profiles.

Then our h264 would become:

<group name="h264" renderer="avformat" type="av">
  <profile name="h264 200k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=200k mbd=2 trell=1 mv4=1" />
  <profile name="h264 400k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=400k mbd=2 trell=1 mv4=1" />
  <profile name="h264 600k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=600k mbd=2 trell=1 mv4=1" />
  <profile name="h264 800k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=800k mbd=2 trell=1 mv4=1" />
  <profile name="h264 1000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=1000k mbd=2 trell=1 mv4=1" />
  <profile name="h264 2000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=2000k mbd=2 trell=1 mv4=1" />
  <profile name="h264 4000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=4000k mbd=2 trell=1 mv4=1" />
  <profile name="h264 6000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=6000k mbd=2 trell=1 mv4=1" />
  <profile name="h264 8000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=128k ar=44100 vcodec=libx264 minrate=0 b=8000k mbd=2 trell=1 mv4=1" />
  <profile name="h264 10000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=384k ar=44100 vcodec=libx264 minrate=0 b=10000k mbd=2 trell=1 mv4=1" />
  <profile name="h264 12000k" extension="mp4" args="f=mp4 hq=1 acodec=libfaac ab=384k ar=44100 vcodec=libx264 minrate=0 b=12000k mbd=2 trell=1 mv4=1" />
</group>

Kdenlive would only need to add profile =)
For any customized profile, the user would need to create a profile.
So we would need to provide Web profiles (Dailymotion, etc ...)

But this would be pretty easy for a user to understand, as there would be only ONE set of profiles. What do you think ?

I am very in favour of this solution, which seems to suit MLT internals.

(0001071)
ddennedy (developer)
2008-11-10 21:53

I think your reasoning is flawed because the project should not be limited to one form of source. So, if I am planning to mix this DV, HDV, and VGA MP4, which profile shall I choose to represent the "source?"

OTOH, I fully understand your use case. In that case, I might choose to set the project profile for the high bar - DVD or Blu-Ray - and compose all of my effects in that mode. Then, I would expect a lower res output might still render at the selected, full profile but then downscale to what I requested as a final step before encoding. In fact, I could achieve that today using a lossless high res output and then use any number of tools to transcode it. At that point I could also reduce the frame rate if the bit rate is rather low, and again, using this workflow I would not have to worry about throwing off the edits in my project. So, the question is, how can we virtualize this so we do not have so many steps and use big intermediate files? Let me think about this.
(0001073)
jmpoure (developer)
2008-11-10 21:55

Okay, I stop thinking of it and let the leaders decide what solution is the most efficient. This is quite important IMHO to have one set of profiles. :)
(0001075)
ddennedy (developer)
2008-11-10 21:57

Guys, the idea of composing certain effects that use absolute spatial coordinates in one profile and rendering to a different profile is a problem just as editing in one frame rate and then rendering to a different one throws off all timing of the edits. Maybe we are better off not offering the flexibility for now. IOW, perhaps for now, render can only offer things like codec and bitrate options.
(0001078)
ddennedy (developer)
2008-11-10 22:05

> As far as I understand, a user should be able to change profile on the fly,
> depending on export needs. Am I right?

Ideally, yes, but this only works when time is expressed in units independent of frame rate, and all spatial coordinates expressed as scalable (percentage) values. Today, you can change the profile, and lets say you do not change frame rate, you might have to adjust anything that requires coordinates or dimensions such as composites. A lot of effects do take scalable or absolute values, but I think kdenlive is using the absolute ones?
(0001079)
administrator (administrator)
2008-11-10 22:09

Well, for sure if we offer profiles with different sizes, there will be problems with some effects, images or text clips. Until now, I decided to allow resizing because it can be very handy.

For example if you are working on an HDV project but want to show how it looks to your friends, it's great to be able to easily produce a middle sized mpeg that will play on any machine, even if everything is not perfect...

However, this will probably lead to users to think that Kdenlive rendering is unstable because their effects do not look like in the preview.

Not sure what to decide for now. As a temporary solution, maybe we could have 2 different tabs in the render dialog. One with quality rendering, offering to change only codec, bitrate, etc. And another tab with "experimental" rendering offering the resized renderings ?
(0001080)
jmpoure (developer)
2008-11-10 22:35
edited on: 2008-11-10 22:41

Dan, I was planning to generalize the h264 profile to other mpeg settings.

1) A user should always work in the profile which suits best his/her media. Generaly, you shoot with one or two camcorders, not more. Myself, I have two camcorders, hidden cam, plus camera. But I only work the HV 1080p profile, which is the higher resolution.

I am always happy the lower resolution stretches to higher res.
I like this feature of MLT/Kdenlive.

2) At export, you choose a profile in a pop-up menu. The default profile is the original profile. But all other profiles are selectable. These profiles provide %width, %height, interlacing/full frames, and %dar to the export parameters.

In the existing set of profiles, we would only need to add Dailymotion, Youtube and Vimeo profiles. Maybe we could use a "Only at export" checkbox in these cases.

3) You then choose the codec, bitrate, and rendering options, etc ... like it is already the case in h264 (see the example). At first, no real change is needed in the export box.

This would be my minimal choice not to beak everything.
Also, it is more simple for user to undersand.

(0001082)
madsdyd (administrator)
2008-11-10 22:42

In response to comment 1071:

OK, your point is taken, but I predict, that a large number of users will expect, based on the current presentation of project profile, and export profile, that what you hint in comment 1078 is the reality. I did, until very very recently :-).

I think the suggestion by jb in comment 1079 is good. I would be sad to have it delay the 0.7.0 release, which I really think we ought to get out the door. So, we should just make a very clear note in the docs for 0.7.0 (README? Announcement?) that rendering to something that has different resolution or framerate from the project settings is experimental. Then we should work on converting kdenlive (and maybe any missing mlt parts) to use relative coordinates. I am unsure about the implications when changing framerates - perhaps kdenlive should not allow a framerate change, or perhaps it should be solved with an approach as you lay out in the later part of your 1071 comment.

The number one thing to avoid for me is to confuse the users on this issue, and I do believe the current situation let users believe that all the rendering options will produce a result that is "equal" to the preview, using the current project profile. Also, it lets one believe that changing the project profile will "do the right thing", which it also does not (right?)

That was my 2 cent.
(0001084)
jmpoure (developer)
2008-11-10 22:59
edited on: 2008-11-10 23:01

I moved h264, mpeg4 and Xvid4 to simple settings, using placeholders.

My point of view is simple:

1) You only need to export to fixed size for web projects. Otherwize you need to original size of the higher resolution. In my case HDV. I like the idea that all media stretch to the higher resolution.

2) Users don't understand that there can be two sets of profiles, one for editing, another one for export.

3) So I useds placeholders in mpeg4, Xvid4 and h264 settings. What users need is to choose a codec and set bitrate. Simple.

4) Now, in the case that users may need a cusom size on export, they can click on customize OR they should be able to use a simple pop-up with profiles, which would only feed placeholders (%width, %height, %dar, etc ...).

Have a try to these profiles : websites, h264, mpeg4 and Xvid4 and tell me if is is simple enough.

(0001086)
ddennedy (developer)
2008-11-11 00:41

> A user should always work in the profile which suits best his/her media.

Correct, the output media. :-) They should not be so concerned with the input media. Unfortunately, they have perhaps been conditioned to think this way.

> a large number of users will expect, based on the current presentation of
> project profile, and export profile, that what you hint in comment 1078 is
> the reality.

Agreed, so removing the render profile eliminates the surprise that may result of that not being reality. At least moving it to experimental can provide a strong hint and excuse.

> I do believe the current situation let users believe that all the rendering
> options will produce a result that is "equal" to the preview

Unfortunately, while likely true, it really should not be the case. If I position something like a title way off to the right hand side of a widescreen video and render to 4:3, personally, I do not expect to predict what would happen to that title!

Currently, I am thinking about some change in MLT that would allow something along the lines of:

inigo -profile render_profile some.kdenlive profile=project_profile

some.kdenlive is like a clip in the inigo composition, and it is handled by the westley producer. Maybe I can get westley to understand a producer that is distinct from the containing project's producer.
(0001113)
jmpoure (developer)
2008-11-11 18:03

MLT was tagged for release. I think this issue wron't get fixed before next MLT release. So tagging it for Kdenlive 0.7.1.
(0001121)
jmpoure (developer)
2008-11-11 22:24

JB, I noted the addition of "experimental render" tooltip
r2679

Some remarks:

1) Could you replace "Show experimental formats" with "Show all formats"
Or use any else than "experimental".

2) My source is HDV. DV and DVD are empty. It would be better to hide empty lists, to avoid confusing users.

Cheers, JMP
(0001126)
madsdyd (administrator)
2008-11-12 00:01

in response to 1121:

1) I think experimental is good. It signals that "you should only uncheck this if you know what you are doing"

2) I agree with that, but I also think JB needs a rest.

I suggest we close this issue, and postpone further work on the render dialog to after a general overhaul/discussion of it and the way it will work in the future.
(0001128)
ddennedy (developer)
2008-11-12 00:56

> 2) My source is HDV. DV and DVD are empty.

Why? This makes no sense. You should be able to make DVD or DV from a HDV source with no problem. Just use a DV project profile and add HDV to your project.

Of course, I know what you meant, but this still demonstrates the flawed approach to understanding the project profile... project profile should be based on your final output, not your source types. You should be free to mix all different types of sources. Before you tell me that I am wrong consider that I designed the profile object and its integration into MLT - I know best how I intended it to be used. Also consider that when you start a document in just about any tool, you setup the page or canvas for how you want the result, or you adjust it shortly after you begin and then make sure it all looks correct before you print or upload or whatever.
(0001131)
madsdyd (administrator)
2008-11-12 08:56

Re 1128: I think confusion reigns here. Might simply be a matter of you, Dan, beeing the only native English speaker.

Dan: Please contrast your note 1057 and 1075 with 1128. I am confused.

I *think* some of the confusion may come from the fact that Kdenlive have two different "profiles": Real profiles, aka, the "project profiles", and the render options, aka "render profiles". I think perhaps that I (and possibly jmpoure and jb as well) have read some of your profile statements to be about "render profiles", but you have actually been talking about "project profiles". Could that be true?

I believe the reason that jb has added the "size filter" to recent svn render dialogs is because it was his (and mine, and possibly jmpoures) understanding, that rendering to a size (using a render profile) that does not match the size of the project profile would risk given unexpected results.
(0001137)
jmpoure (developer)
2008-11-12 10:44
edited on: 2008-11-12 10:49

> Of course, I know what you meant, but this still demonstrates the flawed approach to understanding the project profile... project profile should be based on your final output, not your source types.

Dave, I may understand what you mean, but this MLT internal approach.

IMHO, I plan to choose the project profile with higher resolution available (HDV), to match quality of my best source files. Of course I mix several types of media, including embedded cams, which are PAL/mepg4.

Then I may export to HDV (to burn blue-ray), mpeg2 (to burn DVDs) and h264 (for on demand TV) and divX (for direct download), eventually wbesite formats (for Vimeo preview).

So I don't expect to switch project format whenever I need to export, based on my broadcasting needs. Broadcasting happens AFTER the video editing is finished. The client says "okay" and you deliver the format he is asking for. I don't plan to say : "wait, I have to go through the editing process again".

What I plan to do is :
* Export using Kdenlive export formats. Two-pass encoding would be fine.
* Or export using raw lossless codec, then use Avidemux to preserve quality and export to several format.

Choosing a profile based on ONE export target (on-demand TV or Divx or HDV or DVD) is a deadend, unless Kdenlive is able to switch from one profile to another without hastle. If it can done, fine, this would solve all issues. But this may be more difficult than expected.

The current appoach is satisfying, but:
* I don't expect that the word "experimental" is used. Can you choose something else. Dave, you are the only native English speaker.
* Can you hide categories (DVD, DV, etc ...) when the list is empty.

(0001140)
jmpoure (developer)
2008-11-12 10:54

Attached a screenshot showing empty lists.
(0001162)
jmpoure (developer)
2008-11-12 18:04

I would prefer "Export to different resolutions (experimental)". Maybe this can be added to the 0.7.0 branch.
(0001163)
ddennedy (developer)
2008-11-12 18:26

> I *think* some of the confusion may come from the fact that Kdenlive have two
> different "profiles": Real profiles, aka, the "project profiles", and the
> render options, aka "render profiles".

I try always qualify usage of "profile" with project or render. In certain contexts like "render to... profile" implies render profile, and anything involving layout implies the project profile.

> I plan to choose the project profile with higher resolution available (HDV),
> to match quality of my best source files.

I agree that this is sound choice.

> The client says "okay" and you deliver the format he is asking for.
> I don't plan to say : "wait, I have to go through the editing process again".

I understand, and I agree that this is ideal. However, kdenlive and probably MLT is not ready for that today without using some intermediate file.

It probably sounds like I keep flip-flopping on this issue. This is because I recognize the goal, but I want to prevent giving users the wrong impression about the current state.

> "experimental"

Um, I dunno, it is probably better than the alternatives such as "risky" or "your mileage may vary" :-) Maybe "unsupported" ?
(0001770)
jmpoure (developer)
2008-12-17 22:51

Feature request for MLT.
(0001773)
ddennedy (developer)
2008-12-17 22:56

FYI, I do have in progress a new service called "producer_consumer" that will load a project much like kdenlive does a westley, but with more encapsulation. In fact, you can specify a profile for the loaded project as well as the parent project that contains it. However, initially, it will still not support changing frame rates.
(0001822)
ddennedy (developer)
2008-12-20 07:30

I have just committed this new producer_consumer. Here is the way kdenlive_render can invoke it:

$ inigo consumer:project.kdenlive profile=<project-profile> -consumer avformat:foo profile=<render-profile> ...

where properties after <render-profile> can override the render profile's properties, as usual.

Just to be clear, the results are just like rendering to a lossless file with project-profile setttings, and then encoding that using render-profile settings, plus overrides. Except, it is all virtualized, of course. That means it is entirely possible to have black completely surrounding your picture much like what can happen in broadcast TV on widescreen displays. If you place a widescreen video onto a 4:3 project, it is letterboxed. Then, if you render that letterboxed 4:3 project to a widescreen encoding, it automatically pillarboxes the 4:3 project onto the widescreen.
(0001823)
ddennedy (developer)
2008-12-20 07:32

of course, alternatively:

$ inigo -profile <render-profile> consumer:project.kdenlive profile=<project-profile> -consumer avformat:foo ...

or

$ inigo -profile <project-profile> consumer:project.kdenlive profile=<project-profile> -consumer avformat:foo ...

where the consumer properties can safely override the first, parent profile settings.
(0001845)
madsdyd (administrator)
2008-12-21 10:37

For the part of this discussion that is about the GUI, I have created this forum discussion: http://kdenlive.org/forum/please-help-us-redesign-new-render-dialogworkflow [^]
(0002067)
jmpoure (developer)
2009-01-05 14:03
edited on: 2009-01-05 14:09

Dear Dan,

This is exactly what is needed. Is there an easy way to implement this in the existing kdenlive export profile until the new export is finished.

(0002211)
madsdyd (administrator)
2009-01-25 22:32

Svn commit 2871:

Use the new MLT's producer_consumer to render to a different size than the project profile

I am not sure what we should do with this bug - some redesign have clearly been made, but is it enough to resolve this? (It clearly has been improved).
(0002212)
madsdyd (administrator)
2009-01-25 22:38

Oh, and also

2875:
Only display available codecs in rendering dialog

2927:
Updated the rendering dialog:
* add option to disable audio
* Re-organise categories
* Improved info in the "Running jobs" widget, including crash log
(0002277)
ddennedy (developer)
2009-01-28 22:14

The new dialog needs to disable the rescale checkbox for formats that do not allow an alternative size (DV, HDV, and DVD).

Also, we should add a Destination category for Portable Media Player.

- Issue History
Date Modified Username Field Change
2008-11-09 09:24 jmpoure New Issue
2008-11-09 09:24 jmpoure File Added: vimeo.png
2008-11-09 09:26 jmpoure Description Updated
2008-11-09 09:50 jmpoure Summary PAR/DAR export problem => PAR/DAR export problem - ffmpeg / MLT tweak needed
2008-11-09 09:50 jmpoure Description Updated
2008-11-09 09:54 jmpoure Description Updated
2008-11-09 09:55 jmpoure Description Updated
2008-11-09 09:56 jmpoure Description Updated
2008-11-09 10:03 jmpoure Description Updated
2008-11-09 15:09 madsdyd Note Added: 0000969
2008-11-09 15:09 madsdyd Status new => acknowledged
2008-11-10 04:54 ddennedy Note Added: 0001019
2008-11-10 08:17 jmpoure Note Added: 0001023
2008-11-10 08:20 jmpoure Note Added: 0001025
2008-11-10 08:21 jmpoure Note Edited: 0001025
2008-11-10 13:14 madsdyd Note Added: 0001031
2008-11-10 15:27 jmpoure Note Added: 0001033
2008-11-10 15:28 jmpoure Note Added: 0001034
2008-11-10 17:21 ddennedy Note Added: 0001048
2008-11-10 17:36 jmpoure Note Added: 0001049
2008-11-10 17:37 jmpoure Note Edited: 0001049
2008-11-10 17:39 jmpoure Note Edited: 0001049
2008-11-10 17:59 jmpoure Note Added: 0001051
2008-11-10 18:00 jmpoure Note Edited: 0001051
2008-11-10 18:01 jmpoure Note Edited: 0001049
2008-11-10 18:01 jmpoure Note Edited: 0001051
2008-11-10 18:02 jmpoure Note Added: 0001052
2008-11-10 18:04 jmpoure Note Edited: 0001052
2008-11-10 18:49 ddennedy Note Added: 0001053
2008-11-10 19:01 administrator Note Added: 0001054
2008-11-10 19:03 ddennedy Note Added: 0001055
2008-11-10 19:13 ddennedy Note Added: 0001057
2008-11-10 19:13 madsdyd Note Added: 0001058
2008-11-10 20:50 jmpoure Note Added: 0001062
2008-11-10 20:52 jmpoure Note Added: 0001063
2008-11-10 20:53 jmpoure Note Deleted: 0001063
2008-11-10 20:54 jmpoure Note Edited: 0001062
2008-11-10 20:55 jmpoure Note Edited: 0001062
2008-11-10 21:35 jmpoure Note Added: 0001068
2008-11-10 21:45 administrator Note Added: 0001069
2008-11-10 21:50 jmpoure Note Edited: 0001068
2008-11-10 21:50 jmpoure Note Added: 0001070
2008-11-10 21:53 ddennedy Note Added: 0001071
2008-11-10 21:54 jmpoure Note Edited: 0001070
2008-11-10 21:55 jmpoure Note Added: 0001073
2008-11-10 21:57 ddennedy Note Added: 0001075
2008-11-10 22:05 ddennedy Note Added: 0001078
2008-11-10 22:09 administrator Note Added: 0001079
2008-11-10 22:35 jmpoure Note Added: 0001080
2008-11-10 22:36 jmpoure Note Edited: 0001080
2008-11-10 22:38 jmpoure Note Edited: 0001080
2008-11-10 22:38 jmpoure Note Edited: 0001080
2008-11-10 22:39 jmpoure Note Edited: 0001080
2008-11-10 22:40 jmpoure Note Edited: 0001080
2008-11-10 22:41 jmpoure Note Edited: 0001080
2008-11-10 22:42 madsdyd Note Added: 0001082
2008-11-10 22:59 jmpoure Note Added: 0001084
2008-11-10 23:01 jmpoure Note Edited: 0001084
2008-11-11 00:41 ddennedy Note Added: 0001086
2008-11-11 18:03 jmpoure Note Added: 0001113
2008-11-11 18:03 jmpoure Target Version 0.7.0 => 0.7.1
2008-11-11 22:24 jmpoure Note Added: 0001121
2008-11-12 00:01 madsdyd Note Added: 0001126
2008-11-12 00:56 ddennedy Note Added: 0001128
2008-11-12 08:56 madsdyd Note Added: 0001131
2008-11-12 10:44 jmpoure Note Added: 0001137
2008-11-12 10:47 jmpoure Note Edited: 0001137
2008-11-12 10:49 jmpoure Note Edited: 0001137
2008-11-12 10:54 jmpoure Note Added: 0001140
2008-11-12 10:54 jmpoure File Added: empty-list.png
2008-11-12 18:04 jmpoure Note Added: 0001162
2008-11-12 18:26 ddennedy Note Added: 0001163
2008-11-17 21:12 madsdyd Summary PAR/DAR export problem - ffmpeg / MLT tweak needed => Redesign the render dialog, more intuitive way for users to understand the difference between project and rendering profiles
2008-11-20 20:52 madsdyd Relationship added related to 0000284
2008-11-20 20:52 madsdyd Relationship added related to 0000378
2008-11-21 12:08 madsdyd Relationship added related to 0000381
2008-11-21 20:27 madsdyd Relationship added related to 0000383
2008-11-21 20:27 madsdyd Relationship added related to 0000384
2008-12-08 20:44 madsdyd Relationship added related to 0000438
2008-12-17 22:51 jmpoure Note Added: 0001770
2008-12-17 22:52 jmpoure Build/Install Method => Manual build from SVN
2008-12-17 22:52 jmpoure Severity minor => feature
2008-12-17 22:52 jmpoure Target Version 0.7.1 => future version
2008-12-17 22:56 ddennedy Note Added: 0001773
2008-12-20 07:30 ddennedy Note Added: 0001822
2008-12-20 07:32 ddennedy Note Added: 0001823
2008-12-21 10:37 madsdyd Note Added: 0001845
2008-12-21 15:59 madsdyd Relationship added related to 0000430
2008-12-22 21:09 madsdyd Relationship added related to 0000508
2008-12-29 16:07 madsdyd Target Version future version => 0.7.2
2009-01-05 14:03 jmpoure Note Added: 0002067
2009-01-05 14:09 jmpoure Note Edited: 0002067
2009-01-25 22:32 madsdyd Note Added: 0002211
2009-01-25 22:38 madsdyd Note Added: 0002212
2009-01-28 22:14 ddennedy Note Added: 0002277


Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker