On Sat, 16 Apr 2016 13:56:18 -0400
"Ronald S. Bultje" wrote:
> Reproduces a bug to remain consistent with libvpx' behaviour.
> ---
> libavcodec/vp9.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index 5c6f176..70d9c4b 100644
> --- a/libavcodec
Hi everyone!
I was trying to use a custom log callback and noticed that this pretty
much requires using av_log_format_line(), as the interpretation of the
format string is not trivial.
Unfortunately this approach offers no way of determining the size of the
output buffer for the log message. Typi
On 2016-04-17 05:21:31 +, KO Myung-Hun said:
Even if it's a bug of ramfs.ifs, its bug should be considered when using
ln -s.
Yes, and in this particular case configure handles it safely. It
results into a false fallback though because the symlink dir check is
performed in TMPDIR which in
Hi,
On Fri, Apr 15, 2016 at 8:02 PM, Michael Niedermayer wrote:
> On Fri, Apr 15, 2016 at 02:26:47PM -0400, Ronald S. Bultje wrote:
> > ---
> > libavfilter/vf_scale.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
>
> LGTM (if noone else objects)
Pushed. I'll submit patches to u
Hi,
On Sun, Apr 17, 2016 at 6:17 AM, wm4 wrote:
> On Sat, 16 Apr 2016 13:56:18 -0400
> "Ronald S. Bultje" wrote:
>
> > Reproduces a bug to remain consistent with libvpx' behaviour.
> > ---
> > libavcodec/vp9.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/vp9.c b/
On Sun, 17 Apr 2016 13:18:42 +0200
Andreas Weis wrote:
> Hi everyone!
>
> I was trying to use a custom log callback and noticed that this pretty
> much requires using av_log_format_line(), as the interpretation of the
> format string is not trivial.
Uh what? It's just snprintf formatting. What
Hi!
Attached patch fixes ticket #4637 for me.
Please comment, Carl Eugen
diff --git a/libavcodec/pgssubdec.c b/libavcodec/pgssubdec.c
index 07a2a78..36ebbcb 100644
--- a/libavcodec/pgssubdec.c
+++ b/libavcodec/pgssubdec.c
@@ -354,8 +354,8 @@ static int parse_palette_segment(AVCodecContext *avctx,
On Sun, 17 Apr 2016 17:25:04 +0200
Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #4637 for me.
>
> Please comment, Carl Eugen
This looks like an entirely random change with no explanation or
justification given. It may as well break working combinations of pgs
subs/video.
_
wm4 googlemail.com> writes:
> On Sun, 17 Apr 2016 17:25:04 +0200
> Carl Eugen Hoyos ag.or.at> wrote:
>
> > Hi!
> >
> > Attached patch fixes ticket #4637 for me.
> This looks like an entirely random change with no explanation
> or justification given.
I don't understand:
We have a sample tha
On Sun, 17 Apr 2016 17:39:34 + (UTC)
Carl Eugen Hoyos wrote:
> wm4 googlemail.com> writes:
>
> > On Sun, 17 Apr 2016 17:25:04 +0200
> > Carl Eugen Hoyos ag.or.at> wrote:
> >
> > > Hi!
> > >
> > > Attached patch fixes ticket #4637 for me.
>
> > This looks like an entirely random chan
wm4 googlemail.com> writes:
> > > > Attached patch fixes ticket #4637 for me.
> >
> > > This looks like an entirely random change with no explanation
> > > or justification given.
> >
> > I don't understand:
> > We have a sample that looks broken with current FFmpeg and fine
> > with the
On Fri, 15 Apr 2016, Jan Sebechlebsky wrote:
On 04/15/2016 02:28 AM, Marton Balint wrote:
On Thu, 14 Apr 2016, Marton Balint wrote:
On Tue, 12 Apr 2016, sebechlebsky...@gmail.com wrote:
From: Jan Sebechlebsky
Calling close_slave in case error is to be returned from open_slave
will fre
On 17 April 2016 at 03:40, Michael Niedermayer
wrote:
>
> is this a spec compliance or a profile compliance issue or something
> else ?
>
> from just the Commit message above it sounds a bit like a profile /
> hw decoder limitation, in which case this patch with a different
> av_log() message sho
On Sun, Apr 17, 2016 at 01:18:42PM +0200, Andreas Weis wrote:
> Since av_log_format_line calls snprintf internally, that might be as
> trivial as just forwarding the return value from that call.
This probably wasn't done because snprintf isn't always
implemented 100% right in this regard (too smal
From: Jan Sebechlebsky
Adds per slave option 'onfail' to the tee muxer allowing an output to
fail,so other slave outputs can continue.
Signed-off-by: Jan Sebechlebsky
---
Sorry I've missed those. It is fixed in this patch.
Regards,
Jan S.
doc/muxers.texi | 14 +
libavformat/tee.
On Sun, Apr 17, 2016 at 6:25 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #4637 for me.
>
> Please comment, Carl Eugen
Hi,
Can you please explain the difference between these two YCbCr-to-RGB
conversion functions?
The result, if it is now black, seems to match what MPC-HC's
On Sun, Apr 17, 2016 at 05:54:00PM +, Carl Eugen Hoyos wrote:
> wm4 googlemail.com> writes:
> > What proves that the sample you have renders correctly now?
>
> Nothing.
>
> You think that it is more likely that the sample was
> intentionally made to fool the vlc developers than to
> help t
Tobias Rapp noa-archive.com> writes:
> > $ ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags
> > -f lavfi movie=sample-vitc.avi,readvitc
> >
> > Output looks identical to yuv420p so I guess white is ok...
>
> (I assume you also converted the sample file to GBRP.)
Sorry for the conf
Reimar Döffinger gmx.de> writes:
> On Sun, Apr 17, 2016 at 05:54:00PM +, Carl Eugen Hoyos wrote:
> > wm4 googlemail.com> writes:
> > > What proves that the sample you have renders correctly now?
> >
> > Nothing.
> >
> > You think that it is more likely that the sample was
> > intentionall
On Sun, Apr 17, 2016 at 9:21 PM, Reimar Döffinger
wrote:
> In particular, I have an uncomfortable suspicion that
> PGS might be designed to match the movie's colour space,
> in which case neither variant would give correct results
> but instead it would have to depend on what format the
> correspo
On Sun, 17 Apr 2016 17:54:00 + (UTC)
Carl Eugen Hoyos wrote:
> wm4 googlemail.com> writes:
>
> > > > > Attached patch fixes ticket #4637 for me.
> > >
> > > > This looks like an entirely random change with no explanation
> > > > or justification given.
> > >
> > > I don't under
On Sun, 17 Apr 2016 21:41:32 +0300
Jan Ekstrom wrote:
> On Sun, Apr 17, 2016 at 9:21 PM, Reimar Döffinger
> wrote:
> > In particular, I have an uncomfortable suspicion that
> > PGS might be designed to match the movie's colour space,
> > in which case neither variant would give correct results
>
Jan Ekstrom gmail.com> writes:
> On Sun, Apr 17, 2016 at 6:25 PM, Carl Eugen Hoyos wrote:
> > Attached patch fixes ticket #4637 for me.
> Can you please explain the difference between these two
> YCbCr-to-RGB conversion functions?
I fear you don't accept "it looks black instead of gray"
as an
On Sun, Apr 17, 2016 at 9:44 PM, wm4 wrote:
>
> Ah that's funny. This indeed ruins everything. It looks like subtitle
> decoders should simply output YUV, and until we can fix it, a private
> option could change between the colorspaces?
Well, the colorimetry is at least specified as per the resol
Michael Niedermayer niedermayer.cc> writes:
> > webp.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > 6a8ad3a804cb624b509c6bff37b2dc1359dc43c7 patchwebpwarn.diff
>
> probably ok
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-dev
On Sun, Apr 17, 2016 at 06:38:12PM +, Carl Eugen Hoyos wrote:
> Reimar Döffinger gmx.de> writes:
> > In particular, I have an uncomfortable suspicion that
> > PGS might be designed to match the movie's colour space,
> > in which case neither variant would give correct results
> > but instead i
On Sun, Apr 17, 2016 at 09:41:32PM +0300, Jan Ekstrom wrote:
> On Sun, Apr 17, 2016 at 9:21 PM, Reimar Döffinger
> wrote:
> > In particular, I have an uncomfortable suspicion that
> > PGS might be designed to match the movie's colour space,
> > in which case neither variant would give correct resu
On Sun, Apr 17, 2016 at 9:55 PM, Reimar Döffinger
wrote:
> ?!???
> These two kind of contradict each other, at least if the HDMV video
> stream uses a full range color matrix (or is that not allowed?).
Just poked at this and it seems indeed that the following values are
set for the resolution pro
On Sun, Apr 17, 2016 at 09:49:58PM +0300, Jan Ekstrom wrote:
> On Sun, Apr 17, 2016 at 9:44 PM, wm4 wrote:
> >
> > Ah that's funny. This indeed ruins everything. It looks like subtitle
> > decoders should simply output YUV, and until we can fix it, a private
> > option could change between the col
On Sunday 17 April 2016 08:41:32 pm Jan Ekstrom wrote:
> On Sun, Apr 17, 2016 at 9:21 PM, Reimar Döffinger
>
> wrote:
> > In particular, I have an uncomfortable suspicion that
> > PGS might be designed to match the movie's colour space,
> > in which case neither variant would give correct results
On Sunday 17 April 2016 08:41:32 pm Jan Ekstrom wrote:
> Yes, the YCbCr values in palettes are matched accordingly against the
> video stream. As per the specification:
> "Y, Cr and Cb shall have the same color matrix as the associated HDMV
> Video stream: 525-60/625-50 (Rec.601); 1080i, 720p (ITU-
On Sun, Apr 17, 2016 at 10:08 PM, Carl Eugen Hoyos wrote:
>
> Does attached make it better?
So the difference between the two conversion functions is that one is
Rec.601 in limited range, and the other is Rec.709 in limited range?
If so, that seems correct. The actual coded width/height of "625/5
On Sun, Apr 17, 2016 at 09:08:45PM +0200, Carl Eugen Hoyos wrote:
> -YUV_TO_RGB1(cb, cr);
> -YUV_TO_RGB2(r, g, b, y);
> +if (ctx->hdtv > 0) {
> +YUV_TO_RGB1_CCIR(cb, cr);
> +YUV_TO_RGB2_CCIR(r, g, b, y);
> +} else {
> +YUV_TO_RGB1(
Am 12.04.16 um 11:51 schrieb Thilo Borgmann:
> Am 11.04.16 um 04:34 schrieb Michael Niedermayer:
>> On Sun, Apr 10, 2016 at 06:33:47PM +0200, Thilo Borgmann wrote:
>>> Hi,
>>>
>>> basically adding number of input/output frames in expression evaluation
>>> for perspective transform coordinates.
>>>
On Sun, Apr 17, 2016 at 09:24:29PM +0200, Reimar Döffinger wrote:
> On Sun, Apr 17, 2016 at 09:08:45PM +0200, Carl Eugen Hoyos wrote:
> > -YUV_TO_RGB1(cb, cr);
> > -YUV_TO_RGB2(r, g, b, y);
> > +if (ctx->hdtv > 0) {
> > +YUV_TO_RGB1_CCIR(cb, cr);
> > +
On Sun, 17 Apr 2016, sebechlebsky...@gmail.com wrote:
From: Jan Sebechlebsky
Adds per slave option 'onfail' to the tee muxer allowing an output to
fail,so other slave outputs can continue.
[..]
static int tee_write_trailer(AVFormatContext *avf)
{
TeeContext *tee = avf->priv_data;
+
From: Jan Sebechlebsky
Adds per slave option 'onfail' to the tee muxer allowing an output to
fail,so other slave outputs can continue.
Signed-off-by: Jan Sebechlebsky
---
This is embarassing, sorry for that! You're right in both, I've tried
to merge my old file with the changes in previous p
On Sun, Apr 17, 2016 at 8:55 PM, Reimar Döffinger
wrote:
> On Sun, Apr 17, 2016 at 09:41:32PM +0300, Jan Ekstrom wrote:
>> On Sun, Apr 17, 2016 at 9:21 PM, Reimar Döffinger
>> wrote:
>> > In particular, I have an uncomfortable suspicion that
>> > PGS might be designed to match the movie's colour
On Sun, Apr 17, 2016 at 9:16 PM, Jan Ekstrom wrote:
> On Sun, Apr 17, 2016 at 10:08 PM, Carl Eugen Hoyos wrote:
>>
>> Does attached make it better?
>
> So the difference between the two conversion functions is that one is
> Rec.601 in limited range, and the other is Rec.709 in limited range?
> If
Carl Eugen Hoyos ag.or.at> writes:
> Attached patch fixes ticket #5174, there seems to be nothing
> invalid about a cursor outside of the screen or an empty cursor.
Ping.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg
About a year ago I posted some concerns about color accuracy and received this
response:
> The specific code I'm referring to is at the end of colorspace.h
>
> #define RGB_TO_Y(r1, g1, b1, shift)
> #define RGB_TO_U(r1, g1, b1, shift)
> #define RGB_TO_V(r1, g1, b1, shift)
>A quick search over th
>> I was trying to use a custom log callback and noticed that this pretty
>> much requires using av_log_format_line(), as the interpretation of the
>> format string is not trivial.
>
> Uh what? It's just snprintf formatting. What av_log_format_line() is
> adding additional information, which in th
42 matches
Mail list logo
