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 6.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<Traneptora> haasn: film_grain_params.c, line 77
<Traneptora> there's a continue; but it's inside a do { } while (0);
<Traneptora> so does it actually do anything?
<Traneptora> wouldn't that just break out of the do loop
<Traneptora> you might need a label
<Traneptora> or to just remove the do/while
<iive> do {} while() executes at least once
<iive> do {} while(0) executes exactly once
<iive> and the continue is probably used as a way to avoid using goto.
<Lynne> IndecisiveTurtle: two reasons, blocking artifacts and signalling overhead
<Lynne> haar by itself is a lossless transform, as are all wavelet transforms
<Lynne> but once you start to quantize the coefficients, the block edges quickly start to diverge, so you get discontinuities
<Lynne> signalling overhead because with smaller blocks, you'll have more blocks to encode
any1 has quit [Read error: Connection reset by peer]
any1 has joined #ffmpeg-devel
lexano has quit [Ping timeout: 245 seconds]
<Traneptora> iive: no, the issue in this case is that inside the do while(0) is a continue statement guarded by if and *nothing else*
<Traneptora> the intent is likely to continue the outer loop, but it won't work since it's inside a dowhile0
<iive> yeh, in this case continue and break do the same thing.
<Traneptora> ye, but it looks like an oversight, hence my patch
<iive> oh, there is nothing after the continue, that's the whole thing.
<iive> you might want to keep the {} brackets.
<iive> hum... in this case I think it would be better if "check" is just the if() part, so the usage is something like "CHECK(fgp->luma, bit_luma, 0) continue;" or even
<iive> if( check(fgp->luma, bit_luma, 0) ) continue;
<Traneptora> indeed, the CHECK is just the if part, as in the patch Isent
<Traneptora> I think it doesn't matter much
<Traneptora> point is just to deduplicate code
Livio has quit [Ping timeout: 256 seconds]
iive has quit [Read error: Connection reset by peer]
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
thilo has quit [Ping timeout: 272 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
<haasn> Traneptora: thanks, I hate C
<Traneptora> haasn: already sent a patch to ML
lemourin has quit [Quit: The Lounge - https://thelounge.chat]
lemourin has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
<Lynne> every few hours when I open my mail client there's like 20 posts on the ML
jamrial has quit []
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
Martchus has quit [Ping timeout: 268 seconds]
Martchus has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
Marth64 has quit [Remote host closed the connection]
<Lynne> what's the state of YUVJ removal?
rvalue has quit [Ping timeout: 252 seconds]
rvalue has joined #ffmpeg-devel
Guest52 has quit [Quit: Ping timeout (120 seconds)]
microchip__ has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 255 seconds]
microchip__ is now known as microchip_
Guest52 has joined #ffmpeg-devel
Guest52 has quit [Ping timeout: 250 seconds]
<galad> is there a way to print the exact ffmpeg invocation a fate test uses?
j-b has quit [Ping timeout: 260 seconds]
j-b has joined #ffmpeg-devel
<Lynne> V=1?
<galad> yes, it was actually on the fate doc page, sorry for the noise
\\Mr_C\\ has quit [Remote host closed the connection]
ramiro has joined #ffmpeg-devel
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
ramiro has quit [Ping timeout: 255 seconds]
ramiro has joined #ffmpeg-devel
<Lynne> jkqxz: 2nd ping to take a look at https://github.com/cyanreg/FFmpeg/tree/av1dec2
ramiro has quit [Ping timeout: 255 seconds]
ramiro has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
elastic_dog has quit [Ping timeout: 256 seconds]
elastic_dog has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 260 seconds]
SystemError has quit [Ping timeout: 260 seconds]
SystemError has joined #ffmpeg-devel
Teukka` has quit [Read error: Connection reset by peer]
Teukka has joined #ffmpeg-devel
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Krowl has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
<haasn> Lynne: waiting for review on the AVCodec fields which are a prerequisite to deprecating/deleting YUVJ
<jkqxz> Lynne: I'm confused by why both ref[i] and ref[i]->saved_order_hints are now separate arguments to fill_pict?
microchip_ has joined #ffmpeg-devel
<jkqxz> Agree that RefFrameSignBias in that form seems like the cleanest way to get what the specification asked for.
microchip_ has quit [Client Quit]
Dariusz has quit [Ping timeout: 272 seconds]
Dariusz has joined #ffmpeg-devel
microchip_ has joined #ffmpeg-devel
microchip_ has quit [Quit: There is no spoon!]
<jkqxz> No further comments, looks good.
jamrial has quit []
jamrial has joined #ffmpeg-devel
microchip_ has joined #ffmpeg-devel
microchip_ has quit [Client Quit]
microchip_ has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
Dariusz has quit [Ping timeout: 260 seconds]
Dariusz has joined #ffmpeg-devel
<llyyr> hasn't yuvj been deprecated for years already
<JEEB> yes
<JEEB> from like 10 years ago
<JEEB> but basically a bunch of avfilter etc based on just pix_fmt for stuff
<JEEB> thankfully that is no longer the case, but still some stuff left
<haasn> right now it's encoders
<haasn> filters no longer use yuvj, nor do decoders
Marth64 has quit [Ping timeout: 272 seconds]
Marth64 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Dariusz has quit [Ping timeout: 272 seconds]
Dariusz has joined #ffmpeg-devel
jamrial has quit [Ping timeout: 252 seconds]
Krowl has joined #ffmpeg-devel
cone-304 has joined #ffmpeg-devel
<cone-304> ffmpeg Henrik Gramner master:782c4df28dc9: x86: Avoid using 'd' as an argument name
<cone-304> ffmpeg Henrik Gramner master:afa471d0efed: x86: Update x86inc.asm
jamrial has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
<Marth64> ffmpeg -i hello #ffmpeg_devel
<Traneptora> haasn: do you have any objections to https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=11252
<Traneptora> if not will merge
<haasn> Traneptora: both LGTM
<haasn> I was actually going to submit the unused variable fix myself today
<Traneptora> beat u too it :)
<cone-304> ffmpeg Leo Izen master:438fcc3f6e0c: avutil/film_grain_params: remove unused variables
<cone-304> ffmpeg Leo Izen master:ac21582e5334: avutil/film_grain_params: remove do loop in CHECK macro
Marth64 has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Livio has quit [Quit: leaving]
Marth64 has quit [Ping timeout: 272 seconds]
<Lynne> jkqxz: one is for the ref struct itself, the other is the current frame's saved order hints
unlord has quit [Changing host]
unlord has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
kasper93 has quit [Ping timeout: 255 seconds]
Guest1 has joined #ffmpeg-devel
<jkqxz> Lynne: Why the separate argument given that the saved order hints are inside ref, though?
Guest1 has quit [Ping timeout: 250 seconds]
<Lynne> they are?
<Lynne> aren't they cbs-only, and we don't save the whole cbs context for each ref
Krowl has joined #ffmpeg-devel
ramiro has quit [Ping timeout: 255 seconds]
ramiro has joined #ffmpeg-devel
<mkver> Marth64: inttypes.h us typically implicitly included from common.h (which is auto-included basically everywhere).
<mkver> s/us/is/
ramiro has quit [Ping timeout: 264 seconds]
ramiro has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
cone-304 has quit [Quit: transmission timeout]
___nick___ has joined #ffmpeg-devel
<Traneptora> mkver: I suggested it cause implicit transitive inclusions are bad
<mkver> And I agree with that.
<Traneptora> ye, the code compiles b/c intttypes.h is transitively included, but I suggested he make it explicit
<mkver> I hate unnecessary inclusions, but changing it would often require removing inclusions from public headers which might break users.
<Traneptora> btw, the code itself has: memcmp(&read_buf[PCI_START_BYTE - 4], dvdvideo_nav_header, 4)
<Traneptora> dvdvideo_nav_header is a static const uint8_t[4]
<Traneptora> would it make more sense to define the dvdvideo_nav_header as a uint32_t with MKTAG, and then use AV_RL32(&read_buf[foo]) == dvdvideo_nav_header?
rvalue has quit [Ping timeout: 255 seconds]
<mkver> It will probably not make a difference. Compilers know memcmp (and memcpy).
<Traneptora> that is fair
<mkver> Anyway: This format is BE, so it should be AV_RB32(buf) == 0x000001BF.
<Traneptora> sure, tho if you were to MKTAG it the endianness would swap anyway
tufei has quit [Remote host closed the connection]
tufei has joined #ffmpeg-devel
<jkqxz> Lynne: I thought that was linked up in the generic code, but it isn't. Ignore that, then.
cone-174 has joined #ffmpeg-devel
<cone-174> ffmpeg Andreas Rheinhardt master:07064f9bdac3: avformat/demux: Restore pkt->stream_index assert check
<cone-174> ffmpeg Andreas Rheinhardt master:ccd2b7f858d2: avformat/demux: Combine "Packet corrupt" logmessages
<cone-174> ffmpeg Andreas Rheinhardt master:0d43adcbef9a: configure: Explicitly check for static_assert, _Static_assert
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
<mkver> Traneptora: A start code is not really a tag. And even if it were: If the endianness of MKTAG differs from the endianness of the format, then the former should be avoided.
<Traneptora> true
<mkver> bye MSVC 19.27.
<Lynne> jkqxz: thanks for looking at it
rvalue has joined #ffmpeg-devel
<BtbN> Anyone able to look at the vf_stack patch? Depending on input resolution, it straight up heap overflows right now.
<BtbN> The patch is most definitely not the correct solution, so I'd like to figure out how to fix it correctly.
Krowl has quit [Read error: Connection reset by peer]
tufei has quit [Remote host closed the connection]
tufei has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 268 seconds]
rvalue- is now known as rvalue
jamrial has quit []
jamrial has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
<Marth64> seems cc_dec silently skips text sometimes when switching normal->italic->normal
<Marth64> will look into it sometime
Guest52 has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
marcj has quit [Ping timeout: 240 seconds]
tufei has quit [Quit: Leaving]
<cone-174> ffmpeg Marton Balint master:e6c2c8703732: avformat/mov_chan: respect channel order when parsing and creating chan atom
tufei has joined #ffmpeg-devel
<cone-174> ffmpeg Marton Balint master:9a5627ea9a21: avfilter/af_channelmap: fix error message if FL source channel was missing
<cone-174> ffmpeg Marton Balint master:1bea3e9ee2f3: avfilter/af_channelmap: fix mapping if in_channel was a string but out_channel was not specified
<cone-174> ffmpeg Marton Balint master:2f754a96bd4a: avfilter/af_channelmap: disallow channel index 64
<cone-174> ffmpeg Marton Balint master:bba6dd391f4e: avfilter/af_channelmap: factorize checking indexes against a channel layout
<cone-174> ffmpeg Marton Balint master:eaca78eff832: avfilter/af_channelmap: add some additional checks for the mappings
<cone-174> ffmpeg Marton Balint master:f1e34f158276: doc/filters: extend af_channelmap documentation
IndecisiveTurtle has quit [Ping timeout: 255 seconds]
___nick___ has quit [Ping timeout: 255 seconds]
AbleBacon has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
SystemError has quit [Ping timeout: 260 seconds]
Marth64 has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg-devel
IndecisiveTurtle has quit [Remote host closed the connection]
kasper93 has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
Marth64 has quit [Remote host closed the connection]
kurosu has quit [Quit: Connection closed for inactivity]
<Traneptora> haasn: $ ffplay -v debug -i https://0x0.st/XsZe.jpg -vf libplacebo=color_trc=iec61966-2-1:color_primaries=bt709:format=gbrp
<Traneptora> this hangs, but ffmpeg.c works fine with it
<Traneptora> (as does plplay/mpv)
<Traneptora> any idea why?
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Livio has quit [Ping timeout: 264 seconds]
cone-174 has quit [Quit: transmission timeout]
HarshK23 has quit [Quit: Connection closed for inactivity]