On Tue, Apr 7, 2020 at 7:58 AM Paul B Mahol wrote:
> On 4/7/20, Vittorio Giovara wrote:
> > On Sat, Dec 22, 2018 at 3:18 PM Paul B Mahol wrote:
> >
> >> On 12/22/18, Steinar H. Gunderson wrote:
> >> > On Sat, Dec 22, 2018 at 09:04:26PM +0100, Paul B Mahol wrote:
> >> >> I can not accept
On 4/7/20, Vittorio Giovara wrote:
> On Sat, Dec 22, 2018 at 3:18 PM Paul B Mahol wrote:
>
>> On 12/22/18, Steinar H. Gunderson wrote:
>> > On Sat, Dec 22, 2018 at 09:04:26PM +0100, Paul B Mahol wrote:
>> >> I can not accept internal conversion to RGB. This is subsampled format
>> >> after all.
On Sat, Dec 22, 2018 at 3:18 PM Paul B Mahol wrote:
> On 12/22/18, Steinar H. Gunderson wrote:
> > On Sat, Dec 22, 2018 at 09:04:26PM +0100, Paul B Mahol wrote:
> >> I can not accept internal conversion to RGB. This is subsampled format
> >> after all.
> >
> > Well, it's not Y'CbCr, so if so,
On 4/7/20, Carl Eugen Hoyos wrote:
> Am Fr., 21. Dez. 2018 um 19:48 Uhr schrieb Paul B Mahol :
>>
>> Signed-off-by: Paul B Mahol
>> ---
>> libavcodec/Makefile | 1 +
>> libavcodec/allcodecs.c | 1 +
>> libavcodec/avcodec.h| 1 +
>> libavcodec/codec_desc.c | 7 +
>>
Am Fr., 21. Dez. 2018 um 19:48 Uhr schrieb Paul B Mahol :
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h| 1 +
> libavcodec/codec_desc.c | 7 +
> libavcodec/photocd.c| 493
Derek Buitenhuis (12019-01-11):
> I'm sorry, but this just reeks of "your motives aren't pure enough for
> us to trust you" partisanship, which is, frankly, disgusting.
Maybe not enough people have been obnoxious to you during review for you
to feel the problem. Or maybe you have thicker skin.
>
On 11/01/2019 16:23, Nicolas George wrote:
> Derek Buitenhuis (12019-01-11):
>> Irrelevant to whether a patch is acceptable or not to FFmpeg.
>
> In theory, it is, and it should be.
>
> In practice, I have several times suspected a sponsored work was the
> reason behind cutting corners, poor
Derek Buitenhuis (12019-01-11):
> Irrelevant to whether a patch is acceptable or not to FFmpeg.
In theory, it is, and it should be.
In practice, I have several times suspected a sponsored work was the
reason behind cutting corners, poor design and future planning, bad
reception of review
On 11/01/2019 15:26, Nicolas George wrote:
> Carl Eugen Hoyos (12019-01-11):
>> The original unfinished demuxer was posted to the development
>> mailing list:
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2010-January/086658.html
>
> Ah, good to know. Still, Paul made efforts to resurrect that
2019-01-11 16:26 GMT+01:00, Nicolas George :
> Carl Eugen Hoyos (12019-01-11):
>> The original unfinished demuxer was posted to the development
>> mailing list:
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2010-January/086658.html
>
> Ah, good to know. Still, Paul made efforts to resurrect that
Carl Eugen Hoyos (12019-01-11):
> The original unfinished demuxer was posted to the development
> mailing list:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2010-January/086658.html
Ah, good to know. Still, Paul made efforts to resurrect that patch, I
wonder if these efforts were sponsored, and in
2019-01-11 16:20 GMT+01:00, Nicolas George :
> Paul B Mahol (12019-01-11):
>> No, pay me first.
>
> That actually explains a lot of things...
>
> But I wonder: were you not payed by somebody for this
> unfinished demuxer?
The original unfinished demuxer was posted to the development
mailing list:
Paul B Mahol (12019-01-11):
> No, pay me first.
That actually explains a lot of things...
But I wonder: were you not payed by somebody for this unfinished
demuxer?
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel
On 1/11/19, Carl Eugen Hoyos wrote:
> 2018-12-22 21:32 GMT+01:00, Paul B Mahol :
>> On 12/22/18, Steinar H. Gunderson wrote:
>>> On Sat, Dec 22, 2018 at 09:18:11PM +0100, Paul B Mahol wrote:
Unacceptable, I'm not adding another yuv420p variant.
>>>
>>> Well, if returning YCC as YCC is
2018-12-22 21:32 GMT+01:00, Paul B Mahol :
> On 12/22/18, Steinar H. Gunderson wrote:
>> On Sat, Dec 22, 2018 at 09:18:11PM +0100, Paul B Mahol wrote:
>>> Unacceptable, I'm not adding another yuv420p variant.
>>
>> Well, if returning YCC as YCC is unacceptable, and converting YCC to RGB
>> is
>>
On Sat, Dec 22, 2018 at 09:28:47PM +0100, Steinar H. Gunderson wrote:
> On Sat, Dec 22, 2018 at 09:18:11PM +0100, Paul B Mahol wrote:
> > Unacceptable, I'm not adding another yuv420p variant.
>
> Well, if returning YCC as YCC is unacceptable, and converting YCC to RGB is
> unacceptable, I believe
On Sat, Dec 22, 2018 at 09:32:35PM +0100, Paul B Mahol wrote:
>> 2. Return YCC mislabeled as something else, which will look even more
>> wrong.
> 4. Leave user to do conversion as he wish.
That's essentially the same as #2, no?
/* Steinar */
--
Homepage: https://www.sesse.net/
On 12/22/18, Steinar H. Gunderson wrote:
> On Sat, Dec 22, 2018 at 09:18:11PM +0100, Paul B Mahol wrote:
>> Unacceptable, I'm not adding another yuv420p variant.
>
> Well, if returning YCC as YCC is unacceptable, and converting YCC to RGB is
> unacceptable, I believe your only choices are:
>
>
On Sat, Dec 22, 2018 at 09:18:11PM +0100, Paul B Mahol wrote:
> Unacceptable, I'm not adding another yuv420p variant.
Well, if returning YCC as YCC is unacceptable, and converting YCC to RGB is
unacceptable, I believe your only choices are:
1. Try to convert YCC to Y'CbCr ignoring the gamma
On 12/22/18, Steinar H. Gunderson wrote:
> On Sat, Dec 22, 2018 at 09:04:26PM +0100, Paul B Mahol wrote:
>> I can not accept internal conversion to RGB. This is subsampled format
>> after all.
>
> Well, it's not Y'CbCr, so if so, you'd need to add a new AVPixelFormat value
> (e.g.
On Sat, Dec 22, 2018 at 09:04:26PM +0100, Paul B Mahol wrote:
> I can not accept internal conversion to RGB. This is subsampled format
> after all.
Well, it's not Y'CbCr, so if so, you'd need to add a new AVPixelFormat value
(e.g. AV_PIX_FMT_YCC420P). I'm not sure what applications would do with
On 12/22/18, Steinar H. Gunderson wrote:
> On Sat, Dec 22, 2018 at 09:53:16AM +0100, Paul B Mahol wrote:
>>> FFmpeg doesn't have a good understanding of gamma (it rarely actually
>>> converts between different gamma ramps), but that's not a problem with
>>> PhotoCD per se. I can't find a good
On Sat, Dec 22, 2018 at 09:53:16AM +0100, Paul B Mahol wrote:
>> FFmpeg doesn't have a good understanding of gamma (it rarely actually
>> converts between different gamma ramps), but that's not a problem with
>> PhotoCD per se. I can't find a good reason why FFmpeg could not be
>> extended with
On 12/21/18, Steinar H. Gunderson wrote:
> On Fri, Dec 21, 2018 at 05:07:45PM +0100, Paul B Mahol wrote:
>> The colors that PhotoCD uses predates color space definitions.
>
> Really? It looks fairly well-defined to me, though esoteric
> (the gamma ramp is basically like sRGB but with a much
On Fri, Dec 21, 2018 at 05:07:45PM +0100, Paul B Mahol wrote:
> The colors that PhotoCD uses predates color space definitions.
Really? It looks fairly well-defined to me, though esoteric
(the gamma ramp is basically like sRGB but with a much bigger constant,
and the 8-bit Y'CbCr scaling seems
2018-12-20 0:52 GMT+01:00, Peter Ross :
> also where can i find a sample to fuzz test?
See http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket5923/
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
2018-12-21 19:48 GMT+01:00, Paul B Mahol :
> +if (s->luma) {
> +ptr = p->data[0];
> +
> +for (int y = 0; y < avctx->height; y++) {
> +for (int x = 0; x < avctx->width; x++) {
> +ptr[x] = av_clip_uint8(ptr[x] * 1.35);
> +}
Without this
On 12/20/18, Peter Ross wrote:
> also where can i find a sample to fuzz test?
You can create small samples with ImageMagick/GraphicsMagick otherwise
use google skills.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 +
libavcodec/photocd.c| 493
5 files changed, 503 insertions(+)
create mode 100644
On 12/21/18, Paul B Mahol wrote:
> On 12/21/18, Carl Eugen Hoyos wrote:
>>
>>
>>> Am 21.12.2018 um 16:43 schrieb Paul B Mahol :
>>>
On 12/21/18, Carl Eugen Hoyos wrote:
2018-12-20 10:02 GMT+01:00, Paul B Mahol :
>> On 12/20/18, Carl Eugen Hoyos wrote:
>> 2018-12-19 21:32
On 12/21/18, Carl Eugen Hoyos wrote:
>
>
>> Am 21.12.2018 um 16:43 schrieb Paul B Mahol :
>>
>>> On 12/21/18, Carl Eugen Hoyos wrote:
>>> 2018-12-20 10:02 GMT+01:00, Paul B Mahol :
> On 12/20/18, Carl Eugen Hoyos wrote:
> 2018-12-19 21:32 GMT+01:00, Paul B Mahol :
>
>> +static
> Am 21.12.2018 um 16:43 schrieb Paul B Mahol :
>
>> On 12/21/18, Carl Eugen Hoyos wrote:
>> 2018-12-20 10:02 GMT+01:00, Paul B Mahol :
On 12/20/18, Carl Eugen Hoyos wrote:
2018-12-19 21:32 GMT+01:00, Paul B Mahol :
> +static av_cold int photocd_decode_init(AVCodecContext
Paul B Mahol (2018-12-21):
> I will ignore your comments as there is misunderstanding from your side.
Unacceptable. If somebody has misunderstood something you wrote, then
you need to explain better.
--
Nicolas George
signature.asc
Description: Digital signature
On 12/21/18, Carl Eugen Hoyos wrote:
> 2018-12-20 10:02 GMT+01:00, Paul B Mahol :
>> On 12/20/18, Carl Eugen Hoyos wrote:
>>> 2018-12-19 21:32 GMT+01:00, Paul B Mahol :
>>>
+static av_cold int photocd_decode_init(AVCodecContext *avctx)
+{
+avctx->pix_fmt=
2018-12-20 10:02 GMT+01:00, Paul B Mahol :
> On 12/20/18, Carl Eugen Hoyos wrote:
>> 2018-12-19 21:32 GMT+01:00, Paul B Mahol :
>>
>>> +static av_cold int photocd_decode_init(AVCodecContext *avctx)
>>> +{
>>> +avctx->pix_fmt= AV_PIX_FMT_YUV420P;
>>
>> I very much welcome this patch but it
Paul B Mahol (2018-12-20):
> It is an obvious attack.
It was a technical comment wrapped in very polite and welcoming
language. Maybe it was an obvious mistake (but if it is obvious, I
cannot see it), but it certainly was not an attack.
Regards,
--
Nicolas George
signature.asc
Description:
On 12/20/18, Nicolas George wrote:
> Paul B Mahol (2018-12-20):
>> Please refrain from telling me such obvious untrue things.
>
> How can it be obvious if it is untrue?
>
> Rather than taking it as an attack, I think a better approach would be
> to assume the comment was given in good faith and
Paul B Mahol (2018-12-20):
> Please refrain from telling me such obvious untrue things.
How can it be obvious if it is untrue?
Rather than taking it as an attack, I think a better approach would be
to assume the comment was given in good faith and use the single line
you answer to give an useful
On 12/20/18, Carl Eugen Hoyos wrote:
> 2018-12-19 21:32 GMT+01:00, Paul B Mahol :
>
>> +static av_cold int photocd_decode_init(AVCodecContext *avctx)
>> +{
>> +avctx->pix_fmt= AV_PIX_FMT_YUV420P;
>
> I very much welcome this patch but it appears that the colourspace
> conversion is
2018-12-19 21:32 GMT+01:00, Paul B Mahol :
> +static av_cold int photocd_decode_init(AVCodecContext *avctx)
> +{
> +avctx->pix_fmt= AV_PIX_FMT_YUV420P;
I very much welcome this patch but it appears that the colourspace
conversion is missing that was part of the original patchset=-(
Carl
On Wed, Dec 19, 2018 at 09:32:03PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h| 1 +
> libavcodec/codec_desc.c | 7 +
> libavcodec/photocd.c| 445
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 +
libavcodec/photocd.c| 445
5 files changed, 455 insertions(+)
create mode 100644
42 matches
Mail list logo
