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

[burek]

[00:14:49 CET] <jkqxz> Is there a way to complain to Coverity that their software has done something stupid?
[00:15:08 CET] <JEEB> I would guess they have some sort of support thing
[00:15:29 CET] <jkqxz> "Assigning: crop_unit_x = 1 + (sps->chroma_format_idc < 3). The value of crop_unit_x is now 0."  Er, no.  That's not how < works.
[00:16:05 CET] <JEEB> :D
[00:16:15 CET] <JEEB> 1 + 0|1 is somehow 0
[00:16:17 CET] <JEEB> <3
[00:17:56 CET] <cone-675> ffmpeg 03Mark Thompson 07master:1c49365c62f4: h264_metadata: Fix memory leak on multiple display orientation messages
[01:11:16 CET] <cone-675> ffmpeg 03Carl Eugen Hoyos 07master:cbbefc05b1b8: lavfi/deshake: Check alignment before calling asm init function.
[01:58:35 CET] <Chloe> Compn: ping
[02:37:50 CET] <cone-675> ffmpeg 03James Almer 07master:e4eaaf7bf693: avcodec/vp9_superframe_split: move the reference in the bsf internal buffer
[03:05:54 CET] <Compn> Chloe : pong
[04:09:10 CET] Action: Compn plays pingpong and goes sleep
[07:32:17 CET] <gagandeep> guys i am looking at avframe with 12 bit per channel rgba, so why is avframe data able to accept numbers greater that (1 << 12) - 1
[07:45:28 CET] <gagandeep> kierank: i have solved the alpha bug , yay :D
[10:41:40 CET] <gagandeep__> guys how do i test using fate?
[10:47:00 CET] <gagandeep__> kierank: can i now try and write a proposal for gsoc?
[10:52:46 CET] <durandal_1707> gagandeep__: you should do it already
[12:10:56 CET] <gagandeep_> kierank: yeah, the png output from ffmpeg is not correct, but ffplay is working correctly
[12:11:09 CET] <kierank> ?
[12:11:14 CET] <kierank> so you haven't fixed the bug
[12:11:31 CET] <gagandeep_> ffplay is displaying the output correctly now
[12:11:42 CET] <gagandeep_> so why ffmpeg transcode to png is bugged
[12:11:53 CET] <durandal_1707> gagandeep_: you are not making sense
[12:12:54 CET] <kierank> gagandeep_: the bug report explains exactly the issue
[12:13:12 CET] <gagandeep_> after compiling, running ./ffplay <sample> it has correct transparency
[12:13:21 CET] <durandal_1707> to look alpha with ffplay/ffmpeg use -vf extractplanes=a
[12:14:11 CET] <kierank> durandal_1707: why not just use the command in the ticket https://trac.ffmpeg.org/ticket/6265
[12:15:34 CET] <kierank> gagandeep_: i'm pretty sure the companding curve needs changing
[12:15:37 CET] <kierank> for alpha
[12:15:38 CET] <durandal_1707> kierank: yes, but ffplay does not display alpha ever i think, so use something like mpv
[12:15:53 CET] <kierank> durandal_1707: the command in ticket outputs to png
[12:15:54 CET] <kierank> doesn't use ffplay
[12:16:33 CET] <durandal_1707> yes, but how do you watch pngs?
[12:17:01 CET] <kierank> the ticket has an example of how it's meant to look
[12:17:07 CET] <gagandeep_> https://imgur.com/a/8IicP
[12:17:18 CET] <gagandeep_> the first image is the screenshot of ffplay
[12:17:24 CET] <gagandeep_> second is transcode
[12:17:57 CET] <kierank> I don't think you are doing test correctly, right durandal_1707?
[12:19:46 CET] <durandal_1707> gagandeep_: i see black there or right, and that is meant to be transparent
[12:21:31 CET] <durandal_1707> gagandeep_: ffmpeg currently decodes alpha little off, so use mpv.io and you will see
[12:24:34 CET] <gagandeep> i have also posted the alpha that i am getting from ffplay (screenshot) and ffmpeg transcode to png
[12:24:52 CET] <gagandeep> got disconnected right now
[12:25:02 CET] <durandal_1707> gagandeep: i see with mpv that alpha is wrong with or without your patch
[12:25:34 CET] <durandal_1707> we ought by default disable ffplay building
[12:26:07 CET] <gagandeep> what is ffplay building?
[12:26:12 CET] <durandal_1707> yours just add more alpha to the left
[12:26:55 CET] <durandal_1707> gagandeep: i mean, to disable building of ffplay program
[12:28:03 CET] <gagandeep> so why is ffplay outputing alpha transparency
[12:28:44 CET] <gagandeep> durandal_1707: please see the link i posted, i have placed results of extractplanes=a
[12:30:59 CET] <durandal_1707> gagandeep: where?
[12:32:19 CET] <gagandeep> https://imgur.com/a/8IicP
[12:34:24 CET] <gagandeep> kierank: https://pastebin.com/Mph9hZSU
[12:34:32 CET] <gagandeep> see line 131
[12:35:07 CET] <durandal_1707> gagandeep: as you can see alpha plane is not uniform, there is big black block on the left
[12:36:09 CET] <gagandeep> that is ffmpeg, but why is ffplay has uniform output
[12:36:55 CET] <kierank> ffplay doesn't support alpha, he said
[12:37:27 CET] <durandal_1707> gagandeep: ffplay just ignores alpha
[12:37:51 CET] <gagandeep> ok, so kierank, did you see the line i pointed you to?
[12:38:52 CET] <kierank> gagandeep: ffmpeg gsoc is about fixing bugs not copy and paste
[12:40:37 CET] <durandal_1707> gagandeep: that functions just converts colorspaces
[12:40:51 CET] <kierank> durandal_1707: it has some code to do alpha processing
[12:41:41 CET] <gagandeep> kierank: is that not companding, though i don't know the technical meaning?
[12:41:47 CET] <kierank> gagandeep: you haven't even copy and pasted correctly
[12:41:55 CET] <kierank> where is if(a > 0 && a < (255<<4))
[12:43:16 CET] <kierank> why are you doing the exact inverse?
[12:43:39 CET] <kierank> actually this looks like the encoder
[12:44:18 CET] <gagandeep> yeah, i revesed the steps to decode the alpha
[12:44:33 CET] <gagandeep> i haven't 'copy and pasted'
[12:45:07 CET] <kierank> there must be code in the decoder to do it
[12:46:55 CET] <durandal_1707> mpv ~/cineform_rgba_12b.mov -vf oscilloscope=c=15
[12:47:56 CET] <durandal_1707> why they done this?
[12:48:24 CET] <kierank> durandal_1707: they have some trickery to make sure 0 and 1 alpha not quantised
[12:50:46 CET] <kierank> afk
[13:07:17 CET] <gagandeep> durandal_1707: https://imgur.com/a/yEdmH, this is the output for ffmpeg i am getting now
[13:07:38 CET] <gagandeep> i was just not taking care of a bit of overflow after the alpha processing
[13:07:59 CET] <gagandeep> otherwise tell me how to post results for you guys to see
[13:08:45 CET] <gagandeep> and i want to send the changes to code, so should i send the diff in the mail as reply
[13:08:54 CET] <Chloe> gagandeep: durandal_1707 and kierank arent here to debug your every issue and do it for you. There is a reason there is a bounty on it
[13:09:50 CET] <gagandeep> chloe: i want to send the patch updates i made, so where should i send it
[13:10:02 CET] <gagandeep> should i make a new patch with both commits combined
[13:10:25 CET] <durandal_1707> gagandeep: post changes against master to same ml as reply and as attachment to your last mail
[13:10:41 CET] <Chloe> Just make a github repo
[13:10:54 CET] <Chloe> No need to send every minor update to the ML
[13:11:30 CET] <gagandeep> ok, thanks durandal_1707
[13:11:42 CET] <durandal_1707> Chloe: this is for qualification, so better to send to ML immediatelly
[13:13:15 CET] <Chloe> durandal_1707: for doing this task as gsoc?
[13:13:32 CET] <kierank> Chloe: there is a videolan bounty for cineform
[13:13:37 CET] <kierank> because there are so many features
[13:13:39 CET] <kierank> and code is quite complex
[13:14:20 CET] <Chloe> kierank: yes, I had planned on looking at it
[13:16:24 CET] <durandal_1707> i gonna start working on ecoder very soon
[13:16:56 CET] <gagandeep> i have commited to master and sent the format patch output as reply to my mail
[13:17:18 CET] <durandal_1707> gagandeep: you keep sending patches against previous patches
[13:17:48 CET] <durandal_1707> gagandeep: rebase and squash all single functional additions into single commit
[13:20:07 CET] <gagandeep> yup doing that now, this was what i was asking :), i am really sorry to waste all you guys precious time
[13:29:17 CET] <durandal_1707> gagandeep: spaces between if and (
[13:29:31 CET] <durandal_1707> gagandeep: spaces between ) and {
[13:29:43 CET] <durandal_1707> just one space!
[13:34:10 CET] <gagandeep> durandal_1707: are you able to test the output, and how do i add the space without sending another mail
[13:34:52 CET] <gagandeep> should i send a patch with the necessary cosmetic changes?
[13:35:14 CET] <durandal_1707> gagandeep: do it locally and pastebin it to me
[13:35:32 CET] <durandal_1707> gagandeep: i think you still need this: if(a > 0 && a < (255<<4))
[13:36:46 CET] <gagandeep> https://pastebin.com/GVf7uwtd
[13:37:07 CET] <gagandeep> no the code is for encoder, i am inversing the steps, not copy and pasting
[13:37:33 CET] <gagandeep> you can check the output atleast with the sample given in the bug tracker
[13:38:11 CET] <durandal_1707> gagandeep: yes and i checked, you can too just use -vf oscilloscope=c=15 and you will see interesting stuff
[13:39:22 CET] <durandal_1707> gagandeep: also, just learn to use av_clip_uintp2(X, 12);
[13:39:32 CET] <durandal_1707> instead of FFMIN/FFMAX combo
[13:40:58 CET] <gagandeep> yeah, but now according to you is the output not satisfactory
[13:42:14 CET] <durandal_1707> gagandeep: let me try something
[13:46:41 CET] <durandal_1707> gagandeep: i dunno why AE export have max alpha noticeable lower that your output
[13:46:54 CET] <durandal_1707> s/that/than
[13:51:01 CET] <gagandeep> durandal_1707: is max 4080
[13:52:17 CET] <durandal_1707> gagandeep: yes
[13:53:32 CET] <durandal_1707> output looks fine anyway
[13:54:12 CET] <gagandeep> i think this is caused by that if ( a < 255 << 4)
[13:54:54 CET] <durandal_1707> i doubt so, can you get output from testcfhd?
[13:55:34 CET] <gagandeep> output from test cfhd is the same as i am getting, as i can't get exact numbers from it
[13:55:41 CET] <gagandeep> visually it is same
[13:55:57 CET] <durandal_1707> cant you get it to output file?
[13:56:21 CET] <gagandeep> means, what kind of output?
[13:56:36 CET] <gagandeep> visual output is similar, and it outputs to ppm
[13:56:44 CET] <gagandeep> does ppm even have alpha?
[13:57:03 CET] <gagandeep> let me post the output for you to see
[13:57:28 CET] <durandal_1707> pam does have
[13:57:35 CET] <durandal_1707> ppm does not afaik
[13:57:57 CET] <gagandeep> i cant post the file so i will post the screenshot
[13:58:17 CET] <gagandeep> the file is not getting accepted at imgur
[13:59:04 CET] <gagandeep> https://imgur.com/a/mCb4E
[14:02:11 CET] <gagandeep> durandal_1707: as a patch is this acceptable?
[14:03:51 CET] <gagandeep> durandal_1707: we can always keep max (overflow) as 4080 ;)
[14:04:30 CET] <durandal_1707> gagandeep: how you get it to output ppm?
[14:05:15 CET] <gagandeep> you have to enable a macro #EXPORT_PPM in testcfhd or in utils.c
[14:05:34 CET] <gagandeep> yup, was a pain in the (you know)
[14:07:37 CET] <gagandeep> ctrl + f export_ppm or a combination
[14:08:25 CET] <gagandeep> also you will have to disable the extra outputs in testcfhd to reduce the type of outputs it generates
[14:10:28 CET] <gagandeep> durandal_1707: check TestResolution[] and TestDecodeOnlyPixelFormat[] with ctrl + f
[14:15:21 CET] <gagandeep> durandal_1707: any thoughts
[14:15:53 CET] <durandal_1707> gagandeep: writing PAM export into testcfhd
[14:31:18 CET] <thardin> is opencv really dropping its C API?
[14:31:37 CET] <thardin> that seems incredibly stupid
[14:32:03 CET] <nevcairiel> they are
[14:32:17 CET] <nevcairiel> has been for a while too, the 3.x line never officially supported it
[14:32:21 CET] <nevcairiel> it still kinda worked barely
[14:32:25 CET] <atomnuker> they deprecated it years ago, yeah
[14:32:28 CET] <nevcairiel> but apparently not any longer
[14:35:28 CET] <thardin> who needs stable APIs and ABIs
[14:51:22 CET] <kierank> peloverde: have you ever seen adts mpeg2 audio before?
[14:58:26 CET] <kierank> ah it means mpeg-2 aac
[14:58:27 CET] <kierank> bleh
[15:13:53 CET] <BBB> so, what do I do if timestamps for the psnr lavfi filter dont match up?
[15:13:58 CET] <BBB> this broke between 3.2.2 and 3.4.2
[15:14:12 CET] <BBB> Im trying to use setpts and it does nothing useful
[15:14:30 CET] <BBB> (it shifts timestamps, but theyre still wrong)
[15:15:50 CET] <durandal_1707> BBB: pastebin commands you use and ffmpeg output, or just samples you want to psnr
[15:49:05 CET] <BBB> lets see how quickly its closed for me not doing stuff correctly
[16:01:05 CET] <durandal_1707> BBB: invalid, if you framestep (in player that have that feature) you can spot there is subtle difference in man head movements
[16:27:20 CET] <jamrial> durandal_1707: x.ivf decodes bitexact, psnr shouldn't be different if you use x.ivf directly or a decoded raw version of it as one of the two inputs for the filter
[16:40:04 CET] <jamrial> BBB: 3bd11df459866d7303c1ad6779473528c2cfb76d is the culprit
[16:40:11 CET] <BBB> ?
[16:40:13 CET] <BBB> oh
[16:40:15 CET] <jamrial> aka, framesync2
[16:40:17 CET] <BBB> how did you do that
[16:40:21 CET] <jamrial> which is now framesync
[16:40:34 CET] <BBB> so..
[16:40:39 CET] <BBB> can we revert framesync?
[16:40:40 CET] <jamrial> git log libavfilter/vf_psnr.c then look at the changes since 3.2 :p
[16:40:51 CET] <BBB> I mean its clearly broken
[16:40:56 CET] <jamrial> no, but we could fix it
[16:41:03 CET] <BBB> that would be nice also
[16:41:23 CET] <BBB> I have some longer testcases that are broken also
[16:41:35 CET] <BBB> e.g. if I use trim and setpts, it works a little bit
[16:41:38 CET] <BBB> but breaks after 50 frames
[16:41:42 CET] <BBB> I dont know why
[16:42:04 CET] <BBB> my current workaround is to establish a firewall between ffmpeg and timestamps
[16:42:07 CET] <BBB> by using .yuv fifos
[16:42:17 CET] <BBB> and having ffmpeg read from yuv
[16:42:23 CET] <BBB> to make sure it never gets a timestamp
[16:42:24 CET] <BBB> then it works
[16:43:02 CET] <atomnuker> framesync is kinda neat, makes dual input filters easy
[16:44:38 CET] <BBB> I see what youre saying, but easy and wrong is not any more helpful than not at all
[16:44:49 CET] <BBB> but Ill shut up and let the masters fix it
[16:47:44 CET] <jamrial> BBB: nicolas and durandal_1707 are the ones that know lavfi the most
[16:47:47 CET] <jamrial> the former wrote this new framesync implementation, so he's your best bet
[16:49:14 CET] <jamrial> you could in the meantime try to locally revert that commit and a bunch others, to go back to the old framesync + dualinput stuff
[16:49:51 CET] <BBB> the raw yuv trick works OK
[16:50:08 CET] <BBB> I prefer to use recent ffmpeg so that I can use some other patches to link in libaom
[16:50:51 CET] <jamrial> speaking of which, i should get back to merges
[16:51:22 CET] <jamrial> i'm thinking about not merging the libav version of libaom wrapper as is. it's missing a lot of changes we got for the libvpx wrappers from google devs over the years
[16:52:23 CET] <nevcairiel> not sure thats a good thing, that vpx wrapper also has a lot of crap
[16:52:39 CET] <jamrial> yeah, but useful crap :p
[16:53:09 CET] <nevcairiel> like what, the shitty alpha decoding?
[16:53:14 CET] <nevcairiel> does av1 even need that?
[16:53:41 CET] <jamrial> it probably has it, but i'm not going to bother with it
[17:58:26 CET] <durandal_1707> gagandeep: output looks fine compared to cfhd, just use av_clip_uintp2 and it is ready for merge
[18:07:13 CET] <kierank> durandal_1707: did he fix the bug?
[18:19:48 CET] <kierank> durandal_1707: his code doesn't match at all
[18:19:52 CET] <kierank> what about the if(?)
[18:23:00 CET] <durandal_1707> kierank: he probably should add that one, but he says he does not want to copy/paste code :-)
[18:23:22 CET] <kierank> lol
[18:23:42 CET] <durandal_1707> output looks same what testcfhd does(i hacked pam output into it)
[18:24:09 CET] <durandal_1707> it is not bitexact though, but i think it was not at first place
[18:26:30 CET] <kierank> durandal_1707: i am not sure if testcfhd is right (see the github issue)
[18:32:26 CET] <kierank> durandal_1707: also where does testcfhd do the reverse of his code
[18:32:28 CET] <kierank> that's what's strange
[18:34:34 CET] <Chloe> michaelni: is there a fate test for encryption_iv?
[19:03:53 CET] <BodecsB> in avio.c retry_transfer_wrapper function should handle when  transfer_func return 0 (ret == 0) same as EAGAIN ?
[19:05:56 CET] <BodecsB> e.g in unix.c unix_read never return EAGAIN only 0 in case of other end closed socket
[19:06:34 CET] <nevcairiel> no, the protocol itself should map that to EAGAIN these days
[19:06:35 CET] <BodecsB> infinite loop
[19:07:05 CET] <BodecsB> so should I fix the unix_read function to return EAGAIN in case of zero read?
[19:08:10 CET] <BodecsB> won't it break some app?
[19:16:35 CET] <durandal_1707> kierank: similar code is there, "Codec/convert.c" 21618 lines --32%-- <---  ConvertPlanarRGB16uToPackedRGBA64
[19:17:48 CET] <kierank> oh wow that file is so big that github search doesn't index it!
[19:18:25 CET] <JEEB> :D
[19:18:38 CET] <nevcairiel> the github web interface is all sorts of crappy in big code bases
[19:21:45 CET] <michaelni> Chloe, i dont think there is
[19:26:33 CET] <durandal_1707> BBB, jamrial : I fail to see how it's framesync2 fault
[19:27:23 CET] <jamrial> durandal_1707: i have no idea either, but the commit that ported the filter from framesync+dualinput to framesync2 is the one that introduced the regression
[19:27:25 CET] <nevcairiel> psnr filter was updated to framesync2, problem started. either the change to fs2 was bad, or fs2 is bad, pick one. :)
[19:28:13 CET] <BBB> the ssim filter suffers from the same problem btw
[19:29:35 CET] <durandal_1707> nope, previous behaviour is incorrect, current one is correct
[19:30:10 CET] <JEEB> why can't you goddamn explain things ever?!
[19:30:20 CET] <JEEB> people clearly are not understanding and are not stupid
[19:30:23 CET] <jamrial> durandal_1707: how the hell is getting a different result depending on using one input file or another, both of which decode to the exact same bitstream, the correct behavior?
[19:32:22 CET] <JEEB> kierank: btw someone from this channel is making a shader deinterlacer, so clearly some people still care ;) https://github.com/mpv-player/mpv/pull/5633
[19:33:13 CET] <nevcairiel> well its a blend deinterlacer, thats basically the worst you can create, but it aims at super low power devices, so shrug
[19:33:30 CET] <JEEB> :)
[19:33:54 CET] <kierank> durandal_1707: code is replicated like 50 times
[19:37:05 CET] <kierank> his code is still wrong, he should do it the way they do it
[19:37:54 CET] <durandal_1707> kierank: isn't that what they do exactly same?
[19:38:35 CET] <kierank> no
[19:38:38 CET] <kierank> some diferences
[19:38:56 CET] <kierank> 				a -= alphacompandDCoffset;
[19:38:56 CET] <kierank> 				a <<= 3; //15-bit
[19:38:56 CET] <kierank> 				a *= alphacompandGain;
[19:38:56 CET] <kierank> 				a >>= 16; //12-bit
[19:38:56 CET] <kierank> 				a <<= 4;  //16-bit;
[19:38:57 CET] <kierank> 				if (a < 0) a = 0; else if (a > rgb_max) a = rgb_max;
[19:39:30 CET] <kierank> some kind of approximation
[19:40:43 CET] <durandal_1707> jamrial: to me it looks like it now picks frame with different timestamp in different way to previous version
[19:43:00 CET] <durandal_1707> the trac report have 2 files, one have 3 frames, another 5
[19:44:08 CET] <kierank> JEEB: i have no idea how framesync works if ffmpeg doesn't know what time is
[19:44:17 CET] <durandal_1707> framesync works this way: 0 0, 1 1, 2 2, 3 2, 4 2
[19:44:38 CET] <durandal_1707> because one sample is longer than other
[19:44:50 CET] <durandal_1707> so I do not see what is real issue here
[19:45:46 CET] <JEEB> kierank: I think this is a separate discussion we were having the other day :) in which I do agree that at its current state the filters in lavfi are not really usable for live switching of sources
[19:46:06 CET] <kierank> yes
[19:46:24 CET] <jamrial> BBB: ^
[19:46:38 CET] <kierank> BBB: you should have got party invite on fb by the way
[19:47:25 CET] <jamrial> BBB: copying the first three frames of the ivf into another ivf (still vp9, but 3 frames this time) works
[19:48:36 CET] <jamrial> -vframes 3 as output option for the psnr process doesn't affect the input
[19:49:16 CET] <durandal_1707> BBB: perhaps you also need shortest=1 option
[19:49:29 CET] <BBB> ah, thats a start
[19:49:35 CET] <BBB> where?
[19:50:12 CET] <BBB> is that a psnr filter option?
[19:50:20 CET] <durandal_1707> its framesync option
[19:50:32 CET] <durandal_1707> ffmpeg -h filter=psnr
[20:06:10 CET] <JEEB> btw durandal_1707 - thank you for explaining
[20:45:10 CET] <BodecsB> <nevcairiel>: I submitted the patch
[20:54:46 CET] <Chloe> michaelni: is there another case where the option parser fails? one I can easily test without needing an encrypted file?
[20:56:23 CET] <michaelni> IIRC the command takes an unencrypted file and encrypts it but i might misremember
[21:01:14 CET] <BBB> durandal_1707: mind if I provide longer samples that demonstrate the same issue where shortest=1 does not resolve it for me?
[21:02:08 CET] <BBB> I still see issues on my 50-frame sample
[21:07:07 CET] <durandal_1707> BBB: please do
[21:08:41 CET] <BBB> I dont know if I can keep this within 2.5MB
[21:09:31 CET] <durandal_1707> BBB: framesync works by comparing timestamps, so just add printf in dualinput to print pts
[21:09:45 CET] <BBB> I dont love ffmpeg timestamps
[21:09:53 CET] <BBB> and I use setpts=N*TB to reinforce that
[21:10:07 CET] <BBB> I literally want it to ignore timestamps and just compare what I give it frame-by-frame
[21:10:18 CET] <durandal_1707> why you use TB?
[21:10:30 CET] <durandal_1707> some files have subtly different TB
[21:11:26 CET] <BBB> dont I want the same timestamps in the respective timebase?
[21:11:38 CET] <BBB> (I tried without TB and had similar but different issues)
[21:11:49 CET] <BBB> I literally have no idea what Im doing
[21:11:55 CET] <BBB> all I know is that its broken and doesnt work
[21:12:03 CET] <BBB> and it worked in 3.2.2
[21:12:18 CET] <BBB> this was always michaels thing, wasnt it? commandlines shouldnt break - well, it did
[21:17:07 CET] <durandal_1707> BBB: it doesn't make sense, if you want to compare frame by frame, than use setpts=N
[21:17:17 CET] <BBB> ok
[21:17:29 CET] <BBB> I will try setpts=N and psnr=shortest=1
[21:17:32 CET] <durandal_1707> also use settb for both inputs to same value
[21:17:51 CET] <durandal_1707> framesync use timebase and pts to operate
[21:18:02 CET] <durandal_1707> first change tb than pts
[21:18:15 CET] <durandal_1707> and see if that helps
[21:20:03 CET] <BBB> what do I set tb to?
[21:20:16 CET] <durandal_1707> ffmpeg -i 1 -i 2 -lavfi "[0:v]settb=X,setpts=N[a],[1:v]settb=X,setpts=N[b],[a][b]psnr"
[21:20:24 CET] <BBB> literally X?
[21:20:28 CET] <durandal_1707> no
[21:20:30 CET] <BBB> what does X mean?
[21:20:42 CET] <BBB> so what is X?
[21:20:46 CET] <durandal_1707> X = FFMAX(1.tb, 2.tb)
[21:20:50 CET] <durandal_1707> :-)
[21:21:16 CET] <BBB> can I just set it to 1?
[21:21:39 CET] <durandal_1707> nope/ inverse of fps
[21:22:01 CET] <durandal_1707> i hope they all of same fps
[21:27:30 CET] <BBB> yes
[21:27:31 CET] <BBB> all 30
[21:27:37 CET] <BBB> so can I not use timebase=30?
[21:27:43 CET] <BBB> or settb=1/30?
[21:27:47 CET] <BBB> does anything like that work?
[21:27:59 CET] <durandal_1707> settb=30
[21:28:04 CET] <durandal_1707> settb=1/30
[21:28:07 CET] <durandal_1707> sorry
[21:40:18 CET] <cone-781> ffmpeg 03James Almer 07master:f18f9734694e: avcodec/mp3_header_decompress: don't free the user provided packet on error
[21:40:18 CET] <cone-781> ffmpeg 03James Almer 07master:bd60116794b4: avcodec/mpeg4_unpack_bframes: reduce code duplication
[21:48:56 CET] <atomnuker> why do you need to use setpts anyway? paranoia isn't a valid answer
[21:49:41 CET] <durandal_1707> atomnuker: he needs frame by frame comparison
[21:52:58 CET] <JEEB> atomnuker: because framesync gives one frames based on timestamp and not framenr
[21:53:20 CET] <atomnuker> so it does reordering of frames?
[21:56:52 CET] <durandal_1707> no
[21:57:28 CET] <durandal_1707> it tries to give pts which are nearest to each other
[21:59:37 CET] <jkqxz> jamrial:  av_bsf_receive_packet() does actually say "On failure, pkt is not touched".
[22:00:26 CET] <jkqxz> (Considering those patches to the metadata filters.)
[22:01:55 CET] <jkqxz> I think the patches are probably right, but I hadn't really thought about that case before so maybe there are more problems of the same form.
[22:02:16 CET] <durandal_1707> michaelni: so do you know why pngs color_range is marked as limited?
[22:09:21 CET] <jamrial> jkqxz: it also says "pkt should be "clean" (i.e. freshly allocated or unreffed)". so the "not touched" part basically means making sure that on failure pkt is in that same clean state
[22:09:46 CET] <jamrial> which is what every bsf does by doing unref on it in case they already had started populating it
[22:13:59 CET] <BBB> durandal_1707: does the tb matter if I dont use the output frames (-f null -)?
[22:14:15 CET] <BBB> it doesnt appear to be doing anything meaningful
[22:14:16 CET] <michaelni> durandal_1707, why do you ask me ? pngdec sets color_range = AVCOL_RANGE_JPEG; thats not code written by me
[22:14:42 CET] <BBB> and yes, settb+setpts+shortest=1 appear to do the trick
[22:16:40 CET] <durandal_1707> michaelni: i thought you are relevant subject regarding ffmpeg, but that appers to be no longer true
[22:16:49 CET] <jamrial> jkqxz: filter_units also has a similar leak if ff_cbs_write_packet() succeeds but av_packet_copy_props() doesn't
[22:17:12 CET] <durandal_1707> michaelni: png set color_range to JPEG but, later in filter chain is reported as MPEG
[22:21:11 CET] <durandal_1707> it appears, its changed by scale filter...
[22:26:43 CET] <michaelni> durandal_1707, i do not mind helping even though iam busy but please skip the things sounding like insults
[22:27:12 CET] <michaelni> if its a bug in the scale filter, how can i reproduce it ?
[22:31:37 CET] <tmm1> is there some simple/standard way to drop all packets until an idr slice, for h/w h264 decoders that want to start decoding at a keyframe only
[22:31:48 CET] <cone-781> ffmpeg 03James Almer 07master:039be6a23f43: avcodec/h264_metadata: fix memory leak in case of output packet creation failure
[22:31:49 CET] <cone-781> ffmpeg 03James Almer 07master:ae36d6cdde07: avcodec/h265_metadata: fix memory leak in case of output packet creation failure
[22:31:50 CET] <cone-781> ffmpeg 03James Almer 07master:2aac5ad2f72c: avcodec/mpeg2_metadata: unref output packet on failure
[22:33:23 CET] <durandal_1707> michaelni: just add printf color_range in vf_premultiply.c to show out color_range and call premultiply=inplace=1 filter, becase scale is used it will convert rgba to gbrap with color range set to limited
[22:34:19 CET] <michaelni> do you have a complete testcase ? 
[22:34:55 CET] <durandal_1707> michaelni: sorry but there is not currently filter that print color_range of output frame
[22:35:21 CET] <michaelni> thats not what i meant, i can add the printf, i meant a input file and command line
[22:36:53 CET] <durandal_1707> michaelni: ffmpeg -i ../fate-suite/png1/55c99e750a5fd6_50314226.png -vf premultiply=inplace=1 -f null -
[22:37:25 CET] <michaelni> thx, ill take a look later
[23:01:14 CET] <cone-781> ffmpeg 03Gyan Doshi 07master:8ad83044b47a: ffmpeg.c - drain all decoded frames during stream_loop flush
[23:01:15 CET] <cone-781> ffmpeg 03Jörn Heusipp 07master:81b0d591d690: avformat/libopenmpt: Update file extensions list for libopenmpt 0.3
[23:01:16 CET] <cone-781> ffmpeg 03Jörn Heusipp 07master:f6ea397d0ae4: avformat/libopenmpt: Probe file format from file data if possible
[23:01:17 CET] <cone-781> ffmpeg 03Michael Niedermayer 07master:9e67447a4ffa: avformat/mov: Check STSC and remove invalid entries
[23:44:20 CET] <atomnuker> seems like durandal_1707 lost power
[23:46:10 CET] <atomnuker> or internet
[23:53:36 CET] <cone-781> ffmpeg 03Aman Gupta 07master:2ddc6b439226: avcodec/mediacodecdec: propagate SAR to h/w frames
[00:00:00 CET] --- Wed Mar 21 2018