[Libav-user] Writing 16bit greyscale videos
Masneri, Stefano
stefano.masneri at brain.mpg.de
Wed Aug 31 10:13:50 EEST 2016
Hi, please see my comments inline
>-----Original Message-----
>From: Libav-user [mailto:libav-user-bounces at ffmpeg.org] On Behalf Of Carl Eugen Hoyos
>Sent: Dienstag, 30. August 2016 19:53
>To: This list is about using libavcodec, libavformat, libavutil, libavdevice and libavfilter.
>Subject: Re: [Libav-user] Writing 16bit greyscale videos
>
>Hi!
>
>2016-08-29 17:20 GMT+02:00 Masneri, Stefano <stefano.masneri at brain.mpg.de>:
>>>From: Libav-user [mailto:libav-user-bounces at ffmpeg.org] On Behalf Of
>>>Carl Eugen Hoyos
>>>>2016-08-29 10:59 GMT+02:00 Masneri, Stefano <stefano.masneri at brain.mpg.de>:
>
>>>> Do you know of a codec that supports encoding a video using
>>>> AV_PIX_FMT_GRAY16BE pixel format (or anything similar)?
>>>
>>> jpegls, png, tiff, dpx, sgi, ffvhuff, ffv1 (all lossless) Jpeg2000,
>>> but FFmpeg needs the external library libopenjpeg for encoding
>>> gray16 (lossy or lossless)
>>
>> Thanks Carl. I am able to create the video with 16 bit greyscale
>> images,
>
>> but when I try watching the video in VLC I only see a green image.
>
>Do you think this is an issue that can be fixed within FFmpeg?
To be honest I have no idea. I have never had the need to create 16bit videos before
>
>> Reading the frames one by one (with a simple class which uses FFmpeg)
>> I see a strange behaviour: every second column of the video is zero,
>> while the other are exactly as the input fed to the class that created the video.
>
>Is this issue reproducible with ffmpeg (the application)?
I tried creating the video using ffmpeg and I still get a greenish video. Here's the command line output:
D:\ testFiles>ffmpeg -i test%d.tif -vcodec ffv1 -b:v 2M -r 10 test.avi
ffmpeg version 2.8.4 Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.2.0 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gn
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libgme --enable-libgsm
ibilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-l
able-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-lib
--enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable
ble-decklink --enable-zlib
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 60.100 / 56. 60.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 40.101 / 5. 40.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
Input #0, image2, from 'test%d.tif':
Duration: 00:00:05.32, start: 0.000000, bitrate: N/A
Stream #0:0: Video: tiff, gray16le, 124x128, 25 fps, 25 tbr, 25 tbn, 25 tbc
File 'test.avi' already exists. Overwrite ? [y/N] y
[ffv1 @ 0557eb80] bits_per_raw_sample > 8, forcing coder 1
Output #0, avi, to 'test.avi':
Metadata:
ISFT : Lavf56.40.101
Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), gray16le, 124x128, q=2-31, 2000 kb/s, 10 fps, 10 tbn, 10 tbc
Metadata:
encoder : Lavc56.60.100 ffv1
Stream mapping:
Stream #0:0 -> #0:0 (tiff (native) -> ffv1 (native))
Press [q] to stop, [?] for help
frame= 54 fps=0.0 q=-0.0 Lsize= 307kB time=00:00:05.40 bitrate= 465.2kbits/s dup=0 drop=79
video:300kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.284209%
If needed I can provide the images and the video.
>
>> I guess there is somewhere a problem switching from uint16 to uint8,
>> but I cannot figure it out. Any hints?
>
>I may misunderstand but you get a uint8_t pointer that contains the exact 16bit data you originally encoded after decoding.
>
>Carl Eugen
Yes that's what it's supposed to happen. But I was getting some strange images while inspecting intermediate results, so I was wondering if there's something else going on.
Best,
Stefano
More information about the Libav-user
mailing list