Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-06 Thread Andy Furniss

Jim Worrall wrote:



On 2016 Jan 5, at 6:06 PM, Andy Furniss  wrote:
I would double check your command line(s) - if they seem OK paste it/them along 
with the full output(s).


You are so right.  I had pass=1 twice (I’m going to hide under
a rock now).  Now I get:

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock stats-write
encoded 719 frames in 108.41s (6.63 fps), 3099.37 kb/s, Avg QP:24.68

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock stats-read
encoded 719 frames in 103.39s (6.95 fps), 2990.00 kb/s, Avg QP:24.61

Still getting ~the same time in both passes (this is preset ‘superfast’).


:-)

I guess superfast hides the gain of the first pass. I am not sure I
would want to encode with it using 3M ABR - which is quite low, but
then libx265 is quite slow.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-06 Thread Jim Worrall

> On 2016 Jan 6, at 4:04 AM, Andy Furniss  wrote:
> I guess superfast hides the gain of the first pass. I am not sure I
> would want to encode with it using 3M ABR - which is quite low, but
> then libx265 is quite slow.

Normally I use ‘medium', or now ‘slow' because I’ve got my NAS set up
with ffmpeg and just let it crank there in its own sweet time.  

I started with testing a range of bitrates at medium 2-pass from a bluray
source.  At least looking at the pngs, I found I couldn’t really see any 
clear improvement above 2 Mb/sec, so I chose 3.  I can’t distinguish it
from the source (except for the light/dark business in some cases).  
Do you think the ‘png test’ doesn’t give a good comparison?


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-06 Thread Andy Furniss

Jim Worrall wrote:



On 2016 Jan 6, at 4:04 AM, Andy Furniss 
wrote: I guess superfast hides the gain of the first pass. I am not
sure I would want to encode with it using 3M ABR - which is quite
low, but then libx265 is quite slow.


Normally I use ‘medium', or now ‘slow' because I’ve got my NAS set
up with ffmpeg and just let it crank there in its own sweet time.

I started with testing a range of bitrates at medium 2-pass from a
bluray source.  At least looking at the pngs, I found I couldn’t
really see any clear improvement above 2 Mb/sec, so I chose 3.  I
can’t distinguish it from the source (except for the light/dark
business in some cases). Do you think the ‘png test’ doesn’t give a
good comparison?


Fair enough. I can see that 3M was enough with default for the sample
you posted, but not much happens in that.

I was just thinking that 3M + superfast could be a bit low for high
action scenes with flying cameras etc. As you are not using superfast
anyway that concern does not apply.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Andy Furniss

Jim Worrall wrote:


Strange, unless there is something in the pngs that causes a
different viewer to produce different output.

I looked again (display from ancient imagemagic) and can't see any
difference - psnr/ssim agree.

The pngs are not the same md5sum wise


OK - you’re definitely getting way over my head, but you’re right, it
is strange.  My Mac OS viewers definitely show the three pngs as
different, although it is a bit subtle and you have to switch between
them in place to see it.

However, I opened them in Photoshop.  Here, master.png and
yuv-709.png look the same, and slightly brighter than yuv.png.

I ran the histogram in Photoshop and it shows master and yuv-709 as
identical, and with a bit higher luminosity than yuv as you
expected.

Somehow, the Mac OS viewer is seeing something that other viewers
don’t!

However I think you’ve found the solution with the colormatrix bt709
business.  That should fix it.  I’ll confirm and post again.
Thanks!


Should be that, the png is a different issue/feature - I don't know
what's correct or not. I guess you saw my other post that showed the
gamma difference. Whether you see it or not is going to be down to the
viewer/ICC/OS setup. I haven't got a clue which is correct - I mean we a
re likely seeing 709 on an srgb monitor so not the same as a 709  TV -
perhaps the "corrected" version is the correct one. Not that when
playing the movie you would be using a png viewer anyway. What you get
from players may be a bit pot luck! Even with the same player there can
be differences between output types (xv,vdpau,opengl).

If you really want playback colour perfection, mpv can do correction
using ICC profiles for different displays.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Jim Worrall

> On 2016 Jan 5, at 8:38 AM, Andy Furniss  wrote:
> 
> Should be that, the png is a different issue/feature - I don't know
> what's correct or not. I guess you saw my other post that showed the
> gamma difference. Whether you see it or not is going to be down to the
> viewer/ICC/OS setup. I haven't got a clue which is correct - I mean we a
> re likely seeing 709 on an srgb monitor so not the same as a 709  TV -
> perhaps the "corrected" version is the correct one. Not that when
> playing the movie you would be using a png viewer anyway. What you get
> from players may be a bit pot luck! Even with the same player there can
> be differences between output types (xv,vdpau,opengl).
> 
> If you really want playback colour perfection, mpv can do correction
> using ICC profiles for different displays.
> ___

