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

[burek]

[00:07:55 CET] <cone-878> ffmpeg 03Peter Tissen 07n2.6:HEAD: configure: Make compilable with VS2015 (missing hunk)
[00:43:59 CET] <cone-878> ffmpeg 03Srikanth G 07release/2.4:7071b8192d26: avutil/opencl: is_compiled flag not being cleared in av_opencl_uninit
[00:43:59 CET] <cone-878> ffmpeg 03Srikanth G 07release/2.5:d0aa3d13facb: avutil/opencl: is_compiled flag not being cleared in av_opencl_uninit
[01:24:03 CET] <jamrial> hi BBB
[01:24:14 CET] <jamrial> in case you haven't seen it https://trac.ffmpeg.org/ticket/4359
[01:28:14 CET] <cone-878> ffmpeg 03Jonas Lindgren 07master:cecf45b2bfbb: doc: Add -list_formats all example for video4linux2
[01:28:15 CET] <cone-878> ffmpeg 03Michael Niedermayer 07master:665d47f435c8: Merge commit 'cecf45b2bfbb85e9e59f355428fbd4d8cbc652a8'
[01:36:31 CET] <BBB> oh nice
[01:36:34 CET] <BBB> jamrial: ty
[01:36:39 CET] <BBB> did anyone look into it yet?
[01:41:17 CET] <BBB> I guess not...
[01:42:54 CET] <jamrial> i did briefly :p
[01:44:08 CET] <jamrial> found out that -threads 1 make it decode fine and that it's not asm related, but just that
[02:05:12 CET] <BBB> oh thats interesting
[02:05:23 CET] <BBB> so you think the segmap is not properly mutex-reffed?
[02:05:25 CET] <BBB> I thought it was
[02:05:26 CET] <BBB> odd
[02:14:45 CET] <BBB> vpI dont actually see the corruption in ffplay
[02:15:46 CET] <BBB> or is it the stuff on the left (the people)?
[02:16:31 CET] <jamrial> yeah, the people on the left, in the first few seconds
[02:16:34 CET] <BBB> ah
[02:16:35 CET] <BBB> ok
[02:20:16 CET] <jamrial> tried mpc-hc, not ffplay, and can't reproduce it on every playback. sometimes it's very noticeable, sometimes a little and sometimes not at all
[02:21:18 CET] <jamrial> ffmpeg framemd5 output for the first several frames varies for every run as well
[02:21:51 CET] <BBB> I can reproduce with -threads 1 also?
[02:22:51 CET] <jamrial> -threads 1 for me makes it decode fine. same output as libvpx
[02:23:19 CET] <BBB> in ffplay?
[02:23:26 CET] <jamrial> framemd5
[02:25:03 CET] <cone-878> ffmpeg 03Reynaldo H. Verdejo Pinochet 07release/2.6:791e08563484: RELEASE_NOTES: small grammar fixes and improvements
[02:36:38 CET] <BBB> Ill look tomorrow, tired now
[02:52:36 CET] <Bigpet> ok, so how much do you guys hate including windows headers and using win32 functions :P
[02:53:52 CET] <Bigpet> because microsoft changed the type of FILE in headers in VS2015 and now "stdin->_cnt" no longer compiles
[02:54:09 CET] <Bigpet> and the only alternative I see is using microsofts win32 functions
[02:58:04 CET] <jamrial> depending on where, including os specific headers and such is ok when using the corresponding guards
[02:58:19 CET] <jamrial> see for example libavformat/os_support.{c,h}
[02:59:12 CET] <Bigpet> yeah, it's just in ffmpeg.c
[02:59:20 CET] <Bigpet> the libs compile fine as is
[03:02:34 CET] <jamrial> that seems to be inside a HAVE_PEEKNAMEDPIPE preprocessor guard, which is a windows specific function checked in configure
[03:04:56 CET] <jamrial> you could maybe add a new check in configure for stdin->_cnt availability or whatever is proper for this, and add the relevant changes to ffmpeg.c
[03:05:50 CET] <BBB> oh nm
[03:05:52 CET] <BBB> found it
[03:06:37 CET] <jamrial> alternatively, wait for nevcairiel's opinion. he knows msvc better than i do :p
[03:08:24 CET] <BBB> jamrial: that should fix it, thanks for the poke
[03:08:38 CET] <BBB> also if anyone wants to do proper referencing that buffer I can help you get started
[03:08:42 CET] <BBB> its not hard, Im just too lazy
[03:08:49 CET] <BBB> maybe Ill do it over the weekend
[03:08:55 CET] <BBB> or maybe not at all :-p
[03:10:04 CET] <cone-878> ffmpeg 03Michael Niedermayer 07master:2a34b5099bb4: avfilter/avf_showwaves: Change enums to int, which are accessed via AVOption as int
[03:10:05 CET] <cone-878> ffmpeg 03Michael Niedermayer 07master:b0662a943c81: avfilter/f_perms: Change enums to int, which are accessed via AVOption as int
[03:10:06 CET] <cone-878> ffmpeg 03Michael Niedermayer 07master:6f51cb514b74: avfilter/vf_colormatrix: Change enums to int, which are accessed via AVOption as int
[03:48:58 CET] <jamrial> BBB: no prob
[03:49:22 CET] <jamrial> Bigpet: maybe something like check_struct stdio.h "FILE" _cnt in configure, then HAVE_FILE__CNT would be available for you to use in ffmpeg.c
[03:50:36 CET] <Bigpet> I think there could be a way around that one line, I mean the "PeekNamedPipe" functionality is still there
[03:51:46 CET] <Bigpet> there just needs to be a different way to check whatever _cnt checked (I presume whether there's something in the stdin buffer)
[03:53:31 CET] <Bigpet> I made some quick tets with ReadConsole, ReadFile or WaitForSingleObject but I'm not sure whether the behavior mimicks exactly what's wanted
[04:09:41 CET] <BBB> jamrial: btw if you want to make a 4-frame fate test out of that sample, that would be very cool
[04:09:55 CET] <BBB> its actually a good test case for when I do get to implement segmap referencing
[04:10:06 CET] <jamrial> sure
[04:21:38 CET] <cone-878> ffmpeg 03Ronald S. Bultje 07master:efff3854f05d: vp9: fix segmentation map retention with threading enabled.
[04:27:19 CET] <Compn> so uh
[04:28:06 CET] <Compn> unrelated question. cloud hosting, when they take some servers down, shouldnt the servers be activated in another box within the cloud that isnt going down for maintenence? otherwise whats the point of the cloud ?
[04:29:05 CET] <ninten> hi all i have archive that contain everything to build ALS ref codec and i have done make all now can anyone tell the procedure to decode one of als_ mpeg-4 
[04:40:21 CET] <ninten> anyone thr
[04:40:23 CET] <ninten> !!
[07:09:39 CET] <ninten> hi i am going through this codec for decoding of MPEG-4 ALS http://tinyurl.com/occgj9q 
[07:11:19 CET] <ninten> description in the link says ffmpeg supports this so i was wondering whether i need to incorporate this to ffmpeg compiled software or this codec is already there in the updated version
[10:08:25 CET] <cone-055> ffmpeg 03Michael Niedermayer 07master:ebd59d271c24: Revert "avutil/opencl: is_compiled flag not being cleared in av_opencl_uninit"
[11:31:38 CET] <nevcairiel> Bigpet: WaitForSingleObject should in theory work. But its probably best to just test it, see if it properly reacts to key inputs instead of blocking
[11:35:00 CET] <cone-055> ffmpeg 03James Cowgill 07master:3499a1c0a91c: mips/asmdefs: change include guard to read AVUTIL_ instead of AVCODEC_
[11:55:35 CET] <vladandrei> Hello there. My name is Vlad and I'm new to this community.
[11:56:31 CET] <vladandrei> Can anyone give me a few pointers to get me started? Thanks.
[12:02:55 CET] <ubitux> starting what?
[12:07:44 CET] <vladandrei> Hi. Since this is my first time applying for an open source community, I would very much welcome any thoughs regarding where should I start.
[12:11:46 CET] <ubitux> well, the question is more about what you want to do and what you are interested in
[12:17:46 CET] <vladandrei> Up until recently I've had a limited contact with ffmpeg and my technical knowledge of this particular software is pretty basic. I'm looking for ways through which I can improve on that.  
[12:18:43 CET] <vladandrei> I'm interested in video and sound processing so I'm finding ffmpeg a great place to start contributing
[12:22:05 CET] <wm4> vladandrei: send patches
[12:30:06 CET] <nevcairiel> Just find something that you want to work on, and just do it :)
[12:30:40 CET] <nevcairiel> some people like to pick up a  documentation patch or two to get into the flow a bit
[12:33:23 CET] <wm4> trying to fix random bugs might also a good idea
[12:33:34 CET] <wm4> as long as you don't pick the "long standing architectural issue" ones
[12:35:58 CET] <wm4> or malloc fuzzing (running a program that makes malloc fail occasionally, and then fixing the resulting crashes)
[13:11:27 CET] <vladandrei> That's helpful. I'll get to that
[13:16:08 CET] <cone-055> ffmpeg 03Arwa Arif 07master:48b5be65aedb: avfilter: Add FFT domain filter.
[13:30:34 CET] <Daemon404> Subject: FFmpeg support for interlace with x265
[13:30:35 CET] <Daemon404> :(
[13:30:56 CET] <Mavrik> We're still doing interlaced video in 2015? :)
[13:31:19 CET] <Daemon404> Hi Derek,
[13:31:19 CET] <Daemon404>  
[13:31:19 CET] <Daemon404> I see from git that you are the primary maintainer of the libx265 module for ffmpeg. My company would like to use ffmpeg + libx265 to encode interlaced HEVC, but our assessment shows that it is not supported because libx265 requires that interlaced content be delivered as fields but ffmpeg processes interlaced content as frames (two interleaved fields).  I am writing to ask if you could be available for hire to add this capabili
[13:32:04 CET] <Daemon404> interlacing makes Daemon404 a sad panda
[13:33:17 CET] <Daemon404> to be fair the email is well written and sane.
[13:33:47 CET] <Daemon404> i do wonder -- the last ugly way to do this
[13:33:55 CET] <Daemon404> least*
[13:40:21 CET] <kierank> Take fields input
[13:40:49 CET] <Daemon404> i dont know what mechanisms AVFrame has for that
[13:40:54 CET] <kierank> None
[13:40:57 CET] <Daemon404> figured so
[13:41:00 CET] <kierank> You just do it in the wrapper
[13:41:04 CET] <Daemon404> i could just pass offsets + stride*2
[13:41:06 CET] <Daemon404> in theory
[13:41:22 CET] <kierank> Yes that's what my x264 fields patch does
[13:41:33 CET] <Daemon404> but i dont think i can modify the "framerate" in avcodec
[13:41:46 CET] <kierank> Just double it
[13:42:05 CET] <Daemon404> its kosher to mdoify it inside of avcodec?
[13:42:07 CET] <Daemon404> in the encoder?
[13:42:10 CET] <kierank> Or actually when you do field encoding it's probably already done it
[13:42:13 CET] <kierank> In the encoder
[13:42:20 CET] <kierank> The rate doesn't change
[13:42:28 CET] <Daemon404> ah yes
[13:42:30 CET] <Daemon404> true
[13:42:37 CET] <Daemon404> this should actually be a very simple patch then
[13:42:45 CET] <kierank> It's framerate in avcodec and fields in h364/hevc
[13:42:53 CET] <kierank> You would need to set PIC struct
[13:42:58 CET] <Daemon404> it's a shame my work visa forbids >1 employer
[13:43:00 CET] <Daemon404> so i cant be paid
[13:43:01 CET] <Daemon404> ;)
[13:45:12 CET] <iive> do you have to modify the frame rate, after all it is frame not field rate.
[13:48:01 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.6:28950d1f8ccb: Revert "avutil/opencl: is_compiled flag not being cleared in av_opencl_uninit"
[13:48:02 CET] <cone-055> ffmpeg 03Ronald S. Bultje 07release/2.6:1caad745333c: vp9: fix segmentation map retention with threading enabled.
[13:48:03 CET] <cone-055> ffmpeg 03James Cowgill 07release/2.6:876d2d8db8ed: mips/asmdefs: change include guard to read AVUTIL_ instead of AVCODEC_
[13:50:41 CET] <BBB> michaelni: ty
[14:17:02 CET] <Bigpet> nevcairiel: got it almost working, used a loop of WaitForSingleObject with 0 timeout
[14:17:30 CET] <Bigpet> then filtered all the non-keyboard events with PeekConsoleInput and ReadConsoleInput
[14:18:00 CET] <Bigpet> but now I have an issue with ReadConsoleInput also reacting on modifiers
[14:18:06 CET] <Bigpet> like shift or ctrl
[14:19:04 CET] <Bigpet> if I just try to use read(0, &ch, 1); or ReadConsole() it would just return character, but those all block weirdly enough
[14:19:28 CET] <nevcairiel> yeah the entire point of that function is to get keyboard input non-blocking :(
[14:20:03 CET] <Bigpet> I mean read(0, &ch, 1); obviously doesn't block when (stdin->_cnt > 0) is true  but I can't find an analoguos condition with the wait and peek console stuff
[14:20:21 CET] <nevcairiel> i wonder why the kbhit case alone isnt enough and why this special case was needed
[14:21:06 CET] <Bigpet> well the peeknamedpipe stuff is for GUI stuff according to the comments
[14:21:24 CET] <Bigpet> I assume for subsystem gui stuff with attacked consoles or something
[14:21:34 CET] <nevcairiel> i guess, default stdin is disabled then
[14:21:49 CET] <Bigpet> *attached
[14:24:19 CET] <Bigpet> hm, looks like the modifiers return an ascii value of 0, so that should be easy enough
[14:40:06 CET] <wm4> who, what's the about?
[14:40:15 CET] <wm4> I had my own share of pain with pipes
[14:40:20 CET] <wm4> they're fucking retarded on windows
[14:40:38 CET] <wm4> can't wait on them in an event based way, unless they were created with overlapped IO enabled
[14:40:55 CET] <wm4> Vista+ has API to cancel IO gracefully, but even that is racy
[14:42:40 CET] <Bigpet> nevacairiel: so how bad is is? https://github.com/FFmpeg/FFmpeg/compare/master...Bigpet:master
[14:43:02 CET] <Bigpet> I tested it and it seems to be equivalent as far as I can tell
[14:43:16 CET] <Bigpet> I just might need to try and simplify the control flow
[14:43:37 CET] <nevcairiel> that sure seems like a lot of code
[14:43:49 CET] <Bigpet> I know, I can't find anything else
[14:44:21 CET] <nevcairiel> you should try to match the ffmpeg coding style though, opening/closing { on the same line as the if/else, single-line statements can also skip them entirely
[14:44:22 CET] <wm4> why not break; instead of this variable
[14:44:31 CET] <wm4> that would remove half of the code
[14:45:02 CET] <Bigpet> yeah, this was just copy pasted from a test program I wrote, I didn't match the coding style yet
[14:45:18 CET] <nevcairiel> and yeah, break in a while(true) loop co uld make it even shorter
[14:45:21 CET] <Bigpet> and yeah, the variable was just there to hide that it's a while(1) loop :P
[14:45:47 CET] <wm4> why hide it?
[14:49:08 CET] <Bigpet> should I add some comments, like explaining that ascii = 0 is ignored because it means modifier keys ?
[14:59:16 CET] <aetas> goodjob sourceforge :/
[14:59:37 CET] <aetas> didnt they just go through a whole repair process
[15:03:11 CET] <Bigpet> ok, so how about now? https://github.com/FFmpeg/FFmpeg/compare/master...Bigpet:master
[15:35:47 CET] <Bigpet> alright, so this is a little longer but the semantics are a lot more clear https://github.com/FFmpeg/FFmpeg/compare/FFmpeg:master...Bigpet:win32console?expand=1
[15:36:01 CET] <Bigpet> to non Win32 fanatics I mean
[15:49:57 CET] <nevcairiel> cant we just use kbhit at all times then? it shouldnt block ,should it?
[15:54:16 CET] <nevcairiel> the whole wait t hing seems not really neecessarily
[15:54:19 CET] <nevcairiel> necessary*
[15:58:18 CET] <Bigpet> I assumed it was related to the whole GUI app thing, but I don't know how I would test all the things that the old thing was supposed to do
[16:01:45 CET] <Bigpet> but I guess you're right, if it's used at all then the rest probably doesn't make sense
[16:02:05 CET] <Bigpet> now, the question is, does it make sense to check it twice?
[16:02:45 CET] <Bigpet> since just changing that one line would mean kbhit()->check pipe->kbhit()
[16:03:17 CET] <nevcairiel> would probably need to check the history how that code came to be, maybe it has some hints
[16:11:41 CET] <Bigpet> alright here it is: https://github.com/FFmpeg/FFmpeg/commit/ca4d71b149ebe32aeaf617ffccf362624b9aafb1 doesn't tell me much unfortunately
[16:19:43 CET] <Bigpet> I mean kbhit is deprecated and all but it's used after the #endif, so I don't know
[17:03:16 CET] <nevcairiel> _kbhit is the replacement, only the old name is deprecated
[17:24:58 CET] <andrei_il> Hello 
[17:26:07 CET] <andrei_il> I'm Andrei, second year student at the Faculty of Automatic Control and Computer Science at the  Polytechnic Univ of Bucharest
[17:26:26 CET] <kierank> hello
[17:27:18 CET] <andrei_il> I would like to contribute to ffmpeg for the GSoC 2015 
[17:29:16 CET] <andrei_il> I am interested in working at the directshow digital video capture project
[18:00:58 CET] <Daemon404> so... silly me
[18:01:03 CET] <Daemon404> i have no interlaced content to test
[18:01:29 CET] <nevcairiel> dont we have a interlacing filter =p
[18:02:00 CET] <Daemon404> i mean real temporal interlacing
[18:03:37 CET] <nevcairiel> http://files.1f0.de/samples/Test_clip_avc.1080i59.94.ac3.5.1.mkv
[18:03:41 CET] <nevcairiel> first sample i found
[18:04:13 CET] <Daemon404> ok
[18:04:25 CET] Action: Daemon404 forgot how annoying interlaced 4:2:0 is
[18:04:32 CET] <Daemon404> in that... i cant remember how it even works
[18:04:41 CET] <nevcairiel> chroma is quite funky
[18:05:01 CET] <nevcairiel> but nothing really you need to care about
[18:05:16 CET] <nevcairiel> its only important if you want to upsample it
[18:05:38 CET] <Daemon404> well i mean how to split it
[18:05:40 CET] <Daemon404> for x265
[18:05:51 CET] <nevcairiel> naive split, every second line etc
[18:06:07 CET] <Daemon404> oic
[18:06:09 CET] <kurosu_> the alternating 1/4 3/4 chroma phase?
[18:06:37 CET] <nevcairiel> you only need to take special care when upsampling it, since alternating lines are from different points in time
[18:10:35 CET] <wm4> nevcairiel: aw, directory listing is disabled
[18:10:55 CET] <nevcairiel> a lot of samples with non-meaningful names
[18:35:12 CET] <jfmcarreira> heyy guys
[18:35:14 CET] <jfmcarreira>  is the support of H.264/MVC still part of the google summer of code project mentored by ffmpeg?
[18:37:53 CET] <Bigpet> nevcairiel: even _kbhit is somewhat deprecated, is not available on WinRT
[18:44:58 CET] <Bigpet> I mean, it doesn't really matter if we keep the kbhit right after that, but I really question the need to run both
[18:48:49 CET] <wm4> why do you want to run ffmpeg.c interactively on winrt?
[18:52:23 CET] <Bigpet> I don't
[18:53:42 CET] <Bigpet> But as far as I could make out from Microsofts talk the WinRT API will be their new API of choice to have on new platforms
[18:54:37 CET] <Bigpet> and as I understand it, if you use the Windows AppStore to sell applications they have similar ristrictions
[18:56:02 CET] <Bigpet> not that I know if that would be a use compatible with the licence of FFmpeg
[18:57:51 CET] <Bigpet> regardless, as I said in the mailing list "kbhit()" is apparently not a 1-to-1 replacement of "stdin->_cnt > 0" anyway
[18:59:44 CET] <jamrial> it's worth mentioning that running ffmpeg from a msys2 environment makes it ignore when i press the q key to stop it
[18:59:58 CET] <jamrial> something that doesn't happen when i run it from the command line
[19:22:41 CET] <cone-055> ffmpeg 03Zeng Zhaoxiu 07master:1be605426140: avcodec/vc1_mc: remove useless variables
[19:41:18 CET] <cone-055> ffmpeg 03Martin Storsjö 07master:dcae2e32f7d8: arm: Suppress tags about used cpu arch and extensions
[19:41:19 CET] <cone-055> ffmpeg 03Michael Niedermayer 07master:9a1884a10ecd: Merge commit 'dcae2e32f7d8a1ca5fb8c1e4aa81313be854dd73'
[20:11:12 CET] <cone-055> ffmpeg 03Martin Storsjö 07master:b77e335e4410: configure: Move the .object_arch check to the right place
[20:11:13 CET] <cone-055> ffmpeg 03Michael Niedermayer 07master:a75353e73b8b: Merge commit 'b77e335e441040a40fc6156b8e4a134745d10233'
[20:20:58 CET] <Bigpet> Ok, so to test all stdin methods with ffmpeg I should "test with powershell" "test with cmd.exe" "test with cygwin/MSYS" and test with "CreateProcess with hStdInput being set to a named pipe/file", is there anything I'm missing?
[20:21:49 CET] <Daemon404> i dont think msys/cygwin should really be counted here.
[20:22:30 CET] <Daemon404> also, in poershell stdin and piping is "special"
[20:22:36 CET] <Daemon404> you dont move data, you move "objects"
[20:27:29 CET] <cone-055> ffmpeg 03Xiangyu Liu 07master:b1e9634c1012: ChangeLog: Remove the redundant VP9 RTP entry
[20:27:30 CET] <cone-055> ffmpeg 03Zeng Zhaoxiu 07master:02fc168c9366: avcodec/golomb: cleanup
[21:13:38 CET] <durandal_1707> is there any usecase of fftfilt?
[21:18:29 CET] <cone-055> ffmpeg 03zhaoxiu.zeng 07master:468defc57b47: avcodec/vc1_mc: Simplify v_edge_pos and src_y correction when fieldmv is true
[21:36:17 CET] <cone-055> ffmpeg 03zhaoxiu.zeng 07master:9870c0361531: avcodec/vc1_mc: change the type of s_rndtblfield to uint8_t
[22:03:32 CET] <Bigpet> lol, this is stupid
[22:03:41 CET] <Bigpet> I labour over this one function
[22:04:00 CET] <Bigpet> then I go looking for some usage and "read_key" is never even called in the whole codebase
[22:04:46 CET] <Bigpet> well this was an entertaining way to waste a few hours
[22:05:17 CET] <cone-055> ffmpeg 03Michael Niedermayer 07master:e3201c38d53d: avcodec/utils: Align YUV411 by as much as the other YUV variants
[22:05:18 CET] <cone-055> ffmpeg 03Michael Niedermayer 07master:1ae092587fc1: avcodec/opusdec: Clear out pointers per packet
[22:05:19 CET] <cone-055> ffmpeg 03Michael Niedermayer 07master:6c583e9048fe: avcodec/opusdec: Fix delayed sample value
[22:07:08 CET] <Bigpet> oh wait, it is, how did my first search miss that
[22:07:09 CET] <jamrial> you mean in ffmpeg.c? it's called by check_keyboard_interaction()
[23:35:06 CET] Action: ubitux discovers squish(x) and wonders what it's about
[23:36:17 CET] <ubitux> oh it's actually from 2002 with rate control code
[23:38:30 CET] <jamrial> geez, one of the examples michaelni sent for fftfilt made an h264 sample go from 50fps to 1.5fps
[23:38:50 CET] <jamrial> RDFT is in need of some x86 asm :P
[23:39:38 CET] <ubitux> http://trac.ffmpeg.org/ticket/3921
[23:40:10 CET] <jamrial> yeah, i remember that ticket
[23:40:37 CET] <ubitux> feel free to comment about fftfilt
[23:40:55 CET] <jamrial> for that matter, vf_fftfilt may need a dep for rdft in configure
[23:41:10 CET] <ubitux> definitely
[23:41:30 CET] <ubitux> just like showspectrum
[00:00:00 CET] --- Sun Mar  8 2015