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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
cone-741 has quit [Quit: transmission timeout]
System_Error has quit [Remote host closed the connection]
iive has quit [Quit: They came for me...]
thilo has quit [Ping timeout: 246 seconds]
thilo has joined #ffmpeg-devel
arch1t3cht9 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 248 seconds]
arch1t3cht9 is now known as arch1t3cht
MyNetAz has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
MyNetAz has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
jamrial has quit []
^Neo has quit [Ping timeout: 244 seconds]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 248 seconds]
mkver has quit [Ping timeout: 252 seconds]
zenmov has joined #ffmpeg-devel
klaxa_ has joined #ffmpeg-devel
aaabbb_ has joined #ffmpeg-devel
kepstin has quit [*.net *.split]
klaxa has quit [*.net *.split]
Chagall has quit [*.net *.split]
graphitemaster has quit [*.net *.split]
aaabbb has quit [*.net *.split]
natto has quit [*.net *.split]
bcheng has quit [*.net *.split]
stazthebox has quit [*.net *.split]
Hobbyboy has quit [*.net *.split]
galad has quit [*.net *.split]
fennewald has quit [*.net *.split]
Chagall has joined #ffmpeg-devel
kepstin has joined #ffmpeg-devel
natto has joined #ffmpeg-devel
graphitemaster has joined #ffmpeg-devel
stazthebox has joined #ffmpeg-devel
bcheng has joined #ffmpeg-devel
Hobbyboy has joined #ffmpeg-devel
fennewald has joined #ffmpeg-devel
galad has joined #ffmpeg-devel
MyNetAz has quit [Write error: Connection reset by peer]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
omegatron has joined #ffmpeg-devel
<haasn>
what's the difference between declare_func() and declare_func_emms() and when should I call one or the other? what values should I pass for the cpu_flags when using the latter?
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 246 seconds]
jamrial has joined #ffmpeg-devel
rvalue- is now known as rvalue
<JEEB>
haasn: empty mmx state :D
<haasn>
ah
<JEEB>
> Must be executed at the end of a MMX computation before floating-point operations
<wbs>
to be strictly correct, MMX functions should issue emms before returning. but most of them don't, and assume it will be taken care of by the caller at some point (for performance reasons). this either checks that functions that are supposed to call emms really did, and/or does the calling of emms for you
<Lynne>
this sounds like something which made sense 20 years ago but makes no sense today
<Lynne>
*25 years ago
<wbs>
AFAIK emms is expensive enough that it still makes sense to do, if you do use MMX functions. the general sentiment is of course that we should stop using MMX and the whole issue would go away
<Gramner>
emms is fine on amd but on intel that instruction can take more time than an entire small dsp function
<Gramner>
but yes, the proper long-term solution is to get rid of mmx
<wbs>
there's been some small-scale progress on that recently, luckily
TheSashmo has quit [Read error: Connection reset by peer]
TheSashmo has joined #ffmpeg-devel
Lynne has quit [Remote host closed the connection]
SuperFashi has quit [Ping timeout: 276 seconds]
SuperFashi has joined #ffmpeg-devel
Lynne has joined #ffmpeg-devel
<elenril>
surely an llm could do it
zsoltiv has joined #ffmpeg-devel
cubicibo has quit [Quit: Client closed]
kasper93 has quit [Ping timeout: 244 seconds]
kasper93 has joined #ffmpeg-devel
Marth64 has quit [Read error: Connection reset by peer]
Marth64[m] has joined #ffmpeg-devel
zsoltiv has quit [Remote host closed the connection]
zsoltiv has joined #ffmpeg-devel
zsoltiv has quit [Remote host closed the connection]
zsoltiv has joined #ffmpeg-devel
MyNetAz has quit [Ping timeout: 252 seconds]
MyNetAz has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<ramiro>
wbs: regarding those patches I had reordering smlal instructions with sequences of the same destination register, instead of interleaving the instructions with different destination registers, do you have a suggestion on how this could be well explained in the commit messages? I'm having a hard time coming up with an explanation about the functioning of the cpu itself and why it's faster.
<wbs>
ramiro: the in-order CPUs have fastpaths for repeated accumulation into the same register
<ramiro>
wbs: thanks!
<Lynne>
didn't know that, I've avoided doing this
<Lynne>
does it still work for vectors/floats?
MyNetAz has quit [Ping timeout: 252 seconds]
Traneptora has joined #ffmpeg-devel
MyNetAz has joined #ffmpeg-devel
MyNetAz has quit [Excess Flood]
LaserEyess has quit [Ping timeout: 252 seconds]
ccawley2011_ has joined #ffmpeg-devel
LaserEyess_ has joined #ffmpeg-devel
Arsen has quit [Ping timeout: 252 seconds]
Arsen has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 248 seconds]
LaserEyess_ has quit [Client Quit]
LaserEyess has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 245 seconds]
ccawley2011__ has quit [Ping timeout: 245 seconds]
\\Mr_C\\ has joined #ffmpeg-devel
MyNetAz has joined #ffmpeg-devel
Marth64[m] has quit [Quit: Leaving]
Marth64 has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<fflogger>
[newticket] names_are_hard: Ticket #11344 ([swresample] av_clip functions, use of uninitialised value) created https://trac.ffmpeg.org/ticket/11344
ngaullier has quit [Remote host closed the connection]
Traneptora has quit [Quit: Quit]
<fflogger>
[newticket] names_are_hard: Ticket #11345 ([swscale] yuv2rgb functions, use of uninitialised value) created https://trac.ffmpeg.org/ticket/11345
System_Error has quit [Remote host closed the connection]
<names_are_hard>
This is in ref to my patch attempt, in thread "Add support for LJ92 compressed MLV files, attempt 02"
<names_are_hard>
Bug summary: ffmpeg should probably use calloc() more
System_Error has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
nasso has joined #ffmpeg-devel
<nasso>
hello! i spotted a very minor typo in an example and i tried submitting a patch for it. i never used send-email before and i'm not subscribed to the mailing list. do i need to subscribe to send my patch (even if it's very minor and probably won't need further discussion)? i sent the email but im not sure how i can verify that i did everything correctly and that it was received
<nasso>
also something to note: the email in my commits (nasso - at - kyber.media) is different from the email i use to send the patch (my personal gmail address)
<BtbN>
Mails from non-subscribers are held
<names_are_hard>
Be aware that the mailing list publishes your full email address, too. The instructions were poorly worded in that area
<nasso>
if i were to subscribe should i use my personal email or my professional alias (which just forwards to my personal email but i can't send emails from that one)
<nasso>
names_are_hard: yeah i assumed so anyway
<BtbN>
Whatever you prefer really
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
ccawley2011_ has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 276 seconds]
<pross>
names_are_hard: about mlv lj92 support, your mjpeg patch unfortunately breaks bayer dng decoding. i get a "Could not get a pixel format descriptor." error when attempting to load dng files
<pross>
there are no bayer dngs in fate samples
<names_are_hard>
Then I don't feel very bad about breaking it, but that still wants fixing. Are you looking at attempt_02? Those patches are different to first attempt
<pross>
yeah testing your latest patches. i have another question. how do you propose to use the output? decoding mlv with your patches produces a grayscale image.
<names_are_hard>
It produces a colour image here
<names_are_hard>
Could you provide a bayer dng sample that breaks?
<names_are_hard>
Now I get a third behaviour: LJ92 compressed files don't play at all. Suggesting something in master broke them as I rebased for this test
<pross>
strange, i can decode lj92 mlv, its just the output is gray. and this is what i expect, since mjpegdec sets pix_fmt to AV_PIX_FMT_GRAY16LE
<pross>
i am on master too
<names_are_hard>
Ah no that was just me being an idiot and using system ffmpeg
<BtbN>
Hm, do I dissect this to find the actually useful parts? The patch looks so messy for something that should be simple: https://github.com/BtbN/FFmpeg/pull/2
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 260 seconds]
<BtbN>
Does ff_isom_write_vpcc work for both VP8 and VP9?
<BtbN>
Doesn't look like it, based on the code at least
<wbs>
iirc vp8 wasn't speced for all that many containers
<BtbN>
Yeah, I don't think ffmpeg is currently able to produce that VP8 configuration record
jamrial has quit []
ccawley2011_ has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 260 seconds]
___nick___ has quit [Ping timeout: 248 seconds]
___nick___ has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 272 seconds]
ccawley2011_ has quit [Ping timeout: 272 seconds]
Traneptora has joined #ffmpeg-devel
graphitemaster has quit [Ping timeout: 260 seconds]
graphitemaster has joined #ffmpeg-devel
<names_are_hard>
pross: you're right, it is gray, but it's tinted enough that I was fooled, I was filming something mostly grey
<names_are_hard>
However - this is no worse than before. LJ92 compressed and non-compressed are both gray
<names_are_hard>
I'm surprised by this, given format is detected as: "rawvideo (BIT[16] / 0x10544942), bayer_rggb16le"
<names_are_hard>
You can consider bayer to be 4 channels of gray. I was assuming that would go into something that would unbayer before display, and thus be colour. Any guesses on why it isn't, or how to do that?
<pross>
names_are_hard: correct, gray is an improvement about before, but its not very usable. colors would be nice. auto whitebalance would be even nicer.
aaabbb_ is now known as aaabbb
aaabbb has quit [Changing host]
aaabbb has joined #ffmpeg-devel
TheSashmo has quit [Read error: Connection reset by peer]
TheSashmo has joined #ffmpeg-devel
<names_are_hard>
It's reading the wb vals from the metadata. I have no idea how to tell ffmpeg to debyaer
<names_are_hard>
Thinking about it, it's fine that it doesn't debayer by default - you might want to output to some other container that holds bayer. An option would be nice
<pross>
another wild thought: modify mlvdec to add tiff dng header to the lj92 frames?
<names_are_hard>
local LJ92 ffplay displays that dng you sent fine
<names_are_hard>
Forcing dng format output is undesirable, being able to transcode to dng is desirable (something like ffmpegfs would be nice for ML users, so they can transparently use a NLE of their choice)