Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

December 2017

1 participants
62 discussions

ffmpeg-devel.log.20171215
by burek 16 Dec '17

16 Dec '17

[00:00:17 CET] <atomnuker> apparently it can support 1 packet in -> multiple frames out, its used by some audio codecs iirc [00:00:50 CET] <atomnuker> or you could support only the new decoding api which allows for that without hacks [00:00:50 CET] <wm4> AV_CODEC_CAP_SUBFRAMES doesn't really do anything [00:01:23 CET] <wm4> it's only used for a weak check that prints a warning (which michaelni bullied me into porting, and which he since ignored, even though it triggers for some real files) [00:02:24 CET] <atomnuker> should be deprecated then [00:05:04 CET] <durandal_170> daddesio: if frame doesnt begin in new byte each time, there its nothing you can do to support seeking [00:05:29 CET] <michaelni> wm4, "which michaelni bullied" <-- patch review is not bullying (if that is what this refers to) Please dont randomly throw insults around [00:05:33 CET] <daddesio> ^ without a reframer... :P [00:05:51 CET] <daddesio> I forgot if it does, let me check. [00:06:31 CET] <durandal_170> im being bullied on ml all the time [00:07:42 CET] <daddesio> durandal_170: Within one SCDl packet, MicroTalk frames don't have to begin on a new byte. Across SCDl packets though, the bitstream reader is reset. [00:07:50 CET] <daddesio> So seeking is possible, in theory. [00:08:19 CET] <durandal_170> daddesio: yes, writing bit streamer filter would do it [00:09:59 CET] <cone-639> ffmpeg 03Michael Niedermayer 07master:5e03eea673a9: avcodec/vp9: mark frame as finished on decode_tiles() failure [00:10:00 CET] <cone-639> ffmpeg 03Steven Robertson 07master:2d131fc31bcd: avformat/movenc: Add support for more colorspaces [00:11:18 CET] <jamrial> StevenLi_: the patch to remove the duplicate reverse arrays didn't get approved [00:13:51 CET] <StevenLi_> looks like libavcodec and libavdevice, i will apply the patch build a same reverse.c into libavformat, now just be used for hlsenc. [00:22:50 CET] <wm4> michaelni: demanding pointless things, giving short dismissals without explanation (like obscure command lines and just saying they "fail", you do that all the time), making up claims and insisting they're absolute, are [00:24:15 CET] <wm4> michaelni: oh, also quoting private communication without consent [00:24:50 CET] <michaelni> wm4, stop slandering me [00:26:33 CET] <jamrial> calm down, please [00:28:01 CET] <wm4> michaelni: which of those do you claim to be slander [00:38:51 CET] <michaelni> wm4, i do not know why you keep attacking me and why you try to involve me into these disucssions which are completely off topic. The statements you make are the way you present them slander. I, like everyone is trying to improve FFmpeg and to do that found bugs are reported, issues found in patches are pointed out and so on. I havnt even replied to many mails from you recently IIRC. Can you please just stop with these [00:38:51 CET] <michaelni> attacks, iam interrested to work on the code not to be accused and insulted randomly [00:40:19 CET] <wm4> sure, if you stop yours [00:40:23 CET] <iive> wm4: what are you talking about? what is the private communication that michael has quoted? [00:41:22 CET] <wm4> iive: he posted a line in a mailing post I sent to him privately in IRC (he didn't even respond on IRC) [00:41:34 CET] <wm4> all to make me look bad [00:41:42 CET] <iive> wm4: where and when? [00:41:52 CET] <iive> i still have no idea what you are talking about. [00:41:54 CET] <michaelni> this is slander --> <wm4> all to make me look bad [00:42:17 CET] <wm4> it's not slander to point out your misbehavior [00:43:04 CET] <michaelni> i have not done anything with the intend to make you look bad, saying that i did is slander [00:43:14 CET] <wm4> michaelni: your obnoxious behavior and rejecting patches on minor bullshit almost made me leave this project [00:43:37 CET] <iive> wm4: i still wait for your answer [00:43:53 CET] <nevcairiel> if its so minor, maybe you should just change it in review =p [00:43:57 CET] <wm4> iive: I'm not your personal google [00:44:21 CET] <wm4> nevcairiel: well, someone else did some garbage just to make michaelni happy about his bullshit argument [00:44:23 CET] <iive> wm4: i cannot google your personal private communication [00:45:16 CET] <wm4> michaelni: don't forget that your behavior already caused a major fork... did you ever reflect upon that? [00:45:47 CET] <nevcairiel> there is plenty blame to go around for that, its not on one person [00:46:50 CET] <wm4> not sure why you feel the need to defend him [00:48:06 CET] <iive> wm4: where and when has michael quoted your private communication. [00:49:05 CET] <wm4> mailing list, probably around october or so? [00:49:18 CET] <iive> what's the topic? [00:49:35 CET] <wm4> iive: do you have any pets? [00:50:17 CET] <iive> you want to know my secret pass phrase? [00:51:00 CET] <iive> anyway, the fact that you are bringing back 2 months old issue, even if true tells me what I want to know. [00:51:45 CET] <wm4> I'm not bringing back a 2 months old issue, you are [00:51:53 CET] <wm4> I only cited it as example of past michaelni misbehavior [00:52:13 CET] <wm4> and yes I'm clearly sick of his behavior [00:52:42 CET] <iive> don't worry, it is not michael's fault. [00:53:19 CET] <wm4> yes it is [00:53:27 CET] <wm4> it's my fault for being bothered by it, of course [00:53:54 CET] <iive> you've changed a lot and not for the better. You are burning out, fast. [00:54:32 CET] <wm4> are you now an internet psychologist? [00:54:38 CET] <iive> yes [00:55:00 CET] <wm4> ok, please go to some offtopic channel [00:55:45 CET] <iive> first calm down. [11:13:31 CET] <JEEB> lol I should just post a patch to remove this thing [11:13:32 CET] <JEEB> src/libavcodec/hevc_cabac.c:37:21: warning: variable 'num_bins_in_se' is not needed and will not be emitted [11:13:45 CET] <JEEB> it's a static const [11:29:52 CET] <cone-460> ffmpeg 03Martin Vignali 07master:49dced9fd0c8: avfilter/x86/vf_interlace : avoid crash when data are unaligned [11:29:53 CET] <cone-460> ffmpeg 03Martin Vignali 07master:3c6dc270355f: avfilter/x86/vf_interlace : avfilter/x86/vf_interlace : fix crash when using unaligned data in low_pass complex [12:53:17 CET] <Chloe> Am I able to get the fate samples without rsync? [12:53:38 CET] <JEEB> yes [12:53:45 CET] <JEEB> http://fate-suite.ffmpeg.org/ [12:54:05 CET] <BtbN> rsync is the more efficient way though, if you don't want just one sample [12:54:29 CET] <Chloe> I'm behind an oppressive proxy it seems [12:54:50 CET] <Chloe> I have a bunch of them downloaded, but I just wanted to update [12:56:47 CET] <Chloe> Just gonna wget --recursive it, I think my samples are all really old anyway (probably enough has changed to warrant a full dl) [12:57:43 CET] <JEEB> Chloe: rsync can do HTTP IIRC [12:57:50 CET] <JEEB> oh wait no [12:57:51 CET] <JEEB> welp [12:59:08 CET] <Chloe> I had thought there was a way to do rsync over HTTP but I couldn't find it, hence me just asking [12:59:44 CET] <jkqxz> rsync needs support from the server to work (calculating the rolling checksums). [13:00:33 CET] <jkqxz> The samples do not change, they are only added to (so that test runs on old versions still work). You probably have most of it already, even with a version from a while ago. [13:03:11 CET] <Chloe> `wget -r -np -R "index.html*" -nH -c http://fate-suite.ffmpeg.org/` should do it then I guess [14:12:20 CET] <jdarnley> Is anyone here familiar with the Intel Software Development Emulator and its error messages? [14:14:25 CET] <Compn> no but feel free to paste error :) [14:14:50 CET] <jdarnley> I tried to run checkasm but got these three lines [14:14:52 CET] <jdarnley> SDE ERROR: header_cm == header_bv [14:14:52 CET] <jdarnley> Trackers are NYI, therefore CM should be the same as BV [14:14:52 CET] <jdarnley> at (no-file):303 Function (no-func) [14:16:14 CET] <Compn> the trackers are nyi only gets one result in google [14:16:18 CET] <Compn> https://stackoverflow.com/questions/47420032/when-can-i-call-xsaves-and-xsa… [14:16:25 CET] <Compn> fun error message for sure. [14:16:45 CET] <jdarnley> I would guess that NYI stands for "not yet implemented" -- Oh good [14:17:10 CET] <Compn> why would it abbreviate in the error message haha [14:17:28 CET] <Compn> The plumbus FNI and BV and CM is RD. [14:17:29 CET] <jdarnley> Perhaps they think only their internal devs will see this one [14:18:00 CET] <iive> jdarnley: i've used sde, but it's errors are completely alien :D [14:18:49 CET] <jdarnley> You don't think I need at least AVX for it do you? [14:19:02 CET] <iive> jdarnley: does it work with some other program. [14:19:15 CET] <jdarnley> hm, I didn't try [14:19:28 CET] <iive> jdarnley: no, I used it to emulate avx on sse, and it managed quite well. [14:19:53 CET] <jdarnley> `./sde64 -- $(which true)` worked [14:21:10 CET] <iive> are you trying to run avx512 code? [14:21:17 CET] <jdarnley> Not yet [14:21:30 CET] <jdarnley> But I did plan to [14:22:52 CET] <iive> what version of sde are you running? [14:23:00 CET] <jdarnley> Oh great. The link in the readme for "usage questions" send me to a read-only archived forum [14:23:07 CET] <jdarnley> The latest I think [14:23:25 CET] <jdarnley> 8.12 it says [14:24:43 CET] <jdarnley> Maybe I'll write be own little program just to test these few instructions. [14:25:55 CET] <iive> yeh, good idea. [14:26:23 CET] <iive> also, try specifying different cpu. [14:26:55 CET] <iive> the last version i've used is 8.4.0, so if you suspect regression, try it out. [14:27:25 CET] <jdarnley> noted, thanks [14:37:03 CET] <jdarnley> ls [14:37:50 CET] <jdarnley> great, 8.4 segfaults [14:52:37 CET] <Gramner> jdarnley: sde can be quite buggy, try a bunch of different versions [15:00:47 CET] <jdarnley> oh [15:16:30 CET] <iive> it's possible that the segfault and the error are caused by same issue, just (not) handled. [15:17:00 CET] <iive> jdarnley: btw, have you tried all options in --help , something might work. [15:19:23 CET] <Chloe> atomnuker: https://0x0.st/sX_y.patch passes fate, may not be insane code [15:21:54 CET] <cone-460> ffmpeg 03Karthick J 07master:deceb7d9aeb7: avformat/hlsenc: Call avio_flush during persistent http connections [15:21:55 CET] <cone-460> ffmpeg 03Karthick J 07master:6ae18228cd89: avformat/hlsenc: Handle NULL input in IO open and close utility functions [15:21:56 CET] <cone-460> ffmpeg 03Karthick J 07master:b2d27d912ba9: avformat/hlsenc: Extend persistent http connections to playlists [15:22:03 CET] <Chloe> Will post to ML if you think there's nothing really obvious I've missed [15:31:10 CET] <atomnuker> oh wow, do post to the ml then [15:31:53 CET] <JEEB> do we have a thing like the oracle FATE system which libav has? [15:32:02 CET] <JEEB> so that patches can be tested on the FATE machines before landing [15:36:03 CET] <BtbN> I could setup the github mirror to do that with pull requests. [15:36:15 CET] <BtbN> But that would be horribly confusing, as we still won't accept PRs [15:37:00 CET] <BtbN> and it would only test on x86_64 linux [15:37:03 CET] <BtbN> and maybe osx [15:37:52 CET] <nevcairiel> Chloe: our compat wrappers dont define _Atomic, and the cast may not be safe [15:37:55 CET] <JEEB> yea, in this case mingw-w64 and MSVC would be the most likely things to break anyways [15:38:38 CET] <BtbN> I mean, it could cross-compile to windows. But not run tests. [15:39:11 CET] <BtbN> https://oracle.libav.org/ looks rather dead anyway? [15:41:30 CET] <Chloe> nevcairiel: ok I'll look into that [15:41:57 CET] <Chloe> I've only tested on macOS so far [15:45:58 CET] <JEEB> BtbN: yea but I think they push stuff to it manually anyways [15:46:12 CET] <JEEB> while automated building of patches would be cool, I don't think that's going to happen [15:46:37 CET] <atomnuker> they'd spam the ml [15:46:49 CET] <JEEB> so at this point it would be nice to have a thing where someone could push patches manually at request [15:46:56 CET] <JEEB> like this atomic change [15:47:29 CET] <BtbN> and make it run on the whole fate infra? [15:49:24 CET] <Chloe> running this patch on the whole fate infra before it's pushed would probably be a good odea [15:52:05 CET] <BtbN> we'd need an ffmpeg-oracle.git somewhere for that as well. And someone to hook it up to the fate infra [16:02:28 CET] <JEEB> yea [16:03:06 CET] <JEEB> so for now getting manual requests on from MSVC and mingw-w64 FATE'rs [16:03:19 CET] <JEEB> and then linux at the very least [16:05:00 CET] <wbs> JEEB: BtbN: the thing with fate-oracle is that you need to duplicate all the setup in all the fate clients as well; libav's oracle doesn't contain all the same instances as in the regular fate, only the ones that have been set up [16:05:18 CET] <wbs> so for cronjobs/runloops/whatever, you need to have it first run jobs from normal fate then run jobs from oracle, etc [16:05:37 CET] <JEEB> yup [16:05:49 CET] <wbs> for my arm tests (which take many hours to run), I've only added the most relevant setups to it [16:16:23 CET] <atomnuker> there's no way to disable arbitrary hwaccels/bsfs, right? [16:18:30 CET] <jkqxz> Yes? --disable-hwaccel=foo --disable-bsf=bar [16:21:30 CET] <atomnuker> oh, great, print_enabled_components handles disabled ones [17:48:08 CET] <Chloe> atomnuker: oh, I had a question. At the end of my test you see I just empty the atomics test, how can I remove that file completely? (cant see where it's being compiled from) [17:48:26 CET] <atomnuker> what do you mean? [17:50:33 CET] <Chloe> I think I'm being silly. Are all the files in libavutil/tests just compiled based off their filenames? [17:50:45 CET] <Chloe> I may have not reconfigured when I tried to remove libavutil/tests/atomic.c [17:59:59 CET] <jdarnley> You might need to run `make distclean` to get rid of the .d files too [18:00:28 CET] <jdarnley> but all things to build should be listed in a makefile, usually in the directory next to them. [18:06:11 CET] <cone-460> ffmpeg 03Jun Zhao 07master:d228d52f1cc9: lavc/vp8: Support resolution changes in the VP8 decoder hwaccel [18:06:12 CET] <cone-460> ffmpeg 03Mark Thompson 07master:07e1bd7e2d7b: doc/libav-merge: Remove VAAPI VP8 decode hwaccel merge note [18:40:34 CET] <cone-460> ffmpeg 03James Almer 07master:5450972be4a7: doc/libav-merge: remove line about VP9 superframe parsing [20:10:04 CET] <Chloe> wm4: any idea how you'd make this work on windows? [20:14:00 CET] <wm4> either some macro magic (don't know if this is possible?), or extra typedefs for each stdatomic wrapper (including standard stdatomic) for the argument type [20:16:20 CET] <jamrial> i thought anyway that casting wasn't an option [20:18:37 CET] <wm4> and I assume MSVC doesn't do GNU extensions like typeof or ({ ... }) [20:19:43 CET] <Chloe> I mean _Atomic can just be macro'd out [20:20:21 CET] <Chloe> then it'll throw a warning for void ** -> intptr_t* but I dont see why it wouldnt work? [20:21:45 CET] <wm4> oh right, this is for cases where the type is a pointer [20:22:01 CET] <wm4> so even though it's a strict aliasing violation it could work [20:22:53 CET] <Chloe> there's only 4 instances of it using cas and it's always a pointer [20:23:44 CET] <Chloe> Gonna try setup a windows compile env and test it out [20:24:07 CET] <nevcairiel> if anything _Atomic should probably be volatile [20:24:18 CET] <nevcairiel> not just empty [20:24:28 CET] <nevcairiel> but its hard to test if its really thread safe then [20:24:58 CET] <Chloe> I read that volitile is bad when using atomics [20:25:40 CET] <Chloe> keep in mind, I don't actually know much (or anything) about this (threading), I just wrote something that works and passes tests [20:25:45 CET] <Chloe> volatile* [20:26:36 CET] <JEEB> ok, so if I have an audio format that has a WAV format that has no header and instead just gets the stuff from the WAV header, and then a packet format which contains a header in each packet noting the specifics - how do I deal with this if the decoder in lavc currently just expects the stuff to be in the AVCodecContext already? what is the usual way of switching these sorts of packaging types that you [20:26:42 CET] <JEEB> can flag from the demuxer? [20:27:38 CET] <JEEB> because I need a if (thing) { // handle header } [20:27:42 CET] <JEEB> in the decoder [20:28:39 CET] <JEEB> and during init I need to know that I shouldn't complain even if various values aren't already set [20:32:22 CET] <Chloe> nevcairiel: mingw is just gcc right? so if it works on linux with gcc it should just work when cross-compiled with mingw [20:32:35 CET] <Chloe> i.e. MSVC would be the issue, not mingw [20:33:59 CET] <Chloe> I can't get MSVC (I don't have enough storage space on my windows computer). That is a problem with testing it [20:34:41 CET] <nevcairiel> yeah mingw is just gcc [20:34:42 CET] <BtbN> setup a git repo and use appveyor [21:09:19 CET] <BtbN> michaelni, do you have some unusual umask set or how does that happen? For me the permissions are fine. [21:09:57 CET] <SortaCore> Chloe: I have MSVC on windoze if you need some testing done [21:11:02 CET] <Chloe> SortaCore: my atomics patch on the mailing list, I want to know how much it breaks with MSVC [21:11:46 CET] <SortaCore> I'm not on ML, I have the empty-inbox character trait >.< [21:15:27 CET] <jkqxz> SortaCore: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171215/d22a2d77/atta…> [21:15:30 CET] <michaelni> BtbN, iam not sure its unusual but it of course limits access to what is needed [21:16:49 CET] <SortaCore> ok, newb, how do I apply it? [21:18:58 CET] <jdarnley> wget, maybe dos2unix, git apply [21:21:17 CET] <SortaCore> just git apply attachment.ksh? [21:21:51 CET] <SortaCore> and no requirements on configure to test it? [21:21:56 CET] <jkqxz> git am [21:22:13 CET] <jkqxz> It's a whole git patch, not just a diff. [21:23:37 CET] <BtbN> michaelni, https://gist.github.com/1cc793c0aedb1eb9a5905ec77ab14e5f does this one work better? [21:24:09 CET] <SortaCore> patch format detection failed [21:25:43 CET] <SortaCore> it's in unix format [21:28:55 CET] <michaelni> BtbN, this fixes the permissions, yes [21:29:32 CET] <BtbN> it seems a bit odd that install does not have an option to create the path on demand [23:31:12 CET] <SortaCore_> would you get patch format detection failed if you had modified your working copy? [23:31:34 CET] <JEEB> depends on if the file was related [23:32:00 CET] <SortaCore> that is a counter-intuitive error then [23:32:13 CET] <JEEB> oh wait no [23:32:21 CET] <JEEB> that does mean that the patch lacks something or is incorrect [23:32:42 CET] <JEEB> what most often happens is that when you copy-paste a patch you lack the last line or something [23:32:43 CET] <SortaCore> and it wouldn't be incorrect if you modified the line it was trying to replace? [23:32:55 CET] <SortaCore> e.g. the from line [23:33:28 CET] <JEEB> if the editing didn't touch anything else (such as save with CRLF or whatever) then no [23:33:40 CET] <JEEB> or if it didn't clean up the last \n [23:34:48 CET] <SortaCore> hm, and by editing, I mean editing the source file itself, not the patch [23:35:19 CET] <JEEB> ok [23:35:33 CET] <JEEB> then the patch is derp'd [23:35:48 CET] <JEEB> if it's on patchwork I just curl and push it straight into git am [23:36:03 CET] <JEEB> curl "URL" | git am [23:36:16 CET] <JEEB> curl outputs to standard output, git am takes stuff in [23:36:56 CET] <JEEB> the "download mbox" url in patchwork, https://patchwork.ffmpeg.org/patch/6795/ for example [23:36:58 CET] <SortaCore> oddly, that worked [23:37:07 CET] <SortaCore> curl | am [23:37:12 CET] <JEEB> yup [23:37:18 CET] <JEEB> little change of anything poking it the wrong way [23:37:31 CET] <JEEB> *chance [23:37:45 CET] <SortaCore> weird, I had used wget and tried both dos and unix line endings [23:38:07 CET] <SortaCore> Chloe: I've done your patch [23:38:20 CET] <SortaCore> running my usual configure [23:39:07 CET] <Chloe> SortaCore: right, does it compile? [23:39:16 CET] <Chloe> I assume it wont find stdatomic [23:44:05 CET] <SortaCore> still configuring :p [23:54:06 CET] <SortaCore> why doesn't make use multiprocessor by default? [23:56:50 CET] <iive> SortaCore: last time I checked it had an option to run all jobs in parallel, even if they are few thousands... [23:57:56 CET] <wm4> configure doesn't use make [23:58:05 CET] <wm4> so that wouldn't help [23:58:56 CET] <iive> or an option to spawn jobs until the cpu is not maxed out [00:00:00 CET] --- Sat Dec 16 2017

1 0

ffmpeg.log.20171215
by burek 16 Dec '17

16 Dec '17

