lusciouslover has quit [Read error: Connection reset by peer]
lusciouslover has joined #ffmpeg
TheSilentLink has quit [Ping timeout: 245 seconds]
TheSilentLink has joined #ffmpeg
TheSilentLink has quit [Quit: Good Bye! My bouncer has probably crashed or lost connection to the internet...]
Ogobaga has quit [Read error: Connection reset by peer]
Ogobaga has joined #ffmpeg
Vonter has quit [Ping timeout: 245 seconds]
Vonter has joined #ffmpeg
Asterisk has quit [Ping timeout: 252 seconds]
vampirefrog has joined #ffmpeg
Muimi__ has joined #ffmpeg
Asterisk has joined #ffmpeg
Muimi__ has quit [Ping timeout: 252 seconds]
Muimi__ has joined #ffmpeg
dza has quit [Quit: ]
dza has joined #ffmpeg
dza has quit [Quit: ]
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
Muimi__ has quit [Quit: Going offline, see ya! (www.adiirc.com)]
dza has joined #ffmpeg
dza has quit [Quit: ]
dza has joined #ffmpeg
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
ivanich has joined #ffmpeg
rv1sr has joined #ffmpeg
ivanich has quit [Remote host closed the connection]
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
junaid_ has joined #ffmpeg
AbleBacon has quit [Read error: Connection reset by peer]
lavaball has joined #ffmpeg
zumba_addict has quit [Quit: Client closed]
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
Tano has quit [Ping timeout: 245 seconds]
Tano has joined #ffmpeg
lavaball has quit [Remote host closed the connection]
meinside has quit [Quit: Connection closed for inactivity]
Vonter has quit [Ping timeout: 256 seconds]
hsv has quit [Ping timeout: 260 seconds]
Vonter has joined #ffmpeg
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #ffmpeg
rv1sr has quit [Ping timeout: 256 seconds]
rv1sr has joined #ffmpeg
stevenliu has quit [Read error: Connection reset by peer]
stevenliu_ has joined #ffmpeg
Vonter has quit [Quit: WeeChat 4.1.2]
Vonter has joined #ffmpeg
junaid_ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #ffmpeg
kushal__ has joined #ffmpeg
kus has quit [Ping timeout: 260 seconds]
lavaball has joined #ffmpeg
deus0ww has quit [Ping timeout: 246 seconds]
deus0ww has joined #ffmpeg
kurosu has joined #ffmpeg
antto has joined #ffmpeg
<antto>
hello, i need a library where i can create a (web-friendly, i guess 264+AAC) video file from a pile of images i draw in a pixel buffer, is "libavcodec-dev" the thing i need?
<JEEB>
avcodec for raw AVFrames to AVPackets, then avformat for AVPackets into container like MP4
billchenchina has joined #ffmpeg
billchenchina has quit [Remote host closed the connection]
kurosu has quit [Quit: Connection closed for inactivity]
<antto>
which pixel format would be "most convenient" for ffmpeg? my pixels come all the way from (float) CIE xyY to XYZ and for displaying on screen i convert to linear RGB and then gamma-compressed sRGB (8bit per channel)
<JEEB>
for H.264 the end result you want is YUV420P with probably sRGB transfer
<antto>
assuming it's float g,b,r; linear RGB
<JEEB>
(and BT.709 primaries)
<JEEB>
in theory RGB is possible, but the decoders in browsers will not support it
<JEEB>
(hardware decoders are getting utilized and they mostly lack support)
<antto>
uhm, i mean how do i prepare my data.. since i already toss it between different colorspaces
<antto>
so i thought the less number of conversions - the better, i already go thru CIE XYZ
<JEEB>
yea so if you have sRGB for screen then you have according to H.273: matrix: identity , primaries: BT.709 , transfer: sRGB
<furq>
there is an xyz pixel format for j2k but i guess that will end up getting converted to rgb for the encoder
<JEEB>
so if you convert the matrix to BT.709 or so, and then chroma subsample to 4:2:0, that should be nicely playable in browsers
<antto>
JEEB, i'm rewriting a thing that used to draw pretty pictures on the screen (so, gamma-compressed sRGB) in realtime, but i'm rewriting it as an offline version because this time it'll draw much fancier so it just won't work in realtime, thus i want it to spew out a video
<JEEB>
furq: technically by flagging it as RGB and using the libx264rgb wrapper with the primaries set to XYZ you are getting XYZ
<JEEB>
since matrix = identity for both RGB and XYZ
<JEEB>
but yes, the XYZ pixel format is not usable in the x264 wrappers
<furq>
i meant for input to the encoder
<JEEB>
that's what I meant
<JEEB>
RGB pix_fmt and primaries as XYZ
<JEEB>
ends up coded as XYZ
<antto>
so i have floating point XYZ in the middle, and i have -> linear RGB -> gamma -> sRGB (8bit per channel) just for display, but i am willing to toss that if the encoder prefers a different input format for less color conversion
<JEEB>
well you mentioned web playback right?
<JEEB>
that limits your capabilities
<antto>
ehm
<furq>
any of those should work as input if you flag it all correctly
<JEEB>
since you need to take into account them plastic boxen
<furq>
i guess srgb is the most common
<JEEB>
and hardware decoders
<antto>
i don't expect the colorspace of the .mp4 to be "XYZ"
<JEEB>
technically it's possible, but then what correctly interprets that color space information is a separate question ;)
<JEEB>
avcodec does not do conversions for you
<antto>
i know video encodings have special colorspaces which are similar to xyY in that luma (Y) is sepparate, and usually more detailed, while chroma can be more crushed or undersampled, etc
<JEEB>
yup
<JEEB>
basically you can query this from the API as well, but to see an example
<JEEB>
`ffmpeg -h encoder=libx264`
<antto>
i wanna make average .mp4, the same sort of mp4 i make when i wanna upload to pootube or wherever
<JEEB>
that lists you the supported pixel formats by that module
<JEEB>
then additionally you have requirements such as "I want to play it with XYZ"
<JEEB>
which in your case is "I want to play it on the web or so"
<JEEB>
if I understood your requirements correctly
<JEEB>
that already brings us down to YUV420P since that is the most commonly hardware decode'able format
<antto>
hold on
<JEEB>
it's 8bit, YCbCr. you can flag the matrix, primaries and transfer (aka "gamma" in olden wordings) to tell the player how to handle it
<antto>
i do NOT expect the .mp4 to be XYZ colorspace, that's insane, XYZ is more like a middle colorspace that is used to "glue" all other colorspaces together
<JEEB>
+ 4:2:0 chroma subsampling
<JEEB>
yes I understand that
<furq>
yeah we get that
<JEEB>
> < JEEB> avcodec does not do conversions for you
<JEEB>
so your input to avcodec is literally what you push out
<JEEB>
anyways, re-read the last 5-10 lines I noted
<furq>
swscale or avformat will do xyz to yuv or linear rgb to yuv or srgb to yuv for you
<JEEB>
he already has a flow getting to 8bit sRGB
<furq>
right
<furq>
i'm saying you can pick any
<furq>
just flag it correctly
<JEEB>
so he only needs to add matrix conversion to BT.709 YCbCr, and then chroma subsampling to 4:2:0 and bob's his uncle
<antto>
i'm unfamiliar with ffmpeg, i sorta thought that i tell libavcodec what my pixel buffer is and what the output pixel format should be, or am i supposed to prepare the buffer in the right format?
<furq>
format conversions are done by swscale
<furq>
usually through avformat
<antto>
x_x
<JEEB>
as I said, "avcodec does not do conversions for you"
<JEEB>
there are other things in the FFmpeg project that do that for you but that is clearly separate from "just encoding"
Muimi__ has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<JEEB>
thankfully, you are already very close to one of the formats that is well supported
<antto>
what should i do?
<furq>
through avfilter i mean
<antto>
prepare my buffer in a suitable format myself, or use even more libraries to do that?
<JEEB>
antto: in your position since you already seem to have plenty of colorspace stuff there, I'd probably add a matrix conversion to BT.709 YCbCr + chroma subsampling with the left chroma location position as an alternative to the 8bit sRGB output
<JEEB>
you can then validate it against zscale filter with the command line app or so
<JEEB>
and probably a good idea to do limited range output when taking it to 8bit
<antto>
hm.. how badly is the chroma subsampled btw? :/
<JEEB>
since sRGB in H.273 terms (https://www.itu.int/rec/T-REC-H.273-202107-S/en) is { primaries: BT.709, transfer: sRGB, matrix: identity }, then that YCbCr result would just be { primaries: BT.709 (same), transfer: sRGB (same), matrix: BT.709 (since you did RGB->YCbCr conversion with BT.709 matrix), chroma location: left }
<furq>
hopefully you don't have small coloured text
<JEEB>
antto: the most commonly supported by hardware decoders format is 4:2:0, which means that luma is full res and chroma is 1 sample per 2x2 area
<antto>
what i'm drawing is a noisy-looking colorful pile of pixels that is a spectrograph, so the chroma can vary wildly from pixel to pixel, and while i know noisy pictures are the worst for this kind of video compression, the motion (from frame to frame) is basically a horizontal shift to the left
<JEEB>
if you are watching youtube etc, all of that is 4:2:0
<furq>
most likely everything you've ever watched on a tv was 4:2:0
<furq>
but it can cause artifacts in screen recordings etc
<furq>
you'd just have to test it and see i guess
<antto>
basically for every frame, the old picture shifts N pixels to the left, and then the empty area is drawn with new stuff
<furq>
it's hard to say how bad it'll be from a description
<furq>
it sounds like it could be bad
<antto>
if the chroma is subsampled it would be bad
<antto>
lemme come out with some pictures
<furq>
if you have pictures you can convert them with the ffmpeg cli
<antto>
and for every new frame, this shifts to the left several pixels
<antto>
(the picture comes from the audio)
<JEEB>
antto: if you have an sRGB PNG or so, you can check how it looks with the ffmpeg tool: `ffmpeg -v verbose -i input.png -noauto_conversion_filters -c:v libx264 -crf 21 -vf "scale,format=pix_fmts=gbrp,zscale=m=709,format=pix_fmts=yuv420p,setparams=color_primaries=bt709:color_trc=iec61966-2-1" test.mp4`
<JEEB>
that expects 8bit sRGB PNG
waleee has joined #ffmpeg
<JEEB>
that filter chain basically: whatever the decoder outputs -> gbrp (with 8bit RGB this should just swap the data around into a format that zscale supports) -> converts matrix to BT.709 and chroma subsamples to 4:2:0 with zscale -> makes sure to set primaries and transfer
<JEEB>
since primaries and transfer might not be set in the input, but we want that metadata in the output
<JEEB>
theoretically the setparams could also be the first filter but that's how I quickly concocted that up :P
rv1sr has quit []
cosimone has quit [Ping timeout: 260 seconds]
<antto>
well, it looks jpeg-ized ;P~
<JEEB>
if you get compression artifacts then instead of the CRF you utilize `-qp:v 0`
<JEEB>
that should do lossless coding
<JEEB>
so only loss in that case should be the 4:2:0 chroma subsampling and limited range
waleee has quit [Ping timeout: 264 seconds]
<antto>
i guess "f*ck it" this is gonna be only for fancyness and not for serious analysis, i should make my app also render to .png
<psykose>
if you're not limited to h264 then web browsers don't mind playing 4:4:4 av1 which keeps the colors looking original
<antto>
hm
<psykose>
or at least on desktop
<psykose>
i did not try like ios safari
waleee has joined #ffmpeg
<psykose>
but webkit gnome web and firefox/chromium do it ok
Magissia has joined #ffmpeg
<antto>
when i said "web" i really meant my typical usecase of uploading to pootube
<psykose>
no hwaccel on the decode ofc cause nothing supports that (it's like some professional-tier requirement)
<psykose>
ah, ok for youtube i have no idea
<psykose>
i know they re-encode your shit anyway a bunch
<JEEB>
antto: that is going to get converted to 4:2:0 in any case
<psykose>
yeahg
<JEEB>
so it makes sense to control that conversion
<JEEB>
instead of hoping for the best
<antto>
yeah i notice the chroma is definately badly undersampled on anything pootube
<JEEB>
for stuff like dot art people just use nearest neighbor and scale to 2x2
<JEEB>
then the chroma subsampling doesn't hurt
<antto>
that's what i was thinking too
<psykose>
what's the 2x2 scaling trick
<JEEB>
scale to 2x I mean
<JEEB>
the trick is that then every original chroma sample has an output sample
<JEEB>
in 4:2:0
<JEEB>
since 4:2:0 is one sample for 2x2 area
<JEEB>
(for chroma)
<psykose>
yea, the math checks out
<psykose>
do you have a ffmpeg cli example for it
<antto>
how exactly do you parse this "4:2:0" type of number?
<JEEB>
I never learned it :P
<JEEB>
4:4:4 is full res
<JEEB>
4:2:2 is one sample for 2 samples on a single line (so each line has data)
<JEEB>
4:2:0 is one sample for 2x2 samples
<JEEB>
then there's 4:1:0 which was utilized in DV
Magissia has quit [Ping timeout: 268 seconds]
<JEEB>
I will guess the first number is luma since that keeps being 4
<antto>
and then there's like "RGBA 8:8:8:8"
<JEEB>
that sounds different
* psykose
checks `ffmpeg -pix_fmts`
<JEEB>
that's bits per sample on each plane
<psykose>
the world has too many pixel formats
<JEEB>
since RGBA has 4 planes and each of them are 8 bits per sample :P