On Sun, 25 Sep 2022 10:38:22 +0100, Reino Wijnsma wrote:
On 2022-09-21T17:10:21+0200, Dan wrote:
Thanks for both of those ffmpeg CLI lines! They do actually work for me (in MPC
and Chrome).
Would you consider both of the lines safe to use?
These commands, after careful observation, are the
On 2022-09-21T17:10:21+0200, Dan wrote:
> Thanks for both of those ffmpeg CLI lines! They do actually work for me (in
> MPC and Chrome).
> Would you consider both of the lines safe to use?
These commands, after careful observation, are the ones that work for me to
closely match the original colo
On Sun, 18 Sep 2022 22:49:58 +0100, Reino Wijnsma wrote:
With FFmpeg, creating a temp-file, zscale does work:
ffmpeg -i PLdsb.png -t 5 -vf "zscale=m=709" -c:v libx264 -crf 0
PLdsb_zscale-bt709.mp4
Again, not exactly the same colour, but very close.
SNIP
These are all VUI (Video
On 2022-09-14T11:21:58+0200, Dan wrote:
> The double height version is darker than it should be. I've checked the
> resulting video in both Media Player Classic and Chrome.
>
> If you check the dark green colour on the original PNG images, using an eye
> dropper tool, they're both R=25,G=74,B=15
>
> Is colorspace and color matrix not the same? If not, how can color
> matrix be specified in the command line?
> How can white point be specified in the command line?
>
No, it's not the same. Personally, I prefer to use color representation
instead. But that wouldn't help in this discussion. :)
Please show your complete command line. Because for me it doesn't work.
Different colors for height 576 and 720.
Sure:
ffmpeg.exe -f lavfi -i color=0x19be0f:s=400x720 -crf 0 -vcodec libx264
-t 5 -y -colorspace fcc 720fcc.mp4
For me that doesn't work in Windows. The color in VLC player is
18,
On Fri, 16 Sep 2022 15:51:22 +0100, Erik Dobberkau
wrote:
Thinking RGB would be the remedy for everything is simply a bit naive (no
offense intended), because even RGB may (quite likely) not be one and the
same in any given case.
No offense taken. I'm thinking in more of an ideal sense in th
Am 16.09.2022 um 16:51 schrieb Erik Dobberkau:
Apart from width, height, PAR, DAR and SAR, bit depth and subsampling
method, the color encoding parameters are responsible for the visual
representation of an image: color space, primaries, white point, transfer
function, color range, and color mat
Am 16.09.2022 um 16:34 schrieb Dan:
On Fri, 16 Sep 2022 14:55:20 +0100, Michael Koch
wrote:
Am 16.09.2022 um 15:20 schrieb Dan:
showinfo filter shows video frame color metadata to output of console,
nothing less - nothing more. showinfo cant produce incorrect video, if
you ever bothered to r
> I know enough to say I can't wait until everyone can unify under a single
> colour space/profile, scrap YUV, scrap chroma subsampling and go with RGB.
> Disk space and bandwidth is getting cheaper and cheaper after all.
Unfortunately it’s not that simple, please see below.
Haha, okay let's put
On Fri, 16 Sep 2022 14:55:20 +0100, Michael Koch
wrote:
Am 16.09.2022 um 15:20 schrieb Dan:
showinfo filter shows video frame color metadata to output of console,
nothing less - nothing more. showinfo cant produce incorrect video, if
you ever bothered to read documentation you would know.
B
It is evident that your knowledge is exactly 0.
I know enough to say I can't wait until everyone can unify under a single
colour space/profile, scrap YUV, scrap chroma subsampling and go with RGB.
Disk space and bandwidth is getting cheaper and cheaper after all.
Haha, okay let's put egos aside
Am 16.09.2022 um 15:20 schrieb Dan:
showinfo filter shows video frame color metadata to output of console,
nothing less - nothing more. showinfo cant produce incorrect video, if
you ever bothered to read documentation you would know.
By the way, just to clarify, I wasn't talking about the conso
On 9/16/22, Dan wrote:
>> showinfo filter shows video frame color metadata to output of console,
>> nothing less - nothing more. showinfo cant produce incorrect video, if
>> you ever bothered to read documentation you would know.
>
> By the way, just to clarify, I wasn't talking about the console
showinfo filter shows video frame color metadata to output of console,
nothing less - nothing more. showinfo cant produce incorrect video, if
you ever bothered to read documentation you would know.
By the way, just to clarify, I wasn't talking about the console output, but
the window it opened u
Sure.
The colour is both the same now (for both Chrome and MPC), except it's
the darker, wrong colour (green=164 instead of 190).
Try some other values instead of "bt709".
Went through a ton
ERROR - DIDN'T RUN: bt470m, bt601-6-525, bt601-6-625, bt2020, bt2020ncl,
linear, log100, log316,
On 9/15/22, Michael Koch wrote:
> Am 15.09.2022 um 13:43 schrieb Dan:
>> On Thu, 15 Sep 2022 12:07:08 +0100, Michael Koch
>> wrote:
>>
>>> Am 15.09.2022 um 11:53 schrieb Dan:
> This seems to work with VLC player:
>
> ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0
Am 15.09.2022 um 13:43 schrieb Dan:
On Thu, 15 Sep 2022 12:07:08 +0100, Michael Koch
wrote:
Am 15.09.2022 um 11:53 schrieb Dan:
This seems to work with VLC player:
ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0
-vcodec libx264 -t 5 -y out1.mp4
ffmpeg -f lavfi -i color=
On Thu, 15 Sep 2022 12:07:08 +0100, Michael Koch
wrote:
Am 15.09.2022 um 11:53 schrieb Dan:
This seems to work with VLC player:
ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0
-vcodec libx264 -t 5 -y out1.mp4
ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -colorspace bt709
Am 15.09.2022 um 11:53 schrieb Dan:
This seems to work with VLC player:
ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0
-vcodec libx264 -t 5 -y out1.mp4
ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -colorspace bt709 -crf 0
-vcodec libx264 -t 5 -y out2.mp4
Unfortunately, doe
Am 15.09.2022 um 11:53 schrieb Dan:
This seems to work with VLC player:
ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0
-vcodec libx264 -t 5 -y out1.mp4
ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -colorspace bt709 -crf 0
-vcodec libx264 -t 5 -y out2.mp4
Unfortunately, doe
On Thu, 15 Sep 2022 10:40:10 +0100, Paul B Mahol wrote:
Looks like your knowledge is very limited, incorrect.
Of course it is! I said I was a beginner to ffmpeg and never pretended
otherwise.
My expertise is in other areas (3D, C# programming, music etc.)
I never made any outright statement
Am 15.09.2022 um 11:41 schrieb Paul B Mahol:
On 9/15/22, Michael Koch wrote:
Am 15.09.2022 um 11:26 schrieb Dan:
You are right that datascope shows no difference. But the issue is also
reproducible with VLC player.
As well as VLC Player and FFplay, I've tried MediaPlayerClassic,
Google Chrome
This seems to work with VLC player:
ffmpeg -f lavfi -i color=0x19be0f:s=400x576 -colorspace bt709 -crf 0
-vcodec libx264 -t 5 -y out1.mp4
ffmpeg -f lavfi -i color=0x19be0f:s=400x578 -colorspace bt709 -crf 0
-vcodec libx264 -t 5 -y out2.mp4
Unfortunately, doesn't work for me in MPC or Chrome. Ca
On 9/15/22, Michael Koch wrote:
> Am 15.09.2022 um 11:26 schrieb Dan:
>>> You are right that datascope shows no difference. But the issue is also
>>> reproducible with VLC player.
>>
>> As well as VLC Player and FFplay, I've tried MediaPlayerClassic,
>> Google Chrome,
>> Microsoft Edge and Vegas P
On 9/15/22, Dan wrote:
>> You are right that datascope shows no difference. But the issue is also
>> reproducible with VLC player.
>
> As well as VLC Player and FFplay, I've tried MediaPlayerClassic, Google
> Chrome,
> Microsoft Edge and Vegas Pro, and the problem occurs with each of those.
> Coul
Am 15.09.2022 um 11:26 schrieb Dan:
You are right that datascope shows no difference. But the issue is also
reproducible with VLC player.
As well as VLC Player and FFplay, I've tried MediaPlayerClassic,
Google Chrome,
Microsoft Edge and Vegas Pro, and the problem occurs with each of
those. Co
You are right that datascope shows no difference. But the issue is also
reproducible with VLC player.
As well as VLC Player and FFplay, I've tried MediaPlayerClassic, Google Chrome,
Microsoft Edge and Vegas Pro, and the problem occurs with each of those. Could
there be a "takes two to tango" thi
Am 15.09.2022 um 11:01 schrieb Paul B Mahol:
On 9/15/22, Michael Koch wrote:
Am 15.09.2022 um 00:30 schrieb Paul B Mahol:
On 9/15/22, Dan wrote:
zscale=...,format=yuv420p
O okay. I tried that before (except using two -vf commands),
because
I
suspected you might've meant that.
Just
On 9/15/22, Michael Koch wrote:
> Am 15.09.2022 um 00:30 schrieb Paul B Mahol:
>> On 9/15/22, Dan wrote:
zscale=...,format=yuv420p
>>> O okay. I tried that before (except using two -vf commands),
>>> because
>>> I
>>> suspected you might've meant that.
>>>
>>> Just tried it again, st
Am 15.09.2022 um 00:30 schrieb Paul B Mahol:
On 9/15/22, Dan wrote:
zscale=...,format=yuv420p
O okay. I tried that before (except using two -vf commands), because
I
suspected you might've meant that.
Just tried it again, still no luck. Let me know if I need to tweak
anything:
ffmpeg.
On 9/15/22, Dan wrote:
>> zscale=...,format=yuv420p
>
> O okay. I tried that before (except using two -vf commands), because
> I
> suspected you might've meant that.
>
> Just tried it again, still no luck. Let me know if I need to tweak
> anything:
>
> ffmpeg.exe -f lavfi -i color=0x19be0f
The crazy thing is when you vertically stack the two videos together,
then the colors become again identical in the output:
ffmpeg -i out1.mp4 -i out2.mp4 -lavfi vstack -y out.mp4
Sorry, I have no idea for a solution or workaround.
To make things even more confusing, Media Player Classic break
zscale=...,format=yuv420p
O okay. I tried that before (except using two -vf commands), because I
suspected you might've meant that.
Just tried it again, still no luck. Let me know if I need to tweak anything:
ffmpeg.exe -f lavfi -i color=0x19be0f:s=400x578 -crf 0 -vcodec libx264 -vf
z
On 9/14/22, Dan wrote:
>>> Unless I'm somehow misusing zscale (which is a possibility), it would
>>> seem
>>> as if the
>>> problem lies elsewhere.
>>
>> If you do not use format filter after zscale it will not work correctly.
>
> Do you mean using the "filter" keyword under the zscale property/va
On 9/14/22, Paul B Mahol wrote:
> On 9/14/22, Dan wrote:
>> On Wed, 14 Sep 2022 21:26:59 +0100, Carl Zwanzig wrote:
>>
>>> On 9/14/2022 8:01 AM, Paul B Mahol wrote:
The reason of scale behavior is known and legacy.
>>>
>>> Is it documented with the filter? I don't see anything obvious about
Unless I'm somehow misusing zscale (which is a possibility), it would seem
as if the
problem lies elsewhere.
If you do not use format filter after zscale it will not work correctly.
Do you mean using the "filter" keyword under the zscale property/variable?
I tried this, again no luck (also tr
On 9/14/22, Dan wrote:
> On Wed, 14 Sep 2022 21:26:59 +0100, Carl Zwanzig wrote:
>
>> On 9/14/2022 8:01 AM, Paul B Mahol wrote:
>>> The reason of scale behavior is known and legacy.
>>
>> Is it documented with the filter? I don't see anything obvious about it
>> at
>> https://ffmpeg.org/ffmpeg-fi
On Wed, 14 Sep 2022 21:26:59 +0100, Carl Zwanzig wrote:
On 9/14/2022 8:01 AM, Paul B Mahol wrote:
The reason of scale behavior is known and legacy.
Is it documented with the filter? I don't see anything obvious about it at
https://ffmpeg.org/ffmpeg-filters.html#toc-scale-1, where can a perso
Am 14.09.2022 um 19:00 schrieb Dan:
That's a great idea to use specified colours directly supported by ffmpeg
and helps narrow down the issue a lot!
Would you count this as a bug?
It seems to be a bug.
If this is a known legacy quirk, it seems
one of the ugliest and most misleading quirks I
On 9/14/2022 8:01 AM, Paul B Mahol wrote:
The reason of scale behavior is known and legacy.
Is it documented with the filter? I don't see anything obvious about it at
https://ffmpeg.org/ffmpeg-filters.html#toc-scale-1, where can a person find
about this otherwise-known behavior?
Next time b
That's a great idea to use specified colours directly supported by ffmpeg
and helps narrow down the issue a lot!
Would you count this as a bug? If this is a known legacy quirk, it seems
one of the ugliest and most misleading quirks I have seen in a while, and I
could
imagine being responsible fo
On 9/14/22, Michael Koch wrote:
> Am 14.09.2022 um 11:21 schrieb Dan:
>> Using the latest 5.1.1 "essentials build" by www.gyan.dev.
>>
>> Hi all, I'm a beginner to ffmpeg so I'm having a hard time believing
>> that a utility so old and so widely used has such a fundamental bug,
>> but the evidence
Am 14.09.2022 um 11:21 schrieb Dan:
Using the latest 5.1.1 "essentials build" by www.gyan.dev.
Hi all, I'm a beginner to ffmpeg so I'm having a hard time believing
that a utility so old and so widely used has such a fundamental bug,
but the evidence is staring me in the face and leads me to no
On Wed, 14 Sep 2022 11:12:25 +0100, Paul B Mahol wrote:
On 9/14/22, Dan wrote:
Using the latest 5.1.1 "essentials build" by www.gyan.dev.
Hi all, I'm a beginner to ffmpeg so I'm having a hard time believing that a
utility so old and so widely used has such a fundamental bug, but the
evidence
On 9/14/22, Dan wrote:
> Using the latest 5.1.1 "essentials build" by www.gyan.dev.
>
> Hi all, I'm a beginner to ffmpeg so I'm having a hard time believing that a
> utility so old and so widely used has such a fundamental bug, but the
> evidence is staring me in the face and leads me to no other
Using the latest 5.1.1 "essentials build" by www.gyan.dev.
Hi all, I'm a beginner to ffmpeg so I'm having a hard time believing that a
utility so old and so widely used has such a fundamental bug, but the evidence
is staring me in the face and leads me to no other conclusion.
It's incredibly e
47 matches
Mail list logo
