michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 7.0.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
tufei__ has joined #ffmpeg-devel
tufei_ has quit [Ping timeout: 260 seconds]
thilo has quit [Ping timeout: 256 seconds]
Teukka has quit [Read error: Connection reset by peer]
<cone-031>
ffmpeg James Almer master:bef77c6c9c38: avformat/dump: only print yaw, pitch, and roll if set
feiwan12 has joined #ffmpeg-devel
feiwan1 has quit [Read error: Connection reset by peer]
jamrial has quit []
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 268 seconds]
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
HarshK23 has joined #ffmpeg-devel
f_vk_f has left #ffmpeg-devel [#ffmpeg-devel]
vckt has joined #ffmpeg-devel
<vckt>
Hello
<Marth64>
hi
<vckt>
is it possible to fully statically compile the ffmpeg binary?
<vckt>
i already have an existing ffmpeg installation from my package manager so i dont know if it'll be affected when i try to compile my own version
<Marth64>
it depends what you want to configure it with (ssl, codecs, ....). but not sure how you mean affected, it'll just be a different executable?
feiwan13 has joined #ffmpeg-devel
feiwan12 has quit [Remote host closed the connection]
<Marth64>
people do it
<vckt>
i see... got it
<vckt>
also, is there any restriction against using // comments? i saw most inline comments were /* */ but didnt see it mentioned in the contribution guide
<Lynne>
I prefer /* */ but prefer is the keyword, though most of our comments are /* */
<Marth64>
expecting to get grilled in my new patchset (please do, really want to fix this)... but as it stands now we have broken closed_caption field in ffprobe that is regression, used to work before
<Marth64>
otherwise the code in ffprobe is dead and should be removed
<Marth64>
fix is in ml
<Marth64>
dump also works again: > Stream #0:0: Video: mpeg2video (Main), yuv420p(tv, progressive), 720x480 [SAR 32:27 DAR 16:9], Closed Captions, ...
feiwan12 has joined #ffmpeg-devel
feiwan13 has quit [Remote host closed the connection]
cone-031 has quit [Quit: transmission timeout]
feiwan13 has joined #ffmpeg-devel
feiwan12 has quit [Remote host closed the connection]
<elenril>
Marth64: the notion of internal properties that are visible to api callers is evil and should die
<Marth64>
elenril: I agree going into this it wasn't ideal. I only said ok because I saw av_stream_get_codec_timebase(). Open to ideas. I am just looking from a bugfix perspective
<elenril>
I intend to kill av_stream_get_codec_timebase() as soon as I can find some time for it
<elenril>
its existence offends me
<elenril>
as for your issue, shouldn't ffprobe figure out that property on its own?
<Marth64>
Maybe I can look from "expose the info publically" angle. Maybe CC detected as public field?
<Marth64>
It should, but it's broken. The value is always 0.
<Marth64>
I traced it to the part where it binds codecs. It makes sense, sense its creating new AVCodecContext
<Marth64>
It can't get the original field value
<elenril>
a possibly-less-offensive way to export it might be a new stream disposition
<Marth64>
I think that's a good idea I can explore. Maybe "embedded_cc" or something.
<JEEB>
I think the problem is that this caption field would only work if the probed/decoded content within avformat happened to contain captions, I think? so I think if you f.ex. start having captions minutes later, you may not find those. but this is true to various other fields that avformat exposes for AVStreams
<JEEB>
so yea, I guess I'm not against a flag on avformat level for it if people do not want to do -show_packets or -show_frames themselves for some range to see the side data attached
<Marth64>
JEEB: I agree with your analysis, it is what I realized too. My feature thinking logic was if ffprobe can analyze for a certain duration it should cover picking up a 0/1 on cc found during the duration
<Marth64>
Okay, will take this back to the drawing board. It's a start, at least I know where the issue is now. It's been bugging me for a while.
<Marth64>
It's an embedded stream in a stream. Annoying but it's a stream too so my thinking is ffprobe should detect it properly or not at all.
<JEEB>
there were some ideas on how to expose substreams before, currently clients just see that "oh hey this video frame actually contained captions" at the point where that happens and add a new stream on their side to which the caption packets contained in side data would then get pushed to.
<elenril>
the annoying thing it's fundamentally unreliable unless you decode the whole stream
<JEEB>
yea
<Marth64>
Yes
<JEEB>
since it 100% depends at which point the first caption side data is noticed
<Marth64>
Like forced subtitles.
<JEEB>
for API clients there are already formats where AVStreams get added during runtime
<JEEB>
but then if you want something like mediainfo that just quickly probes your file, it is much less sure :D
<JEEB>
(or ffprobe without show_packets|frames
<vckt>
hi so i have question... i know this is probably file dependent, but how can i stop execution of the program when i recognise invalid input is given?
<Sean_McG>
return AVERROR_INVALIDDATA somewhere
<JEEB>
return an AVERROR? depending on things it may or may not stop the whole API client, but at least you're doing the correct thing
<Marth64>
JEEB: That's acceptable to me ("fuzzy check") and I think it can be documented to convey its unreliable. An educated guess is better than always 0 otherwise why have it at all.
feiwan13 has quit [Ping timeout: 272 seconds]
<Marth64>
I run through all the frames for now in my client (a python script).
<Marth64>
vckt: AVERROR(EINVAL) if invalid user input (e.g. options)
<Sean_McG>
^
<Marth64>
elenril: Alternative thought. The whole idea with the properties and get codec timebase have a similarity. I am seeing both being used in a "create a new codec context, copy the parameters from another one, and some other fields" story.
<Marth64>
Maybe that story can get a public function like av_create_stream_from_stream() or whatever
<Marth64>
It would fix both issues
<Marth64>
But idk. I just learned about av_stream_get_codec_timebase() in ffmpeg_mux_init today
Krowl has quit [Read error: Connection reset by peer]
darkapex has quit [Ping timeout: 268 seconds]
darkapex has joined #ffmpeg-devel
cone-247 has joined #ffmpeg-devel
<cone-247>
ffmpeg Zhao Zhili master:b8b71be07a79: swscale/aarch64: Add bgr24 to yuv
<cone-247>
ffmpeg Zhao Zhili master:52422133ae99: swscale/aarch64: Add bgra/rgba to yuv
<cone-247>
ffmpeg Zhao Zhili master:4d90a76986cf: swscale/aarch64: Add argb/abgr to yuv
<elenril>
Lynne: exactly
feiw has joined #ffmpeg-devel
<Marth64>
elenril: I have prototype for you
<Marth64>
of course it segfaults....sec
<Marth64>
elenril: https://paste.debian.net/hidden/5f16074d/ it seems to work. my only concern is will accessing st->codecpar in stream_init (by way of this new function) break concurrency
ccawley2011 has joined #ffmpeg-devel
<elenril>
fuck no
<elenril>
Marth64: absolutely NO accessing of lavf internal codec context
<elenril>
as far as the API caller is concerned, it does not exist
<Marth64>
ahh
<elenril>
I made it private for a reason
<elenril>
and the reason was, people thought it was a good idea to look inside
<Marth64>
why that "copy timebase while removing common factors" block can't just be shoved in avformat_transfer_internal_stream_timing_info() and call it a day?
<elenril>
I want to kill avformat_transfer_internal_stream_timing_info()
<Marth64>
I see
<elenril>
there should be no "internal stream timing info"
<courmisch>
codec parameters have privacy rights too!
<elenril>
it's a hack to unbreak other hacks
<elenril>
as frank herbert would say, hacks within hacks within hacks
<Marth64>
then the green solution the broken ffprobe field is there should be public property or disposition
<Marth64>
otherwise this is just hacking on hacks
<courmisch>
how about infinitely recursive hacks
<elenril>
that's probably easiest, as long as nobody is too unhappy with the disposition being unreliable
<elenril>
otherwise you could have ffprobe probe decode the stream by itself
<Marth64>
ok .. I will sleep on this
<Marth64>
but I haven't given up yet
<Marth64>
this bug annoys me
<elenril>
making it a disposition should make the functionality equivalent to exporting the properties
<elenril>
without hardcoding more hacks into lavf api
<Marth64>
its the fastest route yea
<Marth64>
is it really a "disposition" though I have to think about how to present that argument
<elenril>
what is a disposition
<Marth64>
to me it is a hint of what purpose the stream is presented for to the user
<Marth64>
accessible needs, alternate commentary, whatever... and is CC just hearing_impaired on a video track, or a new disposition altogether (embedded_cc etc)
<Marth64>
it is 0400 now and I'll sleep through this
<Marth64>
wtf even is "codec timebase" that's a good question
<elenril>
it's not a thing
<elenril>
not a well-defined one anyway, which is why I want to kill it
* Marth64
hands elenril code axe
Krowl has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
<cone-247>
ffmpeg Jun Zhao master:25a7dcf06916: lavc/libx264: minor format fix
<cone-247>
ffmpeg Jun Zhao master:03c2e9d77eac: lavf/scdet: minor fix
Livio has quit [Ping timeout: 246 seconds]
Krowl has quit [Read error: Connection reset by peer]
<cone-247>
ffmpeg Marvin Scholz master:cd9ceaef22ec: avutil/hwcontext_videotoolbox: Set CVBuffer CGColorSpace
Krowl has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
<Kwiboo>
hi, I would like to add support for new pix fmts nv15/nv20/nv30, however there already exists incompatible nv20le/nv20be fmts in ffmpeg, any suggestion on how to best handle a pix fmt name clash?
<jdarnley>
> Instead, a group of 4 luminance/chrominance samples are stored over 5 bytes
<jdarnley>
oh no not again
HarshK23 has quit [Quit: Connection closed for inactivity]
awehr_ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
<nevcairiel>
these names are dumb and should never have been used, just because NV12 is a thing doesnt mean it should just be confusingly continued without consequences.
<nevcairiel>
because they'll eventually always collide. NV24 is 8-bit 4:4:4, or is it 12-bit 4:2:2? Who could tell!
<nevcairiel>
more importantly, NV12 is not bit-packed, due to the nature of being 8-bit. Bitpacked formats are special and need extra treatment, and thus should be named accordingly
<haasn>
I may be biased but I like the libplacebo format naming scheme
<haasn>
Admittedly it does not have the "nice" property of fitting into a 32-bit integer
<haasn>
It's also a bit verbose
<haasn>
nv12 would be y8_uv8
<haasn>
y8_uv8_420 rather
<Kwiboo>
gstreamer calls these formats nv15 = NV12_10LE40 and in a pending merge-request nv20 = NV16_10LE40, any suggestions on what ffmpeg want to name these pix fmts?
cone-247 has quit [Quit: transmission timeout]
<nevcairiel>
what does 10LE40 mean
<nevcairiel>
I get the 10 for 10-bit, and the LE for the endianness, but whats 40 about it
<jkqxz>
The endianness there means what? Whether the first byte is the low or high 8 bits of the first sample?
<nevcairiel>
for bitstream formats it makes little sense, i guess
<Traneptora>
is it possible to systematically name them
<nevcairiel>
since a single pixel doesnt fill two bytes either
vckt has quit [Ping timeout: 246 seconds]
<jkqxz>
Do you actually want to read this format, or will it always be given to another component which can read it (graphics or display)?
vckt has joined #ffmpeg-devel
<Kwiboo>
it is mostly for passing it to another component, the video decoder decode 10-bit content into these formats, and the display controller can display them. having basic swscale input support also helps with hwdownload to do decode conformance testing
<Kwiboo>
I have started reworking our old v4l2-request hwaccel patches from libreeelc for upstreaming purposes, and these formats are used by the rockchip decoder/display pipeline
<Kwiboo>
having them defined as proper ffmpeg pix fmt have mostly helped for running fluster tool to test conformance when working on the kernel driver
<Kwiboo>
using FMT_NONE still make it possible to decode and display video, just harder to know if the 10-bit conformance test videos is decoded correctly
HarshK23 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<courmisch>
size can be 40 bits, but certainly not alignment
<Kwiboo>
sure, but the 10-bit sample alignement is 4 = 5 bytes = 40 bits
<courmisch>
there is no such thing as 10-bit alignment
<courmisch>
alignment is a power of two and the unit is bytes
<courmisch>
feel free to disagree with ISO C and all computer architectures but that's on you
dellas has joined #ffmpeg-devel
<Kwiboo>
I do not mean litteral memory alignment, only that the format expect that: number of samples % 4 = 0
<pal>
haasn: did you find the J2K spec you were looking for?
<haasn>
pal: no longer needed, thx
<haasn>
is there such a thing as interlaced frames with an odd size? for example, 400x101 interlaced; there would be more even rows than odd rows?
<haasn>
or would that be considered the same as 400x100, with the extra row being ignored
<haasn>
or more likely, AVERROR(EINVAL)
<mkver>
haasn: It's a thing according to michaelni.
<nevcairiel>
just start counting from the top in alternates, and what you get is what you get
<nevcairiel>
dont most codecs round up anyway for blocks etc
Krowl has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
ngaullier has quit [Quit: Leaving]
devinheitmueller has joined #ffmpeg-devel
cone-451 has joined #ffmpeg-devel
<cone-451>
ffmpeg Rémi Denis-Courmont master:d1f0c1fbf8db: lavc/h264dsp: R-V V 8-bit h264_idct_add16intra
<cone-451>
ffmpeg Rémi Denis-Courmont master:30475c95ba50: lavc/h264dsp: R-V V 8-bit h264_idct_add16
<cone-451>
ffmpeg Rémi Denis-Courmont master:e0eff64ed1e6: lavc/h264dsp: R-V V 8-bit h264_idct8_add4
odrling has quit [Remote host closed the connection]
odrling has joined #ffmpeg-devel
odrling has quit [Remote host closed the connection]
odrling has joined #ffmpeg-devel
j45_ has joined #ffmpeg-devel
Livio has quit [Ping timeout: 246 seconds]
j45 has quit [Ping timeout: 240 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
<michaelni>
haasn, PAL has 625 scan lines, NTSC 525, if you store that you have odd lines in interlaced frames. In fact, IIRC the different number of lines in the fields can be used to identify which field it is. Also croping interlaced frames results in odd things
<haasn>
"fun"
<haasn>
so vf_scale is currently bugged in this regard?
<haasn>
it just does inlink0->h >> !!i
Livio has joined #ffmpeg-devel
<haasn>
if h is odd, this rounds down, losing one line of luma information
<haasn>
should probably be (inlink0->h + (i == 1)) >> !!i
<haasn>
xyz12Torgb48() seems... wrong
<haasn>
rather, fill_xyztables()
<haasn>
it hard-codes gamma 2.6 for XYZ, gamma 2.2 for sRGB, and god knows what XYZ/RGB conversion matrix
<haasn>
2.6 is not that wrong though it should also normalize by 52.37/48.0 (SMPTE ST428 semantics)
<kepstin>
hey, gamma 2.2 for sRGB is less wrong than 2.4 would be, at least.
ccawley2011 has quit [Ping timeout: 240 seconds]
ccawley2011_ has joined #ffmpeg-devel
jarthur has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
<haasn>
it probably does a conversion to sRGB gamut
<haasn>
though arguably XYZ should convert to AVCOL_PRI_SMPTE428
Livio has quit [Ping timeout: 255 seconds]
awehr_ has quit [Ping timeout: 255 seconds]
awehr_ has joined #ffmpeg-devel
<Marth64>
elenril: nice. that was quick
<Marth64>
i go to sleep, wake up, avformat_transfer_internal_stream_timing_info() is deprecated
<Marth64>
:D
awehr_ has quit [Ping timeout: 264 seconds]
awehr_ has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
awehr_ has quit [Ping timeout: 256 seconds]
dlb76 has quit [Ping timeout: 252 seconds]
Krowl has quit [Read error: Connection reset by peer]
aphysically has quit [Ping timeout: 264 seconds]
AbleBacon has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 255 seconds]
cone-451 has quit [Quit: transmission timeout]
cone-007 has joined #ffmpeg-devel
<cone-007>
ffmpeg Marton Balint release/7.0:c75cabef94e0: avutil/timestamp: avoid possible FPE when 0 is passed to av_ts_make_time_string2()
Livio has quit [Ping timeout: 256 seconds]
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
haihao_ has quit [Ping timeout: 246 seconds]
haihao_ has joined #ffmpeg-devel
ccawley2011_ has quit [Read error: Connection reset by peer]
* Sean_McG
peeks in
mkver has quit [Ping timeout: 255 seconds]
cone-007 has quit [Quit: transmission timeout]
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 256 seconds]