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

[burek]

[02:31:08 CET] <cone-246> ffmpeg 03Himangi Saraogi 07master:613483dcfb05: avfilter/vf_telecine: Fix loss of AVFrame properties in output
[02:55:43 CET] <cone-246> ffmpeg 03James Almer 07master:1f5d1eed78fa: avutil/cpu: add missing check for mmxext to av_force_cpu_flags
[03:38:22 CET] <Zeranoe> Is a CUDA encoder faster than it's counterpart CPU encoder?
[03:40:02 CET] <kepstin-laptop> cuda encoders are usually nearly completely different implementations from cpu encoders, so it's hard to make speed comparisons because the quality tends to be different
[03:40:52 CET] <Zeranoe> There's no way to benchmark them at the same quality?
[03:42:30 CET] <kepstin-laptop> that's hard to do; you could try encoding to a certain ssim score, for example, but it would be a slow process to search the encoding space to find a match
[03:42:56 CET] <kepstin-laptop> particularly since you need to get them to match on bitrate and quality to get a useful speed comparison, imo
[03:44:06 CET] <kepstin-laptop> e.g. if you lower the speed/quality tradeoff enough on x264 to get similar "quality per bitrate" as a gpu encoder, you'll probably find that given a high-end cpu, the speed will be pretty comparable.
[03:45:28 CET] <Zeranoe> I have a GTX 970 and a i7 4790k and would be happy to test. I don't know of a free H.264 encoder though
[03:45:31 CET] <kepstin-laptop> only real reason to use a gpu encoder in most cases is that you're live-encoding a screen capture of a cpu load sensitive application.
[03:46:13 CET] <kepstin-laptop> (games are a tricky case, because a cuda encoder might take away execution resources from the game - while a hardware block encoder like intel quicksync doesn't do that)
[03:47:32 CET] <kepstin-laptop> with a gtx 970 vs i7-4790k, you'd want to be comparing nvenc (which I think is a hardware block encoder, but it might use gpu resources in some modes) vs x264
[03:52:20 CET] <kepstin-laptop_> I don't think there's any actual "cuda" encoders (software encoders running all or in part on gpu execution resources) that are complete enough to be worth comparing.
[03:52:48 CET] <Zeranoe> kepstin-laptop_: Even nvenc?
[03:53:05 CET] <kepstin-laptop_> nvenc is is a dedicated hardware encoder
[03:53:24 CET] <kepstin-laptop_> i looked it up, doesn't seem to use the gpu cores.
[03:54:01 CET] <kepstin-laptop_> which makes sense, given that one of the key target markets is probably video game livestreaming
[03:54:57 CET] <Zeranoe> "The NVENC API supports dedicated H.264 hardware video encoding with NVIDIAs Kepler and Maxwell family of GPUs"
[03:55:29 CET] <kepstin-laptop_> It looks like on some older hardware, the H.265 encoder is split between the nvenc hardware and cpu (not gpu)
[03:57:42 CET] <kepstin-laptop_> but yeah, it's dedicated video encoding hardware that's separate from the gpu cores.
[03:59:20 CET] <kepstin-laptop_> x264 has some incomplete opencl "accelleration" code that uses the gpu cores, but apparently it's actually both slower and lower quality than using only the cpu.
[04:54:36 CET] <cone-246> ffmpeg 03Michael Niedermayer 07master:0fee509cf5f8: avutil/timer: show histogram of cpu cycles each run took
[04:54:37 CET] <cone-246> ffmpeg 03Michael Niedermayer 07master:174330b18e63: avutil/timer: give each printed value of STOP_TIMER a fixed length
[08:28:58 CET] <durandal_1707> ninten: why you did not send als float patch to the mailing list?
[08:32:23 CET] <ninten> durandal_1707,  i have commited the code in the github
[08:33:29 CET] <ninten> durandal_1707,  and i am getting some error also and since from last 3 days i was working on my proposal
[08:34:45 CET] <ninten> so as the proposal deadline is over the next thing i will do is to send patch to devel
[08:36:44 CET] <ninten> durandal_1707,  meanwhile you can see commited code here http://tinyurl.com/pvdj5xp
[09:08:20 CET] <durandal_1707> nineten: what about big 1000 structs inside code?
[09:09:48 CET] <durandal_1707> ninten: ^
[09:29:22 CET] <ninten> durandal_1707, instead of acf_flag[1000] it should be acf_flag[c],  but since at the time of intialization we dont know value of no. of channels so i just took the upper bound here
[09:30:17 CET] <ninten> durandal_1707,  anyway i will find a way to declare in struct without wasting space 
[14:53:33 CET] <Daemon404> zip? seriously?
[14:53:36 CET] <Daemon404> why the shit...
[14:54:21 CET] <BtbN> Yeah, most movies come in rar split archives!
[14:54:45 CET] <Daemon404> not to mention lavf is massively the wrong layer
[15:00:30 CET] <Daemon404> if wm4 or i reply to the patches well just be considerd the usual party pooper
[15:00:37 CET] <Daemon404> code iwll go in the ffmpeg garbage dump anyway
[15:02:15 CET] <nevcairiel> at least its not a re-implementation of the zip format, thats already something for ffmpeg :p
[15:04:18 CET] <BtbN> I don't realy see why ffmpeg should have support for that. It's ok for some media player to implement support for archive formats, but for ffmpeg?
[15:04:41 CET] <Daemon404> BtbN, in fact every major media player does
[15:04:47 CET] <Daemon404> mpc-hc, all the mplayers, vlc
[15:04:53 CET] <Daemon404> theres is no reason it should be in lavf
[15:04:56 CET] <Daemon404> it's the wrong layer.
[15:05:01 CET] <nevcairiel> for rar yes, and only uncompressed ones at that, not for zip
[15:05:11 CET] <Daemon404> (and dont give me the bullshit of ffmpeg -i shit.zip)
[15:05:23 CET] <Daemon404> nevcairiel, mpc-hc has zip i think
[15:05:30 CET] <nevcairiel> dont think so
[15:05:40 CET] <Daemon404> the only thing people ship in zips is music
[15:05:42 CET] <BtbN> rar is primariliy supported because of scene releases beeing in rar split archives
[15:05:45 CET] <Daemon404> and most music players have it
[15:05:47 CET] <Daemon404> foobar does
[15:05:58 CET] <wm4> "and libzip seg faulted :)"
[15:06:02 CET] <wm4> from the newest reply
[15:06:12 CET] <rcombs> the player is the wrong layer for it too
[15:06:27 CET] <Daemon404> rcombs, sure, but lavf is more wrong :)
[15:06:31 CET] <rcombs> Daemon404: sure
[15:06:42 CET] <nevcairiel> whats the correct layer then? :p
[15:06:53 CET] <Daemon404> also i 100% guarantee lukasz's end goal is to use the stupid dir listing api proposal
[15:06:54 CET] <rcombs> there's no reason to keep your compressed audio or video files around in rars or zips to begin with
[15:06:56 CET] <Daemon404> to list the zip
[15:06:56 CET] <Daemon404> and stuff
[15:06:59 CET] <Daemon404> (ugh)
[15:07:33 CET] <Daemon404> rcombs, >implying the scene is not full of incompetent people
[15:07:35 CET] <rcombs> if you _really_ want to do that, for some idiotic reason, then I have a FUSE to sell you
[15:07:36 CET] <BtbN> rcombs, well, if you still want to seed them...
[15:07:48 CET] <Daemon404> BtbN, it makes even less sense to have rars in a torrent
[15:07:56 CET] <Daemon404> the rars were meant for ftp topsites
[15:07:58 CET] <Daemon404> due to ftp beign shit
[15:08:06 CET] <BtbN> Yep, but hey, it's so leet
[15:08:07 CET] <Daemon404> torrents have sha1 per chunk.
[15:08:09 CET] <nevcairiel> rars are for ftps and nzbs
[15:08:16 CET] <nevcairiel> in torrents its just super stupid
[15:08:30 CET] <BtbN> And scene torrents... It's stupid, yes.
[15:08:32 CET] <Daemon404> a lot of private trackers require it
[15:08:37 CET] <Daemon404> to show its "Authentic"
[15:08:47 CET] <nevcairiel> i know a bunch that ban rar'ed releases =p
[15:09:10 CET] <Daemon404> i know some scene people idle in here
[15:09:12 CET] <Daemon404> so: lol you guys.
[15:09:49 CET] <wm4> <Daemon404> to show its "Authentic" <- lol
[15:10:18 CET] <BtbN> Well, those trackers are bragging with <10 second "pre times"
[15:10:27 CET] <BtbN> those aren't possible if the bots have to unpack first.
[15:10:44 CET] <Daemon404> BtbN, i was once approached to help write a streaming encode+rar to an ftp
[15:10:46 CET] <Daemon404> from a user in here
[15:10:48 CET] <rcombs> BtbN: sure they are, if you do a streaming unpack
[15:10:48 CET] <Daemon404> (i told them to go away)
[15:10:51 CET] <Daemon404> it's just so lol.
[15:10:51 CET] <nevcairiel> whats the point if the user has to unpack first then :D
[15:10:55 CET] <rcombs> that'd be stupid, but you could
[15:10:59 CET] <Daemon404> rcombs, yes
[15:11:16 CET] <rcombs> (I wonder if I could make money selling a FUSE FS that exposes RARs as directories)
[15:11:31 CET] <wm4> aren't there a bunch of those around?
[15:11:35 CET] <BtbN> rcombs, gvfs-fuse should be able to do that.
[15:11:41 CET] <nevcairiel> this war on the very last second is stupid anyway, i would rather have them review their releases instead of having to post repacks and proper releases all the time
[15:11:42 CET] <rcombs> well then, I probably couldn't
[15:11:45 CET] <wm4> "zip as FS" is definitely an old idea
[15:12:03 CET] <wm4> so maybe someone solved it?
[15:12:21 CET] <Daemon404> nevcairiel, my favourite is when one group's automatic commercial cutters consistently accidentally cut the countdown bit out of episodes of 24
[15:12:25 CET] <Daemon404> like every week
[15:12:26 CET] <Daemon404> it was nuked
[15:12:32 CET] <nevcairiel> heh
[15:12:32 CET] <BtbN> both gvfs and kio have fuse drivers. So you can mount allmost everything as fs that way.
[15:13:50 CET] <iive> exposing rar as directories should be fairly easy. the biggest problem is random access in solid archives.
[15:14:28 CET] <BtbN> kernel cache should take care of that
[15:15:40 CET] <iive> only if it fits into the cache :|
[15:15:54 CET] <Daemon404> for the use-case of scene people, it would be linear
[15:16:12 CET] <Daemon404> (not counting SD)
[16:00:53 CET] <cone-632> ffmpeg 03Himangi Saraogi 07master:dbce8cdacf0c: avfilter/vf_telecine: Avoid floating point values
[16:19:54 CET] <poste9> hello guys can u point me out how to find about scaling down rgb raw data in c++ ? at the least some good well explained algorithm for it?
[17:35:09 CET] <himangi> durandal_1707: not sure to understand your comment
[17:39:56 CET] <durandal_1707> himangi: code looks similar
[17:42:46 CET] <himangi> durandal_1707: It is the exact inverse of the telecine filter which accepts the same parameters etc.. so the code is similar..
[18:54:18 CET] <cone-632> ffmpeg 03Lukasz Marek 07master:184084c6998c: lavf: add directory listing API
[19:02:30 CET] <wm4> Daemon404: shit ^
[19:02:33 CET] <durandal_1707> what if more than 1 student finish qual task?
[19:02:38 CET] <wm4> damage done, maintain forever
[19:05:21 CET] <Daemon404> D:
[19:05:28 CET] <Daemon404> durandal_1707, which task?
[19:05:33 CET] <wm4> APNG
[19:06:46 CET] <Daemon404> i sure hope you dont mean greeshma.
[19:06:54 CET] <Daemon404> i would not pass them
[19:07:19 CET] <Daemon404> copying and pasting code should not constitute a pass.
[19:07:27 CET] <Daemon404> without copyright might i add.
[19:26:19 CET] <j-b> wm4: new API well reviewed and discussed?
[19:27:00 CET] <Daemon404> j-b, yeah so much so it doesnt even have a version bump in case it changes.
[19:27:04 CET] <Daemon404> <_<
[19:27:21 CET] <j-b> Daemon404: haha
[19:28:57 CET] <wm4> looked at the API... avio_read_dir() already doesn't mention the lifetime of the memory it returns
[19:29:11 CET] <wm4> oh wait it does
[19:34:12 CET] <Daemon404> .. lol the copypaste person for exr also copypasted from ccextractor to vlc
[19:34:15 CET] <Daemon404> with no license.
[19:36:40 CET] <j-b> what for?
[19:37:33 CET] <Daemon404> j-b, CIA-708
[19:37:43 CET] <Daemon404> same person as copypaste of exr B44 code
[19:37:45 CET] <Daemon404> for gsoc
[19:38:31 CET] <j-b> Daemon404: sorry, I was ironic about "licenses? what for!"
[19:38:39 CET] <Daemon404> oh ok
[19:38:56 CET] <Daemon404> :V
[19:38:59 CET] <j-b> :D
[19:39:04 CET] <j-b> Friday \o
[19:39:24 CET] <Daemon404> o/
[20:43:22 CET] <michaelni> Daemon404, wm4, j-b, the directory listing patch(es) have been posted to ffmpeg-devel since at least summer 2014, so they are well reviewed by you all i assume
[20:43:43 CET] <Daemon404> i replied the original thread
[20:43:55 CET] <Daemon404> dissenting, if i recall.
[20:44:32 CET] <michaelni> hmm, i dont remember
[20:44:40 CET] <michaelni> do you have a link?
[20:46:29 CET] <michaelni> also if they where rejected they shoould not have been used as qual task, but i really dont remember ATM that they where
[20:48:17 CET] <Daemon404> found it, but i was misremembering, wm4 replied
[20:48:37 CET] <Daemon404> michaelni, my issue isnt with the dir listing api as gsoc anyway
[20:49:52 CET] <michaelni> do you have a link to wm4s mail?
[20:50:34 CET] <Daemon404> there is a big thread in july 2014
[20:52:58 CET] <Daemon404> michaelni, where do we submit who should pass qualification
[20:53:05 CET] <Daemon404> i dont see too many who succeeded.
[20:53:27 CET] <michaelni> the last mail from wm4 i see says "Probably ok. What happens if you try to read byte data from the AVIOContext?" so i dont see where this was rejected
[20:53:43 CET] <Daemon404> yes, it must have been on irc
[20:53:44 CET] <Daemon404> my bad.
[20:54:29 CET] <wm4> michaelni: I wasn't ok with the API, but I reviewed it anyway
[20:54:41 CET] <wm4> because I knew it's going in anyway
[20:55:03 CET] <Daemon404> wm4, theres still one horrible api thing that never went in thankfully
[20:55:07 CET] <Daemon404> so not everything bad goes in
[20:55:41 CET] <wm4> which one?
[20:55:52 CET] <Daemon404> mr nicholas' fabulous subtitles
[20:58:47 CET] <michaelni> qualification status is at: https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2015-Qualis, i dont think we have any students which passed qualification ATM
[20:59:02 CET] <Daemon404> the libsmbclient guy i thought maybe
[20:59:07 CET] <Daemon404> big maybe
[20:59:16 CET] <wm4> what's the deadline?
[21:00:07 CET] <Daemon404> wm4, i thought it was very soon
[21:00:13 CET] <Daemon404> i saw mini's mail this morning
[21:00:33 CET] <Daemon404> if nobody gets the http2 project, ill just add support
[21:00:44 CET] <Daemon404> it's not hard using nghttp2 (low level recv/send lib)
[21:01:36 CET] <michaelni> the libsmbclient patch has comments from lukasz so it needs changes IIUC
[21:01:52 CET] <Daemon404> yeah
[21:01:54 CET] <Daemon404> hence maybe
[21:09:29 CET] <jamrial> as durandal_1707 asked, what would happen if more than one student passes the task for the same project?
[21:10:09 CET] <Daemon404> i do not forsee this happening
[21:10:16 CET] <Daemon404> but i assume we pick who did a better job
[21:10:46 CET] <durandal_1707> Pick one with nicer proposal
[21:34:52 CET] <cone-632> ffmpeg 03Himangi Saraogi 07master:fff78717725b: lavfi: add inverse telecine filter
[21:34:53 CET] <cone-632> ffmpeg 03Michael Niedermayer 07master:d03b998c48a8: avformat/avio: Document the end of list case in avio_read_dir()
[00:00:00 CET] --- Sat Mar 28 2015