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

[burek]

[01:19:12 CEST] <cone-874> ffmpeg 03Andreas Cadhalpun 07master:ca9849eecdf7: aacpsy: correct calculation of minath in psy_3gpp_init
[01:55:44 CEST] <cone-874> ffmpeg 03Vignesh Venkatasubramanian 07master:4f287a3c5007: webmdashenc: Add minimumUpdatePeriod
[03:46:01 CEST] <cone-874> ffmpeg 03James Almer 07master:ba625dd8a12b: avcodec: use av_mod_uintp2() where useful
[03:53:31 CEST] <Prelude2004c> up everyone.. good evening.. having trouble passing a ffmpeg -i < input  > -vcopy and -acopy -f mpegts udp://destination:port ... < --- this causes artifacts i guess because some UDP traffic is missed on the network. Over a distance i guess this is not the best way to pull data. anyone know a better way without transcoding it at source ?
[03:53:32 CEST] <Prelude2004c> maybe somehow with little horsepower i can push it via TCP or something that way if a packet doesn't arrive it gets retransmitted i want to make sure our stream is clean so i can encode it properly any ideas ?
[04:40:23 CEST] <Timothy_Gu> Prelude2004c: isnt UDP not designed for perfect quality?
[05:39:17 CEST] <Timothy_Gu> Daemon404: since when did your ICL FATE clients die?
[06:21:44 CEST] <Timothy_Gu> time xz -dc report.xz >/dev/null ’ 6.711s |||||  time xz -dc report.xz | wc ’ 57.531s
[06:46:52 CEST] <jamrial> nevcairiel: latest mingw-w64 version (i think still git head, probably not in any formal release) implemented the dxva hevc defines
[06:47:22 CEST] <jamrial> and it broke compilation of your ffmpeg fork for lavfilters where you hardcode the compat hevc header :p
[06:50:17 CEST] <jamrial> should be easy to fix, just check for HAVE_DXVA_PICPARAMS_HEVC before including the compat header
[10:09:29 CEST] <haasn> Out of curiosity: How quickly do posts to FFmpeg-devel get moderated?
[10:09:41 CEST] <haasn> Or moderator approval, rather
[10:10:00 CEST] <Kumi1> It's Non-Moderated
[10:10:12 CEST] <Kumi1> Unmoderated
[10:10:18 CEST] <Kumi1> https://www.ffmpeg.org/contact.html#IRCChannels
[10:11:33 CEST] <haasn> It's non-moderated -> Your message to ffmpeg-devel awaits moderator approval
[10:32:34 CEST] <wm4> haasn: because you're not subscribed
[10:36:51 CEST] <haasn> I know this, but I don't want to subscribe just to post a message
[10:36:58 CEST] <haasn> That seems counter-intuitive to me
[10:37:05 CEST] <nevcairiel> then you'll have to wait until a moderator approves it
[10:37:06 CEST] <haasn> What does sending messages have to do with receiving messages?
[10:37:19 CEST] <haasn> Yes, that's what I'm doing
[10:37:53 CEST] <nevcairiel> in general, everyone who tries to submit patches or the like should really submit, because you will otherwise not get the responses to your mail
[10:38:03 CEST] <nevcairiel> s/submit/subscribe/
[10:42:49 CEST] <haasn> I think the API is bad here. Subscription should not be an everything-or-nothing thing. It should be possible to subscribe to replies to your own posts only. In fact, I think this should be the default behavior
[10:43:37 CEST] <haasn> Every single major forum software supports this kind of notification strategy. I don't know why whatever ML software you're using is incapable of it
[10:43:39 CEST] <haasn> Oh well
[10:43:40 CEST] <wm4> actually, maybe it's quite good to force a certain level of involvement in an all or nothing way
[10:44:57 CEST] <haasn> Then I choose nothing
[10:45:42 CEST] <haasn> Same deal with most bug trackers. If people make it hard to post bugs, people don't want to post bugs
[10:46:22 CEST] <haasn> Lost count of how many bug reports I've simply never submitted because they wanted me to sign up for some stupid one-time account just to post a simple bug; meanwhile eg. on Github it's a matter of seconds to hit New Issue
[10:46:26 CEST] <wm4> on the other low quality bug reports cause negative productivity
[10:46:32 CEST] <haasn> And I also get e-mail replies automatically
[10:46:32 CEST] <wm4> *hand
[10:46:33 CEST] <haasn> To my own bug reports, only
[10:46:53 CEST] <haasn> Email notifications for replies*
[10:46:54 CEST] <wm4> github requires you to rrgister too
[10:47:14 CEST] <haasn> Sure, but I don't have to register for every single project
[10:47:16 CEST] <haasn> Just once for the whole website
[10:47:43 CEST] <haasn> True about low quality bug reports I gues
[10:48:17 CEST] <haasn> But at the end of the day it's just one type of specific filtering heuristic, I'm not sure if it works that well in practice
[11:59:35 CEST] <cone-444> ffmpeg 03Vignesh Venkatasubramanian 07master:f82ce6aa882b: webmdashenc: parameter'ize minimumUpdatePeriod
[12:11:05 CEST] <cone-444> ffmpeg 03Andreas Cadhalpun 07master:afc7748d1f6a: alsdec: check sample pointer range in revert_channel_correlation
[12:33:04 CEST] <BBB> hm vp9 build time is also getting our of hand
[12:33:12 CEST] <BBB> maybe Ill split (finally!) in multiple files
[12:35:21 CEST] <nevcairiel> speaking of vp9, do you have plans to support high bitdepth/chroma extensions? users asked me about it :(
[12:37:22 CEST] <kierank> haasn: you can subscribe and not receive emails
[12:37:32 CEST] <kierank> and just ask to be cc'd in
[12:40:20 CEST] <wm4> lol at the libvpx bug that made it into the "standard"
[12:42:59 CEST] <kierank> wm4: happens in h264 too
[12:43:04 CEST] <kierank> but in SVC
[12:45:26 CEST] <wm4> pretty awesome
[12:55:39 CEST] <kierank> wm4: http://www.itu.int/rec/T-REC-H.Imp264-201007-S/en
[14:06:42 CEST] <Compn> haasn : do you need me to approve some mail ?
[14:07:04 CEST] Action: Compn guessing someone already approved it
[14:07:06 CEST] Action: Compn checks
[14:07:53 CEST] <Compn> ok i see it
[14:08:04 CEST] <Compn> haasn : also i'll do you a favor and auto-accept any mails from that addy
[14:08:05 CEST] <Compn> Add nand at .... to one of these sender filters:    Accepts 
[14:08:15 CEST] <haasn> Heh, neat; thanks
[14:08:25 CEST] <haasn> Now I don't even have to go through the process of complaining about hating mailing lists and subscription :p
[14:08:37 CEST] <Compn> right :)
[14:09:13 CEST] <Compn> mail accepted, should already show up on the list now
[14:10:37 CEST] <Compn> you replied to a post but it does not have re: in subject :P
[14:12:05 CEST] <Compn> oh no nevermind i'm blind
[14:12:27 CEST] <haasn> I just copied the fields from the mailto: link generated by that page
[14:12:35 CEST] <haasn> My manually URL decoding it. And copy/pasting the headers into my email client.
[14:12:43 CEST] <haasn> Technology sure is wonderful
[14:22:53 CEST] <iive> are you writing your emails using telnet client?
[14:24:07 CEST] <av500> isnt everybody?
[14:25:25 CEST] <Compn> we should put a note on the contact page that we can do this so those people who dont like registering dont have to register ;P
[14:26:09 CEST] <Compn> because haasn isnt the first person to have this anti-registration opinion, and will not be the last. hey i dont like registering either :P
[14:31:11 CEST] <haasn> iive: I'm using a relatively young e-mail client, I've already submitted a feature request for mailto support
[14:31:44 CEST] <cone-444> ffmpeg 03wm4 07master:7dd8bf53bdb5: avformat: add common mechanism for skipping samples at the start of file
[14:31:45 CEST] <cone-444> ffmpeg 03wm4 07master:066b92e91d67: avformat/mp3dec: use the common mechanism for skipping samples
[14:41:24 CEST] <cone-444> ffmpeg 03wm4 07master:c3a73666ad1e: avformat/mp3dec: allow enabling generic seek mode
[15:28:56 CEST] <BBB> nevcairiel: yes
[15:29:28 CEST] <BBB> nevcairiel: if users have specific requests, they are free to contact me btw, Im cont(r)actable
[15:29:39 CEST] <Daemon404> BBB, surprising
[15:29:45 CEST] <Daemon404> many us companies have anti-moonlighting clauses
[15:29:48 CEST] <Daemon404> US*
[15:29:52 CEST] <BBB> I quit
[15:30:05 CEST] <BBB> I work for myself, Im just having random fun right now
[15:30:55 CEST] <Daemon404> o
[15:31:10 CEST] <Daemon404> thats fairly risky, given where you live, i would htink
[15:32:48 CEST] <BBB> ?
[15:33:18 CEST] <Daemon404> you dont have a guaranteed source of income
[15:33:22 CEST] <Daemon404> if contracting
[15:34:41 CEST] <BBB> well kinda late for that now I guess
[15:34:43 CEST] <BBB> I already quit
[15:34:45 CEST] <BBB> so...
[15:53:00 CEST] <vibr> kierank, the deadline's really close now, but i'd still like to finish the qualification task for outreachy
[15:54:36 CEST] <vibr> kierank, from looking at fate i understood that all test code is in fate-run.sh
[15:54:53 CEST] <vibr> there's no test code anywhere else, is that correct?
[15:55:26 CEST] <kierank> vibr: erm
[15:55:51 CEST] <kierank> deadline?
[15:56:09 CEST] <vibr> the deadline for finishing the qualification task
[15:56:16 CEST] <vibr> i thought it's this friday
[15:56:37 CEST] <kierank> where does it say that?
[15:56:57 CEST] <vibr> michaelni said 11 days ago that i had 1-2 weeks left
[15:57:08 CEST] <vibr> that would mean 3 days to go now
[15:57:47 CEST] <michaelni> 1-2 weeks meant i did not know exactly when the deadline is
[15:58:17 CEST] <michaelni> if you pass qualification we can still try to get a 2nd slot of course but we are technically too late
[15:59:09 CEST] <vibr> i see
[15:59:27 CEST] <michaelni> rather we WILL try not just can
[16:00:10 CEST] <vibr> that would be great
[16:00:44 CEST] <vibr> the outreachy website says the selections decision are posted next monday
[16:01:22 CEST] <vibr> that sounded like a hard deadline to me
[16:01:52 CEST] <vibr> anyway, may i ask some questions then, kierank?
[16:01:56 CEST] <kierank> yes
[16:02:02 CEST] <kierank> of course
[16:02:35 CEST] <vibr> is all test code inside fate-run.sh?
[16:03:21 CEST] <vibr> i understood that fate-run.sh calls ffmpeg to encode and decode <file> and then compares the output to the original <file>
[16:04:34 CEST] <kierank> yes
[16:04:34 CEST] <wm4> fate-run.sh can call various things
[16:04:39 CEST] <wm4> not only ffmpeg
[16:04:49 CEST] <kierank> it is one of the tthings as wm4 says
[16:05:42 CEST] <wm4> one of the arguments passed to fate-run.sh is the function that is run
[16:05:54 CEST] <wm4> like framecrc()
[16:06:09 CEST] <wm4> I don't completely understand the magic that calls fate-run-sh in the first place though
[16:06:25 CEST] <wm4> lots of makefile magic...
[16:06:46 CEST] <vibr> yes, it seems to be quite involved
[16:07:18 CEST] <vibr> can fate-run call API functions or even local functions?
[16:08:06 CEST] <kierank> no
[16:08:12 CEST] <kierank> it's a makefile/shell-script
[16:08:57 CEST] <vibr> that's why i thought it calls ffmpeg only
[16:09:19 CEST] <vibr> i can't find the definition of framecrc right now
[16:10:23 CEST] <wm4> there's a shell function in fate-run.sh, and there's a muxer in libavformat, which do you mean?
[16:11:36 CEST] <vibr> none ;)
[16:11:47 CEST] <vibr> so that's what you meant ;)
[16:14:11 CEST] <cone-444> ffmpeg 03wm4 07master:58fade2c6848: avformat/mp3dec: make generic index mode the default
[16:15:07 CEST] <vibr> so, kieranc, for the granularity of the tests: first i thought of writing a unit test for one of the functions in flacdec.c (because you pointed me to flac)
[16:15:42 CEST] <vibr> but i think you don't want that granularity, you want tests on the level of the API?
[16:15:58 CEST] <kierank> correct
[16:16:11 CEST] <kierank> it's worth saying a test has already been written for flac
[16:16:22 CEST] <vibr> where's that test?
[16:16:33 CEST] <kierank> libavcodec/api-test-flac iirc
[16:17:33 CEST] <vibr> it's new then?
[16:18:02 CEST] <michaelni> it would be best if each applicant writes a different qualification task so a diferent test would be better and more usefull than a 2nd flac test
[16:19:14 CEST] <vibr> yes, i think so
[16:19:51 CEST] <vibr> it says  Copyright (c) 2001 Fabrice Bellard and Copyright (c) 2015 Ludmila Glinskih
[16:20:11 CEST] <vibr> but it wasn't in my source code tree when i cloned it two weeks ago
[16:21:29 CEST] <gavinatkinson> michaelni: Around?
[16:24:38 CEST] <vibr> hm, so the API regression testing is assigned already?
[16:24:40 CEST] <reynaldo> gavinatkinson: hello
[16:24:49 CEST] <reynaldo> gavinatkinson: you from FreeBSD isnt it ?
[16:25:27 CEST] <reynaldo> Im ont of the peeps admining GSoC for the team
[16:25:32 CEST] <reynaldo> ont/one
[16:25:41 CEST] <reynaldo> will follow up privately if you dont mind
[16:27:45 CEST] <gavinatkinson> reynaldo: Ah, cool.
[16:29:09 CEST] <kierank> vibr: as far as I know there's no reason why two students couldn't work on the same task
[16:29:46 CEST] <vibr> ok
[16:29:57 CEST] <vibr> but what about the qualification task, then?
[16:32:37 CEST] <wm4> so we need a new one? there's enough API to test
[16:32:55 CEST] <kierank> h264 or another bitexact codec is easiest
[16:35:10 CEST] <vibr> But Camila Souto already wrote a test for h264?
[16:35:23 CEST] <kierank> she did?
[16:35:42 CEST] <vibr> it says so on the link posted above?
[16:35:43 CEST] <kierank> I see nothing on the ml
[16:35:53 CEST] <vibr> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2015-Qualis?version=52
[16:35:57 CEST] <kierank> vibr: it is what she *intended* to do
[16:36:02 CEST] <kierank> there has been no submission
[16:36:19 CEST] <kierank> note how the completed box is not ticked
[16:36:29 CEST] <vibr> oh, i see
[16:41:31 CEST] <vibr> do you want me to look at  api-flac-test.c or not? The qualification task is easier that way with a "template" which can be adapted
[16:42:44 CEST] <kierank> you can if you want or you can look at the examples
[16:42:50 CEST] <kierank> api-flac-test is based off the examples
[16:42:51 CEST] <vibr> ok
[16:43:05 CEST] <kierank> there's a difference though in that you won't be able to do the same encode -> decode test with h264
[16:43:18 CEST] <kierank> normal h264 is bitexact but not lossless
[16:46:22 CEST] <vibr> do i need to look at the standard for h264 then?
[16:47:08 CEST] <vibr> what's the definition of bitexact or where can i look it up?
[16:48:23 CEST] <kierank> no you don't need to look at the h264 standard
[16:48:49 CEST] <kierank> the definition of bitexact is that the implementation requires a bit for bit exact decode of a video
[16:48:54 CEST] <kierank> for other formats such as mpeg-2 this is not required
[16:50:29 CEST] <wm4> lossless means the output of the decoder is exactly the same as what you've put into the encoder
[16:50:40 CEST] <vibr> yes
[16:50:47 CEST] <wm4> bitexact means the output of the decoder can be different, but every decoder will output the same
[16:51:19 CEST] <wm4> and for something that is neither lossless nor bitexact, every decoder could output something slightly different from each other
[16:51:24 CEST] <wm4> (obviously bad for testing)
[16:52:16 CEST] <vibr> but there's only one decoder for h264, so i can't compare the output of differenct decoders?
[16:53:15 CEST] <kierank> vibr: correct, but there are crc's already in fate for various test h264 clips
[16:53:23 CEST] <kierank> so if they change then something has broke
[16:53:47 CEST] <vibr> ok
[16:54:17 CEST] <wm4> a decoder that's not bitexact could vary from platform to platform too
[16:55:02 CEST] <wm4> some decoders in ffmpeg can be made bitexact by setting a flag (skips platform specific optimizations that change the output, I think)
[16:55:12 CEST] <cone-444> ffmpeg 03Andreas Cadhalpun 07master:35e855d5b695: dss_sp: use lowercase codec name without whitespace
[16:57:42 CEST] <iive> mpeg1/2 are not bitexact because they allow different precision for (i)dct, 
[16:57:50 CEST] <BBB> vibr: in practice, such differences can happen when we implement things like idcts (for video) differently per platform for performance reasons. it also can happen for float (usually audio) based decoders. 
[16:58:01 CEST] <BBB> mpeg1/2 are indeed example of codecs where the idct isnt specified
[16:58:22 CEST] <BBB> prores is a more modern example where we dont know if the idct is specified and so it varies per platform
[16:58:27 CEST] <iive> because of this they can have a small number of P-frames and need frequent I-frames.
[16:58:37 CEST] <BBB> bitexact works around that so you get the same output on each platform
[16:59:13 CEST] <kierank> we'll find out soon about prores idct
[16:59:15 CEST] <iive> mpeg4-2 asp defines stricter parameters for (i)dct, this allows increasing the refresh interval.
[16:59:16 CEST] <kierank> it's getting standardised
[16:59:25 CEST] <kierank> https://kws.smpte.org/kws/public/projects/project/details?project_id=278
[16:59:30 CEST] <BBB> oh cool
[16:59:34 CEST] <kierank> soon by smpte standards is about 5 years
[16:59:38 CEST] <Daemon404> into the smpte dumping ground
[16:59:44 CEST] <BBB> :)
[16:59:59 CEST] <Daemon404> i still wanna do vc-5.
[17:00:01 CEST] <Daemon404> but im not paying $300.
[17:00:02 CEST] <kierank> I doubt the spec will be any good
[17:00:07 CEST] <kierank> Daemon404: you missed the guy who was working on it
[17:00:10 CEST] <kierank> he said the spec was crap
[17:00:14 CEST] <Daemon404> rofl
[17:00:25 CEST] <kierank> it was good for lossy but useless for lossless
[17:00:38 CEST] <Daemon404> what was it lacking?
[17:00:44 CEST] <Daemon404> precise dwt?
[17:00:53 CEST] <kierank> apparently lossless was just a footnote
[17:01:59 CEST] <vibr> kierank, the test h264 clips are in the fate-suite/h264* dirs, where are the crcs?
[17:02:48 CEST] <kierank> http://git.videolan.org/?p=ffmpeg.git;a=tree;f=tests/ref/fate;h=3c25ec16d76bb1d0a0d67378212d5cee8aa6fd83;hb=HEAD
[17:03:19 CEST] <vibr> thanks!
[17:30:39 CEST] <wm4> is is there a reason why the test programs are part of the libavcodec/libavformat/etc. directories?
[17:31:35 CEST] <kierank> because for some reason there was a rush to commit the code
[17:31:49 CEST] <kierank> I have asked lglinskih to work on moving them to the correct place
[17:31:53 CEST] <Daemon404> to meet deadlines apparently
[17:39:38 CEST] <cone-444> ffmpeg 03Andreas Cadhalpun 07master:b3408ae4c64c: mpeg4videodec: only allow a positive length
[17:41:47 CEST] <wm4> right, the deadline was some hours away or something
[17:42:00 CEST] <wm4> anyway, there are older test programs that do this
[17:42:40 CEST] <nevcairiel> why does the deadline require that its commited, do they really say "it has to be commited to the main code base" in their requirements? I highly doubt that, as many more serious projects have extremely strict requirements for that
[17:45:35 CEST] <BtbN> int diff_r = r - ctx->colorkey_rgba[0]; With r and colorkey_rgba[0] both beeing uint8_t, will the result still be int, so 100-200 will be -100, and not 155?
[17:46:23 CEST] <nevcairiel> its likely doing the calc in the types that the vars are in
[17:46:44 CEST] <BtbN> I remember there beeing some thing about C where it does all calculations as ints
[17:47:20 CEST] <wm4> nevcairiel: true
[17:47:37 CEST] <nevcairiel> https://ideone.com/mfBlB7
[17:47:40 CEST] <nevcairiel> this says it works
[17:47:41 CEST] Action: nevcairiel shrugs
[17:48:25 CEST] <wm4> uint8_t is promoted to int
[17:48:26 CEST] <wm4> I think
[17:48:27 CEST] <nevcairiel> no guarantees it didnt optimize out my example :p
[17:53:28 CEST] <kierank> 4:41 PM <"wm4> right, the deadline was some hours away or something --> the deadline said nothing about committing
[17:53:36 CEST] <BtbN> Why is ff_sqrt in libavcodec/mathops.h?
[17:54:14 CEST] <kierank> https://lists.libav.org/pipermail/libav-devel/2012-October/037115.html
[17:54:15 CEST] <kierank> of course
[17:54:19 CEST] <kierank> need to play the libav shuffle
[17:54:32 CEST] <lglinskih> wm4: It was the simplest way to integrate it into FATE. At first I wanted to put it in tests/api directory! But it's not easy=/ I still don't understand all makefile-magic 
[17:55:06 CEST] <BtbN> And can i still use that in a filter? Seeing that even libavutils includes that header.
[17:55:10 CEST] <nevcairiel> loading data tables from other shared libraries is somewhat annoying re: portability, so i dont mind moving those things to the place they are actually used
[17:57:27 CEST] <kierank> nevcairiel: how come?
[17:57:28 CEST] <cone-444> ffmpeg 03Ludmila Glinskih 07master:5adee9c0af74: api-flac-test: Coding style
[17:57:29 CEST] <kierank> is it a windows thing?
[17:57:45 CEST] <nevcairiel> yes
[17:57:59 CEST] <ubitux> http://pastie.org/pastes/10107660/text funny the AES-128 bench& i wonder if gcrypt is correct
[17:58:00 CEST] <kierank> ah yes I remember actually
[17:58:34 CEST] <kierank> ubitux: aes-ni?
[17:58:58 CEST] <Daemon404> i am frankly surprised libav* doesnt manually implement ssl
[17:59:20 CEST] <nevcairiel> i'm still refusing to bundle openssl or gnutls or something, i'm still waiting for the native!
[17:59:21 CEST] <nevcairiel> :D
[17:59:37 CEST] <wm4> Daemon404: did those curl plans for a SSL abstraction/wrapper lib go somewhere?
[18:00:05 CEST] <nevcairiel> i should just take some pain killers and write a SChannel implementation
[18:00:07 CEST] <Daemon404> wm4, yes
[18:00:14 CEST] <Daemon404> they killed it
[18:00:16 CEST] <Daemon404> it went to death
[18:01:43 CEST] <wm4> sad
[18:01:53 CEST] <BtbN> This is kinda strange, why the hell is something basic as ff_sqrt in avcodec...
[18:02:27 CEST] <Daemon404> because of ricing
[18:02:28 CEST] <BBB> BtbN: no use outside avcodec yet
[18:02:29 CEST] <nevcairiel> because it was used there, and only there?
[18:02:48 CEST] <BtbN> BBB, well, there is at least one pice of code in libavutils that uses it, which is kinda strange.
[18:03:03 CEST] <BBB> then we should move it into avutil
[18:03:18 CEST] <Daemon404> the whole reason it was like this is cause of ricing: OMG FUNCTION CALL OVERHEAD
[18:03:24 CEST] <Daemon404> and sharing tables between libs is derp
[18:03:27 CEST] <BBB> what do I do if a decode to yuv yields identical results but a decode to md5 gives different results between two decoders?
[18:03:30 CEST] <BtbN> It's an inline in a header...?
[18:03:46 CEST] <Daemon404> BtbN, i seem to rememebr it beign a LUT, i may be wrong
[18:03:46 CEST] <BBB> BtbN: sharing tables between libs is derp
[18:03:59 CEST] <BBB> see the mess we got in with pixfmtinfo
[18:04:10 CEST] <nevcairiel> its a bit weird, fixed_sqrt uses ff_sqrt .. fixed_sqrt is a inline function, which in turn is only ever used from avcodec
[18:04:36 CEST] <Daemon404> why do we need our own sqrt btw?
[18:04:41 CEST] <BBB> Daemon404: int
[18:04:43 CEST] <BBB> not float
[18:04:48 CEST] <nevcairiel> but fixed_sqrt is part of the fixed point stuff contributed by the crazy mips people
[18:05:00 CEST] <wm4> ac3dec uses it
[18:05:23 CEST] <BBB> is there a flag to tell avformat to ignore timestamps?
[18:05:30 CEST] <BBB> like, -vsync 0, but also works in muxers
[18:05:36 CEST] <wm4> BBB: what context?
[18:05:38 CEST] <nevcairiel> littering all our pretty decoders with special conditions for fixed point decoding
[18:05:49 CEST] <BBB> [yuv4mpegpipe @ 0x7fdad9849c00] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 6 >= 6
[18:05:49 CEST] <BBB> av_interleaved_write_frame(): Invalid argument
[18:05:53 CEST] <BBB> I get that when I use -vsync 0
[18:06:15 CEST] <Daemon404> i dont know what else you expect when passing ts through
[18:06:30 CEST] <Daemon404> eitehr you fix timestamps or you pass them through
[18:06:40 CEST] <Daemon404> i dont know why there would be a "make up timestamps" option for muxing
[18:08:40 CEST] <BBB> I just want to write yuv frames as they come
[18:08:45 CEST] <BBB> my yuv file has no timestamps
[18:08:52 CEST] <BBB> I dont want it to touch anything
[18:08:54 CEST] <BBB> just write it
[18:09:37 CEST] <nevcairiel> y4m muxer should probably set the no-timestamps flag, then you are happy
[18:11:07 CEST] <nevcairiel> its not using the timestamps anyway
[18:12:10 CEST] <Daemon404> y4m has a "framerate"
[18:12:24 CEST] <nevcairiel> but not timestamps
[18:12:31 CEST] <nevcairiel> so its pointless to complain about them
[18:13:41 CEST] <Daemon404> i know
[18:14:13 CEST] <nevcairiel> gcc 5.1 was officially released today btw
[18:14:26 CEST] <wm4> huh, so I missed 5.0 being released?
[18:14:42 CEST] <nevcairiel> they changed their versioning
[18:14:54 CEST] <nevcairiel> they are using chrome versioning now, 5, 6, 7, 8 .. etc
[18:15:03 CEST] <BtbN> And they break the C++ abi, which is a lot of fun for everyone.
[18:15:04 CEST] <nevcairiel> 5.0.1 was pre-release, 5.1 is first stable
[18:15:38 CEST] <Daemon404> in practice you shouldnt be relying on c++ ABI
[18:15:43 CEST] Action: Daemon404 stares at avisynth
[18:15:52 CEST] <nevcairiel> BtbN: thats probably more C++'s fault than GNUs fault
[18:16:15 CEST] <BtbN> hm? It's the fault of whoever implements libstdc++, which is made by the gcc guys
[18:16:44 CEST] <BtbN> They could have at least bumped the soname
[18:16:48 CEST] <BtbN> And keep the old one for compat
[18:17:46 CEST] <nevcairiel> this claims that old apps should continue to work, and only things build against new headers use the new ABI https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
[18:18:09 CEST] <nevcairiel> (plus a define to defeat the new ABI)
[18:18:16 CEST] <BtbN> Yes, it continues to work as long as absolutely everything is build using the same abi.
[18:18:25 CEST] <Daemon404> well... they should have bumped the soname
[18:18:29 CEST] <Daemon404> thats kinda what sonames are for
[18:18:43 CEST] <BtbN> A single lib or binary using a diffrent abi, and it explodes.
[18:18:48 CEST] <Daemon404> it's worth noting that glibc does the exact same thing
[18:18:53 CEST] <Daemon404> (and everyone LOVES glibc)
[18:19:04 CEST] <BtbN> glibc at least has propper backwards compat.
[18:19:44 CEST] <wm4> glibs makes application reference all sort of crazy symbols
[18:19:45 CEST] <BtbN> a binard built against an old one will allways continue to work. Even when mixed with binaries using more recent features.
[18:20:05 CEST] <wm4> and contributed to the impression that you can't reasonably deploy binaries on Linux
[18:20:26 CEST] <BtbN> Not without staticaly linking in the libc at least.
[18:21:22 CEST] <wm4> ^ or this impression
[18:22:25 CEST] <BtbN> The windows solution of having a ton if diffrent libcs isn't much better though.
[18:23:53 CEST] <Daemon404> BtbN, you cant REALLY statically link glibc
[18:23:58 CEST] <Daemon404> same sort of issues
[18:24:14 CEST] <BtbN> you get at least rid of most symbol crazyness that way
[18:24:16 CEST] <Daemon404> and you can link msvcrt statically
[18:25:38 CEST] <wm4> the old maintainer of glibc hated static linking
[18:25:44 CEST] <wm4> and made it as bad as possible
[18:26:50 CEST] <Daemon404> he hated everything
[18:27:00 CEST] <Daemon404> he is the definition of asshat
[18:27:52 CEST] <BtbN> Wasn't he also the one that purposfully left a /bin/sh shebang in files that were clearly using bash-only features?
[18:29:09 CEST] <wm4> BtbN: at least this sounds like something he'd do
[18:30:13 CEST] <BtbN> Forced a few distributions that weren't using bash as /bin/sh to patch a bunch of glibc scripts.
[18:31:11 CEST] <Daemon404> BtbN, almost as annoying as #!/bin/bash
[18:31:18 CEST] <Daemon404> (bash does *not* belong in /bin)
[18:31:42 CEST] <BtbN> That's way to established to change it though
[18:31:58 CEST] <BBB> you guys need to get a job
[18:32:05 CEST] <BBB> like, one where you need to sit down and get work done
[18:32:18 CEST] <BBB> seriously, if the most important thing you can do in your life is to debate whether bash belongs in /bin...
[18:32:20 CEST] <Daemon404> BtbN, its 5:30pm here.
[18:32:23 CEST] <Daemon404> er BBB
[18:32:43 CEST] <Daemon404> also you couldnt really sound like more of a douche if you tried ther.e
[18:32:48 CEST] <BtbN> An entire new init system was born over the debate where stuff belongs.
[18:33:20 CEST] <wm4> systemd got it wrong though
[18:33:30 CEST] <wm4> they made /usr/bin the "official" place for no reason
[18:33:39 CEST] <wm4> it should have been /bin, because /usr is bullshit
[18:34:05 CEST] <Daemon404> my last job actually did care about /usr/bin vs /bin
[18:34:13 CEST] <Daemon404> since embedded land may not have /usr mounted at init time.
[18:37:33 CEST] <BtbN> systemd solved that by making a mounted /usr a requirement...
[18:37:48 CEST] <Daemon404> i dont know of any embedded linux stuff using systemd
[18:37:50 CEST] <Daemon404> full stop
[18:37:59 CEST] <wm4> there's a phone using systemd
[18:38:02 CEST] <wm4> was it jolla
[18:38:21 CEST] <Daemon404> ubuntu phone maybe?
[18:38:28 CEST] <wm4> whatever lachs0r has
[18:38:35 CEST] <Daemon404> jolla
[18:38:43 CEST] <Daemon404> the once the MUH FREEDUMS people like
[18:38:45 CEST] <wm4> they run systemd
[18:39:22 CEST] <BBB> another one thats fun
[18:39:44 CEST] <BBB> what if I have a scalable sequence
[18:39:48 CEST] <wm4> (it also runs btrfs, which dies when it's out of space... I wonder how that interacts with journald lol)
[18:39:59 CEST] <BBB> and for whatever reason, AVCodecContext.width/height is different between two decoders
[18:40:07 CEST] <BBB> (on init)
[18:40:14 CEST] <BBB> but is identical once the decoding starts
[18:40:36 CEST] <BBB> framemd5 wont work now, since muxing/encoding AVCodecContext.width/height is copied upon init
[18:40:59 CEST] <BBB> so even if decodes are identical between two decoders, encoding will look different because scaling touched it
[18:41:06 CEST] <BBB> how can I tell ffmpeg to not resize?
[18:41:28 CEST] <BBB> as in, quite literally, do not touch my frames which you send to the encoder
[18:41:42 CEST] <BBB> (where encoder is rawenc and muxer is framemd5)
[19:00:04 CEST] <wm4> michaelni: so do you want a separate CBR-mode mp3 seek test?
[19:12:20 CEST] <michaelni> wm4, sounds like a good idea
[19:13:23 CEST] <wm4> ok, I only need to find out how to pass extra arguments for a seek-test call (to enable CBR-mode seeking)
[19:38:36 CEST] <wm4> are the fate-seek-lavf tests dead?
[19:39:11 CEST] <cone-444> ffmpeg 03wm4 07master:53ff9a4ec9ce: fate: gapless: remove useless tests
[19:45:44 CEST] <jamrial> dead how?
[19:46:09 CEST] <wm4> not called by "make fate" or "make fate-seek"
[19:46:22 CEST] <wm4> and manually calling them doesn't seem to work either
[19:46:48 CEST] <jamrial> make fate-seek does call them
[19:46:52 CEST] <jamrial> just tried
[19:47:07 CEST] <wm4> not here
[19:47:57 CEST] <jamrial> from seek.mak : "FATE_SEEK += $(FATE_SEEK_LAVF-yes:%=fate-seek-lavf-%)" "fate-seek:     $(FATE_SEEK)"
[19:48:17 CEST] <jamrial> something must be wrong on your end
[19:48:29 CEST] <wm4> ah, 'Im stupid
[19:48:35 CEST] <wm4> I accidentally removed this line
[19:48:46 CEST] <wm4> sorry
[20:23:25 CEST] <BtbN> Is calling av_frame_make_writable the same as what writing_filters.txt suggests in line 238+?
[20:25:43 CEST] <ubitux> > [FFmpeg-user] Merging animated gif and mp3
[20:25:44 CEST] <ubitux> it begins.
[20:26:31 CEST] <nevcairiel> BtbN: make_writable is writeing_filters 250+, ie. in-place processing
[20:26:58 CEST] <BtbN> nevcairiel, yes, but i don't see it making any difference if all i'm processing is packed RGBA?
[20:27:11 CEST] <BtbN> As i will have to copy the entire buffer anyway if the frame isn't writable
[20:27:22 CEST] <nevcairiel> but it might be writable
[20:27:36 CEST] <BtbN> in that case make_writable just won't do anything
[20:27:37 CEST] <sfan5> ubitux: i tried putting apng, ac3 and ssa into a container the other day; didn't work out
[20:28:18 CEST] <nevcairiel> BtbN: indeed, but if you do in-place processing, then you should call make_writable, since it may or may not be writable, its a no-op when not needed
[20:28:34 CEST] <wm4> <ubitux> > [FFmpeg-user] Merging animated gif and mp3
[20:28:37 CEST] <BtbN> yeah, i can see a difference for YUVA, where alpha is in its own plane.
[20:28:40 CEST] <wm4> use uncompressed rar as container?
[20:29:02 CEST] <ubitux> yeah
[20:29:06 CEST] <BtbN> nevcairiel, yes, i meant make_writable vs. the manual approach of individual buffers.
[20:29:20 CEST] <nevcairiel> individual buffers are only needed if you cannot do in-place processing
[20:29:44 CEST] <nevcairiel> ie. you need input from surrounding pixels, which in-place doesnt easily do since it overwrites the original ones =p
[20:30:15 CEST] <BtbN> Yes, but for YUVA, if the input is not writable, I'd only need to allocate a new alpha buffer.
[20:30:28 CEST] <BtbN> Wouldn't even have to copy it, as i generate an entirely new one anyway.
[20:31:21 CEST] <BtbN> But currently, my RGB based colorkey is doing a better job for a greenscreen than yuv based chromakey... :D
[20:31:24 CEST] <cone-444> ffmpeg 03Mate Sebok 07master:4d98015dcf65: dshow: add capture device save and load
[20:31:25 CEST] <cone-444> ffmpeg 03Andreas Cadhalpun 07master:86d00ede4f9a: bink: check vst->index_entries before using it
[20:31:28 CEST] <nevcairiel> i dont think you can keep the references to the same YUV planes and only allocate a new A plane, dont think frames are designed to work like that
[20:31:59 CEST] <kierank> I think it's possible to do with buffer referencing
[20:32:02 CEST] <kierank> but it's not a good idea
[20:32:06 CEST] <kierank> well it is
[20:32:09 CEST] <kierank> but it won't work within ffmpeg
[20:32:19 CEST] <kierank> I have the same problem with chroma conversions and luma memcpy
[20:32:58 CEST] <wm4> nevcairiel: uh, actually... even libavfilter plays tricks with separate buffers/planes
[20:33:02 CEST] <wm4> I forgot which filter
[20:33:18 CEST] <nevcairiel> wm4: and if people actually used avfilter, it would probably blow up :D
[20:34:10 CEST] <nevcairiel> in other news, why does every article about a simple audio low-pass filter assume you majored in signal processing
[20:34:28 CEST] <BtbN> I'm also thinking the same about chromakey algorithms...
[20:34:39 CEST] <BtbN> I just can't find anything that's not written like a scientific paper
[20:34:59 CEST] <BtbN> The plain stupid RGB approach doesn't work propperly for YUV
[20:36:43 CEST] <nevcairiel> I really do not want to use the avfilter biquads filter for this, so I figured, can't be too hard to figure out, but meh!
[20:36:44 CEST] <wm4> ah, it was vf_pad which does the crazy stuff
[20:37:20 CEST] <wm4> it makes quite a lot of low level decisions how the referenced buffers work
[20:37:36 CEST] <wm4> so you can crop a frame and then pad it again, without having to copy the frame
[20:37:38 CEST] <wm4> (useful huh)
[20:37:47 CEST] <nevcairiel> and it gets away with it because only ffmpeg.c uses it :D
[20:41:40 CEST] <BtbN> I wonder if me just adding a fourth buffer to the frame is ok, for the alpha data, in case it doesn't already exist.
[20:42:20 CEST] <BtbN> I'm also not sure how to communicate the output format, as it depends on the input format.
[20:47:12 CEST] <jamrial> so cinepak encoder has 0% coverage. adding a couple vsynth tests is trivial, but it's so painfully slow that i wonder if it's worth adding them
[20:47:41 CEST] <wm4> why is there a cinepak encoder?
[20:48:00 CEST] <jamrial> because someone wrote it, i guess :p
[20:48:57 CEST] <michaelni> a test with 2-3 frames of low resolution is too slow too ?
[20:51:05 CEST] <jamrial> oh right, passing -vframes 3 or so
[20:51:56 CEST] <jamrial> yeah, it's "fast" that way. i'll send a patch later
[20:57:39 CEST] <Compn> wonder how many companies have sent michaelni some hardware for testing :D
[20:57:51 CEST] <Compn> wonder if michael has enough room for all of these computers in his place :D
[21:01:23 CEST] <BtbN> Most companies are quite happy to send hardware samples.
[21:02:17 CEST] <BtbN> Sending hardware to some developer means there most likely will be software making use of it, which ultimately leads to more users.
[21:13:54 CEST] <BBB> I do wonder about these toy encoders
[21:14:01 CEST] <BBB> I mean, cinepak...
[21:14:37 CEST] <wm4> as usual ffmpeg will keep it because ffmpeg never removes anything
[21:16:06 CEST] <llogan> you want to save 67K
[21:17:04 CEST] <wm4> and potentially a lot of time needed for maintenance
[21:17:31 CEST] <BBB> was this one of mikes toy projects?
[21:17:35 CEST] <BBB> (melanson)
[21:17:58 CEST] <jamrial> the c file mentions Tomas Härdin
[21:18:29 CEST] <BBB> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-January/153472.html ?
[21:18:31 CEST] <BBB> Rl
[21:19:00 CEST] <BBB> oh he sent the email
[21:19:06 CEST] <BBB> it was written by tomas, yes
[21:21:18 CEST] <jamrial> Aetey is the maintainer, though
[21:48:10 CEST] <cone-444> ffmpeg 03Ronald S. Bultje 07master:d02d04a18f30: vp9: remove one optimization branch in iadst16 which causes overflows.
[21:48:40 CEST] <jamrial> :(
[21:51:59 CEST] <jamrial> fortunately this comes after you wrote the sse2 version
[21:55:31 CEST] <BBB> (did my response to you ever made it here before I got disconnected, jamrial?)
[21:55:38 CEST] <jamrial> no
[21:58:58 CEST] <BBB> hm
[21:59:40 CEST] <BBB> I said fortunately it only requires to swap some mulhrsw with slightly more expensive sets of pmaddwd instructions
[21:59:49 CEST] <BBB> so kinda sad, but not the end of the world
[22:00:35 CEST] <jamrial> yeah
[22:01:13 CEST] <BBB> I still have bugs in vp90-2-15-segkey_adpq.webm and vp90-2-16-intra-only.webm
[22:01:20 CEST] <BBB> and of course profile 1 and 2 are missing
[22:08:08 CEST] <BtbN> Great, something seems to be causing random memory corruption.
[22:08:21 CEST] <BBB> asan, valgrind!
[22:09:05 CEST] <BtbN> At least the avctx->priv address changes between config_props of my output pin and filter_frame.
[22:09:11 CEST] <BtbN> And i don't think it is supposed to do that.
[22:09:33 CEST] <BtbN> The random crashes i get also clearly indicate memory corruption.
[23:31:42 CEST] <cone-444> ffmpeg 03wm4 07master:748d4816d92c: avformat: add AVFMT_FLAG_FASTSEEK, use it for mp3
[23:51:22 CEST] <cone-444> ffmpeg 03Tucker DiNapoli 07master:6264b6227c77: postproc: Replaced inline asm for prefetching with prefetch functions
[00:00:00 CEST] --- Thu Apr 23 2015