[Ffmpeg-devel-irc] ffmpeg-devel.log.20170824

[burek]

[11:08:29 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07master:c42a1388a6d1: avformat/rtpdec_h264: Fix heap-buffer-overflow
[11:08:29 CEST] <cone-155> ffmpeg 03Dale Curtis 07master:37e8edc9f515: avformat/mov: Fix trampling of ctts during seeks when sidx support is enabled.
[12:01:59 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07master:2b44dcbc44e9: avcodec/hevc_ps: Check delta_pocs in ff_hevc_decode_short_term_rps()
[12:02:00 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07master:837cb4325b71: ffprobe: Fix null pointer dereference with color primaries
[12:02:01 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07master:351e28f9a799: ffprobe: Fix NULL pointer handling in color parameter printing
[12:51:38 CEST] <cone-155> ffmpeg 03Carl Eugen Hoyos 07master:cb1a3eecac2d: lsws/rgb2rgb: Add unscaled 48bit to 64bit rgb conversion.
[13:00:43 CEST] <cone-155> ffmpeg 03Carl Eugen Hoyos 07master:f61e2dcfc399: lavf/g726: Demuxer for raw G.726 streams, both left- and right-justified.
[14:12:25 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:8dc06a1cb151: avcodec/takdec: Fix multiple runtime error: signed integer overflow: 637072 * 4096 cannot be represented in type 'int'
[14:12:26 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:e3d4321739af: avcodec/pafvideo: Fix assertion failure
[14:12:27 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:e9c8fdbbcbb4: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: 53098 * 40448 cannot be represented in type 'int'
[14:12:28 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:bcdd5463f35d: avcodec/ac3dec_fixed: Fix multiple runtime error: signed integer overflow: -39271008 * 59 cannot be represented in type 'int'
[14:12:29 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:f4dae487906a: avcodec/indeo4: Check remaining data in Pic hdr extension parsing code
[14:12:30 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:5dc0393d9663: avcodec/flicvideo: Fix runtime error: signed integer overflow: 4864 * 459296 cannot be represented in type 'int'
[14:12:31 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:e3a75af7080c: avcodec/ra144: Fix runtime error: signed integer overflow: -2200 * 1033073 cannot be represented in type 'int'
[14:12:32 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:f0f9fa218460: avcodec/tiff: Fix leak of geotags[].val
[14:12:33 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:295b24643ecf: avcodec/aacdec_fixed: Fix runtime error: left shift of negative value -1297616
[14:12:34 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:d182bb21add5: avcodec/snowdec: Fix runtime error: left shift of negative value -1
[14:12:35 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:0dfda74afc8d: avcodec/wavpack: Fix runtime error: signed integer overflow: 1886191616 + 277872640 cannot be represented in type 'int'
[14:12:36 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:bc8fe5c4bdb4: avcodec/jpeg2000dwt: Fix runtime error: left shift of negative value -123
[14:12:37 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:0ac41463891c: avcodec/sbrdsp_fixed: Return an error from sbr_hf_apply_noise() if operations are impossible
[14:12:38 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:fd0da0eef007: avcodec/aacsbr_fixed: Check shift in sbr_hf_assemble()
[14:12:39 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:296b444a5caf: avcodec/mpeg4videodec: Fix integer overflow in num_sprite_warping_points=2 case
[14:12:40 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:7bca492cfcc7: avcodec/mpeg4videodec: Check sprite delta upshift against overflowing.
[14:12:41 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:c2562f5a8e0c: avcodec/hevc_refs: Check nb_refs in add_candidate_ref()
[14:12:42 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:c8733c73763f: avcodec/hevcdec: Check nb_sps
[14:12:43 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:92c5ff0763b8: avcodec/jpeg2000: Fixes integer overflow in ff_jpeg2000_ceildivpow2()
[14:12:44 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:eb38f232b4ed: avcodec/shorten: Sanity check maxnlpc
[14:12:45 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:c436af15596a: avcodec/jpeg2000dec: Check nonzerobits more completely
[14:12:46 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:1ce850f96da2: avcodec/hevcdec: Fix signed integer overflow in decode_lt_rps()
[14:12:47 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:ba23d53710ec: avcodec/hevcpred_template: Fix left shift of negative value
[14:12:48 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:0aa14c7f67b2: avcodec/jpeg2000dsp: Reorder operations in ict_int() to avoid 2 integer overflows
[14:12:49 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:5aa7d228cbad: avcodec/takdec: Fixes: integer overflow in AV_SAMPLE_FMT_U8P output
[14:12:50 CEST] <cone-155> ffmpeg 03Anton Mitrofanov 07release/2.8:365ab04b16ec: avcodec/h264_cabac: Fix CABAC+8x8dct in 4:4:4
[14:12:51 CEST] <cone-155> ffmpeg 03Anton Mitrofanov 07release/2.8:a85f8fd4a625: avcodec/h264_mb: Fix 8x8dct in lossless for new versions of x264
[14:12:52 CEST] <cone-155> ffmpeg 03Anton Mitrofanov 07release/2.8:ea73c4813d83: avcodec/h264: Fix mix of lossless and lossy MBs decoding
[14:12:53 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:cbc4f40d1372: avcodec/aacdec_fixed: Check s for being too small
[14:12:54 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:4afd24805954: avcodec/wavpack: Fix undefined integer negation
[14:12:55 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:b66e30ca7658: avcodec/mpeg4videodec: Fix overflow in virtual_ref computation
[14:12:56 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:5c818b62867d: avcodec/hevc_filter: Fix invalid shift
[14:12:57 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:be92b2702448: avcodec/tiff: Update pointer only when the result is used
[14:12:58 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:7fadd9625f71: avcodec/takdec: Fix integer overflow
[14:12:59 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:fe74c2364ee3: avcodec/wavpack: Fix integer overflow
[14:13:00 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:7ee48d9de118: avcodec/mpeg4videodec: Fix GMC with videos of dimension 1
[14:13:01 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:bd33b15fe6a6: avcodec/wavpack: Fix integer overflow in wv_unpack_stereo()
[14:13:02 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:bbcb59b94826: avcodec/apedec: Fix integer overflow
[14:13:03 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:a6e90e5998ab: avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int()
[14:13:04 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:f6954a1482f3: avcodec/vb: Check vertical GMC component before multiply
[14:13:05 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:a5e969dd28c2: avcodec/hevc_ps: Fix integer overflow with beta/tc offsets
[14:13:06 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:610bd595228b: avcodec/wavpack: Fix invalid shift
[14:13:07 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:82ba7646c249: avcodec/sbrdsp_fixed: Fix integer overflow in sbr_hf_apply_noise()
[14:13:08 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:080d6de9dfc1: avcodec/aacps (fixed point): Fix multiple signed integer overflows
[14:13:09 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:a84ed3d01137: avcodec/mjpegdec: Clip DC also on the negative side.
[14:13:10 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:1b1abf077d64: avcodec/aacdec_template (fixed point): Check gain in decode_cce() to avoid undefined shifts later
[14:13:11 CEST] <cone-155> ffmpeg 03Brice Waegeneire 07release/2.8:061be75481ed: doc/filters: typo in frei0r
[14:13:12 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:56e2ec0e9fea: avcodec/aacdec_fixed: fix: left shift of negative value -1
[14:13:13 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:91442fdc1c6e: avcodec/aacps: Fix multiple integer overflow in map_val_34_to_20()
[14:13:14 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:490b6599bbf4: avformat/oggparsecelt: Do not re-allocate os->private
[14:13:15 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:58ce199abac4: avcodec/hevc_ps: fix integer overflow in log2_parallel_merge_level_minus2
[14:13:16 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:b566ab49ca84: avformat/rtmppkt: Convert ff_amf_tag_size() to bytestream2
[14:13:17 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:8f9cbb3b7e84: avformat/rtmppkt: Convert ff_amf_get_field_value() to bytestream2
[14:13:18 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:406d9fdd1357: avcodec/takdec: Fix integer overflow in decode_subframe()
[14:13:19 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:95bbbbd14e44: avcodec/diracdec: Fix integer overflow in divide3()
[14:13:20 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:9d0eb81cb85c: avcodec/dirac_dwt: Fix multiple integer overflows in COMPOSE_DD97iH0()
[14:13:21 CEST] <cone-155> ffmpeg 03Steven Siloti 07release/2.8:f0f45d840453: avformat/utils: fix memory leak in avformat_free_context
[14:13:22 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:f236601e29b9: avcodec/h264_slice: Fix overflow in slice offset
[14:13:23 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:5f44aa14ddb2: avcodec/aacdec_fixed: fix invalid shift in predict()
[14:13:24 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:30a2c1a1b83f: avcodec/dirac_dwt: Fixes integer overflows in COMPOSE_DAUB97*
[14:13:25 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:96cf249751bb: avcodec/mpeg4videodec: Clear mcsel before decoding an image
[14:13:26 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:b463a0347636: avcodec/diracdec: Check perspective_exp and zrs_exp.
[14:13:27 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:7829a712bb5a: avcodec/snowdec: Fix off by 1 error
[14:13:28 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:0b37ae2ae475: avcodec/fic: Fixes signed integer overflow
[14:13:29 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:079849f40c52: avcodec/me_cmp: Fix crashes on ARM due to misalignment
[14:13:30 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:cab75cde0170: avcodec/aacdec_template: Fix running cleanup in decode_ics_info()
[14:13:31 CEST] <cone-155> ffmpeg 03Vitaly Buka 07release/2.8:05fc22f9f69e: avformat/mov: Fix signed integer overflows with total_size
[14:13:32 CEST] <cone-155> ffmpeg 03Vitaly Buka 07release/2.8:eaf231544f2f: avformat/aviobuf: Fix signed integer overflow in avio_seek()
[14:13:33 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:ae37bbef4368: avcodec/hevc_ps: Check delta_pocs in ff_hevc_decode_short_term_rps()
[14:13:34 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:c1a9f5675b95: ffprobe: Fix null pointer dereference with color primaries
[14:13:35 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:49839ae0139c: ffprobe: Fix NULL pointer handling in color parameter printing
[14:42:41 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07release/2.8:bc57c799704a: Update for FFmpeg 2.8.13
[14:47:35 CEST] <cone-155> ffmpeg 03Paul B Mahol 07master:f8d0689d3ff5: avfilter/vf_blend: rename addition128 and difference128 to grainmerge and grainextract
[15:41:59 CEST] <J_Darnley> I hate this rate control crap in vc2enc.  A circular dependency.  You need to know how large the coded frame will be before you can code it.
[15:43:27 CEST] <J_Darnley> All because a coded plane-slice uses single byte to show the size of itself.
[15:44:03 CEST] <J_Darnley> So you need to scale scale the true size by some factor so that it is <= 255
[15:45:21 CEST] <J_Darnley> To know that factor you need to know how large the largest plane-slice will be.
[15:56:01 CEST] <J_Darnley> I'm going to excise that slice byte counter
[15:56:38 CEST] <BtbN> So you are essentially forced to do a full two-pass run?
[15:57:44 CEST] <J_Darnley> Something like that, I think.
[15:58:36 CEST] <J_Darnley> Fortunately The first pass only appears to count the bits
[16:00:26 CEST] <J_Darnley> Also this links with the sliced multithreading it has: several independant PutBits are used and initialized to start at the right place in the output.
[16:02:13 CEST] <kierank> J_Darnley: bear in mind in our use case each row needs to be the same size
[16:02:16 CEST] <J_Darnley> Ah it is better after excising that count
[16:03:05 CEST] <J_Darnley> kierank: at present it all appears to encode into the same size
[16:03:10 CEST] <kierank> ok
[16:06:48 CEST] <bove> I am writing a demuxer for SGO Mistika files. They mostly decode as rawvideo, but it supports some pixel formats I can't decode correctly. Should I be a) writing custom pixel formats, b) patching rawdec or c) writing a new decoder?
[16:08:06 CEST] <bove> A few of them are stored as 3x10bits in a 32b DWORD. Can rawdec handle that?
[16:08:55 CEST] <J_Darnley> We akready have some like that, v210 spring to mind.
[16:08:59 CEST] <J_Darnley> *already
[16:09:11 CEST] <bove> I'll have a look at that
[16:09:33 CEST] <wm4> yeah, probably new raw decoder
[16:09:50 CEST] <wm4> we try to avoid adding obscure raw codecs as pixfmts these days
[16:10:15 CEST] <wm4> (thinhs like AV_PIX_FMT_BGR4_BYTE...)
[16:10:18 CEST] <wm4> *things
[16:10:44 CEST] <wm4> for 3x10 bits, it might actually be reasonable to add it as pixfmt
[16:10:48 CEST] <wm4> as long as it's byte aligned
[16:14:37 CEST] <bove> Yes. But I can't really understand the .comp part of the pixels format. Is it possible to define 3x10 plus padding in there?
[16:17:29 CEST] <wm4> yes
[16:17:49 CEST] <wm4> AV_PIX_FMT_AYUV64LE should be relatively similar
[16:17:56 CEST] <wm4> just that it uses 8 bits per component
[16:18:18 CEST] <wm4> the disadvantage with adding a new pixfmt is that you need to add support to libswscale....
[16:18:31 CEST] <wm4> a dedicated raw decoder might be simpler
[16:21:49 CEST] <bove> If I do a custom decoder, I would just swap the bytes to match one of the existing pix_fmts, right?
[16:22:07 CEST] <bove> I think the DPX decoder does the exact same thing
[16:22:20 CEST] <wm4> yes
[16:22:44 CEST] <wm4> considering that absolutely nobody hacks libswscale, that might be the easier route
[16:22:53 CEST] <wm4> *nobody _likes_ to hack libswscale
[16:24:17 CEST] <bove> Could I manipulate the data in the format's read_packet(), or is it better to do an encoder?
[16:25:05 CEST] <wm4> I think you could do that
[16:25:14 CEST] <wm4> maybe it's even preferable for something overly obscure
[16:25:33 CEST] <wm4> but if the container can use multiple codecs, a separate decoder would be better
[16:26:41 CEST] <bove> Ok. Thanks so far
[16:34:22 CEST] <BBB> J_Darnley: does the second pass only affect the bitstream writing? or does it require a full new r/d loop?
[16:34:30 CEST] <BBB> J_Darnley: or in other words, how big is the overhead?
[16:34:34 CEST] <BBB> should be small
[16:35:10 CEST] <J_Darnley> I don't know.
[17:16:13 CEST] <wm4> kierank: nicolas george is offensive as usual, but to make an argument that does not aim to piss off everyone: we still could have --disable-libavformat or such, and libffmpeg would not contain the libavformat API
[17:17:13 CEST] <kierank> true
[18:43:09 CEST] <durandal_1707> see, that happens when you do not remove ffserver
[19:01:48 CEST] <BBB> whos maintainer of ffserver again?
[19:03:05 CEST] <wm4> BBB: reynaldo 
[19:11:13 CEST] <jamrial> ffserver hasn't been fixed after the whole vote-to-postpone-its-removal stuff last november, so it's going to be removed with the upcoming bump
[19:11:41 CEST] <atomnuker> when is the next bump?
[19:12:23 CEST] <jamrial> as soon as i get the help i requested on the ml, or once the merges resume and reach that point in the queue
[19:13:30 CEST] <atomnuker> requested help?
[19:13:40 CEST] <atomnuker> what do merges have to do with anything?
[19:14:01 CEST] <jamrial> libav bumped major versions some months ago. the commit in question is in the merge queue
[19:14:21 CEST] <jamrial> we can wait until that's merged, or we can bump at this point
[19:15:43 CEST] <iive> there is somebody offerring a job to developer to maintain and fix ffserver 
[19:15:51 CEST] <iive> it's mail with "no subject"
[19:16:12 CEST] <wm4> oh is that another reason to postpone removal of this POS
[19:17:17 CEST] <jamrial> if someone magically fixes all ffservers problems in record time, then it can stay. but if not, it's going to be removed
[19:17:36 CEST] <jamrial> it's been like nine months since the whole postponing vote stuff and nobody touched it any further
[19:17:43 CEST] <jamrial> so i doubt it's going to be fixed
[19:18:07 CEST] <iive> well, if nobody takes the offer, then ffserver is doomed.
[19:19:18 CEST] <wm4> according to jamrial we're probably past this point
[19:20:37 CEST] <iive> oh, so he is not project leader. Sorry I haven't got the memo. ~~
[19:20:45 CEST] <iive> not/now
[19:21:19 CEST] <wm4> who is our project leader
[19:21:30 CEST] <jamrial> i'm saying what the vote decided
[19:21:47 CEST] <jamrial> if it was up to me, ffserver would have been removed in november
[19:22:25 CEST] <jamrial> after the vote it was decided that if ffserver couldn't be fixed before the next bump, it would be removed
[19:23:22 CEST] <iive> I thought it was fixed, that's why it remained.
[19:23:36 CEST] <jamrial> no, it wasn't
[19:24:26 CEST] <wm4> so let's hold another vote, where we decide to postpone ffserver removal again
[19:24:34 CEST] <iive> i do remember people complaining that the inital plan was to fix the bugs and then remove it, but after the bugfixing people wanted to keep it.
[19:24:37 CEST] <jamrial> I'd rather not
[19:24:48 CEST] <iive> but maybe it's about different bugs
[19:40:10 CEST] <kierank> 6:21 PM <wm4> who is our project leader
[19:40:16 CEST] <kierank> he who shalt not be named
[19:46:15 CEST] <wm4> if you mean HIM, he refuses that he is
[19:54:15 CEST] <kierank> it's a fiat leader
[19:54:17 CEST] <kierank> that's the problem
[20:08:53 CEST] <BBB> VOLDEMORT
[20:08:56 CEST] <BBB> so uh
[20:09:03 CEST] <BBB> is voldermort attending VDD? :-p
[20:09:08 CEST] <BBB> or how does this thing work
[20:09:31 CEST] <BBB> is this like the shadow government, you have the minions feuding in public and the real power people staying behind the shades?
[20:21:24 CEST] <BBB> [and there was silence]
[20:22:40 CEST] <Compn> where are you reading this from bbb ?
[20:22:48 CEST] <Compn> oh lol
[20:22:53 CEST] <BBB> :-p
[20:23:05 CEST] <Compn> kierank : you could nominate a leader and call a vote if you wanted
[20:23:48 CEST] Action: Compn ducks
[20:39:08 CEST] <cone-155> ffmpeg 03Paul B Mahol 07master:f0f48884b023: avfilter/af_sidechaincompress: switch to activate
[20:39:38 CEST] <Compn> kierank : i mean you could nominate yourself if youwanted 
[20:52:04 CEST] <durandal_1707> im potter and you are voldemort
[20:52:24 CEST] <jamrial> michaelni, durandal_1707: do you think you could remove coded_frame usage from vf_mcdeint and vf_uspp? they are apparently the only modules left using it
[20:52:58 CEST] <durandal_1707> just remove it
[20:53:23 CEST] <durandal_1707> nobody uses those voldermort filters
[20:57:35 CEST] <BBB> I think we just created a new meme :-p
[21:04:29 CEST] <wm4> I wonder if there's even a single user of those 2 filters
[21:04:56 CEST] <wm4> or of they are just the forgotten dead pets of the original authors
[21:08:35 CEST] <wbs> wm4: http://martin.st/temp/0001-Properly-specify-dllexport-for-data-symbols-shared-a.patch - proper use of dllexport doesn't seem to be insanely hard to do - this is only tested with msvc and in libav only, but should be a good base, in case you want to try to pursue this
[21:09:32 CEST] <wm4> wbs: interesting
[21:14:16 CEST] <BBB> wbs: oh wow thats pretty cool
[21:15:13 CEST] <wbs> for ffmpeg, there seems to be a few av_export in libavutil as well so it has to be expanded to av_export_avutil, and perhaps the av_export_avcodec definition should be somewhere in libavcodec/*.h, but you get the idea
[21:15:28 CEST] <michaelni> jamrial, i think these filters depend on the coded_frame API. Its possible to replace coded_frame with a different API of course but removing it without replacement would not work with the same efficiency
[21:15:37 CEST] <wbs> (this was my 15 minute idea of derailing your fight by providing a different solution) :P
[21:16:22 CEST] <jamrial> michaelni: so we just keep postponing the removal of coded_frame, then?
[21:16:41 CEST] <wm4> jamrial: lol
[21:16:47 CEST] <wm4> wbs: I thought it would be much more complex... anyway, would have to check whether it works with mingw as intended
[21:16:52 CEST] <jamrial> i'm surprised it could be removed from every other decoder and filter but not these two...
[21:17:07 CEST] <wm4> because they're filters ported from mplayer
[21:17:17 CEST] <wm4> all you need to know
[21:17:22 CEST] <michaelni> jamrial, these 2 actually acess the image 
[21:18:04 CEST] <michaelni> wm4, i dont think your mplayer reference is relevant or helpfull
[21:19:02 CEST] <wm4> michaelni: I don't think your insistance to keep these filters combined with a refusal to fix them is helpful
[21:19:58 CEST] <michaelni> wm4, please dont invent things about me
[21:19:59 CEST] <wbs> wm4: yeah - I think it should work for mingw if you change the defined(_MSC_VER) into a defined(_WIN32), but the map of functions to export works a bit differently so something might come up, anyway, I'll leave the rest to you
[21:20:23 CEST] <wm4> michaelni: I'm not inventing, but observing
[21:20:37 CEST] <RiCON> wbs: as long as it doesn't break 'shared ffmpeg with static libs' even more than it is now
[21:20:43 CEST] <jamrial> don't start a flame war for two filters, please
[21:21:01 CEST] <wm4> yeah, let's choose a less optimal solution because of two filters instead
[21:21:19 CEST] <RiCON> wbs: if some 3rd party lib uses dllimport, the .def only lists that lib's symbols, not ffmpeg's
[21:21:47 CEST] <wbs> RiCON: with mingw?
[21:21:50 CEST] <RiCON> yeah
[21:22:01 CEST] <RiCON> specifically with "shared ffmpeg + static external libs"
[21:22:10 CEST] <RiCON> static with static and shared with shared has no issues
[21:22:36 CEST] <wbs> oh, then this will make the .def contain those dllexports from the external libs + dllexports for all the av_export data
[21:23:01 CEST] <wbs> RiCON: if you want to fix that, hook up the script that we use for msvc to produce a def file prior to invoking the linker
[21:23:46 CEST] <durandal_1707> isnt coded frame just to mark keyframes?
[21:23:58 CEST] <wbs> actually, if you proceed with this dllexport patch with mingw in any normal case as well, you'll probably need to hook up that def script anyway
[21:24:23 CEST] <michaelni> durandal_1707, the 2 filters access the actual pixels
[21:24:45 CEST] <BBB> durandal_1707: it gives access to any portion of the compressed image (in decompressed form)
[21:24:51 CEST] <BBB> durandal_1707: flags, pixels, etc.
[21:25:17 CEST] <BBB> durandal_1707: think of it as the AVFrame if you decoded the compressed image again
[21:25:48 CEST] <michaelni> jamrial, one could add a flag to the used encoder and return the internal bitmap in the avpacket if its set or maybe encode + decode to the the frame, later would be slower
[21:26:09 CEST] <michaelni> then one could use that instead of coded_frame and remove it i think
[21:27:16 CEST] <michaelni> maybe iam missing some magic simpler solution ...
[21:28:09 CEST] <wm4> or we could just remove these obscure/rarely used filters that cause so much trouble
[21:28:36 CEST] <BBB> just expose coded_frame in some internal form (codec-specific property, some internal api only for those encoders)
[21:28:54 CEST] <BBB> I dont think anyone cares about coded_frame except for it being in AVCodecContext
[21:28:55 CEST] <jamrial> we don't even know yet if dropping coded_frame as is will work even without considering those two filters
[21:29:04 CEST] <BBB> if its anywhere else thats not AVCodecContext, I think nobody cares
[21:29:26 CEST] <BBB> OneBigStruct { everything; // FIXME }; is not a good design ;)
[21:29:44 CEST] <BBB> (remember dsputil? :D)
[21:30:04 CEST] <BBB> o o o and mpegvideoenc!!!! woohoo \o\ /o/ \o/
[21:30:13 CEST] <BBB> (which was used in h264dec)
[21:30:13 CEST] <jamrial> that one still exists, though :p
[21:30:41 CEST] <BBB> michaelni: I think people are trying to make ffmpeg more maintainable, codec_frame is fine, just not in AVCodecContext
[21:31:04 CEST] <BBB> michaelni: so just expose it as a codec-private option and I think youre fine
[21:31:20 CEST] <BBB> (or as you said, side-data in a AVPacket)
[21:31:32 CEST] <BBB> just not AVCodecContext
[21:31:45 CEST] <michaelni> it should be something that doesnt require memcpy but is properly ref counted
[21:32:10 CEST] <BBB> side-data refcounting sounds like a good idea
[21:40:15 CEST] <iive> is codec_frame about keeping the quantizers of macroblocks?
[21:43:41 CEST] <iive> no, it isn't
[23:23:42 CEST] <jamrial> alright, libavcodec compiles after a bump and fate passes. we only need to fix or postpone at most four deprecated apis/functionality older than two years
[23:35:16 CEST] <nevcairiel> Why do filters even have access to AVCodecContext in the first place, that seems wrong on do many levels
[23:36:30 CEST] <jamrial> that's what BBB was saying. coded_frame doesn't need to be in avcodeccontext
[23:37:17 CEST] <BBB> struct OneBigThing { everything; /* FIXME */ }; <- ffmpeg
[23:38:07 CEST] <nevcairiel> How do they get to that context even? Do they make their own?
[23:38:52 CEST] <nevcairiel> Would definitely be nice to get rid of coded_frame, at least from that public struct
[23:41:29 CEST] <jamrial> nevcairiel: the two filters above do that, yes. alloc, open2, encode2, then look at coded_frame
[23:42:10 CEST] <nevcairiel> Is the content of that different then the frame they input?
[23:42:30 CEST] <nevcairiel> Seems a bit silly considering they originally had the frame :p
[23:44:53 CEST] <nevcairiel> But side_data is recounted so (optionally) attaching it there might work
[23:45:38 CEST] <nevcairiel> Or wait, maybe sidedata wasn't refcounted
[23:45:43 CEST] <nevcairiel> I forget
[23:58:46 CEST] <iive> they don't want the input frame, they want the frame that is the result of encoded and then decoded frame.
[23:59:48 CEST] <iive> decoding is part of the encoder, as they need the reference frames.
[00:00:00 CEST] --- Fri Aug 25 2017