[00:02:04 CET] <JEEB> pretty sure you'll want to limit your support first [00:02:10 CET] <JEEB> since there's a lot of really limited stuff there [00:02:31 CET] <JEEB> and IIRC there's a by_name getter for them [00:02:43 CET] <JEEB> (and the names of things rarely change) [00:02:57 CET] <JEEB> so I think you'll want to have a list of the ones you actually support [00:03:26 CET] <alexpigment> jkqxz: to work around AMF issue in Windows Media Player, you can specify '-flags loop' in the ffmpeg command (until the driver issue is fixed next month). not sure why it works, and I know you probably don't personally have any reason to use it, but I figured I'd let you know [00:08:55 CET] <alexpigment> roughly how much of a speed boost would you see from disabling the deblock filter on x264? [00:09:11 CET] <alexpigment> i can test this, but I figured I'd quickly ask in case it was common knowledge [00:09:56 CET] <alexpigment> ok, i'll go test ;) [00:10:06 CET] <JEEB> speed boost for what? [00:10:09 CET] <JEEB> encoding or decoding? [00:10:23 CET] <durandal_170> not much, also are your pc from prev century.? [00:10:44 CET] <JEEB> yea, the last time I used -tune fastdecode was for my xbox :) [00:10:48 CET] <JEEB> with xbmc [00:10:58 CET] <JEEB> 733MHz custom celeron chip \o/ [00:11:19 CET] <alexpigment> encoding [00:11:37 CET] <JEEB> nope :) usually that is done together with the presets in general [00:12:23 CET] <JEEB> ok, the last preset benchmark I saw hadn't even considered the faster-than-medium presets :) [00:12:26 CET] <JEEB> so never mind [00:12:43 CET] <alexpigment> ok, running some tests now [00:17:45 CET] <alexpigment> ok, the answer was not a noticeable amount [00:17:52 CET] <alexpigment> maybe that has to do with other settings [00:18:14 CET] <alexpigment> but I just had a moment where I realized I was encoding from non-lossy sources and it was probably applying an unnecessary deblock [00:18:22 CET] <JEEB> yea I didn't expect it to be too time-consuming :P [00:18:23 CET] <JEEB> uhh [00:18:25 CET] <JEEB> lol [00:18:35 CET] <JEEB> alexpigment: did you forget the deblock is post-encode [00:18:42 CET] <JEEB> it's the thing that makes shit look better [00:19:02 CET] <alexpigment> oh, it's decode only? [00:19:19 CET] <alexpigment> i was reading some article that i must have misread [00:19:19 CET] <JEEB> not really, the encoder has to utilize it as well, but it mostly takes time on decoding side IIRC [00:19:22 CET] <alexpigment> and it was showing screenshots [00:19:43 CET] <JEEB> of course x264 has to do the reconstruction itself as well [00:19:44 CET] <alexpigment> anyway, i was like "wait. why would I ever want deblock when the source isn't lossy?" [00:20:08 CET] <JEEB> because you most likely end up with compression artifacts which that stuff is great at hiding [00:20:24 CET] <JEEB> in-loop deblocking is one of those things that came up in H.263 and for some godawful reason didn't en up in MPEG-4 Part 2 [00:20:41 CET] <JEEB> and thus the difference from MPEG-4 Part 2 to AVC/H.264 was even bigger :D [00:20:52 CET] <JEEB> so you had suddenly CABAC, in-loop deblocking etc [00:20:54 CET] <alexpigment> ah [00:21:15 CET] <alexpigment> i always was confused between h.263 and mpeg-4 part 2 [00:21:19 CET] <alexpigment> in my head, they're the same thing [00:21:25 CET] <alexpigment> but i know they're not exactly the same [00:21:31 CET] <JEEB> they're related but MPEG-4 Part 2 removed some things and added others [00:21:49 CET] <alexpigment> like i consider divx mpeg-4 part 2, but maybe that's closer to h.263? [00:21:52 CET] <alexpigment> i don't even know [00:22:03 CET] <JEEB> divx was an mpeg-4 part 2 implementation [00:22:06 CET] <JEEB> xvid as well [00:22:16 CET] <JEEB> even the hacked up divx ;-) [00:22:24 CET] <JEEB> which based on MS's MPEG-4 Part 2 encoder [00:22:33 CET] <JEEB> (IIRC) [00:22:38 CET] <alexpigment> ok, i guess the point of confusion is that an h.264 part 2 decoder will decode h.263 [00:23:08 CET] <JEEB> no? also mpeg-4 part 2 never got ratified over at ITU-T [00:23:09 CET] <alexpigment> i've never even tried ms mp4. i don't know what it does, and I never had a need to try it [00:23:10 CET] <JEEB> unsurprisingly [00:23:18 CET] <JEEB> well, at this point there's no reason [00:23:25 CET] <JEEB> this was early 2000s yo [00:23:36 CET] <alexpigment> from the h.263 wiki: "MPEG-4 Part 2 is H.263 compatible in the sense that basic "baseline" H.263 bitstreams are correctly decoded by an MPEG-4 Video decoder.[8][11]" [00:23:46 CET] <JEEB> ah yes, that maybe [00:23:49 CET] <alexpigment> so i guess baseline is the operative word [00:23:54 CET] <JEEB> if it lacked the in-loop deblocking etc [00:24:03 CET] <alexpigment> most likely [00:24:12 CET] <alexpigment> baseline anything lacks most of what makes the codec good ;) [00:25:39 CET] <alexpigment> alright. enough learning today. time to go home and drink beer [00:50:47 CET] <bilb_ono> is there a good way to analyze movement in a video? I want to look at a video and any time there is movement, create a clip of the movement [00:51:08 CET] <bilb_ono> so when movement is happeneing, I want to detect it [01:26:18 CET] <therage3> bilb_ono: try this, this is someone asking how to do what you said with an IP camera feed https://superuser.com/questions/984841/ffmpeg-remove-parts-without-motion [01:26:40 CET] <therage3> bilb_ono: the proposal is to use the select filter to compare similarity of two consecutive frames [01:42:20 CET] <SortaCore> bilb_ono: that would involve a difference filter and edge filter [01:42:27 CET] <SortaCore> and then some... [01:48:07 CET] <furq> bilb_ono: maybe mpdecimate [01:48:10 CET] <furq> !filter mpdecimate [01:48:10 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#mpdecimate [01:48:41 CET] <furq> overlay a timestamp, set max to 0 and then you'll only get frames that differ from the previous frame [01:49:09 CET] <furq> overlay a timestamp so that you can remux to cfr [01:49:27 CET] <furq> that's not exactly what you asked for but afaik it's as close as ffmpeg will get you [01:50:01 CET] <furq> also if you have a noisy source or a low-quality feed then you're going to have a real hard time with this in general [01:51:29 CET] <therage3> yeah, the compression artifacts are bound to throw off the filters [02:22:58 CET] <bilb_ono> Ideally I could get some number for each new frame showing how much it differs from the previous frame [02:23:24 CET] <bilb_ono> then I could choose like less than 10 and its basically static [02:23:24 CET] <bilb_ono> some threshold [02:30:38 CET] <SortaCore> my current motion detection is homebrew [02:31:10 CET] <SortaCore> I just convert a frame to greyscale, and do a "difference exceeds number" for all pixels, then check if num diff is above another number [02:39:08 CET] <bilb_ono> SortaCore: hmm that seems pretty good [03:51:31 CET] <SortaCore> is there a way to initialise a AVFrame from a AVStream? [03:52:23 CET] <SortaCore> I'm having to set width, height, pixel format, color range, color primaries... [04:57:04 CET] <kriskropd> hi - you know how Audacity has a "Change Tempo" effect where you set the current bpm and tell it which bpm you want it to change into? [04:57:15 CET] <kriskropd> can ffmpeg do something like that with the same sort of input? [04:57:40 CET] <kriskropd> or some other scriptable tool like sox even? [04:58:21 CET] <kriskropd> premise: tons of music loops and samples I want to change the tempo of, but too lazy to open each in audacity individually and then export with a new name manually [04:58:55 CET] <kriskropd> and though each has the bpm in their filename, they are not all the same, so I can't just pitch up by .1 and call it a day [05:00:41 CET] <kriskropd> ah - maybe ill just use a chain in audacity to batch process and hand pick files afterall :/ [05:01:02 CET] <kriskropd> was looking forward to an excuse to use some bash parameters - but alas the wheels need not be reinvented I guess [06:12:47 CET] <SortaCore> kriskropd: isn't tempo just sample rate? [06:34:23 CET] <WireCat> sortacore did you figure out how to tell if its a video stream? [06:34:37 CET] <SortaCore> yea, you use codec->type [06:34:58 CET] <WireCat> thankyou :-) [10:25:36 CET] <Zucca> Hi. I've been using the zlib video codec for quite a many things in the past. It's very fast and scales well on many CPU cores. It's especially good raw compressor on some game videos. Not that facebook has developed zstd, _could_ it be used to create similar video codec with even less overhead and better compression? [10:26:41 CET] <JEEB> there are already nice well compressing video formats that are quite optimized [10:26:48 CET] <JEEB> like libx264's lossless mode [10:27:07 CET] <JEEB> ffv1 is being standardized with the EU for archival [10:27:31 CET] <Zucca> JEEB: But in my experience that way slower. Only utvideo is somewhat comparable to the zlib video codec. [10:27:36 CET] <JEEB> and less on the compression rate of things, but Ut Video is great for when you need to open the file in a video editor because there's modules for all OSs [10:27:43 CET] <JEEB> Zucca: did you actually set preset? [10:27:56 CET] <JEEB> of course zlib and ut video are very very simple [10:28:20 CET] <JEEB> so they (well optimized) probably are faster, but libx264 is /very/ well optimized [10:28:36 CET] <JEEB> it is of course more complex than zlib/ut video :P [10:28:46 CET] <JEEB> but that's the usual thing [10:29:16 CET] <JEEB> if you end up wanting something more complex you will pay with processing (although if you have optimizations then even a less complex format can end up slower) [10:31:04 CET] <Zucca> If my GPU had hw encoding of h.264... The it might be feasible. But most of the time h.264 is too slow. Also when compressing retro game videos, zlib beats every other codec. :P I've been quite impressed how well it fares against ffv1 for example. [10:31:46 CET] <furq> what about qtrle [10:31:55 CET] <Zucca> Anyway. I'm not currently searching for another codec. Although I'll give libx264 a second try at lossless. [10:31:58 CET] <JEEB> what sort of machine is this and did you poke the presets? [10:32:34 CET] <Zucca> I just wonder if zstd could be used to create better zlib -like codec. [10:33:22 CET] <Zucca> JEEB: Last time I tried... it was propably more than year ago. I cannot recall what settings I did try. [10:33:49 CET] <JEEB> in theory yes but I wouldn't be surprised that if you *just* wanted to compress there are better algos for that which are not compatible with zlib :P [10:34:21 CET] <JEEB> the web people are staying in zlib-compatible realm because they need to support browsers for the data decompression [10:34:50 CET] <Zucca> I see. [10:36:45 CET] <JEEB> and most of all, there are actually better video compression techniques than "just feed it to compressor X after giving it some basic 'prediction'" [10:37:19 CET] <JEEB> and given that we're at the point where you get >10fps from x264's preset placebo on some machines... :D [10:37:37 CET] <Zucca> I'll try out the lossless mode of libx264 next time when I'm in process of making video dumps. [10:37:54 CET] <Zucca> What? >10 fps on placebo? [10:37:58 CET] <JEEB> yes [10:38:04 CET] <Zucca> At what resolution and fps? [10:38:11 CET] <Zucca> Oh. Forget fps. [10:38:12 CET] <JEEB> the fps doesn't matter does it :) [10:38:16 CET] <JEEB> 1080p I think [10:38:18 CET] <JEEB> 4:2:0 YCbCr [10:38:31 CET] <Zucca> Damn... CPU only? [10:38:35 CET] <JEEB> as someone who was using x264 in 2006 those numbers make me smile [10:38:51 CET] <JEEB> yes, of course [10:39:13 CET] <JEEB> the opencl stuff in x264 is very limited anyways (it has to be since it has to be able to run completely separate from the main encoding part) [10:39:39 CET] <Zucca> Ah. Yeah. O mixed x264 with vpx. [10:39:45 CET] <Zucca> *I [10:39:57 CET] <JEEB> vpx got much less love poured into it [10:40:05 CET] <JEEB> it was GOOG's toy [10:40:32 CET] <Zucca> Newer GPUs support hw encoding of VP9. [10:40:48 CET] <JEEB> maybe, but that's ASIC-based [10:40:54 CET] <JEEB> all video encoding on those boards is ASIC based [10:40:56 CET] <Zucca> Yup. [10:40:56 CET] <JEEB> not GPGPU [10:41:28 CET] <JEEB> also x264 and vpx are specifically the SW implementations of AVC/H.264 and VPx formats [10:41:32 CET] <Zucca> I believe there's not much of room in adjustments. [10:41:33 CET] <JEEB> so those ASICs are unrelated [10:41:39 CET] <furq> huh [10:41:42 CET] <furq> is there really no mng decoder [10:41:56 CET] <JEEB> possibly, no idea [10:42:04 CET] <furq> it just decodes the first frame [10:42:15 CET] <JEEB> which was PNG-compatible, right? [10:42:19 CET] <furq> yeah [10:42:39 CET] <Zucca> JEEB: Does ffmpeg currently support GPU asic encoding (of any sort)? [10:42:44 CET] <JEEB> yea you only have apng and png_pipe [10:42:46 CET] <JEEB> Zucca: yes [10:42:47 CET] <furq> i figured i would test zlib with "retro game video" and mame spits out mng [10:43:01 CET] <furq> i guess i have to convert it to apng or something [10:43:04 CET] <furq> or i could just not bother [10:43:37 CET] <JEEB> Zucca: I think only nvidia that I know of currently supports lossless video with their ASICs [10:43:45 CET] <JEEB> for encoding [10:43:58 CET] <JEEB> otherwise it's all lossy [10:44:04 CET] <Zucca> furq: Mame can output raw video. I'm not sure if you could just fifo it into ffmpeg and compress with zlib.... [10:44:39 CET] <furq> yeah but i already have some mngs [10:47:10 CET] <Zucca> JEEB: Lossless would be nice, but I wouldn't mind about some higher quality lossy either. Although x264 with some fast preset is quite fast anyways. [10:51:21 CET] <JEEB> yea, the ASICs are generally meant for realtime or so anyways [10:53:04 CET] <furq> x264 4:4:4 at medium is twice as fast and a third the size of zlib [10:53:18 CET] <furq> maybe x264 is just well optimised for real bout 2 [11:11:46 CET] <Nacht> There isn't a way to let ffmpeg make folders, right ? [11:12:46 CET] <JEEB> some muxers have that, but in general the API client should handle stuff like that [11:13:09 CET] <JEEB> and the stuff that has that is usually stuff like HLS which is a meta-muxer anyways :P [11:14:08 CET] <Nacht> Hmm. Segment doesn't seem to have it :/ [11:14:25 CET] <JEEB> not surprising [11:16:08 CET] <termos> I have a loop over all my filter graphs (10-15) where I call av_buffersrc_add_frame_flags for each 1080P decoded frame. The problem is that this causes a bottleneck in my software as too much time is spent copying out that frame into each filter graph. Is there a way around this? [11:17:32 CET] <termos> something I can do with the AV_BUFFERSRC_FLAG_KEEP_REF flag? [11:17:35 CET] <JEEB> in theory with refcounted frames the source frame could be passed the same, but then of course the filter wouldn't be able to do in-place filtering [11:17:48 CET] <JEEB> unfortunately I haven't looked into lavfi enough [11:21:42 CET] <termos> ah I see [11:22:14 CET] <termos> only way out I see now it do a proxy transcoding (maybe just scaling) into lower resolutions and push this to the lower resolution filter graphs [14:56:34 CET] <rodrigo-vitulli> Hi, [14:56:35 CET] <rodrigo-vitulli> I'm using ffmpeg to create 1 minutes mp4 segments, but the problem is I can never assure the segment lenght. Sometimes it has 1 minute + 2 seconds, sometimes 56 seconds. I understand that this may be releated to how ffmpeg use keyframes to properly create segments, but this is causing me timestamp disarrange inside my application. My question is: is it possible to force ffmpeg to stick to exactly 1 minute segments? I'm using the folliwng [14:56:35 CET] <rodrigo-vitulli> command: ffmpeg -i #playlist_url# -force_key_frames 60 -vf scale=1280:720 -b:v 1000 -b:a 128 -f segment -segment_time 60 -segment_atclocktime 1 -reset_timestamps 1 -strftime 1 %Y-%m-%dT%H:%M:00%z.mp4 [14:56:35 CET] <rodrigo-vitulli> Thanks [16:10:41 CET] <alexp> rodrigo-vituli: i'm not sure if this wil help, but perhaps try -g 60 as well [16:11:39 CET] <d9867eb> hi [16:13:35 CET] <d9867eb> i have some video files and I want to store them in a open free format such as theora. however theora is the outdated. what is the best codec for me? [16:13:48 CET] <Fyr> VP9? [16:16:02 CET] <d9867eb> how is the vp9 license? is it permissive? [16:16:18 CET] <d9867eb> Fyr: [16:16:34 CET] <JEEB> software licenses and patent stuff are two completely separate things [16:17:06 CET] <JEEB> you can have something very permissive in software licenses yet (depending on your legal location etc) you can be fscked with the patent situation on it [16:17:16 CET] <Fyr> >> Parts of the format are covered by patents held by Google. The company grants free usage of its own related patents based on reciprocity, i.e. as long as the user does not engage in patent litigations. [16:17:44 CET] <alexpigment> Fyr: what about the other parts? ;) [16:17:51 CET] <JEEB> yes, they also have a patent grant for their stuff in there of course by GOOG [16:18:03 CET] <JEEB> but what you'd care about are non-GOOG things anyways. if you care about it [16:18:15 CET] <JEEB> IANAL but please just *always* remember to keep these two issues separate [16:18:19 CET] <alexpigment> basically any number of entities can come in and say the codec violates patents (and they usually will try at some point) [16:18:44 CET] <JEEB> software licensing is one thing, the mess that is software patents and if it touches *you* is a separate and more messy thing [16:19:05 CET] <alexpigment> you can at least rest safely that google has infinite cash and will probably step in and pay off whoever tries to litigate on their patents [16:19:11 CET] <alexpigment> semi-safely at least [16:19:45 CET] <JEEB> well if you cared about sw patents you wouldn't be caring about the GOOG patents [16:20:00 CET] <JEEB> the things that other places have which are not using libvpx or related things [16:20:13 CET] <alexpigment> that's true [16:20:17 CET] <JEEB> anyways, libvpx is a relatively permissively licensed thing (you can read it license in their repo and FAQs most likely) [16:20:34 CET] <JEEB> and it seems like most places see libvpx as OK to distribute [16:20:37 CET] <JEEB> IANAL though [16:20:52 CET] <alexpigment> but JEEB, aren't you actually a lawyer though? [16:20:57 CET] <alexpigment> :) [16:20:58 CET] <JEEB> fuck no [16:21:04 CET] <d9867eb> so should i libvpx instead of libtheora? how about vc2 [16:21:06 CET] <JEEB> I don't make enough money to be one [16:21:06 CET] <alexpigment> JEEB is a closet lawyer [16:21:07 CET] <d9867eb> ? [16:21:13 CET] <alexpigment> he's a shill for Big Patent [16:21:40 CET] <JEEB> no, all I'm saying is that whether or not you care about sw patents is unrelated to software licensing [16:21:43 CET] <alexpigment> d9867eb: if you have to choose bewteen vp9 and theora, go with vp9 [16:22:06 CET] <JEEB> and that I am not a lawyer who is recommend something to someone [16:22:07 CET] <alexpigment> <-- also not a lawyer [16:22:30 CET] <JEEB> all I can say that entities that tend to be really careful with sw patents distribute libvpx (mozilla, red hat) [16:23:13 CET] <alexpigment> yeah, mozilla has had to also pay out the ass before, which is hard since they don't have millions of other revenue streams [16:23:16 CET] <JEEB> so the de facto thing seems to be that it is perceived as "safe to use", while there of course is no way to really be assured of that unless you do comprehensive IPR [16:23:26 CET] <alexpigment> which is why they dropped native H.264 support [16:23:27 CET] <d9867eb> alexpigment: i had just like a open format. if there are only vp9, vc2 and theora then i have go with someone of them [16:23:37 CET] <JEEB> VC-2 is not for your use case anyways [16:23:48 CET] <alexpigment> d9867eb: vp9 [16:23:55 CET] <JEEB> it's a high bit rate thing utilized instead of raw video over networks [16:24:08 CET] <alexpigment> (assuming you are re-encoding existing files, which I don't really recommend in the first place) [16:24:09 CET] <JEEB> for stuff like broadcast thingamajigs [16:24:22 CET] <JEEB> (internal video transfer etc) [16:24:34 CET] <d9867eb> ok [16:24:35 CET] <JEEB> although I've only seen BBC and open broadcast systems use it [16:25:43 CET] <d9867eb> also, let say i have ac3 audio in the source file. should i use flac or libopus in the output file? [16:26:00 CET] <alexpigment> opus probably, unless you want completely lossless [16:26:10 CET] <JEEB> why would you not just copy the audio over? [16:26:13 CET] <alexpigment> or again, just keep the ac3 [16:26:14 CET] <JEEB> it's already lossy [16:26:22 CET] <d9867eb> ok [16:26:26 CET] <JEEB> or what's the thing? [16:26:38 CET] <alexpigment> ac3 patents have run out anyway, if that matters to you [16:26:46 CET] <JEEB> yea, that's true [16:26:58 CET] <JEEB> which is why two or so years ago Dolby made up AC-4 [16:27:01 CET] <JEEB> for more patent moneys [16:27:03 CET] <alexpigment> :) [16:27:12 CET] <alexpigment> yeah, dolby lives off of licensing [16:27:16 CET] <alexpigment> they gotta keep doing something [16:27:38 CET] <alexpigment> i wonder if they paid adobe to drop AC3 from creative cloud [16:28:05 CET] <alexpigment> there's something to that story - i don't know why adobe would drop ac3 this year - after the patents ran out [16:28:09 CET] <JEEB> and they're not DTS. DTS will basically yell at you over the phone if you ask about specs for putting DTS into, say, MP4 [16:28:45 CET] <JEEB> not even decoding it, lol [16:28:52 CET] <d9867eb> isnt the ac3 codec closed source? [16:29:03 CET] <alexpigment> yes [16:29:05 CET] <JEEB> it's a standard (A/52) [16:29:08 CET] <alexpigment> but open source encoders exist [16:29:12 CET] <alexpigment> and patents have run out [16:29:27 CET] <JEEB> yes, you have both open source decoders and encoders, and as far as I know the spec is open [16:29:37 CET] <alexpigment> i'll trust JEEB [16:29:37 CET] <d9867eb> i had like only open codecs for my videos [16:29:44 CET] <JEEB> so it's not proprietary [16:29:58 CET] <JEEB> https://www.atsc.org/standard/a522012-digital-audio-compression-ac-3-e-ac-3… [16:30:48 CET] <JEEB> d9867eb: I think you're rather confused about things :P [16:30:49 CET] <alexpigment> d9867eb: out of curiosity, are you trying to take lossy videos (e.g. MP4 and MKV files) and transcode them to something open source, just because you prefer open source? [16:31:13 CET] <d9867eb> alexpigmet: yes! [16:31:17 CET] <JEEB> if something is standard, as in with a proper specification, that most likely has an open source decoder or encoder [16:31:18 CET] <alexpigment> d9867eb: don't do it [16:31:23 CET] <d9867eb> why? [16:31:31 CET] <alexpigment> because it's a waste of time, and you're going to lose quality [16:31:37 CET] <JEEB> then *separately* you have the "patent free" (in quotes) stuff [16:31:45 CET] <JEEB> which is what you care about? [16:31:55 CET] <JEEB> is it just having *standardized* stuff [16:32:05 CET] <JEEB> or is it "patent free" (in quotes)? [16:33:30 CET] <JEEB> if it's just "has to have open source decoder/encoder", then that's of course even more wide :P but generally I would limit stuff with an actual specification [16:34:28 CET] <d9867eb> i care about the license of the original decoder/encoder [16:34:44 CET] <alexpigment> d9867eb: well if you care more about that than your time and quality, go ahead [16:34:49 CET] <JEEB> "original" doesn't really make sense [16:35:05 CET] <JEEB> for example you have the AVC/H.264 or HEVC/H.265 formats. [16:35:09 CET] <JEEB> they do have reference implementations [16:35:15 CET] <JEEB> is that the "original" you care about? [16:35:39 CET] <JEEB> (note: absolutely no-one uses the reference ones because they're just that - references) [16:36:22 CET] <JEEB> and what do you care what something is encoded with as long as it's according to a specification and thus you can decode it with open source means? and if we speak about open standardized formats you most likely have an open source encoder for that format, too [16:36:31 CET] <JEEB> but anyways, you have much tighter control on what you *encode* [16:36:46 CET] <alexpigment> d9867eb: what JEEB is trying to get at, for example, is that H.264 has an open source encoder (x264), but it is subject to payments on the patents (to MPEG-LA) [16:37:04 CET] <JEEB> alexpigment: even before that darn it. the question I posed was relatively simple [16:37:25 CET] <alexpigment> sorry, I was trying to break it down from the abstract to the specific [16:38:14 CET] <alexpigment> anyway, I really just don't see the point in all this. people don't care enough about quality to not re-encode an already lossy source. I feel like I'm so ideologically opposed to this that I'll just be quiet :) [16:38:18 CET] <d9867eb> alexpigment: the libx264 encoder is not offical encoder iirc [16:38:28 CET] <alexpigment> there is no official encoder [16:38:28 CET] <JEEB> there is no "official" encoder for AVC/H.264 [16:38:31 CET] <JEEB> other than the reference [16:38:36 CET] <JEEB> they make a reference and the specification [16:39:22 CET] <JEEB> but sure, AVC/H.264 reference software is open source and available here http://iphome.hhi.de/suehring/tml/ [16:39:53 CET] <JEEB> specification is freely available @ http://www.itu.int/rec/T-REC-H.264-201704-I/en [16:40:15 CET] <JEEB> that's why I note that what you should be caring is if something is a standardized format or not [16:40:34 CET] <JEEB> things with specifications etc tend to have open source decoders which will continue to work [16:40:46 CET] <JEEB> and most likely an encoder, too [16:41:46 CET] <alexpigment> if i had to pick a format that I thought would be most likely still playable in 30 years, it would be H.264 [16:43:21 CET] <JEEB> d9867eb: so yea, go re-read my lines starting from the line that begins "if something is standard, as in with a proper specification" (like the following less than 10 lines from me) [16:43:31 CET] <JEEB> then think what do you care about [16:44:42 CET] <JEEB> there are people with beliefs who do not want anything that is considered "patent encumbered" (with a reason or not), and those end up with theora or libvpx for example. and then those that just care that things are standardized and with an open source implementation (thus most likely to work in the future, too) [16:45:24 CET] <JEEB> the first part wouldn't take AVC/H.264 even with GPL (x264) or MIT/BSD (openh264) [16:45:57 CET] <d9867eb> JEEB: i think I am going to keep my video files in x264 for a while [16:46:36 CET] <JEEB> the format's called either AVC or H.264 [16:46:39 CET] <JEEB> x264 is an encoder [16:46:46 CET] <d9867eb> i might migrate to libvpx + libopus in the future [16:46:49 CET] <d9867eb> ok [16:46:57 CET] <d9867eb> thank you [16:48:13 CET] <JEEB> heh, these confused types are not simple to have things explained [16:48:47 CET] <alexpigment> i knew from the get-go that he was just going to try to re-encode x264 [16:48:50 CET] <alexpigment> sorry [16:48:53 CET] <alexpigment> "x264" :) [16:49:08 CET] <JEEB> I was pretty sure he just had something with H.264 or MPEG-2 Video with AC3 [16:49:11 CET] <JEEB> yes [16:49:30 CET] <JEEB> thus I was trying to make him understand what he really wants or does he want anything? [16:49:56 CET] <alexpigment> now, granted: if he had MPEG-2 video from DVD and wanted to transcode, fine. some people just really get on the open source bandwagon and just take it too far [16:50:33 CET] <JEEB> I don't think this has much to do with open source but rather a misunderstanding of what the people with beliefs are requiring [16:50:38 CET] <Fyr> JEEB, I couldn't find comparison of libx264 and openh264. which one is better? [16:50:45 CET] <alexpigment> libx264 is usable [16:50:47 CET] <JEEB> openh264 is limited to baseline profile [16:50:59 CET] <JEEB> and it may be faster with ARM [16:51:00 CET] <Fyr> ok, thanks, it's enough. [16:51:15 CET] <storrgie> I'm trying to use ffmpeg to record audio from two interfaces on a windows machine. I'd like to mux this together into a single file that I can pull channels out of later... correct me if I'm wrong in thinking I can take two stereo inputs and mux them into a file with four channels? [16:51:15 CET] <JEEB> also you can dodge the license stuff by using a binary from cisco [16:51:19 CET] <JEEB> which is what Firefox does [16:51:35 CET] <storrgie> I'm capturing the mic like this: ffmpeg -f dshow -i audio="Microphone (Realtek Audio)" mic.wav, and the "stereo upmix" which is what they here, like this: ffmpeg -f dshow -i audio="Stereo Mix (Realtek Audio)" upmix.wav [16:51:38 CET] <JEEB> storrgie: you can just use an audio filter chain that remaps teh audio stuff [16:51:45 CET] <alexpigment> i thought firefox just gave up entirely and used the H.264 decoder that's included with the system [16:51:57 CET] <alexpigment> i didn't think they encoded anything [16:52:20 CET] <JEEB> alexpigment: they never had a proper integrated H.264 decoder. so your comment about "paying up" was weird. They added openh264 for the webrtc spec compliance, which they download from cisco [16:52:34 CET] <JEEB> also they have support for using MediaFoundation, gstreamer and FFmpeg [16:52:40 CET] <JEEB> for AVC/AAC decoding [16:53:03 CET] <JEEB> so basically if you have libavcodec.so available Firefox on lunix can use that [16:53:04 CET] <alexpigment> JEEB: so MPEG-LA had a license fee that had a cap of ~$5mil I believe [16:53:11 CET] <alexpigment> and all the browsers paid it [16:53:15 CET] <JEEB> 5 or 10 now, don't remember. and no. [16:53:19 CET] <alexpigment> but firefox couldn't swing it at some point [16:53:33 CET] <JEEB> I don't think Mozilla ever distributed a H.264 decoder [16:53:34 CET] <alexpigment> maybe I heard the details wrong... [16:53:56 CET] <JEEB> they "gave up" about it circa 2013 or so? and then implemented Media Foundation, gstreamer [16:54:05 CET] <JEEB> then in 2014 or 2015 they also implemented a libavcodec wrapper [16:54:24 CET] <rodrigo-vitulli> vituli [16:54:35 CET] Last message repeated 1 time(s). [16:54:35 CET] <JEEB> for WebRTC compliance they added openh264 which is used for the video conference stuff [16:54:47 CET] <JEEB> and openh264 is grabbed from cisco, as I noted [16:55:03 CET] <JEEB> since cisco is providing the binaries, and MPEG-LA only cares about binary distribution [16:55:18 CET] <rodrigo-vitulli> alexp: thanks! I've already tried that... [16:55:21 CET] <JEEB> (and cisco just like google has run into the distribution limit ages ago) [16:55:58 CET] <alexpigment> JEEB: k. I probably just misheard the details. thanks for the info [16:57:01 CET] <JEEB> it sounds like you misunderstood the openh264 thing where they're using cisco-provided binaries [16:57:18 CET] <JEEB> because cisco doesn't care as they already pay the maximum :D [16:58:05 CET] <alexpigment> i didn't know they did that. i knew cisco did openh264 and basically all the fees are paid by them. i just didn't know firefox used that for any reason [16:59:12 CET] <JEEB> yea, WebRTC specifies H.264 for video IIRC [16:59:14 CET] <JEEB> which is why it's used [17:01:15 CET] <Johnjay> see xkcd comic about specifications [17:01:41 CET] <storrgie> JEEB, sorry I'm getting a bit lost in all the audio filter documentation... would I want to just do a channelmap? [17:02:16 CET] <alexpigment> Johnjay: that's a good one :) [17:03:35 CET] <storrgie> JEEB, actually it looks like I'd want to do a channelsplit [17:03:53 CET] <JEEB> storrgie: you first need amerge I think https://trac.ffmpeg.org/wiki/AudioChannelManipulation [17:04:31 CET] <JEEB> since you have more than one input from which you want to create a single thing that then gets remapped [17:05:16 CET] <JEEB> just take a look at the examples on that page that have multiple inputs [17:06:45 CET] <storrgie> thanks! [17:07:09 CET] <alexpigment> are there audio formats that have multiple streams? [17:07:26 CET] <alexpigment> or do you have to use a container like MKV for that? [17:07:40 CET] <JEEB> yes, just use a proper container if you need multiple streams [17:08:03 CET] <alexpigment> it sounds like the best option is to have a 3 streams, 1 that is downmixed from the two streams, as well as the two original streams [17:08:30 CET] <alexpigment> rather than a "quad channel" stream that probably won't get downmixed properly on most players [17:08:45 CET] <JEEB> well I have no idea if he has 4.0 input or what [17:08:50 CET] <JEEB> he asked for 4.0 though [17:08:56 CET] <JEEB> and mapping the original tracks is simple anyways [17:09:06 CET] <JEEB> -map 0:a -map 1:a [17:09:09 CET] <alexpigment> sure, i'm just talking about playback [17:09:31 CET] <JEEB> well yea, it depends. something like mpv can handle 4.0 if it's proper 4.0. and if he actually needs mixing he can do that in the filter chain [17:09:37 CET] <JEEB> so far he asked for four channels [17:09:41 CET] <alexpigment> anyway, just figured i'd throw that option out there, because player downmixing from 4.0 to 2.0 or 5.1 is going to be a crapshoot [17:10:00 CET] <alexpigment> right, just trying to read between the lines over here [17:10:21 CET] <alexpigment> anyway storrgie: that's something to consider if the 4.0 thing doesn't work too well [17:10:36 CET] <JEEB> or he just wants a single WAV file for his audio editor [17:10:42 CET] <JEEB> instead of two [17:10:45 CET] <alexpigment> true [17:10:52 CET] <JEEB> so he doesn't actually just care about the actual layout of the channels [17:10:56 CET] <JEEB> E_NO_IDEA [17:10:56 CET] <storrgie> I guess I could just have separate files [17:11:02 CET] <storrgie> I really just wanted to ensure time alignment [17:11:12 CET] <JEEB> just use the filter chain then [17:11:48 CET] <alexpigment> if time alignment is the main concern here, then yeah, a 4.0 channel file is fine if your editor supports it [17:12:01 CET] <storrgie> I'd actually be using ffmpeg to split it later [17:12:10 CET] <alexpigment> yeah, completely fine then [17:12:10 CET] <storrgie> I just want to capture it all aligned [17:12:43 CET] <storrgie> so really I'm just wanting a four channel file to store as an archive, then if someone says "can you examine around this time" I can corroborate what was being said/heard [17:12:56 CET] <storrgie> its literally recording people playing a videogame, but we want to know the things they say based on stimulus [17:13:12 CET] <storrgie> trying to elicit their vocabulary in duress situations [17:13:14 CET] <alexpigment> sure [17:13:53 CET] <alexpigment> i just wanted to make sure you weren't trying to actively listen to 4.0 audio, but wanted the original streams just in case [17:14:02 CET] <storrgie> yeah [17:14:09 CET] <storrgie> so should I use something like mkv as my container? [17:14:11 CET] <alexpigment> because 4.0 audio has to be downmixed for 2.0 [17:14:21 CET] <storrgie> and just store two stereo tracks inside it? [17:14:51 CET] <alexpigment> try the 4.0 thing first [17:15:13 CET] <storrgie> I don't have a machine to try it on right now, I'm going to have to test this next monday. I was just updating my notes about it [17:15:14 CET] <alexpigment> if it *sounds bad* when playing it, then you can consider storing a file with 3 streams [17:15:28 CET] <storrgie> I think it would actually be better to store a file with multiple streams [17:15:34 CET] <storrgie> for simplicity sake [17:15:46 CET] <storrgie> because then someone could reasonably open up, say, vlc, and select the stream they wanted [17:15:55 CET] <storrgie> without bothering me to split into wav/mp3 immediately [17:16:02 CET] <alexpigment> storrgie: would they ever want to select both streams simultaneously? [17:16:07 CET] <alexpigment> or is it one or the other? [17:16:26 CET] <storrgie> I highly doubt it [17:16:36 CET] <storrgie> however, if they did want to... then what do you suggest [17:16:37 CET] <alexpigment> ok, then a two-stream MKV file would be fine [17:16:57 CET] <alexpigment> then i'd suggest doing another audio track (the primary presumably) that is a downmix of the two streams [17:17:24 CET] <storrgie> I guess, because I'm going to be doing this like 30-60 * 8 hours a day * 5 days... I should probaly store it in the "best" archival format [17:17:35 CET] <alexpigment> so the streams would be 1) A+B, 2) A, 3) B [17:17:41 CET] <storrgie> yeah that makes sense [17:17:51 CET] <storrgie> so have a downmix of A+B, then A and B separately [17:17:56 CET] <alexpigment> right [17:18:00 CET] <alexpigment> that would be my suggestion [17:18:01 CET] <storrgie> all in an mkv, so they could select [17:18:05 CET] <alexpigment> right [17:18:20 CET] <storrgie> soo... I have this page (https://trac.ffmpeg.org/wiki/AudioChannelManipulation) to get my started, is that still the right place to begin? [17:18:41 CET] <alexpigment> yes [17:19:16 CET] <alexpigment> see the 2 x stereo > stereo section for the mixdown [17:21:03 CET] <storrgie> so, I'd start like this then: ffmpeg -f dshow -i audio="Microphone (Realtek Audio)" -f dshow -i audio="Stereo Mix (Realtek Audio)" -filter_complex "[0:a][1:a]amerge=inputs=2[aout]" -map "[aout]" -ac 2 output.mkv [17:21:25 CET] <storrgie> however that is only giving the A+B track to the mkv right now, so I also need to do A and B respectively? [17:22:04 CET] <alexpigment> yeah i think you just also add -map 0:a -map 1:a after -ac 2 [17:22:35 CET] <storrgie> thanks a ton [17:22:40 CET] <storrgie> I'll attempt this on Monday! [17:23:26 CET] <alexpigment> good luck [17:23:37 CET] <storrgie> and this is not going to do any on the fly compression right? [17:23:39 CET] <alexpigment> i'll do a test over here real quick to make sure there isn't some caveat about that setup [17:23:40 CET] <storrgie> which, is ok with me [17:24:12 CET] <alexpigment> well, if it's all in PCM, it's not going to be compressed [17:24:20 CET] <storrgie> right, it is [17:24:25 CET] <storrgie> because coming off sound interfaces [17:24:26 CET] <alexpigment> but I guess you need to specify that [17:24:33 CET] <storrgie> I dont think I _want_ to compress it [17:24:40 CET] <storrgie> I could always do that later right, via re-encoding it? [17:24:43 CET] <alexpigment> right [17:24:51 CET] <storrgie> I'd rather spare the CPU cycles at capture time for the actual game [17:24:59 CET] <storrgie> its quite intense on the machine, and they are on Alienware R5 laptops [17:25:04 CET] <storrgie> laptop CPU is not the best [17:25:11 CET] <alexpigment> but keep in mind that with 44.1/16bit you're going to be doing 10MB every minute [17:25:14 CET] <alexpigment> x3 [17:25:18 CET] <alexpigment> so 30MB/min [17:25:26 CET] <storrgie> I have a 1T hard drive in each for capture [17:25:27 CET] <alexpigment> probably fine, but just saying [17:25:37 CET] <storrgie> they have an SSD for the OS/game, but a 1T conventional drive for capture [17:29:07 CET] <alexpigment> i'm doing some tests right now [17:29:20 CET] <storrgie> I've gotta run, but I'm on here with my bouncer so I'll see it! [17:29:21 CET] <alexpigment> the filterchain and the copy are kinda mutually exclusive it hink [17:29:23 CET] <storrgie> thanks for looking at it [17:32:15 CET] <alexpigment> storrgie: i PM'd you the command, so as not to spam in here [17:47:09 CET] <d9867eb> hi again [17:47:31 CET] <d9867eb> I hava a new question [17:49:31 CET] <d9867eb> If I have a 720p or 1080p video and want to convert to 480p, then what is the correct scale filter? would scale=16:9 do fine? [17:50:05 CET] <JEEB> -vf "scale=-2:480" [17:50:16 CET] <JEEB> -2 is (according to aspect ratio, but divisible by 2) [17:50:21 CET] <JEEB> which is what you need for 4:2:0 [17:50:51 CET] <d9867eb> ok thanks jeeb [19:50:27 CET] <SortaCore> JEEB: Any built-in way to set up properties of an AVFrame to receive from a AVStream? [19:50:34 CET] <SortaCore> I'm having to set width, height, pixel format, color range, color primaries... [20:17:07 CET] <BtbN> you mean AVPacket? [20:22:57 CET] <JEEB> SortaCore: the decoder should set the values to the AVFrame, no? [20:33:46 CET] <SortaCore> avcodec_receive_frame() requires a frame, so I have to pre-initialise it to match the stream [20:33:59 CET] <JEEB> uhh, no? [20:34:17 CET] <JEEB> the decoder fills the fields in the AVFrame [20:34:34 CET] <JEEB> you just give it an AVFrame allocated and usable [20:35:17 CET] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html and https://www.ffmpeg.org/doxygen/trunk/group__lavc__decoding.html#ga11e6542c4… are related [20:36:11 CET] <SortaCore> right now I'm doing av_frame_alloc, av_image_alloc, setting the format and types [20:36:46 CET] <SortaCore> I am using sws_scale if that is a factor [20:37:02 CET] <JEEB> you don't have to allocate anything else than the AVFrame [20:37:26 CET] <JEEB> the decoder has already generated the buffer which it will stick to the AVFrame's pointer [20:38:04 CET] <JEEB> also I recommend you use the scale and format filters in lavfi instead of swscale itself since the interface is much clearer that way [20:38:14 CET] <JEEB> but if you're OK with swscale that's fine, too [20:38:30 CET] <JEEB> avfilter just takes in AVFrames and returns you AVFrames [20:38:49 CET] <JEEB> so you never have to leave the AVFrame abstraction layer [20:39:14 CET] <SortaCore> I'm using it for format converts [20:39:17 CET] <JEEB> yes [20:39:28 CET] <SortaCore> yuv to nv12, rgb, greyscale [20:39:33 CET] <JEEB> you get the same with lavfi (it uses swscale in the background) [20:39:43 CET] <JEEB> it's just simpler in the way that you never have to deal with something that isn't AVFrames on your side [20:39:50 CET] <JEEB> but as I said, if you are OK with swscale and all, that's fine [20:40:21 CET] <JEEB> alexpigment: mpv can use the GPU's filters through d3d11 it seems, but only when d3d11 hwdec is being used [20:40:25 CET] <JEEB> https://mpv.io/manual/master/#video-filters-d3d11vpp [20:41:06 CET] <SortaCore> yea, dunno how to use lavfi that way [20:41:39 CET] <JEEB> see the docs/examples if you ever get interested [20:41:53 CET] <alexpigment> JEEB: thanks for the heads up. i'll take a look into that today [20:58:03 CET] <alexpigment> JEEB: under --hwdec= it lists d3d11va [20:58:19 CET] <alexpigment> and mentions Windows 8+ [20:58:24 CET] <alexpigment> i'm on 7 [20:58:27 CET] <JEEB> ah [20:58:32 CET] <JEEB> oh well [20:58:33 CET] <alexpigment> actually, maybe they're just talkinga bout gpu-context=angle [20:58:33 CET] <JEEB> :) [20:58:42 CET] <alexpigment> sorry, still trying to figure this out [21:01:22 CET] <JEEB> I'm using git master mpv anyways since I have to test PRs :D [21:01:41 CET] <JEEB> which defaults to d3d11 rendering if you have the correct dependencies available [21:01:57 CET] <JEEB> (OpenGL shaders compiled into HLSL) [21:02:42 CET] <alexpigment> yeah, they don't really do a good job in the documentation of giving an example for this [21:03:11 CET] <alexpigment> there's a generic filter chain example, but it's unclear if d3d11 itself needs to be specified, or if the sub options need to be specified [21:04:27 CET] <JEEB> don't play with the VO, --hwdec=d3d11va --vf=d3d11vpp=deint=yes [21:04:33 CET] <JEEB> I guess something like that? [21:04:59 CET] <JEEB> the suboptions have defaults so if the default is OK you don't have to override [21:06:59 CET] <JEEB> oh, if I enable the post-processing it downconverts to 8bit YCbCr (NV12) for me in case of P010 :< [21:07:40 CET] <storrgie> alexpigment, sorry it seems znc didn'y pick up the pm :( [21:08:26 CET] <alexpigment> i just re-sent, did you get it? [21:08:44 CET] <JEEB> alexpigment: but yea, current git master on win10 seems to work. not 100% sure if anything else gets applied as well http://up-cat.net/p/fc331504 [21:09:04 CET] <alexpigment> ok, so i've got an mpv.conf file [21:09:06 CET] <JEEB> at least the image received is NV12 from the post-processor [21:09:15 CET] <alexpigment> which I had to create manually [21:09:21 CET] <alexpigment> because it didn't exist (curiosity #1) [21:09:33 CET] <alexpigment> and really all i put in it is this: [21:09:42 CET] <alexpigment> --vo=gpu --gpu-context=d3d11 --hwdec=d3d11va --vf=d3d11vpp=deint=yes [21:09:49 CET] <alexpigment> i tried it without the first two, but nothing happened [21:10:06 CET] <alexpigment> i don't really know of a way to even verify that these parameters or the file in general is getting read [21:10:19 CET] <JEEB> open cmd.exe? [21:10:32 CET] <JEEB> or powershell if you prefer that [21:10:41 CET] <alexpigment> yeah i've got cmd right here [21:11:13 CET] <JEEB> then just don't call it mpv.exe but instead leave the extension out or specify mpv.com :P (because windows is stupid with standard output) [21:11:15 CET] <alexpigment> is there no way to specify this via mpv.conf so it gets used all the time? [21:11:26 CET] <JEEB> it is, but those all are without -- and on separate lines [21:11:31 CET] <JEEB> and you wanted to check, no? [21:11:42 CET] <alexpigment> well, let me try separate lines [21:11:44 CET] <JEEB> easiest way to check is to run it in cli and check what it's using :P [21:12:01 CET] <JEEB> removal of the -- might not be needed but that's what I'm using since it's not command line options [21:12:35 CET] <alexpigment> mpv [what next]? [21:12:39 CET] <alexpigment> to check what it's using [21:12:49 CET] <JEEB> just drag and drop a video file then [21:12:50 CET] <alexpigment> apologies. i'm really green on mpv [21:12:55 CET] <JEEB> on the cmd.exe [21:12:58 CET] <JEEB> and the path to it will get inserted [21:13:11 CET] <JEEB> you can do tab-autocomplete as well, but I find it usually simpler [21:13:30 CET] <alexpigment> ok, so i'm back to what I had before [21:13:33 CET] <alexpigment> with separate lines [21:13:41 CET] <alexpigment> and when i try to load mpv.exe, it never loads [21:13:44 CET] <JEEB> also if you want it to write a verbose log into a text file there's --log-file=file.txt [21:13:50 CET] <alexpigment> ok [21:13:52 CET] <alexpigment> i'll try that [21:15:17 CET] <alexpigment> Video output gpu not found! [21:15:23 CET] <JEEB> ok, so yours is just old [21:15:25 CET] <alexpigment> that's a quote - i'm not that excited [21:15:35 CET] <JEEB> there's separate documentation for the latest "release" [21:15:37 CET] <alexpigment> i downloaded a precompiled binary a few days ago [21:15:41 CET] <alexpigment> k [21:15:51 CET] <JEEB> lachs0r only builds releases, if you want mine I can put it up [21:16:12 CET] <alexpigment> lemme check the other person's site first [21:16:25 CET] <alexpigment> shinchiro [21:18:19 CET] <JEEB> also the reason why mpv builds come with both mpv.exe (the actual player) and mpv.com (a wrapper for standard output/error logging) is because windows either lets you build an app that doesn't output anything to standard output/err (GUI), or an app that outputs to that, but will forcibly open a cmd.exe for you :D (CLI) [21:18:34 CET] <JEEB> and because cmd.exe picks .com first, before .exe :P [21:19:06 CET] <JEEB> (mpv.com launches mpv.exe in the background and redirects the debug output to the terminal) [21:19:09 CET] <alexpigment> oh crap [21:19:15 CET] <alexpigment> this new one had an installer.bat [21:19:21 CET] <JEEB> no need to use it really [21:19:26 CET] <alexpigment> and i didn't realize it creates file associations [21:19:42 CET] <JEEB> yea, that's the only "installation" you'd require with mpv [21:19:57 CET] <JEEB> I think it also comes with an uninstall thing although I am not sure if it can restore things back [21:20:04 CET] <alexpigment> yeah, that's what i'm hoping ;) [21:28:00 CET] <alexpigment> "Creating filter 'd3d11vpp' failed" [21:28:02 CET] <alexpigment> that's in the log [21:28:22 CET] <JEEB> did it succeed with d3d11va? [21:28:25 CET] <alexpigment> after it mentions all the things were registered correctly (or seemingly correctly) [21:29:01 CET] <alexpigment> Loading hwdec driver 'd3d11-egl' [21:29:02 CET] <alexpigment> [ 0.151][v][vo/gpu] Loading failed. [21:29:02 CET] <alexpigment> [ 0.151][v][vo/gpu] Loading hwdec driver 'd3d11-egl-rgb' [21:29:02 CET] <alexpigment> [ 0.151][v][vo/gpu] Loading failed. [21:29:02 CET] <alexpigment> etc [21:31:05 CET] <JEEB> a working case looks like this to me http://up-cat.net/p/bb3d14dd [21:31:36 CET] <alexpigment> oh, so you have the same failure messages? [21:31:53 CET] <JEEB> d3d11va works so it will use that one [21:32:06 CET] <JEEB> the egl stuff is for opengl/angle compatibility I guess [21:32:15 CET] <JEEB> since d3d11 can use d3d11 textures as-is [21:32:26 CET] <JEEB> which the d3d11va decoder outputs [21:34:33 CET] <JEEB> but yea, that has the rendering/decoding/video filter stuff [21:34:38 CET] <JEEB> in a working case [21:35:05 CET] <JEEB> HEVC works the same for me except it will downconvert to 8bit for the deinterlacing filter :( [21:37:15 CET] <alexpigment> hmmm [21:37:22 CET] <alexpigment> it's just failing on the video filter part [21:37:26 CET] <alexpigment> I don't really know why [21:37:35 CET] <alexpigment> maybe this *is* something that doesn't work on win7 [21:37:38 CET] <alexpigment> although i don't know why [21:38:17 CET] <JEEB> so the decoder actually works if you disable the post-processor? [21:38:43 CET] <JEEB> because I would expect d3d11va to also fail on win7 if the post-processor does - as that's a limitation I remember :P [21:39:20 CET] <alexpigment> oh ok, so i guess it diverges where it says "could not create device" [21:39:25 CET] <alexpigment> on mine [21:40:00 CET] <alexpigment> there are some loading failures on yours, but then it says Trying hardware decoding via mpeg2video-d3d11va. [21:40:12 CET] <JEEB> yea, it tries to initialize all of the ones built in I think [21:40:29 CET] <JEEB> I recently merged a PR for some logic like that I think :P [21:40:53 CET] <JEEB> https://github.com/mpv-player/mpv/commit/a4705e8b59a0c496852d67db591bb480e0… [21:40:57 CET] <JEEB> yup [21:41:27 CET] <alexpigment> well, real life is calling for a few minutes. i'll have to try this later [21:41:34 CET] <JEEB> alright [21:41:38 CET] <alexpigment> rather, keep trying and stare at some logs ;) [21:41:48 CET] <JEEB> you could just post the same range as I did if you want :P [21:41:59 CET] <JEEB> also we could move this discussion to #mpv I guess [21:59:32 CET] <TheRock23> hi, is it true that ffmpeg is the best player ? [21:59:54 CET] <teratorn> TheRock23: no, who says that? [22:00:10 CET] <JEEB> FFmpeg is not a player, but you'd be surprised how many players use FFmpeg behind the scenes [22:00:14 CET] <JEEB> ;) [22:00:52 CET] <TheRock23> i see, so its better than winodws player? [22:04:47 CET] <dystoipa_> it's not a video player TheRock23 [22:06:22 CET] <SortaCore> VLC best player [22:49:16 CET] <szefoski> Hello, I have an IP camera, I'm receiving I and P frames. When I do ffprobe on I frame I see such output: [22:49:19 CET] <szefoski> Stream #0:0: Video: h264 (High), yuvj420p(pc, bt709, progressive), 640x360, 25 tbr, 1200k tbn, 50 tbc [22:49:52 CET] <szefoski> How can I Combine these frames into valid video file using FFMPEG C API? [22:50:30 CET] <BtbN> What do you mean? It gives you individual pictures, or a video stream? [22:50:51 CET] <JEEB> you can read packets from the input with libavformat and then you can mux those packets into a container [22:53:16 CET] <szefoski> How to convert such packets into valid AVFrame? [22:53:33 CET] <JEEB> AVFrames require throwing it at the decoder [22:53:43 CET] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [22:53:50 CET] <JEEB> also there are examples under docs/examples [22:54:28 CET] <szefoski> Thank you! [22:56:19 CET] <szefoski> @BtbN, individual pictures [22:56:32 CET] <BtbN> them being I/P frames makes no sense then [22:56:39 CET] <BtbN> That would indicate them being a video stream [23:45:18 CET] <SortaCore> does libopenh264 require shared library or is static ok [23:47:55 CET] <JEEB> SortaCore: both should work [00:00:00 CET] --- Sat Dec 16 2017

