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

[burek]

[00:05:41 CET] <ubitux> tmm1: did you read the README from the hackipedia.org link?
[00:07:40 CET] <ubitux> anyway, 'night
[00:57:37 CET] <tmm1> michaelni: can you revert fe225b113 to fix fate, and then i'll re-roll my patchset off master for ubitux to review tomorrow
[01:02:31 CET] <cone-686> ffmpeg 03Ricardo Constantino 07master:be0f005da639: configure: Use libgcrypt-config's cflags
[01:07:35 CET] <tmm1> or i'll just fix it and he can merge that in, i guess it doesn't matter
[02:38:38 CET] <Compn> anyone want to burn the samples to a disc and mail them to guy requesting them ?
[02:38:47 CET] <Compn> (someone asked webmaster@ for a copy of samples repo on disc)
[02:39:21 CET] <Compn> theres at least 60gb , i'm guessing more like 80gb now), so that would be a dozen dvd or couple blurays
[02:40:07 CET] <BtbN> One BR i think?
[02:40:53 CET] Action: Compn only sees 25gb bluray discs
[02:41:00 CET] <BtbN> There are 100GB ones
[02:41:06 CET] <Compn> oh i see :)
[02:41:22 CET] <BtbN> They are kinda rare and expensive though
[02:41:31 CET] <BtbN> Might be cheaper to just by a 128GB SD card
[02:41:35 CET] <BtbN> +u
[02:41:59 CET] <BtbN> lol, yeah. _one_ 100GB BD-R is 50¬
[02:42:45 CET] <Compn> looks like $21 per disc, according to amazon shipping direct from japan :D
[02:43:10 CET] <Compn> http://www.amazon.com/gp/offer-listing/B0041CJMRU/condition=new
[02:43:37 CET] <BtbN> A 128GB micro-SD is 40¬
[02:43:48 CET] <nevcairiel> why would we bother to fullfill that request, he could easily find someone  with internet and have them download it for cheaper =p
[02:44:04 CET] <Compn> he said he would pay for it
[02:44:14 CET] <Compn> some people like taking small jobs. i dunno ...
[02:44:27 CET] <BtbN> Did he mention where in the world he is?
[02:44:50 CET] <Compn> nope
[02:45:05 CET] Action: Compn stalks internet
[02:45:31 CET] <Compn> no, no idea
[02:57:45 CET] <J_Darnley> Wait, which samples are we talking about?  Fate is <1G
[03:05:47 CET] <Compn> entire samples.ffmpeg.org
[03:06:19 CET] <BtbN> why oO
[03:06:51 CET] <Compn> we get many requests per year to grab all samples. many reasons, usually testing some video equipment they have made or purchased
[03:08:28 CET] <Compn> national library of australia asked, utc aerospace employee, western digital tv employee.... 
[03:09:15 CET] <BtbN> And they can't just download it? Or are they just beeing polite about not wanting to stress the samples server?
[03:09:22 CET] <Compn> china edu student asked so he could add it to "fuzzing corpus"
[03:09:29 CET] <Compn> BtbN : http://samples.ffmpeg.org/00-README
[03:09:39 CET] <Compn> our readme says to ask because it may stress the server, correct
[03:11:09 CET] <J_Darnley> Well I can't make good on that offer.  I would need to download it first.
[03:12:07 CET] <Compn> its never been a problem, so everyone who has asked gets permission
[03:14:01 CET] <BtbN> the bwlimit also seems kinda outdated
[03:14:12 CET] <Compn> its an old message.
[03:14:17 CET] <Compn> how long would 50g take at 50k/s ?
[03:14:22 CET] <BtbN> couple days
[03:23:55 CET] <Compn> 96G     unified/
[03:24:01 CET] <Compn> ah yes. 96 gigs of samples now
[03:30:16 CET] <J_Darnley> That would take 22 days at 50KB/s
[03:32:09 CET] <Compn> lol
[03:58:31 CET] <cone-686> ffmpeg 03Michael Niedermayer 07master:6e249466cc6b: avformat/movenc: Check that pkt duration is within 32bit range
[05:10:20 CET] <tmm1> ubitux: looks like my assumptions were all wrong so i reverted the last few commits and started over: https://github.com/tmm1/ffmpeg/compare/master...upstream-cc-2
[06:51:28 CET] <ubitux> tmm1: ah, i like this better
[06:52:45 CET] <ubitux> yay font styles
[06:53:43 CET] <ubitux> is CCFONT_UNDERLINED_ITALICS really supposed to be in the enum?
[06:54:06 CET] <ubitux> it really looks like CCFONT_ITALICS|CCFONT_UNDERLINED :p
[06:54:19 CET] <ubitux> (1|2==3)
[07:02:59 CET] <prelude2004c> hey, trying to get an answer on ffmpeg for the last few days..anyone here know the quick answer ? " hey everyone.. anyone know why when i record PVR my PVR STart TIME is a negative value ? something to do with -ss ? seeking ? how do i prevent it from being negative and make sure the recording always starts at 00:00:00 "
[08:25:51 CET] <tmm1> ubitux: not sure
[08:26:07 CET] <tmm1> probably doesnt belong lol
[08:26:35 CET] <tmm1> ubitux: let me know if anything needs tweaking, i can rebase or edit before bed
[08:26:45 CET] <tmm1> up for a little while longer
[10:53:58 CET] <cone-809> ffmpeg 03Carl Eugen Hoyos 07master:836c79351471: lavc/libvpxenc: Improve documentation for option cpu-used.
[10:56:25 CET] <ubitux> tmm1: i'm going to work on this now
[10:56:37 CET] <ubitux> if you're available
[12:33:38 CET] <cone-809> ffmpeg 03Aman Gupta 07master:23a50c8ab9fb: Revert "lavc/ccaption_dec: reap_screen is not necessary when clearing screen or buffer"
[12:33:39 CET] <cone-809> ffmpeg 03Aman Gupta 07master:578b911b5ee1: Revert "lavc/ccaption_dec: implement "erase non displayed memory""
[12:33:40 CET] <cone-809> ffmpeg 03Aman Gupta 07master:2693275c02f8: Revert "lavc/ccaption_dec: reap_screen() is responsible for clearing output buffer and signaling screen_changed"
[12:33:41 CET] <cone-809> ffmpeg 03Aman Gupta 07master:6049b15c0afc: lavc/ccaption_dec: combine ROLLUP modes as they are identical
[12:33:42 CET] <cone-809> ffmpeg 03Aman Gupta 07master:8fd7f03c56f7: lavc/ccaption_dec: extract ass time base into constant
[12:33:43 CET] <cone-809> ffmpeg 03Aman Gupta 07master:c75b86951626: lavc/ccaption_dec: rename screen_changed to buffer_changed
[12:33:44 CET] <cone-809> ffmpeg 03Aman Gupta 07master:7def844be81b: lavc/ccaption_dec: centralize buffer_changed=1 into reap_screen
[12:33:45 CET] <cone-809> ffmpeg 03Aman Gupta 07master:e521a32af273: lavc/ccaption_dec: clear buffer before populating with screen contents
[12:33:46 CET] <cone-809> ffmpeg 03Aman Gupta 07master:080de371d8c0: lavc/ccaption_dec: extract capture_screen() for future use
[12:33:47 CET] <cone-809> ffmpeg 03Aman Gupta 07master:811ce8f9c599: lavc/ccaption_dec: simplify by passing screen into write_char()
[12:33:48 CET] <cone-809> ffmpeg 03Aman Gupta 07master:086093c77c71: lavc/ccaption_dec: simplify by incrementing cursor_column inside write_char()
[12:33:49 CET] <cone-809> ffmpeg 03Aman Gupta 07master:b7e64be8fbf4: lavc/ccaption_dec: implement font styles
[12:37:47 CET] <cone-809> ffmpeg 03Clément BSsch 07master:5ae07914d047: lavc/ccaption_dec: check for bprint completeness only at the end
[12:37:48 CET] <cone-809> ffmpeg 03Clément BSsch 07master:d587fbb676a9: lavc/ccaption_dec: fix mixed declarations and code warning
[12:39:01 CET] <cone-809> ffmpeg 03Clément BSsch 07master:31bff21d2c06: lavc/ccaption_dec: mark row and font as const in capture_screen()
[12:41:26 CET] <cone-809> ffmpeg 03Clément BSsch 07master:22765140fa67: lavc/ccaption_dec: check for bprint completeness outside the loop
[12:43:34 CET] <nevcairiel> so many commits for silly CCs
[12:43:47 CET] <ubitux> :)
[12:45:11 CET] <cone-809> ffmpeg 03Clément BSsch 07master:0948e0f553c0: lavc/ccaption_dec: simplify rollup cases
[14:00:51 CET] <ubitux> rcombs: i need to patch ass_split
[14:01:10 CET] <ubitux> you still have some pending stuff, right?
[14:10:47 CET] <ubitux> nevcairiel: you used libzvbi sub decoder recently, didn't you?
[14:13:19 CET] <ubitux> oh pkt duration is finally int64 nice
[14:13:56 CET] <nevcairiel> i did not
[14:17:31 CET] <ubitux> nevcairiel: ah... i thought there was some kind of timebase num/den + rescaling confusion
[14:17:36 CET] <ubitux> well whatever
[14:18:28 CET] <nevcairiel> atomnuker: the doc is clearly wrong, it says "profile: possible values: [...] aac_pred", which is clearly not a possible value for the profile, since no profile by that name exists, the profile is named aac_main
[14:22:00 CET] <atomnuker> nevcairiel: grr, that was confusing
[14:22:15 CET] <cone-809> ffmpeg 03Rostislav Pehlivanov 07master:ba4c2917ebee: doc/encoders: fix typo in AAC encoder documentation
[14:22:17 CET] <nevcairiel> i should've just fixed =p
[15:33:15 CET] <cone-809> ffmpeg 03Michael Niedermayer 07master:2039b3e7511e: avformat: Add integer fps from 31 to 60 to get_std_framerate()
[16:03:46 CET] <ubitux> durandal_170: legend in showspectrumpic is pretty awesome
[16:04:00 CET] <ubitux> for the lazy, http://b.pkh.me/rondo-spectrum.png
[16:04:30 CET] <ubitux> 'love this (ffmpeg -i in.flac -lavfi showspectrumpic out.png)
[16:05:39 CET] <J_Darnley> Impressive
[16:05:49 CET] <nevcairiel> shouldnt frequency typically be on a log scale
[16:06:09 CET] <ubitux>   scale             <int>        ..FV.... set display scale (from 0 to 5) (default log)
[16:06:16 CET] <ubitux> maybe the legend isn't correct ;)
[16:06:18 CET] <J_Darnley> The markers on the axis could be more intelligently chosen I guess.
[16:06:23 CET] <J_Darnley> *axes
[16:06:35 CET] <nevcairiel> also your audio looks  kinda crazy
[16:06:41 CET] <nevcairiel> so many peaks in all sorts of frequencies
[16:06:50 CET] <ubitux> yes that's curious
[16:07:42 CET] <ubitux> http://b.pkh.me/april-spectrum.png
[16:07:45 CET] <ubitux> here is another weird one
[16:08:07 CET] <ubitux> maybe i should questioning my musical tastes
[16:08:11 CET] <nevcairiel> haha
[16:08:32 CET] <nevcairiel> you listen to full spectrum music, thats for sure =p
[16:08:50 CET] <nevcairiel> audio up to 22kHz!
[16:08:58 CET] Action: J_Darnley goes off to build
[16:09:11 CET] <ubitux> http://b.pkh.me/feathers-spectrum.png
[16:09:24 CET] <ubitux> i wonder if it's really correct
[16:09:24 CET] <nevcairiel> i wonder if the output is really correct though
[16:09:27 CET] <nevcairiel> heh
[16:09:27 CET] <ubitux> :)
[16:09:32 CET] <nevcairiel> that looks too weird
[16:09:48 CET] <ubitux> yep
[16:09:49 CET] <nevcairiel> shove a defined sine signal in it and see what happens
[16:10:30 CET] <ubitux> http://b.pkh.me/sine-spectrum.png
[16:10:40 CET] <nevcairiel> hm that looks as expected
[16:10:40 CET] <ubitux> (-f lavfi -i sine=d=30 -lavfi showspectrumpic)
[16:10:57 CET] <J_Darnley> Does ffmpeg have a sweep?
[16:10:57 CET] <nevcairiel> a bit of aliasing, but that might just be lack of dithering
[16:12:31 CET] <ubitux> you can get the flac i used by doing s/-spectrum.png/.flac/
[16:15:18 CET] <ubitux> (the only really weird one being april)
[16:37:05 CET] <Compn> prelude2004c : you need to ask in #ffmpeg , not here. also you can probably fix it with one of the pts filters i forget the name either -vf genpts or -vf fixpts
[16:38:02 CET] <durandal_170> vf compnts
[16:52:59 CET] <cone-809> ffmpeg 03Sasi Inguva 07master:cbcc88c0393f: libvpx: Support setting color range for vp9.
[17:13:00 CET] <BBB> jamrial: sorry about not pushing, I would have done it after 24 hrs but I was lazy
[17:21:59 CET] <atomnuker> so what does the HAVE_FAST_64BIT flag indicate?
[17:22:46 CET] <nevcairiel> if 64-bit integer math is fast
[17:23:13 CET] <nevcairiel> in practice, if there are native 64-bit regs
[17:24:01 CET] <nevcairiel> its generally used for optimizing bitmask shuffling and whatnot, so either one 64-bit value or two 32-bit ones, etc
[18:58:08 CET] <kierank> so why does nonstatic tables crash frame threading?
[19:27:55 CET] <kierank> fixed it seems
[19:40:48 CET] <Timothy_Gu> J_Darnley: no but one can create one really easily with aevalsrc=sin(440*2*PI*t*t*t)
[20:22:28 CET] <cone-637> ffmpeg 03Paul B Mahol 07master:cbad37e5bfe5: avfilter/avf_showspectrum: set color range to frame
[20:45:51 CET] <tmm1> morning
[20:48:10 CET] <tmm1> ubitux: looks like real time patch is still pending?
[21:05:05 CET] <nevcairiel> so that guy posts the vaapi encoder patch agian, and none of the very obvious issues have been fixed
[21:05:44 CET] <wm4> heh
[21:07:07 CET] <fritsch> didn't he add sws_scale dependencies?
[21:07:59 CET] <fritsch> perhaps someone should contact Bryan Christ if that guy even knows he is becoming a maintainer
[21:08:01 CET] <nevcairiel> excuse me, he fixed one problem =p
[21:08:14 CET] <fritsch> hehe
[21:08:41 CET] <wm4> fritsch: yeah, seems to add libswscale deps (why)
[21:08:51 CET] <wm4> not like it matters, but seems fishy
[21:08:58 CET] <nevcairiel> because we told him his inline asm pixfmt conversion was a no go
[21:09:00 CET] <nevcairiel> :D
[21:09:07 CET] <fritsch> hehe
[21:09:12 CET] <fritsch> exactly
[21:09:43 CET] <fritsch> (const uint8_t * const*)frame->data
[21:09:45 CET] <wm4> ...
[21:12:04 CET] <durandal_170> just tell guy to forget about libVA
[21:12:35 CET] <fritsch> that would be too easy
[21:12:46 CET] <fritsch> if it really works, it would in deed be something nice for ffmpeg
[21:12:51 CET] <fritsch> but only if it's maintainable of course
[21:13:32 CET] <nevcairiel> vaapi works on which hardware, intel only? Just use qsv =p
[21:13:38 CET] <fritsch> not really
[21:16:54 CET] <rcombs> nevcairiel: but muh gpl
[22:20:09 CET] <ubitux> tmm1: yes i wanted to discuss the flush patch first
[22:20:19 CET] <ubitux> i think it's missing some stuff
[22:20:47 CET] <ubitux> like, active_screen
[22:21:07 CET] <ubitux> color and font maybe
[22:21:30 CET] <ubitux> buffer_changed to 0 also maybe
[22:21:49 CET] <ubitux> maybe they're not all relevant though
[22:22:19 CET] <ubitux> also, for the ass thing, i don't think you can go up to 999
[22:22:35 CET] <ubitux> but if you look at the ml, there is a patchset to remove the timing from the payload
[22:22:40 CET] <ubitux> so that won't be an issue anymore
[22:24:06 CET] <ubitux> i'd be more comfortable if you send the real_time patch to the ml though
[22:24:14 CET] <ubitux> some other ppl might want to discuss it
[22:32:10 CET] <ubitux> tmm1: also, can't we have a realtime option that actually set the duration properly?
[22:33:40 CET] <ubitux> (i mean additionally to the one you suggest)
[22:40:06 CET] <tmm1> sure, i can send it to the list
[22:40:43 CET] <tmm1> not sure how we would set duration though
[22:44:14 CET] <tmm1> you need to buffer to know the end time, which means its not real time anymore
[22:44:41 CET] <tmm1> ubitux: ill add color font and activescreen to flush
[23:04:17 CET] <ubitux> tmm1: yes with buffering, it's fine
[23:04:42 CET] <ubitux> but i'm curious about the effect of the text progressively appearing :p
[23:05:04 CET] <ubitux> (even if it requires a first pass to extract the subs)
[23:24:21 CET] <wm4> should a muxer be able to handle such events with unknown duration?
[23:25:08 CET] <ubitux> depends on the muxer capabilities maybe
[23:25:33 CET] <ubitux> subtitles are weird beasts anyway, to use nice words
[23:28:16 CET] <wm4> yeah, it's like they consistently resist abstraction and elegance
[23:31:54 CET] <kierank> yeah the most fucked up thing in multimedia
[23:37:17 CET] <nevcairiel> (and thats saying something)
[23:49:37 CET] <tmm1> ubitux: i pushed a new flush patch to my branch, moved it up ahead of the real_time one
[23:51:24 CET] <tmm1> if that looks good could you merge, and i'll submit the last patch to the list
[23:54:10 CET] <tmm1> i'll just push both to the list and you can merge whenever or leave comments there
[00:00:00 CET] --- Sun Jan 10 2016