Re: audio normalize

[Steven Boswell II]

On Thursday, July 4, 2019, 2:44:57 PM MDT, j...@dodin.org  
wrote: > why use an other editor when kdenlive (seems to) already have the 
tool, apart if you say the tool is broken

kdenlive doesn't have a level-compressor, and it also doesn't give you an 
accurate view of your audio waveform, in case there are other issues with your 
audio that need inspection and correction.Use the tool that's appropriate for 
the job.There's a reason that Adobe After Effects is a separate program from 
Adobe Premier.

Feel free to resist this good advice if you want to, but you're only making 
your work more difficult.We're just trying to help.

-Steven
  

Re: Devices compatibility table

[Steven Boswell II]

   On Wednesday, July 3, 2019, 4:09:47 AM MDT, Narcis Garcia 
 wrote: >Does anybody recommend a page with a list of 
video capture devices,
>being compatible with GNU/Linux?

kdenlive isn't really oriented for video capture.The mjpegtools project is more 
deeply involved with that.See their page at MJPEG Tools .
I personally use a Canopus ADVC 300 for capturing VHS videotape footage.It's 
pretty old at this point, but still does well.
-Steven


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
MJPEG Tools

Homepage for MJPEG support under Linux
 |

 |

 |



  

Re: audio normalize

[Steven Boswell II]

   On Wednesday, July 3, 2019, 2:28:42 AM MDT, j...@dodin.org  
wrote: >Can somebody point me to a "normalize" doc (the wiki is empty)?

In my opinion, non-linear video editors like kdenlive are best used to 
composite several different clips together, not perform major processing on 
them.
If you've got an audio file of someone singing, I would recommend fixing it 
first in audacity, then importing the fixed clip into kdenlive.First, you'll 
want to level-compress it, not merely normalize it.I recommend Chris' Dynamic 
Compressor, which can be found at 
https://github.com/theDanielJLewis/dynamic-compressor-for-audacity .You can put 
the compress.ny file into your Audacity plugins folder.Normal audio clips can 
use the default compress ratio of 0.5.For speech and vocals, I tend to boost 
that to 0.75 for better results.
Hope this is helpful.
-Steven


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
theDanielJLewis/dynamic-compressor-for-audacity

Chris's Dynamic Compressor plugin for Audacity. Contribute to 
theDanielJLewis/dynamic-compressor-for-audacity de...
 |

 |

 |



  

Combine project bin duplicates?

[Steven Boswell II]

So, while completing work on a new scene in a larger video, I zoomed out, and 
was surprised (read "horrified") to find that the rest of my project's scenes 
had somehow been deleted! I saved my new scene in the library, reloaded a 
backup file (thank goodness kdenlive makes those), imported the new scene from 
the library, and selected "expand clip" to hopefully make it editable again.
But this had two unexpected side effects: my project bin now had several 
duplicated references to the same source, and each of the clips of the imported 
library scene had a zero-time crop-start! It appears that all of the 
library-clip sources were imported as cut-down versions of the same source. 
Selecting "expand clip" on it again had no effect, and looking at "clip 
properties" for the duplicated references in the project bin doesn't indicate 
that the source is anything but the original full-length source. "Clean 
project" didn't resolve these duplicates, either.

So I ask...how am I supposed to import library clips so that they don't retain 
this sort of uneditable heritage? It appears the duplicate "producer" XML 
elements have different "in" and "out" attributes, all all the related "entry" 
XML elements have a zero "in" attribute.

As it stands, I'm just recreating that scene from scratch in a backup version 
of my project, which is deeply unthrilling.
I would appreciate any insights into these matters.
Steven Boswell

Zombie clips, enter/leave group?

[Steven Boswell II]

I'm using kdenlive 18.12.3 and mlt 6.12.0, as supplied by Fedora Core 29. 
Presently, I'm using kdenlive for the most complex project I've ever attempted, 
so I'm having issues I haven't had before.
Every once in a while -- and I don't know the reproduction steps -- one of my 
video clips will stop working. It still appears in the timeline, but it doesn't 
display any more, and won't export. I can't move it, and if I try to resize it, 
it disappears, and I get a message "Error resizing clip". I can reconstruct the 
clip from its original source, but it's a pain.
Also, is there any way to enter a group, so that the clips in there can be 
edited individually without having to ungroup them? I'm thinking of something 
similar to what LibreOffice Draw has with grouped shapes -- I can select a 
group, and enter it, and all other shapes are grayed out, and I can edit the 
contained shapes (or enter sub-groups). I've grouped my clips by scene, but if 
I want to edit something in an older scene, I have to move surrounding groups 
away from it, so that I can ungroup it, edit its clips, and then re-group them 
without the danger of including nearby clips I didn't intend.
Thanks for any help, and thank you very much for creating this editor. I wish I 
had time and energy outside of work to contribute programming help, but I have 
one of those more-than-full-time jobs.
Steven Boswell