1 0

ffmpeg-devel.log.20171214
by burek 15 Dec '17

15 Dec '17

[00:03:04 CET] <durandal_1707> michaelni: its never recognized [00:11:40 CET] <michaelni> durandal_1707, it is recognized here, ffprobe prints " yuv420p(tv" [00:14:19 CET] <durandal_170> michaelni: why itts experimental.? [03:45:23 CET] <cone-274> ffmpeg 03Rodger Combs 07master:2e391a576c1f: lavf/mpegts: mark packets with TEI flag as corrupted [09:39:41 CET] <durandal_1707> michaelni: the limited mjpeg command cant work as is, you would need to also set color range [12:53:32 CET] <Chloe> What's the status on ffserver removal? Weren't we waiting for an ABI bump to remove it? Has that happened yet? [12:54:38 CET] <atomnuker> yes we are, no the period isn't over, we still need to remove the avpriv_atomic stuff [12:54:39 CET] <durandal_1707> yea, whats status? [12:55:09 CET] <durandal_1707> but commit was reverted [12:55:14 CET] <Chloe> What to do to remove avpriv_atomic? [12:55:15 CET] <atomnuker> nevcairiel said he'd look into making the cas function (the only blocker) disappear but seems like he hasn't had the time yet [12:55:33 CET] <atomnuker> durandal_1707: one was, it was unrelated to atomics stuff, was just a simplification [12:56:10 CET] <atomnuker> Chloe: figure out how to replace the avpriv_atomic_ptr_cas with regular c11 atomics [12:57:50 CET] <atomnuker> btw nevcairiel you really should have pinged me before reverting my commit [12:58:05 CET] <atomnuker> or at least talk with michaelni to figure out if its worth keeping the atomic stuff [12:59:23 CET] <wm4> wasn't that already discussed to death [12:59:50 CET] <wm4> and that code is rather crappy and barely safe anyway (theoretically failure modes were discussed) [12:59:57 CET] <wm4> +possible [13:00:14 CET] <atomnuker> yes, and there were 2 ways to solve it - remove atomics or properly fix the wrapper to support atomic_bool [13:00:40 CET] <atomnuker> yes, I agree, that's option 2 btw Chloe - make the list compile time and make the registry functions a noop [13:01:08 CET] <wm4> like BSFs - that's the ideal solution [13:05:06 CET] <Chloe> atomnuker: dont you just have to rewrite the whole atomics file? [13:05:48 CET] <atomnuker> no, the idea is to remove the avpriv atomic stuff altogether [13:06:03 CET] <atomnuker> since they're part of the abi and we'd like to keep it clean [13:06:18 CET] <Chloe> Oh right [13:06:20 CET] <atomnuker> and since they're useless code since everywhere else we use c1s [13:06:52 CET] <Chloe> Ok. I misunderstood, i thought you wanted a c11 atomic wrapper for some reason [13:08:16 CET] <wm4> at least cas in the win32 wrapper is fundamentally broken, which brought us this whole issue [13:10:14 CET] <Chloe> It's only used across 4 files. Mmmh. I'll give it a look when I get home [13:23:57 CET] <michaelni> durandal_1707, about mjpeg limited color range, you are correct it looks like its needed once yuvj is gone. Before yuv420p seems to have been interpreted as limited range by default, so forcig just that seems to have been enough [13:25:23 CET] <michaelni> this change should be documented somewhere with examples [13:25:42 CET] <wm4> apichanges.txt [13:26:00 CET] <wm4> (ok, there's no .txt extension) [13:42:15 CET] <nevcairiel> atomnuker: i tried to convert it, but i'm not sure i fully understand the logic in avcodec_register in the first place, it doesnt seem entirely thread-safe to me .. plus i have no way to test if it is, since any cases that would result in it being called simultaneously are extremely contrived and unlikely [13:44:28 CET] <nevcairiel> usually linked lists are implemented by swapping the head element out atomically which is easy, this one is weirdly backwards [13:45:47 CET] <jkqxz> It needs to preserve the order so that searching for a codec gives you the normal answer by default rather than some hardware codec you don't have hardware for. [13:48:21 CET] <wm4> yep [13:48:32 CET] <wm4> I have no idea why the list isn't just protected by a mutex [13:48:44 CET] <wm4> that would be easiest [13:48:45 CET] <nevcairiel> static mutexes are annoying [13:48:54 CET] <nevcairiel> but yeah it certainly would be much easier [13:49:02 CET] <wm4> static mutexes are perfectly possible on windows [13:49:09 CET] <wm4> on vista+, MS has explicit API for them [13:49:21 CET] <nevcairiel> not that i can see [13:49:36 CET] <wm4> for XP you could statically initialize CriticalSection, which is not documented, but happens to work (and it won't change anymore so it'll keep working) [13:49:56 CET] <wm4> you'd weirdly have to switch between them at runtime though, if you really want binaries to support both [13:50:08 CET] <wm4> or we could just drop XP support [13:50:10 CET] <jkqxz> Fuck XP support. [13:50:14 CET] <jkqxz> Yeah, that. [13:50:31 CET] <nevcairiel> i dont do XP either anymore these days, but who knows if there would be consensus [13:51:35 CET] <nevcairiel> you could do a pthread_once initialized mutex if you wanted to go down that route, but technically you're leaking a handle [13:52:23 CET] <wm4> the lock manager is already leaking one [13:53:18 CET] <j-b> We drop XP after this release of VLC [13:53:31 CET] <j-b> So, I won't break your b*lls anymore about XP and Vista [13:53:52 CET] <nevcairiel> vista is fine on the api level, most of those things appeared with vista [13:54:16 CET] <j-b> well, sure [13:59:20 CET] <wm4> what stops us from providing a DllMain, and just leaking it for static builds? [14:00:20 CET] <BBB> seems like a lot of effort for a dead os [14:00:30 CET] <BBB> (xp is well beyond eol) [14:00:42 CET] <wm4> yes [14:01:08 CET] <wm4> but you know well that once we actually attempt to drop it, all the trolls will come out of their holes [14:01:22 CET] <nevcairiel> I killed XP in the version where I added d3d11 decoding, because the visual studio SDK which supports XP doesnt have full d3d11, so it was kinda required and a good excuse =p [14:01:47 CET] <atomnuker> btw where does the 40 byte leak happen when using valgrind? in ffmpeg.c [14:02:03 CET] <wm4> --leak-report=full ? [14:02:54 CET] <BBB> wm4: so let the trolls come [14:03:04 CET] Action: jdarnley is already here [14:03:05 CET] <BBB> we get trolled every day [14:03:51 CET] <BBB> \o/ [14:14:19 CET] <wm4> do we have an official list of people who can participate in votes? [14:14:27 CET] <wm4> or any document which outlines how votes work [14:15:01 CET] <wm4> because I want to post a RFC+vote on this [14:17:23 CET] <durandal_1707> on xp support? [14:18:13 CET] <durandal_1707> top 10 recent commit authors can vote [14:18:57 CET] <atomnuker> wm4: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183803.html [14:20:37 CET] <wm4> what dates should be used? [14:21:13 CET] <wm4> well uh the procedure for determining the members of the voting committee is still unclear to me [14:21:39 CET] <wm4> I guess I remove the --until, and set --since to 1 year ago [14:22:42 CET] <durandal_1707> lets ditch all commiters and leave only me and michael [14:23:06 CET] <atomnuker> wm4: well, the people shouldn't have changed [14:23:15 CET] <wm4> hm the result I'm getting can't be right [14:23:36 CET] <atomnuker> originally we agreed to include people from 5th of september (the day of the meeting) until the next 5th of sepetember [14:23:51 CET] <atomnuker> but we just kept the committee as-is [14:25:05 CET] <atomnuker> you should update the committee list first though if you want to document it [14:26:16 CET] <wm4> just sent my post [14:26:35 CET] <wm4> I wanted to include the voting committee member list, but dunno how to do that [14:26:41 CET] <wm4> I don't even know if I can still vote [14:27:27 CET] <atomnuker> yep, you can [14:29:06 CET] <wm4> in any case a list would be useful so we don't have dozens of end users sending votes [14:30:51 CET] <durandal_1707> we have no more subscribers [14:31:06 CET] <durandal_1707> all unsuscribed since my spam [14:33:03 CET] <j-b> m [14:35:27 CET] <rcombs> I dropped XP when Chrome did [14:35:31 CET] <iive> won't it be simple if we just turn off threads on winxp? [14:35:51 CET] <atomnuker> yeah, I don't see the issue xp has if threading was disabled [14:36:30 CET] <rcombs> lol [14:36:33 CET] <atomnuker> durandal_1707: hardly spam, your work to get rid of yuvj is very appreciated [14:37:00 CET] <rcombs> XP still supported, but rendered useless [14:37:09 CET] <wm4> I thought about disabling threads too, but I don't think this would raise general acceptance [14:37:22 CET] <wm4> since multithreaded decoding is pretty important [14:37:33 CET] <rcombs> yeah I don't really see the point of half-assing removal [14:37:59 CET] <rcombs> if the only reason not to remove is people whining about their 2001 OS [14:39:02 CET] <iive> well, wine still hasn't implemented winxp api's fully. and win7 is even less complete. [14:39:16 CET] <rcombs> who uses ffmpeg in wine [14:39:24 CET] <rcombs> have they noticed it's cross-platform [14:39:35 CET] <iive> is there native linux handbrake? [14:39:41 CET] <jdarnley> Must. Not. Troll. [14:39:54 CET] <rcombs> yup [14:40:01 CET] <rcombs> (though also, >>handbrake) [14:42:58 CET] <wm4> rcombs: win32 has a more stable ABI, so using wine on portable programs can be attractive [14:43:26 CET] <iive> anyway, if you vote, I'd prefer to put an option for making all codec/filter static and not having to register it at startup. [14:43:46 CET] <iive> it/them [14:43:55 CET] <rcombs> like with bsfs? [14:44:09 CET] <iive> i guess. [14:44:34 CET] <rcombs> I do have a use-case that requires the _ability_ to register new ones at runtime [14:44:52 CET] <rcombs> though that doesn't mean everything _has_ to be [14:45:01 CET] <wm4> iive: that's prthogonal [14:45:08 CET] <wm4> orthogonal even [14:45:16 CET] <iive> it's the root of the problem, isn't it? [14:45:39 CET] <wm4> static mutexes might be useful for other reasons too [14:45:52 CET] <wm4> also there's an incentive for not using the XP emulation code on modern windows [14:46:12 CET] <iive> are you working for microsoft now? [14:46:16 CET] <iive> ;) [14:47:16 CET] <wm4> no [14:47:57 CET] <wm4> the modern windows locking APIs effectively use the linux futex design [14:50:05 CET] <iive> so the deprecation would simplify the code? would that affect any code outside the os-compatibility? [14:50:24 CET] <wm4> yes, because we could use static mutexes and such [14:51:18 CET] <iive> no, i mean, would that allow clean up of existing if/def-ery, that does not involuve writing new code. [14:53:56 CET] <wm4> that's not sure, but I expect it makes writing new windows code easier, because you don't have to care about XP anymore, and that's a big one [14:55:26 CET] <iive> so, no. [14:56:23 CET] <wm4> I said it's not sure [14:56:26 CET] <wm4> I didn't check for it [15:01:50 CET] <nevcairiel> there definitely is a bunch of stuff that could remove a bunch of checks [15:01:55 CET] <nevcairiel> primarily in the thread emulation [15:02:08 CET] <nevcairiel> but also sprinkled all over [15:03:59 CET] <durandal_1707> do we have xp fate machines? [15:05:49 CET] <nevcairiel> wm4: technically the end of "all support" was on April 8, 2014 [15:06:19 CET] <wm4> nevcairiel: how so? [15:06:35 CET] <nevcairiel> thats just how it is [15:08:30 CET] <nevcairiel> not sure what 2009 was, mainstream support? extended support ended in 2014, which is the point they stop doing security updates [15:08:53 CET] <JEEB> yea [15:09:41 CET] <Compn> there are so many people still using xp [15:09:53 CET] <Compn> millions of users [15:10:04 CET] <Compn> j-b still supports windows xp as well iirc [15:10:10 CET] <nevcairiel> The way I see it, Old OS = Old FFmpeg [15:10:14 CET] <nevcairiel> its not like 3.4 or such stop working [15:10:24 CET] <rcombs> yeah [15:10:26 CET] <j-b> Compn: as I said, I don't. [15:10:31 CET] <Compn> oh you dont, ok then :) [15:10:53 CET] <Compn> all those poor dos users .... :D [15:10:54 CET] <wm4> j-b: will vlc for windows keep using ffmpeg 3.4? [15:11:12 CET] <rcombs> well they're dropping it after 3.0 so ¯\_(Ä)_/¯ [15:11:21 CET] <iive> btw, the thread cleanup could still be done if XP is used with threads disabled. [15:11:24 CET] <wm4> 3.0 is apparently not released yet [15:11:30 CET] <rcombs> SOON" [15:12:28 CET] <Compn> security updates from microsoft haha [15:13:44 CET] <j-b> wm4: 3.0, yes. [15:14:04 CET] <j-b> wm4: 3.0 is LTS, and won't move the ffmpeg hash for a long time [15:14:28 CET] <j-b> wm4: and vlc.git has already dropped XP+Vista+Seven-without-some-KB [15:14:31 CET] <nevcairiel> if its meant to be supported, perhaps it should though, you know, security updates :D [15:14:43 CET] <wm4> neat [15:15:02 CET] <j-b> nevcairiel: and therefore, it will be patched. [15:15:05 CET] <wm4> what does Seven-without-some-KB affect API wise? [15:15:09 CET] <j-b> yessir [15:15:15 CET] <wm4> possibly d3d11 decoding? [15:15:18 CET] <nevcairiel> why not just track the release branch, thats what its for [15:15:45 CET] <nevcairiel> i couldnt get d3d11 decoding working on 7 at all, other then using the opaque pixfmt which I just flat out refuse to consider valid [15:16:11 CET] <nevcairiel> cant make nv12 textures on 7 [15:16:13 CET] <j-b> wm4: so far, no. [15:16:14 CET] <wm4> yeah, I heard some got it to work... [15:16:21 CET] <j-b> wm4: KB2533623 [15:16:33 CET] <wm4> even if it's just the opaque format, then it might still be more useful than dxva [15:16:36 CET] <j-b> wm4: D3D11va sucks on Win7 and Win8.0, in many configuration. [15:17:23 CET] <Compn> win10 is better ? [15:17:29 CET] <j-b> (read borken drivers) [15:17:45 CET] <Compn> win10 has better drivers? [15:17:53 CET] <nevcairiel> 8.0 should be considered dead and buried anyway, there is literally no reason to stay with 8.0 and not go 8.1 [15:17:55 CET] <j-b> Compn: yes. [15:17:59 CET] <Compn> huh wow [15:18:14 CET] <wm4> as far as I'm concerned, there's only win7 and 10 in practice [15:18:24 CET] <wm4> if someone dares to use vista or 8.x, their fault [15:18:31 CET] <j-b> Compn: basically, the windows desktop on Windows7 is rendered with D3D9. So D3D9 drivers are well tested. [15:18:39 CET] <Compn> ah [15:18:43 CET] <nevcairiel> I still use 8.1 on my HTPC because 10 has a whole bunch of annoying things with video playback [15:18:44 CET] <Compn> yes aero is shit [15:18:45 CET] <j-b> Compn: on Windows 10, it is using D3D11. So D3D11 drivers are well tested. [15:18:56 CET] <j-b> We have 2% of users on Windows 8.0 [15:19:02 CET] <j-b> because it is a pain to update to 8.1 [15:19:30 CET] <j-b> because Microsoft is stupid. [15:19:38 CET] <Compn> j-b : you could copy paste all this into a winxp faq wiki on trac.voo [15:19:41 CET] <Compn> :) [15:19:43 CET] <j-b> Compn: sure. [15:20:05 CET] <Compn> i think it would be a good idea for those winxp holdouts. [15:20:19 CET] <Compn> who demand answers! [15:20:20 CET] <Compn> :) [15:20:48 CET] <wm4> j-b: how many users on 8.1? [15:21:28 CET] <j-b> wm4: 4.98% [15:21:38 CET] <j-b> 8.1% on XP. [15:22:06 CET] <wm4> that's a lot [15:22:11 CET] <j-b> yup [15:23:21 CET] <j-b> and you know the worse? Windows 7 usage is increasing... [15:25:13 CET] <wm4> nice [15:25:25 CET] <wm4> Microsoft fucking up really badly [15:25:29 CET] <Compn> because no one wants to be on a terrible untested win10 platform ? [15:26:38 CET] <j-b> because XP and Vista upgrading to 7 [15:27:04 CET] <Compn> "its the last "good" windows" ? [15:27:54 CET] <wm4> any windows user who's on an older version will think that [15:28:02 CET] <wm4> I thought that of Windows 2000 as well [15:28:10 CET] <wm4> (and I upgraded to Linux, instead of XP lol) [15:28:18 CET] <Compn> i rocked win2k into 2013? ehe [15:28:44 CET] <Compn> wm4 : what distro do you use/like ? [15:29:33 CET] <wm4> use debian, like none [15:29:45 CET] <wm4> considering opensuse [15:30:38 CET] <Compn> i tried suse a few years ago and did not like it. maybe it has gotten better since the [15:30:38 CET] <Compn> n [15:30:53 CET] <j-b> win10 is good. [15:32:16 CET] <wm4> one major issue with getting rid of global mutable code is that some wrappers populate AVCodec.pix_fmts with runtime information [15:32:20 CET] <wm4> e.g. libvpx [15:32:29 CET] <wm4> (see ff_vp9_init_static) [15:32:57 CET] <j-b> I hate libvpx. [15:33:50 CET] <wm4> happens with libx264 too [15:34:11 CET] <wm4> it's a fundamental problem with libavcodec's API [15:36:34 CET] <j-b> That does not change my opinion of libvpx :) [15:36:56 CET] <wm4> of course [15:37:13 CET] <wm4> I just noticed that on libvpx [15:37:23 CET] <wm4> on its lavc wrapper I mean [15:52:58 CET] <wm4> meh, v4l is missing AV_COCEC_CAP_DELAY [15:53:08 CET] <durandal_1707> what it adds to .pix_fmts? [15:56:06 CET] <wm4> durandal_1707: supported formats [15:56:13 CET] <wm4> which can depend on how those libs were built [16:00:33 CET] <durandal_1707> atomnuker: whats status of ffmpeg related work? anything new was implemented? [16:02:54 CET] <atomnuker> am in a convention in austin, but 2 new pvq searches for opus may be on their way [16:17:47 CET] <atomnuker> durandal_170: oh yeah and I'm looking into somehow making the filter list static [16:18:00 CET] <atomnuker> *compile time [17:01:58 CET] <durandal_170> atomnuker: you are not doing anything yet? [17:25:15 CET] <tmm1> anyone interested in reproducing my hls/http network benchmark? curious what kind of results others see http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/222270.html [17:27:01 CET] <atomnuker> durandal_170: I am, but if you'd like to help in making the register functions noops by making the array compile time you're welcome [17:29:57 CET] <durandal_170> just change macro [17:38:25 CET] <atomnuker> which one? [18:02:20 CET] <wm4> man who ever thought AVClass was a good idea [18:02:49 CET] <wm4> or that every codec would have to define its own AVClass [18:03:00 CET] <wm4> is there even any purpose? [18:04:18 CET] <BtbN> to identify it without each codec defining the same fields? [18:16:34 CET] <rcombs> wm4: isn't it for logging [18:16:41 CET] <rcombs> and also for options [18:17:31 CET] <rcombs> so that both of those facilities can work with more than just a single type of component [18:36:38 CET] <atomnuker> ok, seems like making the lavf/lavc/lavfi lists compile time won't be hard [18:37:10 CET] <atomnuker> configure already supports everything, just need to add find_things_extern to generate a file and include it [18:37:24 CET] <atomnuker> and copy the next function from the bsf avclass [18:37:25 CET] <wm4> rcombs: not in the beginning - it was added with av_log [18:43:50 CET] <iive> atomnuker: new pvq searches? tell me more. [18:45:02 CET] <atomnuker> kamedo's been working on that for a few months now [18:45:11 CET] <atomnuker> I think its just heuristics [18:50:32 CET] <Dis> Hi, does mp4 muxer provide segmented 'senc' atom per track when used with the dash? moving senc from stbl atom creates an issue while streaming. [19:15:16 CET] <wm4> jkqxz: fine if I push "[PATCH] avcodec: add metadata to identify wrappers and hardware decoders"? [19:36:43 CET] <wm4> well now Libav pushed it, so I guess I'll push it to ffmpeg too [19:40:34 CET] <cone-669> ffmpeg 03wm4 07master:b945fed629a8: avcodec: add metadata to identify wrappers and hardware decoders [20:02:40 CET] <philipl> wm4: push it [20:02:45 CET] <philipl> too late [20:07:26 CET] <atomnuker> why are all AVCodec definitions non-const? [20:07:34 CET] <atomnuker> all bsf defines are consts [20:41:19 CET] <wm4> atomnuker: 1. for the linked lists, 2. to populate the pix_fmts list [20:41:29 CET] <wm4> atomnuker: 2. was what I just brought up today [20:41:37 CET] <wm4> libvpx and libx264, possibly more [20:42:04 CET] <atomnuker> might change them all to consts [20:42:24 CET] <atomnuker> (or might have to) [20:42:25 CET] <wm4> you can't [20:42:31 CET] <atomnuker> why not? [20:42:37 CET] <atomnuker> its done for the bsfs [20:42:41 CET] <atomnuker> oh [20:42:43 CET] <atomnuker> nvm [20:42:52 CET] <atomnuker> because of the pix fmt not being init'd on init [20:43:26 CET] <wm4> yeah, and fixing this will require an API change [20:45:00 CET] <iive> is avcodec a public struct? [20:45:56 CET] <atomnuker> oh well, ought to work fine with it being const [20:45:56 CET] <iive> i mean, we can have them static, and libvpx/x264 could return a modified copy [20:49:41 CET] <wm4> always fun when ffmpeg devs don't know their own API [20:52:24 CET] <durandal_170> that hurts [21:01:48 CET] <wm4> atomnuker, iive: you can see this e.g. on X264_init_static [21:02:13 CET] <wm4> apparently libx264 can be built with support for a specific bit depth [21:02:50 CET] <wm4> and depending on that only certain pixfmts are available [21:03:11 CET] <wm4> and AVCodec.pix_fmts is of course public API [21:03:26 CET] <wm4> API users need to use it to check whether an encoder supports a pixfmt [21:04:20 CET] <wm4> so we could need to add av_codec_get_pix_fmts() or something [21:04:23 CET] <wm4> then wait 2 years [21:04:27 CET] <wm4> then you can make it const [21:07:19 CET] <durandal_170> wait for 2 years? im too old for that crap [21:07:54 CET] <durandal_170> break now for good [21:08:47 CET] <wm4> apparently that's not project policy [21:09:10 CET] <durandal_170> lets vote on new project policy [21:17:31 CET] <durandal_170> wm4: did you knew that it must pass 7 days for every voting to complete? [21:18:02 CET] <wm4> durandal_170: no, where is that written [21:18:19 CET] <durandal_170> voting rules [21:18:28 CET] <wm4> anyway, downstreams hate us for changing the API all the time [21:18:36 CET] <wm4> even though we really don't [21:18:55 CET] <wm4> (you'd think 2 years are plenty of time) [21:19:22 CET] <BtbN> They keep using a 10 year old version and then are surprised the API changed when they update to the latest version [21:19:56 CET] <wm4> yes [21:20:02 CET] <durandal_170> you didnt specify how much voting should take time, so it runs indefinetely [21:20:26 CET] <BtbN> I think it already good a 51% majority of all active voters? [21:21:01 CET] <durandal_170> so you must abandon this voting and start new one, rules are rules [21:22:21 CET] <durandal_170> we should pick api ala gstreamer and then we dont need to change a thing [21:23:18 CET] <BtbN> Inventing your own meta-programming-language to then implement an API in does not count [21:23:52 CET] <wm4> gstreamer is so unattractive because filters and their connections handle literally everything a transcoder or player would do [21:24:07 CET] <wm4> having a plugin system with stable API is still a good idea [21:28:05 CET] <durandal_170> should i tell ffplay to set its buffersink color range to limited only and bee done with it? or proper selection of pix fmt thus rewrite of code is required? [21:28:50 CET] <wm4> ffplay probably always expects limited range for output? [21:31:56 CET] <durandal_170> but for rgb you are doomed [21:32:38 CET] <wm4> how so [21:33:52 CET] <durandal_170> rgb is full range [21:34:14 CET] <durandal_170> and ffplay supports rgb output [21:34:50 CET] <durandal_170> or in this case for rgb, range is unspecified [21:37:22 CET] <wm4> swscale AFAIK only deals in full range RGB [21:38:09 CET] <durandal_170> so i can give it limited and be done with it [23:10:15 CET] <cone-639> ffmpeg 03Martin Storsjö 07master:18a0f420269f: checkasm: Use LOCAL_ALIGNED for aligned variables on the stack [23:10:15 CET] <cone-639> ffmpeg 03Li, Zhong 07master:6ff29343b019: lavc/qsvenc: set HRD buffer size [23:10:15 CET] <cone-639> ffmpeg 03Li, Zhong 07master:bddb2ce179c5: lavc/qsvenc: ICQ/VCM/QVBR are not avilable on Linux [23:10:15 CET] <cone-639> ffmpeg 03Li, Zhong 07master:7c65a76b16bc: lavc/qsvenc: add error messeage if ICQ unsupported. [23:10:15 CET] <cone-639> ffmpeg 03Li, Zhong 07master:f2e9a0ecbef5: qsv/vp8dec: fixes memory leak issue [23:10:16 CET] <cone-639> ffmpeg 03Luca Barbato 07master:508378556631: qsv: Support explicit lookahead downscaling [23:10:16 CET] <cone-639> ffmpeg 03James Almer 07master:5fc649505b2d: Merge commit '18a0f420269ff4c730422361c5c4d8eea096e900' [23:10:17 CET] <cone-639> ffmpeg 03James Almer 07master:0929def32765: Merge commit '6ff29343b01923e9b125fe7404ac8701cdfb1fe5' [23:10:17 CET] <cone-639> ffmpeg 03James Almer 07master:2ca3c049cd09: Merge commit 'bddb2ce179c57db6e3c79fdc3363c165d90850b0' [23:10:18 CET] <cone-639> ffmpeg 03James Almer 07master:f61cf0e4df52: Merge commit '7c65a76b16bc3a44f1592acde2176f187a058797' [23:10:19 CET] <cone-639> ffmpeg 03James Almer 07master:b4718b76937a: Merge commit 'f2e9a0ecbef5027f9532c49ffcdfc11d199f6150' [23:10:20 CET] <cone-639> ffmpeg 03James Almer 07master:374f818bfbc5: Merge commit '508378556631dc18d32247b4a4e35703758e1ca9' [23:12:34 CET] <cone-639> ffmpeg 03wm4 07master:47687a2f8aca: avcodec: add metadata to identify wrappers and hardware decoders [23:12:35 CET] <cone-639> ffmpeg 03James Almer 07master:980af9a88cfd: Merge commit '47687a2f8aca3f65b6fdd117b1cb66a7409a7fd1' [23:22:07 CET] <daddesio> Hi all, would it be worth adding a decoder for EA MicroTalk in FFmpeg? It's a 32kbit/s speech codec used in some (obscure?) EA games from 1997-2002: Beasts & Bumpkins, Ultima IX, FIFA 2001, FIFA 2002, and The Sims Online. [23:22:29 CET] <daddesio> https://wiki.multimedia.cx/index.php/Electronic_Arts_MicroTalk [23:23:09 CET] <daddesio> Thing is, almost every game uses a different container. At least FIFA uses SCxl. [23:26:38 CET] <daddesio> which we already have support for. [23:28:08 CET] <BBB> I think yes [23:28:17 CET] <BBB> we have a ton of game codecs, and theyre typically quite straightforward [23:28:28 CET] <BBB> (decoding only, right? I Dont think we want to encourage encoding of such files) [23:28:34 CET] <jdarnley> I don't object. I once submitted a patch for a demuxer fr 13 files from 1 game. [23:28:59 CET] <jdarnley> speaking of which, I should finish that by adding a probe function. [23:29:16 CET] <daddesio> :p [23:29:51 CET] <daddesio> Okay another thing is that each SCxl packet contains 4 MicroTalk frames. [23:30:13 CET] <daddesio> But MicroTalk doesn't explicitly indicate the size of the frame. You have to decode it first to find out its length. [23:30:31 CET] <daddesio> MicroTalk frames are variable-length. [23:30:41 CET] <daddesio> e.g. it uses unary coding at one point [23:30:46 CET] <jdarnley> So there is no indication where one frame ends without decoding? [23:30:50 CET] <daddesio> correct [23:32:19 CET] <daddesio> The Sims Online has a custom container (.UTK) that doesn't use packets. The UTK body is a stream of thousands of (variable-length) MicroTalk frames, so it's impossible/difficult to seek. [23:32:28 CET] <jdarnley> I don't know much about the API so I would just say that you should make the decoder tolerate several frames in one AVFrame/AVPacket [23:33:00 CET] Action: jdarnley forgets which structgets passed into decoders [23:33:22 CET] <daddesio> lu_zero in #libav-devel suggested I write a reframer to first decode the MicroTalk frame in order to find out the length, then pass the frame to the real decoder. [23:33:27 CET] <BtbN> I think it's pretty common for audio decoders to only partially consume input packets [23:33:47 CET] <BBB> yes [23:33:56 CET] <BBB> but that doesnt give concatenation of packets [23:34:05 CET] <BBB> so you need to give the whole file at once from demuxer to decoder [23:34:12 CET] <BBB> or parse them in e.g. a parser or bsf [23:34:17 CET] <BBB> as lu_zero also said [23:34:47 CET] <daddesio> Well, you can place a pretty generous upper bound on MicroTalk frames. (Technically, MicroTalk frames can be infinite in size due to the unary coding, but I think we can cap the unary coding to 16 bits.) [23:35:48 CET] <StevenLiu> Ping jamrial [23:36:46 CET] <daddesio> But also, decoding a MicroTalk frame isn't that hard to do. You can probably do it in 100 lines. [23:36:54 CET] <daddesio> so a reframer isn't out of the question [23:37:40 CET] <daddesio> Also, vgmstream just added support for MicroTalk, so... we don't strictly need support for it in FFmpeg anymore. :P [23:37:58 CET] <StevenLiu> i see there hre duplicate the ./libavcodec/reverse.c ./libavdevice/reverse.c from why don't define them in libavformat/ , libavcodec, libavfilter, libavdevice, ? only include it? [23:39:40 CET] <StevenLiu> include a c source file, looks it weird even though that have no problem [23:41:05 CET] <StevenLiu> i see there hre duplicate the ./libavcodec/reverse.c ./libavdevice/reverse.c, why don't define them in libavformat/ , libavcodec, libavfilter, libavdevice, ? only include it? [23:41:50 CET] <durandal_170> daddesio: see interplay acm decoder [23:42:16 CET] <jdarnley> whatever you decide to do you shouldn't decode the audio twice just so you can neatly pass a single frame around. [23:42:50 CET] <daddesio> Well you don't need to decode the audio, you only need to decode the fields. [23:43:49 CET] <jdarnley> perhaps I misunderstood, I thought you meant to had to process bits in some from the entire frame [23:43:52 CET] <durandal_170> there must be max possible size of encoded frame, right? [23:44:11 CET] <daddesio> If you cap the unary codes to 16 bits, then yes there is a max size. [23:44:31 CET] <daddesio> The whole decoder is here: https://github.com/daddesio/utkencode/blob/master/utk.h [23:44:39 CET] <daddesio> It's a pretty simple codec. [23:45:05 CET] <daddesio> see utk_decode_frame: https://github.com/daddesio/utkencode/blob/master/utk.h#L289 [23:45:49 CET] <daddesio> Basically it has a Huffman table to decode commands to construct the excitation signal, and some of the commands have arguments. [23:47:10 CET] <daddesio> Also, SCxl guarantees that there are 1-4 MicroTalk frames per SCDl packet. [23:47:56 CET] <daddesio> I think SCxl tells you the duration of the frame which means you can calculate how many MicroTalk frames there are supposed to be inside it. [23:48:11 CET] <daddesio> s/duration of the frame/duration of the SCDl packet/ [23:48:57 CET] <daddesio> I realize that FFmpeg is designed to handle streaming audio from the internet and seeking to random points in the audio. [23:52:51 CET] <cone-639> ffmpeg 03Gyan Doshi 07master:1c76134fe37a: avfilter/drawbox+drawgrid - add option to prevent overwriting of source pixels [23:55:02 CET] <daddesio> Has anyone ever thought about adding coroutines to FFmpeg for situations like this? :p [23:56:34 CET] <durandal_170> daddesio: shorten and acm are codecs similar as that one [23:56:50 CET] <durandal_170> and ffmpeg have decoders for them [23:57:12 CET] <durandal_170> you just cant seek within them [23:59:33 CET] <daddesio> The thing is, I feel it should be possible to seek within SCxl (since there are guaranteed no more than 4 MicroTalk frames per SCDl packet), just not within The Sims Online's UTK format. [23:59:49 CET] <atomnuker> daddesio: you can look into using AV_CODEC_CAP_SUBFRAMES [00:00:00 CET] --- Fri Dec 15 2017

1 0

ffmpeg.log.20171214
by burek 15 Dec '17

15 Dec '17

