03:17 <fflogger> [newticket] ksthey: Ticket #11551 ([ffmpeg] [HEVC] Incorrect PCM Coding Block Length Derivation For YUV400) created https://trac.ffmpeg.org/ticket/11551

11:43 <cone-937> ffmpeg Lynne master:5098b1a34545: vulkan: move feature<->usage mapping code outside of hwcontext_vulkan.c

11:43 <cone-937> ffmpeg Lynne master:cee34e0a550e: vulkan: check that the max number of push descriptors is not exceeded

11:43 <cone-937> ffmpeg Lynne master:96ddce1b3c11: vulkan: move OPT_CHAIN out of hwcontext_vulkan

11:43 <cone-937> ffmpeg Lynne master:3bb2b8aff4f0: hwcontext_vulkan: enable subgroupSizeControl

11:49 <ramiro> haasn: on neon, with interleaved writes, it's a single instruction (st3).

11:54 <Lynne> it's not going to be faster though

11:54 <Lynne> most ARM cpus can do 2 loads/1 store or 1 load/2 stores per cycle, same as most of x86

11:55 <Lynne> so it'll be split up by uops and dispatched after a cycle

11:55 <Lynne> you save on 4 bytes, but decoding is never a bottleneck on arm

11:56 <Lynne> and also st/ld have that total PIA quirk where the registers have to be numerically sequential

11:57 <Lynne> unlike x86, you don't have access to assembler register renaming, which would make this more tolerable to write

11:58 <BBB> neon has all these cool instructions *jealous*

11:58 <BBB> can you guys port some of them to avx1024?

12:00 <Lynne> neon has no fast immediate shuffles, this trumps any "neat" instructions

12:00 <Lynne> its like having world class cheese, tomatoes, chorizo, mushrooms, but no dough for a pizza, so you have to eat with your hands

12:00 <haasn> is SSE4 less common than SSSE3?

12:01 <haasn> I guess not practically, because they're both part of x86-64-v1

12:02 <Lynne> I believe only early athlons from 2001 had ssse3 but no sse4

12:04 <Lynne> the other way around, amd had ssse3 and sse4 on the same gen, intel lacked sse4 on peryn only

12:04 <Lynne> https://store.steampowered.com/hwsurvey says its negligible, and either way, they're 20 year old CPUs

12:45 <kurosu> You're forgetting about SSE4.1 and SSE4.2 XD

12:45 <kurosu> (or not, but just to pile up on x86)

14:11 <haasn> ramiro: wrote a full shuffle solver for x86, it can handle any sort of packed rgb(a) swizzle on any element size, and also handles byte swapping at the same time

14:12 <haasn> so we have a single fast path for e.g. rgb24 -> bgr0, or rgba -> rgb48be, or rgba64le -> bgra64be

14:12 <haasn> that all compile down to a single pshufb loop

14:13 <haasn> performance is blazing fast in all cases except the trivial rgba <-> bgra which is still slowed down by the high loop overhead

14:13 <haasn> but I will tackle that soon-ish

