| View previous topic :: View next topic |
| Author |
Message |
nick87720z
n00b
Joined: 22 Mar 2017
Posts: 42
|
 Posted: Sun Jan 16, 2022 7:12 pm Post subject: ffmpeg & rawvideo stdin - bug with 128..255 bytes input |
 |
|
I have at least 2 unstandard uses for ffmpeg, where it works with parameter value.
In first case I implemented webcam-based light sensor, where it downmixed v4l2 input into 1x1 gray16(le or be, depending on platform) rawvideo image with pipe output, resulting into single 2 byte value per frame.
Now I tried something reversed, inspired by first use (it got me reason to boost understanding about ffmpeg cli interface capabilities).
I want to make ffmpeg to visualize incoming value as value, rather than color. For now I tried implement level bar for 1-byte value. Value is interpreted as 1x1 gray rawvideo. And that's where problems begin.
There's minimal example to reproduce it:
| Code: | stdbuf -o0 yes | stdbuf -o0 awk '
BEGIN {i = 0}
{
printf "%c", i
i = (i+1) % 256
}
NR == 256 {exit}' \
| ( stdbuf -o0 ffmpeg -nostdin -v quiet \
-vcodec rawvideo -f rawvideo -pix_fmt gray -s 1x1 -i - \
-vf format=gray \
-vcodec rawvideo -f rawvideo - ) \
| stdbuf -oL hexdump -v -e '1/1 "hexdump: %u\n"' | nl -v0
|
Hexdump showes unmodified values for range 0..127. For everything above, starting with 128, it gets two values: 194, than value itself (in that order). Though when value reaches 190, preceding misterious value becomes 195. After 191 - value continues with 128, while "pre-value" remains at 195. Second grow cicle completes full _real_ cicle (with real value reaching 255, as at 256 it's mod-divided into 0).
I expected, that gray8 format should allow all 8bit values. At least if I set values directly with geq in -vf, e.g. | Code: | | -vf geq=lum=255,... |
or so, hexdump showes it. This means, that problem occurs before -vf.
Just for case - this is what I tried to accomplish (could be potential executor for whatever supported rawvideo input):
| Code: | #!/bin/sh
# ffmpeg takes input parameters from stdin as raw video frames and returns visualization as raw video to stdout.
# This is simple case, using just one value.
# awk simulates parameter source, ffplay - potential executor host
stdbuf -o0 yes | stdbuf -o0 awk '
{
i = (i+1) % 129
printf "%c", i
}
' | stdbuf -o0 ffmpeg -nostdin -v quiet \
-vcodec rawvideo -f rawvideo -pix_fmt gray -s 1x1 -i - \
-vf scale=48:128:flags=neighbor,geq=lum="
if(
gt(Y\, H - p(X\,Y)*H/128 )\,
100\,
0
)
",format=gray \
-vcodec rawvideo -f rawvideo - \
| SDL_AUDIODRIVER=jack ffplay -v quiet -s 48x128 -pix_fmt gray -vcodec rawvideo -f rawvideo -
|
(also got working N-bar variant using Nx1 input frames).
Could not find anything about such problem. For me this looks like bug. Ffmpeg bugtracker mandates to try latest development version before to report, but I use stable ebuild for 4.4.1-r2. Need help. |
|
| Back to top |
|
 |
nick87720z
n00b
Joined: 22 Mar 2017
Posts: 42
|
| Posted: Mon Jan 17, 2022 9:10 am Post subject: |
|
|
It's not ffmpeg problem. I just discovered, that awk command does this for any value in range 128..255, while ffmpeg is completely happy with any byte values.
For gawk this depends on locale. Solved by runing awk with LANG=C.
ERR: Can't make update for previous post due to strange "posting error" |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Multimedia
