Ffmpeg-devel-irc
Threads by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
December 2017
- 1 participants
- 62 discussions
[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#ga4d7dbc61d2…
[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
1
0
[00:00:25 CET] <TheRock> Hello, i remember clonecd from 2004
[00:00:29 CET] <TheRock> ffmpeg is almost as good as clonecd
[00:00:58 CET] <durandal_1707> clonecd is?
[00:01:22 CET] <alexpigment> I really appreciated this bit of randomness :)
[00:01:29 CET] <fella> durandal_1707: ripping copyrighted DVDs
[00:01:44 CET] <alexpigment> Hello, i remember audiograbber from 2002
[00:01:49 CET] <alexpigment> ffmpeg is almost as good as audiograbber
[00:02:44 CET] <durandal_1707> fella: thats clonedvd :)
[00:03:17 CET] <fella> durandal_1707: see? i can't remember ;)
[00:03:18 CET] <alexpigment> pretty sure it's the same company
[00:03:33 CET] <alexpigment> they also have clonebd
[00:04:41 CET] <durandal_1707> ok, ffmpeg have nothing with ripping, it just have cdparanoia wrapper
[01:08:33 CET] <lightbulb6> hello, how can i make the "crop" filter update the "n", "pos" and "t" variables when the source is a single png image? please see: https://bpaste.net/show/54eeaa31a2b6
[01:09:06 CET] <lightbulb6> here, the text.png file is a simple 640x360 pixels image with some sample text
[01:09:35 CET] <lightbulb6> and for some reason, the "n" variable stays at 0
[01:10:14 CET] <lightbulb6> i expected it to increase with each frame, so that with each frame, more of the text.png can be seen
[01:11:14 CET] <lightbulb6> if i try to use the "pos" or "t" variables, ffmpeg complains "Error when evaluating the expression 't+100'"
[01:31:40 CET] <therage3> what exactly does '-tune animation' do? the docs aren't really clear about how it optimizes cartoons and animation
[01:38:18 CET] <kinkinkijkin> anybody here use vapoursynth?
[01:38:33 CET] <c_14> therage3: ask in #x264
[01:38:52 CET] <therage3> c_14: cheers, let's see what they say
[01:38:55 CET] <c_14> tunes are business of the encoder, not ffmpeg itself
[01:39:07 CET] <therage3> i see
[02:00:22 CET] <yukiup> is there a channel for hevc_nvenc?
[02:00:47 CET] <yukiup> for making the quality of the video higher
[02:12:37 CET] <jfmcarreira> heyy guys
[02:12:48 CET] <jfmcarreira> the new avcodec api works on all codecs?
[02:25:12 CET] <julianc> Hi, I'm re-encoding an mp4 using an HTTP resource as an input. The input's MOOV atom is at the end of the file and is large enough that I want to avoid downloading the MP4 in advance. FFMPEG is getting bogged down making 1000s of HTTP range requests while seeking the MOOV atom. Is there a way to tweak FFMPEG's MOOV atom seeking behaviour so that it makes larger range requests from the HTTP source? I've looked at https://ffmpeg.org/f
[02:25:24 CET] <julianc> and couldn't find anything helpful.
[07:37:41 CET] <Guest72929> >>> youtube.com/watch?v=X8qL6cAI0zQ
[09:18:27 CET] <kode54> Lavc56.12.101 libvorbis <- was this known to write malformed vorbis streams?
[09:19:05 CET] <kode54> I have some game-bundled .ogg files that have sequences of two or three consecutive packets with malformed offsets in their granulepos
[09:19:34 CET] <kode54> two or three packets that all have the same reported dependent timestamp, in the future
[09:20:09 CET] <kode54> https://hydrogenaud.io/index.php/topic,115032.msg948508.html#msg948508 <- log here
[09:20:35 CET] <kode54> my bad
[09:20:46 CET] <kode54> "previous" is in the future, and the same value on two or three packets in a row
[11:39:10 CET] <Kristjan> My name is Kristjan. I am in urgent need for money. People, please send me money with min sum of 50 $. IBAN: EE671010010225901016 (SEB Estonia). Name: Kristjan Robam
[11:41:35 CET] <pomaranc> Kristjan: do you accept bitcoin?
[11:42:15 CET] <Nacht> Yeah man, go with your time. Include a wallet as well
[11:42:49 CET] <fsphil> I am in urgent need of breakfast. Please send me toast
[13:59:27 CET] <dradakovic> So i followed the ffmpeg compile guide on https://trac.ffmpeg.org/wiki/CompilationGuide/Centos. I followed it in a nutshell step by stem. But when i get to ./configure of the ffmpeg itself with enabled encoders i get the ERROR: libmp3lame >= 3.98.3 not found
[14:00:37 CET] <dradakovic> It is like the pkg-config path is not known but i did specify it
[14:02:01 CET] <JEEB> most likely because LAME has a bad .pc file
[14:02:10 CET] <JEEB> check the ffbuild/config.log file for what's missing
[14:06:13 CET] <dradakovic> may i upload the log to be checked?
[14:06:35 CET] <sfan5> yes just pastebin it
[14:06:57 CET] <dradakovic> ah yes
[14:12:37 CET] <dradakovic> https://pastebin.com/H9hxwLzK
[14:15:00 CET] <sfan5> oh yeah someoene had the same issue last week
[14:15:30 CET] <sfan5> add --extra-libs="-lm" to the ffmpeg configure
[14:15:50 CET] <dradakovic> ohh i see. Let me try this immediately
[14:28:59 CET] <dradakovic> i think it worked. installing now. Ive had a similar error for a few other libraries but i removed the --enable from them. It passed libmp3lame tho which it matters
[14:29:18 CET] <dradakovic> i will report the outcome
[14:29:27 CET] <dradakovic> ty very much for now
[14:30:07 CET] <dradakovic> good bunch of people here
[14:35:06 CET] <dradakovic> Damn it works!
[14:35:09 CET] <dradakovic> Ty so much
[14:42:50 CET] <dradakovic> Maybe someone who is maintaining that guide should add that line to it. It would probably help a bunch of us noobs
[15:40:55 CET] <tyng> does libavcodec plan to support its own threaded av1 decoder?
[15:42:55 CET] <DHE> is there a decoder available today?
[15:43:00 CET] <DHE> (or even an encoder)0000000
[15:43:04 CET] <DHE> gah, stupid vnc
[15:43:13 CET] <durandal_1707> no today
[15:45:56 CET] <tyng> there is a reference codec under development
[15:46:13 CET] <tyng> but as libvpx it is not meant to be efficient
[15:46:22 CET] <JEEB> it's libaom now
[15:46:30 CET] <JEEB> libvpx is for VP8/9
[16:12:39 CET] <Fenrirthviti> Hmm, anyone done stress testing with nvenc on a 10-series GPU? Trying to find what FPS it should be hitting at 4k encoding. NVIDIA docs only list 1080p values (261fps) that I can find
[16:13:03 CET] <fx159159> Hey, how do I account for pixel stride of a picture when using av_image_copy_to_buffer?
[16:13:04 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:13:26 CET] <DHE> Fenrirthviti: roughly speaking the limit is pixels/second. so you could expect 1/4 that number for 4k
[16:16:16 CET] <Fenrirthviti> hmm, ok.
[16:19:06 CET] <Guest90028> hello, i am trying to use ffmpeg to save udp stream to check for decoding errors and such. I am using the following command: https://pastebin.com/9qYHeCPs allthought i have a hunch that ffmpeg demuxes and remuxus the stream before it is saved which in the end possibly masking errors
[16:20:43 CET] <DHE> unfortunately yes. also the mpegts demuxer generates alerts for continuity errors at the debug level making them rather useless
[16:21:01 CET] <DHE> I recommend saving it using something else. considering the format, I'd just use netcat in UDP mode
[16:22:09 CET] <Guest90028> i have tried netcat, allthought there isnt a way for specify how long i should record for, and when i kill the process i am getting an issue where last key frame is incomplete and fails to decode
[16:23:02 CET] <Guest90028> unless there is an easy way to remove everything after last key frame
[16:23:33 CET] <DHE> if you're looking for packetloss, wireshark might be able to help you more here. though 10 minutes is a lot
[16:24:44 CET] <Guest90028> I need roughly 5 min, the example above was more of a longer test with ffmpeg
[16:25:58 CET] <Guest90028> but i guess there is no way to disable demuxing/remuxing in ffmpeg
[16:28:55 CET] <DHE> well, how about: ffmpeg [input] -c:v rawvideo -c:a pcm_s8 -f null /dev/null # and just watch for errors from the video/audio decoders
[16:29:20 CET] <DHE> doesn't save it, but does check for errors in realtime?
[16:37:12 CET] <therage3> are there any flags/parameters for detelecine for the x264 encoder? i know there's options for Handbrake, but i can't seem to find anything for ffmpeg
[16:37:39 CET] <Guest90028> hmm, thats possible
[16:38:21 CET] <therage3> were you talking to DHE or to me?
[16:38:52 CET] <Guest90028> DHE
[16:39:06 CET] <therage3> oh
[16:44:52 CET] <Guest90028> quick question, i am trying to figure out what does "co located POCs unavailable" mean?
[16:54:38 CET] <alexpigment> therage3: https://ffmpeg.org/ffmpeg-filters.html#detelecine
[16:56:49 CET] <alexpigment> to be clear, this isn't for the x264 encoder; this is an ffmpeg filter that occurs before x264 in the chain
[17:22:23 CET] <therage3> alexpigment: i see, thanks
[17:22:48 CET] <alexpigment> therage3: if you are detelecining NTSC content, the defaults are usually fine
[17:23:39 CET] <therage3> alexpigment: that's exactly what i want to detelecine, yeah. i got this 2007 animated NTSC DVD, and yesterday when i was comparing quality of frames of a raw mkv with a transcoded one, i noticed the telecined frames
[17:25:01 CET] <alexpigment> therage3: yeah, it should end up as 23.976 (24000/1001) after detelecining then
[17:25:49 CET] <therage3> alexpigment: i see. i told a friend of mine who also happens to be a fan of this show, and he was surprised the publisher released this DVD as is
[17:25:57 CET] <therage3> i'm not sure if this was standard at the time
[17:26:11 CET] <alexpigment> yeah, telecined content is very common
[17:26:17 CET] <therage3> i see
[17:26:22 CET] <alexpigment> the thing is, there is no true 24fps standard for DVD
[17:26:32 CET] <alexpigment> it was always 30fps for NTSC and 25fps for PAL
[17:26:55 CET] <alexpigment> so they later started adding "pulldown flags" so that the player would play 24p as 60i
[17:27:35 CET] <alexpigment> still, many of the broadcast masters are already in 60i, so to make a true 24fps dvd, it would mean that the studio would have to go back to film masters or detelecine it themselves
[17:27:42 CET] <therage3> i see, i guess these flags were somehow embedded into the mpeg-2 stream so that the dvd player knew to do it
[17:27:51 CET] <alexpigment> when it's way simpler to just digitize the 60i tape masters
[17:27:57 CET] <therage3> o see
[17:28:02 CET] <therage3> i see*
[17:29:29 CET] <alexpigment> honestly, I don't really even mind keeping things as 60i so I don't bother detelecining
[17:29:44 CET] <alexpigment> maybe if I ever upgrade from my 60hz TV, i'll see the light ;)
[17:29:50 CET] <therage3> i don't mind it either that much, but i did kind of notice it in the show whe nwatching it
[17:29:59 CET] <therage3> but it was patently obvious when looking at static frames
[17:30:02 CET] <alexpigment> what, exactly, did you notice?
[17:30:09 CET] <therage3> let me give you a visual example
[17:30:37 CET] <alexpigment> 3:2 pulldown usually isn't noticeable on a player that's doing its job correctly
[17:30:55 CET] <therage3> https://imgur.com/a/npSUR
[17:31:13 CET] <therage3> the first frame is what maybe 3 frames look like, followed by two good ones, like the second frame
[17:31:19 CET] <therage3> that's the pattern i observed
[17:31:34 CET] <therage3> then i did googling, and what came up was "hard telecine"
[17:31:35 CET] <alexpigment> hmmm
[17:31:47 CET] <alexpigment> is your player actually deinterlacing to 60i?
[17:31:51 CET] <alexpigment> or is it doing a blend?
[17:32:02 CET] <therage3> not sure what the actual player is doing, I use vlc to play the DVD
[17:32:06 CET] <alexpigment> ahhhh
[17:32:09 CET] <alexpigment> there's your problem
[17:32:09 CET] <therage3> but these are apparently stills from the show
[17:32:21 CET] <therage3> no, no... these stills were extracted from raw mkv's
[17:32:21 CET] <alexpigment> VLC is an awful player and I wish they would get their shit together
[17:32:24 CET] <therage3> before you say anything
[17:32:24 CET] <alexpigment> right
[17:32:31 CET] <therage3> VLC didn't pull these
[17:32:32 CET] <alexpigment> but the stills were from vlc, right?
[17:32:34 CET] <alexpigment> ok
[17:32:42 CET] <therage3> no, I got them from ...... ffmpeg
[17:32:42 CET] <therage3> lol
[17:33:01 CET] <alexpigment> try getting the stills from ffmpeg with -vf yadif=1
[17:33:09 CET] <therage3> what does that do
[17:33:15 CET] <alexpigment> it deinterlaces to 60p
[17:33:27 CET] <alexpigment> which is what VLC would do if it were worth using at all
[17:33:35 CET] <therage3> i see, so it doesn't get the raw but applies a deinterlacing filter first
[17:33:48 CET] <alexpigment> well, the thing is that ffmpeg is getting a "frame"
[17:33:52 CET] <alexpigment> and there are two fields to a frame
[17:33:53 CET] <therage3> yes
[17:33:57 CET] <therage3> aha
[17:34:13 CET] <alexpigment> so if the fields are from different time stamps (they technically always are), you get a blended frame of two different time stamps
[17:34:48 CET] <therage3> right, i see
[17:34:55 CET] <alexpigment> by using -vf yadif=1, you're saying "make every field a whole frame" rather than blend fields
[17:35:01 CET] <therage3> so a frame isn't the most basic unit, but a field is
[17:35:08 CET] <alexpigment> for interlaced content, yes
[17:35:13 CET] <therage3> i see, interesting
[17:35:20 CET] <alexpigment> which is why there's so much confusion around interlaced content
[17:35:28 CET] <therage3> apparently o.O
[17:35:32 CET] <therage3> i'm learning so much lately
[17:35:34 CET] <alexpigment> on top of that, some players don't deinterlace by default, which is frankly stupid
[17:35:51 CET] <therage3> ok let me run that deinterlacing frame yank command
[17:35:54 CET] <therage3> and show you the results
[17:35:55 CET] <therage3> hold on
[17:37:35 CET] <alexpigment> k, now to be clear, if it's actually telecined, you'll still get duplicate frames, but they won't be blended. detelecining can technically reconstruct a true 23.976fps video from the 29.97i source. it uses it by blending certain fields in a particular pattern
[17:38:18 CET] <therage3> alexpigment: hah, yes, sure enough now all frames are clear, but there's a bunch that are appaerently the exact same thing
[17:38:28 CET] <alexpigment> i wasn't advocating that you don't detelecine - most people do that - i was just saying that I don't notice the pulldown enough to worry about it. i leave everything as 60i
[17:39:56 CET] <alexpigment> therage3: now about VLC. if you absolutely must use that horrible piece of garbage, go to Preferences > Video and set the deinterlacing mode to Automatic and the mdoe to Yadif (2x)
[17:40:19 CET] <therage3> alexpigment: i've been meaning to ditch VLC for a while now
[17:40:44 CET] <alexpigment> yadif(2x) is the best deinterlacing mode they have, which is passable for SD, but causes performance problems on high def content on many computers
[17:41:10 CET] <therage3> alexpigment: when i went to their channel here, and merely asked if gapless playback is supported (because i couldnt figure out how to get it running), the dev told me to do it myself because it wasnt going to happen
[17:41:20 CET] <therage3> this gives me yet another reason to ditch VLC
[17:41:29 CET] <alexpigment> yep
[17:41:46 CET] <therage3> i dont understand why it doesn't support gapless playback in this day and age
[17:41:51 CET] <therage3> it completely ruins some music albums
[17:42:07 CET] <alexpigment> well, it's technically a little advanced, but yes, other people do it
[17:42:09 CET] <alexpigment> brb
[17:42:13 CET] <therage3> ok
[19:08:00 CET] <wasilewski> hi guys, i have a text file with about 20 .m3u8 audio stream urls that I would like to download. I have tried downloading a few with FFmpeg using the -i command and it works. I'm wondering if I can use FFmpeg to download all the urls in the text file someway so I don't have to input them all individually?
[19:09:06 CET] <DHE> that's not really how ffmpeg works. a list of m3u8 files isn't something ffmpeg handles natively (or at least, properly)
[19:09:40 CET] <wasilewski> ok, thanks.....so I just have to enter them all in individually?
[19:10:42 CET] <therage3> you can use some script to automate it, i guess
[19:11:43 CET] <wasilewski> yeah
[19:13:07 CET] <wasilewski> just one more thing - am i getting the best quality by just entering ffmpeg -i "http://etc.etc" "file.mp3". ?
[19:13:53 CET] <sfan5> if those audio streams are already mp3 you can add -c copy to avoid any quality loss
[19:14:17 CET] <sfan5> if not i would suggest saving them in the original format if possible
[19:17:48 CET] <wasilewski> sfan5: i'm not sure if they are in mp3, it all comes from the m3u8 playlist....sorry if im' being stupid here
[19:18:16 CET] <sfan5> running ffprobe on one will tell you the codec in use
[19:18:21 CET] <wasilewski> would I add the -c at the start of the command? such as ffmpeg -i -c "http://etc.etc" "file.mp3". ?
[19:18:28 CET] <wasilewski> oh cool - i didn't know that thanks
[19:18:57 CET] <wasilewski> actually i'd probably put the -c after the url part.....
[19:19:08 CET] <sfan5> no, ffmpeg -i http://url -c copy output.mp3
[19:19:13 CET] <wasilewski> oh cool
[19:19:15 CET] <wasilewski> thanks
[19:19:55 CET] <wasilewski> i will use the ffprobe command too
[19:20:17 CET] <wasilewski> thanks again guys
[19:31:55 CET] <DHE> that only works if the input is mp3 itself, which seems unlikely. officially HLS only supports AAC (and maybe in newer versions, other codecs)
[19:39:36 CET] <wasilewski> OK thanks
[19:40:00 CET] <wasilewski> i will take a look later
[19:40:06 CET] <wasilewski> gotta finish making dinner
[19:40:08 CET] <wasilewski> thanks again folks
[19:40:10 CET] <wasilewski> all the best
[20:58:53 CET] <therage3> is it normal for a 30fps hard telecined NTSC DVD movie to still exhibit some telecined frames after having the default detelecine filter applied to it (when it is now 24fps)?
[20:59:42 CET] <JEEB> then whatever filter didn't do the right job, or your source has more issues
[21:00:04 CET] <therage3> that's possible, i'm analyzing the source, frame by frame, to see if it's not the standard pattern
[21:00:30 CET] <JEEB> inverse telecine has the filters fieldmatch and decimate, btw
[21:00:36 CET] <JEEB> those were ported from vapoursynth ages ago
[21:00:53 CET] <JEEB> fieldmatch does field matching and decimation does the removal of duplicates
[21:01:09 CET] <therage3> i see
[21:03:44 CET] <therage3> what's the syntax for the filter? i used ' -filter:v "detelecine" ', and i guess that uses the default parameters?
[21:04:14 CET] <sfan5> it does
[21:04:24 CET] <sfan5> reference for those is here btw http://ffmpeg.org/ffmpeg-filters.html#detelecine
[21:04:26 CET] <therage3> huh, interesting
[21:04:41 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#fieldmatch
[21:04:55 CET] <therage3> it's bizarre how it gets rid of the telecined frames in certain sequences of the movie, but not all. and the fps does go from 30 to 24
[23:03:02 CET] <alexpigment> therage3: out of curiosity, is the fps exactly 24 or is it 23.976 (24000/1001)?
[23:03:34 CET] <therage3> alexpigment: the latter (sorry if I didn't specify; I know there's some specification stuff there with MHz stuff that makes it use that odd number)
[23:03:44 CET] <alexpigment> that's fine, just wanted to check
[23:04:01 CET] <alexpigment> because ntsc telecined content would have duplicate frames every now and then if the frame rate ended up at exactly 24
[23:04:12 CET] <therage3> alexpigment: what I think is happening is that this video that I have isn't telecined in a consistent pattern
[23:04:15 CET] <alexpigment> just figured i'd ask that. i don't really have any more info on what's going on
[23:04:21 CET] <therage3> which throws the filter off and makes it miss some stuff
[23:04:25 CET] <alexpigment> ah
[23:05:05 CET] <alexpigment> well, that's a scenario where I would either leave it as interlaced (force x264 to do MBAFF interlacing), or deinterlace to 60p
[23:05:24 CET] <therage3> i just let VLC or whatever take care of it now
[23:05:33 CET] <alexpigment> k
[23:05:48 CET] <therage3> i have absolutely no idea how to deal with variably telecined footage
[23:05:57 CET] <alexpigment> neither do i ;)
[23:06:06 CET] <alexpigment> fortunately i've never dealt with that
[23:06:08 CET] <JEEB> if it's actually telecined and it's just the pattern that changes then TIVTC/fieldmatch+decimate should do it
[23:06:17 CET] <JEEB> too bad lavfi preview is not really a thing
[23:06:25 CET] <alexpigment> JEEB knows what he's talking about, so i'd trust him
[23:06:26 CET] <JEEB> (although you can test it out with something like mpv)
[23:06:46 CET] <JEEB> if it's not telecined and mixed interlacism and telecine, you will have to handle it in parts
[23:06:47 CET] <therage3> JEEB: hm i see
[23:06:54 CET] <therage3> oh dear Lord
[23:07:00 CET] <therage3> this is getting unnecessarily complicated
[23:07:03 CET] <alexpigment> yeah
[23:07:14 CET] <JEEB> therage3: you hit TIVTC+decimate at it and see if it looks skookem
[23:07:19 CET] <alexpigment> the credits are often true interlaced on otherwise-telecined content
[23:07:26 CET] <therage3> JEEB: i see
[23:07:35 CET] <JEEB> if it doesn't, time to check the fields proper
[23:07:42 CET] <JEEB> vapoursynth or avisynth recommended
[23:07:49 CET] <JEEB> they have the best preview things
[23:07:54 CET] <JEEB> with vapoursynth editor and AvsPmod
[23:07:57 CET] <therage3> oh snap avisynth ;D
[23:08:02 CET] <therage3> i once used it and my brain blew up
[23:08:46 CET] <JEEB> people tend to overcomplicate their crap
[23:09:33 CET] <therage3> i'll try that, hopefully i don't have to tweak any fields
[23:09:52 CET] <JEEB> try a check-up run with fieldmatch and decimate
[23:10:00 CET] <JEEB> that is supposed to be a dynamic IVTC thing in lavfi
[23:10:00 CET] <therage3> good call
[23:10:13 CET] <JEEB> and it's supposed to be a port of the LGPL IVTC filter in vapoursynth
[23:10:23 CET] <therage3> interesting, iirc VLC also uses that
[23:10:25 CET] <JEEB> although I think the latter got some continued development after the lavfi filter got made
[23:28:11 CET] <Cracki_> mjpeg is listed under *audio* codecs... https://ffmpeg.org/ffmpeg-codecs.html#mjpeg
[23:29:28 CET] <jfmcarreira> Heyy guys
[23:29:43 CET] <jfmcarreira> i am using this code to decode a stream using ffmpeg: http://dpaste.com/1CM1RNT
[23:30:00 CET] <jfmcarreira> but i am always getting EOF errors from av_read_frame. even on first try
[23:33:57 CET] <zyme> if the current version is 3.4, when was "ffmpeg version n2.8.11" and whats the n stand for?
[23:37:22 CET] <SortaCore> jfm: I suspect ffmpeg is in release mode?
[23:37:32 CET] <SortaCore> and debugging works best with full source code
[23:37:43 CET] <SortaCore> the PDB files may be stripped
[23:38:32 CET] <jfmcarreira> SortaCore: i know. i got ffmpeg. build it from source (using some kind of debug option in configure) then linking my app against the ffmpeg i just builed and installed in my home folder
[23:40:44 CET] <jfmcarreira> SortaCore: ./configure --prefix=/home/joaoc/.libraries --enable-debug=3 --disable-optimizations --disable-static --enable-shared --disable-stripping --disable-mmx --disable-ssse3 --extra-cflags
[23:41:32 CET] <SortaCore> should be ok then
[23:41:39 CET] <SortaCore> did you try Step Into?
[23:42:01 CET] <SortaCore> put a breakpoint just before a ffmpeg function call, then use step into command on your ide
[23:42:17 CET] <jfmcarreira> SortaCore: idk if i tried this config yet. i tried a different one with static libs
[23:42:51 CET] <jfmcarreira> `.rodata' can not be used when making a shared object; recompile with -fPIC
[23:42:56 CET] <jfmcarreira> how do i enable fpic?
[23:46:09 CET] <zash> Add it to CFLAGS
[23:47:11 CET] <durandal_1707> therage3: detelecine filter works only for fixed patterns
[23:47:29 CET] <therage3> durandal_1707: i see
[23:47:35 CET] <therage3> durandal_1707: that then does explain that
[23:47:36 CET] <JEEB> which is why I recommended the fieldmatch+decimate combo
[23:47:40 CET] <therage3> ^
[23:47:51 CET] <therage3> i'll have to do some fiddling with that as JEEB suggested
[23:48:17 CET] <therage3> but thanks, that does confirm why the plain vanilla defauly with detelecine didn't work fully
[23:48:21 CET] <therage3> default*
[23:49:05 CET] <durandal_1707> there should be telecine detection filter which detect patterns across stream
[23:49:15 CET] <alexpigment> ^^^
[23:50:40 CET] <therage3> yeah
[23:54:13 CET] <TheRock> hi guys, is there filter to detect if the video is sex movie
[23:55:17 CET] Action: therage3 raises an eyebrow
[00:00:00 CET] --- Fri Dec 1 2017
1
0