I’m not really looking for perfection, just don’t want the transcodes to be
darker on any device.

So my testing has shown, for both libx264 and libx265, the problem is
solved (meaning the pngs come out with the same luminosity, which
is good enough for me) either of two ways, using ffmpeg options:

-color_primaries bt709 -color_trc bt709 -colorspace bt709

or using x264/5 params:

-x264-params colormatrix=bt709:colorprim=bt709:transfer=bt709

These alternatives are not quite parallel, I know.  Frankly I don’t
really understand them.  I’m guessing colormatrix is the only one
needed but haven’t tested.  In any case, it seems ffmpeg or libx26* needs
this direction.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Jim Worrall
> I’m not really looking for perfection, just don’t want the transcodes to be
> darker on any device.
> 
> So my testing has shown, for both libx264 and libx265, the problem is
> solved (meaning the pngs come out with the same luminosity, which
> is good enough for me) either of two ways, using ffmpeg options:
> 
> -color_primaries bt709 -color_trc bt709 -colorspace bt709
> 
> or using x264/5 params:
> 
> -x264-params colormatrix=bt709:colorprim=bt709:transfer=bt709
> 
> These alternatives are not quite parallel, I know.  Frankly I don’t
> really understand them.  I’m guessing colormatrix is the only one
> needed but haven’t tested.  In any case, it seems ffmpeg or libx26* needs
> this direction.
> 
Well I’m really confused now.  When I went back to the full source
file (rather than the 1 minute clipped from  it, which was a
stream copy), the transcode with x265-params came out BRIGHTER
than the source.  My head’s about to explode.  I’m just going
to stick with this result.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Andy Furniss

Carl Eugen Hoyos wrote:

Andy Furniss  gmail.com> writes:


I think it's because the master is flagged as rec709 but the yuv
and I guess hevc aren't.


While this is at least likely (sorry for my original comment, I don't
know what I looked at), the source code seems to disagree:
colour_primaries etc. are read from both h264 and hevc files and are
written both when encoding with libx264 and libx265. You could test
to set them with the following: -color_primaries bt709 -color_trc
bt709 -colorspace bt709 (with a faster preset), it shouldn't make a
difference but who knows...

And please also test with -vcodec x264, Carl Eugen