[Kdenlive-devel] Reverse clips?

[Steven Boswell II]

On Sunday, February 3, 2013 4:15 AM, jb wrote:
>On Saturday 02 February 2013 17.22:37 Steven Boswell II wrote:
>>I would like to see [reverse] in the "Clip properties" dialog as a
>>setting, and thought it might be a good first project for me.
>
>that is not so simple, because when loading a clip in MLT / Kdenlive,
>you use a producer service.
>[...]
>I am not sure how easy it is to change the producer of a
>kdenlive_producer entry, will make some tests and let you know
>(probably tomorrow).

Rats, I picked a difficult one. :-)? Thanks for looking into this!
Maybe I'll have better luck writing a luma-key effect...hopefully it's a simple 
modification of the existing chroma-key effect.

Steven Boswell
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mail.kde.org/pipermail/kdenlive/attachments/20130203/4ab03745/attachment.html>

[Kdenlive-devel] Reverse clips?

[Steven Boswell II]

Digging around the Net today, I found out that reversing a clip in kdenlive 
involved first generating an .mlt file that reversed the existing clip, i.e. 
"mlt-melt -profile  framebuffer: reverse=1 -consumer 
xml:.mlt".? That worked fine, and I was able to use it in kdenlive.

I would like to see that in the "Clip properties" dialog as a setting, and 
thought it might be a good first project for me.? But I failed at the first 
step -- modifying a .kdenlive file to reverse an imported clip.? From diffing 
two .mlt files, one with a reverse and one without, the difference is a line 
that says "1" inside of a "producer" 
block.? I tried putting that line in a producer block in the .kdenlive file, 
some alternate names for "reverse" like "meta.media.reverse" and 
"meta.attr.reverse", and adding a 'reverse="1"' attribute to the 
kdenlive_producer block, but none of them had the desired effect.

Can anyone give me a hint on how to proceed?? Is this project harder than I 
think it is?

Steven Boswell
-- next part --
An HTML attachment was scrubbed...
URL: 

[Kdenlive-devel] Rendering interlaced video to HuffYUV

[Steven Boswell II]

Dan Dennedy wrote:
>I applied the patch now, but I did 2 changes:
>1) added a libavcodec version check - had to lookup both libav and ffmpeg
>2) removed the comparison of mlt's progressive property > 0

Thanks!? Glad to help!
BTW, I have an account on github (ulatekh), making it easy to mark me as the 
author for any future contributions.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Kdenlive-devel] Rendering interlaced video to HuffYUV

[Steven Boswell II]

Pardon my learning curve...it never occurred to me that interlaced video could 
be stored in one order and displayed in another order.
The enclosed patch is less erroneous than the previously-sent one.




 From: Steven Boswell II 
To: For kdenlive developers  
Sent: Saturday, January 26, 2013 7:20 PM
Subject: Re: [Kdenlive-devel] Rendering interlaced video to HuffYUV
 

The bug fix to ffmpeg I mentioned earlier, the one that fixes packing raw video 
into a .mov container, has an implication which breaks the recent fix to raw 
video handling in mlt.? Enclosed is a patch that makes mlt work with both the 
original ffmpeg as well as the patched one.

I don't know why both methods of setting the video interlacing in a stream are 
necessary, but that's a question for dedicated ffmpeg hackers.

Given my research into what works and what doesn't, you may want to consider 
changing the container type on kdenlive's HuffYUV export from avi to mov, so 
that interlacing is preserved.


Steven Boswell
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mail.kde.org/pipermail/kdenlive/attachments/20130127/5393c6a9/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: mlt-rawyuv.patch
Type: text/x-patch
Size: 857 bytes
Desc: not available
URL: 
<http://mail.kde.org/pipermail/kdenlive/attachments/20130127/5393c6a9/attachment.patch>

[Kdenlive-devel] Rendering interlaced video to HuffYUV

[Steven Boswell II]

The bug fix to ffmpeg I mentioned earlier, the one that fixes packing raw video 
into a .mov container, has an implication which breaks the recent fix to raw 
video handling in mlt.? Enclosed is a patch that makes mlt work with both the 
original ffmpeg as well as the patched one.

I don't know why both methods of setting the video interlacing in a stream are 
necessary, but that's a question for dedicated ffmpeg hackers.

Given my research into what works and what doesn't, you may want to consider 
changing the container type on kdenlive's HuffYUV export from avi to mov, so 
that interlacing is preserved.


Steven Boswell
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: mlt-rawyuv.patch
Type: text/x-patch
Size: 857 bytes
Desc: not available
URL: 

