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

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

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

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel <at> ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [PATCH]Support encoding gray8a in pam

Michael Niedermayer <michaelni <at> gmx.at> writes:

> > Attached patch allows encoding gray8a in pam.
> > Decoding currently unsupported.
> 
> if it has been tested it should be ok

Patch applied.

Carl Eugen

[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,

Re: [PATCH] y41p encoder and decoder

On 12/31/11, Carl Eugen Hoyos <cehoyos <at> ag.or.at> wrote:
> Paul B Mahol <onemda <at> gmail.com> writes:
>
>> y41p is a packed 12-bit 4:1:1 YUV format used by Brooktree.
>
> (Fixes issue 1123 / ticket 102)
> Just two nits:
>
>> +    avctx->pix_fmt             = PIX_FMT_YUV411P;
>
>> +    avctx->bits_per_raw_sample = 12;
>
> Isn't 12 the default anyway?
>
> [...]
>
>> +    .long_name    = NULL_IF_CONFIG_SMALL("Uncompressed YUV 4:1:1
>> 12-bit"),
>
> Imo, this should be "Uncompressed packed YUV 4:1:1"
> (But please feel free to ignore)
>
> Is encoding odd widths allowed?

Mplayer with bt411 driver crashes when trying to play Y41P muxed in
avi with ffmpeg. (Even if I use -vcodec copy).

Another issue is that frame(for the only sample we have) is apparently
vertically flipped, this is related to
http://roundup.libav.org/issue2395. (Will try mentioned hack).

Re: [PATCH] y41p encoder and decoder

On Sun, Jan 01, 2012 at 11:28:16AM +0000, Paul B Mahol wrote:
> On 12/31/11, Carl Eugen Hoyos <cehoyos <at> ag.or.at> wrote:
> > Paul B Mahol <onemda <at> gmail.com> writes:
> >
> >> y41p is a packed 12-bit 4:1:1 YUV format used by Brooktree.
> >
> > (Fixes issue 1123 / ticket 102)
> > Just two nits:
> >
> >> +    avctx->pix_fmt             = PIX_FMT_YUV411P;
> >
> >> +    avctx->bits_per_raw_sample = 12;
> >
> > Isn't 12 the default anyway?
> >
> > [...]
> >
> >> +    .long_name    = NULL_IF_CONFIG_SMALL("Uncompressed YUV 4:1:1
> >> 12-bit"),
> >
> > Imo, this should be "Uncompressed packed YUV 4:1:1"
> > (But please feel free to ignore)
> >
> > Is encoding odd widths allowed?
> 
> Mplayer with bt411 driver crashes when trying to play Y41P muxed in
> avi with ffmpeg. (Even if I use -vcodec copy).
> 
> Another issue is that frame(for the only sample we have) is apparently
> vertically flipped, this is related to

Re: [PATCH] y41p encoder and decoder

On 1/1/12, Michael Niedermayer <michaelni <at> gmx.at> wrote:
> On Sun, Jan 01, 2012 at 11:28:16AM +0000, Paul B Mahol wrote:
>> On 12/31/11, Carl Eugen Hoyos <cehoyos <at> ag.or.at> wrote:
>> > Paul B Mahol <onemda <at> gmail.com> writes:
>> >
>> >> y41p is a packed 12-bit 4:1:1 YUV format used by Brooktree.
>> >
>> > (Fixes issue 1123 / ticket 102)
>> > Just two nits:
>> >
>> >> +    avctx->pix_fmt             = PIX_FMT_YUV411P;
>> >
>> >> +    avctx->bits_per_raw_sample = 12;
>> >
>> > Isn't 12 the default anyway?
>> >
>> > [...]
>> >
>> >> +    .long_name    = NULL_IF_CONFIG_SMALL("Uncompressed YUV 4:1:1
>> >> 12-bit"),
>> >
>> > Imo, this should be "Uncompressed packed YUV 4:1:1"
>> > (But please feel free to ignore)
>> >
>> > Is encoding odd widths allowed?
>>
>> Mplayer with bt411 driver crashes when trying to play Y41P muxed in
>> avi with ffmpeg. (Even if I use -vcodec copy).
>>
>> Another issue is that frame(for the only sample we have) is apparently

Re: [PATCH] vf_tinterlace: implement interlace mode 5

On date Saturday 2011-12-31 16:16:12 +0100, Michael Niedermayer encoded:
> On Sat, Dec 31, 2011 at 02:13:14PM +0100, Stefano Sabatini wrote:
> > Allow creating interlaced bottom field first video.
> > ---
> >  doc/filters.texi            |    4 ++++
> >  libavfilter/vf_tinterlace.c |   23 +++++++++++++----------
> >  2 files changed, 17 insertions(+), 10 deletions(-)
> 
> LGTM

Applied.
--

-- 
FFmpeg = Fanciful and Fundamental Minimalistic Portable Extensive Game

Re: [PATCH] y41p encoder and decoder

y41p is a packed 12-bit 4:1:1 YUV format used by Brooktree.

Fixes issue 1123 / ticket #102.
---
 Changelog              |    1 +
 doc/general.texi       |    1 +
 libavcodec/Makefile    |    2 +
 libavcodec/allcodecs.c |    1 +
 libavcodec/avcodec.h   |    1 +
 libavcodec/version.h   |    2 +-
 libavcodec/y41pdec.c   |  116 ++++++++++++++++++++++++++++++++++++++++++++++++
 libavcodec/y41penc.c   |  101 +++++++++++++++++++++++++++++++++++++++++
 libavformat/isom.c     |    1 +
 libavformat/riff.c     |    1 +
 10 files changed, 226 insertions(+), 1 deletions(-)
 create mode 100644 libavcodec/y41pdec.c
 create mode 100644 libavcodec/y41penc.c

diff --git a/Changelog b/Changelog
index da179db..7b5d277 100644
--- a/Changelog
+++ b/Changelog
 <at>  <at>  -16,6 +16,7  <at>  <at>  version next:
 - Indeo 4 decoder
 - SMJPEG demuxer
 - Automatic thread count based on detection number of (available) CPU cores
+- y41p Brooktree Uncompressed 4:1:1 12-bit encoder and decoder

 version 0.9:
diff --git a/doc/general.texi b/doc/general.texi