burek021 at gmail.com
Fri Aug 10 03:05:03 EEST 2018
[00:44:36 CEST] <cone-873> ffmpeg 03Carl Eugen Hoyos 07master:6130068453a9: lavf/mov: Force HEVC codec_id for code-point dvh1 and an hvcC atom.
[07:08:50 CEST] <cone-851> ffmpeg 03Mina 07master:e0539f0349e9: lavfi/xbr: update filter url
[09:00:11 CEST] <ultramage> g'day, one of my dxtory captures is reporting "Not enough slice data available is not implemented" many times during processing, haven't seen this before even though I've encoded captures many times. Version N-91548-g481741ece0. Would it be of any use if I uploaded it according to the instructions?
[09:07:43 CEST] <ultramage> hm, the hardcoded instructions say to upload to ftp://upload.ffmpeg.org/incoming, but it's gone
[09:25:22 CEST] <JEEB> ultramage: yea I'm not sure what the write only thing should be atm
[09:32:06 CEST] <ultramage> long ago I cobbled together a basic php upload script, it's only 10 lines but at this day and age I wouldn't be surprised if there's an exploit in it ><
[09:32:59 CEST] <ultramage> so anonymous ftp wasn't good anymore?
[09:35:52 CEST] <ultramage> you could take the hip modern approach - have them upload to their 'google drive' and share the link
[09:37:24 CEST] <JEEB> 0x0.st etc
[09:37:58 CEST] <JEEB> and then add a asample to the trac issue tracker
[09:38:06 CEST] <JEEB> (link to)
[09:47:02 CEST] <ultramage> file's 3 gigs, would have to start slicing and hope ffmpeg recreates the file with all the problem intact... let's see...
[09:49:48 CEST] <ultramage> wonderful, it does... should I really bother making a trac ticket for this though
[10:57:27 CEST] <gagandeepsingh> kierank: did you see the file?
[12:09:40 CEST] <gagandeepsingh> kierank: i am feeling really stuck at this point would like if you could provide the input
[12:11:46 CEST] <kierank> gagandeepsingh: sorry I am busy at the moment, really sorry about this
[12:11:51 CEST] <kierank> who is backup mentor for this project again
[12:11:57 CEST] <kierank> atomnuker perhaps?
[12:14:49 CEST] <gagandeepsingh> yeah
[12:16:01 CEST] <gagandeepsingh> atomnucker how do you suggest i send you the file for reviewing the frame thread code i have written
[12:16:27 CEST] <gagandeepsingh> atomnuker
[12:45:45 CEST] <gagandeepsingh> atomnuker: i have sent you a mail with all the relevant links and you can further ask for more details
[12:57:42 CEST] <ubitux> heh, someone is testing selectivecolor extensively and reporting me a bug
[12:58:09 CEST] <ubitux> i know, nothing out of the ordinary, just made me happy
[13:17:17 CEST] <ultramage> dxtory capture - warnings when encoding with libx264 - "Not enough slice data available is not implemented" - uploaded at http://0x0.st/s4Ot.avi
[14:19:46 CEST] <JEEB> ubitux: it's nice to know that someone is using your code :)
[14:22:28 CEST] <ubitux> JEEB: yeah, especially given the time it took me to RE, code and write about it
[14:29:54 CEST] <JEEB> ubitux: yup :)
[14:30:09 CEST] Action: JEEB waits for his train to get to akiba
[15:13:13 CEST] <durandal_1707> kierank: i checked, it can't overflow as one value is signed int8 and other is 15
[15:15:20 CEST] <durandal_1707> code is here: https://github.com/richardpl/FFmpeg/blob/imm4/libavcodec/imm4.c
[16:02:25 CEST] <durandal_1707> no comments? I thought FFmpeg stands for Fast & Furious Motion Picture Experts Group
[16:03:18 CEST] <BradleyS> i like turtles
[16:08:55 CEST] <atomnuker> that's an odd way to do transforms, people usually loop per-block rather than do 6 at a time
[16:10:41 CEST] <atomnuker> why do you call bswap_buf on the packet? can't you define the bitstream reader endianess manually and have it do it for you?
[16:11:12 CEST] <durandal_1707> atomnuker: it have special little endian reader
[16:11:58 CEST] <durandal_1707> and using little endian flag for bitstream reading did not help
[16:12:29 CEST] <atomnuker> dang
[16:12:59 CEST] <atomnuker> you should use refcounting rather than copying the current frame to the prev_frame, assuming you don't have to dirty your prev_frame
[16:13:27 CEST] <durandal_1707> ok
[16:47:02 CEST] <pasouza> hi, I'm wondering what would be the best place to distribute the super resolution filter data? how is it done for other filters?
[16:53:47 CEST] <atomnuker> off a separate repo
[16:54:50 CEST] <atomnuker> currently you can get the weights for nnedi from a random github repo, but I think a separate repo like ffnvcodec would do fine
[18:53:19 CEST] <JEEB> (34
[19:07:13 CEST] <gagandeepsingh> kierank: are you free right now?
[19:57:40 CEST] <cone-777> ffmpeg 03Clément BSsch 07master:eb1860e0174d: lavfi/selectivecolor: fix neutral color filtering
[20:20:30 CEST] <durandal_1707> anybody had any new insights for imm4 decoder patch I posted
[20:21:25 CEST] <durandal_1707> while i was not here?
[20:30:22 CEST] <jamrial> durandal_1707: use av_fast_padded_malloc
[20:30:43 CEST] <jamrial> the padding is implied with it, and it zeroes it every run as well
[20:32:01 CEST] <jamrial> that is important since, at least afaics, the GetBitContext is overreading into some of those padding bytes
[21:21:35 CEST] <durandal_1707> atomnuker: could you build imm4 branch with ubsan and report any findings when decoding samples from samples.ffmpeg.org/V-codecs/IMM4 ?
[21:29:35 CEST] <atomnuker> building
[21:50:06 CEST] <atomnuker> can't build with either clang or gcc, clang seems to enable -Werror for ubsan and gcc spams gigabytes of "undefined reference" errors when linking
[21:50:13 CEST] <atomnuker> I should try my other machine
[21:50:55 CEST] <durandal_1707> atomnuker: just add -fsanitize=undefined to CFLAGS and LDFLAGS
[21:51:29 CEST] <durandal_1707> with clang, and you need then to rebuild only imm4.o and fftools
[21:52:07 CEST] <jamrial> no, use --toolchain=gcc-usan
[21:52:20 CEST] <jamrial> or clang-usan
[21:52:29 CEST] <durandal_1707> i used above and it worked fine...
[21:53:38 CEST] <jamrial> i know it does, using --toolchain adds the same flags
[22:03:33 CEST] <atomnuker> archlinux broke something probably
[22:03:49 CEST] <atomnuker> I should get rid of it, I only had it to test vulkan with nvidia binaries
[22:04:30 CEST] <jamrial> durandal_1707: ubsan doesn't complain with the two samples
[22:06:23 CEST] <durandal_1707> lol
[22:39:27 CEST] <jamrial> durandal_1707: decoding is wrong, though
[22:39:53 CEST] <durandal_1707> jamrial: yes I know
[00:00:00 CEST] --- Fri Aug 10 2018
More information about the Ffmpeg-devel-irc