[01:02:48 CET] <WireCat> Hey! Does anybody know why would i get such error "make: *** No rule to make target 'libavcodec/x86/huffyuvdsp_template.asm', needed by 'libavcodec/x86/huffyuvdsp.o'. Stop. [01:02:48 CET] <WireCat> " [01:04:53 CET] <jkqxz> WireCat: Are you reusing an old build directory without cleaning after file dependencies have changed? [01:05:25 CET] <WireCat> i think i cleaned it, but let me check [01:05:57 CET] <WireCat> is 'make clean' enough, or one needs to do something in addition to that? [01:06:21 CET] <furq> run git clean -dfx if you want to be totally sure [01:06:30 CET] <furq> assuming you got this from git ofc [01:06:40 CET] <jkqxz> That wouldn't do anything in the build directory? [01:06:50 CET] <jkqxz> "make clean" is what you want, yeah. [01:06:52 CET] <furq> it would delete the build directory wouldn't it [01:07:10 CET] <jkqxz> Well, only if it's inside the source directory. [01:07:12 CET] <WireCat> ok i did both and will try again rn :) [01:07:42 CET] <furq> oh yeah i forget people do out of tree builds [01:08:20 CET] <WireCat> well i have a problem with opencv actually, it segfaults when trying to load a video fiile [01:08:30 CET] <WireCat> so im hoping building the thing manually will help. [01:09:40 CET] <WireCat> the original error I get is " general protection ip:7f1b4a251f01 sp:7ffffb3fd720 error:0 in libavutil.so.55.58.100[7f1b4a23d000+62000]"' but that doesn't mean anything. I'm using ubuntu 17.04. [01:10:03 CET] <WireCat> would you say that trying to compile it manually is a possible way to solve this? [01:11:07 CET] <jkqxz> A backtrace might help. [01:11:42 CET] <jkqxz> That suggests something wrong in libavutil or a caller, but there isn't enough information to tell anything beyond that. [01:13:55 CET] <WireCat> oh, i can't do the backtrace anymore, as i seem to have removed the opencv packages already [01:14:37 CET] <WireCat> i'll just hope then, that the manual compilation will help. :-) [01:17:03 CET] <WireCat> jkqxz, the cleaning helped, it built ok now :-) Thank you again! [01:39:25 CET] <SortaCore> is there a way to check if the codec is video? [01:53:07 CET] <furq> SortaCore: ffprobe -show_entries stream=codec_type [01:53:27 CET] <SortaCore> I mean in C++, I'm looping via avcodec_next [02:07:10 CET] <alexpigment> jkqxz: mikhail emailed me back and said he figured out the problem it should be addressed by a driver update in 2-3 weeks [02:07:48 CET] <alexpigment> jkqxz: clarification - the issue with AMF encoding and the weird artifacting in plaback [02:07:53 CET] <alexpigment> *playback [02:14:40 CET] <jkqxz> So that is indeed a driver problem? Fun. [02:42:38 CET] <WireCat> i have like another stupid question :) [02:42:50 CET] <WireCat> the thing now says this /usr/bin/ld: /usr/local/lib/libavcodec.a(vc1dsp_mmx.o): relocation R_X86_64_PC32 against symbol `ff_pw_9' can not be used when making a shared object; recompile with -fPIC [02:44:27 CET] <SortaCore> add --CFLAGS=fPIC [02:44:41 CET] <furq> --extra-cflags [02:44:49 CET] <SortaCore> furq is hax [02:44:54 CET] <SortaCore> knows too much [02:45:16 CET] <furq> you could just use --enable-pic though [02:45:24 CET] <DHE> that looks like an ASM file being built though... does CFLAGS cover that? [02:45:36 CET] <furq> no idea and it seems hacky anyway [02:45:36 CET] <SortaCore> cwhadimean [02:46:00 CET] <furq> maybe --enable-shared is a better solution [02:46:09 CET] <WireCat> so instead of --static i do that? [02:46:31 CET] <SortaCore> furq, any idea how to get whether it's a video codec from AVCodec? [02:46:38 CET] <WireCat> i don't know much about this stuff, but i need to build the thing :/ [02:46:41 CET] <furq> i've never really used the libs [02:47:13 CET] <SortaCore> *urge to ask on ffmpeg-devel intensifies* [02:47:15 CET] <furq> WireCat: if you want a static build then try --enable-pic [02:48:08 CET] <WireCat> thank you, i will try [04:18:04 CET] <TheRock2> hi guys, i heard ffmpeg is better than handbrake, is that true ? [04:35:44 CET] <furq> that's like asking if a truck is better than a car [05:24:52 CET] <alexpigment> TheRock2: Handbrake is limited in what it can do (although it does have a command line for specific x264 options) [05:25:20 CET] <alexpigment> FFMPEG also uses x264, but it has a lot of filters which are not available in handbrake [05:25:59 CET] <alexpigment> lastly, some of the filters in Handbrake seem to do a better job (e.g. the detelecine option) [05:26:17 CET] <alexpigment> anyway, trucks vs cars ;) [05:42:55 CET] <furq> i was thinking more about the fact that handbrake can rip dvd and bluray [05:43:57 CET] <TheRock2> some say handbrake is good because it has gui [05:46:19 CET] <memi> hello. I have Analog-Digital video encoder with 2 inputs "composite video" and "s-video", attached to PC via USB. Can i switch input by ffmpeg util? [05:46:57 CET] <furq> that sounds like the sort of thing that v4l2 would do [05:47:20 CET] <furq> https://manpages.debian.org/stretch/v4l-utils/v4l2-ctl.1.en.html [05:47:37 CET] <furq> if you're on linux ofc [05:47:43 CET] <furq> on windows i have no idea [05:52:21 CET] <memi> unfortunatly, i need do this on windows. I think, that ffmpeg can do it, but not know, how search that mechanism. [05:57:16 CET] <furq> !indev dshow @memi [05:57:17 CET] <nfobot> memi: http://ffmpeg.org/ffmpeg-devices.html#dshow [05:57:30 CET] <furq> if it's not in there then i doubt ffmpeg can do it [07:25:20 CET] <memi> 2furq, Yes 'dshow' can do that. With option 'crossbar_video_input_pin_number' [09:04:49 CET] <baoxiang> Hi, when i execute ffmpeg to record as audio wav format: use the -sample_fmt u8, ffmpeg show that u8 is invalid,but i use ffmpeg -sample-fmts , u8 is in result? could any tell me why? [09:16:09 CET] <SortaCore> baoxiang, sample is not a codec [09:16:20 CET] <SortaCore> make sure you're specifying the audio codec [09:18:53 CET] <baoxiang> my command is : ffmpeg -y -i test.flv -f wav -ar 11025 -ac 1 -sample_fmt u8 -vn test.wav [09:19:32 CET] <baoxiang> the error is : Specified sample format u8 is invalid or not supported [09:20:56 CET] <baoxiang> when i use s16 , it execute successfully. [09:25:57 CET] <furq> baoxiang: the default codec for wav is pcm_s16, which obviously doesn't support u8 [09:26:02 CET] <furq> set -c:a pcm_u8 [09:26:26 CET] <furq> s/pcm_s16/pcm_s16le/ before someone more pedantic comes along [09:28:22 CET] <baoxiang> furq, thanks, "-c:a pcm_u8" works! [09:30:08 CET] <baoxiang> thanks SortaCore too. [12:13:47 CET] <funyun_> hi. i'm trying to compile ffmpeg using this guide https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu. when i get to the x264 part i get this error https://pastebin.com/cF9148eU anyone know what's wrong? [12:16:41 CET] <BtbN> you cannot link a static lib without PIC into a shared library. [12:18:17 CET] <funyun_> BtbN: so i should use sudo? [12:37:03 CET] <sfan5> no you need different build flags [12:38:12 CET] <JEEB> the person spammed it elsewhere and seems to have already gotten [12:38:14 CET] <JEEB> *gotten it [12:38:22 CET] <JEEB> the person also got me really confused by spamming it here too [12:38:29 CET] <JEEB> since I thought I was replying on #ffmpeg an not #x264 :P [12:39:11 CET] <funyun_> well i didn't "spam" it. i just asked once. sfan5: thanks [12:39:48 CET] <JEEB> posting the same thing on N channels is considered spamming [12:39:52 CET] <JEEB> even if you do it just once [12:42:49 CET] <durandal_1707> how would you know unless you are on all channels [12:42:58 CET] <funyun_> i see. sorry for spamming you guys. hope you can still see previous text from other users [13:02:13 CET] <funyun_> almost done. i'm trying the final step of compiling ffmpeg but i get this error "ERROR: libass not found using pkg-config". libass-dev is installed. anyone know what's wrong [13:02:44 CET] <JEEB> ffbuild/config.log [13:02:52 CET] <JEEB> at the end of it you should see the errored out check [13:12:34 CET] <dradakovic> Is it possible for ffmpeg to detect that input is not available anymore? I am inputing the http radio and outputting it as a multicast. But if an input drops for a moment then ffmpeg process will still run but output only silence. [13:13:21 CET] <dradakovic> i use -reconnect 1, reconnect_at_eof 1, -reconnect-streamed 1 and reconnect-delay-max 4249 [13:14:34 CET] <dradakovic> If i check the log file, i can see that it is not getting filled anymore. Tailf stays at the same time= played [13:15:23 CET] <zerodefect> I notice in the C-API, specifically in the AVFrame, there is a concept of 'channel_layout' for audio channels (it's a member of the struct). For say the #define 'AV_CH_LAYOUT_5POINT1', does ffmpeg assume that the channels are always in given/pre-specified order? Is this implicit knowledge? :) [13:19:43 CET] <funyun_> JEEB: https://pastebin.com/Tex0ni9s i have installed libpng-1.6.34 but still getting this error [15:04:32 CET] <shtomik> Hi to all guys, I'm developing some app build on libavdevice and ffmpeg libs at all, at the beginning so sorry about my English, please tell me, who can help me with some my code? I need an advice and review... Thanks to all [15:14:13 CET] <DHE> you'll have to ask a specific question before you can really get help with what you're trying to do [15:15:20 CET] <fx159159> Hey, is it possible that libvpx-vp9 massively overshoots the target bit rate if in realtime mode and the cpu is under high load? [15:16:10 CET] <JEEB> quite possible [15:16:16 CET] <JEEB> libvpx is not known to have a good rate control [15:16:22 CET] <JEEB> not to even mention VBV/HRD [15:17:42 CET] <fx159159> I'm using a res of 640x480, crf is 35 and target bitrate 300k [15:18:00 CET] <fx159159> vp9 results in 500kbit bit rate, vp8 achieves 190 with roughly the same settings [15:23:46 CET] <fx159159> Does a low frame rate hurt the effiency of vp8/9? [15:24:06 CET] <JEEB> I just don't know [15:24:19 CET] <JEEB> you're better off asking #vp8 (if I recall correctly that's the historical channel for libvpx) [15:27:42 CET] <fx159159> Ok, thank you [15:56:36 CET] <shtomik> Okay, I don't understand what do I wrong... I saw all examples, and read all API description, but I fave a trouble with output... My code: https://pastebin.com/50GpcaAA Trouble with output file with error: [flv @ 0x7f99a6807a00] Could not find codec parameters for stream 0 (Video: h264, none, 2000 kb/s): unspecified size [15:56:37 CET] <shtomik> Consider increasing the value for the 'analyzeduration' and 'probesize' options [15:57:30 CET] <shtomik> [h264 @ 0x7f99a6808000] decode_slice_header error non-existing PPS 0 referenced [15:58:01 CET] <JEEB> sounds like you just haven't gotten the parameter sets yet [15:58:04 CET] <JEEB> the decode shouldn't stop at that [15:58:23 CET] <JEEB> you just keep feeding it more data from the demuxer until you get your image :P [15:58:30 CET] <JEEB> if there are parameter sets there in the input [16:00:31 CET] <shtomik> ffprobe test.flv -> https://pastebin.com/qpaJ5V8s [16:01:28 CET] <shtomik> I set all params, and this error occurred for all file ;( [16:09:11 CET] <JEEB> shtomik: if you encoded it then it lacks the parameter sets. [16:09:28 CET] <JEEB> which go in-band with FLV [16:09:30 CET] <JEEB> IIRC [16:12:17 CET] <shtomik> Parameter sets? What don't I set?( [16:14:32 CET] <JEEB> are you setting this? http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/libx264.c;h=9c67c… [16:17:00 CET] <JEEB> since by your comments I figure that you encoded that FLV file? [16:19:20 CET] <shtomik> yeah [16:19:38 CET] <JEEB> yes to what? [16:19:40 CET] <shtomik> I grab avfoundation input and reencoding it with muxing [16:19:52 CET] <JEEB> ok [16:19:57 CET] <JEEB> and what about the flag? [16:19:58 CET] <shtomik> to flv output [16:20:15 CET] <shtomik> Now i try to set the flag, thanks ;) 1 min please [16:20:33 CET] <JEEB> no, you want the repeated headers for that output format (FLV) [16:20:39 CET] <JEEB> since it's all in-band [16:20:50 CET] <JEEB> I was asking if you were already setting the flag :P [16:21:09 CET] <fx159159> When having an input/output framerate of 15 and a GOP of 45 every 3 seconds a webm chunk is emitted, now doubling the input rate to 30 and staying with output rate 15 and GOP 45, whats the expected interval for webm chunks? [16:21:22 CET] <fx159159> Still 3 sec or 1,5 sec? [16:27:26 CET] <shtomik> JEEB: AV_CODEC_FLAG_GLOBAL_HEADER is set [16:27:50 CET] <JEEB> shtomik: that has to be set depending on the output format [16:28:15 CET] <JEEB> so FLV -> no global header, MP4 -> global header used [16:28:17 CET] <JEEB> for example [16:29:53 CET] <shtomik> This does not solve my question ;( [16:30:36 CET] <JEEB> ok [16:31:16 CET] <JEEB> without that header the encoder is told to output annex b style packets *and* include the parameter sets in the packets [16:31:17 CET] <shtomik> Oh... wait... [16:31:50 CET] <JEEB> while WITH that flag you are telling the encoder to just give you the parameter sets separately into the extradata [16:32:01 CET] <JEEB> and then not repeat them [16:32:14 CET] <JEEB> you need to either set or not set the flag depending on the output format [16:32:23 CET] <JEEB> as I said, FLV needs the stuff in-band [16:32:30 CET] <JEEB> MP4 needs it out-of-band [16:32:34 CET] <JEEB> capisci? [16:33:38 CET] <JEEB> shtomik: you can decide it with https://ffmpeg.org/doxygen/trunk/structAVOutputFormat.html#aad55a00e728a020… I think? [16:33:47 CET] <JEEB> although let me double-check [16:34:19 CET] <JEEB> wait why does it say global header... [16:34:53 CET] <JEEB> ok, so flvenc calls ff_isom_write_avcc [16:35:03 CET] <JEEB> so I was completely incorrect? [16:35:09 CET] <JEEB> I don't even what is this :P [16:35:37 CET] <shtomik> I unset that flag(global header for flv) [16:36:03 CET] <shtomik> and ffprobe now finish without errors ;) [16:36:11 CET] <JEEB> that's how I expected it to work [16:36:28 CET] <JEEB> but I will have to check why the code looks like it does [16:36:51 CET] <JEEB> shtomik: were you writing the header in your code? [16:36:59 CET] <JEEB> there's an avformat function for that [16:37:17 CET] <shtomik> I want to try with mp4 now [16:37:34 CET] <shtomik> I don't... for flv [16:37:40 CET] <JEEB> ok, that explains [16:37:48 CET] <JEEB> you should always call that function [16:38:01 CET] <JEEB> it's expected to be called before you start writing packets [16:38:08 CET] <JEEB> whether or not it actually does something useful depends on the format [16:40:27 CET] <shtomik> yeah... with global header I have all problem [16:41:44 CET] <JEEB> ok, if you are not always calling avformat_write_header() please do that [16:41:57 CET] <JEEB> and no, "global header" is a thing you do with mp4 for example [16:41:59 CET] <JEEB> or matroska [16:42:23 CET] <JEEB> FLV seems to support both, and MPEG-TS is without global headers :P [16:43:17 CET] <shtomik> Can you review my code please? [16:44:26 CET] <shtomik> my output files is not play back... but i don't have errors... [16:45:09 CET] <JEEB> I have my own code to work on, so no. just make sure that you've opened the muxer, added the streams you need and then initialize and write required headers with avformat_write_header [16:45:16 CET] <JEEB> then start writing the packets [16:46:09 CET] <JEEB> and then whether or not to use the global header stuff you can see by looking at the output format's #define AVFMT_GLOBALHEADER 0x0040 /**< Format wants global header. */ [16:46:14 CET] <JEEB> fromt the flag variable [16:46:29 CET] <JEEB> if it needs you add that to your encoding parameters, if it doesn't you don't [16:46:58 CET] <shtomik> I done it... ;( [16:47:59 CET] <JEEB> https://ffmpeg.org/doxygen/trunk/transcoding_8c-example.html [16:48:03 CET] <JEEB> then compare [16:50:08 CET] <shtomik> I write my test from that example ;) [16:50:54 CET] <shtomik> my test is not big ;) it's not a working or production code... [18:42:35 CET] <neverminder> Hi. My pulseaudio default sample format is set to 32bit, but ffmpeg always shows input as 16bit, why is that? [18:44:15 CET] <BtbN> I'd guess because it doesn't have more precision [18:44:41 CET] <neverminder> can you elaborate, please? is there a way to fix that? [18:45:37 CET] <BtbN> What's your source? Does it even have 32bit? [18:46:24 CET] <neverminder> my source is external audio interface, so I'm pretty sure it does [18:47:51 CET] <neverminder> sorry, I might have been wrong, just opened a spec, says "96 KHz, 24-bit conversion" [18:49:24 CET] <neverminder> would I be able to convince ffmpeg to get input as 24bit then? [18:50:19 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#pulse [18:50:53 CET] <JEEB> it has sample rate there but not sample format [18:52:15 CET] <JEEB> oh of course [18:52:19 CET] <neverminder> so it can't be done? [18:52:31 CET] <JEEB> because it's an audio codec as we're dealing with avformat like abstraction [18:53:18 CET] <JEEB> -c:a pcm_s24le before -i ? [18:53:27 CET] <JEEB> if that works [18:54:09 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavdevice/pulse_audio_dec.… [18:54:56 CET] <neverminder> JEEB, that's briliant, it works, thanks [18:55:58 CET] <JEEB> as a really personal note, I really hate how avdevice is structured because it's all about AVPackets and not AVFrames for raw capture devices :< but alas, that's how it will be. [18:56:37 CET] <neverminder> well I hate it too now, just one more thing to hate =] [19:23:19 CET] <Stadtpirat> Hey guys, I ripped a DVD and want to encode it to x264. I need to crop it some pixels since the edges are blurred out and too bright. I made a screenshot with VLC and loaded it into photoshop. There, the crop area is 1010x430. The weird thing is, vlc tells me the resolution is 720*576. [19:23:41 CET] <Stadtpirat> I read that this might be because it has some funny SAR DAR values. ffprobe tells me this: Stream #0:0(eng): Video: mpeg2video (Main), yuv420p(tv, top first), 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 1k tbn, 50 tbc [19:23:59 CET] <sfan5> yes that's due to the SAR [19:24:11 CET] <JEEB> yes, the actual video is either 720x480 or 720x576 with an aspect ratio flag [19:24:12 CET] <Stadtpirat> I tried for a long time to just get square pixels and make the video the original resolution. (no crop yet). I don't want to reencode eyet. [19:24:35 CET] <JEEB> you can check it out with vapoursynth editor if you want to look at how it looks [19:24:47 CET] <JEEB> and then plan cropping and IVTC/deint [19:25:06 CET] <Stadtpirat> it's not interlaces, gladly. [19:25:13 CET] <Stadtpirat> But is there a way to do all this with ffmpeg? [19:25:16 CET] <sfan5> yes [19:25:59 CET] <JEEB> it's just that it's hard to preview with just ffmpeg.c [19:26:25 CET] <sfan5> though i'm wondering why ffmpeg says "top first" if your source is not interlaced [19:26:30 CET] <Stadtpirat> I tried to "-vf setsar=sar=1" but then it changes the aspect ratio. I tried "-vf setsar=sar=1,setdar=dar=16/9" but then nothing happens [19:26:44 CET] <illegal> how do I add fonts to a mkv with ffmpeg? I keep getting attachment stream 3 has no minetype or font doesn't exist [19:26:44 CET] <Stadtpirat> oh, maybe it is then. didn't look like it when watching [19:26:47 CET] <JEEB> the aspect ratio is already correctly ('ish) read [19:26:47 CET] <sfan5> well yeah you can't just "set" these, you need to scale [19:26:57 CET] <sfan5> (if you absolutely want a 1:1 SAR) [19:27:06 CET] <illegal> ffmpeg -i "vd.mkv" -codec copy -attach "OpenSans-SemiBold.ttf" -metadata mimetype=application/x-truetype-font "out.mkv" [19:27:12 CET] <Stadtpirat> But scale would mean a quality loss, right? [19:27:21 CET] <sfan5> not necessarily [19:27:24 CET] <Stadtpirat> like scaling a picture in photoshop [19:27:48 CET] <JEEB> well yes it is no longer original. if you don't want to touch the image just crop it and the SAR should stay correct [19:28:05 CET] <JEEB> just find out the correct amount of crop with vapoursynth editor or something [19:29:24 CET] <sfan5> -vf "scale=1024:576,setsar=1/1" is what I meant by scaling [19:29:39 CET] <JEEB> yes [19:29:51 CET] <JEEB> that will stretch the thing like the video player would [19:32:15 CET] <alexpigment> the crop can be derived pretty easily by the way. your original display width is 1024x576 (pal 16x9) and the crop version is 1010x430. simple algebra says that the actual cropped resolution should be 710x430, which means you need to crop 10 from the sides and 50 from the top and bottom (assuming they're completely even) [19:32:45 CET] <alexpigment> and honestly, for that amount, I wouldn't even worry about the crop. it's going to be letterboxed anyway and there are only a small amount of pixels on the left and right [19:33:27 CET] <alexpigment> people will say that you waste a lot of bits on the left and right, but I don't think that's really true anymore unless you just have noisy letterboxing or VHS lines (I'm guessing you don't) [19:34:48 CET] <Stadtpirat> sfan5, just so I understand this correct. The picture is actually 720/576, while stretched by the player to 1024. This means that for that particular DVD, those missing 304 pixels each line are interpolated ANYWAY? [19:35:14 CET] <alexpigment> 720 is stretched to 1024 for 16x9 PAL DVDs [19:35:41 CET] <JEEB> (there's some extra details there that I will leave out because it will get newbies just even more confuzzled) [19:35:49 CET] <alexpigment> because 720x576 is 1.25:1, which is not a standard for anything [19:35:56 CET] <sfan5> the picture is not 720x576, the stored pixels are [19:36:14 CET] <Stadtpirat> alexpigment, I want to crop because I hate that the letterbox is a slightly brighter than true black, which makes it visible on my vlc player, when i watch it [19:36:18 CET] <sfan5> but the pixels are non-square, so for display on a computer it will need to be streched according to the SAR which results in 1024x576 [19:36:31 CET] <JEEB> you can just get confuzzled by teh sar value mentioned here ;) http://www.x264bluray.com/home/576p-pal [19:36:46 CET] <JEEB> (and yes, that is based on the SD BD spec which bases on the DVD spec) [19:36:46 CET] <alexpigment> Stadtpirat: ok, it's your call. the vertical resolution isn't stretched, so that's a pretty simple crop [19:37:07 CET] <Stadtpirat> alexpigment, yeah, but thanks anyway :) helped me understand [19:38:30 CET] <alexpigment> no problem [19:39:37 CET] <Stadtpirat> But about the interlaced thing. I don't spot any interlace lines, even in very quick movements. Should I deinterlace the video somehow anyway? [19:39:56 CET] <alexpigment> Stadtpirat: you mentioned that the letterbox is brighter than true black. you don't have an nvidia graphics card, do you? [19:40:13 CET] <JEEB> Stadtpirat: if you don't see any stuff in movement then try just adding fieldmatch there just in case [19:40:16 CET] <JEEB> that should do it [19:40:16 CET] <sfan5> "bright than true black" could just be vlc being stupid [19:40:30 CET] <sfan5> also VLC may deinterlace automatically [19:40:31 CET] <alexpigment> if it's pal, it's proabably 1 field per field. 25% speedup [19:40:50 CET] <alexpigment> vlc doesn't deinterlace by default still [19:40:55 CET] <Stadtpirat> alexpigment, nvidia, yes [19:40:57 CET] <alexpigment> it treats interlacing like it doesn't exist [19:41:13 CET] <alexpigment> Stadtpirat: it's because VLC is horrible and doesn't know how to deal with Nvidia's color settings [19:41:19 CET] <sfan5> i see, wasn't sure whether the defaults have changed recently [19:41:30 CET] <alexpigment> sfan5: not to my knowledge, but i could be wrong [19:42:02 CET] <Stadtpirat> to be fair, nvidia doesn't know how to deal with color settings. [19:42:34 CET] <Stadtpirat> okay, i could follow with the sar/dar thing. I don't understand a word about the interlace stuff. I think I'll just leave it at that [19:42:42 CET] <alexpigment> Stadtpirate: go into the Nvidia Control Panel > Video > Adjust Video Color Settings > "With the Nvidia Settings" > Advanced and set it to Full (0-255) [19:43:02 CET] <Stadtpirat> btw, this is my filter now. works really well: -vf "scale=1024:576,setsar=1/1,crop=1010:430" [19:43:05 CET] <Stadtpirat> alex, its full. [19:43:33 CET] <alexpigment> Stadtpirate: still, I'd guess VLC is just being dumb. I'd personally use a real media player and confirm whether the letterboxing is the wrong color first [19:44:09 CET] <JEEB> just use vapoursynth editor or so :P [19:44:18 CET] <JEEB> vapoursynth uses zimg internally [19:45:33 CET] <alexpigment> Stadtpirate: PAL video is 25fps interlaced. film is 24fps progressive. Instead of trying to convert that framerate through doubling, they often just speed the movie up by 4% so that 24 turns to 25fps. in this case, each field will be the same, so there won't be any interlacing lines by default. having said that, i'm not sure whether ffmpeg blends the frames by default when converting to progressive or if it drops every other field completely [19:45:33 CET] <alexpigment> (thereby losing vertical resolution) [19:46:15 CET] <alexpigment> JEEB would know best on that [19:47:31 CET] <JEEB> well you've kind of started from the wrong side to begin with [19:47:45 CET] <alexpigment> me? [19:47:46 CET] <Stadtpirat> oh god ^^ [19:47:49 CET] <JEEB> you start by opening the content in either AvsP or vapoursynth editor or whatever sane that lets you go through the clip [19:47:55 CET] <Stadtpirat> alexpigment, the windows 10 video app shows true black [19:47:55 CET] <alexpigment> oh [19:47:55 CET] <Stadtpirat> hm [19:48:12 CET] <alexpigment> Stadtpirat: I assumed so. It's a real media player :) [19:48:14 CET] <Stadtpirat> okok, ill get the vaporthin :) [19:48:20 CET] <Stadtpirat> I always thought vlc is really good [19:48:27 CET] <Stadtpirat> what would you recommend [19:48:48 CET] <alexpigment> VLC is the worst in almost every aspect. the only benefit to VLC is it plays most everything, even if it doesn't play them correctly [19:48:50 CET] <JEEB> for video rendering mpv is my recommendation [19:49:02 CET] <JEEB> alexpigment: VLC is really good with broadcast sources though [19:49:17 CET] <alexpigment> JEEB: not if they're interlaced (which most are in the US) [19:49:25 CET] <JEEB> no, I mean with the MPEG-TS layer [19:49:30 CET] <JEEB> and deint seemed to work the last I checked [19:49:32 CET] <JEEB> :P [19:49:43 CET] <JEEB> although I've mostly tested the 3.0 nightlies during the last few years [19:49:47 CET] <JEEB> because the 2.2 branch is ancient by now [19:50:17 CET] <Stadtpirat> I'll try mpv, thanks. and I need to go now. I'll check the vaporstuff later. thanks a lot for the explanation. i think you all just wasted your time :D [19:50:22 CET] <alexpigment> i work primarily with broadcast content and I can confirm that the deterlacing in VLC sucks, because Yadif2x is the best you can do, and it can't perform smoothly on most computers [19:50:26 CET] <Stadtpirat> in all seriouslyness, thanks, it helped [19:50:50 CET] <alexpigment> I really like Windows Media Player as a non-fullscreen player, and I like Kodi as a fullscreen player [19:50:54 CET] <JEEB> alexpigment: oh? never noticed that. I've been dealing with 1080i25/30 stuff (50/60 fields per sec) [19:51:06 CET] <alexpigment> both of those are due to interlacing and scaling performance [19:51:08 CET] <JEEB> although as I said I really haven't used vlc 2.2 [19:51:13 CET] <JEEB> in years by now [19:52:06 CET] <alexpigment> JEEB: in my experience, it takes a beefy system to do Yadif2x without dropping frames. but the other thing is that if you have something that's completely round, VLC will show stairstepping when deinterlacing [19:52:37 CET] <alexpigment> and damn, if I could figure out what the hell awful scaling is happening with 720x480 SD content, I might actually find more use for it from time to time [19:53:08 CET] <JEEB> yea the video rendering part is something that was not really up to snuff with 2.2 (no idea about 3.0 where the rewrote a whole crapload of stuff during the N years of development) [19:53:17 CET] <JEEB> mpv's renderer is the one I have most trust right now [19:53:53 CET] <alexpigment> i'm using 3.0, but haven't noticed any benefits or improvements in the short time i've used it [19:53:59 CET] <JEEB> ok [19:54:02 CET] <JEEB> oh well [19:54:10 CET] <alexpigment> MPV would be really nice, but the automatic deinterlacing script doesn't work for me [19:54:13 CET] <JEEB> too bad since the demuxing is pretty good [19:54:23 CET] <JEEB> I just press 'd' if my content is interlaced [19:54:34 CET] <JEEB> since yadif with field speed is OK for me [19:54:37 CET] <alexpigment> and the deinterlacing methods feel subpar [19:54:48 CET] <JEEB> you could use any of the libavfilter ones [19:54:51 CET] <JEEB> there's like three or four now [19:54:58 CET] <JEEB> not sure if DXVA2 deint is usable [19:55:02 CET] <JEEB> which would use whatever the GPU does [19:55:16 CET] <alexpigment> DXVA2 would be ideal if i had access to it through MPV [19:55:18 CET] <alexpigment> maybe that's changed [19:55:27 CET] <alexpigment> that's what i use in Kodi [19:55:27 CET] <JEEB> hwdec is there but not sure about deint [19:55:43 CET] <JEEB> the problem with dxva2 deint is that it's really easy to get whatever the driver decided to /also/ include with that [19:55:52 CET] <JEEB> random post-processing etc [19:56:02 CET] <JEEB> will have to check with rossy I guess [19:56:03 CET] <alexpigment> and honestly, pressing d seems pretty minor, but if almost every single video you play is interlaced, it doesn't seem worth it [19:56:57 CET] <alexpigment> JEEB: i'm assuming the driver isn't applying a bunch of random crap that makes the video worse (and if it is, I can disable it through a control panel). i'd be ok if it was deint+whatever [19:57:19 CET] <JEEB> I've dealt with DirectShow and MF and that used to be a complete mess depending on the vendor [19:57:33 CET] <JEEB> like nvidia auto-enabling color fucking and filtering if you had a "TV" connected [19:57:48 CET] <JEEB> AMD just had random "color correction and stuff" enabled by default [19:57:55 CET] <alexpigment> yeah, AMD is bad about fucking with the color [19:58:02 CET] <JEEB> intel seemed to depend on the driver [19:58:10 CET] <alexpigment> with nvidia it's just the full/limited thing that's mainly where players don't handle it properly [19:58:21 CET] <JEEB> nah, this was not related to the full/limited thing [19:58:27 CET] <alexpigment> intel has its own quirk that i can't recall. i think it's also related to full/limited [19:58:30 CET] <JEEB> it would actually auto-enagle post-processing [19:58:43 CET] <JEEB> the full/tv range stuff is separate altogether [19:59:06 CET] <JEEB> and as someone who had to support a playback package it was a mess [19:59:13 CET] <alexpigment> i haven't seen post processing stuff be set to anything but neutral, but ymmv [19:59:14 CET] <JEEB> so mpv's rendering not being affected by any of that BS was just bliss [19:59:22 CET] <JEEB> oh trust me [19:59:30 CET] <JEEB> I should pull the darn forum back up [19:59:35 CET] <JEEB> there was plenty of crap [19:59:39 CET] <JEEB> from various years, various versions [19:59:58 CET] <JEEB> as I noted the exact logic they used to or still do changes according to driver versions [20:00:10 CET] <alexpigment> i mean i trust you fully. i just haven't personally dealt with it [20:00:24 CET] <alexpigment> anyway, gotta run for a bit [20:02:33 CET] <JEEB> as an extra even directaudio was not free of bullshit. asus xonar and some other vendor that mimic'd it used to just force-load a filter into directaudio if it was called the usual way [20:02:45 CET] <JEEB> and it would always apply filtering - even if it didn't know the sample format [20:03:07 CET] <JEEB> > audio decoder outputs float > forcibly inserted audio filter fscks it up [20:57:15 CET] <alexpigment> JEEB: yeah, i've seen audio cards do filtering by default. that's one of the reasons I only install drivers via inf files on windows [20:57:49 CET] <alexpigment> just give me the basics. i don't need a control panel that gives me options for "stadium echo" on my fucking sound card ;) [20:58:37 CET] <JEEB> I actually found out the registry entry that enabled that crap in the driver and asked in an installer if the user wants to disable that bit [20:58:57 CET] <JEEB> meanwhile foobar2000 just uses directaudio in some weird-ass manual loading way which conveniently skips the place where those drivers plug in [20:59:20 CET] <alexpigment> well fortunately audio is pretty simple [20:59:23 CET] <JEEB> yea [20:59:38 CET] <JEEB> I think I herped a derp at intel if I recall correctly [20:59:40 CET] <alexpigment> video, on the other hand, has a lot of things that need to be addressed, otherwise it's wrong [20:59:55 CET] <JEEB> to find out how I could check if their "added value" filtering was enabled or not [21:00:22 CET] <JEEB> I don't think I ever got an answer [21:01:07 CET] <alexpigment> well, it *is* intel. they're way too big to even make time for the little guys [21:01:18 CET] <alexpigment> "little guys" [21:01:26 CET] <alexpigment> almost everyone is little to them [22:05:17 CET] <vush> hello #ffmpeg community, im new in this channel :):(:? [22:06:26 CET] <therage3> hi [22:07:57 CET] <vush> what are you up to? [22:57:46 CET] <SortaCore> JEEB, any idea how to check if an AVCodec is video? [22:59:17 CET] <JEEB> https://www.ffmpeg.org/doxygen/trunk/structAVCodec.html [22:59:19 CET] <JEEB> third from top [23:00:16 CET] <SortaCore> delectable [23:01:47 CET] <JEEB> ? [23:21:33 CET] <SortaCore> so MPEG4, are those containers... [23:21:54 CET] <DHE> if they're part of libavcodec, then no. if they're part of libavformat, then yes [23:24:58 CET] <SortaCore> I want the user to be able to select a container, video, audio [23:26:44 CET] <SortaCore> so ideally I can just find all the codecs that were in the ffmpeg static library [23:28:05 CET] <DHE> there's a codec iterator option, yeah... [23:31:54 CET] <kepstin> there is, however, no way to tell whether you can put x codec in y container without actually trying to do it :/ [23:39:49 CET] <SortaCore> why not kepstin? [23:40:16 CET] <kepstin> because the api do to that is not fully implemented, so for most codec/container combinations it just returns "maybe" [23:42:47 CET] <SortaCore> why it no implemented [23:42:56 CET] <BtbN> because nobody implemented it [23:44:22 CET] <SortaCore> why nobody implemented [23:49:46 CET] <SortaCore> how do I iterate containers? [23:50:02 CET] <SortaCore> av_oformat_next [00:00:00 CET] --- Fri Dec 15 2017

1 0

ffmpeg-devel.log.20171213
by burek 14 Dec '17

14 Dec '17

[00:19:39 CET] <cone-650> ffmpeg 03James Almer 07master:0e2fbd68e279: avformat/mux: factorize AVFormatContext->avoid_negative_ts initialization [00:32:36 CET] <cone-650> ffmpeg 03Jun Zhao 07master:4280948702bc: avfilter/formats: fix wrong function name in error message [01:38:47 CET] <cone-650> ffmpeg 03Aman Gupta 07master:88e2dc7d0448: libavcodec/mpegvideo_parser: improve detection of progressive mpeg2 [10:43:47 CET] <atomnuker> "in extremely sensitive medical, military and enterprise applications" [10:44:34 CET] <atomnuker> so this is the most EXXXXTTIME!1!! existing protocol? [10:45:56 CET] <atomnuker> "We see a dramatic adoption of the protocol in the market" <- is that guy seriously trying to market it this way on the ml? [10:45:59 CET] <durandal_1707> should all rgb decoders set color range to full pc? [10:47:34 CET] <atomnuker> absolutely, we do not currently support limited range rgb (which does exist but only on hdmi and sdi afaik) [10:49:14 CET] <durandal_1707> they dont [10:51:01 CET] <atomnuker> yep, so that's why they should set the range to full [10:51:09 CET] <nevcairiel> even the hdmi spec calls it invalid, but some devices still accept it [10:51:13 CET] <nevcairiel> or even expect it [11:18:57 CET] <kierank> atomnuker: lol [11:19:10 CET] <kierank> Marketing [11:27:41 CET] <wm4> nevcairiel, atomnuker: yes, some devices apparently expect limited range rgb [11:27:49 CET] <wm4> which is fucked up, but ok [11:34:53 CET] <jkqxz> HDMI assumes limited range for CE modes and full range for IT modes. [11:34:59 CET] <jkqxz> It's definitely not invalid. [11:35:18 CET] <jkqxz> (Fun question: is 1920x1080 a CE mode or an IT mode?) [11:35:48 CET] <cone-703> ffmpeg 03Martin Vignali 07master:46f534bdee34: avfilter/vf_hflip : move context func init in ff_hflip_init [11:35:49 CET] <cone-703> ffmpeg 03Martin Vignali 07master:cefb7e00608d: checkasm/vf_hflip : add test for vf_hflip byte and short simd [11:36:01 CET] <nevcairiel> HDMI also assumes YCbCr in CE modes however [11:36:13 CET] <nevcairiel> consumer devices dont give you rgb [11:38:32 CET] <nevcairiel> anyway limited range rgb is still just weird [11:38:37 CET] <jkqxz> Is that a requirement in HDMI 2? That's not in HDMI 1.4. [11:39:34 CET] <jkqxz> Sinks are allowed to be RGB-only in 1.4 (with suitable EDID). [11:39:49 CET] <nevcairiel> its supposed to default to YCbCr anyway if nothing restricts that [11:40:08 CET] <jkqxz> True, but it's not required to be possible. [12:26:15 CET] <cone-703> ffmpeg 03Kelly Ledford 07master:bc219082bb04: libavfilter/af_dcshift.c: Fixed repeated spelling error [12:26:16 CET] <cone-703> ffmpeg 03Kelly Ledford 07master:309ddcbe6166: patcheck: Add 'threshhold' to common typo list [12:49:51 CET] <rcombs> michaelni: presumably to have a FATE test for the matroska issue, we'd need to add a sample (since it only triggers on corrupt data) [12:50:07 CET] <rcombs> I don't have a small sample, but I guess I could fuzz one [13:16:43 CET] <michaelni> rcombs, if you have a small sample that i should upload then ping me [16:12:02 CET] <cone-072> ffmpeg 03Tristan Matthews 07master:e8f0a463b0d2: ivfenc: add AV1 support [16:48:55 CET] <durandal_1707> why not opengl generic shader filter? vulkan is immature. [16:52:36 CET] <BtbN> Because OpenGL is bad [16:52:47 CET] <BtbN> It would be a nightmare to do OpenGL filters with its global state [16:52:48 CET] <jkqxz> OpenGL is a horrible mess of global state. How do you set up the OpenGL context and avoid libavfilter interfering with anything else running in the program? [16:53:12 CET] <BtbN> Well, I guess you could have a private internal context? [16:54:14 CET] <atomnuker> durandal_1707: you're immature, vulkan is perfectly equipped for everything [16:55:09 CET] <durandal_1707> using glfw [16:55:52 CET] <durandal_1707> vulkan is dangerous it can erupt at any given time [16:56:10 CET] <mateo`> glfw does not support Android or iOS [16:57:00 CET] <durandal_1707> im gonna cry now [16:57:09 CET] <atomnuker> durandal_1707: no, it can't, proprietary junk driver can though [16:57:14 CET] <mateo`> but implementing a backend for each os is not that difficult [16:57:43 CET] <atomnuker> *534 [16:57:50 CET] <ubitux> say that to apple [16:57:51 CET] <jkqxz> I guess it depends on what the use-case for it actually is. [16:58:34 CET] <jkqxz> If all you want is to be able to write stuff in GLSL rather than C, then keeping it internal to lavfi could work. [16:58:54 CET] <atomnuker> our just use vulkan with glslang [16:59:02 CET] <wm4> <jkqxz> OpenGL is a horrible mess of global state. How do you set up the OpenGL context and avoid libavfilter interfering with anything else running in the program? <- you can use a different thread [16:59:13 CET] <wm4> glslang sucks and has global state [16:59:53 CET] <jkqxz> If the point is to actually make things faster for weak devices then you want all the device management and interop. [17:02:10 CET] <durandal_1707> so how would one do vulkan custom filtering when glslang have global state? [17:03:55 CET] <rcombs> you can also store the current context, switch to a different one, do your GL shit, and then switch back [17:03:57 CET] <rcombs> I think [17:05:03 CET] <rcombs> fuck global state though [17:05:09 CET] <rcombs> and fuck thread-local state too [17:05:42 CET] <BtbN> for interop you can share between an external and an internal context [17:09:40 CET] <durandal_1707> actually there is already glfw filter for ffmpeg on github [17:11:47 CET] <durandal_1707> atomnuker: should asynth filter use AVExpr or something else? [17:16:09 CET] <wm4> rcombs: some OS APIs for this force flushing the GL context on switch, so it's not entirely transparent [17:32:28 CET] <rcombs> wm4: lovely [18:08:23 CET] <nevcairiel> some recent-ish extensions let you control the forced flush on switch [18:11:27 CET] <wm4> yeah [18:13:35 CET] <BtbN> properly done OpenGL/GLSL filters would be nice. There is interop for pretty much every other API [18:17:03 CET] <atomnuker> there's opencl which is better [18:17:40 CET] <durandal_1707> you can use shaders with it? [18:18:00 CET] <BtbN> opencl lacks interop with CUDA, and I wouldn't be surprised if it also lacks it for stuff on osx [18:20:05 CET] <jkqxz> durandal_1707: Pixel shaders, sure. See the "run arbitrary pixel shader program" filter which still isn't applied. [18:20:52 CET] <durandal_1707> why it isnt applied ? [18:21:13 CET] <jkqxz> BtbN: I would be fine with a good OpenGL implementation with interop. It's just I'm pretty unsure what that would actually look like. [18:21:39 CET] <BtbN> pretty similar to the current map stuff [18:21:48 CET] <BtbN> you can map a GL texture to pretty much every hw format [18:21:49 CET] <jkqxz> And a hacky thing looking like the old OpenCL implementation would not be good. [18:22:27 CET] <jkqxz> I'm more thinking of how devices, frames and context management might work. [18:25:07 CET] <jkqxz> durandal_1707: Carl had concerns about it running arbitrary code, and whether it's making something like vhook (which was removed a long time ago). [18:25:25 CET] <wm4> wat [18:25:32 CET] <BtbN> a filter intended to run arbitrary shaders can run arbitrary code! Oh my god. [18:25:33 CET] <durandal_1707> carl should be ignored [18:25:35 CET] <wm4> as usual he's full of shit [18:25:53 CET] <BtbN> Just don't allow it to download filters from the net [18:26:13 CET] <BtbN> Carl also wants me to change an nvenc option to work exactly like it does in x264, even though it just doesn't... [18:26:14 CET] <jkqxz> I just pushed the set without it. [18:26:33 CET] <jkqxz> Because I wasn't feeling like spending more time on it. [18:28:01 CET] <jkqxz> It loads from a local file only. That is a bit ugly if someone can convince it to load a sensitive file, because something might be revealed in the compiler error messages. [18:28:38 CET] <BtbN> easy, only log them to a local file as well [18:28:48 CET] <BtbN> that way, if someone were to read it, they'd have access anyway [18:34:11 CET] <jkqxz> Writing local files isn't so good either. [18:34:48 CET] <jkqxz> And that stuff really should be in the normal log. [18:35:44 CET] <wm4> it's a complete non-argument anyway [19:11:36 CET] <Dis> Hi, from ffmpeg mp4 muxer code it looks like the senc item is written into the stbl box instead of traf box. Because of this issue, I observe macroblocks. Hence I moved the senc atom to traf atom but after this change I get senc duplicate atom. Did anyone observe this? thanks in advance [19:57:04 CET] <atomnuker> BBB: yeah, that alignment was weird so I amended it [20:41:11 CET] <philipl> BtbN: ignore Carl? [20:41:34 CET] <BtbN> that's my plan so far [20:41:49 CET] <BtbN> But I suspect he will come up with a patch for it [20:42:42 CET] <philipl> That would surprise me, but then you can NAK it, and someone can call a vote, and it will end up with nothing happening. As long as "do nothing" gets you what you want, the system is very effective. [20:43:58 CET] <philipl> jkqxz: Repeating a question you probably didn't see, does Paul's yuvj removal changeset also remove your yuvj problem with the mjpeg hooks? [21:53:26 CET] <tmatth> BBB: are you frowning at me for av1 muxing or continued ternary abuse? [21:53:40 CET] <BBB> continued ternary abuse [21:53:44 CET] <tmatth> that is fair [21:53:51 CET] <BBB> Id prefer a LUT or something [21:53:56 CET] <tmatth> yeah [21:54:50 CET] <BBB> (or reuse the fourcc LUTs) [21:54:59 CET] <BBB> av1 muxing is awesome [21:55:02 CET] <BBB> (and demuxing) [23:23:52 CET] <durandal_1707> michaelni: the experimental limited support in mjpeg is broken, it should be either fixed or removed [23:29:26 CET] <cone-274> ffmpeg 03Michael Niedermayer 07master:f7617d4b83c0: libavcodec/decode: remove duplicate includes [23:30:09 CET] <michaelni> durandal_1707, what broke it ? [23:32:38 CET] <durandal_1707> michaelni: it doesnt insert required metadata [23:32:51 CET] <durandal_1707> flag of some sort [23:34:00 CET] <durandal_1707> it was never correct, so it is experimental [23:38:00 CET] <michaelni> it should store "CS=ITU601" in jpeg_put_comments() [23:39:31 CET] <wm4> which applications understand this [23:39:32 CET] <michaelni> and it seems to still do that here [00:00:00 CET] --- Thu Dec 14 2017