With Jims command line neither libx264 or libx265 pass through the 709
(it's not shown by ffmpeg -i ...).

With the three options above both do show 709.

Haven't had time to think more about the png "issue" yet ie. why does
ffmpeg (seem to) make pngs with two gamma values coded in when the
source is 709 flagged (but not from yuv when 709 is stated as
in_color_matrix).
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Andy Furniss

Jim Worrall wrote:

I’m not really looking for perfection, just don’t want the transcodes to be
darker on any device.

So my testing has shown, for both libx264 and libx265, the problem is
solved (meaning the pngs come out with the same luminosity, which
is good enough for me) either of two ways, using ffmpeg options:

-color_primaries bt709 -color_trc bt709 -colorspace bt709

or using x264/5 params:

-x264-params colormatrix=bt709:colorprim=bt709:transfer=bt709

These alternatives are not quite parallel, I know.  Frankly I don’t
really understand them.  I’m guessing colormatrix is the only one
needed but haven’t tested.  In any case, it seems ffmpeg or libx26* needs
this direction.


Well I’m really confused now.  When I went back to the full source
file (rather than the 1 minute clipped from  it, which was a
stream copy), the transcode with x265-params came out BRIGHTER
than the source.  My head’s about to explode.  I’m just going
to stick with this result.


Ouch, did the new file show as 709 with

ffmpeg -i newfile.mkv

I can't reproduce this one myself x265-params seems to work.
If for some reason the newfile didn't get flagged as 709 then it could 
be possible to get brighter with different colours in a scene.



___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Jim Worrall
> 
> Ouch, did the new file show as 709 with
> 
> ffmpeg -i newfile.mkv
> 
> I can't reproduce this one myself x265-params seems to work.
> If for some reason the newfile didn't get flagged as 709 then it could be 
> possible to get brighter with different colours in a scene.

Yes.  The ORIGINAL source file gives
Stream #0:0(eng): Video: h264 (High), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 
23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc

The transcode with the x265-params gives
Stream #0:0(eng): Video: hevc (Main), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 
DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

Could the problem be that the input is not recognized as bt709, even though it 
is?
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Jim Worrall
> Yes, that's probably it.
> 
> Maybe you could try below to see if the original shows 709 -
> 
> ffmpeg -analyzeduration 100M -probesize 100M -i original.m2ts
> 
> FWIW I just noticed another issue - using pass 1 and pass 2 via ffmpeg 
> doesn't work for libx265.
> 
> It does work if you use it via -x265-params pass=

No, the original m2ts with the analyze/probe options gives
Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 
1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc

So is it possible to use the -colormatrix and other color options 
as input options?  Is that what I should be doing?  Incidentally, 
those don’t seem to be in the documentation at all.

pass has been working for me - maybe they fixed that in x265 v. 1.8?
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Jim Worrall

> On 2016 Jan 5, at 3:13 PM, Jim Worrall  wrote:
> 
>> Currently I just get an empty ffmpeg2pass-0.log and pass 1 is as slow as 
>> pass 2. As expected he result is worse as well.
>> 
> Uh-oh, I thought that’s what was supposed to happen (except for the worse 
> result part).  I thought libx264 worked that way.  I better try it the other 
> way!

I just tested doing pass both ways.  It is true that ffmpeg’s log appears to 
remain empty, while x265’s does not.  But the output is identical as near as I 
can tell, and putting pass as an ffmpeg option was actually slightly faster 
(both passes about the same speed as opposed to pass 1 being a bit slower via 
x265-params.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Andy Furniss

Jim Worrall wrote:

Yes, that's probably it.

Maybe you could try below to see if the original shows 709 -

ffmpeg -analyzeduration 100M -probesize 100M -i original.m2ts

FWIW I just noticed another issue - using pass 1 and pass 2 via ffmpeg doesn't 
work for libx265.

It does work if you use it via -x265-params pass=


No, the original m2ts with the analyze/probe options gives
 Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 
1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc


Oh, I hadn't noticed that before - it's the same if I test my own m2ts 
files.




So is it possible to use the -colormatrix and other color options
as input options?  Is that what I should be doing?  Incidentally,
those don’t seem to be in the documentation at all.


For the transcode they should be OK as output options - AFAIK all they 
do is set some metadata.


For making a png from the input they do seem to work as input options.

They do show in ffmpeg -h full.


pass has been working for me - maybe they fixed that in x265 v. 1.8?


I'll have to try that - I was using some old Hg now on new Hg (not 
videolans as that doesn't seem to get updated anymore).


Currently I just get an empty ffmpeg2pass-0.log and pass 1 is as slow as 
pass 2. As expected he result is worse as well.



___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Jim Worrall

> On 2016 Jan 5, at 5:17 PM, Andy Furniss  wrote:
> I snipped some other "evidence" in my last post.
> 
> If you want to check outputs between the two ways look at the last
> lines of the larger block of x265 [info].
> 
> with ffmpeg the last 2 lines of both pass 1 and 2 are the same for me -
> 
> x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing
> x265 [info]: tools: deblock sao
> 
> with x265-params they are different and refer to reading/writing stats.
> 
> x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
> x265 [info]: tools: strong-intra-smoothing deblock sao stats-write
> 
> 
> x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing
> x265 [info]: tools: deblock sao stats-read
> 

OK, something’s wrong with my setup then.  When I put pass into 
x265-params, I get the same thing in both passes, with stats-write
both times:

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock stats-write

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock stats-write

What could be going on?
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Andy Furniss

Jim Worrall wrote:



On 2016 Jan 5, at 5:17 PM, Andy Furniss  wrote:
I snipped some other "evidence" in my last post.

If you want to check outputs between the two ways look at the last
lines of the larger block of x265 [info].

with ffmpeg the last 2 lines of both pass 1 and 2 are the same for me -

x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing
x265 [info]: tools: deblock sao

with x265-params they are different and refer to reading/writing stats.

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock sao stats-write


x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing
x265 [info]: tools: deblock sao stats-read



OK, something’s wrong with my setup then.  When I put pass into
x265-params, I get the same thing in both passes, with stats-write
both times:

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock stats-write

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock stats-write

What could be going on?


I would double check your command line(s) - if they seem OK paste 
it/them along with the full output(s).



___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Jim Worrall

> On 2016 Jan 5, at 6:06 PM, Andy Furniss  wrote:
> I would double check your command line(s) - if they seem OK paste it/them 
> along with the full output(s).
> 
You are so right.  I had pass=1 twice (I’m going to hide under
a rock now).  Now I get:

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock stats-write
encoded 719 frames in 108.41s (6.63 fps), 3099.37 kb/s, Avg QP:24.68

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock stats-read
encoded 719 frames in 103.39s (6.95 fps), 2990.00 kb/s, Avg QP:24.61

Still getting ~the same time in both passes (this is preset ‘superfast’).

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Andy Furniss

Jim Worrall wrote:



On 2016 Jan 5, at 4:28 PM, Andy Furniss  wrote:

Jim Worrall wrote:



On 2016 Jan 5, at 3:13 PM, Jim Worrall 
wrote:


Currently I just get an empty ffmpeg2pass-0.log and pass 1 is as
slow as pass 2. As expected he result is worse as well.


Uh-oh, I thought that’s what was supposed to happen (except for the
worse result part).  I thought libx264 worked that way.  I better
try it the other way!


I just tested doing pass both ways.  It is true that ffmpeg’s log
appears to remain empty, while x265’s does not.  But the output is
identical as near as I can tell, and putting pass as an ffmpeg option
was actually slightly faster (both passes about the same speed as
opposed to pass 1 being a bit slower via x265-params.


Hmm I just tried release x265 and with ffmpeg both my passes were the
same time, with x265-parans pass 1 was twice as fast. Quality was a bit
better min psnr wise with x265. Visually I could only really tell on the
first 10 frames - it seemed much the same after that. stats below show
that more was spent on I frames with x265-params.


OK, I bow to your greater knowledge and experience, and will start
using ‘pass’ in x265-params.  Thank you!


I snipped some other "evidence" in my last post.

If you want to check outputs between the two ways look at the last
lines of the larger block of x265 [info].

with ffmpeg the last 2 lines of both pass 1 and 2 are the same for me -

x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing
x265 [info]: tools: deblock sao

with x265-params they are different and refer to reading/writing stats.

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock sao stats-write


x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing
x265 [info]: tools: deblock sao stats-read

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Andy Furniss

Jim Worrall wrote:


Ouch, did the new file show as 709 with

ffmpeg -i newfile.mkv

I can't reproduce this one myself x265-params seems to work.
If for some reason the newfile didn't get flagged as 709 then it could be 
possible to get brighter with different colours in a scene.


Yes.  The ORIGINAL source file gives
Stream #0:0(eng): Video: h264 (High), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 
23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc

The transcode with the x265-params gives
Stream #0:0(eng): Video: hevc (Main), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 
DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

Could the problem be that the input is not recognized as bt709, even though it 
is?


Yes, that's probably it.

Maybe you could try below to see if the original shows 709 -

ffmpeg -analyzeduration 100M -probesize 100M -i original.m2ts

FWIW I just noticed another issue - using pass 1 and pass 2 via ffmpeg 
doesn't work for libx265.


It does work if you use it via -x265-params pass=


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Jim Worrall

> On 2016 Jan 5, at 4:28 PM, Andy Furniss  wrote:
> 
> Jim Worrall wrote:
>> 
>>> On 2016 Jan 5, at 3:13 PM, Jim Worrall 
>>> wrote:
>>> 
 Currently I just get an empty ffmpeg2pass-0.log and pass 1 is as
 slow as pass 2. As expected he result is worse as well.
 
>>> Uh-oh, I thought that’s what was supposed to happen (except for the
>>> worse result part).  I thought libx264 worked that way.  I better
>>> try it the other way!
>> 
>> I just tested doing pass both ways.  It is true that ffmpeg’s log
>> appears to remain empty, while x265’s does not.  But the output is
>> identical as near as I can tell, and putting pass as an ffmpeg option
>> was actually slightly faster (both passes about the same speed as
>> opposed to pass 1 being a bit slower via x265-params.
> 
> Hmm I just tried release x265 and with ffmpeg both my passes were the
> same time, with x265-parans pass 1 was twice as fast. Quality was a bit
> better min psnr wise with x265. Visually I could only really tell on the
> first 10 frames - it seemed much the same after that. stats below show
> that more was spent on I frames with x265-params.

OK, I bow to your greater knowledge and experience, and will start
using ‘pass’ in x265-params.  Thank you!
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-05 Thread Andy Furniss

Jim Worrall wrote:



On 2016 Jan 5, at 3:13 PM, Jim Worrall 
wrote:


Currently I just get an empty ffmpeg2pass-0.log and pass 1 is as
slow as pass 2. As expected he result is worse as well.


Uh-oh, I thought that’s what was supposed to happen (except for the
worse result part).  I thought libx264 worked that way.  I better
try it the other way!


I just tested doing pass both ways.  It is true that ffmpeg’s log
appears to remain empty, while x265’s does not.  But the output is
identical as near as I can tell, and putting pass as an ffmpeg option
was actually slightly faster (both passes about the same speed as
opposed to pass 1 being a bit slower via x265-params.


Hmm I just tried release x265 and with ffmpeg both my passes were the
same time, with x265-parans pass 1 was twice as fast. Quality was a bit
better min psnr wise with x265. Visually I could only really tell on the
first 10 frames - it seemed much the same after that. stats below show
that more was spent on I frames with x265-params.


ffmpeg pass 1

frame= 1461 fps=2.8 q=-0.0 Lsize=   22424kB time=00:01:00.85 
bitrate=3018.8kbits/s speed=0.116x
video:22412kB audio:0kB subtitle:0kB other streams:0kB global 
headers:1kB muxing overhead: 0.056528%

x265 [info]: frame I:  9, Avg QP:16.66  kb/s: 31133.07
x265 [info]: frame P:331, Avg QP:17.87  kb/s: 9346.73
x265 [info]: frame B:   1121, Avg QP:22.43  kb/s: 916.00
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 2.1% 0.3% 26.5% 8.2% 62.9%

encoded 1461 frames in 523.55s (2.79 fps), 3012.18 kb/s, Avg QP:21.36

ffmpeg pass 2

frame= 1461 fps=2.8 q=-0.0 Lsize=   23468kB time=00:01:00.85 
bitrate=3159.2kbits/s speed=0.116x
video:22412kB audio:1024kB subtitle:0kB other streams:0kB global 
headers:1kB muxing overhead: 0.137361%

x265 [info]: frame I:  9, Avg QP:16.66  kb/s: 31133.07
x265 [info]: frame P:331, Avg QP:17.87  kb/s: 9346.73
x265 [info]: frame B:   1121, Avg QP:22.43  kb/s: 916.00
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 2.1% 0.3% 26.5% 8.2% 62.9%

encoded 1461 frames in 523.83s (2.79 fps), 3012.18 kb/s, Avg QP:21.36

x265 pass 1

frame= 1461 fps=6.0 q=-0.0 Lsize=   22471kB time=00:01:00.85 
bitrate=3025.0kbits/s speed=0.248x
video:22458kB audio:0kB subtitle:0kB other streams:0kB global 
headers:1kB muxing overhead: 0.056320%

x265 [info]: frame I:  9, Avg QP:16.61  kb/s: 30834.66
x265 [info]: frame P:331, Avg QP:17.90  kb/s: 9711.25
x265 [info]: frame B:   1121, Avg QP:22.56  kb/s: 818.87
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 2.1% 0.3% 26.5% 8.2% 62.9%

encoded 1461 frames in 245.17s (5.96 fps), 3018.40 kb/s, Avg QP:21.47

x265 pass 2

frame= 1461 fps=2.9 q=-0.0 Lsize=   23364kB time=00:01:00.85 
bitrate=3145.3kbits/s speed=0.122x
video:22308kB audio:1024kB subtitle:0kB other streams:0kB global 
headers:1kB muxing overhead: 0.137916%

x265 [info]: frame I:  9, Avg QP:14.11  kb/s: 38589.83
x265 [info]: frame P:331, Avg QP:17.94  kb/s: 9318.05
x265 [info]: frame B:   1121, Avg QP:22.52  kb/s: 846.47
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 2.1% 0.3% 26.5% 8.2% 62.9%

encoded 1461 frames in 500.53s (2.92 fps), 2998.27 kb/s, Avg QP:21.43
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-04 Thread Jim Worrall

> On 2016 Jan 4, at 1:33 PM, Carl Eugen Hoyos  wrote:
> 
> How did you produce the screenshots?
ffmpeg -i in.mkv -vf fps=1/6 %03din.png
> 
> I do see that one of the png files you uploaded 
> is lighter but when I look at the 91st frame of 
> the file you uploaded, it is darker here with 
> MPlayer, vlc and FFplay (and when I transcode it).
> 
> Or to say it differently: How do you know it is 
> supposed to be lighter?
Sorry, I don’t quite understand.  The screenshots from
the source are brighter than those from the transcode.
That’s why I think the transcode should be brighter.

The video I uploaded is the source - the bright one -
so if it looks darker to you than the bright png, maybe
I’m doing something wrong.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-04 Thread Carl Eugen Hoyos
Jim Worrall  gmail.com> writes:

> Unfortunately I can’t attach the screenshots here, 
> but here are links to them:

How did you produce the screenshots?

I do see that one of the png files you uploaded 
is lighter but when I look at the 91st frame of 
the file you uploaded, it is darker here with 
MPlayer, vlc and FFplay (and when I transcode it).

Or to say it differently: How do you know it is 
supposed to be lighter?

Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-04 Thread Jim Worrall
> 
> Strange, unless there is something in the pngs that causes a different viewer 
> to produce different output.
> 
> I looked again (display from ancient imagemagic) and can't see any difference 
> - psnr/ssim agree.
> 
> The pngs are not the same md5sum wise

OK - you’re definitely getting way over my head, but you’re right,
it is strange.  My Mac OS viewers definitely show the three pngs
as different, although it is a bit subtle and you have to switch
between them in place to see it.

However, I opened them in Photoshop.  Here, master.png and
yuv-709.png look the same, and slightly brighter than yuv.png.

I ran the histogram in Photoshop and it shows master and yuv-709
as identical, and with a bit higher luminosity than yuv as you
expected.

Somehow, the Mac OS viewer is seeing something that other viewers don’t!

However I think you’ve found the solution with the colormatrix bt709
business.  That should fix it.  I’ll confirm and post again.  Thanks!
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-04 Thread Andy Furniss

Jim Worrall wrote:


It seems ffmpeg swscale/png honors the 709 for the master.

testing -

ffmpeg -i in.mkv -vframes 1  frame1-master.png

ffmpeg -i in.mkv -vframes 1  -vcodec rawvideo -f rawvideo frame1-master.yuv

ffmpeg -f rawvideo -pix_fmt yuv420p -s 1920x1080 -i frame1-master.yuv 
frame1-yuv.png

and frame1-yuv.png is darker than frame1-master.png

do

ffmpeg -f rawvideo -pix_fmt yuv420p -s 1920x1080 -i frame1-master.yuv -vf 
scale=in_color_matrix=bt709  frame1-yuv-709.png

and frame1-yuv-709.png visually (but not md5sum) matches frame1-master.png


I’m not sure if you’ve already done this, or you’re predicting.
In any case, you’re not going to like the result.
frame1-yuv-709.png is actually intermediate in darkness to the other two,
but closer to frame1-yuv.png.


Strange, unless there is something in the pngs that causes a different 
viewer to produce different output.


I looked again (display from ancient imagemagic) and can't see any 
difference - psnr/ssim agree.


The pngs are not the same md5sum wise

md5sum frame1-yuv-709.png frame1-master.png
1c086ed015ebe05aa1cfc66d9fe754a3  frame1-yuv-709.png
91ab580b1db4361fcceadaffd24930bd  frame1-master.png

below 709 compared to master followed by "default" vs master.

ffmpeg -i frame1-yuv-709.png -i frame1-master.png -lavfi 
"ssim;[0:v][1:v]psnr" -f null -
ffmpeg version N-77624-gf00e12e Copyright (c) 2000-2015 the FFmpeg 
developers

  built with gcc 4.9.2 (GCC)
  configuration: --prefix=/usr --disable-doc --enable-gpl 
--enable-libvpx --enable-libschroedinger --enable-libx265 
--enable-libdcadec --enable-libmp3lame --enable-libfdk-aac 
--enable-nonfree --enable-libx264

  libavutil  55. 12.100 / 55. 12.100
  libavcodec 57. 21.100 / 57. 21.100
  libavformat57. 21.100 / 57. 21.100
  libavdevice57.  0.100 / 57.  0.100
  libavfilter 6. 22.100 /  6. 22.100
  libswscale  4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc54.  0.100 / 54.  0.100
Input #0, png_pipe, from 'frame1-yuv-709.png':
  Duration: N/A, bitrate: N/A
Stream #0:0: Video: png, rgb24(pc), 1920x1080, 25 tbr, 25 tbn, 25 tbc
Input #1, png_pipe, from 'frame1-master.png':
  Duration: N/A, bitrate: N/A
Stream #1:0: Video: png, rgb24(pc), 1920x1080 [SAR 1:1 DAR 16:9], 
25 tbr, 25 tbn, 25 tbc

Output #0, null, to 'pipe:':
  Metadata:
encoder : Lavf57.21.100
Stream #0:0: Video: wrapped_avframe, gbrp, 1920x1080, q=2-31, 200 
kb/s, 25 fps, 25 tbn, 25 tbc

Metadata:
  encoder : Lavc57.21.100 wrapped_avframe
Stream #0:1: Video: wrapped_avframe, gbrp, 1920x1080, q=2-31, 200 
kb/s, 25 fps, 25 tbn, 25 tbc

Metadata:
  encoder : Lavc57.21.100 wrapped_avframe
Stream mapping:
  Stream #0:0 (png) -> ssim:main
  Stream #0:0 (png) -> psnr:main
  Stream #1:0 (png) -> ssim:reference
  Stream #1:0 (png) -> psnr:reference
  ssim -> Stream #0:0 (wrapped_avframe)
  psnr -> Stream #0:1 (wrapped_avframe)
Press [q] to stop, [?] for help
frame=1 fps=0.0 q=-0.0 Lq=-0.0 size=N/A time=00:00:00.04 bitrate=N/A 
speed=0.201x
video:1kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: unknown
[Parsed_ssim_0 @ 0x1f93340] SSIM R:1.00 (inf) G:1.00 (inf) 
B:1.00 (inf) All:1.00 (inf)
[Parsed_psnr_1 @ 0x1f9f280] PSNR r:inf g:inf b:inf average:inf min:inf 
max:inf



ffmpeg -i frame1-yuv.png -i frame1-master.png -lavfi 
"ssim;[0:v][1:v]psnr" -f null -
ffmpeg version N-77624-gf00e12e Copyright (c) 2000-2015 the FFmpeg 
developers

  built with gcc 4.9.2 (GCC)
  configuration: --prefix=/usr --disable-doc --enable-gpl 
--enable-libvpx --enable-libschroedinger --enable-libx265 
--enable-libdcadec --enable-libmp3lame --enable-libfdk-aac 
--enable-nonfree --enable-libx264

  libavutil  55. 12.100 / 55. 12.100
  libavcodec 57. 21.100 / 57. 21.100
  libavformat57. 21.100 / 57. 21.100
  libavdevice57.  0.100 / 57.  0.100
  libavfilter 6. 22.100 /  6. 22.100
  libswscale  4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc54.  0.100 / 54.  0.100
Input #0, png_pipe, from 'frame1-yuv.png':
  Duration: N/A, bitrate: N/A
Stream #0:0: Video: png, rgb24(pc), 1920x1080, 25 tbr, 25 tbn, 25 tbc
Input #1, png_pipe, from 'frame1-master.png':
  Duration: N/A, bitrate: N/A
Stream #1:0: Video: png, rgb24(pc), 1920x1080 [SAR 1:1 DAR 16:9], 
25 tbr, 25 tbn, 25 tbc

Output #0, null, to 'pipe:':
  Metadata:
encoder : Lavf57.21.100
Stream #0:0: Video: wrapped_avframe, gbrp, 1920x1080, q=2-31, 200 
kb/s, 25 fps, 25 tbn, 25 tbc

Metadata:
  encoder : Lavc57.21.100 wrapped_avframe
Stream #0:1: Video: wrapped_avframe, gbrp, 1920x1080, q=2-31, 200 
kb/s, 25 fps, 25 tbn, 25 tbc

Metadata:
  encoder : Lavc57.21.100 wrapped_avframe
Stream mapping:
  Stream #0:0 (png) -> ssim:main
  Stream #0:0 (png) -> psnr:main
  Stream #1:0 (png) -> ssim:reference
  Stream #1:0 (png) -> psnr:reference
  ssim -> 

Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-04 Thread Carl Eugen Hoyos
Andy Furniss  gmail.com> writes:

> I think it's because the master is flagged as rec709 
> but the yuv and I guess hevc aren't.

While this is at least likely (sorry for my original 
comment, I don't know what I looked at), the source 
code seems to disagree: colour_primaries etc. are 
read from both h264 and hevc files and are written 
both when encoding with libx264 and libx265.
You could test to set them with the following:
-color_primaries bt709 -color_trc bt709 -colorspace bt709
(with a faster preset), it shouldn't make a 
difference but who knows...

And please also test with -vcodec x264, Carl Eugen

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-04 Thread Andy Furniss

Jim Worrall wrote:



On 2016 Jan 4, at 1:33 PM, Carl Eugen Hoyos 
wrote:

How did you produce the screenshots?

ffmpeg -i in.mkv -vf fps=1/6 %03din.png


I do see that one of the png files you uploaded is lighter but when
I look at the 91st frame of the file you uploaded, it is darker
here with MPlayer, vlc and FFplay (and when I transcode it).

Or to say it differently: How do you know it is supposed to be
lighter?

Sorry, I don’t quite understand.  The screenshots from the source are
brighter than those from the transcode. That’s why I think the
transcode should be brighter.

The video I uploaded is the source - the bright one - so if it looks
darker to you than the bright png, maybe I’m doing something wrong.


I think it's because the master is flagged as rec709 but the yuv and I
guess hevc aren't.

Some players (not mplayer) would assume 709 for >= 720p so you wouldn't
notice with them.

It seems ffmpeg swscale/png honors the 709 for the master.

testing -

ffmpeg -i in.mkv -vframes 1  frame1-master.png

ffmpeg -i in.mkv -vframes 1  -vcodec rawvideo -f rawvideo frame1-master.yuv

ffmpeg -f rawvideo -pix_fmt yuv420p -s 1920x1080 -i frame1-master.yuv 
frame1-yuv.png


and frame1-yuv.png is darker than frame1-master.png

do

ffmpeg -f rawvideo -pix_fmt yuv420p -s 1920x1080 -i frame1-master.yuv 
-vf scale=in_color_matrix=bt709  frame1-yuv-709.png


and frame1-yuv-709.png visually (but not md5sum) matches frame1-master.png

so I guess you need to tell hevc that the video is rec709.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-04 Thread Jim Worrall

> On 2016 Jan 4, at 3:29 PM, Andy Furniss  wrote:
> I think it's because the master is flagged as rec709 but the yuv and I
> guess hevc aren’t.

Although my opinion is not worth much, I suspect you are onto it here.
> 
> Some players (not mplayer) would assume 709 for >= 720p so you wouldn't
> notice with them.
> 
> It seems ffmpeg swscale/png honors the 709 for the master.
> 
> testing -
> 
> ffmpeg -i in.mkv -vframes 1  frame1-master.png
> 
> ffmpeg -i in.mkv -vframes 1  -vcodec rawvideo -f rawvideo frame1-master.yuv
> 
> ffmpeg -f rawvideo -pix_fmt yuv420p -s 1920x1080 -i frame1-master.yuv 
> frame1-yuv.png
> 
> and frame1-yuv.png is darker than frame1-master.png
> 
> do
> 
> ffmpeg -f rawvideo -pix_fmt yuv420p -s 1920x1080 -i frame1-master.yuv -vf 
> scale=in_color_matrix=bt709  frame1-yuv-709.png
> 
> and frame1-yuv-709.png visually (but not md5sum) matches frame1-master.png

I’m not sure if you’ve already done this, or you’re predicting.  
In any case, you’re not going to like the result.   
frame1-yuv-709.png is actually intermediate in darkness to the other two,
but closer to frame1-yuv.png.

However, I should add that the x265 guy, Ma0, went ahead and transcoded my 
minute of video
with what I think would be this, and got no difference in darkness:

ffmpeg -i min_source.mkv -f yuv4mpegpipe - | x265 --y4m - --preset placebo 
--subme 7 --merange 121 --deblock -1 --rdoq-level 1 --colormatrix bt709 
--bitrate 3000 --pass 1 -o slow.hevc && \
ffmpeg -i min_source.mkv -f yuv4mpegpipe - | x265 --y4m - --preset placebo 
--subme 7 --merange 121 --deblock -1 --rdoq-level 1 --colormatrix bt709 
--bitrate 3000 --pass 2 -o slow.hevc

Aside from the insane settings (my computer is doing this at 0.1 fps!!), note 
the --colormatrix bt709 - 
I’m guessing that was the key.  Not sure why it comes out intermediate in your 
test - probably
because it is already darkened during the conversion to yuv, but not in the 
above?

I will test this further when my processor allows.  In the meantime, thanks
very much to Andy and Carl for taking the time to look at this.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-04 Thread Andy Furniss

Andy Furniss wrote:

Andy Furniss wrote:


Strange, unless there is something in the pngs that causes a
different viewer to produce different output.

I looked again (display from ancient imagemagic) and can't see any
difference - psnr/ssim agree.

The pngs are not the same md5sum wise

md5sum frame1-yuv-709.png frame1-master.png
1c086ed015ebe05aa1cfc66d9fe754a3  frame1-yuv-709.png
91ab580b1db4361fcceadaffd24930bd  frame1-master.png


The obvious difference between the pngs is master is bigger by 60 bytes
and it has extra info in it, I can see with ffmpeg -i ... that SAR and
DAR are shown - nothing about 709 but maybe that's in there as well?

I tried making another png from yuv using out_color_matrix as well as
in_color_matrix, but it produced the same file (md5sum) as just
in_color_matrix.



I found the difference using identify from  ImageMagick - I don't know 
why display doesn't seem to show it for me but ...


identify -verbose frame1-yuv-709.png > idout-709
identify -verbose frame1-master.png > idout-master
diff idout-master idout-709
1c1
< Image: frame1-master.png
---
> Image: frame1-yuv-709.png
5,6d4
<   Resolution: 1x1
<   Print size: 1920x1080
47c45
<   Gamma: 0.50994
---
>   Gamma: 0.454545
65,68c63,64
< date:create: 2016-01-04T21:52:55+00:00
< date:modify: 2016-01-04T21:52:55+00:00
< png:cHRM : chunk was found (see Chromaticity, above)
< png:gAMA : gamma=0.45454544 (See Gamma, above)
---
> date:create: 2016-01-04T22:04:11+00:00
> date:modify: 2016-01-04T22:04:11+00:00
73c69
< png:pHYs : x_res=1, y_res=1, units=0
---
> png:pHYs : x_res=0, y_res=1, units=0
76c72
< filename: frame1-master.png
---
> filename: frame1-yuv-709.png
82,83c78,79
<   User time: 0.050u
<   Elapsed time: 0:01.060
---
>   User time: 0.060u
>   Elapsed time: 0:01.059

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user


Re: [FFmpeg-user] ffmpeg makes some sources darker

2016-01-04 Thread Jim Worrall

> On 2016 Jan 4, at 5:11 PM, Carl Eugen Hoyos  wrote:
> 
> You could test to set them with the following:
> -color_primaries bt709 -color_trc bt709 -colorspace bt709
> (with a faster preset), it shouldn't make a 
> difference but who knows...
> 
> And please also test with -vcodec x264, Carl Eugen

Just so I don’t spend time testing the wrong way, you’re suggesting a test of 
transcoding with libx264 with and without those three color options,
then comparing a screenshot as before?

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user