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

[burek]

[00:02:02 CET] <philipl> in init_output_stream_encode perhaps?
[00:11:45 CET] <philipl> nevcairiel: So I want to say this ends up requiring us to propagate the colour range through the filter context appropriately because a filter might alter the colour range - you can't just copy from dec_ctx to enc_ctx.
[00:15:30 CET] <atomnuker> jkqxz: oh wow, so vaapi can't map drm frames on amd? since you get more than 1 object and vaapi can't map more than that
[00:16:15 CET] <jkqxz> philipl:  Right.  IIRC you said before that you can't actually get the 4:2:2 output for those anyway, so it doesn't matter in that case.
[00:16:49 CET] <jkqxz> atomnuker:  I haven't added it yet.  I had had enough Intel-wrangling for one release cycle.
[00:18:18 CET] <philipl> jkqxz: yeah. So, I'd like to get the nvdec mjpeg support in, seeing as it doesn't depend on fixing this yuvj mess. I was going to resend your hwaccel hooks minus the yuvj hack.
[00:23:40 CET] <jkqxz> Did you resolve whether it has standard tables and keeps them across images so that non-full MJPEG streams work?
[00:26:27 CET] <jkqxz> (Or do you need to rebuild the tables and inject them into the stream for those cases?)
[00:31:57 CET] <philipl> To the extent that I can test it, I belive it handles it correctly.
[00:32:47 CET] <philipl> Do you have a sample?
[00:41:22 CET] <Chloe> mmh. So my patch for lavfi breaks memory allocation which breaks threads. I'll debug further tomorrow
[01:29:41 CET] <jkqxz> philipl:  <https://0x0.st/sTl-.mjpeg>  (Failing to show the first A is allowable.)
[01:30:52 CET] <jkqxz> ((That is, I don't think any real streams will ever do that, though in theory they could.  ffmpeg does not currently handle it.))
[01:34:12 CET] <philipl> jkqxz: it works.
[01:34:41 CET] <philipl> mpv won't detect it, but I was able to transcode with nvdec successfully, modulo that it decoded to 4:2:0 nv12
[01:34:42 CET] <jkqxz> -BCABC or ABCABC?
[01:35:22 CET] <philipl> BCABB I think
[01:35:47 CET] <philipl> Which is the same as I get with software decoding
[01:37:01 CET] <philipl> (This color_range passing through avfilter is fun...
[01:37:37 CET] <jkqxz> -BCABC then.  Ok, good, at least weird splicing isn't needed.  (I have been forced into that before with TI's decoder and webcam streams, hence wanting to check these cases...)
[01:38:05 CET] <jkqxz> If we are giving up on YUVJ then it shouldn't be too hard to make it actually work, I'll look at it again tomorrow evening.
[01:48:06 CET] <cone-784> ffmpeg 03Xiaohan Wang 07release/2.8:07e46226ae50: avcodec/h264_cavlc: Set valid qscale value in ff_h264_decode_mb_cavlc()
[01:48:07 CET] <cone-784> ffmpeg 03Michael Niedermayer 07release/2.8:6cfd81b04c71: avcodec/h264_cabac: Tighten allowed coeff_abs range
[01:48:08 CET] <cone-784> ffmpeg 03Michael Niedermayer 07release/2.8:a3c66132d957: avutil/common: Fix integer overflow in av_clip_uint8_c() and av_clip_uint16_c()
[01:48:09 CET] <cone-784> ffmpeg 03Michael Niedermayer 07release/2.8:09dad5239002: avcodec/exr: Check remaining bits in last get code loop
[01:48:10 CET] <cone-784> ffmpeg 03Michael Niedermayer 07release/2.8:603d23ffebdd: avcodec/vp8: Check for bitstream end before vp7_fade_frame()
[01:48:11 CET] <cone-784> ffmpeg 03Michael Niedermayer 07release/2.8:3f8a0d5ad1a9: Changelog: update
[02:00:02 CET] <philipl> jkqxz: cheers.
[02:00:31 CET] <philipl> I wonder how far down this rabbit hole I need to go. Functional parity means handling codecpar and ffmpeg_filter stuff.
[02:29:42 CET] <cone-784> ffmpeg 03Michael Niedermayer 07n2.8.14:HEAD: avcodec/dirac_dwt_template: Fix Integer overflow in horizontal_compose_dd137i()
[03:04:37 CET] <ltrudeau> I'm working on Chroma from Luma for AV1, I never wrote any Neon (intrinsics) before. Any advice on how can make this better would be greatly appreciated https://aomedia-review.googlesource.com/c/aom/+/46901
[03:06:59 CET] <atomnuker> I think ubitux is the only one here who's done neon (asm)
[03:07:20 CET] <Compn> Chloe : all i know are that ffmpeg a few developers went on to get jobs at google, facebook, vimeo, nvidia, samsung 
[03:07:44 CET] <Compn> ugh screwed up that sentence
[03:08:22 CET] <Chloe> Compn: surely not with just ffmpeg experience, so it wont apply to me
[03:09:42 CET] <Compn> as long as you are a good coder, and dont have any unprofessional character flaws, you should be hireable in many companies
[03:12:44 CET] <ltrudeau> atomnuker: thanks for the info
[03:13:30 CET] <Compn> Chloe : i mean, it does not hurt to try to apply to these top companies, especially if you have 5y or more open source experience
[03:14:49 CET] <Chloe> Compn: 5y open source experience is rather... Excessive to expect at 18. Sure I've dabbled with various open source stuff for 5 years but i wouldnt consider it 'experience' per se
[03:14:58 CET] <Compn> oh i didnt know you were 18 :)
[03:18:35 CET] <Compn> applying that early would be interesting
[03:23:08 CET] <philipl> man, do I need to create a custom AV_OPT for color range too?
[08:34:05 CET] <cone-778> ffmpeg 03Tobias Rapp 07master:6325bd371734: swresample/rematrix: fix update of channel matrix if input or output layout is undefined
[08:34:05 CET] <cone-778> ffmpeg 03Tobias Rapp 07master:56f77b0f678d: fate: add tests for pan audio filter
[09:09:12 CET] <mateo`> atomnuker: i've done some neon too (armv7 and arm64)
[13:34:48 CET] <th3_v0ice> Hello all. I have one question regarding the decoder context. When we open a file with avformat_open_input followed by avformat_find_stream_info, should we create a new decoder context with avcodec_alloc_context3(input_stream->codecpar->codecid), or should we use the input_stream->codec as a decoder context?
[15:13:50 CET] <ltrudeau> mateo`: If ever you have any advice for me related to https://aomedia-review.googlesource.com/c/aom/+/47101 it would be greatly appreciated
[15:20:17 CET] <mateo`> ltrudeau: ok, i'll take a look at it tomorrow and let you know
[15:20:49 CET] <ltrudeau> awesome, thank you very much for your time :)
[15:33:12 CET] <cone-063> ffmpeg 03Aman Gupta 07master:f611fef37cca: avcodec/mediacodecdec: refactor to take advantage of new decoding api
[15:36:29 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:a5a6d2dc7516: avcodec/dirac_dwt: Fix integer overflows in COMPOSE_DAUB97*
[15:36:30 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:4a5ec6226b85: avcodec/diracdsp: Fix integer overflow in PUT_SIGNED_RECT_CLAMPED()
[15:36:31 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:4d0a4601015b: avcodec/amrwbdec: Fix division by 0 in voice_factor()
[15:36:32 CET] <cone-063> ffmpeg 03Jun Zhao 07release/3.0:e512c83e63fc: avfilter/formats: fix wrong function name in error message
[15:36:33 CET] <cone-063> ffmpeg 03Kelly Ledford 07release/3.0:95139c4480b0: libavfilter/af_dcshift.c: Fixed repeated spelling error
[15:36:34 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:b7f48cd0444b: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_qpel_bi_w_hv()
[15:36:35 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:01f2bc5ec89b: avcodec/hevc_sei: Fix integer overflows in decode_nal_sei_message()
[15:36:36 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:09d61d3b81ce: avcodec/hevc_cabac: Fix integer overflow in ff_hevc_cu_qp_delta_abs()
[15:36:37 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:a0bcc6cced1a: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD97iH0() and COMPOSE_DD137iL0()
[15:36:38 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:b3af84774b03: avcodec/hevcdsp_template.c: Fix undefined shift in FUNC(dequant)
[15:36:39 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:f08be2b3d2ad: avcodec/flacdec: avoid undefined shift
[15:36:40 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:844a9b439b27: avcodec/hevcdsp_template: Fix Invalid shifts in put_hevc_qpel_bi_w_h() and put_hevc_qpel_bi_w_w()
[15:36:41 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:6fab791daade: avcodec/flacdec: Fix overflow in multiplication in decode_subframe_fixed()
[15:36:42 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:9143ddea0f16: avcodec/exr: Check buf_size more completely
[15:36:43 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:0c753a46efe2: avcodec/dnxhddec: Check dc vlc
[15:36:44 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:06325d77bf12: avcodec/h264_slice: Do not attempt to render into frames already output
[15:36:45 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:3cad8e730e06: avcodec/jpeg2000dsp: Fix integer overflows in ict_int()
[15:36:46 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:c17cc8ee4ffb: avcodec/opus_parser: Check payload_len in parse_opus_ts_header()
[15:36:47 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:b4d9605c6718: avcodec/diracdec: Fix integer overflow with quant
[15:36:48 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:6164ca476570: avcodec/dirac_dwt: Fix overflows in COMPOSE_HAARiH0/COMPOSE_HAARiL0
[15:36:49 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:abb7498c3f00: avcodec/h264addpx_template: Fixes integer overflows
[15:36:50 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:c7e98ee6e08a: avcodec/arm/sbrdsp_neon: Use a free register instead of putting 2 things in one
[15:36:51 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:222ac346127e: avcodec/utils: Avoid hardcoding duplicated types in sizeof()
[15:36:52 CET] <cone-063> ffmpeg 03Carl Eugen Hoyos 07release/3.0:e858326086c6: configure: bump year
[15:36:53 CET] <cone-063> ffmpeg 03Nikolas Bowe 07release/3.0:9d0b3fa58c4b: avformat/matroskadec: Fix float-cast-overflow undefined behavior in matroska_parse_tracks()
[15:36:54 CET] <cone-063> ffmpeg 03Nikolas Bowe 07release/3.0:23af1858fe2e: avformat/lrcdec: Fix memory leak in lrc_read_header()
[15:36:55 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:7d5ca2169811: avcodec/ac3dec_fixed: Fix integer overflow in scale_coefs()
[15:36:56 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:e5296dfffaad: avcodec/ulti: Check number of blocks at init
[15:36:57 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:dfb84488428b: avcodec/snowdec: Fix integer overflow before htaps check
[15:36:58 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:a8ce9d518b29: avcodec/truemotion2: Fix integer overflow in TM2_RECALC_BLOCK()
[15:36:59 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:f7abc14d0d94: avcodec/hevc_cabac: Move prefix check in coeff_abs_level_remaining_decode() down
[15:37:00 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:181c3cbacfae: avcodec/dxtory: Fix bits left checks
[15:37:01 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:269aecafabf8: avcodec/mjpegdec: Fix integer overflow in DC dequantization
[15:37:02 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:cedd9ea93ea2: avcodec/hevc_cabac: Check prefix so as to avoid invalid shifts in coeff_abs_level_remaining_decode()
[15:37:03 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:5d06804b3136: avfilter/vf_transpose: Fix used plane count.
[15:37:04 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:78b1d57a4bc4: avcodec/mpeg4videodec: Check mb_num also against 0
[15:37:05 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:6a01b65034a1: avcodec/get_bits: Document the return code of get_vlc2()
[15:37:06 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:60039c2d125f: avcodec/mpeg4videodec: Avoid possibly aliasing violating casts
[15:37:07 CET] <cone-063> ffmpeg 03Aman Gupta 07release/3.0:d66455702304: avcodec/hevc_ps: extract one SPS fields required for hvcC construction
[15:37:08 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:adb0a29111b3: avcodec/hevc_ps: Check log2_sao_offset_scale_*
[15:37:09 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:c1a133b610de: avcodec/indeo5: Do not leave frame_type set to an invalid value
[15:37:10 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:35f47ac0d54b: avcodec/dirac_dwt: Fix several integer overflows
[15:37:11 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:6baa0e811b76: avcodec/aacsbr_fixed: Fix overflows in rounding in sbr_hf_assemble()
[15:37:12 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:8886e1228d1c: avcodec/wavpack: Fix integer overflow in FFABS
[15:37:13 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:a26ac3cc6921: avcodec/huffyuvdec: Check input buffer size
[15:37:14 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:c6b5e80635ee: avcodec/vp3: Check eob_run
[15:37:15 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:ce46e45f4cb9: avcodec/mpeg4videodec: Ignore multiple VOL headers
[15:37:16 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:664e3d217aad: avcodec/vp3: Error out on invalid num_coeffs in unpack_vlcs()
[15:37:17 CET] <cone-063> ffmpeg 03Xiaohan Wang 07release/3.0:d4f911953256: avcodec/h264_cavlc: Set valid qscale value in ff_h264_decode_mb_cavlc()
[15:37:18 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:340c315c671e: avcodec/h264_cabac: Tighten allowed coeff_abs range
[15:37:19 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:e38e2d6533d7: avutil/common: Fix integer overflow in av_clip_uint8_c() and av_clip_uint16_c()
[15:37:20 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:675e243949bc: avcodec/exr: Check remaining bits in last get code loop
[15:37:21 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:010dd0d26e5a: avcodec/vp8: Check for bitstream end before vp7_fade_frame()
[15:37:22 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:6492799fcefb: avcodec/dirac_dwt_template: Fix Integer overflow in horizontal_compose_dd137i()
[15:37:23 CET] <cone-063> ffmpeg 03Michael Niedermayer 07release/3.0:9f14908a96ca: Update for 3.0.11
[16:06:20 CET] <gagandeep_> kierank: for the qualification tasks, are we allowed to discuss with you and others in the community
[16:06:28 CET] <kierank> yes
[16:06:31 CET] <kierank> most definitely
[16:07:43 CET] <gagandeep_> thanks
[17:33:27 CET] <thardin> does the png encoder not support SAR? pHYs chunk
[17:34:30 CET] <thardin> seems it does but not automagically?
[17:37:04 CET] <jamrial> it should
[17:37:45 CET] <thardin> a friend of mine is having trouble thumbnailing h264 in mkv. input files has sar set, so I'm a bit stumped
[17:41:30 CET] <nevcairiel> if you're scaling anyway, maybe should just scale the SAR away
[17:41:40 CET] <nevcairiel> and make square pixels
[17:43:01 CET] <thardin> myes I'm suggesting that
[17:46:10 CET] <thardin> I'm noticing a lack of "make square pixels" example in the documentation
[17:46:59 CET] <kepstin> I wouldn't be surprised if a log of png decoders are ignoring the sar and just assume square pixels, even if it is set correctly in the file.
[17:49:31 CET] <thardin> yes I just asked him to check using ffplay
[17:49:53 CET] <thardin> web browsers are pretty garbage when it comes to this
[18:23:14 CET] <thardin> it turns out he was just using crappy viewers >_<
[18:24:20 CET] <thardin> magic scale incantation for posterity: -vf 'scale=trunc(in_h*dar):in_h,setsar=1/1'
[18:24:51 CET] <jamrial> dump it on the wiki pls :p
[18:26:09 CET] <thardin> or documentation
[18:32:06 CET] <jamrial> that's also good
[18:35:55 CET] <thardin> holy heck, how can doc/ffmpeg-filters.html  be 855k?
[18:36:31 CET] <jamrial> blame durandal_1707 for writing so many filters :p
[18:36:41 CET] <durandal_1707> too much free time
[18:37:22 CET] <thardin> firefox chokes on it
[18:37:23 CET] <jamrial> filters.texi is ~540k. converting to html adds some bloat
[18:37:38 CET] <durandal_1707> lol
[18:38:04 CET] <jamrial> it doesn't for me
[18:45:25 CET] <thardin> patch sent
[18:48:56 CET] <tmm1> is Marton Balint here?
[18:50:07 CET] <jamrial> i don't think so
[18:54:56 CET] <gagandeep> kierank: which header files i should go through in ffmpeg so as to get working knowledge for the library functions
[18:55:08 CET] <kierank> gagandeep: for cineform?
[18:55:11 CET] <kierank> libavcodec/cfhd.c
[18:55:12 CET] <gagandeep> yes
[18:57:02 CET] <gagandeep> how much of the #include ones i need to go through
[18:58:24 CET] <gagandeep> kierank: i am asking the basic libraries that i need to acquiant myself with like avcodec.h etc
[18:58:45 CET] <kierank> in theory you don't need to be aware of those
[19:00:09 CET] <gagandeep> but i will need to go through all the keywords like frames that are included from external files
[19:01:57 CET] <kierank> gagandeep: only avcodec.h
[19:02:04 CET] <kierank> and maybe libavutil/frame.h
[19:11:36 CET] <omerjerk> Is Martin Vignali here?
[19:17:04 CET] <durandal_1707> no,  afaik
[19:48:59 CET] <philipl> Well, that was entertaining. 
[19:54:46 CET] <JEEB> philipl: gj
[19:54:54 CET] <atomnuker> philipl: do the patches overlap with durandal_1707's patches?
[19:55:27 CET] <wm4> should you really add a new option type?
[19:55:27 CET] <atomnuker> (also do they fix all the issues? can we finally deprecate yuvj for real?)
[19:55:39 CET] <philipl> atomnuker: I never looked closely at his.
[19:55:52 CET] <JEEB> -34
[19:56:15 CET] <philipl> I'm not claiming it fixes all issues, just this particular issue. I don't know what the full list is.
[19:56:18 CET] <philipl> :-)
[19:57:31 CET] <philipl> wm4: A new option type seems silly but color range is already handled in a silly way in multiple places right now - each filter that uses it defines its own option and parsing strategy
[19:57:41 CET] <durandal_1707> this is just subset with opt type of my work
[19:57:41 CET] <philipl> I didn't try to consolidate them, but there's an obvious improvement if we do.
[19:58:23 CET] <philipl> durandal_1707: yeah. Maybe that's what I get for not reading those patches. Maybe it helps make it more consumable because it's a subset.
[19:58:27 CET] <durandal_1707> hope this one can be applied asap
[19:59:07 CET] <wm4> unless your program becomes ffmpeg.c, you tend to need to explicitly switch() on the option type for certain things, so I think new option types should generally be avoided as far as possible
[20:00:04 CET] <jamrial> yes please, death to yuvj
[20:00:49 CET] <durandal_1707> yuvj lives again!
[20:01:45 CET] <wm4> so libavfilter was a big part in yuvj, but wasn't there also a problem with the encoding API?
[20:02:49 CET] <jamrial> also sws. it looks at the pixfmt before making some choices, in functions with no apparent access to a color_range value
[20:07:29 CET] <wm4> well that's just a sws bug then
[20:07:41 CET] <wm4> but would explain some weird behavior I've seen with libswscale
[20:08:16 CET] <wm4> (not like I'd waste my time with it - mpv for one basically doesn't use libswscale at all anymore in an ideal setup)
[20:09:53 CET] <nevcairiel> i'm still looking for a decently fast rgb -> rgb scaler, which also has ARM optimizations, its really hard to find something that also has ARM SIMD for such a task you would think many people need
[20:51:55 CET] <philipl> durandal_1707: I'm looking over your change from december. Ignoring the option stuff, the core filter stuff is the same except I missed the ff_get_video_buffer part.
[20:52:22 CET] <philipl> For 'ffmpeg', you obviously added the InputFilter and OutputFilter stuff. I don't see you setting the color_range on the encoder context, however.
[20:53:10 CET] <philipl> (or reading it off the decoder actually)
[20:56:10 CET] <philipl> Ok, I was looking at the wrong patchset
[21:00:44 CET] <philipl> but still don't see you reading it off the decoder or setting the buffersrc parameter
[21:49:42 CET] <jkqxz> philipl:  <http://ixia.jkqxz.net/~mrt/ffmpeg/mjpeg/>
[21:50:05 CET] <jkqxz> I've sorted out the YUVJ stuff in the VAAPI code, so it doesn't need that hack.
[21:50:32 CET] <jkqxz> I'm having fun with testing it, though.
[21:51:28 CET] <jkqxz> Intel still decodes some YUV 4:4:4 images to garbage and I'm not yet sure why (I suspect something in the driver is making incorrect assumptions about the components).
[21:52:39 CET] <jkqxz> AMD can decode 4:2:0 and 4:2:2, but you can't easily get at the results.  The crazy separated-field stuff makes everything except the encoder refuse to deal with the output surfaces (and that includes downloading them back to CPU memory).
[21:52:57 CET] <jkqxz> The encoder does work on the 4:2:0 ones, but it segfaults when given 4:2:2.
[21:53:46 CET] <jkqxz> It all feels very "we made it work once and noone has touched it since".
[21:56:26 CET] <Fenrirthviti> From AMD? Shocking.
[22:04:20 CET] <philipl> an
[22:09:03 CET] <philipl> jkqxz: will look properly in a bit. thanks for pulling the nvdec change in.
[22:10:59 CET] <jamrial> nevcairiel: will you push you dlltools patch? or want me to merge the libav one?
[22:17:15 CET] <nevcairiel> the libav one is incomplete
[22:17:16 CET] <atomnuker> jkqxz: separated fields?
[22:17:29 CET] <nevcairiel> so i'll push mine soon
[22:18:15 CET] <jkqxz> atomnuker:  Decode progressive input to separate top and bottom fields.  Because reasons.
[22:18:33 CET] <atomnuker> hah, I thought only vdpau did that
[22:19:43 CET] <jamrial> nevcairiel: ah right, forgot we had a lib.exe path as well
[22:27:38 CET] <cone-063> ffmpeg 03Hendrik Leppkes 07master:6d8bef8c05ea: build: restore using dlltool/lib.exe for creating Win32 .lib files
[22:36:57 CET] <cone-063> ffmpeg 03Martin Storsjö 07master:97eee953e639: Revert "configure: Stop using dlltool to create an import library"
[22:36:58 CET] <cone-063> ffmpeg 03Martin Storsjö 07master:cc1c94dacd06: configure: Pass the right machine types to dlltool for arm and arm64 mingw
[22:36:59 CET] <cone-063> ffmpeg 03James Almer 07master:6dea6c4b9718: Merge commit '97eee953e639bd4d17a9f9398293775277d00505'
[22:37:00 CET] <cone-063> ffmpeg 03James Almer 07master:04a8d5c2d757: Merge commit 'cc1c94dacd0642ac1a6cad45deb65071f127d91a'
[22:37:33 CET] <nevcairiel> i wonder if those are the right values for lib.exe as well, but not like i can test
[22:38:09 CET] <nevcairiel> arm and arm64 seem correct, so yay
[22:42:12 CET] <rcombs> oh, it imported from the wrong lib
[22:42:16 CET] <rcombs> huh
[22:42:19 CET] <rcombs> how the fuck
[22:42:30 CET] <rcombs> windows is bad, news at 11
[22:42:36 CET] <nevcairiel> ?
[22:42:59 CET] <rcombs> I didn't get why this was happening at runtime before reading those commit messages
[22:43:09 CET] <nevcairiel> because gcc is dumb, apparently
[22:43:19 CET] <nevcairiel> it produces somehow conflicting link sections
[22:43:35 CET] <wbs> and the biggest question is why it doesn't do whatever dlltool does, which seems to be fine
[22:43:41 CET] <rcombs> and I talked to a friend who understands .lib files better than I do the other day and now I'm really mad that they still exist
[22:44:33 CET] <wbs> nevcairiel: about lib.exe; since dlltool is fine otherwise (for msvc <= 2010 there was an issue with /OPT:REF with dlltool produced implibs, but that should be gone by now) I don't think there's a strict need for keeping that - other than potentially risking to break some other subtle case
[22:44:49 CET] <wbs> like when I naively thought it would be just as fine to use the ld produced implib instead of the dlltool one
[22:44:50 CET] <rcombs> apparently .lib files corresponding to .dlls are just the PLT, except emitted as a separate step in a static library, rather than just being emitted by the linker when linking against a .dll
[22:45:27 CET] <wbs> (when implementing the same things for lld and llvm-dlltool, the produced import libraries from both cases are identical)
[22:45:32 CET] <nevcairiel> wbs: who knows, its probably fine, but its not like its a lot of annoyance to keep it
[22:45:39 CET] <rcombs> which is why gcc/ld is fine just linking against a .dll directly: it emits that code itself
[22:45:51 CET] <rcombs> MSVC is just stubborn and doesn't
[22:46:05 CET] <rcombs> so you've gotta do its job for it and make a PLT
[22:46:19 CET] <wbs> rcombs: yes, but then on the other hand, the gcc produced import libraries are much more complex than the msvc ones
[22:46:52 CET] <rcombs> I'm saying we shouldn't need separate import-library files at all
[22:46:59 CET] <wbs> I know
[22:47:07 CET] <nevcairiel> the interesting thing is that you can have symbols visible in the DLL but invisible in the .lib file, which is used for the loading/registration mechanics of COM objects, for example, since all the COM DLLs expose a few functions of the exact same name, which I reckon might cause troubles
[22:47:31 CET] <wbs> yes, and you can have symbol aliases in the import library
[22:47:42 CET] <wbs> like have code calling read() but end up loading _read() from the dll
[22:47:46 CET] <nevcairiel> import libraries can even refer to multiple DLLs
[22:47:52 CET] <nevcairiel> its all sorts of wicked magic
[22:47:58 CET] <wbs> that part actually is no magic at all
[22:48:08 CET] <wbs> it's just a bunch of object files, just like any static library
[22:48:29 CET] <wbs> so you can have whatever helper functions there that end up statically linked into your binary, and then importing the rest from the dll
[22:48:33 CET] <jkqxz> Aha, right.  Intel's JPEG decoder only accepts 4:4:4 images if for all components you have H_i == V_i == 1.
[22:49:51 CET] <jamrial> jkqxz: no documentation at all about this? i'm amazed you have to experiment this much
[22:49:51 CET] <jkqxz> But libavcodecs JPEG encoder creates them with H_i == 1 and V_i == 2, so it just returns complete garbage (while indicating success).
[22:50:08 CET] <jkqxz> Files made by libjpeg do work.
[22:50:11 CET] <rcombs> macOS actually has something sort of similar lately at a very high level
[22:50:30 CET] <rcombs> not in terms of "PLT in a static lib"
[22:50:34 CET] <atomnuker> maybe they know subsampling is pointless if you have a sufficiently advanced codec and have prepared for it
[22:50:42 CET] <rcombs> but a small file that you can link against instead of the full dylib: https://gist.github.com/rcombs/0eea073c7c43e8386bdf3b4f320c60b0
[22:51:08 CET] <jkqxz> jamrial:  No documentation at all for anything like this.  The whole thing is completely unusable without the source code to read.
[22:51:39 CET] <jamrial> that seems to be the foss way
[22:51:54 CET] <jkqxz> atomnuker:  It's not subsampling.  It's just defining the order of the blocks in the file.
[22:52:18 CET] <philipl> jkqxz: btw, the mjpeg profile change requires a fate update. There's a test that expects the profile to be unset right now.
[22:52:18 CET] <nevcairiel> .lib files are so generic that you can create them from nothing but text input anyway, if you don't use any of the more special features, so in theory you could link against a .def file or the dll itself and the linker could create the import statements, if it wanted to - but the lib format is more versatile t hen that, so i guess they just enforce using it
[22:52:46 CET] <rcombs> nevcairiel: yeah
[22:52:49 CET] <nevcairiel> its not like its hard to generate a lib f ile from any given dll
[22:53:41 CET] <nevcairiel> just took us by surprise that gcc/ld sucks at creating those, when dlltool works
[22:53:49 CET] <nevcairiel> you would think those people would talk to each other
[22:54:10 CET] <wbs> nevcairiel: especially since ld and dlltool come from the exact same binutils source tree
[22:54:22 CET] <wbs> it's all just frontends to the same libbfd
[22:55:20 CET] <wbs> dunno if it is msvc link.exe that has got some handwired extra logic to make it work, that only was adapted to the dlltool variant - I tried to have a look and it's mostly a very minor difference in how they name the internal object files
[22:57:27 CET] <jkqxz> philipl:  Right, so it does.  Thanks, I'll fix that.
[22:58:14 CET] <philipl> jkqxz: otherwise, changes looks good to me.
[22:58:42 CET] <jkqxz> The raw_image_buffer at the SOI marker does the right thing on nvdec?
[23:12:31 CET] <philipl> jkqxz: yes, it works. I'm actually surprised.
[23:52:32 CET] <kepstin> oh, huh, the old fps filter applies the start_time option in the *input* timebase rather than *output* timebase. This is gonna make my life unnecessarily complicated.
[00:00:00 CET] --- Tue Feb 20 2018