On Fri, May 27, 2011 at 9:10 PM, Brian Matherly <[email protected]> wrote: >>On Thu, May 26, 2011 at 05:48:07PM -0700, Dan Dennedy wrote: >>> On Thu, May 26, 2011 at 5:38 PM, Ian Lynagh <[email protected]> wrote: >>> > On Thu, May 26, 2011 at 11:47:49AM -0700, Dan Dennedy wrote: >>> >> >>> >> And it is not capable of interlacing/weaving a 50p input into a 50i >>> >> output. >>> > >>> > But it can do 50p -> 25i (e.g. DVD)? >>> >>> Yes, from 50p *AV file* to a 25 fps interlaced project/encoding (50i >>> means the same but refers to vertical frequency in Hz, not frames per >>> second). >> >>Ah, sorry, I think I was confused and PAL DVDs are 50i, not 25i. This >>stuff makes my head hurt! >> >>So if I understand correctly, MLT can do the conversion, but other tools >>might do it better. Another advantage of rendering as 50p with >>kdenlive/melt, and then having the option of using another tool to >>convert to DVD format, I guess! > > > Not exactly. MLT can do the conversion just fine. MLT can convert the source > frame rate to match the profile frame rate (the project profile in Kdenlive). > But MLT can not convert the profile frame rate to be different on the output > (renderer). Basically, make sure your renderer frame rate matches your > profile frame rate. > > > So, if you want to maintain your project profile as 1080p50 (which I think > you do), then after you render the output at 1080p50, your options are: > * transcode the rendered 1080p50 file to PAL DVD using another transcoding > tool > * import the rendered 1080p50 file back into Kdenlive using PAL DVD profile > as the project profile - and then render to PAL DVD. >
Thanks for helping, Brian. >>I'm still having trouble rendering, though. I'd like to make a lossless >>1080/50p profile, so I tried various things, e.g. using x264 with crf=0 >>(mentioned on http://mltframework.org/twiki/bin/view/MLT/ConsumerAvformat) FYI, these options are based on libavcodec v52. IOW, if you are using a git version of ffmpeg since mid-April (v53), then some options are different esp. for x264. >>like so: >> >> melt untitled.mp4 -profile atsc_1080p_50 -consumer >>avformat:/home/ian/kdenlive/untitled2.mp4 progress=1 f=mp4 acodec=ac3 ab=448k >>ar=48000 ac=2 vcodec=libx264 crf=0 preset=placebo no-interlaced >>profile=atsc_1080p_50 threads=1 real_time=-1 >> "preset" is a new option with libavcodec v53 (and similarly recent x264), and it seems like you might already understand this. However, what is this "no-interlaced" in the middle? It does not nothing and might disrupt processing of subsequent property setters. Also, with these new versions of x264/ffmpeg, you should not supply a MLT profile name to the "profile" property since libavcodec is using that with x264 to specify a H.264 profile like base, main, high. So, it is possible a bad value here might disrupt things. Also, I am not sure what is the correct H.264 profile to use for a lossless or near-lossless output - maybe best to leave that out. It is OK to leave the MLT profile off of the consumer since you supplied -profile. It is a good idea to add -verbose to get more informational messages from ffmpeg and x264 libs. >>but the result is definitely lossy. In fact, even if I do >> >> melt -verbose script003.sh.mlt -profile atsc_1080p_50 trellis=0 -consumer >>avformat:/home/ian/kdenlive/untitled2.mp4 trellis=0 progress=1 f=mp4 >>trellis=0 vcodec=libx264 trellis=0 >> Hmm, I am not certain that is enough info to do x264 encoding. Historically, it would not be enough, but perhaps things changed recently. >>the output includes "trellis=1", so I think I must be passing arguments >>incorrectly? >> What do you mean? where do you see that "trellis=1" ? >>Hmm, using cqp=0 looks a lot better, but still isn't lossless according >>to ffmpeg -f framemd5. > We can all use some help keeping up with ffmpeg options. > > Your probably don't REALLY want lossless because the files will be HUGE. But > you can try this if you want: > http://www.kdenlive.org/dnxhd-1920x1080-220-mbs > > Otherwise, create an H.264 renderer based on one of the existing renderers, > but use the -sameq flag. This is probably closer to what you want. Depending > on your quality criteria, H.264 at 25Mbps may be close enough to lossless for > you. It is for me. > MLT does not support the -sameq option. I think that can only really work when there is no or very little image processing or editing involved. > >>I also see that atsc_1080p_50 has colorspace 709, while dv_pal_wide has >>601. Is that going to cause me any problems? How can I tell what >>colourspace my inputs use? > > > Generally: HD=709, SD=601 (especially if captured from an analog source). > Your content is 1080p. So it should be 709. For an HD render, you want the > colorspace to be unchanged. For an SD render intended for DVD playback, you > would want the colorspace to be converted to 601 (although, I would defy you > to tell the difference by visual inspection). > > I don't know if MLT or FFMPEG perform 709 to 601 colorspace conversions when > downscaling from HD to SD. > It uses the colorspace when converting YCbCr to RGB and passes the profile colorspace to the encoder, but unfortunately libswscale (last time I checked several months ago) does not understand the colorspace option when converting from RGB to YCbCr. With that said, in processing where no RGB conversion occurs, I tried to implement colorspace normalization using libswscale, but I did not figure out a way. At first I tried to do it with a YCbCr->RGB->YCbCr despite potential performance hit, but since the requested colorspace was not working from RGB->YCbCr.... Well, at least the framework and some of the logic is in place for the next time I or someone else revisits this. -- +-DRD-+ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Mlt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mlt-devel
