Hi Christoph, > On Jan 19, 2015, at 4:02 AM, Christoph Gerstbauer > <christophgerstba...@gmail.com> wrote: > > Thank you, Dave! > > As I guess, this commandline is just working on linux, right?
On Mac. > I tried it on windows but: > > ffmpeg -i > I:\_10bit_PERFORMANCE_TESTS\analog_tape_records\10bit_v210_captured_via_SDI-8bit.mov > -c:v rawvideo -f rawvideo - | xxd -c 2 -b > 'xxd' is not recognized as an internal or external command, > operable program or batch file. I'm not familiar enough with windows to suggest an alternate to xxd, though perhaps it can be installed on windows. > The whole thing I am trying to do is: ffv1 speed/cpu load tests with 10bit > sources. > But first I have to be 100 percent shure that the v210 files I am generating > with SDI capturing are real 10bit sources. > I have several "10bit"-believing files (v210/AVC-Intra for example) but I was > not the creator of them. If in their generation chain was just one point > where 8bit was used, the 10bit information is lost. And thats why I can just > believe that it is 10bit. You could also try using ffmpeg to view a bit plane of the video, for instance: bit=8 ; ffplay -f lavfi -i mandelbrot -vf "lutyuv=y=bitand(val\,pow(2\,8-$bit))*pow(2\,$bit):u=128:v=128" Here you can set bit to an integer between 1 and 8 to present a bit plane. I haven't been able to identify a way to do this entirely within ffmpeg with a bit position above 8, since the lutyuv and geq filters only take in 8 bit. > I am capturing from a IMX VTR which allows to set the SDI bitdepth for the > SDI output (8bit/10bit). SO I can directly control that the final captured > v210 file will have 8bit or 10bit information (capturing via a AJA Kona card). > > So, for your mentioned method, I will need linux. Right? > > Addionally: > As far as I know, 10bit ffv1 compression rates are better than 8bit. SO a > "8bit"-v210 file is a little bit larger than a "10bit"-v210 file. Do you know > why? This seems unusual. The higher the bit depth of sampling from an analog source the more noise in the least significant bits so the less effective is the lossless encoding. However v210 has padding bits so that every 3 10 bit samples includes 2 bits of padding. In a v210 -> ffv1 the padding bits are discarded and could then be considered to throw off a compression rate analysis. For instance a 320x240 frame in v210 would be 215,040 bytes but only 192,000 of those bytes are non-padding data. Thus the v210 padding may through off your compression test by about 12%. (please correct me if my math is wrong here). Dave > Best Regards > Christoph > > Am 16.01.2015 um 16:40 schrieb Dave Rice: >> Hi Christoph, >> >>> On Jan 16, 2015, at 10:03 AM, Moritz Barsnick <barsn...@gmx.net> wrote: >>> On Fri, Jan 16, 2015 at 14:10:38 +0100, Christoph Gerstbauer wrote: >>>> I am searching for a possibility to check if a 10bit 4:2:2 videofile >>>> (v210 codec or ffvhuff codec) has >>>> a) 8bit+2empty bits or >>>> b) full 10bit data >>>> in the video stream. >>> You'll probably need to export it to raw YUV or RGB (depending on the >>> input color space) and inspect the least significant bits. This might >>> be easier with a small libav* program than ffmpeg. My first shot would >>> be trying to understand the raw output formats, and to parse them with >>> a pipe to a perl one-liner using unpack(). ;-) >> I pipe the data to xxd for this, such as: >> ffmpeg -i v210.mov -c:v rawvideo -f rawvideo - | xxd -c 2 -b >> >> Since the rawvideo of v210 is 16 bits, I use -c 2 to show the output in 2 >> bytes per row (-c 2). You’ll get an output that looks like this: >> >> 008322e: 11011101 00000001 >> 0083230: 01001000 00000010 >> >> In the case I’ll see the last two (right most) bits of the first byte >> toggling indicated that it is actually using 10 bits of detail. If the v210 >> was 8 plus two zeros then the last two bits of the first byte would always >> be zero. Unfortunately there is a lot of video hardware that works as 8 bits >> so often those who are intending to digitize analog video to 10 bit are >> actually creating 10 bit files with the least significant bits simply being >> padding. Some digital videotapes also decode to 8 bit but are received over >> 10 bit SDI so this same process can be used to verify if the SDI contains >> actual 10 bit video or some amount of padding. >> Best Regards, >> Dave Rice >> >> _______________________________________________ >> ffmpeg-user mailing list >> ffmpeg-user@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user > > _______________________________________________ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-user _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
