Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

November 2017

1 participants
58 discussions

ffmpeg-devel.log.20171129
by burek 30 Nov '17

30 Nov '17

[00:03:09 CET] <SortaCore> h264_qsv doesn't like ending empty packets, "h264_qsv : A decode call did not consume any data: expect more data at input (-10)" and "avcodec_send_frame failed with error -11: Resource temporarily unavailable" [00:10:55 CET] <SortaCore> but it is marked with cap delay, so it needs a null packet to flush [00:14:17 CET] <SortaCore> seems to die since a couple weeks ago and 31de45d [00:15:36 CET] <cone-097> ffmpeg 03Carl Eugen Hoyos 07master:ed4a0c7923e8: ffmpeg_opt: Constify hwaccel pointer. [00:19:23 CET] <cone-097> ffmpeg 03James Zern 07master:86cead525633: libvpxenc,vp9: add corpus-complexity option [00:39:42 CET] <whysohard> Hi guys. For years I couldn't understand. Ffmpeg is very powerful. But it cannot handle with a very simple trim case: Trim end of file.. There are several commands -ss -sseof -t... But it's not sufficient. There is a question about that: https://stackoverflow.com/questions/31862634/i-need-to-cut-mp4-videos-a-par… The solution is sooo complex. Why we dont have an easy single comma [00:42:49 CET] <SortaCore> because formats are written to be read from beginning to end? [00:43:59 CET] <whysohard> Couldn't ffmpeg read total length? [00:44:23 CET] <whysohard> It's very vital and common request... You know, almost all video have unnecessary scenes of the end. I think an average user should done easy with ffmpeg... Is this improvement so hard? [00:45:10 CET] <SortaCore> does the codec format have total length in it? [00:45:25 CET] <SortaCore> does it indicate the byte offsets of the last frames and have an index for them? [00:45:40 CET] <SortaCore> at what point from end of file and last frame minus n frames should the data be stored for? [00:46:04 CET] <SortaCore> how large are frames? fixed? compressed? keyframes, partial? [00:46:09 CET] <whysohard> Wow. I started to understand now [00:46:32 CET] <SortaCore> the formats of most are to be read from start of file to end of file [00:46:58 CET] <SortaCore> the best you can do is look for a frame start marker at a best guess from end of file - if the format has one for frames [00:47:07 CET] <SortaCore> then you have to hope it's a frame you can terminate on [00:47:26 CET] <SortaCore> otherwise you may have to rearrange due to gop size [00:47:42 CET] <whysohard> Thank you SortaCore. You're great pathfinder [00:47:55 CET] <SortaCore> plus there's the complication that even if the file stores duration in the header, as in time, that will need recalculating [00:48:05 CET] <SortaCore> and sometimes frames are decoded and stay on screen longer than previous frames [00:48:14 CET] <SortaCore> so... basically it's super annoyingly complex [00:48:30 CET] <SortaCore> you might be able to find a format that's well-equipped for trimming from end, though [00:48:50 CET] <SortaCore> and increasing number of keyframes makes seeking to a particular time easier, so logically seeking from end would be easier too [00:49:09 CET] <whysohard> Therefore we need to have ffprobe.. [00:49:17 CET] <SortaCore> yea [00:49:29 CET] <SortaCore> actually, there's a thing called steganography that exploits footer/header formats [00:49:35 CET] <whysohard> For years I never understand. Now it's so clear. [00:49:41 CET] <SortaCore> you can append a zip file to a bmp file [00:49:53 CET] <SortaCore> a zip file stores its details in the end, a bmp in the start [00:50:05 CET] <SortaCore> so you can read both by just renaming the extension [00:52:19 CET] <whysohard> Yes I tried now. Thank you very much SortaCore [00:52:27 CET] <SortaCore> most video file formats are compressed, so frame byte size varies - some have varying levels of compression, so varies again - most have partial frames only showing what's changed since the last full frame... [00:52:42 CET] <SortaCore> np, it's just you've asked this a lot [00:52:53 CET] <SortaCore> it's more complicated that I'm making out - I'm not even a ffmpeg developer [00:52:54 CET] <iive> SortaCore: cutting at the end is easier that cutting from the start [00:53:17 CET] <SortaCore> now you've just confused him again [00:53:21 CET] <iive> especially if yo do stream copy (not reencoding) [00:53:24 CET] <whysohard> Haha [00:53:47 CET] <iive> yeh [00:53:58 CET] <jdarnley> > Is this improvement so hard? [00:54:08 CET] <SortaCore> y'all should improve it [00:54:10 CET] <jdarnley> Why don't you try it? [00:54:15 CET] <SortaCore> negative start time let's go [00:54:58 CET] <whysohard> Wait a minute. How works sseof command? IF It can easily crop from the end, why we don't "cut out".... (Sorry for my english, I hope you understand) [00:59:13 CET] <SortaCore> why does h264_qsv fuss when you pass null packet to flush the stream? [01:00:18 CET] <JEEB> someone overlooked that thing most likely [01:00:59 CET] <SortaCore> I'm 70% sure it was a bug added in last couple of weeks' commits [01:01:15 CET] <JEEB> alright, oppan bisect time then [01:01:35 CET] <JEEB> I've got my own weird fixations that I need to take care of unfortunately [01:01:43 CET] <JEEB> or you find the maintainer and poke that person [01:01:56 CET] <JEEB> although if you want to be helpful a bisect is always nice [01:01:56 CET] <SortaCore> how do you check the commits for qsv changes? [01:02:19 CET] <SortaCore> I don't have a link for that, and because I messed with patching I don't know the commit hash for the working one [01:03:17 CET] <JEEB> I usually use gitk as that's the least insane graphical UI for git that doesn't try to do Various Things (`gitk -- libavcodec/stuff*.c`) [01:03:27 CET] <JEEB> git log can do it on command line in a similar manner [01:03:48 CET] <JEEB> and github/git.videolan.org has history for specific files [01:04:00 CET] <JEEB> if something spans multiple files it gets less simple though [01:04:38 CET] <JEEB> that will leave out any other generic changes that happen to hit an issue with the qsv thing [01:05:04 CET] <whysohard> Sorry to interrupt, what happen now? Should I write a request to bugtrack? Is this development (a new command to delete X seconds from the end) possible or impossible? [01:06:05 CET] <JEEB> whysohard: if it's a generic "X seconds before end" ffmpeg.c and raw lavf can't do it [01:06:14 CET] <JEEB> if you have a specific timestamp that is possible [01:07:02 CET] <JEEB> for specifics like that I recommend something like ffms2 that indexes files before hand (it uses lavf underneath). of course requires decoding and encoding, so copying is not possible [01:07:37 CET] <JEEB> ffmpeg.c and lavf work purely A->B and you can only know a duration if the file format you're dealing with has such data in it [01:07:59 CET] <JEEB> so with something like mpeg-ts you are bound to get derps [01:08:06 CET] <JEEB> because ffmpeg.c will try to guess [01:08:14 CET] <JEEB> or closer to home, stuff like raw mp3 files [01:08:54 CET] <JEEB> you can request a feature of following the guessed duration blindly, but I bet people will then file bug reports when the value is guessed [01:09:24 CET] <whysohard> Haha you're right. [01:09:44 CET] <JEEB> not that it's impossible to index stuff like ffms2 does and do stream copy [01:09:54 CET] <JEEB> it's just that ffmpeg.c is not an indexing tool [01:10:33 CET] <whysohard> Thanks a lot JEEB. I really learn the real reasons. [01:11:07 CET] <JEEB> you could make a tool on top of lavf/lavc for such cutting, of course [01:11:19 CET] <JEEB> it would index first, then let you do stuff [01:11:43 CET] <JEEB> that way it wouldn't make ffmpeg.c even a bigger badonkadonk than it currently is :) [01:11:57 CET] <JEEB> and people would get their expected results since the files would be indexed [01:12:09 CET] <JEEB> someone just needs to care.jpg [01:12:23 CET] <whysohard> Hahah [01:12:41 CET] <SortaCore> I think jamrial is the culprit? [01:13:05 CET] <SortaCore> he changed error returns in qsv [01:13:16 CET] <JEEB> vOv [01:13:46 CET] <JEEB> of course the actual error might be in some vaguely related place which was hidden before, not that I've looked at the context [01:14:06 CET] <JEEB> and it doesn't mean that it shouldn't be fixed. just that the fix isn't always "revert it" :) [01:14:13 CET] <SortaCore> I'll dig some more [01:14:29 CET] <SortaCore> I suspect the changes are fine there's just exception for flushing [01:14:39 CET] <SortaCore> expecting more data is fine when not flushing, after all [01:15:11 CET] <whysohard> JEEB: Thank you for your valuable comments. I wish everyone could read it. I totally understand what it is. Thank you so much. [01:15:28 CET] <JEEB> whysohard: so you were asking for "-20 seconds from the end" kind of thing? [01:15:32 CET] <JEEB> which is the hard thing [01:15:50 CET] <whysohard> Yep.. [01:15:53 CET] <JEEB> yup [01:16:17 CET] <tmm1> SortaCore: did you figure out how to fix those random device failed errors? [01:16:17 CET] <JEEB> the simple thing is "continue until X seconds/minutes/hours" because you can just keep on rolling until you hit the timestamp [01:16:30 CET] <SortaCore> Not yet, it seems to be a matter of timing [01:16:45 CET] <SortaCore> my app can sometimes run too slowly and get it upset [01:17:06 CET] <SortaCore> having said that, I've not experienced it since the last master update, either [01:17:23 CET] <SortaCore> err, *last git pull [01:18:50 CET] <whysohard> Ignorance is bliss... For years I think it's very very easy, just a developer writes 3-5 lines and the problem is solved [01:19:48 CET] <JEEB> whysohard: if you don't care about the details (making it properly work) it would be something like that :P and it would work with at least a couple of file formats [01:20:05 CET] <SortaCore> whysohard that does imply either no one needs it, or not enough people need it for ffmpeg guys to develop it [01:21:50 CET] <whysohard> Yes I see. You have serious responsibilities. There must always be situations that need to work.. Thank you guys again. Time to go for me. I hope anyone can search and find tese information from logged chat text [01:22:21 CET] <SortaCore> you could post on codeproject site [01:22:33 CET] <SortaCore> *stackoverflow [01:28:25 CET] <SortaCore> err JEEB when did you help me with patches? [01:28:43 CET] <SortaCore> I can use that for filtering the commits [01:34:10 CET] <SortaCore> could AV_CODEC_CAP_AVOID_PROBING have a change on the flush? [01:40:41 CET] <SortaCore> I'm gonna jump in the call stack and see what line makes the error [02:14:24 CET] <SortaCore> err... wot [02:16:18 CET] <SortaCore> rtsp demuxer is avcodec_receive_frame() a YUV420P frame straight into a NV12 AVFrame [02:18:20 CET] <SortaCore> are you meant to be able to do that? [02:55:00 CET] <atomnuker> oh wow, the ML broke the jan 2016 record and now it has the most emails since oct 2015 (which had 2700) [02:55:45 CET] <SortaCore> admit it I carried you all [02:55:54 CET] <SortaCore> (no but seriously what's up with NV12) [03:14:18 CET] <raytiley_> i'm messing around with ffmpeg to generate HLS from a deckling card using dshow. I think i'm seeing the bitrit of the files grow if the decklink card doesn't get video for a while and x264 is encoding black frames... the output is still working ok.. the files are just oo big [03:14:25 CET] <raytiley_> does that make sense? [03:17:16 CET] <raytiley_> `-c:v libx264 -x264opts keyint=60:no-scenecut -s 416x234 -r 29.97 -b:v 200k -preset ultrafast -profile:v main -level 3.0 -pix_fmt yuv420p -y -c:a aac -ar 48000 -hls_list_size 5 out.ts` is the output part of the command i'm using [03:20:19 CET] <raytiley_> oops wrong channel, sorry [03:34:54 CET] <SortaCore> I shall afk and hope someone answers by tomorrow [04:47:57 CET] <cone-178> ffmpeg 03Dale Curtis 07master:a3a0b5bd0aaa: avformat/oggparseopus: Free opus extradata before reallocating. [04:52:53 CET] <cone-178> ffmpeg 03Dale Curtis 07master:c5fd57f483d2: Don't manipulate duration when it's AV_NOPTS_VALUE. [05:42:44 CET] <atomnuker> michaelni: what does need to be atomic when registering filters [05:43:30 CET] <atomnuker> as far as I see, **f points to a place in an array and writing to that array needs to be atomic, right (e.g. *f = filter_next) [07:00:34 CET] <stevenliu> Hello guys? [07:00:44 CET] <stevenliu> https://patchwork.ffmpeg.org/patch/6244/ can this patch be pushed? [07:33:33 CET] <cone-178> ffmpeg 03Jeyapal, Karthick 07master:62f63b24bfec: libavformat/avio: Utility function to return URLContext [07:33:34 CET] <cone-178> ffmpeg 03Jeyapal, Karthick 07master:4ddf7476c009: libavformat/http: Handled multiple_requests option during write [07:33:35 CET] <cone-178> ffmpeg 03Jeyapal, Karthick 07master:815e34b5b4ed: libavformat/hlsenc: Persistent HTTP connections supported as an option [07:39:26 CET] <atomnuker> stevenliu: no, the function needs to start with ff_io rather than ffio_ or whatever [07:46:50 CET] <stevenliu> ...... [07:47:34 CET] <atomnuker> well its for consistency reasons, all around the code all functions start with ff_<stuff> rather than ff<stuff> [07:48:46 CET] <atomnuker> oh wait, nervermind, ffio stuff is excluded [07:49:22 CET] <stevenliu> libavformat/aviobuf.c there have samples api name: ffio_ensure_seekback [07:50:04 CET] <stevenliu> so the name maybe reference the ffio_ensure_seekback , so he make the name "ffio_geturlcontext" [07:50:20 CET] <stevenliu> ok [07:50:40 CET] <stevenliu> Thanks :D [09:50:57 CET] <atomnuker> is there some ptwo fft which needs avx2? [10:53:48 CET] <cone-040> ffmpeg 03Pan Bian 07master:eb69e7bed80a: avcodec/nvenc: set correct error code [12:45:27 CET] <cone-040> ffmpeg 03Karthick J 07master:da49cdf6401e: avformat/hlsenc: Modularized playlist creation to allow reuse [14:34:49 CET] <SortaCore> best codec? [14:36:40 CET] <thardin> cinepak [14:43:39 CET] <SortaCore> motion carries [14:43:45 CET] <SortaCore> all other codecs are now outlawed [14:44:45 CET] <thardin> hooray! [14:45:30 CET] <SortaCore> on a vote of 1 to 0 with abstaining [15:13:31 CET] <ubitux> anyone has a 1:1 pixel filter in mind in the codebase that's not component based (that is, that can not be solved with a lut3d)? [15:13:36 CET] <ubitux> other than... lut3d [15:13:59 CET] <ubitux> i'd say filters like colormatrix but i'm looking for something more "shiny"/visible [15:14:18 CET] <ubitux> s/can not be solved with a lut3d/can not be solved with a lut *2D*/ [15:14:23 CET] <ubitux> (but can with a lut3d) [15:14:49 CET] <ubitux> mmh, maybe selectivecolor could do the trick [15:24:39 CET] <atomnuker> ubitux: yeah, many, but they can all be solved by convolve [15:28:02 CET] <durandal_1707> glitch filters [15:55:50 CET] <Compn> ehe [15:56:07 CET] <Compn> i think my reply to jim delahunt will fix some things... [16:33:21 CET] <BBB> wm4: about that patch, I think jamrial sent that a while ago also, if we remove the parser (or splitting in the parser) Im fine with it [16:33:35 CET] <BBB> wm4: if we keep the splitting in the parser, I feel were doing redundant operations which is silly [16:33:40 CET] <jamrial> i didn't send it [16:33:43 CET] <BBB> hm [16:33:44 CET] <BBB> someone did [16:33:58 CET] <wm4> BBB: I can certainly disable the parser in the mkv demuxer [16:34:11 CET] <wm4> I'm using vp9 without parser in my own mkv demuxer too (now) [16:34:11 CET] <BBB> I meant disable the splitting in the parser [16:34:21 CET] <wm4> hm [16:34:25 CET] <BBB> the parser could still be useful for identifying keyframes etc. [16:34:36 CET] <BBB> I dont know if that makes sense [16:34:43 CET] <BBB> remove the parser altogether is fine also IMO [16:34:52 CET] <BBB> but it might be useful for some fringe scenarios (?) [16:34:58 CET] <wm4> I think while we still have both BSFs and parsers, we can't create anything logically clean anyway [16:35:15 CET] <wm4> I think in the end we'll probably remove all parsers for BSFs? [16:35:28 CET] <wm4> in 20 years or so [16:35:31 CET] <BBB> :-p [16:36:17 CET] <jamrial> just remove/disable the splitting part from the parser [16:36:27 CET] <jamrial> but yeah, i think the idea was for that kind of manipuation to be done in bsfs and leave the parsers for simpler stuff, so the parser api can be replaced by an avpacket based one [16:36:36 CET] <jamrial> eventually(tm) [16:36:51 CET] <BBB> I wonder if you can just remove the whole parser [16:36:55 CET] <BBB> I dont think it does anything else [16:36:58 CET] <BBB> maybe keyframe identification [16:37:15 CET] <jamrial> it does that, yeah [16:37:24 CET] <BBB> I think all you need to keep is the top half of parse-frame [16:37:27 CET] <BBB> parse_frame() [16:37:31 CET] <wm4> raw video? [16:37:47 CET] <BBB> the bottom half (pts mangling) can be removed, including reading the invisible bit [16:37:56 CET] <BBB> and parse itself can just call parse_frame() and return [16:38:08 CET] <BBB> then patch is fine with me (assuming this doesnt break anything) [16:38:22 CET] <wm4> according to mkvdec we parse all video streams, even h264, except hevc (???) [16:38:49 CET] <wm4> BBB: you mean patch is fine as is? [16:39:05 CET] <BBB> delete most of vp9_parser.c [16:39:07 CET] <BBB> then its fine [16:39:58 CET] <nevcairiel> mkvdec used to exclude h264 as well some time ago, but someone probably found some broken mkv that got fixed by it, not that the parser really does anything on frames that are in mp4-style syntax [16:40:00 CET] <BBB> if you dont delete vp9_parser.c splitting, a problem is that I will never call that splitting code in the BSF, because the parser splits for my uses, so my code coverage becomes different from yours, which complicates bug fixing/finding [16:40:10 CET] <BBB> thats why Im asking to delete the splitting from vp9_parser.c [16:40:16 CET] <BBB> it makes my life easier when you find bugs [16:40:43 CET] <wm4> why is ffmpeg's policy "eat shit" [16:41:01 CET] <BBB> huh? [16:41:02 CET] <wm4> (except for subtitle encodings, because of nicolas george) [16:41:28 CET] <wm4> regarding attempting to read every broken file (but also in broader aspects) [16:42:05 CET] <wm4> BBB: so, remind me how the parser works... does it make extra effort to separate out superframes? [16:42:11 CET] <BBB> ys [16:42:12 CET] <BBB> yes [16:42:26 CET] <BBB> http://ffmpeg.org/doxygen/trunk/vp9__parser_8c_source.html [16:42:40 CET] <BBB> delete line 64-72 [16:43:06 CET] <BBB> delete line 116-161 [16:43:26 CET] <BBB> and I think you can delete VP9ParserContext entirely, and all behaviour stemming from that [16:43:42 CET] <BBB> like line 92-114 [16:44:07 CET] <nevcairiel> the entire parse function should basically be emptied and replaced by parse_frame [16:44:15 CET] <BBB> so youre left with half of parse_frame(), line 85-90, line 162-165 [16:44:20 CET] <BBB> yes, basically [16:44:30 CET] <BBB> it becomes an extremely stupid simple little parser that detects keyframes [16:44:36 CET] <nevcairiel> although i dont know if parse_frame needs to be updated to handle super frames [16:44:41 CET] <BBB> so you can remux ivf (which has no keyframe markers) into avi (which does) [16:44:47 CET] <nevcairiel> since those apparently have a prefix marker [16:44:51 CET] <BBB> no, keyframes are never in superframes [16:44:55 CET] <nevcairiel> oh wait its a postfix marker [16:44:57 CET] <BBB> and the marker is at the end [16:44:59 CET] <BBB> so its fine [16:45:12 CET] <nevcairiel> sounds good then [16:45:21 CET] <BBB> :) [16:46:22 CET] <wm4> it's not clear to me where it reads the frame size [16:47:39 CET] <nevcairiel> all sources of vp9 come from properly packeted formats, so packet size = frame size [16:48:11 CET] <wm4> so it's not possible to parse a concatenated byte stream, and the parser can't eat that? [16:48:20 CET] <nevcairiel> no [16:48:25 CET] <wm4> great [16:48:35 CET] <nevcairiel> thats why ivf exists, a super lightweight container that has packet sizes for you [16:48:50 CET] <wm4> yeah I think I remember about this [16:48:57 CET] <wm4> that makes it indeed very trivial [16:49:59 CET] <kierank> wm4: welcome back [16:50:41 CET] <BBB> have you guys confirmed that frame-mt works correctly with the bsf? I have no doubt that it does but just to make sure [16:52:11 CET] <wm4> I mean it looks non-corrupted [16:55:37 CET] <wm4> kierank: sort of [16:57:33 CET] <wm4> BtbN: would you be against moving cuda headers to an external repo? [16:57:56 CET] <wm4> is fate-source failing in git master [16:58:24 CET] <BtbN> wm4, not a fan of it at least. [16:58:37 CET] <durandal_1707> where is it failing ? [16:58:59 CET] <BtbN> And so far it only seems to be one person on the ML who is actually strongly against the headers? [16:59:00 CET] <nevcairiel> yean fate-source seems broken since that recent hls commit [16:59:01 CET] <jamrial> libavformat/hlsplaylist.h [16:59:05 CET] <wm4> why do we even have this useless test [16:59:09 CET] <wm4> oh right, because of michaelni [16:59:27 CET] <jamrial> to find missing header wrappers, for example [16:59:28 CET] <nevcairiel> it wouldnt be so useless if people were to actually run it before pushing to find their mistakes =p [16:59:44 CET] <wm4> pretty hilarious... 1 hour of having returned and I already hit multiple things that made me leave before [17:00:18 CET] <jamrial> a grep test on headers is the last thing that should make people angry, imo :p [17:00:38 CET] <wm4> I don't even know why the test fails [17:00:50 CET] <wm4> that would mean digging into fate's shitty sources and probably inspecting some horrible regexp [17:00:58 CET] <durandal_1707> every header should have copyright and license [17:00:59 CET] <nevcairiel> because that header there has wrong include guards [17:01:03 CET] <nevcairiel> or license [17:01:05 CET] <nevcairiel> one of those [17:01:21 CET] <wm4> the license looks correct [17:01:36 CET] <wm4> except it has the name of a TRAITOR (as cehoyos would put it) in it [17:01:45 CET] <nevcairiel> the include guard is wrong [17:01:47 CET] <jamrial> it's the wrapper [17:01:49 CET] <nevcairiel> has an extra _ at the end [17:01:50 CET] <wm4> correction, a LIAR AND TRAITOR [17:01:51 CET] <jamrial> yeah [17:01:57 CET] <wm4> (add mouth foam) [17:02:30 CET] <kierank> wm4: it's actually liars and thieves [17:02:33 CET] <kierank> get it right [17:03:01 CET] <wm4> oh right [17:03:10 CET] <wm4> my error [17:03:22 CET] <cone-254> ffmpeg 03James Almer 07master:85b84e124330: avformat/hlsplaylist: fix header include guard [17:04:03 CET] <jamrial> meh, it's also missing a lot of inlcude headers, like avio.h [17:04:10 CET] <jamrial> checkheaders will fail as is [17:04:18 CET] <nevcairiel> luckily fate doesnt run that =p [17:04:40 CET] <jamrial> ubitux has one client running it :p [17:04:47 CET] <jamrial> but yeah, it's not part of make fate [17:04:57 CET] <jamrial> but it is part of make check [17:05:28 CET] <jamrial> i think a libav commit tried to add it to make fate but i sort of skipped it [17:06:22 CET] <wm4> poor AMD person [17:06:40 CET] <wm4> BBB: nice, fate passes with the parser change [17:06:52 CET] <BBB> tests are awesome! \o/ [17:07:23 CET] <jkqxz> checkheaders is not part of make check in ffmpeg. (I've been caught out by thinking it was.) [17:07:28 CET] <jkqxz> It probably should be. [17:07:53 CET] <jkqxz> (And everyone should run "make check" before pushing, y'know.) [17:07:54 CET] <jamrial> jkqxz: as i said, i think i didn't merge that. but i can look into it if you want [17:08:56 CET] <wm4> BBB, jamrial: parser change sent [17:09:21 CET] <BBB> I thought you said it failed fate? [17:09:25 CET] <BBB> or was it a typo? [17:09:30 CET] <BBB> oh wait [17:09:30 CET] <BBB> duh [17:09:32 CET] <BBB> I cant read [17:09:35 CET] <wm4> no it failed for this hls thing [17:09:35 CET] <nevcairiel> lol [17:09:42 CET] <cone-254> ffmpeg 03James Almer 07master:91127355f586: avformat/hlsplaylist: add missing header includes [17:09:50 CET] <jkqxz> wm4: The AMD support is already autodetected. (If you have the headers.) [17:10:11 CET] <BBB> Id better become a manager quickly or else my career is going downhill from here [17:10:51 CET] <nevcairiel> any feature without a fixed runtime linkage dependency can realistically just auto-enable if headers are available, with linking it should preferably not, imho [17:11:11 CET] <BBB> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/thread.html ??? [17:11:13 CET] <BBB> how did that happen [17:11:32 CET] <nevcairiel> intel lives in the future [17:11:33 CET] <iive> intel have time machine [17:11:33 CET] <wm4> it wasn't me [17:11:42 CET] <jamrial> he blew his cover and now we know he's from the future [17:11:45 CET] <wm4> maybe it thinks it was february [17:11:47 CET] <nevcairiel> it just takes the emails date, not receiving date [17:12:00 CET] <BBB> I wish I was as smart as intel [17:12:01 CET] <nevcairiel> and email date is specified by the sneder [17:12:21 CET] <wm4> I should randomize my email dates [17:12:50 CET] <nevcairiel> just dont have it way in the past, or your mail may get sorted on page 128 of my inbox [17:13:21 CET] <BtbN> Is anyone against me creating a repository on the github FFmpeg organization for the nvidia-video-sdk headers? And what would be a good name for it? I'm thinking of just nvidia-sdk, but that might be a copyright issue? [17:13:38 CET] <wm4> BtbN: I think that'd be great... [17:13:39 CET] <jamrial> ffnvidia [17:13:44 CET] <BtbN> nah [17:13:53 CET] <wm4> not sure if it should be nvidia specific or just a collection repo where we dump crap [17:14:10 CET] <wm4> (for avisynth too) [17:14:12 CET] <jkqxz> nevcairiel: Lots of features with linking are auto-enabled. I agree they probably shouldn't (because it has surprise dependency on the build machine), but there is a lot of inertia and me-too for it. [17:14:23 CET] <nevcairiel> ffmpeg-contrib-headers [17:14:24 CET] <nevcairiel> no idea [17:14:45 CET] <nevcairiel> jkqxz: luckily ubitux made us an option to disable all autodetected crap now [17:15:07 CET] <wm4> is ffcuda still auto enabled on osx? [17:15:08 CET] <nevcairiel> oss projects configure and build systems are never designed for portable binaries [17:15:14 CET] <BtbN> I'd kind of like to keep them seperate, and give the nvidia headers a proper Makefile and pkg-config [17:15:21 CET] <jamrial> autodetect right now is only for "system" libraries and hardware stuff [17:15:21 CET] <wm4> BtbN: fine [17:15:28 CET] <BtbN> As they can indeed by usefull for non-ff projects [17:15:30 CET] <nevcairiel> why a makefile, its not like it needs to build anything [17:15:35 CET] <ubitux> wm4: it shouldn't with --disable-autodetect [17:15:36 CET] <BtbN> Just for make install [17:16:43 CET] <jamrial> wm4: make sure to remove the stray hls change before pushing the vp9 parser change :p [17:16:55 CET] <jamrial> i'll leave the real review to BBB [17:16:57 CET] <nevcairiel> jamrial: on osx it pulls in a whole lot of shit with relatively high os version requirements tho [17:17:31 CET] <BBB> wm4: lgtm [17:17:32 CET] <BBB> tnx [17:17:37 CET] <wm4> jamrial: oh damn, I intended to remove it by rebasing but forgot that [17:18:19 CET] <jamrial> nevcairiel: the videotoolbox and avfoundation stuff? [17:18:35 CET] <wm4> jamrial: also ok? [17:18:44 CET] <wm4> for the vp9 patches [17:18:54 CET] <nevcairiel> jamrial: all sorts of frameworks get pulled in from all of those, mostly avfoundation i guess [17:19:05 CET] <jamrial> wm4: yeah [17:19:49 CET] <BtbN> Anyone against FFNV-Video-SDK? That avoids having nvidia in there, which could cause issues with name trademarks. [17:20:13 CET] <cone-254> ffmpeg 03wm4 07master:a5679933c1b8: vp9: use superframe split BSF [17:20:14 CET] <cone-254> ffmpeg 03wm4 07master:0c162854c1fa: vp9_parser: don't split superframes into separate packets [17:20:28 CET] <jamrial> with this there's no way to mux split vp9 packets on matroska/mp4 by accident anymore, so maybe the autobsf on muxer level can remain optional [17:20:29 CET] <atomnuker> BtbN: ffmpeg-contrib-headers + a configure/make file to specify which headers to install then? [17:20:45 CET] <iive> BtbN: if it is only headers, then it would be good to have "headers" in the name. [17:20:56 CET] <BtbN> iive, well, the video codec SDK is only headers. [17:21:21 CET] <nevcairiel> the official sdk download is a whole bunch of docs and example apps [17:21:25 CET] <iive> BtbN: sdk could include libraries, documentation and examples [17:21:34 CET] <jamrial> also, as atomnuker and nevcairiel said, is it going to be for nvidia headers only, or for all? (amd, nvidia, avisynth) [17:21:48 CET] <atomnuker> I'd like one for all [17:21:52 CET] <BtbN> atomnuker, I'd really prefer to keep them seperate, as distributions will need to package them, and a meta-thing with a bunch of unrelated stuff might cause issues [17:22:09 CET] <durandal_1707> we could include ladspa and libmysofa header [17:22:17 CET] <jkqxz> Basically everyone else already has a proper repository for their headers. [17:22:25 CET] <nevcairiel> personally i would prefer one for all, we dont want to create 100 repos for all sorts of crap [17:22:44 CET] <atomnuker> because who's going to package the avisynth headers [17:22:48 CET] <BtbN> Specially with nvidia, there could be a reason to build with an older version of that header, since it keeps compatiblity with old drivers [17:22:53 CET] <jkqxz> So I think this is just nvidia, though it could be the avisynth ones as well. [17:23:04 CET] <jamrial> durandal_1707: no, such libraries are not dinamically loaded, nor part of a normal system [17:23:06 CET] <nevcairiel> its not like ffmpeg works with older headers [17:23:10 CET] <BtbN> So if you have all of them in one repo, you cannot just downgrade the nvidia headers without jumping through some hoops [17:23:28 CET] <BtbN> Well, with the next bump and the headers being external, I'd certainly try to keep compatiblity. [17:23:41 CET] <iive> BtbN: what is the full name of the sdk and full name of the "technology" used? [17:23:52 CET] <BtbN> Video-Codec-SDK [17:23:58 CET] <jkqxz> nevcairiel: That's only because the headers were packaged so you had to use a particular version. (One of the problems with packaging the headers.) [17:24:19 CET] <nevcairiel> iive: https://developer.nvidia.com/nvidia-video-codec-sdk [17:24:21 CET] <iive> BtbN: but it is about gpu video, right? [17:24:33 CET] <BtbN> It's about the video codec stuff on nvidia cards. [17:24:34 CET] <philipl> Although I really want to keep the headers in tree, if we have to move them out, can we at least set up a submodule to pull them in? [17:25:01 CET] <iive> BtbN: how about "NVCodec-headers" ? [17:25:44 CET] <BtbN> The headers are the full SDK. There's not more to it. Only docs and examples are missing pretty much [17:26:37 CET] <philipl> BtbN: If you pull them in as a submodule, you specify which hash in the external repo to use, so we could keep the tight coupling and avoid compatibility games. [17:26:59 CET] <BtbN> I'm pretty sure making them a submodule won't find any acceptance. [17:27:17 CET] <wm4> submodules suck too much [17:27:18 CET] <philipl> submodules can be left uninitialised so it doesn't force inclusion. [17:27:27 CET] <philipl> This might be the one place where a submodule is actually useful [17:27:32 CET] <atomnuker> BtbN: --enable-cuda-header-vN which makes the makefile apply a patch? [17:27:34 CET] <nevcairiel> submodules dont solve anything, then everyone still wants the same treatment because unfair [17:28:11 CET] <nevcairiel> and you still need a commit in ffmpeg when they get updated, so might as well keep them itnernal [17:28:31 CET] <philipl> I did say I was in favour of keeping them internal :-) [17:28:47 CET] <BtbN> atomnuker, what? [17:31:07 CET] <BtbN> I don't see what the advantage of an external repository for contrib headers is, over having them in-tree. [17:32:13 CET] <wm4> do you want all the AMD headers in tree? and probably more such cases to come? [17:34:04 CET] <BtbN> I'd like to have them in proper repositories for themselves. Ideally in one made and maintained by AMD. [17:34:27 CET] <atomnuker> how about they distribute the damn headers with their binaries? [17:34:53 CET] <BtbN> The drivers? Unlikely to happen. Nobody would package them. [17:35:42 CET] <atomnuker> I mean e.g. the nvidia binary driver to also install a cuvid header [17:35:57 CET] <atomnuker> distros package the binary drivers [17:36:36 CET] <atomnuker> thinking about it the kernel people have a very similar problem [17:37:00 CET] <atomnuker> to run the proprietary blobs nvidia ship a wrapper which is a kernel module [17:37:08 CET] <atomnuker> which users need to compile themselves [17:37:40 CET] <atomnuker> which breaks pretty much on every new kernel release because more and more symbols get flagged as gpl [17:37:53 CET] <BtbN> In most cases, the one building ffmpeg is not the one running it and having an nvidia card. [17:38:10 CET] <atomnuker> oh, right [17:38:23 CET] <BtbN> So if you'd have to download a whole 500MB driver just to get those headers, that'd be definitely not nice [17:41:12 CET] <wm4> yeah but you just need to extract them and out them into a git or so [17:41:17 CET] <wm4> no custom changes [17:41:30 CET] <iive> that's what he is going to do [17:41:39 CET] <iive> we are just looking for a nice name of the repo [17:42:13 CET] <iive> BtbN: so, would you be happy with "nvcodec-sdk-headers" ? [17:42:47 CET] <BtbN> No, because only calling it headers is missleading. It is the whole SDK, everything you need to develope with their APIs [17:43:00 CET] <nevcairiel> its not misleading, it only contains headers [17:43:15 CET] <nevcairiel> an SDK is more then headers, its docs and examples [17:43:26 CET] <iive> BtbN: so you are oging to put documentation there? [17:43:37 CET] <nevcairiel> calling it just "sdk" i would expect all the extra stuff besides headers to also be included [17:44:08 CET] <philipl> Are we including the dynlink cuda stuff in this discussion? that's not nvidia code - BtbN wrote it [17:44:09 CET] <BtbN> I cannot create repositories anyway, so do whatever [17:44:55 CET] <iive> BtbN: i thought you are making github one [17:45:08 CET] <BtbN> like I said, I can't create repositories. [17:46:01 CET] <nevcairiel> at least you're part of the organization, so you're closer then anyone =p [17:46:39 CET] <iive> sorry, I thought everybody could create a repo in github. What am I missing? [17:47:02 CET] <nevcairiel> its supposed to be part of the ffmpeg org [17:47:04 CET] <BtbN> No idea who has enough access to create a new repository, I guess michaelni? [17:47:19 CET] <jamrial> iive: he means a new repo in github.com/FFmpeg [17:47:35 CET] <iive> oh [17:48:04 CET] <jamrial> IMO it should be added to source.ffmpeg.org first, and mirrored in github [17:48:18 CET] <wm4> yeah [17:48:51 CET] <BtbN> Isn't videolan slowly moving away from that anyway? [17:48:55 CET] <BtbN> To their own gitlab [17:49:09 CET] <j-b> nope, we have both [17:49:31 CET] <j-b> gitlab is just a good replacement for wiki+bugtracker+git+usermanagement for all projects [17:49:40 CET] <j-b> like libdvdcss or libdvdread or the mobile version [17:49:50 CET] <j-b> github is just a mirror, because it is not open source [17:53:19 CET] <BtbN> I don't know. I'd be fine with maintaining that on github. [18:16:33 CET] <jamrial> jkqxz: where are the amd headers currently hosted, btw? [18:16:56 CET] <BtbN> On their github [18:17:15 CET] <BtbN> But the repo is kinda messed up, and included half of ffmpeg or something [18:21:43 CET] <jamrial> amfenc.c includes config.h too late :/ [18:28:28 CET] <cone-254> ffmpeg 03James Almer 07master:a198c1386a4f: avcodec/amfenc: move config.h include where it's needed [18:28:38 CET] <wm4> oh it got merged already? [18:28:51 CET] <jamrial> without the headers in tree, yeah [18:40:10 CET] <jkqxz> jamrial: <https://github.com/GPUOpen-LibrariesAndSDKs/AMF>; "cp -a amf/public/include /usr/local/include/AMF". [18:42:40 CET] <jamrial> jkqxz: https://pastebin.com/PpEZH2dh i thought this was using loadlibrary [18:44:01 CET] <jkqxz> The AMD headers are not very C-compatible. You need to build with optimisations so that everything marked inline is actually inlined. [18:45:10 CET] <jkqxz> (There are non-static inline functions with no out-of-line implementation. They should all be static.) [18:46:34 CET] <jamrial> then shouldn't the headers be fixed? [18:47:02 CET] <jkqxz> Yes. [18:47:36 CET] <jkqxz> The submitter fixed some bits, but there are more. [18:57:18 CET] <wm4> if the author is willing to fix them and acts on requests, everything is ok [18:57:42 CET] <jamrial> 100% cpu usage, 20% gpu encode unit usage... [18:58:36 CET] <jamrial> 25fps for a 1080p h264 stream [18:59:11 CET] <atomnuker> if only vaapi was available under windows, eh? [18:59:20 CET] <jamrial> lets try a different input sample. maybe h264 lossless as input is not a good idea [19:01:28 CET] <nevcairiel> could test with d3d11 input for all the fancyness [19:01:34 CET] <jkqxz> If you have Windows 10 you should be able to do "-hwaccel d3d11va -hwaccel_output_format d3d11 -i whatever -c:v h264_amf". [19:01:40 CET] <jkqxz> Yeah, that :P [19:02:33 CET] <jamrial> 60% cpu, 100% gpu encode unit using a blu ray h264 stream as input. 80 fps [19:02:48 CET] <jamrial> and ok, lets try d3d11 :p [19:04:11 CET] <jamrial> still ~80fps, but now ~0% cpu usage and full gpu encode and decode unit usage [19:04:57 CET] <jamrial> this using a first gen GCN card [19:05:35 CET] <iive> amd [19:07:07 CET] <jkqxz> I didn't get particularly impressive numbers either (1080p60 or so). That was a low-end GCN 2 card. [19:07:32 CET] <nevcairiel> amds video engine isnt particularly good in comparison to nvidia and intel [19:07:40 CET] <jamrial> HD 7950 here, so hevc or anything like that either [19:07:42 CET] <nevcairiel> but still nice to be able to use it, i guess [19:11:09 CET] <jamrial> win10 falls creators build showing gpu usage in task manager is really nice [19:11:44 CET] <nevcairiel> the interesting part about that is that no third party tool could previously show video engine usage on amd, but there it is [19:12:34 CET] <BtbN> it shows video engine usage? More than just "Yes, this uses it!"? [19:12:46 CET] <jamrial> yeah [19:14:02 CET] <jamrial> now if only configure could stop taking 13 minutes on it, i'd consider it the best win10 build so far [19:14:18 CET] <nevcairiel> https://i.imgur.com/3d72ALB.png all sorts of info! [19:15:34 CET] <jamrial> playing something? :p [19:15:44 CET] <nevcairiel> yeah =p [19:19:39 CET] <SortaCore> you guys messing with d3d11 [19:20:05 CET] <SortaCore> I'm doin' H264 decode/encode with HWA so lemme know if you want tests [19:20:12 CET] <SortaCore> windoze 10 [19:35:00 CET] <SortaCore> I'm confused, is d3d11va related to vaapi? [19:35:11 CET] <nevcairiel> no [19:35:40 CET] <nevcairiel> btw jamrial, 6m40s for configure here [19:35:44 CET] <JEEB> \o/ [19:36:53 CET] <jamrial> curious [19:37:21 CET] <jamrial> it can't be cpu dependent since during the last several minutes cpu usage stays in the single digits for me and it just spawns sh time and time again [19:39:52 CET] <atomnuker> what was the variable to regenerate fate checksums [19:40:47 CET] <ubitux> atomnuker: GEN [19:49:08 CET] <SortaCore> hwaccel what's the diff between d3d11va and d3d11va2 hwaccel? [19:52:47 CET] <wm4> d3d11va is old API [19:52:57 CET] <wm4> d3d11va2 is badly named new API, which you should use [22:25:50 CET] <cone-451> ffmpeg 03Pan Bian 07master:61bbc537ab23: avcodec/samidec: check av_strdup() return value [22:25:50 CET] <cone-451> ffmpeg 03Clément BSsch 07master:8d51d10eb895: lavc/samidec: properly raise errors from sami_paragraph_to_ass() [22:31:55 CET] <SortaCore> sorry, I asked this before but forgot [22:32:02 CET] <SortaCore> h264_nvenc or nvenc_h264? [22:32:41 CET] <jkqxz> Look at all the other encoders and follow the common pattern. [22:33:12 CET] <SortaCore> first one? [22:33:25 CET] <SortaCore> I don't wanna run configure for listing, not sure if it'll erase stuff [22:34:41 CET] <jkqxz> ./ffmpeg_g -encoders | grep h264 [22:35:33 CET] <BtbN> Just use the one that does not throw a big deprecation warning [22:36:12 CET] <jkqxz> That too. [22:39:23 CET] <SortaCore> why list the deprecated by default? [22:39:38 CET] <BtbN> what? [22:41:11 CET] <SortaCore> the grep one shows those two + "nvenc" with the same description [22:42:18 CET] <BtbN> Well, they are deprecated, not removed [23:37:10 CET] <jdlh> Hi, anyone want to talk about ffmpeg.org/developer.html ? [23:41:27 CET] <jkqxz> jdlh: It doesn't sound like a very fun subject, tbh. [23:42:24 CET] <wm4> we need a project leader (I nominate jamrial) [23:42:58 CET] <wm4> also why does ffserver.c still exist? [23:45:39 CET] <jkqxz> Apathy? Bloody-mindedness? Some combination thereof? [23:48:42 CET] <atomnuker> wm4: because the abi unstable period isn't over [23:48:53 CET] <atomnuker> and it isn't over because the atomic patches need to be pushed [23:49:02 CET] <atomnuker> so the avpriv_atomic stuff can be removed [23:50:10 CET] <atomnuker> and the reason why they're not pushed is because it takes _time_ and _patience_ to make those patches, review them and redo them [23:50:29 CET] <nevcairiel> both things you dont have? :) [23:50:56 CET] <atomnuker> in limited supplies, I HATE BAD WEATHER AND MY THROAT'S BEEN SICK FOR A FEW DAYS NOW [23:51:08 CET] <atomnuker> see, one just ran out momentarily [23:51:32 CET] <jdarnley> If you select me to be your dictator I will remove it immediately. [23:52:02 CET] <atomnuker> my throat or the bad weather? [23:52:39 CET] <jdarnley> All 3 - ffserver, your throat, batweather - if that's what you want. [23:53:02 CET] <ubitux> ffserver down your throat [23:53:19 CET] <atomnuker> I'd honestly want my left ear fixed, its still clicking when I swallow from when I was sick half a year ago [23:53:53 CET] <atomnuker> and that was during the summer, so the weather wasn't a problem [23:54:05 CET] <iive> have you seen a doctor for it? i've heard UK has free healthcare. [23:54:40 CET] <jdlh> So, there is no description of the ffmpeg-devel list in ffmpeg.org/developer.html . Is that OK? [23:54:52 CET] <wm4> jdlh: probably not [23:55:10 CET] <wm4> I've tried to figure out our development policy maybe a year or two ago [23:55:14 CET] <wm4> I still don't know it [23:55:25 CET] <atomnuker> iive: haven't had the time, and I lost touch with the gp I registered 5 years ago (pretty sure the practise shut down in the meantime too) [23:56:05 CET] <nevcairiel> i havent been to a gp for probably over a decade, and i moved in between too [23:56:15 CET] <wm4> what's a gp [23:56:38 CET] <iive> general practitioner [23:56:51 CET] <nevcairiel> ie. the doctor for your every day problems [23:56:51 CET] <iive> a "personal" doctor. [23:56:52 CET] <durandal_1707> michaelni: how midstream filtering with scale works? it look broken with other filters combinations atm [23:57:21 CET] <jdlh> I get the sense that people regard the patch I proposed in http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220998.html as a change to ffmpeg-devel policy. In fact, Im trying to get people to articulate the *existing* policy, so I can make a patch to add it to the developer.html page. [23:57:30 CET] <jdlh> I dont know how to get that across. [23:58:09 CET] <durandal_1707> michaelni: the calling of config props in filter frame [23:58:54 CET] <wm4> jdlh: good luck with that [23:59:05 CET] <wm4> my opinion is that ffmpeg issues can't be fixed [23:59:06 CET] <wm4> it's fucked [23:59:44 CET] <durandal_1707> jdlh: ask carl eugen, he claims to know it [00:00:00 CET] --- Thu Nov 30 2017

1 0

ffmpeg.log.20171129
by burek 30 Nov '17

30 Nov '17

[00:38:57 CET] <whysohard> Hi guys. For years I couldn't understand. Ffmpeg is very powerful. But it cannot handle with a very simple trim case: Trim end of file.. There are several commands -ss -sseof -t... But it's not sufficient. There is a question about that: https://stackoverflow.com/questions/31862634/i-need-to-cut-mp4-videos-a-par… The solution is sooo complex. Why we dont have an easy single command :( [01:46:11 CET] <anomie____[m]> I just noticed noticed a couple of rtp streams in a video file. I'm wondering how I can extract them and view their contents. [02:16:12 CET] <TheRock> a question [02:16:31 CET] <DHE> a response [02:17:12 CET] <TheRock> can you answer my question [02:20:33 CET] <klaxa> if you can ask one, maybe [02:24:48 CET] <TheRock> do you know the answer [02:27:09 CET] <klaxa> unknown until you ask the question [02:28:45 CET] <TheRock> before i can ask the question, i must know if you can answer it [02:30:02 CET] <klaxa> sounds like a deadlock, i'm out [02:31:14 CET] <TheRock> k, i will try to ask it later [02:38:17 CET] <DHE> acknowledgement and acceptance of terms [02:40:30 CET] <zash> Tomorrow, on "How to ask questions on IRC", will TheRock finally ask their question? Tune in and see! [03:20:50 CET] <raytiley_> i'm messing around with ffmpeg to generate HLS from a deckling card using dshow. I think i'm seeing the bitrit of the files grow if the decklink card doesn't get video for a while and x264 is encoding black frames... the output is still working ok.. the files are just oo big, does that make sense?`-c:v libx264 -x264opts keyint=60:no-scenecut -s 416x234 -r 29.97 -b:v 200k -preset ultrafast -profile:v main -level 3.0 [03:20:50 CET] <raytiley_> -pix_fmt yuv420p -y -c:a aac -ar 48000 -hls_list_size 5 out.ts` is the output part of the command i'm using [03:42:57 CET] <CCFL_Man> kerio: the transport stream identified the video stream as mpeg2 [03:43:11 CET] <CCFL_Man> but it's really mpeg4 [03:46:12 CET] <dystopia_> your tivo records it as mpeg4 [03:46:36 CET] <dystopia_> it was probably broadcast originally as mpeg2 [03:46:55 CET] <dystopia_> but pvr's including tivo don't record the transport stream or program stream raw [03:47:22 CET] <dystopia_> they usually transcode it on the fly to save space [03:56:35 CET] <CCFL_Man> dystopia_: no, the hd channels of my cable are mpeg4 [03:56:49 CET] <CCFL_Man> tivo dumps the stream to the MFS database [03:57:07 CET] <CCFL_Man> they do record it raw [03:57:21 CET] <CCFL_Man> Tivo always recorded raw [04:05:06 CET] <CCFL_Man> except for analog and an mpeg2 encoder was used. [04:07:23 CET] <ian5v> hi all, looking for a way to fill the black portions of a screen on a video taken on a phone in portrait mode with some blurred out still from the video [04:07:43 CET] <ian5v> news channel do this pretty frequently for videos they get [04:08:16 CET] <ian5v> has anyone seen it done in ffmpeg? if not; elsewhere? [04:11:24 CET] <ian5v> something that looks roughly like this: https://youtu.be/LdCLQ2DQ0NY [04:13:30 CET] <ian5v> (worth noting: the video doesn't have black bars yet) [04:29:20 CET] <CCFL_Man> SD channels are mpeg2, HD channels are mpeg4 [05:15:27 CET] <furq> ian5v: scale,boxblur;overlay [05:17:27 CET] <furq> -filter_complex "[0:v]scale=1920:-2,boxblur=4:4[bg];[bg][0:v]overlay=240:0[out]" -map "[out]" [05:17:35 CET] <furq> something like that but you'll want to mess around with the actual numbers [05:17:36 CET] <KTSamy> some of the ffmpeg recommended download sources like evermeet.cx, fmpeg.zeranoe.com are not providing the complete source codes. Thus they are breaking LGPL. But, ffmpeg team still recommends them. [05:18:39 CET] <KTSamy> According to LGPL, they must provide the source codes along with control scripts by which we can produce the exact library or executable. [05:20:11 CET] <KTSamy> if ffmpeg itself supports those who are violating the LGPL, how can we expect others will comply to the LGPL? [05:20:59 CET] <furq> zeranoe does provide the source [05:21:03 CET] <furq> there's a link to it at the top of the page [05:22:13 CET] <furq> actually nvm that just links to the ffmpeg repo [05:22:23 CET] <furq> he definitely used to provide the source for everything [05:22:38 CET] <furq> and also providing it on request is still lgpl compliant [05:25:42 CET] <KTSamy> Which section of LGPL allows disclosing the sources only on demand? [05:27:27 CET] <furq> https://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesWrittenOfferValid [05:27:46 CET] <furq> the zeranoe builds include the license text so that offer is there [05:28:11 CET] <furq> and he definitely used to autogenerate and package all the sources, so i assume you can still get them on request [05:33:39 CET] <KTSamy> I can understand that they might be using a script to autogenerate the binary based on the latest/specific version of the sources. [05:34:14 CET] <KTSamy> but, it must be disclosed to comply with LGPL. [05:34:34 CET] <KTSamy> I will contact them first to know their stands on this. [05:55:21 CET] <ian5v> furq: thank yoU!! [05:56:20 CET] <ian5v> i'll give it a shot [05:58:59 CET] <KTSamy> @furq [05:59:03 CET] <KTSamy> thank you [08:12:09 CET] <KTSamy> frug: I have received a reply from evermeet.cx [08:12:43 CET] <KTSamy> They are not ready to release the build script to compile the binaries [08:13:43 CET] <KTSamy> Their Reply: [08:14:35 CET] <KTSamy> I'm sorry, I won't release my script to build the binaries. [08:14:35 CET] <KTSamy> Some of the 3rd party libraries have broken build systems and some require manual intervention to create static libs to be then able to create a static binary. These things took many, many hours of trial and error and years of maintainance of my script to get it working. [08:16:35 CET] <KTSamy> They are violating LGPL terms. [09:20:35 CET] <foul_owl> How do I reverse a video with filter_complex? [09:24:02 CET] <Nacht> -i inputfile.mp4 -vf reverse reversed.mp4 [09:27:58 CET] <foul_owl> Already using filter_complex to do other stuff, so -vf reverse doesn't work [09:28:37 CET] <KTSamy> can you just provide a sample command? [09:33:59 CET] <Nacht> Then add reverse to your filter complex [10:58:54 CET] <pihpah> Hi everyone, I've got a customer feedback, she reported that a video file has an out-of-sync audio stream. I've checked it by myself and noticed the same problem, but I did that on Windows using Chrome browser, today I checked the same video on Linux and everyhting worked just fine. Any idea? This is ffprobe's output https://pastebin.com/1kfgz0m4 [11:12:54 CET] <pupp> How to use dshow device "virtual-audio-capturer" inside a amovie filter? [11:13:00 CET] <pupp> I tried this, but it didn't work. "No such file or directory". [11:13:04 CET] <pupp> ffplay -f lavfi "amovie='virtual-audio-capturer'[aud];[aud]asplit[aud][out1];[aud]showcqt=1280x720:volume=30:volume2=30[out0]" [12:02:35 CET] <Brian_> im cropping/scaling a video with ffmpeg. It works for most videos but when i try to process one with a rotation in the metadata i get an error: [12:02:37 CET] <Brian_> https://pastebin.com/raw/h3JKA5qv [12:02:56 CET] <Brian_> i compiled ffmpeg myself with minimal settings so maybe im missing a filter? [12:03:29 CET] <Brian_> 'Error reinitializing filters!' [12:36:49 CET] <pihpah> mp4 files made for streaming can't be played on macOS, I am having problems with those both in Safari and Firefox, on Linux and Windows everything is fine. Any idea what's wrong? [12:44:50 CET] <Chloe> pihpah: ffprobe them [12:50:44 CET] <pihpah> Chloe: https://pastebin.com/RJfHf8qK [12:50:57 CET] <Martchus> pihpah: maybe those are mp4 dash? what happens if you just remux the concerning files (with ffmpeg)? [12:52:42 CET] <pihpah> Martchus: did not try that, I am using -crf 28 -strict -2 options when transcoding video streams. [12:53:08 CET] <pihpah> Maybe the problem is in video stream rather audio. [12:53:38 CET] <KTSamy> Probably it's an issue with hardware acceleration [12:54:28 CET] <KTSamy> have you used any other encoding parameters? [12:55:36 CET] <pihpah> KTSamy: I am thinking of using -preset fast option instead of -crf, would that do it? I mean if there is a possible problem with video decoding and the speed of that process. [12:58:57 CET] <KTSamy> I think It shouldn't fix anything. [13:00:20 CET] <KTSamy> I have tried a file after transcoding. It works absolutely fine for me. [13:00:31 CET] <KTSamy> can you share a sample? [13:09:39 CET] <pihpah> KTSamy: https://www.dropbox.com/s/2i0nv33ctorxvlh/S06E06_720p.mp4?dl=0 [13:26:07 CET] <KTSamy_> pihpah: it plays absolutely fine for me on both Firefox & Safari [13:32:09 CET] <SortaCore> it may be processor speed? [13:32:16 CET] <SortaCore> maybe the hardware isn't up to par [13:33:28 CET] <pihpah> What about profile levels? https://trac.ffmpeg.org/wiki/Encode/H.264#Compatibility [13:33:53 CET] <SortaCore> yea, I'm not sure that would cause lag? [13:34:02 CET] <SortaCore> that might make it undecodable [13:34:13 CET] <SortaCore> although, maybe a slower software decode would be used by the browser automatically [13:34:29 CET] <pihpah> Well, on macOS I can't play them at all. [13:34:49 CET] <SortaCore> have you checked the profile levels that your mac supports? [13:36:28 CET] <SortaCore> you could try baseline, main and high [13:36:30 CET] <SortaCore> see where it dies [13:36:56 CET] <SortaCore> baseline 3.0, 3.1, main 3.1, high 4.0, 4.1, 4.2 [13:37:01 CET] <KTSamy_> I am also checking in mac [13:37:07 CET] <BtbN> I don't think any actual baseline encoder even exists [13:37:15 CET] <BtbN> it's always constrained baseline [13:37:23 CET] <KTSamy_> Macbook Pro with High Sierra [13:38:46 CET] <SortaCore> wasn't there a big security risk announced for high sierra? [13:38:50 CET] <SortaCore> https://www.theverge.com/2017/11/28/16711782/apple-macos-high-sierra-critic… [13:38:51 CET] <KTSamy> h264 hardware acceleration might be broken on your device. [13:39:12 CET] <KTSamy> yah. noticed that. hope soon they will announce a fix. [13:39:31 CET] <KTSamy> disabled Remote Login for safer side. [13:40:11 CET] <SortaCore> it's to do with root user, if y'all haven't, add a password for it [13:40:56 CET] <SortaCore> there's a note in h264 that QuickTime only supports h264 with yuv420p [13:57:13 CET] <ritsuka> pihpah: I can play that file even in the old and deprecated QuickTime Player 7 [13:58:27 CET] <pihpah> ritsuka: weird [13:58:52 CET] <pihpah> Okay, I made some changes to ffmpeg options, will try on another video. [13:59:14 CET] <ritsuka> sync issues in some players are caused by those players lack of edit lists support [14:01:09 CET] <ritsuka> in your file the audio track is delayed by 978 ms, if the player can't handle the edit list, it will be out of sync [14:03:05 CET] <pihpah> ritsuka: how did you figured it out? I could not perceive any audio delay. [14:47:16 CET] <seirl> hi [14:47:18 CET] <seirl> i don't understand why the -to parameter cannot be used before -i [14:47:56 CET] <seirl> is there a reason why i can't just do ffmpeg -ss start -to end -i input.mp3 output.mp3? [14:49:00 CET] <seirl> instead i either have to use relative position with -t, or do the cut on the output (which isn't really good when you want to integrate that to another file) [14:49:24 CET] <seirl> or use -ss start -i input -to end -copyts which is both inconvenient and stupid [14:50:00 CET] <seirl> i have trouble understanding the technical reason behind that choice [14:50:23 CET] <seirl> anyone could shed some light on the issue for me? :-) [14:50:31 CET] <BtbN> Nobody implemented it. [14:51:09 CET] <BtbN> And since there is no overhead from specifying it on the output, nobody cares enough [14:52:05 CET] <seirl> well that's the thing, i looked at the code and it *looks* like it is implemented: https://github.com/FFmpeg/FFmpeg/blob/86cead525633cd6114824b33a74d71be677f9… [14:52:32 CET] <seirl> this function handles a non-null recording_time option [14:52:38 CET] <seirl> but maybe i'm mistaken? [14:52:58 CET] <seirl> stop_time* sorry, not recording_time which is for -t [14:53:10 CET] <seirl> line 989 [14:53:45 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/fftools/ffmpeg_opt.c#L3426 it's an input and output option. [14:54:32 CET] <seirl> oh... 11 days ago https://github.com/FFmpeg/FFmpeg/commit/80ef3c83601881ff2b6a90fa5c6e82c83aa… [14:54:41 CET] <seirl> thank you for helping me find that commit! [14:56:44 CET] <dradakovic> guys i have a problem compiling ffmpeg with libmp3lame enabled. I do ./configure --enable-libmp3lame but i get error: libmp3lame >= 3.98.3 not found [14:57:19 CET] <DHE> you might need to export PKG_CONFIG_PATH=/usr/local/lib/pkg-config or such if it's a custom build not installed to standard locations [14:58:15 CET] <dradakovic> Understood. It would be easier then to install it to a standard location then. How can i do that with ./configure? [14:58:42 CET] <seirl> --prefix [14:58:44 CET] <BtbN> Installing into your system manually is a bad idea, don't do that. [14:58:45 CET] <seirl> maybe? [14:58:57 CET] <dradakovic> I am doing that as yum version of ffmpeg is too old and im a noob compiling [15:02:22 CET] <dradakovic> How else can i obtain a new 3.4 version on centos? Did i already ruin it already if i already ran ./configure make install [15:02:42 CET] <dradakovic> There was some installation going on [15:03:15 CET] <BtbN> You might have mad a mess that's hard to clean up [15:04:49 CET] <dradakovic> Hmm. So how exactly should have run my ./configure command? [15:33:35 CET] <tolland> the problem with all this GPL stuff on the mailing list, is that no one is paying attention to my one about gett ONVIF data from RTSP :-( [15:41:26 CET] <atomnuker> ping the patch [16:49:24 CET] <rom1v> hi, on ubuntu 16.04, avcodec_send_packet() does not exist https://www.ffmpeg.org/doxygen/3.1/group__lavc__decoding.html#ga58bc4bf1e0a… [16:49:53 CET] <rom1v> how to know easily the exact version where it appears, so that I can #ifLIBAVCODEC_VERSION_INT < AV_VERSION_INT(?, ?, ?) ? [16:51:55 CET] <rom1v> s/appears/appeared/ [17:00:06 CET] <rom1v> 7fc329e2dd6226dfecaa4a1d7adf353bf2773726 ok la version a été modifiée par le commit lui-même [18:20:25 CET] <SortaCore> Couldn't send an ending video image to encoder: avcodec_send_frame failed with error -11: Resource temporarily unavailable [18:24:39 CET] <BtbN> "ending video image"? [18:26:31 CET] <SortaCore> the stuff frames received from rtsp formatcontext, after a null packet was sent to rtsp [18:26:50 CET] <BtbN> rtsp is not an encoder [18:27:13 CET] <BtbN> And if you send EOF to an actual encoder, it will go into EOF mode, you cannot send it any further frames. [18:27:23 CET] <SortaCore> yea, I'm transcoding [18:27:56 CET] <SortaCore> and I've not sent the null to the encoder yet, not until the attempt to receive from RTSP goes AVERROR_EOF [18:30:00 CET] <SortaCore> atm I do avcodec_send_packet with null packet, then I do avcodec_receive_frame(rtsp) until EOF and avcodec_send_frame to encoder, then send null frame to encoder and do avcodec_receive_packet until it EOFs [18:30:15 CET] <SortaCore> would be neater with some C++ streams amirite [18:30:41 CET] <SortaCore> although I don't know C++ well enough to do that [18:33:40 CET] <SortaCore> atm to do transcoding I'm getting the YUV420P frames from rtsp, passing it through sws_scale to convert to NV12, then passing it to encoder [18:33:55 CET] <SortaCore> otherwise H264 won't be all hardware-ified [18:34:12 CET] <SortaCore> although, it's not QSV hw frame, so... it may be not very hardware anyway [18:34:21 CET] <SortaCore> just regular NV12 [18:53:54 CET] <Cracki> -f image2, how to specify individual images explicitly? multiple -i? comma-separated? [19:04:15 CET] <Cracki> got a build that doesn't have globbing, so image2 with glob not possible [19:21:12 CET] <relaxed> Cracki: use a static build [19:21:21 CET] <Cracki> I have a static build [19:22:03 CET] <relaxed> And it doesn't have glob support? Look at "ffmpeg -h demuxer=image2" [19:23:09 CET] <Cracki> [image2 @ 00000000004f9bc0] Pattern type 'glob' was selected but globbing is not supported by this libavformat build *.png: Function not implemented [19:23:28 CET] <relaxed> which static build are you using? [19:23:49 CET] <relaxed> pastebin.com your command and output [19:23:51 CET] <Cracki> minor inconvenience. I have to take the -f concat -i somelist way [19:24:00 CET] <Cracki> ok hold on I'll check [19:25:06 CET] <Cracki> the 3.4 build from zeranoe [19:26:11 CET] <Cracki> https://pastebin.com/y6Q9s9T3 [19:34:13 CET] <relaxed> Cracki: try without the quotes [19:35:20 CET] <Cracki> changes nothing [19:35:29 CET] <Cracki> you see this is windows [19:35:40 CET] <Cracki> there is no globbing on windows, except if you do it yourself [19:35:54 CET] <Cracki> apparently libavformat has no own glob impl [19:36:14 CET] <Cracki> or zeranoe built it without support for that, if there were support [19:37:43 CET] <Cracki> https://github.com/FFmpeg/FFmpeg/blob/a20f64bee235042f6e35c8e7ae65ccfddbf73… [19:37:51 CET] <Cracki> I think there's no fallback [19:41:21 CET] <JEEB> and you most likely would be correct [19:41:26 CET] <JEEB> some image formats can be piped though [20:05:35 CET] <gon_> Hi. Is there a way to use more than 2 inputs with vstack and hstack? [20:07:07 CET] <furq> gon_: hstack=inputs=3 [20:09:25 CET] <gon_> Awesome, thanks furq [20:47:56 CET] <DocHopper_> Hey ffmpeg, I'm using a program called BDA Viewer Plus to view/log the video feed transmitted by my remote comp running ffmpeg. In this program, there is an option for "UART Demux", which includes GPS options. Is anyone here familiar with adding a data stream of some sort to a .ts steam from FFMPEG? [20:49:49 CET] <SortaCore> may have something to do with -map? [20:53:36 CET] <DocHopper_> SortaCore: That could be an option. There's documentation on subs, maybe there's a way to do it through that? [21:01:20 CET] <BtbN> I don't think ffmpeg can embed gps information [21:02:46 CET] <BtbN> you can set arbitrary metadata, but an embedded running gps stream, I don't think so [21:03:35 CET] <DocHopper_> BtbN: So how do I go about adding metadata that updates frequently? [21:03:45 CET] <DHE> maybe not metadata, but a whole private stream? [21:04:30 CET] <BtbN> If you have something that generates that uart data stream, you might be able to just pipe it in [21:04:37 CET] <BtbN> But there is no direct gps support in ffmpeg. [21:04:46 CET] <BtbN> And metadata does not update. It's set once in the header. [21:04:59 CET] <DHE> I think this might be better suited to making your own via the API. add a private stream type, build AVPackets for it and mux them as you go [21:05:42 CET] <DocHopper_> DHE: That sounds wonderful, and well beyond my current knowledge. [21:06:16 CET] <DocHopper_> Right now I'm just adding my datastream to the video feed and hoping I can set something up to read it through character recognition. [21:06:22 CET] <DocHopper_> Or maybe generation a barcode? [21:29:46 CET] <furq> is it just me or is showspectrumpic size broken [21:30:21 CET] <furq> it truncates the y axis if the height isn't a multiple of 512 [21:31:43 CET] <furq> https://imgur.com/a/aSUEB [21:31:53 CET] <furq> top is s=1024x512, bottom is s=1024x513 [21:37:59 CET] <durandal_1707> furq: height must be multiple of 2 [21:38:52 CET] <furq> it still truncates it with non-mod2 heights [21:39:10 CET] <furq> unless you mean power of 2 [21:39:29 CET] <durandal_1707> ah, yes , power of 2 [21:40:20 CET] <furq> well that's annoying [21:47:12 CET] <SortaCore> DocHopper, you may be better off just converting it to a subtitle format and using that [21:47:22 CET] <SortaCore> not exactly efficient or ideal though [22:56:20 CET] <DocHopper_> SortaCore: I've considered that, but I'm not sure how I would extract that from the stream on the receiving computer. [23:04:35 CET] <SortaCore> some video formats are designed to embed subtitles as well [23:04:42 CET] <SortaCore> *cough* [23:04:46 CET] <SortaCore> some video container formats [23:04:58 CET] <SortaCore> video streams, audio streams, subtitle streams [23:05:03 CET] <SortaCore> it's how you get dual-audio [23:05:23 CET] <klaxa> how do subtitles lead to dual audio? [23:05:37 CET] <SortaCore> BOI [23:06:02 CET] <SortaCore> point is you can embed any amount of any type in a container format [23:06:18 CET] <kinkinkijkin> so, how extensive is opencl support in x264? a google says it's just frame lookahead, but these results are from 2012 [23:06:27 CET] <SortaCore> and most players will pick up on it, so you just need a way to convert gps to coordinates [23:06:34 CET] <SortaCore> I think there was updates on opencl just last week [23:09:44 CET] <SortaCore> gps to coordinates? [23:09:53 CET] <SortaCore> gps to coords + time it so it appears with the video at the correct time [23:38:34 CET] <DocHopper_> SortaCore: So how should I go about doing that in a method that is compliant with DVB standards? [23:59:00 CET] <SortaCore> DVB = ? for me [23:59:03 CET] <SortaCore> so, who knows [23:59:19 CET] <SortaCore> I'm not a ffmpeg guy [23:59:28 CET] <SortaCore> I'm just hanging because my current project involves ffmpeg [00:00:00 CET] --- Thu Nov 30 2017

1 0

ffmpeg-devel.log.20171128
by burek 29 Nov '17

29 Nov '17

[00:22:57 CET] <ramiro> I'm capturing from a live source, but I want to discard all frames unless I receive a trigger command (probably from an arduino connected to serial). I'm thinking about writing a simple filter that listens on the serial, drops frames while the trigger is not set, and keeps track of the pts offset that must be used to compensate for the dropped frames. [00:23:03 CET] <ramiro> does anyone have a simpler idea? [00:59:31 CET] <atomnuker> won't work if your input is variable fps (as most webcams are) [01:00:38 CET] <atomnuker> also use the API, its what its there for, don't extend ffmpeg.c [01:18:48 CET] <cone-097> ffmpeg 03Pan Bian 07master:5b4baf150627: libavformat/rtpenc_mpegts: check avformat_new_stream() return value [01:18:49 CET] <cone-097> ffmpeg 03Pan Bian 07master:2ba6d7cb8278: ffmpeg: Check read_ffserver_streams() return value [01:22:22 CET] <ramiro> atomnuker: why would it not work with variable fps? I save the pts from the first dropped frame, then use it to calculate the delta to the first non-dropped frame, and subtract that delta for the accepted frames. [01:25:31 CET] <atomnuker> ah, yeah, that's okay then, I thought you were just going to take 1/fps an use that [02:38:56 CET] <atomnuker> michaelni: does adding a space like "static _Atomic(AVCodecParser *)av_first_parser = NULL;" help? [02:41:05 CET] <jamrial> why the brackets? [02:41:26 CET] <atomnuker> wouldn't compile here otherwise [02:42:32 CET] <jamrial> _Atomic is a type qualifier, that should be "static _Atomic AVCodecParser *av_first_parser" i think [02:45:11 CET] <atomnuker> 01:48 <@atomnuker> any ideas why "static _Atomic AVCodecParser *av_first_parser = NULL;" isn't accepted as input to atomic_load()? [02:45:13 CET] <atomnuker> 01:48 <@atomnuker> "error: address argument to atomic operation must be a pointer to _Atomic type ('_Atomic(AVCodecParser) ***' invalid)" [02:45:15 CET] <atomnuker> 01:49 <SortaCore> no brackets and where the * is [02:45:17 CET] <atomnuker> 01:51 <@atomnuker> that worked, tnx [02:49:44 CET] <jkqxz> jamrial: No, that would be a pointer to an _Atomic AVCodecParser. You want AVCodecParser *_Atomic. [02:50:35 CET] <jkqxz> Though I'm not sure that this approach is sane. Can't we just replace the "clever" use of atomics with a mutex and be done with it? There are no performance implications. [02:51:14 CET] <jamrial> anything that gets rid of all the lavu atomic stuff [02:52:30 CET] <atomnuker> jkqxz: no, I like clever atomics and dislike mutexes [02:53:15 CET] <jkqxz> (Or delete the registration mechanism entirely and just have a big array.) [02:53:50 CET] <iive> i thought that libav already did that and we had merged it [02:53:51 CET] <atomnuker> maybe once we get rid of atomics [02:54:26 CET] <iive> are you really going through all this trouble just for the register_all() ? [02:54:47 CET] <atomnuker> no, we're going through all this trouble to remove avpriv_atomics [02:55:10 CET] <jamrial> OMFG, someone overloaded ret in avformat_write_header() and it's never returning an error if header writing fails [02:55:27 CET] <iive> how is adding atomics remove them? [02:56:22 CET] <jamrial> iive: replacing lavu wrappers with c11 [02:56:27 CET] <jamrial> or removing them, both are fine [02:57:18 CET] <iive> so instead of wrappers you are hardcoding c11 atomics? [02:57:50 CET] <iive> aka, c11 support is now mandatory [02:58:25 CET] <jamrial> no [02:59:19 CET] <iive> go on... [03:00:06 CET] <jamrial> there's an old internal lavu atomic api that's a wrapper for different kind of atomic functions depending on compiler/os. it's ugly and uses internal avpriv symbols [03:01:36 CET] <jamrial> some time ago a new set of wrappers was added that emulates c11 style atomics, without avpriv symbols in an specific library [03:02:14 CET] <jamrial> compilers that support c11 use their builtin support. those that don't, use said c11 wrappers in the compat folder [03:03:54 CET] <jamrial> most uses of the old lavu api were ported. some haven't, and we're trying to deal with them so we can effectively nuke the old api now that we still can remove apriv symbols [03:04:55 CET] <iive> the avpriv seems to be used in the case when there is no atomics support and they are emulated by explicity mutex [03:05:03 CET] <iive> how the new code handles that case? [03:07:08 CET] <jamrial> the same way [03:08:02 CET] <iive> how do you get rid of avpriv then? [03:08:10 CET] <atomnuker> iive: if c11 atomics aren't supported an stdatomic.h file is used instead which emulates them [03:08:17 CET] <atomnuker> using whatever atomics are available [03:10:01 CET] <jamrial> oh, i see what you mean [03:12:00 CET] <jamrial> these also have two avpriv symbols. technically it's the same scenario with pthreads based emulation, yeah [03:16:22 CET] <atomnuker> jamrial: which ones have avpriv_symbols? [03:16:29 CET] <iive> yeh [03:18:24 CET] <iive> cu, n8 ppl [03:18:42 CET] <jamrial> atomnuker: the pthreads emulation [03:19:28 CET] <atomnuker> what is it used for? [03:20:00 CET] <jamrial> the mutexes [03:22:30 CET] <atomnuker> ah, right [03:25:31 CET] <cone-097> ffmpeg 03James Almer 07master:9924f1bc3424: avformat/matroskaenc: move some initialization checks to mkv_init [05:25:07 CET] <cone-097> ffmpeg 03James Almer 07master:5f67073b4cb1: avformat/matroskaenc: add missing allocation failure checks for stream durations [07:24:26 CET] <cone-097> ffmpeg 03Rodger Combs 07master:1204ce0b6371: lavu/hwcontext_opencl.h: fix build on macOS [11:48:31 CET] <cone-097> ffmpeg 03Anssi Hannula 07master:1dff9adcb934: avformat/hls: Factor playlist need check to a common function [11:48:32 CET] <cone-097> ffmpeg 03Anssi Hannula 07master:143552095dae: avformat/hls: Obey AVProgram discard flags [13:04:27 CET] <cone-097> ffmpeg 03Karthick J 07master:d5d2632e3a0f: avformat/hlsenc: Fixed initial setting for end_pts [14:01:21 CET] <atomnuker> jdarnley: why the hell did you release your vf_removegrain simd under the gpl? [14:01:43 CET] <jdarnley> I think because it was based on the original which is gpl [14:02:03 CET] <atomnuker> ah, ok [14:02:13 CET] <jdarnley> Also why should I not use the GPL for stuff I do on my own time. [14:02:50 CET] <jdarnley> Isn't the filter itself gpl? [14:03:59 CET] <jdarnley> Aparently not. [14:05:33 CET] <jdarnley> I hope durandal_1707 didn't look at the original source when writing it. [15:01:14 CET] <durandal_1707> jdarnley: the implementation of removegrain in vs is lgpl [15:01:39 CET] <durandal_1707> ot better than that [15:02:41 CET] <atomnuker> jdarnley: I think the only reason to gpl some code in ffmpeg is if you're writing an encoder [15:03:26 CET] <atomnuker> otherwise for general purpose filtering/muxing and decoding having gpl code just encourages people to mislicense when they compile because they need to [16:38:58 CET] <jdarnley> I have another question related to the palignr one I asked yesterday. [16:39:02 CET] <jdarnley> https://pastebin.com/mhcR8knE [16:39:22 CET] <jdarnley> Can I do that operation in ymm registers? [16:39:56 CET] <jdarnley> I'm guessing not because I need to move stuff over the lanes [16:40:39 CET] <jdarnley> palignr did work very well when I got the order correct so thank you for that. [16:41:45 CET] <jdarnley> Perhaps I should change the code below so I don't need to split like that. [17:04:25 CET] <jdarnley> Gramner, jamrial, atomnuker, durandal_1707, iive: do you have any suggestions on the above? [17:06:40 CET] <iive> jdarnley: usually ymm operationsa are like two separate xmm operations [17:11:32 CET] <jdarnley> I know. I usually write my avx2 code like I'm unrolling the loop and stick the next loop on to the high end of the registers. [17:14:15 CET] <iive> the #else case looks fishy [17:14:37 CET] <iive> e.g. m0 is changed, but not used (in this scope) [17:27:33 CET] <jdarnley> Yeah, that has limited context [17:27:50 CET] <jdarnley> m0 is used [17:28:59 CET] <iive> what is the code supposed to do, unpack 12 bytes into 16 (and pad with zero) ? [17:31:02 CET] <iive> float rgb -> float rgba ? [17:31:10 CET] <jdarnley> no [17:31:18 CET] <jdarnley> It is effectively the weld between two other pieces of code. The whole function is supposed to turn one bitpacked format into another. [17:31:41 CET] <jdarnley> It turns out the original was wrong plus it needs to clip word values to a given range. [17:32:13 CET] <jdarnley> So I have now taken two similar functions and welded them together witht hat palignr [17:51:18 CET] <cone-097> ffmpeg 03Aman Gupta 07master:b5d56d8ef1ef: avcodec/videotoolbox: fix SEGV when hwaccel decoding h264 with ffmpeg.c [19:03:12 CET] <SortaCore> so uh, how do you tell if a HWAAccel frame is allocated on GPU or RAM? [19:04:30 CET] <BtbN> You look at the pix_fmt. [19:05:14 CET] <SortaCore> swscaler won't let me convert from QSV to anything tho [19:05:48 CET] <BtbN> sounds correct, it's a sw scaler after all [19:06:13 CET] <BtbN> you want to hwdownload the frame [19:13:25 CET] <SortaCore> av_hwframe_transfer_data right? [20:52:43 CET] <cone-097> ffmpeg 03Vittorio Giovara 07master:755207dc53d6: prores: Always assume limited range [20:52:44 CET] <cone-097> ffmpeg 03Vittorio Giovara 07master:10db42f117ed: mov: Support mdcv and clli boxes for mastering display an color light level [20:52:45 CET] <cone-097> ffmpeg 03Vittorio Giovara 07master:3e0560b054dd: vf_zscale: Relax color properties maximum bounds [20:52:46 CET] <cone-097> ffmpeg 03Vittorio Giovara 07master:002db7d49ada: vf_zscale: Add more supported input properties [21:02:02 CET] <Gramner> jdarnley: somewhat awkward permutations in avx2. 2x vpermd + 3x vpblendd should work, but it's kinda slow. in avx512 you can at least do it with 2x two-table permutations [21:07:57 CET] <jdarnley> Gramner: thanks [21:16:54 CET] <SortaCore> hmm, right now the convert from YUV420P to NV12 (for hwaaccel) is using the most CPU [21:17:07 CET] <SortaCore> aren't they basically the same format but with U/V flipped? [21:20:07 CET] <JEEB> no, NV12 has chroma packed [21:20:13 CET] <JEEB> while luma is a separate plane [21:44:37 CET] <cone-097> ffmpeg 03Gyan Doshi 07master:b3cb9bd43fa3: avfilter/drawbox: rename variable for maximum thickness [21:44:38 CET] <cone-097> ffmpeg 03Dale Curtis 07master:96e340760824: Free extradata before reallocating. [21:44:39 CET] <cone-097> ffmpeg 03Pan Bian 07master:89f9332fdf89: avcodec: set correct return value in ff_mpeg_ref_picture [21:44:40 CET] <cone-097> ffmpeg 03Mark Reid 07master:62f7f40caa70: avformat/mxfenc: pass MXFPackage around instead of type [21:44:41 CET] <cone-097> ffmpeg 03Pan Bian 07master:3f81259f337b: avformat/mov: set correct error code in mov_read_custom [21:44:42 CET] <cone-097> ffmpeg 03Pan Bian 07master:f63450c8e4c9: avformat/mov: return correct value in mov_read_cmov [22:58:11 CET] <kierank> how has this guy managed to send an email in december [23:04:11 CET] <BtbN> Intel employees must have their clock 3 days in advance, so they don't miss deadlines [23:16:59 CET] <cone-097> ffmpeg 03Mark Thompson 07master:c5f3e85792d5: Changelog: add VAAPI VP8 decoder [23:17:00 CET] <cone-097> ffmpeg 03Jun Zhao 07master:23db3a1ae6d1: examples: Add a VA-API encode example. [23:17:01 CET] <cone-097> ffmpeg 03Mikhail Mironov 07master:9ea6607d2945: Add HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK [00:00:00 CET] --- Wed Nov 29 2017

1 0

ffmpeg.log.20171128
by burek 29 Nov '17

29 Nov '17

[00:56:04 CET] <CCFL_Man> this ts has a video bitrate of 3mbit. it looks good on my tivo. it has to be mpeg4 at that bitrate, right? [00:56:18 CET] <CCFL_Man> it's an HD feed. [01:00:23 CET] <Ouchsplat> I am having an issue where I am using ffmpeg, I am using a private rtmp server that is recieving 4 seperate streams then using ffmpeg to merge the streams into tiled video. the problem is that if a streamer logs off ffmpeg stops with an error. I would like to have it replace the feed that disconnected with a static image in the output [01:00:53 CET] <Ouchsplat> any ideas? I have only been using ffmpeg for 2 days [01:01:45 CET] <Ouchsplat> this is the command I am using ffmpeg -i rtmp://192.168.0.4/live/ouchsplat -i rtmp://192.168.0.4/live/biidieyz -i rtmp://192.168.0.4/live/inputend -i rtmp://192.168.0.4/live/sirm -filter_complex "nullsrc=size=1920x1080 [base]; [0:v] setpts=PTS-STARTPTS, scale=960x540 [upperleft]; [1:v] setpts=PTS-STARTPTS, scale=960x540 [upperright]; [2:v] setpts=PTS-STARTPTS, scale=960x540 [lowerleft]; [3:v] [01:01:45 CET] <Ouchsplat> setpts=PTS-STARTPTS, scale=960x540 [lowerright]; [base][upperleft] overlay=shortest=1 [tmp1]; [tmp1][upperright] overlay=shortest=1:x=960 [tmp2]; [tmp2][lowerleft] overlay=shortest=1:y=540 [tmp3]; [tmp3][lowerright] overlay=shortest=1:x=960:y=540" -c:v libx264 output.mkv [03:34:52 CET] <kinkinkijkin> so I try to vspipe a video from 75fps to 144, and on running the command with ffmpeg I get "pipe:: invalid data found when processing input" [03:35:10 CET] <kinkinkijkin> source is x265, mkv, if it matters [03:37:09 CET] <kinkinkijkin> oh wait [03:37:12 CET] <kinkinkijkin> I'm an idiot [03:42:57 CET] <kinkinkijkin> yeah, I forgot a dash in the command [03:43:00 CET] <kinkinkijkin> derp [09:19:05 CET] <melkor> I am trying to make a stop motion from a video. Right now there are too many frames, so I was trying to sample it. If I use `-vf fps=1` the output video is the same duration, but each frame is shown for a long time. How do I get it to have the proper time too? [09:19:30 CET] <melkor> eg. a 2 minute move should because a 30second movie. [09:56:42 CET] <melkor> I used the setpts video filter, which worked. The movie went from 2min to 28sec but, the file got bigger !? [10:09:57 CET] <pl0t> came to tell that the issue is resolved, nothing wrong with ffmpeg, recompiling the system helped, also, debianuser: thank you for your troubleshooting, it was great! [12:51:05 CET] <termos> I see "adaptation_sets" option has been added to FFmpeg 3.4, what would be the correct string to supply to get the old behaviour? [12:54:29 CET] <tyng> what's the difference between theses filters? lowpass highpass treble bass bandpass bandreject allpass equalizer [12:59:56 CET] <durandal_1707> tyng: you need some serious read [13:03:51 CET] <termos> seems the adaption_sets option to keep the old behaviour is "id=0,streams=v id=1,streams=a", I wish this was the default as it's the old one people are used to [13:07:26 CET] <tyng> ffmepg documentation isn't very specific [13:07:47 CET] <tyng> where can i read about two-pole Butterworth band-rejection? [15:02:40 CET] <durandal_1707> tyng: google for it [16:01:41 CET] <godofgrunts> After upgrading to 3.4, using -c copy gives me an error https://pastebin.com/uqEx1Y67 [16:03:08 CET] <godofgrunts> same if I use -c:a copy -c:v copy [16:08:37 CET] <godofgrunts> using ffmpeg -i vid.flv vid.mp4 works as expected so something changed with how ffmpeg is handling copy I guess [16:09:32 CET] <godofgrunts> Trying to just isolate audio with -vn -c:a copy out.aac isn't working either so something is definitely screwed up. [16:14:03 CET] <godofgrunts> Just to confirm, using 2.8 does exactly what I expect it too [17:34:34 CET] <kerio> CCFL_Man: ffprobe it? [17:35:14 CET] <kerio> 720p30 h264 content looks decent at 2ish mbps [19:26:46 CET] <teratorn> if I need to encode the result of a `concat' filter multiple times (specifying multiple outputs on the command line) does that necessitate a `split' filter? or can I somehow do multiple encodes off the concat filter? [19:44:14 CET] <MegaSoft> hey [19:45:07 CET] <DHE> teratorn: unless you need or want some custom filters, you can just specify more output options and files [19:45:36 CET] <DHE> ffmpeg -f concat -i concat.txt [output options 1] output1.mkv [output options 2] output2.mp4 [output options 3] output3.flv [19:48:11 CET] <teratorn> DHE: only the first one gets the right result because i -map the result of the concat *filter* [19:48:22 CET] <teratorn> (not muxer) [19:48:50 CET] <teratorn> its ok using a split filter seems like the right thing [21:35:45 CET] <storrgie> I'm wondering, anyone use any of the black magic design capture cards? I'd like to know if its simple to plug into a Linux box and then use ffmpeg to record from the SDI interface to disk [21:37:35 CET] <sfan5> ffmpeg has decklink support [21:37:50 CET] <storrgie> yeah I see that [21:37:52 CET] <storrgie> (https://www.ffmpeg.org/ffmpeg-devices.html#decklink) [21:38:02 CET] <storrgie> I'm wondering a bit more about how I could use the capture devices [21:38:34 CET] <storrgie> I want to record video and audio from a game on a laptop, but I'd also _love_ to be able to record a separate audio channel from the microphone (headset) so that I can de-mux it later [21:39:09 CET] <storrgie> I see that BMD makes a "Mini Converter HDMI to SDI 6G" which does HDMI -> SDI, and can carry maybe some additional audio channels via an analog input [21:39:29 CET] <BtbN> Why would you even use SDI for that? [21:39:55 CET] <storrgie> well the game is intense, and I want to capture the game video, game audio, and microphone audio [21:40:01 CET] <storrgie> I want to do this for 10-30 machines at the same time [21:40:18 CET] <BtbN> You're not going to get that working on a single PC [21:40:25 CET] <storrgie> right, I'd need two machines to do capture [21:40:40 CET] <BtbN> I'd say more than 8 is a bad idea [21:40:49 CET] <BtbN> and even then you need quite a big and expensive CPU [21:40:54 CET] <BtbN> and tons of PCIe lanes [21:41:08 CET] <storrgie> the tradeoff is... do you let the laptop attempt to capture this stuff locally... then snarf it later (the laptops have two SSD in them), or do I do something like a large capture box(s) with the HDMI to SDI converters [21:41:13 CET] <storrgie> I also have to capture some video of the room [21:41:21 CET] <storrgie> which is why I started on HDMI->SDI [21:41:38 CET] <storrgie> so assuming the budget is infinite, I can probably go this route [21:41:57 CET] <storrgie> I could also just attempt to use software to capture this stuff on the laptops themselves... but there is an incurred overhead [21:41:58 CET] <BtbN> If the budget is infinite there are professional video mixing tables designed for stuff like that. [21:42:07 CET] <BtbN> They are easily 100k¬ or more though [21:42:19 CET] <storrgie> I was thinking of doing this for like 25k [21:42:26 CET] <storrgie> also, I need to pack it all up and move it [21:42:52 CET] <storrgie> I have an 11u sever chassis that I have boxes in, getting powerful machines to run decklink cards wont be a problem [21:42:56 CET] <BtbN> You'll want an external hardware mixer at least for the audio [21:43:05 CET] <storrgie> well thats what I'm wondering [21:43:15 CET] <storrgie> I don't care about levels or anything, I just want the source stuff [21:43:31 CET] <storrgie> this is being capture during an "Experiment", it gets reviews afterwards for a couple months then discarded [21:43:38 CET] <storrgie> this isnt meant to be broadcast level stuff [21:43:41 CET] <BtbN> The biggest setup I dealt with was 4 PCs, and that was already a mess and put the capture PC close to its limits [21:44:42 CET] <storrgie> so, if I went the software route and literally just saved stuff locally to the machines... what would you suggest [21:44:58 CET] <storrgie> windows software, nvidia cards (not quadro so we cant use the fancy nvidia broadcast stuff) [21:45:02 CET] <BtbN> That will put a lot of strain on the CPU of each PC [21:45:06 CET] <storrgie> right it would [21:45:14 CET] <storrgie> thats why I was looking at the HDMI->SDI cards [21:45:29 CET] <BtbN> I still don't understand in what way SDI would be of any use [21:45:41 CET] <storrgie> its just a way to get signals off the machine over a distance [21:45:55 CET] <storrgie> and the thought was that if it was a "mirrored display" there would be less overhead [21:46:38 CET] <BtbN> You're probably going to be cheaper with some DTP transmitter instead of SDI [21:46:43 CET] <BtbN> SDI is pointlessly expensive [21:46:52 CET] <storrgie> do you have a suggested product/brand I could look at? [21:46:56 CET] <BtbN> no [21:47:03 CET] <storrgie> I was looking for a reputable place to buy stuff and BMD seems like people like it [21:47:17 CET] <storrgie> also was looking for cameras I could capture the same way that I'd be capturing the laptops [21:49:38 CET] <storrgie> I mean I know this is entirely silly... but it's an interesting challenge [21:57:32 CET] <bray90820> Is there a way to split a video by chapter [22:14:22 CET] <alexpigment> I'm not sure what filter I'm supposed to be using, but I'd like to put a solid black bar over the letterboxed areas in a video (and keep the letterboxing). the current letterboxed areas have a lot of noise [22:14:33 CET] <alexpigment> I know pad is not what I'm looking for [22:21:25 CET] <BtbN> alexpigment, crop and then pad? [22:21:49 CET] <alexpigment> well, it's interlaced, and I'd like to keep it interlaced without introducing any field issues [22:22:10 CET] <alexpigment> I know I could deinterlace, crop, pad, interlace, etc [22:22:19 CET] <BtbN> most filters don't support interlaced content. [22:22:21 CET] <alexpigment> but that just seems like a lot of quality loss potential that i'd like to avoid [22:22:32 CET] <alexpigment> hmmm [22:22:36 CET] <alexpigment> ok [22:22:57 CET] <BtbN> ignoring it being interlaced, and only cropping in multiple of twos should be perfectly fine though? [22:23:35 CET] <alexpigment> maybe. i'd have to do some tests I suppose [22:23:48 CET] <alexpigment> but to your knowledge, there's no way to overlay a color in a particular area of the video? [22:24:30 CET] <BtbN> that'll be a lot less efficient than crop+pad [22:24:54 CET] <alexpigment> I don't really understand why, but I'll take your word for it [22:25:13 CET] <BtbN> Because you'll only need two filters and no extra inputs [22:25:30 CET] <BtbN> instead of at least two extra inputs of the desired size and color, and then two overlay filters [22:25:52 CET] <BtbN> if you're only cropping at the top/bottom, it will also be way easier to configure [22:27:23 CET] <durandal_1707> alexpigment: so your video is already padded? [22:27:35 CET] <alexpigment> it's inherently letterboxed [22:28:44 CET] <durandal_1707> alexpigment: so you only need to fill box of black color over some area? [22:28:52 CET] <alexpigment> right [22:29:07 CET] <alexpigment> 720x60 or thereabouts, starting at the top left corner [22:29:34 CET] <durandal_1707> i written fillborders filter just for that [22:29:54 CET] <alexpigment> oh really? [22:29:57 CET] <durandal_1707> need too finish it and push to master [22:29:59 CET] <alexpigment> i guess this isn't committed? [22:30:02 CET] <alexpigment> gotcha [22:30:20 CET] <alexpigment> well, this actually comes up every now and then for me [22:30:48 CET] <alexpigment> a lot of SD programming happens to be letterboxed and people put persistent advertisement crap in the top letterboxed area [22:30:59 CET] <durandal_1707> with it you set borders which you want colored black: top down left right [22:31:01 CET] <alexpigment> so i look forward to your filter [22:31:31 CET] <alexpigment> would it be worth following the model of crop and pad? [22:31:45 CET] <alexpigment> where you specify width:height:xposition:yposition? [22:32:00 CET] <alexpigment> oh, nevermine [22:32:02 CET] <alexpigment> *nevermind [22:32:11 CET] <alexpigment> you're talking about having it always fill from one of the sides [22:32:16 CET] <alexpigment> in which case, that is actually easier [22:34:26 CET] <durandal_1707> thing is you can do that already with vapoursynth and avisynth, and with lavfi with drawbox hack [22:35:18 CET] <alexpigment> vapour/avisynth is on my list of "things to learn" [22:35:22 CET] <alexpigment> just haven't gotten around to it [22:35:45 CET] <alexpigment> as ffmpeg gets better and better, i find less of a need to go outside of its own capabilities [22:49:18 CET] <furq> "drawbox hack"? [22:55:29 CET] <durandal_1707> furq: drawing black boxes around noisy areas [22:55:38 CET] <furq> what's hacky about that [22:55:46 CET] <furq> is it just slow [22:57:06 CET] <durandal_1707> its bit of work [22:57:39 CET] <durandal_1707> i didnt said that drawbox filter is hack [22:57:50 CET] <furq> fair enough [23:31:48 CET] <tolland> Hi, I have an onvif camera sending events data in the rtp stream. ffprobe detects the stream, but its detected as "Stream #0:1: Data: none " and the probe report shows nothing found: https://pastebin.com/3BkvbhGA [23:33:03 CET] <tolland> however there is definitely data coming down, as I can dump it out with gst-launch-1.0 rtspsrc location='rtsp://192.168.0.32:554/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif' ! application/x-rtp, media=application ! fakesink dump=true [23:33:18 CET] <tolland> which produces lots of xml which is what I am expecting [00:00:00 CET] --- Wed Nov 29 2017

1 0

ffmpeg-devel.log.20171127
by burek 28 Nov '17

28 Nov '17

[00:00:15 CET] <philipl> jkqxz: I had gimp save me a jpg and it blew up when I tried to decode it [00:00:26 CET] <philipl> not in nvdec code, mind you... [00:03:59 CET] <philipl> Seems to dislike progressive dct [00:09:29 CET] <philipl> Alright. So I generated single images with gimp across the matrix of (progressive, 420/422/444, integer/float/fast-integer) [00:09:59 CET] <philipl> All the 420 progressive and 444 progressive ones blow up. The rest work, including 422 progressive. [00:10:09 CET] <philipl> It's dying in an avx transform, which I guess doesn't apply to 422 [00:10:27 CET] <philipl> ff_simple_idct8_put_avx [00:10:46 CET] <philipl> corrupted stack trace [00:10:46 CET] <philipl> sad [00:21:40 CET] <philipl> jkqxz: I want to say that the there's a dependency on some step in the decode taking place before the idct works. One of the parameters passed to the idct is 0 with hwaccel and non-zero otherwise. [00:22:21 CET] <atomnuker> why does the idct even run when doing a hardware decode? [00:22:29 CET] <jcdutton> Isn't there a fast transform between mjpeg and H.264 ? Like a half decode then re-encode? [00:22:49 CET] <philipl> atomnuker: I could not say. Perhaps that is the problem. [00:23:19 CET] <philipl> It's happening as part of parsing EOI [00:23:23 CET] <atomnuker> jcdutton: no, both use different dcts [00:23:24 CET] <philipl> but I don't know my jpeg structures. [00:25:25 CET] <jkqxz> Oh, I missed some processing in the progressive case. [00:25:32 CET] <jkqxz> Yeah, it will do something nasty there. [00:26:07 CET] <jkqxz> Will fix. [00:26:16 CET] <philipl> Cheers. [00:27:30 CET] <jkqxz> So nvdec actually supports all of those? [00:29:16 CET] <philipl> everything else worked. [00:29:27 CET] <philipl> I have not tried any kind of lossless as yet [00:35:29 CET] <jcdutton> atomnuker, but I heard there was some short cut in the conversion. [00:41:26 CET] <atomnuker> I guess if you hack the coefficients enough you could get something which resembles the input for h264 baseline (which has 8x8 transforms, high has 4x4) [00:41:48 CET] <jkqxz> Other way around. [00:42:11 CET] <jkqxz> 8x8 transforms are optional in the higher profiles. [00:43:31 CET] <atomnuker> yep [00:43:37 CET] <atomnuker> (but mandatory in lower profiles) [00:44:44 CET] <kierank> other way round [00:44:52 CET] <kierank> baseline and main don't have 8x8 [00:46:08 CET] <jcdutton> I wonder why web cams use mjpeg. I would guess that H.264 with only I-Frames would at least be easier to compress later. [00:47:11 CET] <kierank> you can get to high bitrates with mjpeg [00:47:22 CET] <kierank> whereas with h264 it would be O(cabac) [00:47:31 CET] <jcdutton> I guess mjpeg is just the cheapest to encode. [01:07:23 CET] <c3r1c3-Win> Also keep in mind the patents for h264 on hardware... as far as I know there are none for MJPEG. [01:10:29 CET] <jkqxz> Standardised by ITU in 1992 - should have expired by now if there were. [01:29:50 CET] <atomnuker> jamrial: "It's avx2 and using ymm regs, not avx" <- but its under an if cpuflag(avx) [01:30:41 CET] <jamrial> and as i said in my previous email, that's wrong ang should be avx2 [01:32:28 CET] <jamrial> there are no avx functions, and he's adding an avx2 one [01:32:32 CET] <jamrial> the check works as intended, but as demostrated by your confusion, it should ideally be more specific :p [01:33:35 CET] <atomnuker> ah, I see, yeah that confused me [01:46:20 CET] <jamrial> something broke msvc [01:51:45 CET] <atomnuker> to be fair msvc is already broken :) [01:56:07 CET] <jamrial> that's far from fair :p [01:56:12 CET] <jamrial> http://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=89248-g3701d499f8;hp=892… one of these broke it [01:57:27 CET] <jamrial> none really look related, though [02:06:03 CET] <jamrial> jkqxz: varied undefined references to ff_*_nvdec_hwaccel on --enable-random builds when linking lavc [02:26:11 CET] <cone-822> ffmpeg 03James Almer 07master:921d7af6e9e6: avcodec/mpeg4videodec: fix preprocessor check for the nvdec hwaccel [02:26:12 CET] <cone-822> ffmpeg 03James Almer 07master:1eee394c7c84: avcodec/vc1dec: fix preprocessor checks and hw_configs lists for the hwaccels [02:26:14 CET] <jamrial> jkqxz: ^ [02:33:04 CET] <atomnuker> what the hell is libavcodec/parser.c doing? [02:33:17 CET] <atomnuker> av_first_parser is always NULL [02:33:42 CET] <atomnuker> oh, wait, nvm [02:35:05 CET] <jamrial> atomnuker: are you sure reverting those two commits will not help? it simplifies the functions considerably, removing the last_whatever pointer [02:37:26 CET] <atomnuker> they didn't remove it iirc [02:38:57 CET] <philipl> jamrial: thanks [02:39:03 CET] <jamrial> atomnuker: they added it. i mean that reverting them will remove it [02:39:50 CET] <atomnuker> I'll look at them again [02:41:52 CET] <atomnuker> yeah, 133fbfc7811 isn't going to make things any harder or easier, it maps to just some atomic loads or stores [02:45:22 CET] <jamrial> and reverting ec464c96831, effectively getting rid of the last_avcodec pointer? [02:47:56 CET] <atomnuker> yeah, both aren't too bad but I'll deal with them once I've dealt with parser.c [02:48:09 CET] <atomnuker> any ideas why "static _Atomic AVCodecParser *av_first_parser = NULL;" isn't accepted as input to atomic_load()? [02:48:22 CET] <atomnuker> "error: address argument to atomic operation must be a pointer to _Atomic type ('_Atomic(AVCodecParser) ***' invalid)" [02:49:26 CET] <SortaCore> no brackets and where the * is [02:51:59 CET] <atomnuker> that worked, tnx [02:52:15 CET] <SortaCore> *completely guessed it* [03:28:53 CET] <jamrial> can we please get the amd headers + encoder committed in some form? with or without a concrete policy about external headers, we can decide that latter [03:29:13 CET] <jamrial> but right now we're being kinda unfriendly with a contributor [03:30:07 CET] <atomnuker> I'd rather have a separate repo for these headers if possible [03:32:55 CET] <cone-822> ffmpeg 03Michael Niedermayer 07master:38f966b2222d: tests/checkasm/float_dsp: Increase allowed difference for float_dsp.vector_dmul [03:32:56 CET] <cone-822> ffmpeg 03Michael Niedermayer 07master:3aad94bf2b14: avcodec/kgv1dec: Check that there is enough input for maximum RLE compression [03:32:57 CET] <cone-822> ffmpeg 03Michael Niedermayer 07master:9cc926da7d99: avcodec/h264idct_template: Fix integer overflow in ff_h264_idct8_add [03:32:58 CET] <cone-822> ffmpeg 03Michael Niedermayer 07master:883de7e8b4fe: libavformat/mov: Replace duplicate stream_nb check by assert [03:32:59 CET] <cone-822> ffmpeg 03Michael Niedermayer 07master:97c00edaa043: avcodec/mlpdsp: Fix signed integer overflow, 2nd try [03:33:00 CET] <cone-822> ffmpeg 03Michael Niedermayer 07master:8e7ac4f04903: tests/fate-run: Use -bitexact [03:33:24 CET] <philipl> I'm fine with shipping the header. [03:33:41 CET] <jamrial> again, we can decide that later, as it requires moving the nvenc and avisynth headers to external repos as well [03:35:32 CET] <atomnuker> ok, I'm fine with that [03:36:25 CET] <jamrial> philipl: then please say so in any of the relevant threads. preferably the latest, otherwise carl will eventually drive him mad or angry [03:39:23 CET] <philipl> I said so in one of the threads, as did Btbn, but I'm happy to repeat myself. [03:48:32 CET] <philipl> sent [03:50:04 CET] <jamrial> thanks [04:12:31 CET] <whysohard> Hi guys. For years I couldn't understand. Ffmpeg is very powerful. But it cannot handle with a very simple trim case: Trim end of file.. There are several commands -ss -sseof -t... But it's not sufficient.... There is a question about that: https://stackoverflow.com/questions/31862634/i-need-to-cut-mp4-videos-a-par… The solution is sooo complex. Why dont we have an easy single co [04:15:46 CET] <whysohard> I've thousands of video. All of them are different length. I want only remove last 5 seconds! I could easily if I want to remove FIRST 5 seconds.... The problem is LAST! But the solution is very complex. [04:25:05 CET] <stevenliu> src/libavcodec/nvdec_vp8.c: In function nvdec_vp8_start_frame: [04:25:05 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:68: error: unknown field frame_type specified in initializer [04:25:05 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:68: warning: missing braces around initializer [04:25:07 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:68: warning: (near initialization for (anonymous).CodecSpecific.vp8.Reserved1) [04:25:09 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:69: error: unknown field version specified in initializer [04:25:11 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:70: error: unknown field show_frame specified in initializer [04:25:13 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:70: warning: excess elements in struct initializer [04:25:15 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:70: warning: (near initialization for (anonymous).CodecSpecific.vp8) [04:25:17 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:71: error: unknown field update_mb_segmentation_data specified in initializer [04:25:19 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:71: warning: excess elements in struct initializer [04:25:21 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:71: warning: (near initialization for (anonymous).CodecSpecific.vp8) [04:25:38 CET] <stevenliu> dose this been fixed? or need do something? [04:26:27 CET] <stevenliu> git pull;rm -rf *;../configure --toolchain=valgrind-memcheck --enable-fontconfig --enable-gpl --enable-libx264 --enable-version3 --cc='ccache gcc' --enable-nonfree;make -j16 [04:29:09 CET] <jamrial> what compiler? gcc 7.2.0 doesn't complain [04:29:25 CET] <stevenliu> gcc version 4.4.7 20120313 (Red Hat 4.4.7-18) (GCC) [04:29:54 CET] <stevenliu> CentOS release 6.9 (Final) [04:31:15 CET] <atomnuker> jamrial: ...there isn't even a need for atomics at all in avfilter_register [04:31:19 CET] <atomnuker> fuck [04:31:29 CET] <atomnuker> it doesn't modify any external state [04:31:46 CET] <atomnuker> avpriv_atomic_ptr_cas was just used out of convenience [04:32:06 CET] <atomnuker> because ternary operators are hard [04:34:08 CET] <atomnuker> I'm willing to bet at least one of the other 4 places that function is used is the same [04:43:05 CET] <jamrial> stevenliu: does https://pastebin.com/raw/EBckJSFT fix compilation for you? [04:46:04 CET] <stevenliu> I have disabled_nvdec module , Let me try this patch again :D [04:47:20 CET] <philipl> What misfortune leads you to using such an old compiler? [04:48:06 CET] <jamrial> his OS probably :p [04:48:39 CET] <stevenliu> yes, Centos 6.9, just this reason :D [04:48:55 CET] <stevenliu> ffmpeg won't support on CentOS6.9? [04:49:29 CET] <philipl> What misfortune leads you to using such an old distro? :-) [04:50:15 CET] <stevenliu> ffmpeg won't support on CentOS6.9? [04:50:36 CET] <stevenliu> jamrial: src/libavcodec/nvdec_vp8.c:68: error: unknown field wFrameTagFlags specified in initializer [04:50:55 CET] <jamrial> :/ [04:51:03 CET] <stevenliu> have problem always :D, maybe this should disabled default? [04:51:39 CET] <jamrial> obviously not [04:51:50 CET] <jamrial> philipl: why is CUVIDVP8PICPARAMS so different than the rest, for that matter? [04:52:11 CET] <philipl> it has a bit field in an anoymous union. [04:52:17 CET] <philipl> only one that has it, [04:52:26 CET] <jamrial> i know, i'm asking why :p [04:52:37 CET] <philipl> onky nvidia can answer that [04:52:42 CET] <jamrial> it's like they went all "we must make this struct small. 8 bits for four fields!" [04:52:48 CET] <jamrial> then they did the hevc one [04:52:51 CET] <jamrial> with huge arrays [04:53:10 CET] <philipl> Yeah. clearly implementation details leaking through [04:53:35 CET] <philipl> vp8 isn't important enough to get more than one byte. [04:54:44 CET] <philipl> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676 [04:55:08 CET] <philipl> It was fixed a long time ago, but centos 6 is even older. [04:55:19 CET] <philipl> Will need to switch to dynamic initialisation. [04:55:55 CET] <philipl> I still think it's nuts to be using centos 6 in this day and age, of course. [04:56:21 CET] <stevenliu> I complie ffmpeg have no problem before, on centos 6 [04:56:35 CET] <jamrial> we have a lot of < 4.6 fate clients, though [04:58:03 CET] <philipl> stevenliu: humour me: why do use centos 6? [04:58:34 CET] <stevenliu> always using it online, no why [04:59:01 CET] <philipl> This gcc feature was added 7 years ago. [04:59:11 CET] <philipl> It's crazy. [04:59:18 CET] <stevenliu> we don't want to change to newest version, there have unstable factor. [05:00:42 CET] <philipl> I'll start by saying I'll fix this, but it'll cost you a rant about ancient distros and compilers. [05:00:44 CET] <stevenliu> If use only at local, i can use newest version, but that is online system, support more and more user, we need more and more time to try the stable. [05:01:19 CET] <philipl> gcc 4.4.3 is what? 10 years old; it's obviously a facetious argument to suggest it's the last stable gcc. [05:01:52 CET] <stevenliu> no matter, i don't care that, i know use disable-nvdec, i just want say ,there have lots of centos 6 user, i don't know if they know use --disable-nvdec [05:02:14 CET] <philipl> I know. It's not your fault. It's redhat's fault. [05:02:29 CET] <philipl> They start with old components, then make a release that's supported for 10 years from them. [05:02:34 CET] <stevenliu> fix it please :D [05:03:40 CET] <philipl> jamrial: actually, why doesn't this initialization blow up on windows? Or fate hasn't fired yet? [05:03:59 CET] <jamrial> it works fine here with mingw-w64 [05:04:07 CET] <jamrial> and msvc is currently broken for unrelated reasons [05:09:19 CET] <philipl> jamrial: http://paste.ubuntu.com/26055929/ [05:09:29 CET] <philipl> bah. Ignore. has extra crap [05:09:54 CET] <philipl> http://paste.ubuntu.com/26055932/ [05:09:55 CET] <philipl> that's better [05:11:28 CET] <jamrial> still compiles fine with mingw-w64 [05:11:51 CET] <jamrial> also, it's decrepit, not decrepid :p [05:12:15 CET] <philipl> foiled. [05:12:16 CET] <philipl> Will fix [05:13:37 CET] <jamrial> stevenliu, StevenLi_: can you try http://paste.ubuntu.com/26055932/ ? [05:13:43 CET] <stevenliu> src/libavcodec/nvdec_vp8.c: In function nvdec_vp8_start_frame: [05:13:43 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:76: error: CUVIDVP8PICPARAMS has no member named frame_type [05:13:43 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:77: error: CUVIDVP8PICPARAMS has no member named version [05:13:45 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:78: error: CUVIDVP8PICPARAMS has no member named show_frame [05:13:47 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:79: error: CUVIDVP8PICPARAMS has no member named update_mb_segmentation_data [05:13:49 CET] <stevenliu> src/libavcodec/qtrleenc.c: In function qtrle_encode_frame: [05:14:54 CET] <philipl> I'm tempted to add a gcc check and say you don't get vp8 if your gcc is old and busted [05:14:59 CET] <philipl> This is ridiculous [05:15:06 CET] <jamrial> do that [05:15:16 CET] <stevenliu> That is better way :) [05:15:30 CET] <stevenliu> check if the gcc is ok :D [05:15:39 CET] <philipl> We could also patch in names for the anonymous inners... [05:16:07 CET] <philipl> but we have nice gcc check macros so I'll do that. [05:20:01 CET] <philipl> jamrial: if I wanted to do this properly, I'd add a configure dependency [05:20:27 CET] <philipl> It doesn't look like we have the right kind of test ready to do [05:25:43 CET] <philipl> Oh man. [05:25:48 CET] <philipl> This is ridiculous. [05:30:41 CET] <atomnuker> jamrial: sent patches which remove all but the last usage of that function [05:30:53 CET] <atomnuker> as it turned out NONE of the cases did require atomics [05:31:05 CET] <atomnuker> so that function did nothing but slow down registration [05:31:27 CET] <atomnuker> the last case doesn't look like it needs the function as well [05:33:14 CET] <jamrial> so only the lock manager stuff remains after this? [05:35:03 CET] <atomnuker> yeah [05:36:44 CET] <atomnuker> avpriv_atomic_ptr_cas(mutex, *mutex, NULL); [05:36:47 CET] <atomnuker> omfg [05:37:17 CET] <atomnuker> this is essentially *mutext = *mutex == *mutet ? NULL : *mutex; [05:37:53 CET] <atomnuker> and before that there's a av_free(*mutex); [05:38:13 CET] <atomnuker> so just changing it to freep and removing the cas crap is enough for one of the two uses [05:43:03 CET] <philipl> jamrial: http://paste.ubuntu.com/26056061/ [05:43:16 CET] <philipl> That's an attempt at using explicit braces, which is supposedly a workaround. [05:43:34 CET] <philipl> Can you at least test it on what you have [05:44:40 CET] <jamrial> seems to work on mingw-w64 [05:44:53 CET] <atomnuker> jamrial: okay, sent over the last patch, now there's absolutely no usage of any avpriv_atomic stuff [05:45:01 CET] <atomnuker> I'll leave you with the honor of removing them [05:45:08 CET] <atomnuker> because I'm going to bed [05:45:38 CET] <philipl> jamrial: I'm going to push it then. fate is unfortunately hosed so I don't think we'll get a reading there for a while. [05:45:48 CET] <philipl> stevenliu: can you try that patch? [05:45:53 CET] <philipl> http://paste.ubuntu.com/26056061/ [05:49:19 CET] <tyng> durandal_1707 when i use the ffmpeg dnxhd muxer at 24fps it then interpret the file as 25fps [05:51:45 CET] <tyng> get https://comfy.moe/mzsucy.mkv and try -c:v copy -f data at 24fps then ffprobe it back as 25fps [05:53:00 CET] <cone-822> ffmpeg 03Philip Langdale 07master:b93d96a07be4: avcodec/nvdec: Make vp8 initialisation more 'compatible' [05:53:23 CET] <philipl> stevenliu: I've pushed it, and hopefully it works. I'd really appreciate it if you could try it out. [05:53:45 CET] <philipl> There are a couple of other possible ways to work around it but this is the least disruptive one if it works [06:12:40 CET] <stevenliu> src/libavcodec/nvdec_vp8.c: In function nvdec_vp8_start_frame: [06:12:40 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:72: warning: braces around scalar initializer [06:12:41 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:72: warning: (near initialization for (anonymous).CodecSpecific.vp8.Reserved1[0]) [06:12:42 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:73: error: field name not in record or union initializer [06:12:44 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:73: error: (near initialization for (anonymous).CodecSpecific.vp8.Reserved1[0]) [06:13:16 CET] <stevenliu> have a lunnch, come back now. [06:24:35 CET] <philipl> stevenliu: well, that's progress, I think. I'll send you another patch [06:26:41 CET] <philipl> stevenliu: http://paste.ubuntu.com/26056297/ [06:47:58 CET] <stevenliu> compling [06:48:43 CET] <stevenliu> this patch is ok mpw [06:48:50 CET] <stevenliu> this patch is ok now [06:49:50 CET] <philipl> *phew* [06:49:53 CET] <philipl> Thanks for testing. [06:49:55 CET] <philipl> I will push [07:00:59 CET] <philipl> stevenliu: If you would be so kind, could I ask you to retry without the last patch (ie: try with current master) [07:01:10 CET] <philipl> I booted a centos6 VM and I can't see why the previous logic wouldn't work [07:21:34 CET] <cone-822> ffmpeg 03Philip Langdale 07master:0e93694e64cd: avcodec/nvdec: More effort to make vp8 compile with gcc < 4.6 [07:22:19 CET] <philipl> Well, I've pushed the second fix. Perhaps some day I'll be in a position to test a full compile and see if I can refine it, but at least it compiles now [09:14:17 CET] <cone-822> ffmpeg 03Tobias Rapp 07master:26c0c84784f1: avformat/avienc: fix fields-per-frame value for interlaced video streams [09:37:57 CET] <stevenliu> Ah, come back from hospital :D [09:38:15 CET] <stevenliu> of course, philipl [09:51:42 CET] <nevcairiel> philipl: thats why i really dont like this struct init syntax all the nvdec stuff uses =p [09:53:10 CET] <nevcairiel> without the explicit names like in the last change, it even becomes quite unreadable [09:58:23 CET] <nevcairiel> hm one of those atomic commits broke msvc compiling [10:08:01 CET] <nevcairiel> oh its because windows.h has #define near [10:16:02 CET] <rcombs> forgot to WIN32_LEAN_AND_MEAN? [10:18:22 CET] <nevcairiel> nah thats unrelated to that [10:19:18 CET] <nevcairiel> far and near are decades old keywords from 16-bit days and memory segmenting, so instead of having people remove them, they just defined them to empty <.< [11:08:36 CET] <BtbN> Does only the VP8 hwaccel fail with old gcc? None of the others? [11:09:28 CET] <nevcairiel> apparently they forgot to name some of the inner structs [11:26:10 CET] <gmoryes> Hello, if I want to know the version of libavcodec, I should look to output of command "ffmpeg", and "libavcodec 56. 60.100 / 56. 60.100" the first number "56." - version? Am I right? [11:26:41 CET] <BtbN> 56.60.100 is the version [11:27:42 CET] <gmoryes> thanks! [12:52:16 CET] <jkqxz> AMF encoder using proper headers: <http://sprunge.us/aPiQ>. [12:52:32 CET] <jkqxz> I haven't tested it on Windows yet, I'll do that later and send it to the ML. [12:52:36 CET] <jkqxz> But it works fine on Linux. [12:53:11 CET] <jkqxz> (Where "works" means "builds but fails immediately at runtime because there is no library".) [12:57:50 CET] <nevcairiel> should AV_PIX_FMT_D3D11 in ff_amf_pix_fmts be conditional on d3d11 support being build? i did it like that in nvenc, dont want to claim to support it if its not build in [12:59:59 CET] <jkqxz> Not sure it matters much? [13:00:06 CET] <jkqxz> Probably more consistent, though. I'll change it. [13:56:13 CET] <cone-097> ffmpeg 03Paul B Mahol 07master:9152bda839c5: avfilter/af_silenceremove: fix logic error in EOF case [14:09:38 CET] <cone-097> ffmpeg 03Carl Eugen Hoyos 07master:b7324950c0fc: lavd/alsa: Double maximum alsa buffer size. [16:03:29 CET] <philipl> BtbN: it's just vp8. The rest are sane. [16:11:07 CET] <jamrial> nevcairiel: do you know what could have broken msvc? [16:11:47 CET] <jamrial> apparently it was one of these http://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=89248-g3701d499f8;hp=892… but none touch jpegls [16:12:08 CET] <nevcairiel> [10:08:00] <nevcairiel> oh its because windows.h has #define near [16:12:26 CET] <nevcairiel> .. and the atomic changes pull in windows.h in more files [16:12:45 CET] <SortaCore> near is from 16-bit days isn't it? [16:12:58 CET] <nevcairiel> [10:19:18] <nevcairiel> far and near are decades old keywords from 16-bit days and memory segmenting, so instead of having people remove them, they just defined them to empty <.< [16:13:28 CET] <SortaCore> yay [16:13:44 CET] <SortaCore> slap an #undef band-aid on it [16:19:05 CET] <iive> far pointers should still exists in 32 and 64 bit x86. they are a couple of segment register and (32/64) offset. [16:19:51 CET] <SortaCore> if it's defined to blank then it has no effect though? [16:21:13 CET] <nevcairiel> with virtual memory stuff, you dont have to deal with that anymore, someone else does it for you, and 64-bit has enough pointer space to address quite a lot of memory directly either way [16:25:43 CET] <iive> in 32 bit the offset is relative to the segment start address [16:26:06 CET] <iive> in 64 bit the offset is relative to the effective address space (aka memory after paging) [16:27:13 CET] <iive> still segments exists and could/are used for different things. e.g. PIC used a special segment to hold some tables [16:28:30 CET] <iive> or making the stack segment non-executable. [16:30:04 CET] <iive> it was possible to have segment+offset pointer is modern C, but I don't remember details about it. [16:31:18 CET] <nevcairiel> possible perhaps, but the point is, you just dont [16:31:25 CET] <nevcairiel> its all done under the hood [16:34:19 CET] <cone-097> ffmpeg 03Paul B Mahol 07master:2d1594a8d6a7: avfilter/af_silenceremove: fix possible crash if supplied duration is negative [16:55:06 CET] <BtbN> isn't there some LEAN_AND_MEAN define, to get rid of some of the cruft? [16:55:32 CET] <philipl> I remember that from the mid 90s... [16:58:07 CET] <philipl> nevcairiel: Regarding the messy static initialisation - I tried doing regular field assignment through a pointer but it apparently generated errors too - I'm not aware of what syntax you use if the names are not automatically resolved through the anonymous inners. [17:23:31 CET] <atomnuker> jamrial / michaelni: can you review the atomics patches? [17:40:48 CET] <cone-097> ffmpeg 03James Almer 07master:9d464dc3fccb: avformat/matroskaenc: actually enforce the stream limit [17:49:29 CET] <atomnuker> "I would prefer if the bundled external headers were installed together with ffmpeg public headers" [17:49:33 CET] <atomnuker> what is that guy on? [17:50:29 CET] <kierank> that's really annoying [17:50:41 CET] <kierank> it means you get these silly nvidia devices on by default [17:50:51 CET] <jkqxz> Sounds like someone who actually wants the external repo with the cleaned headers. [17:50:58 CET] <jkqxz> Rather than them being in ffmpeg at all. [17:51:31 CET] <jkqxz> (Being able to use them in other projects was one of the arguments for that.) [17:51:47 CET] <durandal_1707> help me find out ideas for new filters! [17:51:58 CET] <kierank> durandal_1707: add new cineform features [17:53:34 CET] <durandal_1707> cineform? only if i get paid [17:55:02 CET] <kierank> get that guy to pay you [17:55:45 CET] <kierank> though actually the files that use the temporal transform are historical files, probably no commercial value [18:00:46 CET] <iive> durandal_1707: do we have a filter that syncs two video streams visually? e.g. if we have 2 inputs that are off by a few frames, make so similar/identical frames have same timestamps. [18:02:28 CET] <jamrial> durandal_1707: like i said the other day, tilt shift? [18:05:56 CET] <cone-097> ffmpeg 03Paul B Mahol 07master:eb86f72fcaf3: avfilter/vf_threshold: use correct linesize [18:07:43 CET] <durandal_1707> jamrial: what? [18:07:56 CET] <jamrial> suggestion for a filter [18:19:00 CET] <BtbN> jkqxz, no, he actually wants to make them public headers. [18:19:05 CET] <BtbN> Which is silly and not going to happen. [18:19:25 CET] <BtbN> I won't watch over API/ABI compatiblity for nvidias headers. [19:01:48 CET] <durandal_1707> jamrial: imagemagick have it, its basically mix of blured and normal with saturation and contrast boosted [20:49:32 CET] <jdarnley> Can I do this operation with palignr? https://pastebin.com/zxc0gDup [20:50:41 CET] <jdarnley> Gramner, jamrial, atomnuker, durandal_1707 ^ [20:54:15 CET] <iive> jdarnley: looks like something exactly for palign [20:54:34 CET] <iive> assuming +16 is +mmsize [20:55:14 CET] <iive> or maybe use xm0 [20:56:02 CET] <jamrial> jdarnley: i think yes, palignr m1, m0, m2, 4 or so [21:00:01 CET] <iive> the shift is in bytes, so 12 it is. [21:31:19 CET] <atomnuker> jdarnley: >using crap outdated notation for registers [21:32:47 CET] <atomnuker> use r0-r7, only old people who haven't seen the light of x86inc.asm use those names [21:37:41 CET] <rcombs> use r0-r15 nobody cares about 32-bit x86 [21:40:00 CET] <omerjerk> Is there something I can work on? Kind of done with my ALS codec related work. [21:40:14 CET] <atomnuker> learn assembly [21:40:19 CET] <durandal_1707> omerjerk: encoder? [21:40:52 CET] <Compn> durandal_1707 : how goes bayer rgb support ? :) [21:40:56 CET] <Compn> r3dcode... [21:41:03 CET] <omerjerk> durandal_1707: It's done from my side. Waiting for Thilo to review the patch. [21:41:23 CET] <durandal_1707> Compn: bayer is on hiatus [21:42:04 CET] <omerjerk> atomnuker: I know basic stuff. Do you have something in mind for me? [21:42:24 CET] <durandal_1707> fun project: add gui for filtering [21:43:04 CET] <omerjerk> okay.... [21:43:28 CET] <atomnuker> omerjerk: how about some debugging? [21:43:33 CET] <atomnuker> the mlp decoder has issues [21:43:42 CET] <atomnuker> it has some sort of an overflow happening [21:43:57 CET] <atomnuker> and that causes a pop to appear once every few seconds [21:44:01 CET] <jamrial> and the mlp encoder is broken. too many scenarios where it's not bitexact [21:44:21 CET] <atomnuker> erm yeah, I meant encoder, not decoder [21:45:11 CET] <atomnuker> I haven't been able to figure out where the issue is [21:45:48 CET] <omerjerk> okay. [21:46:00 CET] <omerjerk> is there a bug on the trac which I can pick up? [21:46:05 CET] <durandal_1707> you use address sanitizer to check fo overflows at runtime [21:46:27 CET] <omerjerk> I mean bug for exactly this issue? [21:48:03 CET] <omerjerk> Is there a ticket for this issue on trac.ffmpeg? [21:48:36 CET] <durandal_1707> nope [21:48:48 CET] <omerjerk> okay. [21:48:59 CET] <durandal_1707> you just try encoding file [21:49:13 CET] <omerjerk> okay. [21:49:50 CET] <durandal_1707> no need to type okay each time:its little creppy [21:50:25 CET] <omerjerk> ._. [21:50:36 CET] <durandal_1707> :) [21:51:42 CET] <jamrial> i opened a ticket about it some time ago [21:52:39 CET] <jamrial> there, ticket 6216 [22:04:14 CET] <durandal_1707> atomnuker: why it eats last packet without producing output? [22:04:32 CET] <atomnuker> it does? [22:06:06 CET] <durandal_1707> compare framemd5 asetnsamples=1024 output of any stereo file encoded by that codec [22:06:34 CET] <durandal_1707> i see in code it simply returns 1 [22:09:16 CET] <atomnuker> yeah, that's a problem [22:09:50 CET] <atomnuker> right, erm, finders keepers so since you found it its up to you to fix it :) [00:00:00 CET] --- Tue Nov 28 2017

