00:03 <fflogger> [editedticket] compn: Ticket #11556 ([avformat] Apply sensible FourCC for H.265 in AVI) updated https://trac.ffmpeg.org/ticket/11556#comment:2

00:04 <compn> avi files are so old now

00:04 <compn> why why must i read bugreports about them :D

00:04 <compn> why would you put h265 in avi

00:04 <compn> whyyyyyy

00:57 <fflogger> [editedticket] compn: Ticket #11515 ([avcodec] Consider NV12 / P010 output pixel format support) updated https://trac.ffmpeg.org/ticket/11515#comment:11

00:58 <compn> when a problem comes along, 'patches welcome'

01:27 <fflogger> [editedticket] compn: Ticket #11547 ([ffmpeg] Support for SEGA CD/MEGA CD video and audio codecs used in Road Avenger videogame) updated https://trac.ffmpeg.org/ticket/11547#comment:2

01:27 <compn> writing a sega cd video decoder from emulator source code might be a fun gsoc student qualification task ^

01:33 <fflogger> [editedticket] compn: Ticket #11530 ([avformat] Corrupted MP4 due to unfinished "moov atom" writing) updated https://trac.ffmpeg.org/ticket/11530#comment:3

01:49 <fflogger> [editedticket] compn: Ticket #6091 ([avcodec] support ds2 audio (dss pro audio) file format) updated https://trac.ffmpeg.org/ticket/6091#comment:19

01:56 <fflogger> [editedticket] compn: Ticket #11492 ([ffmpeg] Support for QuickTime skin file) updated https://trac.ffmpeg.org/ticket/11492#comment:4

02:00 <compn> Lynne, were some of the bugs re ffv1 vulkan from this report fixed/wontfixed/invalid? https://trac.ffmpeg.org/ticket/11352 . the 4.9gb from nvidia vs 41gb filesize difference made with intel ?

02:01 <Lynne> oh, that one got fixed

02:02 <Lynne> some sub-issues mentioned aren't

02:02 <Lynne> let's leave it open for a bit longer

02:02 <compn> no problem i leave it alone :)

05:59 <cone-827> ffmpeg softworkz master:1a083a4d90bc: fftools/ffmpeg: Include elapsed-time in print_report()

05:59 <cone-827> ffmpeg softworkz master:7a05f57250b6: avutil/opt: Print default option value for AV_OPT_TYPE_INT64

05:59 <cone-827> ffmpeg softworkz master:3a93fadac1ca: avformat/dump: Stream start offsets: change precision and label

05:59 <cone-827> ffmpeg softworkz master:26429eee22d6: libavformat/asfdec: Fix regression bug when reading image attachments

05:59 <cone-827> ffmpeg softworkz master:1dbc5675c18d: fftools/ffprobe: Disable stderr buffering on Windows

05:59 <cone-827> ffmpeg softworkz master:b322640b4f08: fftools/ffmpeg: Log exit code on exit

14:34 <fflogger> [editedticket] merolac: Ticket #11547 ([ffmpeg] Support for SEGA CD/MEGA CD video and audio codecs used in Road Avenger videogame) updated https://trac.ffmpeg.org/ticket/11547#comment:3

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

15:13 <kasper93> Why AV_PKT_DATA_FRAME_CROPPING exists and is not propagated in AVFrame::crop_* ?

16:09 <ramiro> haasn: I'm rebasing the asmjit branch on your latest swscale6 branch. there are a few issues I'd like to have fixed on your branch so it makes rebasing easier. also, what do you think about not force pushing into this branch anymore, to make it easier to follow the changes? a subsequent branch (swscale7) could then have the fixups merged, but this would make it easier to track the code.

16:10 <ramiro> haasn: 1) op_pass_run doesn't need to be av_always_inline, since it's used by function pointer

16:13 <ramiro> haasn: 2) in_stride and out_stride from SwsOpExec don't seem to be used. instead, you use "exec.{in,out}[i] += {in,out}.linesize[i];" in op_pass_run(). but it would be better to use {in,out}_stride, so that the same functionality could be done by the backend (which has access to exec, but not {in,out})

16:16 <ramiro> haasn: 3) could you move the y loop from op_pass_run() to SwsCompiledOp's func? the backend should be able to do the vertical loop itself. in my previous code I had added x_end and y_end to SwsOpExec and hacked a break out of the loop, but it would be cleaner if this was fixed in your branch instead.

16:18 <ramiro> haasn: 4) could you make sure the SwsContext *ctx passed to ff_sws_ops_compile() already contains the correct values for {src,dst}_format? I use it for debugging purposes (to create a proper function name in asmjit)

