h264 videos are darker
Hello, I'm recording streaming videos from a camera, using ffmpeg. The video stream is 8bit 658x492 grey and the frame rate is 30-60 fps. Individual frames are fed to a pipe on which ffmpeg is listening. The pipeline works very reliably. My command looks like this: ffmpeg.exe -y -hide_banner -vcodec rawvideo -f rawvideo -r 30 -s 658x492 -pix_fmt gray -i \\.\pipe\DEV_000F315BEBB8<file://./pipe/DEV_000F315BEBB8> -r 30 -c:v libx264 -preset veryfast -crf 5 x:\\Videos\output.avi The images are also displayed on the screen. When comparing the screen images with the resulting movie, dark areas are darker in the resulting video, especially at a higher frame rate. As these are scientific videos, we are striving to get as good quality/compression ratio of the output as possible. Is there any other flags to consider in the above command in order to get as close to 'real' result as possible? Any other compression algorithm working better for this? Best Regards, Totte Karlsson - totte.karlsson@alleninstitute.org<mailto:totte.karlsson@alleninstitute.org> Senior Software Engineer - MPE 210B-35
Am 06.02.2020 um 20:24 schrieb Totte Karlsson <totte.karlsson@alleninstitute.org>:
ffmpeg.exe -y -hide_banner -vcodec rawvideo -f rawvideo -r 30 -s 658x492 -pix_fmt gray -i \\.\pipe\DEV_000F315BEBB8<file://./pipe/DEV_000F315BEBB8> -r 30 -c:v libx264 -preset veryfast -crf 5 x:\\Videos\output.avi
Please test current FFmpeg git head, remove hide_banner from your command line and provide the command line together with the complete, uncut console output. The output option “r 30” is unneeded and to answer your question: The semantic of “gray” is not fixed in the multimedia domain (but that shouldn’t rule out a bug, see above). Carl Eugen
Hello, Regarding h264 videos being dark:
Please test current FFmpeg git head, remove hide_banner from your command line and provide the command line together with the complete, uncut console output.
The output option “r 30” is unneeded and to answer your question: The semantic of “gray” is not fixed in the multimedia domain (but that shouldn’t rule out a bug, see above).
I have removed the r 30 as suggested and downloaded the latest ffmpeg binaries from https://ffmpeg.zeranoe.com/builds/ The ffmpeg command and its output is shown below. Again, using the gray -pix_fmt results in videos being slightly 'darker' than the original. This can be seen on image areas that are going from having light and dark-to-black areas, like a rock wall for example. I am using VLC for viewing, but also checked with MPlayer, observing the same. As the input data is 8bit, just giving the intensity of each pixel, I tried other ffmpeg's -pix_fmt's being 8bit. If I use any of the 'bayer' ones; bayer_bggr8 bayer_rggb8 bayer_gbrg8 bayer_grbg8 the result seem much better. In fact, I can't see any difference in the resulting video from using any of those formats, and no difference among them either. Question is, for someone (like me), with little video compression experience, would using one of the "bayer" pixel formats be considered common practice, or reasonable, for a 8bit input video stream? Reason I'm asking is because the resulting videos will be analyzed by machine learning algorithms and so we can't easily change parameters later on, as we are about to create a large data training set. Here is the command and output: ffmpeg.exe -y -vcodec rawvideo -f rawvideo -r 23 -s 658x492 -pix_fmt gray -i \\.\pipe\DEV_000F315BEBB8 -c:v libx264 -crf 23 x:\videos\Box_1_2020T140206.avi ffmpeg version git-2020-02-11-f15007a Copyright (c) 2000-2020 the FFmpeg developers built with gcc 9.2.1 (GCC) 20200122 configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt --enable-amf libavutil 56. 39.100 / 56. 39.100 libavcodec 58. 68.102 / 58. 68.102 libavformat 58. 38.100 / 58. 38.100 libavdevice 58. 9.103 / 58. 9.103 libavfilter 7. 75.100 / 7. 75.100 libswscale 5. 6.100 / 5. 6.100 libswresample 3. 6.100 / 3. 6.100 libpostproc 55. 6.100 / 55. 6.100 Input #0, rawvideo, from '\\.\pipe\DEV_000F315BEBB8': Duration: N/A, start: 0.000000, bitrate: 59567 kb/s Stream #0:0: Video: rawvideo (Y800 / 0x30303859), gray, 658x492, 59567 kb/s, 23 tbr, 23 tbn, 23 tbc Stream mapping: Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264)) Press [q] to stop, [?] for help [libx264 @ 00000111ed67f740] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 [libx264 @ 00000111ed67f740] profile High, level 3.0, 4:0:0, 8-bit Output #0, avi, to 'x:\videos\Box_1_2020T140206.avi': Metadata: ISFT : Lavf58.38.100 Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), gray, 658x492, q=-1--1, 23 fps, 23 tbn, 23 tbc Metadata: encoder : Lavc58.68.102 libx264 Side data: cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A frame= 15 fps=0.0 q=0.0 size= 6kB time=00:00:00.00 bitrate=N/A speed= 0x frame= 27 fps= 26 q=0.0 size= 6kB time=00:00:00.00 bitrate=N/A speed= 0x frame= 39 fps= 25 q=0.0 size= 6kB time=00:00:00.00 bitrate=N/A speed= 0x
Am Do., 13. Feb. 2020 um 23:45 Uhr schrieb Totte Karlsson <totte.karlsson@alleninstitute.org>:
ffmpeg.exe -y -vcodec rawvideo -f rawvideo -r 23 -s 658x492 -pix_fmt gray -i \\.\pipe\DEV_000F315BEBB8 -c:v libx264 -crf 23 x:\videos\Box_1_2020T140206.avi
What range does the input level have? mpeg or jpeg? And which application are you using to test the "darkness" of the output file? As I tried to explain earlier: gray can be both, it may be better if you choose yuv420p / yuvj420p for encoding to make sure the right range is selected. Carl Eugen
ffmpeg.exe -y -vcodec rawvideo -f rawvideo -r 23 -s 658x492 -pix_fmt gray -i \\.\pipe\DEV_000F315BEBB8 -c:v libx264 -crf 23 x:\videos\Box_1_2020T140206.avi
What range does the input level have? mpeg or jpeg?
Each input frame is a grayscale 8bit pixel buffer with a size of 658x492. There is no compression involved before sending the data to ffmpeg, as these grayscale frames is coming from a live streaming camera.
And which application are you using to test the "darkness" of the output file?
Right now we are just observing this by eye. It is pretty pronounced so it is easy to see.
As I tried to explain earlier: gray can be both, it may be better if you choose yuv420p / yuvj420p for encoding to make sure the right range is selected.
I tried both of those, but the resulting video is distorted with random colors flashing on the screen. Best Regards, -tk
I tried both of those, but the resulting video is distorted with random colors flashing on the screen.
Try them as the output pixel format not the input.
I tried both of those, but the resulting video is distorted with random colors flashing on the screen.
Try them as the output pixel format not the input.
Thanks for the response; I'm a little confused about "output pixel format", as I thought that the -pix_fmt flag is for that. The -pixel_format flag seem to be for the input. So question, what flag are you referring to? Is there another flag to be used for the 'output pixel format'? My ffmpeg command is: ffmpeg.exe -y -vcodec rawvideo -f rawvideo -r 23 -s 658x492 -pix_fmt gray -i \\.\pipe\DEV_000F315BEBB8 -c:v libx264 -crf 23 x:\videos\Box_1_2020T140206.avi and I have tried various format for the -pix_fmt flag. Gray kind of works, but problem is the push of dark-gray pixels into black, i.e. pixel intensities of 3-5ish -> 0. Best, -tk
Am Fr., 14. Feb. 2020 um 19:15 Uhr schrieb Totte Karlsson <totte.karlsson@alleninstitute.org>:
ffmpeg.exe -y -vcodec rawvideo -f rawvideo -r 23 -s 658x492 -pix_fmt gray -i \\.\pipe\DEV_000F315BEBB8 -c:v libx264 -crf 23 x:\videos\Box_1_2020T140206.avi
You can try the following: $ ffmpeg -f rawvideo -r 23 -s 658x492 -i pipe -vcodec libx264 -pix_fmt yuv420p -crf 23 output1... $ ffmpeg -f rawvideo -r 23 -s 658x492 -i pipe -vcodec libx264 -pix_fmt yuvj420p -crf 23 output2... Note that avi is generally not considered a good idea to store h264. Carl Eugen
You can try the following: $ ffmpeg -f rawvideo -r 23 -s 658x492 -i pipe -vcodec libx264 -pix_fmt yuv420p -crf 23 output1... $ ffmpeg -f rawvideo -r 23 -s 658x492 -i pipe -vcodec libx264 -pix_fmt yuvj420p -crf 23 output2...
I tried both yuv420p and yuvj420p as suggested, and both results in color flashing distorted videos.
Note that avi is generally not considered a good idea to store h264.
What is a considered good choice for storing h264? -tk
Carl Eugen _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmpeg.org... 2Fmailman%2Flistinfo%2Fffmpeg- user&data=02%7C01%7C%7C29e43fa588bd420463cd08d7b1f08dc3%7C326 69cd6737f4b398bddd6951120d3fc%7C0%7C0%7C637173519044136911&sd ata=%2FSpNsiFazsGRekYyY8wcwlPzp47T8hyRKbSv2qud3kk%3D&reserve d=0
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Am Mo., 24. Feb. 2020 um 21:06 Uhr schrieb Totte Karlsson <totte.karlsson@alleninstitute.org>:
You can try the following: $ ffmpeg -f rawvideo -r 23 -s 658x492 -i pipe -vcodec libx264 -pix_fmt yuv420p -crf 23 output1... $ ffmpeg -f rawvideo -r 23 -s 658x492 -i pipe -vcodec libx264 -pix_fmt yuvj420p -crf 23 output2...
I tried both yuv420p and yuvj420p as suggested, and both results in color flashing distorted videos.
Then please add -pix_fmt gray before "-i".
Note that avi is generally not considered a good idea to store h264.
What is a considered good choice for storing h264?
mkv, mov (and friends), mpegts Carl Eugen
I tried both yuv420p and yuvj420p as suggested, and both results in color flashing
distorted videos.
Then please add -pix_fmt gray before "-i".
That seemed to have fixed the issues! Using both "gray" on input and output seem to work nicely. Is there a reason/advantage to use "yuv420p" instead of "gray" for the output, for this 8bit input video? -tk
Am 25.02.2020 um 01:55 schrieb Totte Karlsson <totte.karlsson@alleninstitute.org>:
I tried both yuv420p and yuvj420p as suggested, and both results in color flashing distorted videos.
Then please add -pix_fmt gray before "-i".
That seemed to have fixed the issues! Using both "gray" on input and output seem to work nicely.
That sounds unlikely as this is the default behaviour / command line and complete, uncut console output missing. Carl Eugen
Thanks for the response; I'm a little confused about "output pixel format", as I thought that the -pix_fmt flag is for that. The -pixel_format flag seem to be for the input. So question, what flag are you referring to? Is there another flag to be used for the 'output pixel format’?
I think pixel_format is just a private option for some decoders that should be mapped to pix_fmt. pix_fmt is both an input and output option, so if you put it before the input it is an input option and if you put it before the output it is an output option.
On 17-02-2020 02:52 am, Ted Park wrote:
Thanks for the response; I'm a little confused about "output pixel format", as I thought that the -pix_fmt flag is for that. The -pixel_format flag seem to be for the input. So question, what flag are you referring to? Is there another flag to be used for the 'output pixel format’? I think pixel_format is just a private option for some decoders that should be mapped to pix_fmt. pix_fmt is both an input and output option, so if you put it before the input it is an input option and if you put it before the output it is an output option.
It's the other way around. -pix_fmt as input will be mapped to -pixel_format for the device/raw input demuxer if it exists. As an output option, it inserts a format filter at the end for that output stream. Gyan
participants (4)
-
Carl Eugen Hoyos -
Gyan Doshi -
Ted Park -
Totte Karlsson