[Kdenlive-devel] Rendering interlaced video to HuffYUV

[Steven Boswell II]

I have awesome news...I was able to build a version of latest-git ffmpeg that 
co-exists with the yum-repos ffmpeg installed on my machine (using the 
--build-suffix and --progs-suffix parameters to ffmpeg's configure script, plus 
some .spec file hacking), and I built latest-git mlt on top of it (using the 
--avformat-suffix parameter to mlt's configure script), and built latest-git 
kdenlive on top of that...and so far, it's all working properly!? No more 
problems with interlaced raw video!

The patch to fix interlaced raw video in ffmpeg has been sent to ffmpeg-devel, 
but hasn't been committed yet; see 
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/158164 if you can't 
wait.? I submitted a patch to ffmpeg that improved the behavior of the 
--build-suffix parameter, but that was minutes ago; see 
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/158184 if you can't wait.

I'll let you all know if anything else comes up.
Thank you so much for all your help!

Steven Boswell
-- next part --
An HTML attachment was scrubbed...
URL: 

[Kdenlive-devel] Rendering interlaced video to HuffYUV

[Steven Boswell II]

On Friday, January 25, 2013 9:29 PM, Dan Dennedy wrote:
>On Fri, Jan 25, 2013 at 7:45 PM, Steven Boswell II wrote:
>>I imported a clip (an AVI containing a HuffYUV video, the one made
>>from an interlaced stream that's mistakenly progressive now), selected
>>"Clip properties", changed to the "Advanced" tab, check "Force field
>>order", leave
>
>You also need to change Force Scanning.

I don't see a "Force Scanning" checkbox in the "Advanced" tab of the 
"Properties" window...?? I apologize if I'm doing something dumb.

>>I posted a bug report to ffmpeg's tracker regarding the
>>loss-of-interlacing bug -- it's at
>>https://ffmpeg.org/trac/ffmpeg/ticket/2190 .? Hopefully something
>>happens.

They responded!? Their patch doesn't fix the problem yet, but at least it's 
being looked at!

My trouble with ffmpeg could be avoided if kdenlive would accept raw yuv files 
as imported clips.? Would that be hard to do?

Steven Boswell
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mail.kde.org/pipermail/kdenlive/attachments/20130126/5f9130de/attachment.html>

[Kdenlive-devel] Rendering interlaced video to HuffYUV

[Steven Boswell II]

On Friday, January 25, 2013 11:11 AM jb wrote:
>>On Fri, Jan 25, 2013 at 6:17 AM, Steven Boswell II  
>>wrote:
>>>One thing I noticed in kdenlive is the "Advanced" tab in the
>>>"Properties" window of the imported clips.? It says I can override
>>>various properties, and I tried to turn off the "progressive" flag on
>>>my imported HuffYUV clips, but it didn't seem to take.
>
>Should be better now with my last commit.

I finally built RPMs for latest git mlt & kdenlive, and installed both on my 
system.

I imported a clip (an AVI containing a HuffYUV video, the one made from an 
interlaced stream that's mistakenly progressive now), selected "Clip 
properties", changed to the "Advanced" tab, check "Force field order", leave it 
on "Bottom first", and click "Apply".? There's no change in the "Video" tab, 
even if I close the dialog and bring it up again.
Not sure what else to try.

Thanks for looking into this.

I posted a bug report to ffmpeg's tracker regarding the loss-of-interlacing bug 
-- it's at https://ffmpeg.org/trac/ffmpeg/ticket/2190 .? Hopefully something 
happens.

I have several videos I want to make in the future (some even job-related!) and 
would love to use all open-source products to do it.

Steven Boswell
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mail.kde.org/pipermail/kdenlive/attachments/20130125/45f93bbb/attachment.html>

[Kdenlive-devel] Rendering interlaced video to HuffYUV

[Steven Boswell II]

>> I'm getting the same problem with HuffYUV rendering -- my interlaced video

>> ends up progressive.
>> To be fair, "ffmpeg -i input.yuv -vcodec huffyuv output.avi" also loses my
>> interlaced flag (at least according to "ffmpeg -i output.avi -vcodec
>> rawvideo -f yuv4mpegpipe - | head -1").
>> I don't suppose this would be another quick, easy fix...?
>
>I looked into it a bit, and I am not sure what is going on.
>[...]
>If you can figure out
>ffmpeg command lines that show how to output interlaced huffyuv and
>verify it (preferably with ffprobe and not mediainfo's magic), that
>would help. Otherwise, I have something big I am working on for MLT at
>the moment and cannot give this much attention at this time.

I understand.? Thanks for looking so deeply into this!? At least you verified 
that it's not an mlt/kdenlive bug.
I'll let you know if I can get any better results out of ffmpeg.

One thing I noticed in kdenlive is the "Advanced" tab in the "Properties" 
window of the imported clips.? It says I can override various properties, and I 
tried to turn off the "progressive" flag on my imported HuffYUV clips, but it 
didn't seem to take.? However, if I hand-edit the .kdenlive file, and change 
>>progressive="1"<< to >>progressive="0" top_field_first="0"<<, then reload it 
in kdenlive, the Properties window now says that the clip is interlaced.? Is 
this a valid workaround?? And should the Properties window have let me do this 
without hand-editing the file?

Thanks for your help with this.? I hope to edit a lot of video with kdenlive.

Steven Boswell
-- next part --
An HTML attachment was scrubbed...
URL: 

[Kdenlive-devel] Rendering interlaced video to HuffYUV

[Steven Boswell II]

>>The avformat consumer sets ILME and ILDCT on the AVCodecContext flags

>>when the mlt profile/consumer is set for non-progressive output.? It
>>is not clear to me if that information is passed to the libavformat
>>yuv4mpegpipe.
>
>It also sets the interlaced and top_field_first fields of the AVFrame,
>except in the case of rawvideo!? Rawvideo output has some special
>handling.? I just committed a fix for it and verified the header field
>of yuv4mpeg output ...

Thanks once again for fixing the raw YUV output so quickly!


I'm getting the same problem with HuffYUV rendering -- my interlaced video ends 
up progressive.
To be fair, "ffmpeg -i input.yuv -vcodec huffyuv output.avi" also loses my 
interlaced flag (at least according to "ffmpeg -i output.avi -vcodec rawvideo 
-f yuv4mpegpipe - | head -1").
I don't suppose this would be another quick, easy fix...?

Steven Boswell
-- next part --
An HTML attachment was scrubbed...
URL: 

[Kdenlive-devel] Rendering to raw YUV (with fix)

[Steven Boswell II]

>It also sets the interlaced and top_field_first fields of the AVFrame,
>except in the case of rawvideo!? Rawvideo output has some special
>handling.? I just committed a fix for it and verified the header field
>of yuv4mpeg output:

Thanks for looking into this so quickly!? I applied your patch locally, and 
indeed the header is correct now!

I'm not sure why I thought video_size was necessary...I guess I went so far 
down the rabbit hole yesterday, trying to get raw YUV output to work, that I 
lost track of what was necessary.? At first, my attempts to export raw YUV 
crashed out with no error message and a zero-length output file.? But it's 
working now, without my source-code patch.

>P.S.? please be aware that if you change the vertical resolution of an
>interlaced clip in any way, it is automatically deinterlaced because
>there is no field-aware scaler.

That's OK; if I need something like that, I can always use y4mscaler externally.

At some point, I think I'll figure out kdenlive's plugin API and write some 
glue code for mjpegtools-libs, so that all our video-processing tools can be 
used inside kdenlive.? That shouldn't be hard, and would be a nice addition.

Steven Boswell
-- next part --
An HTML attachment was scrubbed...
URL: 

[Kdenlive-devel] Rendering to raw YUV (with fix)

[Steven Boswell II]

Hello!? I followed the instructions at 
http://kdenlive.org/contribution-manual/how-submit-patch -- I submitted a bug 
report, which can be found at http://www.kdenlive.org/mantis/view.php?id=2953 , 
and now I'm mailing the kdenlive-devel list.

My patch allows rendering to raw YUV.? I wanted this feature because I want to 
clean up my video clip (e.g. brightness, contrast) in kdenlive, then export it 
to raw YUV for processing in mjpegtools (where I'm one of the developers), then 
bring it back into kdenlive for editing/FX/etc.

The problem is that the exported raw-video is marked as progressive, even 
though the parameters passed to MLT say that the video is not progressive!? (My 
input video is miniDV, which is bottom-field-first interlaced.)? I know how to 
fix this in mjpegtools, but I'm looking to fix the original problem.? This may 
be an MLT bug, in which case I'll keep digging there.? But in kdenlive, the 
"top" property in ProducerAvFormat (see 
http://www.mltframework.org/bin/view/MLT/ProducerAvformat for more info) 
doesn't appear to ever be set!

Does kdenlive handle interlaced video properly?? Does it keep track of the 
difference between top-field-first and bottom-field-first, i.e. if the 
interlacing type of imported clips differ from each other?? I haven't beaten 
the other export types to death yet, but raw YUV is pretty hard to mess up, and 
it's not working right, so I thought I'd ask.

Thanks for your help with this!? I'm happy to contribute to your project, if I 
can get some direction from you.

Steven Boswell
-- next part --
An HTML attachment was scrubbed...
URL: