Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2017

1 participants
62 discussions

ffmpeg-devel.log.20170325
by burek 26 Mar '17

26 Mar '17

[00:00:09 CET] <jpabq_> RiCON: that might work... [00:01:03 CET] <jpabq_> JEEB: does patchwork have a search feature? [00:01:29 CET] <JEEB> jpabq_: click the "show patches with" text [00:01:58 CET] <jpabq_> Thanks! [04:13:24 CET] <jamrial> ubitux: "vex: the `impossible' happened: VEX temporary storage exhausted." [04:13:39 CET] <jamrial> from your valgrind fate slot [04:15:11 CET] <jamrial> i can reproduce it here as well [05:14:58 CET] <cone-209> ffmpeg 03James Almer 07master:36eae4551043: fate/checkasm: use LOCAL_ALINGED_32 on hevc_add_res tests [05:14:58 CET] <cone-209> ffmpeg 03James Almer 07master:09ce5519f3b4: fate/checkasm: fix use of uninitialized memory on hevc_add_res tests [08:35:36 CET] <ubitux> /usr/lib/gcc/i686-pc-msdosdjgpp/6.1.0/../../../../i686-pc-msdosdjgpp/bin/as: libavcodec/vp9.o: /45: reloc overflow: 0x20b49 > 0xffff [08:35:38 CET] <ubitux> :((( [08:36:04 CET] <ubitux> it also refuses to compile a bunch of tables because align of 32 is too big :( [10:44:45 CET] <j-b> JEEB: no there is no bounty for amarecco. [10:44:53 CET] <j-b> JEEB: I have no idea what it is. [10:52:34 CET] <wm4> ubitux: you're obviously trying to compile to 16 bit mode or something? [11:04:17 CET] <JEEB> j-b: https://wiki.videolan.org/Bounties/#Libavcodec_features I just lulz'd at seeing "- AmaRecTV AMV2, AMV3, AMV4" there [11:09:42 CET] <wm4> "500 ¬ To fix the issue that you cannot have MT hw decoding. " [11:09:47 CET] <wm4> j-b: will you pay elenril? [11:10:13 CET] <wm4> you're also free to pay me since I've ported this to ffmpeg against michaelni's resistance [11:14:36 CET] <nevcairiel> This should've really been fixed in vlc, but what can you do, someone badgered elenril into doing this =p [11:15:05 CET] <wm4> it has the advantage that it works for ffmpeg.c [11:15:11 CET] <wm4> which is why I wanted it [11:20:33 CET] <wm4> as usual j-b never replies when it comes to bountied functionality that has been implemented by volunteers unaware of the bounty [11:21:05 CET] <j-b> wm4: yes, we already discussed that with elenril [11:21:13 CET] <wm4> hehe ok [11:21:36 CET] <j-b> wm4: and as you might know, we usually pay elenril's travel&lodging to FOSDEM, at his requests. [11:22:05 CET] <wm4> free travel for code [11:22:30 CET] <j-b> wm4: so far, we've paid a few thousands ¬ on bounties [11:22:37 CET] <j-b> wm4: we're not a company [11:22:46 CET] <j-b> wm4: we don't have VC money [11:22:54 CET] <j-b> I wish some other would do the same [11:23:03 CET] <j-b> (and yes, I know, most of the bounties are too low) [11:23:12 CET] <wm4> which companies [11:24:02 CET] <j-b> do you really want names? [11:24:37 CET] <j-b> JEEB: IIRC, those were suggested. [11:24:46 CET] <j-b> JEEB: but if you have other suggestions, please share. [11:24:58 CET] <wm4> j-b: I think it would be interesting [11:25:19 CET] <j-b> wm4: ok, what about zencoder? [11:25:53 CET] <wm4> never heard of them [11:26:07 CET] <j-b> who explained to us (&other libavcodec devs) that one of their major codec issue was G2Mx and could not fork a couple of thousands of $ for it [11:26:12 CET] <wm4> I mean there are going to be hundreds of companies which use ffmpeg and which won't even report simple bugs [11:26:21 CET] <wm4> aha [11:26:30 CET] <j-b> In the end, VideoLAN paid IIRC 2000¬ for that. [11:26:47 CET] <wm4> why would videolan pay for something a company requested? [11:26:53 CET] <j-b> and zencoder was ffmpeg+x264 rewrapped as SaaS [11:27:11 CET] <wm4> time for AGPL? [11:27:41 CET] <j-b> and they got bought by brightcove $30m [11:27:48 CET] <j-b> and still could not make a fucking donation [11:27:50 CET] <j-b> assholes. [11:28:07 CET] <j-b> wm4: because VLC users were asking for this stupid codec. [11:28:15 CET] <j-b> wm4: and because it helps everyone. [11:28:19 CET] <thardin> agpl with an x264-style separate license is an approach I've considered proposing [11:28:43 CET] <wm4> j-b: that's unfortunate [11:28:57 CET] <wm4> in general ffmpeg is probably saving companies billions of dollars [11:28:58 CET] <j-b> wm4: also, we've found money and gave money for other stuff, like some ARM asm on libavcodec and x264 [11:29:24 CET] <j-b> We're not perfect, and VLC is clearly not, but I found it's normal that we chip in too. [11:29:36 CET] <wm4> did you pay the guy who wrote the DTS HD decoder? [11:29:50 CET] <j-b> I don't remember what happened on that part, tbh [11:29:57 CET] <j-b> but I can check in the archives, if you want. [11:30:08 CET] <j-b> I think now our biggest bounty is MVC though [11:30:10 CET] <wm4> I'd be very interested in that [11:30:24 CET] <wm4> (what happened to the DTS guy in this respect) [11:30:29 CET] <wm4> and people still want MVC? lol [11:30:29 CET] <j-b> 11:20 <+wm4> as usual j-b never replies when it comes to bountied functionality that has been implemented by volunteers unaware of the bounty [11:30:43 CET] <j-b> however, I found your quote quite disrespectful [11:30:53 CET] <wm4> just based on past communication [11:31:08 CET] <j-b> it's untrue [11:31:09 CET] <wm4> it might have been an overly pessimistic assumption [11:31:13 CET] <j-b> I usually always reply when I see it. [11:31:31 CET] <j-b> but, yes, I'm not going to chase all developers when they implement something on this list [11:31:38 CET] <j-b> when I don't even remember all of them [11:31:54 CET] <j-b> However, lately, I've been pushing durandal_1707 quite a bit to send us an invoice [11:32:03 CET] <j-b> on the last 2 codecs... [11:32:12 CET] <j-b> let me look at it. [11:32:13 CET] <wm4> durandal_1707: you don't like money? [11:32:32 CET] <j-b> Was it Pixlet ? [11:32:45 CET] <j-b> and I'm waiting for the second one, aka FMSCC [11:33:00 CET] <j-b> wm4: some people want MVC, yes. Don't ask... [11:33:03 CET] <wm4> anyway, I apologize for my trolling, but see, I got you to actually reply [11:33:25 CET] <j-b> well, you know, this chan is on a non-highlight one for me [11:33:25 CET] <wm4> j-b: I hear kodi got MVC somehow [11:33:34 CET] <j-b> ah? ok [11:33:37 CET] <JEEB> HW decoding? [11:33:42 CET] <nevcairiel> they "borrowed" by code to use the intel decoding library [11:33:48 CET] <j-b> I want SW decoding [11:33:49 CET] <nevcairiel> s/by/my/ [11:33:50 CET] <wm4> per query I rarely get real replies either (though I didn't ask about this topic there) [11:34:05 CET] <wm4> nevcairiel: figured it'd be something like this [11:34:14 CET] <wm4> j-b: who still cares about sw decoding? [11:34:17 CET] <j-b> wm4: so far, I'm on 60+ channels and have 600+ queries [11:34:28 CET] <j-b> wm4: me. [11:34:44 CET] <nevcairiel> the intel library has sw decoding, you just need to ship a blob =p [11:34:48 CET] <j-b> brr [11:34:53 CET] <wm4> didn't koda make some progress on this (this time "a" not "i") [11:35:04 CET] <j-b> I think he did. [11:35:17 CET] <nevcairiel> the decoding itself is probably not too hard, the real thing is frame and reference management [11:35:31 CET] <wm4> yeah there were some API questions [11:35:32 CET] <j-b> wm4: anyway, as once said, if you have good ideas about bounties on libavcodec/libav*, don't hesitate to suggest it. [11:36:00 CET] <j-b> Sure, it's not perfect [11:36:04 CET] <j-b> Sure, it's not enough [11:36:09 CET] <j-b> but, it's something. [11:37:19 CET] <nevcairiel> regarding MVC, you can basically just wait that out if you want to, TVs basically stopped supporting 3D, so its just a matter of time until its dead entirely :p [11:37:31 CET] <j-b> nevcairiel: indeed :) [11:37:36 CET] <JEEB> :D [11:37:40 CET] <wm4> I wonder why TVs did that [11:37:42 CET] <JEEB> yea, I noticed the trend [11:37:46 CET] <wm4> maybe their developers went on strike [11:37:50 CET] <j-b> IIRC, there was a bounty on DSD integration in vlc [11:37:55 CET] <j-b> I don't see where it is now.. [11:38:11 CET] <wm4> j-b: well you were one of those who rejected a DSD samplefmt in libavutil trollol [11:38:28 CET] <j-b> nevcairiel: yes, people just use SxS and TxB [11:38:42 CET] <nevcairiel> j-b: that doesnt help if the tv itself is incapable of s howing 3d [11:38:53 CET] <j-b> nevcairiel: sure, but then you can filter one side or the other [11:39:05 CET] <j-b> wm4: sure, I believe libavutil has too many pixfmt and samplefmt [11:39:09 CET] <j-b> wm4: does not mean I'm right. [11:39:21 CET] <nevcairiel> samplefmts are probably fine [11:39:24 CET] <wm4> I think koda's pixformaton was actually the right thing [11:39:31 CET] <nevcairiel> in fact one might argue a S24 format might be useful [11:39:34 CET] <wm4> fuck all those permutations that get added bit by bit [11:39:37 CET] <nevcairiel> but pixfmts .. thats another mess [11:39:54 CET] <wm4> but surely we could get rid of the obscure pixfmts [11:40:14 CET] <wm4> e.g. remove AV_PIX_FMT_MONOBLACK or AV_PIX_FMT_MONOWHITE [11:40:26 CET] <wm4> who the fuck uses AV_PIX_FMT_BGR4_BYTE [11:40:28 CET] <j-b> I never understood why libavutil needs both 10L and 10B for every YUV formats [11:40:29 CET] <wm4> etc. [11:40:52 CET] <j-b> and never understood why it needed all bit depth and not just use 16, afte 10 [11:40:53 CET] <wm4> because it's faster to read different-endian from raw formats [11:41:06 CET] <j-b> different-endian ? [11:41:10 CET] <j-b> Does it still exist? [11:41:27 CET] <wm4> I mean getting BE pixfmts on a LE machine because the actual data is BE on disk [11:41:53 CET] <j-b> and last time I checked, there were pixfmt used only once or twice in libavcodec [11:42:08 CET] <nevcairiel> thats definitely true [11:42:08 CET] <j-b> but once again, that's my opinion, and I might be wrong [11:42:24 CET] <j-b> also, I never understood the bayer ones [11:42:48 CET] <wm4> yeah [11:43:05 CET] <wm4> supposedly because camera hardware uses them [11:43:28 CET] <j-b> So what? [11:43:45 CET] <j-b> nevcairiel: do you know why there was never a S24 one? [11:44:05 CET] <wm4> because it's 3 bytes this inefficient to process [11:44:09 CET] <wm4> *thuas [11:44:10 CET] <nevcairiel> because its inconvenient to process [11:44:11 CET] <wm4> *thus [11:44:36 CET] <j-b> wm4: as for DSD, I never really understood this format/need for this. But once again, I might be wrong. [11:44:48 CET] <j-b> Can DSD get passthrough'd? [11:44:58 CET] <adeel_> /msg NickServ VERIFY REGISTER adeel_ ljlpvxxgmtzl [11:45:26 CET] <j-b> oops :) [11:45:46 CET] <adeel_> Yeah :D [11:45:54 CET] <nevcairiel> j-b: yes through various USB DACs, through HDMI its rather tricky and generally unsupported [11:45:56 CET] <adeel_> there was a trailing space [11:46:11 CET] <wm4> nevcairiel: does that use spdif framing? [11:46:17 CET] <nevcairiel> no [11:46:22 CET] <wm4> makes sense [11:46:39 CET] <wm4> j-b: as I understand, DSD must not be converted to PCM and back because that DESTROYS it [11:46:39 CET] <nevcairiel> it has its own framing called DoP (DSD over PCM), and some a udio APIs even have a native DSD mode without framing [11:46:41 CET] <j-b> on sdpif, only mp3/aac/dts/ac3, no? [11:46:54 CET] <wm4> (and truehd/eac3) [11:47:00 CET] <j-b> no [11:47:09 CET] <j-b> truehd and eac3 only work on hdmi [11:47:16 CET] <wm4> I'm calling both spdif [11:47:31 CET] <wm4> (did I ever say fuck HDMI?) [11:47:33 CET] <j-b> wm4: yeah, I read that too, but that does not compute (the destroys it part) [11:47:42 CET] <j-b> wm4: maybe you said :) [11:47:50 CET] <wm4> http://www.mojo-audio.com/blog/dsd-vs-pcm-myth-vs-truth/ [11:48:11 CET] <wm4> this also explains why DSD is idiotic audiophile nonsense [11:48:28 CET] <nevcairiel> PCM cannot accurately represent DSD, and DSD cannot accurately represent PCM [11:48:31 CET] <nevcairiel> so either conversion is lossy [11:55:05 CET] <j-b> ok [13:14:39 CET] <uau> michaelni: that pthread_frame failure you get seems quite weird - i tried that too and could not reproduce the problem [13:14:59 CET] <wm4> I've sent a mail about that just now [13:15:01 CET] <uau> the code in pthread_frame looks like it shouldn't return anything other than error or the whole avpacket size [13:15:19 CET] <uau> and the valgrind output seems to list all uses of the "ret" variable as "uninitialized"? [13:16:16 CET] <uau> that goto case? [13:18:27 CET] <wm4> yes [13:20:11 CET] <wm4> that's some pretty questionable code not in Libav, although it appeared to fix a real issue [13:23:29 CET] <uau> wm4: the current form of that code is the result of your merge... [13:24:47 CET] <uau> e0cd598bc4684 (merge of elenril's d4a91e65) changed it from "return err;" to "goto finish;" [13:25:44 CET] <uau> apparently missing the case where err equals 0 but should still be returned [13:26:16 CET] <wm4> I know [13:45:53 CET] <ubitux> BBB: ping [13:46:05 CET] <BBB> pong [13:46:43 CET] <ubitux> BBB: https://github.com/ubitux/FFmpeg/compare/vp9sync opinions? [13:47:14 CET] <BBB> did they re-split the files? [13:47:18 CET] <BBB> or is this still the original split? [13:47:31 CET] <BBB> I explicitly asked Anton to confirm with me before re-splitting so we can make sure its ok [13:47:41 CET] <ubitux> we never merged the split [13:48:12 CET] <ubitux> so i compare how it was split on libav/master/HEAD [13:48:18 CET] <ubitux> and redid it in our tree [13:48:32 CET] <ubitux> + a stack of random cosmetics to reduce the diff [13:49:10 CET] <ubitux> i haven't look at the asm yet [13:51:34 CET] <ubitux> it's still diverging quite a lot, notably because of the shared context / bitstream leading to many diff [13:51:55 CET] <ubitux> with additionnal missing features on libav side [13:52:06 CET] <ubitux> i spotted a few things we may want to import though [13:52:14 CET] <ubitux> such as not using avctx in the vp9_frame* funcs [13:52:42 CET] <ubitux> you may want to run some ${EDITOR}diff between the files to check by yourself [13:55:47 CET] <ubitux> BBB: what's this re-split thing about? [14:01:12 CET] <ubitux> :( [14:07:23 CET] Action: ubitux & [14:08:35 CET] <BBB> ubitux: sorry, disconnected [14:09:10 CET] <BBB> ubitux: re: split [14:09:35 CET] <BBB> ubitux: elenril told me he was aware some features in ffmpeg needed to be imported in libav (along with optimizations), and he was willing to re-import our current codebase into libav head [14:09:47 CET] <BBB> after that he was going to re-split it but asked if I was interested in merging that on our side [14:10:04 CET] <BBB> I said yes, if I can at least provide some input/review on the split to make sure Im OK with it [14:10:19 CET] <BBB> ubitux: so Im basically waiting for the patch to review so we can both have the same split [14:10:26 CET] <BBB> and then hopefully have a relatively equal codebase [14:10:37 CET] <BBB> where whatever they apply on top can be merged trivially on our side [14:11:15 CET] <BBB> ubitux: I Can review the smaller changes but re: split, I would say hold off until elenril sends me the patch [14:13:06 CET] <BBB> ubitux: b5735cbb4a75fb8ec232d623061df70aabee2e08 the tree parts are fundamentally wrong, its diegoification and diego knows nothing about codecs [14:13:56 CET] <BBB> the 32x32 zigzag scantable change is also wrong because it makes it non-32 [14:15:12 CET] <ubitux> BBB: ah... ok [14:15:17 CET] <BBB> I would claim that b5735cbb4a75fb8ec232d623061df70aabee2e08 should have been reviewed by me [14:15:21 CET] <BBB> I would reject most of it [14:15:31 CET] <BBB> its all just opinion, two spaces is nicer than one [14:15:42 CET] <BBB> that opinion should be up to the author(s), not up to some random diego [14:15:46 CET] <ubitux> i can't apply anything without the split, i'm not willing to redo that stuff, so i'll drop that stuff [14:15:59 CET] <ubitux> yeah, about the spaces shuffling, a lot are insane/stupid [14:16:10 CET] <ubitux> and i didn't even merged all of them [14:16:12 CET] <BBB> 7ee37815cd019f1ee079cce54e49107eb51d680f seems nice [14:16:50 CET] <ubitux> it's a pita to apply those without the split so you can stop the review :p [14:16:55 CET] <BBB> okay [14:17:06 CET] <BBB> if youre interested in the split per se, lets discuss that with anton [14:17:16 CET] <BBB> I really continue to think a proper split should be reviewed by me and you [14:17:19 CET] <ubitux> i agree with the loss of information wrt the "tree indent", not sure what you're refering about the zigzag [14:17:42 CET] <BBB> ff_vp9_default_scan_32x32 [14:17:54 CET] <BBB> its a table of 32 rows and columns, because its a 32x32 scantable [14:18:05 CET] <BBB> he changes it into a 64 rows of 16 columns [14:18:10 CET] <BBB> which seems very weird to me [14:18:17 CET] <ubitux> ah, that, yeah, i assumed it was like this on purpose [14:19:27 CET] <ubitux> but i thought it wasn't too much a problem (contrary to the loss of the "tree view indent" [14:19:27 CET] <BBB> and patches like 77c996b62349ca928cc525be694fc2239db666d1 just make me wonder why [14:19:29 CET] <ubitux> ) [14:19:41 CET] <ubitux> BBB: reduce diff. [14:19:47 CET] <BBB> no, I get that [14:19:49 CET] <ubitux> we use ret everywhere [14:19:52 CET] <ubitux> anyway [14:19:57 CET] <ubitux> so consistency as well if you want [14:19:59 CET] <BBB> but lets talk to anton about the split [14:20:27 CET] <ubitux> the split commit doesn't contain any cosmetics IIRC [14:20:34 CET] <ubitux> i really just moved the blocks [14:21:05 CET] <BBB> yeah, we just need to make sure this is the final version [14:21:12 CET] <BBB> and theyre not going to re-split it again after merging it [14:21:16 CET] <BBB> which would be strange [14:21:21 CET] <BBB> and wasteful of our time :) [14:21:54 CET] <ubitux> elenril may have a grudge about me, so i'll let you handle the pourparler [14:22:35 CET] <ubitux> if he started or did a commit to be applied on ffmpeg tree to do the split we should probably take his (and i'll rebase that stuff on it) [14:23:09 CET] <ubitux> otherwise i'll rebase when necessary [14:23:23 CET] <ubitux> but if i could avoid reworking that branch too much that would be appreciated :p [14:23:36 CET] <ubitux> it took me a few hours, and it's really annoying stuff to do [14:30:30 CET] <adeel_> I have submitted my draft fro GSoC. Please review and suggest modifcaions / improvements: https://docs.google.com/document/d/1QMjzzXO6lF7Jk3KSiKWjaPQWyOYs6VZIdCKCL_U… [15:24:35 CET] <BBB> ubitux: Ill try to help where I can [15:24:53 CET] <BBB> ubitux: I obviously want whatever is best for the overall vp9 decoder, and I think them being in sync is always better [16:14:18 CET] <kierank> 10:40 AM <"j-b> and never understood why it needed all bit depth and not just use 16, afte 10 [16:14:31 CET] <kierank> because you can do arithmetic and not overflow in 16-bit [16:48:43 CET] <ubitux> BBB: btw, it looks like valgrind doesn't like ff_vp9_idct_iadst_16x16_add_avx2 at all :p [16:48:50 CET] <BBB> hm... [16:48:56 CET] <BBB> overreads? [16:48:59 CET] <BBB> link? [16:49:08 CET] <ubitux> might be a problem with valgrind [16:49:11 CET] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170325102224&slot=x86_64-archlinux… [16:49:29 CET] <ubitux> "VEX temporary storage exhausted. [16:49:35 CET] <BBB> huh? [16:49:36 CET] <BBB> :D [16:49:36 CET] <ubitux> Increase N_{TEMPORARY,PERMANENT}_BYTES and recompile." [16:49:38 CET] <ubitux> :D [16:49:50 CET] <BBB> ok thats probably a valgrind issue yes [16:51:10 CET] <ubitux> your asm is too complex for valgrind :( [16:52:06 CET] <durandal_1707> anyone understands what needs to be done to add 444 support to our dnxhdenc? [16:52:09 CET] <BBB> so uhm [16:52:14 CET] <BBB> is that a compliment or a criticism? [16:52:26 CET] <BBB> Im not quite sure what to do, basically [16:52:42 CET] <BBB> I fully agree that the code is very, very complicated, but I dont think it does anything utterly strange [16:52:56 CET] <BBB> shall I email the valgrind list? [16:53:04 CET] <ubitux> it's not criticism :) [16:53:07 CET] <BBB> I have an additional issue that valgrind doesnt work on macosx 10.12 so I cant test it :( [16:53:08 CET] <ubitux> it's always the same function though [16:53:40 CET] <durandal_1707> i keep getting put bits overflow [16:53:57 CET] <BBB> durandal_1707: so if you increase the buffer, does it work? :-p [16:54:48 CET] <BBB> ubitux: shall I just file a bug and see what happens? [16:54:55 CET] <ubitux> would be great [16:55:01 CET] <ubitux> :) [16:55:12 CET] <BBB> can you reproduce locally? [16:55:23 CET] <BBB> (just to make sure its not some weird config on the testing machine) [16:55:40 CET] <durandal_1707> BBB: buffer size is calculated from contents iirc [16:56:24 CET] <ubitux> BBB: yes [16:57:12 CET] <ubitux> BBB: valgrind checkasm http://sprunge.us/FBKM [16:57:53 CET] <ubitux> BBB: want me to try to recompile valgrind with that macro increased? [17:01:32 CET] <BBB> no [17:01:41 CET] <BBB> lets ask them what it means [17:02:13 CET] <BBB> thats a different function btw [17:02:14 CET] <BBB> very strnage [17:02:35 CET] <ubitux> http://sprunge.us/MgaI [17:02:45 CET] <ubitux> here is what you get with valgrind svn [17:03:19 CET] <ubitux> you may want to provide this backtrace [17:04:05 CET] <BBB> thats very helpful, yes [17:04:05 CET] <BBB> thanks [17:04:20 CET] <ubitux> the ffmpeg stack is completely fucked up [17:04:47 CET] <ubitux> at least enough to drive valgrind nuts [17:06:17 CET] <ubitux> by 0xDEADBEEFDEADBEEE [17:06:19 CET] <ubitux> hehehe [17:06:54 CET] <nevcairiel> whats that, 64-bit beef? [17:07:09 CET] <ubitux> ah that might be the checkasm clobbering thing [17:07:29 CET] <BBB> https://bugs.kde.org/show_bug.cgi?id=378068 [17:07:42 CET] <BBB> I noticed that also [17:07:51 CET] <BBB> its funny that its not deadbeefdeafbeef, but eee at the end [17:08:05 CET] <BBB> but the fact that we get a backtrace out of valgrind suggests an actual bug in valgrind [17:08:22 CET] <BBB> I dont know what it means exactly but I think asking themf or advice is probably a good idea [17:09:21 CET] <kierank> BBB: I can test on valgrind git if you want [17:09:35 CET] <kierank> i've had problems with simd and valgrind before and upgrading to git usually fixes it [17:09:42 CET] <BBB> ok that would be nice, thanks [17:09:46 CET] <ubitux> valgrind svn doesn't fix it [17:10:07 CET] <ubitux> r16286 [17:10:10 CET] <kierank> what command do I have to run? [17:10:27 CET] <ubitux> ~/src/valgrind/vg-in-place ./tests/checkasm/checkasm [17:10:39 CET] <ubitux> you need an avx2 machine [17:11:22 CET] <BBB> is valgrind in svn or in git? [17:11:27 CET] <BBB> how strange [17:11:45 CET] <kierank> svn [17:12:50 CET] <ubitux> BBB: we should probably report that svq1 thing too [17:12:54 CET] <ubitux> iirc it's a false positive :3 [17:13:37 CET] <BBB> if its a false positive, then yes [17:13:44 CET] <BBB> I need to get a working valgrind on my machine [17:13:56 CET] <BBB> its so irritating that every time I get a osx update, valgrind stops working :-/ [17:14:01 CET] <BBB> fortunately asan works fine [17:14:13 CET] <BBB> brb gotta bring kids to swimming [18:31:15 CET] <philipl> BtbN: So, I'm still looking at the nvenc bframe thing. [18:31:41 CET] <BtbN> Yeah, looked at it myself, but couldn't find anything obvious wrong [18:31:52 CET] <BtbN> except for it not working [18:31:54 CET] <philipl> So, I established that the encoder works until it runs out of surfaces [18:31:59 CET] <philipl> So it's not failing right away [18:32:14 CET] <philipl> Surfaces are being leaked. They get locked and then never unlocked [18:32:30 CET] <BtbN> Well, the encoder never signals that one is ready [18:32:37 CET] <BtbN> So of course they stay locked [18:40:56 CET] <philipl> huh. [18:42:07 CET] <BtbN> That's what I think is happening. But I can't think of a reason why [18:46:13 CET] <philipl> timestamps? The dts stuff is the main difference in the encoder logic [18:46:32 CET] <philipl> And it also only started happening after the filter merge [18:49:03 CET] <iive> i don't get it, how does it work at all if surfaces are only locked and never unlocked? [18:50:28 CET] <philipl> If you turn off bframes, or if you don't use hwaccel, it works fine. [18:50:35 CET] <philipl> That's the crazy part. [18:51:14 CET] <philipl> Not using hwaccel is a very different code path, as the surface management is completely different, so the comparison there is not so immediately useful. [18:51:36 CET] <philipl> but bframes - out of the stuff we control, there isn't much different. [19:02:45 CET] <BtbN> philipl, adding some debug-prints reveals that the very first call to nvEncEncodePicture already fails. [19:03:06 CET] <BtbN> [h264_nvenc @ 0x6000604a0] EncodePicture failed!: no encode device (1) [19:03:12 CET] <BtbN> Are we even seeing the same error? [19:03:25 CET] <philipl> Ah. [19:03:34 CET] <philipl> So if your rc-lookahead is 0, then you get that error. [19:04:15 CET] <philipl> (and without hwaccel, that works too) [19:05:02 CET] <BtbN> It almost looks like a driver-side issue to me. [19:05:13 CET] <BtbN> But hard to tell [19:05:30 CET] <philipl> yeah, except the filter merge thing. [19:05:34 CET] <philipl> If I revert that, then this works. [19:05:36 CET] <philipl> same driver [19:06:32 CET] <BtbN> Probably the same weird reason not binding the CUDA context worked before [19:06:59 CET] <philipl> maybe we need to bind more cuda contexts :-) [19:10:03 CET] <BtbN> It is bound while the error happens [19:10:42 CET] <philipl> Have you ever emailed one of the nvidia guys and got a response? [19:10:55 CET] <philipl> We could ask them to look at it. Presumably they care if this stuff works. [19:11:21 CET] <BtbN> They responded to some issues sent on the ML [19:14:35 CET] <BtbN> The error is also super weird: "indicates that no encode capable devices were detected" [19:14:53 CET] <philipl> I feel like that implies the combination of options is invalid [19:15:08 CET] <philipl> but then why does it work without hwaccel [19:16:03 CET] <BtbN> It kind of makes sense that requesting b frames implied lookahead [19:16:08 CET] <BtbN> *implies [19:16:24 CET] <philipl> yeah [19:16:42 CET] <BtbN> When doing "-bf 1 -rc-lookahead 1": [h264_nvenc @ 0x6000aa860] EncodePicture returned: need more input (17) [19:16:49 CET] <BtbN> Until nvenc runs out of free surfaces [19:17:45 CET] <philipl> so weird. [19:18:06 CET] <BtbN> Maybe it just needs more...? [19:18:35 CET] <philipl> I think I tried going all the way to hardware max surfaces and it didn't help [19:20:22 CET] <philipl> it does not [19:22:16 CET] <durandal_1707> BBB: it should have calculate enough bits it needs [19:22:45 CET] <BBB> durandal_1707: its really hard to give any sort of reasonable indication of what is wrong, I dont know, sorry [19:23:05 CET] <BBB> Im guessing theres a bug in VLC codes or buffer allocation, if you analyze it should be easy to figure out [19:23:49 CET] <durandal_1707> no, this is dnxhd encoder for 444 profile [19:24:11 CET] <BtbN> philipl, "-bf 1 -rc-lookahead 1 -delay 0" just makes it return the no encode device error again [19:24:14 CET] <durandal_1707> its basically 444 yuv pix fmt instead of 422 [19:25:25 CET] <BtbN> philipl, that makes me wonder... why does the async_delay influence the returned error from EncodePicture?! [19:25:31 CET] <BtbN> It's never passed to the encoder [19:25:46 CET] <BBB> durandal_1707: I dont know, sorry& I think the buffer or init size for the buffer is not big enough then [19:25:49 CET] <BBB> but Im sure you looked at that [19:25:54 CET] <BBB> I have no other suggestions beyond that [19:26:26 CET] <BtbN> "Lookahead not enabled. Increase buffer delay (-delay).", oh, that's why [19:26:32 CET] <durandal_1707> take look at code [19:27:19 CET] <philipl> BtbN: heh. [19:39:53 CET] <BtbN> philipl, well, this is either nvEncEncodePicture returning a weird error, or it never returning anything but need_more_input [19:50:43 CET] <BtbN> philipl, is the same happening on libav, btw.? [19:51:57 CET] <nevcairiel> libav doesnt have cuvid hwaccel to test t hat [19:52:20 CET] <BtbN> Oh, they never added that? Weird, as the CUDA pix_fmt comes from there [19:52:47 CET] <nevcairiel> they are still toying with the idea of making cuvid an actual hwaccel [19:59:46 CET] <BtbN> Well, if they feel like doing that. [20:15:59 CET] <BtbN> philipl, cuvid->hwupload_cuda->nvenc also works fine in all circumstances. [20:16:26 CET] <BtbN> So it's not the CUDA code in nvenc.c that's broken, but the specific combination of cuvid and nvenc sharing a cuda context, with cuvid being initialized first. [20:21:35 CET] <philipl> that does sound like a driver bug scenario [21:10:33 CET] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170325195844&slot=x86_64-archlinux… [21:10:43 CET] <ubitux> there is a cuvid dependency problem [21:14:17 CET] <ubitux> all my fate instances are back btw, except icc, but fuck intel anyway [21:38:57 CET] <durandal_1707> dnxhd is dct based codec, im working on 444 dnxhr profile [21:42:41 CET] <philipl> ubitux: It's because the hwaccel and the decoder are declared together under the decoder #define. So if hwaccel is requested and decoder is not, then it fails like this. [21:43:01 CET] <philipl> I'm not sure why we declare hwaccels as there is no actual hwaccel support. [21:43:04 CET] <philipl> BtbN: ? [21:43:46 CET] <BtbN> Because ffmpeg.c [21:45:01 CET] <BtbN> I'm not sure if that requirement is still needed after the merges [21:47:40 CET] <philipl> trying it out [21:48:52 CET] <philipl> doesn't work without the hwaccels declared [21:49:41 CET] <philipl> So have to separate out hwaccel decls to make the config robust [21:50:28 CET] <wm4> you'Re talking about AVHWAccels for "full" hw decoders? they're needed because libavcodec/utils.c [21:50:45 CET] <wm4> ff_get_format or whatever rejects hw pixfmts if there's no matching AVHWAccel [21:50:57 CET] <philipl> there you go. [21:51:42 CET] <BtbN> philipl, or just add proper dependencies to configure [21:51:52 CET] <wm4> we could just stop this and remove the associated utils.c code [21:52:41 CET] <philipl> BtbN: make hwaccel depend on decoder in configure? [21:52:48 CET] <BtbN> and vice versa [21:54:00 CET] <philipl> circular dependency? [21:55:08 CET] <BtbN> The dependency resolver is not that smart [21:55:24 CET] <BtbN> It will just error out if one of the two are disabled then [21:56:06 CET] <philipl> Does that count as a fate failure? [22:00:41 CET] <BtbN> Why does fate even get into that weird state? [22:01:48 CET] <philipl> random configuration test [22:06:37 CET] <ubitux> philipl: i won't fix that so sure, ok :) [22:06:54 CET] <BtbN> It is a legitimate bug though [22:07:08 CET] <BtbN> I guess the hwaccel should depend on the decoder [22:08:42 CET] <wm4> hwaccel dependencies are all kind of weird [22:09:05 CET] <BtbN> h264_cuvid_hwaccel_deps="cuda cuvid" -> h264_cuvid_hwaccel_deps="h264_cuvid_decoder cuda cuvid" [22:09:08 CET] <BtbN> same for all the other ones [22:09:09 CET] <wm4> e.g. auto detection (which leads to dxva2 etc. being enabled) factors into this [22:09:41 CET] <philipl> BtbN: yeah [22:20:20 CET] <nevcairiel> we have the "select" type for deps on internal components [22:20:30 CET] <nevcairiel> deps should be for external things [22:20:53 CET] <nevcairiel> so basically add h264_cuvid_hwaccel_selects=h264_cuvid_decoder [22:22:11 CET] <BtbN> Can it be added in both directions? [22:22:21 CET] <BtbN> Or will that cause weird cycles? [22:22:44 CET] <nevcairiel> cant you basically have the decoder without the hwaccel [22:22:54 CET] <nevcairiel> just not use the cuda pixfmt? [22:22:59 CET] <philipl> Yeah, it seems valid to ahve decoder without hwaccel [22:23:05 CET] <philipl> so circular dep is not required [22:32:16 CET] <iive> can the cuda decoder output regular yuv image? [22:32:36 CET] <nevcairiel> yes [22:33:04 CET] <nevcairiel> (also, its not cuda, but cuvid/nvdec, its still dedicated video hardware, not a "cuda program") [22:36:29 CET] <BtbN> Circular dependency for h264_cuvid_decoder. [22:36:29 CET] <BtbN> hm [22:36:59 CET] <BtbN> https://github.com/BtbN/FFmpeg/commit/524e0997be7e38898dc74d1b00154aff20c7f… [22:37:07 CET] <BtbN> aparently this is already enough to cause a circle [22:37:47 CET] <BtbN> Oh, because h264_cuvid_decoder_select="h264_mp4toannexb_bsf h264_cuvid_hwaccel" [22:40:06 CET] <nevcairiel> like I said, i dont think the decoder needs to depend on the hwaccel [22:40:13 CET] <iive> nevcairiel: is it the same hardware used by vdpau? [22:40:15 CET] <nevcairiel> it should be able to function fine without it [22:40:17 CET] <BtbN> Yeah, it's just the wrong way around right now. [22:40:20 CET] <nevcairiel> iive: yes [22:40:26 CET] <BtbN> https://github.com/BtbN/FFmpeg/commit/bd717340a28ef0fdb997584623236c4428a3b… [22:41:02 CET] <philipl> ship it [22:41:11 CET] <iive> nevcairiel: does the decoder output yuv automatically or it needs something extra. e.g. if you want to use software filters? [22:41:34 CET] <nevcairiel> it gives you a memory buffer with the yuv on it, you can either copy that to normal system memory or keep it on gpu memory [22:41:36 CET] <BtbN> it needs special treatment if you want it to NOT output YUV [22:42:12 CET] <iive> nevcairiel: i'm asking if ffmpeg can do it? [22:42:29 CET] <nevcairiel> it can [22:42:37 CET] <nevcairiel> it gives you yuv by default [22:42:49 CET] <nevcairiel> need extra options to keep it on gpu memory [22:43:25 CET] <iive> hum.. [22:45:06 CET] <nevcairiel> you can basically just use -c:v h264_cuvid and it uses the hardware decoder and gives you normal yuv [23:13:00 CET] <atomnuker> "ERROR SUMMARY: 1122806 errors from 311 contexts (suppressed: 0 from 0)" [23:13:08 CET] <atomnuker> how am I meant to debug this, valgrind? [23:13:41 CET] <atomnuker> all of them come from a single uninitialized variable somewhere which propagates and valgrind freaks out [23:14:31 CET] <iive> nevcairiel: i ask because somebody had problem with filters when using cuvid and nvenc. I assumed the surface remained on the card. [23:14:49 CET] <iive> i don't have nvidia hardware to test myself. [23:32:33 CET] <cone-982> ffmpeg 03Timo Rothenpieler 07master:bd717340a28e: configure: cuvid hwaccels need the corresponding decoder, not the other way around [23:33:48 CET] <BtbN> that should fix fate [23:56:11 CET] <kierank> wm4: any idea what this is https://stackoverflow.com/questions/40991412/ffmpeg-producing-strange-nal-s… [00:00:00 CET] --- Sun Mar 26 2017

1 0

ffmpeg.log.20170325
by burek 26 Mar '17

26 Mar '17

[00:00:49 CET] <oftc_ftw> furq: just fyi, its 556M to 4.2G; going to upload now [00:10:46 CET] <haroldp> furq: thanks so much for your help today. [00:14:33 CET] <alexpigment> oftc_ftw: just a note on your convo about the DVDs. if you do happen to have both DVD copies and also MP4 copies for browser viewing, make sure and deinterlace to 480p60 (or 576p50 if you're in a PAL region) [00:15:00 CET] <alexpigment> most people seem to be fine with throwing away half of the temporal resolution online, but that sticks out to my eyes way more than a slightly-lossy encoding [00:15:19 CET] <ZexaronS> libav doesn't have trac ? [00:15:52 CET] <oftc_ftw> alexpigment: i am no professional, but wouldn't lossless conversion imply original frame rate? [00:16:15 CET] <JEEB> ZexaronS: the libav* libraries in FFmpeg are part of FFmpeg [00:16:20 CET] <ZexaronS> oh nvm, it has a an irc channel [00:16:21 CET] <JEEB> so FFmpeg's trac is the correct place [00:16:32 CET] <JEEB> libav is a separate project, yes [00:16:39 CET] <ZexaronS> ah so ffmpeg project created libav? [00:17:16 CET] <JEEB> FFmpeg is a project that has libraries such as libavcodec, libavformat etc. [00:17:21 CET] <JEEB> Libav is a fork of FFmpeg from 2011 [00:17:22 CET] <ZexaronS> eh, i meant, if I want to contribute to libav [00:17:35 CET] <JEEB> which also provides its own versions of those libraries [00:17:51 CET] <JEEB> I will guess you meant FFmpeg's libraries and not Libav the project [00:18:02 CET] <JEEB> at least, given that you're on #ffmpeg [00:18:03 CET] <ZexaronS> I just want to see if I can contribute to libavfilter that ffmpeg uses, im not insterested in other forks that ffmpeg isn't using [00:18:18 CET] <ZexaronS> these names are confusing [00:18:23 CET] <JEEB> yes, libavfilter that you've built from FFmpeg is FFmpeg's [00:18:38 CET] <JEEB> so trac.ffmpeg.org is the correct place to report issues / feature requests [00:18:46 CET] <ZexaronS> so there's more flavors of libavfilter ? [00:18:56 CET] <JEEB> well Libav also contains libavfilter of their own :P [00:19:00 CET] <alexpigment> oftc_ftw: if you don't specify how interlaced content is handled in FFMPEG, you end up with progressive usually [00:19:01 CET] <JEEB> as it's a fork [00:19:37 CET] <ZexaronS> Not sure what's the point of keeping the name if both aren't related [00:19:39 CET] <alexpigment> oftc_ftw: and i don't think browsers / web players support interlacing to my knowledge [00:20:01 CET] <JEEB> ZexaronS: you can think of Libav as some developers of let's call it FFmpeg-old [00:20:10 CET] <JEEB> who forked as Libav [00:20:21 CET] <JEEB> so yes, the base was the same [00:20:37 CET] <JEEB> FFmpeg merges most of what Libav does so most improvements made in Libav get into FFmpeg [00:20:38 CET] <alexpigment> now to be clear, i'm not implying that deinterlacing is a good idea for posterity, but if your goal is to have something playable on the web, you want to do x264 with deinterlacing [00:20:54 CET] <JEEB> on the other hand Libav only does backports if someone posts a patch to Libav [00:21:00 CET] <JEEB> (and goes through their review process) [00:21:11 CET] <ZexaronS> but if I want a certain thing in libavfilter then I can do it through ffmpeg trac? [00:21:16 CET] <JEEB> yes [00:21:30 CET] <oftc_ftw> alexpigment: ok, do you quickly have a parameter that does deinterlace? or is it more complicated than that? [00:21:36 CET] <ZexaronS> and libav doesn't necessairly merge those into their stuff ? [00:22:05 CET] <ZexaronS> it's somewhat convoluted but I get it now [00:22:50 CET] <alexpigment> -vf yadif=1:-1:0 [00:22:50 CET] <furq> oftc_ftw: -vf yadif=1 [00:22:55 CET] <furq> assuming your input is actually interlaced [00:23:03 CET] <ZexaronS> jeeb: did you saw the idea i talked about earlier? [00:23:14 CET] <alexpigment> furq: if it's coming from VHS to DVD and it's not done by an idiot, it's probably interlaced ;) [00:23:23 CET] <furq> oh right i forgot the vhs bit [00:23:26 CET] <JEEB> ZexaronS: nope [00:24:10 CET] <oftc_ftw> thanks guys :) [00:24:23 CET] <alexpigment> oftc_ftw i specified 1:-1:0 for completeness sake, but the last two values are probably implied, so furq's solution might be equivalent [00:24:25 CET] <haroldp> If I wanna do HTML5 streaming video instead of Flash RTMP, what is a better streaming proto? [00:24:33 CET] <furq> hls [00:24:36 CET] <furq> which you can do with nginx-rtmp if you want [00:25:00 CET] <oftc_ftw> alexpigment: noted, thanks [00:30:31 CET] <haroldp> can I just set "hls on;" in the app I have, or do I need a seperate app for it? [00:31:05 CET] <furq> you can pretty much just do that [00:31:15 CET] <furq> you'll need hls.js for it to work on desktop [00:36:39 CET] <obamoose> can someone help me out with setting up a stream ;_;? [00:40:17 CET] <xtina> hi, can anyone remind me the correct syntax for h264-encoded video capture with ffmpeg? [00:40:19 CET] <haroldp> erm, do I need to enable an http server in nginx to server this? [00:40:35 CET] <oftc_ftw> alexpigment: i happen to live in a PAL region, could you kindly elaborate on that 576p50? i've never heard of such a thing actually. does it depend on the input? i would not care if the output is not PAL. (should i?) [00:40:54 CET] <oftc_ftw> is this reasonable? -c:v libx264 -vf scale=-1:720 -vf yadif=1:-1:0 -crf 18 -preset veryslow [00:41:03 CET] <oftc_ftw> ah forgot -framerate 60 [00:41:30 CET] <furq> don't use -framerate unless you want to change the framerate [00:41:56 CET] <oftc_ftw> oh ok [00:42:58 CET] <furq> pal dvds are 576i [00:43:12 CET] <furq> yadif=1 does a double-rate deinterlace which gives you 576p50 [00:43:24 CET] <llogan> xtina: from a device like a webcam, or a pipe, or...? [00:43:33 CET] <xtina> llogan: from a pi cam, yep [00:44:03 CET] <llogan> you can just search the IRC archives for your commands you pasted here previously [00:44:16 CET] <llogan> if you're looking for the same thing [00:44:42 CET] <xtina> haha, i am looking, but not sure how to search irc archives [00:44:47 CET] <xtina> i tried a google search of the irclogs [00:44:51 CET] <xtina> but it doesn't seem tow ork [00:44:58 CET] <oftc_ftw> the rip log says 720x576 indeed :) [00:45:16 CET] <alexpigment> oftc_ftw sorry i missed your earlier message but furq answered it nicely. out of curiosity, why are you scaling to 720 width? [00:45:29 CET] <oftc_ftw> so furq, how do i use it? is scale=-1:720 wrong? [00:45:40 CET] <oftc_ftw> i have no idea actually... [00:45:54 CET] <xtina> llogan: i tried this: https://www.google.com/search?sourceid=chrome-psyapi2&ion=1&espv=2&ie=UTF-8… [00:45:55 CET] <alexpigment> well, it's a good idea to get it out of anamorphic [00:46:08 CET] <xtina> i suppose that is not the right way to search irc logs.. [00:46:09 CET] <alexpigment> but i don't know if 720:-2 does that [00:46:27 CET] <alexpigment> furq: does the scale filer turn anamorphic into 1:1? [00:46:54 CET] <furq> you might need setsar as well [00:47:04 CET] <alexpigment> alternately, i guess -2:576 is probably the better way [00:47:10 CET] <oftc_ftw> i'm sorry, i'm such a noob in this, i don't know what the correct settings would be [00:47:18 CET] <furq> it's better to just leave it anamorphic [00:47:25 CET] <oftc_ftw> ok, so no scale at all? [00:47:27 CET] <furq> yeah [00:47:33 CET] <oftc_ftw> thanks :) [00:47:35 CET] <furq> i normally just crop to mod2 [00:47:37 CET] <alexpigment> furq: do web players support anamorphic fully? [00:47:45 CET] <JEEB> quite a few seem to [00:47:47 CET] <furq> firefox and chrome do [00:47:52 CET] <furq> i can't speak to any others [00:47:58 CET] <oftc_ftw> i use firefox, that should be fine [00:48:12 CET] <oftc_ftw> i will use "-c:v libx264 -vf yadif=1:-1:0 -crf 18 -preset veryslow" then [00:48:17 CET] <alexpigment> k, i'll defer to your knowledge. it seems like a thing that people *wouldn't* all support, but maybe i'm too pessimistic [00:48:31 CET] <alexpigment> looks like a good command line to me oftc [00:48:37 CET] <furq> i'm not sure i'd bother with veryslow if it's not for archival [00:48:37 CET] <oftc_ftw> thanks :) [00:48:38 CET] <TD-Linux> I think that pessimism is rational :) [00:48:59 CET] <furq> certainly not if you have plenty of space/bandwidth [00:49:00 CET] <oftc_ftw> furq: i have other things to do and dont care for how long it takes at all [00:49:01 CET] <ZeroWalker> hmm when compiling in a separate folder it seems to make a ton of source files, as well as the builds. Shouldn't i just get the builds;o? [00:49:04 CET] <furq> fair enough [00:49:10 CET] <alexpigment> the internet seems to pretend like NTSC/PAL never existed, hence my pessimism [00:49:18 CET] <furq> -preset medium -crf 17 will look about the same and run much faster, but it'll be a bit bigger [00:49:18 CET] <JEEB> ZeroWalker: on *nix those are symbolic links [00:49:36 CET] <JEEB> ZeroWalker: what will have only the build is the prefix [00:50:02 CET] <JEEB> ZeroWalker: so after make you run `make install` and just the stuff you need to use FFmpeg with gets installed properly into what you defined as --prefix [00:50:30 CET] <ZeroWalker> ah [00:50:49 CET] <alexpigment> medium and crf 17 bigger than veryslow and crf 10? interesting [00:51:10 CET] <ZeroWalker> or wait, ehm, hmm this was confusing [00:51:26 CET] <furq> alexpigment: 18, not 10 [00:51:29 CET] <JEEB> for build you will need the stuff around, so that's why it's there in your build root [00:51:33 CET] <alexpigment> ohhhh [00:51:47 CET] <JEEB> and the libraries/DLLs are located incorrectly, because it's the *build* root [00:51:49 CET] <alexpigment> remoted in and the monitor is scaled, so it looks the same [00:51:56 CET] <llogan> xtina: i guess it's not indexed [00:51:56 CET] <ZeroWalker> ah okay, but with the prefix and install it will copy the resulted data only? [00:52:01 CET] <ZeroWalker> to that folder [00:52:02 CET] <JEEB> yes [00:52:04 CET] <furq> you crazy people and your non-ssh irc clients [00:52:07 CET] <ZeroWalker> ah [00:52:23 CET] <ZeroWalker> and prefix starts from the home folder? [00:52:25 CET] <alexpigment> ;) [00:52:32 CET] <JEEB> ZeroWalker: you will have to define it [00:52:35 CET] <JEEB> during configure [00:52:39 CET] <ZeroWalker> Ah [00:52:44 CET] <JEEB> --prefix=/your/path/to/things [00:52:46 CET] <xtina> @llogan: i am trying: -f video4linux2 -i /dev/video0 -framerate 20 -s 1280x720 -c:v h264_omx \ [00:52:50 CET] <JEEB> the directory will get created [00:52:56 CET] <xtina> but it says 'Unknown decoder 'h264_omx'' [00:53:03 CET] <ZeroWalker> wait, but, is it relative to where it's launched or? [00:53:10 CET] <JEEB> no [00:53:18 CET] <xtina> my ffmpeg is compiled with omx: configuration: --extra-cflags=-I/opt/vc/include/IL --enable-nonfree --enable-omx-rpi --logfile=CONFIG.TXT [00:53:31 CET] <JEEB> msys2 uses *nix paths [00:53:40 CET] <JEEB> you start off in /home/your_user_name [00:54:09 CET] <ZeroWalker> ah okay, not used to how *nix works as i am a windows user;d [00:54:15 CET] <xtina> omx_h264 shouldn't be a decoder right? so i guess my order of params is wrong.. but how? [00:54:15 CET] <ZeroWalker> much appreciated [00:54:37 CET] <JEEB> ZeroWalker: this prefix thing is what most *nix configures lets you set in one way or another [00:54:51 CET] <JEEB> ZeroWalker: for example I do cross-compilation for Android a lot [00:55:02 CET] <JEEB> I always start with a clean prefix for it [00:55:05 CET] <llogan> xtina: i think omx is just an encoder. [00:55:11 CET] <JEEB> say, /home/jeeb/ownapps/armv7_prefix [00:55:18 CET] <xtina> @llogan: i'm trying to use it as an encoder, yes [00:55:21 CET] <JEEB> and thus I know that everything I build goes there [00:55:30 CET] <ZeroWalker> clean prefix, you mean empty/non-existing folder? [00:55:36 CET] <JEEB> yea [00:55:46 CET] <ZeroWalker> see, i am starting to understand this [00:55:52 CET] <ZeroWalker> i might still become a hero [00:56:30 CET] <ZeroWalker> i tried searching for the command to disable the binaries as i don't need them to no avail, you happen to know them? [00:56:42 CET] <xtina> llogan: http://pastebin.com/fBrjCCWC [00:57:26 CET] <JEEB> ZeroWalker: --disable-programs [00:57:32 CET] <ZeroWalker> i want to disable many things as i pretty much only need muxer/demuxer and codec (PCM,Opus,x264) and probably swscale for now. [00:57:36 CET] <JEEB> it's all listed in /path/to/configure --help [00:57:40 CET] <ZeroWalker> oh [00:57:44 CET] <ZeroWalker> thanks will check [00:57:45 CET] <llogan> xtina: options placement matters. you're attempting to apply it to -i /tmp/temp_audio.mp3 [00:57:52 CET] <ZeroWalker> i searched on "disable binaries";p [00:57:59 CET] <JEEB> :) [00:58:08 CET] <JEEB> ZeroWalker: also for colorspace conversions I deeply recommend zimg [00:58:14 CET] <JEEB> https://github.com/sekrit-twc/zimg [00:58:19 CET] <JEEB> usable from libavfilter as zscale [00:58:20 CET] <xtina> @llogan: i have tried putting omx_h264 in front of /dev/video0 but same error [00:58:34 CET] <xtina> http://pastebin.com/mvQbhu18 [00:58:39 CET] <ZeroWalker> is swscale slow or something? [00:58:58 CET] <JEEB> it supports a lot, but I consider it not always correct and in various ways meh [00:59:08 CET] <JEEB> it was made in times when threading wasn't as big, and CPUs were slower [00:59:14 CET] <ZeroWalker> though i am going to want to do it with the GPU through shaders (however that works). As it's data captured from Direct3D9 and the like [00:59:17 CET] <llogan> xtina: it's being interpreted as an input option for -i /dev/vide0 [00:59:19 CET] <JEEB> ah [00:59:40 CET] <JEEB> ZeroWalker: in that case if you're doing open source there's some shaders for that stuff @ mpv (although they're OpenGL) [00:59:41 CET] <xtina> isn't it an input option? [00:59:46 CET] <JEEB> vlc has D3D shaders [00:59:57 CET] <llogan> xtina: ffmpeg <input options> -i input0 <input options> input1 <output options> output [01:00:41 CET] <xtina> hmm, i see [01:00:46 CET] <xtina> i guess it's not an input option after all... haha [01:00:50 CET] <llogan> IIRC, previously you were piping from raspivid to ffmpeg. [01:01:07 CET] <xtina> llogan: yea, but i'd like to make use of -maxrate and -bufsize [01:01:11 CET] <xtina> in ffmpeg, so i'm switchign over [01:01:13 CET] <ZeroWalker> well i guess one would need to use shaders for the version i capture somehow. But well i leave that aside for now as it's not a top priority, but as it's most likely much faster as the data is in the GPU to begin, i would prefer to use it if possible [01:01:24 CET] <ZeroWalker> gonna try to do the precix stuff now [01:03:45 CET] <llogan> xtina: http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2017-February/004130.html has a link to one of your pastes that has a link to the rest of them under that account [01:04:01 CET] <llogan> (i just randomly picked a somewhat recent log) [01:09:12 CET] <xtina> llogan: OK. i don't know what is going on but i have never gotten omx h264 working with ffmpeg. it's why i always stuck with raspivid [01:09:34 CET] <xtina> http://vpaste.net/3MB5P [01:11:40 CET] <llogan> debug is too verbose. try to get it working with a local output file first. [02:11:00 CET] <oftc_ftw> furq and alexpigment: the latest command line we discussed gave me "The video playback was aborted due to a corruption problem or because the video used features your browser did not support." [02:11:01 CET] <oftc_ftw> me [02:11:28 CET] <oftc_ftw> VIDEOJS: ERROR: (CODE:3 MEDIA_ERR_DECODE) [02:12:45 CET] <oftc_ftw> could -crf 18 be the reason? [02:20:40 CET] <oftc_ftw> hmm, using only -c:v libx264 -vf yadif=1:-1:0 the videos still won't play [02:21:18 CET] <furq> no -preset veryslow? [02:21:25 CET] <furq> that would've been my guess [02:21:45 CET] <oftc_ftw> furq: in the second attempt i left that out as well, just to be sure [02:22:15 CET] <oftc_ftw> they do play locally tho, they're not corrupted [02:25:09 CET] <oftc_ftw> a non-educated wild guess: maybe the 50fps are an issue? [02:30:42 CET] <alexpigment> 50fps should be fine, assuming you're on a computer [02:30:43 CET] <furq> shouldn't be [02:31:53 CET] <furq> pastebin the output of `ffprobe foo.mp4` [02:31:56 CET] <alexpigment> oftc_ftw: what audio codec? [02:32:20 CET] <oftc_ftw> alexpigment: Stream #0:1 -> #0:1 (ac3 (native) -> aac (native)) [02:32:28 CET] <alexpigment> ah, gotcha [02:32:34 CET] <alexpigment> pastebin it is then :) [02:33:45 CET] <oftc_ftw> https://gist.github.com/anonymous/ecd4823e7c1d605a1e91ea8743341fce [02:33:48 CET] <oftc_ftw> there you go [02:33:59 CET] <alexpigment> oh [02:34:01 CET] <alexpigment> high 10 [02:34:05 CET] <alexpigment> you're using 10-bit x264 [02:34:22 CET] <oftc_ftw> alexpigment: not intentionally for this lq version [02:34:38 CET] <oftc_ftw> err, yes i do :D [02:34:43 CET] <oftc_ftw> took a while... [02:35:04 CET] <oftc_ftw> can i emulate the 8-bit (?) version somehow? [02:35:09 CET] <alexpigment> ffmpeg with x264 high bit depth and normal 8-bit depth are mutually exclusive in my experience [02:35:17 CET] <furq> more or less [02:35:20 CET] <alexpigment> try just downloading a precompiled static build [02:35:24 CET] <oftc_ftw> so i need to re-install? [02:35:27 CET] <furq> no [02:35:42 CET] <furq> wait [02:35:43 CET] <furq> is this windows [02:35:46 CET] <furq> if so then yes [02:35:48 CET] <oftc_ftw> no it's linux [02:35:56 CET] <alexpigment> oh yeah, there's a way to do it on linux [02:36:01 CET] <alexpigment> furq knows more about it [02:36:11 CET] <oftc_ftw> nice :) [02:36:19 CET] <furq> if you have an 8-bit libx264.so of the same version, you can do it with LD_LIBRARY_PATH [02:37:28 CET] <furq> LD_LIBRARY_PATH=/usr/local/lib ffmpeg -i ... [02:37:34 CET] <oftc_ftw> hmm, it seems i'd have to download the binary which is more of an hassle than to just reinstall the 8 bit packet [02:37:44 CET] <furq> or you could just do that [02:37:55 CET] <alexpigment> if in doubt, 8 is what you'll want [02:37:58 CET] <oftc_ftw> reinstallation done :P [02:38:01 CET] <furq> if ffmpeg is dynamically linked then you should be able to swap out libx264 [02:38:06 CET] <furq> as long as the version is identical [02:38:21 CET] <furq> the LD_LIBRARY_PATH trick is just for if you want to be able to swap between them at will [02:39:00 CET] <oftc_ftw> i noticed these lines in the previous conversion: [02:39:00 CET] <oftc_ftw> No pixel format specified, yuv420p10le for H.264 encoding chosen. [02:39:00 CET] <oftc_ftw> Use -pix_fmt yuv420p for compatibility with outdated media players. [02:39:08 CET] <oftc_ftw> could that have worked? [02:39:08 CET] <furq> yeah that's because of the 10-bit x264 [02:39:29 CET] <furq> you can only do yuv4**p10le with 10-bit x264 [02:39:30 CET] <alexpigment> man, have i seen *that* message a lot lately ;) [02:39:47 CET] <furq> and none of those will work with most players [02:39:54 CET] <oftc_ftw> i see, thanks. the message is gone now, currently running the conversion [02:40:10 CET] <alexpigment> i presume you put all the original parameters back in? [02:40:17 CET] <oftc_ftw> hehe, i just figured 10 bit is better then 8 bit when in doubt [02:40:30 CET] <furq> it is better in every regard except support [02:40:35 CET] <furq> which is a shame [02:40:38 CET] <oftc_ftw> alexpigment: i'll try the quick version first, then the veryslow one [02:40:38 CET] <alexpigment> yep [02:40:48 CET] <alexpigment> oh, i also think veryslow is pointless [02:40:51 CET] <alexpigment> medium is what i use [02:40:54 CET] <alexpigment> with a lower CRF [02:40:58 CET] <alexpigment> as furq suggested earlier [02:41:04 CET] <furq> i use veryslow and 20, but that's for archival [02:41:22 CET] <furq> i wouldn't do that for cloud storage [02:42:28 CET] <oftc_ftw> so, 17 and medium instead of 18 and veryslow? but i thought the lower the number the less lossy? [02:42:41 CET] <alexpigment> that's my vote, fwiw [02:43:10 CET] <furq> lower crf = higher quality [02:43:16 CET] <furq> but also slower preset = higher quality [02:43:23 CET] <furq> so you're reducing one and increasing the other [02:43:29 CET] <oftc_ftw> i see :) [02:43:39 CET] <furq> tbh i think medium at 18 will already look great [02:43:52 CET] <furq> i'm perfectly happy with veryslow at 20 for dvd rips [02:43:57 CET] <oftc_ftw> the new video works :) [02:44:23 CET] <alexpigment> cool. 10-bit is about the only thing i could think that a video on a computer wouldn't support [02:44:30 CET] <oftc_ftw> i guess i'm fine with keeping the dvd rip and a lower quality "preview" version [02:44:42 CET] <furq> the other possibility was too high level [02:44:47 CET] <furq> but i don't think that's an issue at 576p [02:45:05 CET] <furq> i'm still not entirely clear on what the limits are for that [02:45:06 CET] <alexpigment> too high of a level on a computer is rare [02:45:15 CET] <furq> well i meant in a browser [02:45:20 CET] <alexpigment> high is only limited on handhelds [02:45:26 CET] <furq> level, not profile [02:45:31 CET] <alexpigment> even so [02:45:38 CET] <alexpigment> maybe once you get to level 5 [02:45:55 CET] <furq> i know refs affect the level but i assume it does that less at lower resolution [02:46:02 CET] <alexpigment> yeah, refs can do it [02:46:12 CET] <alexpigment> but you have to specify more refs i think [02:46:15 CET] <alexpigment> right? [02:46:16 CET] <oftc_ftw> also thanks again for the hint with deinterlace, it's so obvious when you know it. :D [02:46:18 CET] <furq> veryslow affects refs [02:46:29 CET] <alexpigment> oh gotcha [02:46:32 CET] <alexpigment> <-- never uses veryslow [02:46:34 CET] <furq> veryslow is 16 refs [02:46:35 CET] <alexpigment> ;) [02:46:39 CET] <alexpigment> aight, i'm out [02:46:40 CET] <alexpigment> later guys [02:46:42 CET] <furq> which will probably cause some issues at 1080p [02:46:57 CET] <oftc_ftw> later alexpigment and thanks again [02:47:12 CET] <alexpigment> np. furq always has the good info though. thank him ;) [02:47:24 CET] <oftc_ftw> yes, thanks furq! [02:47:58 CET] <furq> thanks furq [02:55:24 CET] <xtina> hey guys. i'm a bit confused what ffmpeg does when it's at <1.0x speed. when i watch my livestream, the video is moving at >1.0x speed while the audio is at 1.0x speed [02:56:37 CET] <xtina> i'm wondering if this is because i'm dropping video packets before ffmpeg eats them [02:56:45 CET] <xtina> or if it's something ffmpeg is actually doing with the video packets? [02:56:55 CET] <xtina> (i'm using raspivid for recording atm) [03:10:09 CET] <xtina> i can only think that because i'm streaming <1.0x, video packets build up and ffmpeg reads them as quickly as it can, so sometimes the video is frozen and other times the video is streaming at >1.0x speed [03:10:26 CET] <xtina> but if that's true, why is the audio streaming at a consistent 1.0x speed - it's never frozen and never going >1.0x? [03:11:30 CET] <xtina> i thought ffmpeg always had to mux video+audio before sending them out, so how is it possible that the video and audio are running at different speeds? [03:35:33 CET] <xtina> i have tried using the -re param with my video input file so it streams at real-time speed [03:35:41 CET] <xtina> but it still sometimes streams faster than realtime if my ffmpeg speed <1.0x [03:36:07 CET] <xtina> here's my command: http://vpaste.net/61LII [03:36:45 CET] <xtina> here's the resulting stream: https://www.youtube.com/watch?v=H3h1NxVYYZU [03:37:06 CET] <xtina> at the 0:45s mark in you can see that the video speeds up, while the audio remains 1.0x speed [03:37:30 CET] <xtina> my CPU usage <25% so i know that's not the issue [03:37:35 CET] <xtina> am i misunderstanding what -re is supposed to do? [03:38:39 CET] <xtina> if i specified -re and it sometimes still streams video at >1.0x speed, does that mean that raspivid is somehow dropping frames? [04:24:48 CET] <kepstin> xtina: ffmpeg doesn't care about realtime, in your config it never drops frames, it just reads on, does stuff, reads another, does stuff, and so on [04:25:32 CET] <kepstin> so any frame dropping is happening because raspivid is blocked so it can't write to ffmpeg, which prevents it from capturing another frame [04:25:58 CET] <kepstin> I'm guessing this is less likely to happen with audio, because audio is smaller, so it's less likely to fill up the pipe buffer [04:27:07 CET] <kepstin> the "-re" option should not be used in your case - all that does is make ffmpeg block the video even more, because it adds an occasional "sleep" in ffmpeg where it does nothing. this mode is for if you're playing back a local file to a remote server, and want it streamed at close to realtime [04:27:27 CET] <kepstin> if you have a live source, you want ffmpeg to send data as fast as the live source is making new data, so don't use -re [04:29:47 CET] <kepstin> since ffmpeg is a batch encoding tool, the speed indicator (1.0x) is really just to estimate how long your batch encoding time is gonna take relative to the input file length :/ [05:15:54 CET] <lindylex> I get this error "...vf/-af/-filter and -filter_complex cannot be used together for the same stream" When I do this ffmpeg -i slice.MOV -i url.png -filter_complex "overlay=x=(main_w-overlay_w)/2:y=(main_h-overlay_h)/2" -vf "crop=640:640:250:40" 1.mov [05:21:20 CET] <furq> you can't use filter_complex and vf [05:21:50 CET] <furq> -filter_complex "overlay=x=(main_w-overlay_w)/2:y=(main_h-overlay_h)/2,crop=640:640:250:40" [05:22:52 CET] <lindylex> furq: Thanks I will give this a try. [05:36:17 CET] <lindylex> furq: thanks that was amazing it all worked. [05:36:39 CET] <lindylex> I struggle with how to combine the commands. [08:00:01 CET] <xtina> kepstin: thanks for the explanation, i won't use -RE then [08:00:25 CET] <xtina> when my audio buffer overruns i see an alsa buffer overrun msg and it's very obvious audio packets drop because multi-second chunks of audio are missing [08:00:40 CET] <xtina> but my issue with video now is that sometimes it streams at >1.0x speeds but it seems continuous and smooth - there's no obvious drops [08:00:47 CET] <xtina> and there's no print output telling me the raspivid buffer overran [08:01:02 CET] <xtina> how can you be sure that the raspivid buffer overruns? i dont' see any skips in the video [08:01:12 CET] <xtina> i just see the video sometimes playing really fast.. [08:17:57 CET] <dsc_> guys, how does realtime encoding work ;d [08:18:14 CET] <dsc_> say I have a .mkv file that I'd like to have in h264 so that it works in the browser [08:18:26 CET] <dsc_> and I want to do this conversion server side, on-the-fly [08:18:30 CET] <dsc_> can I do that with ffmpeg? [08:20:30 CET] <dsc_> (without having to wait before the file is encoded) [08:20:40 CET] <dsc_> perhaps encode it in parts ... [08:39:56 CET] <thebombzen> xtina: I feel like we've told you about twenty five times not to use -re [08:40:31 CET] <thebombzen> xtina: you say it's streaming at >1.0x but what is it actually streaming at? [08:40:37 CET] <thebombzen> is it like 1.01x? [08:46:28 CET] <xtina> thebombzen: [08:46:31 CET] <xtina> it's streaming at 0.5x [08:46:36 CET] <xtina> when i watch the stream itself [08:46:38 CET] <xtina> sometimes it's buffering [08:46:48 CET] <xtina> sometimes it's going at like 2-3x speeds (judging from watching it on youtube) [08:47:10 CET] <xtina> this is VIDEO only. audio goes at realtime speeds (whenever it isn't buffering) [08:47:33 CET] <xtina> i'm trying to understand what is happening here. are packets being dropped by raspivid? or is ffmpeg streaming at greater than realtime speeds for bursts of time? [08:47:57 CET] <xtina> to be clear. ffmpeg reports ~0.5x speed. on the youtube stream sometimes it buffers, sometimes video goes 2-3x fast [08:49:20 CET] <xtina> while the audio sometimes buffers and otherwise goes exactly 1x fast on the stream [08:52:35 CET] <thebombzen> well are you unable to encode video in realtime or is ffmpeg not even receiving video in realtime? [09:00:08 CET] <xtina> thebombzen: i'm not sure how to tell [09:00:16 CET] <xtina> because raspivid gives me 0 debugging output even when i'm verbose mode [09:00:20 CET] <xtina> but i'm h264 encoding with raspivid [09:00:23 CET] <xtina> ffpeg just receives h264 [09:00:44 CET] <xtina> i told raspivid to annotate the frames by frame# so i could look for some frame drops [09:00:58 CET] <xtina> and as far as i can tell, there aren't any missing frames, this is why i suspected something was wrong with ffmpeg [09:01:43 CET] <xtina> you can see what i mean here: https://www.youtube.com/watch?v=H3h1NxVYYZU [09:01:46 CET] <xtina> at the 0:45s mark [09:01:48 CET] <xtina> the video starts to speed up [09:02:00 CET] <xtina> (this is with ffmpeg streaming at 0.5x speed, due to low wifi signal) [09:02:35 CET] <xtina> but overall, i don't know how to tell where in the pipeline things go wrong, since raspivid has no debug output... [09:41:19 CET] <thebombzen> xtina: try reading from libavfilter rather than from a pipe [09:41:23 CET] <thebombzen> see if it works [09:42:10 CET] <xtina> thebombzen: isn't libavfilter a filter library? i don't want to apply filters on the inputs because then they would have to be decoded first right? [09:42:14 CET] <xtina> i'm passing encoded audio/video into ffmpeg [09:42:32 CET] <thebombzen> xtina: you can also use it to create a test source [09:42:40 CET] <thebombzen> ffmpeg -f lavfi -i testsrc will give you a test source [09:43:53 CET] <xtina> thebombzen: to clarify, my whole pipeline works great as long as i have good wifi [09:43:57 CET] <thebombzen> also, have you considered recording from raspivid to a file for about a minute, and then using ffmpeg to stream that file (this time with -re) [09:44:00 CET] <xtina> i'm testing it under low wifi conditons [09:44:06 CET] <thebombzen> well [09:44:13 CET] <thebombzen> if your wifi is bad then it's not an ffmpeg problem [09:44:23 CET] <thebombzen> if it works with good internet then it's not an ffmpeg issue [09:44:48 CET] <thebombzen> if this only happens when your wifi is bad then it means data is getting clogged in a buffer somewhere [09:44:52 CET] <thebombzen> network-wise [09:45:19 CET] <thebombzen> given that it happens only with video and not audio my best guess is your ISP is packet sniffing and throttling the video [09:45:34 CET] <thebombzen> to which there is nothing you can do [11:29:34 CET] <australia> Hello. I have an install error I am looking for help. " yasm/nasm not found or too old. Use --disable-yasm for a crippled build. " [11:30:32 CET] <JEEB> if you are building for x86/x86_64 then just install yasm [11:30:41 CET] <JEEB> you definitely don't want to build without it [11:42:49 CET] <australia> izzymate@izzymate ~ $ urpmi ffmpeg Package ffmpeg-2.8.9-1.1plf-plf2014.1.x86_64 is already installed [11:42:52 CET] <australia> mybad lol [11:44:21 CET] <australia> Although I have never used it before. What Ive been curious about is when Ive used youtube-dl ( Linux ) I get downloads outputs in MKV MP4 and WEBM ............. [11:44:37 CET] <australia> I want to convert all into MP4 [13:10:46 CET] <Qas> hello everyone, which ffmpeg download should I use for ubuntu 14.4.3 ? [13:11:11 CET] <Qas> I see official packages for later versions. and 'multimedia for trusty PPA' [13:11:22 CET] <Qas> trusty is 14.4.3 [13:11:57 CET] <JEEB> if you need just the command line tool I recommend either building one yourself that doesn't interfere with your package management, or using one of the static binaries linked around here [13:12:53 CET] <Qas> JEEB, yes, i will use command line, so I should use the multimedia ppa? [13:13:22 CET] <JEEB> no [13:13:30 CET] <JEEB> or at least I haven't seen any PPAs recommended here [13:13:50 CET] <JEEB> mostly because PPAs tend to have packages that imitate what's in teh main repos and that will cause major chaos [13:15:09 CET] <JEEB> I don't use these myself but you can download just the command line tool from https://johnvansickle.com/ffmpeg/ [13:15:22 CET] <JEEB> and then you can call it where you extracted it [13:15:27 CET] <JEEB> like ~/my_apps/ffmpeg [14:04:50 CET] <bmduser> Hi could anyone shed some light on this? I am trying to get ffmpeg to capture from the blackmagic studio2 capture card but all it captures is color bars [14:05:45 CET] <bmduser> thinking that i didnt get the resolution and framerate correct i checked with the desktop video utility and found that it was exactly as i set at 1080p 25 [14:06:20 CET] <thebombzen> what do you mean be color bars? [14:06:25 CET] <bmduser> however when i use ffmpeg to capture at 1080p 25 i am still getting color bars [14:06:25 CET] <thebombzen> can you post a screenshot? [14:06:59 CET] <thebombzen> my best guess is it's a pixel format error but can you upload a screenshot and give us the link? [14:07:37 CET] <bmduser> color bar like this [14:07:56 CET] <bmduser> https://i.ytimg.com/vi/mO98ninuGJc/maxresdefault.jpg [14:08:11 CET] <thebombzen> is that the screenshot you generated? [14:08:16 CET] <thebombzen> or is that something you googled? [14:08:32 CET] <bmduser> no its the exact same thing that got captured [14:08:55 CET] <bmduser> here is my pastebin [14:08:57 CET] <bmduser> http://pastebin.com/1R0eAJ7L [14:09:24 CET] <thebombzen> well you're using a version of FFmpeg from 2014 [14:09:26 CET] <thebombzen> that's 3 years old [14:09:33 CET] <thebombzen> try updating your FFmpeg and trying again [14:10:08 CET] <thebombzen> here's a link for your convenience: https://ffmpeg.zeranoe.com/builds/ [14:10:22 CET] <bmduser> ah ok thanks let me go have a look [14:11:35 CET] <thebombzen> I also find it amusing that you're using a nonfree build of ffmpeg [14:11:55 CET] <thebombzen> whoever gave you that is violating the license [14:12:13 CET] <thebombzen> (unless you built it yourself) [14:14:51 CET] <bmduser> oh i didnt realize that thanks [14:17:28 CET] <bmduser> i am trying to wrap my head around this compiling it seems a bit overwhelming for me at the moment [14:19:15 CET] <bmduser> am i right to say the pre compiled versions would not have been built with decklink support? [14:19:40 CET] <bmduser> and I would need to compile on my one and enable decklink support during the compile? [14:39:31 CET] <bmduser> thanks thebombzen i went to zeroanoe and downloaded the december version with he decklink compiled in it [14:39:56 CET] <thebombzen> did it work? [14:40:18 CET] <thebombzen> it'll have decklink support as long as it was built with --enable-decklink [14:40:21 CET] <thebombzen> afaik Zeraoe does that [15:10:25 CET] <cesdo> Hello. [15:10:55 CET] <cesdo> Tryed to compile VLC and got some errors( [15:11:04 CET] <cesdo> codec/avcodec/video.c: In function DecodeBlock: [15:11:04 CET] <cesdo> codec/avcodec/video.c:848:19: error: implicit declaration of function avcodec_send_packet [-Werror=implicit-function-declaration] [15:11:04 CET] <cesdo> int ret = avcodec_send_packet(p_context, &pkt); [15:11:04 CET] <cesdo> ^ [15:11:04 CET] <cesdo> codec/avcodec/video.c:869:15: error: implicit declaration of function avcodec_receive_frame [-Werror=implicit-function-declaration] [15:11:04 CET] <cesdo> ret = avcodec_receive_frame(p_context, frame); [15:11:05 CET] <cesdo> ^ [15:11:05 CET] <cesdo> cc1: some warnings being treated as errors [15:11:38 CET] <JEEB> sounds like your libavcodec is too old [15:12:04 CET] <JEEB> but the configure check should checked the version... [15:13:02 CET] <JEEB> so it sounds like it's either picking up wrong headers (which don't contain those APIs), or you somehow got through the configure checks without having those functions in there [15:18:10 CET] <cesdo> JEEB: I have two versions of ffmpeg -- one is in /usr/bin and one is in ~/ffmpeg_sources. To use version that is in ~/ffmpeg_sources I did [15:18:31 CET] <cesdo> PKG_CONFIG_PATH=/home/user/ffmpeg_sources/ffmpeg/libavcodec:/home/user/ffmpeg_sources/ffmpeg/libswresample:/home/user/ffmpeg_sources/ffmpeg/libavutil:/home/user/ffmpeg_sources/ffmpeg/libavformat:/home/user/ffmpeg_sources/ffmpeg/libswscale ./configure --disable-chromecast --enable-aa --enable-realrtsp --disable-wayland [15:19:12 CET] <JEEB> that's incorrect [15:19:22 CET] <cesdo> wtf [15:19:25 CET] <cesdo> why [15:19:54 CET] <cesdo> How can I do it right? [15:20:50 CET] <JEEB> what you're supposed to do is use --prefix when you configure FFmpeg (say, /home/user/ffmpeg_prefix), do a `make install` so that FFmpeg can actually create a proper directory structure and install files correctly, and then set PKG_CONFIG_PATH=/home/user/ffmpeg_prefix/lib/pkgconfig ./configure --options with VLC or anything else using that stuff [15:21:07 CET] <JEEB> if that still picks up the wrong libav*.pc files, then you have to switch to PKG_CONFIG_LIBDIR [15:21:18 CET] <JEEB> which ignores what you have in the pkg-config search path already [15:21:26 CET] <JEEB> (usually only used in cross-compilation) [15:21:54 CET] <JEEB> but yeah, the basic part being that the files in the build directory are not meant to be used as-is [15:22:07 CET] <JEEB> it's not in the correct way since it's the *build* directory [15:22:37 CET] <JEEB> you set a prefix with --prefix and utilize `make install` and FFmpeg's libraries, headers and apps will get properly installed into bin/ lib/ include/ in that prefix [15:23:03 CET] <JEEB> and you set PKG_CONFIG_PATH to /your/prefix/lib/pkgconfig [15:23:05 CET] <JEEB> and you're done [15:23:32 CET] <JEEB> (exceptions happen when you have stuff in your /usr/lib/pkgconfig already related to that stuff, which pkg-config might or might not pick up [15:23:53 CET] <JEEB> in which case you either get rid of the pc files in there, or use PKG_CONFIG_LIBDIR [15:23:58 CET] <JEEB> which overrides instead of appending [15:33:44 CET] <JEEB> cesdo: and I'm not even going to ask why you're not using the contribs system which would build Libav or FFmpeg for you [15:43:51 CET] <marcurling> Hello, under Win7, using the ouput option "pan=stereo| FL < FL + 0.5*FC + 0.6*BL + 0.6*SL | FR < FR + 0.5*FC + 0.6*BR + 0.6*SR" gives "Specified file is unfindable" < (traslated: may be not the exact English text) [15:44:40 CET] <marcurling> Does one has any workaround ? (I guess the pb comes from the < and pipes) [15:49:37 CET] <marcurling> ok migthy sword, will do immediately ;) [15:55:18 CET] <marcurling> http://pastebin.com/RvrwCAg8 [15:56:43 CET] <marcurling> (it could be just something I miss between '-acodec aac' and 'pan=...') [15:57:42 CET] <marcurling> I got the option from https://ffmpeg.org/ffmpeg-filters.html#Mixing-examples [16:11:49 CET] <ZeroWalker> is it possible to disable all encoder/decoders to then manually select the ones you want? [16:11:57 CET] <ZeroWalker> instead of disable all manually [16:12:09 CET] <JEEB> yes [16:12:18 CET] <ZeroWalker> ah nice [16:12:24 CET] <JEEB> --disable-everything is a thing, but you will have to make sure you enable everything you really need [16:13:10 CET] <ZeroWalker> ah yeah saw that one, was hoping there was a thing for only encoder/decoders etc, will have to try it out, hopefully it's not that complicated [16:14:24 CET] <ZeroWalker> oh wait there is [16:14:26 CET] <ZeroWalker> i am blind [16:14:27 CET] <JEEB> there might be, look at --help [16:14:31 CET] <JEEB> gg [16:16:04 CET] <marcurling> JEEB how could this work in a shell/console when < and | sign will be considered as redirections ? [16:16:06 CET] <marcurling> https://ffmpeg.org/ffmpeg-filters.html#Mixing-examples [16:16:51 CET] <JEEB> marcurling: you just make sure the shell doesn't try to evaluate it. whatever your effing shell/console/terminal emu is [16:16:52 CET] <dsc_> Encoding chunks of video to .mp4 h264, is that something ffmpeg can do [16:17:11 CET] <dsc_> and these chunks can be any bytestream of arbitrary length [16:21:47 CET] <IntruderSRB> 'ello everyone [16:21:54 CET] <IntruderSRB> @JEEB want to thank you for all the help you gave - got fmp4/cbcs finally working on my packager :D [16:22:59 CET] <IntruderSRB> issue was the most stupid thing on earth ... for some reason my sps parser made default value for chroma_format_idc to be 0 and not 1 ... with that there's no chance I would parse h264 video slice correctly :) [16:24:57 CET] <JEEB> heh [16:27:22 CET] <IntruderSRB> yea ... exactly my thought after 1 week troubleshooting it :D [16:29:04 CET] <TAFB> I want to downsize 1080p to 540p (50% scale) but want it to be super sharp. When I run "ffmpeg -i tos.mov -vf scale=-1:540 tos_0x540.mov" the final output looks "soft", is there a smoothing filter run on the output by default? [16:31:00 CET] <JEEB> outputting 4:4:4 might help you but I have no idea of your requirements. also using scalers from zimg (via the zscale filter) might help [16:32:43 CET] <sfan5> there's also different scalers to select http://ffmpeg.org/ffmpeg-scaler.html#scaler_005foptions [16:33:44 CET] <JEEB> yes, different things available in both swscale and zimg/zscale [16:34:13 CET] <TAFB> thanks guys, I'll take a look [16:38:37 CET] <sfan5> hm why do all tutorials suggest -f also -i pulse when there is a pulse device? [16:46:25 CET] <JEEB> welcome to tutorials, and I'm not sure of the age or quality of either module [17:05:29 CET] <ZeroWalker> hmm, when you want to add like opus etc, how did that work, do you compile and make install opus beforehand? [17:13:41 CET] <thebombzen> did someone say discussion of best video scalers? [17:13:50 CET] <TAFB> me me me [17:14:00 CET] <TAFB> 50% downscaling, what it sharp AF :D [17:14:03 CET] <thebombzen> lol we're literally having this dicussion right now in #mpv [17:14:09 CET] <thebombzen> but mitchell is particularly good at downscaling [17:14:13 CET] <DHE> ZeroWalker: I think ffmpeg has its own opus encoder [17:14:16 CET] <TAFB> mitchell? [17:14:43 CET] <DHE> oh, never mind [17:14:46 CET] <ZeroWalker> hmm, i get opus doesn't exist [17:14:53 CET] <ZeroWalker> or something [17:14:54 CET] <thebombzen> doesn't have it [17:14:58 CET] <thebombzen> TAFB: try "spline" [17:15:02 CET] <DHE> yeah I'm wrong [17:15:27 CET] <TAFB> thanks thebombzen :) [17:15:34 CET] <thebombzen> also try lanczos [17:15:40 CET] <thebombzen> it depends onw hat looks better [17:21:10 CET] <obamoose> hello [17:26:58 CET] <obamoose> can someone help me figure out how to create a stream that loops forever [17:27:24 CET] <TAFB> obamoose: pretty tricky :( [17:27:32 CET] <obamoose> ;_; [17:27:46 CET] <obamoose> http://pastebin.com/0QjWULPL [17:27:50 CET] <obamoose> this is my current config [17:27:51 CET] <obamoose> It works [17:28:16 CET] <obamoose> but it restarts the stream after every file [17:28:17 CET] <TAFB> nice, I ended up making up a huge concat list, worked fine for me [17:28:21 CET] <obamoose> so it only kinda works [17:28:40 CET] <TAFB> just make a concat list that's 90000000000 lines long with repeating lists of your file, it'll work great. [17:28:50 CET] <obamoose> not a single file though [17:28:51 CET] <obamoose> a directory [17:29:19 CET] <TAFB> as long as the files stay the same, file1.mp4, file2.mp4, file3.mp4, file1.mp4, file2.mp4, file3.mp4, file1.mp4, etc. [17:29:48 CET] <ZeroWalker> what's the command to install autoreconf in via pacman, i tried that and autotools to no avail [17:38:46 CET] <BtbN> automake and autoconf i guess [17:39:17 CET] <BtbN> but those dont apply to ffmpeg to begin with [17:40:21 CET] <ZeroWalker> yeah it's for libopus, will see if making and installing it makes it work in ffmpeg [17:42:52 CET] <JEEB> FFmpeg itself has opus decoder and encoder, but libopus is still better with encoding [17:44:13 CET] <ZeroWalker> ah [17:49:24 CET] <ZeroWalker> configure: error: no acceptable ld found in $PATH [17:49:28 CET] <ZeroWalker> what's this? [17:50:36 CET] <JEEB> oh right [17:50:39 CET] <JEEB> you were on MSVC [17:50:43 CET] <JEEB> that's fun with various things :P [17:51:30 CET] <JEEB> now the fun part is that libopus probably has a MSVS solution, but of course that has no pkg-config files or such [18:12:42 CET] <ZeroWalker> oh, yay xd [18:17:42 CET] <ZeroWalker> okay it had msvc stuff and i could build those, so that part is fine at least. can i manually install it somehow;o? [18:17:56 CET] <thebombzen> obamoose: have you considered the many many times I have told you what to do [18:18:12 CET] <obamoose> I told you I'm retarded [18:18:28 CET] <thebombzen> did you try it though? [18:18:44 CET] <obamoose> up until I couldn't understand what I was doing [18:18:50 CET] <obamoose> Can we try again ;_;? [18:18:53 CET] <thebombzen> what about when we asked you to literally copy and paste [18:18:56 CET] <obamoose> I did [18:19:02 CET] <obamoose> while true; do cat *.ts; done | ffmpeg -y -re -f mpegts -i - <rest of your command line> [18:19:15 CET] <thebombzen> there you go [18:19:22 CET] <obamoose> but I don't understand ;_; [18:19:27 CET] <thebombzen> so what? [18:19:35 CET] <obamoose> where does the rest go? [18:19:39 CET] <obamoose> define rest [18:20:01 CET] <thebombzen> well you had: ffmpeg <some stuff> -i <input filename> <some other stuff> [18:20:04 CET] <thebombzen> I mean the <some other stuff> [18:20:05 CET] <ZeroWalker> your original command arguments i guess [18:21:08 CET] <thebombzen> listen if you're going to be streaming other people's IP at least learn how [18:22:03 CET] <obamoose> but but [18:22:14 CET] <thebombzen> I'm wondering if "I'm retarded ;_; it restarts the stream after every file" is going to become the new "there's a huge bug in vlc and the devs aren't willing to fix it" [18:24:01 CET] <obamoose> how do I track the killers IP using visual basic gui interfaces? [18:24:05 CET] <ZeroWalker> i am actually also doing streams to point to point [18:24:52 CET] <obamoose> cat: '*.ts': No such file or directory [18:24:57 CET] <obamoose> is the error i'm getting [18:25:06 CET] <obamoose> " " yes? [18:25:58 CET] <thebombzen> ZeroWalker: this guy is streaming to twitch [18:26:11 CET] <thebombzen> namely he's streaming videos he downloaded from youtube channels [18:26:20 CET] <thebombzen> without having any clue how to use a command line [18:26:27 CET] <bmduser> thebombzen yes it did work with the december version!!! [18:26:29 CET] <thebombzen> or any sort of ability to read or copy/paste [18:26:34 CET] <thebombzen> bmduser: there you go :) [18:26:39 CET] <thebombzen> bugs get fixed [18:27:23 CET] <thebombzen> when I see this discussion I just wanna be like [18:27:24 CET] <thebombzen> https://0x0.st/vsA.opus [18:28:35 CET] <ZeroWalker> ah [18:29:39 CET] <bmduser> thebombzen thanks so much for pointing me in the right direction i was stuck for so many days [18:29:58 CET] <thebombzen> when it doubt update your software [18:31:30 CET] <obamoose> thebombzen: please point me in the right direction [18:32:09 CET] <bmduser> i am streaming rtmp and it seems to be using alot of cpu at 40-60% [18:32:40 CET] <TAFB> bmduser: can you stream without re-encoding? that's what I do, 3% cpu usage :) [18:32:56 CET] <bmduser> is that normal for a 1080p rtmp stream with an i7 processor [18:33:39 CET] <thebombzen> obamoose: no [18:33:58 CET] <thebombzen> bmduser: the actual streaming? no [18:34:01 CET] <thebombzen> but are you transcoding [18:34:20 CET] <thebombzen> because if you're streaming and transcoding at the same time that's expected becuse video conversion is expensive [18:34:31 CET] <bmduser> i am taking a blackmagic input with this [18:34:42 CET] <thebombzen> if you're taking raw yuyv422 input [18:34:49 CET] <bmduser> -f decklink -i "DeckLink Studio 2@6" -threads 16 -vcodec libx264 -maxrate 3000k -strict -2 -b:v 3M -pix_fmt yuv420p -preset veryfast -acodec aac -b:a 128k -bsf:v h264_mp4toannexb -f flv rtmp://rtmpaddress [18:34:50 CET] <thebombzen> then you have to transcode [18:35:00 CET] <thebombzen> yes 40-60% is unsurprising [18:35:09 CET] <thebombzen> also don't use -strict -2 [18:35:18 CET] <thebombzen> you don't need it anymore for the audio encoder [18:35:52 CET] <damnruskie> hey im getting an error while building the arch openpht-ffmpeg package, it seems the package is out of date - anyone happen to know of an upcoming update? [18:36:53 CET] <thebombzen> you should be using htis instead: -pix_fmt yuv420p -c:v libx264 -maxrate:v 30M -minrate:v 3M -b:v 3M -preset:v veryfast -c:a aac -b:a 128k -f flv rtmp://theaddr [18:37:50 CET] <marcurling> Which option (-something) should precede a pan=[parameters] please [18:38:32 CET] <thebombzen> damnruskie: have you considered openpht-git [18:38:45 CET] <bmduser> seem to be getting input buffer overrun [18:39:00 CET] <damnruskie> didnt realize it was an option, thanks thebombzen [18:39:06 CET] <thebombzen> damnruskie: you can also just build from source [18:39:11 CET] <thebombzen> cause tha'ts literally what the AUR is [18:39:16 CET] <thebombzen> it's a glorified build-from-source method [18:39:24 CET] <damnruskie> ah ok awesome ill do that then [18:39:29 CET] <damnruskie> thanks for the tips [18:39:30 CET] <thebombzen> damnruskie: try installing pacaur from the AUR [18:39:36 CET] <thebombzen> it's very convenient [18:40:07 CET] <thebombzen> it allows you to run pacaur -Ss or pacaur -Si or pacaur -Su and also work with the aur [18:40:14 CET] <thebombzen> then you don't have to do that worrying [18:42:40 CET] <damnruskie> gotcha, ive been installing manuall previously, this seems way nicer - thanks again [21:29:57 CET] <thebombzen> hey I have a question - suppose I'm recording highmotion content [21:30:10 CET] <thebombzen> can I improve compression ratio by keeping the native res [21:30:52 CET] <DHE> bigger images require bigger files. there's not much you can do about that if you want to maintain image quality [21:30:59 CET] <DHE> can you be more specific about what you're trying to accomplish [21:31:12 CET] <thebombzen> not native res, typo [21:31:15 CET] <thebombzen> native framerate [21:31:29 CET] <thebombzen> I'm recording 144 fps content - does the ratio improve if I record it to 60 fps or should I keep it at 144 [21:31:48 CET] <thebombzen> the issue is it's highmotion content and if I do 144 fps the predictors are significantly more accurate [21:32:07 CET] <thebombzen> but I don't know if that's worth it when I have more than 2x the data [21:32:17 CET] <DHE> yes, but it's usually a matter of pixels per second. cut the framerate in half and you can usually maintain ABOUT the same image quality for half the bitrate [21:32:21 CET] <ChocolateArmpits> 2x only if uncompressed [21:32:32 CET] <thebombzen> ChocolateArmpits: it is [21:32:35 CET] <thebombzen> I'm recording it [21:32:47 CET] <ChocolateArmpits> so you intend to storing it uncompressed too ? [21:33:00 CET] <thebombzen> so what I'm saying is that I'm generating 144 fps content [21:33:07 CET] <thebombzen> I'm not sure whether to record at 144 or record at 60 [21:33:11 CET] <thebombzen> for better compression ratio [21:33:15 CET] <thebombzen> for example, 10bit encoding is worth the extra data over 8bit because it makes the predictors more accurate [21:33:29 CET] <thebombzen> given that it's highmotion content, 144 fps will have much more accurate prediction [21:33:37 CET] <thebombzen> but idk if it's worth it to more that double the pixels per second [21:33:57 CET] <DHE> you can crank the encoder settings (eg: x264 veryslow) to make the motion estimation search harder for the lower framerate. dunno if that's a win for quality [21:35:36 CET] <thebombzen> well if I'm recording in realtime that defeats the point [21:35:49 CET] <thebombzen> I think the best option here is probably "just try it with crf 18 and see what makes a lower filesize" [21:35:56 CET] <TAFB> i love veryslow with crf0 :) [21:35:56 CET] <DHE> well if you're recording uncompressed there are no motion vectors. [21:36:07 CET] <DHE> (being pedantic with "uncompressed" vs "lossless") [21:36:14 CET] <thebombzen> DHE: what's the difference? [21:36:24 CET] <thebombzen> x264 sees the same thing, right? [21:36:36 CET] <thebombzen> what's the difference between recording uncompressed and recording lossless? [21:36:37 CET] <DHE> uncompressed has constant size files, usually width * height * pixels_per_frame [21:37:00 CET] <thebombzen> but if I record to lossless/uncompressed and then later test the bitrates with x264, is it any different? [21:37:22 CET] <DHE> no. but you said you're recording in realtime so decisions are to be made [21:37:33 CET] <thebombzen> well I can always record to lossless and then transcode [21:37:41 CET] <ChocolateArmpits> lossless compression when uncompressed produces the exact input, so it essentially doesn't lose quality but maintains a lower file size [21:37:42 CET] <thebombzen> assuming I'm just doing a short test [21:37:50 CET] <thebombzen> ChocolateArmpits: I know that [21:38:00 CET] <thebombzen> but DHE here is being pedantic about motion vectors [21:38:00 CET] <ChocolateArmpits> then why are you asking this [21:38:11 CET] <thebombzen> [20:35:56] <DHE> well if you're recording uncompressed there are no motion vectors. [21:38:12 CET] <thebombzen> [20:36:06] <DHE> (being pedantic with "uncompressed" vs "lossless") [21:38:22 CET] <thebombzen> because I was wondering why this ^ is relevant [21:38:38 CET] <thebombzen> ChocolateArmpits: I happen to frequent this channel regularly so please don't baby me [21:39:25 CET] <DHE> because I'm still confused about what it is you're doing. "generating" 144 fps content. does that mean live from a camera, or software generated and doesn't care about how fast the receiver is... [21:39:33 CET] <thebombzen> record from screen [21:39:41 CET] <DHE> okay, so properly realtime [21:39:44 CET] <thebombzen> yes [21:40:08 CET] <thebombzen> in order to test it I could record it in lossless for like 30 seconds [21:40:14 CET] <thebombzen> and then transcode with x264 [21:40:20 CET] <thebombzen> which is what I'm going to do [21:40:39 CET] <thebombzen> the issue is 144 is not an integer multiple of 60 [21:40:56 CET] <thebombzen> so I'm probably going to reset my monitor to 120 to make it so judder doesn't affect the output [21:42:06 CET] <TAFB> do you have a second computer that could do the encoding and streaming? would probably work a lot better than doing it on the gaming computer. You could also buy an external hardware encoder. [21:47:57 CET] <thebombzen> TAFB: why does that matter [21:48:02 CET] <thebombzen> I'm not streaming it [21:48:07 CET] <thebombzen> I'm just recording it locally [21:48:11 CET] <TAFB> oh, sorry, thought you were live streaming [21:48:19 CET] <thebombzen> ah no I'm nowhere near charismatic enough :) [21:48:31 CET] <thebombzen> I record it locally with lossless nvenc using OBS's replay buffer feature [21:48:45 CET] <thebombzen> then if I do a really cool play I have a hotkey to dump the buffer to a file [21:48:51 CET] <thebombzen> I then transcode it so it's not like 300 Mbps [21:48:52 CET] <TAFB> nice. I've gotta try OBS soon, ffmpeg is way too unreliable [21:52:00 CET] <thebombzen> the issue is the transcoding from 120 to 60 [21:52:06 CET] <thebombzen> is it worth it to stay at 120? [21:52:24 CET] <thebombzen> if not, I'll just use nvenc to encode at 60 b/c the dumps won't be as large [21:52:45 CET] <furq> 20:48:19 ( thebombzen) ah no I'm nowhere near charismatic enough :) [21:52:51 CET] <furq> sounds like you're well qualified for live streaming then [21:53:12 CET] <thebombzen> well I'm only qualified in that I'm very skilled a recognizing my limitations [21:53:16 CET] <thebombzen> far more that most actual livestreamers [21:53:24 CET] <furq> as long as you don't have a voice that ordinary humans would find acceptable [21:53:30 CET] <furq> that's the death sentence for streamers [21:56:18 CET] <thebombzen> haha [21:56:24 CET] <thebombzen> okay so the results of the test are in [21:56:36 CET] <thebombzen> I took the same 120 fps recording (lossless) and did two transcodes [21:56:49 CET] <thebombzen> first, straight -c libx264 -preset slow -crf 18 [21:57:06 CET] <thebombzen> and the next one was -vf framestep=2 -c libx264 -preset slow -crf 18 [21:57:41 CET] <furq> well i know which one took half as long [21:57:42 CET] <thebombzen> 60 fps was smaller but only slightly - 21.1 Mbps for 60 fps and 23.5 Mbps for 120 fps [21:58:21 CET] <furq> you can probably get that even closer by doubling the 120fps gop size [21:58:30 CET] <thebombzen> 250 rather than 500? [21:58:33 CET] <furq> although 250 is probably too small in either case [21:58:33 CET] <thebombzen> err [21:58:41 CET] <thebombzen> so 500 vs 1000? [21:58:46 CET] <thebombzen> or like 400 vs 800 [21:58:47 CET] <furq> i was thinking 300 vs 600 [21:58:50 CET] <thebombzen> ah okay [21:59:04 CET] <thebombzen> I wonder if extra bframes would close the gap or widen it [21:59:07 CET] <furq> 600 vs 1200 is 10-second gops, which is what you'd normally get [21:59:13 CET] <furq> i would expect veryslow would narrow the gap as well [21:59:22 CET] <thebombzen> yea extra bframes helps 120 fps [21:59:35 CET] <thebombzen> 10-second gops is normal? [21:59:43 CET] <furq> 250 is 10-second gops for pal [21:59:50 CET] <thebombzen> 250 is the normal keyint, which is 25 fps yea [22:00:07 CET] <thebombzen> does -g takes frames or seconds as the units? [22:00:10 CET] <furq> frames [22:00:16 CET] <thebombzen> okay [22:00:31 CET] <thebombzen> so I'll try again but with 400 and 800 as a good intermediary between 600 and 1200 [22:00:34 CET] <thebombzen> and 250/500 [22:01:50 CET] <furq> not sure what that'll do with an fps demo [22:02:00 CET] <furq> guess it depends how twitchy you are [22:02:42 CET] <thebombzen> very [22:03:44 CET] <thebombzen> I would also try veryslow but it's very slow [22:03:58 CET] <thebombzen> I think -preset slow is a good compromise [22:06:38 CET] <thebombzen> weirdly enough, I wouldn't think the keyint would do all that much for highmotion content [22:06:43 CET] <thebombzen> cause it's mostly the microscopic changes [22:08:25 CET] <thebombzen> huh, so results part 2 are in [22:08:43 CET] <thebombzen> increasing the keyint to 400 reduced 60 fps from 21 Mbps to 19 Mbps [22:08:51 CET] <thebombzen> but 120 fps stayed at 23 Mbps with 800 keyint [22:09:02 CET] <thebombzen> it appears to not have changed much [22:10:18 CET] <furq> fun [22:10:33 CET] <ChocolateArmpits> so long term compression benefitted more from a higher gop length, than the short term compression [22:12:01 CET] <thebombzen> which wasn't really surprising tbh [22:12:21 CET] <thebombzen> 120 fps has its main advantage from smaller per-frame differences [22:12:42 CET] <thebombzen> either way, I think I'm gonna stick with 120 fps because I think the extra few Mbps are (19 vs 23) are worth it [22:12:52 CET] <thebombzen> for double the framerate [22:13:48 CET] <furq> i think you were lying about you/overwatch being twitchy if that's crf 18 at 1080p120 [22:14:53 CET] <BtbN> it's also a matter of the gop length [22:15:23 CET] <BtbN> it's set as an mount of frames, so if you increase the framerate, an I frame happens more frequently [22:15:40 CET] <thebombzen> well yea that's why I used twice the gop length for 120 [22:15:46 CET] <furq> i feel like you maybe missed part of this conversation [22:16:05 CET] <BtbN> it fills like 5 screens of scrolling up, not going to read all of that. [22:16:09 CET] <thebombzen> I used -g 400 for 60 and -g 800 for 120 [22:16:22 CET] <thebombzen> I took into account twice the framerate so I have the same number of seconds between Iframes [22:16:37 CET] <furq> increasing the gop length reduced the bitrate at 60fps but didn't at 120fps [22:16:48 CET] <furq> which i found surprising if nobody else did [22:16:54 CET] <thebombzen> it didn't to me [22:16:57 CET] <thebombzen> remember I'm very twitchy [22:16:59 CET] <thebombzen> it's an fps game [22:17:06 CET] <thebombzen> Overwatch is really twitchy [22:17:19 CET] <furq> i don't see why that makes it unsurprising [22:17:47 CET] <furq> unless you're so twitchy that your twitches only last 8ms [22:19:53 CET] <thebombzen> http://0x0.st/vPK.jpg http://0x0.st/vPP.jpg [22:19:59 CET] <thebombzen> this is the difference between consecutive frames at 60 fps [22:20:18 CET] <thebombzen> wait lemme vstack that [22:20:42 CET] <furq> is that the much-reviled "tracer" i've heard so much about [22:21:00 CET] <thebombzen> http://0x0.st/vPZ.jpg [22:21:11 CET] <thebombzen> by "much-reviled" you mean "muchloved" then yes [22:21:17 CET] <furq> i do not mean that [22:21:34 CET] <thebombzen> so whether or not you hate tracer depends on who you play [22:21:45 CET] <thebombzen> if you play tracer then you like her. if you play roadhog or mccree she's fine [22:21:54 CET] <thebombzen> if you play mercy or zenyatta you hate her guys [22:21:57 CET] <thebombzen> her guts* [22:22:05 CET] <furq> http://www.quake-1.com/docs/any/player.mdl_0.png [22:22:07 CET] <furq> this is who i play as [22:22:22 CET] <thebombzen> tracer also happens to be a good test for this [22:22:25 CET] <durandal_1707> ot [22:22:31 CET] <thebombzen> because her playstyle is very highmotion and twitchy [22:22:46 CET] <thebombzen> if you're playing a reinhardt, the huge shield dude, not as much [23:07:42 CET] <RossW> greetinks sire. [23:07:49 CET] <RossW> oops, wrong window. [00:00:00 CET] --- Sun Mar 26 2017

1 0

ffmpeg-devel.log.20170324
by burek 25 Mar '17

25 Mar '17

[00:00:34 CET] <michaelni> the way the output is printed looks endian sensitive [00:01:38 CET] <ubitux> maybe i should remap back endian specific pix fmt to their native ones? [00:02:19 CET] <michaelni> yeah, these 2 macros need some other way of printing their contents [00:02:51 CET] <ubitux> speaking of these 2 macros [00:03:01 CET] <ubitux> http://b.pkh.me/0001-sws-make-is-RGB-BGR-inInt-functions.patch any objection to this? [00:03:08 CET] <ubitux> (and http://b.pkh.me/0002-sws-tests-pixdesc_query-remove-func-wrappers.patch) [00:05:26 CET] <michaelni> ubitux, sure if its equivalent, nice cleanup [00:06:14 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:0bfdcce4d42a: hevc: move the SliceType enum to hevc.h [00:06:15 CET] <cone-520> ffmpeg 03James Almer 07master:dc39ccdc3b88: Merge commit '0bfdcce4d42a6e654c00ea5f9237dc987626457f' [00:06:16 CET] <ubitux> jamrial: are you doing merges or i can push some stuff? [00:06:22 CET] <ubitux> ah i guess you are [00:06:24 CET] <jamrial> now you can :p [00:06:46 CET] <cone-520> ffmpeg 03Clément BSsch 07master:bc7308aae820: sws: make is{RGB,BGR}inInt functions [00:06:48 CET] <cone-520> ffmpeg 03Clément BSsch 07master:99dd6fe62cb4: sws/tests/pixdesc_query: remove func wrappers [00:06:50 CET] <ubitux> done [00:51:11 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:59c90097a0ef: hevc: factor out a repeated condition [00:51:12 CET] <cone-520> ffmpeg 03James Almer 07master:e9d4b3dc375b: Merge commit '59c90097a0eff0dc81fbec15b8900c929859d1e7' [00:55:47 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:7c9e2b295e4f: Makefile: fix checking whether reconfiguring is required [00:55:48 CET] <cone-520> ffmpeg 03James Almer 07master:9bcc5e8973ea: Merge commit '7c9e2b295e4f70e8fedf9cceb12d95399a859a9c' [00:57:15 CET] <jamrial> i remember people complained about the enum value from 0d9b9bd37f43ee29ad9f709d85c8f3be9db71104 [00:57:23 CET] <jamrial> what should we do? [00:58:17 CET] <nevcairiel> is there any reason why it is 22, its seems super arbitrary [00:58:39 CET] <nevcairiel> other then being its name, i guess [01:00:09 CET] <jamrial> i have no idea :p [01:00:53 CET] <jamrial> matroska uses 22 for it as well [01:01:31 CET] <jamrial> supposedly, the values are taken from table 2 of ISO/IEC 23001-8:2013/DCOR1 [01:25:13 CET] <nevcairiel> is that the same table that feeds the values in the h264/hevc specs usually? [01:25:29 CET] <nevcairiel> although some people had concerns about the gap, i guess [01:30:29 CET] <philipl> BtbN: for what it's worth, the libx264 option is -cqp and not -qp (in the x264 binary, it's -qp). Maybe worth changing for consistency? [01:31:04 CET] <nevcairiel> would be nice to use the same option for the same things [01:31:23 CET] <philipl> right [01:31:23 CET] <JEEB> wouldn't -q:v be the thing for constant quantizer? [01:31:30 CET] <JEEB> like, in libavcodec general [01:33:14 CET] <philipl> I dunno, I don't think libx264 uses that. [01:33:38 CET] <nevcairiel> q is qscale, not sure that really maps to constant qp semantically [01:34:29 CET] <nevcairiel> but it does set global_quality [01:34:38 CET] <nevcairiel> which apparently is being faded out due to its weird lambda hackery [01:35:32 CET] <JEEB> interesting [01:35:48 CET] <JEEB> I always thought -q:v 0 with libx264 in avcodec would set lossless, for example [01:35:56 CET] <JEEB> but if it's not constant quant then welp [01:36:09 CET] <nevcairiel> no q doesnt do a nything with libx264 [01:36:20 CET] <JEEB> cool [01:37:03 CET] <nevcairiel> philipl: i just checked and it appears libx264 uses -qp, not -cqp [01:38:16 CET] <nevcairiel> (the struct member is called cqp, but thats just internal, the avoption is called qp) [01:41:57 CET] <philipl> oh, ok. BtbN did his research. [01:43:13 CET] <nevcairiel> JEEB: the reason global_quality isnt used is apparently that it doesn't map well to anything. constant-qp isnt really a good "constant quality" mode as depending on the scenes the quality can vary quite a bit, and crf often does a better job at constant quality, but since people know crf under the crf name and know the crf numbers, the global_quality with its mpeg2/4 lambda stuff is just annoying [08:48:29 CET] <JEEB> nevcairiel: yes, I did know constant quant is not for real usage (other than forcing lossless on >8bit) [08:48:50 CET] <JEEB> but I didn't know the global quality mess :p [10:55:45 CET] <wm4_> is there any reason there's no FATE android instance that actually runs fate? [10:55:51 CET] <wm4_> they all seem to be "build only" [10:58:13 CET] <wbs> wm4_: you'd need a shared mount (nfs/smb) with the target device, or build on-device for that to be feasible. on the other side, I've got a few fate instances that build with the android toolchain built link the libc statically, and run tests on a normal vanilla-linux [11:00:14 CET] <wm4_> I find it strange that nobody did that [11:26:12 CET] <cone-060> ffmpeg 03Vittorio Giovara 07master:0d9b9bd37f43: lavu: Add JEDEC P22 color primaries [11:26:12 CET] <cone-060> ffmpeg 03Clément BSsch 07master:a44ab512e6b9: lavu/pixfmt: fix redundant comment [11:26:12 CET] <cone-060> ffmpeg 03Clément BSsch 07master:0b3decc5964b: Merge commit '0d9b9bd37f43ee29ad9f709d85c8f3be9db71104' [11:34:00 CET] <cone-060> ffmpeg 03Vittorio Giovara 07master:4b07ebf1eb13: mov: Update colr values [11:34:01 CET] <cone-060> ffmpeg 03Clément BSsch 07master:30ac66abf099: Merge commit '4b07ebf1eb13561492f7e3c30a67f34415016b3e' [11:41:59 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:043b0b9fb148: Replace leftover uses of -aframes|-dframes|-vframes with -frames:a|d|v [11:42:00 CET] <cone-060> ffmpeg 03Clément BSsch 07master:71d541751ef1: Merge commit '043b0b9fb1481053b712d06d2c5b772f1845b72b' [11:46:36 CET] <cone-060> ffmpeg 03Clément BSsch 07master:40ac22601408: lavc/x86/hevc: rename hevc_res_add to hevc_add_res [11:59:42 CET] <ubitux> dammit these !@#$ cosmetics [11:59:49 CET] <ubitux> renaming everything and shuffling all the spaces [12:00:09 CET] <ubitux> adding random _ and shuffling words just to make them different [12:02:15 CET] <wm4_> heh [12:09:21 CET] <ubitux> so apparently they prefer a reg loop instead of %rep [12:09:25 CET] <ubitux> what should i keep? [12:10:48 CET] <ubitux> add res mmx looks pretty different too [12:12:06 CET] <atomnuker> I prefer %rep [12:12:44 CET] <ubitux> ok [12:13:06 CET] <ubitux> opinion on the differences between TR_ADD_MMX_4_8 and ADD_RES_MMX_4_8? [12:13:18 CET] <ubitux> (ffmpeg / libav) [12:13:58 CET] <kierank> atomnuker: you prefer at&t syntax? [12:13:59 CET] <kierank> wow [12:14:34 CET] <ubitux> %rep is refering to the pp [12:14:45 CET] <ubitux> it's not "%reg" [12:14:52 CET] <ubitux> it's a way of unrolling [12:17:29 CET] <atomnuker> granted it does increase code when you know how much to loop for but it spares a register [12:25:17 CET] <kierank> oh %rep [12:25:22 CET] Action: kierank read %rsp [12:31:56 CET] <furqan> my ffmpeg hangs while executing this command [12:32:13 CET] <furqan> http://pastebin.com/FJTvci6j [12:34:24 CET] <cone-060> ffmpeg 03Pierre Edouard Lepere 07master:6d5636ad9ab6: hevc: x86: Add add_residual() SIMD optimizations [12:34:26 CET] <cone-060> ffmpeg 03Clément BSsch 07master:3d6535983282: Merge commit '6d5636ad9ab6bd9bedf902051d88b7044385f88b' [12:40:23 CET] <cone-060> ffmpeg 03Alexandra Hájková 07master:ed48a9d8143d: checkasm: Add a test for HEVC add_residual [12:40:25 CET] <cone-060> ffmpeg 03Clément BSsch 07master:3d4039f964e4: Merge commit 'ed48a9d8143d2575a4458589cebde69ec326afd8' [12:41:41 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:2f806622e127: bktr: Use memset(0) instead of zero initialization for struct sigaction [12:41:42 CET] <cone-060> ffmpeg 03Clément BSsch 07master:761bbb06ff59: Merge commit '2f806622e1270d3ed1d41a53049a19673dafbe70' [12:51:41 CET] <cone-060> ffmpeg 03Martin Storsjö 07master:016387fe0fe3: rtmpdh: Don't use the OpenSSL DH struct [12:51:42 CET] <cone-060> ffmpeg 03Clément BSsch 07master:2c47d243585a: Merge commit '016387fe0fe3eff1a03ec0673bf4d2967f6cad94' [13:00:23 CET] <cone-060> ffmpeg 03Matt Oliver 07master:ee050797664c: openssl: Support version 1.1.0. [13:00:24 CET] <cone-060> ffmpeg 03Clément BSsch 07master:fc83de7e1d0e: Merge commit 'ee050797664c7c74cae262ffab05006b55d47a11' [13:02:10 CET] <cone-060> ffmpeg 03Gwenole Beauchesne 07master:754b20d7ebcc: vaapi_h264: fix RefPicList[] field flags. [13:02:11 CET] <cone-060> ffmpeg 03Clément BSsch 07master:b0625388411a: Merge commit '754b20d7ebccbe8d316b12128c8cb433d5a516ac' [13:05:10 CET] <cone-060> ffmpeg 03Mark Thompson 07master:5e879b54a3a4: vaapi_decode: Clear parameter buffers to fix picture reuse [13:05:11 CET] <cone-060> ffmpeg 03Mark Thompson 07master:0aec37e62582: vaapi_decode: Remove vestigial unmap code [13:05:12 CET] <cone-060> ffmpeg 03Clément BSsch 07master:9da2b376683b: Merge commit '0aec37e625821040c103641eec9c1e7a1efa2952' [13:06:47 CET] <cone-060> ffmpeg 03Yogender Gupta 07master:99aeae20de4d: scale_npp: fix passthrough mode [13:06:48 CET] <cone-060> ffmpeg 03Clément BSsch 07master:99c9e00c685d: Merge commit '99aeae20de4d09ea313fdc619d4e2df825155e62' [13:09:59 CET] <cone-060> ffmpeg 03Luca Barbato 07master:052b97855de2: aviocat: Support avio options [13:10:01 CET] <cone-060> ffmpeg 03Clément BSsch 07master:d1ab8c66cf47: Merge commit '052b97855de2396e46682bcbae97f95a258816d4' [13:10:39 CET] <cone-060> ffmpeg 03Martin Storsjö 07master:f22363c72968: openssl: Avoid double semicolons after the GET_BIO_DATA macro [13:10:43 CET] <cone-060> ffmpeg 03Clément BSsch 07master:65cb02301acc: Merge commit 'f22363c72968f1a1fc4881d8695ec7068b0aa03c' [13:12:55 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:14cab426b03a: build: Hardcode avversion.h dependency [13:12:56 CET] <cone-060> ffmpeg 03Clément BSsch 07master:3a3791a5826e: Merge commit '14cab426b03afd08bc9fe9b6e021a9543c4bdd7e' [13:14:31 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:255526998501: mpegaudio: Do not print value of uninitialized variable [13:14:33 CET] <cone-060> ffmpeg 03Clément BSsch 07master:fe7cae38801f: Merge commit '255526998501f0040ae43fe4848c817a97fc578a' [13:16:40 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:0574780d7a19: h264_loopfilter: Do not print value of uninitialized variable [13:16:41 CET] <cone-060> ffmpeg 03Clément BSsch 07master:4c840c249dff: Merge commit '0574780d7a196f87ddd89d6362f4c47f3532b4c4' [13:18:14 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:0456e684394d: audio_fifo: Drop write-only variable [13:18:15 CET] <cone-060> ffmpeg 03Clément BSsch 07master:2a69724fd5e0: Merge commit '0456e684394dc5a7b98ab9ebb48396d743bf3730' [13:18:54 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:47756f51fe83: dnxhdenc: Drop pointless, commented-out debug output [13:18:55 CET] <cone-060> ffmpeg 03Clément BSsch 07master:e809c2e40d7a: Merge commit '47756f51fe836959ffa5c6e2baeacbd71e150069' [13:19:39 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:c3dad1bf3b5e: nsv: Drop unnecessary TRACE level debug code [13:19:41 CET] <cone-060> ffmpeg 03Clément BSsch 07master:50a06c841f05: Merge commit 'c3dad1bf3b5e04e01c291b1ac41e6bef0adf2206' [13:21:48 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:07eea5a5ded1: nut: Drop pointless TRACE level debug code [13:21:49 CET] <cone-060> ffmpeg 03Clément BSsch 07master:bb9fdd9f616f: Merge commit '07eea5a5ded1141632aefecfa59dcdc26de2d7ea' [13:24:55 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:ca1e5eea0c7b: Remove some pointless TRACE level debug code [13:24:56 CET] <cone-060> ffmpeg 03Clément BSsch 07master:1436769c57cc: Merge commit 'ca1e5eea0c7b72a6e30aa6488cfeced3a4853521' [13:37:13 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:1263b2039eb5: Adjust printf conversion specifiers to match variable signedness [13:37:14 CET] <cone-060> ffmpeg 03Clément BSsch 07master:46f4f8ad865d: Merge commit '1263b2039eb5aaf1522e9de9f07c787ab30a5f50' [13:38:34 CET] <cone-060> ffmpeg 03Diego Biurrun 07master:fbe425c8d29e: hap: Adjust printf length modifiers to match variable types [13:38:35 CET] <cone-060> ffmpeg 03Clément BSsch 07master:63ad47d76b8f: Merge commit 'fbe425c8d29e473a8f69ae2dc52b1a10b77f3b44' [13:39:17 CET] <ubitux> dammit that next commit [13:40:35 CET] <nevcairiel> just merge those parts that apply at least somewhat similarly, leave other occurances to be fixed by someone else? [13:43:26 CET] <ubitux> yeah sure but... technically i should check if we didn't change signdness [13:43:33 CET] <ubitux> also, some of these a braindead [13:44:05 CET] <ubitux> most of them actually are [13:44:50 CET] <ubitux> replacing the %x with PRIx8, like, really? :/ [13:45:32 CET] <JEEB> lol [13:45:38 CET] <ubitux> yeah i don't want to merge that one, at least no now [13:45:42 CET] <ubitux> i need to take a break [13:45:46 CET] <JEEB> gg [13:45:52 CET] <JEEB> you've done quite a bunch [13:45:56 CET] <nevcairiel> i have no clue which of those are really properly portable [13:46:25 CET] <ubitux> (ETA: 725) [13:46:32 CET] <ubitux> still a long way to go [13:46:55 CET] <ubitux> we're at end end of oct 2016 [13:47:30 CET] Action: ubitux & [13:48:53 CET] <atomnuker> ubitux: throughout all the code? [13:48:57 CET] <atomnuker> why would they do that? [13:49:28 CET] <nevcairiel> presumably because %x isnt standardized? [13:49:31 CET] <atomnuker> what's the advantage? PRIx8 does masking for you? [13:49:48 CET] <wm4> what's the commit? [13:50:16 CET] <nevcairiel> https://git.libav.org/?p=libav.git;a=commitdiff;h=c454dfcff90f0ed39c7b0d4e8… [13:51:12 CET] <atomnuker> even for integers? [13:51:15 CET] <atomnuker> this is retarded [13:52:02 CET] <atomnuker> well at least its only for hex [13:53:15 CET] <wm4> I mean the change is correct [13:53:24 CET] <wm4> you can't pass int32_t for %d etc. [13:53:48 CET] <wm4> personally I'd rather cast it like int32_t v; printf("%d", (int)v); [13:53:51 CET] <wm4> looks less ugly [13:56:08 CET] <wm4> if you want the ffmpeg equivalent of such correct but pointless changes, it's those fuzz fixes [13:56:28 CET] <wm4> and other static analyzer stuff [13:57:48 CET] <ubitux> i'd rather do that instead [13:58:07 CET] <ubitux> any idea of the tool used? clang static analyzer? [14:04:05 CET] <wm4> no, I can ask [14:07:14 CET] <ubitux> oh god [14:07:21 CET] <wm4> well.... [14:17:24 CET] <ubitux> TimothyGu: what's going on wrt "fate2"? [15:30:14 CET] <cone-060> ffmpeg 03James Almer 07master:ac42f080991c: x86/hevc_add_res: merge missing changes from 3d6535983282bea542dac2e568ae50da5796be34 [15:44:51 CET] <durandal_1707> fine to push dnxhd parser fix? [15:47:17 CET] <BBB> finally openssl is fixing its license: https://www.openssl.org/blog/blog/2017/03/20/license/ [15:47:50 CET] <JEEB> yea [15:48:41 CET] <BBB> ubitux: thanks for doing the merges [15:53:23 CET] <durandal_1707> ubitux, jamrial still merging something? [15:53:39 CET] <ubitux> i'm not doing any merge currently [15:53:50 CET] <jamrial> durandal_1707: not right now, so you can push [15:54:01 CET] <ubitux> BBB: i'm not alone, but we did around 300/1000 in about a week i'd say [15:54:21 CET] <ubitux> we'll need one month at this pace to keep up [15:54:35 CET] <ubitux> (but i'll stop at the end of the week) [15:54:40 CET] <BBB> j-b: so hows your project to fix this going? [15:54:58 CET] <durandal_1707> what fixing? [15:55:22 CET] <BBB> merge libav and ffmpeg back together" [15:55:31 CET] <j-b> BBB: hahaha [15:55:38 CET] <j-b> BBB: people are not interested. [15:55:41 CET] <BBB> :( [15:55:42 CET] <BBB> I am [15:55:42 CET] <j-b> so, plonk [15:55:49 CET] <j-b> and I'm fed up of being insulted. [15:56:19 CET] <j-b> I should just do a startup and make money, like bitmovin or elemental [15:56:24 CET] <j-b> instead of caring about floss [15:56:53 CET] <BBB> the market for bitmovin companies is already saturated [15:57:03 CET] <BBB> theres literally 13-in-a-dozen versions of that company everywhere [15:57:11 CET] <j-b> I'll buy and sell buildings then [15:57:16 CET] <BBB> thats a good idea [15:57:19 CET] <BBB> you can be president after that [15:57:30 CET] <j-b> yeah [15:57:34 CET] <j-b> JB Trump JR [15:57:35 CET] <BBB> as for elemental, didnt people say it typically wasnt such a great encoder? [15:57:57 CET] <BBB> or you mean the amazon integration api? [15:58:56 CET] <ubitux> jamrial: are you looking at the ADD_RES_MMX_4_8 thinh? [15:58:59 CET] <ubitux> thing* [15:59:33 CET] <cone-060> ffmpeg 03Paul B Mahol 07master:e1940d245835: avcodec/dnxhd_parser: take into account compressed frame size and skip it [16:03:23 CET] <durandal_1707> ubitux: regarding dnxd parser commit i picked shorter variant [16:03:37 CET] <ubitux> okay [16:03:44 CET] <jamrial> ubitux: it's functionally the same, but instead of doing stuff on four half filled registers it combines the data and does it on two full registers [16:04:11 CET] <ubitux> any idea why? i doubt that's a change from Diego himself, he may have take it from a more recent code in x264 or something [16:07:11 CET] <jamrial> ubitux: it was probably alexandra [16:07:29 CET] <jamrial> but i can't say [16:08:02 CET] <jamrial> i remember the loop change was hers as recommended by Gramner [16:08:54 CET] <jamrial> that commit's authorship and comments are kinda wrong/incomplete to be honest [16:40:44 CET] <BBB> does anyone have experience with reporting bugs to clang? [16:41:03 CET] <BBB> I tried using the apple bug reporter tool but it seems nobody is looking at those bugs, I have no comments for 2 weeks [16:46:20 CET] <iive> BBB: clang is not apple product , afaik [16:58:55 CET] <wm4> iive: it sort of is [16:59:43 CET] <wm4> I don't remember the history, but I guess they were probably the driving force to make it a realistic gcc replacement... [16:59:52 CET] <iive> i've heard that they've bought cups [17:01:35 CET] <wm4> according to wikipedia apple wrote clang and then open sourced it [17:03:25 CET] <iive> mybad [17:04:54 CET] <iive> hum, wiki doesn't say that. [17:08:03 CET] <iive> found it. [17:19:29 CET] <kierank> BBB: doesn't matter that it was a crap encoder, they had aggressive sales guys [17:31:35 CET] <JEEB> kierank: aggressive sales team and nice "educational" events do sell indeed [17:31:48 CET] <kierank> White Papers and being old also sells [17:31:49 CET] <JEEB> just looking at stuff like the fighter plane competitions in various countries [17:32:12 CET] <JEEB> it just gets even more big-scale when people put billions on the line [17:32:29 CET] <JEEB> but yes, White Papers [17:32:37 CET] <JEEB> also a Very Important Ingredient [17:33:13 CET] <cone-060> ffmpeg 03Thomas Turner 07master:824fe914fee7: avcodec/tests: added test for celp_math.c [17:39:25 CET] <ubitux> michaelni: that dubious IsAlmostEqual macro is creating an empty statement [17:39:44 CET] <ubitux> (its existence as macro also makes no sense btw) [17:46:47 CET] <michaelni> ubitux, will fix [17:47:34 CET] <michaelni> just need to double check its still passing on all platforms i can easily test [17:50:13 CET] <durandal_1707> new release when? [17:55:16 CET] <michaelni> preferably a month ago ... [17:55:39 CET] <jamrial> i don't think there's any blocker right now [17:55:53 CET] <jamrial> the side data size printing thing was fixed [17:56:14 CET] <michaelni> i think ffplay is broken unless that was fixed today [17:56:49 CET] <michaelni> i needed to revert one commit locally when i want to test with ffplay ... [17:57:15 CET] <jamrial> which one? i thought marton was only working on porting it to the new decode api [17:57:42 CET] <jamrial> is he aware of it? [17:58:20 CET] <durandal_1707> we should remove ffplay and use external mpv [17:59:15 CET] <michaelni> i dont think the issue is in ffplay [18:00:26 CET] <nevcairiel> for the frame threading thing wm4 posted a patch on the ML, feel free to review to get it along [18:03:56 CET] <wm4> I think a new release should wait a while [18:08:20 CET] <jamrial> ubitux or whoever wants to check, i fixed most of the fate failures introduced by merging 8e2ea69135 and pushed to https://github.com/jamrial/FFmpeg/commits/mergework [18:08:48 CET] <jamrial> the remaining failing test are reporting different extradata size and contents [18:09:04 CET] <jamrial> probably because of differences in the old code based on the return value of AVParser.split() and the new code creating custom extradata rather than just taking part of the packet raw [18:18:58 CET] <jamrial> decoding of those h264 samples seems unaffected with the changed extradata [18:19:34 CET] <durandal_1707> wm4: more than 3 months passed since last release [18:19:36 CET] <cone-060> ffmpeg 03Michael Niedermayer 07master:d92ad42fb38a: avcodec/tests/celp_math: Change IsAlmostEqual() to a function [18:22:58 CET] <BBB> kierank: I guess we should all learn from them then [18:23:33 CET] <BBB> kierank: lets dump our code, forget everything we know, and take an MBA from some expensive suitniversity? [18:23:55 CET] <kierank> to some extent that is broadcast industry [18:24:18 CET] <wm4> what code was dumped? [18:24:20 CET] <kierank> they basically go round saying to broadcasters that you must must must have an OTT encoder [18:24:30 CET] <kierank> because neflix netflix netflix [18:24:37 CET] <kierank> and milennials don't want tv [18:24:45 CET] <kierank> when in fact webcasting has tiny audiences [18:24:52 CET] <wm4> wtf is OTT [18:24:59 CET] <kierank> over the top [18:25:11 CET] <kierank> hls/dash/etc [18:25:15 CET] <kierank> all http delivered crap basically [18:25:26 CET] <kierank> i.e no telco/cableco or broadcaster [18:25:36 CET] <wm4> you're saying there's another adaptive http streaming proto? [18:25:44 CET] <kierank> smooth streaming [18:26:00 CET] <wm4> oh I see [18:31:01 CET] <ubitux> michaelni: what is the multiplication by largest for? [18:31:40 CET] <michaelni> so the scale for epsilon is correct [18:32:43 CET] <jfmcarreira> heyy guys [18:33:26 CET] <jfmcarreira> where i can find examples of the new API avcodec_receive_frame?? of where it is used on the code so i can have an ideia how to use it :) [18:58:15 CET] <JEEB> jfmcarreira: there's a patch for it in ffplay on the mailing list, not sure if ffmpeg.c uses it. vlc and mpv also use it [19:00:50 CET] <jfmcarreira> JEEB: i guess i found the problem.. i guess it is the same behaviour of avcodec_decode_video2 [19:02:21 CET] <wm4> durandal_1707: what does audio threading do differently from video? (see michaelni's reply on the pthread changes) [19:11:24 CET] <michaelni> jamrial, extradata could also contain global data that isnt essential for decoding, information about bitsteram restrictions, colorspace details, all kinds of other stuff [19:20:45 CET] <jamrial> supposedly, this bsf should extract the same information out of the packet as AVParser.split() reports back (for h264, that is sps/vps/pps it seems) [19:20:47 CET] <jamrial> but in one of the h264 tests, the extradata post patch is 50 bytes instead of 795 bytes [19:21:25 CET] <jamrial> that said, extract_extradata_h2645 uses ff_h2645_packet_split() whereas h264_split does some manual bitstream parsing [19:40:29 CET] <uau> wm4: there's nothing obvious about the patch that could affect anything else other than by changing timing (implying a bug elsewhere) or causing a deadlock [19:40:47 CET] <uau> can you actually reproduce that assertion failure? [19:43:26 CET] <wm4> uau: didn't try yet [19:53:59 CET] <cone-060> ffmpeg 03Carl Eugen Hoyos 07master:66c1c9b27749: lavc/xface: Reorder conditions to silence a gcc warning. [19:55:34 CET] <Compn> michaelni / durandal_1707 / anyone : someone sent me dvr .tfs file , do you want to take a look / reverse engineer it ? [19:55:50 CET] <JEEB> inb4 encrypted [19:55:55 CET] <Compn> could be [19:56:05 CET] <Compn> i think this is standard camera dvr file though (e.g. cctv) [19:56:09 CET] <Compn> not ... cable dvr [19:56:14 CET] <JEEB> oh [19:56:18 CET] <Compn> like lvf format [19:56:28 CET] <JEEB> goddamnit with these pretty words [19:56:36 CET] <JEEB> for me DVR has always been broadcast [19:56:45 CET] <Compn> yea i dont make the names. :( [19:57:07 CET] <durandal_1707> Compn: is there signature at beggining? [19:57:27 CET] <durandal_1707> see in hex editor [19:57:34 CET] <Compn> 6000 series DVR is designed specially for security and defence field which is an outstanding digital surveillance product. in introduces embedded linux operating system which is more stable. [19:57:44 CET] <cone-060> ffmpeg 03Paul B Mahol 07release/3.2:a60e66516233: avcodec/dnxhd_parser: take into account compressed frame size and skip it [19:58:02 CET] <Compn> it introduces standard h.264mp video compressed format and g711a audio compressed format which insures the high quality image. [19:58:03 CET] <Compn> heh [19:58:14 CET] <Compn> the guy sent me the manual for hte dvr too haha [19:58:35 CET] <Compn> guess i have to de-rar this... [19:59:18 CET] <durandal_1707> Compn: just upload video file [19:59:54 CET] <Compn> he uploaded it to this site i paste you addy [19:59:55 CET] <Compn> :P [20:00:08 CET] <Compn> lookinmg for my hex editor now... [20:01:32 CET] <Compn> durandal_1707 : starts with "TSF4" [20:02:53 CET] <farfel> are there plans to support newer Red Cinema R3D files ? I realize this is probably a lot of work [20:03:15 CET] <JEEB> farfel: if someone provides samples and a decoder to RE if there is no specification [20:03:26 CET] <JEEB> and after that someone needs to get deep [20:03:27 CET] <Compn> we have samples [20:03:39 CET] <JEEB> and in that case if someone can sponsor the work, there are more chances of results [20:03:46 CET] <farfel> http://www.red.com/sample-r3d-files has sample files _ 8K ! [20:03:55 CET] <Compn> ehe [20:03:57 CET] <JEEB> since R3D stuff is used in professional context [20:04:12 CET] <Compn> we get a few people who say that ffmpeg cant handle the complex colorspaces :D [20:04:20 CET] <JEEB> sure [20:04:26 CET] <farfel> :) [20:04:28 CET] <JEEB> that's usually related to colorspace conversions [20:04:33 CET] <Compn> https://trac.ffmpeg.org/ticket/2690 [20:04:39 CET] <farfel> Bayer 16 bit ? [20:04:40 CET] <JEEB> because swscale is something I can't wait to have derp'd [20:05:04 CET] <JEEB> I wonder if zimg can support it [20:05:14 CET] <durandal_1707> nope [20:05:20 CET] <Compn> farfel : i dont think there is anyone working on it... [20:05:31 CET] <farfel> so, as I understand, R3D is a wrapper around J2K files plus colour space conversion [20:05:32 CET] <Compn> but usually people work in secret and then drop a huge patch anyhow :D [20:05:35 CET] <durandal_1707> unless you pay [20:06:03 CET] <farfel> so, perhaps it would be enough to simply extract the J2K [20:06:08 CET] <farfel> for starters [20:06:18 CET] <JEEB> yea, as I noted R3D is a professional thing so if a company or companies want support, some sort of sponsorship through VideoLAN could a good idea [20:06:18 CET] <durandal_1707> There are more complicated r3d compressions [20:06:39 CET] <JEEB> since VideoLAN already hosts a bounty page [20:06:49 CET] <Compn> farfel : for starters would be using the r3d sdk with ffmpeg ;) [20:06:53 CET] <JEEB> https://wiki.videolan.org/Bounties/ [20:06:53 CET] <durandal_1707> Compn: open bug report with that file [20:06:56 CET] <Compn> then... we work on other things [20:07:09 CET] <Compn> durandal_1707 : ok [20:07:20 CET] <farfel> Compn: would this be fine with LGPL ? [20:07:33 CET] <JEEB> j-b: wait what is there really a bounty for amarecco? :D [20:07:33 CET] <farfel> I guess as long as it is not distributed [20:07:39 CET] <Compn> farfel : of course not distributed [20:07:50 CET] <farfel> gotcha [20:07:51 CET] <Compn> the SDK license probably wont allow distribution either [20:07:55 CET] <farfel> yes [20:07:56 CET] <Compn> farfel : but the wrapper code is OK [20:08:01 CET] <farfel> hmmm [20:08:16 CET] <Compn> well maybe non-free :D [20:08:17 CET] <Compn> ehe [20:09:19 CET] <farfel> is it possible that VideoLAN already supports this? [20:10:03 CET] <Compn> durandal_1707 : uploading now... http://samples.ffmpeg.org/camera-dvr/0000241985.tfs [20:10:17 CET] <farfel> well, anywho, thanks for the back-story on this format [20:10:19 CET] <JEEB> farfel: highly unlikely [20:10:19 CET] <durandal_1707> farfel: why you need this? [20:10:32 CET] <Compn> farfel : no, r3d is pretty proprietary. dont think there is any open source supporting it right now [20:10:42 CET] <Compn> (i could be wrong) [20:11:00 CET] <farfel> durandal: some benchmark for j2k compression used these files, so I wanted to take a look myself [20:11:14 CET] <farfel> at the images [20:11:16 CET] <JEEB> right [20:11:31 CET] <Compn> yeah... great reason for us to spend weeks reverse engineering the format :P [20:11:43 CET] <Compn> months... years [20:12:09 CET] <durandal_1707> hmm, if they are real j2k then it should be not hard to grasp it [20:12:16 CET] <farfel> http://comprimato.com/jpeg2000-is-ready-for-your-8k-video/ [20:12:22 CET] <Compn> farfel : did you know ffmpeg created a codec, ffv1, which some archiving people have started to use instead of j2k ? [20:12:39 CET] <farfel> yeah, I heard about that: looks very cool. lossless [20:12:41 CET] <JEEB> (being standardized at the EU level) [20:12:43 CET] <Compn> and there is now a ffv1 standard... :) [20:12:52 CET] <JEEB> did it finish? [20:12:53 CET] <farfel> I like it : J2K is brutally slow [20:13:05 CET] <farfel> except, it is the standard for cinema [20:13:08 CET] <JEEB> farfel: yea, almost like it was made for hardware manufacturers [20:13:08 CET] <farfel> and not going away [20:13:12 CET] <farfel> :) [20:13:19 CET] <Compn> farfel : interestingly, videolan supports some DCP i think [20:13:21 CET] <Compn> or wants to... [20:13:34 CET] <farfel> yeah, I think you need a 32 core server CPU to get it to play [20:13:36 CET] <JEEB> yes, we had a demo of that a few years back at VDD [20:14:01 CET] <Compn> just some hardware decoder... :) [20:14:08 CET] <farfel> I really wish they did support it in software [20:14:13 CET] <Compn> wonder if there is consumer hardware j2k decoder [20:14:22 CET] <JEEB> pretty sure there isn't [20:14:25 CET] <JEEB> since there's the money in it [20:14:52 CET] <farfel> if you buy a big-ass server box, you can use OpenJPEG [20:14:55 CET] <farfel> to decode [20:14:58 CET] <farfel> so [20:15:12 CET] <Compn> is openjpg faster than ffjpeg decoder? hmm [20:15:28 CET] <farfel> sorry, but yes it is [20:15:39 CET] <JEEB> yea [20:15:49 CET] <JEEB> also the effing weirdly licensed fork of it I think [20:15:58 CET] <farfel> yes [20:16:07 CET] <Compn> no one wrote new asm for old jpeg decoder? :P [20:16:45 CET] <farfel> assembly is the key, but that takes a lot of time [20:16:57 CET] <farfel> just throw a few Ryzen at the problem [20:17:39 CET] <durandal_1707> openjpeg2000 is flawed [20:17:49 CET] <farfel> really? [20:18:10 CET] <farfel> you mean large attack surface? any codec has that problem [20:18:28 CET] <durandal_1707> yes see bugs on bug tracker on github [20:19:02 CET] <farfel> here is an interesting fact: project lead works for a hardware j2k board manufacturer [20:19:38 CET] <farfel> I suppose they don't want high quality software codec taking business away [20:19:46 CET] <Compn> farfel : so can you use r3d sdk to extract jp2k out of .r3d files ? [20:19:59 CET] <farfel> Compn: don't know, will give it a try [20:20:49 CET] <farfel> but won't look good without colour conversion, I guess [20:21:06 CET] <farfel> I will see what I can do in a day or so [20:21:07 CET] <Compn> maybe sdk does it too who knows [20:21:29 CET] <farfel> yes, that is true - I was just hoping for the open solution [20:21:31 CET] <cbsrobot> I thought kakadou can decompress 2k j2k files on moderate hw [20:21:55 CET] <farfel> Yes, someone made a Kakadu patch for FPGA [20:21:59 CET] <farfel> a while ago [20:22:13 CET] <farfel> Kakadu is rather expensive [20:22:14 CET] <farfel> though [20:23:00 CET] <Compn> red cameras still sub $3k ? [20:23:01 CET] <cbsrobot> frauenhofer easydcp uses the kakadu lib and it plays dcp - well maybe at a lower res (not sure) [20:24:53 CET] <farfel> yes, I think they often do replay at 1/4 size, and full res when pause [20:25:08 CET] <cbsrobot> farfel: I'd be happy for any speed improvement on j2k [20:25:27 CET] <cbsrobot> btw are you behind grok ? [20:25:38 CET] <farfel> yep [20:26:11 CET] <cbsrobot> I'd be glad to talk about it but I need to leave now [20:26:19 CET] <cbsrobot> maybe we can talk later ... [20:26:25 CET] <farfel> np, will be back [20:26:27 CET] <farfel> later [20:26:33 CET] <farfel> have to go too - cheers everyone [20:30:58 CET] <Compn> cya [20:41:32 CET] <tlshum> hi, I'm curious if anyone has already expressed interest in implementing DICOM support in GSoC [20:41:43 CET] <tlshum> i'd have hilighted cehoyos but they don't seem to be here [20:45:48 CET] <Compn> dicom was suggested to another student [20:45:51 CET] <Compn> in my irc logs [20:46:18 CET] <Compn> but i dont know what they chose... [20:46:26 CET] <Compn> durandal_1707 might know [20:47:20 CET] <durandal_1707> i dont know, ask carl via email [20:49:36 CET] <tlshum> thank you both. would carl mind if I end up sending what amounts to an unsolicited email directly to him [20:49:49 CET] <tlshum> or is there some sort of procedure that i should follow? [20:50:29 CET] <Chloe> You could email him to ask if you can email him? [20:51:39 CET] <tlshum> i could probably ask him the question via email, along with asking if he's fine with me continuing to email him [20:51:51 CET] <tlshum> since the first email would just be wasting his time [21:04:59 CET] <jamrial> michaelni: pushed a "fix" for the h264 failures [21:05:50 CET] <jamrial> basically, just copied the code from h264_split(), since the parsing code in the bsf was discarding several nals that apparently are needed in extradata [21:16:38 CET] <Compn> tlshum : please feel free to email carl direct [21:17:04 CET] <Compn> carl is a mentor? i think? so he has accepted being a contact for GSOC students... [21:19:39 CET] <tlshum> thanks for the reassurance! I wasn't sure about the etiquette here [21:27:02 CET] <ubitux> how do people manage their fate instances here? is there anything smarter than running custom shell script in a screen or through cron? [21:41:22 CET] <nevcairiel> thats what i do, timed custom script :d [22:40:48 CET] <ubitux> nevcairiel: the sample you uploaded is available on rsync://fate-suite.ffmpeg.org/fate-suite/ but not rsync://fate.ffmpeg.org/fate-suite/ [22:41:04 CET] <nevcairiel> why is there both with different content [22:41:09 CET] <ubitux> don't ask me [22:41:11 CET] <ubitux> :D [22:41:17 CET] <nevcairiel> fate-suite is the official URL we reference in the makefile [22:41:42 CET] <ubitux> my old script uses fate.ffmpeg.org [22:41:47 CET] <ubitux> like probably many of the other instances [22:42:31 CET] <nevcairiel> fate-rsync: [22:42:31 CET] <nevcairiel> rsync $(RSYNC_OPTIONS) rsync://fate-suite.ffmpeg.org/fate-suite/ $(SAMPLES) [22:42:34 CET] Action: nevcairiel shrugs [22:42:44 CET] <nevcairiel> i only have access to that one [22:43:31 CET] Action: ubitux looks at michaelni :° [22:44:11 CET] <nevcairiel> i dont know where the other url even ever came from [22:44:41 CET] Action: michaelni runs fate rsync sync script [22:44:49 CET] <nevcairiel> 236ecc3502e35b4f513c19c542075dc5737a4633 changed it apparently [22:44:52 CET] <nevcairiel> 5 years ago [22:45:00 CET] <ubitux> my script is older :3 [22:45:27 CET] <nevcairiel> this is your chance! [22:45:27 CET] <nevcairiel> :D [22:45:52 CET] <ubitux> i'm updating my script but other fate instances will continue failing [22:45:53 CET] <nevcairiel> michaelni: is that on a cron job otherwise, or do we have to upload it twice? [22:46:11 CET] <nevcairiel> i think i uploaded it ov er 24 hours ago already now [22:47:55 CET] <michaelni> its just a local script with a few rsync commands, i need to run it for one of my fate clients too IIRC. I forgot running it [22:51:04 CET] <cone-060> ffmpeg 03Clément BSsch 07master:b68068eed20e: fate: mask errors while constructing report files [23:04:12 CET] <TimothyGu> ubitux: huh? [23:09:31 CET] <ubitux> TimothyGu: wasn't there some fate beta at some point? [23:09:44 CET] <ubitux> and an oracle-like [23:09:48 CET] <ubitux> and all kind of stuff? [23:10:59 CET] <ubitux> oh there is still actually fatebeta.ffmpeg.org [23:11:12 CET] <ubitux> when is it going to replace the current one? [23:11:20 CET] <BtbN> It did [23:11:25 CET] <BtbN> Unless there is already a new beta [23:12:07 CET] <ubitux> well i mean replace fate.ffmpeg.org [23:12:32 CET] <BtbN> yes, I'm pretty sure that already happened quite a while ago [23:12:42 CET] <BtbN> Probably just wasn't ever taken down [23:12:44 CET] <nevcairiel> it did not [23:12:47 CET] <TimothyGu> IIRC it iddn't [23:12:57 CET] <nevcairiel> fatebeta has release branch tabs [23:12:59 CET] <nevcairiel> fate does not [23:13:13 CET] <nevcairiel> (which is the main feature i would really like to have, the release branches really crowd the list) [23:13:14 CET] <TimothyGu> I wanted to do it (and sent an email to the list saying I'd do it) but it never materialized [23:13:16 CET] <BtbN> I remember talk about it replacing the normal fate from months ago [23:13:55 CET] <TimothyGu> in short it just got stalled. more important things in real life (like university applications) took precedence [23:14:25 CET] <ubitux> ok :( [23:32:59 CET] <jamrial> there, patchset sent [23:47:05 CET] <ubitux> jamrial: nice :) [23:47:17 CET] <ubitux> i'm currently making up a freedos fate instance& [23:47:25 CET] <ubitux> kill T_T [23:47:29 CET] <ubitux> kill me T_T [23:47:38 CET] <jamrial> of all the missing targets, you're doing that one? :p [23:47:52 CET] <JEEB> le djgpp face [23:48:17 CET] <ubitux> jamrial: i need it to merge the next commit properly [23:48:41 CET] <ubitux> btw, i started migrating my fate instances, so they should be back in the green [23:49:20 CET] <jamrial> the printf specifiers one? [23:49:22 CET] <ubitux> i still miss ones though, like coverage, enable shared, old yasm or icc [23:49:25 CET] <ubitux> jamrial: yes [23:55:38 CET] <jpabq_> I read that the proper way to submit a patch, was to email it to the ffmpeg developer email list. Is that correct? [23:56:04 CET] <jpabq_> ffmpeg only uses the ticket system for problem reports? [23:56:04 CET] <JEEB> yes, git send-email nicely can handle it for you as well :) [23:56:49 CET] <jpabq_> I submitted a patch a few days ago. I just discovered that it does not handle ALL cases, so I need to submit a replacement. Should I just reply to the email I sent originally? [23:57:11 CET] <JEEB> you can do that :) [23:58:49 CET] <jpabq_> `git send-email` is problematic for me, since I am developing this at work and a machine that does not have email configured :( I ended up using git-format-patch and then attaching the result. I hope that is acceptable. [23:59:00 CET] <JEEB> should be [23:59:27 CET] <JEEB> you can also check if patchwork was able to grasp your patch https://patchwork.ffmpeg.org/project/ffmpeg/list/ [23:59:40 CET] <RiCON> jpabq_: you can also use gmail's smtp [00:00:00 CET] --- Sat Mar 25 2017

1 0

ffmpeg.log.20170324
by burek 25 Mar '17

25 Mar '17

[01:03:31 CET] <hiru> hello everyone! is it normal having inaccurate cuts using -ss and -to parameters? I tried using a starting point but the output video starts a minute and half away from the starting point I declared.. [01:05:09 CET] <hiru> this is the line I used: ffmpeg -i <input> -ss <starting-point> -to <ending-point> -c:v libxh264 -preset medium -crf 17 <output> [01:16:15 CET] <znf> Hi. Anyone has any idea why would a rtsp stream work just fine in VLC but not in ffmpeg? I get "Output file #0 does not contain any stream" when I try to transcode it [01:17:19 CET] <furq> znf: try increasing probesize and/or analyzeduration [01:17:22 CET] <znf> ffprobe finds the stream, tough it can't seem to determine the resolution, but ffplay doesn't work either (I get method not allowed) [01:19:46 CET] <znf> I increased them to 999999 [01:19:53 CET] <znf> still nothing [01:21:45 CET] <furq> the default for both is 5000000 so that's not a surprise [01:21:58 CET] <furq> try 50M or something [01:25:49 CET] <marbar> hey everyone. does anyone here have experience w/ hls on ios? [01:25:58 CET] <marbar> i'm segmenting a source video with this command: [01:26:04 CET] <marbar> ffmpeg -i 9 -map 0 -c:v libx264 -c:a aac -deinterlace -f ssegment -segment_list hls/9/list.m3u8 -segment_list_flags +live -segment_time 10 hls/9/%03d.ts [01:26:12 CET] <marbar> and on ios (only) it stops after about a minute and a half [01:26:19 CET] <marbar> is there some flag i can add to ensure playback on the ipad? [01:30:24 CET] <znf> furq, nah, still getting 405 method not allowed [01:31:43 CET] <dystopia_> marbar if your doing -c:a you don't need to specify the codec [01:31:48 CET] <dystopia_> as your just remuxing from source [01:32:00 CET] <dystopia_> as to your issue, i imagine it's an issue with ios [01:32:30 CET] <xtina> hey guys. it's been a while since i've been in here, i'm the one working on livestreaming audio/video from my pi zero [01:32:40 CET] <marbar> dysfigured, thanks, i'll change that. yes, it seems to be, as it plays fine everywhere else. [01:32:42 CET] <dystopia_> as your live encoding, when you open the video on the ipad it see's it's currently like 90s long or whatever and quits playback when it reaches that point [01:32:48 CET] <xtina> i'm looking for some advice on adding timestamps to the audio and video so they can stay in sync. they both need to be timestamped off of 1 clock [01:32:56 CET] <dysfigured> marbar: you should get a better irc client :^) [01:33:07 CET] <marbar> dysfigured, haha, ok, what do you recommend? [01:33:15 CET] <xtina> i'm currently recording audio using SOX and video using ffmpeg. is anyone familiar with how i might add timestamps for both off of one clock? [01:33:19 CET] <dysfigured> or, if you're using weechat, configure it so that it tab-completes the last active nick [01:33:41 CET] <marbar> oh my! i see. sorry dysfigured and dystopia_ [01:33:51 CET] <dysfigured> if weechat, /set irc.look.nick_completion_smart speakers [01:34:03 CET] <marbar> dysfigured, i'm on xchat, just sloppy i guess [01:34:10 CET] <znf> furq, ah, got it, apparently I have to specify tcp mode [01:34:32 CET] <dysfigured> it's all good, just being a cheeky git. weechat is super nice tho, if you're a cli nerd i highly recommend it [01:34:39 CET] <xtina> just to add: i want to add timestamps without re-encoding the video [01:34:42 CET] <xtina> since I'm really CPU bound [01:34:47 CET] <marbar> dysfigured, mmm, i'll check it out, thanks [01:34:53 CET] <xtina> can ffmpeg timestamp my h264 encoded video file without reencoding it? [01:35:00 CET] <dysfigured> i recommend it even if you're not a cli nerd actually. anyway, i'll leave now /me waves bye [01:35:11 CET] <marbar> dystopia_, do you happen to know of any flags that smooth out videos on ios? like is there some particular thing that they uniquely disallow or choke on? [01:35:55 CET] <znf> xtina, not really, video doesn't work that way [01:37:09 CET] <xtina> @znf: hmm, i see. i got the following response to my question on the raspberry pi forums: "Every camera frame has a timestamp on it taken from the SoC STC (System Time Clock). The same STC is used as the Linux reference. The V4L2 driver already converts between the two clock domains, and raspivid has the -pts option to save a file of timestamps that mkvmerge can handle ("mkvmerge -o video.mkv --timecodes 0:timecodes.txt video.h264". D [01:37:43 CET] <xtina> i'm having a hard time understanding it though :( what are the two different clock domains? what clock is there besides the SoC clock? Why is conversion needed? [01:38:04 CET] <znf> oh, nevermind, you meant proper timestamps not just overlay, ignore me [01:38:11 CET] <xtina> znf: yes, not overlay [01:40:25 CET] <marbar> does anyone know the best place to find presets that work with current ffmpeg builds? an ios preset in particular? [01:51:19 CET] <xtina> i'm trying to add timestamps to my audio recording [01:51:39 CET] <xtina> i'm currently using SOX for the recording but might be willing to use a different lib if it allows me to add timestamps [01:51:44 CET] <xtina> any ideas? [01:52:18 CET] <xtina> is this something i might have to code myself? [02:13:49 CET] <xtina> has anyone used mkvmerge before? it does absolutely nothing but hang for me [02:13:51 CET] <xtina> i'm on a pi zero [02:14:23 CET] <xtina> @furq: do you have any ideas how I can add timestamps to my audio and video? i thought it would be simple but i'm making no headway [02:14:49 CET] <xtina> on the video front I have a MKV file as well as a txt file of timestamps. [02:14:53 CET] <xtina> can ffmpeg accept this? [02:15:06 CET] <xtina> or do i need to merge them using some other lib first? [02:40:53 CET] <moneylotion> hey ffmpegers, anyone have some pointers for how to batch remove commercials from ripped videos? [02:41:16 CET] <moneylotion> i was trying mythtvcommflag, but that only works with myth videos from what i've read [03:08:52 CET] <Anthropohedron> Is there any way to tell from a .VOB (or .BUP or .IFO) file what language the audio or subtitle tracks are? I've been fighting with a particular DVD for over a week now. The first .VOB of the title has native audio (Chinese, in this case) as its first audio stream and English as its first subtitle stream. But it also has English, French, and Spanish audio dubs, and French and Spanish subtitles. In subsequent .VOB file [03:08:53 CET] <Anthropohedron> s the audio and subtitle streams are in different orders. It's maddening. [04:22:11 CET] <alexpigment> moneylotion: i've never found that process to be something you can do automatically [04:23:17 CET] <alexpigment> perhaps it's because american broadcasts are horrible at allowing lead-ins and lead-outs, but there's often more black frames in between commercials than there are in between the commercial and program itself. i just end up using VideoRedo and do it manually [04:23:27 CET] <alexpigment> depends on the channel, i'm sure [04:39:04 CET] <moneylotion> im using playon.tv - it's hit or miss, but it actually added chapters in the video file for ads... anyway ffmpeg could clip chapters out? [05:27:56 CET] <xtina_> hey guys. i'm struggling to add mmap access to my soundcard. [05:28:05 CET] <xtina_> i've added mmap_emulation true to my alsa config: http://vpaste.net/rBKeK [05:28:19 CET] <xtina_> i've also tried adding dtoverlay=i2s-mmap to /boot/config.txt [05:28:29 CET] <xtina_> but i get the error that mmap_emulation is not a recognized param: [05:28:50 CET] <xtina_> http://vpaste.net/2k9HP [05:28:53 CET] <xtina_> any suggestions? [06:00:07 CET] <xtina_> also, does anyone know how to get timestamps for ALSA audio? i thought it would be easy but... no pointers.. [06:13:50 CET] <xtina_> anyone know if i can pass a timestamp input file to ffmpeg along with a video source? [06:50:39 CET] <xtina_> hey guys, i'm trying to give ffmpeg a txt file of timestamps along with the video file i'm passing in. i just want to know if that is possible [06:50:42 CET] <xtina_> ideas? [07:16:40 CET] <xtina> Hey guys, I want ffmpeg to accept a text file of timestamps along with my h264 input, instead of generating timestamps based on an FPS argument (-r) [07:16:48 CET] <xtina> is there any way for ffmpeg to accept an input file of timestamps? [07:17:03 CET] <xtina> if not, any pointers on how I could modify ffmpeg to do so? I am willing to write my own patch if it isn't really complex [07:29:14 CET] <panpeter> Good morning everyone, ive want to compile gst-plugins-bad myself, my gst-launch says its version 1.8.4, the current master of plugins bad has 1.11.2, do i have to use matching versions or is it possible to mix up versions? [07:31:41 CET] <xtina> can anyone point me to where in ffmpeg "timestamps" are generated based on the input -r, since that's the part i assume i need to patch? [08:41:38 CET] <xtina> hey guys. i'm running into an issue where i'm using ffmpeg to stream and i'm sometimes in low wifi-signal areas. when this happens, i end up overflowing my 1MB FIFO audio pipe, and my ALSA buffer_size is a sad 62kb. [08:41:50 CET] <xtina> I believe 1MB is the upper limit for a FIFO pipe size so i can't increase this [08:42:16 CET] <xtina> I tried writing the audio input to a regular file instead of FIFO, hoping that my theoretical 'buffer' would not be constrained by the 1MB limit [08:42:48 CET] <xtina> but in that situation it seems like writing/reading from disk is too slow, since i end up with high delays between audio/video packets, and errors thrown in ffmpeg [08:43:21 CET] <xtina> does anyone have ideas for how else i can increase the buffer for my audio packets beyond a paltry 1MB? I'm on a pi zero with 512MB of RAM and I'm not using more than 100MB while streaming, so I'd really like to be able to use the remaining 400MB instead of losing those packets [09:33:52 CET] <hiihiii> hello [09:34:12 CET] <hiihiii> how do you describe time in milliseconds? [09:36:44 CET] <hiihiii> I've looked one example which had the x & y parameters of drawtext filter change every 30 seconds [09:37:04 CET] <hiihiii> x=if(eq(mod(t\,30)\,0)\,rand(0\,(w-text_w))\,x) [09:37:43 CET] <hiihiii> I'd like to know is it possible to express 30seconds in milliseconds? [09:50:37 CET] <Rajko> please tell me how to use dxva through C api ? [09:50:49 CET] <Rajko> the find_decoder_by_name of h264_dxva2 does not exist [09:53:10 CET] <Rajko> i can find AHWAccell but i do not know where to plug it into my AVContext [09:53:40 CET] <Rajko> AVCodecContext [11:13:48 CET] <kerio> on a raspberry pi there's unnecessary copying going on with ffmpeg even if i use accelerated decoding and encoding, right? [11:18:06 CET] <BtbN> what do you mean? [11:19:01 CET] <kerio> ffmpeg -c:v h264_mmal -i foo.mp4 -c:v h264_omx bar.mp4 [11:30:58 CET] <mad_ady> hello all! [11:31:51 CET] <mad_ady> quick question - I want to make a movie out of an image sequence. The thing is - I already have the sequence file names in a variable space separated (e.g. ./83dad79139d8cccd498d_1490320502.png ./83dad79139d8cccd498d_1490320562.png ./83dad79139d8cccd498d_1490320621.png) [11:32:15 CET] <mad_ady> do I need to prefix each file with -i, or one -i should be enough at the beginning? [11:32:34 CET] <mad_ady> the order I'm giving them in is chronological [11:33:01 CET] <DHE> I think the easiest answer is to make a symlink sequence to put them into numerical order and import tnat [11:33:02 CET] <DHE> that [11:34:12 CET] <mad_ady> hmm, sounds like a lot of work, but I understand the concept [11:34:28 CET] <mad_ady> let's see if adding -i before each file works [11:34:42 CET] <mad_ady> though I'm talking about thousands of files [11:34:55 CET] <DHE> no. it won't [11:35:12 CET] <mad_ady> that's because it should all be one input? [11:35:13 CET] <DHE> ffmpeg supports multiple input files, usually for the intention of taking audio from file 1 and video from file 2, etc. [11:35:23 CET] <mad_ady> I see [11:35:34 CET] <DHE> you'd need to use a concatenation filter to turn it into a movie, and that becomes its own logistical nightmare [11:36:05 CET] <mad_ady> there is no separator between files to show ffmpeg it's an explcit list, right? [11:36:13 CET] <DHE> ffmpeg [11:36:41 CET] <DHE> ffmpeg's commandline is loosely: ffmpeg [input1 options] -i input1 [input2 options] -i input2 .... [output1 options] output1 [output2 optinos] output2 ... [11:36:50 CET] <DHE> though most times it's only 1 input and 1 output [11:36:55 CET] <mad_ady> yes [11:36:57 CET] <DHE> with a few options being global [11:37:14 CET] <mad_ady> I've played with stream mapping in the past, and that's not what I'm trying to do in this case [11:37:24 CET] <mad_ady> I'll give your symlink suggestion a try [11:37:45 CET] <mad_ady> maybe use /tmp or a ramfs to reduce wear on the disk [11:37:58 CET] <mad_ady> will try it after lunch, thanks :) [11:39:43 CET] <jkqxz> It would probably be easier to cat the files together in order and use image2pipe. [12:12:26 CET] <animaonline_> Hi there, I was wondering how I can programmatically re-stream a local RTSP stream to an external one. Any starting directions would be greatly appreciated. [12:18:04 CET] <vlt> Hello. What is the recommended way to stream a USB webcam video in most realtime possible to another machine? (Both in same 100 Mbit/s LAN, Linux) [12:32:43 CET] <furqan> i have problem executing this http://pastebin.com/FJTvci6j [12:32:52 CET] <furqan> ffmpeg hangs while executing that [12:38:16 CET] <panpeter> Hello, ive checked out gstreamer-plugins-bad repo and compiled everything, is it possible to only add a single plugin to my working installation? i.e. copy [plugin].so into my /usr/lib/x86_64-linux-gnu/gstreamer-1.0/ folder, will this work? [12:39:46 CET] <BtbN> this is #ffmpeg [12:48:01 CET] <hiru> hello everyone. I have a question, may I? [13:06:25 CET] <DHE> hiru: don't ask to ask, just ask [13:12:32 CET] <mad_ady> @DHE: I implemented your method and worked wonderfully [13:12:36 CET] <mad_ady> Thank you for the suggestion [13:12:44 CET] <mad_ady> and have a nice weekend [13:38:26 CET] <furqan> hi, i want to trim video depending concated video length in complex filter [13:38:31 CET] <furqan> how can i do that? [13:49:46 CET] <vlt> Can ffmpeg take a video source (like /dev/video0 created by what appears as "usbcore: registered new interface driver uvcvideo" in dmesg), encode it using a low latency (libx264?) mode and then provide it via network to any "client" that wants to play that? [13:50:04 CET] <vlt> I mean can ffmepg itself act as the "server" part of that setup? [13:51:57 CET] <JEEB> it can do multicast if that's what you mean as means for low-latency streaming [13:52:24 CET] <JEEB> for HTTP and stuff there's some "listen" mode, but generally I wouldn't recommend it, and you have better alternatives [13:52:44 CET] <JEEB> also low latency wise you will most likely have to tweak some parameters, but libx264 most definitely can do it [13:53:17 CET] <JEEB> libavformat and libavcodec's shenanigans etc require tweaking, but people have done it [13:53:20 CET] <vlt> JEEB: What would be a better alternative to provide (a) client(s) with the video stream? [13:53:32 CET] <JEEB> well with low latency you need UDP [13:53:43 CET] <JEEB> and multicast/unicast is supported in lavf [13:54:30 CET] <vlt> JEEB: Ok, so ffmpeg _is_ the "server" but just not in HTTP mode, right? [13:56:18 CET] <JEEB> yes [14:12:49 CET] <marbar> hi folks [14:13:16 CET] <marbar> so, i've been trying to encode this video all sorts of ways, and it always fails on ios right around the same place (a little over a minute in) [14:13:41 CET] <marbar> does anyone know of a set of flags that guarantee ios playback? [15:07:59 CET] <alexpigment> marbar: what device are you trying to play it on? [15:08:39 CET] <alexpigment> and what is your current command line? [15:14:05 CET] <alexpigment> marbar: well, in absense of an answer, here's a sample that will work on iphone 4s and above (and probably the iphone 4, but unofficially so) [15:14:38 CET] <alexpigment> ffmpeg -i [infile] -f mp4 -vcodec libx264 -s 1920x1080 -aspect 16:9 -crf 18 -level 4.1 -profile:v high -r 30000/1001 -g 30 -acodec aac -ar 44100 -ac 2 -ab 160000 [outfile] [15:22:16 CET] <obamoose> hello! [15:22:43 CET] <alexpigment> hey obamoose [15:23:03 CET] <obamoose> http://pastebin.com/1PP7S6ig [15:23:13 CET] <obamoose> will this eternally loop my cgn directory in a single stream? [15:23:59 CET] <alexpigment> that's outside of my wheelhouse [15:24:04 CET] <obamoose> ;_; [15:24:13 CET] <alexpigment> however, why do you have -f -f flv at the end? [15:24:18 CET] <obamoose> I have no idea [15:24:21 CET] <obamoose> I'm pretty bad with ffmpeg [15:24:39 CET] <alexpigment> k [15:25:01 CET] <alexpigment> well i'd wait for others here to chime in [16:43:34 CET] <marbar> alexpigment!!! sorry, i was afk :) thanks for the tip, running it now [16:43:45 CET] <marbar> alexpigment, i'm testing on an ipad [16:44:22 CET] <marbar> alexpigment, i modified your sample because i'm using hls [16:44:31 CET] <marbar> so: ffmpeg -i 9 -vcodec libx264 -s 1920x1080 -aspect 16:9 -crf 18 -level 4.1 -profile:v high -r 30000/1001 -g 30 -acodec aac -ar 44100 -ac 2 -ab 160000 -f ssegment -segment_list hls/9/list.m3u8 -segment_time 10 hls/9/%03d.ts [16:54:26 CET] <alexpigment> k, does that appear to work or no? [16:54:59 CET] <marbar> it's still running... i'm gonna stop it and just do a small chunk. [16:55:56 CET] <marbar> ok this'll be a couple minutes but that's enough to test the part that messed up. thanks again alexpigment you're my hero. [16:56:26 CET] <alexpigment> ok, if it doesn't work, it may be because older ipads don't officially support 1080p [16:56:26 CET] <marbar> alexpigment, are you a dev? [16:56:33 CET] <marbar> ah i c [16:56:41 CET] <marbar> yeah, before i was encoding with way lower settings [16:56:44 CET] <alexpigment> no, just a guy who has had to do a lot of custom encoding in the past [16:56:44 CET] <marbar> going off old info i guess [16:56:57 CET] <marbar> oh man, i feel for ya [16:57:26 CET] <alexpigment> i have a spreadsheet with all the specs of all Apple devices. some of the devices support higher video specs than they advertise, but it's a good guideline [16:57:38 CET] <marbar> oh dude that's awesome. is it online somewhere? [16:57:49 CET] <alexpigment> no, not at the moment [16:58:06 CET] <marbar> man, i feel like it's been hard to find up to date info on this stuff [16:58:12 CET] <alexpigment> the world of video encoding is so small that i doubt it would benefit many people [16:58:18 CET] <marbar> haha [16:58:21 CET] <alexpigment> well, that's the thing, it's old info and it's very googleable [16:58:35 CET] <alexpigment> e.g. google "iphone 4 tech specs" [16:58:44 CET] <alexpigment> they have a page and they list supported video information [16:59:20 CET] <marbar> hm doesn't seem to work :( [16:59:32 CET] <marbar> with that command it dies on the first chunk [16:59:33 CET] <alexpigment> so usually it's just a matter of matching the resolution, h264 profile, h264 level, and audio bitrate (the last part i think is bs, but still) [16:59:46 CET] <marbar> previous command was this: ffmpeg -i 9 -map 0 -c:v libx264 -c:a aac -deinterlace -f ssegment -segment_list hls/9/list.m3u8 -segment_list_flags +live -segment_time 10 hls/9/%03d.ts [16:59:50 CET] <marbar> got as far as the 8th chunk, hah [17:00:05 CET] <alexpigment> are you getting any errors? [17:00:24 CET] <alexpigment> also, do you know the specs of your source material? [17:00:26 CET] <marbar> in the encoding? [17:00:33 CET] <marbar> ah, that's something i should figure out [17:00:36 CET] <marbar> ffprobe, right? [17:01:05 CET] <marbar> "Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc" [17:01:12 CET] <marbar> "Audio: aac (LC) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp" [17:01:42 CET] <marbar> is what it says for "ffprobe list.m3u8" [17:02:06 CET] <marbar> oh i mean that's the output [17:02:16 CET] <marbar> the source: [17:03:41 CET] <marbar> http://pastebin.com/nHJWmjqR [17:04:11 CET] <marbar> above is the ffprobe of the source file [17:04:21 CET] <marbar> i didn't get any errors in the encoding process [17:05:46 CET] <alexpigment> ok, so i don't know why the error is happening - that seems more like an HLS-related issue to me [17:06:48 CET] <alexpigment> but based on this information in the pastebin, i would modify the code above with the following parameters (replace what's already there) -level 4.0 -r 24000/1001 -g 48 [17:07:02 CET] <marbar> here's encoding output: http://pastebin.com/nRbu3GYT [17:07:38 CET] <alexpigment> oh i see [17:07:42 CET] <alexpigment> your source is 480x270 [17:07:51 CET] <marbar> oooh that's doing it? [17:07:56 CET] <alexpigment> no [17:08:01 CET] <alexpigment> but my settings are all wrong [17:08:15 CET] <marbar> oh *head smack* shoulda told you this stuff up front, sorry [17:08:21 CET] <alexpigment> again, i was basing it off your initial request, which was just that you were trying to encode for iOS and it was failing [17:08:25 CET] <alexpigment> no worries [17:08:50 CET] <marbar> also that's not the original original [17:08:50 CET] <alexpigment> lemme get something better for you; 1 sec [17:08:59 CET] <marbar> i suppose it's good practice to start with the closest to original file [17:10:10 CET] <marbar> orig file ffprobe: http://pastebin.com/hLWm6nip [17:10:30 CET] <marbar> i can try your command on the orig, might work better [17:10:58 CET] <alexpigment> wait [17:11:01 CET] <alexpigment> i'm confused [17:11:20 CET] <marbar> sorry. i was starting from a file that i had already encoded because i thought it would maybe help. [17:11:24 CET] <alexpigment> the pastbin earlier of "the source" was also 480x270 [17:11:29 CET] <alexpigment> so is *this* the actual source? [17:11:38 CET] <alexpigment> the newest link you sent? [17:11:38 CET] <marbar> well the first paste was the source i was using [17:11:51 CET] <marbar> the later paste is the source that i encoded to get it [17:11:57 CET] <marbar> which i should probably use instead, right? [17:12:03 CET] <marbar> i mean, of course [17:12:15 CET] <alexpigment> yeah, i think it's better to do one encode at a time [17:12:22 CET] <alexpigment> rather, one encode period [17:12:25 CET] <alexpigment> rather than two [17:12:31 CET] <marbar> good call [17:12:41 CET] <alexpigment> but your goal is to output to 480x270? [17:12:49 CET] <alexpigment> or remain in 720p? [17:13:30 CET] <marbar> well i think the 480x270 came in because i resized based on some old info [17:13:37 CET] <marbar> thinking it would make it work [17:13:48 CET] <alexpigment> ok, let's go for 1280x720 first [17:13:50 CET] <alexpigment> 1 sec [17:13:51 CET] <marbar> so i guess i should just forget that intermediate file. i'll try your command on the orig. [17:13:55 CET] <marbar> ok thanks :) [17:14:43 CET] <alexpigment> so this is for streaming? [17:14:57 CET] <alexpigment> i guess the bitrate should be constained a little bit then [17:15:08 CET] <marbar> basically when users upload videos i want to make an hls version for ios [17:15:21 CET] <marbar> (hls process currently works for android tablet) [17:15:30 CET] <alexpigment> ok, so this 720p is not going to be a static thing? [17:15:32 CET] <marbar> so streaming yes, but not live [17:15:48 CET] <alexpigment> like, the input resolution will constantly be changing based on what is uploaded? [17:15:57 CET] <marbar> well i could try to constrain that initially [17:16:22 CET] <marbar> but you would essentially need different commands depending? [17:16:27 CET] <alexpigment> no [17:16:34 CET] <alexpigment> lemme refresh myself on constaining resolution [17:16:35 CET] <marbar> oh ok. then i suppose i need something generic [17:16:48 CET] <marbar> dude thank you so much. you're a real lifesaver. [17:17:54 CET] <alexpigment> don't thank me yet - i don't know if any of this will work. my experience is piping from a renderer at any size and formatting to the upper limit of the device's capabilities [17:17:59 CET] <alexpigment> no HLS whatsoever [17:18:27 CET] <marbar> that sounds cool though [17:19:40 CET] <marbar> oh geez [17:19:43 CET] <marbar> i feel like such a troll [17:20:11 CET] <marbar> gosh i just realized this is the orig: http://pastebin.com/n7tJpfsu [17:20:19 CET] <marbar> i have so many video files floating around [17:20:40 CET] <marbar> this came fresh outta my friend's final cut pro [17:20:40 CET] <alexpigment> man, the confusion stacks ;) [17:20:47 CET] <marbar> i know :( haha [17:20:56 CET] <marbar> you know how these all-nighters go... [17:21:26 CET] <alexpigment> ok, so here's the deal - your original code is very bare-bones. there isn't a whole lot of limiting to the constraints of the device [17:21:28 CET] <alexpigment> BUT [17:21:48 CET] <alexpigment> at 480x270, you could encode this any number of ways and it wouldn't cause a problem [17:22:53 CET] <alexpigment> what i do find interesting is that the stream 0:0 of this original file is audio, and stream 0:1 is video [17:22:58 CET] <alexpigment> usually it's the other way around in my experience [17:23:08 CET] <marbar> oh right i noticed that! [17:23:14 CET] <marbar> weird right? i wonder if that's it... [17:23:24 CET] <alexpigment> well, you were using -map earlier [17:23:27 CET] <alexpigment> and i didn't know why [17:23:33 CET] <marbar> heh, neither did i [17:24:51 CET] <marbar> i'm just gonna try the command you suggested on the _real_ orig [17:24:52 CET] <alexpigment> well, i think i'm officially at that point - which i often get to here - where a simple question that i can certainly answer reveals itself to be a complex problem involving things i've never touched before [17:24:59 CET] <marbar> maybe everything will be fine once i'm not encoding it ten times [17:25:05 CET] <alexpigment> well, the real original is 480x270 [17:25:10 CET] <alexpigment> so you're upscaling [17:25:25 CET] <marbar> oh yeah so it is [17:25:31 CET] <marbar> does that cause problems sometimes? [17:25:51 CET] <alexpigment> how about just doing -i [infile] -c:v libx264 -crf 20 -c:a aac -b:a 128000 [17:26:05 CET] <marbar> ok i'll give it a shot... [17:26:14 CET] <alexpigment> no, upscaling usually works fine, but it's just unnecessary work if you're going from 480x270 to 1920x1080 [17:29:10 CET] <marbar> :-\ ran it on orig, chokes on second chunk [17:31:37 CET] <obamoose> hello [17:32:00 CET] <obamoose> i'm trying to create a stream that never stops [17:32:09 CET] <obamoose> but my stream ends after every video file I stream [17:32:13 CET] <obamoose> how do i fix this ;_;? [17:32:17 CET] <obamoose> http://pastebin.com/1PP7S6ig [17:32:21 CET] <marbar> alexpigment, ok, i tried making a regular mp4 instead of doing hls anything and it doesn't play in ios [17:32:31 CET] <marbar> there's something messed up about the orig that i can't seem the shake off [17:33:33 CET] <alexpigment> that seems so weird [17:33:46 CET] <alexpigment> you're playing it on iOS how? [17:33:54 CET] <marbar> yeah totally. my friend exported it from final cut pro [17:34:05 CET] <marbar> i'm opening it in chrome [17:34:07 CET] <marbar> on an ipad [17:34:11 CET] <alexpigment> oh ok [17:34:13 CET] <marbar> served from my computer [17:34:16 CET] <alexpigment> well, there's a potential point of failure there [17:34:42 CET] <alexpigment> again, out of my wheelhouse because i'm not a webdev [17:34:52 CET] <alexpigment> but i know that sometimes you have to define the mime types in a certain way [17:35:11 CET] <marbar> hm interesting [17:35:20 CET] <marbar> because it's only happening every once in a while [17:35:25 CET] <marbar> that is, not on every chunk [17:35:42 CET] <marbar> it's possible, i suppose, that certain chunks are misidentified for whatever reason, resulting in wrong mime types like you say [17:36:04 CET] <alexpigment> you could try renaming it to .m4v as a test [17:36:36 CET] <alexpigment> Apple generally prefers .m4v for mp4 files, but in my experience, it's only because it allows them to associate a non-standard extension with iTunes [17:37:29 CET] <alexpigment> but a stopgap solution would be to change the mimetype to video/m4v [17:37:45 CET] <alexpigment> type="video/mp4" in your source tag [17:37:47 CET] <alexpigment> er [17:37:51 CET] <alexpigment> video/m4v [17:37:56 CET] <marbar> still messes up :-\ [17:38:02 CET] <marbar> but differently interestingly [17:38:06 CET] <alexpigment> yeah, not sure then [17:38:18 CET] <alexpigment> i suppose you can't use safari in ios for this? [17:38:24 CET] <marbar> as a .m4v it gets really messed up but continues playing [17:38:33 CET] <marbar> whereas as an .mp4 it doesn't even play [17:39:09 CET] <marbar> but yeah it's super messed up. all green, sound and video both in and out, now frozen [17:39:12 CET] <alexpigment> ok, but what about keeping .mp4 and changing the source to type="video/m4v" [17:39:27 CET] <alexpigment> green video usually means missing information in the video stream [17:39:30 CET] <marbar> oh i'm not even loading this up on a web page [17:39:39 CET] <marbar> i'm just loading the file directly (in chrome) [17:39:47 CET] <marbar> so no video tag or anything eveen [17:42:45 CET] <alexpigment> ok, well as a test, take the original video and re-encode it with this command: ffmpeg -i [infile] -f mp4 -c:v libx264 -crf 20 -c:a aac -b:a 128000 -movflags faststart [outfile.mp4] [17:43:03 CET] <alexpigment> play it on your computer and make sure it works [17:43:10 CET] <alexpigment> then try the test again in chrome [17:43:59 CET] <marbar> ok [17:45:41 CET] <marbar> oh crap, works for about ten seconds [17:46:05 CET] <marbar> ya know, the guy just called me. i can probably get a different cut of this video [17:46:08 CET] <marbar> to work with [17:46:55 CET] <marbar> (and yes, it works fine on my computer) [17:47:29 CET] <marbar> is there some basic export setting you'd recommend from final cut pro to avoid this kinda thing? [17:47:52 CET] <alexpigment> i haven't worked in FCP in years - i use Adobe Premiere [17:47:58 CET] <marbar> ah i c [17:48:05 CET] <alexpigment> so i don't know what setting to use, but it does seems weird that you're getting a 480x270 video [17:48:26 CET] <marbar> yeah i think he used an iphone setting of some kind [17:48:30 CET] <alexpigment> like that's not reference quality for any TV standard, new or old [17:48:35 CET] <marbar> haha [17:49:10 CET] <marbar> ok i'm calling him for another cut... [17:49:36 CET] <alexpigment> yeah, see if you can get it in 1280x720 [17:49:55 CET] <marbar> ok will do [17:50:06 CET] <alexpigment> some encoders (and decoders I suppose) have a hard time with resolutions that aren't divisible by a certain number [17:50:21 CET] <alexpigment> 1280x720 is divisible by 16 on both width and height [17:50:44 CET] <alexpigment> whereas 480x270 doesn't divide evenly by 4 on the height [17:50:55 CET] <alexpigment> not that i think it should matter at all, but still [17:57:29 CET] <marbar> dude thanks so much. all great points. i'll let you know as soon as i have a fresh source file... [18:27:38 CET] <flomko> Hi all! I have some problem with filters/ filter_complex. My system Centos7, to run ffmpeg i use repo nux-dextop/x86_64. On previos system i run "ffmpeg -i input.mp3 -filter_complex "showwavespic=s=640x120" -frames:v 1 output.png" to create waveform, but on fresh ffmpeg it dont work. I found, that i need use -lavfi with "ffmpeg -i input.mp3 -lavfi showwavespic=split_channels=1:s=640x120 [18:27:38 CET] <flomko> output.png" and it still useless. In outpit ffmpef -filter i found that i have only "showwaves" for videooutput. Can anybody help? [18:28:47 CET] <flomko> i try create videofile with 1 framy, but output definetly wrong "ffmpeg -i input.mp3 -lavfi showwaves=s=640x120 -frames:v 1 output.png" [18:28:52 CET] <jfmcarreira> heyy guys [18:29:11 CET] <jfmcarreira> is there any examples or code where i can see the new api uses? avcodec_receive_frame [18:29:30 CET] <jfmcarreira> i am currently feeling that i am using bleeding edge functions... [18:29:40 CET] <c_14> flomko: your version of ffmpeg is too old, update [18:31:18 CET] <flomko> c_14 ffmpeg version 2.6.8 Copyright (c) 2000-2016 the FFmpeg developers. Maybe u can help me with link to fresh repo to centos? [18:31:41 CET] <c_14> try a static build [18:31:44 CET] <c_14> http://johnvansickle.com/ffmpeg/ [18:32:47 CET] <c_14> or build from source https://trac.ffmpeg.org/wiki/CompilationGuide/Centos [18:34:08 CET] <flomko> thank y [18:37:22 CET] <cesdo> Hello. I watch youtube videos with mpv and often get [ffmpeg] tls: The TLS connection was non-properly terminated. [18:37:53 CET] <cesdo> Is it serious error? [18:43:41 CET] <cesdo> [osd/libass] PlayResX undefined, setting to 960 [18:43:52 CET] <cesdo> What is 960? [18:45:18 CET] <kepstin> a number in pixels. it's an internal detail from the subtitle renderer; if everything looks fine don't worry about it. [18:51:40 CET] <durandal_1707> jfmcarreira: doc/examples [19:00:55 CET] <jfmcarreira> thanks [19:01:04 CET] <jfmcarreira> but there is not example with the new API [19:06:43 CET] <ZexaronS> hello [19:07:43 CET] <ZexaronS> i was wondering if it was possible to create a ffmpeg script to run on some portable device that is hooked up to a digital camera for timelapse recording [19:08:05 CET] <dystopia_> a script to do what? [19:08:42 CET] <marbar> alexpigment, omg dude i got sidetracked. my friend is sending me a fresh file later tonight. i'll let you know how it goes. thanks again dude! [19:09:19 CET] <ZexaronS> The idea is, so that it works in real-time (buffer) so that a lot of the video doesn't need to be saved, but that the video is being converted to snapshots highlights, however, the script has to analyze a portion of the video to determine the occurence of highlights, that's where the for example 5 minute buffer comes in [19:10:07 CET] <ZexaronS> so instead of me having to recoird 10 gigabytes for 24 hours and then extract and do manual screenshots, it would do this onfly [19:11:18 CET] <ZexaronS> The point of the script would also be to save more screenshots when there is more activity going on in the picture, so when there's night and not much going on it would do only 1 screenshot per 10 minutes, when there's alot going on it would take for example 1 sceenshot every 10 seconds [19:13:00 CET] <ZexaronS> the script would recognize the video as if it was offline, well, probably has to know it's being recorded live but with a big buffer it doesn't need actual "live" capability, plus the buffer is needed because an area of 1-2 minutes has to be analyzed in whole to determine the number of appropriate highlights based on how much change happens over that 1-2 minute span [19:13:37 CET] <dystopia_> that seems very possible to do [19:13:49 CET] <ZexaronS> This would create very good timelapses automatically, without having to sift through hoards of gigabytes of video and doing it manually [19:13:58 CET] <dystopia_> save 1 frame ever x seconds or somthing [19:14:13 CET] <ZexaronS> Indeed [19:14:15 CET] <furq> ZexaronS: mpdecimate can probably do that [19:14:17 CET] <furq> !filter mpdecimate [19:14:17 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#mpdecimate [19:16:18 CET] <mofasa> Is there any way to produce a "libffmpeg.so" when building ffmpeg? [19:16:41 CET] <furq> bye [19:17:38 CET] <kepstin> mofasa: like, combine all the different ffmpeg libraries (libavcodec, libavformat, etc.) into one dll? not that I know of. [19:17:43 CET] <ZexaronS> That's one part, but it would be rough, this is meant for construction sites in my case, ... it's also more complex because the thing has to save minimal, it has to save 1 frame each 2 minutes anyway at least, then the activity-sensor would determine the frequency of saved frames up to 10 per minute max. [19:17:55 CET] <furq> gcc can merge multiple .a into one .so [19:18:02 CET] <furq> but there's no way of doing it with the ffmpeg build system [19:18:13 CET] <furq> you'd have to build with --enable-static and then merge them yourself [19:18:20 CET] <furq> it also might break shit [19:18:51 CET] <ZexaronS> I kinda feels so strongly about this I'd contribute myself if I had more experience [19:19:06 CET] <mofasa> Allright.. Just need h264 for chromium, which isn't provided by openSuse any longer [19:23:05 CET] <furq> ZexaronS: drop the input framerate to 1/6 and then set mpdecimate's max to 19 [19:33:05 CET] <ZexaronS> furq: I find that a bit too easy to do all the things I had in mind, but how close would it be? [19:33:34 CET] <furq> "it has to save 1 frame each 2 minutes anyway at least, then the activity-sensor would determine thefrequency of saved frames up to 10 per minute max." [19:33:37 CET] <furq> it does that [19:33:50 CET] <furq> and how often it saves frames is based on the difference from the previous frame [19:34:10 CET] <furq> whether it'll be a functional security camera i don't know [19:34:51 CET] <furq> the problem with setting the input framerate to 1/6 means that if something happens but only lasts four seconds, it might not get noticed [19:37:08 CET] <furq> i'm not an expert on all 172 video filters in ffmpeg but i can't think of any other way to do it without using external tools [19:37:23 CET] <ZexaronS> Oh, sorry, see, it's not a security camera, it's for construction work site timelapse, a key thing is missing, it has to have a way to determine how much something has moved over a range of 1000 frames, so of a excavator has moved only a few pxiels, that's too low, we don't need to snap a highlight, but if a big truck moved in and out of the whole picture in less than 1000 frames then we need to take a highlight of that truck at [19:37:23 CET] <ZexaronS> least once or twice [19:37:43 CET] <furq> well yeah that's how mpdecimate works [19:38:15 CET] <ZexaronS> highway construction timelapse, wee need a sensor of movement over larger frame batches not just difference of current to previous frame, that's too low for detecting any of that slow movement of vehicles [19:38:26 CET] <furq> maybe [19:39:10 CET] <ZexaronS> That's why timelapses don't look good if people do it too roughly because there's a lot of rough cuts, this would make it a lot more smooth. [19:39:14 CET] <ZexaronS> And all automatically [19:39:25 CET] <thebombzen> yea mpdecimate drops frames that are close the the previous one [19:39:26 CET] <furq> this sounds like it's getting into opencv territory to do it properly [19:39:44 CET] <ZexaronS> Forget the realtime on-fly part, i'd rather just have it work offline for starters. [19:39:59 CET] <thebombzen> so by seting the framerate to 1/6 you are recording 10 frames per minute [19:40:10 CET] <thebombzen> and mpdecimate will drop ones that are very similar to the previous one [19:41:00 CET] <furq> yeah bear in mind mpdecimate is analysing one frame every six seconds [19:41:21 CET] <furq> or whatever you set the framerate to before invoking it [19:41:26 CET] <thebombzen> then, if you want to timelapse it correctly, you can use the setpts filter to rewrite the timestamps as a constant framerate [19:41:42 CET] <thebombzen> so like, this will drop frames but it won't change their timestamps so you'll end up with variable framerate [19:42:04 CET] <furq> i assumed he was outputting to images, in which case you don't need to do that [19:42:06 CET] <ZexaronS> Yes that's all good to hear that this is roughtly possible, but what if the machines on the construction site simply chugg along and don't do much, for example if an excavator is excavating and rotating it's hand, we don't need highlights of the excavator rotating, but if the excavator moves some distance we might want to keep the a few frames of it moving on it's tracks toward a new section in the pciture [19:42:13 CET] <furq> but if you want to output a video in the same pass then you'll need setpts [19:42:34 CET] <furq> ZexaronS: that's about as good as you'll get with ffmpeg as far as i know [19:42:45 CET] <thebombzen> ZexaronS: mpdecimate has a parameter on how different you want the frame to be [19:43:02 CET] <furq> mpdecimate isn't really designed for that and i don't think anything else gets any closer [19:43:25 CET] <furq> maybe one of the libavfilter gurus can tell us otherwise [19:44:19 CET] <furq> if you know a bit of C then it shouldn't be that difficult to add a new filter or modify mpdecimate [19:44:22 CET] <ZexaronS> thebombzen, I was about to ask about that as well yes, 1 frame of comparison might simply not be enough no matter how much I try because there's going to be a lot of movement of all the people , even if those people move only a little if there's 15 people strolling, each one of them adds up to the bits changing [19:45:08 CET] <thebombzen> then you're going to have to do that one yourself probably [19:45:36 CET] <ZexaronS> Yes I was amusing the idea of trying to have a look at libavfilter myself ... but I'm not a real programmer and if I was I'd be happy to contribute right now [19:49:25 CET] <ZexaronS> But at least I brought it up to kinda get it familiarized, and anyone knows who these liavfilter guru's are ? [19:54:28 CET] <ZexaronS> For starters I'll make a trac [20:37:27 CET] <ZeroWalker> what's a simple way to compile ffmpeg on windows? (i would love to use visual studio, but i guess one has to use mingw or something) [20:37:36 CET] <JEEB> you can use mingw-w64 or MSVC [20:37:40 CET] <JEEB> but you need a shell in any case [20:38:00 CET] <JEEB> MSVC needs to be 2013, 2015 or 2017 with latest update(s) installed [20:38:27 CET] <JEEB> testing with 2012 was stopped recently due to 2017 coming out and 2012 needing a converter for the source code [20:39:45 CET] <JEEB> ZeroWalker: for MSVC you basically call the configure script with certain parameters when the MSVC things are in your PATH (just make sure 'link' points to the MSVC link and not the msys2 thing) [20:41:15 CET] <ZeroWalker> hmm, that's a bit beyond me, really bad at the configure script stuff, i only used it with mingw cause, well that's was the way to do things, but i don't know hot it's setup or how to modify it [20:41:26 CET] <ZeroWalker> i do use visual studio 2017 so at least that's set [20:48:35 CET] <JEEB> ZeroWalker: so if you want to build with msys2 + MSVC (first just for the shell and make to configure and run the compilation), make sure the tools like cl and link are in PATH (usually there's an env var which leads to vsvars32.bat or so) [20:48:49 CET] <JEEB> and then you can try configuring it like the MSVC 2017 FATE machine [20:49:07 CET] <JEEB> http://fate.ffmpeg.org/report.cgi?time=20170323125228&slot=x86_32-msvc15-wi… [20:49:29 CET] <JEEB> that has stuff like enable-gpl and enable-memory-poisoning etc enabled but those aren't required of course [20:49:53 CET] <JEEB> --toolchain=msvc --arch=x86 or x86_64 seem to be the main things [20:50:13 CET] <JEEB> setting the toolchain pretty much enables the MSVC build mode [21:10:00 CET] <faLUCE> Hello. How can I generate a stereo dummy audio (like a sin() or something similar) ? [21:10:49 CET] <JEEB> libavfilter should have filters for that [21:11:12 CET] <faLUCE> JEEB: I mean with ffmpeg command [21:11:45 CET] <JEEB> yes [21:11:58 CET] <JEEB> ffmpeg-all.html and see what filters there are that you can use from ffmpeg.c as well [21:12:03 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html [21:13:47 CET] <faLUCE> JEEB: what should I search? I searched "dummy" and found only video stuff [21:14:23 CET] <JEEB> are you fucking incapable of doing even basic fucking searching [21:14:24 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#toc-Audio-Filters [21:14:30 CET] <JEEB> ctrl+f "audio filters" [21:14:37 CET] <JEEB> or just scrolled a bit down [21:15:21 CET] <JEEB> or actually, audio sources would probably be better which is just under the filters [21:15:34 CET] <JEEB> one of them is called "sine", even [21:15:38 CET] <JEEB> which you can guess what it does [21:15:52 CET] <alexpigment> anullsrc is what i've used in the past, fwiw [21:16:05 CET] <alexpigment> but i don't know if faLUCE needs the audio to be audible [21:16:09 CET] <JEEB> yea, any of those audio sources or filters [21:18:29 CET] <faLUCE> there's not anything like what I asked... [21:18:41 CET] <faLUCE> there's only a silence filter [21:18:59 CET] <faLUCE> JEEB: sorry, I did not read "sine" [21:19:06 CET] <kepstin> aevalsrc is the best for making dummy streams, it's pretty easy to make e.g. a sine wave [21:19:24 CET] <JEEB> " there's not anything like what I asked..." <- fuck you [21:19:33 CET] <JEEB> just read the fucking list you piece of shit [21:19:44 CET] <alexpigment> well that escalated quickly... [21:19:45 CET] <JEEB> sorry, but you've been around for long enough [21:20:29 CET] <JEEB> alexpigment: it just pisses me off that after you've even linked the correct'ish spot on the TOC and then noted the actual specific point you still get "there's nothing like I need here" [21:20:55 CET] <alexpigment> no, i get it. i saw the tension yesterday too. you should just actually add him to your ignore list [21:21:03 CET] <faLUCE> JEEB: I wrote: [21:18] <faLUCE> JEEB: sorry, I did not read "sine" [21:21:19 CET] <faLUCE> JEEB: be calm [21:21:41 CET] <JEEB> alexpigment: he's been here for months and even used the API IIRC [21:22:17 CET] Action: JEEB goes back to stabbing himself with google build systems [21:22:25 CET] <furq> oh wow, a new build system [21:22:29 CET] <furq> just what we've always needde [21:22:30 CET] <furq> ed [21:22:31 CET] <faLUCE> JEEB: are you just stupid or even mad? [21:23:04 CET] <JEEB> weren't you the guy doing "low latency streaming" with lavf+lavc? [21:23:06 CET] <furq> well, i tried [21:23:26 CET] <JEEB> pretty sure I'm not making it up that a person with your nickname has been here for months [21:23:31 CET] <alexpigment> furq: it was a good attempt [21:23:42 CET] <furq> now to sit here and pretend like i'm not going to extremely enjoy this [21:23:50 CET] Action: alexpigment grabs popcorn [21:24:51 CET] <JEEB> around --- Day changed Thu Feb 18 2016 [21:25:27 CET] <JEEB> anyways, really. back to stabbing myself and others with gclient/ninja [21:28:12 CET] <faLUCE> JEEB: you should see a doctor, believe me [21:35:19 CET] <ZeroWalker> hmm [21:35:34 CET] <ZeroWalker> let's see if i can figure this out [21:37:09 CET] <JEEB> ZeroWalker: it shouldn't be too hard [21:37:23 CET] <JEEB> just make sure you have an msys2 shell with MSVC's cl and link in the PATH [21:38:36 CET] <ZeroWalker> was a long time i did this stuff. But i want to begin with installing this: https://sourceforge.net/projects/msys2/ ? [21:39:30 CET] <JEEB> http://www.msys2.org/ [21:39:45 CET] <JEEB> the least retarded msys environment, and you will want the x86_64 one generally [21:40:37 CET] <ZeroWalker> ah, yeah always been confused by all these versions, to me all this stuff is a total mess, link appreciated [21:41:22 CET] <JEEB> I still haven't moved to msys2 myself since the basic tools I've got from original msys (which are ancient) still work and I've been switching the toolchain myself manually [21:42:49 CET] <ZeroWalker> oh, or well i say oh, but not really sure what this implies. But, what does msys2 have that the old one doesn't? (i am not even sure what msys lol;P) [21:43:10 CET] <JEEB> msys2 has a nicer package manager and isn't awfully outdated [21:43:21 CET] <JEEB> msys bases on ancient times' cygwin [21:43:27 CET] <JEEB> while msys2 bases on relatively recent cygwin [21:44:19 CET] <ZeroWalker> Ah i see [21:44:47 CET] <BtbN> Why not just use actual cygwin then, if it bases on it anyway? [21:45:45 CET] <JEEB> BtbN: good question but most people do mingw-w64 builds and MSVC builds in msys instead of cygwin. probably because cygwin tries even harder to be not windows [21:45:49 CET] <JEEB> like windows paths etc [21:45:58 CET] <Cracki> ffmpeg bindings/ffi for use in python, recommendations? [21:46:12 CET] <BtbN> Cygwin has proven very useful for me. [21:46:18 CET] <JEEB> sure, I use it too [21:46:27 CET] <BtbN> You can just install mingw compilers, and get rather normal binaries [21:46:29 CET] <JEEB> this very terminal window I write this text into is on cygwin [21:46:33 CET] <BtbN> But I'm just using MSVC in it now. [21:46:41 CET] <JEEB> oh, MSVC works in it too? cool [21:46:48 CET] <ZeroWalker> i have used cygwin before, i kinda like that it was "automated", but it was messy and required cygwin dll for everything which i wasn't a fan of [21:46:49 CET] <JEEB> oh, right. probably not a surprised :P [21:46:58 CET] <BtbN> Well, just need to get the environment variables into it [21:46:59 CET] <JEEB> ZeroWalker: yes if you build with the cygwin compiler [21:47:15 CET] <ZeroWalker> oh you can use msvc, that's neat [21:47:16 CET] <JEEB> BtbN: aye. I guess I've just set up my ancient msys environment with the PATH [21:47:27 CET] <BtbN> it needs quite a bit more stuff than PATH [21:47:29 CET] <JEEB> which is why I'm not using cygwin for it [21:47:36 CET] <BtbN> You just launch the cygwin stuff from an MSVC terminal, and it works [21:47:47 CET] <JEEB> vsvars32 [21:47:55 CET] <BtbN> I made myself a cygwin alias that does that [21:47:57 CET] <JEEB> I have that in my msys.bat [21:48:15 CET] <BtbN> So I can just type vc32 or vc64, and get my environment [21:48:39 CET] <JEEB> anyways, both environments provide you with the necessary tooling [21:49:09 CET] <ZeroWalker> hmm, so wait do i do that with msys2 as well, just launch it from msvc terminal? [21:49:20 CET] <JEEB> run the msys_shell.bat from the VS2017 prompt [21:49:22 CET] <Cracki> would swig-generated language bindings within the source tree be something the community accepts? [21:49:28 CET] <ZeroWalker> kk [21:49:29 CET] <JEEB> Cracki: no [21:49:46 CET] <Cracki> I just want any kind of decent bindings for python [21:49:47 CET] <JEEB> Cracki: generally I recommend you do it like the rust bindgen stuff does it [21:49:59 CET] <JEEB> which generates bindings in the build system [21:50:03 CET] <Cracki> preferably not rolling my own, duplication of effort and such [21:50:05 CET] <JEEB> so it's always up-to-date to the version [21:50:08 CET] <BtbN> ffmpeg won't accept anything that's not C. So any kind of bindings will always be 3rd party [21:50:21 CET] <JEEB> also man, I remember using swig [21:50:23 CET] <JEEB> it was awful [21:50:32 CET] <JEEB> I just ended up writing the boilerplate myself [21:50:35 CET] <Cracki> JEEB, don't take me literally. I don't care about the how, I care about having python bindings at all [21:50:52 CET] <JEEB> I think vlc uses a custom python script for it [21:50:59 CET] <JEEB> for libvlc, though [21:51:04 CET] <JEEB> so you could take a look at that [21:51:16 CET] <Cracki> so there is no feasible existing solution to bindings [21:51:22 CET] <Cracki> I'd have to dissect what they did [21:51:27 CET] <ZeroWalker> okay, did, and it opens the msys2 terminal, is that all, can i now do like ./configure and stuff on the ffmpeg source;P? [21:51:44 CET] <JEEB> ZeroWalker: check that cl and link are the MSVC tools [21:51:53 CET] <furq> Cracki: https://github.com/mikeboers/PyAV [21:51:58 CET] <JEEB> with `which cl` and `which link` [21:52:16 CET] <Cracki> furq, I assume it's maintained well? [21:52:17 CET] <JEEB> ZeroWalker: if yes, then you will probably want to install git, yasm [21:52:22 CET] <furq> no idea, i've never used it [21:52:38 CET] <ZeroWalker> hmm, says "no cl" [21:52:40 CET] <Cracki> that's bad. I have already found several efforts such as pyav [21:52:53 CET] <ZeroWalker> and link says "/usr/bin/link" [21:52:55 CET] <Cracki> I'm really looking for endorsements from people who've used the libs [21:53:18 CET] <JEEB> yes, many have done bindings but they generally tend to end up outdated which is why you need to find something that generates them on the run [21:53:27 CET] <JEEB> otherwise they will always be out-of-date [21:53:31 CET] <Cracki> _I am ok with generated bindings_ [21:53:44 CET] <JEEB> yes, just saying how the status is [21:54:07 CET] <JEEB> I think your best bet would be to look at the vlc script [21:54:12 CET] <Cracki> so how are bindings generated? [21:54:15 CET] <Cracki> nvm [21:54:15 CET] <JEEB> since that parses their headers [21:54:35 CET] <Cracki> not sure I trust custom-rolled header parsing, but oh well [21:54:50 CET] <JEEB> sure, if it uses libclang that'd be best [21:54:56 CET] <JEEB> never looked at that script tbqh [21:55:08 CET] <JEEB> just know that it's there [21:55:22 CET] <JEEB> and it seemed like the least retarded way to do python mappings [21:55:29 CET] <Cracki> ideally i'd like to see someone caring about maintaining the neccessary build structure to generate bindings in *some* way [21:56:20 CET] <JEEB> well, if someone would make a generic enough thing then that would be a pip package, and then the build script for a package would require the headers and run that tool during the build phase [21:56:22 CET] <BtbN> you seem to care, so go ahead [21:56:32 CET] <JEEB> nothing that would IMHO go into FFmpeg main [21:56:38 CET] <Cracki> I wish someone else cared before me. [21:57:01 CET] <JEEB> of course :P [21:57:07 CET] <JEEB> so do all of us [21:57:15 CET] <JEEB> I was happy to learn of bindgen for rust [21:57:20 CET] <JEEB> and even more happy when I got it to work [21:57:30 CET] <Cracki> >_> if only I care, it'll exist in my little world of software, and nobody else benefits [21:57:56 CET] <Cracki> or it'll go the way of all the other python bindings, more or less maintained [21:58:00 CET] <JEEB> well, someone has to care and be the progenitor for everything. whether or not it gets used by others is a separate thing [21:58:09 CET] <Cracki> ... or useless on anything other than linux [21:58:13 CET] <BtbN> Can always just dlopen the library and dig your way through it that way [21:58:21 CET] <Cracki> yes I can use ctypes, but I'd rather not [21:58:30 CET] <Cracki> or use ctypes, but generate the boilerplate [21:58:40 CET] <JEEB> yea, that's what the vlc script does [21:58:45 CET] <ZeroWalker> okay seems to work, had to uncomment a line in the bat file. though it seems to point to the x86 cl weirdly enough [21:58:54 CET] <JEEB> ZeroWalker: 'gratgs [21:58:59 CET] <JEEB> *'grats [21:59:02 CET] <ZeroWalker> c/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.10.25017/bin/HostX86/x86/cl [21:59:15 CET] <JEEB> ZeroWalker: and for link you might have to remove/move the msys link tool [21:59:37 CET] <ZeroWalker> ah [22:00:15 CET] <Cracki> oh hell, that beast is looong http://git.videolan.org/?p=vlc/bindings/python.git;a=blob_plain;f=generated… [22:00:25 CET] <ZeroWalker> okay it points to msvc now for link as well:) (though x86) [22:00:45 CET] <JEEB> ok, now just install git and yasm in msys2 [22:00:55 CET] <ZeroWalker> don't i want it to point to x64? [22:00:57 CET] <JEEB> and git clone https://git.videolan.org/ffmpeg.git [22:01:07 CET] <JEEB> ZeroWalker: you could do that as well, but you could just get rolling for now [22:01:18 CET] <furq> --depth=1 for god's sake [22:01:37 CET] <ZeroWalker> well i need it to be x64 for my usercase, but if it's not hard to change i guess i can just move on to get it working [22:02:02 CET] <JEEB> yea, since the difference would just be to load msys2 from the other MSVS shell [22:02:20 CET] <JEEB> and I think both 32bit and 64bit MSVC tools could build both? [22:02:44 CET] <ZeroWalker> ah [22:03:17 CET] <ZeroWalker> not that familiar with msvc terminal, though i have used it once and i can set it to one or the other, i just launched it so it might just be 32bit per default [22:03:37 CET] <ZeroWalker> to install yasm, do i just add it to the bin folder (as yasm.exe)? [22:03:47 CET] <JEEB> msys2 has a package manager [22:03:51 CET] <JEEB> pacman [22:03:57 CET] <JEEB> you can install git and yasm from it [22:03:59 CET] <ZeroWalker> oh [22:04:01 CET] <ZeroWalker> nice [22:04:18 CET] <JEEB> http://www.msys2.org/7_msys2-install-freely.png [22:04:18 CET] <ZeroWalker> pacman, the one you can always trust [22:04:34 CET] <ZeroWalker> ah thanks [22:04:54 CET] <JEEB> I've never liked the cryptic options for pacman (it comes from arch linux), but otherwise I've seen no issues with it [22:05:31 CET] <ZeroWalker> do i want any of those options? (i see -S, which i assume might be Silent?) [22:05:40 CET] <JEEB> -S is actually install [22:05:44 CET] <JEEB> welcome to pacman [22:05:46 CET] <ZeroWalker> that makes no sense [22:05:52 CET] <ZeroWalker> i trusted you pacman [22:06:01 CET] <JEEB> now you know why I said "cryptic options" [22:06:07 CET] <ZeroWalker> indeed xd [22:06:23 CET] <JEEB> little y was something about updating the caches? [22:06:24 CET] <JEEB> not sure [22:06:37 CET] <JEEB> so you ended up with something like pacman -Syu package_name [22:06:39 CET] <ZeroWalker> totally logical ofcourse [22:07:08 CET] <JEEB> but if you looked at the arch wiki you would probably find a ton of explanations :P [22:07:19 CET] <ZeroWalker> probably xd [22:07:22 CET] <JEEB> so while you can't remember the darn things arch wiki would help as long as you have a browser [22:07:33 CET] <JEEB> https://wiki.archlinux.org/index.php/pacman [22:08:08 CET] <ZeroWalker> The goal of pacman is to make it possible to easily manage packages, however the options are cryptic and can only be understood by veterans. [22:09:17 CET] <furq> christ don't say that pacman has cryptic options [22:09:27 CET] <ZeroWalker> hmm is ffmpeg git down? [22:09:31 CET] <furq> i can hear them descending on the channel already [22:09:43 CET] <ZeroWalker> well cryptic isn't neccesarily bad [22:09:47 CET] <JEEB> nope [22:09:50 CET] <ZeroWalker> hmm [22:09:51 CET] <JEEB> https://git.videolan.org/git/ffmpeg.git seems to be online [22:09:58 CET] <JEEB> at least the web interface for it [22:10:02 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=summary [22:10:03 CET] <furq> ready to tell us "ah, but did you know, you can remove packages with apt-get install -packagename, THEREFORE ARCH IS BETTER" [22:10:18 CET] <furq> i don't know why i'm now doing their job for them. i'll stop [22:10:32 CET] <ZeroWalker> hmm [22:10:36 CET] <haroldp> I have an ffmpeg command-line that is converting an rtsp stream from a crappy netcam to rtmp stream. I can end the output to a file and get a valid mp4 file. Now I'm having trouble getting nginx to serve it. I set up nginx with the rtmp module, configured server and app (probably wrong, heh), and then try to hit the stream with VLC. no errors on client or server. no stream. [22:10:54 CET] <ZeroWalker> okay this one seems to work [22:11:04 CET] <ZeroWalker> hmm, maybe i copied the old link wrong or something [22:11:11 CET] <JEEB> or I just wrote it wrong [22:11:14 CET] <JEEB> I didn't copypasta it at first [22:11:20 CET] <furq> haroldp: try opening it with ffmpeg/ffplay [22:11:23 CET] <furq> that should at least give some errors [22:11:38 CET] <furq> ffmpeg -v debug -i rtmp://... -f null - [22:11:44 CET] <haroldp> ok. I'll try to install ffplay somewhere [22:11:46 CET] <ZeroWalker> the i put all blame on you, you should be ashamed! [22:11:53 CET] <ZeroWalker> or unshamed? [22:12:10 CET] <Cracki> well, thanks. I'll figure this out from here [22:12:53 CET] <JEEB> huh [22:12:54 CET] <JEEB> warning: terminate MSYS2 without returning to shell and check for updates again [22:12:55 CET] <JEEB> warning: for example close your terminal window instead of calling exit [22:13:09 CET] <JEEB> msys2 sounds like fun with how it tries to do cli package management [22:13:10 CET] <JEEB> I guess [22:14:35 CET] <JEEB> but at least it has newer tooling than my olden msys2 thing [22:15:09 CET] <BtbN> package management from within the environment just doesn't work on Windows [22:15:17 CET] <BtbN> Because of unavoidable file locking [22:15:20 CET] <JEEB> yes [22:15:47 CET] <JEEB> also I think you could avoid it, but only by windows APIs instead of the "standard" ones. plus I think binaries would get locked anyways [22:16:29 CET] <obamoose> Hello [22:16:42 CET] <obamoose> Can someone help me figure out how to turn my stream into an eternal stream [22:17:21 CET] <obamoose> that just keeps on playing the files I add on the end [22:17:27 CET] <obamoose> This is my current config: [22:17:33 CET] <obamoose> http://pastebin.com/1PP7S6ig [22:22:49 CET] <xtina> Hello! I'm trying to understand if I can increase my ALSA buffer size over 65536; I'm unable to do so. does anyone know if this is a hardware constraint? [22:32:19 CET] <alexpigment> xtina: i don't have a clue, but 65536 = 64 x 1024 [22:32:58 CET] <xtina> @alexpigment: yes, which makes me suspect that the ALSA buffer size does have an upper limit [22:33:02 CET] <xtina> i've never seen a value over 65536 [22:34:29 CET] <alexpigment> yeah, i don't know enough about ALSA (been a while since I used linux regularly) [22:34:58 CET] <haroldp> furq: the ffmpeg command you suggested just hangs after, "Sending play command for 'cam1'". Nothing after that untill I ^c [22:37:16 CET] <ZeroWalker> ./configure: line 1420: cmp: command not found [22:37:41 CET] <ZeroWalker> i get this, i installed pkg-config as well as it seemed to need it. but not sure what this error is about [22:38:17 CET] <JEEB> diffutils [22:38:26 CET] <alexpigment> xtina: google isn't retuning anything useful when searching for 64mb alsa buffer limit [22:38:38 CET] <alexpigment> is it possible your audio card is the limiting factor? [22:38:45 CET] <JEEB> ZeroWalker: diffutils is the package name that provides cmp [22:38:46 CET] <JEEB> just fyi [22:39:00 CET] <JEEB> cmp [22:39:03 CET] <ZeroWalker> ah, thanks, what would i ever do without you [22:39:36 CET] <JEEB> you would have started typing "msys2 cmp" and gotten "msys2 cmp not found" [22:40:32 CET] <ZeroWalker> oh [22:40:49 CET] <ZeroWalker> but i want it to be melodramatic;( [22:43:40 CET] <xtina> @alexpigments: yea, google doesn't tell me anything. it's possible [22:47:46 CET] <alexpigment> xtina: did you see this page? https://bbs.archlinux.org/viewtopic.php?id=171477 [22:47:55 CET] <alexpigment> perhaps there's a hint somewhere in there [22:48:43 CET] <alexpigment> http://stackoverflow.com/questions/43009246/does-alsa-buffer-size-have-a-ha… [22:48:44 CET] <alexpigment> also that [22:52:19 CET] <ZeroWalker> hmm, i looks like the configure succeeds, but i can't "make", so i guess it doesn't? [22:52:59 CET] <JEEB> ah, fun. maybe you're missing good ol' make? [22:53:13 CET] <JEEB> yes, funny enough that's not installed by default [22:53:19 CET] <JEEB> package name is make [22:58:12 CET] <alexpigment> this is a pretty exhaustive compilation guide by JEEB here. i'm going to have to save this chat log for future reference :) [22:58:23 CET] <alexpigment> (appreciate the info as a spectator) [22:58:30 CET] <ZeroWalker> oh, yeah i thought it would be [22:59:05 CET] <furq> this is why i just cross-compile [22:59:10 CET] <alexpigment> same [22:59:22 CET] <ZeroWalker> instead of make? [22:59:54 CET] <haroldp> furq: got any other ideas for debugging this? :) [23:00:16 CET] <furq> pastebin your ffmpeg command (the one streaming to nginx) and maybe your nginx config [23:00:41 CET] <JEEB> furq: tbqh this ain't too different from cross-compilation on *nix [23:00:51 CET] <furq> msys is just generally a bit of a pain [23:01:06 CET] <JEEB> if your distro doesn't install make, diffutils, yasm, git by default you install the same packages [23:01:26 CET] <JEEB> the only extra requirement is to have the msys bat run from MSVS's thing [23:01:27 CET] <JEEB> vOv [23:03:55 CET] <faLUCE> can ffmpeg/libav compiled WITHOUT aac support? [23:04:08 CET] <furq> --disable-encoder=aac --disable-decoder=aac [23:04:29 CET] <faLUCE> thnks furq [23:04:58 CET] <JEEB> furq: I do agree that *nix is faster with fork() n' all tho :D [23:05:10 CET] <JEEB> anyways, I guess this is weekend so time to install VS2017 on this box finally [23:05:27 CET] <haroldp> furq: here's my nginx conf. The ffmpeg comamand is exec-ed from there: http://pastebin.com/PKXDCUvj [23:06:11 CET] <furq> does anything show up in error.log [23:06:18 CET] <haroldp> nada [23:07:20 CET] <haroldp> I'm pretty sure it's something wrong with my conf. First time setting something like this up [23:07:50 CET] <furq> you might need "allow play all" [23:07:56 CET] <furq> in rtmp{} [23:07:59 CET] <haroldp> within what black? [23:08:02 CET] <haroldp> thanks [23:08:17 CET] <furq> the docs don't mention the default, but i have that so i assume it's there for a reason [23:09:39 CET] <haroldp> ok, added, restarted, still stalling at ' Sending play command for 'cam1'' [23:10:10 CET] <haroldp> my command is like, ffmpeg -v debug -i rtmp://10.0.0.42/live360p/cam1 [23:14:28 CET] <furq> actually i'm not sure if that's how exec works [23:15:01 CET] <haroldp> ok. Lifted it from various examples I found [23:15:02 CET] <furq> you might want to use exec_static [23:15:10 CET] <haroldp> I'll try that [23:15:17 CET] <furq> outside of the application block [23:18:19 CET] <haroldp> ooh, actually getting an error message in teh log now [23:18:28 CET] <haroldp> 2017/03/24 15:17:49 [alert] 15896#103419: kevent() error on 9 filter:-1 flags:4000 (9: Bad file descriptor) [23:19:44 CET] <haroldp> getting that like every 5 seconds, heh [23:21:33 CET] <ZeroWalker> wasn't --enable-shared the command for making the dlls ? [23:21:43 CET] <JEEB> yes [23:21:48 CET] <JEEB> during configure [23:21:58 CET] <JEEB> also a little hint, use out-of-tree building [23:22:00 CET] <ZeroWalker> yeah did that, but ended up with ffmpeg.exe:( [23:22:08 CET] <ZeroWalker> what's that? [23:22:09 CET] <JEEB> yes, you always also get the exe [23:22:14 CET] <JEEB> unless you disable the binaries [23:22:40 CET] <JEEB> out-of-tree just means that you call the configure outside of the source tree [23:23:12 CET] <JEEB> so if you have ffmpeg sources under a directory called "ffmpeg", you can a directory called "build" next to it and then run "../ffmpeg/configure"... and that works :) [23:23:20 CET] <ZeroWalker> not really sure what that means. i just call ./configure inside the git clone map [23:23:21 CET] <ZeroWalker> Oh [23:23:36 CET] <JEEB> that way to reset the situation you can just remove that directory and re-create it [23:23:59 CET] <JEEB> that said, if you already once configured within you'll have to run `git clean -dfx` [23:24:01 CET] <ZeroWalker> that sounds neat, as now it just compiles it in the middle of everything [23:24:04 CET] <JEEB> to clean the ffmpeg source directory :) [23:24:09 CET] <ZeroWalker> ah:d [23:24:42 CET] <JEEB> also, to utilize the libraries you made, you will also have to install [23:24:54 CET] <JEEB> for that I recommend utilizing the --prefix option [23:25:16 CET] <JEEB> in msys2 you can probably just do --prefix=/home/username/ownapps/ffmpeg or so [23:25:30 CET] <JEEB> and then after you have built it with make and it succeeded, you can run `make install` [23:25:38 CET] <JEEB> that way you get the correct directory structure [23:25:50 CET] <JEEB> you will have lib/ bin/ include/ etc [23:25:53 CET] <JEEB> within your prefix [23:27:27 CET] <ZeroWalker> wait, i want to install those into msys2? i thought you only did that if it's used withing msys or the compiler or something [23:27:45 CET] <JEEB> the install is needed for re-usage of the libraries and headers [23:27:48 CET] <JEEB> in general [23:27:53 CET] <JEEB> that's why I noted --prefix [23:28:00 CET] <JEEB> so you have your little directory with just ffmpeg [23:28:04 CET] <alexpigment> haroldp: i'm about to head out and it's not clear if furq is still around or not, but i found some people who seem to be running into similar issues. perhaps it's worth a look if furq doesn't come back [23:28:07 CET] <alexpigment> https://www.google.com/search?q=kevent+()+error+on+9+filter%3A+-1+flags%3A4… [23:28:28 CET] <haroldp> yeah, I was looking at the same search [23:28:32 CET] <alexpigment> the 4th result seems to be particularly relevant [23:28:36 CET] <JEEB> then in that other thing you'd be using FFmpeg's libraries with you can specify <that prefix directory>/lib for libraries and /include for header search paths [23:28:40 CET] <JEEB> if you get what I say :P [23:29:13 CET] <haroldp> one guy is on FreeBSD same as me, but suggests redirecting stdin and stdout to /dev/null but that didn't help me at all. Still getting the error. [23:29:35 CET] <alexpigment> yeah, that's the one i was looking at [23:29:41 CET] <alexpigment> oh well, figured i'd throw that out there just in case [23:29:43 CET] <alexpigment> good luck! [23:29:52 CET] <haroldp> thanks anyway [23:30:46 CET] <haroldp> was trying to copy something like this: https://www.vultr.com/docs/setup-nginx-rtmp-on-ubuntu-14-04 [23:31:27 CET] <furq> haroldp: change ffmpeg to /usr/local/bin/ffmpeg [23:33:47 CET] <ZeroWalker> hmm [23:34:01 CET] <oftc_ftw> hi all. i want to convert some old family videos that already were converted from VHS to DVD. Now I have a bunch of files that I want to upload to my cloud storage and ideally want to be able to play it in my browser (HTML5 player). I guess this leaves webm/VP9 or mp4/H.264 as best possibilities, right? but i also want to make sure i don't have information loss, i.e. artifacts new that were not already there. are these codecs capable [23:34:01 CET] <oftc_ftw> of such a "lossless" conversion? [23:34:26 CET] <furq> both of them do lossless but i don't think browsers will play that back [23:34:26 CET] <oftc_ftw> *new artifacts [23:34:37 CET] <oftc_ftw> oh :( [23:35:04 CET] <oftc_ftw> well, i could at least try i guess? is there a special command line parameter for lossless in ffmpeg? [23:35:16 CET] <furq> -c:v libx264 -qp 0 [23:35:27 CET] <furq> i just tested and that definitely doesn't work in browsers [23:35:35 CET] <oftc_ftw> that was quick :D [23:35:41 CET] <oftc_ftw> ok, i' [23:35:44 CET] <furq> or at least not in mine [23:35:53 CET] <furq> maybe it'll work in something which uses lavc for decoding [23:35:56 CET] <oftc_ftw> ok, i'd rather have it lossless and not play it in a browser... [23:36:13 CET] <furq> don't convert it at all then [23:36:17 CET] <klaxa> ^ [23:36:18 CET] <haroldp> I swear, if it's a dumb PATH fail... :) [23:36:30 CET] <furq> lossless h264 will be much bigger than a dvd source [23:36:38 CET] <oftc_ftw> right, i will try if it works and if not upload the originals. thanks guys! [23:37:12 CET] <furq> what cloud storage is this [23:37:15 CET] <oftc_ftw> furq: btw, are you implying h264 is better than vp9? [23:37:25 CET] <oftc_ftw> "better" in any way [23:37:33 CET] <furq> x264 is better than libvpx in some ways [23:37:39 CET] <oftc_ftw> ok, thanks :) [23:37:41 CET] <furq> mostly speed and compatibility [23:38:10 CET] <furq> also i can't remember how to do lossless vp9 off the top of my head [23:39:12 CET] <furq> but yeah depending on the cloud storage it might generate browser-playable videos for you from a dvd source while keeping the originals [23:39:23 CET] <furq> i believe google drive can do that [23:40:45 CET] <oftc_ftw> nextcloud can do it as well, i have a private server [23:40:56 CET] <haroldp> furq: holy shit. this is kinda working. [23:40:58 CET] <oftc_ftw> thanks again, i will simply try it with your parameters [23:41:07 CET] <furq> well yeah those lossless files will be huge [23:41:19 CET] <oftc_ftw> :) [23:41:21 CET] <furq> probably 3-5x bigger than the source [23:41:52 CET] <furq> it's probably less hassle to back up the dvds and then make lossy copies for browser viewing [23:42:04 CET] <haroldp> anyway, VLC got at leats one frame out of it, heh [23:44:47 CET] <xtina> hey guys, i know this isn't really the right chat for this, but is anyone here familiar with mmap? [23:44:58 CET] <xtina> i'm looking for a way to read/write from memory with a large buffer (say, 50MB) [23:45:11 CET] <xtina> i'm currently using a FIFO pipe but that has an upper buffer limit of 1MB. i'm hitting htat limit. [23:45:46 CET] <xtina> i can't read/write from disk quickly enough for my needs (realtime streaming with ffmpeg) [23:50:50 CET] <kerio> how's that gonna help you [23:57:01 CET] <xtina> @kerio: my 1mb buffer is currently filling up if i have low connectivity for a bit of time [23:57:11 CET] <xtina> i don't use more than 100mb of ram for streaming and i have 512 [23:57:28 CET] <xtina> so i'd like to have a bigger leeway to store audio packets if ffmpeg isn't reading them fast enough [23:57:52 CET] <xtina> i know it's not a 100% solution but if i could use a 100mb buffer, i could get 100x more leeway which is good enough [23:57:55 CET] <kerio> can you use mbuffer [23:57:56 CET] <kerio> ? [23:58:17 CET] <xtina> hmm, let me look into it [00:00:00 CET] --- Sat Mar 25 2017

1 0

ffmpeg-devel.log.20170323
by burek 24 Mar '17

24 Mar '17

[09:39:44 CET] <cone-520> ffmpeg 03wm4 07master:156bd8278f40: lavc: Add hwaccel_flags field to AVCodecContext [09:39:44 CET] <cone-520> ffmpeg 03wm4 07master:7e4ba776a224: lavc: vdpau: Add support for new hw_frames_ctx and hw_device_ctx API [11:14:33 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:5cc0057f4910: lavu: remove the custom atomic API [11:14:34 CET] <cone-520> ffmpeg 03Clément BSsch 07master:d521258b19a5: Merge commit '5cc0057f4910c8c72421b812c8f337ef6c43696c' [11:16:59 CET] <cone-520> ffmpeg 03Mark Thompson 07master:314b421dd891: vaapi_encode: Decide on GOP setup before initialising sequence parameters [11:17:00 CET] <cone-520> ffmpeg 03Mark Thompson 07master:17a0f9481cf0: vaapi_h264: Fix CFR mode with frame_rate set in AVCodecContext [11:17:01 CET] <cone-520> ffmpeg 03Mark Thompson 07master:ec17ab381ede: vaapi_h264: Write bitstream restriction fields [11:17:02 CET] <cone-520> ffmpeg 03Mark Thompson 07master:fc30a90898e4: vaapi_h265: Fix slice header writing [11:17:03 CET] <cone-520> ffmpeg 03Mark Thompson 07master:b8cac1e83066: vaapi_h265: Fix buffering parameters [11:17:04 CET] <cone-520> ffmpeg 03Clément BSsch 07master:553d8a9ecf16: Merge commit 'b8cac1e83066aa87e8402c146c81b77a11b5eec3' [11:17:13 CET] <wm4_> ubitux: I assume you skipped it for now [11:17:36 CET] <ubitux> yes, see http://git.videolan.org/?p=ffmpeg.git;a=commit;h=d521258b19a54f4ada61d24b9a… [11:17:58 CET] <ubitux> it's added to the libav merge doc [11:18:03 CET] <ubitux> won't be forgotten [11:19:02 CET] <wm4_> ok [11:19:05 CET] <wm4_> makes sense [11:19:37 CET] <cone-520> ffmpeg 03Mark Thompson 07master:eaaaabf6c933: hwcontext_vaapi: Enable P010 support [11:19:38 CET] <cone-520> ffmpeg 03Clément BSsch 07master:c4f613fe5120: Merge commit 'eaaaabf6c93321cdb78bf61dc383cf515ec12e07' [11:20:42 CET] <cone-520> ffmpeg 03Mark Thompson 07master:5a5df90d9c05: vaapi_h265: Add main 10 encode support [11:20:43 CET] <cone-520> ffmpeg 03Clément BSsch 07master:1a5631dc716e: Merge commit '5a5df90d9c05d86d9b0564b8b40b6d64a324df5e' [11:21:11 CET] <ubitux> btw, thanks for everyone who did cherry-picks in the past [11:21:19 CET] <ubitux> it makes the merges much simpler :p [11:23:18 CET] <wm4_> I guess the interesting parts get cherry-picked [11:24:00 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:310c55f1799d: pixfmt: Document alternative names for smpte 431 and 432 [11:24:01 CET] <cone-520> ffmpeg 03Clément BSsch 07master:a1f6b1d9d816: Merge commit '310c55f1799deab395319471a75c528d0fa7b30d' [11:26:46 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:bad4aad4037f: avidec: Do not special case palette on big-endian [11:26:47 CET] <cone-520> ffmpeg 03Clément BSsch 07master:554cc43ac6c3: Merge commit 'bad4aad4037f59ba0ad656164be9ab8f7a0fa2d4' [11:27:22 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:497c087939e3: avidec: Set palette alpha as fully opaque [11:27:23 CET] <cone-520> ffmpeg 03Clément BSsch 07master:76e21e83acbe: Merge commit '497c087939e32b26b792515d2dbc7e22561203f7' [11:28:23 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:b8d5070db631: avcodec: Document AV_PKT_DATA_PALETTE side data type [11:28:24 CET] <cone-520> ffmpeg 03Clément BSsch 07master:7b3a3e6276c4: Merge commit 'b8d5070db6313f985562865edcfd08a01c2d7503' [11:37:09 CET] <ubitux> can someone sync the fate samplse please? in particular /rscc/8bpp.avi [11:37:13 CET] <ubitux> nevcairiel? michaelni? [11:37:19 CET] <nevcairiel> sure [11:37:23 CET] <ubitux> thanks :) [11:38:32 CET] <nevcairiel> not sure w hat else might be new, so i'll just add that one [11:38:59 CET] <ubitux> i'll poke you if i need more [11:39:06 CET] <nevcairiel> its there now [11:39:14 CET] <ubitux> perfect, thanks :) [11:40:24 CET] <cone-520> ffmpeg 03Carl Eugen Hoyos 07master:c19830aa2c19: rscc: Support palette format [11:40:25 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:dc3fe45fca9c: fate: Add test for rscc palette [11:40:26 CET] <cone-520> ffmpeg 03Clément BSsch 07master:5f044d237263: Merge commit 'c19830aa2c19f9713b612f7e2fdb437df91ba266' [11:40:27 CET] <cone-520> ffmpeg 03Clément BSsch 07master:dffa4ec1ed20: Merge commit 'dc3fe45fca9c10c4af6bfcf48eb7b81968892ef9' [11:43:57 CET] <nevcairiel> neat we're at the hevc idct patches soon [11:44:19 CET] <nevcairiel> (contrary to previous hevc patches, those should actually still fit) [11:44:22 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:a451324dddf5: vp9: ignore reference segmentation map if error_resilience flag is set. [11:44:23 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:c935b54bd6a1: checkasm: add VP9 loopfilter tests. [11:44:24 CET] <cone-520> ffmpeg 03Clément BSsch 07master:a692724c5878: vp9lpf/x86: add x86 SSSE3/AVX SIMD for vp9_loop_filter_[vh]_16_16. [11:44:25 CET] <cone-520> ffmpeg 03James Almer 07master:1f451eed606b: vp9lpf/x86: add ff_vp9_loop_filter_[vh]_16_16_sse2(). [11:44:26 CET] <cone-520> ffmpeg 03Clément BSsch 07master:6bea47815891: vp9lpf/x86: add ff_vp9_loop_filter_[vh]_88_16_{ssse3,avx}. [11:44:27 CET] <cone-520> ffmpeg 03James Almer 07master:92d47550ea09: vp9lpf/x86: add an SSE2 version of vp9_loop_filter_[vh]_88_16 [11:44:28 CET] <cone-520> ffmpeg 03Clément BSsch 07master:f2e3d706a16d: vp9lpf/x86: add ff_vp9_loop_filter_h_{48,84}_16_{sse2,ssse3,avx}(). [11:44:29 CET] <cone-520> ffmpeg 03Clément BSsch 07master:0ed21bdc9e7f: vp9lpf/x86: add ff_vp9_loop_filter_[vh]_44_16_{sse2,ssse3,avx}. [11:44:30 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:a6e288d62414: vp9lpf/x86: save one register in loopfilter surface coverage. [11:44:31 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:6411c328a233: vp9lpf/x86: make cglobal statement more conservative in register allocation. [11:44:32 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:6e74e9636b17: vp9lpf/x86: slightly simplify 44/48/84/88 h stores. [11:44:33 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:683da2788e41: vp9lpf/x86: remove unused register from ABSSUB_CMP macro. [11:44:34 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:e4961035b288: vp9lpf/x86: simplify ABSSUM_CMP by inverting the comparison meaning. [11:44:35 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:4ce8ba72f9cb: vp9lpf/x86: move variable assigned inside macro branch. [11:44:36 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:c6375a83d1ad: vp9lpf/x86: store unpacked intermediates for filter6/14 on stack. [11:44:37 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:7c62891efedf: vp9lpf/x86: save one register in SIGN_ADD/SUB. [11:44:38 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:be10834bd9dd: vp9lpf/x86: make filter_44_v work on 32-bit. [11:44:39 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:37637e65907b: vp9lpf/x86: make filter_88_v work on 32-bit. [11:44:40 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:b905e8d2fe03: vp9lpf/x86: make filter_48/84_v work on 32-bit. [11:44:41 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:5bfa96c4b30d: vp9lpf/x86: make filter_16_v work on 32-bit. [11:44:42 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:725a216481c4: vp9lpf/x86: make filter_44_h work on 32-bit. [11:44:43 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:8915320db94c: vp9lpf/x86: make filter_48/84/88_h work on 32-bit. [11:44:44 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:715f139c9bd4: vp9lpf/x86: make filter_16_h work on 32-bit. [11:44:45 CET] <cone-520> ffmpeg 03Clément BSsch 07master:9a23b149c7d8: Merge commit '715f139c9bd407ef7f4d1f564ad683140ec61e6d' [11:47:44 CET] <cone-520> ffmpeg 03Steve Lhomme 07master:be630b1e08eb: d3d11va: Use the proper decoding slice index [11:47:45 CET] <cone-520> ffmpeg 03Clément BSsch 07master:3e40c9560a57: Merge commit 'be630b1e08ebe8f766b1798accd6b8e5e096f5aa' [11:56:16 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:d9dccc03890a: hevc: x86: Refactor IDCT macro declarations [11:56:17 CET] <cone-520> ffmpeg 03Clément BSsch 07master:9954d5b44eec: Merge commit 'd9dccc03890a976dba59d66ed3b5aceeaa33d14c' [11:57:15 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:20abcaa273a6: configure: #include stdint.h as part of libxavs test [11:57:16 CET] <cone-520> ffmpeg 03Clément BSsch 07master:fb477193cd14: Merge commit '20abcaa273a6e77d0a2e1a98c643c73562c6f8f2' [11:59:41 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:5801f9ed245c: h264_intrapred: x86: Update comments left behind in 95c89da36ebeeb96b7146c0d70f46c582397da7f [11:59:42 CET] <cone-520> ffmpeg 03Clément BSsch 07master:4bb4fa28e374: Merge commit '5801f9ed245ca5ebb57b0b5183de7a24aaece133' [12:00:16 CET] <ubitux> wait wat [12:00:24 CET] <ubitux> i should have read a bit further the commit log lol [12:01:47 CET] <ubitux> ah, i guess it's an authorship thing [12:02:00 CET] <ubitux> should i merge the revert? [12:02:09 CET] <ubitux> i think it's related to http://lists.libav.org/pipermail/libav-devel/2016-October/079560.html [12:04:58 CET] <ubitux> i guess it will be re-applied differently later on [12:05:44 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:e4128c08d786: Revert "hevc: x86: Refactor IDCT macro declarations" [12:05:45 CET] <cone-520> ffmpeg 03Clément BSsch 07master:733b13ad666c: Merge commit 'e4128c08d786eb5513578e8c6063671ba03226ab' [12:08:47 CET] <cone-520> ffmpeg 03Yogender Gupta 07master:da2848375a2e: nvenc: Force high_444 profile for 444 input [12:08:48 CET] <cone-520> ffmpeg 03Clément BSsch 07master:464790f10922: Merge commit 'da2848375a2e2121dad9f1e8cbd0ead4e3bf77d6' [12:11:39 CET] <cone-520> ffmpeg 03Yogender Gupta 07master:cbd84b8a51aa: nvenc: Fix error log [12:11:40 CET] <cone-520> ffmpeg 03Clément BSsch 07master:1b2a7f42c0a0: Merge commit 'cbd84b8a51aa656d71b7d6ed44bd89041ff081a8' [12:15:39 CET] <faLUCE> Hello. when I allocate an AVCodecContext* for a decoder, do I have to specify the pixel format (decodec_context->pix_fmt) ? This is absolutely not clear in the API. I opened a MJPEG decoder with codec = avcodec_find_decoder(AV_CODEC_ID_MJPEG) but codec->pix_fmts doesn't contain anything.... [12:16:09 CET] <ubitux> wbs: did 9b2ccafb480 led to glitches or something? [12:16:28 CET] <wm4_> faLUCE: for decoding generally not, but a few obscure decoders need the pixfmt from the demuxer info... anyway, this is offtopic here, go to #ffmpeg [12:16:54 CET] <wbs> ubitux: not reproduced in practice, but a few commits later you'll find checkasm support for aarch64 to detect missing sign extensions [12:17:08 CET] <ubitux> interesting, cool, thanks [12:17:14 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:9b2ccafb480c: aarch64: Add missing sign extension in ff_h264_idct8_add_neon [12:17:15 CET] <cone-520> ffmpeg 03Clément BSsch 07master:739d8c83f2c6: Merge commit '9b2ccafb480c94fd09cfb24306d5296dc013cf5b' [12:17:51 CET] <faLUCE> wm4_: nobody never answers in #ffmpeg. But in this way, how can I know which pixel format is used by the MJPEG decoder? [12:18:27 CET] <wm4_> faLUCE: you know after decoding, also this channel is development _of_ ffmpeg only [12:19:44 CET] <faLUCE> wm4_: I understand, but there's not another place where to ask. You say: " you know after decoding"---> how can I know that? from which struct/container I can pick this info? [12:20:31 CET] <cone-520> ffmpeg 03Alexandra Hájková 07master:e3f941cb03b1: checkasm: add a test for HEVC IDCT [12:20:32 CET] <cone-520> ffmpeg 03Clément BSsch 07master:50bbb674723e: Merge commit 'e3f941cb03b139b866a0ad6dc95fbe1b247d54af' [12:20:41 CET] <wm4_> faLUCE: from the AVFrame, also in your case you could just look at any example or whatever [12:20:48 CET] <faLUCE> thanks wm4_ [12:20:52 CET] <wm4_> of course half of our examples use deprecated APIs or bad practices [12:21:19 CET] <ubitux> patch welcome btw [12:21:54 CET] <ubitux> faLUCE: in exchange for special exclusive support, you're officially registered as responsible for updating the examples in FFmpeg tree [12:21:58 CET] <faLUCE> wm4_: The library is like a Bible, but the examples are really a nightmare, and full of errors and wrappers to wrappers to wrappers. For example encode_aac is completely nonsense [12:22:50 CET] <wm4_> you mean transcode_aac.c? [12:24:03 CET] <faLUCE> [12:21] <ubitux> faLUCE: in exchange for special exclusive support, you're officially registered as responsible for updating the examples in FFmpeg tree <--- I created a C++ library which wraps ffmpeg. I did that by making all the examples (decoding, encoding, resampling etc.) on myself and I would be interested in updating the doc/examples folder, because it is in a very bad state [12:24:35 CET] <faLUCE> I'll do that as soon as I publish my library [12:24:36 CET] <ubitux> main thing required in the examples is to update them to the new API [12:24:47 CET] <ubitux> basically the push/received frame/packet thingy [12:24:59 CET] <wm4_> faLUCE: if you're updating the ffmpeg in-repo examples, feel free to ask anything here [12:25:02 CET] <faLUCE> ubitux: my lib is updated to 3.2 (I use send/receive) [12:25:04 CET] <ubitux> or said differently, fix all the warnings you get when running `make examples` [12:27:41 CET] <faLUCE> wm4_: I had to re-make all the examples in a very simpler way. It's nonsense, IMHO, to have such long examples (aac_transcode.c) which are full of errors, unuseful and obscure generic functions etc. I made examples for reading and encoding h264 from webcamera, for writing muxed data iun memory (through callbacks) etc. Ande they are SHORT [12:28:04 CET] <wm4_> I agree [12:28:08 CET] <faLUCE> anyway, as soon as my lib is finished I'll send you these snippets [12:30:31 CET] <faLUCE> wm4_: for example, I made a code which reads from a raw audio frame (created with arecord on linux), encodes it to AAC, muxed into ADTS and write it into file through the callback. It's very short and useful for users. OK, I'll post it ASAP [12:31:37 CET] <wm4_> if it's C++ we're probably not interested [12:31:45 CET] <faLUCE> wm4_: no, it's plain C [12:31:51 CET] <wm4_> then we're very interested [12:32:48 CET] <faLUCE> wm4_: well, in one/two days I'll give you the code [12:39:14 CET] <wm4_> was this never applied? http://ffmpeg.org/pipermail/ffmpeg-devel/2017-February/207296.html [12:50:49 CET] <wm4_> ubitux: can I push a patch? [12:54:14 CET] <ubitux> wm4_: yeah [12:55:08 CET] <cone-520> ffmpeg 03Jan Berkel 07master:aff80aa4ecad: hls: consistent use of user_agent [12:55:13 CET] <wm4_> done [14:15:59 CET] <Guest60> Hello folks, my name is Koustuv Kanungo [14:17:31 CET] <Guest60> I want to join the Google Summer of Code and do a project under FFmpeg [14:18:06 CET] <Guest60> I'm comfortable with coding in C, but not proficient at signal theory, but I'm willing to learn [14:18:31 CET] <Guest60> Do I need to learn any other skills for doing a project? [14:18:53 CET] <nevcairiel> it depends which task you want to work on [14:19:35 CET] <Guest60> I was thinking about the one on improvement of the Vorbis decoder [14:23:45 CET] <wm4_> kkanungo17: contact whichever mentor is listed [14:23:52 CET] <wm4_> (on the wiki) [14:24:06 CET] <kkanungo17> I did email atomnuker [14:24:18 CET] <kkanungo17> just wanted to make sure [14:24:38 CET] <wm4_> he'll probably reply, unless you accidentally landed in his spam folder or so [14:29:38 CET] <nevcairiel> the vorbis task doesnt list any special requirements, but you should be prepared to learn such things then ;) [14:30:08 CET] <kkanungo17> I am, really looking forward to it :D [14:57:21 CET] <atomnuker> kkanungo17: sorry, didn't have time to respond yesterday [14:57:58 CET] <kkanungo17> its okay [15:05:11 CET] <atomnuker> kierank: that'll not be a small task at all since we have no decoder to test with, and the aac decoder is the audio equivalent of the h264 decoder [15:12:49 CET] <durandal_1707> wasnt it supported by libfdk? [15:14:39 CET] <atomnuker> some fork of it [15:26:15 CET] <cone-520> ffmpeg 03Michael Niedermayer 07master:3182e19c1c29: avcodec/tiff: Check geotag count for being non zero [15:26:16 CET] <cone-520> ffmpeg 03Michael Niedermayer 07master:0f34c0789f85: avcodec/pictordec: runtime error: left shift of 15 by 28 places cannot be represented in type 'int' [15:26:17 CET] <cone-520> ffmpeg 03Michael Niedermayer 07master:4f727fbc7330: avcodec/h264_ps: Fix runtime error: signed integer overflow: 2147483647 + 26 cannot be represented in type 'int' [15:47:55 CET] <cone-520> ffmpeg 03James Almer 07master:005da88c1ee2: avcodec/mediacodec: convert to stdatomic [15:51:45 CET] <cone-520> ffmpeg 03James Almer 07master:05510ec06776: avcodec/videotoolboxenc: remove unused atomic header [15:53:08 CET] <ubitux> is bit depth 12 fundamentally different from bit depth 10 in hevc idct? [15:53:46 CET] <ubitux> i'm wondering if i should add the idct 12 support in our libav merge document in the last section (extra changes for consistency) [15:53:53 CET] <ubitux> since it may be forgotten [15:59:44 CET] <cone-520> ffmpeg 03Alexandra Hájková 07master:112cee0241f5: hevc: Add SSE2 and AVX IDCT [15:59:45 CET] <cone-520> ffmpeg 03Clément BSsch 07master:947230837cb6: Merge commit '112cee0241f5799edff0e4682b9e8639b046dc78' [16:01:25 CET] <BtbN> philipl, thoughts on adding -cqp, to replace the weird -global_quality thing? global_quality isn't even intended to be a public option it seems, and it's used via -q, which does h263 qscale stuff, with very weird results. [16:03:30 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:eb542106029a: swscale: Add missing yuv444p12 swapping [16:03:31 CET] <cone-520> ffmpeg 03Clément BSsch 07master:4c45c866cfbb: Merge commit 'eb542106029a9b28b4f76ff7c181eb4f542da9c4' [16:05:54 CET] <nevcairiel> ubitux: maybe jamrial wants to look into that, he made the idct_dc support 12-bit, which basically didnt require asm changes [16:06:51 CET] <philipl> BtbN: makes sense to me. [16:08:05 CET] <philipl> more intuitive wrt x264. I know global_quality had me scratching my head originally [16:08:24 CET] <BtbN> I have actually no idea why on earth I picked that. [16:08:31 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:14e7e19a90e9: lavc: bsf: Document input/output codecparam alloc/init process [16:08:32 CET] <cone-520> ffmpeg 03Clément BSsch 07master:cc012c46e8b8: Merge commit '14e7e19a90e9b45db7adeb4d40e7f16aa7404f28' [16:08:39 CET] <BtbN> -cqp is in line with how libx264 handles things [16:08:44 CET] <philipl> right [16:09:00 CET] <BtbN> What I'm also confused about is that -cq thing nvidia sent a patch for recently... [16:09:07 CET] <BtbN> It looks like constant quality, but for the VBR mode? [16:09:12 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:e7e5be8635c1: APIchanges: Expand the name of recently added pixel formats [16:09:13 CET] <cone-520> ffmpeg 03Clément BSsch 07master:295450e7f438: Merge commit 'e7e5be8635c1cf0588d2a07e59374135de6da55a' [16:09:31 CET] <philipl> Well, 'constant quality' is variable bitrate :-) [16:09:44 CET] <BtbN> yes, but VBR RC mode rather than CONSTQP RC mode. [16:09:57 CET] <philipl> Which subject? [16:10:18 CET] <BtbN> It's already merged, the patch itself was fine, as it just exposes another option [16:10:28 CET] <BtbN> I just wonder what that option itself does [16:10:38 CET] <BtbN> Or rather, what the difference to constQP is [16:10:39 CET] <philipl> K. Well, they never really explain how all their modes really work. [16:11:07 CET] <philipl> For -cqp - I'd argue that it should also set the i/p/b ratios the same as x264 does [16:11:48 CET] <BtbN> I'd migrate the entire code to use cqp where it currently uses global_quality, and then have one place set cqp from global_quality if it's set, and maybe print a deprecation warning. [16:11:55 CET] <philipl> yes. [16:12:31 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L511 [16:12:34 CET] <philipl> but I mean, today all three are set to the same value when you use global_quality. I'd say have the -2/-3 (or whatever) adjustments happen automatically like in x264 [16:12:43 CET] <BtbN> that's all I can see x264 do with the -cqp setting. What ratios do you mean? [16:12:51 CET] <philipl> They are internal to x264 [16:12:54 CET] <philipl> Not our policy [16:13:01 CET] <BtbN> ah. hm. [16:13:44 CET] <BtbN> https://github.com/mirror/x264/blob/90a61ec76424778c050524f682a33f115024be9… [16:13:46 CET] <BtbN> you mean this? [16:14:12 CET] <philipl> yeah [16:15:01 CET] <BtbN> That basically increases the quality for I frames a bit, and recudes it for B frames [16:15:21 CET] <philipl> right [16:15:32 CET] <BtbN> Kind of makes sense, I guess [16:15:39 CET] <philipl> which seems to be generally considered correct [16:16:15 CET] <philipl> I need to head into the office now. Back in about an hour. [16:23:24 CET] <cone-520> ffmpeg 03Michael Niedermayer 07master:1e93aa69a608: Add GBRP12 pixel format support [16:23:25 CET] <cone-520> ffmpeg 03Clément BSsch 07master:fbd352e07719: Merge commit '1e93aa69a60815d1407a6c34d8da3f83ab193ad5' [16:27:30 CET] <durandal_1707> ubitux: you sure gif can output fine with pal8? [16:27:34 CET] <cone-520> ffmpeg 03Michael Niedermayer 07master:328ea6a9a5ab: swscale: Add input support for 12-bit formats [16:27:35 CET] <cone-520> ffmpeg 03Michael Niedermayer 07master:f59750641afd: swscale: x86: Add some forgotten 12-bit planar YUV cases [16:27:36 CET] <cone-520> ffmpeg 03Luca Barbato 07master:ef3740c3a02b: swscale: Enable GBRP12 output [16:27:37 CET] <cone-520> ffmpeg 03Kieran Kunhya 07master:81f1f6c3f62b: Add GBRAP12 pixel format support [16:27:38 CET] <cone-520> ffmpeg 03Luca Barbato 07master:881477c77bb1: swscale: Add the GBRAP12 output [16:27:39 CET] <cone-520> ffmpeg 03Clément BSsch 07master:6d541424da7b: Merge commit '881477c77bb10c3c62fda111b0f1f3554968bc78' [16:28:30 CET] <ubitux> durandal_1707: mmh, now that i think about it... [16:28:54 CET] <ubitux> yeah indeed it may not due to palette changes accross frames and old colors keeping the same values [16:29:01 CET] <ubitux> or a picture composed of multiple palettes [16:30:04 CET] <durandal_1707> well, if number of colors is greater than 256 [16:30:34 CET] <durandal_1707> we donnt have color count filter [16:30:59 CET] <iive> there are some animations that use same picture but change the palette [16:31:27 CET] <cone-520> ffmpeg 03Sean McGovern 07master:c9527bf3444c: Make the RELEASE file match with the most recent tag [16:31:28 CET] <cone-520> ffmpeg 03Clément BSsch 07master:e7329c0fd55c: Merge commit 'c9527bf3444c5332fa04931d32997308784fc862' [16:35:05 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:7395784ba727: rtmpproto: Check the return from ff_amf_read_string [16:35:06 CET] <cone-520> ffmpeg 03Clément BSsch 07master:36fcbc00765a: Merge commit '7395784ba72742b6daa62d35db4028e09f3fdf06' [16:36:00 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:d6ded94036e4: rtmpproto: Lengthen the filename buffer when receiving streams [16:36:01 CET] <cone-520> ffmpeg 03Clément BSsch 07master:a106b7e8b93f: Merge commit 'd6ded94036e43a04889f4ff2813a7f7dd60b82fe' [16:37:22 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:8b5e0d17e704: rtmpproto: Send chunk size on the network channel [16:37:23 CET] <cone-520> ffmpeg 03Clément BSsch 07master:d1c341f77b01: Merge commit '8b5e0d17e70400eaf5dc3845b5c1df8b2b88d830' [16:38:18 CET] <BtbN> philipl, wouldn't that be basically identical to the logic nvidia added for the init_qp_p? [16:38:18 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:9f23f77a532c: rtmpproto: Don't include the libavformat version as "clientid" [16:38:19 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:7d8d726be7dc: rtmpproto: Don't include a client version in the unencrypted C1 handshake [16:38:20 CET] <cone-520> ffmpeg 03Clément BSsch 07master:ddcd396075df: Merge commit '9f23f77a532ca9c2b7dc4b5328bc413e4f6f5b56' [16:38:21 CET] <cone-520> ffmpeg 03Clément BSsch 07master:8892739a1605: Merge commit '7d8d726be7dc46343ab1c98c339c1ed44bcb07c1' [16:38:23 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L516 [16:38:49 CET] <BtbN> Except that it adds it to both, reducing both I and B frames quality [16:40:38 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:20b75970e43a: file protocol: handle the file: protocol string in file_check [16:40:39 CET] <cone-520> ffmpeg 03Clément BSsch 07master:962e15d0f525: Merge commit '20b75970e43a030f959b17ff2dfd561174b6f24e' [16:41:25 CET] <cone-520> ffmpeg 03James Almer 07master:6c31ba226968: avformat/matroska: fix MatroskaVideoFieldOrder enum values [16:41:26 CET] <cone-520> ffmpeg 03Clément BSsch 07master:590fb5291ad4: Merge commit '6c31ba226968f12f898120dbb928dab34e03782b' [16:41:51 CET] <BtbN> philipl, ah, the avctx->i_quant_factor and b_quant_factor are set to -0.8 and 1.25 [16:41:58 CET] <BtbN> But why does he fabs() it? [16:50:13 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:4abe3b049d98: hevc: rename hevc.[ch] to hevcdec.[ch] [16:50:14 CET] <cone-520> ffmpeg 03Clément BSsch 07master:038e6aef7a54: Merge commit '4abe3b049d987420eb891f74a35af2cebbf52144' [16:50:45 CET] <ubitux> anyone wants to take over the merges for a while? i'm getting tired :( [16:51:24 CET] <ubitux> (ETA: 776) [16:53:30 CET] <ubitux> we're mid-october 2016 [16:57:37 CET] <BtbN> philipl, nevermind, libx264.c in ffmpeg compensates for that - and +: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L527 [16:57:55 CET] <BtbN> In ffmpeg, the factor is instead less than 1 [17:07:08 CET] <BtbN> Is it only me, or is this specific line a bug in libx264.c: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L526 [17:07:23 CET] <BtbN> The i_quant_factor is -0.8 by default. The check should imo just be != 0.0 [17:11:00 CET] <nevcairiel> the default is -1, ie. disabled [17:11:14 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/options_table.h#L204 [17:11:24 CET] <nevcairiel> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L988 [17:11:32 CET] <nevcairiel> need to read the correct defaults =p [17:11:46 CET] <BtbN> But still, -0.8 would be a perfectly valid value [17:12:00 CET] <nevcairiel> not necessarily for x264 [17:12:08 CET] <BtbN> would be no reason for the fabs() around it if it wasn't [17:12:34 CET] <nevcairiel> makes no sense to use negative values then [17:12:44 CET] <nevcairiel> so might as well leave it [17:12:52 CET] <BtbN> yes, I do wonder why the options_table.h default is negative [17:13:01 CET] <nevcairiel> probably for other encoders [17:13:03 CET] <nevcairiel> mpeg2 or mpeg4 [17:13:05 CET] <BtbN> But the check for > 0 and fabs() in the very next line does seem a bit strange [17:13:22 CET] <nevcairiel> -1 is typically used as a default-unused value [17:13:44 CET] <BtbN> for a factor, 0 would make more sense there [17:15:02 CET] <nevcairiel> the factor is a mulitplier, so 0 is inherently invalid and should probably be avoided as a value at any time [17:16:09 CET] <BtbN> hm, wonder if I should override the default in nvenc as well then [17:16:25 CET] <BtbN> Right now, the only way to disable the offset for nvenc is to set it to 0 [17:17:15 CET] <BtbN> So default the I offset to 0.8, B offset to 1.25, and drop all the fabs, and check for > 0 [17:18:19 CET] <BtbN> philipl, https://github.com/BtbN/FFmpeg/commits/master see my latest commits [17:30:46 CET] <philipl> BtbN: looks good to me [17:49:03 CET] <thebombzen> huh, I can't reproduce that bug and I built ffmpeg 5 minutes ago. says it's 3.2.4 tho so I'll try that [17:50:42 CET] <thebombzen> okay, I can reproduce on 3.2.4 but not git master [17:50:50 CET] <thebombzen> seems already fixed [18:21:52 CET] <cone-520> ffmpeg 03Timo Rothenpieler 07master:7fb2a7afa174: avcodec/nvenc: Deprecate usage of global_quality, introducing qp [18:21:53 CET] <cone-520> ffmpeg 03Timo Rothenpieler 07master:d84c2298e28c: avcodec/nvenc: apply quantization factors to cqp [18:56:11 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:c359d624d3ef: hevcdec: move decoder-independent declarations into a separate header [18:56:12 CET] <cone-520> ffmpeg 03James Almer 07master:a1a80a6c9ce5: avcodec/bytestream: check for AV_HAVE_BIGENDIAN instead of HAVE_BIGENDIAN [18:56:13 CET] <cone-520> ffmpeg 03James Almer 07master:6397815be0be: Merge commit 'c359d624d3efc3fd1d83210d78c4152bd329b765' [19:00:14 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:645c6ff4231a: hevcdec: drop the prototype of a non-existing function [19:00:15 CET] <cone-520> ffmpeg 03James Almer 07master:e7a6200dcb3c: Merge commit '645c6ff4231a75a71db58c8e6d06346068d2f949' [19:08:33 CET] <cone-520> ffmpeg 03James Almer 07master:5c6efaffd09d: avcodec/hevc: add missing hevc.h header [19:17:03 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:150c896a9e46: hevcdec: split ff_hevc_diag_scan* declarations into a separate header [19:17:04 CET] <cone-520> ffmpeg 03James Almer 07master:b29c8c995f17: Merge commit '150c896a9e46b23b97debb0a5f66fbaeaa32f153' [20:09:10 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:f6e2f8a9ffda: hevcdec: move parameter set parsing into a separate header [20:09:11 CET] <cone-520> ffmpeg 03James Almer 07master:4a5810b6592d: Merge commit 'f6e2f8a9ffda2247bffba991450990d075ea68e3' [20:33:15 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:89b35a139e83: lavc: add a bitstream filter for extracting extradata from packets [20:33:16 CET] <cone-520> ffmpeg 03James Almer 07master:7ebc9f8df403: Merge commit '89b35a139e838deeb32ec20d8d034c81014401d0' [21:23:49 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:8e2ea691351c: lavf: use the new bitstream filter for extracting extradata [21:23:50 CET] <cone-520> ffmpeg 03James Almer 07master:1c193ac1f9cf: Merge commit '8e2ea691351c5079cdab245ff7bfa5c0f3e3bfe4' [21:35:39 CET] <legume> Another header needed since recent merges? libavcodec/vaapi_encode_h265.c:633:35: error: P_SLICE undeclared [21:36:31 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:a05cc56124b4: checkasm: arm/aarch64: Fix the amount of space reserved for stack parameters [21:36:32 CET] <cone-520> ffmpeg 03James Almer 07master:cab4c7fa199f: Merge commit 'a05cc56124b4f1237f6355784de821e3290ddb44' [21:37:57 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:f1b3e1313851: checkasm: aarch64: Clobber the stack before calling functions [21:37:58 CET] <cone-520> ffmpeg 03James Almer 07master:a2d34cc51ba1: Merge commit 'f1b3e131385176c3c9d9783b25047856a0dcebf6' [21:39:10 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:c91d6a33f872: checkasm: aarch64: Add filler args to make sure all parameters are passed on the stack [21:39:11 CET] <cone-520> ffmpeg 03James Almer 07master:67b639b49626: Merge commit 'c91d6a33f872574c95c8784277cf60ffcf6bff4f' [21:42:56 CET] <ubitux> jamrial: nice, thanks for taking over [21:42:58 CET] <ubitux> did you see dd5d4a0e1e? [21:43:44 CET] <jamrial> we're not there yet [21:44:02 CET] <jamrial> and no prob. I'll try to do some more [21:45:02 CET] <ubitux> yeah but it's a regression in a commit you recently merged :) [21:45:12 CET] <ubitux> but i guess you'll reach that one soon [21:45:26 CET] <jamrial> ah, lol [21:45:34 CET] <jamrial> if i don't i'll cherry pick it [21:45:47 CET] <ubitux> it's 10 commits away [21:45:49 CET] <ubitux> no worry [22:00:05 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:93d5b022a9fd: build: Drop duplicate asm recipe [22:00:06 CET] <cone-520> ffmpeg 03James Almer 07master:3ddae9eee9a8: Merge commit '93d5b022a9fd3a1a1f9c521a1eac7f0410e05b81' [22:02:53 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:2816f8a8bb33: build: Drop arch-specific checkasm Makefiles [22:02:54 CET] <cone-520> ffmpeg 03James Almer 07master:f23078904f99: Merge commit '2816f8a8bb33bd67fec5e94f5d357918caf4e055' [22:03:40 CET] <faLUCE> ubitux: wm4_ : I wrote many examples which are SHORT and CLEAN, and can be really useful for the documentation, instead of the messy and not up to date doc/examples folder. I would be glad to push them to the ffmpeg project if you find them good/useful... but who is a person that can judge them? I can show you one of them, if you want [22:06:25 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:6be7944ee2ec: x86: Add missing colons after assembly labels [22:06:26 CET] <cone-520> ffmpeg 03James Almer 07master:29db87af522c: Merge commit '6be7944ee2ec2f045e6eb9a93237e992c8b20ac4' [22:07:38 CET] <jamrial> faLUCE: send them to the ml. documentation and api usage examples are always welcome [22:09:03 CET] <faLUCE> jamrial: after sending them to the ml, who will judge if they can be published ? [22:09:31 CET] <jamrial> any developer who can review them [22:10:08 CET] <faLUCE> jamrial: can I send them to some developer, directly ? [22:11:23 CET] <cone-520> ffmpeg 03Mark Thompson 07master:f9bb356e0eb3: vaapi_h265: Include header for slice types [22:11:24 CET] <cone-520> ffmpeg 03James Almer 07master:c43fd1f279ce: Merge commit 'f9bb356e0eb38ab4df32df8276b71a0b2626538f' [22:15:02 CET] <jamrial> faLUCE: no [22:16:27 CET] <cone-520> ffmpeg 03Mark Thompson 07master:0cf86fabfa58: vaapi_encode: Write sequence header as extradata [22:16:28 CET] <cone-520> ffmpeg 03James Almer 07master:530066166e3c: Merge commit '0cf86fabfa5820596cca2cfead63c6f8df76c3f2' [22:18:58 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:58224dc5f3d4: ppc: avcodec: Drop silly "_ppc" suffixes from files in ppc subdirectories [22:18:59 CET] <cone-520> ffmpeg 03James Almer 07master:09a80419b73d: Merge commit '58224dc5f3d4fea40a8d55cca87291a960c11622' [22:21:12 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:d32571626a2c: build: Add VSX-OBJS to SUBDIR_VARS [22:21:13 CET] <cone-520> ffmpeg 03James Almer 07master:78c52e2721ca: Merge commit 'd32571626a2c36c026b7fa13d19ac4ed1aad75c9' [22:28:12 CET] <cone-520> ffmpeg 03Michael Niedermayer 07master:be9dba5c8abc: swscale: Properly load alpha for planar rgb [22:28:13 CET] <cone-520> ffmpeg 03James Almer 07master:0dcfa02fd278: Merge commit 'be9dba5c8abc6ecf0b8ee4ccb11c7850327fcf8d' [22:31:18 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:7911186ed616: emms: Give apriv_emms_yasm() a more general name [22:31:19 CET] <cone-520> ffmpeg 03James Almer 07master:c97e986e90c3: Merge commit '7911186ed616ae81dd8617d6d0e8b08c818db9d8' [22:32:53 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:dd5d4a0e1e3a: checkasm: aarch64: Don't clobber x29 in checkasm_stack_clobber [22:32:54 CET] <cone-520> ffmpeg 03James Almer 07master:0d34473d8ecd: Merge commit 'dd5d4a0e1e3a30a254d1a57ecbdcedf230c6014b' [22:34:41 CET] <cone-520> ffmpeg 03Luca Barbato 07master:da4f8c8e35a8: fate: Update filter-pixfmts-scale gbrap12le hash missing from be9dba5c8a [22:34:42 CET] <cone-520> ffmpeg 03James Almer 07master:acf125f3336b: Merge commit 'da4f8c8e35a867f2d9fed0fb75e16c81ab968637' [22:36:29 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:b89804da9bad: x86: videodsp: Add parentheses to expression to work around warning [22:36:30 CET] <cone-520> ffmpeg 03James Almer 07master:bac44a50206e: Merge commit 'b89804da9bad2d94dd95bf20ac6187447e9c17e9' [22:41:49 CET] <legume> build OK now [22:44:17 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:1f821e5ad3f8: configure: Print warnings after all other output [22:44:18 CET] <cone-520> ffmpeg 03James Almer 07master:d07f2dacb97f: Merge commit '1f821e5ad3f8ebacbbb362668561ad976c392c9e' [22:46:55 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:788544ff0ed6: audiodsp: x86: Remove pointless header file [22:46:58 CET] <cone-520> ffmpeg 03James Almer 07master:380448194fb4: Merge commit '788544ff0ed6fe67fda80ad6d3a0796ace035584' [22:58:13 CET] <jamrial> ubitux: could you check the failing subtitle tests? [22:58:43 CET] <jamrial> the bad merge is 1c193ac1f9cf, with the new bsf [23:00:01 CET] <jamrial> is the change desired or not? i ask based on the comment in the relevant merged commit [23:01:04 CET] <ubitux> huh [23:01:08 CET] <ubitux> we're loosing 1 sec? [23:01:16 CET] <ubitux> on the pts [23:02:34 CET] <ubitux> it's incorrect [23:02:37 CET] <jamrial> supposedly, the commit may change packet durations [23:02:43 CET] <jamrial> but yeah, i'm inclined to revert it [23:02:53 CET] <jamrial> other failing tests are clearly broken [23:03:04 CET] <ubitux> the first pts starts at 0 for subtitles [23:03:07 CET] <jamrial> fuck, i was sure i ran fate before pushing it [23:03:08 CET] <ubitux> while it shouldn't [23:04:26 CET] <jamrial> i'm going to bet the problem is some difference in how we copy codecpar info with bsfs [23:35:55 CET] <cone-520> ffmpeg 03James Almer 07master:40fa9d416a25: Revert "Merge commit '8e2ea691351c5079cdab245ff7bfa5c0f3e3bfe4'" [23:40:37 CET] <ubitux> michaelni: http://sprunge.us/dNLZ isn't this more correcT? [23:43:33 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:096a8effa3f8: lavf: check that the codec is supported by extract_extradata [23:43:34 CET] <cone-520> ffmpeg 03James Almer 07master:950c3fa52097: Merge commit '096a8effa3f8f3455292c958c3ed07e798def7bd' [23:46:10 CET] <ubitux> michaelni: it's changing a bunch of fate ref though& [23:46:45 CET] <ubitux> but maybe i do not understand the meaning of that macro [23:47:56 CET] <ubitux> (also, shouldn't this list include the 0RGB and 0BGR pix fmts?) [23:50:20 CET] <cone-520> ffmpeg 03James Almer 07master:0f4abbd4ee1c: doc/libav-merge: add a line about the extract_extradata commits [23:56:01 CET] <michaelni> ubitux, IIRC RGBinInt would be the formats that are ordered as RGB when loaded in a integer [23:56:50 CET] <michaelni> i suspect the patch linked is wrong, but does it fix anything? [23:57:41 CET] <ubitux> it probably doesn't [23:57:48 CET] <ubitux> i indeed misunderstood the function then [23:58:07 CET] <ubitux> but yeah i was wondering about the suncc fate failure [23:59:02 CET] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170323205016&slot=sparc-solaris-32… [23:59:47 CET] <ubitux> i'm wondering what would be a correct fix for this, if any [00:00:00 CET] --- Fri Mar 24 2017

1 0

ffmpeg.log.20170323
by burek 24 Mar '17

24 Mar '17

[00:01:15 CET] <llogan> is your ffmpeg old? [00:10:10 CET] <kcghost> ffmpeg version 3.0.2 [00:13:38 CET] <kcghost> ill try building the latest release and see if it still has the issue. [00:22:03 CET] <llogan> you could be lazy and download a recent static build [00:25:21 CET] <kcghost> llogan: ah thanks, I didn't realize that was an option. That's nice, I didn't want to deal with packages [00:28:42 CET] <kcghost> llogan: huh, looks like it's fixed. I wonder when it got fixed, my ffmpeg wasn't super old. [00:37:19 CET] <llogan> you could try a git bisect if you want to find out [00:39:51 CET] <llogan> in general any ffmpeg release branch is always considered old [04:27:27 CET] <RossW> when using ffmpeg to convert discrete images (jpg) into a movie, is it possible for it to not require all filenames to have the same length? Ie, if my files are "1.jpg", "2.jpg" ..... "1234.jpg" ??? [04:30:06 CET] <RossW> Looks like just %d not %4d might be the answer. So many examples, so little clarity! [04:39:53 CET] <c_14> use -pattern_type glob [07:04:32 CET] <lindylex> Can I make a video that has a vertical line move from left to right on top of a image with a specified time? I am trying to replicate the scrub on top of a waveform image? [07:30:22 CET] <marbar> hello all [07:30:33 CET] <marbar> does anyone here have experience w/ hls on ios? [07:30:46 CET] <marbar> i have a source video i'm segmenting like this: [07:30:47 CET] <marbar> ffmpeg -i 9 -map 0 -c:v libx264 -c:a aac -deinterlace -f ssegment -segment_list hls/9/list.m3u8 -segment_list_flags +live -segment_time 10 -segment_time_delta 0.03 hls/9/%03d.ts [07:31:04 CET] <marbar> and on ios (only) it stops after about a minute and a half [07:31:18 CET] <marbar> is there some flag i can add to ensure playback on the ipad? [10:35:09 CET] <matkatmusic> what is the idea behind h264/x264 decoding? [10:35:58 CET] <matkatmusic> is it that there is a bunch of data, organized as "here's frame number 0, now here's what changed for frame 1, now frame 2, etc" [10:36:56 CET] <matkatmusic> hmm, i guess that would be how gifs work lol [10:37:56 CET] <BtbN> Fenrirthviti, alexpigment you mean the ancient NVDefault in the dead OBS encoder? [10:38:07 CET] <BtbN> That's what the nvenc API calls default. [10:38:27 CET] <BtbN> Default in classic OBS is hq/llhq, depending on the resolution and FPS. [10:38:59 CET] <BtbN> Modern obs-studio does not have anything called nvdefault, and the presets map directly to the ffmpeg -preset option. [10:39:43 CET] <BtbN> Guess why I want to get rid of the "default" preset. It's confusing, because it's not the default. [11:01:36 CET] <furqn> hi i am concatenating videos and adding background music to it [11:02:07 CET] <furqn> and background music file is bigger so how can i trim it to match the size of outputed video file [11:03:47 CET] <furqn> here it is [11:03:50 CET] <furqn> http://pastebin.com/fHTsrRYv [11:09:49 CET] <relaxed> furqn: there's -shortest or you could use an audio filter [11:11:04 CET] <furqn> relaxed: -shortest will select shortest video stream in concatednated video [11:11:11 CET] <furqn> i checked already with that [11:12:44 CET] <relaxed> atrim filter [11:13:19 CET] <relaxed> along with afade [12:14:42 CET] <faLUCE> Hello. when I allocate an AVCodecContext* for a decoder, do I have to specify the pixel format (decodec_context->pix_fmt) ? This is absolutely not clear in the API. I opened a MJPEG decoder with codec = avcodec_find_decoder(AV_CODEC_ID_MJPEG) but codec->pix_fmts doesn't contain anything.... [12:40:46 CET] <njascgil> Hi everyone! I'm trying to use ffmpeg to remove the handler_name tag from audio tracks. It is set by default to handler_name=SoudHandler, but I want to delete it. [12:42:36 CET] <njascgil> I'm able to set it to something else using "-metadata:s:a:1 handler_name=EXAMPLE", but I can't remove it using "handler_name=" or other options such as just "handler_name" or 'handler_name=""'... Any ideas? Thanks! [13:06:13 CET] <BtbN> faLUCE, except for some weirdnesses, decoders return the native pixel format. [13:06:48 CET] <BtbN> If a decoder supports multiple formats, you have to implement get_format to select one [13:06:55 CET] <BtbN> primarily used for hwaccels [13:10:29 CET] <faLUCE> BtbN: I see. Anyway it's weird that codec->pix_fmts returns NULL, while AVFrame->format returns the format. I think it's a bug of the API [13:11:18 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/avcodec.h#L1950 [13:11:20 CET] <BtbN> no it's not [13:12:04 CET] <BtbN> Most decoders just set it to the pix_fmt they output, and ignore any user input [13:13:55 CET] <faLUCE> BtbN: MJPEG doesn't set codec->pix_fmts to anything, while it sets AVFrame->format to YUVJ420P. This is a missing stuff of the API [13:14:34 CET] <faLUCE> why the hell there's not a format in the avcodeccontext, while there is it in the resulting frame? it's nonsense [13:14:46 CET] <BtbN> There is pix_fmt in AVCodecContext. [13:14:51 CET] <kerio> i wish the "scene" would stop tailoring files to optical media [13:14:52 CET] <kerio> :\ [13:15:09 CET] <BtbN> Also, why do you care about what is in the AVCodecContext? In the end you need to care about what is in the Frame anyway [13:16:15 CET] <faLUCE> BtbN: sorry, I mean, why the hell there's not a format in AVCodec? [13:17:17 CET] <faLUCE> BtbN: all the three containers (codec, format, context) must be aligned in all the fields [13:17:19 CET] <BtbN> There is, for encoders, to signal supported input formats. [13:17:37 CET] <BtbN> For decoders it's optional [13:17:47 CET] <faLUCE> BtbN: then the field should be called "input_pix_fmts" [13:17:53 CET] <BtbN> Some set it, like cuvid. mjpeg doesn't. [13:17:57 CET] <faLUCE> otherwise it's misleading [13:18:08 CET] <BtbN> It's just optional for decoders [13:18:20 CET] <faLUCE> better: encoder_pix_fmts [13:18:31 CET] <BtbN> The fiels is univeral between decoders and encoders. [13:18:45 CET] <BtbN> And it makes sense, as you have no idea about the actual output pixel format from a decoder until it actually gives you a frame [13:18:54 CET] <BtbN> in theory, the API even allows for it to change from frame to frame [13:19:27 CET] <faLUCE> BtbN: yes. Then they should be specialized in some way, at least in their description (in comments or whatsoever) for decoders and encoders. [13:19:37 CET] <BtbN> Why? There is no need to. [13:19:38 CET] <faLUCE> otherwise it's misleading. [13:20:16 CET] <BtbN> I don't see anything misleading about it. The fiels is properly documented in what it means for an encoder and what for a decoder. [13:22:41 CET] <faLUCE> BtbN: please. I appreciate your help, but you insist in things in a dogmatic way. Note that this differentiation is ALREADY specified in the description of many fields of the API (like: "for encoder it does X, for decoder it does Y"). Someone forgot to specify that for pix_fmt and this is MISLEADING. It's so obvious that it should not be explained. It's just a missing feature. I'll signal it to the developers [13:22:59 CET] <BtbN> But it is specified for pix_fmt [13:23:23 CET] <faLUCE> BtbN: ok, no way to discuss in this way. [13:23:41 CET] <BtbN> I just gave you the link... If you are just here to waste peoples time with trolling, please leave. [13:24:22 CET] <faLUCE> BtbN: really not. I only explained an obvious thing. [13:25:31 CET] <BtbN> I'll just add you to my ignore list. Annoy someone else. [14:05:48 CET] <k-man> while converting an mp3 to m4a, is it possible to also add album art at the same time? [14:06:53 CET] <furq> there's a longstanding open bug for that, so i guess not [14:07:03 CET] <k-man> ah ok [14:07:05 CET] <k-man> thanks [14:07:12 CET] <furq> album art in m4a isn't specified anywhere iirc [14:07:33 CET] <furq> although the de facto standard is "what itunes does" so i don't see what the problem is with just doing that [14:10:44 CET] <k-man> dunno either [14:11:58 CET] <kerio> itunes \o/ [14:12:16 CET] <k-man> can i add coverart some other way? [14:12:28 CET] <furq> actually i distinctly remember doing this with ffmpeg [14:12:32 CET] <k-man> ugh more like [14:13:20 CET] <k-man> using xargs to run conversions in parrallel sure makes it go faster :) [14:13:25 CET] <k-man> one per core [14:13:54 CET] <furq> i think `ffmpeg -i foo.mp3 -i bar.png -map 0:a -map 1:v baz.m4a` will work [14:14:09 CET] <furq> and probably -c:v copy as well [14:14:29 CET] <k-man> i don't get the -map 1:v pard, what does that do? [14:14:51 CET] <furq> maps the video stream (the picture) from bar.png [14:14:55 CET] <k-man> oh is it map video from the nth file [14:14:56 CET] <k-man> right [14:15:05 CET] <k-man> ok let me try that [14:17:38 CET] <k-man> i have -map_metadata:s:a 0:s:a already in my command [14:17:51 CET] <k-man> is 0:s:a for the metadata or the audio? [14:42:34 CET] <Fenrirthviti> BtbN: yeah, that's what I found. I can't find any existing documentation where it's still called "NVDefault" though. Seems they just call it default everywhere now, which was very confusing. It's all good, thanks for the follow up though [14:42:57 CET] <BtbN> I called it NVDefault in OBS to signal that it is _not_ the default [14:43:17 CET] <BtbN> Default in OBS was an automatic profile selection based on resolution and framerate. [14:43:43 CET] <BtbN> In obs-studio the plugin-author just blindly copied the ffmpeg presets, and made default the default, which happens to be the worst choice. [15:10:25 CET] <alexpigment> Fenrirthviti: did you ever figure out why that user thought it looked superior? [15:10:50 CET] <alexpigment> i.e. was it a legitimate discrepancy, or was there another factor that explained the difference? [15:11:13 CET] <Fenrirthviti> BtbN: yeah that makes sense [15:11:44 CET] <Fenrirthviti> alexpigment: No, they stopped responding. If I had to guess, they were under the assumption that Shadowplay was using it? I can't find much documentation on what Shadowplay uses for settings [15:11:58 CET] <BtbN> Shadowplay is using an undocumented preset. [15:12:12 CET] <alexpigment> it's probably based on one of the low latency presets i would guess [15:12:21 CET] <Fenrirthviti> Well that explains why I can't find it :P Does anyone have it documented? [15:12:23 CET] <BtbN> Copying its GUID results in an initialization error [15:12:29 CET] <Fenrirthviti> Interesting. [15:12:29 CET] <BtbN> Find what? [15:12:41 CET] <Fenrirthviti> What it's actually setting to replicate the results [15:13:06 CET] <BtbN> You can just tap into its API calls. It does nothing fancy except for the non-public preset guid [15:14:07 CET] <Fenrirthviti> Dunno how to do that. Very little experience with actual code. [15:14:40 CET] <BtbN> You write a shim dll that exposes the same API, and make it log every single function call and its parameters [15:14:58 CET] <Fenrirthviti> Which I'm sure is easy to someone who knows what a shim dll is. [15:17:38 CET] <Fenrirthviti> It's all good though, I don't really care all that much. I've done my own testing that's shown the "indistinguishable quality" preset we set in OBS (which is just hq with b-frames, 2pass, and a low keyint) is just as good or better than shadowplay itself [15:19:54 CET] <thebombzen> undocumented apis [15:19:57 CET] <thebombzen> :P [15:20:11 CET] <thebombzen> didn't microsoft lose a lawsuit about that [15:20:21 CET] <Fenrirthviti> I'm just happy I wasn't going crazy trying to research all this shit to prove it. [15:23:24 CET] <alexpigment> here's another question about NVENC H264: does anyone have any rough equivalents for x264's -crf to nvenc's -global_quality ? [15:24:07 CET] <alexpigment> i've been using 20, which seems fine, but i was hoping to avoid some annoying tests if someone has already got a good comparison between x264 and nvenc (and quicksync too perhaps) [15:24:42 CET] <Fenrirthviti> CQP? or is global_quality something else? [15:24:44 CET] <alexpigment> (and i do realize that crf works differently than -global_quality, of course) [15:25:00 CET] <alexpigment> global_quality is a CQP setting i believe [15:25:28 CET] <Fenrirthviti> If it's CQP, I've always used 14, which seems comparable to x264 crf 16 [15:26:06 CET] <thebombzen> wait it has vbr [15:26:08 CET] <thebombzen> since when [15:26:27 CET] <alexpigment> yeah for some reason cqp errors on ffmpeg, so global quality is the only way i know to specify a quality-based setting [15:26:46 CET] <thebombzen> so if you uset his: -c:v h264_nvenc -global_quality:v 14 you don't have to set the bitrate [15:26:48 CET] <Fenrirthviti> it's had it as long as I've used it [15:26:48 CET] <thebombzen> that's good to know [15:27:22 CET] <momomo> is there a way to change the file ending of ts files for hls generation? [15:27:43 CET] <thebombzen> don't call them .ts? [15:28:10 CET] <alexpigment> Fenrirthviti - i've only been testing for 2 months or so, but in that time, -cqp always give an error "Not recognized option 'cqp"" [15:28:20 CET] <alexpigment> maybe it was deprecated before i started testing [15:28:35 CET] <Fenrirthviti> well I dunno how OBS is actually passing it, let me check [15:28:55 CET] <thebombzen> momomo: try -hls_segment_filename [15:29:01 CET] <thebombzen> and name them something other than a .ts [15:29:17 CET] <BtbN> alexpigment, it's -global_quality [15:29:37 CET] <thebombzen> BtbN: the bigger question is why it's not on "ffmpeg -h encoder=h264_nvenc" [15:29:48 CET] <thebombzen> ffmpeg -h encoder=h264_nvenc doesn't list -global_qualit [15:29:50 CET] <BtbN> Because it's a global option. [15:30:19 CET] <Fenrirthviti> enc->context->global_quality = cqp; yeah [15:30:49 CET] <alexpigment> BtbN: yeah, that's what i've been using (see above) [15:31:20 CET] <thebombzen> BtbN: it's a global option but has no description [15:31:30 CET] <thebombzen> if you run "man ffmpeg-all" it lists it but doesn't say anything [15:31:34 CET] <BtbN> It has, just not in the nvenc help, as it's not an nvenc specific option. [15:31:54 CET] <thebombzen> no it doesn't have a description [15:32:39 CET] <thebombzen> https://ffmpeg.org/ffmpeg-all.html#Codec-Options [15:32:41 CET] <thebombzen> see this [15:33:30 CET] <thebombzen> anyway, so you said -global_quality 14 is comparable to x264's -crf 16? [15:33:54 CET] <Fenrirthviti> For nvenc, seems to be, yes [15:34:01 CET] <furq> it's time for your daily reminder that crf quality depends on the preset [15:34:12 CET] <Fenrirthviti> crf 16 on veryfast [15:34:13 CET] <alexpigment> global_quality is usually better at a given value equivalent to CRF in my experience [15:34:31 CET] <BtbN> I think it's not documented because you are expected to just use -q, which has documentation. [15:34:32 CET] <alexpigment> and yeah, i've been comparing to veryfast as well [15:34:35 CET] <Fenrirthviti> thebombzen: https://ffmpeg.org/ffmpeg-all.html#Options-6 there's a note here for -q [15:34:57 CET] <thebombzen> that's the aac encoder [15:34:58 CET] <alexpigment> BtbN - for nvenc, -q is not equivalent to -global_quality [15:34:59 CET] <thebombzen> why would I care [15:35:22 CET] <BtbN> alexpigment, ffmpeg_opt.c assigns global_quality from -q. [15:35:23 CET] <alexpigment> i mean effectively, they might be the same perhaps, but the scale is very different [15:35:33 CET] <Nacht> Hey. Quick question. Anyone know why I get 3M extra bitrate when I use a simple -c copy -t 00:02:00 command on ffmpeg ? [15:35:56 CET] <furq> because the bitrate of that two minutes is more than the rest of the file [15:36:02 CET] <alexpigment> BtbN - i can tell you for a fact that they are not the same in the ffmpeg i built last week [15:36:09 CET] <Nacht> Good point furq [15:36:32 CET] <alexpigment> average bitrate of -q:v 26 ends up as 691kbps for this test video [15:37:07 CET] <BtbN> It multiplies it with some weird factor [15:37:19 CET] <BtbN> for h263 compat. Seems weird. Better just use -global_quality [15:37:20 CET] <alexpigment> yeah, that's what i assumed [15:37:27 CET] <alexpigment> yes, that's what i use [15:37:48 CET] <alexpigment> if you look above, you'll see that the CQP started with Fenrirthviti asked what global_quality was and why i wasn't using CQP [15:38:07 CET] <Fenrirthviti> I didn't ask why you weren't using it, I was just confirming it was the same thing [15:38:47 CET] <BtbN> There is also -cq, which was recently added by nvidia [15:38:55 CET] <BtbN> No idea what it does differently than global_quality [15:39:49 CET] <alexpigment> Fenrirthviti: sorry, you're right. just trying to explain the confusion here with -global_quality. i have no problem with it and have been using it for a few months now [15:40:31 CET] <alexpigment> -cq seems diff than -q:v or -global_quality, oddly [15:40:36 CET] <alexpigment> i didn't know this existed [15:40:45 CET] <alexpigment> perhaps this is more CRF-like based on the bitrates? [15:40:53 CET] <Fenrirthviti> yeah that's the right thing to be using, it's what OBS is passing with the CQP setting in the UI (which is what I was testing with) [15:41:10 CET] <BtbN> the old OBS nvenc encoder is bad [15:41:16 CET] <BtbN> I wouldn't bother with it anymore [15:41:22 CET] <Fenrirthviti> classic? I'm not. [15:41:32 CET] <Fenrirthviti> We don't support anything with classic anymore [15:41:35 CET] <BtbN> studio just uses ffmpeg [15:41:58 CET] <Fenrirthviti> right, but we call the setting "cqp" in the UI, which is just an alias to global_quality when the params are actually passed to ffmpeg [15:42:54 CET] <BtbN> yes, global_quality is the intended constant quality mode, with -rc is set to constqp [15:43:08 CET] <Fenrirthviti> alexpigment: https://gist.github.com/Fenrirthviti/554635fc7f31a00b1f0f51c2174c4575 [15:43:35 CET] <Fenrirthviti> if you care, that's our recommended recording settings for nvenc [15:43:58 CET] <BtbN> seeams reasonable [15:44:21 CET] <BtbN> one might argue you want to go for lossless for recording [15:44:53 CET] <alexpigment> yeah, i'm looking for something a little bit more delivery-friendly, but these are good settings [15:45:13 CET] <Fenrirthviti> yeah, we don't recommend that solely on the fact people are idiots and try to record to 5400rpm NAS drives or only have laptops with 80gb HDDs in it 90% of the time [15:45:13 CET] <alexpigment> global_quality 14 is a bit *too* good for my purposes ;) [15:45:40 CET] <BtbN> The -global_quality options sets the constQP values: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L525 [15:46:10 CET] <BtbN> While -cq sets rcParams.targetQuality: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L757 [15:47:08 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/compat/nvenc/nvEncodeAPI.h#L10… https://github.com/FFmpeg/FFmpeg/blob/master/compat/nvenc/nvEncodeAPI.h#L10… [15:47:10 CET] <alexpigment> BtbN do you mind explaining that in layman's terms? [15:47:23 CET] <BtbN> well, those comments are all the documentation there is [15:47:28 CET] <BtbN> what it means, is up to the nvidia driver [15:48:09 CET] <BtbN> the -cq seems to be intended for non-CQP mode, like classic VBR, but with a forced target quality...? [15:48:17 CET] <alexpigment> well if i'm trying to get something more equivalent to CRF, do you recommend sticking with global_quality or trying -cq instead? [15:48:47 CET] <BtbN> Can always play around with that option [15:49:06 CET] <alexpigment> ok, well the ambiguous answer means more testing for me i guess ;) [15:49:13 CET] <alexpigment> thanks for pointing out cq - i didn't know it existed [15:51:28 CET] <BtbN> The x264 crf is an implementation specific thing with no equivalent elsewhere. [15:51:54 CET] <BtbN> If you want something rougly compareable, you should compare x264 CQP to nvenc CQP [15:53:17 CET] <BtbN> In retrospect, using a custom -cqp option would have been nicer for nvenc. As global_quality is kind of clunky, and is originally intended for qscale stuff [15:59:16 CET] <alexpigment> yeah, i agree. i had never heard of global_quality until i started using NVENC, cqp seems at least more intuitive [15:59:41 CET] <BtbN> Well, changing it now would break the API [15:59:51 CET] <alexpigment> no worries [16:00:17 CET] <BtbN> Could always start a deprecation process though [16:01:31 CET] <momomo> thebombzen: when I use -hls_segment_filename %0d.ts the encoding kind of gets destroyed and picture green ... it seems to have a wierd effect on the output [16:04:23 CET] <momomo> yeah, for sur [16:04:24 CET] <momomo> e [16:04:59 CET] <momomo> is the option -single_file to create only one ts file likely to be computationally less expensive than for several ts files? [16:18:56 CET] <Fenrirthviti> BtbN: Sorry if this is just an ignorant question, but would the changes proposed in -devel change the scale for quality from the current? i.e. 14 vs 26, etc. [16:19:18 CET] <BtbN> I'll just rename -global_quality to -qp [16:19:25 CET] <BtbN> so the name is identical to libx264 [16:19:38 CET] <Fenrirthviti> ah just a naming convention change, ok [16:19:57 CET] <BtbN> Should have never used global_quality in the first place, it's plain wrong [16:21:11 CET] <Fenrirthviti> yeah fair enough, thanks for the clarification [16:29:03 CET] <Darxus_> A video I recorded is quite jiggly after using vidstab, I suspect due to lens distortion? Does that make sense? Is http://www.ffmpeg.org/ffmpeg-all.html#lenscorrection likely to be helpful? [16:46:36 CET] <KOPRajs> hi, is it possible to stream from ffmpeg running on local machine to ffserver running on remote server? [16:59:30 CET] <BtbN> Use nginx-rtmp instead. [16:59:46 CET] <BtbN> ffserver is pretty much dead [17:00:00 CET] <pzy> hey all, ffmpeg for life, etc [17:01:47 CET] <pzy> anyone here playing with/working on NDI and ffmpeg? [17:10:48 CET] <pzy> aka SpeedHQ [17:28:01 CET] <alexpigment> BtbN - i just got around to doing more testing with -cq - it turns out it's just ignored ;) [17:29:02 CET] <alexpigment> there are no messages denoting this, but changing the -cq [anything] is the same as not specifying a quality level or bitrate at all [17:29:10 CET] <thebombzen> it should be qp [17:29:11 CET] <thebombzen> not cq [17:29:13 CET] <alexpigment> at least that saves me some more testing [17:29:28 CET] <thebombzen> at least with libx264, you need -qp, not -cq, just fyi [17:29:49 CET] <alexpigment> this is referring to an earlier conversation [17:29:57 CET] <alexpigment> where BtbN mentioned -cp [17:30:18 CET] <alexpigment> er [17:30:19 CET] <alexpigment> cq [17:30:23 CET] <alexpigment> confused myself there ;) [17:30:51 CET] <alexpigment> "<BtbN> There is also -cq, which was recently added by nvidia" [17:32:20 CET] <alexpigment> but for what it's worth, thebombzen, -qp doesn't do anything either. -global_quality is the only real way to do this, i think [17:32:35 CET] <thebombzen> nvidia's -cq doesn't do anything tho [17:32:39 CET] <thebombzen> you need to use -global_quality [17:32:45 CET] <thebombzen> also -qp is a private option, not a global option [17:32:57 CET] <thebombzen> so you shouldn't expect -qp to work in every case -global_quality does [17:33:02 CET] <alexpigment> thebombzen - i literally just said that [17:33:04 CET] <thebombzen> similar to how -q:a doesn't work for certain codecs [17:33:26 CET] <thebombzen> you did? [17:33:32 CET] <thebombzen> nvidia has -cq which I've seen [17:33:35 CET] <thebombzen> but it doesn't actually do anything [17:33:37 CET] <thebombzen> which is weird [17:33:41 CET] <alexpigment> yes [17:33:50 CET] <alexpigment> "<alexpigment> BtbN - i just got around to doing more testing with -cq - it turns out it's just ignored ;)" [17:33:57 CET] <thebombzen> oh I mssed that [17:33:58 CET] <thebombzen> lol [17:34:12 CET] <alexpigment> no worries ;) [17:34:22 CET] <thebombzen> silly me l2read [17:34:53 CET] <alexpigment> it's hard to read everything, i know, but you responded to me right after i said it ;) [17:53:00 CET] <fudge111> in "man ffmpeg-all" there is an example for aeval [17:53:06 CET] <fudge111> "eval=val(0)|-val(1)" [17:53:17 CET] <fudge111> shouldn't it be: [17:53:17 CET] <fudge111> "aeval=val(0)|-val(1)" [17:54:35 CET] <thebombzen> if it's a simple typo you can just submit a patch [17:54:40 CET] <thebombzen> I don't see why it would be rejected [18:18:36 CET] <BtbN> alexpigment, thebombzen ffmpeg will soon have -qt for nvenc, and print a deprecation warning about using -global_quality [18:18:43 CET] <BtbN> -qp [18:18:52 CET] <thebombzen> soon as in "patch was accepted" [18:18:54 CET] <thebombzen> ? [18:19:01 CET] <BtbN> Soo as in I will push it in a minute or so [18:19:04 CET] <BtbN> *Soon [18:19:16 CET] <thebombzen> lol that's soon [18:29:41 CET] <sikilikis> any ffmpeg pros on here? I'm reaching my limit and I need professional help [18:30:14 CET] <DHE> just state the problem, including pastebins of the full command-line and output. censor any private information but keep the command-line otherwise fully intact [18:31:30 CET] <sikilikis> I'll do that later. I'm not at my home computer right now so I can't get any of that, but I was hoping I could at least get pointed in the right direction and hopefully figure it out [18:32:00 CET] <sikilikis> running it on a raspberry pi. Compiled the 3.2.4 version. [18:32:18 CET] <sikilikis> I'm trying to take in an animated gif, capture audio from pulse, and livestream that to youtube. [18:32:19 CET] <BtbN> Use latest master, specially if you are compiling yourself anyway. [18:32:38 CET] <BtbN> Also, video encoding on an RPi is not fun [18:32:43 CET] <sikilikis> and it works for a while, but at some point it simply hangs on a frame and the output just repeats that same frame. The stream gets killed [18:32:51 CET] <sikilikis> yeah for my use case its perfectly fine if it goes 10 fps [18:33:05 CET] <BtbN> latest master has support for the hw encoder on the Pi [18:33:23 CET] <sikilikis> I had tried this on like 2.7 or something as well as this current release. and its always random [18:33:35 CET] <BtbN> There was no support until recently. [18:33:38 CET] <sikilikis> it stays up for about 43 hours before locking up. Sometimes it just goes 20 minutes [18:33:47 CET] <sikilikis> I'm using the libx264 encoder. [18:34:09 CET] <sikilikis> I think I tried the hardware encoder but performance didnt improve since I'm also using the drawfilter [18:34:21 CET] <sikilikis> or something I dunno. Like I said the low fps is perfectly fine. [18:34:50 CET] <sikilikis> it just always ends up locking up on some frame and stays there. It doesn't crash and the cpu stays at 100% [18:34:51 CET] <BtbN> the encoder running slow and skipping frames is not a clean way to recude the framerate, and can easily be what leads to your issue [18:34:58 CET] <sikilikis> but nothing is encoding and the stream stops [18:35:15 CET] <sikilikis> well when I check the log, there is no indication that frames are being skipped [18:35:21 CET] <sikilikis> there are no warnings [18:35:30 CET] <BtbN> The CPU being locked at 100% is a clear indication that the encoder can't keep up [18:35:34 CET] <sikilikis> it just happily displays the frame number every half second or so [18:36:02 CET] <sikilikis> hmm. When its working it will use the four cpus at around 30-50% each [18:37:11 CET] <sikilikis> I dont remember the output but it might spit out something like "frame=100 fps=10 <etc etc [18:37:31 CET] <sikilikis> and eventually it will keep outputting with the same frame number but the fps slowly decreases [18:37:58 CET] <sikilikis> so its might say "frame= 100 fps=10" then "frame= 100 fps=9.9" ... "frame=100 fps=2.0" etc [18:38:48 CET] <sikilikis> and at that point the entire terminal seems unresponsive and I gotta ctrl-c [18:39:17 CET] <kepstin> sikilikis: you're using x264 with nearly default options? it can buffer a *lot* of frames in memory as it encodes, and periodically has to flush them out. this is normal behaviour [18:39:19 CET] <BtbN> Have you tried latest master? [18:39:31 CET] <sikilikis> Once I get home I'll get as much info as I can but I'm hoping you've seen this symptom before [18:39:46 CET] <kepstin> sikilikis: if you're doing realtime encoding, you might want to tune x264 to reduce the frames it buffers [18:39:55 CET] <sikilikis> for the libx264 lets see [18:40:26 CET] <sikilikis> I change the key interval, set the preset to ultrafast or veryfast (neither made a different in performance) [18:40:37 CET] <sikilikis> bitrate at like 1000k [18:41:02 CET] <kepstin> sikilikis: how is ram usage on the machine looking? is it going into swap? that would cause a slowdown like that [18:41:07 CET] <sikilikis> I'll try the latest master when I get home [18:41:24 CET] <sikilikis> memory usage stays somewhere between 100-110mb [18:41:56 CET] <ffmpeg> Hi [18:42:12 CET] <kepstin> sikilikis: also, what are you outputting to? [18:42:18 CET] <sikilikis> but I haven't done any extensive checking. sometimes it lasts hours and sometimes I'm just not around when it finally locks up (like right now) [18:42:27 CET] <kepstin> e.g. if it's a network stream over wifi, it could just be network issues... [18:42:27 CET] <sikilikis> outputting to youtube [18:42:32 CET] <sikilikis> ethernet [18:43:08 CET] <ffmpeg> Does anybody knows what's the simplest way of "converting" any video/audio to an audio webm? [18:43:31 CET] <kepstin> ffmpeg -i anyvideo.whatever -map 0:a audio.webm [18:44:06 CET] <kepstin> (additional options might be desired to use opus rather than vorbis, or adjust audio encoding quality) [18:45:03 CET] <ffmpeg> thanks kepstin [18:46:55 CET] <fudge111> I use 2.3 version, is it lacks a lot from 3.2.4 version ? [18:47:14 CET] <sikilikis> Ive been constantly tweaking the parameters as well and chasing a bunch of different issues. I used to get "non monotonous dts" errors and now they're gone. I used to get "past duration too large" errors and those are gone too [18:47:20 CET] <sikilikis> but it still always breaks at some point [18:47:47 CET] <sikilikis> happened with both an older version and the current stable version [18:48:13 CET] <sikilikis> I'm assuming a 24/7 live stream is actually possible with ffmpeg right? [18:48:19 CET] <sikilikis> or just live streaming to some rtmp server forever? [18:49:24 CET] <furq> sikilikis: pastebin the command [18:49:51 CET] <sikilikis> I'm not at my home computer at the moment so I can't. As soon as I get home I'll do that [18:49:59 CET] <furq> kepstin: if it's an rpi then it won't have any swap [18:50:29 CET] <sikilikis> I tried it with an image that sets up like 100mb of swap memory. It still happened [18:50:42 CET] <furq> that's probably not a good idea [18:50:55 CET] <furq> i'd rather just let shit get oom killed on a pi than have to deal with swapping to an sd card [18:51:01 CET] <sikilikis> well the pi itself isnt running anything else. theres no desktop installed or anything [18:51:08 CET] <furq> i meant in general [18:51:12 CET] <sikilikis> yeah I installed a different image. it has no swap [18:51:14 CET] <kepstin> sikilikis: ffmpeg has no automatic reconnect or anything, so a reliable 24/7 stream would require some script to restart it if needed. [18:51:14 CET] <furq> if it's not swapping then it doesn't matter [18:51:43 CET] <furq> well that's no good if it's hanging [18:52:03 CET] <furq> is it just the ffmpeg process hanging or the entire system [18:52:08 CET] <sikilikis> just ffmpeg [18:52:33 CET] <sikilikis> system is headless as well. I use ssh+screen [18:52:38 CET] <sikilikis> so theres no desktop installed [18:52:47 CET] <furq> i take it the gif or the drawtext is updating dynamically so there's some actual reason to encode it [18:52:56 CET] <sikilikis> I use pulseaudio, mpg123 (some terminal mp3 player) and ffmpeg [18:53:03 CET] <sikilikis> yes that is correct [18:53:13 CET] <sikilikis> I use -ignore_loop 0 -i <my gif> [18:53:17 CET] <sikilikis> and the drawtext filter [18:53:26 CET] <furq> is the text updating dynamically [18:53:42 CET] <furq> because if not you could just preencode one loop and then not have to waste the cpu encoding the same thing forever [18:53:48 CET] <sikilikis> I tried to turn the gif into an mp4 first and use -stream_loop -1 but that didnt work at all. It would immediately hang at like frame 11 [18:53:56 CET] <sikilikis> the text updates dynamically [18:54:16 CET] <furq> nvm then [18:54:43 CET] <sikilikis> -threads 4 if that matters [18:55:09 CET] <furq> i probably wouldn't set -threads but that shouldn't be the problem [18:55:09 CET] <sikilikis> libmp3lame is the audio encoder [18:55:42 CET] <sikilikis> is it possible that there is some deadlock happening because its using multiple threads? [18:56:02 CET] <sikilikis> let me see if I remember the complete command [18:56:04 CET] <furq> i doubt it [18:56:12 CET] <furq> libx264 would default to more than 4 threads though [18:56:23 CET] <furq> the default is logical cores * 1.5 [18:56:55 CET] <sikilikis> going from 4 to 6 probably won't change much though [18:57:05 CET] <furq> probably [18:57:06 CET] <kepstin> if you just wait it out, does it start making progress again? Does it do this when saving to a file or only network? [18:57:11 CET] <sikilikis> no [18:57:47 CET] <sikilikis> I haven't tried saving to a file but this is supposed to be running 24/7 [18:58:23 CET] <kepstin> well, you could try just writing to /dev/null and see if it still has the same issue [18:58:30 CET] <kepstin> to rule out network problems [18:59:50 CET] <sikilikis> if it were a network problem, would it lead to the symptom I described? [19:01:12 CET] <kepstin> not sure. you said the cpu usage stays at 100%? if so, probably not [19:01:29 CET] <kepstin> does it always happen around some number of frames into the video? [19:01:29 CET] <sikilikis> one only core stays at 100% [19:01:38 CET] <sikilikis> no its completely random [19:01:50 CET] <sikilikis> like i mentioned before, it once lasted 43 hours before hitting that issue [19:01:54 CET] <kepstin> hard to say then :/ [19:01:57 CET] <sikilikis> and sometimes it doesnt even last 20 minutes [19:02:32 CET] <sikilikis> I'll try to get pull log output with -loglevel 99 once I get home but again, if it lasts hours then it's going to be a long log [19:03:01 CET] <sikilikis> does ffmpeg have any sort of built in logging or do I just need to do something like ffmpeg ... > log.txt 2>&1 [19:07:58 CET] <kepstin> but yeah, other than making sure your x264 library is up to date, I can't really think of anything. it is a really widely tested library, and the multithreading in it is known to work quite well... so it's *probably* not x264. [19:08:22 CET] <sikilikis> my other suspicion is that it might be the audio [19:08:27 CET] <kepstin> and intermittent failures over a large range of timespans does lead me to think that it might be network related. [19:08:59 CET] <sikilikis> I just remembered. sometimes after killing it I'll try to restart it and it doesnt start up [19:09:19 CET] <sikilikis> it will just print the sort of header information and stay there. CPU stays at like 0 or 1% [19:09:45 CET] <sikilikis> so I'll usually just kill mpg123 and pulseaudio and restart it [19:10:33 CET] <sikilikis> but I have no idea how that would break things. Initially I would always get non monotonous dts output warnings [19:10:47 CET] <sikilikis> I added the +getpts flag [19:11:53 CET] <alexpigment> anyone know if NVENC supports MBAFF? [19:12:02 CET] <earnestly> The latest commit c359d624d3efc3fd1d83210d78c4152bd329b765 "hevcdec: move decoder-independent declarations into a separate header" has broken the build with: libavformat/hevc.c:24:29: fatal error: libavcodec/hevc.h: No such file or directory [19:12:25 CET] <alexpigment> or - perhaps - if it supports a 30p 'fake interlaced' mode like x264 does? [19:12:29 CET] <earnestly> I assume the appropriate compiler flags weren't updated to reflect this new split [19:21:17 CET] <kepstin> alexpigment: looks like it does, depending on gpu and driver support (some google searching makes it sound like the drivers are occasionally buggy on interlaced stuff), but ffmpeg's nvenc driver won't use mbaff mode. (it can encode interlaced stuff tho) [19:22:43 CET] <kepstin> (if -flags +ildct is set, ffmpeg tells nvenc to use "Field mode") [19:24:13 CET] <kepstin> alexpigment: i'm not sure what you're talking about with x264 "fake interlaced", it can use mbaff for interlaced inputs just fine... [19:31:34 CET] <alexpigment> kepstin, yeah i can get it to be "interlaced", but Adobe Encore won't accept it for some reason, so I was hoping to see if MBAFF was supported [19:32:02 CET] <alexpigment> regarding "Fake Interlaced", that's a way to have 30p (or 25p) video be Blu-ray compliant [19:32:07 CET] <alexpigment> it's just a 2:1 pulldown flag i believe [19:36:38 CET] <kepstin> hmm, I assume nvenc is using paff mode then, i guess adobe encode just doesn't like that for some reason :/ [19:37:26 CET] <BtbN> kepstin, everytime I tested interlaced encoding with nvenc it was hilariously broken [19:37:42 CET] <BtbN> The API has support for it, and even claims hw support when doing the capability check [19:37:45 CET] <BtbN> but it just doesn't work [19:38:39 CET] <alexpigment> BtbN, i mean it *visually* works [19:38:44 CET] <kepstin> huh, apparently interlaced encoding was broken in a bunch of drives until very recently https://devtalk.nvidia.com/default/topic/976088/video-technologies/ffmpeg-h… :/ [19:38:49 CET] <kepstin> drivers* [19:38:49 CET] <BtbN> It never visually worked for me [19:39:07 CET] <BtbN> I haven't tested it in a while [19:39:16 CET] <BtbN> And the ffmpeg part of it being fine was always my impression of it [19:39:45 CET] <alexpigment> the strange thing about it is that it says "Scan Type: Interlaced" and "Scan type, store method: Separated fields" according to MediaInfo [19:40:03 CET] <alexpigment> i've never seen that separated fields entry in MediaInfo [19:40:22 CET] <kepstin> alexpigment: right, because x264 always use mbaff (it doesn't support paff) [19:40:43 CET] <alexpigment> yeah, but i believe mainconcept does PAFF and doesn't have that field [19:40:50 CET] <alexpigment> (as i recall, at least) [19:43:39 CET] <alexpigment> Kepstin: the thing you mentioned about it being broken in drivers until recently rings a bell. i think it was broken the last time i checked this 2 months ago [19:43:49 CET] <alexpigment> i probably have it in my notes and just forgot about it [19:53:16 CET] <arpu> anyone have uses opencv and ffmpeg i try to pipe a opencv BGR MAT to a ffmpeg pipe [19:53:47 CET] <arpu> cv::cvtColor(img,img, CV_BGR2YUV_I420); [19:53:58 CET] <arpu> but ffmpeg does not like it :/ [19:54:56 CET] <arpu> [rawvideo @ 0x2b96c80] Invalid buffer size, packet size 135168 < expected frame_size 12582912 [20:05:05 CET] <alexpigment> oh wow, NVENC interlacing introduces some really weird artifacting. the luma is fine, but i think the chroma is has some field swapping or something. just huge vertical bands during motion [20:21:58 CET] <sikilikis> yo is kepstin still on? [20:23:38 CET] <rjp421> ffmpeg --loglevel debug used to flood the screen with RTMP output, which included the function calls to the media server.... but now it only outputs a not-very-verbose summary [20:25:13 CET] <rjp421> arpu, what os? i have gotten around similar errors in linux, with (on a raspberry pi) LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libv4l/v4l1compat.so ffmpeg ... [20:25:22 CET] <furq> sikilikis: am i good enough [20:25:23 CET] <obamoose> Hello! [20:25:39 CET] <sikilikis> probably. You remember my problem right? [20:25:43 CET] <furq> i do [20:25:48 CET] <sikilikis> I just discovered something [20:25:57 CET] <sikilikis> I dont know why I never thought to check before [20:26:09 CET] <sikilikis> so its locked up right now. its using like 1% cpu [20:26:19 CET] <sikilikis> but I just noticed that pulseaudio is also using like 1% cpu [20:26:28 CET] <sikilikis> and i'm using pulse as the audio input [20:26:36 CET] <sikilikis> and the media player I'm using is seemingly halted as well [20:26:47 CET] <sikilikis> is it possible that ffmpeg is waiting for pulse? [20:26:47 CET] <furq> well that doesn't seem good [20:26:55 CET] <fudge111> I have 2.3 version is it lacking a lot in compare to 3.2.4 version ? [20:26:58 CET] <furq> it wouldn't surprise me [20:27:16 CET] <furq> you could try using alsa [20:27:32 CET] <sikilikis> I could never figure out alsa [20:27:50 CET] <furq> pulse is probably overcomplicated for a headless box [20:27:56 CET] <sikilikis> so I just killed my media player. ffmpeg just spit a bunch of [flv @ 0xb60de0] Non-monotonous DTS errors [20:28:00 CET] <sikilikis> and now it closed [20:28:02 CET] <furq> oh nice [20:28:04 CET] <sikilikis> like actually closed [20:28:08 CET] <furq> yeah that definitely sounds like pulse then [20:28:11 CET] <sikilikis> so its definitely pulse [20:28:19 CET] <sikilikis> how would I get alsa to work? [20:28:25 CET] <sikilikis> I tried that before and I couldnt figure it out [20:28:44 CET] <sikilikis> I ended up using pulse due to that reason [20:28:49 CET] <sikilikis> btw I don't much about either [20:28:51 CET] <furq> https://trac.ffmpeg.org/wiki/Capture/ALSA [20:29:15 CET] <sikilikis> yeah I looked at that but that assumes I'm using alsa as an input device [20:29:24 CET] <sikilikis> I want to basically capture output from an mp3 player [20:29:31 CET] <sikilikis> so like the "Desktop" audio even though there is no desktop [20:29:38 CET] <furq> oh [20:29:50 CET] <furq> https://trac.ffmpeg.org/wiki/Capture/ALSA#Recordaudiofromanapplication [20:30:38 CET] <furq> although if you're capturing from the player then maybe it's the player's fault, not pulse [20:30:51 CET] <sikilikis> it could be [20:30:56 CET] <furq> i guess using alsa is one way to find out [20:31:05 CET] <sikilikis> well I'm setting pulse as the input in ffmpeg [20:31:11 CET] <sikilikis> it could very well be the player as well though [20:31:21 CET] <sikilikis> but yeah if I can get just plain alsa to work thats better anyway [20:31:33 CET] <kepstin> why are you using a player into pulse into ffmpeg rather than having ffmpeg just read the media directly? [20:31:36 CET] <obamoose> furq: can you help me again ;_;? [20:31:46 CET] <rjp421> is there a way to see the exact RTMP function calls to/from the server, when outputting and/or ingesting RTMP(F)P/S/E/T/TE? [20:31:53 CET] <furq> i assume he wants to stream his playlist while he listens to it [20:31:56 CET] <sikilikis> its supposed to be a 24/7 stream [20:32:09 CET] <sikilikis> so I can't change the input without having to shut down the stream [20:32:15 CET] <furq> rjp421: maybe -v debug [20:32:42 CET] <sikilikis> ideally I also wanted to be able to change the playlist on the fly and maybe using alsa directly will let me do that [20:32:49 CET] <sikilikis> instead of crashing once the audio source stops [20:33:14 CET] <furq> yeah recording from loopback will just record everything that's going to speakers [20:33:49 CET] <sikilikis> the .asoundrc file is in the home directory? [20:34:01 CET] <sikilikis> actually nevermind I should be able to use the global [20:34:10 CET] <rjp421> i have yet to try but i hear jack is good for per-app audio piping [20:34:18 CET] <furq> yeah it's just in ~ [20:35:10 CET] <furq> fwiw you probably want to use the builtin aac encoder rather than lame [20:35:22 CET] <furq> assuming it's quick enough on an rpi [20:35:39 CET] <sikilikis> its not [20:35:41 CET] <sikilikis> I tried it [20:35:45 CET] <furq> i still need to build with fdk and see if it's any faster on a pi [20:35:49 CET] <sikilikis> youtube kept complaining that it wasnt receiving enough frames [20:35:51 CET] <furq> since that's designed for mobile devices [20:36:12 CET] <sikilikis> which is weird because it seemed to be pushing the same framerate as liblamemp3 [20:36:17 CET] <furq> fun [20:36:35 CET] <sikilikis> okay ffmpeg is complaining that it doesnt know the alsa format. What do I need to enable in the configure step? [20:36:49 CET] <furq> nothing, but you need libasound2-dev installed [20:37:05 CET] <furq> also yeah if you're rebuilding then you might want to build with fdk-aac [20:37:25 CET] <sikilikis> I couldnt find any apt-get package for that and didnt feel like compiling another package [20:37:39 CET] <furq> libfdk-aac-dev [20:37:43 CET] <sikilikis> im actually really shit when it comes to manually compiling stuff and installing it under linux [20:38:01 CET] <sikilikis> that package isnt available on raspberry pi [20:38:07 CET] <furq> is that raspbian [20:38:15 CET] <sikilikis> and I'm hesitant to add new sources because they always fuck up the dependencies [20:38:20 CET] <sikilikis> its minibian but its based off raspbian [20:38:57 CET] <furq> it's usually ok to install debs manually [20:39:02 CET] <furq> https://packages.debian.org/jessie/armhf/libfdk-aac-dev/download [20:39:13 CET] <furq> but yeah don't add more repos, especially not on raspbian which seems particularly flaky with that [20:39:43 CET] <sikilikis> to install a deb its dpkg -i <file> right? [20:39:47 CET] <furq> https://packages.debian.org/jessie/armhf/libfdk-aac0/download [20:39:50 CET] <furq> and that as well ofc [20:39:50 CET] <furq> and yeah [20:40:02 CET] <furq> oh actually nvm [20:40:05 CET] <furq> it's in non-free [20:40:10 CET] <furq> you probably just need to add non-free to sources.list [20:40:50 CET] <rjp421> furq, http://pastebin.com/raw/fqu3sj7t [20:41:19 CET] <furq> well that's something at least [20:41:28 CET] <furq> i doubt you'll get anything more detailed than that [20:41:51 CET] <rjp421> furq, but debug is supposed to be much more verbose [20:42:05 CET] <furq> shrug [20:42:07 CET] <furq> i'm not a developer [20:42:32 CET] <rjp421> it used to floot the rtmp packets along with the function and amf objects [20:42:37 CET] <rjp421> flood [20:42:43 CET] <furq> was that with librtmp [20:42:43 CET] <rjp421> i am, i need that info lol [20:43:26 CET] <rjp421> i think it was.. is that not used anymore? [20:43:46 CET] <furq> it is with --enable-librtmp [20:43:58 CET] <furq> your build is using the internal rtmp stuff [20:44:22 CET] <sikilikis> I'll get back to you when I finish installing and recompiling [20:44:35 CET] <sikilikis> though I guess I won't know if it breaks until I see it break [20:44:49 CET] <rjp421> librtmp is old and doesnt support the different protocols, or user:pass@server authentication... so i built without librtmp [20:44:56 CET] <sikilikis> are there any other good terminal-only mp3 players, incase it is the mp3 player thats causing the trouble? [20:45:04 CET] <sikilikis> I'm using mpg123 [20:45:08 CET] <furq> rjp421: yeah i don't necessarily recommend librtmp [20:45:13 CET] <furq> sikilikis: moc, mpd, xmms2 [20:45:22 CET] <sikilikis> mpd is kind of heavy isnt it? [20:45:29 CET] <furq> oh and cmus [20:45:33 CET] <furq> i think cmus is the one i use on my laptop [20:45:41 CET] <furq> mpd and xmms2 are relatively heavyweight [20:45:43 CET] <sikilikis> does it do playlists? [20:45:46 CET] <rjp421> for the sake of seeing this simple call i need, ill rebuld with librtmp :( [20:45:48 CET] <furq> probably [20:45:53 CET] <sikilikis> and can it shuffle? [20:45:57 CET] <furq> probably [20:46:48 CET] <kerio> do you guys know if quicktime understands single-file HLS with byte ranges? [20:48:39 CET] <ritsuka> quicktime can do byte ranges with mov and mp4, no idea about hls [20:52:50 CET] <sikilikis> for alsa I don't need to enable anything during configure right? just having libasound2-dev is enough? [20:53:12 CET] <furq> it should show up in the devices list in the configure output [20:56:04 CET] <kerio> apparently the example fmp4 hls stream on apple's website has a single mp4 file with byteranges :o [20:56:12 CET] <kerio> is there a simple way to tell the hls muxer to do that? [20:57:31 CET] <sikilikis> even if this doesnt work, thanks a lot for your help [20:57:46 CET] <sikilikis> spent all this fucking time and I didn't even bother to check if it was the sound causing the problems [20:58:23 CET] <furq> there's a linear relationship between how long it takes to track down a bug and how likely it is to be something completely fucking stupid [20:58:35 CET] <sikilikis> yup [21:08:27 CET] <arpu> rjp421, yes linux fedora the old v4l1compat use software color convert and its slow [21:09:05 CET] <arpu> think its not a good solution [21:09:16 CET] <arpu> but i will try thx! [21:16:42 CET] <rjp421> arpu, im curious if it works, pls let me know [21:29:13 CET] <sikilikis> it looks to be working [21:29:21 CET] <sikilikis> sound is being capture correctly [21:30:32 CET] <sikilikis> holy shit furq you're a genius [21:32:09 CET] <sikilikis> hmm. I see this at the beginning: [alsa @ 0xc61b50] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8) [21:32:13 CET] <sikilikis> should I worry about that? [21:32:36 CET] <BtbN> you are running too slow [21:32:43 CET] <BtbN> so it eventually stalls and/or drops frames [21:33:00 CET] <sikilikis> for alsa in particular or everything? [21:33:11 CET] <sikilikis> and yeah its going slow. like 12 fps. But the music sounds fine [21:33:13 CET] <furq> does that actually mean that [21:33:39 CET] <BtbN> I'd interpret it as ffmpeg being unable to empty the message queue in time [21:33:58 CET] <BtbN> Because the "main loop" didn't get back to alsa fast enough [21:34:04 CET] <furq> i get that all the time piping from vapoursynth and it doesn't mean anything there [21:34:06 CET] <BtbN> making it bigger, like the message suggests, might help [21:34:23 CET] <sikilikis> actually I tried that once but it didnt make a difference [21:34:32 CET] <furq> if increasing it makes no difference then you can probably ignore it [21:34:33 CET] <sikilikis> to like 512 and 1024 [21:34:42 CET] <sikilikis> i mean the error still showed up [21:35:18 CET] <BtbN> you should probably use the hardware encoder [21:35:53 CET] <sikilikis> I just compiled it with that and I think I decided not to use it because performance didnt improve and the picture quality was worse [21:35:58 CET] <rjp421> rpi hw encoder? do u have a working cmd by chance? [21:36:06 CET] <furq> -c:v h264_omx [21:36:14 CET] <sikilikis> I can try that [21:36:15 CET] <furq> there's not much else you can tune with that encoder other than -b [21:36:26 CET] <sikilikis> -b? [21:36:28 CET] <sikilikis> bitrate? [21:36:28 CET] <BtbN> no cbr/vbr/cqp [21:36:29 CET] <furq> bitrate [21:36:31 CET] <BtbN> +? [21:36:37 CET] <furq> not as far as i know [21:36:44 CET] <furq> they might exist in omx but i don't think they're wired up [21:36:56 CET] <sikilikis> I dont use any of those options... [21:37:09 CET] <rjp421> furq, what about setting the v4l capture size and bitrate etc, to as close to the output as u can get? [21:37:20 CET] <furq> huh [21:37:35 CET] <rjp421> isnt that a waste of resources? [21:37:51 CET] <furq> i'm not sure what you're asking [21:37:59 CET] <rjp421> when the pi cam is 720p/1080i? [21:38:06 CET] <sikilikis> anyway I can pastebin my command now if you're interested [21:38:24 CET] <furq> scaling will use more resources than not scaling, sure [21:38:45 CET] <furq> that's equally true with any encoder [21:38:50 CET] <rjp421> like in the cmd i psated, "v4l2-ctl -d /dev/video4 --set-fmt-video=width=1280,height=720,pixelformat=1 --overlay=0 --set-ctrl video_bitrate=14000000 ; sleep 1 ; raspivid -t 0 -w 1280 -h 720 -vf -hf -pf main -fps [21:38:50 CET] <rjp421> 24 -g 48 -b 14000000 -ih -v -o - | ffmpeg ..." [21:39:13 CET] <rjp421> video4 is my rpi cam [21:42:45 CET] <rjp421> furq, what i mean is, does setting the capture like that, have any benefit over using ffmpeg and h264_omx? also what about input and type? just -i /dev/video4? [21:43:26 CET] <furq> you can just do -video_size 1280x720 -i /dev/video4 [21:43:38 CET] <furq> !indev v4l2 [21:43:38 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2 [21:44:10 CET] <rjp421> cool, ty [21:45:43 CET] <rjp421> im still using the raspivid... i dont really want to have to play around four hours to get a final working cmd :p [21:47:33 CET] <rjp421> for* [21:48:39 CET] <sikilikis> i'm using the hw encoder now anyway. It doesn't perform any faster but it does use less cpu so thats goo [21:49:16 CET] <sikilikis> and I set -threads 0 instead of -threads 4. Don't know if that will help but you said it will default to <num of cores> * 1.5 right? [21:49:26 CET] <furq> you can just not set -threads at all [21:49:32 CET] <sikilikis> oh okay [21:52:14 CET] <sikilikis> here is my full command btw. Let me know if you see anything wrong: http://pastebin.com/3rB4uRty [21:52:27 CET] <sikilikis> it works but I mean I'm sure I'm doing something stupid [22:00:57 CET] <sikilikis> wait if I use h264_omx and leave out the -threads option, will it still be multithreaded? or does it not matter? [22:07:48 CET] <BtbN> the default is to use all cores [22:12:34 CET] <sikilikis> cool [22:12:56 CET] <sikilikis> its working though I won't know if its completely fixed until I see it last at least two days [22:13:27 CET] <BtbN> Once the timestamps overflow, things will get wonky anyway [22:13:35 CET] <BtbN> So you might want to restart once per day [22:14:28 CET] <sikilikis> I'll look into that, but what I'm interested in right now is consistency [22:14:54 CET] <sikilikis> if it can consistently last at least 24 hours without any problems then I can set it up to restart every night [22:15:19 CET] <sikilikis> but I mean last time it ran for 43 hours before it fucked up [22:15:26 CET] <sikilikis> and now I know that it was due to pulse and not ffmpeg [22:15:39 CET] <sikilikis> well its either pulse or its mpg123 [22:15:56 CET] <sikilikis> but I'm still in a much better position now [22:16:11 CET] <sikilikis> pulse is gone now and it feels more stable, so it was probably that [22:16:20 CET] <sikilikis> but if not then I just have to find another mp3 player [22:19:54 CET] <sikilikis> anyway i think im good for now [22:20:00 CET] <sikilikis> thanks everyone who helped me [22:25:52 CET] <sikilikis> actually one more quick question [22:26:00 CET] <sikilikis> what will happen when the timestamps overflow [22:26:03 CET] <sikilikis> would it just crash? [22:27:46 CET] <rjp421> sikilikis, i was checking out that cmd.. thats on a pi? is the video just text with a bg? 1000k seems a bit much for a mostly static image... [22:28:11 CET] <sikilikis> its an animated gif [22:28:22 CET] <rjp421> i havent seen '-rtmp_live live' before, im going to try it after this rebuild [22:28:32 CET] <sikilikis> and i dont need the bitrate really. When i left it out it used like 500kbs [22:28:35 CET] <sikilikis> but its also streaming music [22:29:06 CET] <sikilikis> i have no idea what the rtmp_live option does but this was when I was googling a bunch and found various solutions to problems I now know I never had [22:29:21 CET] <rjp421> possibly set audio bitrate with -b:a 128k etc [22:29:25 CET] <sikilikis> it seems like its a correct option though. its a live stream [22:29:35 CET] <sikilikis> I had that before as well. it didnt really make a difference though [22:29:59 CET] <sikilikis> I suppose it wouldnt hurt to add though [22:31:43 CET] <sikilikis> right now its streaming at 700kb/s [22:31:58 CET] <sikilikis> and youtube recommends like 500-1000k for a simple 480p stream, which this is [22:34:39 CET] <furq> i assume -rtmp_live is an input option [22:35:28 CET] <BtbN> I think it's an output one [22:35:34 CET] <BtbN> turning on "livestreaming mode" [22:35:46 CET] <sikilikis> "-f flv -rtmp_live live $URL" [22:35:50 CET] <sikilikis> thats at the end [22:36:09 CET] <furq> BtbN: what other mode would there be for an rtmp output [22:36:24 CET] <sikilikis> I dunno lol [22:36:24 CET] <BtbN> vod [22:36:28 CET] <sikilikis> but its there and it exists [22:36:43 CET] <furq> how would you output vod [22:37:02 CET] <BtbN> I think it's purely meant as an indicator if the content is live or pre-recorded. [22:37:24 CET] <furq> The default value is any, which means the subscriber first tries to play the live stream specified in the playpath. If a live stream of that name is not found, it plays the recorded stream. The other possible values are live and recorded. [22:37:32 CET] <furq> my reading of that is that it does something for rtmp inputs [22:37:55 CET] <furq> i guess maybe it could send something to the server when used with an output [22:38:02 CET] <furq> either way i've never needed it [22:39:26 CET] <sikilikis> hmm. think I should remove it then? [22:39:37 CET] <sikilikis> it probably is used for live inputs [22:39:53 CET] <furq> you might as well [22:40:14 CET] <furq> shorter commands are generally better [22:41:20 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/rtmpproto.c#L3116 it's definitely an output flag [22:41:39 CET] <sikilikis> well for what its worth, i've been quickly modifying the command, killing ffmpeg and restarting it. and it hasnt had any problems [22:41:41 CET] <BtbN> oh, nevermind. Read the wrong line [22:42:19 CET] <sikilikis> normally by now it would have refused to work and I'd have to reboot [22:43:19 CET] <sikilikis> here's the actual stream if you're interested in seeing what the pi can do: https://www.youtube.com/watch?v=EgbVOsom6CU [22:43:45 CET] <sikilikis> but I won't know if its truely working until I can consistently get it to run for like 50+hours every time [22:43:50 CET] <sikilikis> so here's hoping [22:44:17 CET] <furq> Playing soundtracks from your favorite games on NES, Gameboy, Sega Master System, and Game Gear. [22:44:22 CET] <furq> what if my favourite soundtracks are on the megadrive [22:44:47 CET] <sikilikis> thats the genesis right? [22:44:59 CET] <sikilikis> I've been debated whether I want to add 16-bit to that list [22:45:00 CET] <furq> if you must [22:45:08 CET] <sikilikis> haha. american here so [22:45:38 CET] <sikilikis> I need to add space to the pi unfortunately and I dont have too many flash drives or externals I can spare [22:45:49 CET] <sikilikis> but first things first is that I need to get it working right [22:45:57 CET] <sikilikis> then I can add all the megadrive games you want [22:46:10 CET] <sikilikis> (I didnt grow up with a sega so...) [22:48:38 CET] <furq> https://www.youtube.com/watch?v=LzMZuKZAfgc&t=20m52s [22:48:40 CET] <furq> do you have this [22:49:56 CET] <sikilikis> uh [22:49:57 CET] <sikilikis> lemme check [22:50:22 CET] <sikilikis> is that nes? [22:50:25 CET] <furq> yeah [22:50:53 CET] <furq> i have an nsfe of it so you probably should too [22:50:55 CET] <sikilikis> Zombie Nation yes I do [22:51:32 CET] <Darxus> Ugh, I concatenated a 17 video clips together, totalling about an hour, and some of them are coming out upside down. Viewing the clips by themselves looks fine. I used -f concat, with "ffmpeg version N-84348-gdb7a05d", statically compiled, for windows. [22:51:32 CET] <alexpigment> speaking of NSF, the dude who invented that format - "Kevtris" just put out a pretty awesome retro game console [22:53:03 CET] <Darxus> Any guesses how I could fix this? [22:53:19 CET] <sikilikis> kevtris? [22:53:33 CET] <alexpigment> yeah, kevin horton - his internet name is Kevtris [22:54:11 CET] <alexpigment> but he engineered the Analogue NT Mini, which is an FPGA-based NES console which also supports "Flashing" the core hardware to a number of 8-bit systems (gameboy, master system, atari, etc) [22:54:35 CET] <alexpigment> an extremely well-designed system with none of the downsides of emulation [22:54:46 CET] <Darxus> The video was recorded on an android phone (Samsung Galaxy S4). [22:54:54 CET] <alexpigment> Darxus - i take it some of those videos were shot upside down? [22:55:00 CET] <alexpigment> yeah, phone videos. makes sense [22:55:20 CET] <alexpigment> i forgot the parameters needed to detect the rotation properly [22:55:51 CET] <alexpigment> i'll look and see if i have any notes on that (others here probably know off the top of their heads though) [22:55:56 CET] <furq> you can detect it in ffprobe and fix it with -metadata:s:v:0 rotate=xx -c copy [22:56:11 CET] <Darxus> alexpigment: It's quite possible the phone was rotated differently when they were recorded, yes. [22:56:13 CET] <furq> where xx is 0 or 180 depending on what ffprobe says [22:56:25 CET] <furq> you'd need to fix it in all the clips that are wrong and then concat them again [22:56:54 CET] <Darxus> There isn't a way to get ffmpeg to just... detect the rotation properly? [22:56:58 CET] <alexpigment> Darxus, is this a 1-time job or do you need this to be an automatic detection? [22:57:29 CET] <furq> if the clips are actually inverted and not just by metadata then you might need to actually reencode [22:57:39 CET] <furq> actually [22:57:47 CET] <alexpigment> yeah, re-encoding is certainly necessary at some step in this process [22:57:52 CET] <Darxus> I'm re-encoding anyway, to use vidstab. [22:57:57 CET] <furq> if they're just flipped by metadata then there's no need [22:58:11 CET] <furq> but if you're reencoding anyway then never mind [22:58:22 CET] <furq> i'm not really sure how ffmpeg deals with rotation metadata in concat [22:59:02 CET] <Darxus> alexpigment: I guess it's a 1-time job. [22:59:33 CET] <alexpigment> i have a rotate script i made a while back [22:59:36 CET] <alexpigment> -filter:v "hflip,vflip" -metadata:s:v:0 rotate=0 [22:59:42 CET] <alexpigment> that's the important part of it [23:00:05 CET] <alexpigment> basically it's flipping it and then removing the embedded metadata for the rotation [23:00:21 CET] <furq> sikilikis: fwiw cmus and moc both use libavcodec, so they can play back emulated formats directly if your ffmpeg was built with libgme [23:00:30 CET] <furq> xmms2 and mpd can probably do that too [23:00:44 CET] <Darxus> alexpigment: And I'd need to do that only for the clips that are upside down, and not the rest? [23:00:49 CET] <alexpigment> right [23:00:53 CET] <sikilikis> eh by this point I like [23:00:57 CET] <alexpigment> it's not any sort of auto-detection [23:00:59 CET] <sikilikis> mp3 is perfectly fine for me [23:01:09 CET] <furq> well you said space was an issue and emulated formats are way smaller [23:01:11 CET] <sikilikis> and if its truly working now I'd like to stop spending time on it lol [23:01:15 CET] <alexpigment> but i made a batch script, so i just drag the files in question on the bat, it quickly re-encodes them, and then it's done [23:01:17 CET] <sikilikis> oh I suppose [23:01:38 CET] <sikilikis> but does it support any emulated format? [23:01:45 CET] <furq> it supports all the important ones [23:01:50 CET] <furq> it doesn't do obscure stuff like mdx or s98 [23:01:57 CET] <alexpigment> Darxus: i'm sure it's possible to do it in a more automated way, but that's beyond my skill level [23:02:05 CET] <furq> https://github.com/mcfiredrill/libgme/blob/master/readme.txt [23:02:16 CET] <sikilikis> I don't know anything about emulated formats though [23:02:25 CET] <sikilikis> like are all the songs already predefined lengths? [23:02:30 CET] <furq> depends on the format [23:02:38 CET] <sikilikis> and also these mp3s tend to come with meta data so I can easily get the game and title [23:02:39 CET] <Darxus> I'm kind of more curious about implementing automatic detection in ffmpeg than dealing with this manually. [23:02:53 CET] <furq> the good emulated formats have metadata and correct track lengths [23:02:57 CET] <furq> vgm and nsfe do [23:03:05 CET] <furq> gbs doesn't though [23:03:09 CET] <sikilikis> oh [23:03:11 CET] <sikilikis> hmm [23:03:20 CET] <sikilikis> that will definitely be a v2 kind of thing [23:03:21 CET] <alexpigment> Darxus: understandable. that's why i asked if it was a one-time thing or not [23:03:31 CET] <alexpigment> if it's one=time fixing them like this would be quicker overall [23:04:47 CET] <Darxus> "FFMPEG recently changed the default behavior to auto rotate input video sources with "rotate" meta data." - version 2.7 - http://stackoverflow.com/questions/9408542/video-captured-from-iphone-gets-… [23:05:24 CET] <alexpigment> well, it's possible that the problem here is that you're doing concat, and that filter doesn't assume re-encoding [23:05:33 CET] <furq> Darxus: try with -noautortate before -i [23:05:39 CET] <furq> -noautorotate [23:06:02 CET] <furq> probably do a test encode with -ultrafast to make sure you're not wasting your time [23:06:10 CET] <Darxus> I... need to figure out a test set that doesn't take a whole day to re-encode :) [23:06:10 CET] <furq> -preset ultrafast [23:06:11 CET] <alexpigment> furq - that seems counterintuitive - what's your thought process? [23:06:36 CET] <furq> if the flipped videos are the right way up but flipped by metadata then that should fix it [23:06:40 CET] <alexpigment> ahh [23:06:44 CET] <alexpigment> makes sense [23:07:15 CET] <furq> Darxus: ffmpeg -noautorotate -i concatlist -preset ultrafast test.mp4 [23:07:38 CET] <alexpigment> downscaling would also save some time [23:07:46 CET] <alexpigment> e.g. -s 320x180 [23:12:55 CET] <Darxus> alexpigment: Weird, that said "option video size not found" (not copied and pasted). [23:13:59 CET] <Darxus> Okay, the two smallest clips do reproduce this result (without -noautorotate). [23:14:42 CET] <furq> -s goes after the input file [23:15:53 CET] <Darxus> furq: -noautorotate didn't help: ffmpeg.exe -f concat -safe 0 -noautorotate -i sample.txt -preset ultrafast sample2.mp4 [23:16:17 CET] <furq> shame [23:16:39 CET] <furq> i guess they are actually upside down then [23:16:45 CET] <furq> which is trickier to deal with in one go [23:16:51 CET] <alexpigment> ok, so is the difference here that you're doing -f concat vs the concat filter? [23:17:22 CET] <alexpigment> again, maybe -f concat assumes no re-encoding, whereas the concat filter *does* assume re-encoding [23:17:44 CET] <Darxus> So how do I figure out if "version N-84348-gdb7a05d" is at least as new as version 2.7? [23:17:45 CET] <alexpigment> i seem to recall there's two ways to concat, right? [23:18:01 CET] <alexpigment> what's the date of the file? [23:18:09 CET] <Darxus> alexpigment: At least two... [23:18:22 CET] <alexpigment> if it's older than a few months, just get the newest static built from zeranoe [23:18:26 CET] <furq> Darxus: db7a05d is two days old, so that should be fine [23:18:53 CET] <furq> https://github.com/FFmpeg/FFmpeg/search?q=db7a05d&type=Commits&utf8=%E2%9C%… [23:19:21 CET] <Darxus> So, my video clips have their rotation metadata recorded in some way ffmpeg is not recognizing? [23:19:35 CET] <furq> if it was metadata then noautorotate should have worked [23:19:41 CET] <furq> so i'm guessing they're actually recorded upside-down [23:19:55 CET] <furq> which is probably going to be a pain to deal with [23:20:24 CET] <Darxus> Well... if they're playing back right, outside of ffmpeg, they're either recorded right side up, or have metadata that the player is reading correctly and ffmpeg is not, right? [23:20:43 CET] <alexpigment> they're almost certainly recorded upside down with metadata that's being read to play them correctly [23:20:47 CET] <furq> ^ [23:20:58 CET] <alexpigment> that's how all phones work these days [23:21:27 CET] <Darxus> Right. So... I just need to figure out how my metadata is different than the rotation detection that's been implemented, and patch it? [23:21:30 CET] <alexpigment> anyway, again, my vote is for the concat filter. it's incompatible with stream copying, so it's likely applying all metadata information to the input [23:21:30 CET] <furq> it should in theory obey the metadata when reencoding [23:22:04 CET] <furq> yeah maybe try the filter [23:22:20 CET] <alexpigment> and in the case of the filter, don't use the -noautorotate flag [23:23:03 CET] <furq> -i normal.mp4 -i flipped.mp4 -preset ultrafast -filter_complex "concat=2:1:1[out]" -map "[out]" test.mp4 [23:23:36 CET] <Darxus> Thanks. [23:23:54 CET] <furq> if it works then you'll need to replace 2 with 17 for 17 inputs [23:24:17 CET] <furq> and uh [23:24:58 CET] <furq> -filter_complex "concat=17:1:1,vidstabtransform[out]" [23:25:42 CET] <furq> hopefully each file has one video and one audio track in that order or you'll have to specify 17 inputs to the filter [23:25:45 CET] <furq> that sounds like fun [23:25:53 CET] <alexpigment> as a random aside, i have a love/hate relationship with video stabilization. it has it's place, but i'm more often bothered by the look of stabilized video than i am shaky video (end mini rant) [23:26:02 CET] <Darxus> furq: Heh, I hope so. Seems likely. [23:26:20 CET] <alexpigment> furq: they're all camera videos - i presume on audio channel is going to be the norm ;) [23:26:27 CET] <furq> one would hope so [23:26:37 CET] <alexpigment> *one [23:26:47 CET] <Darxus> furq: Woo, that worked! Thank you. [23:29:08 CET] <Darxus> alexpigment: Yup, I... hate noticably stabilized videos. Not sure what I'm going to do about that. Seems like it should be possible to do without the artifacts. [23:29:30 CET] <alexpigment> i mean, you're creating something that doesn't exist. there are always downsides to that [23:29:39 CET] <alexpigment> kinda like motion interpolation on TVs [23:29:46 CET] <Darxus> I'm guessing the artifacts I'm currently getting are from lens distortion... [23:30:13 CET] <alexpigment> well, if you have a lossy stream, it's possibly those macroblocks are interfering with the vidstab [23:30:29 CET] <Darxus> alexpigment: I think I disagree, what I want is just sampling the subset of pixels that's roughly in the same place some subset in the previous and next frames. [23:31:02 CET] <alexpigment> yeah, but this is videos encoded from a camera in someone's hands, right? [23:31:08 CET] <Darxus> alexpigment: Yes. [23:31:23 CET] <alexpigment> if so, there's a lot of motion on both axe [23:31:26 CET] <alexpigment> *axes [23:31:38 CET] <alexpigment> and so the background is moving more than the foreground [23:31:55 CET] <alexpigment> and some of that background has to be made up as part of the stabilization, because it's being obscured by the foreground [23:32:01 CET] <alexpigment> that's where the weirdness comes from [23:32:04 CET] <alexpigment> making up the background [23:32:07 CET] <Darxus> Ah, good point, thank you. [23:32:31 CET] <alexpigment> if the motion only ever went truly up or down or left or right, stabilization would be easy [23:32:32 CET] <Darxus> Maybe... I will give up on producing videos :P [23:32:39 CET] <alexpigment> it's that z-axis that's the killer [23:32:45 CET] <alexpigment> haha, no [23:32:59 CET] <Darxus> Yup, it's an excellent argument that had not occurred to me. I wondered why it was being so hard :) [23:33:22 CET] <Darxus> But I suspect the primary artifact I'm getting probably is due to lens distortion. [23:33:29 CET] <Darxus> Wobbling at the corners each time I take a step. [23:33:44 CET] <alexpigment> oh, are you not overscanning and cropping? [23:34:03 CET] <Darxus> I'm using vidstab, which is cropping. [23:34:14 CET] <alexpigment> maybe i'm assuming too much. you have eyes and a brain, so i'll trust your assumption about lens distortion [23:34:37 CET] <Darxus> I'm guessing by overscanning you mean... recording a larger area than I'm using in the final result? [23:34:52 CET] <Darxus> I'm also very new to a lot of this stuff. [23:35:04 CET] <alexpigment> i just meant that there's an inherent zooming and cropping that is involved in video stabilization [23:35:08 CET] <Darxus> But the middle of the videos look great, it's just the corners wobbling. [23:35:14 CET] <alexpigment> otherwise you'd get an annoying black border moving everywhere [23:35:17 CET] <Darxus> Yes. [23:35:40 CET] <alexpigment> so i don't know. it may be worth seeing if there's a way to crop more of the outside [23:36:01 CET] <alexpigment> i've never used vidstab myself though, so i don't know what parameters are available [23:37:17 CET] <Darxus> furq: The concat method I was originally using is the demuxer, the one you suggested, which is rotating correctly, is the concat filter. It seems like there may be a bug worth filing against the demuxer? [23:37:36 CET] <furq> maybe [23:37:41 CET] <Darxus> alexpigment: Yeah, doing more cropping was something I've been meaning to try. [23:37:54 CET] <Darxus> I really should check if this thing runs vastly faster on my linux desktop. [23:38:16 CET] <furq> it might not be possible for it to work with the demuxer [23:38:31 CET] <Darxus> furq: I have difficulty with that statement :P [23:38:43 CET] <alexpigment> Darxus re the concat thing, i think that's just how it should work probably. if you were using the concat demuxer, you could simply do -copy and copy the inputs to the outputs, but this couldn't apply the metadata [23:38:57 CET] <alexpigment> the filter is assuming that you're going to re-encode, so it can take in that metadata accordingly [23:39:04 CET] <furq> since it demuxes all the files into one continuous stream, it'd have to be possible for the metadata to change mid-stream [23:39:12 CET] <furq> and i don't think that's a thing [23:39:34 CET] <furq> i'm not a dev though, i'm just speculating [23:39:44 CET] <Darxus> Ah, weird, thanks. [23:40:22 CET] <alexpigment> i mean the only other option is to detect that you're re-encoding and then apply metadata. but then it would work two different ways, which always confuses users ;) [00:00:00 CET] --- Fri Mar 24 2017

1 0

ffmpeg-devel.log.20170322
by burek 23 Mar '17

23 Mar '17

[00:23:39 CET] <cone-847> ffmpeg 03James Almer 07release/2.8:a1ad585c8ef1: avformat/apng: fix setting frame delay when max_fps is set to no limit [00:23:40 CET] <cone-847> ffmpeg 03James Almer 07release/3.0:48706b9fef0c: avformat/apng: fix setting frame delay when max_fps is set to no limit [00:23:41 CET] <cone-847> ffmpeg 03James Almer 07release/3.1:b014fa21d4a3: avformat/apng: fix setting frame delay when max_fps is set to no limit [00:23:42 CET] <cone-847> ffmpeg 03James Almer 07release/3.2:33978a49c025: avformat/apng: fix setting frame delay when max_fps is set to no limit [00:44:12 CET] <cone-847> ffmpeg 03Marton Balint 07master:51546504133c: avcodec/avcodec.h: clarify decoupled decode/encode API docs [02:02:03 CET] <cone-847> ffmpeg 03Jun Zhao 07master:9365dfcbf665: hwcontext: fix comments for av_hwdevice_ctx_alloc() [02:27:33 CET] <cone-847> ffmpeg 03Matthias Hunstock 07master:607bffbed287: avdevice/decklink: add format_code of display mode to list_format output [02:27:34 CET] <cone-847> ffmpeg 03Matthias Hunstock 07master:b3a2adaac652: avdevice/decklink: new option 'format_code' to set video format by fourCC [04:20:40 CET] <cone-847> ffmpeg 03James Almer 07master:aee046a895db: x86/audiodsp: remove an unnecessary movss [06:26:47 CET] <IRC-Source_62632> I have a question, can ffserver stream audio in PCM raw format? [07:49:14 CET] <wm4> jkqxz: ported the vdpau patch to ffmpeg and sent to ML [07:49:36 CET] <wm4> the conflict was trivial, but there were other problems (legacy bullshit that wasn't in Libav caused crashes) [07:50:10 CET] <wm4> I tested the normal vdpau API and the hw_frames_ctx, but not the old vdpau API, the very old vdpau API, or the hw_device_ctx API [08:53:16 CET] <kierank> damn, should have got a gsoc student to write memory leak testsa [08:56:53 CET] <kierank> not sure if it's a gsoc worth of work though [10:35:11 CET] <Hawoo_> Hi:) I am a student from GSoC program. I would like to participate in VMAF video filter program but the specified qualification task was already completed, I wonder is there any alternative task I can choose? Thanks a lot! [10:40:13 CET] <nevcairiel> Best would be to contact one of the listed mentors directly [11:07:04 CET] <cone-829> ffmpeg 03Steven Liu 07master:8ddadf56f621: avformat/rtmpproto: change rtmp_open from url_open to url_open2 [11:25:39 CET] <ubitux> fate is broken :( [11:25:55 CET] <ubitux> (apng stuff) [11:30:33 CET] <cone-829> ffmpeg 03Justin Ruggles 07master:43717469f9da: ac3dsp: Reverse matrix in/out order in downmix() [11:30:34 CET] <cone-829> ffmpeg 03Clément BSsch 07master:e39d4ff150f4: Merge commit '43717469f9daa402f6acb48997255827a56034e9' [11:31:53 CET] <wm4> what broke it? [11:40:46 CET] <cone-829> ffmpeg 03Justin Ruggles 07master:a9ba59591ed5: ac3dsp: Add some special-case handling for the C downmix function [11:40:47 CET] <cone-829> ffmpeg 03Clément BSsch 07master:fd5e1d132b46: Merge commit 'a9ba59591ed509fb7e6decfde8da4cbfd4ddf4b8' [11:43:19 CET] <cone-829> ffmpeg 03Clément BSsch 07master:ce10e4cb1f21: doc/libav-merge: create a special "extra changes" section [11:47:39 CET] <jkqxz> wm4: VDPAU is surely fine, but it's probably worth checking on Mesa before you push. I'll do that later today. (I assume you're using Nvidia blob.) [11:48:38 CET] <cone-829> ffmpeg 03Clément BSsch 07master:9dc57688c8e2: lavc/mips: temporally disable ac3 downmix [11:50:34 CET] <wm4> jkqxz: yes, nvidia blob here [11:50:49 CET] <wm4> jkqxz: well, feel free to push my patches once you've confirmed it on mesa [12:48:11 CET] <BBB> does anyone have more ideas for vmaf qualification tasks? [12:48:19 CET] <wm4> so, x264 has commercial licensing, right? then I don't understand why the ffmpeg x264 support requires GPL? unless the wrapper itself is explicitly GPL licensed [12:48:21 CET] <BBB> or alternatively, is any gsoc mentor looking for more students? [12:52:15 CET] <RiCON> wm4: and you can build a lgpl x264 too [12:53:12 CET] <wm4> wut [12:53:19 CET] <ubitux> huh? :o [12:53:30 CET] <ubitux> for real? [12:55:09 CET] <cone-829> ffmpeg 03Justin Ruggles 07master:b57e38f52cc3: ac3dsp: x86: Replace inline asm for in-decoder downmixing with standalone asm [12:55:10 CET] <cone-829> ffmpeg 03Clément BSsch 07master:c66bd8f3ff28: Merge commit 'b57e38f52cc3f31a27105c28887d57cd6812c3eb' [12:55:19 CET] <RiCON> --disable-gpl disable GPL-only features [12:55:25 CET] <RiCON> or does this do nothing? [12:55:53 CET] <ubitux> so we could have a ffmpeg+libx264 build in LGPL? [12:56:49 CET] <BBB> I dont think so [12:57:04 CET] <wbs> RiCON: isn't that more that you can avoid including any gpl-only feature in a commercially licensed build [12:57:06 CET] <BBB> configure urrently dies if gpl is disabled but x264 is enabled [12:57:30 CET] <BBB> and also what wbs said [12:57:32 CET] <wbs> RiCON: like, not trying to include gpl dependencies if you've got a commercial license [12:57:45 CET] <BBB> there is no lgpl x264 [12:57:49 CET] <BBB> there is only commercial or gpl [12:57:57 CET] <wm4> anyway, this was just from a nitpicky, theoretical point of view, since I suspect most --enable-gpl GPL violations by companies were done for the x264 wrapper [12:57:57 CET] <BBB> disable-gpl is for commercial builds [12:58:01 CET] <ubitux> ok ok [12:58:09 CET] <wm4> and these companies could just license x264 commercially [12:58:42 CET] <BtbN> So if a company has a commercial license, the enable-gpl build of ffmpeg, if it's only for x264, is ok? [12:58:52 CET] <wm4> dunno lol [12:59:47 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:2124711b950b: hwcontext_vaapi: add a quirk for the missing MemoryType attribute [12:59:48 CET] <cone-829> ffmpeg 03Clément BSsch 07master:4205010240fe: Merge commit '2124711b950b03c582a119c75f52a87acc32d6ec' [13:07:05 CET] <RiCON> hm, --disable-gpl doesn't actually seem to do anything other than change Copyleft to Copyright and license to "Non-GPL commercial" [13:07:20 CET] <RiCON> there's no gpl-only filters or files [13:07:43 CET] <nevcairiel> for x264? no, its either GPL or commercial license [13:07:49 CET] <nevcairiel> you need to buy the second [13:08:06 CET] <ubitux> pthread_mutex_unlock failed with error: Operation not permitted [13:08:08 CET] <ubitux> zsh: abort (core dumped) [13:08:10 CET] <ubitux> meeeh [13:08:12 CET] <ubitux> :( [13:09:58 CET] <nevcairiel> wm4 wanted to look into that [13:10:37 CET] <nevcairiel> and yeah apng-clock seems broken [13:10:42 CET] <nevcairiel> maybe just needs a ref update [13:11:26 CET] <ubitux> ok, i'll wait for the next merge then [13:19:04 CET] <wm4> uh yeah [13:19:24 CET] <wm4> yesterday it seemed like something strange is going on rather than a simple logic error [13:59:13 CET] <ubitux> wm4: "current thread does not own the mutex"? [14:02:33 CET] <wm4> ooh, that could be [14:02:40 CET] <wm4> maybe it's indeed unlocked by another thread [14:17:51 CET] <jamrial> ubitux: we'll have to disable the mips ac3dec downmix code since it wont compile or work anymore [14:17:54 CET] <jamrial> since we can't fix it [14:18:29 CET] <jamrial> the mips guys will have to adapt it. and maybe also add those 5 to 1/2 channel downmix paths to the fixed decoder [14:18:32 CET] <ubitux> i did in a later commit [14:18:35 CET] <ubitux> and mailed the guy [14:18:46 CET] <jamrial> oh, missed the separate commit [14:18:48 CET] <jamrial> cool then [14:18:51 CET] <ubitux> yeah i realized later [14:19:06 CET] <ubitux> jamrial: btw, you need to fix the apng fate test [14:19:15 CET] <ubitux> :p [14:19:32 CET] <jamrial> ah fuck [14:19:45 CET] <jamrial> thanks for reminding me :p [14:28:37 CET] <cone-829> ffmpeg 03James Almer 07master:0dbfed08d06a: fate: update ref file for apng-clock test [14:37:07 CET] <DHE> I have a patch I'm considering submitting. Looking for more of a "does this patch make sense?" than a review: https://github.com/DeHackEd/FFmpeg/commit/472dddaf97418e00 [14:37:32 CET] <DHE> short version: if an mpeg-ts file appears corrupted due to continuity check errors, it shouldn't be a DEBUG level log event, it should be a WARNING. [14:38:19 CET] <DHE> and I use the word "file" loosely [14:38:20 CET] <atomnuker> adding an option to do that isn't good, just report it as warning by default [14:38:50 CET] <DHE> yeah, I thought about that. question of is it worth changing current behaviour or add an option and maintain existing behaviour [14:39:01 CET] <wbs> DHE: 7e75f061825dd29059ae3110814c8e424aa1e2e2 [14:39:26 CET] <DHE> oh geez... [14:40:27 CET] <wbs> (iirc, in practice, one gets that warning on lots of hls streams, if the mpegts stream in one segment doesn't match the previous segment) [14:41:16 CET] <wbs> and there are hls streams where you lose packets in the gap between segments if you close and reopen the demuxer, so to handle them, you need to actually treat the segments as one continuous stream [14:41:38 CET] <BBB> wm4: sorry I didnt notice you already lgtmed elsewhere [14:42:04 CET] <DHE> that... actually makes sense.. [14:42:40 CET] <wbs> DHE: so perhaps your patch, changing the default to warning, but have the hls demuxer set it back to debug? [14:43:41 CET] <wm4> lgmt'ed what? doesn't matter much anyway [15:01:07 CET] <ubitux> michaelni: opinion on 5bf2454e7cb? we decode that sample fine in FFmpeg (but logging is flooded with errors in our case, even with the patch applied) [15:02:15 CET] <ubitux> basically, applying the patch has no effect because we simply don't error out and enter this code [15:03:42 CET] <ubitux> (our ff_h2645_packet_split() doesn't fail) [15:14:58 CET] <wm4> ubitux: yeah, you're right, it unlocks the mutex on a different thread [15:15:34 CET] <wm4> curiously it doesn't normally happen [15:15:37 CET] <wm4> only with ffplay [15:15:54 CET] <nevcairiel> ubitux: we support such samples already, just differently [15:15:59 CET] <nevcairiel> (re 5bf2454e7cb) [15:16:45 CET] <nevcairiel> wm4: it seems rather fragile in general if some order of api calls can abort the process :d [15:17:01 CET] <wm4> nevcairiel: it's just UB [15:17:10 CET] <ubitux> nevcairiel: yes we do, but with lots of errors in the logging, so maybe the patch from Libav is better [15:17:26 CET] <ubitux> but maybe the errors are unrelated [15:17:30 CET] <wm4> possibly it's because ffplay calls APIs from different threads or so (which it is allowed to) [15:17:58 CET] <wm4> I really don't like what the code does with async_mutex anyway [15:18:14 CET] <nevcairiel> ubitux: the libav approach would also still log an error for every packet before it re-tries parsing as annexb [15:18:42 CET] <ubitux> but we have like 5-6 for every frame [15:19:00 CET] <ubitux> see the sample from https://github.com/HandBrake/HandBrake/issues/339 [15:24:44 CET] <nevcairiel> hm those are not parsing errors [15:24:53 CET] <nevcairiel> but actual decoding errors [15:25:03 CET] <nevcairiel> so unless it mis-reads some things due ot parsing problems [15:25:20 CET] <nevcairiel> do we decode the same stuff from it as libav after the patch? [15:25:54 CET] <nevcairiel> generally we log quite a bunch more error conditions then libav does [15:28:39 CET] <ubitux> but the errors i see are present in libav codebase [15:42:53 CET] <nevcairiel> ubitux: the frame hashes are identical, so not sure its worth worrying about [15:44:12 CET] <ubitux> ok well, i'll skip it then [15:44:28 CET] <ubitux> any idea what commit may have fix that issue? (for hash ref in merge description) [15:45:47 CET] <nevcairiel> 93b89868e139e9b45dfc8a62b4f8e1832bbfd5d8 i would guess [15:45:56 CET] <nevcairiel> it handles the same case in mp4, but should apply to avi equally [15:48:47 CET] <ubitux> indeed, i confirm commenting out that chunk makes it fail [15:48:52 CET] <ubitux> thanks [15:50:15 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:5bf2454e7cb0: h264dec: support broken files with mp4 extradata/annex b data [15:50:16 CET] <cone-829> ffmpeg 03Clément BSsch 07master:17f2c0abea87: Merge commit '5bf2454e7cb03609b3ec1a3cf4c22427fe5f8e36' [15:50:49 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:d10102d23c94: avconv: set the encoding framerate when the output is CFR [15:50:50 CET] <cone-829> ffmpeg 03Clément BSsch 07master:97c17cafab4e: Merge commit 'd10102d23c9467d4eb84f58e0cd12be284b982f6' [15:54:13 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:f6772e9bf825: avconv: make sure the filtergraph is freed on init failure [15:54:14 CET] <cone-829> ffmpeg 03Clément BSsch 07master:204b4a7ee2e9: Merge commit 'f6772e9bf8251d3943f52f6f34d97d2ce6c4b8af' [16:05:52 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:27085d1b47c3: avconv: only retry decoding on actual decoding errors [16:05:53 CET] <cone-829> ffmpeg 03Clément BSsch 07master:928db5134478: Merge commit '27085d1b47c3741cc0fac284c916127c4066d049' [16:09:47 CET] <michaelni> ubitux, $One\ Piece\ AMV$\ Centuries.avi decodes with far fewer errors in ffmpeg-3.0 than later [16:10:02 CET] <michaelni> i mean log errors [16:10:14 CET] <ubitux> ok, so probably unrelated [16:15:56 CET] <cone-829> ffmpeg 03Clément BSsch 07master:c7904af05723: lavc/huffyuvdsp: remove unused ppc init prototype [16:23:09 CET] <cone-829> ffmpeg 03Clément BSsch 07master:af607b7e0787: lavc/huffyuvdsp: only transmit the pix_fmt instead of the whole avctx [16:26:36 CET] <ubitux> oh actually we split these optims out [16:32:42 CET] <cone-829> ffmpeg 03Alexandra Hájková 07master:22c3ab186469: checkasm: Add test for huffyuvdsp add_bytes [16:32:43 CET] <cone-829> ffmpeg 03Clément BSsch 07master:7c2a7f9c11ab: Merge commit '22c3ab18646924ce24dc6017a9e882ff69689e40' [16:34:02 CET] <stevenliu> Hello [16:34:04 CET] <stevenliu> Rodger Combs here [16:34:13 CET] <RiCON> he's rcombs [16:34:20 CET] <rcombs> ohai [16:34:32 CET] <stevenliu> Hi, This is Steven Liu [16:34:51 CET] <stevenliu> I want talk and learn about the av_asprintf :) [16:35:21 CET] <stevenliu> I saw libavformat/segment.c use it to build file name too [16:35:59 CET] <stevenliu> Is that mean it need to modify for looks like replace operation? [16:36:09 CET] <rcombs> you mean hls.c? [16:36:42 CET] <rcombs> or, actually, that doesn't use it either [16:36:44 CET] <cone-829> ffmpeg 03Luca Barbato 07master:1d25a8690294: huffyuvdsp: Reenable PPC optimizations [16:36:46 CET] <cone-829> ffmpeg 03Clément BSsch 07master:7a11e6b2fde8: Merge commit '1d25a86902946dbc80bb3a38e61755181ca3af7b' [16:36:47 CET] <rcombs> which file and line are you referring to [16:37:30 CET] <stevenliu> 279 snprintf(seg->temp_list_filename, sizeof(seg->temp_list_filename), seg->use_rename ? "%s.tmp" : "%s", seg->list); [16:37:39 CET] <stevenliu> libavformat/segment.c [16:38:00 CET] <rcombs> oh, snprintf [16:38:02 CET] <cone-829> ffmpeg 03Luca Barbato 07master:b015872c0d08: huffyuvdsp: Enable the altivec code for PPC little-endian as well [16:38:04 CET] <cone-829> ffmpeg 03Clément BSsch 07master:34389e847213: Merge commit 'b015872c0d0823e70776e98b865509ec1287e2f6' [16:38:09 CET] <stevenliu> Is that wrong? [16:38:13 CET] <rcombs> stevenliu: OK, notice that the format string argument there is a string constant [16:38:22 CET] <rcombs> "%s.tmp" or "%s" depending on seg->use_rename [16:38:26 CET] <rcombs> that's fine [16:38:46 CET] <rcombs> the problem with your code is that the format string argument comes from the XML file [16:39:05 CET] <rcombs> you should never use dynamic data like that as the format-string argument to a function in the printf family [16:39:11 CET] <rcombs> it's a security vulnerability [16:39:46 CET] <rcombs> it can result in memory corruption, leading potentially to crashes or code execution, if the format string is maliciously crafted [16:39:49 CET] <ubitux> simple example of why: put "%s%s%s%s%s%s%s%s%s%s%s%s%s" in your xml [16:39:54 CET] <rcombs> ^ [16:40:03 CET] <stevenliu> 222 snprintf(seg->cur_entry.filename, size, "%s%s", [16:40:16 CET] <rcombs> %s will probably crash; %p can cause code execution [16:40:24 CET] <rcombs> stevenliu: that's writing _into_ seg->cur_entry.filename [16:40:27 CET] <stevenliu> No, not come from XML file [16:40:30 CET] <rcombs> the first arg to snprintf is the output [16:40:37 CET] <stevenliu> it is compte from XML Duration [16:40:48 CET] <rcombs> "%s%s" is the format string there [16:41:44 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:13f5d2bf75b9: configure: check for stdatomic.h [16:41:45 CET] <cone-829> ffmpeg 03Clément BSsch 07master:2d6f7e6c74bd: Merge commit '13f5d2bf75b95a0bfdb9940a5e359a719e242bed' [16:41:55 CET] <rcombs> stevenliu: it's set in rep->url_template = replace_template_str(temp_string, "$Number$");, and temp_string comes from temp_string = get_content_url(baseurl_nodes, 4, rep_id_val, rep_bandwidth_val, media_val); [16:42:25 CET] <rcombs> get_content_url gets its base string from the XML file (xmlNodeGetContent) [16:42:38 CET] <rcombs> and then replaces some template strings [16:42:40 CET] <jamrial> ubitux: just ported the ac3 fixed downmix functions [16:42:52 CET] <stevenliu> 1197 int64_t tmp_val = pls->tmp_url_type == TMP_URL_TYPE_NUMBER ? pls->cur_seq_no : get_fragment_start_time(pls, pls->cur_seq_no); [16:43:07 CET] <jamrial> the ones in ac3dsp. i can't find a sample that uses the one in ac3dec_fixed to test [16:43:23 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:4e928ef340ac: Add a compat stdatomic.h implementation based on GCC atomics [16:43:24 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:c2755864afad: Add a compat stdatomic.h implementation based on windows atomics [16:43:25 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:bb81ed476569: Add a compat stdatomic.h implementation based on suncc atomics [16:43:26 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:f9a6a80e065c: Add a compat stdatomic.h implementation based on pthreads [16:43:27 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:eb34d40354e2: Add a compat dummy stdatomic.h used when threading is disabled [16:43:28 CET] <cone-829> ffmpeg 03Clément BSsch 07master:f015711ed124: Merge commit 'eb34d40354e2474517c9b9bd787e0dadc89c2a81' [16:43:35 CET] <rcombs> stevenliu: that's not the format string [16:43:43 CET] <rcombs> the format string is pls->url_template (the first arg to av_asprintf()) [16:43:46 CET] <stevenliu> yes , it is val [16:43:56 CET] <ubitux> jamrial: did you see the int16 version? [16:44:01 CET] <stevenliu> url_template is replaced [16:44:09 CET] <jamrial> i said above i couldn't find a sample for it :p [16:44:15 CET] <stevenliu> looks like %lld [16:44:30 CET] <ubitux> jamrial: oh, ok sorry :) [16:44:37 CET] <ubitux> (thanks!) [16:45:10 CET] <kkanungo17> hi folks! [16:45:18 CET] <ubitux> i actually did it locally pre-split, but couldn't test so ignored [16:45:34 CET] <ubitux> i guess you just added the int64_t case and "+x>>y" [16:45:35 CET] <rcombs> stevenliu: right, but the base string that gets valued replaced to produce url_template comes from the XML [16:45:46 CET] <jamrial> ubitux: yeah. and any ac3 sample works [16:45:47 CET] <ubitux> and s/cmp_matrix/matrix/ [16:45:51 CET] <jamrial> even the fate test i added [16:46:01 CET] <ubitux> alright, cool [16:46:12 CET] <ubitux> so far LGTM, but i'm not a maintainer of that code [16:46:23 CET] <stevenliu> get from XML and get from user set have different? [16:46:56 CET] <ubitux> no [16:47:20 CET] <rcombs> I don't understand the question [16:47:47 CET] <stevenliu> get from XML, have been replaced insert %lld to replace $$, set the template from user by command line, i think is same thing [16:48:16 CET] <ubitux> in the xml, if you add %s%s%s%s in the string where there is the $$ [16:48:20 CET] <ubitux> you're going to have a bad time [16:48:45 CET] <stevenliu> you mean, ffmpeg will have a bad format to output dash? [16:49:03 CET] <rcombs> I still don't understand what you're trying to say [16:49:13 CET] <rcombs> but if you don't fix this then your patch will not be accepted [16:49:40 CET] <ubitux> stevenliu: ffmpeg will crash at best [16:50:39 CET] <stevenliu> ubitux's anwser is accept, but rcombs' is look like dictatorship :D [16:50:59 CET] <stevenliu> anyway, i fix it [16:51:00 CET] <rcombs> well that's code review for you [16:51:23 CET] <stevenliu> Not for me, just for ffmpeg [16:51:31 CET] <ubitux> stevenliu: rcombs is right, your patch introduces a major security issue so it won't be accepted [16:51:43 CET] <stevenliu> ffmpeg not support it now [16:51:52 CET] <stevenliu> just add dashdec into ffmpeg , that is it [16:52:00 CET] <stevenliu> yes [16:52:23 CET] <durandal_1707> yes we know [16:52:32 CET] <stevenliu> he is right [16:53:10 CET] <stevenliu> let me fix it :) [16:53:57 CET] <stevenliu> Thanks rcombs ubitux and durandal, thanks guys [16:55:00 CET] Last message repeated 1 time(s). [17:00:04 CET] <ubitux> dammit, what's this USE_ATOMICS in our lavu/buffer.c [17:01:47 CET] <ubitux> can we drop that now? [17:03:41 CET] <jamrial> ubitux: 6db8cd8f37b and 890d8f44fdf [17:03:47 CET] <jamrial> so michaelni might know [17:05:35 CET] <ubitux> 27079a426c9d3db918b158976e44b9b143d78e1c is strange [17:05:50 CET] <ubitux> it does move the avbuffer refcount to a "stdatomic" [17:06:17 CET] <ubitux> or wait i missed it does it for the pool one as well [17:06:43 CET] <ubitux> ok i get it, i should be able to update it, but that will probably be a blind one [17:08:51 CET] <ubitux> that USE_ATOMIC code smells really bad [17:09:32 CET] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/buffer.c;h=478e488… [17:09:39 CET] <ubitux> this is full of races or i'm missing something? [17:10:05 CET] <ubitux> doing a pool->refcount <= pool->nb_allocated, and then next line using avpriv_atomic_int_get for the error message [17:10:07 CET] <ubitux> what's going on? [17:11:50 CET] <jamrial> michaelni: ^ [17:12:43 CET] <wm4> ubitux: is that the code that was removed from libav [17:13:01 CET] <wm4> yes it is [17:13:06 CET] <wm4> ask michaelni, he committed this crime [17:13:14 CET] <jamrial> cea3a63ba3d seems like the reason why it was added is no longer valid [17:13:29 CET] <wm4> of course [17:13:34 CET] <jamrial> since this code is used only on non threading builds [17:13:43 CET] <jamrial> because of that USE_ATOMICS check [17:14:01 CET] <ubitux> ok so that part can go away [17:14:10 CET] <ubitux> now what about the whole USE_ATOMIC? [17:15:14 CET] <wm4> kill it [17:17:12 CET] <jamrial> if you kill it (enabling these atomics on builds with threading enabled) wouldn't the reason that code above was added for become valid again? [17:20:09 CET] <ubitux> the code is in the USE_ATOMICS scope [17:20:19 CET] <ubitux> i'm trying to remove completely what's inside these scopes [17:21:07 CET] <rcombs> just require atomics [17:21:16 CET] <ubitux> http://sprunge.us/YZZb [17:22:57 CET] <ubitux> (oh and dropping nb_allocated in buffer_internal.h) [17:24:25 CET] <ubitux> it appears the next commits in libav drops all the libavutil/atomic.h refs [17:24:41 CET] <ubitux> (we'll have a few more) [17:24:55 CET] <ubitux> so should i commit that and go on with the merges? [17:26:06 CET] <michaelni> jamrial, i dont want to be impolite and not reply to being pinged but what should i say ? that it might reintroduce races and then people attack and remove it anyway ... i rather spend my day in peace [17:26:08 CET] <wm4> ubitux: I say yes [17:26:42 CET] <wm4> yeah because it's totally valid that people compile without threads and then expect code to be threadsafe [17:26:44 CET] <wm4> TOTALLYX [17:26:51 CET] <ubitux> michaelni: any objection on removing USE_ATOMICS? [17:26:56 CET] <ubitux> wm4: please :) [17:27:22 CET] <ubitux> i'm asking because it's blocking my merges [17:27:27 CET] <wm4> it's nonsensical to support [17:27:52 CET] <ubitux> maybe, i still want to understand the rationale and if it was/is/will be required [17:28:12 CET] <wm4> no [17:28:24 CET] <wm4> the atomics code was race so it was replaced with mutexes (in Libav) [17:28:53 CET] <michaelni> ubitux, i didnt follow the merges and changes, i dont object to removing it if it doesnt introduce issues, if it does its maybe better to leave it [17:29:21 CET] <ubitux> i can't tell if it introduce issues as it's being used only if... there is no thread implementation [17:29:59 CET] <ubitux> ...but it's using various current atomic code [17:32:22 CET] <michaelni> is there something that prevents user apps which use threads to use a lib* that was built without threads ? are we checking for this, is this documented as a problem in the previous releases ? and what if a user app is build arond a different thread implementation than the one used in the libs mutexes ? [17:33:35 CET] <michaelni> anyway these are just comments i object to no choice for this [17:37:52 CET] <ubitux> i think wm4 is right with saying that if you're building ffmpeg without any threads you can't except any lock mechanism [17:38:10 CET] <ubitux> i'll check that if it still work if i disable threading [17:38:33 CET] <ubitux> if it does i'll drop it and go on with the merges [17:44:10 CET] <ubitux> seems to pass, RIP [17:44:38 CET] <cone-829> ffmpeg 03Clément BSsch 07master:67d8eabdbb29: lavu/buffer: drop USE_ATOMICS [17:49:14 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:27079a426c9d: buffer: convert to stdatomic [17:49:15 CET] <cone-829> ffmpeg 03Clément BSsch 07master:443e9692935f: Merge commit '27079a426c9d3db918b158976e44b9b143d78e1c' [17:49:29 CET] <ubitux> wm4: i'll merge the v4l2 commit soon, but can you have a look to the mmal one and the 3 next? [17:49:38 CET] <ubitux> i think they're related to your pthread crash [17:49:53 CET] <ubitux> (which affects teh progress, but the commits switch this stuff to stdatomic) [17:55:53 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:3a165c187da7: v4l2: convert to stdatomic [17:55:54 CET] <cone-829> ffmpeg 03Clément BSsch 07master:b7336faa39b8: Merge commit '3a165c187da7d74f46f6c1778294e8c5a3a7151f' [17:56:46 CET] <ubitux> mmal doesn't differ much so it should be trivial to merge [17:56:56 CET] <ubitux> for the others, it might be a bit more tricky [17:57:30 CET] <ubitux> (it applies cleanly) [17:58:50 CET] <ubitux> (ETA: we're close to 800 commits left) [18:01:23 CET] <wm4> are there any conflicts in the mmal one? [18:01:27 CET] <ubitux> nope [18:01:31 CET] <ubitux> it applies cleanly [18:01:33 CET] <wm4> then it should be fine [18:02:12 CET] <wm4> which pthread crash? [18:02:21 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:8385ba53f115: mmaldec: convert to stdatomic [18:02:22 CET] <cone-829> ffmpeg 03Clément BSsch 07master:82d6179a88bb: Merge commit '8385ba53f115401a67a4748c0d107769ebfb2941' [18:02:31 CET] <ubitux> wm4: the one we talked about earlier [18:02:41 CET] <ubitux> the mutex lock from another thread [18:02:46 CET] <wm4> the ffplay one triggers only if you enable some debug stuff (if not it'll hang or work, maybe latter) [18:04:16 CET] <ubitux> ok well, i'll look at these commits as well [18:06:08 CET] <wm4> I think I tried to port all commits on pthread_frame [18:06:43 CET] <wm4> and the next commit was redundant or so [18:08:09 CET] <wm4> anyway whether or not the commit was already merged or whatever happened, it's ok not needed in current ffmpeg master [18:10:26 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:db2733256db3: pthread_frame: use a thread-safe way for signalling threads to die [18:10:27 CET] <cone-829> ffmpeg 03Clément BSsch 07master:e6c868befa6a: Merge commit 'db2733256db323e4b88a34b135320f33274148e2' [18:12:02 CET] <ubitux> ah indeed all of this is already merged [18:12:35 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:64a31b2854c5: pthread_frame: use atomics for PerThreadContext.state [18:12:36 CET] <cone-829> ffmpeg 03Clément BSsch 07master:5aee64991999: Merge commit '64a31b2854c589e4f27cd68ebe3bcceb915704e5' [18:14:13 CET] <cone-829> ffmpeg 03Anton Khirnov 07master:59c70227405c: pthread_frame: use atomics for frame progress [18:14:14 CET] <cone-829> ffmpeg 03Clément BSsch 07master:9ce031c37f13: Merge commit '59c70227405c214b29971e6272f3a3ff6fcce3d0' [18:15:03 CET] <ubitux> we have a lot of stuff to update in our codebase to be able to drop atomic.h [18:15:54 CET] <ubitux> anyone will to help, especially for videotoolboxenc, decklink and mediacodec which i can't test? [18:15:59 CET] <ubitux> willing* [18:17:05 CET] <cone-829> ffmpeg 03Clément BSsch 07master:cb763a9ba849: lavc/bitstream: remove unused atomic.h include [18:17:50 CET] <cone-829> ffmpeg 03Clément BSsch 07master:cf1c8a379e9f: lavc/bitstream_filter: remove unused atomic.h include [18:19:40 CET] <jamrial> ubitux: the stdatomics are pretty much drop in replacements for the atomic.h stuff, so they can probably be replaced blindly [18:19:47 CET] <jamrial> if it doesn't work, mac people will complain anyway :p [18:19:54 CET] <wm4> why mac people [18:20:02 CET] <ubitux> because videotoolbox :p [18:20:14 CET] <ubitux> but there is also windows & android :) [18:20:21 CET] <ubitux> but sure i can blind it [18:20:40 CET] <ubitux> i'd still prefer is someone who can test does it :p [18:20:54 CET] <jamrial> only issue is add and fetch, which is not available on stdatomic [18:20:58 CET] <jamrial> there's only fetch and add [18:21:11 CET] <jamrial> but a previous merge already dealt with that [18:21:42 CET] <atomnuker> ubitux: can I push something? [18:22:00 CET] <ubitux> atomnuker: yes [18:22:22 CET] <cone-829> ffmpeg 03Rostislav Pehlivanov 07master:38d7cc22f778: mdct15: fix left shift of a negative value [18:22:34 CET] <atomnuker> ubitux: ktnx, that was it [18:22:55 CET] <ubitux> jamrial: http://sprunge.us/GZAI does this looks good to you? [18:24:03 CET] <ubitux> actually i need to update the type in the struct too [18:24:05 CET] <jamrial> why init instead of store? [18:24:14 CET] <nevcairiel> i was wondering about the type [18:24:16 CET] <nevcairiel> :d [18:25:18 CET] <jamrial> the compat headers don't seem to use any kind of relevant atomic function for init() but do for store() [18:25:50 CET] <nevcairiel> init should be used in actual init code that never runs in parallel, store otherwise [18:26:20 CET] <ubitux> ah indeed i missed the store [18:28:15 CET] <wm4> the current code assumes 0 initializing atomics is ok anyway [18:28:26 CET] <wm4> although in theory that's probably not the case [18:28:44 CET] <jamrial> ubitux: is videotoolboxenc.c even using anything from lavu/atomic.h? [18:29:04 CET] <ubitux> it appears not [18:29:06 CET] <ubitux> :p [18:29:17 CET] <jamrial> one down then :p [18:29:42 CET] <ubitux> http://sprunge.us/cBhR [18:29:48 CET] <ubitux> does this look better? [18:31:22 CET] <ubitux> i'm not sure if i can miss the atomic_init [18:32:58 CET] <jamrial> it worked without it before [18:33:37 CET] <ubitux> because of the memset 0 of the context [18:33:57 CET] <ubitux> but officially i'm supposed to init these [18:35:28 CET] <jamrial> then leave it [18:36:29 CET] <ubitux> what's the replacement for avpriv_atomic_ptr_cas? [18:37:24 CET] <jamrial> atomic_compare_exchange it seems [18:38:34 CET] <cone-829> ffmpeg 03Clément BSsch 07master:e28bd75f7cfd: lavc/hevc: use atomics for wpp_err [18:39:19 CET] <ubitux> help welcome for fixing the remaining git grep 'include.*[^d_]atomic.h' [18:39:26 CET] <ubitux> i'm going away for a while [18:39:38 CET] <ubitux> as soon as they are dropped i can move on with the merges [18:39:59 CET] <ubitux> (ETA: 799 commits) [18:48:00 CET] <BtbN> philipl, how do you even test encoding with nvenc with b frames? [18:48:38 CET] <BtbN> Setting -bf to anything other than 0 makes EncodePicure fail for me [18:50:57 CET] <BtbN> Or is that the failure you mean? As it works just fine without hwaccel cuvid [18:53:02 CET] <BBB> wm4: I dont think libav removed atomics? [18:53:39 CET] <wm4> BBB: ? [18:53:59 CET] <nevcairiel> they replaced our custom atomics with C11 atomics [18:54:04 CET] <BBB> <wm4> the atomics code was race so it was replaced with mutexes (in Libav) (at 1 1/2 hr ago) [18:54:06 CET] <BBB> right [18:54:18 CET] <BBB> nevcairiel: indeed [18:54:21 CET] <nevcairiel> not all of the atomics [18:54:25 CET] <nevcairiel> but some use of it [18:54:30 CET] <nevcairiel> was what wm4 referred to [18:54:33 CET] <BBB> I believe they removed the custom atomics and now use stdc atomics [18:54:34 CET] <BBB> ok [18:55:12 CET] <BBB> if this is about pthreads, that work of wah-teng was done on ffmpeg and I asked him to do it in libav instead (after I approved his patch here) so that we wouldnt have widely diverging implementations of the same thing [18:55:17 CET] <wm4> s/race/racy [18:55:18 CET] <BBB> (pthread_frame, I mean) [18:55:35 CET] <wm4> that's what ubitux is merging right now [18:55:47 CET] <wm4> we have additional old-atomics use so these must be fixed first [18:55:59 CET] <BBB> right [19:07:27 CET] <philipl> BtbN: Yes. But it worked before the filter merge [19:07:36 CET] <philipl> That was my point [19:35:27 CET] <jamrial> ubitux, nevcairiel: http://pastebin.com/raw/PE0ZxPUe mediacodec [22:17:35 CET] <cone-829> ffmpeg 03Diego Biurrun 07master:6ff3da4f6a8e: Place attribute_deprecated in the right position for struct declarations [22:17:36 CET] <cone-829> ffmpeg 03Mark Thompson 07master:81b7deab8296: vaapi: Implement device-only setup [22:17:37 CET] <cone-829> ffmpeg 03Mark Thompson 07master:14c110151838: vaapi_hevc: Mark as async-safe [22:17:38 CET] <cone-829> ffmpeg 03Mark Thompson 07master:9560766a6164: vaapi_vp9: Mark as async-safe [22:42:20 CET] <cone-829> ffmpeg 03James Almer 07master:30cadfe071ad: avcodec/lossless_videodsp: use ptrdiff_t for length parameters [23:45:14 CET] <kierank> atomnuker: would you be willing to mentor aac-960 encoding by any chacne? Mathias continues to troll me [23:45:48 CET] <nevcairiel> someone should get decoding of that going first =p [00:00:00 CET] --- Thu Mar 23 2017

1 0

ffmpeg.log.20170322
by burek 23 Mar '17

23 Mar '17

[00:07:38 CET] <ritsuka> you shouldn't ignore the edit lists btw [00:56:46 CET] <alexpigment> ritsuka: yeah i was wondering that myself. i'd guess that the old version ignored the edit lists and the new version respected them. in which case, it's probably best to use a newer copy of FFMPEG and *not* ignore them [00:58:48 CET] <alexpigment> unless, of course, there's an A/V sync issue caused by the edit lists (this used to happen back in the day, I recall) [01:10:44 CET] <ZeroWalker> okay was able to steram tcp, but it seems to be quite bad for low latency compared to how rtp handles it (the video part at least). in rtp it seems to just play the frame as fast as possible, which is what i want (as it's VFR, which doesn't seem to work with a tcp stream, it will buffer and play it at specified timebase). [01:12:06 CET] <ZeroWalker> so, i would probably want to try rtp with tcp (or something, find it really complicated about all these protocols;P). And then maybe stream the audio separately [04:05:54 CET] <obamoose> hello [06:07:45 CET] <IRC-Source_62632> Hey, anyone online? [06:26:07 CET] <IRC-Source_62632> I have a question, can ffserver stream audio in PCM raw format? [09:04:38 CET] <BridgeUK> Hi, please can someone tell me what a malformed aac bitstream is and how to fix it, thank you very much [09:15:19 CET] <Threads> -bsf:a aac_adtstoasc [09:15:27 CET] <Threads> should help [09:22:10 CET] <BridgeUK> thanks for the reply Threads, when I do "ffmpeg.exe file.mp4 -bsf:a aac_adtstoasc" I get two error messages, "Trailing options were found on the commandline." and "Output file #0 does not contain any stream" please can you tell me what I need to do next [09:24:54 CET] <BridgeUK> http://pastebin.com/vADjycMa is the full printout [09:26:28 CET] <BridgeUK> sorry i'm just being a bit overcautious, i don't want to so something wrong which may break the file :) [09:36:21 CET] <Threads> are you copying or extracting ? [09:36:26 CET] <Threads> what do you need fully [09:44:24 CET] <BridgeUK> Threads, what it is is i downloaded a couple videos with youtube-dl and noticed youtube-dl said "malformed aac bitstream" and i wasn't sure what that meant apart from it was an ffmpeg message [09:45:21 CET] <BridgeUK> the audio is fine on the files, it's just i wasn't sure what the malformed aac bitstream meant [10:25:07 CET] <Hawoo_> Hi:) I am a student from GSoC program. I would like to participate in VMAF video filter program but the specified qualification task was already completed, I wonder is there any alternative task I can choose? Thanks a lot! [10:25:45 CET] <durandal_170> Hawoo_: wrong channel [10:26:10 CET] <durandal_170> Hawoo_: #ffmpeg-devel [10:27:22 CET] <Hawoo_> So sorry [10:51:38 CET] <BOFH_org> Hi all [10:54:58 CET] <BOFH_org> I try to recode a m2p file to a h264 avi. the stream is greyscale and although there is an audiotrack in the m2p, it's just static. So I'd like to drop the audio track when recoding. I use the following commandline: ffmpeg -i input.m2p -q:v 0 -pix_fmt grey -vcodec h264 -an output.avi. But now I get repeating warning like this: Past duration 0.999992 too large. This warning doesn't appear when I exclude '-an' from the commandline. What's going on here? Can [10:54:59 CET] <BOFH_org> I just ignore these warnings? [10:56:27 CET] <nyuszika7h> Those warnings can be usually ignored [10:56:52 CET] <nyuszika7h> Also why would you put H.264 video in AVI? [10:56:57 CET] <nyuszika7h> You can, it's just illogical [10:57:18 CET] <nyuszika7h> AVI generally stores XviD, for H.264 use MP4/MKV [10:57:21 CET] <vlt> BOFH_org: Do those warning appear when you use a decent container format? [10:57:42 CET] <nyuszika7h> I get such warnings with MKV sometimes [10:57:50 CET] <nyuszika7h> But the output file is fine [10:57:51 CET] <BOFH_org> let me try. [10:58:42 CET] <BOFH_org> exactly the same error, regardless the container I use. the warnings disappear when removing the '-an' flag though [11:28:30 CET] <panpeter> Hi all, is "gst_debug_bin_to_dot_data" in all gstreamer1.0 versions available? [11:59:51 CET] <BOFH_org> ahh. it seems the "past duration too large" errors disappear when using .mp4 [12:00:45 CET] <BOFH_org> nyuszika7h: indeed, it seems the warnings can be ignored. video output seems fine. thanks [12:11:11 CET] <ZeroWalker> is it possible to output CFR with VFR input (in code). I set the framerate at the encoder, and input is VFR and just timestamp based live. but the output is the same as the input. Which is fine usually, but it seems to be a bit problematic when trying to stream as it wants CFR, unless i am missing something [12:11:16 CET] <panpeter> Ok it seems not to be the case, in 1.8.3 "gst_debug_bin_to_dot_data" is available in 1.2.4 only "gst_debug_bin_to_dot_file" and "gst_debug_bin_to_dot_file_with_ts" is available [12:16:56 CET] <panpeter> Is there a way to set "GST_DEBUG_DUMP_DOT_DIR" directly for gstreamer instead of using an environment variable? [12:54:54 CET] <ZexaronS> So MPEG4 isn't really a successor to MPEG2 - what about a real MPEG2 successor [12:55:30 CET] <ZexaronS> Online streaming is definitely another class than MPEG2 was in [12:57:01 CET] <ZexaronS> A compression that compresses more but also loses more information is not considered "better", weird monikers, it's really more specific, better in filesize but not better overall [13:03:11 CET] <flux> zexarons, so you're looking for better quality? in the end it all comes down to required bitrate and achieved quality at that bitrate. for that function I believe H264 and H265 handily beat/succeed MPEG2. [13:04:03 CET] <ZexaronS> the hardcore guys around MPC-HC always say MPEG2 is better looking [13:04:16 CET] <ZexaronS> but at high bitrates imo only [13:04:19 CET] <kerio> the hardcore guys are stupid [13:04:21 CET] <ritsuka> -.- [13:04:32 CET] <kerio> like that's not true in any way shape or form [13:04:44 CET] <ZexaronS> this is something MP4 and HEVC can't do [13:04:50 CET] <ZexaronS> that's what I heard [13:05:07 CET] <kerio> h264 can be literally lossless [13:05:25 CET] <kerio> so i have absolutely no idea what those guys are smoking [13:06:13 CET] <ZexaronS> But I have noticed the same thing with AVC it's always so blocky compared to silk smoothness of MPEG2 [13:06:23 CET] <ZexaronS> but im not an expert maybe it wasn't a good comparison [13:06:24 CET] <kerio> at the same bitrate? [13:06:32 CET] <ZexaronS> sorry i don't remember [13:06:44 CET] <kerio> then what is the point [13:07:11 CET] <nido> does doom9 still do its comparisons? [13:07:24 CET] <flux> could even be interlaced/progressive mixing up [13:07:39 CET] <flux> interlaced sure was popular with mpeg2. [13:07:46 CET] <ZexaronS> The point is, when they designed HEVC and AVC they focused more on getting the size down than expanding quality features and designing it in quality in mind, the compression probably isn't meant to preserve quality [13:07:58 CET] <nido> hrm... doom9 doenst work anymore [13:08:10 CET] <kerio> http://streaminglearningcenter.com/images/2mbps_horse.jpg [13:08:18 CET] <kerio> ZexaronS: no they didn't [13:08:22 CET] <kerio> and yes it is [13:08:28 CET] <kerio> that is literally the whole point of lossy compression [13:11:19 CET] <ZexaronS> well i must have heard something a long while ago like 2 years [13:11:27 CET] <ZexaronS> but there was also discussion of color [13:11:48 CET] <ZexaronS> I had some old dvd archival remastering to do a year back [13:12:15 CET] <ZexaronS> I poked into all things transcoding for the first time for serious, but i had some early beginner experience [13:12:23 CET] <ZexaronS> but im still not that of an expert [13:13:29 CET] <ZexaronS> when HDR and WCG arrive, would these codecs be fine? they weren't designed around keeping good color info ? [13:15:10 CET] <ritsuka> yes, there are already using h.264/h.265 for hdr [13:15:54 CET] <ZexaronS> I'm trying to find that picture [13:40:17 CET] <ZexaronS> oh ops [13:40:30 CET] <ZexaronS> that was just how MadVR renders compared to EVR in MPCHC [13:40:52 CET] <ZexaronS> MadVR looks more brown while EVR more reddish, but these could just be my settings at the time who the heck knows [14:23:43 CET] <jonascj> Is it possible to specify a specific lame library version in ffmpeg, or will ffmpeg always use what is installed in predefined dirs e.g. /usr/lib ? [14:24:25 CET] <jonascj> by specifying I mean if you could point it to /tmp/libmp3lame.so.0 [14:36:59 CET] <kepstin> jonascj: on linux? you can use standard linker mechanisms e.g. LD_LIBEARY_PATH or LD_PRELOAD to affect which library is used. [14:39:02 CET] <jonascj> kepstin: on linux yes, I've never played much with LD_LIBRARY and lD_PRELOAD, maybe now is the time. I'll look into it. Otherwise I would jsut relink the /usr/bin/ file to the version I wanted stored elsewhere. [14:39:50 CET] <kepstin> jonascj: simplest way to do it is something like `LD_PRELOAD=/tmp/libmp3lame.so.0 ffmpeg ...` [14:40:53 CET] <jonascj> thanks, I'll try that. [14:42:41 CET] <kepstin> why are you switching out the lame encoder anyways? my impression is that lame hasn't really changed in quite a few years... [14:43:24 CET] <jonascj> kepstin: for kicks, but no, last stable release was 2012 I think [14:43:31 CET] <jonascj> Just wanted to try and build it myself etc. [14:53:37 CET] <jonascj> do you know why ffprobe shows "encoder lavc57" instead of something like: "encoder: lame" when I encode audio as "ffmpeg -i file.wav -c:a libmp3lame file.mp3"? [15:11:04 CET] <BtbN> Because libavcodec57 is the encoder. [15:11:52 CET] <jonascj> BtbN: which relies on the lame library? [15:12:04 CET] <BtbN> It relies on whatever you tell it to use [15:12:06 CET] <jonascj> internally [15:12:12 CET] <jonascj> alright, thanks [15:18:13 CET] <alexpigment> BtbN: i saw you had a commit for removing the Nvidia NVENC 'default' preset because there were no quality benefits. do you have any info about what sets it apart from other presets? is it possible it has any advantages on older (or newer) hardware? [15:18:22 CET] <thebombzen> jonascj: because it was encoded with libavcodec, it uses that. it turns out libavcodec just delegates the actual encoding to libmp3lame, but that's abstracted away from libavformat and the tohers [15:18:44 CET] <BtbN> alexpigment, "what sets it"? [15:18:52 CET] <BtbN> I'm not aware of any point for it [15:19:03 CET] <thebombzen> what does the -preset 0 even do with nvenc [15:19:24 CET] <alexpigment> "what sets it apart" = "what makes it unique" [15:19:28 CET] <thebombzen> setting the preset to "default" doesn't actually change anything [15:19:29 CET] <BtbN> if you want high quality, you go hq, if you want high performance, you go hp. low latency, there are ll presets. [15:19:54 CET] <BtbN> The only unique quality of it is that it's confusing and seemingly pointless [15:20:05 CET] <thebombzen> also what's the difference between the various things like "medium" and "hq" [15:20:06 CET] <alexpigment> a very scientific answer there ;) [15:20:16 CET] <thebombzen> medium says "hq 1 pass" [15:20:28 CET] <alexpigment> well, i know in terms of speed, there are ver little *speed* differences between a lot of the presets [15:20:35 CET] <alexpigment> *very [15:20:47 CET] <BtbN> fast/medium/slow are convenience presets made by ffmpeg, that set a few other options to mimic x264 presets [15:20:58 CET] <BtbN> There are huge speed differences betweem them [15:21:11 CET] <alexpigment> yeah, i'm specifically talking about NVENC presets [15:21:15 CET] <BtbN> hp can easily do several 1000 fps, while hq with 2 pass(i.e. slow) barely handles 100 or 200 [15:22:23 CET] <alexpigment> anyway, i wanted to make sure I could just safely ignore "Default". but I was really wondering if there was some attribute about default that isn't useful for one application but may be useful for another [15:22:48 CET] <BtbN> It's not well defined in any way, and I'm actually thinking about deprecating it in ffmpeg as well [15:22:59 CET] <BtbN> Making it an alias for medium [15:23:27 CET] <alexpigment> fair enough. thanks for the extra info [15:29:47 CET] <alexpigment> so is there any documentation on the fast/medium/slow ffmpeg presets for NVENC? i notice, again, that there isn't a huge speed difference on my end between fast and medium - only 5%. and just slightly faster than medium, but warns that "The variable bitrate rate-control requires the 'qmin' and/or 'qmax' option set." [15:30:17 CET] <alexpigment> *and slow is just slightly faster than medium [15:30:22 CET] <alexpigment> sorry, no coffee yet [15:32:00 CET] <DHE> alexpigment: not much beyond what NVENC describes which is little more than "quality improves, framerate decreases". most of the docs I've seen are just framerate estimates to give you an idea how much you lose by choosing slow [15:33:36 CET] <alexpigment> does the warning i mention above imply that slow doesn't have any effect outside of a particular rate control method? [15:33:43 CET] <alexpigment> e.g. 2pass [15:34:33 CET] <alexpigment> in other words, when doing a single pass encoding, why do fast and medium give no warning messages, but slow warns about using qmin and qmax? [15:39:55 CET] <BtbN> alexpigment, if you get that warning, you should update your ffmpeg. It was removed. [15:44:52 CET] <alexpigment> BtbN, ok confirmed. i was using the last zeranoe build i downloaded last month or so. my own build doesn't give the same error [15:45:03 CET] <BtbN> it's not an error [15:45:04 CET] <alexpigment> and now i'm also seeing a more noticeable different in FPS [15:45:06 CET] <BtbN> just a pointless warning [15:45:14 CET] <alexpigment> yeah, i meant warning, sorry [15:45:34 CET] <alexpigment> man, i need to drink coffee. these typos are out of control :) [15:46:25 CET] <alexpigment> but yeah, now i'm seeing Slow at 400fps, Medium at 560fps, and Fast at 600fps [15:46:48 CET] <BtbN> which card is that on? [15:46:55 CET] <alexpigment> 1060 [15:47:28 CET] <BtbN> if you want to truely bench only nvenc, make sure to use something like yuvtestsrc and -f null as output [15:49:47 CET] <alexpigment> well, i don't need to do any synthetic benchmarking - i'm using a 1080p60 source which is generally what i'll be working with [15:50:02 CET] <alexpigment> i just wanted to make sure i was seeing the correct differences between the speed-based presets [15:50:16 CET] <alexpigment> which i now am, thanks to your tip about using a newer ffmpeg build [15:50:43 CET] <BtbN> if you are going for livestreaming, there is absolutely no point in going for any but the highest quality preset [15:52:24 CET] <alexpigment> well, not for livestreaming really, but for draft previews. just something quick and dirty to put on the screen. final encodes will use x264, naturally [15:53:12 CET] <alexpigment> but yes, i can see that the FPS is high enough that realtime is easily possible on the highest quality presets [16:11:01 CET] <thebombzen> BtbN: is that the slow preset? [16:14:15 CET] <panpeter> Is there any internal way to set GST_DEBUG_DUMP_DOT_DIR without using an environment variable? [16:17:21 CET] <thebombzen> why would you need to do that? [16:37:37 CET] <erbal> Hi, I'm trying to cross-compile ffmpeg to target Android but having issues. Anyone have any experience with that? Or compiling ffmpeg in general? [17:11:36 CET] <BtbN> thebombzen, depending on the content it's either llhq+2pass or hq+2pass [18:44:45 CET] <bmduser> can anyone tell me if there is a precompiled binary for windows that supports the blackmagic decklink duo2? [18:46:50 CET] <bmduser> because i have been trying everything and all i get is a black recording [18:47:15 CET] <bmduser> here is the command i am using -f dshow -video_size 1920x1080 -pixel_format uyvy422 -framerate 25 -i video="Decklink Video Capture (2)" -codec:v mpeg4 -pix_fmt yuv420p -preset ultrafast -an -crf 0 output.mp4 [18:47:59 CET] <oerg866> why are you setting the pixel format twice [18:48:10 CET] <bmduser> I am sure that I have a 1080p video source at 25 fps on every single input on the capture card [18:49:20 CET] <bmduser> oerg866: i am quite new to this and have been trying it differently [18:59:33 CET] <bmduser> what i am really trying to do is to stream a backmagic capture card's input to VLC [19:00:51 CET] <bmduser> with this command ffmpeg.exe -f dshow -video_size 1920x1080 -pixel_format uyvy422 -framerate 25 -i video="Blackmagic WDM Capture (2) " -f mpegts udp://127.0.0.1:5000?pkt_size=1316 [19:01:55 CET] <bmduser> and all i am getting is a black screen so i thought its a case of me not getting the right input settings on the blackmagic card. [19:02:17 CET] <bmduser> streaming an mp4 file to vlc works though [19:42:57 CET] <faLUCE> Hello. If I decode a MJPEG packet to AV_PIX_FMT_YUYV422 format, the resulting AVFrame is filled in data[0], data[1] and data[2].... why that? AV_PIX_FMT_YUYV422 is packed, not planar [20:51:53 CET] <matkatmusic> off topic: anyone know what are good bitrate settings for exporting? I've got some raw footage from a camera that says the data rate is 40.72Mbit/sec [20:53:00 CET] <dystopia_> depends on the type of content [20:53:30 CET] <dystopia_> and resolution [20:55:04 CET] <matkatmusic> 1920x1080 both in and rendered [20:55:09 CET] <matkatmusic> piano tutorials [20:55:18 CET] <matkatmusic> so, mostly static footage [20:55:35 CET] <matkatmusic> except for moving hands [20:55:40 CET] <alexpigment> matkatmusic: is there a reason you aren't able to use CRF? [20:55:49 CET] <matkatmusic> what is CRF? [20:55:54 CET] <dystopia_> yeah he can heh [20:55:58 CET] <matkatmusic> I'm doing the editing in Screenflow [20:55:59 CET] <dystopia_> so footage is low motion [20:56:16 CET] <dystopia_> you could use crf 17 or crf 18 [20:56:21 CET] <dystopia_> it will compress well [20:56:31 CET] <alexpigment> does Screenflow not have a CRF mode? [20:56:31 CET] <matkatmusic> I've been using 3000kbit/sec because I didn't see any difference when I used higher settings [20:56:46 CET] <alexpigment> 3000kbps is not bad for very low motion 1080p [20:56:51 CET] <alexpigment> but i wouldn't go too much lower [20:57:35 CET] <alexpigment> especially if it's only 1pass VBR [20:58:54 CET] <alexpigment> i guess your question didnt' get answered up there. CRF = constant rate factor. it basically allows you to choose a desired quality level, then the bitrate is allocated accordingly [20:59:22 CET] <alexpigment> instead of -b:v 3000k, just use -crf 17 or 18 as dystopia suggested [20:59:46 CET] <alexpigment> (i tend to use 18 for things where i still retain a master copy in higher quality) [21:05:47 CET] <furq> if it's osx only then it's probably using the avfoundation h264 encoder [21:05:57 CET] <furq> which i assume sucks, but i've never used it [21:06:48 CET] <alexpigment> 2-pass generally makes sucky things suck slightly less [21:07:12 CET] <alexpigment> i wish Premiere's encoder sucked less :( [21:10:44 CET] <llogan> alexpigment: install UT video. then you can export it from AME. then re-encode with ffmpeg. or maybe use a frameserver w/ avisynth [21:11:21 CET] <alexpigment> llogan: i already effectively do that [21:11:39 CET] <llogan> what method do you use? [21:11:40 CET] <alexpigment> i export to an intermediate format and then re-encode with ffmpeg [21:11:52 CET] <furq> llogan: no avisynth on osx [21:12:07 CET] <alexpigment> furq: i don't think he's talking about OSX [21:12:18 CET] <llogan> didn't realize it was os x [21:12:22 CET] <furq> screenflow is osx only [21:12:25 CET] <furq> so i assume he is [21:12:34 CET] <alexpigment> furq: you have two people confused [21:12:38 CET] <furq> oh nvm [21:13:17 CET] <alexpigment> no worries [21:13:19 CET] <furq> i don't see why you'd use ut video for that though [21:13:23 CET] <furq> ffv1 is builtin [21:13:29 CET] <llogan> when did that happen? [21:13:30 CET] <furq> wait. premiere [21:13:44 CET] <furq> i'm doing well today [21:13:48 CET] <faLUCE> any help about that? I saw the decoding_encoding example: for decoding, AVCodecContext->pix_fmt is not set. Then, how can I know which pixel format is used by the codec context for the output frame? [21:14:12 CET] <alexpigment> sorry, i was making an aside about how i disliked Premiere's encoder (Mainconcept, i think), which was really an aside since you mentioned that avfoundation's encoder probably sucks [21:14:28 CET] <llogan> alexpigment: intermediates. the traditional "AME tax". [21:14:30 CET] <furq> no this is pretty much my fault [21:14:32 CET] <alexpigment> i think i'm contributing to furq's confusion here [21:14:43 CET] <furq> anyway yes mainconcept sucks [21:14:49 CET] <furq> let's all get angry at that instead of at me [21:15:02 CET] <alexpigment> ;) [21:15:13 CET] Action: llogan casts magic missle on mainconcept [21:15:41 CET] <alexpigment> i remember back in the day that mainconcept used to be a big player in the MPEG-2/DVD game [21:15:58 CET] <alexpigment> and they just got owned in H.264 [21:16:13 CET] <alexpigment> on the other hand, FFMPEG still can't create a decent looking MPEG-2 DVD imho [21:17:00 CET] <furq> what would you recommend [21:17:06 CET] <furq> on the off chance i ever need to make a dvd again [21:17:08 CET] <llogan> i still use it on occassion because I don't care enough...it's just doovday anyway. [21:17:18 CET] <furq> i think i used hcenc last time i was called upon to do that [21:17:24 CET] <alexpigment> hcenc is highly regarded [21:17:28 CET] <furq> but that was like five years ago and it was already surprising that anyone asked [21:17:39 CET] <alexpigment> i generally just export from Adobe Premiere because I'm already there and it looks pretty decent [21:18:18 CET] <alexpigment> I still author a decent amount of DVDs for analog > digital conversions, so it's not exactly a "dead" format to me ;) [21:18:39 CET] <alexpigment> but yeah, FFMPEG... wow. just horrible MPEG-2 quality with any combination of settings i try [21:18:49 CET] <furq> it was for my flatmate's short film, which he'd already put on vimeo in 1080p [21:18:56 CET] <furq> he just wanted to have something to hand out [21:19:14 CET] <furq> i'm not sure which commissioner he expected to meet who didn't have internet [21:19:29 CET] <matkatmusic> ok, so lemme see what kinds of codecs are available to export with... [21:19:43 CET] <llogan> furq: maybe for the old people [21:20:50 CET] <matkatmusic> ok, there is Lossless - ProRes with Alpha where I can customize the frame rate [21:21:04 CET] <matkatmusic> and then there is Web HD (h264) where i can specify a bunch of paramters [21:21:07 CET] <matkatmusic> parameters [21:21:16 CET] <matkatmusic> everything else is like for ipod/iphone or whatnot [21:21:30 CET] <furq> there's a lossless prores? [21:21:41 CET] <matkatmusic> Also, there is plain old apple Lossless [21:22:27 CET] <furq> if that means prores 4444 then that's not lossless [21:22:45 CET] <matkatmusic> https://s16.postimg.org/me5uxv6at/Screen_Shot_2017_03_22_at_4_22_06_PM.png [21:22:46 CET] <furq> it has a lossless alpha channel, which seems useful (i am lying) [21:22:58 CET] <alexpigment> prores is effectively lossless if you're going to re-encode. it's an intermediate format for a reason [21:23:07 CET] <matkatmusic> https://s11.postimg.org/5cw8uaqlv/Screen_Shot_2017_03_22_at_4_21_58_PM.png [21:23:07 CET] <furq> it's "visually lossless" according to apple [21:23:19 CET] <furq> but i would still complain if a $99 application told me it was lossless [21:23:32 CET] <matkatmusic> that's for "Lossless" setting [21:24:05 CET] <llogan> probably qtrle [21:24:08 CET] <matkatmusic> here's the WebHD: https://s18.postimg.org/6o2udqu6x/Screen_Shot_2017_03_22_at_4_23_41_PM.png [21:24:28 CET] <furq> not even a 2-pass option ;_; [21:24:31 CET] <matkatmusic> So, the raw footage Data Rate was 40.72Mbit/Sec [21:24:33 CET] <Threads> isn't everything from apple just 'BS' on a media level ? [21:24:50 CET] <alexpigment> matkatmusic - are you trying to make these files as small as possible, or is size even a concern? [21:25:35 CET] <furq> matkatmusic: https://www.macupdate.com/app/mac/24173/x264encoder [21:25:36 CET] <matkatmusic> size isn't a concern, but upload time is [21:25:38 CET] <furq> apparently that works with screenflow [21:26:45 CET] <matkatmusic> Where do you see that? [21:26:50 CET] <furq> http://telestreamblog.telestream.net/2010/02/apple-h-264-vs-x264-in-screenf… [21:27:22 CET] <furq> 2010, so hopefully they haven't broken it since then [21:28:32 CET] <alexpigment> i don't see any CRF settings in those screenshots [21:28:38 CET] <furq> i assume it's in a different tab [21:28:49 CET] <alexpigment> unless "Data Rate: Automatic" means CRF (which i doubt) [21:29:09 CET] <furq> x264 will be much better even if you can't use crf [21:29:13 CET] <alexpigment> true [21:29:52 CET] <alexpigment> but it really comes down to what's trying to be achieved here. if a bitrate of 3000kbps gets good results for matkatmusic and the upload time is acceptable, i'm not sure that x264 is going to make a meaningful difference [21:30:04 CET] <furq> if screenflow works with any quicktime component then there are probably plenty of others you can use [21:30:51 CET] <alexpigment> other than, of course, knowing that x264 will produce better quality at a given bitrate below saturation [21:39:58 CET] <Fenrirthviti> Hmm, is NVDefault an actual mode, or just a preset? Does anyone know what settings it translates to if a preset? Having trouble confirming. [21:40:12 CET] <Fenrirthviti> (for nvenc, of course) [21:42:50 CET] <matkatmusic> hey, that link is from 2010 [21:42:57 CET] <matkatmusic> check the date on those comments [21:44:41 CET] <alexpigment> Fenrirthviti: i just talked to BtbN about this earlier today, but couldn't get a good answer [21:44:52 CET] <alexpigment> according to him, it's not a good setting and is being deprecated [21:45:15 CET] <alexpigment> but yes, it's a preset [21:45:49 CET] <alexpigment> the recommendation is to use fast, medium, or slow instead (and preferrably slow) [21:45:52 CET] <Fenrirthviti> Yeah, I'm just trying to see what it actually translates to. I have a user complaining that the nvenc presets in OBS are not as good of quality as NVDefault, which I find very hard to believe. [21:46:17 CET] <alexpigment> wish i knew more, but i don't [21:46:22 CET] <Fenrirthviti> Our higher quality preset is hq (slow) [21:47:41 CET] <Fenrirthviti> Thanks though, alexpigment. [21:48:48 CET] <alexpigment> no problem. i do find it funny that i tried to get the exact same information earlier today ;) [22:10:46 CET] <Fenrirthviti> alexpigment: I'm still digging, if I find anything I'll let you know. [22:11:57 CET] <Fenrirthviti> everything I'm finding is saying NVDefault is much higher quality than even slow :\ [22:12:00 CET] <alexpigment> yeah cool. i don't need it as much as you, fwiw. i was really just trying to get more details about each preset because they don't seem to make as significant of a difference as x264 presets do [22:12:12 CET] <alexpigment> really? interesting [22:12:14 CET] <Fenrirthviti> but nothing is telling me what it's actually doing. [22:15:10 CET] <alexpigment> yeah i know [22:15:13 CET] <alexpigment> "It has most of the features enabled except B-frames." [22:15:24 CET] <alexpigment> that doesn't tell me much ;) [22:16:48 CET] <seb_> Hello, I want to use ffmpeg to find the same frame in a stream. So i decided to use -framemd5 but it doesn't work like i want: the same frame give me 2 md5 different. I suppose that's why it work by packet. Is there a command to have de md5 frame by frame from a stream? [22:17:05 CET] <seb_> Thanks for your help [22:18:09 CET] <Fenrirthviti> alexpigment: That's the ONLY note I can find about it. I don't even see it referenced in nvidia's docs, though those are lacking in more than one aspect [22:18:24 CET] <Fenrirthviti> Really annoying. [22:26:16 CET] <Fenrirthviti> reading the nvenc documentation and it doesn't have anything listed either. it just says "the client can use the presetGUID for configuring the encode [22:26:16 CET] <Fenrirthviti> session directly. This will automatically set the hardware encoder with appropriate [22:26:16 CET] <Fenrirthviti> parameters for particular use-case implied by the preset." [22:30:06 CET] <Fenrirthviti> Just read up on your conversation with BtbN, though, and it looks like there was a misunderstanding. NVDefault is not the same as default [22:30:13 CET] <alexpigment> ohhhhh [22:30:23 CET] <alexpigment> well, that explains that [22:30:29 CET] <alexpigment> is NVDefault not exposed in FFMPEG? [22:30:32 CET] <alexpigment> just OBS? [22:30:41 CET] <Fenrirthviti> It's exposed by the nvenc API, yeah [22:30:58 CET] <Fenrirthviti> so not sure if ffmpeg has an equivalent. [22:31:16 CET] <alexpigment> i just naturally assumed that the "default" preset was the same as NVDefault [22:32:06 CET] <Fenrirthviti> Looks like it definitely is not. [22:32:26 CET] <Fenrirthviti> seems to be some internal API call, but I'm having trouble finding out what it actually does. [22:32:31 CET] <Fenrirthviti> the API is not very well documented. [22:33:30 CET] <Fenrirthviti> Or maybe it is the same thing? Man I don't even know anymore :\ [22:33:46 CET] <alexpigment> haha [22:34:13 CET] <alexpigment> i mean it doesn't help you with that customer, obviously [22:34:58 CET] <alexpigment> given that i don't use OBS regularly, i presume they still have the NVDefault option right? [22:35:06 CET] <alexpigment> if so, they should just keep using it and stop complaining ;) [22:35:42 CET] <Fenrirthviti> We do, it's just changed names. [22:35:54 CET] <alexpigment> what name is it now? [22:41:24 CET] <Fenrirthviti> default [22:41:52 CET] <Fenrirthviti> it was never actually called nvdefault, whoever wrote the original code for the nvenc encoder options in OBS called it nvdefault for some reason. [22:42:16 CET] <alexpigment> ah, well that explains that discrepancy [22:42:41 CET] <Fenrirthviti> Sending me on a wild goose chase :\ [22:43:06 CET] <alexpigment> anyway, having dealt with customers about quality issues for quite a few years at this point, i never underestimate the power of screenshots and samples. usually it's like "oh, that's because you're doing something completely different than you said you were" [22:43:51 CET] <alexpigment> so hopefully you've got actual proof of what they're saying before tearing your hair out just because of what they told you [22:44:13 CET] <Fenrirthviti> well OBS is free and I'm just community support, I couldn't care less about proving anything to them :P [22:44:22 CET] <Fenrirthviti> I'm providing the facts, they can do what they want with it. [22:44:30 CET] <alexpigment> fair enough [22:44:44 CET] <alexpigment> i'd at least get a screenshot if you haven't already though [22:44:59 CET] <alexpigment> there's probably another explanation [22:46:45 CET] <Fenrirthviti> The end user is an idiot who claims shadowplay is better, is the explanation. [22:54:27 CET] <mac_nibblet> Heya, i'm exporting a bunch of thumbnails from a video using scene detection, I want to figure out when exactly the frame is from, how do I do that ? [22:54:38 CET] <mac_nibblet> ffmpeg -i video.mp4 -vf "select=gt(scene\,0.6),scale=250:-1" -frames:v 9 -vsync vfr -loglevel verbose images-%d.jpg [22:54:41 CET] <mac_nibblet> is the command i'm running [22:54:58 CET] <Fenrirthviti> scene detection what [22:55:08 CET] <Fenrirthviti> oh wait, nevermind. [22:55:18 CET] Action: mac_nibblet did not copy most of this of stackoverflow. [23:00:35 CET] <mac_nibblet> Fenrirthviti, any idea how to do this ? [23:00:46 CET] <Fenrirthviti> I do not. [23:02:21 CET] <kcghost> Quick question regarding mapping audio streams. I am specifying by an id, e.g. "-map i:0x1100", and found that I got two audio streams in the output since there are two input audio streams with that id. Is there a way to tell ffmpeg to select only one? Perhaps the highest quality one? [23:11:39 CET] <idlus> kcghost: you can select streams with "m:key[:value]" rather than "i:index", maybe you could use that to specify quality? [23:16:32 CET] <kcghost> idlus: this is to avoid having to parse it out, I don't know the quality or much about the stream beforehand [23:50:16 CET] <kcghost> idlus: I think I have a somewhat crazy solution, have ffmpeg with the ids and copy streams and pipe into another ffmpeg that will by default just select the best streams. [23:51:11 CET] <kcghost> idlus: though i think I ran into a bug with mpegts and the 'truehd' audio codec, it shows up as an unknown stream in the output. [00:00:00 CET] --- Thu Mar 23 2017

1 0

ffmpeg-devel.log.20170321
by burek 22 Mar '17

22 Mar '17

[00:12:03 CET] <cone-785> ffmpeg 03Gerion Entrup 07master:5e3a418b6047: add signature filter for MPEG7 video signature [00:12:49 CET] <atana> michaelni, I am getting 2 failures with 2048 window size [00:14:26 CET] <michaelni> atana, hmm, great [00:14:44 CET] <michaelni> atana, can you push your code to github ? [00:14:58 CET] <atana> but you were getting 7 failures I guess [00:15:03 CET] <atana> I will push the code [00:19:15 CET] <atana> michaelni, code pushed [00:26:20 CET] <michaelni> atana, confirmed, its 2 here too, i must have had a mistake in the code when i tried earlier [00:26:44 CET] <michaelni> atana, does it improve further for 4096 or 8192 ? [00:26:52 CET] <atana> ok so I will try will other window setting too [00:27:00 CET] <atana> *with [00:46:44 CET] <atana> michaelni, it remain 2 for 4096 and 8129 [00:48:27 CET] <michaelni> atana, each case is split in 64 sample blocks and for 8 of them the peak frequencies are stored and looked up [00:49:05 CET] <michaelni> atana, maybe using more than 8 works better, there should be more peaks beyond 1024 [00:57:44 CET] <atana> I will it [00:57:50 CET] <atana> *try [01:14:43 CET] <atana> michaelni, I used 10 points and it gives 160 errors. I replaced 8 with 10 and 7 with 9 [01:15:07 CET] <atana> *failures [01:27:09 CET] <michaelni> atana, entry and buff sizes probably need to be bigger [03:12:15 CET] <jamrial> so chromium now supports apng and firefox is going to support webp [04:02:19 CET] <wm4> jamrial: and the world became a worse place [04:34:52 CET] <philipl_> ubitux: Yeah. no-op was the right thing to do. [04:35:18 CET] <philipl> There's no benefit in perpetuating this whole YUV444P16-is-ok thing. [04:35:24 CET] <philipl> The nvenc mess is still outstanding there. [04:36:20 CET] <philipl> BtbN: speaking of messes - have you looked at the bframe failure? [06:41:11 CET] <cone-847> ffmpeg 03wm4 07master:d682ae70b4b3: avcodec, avformat: deprecate anything related to side data merging [06:41:11 CET] <cone-847> ffmpeg 03wm4 07master:87c082c42602: ffmpeg: don't unnecessarily use a deprecated API function [06:41:11 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:749262693247: pthread_frame: use atomics for PerThreadContext.state [06:41:11 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:b6587421c779: pthread_frame: use atomics for frame progress [06:41:11 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:98f89d615b64: pthread_frame: properly propagate the hw frame context across frame threads [06:41:12 CET] <cone-847> ffmpeg 03Mark Thompson 07master:fb69a8e1f124: pthread_frame: Unreference hw_frames_ctx on per-thread codec contexts [06:41:12 CET] <cone-847> ffmpeg 03Wan-Teh Chang 07master:c358c62550e6: pthread_frame: use better memory orders for frame progress [06:41:13 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:14bb15bfd56d: pthread_frame: ensure the threads don't run simultaneously with hwaccel [06:41:13 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:e0cd598bc468: pthread_frame: do not run hwaccel decoding asynchronously unless it's safe [06:41:14 CET] <cone-847> ffmpeg 03wm4 07master:2e5c52896b0a: pthread_frame: remove some dead code [06:41:15 CET] <cone-847> ffmpeg 03wm4 07master:66963d4b8d30: avcodec: remove warning against using frame threading with hwaccels [06:46:00 CET] <wm4> hm forgot to clean up certain "details" (not related to actual code) [06:46:03 CET] <wm4> but whatever [07:40:16 CET] <wm4> wow fate doesn't print some commands even with V=1 [07:45:47 CET] <wm4> that gets pretty confusing when an earlier command is crashing [08:05:22 CET] <cone-847> ffmpeg 03Carl Eugen Hoyos 07master:4b192ffdbe22: ffmpeg: Initialize two stack variables. [08:27:37 CET] <cone-847> ffmpeg 03Vittorio Giovara 07master:de8e096c7eda: swscale: Consistently order input YUV pixel formats [08:27:38 CET] <cone-847> ffmpeg 03Clément BSsch 07master:fa8db3f5975e: Merge commit 'de8e096c7eda2bce76efd0a1c1c89d37348c2414' [08:30:02 CET] <ubitux> michaelni: opinions on e87a501e7d03ac68b58520108fe24ad9d0b36765? [08:30:15 CET] <ubitux> it looks like we are currently checking against 14 instead of 15 [08:30:26 CET] <ubitux> but i'm wondering if that's not on purpose due to overflow risks [09:24:24 CET] <ubitux> michaelni: basically this: http://sprunge.us/Rfde (passes FATE here) [09:49:52 CET] <BtbN> philipl, bframe failure? Last thing I looked at was cuvid mpeg2 getting stuck, which doesn't happen on both of my machines, no matter how often I re-run it. [10:32:16 CET] <wm4> jkqxz: are you going to push your changes to ffmpeg too? [10:36:56 CET] <jkqxz> The hw_device_ctx support? Yes, soon. I think the generic hardware support in ffmpeg.c and deleting ffmpeg_*.c wants to wait for the next set, though. [10:39:22 CET] <jkqxz> (It doesn't actually do anything other than cleanup yet.) [10:41:35 CET] <wm4> why would that wait? [10:43:51 CET] <durandal_1707> anyone can generate raw dnxhd/dnxhr files for me? [10:44:19 CET] <durandal_1707> im looking for variable sizes of frames [10:44:49 CET] <jkqxz> wm4: It needs clearer use-cases to resist attack by bikeshedders. [10:57:56 CET] <jkqxz> Hmm. That VAAPI hwaccel example doesn't actually need to have any dependency on VAAPI at all. [10:58:33 CET] <jkqxz> Given that it was from Intel they might not appreciate it working for VDPAU as well, though... [11:00:11 CET] <wm4> they still need to know about the pixfmt, don't they [11:05:47 CET] <jkqxz> Only for the actual output writing. rawvideo could deal with that, but probably isn't helpful for the example. [11:06:17 CET] <wm4> I mean you need to select the hwaccel impl in get_format [11:09:49 CET] <jkqxz> Hmm, yeah. The pixfmts supported by a given device aren't actually exported. Maybe they should be. [11:11:03 CET] <wm4> yes, and/or making AVCodecContext.hw_device_ctx select it by default in the default get_format callback [11:11:48 CET] <wm4> also elenril talked about changing the way hwaccels are selected (some other callback instead of get_format?) [11:23:45 CET] <jkqxz> Yeah, selecting it by default if hw_device_ctx is set and get_format isn't is probably sensible. (That still needs some way to match pixfmt to device type, though.) [11:46:52 CET] <feliwir> what is the bits and max_depth parameter of get_vlc2 supposed to be? If max_depth is the depth of the huffman tree that is also the amount of bits required to be read [11:51:31 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:b4da4307a91e: avcodec/fmvc: small refactoring in decode_type1() [11:55:09 CET] <feliwir> also what is n0 representing in the node struct? [11:58:00 CET] <michaelni> ubitux, do you have any case where it makes a difference ? i also think the 14 was intentional but easiest would be if there was something to test these codepathes [11:58:56 CET] <ubitux> it passes FATE so apparently it made no difference (except maybe faster in some cases?) [11:59:29 CET] <michaelni> do we have 15bit pixel formats ? [11:59:59 CET] <ubitux> not afaik [12:00:31 CET] <wm4> RGB555? [12:00:34 CET] <ubitux> IO... yuv420p10be 3 15 [12:00:36 CET] <ubitux> IO... yuv420p10le 3 15 [12:00:37 CET] <michaelni> ubitux, then maybe nothing triggers the changed path [12:00:38 CET] <ubitux> these? [12:00:50 CET] <ubitux> IO... p010le 3 15 [12:00:52 CET] <ubitux> IO... p010be 3 15 [12:00:55 CET] <michaelni> wm4, thats 5bit [12:01:09 CET] <ubitux> IO... rgb555be 3 15 [12:01:11 CET] <ubitux> IO... rgb555le 3 15 [12:01:17 CET] <durandal_1707> heh [12:01:18 CET] <michaelni> i should have said 15 bit per sample [12:03:39 CET] <ubitux> so what's your opinion? should we move to 15 even if unused currently to make it consistent with libav and the function names, or keep our 14 suggesting there might be an issue with 15? [12:05:33 CET] <ubitux> (functions are called hScale8To15_c, hScale16To15_c, ff_hscale8to15, ... [12:05:35 CET] <ubitux> ) [12:06:33 CET] <michaelni> I prefer to keep 14 until theres a case that allows us to test this and i suspect it will not work with 15 at least not all the code [12:06:47 CET] <ubitux> OK [12:07:26 CET] <ubitux> in the same spirit i'll noop the rename from is9_OR_10BPS to is9_15BPS and keep our isNBPS [12:07:47 CET] <michaelni> ok [12:07:49 CET] <ubitux> as it's not actually the 9-15 range but a 9-14 that could change [12:08:38 CET] <michaelni> also ill do some tests with avaseert to check that things arent 15 in some unexpected corner case [12:08:39 CET] <ubitux> i might have some questions for the introduction of the pixel formats we already have as they may have introduced some differences [12:09:04 CET] <ubitux> ok, thanks :) [12:19:14 CET] <cone-847> ffmpeg 03Luca Barbato 07master:e87a501e7d03: swscale: Update bitdepth range check [12:19:15 CET] <cone-847> ffmpeg 03Clément BSsch 07master:2ea585b8e3f6: Merge commit 'e87a501e7d03ac68b58520108fe24ad9d0b36765' [12:22:58 CET] <cone-847> ffmpeg 03Luca Barbato 07master:2b5b1e1e9b89: swscale: Rename is9_OR_10 to match what it does [12:22:59 CET] <cone-847> ffmpeg 03Clément BSsch 07master:51f88ac57b90: Merge commit '2b5b1e1e9b89063d352e2efed014f9d761b85032' [12:38:56 CET] <cone-847> ffmpeg 03Clément BSsch 07master:6476bb84bca3: lavc/hwaccel: fix header copyright [12:51:13 CET] <cone-847> ffmpeg 03Luca Barbato 07master:85406e7a8d5a: pixfmt: Add yuv420p12 pixel format [12:51:14 CET] <cone-847> ffmpeg 03Luca Barbato 07master:0aebbbd02476: pixfmt: Add yuv422p12 pixel format [12:51:15 CET] <cone-847> ffmpeg 03Luca Barbato 07master:9bd6ea569566: pixfmt: Add yuv444p12 pixel format [12:51:16 CET] <cone-847> ffmpeg 03Luca Barbato 07master:0e8d1fc1f013: lavu: Bump version for the 12bit Planar YUV support [12:51:17 CET] <cone-847> ffmpeg 03Clément BSsch 07master:876e32f7fc17: Merge commit '0e8d1fc1f013eb805a7b66656d9452bcbca36d22' [12:53:38 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:6c09af7e46a5: APIchanges: fix a typo in the version number [12:53:39 CET] <cone-847> ffmpeg 03Clément BSsch 07master:81dc9b77a757: Merge commit '6c09af7e46a5a1ada67ffe832f7895cf2749130b' [12:55:54 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:6f733ecab6fa: mpegvideo_enc: add const to the AVCodec instance [12:55:55 CET] <cone-847> ffmpeg 03Clément BSsch 07master:70ca9b76e2af: Merge commit '6f733ecab6faff2a16534f2ce7d2ffd41c07846b' [13:00:19 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:f03f78bc1c99: mpegvideo_enc: handle encoding errors with b_strategy=2 [13:00:20 CET] <cone-847> ffmpeg 03Clément BSsch 07master:b2cb9191eaf2: Merge commit 'f03f78bc1c99b1e29624418e2f7315b8a47981e9' [13:04:32 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:68811a41c70f: mpegvideo_enc: use the new encoding API for b_strategy=2 [13:04:34 CET] <cone-847> ffmpeg 03Clément BSsch 07master:e6be531a30b7: Merge commit '68811a41c70f019bde6df2a4f289674228c48958' [13:15:49 CET] <wm4> BBB: I don't think an API user really needs to care about it, but it sure will be confusing if it tries to use both [13:16:00 CET] <BBB> thats the whole point [13:16:06 CET] <cone-847> ffmpeg 03Kieran Kunhya 07master:4cca2f74f253: vf_drawtext: Fix memory leak [13:21:22 CET] <mateo`> wm4: for what it's worth, i also want a single API, i didn't take a look at the new API (is the transformation exported as a matrix ?) [13:21:48 CET] <wm4> mateo`: yes, see libavutil/display.h [13:22:21 CET] <wm4> there are also convenient accessors that give you the old API essentially (just not using AVDictionary) [13:23:48 CET] <mateo`> where is the transformation matrix exported ? in AVCodecContext ? [13:24:33 CET] <wm4> AVFrame side data [13:24:43 CET] <nevcairiel> can i get the rotation directly from an avformatcontext after probing? [13:24:51 CET] <nevcairiel> or avstream as it may be [13:24:58 CET] <wm4> nevcairiel: yes via AVStream side data [13:25:12 CET] <wm4> (seriously why is this side data stuff inconsistently duplicated everywhere) [13:25:39 CET] <nevcairiel> if it wouldnt be, then my use-case would break =p [13:25:51 CET] <nevcairiel> i dont have decoding or frames in the component that wants to export the rotation [13:25:54 CET] <wm4> no mechanism gets lost [13:28:59 CET] <mateo`> well, my probing library already uses this api [13:46:25 CET] <mateo`> I just gave a quik look at the patch and I'm in favor of it, I also wonder if mjpeg{dec,enc} should honor this api (regarding the exif orientation tag) [13:59:44 CET] <wm4> yes they should [14:18:28 CET] <BBB> wm4: removing the metadata quite literally just means removing the side-data field from the AVFrame, e.g. in a filter [14:18:42 CET] <wm4> ah [14:18:49 CET] <BBB> wm4: theres many ways to do that, maybe ubitux wants a commandline switch to do that in ffmpeg.c? lets ask him [14:19:05 CET] <BBB> there may not be a user-accessible way to do that in ffmpeg.exe ATM [14:19:10 CET] <wm4> well that metadata hack I point out in the patch is supposed to do just that [14:19:19 CET] <BBB> ah, ok [14:19:24 CET] <wm4> old API => you could override the metadata field [14:19:38 CET] <wm4> new API => needs a dedicated mechanism, but is emulated here [14:20:22 CET] <ubitux> there are several cases you want to be able to handle at cli: hard rotate (filters), remux/transcode without loss of rotation information, remux/transcode dropping or altering the rotate information [14:20:41 CET] <ubitux> (hard rotate means you want to drop the rotation information too btw) [14:20:53 CET] <ubitux> these are commons cases for cli users [14:21:20 CET] <cesdo> Hey guys, help me to configure ffmpeg, please! [14:21:27 CET] <BBB> cesdo: #ffmpeg [14:21:49 CET] <BBB> cesdo: this channel is for development of ffmpeg, not user support with ffmpeg [14:24:54 CET] <cesdo> BBB: It's silence there(( Probably, only the developers know how to overcome it)) So, may I ask a question? [14:25:18 CET] <BBB> cesdo: wait patiently until someone has time to help you, please dont ask user questions here [14:27:29 CET] <wm4> BBB: maybe let him ask his question? then we know whether it's more a user or a devel question [14:27:50 CET] <BBB> configure ffmpeg sounds very userish to me? ;) [14:28:11 CET] <BBB> but sure if you isist [14:28:18 CET] <hemalpatil> BBB: what task do I need to do to qualify for the VMAF project? [14:29:23 CET] <BBB> hemalpatil: the original qual task was given out and finished already, so we need something else& Im considering whether it makes sense to librarify vmaf and link to it as an alternate qual task [14:29:34 CET] <BBB> do you guys think thats suitable? should be ok right? [14:30:36 CET] <hemalpatil> BBB: does that mean I will not be to able apply for it for GSoC'17? [14:30:42 CET] <BBB> you will [14:30:51 CET] <BBB> but it means theres multiple candidates for each project [14:30:51 CET] <hemalpatil> ok [14:32:24 CET] <BBB> https://github.com/Netflix/vmaf/blob/master/wrapper/src/vmaf.cpp thats the source code for the c++ version (non-python) of the vmaf tool. I think a suitable qualification task (this isnt easy, but should be doable nonetheless) is to basically turn the API used by this tool into a library on their end, and then link against that API in a ffmpeg video filter [14:32:32 CET] <hemalpatil> will you be selecting the candidates after the applications close (April 3rd)? also, do you have only 1 student per project or multiple students? [14:32:34 CET] <BBB> thats still pretty close to the original GSoC task [14:32:45 CET] <BBB> 1 student, and well pick the best [14:32:52 CET] <BBB> (if we get enough spots) [14:33:13 CET] <BBB> if we have enough spots, well find alternative gsoc projects for the student not selected for his/her preferred project [14:33:18 CET] <BBB> (or something like that) [14:33:33 CET] <hemalpatil> alright. any deadlines (other than April 3rd)? [14:34:09 CET] <wm4> BBB: I mean there's a chance he's a developer who can or did analyze the problem and even write a patch [14:34:54 CET] <BBB> I only select students who finish a qualification task, so it needs to be finished by whenever we have to select projects [14:35:33 CET] <hemalpatil> ok, thanks for your help [14:44:23 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:de2ae3c1fae5: lavc: add clobber tests for the new encoding/decoding API [14:44:24 CET] <cone-847> ffmpeg 03Clément BSsch 07master:ad98af27f710: Merge commit 'de2ae3c1fae5a2eb539b9abd7bc2a9ca8c286ff0' [14:45:24 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:7bf8db4db61e: tdsc: use the new decoding API [14:45:25 CET] <cone-847> ffmpeg 03Clément BSsch 07master:5dfe343d96dc: Merge commit '7bf8db4db61eb09fac00eb665d8ec58de8817da6' [14:46:10 CET] <cesdo> wm4: Ok. I used --pkg-config-flags="--static" ---enable-libx265 and got "ERROR: x265 not found using pkg-config". I did instructions from https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu. Libx265-dev was installed from repos. What's the safest way to solve it? [14:46:58 CET] <ubitux> wrong channel [14:48:04 CET] <ubitux> wm4: do you wish to port our examples to the new decode/encode api? [14:48:22 CET] <ubitux> advertising deprecated api is not that great [14:49:02 CET] <ubitux> `make examples` shows ton of warnings related to the old api [14:49:03 CET] <wm4> ubitux: I wish someone else to do it [14:49:40 CET] <ubitux> i'm hitting 67d28f4a0fb where there is a port to that new api, but doesn't apply to our code [14:49:45 CET] <ubitux> still, we need to fix it [14:50:08 CET] <ubitux> i'd like to go ahead with the merges so i won't have time to do that [14:50:18 CET] <ubitux> (and i have other daemons on the todo list) [14:54:17 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:67d28f4a0fbb: examples/output: switch to the new encoding API [14:54:18 CET] <cone-847> ffmpeg 03Clément BSsch 07master:bb7cc5b5d928: Merge commit '67d28f4a0fbb52d0734ca3682b85035e96d294fb' [14:54:27 CET] <wm4> skipping it for now should be ok [14:59:49 CET] <cone-847> ffmpeg 03Mark Thompson 07master:80a5d05108cb: vaapi_encode: Refactor initialisation [14:59:50 CET] <cone-847> ffmpeg 03Mark Thompson 07master:892bbbcdc171: vaapi_encode: Check packed header capabilities [14:59:51 CET] <cone-847> ffmpeg 03Mark Thompson 07master:086e4b58b59e: vaapi_encode: Sync to input surface rather than output [14:59:52 CET] <cone-847> ffmpeg 03Mark Thompson 07master:956a54129db5: vaapi_h264: Set max_num_ref_frames to 1 when not using B frames [14:59:53 CET] <cone-847> ffmpeg 03Clément BSsch 07master:267cb20e2bf3: Merge commit '956a54129db522998a5abae869568dae2c9774cb' [15:04:53 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:009adfd4fbdd: x86: fpel: Remove unnecessary sign extend [15:04:54 CET] <cone-847> ffmpeg 03Clément BSsch 07master:f54da138e98c: Merge commit '009adfd4fbdd78a890a4a65d6f141c467bb027fa' [15:11:31 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:92c5755a1850: hpeldsp: arm: Update comments left behind in 25841dfe806a13de526ae09c11149ab1f83555a8 [15:11:32 CET] <cone-847> ffmpeg 03Clément BSsch 07master:51b5672f49f5: Merge commit '92c5755a185086067fe49e7e64c23a8e7011be31' [15:15:59 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:3281d823cdc7: intrax8: Change type of array stride parameters to ptrdiff_t [15:16:00 CET] <cone-847> ffmpeg 03Clément BSsch 07master:6eb75e7d592d: Merge commit '3281d823cdc7601c4900eb103958c05f59f65555' [15:21:12 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:b2939a75270b: blockdsp: Change type of array stride parameters to ptrdiff_t [15:21:13 CET] <cone-847> ffmpeg 03Clément BSsch 07master:6d11b2f65676: Merge commit 'b2939a75270bc7e971462648168aa3a2a48c1c8c' [15:27:56 CET] <ubitux> the next merges are starting to be quite annoying and will require some testing [15:28:16 CET] <ubitux> (i may already have break some mips some way or another in previous ones) [15:28:25 CET] <ubitux> anyone willing to take over those? [15:28:43 CET] <ubitux> (ETA: 829) [15:29:40 CET] <philipl> BtbN: As soon as you ask for bframes when transcoding with hwaccel, you get an out-of-surfaces error [15:29:54 CET] <ubitux> is anyone working on some oracle-like on our fate? [15:30:04 CET] <ubitux> so i can at least test that way? [15:30:08 CET] <philipl> Regardless of input codec, and obviously h264 on the output (nvenc doesn't support hevc bframes) [15:34:15 CET] <ubitux> michaelni: it seems there is a leak in swr: http://fate.ffmpeg.org/report.cgi?time=20170321032538&slot=x86_64-archlinux… [15:34:24 CET] <ubitux> (might be an opus misusage) [15:34:44 CET] <nevcairiel> there was a fix on the ml from jamrial, possibly thats this one [15:34:54 CET] <jamrial> yes [15:35:10 CET] <michaelni> nevcairiel, yes, thought the same [15:35:39 CET] <jamrial> wm4 reviewed it but i didn't commit it yet to save ubitux some merge rebasing [15:35:53 CET] <ubitux> you can go ahead, i'm not merging anything right now [15:35:59 CET] <ubitux> thanks for caring :) [15:36:07 CET] <jamrial> alright [15:36:17 CET] <ubitux> btw, if you want to enjoy some ptrdiff_t search and replace, you can take over :p [15:36:37 CET] <ubitux> i'll work on moving my fate instances this afternoon i guess [15:37:20 CET] <ubitux> carefull with the ptrdiff_t as they may involve code we have in other arch such as mips, aarch64 or even... alpha [15:37:21 CET] <jamrial> did you solve the bitflip issue? the other day i saw your instances failing on a lot of tests randomly [15:37:51 CET] <ubitux> i don't know, i'm pissed of of it, so i just upgraded to a new machine at the same cost [15:37:55 CET] <ubitux> i just need to do the migration [15:38:04 CET] <jamrial> heh, alpha is alive because i carried it blindly through the dsputils purge :p [15:38:10 CET] <jamrial> maybe we should just let it die [15:38:33 CET] <jamrial> it doesn't even have real asm. just "optimal" c versions for some compiler from a decade ago [15:39:33 CET] <jamrial> no wait, it does have some asm. meh [15:40:32 CET] <jamrial> ubitux: i'll try to merge a couple of these [15:40:51 CET] <ubitux> cool, thanks :) [16:01:40 CET] <BBB> michaelni: bugs are fairly normal, dont take any of this so personal, its just code& regressions can be addressed [16:02:17 CET] <michaelni> BBB: what do you talk about ? [16:02:23 CET] <michaelni> i take nothing personal [16:03:01 CET] <BBB> the hw accel/frame-mt patches being committed [16:05:12 CET] <michaelni> BBB, why do you think iam taking any of it personal ? [16:05:34 CET] <michaelni> i pointed out that patches should be sent to the ML after it was pushed and broke ffplay [16:05:48 CET] <cone-847> ffmpeg 03James Almer 07master:2a8a8a2e9813: swresample/resample: move resample_free() higher in the file [16:05:49 CET] <cone-847> ffmpeg 03James Almer 07master:db7a05dab065: swresample/resample: free existing ResampleContext on reinit [16:09:59 CET] <BBB> michaelni: I dont know, it sounded like you were irritated& Im just suggesting we all chill [16:11:13 CET] <jamrial> the problems of text based communication :p [16:23:17 CET] <cone-847> ffmpeg 03James Almer 07release/2.8:f7f5a524590b: swresample/resample: move resample_free() higher in the file [16:23:18 CET] <cone-847> ffmpeg 03James Almer 07release/2.8:31e65eb84d6d: swresample/resample: free existing ResampleContext on reinit [16:23:19 CET] <cone-847> ffmpeg 03James Almer 07release/3.0:2423dd965637: swresample/resample: move resample_free() higher in the file [16:23:20 CET] <cone-847> ffmpeg 03James Almer 07release/3.0:4c97b79cf560: swresample/resample: free existing ResampleContext on reinit [16:23:21 CET] <cone-847> ffmpeg 03James Almer 07release/3.1:f9083dec0c2e: swresample/resample: move resample_free() higher in the file [16:23:22 CET] <cone-847> ffmpeg 03James Almer 07release/3.1:8e4abfbb9dbc: swresample/resample: free existing ResampleContext on reinit [16:23:23 CET] <cone-847> ffmpeg 03James Almer 07release/3.2:2d322bf3e9d9: swresample/resample: move resample_free() higher in the file [16:23:24 CET] <cone-847> ffmpeg 03James Almer 07release/3.2:2bf28b9db6e7: swresample/resample: free existing ResampleContext on reinit [16:29:12 CET] <wm4> michaelni, BBB: well the mention that patches should be sent to the ML is certainly bullshit (I posted an updated patch on the ML, just that it was a _link_ to a patch) [16:29:25 CET] <wm4> also also this implicit accusation that I pushed too early [16:30:34 CET] <wm4> I also pushed 24 h after the updated patch [16:34:15 CET] <michaelni> http://ffmpeg.org/developer.html 1.6 Submitting patches "Patches should be posted to the ffmpeg-devel mailing list. Use git send-email when possible since it will properly send patches without requiring extra care. If you cannot, then send patches as base64-encoded attachments ..." [16:52:03 CET] <nevcairiel> lets just fix the issue, shall we [16:58:38 CET] <wm4> well, the mutex is initialized and locked, and then the first unlock call on it appears to fail [16:58:42 CET] <wm4> valgrind seems clean [16:59:03 CET] <wm4> it happens because ffplay calls ff_thread_flush first thing [16:59:19 CET] <wm4> I guess I'll take a closer look at it later [17:37:45 CET] <jamrial> michaelni: could you check on your qemu machines (arm, aarc64) if https://github.com/jamrial/FFmpeg doesn't complain about conflicting/incompatible types? [17:42:25 CET] <mateo`> jamrial: i can check on my aarch64 box [17:43:08 CET] <jamrial> mateo`: cool, thanks [17:44:39 CET] <mateo`> jamrial: i'll run fate and let you know the outcome if that helps (the box is quite slow, i'll ping you back in 2 or 3hours if that's not too late) [17:47:36 CET] <jamrial> mateo`: compiling to see if it warns about conflicting/incompatible types should be enough i think, no need to run the whole fate suite [17:49:04 CET] <mateo`> jamrial: ok, i'll let you know [17:49:06 CET] Action: mateo` afk for a bit [17:59:48 CET] <peloverde> Has the pushurl changed recently? my auth is failing [18:02:01 CET] <jamrial> peloverde: source.ffmpeg.org is failing for me every now and then, but only when i tried to pull [18:02:07 CET] <jamrial> had no issues trying to push [18:04:11 CET] <michaelni> peloverde, nothing should have chnaged recently [18:07:14 CET] <michaelni> jamrial, should i just test build or fate too under qemu ? [18:08:07 CET] <jamrial> michaelni: build should be enough imo [18:08:47 CET] <ubitux> jamrial: well it changes the way args are handled, so it should probably run the asm, no? [18:09:02 CET] <ubitux> (doesn't it need use of different registers?) [18:09:40 CET] <jamrial> the actual commit i'm merging doesn't touch asm on any arch, just the prototypes, so dunno [18:09:46 CET] <jamrial> fate passes on x86 at least [18:10:07 CET] <cone-847> ffmpeg 03Alex Converse 07master:2c8a3aa985ac: aacsbr: Turnoff in the event of over read. [18:10:23 CET] <peloverde> ^ solved [18:10:40 CET] <nevcairiel> should be fine without asm changes, you can afterwards perhaps remove a bit of redundant asm that did zero-extend in asm [18:10:55 CET] <nevcairiel> but that would only affect 64-bit asm to begin with [18:11:15 CET] <nevcairiel> so aarch64 and x86_64 at most [18:12:38 CET] <jamrial> yeah, next commit in queue removes a sign extend instruction from an aarch64 asm function, for example [18:12:59 CET] <jamrial> same thing we have always done for x86_64 [18:17:24 CET] <michaelni> jamrial, here is arm: build log http://pastebin.com/SiaL434h [18:23:10 CET] <michaelni> jamrial, heres mips: http://pastebin.com/DrBghvZG (minus half a megabyte of unrelated msingle-float warnings) [18:26:20 CET] <ubitux> does that mips have msa or mii or both? [18:26:33 CET] <ubitux> (or none) [18:31:15 CET] <jamrial> both those logs seem good [18:38:24 CET] <michaelni> MSA seems disabled, does modern qemu support msa ? [18:52:45 CET] <jamrial> michaelni: shouldn't you be able to cross compile it even if qemu doesn't support emulating it? [18:53:25 CET] <michaelni> if my compiler supports it ... what configure params should i try ? [18:54:26 CET] <michaelni> also i have that real mips machine i can try if its important [18:56:22 CET] <jamrial> michaelni: looks like --cpu should do it [18:56:36 CET] <jamrial> no idea which one to choose, though [18:57:33 CET] <jamrial> the only fate instance apparently also disables all asm [18:58:03 CET] <jamrial> meh, if it breaks someone who cares about mips can report it [18:59:52 CET] <jamrial> michaelni: try --cpu=p5600 [19:00:08 CET] <michaelni> will do in a moment just need to finish a bisect [19:00:18 CET] <jamrial> configure checks for compiler support for that one and seems to enable all asm [19:03:54 CET] <michaelni> jamrial, ccache mips-linux-gnu-gcc-4.4 is unable to create an executable file. [19:04:07 CET] <michaelni> cc1: error: unrecognized command line option "-mtune=p5600" [19:04:30 CET] <jamrial> ah well [19:05:09 CET] <jamrial> with no --cpu configure checks for msa inline asm anyway, so guess the compiler is too old [19:05:25 CET] <jamrial> i'll push it then [19:07:39 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:2ec9fa5ec60d: idct: Change type of array stride parameters to ptrdiff_t [19:07:40 CET] <cone-847> ffmpeg 03James Almer 07master:5a49097b42cb: Merge commit '2ec9fa5ec60dcd10e1cb10d8b4e4437e634ea428' [19:11:49 CET] <michaelni> gcc 5 with --cpu=p5600 still #define HAVE_MSA 0 [19:12:35 CET] <michaelni> mips-linux-gnu-gcc-5: error: unrecognized command line option '-mmsa' [19:20:23 CET] <jamrial> wonder if it even work with any compiler at all then... [19:27:08 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:e4a94d8b36c4: h264chroma: Change type of stride parameters to ptrdiff_t [19:27:09 CET] <cone-847> ffmpeg 03James Almer 07master:a8474df9447d: Merge commit 'e4a94d8b36c48d95a7d412c40d7b558422ff659c' [19:54:58 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:ba479f3daafc: hevc: Change type of array stride parameters to ptrdiff_t [19:54:59 CET] <cone-847> ffmpeg 03James Almer 07master:1e185488269f: Merge commit 'ba479f3daafc7e4359ec1212164569ebe59f0bb7' [19:56:43 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:a339e919cad1: ea: Change type of array stride parameters to ptrdiff_t [19:56:44 CET] <cone-847> ffmpeg 03James Almer 07master:b16752f694a5: Merge commit 'a339e919cad1ab0125948f0dd9d49f6cb590db89' [19:58:51 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:15b4f494fc6b: mss*: Change type of array stride parameters to ptrdiff_t [19:58:52 CET] <cone-847> ffmpeg 03James Almer 07master:a0478341f34b: Merge commit '15b4f494fc6bddb8178fdb5aed18b420efc75e22' [20:05:52 CET] <cone-847> ffmpeg 03Diego Biurrun 07master:2caa93b813ad: mpegaudiodsp: Change type of array stride parameters to ptrdiff_t [20:05:53 CET] <cone-847> ffmpeg 03James Almer 07master:9a0fbb9ca925: Merge commit '2caa93b813adc5dbb7771dfe615da826a2947d18' [20:11:40 CET] <cone-847> ffmpeg 03Hendrik Leppkes 07master:8d1267932ca9: x86/h264_weight: use appropriate register size for weight parameters [20:11:41 CET] <cone-847> ffmpeg 03James Almer 07master:387d96fcf54b: Merge commit '8d1267932ca9c2e343ef303349101bab6681d02e' [20:13:14 CET] <jamrial> 83548fe894cdb455cc127f754d09905b6d23c173 is the kind of commit that makes us regret having so many de/muxers :P [20:57:42 CET] <cone-847> ffmpeg 03Michael Niedermayer 07master:b15818642b4e: avcodec/mpegaudiodec_template: Fix 2 runtime error: signed integer overflow [20:57:43 CET] <cone-847> ffmpeg 03Michael Niedermayer 07master:423375d4f06a: avcodec/wavpack: Check shift [21:00:25 CET] <kierank> do memory leaks require backporting? [21:01:19 CET] <jamrial> doesn't hurt [21:03:44 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:83548fe894cd: lavf: fix usage of AVIOContext.seekable [21:03:45 CET] <cone-847> ffmpeg 03James Almer 07master:4de591e6fb73: Merge commit '83548fe894cdb455cc127f754d09905b6d23c173' [21:05:29 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:75c1db6152c7: avio: cosmetics, prettify AVIO_SEEKABLE_NORMAL [21:05:30 CET] <cone-847> ffmpeg 03James Almer 07master:de36e98a16f4: Merge commit '75c1db6152c7c90c7ce28c9adb945028e5512c4f' [21:10:33 CET] <cone-847> ffmpeg 03Anton Khirnov 07master:8ea35af7620e: avio: add a new flag for marking streams seekable by timestamp [21:10:34 CET] <cone-847> ffmpeg 03James Almer 07master:fc9f14c7de5b: Merge commit '8ea35af7620e4f73f9e8c072e1c0fac9a04ec161' [21:11:16 CET] <jamrial> ubitux: done with the search and replace party [21:11:27 CET] <ubitux> jamrial: thanks! [21:11:43 CET] <ubitux> i'll take over starting tomorrow [21:12:03 CET] <jamrial> no prob [21:37:14 CET] <kierank> what does this mean [21:37:16 CET] <kierank> usr/bin/ld:libswscale/libswscale.ver:1: syntax error in VERSION scrip [22:27:02 CET] <mateo`> jamrial: sorry for being late, but the build went fine on my aarch64 box, executing the simple_idct_put_neon functions [22:27:08 CET] <mateo`> went well [22:27:35 CET] <jamrial> mateo`: thanks [22:27:59 CET] <mateo`> jamrial: thanks for the merges :) [23:16:26 CET] <cone-847> ffmpeg 03James Almer 07master:d8962ffbd8aa: avutil/x86util: don't use movss in VBROADCASTSS macro when src and dst args are the same [23:16:27 CET] <cone-847> ffmpeg 03James Almer 07master:874eb012f75b: avformat/apng: fix setting frame delay when max_fps is set to no limit [23:16:28 CET] <cone-847> ffmpeg 03James Almer 07master:7bfbb7229971: avformat/apng: set max_fps to no limit by default [23:49:40 CET] <jkqxz> wm4: The VDPAU code on the two tines is subtly different such that device setup doesn't merge cleanly, so I've not done that for now. [00:00:00 CET] --- Wed Mar 22 2017

1 0

ffmpeg.log.20170321
by burek 22 Mar '17

22 Mar '17

[00:28:32 CET] <momomo> what is the -movflags +faststart option really for? i can't see that it makes any difference [00:29:04 CET] <DHE> it puts metadata needed to start playback near the front of the file so that streaming can playback without needing the whole file loaded [00:29:15 CET] <DHE> dunno about the specifics, but it's loosely like that [02:11:24 CET] <RossW> anyone got the ffmpeg incantation required to crop an area (x1,y1)-(x2,y2) from an incoming RTSP stream, to then use in the rest of my processing? [02:12:02 CET] <RossW> eg, if the stream is 2688x1500, and I want to take a 1920x1080 chunk of it, lets say out of the centre... ? [02:12:44 CET] <klaxa> https://ffmpeg.org/ffmpeg-filters.html#crop [02:15:30 CET] <RossW> klaxa: does that go before the -i? I'm a neophyte ffmpeg user and still getting my head around it's operation. [02:17:06 CET] <klaxa> ffmpeg -i rtsp://server -cf crop=1920:1080:384:210 output.mkv [02:17:10 CET] <klaxa> *-vf [02:17:16 CET] <klaxa> instead of -cf [02:17:30 CET] <RossW> Mmm. [02:17:42 CET] <RossW> ffmpeg -f lavfi -i anullsrc=channel_layout=stereo:sample_rate=44100 -buffer_size 128000 -rtsp_transport tcp -i "$camip" -c:v copy -c:a aac -pix_fmt yuv420p -s 1920x1080 -t $duration ..... (etc) [02:17:54 CET] <klaxa> you first define inputs, then what you want to do with it, then how to save it [02:18:23 CET] <klaxa> you should be able to put it anywhere between your input and your output [02:18:28 CET] <RossW> What I'm trying to get to is to read rtsp, cut/scale if required, then overlay a watermark/logo, then stream it. [02:18:37 CET] <klaxa> i prefer to put it before the codec settings, as it occurs before encoding [02:18:45 CET] <RossW> ok, I'll give that a go and see. [02:24:41 CET] <RossW> Filtergraph 'crop=w=200:h=200:x=400:y=500' was defined for video output stream 0:0 but codec copy was selected. [02:24:42 CET] <RossW> Filtering and streamcopy cannot be used together. [02:25:05 CET] <RossW> I guess I have to lose the -copy ?? [02:47:14 CET] <klaxa> yes [02:48:12 CET] <klaxa> since you want a watermark, you have to re-encode in any case [05:41:36 CET] <oerg866> Hi, how do I get VP9 packetizing working? [05:41:41 CET] <oerg866> http://img.ctrlv.in/img/17/03/21/58d0aef3665e9.png <-- this is as far as I got. [05:42:06 CET] <oerg866> Same principle works fine with h265 [05:42:09 CET] <oerg866> for example [06:07:59 CET] <petecouture> is there any performance different between scale=1024:576 versus -s 1280x576 I understand -s just puts it at the end of the filtergraph but I wanted to know if there's one that's recommended. [07:39:05 CET] <DHE> petecouture: no performance difference I think. unless you're changing the scaling algorithm which takes different syntax [08:11:48 CET] <petecouture> @DHE Gotcha thanks. Ya I think -s is just a shortcut to having to write out filter_complex [11:36:02 CET] <mcjack> Hi, can someone tell me how to get an AVPixFmtDescriptor from an AVPixelFormat? [11:38:49 CET] <mcjack> nevermind, found it: https://ffmpeg.org/doxygen/trunk/pixdesc_8c.html#afe0c3e8aef5173de28bbdaea4… [13:47:40 CET] <ZeroWalker> when you encode audio, are you supposed to buffer to the specified framesize, which would mean "framesize*channels*bytesPerSample" ? [13:48:00 CET] <mcjack> I try to write a video file similar to the code in decoding_encoding.c example, but the stream only has I_Frames. Any idea what I did wrong? [13:52:38 CET] <mcjack> you can see the code here, how I set up the encodercontext: https://github.com/filmstro/filmstro_ffmpeg/blob/master/modules/filmstro_ff… [13:55:50 CET] <mcjack> I also tried setting manually frame->pict_type either AV_PICTURE_TYPE_P or to NONE, thought it might make the encoder to choose the correct one& [14:05:55 CET] <cesdo> Hey, guys, I got an error ERROR: x265 not found using pkg-config [14:06:02 CET] <cesdo> Can you help? [14:06:59 CET] <cesdo> I did instructions from https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [14:26:22 CET] <ubitux> look at your config.log [14:51:43 CET] <cesdo> ubitux: config.log is very large [14:52:02 CET] <ubitux> look at the end [14:52:12 CET] <ubitux> or look for x265 [14:55:17 CET] <cesdo> ubitux: http://pastebin.com/bNCqZL96 [14:56:06 CET] <ubitux> your x265 install says you need -lnuma [14:56:36 CET] <ubitux> pkg-config --libs x265 [14:58:55 CET] <cesdo> ubitux: -lx265 [15:00:00 CET] <ubitux> pkg-config --static --libs x265 [15:00:46 CET] <cesdo> ubitux: -lx265 -lstdc++ -lm -lrt -ldl -lnuma [15:01:04 CET] <ubitux> here you go [15:01:13 CET] <ubitux> the installed .pc of your x264 wants numa [15:01:27 CET] <ubitux> so you built it with numa but don't have it [15:01:37 CET] <ubitux> that's a problem with your x265 install [15:01:47 CET] <ubitux> (i meants x265, not x264) [15:01:55 CET] <cesdo> Ahh [15:02:20 CET] <cesdo> I should compile it youself [15:03:03 CET] <cesdo> ubitux: am I right? [15:03:17 CET] <ubitux> i don't know [15:04:07 CET] <cesdo> ubitux: ? I mean compilling x265 [15:05:12 CET] <ubitux> i don't know, i never built x265, i don't know its dependencies nor what you want [15:05:26 CET] <ubitux> you probably have multiple solution, all i'm saying is that x265 wants to be linked against numa [15:09:19 CET] <BleuDiamant> Hello :) [15:11:13 CET] <BleuDiamant> i have a question about ffmpeg, i need to do this http://i.imgur.com/VaXCc9T.png ffmpeg can do that ? (for the 3 first step i have succeeded but for the last step ?) [15:11:20 CET] <cesdo> ubitux: what is .pc? [15:11:56 CET] <ubitux> Pkg-Config file [15:12:03 CET] <cesdo> aah [15:12:07 CET] <ubitux> installed by x265 [15:12:43 CET] <ubitux> BleuDiamant: scale=...,transpose=...,pad=... [15:13:27 CET] <alexpigment> BleuDiamant: that sort of successive filtering is not my strong suit, but I just wanted to point out a potential error in your drawing. Presumably you mean 1080x608, right? [15:14:03 CET] <BleuDiamant> yeah sorry i made a mistake >< [15:14:26 CET] <alexpigment> k, just making sense. @ubitux's plan makes sense to me [15:15:31 CET] <alexpigment> *just making sure, i mean [15:15:55 CET] <BleuDiamant> no problem :) [15:16:14 CET] <BleuDiamant> ok thank ubitux i look "pad" [15:18:02 CET] <cesdo> ubitux: Package libnuma-dev helps me)) It runs)) Thanks! [15:26:33 CET] <ffnopeg> hello! I'm trying to do something, which may not be a good idea after all, but having trouble setting the right ffmpeg flags. I have a .avi file with audio and video streams, I'd like to pipe the video stream (doing that without issues right now) and play the audio stream using ffmpeg [15:26:48 CET] <ffnopeg> is there some way to do that? [15:29:03 CET] <ffnopeg> running it as ffmpeg -re -i inputfile.avi -f image2pipe -, which sends the frames individually but ffmpeg also drops the audio [15:53:19 CET] <BleuDiamant> this perfect with "pad" thank @ubitux [16:01:41 CET] <DHE> fflogger: you can then put in more parameters to describe a second output "file" for the audio. if you can do "ffmpeg -re -i inputfile.avi <options>" to play the audio, you should be able to just append <options> to your video player [16:12:22 CET] <mcjack> I have still problems encoding the video, here is the full output when I run ffprobe on the output: https://github.com/filmstro/filmstro_ffmpeg/issues/3#issuecomment-288083162 [16:12:54 CET] <mcjack> [h264 @ 0x7fd37a808000] non-existing PPS 0 referenced [16:13:36 CET] <mcjack> seems like the pixel format doesn't make it into the file: (Video: h264 (avc1 / 0x31637661), none, 800x600, 410 kb/s): unspecified pixel format [16:13:59 CET] <mcjack> but I definitively set it, verified it via debugger [16:27:17 CET] <ffnopeg> DHE: I think was directed to me. Ah, just noticed I mixed two things and forgot that ffmpeg wasn't rendering the video stream either [16:33:23 CET] <momomo> is there a way to fake choppy hls output ? [17:13:33 CET] <mcjack> Ok, I mixed the decoding_encoding.c and muxing.c example. So setting "videoContext->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;" was bad& [17:14:03 CET] <mcjack> The error in ffprobe is gone, but still no image& [17:39:26 CET] <mcjack> Wrong again, not setting AV_CODEC_FLAG_GLOBAL_HEADER made the stream vanish, so no wonder no error message& [17:40:51 CET] <mcjack> Can somebody please have a look at the output format, anything suspicious here? [17:40:53 CET] <mcjack> Output #0, mp4, to '/Users/daniel/Documents/test/foot4.mp4': [17:40:53 CET] <mcjack> Stream #0:0: Video: h264, yuv420p(pc), 640x324 [SAR 1:1 DAR 160:81], q=2-31, 400 kb/s, 24k tbn [17:40:53 CET] <mcjack> Stream #0:1: Audio: aac, 48000 Hz, stereo, fltp, 64 kb/s [17:41:09 CET] <cybex_> hi all, based on a SU question. ffmpeg -i in_file.mp4 -ss 00:10:00 -t 00:10:30 -c copy out_file.mp4 should create a file of length 30s, starting at 10min and ending at 10min 30s. Is this correct? https://superuser.com/questions/140899/ffmpeg-splitting-mp4-with-same-quali… [17:42:34 CET] <cybex_> if so, something is wrong. Since I created a file which ends at 10min has (i.e. is 10min in length) and has roughly the same size as the aforementioned 30's file [17:43:51 CET] <ChocolateArmpits> cybex_, there are two commands that affect the end file length -t and -to. -t as you used defines the total length of the file, -to when used defines the end time. So in this case you should use -to [17:44:44 CET] <cybex_> ChocolateArmpits: Thank you for the clarification! [17:44:55 CET] <ChocolateArmpits> np [18:51:08 CET] <faLUCE> Hello. What does it happen if I use FF_PROFILE_H264_HIGH_422 for a YUV444 planar frame? I don't get any warning by libav, and I don't understand if I can combine them [18:59:06 CET] <phillipk> is there a way to run FFMPEG in a hidden state? I have "-loglevel quiet" but I still see a command window opening--maybe it's not FFMPEG but the script that's launching ffmpeg [19:02:17 CET] <JEEB> welcome to windows, console applications always open a visible console [19:03:59 CET] <phillipk> thanks--not the end of the world I suppose--though distracting when I test locally [19:03:59 CET] <vlt> phillipk: You could run it in a screen or tmux session. [19:27:00 CET] <ZeroWalker> is rtcp like rtp but uses tcp? [19:30:25 CET] <st-gourichon-fid> ZeroWalker no. [19:31:02 CET] <st-gourichon-fid> https://en.wikipedia.org/wiki/RTP_Control_Protocol Quality-of-service feedback from RTP receivers to senders. [19:31:06 CET] <blue_misfit> hey guys I'm consistently seeing h264 transcodes of prores sources missing the first couple frames of video when I compare them in Premiere [19:31:11 CET] <blue_misfit> is this a known issue ??? [19:31:21 CET] <kepstin> no, rtcp is a protocol run alongside rtp (usually on rtp port +1) which adds some signalling for things like packet loss/retransmits [19:38:10 CET] <ZeroWalker> ah [19:38:54 CET] <ZeroWalker> so, what should i use to send rtp (or something that does the same) with tcp?;o [19:39:31 CET] <kepstin> if you're using tcp, just use any standard container format that can be streamed [19:39:49 CET] <kepstin> mpeg-ts is common, you can even use matroska or something [19:40:37 CET] <DHE> mpeg-ts has high-ish overhead, but requires no seeking whatsoever for streaming or playback and is very well supported [19:53:57 CET] <blue_misfit> anyone seen this before (2 frames missing at the head of a prores-> h264 transcode)? [20:10:44 CET] <st-gourichon-fid> Hello. On Ubuntu 16.04, have compiled ffmpeg okay but cannot compile avplay. Have installed all dependencied per https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu . [20:11:27 CET] <st-gourichon-fid> includes, libs are generated. generated bin directory is empty. [20:11:30 CET] <c_14> you mean ffplay? [20:12:52 CET] <c_14> upload the contents of your config.log to a pastebin service [20:13:09 CET] <st-gourichon-fid> c_14, checking, thanks. [20:21:38 CET] <st-gourichon-fid> I'm surprised that https://trac.ffmpeg.org/wiki/CompilationGuide does not tell where to find source code. Public search engine tell https://git.ffmpeg.org/ffmpeg.git but not wiki. [20:26:04 CET] <c_14> https://ffmpeg.org/download.html [20:32:01 CET] <st-gourichon-fid> c_14, ah, there's actually something with the configure options. [20:33:08 CET] <st-gourichon-fid> bisecting... [20:34:51 CET] <st-gourichon-fid> "--disable-avfilter" prevents build of "ffplay". [20:38:00 CET] <kepstin> disabling avfilter prevents building lots of stuff. kind of important library. [20:39:42 CET] <st-gourichon-fid> --disable-avresample also is enough to kill ffplay [20:41:04 CET] <kepstin> if you want to save some time, just read the deps in the configure script: https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3200 [20:42:07 CET] <st-gourichon-fid> kepstin, thanks! [20:42:45 CET] <st-gourichon-fid> kepstin, these seem to be direct dependencies, not transitive. [20:43:14 CET] <st-gourichon-fid> Anyway enabling avdevice, avfilter and eavresample seems enoguh to get ffplay back. Thanks. [20:43:35 CET] <kepstin> st-gourichon-fid: as long as you don't disable those libraries, the configure script uses "select" to pull in the remaining required features [20:43:59 CET] <kepstin> (which is mostly just a few builtin video filters) [20:44:40 CET] <kepstin> but yeah, it's not transitive, so you'll need avutil as well (*everything* needs avutil tho) [20:46:22 CET] <kepstin> (I assume the configure script doesn't even let you turn off avutil, since "--disable-avutil" would mean "don't build anything at all") [20:46:25 CET] <st-gourichon-fid> Which kind of "select" is that? [20:46:43 CET] <st-gourichon-fid> grep returns zillions of occurrences. :-) [20:47:35 CET] <kepstin> st-gourichon-fid: I'm referring to the magic variables in the configure script with names ending in _select [20:48:08 CET] <Alex______> Anyone available for a question? [20:48:19 CET] <kepstin> st-gourichon-fid: if you enable something in configure, the script also enables everything in the something_select variable [20:48:52 CET] <kepstin> Alex______: if you don't ask the question, you definitely won't get an answer ;) [20:49:31 CET] <Alex______> Is it possible to use ffmpeg to stream out an already recorded video? Like if i have a .mp4 video on my desktop, can i stream it out to http:192.168.0.150:9005/myVideo.mp4 or something like that? [20:49:41 CET] <st-gourichon-fid> Alex______, sure [20:50:11 CET] <st-gourichon-fid> I mean, I streamed video using ffmpeg, but via RTP not http. [20:50:46 CET] <kepstin> Alex______: the ffmpeg tool isn't designed to run as a streaming server, but it can be used to send a file to an external streaming server [20:50:53 CET] <Alex______> We currently are able to grab live frames from a UV4L stream via raspberry pi on html, but we want to also be able to stream out a recorded video [20:51:01 CET] <kepstin> there's some limited stuff you can do if you know you're only gonna have one client. [20:51:22 CET] <Alex______> There would be a maximum of 2 clients accessing a recorded video at one time [20:51:44 CET] <kepstin> alright, you'll want an actual streaming server then :/ [20:52:02 CET] <klaxa> the way ffmpeg (the binary) "streams" over http is like a webserver [20:52:16 CET] <st-gourichon-fid> Are your client close to the server (say, local network) or far on the internet ? [20:52:19 CET] <klaxa> and like kepstin said, one client (output) only :( [20:52:26 CET] <Alex______> Everything is local network [20:52:44 CET] <Alex______> How would I go about doing it for one client? [20:53:05 CET] <kepstin> alexpigment: simplest way to stream to multiple clients - if you're ok with HLS segmented streaming, you can have ffmpeg generate the stream files to be served with a small webserver like nginx [20:53:05 CET] <st-gourichon-fid> kepstin, klaxa, would you consider multicast RTP an option? [20:53:22 CET] <st-gourichon-fid> On local network. [20:53:37 CET] <klaxa> ffmpeg -i file.mp4 -c copy -listen 1 -f mp4 http://0.0.0.0:8080 ? [20:53:46 CET] <klaxa> not sure if -f mp4 is "streamable" [20:54:09 CET] <klaxa> dunno, never really used rtp [20:54:13 CET] <kepstin> no, mp4 is not streamable [20:55:30 CET] <st-gourichon-fid> I would consider a mp4 file not adapted for a live video stream. [20:55:59 CET] <Alex______> What about .avi? [20:56:03 CET] <st-gourichon-fid> AAAh [20:56:27 CET] <st-gourichon-fid> Ah, you meant recorded video also. Should both clients be allowed to stream the recorded video at any time and pause etc? [20:57:11 CET] <klaxa> if your clients are reasonably recent you could use matroska [20:57:25 CET] <kepstin> Alex______: mkv would probably work, mepg-ts should work with more stuff but is less cool. [20:58:26 CET] <Alex______> So we have a backend server, where the recorded files would be stored. We want to try and also allow these recorded videos to be streamed out, if a user missed what was being broadcasted earlier [20:59:17 CET] <kepstin> Alex______: ok, so what you need it to run an actual streaming server application on your backend server which e.g. accepts rtmp streams or something. Then you can use ffmpeg on the rpi systems to send video to that server, and have it handle the rest [20:59:52 CET] <Alex______> What type of streaming server would you reccomend? Sorry for all the questions, quite new to this [21:00:02 CET] <furq> nginx-rtmp is good [21:00:21 CET] <kepstin> Alex______: to be honest, you might consider just streaming to twitch or youtube or something, they already have this set up ;) [22:49:41 CET] <ZeroWalker> but if i stream tcp, with say flv, it will fail on "avio_open" or what it's called. I think it's cause it's waiting for the tcp establishing, but i don't know how to listen for the tcp in say, a media player [22:57:32 CET] <blue_misfit> anyone know why an old build (2.8 era) would output a different number of frames than a newer build when transcoding ProRes MOVs at 23.976fps into H.264 in MP4? [22:58:43 CET] <durandal_1707> editlist [22:59:11 CET] <durandal_1707> try adding -ignore_editlist 1 [23:03:16 CET] <blue_misfit> durandal_1707, thank you!!! [23:03:25 CET] <blue_misfit> what's the story with these? how can I tell if my MOVs have edit lists? [23:28:33 CET] <alexpigment> blue_misfit - i don't know if ProRes works the same as an MPEG-4 based MOV file, but if you view the file with MediaInfo, usually it'll have a 3rd stream called "Quicktime Time Code" [23:28:57 CET] <alexpigment> was just dealing with a similar issue today, actually [23:28:57 CET] <blue_misfit> for sure [23:29:48 CET] <blue_misfit> yeah my sources always have that [23:30:10 CET] <alexpigment> interesting [23:30:19 CET] <blue_misfit> ProRes feature masters from studios :) [23:30:23 CET] <alexpigment> i don't work with ProRes enough to know that it's always there, but i'll take your word for it [23:30:29 CET] <blue_misfit> generally exported from an NLE [23:30:35 CET] <blue_misfit> quite common [23:31:11 CET] <blue_misfit> have you tried this ignore_editlist thing? [23:32:45 CET] <alexpigment> yeah, i mean i've worked with ProRes from Adobe Premiere, but generally, i'm moving something TO Premiere for exporting to a delivery format, so it's just not common for my workflow. anyway, no i haven't used the ignore_editlist feature. it's cool to know it exists though [00:00:00 CET] --- Wed Mar 22 2017

1 0