Opened 4 weeks ago

Closed 4 weeks ago

Last modified 2 weeks ago

#7115 closed defect (invalid)

Image BECOMES darker unexpectedly

Reported by: testh001 Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Here is very simple demonstration of the bug:

ffmpeg -hide_banner -i 1.png -y 1.mp4

Input image "1.png":
https://user-images.githubusercontent.com/29530279/38143163-8e07b0e8-343f-11e8-8545-96c51e8e21e7.png

Output video "1.mp4" (has only one frame):
https://user-images.githubusercontent.com/29530279/38143164-8e25a846-343f-11e8-971b-69b4d0958fbc.png

Do you see what I am talking about? Image is darker, colors were changed. I tried to set different pixel formats, to set different presets, to change quality, bitrate, etc, but no matter what I try, the output is the same.

When will this bug be fixed? Thanks.

Change History (7)

comment:1 Changed 4 weeks ago by cehoyos

  • Keywords png mp4 raw yuv420p rgb24 rgb32 removed
  • Priority changed from important to normal
  • Resolution set to needs_more_info
  • Status changed from new to closed

comment:2 Changed 4 weeks ago by testh001

@cehoyos

Can you explain why is this ticket closed? You labeled it as "needs more info". I'll provide more info, but I don't see what is unclear. Input image is brighter, output if darker, if it is not a bug, then explain why. BTW, closing issue without leaving any comments explaining why it is closed is not good. I hope you will respond to this comment.

Thanks.

comment:3 Changed 4 weeks ago by cehoyos

  • Resolution changed from needs_more_info to worksforme

I am sorry: While this ticket is invalid because command line including complete, uncut console output is missing and because of the usage of -hide_banner in a ticket unrelated to this option, there is still enough information to test, note that using external resources for small input files is not welcome though.
I tested the following:

$ ffmpeg -i 38143163-8e07b0e8-343f-11e8-8545-96c51e8e21e7.png out.mp4
ffmpeg version N-90524-ge30a37e Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 6.3.0 (GCC)
  configuration: --enable-gpl
  libavutil      56. 12.100 / 56. 12.100
  libavcodec     58. 16.100 / 58. 16.100
  libavformat    58. 10.100 / 58. 10.100
  libavdevice    58.  2.100 / 58.  2.100
  libavfilter     7. 13.100 /  7. 13.100
  libswscale      5.  0.102 /  5.  0.102
  libswresample   3.  0.101 /  3.  0.101
  libpostproc    55.  0.100 / 55.  0.100
Input #0, png_pipe, from '38143163-8e07b0e8-343f-11e8-8545-96c51e8e21e7.png':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: png, rgb24(pc), 300x300 [SAR 3779:3779 DAR 1:1], 25 tbr, 25 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (png (native) -> mpeg4 (native))
Press [q] to stop, [?] for help
Output #0, mp4, to 'out.mp4':
  Metadata:
    encoder         : Lavf58.10.100
    Stream #0:0: Video: mpeg4 (mp4v / 0x7634706D), yuv420p, 300x300 [SAR 1:1 DAR 1:1], q=2-31, 200 kb/s, 25 fps, 12800 tbn, 25 tbc
    Metadata:
      encoder         : Lavc58.16.100 mpeg4
    Side data:
      cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1
frame=    1 fps=0.0 q=1.6 Lsize=       2kB time=00:00:00.00 bitrate=198461.5kbits/s speed=0.000438x
video:1kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 79.499069%

Input and output file look identical here.

comment:4 follow-up: Changed 4 weeks ago by testh001

@cehoyos

Thanks for the response. I was thinking that you had closed this because it is working as intended, but since you have said that the input and output is looking same for you, I suppose what I am experiencing is actually a bug.

Sorry for missing full output, I didn't know it is required, and sorry for -hide_banner command, I didn't know it is prohibited. I think the easiest way to demonstrate the issue is to attach screen recording. But I hadn't find a way to attach large videos in the ticket, so I made a video and posted to youtube, please take a look, I demonstrated the issue there: https://www.youtube.com/watch?v=2mY1M0yK0ck