14:13 <haasn> (and even in that case it's like 5% slowdown)

15:08 <ramiro> haasn: nice!

15:09 <ramiro> Lynne: st3 might not be faster, but is it slower than manually packing + st1?

15:09 <ramiro> I've been told that might be the case with newer apple silicon, but I haven't had a chance to test any of it.

15:11 <Lynne> depends on the SoC, I would regard any chip which runs that slower as being a toy

15:12 <Lynne> ...but then again it's all just mostly toys in the arm world

16:28 <fflogger> [editedticket] rmader: Ticket #11515 ([avcodec] Consider NV12 / P010 output pixel format support) updated https://trac.ffmpeg.org/ticket/11515#comment:10

17:05 <BtbN> welp, github just banned the workflow that keeps the coverity runs alive

17:05 <BtbN> and also lowered the time until a repo goes inactive

17:06 <JEEB> \o/

17:06 <JEEB> what was the reasoning for the ban?

17:06 <BtbN> https://github.com/gautamkrishnar/keepalive-workflow

17:07 <BtbN> so from now on I'll have to remember to click the button again every 30 days

17:07 <BtbN> Or commit something every week or so

17:10 <fflogger> [editedticket] pal1000: Ticket #11435 ([avformat] Added "-extension_picky" breaks various applications) updated https://trac.ffmpeg.org/ticket/11435#comment:34

17:19 <jkqxz> Lynne: In what sort of context? Without messing with frequencies it gets 1080p~50 on one thread on a few-year-old laptop (Intel 4P+8E), or 1080p~500 with all threads.

17:35 <jkqxz> Lynne: "src/libavutil/vulkan.c:156:22: error: ‘VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PUSH_DESCRIPTOR_PROPERTIES’ undeclared"

17:36 <jkqxz> Some missing check? My headers are 1.4.309.

17:49 <jkqxz> michaelni: Can you explain what probetest is trying to do?

17:50 <jkqxz> It seems to have found a sequence of zero and one bytes which the demuxer accepts could be a valid apv file. I am unclear why that means failure?

18:04 <jkqxz> Adding a stronger check of the validity of profile (which I was avoiding because it is not currently meaningful for the decoder) just means it gets a bit further and finds a different sequence which is also plausibly a valid file and declares that a failure.

18:42 <michaelni> jkqxz, probetest check if any probe function claims a high certainity detection in random data.

18:43 <michaelni> as in "iam really sure this random data is a valid XXX file" is a failure

18:46 <jkqxz> It returns AVPROBE_SCORE_EXTENSION + 1 if it's a plausible match. Is that wrong? It looks like that is a common thing to do.

18:46 <jkqxz> (Presumably the intent of that is to beat an incorrect file extension.)

18:52 <cone-789> ffmpeg Marvin Scholz master:8129474b93a5: avformat/dashdec: use av_err2str

18:52 <cone-789> ffmpeg Marvin Scholz master:da38b2fcd229: tools/sidxindex: use av_err2str

18:52 <cone-789> ffmpeg Marvin Scholz master:b781f1836e67: tests: lavfi/drawutils: use av_err2str

18:52 <cone-789> ffmpeg Marvin Scholz master:cd96d2ed6a0b: avformat/crypto: use av_err2str

18:52 <cone-789> ffmpeg Marvin Scholz master:d0bcf62597a4: tools/aviocat: use av_err2str

18:52 <cone-789> ffmpeg Marvin Scholz master:a903d6dade3d: tools/ismindex: use av_err2str

18:52 <cone-789> ffmpeg Marvin Scholz master:d7d103c34c79: lavfi/vf_xpsnr: use av_err2str

18:53 <jkqxz> The probetest threshold of AVPROBE_SCORE_MAX/4 is AVPROBE_SCORE_RETRY.

18:53 <jkqxz> michaelni: Can you suggest what score should be returned for a plausible but uncertain match? It will sometimes hit in random data as seen here.

19:00 <cone-789> ffmpeg Marvin Scholz master:0ea83e65aa07: avfilter/drawutils: narrow variable scopes

19:01 <michaelni> cant the probe function read a few packets to check more ?

19:01 <michaelni> but the threshold is a good value to return for uncertain matches

19:03 <jkqxz> A single frame might easily be >1MB.

19:04 <jkqxz> I can look to see if there is another frame there anyway, that's fair.

19:05 <cone-789> ffmpeg Marvin Scholz master:cacc68f3b5f9: ffbuild: fix include path for uninstalled .pc files

19:05 <jkqxz> I'll see if I can add a bit more checking and return something slightly under the threshold value in any case. Thank you.

19:15 <ePirat> michaelni, should I add Signed-off-by with my name, when pushing a patch of someone else?

19:16 <jamrial> ideally

19:18 <fflogger> [newticket] jasperE: Ticket #11552 ([undetermined] A decoder returned an unexpected error code) created https://trac.ffmpeg.org/ticket/11552

19:20 <cone-789> ffmpeg Erik Linge master:09a83e095d84: rtpdec_mpeg4: Add fmtp parsing of bitrate value

19:24 <michaelni> ePirat, yes, thats what most people do

19:33 <toots5446> michaelni: Hi! If I attach a PTS to this metadata update and pass it to the frame only when it matches do you think that this would work for you?

20:13 <michaelni> toots5446, isnt there some existing cases where sidedata is passed from AVPackets to AVFrames, like in h264 or something. What i would hve thought is that the decoder as it decodes the AVPacket would take the sidedata and copy it to the corresponding AVFrame. If thats what should be done with it but maybe iam missing something

20:13 <michaelni> doing this independant of the decoder seem "hard"

20:15 <ePirat> is Gyan Doshi on irc?

20:18 <michaelni> toots5446, also look at AV_CODEC_FLAG_COPY_OPAQUE related code

21:07 <toots5446> Thanks for the pointer michaelni. This seems like a promising entry point indeed. Packet props are only saved if the codec has the FF_CODEC_CAP_SETS_FRAME_PROPS. Let me see if we can tap into it by always saving the last packet props regardless of the flag. The set is also conditional to the flag so this shouldn't change anything on that end.

21:13 <toots5446> michaelni: yeah I remember why I didn't use this though: I see cases with flac streams where packet->frame mapping is not 1:1. Two packets with PTS 0 come through in the tests.

21:14 <toots5446> Likewise, with vorbis, I see one packet with PTS 0 coming out with the metadata update before a frame with an actual PTS of 128 is decoded.

21:15 <toots5446> I think that this can all be addressed with the next set of patches which is planning on removing header packets from those streams. Perhaps I should switch around and send the patches removing header packets first?

21:32 <ePirat> michaelni, btw did you notice: libavcodec/ffv1enc.c:1444:39: warning: using floating point absolute value function 'fabs' when argument is of integer type

21:38 <toots5446> Ok I have extracted the part of the code that removes the ogg packet headers first, along with the test. It's pretty cool you can follow the changes from the test output diff.

21:38 <toots5446> Will submit.

21:41 <michaelni> toots5446, ok, will take a look, btw if someone else wants to take this set over, iam fine with that. it seems i have been a bit slow in replying to it

21:42 <michaelni> ePirat, didnt see that, thx

21:44 <ePirat> michaelni, would have sent a fix but I am not sure about the intention of the code there without spending some time to understand it further

21:45 <toots5446> Cool. Happy to work with whomever. But I have a feeling Lynne will like this new patchset I just sent: Remove chained ogg stream header packets from demuxer

21:51 <michaelni> ePirat, its a heuristic to minimize the size of the table it stores. log(score) ~ expected size. Whatever makes the table on average smaller is "correct"

21:51 <michaelni> ill check which way my testcase becomes smaller and send a patch

21:53 <ePirat> toots5446, why do you check for "if (!ret)" in ogg_packet?

21:53 <ePirat> given if ret is <0 that code would be unreachable anyway