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

Thu Mar 10 02:05:02 CET 2016

[00:01:21 CET] <cone-905> ffmpeg 03Reimar Döffinger 07master:b91e3763905a: aacenc: use generational cache instead of resetting.
[00:01:22 CET] <cone-905> ffmpeg 03Reimar Döffinger 07master:b60dfae7af65: aacenc_utils: Use temporary variable.
[00:58:50 CET] <ethe> I'm a little confused, I think I need timefilter, but not sure. How would I go about syncing output to samplerate? I want to say use ff_timefilter_eval to check how long since the last frame was sent, and if it's above 1/samplerate, then I need to send a frame again
[03:13:11 CET] <Timothy_Gu> ethe: why would you have to do that?
[03:13:32 CET] <ethe> Timothy_Gu: to output at the samplerate to JACK
[03:14:14 CET] <ethe> using -re breaks it, because (I think), it's not getting frames to the write quick enough
[03:17:17 CET] <Timothy_Gu> ethe: just dumping all the frames you get to JACK doesn't work?
[03:18:39 CET] <ethe> then it goes to jack at 4x speed, and outputs crazy fast
[03:19:22 CET] <Timothy_Gu> ethe: that shows that the pipeline should be able to satisfy a much higher throughput
[03:19:40 CET] <Timothy_Gu> and -re limits that throughput to a normal rate
[03:19:53 CET] <Timothy_Gu> and JACK apparent can't take the normal rate?
[03:22:50 CET] <ethe> lemme get a patch quick, might be easier to explain
[03:26:52 CET] <ethe> Timothy_Gu: https://gist.github.com/cefad88c48e83f5a57fd
[03:29:20 CET] <ethe> I reckon I'm thinking that the wrong thing is the problem, even if it is faster playback it shouldn't be *so* distorted, just pitched up.
[03:29:59 CET] <Timothy_Gu> ethe: do I need jack2 or jack1
[03:30:03 CET] <Timothy_Gu> to build it
[03:30:23 CET] <ethe> they use a common api, so in theory, either.
[03:30:26 CET] <ethe> ABI*
[03:31:16 CET] <ethe> I'm testing with jack2 though
[04:48:04 CET] <cone-628> ffmpeg 03Michael Niedermayer 07master:89862cd73401: avcodec/ffjni: Fix ;;
[04:48:04 CET] <cone-628> ffmpeg 03Michael Niedermayer 07master:a008a7cc953e: avcodec/ffjni: Fix occured typo
[04:53:30 CET] <Timothy_Gu> ethe: I'm fairly sure the slowness results from your allocating memory in process_callback
[04:53:46 CET] <Timothy_Gu> jack_dec explicitly warns against that
[04:56:11 CET] <Timothy_Gu> for me even without -re the output still stutters
[05:58:55 CET] <arthcp> Where can I find more information about the rm container? 
[05:59:14 CET] <Compn> THE GARBAGE!
[05:59:16 CET] <Compn> haha :P
[05:59:28 CET] <Compn> arthcp : realmedia put a lot of info in openhelix website
[05:59:45 CET] <Compn> arthcp : http://wiki.multimedia.cx/index.php?title=RM
[06:00:29 CET] <arthcp> Compn: I'll give it a try
[06:01:55 CET] <arthcp> Compn: thb
[06:02:18 CET] <arthcp> Compn: thanks... It's what I was looking for
[06:02:35 CET] <Compn> no problem
[06:02:44 CET] Action: Compn afk
[07:45:35 CET] <rcombs> `rm *.rm`
[08:29:19 CET] <flux> yes, when you want to watch some files real quick, it's best to use the RealMedia player, "rm".
[11:45:15 CET] <carpediem> Hello developers
[11:46:11 CET] <carpediem> I have been running afl-fuzz on ffmpeg as part of the GSOC Project "Create a fuzzing testsuite for FFmpeg" for the past few days
[11:46:58 CET] <carpediem> during this period, afl-fuzz has reported quite a lot of hangs (almost 500+)
[11:47:07 CET] <kierank> that can be because your PC is too slow
[11:47:14 CET] <kierank> you should increase the timeout threshold
[11:47:22 CET] <kierank> unless you can specifically reproduce the hang
[11:47:49 CET] <carpediem> ok. Now I will be working on reproducing the hangs and reporting them to your bug tracker
[11:48:04 CET] <kierank> if you can't reproduce the first couple then increase the threshold
[11:48:17 CET] <kierank> I would still use zzuf though, much quicker to find low hanging stuff
[11:48:37 CET] <carpediem> ok
[11:48:53 CET] <carpediem> should I batch process these hang files through zzuf?
[11:49:07 CET] <kierank> no
[11:49:16 CET] <kierank> zzuf is an alternative to afl-fuzz
[11:49:22 CET] <kierank> try reproducing the hangs first
[11:49:28 CET] <kierank> it could be they are just files which are slow to decode
[11:49:28 CET] <carpediem> ok
[11:50:19 CET] <carpediem> one more thing, qualification task for this project included building fffuzz
[11:50:32 CET] <carpediem> I git cloned it from the repo
[11:51:03 CET] <carpediem> but when I try to build it, it does not detect the include files(the libraries)
[11:51:24 CET] <kierank> well the idea should be that you use fffuzz to fuzz 
[11:51:24 CET] <carpediem> even when the directory is changed to that one which contains the libraries
[11:51:38 CET] <kierank> you need to do "make install" on ffmpeg and have pkg-config available
[11:52:08 CET] <carpediem> ok. I will try again.
[11:53:44 CET] <cone-861> ffmpeg 03Paul B Mahol 07master:953b8c5a43ef: avfilter/vf_waveform: use intensity for other components too
[12:34:32 CET] <thardin> woo
[12:35:36 CET] <carpediem> Hi, I tried building fffuzz and ran into an error
[12:35:39 CET] <carpediem> build.sh: 1: build.sh: afl-clang-fast: not found
[12:36:00 CET] <carpediem> should I post a pastebin?
[12:42:55 CET] <kierank> there's away of installing afl-clang-fast in the afl-help
[12:43:03 CET] <kierank> can't remember where exactly
[12:44:36 CET] <carpediem> ok. will find it out and install. 
[13:05:51 CET] <DSM_> hi everyone
[13:08:58 CET] <durandal_1707> Hi
[13:29:22 CET] <nevcairiel> michaelni: the seek-cache-pipe test you added last week fails on one of my fate boxes
[13:42:08 CET] <kierank> does the lavc api provide a way to signal if the frame had corrupt data
[13:42:20 CET] <nevcairiel> there is a flag
[13:43:55 CET] <kierank> I haven't found that flag
[13:44:38 CET] <nevcairiel> AVFrame.decode_error_flags
[13:45:14 CET] <nevcairiel> there is also AV_FRAME_FLAG_CORRUPT for AVFrame.flags
[13:50:52 CET] <michaelni> nevcairiel, seems it fails on your enable-shared box while passing on the static one, no information is shown about the failure. Is there something special about shared msvc builds and pipes or something ?
[13:51:38 CET] <nevcairiel> no idea why shared should be failing
[13:51:56 CET] <nevcairiel> due to the piping i cant attach a debugger though
[13:52:07 CET] <nevcairiel> unless there is a gdb flag that  i dont know about =p
[13:57:08 CET] <nevcairiel> looks like it aborts because cache tries to seek the fd
[13:57:14 CET] <nevcairiel> which it doesnt allow
[13:58:21 CET] <nevcairiel> no idea why static wouldnt also do that
[14:00:48 CET] <cone-861> ffmpeg 03Carl Eugen Hoyos 07master:144ef773c714: Use correct msvc type specifiers for ptrdiff_t and size_t.
[14:02:46 CET] <cone-861> ffmpeg 03Carl Eugen Hoyos 07master:a6a52ef29ac2: lavc/hevc_ps: Fix offset for yuv422 and yuv444.
[14:04:45 CET] <nevcairiel> why does the cache protocol create a temp cache file and then delete it right after? o.o
[14:06:46 CET] <michaelni> so it wont leave a stale file on exit
[14:06:51 CET] <nevcairiel> michaelni: i found the problem, av_tempfile returns a file handle across dynamic library boundary, thats not allowed
[14:08:28 CET] <nevcairiel> because the way we build msvc shared libs, every lib has its own CRT, and handles are not interchangeable
[14:08:30 CET] <cone-861> ffmpeg 03Carl Eugen Hoyos 07master:260c12cdd1df: lavc/mjpegdec: Set sar for multiscope videos.
[14:11:42 CET] <nevcairiel> (ie. a very bad idea for public API)
[14:12:31 CET] <BtbN> Really? Aren't they per-application?
[14:12:50 CET] <nevcairiel> not if you statically link the CRT in like we do
[14:13:16 CET] <BtbN> so the handle is more complex than a fd number on linux i assume
[14:13:51 CET] <nevcairiel> there is a low level fd handle somewhere behind it, but what you get is higher level and tracked by the current CRT
[14:14:07 CET] <cone-861> ffmpeg 03Carl Eugen Hoyos 07master:fb9036b3142e: lavf/mpeg: Identify sub-stream ID 0xa1 as mlp.
[14:15:37 CET] <nevcairiel> ie. you can call _get_osfhandle and _open_osfhandle to get the OS handle and create a CRT handle for an OS handle
[14:15:54 CET] <nevcairiel> but thats really rather special to want that
[14:17:00 CET] <ismail> nevcairiel: (just wondering) whay are you statically linking crt for each DLL?
[14:19:00 CET] <nevcairiel> doesnt require shipping around specific runtime versions
[14:19:51 CET] <cone-861> ffmpeg 03Carl Eugen Hoyos 07master:a62d76889470: configure: Check for msghdr struct.
[14:19:53 CET] <ismail> I see
[14:21:36 CET] <michaelni> nevcairiel, s it safe to pass pointers to open/mkstemp between dlls and when called later will actually provide a local useable fd ?
[14:22:29 CET] <nevcairiel> seems evil, why not just return a temp filename instead
[14:22:47 CET] <ubitux> are we going to do tep2 lavc this week end?
[14:23:28 CET] <nevcairiel> i still have no idea what you mean with lavc
[14:23:33 CET] <nevcairiel> lavc does not change with this
[14:23:43 CET] <nevcairiel> its lavf only
[14:23:55 CET] <nevcairiel> and the old one isnt even remotely finished
[14:24:28 CET] <ubitux> oh my bad
[14:24:42 CET] <ubitux> yeah ok, sorry
[14:25:02 CET] <ubitux> so there is only this big commit followed by the tools
[14:25:29 CET] <nevcairiel> the big commit introduces the new API, everything else is just moving the cli tools to the new API
[14:25:53 CET] <michaelni> nevcairiel, yes it seems evil, but then to fix the av_tempfile() implementation we need to call open/mkstemp from a inline function of a public header
[14:26:20 CET] <michaelni> iam not sure about what kind of headers and config.h stuff that would need
[14:26:58 CET] <michaelni> or we could deprecate av_tempfile() 
[14:27:27 CET] <nevcairiel> to solve the problem with generic file opening, we have file_open.c in every library that includes a C file from libavutil
[14:27:32 CET] <nevcairiel> but no public API of course
[14:32:08 CET] <nevcairiel> so we could use that mechanism to offer ff_tempfile, deprecate av_tempfile with a warning that its not safe on all systems
[14:33:23 CET] <ubitux> arent most of the failing tests due to mov?
[14:36:29 CET] <michaelni> nevcairiel, is the av_fopen_utf8() call in ffmpeg_opt.c havng the same issue ?
[14:36:43 CET] <nevcairiel> probably
[14:36:56 CET] <nevcairiel> someone that added that didnt think very hard about why this whole mess exists =p
[14:37:47 CET] <nevcairiel> its only used for pass1 logfile, who really uses that anyway :D
[14:38:44 CET] <michaelni> low impact is good but it should be fixed anyway
[14:39:06 CET] <nevcairiel> lets see who to blame for even adding that public api
[14:39:23 CET] <nevcairiel> hey its you =P
[14:40:13 CET] <michaelni> i should have realized :(
[14:40:23 CET] <nevcairiel> but yes, we should not have any public API that returns file pointers
[14:40:26 CET] <nevcairiel> its not quite portable
[14:40:52 CET] <michaelni> it could be done with static inline functions in theory
[14:41:10 CET] <nevcairiel> that would be private since it needs config.h, not good for the CLI tools
[14:42:25 CET] <nevcairiel> for the libraries the existing solution worked fine with including a file from avutil
[14:42:32 CET] <nevcairiel> for ffmpeg.c, thats not so easy
[14:43:27 CET] <nevcairiel> just to confirm, I build ffmpeg with dynamically linked CRT and that fixed it, so..
[14:44:55 CET] Action: nevcairiel adds a new fate box that tests building that configuration as well, just in case
[14:49:00 CET] <ubitux> btw, i'm adding an assert-level=2 fate instance
[14:50:15 CET] <rcombs> why aren't they all assert-level=2 unless doing perf tests
[14:52:32 CET] <ubitux> rcombs: yeah maybe they should
[14:54:01 CET] <ubitux> the risk i'm seeing is a developer might trigger an assert without realizing because his local build hasn't the option, and then all fate instances turn red
[14:54:51 CET] <nevcairiel> one instance should be enough, doesnt sound like something that would be very setup dependent
[14:56:14 CET] <ubitux> grep 'av_assert[12]' -r **/{x86,arm,ppc,aarch64,mips}|wc -l
[14:56:16 CET] <ubitux> 47
[14:56:23 CET] <ubitux> seems there isn't that much
[14:56:25 CET] <ubitux> indeed
[14:57:10 CET] <ubitux> btw, fate with --disable-everything is still freezing, so i disabled the instance
[14:58:43 CET] <rcombs> could we have a branch that commits go to before merging to master that gets run through fate, and then master ffwd's to that if everything passes?
[14:59:13 CET] <nevcairiel> isnt that what our master is for =p
[15:11:45 CET] <Compn> we could just run fate before committing
[15:11:48 CET] <Compn> (oh shit i said it)
[15:11:54 CET] <Compn> :P
[15:25:43 CET] <Daemon404> [13:40] <@nevcairiel> but yes, we should not have any public API that returns file pointers <-- we have api that consumes file pointers too
[15:25:46 CET] <Daemon404> also evil
[15:26:04 CET] <Daemon404> presumably it should be aviocontext instead
[15:26:07 CET] <durandal_1707> which ones?
[15:26:47 CET] <Daemon404> https://ffmpeg.org/doxygen/trunk/group__lavf__misc.html
[15:48:15 CET] <BBB> so, hows TEP2 going?
[15:48:31 CET] <BBB> should I just merge my patches for vp9_superframe or do you want me to wait for you guys merging all your stuff?
[15:59:18 CET] <Daemon404> BBB, im nto sure if your patchset would be affected by TEP2 anyway>
[15:59:19 CET] <wm4> does it conflict anywhere?
[15:59:35 CET] <BBB> well, libav had some patch to change bsf api right?
[15:59:45 CET] <BBB> I dont know if thats tep2 or after
[16:00:36 CET] <wm4> after
[16:02:18 CET] <Daemon404> P.S. >2>@8< ?> @CAA:8.
[16:02:19 CET] Action: Daemon404 luls
[16:02:36 CET] <Daemon404> Please email your resume and questions to toronto.ffmpeg at gmail.com <-- this stuff is always so sketchy
[16:03:16 CET] <kierank> it's yet another streaming company
[16:03:24 CET] <Daemon404> of course
[16:03:28 CET] <Daemon404> but they dont share their name ;P
[16:03:59 CET] <kierank> well the biggest problem with these things is they want someone who's good at ffmpeg but who suddenly has expertise in java and other stuff
[16:04:10 CET] <kierank> and they'll pay a pittance no doubt
[16:04:36 CET] <kierank> but at the same time pay huge sums to some company using ffmpeg inside
[16:07:01 CET] <Daemon404> java can be learned
[16:07:10 CET] <Daemon404> but you get what you pay for
[16:15:00 CET] <ubitux> endless agony?
[16:18:35 CET] <Compn> working with canadians?
[16:20:36 CET] Action: wm4 awards Compn 50 micro-courmisch
[16:24:22 CET] Action: nevcairiel knows both java and ffmpeg
[16:24:30 CET] Action: nevcairiel has a well paid job, though
[17:53:07 CET] <BBB> kierank: thats why you set up a company that uses ffmpeg inside ;)
[17:53:33 CET] <kierank> and claim it's super secret technology
[17:53:50 CET] <BBB> Daemon404: so since youre merging, do you mind if I merge my patches? theyll require minor extra effort once you merge the patch from libav
[17:54:08 CET] <Daemon404> BBB, teh bsd stuff isnt so bad
[17:54:10 CET] <Daemon404> so its fine
[17:54:15 CET] <Daemon404> its TEP2 that == pain
[17:54:16 CET] <Daemon404> er
[17:54:20 CET] <Daemon404> bsf stuff*
[17:54:22 CET] <Daemon404> best typo.
[17:54:25 CET] <BBB> indeed
[17:54:27 CET] <BBB> freudian
[17:54:39 CET] <Daemon404> lol
[17:55:05 CET] <BBB> Ill help make vp9_superframes work after the bsf merge if you want
[17:56:00 CET] <BBB> kierank: its always best to keep key technology super secret
[17:56:21 CET] <BBB> itd be hard to sell to investors if they heard that your super secret technology could be downloaded for free and that you have no friggin clue how it works
[17:56:57 CET] <BBB> even though you gave a stanford newgrad co-founder 40% equity because he has technical knowledge
[17:59:08 CET] <BBB> (technical knowledge means he converted an algorithm written originally in python to scala some day - he still doesnt quite know what the algorithm does but it uses additions and subtractions in some places)
[18:00:31 CET] <Daemon404> i see you've been to the bay area
[18:00:50 CET] Action: kierank is going to visit for first time soon
[18:01:02 CET] <kierank> not sure I can stomach the smell of BS everywhere
[18:01:08 CET] <Daemon404> kierank, after NAB?
[18:01:12 CET] <kierank> yeah
[18:47:38 CET] <ethe> Timothy_Gu: even when not allocating at all in the process_callback function, and not blocking the write function, throughput is still way below jack. the only solution I can see is limiting jack to samplerate (or other, lower fps)
[18:52:22 CET] <t_than> Hello. I'm I student and I'm thinking of applying for this year's GSoC with ffmpeg (I was mainly thinking about the FFv1 P-frame support)
[18:53:38 CET] <t_than> I have some (academic) experience with video coding, but I haven't developed for ffmpeg. Could someone give me some pointers on where to begin?
[18:54:55 CET] <durandal_1707> t_than: ask michaelni for qualification task
[18:58:36 CET] <t_than> Ok, thank's for your response.
[19:04:25 CET] <michaelni> t_than, you can do the "Improve the compression of the existing FFV1 Intra frames, you can change any part of the algorithm but it must be practical, the more improvement you can achieve, the better " task if you like. If so please add yourself to https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016-Qualis 
[19:04:52 CET] <michaelni> t_than, you can of course also suggest some other qualification task
[19:07:52 CET] <JEEB> wm4: funky with the start_time patch
[19:07:57 CET] <JEEB> more timestamp madness
[19:10:01 CET] <wm4> yeah I'm not sure if I get it
[19:10:21 CET] <t_than> michaelni: Thanks for the response. Do you have in mind any resources that you think would be helpful (an academic paper or development-wise?)
[19:11:05 CET] <JEEB> wm4: I stopped understanding it after I heard about the delay field
[19:11:16 CET] <JEEB> negative timestamps = cut kind of made sense
[19:11:25 CET] <JEEB> and I thought that was why the start_time was positive with mov
[19:11:50 CET] <michaelni> t_than, thats a good question
[19:12:04 CET] <wm4> the start_time is just informational (libavformat/libavcodec itself won't do anything with it)
[19:12:17 CET] <JEEB> ok
[19:12:19 CET] <wm4> as I understand it, the user can use it to rebase timestamps to 0
[19:12:26 CET] <wm4> e.g. if the stream starts at timestamp 24525634
[19:12:46 CET] <wm4> but with codec delay, the interactions with it are a bit more subtle
[19:13:23 CET] <michaelni> t_than, maybe theres some recent paper that surveys dfferent lossless compression methods / compares them, that might be usefull but i dont know one specific that i culd point to
[19:13:27 CET] <nevcairiel> thats what i do with it, rebase to zero, since directshow wants that
[19:15:35 CET] <t_than> I'll look around then to see if I can find anything useful. In case I do, I'll let you know.
[19:51:40 CET] <BBB> kierank: it doesnt smell like bullshit, it smells like the uttermost happiness
[19:51:49 CET] <BBB> kierank: people who see bs move out as quickly as they can :-p
[19:51:59 CET] <BBB> kierank: so the people left are still drinking the koolaid
[19:52:56 CET] <BBB> michaelni: if youre gonna have hm work on ffv1, why not give him the ffv1 specs that were under construction?
[19:53:07 CET] <BBB> michaelni: ts a standard isnt it?
[19:54:37 CET] <michaelni> t_than, you can look at the ffv1 spec, its a good idea to learn about how ffv1 works but they wont directly tell you how it can be improved
[19:54:40 CET] <michaelni> BBB ^
[19:56:11 CET] <BBB> to kno what can be improved, one must first know what it currently does
[19:56:12 CET] <michaelni> http://www.ffmpeg.org/~michael/ffv1.html or http://www.ffmpeg.org/~michael/ffv1.pdf
[19:57:31 CET] <michaelni> and also of course the source code libavcodec/ffv1*.c
[20:07:26 CET] <cone-909> ffmpeg 03Vicente Olivert Riera 07master:ad16eff64ba7: mips: add support for R6
[20:07:27 CET] <cone-909> ffmpeg 03NagaChaitanya Vellanki 07master:285fda093732: Add tests for functions in hash.c
[20:08:51 CET] <jamrial> michaelni: i was waiting (and hoping) for reimar to comment and push that instead, seeing how he's the maintainer
[20:08:56 CET] <jamrial> but guess he missed the thread
[20:09:23 CET] <jamrial> oh, nevermind, he just replied
[20:11:24 CET] <michaelni> jamrial, yes, i just didnt want to let a student wait especially when he already is pinging a patch ...
[20:11:49 CET] <jamrial> she said she's not going to apply for gsoc, though
[20:12:10 CET] <jamrial> was this for outreachy?
[20:13:48 CET] <michaelni> NagaChaitanya mentioned gsoc so i assume it was gsoc
[20:14:45 CET] <michaelni> but "full time employed and a part time student." is a problem for both gsoc and outreachy
[20:15:15 CET] <jamrial> she said she didn't qualify, yes
[20:16:06 CET] <michaelni> maybe (s)he wrote the patch before realizing that (s)he will be full time employed during the summer
[20:18:02 CET] <michaelni> just guessing, ask her or him (ive no idea about gender) why (s)he posted a qualification patch even tough she doesnt qualify due to employment ...
[20:20:16 CET] <michaelni> either way iam happy about every contribution and some extra tests for better coverage really doesnt hurt  ...
[21:24:41 CET] <dinux5> I am getting error message: libavutil/buffer.h does not exist while compiling a file which includes avcodec.h
[21:24:56 CET] <dinux5> but the file exists. Why is the error coming then?
[22:15:05 CET] <kierank> 6:51 PM <"BBB> kierank: people who see bs move out as quickly as they can :-p
[22:15:05 CET] <kierank> 6:52 PM <"BBB> kierank: so the people left are still drinking the koolaid
[22:15:08 CET] <kierank> explains a lot actually
[22:15:32 CET] <BBB> ;)
[22:15:44 CET] <kierank> I guess that's what happens in a city oriented around one industry
[22:17:26 CET] <Daemon404> kierank, the other possibility is detroit
[22:48:04 CET] <jabashque> Hi, i'm a student who might be interested in applying for 2016's GSoC. I looked at the unmentored projects and saw the one relating to subtitles, and i'd like to know what i'm supposed to do once i successfully complete the the qualification task
[22:48:23 CET] <jabashque> since there isn't an assigned mentor for that specific task
[22:52:11 CET] <wm4> jabashque: for now, ask ubitux (he isn't going to mentor this, though)
[22:53:46 CET] <ubitux> i can't tell more than what i said in the thread...
[22:54:29 CET] <ubitux> you might not be the same person though, i'm refering to http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-March/191048.html
[22:54:39 CET] <jabashque> yeah, i'm not the same person
[22:55:50 CET] <jabashque> also, thank you for pointing me to that.
[00:00:00 CET] --- Thu Mar 10 2016