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

Tue Apr 11 03:05:04 EEST 2017

[00:31:28 CEST] <lalalalala> i'm using ffmpeg to ffconcat a bunch of images and mp3s into a sort of video slide show
[00:31:50 CEST] <lalalalala> i'm running ffmpeg head freshly compiled (and i've also tried stable 3.2.4)
[00:31:58 CEST] <lalalalala> and i'm getting this error message a zillion times: Non-monotonous DTS in output stream 0:1; previous: 24220238, current: 23567718; changing to 24220239. This may result in incorrect timestamps in the output file.
[00:32:18 CEST] <lalalalala> and the audio in the output is broken
[00:32:57 CEST] <lalalalala> i also specified the audio output codec as 128k lame encoded mp3
[00:35:10 CEST] <RiCON> wrong channel, you're looking for #ffmpeg
[10:42:16 CEST] <ubitux> can anyone with a windows merge the next commit?
[10:42:31 CEST] <ubitux> (9265364bec)
[10:42:40 CEST] <ubitux> it's a bit too sensible to blind it
[10:49:08 CEST] <nevcairiel> wouldnt that break configure strings on linux that use --enable-avisynth right now
[10:57:08 CEST] <wm4> isn't our avisynth support completely different, or did Libav merge that back
[10:57:11 CEST] <nevcairiel> (I also dont see the claim that it simplifies anything, but shrug)
[10:57:13 CEST] <wm4> also, fuck avisynthj
[10:57:15 CEST] <wm4> -j
[10:57:52 CEST] <rcombs> would vapoursynth-in-lavfi make any sense
[10:58:13 CEST] <nevcairiel> we have wrappers for other external frameworks, so maybe?
[10:58:13 CEST] <rcombs> (I get the feeling that line might've given someone an aneurism)
[10:58:33 CEST] <nevcairiel> definitely better then some "demuxer"
[10:58:36 CEST] <wm4> I had a vapoursynth "demuxer" patch
[10:59:24 CEST] <wm4> nevcairiel: mpv has vapoursynth as an actual filter, although it's a bit fragile
[11:00:44 CEST] <nevcairiel> some people asked me a couple times, but i dont really do any filtering other then some  basic deinterlacing, so its not something I want to do
[11:08:58 CEST] <ubitux> nevcairiel: we could skip it, but i'd better have the opinion of someone concerned about this stuff
[11:09:49 CEST] <nevcairiel> thats not me then =p
[11:10:19 CEST] <nevcairiel> anyway our stuff is sufficiently similar that the merge was really quite easy
[11:21:59 CEST] <cone-599> ffmpeg 03Paul B Mahol 07master:7437602806db: avfilter/vf_dctdnoiz: add GBRP support
[11:31:54 CEST] <nevcairiel> silly compilers complaining about better looking code =p
[11:34:03 CEST] <ubitux> the actual word is "misleading", not misaligned
[11:34:09 CEST] <ubitux> which i think is justified in most cases
[11:34:41 CEST] <nevcairiel> i suppose
[11:37:21 CEST] <nevcairiel> interesting, since when does ffmpeg actually use the windows temp folder for temporary files. wonder if thats a change from mingw-w64 5.x
[11:37:40 CEST] <nevcairiel> now i should figure out why those temp files are not cleared like they are supposed to =p
[11:41:19 CEST] <nevcairiel> i had a million ffcacheXXXX files in my temp folder on the fate box :(
[11:58:29 CEST] <cone-599> ffmpeg 03Paul B Mahol 07master:9cd44e64be25: avfilter/vf_paletteuse: silence warning about misaligned indentation
[12:21:15 CEST] <cone-599> ffmpeg 03Paul B Mahol 07master:4dc2dd80dc78: avutil/float_dsp: add vector_dmac_scalar()
[12:21:16 CEST] <cone-599> ffmpeg 03Paul B Mahol 07master:75b854adbd4e: avfilter/af_amix: add double sample format support
[12:40:53 CEST] <ubitux> https://lists.libav.org/pipermail/libav-devel/2017-April/083283.html
[12:48:53 CEST] <nevcairiel> TL;DR someone should optimize huffyuv and then we can scrap the new one? =p
[12:54:37 CEST] <ubitux> it's slower on almost everything on arm
[12:55:01 CEST] <ubitux> huffyuv and flac in particular
[12:55:18 CEST] <nevcairiel> huffyuv is rather weird, it either gets quite a bit slower or quite a bit faster
[12:55:32 CEST] <ubitux> on x86_32 it's slower almost everywhere too
[12:56:02 CEST] <ubitux> and even on aarch64 where it's not supposed to be slow
[12:56:08 CEST] <ubitux> it actually is half of the time
[12:56:30 CEST] <ubitux> we were supposed to expect a perf boost on aarch64
[12:56:33 CEST] <nevcairiel> like i  said, if you just manually optimize the high bitrate video codecs to generally be faster, then the new reader doesnt even make stuff faster on x64 anymore
[12:56:46 CEST] <ubitux> but we get stuff like -7.4% on flac
[13:08:26 CEST] <ubitux> BBB: my last tests told me that helgrind doesn't understand atomics
[13:08:32 CEST] <ubitux> so such fate instance is pointless
[13:08:35 CEST] <BBB> lol
[13:08:43 CEST] <BBB> okiedokie
[13:08:47 CEST] <BBB> thanks for trying
[13:08:50 CEST] <ubitux> btw, i confirm that svn valgrind doesn't fix the problem
[13:09:00 CEST] <ubitux> (i fixed my fate instances to actually use it)
[13:09:10 CEST] <ubitux> wrt vp9 asm
[13:09:23 CEST] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170410094609&slot=x86_64-archlinux-gcc-valgrindundef
[13:09:39 CEST] <ubitux> you have full valgrind backtraces here if you want to bump the ticket
[13:13:37 CEST] <cone-599> ffmpeg 03Michael Niedermayer 07master:8dd0c12648d8: avcodec/mjpegenc_huffman: Assert length in ff_mjpegenc_huffman_compute_bits()
[13:13:38 CEST] <cone-599> ffmpeg 03Michael Niedermayer 07master:c94d551ea7b3: avcodec/pixlet: Reorder rlen check
[13:17:45 CEST] <BBB> ubitux: thanks, Ill do that when I return from vacation
[13:19:02 CEST] <BBB> ubitux: why does it say valgrind (c) 2003-2015?
[13:19:03 CEST] <BBB> "
[13:19:10 CEST] <BBB> ubitux: doesnt that suggest its not a new SVN checkout?
[13:19:26 CEST] <BBB> ubitux: can you give the output of valgrind version also?
[13:19:28 CEST] <BBB> (hell ask)
[13:19:36 CEST] <BBB> ubitux: or the svn revision
[13:20:07 CEST] <ubitux> Last Changed Rev: 16297
[13:20:42 CEST] <ubitux> ./vg-in-place --version
[13:20:44 CEST] <ubitux> valgrind-3.13.0.SVN
[13:20:58 CEST] <BBB> and which libvex version is that?
[13:21:09 CEST] <BBB> (I think thats a separate sub-repo inside it)
[13:21:10 CEST] <ubitux> Last Changed Rev: 3344
[13:21:14 CEST] <BBB> tnx!
[13:22:19 CEST] <BBB> updated
[13:22:35 CEST] <BBB> back to vacation :) &
[15:28:04 CEST] <cone-599> ffmpeg 03James Almer 07master:d36a3f5a78bb: avformat/movenc: auto insert vp9_superframe bsf when needed
[16:09:23 CEST] <cone-599> ffmpeg 03Clément BSsch 07master:8839cbf91188: Revert "avcodec/svq1: zero initialize entries array"
[16:50:33 CEST] <ubitux> michaelni: here it is for ffv1 https://bugs.kde.org/show_bug.cgi?id=378627
[16:50:53 CEST] <ubitux> maybe it's a bug in GCC, dunno
[16:56:29 CEST] <cone-599> ffmpeg 03Paul B Mahol 07master:0da3c568fd49: avfilter/vf_blend: add GBRAP16
[17:21:56 CEST] <cone-599> ffmpeg 03James Almer 07master:128e1fbf1335: avutil/float_dsp: add test for vector_dmac_scalar
[17:21:57 CEST] <cone-599> ffmpeg 03James Almer 07master:ed9b25a148f2: x86/float_dsp: add ff_vector_dmac_scalar_{sse2,avx,fma3}
[17:40:41 CEST] <cone-599> ffmpeg 03Paul B Mahol 07master:d6b9f2b7da8e: avfilter/vf_alphamerge: use av_image_copy_plane()
[17:40:42 CEST] <cone-599> ffmpeg 03Paul B Mahol 07master:0c4d75d92e3a: avfilter/vf_alphamerge: add GBRAP support
[18:14:20 CEST] <cone-599> ffmpeg 03Paul B Mahol 07master:27ebdcf079ed: avfilter: add GRAY10 and GRAY12 to some filters
[20:23:18 CEST] <ubitux> nevcairiel: didn't you plan to merge the av*synth commit?
[20:23:30 CEST] <ubitux> o thought you said the merge was straightforward
[20:23:38 CEST] <ubitux> s/^o/i/
[20:24:14 CEST] <jamrial> does it make sense? it adds a new configure option for the exact same thing
[20:24:44 CEST] <ubitux> i have no opinion on it
[20:25:35 CEST] <jamrial> one for the linux port and one for the original, when that's already checked during compilation
[20:28:56 CEST] <nevcairiel> And it breaks current Linux configure commands
[20:29:06 CEST] <nevcairiel> I could do it, but doesn't seem that worthwhile
[20:34:57 CEST] <Bitterblue> How come there is no enum for the possible values of repeat_pict?
[20:35:38 CEST] <JEEB> nobody thought of it
[20:51:04 CEST] <durandal_1707> whats cooking?
[21:03:04 CEST] <llogan> did ip address for source.ffmpeg.org recently change? getting the typical "rsa host key" dns spoof message
[21:04:00 CEST] <j-b> llogan: https://mailman.videolan.org/pipermail/vlc-devel/2017-April/112787.html ?
[21:04:02 CEST] <JEEB> yea, thresh switched the server
[21:04:14 CEST] <JEEB> as j-b noted :)
[21:05:08 CEST] <llogan> thanks
[21:06:33 CEST] <j-b> llogan: the git was a bit too slow sometimes, and had a few DDOS attacks.
[21:06:37 CEST] <j-b> llogan: this one should be faster.
[21:07:50 CEST] <llogan> j-b: who would want to ddos videolan and why?
[21:07:57 CEST] <j-b> llogan: lol.
[21:08:03 CEST] <j-b> llogan: are you serious?
[21:08:17 CEST] <j-b> llogan: https://www.youtube.com/watch?v=hNjdBSoIa8k
[21:08:44 CEST] <j-b> llogan: we receive attacks every week or so. (DDOS, but malware on FTP and other related stuff)
[21:09:15 CEST] <llogan> people don't have better things to do with their lives
[21:09:46 CEST] <nevcairiel> that generally applies to every ddos
[21:10:03 CEST] <j-b> llogan: sorry. no idea.
[21:10:26 CEST] <nevcairiel> also, i would totally do it just to make such a video
[21:10:28 CEST] <nevcairiel> thatl ooks  pretty
[21:10:54 CEST] <j-b> Well, it was also interesting to block such attack
[21:11:07 CEST] <j-b> and that, in a few days, they changed techniques at least 3 times
[21:11:08 CEST] <ubitux> j-b: is this targetting the server of the official binary to increase the chance to get ppl to download from another server (backdoored .exe)?
[21:11:21 CEST] <j-b> ubitux: that was my guess, yes.
[21:11:49 CEST] <j-b> ubitux: but at the same time, we've received couterfeited binaries on our ftp and on our POST forms.
[21:12:20 CEST] <j-b> ubitux: or just SF retaliating from us switching out of their infra. (if you like conspiracies)
[21:13:24 CEST] <JEEB> seems like skript kiddies still can want to DDOS you even if you're just providing something for free. and yes, trying to get backdoor'd binaries onto mirrors
[21:13:50 CEST] <ubitux> strange that they actually target a single binary; maybe it's because someone controlling a botnet is making all his instances download that binary for whatever reason (patch it on the fly to swap an existing installation or whatever) 
[21:14:09 CEST] <nevcairiel> according to the video, they even only targeted a small file, not the actual binary
[21:14:18 CEST] <nevcairiel> maybe t hats more efficient in producing load
[21:14:22 CEST] <ubitux> what's the kind of request? download the whole file?
[21:14:37 CEST] <ubitux> or just pure request overload
[21:15:32 CEST] <JEEB> at least one skript kiddie tried this in my case https://en.wikipedia.org/wiki/Slowloris_(computer_security)
[21:29:02 CEST] <llogan> durandal_1707: someone from Adobe sent me an alleged 4:2:2 DNxHR SQ 8192x8192 that doesn't decode properly with ffmpeg. want me to have them provide the sample? it's 2.8G
[21:30:01 CEST] <durandal_1707> llogan: what error you get?
[21:36:59 CEST] <llogan> durandal_1707: none. just solid green video if i output with mpeg4. https://pastebin.com/PydEum55 but i didn't try anything else. in middle of other things...
[21:42:22 CEST] <nevcairiel> are you sure thts just not too much for mpeg4 :D
[21:49:47 CEST] <durandal_1707> llogan: is it wrapped in mov?
[21:51:12 CEST] <durandal_1707> just do -c:v copy -an out.dnxhd and start uploading few mbs sonewhere
[21:52:02 CEST] <llogan> nevcairiel: i tried a png output too
[21:57:39 CEST] <durandal_1707> llogan: i only need 1 frame, 2.8 div 150
[22:14:55 CEST] <durandal_1707> llogan: what is it supposed to have displayed?
[22:15:16 CEST] <durandal_1707> quicktimeplayer crashes here
[22:22:59 CEST] <llogan> durandal_1707: http://0x0.st/w6C.jpg
[22:23:07 CEST] <llogan> and yes, it was in mov
[22:23:28 CEST] <llogan> the single frame crashed mine too
[22:25:04 CEST] <llogan> oddly, it did play on the second attempt
[23:31:37 CEST] <durandal_1707> llogan: so this first single frame plays ok?
[23:37:06 CEST] <llogan> durandal_1707: it seemed to in QT on a Windows 7 VM.
[23:39:50 CEST] <llogan> ...in mov
[00:00:00 CEST] --- Tue Apr 11 2017