1 0

ffmpeg.log.20171213
by burek 14 Dec '17

14 Dec '17

[00:09:48 CET] <ArsenArsen> how do I set the avfoundation video frame location? [01:13:15 CET] <illegal> https://trac.ffmpeg.org/ticket/5718 Is there a way to encode with opus with a surround sound input? according to teh last comment none of the methods work, why isn't this default anyways if every other audio encoder doesn't have this problem if I may ask? it certainly doesn't happen with aac [01:24:32 CET] <furq> illegal: -af channelmap worked last time i tried [01:24:42 CET] <furq> also iirc this is dependent on the input format layout [01:24:58 CET] <furq> the only time it's come up in here was with a dts input and i couldn't reproduce it with anything else [01:28:08 CET] <alexpigment> illegal: sorry to ask this qusetion as it's really a tangent, but why opus? [01:28:35 CET] <furq> why not [01:28:51 CET] <alexpigment> presumably you've got a source format you're encoding from, presumably it's from a video, and presumably there's no real benefit to transcoding [01:28:55 CET] <furq> illegal: channelmap definitely still works with 3.3.4, i don't have a 3.4 build here to test with [01:29:16 CET] <alexpigment> (i realize i'm presuming a lot) [01:29:18 CET] <illegal> furq, af thing apparently worked after updating again to a new nightly just now [01:29:23 CET] <furq> fun [01:29:26 CET] <illegal> but still shouldn't this be done by default? [01:29:29 CET] <furq> yeah [01:29:44 CET] <furq> it used to be done by default, there's some regression that nobody's bothered fixing because there's a workaround [01:30:19 CET] <furq> all of my knowledge of this is from the bug report that you linked and have presumably read [01:30:23 CET] <furq> so i can't really add much [01:30:31 CET] <illegal> alexpigment, I like it better than aac, at least my ears did when I did some test nothing much to be honest, is also free as in open sores. [01:30:43 CET] <alexpigment> illegal: sure, but what's your source audio format? [01:30:43 CET] <furq> if it is dts then you'll get a significant rate saving [01:30:45 CET] <alexpigment> ac3? [01:30:56 CET] <illegal> furq, I am not encoding from dts mainly from flac which probably came from a dts source [01:31:03 CET] <furq> oh right [01:31:08 CET] <furq> 5.1 flac is even bigger [01:31:09 CET] <alexpigment> ok, flac to opus makes sense [01:31:14 CET] <alexpigment> i'll stop asking now ;) [01:31:17 CET] <furq> dts to opus makes some sense really [01:31:29 CET] <alexpigment> sure, i was just making sure it wasn't lossy to lossy [01:31:37 CET] <furq> regular dts is lossy [01:31:45 CET] <furq> it's only dtsma or something which is lossless [01:31:50 CET] <alexpigment> i i thought you were talking about master [01:32:05 CET] <alexpigment> if it was dts, i'd probably just leave it, unless there were some sort of compatibility issues with the player [01:32:15 CET] <alexpigment> if it were ac3, i'd 100% leave it in ac3 [01:32:23 CET] <illegal> furq, it's probably the loseless version [01:32:25 CET] <furq> if i'm downscaling something with dts audio i'll normally transcode it [01:32:40 CET] <furq> otherwise it ends up being a third of the total size [01:32:46 CET] <furq> ac3 is never big enough to bother messing with [01:33:12 CET] <alexpigment> right, and ac3 is supported by basically everything (including players and receivers), which is actually a pro compared to opus [01:33:43 CET] <alexpigment> to me, the only benefit to opus is that it's free and that it's relatively modern. that's about all i can say [01:34:15 CET] <alexpigment> anyway, i'll shut up and let the guy get to his 5.1 transcode ;) [01:34:33 CET] <furq> well the benefit is obviously that it's very small [01:34:51 CET] <furq> it's just not often that you get the chance to benefit from that without some other compromise [01:34:53 CET] <alexpigment> furq: compared to the video, I just can't imagine that's really every a huge concern [01:34:57 CET] <furq> right [01:35:02 CET] <alexpigment> *ever [01:35:54 CET] <furq> i mean i've done a 576p encode from a blu-ray with dts-hd before [01:36:05 CET] <alexpigment> yeah, dts-hd is huge [01:36:17 CET] <furq> that would've been 2100kbps of audio for a 2700kbps video [01:36:22 CET] <furq> that's too big [01:36:26 CET] <alexpigment> you can extract the "lossless" part of the audio though, right? [01:36:30 CET] <furq> shrug [01:36:32 CET] <alexpigment> and just keep the lossy core [01:36:42 CET] <alexpigment> not that i'd recommend it, but at least that's one option [01:37:25 CET] <alexpigment> ffmpeg -i DTS-HD_MA.dts -bsf:a dca_core -c:a copy TS-Core.dts [01:37:28 CET] <alexpigment> that's apparently how you do that [01:37:42 CET] <furq> hopefully ffmpeg defaults to decoding the lossless version [01:37:42 CET] <alexpigment> for future reference if you ever decide to do that or need to recommend it [01:37:51 CET] <furq> because otherwise i transcoded the core [01:37:56 CET] <alexpigment> well, i would hope so, but i wouldn't bet my life on it [01:38:03 CET] <furq> yeah i didn't even check [01:38:07 CET] <alexpigment> :) [01:38:16 CET] <alexpigment> well, next time do a copy and check the bitrate ;) [01:39:00 CET] <furq> i don't think i remembered what dtshd was at the time [01:39:22 CET] <furq> it's not a film i care about anyway so it doesn't matter [01:39:42 CET] <alexpigment> either way, people put wayyyy too much stock in lossless audio when they butcher the hell out of the video bitrate. i'm known to many friends as an "audiophile" and I wouldn't notice the difference between dts and dts hd without a side-by-side and some luck, i'm sure [01:40:26 CET] <alexpigment> furq: it's cool man. american pie 3 is still ok with transcoded dts core [01:40:45 CET] <furq> i'd be shocked if jon kirchner's dog could abx dts from dtsma [01:40:56 CET] <alexpigment> haha [01:42:18 CET] <alexpigment> i do find it funny how some DVDs have like DTS + AC3 or PCM + AC3 or whatever, as well as a commentary track, and the video is like 3mbps after everything is said and done [01:42:39 CET] <furq> yeah i don't see why you'd ever put dts on a video dvd [01:42:40 CET] <alexpigment> just pick one. no one cares [01:42:58 CET] <furq> let alone dts and ac3 together [01:43:07 CET] <alexpigment> furq: well, i'm sure it's some under-the-table bribing between the dts people and the movie studios [01:43:25 CET] <furq> i can't imagine hollywood would let something like that happen [01:44:00 CET] <alexpigment> some real principled people in that industry [01:44:44 CET] <furq> also i'm pretty sure this bluray was just dtshd and not "dts-hd master audio" [01:44:49 CET] <furq> so it was lossy anyway [01:44:57 CET] <furq> it's good that they didn't give it a confusing name [01:45:09 CET] <alexpigment> doesn't dtshd also do the core thing though? [01:45:17 CET] <furq> idk i'm just reading what wikipedia says [01:45:27 CET] <furq> https://en.wikipedia.org/wiki/DTS_(sound_system)#DTS-HD_High_Resolution_Aud… [01:45:29 CET] <alexpigment> i think dts hd is master audio [01:45:36 CET] <furq> nah there's two different ones apparently [01:45:50 CET] <furq> dtshd is upto 7.1 at upto 24/96 [01:45:54 CET] <furq> and then ma is the lossless extension [01:46:08 CET] <alexpigment> ah [01:46:19 CET] <alexpigment> dtshd non-ma also has a dts core [01:46:20 CET] <furq> the bitrate was only 2100kbps for 5.1 so that can't have been lossless [01:46:28 CET] <alexpigment> true [01:47:00 CET] <alexpigment> but yeah, i think about 1700 of that is lost of most people, including myself [01:47:09 CET] <furq> yeah [01:47:34 CET] <furq> four of the channels are lost on me because i only have a stereo setup [01:47:40 CET] <alexpigment> same here [01:47:46 CET] <alexpigment> i have two big floor speakers [01:47:56 CET] <alexpigment> they sound so good that i've never gotten around to buying the rest [01:49:27 CET] <alexpigment> i'd rather have 2 really good speakers than a home-theater-in-a-box with the tiny satellite speakers and the budget subwoofer [01:58:24 CET] <thebombzen> is there a way to get ffmpeg -i bluray:foo to read the chapters? [02:01:16 CET] <alexpigment> thebombzen: not sure how accurate this still is: https://trac.ffmpeg.org/ticket/3953 [02:01:56 CET] <alexpigment> tsmuxer can apparently do it though, fwiw [02:02:40 CET] <alexpigment> was it something i said? ;) [03:02:42 CET] <corporate_shill> Can I encode 4K 60hz lossless from a capture card? [03:02:56 CET] <corporate_shill> Ive tried everything but my buffer keeps overflowing [03:03:06 CET] <corporate_shill> -rtbufsize 2G doesnt work [03:03:24 CET] <corporate_shill> Any help is much appreciated [03:56:33 CET] <alexpigment> corporate_shill: i don't have any experience 1st hand with capturing lossless 4k 60hz, but how fast are you hard drives? [03:56:52 CET] <alexpigment> i would think you would need at least a pci-e ssd [03:57:05 CET] <alexpigment> if not a raid of them [03:57:56 CET] <furq> oh he left [03:58:02 CET] <furq> well for reference that's 750MB/s so yeah [03:58:29 CET] <alexpigment> yeah, the idea of 4k60 lossless kinda gives me chills ;) [03:58:30 CET] <furq> or 933 for 10-bit [03:59:08 CET] <alexpigment> man [03:59:16 CET] <alexpigment> that would fill up your drives so fast [03:59:21 CET] <furq> that's uncompressed but still [03:59:33 CET] <alexpigment> well, lossless it's going to get you much further [03:59:37 CET] <alexpigment> *isn't [03:59:46 CET] <furq> even half that is still going to need more than sata3 [03:59:48 CET] <alexpigment> maybe 1/10th? [04:00:04 CET] <alexpigment> yeah, i knew sata was out of the question [04:00:04 CET] <furq> i'd expect better than that [04:00:11 CET] <alexpigment> well, realtime [04:00:14 CET] <furq> maybe like 66% if you're lucky [04:00:16 CET] <furq> that's true though [04:01:08 CET] <alexpigment> it's questions like that that make me realize we're in a weird situation where the current standards of video aren't really feasible for the average person [04:01:41 CET] <alexpigment> that's one of the reasons i've been heavily researching hardware encoding, because that's what we're all going to be using as 4k goes mainstream [04:02:00 CET] <alexpigment> a core i7 from today is much faster than a core i7 from 2010, but it's not that much faster [04:18:13 CET] <lolDude> hi [04:18:29 CET] <lolDude> I wanna write video and audio from rtsp [04:18:40 CET] <lolDude> is there any book about video coding? [08:41:14 CET] <SortaCore> why does avcodec_parameters_copy not copy time_base and framerates? [10:33:04 CET] <BlueInk> Hello everybody, I would like to know if there is a way to check the effectiveness of an encoding process. I'd like to encode six hours of video material with the least amount of disk space possible, while retaining a good quality. size is a premium for this task. the source material is a talkshow 720p@60. Step 1: I could go to 30 fps to half the data, but ffmpeg/h264 has so many settings that hard to see where to [10:33:04 CET] <BlueInk> adjust for more savings. Is there any good reading material on how to set the right encoding flags for a given material? [10:34:02 CET] <furq> there isn't really anything worth touching other than crf, preset and tune in 99% of cases [10:34:14 CET] <furq> as far as x264 options specifically [10:34:53 CET] <furq> just cut a clip, pick a crf, encode it with -preset veryslow, and see if it meets your needs [10:35:18 CET] <furq> dropping the framerate will give a marginal saving but not as much as you'd think [10:35:43 CET] <furq> and if it's a talkshow then it's probably not worth denoising to get rid of grain [10:36:47 CET] <BlueInk> wow thank you for the very quick response [10:50:58 CET] <JC_Yang> crash in filter_mb_dir(), would it be a bug or corrupt stream? [10:51:44 CET] <JC_Yang> within h264 loop filter [10:52:23 CET] <JC_Yang> how tolerant is libavcodec to corrupt stream? [10:58:28 CET] <BtbN> A crash is always a bug. [11:06:35 CET] <JC_Yang> it's not hard to reproduce, but the stream is from ip cam, I didn't really decode it but just try_decode() done by avformat_find_stream_info(). I'm not familiar with the codebase and algo, any suggestions? [11:26:19 CET] <BtbN> open a bug with a sample that makes it crash. [11:27:36 CET] <JC_Yang> that's not so easy, that's a rtsp stream, an it may not always crash, just sometimes, [11:49:44 CET] <BlueInk> Got 5 hours in 1.8Gb, with good enough quality. I think that's everything I could ask for. [13:43:18 CET] <Fyr> guys, what does the following mean: [13:43:19 CET] <Fyr> Stream #1:0(und): Video: h264 (High 4:4:4 Predictive) (avc1 / 0x31637661), yuv420p [13:43:19 CET] <Fyr> ? [13:43:33 CET] <Fyr> is it yuv420p or yuv444p? [13:44:09 CET] <JEEB> it's yuv420p [13:44:15 CET] <JEEB> the profile for *any* lossless is that one [13:44:32 CET] <JEEB> as lossless coding is only permitted in the High 4:4:4 predictive profile [13:44:35 CET] <JEEB> in H.264 [13:44:47 CET] <Fyr> ok, thanks. [13:48:48 CET] <Fyr> is there a difference between yuv420p(progressive) and yuv420p? [13:49:34 CET] <Fyr> the output files came from the almost identical input files. [13:49:50 CET] <Fyr> however, FFMPEG chose different colorspace. [13:53:24 CET] <JEEB> Fyr: it's just extra data if it specifically states it's progressive. [13:53:31 CET] <JEEB> colorspace is the same with 4:2:0, planar [13:53:50 CET] <JEEB> (YCbCr which is called 'YUV' in FFmpeg due to hysteric raisins) [13:54:28 CET] <Fyr> JEEB, why is it different for almost identical files? [13:55:15 CET] <JEEB> it was able to specifically infer that from one of the files :P [13:55:20 CET] <JEEB> another didn't have it specifically set [13:55:31 CET] <JEEB> it's just how ffmpeg.c or ffprobe prints it out [13:55:39 CET] <JEEB> if you need something machine-readable use ffprobe and -of json [13:55:50 CET] <JEEB> with -show_streams and -show_format [18:07:06 CET] <zerodefect> Using the ffmpeg C-API, is there any way to handle 24-bit audio (perhaps say in 32-bit samples to make it easier for processing). I've seen this page here: https://trac.ffmpeg.org/wiki/audio%20types [18:07:21 CET] <zerodefect> The AVSampleFormat doesn't seem to have any enumerations for any sort of 24-bit [18:11:20 CET] <DHE> it will produce a AV_SAMPLE_FMT_S32[P] sample [18:14:13 CET] <zerodefect> @DHE, so is S32(p) actually 32/24-bit or 32/32-bit? [18:15:07 CET] <DHE> I presume it would effectively resample the 24 bit into 32 bit during "encoding" [18:22:02 CET] <zerodefect> Ok. That is was I suspected. It's an interesting problem. I think SDI in broadcast uses 24-bit packed into 32-bit. I appreciate that ffmpeg is not developed solely with broadcast in mind :) [18:23:01 CET] <durandal_1707> zerodefect: 24 bit is shifted by 8 to become 32bit [18:23:52 CET] <zerodefect> In what scenario? When converting from 24 to 32-bit? [18:24:19 CET] <durandal_1707> when decoding [18:24:52 CET] <durandal_1707> its just internal representation [18:24:57 CET] <zerodefect> Ah right, I see what you're saying. Thanks. [18:25:01 CET] <zerodefect> Yeah [18:26:18 CET] <zerodefect> It's only a pain in that I have some I/O interfaces that expect 24-bit. I don't want to re-invent the wheel and perform the conversion myself (inefficiently). [18:29:55 CET] <mbrrr> What is a good way (or any way) to take a video input at 30fps and output a slideshow like stream of every 90th frame? I've tried the select video filter and I can output a video but it looks terrible. I can capture still images that look great but can't seem to get them to 'stream'. I can use the segment format to continuously grab and overwrite a a few images but can't get them to play in a loop on my network. Any thoughts? I need [18:29:55 CET] <mbrrr> stream with good picture quality, very low fps, and no audio. [18:38:24 CET] <DHE> durandal_1707: it's a bit more complex than that. you usually want to map "0000" to "00000000" (to use a small size for example) but "1000" to "10001000" so that "1111" maps to "11111111" with a nice smooth transition curve [18:39:00 CET] <DHE> it's pedantic, but most correct [19:03:16 CET] <alexpigment> mbrrr: you mention that you tried the "select video filter". what filter specifically? [19:03:54 CET] <alexpigment> mbrrr: it seems weird that a filter would make the quality bad; that seems more to do with what CRF or bitrate you specified for the output video [19:04:45 CET] <alexpigment> mbrrr: also, is your source fairly lossy? a lot of videos "look" fine when played, but each invidivual frame is pretty messy. this would be exacerbated in the video you're trying to make [19:05:05 CET] <DHE> there's actually a fitler named 'select' [19:05:45 CET] <alexpigment> DHE: well, he apparently left, but I'm still thinking the filter is not the reason for the quality concerns he described [19:09:03 CET] <alexpigment> mbrr (mbrrr?): welcome back. did you miss my messages? [19:10:33 CET] <alexpigment> well, i tried [19:12:50 CET] <DHE> wonder if maybe he just wants setfps=0.3 or something like that. as for quality, some encoder numbers likely need cranking. :) [19:14:28 CET] <alexpigment> it does have me wondering: is there a filter that chooses the least macroblock-y frame from within a range? [20:06:26 CET] <beo> hello, can someone tell me whats wrong with this script for making sshots from video files in batch? --> for %%A IN (*.mp4) DO ffmpeg -ss 00:00:10 -i "%%A" -frames:v 1 "%%A.png" [20:08:17 CET] <sfan5> does it give you an error message? [20:09:34 CET] <beo> im on windows, typical error "ffmpeg has stopped working" [20:09:44 CET] <beo> but it is working with jpg, i just found out [20:09:57 CET] <beo> png output is crashing ffmpeg [20:11:08 CET] <beo> im using nightly, if that makes any difference [20:11:13 CET] <beo> hm [20:11:16 CET] <BtbN> do it manually, and if it still crashes, report a bug with a crashing sample. [20:15:09 CET] <beo> i tried stable [20:15:49 CET] <beo> it is only crashing in Nightly 20171212 build [20:15:54 CET] <beo> :) [20:21:25 CET] <beo> actually no, its some other build, i dont know how to check which it is exactly [20:21:30 CET] <beo> latest is ok [20:21:55 CET] <sfan5> sounds like the bug in question was already fixed, then [20:24:05 CET] <beo> yes [22:56:40 CET] <blackburn1911> Hello people [23:04:27 CET] <blackburn1911> I have a "problem" with this command https://pastebin.com/rU5XZnsu . I want to make the text rolling from right to left every 20 seconds. The problem with the command is like the text disappearing before finishing rolling the text [23:05:07 CET] <blackburn1911> I want to make a loop or something. Every 20 seconds, show the rolling text and so on [00:00:00 CET] --- Thu Dec 14 2017

1 0

ffmpeg-devel.log.20171212
by burek 13 Dec '17

13 Dec '17

[00:48:00 CET] <atomnuker> nevcairiel: did you have the time to port one avpriv cas to c11 exchange? [00:48:17 CET] <atomnuker> jamrial_: as soon as the atomics stuff get removed [01:41:02 CET] <tmm1> i'm trying to add prores support to the videotoolbox encoder [01:41:46 CET] <tmm1> can someone help me figure out the AV_PIX_FMT_YUV422P10LE version of get_cv_pixel_info here: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/videotoolboxenc.c#L… [01:42:01 CET] <tmm1> would it be the same as AV_PIX_FMT_YUV420P [01:44:36 CET] <jkqxz> Probably, but without the /2s on chroma height. [01:45:36 CET] <jkqxz> Make sure the videotoolbox layout is actually the same as YUV422P10LE, though. They can do all sorts of things with weird packing when it's 10-bit. [01:48:24 CET] <jkqxz> What advantage would that encoder have, anyway? Is it something GPU something for great somehowbetterness? [01:50:24 CET] <tmm1> yea its hardware accelerated supposedly [01:55:25 CET] <tmm1> encoder is throwing kVTPixelTransferNotSupportedErr, i guess its probably not in v210 format [03:20:11 CET] <jamrial_> nevcairiel: your msvc 2017 fate failures are almost all an EPERM error [04:51:00 CET] <cone-886> ffmpeg 03Steven Liu 07master:0e5260226a72: avformat/hlsenc: reindent after previous commits [05:35:11 CET] <G30rge> Seeing an issue where the AAC decoder is populating the AVFrame linesize incorrectly. Is there a known issue related to this? The sample format is FLTP and the linesize is being set as though it is a packed format - not interleaved (IE the linesize = chan 1 + chan 2) [05:39:08 CET] <G30rge> I meant to say treated as packed/interleaved instead of planar [05:49:57 CET] <durandal_1707> G30rge: really? [05:52:27 CET] <G30rge> @duranda1_1707 : I have a situation where nb_samples == 1024, bytes per sample is 4 (fltp), channels is 2 [05:52:38 CET] <G30rge> linesize[0] == 8192 [05:52:45 CET] <G30rge> linesize[1] = 0 [11:13:09 CET] <durandal_1707> michaelni: ffv1 doesnt store color_range anywhere [11:53:21 CET] <atomnuker> durandal_1707: that's something than can be fixed actually, version 4 is still unstable so you can add a flag [13:02:08 CET] <durandal_1707> so what is consensus versus adding color range to AVCodec? [13:02:53 CET] <atomnuker> IMO I think it should be there and it should be an array (to indicate e.g. what ranges an encoder supports) [13:03:06 CET] <JEEB> yup [13:04:50 CET] <wm4> I'd prefer an array too [13:08:21 CET] <jdarnley> What? An array like luma min/max and chroma min/max? [13:08:27 CET] <durandal_1707> that is sick [13:08:46 CET] <durandal_1707> int should be enough [13:08:49 CET] <atomnuker> lol no, an array of enums which map to luma/chroma min/max [13:09:07 CET] <atomnuker> durandal_1707: the issue is that a single int isn't enough [13:09:23 CET] <durandal_1707> 0 supports both [13:09:45 CET] <atomnuker> sure you can treat the field as a bitmask to signal values but I think it should be treated the same as pixfmts [13:10:01 CET] <durandal_1707> or you gonna add more ranges? [13:10:18 CET] <durandal_1707> this complicares code a lot [13:10:39 CET] <wm4> I'm only suggesting AVColorRange ranges[]; [13:10:52 CET] <atomnuker> that's exactly my concern, its a matter of time before someone with half a brain cell decidec for something like an alternative range for hdr [13:11:06 CET] <wm4> but I'm not opposed to a flat AVColorRange value either to stop the bikeshedding lol [13:11:10 CET] <atomnuker> where the top part is full but the bottom is still limited [13:12:14 CET] <atomnuker> (technically in broadcast IIRC overshoots over 235 are allowed sparingly but not undershoots under 16 or whatever that was) [13:14:14 CET] <JEEB> well broadcast is signalled limited range and we don't care if the values overshoot [13:14:43 CET] <atomnuker> durandal_1707: if it complicates the code I wouldn't mind making the field a bitmask [13:14:45 CET] <JEEB> I don't think those flags mean that you have to make sure your content is within that level if it is already flagged so [13:15:07 CET] <JEEB> overshoot? it goes right through like it would in 99% of those darn processes [13:15:14 CET] <atomnuker> e.g. color_range = AVCOL_RANGE_FULL | AVCOL_RANGE_LIMITED | AVCOL_RANGE_SHIT [13:15:54 CET] <wm4> just make it an array [13:16:08 CET] <wm4> a bit mask would require separate flag constants [13:16:17 CET] <atomnuker> I really doubt that as bad as things might get in 50 years there'll be more than 32 different ranges [13:17:10 CET] <kierank> atomnuker: well arguably HLG is already like that [13:17:18 CET] <kierank> the range is kinda limited [13:17:26 CET] <atomnuker> yeah, an array would make it pretty much identical to a pixfmt so it would be consistent with what we have [13:18:32 CET] <atomnuker> there you go then, a reason for AVCOL_RANGE_KINDA_LIMITED to exist [13:24:03 CET] <rcombs> AVCOL_RANGE_FUZZY [13:26:26 CET] <JEEB> kierank: eh, I thought all those fancy HDR things follow limited range YCbCr and it's then the colorspace information that then leads to different handling [13:26:38 CET] <JEEB> as far as something that cares about limited/full range goes it's either full or limited [14:31:40 CET] <kierank> JEEB: afaik hlg uses some of the peaks [14:58:22 CET] <durandal_1707> buahaha, enjoy more spam [15:23:18 CET] <atomnuker> awesome [19:53:58 CET] <cone-343> ffmpeg 03Paul B Mahol 07master:a0e4c41d086b: avfilter/vf_pseudocolor: add support for more formats [20:47:37 CET] <durandal_1707> no more filters for you folks, you were all very evil this year [20:59:48 CET] <BtbN> "I made git log to the first bad after this revision" he what? [21:10:05 CET] <jkqxz> Er, what? I'm not sure what the bug is now. [21:14:23 CET] <BtbN> same [21:25:25 CET] <BtbN> I have no idea what he's going on about. nvenc not being x264 is a bug now?! [21:37:20 CET] <atomnuker> durandal_1707: did you run out of ideas? [21:38:11 CET] <durandal_1707> atomnuker: you stole all ideas and atrac9, ruined my christmas [21:38:45 CET] <atomnuker> I'm a generous person so I shall give you an idea [21:39:52 CET] <durandal_1707> generic glsl shader filter? [21:40:41 CET] <BtbN> Shadertoy as a filter [21:41:07 CET] <atomnuker> nope, nope, those are mine and mine alone and will see the light of day once I finish my vulkan patchset [21:41:08 CET] <jkqxz> With Vulkan, sure. Please no OpenGL. [21:41:41 CET] <durandal_1707> wtf? [21:42:05 CET] <atomnuker> durandal_1707: we don't have enough generators [21:42:39 CET] <atomnuker> for audio [21:43:15 CET] <atomnuker> I think it would be great to have a rain / thunder generator [21:43:31 CET] <atomnuker> which synthesized the effects for both proceduraly during init [21:44:46 CET] <atomnuker> you could probably have one or two samples stored as tables and you'd manipulate them to generate different variations randomly [21:45:24 CET] <durandal_1707> synths are beast on their own [21:46:01 CET] <atomnuker> yeah, so just manipulate some existing samples, with time stretching, bandpassing, etc. to make variations of [21:46:48 CET] <durandal_1707> for synths you need midi [21:46:59 CET] <atomnuker> no, you don't [21:48:02 CET] <atomnuker> I'm not talking about midi synth synth, just about general synthesis (e.g. a thunder is pretty easy to synthesise, look at how smoke is synth'd in video) [21:49:55 CET] <durandal_1707> atomnuker: one could create special waves, but how to control them [21:51:24 CET] <durandal_1707> and how to combine them? [21:51:25 CET] <atomnuker> randomly [21:51:36 CET] <atomnuker> how to combine them? mix 'em [21:52:31 CET] <durandal_1707> atomnuker stole my christmas and new year [21:53:13 CET] <durandal_1707> sox have its synth filter [22:29:06 CET] <alevinsn> nevcairiel: Not sure if you are around, but could you provide an example of a codec for which FF_CODEC_CAP_INIT_THREADSAFE isn't appropriate yet? [22:30:28 CET] <wm4> any codec which hasn't it set could be affected and must be checked manually [22:30:54 CET] <alevinsn> I get that, but what sort of thing should I be looking for? [22:31:11 CET] <alevinsn> any modification to the AVCodecContext * that is passed in? [22:31:33 CET] <wm4> no [22:31:36 CET] <alevinsn> the argument that is passed in is an AVCodecContext * (to .init), not the AVCodec * object [22:31:42 CET] <wm4> this is mostly about initializing global data [22:31:51 CET] <wm4> like tables used for decoding or encoding [22:32:01 CET] <alevinsn> got it [22:32:14 CET] <alevinsn> so, some that aren't marked thread safe may very well already be [22:32:36 CET] <wm4> yes [22:32:43 CET] <durandal_1707> atomnuker: what literature you propose? [22:32:45 CET] <wm4> but it'd not always easy to find out [22:33:00 CET] <wm4> and those which are definitely affected must be fixed [22:33:01 CET] <alevinsn> right, and difficult to test properly if you didn't do it properly [22:33:18 CET] <wm4> either by moving the data into a context, or initing them with ff_thread_once [22:33:40 CET] <alevinsn> or doing things differently if appropriate [22:34:18 CET] <durandal_1707> you wrote decoder of some sort? [22:34:40 CET] <alevinsn> no--but I was thinking about doing this, at least for the decoders/encoders that I use for my project [22:35:08 CET] <alevinsn> wm4: Once all codecs are made thread-safe, then what's the plan? [22:40:17 CET] <wm4> alevinsn: remove the codec locking [22:40:35 CET] <wm4> I believe this makes the "lock manager" useless [22:40:51 CET] <wm4> (a thing which MS just implemented in their ffmpeginterop, for unknown reasons) [22:40:58 CET] <alevinsn> right, but beyond that, how will it be ensured that new codecs are threadsafe on init and codecs that are merged in from libav? [22:41:19 CET] <wm4> libav has the same ideas about this [22:41:41 CET] <wm4> it's unlikely they will add new code that requires locking on init [22:42:06 CET] <durandal_1707> or any code at all [22:42:24 CET] <alevinsn> so, the basic idea, is, if any locking is necessary, move that into codec's init method, not do at the global level [22:46:08 CET] <wm4> the basic idea is: never use global mutable data [22:46:43 CET] <wm4> but if you do anyway (like "lazy" conversion of old code), use ff_thread_once() [23:45:45 CET] <atomnuker> durandal_1707: also here's another idea - move the cng from being a codec to being a filter [23:46:27 CET] <atomnuker> because as-is it just ignores all input and generates noise, which is what a filter generator ought to do [23:47:17 CET] <durandal_1707> isnt that nicolas stuff? [23:48:50 CET] <atomnuker> no? its very old [23:49:32 CET] <atomnuker> durandal_1707: here's some literature on storm noise generation - http://www.planetz.com/Pulsar/files/modular/emulatingthunder.PDF [23:51:17 CET] <atomnuker> actually nvm about the cng stuff, its a legit codec [00:00:00 CET] --- Wed Dec 13 2017