To make this issue valid, as you said, I am attaching full output:

  built with gcc 7.3.0 (GCC)
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --e
nable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libblur
ay --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-
libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enab
le-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-li
bvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --en
able-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-
libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enabl
e-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enabl
e-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enab
le-dxva2 --enable-avisynth
  libavutil      56. 12.100 / 56. 12.100
  libavcodec     58. 16.100 / 58. 16.100
  libavformat    58. 10.100 / 58. 10.100
  libavdevice    58.  2.100 / 58.  2.100
  libavfilter     7. 13.100 /  7. 13.100
  libswscale      5.  0.102 /  5.  0.102
  libswresample   3.  0.101 /  3.  0.101
  libpostproc    55.  0.100 / 55.  0.100
Input #0, png_pipe, from '1.png':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: png, rgb24(pc), 1920x1080 [SAR 3779:3779 DAR 16:9], 25 t
br, 25 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (png (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[libx264 @ 000000592af5d580] using SAR=1/1
[libx264 @ 000000592af5d580] using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 S
SE4.2
[libx264 @ 000000592af5d580] profile High 4:4:4 Predictive, level 4.0, 4:4:4 8-b
it
[libx264 @ 000000592af5d580] 264 - core 155 r2901 7d0ff22 - H.264/MPEG-4 AVC cod
ec - Copyleft 2003-2018 - http://www.videolan.org/x264.html - options: cabac=1 r
ef=3 deblock=1:0:0 analyse=0x1:0x111 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed
_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11 fast_pski
p=1 chroma_qp_offset=4 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decim
ate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_a
dapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25
 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60
 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to '1.mp4':
  Metadata:
    encoder         : Lavf58.10.100
    Stream #0:0: Video: h264 (libx264) (avc1 / 0x31637661), yuv444p, 1920x1080 [
SAR 1:1 DAR 16:9], q=-1--1, 25 fps, 12800 tbn, 25 tbc
    Metadata:
      encoder         : Lavc58.16.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
frame=    1 fps=0.0 q=28.0 Lsize=       2kB time=00:00:00.00 bitrate=206666.7kbi
ts/s speed=0.000999x
video:1kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing ove
rhead: 68.196999%
[libx264 @ 000000592af5d580] frame I:1     Avg QP:13.00  size:   510
[libx264 @ 000000592af5d580] mb I  I16..4: 100.0%  0.0%  0.0%
[libx264 @ 000000592af5d580] coded y,u,v intra: 0.0% 0.0% 0.0%
[libx264 @ 000000592af5d580] i16 v,h,dc,p: 99%  0%  1%  0%
[libx264 @ 000000592af5d580] kb/s:102.00

Please take a look at the screen recording I posted and please tell me if I am doing anything wrong or is this a bug? And in case of the latter, please reopen the issue, if possible.

Thanks :)

Last edited 2 weeks ago by testh001 (previous) (diff)

comment:5 in reply to: ↑ 4 Changed 2 weeks ago by cehoyos

Replying to testh001:

I was thinking that you had closed this because it is working as intended, but since you have said that the input and output is looking same for you, I suppose what I am experiencing is actually a bug.

What are you experiencing?
It is good that you posted the console output (carefully comparing it with the output I posted will show you that it contained information that was essential to reproduce but originally missing) but you also have to explain with a few words what you did after the conversion: You write elsewhere play with any video player: At least with FFplay and MPlayer, I get the expected identical output. There may of course be a video driver issue on your end but this is impossible to judge with the available information.

I sincerely hope you understand highjacking unrelated tickets, opening a ticket just to complain or open a duplicate ticket will not help you here.

comment:6 Changed 2 weeks ago by testh001

@cehoyos

Weird. I tested with ffplay and colors are fine. My drivers are also fine, so maybe the problem is with the chrome, because I used it as a video player. I just reported a bug there, and I'm posting link here for reference:
https://bugs.chromium.org/p/chromium/issues/detail?id=830567

Thanks for explanations... And sorry if I was too annoying, but you know, this bug is annoying too.
Have a nice day :)

Last edited 2 weeks ago by testh001 (previous) (diff)

comment:7 Changed 2 weeks ago by cehoyos

  • Resolution changed from worksforme to invalid

Just for reference, there is also no issue with vlc and totem.

Note: See TracTickets for help on using tickets.