04:36 <Lynne> so when are we getting a webcodecs api?

06:08 <cone-332> ffmpeg Fei Wang master:ae9cf903e823: cbs_av1: Copy loop filter and segment parameters of repeat frame from its mapped frame

06:24 <rajivharlalka> had seen a wiki link few days/weeks? ago regarding beginner friendly issues on ASM, does anyone still have it

09:21 <jdek> rajivharlalka: https://trac.ffmpeg.org/wiki/SmallASMTasks but I think it is quite out of date

10:58 <Daemon404> Lynne, what do you mean? webcodecs is a js api

11:00 <wbs> Daemon404: yes, but consider if you build ffmpeg (or just the libraries) with wasm; you may want to call the webcodecs api from regular C code in there, rather than plumbing that all up to the js level

11:04 <Daemon404> ... no

11:04 <Daemon404> sounds oerverse

11:04 <Daemon404> perverse*

11:05 <wbs> TBH, it's not much different than using JNI to call out to java APIs for MediaCodec on android

11:05 <Daemon404> jni is exactly the cursed thing it made me think of

11:05 <wbs> whether you like it or not, your C code may be running inside some sort of sandbox, and it's totally ok to reach out and call things in it

11:06 <Daemon404> i can acknowledge it is a thing people want while still maintaining itnis terrible

11:06 <Daemon404> i get it now tho

11:06 <Daemon404> no idea who has the willpower to inplement it

12:42 <rajivharlalka> jdek thanks. let me check if I can find things relevant else maybe this could be updated?

12:59 <cone-479> ffmpeg Frank Plowman master:54291f43837b: lavc/vvc: Fix assertion bound on qPy_{a,b}

13:08 <Lynne> I was only talking about having an external webcodecs api without ever thinking anyone would want to have an internal decoder/encoder for webcodec APIs

13:09 <Lynne> zero interest or anything ofc, its just the new thing I hear

14:12 <cone-479> ffmpeg Nuo Mi master:3d2fafa2294b: avcodec/vvcdec: fix potential deadlock in report_frame_progress

15:00 <smandelli> Dear all, I would like to discuss about a decoding problem. The same version of ffmpeg (same dll, lib) produces two different results, and it depends on my implementation. Both `ffplay` and my decoder implementation return the error `non-existing PPS1 referenced` `slice type 32 too large at 20607` `no frame!` but ffplay is able to reproduce the video with no artifacts, while my implementation based on send_packet/receive_frame

15:00 <smandelli> shows artifacts like pixelization, during motion, the next frame has some residuals of the previous one etcc....

15:00 <smandelli> I am wondering where is the difference

15:01 <smandelli> in particular, I don't have any particular control for error like i cited before, Should I add some control?

15:02 <smandelli> My program is based on the same dll of ffplay, so the problem is definitely in my implementation

15:06 <cone-479> ffmpeg Ramiro Polla master:b6f7271fa914: avcodec/x86/mpegvideoenc: remove av_assert2() for variable alignment

15:15 <cone-479> ffmpeg Ramiro Polla master:4f7aeffd8c36: avcodec/mpegvideo: remove redundant workaround to recalculate last nonzero coefficient

15:22 <Lynne> hardware decoders are not robust towards mislabelled units, but he left anyway, so

15:23 <Lynne> I have a weird legit scene sample which someone somehow encoded with incorrectly IDd units, wonder how that happened

15:48 <cone-479> ffmpeg Ramiro Polla master:3f9b78bd190e: avcodec/dnxhdenc: use BlockDSPContext from MpegEncContext

22:43 <Lynne> could someone review the hw_base_encode changes? tong wu seems to be busy

22:44 <Lynne> the first change is trivial and tested, only moves DPB image allocation to the common code

22:44 <Lynne> the second change moves the entire VAAPI SPS/PPS generation to a common file

22:44 <Lynne> jkqxz maybe you?