1 0

ffmpeg.log.20171212
by burek 13 Dec '17

13 Dec '17

[00:17:41 CET] <alexpigment> i can ffmpeg to say q=[int]-[int] by using qmax and qmin, but it seems to have no effect on bitrate [00:18:01 CET] <alexpigment> and there's a default bitrate of 200kbps, which I can override by setting -b:v 0 [00:18:19 CET] <alexpigment> but basically -b:v 0 is always unlimited regardless of the qmax/qmin [00:18:36 CET] <alexpigment> in other words, qmax and qmin have no purpose from what I can tell [00:20:24 CET] <alexpigment> well, I guess I'm done talking to myself for the day :) maybe someone will chime in later who has any experience with the h264_videotoolbox encoder [00:33:02 CET] <daddesio> Hmm, is there a way to specify the input sample rate for an Xbox 360 XMA .wav file (compression type 0x165)? I don't see anything that looks like a sampling rate (e.g. 0xac44 -> 44100) in the header of my file. [00:33:30 CET] <JEEB> you'd probably want to check if someone has documented that format [00:33:34 CET] <daddesio> passing -ar 44100 either before or after the -i input.wav doesn't seem to do anything. I always get: "Invalid sample rate: 0 [00:33:37 CET] <daddesio> " [00:33:52 CET] <JEEB> yea non-raw demuxers usually try to read stuff themselves [00:35:00 CET] <JEEB> ok, the first hint is that X360 WAVs seem to use the same code but since it's all big endian I bet all the values have to be read in BE [00:35:13 CET] <furq> daddesio: https://wiki.multimedia.cx/index.php/XMA [00:35:25 CET] <furq> looks like you're going to have fun [00:35:57 CET] <JEEB> hmm, that sounds different [00:36:20 CET] <JEEB> there seem to be actual WAV files which are in the opposite endian on the X360 as well [00:37:04 CET] <furq> where are you reading that [00:37:13 CET] <furq> google isn't being much use here [00:37:59 CET] <JEEB> xbox 360 wav brought up "WAV endian converter" on some forum [00:38:14 CET] <JEEB> "Changes endianess for standard WAV files (all floats + ints) found in the game." [00:38:27 CET] <JEEB> which sounds like MS used common code and just dumped data from memory in it [00:38:31 CET] <JEEB> which led to endian swaps [00:42:19 CET] <daddesio> yes, seems I will have to do some investigating/RE :) [00:42:34 CET] <daddesio> vgmstream also can't decode it [00:52:18 CET] <furq> http://www.scampers.org/steve/sms/other.htm [00:52:19 CET] <furq> maybe this? [00:52:26 CET] <furq> Supports XMA v1 and XMA2 (format tags 0x165 and 0x166). [01:11:57 CET] <matej_k> when parsing hevc bytestream, the zero byte seems to be last byte of previous frame instead of first byte of next [01:12:20 CET] <matej_k> so the AU starts with 3 bytes startcode [01:12:25 CET] <matej_k> is that to be expected? [01:20:24 CET] <jkqxz> Parsing with what? [01:20:30 CET] <jkqxz> I don't think anything really cares, though. [01:21:21 CET] <jkqxz> Though things writing it should do the right thing (zero byte at start of AU and in front of PS NALs). [01:24:03 CET] <matej_k> jkqxz: thanks. right now it seems to leave zero byte trailing in previous AU, at least for the file im testing this with [01:24:47 CET] <matej_k> on the other hand annex b says zero byte should be discarded, so it should probably be irrelevant [01:24:58 CET] <matej_k> but it confuses timestamps in gstreamer HEVC parser [01:25:28 CET] <matej_k> so now Im trying to figure out if the HEVC parser in ffmpeg is doign something wrong or just gstreamer should handle this better [01:25:54 CET] <jkqxz> Um, what to timestamps have to do with it? There are no timestamps in annex B. [01:26:01 CET] <jkqxz> *what do [01:26:50 CET] <JEEB> there can be SEI messages but those are unlikely :P [01:27:08 CET] <JEEB> usually you just get a header that says the time base or so [01:27:12 CET] <JEEB> if even that [01:28:24 CET] <matej_k> jkqxz, the timestamps are not in stream of course; the problem happens when gstreamer assign timestamp to AU [01:28:44 CET] <matej_k> because it looks the bufferr where there zero byte belongs [01:29:00 CET] <matej_k> and uses that as timestamp for the AU [01:29:15 CET] <matej_k> except when parsed by ffmepg that the zero byte is traling byte in previous AU [01:29:28 CET] <matej_k> which is different buffer, with different timestamp [01:30:13 CET] <matej_k> but specs says that zero byte is to be discarded, so i dont think what gstreamer does is correct [01:30:37 CET] <jkqxz> How does it distinguish between zero_byte and the other zero bytes ((leading|trailing)_zero_8bits)? [01:32:04 CET] <matej_k> it just searches for 0x000001, and once it finds, check if there is zero byte before it [01:32:04 CET] <matej_k> if it is, moves the pointer [01:32:31 CET] <matej_k> and that pointer position later determines timestamp of AU [01:32:50 CET] <jkqxz> What if the previous NAL unit is padded with trailing_zero_8bits? [01:33:52 CET] <jkqxz> You can always put as many zeroes as you like between NAL units. [01:34:54 CET] <matej_k> yeah, looking at the code traling_zero_8bits would also mess up the timestamp assignment [01:37:29 CET] <jkqxz> Generating timestamps from raw streams is in general a hard problem (though not quite as bad as H.264). You need to at least look inside the packets to find the POCs. [04:51:32 CET] <lpt10> hi [04:55:41 CET] <lpt10> can you specify the RGB (and white) CIE xy primaries of an input footage to be encoded? [04:56:01 CET] <lpt10> i.e, i have a sequence of scene-linear EXR files, with ACEScg AP1 RGB primaries, D60 whitepoint [04:56:35 CET] <lpt10> and want to encode that to a Rec.2020 transfer function encoded sequence, with Rec.2020 RGB primaries, D65 whitepoint, 10 bit full range [04:57:02 CET] <lpt10> one would expect a chromatic adaptation transform from D60 to D65, and indeed you have Bradford and "fake von Kries" transform to deal with this [04:57:48 CET] <lpt10> but i cannot seem to find where to specify the RGB(W) xy primaries of the input space. Is it assumed to be always Rec.709/sRGB RGB primaries (and D65 whitepoint) ? [05:01:36 CET] <lpt10> Or is it the input sequence assumed to be in the same RGB primaries (and whitepoint) of the output space? [05:02:17 CET] <lpt10> i.e, choosing an for instance, Rec.2020 transfer function encoded sequence, with Rec.2020 RGB primaries, D65 whitepoint, would expect the input footage to be using the same RGB primaries (Rec.2020) and whitepoint (D65) [07:19:52 CET] <SortaCore> bad JEEB [07:20:33 CET] <SortaCore> turns out setting the interrupt_cb callback for RTSP gets it silently copied to the underlying TcpContext [07:20:46 CET] <SortaCore> and you can't access that without more fun address hackery [07:21:36 CET] <SortaCore> memset((AVIOInterruptCB *)(*(((int ***)rtsp_format_context->priv_data) + 1) + 8), 0, sizeof(AVIOInterruptCB)); [07:23:25 CET] <SortaCore> so my timeout for connecting ended up aborting all the streams [07:23:30 CET] <SortaCore> el sob [07:23:42 CET] <furq> what a beautiful line of code [07:24:50 CET] <SortaCore> I have one that's worse for accessing the socket [07:25:13 CET] <SortaCore> inside a tcpcontext, inside a urlcontext, inside a rtspstate, inside a formatcontext [07:28:08 CET] <SortaCore> my motto is "you can use really evil code as long as you fully document it" [07:28:39 CET] <SortaCore> come to think of it, I can read back the interrupt callback and check it matches my cb's function address [07:29:02 CET] <SortaCore> ima add an if in thar [07:32:09 CET] <SortaCore> now it's fully documented and not very likely to break things [07:32:19 CET] <SortaCore> yay for progress [07:40:38 CET] <fantesy> would anybody know how to output the average encode speed to a text file [07:54:13 CET] <SortaCore> fantesy, you probably want the batch > operator [07:55:22 CET] <JC_Yang> when avformat_find_stream_info failed with get_buffer() failed and thread_get_buffer() failed, what might be the cause? ffmpeg build with "--disable-encoders --disable-decoders --disable-demuxers --disable-muxers --disable-bsfs --disable-protocols --disable-filters --disable-parsers --enable-demuxer=h264,mpegps,hevc,mov,rtp,rtsp --enable-parser=h264,hevc --enable-protocol=file,rtp --enable-bsf=h264_mp4toannexb,hevc_mp4toannexb --disable-avfilter --disable-swres [07:55:22 CET] <JC_Yang> sable-avdevice --enable-decoder=h264,hevc" [07:57:00 CET] <fantesy> it only outputs per frame and i am doing a lot of these so i don't want to have to average them myself, does ffmpeg even store that, might i need to do verbose logging [07:57:27 CET] <SortaCore> you may need sdp demuxer JC_Yang [07:58:25 CET] <JC_Yang> the output indicate rtp is in action [07:58:31 CET] <SortaCore> fantesy: afaik it doesn't, but I'm not a pro user [07:58:41 CET] <SortaCore> JC: rtsp uses sdp in the headers [07:58:50 CET] <fantesy> ok thanks [07:59:23 CET] <JC_Yang> okay, will try immediately [08:11:33 CET] <JC_Yang> does not help much, still "no frame! get_buffer() failed thread_get_buffer() failed" [08:17:06 CET] <Fig1024> I'm using C++ SDK for h264 encoder, trying to record 60 fps video, but for some strange reason, media info says file has "variable frame rate." I'm giving it exactly 60, it should say constant frame rate! [08:18:21 CET] <SortaCore> set r_frame_rate and avg_frame_rate? [08:18:35 CET] <SortaCore> although, forcing a higher framerate than what you have will just waste space [08:20:47 CET] <Fig1024> variable frame rate is not good for video editing [08:24:04 CET] <SortaCore> having wasted space isn't good for video editing [08:24:29 CET] <Fig1024> also, I couldn't find either r_frame_rate or avg_frame_rate in avcodec.h [08:25:19 CET] <c3r1c3-Win> When it comes to editing videos, CFR is the way to go, always. [08:26:44 CET] <Fig1024> also, when I try to open Nvidia h264 encoder, it fails, I suspect it doesn't like variable frame rate. But I can't find how to change it [08:27:27 CET] <SortaCore> c3r1c3-Win tag you're it [08:27:55 CET] <c3r1c3-Win> lol [08:31:02 CET] <MoziM> is writing images to disk slower than writing video? [08:31:23 CET] <c3r1c3-Win> Depends, but almost 100% yes. [08:32:04 CET] <c3r1c3-Win> Images = uncompressed video (usually). Also you have to add entries to the file tables (and whatnot) for each image saved. [08:37:43 CET] <c3r1c3-Win> That said, if you're completely CPU bound (i.e. your drives can keep up and are always waiting on your CPU) then writing video can be slower than images. [08:45:00 CET] <Fig1024> oops, my NVidia driver was too old to support nvenc [08:46:29 CET] <MoziM> c3r1c3-Win: hmmm... it was an embedded board and the drive was an sd card. i'm thinking now that writing video may have been a little better, but not a whole lot. [08:47:04 CET] <c3r1c3-Win> MoziM: Were you writing a compressed video or something uncompressed? [08:48:07 CET] <MoziM> raw images [08:49:14 CET] <MoziM> get buffered image from raspberry pi camers -> jetson tk1 -> opencv program -> write image with status overlay to disk [09:15:05 CET] <astral> Hello, I have a very interesting case that I am unable to crack myself, perhaps anybody can take a look at the video file? context: Video file comes from Hikvision's NVR (security IP cameras) internal API. You pass start time and end time parameters to this API and it produces a video file in memory available for download, [09:15:47 CET] <astral> but this video file is flawed in several ways: [09:16:05 CET] <astral> Duration of the video file is wrong (as seen in Mediainfo or VLC). My guess is this happens due to NVR storing video files in chunks and when attempting to download video by supplying specific start time and end time to NVR's API the software just creates a new video file in memory by extracting the needed parts from stored video and attaching the original video file's duration to the newly created one. [09:16:35 CET] <astral> and also Audio cannot be played in most media players including VLC. [09:16:51 CET] <astral> I have tried converting the video file using ffmpeg with different settings to try and fix these issues but the output video still has the same problems. What's interesting is that ffmpeg's ffplay is able to play the video file perfectly with sound and no disruptions. Therefore I figured there must be a way to convert the video file to normalize it for other players as well. [09:17:08 CET] <astral> Mediainfo output of the video file in question: https://pastebin.com/zNTpPi79 [09:17:27 CET] <astral> Output of ffmpeg: https://pastebin.com/vAZZV9CT [09:17:55 CET] <astral> Video file itself: https://www.dropbox.com/s/9ccptsuiqk2ntsv/1.zip?dl=0 [09:18:04 CET] <astral> Any help is greatly appreciated. [09:37:32 CET] <JC_Yang> ever tried ffprobe? [09:48:04 CET] <SortaCore> what is yuv4mpegpipe [09:52:24 CET] <JC_Yang> astral, you should try ffprobe, it probably can detect the correct info of your file. since ffplay can do it [09:53:09 CET] <JC_Yang> and then, instruct ffmpeg to use a probe, then you can remux the file correctly [09:53:15 CET] <astral> Tried it yesterday, but just a second, let me do it again [09:54:39 CET] <Fig1024> for some reason my h264 video recording always starts with broken keyframe, so first couple seconds show broken stuff [09:55:49 CET] <astral> Here is the output from ffprobe https://pastebin.com/wy0QjURM [10:00:13 CET] <JC_Yang> okay that is a program stream [10:00:22 CET] <astral> Yep, PS [10:00:47 CET] <astral> Which is why timestamps are incorrect, because I requested only a small piece of a big video chunk [10:01:31 CET] <astral> I tried -t parameter in ffmpeg to set the correct duration, but it still does not play audio [10:36:13 CET] <gmipf> hello [10:36:54 CET] <gmipf> I would like to report a bug for a wiki page: https://trac.ffmpeg.org/wiki/CompilationGuide/Centos#IfYouNeedHelp [10:37:22 CET] <durandal_1707> anybody can edit wiki [10:37:49 CET] <gmipf> https://trac.ffmpeg.org/wiki/CompilationGuide/Centos [10:38:05 CET] <gmipf> but I have no account [10:39:06 CET] <JC_Yang> it's not a pure PS stream, contain some proprietary headers and data, so may confuse the codes. cut 40 bytes from the head, everything works [10:39:21 CET] <JC_Yang> astral [10:39:58 CET] <astral> Hm, let me try that [10:41:22 CET] <JC_Yang> the video is recognized as 2 mins long after I cut the 40 bytes, and play well [10:41:38 CET] <gmipf> for the last step you need to add the line "--extra-libs=-lm" after \"--extra-libs=-lpthread \". Without lm you get the error message: "ERROR: libmp3lame >= 3.98.3 not found" on the latest snapshot, see: http://ffmpeg.org/pipermail/ffmpeg-user/2017-October/037662.html [10:43:03 CET] <JC_Yang> just use any hex editor/tool you like [10:43:13 CET] <astral> already on it, 1 min [10:45:47 CET] <astral> are you sure it's the first 40 bytes? I did it but i still get incorrect duration and no audio [10:46:05 CET] <JC_Yang> yes, 40, in decimal [10:46:35 CET] <astral> it is undoubtedly Hikvision's proprietary codec data [10:46:37 CET] <astral> Let me try again [10:47:50 CET] <JC_Yang> the first 4 bytes should be 00 00 01 ba [10:48:45 CET] <astral> yes, that is what I get as well. But still incorrect duration and no audio [10:49:11 CET] <astral> What player are you using? [10:49:19 CET] <JC_Yang> the player still does not play audio, yet. but at least the duration seems correct, 2mins here. mpc-hc [10:49:53 CET] <Nacht> Removing the first 40 seems to work, nice find JC_Yang [10:51:39 CET] <astral> Indeed, in works in MPC. VLC shows the wrong duration though [10:51:54 CET] <JC_Yang> because it's a ps, still we need probe to find the complete(hopefully) media info, in api level, that is avformat_find_stream_info(). [10:52:46 CET] <astral> I was told on mailing list: to convert you currently have to use an audio-only intermediate file or force audio pts. [10:53:07 CET] <astral> I however do not have experience with syncing PTS with regards to video streams [10:53:21 CET] <astral> Any insight on this matter? [10:55:20 CET] <Nacht> I assume with asetpts [10:55:36 CET] <Nacht> https://ffmpeg.org/ffmpeg-filters.html#setpts_002c-asetpts [10:55:59 CET] <astral> ffplay is not unable to play audio as well, with 40 bytes removed [10:56:06 CET] <astral> ffplay is unable* [10:57:48 CET] <JC_Yang> maybe the best bet is RE the 40 bytes headers, it may contain some hints for the following streams, including syncing [10:58:21 CET] <JC_Yang> had you tried their proprietary players? [10:58:28 CET] <JC_Yang> can it play them well [10:59:01 CET] <astral> Yes I have and it works there. But my goal is to display this video on a website, therefore I was going for H.264 & AAC [10:59:16 CET] <astral> How is it possible that ffplay has the means to play this file flawlessly but VLC cannot? [11:00:13 CET] <JC_Yang> ffplay do so correctly by *guess*, and definitely with the help of avformat_find_stream_info(), [11:01:32 CET] <astral> I will try to produce the output of avformat_find_stream_info() [11:02:25 CET] <astral> "to convert you currently have to use an audio-only intermediate file , Use FFmpeg to create the intermediate audio file." Why would extracting the audio stream and then merging it with original video stream again solve this issue? [11:07:19 CET] <gmipf> so I have changed the wiki page now. [11:13:30 CET] <astral> Extracting audio from the video file and playing it separately in VLC/MPC works perfectly [11:14:00 CET] <astral> I guess I will try extract the video now and merge them and convert simultaneously now [11:27:46 CET] <gmipf> I have followed the instruction to install ffmpeg: https://trac.ffmpeg.org/wiki/CompilationGuide/Centos [11:28:30 CET] <gmipf> is ffmpeg-devel included in the installation process with last make install command? [12:06:50 CET] <throstur> I'm trying to concatenate 4 mp4 files, but keep having problems. I tried with the concat protocol and it produced a broken output file because the files are not concat-able, so then I tried with a video filter but couldn't produce a valid filtergraph descritpion. Could anyone hook me up with "concat video filter" example with 4 input files (1-4.mp4) ? [12:29:16 CET] <astral> In case anyone ever bumps into the same problem: I was able to solve mine by first extracting audio from MPEG-PS video file and encoding it to AAC, then producing video file by removing audio from the original MPEG-PS, and finally merging the two files together [12:29:58 CET] <astral> I also used the -t parameter to correct the duration of both video and audio files before merging them [12:30:50 CET] <astral> Doing this manually is not the best option, sure, but I always have the exact video duration since it is stored in my app, so.. [12:35:57 CET] <throstur> my problem was videos not same size :p snapchat exports some with black bars and some without... heh [13:31:04 CET] <ayum> Hi, I am current using a linked-list to cache AVFrame in the libavfilter, but I have to return a AVFrame everytime. anyone knows how to properly cache AVFrame in libavfilter? [13:32:21 CET] <ayum> If I return a NULL pointer in the filter process function, they I get segment fault. my current idea is to create a dummy AVFrame. and give it a wrong pts, so ffmpeg will ignore it when output [16:20:05 CET] <neverminder> How to see what's being recorded? Is it possible somehow to use ffplay for that? [16:21:33 CET] <DHE> depends. some file types will allow viewing the file as it's being written. otherwise you'll need to do a multi-output from ffmpeg to a viewable stream format [16:24:48 CET] <neverminder> Well I'm doing this: ffmpeg -f v4l2 -input_format mjpeg -s uhd2160 -i /dev/video0 -vcodec copy video.mkv [16:25:00 CET] <neverminder> so the file format is mkv, would that work? [17:00:52 CET] <alexpigment> hey guys. i'm trying to figure out whether I'm looking at a bug or just a feature limitation with the videotoolbox encoder on macOS [17:01:38 CET] <alexpigment> in the "Stream #0:0" information, it shows "q=2-31" by default. I can seemingly change these numbers with qmin and qmax, but it has no effect on file size at all [17:01:51 CET] <alexpigment> even if I set -b:v 0 [17:02:05 CET] <alexpigment> (the default bitrate is 200kbps otherwise) [17:02:18 CET] <alexpigment> would that qualify as a bug? [17:20:52 CET] <kepstin> maybe, but it could just be that the videotoolbox interface simply has no way to set min/max qp values - in which case it's unfixable. [17:21:17 CET] <kepstin> hmm. [17:21:18 CET] <alexpigment> kepstin: I considered that, but I don't know how to confirm that [17:21:41 CET] <alexpigment> I'd like to log it up so we can whip this encoder into shape, but I don't understand where the limitations are coming from [17:22:56 CET] <kepstin> well, here's a list of properties: https://developer.apple.com/documentation/videotoolbox/vtcompressionsession… [17:23:53 CET] <alexpigment> yeah it seems like kVTCompressionPropertyKey_Quality should at least be implemented [17:24:11 CET] <alexpigment> I don't really care about qmin/qmax; it was just the only way I could seemingly get something related to quality [17:24:33 CET] <ritsuka> kVTCompressionPropertyKey_Quality is not implemented for h.264 in VideoToolbox [17:24:37 CET] <ritsuka> I didn't check hevc yet [17:24:49 CET] <alexpigment> ah [17:25:13 CET] <alexpigment> how can you tell? [17:25:41 CET] <alexpigment> this documentation doesn't mention hevc or h.264 specifically [17:25:46 CET] <ritsuka> there is a function to ask an encoder which properties can be set [17:26:51 CET] <alexpigment> well, as a more general question, is there a way at all to get a bitrate that is variable based on the complexity of the source? [17:27:01 CET] <alexpigment> or is it always ABR? [17:36:10 CET] <alexpigment> kepstin: do you see any reason why kVTCompressionPropertyKey_Quality couldn't be implemented for H.264? [17:36:20 CET] <alexpigment> i'm not seeing the restriction that ritsuka is talking about [17:37:57 CET] <ritsuka> well it's easy to check, start and encode, set only the quality and not the bitrate in the videotoolbox session, see what happens [17:38:23 CET] <alexpigment> ritsuka: are you talking about ffmpeg's implementation or videotoolbox itself? [17:38:31 CET] <ritsuka> videotoolbox itself [17:38:53 CET] <alexpigment> is there a reference encoder, or do I have to write an application to test that? [17:39:05 CET] <alexpigment> (option b is above my skill level) [17:39:52 CET] <ritsuka> I added support for videotoolbox h.264 encoder in handbrake years ago [17:40:23 CET] <alexpigment> ritsuka: are you sure it's not a hardware-specific limitation you're running into? [17:40:28 CET] <alexpigment> what is your CPU/GPU/ [17:40:29 CET] <alexpigment> ? [17:42:32 CET] <alexpigment> ritsuka: I'm not trying to be incredulous. I just have to make 100% sure of its limitations before I give up on this encoder [17:44:21 CET] <ritsuka> you can run https://subler.org/downloads/VideoToolboxTest.zip and see the supported keys for each codec [17:49:31 CET] <alexpigment> ritsuka: thanks. apparently I need to update macOS to test this, so I'll check it out afterward [17:53:46 CET] <kepstin> alexpigment: there's no reason it couldn't be implemented, but whether it is or not is completely up to apple, not the ffmpeg decs. [17:54:31 CET] <alexpigment> understandable. I was confused initially if ritsuka was saying it wasn't implemented in ffmpeg or videotoolbox, since I didn't see any documentation saying it wasn't available for h.264 [17:54:58 CET] <alexpigment> it sounds like it isn't though, which I'll confirm once this 6gb download/install for the new macOS finishes [18:04:19 CET] <redblob> is there an option or audio filter that can be used to emit silence when there is missing time in the input (like errors/breaks in a TS stream) when converting a video+audio file to an audio-only file? [18:06:12 CET] <redblob> currently if I convert a TS with problems, to an aac output, it will just skip over the bad time and pick up when it can decode again, so a 1hr file with 5 min of issues ends up 55 min long, I want it to be the original hr with silence where the audio isn't there [18:18:47 CET] <adgtl> ping [18:35:39 CET] <teratorn> redblob: perhaps if you do an amix filter with a silent source [18:35:48 CET] <teratorn> redblob: it will automatically "fix" the broken parts [19:05:21 CET] <redblob> teratorn, interesting - thanks I'll give it a try. [19:19:40 CET] <alexpigment> is cehoyos on trac just a dick in general? [19:19:52 CET] <alexpigment> or just mostly a dick? [19:20:39 CET] <JEEB> he can be rather cold and not understanding [19:21:00 CET] <JEEB> also one of the few people roaming the tickets. when he understands the issue he will attempt to do something about it, though [19:21:04 CET] <alexpigment> seems like it [19:22:19 CET] <Netun0> Is It possible for any reason that x11grab are working just fine to save in file and really doesn't in go with rtmp://? because I can't do it work, already did all kind of combinations in command. lol [19:22:24 CET] <BtbN> There are a lot of weird and annoying people reporting stuff on track. So I can understand why he behaves like a better bot a lot of the times. [19:23:46 CET] <JEEB> yes, he will template the first response or responses [19:23:49 CET] <sfan5> alexpigment: I'd definitely say it is the issue reporters responsibility to verify that the issue is still present on HEAD. [19:24:31 CET] <alexpigment> sfan5: you'll have to pardon my ignorance on this, but I'm not an ffmpeg developer, and I don't even really know what HEAD means. i did build ffmpeg yesterday though [19:24:38 CET] <alexpigment> and noted that in the issue [19:25:56 CET] <JEEB> alexpigment: he just wants "I tested this with the current master" or so [19:26:03 CET] <JEEB> HEAD means the tip of master usually [19:26:05 CET] <sfan5> " test current FFmpeg git head" == clone this https://github.com/ffmpeg/ffmpeg, compile it and verify that the same stuff happens [19:26:18 CET] <JEEB> > linking to the github mirror [19:26:28 CET] <JEEB> https://git.videolan.org/git/ffmpeg.git , was it? [19:26:48 CET] <alexpigment> i built with brew install ffmpeg [19:27:00 CET] <sfan5> i think brew has a --HEAD flag or something similar [19:27:27 CET] <sfan5> JEEB: it's a lot faster than the ffmpeg.org git [19:27:44 CET] <alexpigment> sfan5: thanks [19:28:51 CET] <alexpigment> at any rate, i'm not trying to say there's a reason for checking the newest available code. I just think it's a dumb move to come into an issue, say it's not valid because of some seemingly unwritten rule, and then assign me with more work. like, take less time and just copy and paste the information expressly given in the issue details [19:29:04 CET] <JEEB> sfan5: ffmpeg.org should anyways be videolan.org [19:29:20 CET] <JEEB> someone just decided they wanted some redirection [19:29:22 CET] <alexpigment> er, not trying to say there's *not* a reason [19:29:49 CET] <JEEB> alexpigment: it's a template response to make sure the thing still happens on the tip [19:29:50 CET] <sfan5> you know he might not have a mac? [19:30:03 CET] <alexpigment> sfan5: right, and that's why he shouldn't be commenting on the issue at all [19:30:13 CET] <alexpigment> that's exactly my point [19:30:23 CET] <alexpigment> stay out of issues that do not concern you [19:30:34 CET] <alexpigment> especially when all the relevant information is there [19:30:51 CET] <alexpigment> and the bug submission template has been followed to a T [19:31:01 CET] <sfan5> i would agree with you if he was an outsider [19:31:23 CET] <sfan5> but it's the "job" of project-affiliated devs to categorize issues and ascertain whether it's a "real" issue or not [19:31:35 CET] <alexpigment> sfan5: I don't give people passes like that. good developers are dicks too. i'm not questioning his developer skills. i'm questioning his people skills [19:33:28 CET] <sfan5> hmm yea i guess i can agree with that [19:33:34 CET] <alexpigment> so now I have to spend the next 30 minutes following these unwritten rules and recompiling to verify an issue that is 99.999% certain to still be an issue, just because some person that was never socially adjusted can have some extra details that he still won't do anything with because he probably doesn't have a mac [19:33:52 CET] <alexpigment> hence my frustration [19:33:54 CET] <sfan5> but as BtbN has said, it's not surprising considering the shit FOSS developers always have to deal with [19:33:55 CET] <alexpigment> end of rant :) [19:45:23 CET] <jkqxz> alexpigment: You got what you paid for. [19:45:35 CET] <jkqxz> Also, while you may be 99.999% certain, you are also wrong. [19:46:53 CET] <alexpigment> jkqxz: thanks [19:46:59 CET] <jkqxz> Hardware codecs are now annotated with metadata which provides that information to an API user, and the ffmpeg utility uses it to determine whether a device is needed. [19:47:49 CET] <ritsuka> alexpigment: which version of macOS are you running? [19:47:49 CET] <jkqxz> (Which was not possible in previous versions, hence the message.) [19:50:36 CET] <alexpigment> ritsuka: just updated to 10.13.2 a few minutes ago to test the project you linked me to [19:52:36 CET] <alexpigment> jkqxz: are you implying that there should be a warning? [19:52:48 CET] <alexpigment> why have a warning if the default case gives you that warning? [19:53:53 CET] <alexpigment> anyway, still building over here on this Core M... [19:55:08 CET] <jkqxz> If you have an encoder which requires a device and you don't provide one, yes there should be a warning. [19:55:34 CET] <alexpigment> jkqxz: x264 requires a device and it doesn't make you list your CPU [19:55:40 CET] <alexpigment> it assumes you have one [19:55:49 CET] <alexpigment> nvenc requires a device and it doesn't make you list your gpu [19:55:54 CET] <alexpigment> it assumes you have one [19:56:00 CET] <alexpigment> specifically assumes you have exactly one [19:56:12 CET] <alexpigment> multi-gpu situations are opt-in [19:56:22 CET] <alexpigment> you don't warn for the common case [19:56:32 CET] <jkqxz> nvenc inherits the device from its input frames. [19:56:34 CET] <alexpigment> that's not logically in any field [19:56:51 CET] <alexpigment> *logical [19:57:22 CET] <BtbN> nvenc also does not have a software-fallback. [19:57:25 CET] <alexpigment> jkqxz: hear me out. if you warn in a default case where the vast majority of users will be, and you don't tell the user what to even do to remedy such warnings, that is bad design [19:57:43 CET] <jkqxz> Anyway, here "device" means "some sort of hardware device exposed by the generic hardware device framework". [19:57:56 CET] <alexpigment> a) you should not warn in the default case, b) when you do have to warn (in the non-default case) you provide suggestions [19:58:25 CET] <alexpigment> jkqxz: you're speaking from a developer's point of view, and in this case, the user is who you should be focusing on [19:58:48 CET] <alexpigment> there is a warning given that does not provide any suggestions [19:59:11 CET] <alexpigment> and ignoring the warning is somehow the correct solution [19:59:46 CET] <jkqxz> For the videotoolbox case. [19:59:51 CET] <alexpigment> there is no logic there, regardless of the technical explanation of why the code does this [20:00:40 CET] <alexpigment> anyone who's ever written software knows that there's a reason why developers do not run companies. developers are notoriously terrible at making sound end-user decisions [20:01:02 CET] <alexpigment> and i've met very very few developers who do not make terrible end-user decisions [20:01:24 CET] <alexpigment> end of second rant (which I didn't start) [20:06:06 CET] <jkqxz> I guess from my point of view ffmpeg is fundamentally a tool for developers. Using it without understanding what is going on is bound to lead to confusion and pain. [20:07:22 CET] <alexpigment> jkqxz: I do get that distinct vibe around here. given that it's a powerful tool and google search often brings up results with explicit instructions on how to solve a specific problem with ffmpeg, I don't really see it that way [20:07:30 CET] <jkqxz> So making things which are friendly to people who don't understand what is going on is not, from my point of view, a priority. [20:07:39 CET] <alexpigment> I obviously do not have stats, but I'd say the ratio of non-dev to dev is probably a lot higher than you'd think [20:08:23 CET] <alexpigment> jkqxz: well, I'm certainly not a dev. perhaps I was personally confused by the message and had no idea what to do about it [20:09:41 CET] <alexpigment> anyway, I'm not trying to make enemies here. I want to get these hardware encoders from the state they're currently in to something that has a similar place as x264 based on a particular use-case [20:09:48 CET] <jkqxz> (Hence also trying to make people understand what is going on, rather than just answering questions.) [20:10:20 CET] <alexpigment> jkqxz: yes, but please understand that a warning that occurs in a default case without any suggestions for remedying it is not acceptable in any scenario [20:10:38 CET] <alexpigment> I would fire a developer right on the spot if they tried to defend that [20:10:56 CET] <alexpigment> it's like 10 Commandments level of wrong [20:20:11 CET] <Netun0> someone available to help me out setup a command line ffmpeg to stream with x11grab from a aws ec2 to periscope and/or youtube? [21:10:52 CET] <SpeakerToMeat> Hello [21:11:22 CET] <SpeakerToMeat> Question, is mxf_opatom format OP1a? ANy way to output OP1a compatible MXF from ff? [21:12:38 CET] <alexpigment> SpeakerToMeat: i was helping someone with this recently. I believe they are the same, based on my interaction with that person [21:12:56 CET] <alexpigment> the regular mxf muxer will require that you have a video stream, so it won't work for audio streams [21:13:04 CET] <SpeakerToMeat> ok, thank you alexpigment [21:13:05 CET] <alexpigment> mxf_opatom will allow you to create those streams [21:13:35 CET] <SpeakerToMeat> alexpigment: Yes, I'm just doing a test, I have an xdcam sourced mpeg2 inside a mov, and I want to move it to MXF OP1a (the expected for xdcam) without transcoding. [21:14:01 CET] <SpeakerToMeat> I found something about using ffmbc but I preffer to use ffmpeg whenever possible [21:29:57 CET] <ArsenArsen> how do I set the avfoundation video frame location? [21:49:56 CET] <php67> hi, I just tried to convert a bmp to jpg with ffmpeg -i 01.bmp 01.jpg It works but the jpg image is a bit grumsy. Any chance to adjust the quality of the jpg from ffmpeg? [21:50:24 CET] <durandal_1707> php67: -qscale 0? [21:50:38 CET] <php67> I'll try brb [21:53:30 CET] <php67> -qscale 0 didnt work but then I tried -qscale 2 cause I read somewhere it goes from 2-31 or something.. but with 2 is much better thx. [21:53:49 CET] <durandal_1707> yea [21:53:59 CET] <kepstin> yeah, the jpeg encoder defaults to -qmin 2, iirc [21:54:12 CET] <kepstin> you can change that, but 2 should already be pretty decent [21:54:39 CET] <alexpigment> going down to 0 on a jpeg is getting close to defeating the purpose of jpeg (over PNG, for example) anyway [21:55:14 CET] <php67> would it be better with png? [21:55:33 CET] <alexpigment> php67: if there are a lot of solid colors and also text, yes [21:56:06 CET] <alexpigment> in other words, if it's purely synthetic content, png is usually what you'd use. if it's a photo that was taken, jpeg is usually better [21:57:51 CET] <php67> wow my bmp is 1.44mb and the png I just generated is 71kb and I cant see any major diff :) [21:58:04 CET] <alexpigment> you shouldn't be able to see a difference [21:58:06 CET] <alexpigment> it's a lossless codec [22:00:35 CET] <php67> thx im amazed. So now if I want to convert a bunch of bmp in same folder into a bunch of png in same folder is this correct then? ffmpeg -i *.bmp -qscale 2 %03d.png [22:01:45 CET] <kepstin> php67: no, ffmpeg can't do batch conversion like that by itself. [22:02:06 CET] <kepstin> php67: (you can write a shell or batch script loop that runs ffmpeg a bunch of times, tho) [22:02:26 CET] <alexpigment> you can also get rid of the qscale 2 by the way [22:02:39 CET] <alexpigment> png is lossless so I'm guessing it ignores qscale completely [22:02:58 CET] <php67> I'll try see if there is a diff. [22:03:42 CET] <php67> no diff.. so -qscale 2 is not nessesary [22:04:37 CET] <php67> the %03d.png would work I think if instead of bmp it was a movieformat like ex. mpeg or avi etc. [22:04:42 CET] <ArsenArsen> how do I set the avfoundation video frame location? [22:06:48 CET] <alexpigment> php67: yes, because that basically is saying create a PNG for every frame in the source video. the input in this case is a single frame as well. as kepstin said, you need a script to actually run ffmpeg multiple times because each one has a new infile and outfile [22:08:33 CET] <php67> Oki thanks for the help, long live ffmpeg :) ..I'll try make a batch with loop tc&merychristmas :) [22:28:40 CET] <alexpigment> ok, I've got a weird one that I don't fully understand. I'm testing with the AMF encoder. When I use MP4 as my output container and play in Windows Media Player, high motion scenes will cause all kinds of visual garbage (colors will get weird, heavy macroblocks, etc) [22:28:54 CET] <alexpigment> playing the same video in VLC doesn't result in the same problem [22:29:10 CET] <alexpigment> outputting to MKV and playing in Windows Media Player doesn't cause the problem [22:29:30 CET] <alexpigment> using another hardware codec (e.g. NVENC) with similar settings in mp4 output doesn't cause the same problem [22:29:40 CET] <alexpigment> any ideas what this would point to? [22:32:56 CET] <jkqxz> Can you post an example stream? [22:33:11 CET] <jkqxz> (I didn't see that when testing, but I didn't run it on anything particularly nasty.) [22:33:13 CET] <teratorn> redblob: did it work? [22:33:28 CET] <alexpigment> jkqxz: yes, give me 5 [22:33:34 CET] <alexpigment> (minutes) [22:41:02 CET] <ChocolateArmpits> Has anyone tried to produce an encoding table that would suggest optimal settings for given conditions? For example specifying intended bitrate would give optimal preset and resolution settings, possibly suggesting two pass encoding for added benefit? [22:41:08 CET] Action: kepstin has no idea what the 'amf' encoder is, there's nothing obvious in ffmpeg by that name? [22:41:57 CET] <kepstin> ChocolateArmpits: for x264 you don't need a table - it's just "use -crf mode at a quality you like with -preset veryslow, or twopass if you're targetting a specific filesize", done. [22:43:04 CET] <alexpigment> jkqxz: http://s000.tinyupload.com/index.php?file_id=68868310432733014351 [22:43:29 CET] <ChocolateArmpits> kepstin, well sometimes the only option is to reduce resolution, those options do not help at that by themselves. [22:44:08 CET] <alexpigment> jkqxz: command was https://pastebin.com/VJb3xYat [22:44:27 CET] <alexpigment> note: the video linked is the source video, not the resultant "bad" video [22:45:23 CET] <alexpigment> oddly, the artifacting is different on systems with nvidia and amd graphics, so I suspect this causes hardware decoders or dxva2 to freak out [22:45:43 CET] <kepstin> ChocolateArmpits: ok, but that depends so much on the video content that you can't really do any useful general recommendations, other than say "if you're using two pass and the video quality is too low, try reducing the resolution" :/ [22:46:24 CET] <furq> kepstin: amf is the amd vce encoder [22:46:27 CET] <furq> it got added a few days ago [22:46:54 CET] <kepstin> oh, fun. [22:47:15 CET] <jkqxz> Right, I was about to say that that was made with x264... [22:47:18 CET] <alexpigment> kepstin: what's more fun is the sheer lack of b-frames ;) [22:47:19 CET] <jkqxz> I was meaning the result? [22:47:28 CET] <jkqxz> Since it will likely be system-dependent. [22:47:31 CET] <alexpigment> jkqxz: coming up [22:48:29 CET] <alexpigment> jkqxz: http://s000.tinyupload.com/index.php?file_id=50058129558109292999 [22:48:50 CET] <jkqxz> I suspect those rate options won't do anything when you've specified the QP values, but I don't actually know. [22:48:52 CET] <alexpigment> i should note that i just added -g 30 to my command line to exacerbate the issue, although it occurs with the standard gop length as well [22:48:58 CET] <jkqxz> They all get passed to the driver, so maybe. [22:48:59 CET] <kepstin> the 'amf' name is confusing, because iirc isn't amf the name of the serialization used in flv/rtmp? [22:49:29 CET] <alexpigment> jkqxz: they're there because I was trying to mimic a virgin test against Staxrip. it occurs with much simpler commands [22:49:45 CET] <alexpigment> basically i compare against staxrip to determine if it's an ffmpeg-specific thing [22:50:13 CET] <kepstin> I guess this AMF stuff is specific to windows? [22:50:37 CET] <kepstin> (I presume this'll be exposed via vaapi or vdpau or something on linux, maybe) [22:50:39 CET] <alexpigment> kepstin: yeah, I think linux would be through vaapi [22:50:54 CET] <jkqxz> Currently. They have said they will do it on Linux, but it will probably be in the crazy proprietary driver and therefore not very useful. [22:53:16 CET] <alexpigment> jkqxz: let me know if you aren't seeing the issue on your end. I've verified it on two Windows 7 systems, but I haven't looked at Win10 [22:53:43 CET] <ChocolateArmpits> kepstin, well I would surely like it hands free. ffmpeg recently got two vmaf based filters that measure video quality. My idea is to run tests involving different sets of video that have different motion levels, repeat this for different resolutions vs presets vs pass count and receive quality score. Under given bitrate constraints and knowing the amount of motion, the previous data can be used to give settings for optimal quality. [22:53:52 CET] <jkqxz> Just in that video I already see brokenness at the top of frame 2. [22:53:52 CET] <miller7> can I use two -c copy outputs with ffmpeg? I'm trying to but only the first one seems to work [22:54:49 CET] <kepstin> huh, the x.org radeon feature page says vaapi support is "DONE" up to artic islands (amdgpu kernel driver), apparently via some code in mesa. [22:55:29 CET] <kepstin> who knows if it actually works :/ [22:55:41 CET] <jkqxz> VAAPI on AMD is completely fine for decode. [22:55:46 CET] <jkqxz> It's not so good for encoding. [22:56:09 CET] <alexpigment> i'm kinda regretting buying an rx 550 for testing. it sounds like the vega series has b-frame support [22:56:23 CET] <jkqxz> ? I get B-frames from a GCN 2. [22:56:31 CET] <jkqxz> You don't seem to have any here. [22:56:32 CET] <alexpigment> really? [22:56:38 CET] <jkqxz> Yes. [22:56:54 CET] <alexpigment> what card exactly? [22:57:50 CET] <jkqxz> Bonaire Pro. [22:58:31 CET] <alexpigment> hmmm [22:58:49 CET] <alexpigment> i looked this up yesterday and found random forum talk that seemed to indicate polaris chips don't have b-frames [22:59:32 CET] <alexpigment> https://github.com/Xaymar/obs-studio_amf-encoder-plugin/wiki/Hardware-VCE3.4 [22:59:43 CET] <alexpigment> "Version 3.4 added support for H265/HEVC encoding at the cost of reduced throughput in H264/AVC and H264/SVC encoding and also losing the ability to encode B-Frames." [23:00:27 CET] <alexpigment> good ol' amd doing what they do best [23:00:29 CET] <miller7> https://pastebin.com/ugVSkMZu Command works fine (creates mp4 files and publishes stream). It does not create JPG file though. Any pointers? [23:01:01 CET] <miller7> if I remove the first -c copy, it works as expected [23:01:52 CET] <kepstin> miller7: what format is your camera actually producing, mjpeg? [23:02:37 CET] <miller7> kepstin: is there a command to check it? ffmpeg -i <input> ? [23:03:17 CET] <sfan5> ffprobe /dev/camera should work [23:03:29 CET] <sfan5> also the second -c copy would need to be just before the jpg filename [23:03:32 CET] <kepstin> "ffmpeg -list_formats all -i /dev/video0" or so will list everything the camera supports [23:03:55 CET] <kepstin> nah, the positioning is fine, it just has to be after the first output file and before the second output file [23:04:18 CET] <miller7> input #0, mpegts [23:04:43 CET] <jkqxz> alexpigment: <http://sprunge.us/GiQM> [23:04:57 CET] <kepstin> miller7: please pastebin the complete output [23:05:17 CET] <alexpigment> jkqxz: what's the context? [23:05:48 CET] <alexpigment> are you showing me that yours has b frames? [23:08:11 CET] <jkqxz> Yes. I'm just looking at encoding your file now. [23:09:16 CET] <alexpigment> jkqxz: yeah, I trust that it lets you on your end. I guess I just bought the wrong series of card. was really just looking for a middle-of-the-road chip from a recent gen, and the only option was the 550 [23:09:49 CET] <alexpigment> oh well, it wasn't the most expensive card in the world [23:10:04 CET] <jkqxz> It gives output which is broken in WMP as well for me. [23:10:07 CET] <jkqxz> Works in mpv. [23:10:42 CET] <alexpigment> jkqxz: yeah, I just don't have the knowledge to even know what that would mean. I really do think it's something related to decoding through hardware though [23:11:12 CET] <alexpigment> as if the MP4 container has info that is incorrect, and the hardware decoders are using the info [23:11:26 CET] <jkqxz> <http://ixia.jkqxz.net/~mrt/ffmpeg/broken_amf.mp4> is my output. [23:11:51 CET] <alexpigment> yep [23:11:58 CET] <miller7> kepstin: You were right. The format of the input has the problem. [23:12:53 CET] <kepstin> miller7: if your input is not mjpeg, you can't use "-c copy" to save to a jpeg file, you have to transcode it. [23:13:06 CET] <jkqxz> alexpigment: Maybe send it to the AMD guy on the ffmpeg ML? [23:13:27 CET] <alexpigment> jkqxz: mikhail? [23:13:30 CET] <jkqxz> Yeah. [23:13:37 CET] <alexpigment> ok, I'll do that [23:13:46 CET] <jkqxz> Or open a bug on trac and point him at it. [23:14:00 CET] <alexpigment> still though, what does it mean if it's just MP4 output? [23:14:13 CET] <alexpigment> i doubt his code has anything to do with the mp4 container [23:14:28 CET] <alexpigment> although it does seem specific to AMF [23:14:33 CET] <alexpigment> ok, I just talked myself into a circle [23:14:38 CET] <alexpigment> I'll email him [23:14:39 CET] <jkqxz> This is a really trivial stream for the container (I dropped the audio in mine, too). [23:14:48 CET] <jkqxz> So I think it must be AMD's problem. [23:14:56 CET] <jkqxz> What else does WMP play? [23:15:16 CET] <jkqxz> Can I put H.264 in a WMV container? [23:15:17 CET] <alexpigment> jkqxz: ts, mkv, mov(ish), etc [23:15:28 CET] <alexpigment> probably not officially, but I'm sure it'll play it [23:15:29 CET] <jkqxz> (ASF, whatever it is.) [23:15:34 CET] <alexpigment> I just compared it with MKV [23:15:42 CET] <alexpigment> but I didn't go further than that [23:16:14 CET] <jkqxz> Hmm, yeah. It works in an ASF container. [23:16:15 CET] <miller7> kepstin: thanks a lot for the assistance [23:16:17 CET] <jkqxz> That's pretty weird. [23:17:23 CET] <jkqxz> The timestamps aren't obviously doing anything funny. I've no idea what else to suggest as a possible container difference. [23:17:45 CET] <alexpigment> ts is also broken [23:17:58 CET] <alexpigment> although i feel like ffmpeg's ts implementation is generally broken [23:18:08 CET] <alexpigment> mov broken [23:18:39 CET] <alexpigment> hmmmm, avi and wmv are fine [23:18:48 CET] <alexpigment> i know avi doesn't officially support b-frames [23:19:20 CET] <alexpigment> is it possible it's related to something about b-frame metadata (even though mine isn't making b-frames) [23:20:23 CET] <jkqxz> If I enable B-frames it's crazy broken. [23:20:46 CET] <alexpigment> are b frames bigger than p frames? [23:21:06 CET] <jkqxz> A lot smaller. [23:21:17 CET] <alexpigment> ok, well that theory is out [23:21:54 CET] <jkqxz> <http://ixia.jkqxz.net/~mrt/ffmpeg/broken_amf_bframes.mp4> [23:22:32 CET] <alexpigment> yeah, that one got nice and choppy at the end for me ;) [23:22:58 CET] <jkqxz> It's like WMP is just picking totally the wrong reference frame at times. [23:23:06 CET] <alexpigment> right [23:24:48 CET] <jkqxz> Can I commend to you the merits of only using ffmpeg-based players which do not do that? :) [23:29:06 CET] <jkqxz> ffmpeg output does agree exactly with the reference decoder. The stream is in some sense "correct". [23:29:22 CET] <alexpigment> sorry back [23:30:02 CET] <jkqxz> (All 1866240000 bytes of it.) [23:30:17 CET] <alexpigment> jkqxz: that's an understandable position. however, if you create something that exposes a bug in the player that 90%+ of people use, it's kinda your bug at that point [23:30:30 CET] <alexpigment> sadly [23:31:19 CET] <rmbarbosa> hello good people [23:31:29 CET] <jkqxz> Doesn't everyone play videos in chrome nowadays? [23:31:50 CET] <alexpigment> jkqxz: i'll grant you this technicality :) [23:32:01 CET] <rmbarbosa> i'm having a problem compiling ffmpeg on windows 64 with visual studio 2017 and msys2 64 [23:32:23 CET] <rmbarbosa> everything is smooth running until the ./configure [23:32:41 CET] <rmbarbosa> ./configure -toolchain=msvc -arch=x86_64 -enable-yasm -enable-asm -enable-static -disable-examples -disable-programs -enable-libx264 -enable-gpl -prefix=./install [23:32:52 CET] <rmbarbosa> throws: [23:32:53 CET] <rmbarbosa> Unknown option "-toolchain=msvc". [23:33:07 CET] <rmbarbosa> has anybody ever had this issue?? [23:33:17 CET] <rmbarbosa> thank you... [23:34:30 CET] <alexpigment> rmbarbosa: is it possible this is related? https://github.com/telegramdesktop/tdesktop/issues/2646 [23:34:43 CET] <jkqxz> rmbarbosa: What version? That really shouldn't be an unknown option. [23:35:26 CET] <jkqxz> Oh, that might make more sense. [23:35:29 CET] <SortaCore> I'm using VS 2015, msys2 64, works ok [23:35:52 CET] <rmbarbosa> this happened to me today in the beginning of the afternoor [23:36:10 CET] <rmbarbosa> then for some unexplicable reason it worked... [23:36:17 CET] <rmbarbosa> then i closed the bash [23:36:36 CET] <rmbarbosa> and when i opened it again is stuck on the same problem [23:36:40 CET] <SortaCore> you're meant to run the bash from VS 2015 command prompt [23:36:52 CET] <rmbarbosa> yes... well to be more clear [23:37:01 CET] <miller7> Any suggestion for hardware to use with my linux box to capture full HD from DVB-T2 free-to-air channel? I want to connect an antenna to my linux so I can capture and save the stream. [23:37:03 CET] <rmbarbosa> i've opened a terminal cmd [23:37:25 CET] <rmbarbosa> called vcvars64.bat [23:37:30 CET] <alexpigment> miller7: does hauppauge make anything linux compatible? I use a lot of their hardware for OTA capture [23:37:37 CET] <rmbarbosa> then C:\msys64\msys2_shell.cmd -mingw64 -use-full-path [23:37:59 CET] <rmbarbosa> i've checked the "where link" and "where cl" [23:38:06 CET] <miller7> alexpigment: I don't know. Never done this before [23:38:08 CET] <rmbarbosa> all is pointing to the correct locations [23:38:15 CET] <SortaCore> yea, this looks valid so far [23:38:20 CET] <SortaCore> did you CD into ffmpeg? [23:38:27 CET] <rmbarbosa> but the configure just not working [23:38:29 CET] <SortaCore> from bash [23:38:41 CET] <alexpigment> miller7: https://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-dualHD [23:38:41 CET] <rmbarbosa> yes i've cd to ffmpeg [23:38:42 CET] <miller7> alexpigment: http://www.hauppauge.com/site/support/linux.html has many different models. Any particular you suggest? [23:39:09 CET] <miller7> thanks :) [23:39:17 CET] <rmbarbosa> 'm using vs2017 [23:39:20 CET] <SortaCore> I can download latest git and try again [23:39:25 CET] <alexpigment> miller7: i'd recommend dualHD or quadHD. i've used them both. i've also used the 955Q, but it only has one tuner [23:39:28 CET] <SortaCore> but I'm using vs2015, it may not support 2017 [23:39:37 CET] <rmbarbosa> humm [23:40:06 CET] <SortaCore> the configure has a log file you can check [23:40:52 CET] <SortaCore> look for under ffmpeg\ffbuild\config.log [23:41:17 CET] <rmbarbosa> ok.. i will look at the config.log... [23:42:50 CET] <miller7> alexpigment: How can I use DVB-C and DVB-T2 at the same time with it? It only has 1 cable antenna connection [23:43:15 CET] <alexpigment> miller7: the dualhd and quadHD are split internally [23:43:30 CET] <rmbarbosa> is there a way to clean the configure? and restart from clean? [23:43:31 CET] <alexpigment> but if you're trying to hardwire one to an antenna and one to cable, you'll need two cards probably [23:45:04 CET] <Li> I'm wondering if there is anyway to watch video in linux without GUI! and no one seems to have a proper answer in #linux channel. Can anyone help here? [23:45:47 CET] <jkqxz> You mean at the console, without X or anything like that? [23:45:50 CET] <alexpigment> Li: https://www.maketecheasier.com/mpv-cli-media-player/ [23:45:59 CET] <jkqxz> DRM output in mpv, yeah. [23:46:34 CET] <jkqxz> Oh, that's not quite the same thing. [23:46:52 CET] <Li> jkqxz: this is the second time I read the word "output" in this context without knowing what it means! [23:46:53 CET] <jkqxz> But mpv is probably the answer, whichever your question was :) [23:47:52 CET] <miller7> alexpigment: Have you used this box? HD PVR 2 [23:47:53 CET] <jkqxz> "output" meaning the method it is using the display the frames. [23:47:57 CET] <alexpigment> maybe he wants the video to play in ascii? ;) [23:48:16 CET] <alexpigment> miller7: yes, almost every single day [23:48:32 CET] <alexpigment> but it's for capture streams via HDMI, not OTA [23:48:41 CET] <alexpigment> *capturing [23:49:08 CET] <miller7> alexpigment: I understand. How can I get the stream from it? [23:49:11 CET] <alexpigment> it also allows you to capture the original dolby digital 5.1 audio, so it's the only one I know that can do that [23:49:23 CET] <Li> thanks guys i'll check mpv [23:49:32 CET] <alexpigment> miller7: I'm not sure really. I just use the Hauppauge Capture app for Windows that it ships with [23:49:57 CET] <miller7> I would like to stream my laptop screen etc and show it on a webpage. So if it somehow streams to an endpoint, it's nice [23:50:47 CET] <alexpigment> miller7: i'm sure there's a way to do what you're doing. i'm just not the person to help. I've used the products, but only in the normal context of how to use them [23:51:00 CET] <miller7> thanks a lot [23:51:17 CET] <Li> oh Ok, now i recall trying that mpv before but it works only if I'm on full fledged linux desktop system [23:51:52 CET] <Li> I'm trying to play video from command line terminal distro without launching x windows [23:52:29 CET] <jkqxz> Li: mpv --vo=drm [00:00:00 CET] --- Wed Dec 13 2017