16:33 <another|> nevcairiel:

16:33 <another|> oops, sorry

16:52 <cone-430> ffmpeg Michael Niedermayer master:f99f223eb1ac: avformat/hls: Split allowed_segment_extensions off allowed_extensions

16:52 <cone-430> ffmpeg Michael Niedermayer master:75be669ca1c9: avformat/hls: Fix flash1.bogulus.cfd support

16:52 <cone-430> ffmpeg Michael Niedermayer master:26bbca84dea7: postproc/tests: Add test for temporal denoise

16:52 <cone-430> ffmpeg Michael Niedermayer master:917c15435ae2: libpostproc: check minimum size

16:52 <cone-430> ffmpeg Michael Niedermayer master:71e25beb5c91: postproc/tests/blocktest: use dimensions

16:52 <cone-430> ffmpeg Michael Niedermayer master:fd9adbdbfbd5: postproc/postprocess_template: fix dering with a 16x16 image

16:52 <cone-430> ffmpeg Michael Niedermayer master:d153b0053499: postproc/tests/stripetest: use dimensions

16:52 <cone-430> ffmpeg Michael Niedermayer master:fc3035e3c4da: postproc/tests/blocktest: initialize qp array randomly to for testing

16:52 <cone-430> ffmpeg Michael Niedermayer master:7faa560f1a36: postproc/tests/blocktest: Test several filter combinations

17:23 <TheVibeCoder> when the new release is coming?!?

17:57 <jkqxz> Is there any opinion on whether/how to do error concealment when AV_CODEC_FLAG_OUTPUT_CORRUPT is set?

17:58 <jkqxz> Currently I just don't write the error regions, so they probably contain data from a previous frame in the pool.

17:59 <jkqxz> Filling the bad blocks in the component with (1 << bit_depth - 1) seems reasonable, but that will be weirder when you lose one of the chroma components.

18:00 <jkqxz> Filling the bad blocks across all components is really annoying because they can be in different slice threads, though.

18:01 <TheVibeCoder> i think output_corrupt was added to always display frames even with error in decoding, now should or should not it and how to attempt conceal errors is another problem, just that with that flag output should clearly at least memset uninitialized memory blocks

18:01 <kierank> TheVibeCoder: +b

18:01 <kierank> traitors not allowed here

18:02 <kierank> TheVibeCoder: this is transparent project, all infrastructure is documented

18:02 <kierank> in l**rempeg all is controlled by one person

18:02 <kierank> FFmpeg is not like that

18:03 <TheVibeCoder> M$ controls all librempeg infrastructure

18:03 <kierank> do you use microsoft office for PRs?

18:04 <TheVibeCoder> off topic

18:04 <kierank> lol

18:06 <jkqxz> TheVibeCoder: Yeah, that's what I'm reading OUTPUT_CORRUPT as.

18:06 <jkqxz> Just looking at the output not writing the blocks appears nicest because you generally get something very related from a previous frame (though threading-dependent).

18:07 <TheVibeCoder> well, decoder output should not depend on thread setup

18:07 <jkqxz> But indeed not writing them at all seems bad. (What if someone is decoding naughty videos in another thread of the same process...)

18:09 <TheVibeCoder> decoder should produce always defined results, with no undefined behavior, aka leaving uninitialized memory or having serious undefined behavior bugs in code itself with or without errors in bitstream

18:10 <mkver> jkqxz: The default get_buffer callback will not reuse the buffer of a different AVCodecContext; if a user-supplied get_buffer does it, then that is up to the user.

18:10 <mkver> TheVibeCoder: Uninitialized data in a buffer is not UB.

18:14 <TheVibeCoder> get buffer usually by default always memset whole buffer

18:14 <TheVibeCoder> but pure av_malloc() does not

18:45 <TheVibeCoder> lol, on this CPU ardftsrc=48000:thread_type=frame is now faster than default settings of aresample=48000:resampler=swr

18:47 <kierank> Memset to black is slow

18:49 <TheVibeCoder> write SIMD code

18:51 <TheVibeCoder> could be 5th asm ffmpeg lesson

19:04 <kierank> We did, still slow

21:37 <fflogger> [newticket] Hackerpcs: Ticket #11573 ([ffmpeg] WebSocket (wss) streaming support) created https://trac.ffmpeg.org/ticket/11573

22:39 <fflogger> [editedticket] oromit: Ticket #11573 ([ffmpeg] WebSocket (wss) streaming support) updated https://trac.ffmpeg.org/ticket/11573#comment:1