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

[burek]

[00:02:15 CET] <jdlh> durandal_1707 I did ask. It didnt lead to an answer. :-(
[00:02:39 CET] <wm4> cehoyos is one of the most trollish in terms of personal behavior
[00:03:12 CET] <jdlh> wm4 its fucked, thats a descriptive and therefore helpful policy statement, maybe add that to developer.html?
[00:04:52 CET] <wm4> if I could get that in, then I'd rather fix it
[00:05:52 CET] <durandal_1707> jdlh: thing is devs do not agree on some stuff, but we have voting comitee
[00:06:31 CET] <durandal_1707> just call for votes on some subject for resolution
[00:06:49 CET] <jdlh> Is it possible to get the voting committee to write a paragraph describing ffmpeg-devel? Then put that paragraph into developer.html?
[00:07:37 CET] <durandal_1707> beware of  vetoes. somehow one can block further actions that way
[00:08:20 CET] <wm4> hell of a voting system
[00:08:33 CET] <wm4> agree/disagree/flip over table
[00:08:34 CET] <durandal_1707> jdlh: just put to the vote part of conflicting matter
[00:09:37 CET] <durandal_1707> like, should cvs mailing list be mandatory for new contributors
[00:09:53 CET] <jdlh> The problem is, there is zero description of -devel now. How to go from zero to something?
[00:10:19 CET] <durandal_1707> there is somewhere
[00:10:35 CET] <nevcairiel> its just called "the mailing list" in places
[00:10:47 CET] <wm4> I unsubscribed from the cvs list a longer time ago
[00:10:55 CET] <nevcairiel> i never subscribed
[00:10:57 CET] <durandal_1707> its about sending and discussing patches
[00:11:19 CET] <nevcairiel> i read git web and pay attention here when the bot announces stuff most of the time
[00:12:58 CET] <durandal_1707> cvs is mostly usefull for carl eugen and nicolas, people not on irc
[00:14:42 CET] <jkqxz> I do find -cvslog kindof nice to have as it interleaves with discussion in -devel.  It's also a source of emails to reply to.
[00:14:53 CET] <jkqxz> But I don't think it's useful to suggest to random contributors that they should subscribe to it.
[00:17:58 CET] <jkqxz> And yes, being on IRC totally supersedes the notification use for it.
[00:18:23 CET] <wm4> I sorted it into a different imap folder - that was just useless
[00:18:45 CET] <wm4> didn't have the idea to put it into the ffmpeg-devel folder, which makes way more sense
[00:34:30 CET] <jdlh> There are _references_ to ffmpeg-devel in developer.html, but no description of what the list is and how developers should use it. 
[00:35:01 CET] <jdlh> There is such a description for the ffmpeg-cvslog list, but it is wrong, which is also a bug IMHO.
[00:36:23 CET] <iive> jdlh: all ffmpeg development, by default happens on ffmpeg-devel
[00:37:11 CET] <iive> all arguments, changes and decisions are done on it, so they could be documented.
[00:37:26 CET] <iive> and if you want to do development, you have to subscribe to it.
[00:37:51 CET] <iive> telling contributors that they can drop a patch without subscribing is not OK
[00:39:03 CET] <atomnuker> its alright if they're kept in cc so they can reply though
[00:39:11 CET] <atomnuker> for drive-by patches
[00:39:12 CET] <iive> the mail admins have a lot of work, they can easliy miss the patch. the author may not be able to get a reply from developers.
[00:39:18 CET] <michaelni> durandal_1707, i dont remember the exact details, but scale "just" implements support for changing input, it shuld be possible to do similar with other filters
[00:39:20 CET] <BBB> jdlh: Im really sorry that you got stuck in this discussion
[00:39:25 CET] <iive> cc is cancer
[00:39:54 CET] <michaelni> durandal_1707, there is possibly a assert that lists filters wich support changes, this (ugly) code would need to be updated too
[00:39:57 CET] <iive> it grows unrestrained.
[00:40:53 CET] <jdlh> live: several senior developers disagree with you, and say that dropping a patch without subscribing is OK and happens a couple times a month. http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221156.html et seq.
[00:41:07 CET] <iive> jdlh: it happens by accidents
[00:41:13 CET] <jdlh> s/live/iive/, sorry, I cant read.
[00:41:23 CET] <jkqxz> Yeah, asking for cc is really not a good solution.  It gets lost, you lose some replies, things don't make sense.
[00:41:27 CET] <wm4> I don't think that's ok unless said patch authors are ok with the patch easily getting burried and forgotten
[00:41:55 CET] <jkqxz> Subscribing is just better, and if you want you can unsubscribe at the end of it.
[00:42:07 CET] <Compn> oh
[00:42:11 CET] <Compn> whats up jdlh
[00:42:21 CET] <Compn> welcome to the thunderdome :)
[00:42:22 CET] <jdlh> jkqxz, I am about to demonstrate unsubscribe at the end of it.
[00:42:23 CET] <iive> you can subscribe and not get mails... if you don't want to follow it.
[00:42:24 CET] <jkqxz> (I suppose you could use the ML archives instead, but that wouldn't be very fun.)
[00:42:44 CET] <jdlh> Hi Compn, many thanks for your helpful and informative email to me on -devel earlier.
[00:43:11 CET] <jdlh> As you suggested, Im bringing the topic to IRC. 
[00:43:42 CET] <jdlh> So, there is no description of the ffmpeg-devel list in ffmpeg.org/developer.html . Is that OK? (asked just under an hour ago.)
[00:44:51 CET] <Compn> my immediate reaction is yes, but i admit, for a total new person to open source, the arcane things one must know will be daunting without a description
[00:46:05 CET] <Compn> we may take the standard project-developer project-user project-commit mailing list setup for granite.
[00:47:40 CET] <Compn> jdlh : to bolster your argument, i suggest bringing in examples of other projects development documentation to show how ours is deficient.
[00:48:37 CET] <Compn> jdlh : also, if you are looking for a consensus in an all-volunteer project , especially here in ffmpeg land, you will not find one. i dont think we've had a unanimous decision in a long time.
[00:48:59 CET] <Compn> but like i said in the email, i think with some work your patches could get in 
[00:49:14 CET] <jdlh> Compn, most projects I contribute to have either a submit-review-revert workflow (Wikipedia) or a issue - pull request - commit workflow (most github-hosted projects). This is the first project Ive come across which wants me to email patches.
[00:49:17 CET] <Compn> or as i forgot to say in my email and i'm saying now :)
[00:50:04 CET] <iive> jdlh: why do you think git has a send-mail command?
[00:50:05 CET] <jdlh> Compn, Im willing to do work, but Im having a hard time finding people to discuss and agree with. In the -devel list I just got vetoes from cehoyos but not constructive suggestions.
[00:51:30 CET] <jdlh> iive, obviously git has such a command because some projects use it. But Compns comment was, take the standard project-developer project-user project-commit mailing list setup for granite. Im showing there are other setups.
[00:51:47 CET] <Compn> jdlh : if you take a gander at the maintainers file, it explains who to talk to about documentation. documentation                           Stefano Sabatini, Mike Melanson, Timothy Gu, Lou Logan
[00:52:13 CET] <Compn> jdlh : i'd say stefano and mike are not available, so tim or probably lou...
[00:52:36 CET] <Compn> oh TimothyGu is here :)
[00:52:44 CET] <Compn> llogan is not on irc at the moment
[00:52:45 CET] <TimothyGu> huh
[00:52:53 CET] <Compn> TimothyGu : you still maintain the docs ?
[00:53:00 CET] <jdlh> Compn, yes, do you think I should send them emails off-list? I was hoping they would see the discussion on-list and intervene. Lou obviously was reading, they already replied. But didnt say, we need to fix this, heres a better way to fix it".
[00:53:03 CET] <TimothyGu> uhh no, not really I guess
[00:53:34 CET] <TimothyGu> jdlh: feel free to ping me here if you have questions.
[00:53:46 CET] <Compn> jdlh : we are not a very well organized all volunteer project. just so you understand what it is you are dealing with . :)
[00:54:05 CET] <jdlh> TimothyGu, what do you think about adding a description of the ffmpeg-devel list to ffmpeg.org/developer.html ? Presently there is zero description.
[00:54:16 CET] <jdlh> Zero seems like too little.
[00:54:30 CET] <TimothyGu> sure, or just link to https://ffmpeg.org/contact.html#MailingLists
[00:55:22 CET] <Compn> right the description of the list is on that page or on the mailing list page itself https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel/
[00:55:32 CET] <Compn> do you think we need to duplicate a description a third time ?
[00:55:59 CET] <TimothyGu> Honestly I'd just link to contact.html
[00:56:02 CET] <jdlh> I think there needs to be a doc telling new contributors how they should get started. I thought developer.html was that doc, but apparently others think it is a policy statement.
[00:56:42 CET] <TimothyGu> jdlh: there's this: https://ffmpeg.org/git-howto.html
[00:56:45 CET] <cone-451> ffmpeg 03Mark Thompson 07master:b0d9eab7f202: examples/hw_decode: Use hw-config information to find pixfmt
[00:56:47 CET] <iive> isn't there a sending patches section somewhere?
[00:57:37 CET] <Compn> TimothyGu : that page probably needs a mention about subscribing to lists before using git-send email :D
[00:57:49 CET] <TimothyGu> yeah
[00:58:29 CET] <TimothyGu> jdlh: as you can tell we don't quite have a centralized document for how to get started. info is scattered all over the places. It would really help if you could, you know, help contribute to that
[00:58:43 CET] <Compn> TimothyGu : he submitted a patch to -devel to do this
[00:58:49 CET] <jdlh> Heres the flow for a new contributor. 1. In left pane, click on Contribute link. 2. Read 1.2 Contributing at http://ffmpeg.org/developer.html#Contributing . It says Submitting patches to the main developer mailing list. See Submitting patches for details.  3. Read 1.6 Submitting patches at http://ffmpeg.org/developer.html#Submitting-patches . It says, Patches should be posted to the ffmpeg-devel mailing list.â
[00:58:50 CET] <jdlh> It doesnt mention git-howto.html . 
[00:58:51 CET] <Compn> he wants suggestions how to make it better...
[00:59:50 CET] <jdlh> 4. Click on the ffmpeg-devel mailing list link, go to https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel . This has a two-sentence description. Thats only there because I suggested it last week, and Lou accepted my suggestion.
[01:00:48 CET] <jdlh> Notice how we havent sent the new contributer to http://ffmpeg.org/contact.html yet, or told them how to use ffmpeg-devel.
[01:01:29 CET] <TimothyGu> jdlh: I understand you are frustrated. You are entirely welcome to do *whatever* you think would help this situation
[01:02:56 CET] Action: Compn forsees an angry blog post about mean ffmpeg developers
[01:03:13 CET] <Compn> ehehe
[01:03:15 CET] <wm4> ffmpeg developers _are_ mean
[01:03:59 CET] <jdlh> I am trying to. I submitted a patch to make what I think are three small changes to developer.html . 1. describe present behaviour for ffmpeg-devel. 2. change description of ffmepg-cvslog to accurately describe it. 3. Fix structure problem, everything is in Chapter 1. See thread at http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220528.html . The result has been a veto by cehoyos, and no other voices saying, yes we need to fix th
[01:04:00 CET] <jdlh> heres a way forward.
[01:04:41 CET] <Compn> i suggested splitting the patch of changes
[01:04:58 CET] <TimothyGu> ugh cehoyos
[01:05:00 CET] <Compn> just like in ffmpeg code, when you want to change multiple things in one piece of the code, the different changes should be split to speed up review
[01:05:08 CET] <jdlh> Compn, I dont think the developers are mean. I think the project is dysfunctional and structurally broken. I think theres not a strong culture of welcoming and thanking newcomers, like you find at Wikipedia or Python.
[01:05:17 CET] <Compn> so you want to change the chapter thing, then that would be easy to approve of
[01:05:28 CET] <Compn> but your patch wanted to change the policy of ffmpeg, which is why it was rejected...
[01:05:47 CET] <jdlh> But the people are not particularly bad. Like any group, there are better and worse.
[01:06:06 CET] <Compn> having been a wikipedia "editor" since it started, the deletion culture of wikipedia is terrible and full of censorship
[01:06:34 CET] <jdlh> Compn, my patch didnt want to change the policy of ffmpeg, it wanted to _document_ the _existing_ policy of ffmpeg. I tried to write what people told me, and discovered disagreement.
[01:06:49 CET] <wm4> I tried such a patch once too
[01:06:53 CET] <Compn> right , we cant make policy unless we take a vote on it... ;)
[01:07:08 CET] <Compn> which is why i suggest splitting out the other changes (fixing broken links) so those can be applied
[01:07:12 CET] <jdlh> Compn, what does it take to document existing policy?
[01:07:14 CET] <wm4> really I can't make sense out of this shitty project handling
[01:07:39 CET] <Compn> jdlh : a vote of regular developers to agree on a policy
[01:07:48 CET] <cone-451> ffmpeg 03Li, Zhong 07master:b843b343d8a3: qsvenc: cavlc option is only available for h264
[01:07:49 CET] <cone-451> ffmpeg 03Vittorio Giovara 07master:45d7be7f930c: prores: Always assume limited range
[01:07:50 CET] <cone-451> ffmpeg 03Vittorio Giovara 07master:99e9697e3a12: stereo3d: Support view type for frame sequence type
[01:07:51 CET] <cone-451> ffmpeg 03James Almer 07master:dde7b1d4857f: Merge commit 'b843b343d8a3210ae37a2342b1904a5bd1e5fc6e'
[01:07:52 CET] <Compn> majority of regular developers that is
[01:07:52 CET] <cone-451> ffmpeg 03James Almer 07master:eb01ac6c75b5: Merge commit '45d7be7f930cf707ead07416e10e2d0e061e99ce'
[01:07:53 CET] <cone-451> ffmpeg 03James Almer 07master:d268094f8894: Merge commit '99e9697e3a12ab4a6638a36b95edafd6a98f9eaa'
[01:08:16 CET] <Compn> jdlh : much like the wikipedia admins have to gather to vote on policy changes
[01:08:23 CET] <Compn> jdlh : you know the routine.
[01:09:09 CET] <Compn> discuss, propose, vote, etc
[01:09:42 CET] <jdlh> Compn, wikipedia project seems much better than ffmpeg project at devoting effort to writing down policy.
[01:09:46 CET] <Compn> j-b runs a large organization where his members hold meetings and vote on policy
[01:09:58 CET] <Compn> meetings of over 100 people
[01:10:10 CET] <wm4> that's because j-b can actually manage a project, unlike certain other people
[01:10:16 CET] <jamrial> i'm surprised the cvs list is used for anything other than people that like to get commit notifications in their inbox
[01:10:24 CET] <wm4> is ffmpeg/libav the most infamous open source fork drama yet?
[01:10:43 CET] <jdlh> Compn, if say on -devel, regular developers please vote on what is the policy for ffmpeg-devel, and give me a paragraph or two to put in a patch, will that result in any useful agreement and writing?
[01:10:43 CET] <Compn> wm4 : there are large forks like open bsd / free bsd :P
[01:10:49 CET] <jamrial> like, i only found out some people actually sent replies to the automated emails there a few weeks ago
[01:11:14 CET] <Compn> jdlh : no useful writing probably. developers are busy writing code not caring about fixing some old docs no one reads
[01:11:54 CET] <Compn> jdlh : but you could ask lou for suggestions
[01:12:23 CET] <Compn> as he is docs maintainer according to maintainers file :D
[01:12:34 CET] <Compn> TimothyGu : do you still want to be listed as docs maintainer in maintainers file ?
[01:12:36 CET] <jdlh> Compn, and therein lies one of the underlying problems. Developers believe that /developer.html is old docs no one reads, not the primary vehicle for welcoming new contributors and getting them started with helping ffmpeg.
[01:12:52 CET] <TimothyGu> Compn: feel free to remove me from MAINTAINERS
[01:12:54 CET] <Compn> thats just my opinion , not "developers" opinion
[01:13:33 CET] <jdlh> Compn, from the discussion, others agree with that opinion. Its evident from the behaviour of the project.
[01:13:36 CET] <Compn> the primary vehicle to new contributors is the mailing list itself
[01:13:51 CET] <Compn> or here on irc sometimes
[01:14:29 CET] <Compn> writing up a complete how to get started in open source manual is beyond the scope of this project i fear
[01:15:09 CET] <Compn> i mean, how did you learn about github pull requests ?
[01:15:19 CET] <Compn> i guess github has some docs
[01:15:28 CET] <jdlh> Compn, I dont want to write a complete manual. I just want /developer.html to describe ffmpeg-devel, and to stop telling everyone to discuss on ffmpeg-cvslog.
[01:15:30 CET] <TimothyGu> Compn: github pull requests are literally just a button
[01:15:34 CET] <c3r1c3-Win> Yes, in fact their docs are decent to good.
[01:16:11 CET] <TimothyGu> at most individual projects have a separate CONTRIBUTING.md document, which is generally clear and concise (1, 2, 3, 4)
[01:16:43 CET] <Compn> we used to have a dedicated docs writer
[01:16:45 CET] <Compn> but he left
[01:16:55 CET] <Compn> no one has replaced diego
[01:17:14 CET] <jdlh> Compn, do you think that if I proposed a new patch with just one @subheading describing ffmpeg-devel and what contributors do there, that it would get accepted? I see no reason it wouldnt get the same veto which the thread at http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220998.html got.
[01:17:29 CET] <Compn> it cant hurt to try
[01:17:31 CET] <philipl> jkqxz: Can you look at the hw metadata patches? wm4 wants me to send them to libav but I want to make sure you're happy first.
[01:17:33 CET] <Compn> i would say possibly
[01:17:52 CET] <Compn> its hard to tell because i cant see what you will write :D
[01:18:14 CET] <jkqxz> philipl:  I'm just redoing the hw-config patches for libav now.
[01:19:09 CET] <wm4> wait they're still not applied there?
[01:19:24 CET] <jdlh> Compn, you quoted what I would write, in http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221309.html . The 2 paragraphs you described as well meaning, but& repetitive and can be made smaller. If I made a patch with just that, or maybe that but made smaller, would it escape the veto?
[01:19:34 CET] <TimothyGu> jdlh: what I would do is move/split the current document to coding-style.html, checklists.html, etc., and create a new document called "getting started"
[01:19:55 CET] <TimothyGu> but do the getting started thing first, because some people really dislike refactoring
[01:19:56 CET] <jkqxz> I think the flags are fine.  I'm not sure about the provider stuff.
[01:20:15 CET] <jkqxz> wm4:  No, they aren't.  elenril is on holiday so all development grinds to a halt.
[01:20:42 CET] <TimothyGu> because nothing is removed, there's no policy change to discuss
[01:20:48 CET] <jdlh> TimothyGu, that sounds like a great way to do documentation editing, but if my current patch is too complicated for the -devel list, refactoring into coding-style.html, checklists.html etc would drive people nuts.
[01:21:25 CET] <TimothyGu> jdlh: another option is to move stuff to the wiki. less surveillance there, and easier to edit
[01:21:42 CET] <TimothyGu> like just write a new document, link to it from the main website, and be done with it
[01:22:05 CET] <TimothyGu> also, IIRC there isn't a hard veto in the policy, at least not when I was here
[01:22:07 CET] <jdlh> TimothyGu my experience is that policy change or not isnt particularly relevant. All it takes is for one developer to veto a doc change, and the patch is defeated. There is no force to override the veto.
[01:22:43 CET] <TimothyGu> and I by virtue of being the documentation maintainer have the authority to override any veto by the bug tracker maintainer
[01:22:58 CET] <Compn> ooo TimothyGu is maintainer of docs, he has veto override :)
[01:23:10 CET] <jdlh> TimothyGu would you exercise that override?
[01:23:23 CET] <TimothyGu> Yes
[01:23:29 CET] <jdlh> :yay:!
[01:23:55 CET] <wm4> jkqxz: hasn't he been on holiday for a while
[01:24:09 CET] <Compn> TimothyGu : i think he means for the patch he posted
[01:24:17 CET] <Compn> TimothyGu : you may want to review it first...
[01:24:36 CET] <TimothyGu> of course
[01:24:41 CET] <TimothyGu> I will do this tonight.
[01:25:06 CET] <TimothyGu> (in ~5 hours)
[01:25:15 CET] <jdlh> Then, do you think that the present patch is a worthwhile first step?  I mean review it, and maybe have me add the paragraph about it is more important that we receive your patch than that you be subscribed, then is that modification something you would commit?
[01:25:45 CET] <iive> jdlh:  plase
[01:26:02 CET] <iive> plece, do not encourage people to send patches without subscribing
[01:26:31 CET] <iive> or we will make you a mail admin and you will have to read all the spam and find these patches
[01:26:45 CET] <jdlh> TimothyGu, I welcome your review, when you can get to it. Then, it would be veeerrrryy helpful for you to reply to the thread, saying that you are prepared to commit in the face of objections once the editorial corrections are made.  So far, no one has said that in this thread.
[01:27:07 CET] <Compn> iive : did you read the patch ?
[01:27:11 CET] <TimothyGu> iive: :)
[01:27:16 CET] <jdlh> iive, I dont have a strong feeling either way. But Im reporting what I hear developers say. There is divided opinion on this topic.
[01:27:59 CET] <TimothyGu> jdlh: if course, after I review
[01:28:00 CET] <jdlh> Nooooo! Not an email admin!!!
[01:28:23 CET] <iive> jdlh: mail admin approving mails from people that are not subscribed - this is the exception that defines the rule.
[01:28:58 CET] <TimothyGu> alright folks, got some errands to run. will be back in a few hours
[01:28:59 CET] <jdlh> Thank you, TimothyGu, you are my only hope! https://giphy.com/gifs/DrL54YGfFb5Bu
[01:29:48 CET] <jdlh> Im going to step away for a minute&.
[01:30:11 CET] <iive> jdlh: well, there are worse things than manual spam filtering. Like manual youtube video filtering.
[02:09:37 CET] <philipl> jkqxz: I think I've got a failure case with the hw config stuff for you.
[02:09:48 CET] <philipl> Try and play a real h.263 file.
[02:22:39 CET] <wm4> does ffmpeg have any concept for handling float parsing/formatting correctly if the LC_NUMERIC locale is set?
[02:46:49 CET] <cone-451> ffmpeg 03Steven Robertson 07master:c6a905b91d93: avcodec/dnxhddec: Do not overwrite colorspace if the container has set it.
[04:16:36 CET] <cone-451> ffmpeg 03Karthick J 07master:3684b5e56a54: avformat/hlsenc: Refactored 'get_int_from_double' function to allow reuse
[04:16:37 CET] <cone-451> ffmpeg 03Karthick J 07master:8c2b37e678e3: avformat/dashenc: Option to generate hls playlist as well
[04:26:56 CET] <wm4> graphitemaster: does glsl-parser have an irc channel?
[04:38:40 CET] <cone-451> ffmpeg 03James Almer 07master:ae7df68edd79: avformat/avc: return an error in ff_isom_write_avcc if the buffer lenght is too small
[04:38:41 CET] <cone-451> ffmpeg 03James Almer 07master:9cd361c5c1f3: avformat/avc: refactor ff_isom_write_avcc
[04:38:42 CET] <cone-451> ffmpeg 03James Almer 07master:df20619b649e: avformat/avc: reindent after the last commit
[04:38:43 CET] <cone-451> ffmpeg 03James Almer 07master:d5af8afbe469: avformat/avc: free buffer in ff_isom_write_avcc on failure
[04:38:44 CET] <cone-451> ffmpeg 03James Almer 07master:8d33e8661694: avformat/avc: support writting more than one sps/pps in ff_isom_write_avcc
[04:59:51 CET] <graphitemaster> wm4, no not really
[05:00:06 CET] <graphitemaster> I have an irc channel for all my projects tho #gmqcc
[05:03:37 CET] <wm4> I'll go there because this seems a bit too offtopic here
[05:51:43 CET] <cone-451> ffmpeg 03James Almer 07master:5a366f9770dd: configure: select vp9_superframe_split_bsf when enabling vp9_decoder
[05:52:00 CET] <wm4> whoops
[08:43:54 CET] <wm4> would a spdif conversion decoder be accepted? (would take certain codecs and output spdif frames containing compressed data as s16 samples)
[08:59:49 CET] <atomnuker> sure, it'd be just like v210 or bitpacked
[09:00:28 CET] <wm4> no it wouldn't
[09:00:35 CET] <wm4> more like spdifenc
[09:00:38 CET] <wm4> just as decoder
[09:02:13 CET] <atomnuker> it takes compressed data, right? why not make it a bsf?
[09:02:55 CET] <wm4> so I can delete the "decoder" in mpv
[09:07:07 CET] <j-b> btw, is there a simpler EAC3->AC3 conversion process or does it need a full decode+reencode
[09:14:58 CET] <atomnuker> yep, rcombs said its possible to do it directly but its a lossy step
[09:15:14 CET] <rcombs> j-b: in theory I think there's a simpler (lossy) one, but I've never seen actual implementation code so I dunno how you'd go about it
[09:15:34 CET] <j-b> rcombs: who could do that?
[09:15:47 CET] <rcombs> do what?
[09:16:20 CET] <j-b> Have the knowledge to implement that? (against money)
[09:16:39 CET] <rcombs> ¯\_(Ä)_/¯
[11:31:25 CET] <nevcairiel> wm4: the spdif stuff doesnt really fit well into any of the APIs we have, although i dont mind it being in a muxer - its a bit unintuitive to use because muxer output is not packet based, but its easy enough to just packetize it again
[11:44:03 CET] <atomnuker> imo should just be a bsf, it would fit in there the most
[11:45:41 CET] <omerjerk> does someone has the spec for truehd? I was looking at the bug 6216. I will need the spec to fix the bug I guess.
[11:51:48 CET] <atomnuker> no spec, it was re'd afaik
[12:46:16 CET] <atomnuker> michaelni: posted v2 of 2 of the atomic patches so I know whether this will work for the rest as well
[12:47:10 CET] <kierank> j-b: yes there are optional "aids" in the bitstream for set top boxes to transcode
[12:47:29 CET] <j-b> kierank: ah? never heard about that.
[12:47:32 CET] <j-b> kierank: supported in libavocdec?
[12:47:39 CET] <kierank> No
[12:47:47 CET] <nevcairiel> why would we bother with that, we have a eac3 decoder =p
[12:49:01 CET] <j-b> I'd like to do eac3->ac3 (for spdif) with the lowest cpu possible
[12:50:08 CET] <kierank> j-b: it's in the spec somewhere, libavcodec skips over the field
[14:15:15 CET] <durandal_1707> BBB: whats missing for rest of vmaf filter work?
[14:15:16 CET] <cone-069> ffmpeg 03Carl Eugen Hoyos 07master:d13b8f68d7cb: lavfi/libvmaf: Rename local variable "main" as "master".
[14:16:10 CET] <BBB> durandal_1707: time, integerization
[14:22:51 CET] <durandal_1707> typical carl eugen
[14:28:58 CET] <BBB> the users need some help making the bug report useful
[15:15:46 CET] <nevcairiel> what I dont understand about those atomic changes, why bother trying to re-do that code, instead of just replacing the atomic functions that are in use there with stdatomic variants
[15:16:36 CET] <nevcairiel> if two thread modify a linked list, you'll need some sort of cas instruction anyway
[15:28:36 CET] <BBB> everyone is just so rude nowadays :(
[15:33:31 CET] <kierank> durandal_1707: why did you set cfhd bug report to wontfix
[15:39:43 CET] <durandal_1707> kierank: its missing sponsoring contract
[15:42:15 CET] <kierank> meh
[15:42:52 CET] <durandal_1707> you gonna do it for free?
[15:44:25 CET] <kierank> durandal_1707: whether i do it for free or paid is irrelevant to the wish status
[15:49:53 CET] <durandal_1707> kierank: that bug report explicitly talks about using code from github repo
[15:50:02 CET] <kierank> and code is MIT
[15:50:04 CET] <kierank> so what's the issue
[15:50:43 CET] <durandal_1707> code is problematic, license is ok
[15:56:47 CET] <kierank> sure, but afaik the issue is just to find another cropping tag
[15:57:05 CET] <kierank> should be simple but I implemented it in a weird way a per the smpte spec
[16:09:46 CET] <fx159159> Hey, how do I account for pixel stride of a picture when using av_image_copy_to_buffer?
[16:10:37 CET] <fx159159> When pixel stride is one and using row strides as linesizes my picture has the correct colors, on a device with pixel stride 2 the colors are off, only the base image is correctly visible
[16:11:45 CET] <durandal_1707> fx159159: #ffmpeg
[16:12:23 CET] <fx159159> I need it for an indev I developed for ffmpeg...
[16:15:13 CET] <durandal_1707> fx159159: do you use frame->linesize
[16:16:27 CET] <fx159159> durandal_1707: I do not use frames, I'm using packets
[16:16:52 CET] <fx159159> I get the row strides from android, fill in a linesizes array and pass it to av_image_copy_to_buffer
[16:17:44 CET] <durandal_1707> perhaps its padded and lavc expect unpadded?
[16:19:47 CET] <fx159159> The thing is on devices where the pixel stride in every row is 1 it works, I got a new device where the pixel stride of the U and V plane is 2, this breaks the indev
[16:21:13 CET] <fx159159> So yeah, it is somehow padded
[16:22:37 CET] <durandal_1707> than you need to manually unpad it somehow i guesd
[16:24:52 CET] <fx159159> Is there a helper function in lavc to copy and remove a padding?
[16:38:58 CET] <durandal_1707> nope, afaik
[16:39:45 CET] <jdarnley> Do I understand that right?  There is junk between the samples in the chroma plane?
[16:41:25 CET] <fx159159> Yeah
[16:41:45 CET] <nevcairiel> between individual samples? not just between lines? now thats just dumb
[16:42:28 CET] <fx159159> Y plane has a row stride of 640 and pixel stride of 1 => no garbage
[16:42:30 CET] <jdarnley> Not too dissimilar to rgb32 formats but then that means it would be a different pixel format to the one without junk.
[16:42:53 CET] <fx159159> U and V have a row stride of 640 and a pixel stride of 2 => 320 pixels are garbage
[16:43:34 CET] <fx159159> android still calls it YUV420
[16:44:04 CET] <fx159159> pixel stride 2 => use only every second pixel
[16:44:12 CET] <fx159159> guess I need to copy that by hand?
[16:44:39 CET] <nevcairiel> probably
[16:44:42 CET] <nevcairiel> never heard of such a format
[16:45:00 CET] <fx159159> https://developer.android.com/ndk/reference/group___media.html#ga4d7dbc61d2e03f81fa60d365685035b3
[16:45:33 CET] <jdarnley> It may still be YCbCr 4:2:0 but that doesn't state how it is layed out in memory.  That could be yv12, i420, nv12, and so on
[16:46:57 CET] <fx159159> I guess they interleave U and V in memory?
[16:47:17 CET] <nevcairiel> thats what we typically call NV12
[16:53:15 CET] <fx159159> Yeah it is, changing it to AV_PIX_FMT_NV12 makes it work
[16:55:13 CET] <fx159159> Oh well.. how do I make that work on both devices without too much of a fuss...
[17:05:17 CET] <jdarnley> if (junk) pixel format = nv12 else  pixel format = yuv420p
[17:06:45 CET] <fx159159> I need to set the image format on the stream as well... I do not have the information yet to decide which format it is
[17:07:22 CET] <fx159159> I only know it after receiving the first frame
[17:13:27 CET] <jdarnley> Ha!  I've solved this SIMD problem by doing 1 sample in general purpose registers
[17:14:43 CET] <jdarnley> that is so~ ugly
[17:15:39 CET] <fx159159> Would it be acceptable to introduct an av_image_copy_padded_plane plane function in imgutils?
[17:15:44 CET] <fx159159> introduce
[17:16:29 CET] <jamrial> jdarnley: that's not too unusual. other functions do the last bunch of samples (less than 8 or 16) using gprs, but most avoid that by padding the buffers
[17:17:08 CET] <jdarnley> This isn't at the end.  It is th 8th out of 12.
[17:18:51 CET] <jdarnley> Meh. It is that sample's fault for being where it is.
[18:54:36 CET] <durandal_1707> trac is under attack
[19:25:03 CET] <durandal_1707> michaelni: i have code that runs reconfiguration of outpads for filters, but it does not work if .needs_writable is used
[19:26:04 CET] <durandal_1707> idea is to check frame sidedata for stereo3d and resize frame accordingly
[19:32:17 CET] <ubitux> durandal_1707: there is a hardcoded list of filters supposed to support reconfiguration
[19:32:30 CET] <ubitux> look for "idet" in libavfilter/avfilter.c typically
[19:32:49 CET] <durandal_1707> ubitux: i already checked that 
[19:33:13 CET] <durandal_1707> that is for one size change came out 
[19:33:29 CET] <durandal_1707> but i need one from inside
[19:34:16 CET] <durandal_1707> aand i need al next filters in graph to call reconfiguration
[19:42:20 CET] <michaelni> durandal_1707, i dont know of the top of my head how needs_writable interacts here to cause a problem
[20:01:00 CET] <daddesio> if I want to contribute a patch to both Libav and FFmpeg--how does that work? in 2012, you could send a patch to Libav and you could be reasonably certain somebody would adapt it to FFmpeg and credit you in the patch. does that still hold?
[20:02:01 CET] <daddesio> (the Opus decoder has 2 arithmetic overflows from RFC8251 that still need to be fixed in FFmpeg/Libav)
[20:02:10 CET] <BtbN> If the patch is identical, just send it to both
[20:02:22 CET] <ubitux> ideally you write, test and send the patch to both projects, it will save some time for the one merging one way or the other
[20:02:28 CET] <daddesio> :)
[20:03:31 CET] <daddesio> yes, that definitely sounds like the best solution, as it's handy to have the original patch writer present on the mailing list. I will do that then, thanks!
[20:04:01 CET] <daddesio> atomnuker: here are the patches I am talking about: http://daddesio.com/~andrew/files/libav_rfc8251_changes.txt
[20:04:25 CET] <BtbN> That's a weird patch format.
[20:04:32 CET] <daddesio> well they are my personal notes :P
[20:04:48 CET] <daddesio> in fact I will probably post that as a summary of the patchset.
[20:05:11 CET] <daddesio> i.e. as a reply to my patchset
[20:06:41 CET] <daddesio> atomnuker: silk_stabilize_lsf() was already patched a long time ago in FFmpeg (thanks to fuzzing), but the other functions still need to be patched.
[20:07:13 CET] <wm4> wow a manual patch
[20:08:00 CET] <tmm1> durandal_1707: i ran into similar problems a few weeks ago when i was trying to change frame size dynamically in vf_cropdetect
[20:10:36 CET] <wm4> I still claim lavf can't do this
[20:10:51 CET] <JEEB> what exactly?
[20:10:52 CET] <wm4> unless it works with every filter, and buffersink causes the frame to be converted back to the original format
[20:10:55 CET] <JEEB> ah
[20:10:56 CET] <JEEB> lavfi
[20:10:58 CET] <JEEB> not lavf
[20:10:58 CET] <wm4> err, lavfi
[20:10:58 CET] <JEEB> :D
[20:14:56 CET] <BtbN> The problem with lavfi is that the filter is asked about the output link format once, at the start, before it sees a single frame
[20:15:14 CET] <BtbN> So dynamic output resolutions on a per-frame basis just won't work
[20:15:34 CET] <BtbN> You could do a filter that crops and scales up. But that sounds rather ugly.
[20:16:11 CET] <iive> or exands and scales down
[20:16:27 CET] <wm4> the problem is that lavfi format negotiation is too basic, yet too complex
[20:16:59 CET] <wm4> it only negotiates pixfmt/samplefmt/frame size/samplerate/channel layout
[20:17:09 CET] <wm4> but there are a lot of other properties these days
[20:17:25 CET] <wm4> like the color range, and lavfi is half of the reason we _still_ have those jpeg pixfmts
[20:17:33 CET] <wm4> which have been deprecated a decade ago or so
[20:17:57 CET] <jamrial> the other half is swscale
[20:18:30 CET] <wm4> well libswscale can use the color range these days
[20:18:39 CET] <wm4> if you don't use any of the crappy old APIs
[20:18:54 CET] <wm4> (you need to use AVOption to configure all parameters instead...)
[20:19:09 CET] <JEEB> :D
[20:48:56 CET] <durandal_1707> it can be added i have half working code
[20:51:11 CET] <atomnuker> daddesio: yeah no mate, the celt hybrid folding's fucked
[20:51:28 CET] <daddesio> lolwut?
[20:51:30 CET] <atomnuker> I tried to do it and I just get DCs
[20:51:40 CET] <atomnuker> no ac coeffs anywhere
[20:51:52 CET] <atomnuker> because lowband_offset = i
[20:51:58 CET] <atomnuker> also there's a second issue
[20:52:06 CET] <daddesio> I admit I haven't actually tested my patches yet (which is why I haven't submitted them to the ML yet)
[20:52:09 CET] <atomnuker> the effective_lowband is different from the one in opus
[20:52:32 CET] <daddesio> that certainly helps to know...
[20:55:51 CET] <atomnuker> daddesio: you handle the silk stuff, I'll try to find out what goes wrong in celt
[20:55:59 CET] <atomnuker> the issue seems to be somewhere in the pvq code
[20:56:34 CET] <daddesio> that's impossible. effective_lowband should be the same because I already verified yesterday (with gdb) that celt_freq_bands = eBands
[20:57:20 CET] <atomnuker> nope, 40 is what I got, 40 and -1
[20:57:26 CET] <daddesio> are you saying that effective_lowband takes on different units / dimensional analysis, or is it a bug in FFmpeg causing effective_lowband to have the *wrong* value?
[20:57:32 CET] <atomnuker> and look at how its defined, its different
[20:57:44 CET] <atomnuker> could be
[20:57:57 CET] <atomnuker> nevcairiel: I _CAN'T_ USE THAT CAS PIECE OF SHIT FUNCTION
[20:58:58 CET] <atomnuker> I bet that new logic you proposed won't work
[20:59:09 CET] <atomnuker> why does filter registration need to be so difficult
[20:59:12 CET] <atomnuker> fuck linked lists
[20:59:46 CET] <daddesio> I'll try it out in Libav, and do some investigation if it doesn't work. then look at FFmpeg. since Libav's code is a little bit closer to libopus.
[21:00:09 CET] <daddesio> libopus circa 2012, that is
[21:00:59 CET] <atomnuker> a little closer? try again
[21:01:13 CET] <atomnuker> current opus git master is completely different to anything
[21:02:25 CET] <atomnuker> so how am I meant to fix the _Atomic keyword issue?
[21:02:52 CET] <atomnuker> also michaelni on which platoform does you complilation fail?
[21:03:53 CET] <michaelni> atomnuker, ubuntu 14.04 LTS x86-64
[21:04:06 CET] <atomnuker> so gcc 5?
[21:04:23 CET] <michaelni> it should have been: gcc (Ubuntu 4.8.5-2ubuntu1~14.04.1) 4.8.5
[21:04:32 CET] <atomnuker> ah, it shipped with 4
[21:05:24 CET] <wm4> durandal_1707: so for mid-stream changes I'd have 3 conditions: 1) every filter has been checked whether it supports if its inputs are dynamically changing, or something to guard against filters which do not support it, 2) buffersrc by default does not change configuration, 3) it's clarified whether buffersink allows changing input frame parameters
[21:05:52 CET] <wm4> durandal_1707: it'd also be fine to add an user API flag to buffersrc, so a user can choose to support frame changes
[21:05:59 CET] <wm4> (on top of those)
[21:57:51 CET] <TimothyGu> l
[21:57:52 CET] <TimothyGu> oops
[21:58:44 CET] <gnafu> Froot Loops?
[21:59:51 CET] <BtbN> That zermok guy...
[22:06:16 CET] <durandal_1707> wm4: this is about filters adopting to internal changes and not external
[22:07:58 CET] <wm4> durandal_1707: not really... buffersrc reflects those changes
[22:08:03 CET] <wm4> so it's an API issue too
[22:08:18 CET] <durandal_1707> i do not touch buffersrc
[22:08:46 CET] <durandal_1707> the only difference are buffersink frames
[22:21:46 CET] <wm4> oh I think I confused them
[22:21:52 CET] <wm4> so switch those terms in my text
[22:22:28 CET] <wm4> anyway, if lavfi can do mid-stream parameter changes, I'd like to use that via buffersrc (filter input)
[22:22:51 CET] <wm4> does the filter graph data flow code properly flush frames before reconfiguring filters?
[22:39:31 CET] <nevcairiel> atomnuker: don't scream, and why not. It's the only way to do this, as soon as you need two instructions to basically do the same thing different, you lose the atomic nature
[22:40:12 CET] <wm4> is this about the filter reg mechanism?
[22:40:17 CET] <wm4> it should be killed anyway
[22:40:25 CET] <wm4> in the same way it was done for BSF
[22:41:18 CET] <nevcairiel> That's a separate discussion, just exchanging one cas command for another shouldn't be this big of a deal
[22:41:58 CET] <nevcairiel> The functions practically do the same with slightly different syntax
[22:42:08 CET] <jamrial> there are two pointers, for first and last element in the lists. if he reverts the two commits i mentioned that will become just one
[22:42:09 CET] <jkqxz> And then all those things could be marked as const, go in rodata, and be shared between instances, too.
[22:42:17 CET] <jamrial> i find it hard to believe it wouldn't help porting things easier
[22:42:47 CET] <jamrial> specially when one of the commits explicitly says it's complex on purpose to maintain the order for the sake of a 3 years old abi
[22:43:00 CET] <wm4> lol?
[22:43:15 CET] <nevcairiel> The logic is already there, just swapping out the atomic functions shouldn't really be that hard
[22:43:48 CET] <jamrial> wm4: one commit made the registering faster, but was done in a complex way to avoid inverting the order of elements in the list, which would be an abi break, supposedly
[22:44:05 CET] <jamrial> that of course is not an issue now
[22:45:03 CET] <wm4> ...
[22:45:07 CET] <jamrial> 133fbfc7811 and ec464c96831
[22:45:13 CET] <wm4> I love complex fixes for ridiculous crap
[22:45:22 CET] <jamrial> they are complex and pointless, just to make the thing faster
[22:45:22 CET] <wm4> and avoiding the simple and obvious solution
[22:46:28 CET] <nevcairiel> The atomics don't really make the register functions fully thread-sane anyway, it may not corrupt the structure, but can't it result in one filter being in there twice when two threads do it?
[22:47:19 CET] <wm4> yeah I doubt it's sane
[22:47:21 CET] <nevcairiel> Personally i just call it from DllMain which is always fully serialized
[22:47:45 CET] <wm4> unless something else also calls it at the same time for whatever reason
[22:48:01 CET] <wm4> that's the nice thing about non-threadsafe global init functions
[22:50:06 CET] <nevcairiel> I ship private dlls, so noone else messing with that
[22:50:42 CET] <wm4> I mean if you do it in ffmpeg's DllMain, then sure
[22:51:51 CET] <nevcairiel> Nah, but it's highly unlikely that anyone else is going to load my private copies of the libs and mess with them
[22:52:21 CET] <wm4> hm, fine
[22:53:05 CET] <nevcairiel> Anyway not against converting that to a static list, it's just a separate issue from porting the atomics
[23:05:15 CET] <SortaCore> "The encoder expects a raw 4:2:0 planar YUV (FourCC: NV12) frame input. All input of other formats needs to be converted (real-time or otherwise) to the supported NV12 format."
[23:05:25 CET] <SortaCore> from QSV docs
[23:05:35 CET] <SortaCore> yet it doesn't like YUV420P format?
[23:06:03 CET] <nevcairiel> Why would it, it clearly says it wants NV12
[23:06:17 CET] <SortaCore> I'm confused on the difference, then
[23:06:47 CET] <SortaCore> I thought they were completely different, but there it mentions it like one's a subtype
[23:06:49 CET] <nevcairiel> Nv12 has interleaved chroma samples
[23:07:27 CET] <wm4> yeah I'd definitely not call nv12 planar
[23:07:33 CET] <wm4> maybe semi-planar
[23:07:44 CET] <wm4> it's 4:2:0 yuv anyway
[23:07:54 CET] <wm4> so that qsv docs statement is a bit ambiguous
[23:08:25 CET] <SortaCore> well, I'm getting YUV420P from a RSTP stream, but I can't use HWA to decode it, which is a bit annoying
[23:08:36 CET] <nevcairiel> Well it quotes the FourCC, so that seems pretty clear
[23:09:44 CET] <SortaCore> Video: h264 (High), 1 reference frame, yuv420p(pc, bt709, progressive, left), 960x480
[23:09:56 CET] <nevcairiel> And rtsp is going to give you a compressed bitstream, that's the decoder, not encoder
[23:10:18 CET] <SortaCore> am I puzzled on this, too?
[23:10:34 CET] <SortaCore> rtsp de-muxes and removes rtsp wrapper around video feed
[23:10:40 CET] <SortaCore> video feed is then decoded by h264 native
[23:10:54 CET] <SortaCore> at that point I can access the frames from the decoder
[23:11:03 CET] <SortaCore> and pass to encoder, then mux to file
[23:11:23 CET] <SortaCore> am I misusing terms or any oddities about that
[23:12:01 CET] <SortaCore> "Intel Media SDK 3.0 DxShow H.264 Encoder plug-in supports native FourCC YUY2 input and automatically converts to the supported pixel format (NV12) of Intel® EMGD encode engine. The pixel conversion process uses fast Intel® Integrated Performance Primitives (IPP) libraries or if supported by the driver, the DXVA2 VideoProcessBlt interface."
[23:12:06 CET] <SortaCore> (sry for spam)
[23:12:23 CET] <SortaCore> so is there a built-in convert I can use for the decoder part
[23:12:33 CET] <nevcairiel> No.
[23:12:43 CET] <nevcairiel> You don't need to convert
[23:13:25 CET] <nevcairiel> If you use a hardware decoder it's going to give you NV12 frames, and you can pass that to the encoder
[23:13:59 CET] <SortaCore> so how do I do that?
[23:14:04 CET] <nevcairiel> Or even better, directly transfer it on hardware surfaces
[23:15:00 CET] <SortaCore> I've seen stuff about hw_context, hwaaccel, don't mix qsv hwaccel with qsv encoder, pix_fmt_qsv is ffmpeg.c trickery...
[23:16:34 CET] <jfmcarreira> heyyy guys
[23:16:36 CET] <tmm1> ffmpeg -i rtsp-source -vf format=nv12 -c:v h264_qsv ...
[23:16:55 CET] <jfmcarreira> calling this code on a .264 and always returning EOF in av_read_frame
[23:17:01 CET] <jfmcarreira> http://dpaste.com/1CM1RNT
[23:17:44 CET] <SortaCore> make sure you're not passing null packet, or packet with data 0 size 0, that eofs it
[23:18:45 CET] <SortaCore> you should be checking line 34 doesn't fail
[23:19:05 CET] <SortaCore> and line 31 never checks for eagain
[23:19:07 CET] <tmm1> wm4: can your lavc mf encoders be upstreamed?
[23:19:45 CET] <SortaCore> tmm1: how do I do that from C++?
[23:19:55 CET] <jfmcarreira> SortaCore: first time line 10 returns  ( iRet == AVERROR( EAGAIN ) || iRet == AVERROR_EOF ) which is normal
[23:20:21 CET] <JEEB> EAGAIN is normal procedure
[23:20:25 CET] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
[23:20:30 CET] <JEEB> properly documented, too
[23:21:22 CET] <jfmcarreira> SortaCore: then i am going to read a pkt using av_read_frame and it return EOF
[23:21:22 CET] <jfmcarreira> SortaCore: what kind of AVPacket should i supply to av_read_frame?
[23:21:40 CET] <SortaCore> I have two loops, once for ending and one for regular
[23:22:15 CET] <jfmcarreira> thats not my problem. the problem is with av_read_frame. so i cant get a pkt to supply to the decoder
[23:22:27 CET] <durandal_1707> tmm1: mf is demuxer
[23:22:50 CET] <SortaCore> that's probably what you want to do tho jfm
[23:23:09 CET] <jfmcarreira> SortaCore: that makes sense. i use to have that too with the old API. but so far i cant even read one frame. so i do not need to be worried about flushing the decoder
[23:23:54 CET] <SortaCore> you could combine them I guess, but makes your code harder to read
[23:24:17 CET] <SortaCore> plus if user terminates you want to be able to end by yourself
[23:24:45 CET] <jfmcarreira> SortaCore: yeah so far my loop tries to combine both. if it doesnt work i can fix it later. i cant even read 1 frame :(
[23:25:09 CET] <jamrial> durandal_1707: maybe see 99e9697e3a, which i merged yesterday, for the stereo3d mono case
[23:25:35 CET] <jfmcarreira> SortaCore: i cant follow the normal examples because this is not decoding to file. i want to decode and display. so just need one frame at a time
[23:26:13 CET] <jfmcarreira> at this moment i just want to call av_read_frame for the first time without getting EOF error :)
[23:27:51 CET] <wm4> tmm1: not sure why you're asking me
[23:28:15 CET] <SortaCore> jfm: this should be in #ffmpeg as it's your usage of deving with ffmpeg, not devving ffmpeg itself
[23:28:37 CET] <jfmcarreira> SortaCore: ok fair enough.
[23:29:17 CET] <jfmcarreira> SortaCore: btw how could i compile ffmpeg to be able to debug from my code into libav libraries. that would be awesome. so i could find the origin of these errors messages
[23:29:37 CET] <tmm1> wm4: i found the commit/branch in your ffmpeg tree, wasn't sure if it was ever submitted to the list or considered for merging
[23:29:47 CET] <SortaCore> most of libav libraries are static functions
[23:29:58 CET] <SortaCore> so C++ can only see them from within the file they're in
[23:30:03 CET] <SortaCore> makes debugging harder
[23:30:07 CET] <jcdutton> I have a patch that helps the -f segment options store the segments in separate directories based on date.  What is the best way to submit a patch?
[23:30:28 CET] <SortaCore> but if you do changes to the code and then make (without configure first), it will only change that part
[23:30:36 CET] <wm4> if I have such a branch it must be old and bitrot
[23:30:36 CET] <tmm1> jcdutton: git-format-patch + git-send-email to the ffmpeg-devel list
[23:30:53 CET] <jcdutton> tmm1, cheers
[23:31:07 CET] <SortaCore> so you can insert a function that will cause your program to break, or put a breakpoint and Step Into (F11 normally)
[23:31:17 CET] <durandal_1707> tmm1: have a link?
[23:31:32 CET] <SortaCore> my guess is, your bools and ifs are wrong
[23:31:43 CET] <SortaCore> why do you break on line 24?
[23:31:47 CET] <jfmcarreira> SortaCore: but i was not being able to step into ffmpeg functions. maybe something i didnt wrong with ffmpeg build or linking
[23:31:48 CET] <tmm1> https://github.com/wm4/FFmpeg/commit/f249f5f3ce71
[23:33:06 CET] <durandal_1707> ah ms stuff
[23:33:10 CET] <wm4> ancient, so I got rid of it
[23:34:38 CET] <wm4> I mean there's a newer version of that, if you know where to look
[23:34:49 CET] <SortaCore> jfm, push comes to shove you can add a debug breakpoint in there
[23:34:59 CET] <SortaCore> and if you do make without configure it will build a new library with it
[23:35:06 CET] <SortaCore> won't remake the entire thing
[23:35:46 CET] <SortaCore> *cough* just noticed I was still on ffmpeg-devel
[23:35:48 CET] <SortaCore> thought I switched
[23:36:32 CET] <jfmcarreira> SortaCore: i dont mean creating a new stuff.. cant i just build normal ffmpeg and debug into it? or doesnt it allow from c++?
[23:36:46 CET] <nevcairiel> re mf: i personally never thought its a particularly good idea to wrap something huge like that in the guise of an encoder or decoder, fwiw
[23:36:54 CET] <SortaCore> tmm1, how do I do -vf format=nv12 in C++?
[23:37:23 CET] <tmm1> SortaCore: the same way that ffmpeg.c does
[23:37:42 CET] <nevcairiel> if all you need is format changes, just use swscale directly
[23:37:48 CET] <nevcairiel> for more complex things, use avfilter
[23:37:56 CET] <tmm1> jfmcarreira: ./configure --disable-stripping maybe
[23:38:29 CET] <SortaCore> I'm using swscale directly, but I'd prefer HWA converts
[23:38:40 CET] <SortaCore> or better yet a way to tell the rtsp stream to send nv12...
[23:39:30 CET] <jfmcarreira> SortaCore: actually i built some static ffmpeg libs 
[23:39:32 CET] <nevcairiel> rtsp doesnt send either nv12 or yuv420p, it sends compressed h264
[23:39:46 CET] <nevcairiel> it depends on the decoder what comes out of that
[23:39:54 CET] <SortaCore> it's the native h264 decoder
[23:40:07 CET] <SortaCore> despite trying to switch to h264_qsv for decoding
[23:41:42 CET] <wm4> the qsv decoder doesn't have any advantages anyway
[23:41:48 CET] <wm4> use native h264 wioh hwaccel
[23:41:50 CET] <wm4> *with
[23:42:05 CET] <nevcairiel> its unfortunate that intel broke d3d11 input to qsvenc
[23:42:24 CET] <wm4> yeah
[23:42:33 CET] <wm4> apparently jkqxz never got that to work
[23:42:34 CET] <SortaCore> qsv files have an odd mix of having d3d11 and not having it
[23:43:01 CET] <nevcairiel> wm4: he figured out why, intel doesnt currently support array textures
[23:43:03 CET] <jkqxz> SortaCore:  "ffmpeg -hwaccel dxva2 -i ... -vf hwmap=derive_device=qsv -c:v h264_qsv ..."
[23:43:14 CET] <wm4> right
[23:43:37 CET] <jkqxz> wm4:  Intel guy said that it wasn't implemented and that they might at some point.  Haven't heard anything more.
[23:43:44 CET] <wm4> (could just do a texture copy on the GPU)
[23:43:53 CET] <wm4> we discussed this I think
[23:44:13 CET] <jkqxz> DXVA2 is fine, though, so whatever.  (Until people start implementing useful D3D11 filters, then maybe it would be worth doing.)
[23:44:44 CET] <SortaCore> ok, so h264 decoder, dxva2 hwaaccel, then encoder is h264_qsv, dxva2 hwaccel or no hwaccel?
[23:45:03 CET] <nevcairiel> right i should continue working on the d3d11 filter
[23:45:06 CET] <SortaCore> I'm setting up hwaccel by hw_device_ctx
[23:45:33 CET] <SortaCore> I think I've been sat trying to get QSV to work for nearly half a year now
[23:46:38 CET] <wm4> nevcairiel: what would that filter do?
[23:46:39 CET] <jkqxz> nevcairiel:  Yep :P
[23:47:23 CET] <nevcairiel> wm4: scale and deinterlace i figure, maybe pixfmt conversion as much as the d3d11 vpp offers (probably p010 -> nv12 and p010/nv12->rgb)
[23:47:27 CET] <daddesio> atomnuker: my special hybrid folding patch seems to work fine. On test vector #12, the difference signal (before and after special hybrid folding) shows a small noise difference at 11.7 seconds in Audacity--exactly like libopus does (when compiled with/without --disable-rfc8251).
[23:47:51 CET] <wm4> nevcairiel: feel free to steal from the mpv source code, if it's any help
[23:48:38 CET] <wm4> that one (pretty basic but mostly works) https://github.com/mpv-player/mpv/blob/master/video/filter/vf_d3d11vpp.c
[23:49:53 CET] <nevcairiel> i p robably just need to sit down and actually work on it for a bit, and it'll all come together
[23:50:28 CET] <wm4> I think it's pretty simple (nicer API than vaapi vpp at least)
[23:50:38 CET] <wm4> though I never understood how you select the deint algo
[23:50:44 CET] <nevcairiel> adding d3d11 input to nvenc was rather trivial already, so it would be nice to get a full chain setup with scale and deint
[23:50:55 CET] <nevcairiel> i dont think you're really supposed to
[23:51:16 CET] <wm4> yeah, but vavpp and vdpau allow you to select it
[23:55:00 CET] <jkqxz> And does anyone ever use that ability?
[23:55:17 CET] <wm4> that's a UI issue
[23:55:29 CET] <wm4> kodi for one lets you easily select it with its UI
[23:55:34 CET] <wm4> (I think)
[23:55:36 CET] <nevcairiel> is it? does it make sense to use anything but the best one?
[23:56:05 CET] <jfmcarreira> SortaCore: got it :)
[23:56:08 CET] <wm4> is there a best deint algo? also deint and ivtc are different
[23:59:04 CET] <JEEB> oh fun, libavcodec/arm/hevcdsp_idct_neon.o still fails
[23:59:07 CET] <JEEB> on clang
[00:00:00 CET] --- Fri Dec  1 2017