1 0

ffmpeg-devel.log.20171211
by burek 12 Dec '17

12 Dec '17

[00:10:05 CET] <BBB> atomnuker: I dont see the problem with using mutexes, I mean, were talking about codec registration, which happens a 100 times in the application lifetime; did you know we decode 100s of coefficients per block, of which we have 100s per frame, of which we have 100s per stream in a sequence, of which we have many in a media file, of which many may be processed during the lifetime of an application? atomic codec registrati [00:10:05 CET] <BBB> reasonable person would quality as premature optimization - but hey, who am I, I know nothing about codecs or speed, right? [00:14:12 CET] <nevcairiel> in reality those registers functions are never going to be an issue anyway [00:14:24 CET] <nevcairiel> an external api user can't realistically call them with any valid values [00:14:35 CET] <nevcairiel> and avcodec_register_all etc use pthread_once [00:19:46 CET] <nevcairiel> basically, if we just were to make them private, noone would miss them, and all would be solved [00:23:10 CET] <nevcairiel> using a static mutex even with pthread_once to init is still has the bad aftertaste of "leaking" the mutex, since it can never be freed [00:23:31 CET] <JEEB> yup [00:28:13 CET] <iive> can't we use pthread_once for avfilter_register_all too? [00:28:56 CET] <nevcairiel> it uses that [00:29:40 CET] <nevcairiel> but theoretically avfilter_register is public api and could be called from any thread at any time ... even if noone is ever going to do so, but shrug [00:46:01 CET] <cone-761> ffmpeg 03Tristan Matthews 07master:f6161fccf8c5: rtsp: only break on parse_rtsp_message on error [00:46:02 CET] <cone-761> ffmpeg 03James Almer 07master:dae6d27aa0b0: Merge commit 'f6161fccf8c5720ceac1ed1df8ba60ff8fed69f5' [00:51:10 CET] <cone-761> ffmpeg 03Mark Thompson 07master:7bf3f380466e: cbs: Add padding to slice data allocations [00:51:11 CET] <cone-761> ffmpeg 03Mark Thompson 07master:5a6707e49b77: cbs_mpeg2: Fix marker_bit type [00:51:12 CET] <cone-761> ffmpeg 03James Almer 07master:f750a0bcfea9: Merge commit '5a6707e49b7710f48d658b2f2591b9a6337fb9b7' [00:58:55 CET] <cone-761> ffmpeg 03Jun Zhao 07master:e7adf2250b43: vaapi_h265: Enable VBR mode [00:58:56 CET] <cone-761> ffmpeg 03Jun Zhao 07master:4b57f064477c: vaapi_h264: Fix VUI max_dec_frame_buffering [00:58:57 CET] <cone-761> ffmpeg 03Mark Thompson 07master:e171022c24c4: vaapi: Make the decode profile matching more explicit [00:58:58 CET] <cone-761> ffmpeg 03Mark Thompson 07master:6679654efe15: vaapi_h264: Add named options for setting profile and level [00:58:59 CET] <cone-761> ffmpeg 03Mark Thompson 07master:3ff8fbbf5a7b: vaapi_h265: Add named options for setting profile and level [00:59:00 CET] <cone-761> ffmpeg 03James Almer 07master:7a10541109cc: Merge commit '3ff8fbbf5a7bc40c09db74d4952364997fd3c611' [01:01:10 CET] <SortaCore> why does av_dict_parse_string have in docs you *may* need to free the returned dict? [01:04:16 CET] <cone-761> ffmpeg 03Alexandra Hájková 07master:7993ec19af39: hevc: Add hevc_get_pixel_4/8/12/16/24/32/48/64 [01:04:17 CET] <cone-761> ffmpeg 03James Almer 07master:dd1ecf093c0f: Merge commit '7993ec19af394fdc58ec64165bc0b12619543a5d' [01:04:18 CET] <cone-761> ffmpeg 03James Almer 07master:bad51e928718: doc/libav-merge: add a line about the skipped HEVC MC arm functions [01:23:18 CET] <BBB> nevcairiel: I think thats a good idea [01:23:27 CET] <BBB> nevcairiel: but Im sure someone uses it now that it was public one day [01:24:04 CET] <cone-761> ffmpeg 03Kieran Kunhya 07master:a83a03af9a84: libavcodec: Move ff_print_debug_info2 to mpegutils.c [01:24:05 CET] <cone-761> ffmpeg 03Kieran Kunhya 07master:918de766f545: h264dec: Remove mpeg4video.h header dependency [01:24:49 CET] <JEEB> BBB: sure, but I don't think it worked properly without hacks? [01:24:57 CET] <JEEB> since you couldn't make your own codecs [01:25:03 CET] <JEEB> (without private symbols) [01:29:45 CET] <BBB> JEEB: I dont know, I think if it only uses external libs, it may be possible [01:29:54 CET] <BBB> JEEB: e.g. something like libvpx can possibly be done outside [01:29:59 CET] <BBB> I Dont know though, never tried [01:30:20 CET] <SortaCore> on another separate note, last year libx264 still used codec instead of codecpar, is that still a problem? [01:32:43 CET] <JEEB> BBB: and here I thought there were definitions that were private ff_ prefixed that were required for an "external" AVCodec etc being registered [01:39:08 CET] <BBB> JEEB: I guess I dont know either :( ohwell [01:39:14 CET] <BBB> but atomics, right? [01:39:16 CET] <BBB> because why not [02:23:25 CET] <atomnuker> durandal_1707: today, today? my alarm clock, I'm flying [03:09:14 CET] <rcombs> so, I need to expose FF_CODEC_PROPERTY_CLOSED_CAPTIONS on AVStream, presumably via codecpar [03:10:29 CET] <rcombs> should I just add a "properties" field to codecpar and copy that field out? (the only other property is "lossless", which also isn't implementation-specific) [03:16:23 CET] <jamrial> that was suggested before but rejected [03:16:32 CET] <jamrial> adding a properties field, i mean [03:37:02 CET] <rcombs> why? [03:39:08 CET] <jamrial> the properties it defines are supposedly not stream parameters or something like that [03:39:40 CET] <jamrial> it was a long time ago, back when we were trying to get ffmpeg.c to work with codecpar [03:39:41 CET] <rcombs> it defines 2 things: "is lossless", and "contains closed captions" [03:40:03 CET] <rcombs> I guess you could argue those are really _packet_ parameters? [03:41:03 CET] <rcombs> but they're definitely not _implementation_ parameters, which would make sense to keep solely on AVCodecContext [04:25:49 CET] <cone-670> ffmpeg 03Steven Liu 07master:08d28ee1823a: avformat/hlsenc: move init operations from write_header to init [04:42:54 CET] <cone-670> ffmpeg 03James Almer 07master:c7a5e80f569d: avcodec/libvpx: remove disabled code [05:15:19 CET] <daksh> I am new here. I want to start contributing to ffmpeg, where do I start? [05:15:38 CET] <Compn> daksh : do you have c programming skills? :) [05:15:49 CET] <daksh> Yes, I do :D [05:15:53 CET] <Compn> nice [05:16:02 CET] <daksh> And I know git too [05:16:27 CET] <Compn> you can start with bugs at http://trac.ffmpeg.org , or subscribe to the ffmpeg-devel mailing list and ask for projects to work on ? [05:16:31 CET] <Compn> or maybe review some patches there [05:16:54 CET] <Compn> just testing if patches build helps [05:17:23 CET] <daksh> I will try and do some of the things that you mentioned [05:17:53 CET] <daksh> I was looking forward to GSoC'18. So I wanted to explore this organisation and contribute first :) [05:18:09 CET] <Compn> ah, that is a great way to start gsoc :) [05:19:20 CET] <daksh> What about you? You are a regular developer here? [05:19:58 CET] <Compn> somewhat , i do irc and mailing list stuff [05:20:05 CET] <Compn> sometimes bug tracker and reviewing patches [05:20:20 CET] <daksh> Oooh nice! [05:20:46 CET] <daksh> There is no Issues tab in https://github.com/FFmpeg/FFmpeg ? :\ [05:21:26 CET] <Compn> we were around before github, so we use videolans servers [05:22:02 CET] <daksh> Oooh, wow [05:22:20 CET] <daksh> Do you have any tags for simple bugs? Just so that I can get started? [05:22:49 CET] <Compn> haha no, thats the problem i think, there is no one who organizes bugs based on complexity [05:23:23 CET] <Compn> i know this makes it more difficult for new developers to join in. i am trying to think of solutions for this [05:24:09 CET] <daksh> Oooh, I see [05:24:37 CET] <daksh> Why don't you guys also have Issues on GitHub now? I guess that would make it much easier for new users to find it (Sorry if this suggestion is stupid) [05:24:51 CET] <daksh> Could you refer some bug to me? That I can test [05:24:59 CET] <Compn> its not sstupid, we get quite a few people who want github stuff [05:25:02 CET] <Compn> sure let me see [05:26:15 CET] Action: Compn digging [05:29:23 CET] <Compn> daksh : http://trac.ffmpeg.org/ticket/6863 [05:29:46 CET] <Compn> daksh : if you want to try connecting an external lib into our makefile and codecs so we can decode / encode with it ? [05:30:03 CET] <Compn> difficulty could be high or low depending on how weird the sdk api is [05:31:23 CET] <daksh> Compn: I have almost no clue about codecs and this. Also, I am not very comfortable with makefiles. Is there an easier task? Or rather first something that I just have to check? [05:31:36 CET] <Compn> sure [05:31:40 CET] <Compn> give me a min [05:32:20 CET] <daksh> Sure [05:35:05 CET] <Compn> ah i was looking at open bugs, need to look at ne wbugs only [05:36:22 CET] <Compn> daksh : http://trac.ffmpeg.org/ticket/6890 [05:36:32 CET] <Compn> you could hunt down the string and find out how to replace it [05:38:17 CET] <daksh> "Applying option ab (audio bitrate (please use -b:a)) with argument 160k." is the string to be replaced to? [05:39:28 CET] <Compn> "Applying option b:a (video bitrate (please use -b:v)) with argument 160k." [05:39:36 CET] <Compn> should be replaced to [05:39:44 CET] <Compn> "Applying option b:a (audio bitrate (please use -b:a)) with argument 160k." [05:40:39 CET] <daksh> Sure, I will try and find that :) [05:40:40 CET] <daksh> THank you [05:40:41 CET] <Compn> looks like a copy paste typo [05:40:53 CET] <Compn> you could also verify the bug is there with latest git master [05:41:01 CET] <Compn> no problem :) [05:41:25 CET] <daksh> Though I do not understand what the error message means (and I do not need to understand it, to fix it ) [05:41:57 CET] <daksh> But how do I learn things like these? [05:44:23 CET] <Compn> i guess you can start by reading the docs , http://ffmpeg.org/ffmpeg-all.html [05:44:30 CET] <Compn> careful its a long document [05:44:40 CET] <Compn> shorter portions here http://ffmpeg.org/documentation.html [05:44:47 CET] <daksh> Huge :P [05:44:57 CET] <daksh> having a look at it [05:45:04 CET] <daksh> and a couple of more questions if you dont mind [05:45:10 CET] <Compn> sure [05:46:14 CET] <daksh> 1. I have ffmpeg already installed (I am using a MacOs). If I type 'ffmpeg' on the terminal then it shows the options. So yes it is there. Now how to I develop along with that. Is there a virtual environment kind of thing that I have to make or do I uninstall this and install the development version? How? [05:46:56 CET] <Compn> oh you need a build environment i think [05:47:01 CET] <daksh> 2. The process of submitting patches doesn't seem straight forward as I have seen in other places, where they use github PRs. I saw that you guys don't do that. Do I have to mail it? o.O [05:47:16 CET] <Compn> git has a feature called git send email [05:47:24 CET] <daksh> Umm, what is a build environment? Do you have a webpage regarding this? [05:47:40 CET] <Compn> so you set it up with git, type git send email and it mails the patch to the mailing list :) [05:47:52 CET] <Compn> let me see... i dont think we have a guide ourselfs [05:48:26 CET] <daksh> But then how is the review process and all? Maybe you guys want me to change somethings in the patch. So how is the communication done then? [05:48:33 CET] <Compn> oh we do, https://trac.ffmpeg.org/wiki/CompilationGuide/macOS [05:48:35 CET] <Compn> read that ! :) [05:48:52 CET] <Compn> the communication is done on the mailing list [05:48:59 CET] <Compn> (emails) [05:49:31 CET] <daksh> Thanks thanks :D [05:51:44 CET] <Compn> i know it can be difficult to learn a new system , but it will be an experience! maybe you will like it better than github? nahhh [05:52:06 CET] <daksh> Hehe xP [05:52:46 CET] <daksh> I dont think the answer I was looking for is at https://trac.ffmpeg.org/wiki/CompilationGuide/macOS, although it is pretty helpful, it does not tell me how to do I simultaneous install [05:53:26 CET] <daksh> I mean, can I develop on another `build environment` kind of thing, rather than having/removing my system wide ffmpeg installation [05:54:02 CET] <Compn> ah well when you build ffmpeg in homebrew , just do a "make" not "make install" , this means you can run that new ffmpeg by typing ./ffmpeg. where ffmpeg without the ./ will run the normal system installed version [05:54:20 CET] <Compn> so yes, multiple simultaneous versions [05:54:28 CET] <Compn> just have to have different directories of ffmpeg [05:55:02 CET] <Compn> there are a lot of terminal things you have to learn about using a command line program , it takes a while :) [05:55:29 CET] <daksh> Well a journey it is! [05:55:30 CET] <Compn> with xcode that is [05:55:33 CET] <Compn> not homebrew ... [05:55:42 CET] <Compn> sorry i got it mixed up, been a while since i compiled on osx [05:55:46 CET] <daksh> Yeah I was just about to ask you that [05:56:14 CET] <Compn> looks like homebrew will install it system wide, probably not what you want [05:56:45 CET] <Compn> more stuff in our wiki https://trac.ffmpeg.org/wiki [05:57:28 CET] <daksh> Yeah, that is not what I want. I already have a system wide installed version. I want a separate one inside the directory [05:58:25 CET] <Compn> after you get xcode setup, grab the dependencies and git ffmpeg pull , just do make not make install. when you get to that step anyways, its a lot of steps [05:58:59 CET] <daksh> https://trac.ffmpeg.org/wiki/CompilationGuide/macOS I was looking at that, so what I can understand from it. I will first need to install dependencies (which I guess I could do with brew(?)).. Aahhh I see [05:59:24 CET] <daksh> I see I see [05:59:32 CET] <daksh> ./configure; make. Thats it [05:59:38 CET] <daksh> Sure, I will try that out in a bit :D [05:59:38 CET] <Compn> yep [06:00:08 CET] <Compn> take your time, dont get too discouraged if you run into problems, and write down problems and what works... we can use that to improve our documentation / wiki [06:01:03 CET] <Compn> it can be hard for us to write documentation because we have taken for granite all of the tweaks and skills we have learned [06:01:19 CET] <Compn> r&m joke [06:03:40 CET] <Compn> daksh : its late here, i must be going soon. other people might be on later... [06:04:41 CET] <Compn> daksh : there is also #linux or #help channels here on irc if you get stuck. or you can ask questions about compiling ffmpeg in #ffmpeg too of course [06:05:15 CET] <Compn> we try to separate the developing and bugs/compiling talk to different channels so we dont get lost [06:06:07 CET] <Compn> daksh : what country are you from ? [06:32:51 CET] <daksh> I am from India [06:33:05 CET] <daksh> Compn: Sure, Good night :) [06:40:22 CET] <Compn> night night [08:48:48 CET] <daksh_> I want to use ffmpeg in Python2 to extract audio from a video. How do I go about it? Is there some reliable python library for ffmpeg or should I run a terminal command using python? [08:51:32 CET] <wm4> probably best to invoke ffmpeg CLI as process, because the ffmpeg API is very low level [08:51:39 CET] <wm4> anyway this is a question for #ffmpeg [09:02:11 CET] <daksh_> wm4: I tried asking in #ffmpeg, did not get any response. So I thought it might have belonged here. Sorry [09:10:02 CET] <wm4> technically this channel is for development of ffmpeg, not a #ffmpeg fallback channel [09:17:24 CET] <daksh_> wm4: My apologies [10:34:05 CET] <kwizart> hi there, is there a way to schedule commit 9dde6ab06c48f9447cd16f39bee33569cddb7be4 in master for older branches ? (at least 3.3x and later) [10:34:22 CET] <kwizart> fedora27 at least seems affected by this [10:34:49 CET] <kwizart> apparently it missed the 3.4.1 train, sorry for reporting that late [10:48:14 CET] <JEEB> but fedora 27 doesn't have FFmpeg at ll? [10:48:27 CET] <JEEB> so this is most likely rpmfusion or something [10:48:34 CET] <kwizart> of course it has, it's just not redistributed by Red Hat [10:48:50 CET] Action: kwizart is the rpmfusion project coordinator indeed [10:49:18 CET] <JEEB> and yea, I agree that if that applies to 3.3 it should be back-ported [10:49:37 CET] <wbs> that patch should apply to any maintained branch [10:49:58 CET] Action: JEEB just doesn't know what branches are "maintained" in FFmpeg [10:50:44 CET] <kwizart> I think maintained branches are down to 2.8 ? we are using 2.8 for Enterprise Linux (RHEL, CentOS, etc) [10:51:21 CET] <kwizart> but there: 1/ we don't have such recent binutils, 2/ we don't build for arm(v7,v8) at all [10:51:54 CET] <kwizart> despite we might be in the future [11:25:08 CET] <durandal_1707> michaelni: im more and more convinced that current behaviour of color range paatch is correct [11:27:01 CET] <durandal_1707> michaelni: the alternative is add color range to format conversion, so whenever it changes, it will auto insert scale filter to convert between different color ranges [11:27:26 CET] <durandal_1707> so even more conversions [11:51:15 CET] <durandal_1707> michaelni: if you dont have more arguments than i would be happy to apply patch set [11:51:51 CET] <nevcairiel> doesnt it have to convert between color ranges, or it may end up being the wrong one? [12:00:21 CET] <wm4> durandal_1707: anyway I appreciate that you try to get rid of that crap [12:02:12 CET] <durandal_1707> nevcairiel: so you saying that color range should be added to filter format negotiation? [12:03:21 CET] <nevcairiel> why not? its part of it now through the J type. If a filter doesn't support full range (for some reason, perhaps math would overflow or whatever), then it should not receive full range, or the result will be wrong [12:04:43 CET] <nevcairiel> although range is generally an annoying topic, as some pixel formats are inherently full range by default (ie. rgb) [12:09:57 CET] <wm4> all parameters should be part of negotiation [12:10:11 CET] <wm4> the fact that lavfi currently only supports pixfmt and video size is entirely backwards [12:10:28 CET] <wm4> and as one of the few API users, mpv actually suffers from it [12:11:47 CET] <nevcairiel> luckily i always refused to do much filtering [12:11:55 CET] <nevcairiel> only do deint, thats simple [12:11:59 CET] <nevcairiel> same in/out format, done [12:12:41 CET] <wm4> heh [12:14:11 CET] <durandal_1707> please stop fucking bullshit bikesheding and provide aactual solutions [12:14:31 CET] <durandal_1707> why it must be arrray? [12:17:44 CET] <wm4> because other things (like pixfmt) is an array too [12:17:53 CET] <cwilson_> Hi guys, I was just trying to upload some files to the FTP server at upload.ffmpeg.org but I can't connect. Is anyone else having trouble with it? [12:18:12 CET] <wm4> if we ever add correct handling of colorspace flags etc., those will be arrays too [13:16:08 CET] <durandal_1707> why was fucking custom parameters setup for some filters was increased from 7 yo 8? [13:16:27 CET] <durandal_1707> this is pure fucking shit [13:17:03 CET] <durandal_1707> it is hidden by merge commits [13:17:18 CET] <durandal_1707> who increased number? [19:10:39 CET] <kierank> so, why can't I use fate reliably? [19:11:52 CET] <wm4> you can't? [19:11:54 CET] <JEEB> is there issues with it? [19:12:06 CET] <wm4> does that refer to failing randomly or what? [19:12:58 CET] <kierank> yes [19:13:34 CET] <kierank> https://www.irccloud.com/pastebin/z9GhfAdT/ [19:14:21 CET] <wm4> looks evil [19:14:35 CET] <JEEB> :< [19:14:49 CET] <JEEB> so after some frame delay all are different [19:14:51 CET] <nevcairiel> never seen random h264 tests fail [19:14:55 CET] <kierank> Test api-flac failed. Look at tests/data/fate/api-flac.err for details. [19:15:00 CET] <nevcairiel> with threads? [19:15:02 CET] <JEEB> that IIRC is threaded as well [19:15:09 CET] <JEEB> so I will guess that's got something to do with threads [19:15:22 CET] <kierank> api-flac passes now [19:15:26 CET] <kierank> tests just randomly fail [19:15:35 CET] <JEEB> that's bad [19:15:36 CET] <wm4> bad hardware? [19:15:47 CET] <kierank> nope [19:16:10 CET] <JEEB> the last threading related thing I remember is the atomics stuff [19:16:15 CET] <JEEB> before that I don't remember [19:17:46 CET] <kierank> Test vsynth1-dnxhd-4k-hr-lb failed. Look at tests/data/fate/vsynth1-dnxhd-4k-hr-lb.err for details. [19:18:00 CET] <nevcairiel> are you sure its not hardware [19:19:19 CET] <kierank> no errors in dmesg [19:19:36 CET] <wm4> what's the fate invocation? [19:20:07 CET] <kierank> make fate SAMPLES=fate-suite/ [19:20:22 CET] <kierank> obe@obe:~/ffmpeg-kk$ ./ffmpeg [19:20:22 CET] <kierank> ffmpeg version N-89461-g918de76 Copyright (c) 2000-2017 the FFmpeg developers [19:20:22 CET] <kierank> built with gcc 4.8 (Ubuntu 4.8.5-2ubuntu1~14.04.1 [19:20:41 CET] <nevcairiel> not even parallel make or any threading? definitely not seeing any of that here or on any fate box i run [19:22:03 CET] <kierank> nope [19:24:37 CET] <wm4> strange CPU with unusual feature combination? [19:27:05 CET] <kierank> Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz [19:35:39 CET] <SortaCore> welp windows is now working properly after the update [20:03:36 CET] <nevcairiel> actually it isnt, it just builds again [20:28:30 CET] <jamrial> nevcairiel: just revert the commit that added atomics to the codec locking mechanic [20:28:52 CET] <jamrial> it wasn't even needed or part of the work to remove lavu atomic wrapper usage [20:30:17 CET] <wm4> anyway, the emulation for the cas function is still broken? [20:30:49 CET] <jamrial> nobody touched the c11 wrappers, so yes [20:31:24 CET] <wm4> and the breaking case was the only case these cas functions were used [20:31:44 CET] <wm4> that means if someone tries to use them again we'll have the same situation again [20:31:57 CET] <jamrial> probably [20:32:09 CET] <jamrial> also, it's been almost two months now since the bump. we need to decide when the unstable abi period ends [20:32:34 CET] <wm4> why do we need a stable ABI in what is a dev branch [20:34:15 CET] <jamrial> good question. although i don't think we ever waited until the first post bump release was tagged before [20:36:36 CET] <wm4> IMO it'd be much simpler if we only froze ABI in release branches [20:44:10 CET] <JEEB> kierank: I haven't looked yet, but did upipe have nice code regarding making <the randomness you can get out of MPEG-TS> into monotonically rising timestamps? [20:47:10 CET] <kierank> Yes but quite complex modular arithmetic [20:47:25 CET] <JEEB> ok, that's fine. it gives me hope [20:47:42 CET] <JEEB> (hope is the first thing on the path to destruction, anyways) [20:48:22 CET] <kierank> I would imagine vlc does the same thing [20:49:08 CET] <JEEB> most likely [21:03:10 CET] <nevcairiel> wm4: the cas functions are fine for pointers, or if you need them for anything else, make the type intptr_t, but considering the only cas f unction we had in the old avutil stuff was for pointers, its probably fine. [21:04:22 CET] <wm4> the cas emulation can't work because it's not c11 compatible [21:04:38 CET] <nevcairiel> it can work on any pointer-sized variables just fine [21:04:48 CET] <wm4> it can only work for intptr_t itself [21:04:50 CET] <nevcairiel> it just fell apart here because it was the wrong size argument [21:05:25 CET] <nevcairiel> casts dont show up in assembly, so its fine =p [21:06:09 CET] <wm4> well if the compiler doesn't eat you for strict aliasing violation, and you don't mind the ugly warnings, sure [21:06:26 CET] <nevcairiel> there are no warnings for conversion of pointers to intptr_t [21:06:34 CET] <nevcairiel> thats the point of that type, you can convert pointers to it [21:07:50 CET] <wm4> wat [21:08:03 CET] <nevcairiel> but perhaps you should ask courmisch what he was thinking when he wrote that, he is usually the first one to scream aliasing violations [21:08:03 CET] <wm4> intptr_t* is incompatible to void** [21:08:23 CET] <wm4> yeah, not sure how he could write that [21:08:47 CET] <SortaCore> isn't sizeof(type *) == sizeof(void *)? [21:09:08 CET] <wm4> it's still a strict aliasing violation [21:09:33 CET] <nevcairiel> we violate those everywhere anyway [21:09:44 CET] <wm4> not really [21:09:51 CET] <wm4> av_freep was a big one [21:10:05 CET] <wm4> but that got solved with technically correct nonsense [21:10:36 CET] <nevcairiel> which shows that the entire topic is basically nonsense [21:10:37 CET] <wm4> uint8_t might not be unsigned char in theory, so it could break on implementations which make that a separate type I guess [21:11:14 CET] <wm4> I still sometimes confuse the av_freep argument, so I think that function has a very real toll on readability etc. [21:23:14 CET] <cone-448> ffmpeg 03Hendrik Leppkes 07master:fd542b6f2026: Revert "libavcodec/utils.c: simplify avcodec locking with atomics" [21:37:12 CET] <nevcairiel> hm, i wonder if the recent msvc2017 update causes rmdec to miscompile for some reason, i get odd failures [21:38:04 CET] <BtbN> working as intended (tm) [21:38:17 CET] <nevcairiel> they introduced a bunch of new optimizations in that update [21:38:19 CET] <nevcairiel> so who knows [21:40:42 CET] <wbs> nevcairiel: I'm looking at 2 broken tests for arm64 in the 15.5 update as well; haven't confirmed whether they're bugs in the code or in the compiler yet [21:41:21 CET] <nevcairiel> some weird audio te sts have been failing for ever in 2017, i have been meaning to fully review that [21:41:29 CET] <nevcairiel> but so busy lately [21:41:31 CET] <wbs> right, those aren't in libav [21:42:25 CET] <nevcairiel> guess i never got around to setting up 2017 libav boxes, only 2013 and 2015 there, maybe i should update the 2013 one [21:46:04 CET] <jamrial> gcc trunk (what will be in 8) is also currently miscompiling something [21:46:07 CET] <jamrial> http://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-experimental&ti… [21:46:15 CET] <jamrial> probably the filter in question, owdenoise [21:47:06 CET] <jamrial> i have no idea how to make a working testcate to report this, and gcc bugzilla dislikes reports that say things like "download and compile ffmpeg, download 1gb of samples, then run this test" [21:47:33 CET] <jamrial> at least it's a filter and not the flac decoder, like with gcc 4.9 [21:56:06 CET] <tmm1> jkqxz: so was it decided that hwaccels should have both AV_CODEC_HW_CONFIG_METHOD_AD_HOC and AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX [21:58:57 CET] <nevcairiel> if they support both, then they should [22:20:07 CET] <wm4> applies to mediacodec [22:29:57 CET] <jkqxz> tmm1: Yes. The ff_get_format() code rejects the method if it's not present there. [22:30:45 CET] <jkqxz> While we would like Very Naughty People (such as nevcairiel) to update their code, the old API is technically there still for quite a while. [22:44:23 CET] <cone-448> ffmpeg 03Paul B Mahol 07master:cbd524b26cd8: avfilter/avfiltergraph: remove ugly dead code [22:45:48 CET] <nevcairiel> i like my code, it works and gives me a maximum of control [22:46:42 CET] <nevcairiel> i'm sure there would be a range of regressions if i change it [22:50:41 CET] <tmm1> in mateo`'s patch he added a new AVCodecHWConfigInternal entry for HW_DEVICE_CTX.. that should be the same as bitwise-or together right? [22:55:20 CET] <cone-448> ffmpeg 03Lou Logan 07master:555119bd7625: doc/filters: re-arrange options for testsrc family [00:00:00 CET] --- Tue Dec 12 2017

