Re: [FFmpeg-user] ffmpeg makes some sources darker
Jim Worrall wrote: On 2016 Jan 5, at 6:06 PM, Andy Furnisswrote: 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
> On 2016 Jan 6, at 4:04 AM, Andy Furnisswrote: > 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
Jim Worrall wrote: On 2016 Jan 6, at 4:04 AM, Andy Furnisswrote: 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
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
> On 2016 Jan 5, at 8:38 AM, Andy Furnisswrote: > > 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
> 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
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
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
> > 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
> 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
> On 2016 Jan 5, at 3:13 PM, Jim Worrallwrote: > >> 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
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
> On 2016 Jan 5, at 5:17 PM, Andy Furnisswrote: > 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
Jim Worrall wrote: On 2016 Jan 5, at 5:17 PM, Andy Furnisswrote: 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
> On 2016 Jan 5, at 6:06 PM, Andy Furnisswrote: > 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
Jim Worrall wrote: On 2016 Jan 5, at 4:28 PM, Andy Furnisswrote: 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
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
> On 2016 Jan 5, at 4:28 PM, Andy Furnisswrote: > > 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
Jim Worrall wrote: On 2016 Jan 5, at 3:13 PM, Jim Worrallwrote: 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
> On 2016 Jan 4, at 1:33 PM, Carl Eugen Hoyoswrote: > > 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
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
> > 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
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
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
Jim Worrall wrote: On 2016 Jan 4, at 1:33 PM, Carl Eugen Hoyoswrote: 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
> On 2016 Jan 4, at 3:29 PM, Andy Furnisswrote: > 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
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
> On 2016 Jan 4, at 5:11 PM, Carl Eugen Hoyoswrote: > > 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