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

[burek]

[00:00] <cone-408> ffmpeg.git 03Vittorio Giovara 07master:195942ed9b9b: riff: Support QT RLE Animation in avi ('rle ' FourCC)
[00:00] <cone-408> ffmpeg.git 03Michael Niedermayer 07master:77ae94727f04: Merge commit '195942ed9b9b563ec86d34b73aa2c1ee8715d59d'
[01:24] <cone-408> ffmpeg.git 03Supraja Meedinti 07master:092ee6cd32e4: libavutil: optimize twofish cipher
[01:50] <cone-408> ffmpeg.git 03Michael Niedermayer 07master:dfc2a3982fa8: avcodec/wmalosslessdec: Add () to protect the arguments of WMASIGN()
[01:50] <cone-408> ffmpeg.git 03Michael Niedermayer 07master:b7c19aee6c86: avcodec/wavpack: Add () to protect the arguments of UPDATE_WEIGHT_CLIP()
[01:50] <cone-408> ffmpeg.git 03Michael Niedermayer 07master:0babb896b435: compat/avisynth/windowsPorts/windows2linux: Add () to protect macro arguments
[02:18] <cone-408> ffmpeg.git 03Michael Niedermayer 07master:d501b986a976: swscale/bayer_template: Add () to protect the argument of BAYER_READ()
[02:18] <cone-408> ffmpeg.git 03Michael Niedermayer 07master:8bc80016c18d: avfilter/vf_removelogo: Add () to protect the argument of apply_mask_fudge_factor()
[10:59] <cone-827> ffmpeg.git 03Paul B Mahol 07master:956bd71eebe4: avcodec/opusdec: remove unused headers
[11:44] <cone-827> ffmpeg.git 03Michael Niedermayer 07master:424ed1a83e1f: avcodec/faxcompr: Fix memleak
[12:46] <cone-827> ffmpeg.git 03Michael Niedermayer 07master:a76e91bf6708: avfilter/avfiltergraph: assert that the heap_bubble index is valid
[12:50] <michaelni> ubitux, coverity found some things in palettegen, showpalette and paletteuse
[12:50] <michaelni> dont know if they are real or false positives
[12:51] <michaelni> didnt check as i assume you want to take a look
[13:35] <cone-827> ffmpeg.git 03Michael Niedermayer 07master:bdb31942174c: avfilter/vf_qp: Fix leak of out_qp_table_buf
[13:41] <ramiro> why is the mpeg4 encoder faster on 1 thread than 4 threads?
[13:41] <ubitux> michaelni: i will, thanks
[13:42] <michaelni> ramiro, what kind of CPU is that and how to reproduce ?
[13:45] <ramiro> michaelni: I'll reproduce it with a sample from fate and get back to you in a few minutes
[13:48] <cone-827> ffmpeg.git 03Michael Niedermayer 07master:9f6431c8f6c4: avfilter/af_channelmap: Move potential dereference after NULL check in get_channel_idx()
[13:59] <ramiro> michaelni: http://pastebin.com/2is3FiPK
[14:04] <cone-827> ffmpeg.git 03Clément BSsch 07master:f40266560b85: avfilter/paletteuse: fix leak in case of error
[14:04] <cone-827> ffmpeg.git 03Clément BSsch 07master:80f44eafaa7a: avfilter/palettegen: fix leak in case of error
[14:04] <cone-827> ffmpeg.git 03Clément BSsch 07master:8087632027d7: avfilter/showpalette: fix leak in case of error
[14:05] <michaelni> ramiro, try time ./ffmpeg ...
[14:06] <ubitux> michaelni: the 3 "leaks" are fixed, the last one was a false positive
[14:06] <ramiro> ha, that was dumb...
[14:07] <michaelni> ubitux, thanks
[14:11] <ramiro> michaelni: still same thing (but not as exaggerated as I thought before)
[14:12] <ramiro> 4.251s (4 threads) vs 3.693s (1 thread)
[14:14] <michaelni> i get real	real	0m1.147s(4 threads) 0m1.995s (1 threads) 
[14:15] <michaelni> user time gets slower which isnt unexpected as there is overhead from more threads 0m5.264s / 0m4.140s
[14:18] <michaelni> also you could try to limit the decoder to 1 thread maybe that is actually limiting 
[14:19] <ramiro> same thing with single threaded decoding
[14:25] <ramiro> hm, I can't reproduce it in another box. I'll look more into it later on the bad box
[14:29] <wm4> michaelni: was the "[FFmpeg-devel] [PATCH 1/2] avformat: Optimize av_find_program_from_stream() so it is O(1) instead of O(streams*programs)" patch set meant to speed up opening .ts?
[14:33] <michaelni> "[PATCH 2/2] avformat/utils: If scan_all_pmts is explicitly disabled then skip streams outside programs in avformat_find_stream_info()" <-- was intended to speedup opening ts, but only a specific set
[14:34] <michaelni> 1/2 just avoids 2/2 causing a potential slowdown due to otherwise slow av_find_program_from_stream()
[14:35] <michaelni> 1/2 on its own is probably a good idea as well
[14:36] <wm4> should I tell someone to try it with these patches?
[14:37] <compn> wm4: you should tell them to upload the ts file so michael can fix it, assuming these patches do not fix the issue.
[14:37] <compn> (i might be ignored by wm4, so someone should tell wm4 that)
[14:38] Action: compn afk
[14:39] Action: compn grumbles about isom and riff tables being seperate
[14:44] <michaelni> wm4, if you like, it requires scan_all_pmts=0 though to make a difference
[14:45] <michaelni> also if it doesnt help, iam interrested in a testcase/sample
[15:16] <wm4> michaelni: what option values does scan_all_pmts take?
[15:18] <michaelni> 0, -1, 1
[15:22] <wm4> but they're not documented anywhere?
[16:22] <cone-30> ffmpeg.git 03Derek Buitenhuis 07master:b920db67317a: libx265: Reduce the scope of some variables
[16:23] <cone-30> ffmpeg.git 03Derek Buitenhuis 07master:8b96e8dd28c8: libx265: Add crf private option
[16:29] <Daemon404> never saw this before:
[16:29] <Daemon404> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/avisynth/windowsPorts/basicDataTypeConversions.h;h=ff367d5a2a7ad2f4c54ae8bfd19a1a7c983d5988;hb=0babb896b4352e48bd2157f7ef08b341f55f2d91
[16:29] <Daemon404> it looks utterly moronic
[16:29] <ubitux> >compat
[16:29] <ubitux> >windows
[16:29] <ubitux> ENOCARE
[16:29] <Daemon404> its nto for windows
[16:29] <Daemon404> windows doesnt need that.
[16:29] <ubitux> but indeed, it stinks
[16:30] <Daemon404> it's redefining stuff that already exists in windows
[16:30] <Daemon404> in fact its redefining things that ONLY exist in windows
[16:30] <Daemon404> its just for "avxsynth"
[16:30] <Daemon404> the abomination that keeps on giving
[16:30] <nevcairiel> thats such an ugly port
[16:31] <nevcairiel> looks like corporate code =P
[16:31] <Daemon404> netflix bro
[16:31] <Daemon404> also it has no license header
[16:31] <nevcairiel> I wouldnt really call that file copyright-worthy
[16:33] <nevcairiel> in other news, building universal osx binaries is hard
[16:33] <nevcairiel> even if you dont want ppc
[16:33] <Daemon404> ubitux, actually that header seems to be defining windows names for linux...
[16:33] <Daemon404> because they "porte" avxsynth that way
[16:33] <Daemon404> nevcairiel, apple doesnt care about non-x86_64, and neither should you
[16:34] <nevcairiel> but but some people still run 32-bit 10.6 mac minis or some such
[16:34] <nevcairiel> or was it old mac books?
[16:34] <ubitux> :(
[16:34] <nevcairiel> something like that
[16:34] <wm4> Daemon404: I assume avxsynth uses types like HWND on unix?
[16:34] <wm4> also what does netflix have to do with this
[16:34] <Daemon404> netflix made avxsynth
[16:34] <wm4> really? ...
[16:34] <Daemon404> yes
[16:35] <Daemon404> "anonymously"
[16:35] <wm4> what does arwen say about this
[16:35] <Daemon404> nowadays? NDA probably. in the past he worked testing avxsynth for them iirc.
[16:36] <Daemon404> i thought avxsynth<->netflix was fairly common knowledge
[16:36] <Daemon404> the idea was they could ditch their expensive windows instances that run avisynth by porting it
[16:36] <Daemon404> because wine totally isnt a thing
[16:37] <Daemon404> in the end they switched to a giant pile of java and an internal ffmpeg ork
[16:37] <Daemon404> fork*
[16:39] <kierank> https://www.linkedin.com/in/milanstevanovic
[16:39] <kierank> "experienced FFMpeg plugin developer (passed Dolby certification for AC-3/DDPlus and AAC encoders)"
[16:39] <kierank> wtf
[16:40] <Daemon404> Multimedia Software Consultant
[16:40] <Daemon404> WhatsApp Inc.
[16:40] <wm4> Daemon404: so axvsynth is effectively dead?
[16:40] <Daemon404> wm4, it never was alive imo
[16:40] <Daemon404> its like 2 guys who wanna keep it going
[16:40] <wm4> too bad ffmpeg is the multimedia garbage shag, so avxsynth will be in ffmpeg forever
[16:41] <Daemon404> it should never have gone in
[16:41] <Daemon404> it went into x264 too
[16:41] <Daemon404> much to my chagrn
[16:41] <Daemon404> chagrin*
[16:42] <Daemon404> kierank, "Designed/implemented/documented the cross-platform client side on-the-fly video transcoding module (FFMpeg/X264)."
[16:42] <Daemon404> inb4 gpl violating
[16:42] <kierank> well of course
[17:57] <cone-30> ffmpeg.git 03Michael Niedermayer 07master:9e008ed1b4ca: avformat/movenc: Fix use of uninitialized variable (ret)
[18:33] <cone-30> ffmpeg.git 03Supraja Meedinti 07master:4b7c26843ce9: tests: fate: adding fate-test for twofish
[19:23] <amalia> Hi saste
[19:24] <amalia> Will ffmpeg do Outreachy program this session ? saste\
[19:25] <saste> amalia, what michaelni said, we don't know how many slots will have
[19:25] <saste> last OPW we only knew at the last time
[19:25] <amalia> at the last minute ? 
[19:26] <saste> amalia, more or less, one slot was sponsored by an external company, and one was assigned by OPW
[19:26] <saste> the other one was paid with donations money
[19:27] <Daemon404> what came of it anyway
[19:27] <Daemon404> besides teh crypto
[19:27] <saste> so we can't tell in advance
[19:27] <aetas> whats the outreach program?
[19:27] <amalia> Last time I compiled ffmpeg on various platforms like fedora and returned results to when applying for a testing project, 3 girls were selected and I wasn't
[19:27] <saste> Daemon404, we got three mentees, all three passed midterm
[19:27] <Daemon404> i meant what went in the codebase
[19:28] <Daemon404> tangible code
[19:28] <amalia> If I was selected, I would have done my project through till final evaluations
[19:28] <saste> Daemon404, mp filters port was mostly done by arwa
[19:28] <Daemon404> oh right.
[19:29] <saste> the other student (akira IIRC) posted a patch which was applied some time ago
[19:30] <saste> Daemon404, BTW do you want to mentor for GSOC/Outreachy?
[19:30] <Daemon404> depends if you mean mentor or "repeat the same instructions over and over again while the student ignores them"
[19:30] <Daemon404> as previous GSOC have been
[19:30] <Daemon404> <_<
[19:31] <aetas> lol
[19:31] <saste> Daemon404, you should apply only if you think it's a good idea and you enjoy it
[19:32] <michaelni> amalia, about OPW 2014-12 see https://trac.ffmpeg.org/wiki/SponsoringPrograms/OPW/2014-12-Qualis  your qualification task was at "Work in Progress" while the other 3 applicants which we accepted had their qualification tasks finished
[19:36] <amalia> michaelni. The task said create 1 OR 2 working images with fate clients.... and I created 1 on fedora. I think nobody updated the that qualis status for my project. 
[19:37] <amalia> michaelni No offence given
[19:39] <jamrial> Daemon404: afaik it was one for crypto, one for lavfi, and one for subtitles
[19:39] <jamrial> the lavfi work culminated with the death of libmpcodecs
[19:39] <Daemon404> the subtitles code looked like they ran all teh existing subtitles code through a markov chain generator, jamrial 
[19:40] <Daemon404> yeah, i forgot about lavfi
[19:40] <michaelni> amalia, you submited no image
[19:41] <amalia> ramiro told me the submission of results on fate.ffmpeg.org was enough
[19:42] <amalia> You saw the fedora test results didn't you michaelni ?
[19:42] <kierank> Daemon404: 
[19:42] <kierank> 6:27 PM <"Daemon404> i meant what went in the codebase
[19:42] <kierank> 6:28 PM <"Daemon404> tangible code
[19:42] <kierank> you know as well as I do GSOC/OPW/Outreachy is about fork politics
[19:42] <kierank> now about getting things done
[19:43] <kierank> not*
[19:43] <saste> kierank, that and some chance to get some nice contributions/contributors
[19:43] <Daemon404> dont ruin my trolling kierank 
[19:43] <kierank> libav had OPW and it was a "great success" [sic] so ffmpeg has to have it too!
[19:44] <michaelni> amalia, yes, i saw a result from fedora but the qualification task was about a virtual machine image, not about locally outside a VM running fate
[19:45] <michaelni> iam sorry that we didnt select you
[19:46] <wm4> kierank: I think it's more about michaelni politics than ffmpeg politics
[19:49] <amalia> michaelni You may have forgotten what's in the email exchanges but let's not belabour the point. I wasn't selected. 
[19:50] <Daemon404> im not sure im understanding what youre looking for amalia
[19:51] <amalia> I worked hard to get selected. I felt used by ffmpeg
[19:52] <Daemon404> it's a competetive process and not everyone can be selected
[19:52] <Daemon404> thats how the program works
[19:52] Action: amalia cries :( Daemon404
[19:53] <amalia> What do you advice as the way forward Daemon404 ?
[19:54] <wm4> amalia: you still can work for this project, you just won't get paid (like most contributors)
[19:54] <Daemon404> or you can apply for the next round.
[19:55] <amalia> I want to apply for the next round but I don't know if OPW will be there Daemon404
[19:55] <Daemon404> i know even less than you about that
[19:55] <Daemon404> im not the guy to aks.
[19:56] <michaelni> it all depends on if there will be a sponsor
[20:26] <compn> well that went well :P
[20:28] <compn> kierank : 1/10 troll harder. the developers in both projects have tried various paid coding opportunities, do you notice that you are the only one left rattling on about libav in here?
[20:30] <compn> i mean , is your free speech right to rattle on about libav, but i'm wondering who you think still cares about the fork business ?
[20:30] <compn> is/its
[20:31] <Daemon404> hes not wrong
[20:31] <Daemon404> ffmpeg only picked up opw after they found out libav was registered.
[20:31] <compn> or after ffmpeg found out about opw itself ?
[20:35] <cone-30> ffmpeg.git 03Derek Buitenhuis 07master:2de887e45b66: libx265: Reduce the scope of some variables
[20:35] <cone-30> ffmpeg.git 03Michael Niedermayer 07master:00acf38379d3: Merge commit '2de887e45b664f44b51686f5979fa8ce6dfe2ec2'
[20:37] <wm4> does anyone know what "bintext" is?
[20:37] <wm4> it makes ffmpeg open .bin files
[20:37] <wm4> which are typically not what bintext expects
[20:37] <wm4> (ff_bintext_demuxer has only a file extension set, no read_probe)
[20:38] <compn> what year was the extension added ?
[20:38] <compn> only bin i remember is bin/cue
[20:38] Action: compn wonders if wm4 still has compn on ignore
[20:51] <cone-30> ffmpeg.git 03Derek Buitenhuis 07master:d617e77cecc5: libx265: Add crf private option
[20:51] <cone-30> ffmpeg.git 03Michael Niedermayer 07master:77c133f7ac52: Merge commit 'd617e77cecc5b363ef1860955b548f4ac007add6'
[20:57] <ePirat> hmm seesm ffmpeg's m3u8 segmenter changes targetduration 
[20:58] <ePirat> pretty sure this is forbidden according to the rfc draft
[20:58] <BtbN> You mean it changes the segment length?
[20:59] <ePirat> I mean it changes the targetduration in the playlist (not only of some segments)
[20:59] <ePirat> but the inital one
[20:59] <ePirat> which should never change
[21:00] <ePirat> or maybe I interpreted the rfc draft wrong (or this changed in a newer version, as I only read a quite old one)
[21:01] <ePirat> but from a implementation point of view it seems that targetduration should never change
[21:02] <ubitux> wm4: yeah it's part of the "ascii" stuff
[21:02] <ubitux> iirc
[21:03] Action: Daemon404 disables it
[21:03] <ePirat> ok just checked: "The value of the EXT-X-TARGETDURATION tag in the Media Playlist MUST NOT change."
[21:04] <nevcairiel> i noticed that before, but i didnt bother to care because it didnt break anything
[21:10] <Daemon404> there it goes again
[21:11] <Daemon404> mind boggling
[21:17] <JEEB> le longest thread
[21:29] <jamrial> hey, if in the long run we end up with a native aac encoder that rivals fdk's then let the thread grow
[21:29] <JEEB> sure, it just worries me
[21:29] <JEEB> that it will never get merged
[21:29] <JEEB> due to never getting "finished"
[21:30] <Daemon404> i would think incremntal changes could be merged
[21:38] <nevcairiel> apparently the improvements to twoloop broke amnr so it asserts now
[21:39] <nevcairiel> which is the blocker right now
[21:41] <wm4> the next version which doesn't happen to break anything should just be merged, even if it's not perfect
[22:22] <cone-30> ffmpeg.git 03Michael Niedermayer 07master:80d278a981ef: ffmpeg_opt: Add missing MATCH_PER_TYPE_OPT() for data codecs
[22:37] <Daemon404> wm4, the more insane thing to me is that theyre devloping with no VCS at all
[22:37] <Daemon404> patches on a bug tracker
[22:37] <Daemon404> like 1999
[22:37] <andlabs> hate to barge in like this but this (someone else's question) has been sitting in my feed reader for a week and I'm cleaning that out; maybe someone here could help the guy - http://stackoverflow.com/questions/28476219/how-to-use-win32-pipe-on-single-application (specifically to ffmpeg)
[22:38] <andlabs> the windows experts there don't know, anyway :S
[22:38] <Daemon404> i dont think we even support windows named pipes
[22:38] <Daemon404> mostly cause noone ever uses them
[22:38] <wm4> lol windows
[22:38] <wm4> but I thought named pipes just work (as client)
[22:39] <Daemon404> i dont know
[22:39] <Daemon404> i think elby had a patch to support it
[22:39] <Daemon404> 1 sec while i dl their stupid rar
[22:47] <Daemon404> +
[22:47] <Daemon404> +    if (av_strstart(filename_utf8, "\\device\\handle\\", &s))
[22:47] <Daemon404> +      return _open_osfhandle(atoi(s), oflag);
[22:47] <Daemon404> from elby's diff
[22:47] <JEEB> yeah, named pipes are a completely different beast in windows
[22:48] <Daemon404> they use a named pipe to transcode
[22:48] <Daemon404> between their app and avdrone
[22:48] <Daemon404> so they dont link at all to libav*
[22:52] <andlabs> right
[22:52] <andlabs> named pipes as a concept is something that's beyond me =p
[22:56] <rcombs> named pipes on non-Windows are simple enough
[23:08] <cone-30> ffmpeg.git 03Michael Niedermayer 07master:e0be5c4fbedd: avutil/sha: Protect macro arguments with ()
[23:26] <wm4> there's vf_thumbnail? ....
[23:30] <ubitux> yes, sorry about that
[23:31] <Daemon404> iirc it's pretty useless
[23:31] <ubitux> :(
[23:31] <Daemon404> like, you still decode teh entire video
[23:31] <Daemon404> just to make a few thumbs
[23:31] <Daemon404> instead of seeking
[23:31] <ubitux> no, you decode n frame and it picks the most representative
[23:31] <ubitux> generally 50 or 100
[23:32] <ubitux> problem is memory.
[23:32] <ubitux> because yeah, seeking.
[23:35] <ubitux> but anyway, you most of the time are more lucky using the scene change detection and picking the first scene change
[23:36] <Daemon404> more or less
[23:36] <Daemon404> or even rand()
[23:36] <ubitux> problem with rand() is that you can have all kind of annoying frames
[23:36] <ubitux> such as high motion, or in a fading, etc
[23:37] <ubitux> but clearly, being forced to cache N frames is annoying, i raised that issue again not that long ago
[23:41] <wm4> seeking on keyframes actually often gets you to scene changes
[23:42] <wm4> at least if the encoder cranked up all the settings
[23:43] <Daemon404> *if* seeking works
[23:43] <wm4> vf_thumbnail makes for a perfect vfr test case in video players, though
[23:43] <wm4> there are so little vfr sources that it gets hard to test
[23:44] <Daemon404> theyre dead simple to make though
[23:44] <Daemon404> also >so few
[23:44] <Daemon404> >iphone makes vfr videos
[23:44] <wm4> it does?
[23:44] <Daemon404> sure does
[23:44] <wm4> how? does it actually have random frame durations?
[23:45] <wm4> random as in arbitrary
[23:45] <ubitux> damn, i didn't realized the guy was from crunchyroll, fun
[23:45] <Daemon404> low movement detection
[23:45] <ubitux> maybe i should recommend him not to use it
[23:45] <ubitux> but well, why not
[23:46] <ubitux> > This is a pretty obvious bug we caught in the thumbnail filter that is very subtle
[23:46] <ubitux> obvious or subtle?
[23:46] Action: ubitux confused
[23:47] <wm4> subtle bug, obvious results?
[23:47] <j-b> m
[23:52] <aetas> wonder what vlc could possibly need 1.2gb of ram for
[00:00] --- Thu Feb 19 2015