1 0

ffmpeg.log.20171211
by burek 12 Dec '17

12 Dec '17

[00:29:37 CET] <Lunchbox> ok as we were cutting the base of the tree and drilling the hole to fit it onto the christmas tree stand [00:29:41 CET] <Lunchbox> i thought to myself [00:29:49 CET] <Lunchbox> oh im encoding my videos using quicksync [00:29:55 CET] <Lunchbox> is that the problem here? [00:30:26 CET] <JEEB> the thing says libx264, though? the mediainfo you posted :P [00:30:35 CET] <JEEB> so didn't really look like QSV encoding [00:30:51 CET] <Lunchbox> huh [00:30:55 CET] <Lunchbox> well thats weird [00:31:03 CET] <Lunchbox> definitely has to be though [00:31:11 CET] <Lunchbox> i only use like 2% cpu [00:31:45 CET] <Lunchbox> my computer is nothing fancy either [00:33:03 CET] <JEEB> anyways, since you remember how the colors looked of what you captured [00:33:08 CET] <JEEB> go grab mpv from lachs0r's place [00:33:19 CET] <JEEB> and go ask #mpv how to switch between BT.601 and BT.709 [00:33:28 CET] <JEEB> then check which it is [00:33:37 CET] <JEEB> and define that in the colorspace filter [00:35:39 CET] <Lunchbox> its called quicksync h.264 in obs [00:35:53 CET] <Lunchbox> ask how to switch from 601 and 709 in mpv? [00:36:05 CET] <Lunchbox> like what it uses when playing a video [00:36:21 CET] <Lunchbox> or ask how to make it tell me what my video actually is [00:36:23 CET] <Lunchbox> i'm confused [00:37:37 CET] <JEEB> ask how to switch between bt.601 and bt.709 to check which it is :P [00:37:58 CET] <JEEB> the player can't know it any more than me or you because the file's not tagged [00:38:40 CET] <Lunchbox> wont it still play the video regardless [00:38:48 CET] <Lunchbox> i dont get what you mean [00:39:04 CET] <Lunchbox> i thought all of that was determined by the encoding of the video itself [00:39:27 CET] <JEEB> what gets encoded is YCbCr raw images [00:39:41 CET] <JEEB> now, the problem is that there's multiple ways of converting that YCbCr to RGB (just like the other way) [00:39:49 CET] <JEEB> it doesn't affect the decode [00:40:00 CET] <JEEB> but it does as sure hell affect how you convert that video into RGB to show [00:40:15 CET] <JEEB> of course, with BT.601 and BT.709 the difference is very small [00:40:49 CET] <Lunchbox> looks pretty busy in there [00:40:51 CET] <JEEB> http://avisynth.nl/index.php/Colorimetry#How_can_I_see_if_the_correct_stand… [00:40:56 CET] <Lunchbox> idk if i'll get a response soon but no worries [00:41:55 CET] <Lunchbox> so because my video doesnt specify what color matrix it uses or whatever [00:42:00 CET] <Lunchbox> the players just pick one [00:42:01 CET] <Lunchbox> lol [00:42:09 CET] <Lunchbox> i get it now [00:42:19 CET] <Lunchbox> so you want me to play my video in mpv and see what it says its using [00:43:08 CET] <JEEB> no [00:43:11 CET] <therage3> ._. [00:43:15 CET] <JEEB> I want you to stare at the video YOURSELF [00:43:19 CET] <JEEB> since the player cannot know [00:43:26 CET] <JEEB> while YOU know what the video should look like in RGB [01:02:11 CET] <Lunchbox> brb [08:39:47 CET] <daksh_> I want to use ffmpeg in Python2 to extract audio from a video. How do I go about it? Is there some reliable python library for ffmpeg or should I run a terminal command using python? [10:11:19 CET] <atomnuker> Darxus: there's pyav which exposes it [10:11:34 CET] <atomnuker> https://github.com/mikeboers/PyAV [12:52:19 CET] <Fyr> guys, does anyone know here why John van Sickle does not include libfdk_aac into his builds? [12:52:40 CET] <JEEB> because fdk-aac's license only lets you put it together with LGPL stuff [12:52:41 CET] <JEEB> not GPL [12:52:46 CET] <JEEB> so you can't do libx264+fdk-aac [12:52:50 CET] <JEEB> (for example) [12:52:51 CET] <Fyr> standard openSUSE's FFMPEG is built with it. [12:53:12 CET] <Fyr> guys in openSUSE know license stuff. [12:53:24 CET] <Fyr> possibly, they think that it's LGPL compatible. [12:53:26 CET] <JEEB> I'm pretty sure openSUSE builds a limited thing and most likely without GPL [12:53:31 CET] <JEEB> it is LGPL compatible [12:53:36 CET] <JEEB> as I noted [12:53:38 CET] <bencoh> then they either interpreted it differently or overlooked that issue [12:53:39 CET] <JEEB> it has an issue with GPL [12:53:53 CET] <JEEB> the FFmpeg configure lets you configure fdk-aac with LGPL but not GPL [12:54:00 CET] <bencoh> (or build without x264 and other gpl parts) [12:54:01 CET] <JEEB> most builds that people distribute are GPL because of x264 or so [12:54:10 CET] <JEEB> bencoh: opensuse disables most things I think [12:54:14 CET] <JEEB> at least the official builds [12:54:26 CET] <JEEB> just like fedora just doesn't distribute FFmpeg or VLC [12:54:40 CET] <bencoh> JEEB: tbh prefer x264 over libfdk_aac is a bit strange to me [12:54:41 CET] <bencoh> :) [12:54:46 CET] <bencoh> preferring* [12:54:50 CET] <JEEB> lol [12:54:58 CET] <bencoh> err, the other way around :D [12:55:16 CET] <JEEB> well, AAC recently became OK to distro it seems. since even fedora now packages fdk-aac [12:55:42 CET] <JEEB> or I was mistaken, maybe in the next one? aanyways [12:55:42 CET] <bencoh> together with x264? [12:55:43 CET] <Fyr> because some patents have expired? [12:55:48 CET] <JEEB> bencoh: of coure not [12:55:52 CET] <bencoh> ah, okay [12:55:55 CET] <JEEB> the license is incompatible with GPL [12:55:57 CET] <bencoh> then still strange :) [12:55:58 CET] <JEEB> LGPL is OK [13:00:38 CET] <Fyr> I downloaded some builds from the Internet on sites where people don't care about license issues. =) [13:00:45 CET] <Fyr> God bless them [13:05:37 CET] <BtbN> just use Gentoo and you don't need to care about license bullshit [13:09:12 CET] <JEEB> Fyr: I kind of wish people would care so that the fdk-aac license bullshit would get solved, or the internal AAC encoder improved further :P [13:09:37 CET] <Fyr> I'll raise my glass to it. [13:10:53 CET] <Fyr> I wish the internal AAC to be improved. [13:16:37 CET] <BtbN> How would you solve that license issue? You'd need to change the GPL for that, and that's not gonna happen. [13:16:56 CET] <JEEB> no, I mean it's fdk-aac having a custom license [13:17:18 CET] <JEEB> of course it's also highly unlikely they will change it because it works for GOOG for android [13:17:50 CET] <BtbN> The FDK license isn't even bad imo. It just happens to be incompatible with the GPL because of some of the more weird requirements of it. [13:18:14 CET] <JEEB> I don't see "don't add additional requirements" as weird tbh [13:18:39 CET] <JEEB> which is why the latter part is what would actually fix it (together with people switching to the internal encoder as in my last tests at ~96kbps the internal encoder was not audibly worse for me) [13:42:06 CET] <Tomaz^> Maybe someone here can help, avformat_open_input returns -5, and I can't for my life figure out what that means, tried av_strerror with both 5 and -5, but they just say "error -5/5 occured" or something along those lines [13:48:46 CET] <JEEB> av_err2str [13:48:47 CET] <JEEB> try that one [13:48:55 CET] <JEEB> and it hsould be the negative one [13:49:03 CET] <JEEB> also enable more verbose logging then [14:20:18 CET] <Timmey> Good afternoon, quick question: I'm trying to write progress to stdout. For mac '-progress "/dev/stdout"' works but on debian it doesn't. Anyone got an idea? [14:45:05 CET] <DHE> debian likely has an old version. that happens a lot unfortunately [14:47:34 CET] <kr16> hi , attempting to play HEVC 10bit files using Ubuntu 16.04 and Nvidia GT1030, compiled ffmeg with cuda per Nvidia instructions but no luck [14:47:52 CET] <kr16> i execute ffplay "file name" [14:49:03 CET] <kr16> Picture is stuttering and all 4 cores are at 100% [14:49:30 CET] <kr16> Is this a right place to ask for stuff like that or should I try mailing list? [14:50:06 CET] <Timmey> @DHE I did compile the sources myself, so shouldn't be outdated :[ [14:52:59 CET] <iive> kr16: what version of ffmpeg. are you sure you had yasm/nasm present. hw acceleration is not used by default, have you specified you want it. mpv might be better for video playback. [14:53:26 CET] <iive> i mean, hwaccel is not used by default for playback. [14:53:50 CET] <kr16> ffmpeg was pulled from git at Dec 7th [14:54:24 CET] <kr16> yasm I had to add as requested by ./configure [14:54:59 CET] <kr16> I am not sure how to specify hw with ffplay [14:55:44 CET] <kr16> thats what I was afraid of, missing command line options for ffplay [14:56:08 CET] <kr16> can you give an example for hevc? [14:57:29 CET] <kr16> did not try mpv , I am not aware of it , start reading now :) [15:58:07 CET] <artushin> hey guys, anyone happen to have any experience with RTP/RTCP streams to ffmpeg? [15:58:24 CET] <teratorn> artushin: just ask your question :) [15:59:16 CET] <artushin> thanks! I've written it up on https://stackoverflow.com/questions/47731788/fixing-a-v-sync-issues-with-rt… but basically I want to know how to change timestamps on a stream to match the timestamps of a stream that starts a bit later [16:27:27 CET] <kr16> how would I invoke ffplay command to use hevc or hevc_cuvid decoder? [16:29:25 CET] <kepstin> kr16: just use mpv instead, it has decent docs on setting up hardware decoding. [16:29:42 CET] <kepstin> kr16: but that said, I suspect it should be similar to using hardware decoding in the ffmpeg tool. [16:33:31 CET] <kr16> do I just install mpv from PPA? my ffpmeg is compiled locally without make install [16:36:10 CET] <sfan5> if you want mpv to link to your local ffmpeg installation you will need to compile it yourself [17:44:24 CET] <kr16> ok, think I got it , made .deb package from my ffmpeg with cuda and install it, installed mpv (and it did not ask for ffmpeg anymore) [17:44:50 CET] <kr16> so now I tell mpv to play file, I will need to specify decoder correct ? [17:59:04 CET] <kr16> so I have h264_cuvid decoder and hevc_cuvid decoder , I am guessing this is what I want to use to get hardware decoding from gt1030 [17:59:38 CET] <kr16> exectuing mpv just use h264 and hvec which kills CPU [18:02:38 CET] <DHE> for video playback vdpau is another possibility. you might also need the binary nvidia drivers though [18:08:54 CET] <kr16> i do have those, tried --vo=vdpau which gives same results, CPU 100% [18:09:14 CET] <kr16> not sure how to use this cuda stuff [18:10:10 CET] <kr16> ffmpeg shows hevc and hevc_cuvid , cuvid I guess gives hardware support for hevc 10bit [18:10:51 CET] <iive> are you sure you have hw acceleration working at all? [18:11:21 CET] <iive> e.g. there is `vdpauinfo` program, see what it tells [18:12:33 CET] <dystopia_> i have a video an 29.970 and every 5th frame is a duplicate [18:13:04 CET] <dystopia_> do i just add "-decimate cycle 5" to my line to handle it? [18:16:28 CET] <DHE> it's a filter, not a commandline option [18:16:42 CET] <DHE> also note that decimate causes variable framerate [18:17:19 CET] <dystopia_> oh :( [18:17:55 CET] <dystopia_> so whats the best way to take it to 23.976 ? [18:21:18 CET] <kr16> so yes , vdpauinfo shows support for hevc main line but not hevc 10 bit [18:21:31 CET] <kr16> but thats expected [18:22:07 CET] <kr16> whole idea of 10bit support was compiling ffmpeg with nvidia cuda [18:22:27 CET] <kr16> that should give 10bit support (hardware) [18:25:39 CET] <kr16> this is what I am attempting BTW https://developer.nvidia.com/ffmpeg [18:33:30 CET] <TheRock2> i heard handbrake is better than ffmpeg, is that true ? [18:40:04 CET] <durandal_1707> TheRock2: yes, go away [18:52:07 CET] <microchip_> TheRock2: take your meds so you won't hear voices [18:58:21 CET] <illegal> So I was trying to convert audio to opus on ffmpeg but problem was that the audio was 5.1channels, which gave me these error, but according to the latest comment none of the workarounds (even the ones I tried) work, is there one which actually works? https://trac.ffmpeg.org/ticket/5718 [19:00:03 CET] <TheRock2> ok, im sorry that i heard this [19:07:11 CET] <TheRock2> I did not want to raise aggressions here [19:10:29 CET] <kr16> @TheRock2 Imagine going to Audi forum and asking that you heard BMW is better, what is it that you expect? :) [19:11:36 CET] <JEEB> TheRock2: handbrake uses FFmpeg's libraries [19:11:37 CET] <JEEB> QED [19:13:22 CET] <TheRock2> I'm sorry to hear that [19:13:44 CET] <JEEB> why? :) [19:14:08 CET] <JEEB> tl;dr handbrake is probably one of the least retarded graphical interfaces for the FFmpeg libraries [19:17:43 CET] <Fyr> guys, does anybody know when the developers are going to implement AV1? [19:18:08 CET] <JEEB> maybe when it's finished? [19:18:17 CET] <JEEB> it's still in soft freeze and IP review [19:22:10 CET] <TheRock2> one question [19:22:17 CET] <TheRock2> codecs like h264, etc. [19:22:26 CET] <TheRock2> are they reconstructed by reverse engineering? [19:22:46 CET] <JEEB> things that have actual specifications and official reference test suites don't really need that [19:22:53 CET] <JEEB> formats that are "proprietary" need that [19:23:06 CET] <TheRock2> becuse i read handbrake reverse engineered h264 [19:23:14 CET] <JEEB> H.264 http://www.itu.int/rec/T-REC-H.264-201704-I/en [19:23:16 CET] <TheRock2> and they were the first that had it [19:23:17 CET] <JEEB> full spec to decode it [19:23:36 CET] <DHE> there's a (very long) spec document for h264. "annex b" mode is so named because the document's annex B describes it [19:23:37 CET] <JEEB> then you have left some very important parts out of those sentences you've read [19:23:41 CET] <DHE> you can download it for free [19:23:50 CET] <JEEB> DHE: linked already [19:24:15 CET] <DHE> I've read (part of) it [19:24:18 CET] <DHE> :) [19:24:27 CET] <JEEB> you usually just read what you care about [19:24:33 CET] <JEEB> what you're implementing etc [19:25:25 CET] <TheRock2> No [19:25:32 CET] <TheRock2> I read correctly [19:25:33 CET] <TheRock2> https://en.wikipedia.org/wiki/HandBrake#MediaFork [19:25:42 CET] <TheRock2> In September 2006, Rodney Hester and Chris Long had been independently working to extract the H.264 video compression format from Apple's iPod firmware (1.2) through reverse engineering before meeting on the HandBrake forum. Since their work was complementary, they began working together to develop an unstable, but still compilable, release of HandBrake supporting the H.264 format. [19:25:55 CET] <TheRock2> So why they do that, if there is a spec? [19:26:12 CET] <JEEB> what the fuck :D [19:26:19 CET] <JEEB> yea, because that thing's been public [19:26:26 CET] <JEEB> I think that omits something [19:27:07 CET] <BtbN> that sounds like either bullshit, or they were working on its hw decoder/encoder or something [19:27:08 CET] <JEEB> also by 2006 we already had the H.264 decoder in FFmpeg as well as an encoder in x264 [19:27:16 CET] <iive> maybe they RE ipod, in order to figure out the constraints of the device. [19:27:16 CET] <DHE> iirc only a decoder was really specified. encoding has been a ground-up job. maybe they meant an encoder? [19:27:17 CET] <BtbN> also, h264 on an iPod?! [19:27:24 CET] <DHE> maybe baseline? [19:27:30 CET] <DHE> does the iPod have a camera? [19:27:34 CET] <BtbN> no [19:27:37 CET] <JEEB> yea, probably baseline H.264 at that point [19:27:45 CET] <JEEB> and yes, figuring out the limitations would make sense [19:27:53 CET] <JEEB> or if they for some reason started their own encoder project [19:28:02 CET] <JEEB> which at the point of 2006 already sounds like question marks [19:28:18 CET] <JEEB> because x264 was already out there (my teenage dumb self used it) [19:29:12 CET] <ritsuka> one model of the ipod nano had a camera [19:29:14 CET] <TheRock2> maybe they didn't know about the spec [19:29:21 CET] <BtbN> highly unlikely [19:29:32 CET] <JEEB> https://web.archive.org/web/20160611174745/https://trac.handbrake.fr/wiki/H… [19:29:35 CET] <JEEB> ok [19:29:39 CET] <JEEB> this sounds more like they wanted to know how to package it [19:29:43 CET] <JEEB> for the iPod [19:30:02 CET] <JEEB> (and/or the limitations) [19:30:20 CET] <JEEB> and yes, > Apple's new uuid atom [19:30:22 CET] <ritsuka> yes, it was just an additional atom in the mp4 container [19:30:23 CET] <JEEB> so that's MOV/MP4 [19:30:31 CET] <ritsuka> to make it work on the ipod [19:30:34 CET] <JEEB> yup [20:02:49 CET] <kr16> so ffplay -vcodec hwec_cuvid works and mpv --hwdec-codecs=hevc_cuvid also work, beautiful , now I need 4k TV :) [20:03:21 CET] <BtbN> that ffplay line makes no sense. [20:05:31 CET] <kr16> hewc_cuvid [20:05:37 CET] <kr16> typo :) [20:05:40 CET] <sfan5> the mpv line doesn't either: hwdec-codecs denotes the codecs that will be hwdecoded, not which hwdecoders to use (it has a sane default value anyway) [20:06:00 CET] <BtbN> that does not make any more sense [20:06:14 CET] <BtbN> There is nothing in ffmpeg called that way [20:06:17 CET] <BtbN> even ignoring the typos [20:06:27 CET] <sfan5> for mpv you want --hwdec=cuda instead [20:06:29 CET] <kr16> you need cuda compiled [20:07:03 CET] <BtbN> it's either -hwaccel nvdec or -c:v hevc_cuvid for the "legacy" decoder. [20:09:04 CET] <kr16> Failed to set value 'nvdec' for option 'hwaccel': Option not found [20:09:26 CET] <BtbN> your ffmpeg is too old. [20:09:58 CET] <BtbN> Or you're using the option wrong. On the output or so [20:10:07 CET] <kr16> pulled from git last Thursday [20:13:18 CET] <kr16> anyway it's working ffplay -vcodec hevc_cuvid [20:13:31 CET] <BtbN> -c:v [20:13:51 CET] <BtbN> And the decoders called cuvid are legacy and might, at some point in the future, be removed [20:14:50 CET] <kr16> what would be used instead [20:15:32 CET] <BtbN> nvdec. [20:16:02 CET] <kr16> I see, should it be an option to pick already? [20:16:23 CET] <BtbN> It's a native hwaccel [20:16:32 CET] <BtbN> turn it on like I just told you. [20:18:22 CET] <buttocks> hello im a pleb and i need help D: [20:19:23 CET] <buttocks> ive been trying to dl a file from fite.tv i purchased and i am trying to figure out how i can supply uid and password in the command line. i am currently getting a 403 message [20:20:25 CET] <kr16> I dont see -hwaccel option for ffplay [20:22:27 CET] <BtbN> no idea about ffplay [20:22:30 CET] <BtbN> it might plain not support it [20:22:37 CET] <BtbN> it's not meant as a real player [20:38:11 CET] <kr16> mpv --hwdec=cuda gives me an error, do I need manually compile it? [20:38:43 CET] <JEEB> hwdec=help should give you teh alternatives available in your build [20:42:27 CET] <kr16> yeah it does not list cuda as an option [21:23:33 CET] <kr16> OK , compiling mpv did the trick, very cool, thx guys [22:36:29 CET] <alexpigment> has anyone had any experience encoding with h264_videotoolbox on macOS? [22:37:04 CET] <alexpigment> it says "no device available for encoder", but i'm not sure what the requirements are [22:37:42 CET] <alexpigment> i've got a macbook (non-pro) that can do airplay mirroring, so I'm assuming that it has a valid videotoolbox encoder [22:37:46 CET] <alexpigment> (intel quick sync) [23:46:42 CET] <alexpigment> re: earlier, it turns out videotoolbox has the same dumb meaningless warning as quick sync: https://trac.ffmpeg.org/ticket/6492 [23:47:05 CET] <alexpigment> also, as far as I can tell, -b:v and -q:v do nothing [23:47:22 CET] <alexpigment> -maxrate is the only bitrate control that seems to work from what i can tell [23:50:25 CET] <alexpigment> nm; i had a -b:v 0 later in my command ;) [23:51:00 CET] <alexpigment> still no -q:v though :( [00:00:00 CET] --- Tue Dec 12 2017

1 0