>> I bet Michael or me could do this in 15 minutes.
>
> i had almost forgotten it but there is:
> { "src_v_chr_pos", "source vertical chroma position in luma grid/256"
> , OFFSET(src_v_chr_pos), AV_OPT_TYPE_INT, { .i64 = -1}, -1,
> 512, VE },
> { "src_h_chr
Hi,
2014-08-18 19:22 GMT+02:00 Ronald S. Bultje :
> You mean the centerpoint chroma location (top-left, top-middle,
> middle-middle, etc.) respective to the set of luma pixels?
I don't think it's only that, but it's probably only slightly longer
to implement.
For interlaced 4:2:0, each chroma fi
On Mon, Aug 18, 2014 at 01:31:26PM +0200, Stefano Sabatini wrote:
> On date Sunday 2014-08-17 19:04:35 -0400, compn encoded:
> > libav brought up the point again that it doesnt like libmpcodecs.
>
> That is, they will reunite if we drop mp? Or is that one of the
> conditional requirements?
>
> >
On Mon, Aug 18, 2014 at 01:22:37PM -0400, Ronald S. Bultje wrote:
> Hi,
>
>
> On Mon, Aug 18, 2014 at 9:58 AM, Kieran Kunhya wrote:
>
> > > How is it different? If you're interlacing-aware and call
> > swscale_convert()
> > > twice (once for each field, double stride each, alternate offset for
Hi,
On Mon, Aug 18, 2014 at 9:58 AM, Kieran Kunhya wrote:
> > How is it different? If you're interlacing-aware and call
> swscale_convert()
> > twice (once for each field, double stride each, alternate offset for
> second
> > call), isn't that the same?
>
> That would be true in the 422 domain,
On Mon, 18 Aug 2014 13:31:26 +0200
Stefano Sabatini wrote:
> On date Sunday 2014-08-17 19:04:35 -0400, compn encoded:
> > is there anyone using the remaining libmpcodecs filters ?
>
> Of the remaining filters, at least eq and eq2 are useful, and they are
> actually used by real users.
ok, then i
> How is it different? If you're interlacing-aware and call swscale_convert()
> twice (once for each field, double stride each, alternate offset for second
> call), isn't that the same?
That would be true in the 422 domain, yes. In 420, the chroma planes
are offset and this has to be taken into ac
Hi,
On Mon, Aug 18, 2014 at 9:48 AM, Kieran Kunhya wrote:
> On 18 August 2014 14:37, Ivan Kalvachev wrote:
> > On 8/18/14, Kieran Kunhya wrote:
> >> On 18 August 2014 02:26, Ivan Kalvachev wrote:
> >>
> >>> ilpack - interlaced yuv420-> yuv422 converter. Scale should be able to
> >>> do that t
On 18 August 2014 14:37, Ivan Kalvachev wrote:
> On 8/18/14, Kieran Kunhya wrote:
>> On 18 August 2014 02:26, Ivan Kalvachev wrote:
>>
>>> ilpack - interlaced yuv420-> yuv422 converter. Scale should be able to
>>> do that too.
>>
>> Scale doesn't have much (any?) knowledge of interlaced chroma.
On 8/18/14, Kieran Kunhya wrote:
> On 18 August 2014 02:26, Ivan Kalvachev wrote:
>
>> ilpack - interlaced yuv420-> yuv422 converter. Scale should be able to
>> do that too.
>
> Scale doesn't have much (any?) knowledge of interlaced chroma.
> That said I could probably port this filter to lavfi b
On 18 August 2014 02:26, Ivan Kalvachev wrote:
> ilpack - interlaced yuv420-> yuv422 converter. Scale should be able to
> do that too.
Scale doesn't have much (any?) knowledge of interlaced chroma.
That said I could probably port this filter to lavfi because it would
be quite useful to me. I was
On 8/18/14, Carl Eugen Hoyos wrote:
> Ivan Kalvachev gmail.com> writes:
>
>> softpulldown - turns soft into hard telecine.
>
> Do you remember how this filter was used with MEncoder?
> I have a suspicion that it cannot work with FFmpeg.
I have written about it before:
On 5/4/13, Ivan Kalvachev
Ivan Kalvachev gmail.com> writes:
> softpulldown - turns soft into hard telecine.
Do you remember how this filter was used with MEncoder?
I have a suspicion that it cannot work with FFmpeg.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg
Le primidi 1er fructidor, an CCXXII, Stefano Sabatini a écrit :
> That is, they will reunite if we drop mp?
And accept the features in FFmpeg that they have disparagingly called hacks?
I would not bet on that.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
_
On date Sunday 2014-08-17 19:04:35 -0400, compn encoded:
> libav brought up the point again that it doesnt like libmpcodecs.
That is, they will reunite if we drop mp? Or is that one of the
conditional requirements?
> is there anyone using the remaining libmpcodecs filters ?
> most of the filters
On 8/18/14, compn wrote:
> libav brought up the point again that it doesnt like libmpcodecs.
>
> is there anyone using the remaining libmpcodecs filters ?
> most of the filters have been ported to libavfilter already.
They doesn't like Michael too.
They doesn't like that we merge their code.
They
On Sun, 17 Aug 2014 23:11:53 + (UTC)
Carl Eugen Hoyos wrote:
> compn mi.rr.com> writes:
>
> > libav brought up the point again that it doesnt like
> > libmpcodecs.
>
> I don't think removing features is an option that should
> be considered.
I wouldn't call these "features"; more like "
compn mi.rr.com> writes:
> libav brought up the point again that it doesnt like
> libmpcodecs.
I don't think removing features is an option that should
be considered.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.or
On Sun, 17 Aug 2014 19:04:35 -0400
compn wrote:
> libav brought up the point again that it doesnt like libmpcodecs.
>
> is there anyone using the remaining libmpcodecs filters ?
> most of the filters have been ported to libavfilter already.
>
> comments?
+1000
Nobody cares about these filters
libav brought up the point again that it doesnt like libmpcodecs.
is there anyone using the remaining libmpcodecs filters ?
most of the filters have been ported to libavfilter already.
comments?
-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
20 matches
Mail list logo
