On Tue, Apr 19, 2016 at 3:15 PM, Carl Eugen Hoyos wrote:
> Could you explain how I can reproduce the incompleteness?
> Visibly if possible...
It seems right now that we have a function (macro) to convert
(seemingly limited range?) YCbCr to limited range or full range RGB,
both (seemingly) followi
Hendrik Leppkes gmail.com> writes:
> Maybe we should define a "proper" solution (ie. creating a BT.709
> conversion for HD)
I am waiting for your patches since yesterday;-(
> instead of pushing for an incomplete fix.
Could you explain how I can reproduce the incompleteness?
Visibly if possible
On Tue, 19 Apr 2016 08:07:05 + (UTC)
Carl Eugen Hoyos wrote:
> Hendrik Leppkes gmail.com> writes:
>
> > the original patch "improves" it to some degree, as the PAL8
> > format that subtitles come in should be considered a full-range
> > RGB format, but its still not the correct HD RGB colo
On Tue, Apr 19, 2016 at 10:07 AM, Carl Eugen Hoyos wrote:
> Hendrik Leppkes gmail.com> writes:
>
>> the original patch "improves" it to some degree, as the PAL8
>> format that subtitles come in should be considered a full-range
>> RGB format, but its still not the correct HD RGB colorspace.
>
> S
Hendrik Leppkes gmail.com> writes:
> the original patch "improves" it to some degree, as the PAL8
> format that subtitles come in should be considered a full-range
> RGB format, but its still not the correct HD RGB colorspace.
So does everybody agree that it should be committed?
Carl Eugen
__
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
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 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, 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(
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 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 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 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: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 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 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
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, 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
>
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, 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
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 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
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 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:
> 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: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.
_
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,
29 matches
Mail list logo
