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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
jarthur_ has joined #ffmpeg-devel
jarthur has quit [Ping timeout: 240 seconds]
feiwan1 has joined #ffmpeg-devel
thilo has quit [Ping timeout: 255 seconds]
thilo has joined #ffmpeg-devel
feiwan1 has quit [Ping timeout: 264 seconds]
feiwan1 has joined #ffmpeg-devel
<jamrial> BBB: is vvc sad for 8bit correct? fate doesn't exercise it
<jamrial> and the same c function is used for all bitdepths
<jamrial> the checkasm is limited to 10bit
<sdc> hi jamrial, the passed values are always 16bit ints even if the video bit depth is 8bit
<jamrial> i see
<sdc> I mentioned it in the commit msg of the other patch but I probably should add it to the checkasm commit / leave a comment as well
arch1t3cht8 has joined #ffmpeg-devel
cone-023 has joined #ffmpeg-devel
<cone-023> ffmpeg llyyr master:d1b96c380826: avformat/mov: avoid seeking back to 0 on HEVC open GOP files
lemourin has quit [Quit: The Lounge - https://thelounge.chat]
arch1t3cht has quit [Ping timeout: 264 seconds]
arch1t3cht8 is now known as arch1t3cht
lemourin has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
jamrial has quit []
jarthur_ has quit [Quit: jarthur_]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 268 seconds]
mkver has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
philipl has quit [Quit: leaving]
cone-023 has quit [Quit: transmission timeout]
rvalue has quit [Ping timeout: 252 seconds]
philipl has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
ngaullie has joined #ffmpeg-devel
c1480 has quit [Ping timeout: 260 seconds]
quietvoid has quit [Remote host closed the connection]
quietvoid has joined #ffmpeg-devel
ngaullie has quit [Ping timeout: 260 seconds]
cubicibo has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 260 seconds]
Krowl has joined #ffmpeg-devel
elenril has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Lypheo2 has joined #ffmpeg-devel
signalhunter7 has joined #ffmpeg-devel
odrling_ has joined #ffmpeg-devel
staceee_ has joined #ffmpeg-devel
jluthra_ has joined #ffmpeg-devel
jkkm_ has joined #ffmpeg-devel
kylophone_ has joined #ffmpeg-devel
Son_Goku_ has joined #ffmpeg-devel
galad_ has joined #ffmpeg-devel
Kei_N has quit [Read error: Connection reset by peer]
Kei_N has joined #ffmpeg-devel
skinkie has joined #ffmpeg-devel
odrling has quit [Ping timeout: 268 seconds]
jluthra has quit [Ping timeout: 268 seconds]
jkkm has quit [Read error: Connection reset by peer]
graphitemaster has quit [Ping timeout: 268 seconds]
kylophone has quit [Read error: Connection reset by peer]
galad has quit [Remote host closed the connection]
Son_Goku has quit [Read error: Connection reset by peer]
staceee has quit [Read error: Connection reset by peer]
signalhunter has quit [Read error: Connection reset by peer]
Lypheo has quit [Read error: Connection reset by peer]
skinkie_ has quit [Ping timeout: 268 seconds]
odrling_ is now known as odrling
kylophone_ is now known as kylophone
Son_Goku_ is now known as Son_Goku
Lypheo2 is now known as Lypheo
jluthra_ is now known as jluthra
jkkm_ is now known as jkkm
staceee_ is now known as staceee
signalhunter7 is now known as signalhunter
emersion has quit [Ping timeout: 268 seconds]
graphitemaster has joined #ffmpeg-devel
emersion has joined #ffmpeg-devel
galad_ is now known as galad
<frankplow> mkver: WDYM by "prefer loop-based iterators"?
<mkver> Use loop scope for iterators
<mkver> for (unsigned i = 0;
<frankplow> Ah, I see
<frankplow> Is it okay to shadow i in such a case?
<mkver> IMO yes.
<mkver> I always use loop-scope when I have to touch the line containing the for anyway, even if it leads to shadowing (of course, it sometimes also allows to remove the outer "int i" altogether).
System_Error has joined #ffmpeg-devel
<frankplow> Makes sense
Krowl has joined #ffmpeg-devel
OLGA69 has joined #ffmpeg-devel
OLGA69 has quit [Client Quit]
cubicibo has quit [Quit: Client closed]
<Lynne> courmisch: I figured, but how did they get even less memory bandwidth than a 908?
Krowl has quit [Read error: Connection reset by peer]
cubicibo has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
novaphoenix has quit [Quit: i quit]
novaphoenix has joined #ffmpeg-devel
<courmisch> Lynne: and single thread scalar perf worse than VF2, which is the current FATE hardware
<courmisch> although 8 threads would be faster than 4... if there is enough RAM for 8 clangs or gccs in 4 GiB
Krowl has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 240 seconds]
cubicibo has quit [Quit: Client closed]
rvalue has joined #ffmpeg-devel
<Lynne> a 908 has a single core, this has 8, if the bandwidth is 1/8th of that with all CPUs running, oof
<courmisch> FATE is on a VF2 with NVMe, not a K230 and a TF card
cone-356 has joined #ffmpeg-devel
<cone-356> ffmpeg James Almer master:3d1597d3e2ff: x86/vvc_alf: use the x86inc instruction macros
Krowl has quit [Read error: Connection reset by peer]
<courmisch> I'll try to switch to eMMC and see
<BBB> I wonder how my last round of review made vvc-sad faster (128x128: 1070 -> 860 cycles)
<BBB> it was just cleanups or out of loop optimizations
<BBB> nothing inloop afaics
<BBB> weird
<BBB> noise I suppose?
<kurosu> No idea, but yeah, most x86 numbers are meaningless without enough iterations, or warm up, or... In a way, the START/STOP_TIMER are neat because they try to take into account outliers (that should be due to the OS or processes doing things in benchasm's back, and not merging numbers that could be way too different) to converge to a somewhat nicer number
<courmisch> x86 is forbidden arcane dark magic, so...
<kurosu> I wonder how much is due to how deep/precise the OOE is. What is the impact of a context switch, or something that throws off/empties the branch predictor
<Lynne> impact of a context switch would be quantized to the linux kernel timer frequency
<Lynne> branch predictor issues would go on top of that, not sure how mitigations are done these days
Krowl has joined #ffmpeg-devel
<jdek> im seeing up to 50% variance in --bench results even at 262k samples using rdtime, will try rdcycle again but it makes it really hard to bench anything reasonably
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<Lynne> but its secure
blb has quit [Quit: brb]
blb has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<cone-356> ffmpeg Andreas Rheinhardt release/7.0:935279b85572: avcodec/x86/vp3dsp_init: Set correct function pointer, fix crash
<cone-356> ffmpeg Andreas Rheinhardt release/6.1:ab4fcc06ce95: avcodec/x86/vp3dsp_init: Set correct function pointer, fix crash
merbanan has joined #ffmpeg-devel
* Sean_McG peeks in
<cone-356> ffmpeg Andreas Rheinhardt release/6.0:90a59f9e4889: avcodec/x86/vp3dsp_init: Set correct function pointer, fix crash
Krowl has quit [Read error: Connection reset by peer]
<cosminaught> when it comes to modifying AVDOVIRpuDataHeader do fields have to go to the end? It seems like it would be better to keep them matching the RPU syntax, and I think this was the intention based on the commit that added them
<cosminaught> > In order to be able to extend this struct later (as the Dolby Vision RPU evolves), all of the 'container' structs are considered extensible, and the individual constituent fields must instead be accessed via offsets.
<mkver> cosminaught: If you add something in the middle of a struct, direct access to all the fields after the field you just added will no longer work, because their offset changes.
<cosminaught> understood, but I think this is not intended to use direct access and instead must be accessed via offsets
<mkver> The constituent "fields" meant here are the substructures, not the individual basic members.
<mkver> You do not understand: Accessing a AVDOVIDmData via a AVDOVIDmData* works via direct accesses (after all, we provide no getter for AVDOVIDmData.level (or for its offset in AVDOVIDmData)); only retrieving a pointer to the substructures from the containing AVDOVIMetadata* works via offsets.
<cosminaught> I very well might not understand, that's why I'm asking for clarification
<cone-356> ffmpeg Andreas Rheinhardt release/4.3:78cf22f3990f: avcodec/x86/vp3dsp_init: Set correct function pointer, fix crash
<cone-356> ffmpeg Andreas Rheinhardt release/4.4:abe6b3fb3819: avcodec/x86/vp3dsp_init: Set correct function pointer, fix crash
<cone-356> ffmpeg Andreas Rheinhardt release/5.0:43de07cd2032: avcodec/x86/vp3dsp_init: Set correct function pointer, fix crash
<cone-356> ffmpeg Andreas Rheinhardt release/5.1:41c2da99f7ed: avcodec/x86/vp3dsp_init: Set correct function pointer, fix crash
<cosminaught> ok, sent v3 which moves these fields to the end and bumps the lavu minor version
Livio has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<JEEB> cosminaught: basically it would work if the struct's contents would be strictly private and all external users would see would be more or less a void pointer with a named type. and then all access would go through functions or so. (or you don't give API users any ways of accessing what's in the thing
<Sean_McG> mkver: I had a thought for the patches reads where you are checking for non-zero and returning -- is it possible any of those reads could set errno to EAGAIN?
<cosminaught> I thought that was the intent based on the commit message, but not seeing anything to facilitate that so perhaps it never materialized (or I misunderstood the intent)
<JEEB> I don't recall that being there ever since actual RPU parsing got in, since projects like libplacebo would just utilize the struct members
<mkver> Sean_McG: What patches?
<Sean_McG> the coverity ones you posted recently, there's quite a few of them
<mkver> The ffio_ensure_seekback ones?
<JEEB> kasper93: god I think it just dawned me how lulz the code in hls_read_header must be looking at https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240317023628.1936-1-kasper93@gmail.com/ again
<mkver> JEEB: The muxer isn't really better.
<JEEB> yea
<JEEB> I have looked at that as well as the dash components
<Sean_McG> I was talking more generally, but was thinking specifically of ones like avformat/dhav and matroskaenc ff_put_wav_header() ones
<Sean_McG> if handling EAGAIN in those is not the "done thing" I apologize
<mkver> Which should errno be set to EAGAIN on ff_put_wav_header() failure?
<haasn> cosminaught: the intent was for these structs to only be extended by adding members to the end
<haasn> but for the three structs to be extensible independently
<haasn> (hence them being variable size with offsets)
<mkver> The code for the Matroska muxer (and most muxers) would have to be rewritten for it to support the usecase of calling write_header a second time after the first one failed.
<Sean_McG> OK, fair enough. it was just a thought.
<mkver> If writing the header fails, the user can analyze the error and retry (with a new AVFormatContext with the necessary parameters set, so that it does not fail this time).
<JEEB> michaelni: with regards to tests failing with zlib-ng, did I understand it correctly that you and paul are of the opinion that we should invent our own zlib to get bitexact results everywhere? since most of the tests actually failing seem to be failing because the transcoding function always logs the size and hash of the output file
<JEEB> so I thought the more realistic way would be to add an option to the transcode shell function to allow for disabling of the size/checksum output
<JEEB> then there's one or so test which logs exact sizes of packets it's encoding, that's less simple although there as well I don't think the exact size of the packet matters?
<JEEB> as long as the packet has a correct timestamp and can be decoded into the expected image the result should be correct, no?
<JEEB> it's just being really annoying not being able to run FATE nicely
<JEEB> (I wonder how fedora works around it since they do package FFmpeg. do they just not run FATE?)
<Sean_McG> hmmm, do they publish their package build scripts?
<JEEB> yea
<Sean_McG> if their build.log is any indication, I don't think they do run FATE, no
<Sean_McG> (naughty naughty!)
<JEEB> this is the reason for all the test failures in F40 https://fedoraproject.org/wiki/Changes/ZlibNGTransition
<mkver> Does Debian actually consider switching to a different zlib, too?
<Sean_McG> not sure... where would they post that sort of thing, tracker.d.o?
<JEEB> apparently it just got packaged
<JEEB> May 2nd this year
<Sean_McG> oh wow, 3 year old bug
<JEEB> so I would be surprised if it would replace ye olde zlib any time soon
Livio has quit [Ping timeout: 272 seconds]
<JEEB> oh wait, david heidelberg in that thread seems to note that it's a step-by-step process
Livio has joined #ffmpeg-devel
<cone-356> ffmpeg Rémi Denis-Courmont master:910d281b2157: lavc/h263dsp: R-V V {h,v}_loop_filter
cubicibo has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
Livio has quit [Ping timeout: 264 seconds]
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #ffmpeg-devel
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<michaelni> JEEB if zlib-ng results in 5% loss in compression rate it should not be used. Also we have replaced other simple LZ compressors already. If zlib has unstable output it would be nice if it can be avoided. How complex is it to replace it?
<JEEB> I don't think it in general gave worse results since there were multiple cases where the packet size or such went down?
microchip_ has quit [Quit: There is no spoon!]
<JEEB> in other words, I recall there being one or couple which went upwards, and then others that went downwards
<JEEB> as for complexity, I have no idea. haven't mapped what we're utilizing from the library
<JEEB> also apparently one of the r'aison d'etre of zlib-ng seems to be merging the various SIMD from various other zlib forks
microchip_ has joined #ffmpeg-devel
<JEEB> and finally, I would like to contribute something else to FFmpeg, not end up rewriting zlib :D
<JEEB> https://fedoraproject.org/wiki/Changes/ZlibNGTransition > The transition to Zlib-ng aims to enhance the compression efficiency and performance for Fedora while ensuring compatibility with existing packages and libraries.
<JEEB> so according to something, the overall compression efficiency is *supposed* to be better
s55 has quit [Quit: ZNC 1.9.0 - https://znc.in]
<michaelni> where 5% worse is "better"
<JEEB> was that in the failed test results I posted or are you basing on something else?
<michaelni> posted results
<JEEB> since I recall the test failures had cases going downwards, did you take an average of some sorts or did I miss something?
<michaelni> why would i care about the average ? :)
s55 has joined #ffmpeg-devel
<michaelni> one case is worse (by alot) so the code can be improved
<JEEB> or it's a case of different defaults, E_NO_IDEA unfortunately regarding that
<michaelni> why would ffmpeg use different defaults in a bitexact fate test ?
<JEEB> so you don't think it's a case of zlib-ng having different defaults? I don't think that requires explicit usage.
<JEEB> but as I said, I have no idea about how the defaults are different.
<michaelni> i think nothing, i just see zlib ng breaking fate, i see it being 5% worse and so i dont like it :)
s55 has quit [Quit: ZNC 1.9.0 - https://znc.in]
<Sean_McG> hi michaelni \o
<michaelni> JEEB, zlib ng should provide bitexact mode or someone should look at how hard it is to write a native one (not saying you need to)
<michaelni> hi
<michaelni> o/
s55 has joined #ffmpeg-devel
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<michaelni> if its too hard then we need to do something else but we should look first maybe its not hard ?
<JEEB> I'm not really caring about it with regards to likes & dislikes. just that does do somewhat different things, and it feels like the tests that are were not actually testing what the test tests with the bitexactness since in most cases it was just the file size/checksum that changed. then there's one test testing PNG attached image feature I think, and that didn't seem to actually require the packet
<JEEB> size there to check that it can be parsed as an image and that the provided image could be decoded.
<JEEB> *tests that are failing
<JEEB> if it was a test which seemed like it based on the bitexactness for something serious I'd feel a bit different
<michaelni> is zlib-ng matching zlib if compression is disabaled ?
___nick___ has joined #ffmpeg-devel
<JEEB> is some test doing bitexactness and setting that mode? if yes, then if that test is not within the ones I posted (and which are available @ https://megumin.fushizen.eu/random/fate-zlib-ng.diff ), it is still working
___nick___ has quit [Client Quit]
<michaelni> i have no idea, iam just wondering if some mode would still math between zlib and zlib ng
<michaelni> matCh
___nick___ has joined #ffmpeg-devel
<JEEB> it could, but I'm not sure how useful that is
<courmisch> guess who did a debootstrap and did not create a user account or root password
<michaelni> JEEB, that mode can be used in fate and then noone would have to look at zlib to find out how hard it is to write a native implementatin of what we need
<JEEB> then you're suddenly testing some parameter path which is not what production users will utilize. in which case encoding and then decoding and checking you're getting the same decoded image back (which some of the tests might already be doing) would be a more realistic check.
c1480 has joined #ffmpeg-devel
<JEEB> bitexactness is simple to check for, but is it actually helping to verify what these failing FATE tests are testing?
<michaelni> its better to test the muxer output than not to
<michaelni> if we canot then we cant but it should not be the first choice
<JEEB> but it is being tested in many of these cases by them decoding the result?
<JEEB> because for me the first idea after seeing that most of them were just the default size & checksum which you cannot disable in the shell function, that there could be an option added to the transcoding shell function to control if the test wants that thing to get disabled
<JEEB> meanwhile the remux function doesn't have that checksum and file size stuff to begin with
<michaelni> everything should be tested, muxer output demuxer output decoder output
<JEEB> thus one of the tests could be fixed easily by switching to stream_remux https://github.com/jeeb/ffmpeg/commits/zlib_ng_fixups
<JEEB> I agree that everything should be tested, but were these tests that are now failing actually trying to test what is now causing the difference?
<JEEB> but sure, if you think all these tests explicitly chose to have the size and checksum there, then I will just raise my hands and give up for now
<JEEB> I will just have to remember each time I try to add something to have the commits updating those FATE test results in all of my branches, and get annoyed when I forget
<JEEB> btw, the idea of using a specific config or something is not bad, but I just think it makes sense to test the code path that's probably going to get utilized in actual usage :)
<courmisch> -bash: make: komentoa ei löydy
<courmisch> funny that configure does not complain about that
cone-356 has quit [Quit: transmission timeout]
s55 has quit [Quit: ZNC 1.9.0 - https://znc.in]
<courmisch> 26 minutes to build FFmpeg, not too bad
s55 has joined #ffmpeg-devel
ngaullie has joined #ffmpeg-devel
cone-071 has joined #ffmpeg-devel
<cone-071> ffmpeg Michael Niedermayer release/7.0:4197c3203b63: avfilter/signature_lookup: Dont copy uninitialized stuff around
<cone-071> ffmpeg Michael Niedermayer release/7.0:ba031f8771d2: avfilter/signature_lookup: Fix 2 differences to the refernce SW
<cone-071> ffmpeg Michael Niedermayer release/7.0:1dbfdd2d306d: avfilter/vf_thumbnail_cuda: Set ret before checking it
<cone-071> ffmpeg Michael Niedermayer release/7.0:53868f5193d6: doc/examples/qsv_transcode: Simplify loop
<cone-071> ffmpeg Michael Niedermayer release/7.0:ad26b2d05a4c: avcodec/cbs_h2645: Check NAL space
<cone-071> ffmpeg Michael Niedermayer release/7.0:70191fc0a6bd: doc/examples/qsv_transcode: Simplify str_to_dict() loop
<cone-071> ffmpeg Michael Niedermayer release/7.0:6b42ba2094e6: doc/examples/vaapi_transcode: Simplify loop
<cone-071> ffmpeg Michael Niedermayer release/7.0:7fa0143d7e02: doc/examples/qsv_transcode: Initialize pointer before free
<cone-071> ffmpeg Michael Niedermayer release/7.0:62d3e4fd2981: avcodec/hevcdec: Check ref frame
<cone-071> ffmpeg Michael Niedermayer release/7.0:a0577e9877ef: avcodec/pngdec: Check last AVFrame before deref
<cone-071> ffmpeg Michael Niedermayer release/7.0:c42248f46648: avcodec/ac3_parser: Check init_get_bits8() for failure
<cone-071> ffmpeg Michael Niedermayer release/7.0:e806d36b3860: avcodec/atrac9dec: Check init_get_bits8() for failure
<cone-071> ffmpeg Michael Niedermayer release/7.0:dba4b859d86b: avformat/kvag: Check sample_rate
<cone-071> ffmpeg Michael Niedermayer release/7.0:0e44de3b9b5c: avformat/mxfdec: Check body_offset
<cone-071> ffmpeg Michael Niedermayer release/7.0:9a4199c71b69: avfilter/avfiltergraph: return value of ff_request_frame() is unused
<cone-071> ffmpeg Michael Niedermayer release/7.0:ec35ed8bb2d1: avcodec/avs2_parser: Assert init_get_bits8() success with const size 15
<cone-071> ffmpeg Michael Niedermayer release/7.0:13ef4f209f64: avcodec/avs3_parser: assert the return value of init_get_bits()
<cone-071> ffmpeg Michael Niedermayer release/7.0:c5671e9de91c: avcodec/av1dec: bit_depth cannot be another values than 8,10,12
<cone-071> ffmpeg Michael Niedermayer release/7.0:8170914a34b6: avcodec/av1dec: Change bit_depth to int
<cone-071> ffmpeg Michael Niedermayer release/7.0:ccd7fe3c6727: swscale/output: Fix integer overflow in yuv2rgba64_1_c_template
<cone-071> ffmpeg Michael Niedermayer release/7.0:ef9d59defb10: swscale/output: Fix integer overflow in yuv2rgba64_full_1_c_template()
<cone-071> ffmpeg Michael Niedermayer release/7.0:0047b51b8dc1: avcodec/wavarc: fix integer overflow in decode_5elp() block type 2
<cone-071> ffmpeg Michael Niedermayer release/7.0:c8ffda5684d1: avcodec/amrwbdec: assert mode to be valid in decode_fixed_vector()
<cone-071> ffmpeg Michael Niedermayer release/7.0:67ca3a5ee7d4: avcodec/mpegvideo_enc: Fix 1 line and one column images
<cone-071> ffmpeg Michael Niedermayer release/7.0:4eccabcc262a: avformat/concatdec: Check file
<cone-071> ffmpeg Michael Niedermayer release/7.0:c8a9e355146e: doc/examples/demux_decode: Simplify loop
<cone-071> ffmpeg Michael Niedermayer release/7.0:4d920afb8258: tools/opt_common: Check for malloc failure
<cone-071> ffmpeg Michael Niedermayer release/7.0:44b0e6a99f1d: fftools/ffplay: Check return of swr_alloc_set_opts2()
<cone-071> ffmpeg Michael Niedermayer release/7.0:559dd6f68af7: avcodec/cbs_av1: Avoid shift overflow
<cone-071> ffmpeg Michael Niedermayer release/7.0:b9985f105ed5: libavutil/base64: Try not to write over the array end
<cone-071> ffmpeg Michael Niedermayer release/7.0:9eb6558fa91e: avutil/tests/base64: Check with too short output array
<cone-071> ffmpeg Michael Niedermayer release/7.0:e94527f38fdb: avcodec/lpc: copy levenson coeffs only when they have been computed
<cone-071> ffmpeg Michael Niedermayer release/7.0:402a2c730f9e: avcodec/h264_slice: Remove dead sps check
<cone-071> ffmpeg Michael Niedermayer release/7.0:15de2a9b9690: avcodec/h2645_sei: Remove dead checks
<cone-071> ffmpeg Michael Niedermayer release/7.0:271c364eb59c: avcodec/fmvc: remove dead assignment
<cone-071> ffmpeg Michael Niedermayer release/7.0:b01e6a7e0b96: avcodec/decode: decode_simple_internal() only implements audio and video
<cone-071> ffmpeg Michael Niedermayer release/7.0:14bd2b4b87ce: avcodec/exr: Fix preview overflow
<cone-071> ffmpeg Michael Niedermayer release/7.0:1e67935ab196: avcodec/qsvdec: Check av_image_get_buffer_size() for failure
<cone-071> ffmpeg Michael Niedermayer release/7.0:8c5358c617ef: avcodec/jpeg2000dec: remove ST=3 case
<cone-071> ffmpeg Michael Niedermayer release/7.0:7f05002e05e8: avcodec/vp8: Forward return of ff_vpx_init_range_decoder()
<cone-071> ffmpeg Michael Niedermayer release/7.0:3a0320e95a76: avcodec/vp3: Replace check by assert
<cone-071> ffmpeg Michael Niedermayer release/7.0:68763d6a6ffc: avcodec/vble: Check av_image_get_buffer_size() for failure
<cone-071> ffmpeg Michael Niedermayer release/7.0:b27c156c1558: avcodec/vvc/dec: Check init_get_bits8() for failure
<cone-071> ffmpeg Michael Niedermayer release/7.0:c250e3b101d9: avcodec/vqcdec: Check init_get_bits8() for failure
<cone-071> ffmpeg Michael Niedermayer release/7.0:39da4ac79b34: avcodec/mpeg12dec: Use 64bit in bit computation
<cone-071> ffmpeg Michael Niedermayer release/7.0:b4fdbbe6aa80: avcodec/mpeg4videodec: assert impossible wrap points
<cone-071> ffmpeg Michael Niedermayer release/7.0:435b74c6a5d4: avcodec/mpegvideo_enc: Fix potential overflow in RD
<cone-071> ffmpeg Michael Niedermayer release/7.0:a49a8dc0d69b: avcodec/mscc & mwsc: Check loop counts before use
ngaullie has quit [Ping timeout: 268 seconds]
cubicibo has quit [Quit: Client closed]
<cone-071> ffmpeg James Almer master:3bd7e3a33682: avformat/vvc: initialize some ptl flags
<cone-071> ffmpeg James Almer master:2d84ee374528: avformat/vvc: fix parsing sps_subpic_id
<cone-071> ffmpeg James Almer master:3146b77a7d31: avformat/mov: store sample_sizes as unsigned ints
<cone-071> ffmpeg James Almer release/7.0:1a6995c6d687: avformat/vvc: initialize some ptl flags
<cone-071> ffmpeg James Almer release/7.0:85d4df387347: avformat/vvc: fix parsing sps_subpic_id
ccawley2011 has quit [Read error: Connection reset by peer]
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
mkver has quit [Ping timeout: 260 seconds]
feiwan1 has quit [Ping timeout: 252 seconds]
feiwan1 has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 268 seconds]
IndecisiveTurtle has quit [Ping timeout: 268 seconds]
wyatt8740 has quit [Remote host closed the connection]
<Lynne> does anyone have a link to the old GSoC final report/code dump database?
<Lynne> not our ancient 2007/8-era gsoc, I'm looking for 2021's
kurosu has quit [Quit: Connection closed for inactivity]
<cone-071> ffmpeg Stone Chen master:0e52a4e43475: libavcodec/x86/vvc: Add AVX2 DMVR SAD functions for VVC
<cone-071> ffmpeg Stone Chen master:2e877090f958: tests/checkasm: Add check_vvc_sad to vvc_mc.c
wyatt8740 has joined #ffmpeg-devel