Re: [PATCH] waveform monitor filter

Le primidi 11 nivôse, an CCXX, Mark Himsley a écrit :
> This is quite an early/raw version of a luminance waveform monitor.
> I'd like to add to it with vector-scope, RGB parade, etc.
>
> At this stage I'm just looking for some comments from you experienced
> folks whether I'm doing something crazy.
>
> I've been testing this filter with this, to overlay the waveform
> monitor on top of the original video (thanks to Nicholas for the
> fifo workaround).
>
> ffmpeg -i input.mov -vf
> "split[one][two];[two]wfm_luma,scale=256:256[wfm];[one]fifo,[wfm]overlay=0:0"
> -aspect 16:9 -vcodec dvvideo -acodec pcm_s16le -ac 2 -y output.mov
I do not really know what a waveform monitor is, I can only comment on a few
points of detail.
Sounds interesting, though. I look forward to reading the docs.
> + * Copyright (c) 2011 Mark Himsley
Too late...
By the way, happy new year to everyone.
> +typedef struct
> +{
The convention is to put the brace on the same line, I believe.

Re: [PATCH] waveform monitor filter

Mark Himsley <mark <at> mdsh.com>
2012-01-01 01:57:52 GMT

On 01/01/2012 00:24, Nicolas George wrote:
> Le primidi 11 nivôse, an CCXX, Mark Himsley a écrit :
>> This is quite an early/raw version of a luminance waveform monitor.
>> I'd like to add to it with vector-scope, RGB parade, etc.
[...]
> I do not really know what a waveform monitor is, I can only comment on a few
> points of detail.
I think the wikipedia entry will give a better description of a waveform
monitor than I can write: http://en.wikipedia.org/wiki/Waveform_monitor
(although, the image on that page is of a PAL encoded composite video
signal - not something you can see in the digital world).
[...]
>> + * Copyright (c) 2011 Mark Himsley
>
> Too late...
>
> By the way, happy new year to everyone.
It was 2011 when I posted (in the UK anyway) but I'll update that. And
write some docs.
Thanks for all the other formatting, malloc return checking, and
spelling comments.
Thanks, and Happy New Year too!
--
--

new year bugs

Michael Niedermayer <michaelni <at> gmx.at>
2012-01-01 03:05:15 GMT

Hi
Todays merge enabled the automatic cpu counting and
thus multithreading.
Anyone following gitlog probably already spoted a bunch of bugfixes
from me
But there are likely more things that need fixing.
Thus if you spot a bug try disabling threads first
These bugs arent really new, its just the threads=1 default that hid
them.
--
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato

[RFC] lavfi: automatic buffer ordering

Hi.
Mark's message yesterday on the users mailing list (
http://ffmpeg.org/pipermail/ffmpeg-user/2011-December/004045.html
) has shown that there may be actual problems when filters output frames
unasked (like split does) while the other end is not capable to deal with it
(like overlay; it is not a coincidence if it happens mostly with filters
with more than one input or output).
In this example, the filters enter an endless loop of one asking a frame on
one link and the other sending one on the other, eating all stack and heap
space.
The problem can be easily fixed by inserting a fifo filter at the adequate
place; actually, it is the whole purpose of the fifo filter. I believe it
would be better if it was done automatically.
For that, I have the following proposal, that I intend to implement, but I
would like to have some feedback before:
struct AVFilterPad {
...
unsigned flags;
};
/**
* The pad is safe with regard to asynchronous pushes.
* For output pads, that means that it will only push a buffer (start_frame
* or filter_samples) as a result of a request.
* For input pads, that means that it can accept a buffer at any time,