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

[burek]

[01:57:01 CEST] <BBB> jamrial: hey, have you decided to come to VDD?
[02:03:04 CEST] <jamrial> BBB: i'll probably pass this year, sorry
[02:06:21 CEST] <atomnuker> you pass every year :(
[02:10:21 CEST] <BBB> awh :( please please please?
[02:10:29 CEST] <BBB> we really need more normal people to show up
[02:10:44 CEST] <BBB> at some point people will think we (ffmpeg) are just one big freakfest
[02:11:10 CEST] <BBB> youre probably the most normal person in our community, please please please come
[11:17:46 CEST] <cone-481> ffmpeg 03Jun Zhao 07master:d428ef0ea584: lavf/network: add a ff_log_net_error function.
[11:17:46 CEST] <cone-481> ffmpeg 03Jun Zhao 07master:0a8ff1d8bb07: lavf/network: check return value of setsockopt.
[11:17:46 CEST] <cone-481> ffmpeg 03Jun Zhao 07master:0ed0af595b69: lavf/tcp: check return value of setsockopt.
[11:17:46 CEST] <cone-481> ffmpeg 03Jun Zhao 07master:49efd41c4717: lavf/udp: use ff_log_net_error to replace log_net_error
[12:37:31 CEST] <akravchenko188> Hi, guys. could you please help me. I have sent patch month ago, I have put couple of reminders here and in forum, no answer
[12:38:51 CEST] <JEEB> feel free to find your patch on patchwork (if you sent it to the mailing list) and both link it here as well as ping the patch on the mailing list https://patchwork.ffmpeg.org/project/ffmpeg/list/
[12:43:38 CEST] <akravchenko188> Thanks, I have already sent reminder in maillist
[12:45:09 CEST] <akravchenko188> reminder: could you please review the patch 1: https://patchwork.ffmpeg.org/patch/9663/
[12:46:07 CEST] <akravchenko188> reminder: could you please review the patch 2: https://patchwork.ffmpeg.org/patch/9662/
[12:46:35 CEST] <akravchenko188> thanks
[16:40:27 CEST] <cone-766> ffmpeg 03PaweB Wegner 07master:85c00643b763: avformat/tls_schannel: Fix use of uninitialized variable
[18:30:31 CEST] <durandal_1707> j-b: have you looked at last patch for IMM4, is log message ok for you?
[19:10:02 CEST] <kierank> durandal_1707: going to RE that canon codec?
[19:12:26 CEST] <durandal_1707> kierank: canon?
[19:12:35 CEST] <kierank> cr3 or wahtever it called
[19:12:44 CEST] <kierank> https://github.com/lclevy/canon_cr3
[19:13:15 CEST] <durandal_1707> ah, only if guy pay me, i'm pro now
[19:18:29 CEST] <gagandeepsingh> michaelni: what do i need to perform fuzzing?
[19:21:10 CEST] <kierank> I think you should commit (good) changes and let google fuzz it
[19:21:32 CEST] <kierank> michaelni: just give gagandeepsingh access to the cfhd crashes
[19:23:31 CEST] <Compn> gagandeepsingh : zzuf program, sample file and ffmpeg
[19:24:06 CEST] <durandal_1707> american fuzzy loop for advanced fuzzers
[19:25:18 CEST] <michaelni> gagandeepsingh, what compn and durandal_1707 said. thx btw
[19:26:46 CEST] <jamrial> wow, there really exists a fuzzer called "american fuzzy lop"
[19:27:22 CEST] <JEEB> yup
[19:27:25 CEST] <JEEB> AFL
[19:27:47 CEST] <gagandeepsingh> thanks
[19:28:16 CEST] <durandal_1707> but that would be very hard for big files to get fuzzed with AFL
[19:28:53 CEST] <durandal_1707> so just leave it to google machines?
[19:29:29 CEST] <durandal_1707> unless you can already spot possible security relevant bugs/problems
[19:31:30 CEST] <durandal_1707> gagandeepsingh: does github cineform have code to handle IP encoding?
[19:32:11 CEST] <gagandeepsingh> durandal_1707: i haven't looked at encoder.c currently
[19:32:24 CEST] <gagandeepsingh> it has all the functions to perform the transforms though
[19:34:25 CEST] <kierank> michaelni: why won't you just let him commit and make google do the fuzzing
[19:34:35 CEST] <kierank> and then send him the crashes and he fix them
[19:37:31 CEST] <durandal_1707> anybody with commit bit can already push cfhd patches
[19:39:02 CEST] <kierank> one of them needs some work
[19:48:42 CEST] <Compn> durandal_1707 : have to mark cfhd as experimental :P
[19:49:29 CEST] <durandal_1707> Compn: i could tell you something nasty
[19:51:00 CEST] <atomnuker> we don't mark decoders as experimental
[19:54:25 CEST] <kierank> gagandeepsingh: if you make good fix for #if0 I will push 1/2
[19:55:31 CEST] <jamrial> speaking of cfhd, the current code has data races
[19:55:50 CEST] <durandal_1707> where?
[19:55:57 CEST] <jamrial> http://fate.ffmpeg.org/report.cgi?time=20180818110226&slot=x86_64-archlinux-gcc-tsan
[19:56:26 CEST] <jamrial> alloc_buffers() called from cfhd_decode()
[19:58:37 CEST] <jamrial> ff_set_dimensions() called from that function, to be precise
[19:58:56 CEST] <kierank> gagandeepsingh: can you look at that ^
[20:00:46 CEST] <kierank> gagandeepsingh: 
[20:00:46 CEST] <kierank> 6:55:30 PM <"jamrial> speaking of cfhd, the current code has data races
[20:00:46 CEST] <kierank> 6:55:49 PM <"durandal_1707> where?
[20:00:46 CEST] <kierank> 6:55:57 PM <"jamrial> http://fate.ffmpeg.org/report.cgi?time=20180818110226&slot=x86_64-archlinux-gcc-tsan
[20:00:46 CEST] <kierank> 6:56:25 PM <"jamrial> alloc_buffers() called from cfhd_decode()
[20:00:46 CEST] <kierank> 6:58:37 PM <"jamrial> ff_set_dimensions() called from that function, to be precise
[20:00:47 CEST] <kierank> 6:58:55 PM <"kierank> gagandeepsingh: can you look at that ^
[20:01:25 CEST] <gagandeepsingh> kierank: alright
[20:03:18 CEST] <gagandeepsingh> kierank: data races, are they for the existing code or the code in my patch?
[20:03:25 CEST] <kierank> existing code
[20:03:35 CEST] <gagandeepsingh> ok, will help pinpointing stuff
[20:07:00 CEST] <gagandeepsingh> kierank: just wondering, that check in place, if i had to work around that check, wouldn't that defeat the purpose?
[20:07:15 CEST] <kierank> gagandeepsingh: ?
[20:07:16 CEST] <kierank> check in place
[20:07:21 CEST] <gagandeepsingh> #if 0
[20:07:37 CEST] <kierank> you need to submit working code without that
[20:08:04 CEST] <gagandeepsingh> i had to disable it because it was checking image width and height, but mountain sample does not bring that info before the check executes
[20:08:27 CEST] <kierank> strange, where does it do the check
[20:08:34 CEST] <kierank> where does it signal width and height
[20:09:09 CEST] <kierank> how can it code width and height *after* end of header tag
[20:09:20 CEST] <gagandeepsingh> since s->coded_width is set form the image width tag, it was zero, and then for allocating buffers one needs non zero s->coded_width initially
[20:09:36 CEST] <kierank> it must use another tag then
[20:09:40 CEST] <gagandeepsingh> so i had to give s->coded_width from s->lowpass_width dat
[20:09:56 CEST] <gagandeepsingh> the image tag is in next packet, the empty packet
[20:09:57 CEST] <kierank> it's weird though, official decoder must have same problem
[20:10:24 CEST] <gagandeepsingh> all other samples correctly bring it though in the first packet
[20:10:57 CEST] <kierank> you could make a check for if(coded_width == 0) allocate buffers elswhere
[20:11:03 CEST] <kierank> a bit of a hard problem
[20:12:10 CEST] <kierank> do we have a "fate with big samples"?
[20:12:49 CEST] <kierank> I guess mountain sample can be cut
[20:13:07 CEST] <gagandeepsingh> yeah, cut without re-encode
[20:13:21 CEST] <kierank> mountain sample should be in fate
[20:13:26 CEST] <kierank> at least first few frames
[20:14:09 CEST] <gagandeepsingh> again i also have bit exact samples, will cut and ask how to add in fate
[20:14:30 CEST] <kierank> michaelni: can you add gagandeepsingh samples to fate?
[20:14:56 CEST] <durandal_1707> kierank: first need to be uploaded somewhere
[20:15:12 CEST] <kierank> gagandeepsingh: send michaelni samples with wetransfer 
[20:15:14 CEST] <kierank> or 0x0.st
[20:15:33 CEST] <gagandeepsingh> after cut right?
[20:15:43 CEST] <kierank> small ones are ok
[20:15:48 CEST] <kierank> but mountain sample needs cut
[20:15:50 CEST] <kierank> it's big if i remember
[20:15:52 CEST] <gagandeepsingh> i have no small ones
[20:16:09 CEST] <michaelni> kierank, yes, i can but probably later
[20:16:09 CEST] <gagandeepsingh> mine are above full hds for 20seconds
[20:16:20 CEST] <kierank> https://github.com/gopro/cineform-sdk/tree/master/Example/videos
[20:16:25 CEST] <kierank> what about those as well?
[20:17:22 CEST] <kierank> wow people use virtualdub
[20:17:27 CEST] <kierank> I used that like 15 years ago
[20:18:19 CEST] <gagandeepsingh> they both are intra only
[20:18:27 CEST] <kierank> ok
[20:18:30 CEST] <kierank> but they are quite small
[20:18:33 CEST] <kierank> could be useful still
[20:18:42 CEST] <gagandeepsingh> i got no problem
[20:21:53 CEST] <kierank> I had a big repository of samples but I can't find it any more
[20:22:35 CEST] <kierank> actually I found them
[20:22:38 CEST] <kierank> gagandeepsingh: let me email them
[20:24:29 CEST] <kierank> gagandeepsingh: I pmmed you samples
[20:27:18 CEST] <gagandeepsingh> kierank: where?
[20:27:24 CEST] <kierank> gagandeepsingh: PM
[20:27:46 CEST] <gagandeepsingh> got them
[20:28:02 CEST] <kierank> some quite small ones in there
[20:28:05 CEST] <kierank> lots of features tested
[20:43:00 CEST] <kierank> durandal_1707: do you have 14496-4 
[20:44:01 CEST] <durandal_1707> kierank: what is that?
[20:44:10 CEST] <kierank> spec
[20:44:22 CEST] <durandal_1707> about what?
[20:44:46 CEST] <kierank> mpeg-4 conformance
[20:44:51 CEST] <kierank> it explains what features the bitstream samples use
[20:45:12 CEST] <durandal_1707> nope, mail me
[20:46:13 CEST] <kierank> actually I got it
[20:49:34 CEST] <kierank> ffs
[20:51:03 CEST] <kierank> not got what i need
[20:55:21 CEST] <durandal_1707> kierank: why you need it?
[20:55:33 CEST] <kierank> I want to know what features are in each file
[20:55:34 CEST] <kierank> http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-4_2004_Conformance_Testing/video_conformance/studio/
[20:59:46 CEST] <kierank> samples are interesting, they use DPCM mode which I will have to hack into ffmpeg mpegvideo masterpiece
[21:00:10 CEST] <atomnuker> there's a 20 page preview here https://www.sis.se/api/document/preview/617424/
[21:00:56 CEST] <kierank> that's the 2000 edition anyway
[21:00:59 CEST] <kierank> so it's old
[21:02:10 CEST] <JEEB> yeh
[21:05:19 CEST] <atomnuker> kierank: you did check the dropbox first, right?
[21:05:46 CEST] <kierank> sure, since it's my dropbox
[21:06:19 CEST] <atomnuker> kierank: found it
[21:06:21 CEST] <atomnuker> https://manualzz.com/doc/29217911/iso-iec-14496-4
[21:06:27 CEST] <kierank> doesn't have what i need
[21:06:30 CEST] <kierank> already have that
[21:06:33 CEST] <atomnuker> :/
[21:06:56 CEST] <durandal_1707> i need non-power of 2 mdct/fft, filters and decoders depends on you!
[21:06:57 CEST] <atomnuker> funnily its listed under "baby & children toys & accessories toy parts  ISO/IEC 14496-4"
[21:11:42 CEST] <kierank> finally found samples with dpcm coding so I can implement this tonight
[21:13:33 CEST] <kierank> dpcm_scan_order: This is a flag that indicates the scanning order of blocks for DPCM coding. If set to value 0
[21:13:33 CEST] <kierank> the block is scanned from top line to bottom line, and from left to right. If set to value 1 the block is scanned from
[21:13:33 CEST] <kierank> bottom line to top line, and from right to left.
[21:13:34 CEST] <kierank> insane
[21:15:29 CEST] <JEEB> wow, so they even reversed the order horizontally
[21:16:00 CEST] <durandal_1707> who is running this persistent and pointless, resource wasting spamming?
[21:16:28 CEST] <kierank> JEEB: yeah it's an insane mode to check
[21:20:15 CEST] <atomnuker> why did they implement something like that? the hardware people wouldn't have been happy
[21:21:53 CEST] <kierank> atomnuker: it's delta coding so theoretically top left part of block could have nothing
[21:21:56 CEST] <kierank> and bottom right could
[21:22:05 CEST] <kierank> (but then why the encoder would choose pcm)
[21:22:35 CEST] <kierank> I really hope none of the samples have that weird system
[21:22:47 CEST] <durandal_1707> it was someone's job
[21:28:13 CEST] <atomnuker> mpeg4 is kinda rare to see nowadays, no one distributes xvid encodings anymore and outside of that it was only viable for a short amount of time before h264
[21:28:34 CEST] <kierank> sure but in 100 years I want random fields to be decodable
[21:28:41 CEST] <kierank> long before the binary blobs needed are gone
[21:30:13 CEST] <JEEB> atomnuker: I've seen it in the weirdest places still used
[21:30:49 CEST] <durandal_1707> atomnuker: please tell me you are working on new mdct/fft
[21:31:19 CEST] <kierank> durandal_1707: 
[21:31:20 CEST] <kierank> 8:06:56 PM <"durandal_1707> i need non-power of 2 mdct/fft, filters and decoders depends on you!
[21:31:22 CEST] <atomnuker> JEEB: where? it was never (afaik) used in broadcasting apart from consumer decoders which isn't pro
[21:31:23 CEST] <kierank> what do you use that for?
[21:31:40 CEST] <atomnuker> a filter (I think) and the siren codec (I think)
[21:31:51 CEST] <durandal_1707> bm3d filter
[21:32:02 CEST] <JEEB> atomnuker: internal stuff in certain places. I double-blinked when I saw the stream contained MPEG-4 Part 2
[21:32:16 CEST] <durandal_1707> vivo siren for Compn's porn
[21:32:46 CEST] <atomnuker> that non-keyframe codec? lol, I tried to find some samples of that today and couldnt
[21:33:40 CEST] <atomnuker> (it put a single keyframe at the start and then never, to save space and appear better than realvideo, but both were h263 based afaik)
[21:33:41 CEST] <JEEB> after it was mentioned that the episodes would be a few % smaller than with Real Video?
[21:34:17 CEST] <atomnuker> yeah, we didn't have anything in the fate samples repo but there's code in lavf
[21:34:57 CEST] <durandal_1707> atomnuker: huh? thare are vivo samples...
[21:36:02 CEST] <atomnuker> find . -iname "*vivo*", nothing, maybe they used a standard-ish container
[21:36:18 CEST] <durandal_1707> extension is viv
[21:37:03 CEST] <atomnuker> there are some in samples.ffmpeg.org though
[21:37:03 CEST] <durandal_1707> in old days, internet was full of that...
[21:38:04 CEST] <atomnuker> nope, seems like we can't decode either video or audio, oh well
[21:39:03 CEST] <durandal_1707> you picked 2 version
[21:39:33 CEST] <durandal_1707> old version have supported video and audio
[21:56:49 CEST] <kierank> C question:
[21:56:52 CEST] <kierank> Can I address this int16_t (*blocks)[12][64]; 
[21:56:58 CEST] <kierank> like this block[128]
[21:57:16 CEST] <kierank> if I cast it, that's valid C, right?
[21:58:19 CEST] <kierank> actually I need it like block[3][128], is that allowed?
[22:00:06 CEST] <durandal_1707> in C its possible , but is not nice to casual reader i guess
[22:00:38 CEST] <kierank> durandal_1707: dpcm is in terms of macroblock
[22:01:03 CEST] <kierank> actually I need [3][256]
[22:01:25 CEST] <kierank> so it not big enough
[22:01:30 CEST] <kierank> I will allocate my own buffer
[22:02:29 CEST] <kierank> I will do that and let the usual complainers fix it
[22:03:11 CEST] <durandal_1707> nobody will complain if code is nice
[22:03:28 CEST] <kierank> it might affect benchmarks of mpegvideo.c cache
[22:03:30 CEST] <kierank> and stuff
[22:03:36 CEST] <atomnuker> just extend the buffer such that it sums up to what you need
[22:03:48 CEST] <atomnuker> you can cast it as a pointer and address it linearly
[22:04:23 CEST] <durandal_1707> yes, C is forgiving
[22:04:32 CEST] <kierank> how do I cast int32_t (*block32)[12][64]; to be int16_t *dpcm_block[3][256]?
[22:05:54 CEST] <atomnuker> right, I don't think that's possible, maybe using a union?
[22:07:00 CEST] <atomnuker> if you add another field to the struct I wouldn't mind
[22:07:38 CEST] <durandal_1707> i hate micro optimizations
[22:09:50 CEST] <durandal_1707> does that block have alignment need?
[22:10:13 CEST] <atomnuker> kierank: checked, you can just replace block32 with union { int32_t block32[12][64]; int16_t *dpcm_block[3][256]; };
[22:10:40 CEST] <atomnuker> code can still access ctx->block32 as normal and you can access ctx->dpcm_block as you need to
[22:11:08 CEST] <durandal_1707> isnt there policy against union?
[22:11:13 CEST] <atomnuker> gcc doesn't complain with --std=c89 so I guess anonymous unions are allowed
[22:12:08 CEST] <durandal_1707> in c pointers are just integers...
[22:13:30 CEST] <rcombs> hmmmm
[22:13:54 CEST] <atomnuker> durandal_1707: yeah, you can add stuff to them, they're totally mutable, its awesome!
[22:13:55 CEST] <rcombs> if you cast first I _think_ that's fine but lemme double-check
[22:15:07 CEST] <durandal_1707> C++ have several cast versions, i dunno what they mean
[22:17:46 CEST] <atomnuker> I don't see any anonymous unions in our codebase, but if that's the case just name it block and the variables inside as as_32 and as_dpcm or something
[22:18:57 CEST] <atomnuker> yeah, seems like anoymous unions are a c11 thing
[22:18:57 CEST] <durandal_1707> yes, iirc anonymous unions are forbiden
[22:20:04 CEST] <rcombs> kierank: block[3][128] would be UB
[22:20:22 CEST] <rcombs> because you're past the end of a sub-array
[22:21:17 CEST] <rcombs> dunno if any compiler would actually punish you for that in practice (might warn? dunno if it'd affect codegen), but it's not defined
[22:22:26 CEST] <kierank> I will implement it directly then and let the person who complains fix it
[22:54:12 CEST] <kierank> durandal_1707: ping
[22:54:46 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/S1Zg4dZV/image.png
[22:54:53 CEST] <kierank> is there a function to do this already?
[22:55:58 CEST] <kierank> ah unary
[22:56:07 CEST] <durandal_1707> is that get unary with twist?
[22:57:32 CEST] <durandal_1707> give me something harder as tables that needs conversion to our syntax
[23:28:05 CEST] <jamrial> nevcairiel: neat, new msvc version fixed the fate failures
[23:31:25 CEST] <nevcairiel> jamrial: yeah i know, they  notified me that my ticket was resolved
[00:00:00 CEST] --- Sun Aug 19 2018