1 0

ffmpeg.log.20171127
by burek 28 Nov '17

28 Nov '17

[00:16:04 CET] <JEEB> SortaCore: I'm pretty sure there's a thing on "if you don't have any user interface then blah blabh" [00:24:24 CET] <ZexaronS> Hello [00:26:58 CET] <ZexaronS> I have trouble with MPEGTS muxing when doing a test, the original TS is a bit broken (doesn't start on keframe) but encoders can deal with it, so I put it to MKVToolNix, made sure DVBSUB is supported as of this year, good, out to MKV and then used ffmpeg to mux/copy everything back to TS [00:27:21 CET] <ZexaronS> but it produces a laggy file, both VLC and MPC-HC look the same [00:28:56 CET] <ZexaronS> I'll also try testing with a recoded MKV, which was origTS -> Handbrake -> MKV1 -> MKVToolnix Add DVBSub from origTS -> MKV2 -> ffmpeg-MPEGTS [00:29:47 CET] <ZexaronS> So the laggy example was, origTS -> MKVToolnix do nothing (copy all streams) -> MKV - > ffmpeg-MPEGTS [00:30:31 CET] <ZexaronS> ffmpeg -loglevel verbose -i input.mkv -vcodec copy -acodec copy -scodec copy -threads 0 -f mpegts output.ts [00:35:58 CET] <ZexaronS> oh it may be framerate .. maybe i need to force, it's interlaced source [00:36:05 CET] <ZexaronS> no dropped frames [00:36:21 CET] <ZexaronS> 25, it should be 50 fps [00:36:38 CET] <ZexaronS> hopefully it's an easy fix [00:38:37 CET] <ZexaronS> I was trying to find which options ffmpeg has for mpegts that are for mux only [00:40:26 CET] <ZexaronS> actually, maybe it doesn't play here right, but it will on tv, but doubt it, it'll be played with the video player, not the tvs internal DVB player from signal [00:46:47 CET] <ZexaronS> well that's truncated fps, oh ok, 25 is right, [00:50:06 CET] <ZexaronS> could be some timestamp issue, but i can see the audio sync is just fine, it feels as if half the frames get dropped [00:59:00 CET] <ZexaronS> Oh [00:59:25 CET] <ZexaronS> jitter is at 54 ms in the muxed one, original has 0 to 1 ms most of the time [02:08:53 CET] <ZexaronS> OH the test where recoding is involved seems to fix it - Handbrake gets rid of most of the corrupted bits [03:34:26 CET] <yukiup> this is my current command: "ffmpeg -i in.mkv -c:v hevc_nvenc -c:a libopus -b:a 320k -ac 2 -c:s copy out.mkv" [03:34:42 CET] <yukiup> any suggestions to imrpove the quality of dark black scenes? [04:08:56 CET] <whysohard> Hi guys. For years I couldn't understand. Ffmpeg is very powerful. But it cannot handle with a very simple trim case: Trim end of file.. There are several commands -ss -sseof -t... But it's not sufficient [04:09:34 CET] <whysohard> There is a question about that: https://stackoverflow.com/questions/31862634/i-need-to-cut-mp4-videos-a-par… [04:10:13 CET] <whysohard> The solution is sooo complex. Why we dont have an easy single command :( [05:03:56 CET] <sado[de]> Hi [05:05:55 CET] <sado[de]> I have video files in mp4 and i can't play them, the moov atom isn't found, for this error it worked. Have someone an idea to repair it with ffmpeg ? [05:06:11 CET] <sado[de]> ... before this ... [05:07:48 CET] <sado[de]> mom reconnect [05:23:31 CET] <TheRock> decoder=avi,wma,ogg,wmv,vp8,vp9,opus,vorbis,vc1,mpegvideo,flv,mp3,aac,h264,mpeg2video,mpeg4,asf,swf,mov,wav [05:23:37 CET] <TheRock> which one enables h263 ? [05:24:04 CET] <TheRock> i added some decoders and h263 is now listed in configure overview [05:24:42 CET] <TheRock> --enable-demuxer=wmv,ogg,vc1,m4v,flv,mp3,aac,avi,h264,matroska,mov,m4v,rawvideo,wav,mpegvideo,wma,asf,swf,vp8,vp9 [05:24:50 CET] <TheRock> i know some of them dont exist [05:25:00 CET] <TheRock> but it's just for safety [05:40:16 CET] <sado[de]> sry for reconnect [05:41:21 CET] <sado[de]> Is it possible to repair a mp4 with missed atom section with ffmpeg ? [11:49:14 CET] <fps> cann i call av_register_all more than once per process? [12:39:01 CET] <fps> or put more technically. are these functions idempotent_ [12:39:05 CET] <fps> avcodec_register_all(); [12:39:05 CET] <fps> av_register_all(); [12:39:05 CET] <fps> avformat_network_init(); [12:39:59 CET] <DHE> it is, but it isn't thread-safe [12:47:36 CET] <fps> DHE: ok, ty [14:12:18 CET] <Nacht> Is it possible to get ffmpeg's output in JSON, just like ffprobe ? [14:12:32 CET] <JEEB> no [14:12:40 CET] <JEEB> it's not supposed to be machine-parsed [14:12:54 CET] <Nacht> Hmm. That's a shame [14:13:33 CET] <Nacht> ffprobe isn't giving me the correct clip length, due to it being an estimate, so I thought I'd just use ffmpeg to get the correct length [14:13:56 CET] <JEEB> -show_frames is what you want then [14:14:01 CET] <JEEB> which will decode the pictures [14:14:09 CET] <Nacht> Ah cheers [14:15:15 CET] <DHE> but it does raise CPU requirements and takes time to run since it literally decodes the video/audio in memory [14:15:22 CET] <BtbN> that can take _a long time_ though, depending on what you are decoding there [14:18:55 CET] <Nacht> So be it. I'm using it to calculate the -ss & -t time. So it has to be accurate [14:55:44 CET] <furq> Nacht: -count_frames, not -show_frames [16:26:59 CET] <kepstin> i think -count_frames doesn't decode, it only demuxes. But still, high io requirement since it has to read the whole file [16:38:17 CET] <yvi> playback with mplayer -benchmark seems to be the best way to reduce latency (coming from ffmpeg x11grab->x265 encode->pipe->mplayer) according to my (simplistic) measurements..can i replicate whatever it does with ffplay/ffmpeg [16:38:59 CET] <yvi> using ffplay or ffmpeg (with -f sdl) i can get around 100ms best case [16:39:47 CET] <yvi> also i can't seem to make kmsgrab work..none of the examples work for me [16:43:43 CET] <yvi> more like 120ms+ actually..with mplayer its half that [16:44:43 CET] <yvi> this is for sending desktop over the network..at first i thought i had delays at the encoder/network but the buffering of all the fucking players is just terrible [16:45:25 CET] <JEEB> normal players generally aren't by default suited for low latency usage [16:45:35 CET] <JEEB> nor is libavformat or libavcodec by default [16:47:30 CET] <bencoh> libavcodec is fine actually [16:59:30 CET] <JEEB> bencoh: for encoding you might have to configure things [16:59:39 CET] <JEEB> for decoding yea [16:59:44 CET] <JEEB> you generally get as good as you get [17:00:55 CET] <xuing> Hello https://github.com/openwrt/packages/issues/5181 May I help?.Thanks. [17:04:12 CET] <yvi> have zero problems with encoding latency [17:04:30 CET] <fps> xuing: do you want to help? or do you want to get help [17:04:30 CET] <fps> ? [17:04:48 CET] <yvi> seems to be that mplayer is the only player that can actually do this for some reason [17:05:10 CET] <yvi> i tried mpv also with untimed, no demuxer readahead, no caches etc.. not working [17:05:32 CET] <xuing> sorryMy English is very poor [17:05:40 CET] <xuing> I mean I need a help [17:10:31 CET] <bencoh> JEEB: ah, for encoding libavcodec is terrible yeah :) [17:10:41 CET] <JEEB> well as terrible as any other thing to be honest [17:10:50 CET] <JEEB> since most encoders just are by default not latency optimized [17:10:53 CET] <bencoh> s/encoding/low latency encoding/ mybad [17:11:23 CET] <JEEB> in theory I think you can get the lavc libx264 layer to as low latency as x264 permits, I think? although not sure about the separate slice outputs [17:11:43 CET] <JEEB> you might need to wait until a picture is fully encoded so you can get the AVPacket [17:11:54 CET] <atomnuker> bencoh: kierank has some patches to support the equivalent of draw_horiz_band in encoding [17:12:01 CET] <bencoh> oh :) [17:12:09 CET] <bencoh> JEEB: that, and some vbv issues [17:13:02 CET] <JEEB> yea but that isn't avcodec specific, is it? [17:13:12 CET] <bencoh> afaicr (that was a few years ago) avcodec doesn't pass along all the vbv information needed for muxing [17:13:13 CET] <JEEB> unless it's one of the internal encoders which I have no idea of :D [17:13:37 CET] <bencoh> (while directly calling x264 "just worked" fine) [17:13:52 CET] <JEEB> yea, MPEG-TS mux rate is separate and UDP's bitrate are separate [17:14:22 CET] <JEEB> if you set maxrate/bufsize those are set into the avcodec context and thus applied to libx264 [17:14:40 CET] <JEEB> (plus you have the x264-params thing if you need something not available through lavc's struct) [17:14:42 CET] <bencoh> yep, but you're still missing per-frame information back from the encoder [17:14:56 CET] <bencoh> (at least that's what I recall from back then) [17:15:35 CET] <JEEB> if you need the nal-hrd vbr stuff that has to be enabled specifically in x264 cli , libx264 and of course lavc [17:15:49 CET] <JEEB> it doesn't "just work" with x264 or libx264 either [17:16:23 CET] <JEEB> and it's highly unlikely that libavcodec strips some things out of the bit stream given to you by libx264, although theoretically that is possible [17:17:05 CET] <bencoh> no it doesn't strip anything, it was metadata available in the picture struct iirc [17:19:41 CET] <bencoh> although I can't seem to find what, which has me confused now [17:28:53 CET] <JEEB> bencoh: nal-hrd vbr/cbr output extra stuff [17:29:01 CET] <JEEB> which contain the current state of the NAL-HRD stuff [17:52:04 CET] <Cracki> cheers. where would I submit a feature request for the dshow input device? got a hardware-h264-capable webcam and would like to set its bitrate too. I've found some relevant places in the code [17:52:35 CET] <Cracki> namely libavdevice/dshow.c:1284 (static const AVOption options[]) [17:53:02 CET] <Cracki> and anything that uses the VIDEO_STREAM_CONFIG_CAPS structure from dshow [17:53:43 CET] <Cracki> that thing _has_ Min/MaxBitsPerSecond and a debug-guarded print output in the dshow module also lists these values [17:53:55 CET] <Cracki> however I see nothing that sets them [17:59:34 CET] <Cracki> seems the cli argument parsing puts the given values into a struct dshow_ctx, which might need extending too [18:05:47 CET] <Cracki> I think 'dshow_cycle_formats' is where most of the work needs to be [18:06:19 CET] <Cracki> I am not sure I am set up to build ffmpeg myself (on windows), but I might try... [18:26:09 CET] <fps> yvi: do you have libshine installed? [18:28:12 CET] <TheRock> player.audio()->setVolume(100); [18:28:17 CET] <TheRock> is that normal that the sound is so loud [18:28:24 CET] <TheRock> that my notebook virbates ? [18:28:35 CET] <TheRock> i never heard such a loud sound from my notebook [18:33:14 CET] <alexpigment> TheRock: if your notebook vibrates at max volume, then that's just something you have to accept about your notebook. There's nothing software-wise that can increase the volume of playback above what the driver already considers to be 100% [18:34:20 CET] <alexpigment> also, keep in mind that most audio is not brickwalled at 0db. a lot of the content out there sits between -6db and -3db, maybe peaking near 0db at points [18:34:51 CET] <alexpigment> if you have a highly compressed audio track and you normalize it to 100%, it's going to be louder than most things you hear [18:35:06 CET] <TheRock> i'm just wondering, because if i dont set the volume and control it through windows, the sound is not loud as when i set it in the software with 100 [18:36:26 CET] <alexpigment> TheRock: out of curiosity, what is the scale of setVolume? [18:36:54 CET] <TheRock> the libray has 0-100 [18:37:03 CET] <TheRock> and if i dont set it, the windos volume is usedd [18:37:11 CET] <alexpigment> what if you set it to 1? [18:38:10 CET] <TheRock> setVolume(1) is quite loud [18:38:11 CET] <alexpigment> if it works on the same scale as the audio volume filter in FFMPEG, then 1 is 100% [18:38:24 CET] <alexpigment> try 0.5 [18:38:27 CET] <alexpigment> see if it's half volume now [18:38:43 CET] <TheRock> and 100 is louder than a jet engine [18:39:45 CET] <TheRock> you are right [18:39:50 CET] <TheRock> 0.05 - 1 [18:39:53 CET] <TheRock> is normal [18:40:58 CET] <alexpigment> ok, then 100 is simulating what I described above, which is a brick-walled track at 0db. kinda the theoretical max volume of your computer [18:43:14 CET] <TheRock> yeah [18:43:15 CET] <TheRock> at 100 [18:43:25 CET] <TheRock> you don't even understand the words of the movie [18:43:48 CET] <alexpigment> yeah, intelligibility requires dynamics ;) [18:44:06 CET] <TheRock> so i could shock my app users [18:44:10 CET] <TheRock> by setting it to 100 [18:44:21 CET] <alexpigment> just call it "distortion" and sell it as a feature ;) [18:44:42 CET] <alexpigment> "I've digitally recreated a guitar distortion pedal in this app" [18:46:13 CET] <TheRock> :P [19:08:35 CET] <devinheitmueller> Question: if I need a generic FIFO for AVPackets, is there some existing implementation I should be using? Should I be trying to reuse av_fifo_generic*() ? [19:12:11 CET] <thebombzen> is there any easy way to combo -vf cropdetect with -vf crop? or does that require two passes and copy/pasting by hand? [19:12:54 CET] <thebombzen> I mean I could always run -vf cropdetect and output to null, copy/paste from the terminal, but I was looking for a way to perhaps expedite the process (or rather, what I really want is to make it more scriptable) [19:13:21 CET] <BtbN> no [19:17:52 CET] <thebombzen> is there a way to have ffmpeg.c output the cropdetect info in a more machine-parseable way? [19:19:16 CET] <devinheitmueller> Feels like the sort of case where you would want cropdetect to set frame metadata, which can then be consumed by the crop filter. [19:19:49 CET] <devinheitmueller> Oh look, cropdetect does set metadata! [19:19:55 CET] <devinheitmueller> SET_META("lavfi.cropdetect.x1", s->x1); [19:20:17 CET] <BtbN> that won't work [19:20:29 CET] <BtbN> The frame dimensions have to be known, you cannot change them on the fly [19:21:22 CET] <devinheitmueller> BtbN: Presumably that would depend on the output format. Some out formats/codecs do support frame dimension changes. [19:21:50 CET] <devinheitmueller> Let me rephrase - the specs for some codecs support frame dimension changes. No idea if ffmpegs implementation of such codecs do. [19:21:53 CET] <BtbN> none that are in ffmpeg [19:22:06 CET] <BtbN> And I'm pretty sure filtergraphs and ffmpeg.c don't support it either [19:23:11 CET] <devinheitmueller> Continues to amaze me how some things that happen all the time in broadcast television are seen as some weird/wacky edge case in the eyes of ffmpeg. :-) [19:23:29 CET] <JEEB> decoders can output different sized frames just fine [19:23:39 CET] <JEEB> at least stuff like H.264 [19:23:48 CET] <JEEB> the issue really is the rest of the business like lavfi [19:23:52 CET] <thebombzen> could you handle it with something like sendcmd? [19:24:00 CET] <BtbN> no [19:24:02 CET] <JEEB> ffmpeg.c is a completely separate thing [19:24:08 CET] <JEEB> and other pile of lulz [19:24:29 CET] <devinheitmueller> JEEB: Yeah, I can imagine things like resolution changing after the filtergraph has been setup can cause some confusion (i.e. in principle you may need to renegotiate the pipeline) [19:24:30 CET] <BtbN> For filters, the output resolution has to be known when config is called on the outlink [19:24:38 CET] <BtbN> which iirc happens before even a single frame is fed [19:24:55 CET] <thebombzen> I say "scriptable" but realistically I'm just calling ffmpeg.c from a language that isn't C/C++ [19:25:08 CET] <JEEB> devinheitmueller: yea [19:25:10 CET] <thebombzen> it's easier to call ffmpeg.c than it is to deal with bindings to libav* from high level languages [19:25:58 CET] <thebombzen> either way, would it be possible to use vf cropdetect to generate a crop filter for one frame, and then use that for vf_crop without changing it? [19:26:02 CET] <JEEB> devinheitmueller: that said if you control your own flow you can do that just fine. flush the filter graph and re-create it if necessary. of course it would be better if lavfi could handle it nicer but it is handle'able [19:26:30 CET] <JEEB> devinheitmueller: for broadcast stuff the limitations start appearing in things like "you cannot add streams after you've done av_write_header" [19:26:39 CET] <devinheitmueller> I continue to look for good libav* bindings in any high level language. Recommendations welcome. [19:27:05 CET] <JEEB> I think I tested some python bindings generator some time ago that was not as backwards as SWIG [19:27:11 CET] <devinheitmueller> JEEB: you can add streams after av_write_header if a flag is set, but I think the problem is really there is no way to *remove* streams. [19:27:33 CET] <JEEB> yea, that too [19:27:34 CET] <devinheitmueller> Ugh SWIG. I just threw up in my mouth a little. :-/ [19:27:40 CET] <JEEB> yes, I tried that in 2014 [19:27:42 CET] <JEEB> it was awful [19:27:52 CET] <JEEB> recently I tried rust and I liked bindgen [19:28:11 CET] <JEEB> too bad I'm not sure of the rust ecosystem just yet [19:28:19 CET] <JEEB> golang is OK until you hit an edge case [19:28:41 CET] <devinheitmueller> Thats the issue. Sure, I could learn rust and write it, but there are so few developers I could hire to maintain the result. [19:29:05 CET] <JEEB> one of my friends has been unlucky enough to be in multiple golang tickets about the C FFI [19:29:30 CET] <JEEB> I think there's some stuff for C# and Java as well to generate the mappings during build time [19:29:58 CET] <JEEB> of course you have to then create your own higher level things but that generally depends so much on what you're trying to do that I'm not sure if it's worth abstracting too much [19:30:35 CET] <devinheitmueller> Would just be nice to be able to assemble pipelines without having to write my own version of ffmpeg.c. [19:31:00 CET] <JEEB> no, you don't want to be nowhere near ffmpeg.c to be honest :D [19:31:10 CET] <JEEB> ffmpeg.c is trying to be too many things and isn't dynamic at all [19:32:02 CET] <devinheitmueller> I argued at the VDD conference that there is way too much being done by ffmpeg.c that should really be part of the framework itself, but I dont think we would ever see any consensus on what parts to abstract or how they should work. [19:32:26 CET] <JEEB> I was around that table as well :) [19:33:04 CET] <JEEB> but yes, I agree there are too many things in ffmpeg.c that fixup some weirdness in how lavf or so work (esp. wrt timestamps) [19:33:59 CET] <devinheitmueller> Yeah, Ive got some pretty nasty patches related to passing along the original timestamps to the output, which I suspect will result in some lively debate. [19:34:58 CET] <JEEB> well, that's how for example the MPEG-TS demuxer is currently (supposed) to work, which from the other side is just pants-on-head stupid for something that most of the framework thinks should be a proper monotonically rising timestamp [19:35:14 CET] <JEEB> which is why upipe has I think three timestamps [19:35:33 CET] <JEEB> coded timestamp, aligned (?) timestamp and receival timestamp [19:35:38 CET] <devinheitmueller> Right. The TS demux passes along the original timestamps, which ffmpeg.c immediately throws away and re-timestamps everything before the frames hit the output. [19:36:16 CET] <JEEB> first being the original, aligned being what a lot of the framework expects and receival being there just for the shits n' giggles (and for some heuristics) [19:36:39 CET] <JEEB> I would say we could use at least two of those [19:37:10 CET] <JEEB> because in some cases I want the original timestamps, but then in other cases I as the API user just want the monotonically rising stuff that is fixed from the original coded stuff [19:37:10 CET] <devinheitmueller> From what I hear, proper timestamps is one of the strengths that upipe claims to have. [19:37:16 CET] <JEEB> yea [19:37:29 CET] <JEEB> I might or might not have noted that at the discussion [19:37:45 CET] <JEEB> because both use cases are 100% valid but having them in the same DTS/PTS field makes IMHO no sense [19:38:03 CET] <JEEB> because then you get disconnects like half of the framework not taking things in [19:38:58 CET] <devinheitmueller> Yup. [19:40:27 CET] <devinheitmueller> Ill be the first to acknowledge that the concept of timestamps in general are hard. At this point Im just trying to find low-impact ways to extend ffmpeg to be able to accomplish the use cases I care about. [19:43:33 CET] <JEEB> for me my initial thought was to move the mpeg-ts specific timestamp fixing into the demuxer, and since some people wanted the original timestamps make it an option to make life simpler for the API (ab)user [19:44:01 CET] <devinheitmueller> JEEB: I started injecting the original timestamp as side data. No idea if that will get accepted upstream though. [19:44:07 CET] <JEEB> :D [19:44:19 CET] <JEEB> that's sad yet I understand why you're doing that [19:44:21 CET] <JEEB> which is also sad [19:44:28 CET] <devinheitmueller> Thats the least invasive approach I could come up with. [19:45:02 CET] <JEEB> yea, because you can ignore all the ffmpeg.c stuff and just check in the muxer [19:45:09 CET] <JEEB> and suddenly you've got original stuff [19:45:13 CET] <devinheitmueller> Yup. [19:45:24 CET] <devinheitmueller> Ive got a bitstream filter which acts on it. [19:47:53 CET] <JEEB> I wonder if -copyts and -vsync passthrough was all that I was using at some point... (for some other reasons). and I bet there was some code in ffmpeg.c to poke even that [19:48:03 CET] <JEEB> I remember at some point looking into the "vsync" code in ffmpeg.c [19:48:13 CET] <JEEB> iä iä cthulhu f'thagn [22:21:47 CET] <TheRock> Is XAudio2 thread friendly? [22:22:22 CET] <TheRock> XAudio2 backend doesn't make any sound [22:22:26 CET] <TheRock> in a thread [22:22:29 CET] <TheRock> any ideas? [22:22:47 CET] <TheRock> When DirectSound backend is activated all works as expected [22:22:54 CET] <durandal_1707> whats XAudio2? [22:23:43 CET] <TheRock> Looks like QtAV (lib for ffmpeg) uses it as backend [22:25:57 CET] <BtbN> You should ask them about it then [22:27:48 CET] <JEEB> TheRock: this is FFmpeg, not <random project utilizing FFmpeg in the background> [22:31:36 CET] <TheRock> nah [22:31:58 CET] <TheRock> if you guys link/recommend the library on the page, there could be at least a chance one of you guy knew something ;) [22:32:43 CET] <JEEB> eh [22:32:50 CET] <JEEB> do we recommend QtAv anywhere? [22:32:56 CET] <JEEB> if we do please note so it can be removed [22:33:35 CET] <durandal_1707> why? [22:34:08 CET] <camjac251> Does anyone have any experience with converting variable framerate to constant framerate videos with ffmpeg? I have this command https://pastebin.com/ZBfAYdgF and was wondering if it is correct for conversion of VFR to CFR (shadowplay NVENC footage to dnxhd) [22:34:25 CET] <TheRock> there is no need to remove it, QtAV took the authr a lot of work. it can be found on your ffmpeg page https://trac.ffmpeg.org/wiki/Projects [22:34:33 CET] <JEEB> that's the wiki [22:34:37 CET] <JEEB> free reign pretty much [22:34:39 CET] <JEEB> :P [22:34:49 CET] <JEEB> you cannot take it as any sort of recommendation [22:34:52 CET] <TheRock> ah, ok [22:41:24 CET] <alexpigment> camjac251: have you tried just putting in -r 60 or something like that? [22:42:06 CET] <alexpigment> i know there's a force-cfr param for x264, but I'm not sure about dnxhd [22:42:19 CET] <alexpigment> either way, specifying the frame rate explicitly *should* convert it to CFR [22:42:59 CET] <camjac251> It's added right after the input [22:45:34 CET] <alexpigment> camjac251: apparently I didn't look at your command close enough ;) [22:45:43 CET] <alexpigment> at any rate, that should work fine [22:47:07 CET] <camjac251> i noticed something weird. in mpc-hc with madvr it looks fine but in After Effects it's different. The start of the ffmpeg converted video and the same source converted with handbrake to constant framerate at 60fps starts on different frames [22:47:19 CET] <camjac251> one of the files is 2 frames behind the other [22:47:36 CET] <gon_> Hello, having some trouble with combining files. I'm trying to combine video clips with pictures using hstack. The clips and pictures are the same height but the image resolution seems off, it's too wide. Any ideas? [22:49:39 CET] <camjac251> could be aspect ratio? [22:50:28 CET] <camjac251> pixel format [22:50:32 CET] <durandal_1707> use setsar, latest master have this limitation removed [22:50:51 CET] <camjac251> thank you alexpigment for your help [22:52:24 CET] <gon_> Yeah I seem to be missing something. The video clip is 720x960 so made sure the image height was also 960 thinking the rest would be taken care of. Using hstack to merge them together [22:53:41 CET] <durandal_1707> gon_: as said use setsar, pastebin full ffmpeg output [23:03:12 CET] <gon_> Sorry still very new to ffmpeg. Just trying this out. How could I use setsar instead of hstack? or along with hstack? Here's where I'm at so far https://pastebin.com/cj8zr4Zp [23:03:22 CET] <bray90820> How would I use ffmpeg with audacity [23:04:07 CET] <durandal_1707> gon_: before each hstack call setsar=1/1 on each input video [23:04:51 CET] <durandal_1707> bray90820: by compiling audacity with ffmpeg support [23:10:28 CET] <durandal_1707> gon_: i see nothing wrong with that pastebin output, perhaps disable shortest of hstack [23:11:58 CET] <gon_> Yeah it's coming out but just having that aspect ratio problem with the image. The video AR seems to be ok but just having trouble keeping the AR on the image. Now trying to figure out the order for the call you mentioned [23:13:01 CET] <alexpigment> camjac251: it's possible there's a cue sheet or something that tells the player to start at a particular time. that's pretty common for quicktime files [23:13:13 CET] <alexpigment> not sure if it's what's going on, but I figured i'd mention it [23:13:36 CET] <durandal_1707> gon_: well if aspect ratios do not match you will need to manually fix that with pad and scale [23:18:31 CET] <gon_> So the same AR even though height is the same for both inputs? [00:00:00 CET] --- Tue Nov 28 2017

1 0

ffmpeg-devel.log.20171126
by burek 27 Nov '17

27 Nov '17

[00:07:11 CET] <jkqxz> BtbN: <http://sprunge.us/dQTH>? [00:07:21 CET] <jkqxz> (Noticed by checkheaders.) [00:07:50 CET] <BtbN> Yeah. I wonder why this didn't break when I did the other patch to make checkheaders work [00:08:45 CET] <jkqxz> I'm not quite sure what the ordering requirements are there. [00:09:16 CET] <BtbN> the d3d/windows headers have to be included before the cuvid header, because they otherwise define GUID [00:09:34 CET] <BtbN> so putting config.h to the top is fine [00:09:38 CET] <BtbN> I hope? [00:10:38 CET] <BtbN> yeah, it doesn't include anything [00:13:12 CET] <jkqxz> Happy with that, then? [00:14:42 CET] <BtbN> sure, feel free to push that. [00:14:54 CET] <jkqxz> Ok, thanks! [00:16:51 CET] <SortaCore> speaking of which, I saw comments that D3D11 is slower than DX9 [00:17:10 CET] <jkqxz> Can anyone here test XvMC or videotoolbox? I'd like to be sure I'm not accidentally breaking them somehow. [00:17:41 CET] <jkqxz> Other than that, I would push 1-12 of the hwaccel configuration set (including VP8 but not MJPEG). [00:19:14 CET] <SortaCore> https://github.com/rigaya/QSVEnc/blob/master/QSVEncC/QSVEncC.cpp#L435 sauce [00:19:21 CET] <jkqxz> SortaCore: They should be identical underneath, but at least the copy-back behaviour has significantly different paths and therefore possibly different performance. [00:19:44 CET] <nevcairiel> dont believe everything you need [00:19:46 CET] <nevcairiel> read* [00:19:53 CET] <SortaCore> should I believe you when you say that [00:20:18 CET] <BtbN> jkqxz, is it already possible for a hwaccel to output a sw format with that? [00:20:41 CET] <nevcairiel> in my tests copy-back d3d11 is actually faster, despite (or maybe because of?) the on-gpu copy to a staging texture, but it does use a tad bit more cpu [00:21:24 CET] <jkqxz> Yes, as long as it is different from associated software formats. If they are the same then we need something other than get_format() to distinguish the choice. [00:21:41 CET] <BtbN> hm. It'd be NV12. [00:21:50 CET] <BtbN> Or P010/P016 [00:22:05 CET] <nevcairiel> doesnt that limit this to one hwaccel doing that? [00:22:09 CET] <nevcairiel> seems kinda annoying [00:22:13 CET] <jkqxz> Yes, it would. [00:22:27 CET] <nevcairiel> i would rather not tie one particular hwaccel to say nv12 [00:22:27 CET] <jkqxz> We could maybe do something like checking the device in hw_device_ctx/hw_frames_ctx to get past that. [00:22:39 CET] <jkqxz> But I haven't written that. [00:22:53 CET] <BtbN> Or intruduce ugly fake-hw-formats that can be no-op downloaded [00:23:06 CET] <nevcairiel> lets not do more fake hwaccel hacks [00:23:21 CET] <BtbN> it would be something like PIX_FMT_CUDA_SW_NV12 [00:23:28 CET] <BtbN> Which is just PIX_FMT_NV12... [00:23:43 CET] <jkqxz> nevcairiel: + [00:24:06 CET] <BtbN> Is there even another true hwaccel that can output software frames right away, other than nvdec? [00:25:12 CET] <jkqxz> You could make some other cases faster by doing it. [00:26:31 CET] <SortaCore> I'm just trying to feed H264 into it [00:26:31 CET] <jkqxz> I think at least VAAPI (and D3D11?) could have an internal copy to CPU-memory-but-GPU-visible frames, avoiding another copy further down the stack. [00:26:43 CET] <SortaCore> but the stream is decoding to YUV420P so NV12 conversion is a bit weird [00:27:01 CET] <BtbN> nvdec outputs nv12 [00:27:02 CET] <jkqxz> But I don't really like that idea, because hwaccel output to software isn't a particularly common case. [00:27:04 CET] <SortaCore> I have to receive it from rtsp, re-encode to NV12, pass to encoder... [00:27:23 CET] <SortaCore> *convert frame to NV12 [00:27:34 CET] <SortaCore> is there a way to RTSP HWA decode? [00:27:41 CET] <BtbN> what? [00:27:53 CET] <jkqxz> (Well, maybe it is a common case, but I don't care about it myself. If you're on the GPU, stay there.) [00:27:55 CET] <BtbN> last time I checked, rtsp was not a video codec [00:28:06 CET] <SortaCore> get from RTSP and pass into HWA for transcoding immediately [00:28:39 CET] <BtbN> jkqxz, the issue for nvdec right now is, if the filter chain and everything expects software frames, the decoder will first copy from the mapped cuvid surface to a on-device CUDA frame. And then ffmpeg.c will download that to software. [00:28:53 CET] <BtbN> But the cuvid surface can also be loaded into system memory immediately, which is substantially faster [00:29:49 CET] <jamrial> jkqxz: poke iive about xvmc [00:30:06 CET] <iive> what are these changes? [00:31:25 CET] <jkqxz> iive: Improving hwaccel setup - <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220733.html>. [00:32:04 CET] <jkqxz> iive: Can you test XvMC? I can give you a set of patches, or a git repo. [00:32:22 CET] <jkqxz> (Some changes since the last email set.) [00:41:38 CET] <iive> jkqxz: repo or a single patch over current git ffmpeg [00:41:40 CET] <SortaCore> whenever I try to switch h264 native decoder to a HWA h264 it doesn't decode [00:42:29 CET] <iive> these patches does look ... messy [00:46:03 CET] <jkqxz> iive: <http://ixia.jkqxz.net/~mrt/ffmpeg/hwaccel/all.patch> [00:46:37 CET] <jkqxz> (Full set of single patches available in the same directory.) [00:52:09 CET] Action: iive compiling [00:53:59 CET] <jkqxz> Thank you! [01:24:15 CET] <iive> jkqxz: gonna take a while, since moving the hwaccel structures breaks the way mplayer configure finds them out. [01:27:01 CET] <jkqxz> Does it look inside the AVHWAccel structures? [01:28:00 CET] <iive> no, but HWACCEL is moved from allcodecs.c to hwaccels.h [01:28:47 CET] <jkqxz> Right, mplayer configure stuff. You should be able to replace it with the same mechanism as bsfs. [01:29:42 CET] <jkqxz> $(list_subparts_extern AVHWAccel hwaccel codec/hwaccels.h) maybe. [01:32:44 CET] <iive> yes already did it :D [01:33:01 CET] <iive> and that's exactly how it looks :D [01:44:21 CET] <iive> jkqxz: it segfaults in libavcodec/decode.c:1251 that is "err = hwaccel->init(avctx);" I suspect that init might be null, but gdb is been mean to me, saying variables are optimized out, even when i set breakpoing. [01:46:54 CET] <jkqxz> Put "if (hwaccel->init) { }" around that and the error check? [01:46:57 CET] <iive> jkqxz: should I make a stub init function and place it in hwaccel struct, or you'll add an if() check before calling init. [01:47:26 CET] <iive> i don't set .init, so it is NULL in the best case :D [01:47:36 CET] <jkqxz> The check used to be there, but I dumped it when eliminating the fake hwaccels. [01:47:47 CET] <jkqxz> Apparently xvmc doesn't have it set either (though it does have the other calls)> [01:47:59 CET] <jkqxz> So the if should stay. [01:50:14 CET] <iive> with that change [01:50:18 CET] <iive> it seems to work. [01:51:39 CET] <jkqxz> Yay! I've changed that here as well. [01:51:42 CET] <jkqxz> Thank you for testing! [01:51:54 CET] <jkqxz> Videotoolbox, anyone? [01:54:36 CET] <jamrial> ubitux or nevcairiel, maybe [01:55:46 CET] <iive> what is videotoolbox, arm/rpi ? [01:55:46 CET] <jamrial> or wm4. i think he wrote some videotoolbox patches before, so he probably has a mac laying around [01:55:52 CET] <jamrial> osx [01:55:57 CET] <iive> oh [01:57:55 CET] <jamrial> mmal seems to be rpi [02:11:20 CET] <Compn> videolan has some vtb people if you ask in their channel to test maybe ? [02:11:22 CET] <Compn> :) [02:11:51 CET] <atomnuker> rcombs did some videotoolbox stuff too I think [02:32:56 CET] <rcombs> yeah I know a thing or two about both [02:33:34 CET] <rcombs> you may notice my name is in the copyright header for mmaldec.c [02:33:55 CET] <rcombs> been a while, though [02:34:13 CET] <tmm1> i can test videotoolbox stuff too, is there a git url/branch? [02:42:28 CET] <jamrial> jkqxz: ^ [02:44:43 CET] <iive> tmm1: same patch should work for you. <jkqxz> iive: <http://ixia.jkqxz.net/~mrt/ffmpeg/hwaccel/all.patch> [02:50:24 CET] <tmm1> ok, am i just checking to see if vt hwaccel decoding still works? [02:52:12 CET] <iive> i guess, compilation and working :D [02:56:59 CET] <tmm1> its segfaulting [02:57:24 CET] <tmm1> https://gist.github.com/tmm1/990cb460f0cfe8a6880728d0a9141649 [03:09:11 CET] <rcombs> tmm1: happen to know much about OpenAL? [03:12:45 CET] <tmm1> not really [03:14:14 CET] <atomnuker> why would anyone use openal? [03:14:29 CET] <atomnuker> (besides to get eax working) [03:14:58 CET] <iive> is there anything better? [03:15:58 CET] <atomnuker> ...not really, its the most decent library out there for platform-independent audio [03:16:25 CET] <cone-321> ffmpeg 03James Almer 07master:08b294bf5f4e: avformat/isom: return proper error values in ff_mp4_read_dec_config_descr [03:16:25 CET] <cone-321> ffmpeg 03James Almer 07master:abf669479c00: avformat/mov_esds: check return value of ff_mp4_read_dec_config_descr [03:16:27 CET] <iive> how about sound 3d positioning ? [03:17:39 CET] <cone-321> ffmpeg 03Rostislav Pehlivanov 07master:3154f4417ab5: lavc/utils.c: use C11 atomics for entangled thread handling [03:17:40 CET] <cone-321> ffmpeg 03Rostislav Pehlivanov 07master:590136e78da3: libavcodec/utils.c: simplify avcodec locking with atomics [03:17:41 CET] <cone-321> ffmpeg 03Rostislav Pehlivanov 07master:3701d499f873: error_resilience: remove avpriv_atomic usage [03:18:01 CET] <atomnuker> now only that annoying cas function remains [03:18:37 CET] <atomnuker> iive: it does 3d positioning I think, it has to in order to provide software eax emulation [03:19:13 CET] <iive> atomnuker: i know it does. i ask if there is a library that does it better. [03:22:06 CET] <atomnuker> not sure any other library does 3d positioning apart from fmod which sucks and is closed source [03:24:12 CET] <iive> :) [03:24:17 CET] <iive> n8 ppl [04:25:04 CET] <atomnuker> michaelni: afaik the api for c11 threads was more limited than pthreads [04:26:06 CET] <atomnuker> they should have just made pthreads part of the standard somehow [04:26:30 CET] <atomnuker> and should have just standardized all the non portable functions like namesetting [04:26:37 CET] <atomnuker> (no ubitux, I haven't forgotten yet) [04:51:34 CET] <michaelni> atomnuker, it seems many of the additions in the recent years arent at the quality level the original K&R C was. But pthreads itself is also not all that great [09:03:28 CET] <kurosu> what's with all the avx2 for lossless decoders? [09:03:38 CET] <kurosu> has the overall speed been benchmarked? [09:04:01 CET] <kurosu> I suspect that's actually a slowdown because the CPU is forced to downclock [09:04:33 CET] <kurosu> in those, bitstream reading should be like 80-90% of the decoding time [09:30:46 CET] <c3r1c3-Win> the only thing I can think of as to using AVX2 is double width registers, so in theory if your clock speed drops 30% it's still a win...but I'm not the expert on such. [10:17:50 CET] <kurosu> If you halve 10%, you get 5% speedup, but if you loose even 10% on 80% it's 8%: net loss [10:18:25 CET] <kurosu> (well, halve 20%, but 10% loss was conservative) [11:37:08 CET] <jkqxz> tmm1: Er, does that work before the change? The hwaccel initialisation hasn't run when get_format() is called, so hwaccel_priv_data can't be filled (nothing has been chosen yet). [11:39:25 CET] <jkqxz> It will only be set after get_format() returns, because it's created just before AVHWAccel.init is called. [13:36:53 CET] <omerjerk> Hi, how do I mark the encoder as experimental? I know I asked this question before but I seem to have lost the message. [13:37:15 CET] <omerjerk> There's some flag need to be set in codec capabilities. [13:37:19 CET] <omerjerk> What's it exactly? [13:43:13 CET] <jdarnley> omerjerk: There is a struct for every codec usually at the bottom of their file. [13:43:36 CET] <jdarnley> In the strcut there is a capabilities field [13:43:58 CET] <jdarnley> That is where you need to addthe experimental flag. [13:43:59 CET] <omerjerk> yeah I know. I need to know the exact flag which needs to be set to mark the encoder as experimental. [13:44:12 CET] <omerjerk> what's the flag exactly? [13:44:25 CET] <jdarnley> AV_CODEC_CAP_EXPERIMENTAL [13:51:59 CET] <omerjerk> thanks. :) [14:05:51 CET] <cone-523> ffmpeg 03Paul B Mahol 07master:ffc01280be63: avfilter: add lv2 wrapper filter [14:38:38 CET] <durandal_1707> YEAH! [14:56:38 CET] <cone-523> ffmpeg 03Derek Buitenhuis 07master:52a44d50beb2: h264_picture: Actually return error during alloc failure [16:07:37 CET] <jdarnley> You know how I was wondering whether my flac assembly was correct? [16:07:49 CET] <jdarnley> My test for checkasm doesn't work. [16:08:06 CET] <jdarnley> I'm not sure the asm works with order=0 but then I'm not sure whether that is possbile in the real code. [16:31:04 CET] <jdarnley> Gah! [16:31:09 CET] <jdarnley> I'm just too incompetent. [16:31:18 CET] <jdarnley> I want to pass the same value into the function [16:31:24 CET] <jdarnley> not call rnd() twice [16:33:51 CET] <jdarnley> oh but that was a separate issue to the 0 order problem [16:40:39 CET] <cone-523> ffmpeg 03Mark Thompson 07master:6e0e3e1d8ddc: hwcontext_vaapi: Do not assume that sw_format is transferable [16:40:40 CET] <cone-523> ffmpeg 03Mark Thompson 07master:3fbd4fc47621: nvenc: Include config.h before checking for D3D11 support [16:40:41 CET] <cone-523> ffmpeg 03Mark Thompson 07master:022ddff0b2c2: doc/fftools: Remove documentation for old -opencl_bench option [16:40:42 CET] <cone-523> ffmpeg 03Mark Thompson 07master:37c57df18e7c: doc/ffmpeg: Document opencl for -init_hw_device [18:27:33 CET] <cone-523> ffmpeg 03Derek Buitenhuis 07master:e7af1394ecd0: vorbisenc: Check the return value of av_frame_clone [18:36:43 CET] <cone-523> ffmpeg 03Michael Niedermayer 07master:2b6964f76438: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi* [18:36:44 CET] <cone-523> ffmpeg 03Michael Niedermayer 07master:2779d33ed998: avformat/aacdec: Fix leak in adts_aac_read_packet() [19:06:05 CET] <philipl> jkqxz: back to mjpeg. What's the pix_fmt remapping meant to avoid? I commented it out and it didn't stop the hwaccel from working. I tried with 420, 422 and 444 samples. [19:27:17 CET] <philipl> jkqxz: I guess it's because there's a code path where get_format is bypassed and you want the pix_fmt to match the pre-set sw_pix_fmt, but what usage follows this path? I didn't hit it using 'ffmpeg' or mpv [19:45:53 CET] <tmm1> jkqxz: you're right it crashes on master too [20:15:38 CET] <jkqxz> tmm1: Presumably it is caused by 259dc4e01381c0d01fb1dbb8509c5087d621a0d7, which adds the reference to the VTContext which doesn't necessarily exist when videotoolbox_start is called externally? [20:16:56 CET] <jkqxz> (It would work in a hw_device_ctx-only case, because start is called internally by AVHWAccel.init (after get_format) there.) [20:22:36 CET] <jkqxz> I think you want to move that saving of the SPS profile/constraint/level bits somewhere later. [20:22:59 CET] <tmm1> yea its my bug, will fix [20:23:16 CET] <tmm1> need to figure out where best to move it [20:23:24 CET] <jkqxz> To make it work in ffmpeg for testing, you can probably just delete the hwaccel definition in fftools/ffmpeg_opt.c - it will then use the generic setup only. [20:24:42 CET] <jkqxz> (Which would be nice, though it kills the videotoolbox_pixfmt option. That's why I didn't do it already, along with inability to test anything.) [20:26:05 CET] <jcdutton> I am trying to use the segment muxer, so I have capture from a web cam, and store the files in 10 minute chunks. The HLS muxer lets you create date directories, but the segment one appears not to [20:26:17 CET] <jcdutton> Is there a patch for it somewhere? Or shall I write one? [20:29:28 CET] <tmm1> there is no patch, you would need to write it [20:41:59 CET] <jkqxz> tmm1: Mind trying <http://ixia.jkqxz.net/~mrt/ffmpeg/hwaccel/all_vt-hdc.patch>? That's as before, but without the non-hw_device_ctx path for videotoolbox. [20:46:10 CET] <tmm1> sure [20:52:03 CET] <tmm1> jkqxz: works as expected [20:57:49 CET] <jkqxz> tmm1: Great, thank you. I think that means I can push the set, then. [20:59:26 CET] <tmm1> awesome [21:00:31 CET] <jkqxz> Whether to get rid of ffmpeg_videotoolbox.c can be decided separately. [21:10:01 CET] <jcdutton> tmml, thank you. Just checking. Not wanting to duplicate effort [21:34:42 CET] <jamrial> carl literally behaves like a bot in the above ticket, wtf [21:36:25 CET] <BtbN> well, that guy is very good at ignoring what he says though [21:37:10 CET] <jamrial> repeating himself will not get him make the user understand [22:36:50 CET] <atomnuker> jamrial: https://www.phoronix.com/scan.php?page=news_item&px=LLVM-6.0-3DNow-Improvem… [22:40:42 CET] <atomnuker> wouldn't it be a twist if some big corporate intel user requested 3dnow support to migrate their handwritten simd to new cpus [22:41:20 CET] <jamrial> "So if you're running an AMD K6 up to Bulldozer CPU still, with the upcoming LLVM 6.0 release you may find better performance" [22:41:37 CET] <jamrial> what a load of bullshit [22:41:55 CET] <atomnuker> or maybe arm throws some cents at amd and buys a 3dnow license and adds support for it in armv9 or whatever's next [22:41:56 CET] <jamrial> anything from athlon xp and newer has sse [22:42:05 CET] <jamrial> there's zero gain in using 3dnow if you have sse [22:42:26 CET] <jamrial> it's not like mmx where you can still see some advantage in using the smaller regs compared to sse2 [22:42:48 CET] <atomnuker> well intel still owns the sse license and won't give it to anyone else unless forced [22:42:58 CET] <atomnuker> anyone else like people who want to emulate them [22:43:35 CET] <atomnuker> (actually they have a patent, not a license) [22:43:44 CET] <jamrial> i'm talking about that closing line. it's not only factually wrong (bulldozer doesn't have 3dnow), it's also absurd [22:44:27 CET] <BtbN> He also made news about every little change we pushed for nvdec, even though the same feature was available forever, just called cuvid. [22:44:42 CET] <atomnuker> yeah, it is, its phoronix after all [22:47:57 CET] <cone-822> ffmpeg 03Mark Thompson 07master:24cc0a53e99e: lavc: Add codec metadata to indicate hardware support [22:47:57 CET] <cone-822> ffmpeg 03Mark Thompson 07master:758fbc54fef2: lavc: Add hardware config metadata for decoders supporting hardware output [22:47:57 CET] <cone-822> ffmpeg 03Mark Thompson 07master:67e81d79ccfc: lavc: Use hardware config information in ff_get_format() [22:47:57 CET] <cone-822> ffmpeg 03Mark Thompson 07master:3536a3efb9fd: lavc: Deprecate av_hwaccel_next() and av_register_hwaccel() [22:47:57 CET] <cone-822> ffmpeg 03Mark Thompson 07master:9bd326ac465d: lavc: Remove register mechanism for hwaccels [22:47:58 CET] <cone-822> ffmpeg 03Mark Thompson 07master:da4e02b19615: lavc: Delete all fake hwaccels [22:47:58 CET] <cone-822> ffmpeg 03Mark Thompson 07master:3a71bcc213f2: lavc: Mark all AVHWAccel structures as const [22:47:59 CET] <cone-822> ffmpeg 03Mark Thompson 07master:b0cd14fb1dab: ffmpeg: Use codec hardware config to configure hwaccels [22:47:59 CET] <cone-822> ffmpeg 03Mark Thompson 07master:efd0612fdcb7: vaapi: Make the decode profile matching more explicit [22:48:00 CET] <cone-822> ffmpeg 03Mark Thompson 07master:9f00fa536938: vp8: Add hwaccel hooks [22:48:01 CET] <cone-822> ffmpeg 03Mark Thompson 07master:40b75a943bcb: vaapi: Add VP8 decode hwaccel [22:48:02 CET] <cone-822> ffmpeg 03Mark Thompson 07master:f69e9365f6e0: vaapi_decode: Ignore the profile when not useful [22:50:05 CET] <atomnuker> jkqxz: is there still something to do to the mjpeg hooks? [22:50:39 CET] <jkqxz> Yes, make them work properly. [22:52:27 CET] <jkqxz> 4:2:0 still doesn't work in VAAPI without external allocation hackery. [22:53:08 CET] <jkqxz> There is more to do around getting the right huffman/quant tables (it only works with JPEGs containing everything inline at the moment, ones with implicit tables don't). [22:54:26 CET] <BtbN> Is this compatible with the way nvdec wants its jpeg stuff? [22:55:19 CET] <jkqxz> And I don't much like how pulling the bitstream out for the hardware works at the moment. [22:55:33 CET] <philipl> jkqxz: yay! [22:57:33 CET] <jkqxz> BtbN: Still unclear on that. It's good using the whole packet for whatever cases philipl tried, but I'd still like to know how nvdec deals with implicit tables. [22:57:57 CET] <BtbN> I'd guess it doesn't [22:58:27 CET] <jkqxz> philipl: nvdec VP8 -> ML, then? [22:58:58 CET] <jkqxz> BtbN: If it doesn't then some splicing of reconstructed tables into the bitstream may be desirable. [22:59:10 CET] <philipl> jkqxz: I'll send it shortly [23:04:35 CET] <philipl> sent [23:13:10 CET] <philipl> jkqxz: the lazy option is to say it's extremely unlikely that any new mjpeg hw will show up so pass what nvdec wants to start_frame and what vaapi wants to decode_slice. :-) [23:13:43 CET] <jkqxz> I don't think that's true, webcams are still all MJPEG. [23:14:36 CET] <atomnuker> well some have uncompressed modes at least [23:14:37 CET] <jkqxz> In fact, they seem to be going away from H.264 now that every machine has a better H.264 encoder than the webcam could possibly implement. [23:16:50 CET] <jkqxz> Logitech's 4K webcam gives you MJPEG at 0.5Gbps or so, and doesn't have any other compressed mode at all. (4K isn't really doable uncompressed over USB 3.) [23:18:48 CET] <nevcairiel> high bitrate jpeg isnt that terrible, if they assume you're going to re-compress it anyway [23:19:30 CET] <jkqxz> Yeah, which means everyone needs a fast MJPEG decoder. [23:19:48 CET] <nevcairiel> not that this hardware is really faster on most pcs [23:20:49 CET] <nevcairiel> didnt you test that our single-threaded software decoder almost beats vaapi [23:20:53 CET] <jkqxz> It uses a lot less power. [23:21:29 CET] <philipl> no one has benchmarked nvidia yet [23:21:49 CET] <nevcairiel> running a dGPU might throw out the power rating tho =p [23:21:55 CET] <philipl> heh [23:22:41 CET] <jkqxz> It was pretty much best-case single-threaded, and the stuff after the decode is going to be nontrivial too. [23:23:10 CET] <nevcairiel> i also dont think anyone took a real good look at making mjpegdec really efficient on modern hardware, because its just fast enough as it is [23:24:16 CET] <philipl> jkqxz: do you have a source for samples of implicit tables and the different dcts? i haven't tested all the cases. [23:26:03 CET] <jkqxz> The 4K from that webcam barely works on an Intel desktop if you want to do anything with the result. [23:26:41 CET] <jkqxz> philipl: Not really, I have some random webcams to test because that's the interesting case. [23:26:52 CET] <jkqxz> I can make some streams. [23:29:12 CET] <philipl> Hard to distribute due to size :-) [23:42:51 CET] <philipl> jkqxz: regarding the conflict marker - it seems I fixed that when resolving a subsequent change in my stack. Now have to fiddle that around. good times. [23:43:42 CET] <philipl> BtbN: should ff_nvdec_frame_params be called with the total number of frames (current + references) or just references? [23:44:15 CET] <philipl> I did just references for vc1 and mpeg but current + references for vp8 and now I'm not sure which one is preferred. [23:44:24 CET] <BtbN> not sure either [23:44:41 CET] <BtbN> For VP9 it's just the 8 reference frames [23:44:59 CET] <philipl> it grows the pool when needed so having it one short doesn't break anything but if the goal is to set it to the maximum, then it should be current + references [23:45:31 CET] <philipl> I guess I'll stick to just references as that's what all the pushed ones have [23:45:46 CET] <BtbN> the buffer is slightly too big all the time anyway [23:52:37 CET] <jdarnley> atomnuker: I've just sent a patch set almost dedicated to you :) [23:54:11 CET] <jcdutton> jkqxz, have you tried nvdec instead of vaapi? [23:56:01 CET] <cone-822> ffmpeg 03Philip Langdale 07master:1da9851e3470: avcodec/nvdec: Implement vp8 hwaccel [23:56:04 CET] <jcdutton> my nvidia card does nvdec at 200 fps for 1920x1080 frames. [00:00:00 CET] --- Mon Nov 27 2017

1 0

ffmpeg.log.20171126
by burek 27 Nov '17

27 Nov '17

[00:03:25 CET] <SortaCore> why does VLC so easily vomit when it gets webm [00:10:33 CET] <sfan5> it's VLC what did you expect [00:11:24 CET] <iranen> VLC is often the best you can have [00:12:07 CET] <JEEB> the thing with VLC is that releases happen so slowly that you have a long time until a lot of good stuff hits a release [00:13:11 CET] <BtbN> a long time is an understatement by now [00:14:23 CET] <c3r1c3-Win> LOL, that's true. [00:14:50 CET] <SortaCore> dunno why but whole app freezes [00:14:58 CET] <SortaCore> audio starts to loop, video stuck, UI unresponsive [00:15:40 CET] <TheRock> guys vlc is not bad [00:15:55 CET] <TheRock> you can play movies [00:16:17 CET] <SortaCore> you guys know nothing about video [01:39:25 CET] <TheRock> wow [01:39:36 CET] <TheRock> added ffmpeg static to QT project [01:39:40 CET] <TheRock> 16 mb size increase :s [01:40:50 CET] <DHE> it can be shrunk by omitting things like codecs, formats, protocols and filters. I have a ~12 megabyte static link I use [01:42:21 CET] <TheRock> yeah i will recompile and skip some not required stuff [01:42:26 CET] <TheRock> and use upx [01:58:23 CET] <TheRock> other than that [01:58:29 CET] <TheRock> i have to say my ffmpeg build with qt works well [01:58:36 CET] <TheRock> :P [01:58:37 CET] <TheRock> even on xp [02:02:44 CET] <TheRock> so what do i need for normal mp4,wav,avi decoding (for playing a video). can i disable dexmuxers and muxers? [02:04:44 CET] <sfan5> for just playing you should be able to disable muxers,encoders,indevs,filters [02:05:29 CET] <TheRock> i also disabled bsfs and protocols [02:05:41 CET] <TheRock> is that required? [02:05:51 CET] <sfan5> should be fine unless you need e.g. playing from http [02:07:15 CET] <TheRock> $ configure --extra-version=QtAV --disable-doc --disable-debug --enable-static --disable-shared --enable-runtime-cpudetect --disable-postproc --toolchain=msvc --extra-ldexeflags='-SUBSYSTEM:CONSOLE,5.01' --disable-programs --disable-network --disable-nvdec --disable-indevs --disable-protocols --disable-filters --disable-bsfs --disable-muxers --disable-demuxers [02:07:17 CET] <TheRock> i ran this [02:07:25 CET] <TheRock> it seems to do some checks now [02:07:37 CET] <TheRock> anything else i could disable? [02:08:04 CET] <sfan5> disabling demuxers won't work [02:08:15 CET] <sfan5> ffmpeg needs to know how to deconstruct e.g. avi [02:08:24 CET] <TheRock> ok, so just --disable-muxers [02:08:28 CET] <sfan5> yes [02:19:41 CET] <zyme> anyone around for a possibly technical question, compilation related? [02:20:58 CET] <sfan5> tip: just ask your question, someone will answer if they can [02:25:29 CET] <TheRock> Enabled hwaccels: [02:25:35 CET] <TheRock> should i let this enabled? [02:27:08 CET] <zyme> I'm wondering if there's any special editions, mitm executable programs, or something similar to have certain options always enabled even when not cli command specified for ffmpeg, specifically I figure it would be easier to modify the command line arguments code to act the way I want regardless of what's actually typed (for certain options) so as to utilize hardware like cuda decoding and intel's accelerated hardware [02:27:08 CET] <zyme> accelerated x264 encoding when they're not specified to be used in programs like VS or Plex -- my thought is that would be easier than trying to modify the programs themselves if I just replaced the ffmpeg.exe with a customized one. [02:28:11 CET] <zyme> if there isn't then whats the easiest dev env to download the source, make a couple tweaks and compile it myself in windows for that purpose? [02:30:38 CET] <TheRock> when i disable hw accelerators in ffmpeg build, it will use always software? [02:32:07 CET] <sfan5> ffmpeg likely won't be using any hw accels by default anyway [02:32:52 CET] <TheRock> ah, ok so then i'm going to disable them [02:33:21 CET] <sfan5> zyme: you can problably just have a wrapper script that carefull modifies the ffmpeg args to enabled the options you want [02:34:04 CET] <zyme> thats what I meant when I said mitm exe programs [02:34:47 CET] <sfan5> yeah, i'm suggesting it's easiest to write one from scratch [02:35:59 CET] <TheRock> External libraries providing hardware acceleration: [02:35:59 CET] <TheRock> cuda cuvid dxva2 [02:36:14 CET] <TheRock> should i do something like --disable-dxva2? [02:36:24 CET] <TheRock> as i don't need hw accel. anyway [02:37:28 CET] <zyme> here is an example of one attempt to use it with defaults (showing the current VSv2 command arguments) https://usercontent.irccloud-cdn.com/file/cHa35flb/VS%20v2%20ffmpeg%20synta… [02:40:59 CET] <zyme> from what I gather it saves .ts files slowlly/laggily in my %temp% folder, and at some point converts them to x264 before streaming them out, v1 didn't follow the gpl guidelines and kept everything closed source in a single program and whatever it did was mysterious, because I don't think it used x264 I think it streamed the .ts files. which were probably buffered in ram, based off the lower cpu usage and ultra-high [02:40:59 CET] <zyme> bandwidth-use [02:44:25 CET] <zyme> VS-v2 ffmpeg video decoded .ts file medainfo .txt file; 8 or so of these are kept in %temp% while its running https://www.irccloud.com/pastebin/tJKIWEVb/c0000000249.ts.txt [04:22:30 CET] <TheRock> holy cow [04:45:32 CET] <TheRock> https://stackoverflow.com/questions/27832052/how-do-i-modify-this-ffmpeg-bu… [04:45:43 CET] <TheRock> this seems like a small build that supports mp3 and video only [04:46:49 CET] <SortaCore> ./configure--disable-programs --disable-doc --disable-encoders --disable-decoders --disable-filters --disable-demuxers --disable-muxers --disable-protocols --disable-parsers --disable-hwaccels --disable-bsfs --disable-indevs --disable-outdevs --disable-swscale-alpha [04:47:19 CET] <SortaCore> then you explicitly add --enable-thing=item1,item2 [04:47:51 CET] <SortaCore> for example, --enable-muxer=mp4,h264 [04:47:56 CET] <TheRock> Ah, ok. So --disable-everything is not good? [04:48:07 CET] <SortaCore> that probably works too [04:48:27 CET] <TheRock> i will give it a try [04:48:28 CET] <SortaCore> I have this from my configure that also needs the programs, and it doesn't have --enable-program [04:48:33 CET] <TheRock> the binary is way too big [04:48:54 CET] <SortaCore> if it is MSVC don't forget the --toolchain=msvc [04:49:49 CET] <TheRock> yeah thx [04:49:55 CET] <TheRock> how much is your binary on windows? [04:50:15 CET] <TheRock> if you disable anything except a few things needed to play videos [04:50:57 CET] <SortaCore> atm I have that [04:51:05 CET] <SortaCore> if you are generating ffmpeg.exe it'll probably be small [04:51:33 CET] <SortaCore> for me, I support mp4, h264, mjpeg, and ffmpeg.exe is 5mb [04:51:41 CET] <SortaCore> 5.5mb* [04:51:48 CET] <TheRock> way better [04:52:13 CET] <TheRock> right now it takes 15mb [04:52:25 CET] <TheRock> and i just need basic stuff to decode popular media files [04:52:31 CET] <TheRock> that my player can play it [05:24:54 CET] <TheRock> ./configure --disable-everything --extra-version=QtAV --disable-debug --enable-static --disable-shared --enable-runtime-cpudetect --toolchain=msvc --extra-ldexeflags='-SUBSYSTEM:CONSOLE,5.01' --enable-avresample --enable-decoder=aac,h264,mjpeg,mpeg2video,mpeg4 -enable-demuxer=aac,avi,h264,image2,matroska,pcm_s16le,mov,m4v,rawvideo,wav --enable-parser=aac,h264,mjpeg,mpeg4video,mpegaudio,mpegvideo,png [05:25:00 CET] <TheRock> did i miss anything? [05:25:03 CET] <TheRock> it doesn't play mp4 [05:25:10 CET] <TheRock> nor wmv, etc [05:25:26 CET] <TheRock> Decoder, parser, demuxer [06:26:04 CET] <TheRock> protocol file was missing [09:12:33 CET] <Aprel> Hi I'm encoding videos that have static overlays. For some videos, as much as 50% of the screen is identical from frame to frame throughout the duration of the video. Are there any settings in ffmpeg to leverage this known aspect of the video to reduce bitrate? [09:13:40 CET] <Aprel> I'm encoding into either h.264 or h.265 [10:11:28 CET] <tyng> how do i cut audio frequencies above a certain treshold? [10:13:53 CET] <tyng> the treble filter just do equalization [11:08:47 CET] <durandal_1707> tyng: lowpass or highpass [12:14:24 CET] <jinzo78> Hi! I have a question, maybe a newbie question, but I don't know where else I could post it [12:16:03 CET] <jinzo78> I need to play a video that has one video track and multiple audio tracks. For the video track, I need to output it to a NDI "fake device", so my idea (I'm under Windows and recompiling ffmpeg is a trouble for me) is to pipe the output to VLC [12:17:15 CET] <jinzo78> For the audio tracks, I need to output them to one output device each (I mean: Audio Track #1 to Audio Device #1, Audio Track #2 to Audio Device #2 and so on). [12:18:13 CET] <jinzo78> This system HAS TO BE all synchronized. [12:19:25 CET] <jinzo78> I reached a point in which I can pipe the output of one video and one audio track to VLC but I don't know how to play the other audio tracks. Maybe because I'm under Windows and the shell instruments are garbage... [12:20:01 CET] <jinzo78> How could I do? Any advice is welcome! [12:20:08 CET] <jinzo78> Thank you in advance :) [18:19:33 CET] <kerio> apparently avahi pulls in CUPS [18:19:47 CET] <kerio> and xproto [18:19:49 CET] <kerio> and mesa-libs [18:20:10 CET] <kerio> oh ok apparently avahi-app is what i was looking for [18:22:03 CET] <bencoh> :D [18:22:17 CET] <bencoh> (a bit offtopic though) [18:22:52 CET] <kerio> hold on [18:22:57 CET] <kerio> this isn't #freebsd [18:23:07 CET] <kerio> how dare you have the same initial [18:35:26 CET] <benwilber> Hello is it possible to script -filter_complex in realtime via a socket or something? I want to ingest two rtmp streams, overlay one on top of the other, and output a new rtmp stream, but I would like to be able to control the positioning of the PIP overlay in realtime without having to restart the stream to make filter changes [18:51:36 CET] <furq> benwilber: sendcmd or zmq [18:57:39 CET] <TheRock> ./configure --disable-everything --extra-version=QtAV --disable-debug --enable-static --disable-shared --enable-runtime-cpudetect --toolchain=msvc --extra-ldexeflags='-SUBSYSTEM:CONSOLE,5.01' --enable-avresample --enable-decoder=aac,h264,mjpeg,mpeg2video,mpeg4 --enable-demuxer=aac,avi,h264,image2,matroska,pcm_s16le,mov,m4v,rawvideo,wav --enable-parser=aac,h264,mjpeg,mpeg4video,mpegaudio,mpegvideo,png [18:57:40 CET] <TheRock> --disable-programs --enable-protocol=file [18:57:54 CET] <TheRock> did i miss something? Videos are played well, but mp3 do not work [18:58:07 CET] <JEEB> you don't have the decoder enabled :P [18:58:18 CET] <TheRock> aac isn't mp3? [18:58:20 CET] <JEEB> no? [18:58:25 CET] <TheRock> oh [18:58:26 CET] <JEEB> AAC is MPEG-4 Part... something [18:58:38 CET] <JEEB> MP3 is MPEG-1 Layer 3 [18:58:55 CET] <TheRock> what would i need to add in demuxer, parser and decoder? [18:59:07 CET] <JEEB> mp3 most likely :P [18:59:55 CET] <TheRock> :) ok [19:00:19 CET] <JEEB> I would recommend taking the output of a configure line without all your random options and taking a note of that [19:00:26 CET] <JEEB> since it will output everything it enables by default [19:01:09 CET] <TheRock> yeah, I have that log somewhere [19:01:41 CET] <TheRock> if you look at my config regarding the video files [19:01:57 CET] <TheRock> mp4, .wmv, .avi, .webm, .flv, can be played? [19:02:03 CET] <TheRock> or did i miss anything? [19:02:19 CET] <TheRock> i'd like to support all most used video extensions [19:02:39 CET] <TheRock> right now i just tested mp4, it worked good [19:03:41 CET] <JEEB> well there's no flv demuxxer enabled, and the webm one is part of matroska but might be a separate thing, maybe. also ASF (wmv) is missing [19:03:59 CET] <sfan5> wmv will also need the wmv* and wma* codecs [19:04:22 CET] <JEEB> also for video you're missing vp8, vp9 which are used for webm and wmv* and vc1, yes [19:04:49 CET] <JEEB> for audio vorbis, opus and wma* for webm and ASF [19:06:26 CET] <TheRock> ok [19:06:35 CET] <TheRock> flv is just "flv" in demuxer? [19:06:41 CET] <TheRock> that webm, wmv thing is clear [19:06:49 CET] <JEEB> yes [19:08:02 CET] <TheRock> the lib i'm using recommends --enable-runtime-cpudetect [19:08:18 CET] <TheRock> would you recommend this too? what is the benefit? [19:08:55 CET] <sfan5> that's enabled by default, you don't need that flag [19:09:52 CET] <JEEB> yes, it makes sense to have around and you shouldn't have to enable it since it's enabled by default [19:10:13 CET] <TheRock> ok, even if --disable-everything is specified? [19:10:16 CET] <JEEB> yes [19:10:31 CET] <JEEB> disable-everything disables all features but not how the framework is built [19:10:41 CET] <JEEB> meh, I put it in a bad way [19:11:02 CET] <JEEB> in any case, it just means that the internal configuration of that framework (even if it doesn't contain anything) isn't changed :P [19:11:17 CET] <JEEB> in other words, it just disables things in the framework, not the framework itself [19:11:54 CET] <TheRock> yeah understood [19:15:00 CET] <debianuser> Hello. Trying to debug pl0t's issue. Summary: `ffmpeg -f lavfi -i "aevalsrc='mod(t,.01)*20*mod(t,-.5)+mod(t,.5)*mod(t,2)/2'" -f alsa default` works and produces sound, but `ffplay -nodisp -f lavfi "aevalsrc='mod(t,.01)*20*mod(t,-.5)+mod(t,.5)*mod(t,2)/2'"` freezes: https://pastebin.com/EL1MyjSQ What's the difference between ffplay and ffmpeg playing to alsa? Any ideas welcome! [19:15:05 CET] <debianuser> (you can ignore the aevalsrc=... part, it's just a way to produce some test sound out of ffmpeg/ffplay) [20:15:26 CET] <jcdutton> I am trying to use the segment muxer, so I have capture from a web cam, and store the files in 10 minute chunks. The HLS muxer lets you create date directories, but the segment one appears not to [20:15:39 CET] <jcdutton> Is there a patch for it somewhere? Or shall I write one? [22:27:44 CET] <SortaCore> hmm I need someone to explain the libx264 license to me [22:27:57 CET] <SortaCore> I'm using it to create a DLL, which other people will use to create EXEs [22:28:15 CET] <SortaCore> does that mean both my DLL and their EXEs are then required to be open-source? [22:28:48 CET] <SortaCore> does making libx264 a separate DLL remove that restriction and I only need provide the libx264 source? [22:29:12 CET] <BtbN> iirc x264 is GPL [22:29:14 CET] <BtbN> and not LGPL [22:29:40 CET] <BtbN> So there is no exception, even if it's a shared library. [22:31:12 CET] <JEEB> x264 is either GPL or you get a license from x264 LLC [22:31:30 CET] <JEEB> so if you don't want to share your source code and use x264, then the latter is the only alternative [22:32:06 CET] <SortaCore> well, my source code I don't particularly mind about [22:32:19 CET] <SortaCore> it's just the guys who are using it for EXEs might want closed-source EXEs [22:32:35 CET] <SortaCore> so best way forward is to have two versions of my DLL? [22:32:45 CET] <SortaCore> (or contact x264 LLC?) [22:32:58 CET] <JEEB> well yes, if you pick the GPL route then your thing is as well under GPL, which makes the things using your library also GPL [22:33:28 CET] <TheRock> i heard the h264 company provides up to a certain amount of users/subscribers no fees [22:33:39 CET] <JEEB> TheRock: that's separate from SOFTWARE licensing [22:33:47 CET] <JEEB> you have the patent/licensing mess separate [22:33:54 CET] <JEEB> let's keep this to software licensing, OK? [22:34:19 CET] <TheRock> i see, ok [22:34:27 CET] <JEEB> TheRock: also it's not a "H.264 company" but MPEG-LA, which is the completely-separate-from MPEG licensing pool thing [22:34:48 CET] <JEEB> H.264 is under MPEG-LA for licensing, and yes you can read their PDFs about it [22:35:04 CET] <TheRock> i see [22:35:24 CET] <JEEB> their licensing stuff is relatively sane, which is why with HEVC some companies decided they weren't getting enough cash and now we have like three or four patent licensing pools :P [22:35:35 CET] <JEEB> (for HEVC) [22:35:50 CET] <JEEB> SortaCore: but yes, licensing x264 commercially is another alternative [22:36:01 CET] <TheRock> JEEB: for playing videos (only decoding) to which companies do i have to contact [22:36:16 CET] <TheRock> when it's closed source/commerical [22:37:03 CET] <JEEB> IANAL (I Am Not A Lawyer), but it basically depends :P generally for H.264 it's MPEG-LA and for AAC it's some other place (fraunhofer or technicolor?) for example [22:37:14 CET] <JEEB> whether you're required or not depends on your juristiction and other things [22:37:52 CET] <TheRock> yeah i will look into it [22:37:59 CET] <TheRock> but i could also provide *.obj, i guess [22:38:32 CET] <JEEB> well, I'm not sure that always decides anything [22:38:43 CET] <JEEB> for you to understand it you will have to read through MPEG-LA's licensing terms [22:38:48 CET] <JEEB> what you have to license and for what [22:39:15 CET] <TheRock> yeah, i see. but afaik decoding is lpgl and encoding gpl, right? [22:39:27 CET] <TheRock> because i don't need to --enable-gpl and it works [22:39:34 CET] <JEEB> that's not format licensing [22:39:44 CET] <JEEB> that's software licensing, in which case yes - the FFmpeg AVC decoder is LGPL [22:40:02 CET] <JEEB> x264 can be utilized for encoding, which is a GPL project [22:40:20 CET] <TheRock> so i guess i'd need to license the software at MPEG LA/AAC [22:40:22 CET] <SortaCore> well, my EXE buyers are on the poor side of things, so I'm not sure x264 LLC will be that interested [22:40:45 CET] <JEEB> SortaCore: they usually cater the licensing per client [22:41:05 CET] <SortaCore> can't hurt to ask (looks for contact details) [22:42:13 CET] <JEEB> TheRock: and you have to look up for how each format is licensed. For example, this is the thing for AVC (the general terms http://www.mpegla.com/main/programs/AVC/Documents/avcweb.pdf ) [22:42:39 CET] <JEEB> but as I said, this is completely separate from any software licensing [22:44:07 CET] <JEEB> SortaCore: it's much less good for compression ratios and features but there's also openh264 from cisco which is under 2-clause simplified if you just need /some/ H.264 encoding https://github.com/cisco/openh264/blob/master/LICENSE [22:45:09 CET] <TheRock> JEEB: so let's say I'm selling an app that does only h264 decoding. In page 8 it says no royality up to 100k. [22:45:29 CET] <TheRock> when i got it settled with the MPEG LA, is there any other licensing required by h264 company or anyone else? [22:45:47 CET] <JEEB> officially not that I know, MPEG-LA was supposed to be the one-stop shop. [22:45:47 CET] <TheRock> i didn't get it [22:46:01 CET] <TheRock> ok. [22:46:03 CET] <JEEB> but this is, once again, completely different from software licensing [22:46:08 CET] <JEEB> just remember that [22:46:26 CET] <TheRock> so, software licensing is handled different at MPEG LA? [22:46:34 CET] <TheRock> that's the part i don't get [22:46:35 CET] <JEEB> it's unrelated to MPEG-LA [22:46:48 CET] <JEEB> you follow the software licensing of the OSS projects you use [22:46:50 CET] <JEEB> that's the first checkbox [22:47:03 CET] <TheRock> ah, i get it now. [22:47:26 CET] <TheRock> so when i use ffmpeg. I have to follow lpgl for decoding [22:47:28 CET] <JEEB> and then you follow the patent licensing mess if required (IANAL so talk to a lawyer if you really care) [22:47:37 CET] <TheRock> and additionally get a contract with mpeg la [22:47:41 CET] <TheRock> did you mean like that? [22:47:44 CET] <JEEB> TheRock: no, you need to follow LGPL for LGPL features (aka, you don't use --enable-gpl) [22:47:56 CET] <JEEB> as soon as you use --enable-gpl you go into GPL territory [22:48:04 CET] <JEEB> or otherwise utilize OSS software that is under the GPL [22:48:08 CET] <TheRock> yeah whatever license is used by the foreign source [22:48:22 CET] <JEEB> ok [22:48:36 CET] <TheRock> and additionally to that a contract with mpeg la [22:48:36 CET] <JEEB> but yes, basically keep with the software licensing first (it's the simpler one) [22:48:47 CET] <JEEB> and then you might have to deal with the patent licensing mess [22:49:29 CET] <TheRock> but does ffmpeg not require a license then too as they provide h264 stuff? [22:49:33 CET] <TheRock> when that's two different things [22:49:49 CET] <JEEB> FFmpeg is not officially producing any binaries [22:49:51 CET] <furq> ffmpeg doesn't provide binaries [22:49:53 CET] <JEEB> or distributing them [22:49:58 CET] <furq> it links to some other people's binaries [22:49:59 CET] <JEEB> which is what most patent licensing pools care about [22:50:10 CET] <TheRock> ok, got it :P [22:50:36 CET] <furq> those people may or may not have licenses, idk, but they're not making any money so it's unlikely the licensors care to go after them [22:50:51 CET] <SortaCore> there's a screen capture software I know that runs ffmpeg.exe in the background [22:50:54 CET] <furq> plus i'm pretty sure the two main guys distributing binaries are in the EU where software patents don't exist [22:50:55 CET] <SortaCore> paid for [22:51:10 CET] <TheRock> well, i'm in EU too [22:51:13 CET] <furq> basically unless americans are buying your product you're probably safe from mpeg-la and friends [22:51:24 CET] <TheRock> in EU the fines are not high usually [22:51:27 CET] <TheRock> but USA = millions [22:51:51 CET] <furq> you don't need a license for anything intra-EU because software patents aren't recognised in the EU [22:52:19 CET] <TheRock> so their USA patent is not world wide, unlike for trademarks (company names)? [22:52:23 CET] <furq> i am extremely not a lawyer though [22:52:25 CET] <JEEB> uhh, if I was you I'd stick a big IANAL there, and IIRC it was much more murky per-country [22:52:29 CET] <furq> ^ [22:52:59 CET] <JEEB> there definitely are people distributing binaries from France etc [22:53:13 CET] <JEEB> (videolan f.ex.) [22:53:15 CET] <JEEB> but those are thought to have done their own research [22:53:28 CET] <furq> also, to be very clear: patent license, not software license [22:53:32 CET] <furq> you're still bound by the (l)gpl [22:53:37 CET] <TheRock> yeah [22:54:17 CET] <JEEB> yea, it's two different worlds - and the software licensing one is generally a much more simple thing :P [22:54:28 CET] <JEEB> following GPL or LGPL or BSD is generally simple [22:54:56 CET] <furq> if you're inside the free usage tier for the patent licenses, which you probably do, then you should get one regardless [22:55:07 CET] <furq> otherwise you'll need someone qualified to tell you if you actually need one [22:55:21 CET] <furq> i suspect you don't, but who the fuck am i [22:57:54 CET] <TheRock> i prefer BSD license [22:58:29 CET] <JEEB> well different licenses convey different thoughts of the developer(s) [22:59:32 CET] <JEEB> also do remember that the older versions and v3 of (L)GPL are quite different. mostly in the "you can't use DRM" part, which came out after tivo did their thing which FSF didn't like [23:01:11 CET] <TheRock> LPGL is not bad, though [23:01:24 CET] <TheRock> afaik, it's enough to provide the .obj files so relinking is possible [23:01:32 CET] <TheRock> whereas with GPL you need to provide the full src [23:01:47 CET] <JEEB> yes, object files and code for the LGPL thing [23:02:05 CET] <JEEB> or just the code for the LGPL thing if it's a dynamically linked thing [23:02:27 CET] <JEEB> which is why a lot of people use shared libraries with LGPL [23:02:49 CET] <furq> isc for life [23:02:50 CET] <JEEB> with GPL, yes. if you base on GPL software your software must also be available under the GPL [23:03:06 CET] <JEEB> furq: ISC is nice and simple, but I do see the fact that people like to limit things somewhat [23:03:13 CET] <JEEB> esp. with libraries and LGPL [23:03:23 CET] <furq> yeah lgpl is fine [23:03:40 CET] <furq> i'm not one of these people who gets extremely angry about it online [23:04:12 CET] <JEEB> there's usually a reason why something is GPL or LGPL, and generally those that seem to have some commercial prospects let you license the (A)GPL thing with a more corporate-oriented license [23:04:28 CET] <furq> i might get a bit mad about the agpl [23:04:43 CET] <furq> but that's pretty normal i think [23:04:47 CET] <JEEB> the AGPL is very strict, yes. which is why I just often don't look at things that are AGPL [23:04:59 CET] <JEEB> but generally those projects have an alternative licensing scheme [23:05:05 CET] <TheRock> if you use LPGL, is it actually enough to provide the src/obj files on github or do they need to come together with the binary/installer [23:05:09 CET] <furq> is there anything notable that uses the agpl [23:05:18 CET] <furq> i assume anything agpl just doesn't get used because nobody wants to touch it [23:05:35 CET] <JEEB> I think some media serving stuff used it but also had a big big separate licensing thing [23:05:48 CET] <JEEB> so you could see how something worked but definitely not put it into production [23:05:50 CET] <furq> TheRock: you're supposed to provide the source in the same place as the binaries [23:06:00 CET] <furq> if you host the binaries on github then having the source on github is fine [23:06:14 CET] <SortaCore> ok sent them a message [23:06:36 CET] <furq> you basically want it to be impossible to be able to download the binaries but not the source [23:06:39 CET] <furq> because then you're in breach [23:06:45 CET] <JEEB> SortaCore: cool, hope that goes through well :) if not, there's alternatives like openh264 [23:07:05 CET] <TheRock> I see. I wanted to release the source and use a single static binary [23:07:07 CET] <JEEB> TheRock: technically the license says IIRC that the person can request the source code after 3 years or so, which is why I tend to just put the sources together with the code [23:07:08 CET] <SortaCore> well, the priciest DLL in the niche market I'm sending to is $10 [23:07:20 CET] <SortaCore> so they're not going to make a mint off my customers :p [23:07:28 CET] <TheRock> my plan was to provide a link to the src [23:07:31 CET] <TheRock> inside the app [23:07:37 CET] <furq> you don't need to ship the source with the binary [23:07:38 CET] <TheRock> but i guess that isn't possible [23:07:42 CET] <JEEB> yes, that's also really good. I'm just generally paranoid [23:08:07 CET] <furq> but if you have a download page on your site then that needs to link to a copy of the exact lgpl source you used [23:08:19 CET] <TheRock> yeah [23:08:21 CET] <furq> i.e. the exact release/commit [23:08:34 CET] <furq> and if you just link to github.com/ffmpeg then if github goes down then you're in breach [23:08:34 CET] <TheRock> so a link to github fo example is fine? [23:08:37 CET] <furq> it's up to you how likely you think that is [23:08:49 CET] <TheRock> yeah a link to my src/commit [23:08:52 CET] <TheRock> not the ffmpeg rep [23:08:58 CET] <SortaCore> *cough* my pi died [23:09:05 CET] <SortaCore> it was probably rebooted while it was still booting up [23:09:28 CET] <TheRock> when i provide the SRC *upon request* [23:09:29 CET] <furq> i mean you can do that but i would just host a tarball on the download server my binaries are on [23:09:33 CET] <TheRock> is that enough too? [23:09:36 CET] <furq> it's hardly any extra effort [23:09:39 CET] <SortaCore> yea, I would keep a copy of the source [23:09:49 CET] <SortaCore> then have "if GitHub is down, please contact the author for a copy" [23:09:57 CET] <SortaCore> that gives you some margin on time, as well [23:10:01 CET] <furq> when i've made binaries in the past i just added a step to my build system that created the source tarballs [23:10:37 CET] <SortaCore> hmmm [23:10:51 CET] <furq> linking to github is "probably going to be fine" but it's hardly any extra effort to definitely be fine forever [23:11:22 CET] <TheRock> and how about if you provide the src only upon request (i. e. you write in the info section of your app a notice)? [23:11:33 CET] <furq> i never bothered reading that far into the lgpl tbh [23:11:42 CET] <JEEB> TheRock: technically valid [23:12:13 CET] <JEEB> so technically you could require someone to actually request the source code from you [23:12:23 CET] <JEEB> which is valid for X years mentioned in the license [23:12:36 CET] <furq> tbh that actually seems like more effort to me [23:12:40 CET] <JEEB> yes [23:12:43 CET] <SortaCore> actually my client is using this DLL in programs that run on a screen-less device [23:12:45 CET] <JEEB> also you're much more likely to forget [23:12:57 CET] <SortaCore> so... GPL still even though user can't see anything? [23:13:03 CET] <furq> imagine you don't update the project for 18 months, delete your cloned ffmpeg repo [23:13:05 CET] <SortaCore> or even wire up a computer to it to dev on it? [23:13:06 CET] <furq> then you get a request [23:13:14 CET] <furq> now you've got to figure out exactly what commit you used to build the binaries [23:14:04 CET] <JEEB> SortaCore: is that regarding the requirements in GPL to show the license or something? I'm pretty sure it had provisions [23:14:30 CET] <JEEB> because I'm pretty sure there are embedded boxes with linux on it that don't have screens or anything [23:15:48 CET] <sfan5> >see long discussion in #ffmpeg [23:15:52 CET] <sfan5> >it's about licensing [23:15:55 CET] <sfan5> 🤔 [23:16:02 CET] <JEEB> lol [23:18:30 CET] <furq> hell yeah [23:57:35 CET] <SortaCore> yea JEEB [23:57:49 CET] <SortaCore> so if it's linux-box there's a section? [00:00:00 CET] --- Mon Nov 27 2017

1 0

ffmpeg-devel.log.20171125
by burek 26 Nov '17

26 Nov '17

[00:30:29 CET] <atomnuker> jamrial: how the hell to replace avpriv_atomic_ptr_cas? [00:30:58 CET] <jamrial> atomnuker: http://en.cppreference.com/w/c/atomic/atomic_compare_exchange [00:31:09 CET] <atomnuker> no, that's not the problem [00:31:24 CET] <atomnuker> its equal to atomic_compare_exchange(ptr, old, new); return old; [00:31:39 CET] <atomnuker> the issue is that the function itself takes void *, void * and a void * [00:31:59 CET] <atomnuker> but the atomic_compare_exchange_strong takes a const non-pointer for the new value (desired) [00:32:52 CET] <atomnuker> the options are to either scrap the function and do the exchange manually which works in all but two cases (both in utils.c) [00:33:10 CET] <atomnuker> or to I dunno, make a macro? [00:33:25 CET] <jamrial> i think you can declare them as _Atomic type* [00:34:25 CET] <jamrial> so for av_register_codec_parser() you can use static _Atomic AVCodecParser *av_first_parser or so [00:34:36 CET] <jamrial> not sure how the compat wrappers will handle that, though [00:35:36 CET] <atomnuker> do we need the compat macros at all? [00:35:49 CET] <atomnuker> my plan is to put the function in libavutil/internal.h [00:36:07 CET] <atomnuker> and remove all files that mess with avpriv_atomic [00:36:13 CET] <jamrial> no, i mean the compat/ folder wrappers for c11 atomics on compilers that don't support them [00:36:25 CET] <atomnuker> oh, hm [00:36:49 CET] <jamrial> i think they handle _Atomic attribute just fine, but nothing uses it in the code right now [00:37:28 CET] <jamrial> ignore them for now and focus on writing valid c11 atomics code [00:38:28 CET] <jamrial> also, not sure what function you want to put in lavu/internal.h [00:39:00 CET] <jamrial> the idea here is to replace all the lavu avpriv_atomic_ functions with the c11 atomics that are compiler builtins [00:40:20 CET] <jamrial> replace all their uses, i mean, so the functions can be safely removed [00:40:31 CET] <atomnuker> I have 2 patches which remove all avpriv_atomic usage except for avpriv_atomic_ptr_cas [00:41:10 CET] <atomnuker> and I think we should move avpriv_atomic_ptr_cas into internal.h [00:43:22 CET] <atomnuker> ah, I see, so you want to avoid having that function altogether [00:44:07 CET] <jamrial> atomnuker: also, as i said the other day, you could probably revert 133fbfc7811 and ec464c96831 to simplify some of the register functions if needed [00:44:26 CET] <atomnuker> doesn't help really [00:45:04 CET] <atomnuker> besides, wouldn't someone object if I did revert it? [00:45:41 CET] <jamrial> those changes were to make the register functions slightly faster [00:45:52 CET] <jamrial> registering codecs is far from anyone's bottleneck [00:46:12 CET] <jamrial> so if said changes get in the way of porting them to c11 atomics, they can be reverted [00:47:04 CET] <jamrial> especially when one of them is reported to be "slighty more complex" than necessary just to keep it ABI compatible back in 2013 [00:47:56 CET] <atomnuker> reverting 133fbfc7811 really doesn't help [00:49:01 CET] <atomnuker> if I change the parser register function to have an _Atomic prefix I also have to change its definition in avcodec.h [00:50:24 CET] <atomnuker> ec464c96831 wouldn't help either, that cas function is still used inside a loop [00:50:37 CET] <atomnuker> seems I have no choice but to manually rewrite the loops [00:54:25 CET] <jamrial> the _Atomic prefix would not be for the function, but the atomic variables [00:55:21 CET] <jamrial> static variables like av_first_parser in parser.c, and first_avcodec in utils.c [00:56:12 CET] <atomnuker> I've been looking at these register functions for some time now and I have _no_ idea how the operate [00:56:38 CET] <atomnuker> bloody linked lists [01:06:45 CET] <SortaCore> linked lists are so annoying [01:07:10 CET] <atomnuker> michaelni: how would you implement ec464c96831ac in less lines like it says in the description? [02:34:59 CET] <cone-187> ffmpeg 03Michael Niedermayer 07master:12a511f2c265: avcodec/sbrdsp_fixed: Fix integer overflow [02:34:59 CET] <cone-187> ffmpeg 03Karthick J 07master:a1f8f1340acc: avformat/dashenc: Associate mpd extension with dash muxer [02:34:59 CET] <cone-187> ffmpeg 03John Stebbins 07master:bdddcb7b030d: lavf/mov: fix crash in mov_read_sidx [02:34:59 CET] <cone-187> ffmpeg 03Mikulas Patocka 07master:279d2599dd6b: ffmpeg libopusdec: fix missing include file in libopusdec.c [02:58:09 CET] <atomnuker> jamrial: what's the difference between laxer and stricter atomics? [03:05:18 CET] <jamrial> atomnuker: performance, mostly. it affects how non-atomic memory accesses behave around the atomic operation [03:05:48 CET] <jamrial> don't ask me about specifics as it's far from my area of expertise :p [03:06:10 CET] <jamrial> BBB might be able to [03:25:18 CET] <atomnuker> with name like "strong" or "weak" I thought it would behave in a non-atomic manner in some conditions [03:38:44 CET] <jamrial> ah, i was talking about the memory order parameter, not the weak/strong variants of atomic_compare_exchange [03:38:57 CET] <jamrial> i have no idea what those do [03:39:32 CET] <jamrial> the memory order is available when you use the _explicit variants [03:39:53 CET] <jamrial> it's orthogonal to what you're trying to do anyway [10:05:47 CET] <cone-893> ffmpeg 03Richard Ling 07master:7d4fe0c5cb95: avfilter: add normalize filter [12:06:26 CET] <nevcairiel> atomnuker: weak can spuriously fail, its only good use that I know of is when you implement a tight loop with an atomic exit condition triggered externally, and a few more iterations due to lack of forced synchronization don't hurt, for a performance advantage (note: on x86 there is no difference, but on arm and ppc there might be) [13:59:13 CET] <durandal_1707> ubitux: gonnna do this http://www.ipol.im/pub/art/2017/201/ ? [15:19:27 CET] <ubitux> durandal_1707: nope, go for it [15:19:42 CET] <ubitux> feel free to add modes to dctdnoiz if it makes sense btw [15:38:43 CET] <kierank> durandal_1707: probably fixed in https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=d2917501c252d999e5478… [15:39:37 CET] <cone-893> ffmpeg 03Li, Zhong 07master:136e7cf64ce9: qsv/hevcdec: Load hw plugin by default on non-windows os [15:39:39 CET] <cone-893> ffmpeg 03Mark Thompson 07master:b26dd5ae2fb9: Merge commit '136e7cf64ce9e78de7158d6720539d51cb96b743' [16:12:01 CET] <jamrial> why was that closed as wont fix? [16:12:57 CET] <jamrial> i mean the gopro one [16:13:10 CET] <jamrial> and for that matter, that libvmaf as invalid as well... [16:13:33 CET] <nevcairiel> the vmaf one probably because its a dupe [16:13:40 CET] <jamrial> ah [16:13:52 CET] <jamrial> wonder why carl didn't mention that, then [16:16:02 CET] <cone-893> ffmpeg 03Mark Thompson 07master:e1d192442780: lavu/pixfmt: Remove gap in the middle of enum AVPixelFormat [16:16:03 CET] <cone-893> ffmpeg 03Mark Thompson 07master:89216895757c: doc/APIchanges: Fix lavu versions for OpenCL changes [16:21:13 CET] <jkqxz> nevcairiel: Do you have any comment on <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219795.html>? [16:22:08 CET] <nevcairiel> i still wonder why the entire function uses adapter2 in the first place, but thats unrelated =p [16:22:53 CET] <nevcairiel> is %ls portable? [16:23:48 CET] <JEEB> jkqxz: btw does this look alright for you? segfault that seemed to get fixed by this is linked in the next post https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220750.html ? [16:24:53 CET] <jkqxz> nevcairiel: With C99, yes. I've no idea if it works in every crazy Windows setup, though :P [16:25:31 CET] <nevcairiel> microsoft certainly doesnt document %ls, they use %S, and even claim that %S is ISO C [16:26:57 CET] <jkqxz> Not in the copy I have. [16:27:52 CET] <jkqxz> The Linux docs say "S (Not in C99 or C11, but in SUSv2, SUSv3, and SUSv4.) Synonym for ls. Don't use." [16:27:53 CET] <nevcairiel> "An ls, lS, ws or wS type specifier is synonymous with S in printf functions", there it is, they do mention it afterall =p [16:29:32 CET] <jkqxz> JEEB: Change is fine, I think. [16:29:41 CET] <jkqxz> device_uninit being called twice is rather nasty, though. [16:30:55 CET] <JEEB> well, the case is that you allocate the hwdevice, then you try init'ing it, and it fails. that calls uninit once. then you unref the buffer and it gets called again [16:31:10 CET] <JEEB> https://github.com/mpv-player/mpv/blob/master/video/decode/d3d.c#L97..L113 [16:31:12 CET] <JEEB> basically [16:31:26 CET] <jkqxz> It does makes sense in the hwcontext generic code. [16:31:32 CET] <jkqxz> Yeah. [16:32:28 CET] <jkqxz> Looking through other implementations, they all look safe except OpenCL. Oops. [16:32:43 CET] <nevcairiel> dxva2 probably has the same issue as d3d11 [16:33:10 CET] <jkqxz> It doesn't have a device_uninit function at all. [16:33:38 CET] <nevcairiel> oh right, it shoves that in the free callback for r easons [16:36:25 CET] <jkqxz> <http://sprunge.us/HRiA> [16:44:04 CET] <cone-893> ffmpeg 03James Almer 07master:4af050c46e2a: configure: remove superfluous cuvid and nvdec checks [17:08:44 CET] <cone-893> ffmpeg 03Mark Thompson 07master:8bbf2dacbfb4: hwcontext_d3d11: Log adapter details on device creation [17:08:45 CET] <cone-893> ffmpeg 03Mark Thompson 07master:f4e319d8a946: hwcontext_opencl: Reset internal command queue on device_uninit [17:11:59 CET] <cone-893> ffmpeg 03Mikulas Patocka 07master:fbdd78fa3e99: avcodec/fft: fix INTERL macro on 3dnow [17:13:06 CET] <atomnuker> 3dnow? [17:13:09 CET] <jamrial> 3dnow without sse means athlon thunderbird or older [17:13:15 CET] <jamrial> i'm amazed such cpus still work today [17:38:38 CET] <atomnuker> jamrial: do you know why "extern volatile int ff_avcodec_locked;" is exposed in internal.h? [17:38:45 CET] <atomnuker> nothing else seems to be using it [17:39:53 CET] <jamrial> atomnuker: not really. maybe it was meant to be used outside utils.c but didn't happen, and then it was left as is? [17:40:32 CET] <atomnuker> removed it and replaced it with proper atomics [17:49:27 CET] <jamrial> atomnuker: you still forgot the error_count initialization in ff_er_frame_start() [17:49:42 CET] <jamrial> according to michaelni it should be safe to use atomic_init() there [17:52:39 CET] <cone-893> ffmpeg 03Jan Ekström 07master:f6d49a0dc84a: hwcontext_d3d11va: properly reset values after release/close [17:57:44 CET] <atomnuker> ah, bloody hell, I thought I checked them all [18:41:16 CET] <Compn> approved a patch to the mailing list [18:41:21 CET] <Compn> deleted some spam [18:41:23 CET] <Compn> mod queue empty [18:53:22 CET] <durandal_1707> Compn: good job! [19:05:06 CET] <atomnuker> this month the ml has had the most traffic since january of last year (which had 2300 emails) [19:25:11 CET] <durandal_1707> atomnuker: is that bad? [19:35:10 CET] <atomnuker> no, its good, alot of nice patches this month from people who never posted before [20:01:27 CET] <cone-893> ffmpeg 03Martin Vignali 07master:07e427aa5655: avcodec/texturedsp : add rgtc1u gray decoding [20:01:28 CET] <cone-893> ffmpeg 03Martin Vignali 07master:21c06c4095f5: avcodec/hapdec : use gray8 for HapAlphaOnly decoding instead of RGB0 [20:01:29 CET] <cone-893> ffmpeg 03Martin Vignali 07master:8794e0c0372c: fate/hapAlphaOnly : add test for hap alpha only decoding [21:16:50 CET] <SortaCore> what is QSV's RecoveryPointSEI? [21:18:44 CET] <SortaCore> also, I figured out how to access RTSP's SOCKET [21:18:51 CET] <SortaCore> socket = (SOCKET)*(*(*(((int ***)rtsp_format_context->priv_data) + 1) + 2) + 1); [21:19:07 CET] <SortaCore> healthy code (thumbsup) [21:24:27 CET] <omerjerk> how do I mark an encoder as experimental? [21:26:54 CET] <jkqxz> Put AV_CODEC_CAP_EXPERIMENTAL in AVCodec.capabilities. [21:35:01 CET] <omerjerk> thanks. [22:01:22 CET] <tmm1> SortaCore: thats an h264 sei [22:28:26 CET] <SortaCore> which sei tho [22:28:38 CET] <nevcairiel> the recovery point sei, obviously [22:28:54 CET] <nevcairiel> there is one with that name =p [22:29:08 CET] <SortaCore> I keep getting those unrecognised SEIs for 229 [22:29:25 CET] <SortaCore> apparently it's dodgy Chinese cameras [22:29:37 CET] <SortaCore> (secretly giving the camera commands from Chinese government) [22:31:59 CET] <JEEB> AVC didn't have a generic IRAP NAL units for open gop which is why I think that SEI was utilized to tell the client "from this point on you can play" [22:32:49 CET] <SortaCore> is there a way to turn those off? [22:33:25 CET] <JEEB> set your thingamajig to not use open gop? libavcodec should be able to handle those fine, though. [22:34:11 CET] <SortaCore> is the jig the camera? [22:34:20 CET] <SortaCore> yea, I just get a warning, or it might be an error? [22:34:31 CET] <SortaCore> I modified the log callback to discard them [22:41:36 CET] <BtbN> atomnuker, this audio glitch has been going on on Twitch for a while now. Since most streams use OBS, which uses the ffmpeg aac encoder, could this be a glitch in our aac encoder? https://clips.twitch.tv/NicePopularPorcupineCurseLit [22:42:17 CET] <BtbN> It is triggered by various high pitched noises. Alttp has a bunch of them, and it's happening over and over again, and it's highly annoying. [22:48:36 CET] <BtbN> https://btbn.de/public/glitch.mp4 here it's as raw mp4 [22:51:02 CET] <atomnuker> I wish most would use the ffmpeg aac encoder... [22:51:16 CET] <BtbN> Every stream running with OBS uses it [22:51:23 CET] <BtbN> which is the absolute majority on Twitch [22:51:53 CET] <atomnuker> its been *5* years since I used obs but I remember it needed an ffmpeg.exe [22:52:07 CET] <atomnuker> and I think most compilations used libfdk_aac [22:52:08 CET] <BtbN> it never needed an ffmpeg.exe oO [22:52:25 CET] <atomnuker> I thought I remembered you had to download it [22:52:30 CET] <BtbN> The old OBS, which was 5 years old, uses libvo_aac or something [22:52:59 CET] <BtbN> The current, new OBS uses libav*, and by default, that is if you don't build it with fdk yourself, it uses the ffmpeg native encoder [22:54:01 CET] <BtbN> So I'm pretty sure that glitched clip there was encoded with the ffmpeg aac encoder [22:54:24 CET] <BtbN> And I'd like to know if it's a bug on ffmpegs end [22:56:16 CET] <atomnuker> do you know often it occurs? [22:57:03 CET] <BtbN> not all the time. But specially when there's a lot of high pitched noises(In Link to the past, the sound of the spike-things or the boomerang hitting a wall is very trigger happy there) [22:57:22 CET] <BtbN> I'd say once or twice every couple hours, with alttp [22:59:32 CET] <atomnuker> hm, I know kierank's using the encoder in production and he hasn't seen anything like this [23:00:04 CET] <atomnuker> though he doesn't use aac_pns because it was unstable [23:00:23 CET] <kierank> Yes [23:00:23 CET] <BtbN> This is going on on Twitch for almost a year now according to some people. I have only noticed in the last couple months [23:00:52 CET] <atomnuker> if I knew this many people use the encoder I'd have made the fast coder the default [23:01:23 CET] <BtbN> By now, with obs, it's several tens of thousands of people using it all the time [23:01:40 CET] <BtbN> if not more [23:01:50 CET] <BtbN> over 90% of the streams on Twitch are made with it [23:02:34 CET] <JEEB> yup [23:02:44 CET] <atomnuker> I really doubt it, I don't watch twitch streams often but every time I do I look at the spectrum [23:02:53 CET] <atomnuker> and I see that 15khz bandwidth limiting fdk does [23:03:10 CET] <BtbN> None of the popular streaming software use fdk though [23:03:24 CET] <BtbN> You also have to look at the source stream. Not one of their transcodes. [23:03:29 CET] <atomnuker> I thought people downloaded special builds to have it [23:03:34 CET] <JEEB> https://twitter.com/marcan42/status/873241816434221056 [23:03:35 CET] <BtbN> That might be using fdk, but I have no idea. [23:03:40 CET] <JEEB> kind of reminds me of this [23:03:51 CET] <sfan5> obs can't ship with fdk because of the licensing anyway, can it? [23:03:52 CET] <JEEB> although he uses some heavy words there :P [23:04:06 CET] <JEEB> sfan5: as long as you don't put it together with (L)GPL stuff you can distro it [23:04:10 CET] <JEEB> like ubuntu does, or debian [23:04:21 CET] <sfan5> but x264 is gpl and i'm sure they ship that [23:04:56 CET] <JEEB> yup. in anothoer process, IIRC [23:05:16 CET] <BtbN> no [23:05:22 CET] <JEEB> oh, ok [23:05:24 CET] <BtbN> nothing is done in another process, except for qsv [23:05:28 CET] <JEEB> ah, right [23:05:59 CET] <BtbN> But I don't think obs ships with fdk by default [23:06:09 CET] <BtbN> And I'm not aware of any widely used custom builds with it [23:06:19 CET] <BtbN> most people who use obs don't even know what aac is [23:09:06 CET] <atomnuker> I'll run the lttp soundtrack through the encoder for a few hours and I'll use af_volumedetect to see if anything bad does appear [23:09:17 CET] <BtbN> It's not in the soundtrack [23:09:21 CET] <BtbN> it's the in game sound effects [23:09:55 CET] <JEEB> can someone provide a simple enough test case that can be utilized? [23:10:06 CET] <JEEB> for repeating it [23:10:12 CET] <BtbN> So far I have not been able to reproduce it intentionally [23:10:42 CET] <BtbN> https://www.twitch.tv/speedgaming/videos/all and https://www.twitch.tv/speedgaming2/videos/all have a huge bunch of hour+ long gameplay [23:11:23 CET] <JEEB> yea, would be nice if someone could cap audio from one of those things that seems to make it happen and then that thing could be looped for testing [23:12:34 CET] <nevcairiel> to really be reproducible you need the original audio though, so thats a bit harder [23:12:37 CET] <atomnuker> well, I haven't really played through the entire lttp, maybe I should do that tomorrow and record the audio [23:13:06 CET] <JEEB> nevcairiel: yea that's why I was requesting :/ [23:13:18 CET] <JEEB> atomnuker: was lttp the SNES one? [23:13:23 CET] <BtbN> it was [23:13:38 CET] <JEEB> right, I should now finally be able to play it with the little SNES box I got :V [23:13:52 CET] <BtbN> it emulates pretty perfectly [23:13:57 CET] <atomnuker> it sure does [23:14:18 CET] <atomnuker> I wish saturn games would emulate perfectly too... [23:14:27 CET] <rcombs> tfw I can't find my snes [23:14:56 CET] <BtbN> The hookshot sound is also very trigger-happy [23:15:04 CET] <BtbN> and hookshot hitting the wall is very easy to do [23:16:18 CET] <JEEB> rcombs: I need to find my Megadrive from Russia [23:26:03 CET] <atomnuker> the megadrive was so ahead of its time [23:26:48 CET] <atomnuker> had a nice, generic cisc cpu [23:27:00 CET] <atomnuker> wasn't until the xbox that a console used a cisc cpu again [23:27:22 CET] <JEEB> my father's sister's kids never really understood how nice the segamega was :< [23:27:33 CET] <JEEB> so if they still keep that box around, I will take it back [23:43:52 CET] <BtbN> atomnuker, https://btbn.de/public/lttp.flac some lossless recording of a bit lttp messing around [23:49:17 CET] <atomnuker> jesus christ, 27x realtime isn't nice at all [23:51:29 CET] <iive> atomnuker: you mean, playing games at 27x speed? [23:52:02 CET] <BtbN> Pretty sure he means that the aac encoder is too slow for his liking [23:52:35 CET] <iive> hum, 27x is acceptable speed. or maybe it doesn't produce good quality at that speed? [23:58:02 CET] <atomnuker> the native opus encoder is 200x realtime if you disable most searching, libopus is like 96x realtime [23:58:33 CET] <atomnuker> though the speed would plummet if I implemented support for the pitch prefilter [23:58:55 CET] <atomnuker> (or maybe it wouldn't, its a FIR filter IIRC so it can be SIMDd) [00:00:00 CET] --- Sun Nov 26 2017

1 0

ffmpeg.log.20171125
by burek 26 Nov '17

26 Nov '17

[00:00:16 CET] <kepstin> Scrappy: hmm. what container & codec? [00:01:21 CET] <kepstin> in many cases the avg_frame_rate is actually probed or guessed by looking at a few frames, and in some cases i guess it might not be fully determined until decoding. I wonder how the ffprobe -show_streams output compares. [00:12:00 CET] <AppleTor> Ola, regarding of my question above, is it possible to make ffmpeg retry downloading the failed chunk? instead of skipping it [00:58:16 CET] <CCFL_Man> anyone here have a hacked tivo hd with mfs ftp? [02:56:15 CET] <SortaCore> what are reference frames, and when should I need more of them? [02:56:29 CET] <SortaCore> Video: h264 (h264_qsv) (High), 1 reference frame (avc1 / 0x31637661), nv12, 960x480, q=2-31, 1000 kb/s [02:57:34 CET] <iive> reference frames are the frames that are used as basis for motion compensation [02:58:47 CET] <SortaCore> when should there be > 1? [03:28:06 CET] <DHE> more are usually helpful for image quality, especially when the video is prone to brief bursts of temporary change (eg: a flash of lightning) [03:28:34 CET] <DHE> but diminishing returns sets in quickly, and the number of reference frames is constrained by the 'Level' capabilities of your player [03:32:38 CET] <TheRock> can anyone confirm that ffmpeg builds with vs 2013 [05:12:13 CET] <factor> I get the error "ERROR: vaapi requested but not found." when trying to compile Kodi for android. Said to come here for ffmpeg erros. [06:01:56 CET] <vigilante> hi can i remux using ffmpeg? [06:02:06 CET] <vigilante> from Bluray dvd?/ [06:02:21 CET] <vigilante> and get a mkv output? [06:28:03 CET] <TheRock> while buildin static ffmpe [06:28:29 CET] <TheRock> do i need filters, bsfs, indevs, protocols, [06:28:35 CET] <TheRock> or can i disable them all [06:28:51 CET] <TheRock> *i just need to play a video* such as mp4, wmv, avi, etc. [10:18:06 CET] <illegal> I am having a problem converting to webp, it gives the images transparent borders https://i.imgur.com/D3CKzHg.png | https://i.imgur.com/r1a9at6.png [10:20:52 CET] <illegal> I am using this .bat to convert a whole folder https://ghostbin.com/paste/gvpje [10:21:22 CET] <illegal> could just be whatever program is previewing the thumbnails [10:53:54 CET] <illegal> Nevermind I believe it's the thumbnail previewer, sorry [11:50:05 CET] <radicate> Hey guys, perhaps someone knows what's required in order to make the "rtmp_conn" option to be available? I'm getting this error when trying to use it: "Unrecognized option rtmp_conn" [12:04:57 CET] <Yosh12345mpeg-gr> hi, i have one question :) does anyone have some kind of script which do precise video cutting which would re-encode to first keyframe, and copy the rest of data ? [12:06:02 CET] <Yosh12345mpeg-gr> or --- to dump precise keyframe offsets, I'll do script myself :) [12:10:24 CET] <seleejane> hi [14:17:48 CET] <pl0t> hi, mplayer works with alsa plugin, ffplay does not play (although pulseaudio plug appears, it is silent as seen in pavucontrol), youtube does work, soundcloud does not, what could be the problem? [14:22:19 CET] <faLUCE> Hello. I created this library, which wraps ffmpeg: https://github.com/paolo-pr/laav . It includes a low-latency streaming system, maybe the first open source one. Give me a feedback [14:23:16 CET] <DHE> in what way is it low latency? [14:23:36 CET] <faLUCE> the correct term is "lowest possible" [14:23:44 CET] <DHE> my question stands [14:23:45 CET] <faLUCE> (I defined it as "optimum latency") [14:23:58 CET] <faLUCE> well, all the modules are optimized in latency [14:24:01 CET] <faLUCE> this is the meaning [14:24:23 CET] <atomnuker> do you use draw_horiz_band()? [14:26:08 CET] <JEEB> talking of low latency https://www.youtube.com/watch?v=A4L5xEXXlas [14:26:08 CET] <atomnuker> if not and you want the best possible latency you should [14:27:36 CET] <faLUCE> [14:24] <atomnuker> do you use draw_horiz_band()? <--- for what? [14:28:37 CET] <atomnuker> to get lines of a frame before the whole frame's done rendering? [14:28:50 CET] <faLUCE> atomnuker: I use gstreamer for rendering [14:28:59 CET] <atomnuker> *decoding [14:29:15 CET] <faLUCE> I use gstreamer for decoding too [14:29:52 CET] <faLUCE> ffmpeg is on the server side [15:30:40 CET] <durandal_1707> faLUCE: expect lawyers knocking on you door [15:47:47 CET] <pl0t> ah, and ffmpeg output: https://pastebin.com/WwnQekiC https://pastebin.com/5mLiDAvq <- stucks at that [15:50:30 CET] <redrabbit> https://images-na.ssl-images-amazon.com/images/I/71Y7Lx7S8dL._SL1100_.jpg < bwarf [15:55:43 CET] <debianuser> pl0t: If your problem related to pulseaudio you may want to repeat your question in #pulseaudio channel. [16:26:42 CET] <faLUCE> durandal_1707: why? [16:30:12 CET] <concatter98298> Hi [16:30:53 CET] <concatter98298> please look into this code https://pastebin.com/AztN4S7w [16:30:59 CET] <concatter98298> its batch [16:31:21 CET] <concatter98298> basically loop all files in folders and add them to concat.txt [16:31:37 CET] <concatter98298> file 'name' /n duration 0.3 [16:31:45 CET] <concatter98298> video ends up looking shit [16:32:07 CET] <concatter98298> I want to make all my videos 0.3 seconds and connect them into one video [16:37:37 CET] <faLUCE> what is the problem with my library? [16:37:38 CET] <faLUCE> Ricordo che tempo fa qui ci fu una surreale discussione sulla Collezione Farnese, dove io tentavo inutilmente di far capire che questo patrimonio è superiore, per mole e importanza, a quello attualmente contenuto nel Louvre. [16:37:39 CET] <faLUCE> A distanza di qualche mese, ecco che spunta questo video, dove il direttore del MANN, sottolinea appunto che si tratta del museo archeologico più grande al mondo. [16:37:41 CET] <faLUCE> https://www.youtube.com/watch?v=vCkCU7xvekM [16:37:42 CET] <faLUCE> Ma lasciamo pure le persone credere che il non plus ultra, in Italia, siano gli Uffizi. [16:37:44 CET] <faLUCE> In ogni caso, a questo tizio (Giulierini), benché ignaro del tutto che l'arte/archeologia etrusca nella zona di Capua è importante e rilevante quanto quella umbra e toscana (ma lo scoprirà col tempo), l'Italia tutta dovrebbe fare un monumento. [16:37:46 CET] <faLUCE> Quello che Giulierini è stato in grado di fare per riportare in vita il MANN ha dello stupefacente e commovente. [16:37:47 CET] <faLUCE> Ecco: ci vorrebbero, in Italia, esattamente persone come Giulierini, e NON come acremone. [16:37:49 CET] <faLUCE> Sentite cosa dice Giulierini di Firenze: [16:37:50 CET] <faLUCE> https://www.youtube.com/watch?v=vCkCU7xvekM&t=10m20s [16:37:51 CET] <faLUCE> Finalmente un toscano non toscanocentrico. [16:37:53 CET] <faLUCE> Se acremone fosse toscano e se fosse in qualche ministero culturale, sarebbe la rovina dell'Italia. [16:37:55 CET] <faLUCE> sorry [16:37:56 CET] <faLUCE> (I pasted a long code in a wrong channel) [16:40:30 CET] <pl0t> :D right after "what is the problem?" came a long paste, just like some navy seals stuff [16:50:12 CET] <faLUCE> please can you help me understanding if all is ok about the license of my library? https://github.com/paolo-pr/laav [16:50:22 CET] <faLUCE> (it wraps ffmpeg) [16:50:51 CET] <faLUCE> I used GPL 3.0 [18:42:11 CET] <leewdch> hello. just a question, if a codec (let's say opus) is compatible with two container types (.opus and .ogg), is it safe to simply rename a file 'test.opus' to 'test.ogg'? since I don't want to re-encode the file and just change the containers I can just rename to swap it, right? [18:44:52 CET] <SortaCore> lol [18:45:21 CET] <SortaCore> you may be able to export opus to a raw opus format, and then re-add it in ogg? [18:45:41 CET] <SortaCore> but renaming doesn't change the container format [18:45:58 CET] <SortaCore> most video players will read the type from the content, not from file ext [18:46:50 CET] <leewdch> I see [18:47:02 CET] <leewdch> then someone lied to me on the internet \o [18:47:12 CET] <SortaCore> well, take H264 [18:47:49 CET] <SortaCore> you can have it in a MP4 or MKV [18:48:18 CET] <SortaCore> but MP4 and MKV are particular container formats for several streams at once - audio, video, subtitles [18:48:44 CET] <SortaCore> and those container formats are obviously used in the file's content, not in the file name [18:49:14 CET] <SortaCore> so whether you have MP4 in a .mkv may upset some players (maybe VLC?) otherwise it'll just read the real format [18:49:39 CET] <leewdch> so if a file can be wrapped in two different containers, can I just ffmpeg -i <input> -c copy <output.ogg> ? [18:49:58 CET] <sfan5> yes [18:50:47 CET] <sfan5> .opus and .ogg are just two file extensions for the same format btw [18:50:57 CET] <sfan5> so you can in fact just rename it [18:51:10 CET] <leewdch> oh, you see? that's what I was asking in the first place [18:52:17 CET] <leewdch> sometime in tutorials you are asked to rename .img to .iso for whatever reasons, so I was wondering if you can do that too if a file can be wrapped in two different containers anyway [18:52:32 CET] <leewdch> like opus [18:54:06 CET] <sfan5> you can't generally do that, it happens to be possible in this case [18:54:13 CET] <JEEB> 32 [19:08:56 CET] <SortaCore> there we go then [19:09:11 CET] <SortaCore> so mp4 <-> mkv is bad, but ogg and opus are same container format anyway [19:09:42 CET] <SortaCore> although I've not heard of a set ext for ogg video [19:32:23 CET] <shmibs> ogv? [19:32:30 CET] <shmibs> and oga [21:25:38 CET] <nahro> hello [21:26:24 CET] <nahro> when using -itsoffset for audio, the audio glitches for a brief moment at the start [21:26:38 CET] <nahro> anybody else have this issue [21:56:02 CET] <durandal_1707> nahro: pastebin full output [22:00:07 CET] <durandal_1707> lol [22:01:12 CET] <TheRock> you made him close the page [22:48:18 CET] <TheRock> is there a way to build ffmpeg with software renderer only [22:48:24 CET] <TheRock> in ./configure [22:49:14 CET] <furq> renderer? [22:49:55 CET] <JEEB> while there's some funky things in libavdevice, FFmpeg itself is not really a thing to utilize for rendering [22:49:59 CET] <JEEB> (of video) [22:50:13 CET] <TheRock> i mean processing [22:50:18 CET] <TheRock> for encoding and decoding [22:50:26 CET] <TheRock> i saw some nvidia specific parts [22:50:30 CET] <TheRock> i don't need that [22:50:59 CET] <JEEB> yea, since the header is included it can get enabled by default in a lot of places, but will not get utilized by default [22:51:09 CET] <TheRock> I think it was nvdec [22:51:20 CET] <TheRock> i caused compile errors [22:51:22 CET] <TheRock> it* [22:51:24 CET] <JEEB> you have to specifically ask for hwdec or hwenc [22:51:26 CET] <JEEB> huh [22:51:43 CET] <JEEB> I haven't heard of compile errors with it, but it's always possible :P [22:51:56 CET] Action: JEEB has built for *nix and windows [22:51:56 CET] <TheRock> I compile with VS2013 and SDK 7.1 to support XP [22:52:09 CET] <TheRock> and VS2013 treats some stuff as errors [22:52:12 CET] <TheRock> where as vs2017 wont [22:52:24 CET] <JEEB> let's see our MSVC FATE instances [22:52:24 CET] <TheRock> the vs2017 compile went well. [22:52:45 CET] <JEEB> http://fate.ffmpeg.org/report.cgi?slot=x86_64-msvc12-windows-native&time=20… [22:52:51 CET] <JEEB> the MSVC 2013 thing seems to be passing [22:53:03 CET] <JEEB> it fails a test, but that's after compilation [22:54:06 CET] <TheRock> The current git clone fails in \libavcodec\nvdec_264.c [22:54:07 CET] <TheRock> line 111 [22:54:22 CET] <TheRock> with VS2013 [22:54:32 CET] <TheRock> so i configured with --disable-nvdec [22:54:34 CET] <JEEB> that thing I just linked is MSVC 2013 [22:54:36 CET] <TheRock> it compiles now [22:54:46 CET] <TheRock> Yeah, i know [22:54:46 CET] <JEEB> and it seems like 8794e0c037 is current master [22:54:56 CET] <JEEB> so current master seems to pass in MSVC 2013 [22:55:14 CET] <JEEB> and yes, you can disable it like that if you have some specific issues [22:55:30 CET] <JEEB> that said, I'm just saying that our testing suite finds no compilation errors and has nvdec enabled [22:55:49 CET] <TheRock> I downloaded the current git repository [22:56:00 CET] <TheRock> is that 8794e0c037? [22:56:03 CET] <JEEB> git show [22:56:07 CET] <JEEB> shows you the current hash [22:56:18 CET] <JEEB> but yes, currently it is at that hash [22:56:25 CET] <JEEB> like, right now. which is what the test run tested [22:57:03 CET] <TheRock> hmmm [22:57:07 CET] <JEEB> anyways, what I was trying to point out is that whatever's happening to you is specific to something [22:57:17 CET] <JEEB> are you on an older version of FFmpeg, or older version of MSVC 2013? [22:57:25 CET] <JEEB> since 2013 did get a good few updates [22:57:47 CET] <TheRock> i haven't checked, but i use the current ffmpeg version [22:58:00 CET] <TheRock> maybe i should update 2013 [23:02:49 CET] <TheRock> the error was weird anway [23:03:12 CET] <TheRock> I wouldnt know how to fix it [23:14:52 CET] <TheRock> looks like it finished [23:15:04 CET] <TheRock> w/o othe errors [23:15:08 CET] <TheRock> other* [00:00:00 CET] --- Sun Nov 26 2017

1 0