Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2016

1 participants
58 discussions

ffmpeg-devel.log.20160218
by burek 19 Feb '16

19 Feb '16

[00:36:40 CET] <ethe> ubitux: I think this should work now. I can't test it on anything else other than OSX though https://gist.github.com/anonymous/ce6da631796cbaff69a7 [01:47:53 CET] <cone-478> ffmpeg 03Michael Niedermayer 07master:5590ab45e0b1: ffmpeg: Check best_effort_timestamp after rescale [10:28:06 CET] <JEEB> hmm [10:28:15 CET] <JEEB> did we have a feature for pushing a single mux into multiple outputs? [10:28:44 CET] <durandal_170> tee muxer? [10:30:24 CET] <JEEB> oh wow [10:30:26 CET] <JEEB> cheers [10:31:20 CET] <JEEB> I had somehow completely missed that one [11:00:52 CET] <ubitux> i'm looking at the png dsp; it seems src and dst buffers are padded, so why is add_bytes doing overwrite checks? [11:32:46 CET] <durandal_170> nobody tried loop filters? [11:34:01 CET] <durandal_170> michaelni: have you sent gsoc request? [11:37:36 CET] Action: wm4 stares at 30 mails saying "probably ok" on libav-devel [11:37:39 CET] <wm4> quite literally [11:38:39 CET] <durandal_1707> carl was right :P [11:41:13 CET] <durandal_1707> the codecpar patches are benign [11:45:15 CET] <iive> the 269 patches? [11:45:50 CET] <durandal_170> so many demuxers [11:47:27 CET] <michaelni> durandal_1707, yes i sent the gsoc req, carl and reynaldo then did fill out the new fields in the forms/questions [12:09:28 CET] <ubitux> damn, i must say the neon set on aarch64 is quite nice. [12:10:09 CET] <durandal_170> really? How fast it can get? [12:12:50 CET] <cone-349> ffmpeg 03Paul B Mahol 07master:08acab85d342: avfilter: add loop filters [12:15:29 CET] <durandal_1707> 27 to go [12:17:03 CET] <durandal_1707> *filters to reach 300th one [12:22:51 CET] <ubitux> durandal_1707: no idea, i can't bench :D [12:22:57 CET] <ubitux> but the instruction set is really nice [12:23:16 CET] <ubitux> i get asm smaller that C equivalent [12:27:09 CET] <durandal_170> really wants motion estimation filter [13:36:23 CET] <cone-349> ffmpeg 03Thomas Mundt 07master:da94d619f641: avfilter: add BobWeaver deinterlacing filter [14:42:36 CET] <cone-349> ffmpeg 03Michael Niedermayer 07master:090b673aba21: avformat: add ff_reshuffle_raw_rgb() [14:42:37 CET] <cone-349> ffmpeg 03Michael Niedermayer 07master:07c7e71d20f7: avformat/avienc: Split avi_write_packet_internal() out [14:46:49 CET] <ethe> ubitux did you see my updated patch? [14:47:32 CET] <ubitux> + ( check_func sem_timedwait || check_header dispatch/dispatch.h ) && [14:47:41 CET] <ubitux> since you have them in lists [14:47:56 CET] <ubitux> you can probably instead do enabled sem_timedwait || enabled dispatch_dispatch_h [14:52:52 CET] <wm4> lol everyone is reporting breakages over that libav configure change (apparently) [14:54:45 CET] <ubitux> yeah well, it's really broken [14:55:19 CET] <ubitux> they still haven't send a revert patch? [14:55:32 CET] <J_Darnley> Has the spaghetti finally become too knotted to pick apart? [14:55:32 CET] <ubitux> we should probably revert ourselves [14:55:53 CET] <wm4> J_Darnley: no, someone added something to the spaghetti without knowing what he was doing [14:56:08 CET] <wm4> the latter is _very_ easy with this insane 7kloc sh script we have [14:56:23 CET] <J_Darnley> Could be worse. Could be autotools [15:00:53 CET] <atomnuker> m4 is a tool of satan [15:02:40 CET] <RiCON> wonder why no one made a PR in GitHub to Cmake-fy FFmpeg yet [15:02:54 CET] <wm4> maybe it was too hard [15:03:29 CET] <durandal_170> atomnuker: look at ffmpeg -codecs output [15:05:19 CET] <fritsch> kodi is going cmake [15:05:23 CET] <fritsch> on all platforms currently [15:05:35 CET] <wm4> I'm so sorry [15:05:49 CET] <fritsch> yeah - most people that don't understand cmake - tells that :-) [15:06:05 CET] <nevcairiel> cmake isnt any better than other build systems [15:06:13 CET] <wm4> cmake is just ridiculously bad in all aspects [15:06:24 CET] <wm4> I had my own share of fun with it [15:06:32 CET] <wm4> (I'd prefer ffmpeg's build system any time) [15:06:46 CET] <J_Darnley> Uh oh. I'm starting to feel like I should never have said anything. [15:06:48 CET] <nevcairiel> I like simple projects that have nothing but a makefile [15:07:38 CET] <durandal_170> we should not have configure, user should manually build [15:08:12 CET] <atomnuker> durandal_170: what's wrong with ffmpeg -codecs? [15:08:51 CET] <durandal_170> count how many times it writes DEVILS [15:09:20 CET] Action: J_Darnley guesses six hundred and sixty-six [15:10:07 CET] <wm4> only 3 times here [15:10:24 CET] <ubitux> BBB: aarch64 is really simple, you'll probably like it [15:10:31 CET] <ubitux> i miss the macro fun though [15:10:40 CET] <ubitux> the gas pp is too limited :( [15:10:45 CET] <BBB> hm... [15:10:49 CET] <BBB> maybe we need a new meta language [15:10:58 CET] <nevcairiel> "C"? [15:10:58 CET] <nevcairiel> :D [15:11:01 CET] <durandal_170> lavfi [15:11:24 CET] <ubitux> BBB: but honestly, the assembler is really straightforward, and a pleasure to deal with wrt bytes [15:11:28 CET] <ubitux> contrary to x86 [15:11:29 CET] <wm4> how about a sh script that generates asm (this would be so deliciously evil) [15:11:38 CET] <nevcairiel> whats wrong with javascript [15:11:48 CET] <fritsch> php +1 [15:11:59 CET] <ubitux> BBB: also, no need for all the instruct set ifdefery [15:12:04 CET] <ubitux> so code is way cleaner [15:12:06 CET] <JEEB> nevcairiel: sounds like boost's build system [15:12:09 CET] <JEEB> or was it c++? [15:12:14 CET] <JEEB> it builds the build system first [15:12:18 CET] <ubitux> the only thing i miss is some good doc [15:12:19 CET] <JEEB> then builds boost [15:12:21 CET] <ubitux> damn that doc is shit.. [15:12:27 CET] <nevcairiel> yeah boost has its own binary build thing [15:12:28 CET] <BBB> real men write assembler [15:12:30 CET] <BBB> that outputs assembler [15:12:35 CET] <BBB> so ... [15:12:36 CET] <nevcairiel> i never looked into how it works [15:12:36 CET] <BBB> anyway [15:12:37 CET] <BBB> :D [15:12:42 CET] <ubitux> :) [15:12:42 CET] <nevcairiel> but it just worked when i needed to build boost [15:12:44 CET] <BBB> ubitux: ok that sounds pretty cool [15:13:36 CET] <ubitux> BBB: png add bytes (no boundary checks): http://pastie.org/pastes/10727437/text [15:14:14 CET] <BBB> how about vp9 loopfilter? :-p [15:14:23 CET] <atomnuker> DEVILS jpeg2000 DEVILS jpegls DEVILS webp [15:14:27 CET] <atomnuker> I KNEW IT [15:14:29 CET] <ubitux> BBB: probably prettier ;) [15:14:35 CET] <BBB> also, from what I recall, libvpx has all arm64 code in intrinsics [15:14:43 CET] <BBB> and so does libav [15:14:45 CET] <atomnuker> proof that jpeg2000 and webp are spawns of satan himself! [15:14:49 CET] <BBB> so & thats not necessary? [15:15:06 CET] <wbs> BBB: no, libav has got separate arm and aarch64 asm [15:15:17 CET] <wbs> BBB: there's only one small snippet that somebody from linaro contributed that is in intrinsics [15:15:23 CET] <BBB> oh, ok, interesting [15:15:29 CET] <BBB> so why does libvpx have intrinsics then [15:15:29 CET] <ubitux> BBB: 32 simd reg, no need for intrinsic [15:15:31 CET] <BBB> blegh [15:15:31 CET] <ubitux> :D [15:15:37 CET] <BBB> 32 reg& omg [15:15:44 CET] <BBB> you can almost write a stack-free idct32x32 [15:16:01 CET] <nevcairiel> avx512 extends all xmm/ymm to 32 as well :D [15:18:15 CET] <jamrial> but that's simd registers. aarch64 also has 32 gprs [15:18:26 CET] <durandal_1707> ubitux: how is division handled? [15:19:40 CET] <ubitux> only float in simd afaict [15:41:36 CET] <ubitux> cmge v0.16B,v1.16B,v2.16B OK [15:41:52 CET] <ubitux> cmle v0.16B,v1.16B,v2.16B NOT OK [15:41:56 CET] <ubitux> Error: operand 1 should be a SIMD scalar register -- `cmle v0.16B,v1.16B,v2.16B' [15:42:04 CET] <ubitux> the doc even says cmle is an alias for cmge :( [15:44:47 CET] <ubitux> similarly cmgt works, cmlt doesn't [15:46:28 CET] <ubitux> sadness. [15:56:51 CET] <ubitux> http://infocenter.arm.com/help/topic/com.arm.doc.dui0802a/UZP1_advsimd_vect… useful doc is useful [15:57:02 CET] <ubitux> "uzp" = "unzip" thx [16:18:47 CET] <ethe> ubitux: this should do it https://gist.github.com/anonymous/4c96f7d6d1777793bdd4 [16:20:42 CET] <ubitux> ok but now the jack indev is enabled gets enabled even when sem_timedwait and dispatch_dispatch_h are unavailable [16:21:33 CET] <BBB> michaelni: Id just revert immediately [16:24:05 CET] <durandal_1707> reverting merges, what if one try to merge other changes? [16:29:34 CET] <cone-349> ffmpeg 03Moritz Barsnick 07master:6eaad752c1c6: lavf/options_table: mark use_wallclock_as_timestamps as boolean [16:29:35 CET] <cone-349> ffmpeg 03Michael Niedermayer 07master:8fdee3ee8fb5: Revert 4 commits to configure which broke dependency handling [16:29:57 CET] <michaelni> durandal_1707, same as if the merges had been "skiped" [16:39:29 CET] <ethe> ubitux right. yeah idek then [16:40:52 CET] <ubitux> ethe: || disable jack at the end maybe [16:41:01 CET] <ubitux> or a smarter dep [16:42:29 CET] <ethe> I have no idea, I've never done anything with FFmpeg before, and the configure script isn't exactly that straight-forward [16:43:02 CET] <ethe> ohwait, I think I see what you mean [16:51:08 CET] <wm4> ethe: oh that looks nice, I didn't know there was such a simple mapping from the dispatch stuff to posix semaphores [16:53:09 CET] <ubitux> not sure anyone if anyone will know that, but any idea how to get v0=ABCDEFGHIJKLMNOP from v1=AABBCCDDEEFFGGHH and v2=IIJJKKLLMMNNOOPP in neon? [16:53:10 CET] <ethe> It works pretty nicely, I'm not sure if ffmpeg uses posix semaphores in other places, but GCD is probably the way to go for operating systems that have it (I'm pretty sure it's OSX & FreeBSD but I'm still trying to confirm that FreeBSD uses it) [16:53:36 CET] <ubitux> (AA, BB, CC, ... are 0x0000 or 0xffff) [16:53:53 CET] <wm4> surely fbsd actually supports posix [16:54:09 CET] <ubitux> it seems i can somehow do that in 3 instr. but that sucks [16:58:13 CET] <ethe> wm4: It does, but GCD is supposedly faster, but if posix works, there's no real reason to change them. [17:06:52 CET] <nevcairiel> whoever invented nested SEI messages in h264 deserves a special kind of hell [17:11:50 CET] <kierank> nevcairiel: which message is nested? [17:12:01 CET] <kierank> or you mean the one where they write a single NAL with multiple SEIs? [17:12:17 CET] <nevcairiel> no, they have SEI messags that can contain a new SEI inside of it [17:12:30 CET] <kierank> hevc? [17:12:34 CET] <nevcairiel> h264 [17:13:08 CET] <kierank> which sei si that [17:13:31 CET] <nevcairiel> apparently only used in annex g and annex h, ie. scalable and multiview [17:13:58 CET] <nevcairiel> why they didnt just code multiple SEIs is beyond me [18:50:44 CET] <ethe> why does using "-hide_banner" make it an invalid ticket? [18:51:30 CET] <nevcairiel> because it hides the version and compile options [20:01:08 CET] <wm4> "merge of ffmpeg and ffplay" [20:01:30 CET] <wm4> "SVG decoder" [20:03:07 CET] <JEEB> sounds real good yo [20:03:34 CET] <jamrial> he did say the former was probably naive [20:23:52 CET] <kurosu_> and even if not, there's no harm in asking, he's candidating for gsoc [21:01:10 CET] <wm4> so uh [21:01:14 CET] <wm4> what can we give them to do [21:01:20 CET] <wm4> surely there are good ideas around [21:01:52 CET] <durandal11707> libavdevice API [21:02:58 CET] <BtbN> merges [21:03:15 CET] <durandal11707> let they do merges :) [21:08:05 CET] <kurosu_> is there anything in what he listed that is not yet exported, but would be useful to export eg as metadata? From what I understand, it seems a core topic in his proposals [21:14:13 CET] <durandal11707> kurosu_: only stuff then get printed at end of processing [21:18:59 CET] <durandal11707> imho rdft/fft should be moved to lavu [21:20:05 CET] <durandal11707> why vp9 encoder doesn't set supported pix fmts? [21:28:20 CET] <JEEB> hmm [21:28:21 CET] <JEEB> https://github.com/FFmpeg/FFmpeg/blame/master/libavfilter/vf_zscale.c#L545 [21:28:24 CET] <JEEB> so this has always been here [21:28:56 CET] <JEEB> yet I distinctly remember that I didn't get the BT.709 flag set when encoding with libx264 [21:29:06 CET] Action: JEEB scratches head [21:32:13 CET] <durandal11707> JEEB: default is whatever input have [21:32:30 CET] <JEEB> yes, I can see the code [21:32:56 CET] <JEEB> I just distinctly remember not getting it through but this forces me to think about retrying just to make sure I wasn't dreaming [21:33:33 CET] <cone-349> ffmpeg 03Michael Niedermayer 07master:9dd4dcde9cde: avformat/avienc: Use avi_write_packet_internal() to store raw rgb in a more spec compliant way [21:44:42 CET] <ethe> I really don't how the configure part could be wrong now, so if it is, I'd be grateful if someone explained why it's wrong https://gist.github.com/507fc57c9f934c1b64a3 (Patch for issue #43) [21:45:01 CET] <durandal11707> michaelni: why colorspace,range,transfer,primaries are not stored if ffv1? [21:46:00 CET] <JEEB> nobody thought of it I guess? [21:46:45 CET] <JEEB> ethe: that seems to have a lot of... unrelated changes in it? [21:46:56 CET] <ethe> ohwait [21:47:03 CET] <ethe> yeah something broke [21:47:29 CET] <ethe> https://gist.github.com/28e1408a13444f1dbaf4 <-- there we go [21:47:41 CET] <ethe> apparently I didn't change the commit I was diffing from [21:50:16 CET] <michaelni> durandal11707, the idea was that its stored in the codec layer. But it surely could be added to cover the cases like rawvideo ... [21:51:30 CET] Action: michaelni mixed nut up with ffv1, lets see where i put my brain [21:52:07 CET] <durandal11707> michaelni: adding it to nut wouldn't hurt but it's tricky [21:55:19 CET] <cehoyos> ethe: Did you test jack with the resulting binary? [21:57:00 CET] <michaelni> it could be added to ffv1, or not or both. Storing ffv1 in mpeg-ps would need it in ffv1, storing rawvideo in nut would need it in nut [22:02:10 CET] <durandal11707> ffmpeg -h full output have 8k lines [22:02:46 CET] <JEEB> I think nowadays since I always have a browser open I just write ffmpeg-all into my url bar [22:02:52 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html [22:06:12 CET] <ethe> cehoyos: yes, it works. [22:13:17 CET] <cehoyos> ethe: Could you post console output to the ticket? I wonder why it didn't work for me... [22:23:44 CET] <cehoyos> ethe: Thank you! Please send your patch made with "git format-patch" to the development mailing list [22:24:16 CET] <wm4_> cehoyos: you never send git format-patches to the ML [22:24:45 CET] <JEEB> well, their content, no? [22:24:52 CET] <JEEB> like what git send-email does [22:25:19 CET] <JEEB> I'm taking the freedom of thinking that he meant that instead of attaching things as attachments [22:25:28 CET] <JEEB> although lately that seems to be accepted as well [22:34:38 CET] <JEEB> cehoyos: seems like this poor soul doesn't have a mail provider that lets him send out plain text e-mails [22:34:44 CET] <nevcairiel> as long as its actually a git format-patch thing its generally OK [22:35:00 CET] <JEEB> and I don't have send-email set up in this thing so welp [22:35:03 CET] <nevcairiel> but just pasting diffs without author info etc are annoying [22:35:11 CET] <JEEB> yeah [22:36:07 CET] <TD-Linux> durandal11707, JEEB, ffv1 v4 on the CELLAR mailing list is adding them [22:36:23 CET] <JEEB> nice [22:47:01 CET] <durandal_1707> TD-Linux: link? [22:48:43 CET] <TD-Linux> durandal_1707, https://mailarchive.ietf.org/arch/search/?email_list=cellar [22:49:01 CET] <TD-Linux> apologies for the horrific archive viewer [22:53:48 CET] <nevcairiel> and i thought pipermail is terrible [22:53:53 CET] <nevcairiel> this one doesnt even have threads [00:00:00 CET] --- Fri Feb 19 2016

1 0

ffmpeg.log.20160218
by burek 19 Feb '16

19 Feb '16

[00:07:55 CET] <CoJaBo> Is there a faster way to speed up a video than this? https://trac.ffmpeg.org/wiki/How%20to%20speed%20up%20/%20slow%20down%20a%20… [00:11:08 CET] <EmleyMoor> DHE/kepstin: Thanks, between you I got it. [00:23:09 CET] <CoJaBo> I think what I want to do is like, copy ONLY keyframes or something; is that possible? [00:38:25 CET] <CoJaBo> ..ok, is there a problem with the above method and "-i concat:" ? [00:43:58 CET] <Wader8> how do you mean faster way to speed up ? [00:44:43 CET] <CoJaBo> Wader8: It takes about 10 seconds per frame [00:45:24 CET] <CoJaBo> A more significant problem is that it ignores the concat: input, and ONLY reads the very first file [00:51:27 CET] <CoJaBo> Is there a way to fix that? [00:51:44 CET] <pzich> what is the exact concat command you're running? [00:51:46 CET] <pzich> better yet... [00:52:13 CET] <pzich> and are your input files the same resolution/framerate/codec etc.? [00:52:50 CET] <CoJaBo> They're all the same [00:52:52 CET] <CoJaBo> "setpts=(STARTPTS+PTS)/60" [00:53:10 CET] <CoJaBo> And I'm using -i concat:file1.mp4|file2.mp4|... [00:53:17 CET] <CoJaBo> The output stops after file1 [00:55:26 CET] <pzich> Have you tried using a concat file, like https://trac.ffmpeg.org/wiki/Concatenate#demuxer ? [00:56:03 CET] <furq> yeah you can't use the concat protocol for mp4 [00:56:09 CET] <furq> use the demuxer [00:56:41 CET] <CoJaBo> "Unknown input format: 'concat'" [00:57:02 CET] <furq> which ffmpeg version [00:57:10 CET] <furq> i'm guessing it predates 1.1 [00:57:35 CET] <CoJaBo> The fricking ubuntu version avconv version 9.18-6:9.18-0ubuntu0.14.04.1, Copyright (c) 2000-2014 the Libav developers [00:57:49 CET] <furq> that's not even ffmpeg [00:59:17 CET] <furq> upgrade ubuntu or install ffmpeg from http://johnvansickle.com/ffmpeg/ [00:59:32 CET] <furq> or remux all your input files to a format which does work with the protocol, like ts [01:13:12 CET] <CoJaBo> furq: So, will -f concat work for sure if I can install the nonbuntufied ffmpeg? [01:14:21 CET] <pzich> definitely should, if it's the right version and installed correctly [01:15:12 CET] <CoJaBo> ..is there a build I can install from a site that isn't plain http? [01:17:16 CET] <pzich> you could install it for real instead of downloading a static build [01:18:41 CET] <CoJaBo> Ubuntu package manager doesn't actually have it tho [01:20:01 CET] <pzich> yup, will have to find a solution for that. Google is good at that: https://www.google.com/search?q=ubuntu+install+ffmpeg [01:21:31 CET] <CoJaBo> pzich: The PPA also broke everything [01:21:44 CET] <CoJaBo> PPAs in ubuntu are.. not very reliable :/ [01:21:50 CET] <furq> yeah short of upgrading ubuntu or compiling it yourself, that's your only option [01:21:59 CET] <pzich> so pick your poison ;) [01:22:13 CET] <furq> i would just upgrade ubuntu but i appreciate that some people sadly have reasons to use an LTS release [01:23:33 CET] <furq> obviously PPAs are also technically an option but i excluded those because why would you want to ruin ubuntu even more [01:24:52 CET] <CoJaBo> lol [01:25:18 CET] <furq> i guess installing debian in a chroot is also an option [01:25:33 CET] <pzich> oh jeez [01:25:34 CET] <furq> or like i said just remuxing your input files to ts [01:25:53 CET] <furq> assuming you only need to do this once that's going to be easiest [01:27:52 CET] <CoJaBo> I'm going to want to make these regularly; also the files are a few tens of GB, each [01:28:44 CET] <CoJaBo> My last attempt at installing a PPA managed to toast even the /home directory >_> [01:29:22 CET] <lufi> hi, are the rhel packages provided in rpmfusion repo includes qt-faststart already? or should I follow the tutorials I see online (manually compiling it in tools dir) [01:33:42 CET] <CoJaBo> furq: ..ok, so I managed to get a recent verison running on a different machine, but ussing -f concat just appears to... freeze [01:33:51 CET] <CoJaBo> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x4bc78e0] Auto-inserting h264_mp4toannexb bitstream filter [01:38:09 CET] <CoJaBo> ..ok, maybe it is going, but it's kinda slow [01:38:47 CET] <CoJaBo> it just got to frame #3 [01:40:04 CET] <furq> pastebin the command [01:40:22 CET] <CoJaBo> pzich: Ok, so it will no doubt be hours till that finishes; but assuming it works, is there a way to speed up doing a timelapse video? E.g., something like making it decode only keyframes? [01:41:08 CET] <furq> no seriously pastebin the command [01:41:12 CET] <furq> there's no way it should be that slow [01:42:50 CET] <CoJaBo> ffmpeg -f concat -i ~/tmp.txt -an -r ntsc -filter:v "setpts=PTS/60" -codec:v libx264 -preset placebo -qp 0 ~/output5.mkv [01:43:08 CET] <furq> why are you transcoding [01:43:39 CET] <CoJaBo> ..I don't think it can speed up without doing so, can it? [01:43:59 CET] <furq> you can change framerate without reencoding [01:44:24 CET] <CoJaBo> I need to actually drop frames tho; lots of them [01:45:09 CET] <furq> oh [01:45:10 CET] <CoJaBo> I'm speeding it up by 240× [01:45:22 CET] <furq> well if you're reencoding then you can select only keyframes with -vf select [01:45:59 CET] <furq> -vf select=eq(pict_type\,I) [01:46:15 CET] <furq> also there is literally no reason to use -preset placebo [01:46:16 CET] <furq> hence the name [01:47:56 CET] <CoJaBo> I figured I might as well get that extra 0.007% compression if decompression is taking 99% of the time anyway lol [01:48:41 CET] <furq> placebo is something like an order of magnitude slower than veryslow for insignificant gains [01:50:11 CET] <CoJaBo> That's actually still a tiny fraction of the overall time lol; I actually changed it to veryfast when adding the -vf, in case that does go tons faster... [01:50:37 CET] <furq> i would have thought it would be much faster but i've not done much x264 lossless [01:50:43 CET] <CoJaBo> I think it's reading the entire input file at startup tho, because it's been stalled completely for a minute or 2 now [01:51:12 CET] <CoJaBo> I'm doing lossless mostly because I'm not sure the output will be fast enough (I may want to speed it up further) [01:56:23 CET] <CoJaBo> ..ok, i screwed something up [02:05:39 CET] <CoJaBo> ..ok, got it right that time, but it's only about 2-4× faster; filter command is -filter:v "select=eq(pict_type\,I),setpts=PTS/60" [02:06:18 CET] <CoJaBo> at least i hope its right <_< [02:18:09 CET] <CoJaBo> well, it didn't crash this time. With any luck, it'll be done by March [02:21:07 CET] <CoJaBo> furq: Seems to be going slowly, but surely; huge thanks =D [02:21:25 CET] <CoJaBo> (unless there's any way to make it even faster lol) [04:15:36 CET] <needmorespeed> What does this value mean? AVCodecContext.thread_type=3 [04:15:56 CET] <needmorespeed> avcodec.h says FF_THREAD_FRAME=1 and FF_THREAD_SLICE=2 [06:09:40 CET] <Abbott> what command would i use to change name001.bmp, name002.bmp,...,name089.bmp into a 30fps video [06:10:19 CET] <Abbott> I tried ffmpeg `ffmpeg name%d.bmp -vcodec mpeg4 output.mp4 [06:10:54 CET] <furq> -i name%03d.bmp [06:11:01 CET] <furq> also don't use mpeg4, use libx264 [06:13:29 CET] <klaxa> i think the default is 25 fps, so use ffmpeg -r 30 name%d.bmp [...] [06:13:37 CET] <klaxa> *+ -i [06:13:52 CET] <klaxa> so ffmpeg -r 30 -i name%d.bmp -c:v libx264 out.mkv [06:23:15 CET] <Abbott> that did it. I also muxed in audio with another -i flag and a -c:a flag. I am noticing that the video plays back slower than the original video i extracted the frames from (most likely because the original video has a variable framerate). I tried pumping up the framrate, but that doesn't seem to have an effect on how quickly the frames pass. Is there something I'm not doing right? [06:24:01 CET] <Abbott> This is the command I have: ffmpeg -i D:\Users\Abbott\Desktop\extractedmp4\name%03d.bmp -i D:\Users\Abbott\Desktop\snap.flac -c:v libx264 -r 60 -pix_fmt yuv420p -c:a aac -strict experimental out.mp4 [06:24:24 CET] <Abbott> i tried pumping it up to 60 but no change [06:25:27 CET] <Abbott> oh wait adding -framrate 40 at the beginning did it [06:25:34 CET] <Abbott> sorry I'm probably really frustrating to deal with lol [06:35:11 CET] <klaxa> heh, it's ok, you found your mistake on your own :) [10:02:22 CET] <cowai> Hi, is there anyone here that can answer this. Can ffmpeg apply one filter to all outputs but also have individual filters (like scale) on each output without using several commands/pipes ? [10:13:57 CET] <durandal_170> cowai: ffmpeg tool cannot do that afaik, but can be done with programming own tool [10:14:19 CET] <cowai> Thanks [10:14:45 CET] <cowai> I want to deinterlace with mcdeint first and then scale each output [10:15:05 CET] <cowai> doing a pipe is okay, but I want to have as little delay as possible. [10:27:09 CET] <durandal_170> cowai: actually it can be done [10:27:47 CET] <cowai> I would appreciate it if you could provide me with an example. [10:28:02 CET] <durandal_170> use split filter, and than scale on each output than use -map [10:58:07 CET] <cowai> durandal_170: Would it be possible for you to check this out and make the needed adjustments? [10:58:07 CET] <cowai> ffmpeg -i - -c:v rawvideo -filter:v "yadif=3:0,mcdeint=1:0,framestep=2" -f nut -|\ [10:58:07 CET] <cowai> ffmpeg -i - -c:a aac -b:a 128k -c:v libx264 -b:v 1M -filter:v "scale=640x480" -f flv rtmp://127.0.0.1/level1 -c:a aac -b:a 64k -c:v libx264 -b:v 1M -filter:v "scale=320x240" -f flv rtmp://127.0.0.1/level2 [10:58:46 CET] <cowai> piped into the first command is a rawvideo nut output from bmdtools [11:06:27 CET] <durandal_1707> cowai: ffmpeg -i - -c:v rawvideo -lavfi "yadif=3:0,mcdeint=1:0,framestep=2,split=2[a][b],[a]scale=640x480[A],[b]scale=320x240[B]" -map '[A]' -f flv rtmp:/.. -map '[B]' -f flv rtmp://.. [11:07:29 CET] <cowai> Thanks ! [12:06:10 CET] <kudjomensah> Hello [12:08:29 CET] <durandal_170> hello [12:08:50 CET] <kudjomensah> Need some help compiling ffmpeg on ubuntu [12:09:18 CET] <durandal_170> use pastebin or similar [12:09:34 CET] <durandal_170> what's problem? [12:12:07 CET] <kudjomensah> followed all the steps without a problem [12:12:19 CET] <kudjomensah> till I got to libx265 [12:15:32 CET] <kudjomensah> I get "error: size_t does not name a type [12:15:32 CET] <kudjomensah> size_t framesize; [12:15:55 CET] <durandal_1707> what gcc version? [12:17:05 CET] <kudjomensah> 4:4.8.2 [12:25:39 CET] <durandal_170> kudjomensah: pastebin console output [12:51:04 CET] <cowai> is there any comparable alternative to mcdeint in ffmpeg? [12:51:29 CET] <cowai> with the same quality but faste [12:51:30 CET] <cowai> r [12:54:39 CET] <durandal_1707> cowai: there is nnedi, but its slow too [12:55:20 CET] <durandal_1707> and there is soon bwdif to combine yadif and w3fdif [12:55:57 CET] <cowai> interesting [12:56:42 CET] <pavel_> Hello, how I can launch rtsp stream with listening incoming connections? [12:56:50 CET] <pavel_> I try avformat_alloc_output_context2(&m_avOutputContext, NULL, "rtsp", "rtsp://127.0.0.1:30010/live.sdp"); [12:57:13 CET] <pavel_> maybe need some flag? [12:57:20 CET] <cowai> I have problems with plain yadif where important things like mouth/teeth and eyelids does not look good. yadif + mcedeint makes it much better, but with i7 I can barely keep up. [13:27:02 CET] <cowai> durandal_1707, in my test w3fdif was much much better quality then yadif [13:27:09 CET] <cowai> is that normal? [13:33:31 CET] <durandal_1707> cowai: there are cases where w3fdif have artefacts [13:33:43 CET] <durandal_1707> high motion stuff [13:33:56 CET] <durandal_1707> and static pixels [13:34:29 CET] <cowai> would I see it more in high motion scenes? [13:34:37 CET] <durandal_1707> bwdif should help here, i will push it soon to upstream [13:35:17 CET] <durandal_1707> cowai: where motion is really hight like moving trees just in front of you [13:36:05 CET] <cowai> our channel is mainly static talk shows though. [13:36:22 CET] <cowai> But thanks for the heads up, I will test with a high motion scene and check [13:36:39 CET] <cowai> I have yadif in production now, should I just wait for bwdiff? [13:36:44 CET] <cowai> *bwdif [13:37:14 CET] <cowai> how will the performance be with bwdif ? [13:37:15 CET] <durandal_1707> currently bwdif is 2 times slower than yadif because lack of SIMD [13:38:52 CET] <cowai> so about the same as w3fdif? [13:42:57 CET] <durandal_1707> w3fdif have SIMD [13:43:36 CET] <durandal_1707> and is actually faster than yadif=1 [13:44:10 CET] <J_Darnley> Is that double rate though? [13:44:45 CET] <durandal_1707> w3fdif doesnt have send frame mode [13:45:12 CET] <durandal_1707> so yes, double rate [13:46:50 CET] <cowai> Do I need to care about double rate in my case durandal_1707? [13:47:00 CET] <cowai> as long as I set the output rate? [13:47:18 CET] <durandal_1707> actually bwdif is not 2x slower than yadif, with broadcast sample i have it is 3.53 vs 4.94 realtime [13:48:04 CET] <cowai> nice [13:48:36 CET] <durandal_1707> cowai: if you are only interested in yadif=0 mode than w3fdif is still slower because it does more calculations [13:49:53 CET] <durandal_1707> bwdif have both modes, but its default is bwdif=1 compared to yadif which is yadif=0 [13:50:56 CET] <durandal_1707> so fetch latest ffmpeg, and compare bwdif=0 with yadif=0 [13:51:25 CET] <cowai> my input is 25fps, but what I need to output is 30fps. Could double rate actually help to make the motion more smooth, or would it be the same? [13:52:33 CET] <durandal_1707> fps filter just drop/duplicate frames, so it depends... [13:53:18 CET] <durandal_1707> i guess i hight motion scenes it could theoretically help [13:53:21 CET] <durandal_1707> *in [13:55:00 CET] <durandal_1707> cowai: what ffmpeg version you are using? [13:56:27 CET] <cowai> "7:3.0.0+git~trusty " from ppa:mc3man/trusty-media [13:57:02 CET] <cowai> I will try to build latest [13:57:04 CET] <durandal_1707> that version should have w3fdif simd [14:38:45 CET] <kudjomensah> http://pastebin.com/fdsNHXsK [14:39:57 CET] <J_Darnley> > error when building x265 [14:40:05 CET] <J_Darnley> What do you want us to do about it? [14:42:54 CET] <kudjomensah> sorry it took me so long [14:43:52 CET] <kudjomensah> want to know if I have to fix it before I continue [14:44:31 CET] <J_Darnley> You need to fix the problem before x265 will compile, yes [14:44:31 CET] <kudjomensah> Or I can ignore it [14:44:56 CET] <J_Darnley> Are you ultimately trying to build ffmpeg? [14:45:04 CET] <kudjomensah> yes [14:45:20 CET] <J_Darnley> x265 is an optional library you can enable [14:45:30 CET] <J_Darnley> if you don't need it, don't enable it. [14:46:01 CET] <kudjomensah> ok [14:48:12 CET] <kudjomensah> will let you know how it goes [14:48:17 CET] <kudjomensah> Thanks [14:53:59 CET] <oldcode> is it possible for swr_alloc_set_opts to fail if the input and output formats are the same? [14:58:08 CET] <oldcode> nevermind, the problem might be something else [14:59:20 CET] <oldcode> yeah, it was an int64 thing [15:05:38 CET] <cowai> I will try to build latest [15:05:48 CET] <cowai> oops [15:05:55 CET] <cowai> alt-tab fail [15:23:41 CET] <cowai> alright I have the latest git now. durandal_1707 [15:23:50 CET] <cowai> Is there any options I should feed bwdif? [15:24:03 CET] <cowai> my source is top field first [15:29:10 CET] <durandal_1707> cowai: only bwdif=0 if you want same mode as yadif default [15:29:39 CET] <cowai> what if I want to set the field order? [15:35:51 CET] <durandal_1707> cowai: ffmpeg -h filter=bwdif [15:36:07 CET] <durandal_1707> bwdif=parity=tff/bff/auto [15:36:07 CET] <cowai> ah :) [15:37:22 CET] <cowai> yeah, thanks [15:37:24 CET] <cowai> :) [15:37:39 CET] <cowai> when exactly do I want parity to be field? [15:37:54 CET] <cowai> is when I want to make 25i -> 50p ? [15:40:45 CET] <durandal_1707> cowai: yes [15:41:22 CET] <cowai> btw, bwdif looks very nice [15:41:37 CET] <durandal_1707> i mean mode, send_field, parity option is something else [15:41:40 CET] <cowai> and more "stable" overall in my test clips [15:42:07 CET] <cowai> ok [15:45:46 CET] <cowai> ah yeah, parity is field order, right. [15:45:57 CET] <cowai> I meant mode. [17:11:02 CET] <stu0> Hi all, I have a question about using pipes for input sources to ffmpeg. I'm writing encoded (h264 and aac) streams from an android app and writing to a pipe to which a CLI (arm) ffmpeg is listening, but ffmpeg is stalling on the first input. I've successfully streamed to youtube with this approach when i used a null audio src and encoded it to aac within ffmpeg, but with two pipes it doesn't seem happy. Is this approach possible in [17:11:09 CET] <stu0> if this is allowed... : http://stackoverflow.com/questions/35469445/how-can-i-run-command-line-ffmp… [17:12:13 CET] <stu0> My current theory is maybe I need to uncouple the different streams and start writing the video without audio until ffmpeg processes and starts looking for audio [17:42:29 CET] <mrph> is there an ffmpeg lib or a thirdparty lib which could be coupled with ffmpeg that would allow me to embed annotations into a video output? By annotations I mean lines and shapes drawn by a user as the video plays as well as pause and scrub annotations. [17:43:10 CET] <J_Darnley> Use subtitles? [17:43:58 CET] <mrph> those are just text though, I need to animate a line being drawn for example [17:44:08 CET] <J_Darnley> use ass subs then [17:44:24 CET] <J_Darnley> that'll draw various shapes [17:45:47 CET] <mrph> oh really? that would be awesome, do you have a link you can point me to with examples? [17:46:01 CET] <J_Darnley> No, not really [17:46:17 CET] <J_Darnley> Aegisub might have a decent tutorail [17:46:20 CET] <faLUCE> Hello, how can I create a video with animatedpicture.gif + audio.mp3 ? I tried : ffmpeg -i animatedpicture.gif -f image2 -i audio.mp3 out.avi, but the resulting video is not viewable. I use ffmpeg 2.4.3 [17:46:56 CET] <faLUCE> J_Darnley: ????? [17:46:59 CET] <mrph> alright. I'll see what I can find. what about simulating the user scrubbing. [17:47:09 CET] <J_Darnley> What is "not viewable"? [17:47:13 CET] <faLUCE> J_Darnley: I just pasted the exact command [17:47:14 CET] <J_Darnley> What player? [17:47:17 CET] <faLUCE> J_Darnley: vlc [17:47:24 CET] <J_Darnley> But nothing of the output [17:47:51 CET] <faLUCE> J_Darnley: the output of what? [17:48:05 CET] <J_Darnley> THE TEXT THAT FFMPEG PRINTS TO YOUR TERMINAL [17:48:32 CET] <bencoh> ouch [17:48:49 CET] <J_Darnley> mrph: what does "user scrubbing" mean? [17:48:52 CET] <drv> you shouldn't need to do '-f image2' [17:49:37 CET] <faLUCE> J_Darnley: http://pastie.org/10727631 [17:50:15 CET] <J_Darnley> ha ha drv is right. [17:50:28 CET] <J_Darnley> you are telling ffmpeg that audio.mp3 is an image file [17:50:50 CET] <J_Darnley> as for why vlc can't play that video stream, I don't know. blame vlc [17:51:05 CET] <mrph> J_Darnley: We have an app that listens for user interactions with a video and then saves that info so that we can replay the users actions. So is a user is scrubbing (doing frame-by-frame navigation) we want to record that and then generate a video which replays those actions. [17:51:25 CET] <mrph> if a user is scrubbing* [17:51:41 CET] <faLUCE> drv: J_Darnley: same result if I omit it. I can't hear audio and the image is too big (it is not resized according to the screen size) [17:52:11 CET] <J_Darnley> Of course you can't hear audio. There is no audio in the file. [17:52:41 CET] <J_Darnley> And a player controls how a video is shown. [17:52:44 CET] <drv> what does the ffmpeg output look like without -f image2? [17:53:01 CET] <drv> you could copy the mp3 audio directly into the avi so it doesn't get re-encoded, although that shouldn't make a difference [17:53:04 CET] <faLUCE> how can I add audio, J_Darnley? I used this command: ffmpeg -i animatedpicture.gif -f image2 -i audio.mp3 out.avi [17:53:23 CET] <J_Darnley> Try reading what we say. [17:53:39 CET] <J_Darnley> [Thu 17:50] <J_Darnley> you are telling ffmpeg that audio.mp3 is an image file [17:53:44 CET] <J_Darnley> [Thu 17:52] <drv> what does the ffmpeg output look like without -f image2? [17:53:46 CET] <faLUCE> J_Darnley: even if I remove -f image the result is the same [17:53:51 CET] <faLUCE> J_Darnley: as said before [17:54:06 CET] <J_Darnley> What? That ffmpeg thinks the mp3 file is another image? [17:54:22 CET] <faLUCE> J_Darnley: I don't know. [17:54:34 CET] <faLUCE> J_Darnley: I just don't hear audio [17:54:41 CET] <J_Darnley> mrph: save edit lists or soemthing? that doesn't sounds like a feature of any video format [17:55:26 CET] <J_Darnley> Some do support arbitrary data/metadata so you could abuse that [17:58:29 CET] <faLUCE> any idea? [18:02:57 CET] <mrph> J_Darnley: say you watch a video of an athlete doing some particular movement. You then scrub around the video and comment of different parts of their technique. You then want to share that with them on youtube or something but first a video of the scrubbing you did needs to be recreated. thats what I'm trying to produce...hope that made more sense [18:03:15 CET] <J_Darnley> A little [18:03:28 CET] <J_Darnley> I must say I know of no existing solution for that [18:04:00 CET] <J_Darnley> I mean obviously editors will store that somehow [18:06:14 CET] <J_Darnley> I guess they use a project file rather than trying to stick it into a video file as metadata [18:06:41 CET] <mrph> yeah I mean right now we do it via the player and a json file which has cues to move the playhead this way and that way but obviously that won't do much in the way of making that content shareable [18:08:09 CET] <J_Darnley> You could modify ffmpeg to read the json and follow the instructions in there to render the final file [18:08:39 CET] <J_Darnley> or have it store the json somewhere [18:08:50 CET] <J_Darnley> or extract the command and store those somewhere [18:09:00 CET] <mrph> essentially build a custom lib ? [18:09:03 CET] <J_Darnley> Yes. [18:09:18 CET] <J_Darnley> If no solution exists you will have to write it yourself [18:09:25 CET] <J_Darnley> But definitel ask others [18:09:30 CET] <J_Darnley> *definitely [18:09:53 CET] <J_Darnley> I don't try to follow all the horrors people do with video these days. [18:10:09 CET] <mrph> haha this me asking others [18:10:35 CET] <J_Darnley> I would suggest also emailing the ffmpeg-users list [18:11:11 CET] <J_Darnley> Be clear and ask if anyone knows of an exsting solution. [18:11:33 CET] <ChocolateArmpits> That sounds like it could be better done using screen capture [18:11:42 CET] <J_Darnley> It probably won't be available through ffmpeg [18:11:58 CET] <J_Darnley> but people might know of other software that does it [18:12:07 CET] <J_Darnley> Then all you have to do it adapt that to your needs. [18:12:13 CET] <techtopia> may i ask why you want spy on your users mrph :p [18:12:20 CET] <mrph> mmm but scaling wouldn't work well with screen capture I don;t think [18:12:33 CET] <mrph> we're not spying [18:12:43 CET] <mrph> checkout upmygame.com [18:12:55 CET] <mrph> #shameless [18:13:11 CET] <furq> i'm so glad that this has a picture of an actual sportsman [18:13:23 CET] <furq> for a minute there i was worried that this would be for ESPORTS [18:13:33 CET] <techtopia> looks nice :) [18:13:54 CET] <furq> but yeah that sounds like something that should be done on the player side [18:14:38 CET] <furq> oh never mind you already said that [18:15:28 CET] <mrph> thanks [18:15:39 CET] <mrph> yep. already doing int via the player [18:15:44 CET] <mrph> it* [18:19:01 CET] <mrph> thanks J_Darnley. Appreciate the help [18:31:35 CET] <theFam> oh boy isn't this slow [18:32:40 CET] <theFam> my ffmpeg converting has been going for 2 hours and so far 28% aka 43 seconds were finished [18:35:33 CET] <durandal_1707> theFam: what command? [18:47:38 CET] <theFam> durandal: [18:48:51 CET] <theFam> ffmpeg -i Comp\ 1.mp4 -c:v libx264 -preset veryslow -refs 3 -threads 2 -c:a copy Tristam\ -\ Once\ Again.mp4 [18:49:19 CET] <ChocolateArmpits> theFam: what is the video format ? [18:49:30 CET] <Mavrik> huh [18:49:35 CET] <Mavrik> Are you running that on a potato? [18:49:38 CET] <theFam> ChocolateArmpits: input is 1080p [18:49:47 CET] <furq> -threads 2? [18:49:54 CET] <theFam> h264 too [18:50:13 CET] <Mavrik> Aren't you the guy that's running ffmpeg without ASM or was that someone else? O.o [18:50:19 CET] <theFam> ignore the first 2 lines [18:50:20 CET] <furq> no that's someone else [18:50:24 CET] <theFam> r/qutebrowser.py", line 153 in main [18:50:26 CET] <theFam> File "/usr/bin/qutebrowser", line 9 in <module> [18:50:26 CET] <furq> i think this might be the guy with the atom [18:50:27 CET] <theFam> frame= 1533 fps=0.3 q=29.0 size= 7281kB time=00:00:51.09 bitrate=1167.4kbits/s [18:50:44 CET] <theFam> fps=0.3 [18:50:46 CET] <theFam> ;_; [18:50:58 CET] <furq> if it's a dualcore atom then you should be using -threads 3, although that won't make a huge difference [18:51:01 CET] <ChocolateArmpits> theFam: change your preset to at least superfast and set the bitrate [18:51:17 CET] <furq> or just don't use -threads at all and let it autodetect [18:51:33 CET] <theFam> it's too laaate [18:51:37 CET] <ChocolateArmpits> there is no real point for anything below medium when rendering hd video [18:51:41 CET] <ChocolateArmpits> You'll save time [18:51:48 CET] <theFam> i can't risk giving up 51 seconds of progress [18:51:48 CET] <ChocolateArmpits> or is it just that short? [18:52:04 CET] <theFam> it's about 3 mins [18:52:26 CET] <theFam> it'll probably render when I am asleep [18:52:33 CET] <theFam> this an arm tablet btw [18:52:40 CET] <theFam> I have no other device ;_; [18:54:22 CET] <Mavrik> Those have HW encoders for a reason. [18:54:33 CET] <Mavrik> But yeah, that progress sounds about right. [18:54:50 CET] <furq> i don't use veryslow on an i7 [18:55:00 CET] <furq> using it on an arm tablet sounds like a fun day out [19:06:01 CET] <Pajeet> it's not fun [19:06:06 CET] <Pajeet> it's neer been fun [19:15:36 CET] <furq> no but you'll have plenty of time to go somewhere nice while you wait for it to finish [19:16:05 CET] <Pajeet> haha [19:16:14 CET] <Pajeet> yay 01:04:00 [20:28:43 CET] <faLUCE> Hello, I created a video from a mp3 file and an animated gif, with this command: ffmpeg -i framm.wav -i anim.gif -acodec mp2 output.avi. Unfortunately, the animated gif is delayed (the second frame doesn't start at its real value, but it is delayed of abou 5 seconds) ... where can be the problem? I use ffmpeg 2.4.3 [20:41:00 CET] <pzich> faLUCE: might be worth trying a newer version? this was opened against 2.3.5 (14 months ago) and closed 11 months ago, not sure if that means 2.4.3 has the fix: https://trac.ffmpeg.org/ticket/4235 [20:43:15 CET] <pzich> the example looks like it's working correctly in 2.7.2 for me [20:45:34 CET] <faLUCE> pzich: is there an alterantive command for linux? I don't want to install a new ffmpeg from scratch by compiling [20:48:41 CET] <jtdesigns01> Are there any optimizations I could do for this command to keep file size down without losing quality and still use mpeg2 video? [20:48:41 CET] <jtdesigns01> ffmpeg -i 20.mkv -s 320x240 -vcodec mpeg2video -b 1000k -ab 128k -ac 2 -ar 44100 -acodec mp3 "F:20.mpg" [20:49:29 CET] <DHE> 2-pass mode might help [20:49:47 CET] <jtdesigns01> how do I do that? [20:51:38 CET] <DHE> run ffmpeg twice, once with `-pass 1` and once with `-pass 2` [20:53:08 CET] <jtdesigns01> hmm. ok [20:53:13 CET] <jtdesigns01> will try that [20:56:14 CET] <jtdesigns01> which stream should I run it on? video? [22:59:21 CET] <durka42> hi, I'm looking to extract the timestamp of each frame of a video as accurately as possible [22:59:31 CET] <durka42> I found the -debug_ts option but I don't know which fields I should be looking at [23:07:28 CET] <kepstin> durka42: you probably want to use ffprobe with the -show_frames option [23:07:57 CET] <kepstin> then depending what you are looking for, maybe the pkg_pts or pkg_pts_time fields is appropriate [23:08:31 CET] <durka42> kepstin: oh nice [23:08:38 CET] <durka42> kepstin: yeah so is there docs somewhere on what those field names stand for? [23:08:59 CET] <durka42> best_effort_timestamp_time also sounds promising :) [23:09:00 CET] <kepstin> durka42: to interpret the pts values, you'll also want "show_streams" so you can get the time_base. [23:09:14 CET] <durka42> the units of pts are seconds, right? [23:09:19 CET] <kepstin> pts is 'presentation time stamp', i.e. basically the time at which the frame should be shown [23:09:38 CET] <kepstin> pts is an integer, you multiply by the time_base fraction to get seconds. [23:09:52 CET] <kepstin> the pkt_pts_time field is premultiplied and is in seconds, I think? maybe ms [23:10:04 CET] <kepstin> looks like seconds [23:10:06 CET] <durka42> oh so it looks like show_frames already looked at the time_base and multiplied for me [23:10:15 CET] <styler2go> Heya everyone. I am trying to make some live transcoding in a rtmp server. My current commands knocks out after some seconds with the error av_interleaved_write_frame(): Operation not permitted [23:10:15 CET] <durka42> yeah it matches up with what I would expect given the length of the video [23:10:24 CET] <durka42> and what is "best effort"? is it smoothed or something? [23:11:17 CET] <kepstin> durka42: it's equal to pts for most formats, but if the container doesn't store proper timestamps it can be basically made up by ffmpeg, iirc. [23:11:21 CET] <kepstin> don't know exactly how it works [23:11:27 CET] <styler2go> it works if i use -f flv but if i use -f h264 it dies after a few ticks [23:12:00 CET] <durka42> kepstin: I see [23:12:04 CET] <durka42> kepstin: this is H.264 [23:13:53 CET] <durka42> kepstin: thanks for the tips! [23:13:55 CET] <kepstin> durka42: I think it depends more on the container/stream than the codec [23:14:03 CET] <durka42> MP4 [23:15:09 CET] <kepstin> i think in general, for most uses, you probably want to use pts. [23:16:33 CET] <styler2go> does -re set ffmpeg into realtime? [23:17:13 CET] <kepstin> -re causes ffmpeg to wait (sleep basically) after decoding each frame until the time when the next frame should be shown [23:17:28 CET] <styler2go> sounds like realtime :P [23:17:41 CET] <kepstin> so slows down input, particularly for stuff like reading from files, to approximately realtime [23:17:57 CET] <kepstin> obviously it can't speed up output if you have an encoder slower than realtime ;) [23:18:01 CET] <styler2go> does this work with -f h264? [23:18:57 CET] <furq> use -f flv [23:19:05 CET] <styler2go> when i use -f h264 it has around 64 fps, when i use -f flv i have around 34 (live is 30) [23:19:10 CET] <kepstin> styler2go: as input or output? [23:19:14 CET] <styler2go> output [23:19:35 CET] <kepstin> are you streaming from a local file to rtmp? [23:19:50 CET] <styler2go> i am trying to set up my rtmp server [23:19:57 CET] <styler2go> to lvie transcode to lower quality [23:20:34 CET] <kepstin> Then you don't want -re - you want it to output frames as fast as it receives them to the output. [23:20:39 CET] <furq> i doubt that -re will work for raw h264 and i don't think rtmp even supports it [23:20:42 CET] <styler2go> http://pastie.org/10728012 that's my current full command like [23:21:19 CET] <furq> -f h264 definitely won't work if you want audio [23:21:30 CET] <furq> also -b:v doesn't do anything if you're copying streams [23:21:34 CET] <kepstin> styler2go: aso, you're using -vcodec copy, so it's not actually transcoding [23:21:34 CET] <furq> nor does -s [23:21:41 CET] <styler2go> humm >.< [23:21:51 CET] <styler2go> I love ffmpeg but it's so hard to use :( [23:21:57 CET] <styler2go> (for me) [23:22:12 CET] <furq> and yeah i would have thought -re would be useless there [23:22:22 CET] <styler2go> what would i need to do if i want to have it at 2000 kbit/s instead of 4000 which is the live input [23:22:27 CET] <furq> you need to transcode it [23:22:33 CET] <kepstin> since it's already reading from a realtime rtmp stream, adding -re would only slow it down and desync it [23:22:42 CET] <furq> replace -vcodec copy with -c:v libx264 [23:22:50 CET] <styler2go> oh and i also want to go down form 60fps to 30fps :o [23:22:54 CET] <styler2go> is that even possible? [23:23:10 CET] <furq> -vf fps=fps=30 [23:23:32 CET] <styler2go> like that? ffmpeg -i rtmp://localhost:1935/live -b:v 2000 -c:v libx264 -vf fps=fps=30 -acodec copy -s 1280x720 -f flv rtmp://localhost:1935/twitch [23:24:00 CET] <furq> sure [23:24:30 CET] <furq> except -b:v 2000k [23:25:07 CET] <furq> you might also want to tweak x264's -preset setting depending on how much cpu usage you can/want to use [23:25:34 CET] <styler2go> it's already at 60% cpu usage with current settings [23:25:36 CET] <kepstin> yeah, 2000 bits per second is probably not enough for 720p video ;) [23:26:08 CET] <styler2go> i should lower resolution, ture [23:26:41 CET] <furq> read what he said again [23:26:48 CET] <styler2go> woups [23:26:54 CET] <styler2go> sorry i am sleepy already :D [23:27:07 CET] <furq> 2000kbps is probably a bit low but it depends what you're streaming [23:27:38 CET] <styler2go> Well, i can't stream on more because of twitch, that's why i want to use an own rtmp server to stream at better quality somewhere else [23:27:44 CET] <styler2go> but also reach out to twitch platform [23:29:08 CET] <styler2go> thanks a lot people. u saved my evening :) [23:44:41 CET] <podman> anyone have experience using FFMPEG with the GPU instances on AWS? Is there anything special that needs to be done to take advantage of the hardware encoders? [23:49:36 CET] <kepstin> podman: start with https://trac.ffmpeg.org/wiki/HWAccelIntro#NVENC [23:50:06 CET] <kepstin> podman: probably need a custom ffmpeg build with nvenc enabled, and you'll need to switch some parameters to us the encoder [23:52:07 CET] <podman> kepstin: thanks [23:53:10 CET] <wintershade> hey guys! a quick question. is it possible to define a target filesize, rather than bitrate? using libvpx as a video codec and libfdk_aac as audio when I need. [23:53:26 CET] <kepstin> wintershade: target filesize and target bitrate are equivalent [23:53:32 CET] <kepstin> filesize = bitrate * length [23:54:01 CET] <wintershade> yes, but sometimes I don't know the length until I open the video, and it's not too convenient for a batch [23:54:31 CET] <wintershade> unless there's a formula which I can insert into the command line... [23:54:39 CET] <kepstin> if you're scripting it, you could use something like ffprobe to read the video length before starting the encode [23:56:28 CET] <wintershade> ok, is there an easy way to get the duration in seconds? [23:56:55 CET] <wintershade> like ffprobe -someswitch <input video>, which yields <some integer>? [23:56:59 CET] <kepstin> by using ffprobe and parsing it from the output (ffprobe is designed to have machine-readable output) [23:57:42 CET] <wintershade> kepstin: I think I'm a bit lost here... [23:59:33 CET] <kepstin> if you run 'ffprobe -show_format file.whatever', it'll print a line like duration=1234.5678 on stdout which is the duration in seconds. A script can read the output, look for that, and use it to calculate the bitrate to use in the encode. [00:00:00 CET] --- Fri Feb 19 2016

1 0

ffmpeg-devel.log.20160217
by burek 18 Feb '16

18 Feb '16

[00:50:02 CET] <Daemon404> michaelni, potentially, i suppose. [00:50:13 CET] <Daemon404> i dont know what weeks gsoc is [00:51:12 CET] <michaelni> timeline: (for anyone interrested what is when) https://developers.google.com/open-source/gsoc/timeline [00:53:04 CET] <Daemon404> wow i didnt remember it being 4 months [00:53:17 CET] Action: Daemon404 will probably have a week vacation somewhere in there [00:53:29 CET] <Daemon404> as in disconnected [00:53:54 CET] <michaelni> that should be no problem [00:54:28 CET] <michaelni> some backup mentor or admin has to fill in that time [00:54:49 CET] <Daemon404> i sure i could mentor [00:54:59 CET] <michaelni> great, thanks [00:55:10 CET] <Daemon404> maybe ill actually get a tshirt [00:55:13 CET] <Daemon404> they never sent mine last time [01:03:25 CET] <michaelni> BBB, wm4, are you potentially available as mentor for this years GSoC ? [01:41:51 CET] <michaelni> Timothy_Gu, fatebeta is "502 Bad Gateway" after reboot [01:42:22 CET] <BBB> michaelni: depends on project [01:42:43 CET] <michaelni> BBB, whatever project you like [01:45:16 CET] <BBB> I dont know yet, its quite far away [01:45:17 CET] <BBB> maybe [01:45:31 CET] <BBB> I dont have any fun projects in my head right now [01:45:45 CET] <michaelni> i was asking because of "How many potential mentors have agreed to mentor this year?" [01:46:07 CET] <jamrial_> Daemon404: http://fate.ffmpeg.org/report.cgi?time=20160216235604&slot=x86_64-archlinux… not sure which commit is at fault [01:46:32 CET] <michaelni> jamrial_, are you potentially available as mentor for this years GSoC ? [01:47:17 CET] <jamrial_> michaelni: no, i don't think i could do it, sorry [01:47:24 CET] <michaelni> ok :( [01:47:39 CET] <michaelni> thanks anyway [01:57:38 CET] <BBB> if you can suggest interesting projects I can re-consider it [01:57:44 CET] <BBB> but I Cant think of anything fun right now [01:58:01 CET] <BBB> I dont really want to do any filters, I dont think anyone cares for ffvp9 since its mostly done [01:58:15 CET] <BBB> hevc is not appropriate for most students and is mostly grind work rather than new implementation work [01:58:18 CET] <BBB> vp10 is too early [01:58:26 CET] <BBB> etc. [02:02:15 CET] <michaelni> some encoder maybe ? would need to be simple enough and interresting enough, maybe intra only something ? [02:05:39 CET] <Daemon404> jamrial_, weird... but its 1am here, sleep time [02:06:51 CET] <iive> michaelni: what happened with your 100fps filter? [02:10:48 CET] <michaelni> i should work on it but i lack time [02:16:30 CET] <iive> what is there to be done? [02:42:05 CET] <Timothy_Gu> michaelni: manually started the server [02:45:10 CET] <Timothy_Gu> never expected anyone to actually care about our codename https://i.iinfo.cz/images/298/ffmpeg-einstein-prev.jpg [02:45:42 CET] <TD-Linux> ffmpeg has codenames? [02:46:01 CET] <Timothy_Gu> https://www.ffmpeg.org/download.html [02:47:35 CET] <TD-Linux> I named a libvorbis release ÄÄÄÄ [03:56:44 CET] <BBB> michaelni: its hard to review asm if you move the code along with changing it [04:21:49 CET] <michaelni> BBB, ill post a cleaner patch(set) for that one [04:42:27 CET] <BBB> michaelni: ah much easier to read, ty [04:43:07 CET] <BBB> lgtm [04:54:26 CET] <michaelni> atomnuker, aac-pns seems to need a higher FUZZ factor on http://fatebeta.ffmpeg.org/report/loongson-fedora-gcc-4.8/20160216214610#fa… [04:54:44 CET] <michaelni> this also may need backporting [05:17:33 CET] <cone-228> ffmpeg 03Michael Niedermayer 07master:d07f6e5f1c36: swscale/x86/output: Move code into yuv2planeX_mainloop [05:17:33 CET] <cone-228> ffmpeg 03Michael Niedermayer 07master:f6492a2ea8df: swscale/x86/output: Fix yuv2planeX_16* with unaligned destination [09:49:58 CET] <cone-571> ffmpeg 03Paul B Mahol 07master:5589698e0bd6: avfilter/vf_drawbox: add alpha pixel formats support [09:49:58 CET] <cone-571> ffmpeg 03Paul B Mahol 07master:4dc58803813f: avfilter/vf_drawbox: reindent [11:28:19 CET] <atomnuker> michaelni: thanks for telling me, I'll try to fix it later today [13:50:28 CET] <wm4> note to self: never engage Mats [13:55:59 CET] <BBB> wbs: thanks for merging [13:56:02 CET] <BBB> wm4: what happened? [13:58:07 CET] <durandal_1707> it could get worse, sending mails directly to you [14:58:05 CET] <wm4> michaelni: I wouldn't know for what [15:46:00 CET] <ubitux> {nv12,nv21,yuv420p,yuv422p}_to_{argb,rgba,abgr,rgba}_neon 16 and 32 for aarch64 done. [15:46:10 CET] <ubitux> need to add some prefetch and cleanups and it's good to go [15:47:37 CET] <durandal_1707> got mail to respect copyright laws [15:48:18 CET] <durandal_1707> from svnoreply(a)googlemail.com [15:49:14 CET] <durandal_1707> including patent, trademark, trade secret etc [15:49:23 CET] <nevcairiel> sounds bogus =p [15:50:25 CET] <durandal_1707> its interesting scam [15:52:06 CET] <rcombs> ubitux: wtb aarch64 yuv2yuv [15:52:51 CET] <ubitux> better do rgb2yuv first [15:53:00 CET] <nevcairiel> how often does that happen [15:53:18 CET] <nevcairiel> yuv2rgb and yuv2yuv are at least used in various playback scenarious [15:53:20 CET] <nevcairiel> -u [15:54:02 CET] <J_Darnley> Speaking of scams, did anyone else recieve a "floss survey" today? [15:54:09 CET] <nevcairiel> oh yeah [15:54:16 CET] <nevcairiel> second time already, too [15:54:20 CET] <nevcairiel> (not today, mind you) [15:55:38 CET] <rcombs> I've been asking for some cleanup (logging, statics&) and confirmation this passes FATE and memcheck for a while, but haven't heard back, so here have a patch made of intrinsics and hardcoded cases: https://gist.github.com/541a7715a6213f71f91a [15:55:56 CET] <J_Darnley> Aww. The survey doesn't have as many free-form boxes as I want. :( [15:56:21 CET] <nevcairiel> rcombs: psh intrinsics, write asm files like a big boy! :D [15:56:28 CET] <rcombs> nevcairiel: that's what I said [15:57:09 CET] <rcombs> they preferred the intrinsics because it allows sharing between arm and aarch64 more easily, which I suppose isn't absurd [15:57:28 CET] <rcombs> and maybe we should have something like x86inc.asm for arm/aarch64 [15:57:35 CET] Action: J_Darnley suggests they need to writea better assembler [16:02:16 CET] <J_Darnley> LOL. "please insert -1 if don't know" --> "Must be a number greater than 0" [16:02:25 CET] <J_Darnley> A real good programmer wrote that! [16:07:00 CET] <J_Darnley> This survey also heavily github centered [16:07:09 CET] <J_Darnley> pull request this, pull request that [16:07:18 CET] <nevcairiel> i just deleted the mail with no second thought [16:07:37 CET] <J_Darnley> I'm just filling it with junk to see what's on the pages [16:08:16 CET] <nevcairiel> but I think github didnt ínvent pull requests, it kind of came natural to the git flow [16:08:41 CET] <wm4> wasn't pull request a term before github (curse you github) [16:09:18 CET] <J_Darnley> maybe they didn't but I don't know a git tool that send an email saying "please pull changes from this branch" [16:09:46 CET] <nevcairiel> maybe not a tool, but i think it was at least common practice in kernel development, and those guys invented git, so.. [16:09:51 CET] <Daemon404> you guys got that email? [16:09:57 CET] <Daemon404> gmail put it in spam for me [16:10:08 CET] <J_Darnley> Me too but I always look in spam [16:10:09 CET] <nevcairiel> i should have spammed it instead of deleting it right away =p [16:10:10 CET] <Daemon404> act [16:10:14 CET] <Daemon404> ic [16:11:44 CET] <J_Darnley> Well gmail can be overzealous in marking spam. I found several winamp beta list mails in there when I checked. [16:12:05 CET] <nevcairiel> didnt someone tell you, winamp died [16:12:20 CET] <J_Darnley> Then why am I running a 2 day old beta? [16:12:30 CET] <J_Darnley> I might be undead [16:12:32 CET] <J_Darnley> *it [16:13:57 CET] <cone-478> ffmpeg 03Michael Niedermayer 07master:c351126ee938: avcodec/eatqi: print error on mb decode failure [16:13:58 CET] <cone-478> ffmpeg 03Muhammad Faiz 07master:7c11e727f640: avfilter/avf_showcqt: improve pts handling [16:18:18 CET] <J_Darnley> There's the jackpot word [16:18:21 CET] Action: J_Darnley cheers [16:26:59 CET] <cone-478> ffmpeg 03Johan Ström 07master:6c31c99289e3: hlsenc: add use_localtime_mkdir option to automatically create time-based directory [16:40:16 CET] <cone-478> ffmpeg 03Luca Barbato 07master:21c750f240b9: configure: Use `require` for the non-component options [16:40:17 CET] <cone-478> ffmpeg 03Luca Barbato 07master:5e1beec944da: configure: Print which libraries will be built [16:40:18 CET] <cone-478> ffmpeg 03Luca Barbato 07master:a2bb771a3cde: configure: Restore the --enable-everything behaviour [16:40:19 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:f97ee815cf25: Revert "configure: Revert recent changes to disable-everything" [16:40:20 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:470bfab47089: Merge commit '21c750f240b9d0c41a258d1adee2d9f75ff378b6' [16:40:21 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:3bff005be8ea: Merge commit '5e1beec944dacd6b4ed7d710125dd508c41ca969' [16:40:22 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:e8ebcb0034c5: Merge commit 'a2bb771a3cded8a05137c0effb34f61a2bc78e22' [16:40:29 CET] <Daemon404> carl should be happy... [16:50:46 CET] <nevcairiel> Carl is never happy [16:53:07 CET] <Daemon404> true [16:53:14 CET] <Paranoialmaniac> lol [17:02:54 CET] <cone-478> ffmpeg 03Anton Khirnov 07master:c084d6d2cfb5: buffersrc: default SAR to 0 (unknown) rather than 1 [17:02:55 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:ae3c0a9c1f66: Merge commit 'c084d6d2cfb570b10d8784eb20cc696dfb7c5605' [17:03:51 CET] <wm4> michaelni: can you stop giving random people push access [17:04:03 CET] <wm4> we've had some problems with this in the past [17:04:41 CET] <Daemon404> wm4, what happened [17:04:59 CET] <wm4> nothing [17:05:06 CET] <Daemon404> o [17:05:22 CET] <wm4> but someone sends a patch to some single libavfilter filter -> offer git write access [17:05:36 CET] <wm4> that seems a bit premature in my opinion [17:07:06 CET] <michaelni> he is the author of that filter [17:07:24 CET] <nevcairiel> well since you cant limit push access to that single filter, it should still be done rather carefully [17:07:42 CET] <cone-478> ffmpeg 03Anton Khirnov 07master:721a4efc0545: buffer: add support for pools using caller data in allocation [17:07:43 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:26abd5149ebf: Merge commit '721a4efc0545548a241080b53ab480e34f366240' [17:08:39 CET] <wm4> michaelni: if he's a regular contributor who knows the rules and who behaved well it should be ok [17:13:09 CET] <mateo`> I'm wondering what a decoder (the mediacodec one in my case) is supposed to return to signal that it has output all the remaining frames while he's been sent null avpackets to flush it, AVERROR_EOF ? Considering you can send a null avpacket but you are not guaranteed to return a frame at that time. [17:13:35 CET] <cone-478> ffmpeg 03Anton Khirnov 07master:89923e418b49: lavu: add a framework for handling hwaccel frames [17:13:36 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:1a708780f3d4: Merge commit '89923e418b494e337683442ab896d754bc07341a' [17:14:07 CET] <wm4> mateo`: return success (0) [17:14:13 CET] <Daemon404> wm4, https://git.libav.org/?p=libav.git;a=commit;h=a001ce31bc2bcf875a39b5fb22dae… [17:14:28 CET] <Daemon404> this should be ok to merge, no? [17:14:31 CET] <wm4> Daemon404: yes [17:14:36 CET] <Daemon404> since afaik the VDPAU code between both repos is identical [17:14:37 CET] <Daemon404> right> [17:14:45 CET] <wm4> it should be, yes [17:15:00 CET] <wm4> but it doesn't even touch libavcodec yet [17:15:14 CET] <michaelni> wm4, IMO he is, also ill point it out to him privately again just to be double sure but i think we dont have a problem with people ignoring rules [17:15:30 CET] <Daemon404> wm4, yeah i know [17:16:36 CET] <mateo`> wm4: so then, what is it supposed to return when it received a null avpacket but does not return a frame ? [17:16:54 CET] <cone-478> ffmpeg 03Anton Khirnov 07master:a001ce31bc2b: hwcontext: add a VDPAU implementation [17:16:55 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:d779d8d771c0: Merge commit 'a001ce31bc2bcf875a39b5fb22dae49120293b42' [17:21:32 CET] <Daemon404> i need someone with a VDPAU setup to test this next merge [17:21:35 CET] <Daemon404> before a push [17:21:38 CET] <Daemon404> who could i poke? [17:21:53 CET] <wm4> I could test, if there's something to test at all [17:22:05 CET] <wm4> oh right, ffmpeg_vdpau.c I suppose [17:22:07 CET] <Daemon404> yep [17:22:29 CET] <BBB> seeking in lavfi [17:22:30 CET] <BBB> hm [17:22:32 CET] <BBB> wonderful [17:22:36 CET] <BBB> so& why is that a command [17:22:40 CET] <BBB> thats probably ridiculous, no? [17:22:45 CET] <wm4> BBB: it's for the movie_src only [17:22:52 CET] <nevcairiel> BBB: because its a cheap-ass hack, not a generic solution [17:22:53 CET] <wm4> which demuxes/decodes stuff [17:22:55 CET] <BBB> shouldnt lavfi overall support seeking? [17:23:02 CET] <BBB> or flushing, at least [17:23:14 CET] <wm4> BBB: no, because mpeg has discontinuities anyway [17:23:17 CET] <wm4> so you don't need flushing [17:23:23 CET] <wm4> (god why am I bothering) [17:23:24 CET] <BBB> ????? [17:23:30 CET] <BBB> mpeg is broken shit [17:23:34 CET] <Daemon404> wm4: curl http://pastebin.com/raw/2e2gZ9Gm | base64 -d | xz -d > patch.diff [17:23:35 CET] <BBB> so we dont need a solution for a problem [17:23:37 CET] <BBB> ????? [17:23:37 CET] <Daemon404> can you test that [17:23:43 CET] <wm4> Daemon404: give me a moment [17:24:12 CET] <kierank> movie_src is becoming a mini gstreamer [17:24:38 CET] <wm4> kierank: it was always the intention for lavfi to become gstreamer [17:24:48 CET] <wm4> Daemon404: xz: (stdin): Unexpected end of input [17:24:53 CET] <BBB> quick, let me unsubscribe [17:24:57 CET] <wm4> actually base64: invalid input [17:25:01 CET] <BBB> can we split lavc and lavfi in separate projects then? [17:25:07 CET] <Daemon404> wm4, oh... maybe pastebin fucks it up [17:25:08 CET] <kierank> split them all [17:25:19 CET] <BBB> I dont want to make this political [17:25:47 CET] <nevcairiel> movie_src in itself is a big hack because apps dont implement multiple-input support [17:25:53 CET] <wm4> (IMO it's fine to try to recreate gstreamer/dshow/etc, but not in libavfilter and certainly not in the same repo as libavcodec) [17:25:57 CET] <nevcairiel> so make the filter graph create its own inputs [17:26:12 CET] <wm4> movie_src has no input [17:26:14 CET] <wm4> only outputs [17:26:18 CET] <nevcairiel> it is an input [17:26:21 CET] <nevcairiel> its the point [17:26:31 CET] <wm4> depends in the viewpoint I guess [17:26:37 CET] <nevcairiel> otherwise whatever host app is used would need to support multiple inputs [17:26:48 CET] <wm4> ffmpeg.c does! mpv also does [17:27:04 CET] <wm4> and the libavdevice libavfilter wrapper (which also has some extra code for CCs) [17:27:22 CET] <wm4> that libavdevice thing is actually the "main use" of moviesrc [17:27:38 CET] <Daemon404> wm4, ... base64 tool is retarded [17:27:48 CET] <Daemon404> it's because pastebin is CRLF [17:27:51 CET] <wm4> so why use base64 at all [17:27:56 CET] <Daemon404> cause im lazy [17:28:13 CET] <michaelni> ./configure --enable-x11grab --enable-gpl fails "x11grab cannot be enabled", is that intended ? [17:28:14 CET] <Daemon404> and copypasting patch from terminal breaks stuff [17:28:17 CET] <wm4> git diff | curl -F 'sprunge=<-' http://sprunge.us [17:28:25 CET] <Daemon404> michaelni, might be due to some recent merge of mine [17:28:35 CET] <michaelni> yes it worked before [17:28:35 CET] <Daemon404> wm4, oh cool. [17:28:49 CET] <wm4> Daemon404: it returns a url for the raw data too [17:29:14 CET] <nevcairiel> arent there even finished tools to do that so you dont have to remember the curl syntax [17:29:43 CET] <Daemon404> wm4, http://sprunge.us/RaeU [17:29:48 CET] <wm4> nevcairiel: a 2 line sh script? [17:29:52 CET] <Daemon404> not even [17:29:54 CET] <Daemon404> just an alias [17:30:08 CET] <wm4> error: patch failed: ffmpeg_vdpau.c:30 [17:30:08 CET] <wm4> error: ffmpeg_vdpau.c: patch does not apply [17:30:13 CET] <Daemon404> uh? [17:30:17 CET] <Daemon404> git pull to master? [17:30:21 CET] <wm4> ah wait [17:30:24 CET] <nevcairiel> those tools probably just are scripts, but they offer a choice of hosts i think =p [17:30:36 CET] <Daemon404> wm4, crlf? [17:30:53 CET] <wm4> my repo was unclean [17:30:55 CET] <wm4> now it applied [17:30:58 CET] <Daemon404> ah [17:31:01 CET] <nevcairiel> UNCLEAN! [17:31:02 CET] <nevcairiel> :D [17:31:19 CET] <Daemon404> git-clean ftw [17:31:23 CET] <jamrial> git purge [17:31:49 CET] <nevcairiel> git clean doesnt revert [17:31:59 CET] <Daemon404> true [17:33:25 CET] <Daemon404> michaelni, can you look at config.log [17:33:28 CET] <Daemon404> i dont have any system with x11 [17:33:41 CET] <wm4> ffmpeg_vdpau.c:251:12: error: VDPAUContext {aka struct VDPAUContext} has no member named decoder [17:33:41 CET] <wm4> if (ctx->decoder) [17:33:41 CET] <wm4> ^ [17:34:11 CET] <Daemon404> it might be a tad hard for me to fix this without a vdpau system [17:34:34 CET] <wm4> would it be useful if I beat this into working and then send a diff? [17:34:46 CET] <Daemon404> yea [17:35:39 CET] <Daemon404> lazy way of "fixing" a merge is: git merge -s ours <hash> && patch -p1 < a.patch && git commit -a -s --amend [17:35:41 CET] <wm4> ah the entire function is actually unused now [17:35:42 CET] <Daemon404> <_< [17:35:48 CET] <wm4> - if (vdpau_api_ver == 1) [17:35:48 CET] <wm4> - return vdpau_old_init(s); [17:35:52 CET] <wm4> this removed its use [17:35:57 CET] <Daemon404> right [17:36:03 CET] <wm4> ffmpeg: add vdpau_old to allow continued testing of the older (but not oldest) API [17:36:03 CET] <Daemon404> why the heck was that there anyway? [17:36:09 CET] <wm4> LOL [17:36:10 CET] <Daemon404> it was hardcoded to 2 [17:36:13 CET] <Daemon404> yeah thats fucking dumb [17:36:26 CET] <wm4> indeed [17:36:31 CET] <nevcairiel> ffmpeg_vdpau.c actually used the crappy old api? [17:36:35 CET] <nevcairiel> or well could [17:36:39 CET] <Daemon404> if you edited the file [17:36:41 CET] <wm4> I have no idea [17:36:43 CET] <nevcairiel> just rip it out then, its scheduled for removal anyway [17:36:48 CET] <Daemon404> thats what i did [17:36:50 CET] <Daemon404> as wm4 noted [17:36:53 CET] <wm4> I think it only tests av_vdpau_get_profile? but still uses hwaccel [17:37:07 CET] <Daemon404> apologies for language above. [17:37:14 CET] <wm4> ffmpeg_opt.o:(.data.rel.ro+0x1498): undefined reference to `vdpau_api_ver' [17:37:41 CET] <wm4> ok an unused option [17:38:04 CET] <Daemon404> oh.. wtf [17:38:08 CET] <wm4> now uh how do I test it at runtime [17:38:15 CET] <Daemon404> i dont know how to use vdpau via cli [17:38:28 CET] <nevcairiel> make fate HWACCEL=vdpau =p [17:38:48 CET] <nevcairiel> or ffmpeg -hwaccel vdpau -i ... [17:38:51 CET] <Daemon404> i wonder if this will break some fate instance which tests the old apo [17:38:57 CET] <nevcairiel> doubt we have those [17:39:04 CET] <Daemon404> it would be a huge amount of crap to keep version=1 support [17:39:05 CET] <Daemon404> i think [17:39:09 CET] <wm4> [h264 @ 0x2aa4460] Hardware accelerated decoding with frame threading is known to be unstable and its use is discouraged. [17:39:10 CET] <wm4> trollol [17:39:15 CET] <Daemon404> :D [17:39:34 CET] <nevcairiel> i wanted to write a patch to automatically make ffmpeg.c disable threads if hwaccel is requested [17:39:36 CET] <nevcairiel> but i got lazy [17:40:07 CET] <wm4> how do I disable threads for fate? [17:40:10 CET] <Daemon404> i swear i heard that vdpau allows threads [17:40:17 CET] <nevcairiel> fate automatically disables threads [17:40:22 CET] <fritsch> Daemon404: where did you hear that? [17:40:25 CET] <wm4> Daemon404: it does, it's not a problem with the hw api really [17:40:28 CET] <nevcairiel> unless you run it with THREADS=x [17:40:32 CET] <michaelni> Daemon404,is caused by disable x11grab and later enable x11grab [17:40:47 CET] <wm4> fritsch: it's specified to allow concurrent access [17:40:49 CET] <Daemon404> michaelni, i dont recall merging anything relating to x11 latelt [17:41:00 CET] <nevcairiel> Daemon404: configure dependency changes [17:41:06 CET] <fritsch> wm4: we talk about frame threading currently, right - which is something highly special [17:41:07 CET] <nevcairiel> those things are borked as f' [17:41:23 CET] <wm4> fritsch: yeah, libavcodec vs. pure vdpau API [17:41:28 CET] <nevcairiel> there was another new patch on the ML to try to fix some fallout [17:41:44 CET] <nevcairiel> ie. libav quality =p [17:41:49 CET] <wm4> that's what you get for having a 7kloc sh script? [17:42:08 CET] <nevcairiel> thats what you get for changing the status quo just to improve the failure messages a bit [17:42:11 CET] <wm4> 746ae4adb7d1921800b9cc30257d7231 *tests/data/fate/vsynth1-mpeg1.mpeg1video [17:42:11 CET] <wm4> 711835 tests/data/fate/vsynth1-mpeg1.mpeg1video [17:42:11 CET] <wm4> -c126c7dd12e7161df192d253e3100475 *tests/data/fate/vsynth1-mpeg1.out.rawvideo [17:42:11 CET] <wm4> +926e3b20178b3b89b36b7f9c1e8325e2 *tests/data/fate/vsynth1-mpeg1.out.rawvideo [17:42:11 CET] <wm4> stddev: 7.63 PSNR: 30.48 MAXDIFF: 84 bytes: 7603200/ 7603200 [17:42:16 CET] <wm4> what does it mean [17:42:22 CET] <nevcairiel> mpeg1 is not bitexact in hardware [17:42:25 CET] <nevcairiel> stick to h264 [17:42:31 CET] <wm4> makes sense [17:42:43 CET] <Daemon404> michaelni, im not seeing where it changed [17:42:59 CET] <Daemon404> it could be merges exposed some existing bug, or introduced one [17:42:59 CET] <nevcairiel> mpeg1/2 dont specify strictly enough for bitexact decoding in all decoders [17:43:05 CET] <Daemon404> but i cant see where x11 specifically was affected [17:44:12 CET] <michaelni> previously disable X enable X was ok now it fails, x11 is one path that did it it seems [17:44:41 CET] <nevcairiel> Daemon404: like i said, there is at least 2 more unpushed patches on their ML that "fix" some behavior they broke... [17:44:41 CET] <wm4> now h264-conformance-cvfc1_sony_c fails [17:44:46 CET] <nevcairiel> wm4: thats cropping [17:44:49 CET] <wm4> ok [17:44:57 CET] <wm4> then I suppose everything is fine [17:45:01 CET] <Daemon404> michaelni, ok [17:45:13 CET] <wm4> Daemon404: http://sprunge.us/AbHB [17:45:16 CET] <Daemon404> wm4, ok [17:45:38 CET] <wm4> and yes the "old API" option is removed from ffmpeg [17:46:10 CET] <Daemon404> michaelni, [libav-devel] [PATCH] configure: Use set_all to force the dependency refresh [17:46:17 CET] <Daemon404> sounds like it is related [17:47:27 CET] <michaelni> doing --enable-libpulse twice failed too [17:47:28 CET] <cone-478> ffmpeg 03Anton Khirnov 07master:bd49be885e9a: avconv_vdpau: use the hwcontext API to simplify code [17:47:29 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:6b706ce85fa5: Merge commit 'bd49be885e9ad6bae599c54473ba2fa2957eb140' [17:47:48 CET] <Daemon404> michaelni, that is mentioned in the patch i just talked about [17:48:56 CET] <michaelni> what is the point of the changes that broke this ? [17:49:20 CET] <Daemon404> to make things like --disable-protocols --enable-protocol=https work as intneded [17:49:31 CET] <Daemon404> iirc in the past, it just left everything enabled [17:49:36 CET] <nevcairiel> that seemed to work fine for me before, i used such syntax in my build files [17:49:45 CET] <nevcairiel> and verified the outcome [17:50:16 CET] <Daemon404> maybe i misremember; it's listed in the commit message [17:50:41 CET] <Daemon404> hmm.. [17:50:57 CET] <Daemon404> next up are a whole boatload of patches related to lavu hwaccel api and cuda/nvenc [17:51:05 CET] <Daemon404> this is likely over my head... [17:51:07 CET] <wm4> blergh [17:51:30 CET] <wm4> well lavu hwaccel is of course new, so no conflicts? [17:51:40 CET] <wm4> but cuda/nvenc are a mess already [17:51:52 CET] <Daemon404> nvenc: support CUDA frames as input [17:51:57 CET] <Daemon404> stuff like this [17:52:15 CET] <Daemon404> is the nvenc author on irc? [17:52:18 CET] <Daemon404> he may be able to help. [17:52:20 CET] <nevcairiel> could just skip that one and ping our maintainer for that if he is interested to add that [17:52:40 CET] <Daemon404> indeed [17:52:51 CET] <Daemon404> see above [19:03:38 CET] <cone-478> ffmpeg 03Paul B Mahol 07master:38ed528fa5fe: avfilter/drawutils: >8 bit support [19:05:18 CET] <cehoyos> Derek: Can you please revert this? [19:05:39 CET] <cehoyos> Why are these merges necessary? [19:07:11 CET] <BtbN> Daemon404, yes, I'm here. But I wonder how that's supposed to work. API-Only, so some application using CUDA has a way to send frames as On-GPU-Surfaces? [19:07:30 CET] <cehoyos> Daemon404: Please revert the changes to configure, they are horribly broken. [19:07:35 CET] <BtbN> Or is it that horrible nvidia-hack-patch that adds a full hw pipeline by monkey-patching litteraly everything. [19:11:36 CET] <Daemon404> cehoyos, please give actual reasons. [19:11:44 CET] <Daemon404> and actual usecases which are broken [19:11:58 CET] <cehoyos> The following do not work correctly (some shamelessy stolen from Martin): [19:12:02 CET] <cehoyos> ./configure --disable-everything [19:12:03 CET] <Daemon404> there is alreaydy a fix for x11grab, and double disable/enable [19:12:08 CET] <cehoyos> ./configure --enable-gpl --enable-gpl [19:12:12 CET] <Daemon404> yes. there;s a fix. [19:12:17 CET] <Daemon404> i just havent pushed it yet [19:12:17 CET] <cehoyos> ./configure --disable-everything ---disable-network [19:12:50 CET] <cehoyos> Please just revert this: These are just the first three things I tried. [19:12:57 CET] <cehoyos> Why are you doing merges?? [19:13:11 CET] <Daemon404> cehoyos, i will not revert it if there is a fix. [19:13:11 CET] <cehoyos> This is not only useless, it actually hurts development severly! [19:13:17 CET] <Daemon404> if it is broken after the fix, we can talk. [19:13:22 CET] <cehoyos> Where is a fix? Please point me to the fix! [19:13:34 CET] <Daemon404> https://patches.libav.org/patch/59824/raw/ [19:14:03 CET] <Daemon404> [18:12] <@cehoyos> Why are you doing merges?? <-- because nevcairiel wanted a break. [19:14:44 CET] <cehoyos> The patches neither fix --disable-everything nor --disable-networks [19:14:52 CET] <cehoyos> No, I mean: Why are merges done at all? [19:15:02 CET] <durandal_1707> they are doing evil merges, cehoyos [19:15:03 CET] <kierank> lol [19:15:04 CET] <Daemon404> ... im not even going to dignify that with a response [19:15:08 CET] <cehoyos> Please revert the changes to configure. [19:15:19 CET] <Daemon404> cehoyos, how about you test the fix [19:15:29 CET] <Daemon404> and stop beign so damn rude [19:15:41 CET] <cehoyos> What? [19:15:46 CET] Action: Daemon404 facedesk [19:16:33 CET] <durandal_1707> cehoyos: could you wait 24h? [19:16:54 CET] <cehoyos> The problem is not to wait now but that this breaks regression tests. [19:17:01 CET] <Daemon404> i ran fate fully [19:17:11 CET] <Daemon404> i linked you a possiblw fix [19:17:18 CET] <cehoyos> If it will be fixed I don't care about changes but it can't stay like this, sorry. [19:17:25 CET] <cehoyos> The fix does not work,, please read my posts! [19:17:26 CET] <Daemon404> [18:13] <@Daemon404> https://patches.libav.org/patch/59824/raw/ [19:17:33 CET] <Daemon404> uh [19:17:37 CET] <Daemon404> you did not say you tested it [19:17:39 CET] <Daemon404> and that it didnt work [19:17:44 CET] <Daemon404> please do point that out [19:17:53 CET] <cehoyos> The patches neither fix --disable-everything nor --disable-networks <-- what else should this mean?? [19:18:02 CET] <cehoyos> [19:14] <cehoyos> [19:18:40 CET] <Daemon404> considering i linked you one (single) patch, i did not think "patches" (plural) referred to it. [19:18:54 CET] <durandal_1707> perhaps our configure is wastly different? [19:18:54 CET] <cehoyos> Sorry, my fault! [19:19:11 CET] <cehoyos> The patch you linked does not fix the issue with current configure in FFmpeg: Please revert the changes. [19:19:53 CET] <Daemon404> give me more than 2 seconds to test this [19:20:02 CET] <cehoyos> Please do! [19:20:51 CET] <durandal_1707> cehoyos: can you wait? [19:21:10 CET] <Daemon404> i cant see what is wrong with --disable-everything --disable-networks [19:21:21 CET] <Daemon404> configure says networking is disabled if i do that [19:21:33 CET] <Daemon404> (with the patch i linked above applied) [19:21:33 CET] <cehoyos> It does not disable networks here;-( [19:21:40 CET] <cehoyos> I have the patch applied. [19:22:01 CET] <Daemon404> daemon404@bbvm:~/dev/f/ffmpeg$ ./configure --disable-everything --disable-network | grep network [19:22:04 CET] <Daemon404> network support no [19:22:22 CET] <cehoyos> Pleae compare the output of configure from yesterday with today. [19:22:39 CET] <Daemon404> how about you tell me whats wrong [19:22:40 CET] <Daemon404> with words [19:22:40 CET] <durandal_1707> what changed? [19:22:41 CET] <cehoyos> Or do "grep TCP config.h" [19:22:46 CET] <Daemon404> because "output changed" is not a regression. [19:22:52 CET] <cehoyos> network is not disabled, that is the difference. [19:23:02 CET] <cehoyos> Of course not, you are right. [19:23:07 CET] <Daemon404> i cannot reproduce this. [19:23:17 CET] <Daemon404> daemon404@bbvm:~/dev/f/ffmpeg$ grep TCP config.h [19:23:17 CET] <Daemon404> #define CONFIG_MSNWC_TCP_DEMUXER 0 [19:23:17 CET] <Daemon404> #define CONFIG_TCP_PROTOCOL 0 [19:23:19 CET] <cehoyos> But if the relevant option is "--disable-network" and network is still enabled then it is a bug [19:23:29 CET] <Daemon404> its not enabled [19:23:45 CET] <cehoyos> I am on 38ed528fa5fe5cd1f47edb70090f65958fb1e8ce with the "raw" patch applied. [19:24:16 CET] <Daemon404> even pre-patch it is not enabled [19:24:34 CET] <Daemon404> i am on 6b706ce85fa56564986211b99d34e269066ca3d9 [19:24:56 CET] <Daemon404> let me pull to 38ed528fa5fe5cd1f47edb70090f65958fb1e8ce [19:25:03 CET] <cehoyos> No, forget it! [19:25:12 CET] <cehoyos> The only remaing issue is with --disable-everything. [19:25:23 CET] <Daemon404> ok [19:25:30 CET] <Daemon404> what is wrong with disable-everything [19:25:31 CET] <cehoyos> It does not disable h264 and some demuxers (I thought the demuxers are related to network, but that may be wrong) [19:26:40 CET] <jamrial> wouldn't that be something pulled by ffmpeg and/or ffprobe? [19:27:01 CET] <jamrial> i know some filters are enabled that way [19:27:24 CET] <Daemon404> cehoyos, where can i find martin's email? [19:27:28 CET] <cehoyos> I am not talking about filters [19:27:35 CET] <cehoyos> That is only related to enable-gpl [19:28:41 CET] <cehoyos> Isn't it much easier for everybody of us if we just keep our working configure? [19:28:44 CET] <jamrial> no, i mean, ffmpeg and ffprobe have select lines in configure that if i remember right override --disable-everything [19:29:27 CET] <Daemon404> that shouldnt pull in h264 [19:29:31 CET] <cehoyos> Yes, you are absolutely right: ffmpeg does enable some filters with --disable-everything [19:29:42 CET] <cehoyos> But currently several demuxers are enabled. [19:29:49 CET] <Daemon404> i think i see what is pulling it in [19:29:58 CET] <cehoyos> I thought this is network related but it may not be related at all. [19:30:02 CET] <Daemon404> it's not [19:30:20 CET] <cehoyos> Why do you believe it makes sense to try to fix this? [19:30:51 CET] <cehoyos> Aren't you trippling the work like this? [19:31:11 CET] <Daemon404> only yours. [19:31:23 CET] <Daemon404> it fixes some other stuff, i'd like to have more than 5 bloody minutes [19:31:24 CET] <Daemon404> to fix it [19:31:33 CET] <Daemon404> instead of OMG REVERT NOW I CNAT HANDLE THIS FOR AN HOUR [19:31:36 CET] <cehoyos> I am curious: What does it fix? [19:31:44 CET] <kierank> cehoyos: can you shut up and let derek fix things [19:31:54 CET] <cehoyos> I don't remeber shouting at you, please don't shout at me. [19:32:04 CET] <kierank> or better still send a fix [19:32:13 CET] <wm4> I have to second this [19:32:20 CET] <cehoyos> Sorry, I don't understand why these patches have to be merged: Nobody claimed so far they fix anything. [19:32:29 CET] <cehoyos> You want me to revert? [19:32:29 CET] <wm4> don't bark just because it smells like Libav [19:32:38 CET] <jamrial> no [19:32:39 CET] <cehoyos> I only bark because it is broken. [19:32:40 CET] <nevcairiel> bugs dont have to be fixed within 60 seconds, either contribute to help fix them, or sit by quietly and let derek work [19:32:43 CET] <Daemon404> it's not broken [19:32:46 CET] <Daemon404> nothing is failing [19:32:51 CET] <Daemon404> it adds some extra compile time [19:33:06 CET] <Daemon404> im looking ito it as we speak [19:36:29 CET] <Daemon404> i think i see what is causing it [19:46:57 CET] <Daemon404> ok [19:47:00 CET] <Daemon404> i figured it out. [19:47:08 CET] <Daemon404> cehoyos, i have a patch for you to test [19:47:50 CET] <cehoyos> I am willing to test but please allow me to ask again: Why isn't it simpler to just revert? [19:47:58 CET] <cehoyos> What is the advantage of the merged patch? [19:48:26 CET] <Daemon404> some stuff (i think --disable-protocols) used to be incorrect [19:48:42 CET] <Daemon404> however, your argument doesnt hold a lot of weight if nothing bad comes after fixing [19:48:44 CET] <cehoyos> It worked fine here for years: Do you have an example of a non-working configure line? [19:49:16 CET] <cehoyos> The real problem is: I only tested three configure lines and two didn't work, it's not easy to believe that this was the last issue. [19:49:28 CET] <cehoyos> But I am still curious to hear what didn't work before: [19:49:48 CET] <Daemon404> sorry, i dont buy your "revert now just in case" line [19:49:53 CET] <cehoyos> I use --disable-everything (which includes --disable-protocols) every day so I believe I should have noticed. [19:49:55 CET] <Daemon404> nor do i feel the need to have to defend it to you [19:50:16 CET] <cehoyos> It would be enough if you could tell me what was fixed by the original patch... [19:50:30 CET] <cehoyos> And as said: I only tested three lines, not more [19:51:14 CET] <Daemon404> http://sprunge.us/bOAC [19:51:21 CET] <Daemon404> with this patch, output matches [19:51:41 CET] <Daemon404> i am not going to argue abotu reverting "just in case" [19:51:49 CET] <Daemon404> if you feel so strongly, put it to the mailing list for a vote. [19:51:58 CET] <cehoyos> Then please explain what was fixed! [19:52:09 CET] <Daemon404> [18:49] <@Daemon404> nor do i feel the need to have to defend it to you [19:52:11 CET] <cehoyos> Is the patch meant to be tested with the other patch, or just yours [19:52:17 CET] <Daemon404> you are not the Almighty Gatekeeper [19:52:24 CET] <cehoyos> No, definitely not! [19:52:34 CET] <cehoyos> I just wonder why you are the new project maintainer... [19:52:40 CET] <Daemon404> the patch i just libked applies to a clean git HEAD [19:52:48 CET] <wm4> I wonder since when cehoyos was the project maintainer [19:52:53 CET] <cehoyos> Is it meant to be tested together with the other patch? [19:52:54 CET] <Daemon404> there's no such thing as a project maintainer [19:52:57 CET] <Daemon404> more than one person can merge [19:53:03 CET] <Daemon404> it is not the sole responsibility of one person [19:53:06 CET] <cehoyos> I am not and I don't want to be (and I am not able to be) [19:53:07 CET] <Daemon404> that would be stupid [19:53:14 CET] <durandal_1707> since now [19:53:46 CET] <cehoyos> You are the maintainer: You are committing unreviewed patches. [19:54:15 CET] <cehoyos> Daemon404: Is the new patch meant to be tested together with the old patch or alone? [19:54:15 CET] <jamrial> cehoyos: no, and please stop [19:54:16 CET] <kierank> hahahahahahahahah [19:54:18 CET] <durandal_1707> supreme overlord [19:54:23 CET] <kierank> cehoyos: WOW [19:54:27 CET] <jamrial> like, seriously, stop [19:54:33 CET] <cehoyos> Stop what? [19:54:42 CET] <cehoyos> Running --disable-everything every other day? [19:54:44 CET] <Daemon404> cehoyos, alone [19:55:01 CET] <kierank> cehoyos: do everyone a favour here and grow up [19:55:09 CET] <kierank> instead of being the embarassment of the project [19:55:22 CET] <jamrial> with all the stuff you're saying today. you could have just asked Daemon404 to check the regression you found, but instead came here asking for a revert and now start spouting things about maintainers [19:56:14 CET] <durandal_1707> its free country, say wathever you want [19:56:23 CET] <cehoyos> The following for example used to work, does not work anymore: configure --enable-libmp3lame --disable-libmp3lame --enable-libmp3lame [19:56:27 CET] <Daemon404> durandal_1707, we're all in different countires, some may not be free! [19:56:54 CET] <Daemon404> that's a separate bug [19:57:04 CET] <durandal_1707> wtf, I got headeache with that line [19:57:23 CET] <cehoyos> jamrial: I asked last week the exact same question and I have two more: Why are we merging and what does the original configure patch fixes. [19:57:43 CET] <cehoyos> Surprisinly, I don't get an answer, instead the usual accusaion that "I" should grow up [19:57:55 CET] <cehoyos> (Which unfortunately doesn't hurt me at all, sorrry!) [19:58:06 CET] <jamrial> we're merging because the changes may be useful. if they are not, or if they don't apply, the commit is added as a no-op [19:58:09 CET] <durandal_1707> merging because it easier to follow [19:58:13 CET] <Daemon404> you know what [19:58:30 CET] <Daemon404> i dont volunteer my time helping an open soruce project [19:58:35 CET] <Daemon404> only to get shat on [19:58:37 CET] <Daemon404> good day. [19:58:42 CET] <kierank> cehoyos: look at the wonderful attitude you have [19:58:50 CET] <wm4> cehoyos: thanks for pissing off someone who did hard work [19:58:53 CET] <kierank> this is why we are a laughing stock [19:58:58 CET] <cehoyos> I don't understand: What attitude are you talking about? [19:59:02 CET] <wm4> cehoyos: yours [19:59:06 CET] <cehoyos> Dreek? [19:59:08 CET] <cehoyos> Hard work? [19:59:09 CET] <wm4> cehoyos: yours [19:59:12 CET] <jamrial> absolutely everything you've done today, cehoyos [19:59:13 CET] <wm4> yes [19:59:14 CET] <cehoyos> Are you jloking? [19:59:15 CET] <wm4> merging is hard [19:59:37 CET] <cehoyos> Why does he merge? There are enough bugs that people could look at! [19:59:55 CET] <kierank> cehoyos: and when michael did it, it was fine for years? [19:59:56 CET] <wm4> are you serious [19:59:58 CET] <nevcairiel> just leave already before you drive more contributors off, thank you [19:59:58 CET] <kierank> interesting double standard [20:00:00 CET] <cehoyos> I am! [20:00:06 CET] <jamrial> because we're interested in the changes made by libav [20:00:22 CET] <cehoyos> And I still don't understand his attitude: I was testing a patch, and now he disappeared. [20:00:24 CET] <kierank> This is the part where we act like adults and vote to ban carl [20:00:27 CET] <kierank> but this won't happen [20:00:29 CET] <cehoyos> What am I supposed to do now? [20:00:40 CET] <jamrial> shut up, for starters. don't make things worse [20:00:48 CET] <cehoyos> Very adult, yes! [20:00:52 CET] <wm4> cehoyos: join another project? [20:01:05 CET] <cehoyos> I like this project, you seem to prefer the dark side... [20:01:08 CET] <nevcairiel> cehoyos: you are the one ranting over dereks work for the last hour, so give it a rest [20:01:09 CET] <durandal_1707> mplayer [20:01:09 CET] <jamrial> you turned what should have been regression report into a mess [20:01:27 CET] <wm4> cehoyos: and stop with your pathetic Libav persecution complex [20:01:39 CET] <atomnuker> come one guys, carl just reported stuff broke under some corner cases and everyone jumped up becase it's carl [20:01:57 CET] <cehoyos> wm4: You haven't been the target of hate mails, afair, have you? [20:02:12 CET] <wm4> I'm not interested in your affairs [20:02:12 CET] <durandal_1707> he demanded revert [20:02:26 CET] <cehoyos> I am happy if it gets fixed! [20:02:40 CET] <cehoyos> But I am sure it is much easier to revert than to fix! [20:03:06 CET] <cehoyos> So question to all the grown ups here: How do we proceed? [20:03:08 CET] <jamrial> no, that's stupid [20:03:08 CET] <durandal_1707> but Derek want to help [20:03:22 CET] <kierank> cehoyos: we proceed by you not being a dick [20:03:23 CET] <cehoyos> Derek disappeared: How does that help? [20:03:25 CET] <kierank> but that's not possible [20:03:26 CET] <wm4> cehoyos: apologize to derek [20:03:29 CET] <kierank> he disappeared because of you [20:03:32 CET] <cehoyos> About what? [20:03:32 CET] <atomnuker> well, we patiently wait for a fix and try to help with it, simple as that [20:03:34 CET] <kierank> and your disgusting behaviour [20:03:48 CET] <jamrial> cehoyos: start by testing the patch derek wrote and report back if it fixed the bug you found [20:03:59 CET] <jamrial> then drop the subject. you already did enough damage by being insufferable [20:04:00 CET] <cehoyos> I did test it! [20:04:05 CET] <cehoyos> I did post results here! [20:04:10 CET] <cehoyos> What else do you want? [20:04:36 CET] <wm4> anyway, drama is bad for the nerves, so have fun [20:04:37 CET] <jamrial> did it work? did it fix the whole h264 with --disable-everything? [20:05:00 CET] <cehoyos> No, from a quick test (only one line) it is still broken [20:05:41 CET] <durandal_1707> now it will remain that because of you [20:06:17 CET] <cehoyos> You mean without me reporting it would miracoulously have fixed itself? [20:06:46 CET] <durandal_1707> if you only reported... [20:06:47 CET] <cehoyos> Again: How do we continue? [20:06:55 CET] <cehoyos> configure does not work correctly now... [20:06:58 CET] <kierank> cehoyos: we continue by you apologising to derek [20:07:14 CET] <jamrial> because instead of simply reported you turned this into a mess now derek is not here to fix the proble you found [20:07:16 CET] <kierank> you clearly fail to realise it but you being rude to him is much worse than the minor bug [20:07:16 CET] <cehoyos> For what exactly? [20:07:21 CET] <cehoyos> Reporting an issue? [20:07:26 CET] <cehoyos> Or suggesting a fix? [20:07:31 CET] <jamrial> you didn't just repot [20:07:38 CET] <kierank> cehoyos: http://zestbooks.net/how-not-to-be-a-dick/ [20:07:45 CET] <cehoyos> No, seriously: What can we do to fix the cofigure issue? [20:07:53 CET] <nevcairiel> we are being serious [20:07:53 CET] <cehoyos> Is there an alternative to reverting the change? [20:07:54 CET] <jamrial> you reported, demanded a revert, then started criticizing merges, talked about maintainers, etc [20:07:57 CET] <jamrial> you were annoying [20:08:04 CET] <jamrial> you should have just reported [20:08:07 CET] <jamrial> and waited for a fix [20:08:10 CET] <jamrial> quietely [20:08:13 CET] <cehoyos> No: I asked why merges are done and I did not recieve an answer. [20:08:36 CET] <durandal_1707> I answered [20:08:44 CET] <durandal_1707> and others [20:08:45 CET] <kierank> can we vote to remove carl from the project [20:08:47 CET] <cehoyos> Sorry, I missed it: Where is it? [20:08:50 CET] <jamrial> and so did i [20:08:56 CET] <jamrial> becuase we're interested in the changes added by libav [20:09:14 CET] <cehoyos> jamrial: I am also interested in the patches, I just don't understand why they have to be merged without any review. [20:09:17 CET] <jamrial> now, again, if you want to report something, do it, then don't mix it with your bullshit merge agenda [20:09:29 CET] <kierank> cehoyos: and when michaelni did the merge for the last 4 years it was "reviewed" was it? [20:09:31 CET] <durandal_1707> kierank: propose it on ml [20:09:33 CET] <kierank> interesting double standard [20:09:40 CET] <kierank> durandal_1707: yes I will [20:09:52 CET] <cehoyos> Why is it suddenly my agenda: For years, I have read from different people that the merges should stop, isn't now a good time? [20:10:05 CET] <jamrial> no, it isn't [20:10:06 CET] <durandal_1707> no [20:10:18 CET] <cehoyos> keirank; You may have missed it but at that time FFmpeg had no choice, we had to do the merges. [20:10:23 CET] <jamrial> can you shut up already? you already fucked up everything yet still go at it? [20:10:28 CET] <jamrial> are you getting a kick out of this? [20:10:37 CET] <cehoyos> What did I fuck up? [20:10:42 CET] <jamrial> everything [20:10:44 CET] <kierank> the entire multimedia community [20:10:54 CET] <kierank> people like you are why we are a joke [20:10:57 CET] <jamrial> the problem you reported is not fixed because you wouldn't shut up [20:10:57 CET] <cehoyos> That's news to me! [20:11:19 CET] <n00b81_> Stop with the exclamation marks dude [20:11:22 CET] <durandal_1707> this is going nowhere [20:11:23 CET] <jamrial> you should have just reported it then wait until it was fixed [20:11:24 CET] <cehoyos> I always thought I helped the multimedia community not be taken over by thieves and copyright violators [20:11:33 CET] <kierank> here we go [20:11:39 CET] <jamrial> see? you can't keep issues separated [20:11:43 CET] <cehoyos> Didn't I wait? [20:11:44 CET] <jamrial> you keep pushing you shitty agenda [20:11:50 CET] <kierank> jamrial: it's worse in person [20:12:02 CET] <cehoyos> The agenda to stop the merges? As said, I don't think this is my agenda [20:12:03 CET] <kierank> seriously carl, you have half a dozen people saying you are wrong [20:12:07 CET] <jamrial> you're annoying, disrespectful, talk about things out of place all the time [20:12:16 CET] <jamrial> you ruin everything every time you open your mouth [20:12:32 CET] <cehoyos> But all this doesn't really help anybody: How can we fix configure? [20:12:57 CET] <cehoyos> Sorry? [20:13:03 CET] <cehoyos> Can you please undo this [20:15:11 CET] <n00b81_> And you were so close to getting promoted to lead cheerleader captain too. [20:15:50 CET] <n00b81_> sorry just lurking and enjoying this. [20:15:52 CET] Action: n00b81_ leaves [20:21:32 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:02dfa64c088c: configure: Don't enable examples when --disable-everything is used [20:31:21 CET] <cehoyos> Daemon404: Thank you, --disable-everything --disable-network still enables several demuxers that were not enabled before. [20:31:32 CET] <kierank> he's not here [20:31:34 CET] <kierank> I wonder why [20:33:43 CET] <jamrial> cehoyos: he's not here, or did you miss the fact he left half an hour ago? [20:33:58 CET] <jamrial> he didn't de-op or re-op you [20:40:24 CET] <cehoyos> I know, I was hoping somebody forwards this to him, I am not convinced he reads -cvslog [20:41:04 CET] <kierank> ... [20:41:17 CET] <JEEB> I would recommend posting the cases where output differs together with the diff on the mailing list [20:55:29 CET] <ubitux> where is tmm1 :( [20:57:51 CET] <jas99> Hi guys [20:57:58 CET] <jas99> anybody thr?? [20:58:45 CET] <ubitux> mmh, i must admit configure is quite broken currently [20:58:46 CET] <jas99> knock knock!! [20:59:00 CET] <jas99> oh hi ubitux [20:59:44 CET] <ubitux> like, typically x11grab [20:59:48 CET] <ubitux> pretty strange [21:00:47 CET] <jas99> so ubitux completely ignored me [21:00:55 CET] <jas99> pffff...... [21:01:50 CET] <kierank> that's what happens on irc [21:01:56 CET] <kierank> you should just talk and see if someone responds [21:02:03 CET] <jas99> lol iam new with irc [21:02:12 CET] <jas99> you replied [21:02:23 CET] <jas99> i feel happy :) [21:02:38 CET] <jas99> hi @kierank [21:03:01 CET] <kierank> hello [21:03:23 CET] <jas99> so this is right place to discuss c++ libav lib [21:03:26 CET] <jas99> right?? [21:03:38 CET] <ubitux> no [21:03:51 CET] <cehoyos> jas99: Consider reading the channel topic, I believe it answers your question [21:04:05 CET] <cehoyos> ubitux: Yes, could you send an email? [21:04:28 CET] <jas99> oops [21:04:39 CET] <ubitux> cehoyos: i feel like you already have a bunch of cases that fail; can you try --enable-x11grab to your list and send the mail instead? [21:04:49 CET] <cehoyos> No. [21:05:03 CET] <cehoyos> I mean: It would be much better if somebody else wrote the email, sorry [21:05:04 CET] <ubitux> ok well then can you make me a list of the current failures? [21:05:37 CET] <cehoyos> I had only tested two configure lines: "./configure --enable-libmp3lame --disable-libmp3lame --enable-libmp3lame" and "./configure --disable-everything" [21:05:52 CET] <jas99> cehoyos: what about build issues?? [21:05:55 CET] <cehoyos> The first one is (I assume, I did not test) fixed by the non-yet-committed patch [21:06:06 CET] <cehoyos> The second one enables several demuxers: [21:06:32 CET] <cehoyos> asf, mpegts, rm and mov [21:06:36 CET] <cehoyos> They were not enabled before. [21:06:50 CET] <cehoyos> Sorry, wrong again: [21:07:09 CET] <cehoyos> i tested "./configure --disable-everything --disable-network" and this enables the following demuxers: [21:07:14 CET] <cehoyos> asf, mpegts, rm and mov [21:07:38 CET] <cehoyos> They were not enabled before, I just tested 2ec66ff8 [21:08:10 CET] <cehoyos> Version 2ec66ff8 enables no demuxers with "./configure --disable-everything --disable-network" [21:09:13 CET] <cehoyos> Version 02dfa64c enables asf, mpegts, rm and mov with the same configure line [21:09:23 CET] <iive> I really cannot believe what I'm reading here. [21:10:09 CET] <ubitux> cehoyos: ok; i'm in the middle of review&testing, i'll do sth in the coming hour [21:10:18 CET] <iive> Honestly, Derek commits something that he KNOWS is broken, and it is cehoyos fault for wanting to revert it? [21:10:20 CET] <cehoyos> Don't worry, I have to leave now... [21:10:31 CET] <cehoyos> I am not sure he knew it. [21:10:51 CET] <cehoyos> He knew about --enable-gpl --enable-gpl but not the other issues. [21:11:03 CET] <iive> And yes, Michael have been reviewing the merges and actually committing fixes right after them. [21:11:23 CET] <iive> well, he could have waited, for these things to be fixed in libav before merging them. [21:11:59 CET] <JEEB> he did do basic testing, such as making sure nothing breaks FATE (no idea how many configurations of it he did, of course) [21:12:27 CET] <jamrial> iive: he did. that's why he reverted an old merge some weeks ago and now merged this stuff today [21:13:37 CET] <cehoyos> Sorry, but I really don't think he reverted the old merge because he tested it... [21:14:09 CET] <iive> jamrial: are you telling me the code he merged had no known bugs. Because the patch he pointed, indicates otherwise. the libav.org one [21:14:45 CET] <jamrial> which patch? [21:15:26 CET] <iive> <Daemon404> [18:13] <@Daemon404> https://patches.libav.org/patch/59824/raw/ [21:15:30 CET] <cehoyos> iive: Yes, but he didn't really know there were other issues. [21:17:16 CET] <cone-478> ffmpeg 03Michael Niedermayer 07master:c4ac30909e50: avutil/hwcontext: Remove duplicate ; [21:17:17 CET] <cone-478> ffmpeg 03Mark Reid 07master:f09449daa4f2: tests/fate: added dnxhr parser regression test [21:19:08 CET] <cehoyos> Before I forget: Has anybody else seen this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814807 [21:20:50 CET] <Compn> cehoyos : looks like persons' fate test sample is corrupted? [21:21:01 CET] <cehoyos> No, unfortunately not. [21:21:17 CET] <cehoyos> It looks reproducible between the last two runs. [21:21:20 CET] <Compn> ah [21:21:33 CET] <cehoyos> I suspect a gcc regression but who knows... [21:21:38 CET] <nevcairiel> we have mips fate and it passes there [21:21:49 CET] <cehoyos> With a different compiler. [21:21:54 CET] <cehoyos> Do we really test 2.8.6? [21:22:46 CET] <cehoyos> And with a different configure line [21:26:56 CET] <durandal_1707> I can't enable x11grab_xcb any more [21:29:04 CET] <jamrial> cehoyos: fate shows a couple 2.8.6 fate mips clients [21:29:52 CET] <jamrial> gcc 4.4, though. that debian report uses gcc 5.3 [21:31:03 CET] <michaelni> if its imgtec mips probably best to CC the imgtec people if its loongson mips CC the loongson guys [21:31:37 CET] <cehoyos> gcc-5_5.3.1-8 while gcc-5_5.3.1-7 worked well with FFmpeg 2.8.5 [21:31:54 CET] <cehoyos> I think it is older than imgtec vs loongson [21:32:47 CET] <michaelni> the question is what hw it is, the hw manufactor is likely interrested to have it working be that a compiler bug or other [21:33:50 CET] <cehoyos> There was a possibility to find out hw of Debian test systems, if I could just remember... [21:34:26 CET] <cone-478> ffmpeg 03Aman Gupta 07master:2f26b67d557f: lavc/ccaption_dec: do not ignore repeated character commands [21:34:27 CET] <cone-478> ffmpeg 03Aman Gupta 07master:5f5467e749f9: lavc/ccaption_dec: implement special and extended character sets [21:34:29 CET] <cehoyos> Imagination Technologies [21:34:49 CET] <RiCON> Timothy_Gu: "Environmnet" typo in fatebeta's header [21:36:34 CET] <cehoyos> Last successes were on the same imgtec hardware and on "Cavium Octeon V0.3" by Movidis [21:37:47 CET] <ubitux> cehoyos: --enable-libmp3lame x3 is fixed by the patch yes [21:37:57 CET] <cehoyos> Loongson are mipsel (at least for Debian) [21:38:04 CET] <cehoyos> ubitux: Yes, I had tested this. [21:38:25 CET] <ubitux> you said "The first one is (I assume, I did not test) fixed by the non-yet-committed patch" so.. [21:38:31 CET] <ubitux> i had to test [21:38:54 CET] <cehoyos> Sorry! [21:39:04 CET] <ubitux> - dash ./configure --enable-gpl --enable-x11grab [21:39:06 CET] <ubitux> x11grab cannot be enabled [21:39:06 CET] <cehoyos> I had tested it before the latest commit to configure [21:39:08 CET] <ubitux> :(( [21:39:21 CET] <cehoyos> It should not need --enable-gpl and it should be autodetected. [21:39:42 CET] <ubitux> it needs it [21:42:08 CET] <ubitux> x11grab was never autodetected btw [21:42:14 CET] <cehoyos> Sorry, but I found another regression: libxcb is not autodetected anymore afaict [21:42:15 CET] <ubitux> you might be mistaken with xcb [21:42:27 CET] <cehoyos> I mean: It is not autodetected anymore. [21:42:28 CET] <ubitux> well, that should be a good thing [21:42:32 CET] <ubitux> ;) [21:42:33 CET] <cehoyos> No? [21:42:45 CET] <ubitux> we talked about that one already, but whatever [21:42:49 CET] <cehoyos> That would be an undocumented unintended change of behaviour. [21:42:56 CET] <ubitux> i'm sticking with x11grab right now [21:43:06 CET] <ubitux> which is gpl, and always needed explicit enable [21:43:16 CET] <cehoyos> Of course, you are right. [21:43:44 CET] <cehoyos> Gtg, bye! [22:07:53 CET] <michaelni> Do any (known) issues remain after the 3 configure patches i just posted? [22:08:39 CET] <ubitux> michaelni: --disable-everything --disable-network now keeps some demuxer enabled [22:08:53 CET] <ubitux> (it wasn't the case before) [22:11:03 CET] <ubitux> michaelni: apparently, libxcb was also autodetected, which isn't the case anymore (but i don't care about that) [22:26:31 CET] <michaelni> what does the original patch fix ? [22:26:37 CET] <michaelni> i mean the merged one [22:31:16 CET] <michaelni> the code that causes the problem looks "unclean" to me, it kind of messes the dependancy solver up [22:32:15 CET] <michaelni> it looks almost like someone who doesnt understand the code is trying to "fix" it [22:32:34 CET] <michaelni> but i might be wrong [22:35:54 CET] <michaelni> does anyone have some testcases or something to test configure ? [22:38:53 CET] <ethe> how does configure do the check_func, is there a way I can insert a macro depending on the OS for a specific function? [22:40:38 CET] <ethe> I'm trying to have an optional check for a function depending on the OS [22:41:32 CET] <ubitux> ethe: how about adding it to the SYSTEM_FUNCS list? [22:41:55 CET] <ubitux> michaelni: adding regressions tests for configure sounds like a good idea [22:42:12 CET] <michaelni> ubitux, yes that would be a very good idea [22:42:22 CET] <ubitux> no idea about the original patch [22:42:31 CET] <ethe> ubitux: what does that do? [22:42:44 CET] <ethe> Maybe it'd help to explain what I'm actually trying to do [22:42:57 CET] <nevcairiel> running configure takes ages on windows, please dont =p [22:43:09 CET] <ubitux> nevcairiel: haha :) [22:43:27 CET] <ubitux> ethe: it will test the existence of the function X and will define HAVE_X if so [22:43:43 CET] <ethe> oh. thanks [22:44:03 CET] <ubitux> if you don't consider it a "system function", see how HAVE_LIST is built [22:44:12 CET] <ubitux> you might find another list more appropriate [22:45:27 CET] <ubitux> nevcairiel: maybe we could extract the whole enable/disable logic, and test it in standalone [22:45:47 CET] <ubitux> that should be instant, since no fork or whatever would be involved [22:46:50 CET] <ethe> although I still dont think that is the right solution; I've fixed issue #43, but you need to remove the non-osx sem_timedwait from line 2793 & 5755 to make it configure. What would be ideal is a way to change sem_timedwait checking to checking for dispatch_semaphore_wait if it's OSX (I'm also checking is this is in other OSes as well, I think it may be in FBSD) [22:47:24 CET] <ethe> if dispatch_semaphore_wait is in* [22:47:42 CET] <ubitux> michaelni: http://pastie.org/pastes/10726341/text [22:49:33 CET] <ubitux> sounds weird that sem_timedwait is tested that way [22:50:10 CET] <ubitux> maybe it should be in BUILTIN_LIST [22:50:27 CET] <ubitux> with the other atomic, membarrier and friends [22:55:02 CET] <iive> michaelni: carl asked quite significant question about these configure changes... what are they fixing/improving. [23:16:12 CET] <ethe> ubitux I'm guessing that any function in the BUILTIN_LIST also gets a HAVE variable set? [23:16:57 CET] <ubitux> yes, they end up in the sale HAVE_LIST in the end [23:17:10 CET] <ubitux> and there is no other usage afaict [23:37:17 CET] <ethe> this is what I have so far: https://gist.github.com/anonymous/eb759174e887a6ddb765 at the moment HAVE_DISPATCH_SEMAPHORE_WAIT isn't actually set to 1 (although I'm not sure why), but if you manually set it, then it all works. [23:40:13 CET] <ubitux> because it's not tested with the dispatch include at configure time probably [23:40:23 CET] <ubitux> (you can check the config.log) [23:41:21 CET] <ubitux> testing for the presence of the include could work, right? [23:42:45 CET] <ethe> yes [23:42:54 CET] <ubitux> like, maybe just add dispatch_dispatch_h to the HEADERS_LIST and add a check_header dispatch/dispatch.h along with the other [23:43:06 CET] <ubitux> then you'll have a HAVE_DISPATCH_DISPATCH_H which you can check [23:45:01 CET] <ethe> and leave sem_timedwait in BUILTIN_LIST? [23:57:23 CET] <ubitux> ethe: i guess [23:57:51 CET] <ubitux> ethe: your patch looks wrong though, because jack will fail to compile [23:57:57 CET] <ubitux> even if configure passes [23:58:08 CET] <ubitux> so you need to somehow keep the dependency mechanism [23:59:14 CET] <ethe> yeah, if both HAVE_SEM_TIMEDWAIT and HAVE_DISPATCH_SEMAPHORE_WAIT are 0 [23:59:24 CET] <ethe> well it'd be HAVE_DISPATCH_DISPATCH_H now. [00:00:00 CET] --- Thu Feb 18 2016

1 0

ffmpeg.log.20160217
by burek 18 Feb '16

18 Feb '16

[00:00:00 CET] <J_Darnley> What CPU does that machine have? [00:00:18 CET] <TD-Linux> yeah basically, if -speed 7 is still too slow for you [00:00:38 CET] <cyphix> Intel(R) Atom(TM) CPU N2800 @ 1.86GHz, 4 CPU [00:00:42 CET] <TD-Linux> rip [00:00:45 CET] <kepstin> lol, an Atom? [00:01:04 CET] <kepstin> yeah... good luck with that. It's never gonna be fast. [00:01:12 CET] <interrogator> how to download youtube-videos with ffmpeg ? im a new ffmpeg intruder [00:01:14 CET] <cyphix> Ah. Damn. [00:01:34 CET] <J_Darnley> interrogator: don't. use youtube-dl [00:01:44 CET] <kepstin> interrogator: you probably want to try the 'youtube-dl' tool (which does use ffmpeg for some parts) [00:01:47 CET] <TD-Linux> you could MAYBE try libvpx 1.5.0 and vp9 with threaded encodes at a really high speed setting [00:03:28 CET] Action: TD-Linux used an overclocked atom as a desktop for half a year [00:03:41 CET] <interrogator> thanks guys [00:04:13 CET] <cyphix> TD-Linux: What's vp9? [00:04:34 CET] <kepstin> cyphix: new and improved version of vp9 [00:04:39 CET] <kepstin> er, of vp8 [00:04:50 CET] <kepstin> supposed to compete with h265, apparently. [00:04:56 CET] <TD-Linux> cyphix, a newer video codec than vp8 which you are using [00:05:01 CET] <TD-Linux> also in libvpx [00:05:06 CET] <J_Darnley> Surely vp9 won't be quicker than vp8 [00:05:28 CET] <furq> it won't [00:05:38 CET] <TD-Linux> J_Darnley, well libvpx 1.5.0 can do threaded encode of vp9, so it *might* be with a really high -speed setting [00:05:52 CET] <furq> can it not do threaded vp8 [00:06:13 CET] <J_Darnley> Did they just abandon vp8 and let it rot in their library? [00:06:20 CET] <furq> cyphix: i take it you need webm and not mp4 [00:06:30 CET] <TD-Linux> no because I think it only does tile threading [00:06:44 CET] <furq> for webm your only options are vp8 and vp9 [00:06:44 CET] <TD-Linux> and vp8 doesn't have tiles [00:07:15 CET] <TD-Linux> x264 is not going to be spectacular on an atom either though. [00:07:20 CET] <cyphix> furq: yes [00:07:21 CET] <furq> it'll be better than vpx [00:07:48 CET] <TD-Linux> J_Darnley, mostly, though they still add speed improvements. tiles are a bitstream feature [00:08:09 CET] <TD-Linux> basically 100% of webrtc calls are vp8 [00:08:16 CET] <J_Darnley> Did they never invent frame threading? [00:08:20 CET] <J_Darnley> huehuehue [00:08:31 CET] <furq> but yeah using an atom as a transcoding server isn't going to work out well [00:08:53 CET] <jkqxz> If you can accept rather dodgy H.264 then your Bay Trail atom has a lot of hardware capability - 60fps transcode maybe. (*Support not yet present in ffmpeg, unfortunately.) [00:08:53 CET] <J_Darnley> libx264 and lame master race for ever! [00:08:57 CET] <TD-Linux> J_Darnley, I don't think it's in libvpx but I'm not totally sure. doesn't matter for any of Google's use cases [00:09:21 CET] <TD-Linux> because codec technology hit its peak in 2001 and will never improve :^) [00:09:48 CET] <jkqxz> When webrtc is the target use, frame threading doesn't make sense (the next frame isn't available when you want to encode the current one, so there is no parallelism). [00:09:51 CET] <TD-Linux> though technically lame was already worse than vorbis in 2001 [00:11:16 CET] <J_Darnley> Only if you try to encode a shit-tier stream [00:11:17 CET] <cyphix> it seems that libvpx 1.3 (the version I have) already has vp9 [00:11:25 CET] <furq> you mean x264 and -c:a copy [00:11:33 CET] <furq> cyphix: 1.3 doesn't support vp9 multithreading [00:11:48 CET] <furq> which means vp9 will definitely be much slower [00:11:51 CET] Action: J_Darnley goes away to prevent further trolling [00:11:52 CET] <cyphix> And I'm a bit afraid to install the 1.5 version from the unstable. But maybe I should [00:12:05 CET] <J_Darnley> Oh noes! Unstable! [00:12:14 CET] Action: J_Darnley really leaves [00:12:19 CET] <furq> install it from stretch [00:13:46 CET] <furq> installing packages from other repos is fine if you manually install the .deb to avoid pulling in conflicting deps [00:14:06 CET] <furq> that way when it all inevitably goes wrong, you'll be able to resolve it by removing one package [00:14:14 CET] <TD-Linux> well the ABI broke between 1.3.0 and 1.5.0 [00:14:26 CET] <furq> oh [00:14:53 CET] <furq> well then my expert advice, as your lawyer, is to upgrade to testing [00:15:01 CET] <interrogator> is there any url to have ffmeg compiled with all ffmeg known LIBs ? [00:15:10 CET] <TD-Linux> also 1.3.0 is from 2013 [00:15:23 CET] <furq> interrogator: http://ffmpeg.org/releases/ffmpeg-3.0.tar.bz2 [00:15:49 CET] <interrogator> is it for windows ? [00:16:00 CET] <furq> sure [00:16:06 CET] <interrogator> thanks [00:16:29 CET] <TD-Linux> cyphix, tbh my vp9 suggestion is kind of a long shot [00:16:38 CET] <TD-Linux> why do you need fast encodes? [00:16:48 CET] <TD-Linux> are you trying to transcode realtime? [00:17:51 CET] <cyphix> TD-Linux: Oh no. I don't even need amazing quality. It's just that if I want to upload a 10mn video on my mediacrush server, it takes... well... more than an hour, if it succeeds. That's not convenient at all. [00:18:31 CET] <cyphix> furq: I might consider change to gentoo instead :p [00:19:09 CET] <furq> if it's not some kind of important business production server then you should be running testing anyway [00:19:22 CET] <TD-Linux> cyphix, how much do you care about filesize? you could use theora [00:19:31 CET] <cyphix> furq: it's not indeed [00:19:33 CET] <furq> and it's easy enough to upgrade [00:19:34 CET] <TD-Linux> it's great for potatoes [00:20:05 CET] <cyphix> TD-Linux: You mean that it would be faster, but the resulting files would be bigger? I don't care at all about the size. [00:20:13 CET] <furq> the former [00:20:32 CET] <furq> i'm not sure why it insists on webm though [00:20:37 CET] <cyphix> Well.... it has to be viewable in streaming from a webpage. [00:20:52 CET] <TD-Linux> cyphix, yeah, maybe try theora, supported in the same browsers as webm [00:21:10 CET] <furq> mp4 is more widely compatible in browsers than webm [00:21:18 CET] <cyphix> TD-Linux: So I should replace libvpx by libtheora? [00:21:36 CET] <TD-Linux> cyphix, yes [00:21:44 CET] <cyphix> I'll try that [00:21:49 CET] <TD-Linux> probably also change container to .ogv [00:22:15 CET] <furq> and say goodbye to android support [00:22:16 CET] <cyphix> TD-Linux: What part of the command specifies the container? :/ [00:22:25 CET] <TD-Linux> the filename of the output [00:22:29 CET] <cyphix> These notions still confuses me a bit... [00:22:33 CET] <cyphix> ah ok [00:22:39 CET] <furq> cyphix: it guesses the container from the filename if you don't provide one [00:27:16 CET] <cyphix> So I tried this command: "ffmpeg -y -i tmpiQFeWX.mkv -c:v libtheora -speed 7 -c:a libvorbis -q:a 5 -pix_fmt yuv420p -quality good -b:v 5M -crf 5 -vf "scale=trunc(in_w/2)*2:trunc(in_h/2)*2" -map 0:v:0 -map 0:a:0 /var/www/mc.cyphix.org/MediaCrush/storage/h18uoUjcQ6o6.ogv" but I'm still at 2 fps... [00:31:21 CET] <cyphix> It seems definitely 2-3x faster with libvpx than with libtheora [00:32:27 CET] <TD-Linux> ok, well I guess vp8 got a lot of love :) [00:32:52 CET] <TD-Linux> also I don't know how speed settings map to libtheora [00:35:10 CET] <cyphix> Mkay. I think I'm too limited by the hardware of my server. Too bad... [00:52:05 CET] <utack> Hi. is the new version 3 "wrapped_avframe" in benchmark mode supposed to be slower than the previous "rawvideo" it decoded it to? [01:47:13 CET] <durandal_1707> utack: faster [01:47:46 CET] <utack> in that case i have bad news on my arch system, but i will wait for the final version in the community repo test again and make more than two tests [01:54:40 CET] <kbarry> I'm looking for an example of comparison of audio with and without the sofalizer filter. [02:21:22 CET] <Wader8> is it okay to talk about specific codec option tips but tied with my attempt at a custom config for batch processing of files for archival project, since #x265 looks like to be for development only [05:09:30 CET] <ThomQ> Hi all. IŽm trying to make a transparent Webm video from a series of PNGs. Now, for one series, the following code works absolutely fine: ffmpeg -i wow.wav -r 30 -f image2 -i wow%3d.png -vf fps -pix_fmt yuva420p -metadata:s:v:0 alpha_mode="1" -c:v libvpx -b:v 0 -crf 30 output.webm [05:10:06 CET] <ThomQ> But for another series of transparent PNGs, rendered the exact same way, I get weird blue artifacts / backgrounds, and stuttering near the end of the video [05:10:53 CET] <ThomQ> I just changed the names in that line, nothing else. Anybody any idea? [05:58:21 CET] <relaxed> ThomQ: that should be -framerate 30 [06:00:33 CET] <ThomQ> relaxed: it did seem to work though. What part should I change? [06:05:02 CET] <relaxed> -r 30 [06:05:25 CET] <relaxed> I'm not saying that's going to fix your issue [06:07:17 CET] <relaxed> ffmpeg -h demuxer=image2 [06:10:47 CET] <ThomQ> IŽve narrowed the problem down to the chromakeying. If not done very precisely (as in having small transparent outlines along the chromaŽed footage), results in major artifacts all over [06:10:56 CET] <ThomQ> They?e not visible in the PNGs though, ofcourse [06:12:21 CET] <ThomQ> -h demuxer=image2 instead of -f image2? [06:12:35 CET] <furq> no -h is help [06:12:49 CET] <furq> that shows all the private options for the image2 demuxer, but it sounds like the issue is with the source [06:15:19 CET] <ThomQ> yeah, i tried some more Heavy Duty chromaŽing, get rid of as much of the edges as i can. In the PNG the edges look very nice though, even when overlayd on a solid color. Its only after using FFMPEG the blue and now also red artifacts appear [09:52:24 CET] <termos> should the PTS of my audio and video packets be the same for the video to be in sync with the audio? [09:52:35 CET] <Mavrik> uhm [09:52:39 CET] <Mavrik> it should be in the same timebase. [09:53:02 CET] <Mavrik> But since your audio and video packets almost certanly don't represent same slices of time, they usually aren't exactly the same [09:55:49 CET] <termos> hm so they should be the same timebase [09:58:25 CET] <Mavrik> when encoded [09:58:31 CET] <termos> because I convert from stream_tb to codec_ts (this will differ between codecs I guess) when encoding and then back to output stream tb [09:59:01 CET] <Mavrik> yes [09:59:08 CET] <Mavrik> That's usually how you do it [09:59:57 CET] <termos> ok, that's good to know [10:00:50 CET] <termos> so before decoding + filtergraph + encoding: av_packet_rescale_ts(&in_packet.p, in_stream->time_base, in_stream->codec->time_base); [10:01:06 CET] <termos> before write_frame: av_packet_rescale_ts(&packet, stream->codec->time_base, stream->time_base); [10:25:41 CET] <termos> one strange thing I'm doing is having one thread that pushes to my filter graph and another thread pulling from it, could that lead to any issues? [10:26:14 CET] <termos> what I'm seeing now is some syncing issues for some streams [10:28:53 CET] <durandal_1707> what your filtergraphs looks like? [10:39:54 CET] <termos> the filter string is pretty long and out of order but for video it's: buffer -> yadif -> fps -> scale -> buffersink [10:41:52 CET] <termos> for audio it's: aeval=val(0)*1.000000|val(1)*1.000000,aformat=sample_fmts=s16:channel_layouts=stereo,aresample=44100,asetnsamples=n=2048:p=0 [11:15:29 CET] <Wader8> Hello, any HEVC GPU Acceleration supported for latest ATI Radeon GPUs (R7 370 latest OpenCL DC and DX12) [11:15:47 CET] <Wader8> or just nvenc ? [11:29:01 CET] <jkqxz> Wader8: VAAPI/VDPAU H.265 decode should work on those, I think. No encode support. [11:30:02 CET] <Wader8> jkqxz, that's for the heads up, unfortunately I need encode, building an archive [11:30:07 CET] <Wader8> thanks* [11:33:50 CET] <fritsch> only hevc 8 bit, though [12:12:57 CET] <Wader8> fritsch 8bit ? [12:15:13 CET] <fritsch> Wader8: hevc exists in 8 10 12 14 bit [12:15:52 CET] <Wader8> and that would mean what ? sorry I haven't got that far with my research, started 2 days ago [12:20:17 CET] <jkqxz> Wader8: Higher-quality streams with greater than eight bit sample depth will not decode on that AMD hardware with current software. This is mostly an irrelevant problem for now because almost everything is still eight bit, but it will become more of a problem in future. [12:22:04 CET] <Wader8> oh you mean color, well most of it is historical videos, even if it would be 10 bit, color quality is the least important thing [12:22:31 CET] <Wader8> well in some cases it would be but quite rare [12:22:37 CET] <at0m> Wader8: been looking hw accel for a bit too, seems that conflicts with X, so better on headless machines [12:22:54 CET] <Wader8> conflicts with X? [12:23:03 CET] <at0m> Wader8: and nvenc is obviously for nvidia cards (that support cuda) [12:24:08 CET] <at0m> https://trac.ffmpeg.org/wiki/HWAccelIntro is where i went from [12:26:23 CET] <at0m> maybe check if your intel CPU (if that's what you got) is listed at http://ark.intel.com/search/advanced?s=t&QuickSyncVideo=true and go for qsv [12:33:27 CET] <Wader8> at0m i have i7-3820 and there are some with QM at the end, but this naming system is very confusing to me I don't like it, so many similar names in the last 3-4 years for intel CPUs, basically i have Sandy Bridge E , the one without IGPU [12:33:47 CET] <Wader8> so this one is not on the list i guess [12:36:33 CET] <at0m> Wader8: lscpu | grep Model [12:36:42 CET] <at0m> it'll say there [12:36:57 CET] <Wader8> what does that mean ? [12:37:33 CET] <at0m> for example on this laptop, i see "i5-3230M" which is in that list [12:37:34 CET] <Wader8> em, I've bought this PC in 2013, since then I've been out of the loof from hardware [12:37:59 CET] <Wader8> and this was early 2013, i just followed Mantle, CES and AMD GPU stuff, that's about it [12:37:59 CET] <at0m> even my core2duo is there, it's way older [12:38:31 CET] <Wader8> LSCPU .. never heard of that [12:39:01 CET] <at0m> lscpu lists cpu info [12:39:11 CET] <at0m> assuming you run linux [12:39:18 CET] <Wader8> Win7X64 [12:39:20 CET] <at0m> oh [12:39:45 CET] <Wader8> i have Mint debian and Win10 on another drive but so far only for small stuff testing, it's not on SSD so it's slow [12:40:15 CET] <Wader8> no it's just Mint, not debian, afaik [12:40:33 CET] <at0m> not sure how windows goes about displaying CPU info and stepping etc [12:43:30 CET] <Wader8> well yes I said it's i7-3820 that's the name, now, the family is Sandy Bridge-E, Family 6, Stepping 7, Model D, Ext. Model 2D, Revision C2 , instructions, VT-X, AVX. EMT64T, AES, MMX and 7 SSEs [12:44:00 CET] <Wader8> 32nm [12:44:08 CET] <Wader8> LGA 2011 [12:45:00 CET] <jkqxz> That's not a desktop CPU at all, it's a nobbled Xeon E5. Therefore it doesn't have any hardware for graphics or video at all. [12:45:23 CET] <Wader8> jkqxz, did i say it does ? [12:45:34 CET] <Wader8> I know, i didn't want any video at the time [12:45:43 CET] <Wader8> this one was cheaper [12:45:53 CET] <at0m> Wader8: we're just trying to find out if your CPU supports QSV [12:46:06 CET] <Wader8> probably not since I never heard of that [12:46:31 CET] <at0m> Wader8: so it would do hardware encoding. and seems ATI doesn't support it either, so there you go. [12:47:07 CET] <at0m> Wader8: i hadn't heard of it till i started to look for hw accelerated encoding [12:47:43 CET] <Wader8> Sandy Bridge E family doesn't have GPU, it's just CPU, I wanted an i7 but I didn't want the GPU, and I usually pick the top market but pick the lowest , so this is the lowest i7 which cost like 250 Euro, anything up was 500 Eur which I would never pay for a CPU [12:47:57 CET] <at0m> still, without hw accel you should be able to do 8-10x realtime encoding [12:48:38 CET] <jkqxz> Pretty much all recent desktop/mobile Intel has the hardware for encoding and decoding. In Sandy Bridge / Ivy Bridge generations they played some games with disabling it on certain models, but they've given up on that now. [12:49:13 CET] <Wader8> well i'm planning to use very-slow preset for maximizing quality and low size, (keeping same quality at a smaller size) [12:49:39 CET] <Wader8> to better use my archive space of 2+2TBs [12:50:18 CET] <Wader8> can the GPU inside be disabled by BIOS option ? [12:50:34 CET] <Wader8> probably has separate clocks no ? [12:51:06 CET] <at0m> Wader8: you don't have a 'GPU inside' [12:51:18 CET] <Wader8> i didn't knew GPU inside would help for video transcoding, i just wasn't thinking about that at the time [12:52:18 CET] <jkqxz> If your target is output quality/size rather than transcode speed, hardware is not a sensible thing to use anyway. [12:53:05 CET] <Wader8> Would be slower ? [12:53:58 CET] <at0m> Wader8: yes, but neither your videocard nor cpu support hw transcoding. so it's not an option at all. [12:54:43 CET] <jkqxz> The result is /much/ worse from hardware encoders compared to x26[45]. The only reason to use them is if you need high encoding speed. [12:56:58 CET] <at0m> i'm looking at a project that required to transcode maybe 100s of streams in realtime. so pursuing the hw accel path... [12:57:41 CET] <Wader8> Well I don't have a problem leaving it at night, i will make batch processes completely customized for what I need, it's just if it takes .... 3DAYS to finish one video it's a bit of a weird, but I guess one or two such cases won't be that bad, most of the videos are small, below 500 MB, some are 10-15 GB but only a hanful and some of those are "professionally" encoded not sure if i'll have... [12:57:42 CET] <Wader8> ...the time to fiddle with HEVC params just to lower a few GBs but also weaker quality,, plus x265 not being as mature as x264 but im not even sure if maturity right now is only for performance or also featureset, but i heard lookahead isn't done yet, any other major thing that can affect quality and size that aren't finished in x265, i did look on official site, i just don't understand half... [12:57:44 CET] <Wader8> ...the coding talk [12:58:35 CET] <Wader8> well alot of them are below 100 MB also [12:59:07 CET] <at0m> Wader8: like i said, even without hw acceleration you should get about 10x realtime encoding [12:59:54 CET] <Wader8> based on what you say that ? [12:59:58 CET] <at0m> i can do maybe 6 here in realtime on the laptop [13:01:03 CET] <Wader8> because I was using all kidns of transcoding and H264 was always the slowest for me on anything below middle [13:01:13 CET] <Wader8> iand I was doing MPEG also [13:01:32 CET] <Wader8> maybe I was using bad codecs, i forgot, [13:01:40 CET] <Wader8> choice [13:02:53 CET] <at0m> if i use 1080p input streams, transcoding goes down a lot, i can do maybe 2, 3 in realtime [13:03:02 CET] <Wader8> well i was using libx265 in one ocassion [13:03:09 CET] <at0m> so depends on the source material, too [13:03:25 CET] <at0m> outputting 720p [13:03:27 CET] <Wader8> 3 months ago, i did a lot of work between, kinda forgot let me check out [13:04:26 CET] <Wader8> well one video it was hard, DVDs, i have to deal with them being interlaced and having weird pulldowns and well i spend like a week trying to put one of them into x265 properly i did it, took like 11 hours on MEDIUM [13:05:10 CET] <Wader8> 12.4 hours [13:05:15 CET] <Wader8> 3.4 FPS average [13:05:23 CET] <Wader8> output size 1.2 GB [13:05:43 CET] <Wader8> input size 4GB (VOB) [13:06:11 CET] <Wader8> ffmpeg version N-76137-gb0bb1dc [13:08:40 CET] <Wader8> sorry i'll just pastebin it [13:11:00 CET] <Wader8> at0m so here's what happened last time 3 months ago, note x265 version too, i think 1.9 now, it was 1.8 at the time [13:11:02 CET] <Wader8> http://pastebin.com/UCaaB3j3 [13:11:51 CET] <Wader8> sorry, the preset was SLOW, not medium, i had 2 config candidates and I used the CRF one (rate factor) [13:12:58 CET] <Wader8> so for my archival work, most of the videos are X264, so if it has to decode X264 (this was MPEG2) and if I use very-slow, isn't that going to be like super slow then ? [13:13:06 CET] <at0m> the "-preset slow" will have quite an impact on the speed, obviously. i'd try skipping that and using default, or even 'faster', on smaller files, and then check the difference in results [13:13:20 CET] <Wader8> so I don't get where you get 6-10 times the realtime from ? [13:13:37 CET] <at0m> if you're encoding old VHS recordings for example, you might maybe not even notice the difference [13:14:23 CET] <kevmitch> is there any reason to link to libdcadec anymore? [13:14:25 CET] <at0m> experiment with a bunch of different settings, on smaller size source file [13:15:26 CET] <Wader8> oh sorry this probably isn't a fair comparrison because this was one exception with the interlaced mess, you can see a lot of additional filters used, most of the videos are all progressive and clean of these ancient methods [13:15:26 CET] <eynix> Hi, I have a question regarding the usage of ffmpeg lib in a propritary software. I read in the legal FAQ : "Notably, MPEG LA is vigilant and diligent about collecting for MPEG-related technologies. ". Does this mean that my company should give money to MPEG LA ? (sorry my english is not really good) [13:19:35 CET] <Wader8> well the results I'm showing you in the pastebin are from a successful run, the size got decreased by 75% at minimal quality loss, obviously MPEG2 does look a bit better in the original, i probably couldn't have made it better because I had to convert it into progressive and get rid of pulldowns and telecines and it was really a headache getting the config just right to get the output... [13:19:36 CET] <Wader8> ...working, cuase anything else produced playback issues [13:20:07 CET] <Wader8> in terms of HEVC speed, it a bad example, but I don't have any other example at the moment [13:20:15 CET] <blarghlarghl> Hi all. I have a question about streaming via RTMP(S). I have a phone. It has a live streaming app (Broadcast Me, for example.) On this phone, I can type in an address to my RTMP(S) server and then hit 'record.' I would like to have ffmpeg or ffserver or whatever sit at that address and receive that stream and save it to disk. How can I do that? [13:21:10 CET] <jkqxz> eynix: Quite possibly - you should look for actual legal advice to answer that question. (I believe that it is dependent on many things, notably sales volume and location, so there are no useful general remarks we can make.) [13:21:32 CET] <eynix> jkqxz: thank you [13:21:41 CET] <blarghlarghl> Or rather - is it even possible? [13:22:00 CET] <blarghlarghl> All I can find is the other way around - ffmpeg can accept a URI to an RTMP(S) stream and then save it. [13:22:08 CET] <blarghlarghl> That's not useful for me though, I think. [13:22:43 CET] <at0m> blarghlarghl: https://en.wikipedia.org/wiki/Nginx-rtmp-module [13:23:20 CET] <blarghlarghl> at0m: Yeah, I use that, but I'd rather ... not. [13:23:46 CET] <blarghlarghl> at0m: Isn't it possible to reimplement this using ffserver or ffmpeg? [13:24:08 CET] <blarghlarghl> All it needs to do is sit and listen on a port and save what it gets... [13:24:25 CET] <blarghlarghl> (Okay, that's not true. But you get my point.) [13:24:27 CET] <at0m> blarghlarghl: i have no idea. i did get a feel that ffserver is frowned upon here [13:25:30 CET] <at0m> ... so i'd stick to ffmpeg instead [13:25:30 CET] <blarghlarghl> Oh. [13:26:12 CET] <blarghlarghl> at0m: Okay, sure, so how do I do this in vanilla ffmpeg? :) [13:26:56 CET] <at0m> blarghlarghl: i pointed you in a direction i use and know which works. feel free to hint me on what you come up with as alternative ;) [13:27:15 CET] <Wader8> at0m, what about VP9 and WEBM, since Youtube's not going to support H265 from what I hear, and they say VP9 is faster in FFMPEG also, so if youtube cuts HEVC, what's the point of me DLing H264 and then putting to HEVC if VP9 is good enough I could do directly that, but there's a question of future proof, is VP9 that future proof ? but there's another thing, inside WEBM not everything is VP9,... [13:27:16 CET] <Wader8> ...old videos are probably still in VP8, and I want to have some order in my archive, not a bunch of codecs, I rather have just one or two [13:28:10 CET] <blarghlarghl> at0m: We already use nginx-rtmp in our testing infra as a spike. Now we're rewriting it to support rtmps, and I'm taking the opportunity to see if there are cleaner ways of doing it :) Sadly it looks like we're coming up empty :( [13:30:08 CET] <at0m> just to go to rtmps? can't you just reverse proxy that, or stunnel? [13:38:49 CET] <blarghlarghl> at0m: no, not just for rtmps. for actually getting it right. second iteration is always better than the first ;) [13:44:03 CET] <Mavrik> blarghlarghl, ffmpeg isn't a streaming server but a transcoding tool [13:44:06 CET] <Mavrik> And you need a streaming server. [13:44:17 CET] <Mavrik> ffserver is a streaming server but it's a mess of unmaintained obsolete code [13:44:26 CET] <Mavrik> So use nginx-rtmp-server, it's the right tool for the job [13:44:38 CET] <Mavrik> Or use Wowza or similar product. [13:45:01 CET] <blarghlarghl> Mavrik: yeah, i'm considering red5. [13:45:13 CET] <blarghlarghl> it supports rtmps out of the box, then i don't have to faff about with stunnel or whatever. [15:45:23 CET] <oldcode> is checking the return value of av_read_frame for AVERROR_EOF the best way to test if the video is complete? [16:23:18 CET] <kbarry> I've never compiled from source before. I'm hoping to get the sofalizer filter into a build, for windows. [16:25:48 CET] <J_Darnley> You can start by reading http://trac.ffmpeg.org/wiki/CompilationGuide [16:35:14 CET] <eynix> is there a "free" encoding format ? [16:35:24 CET] <eynix> as in "you don't pay royalties to anyone" [16:35:53 CET] <at0m> "but you want to use it for commercial projects" ? [16:36:08 CET] <eynix> at0m: yes [16:37:11 CET] <eynix> at0m: also, since the feature using the encoding format is really small compare to the product, i'm unsure about if we still need to pay royalties.. [16:39:38 CET] <J_Darnley> eynix: then you'd better go oldschool and use something like mpeg3 [16:39:45 CET] <J_Darnley> uh mpeg1 [16:39:46 CET] <eynix> this is completely new to me, sorry if those questions are stupids ^^' [16:40:03 CET] <kbarry> J_Darnley: I am having some trouble following the guides on th elink above. [16:40:24 CET] <J_Darnley> Well which one are you trying to follow? [16:40:31 CET] <J_Darnley> MSVC or Mingw? [16:40:55 CET] <J_Darnley> eynix: the amount of royalites you might have to pay someone depends on who you're paying. [16:41:12 CET] <J_Darnley> the h264 patent pool is quite well defined [16:41:35 CET] <kbarry> CompilationGuide/MSVC , But I think i will try to cross-compile. [16:41:46 CET] <J_Darnley> Wait, are you on Windows or not? [16:42:08 CET] <eynix> J_Darnley: I though MPEG-3 and 4 was done by the same people, so we still needed to pay royalties [16:42:18 CET] <eynix> to MPEG LA [16:42:33 CET] <J_Darnley> All patent on mpeg1 have probably expired by now [16:43:13 CET] <eynix> J_Darnley: do you know about motion jpeg ? [16:43:13 CET] <J_Darnley> You should be asking your lawyer these questions [16:43:46 CET] <J_Darnley> theora's another choice for "patent free" [16:43:57 CET] <eynix> J_Darnley: thank you for your help. It's a rather small company, I don't believe we have any lawyer. [16:44:12 CET] <kbarry> I am on windows, But have access to linux. [16:44:46 CET] <eynix> J_Darnley: Theora seems perfect ! I didn't know about it ! looking into it [16:45:05 CET] <J_Darnley> I don't know which a newbie will find easier to be honest, setting up a dev environment on Windows or cross-compiling from linux. [16:45:13 CET] <ritsuka> if your software runs on mac os x or windows you can probably use the system build-in video libraries, and the royalties should be already paid by apple and microsoft. [16:45:15 CET] <kbarry> eynix: It is in your best interest to consult legal counsel, be it an in-house legal staff member, or an attorney on retainer. Chances are, you company has a lawyer [16:45:44 CET] <kbarry> hahaha, right [16:45:51 CET] <kbarry> Well, I don't know either, [16:45:55 CET] <J_Darnley> Indeed. I'm just some arsehole who thinks software can't be patented. [16:46:04 CET] <eynix> ritsuka: can you give me an example ? [16:46:32 CET] <kbarry> expecially because the linux i'd probably be using centos 6.5, which isnt the most easy thing to build ffmpeg for. [16:49:24 CET] <ritsuka> eynix: for example avfoundation on os x or directshow or whatever on windows. firefox for example does use them, so it can playback h.264 and aac without paying a $ [16:50:15 CET] <eynix> ritsuka: I'm not sure to get it, but I'll look into it. thank you very much. [16:53:15 CET] <eynix> ritsuka: ... oh, so encoding can be done using only the OS API. [16:53:21 CET] <eynix> and without paying. [16:53:31 CET] <eynix> this is a great solution [17:00:39 CET] <furq> eynix: vp8 and vp9 are probably your best modern choice [17:00:58 CET] <furq> those are royalty-free but it's not impossible that they could be found to be using patented technology [17:01:43 CET] <furq> mpeg-la claim to be creating a patent pool to use against vp8/vp9, but they said the same thing about theora and that never happened [17:01:57 CET] <eynix> furq, I'll look, thanks. Currently, I'm looking in Theora. I wonder if I can encode images in a vids with it. Like the motion jpeg thing [17:02:31 CET] <eynix> but hm, by the way. [17:02:35 CET] <eynix> those patent [17:02:41 CET] <eynix> are patent to code, right ? [17:02:55 CET] <eynix> since, I'm in EU, does this apply ? [17:03:00 CET] <eynix> damn, I need a lawyer. [17:03:07 CET] <furq> are you doing business with the US [17:03:12 CET] <eynix> probably [17:03:20 CET] <eynix> yes, we are [17:03:26 CET] <furq> then yeah, i think it does [17:03:34 CET] <furq> although it probably makes it less likely that anyone will come after you for it [17:04:29 CET] <eynix> this is so complicated. I just want to make a movie from my images TT__TT [17:06:01 CET] <J_Darnley> Then say "fuck imaginary property" [17:06:13 CET] <furq> if you're a small business you probably fall under the minimum usage exemption anyway [17:06:28 CET] <eynix> what's that ? [17:09:56 CET] <furq> with h265 at least you can ship 100,000 units per year, which afaik either means h265 videos or products that encode h265, without paying royalties [17:10:04 CET] <furq> idk if something similar exists for h264 [17:10:30 CET] <furq> unless they changed the licence again since i last read it, which isn't unlikely [17:11:41 CET] <furq> you're probably best off sticking with webm though [17:13:04 CET] <Venti> mpeg-la isn't the only party holding patents on obvious things, and not even the only party accepting money for hevc [17:13:58 CET] <zeryx> hey guys, I'm looking to build a wrapper that can split a video into multiple intervals (currently using -ss & -t iteratively), but it doesn't seem to split accurately [17:14:09 CET] <zeryx> I'm looking to recombine the videos later in a stitching operation, but I don't want repeated frames [17:14:14 CET] <zeryx> is there a way to do this with ffmpeg? [17:14:36 CET] <furq> zeryx: -ss isn't frame accurate with -c copy, it'll split at the nearest keyframe [17:15:20 CET] <zeryx> furq, ahh, so what I should do is gather the keyframes of the video and cut at those times instead of cutting at an arbitrary time right? [17:15:23 CET] <furq> right [17:15:25 CET] <zeryx> is there a way to do that with ffmpeg or would I need ffprobe? [17:15:35 CET] <furq> https://www.ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_… [17:15:38 CET] <furq> that might work for you as well [17:15:48 CET] <zeryx> I was looking at refactoring that in actually [17:16:13 CET] <furq> that always splits at the next keyframe so you won't get repeated frames [17:16:18 CET] <zeryx> is there a way to alter the output metadata in the filename from an iterator to a keyframe interval? [17:16:22 CET] <zeryx> nice [17:16:31 CET] <zeryx> I know the split to images works great with the FPS arg [17:17:47 CET] <zeryx> I still don't know why I don't always join irc instead of searching SO for 4 days, its almost always faster :D [17:17:55 CET] <zeryx> thanks a ton furq [17:29:11 CET] <zeryx> furq, is segment_time's input in seconds or ms? [17:29:26 CET] <zeryx> and does it accept the regular HH:MM:SS.mm format as well? [17:31:48 CET] <furq> seconds and yes [17:32:21 CET] <pkeuter> hey guys, i know there's a black detection in ffmpeg, is there also a way to detect motion, or the lack thereof? [17:33:54 CET] <durandal_1707> see tblend [17:35:43 CET] <pkeuter> thanks! [17:57:47 CET] <zeryx> furq, ok cool that seems to have worked, but the resulting videos seem to be missing some metadata (IE: when the clip is over, when it starts) vlc player seems to start in the center of the video [17:57:55 CET] <zeryx> is that normal or is there a way to solve that by resetting the headers or something? [18:06:05 CET] <zeryx> can force_keyframes accept an interval parameter instead of a list of times? [18:07:27 CET] <DHE> for an interval I just use "-g 300" and then disable automatic keyframe generation. (x264 option is no-scenecut) [18:08:24 CET] <zeryx> DHE, -g? I haven't see that command before, I was initially trying -ss & -t however I need accurate cutting so I can stitch video segments back together [18:09:20 CET] <DHE> that doesn't sound like the response I expected... [18:10:03 CET] <zeryx> now using force_keyframes & segment_time commands [18:10:40 CET] <zeryx> creating a tool that can do work on small accurately segmented components of a video, and then stitch them back together into a coherent video [18:15:49 CET] <DHE> ah, and you want the segments to be of consistent size for the initial splitting... [18:16:04 CET] <DHE> yeah, the above is what I do. I've use HLS which is a narrow version of that [18:47:21 CET] <EmleyMoor> To create my "front view stamped" dashcam videos, I currently use three calls to ffmpeg - two crops and a vstack. Is there any way to combine them? [19:01:31 CET] <DHE> should be.... something like: ffmpeg -i input1.mp4 -i input2.mp4 -filter_complex "[0:v] crop=... [top]; [1:v] copy=... [bottom] ; [top][bottom] vstack [output]" -map '[output]' -map 0:a $CODEC_OPTIONS output.mp4 [19:01:57 CET] <DHE> audio is taken from input1.mp4 in this example [19:11:54 CET] <kepstin> EmleyMoor: if you have a single video input that you're taking two cropped sections from, change DHE's command to drop the second -i and change the '1:v' to '0:v' in the filter_complex string [19:12:48 CET] <DHE> .. changing a side-by-side video into a vertical stack video? [19:14:23 CET] <durandal_1707> see stereo3d filter [19:18:26 CET] <Filarius> how to make FFmpeg try to reconnect to live stream while recording if stream laggy or can be turned off for short time and turned on again ? [19:34:25 CET] <zeryx> if I wanted to force a keyframe every X interval of miliseconds, how would I do that without needing to escape double quotes? [19:34:45 CET] <zeryx> expr:gte(t, n_forced*$interval) errors out, and seems to require double quotes to work [19:37:13 CET] <zeryx> Unable to find a suitable output format for 'n_forced*1.000) [19:37:25 CET] <zeryx> -force_key_frames 'expr:gte(t, n_forced*$interval)' [19:39:13 CET] <zeryx> rofl [19:39:29 CET] <zeryx> expr:gte(t,n_forced*$interval) works, expr:gte(t, n_forced*$interval) doesn't [19:41:43 CET] <zeryx> ok so I'm cutting with exactly 1 second intervals and creating timestamps at 1 second, however my video lengths are around 4 seconds long, thoughts? [20:00:38 CET] <furq> zeryx: if you're not reencoding then your gops are probably 4 seconds long [20:04:46 CET] <zeryx> furq, I'm copying the encoding from the original, but I'm also trying to force keyframes at the timestamps that I plan to cut from [20:05:05 CET] <zeryx> I want 100 millisecond accuracy on my cuts, but right now I'm getting like 5-6 seconds minimum [20:05:20 CET] <Mavrik> um [20:05:22 CET] <zeryx> plus the duration of my videos are all wrong, they don't reset properly [20:05:36 CET] <furq> yeah that's not a thing [20:05:39 CET] <Mavrik> you're copying the stream_ [20:05:46 CET] <Mavrik> and you want to force keyframes? [20:05:51 CET] <furq> if you're copying the stream then you get the keyframes that are in the original stream [20:06:07 CET] <furq> if you want them in different places then you need to reencode [20:06:20 CET] <zeryx> /tmp/ffmpeg-static/ffmpeg -i /tmp/counting.webm -force_key_frames interval -c copy /tmp/7fd19e99-7fad-4010-9a43-3aaa186087ee/formattedInput.webm -y [20:06:23 CET] <zeryx> that doesn't work? [20:06:27 CET] <furq> no [20:06:36 CET] <DHE> you can't specify keyframes when copying pre-encoded material [20:06:49 CET] <DHE> you need to use "-c:v libx264" or something [20:07:10 CET] <furq> just get rid of -c copy and it'll use vp9 [20:07:20 CET] <furq> -c:a copy should be ok [20:07:37 CET] <zeryx> good thing I asked you guys, would literally never figure that out [20:09:33 CET] <jas99> hey guys [20:09:34 CET] <zeryx> ok this is getting disgusting, I'm trying to create a universal video splitter + concentate tool for computer vision tasks [20:09:45 CET] <jas99> new here [20:09:53 CET] <jas99> new at even using irc [20:10:12 CET] <zeryx> my webm sample video file doesn't allow for those codecs, I'm assuming there's no universal video encoding that can be used [20:10:18 CET] <zeryx> yo jas99 [20:10:29 CET] <jas99> hey zeryx [20:11:02 CET] <jas99> is this right channel to discuss c++ coding with ffmpeg [20:11:10 CET] <jas99> or that will be dev one [20:11:24 CET] <zeryx> I think it's more of a "just ask a question" channel than anything else [20:11:41 CET] <croepha> so, when streaming from a file? how can I tell ffmpeg to stream the file at a steady pace (1 second of video for 1 second of time) currently it acts like an upload, and tries to upload as fast as bandwidth seems to allow [20:11:57 CET] <jas99> i am trying to encode 16bit gray video [20:12:30 CET] <jas99> hey zeryx [20:12:38 CET] <jas99> so people help each other here [20:12:46 CET] <jas99> or some devs live here?? [20:13:08 CET] <furq> zeryx: -c:v libvpx-vp9 [20:13:09 CET] <zeryx> yeah jas99 what you do is you actually just ask a question [20:13:16 CET] <furq> it should use that automatically if you don't specify a codec [20:13:50 CET] <furq> you probably also want -b:v 0 -crf 30 or similar so that it doesn't encode at 200kbps [20:13:51 CET] <jas99> so i do ffv1 encoding [20:13:57 CET] <jas99> for gray16 [20:14:08 CET] <furq> croepha: -re as an input option [20:14:27 CET] <jas99> on muxing.c [20:14:31 CET] <croepha> furq, ok, Thanks alot! [20:14:33 CET] <jas99> example [20:14:56 CET] <jas99> by editing config off course [20:15:41 CET] <furq> 19:09:34 ( zeryx) ok this is getting disgusting, I'm trying to create a universal video splitter + concentate tool for computer vision tasks [20:15:44 CET] <furq> oh. [20:15:46 CET] <furq> yeah that's going to be difficult [20:16:05 CET] <zeryx> like, everything works except this [20:16:08 CET] <zeryx> absolutely everything [20:16:21 CET] <zeryx> I actually thought it was working reasonably correctly until I realized I couldn't enforce splits smaller than the video keyframe [20:16:21 CET] <furq> a segment generally needs to start with a keyframe, so splitting at arbitrary points is going to get very complicated [20:17:00 CET] <zeryx> yea [20:17:07 CET] <jas99> sorry you guys were talking i guess sorry to be rude :) [20:17:17 CET] <zeryx> this is for a very large work project, this is a foundation [20:17:23 CET] <furq> if it's for splitting and concatenating you might want to use a lossless codec for the segments and then reencode it when you're done [20:17:45 CET] <zeryx> I would love to do that, the docs aren't the easiest to read for stuff like this [20:18:03 CET] <furq> that'll obviously take a bunch of space and ideally you'd have the user provide the final encoding settings [20:18:07 CET] <furq> but that should at least be relatively simple [20:18:30 CET] <zeryx> I'd like to have a concatenated duplicate as an end result after combining the subvideos [20:19:17 CET] <zeryx> so the best way would be to re encode the original video to some standard format, while doing so have keyframes every specified interval, then do a segment_times on those keyframes [20:19:31 CET] <jas99> hey @zeryx @furq any experience encoding 16bit video? [20:19:37 CET] <furq> well yeah pick a lossless codec and mux it into mkv or some other appropriate container [20:20:06 CET] <jas99> i tried with 16bit ffv1 [20:20:11 CET] <zeryx> jas99, I don't, I'm only working on AV stuff because I was told to [20:20:34 CET] <jas99> @zeryx :( [20:20:45 CET] <furq> jas99: if someone knows, they'll answer [20:21:09 CET] <jas99> with i upday yuv fill function [20:21:14 CET] <jas99> gray 8 works [20:21:26 CET] <jas99> but gray16 produces video [20:21:31 CET] <jas99> with green output [20:21:38 CET] <jas99> with vlc [20:22:04 CET] <jas99> i am trying to encode stream from xtion pro(kinnect) [20:22:17 CET] <jas99> oh cool [20:22:44 CET] <jas99> @furq so this get archived ? [20:22:56 CET] <jas99> and you guys are just users like me ? [20:24:09 CET] <zeryx> yea [20:24:15 CET] <zeryx> I have like 10 irc chats open [20:24:27 CET] <zeryx> I primarily use IRC to ask questions relating to a project I can't easily find help for on stack overflow [20:24:34 CET] <zeryx> but I also answer questions on irc channels when I know the answer [20:24:38 CET] <zeryx> kind of a give/take [20:24:55 CET] <jas99> very nice zeryx [20:24:56 CET] <zeryx> like whenever someone asks a question on #cuda, I usually can answer it [20:25:27 CET] <jas99> oh nice you work on gpu projects? [20:26:12 CET] <zeryx> yeah [20:26:23 CET] <jas99> cool [20:26:23 CET] <zeryx> I actually started programming on gpu's and moved onto regular cpu based stuff [20:26:40 CET] <zeryx> cuda was the first framework I ever used [20:26:42 CET] <jas99> nice I am computer vision guy [20:27:09 CET] <jas99> i work from india [20:27:27 CET] <jas99> like where are you from and what do work on [20:28:01 CET] <jas99> btw what problem you are having ?? [20:28:16 CET] <jas99> maybe you can also bounce ideas off me?? [20:28:30 CET] <zeryx> I'm from canada, and I build algorithms [20:28:57 CET] <jas99> nice allot of friends from canada, very nice place [20:29:04 CET] <zeryx> trying to convert abritrary video content into small interval videos & images, and then concatcenate them back together after performing cv operations on them [20:29:37 CET] <jas99> ah [20:29:54 CET] <zeryx> so streaming webcam input video for example [20:29:54 CET] <jas99> i was looking for code to do av_frame to cv myself [20:30:10 CET] <zeryx> building essentially that tool in java, it'll eventually be on www.algorithmia.com [20:30:19 CET] <zeryx> available for anyone to use it [20:30:33 CET] <jas99> chking it out [20:30:54 CET] <jas99> are you into bitcoin and stuff [20:31:15 CET] <jas99> this is aweosome [20:31:29 CET] <zeryx> yea [20:31:42 CET] <jas99> http://colony.io/ [20:32:03 CET] <jas99> know about ethereum?? [20:32:12 CET] <zeryx> furq, I'm currently trying to convert by hand, however I'm getting a seg fault, how would I determine the cause? [20:32:20 CET] <zeryx> (its actually converting for about 1 second, then faulting) [20:32:27 CET] <zeryx> yep my company works with them as partners [20:32:34 CET] <jas99> oh nice [20:33:52 CET] <zeryx> ahh figured it out [20:33:59 CET] <zeryx> -b:v 0 was causing some pretty big problems [20:34:19 CET] <jas99> so i can build algo and sell it at you place?? [20:34:42 CET] <zeryx> yep, and if you need any help I'm part of the QA team :P [20:34:53 CET] <jas99> nice [20:35:11 CET] <zeryx> if anyone uses it, you get paid a royalty, but I shouldn't say much more than that, at this point I'm essentially soliciting [20:35:21 CET] <zeryx> if you want to know more shoot me a private message [20:35:48 CET] <jas99> like do you have email [20:36:00 CET] <jas99> like can we discuss stuff like that?? [20:36:09 CET] <jas99> on irc [20:36:21 CET] <jas99> i guess its public record [20:36:43 CET] <durandal_1707> private message on irc [20:36:52 CET] <jas99> oh nice [20:37:04 CET] <jas99> whats command to do that [20:37:49 CET] <zeryx> /pm zeryx [20:48:25 CET] <zeryx> furq, just spoke with my boss and I misread the use case (doh!), is there a way to segment_ split on every keyframe? [20:53:54 CET] <jas99> hey @zeryx do you know how to convert avframe to cv mat [20:53:59 CET] <jas99> and vice versa [20:54:13 CET] <jas99> like code snipet for that in c++ [20:55:51 CET] <zeryx> nope, not that skilled in the AV field [20:55:59 CET] <zeryx> I know the basics of video/audio codecs, containers [20:56:01 CET] <zeryx> now keyframes [20:56:22 CET] <jas99> cool [20:58:26 CET] <ethe> there doesn't seem to be an --enable-(lib)jack option, is it just automatically detected, and compiled if found? [21:02:34 CET] <RobertKm> --enable-x11grab Option does not work? Who can help me [21:03:39 CET] <c_14> RobertKm: bug in current git, go back a few versions [21:03:50 CET] <c_14> s/versions/revisions/ [21:04:50 CET] <c_14> Any revision before today should be fine. [21:05:02 CET] <RobertKm> c_14 WoW, Thanks [21:09:35 CET] <jas99> av frame to cv mat [21:09:37 CET] <jas99> ?? [21:09:41 CET] <jas99> relp :) [21:09:47 CET] <jas99> and vice versa [21:44:16 CET] <_jamiejackson> hi folks, i've got ffmpeg version 0.8.17-4:0.8.17-0ubuntu0.12.04.1 and i'm trying to concatenate two mpg video files without re-encoding them... [21:44:33 CET] <_jamiejackson> I'm looking at https://trac.ffmpeg.org/wiki/Concatenate , but i'm having trouble with the example syntax... [21:45:19 CET] <_jamiejackson> the example that's given: ffmpeg -f concat -i mylist.txt -c copy output [21:46:37 CET] <_jamiejackson> http://pastebin.com/ZvaWDpLC [21:47:46 CET] <_jamiejackson> gives: Unknown input format: 'concat' [21:48:10 CET] <_jamiejackson> please help me get this figured out [21:48:45 CET] <furq> that's an ancient version of ffmpeg [21:48:49 CET] <jkqxz> I suggest starting by upgrading to version 3.0 from your current 0.8.17. [21:48:51 CET] <furq> -f concat was only added in 1.x [21:49:13 CET] <_jamiejackson> oh geez, that would explain it [21:49:34 CET] <furq> http://johnvansickle.com/ffmpeg/ [21:49:40 CET] <furq> you can use that if you're stuck on an old ubuntu [21:53:28 CET] <_jamiejackson> furq: thanks, it's rocking its way through the concat with that binary you linked [21:54:54 CET] <_jamiejackson> this is the most lossless way of concatenating mpg video, right? [21:56:10 CET] <furq> it's a lossless way [21:56:15 CET] <furq> lossless isn't really a comparative term [22:23:56 CET] <_jamiejackson> understood, thanks [22:36:18 CET] <zeryx> is there a way to automatically generate a list of split files from semething like segment_list? [22:36:45 CET] <zeryx> I'm trying to concatcenate and I'd like to automate the process of creating the txt file [22:37:43 CET] <J_Darnley> A good shell will do that with ease [22:38:00 CET] <zeryx> yeah, I can do it with a shell [22:38:08 CET] <zeryx> but I'd like to do it with ffmpeg output preferably [22:38:20 CET] <zeryx> is it not possible as an output from a -f -segment operation? [22:38:35 CET] <J_Darnley> Oh, that makes a little more sense [22:38:54 CET] <zeryx> ffconcat file [22:38:55 CET] <zeryx> yea [22:38:56 CET] <J_Darnley> No idea. Why split only to rejoin [22:39:02 CET] <zeryx> computer vision [22:39:07 CET] <zeryx> and parallel video processing [22:39:19 CET] <zeryx> GPUs and stuff [22:39:50 CET] <J_Darnley> but why rejoin? what did you do to the origina; file? [22:39:59 CET] <J_Darnley> *original [22:40:31 CET] <zeryx> the video files will be edited, but they will remain the same codec & format [22:40:44 CET] <zeryx> there may be some operations done to the videos such as image recognition overlays [22:41:23 CET] <zeryx> pretty standard stuff, we want to output as both a rejoined video and a streamable video [22:41:39 CET] <J_Darnley> Then yes it does look like its possible, rtfm [22:41:53 CET] <zeryx> thanks J_Darnley, been reading it all day [22:41:55 CET] <zeryx> :D [22:41:56 CET] <J_Darnley> http://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-… [22:42:04 CET] <zeryx> staring at it [22:42:05 CET] <J_Darnley> segment_list name [22:42:05 CET] <J_Darnley> Generate also a listfile named name. If not specified no listfile is generated. [22:43:39 CET] <zeryx> also the manual is attrocious to read fyi [22:43:50 CET] <J_Darnley> It sure is. [22:43:54 CET] <zeryx> some of the worst documentation I've had to sift through [22:45:25 CET] <furq> contributions welcome [23:25:15 CET] <Wader8> hello [23:27:24 CET] <Wader8> is it possible or is it planned to support automatic fragmental cut-out and concat ? Or is there a prepared script to do this with multiple actions, basically taking H264, taking out a few seconds of both video and audio in a number of areas from the source file, and then recoding that back to either remux or x265 for example [00:00:00 CET] --- Thu Feb 18 2016

1 0

ffmpeg-devel.log.20160216
by burek 17 Feb '16

17 Feb '16

[00:28:07 CET] Action: Daemon404 will merge some more tomorrow; today was a holiday [00:47:09 CET] <cone-932> ffmpeg 03Timothy Gu 07n3.1-dev:HEAD: RELEASE: Update to 3.0.git [00:55:42 CET] <cone-932> ffmpeg 03Rostislav Pehlivanov 07master:3b1d1437a0f3: vc2enc: print the average quantization index at the end [02:00:12 CET] <Timothy_Gu> FYI, GitStats for FFmpeg since ubitux's is down https://timothygu.me/gitstats/ffmpeg/ [02:48:08 CET] <Timothy_Gu> In case anyone's interested: Added VideoToolbox H.264 encoder. https://github.com/FFmpeg/FFmpeg/pull/177 [03:51:53 CET] <rcombs> Timothy_Gu: ooh, interesting [05:02:13 CET] <Timothy_Gu> proud host of the only x86 Linux GCC release branch FATE box [05:06:18 CET] <Timothy_Gu> also michaelni, do you plan on reenabling the Loongson FATE station? [05:54:39 CET] <Timothy_Gu> ubitux: for some reason ffmpeg.org is being rrreally slow [05:55:09 CET] <Timothy_Gu> the homepage takes 12s to load here (without encryption), but even fatebeta.ffmpeg.org takes 2s [08:20:38 CET] <wm4> Timothy_Gu: there were patches for this before [08:20:47 CET] <wm4> somehow got lost [08:21:23 CET] <wm4> ah it's the same author [09:17:55 CET] <cone-521> ffmpeg 03Carl Eugen Hoyos 07master:d0962160e076: lavfi/elbg: Make the pal8 output opaque. [10:52:17 CET] <michaelni> Timothy_Gu, about loongson, yes, i already thought about it yesterday but then didnt have enough time [11:43:47 CET] <ubitux> http://b.pkh.me/howto-aarch64-qemu-ffmpeg-neon-debug [11:44:12 CET] <ubitux> (since it's always a pain to get such shit working, just sharing a quick bootstrap) [11:45:04 CET] <ubitux> note: i didn't use linaro builds because gdb wasn't working (linked against libncurses5 while local system only has libncurses6) [11:47:31 CET] <ubitux> Timothy_Gu: i'm not responsible for ffmpeg.org admin [11:47:53 CET] <ubitux> Timothy_Gu: and my gitstats isn't down, i just don't update it on a regular basis [11:48:05 CET] <ubitux> i need to add an instance juste like coverage [11:48:56 CET] <michaelni> Timothy_Gu, http://ffmpeg.org/ loads instantaneously here locally [11:50:59 CET] <ubitux> it was probably stressed yesterday because of HN [11:51:42 CET] <michaelni> quite possibly [11:56:53 CET] <michaelni> also we still have a 2nd server that is unused and should instead contain a duplicate of ffmpeg.org, it likely is more powerfull but ENO_VOLUNTEERS [12:06:44 CET] <BtbN> Well, the 3.0 version number certainly brought more media attention than a 2.9 would have. [12:09:11 CET] <ubitux> oh ffs "nexti" and related are all interpreted as a "continue" in gdb [12:09:18 CET] <ubitux> what in the fucking hell is this shit [12:11:05 CET] <wm4> lol gdb [12:11:32 CET] <wm4> maybe there's a technical reason, like nit knowing whether single step will work, and if it doesn't, program execution is forcibly continued beyond? [12:12:15 CET] <ubitux> there is obviously a (braindead) technical reason [12:12:27 CET] <ubitux> i'd like to know it though [12:42:38 CET] <durandal1707> michaelni: could you please look at my drawutils patch, fate test mess up terminal and I dunno how to fix it [13:33:59 CET] <michaelni> durandal1707, against term messup this (from nicolas) may help if you use bash at least: bash_tty_mode=$(stty -g) [13:33:59 CET] <michaelni> PROMPT_COMMAND='stty $bash_tty_mode' [13:37:37 CET] <michaelni> the term messup is due to segfaults i think [13:38:02 CET] <michaelni> fate-filter-pixfmts-pad test for yuva422p16le segfaults for example [13:39:25 CET] <michaelni> more precissely this segfaults: ffmpeg -nostdin -nostats -cpuflags all -threads 1 -idct simple -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact -f image2 -vcodec pgmyuv -hwaccel none -threads 1 -thread_type frame+slice -i tests/vsynth1/%02d.pgm -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact -threads 1 -idct simple -dct fastint -vf format=yuva422p16le,pad=500:400:20:20 -vcodec rawvid [13:39:25 CET] <michaelni> eo -frames:v 5 -pix_fmt yuva422p16le -frames:v 1 -f nut md5: [13:40:48 CET] <BBB> kierank: I couldnt get it to crash with 2 threads with your patch, FWIW, and valgrind was happy [13:56:07 CET] <durandal1707> michaelni: thanks [14:05:17 CET] <durandal1707> michaelni: looks like bug in vf_pad [14:30:21 CET] Action: Daemon404 doesn't know how michaelni has the patience for Mats [14:31:18 CET] <durandal1707> i marked him as spam and now all his mails is happily in spam [14:32:47 CET] <Daemon404> lol [14:40:47 CET] <durandal1707> michaelni: actually everything points in output.asm bug in swscale [14:43:01 CET] <durandal1707> is there way to force valgrind to print exact instruction that caused crash? [14:43:59 CET] <iive> durandal1707: you can attach gdb on valgrind issue [14:52:04 CET] <mateo`> wm4: forgot to reply to one of your question, content uris support is not mandatory for mediacodec (it's not even related except from the fact that it comes from android) [14:55:20 CET] <wm4> ok [14:55:32 CET] <wm4> still confused about the jni thing [14:56:27 CET] <mateo`> which part ? [14:57:08 CET] <wm4> it sounds like we can just use JNI_GetCreatedJavaVMs()? [14:58:07 CET] <mateo`> In theory we could, we just need to check that jni_invocation_ != NULL, get the symbol of this function and call it [14:58:25 CET] <mateo`> gst is doing that actually [15:00:10 CET] <wm4> well if it crashes just blame google or the API user? [15:00:12 CET] <mateo`> the only reason why i didn't do that is that i don't want to call private c++ code dlopen/dlsym etc [15:01:18 CET] <mateo`> and don't really want to deal with those potential crashes ... [15:01:23 CET] <mateo`> but this is something i can change [15:02:29 CET] <wm4> is the jni_invocation symbol maybe exported? I noticed it's not static [15:03:16 CET] <mateo`> yes it's exported [15:03:25 CET] <cone-348> ffmpeg 03Mats Peterson 07master:b86ba37096dd: lavc/rawdec: Retrieve nut palette from packets [15:04:22 CET] <mateo`> it's possible to dlsym all this mess :p [15:06:14 CET] <wm4> mateo`: if it's exported, it's easy to check... the symbol is a pointer to a C++ class, but on all ABIs we deal with it it can be treated like a void* and checked for NULL [15:08:51 CET] <mateo`> should i really go that way then ? :s [15:09:46 CET] <wm4> IMHO yes, don't know about others [15:17:00 CET] <mateo`> wm4: your idea behind is to not export any public api related to jni / android (so no application context either) and confine the jni utils to lavc ? [15:19:12 CET] <durandal2707> michaelni: why it crashes only in asm in swscale? [15:19:13 CET] <wm4> mateo`: kind of [15:19:55 CET] <wm4> mateo`: if we really want this lavf content thing, we could probably do echo '#include "libavcodec/jni.c"' > libavformat/jni.c [15:20:09 CET] <wm4> a dirty trick, but it's already used somewhere else [15:20:23 CET] <ubitux> what am i reading [15:21:09 CET] Action: JEEB closes ubitux's eyes with his hands [15:21:53 CET] <mateo`> android, jni, dlsym c++ symbols, including .c [15:22:10 CET] <mateo`> my life is really full of shit :D [15:22:28 CET] <wm4> welcome to multimedia [15:23:18 CET] <ubitux> http://z0r.de/3564 [15:23:32 CET] <mateo`> and now flash ... [15:23:34 CET] <mateo`> thanks man [15:24:25 CET] <ubitux> ffplay "http://z0r.de/L/z0r-de_3564.swf" [15:24:27 CET] <ubitux> ;) [15:25:47 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:15d9645fb4ce: swscale/slice: Actually use the buffers' strides [15:27:20 CET] <kierank> eugh probing for dvb teletext [15:30:43 CET] <J_Darnley> I'm tempted to shout at these android guys and tell them to get a proper OS with an actual file system [15:31:33 CET] <Mavrik> Well it does have a file system. [15:31:38 CET] <Mavrik> It's just fun to use! [15:32:06 CET] <J_Darnley> Is this the future that the idiots who say "file are dead" actually want? [15:32:27 CET] <durandal2707> andrey_utkin: ping [15:32:45 CET] <Mavrik> (Not sure how filesystem is related to the crappy API that's MediaCodec) [15:33:07 CET] <mateo`> it's not related [15:33:33 CET] <J_Darnley> Sure it is. Look at that horrible nonsense in the guy's latest mail. [15:33:48 CET] <ubitux> note: please never remove --disable-pthreads in the future [15:33:49 CET] <mateo`> it's me [15:34:04 CET] <J_Darnley> Oh I can shout at you here can I? [15:34:08 CET] <mateo`> you can [15:34:36 CET] <J_Darnley> GET A PROPER OPERATING SYSTEM WITH AN ACTUAL FILE SYSTEM [15:34:52 CET] <Mavrik> mateo`, btw, any worries about people who'll try to use MediaCodec from binaries that don't have a JVM instantiated? [15:36:47 CET] <mateo`> Mavrik: i'm not familiar with this configuration, i don't know in details the implications of not having a jvm instantiated. [15:37:10 CET] <Mavrik> Ok, so for example in one of the applications we abuse ffmpeg by using Runtime.getRuntime().exec() [15:37:19 CET] <Mavrik> Which just runs ffmpeg compiled as a normal Linux binary for Android. [15:37:31 CET] <Mavrik> Of course as a silly developer I'd like ffmpeg to use MediaCodec APIs [15:37:38 CET] <Mavrik> But that binary won't have a JVM available :) [15:37:58 CET] <Mavrik> Since it's just a binary and there's no JNI environment. [15:38:33 CET] <mateo`> The c++ jni wrapper of google is supposed to be able to spawn a vm but i have no idea if it's actually working [15:39:28 CET] <Mavrik> Well if you need testing :) [15:39:33 CET] Action: Mavrik looks at pile of devices on his table. [15:40:12 CET] <andrey_utkin> durandal2707: hi? [15:42:29 CET] <durandal2707> andrey_utkin: there is drawbox/drawgrid patch on ml [15:42:31 CET] <mateo`> Mavrik: I have also a bunch of devices. Do you need something special on the device to exec the binary ? [15:42:43 CET] <Mavrik> nop, just build the binary with NDK standalone toolchain [15:42:54 CET] <andrey_utkin> durandal2707: thanks, I will take a look. [15:42:55 CET] <Mavrik> push it to /data/tmp [15:42:56 CET] <Mavrik> and run it [15:42:59 CET] <mateo`> ok [15:43:12 CET] <Mavrik> Or the use case we did was to unpack it from assets to app files dir and run it from there via Java [15:44:04 CET] <andrey_utkin> durandal2707: "avfilter/vf_drawbox: add alpha support" ? [15:44:09 CET] <mateo`> Mavrik: then i'll try to do something for this particular case, but it won't be my priority at first. [15:44:13 CET] <michaelni> also if anyone can help fill in awnsers for the GSoC questions in "0127 22:03 To FFmpeg devel (3.7K) [FFmpeg-devel] GSoC 2016" please do, and especially the "How many potential mentors have agreed to mentor this year?" i need, need to leave now, will read log [15:44:34 CET] <Mavrik> mateo`, yp, personally I think just not supporting that is a valid option as well [15:44:49 CET] <Mavrik> Just wanted to warn about that possibility since that's the "easiest" way of using ffmpeg from an Android app. [15:46:55 CET] <durandal2707> andrey_utkin: yes [15:48:04 CET] <mateo`> J_Darnley: there is a proper filesystem behind it, which uses fuse, which ... well ... :D [15:48:32 CET] Action: J_Darnley resists further arguing/trolling [15:50:02 CET] <andrey_utkin> sorry for being not an active part of ffmpeg, now I've got new job and it is strongly ffmpeg-related :) I hope I'll get more active, also a tricky transcoding tool (main feature is time interval based transcoding with filtering or remuxing) will get developed and released under GPL [15:50:57 CET] <wm4> <ubitux> note: please never remove --disable-pthreads in the future <- ? [15:51:50 CET] <wm4> andrey_utkin: awesome [15:52:14 CET] <durandal2707> andrey_utkin: no need to be sorry, you do what you want.. [15:52:50 CET] <ubitux> wm4: i need it for qemu+gdb to work [15:52:57 CET] <ubitux> with pthreads, it's unusable [15:54:28 CET] <mateo`> wm4: i'm wondering about the ability to open a fd from lavf, would that mean a fd protocol (which will have big security concerns) ? [15:54:58 CET] <wm4> you always have to be careful about what to pass to lavf [15:55:07 CET] <wm4> also I wonder if we already have a fd protocol somewhere [15:55:11 CET] <wm4> I just didn't find it [15:59:41 CET] <andrey_utkin> wm4: there's underdeveloped "fd" protocol named "pipe", it handles only STDIN and STDOUT currently. [16:24:45 CET] <Daemon404> hmm. [16:24:52 CET] <Daemon404> we have 0 hls coverage. [16:25:01 CET] <nevcairiel> network things are usually not covered [16:25:06 CET] <Daemon404> i guess i can only pray my hls merge is correct aside from testing manually [16:25:12 CET] <Daemon404> nevcairiel, hls can have file:// [16:25:15 CET] <Daemon404> for fate [16:25:28 CET] <nevcairiel> i would argue that no, hls can not have file, it has http in the name [16:25:29 CET] <nevcairiel> =p [16:25:37 CET] <Daemon404> :P [16:28:30 CET] <cone-348> ffmpeg 03Paul B Mahol 07master:a588c7ac13bc: avfilter: add fieldhint filter [16:28:39 CET] <wm4> well this ability of the hls demuxer caused the recent security issue [16:28:48 CET] <wm4> might as well use it for good and add it to fate? [16:33:28 CET] <Daemon404> perhaps yes [16:34:18 CET] <rcombs> have we limited it to only allow mpegts for the underlying demuxer? [16:34:35 CET] <rcombs> and uh I think maybe mp3 is also allowed [16:34:39 CET] <nevcairiel> its not limited to that though, it allows raw audio things [16:34:44 CET] <nevcairiel> adts and mp3 at least [16:34:48 CET] <nevcairiel> also some subtitle formats i think [16:35:09 CET] <nevcairiel> anyway the thing that got limited is the protocol support [16:40:37 CET] <ubitux> yay, nv12 to bgra on aarch64 working [16:40:48 CET] <Daemon404> ur [16:40:50 CET] <Daemon404> urg [16:40:59 CET] <Daemon404> for merging 81306fd4bdeb5c17d4db771e4fec684773b5790f [16:41:01 CET] <Daemon404> im unsure what to do [16:41:09 CET] <Daemon404> we use (abuse?) urlcontext stuff [16:41:21 CET] <Daemon404> cookies, user-agent, http-proxy [16:41:21 CET] <Daemon404> etc [16:41:47 CET] <Daemon404> im dont know what to do here [16:42:50 CET] <Daemon404> wm4, you may have an opinion? [16:42:56 CET] <durandal1707> ubitux: aarch64 is alive? [16:43:31 CET] <durandal1707> ubitux: stop working on obsolete stuf, do nlmeans ;) [16:43:32 CET] <ubitux> awakening [16:43:40 CET] <ubitux> it's not obsolete [16:43:45 CET] <ubitux> it's the name for arm64 [16:43:46 CET] <rcombs> aarch64 is the hot new thing [16:43:46 CET] <wm4> Daemon404: let me see [16:44:06 CET] <Daemon404> wm4, libav ripped out the use of ffurl_* and make it use ctx->io_open [16:44:14 CET] <Daemon404> i.e. the new callbacks for sub-file i/o [16:44:26 CET] <Daemon404> but we use a bunch of options in the ffurl stuff (ss\ee above) [16:44:36 CET] <wm4> user-agent needs to be passed down, cookies need to be preserved (sub-requests can change them) [16:44:53 CET] <Daemon404> yeah but this is all specific to ffurl [16:44:56 CET] <Daemon404> which is my problem. [16:45:11 CET] <wm4> which specific parts cause problems? [16:45:27 CET] <Daemon404> because where the hell do i set the options then [16:45:31 CET] <Daemon404> ffurl use is *gone* [16:45:32 CET] <wm4> it seems hls.c mainly uses avoption to communicate this stuff [16:46:23 CET] <Daemon404> e.g. see hls_read_header [16:46:26 CET] <Daemon404> i dont know wtf to do with this [16:47:47 CET] <wm4> man... [16:48:00 CET] <durandal1707> relax [16:48:27 CET] <wm4> accessing another URLContext->priv_data_class and then using avoptions on it [16:49:08 CET] <wm4> Daemon404: replace URLContext->priv_data_class with AVIOContext->opque, maybe [16:49:09 CET] <Daemon404> i cleaned up the merge itself, but this bit is left, and it's over my head atm [16:49:23 CET] <Daemon404> wm4, i though about that but i was not sure. [16:49:33 CET] <Daemon404> technically that is wrong [16:49:38 CET] <Daemon404> especially for custom i/o [16:49:44 CET] <wm4> it was wrong before [16:49:53 CET] <Daemon404> lol [16:50:17 CET] <Daemon404> i guess ill add a similar check to the custom i/o check [16:50:23 CET] <Daemon404> itll just mean custom i/o = no cookeis n shit [16:50:42 CET] <wm4> I wonder if you want just call av_opt_get on AVIOContext directly [16:50:50 CET] <nevcairiel> custom io for hls sounds like a dangerous path anyway [16:50:59 CET] <nevcairiel> so much shit you can screw up =p [16:51:08 CET] <Daemon404> nevcairiel, i used it once :P [16:51:09 CET] <Daemon404> for fun [16:51:09 CET] <wm4> with search flags = AV_OPT_SEARCH_CHILDREN [16:51:19 CET] <wm4> strange definition of fun [16:51:21 CET] <Daemon404> libcurl-implemented avio callbacks [16:51:28 CET] <Daemon404> i did not use this in a rwal scenario though [16:51:31 CET] <Daemon404> real* [16:52:28 CET] <Daemon404> wm4, i notice our hls.c is orders of magnitude more complex ;p [16:52:35 CET] <Daemon404> (and cookies with hls... wtf why?) [16:52:57 CET] <wm4> some servees require it [16:52:59 CET] <wm4> *servers [16:53:08 CET] <Daemon404> but why [16:53:14 CET] <Daemon404> cant you use params or a rest-like api [16:53:19 CET] <Daemon404> params as in GET [16:53:26 CET] <wm4> because mixing of multimedia and web devs [16:53:32 CET] <Daemon404> ;-; [16:54:02 CET] <Daemon404> the hls segmenter i wrote uses a rest-liek api with signing [16:54:12 CET] <Daemon404> i cant fathom why cookies would be needed [16:54:41 CET] <rcombs> idiocy [16:56:52 CET] <ubitux> anyone friendly with as ? [16:57:02 CET] <ubitux> i'd like to do additions in preproc [16:57:27 CET] <ubitux> but for identifying a register typically [16:57:55 CET] <Daemon404> rcombs, that makes me really sad [16:59:08 CET] <Daemon404> wm4, seems to work [16:59:18 CET] <wm4> good enough [16:59:18 CET] <Daemon404> but i dont have any cookie-needing hls urls to test [16:59:25 CET] <Daemon404> so uh... :| [16:59:28 CET] <wm4> neither have I [16:59:36 CET] <Daemon404> but it doesnt segfault, and it plays vimeo's hls streams from ym segmenter [16:59:39 CET] <wm4> though it was added recently [16:59:39 CET] <Daemon404> ... lol [17:00:02 CET] <Daemon404> wm4, feel liek doign a quick once-over on teh diff? [17:00:06 CET] <Daemon404> just on irc [17:00:19 CET] <wm4> sure [17:01:42 CET] <Daemon404> wm4, http://chromashift.org/diff.txt [17:03:08 CET] <nevcairiel> i assume avio handles the whitelist which was previously handled manually? [17:03:30 CET] <Daemon404> nevcairiel, only with non-custom i/o [17:03:36 CET] <nevcairiel> of course [17:03:46 CET] <Daemon404> when i merged io_open i made sure to keep whitelisting [17:03:49 CET] <Daemon404> in teh default handler [17:05:01 CET] <wm4> I like how this whitelist shit goes out of the window [17:05:17 CET] <Daemon404> it does; it's still there [17:05:24 CET] <Daemon404> just in a different layer [17:05:31 CET] <wm4> -/* Intercept and handle ID3 tags between URLContext and AVIOContext */ [17:05:33 CET] <wm4> stray change? [17:05:55 CET] <Daemon404> well it doesnt intercept considering there's no URLContext [17:06:00 CET] <Daemon404> i wasnt sure what to change it to though [17:08:07 CET] <ubitux> we need to decide something for the precision in sws convert :( [17:08:21 CET] <ubitux> i'm porting the 32-bit code but since it's unused... [17:08:45 CET] <wm4> Daemon404: I can make a short test, does the patch apply on git master? or alternatively, hand me a git url [17:09:10 CET] <Daemon404> git master yes [17:09:17 CET] <Daemon404> git apply or patch -p1 [17:09:48 CET] <Daemon404> it worked on a playlist with subplaylists over https for me [17:10:00 CET] <Daemon404> need someone else to test [17:10:34 CET] <wm4> not sure if I can contribute to this, but I'll test anyway [17:10:48 CET] Action: Daemon404 could always push and wait for people to send him death threats [17:24:39 CET] <wm4> Daemon404: I don't know, seems to work for me [17:25:01 CET] <Daemon404> ok [17:27:36 CET] <cone-348> ffmpeg 03Anton Khirnov 07master:81306fd4bdeb: hls: eliminate ffurl_* usage [17:27:37 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:d0fc5de3a643: Merge commit '81306fd4bdeb5c17d4db771e4fec684773b5790f' [17:33:05 CET] <Timothy_Gu> ubitux: thanks for the info [17:36:02 CET] <Daemon404> do we have a policy on how to merge avplay stuff into ffplay? [17:36:05 CET] <Daemon404> do it? dont do it? [17:36:09 CET] <wm4> don't [17:36:15 CET] <wm4> they're probably far too different [17:36:17 CET] <wm4> same for avconv [17:36:43 CET] <Daemon404> i see [17:36:44 CET] <Timothy_Gu> michaelni: loads fine now [17:36:45 CET] <nevcairiel> i usually just looked at the affected areas [17:36:53 CET] <nevcairiel> and if its similar and easily merged, i did it [17:36:55 CET] <nevcairiel> if not, then not [17:37:07 CET] <Daemon404> nevcairiel, ok, i wasnt sure how martin balint felt. [17:37:17 CET] <Daemon404> it's a shame git is too dumb to understand renames during merges [17:37:22 CET] <nevcairiel> since w hen do merges care about the individual maintainers =p [17:37:38 CET] <Daemon404> lo,. [17:37:39 CET] <Daemon404> lol* [17:50:08 CET] <cone-348> ffmpeg 03Luca Barbato 07master:f22f90059432: avplay: Move the stream setup in the main thread [17:50:09 CET] <cone-348> ffmpeg 03Luca Barbato 07master:fdd464cb7045: avplay: Allocate the refresh thread next to the decode thread [17:50:10 CET] <cone-348> ffmpeg 03Luca Barbato 07master:21bbc345ccb6: avplay: Rename VideoState to PlayerState [17:50:11 CET] <cone-348> ffmpeg 03Luca Barbato 07master:611ba89b896a: avplay: Rename cur_stream to player [17:50:12 CET] <cone-348> ffmpeg 03Luca Barbato 07master:6fa464f8d29b: avplay: Statically allocate the player state [17:50:13 CET] <cone-348> ffmpeg 03Luca Barbato 07master:eef9f0650835: avplay: Allow to override the codec [17:50:14 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:32766877b4e1: Merge commit 'eef9f06508354d1c7d5624c1c18997e7974288f1' [17:52:24 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:9cac1b4b4f15: qsvenc: Add private option to replace coder_type [17:52:25 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:c63da6e91630: Merge commit '9cac1b4b4f1532fb2aeef54799285360656be5eb' [17:53:51 CET] <ubitux> nothing to take from the avplay patches? [17:54:25 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:1546a41adae8: pixdesc: Drop unneeded deprecation warning guards [17:54:26 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:3f462fcf76bb: Merge commit '1546a41adae818b340acdd9b5dacd6d0a92b6507' [17:54:47 CET] <Daemon404> ubitux, out stuff seems to be vastly different / incompatible [17:55:00 CET] <ubitux> ok [17:55:02 CET] <Daemon404> and has some of it already [17:56:04 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:6695f178a592: pixdesc: Use AV_CEIL_RSHIFT in documentation [17:56:05 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:73bd20c4d238: Merge commit '6695f178a5929eab91d3da7e9023999f1774bd0e' [17:57:51 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:e80307140f73: yuv4mpegenc: Use AV_CEIL_RSHIFT where needed [17:57:52 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:56475e885ba7: Merge commit 'e80307140f736f593ee643affa015333d7c5e27f' [18:01:03 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:4709f72115e4: lavfi: Use AV_CEIL_RSHIFT where needed [18:01:04 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:4401f07f4daa: Merge commit '4709f72115e4028a1cb43e916925678bfceef870' [18:03:08 CET] <cone-348> ffmpeg 03Luca Barbato 07master:eafb05fcf37c: v210: x86: Add the correct guards around the asm code [18:03:09 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:8f8381bf0364: Merge commit 'eafb05fcf37cd19a910ca3b17824384f9006bc0a' [18:04:08 CET] <cone-348> ffmpeg 03James Almer 07master:b624f0660b66: x86: Add ymm_reg struct [18:04:09 CET] <cone-348> ffmpeg 03James Almer 07master:77a44f577b64: configure: add missing avx2 support check [18:04:10 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:2f78be00194b: Merge commit '77a44f577b644a328dcf90cde11d2ecae69eda05' [18:07:09 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:60f0fde3092d: libx264: Make sure to preserve default option values [18:07:10 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:113c25653320: Merge commit '60f0fde3092d18d4d36555962c192af8691a099c' [18:12:32 CET] <ubitux> yay, vulkan out [18:12:41 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:1ba1fede9dfe: flacenc: Restore defaults and range for {min, max}_prediction_order [18:12:42 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:dc22269b2325: Merge commit '1ba1fede9dfe03dc48862e5e0530cca7192f5038' [18:15:55 CET] <durandal2707> ubitux: what is vulkan? [18:16:26 CET] <ubitux> http://www.phoronix.com/scan.php?page=article&item=vulkan-10&num=1 [18:16:54 CET] <ubitux> "successor" / alt opengl [18:17:11 CET] <nevcairiel> its extremely low level, so its not going to replace anything [18:17:17 CET] <jamrial> both amd and nvidia released drivers with support, at least on windows [18:17:24 CET] <Daemon404> J_Darnley, ping [18:17:32 CET] <J_Darnley> pong [18:18:52 CET] <Daemon404> J_Darnley, can i skip these two from Libav: v210: Add avx2 version of the 8-bit line encoder, v210: Add avx2 version of the 10-bit line encoder [18:19:01 CET] <Daemon404> they seem to be weirdly different from ours [18:19:03 CET] <Daemon404> and im not sure why [18:19:13 CET] <J_Darnley> ... [18:19:17 CET] <J_Darnley> Let me look [18:19:39 CET] <J_Darnley> I did send the patches there at kierank's request and got infrequent replies from them. [18:19:50 CET] <J_Darnley> They seem to hate keeping me in Cc [18:19:52 CET] <Daemon404> i guess they fiddled with them [18:20:05 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commitdiff;h=d29237e5578a187c5a8d91338… [18:20:08 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commitdiff;h=15ec7aa4170ed05ad1b17000e… [18:23:04 CET] <wm4> so how long is this fork bullshit supposed to carry on [18:23:20 CET] <J_Darnley> Hm, no cextern from them [18:26:03 CET] <J_Darnley> Okay, the 8 bit has a few changes in asm constants and AVX2 guards. Otherwise I think its the same from a cursory glance. [18:26:25 CET] <durandal2707> wm4: until you stop talking with evil nicks [18:26:53 CET] <Daemon404> J_Darnley, should i skip then, or are those constraints important [18:26:57 CET] <mateo`> wm4: news from android bs land, i got the hack using the c++ private api to retreive the vm, no need to have av_jni_set_java_vm anymore (in theory) [18:27:14 CET] <J_Darnley> I thought someone had already merged in the AVX2 guards [18:27:19 CET] <wm4> mateo`: sounds good [18:27:36 CET] <J_Darnley> I'm still looking at thw 10 bit [18:27:39 CET] <Daemon404> ok [18:27:49 CET] <Daemon404> J_Darnley, also see: https://git.libav.org/?p=libav.git;a=commitdiff;h=15ec7aa4170ed05ad1b17000e… [18:27:54 CET] <Daemon404> it comes directly after your commit [18:28:00 CET] <Daemon404> just wanna make sure it wont make anything explode [18:28:52 CET] <J_Darnley> Similar differences for the 10 bit [18:29:20 CET] <J_Darnley> I think you gave me a wrong link just now [18:29:29 CET] <J_Darnley> that's the 10bit patch [18:29:34 CET] <Daemon404> uh.. yeah [18:29:43 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commitdiff;h=e280fe13291e9c712a5f4aa13… [18:29:55 CET] <Daemon404> im not sure how the asm consumes that struct member [18:29:59 CET] <Daemon404> so i thought i'd aks. [18:30:01 CET] <Daemon404> ask even [18:30:44 CET] <J_Darnley> The asm doesn't use it. The C does when deciding how many samples the DSP functions processes [18:30:57 CET] <Daemon404> ok [18:31:19 CET] <cone-348> ffmpeg 03James Darnley 07master:d29237e5578a: v210: Add avx2 version of the 8-bit line encoder [18:31:20 CET] <J_Darnley> It is a better solution than 1 value controlling 2 separate code paths [18:31:20 CET] <cone-348> ffmpeg 03James Darnley 07master:15ec7aa4170e: v210: Add avx2 version of the 10-bit line encoder [18:31:21 CET] <cone-348> ffmpeg 03Luca Barbato 07master:e280fe13291e: v210: Use separate sample_factors [18:31:22 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:6bff2b5f6a3d: Merge commit '15ec7aa4170ed05ad1b17000ef1e3940d0a0c5e7' [18:31:23 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:04e4166536d3: Merge commit 'e280fe13291e9c712a5f4aa13b5263f3e8afed45' [18:32:52 CET] <J_Darnley> P.S. How can I make git show what gets changed in a merge commit? [18:33:24 CET] <durandal2707> no that's secret, it hides backdoors [18:33:49 CET] <jamrial> J_Darnley: click "diff1" on each listed file [18:34:08 CET] <durandal2707> that's why i hate merges [18:34:11 CET] <J_Darnley> Click? My terminal has nothing to click on [18:34:22 CET] <durandal2707> buy windows [18:34:31 CET] <jamrial> then use the web interface [18:34:59 CET] <cone-348> ffmpeg 03Luca Barbato 07master:a38a4f44b5c7: configure: Support MSYS2 mingw-w64 64bit [18:35:00 CET] <cone-348> ffmpeg 03Vicente Jimenez Aguilar 07master:f428893c1725: doc: Improve the channelsplit example [18:35:01 CET] <J_Darnley> I will not buy Windows when I can pirate. :) [18:35:01 CET] <cone-348> ffmpeg 03Henrik Gramner 07master:389b79842c67: msvc: Fix libx264 linking [18:35:02 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:e7b8ec8b6fd8: Merge commit '389b79842c67b1f5730215a752a5f89cb1b8d9a3' [18:35:20 CET] <durandal2707> J_Darnley: this channel is public [18:35:26 CET] <Daemon404> J_Darnley, git diff <mergehash>^..<mergehash> [18:35:29 CET] <Daemon404> is how i check [18:35:35 CET] <J_Darnley> I know. [18:35:51 CET] <J_Darnley> Daemon404: thanks [18:35:52 CET] <Daemon404> i dont think cgit has a real way to look on the webui [18:35:54 CET] <Daemon404> it's pretty bad. [18:36:28 CET] <J_Darnley> durandal_1707: I know. What is MS going to do? Sue me for my life savings of ~¬200 [18:38:07 CET] <cone-348> ffmpeg 03Andreas Cadhalpun 07master:a32dbf2aed3b: asfdec: break if EOF is reached after asf_read_packet_header [18:38:08 CET] <cone-348> ffmpeg 03Andreas Cadhalpun 07master:e4d1621c6e51: asfdec: check avio_skip in asf_read_simple_index [18:38:09 CET] <cone-348> ffmpeg 03Andreas Cadhalpun 07master:bf50607ab761: asfdec: check for too small size in asf_read_unknown [18:38:10 CET] <cone-348> ffmpeg 03Andreas Cadhalpun 07master:2e6ba1993ef4: asfdec: make sure packet_size is non-zero before seeking [18:38:11 CET] <cone-348> ffmpeg 03Michael Niedermayer 07master:5781bfae0cf4: flacenc: Load default prediction_order parameters if none is selected [18:38:12 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:8bbca8de3944: Merge commit '5781bfae0cf4271278a8bea176d615cb5c222335' [18:40:13 CET] <wm4> did you know that configure checks for certain shell bugs, and tries other shells if they are detected? [18:40:35 CET] <durandal2707> omg, that is insane [18:40:43 CET] <cone-348> ffmpeg 03Anton Khirnov 07master:dd53af4b37c7: avplay: drop support for building without lavfi [18:40:44 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:a236e4e8b840: Merge commit 'dd53af4b37c7790ce26065b36d5655c1af38b295' [18:40:52 CET] <wm4> it tries bash, ksh, and /usr/xpg4/bin/sh [18:40:57 CET] <ubitux> yep [18:41:26 CET] <durandal2707> from who originated such an idea? [18:41:44 CET] Action: J_Darnley suggests it was autotools [18:42:12 CET] <wm4> mans, 2006 [18:42:24 CET] <ubitux> it actually predates this commit [18:42:26 CET] <wm4> for Solaris [18:42:50 CET] <J_Darnley> Daemon404: your merge looks good to me, sorry for the trouble. [18:43:04 CET] <ubitux> ah still mans in 2006 actually [18:46:00 CET] <cone-348> ffmpeg 03Diego Biurrun 07master:34c9eba982c7: configure: Refactor toolchain flag setting [18:46:01 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:1c417bad613d: Merge commit '34c9eba982c75196392a3b0b245dd34297c4511d' [18:46:10 CET] <Daemon404> J_Darnley, not your doing, dont worry [18:46:18 CET] <Compn> its not insane [18:46:25 CET] <Compn> its insane that there are so many shell bugs to work around [18:46:29 CET] <Compn> at least 10 years ago :P [18:46:31 CET] Action: Compn runs [18:48:58 CET] <cone-348> ffmpeg 03Luca Barbato 07master:99214d42a902: dnxhd: Make the encoder message friendlier [18:48:59 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:55cada301049: Merge commit '99214d42a902c8392d7887c08fdc5dc1fc2475ae' [18:50:13 CET] <durandal2707> there is no filter that insert silence/black inside vfr gaps? [18:51:09 CET] <Daemon404> .. gaps? [18:51:13 CET] <Daemon404> there are no gaps to fill [18:51:32 CET] <Daemon404> vfr has no gaps. the two are urnelated [18:52:07 CET] <durandal2707> say last frame you get at 6 hours and next frame you get at 7th hour.. [18:52:45 CET] <Daemon404> yes> [18:52:51 CET] <Daemon404> that frame is static for that full hour then [18:52:54 CET] <Daemon404> there is no gap. [18:53:22 CET] <durandal2707> what if there is gap, and last frame have duration [18:53:37 CET] <Daemon404> how can there be a gap? [18:53:51 CET] <Daemon404> with lavf/lavc there cant be [18:54:03 CET] <Daemon404> the only possible way there could be a gap is mismatched frame durations and timestamps [18:54:11 CET] <Daemon404> in which case it's not a vfr problem at all [19:03:28 CET] <durandal2707> Daemon404: there is possible to have non-monotonic pts [19:04:30 CET] <cone-348> ffmpeg 03Lou Logan 07master:ddc9a587f929: doc/filters: remove redundant example [19:08:39 CET] <omerjerk> can someone explain this .comp field ? - https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixdesc.c#L481 [19:09:06 CET] <wm4> omerjerk: see pixdesc.h [19:09:27 CET] <omerjerk> okay, Thanks. [19:09:31 CET] <wm4> it's not easy to figure out (because these descriptors are complex), but all information is there [19:10:54 CET] <omerjerk> okay. [19:11:22 CET] <cone-348> ffmpeg 03Thomas Lee 07master:7a00653be6b1: tiny_psnr: Support large files [19:11:23 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:ea1f47757b2d: Merge commit '7a00653be6b13131ce1b2cdeca696429f57caaf8' [19:17:31 CET] <durandal2707> llogan: there was no need to remove example [19:19:29 CET] <cone-348> ffmpeg 03Paul B Mahol 07master:c4ed21367559: avfilter/f_streamselect: check if map is available [19:35:17 CET] <llogan> durandal2707: it wasn't good [19:47:51 CET] <tmm1> ubitux: any other comments on the ccaption encoding patch? [19:59:07 CET] <ubitux> tmm1: i will test and apply soon [20:02:13 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:cdbaa436042b: mpeg12dec: Always close reader on error [20:02:14 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:2ec66ff83d00: Merge commit 'cdbaa436042ba59c3b2bd7e9652e9a14136fd604' [20:03:21 CET] <JEEB> -win21 [20:06:28 CET] <cone-348> ffmpeg 03Diego Biurrun 07master:249827f736db: mpeg12dec: Refactor mpeg1_decode_block_intra() [20:06:29 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:8e2105297dae: Merge commit '249827f736db4c94dfcb24a3883aa4c04f9b119b' [20:33:02 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:7c25ffe070c2: mpeg1: Make intra-block decoding independent of MpegEncContext [20:33:03 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:58dd885f9ae7: Merge commit '7c25ffe070c286874a8c3513f7504b90e1626b0c' [20:46:45 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:f7d77b9a5dd4: eatqi: Remove MpegEncContext dependency [20:46:46 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:c82d31808bdc: Merge commit 'f7d77b9a5dd42bf0f5dffecf590466b4c4239437' [20:49:01 CET] <cone-348> ffmpeg 03Anton Khirnov 07master:fb25d99b0a5e: buffersrc: do not discard the error from ff_filter_frame() [20:49:02 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:9a9f3f151fa2: Merge commit 'fb25d99b0a5e21fb8cc184c7a9d3736387778266' [20:50:20 CET] <cone-348> ffmpeg 03Anton Khirnov 07master:28259c13db78: nvenc: factor out the pixel format list [20:50:21 CET] <cone-348> ffmpeg 03Anton Khirnov 07master:118beda35507: nvenc: merge input and output surface structs [20:50:22 CET] <cone-348> ffmpeg 03Anton Khirnov 07master:d005ccc630e4: nvenc: rename a misnamed function [20:50:23 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:fab8d9717c9c: Merge commit 'd005ccc630e42daab8ec2afecf972d1551a9401a' [20:52:00 CET] <cone-348> ffmpeg 03Luca Barbato 07master:e579d8b29cdb: lavf: Dump the cpb side data information [20:52:01 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:0479cf8530d0: Merge commit 'e579d8b29cdb9b42c50a0fde277dfb047c1466ad' [20:52:43 CET] <cone-348> ffmpeg 03Hendrik Leppkes 07master:8c399bd5cefd: dxva2_hevc: properly signal the num_delta_pocs from the SPS RPS [20:52:44 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:df61e4c24150: Merge commit '8c399bd5cefd572eceb448981fcb6d4dbca35d27' [20:54:04 CET] <cone-348> ffmpeg 03Philip Langdale 07master:8958c5c64d05: hevc: Track long and short term RPS size for VDPAU [20:54:05 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:146637905920: Merge commit '8958c5c64d05453204642b55a7b8b44c93023b17' [21:06:00 CET] <cone-348> ffmpeg 03Philip Langdale 07master:8d34a2f803c9: vdpau: Support for VDPAU accelerated HEVC decoding [21:06:01 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:cbe3f28d0ac7: Merge commit '8d34a2f803c9ca9433b5a51bacbbe352e8d327e2' [21:07:22 CET] <cone-348> ffmpeg 03Luca Barbato 07master:5eb562831b3a: mov: Use the correct type for size [21:07:23 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:4e3185d20866: Merge commit '5eb562831b3a9bea8026c413ef1338e06450d005' [21:07:30 CET] <Daemon404> oh FUCK [21:08:10 CET] <Daemon404> fixing [21:10:18 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:00bd23749988: mov: Fix leftover merge conflict cruft [21:10:27 CET] <Daemon404> maybe thats enough for today. [21:12:34 CET] <Daemon404> nevcairiel / wm4 - whats up with the hwaccel/cuda stuff anton pushed recently [21:12:38 CET] <Daemon404> re: merge [21:15:45 CET] <wm4> git.libav.org (web) is timing out [21:15:48 CET] <wm4> so, no idea [21:15:54 CET] <wm4> did he push the hwcontext stuff? [21:16:10 CET] <jkqxz> Yes. [21:16:15 CET] <nevcairiel> yes yesterday already [21:16:57 CET] <Daemon404> janne is updating libav.org services [21:17:00 CET] <Daemon404> its a planned downtime [21:17:04 CET] <Daemon404> itll be back [21:17:11 CET] <Daemon404> get the github mirror [21:17:14 CET] <Daemon404> check* [21:17:55 CET] <durandal_1707> its finnally down! [21:20:32 CET] <wm4> github, I'd rather use the terminal [21:21:20 CET] <Daemon404> looks like its back up anywya [21:21:37 CET] <wm4> ok the hwcontext stuff was merged [21:21:46 CET] <wm4> what about it? we kind of want it [21:21:52 CET] <wm4> (I think...) [21:22:03 CET] <Daemon404> i dunno, i dont live in hardware land [21:22:22 CET] Action: Daemon404 is no player person [21:23:20 CET] <jkqxz> Yes. It's not clear that it's actually in final form yet. I don't know how your merging works, though. [21:24:42 CET] <Daemon404> i type /<<< in vim and then hit dd a lot [21:24:46 CET] <Daemon404> and then cy [21:25:57 CET] <durandal_1707> learn regexp [21:26:21 CET] <Daemon404> / in vim is a regexp [21:27:01 CET] <durandal_1707> advanced stuff [21:27:27 CET] <Daemon404> i dont think there is a regexp advanced enough to gain sentient intelligence and handle merge conflicts [21:27:35 CET] <xyz> mateo`: hey, are the newest mediacodec changes not on your github yet? here https://github.com/mbouron/FFmpeg/commits/stupeflix-devel it still uses av_jni_register_java_vm [21:28:00 CET] <J_Darnley> Daemon404: at that point you might as well let it write the program for you. [21:28:08 CET] <Daemon404> indeed [21:36:05 CET] <durandal_1707> michaelni: are you back? [21:38:36 CET] <michaelni> durandal_1707, iam here, yes [21:40:12 CET] <durandal_1707> michaelni: know why pad crashes only with asm and only with x bigger than 0 [21:40:40 CET] <durandal_1707> with my drawutils patch [21:40:54 CET] <michaelni> didnt look yet, but is it SSE asm and misaligned access maybe ? [21:46:52 CET] <durandal_1707> it uses mov instruction [21:47:33 CET] <durandal_1707> for reading, for writing I can't remember [21:48:45 CET] <cone-348> ffmpeg 03Michael Niedermayer 07master:58f21b6c9354: avformat/hls: fix potential integer overflow [21:48:46 CET] <cone-348> ffmpeg 03Michael Niedermayer 07master:5c02c95f2c2a: avcodec/mpeg12: Fix error return [21:48:47 CET] <cone-348> ffmpeg 03Michael Niedermayer 07master:2e8ad2d65af5: avcodec/mpeg12: Remove duplicate block_last_index setting code [22:18:16 CET] <durandal_1707> michaelni: it seems to crash when x is not multiple of 8 [22:18:25 CET] <michaelni> durandal_1707, crash is due to misalgned access [22:24:36 CET] <durandal_1707> michaelni: so what should get fixed ? pad? [22:30:52 CET] <michaelni> if pad could produce aligned data that would be better/faster. Either way the code shouldnt crash [22:31:11 CET] <durandal2707> michaelni: shouldnt same happen with crop filter? [22:31:29 CET] <michaelni> yes, quite possible [22:32:17 CET] <durandal2707> but it doesnt [22:32:34 CET] <durandal2707> and why 8bit path is not affected? [22:36:36 CET] <wm4> so why can't we have a crop rectangle in AVFrame, instead of intentionally misnaligning image data [22:37:07 CET] <nevcairiel> why do you keep caring about top/left cropping, i have never even seen a sample that used it outside of fate =p [22:37:18 CET] <durandal2707> its planned to do in evil(tm) plan [22:39:01 CET] <wm4> nevcairiel: it does become a minor issue surprisingly often (not necessarily left/right, but width/height too... like non-mod-2 4:2:0) [22:40:49 CET] <nevcairiel> my stuff can deal with such conditions [22:41:50 CET] <wm4> mine too, by rounding up in all situations [22:46:54 CET] <ubitux> durandal2707: sometimes a new buffer is allocated [22:47:01 CET] <ubitux> durandal2707: that's what happens with w3dif [22:47:09 CET] <ubitux> iirc [22:48:35 CET] <durandal2707> w3fdif uses movu instructions [22:49:00 CET] <nevcairiel> it also reads half-vector sized data, so it needs to [22:50:00 CET] <durandal2707> actually w3fdif doesnt access buffers directly [22:52:42 CET] <d-fens_> hi, i couldn't find it in docs anywhere: is it possible to a time-based expression to any filter or does each filter have to support expressions individually? like using unsharp=luma_amount=sin(%t) for example? [22:52:50 CET] <d-fens_> *use [22:54:16 CET] <durandal2707> d-fens_: individually, if its mentioned in filter docs [22:54:51 CET] <d-fens_> durandal2707: thanks, thats a pity though [22:55:52 CET] <durandal2707> d-fens_: there is luascript filter in works [22:56:29 CET] <d-fens_> durandal2707: ok i gotta read up on this [22:58:05 CET] <d-fens_> durandal2707: what will thes filter allow me to do? [22:58:34 CET] <durandal2707> to change filter options each frame [22:58:54 CET] <durandal2707> for filters that do 1 in 1 out frame [22:59:33 CET] <ubitux> durandal2707: there are many mova in w3fdif [22:59:45 CET] <d-fens_> ah i see [23:00:15 CET] <d-fens_> durandal2707: anything to try out yet? [23:00:32 CET] <ubitux> durandal2707: and the reason it works is only because of av_frame_clone() afaict [23:00:47 CET] <ubitux> so something similar might happen in vfscale/pad [23:01:15 CET] <ubitux> BBB: find has a -delete option :p [23:01:23 CET] <BBB> on mac? [23:01:34 CET] <ubitux> good question [23:01:35 CET] <BBB> oh it does! [23:01:39 CET] <BBB> ++ [23:01:45 CET] <BBB> you awesome [23:02:05 CET] <durandal2707> ubitux: wtf you are talking about? [23:02:08 CET] <ubitux> on mac it has the annoying limitation of requiring the current dir [23:02:16 CET] <ubitux> (so you have to explicit the .) [23:02:24 CET] <ubitux> that's the only difference i know [23:02:46 CET] <ubitux> durandal2707: w3fdif clones the frame, so it gets a new aligned buffer, so the x86 asm using mova can work [23:03:04 CET] <ubitux> if it wasn't doing so, sth like crop=x=1,w3fdif would crash [23:03:08 CET] <durandal2707> ubitux: w3fdif doesnt use frame directly [23:03:17 CET] <durandal2707> and when it does it uses movh [23:03:43 CET] <ubitux> ok [23:04:28 CET] <durandal2707> not ok, you are repeating this w3fdif story over and over again [23:04:45 CET] <ubitux> because i probably didn't understand the first time [23:04:53 CET] <ubitux> so this is the 2nd time and now i get it :) [23:14:50 CET] <durandal2707> d-fens_: not yet [23:23:57 CET] <michaelni> Daemon404, are you available as GSoC mentor ? (we need to know approximately for "How many potential mentors have agreed to mentor this year?"), same question for others [23:25:08 CET] <michaelni> atomnuker,nevcairiel, durandal2707 , are you potentially available as mentor for GSoC ? [23:28:17 CET] <durandal2707> mentor for what? [23:29:18 CET] <michaelni> whatever you like [23:29:40 CET] <nevcairiel> I'll happily answer questions on IRC and assist in any way I can, but I'm not really guaranteed to be available, so i'm not available for any official roles [23:30:46 CET] <michaelni> iam asking because we need to give google some number of "potential mentors" and that likely will affect how many slots we get. would be crazy for google to give us more slots than we have mentors [23:31:38 CET] <michaelni> so if few people say "yes" now and later many have a great idea and student then we will be short on slots likely [23:38:04 CET] <durandal2707> what about motion interpolation for lavfi? [23:38:26 CET] <michaelni> durandal2707, yes perfect idea [23:39:09 CET] <michaelni> also please add it to the ideas page (https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016) [23:40:59 CET] <michaelni> also i would interpret "potential mentor" as "assuming theres a student who is well qualified for the project you wish to mentor, would you mentor him" [00:00:00 CET] --- Wed Feb 17 2016

1 0

ffmpeg.log.20160216
by burek 17 Feb '16

17 Feb '16

[00:03:01 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#nnedi [00:03:02 CET] <furq> neat [01:09:12 CET] <explodes> My AudioTrack decoding 5.1 audio is very very quiet [01:09:45 CET] <c_14> ac3? [01:10:02 CET] <explodes> Yea [01:10:37 CET] <c_14> tyr adding -drc_scale 1 [01:13:47 CET] <explodes> all lower case like that?\ [01:15:28 CET] <c_14> yep [02:31:43 CET] <explodes> ...Got my build box working again. -drc_scale 1 as CFLAGS is breaking things [02:38:58 CET] <explodes> I'm wondering if "-drc_scale 1" isn't a flag for the ffmpeg library, not for the build :P [02:51:42 CET] <J_Darnley> Why would you think otherwise? [02:55:51 CET] <furq> if only there were some way to find out [02:55:55 CET] <furq> http://sprunge.us/ASVe [02:55:57 CET] <furq> but there isn't [03:00:27 CET] <explodes> ..another library question: After I specify that I'm downmixing to stereo with av_opt_set_int(strm->swr, "out_channel_layout", outChannelLayout, 0), how can I get the new output sample rate? [03:26:57 CET] <explodes> yayy found the problem- [03:28:21 CET] <smdrz> trying to convert with h264_qsv, compains Error initializing an internal MFX session using ffmpeg 3.0 [03:28:22 CET] <smdrz> http://pastebin.com/tiQ0BHWn [03:29:40 CET] <smdrz> not using intel media server stufio, since i have all dependenciies installed such aslibva and libdrm [03:30:25 CET] <smdrz> using https://github.com/lu-zero/mfx_dispatch for comiling and linking for "--with-libmfx" [04:38:38 CET] <_Vi> Can FFmpeg show me sound spectrum as numbers to stdout (not as image such as in showspectrum filter)? [07:10:04 CET] <situation> Hmmm, no more h264_qsv in ffmpeg 3.0 ? [07:10:41 CET] <situation> my bad, nvm [07:10:47 CET] Action: dystopia slaps situation around a bit with a large trout [07:10:57 CET] <dystopia> such a n00b sit [07:13:05 CET] <situation> lol [09:38:52 CET] <frengo> http://pastebin.com/tjhfSikZ [09:39:02 CET] <frengo> http://pastebin.com/0Apa3D3W [10:21:47 CET] <andrey_utkin> Hi, I'm interested in subtleties with H.264 Annex B vs AVCC. Willing to pay for good consulting with explanations why things work. The question is related to joining video clips of different origin. Joining AnnexB (mpegts) files work and with AVCC (MP4 container) it doesn't which I assume is legit. But if you convert this joined file to MP4, it still works. I wonder why. [10:56:01 CET] <termos> I'm unsure of how to set the AVCodecContext::level, is it just an integer where level 3.1 would be the integer 31? [11:04:37 CET] <jkqxz> termos: libavcodec does not define level generically; the interpretation depends entirely on the codec you are using. [11:05:26 CET] <termos> ah, it's x264 should have mentioned. I noticed this line x4->params.i_level_idc = avctx->level; [11:07:40 CET] <jkqxz> Sure. Then it is indeed ten times the level number, as you suggested. [11:08:21 CET] <termos> that's a much better way of thinking of it, thanks [11:28:42 CET] <sono> how do i extract X seconds starting at time Y from a video, and encode it (with a reasonable quality) in a commandline? [11:31:08 CET] <grublet> sono: -ss and -t [11:31:53 CET] <grublet> ffmpeg -ss timecode -i infile.ext -t seconds [other params] outfile.ext [11:32:14 CET] <sono> grublet: cool :) thanks [11:32:31 CET] <grublet> np let me know if you have any more issues and if i don't know someone else surely will help [11:33:07 CET] <sono> what do you recommend as an encoding? i captured old HI8 tapes and want to encode to share with family online; no need for very good quality [11:35:22 CET] <grublet> sono: will they be downloading it to view it or will you be putting it on a site like youtube? [11:36:24 CET] <sono> grublet: most likely on a private sharing website, but not sure yet if streaming or download [11:36:28 CET] <sono> google drive allows both i think [11:38:59 CET] <grublet> sono: are you aware of their brwoser or media players file format support? because that will determine a lot of options as well [11:40:12 CET] <sono> grublet: it will be chrome or vlc [11:46:58 CET] <grublet> sono: before i suggest anything, what format is the video right now? if it's already compressed you can just use -c:v copy -c:a copy [11:47:21 CET] <grublet> if they have vlc then container format shouldnt be much of an issue [11:47:59 CET] <sono> grublet: no it's not compressed; i don't have access to the files right now but they're huge (3GB for 20 minutes i think), and they were captured raw [11:48:11 CET] <sono> they're in mp4 though iirc [11:48:30 CET] <grublet> sono: do you know their resolution? [11:48:36 CET] <grublet> or framerate [11:50:05 CET] <sono> sorry not sure, maybe 720p [11:57:17 CET] <grublet> sono: i'd try something like -c:v libx264 -preset slow -crf 24 for the video [12:00:02 CET] <dystopia> -crf 24 will give you a very low bitrate [12:00:14 CET] <dystopia> i would up it to like -crf 17 or 18 [12:00:49 CET] <grublet> dystopia: i was thinking of file size, 24 may be too low but id try something around 20 first [12:01:55 CET] <grublet> i did most of my encoding when 1080p was difficult for a computer to decode so i'm still operating from that mindset so sono i suggest you let dystopia or someone else more up to date guide you from here [12:03:24 CET] <onodera> Hi, I'm trying to compile the latest ffmpeg git master, and keep getting this: [12:03:24 CET] <sono> grublet: dystopia: thanks i'll do some tests [12:03:25 CET] <onodera> make: *** No rule to make target 'libavcodec/x86/dirac_dwt.c', needed by 'libavcodec/x86/dirac_dwt.o'. Stop. [12:03:44 CET] <onodera> does anyone know why this happens, google doesn't give me any relevant results [12:05:13 CET] <saste> onodera: try to fix with make distclean [12:05:21 CET] <jkqxz> onodera: Run "make clean". You've built it before in the same tree and some old dependencies are still there. [12:05:27 CET] <onodera> ah thanks [12:30:13 CET] <Bluez_> hey guys, im still loosing hair trying to figure out why quicktime doesnt see my AAC audio at all (media information doesnt even show an aac track) :/ [12:30:18 CET] <thunfisch> hi! is there a easy way to crop different regions depending on timemarks? say, i've got a list (format doesn't matter to me) which has timestamps and a associated region. can i pass this list on to ffmpeg, so it automatically varies the crop region? or do i first have to split the sections, crop them separately and then reassemble? [12:30:21 CET] <Bluez_> i posted on the list here: http://libav-users.943685.n4.nabble.com/Libav-user-h264-aac-in-quicktime-co… [12:30:27 CET] <Bluez_> if anyone has any ideas (^^code) [12:31:22 CET] <thunfisch> i've seen in the documentation that you can pass on mathematical functions to vary the cropregion, but didn't see any info on how to do this the way i want (which would be a stepped function essentially) [12:44:37 CET] <ritsuka> Bluez_: did you set the es descriptor for the aac track? [12:45:11 CET] <Bluez_> hmm no :/ [12:45:32 CET] <ritsuka> then you just found the problem [12:45:56 CET] <Bluez_> :) thanks! [12:46:03 CET] <Bluez_> looking now for an example on how to set it [12:54:23 CET] <DHE> which should be faster? deinterlace, scale, encode or leaving it interlacing and scaling+encoding aware mode [12:56:22 CET] <grublet> DHE: is the material already compressed? most media players can deinterlace and upscale during playback [12:57:01 CET] <grublet> if you're trying to compress, some encoders like x264 can handle interlaced content [12:59:40 CET] <DHE> yes, I'm concerned about performance in encoding. it's pretty high-res and I need real-time [13:00:43 CET] <grublet> DHE: realtime encoding? what is the current file format and audio/video codec. is the material already compressed or is it uncompressed/lossless [13:01:48 CET] <Bluez_> ritsuka: hmm do you mean where i do AVStream *audioStream = avformat_new_stream(c->oc, NULL); and setup the codec type etc? [13:02:42 CET] <ritsuka> yes, like you set the extradata for the video track, you need to set the extradata in the audio track too [13:03:50 CET] <Bluez_> oh, any example of how i might do that? [13:51:19 CET] <j03> Hi all. I have a folder full of images, with sequential filenames, but not in increments of one - for instance, I have 00000.png, 00060.png, 00120.png. Is there way of passing in a "step" value when converting this series of images to video? [13:51:44 CET] <j03> I think I can use globbing -- will that preserve the order of my images? [13:56:33 CET] <brontosaurusrex> j03: what i did in past is generate soft links in tmp [13:56:50 CET] <brontosaurusrex> and then feed that to ffmpeg [13:57:16 CET] <j03> soft links with with numerical step of 1? [13:57:26 CET] <brontosaurusrex> yes [13:57:54 CET] <brontosaurusrex> i can find the script if you want [13:58:12 CET] <j03> if it's to hand then that would be great! Don't worry if you can't find it, though! [14:01:36 CET] <brontosaurusrex> j03: full thing http://paste.debian.net/391526/ (you probably want things from line 100) [14:02:18 CET] <j03> brontosaurusrex: that's awesome - thank you! i'll give it a try later this afternoon. [14:21:36 CET] <Bluez_> ritsuka: that fixed it :) thanks! [14:25:24 CET] <DHE> grublet: mpeg2 [14:25:32 CET] <DHE> and AC3 [14:42:05 CET] <grublet> DHE: I'm assuming it's a DVD or Blu-ray source, in which case I'd suggest letting your media player deinterlace/upscale on the fly. most decoders now have GPU acceleration [14:59:40 CET] <DHE> grublet: no, it's a over-the-air source from an ATSC receiver. it's all 1080i up there [15:00:07 CET] <Mavrik> DHE, deinterlacer is pretty CPU intensive [15:00:11 CET] <Mavrik> so keep it interlaced [15:00:24 CET] <Mavrik> But also keep in mind that interlaced streams are way less efficient in new codecs. [15:02:15 CET] <brontosaurusrex> do AVC decoders in TVs support interlaced decoding at all? [15:02:48 CET] <DHE> HDMI does carry whether the image being sent is interlaced or not. any good TV should then deal with the signal [15:03:23 CET] <DHE> but in my scenario I am transcoding to H264 after scaling it down (bandwidth and all) [15:04:23 CET] <Mavrik> brontosaurusrex, of course. [15:04:49 CET] <Mavrik> brontosaurusrex, interlaced content is still the majority in broadcast TV [15:05:24 CET] <DHE> yeah... it sucks.. [15:05:32 CET] <Mavrik> DHE, yeah, I'm regularly seeing yadif eat like 5-15% CPU time of live reencode [15:05:50 CET] <Mavrik> (x264 medium or fast preset) [15:06:06 CET] <DHE> yeah, and I'd love to get that back, but not if deinterlaced scaling and encoding will just use 10-20% instead [15:06:46 CET] <Mavrik> m? [15:11:52 CET] <brontosaurusrex> Mavrik: right, stupid questions I have this days .... [15:12:18 CET] <Mavrik> :) [15:12:36 CET] <Mavrik> Here all DVB TV has to be broadcast with AVC. [15:12:46 CET] <brontosaurusrex> yeah, same here [15:12:53 CET] <Mavrik> And pretty much everyone standardized on 1080i for HD channels. [15:13:01 CET] <brontosaurusrex> right [15:14:59 CET] <DHE> here's it all mpeg2... [15:15:21 CET] <DHE> it's pretty much all 720p or 1080i with the latter being much more common [15:15:44 CET] <DHE> one channel in the area actually sends both HD and SD versions on the same frequency.... dunno why but they do [15:15:58 CET] <bencoh> DHE: vertical scaling of interlaced content without de-interlacing (or special handling) is usually not a good idea :) [15:16:21 CET] <DHE> the scale filter in ffmpeg has interlacing support... [15:16:44 CET] <bencoh> ah right you can use that :) [15:17:45 CET] <bencoh> depending on your receivers and your bandwitdh reduction needs, you might get away with horizontal downscaling and a different SAR, by the way [15:17:47 CET] <xace> im sshing into my windows machine (using cygwin) and converting a movie file. however I can't seem to press Q to cancel the conversion, ctrl-c seems to corrupt the file. any ideas on how to solve this? [15:17:57 CET] <bencoh> (soomething like half-width scaling) [15:18:04 CET] <bencoh> (without deinterlacing, that is) [15:21:31 CET] <DHE> bencoh: ... interesting idea... [15:21:55 CET] <DHE> I was going to scale it way down, to like 480 [15:22:02 CET] <bencoh> from? [15:22:09 CET] <DHE> 1080 [15:22:17 CET] <bencoh> mpeg2 1080i? [15:22:36 CET] <DHE> yeah that [15:23:25 CET] <bencoh> how much bw do they need for 1080i mpeg2 to look "good"? [15:24:05 CET] <DHE> something like 12-15 megabits. the frequency carries a peak of ~18 megabits [15:25:08 CET] <DHE> the bitrate varies so it's hard to get a good measurement [15:27:20 CET] <Mavrik> bencoh, I've seen something like 15-20Mbit mostly [15:27:37 CET] <Mavrik> I think DVB-C here mostly had 25MBit CBR reserved [15:28:52 CET] <andrey_utkin> Hi, I'm interested in subtleties with H.264 Annex B vs AVCC. Willing to pay for good consulting with explanations why things work. The question is related to joining video clips of different origin. Joining AnnexB (mpegts) files work and with AVCC (MP4 container) it doesn't which I assume is legit. But if you convert this joined file to MP4, it still works. I wonder why. [15:29:36 CET] <Mavrik> andrey_utkin, how are you joining stuff? [15:32:52 CET] <andrey_utkin> Mavrik: let's say I have clips A, B, C of same origin and properties (not necessarily encoded by ffmpeg), and then I need to apply filters (and reencode) B clip and concatenate A, B, C clips into single video clip. Concat demuxer does this job, but the resulting file plays fine only if concat is fed with MPEG TS files containing Annex B formatted video data. [15:33:00 CET] <mbeacom> Does anyone happen to know if ffmpeg's autorotate functionality works with an RTMP source (i.e. an iPhone streaming via RTMP) and the orientation changes from landscape to portrait. Does ffmpeg pass the Rotation metadata to the outputs (in this case, it splits output to HLS and generates a recorded FLV that gets -copyts'd to MP4. [15:34:21 CET] <andrey_utkin> I have all input files in MP4 (AVCC H264 format), and I wonder can I avoid translation of all files to Annex B and then back to MP4/AVCC (in case output must be also MP4) [15:35:43 CET] <andrey_utkin> mbeacom: can ffmpeg be anyhow related to autorotate on iphone? [15:36:43 CET] <Mavrik> andrey_utkin, that's strange [15:36:48 CET] <Mavrik> I guess it might be SPS/PSS related [15:37:04 CET] <mbeacom> @andrey_utkin ... the iPhone is streaming video and audio via RTMP... ffmpeg is transcoding the data being pulled from the RTMP server... [15:37:54 CET] <andrey_utkin> yes, MP4 (AVCC) format seems to store PPS/SPS data in file header (global extradata), and MPEG TS (Annex B) has this data in each keyframe [15:38:26 CET] <Mavrik> andrey_utkin, one explanation would be that you have different image parameter set (since you're not really reenconding a stream). [15:38:27 CET] <andrey_utkin> that's it, i just wanted to consult about the subtleties of it, to figure out what are possible optimizations [15:38:36 CET] <mbeacom> @andrey_utkin ffmpeg is outputting four separate HLS streams, a thumbnail, and a recorded FLV that gets -copyts'd to MP4. [15:38:42 CET] <Mavrik> MPEG-TS carries SPS/PSS in front of each I-frame so players will reconfigure that. [15:38:42 CET] <andrey_utkin> Mavrik: i know that [15:38:52 CET] <Mavrik> While MP4 doesn't... which means that players will crash hard when they get new frames. [15:39:50 CET] <andrey_utkin> what I wonder about is (how) can I mux straight to MP4 and not to transitional MPEGTS, because it still works when I convert back from MPEGTS to MP4. [15:52:59 CET] <mbeacom> andrey_utkin: Did you have anything else to add to that statement posed as a question? [15:53:27 CET] <Mavrik> andrey_utkin, hmm... that sounds like a bug in ffmpeg :/ [15:54:24 CET] <bencoh> andrey_utkin: how do you "convert" back to mp4? codec copy, or transcoding? [15:55:12 CET] <andrey_utkin> bencoh: yes, codec copy [15:57:10 CET] <bencoh> have you tried comparing the extradatas? [15:57:58 CET] <andrey_utkin> mbeacom: the actual question is a bit hard to address because demonstration scripts would be needed, and on my sample data the concat demuxer produces broken files (due to lack of handling of different timebases). So a bit of patching is needed, or usage of custom app. I haven't yet made this all clean enough to make consolidated help request. Maybe a bit later. [16:53:45 CET] <xace> looking at https://www.ffmpeg.org/ffmpeg-devices.html#toc-gdigrab . running `ffmpeg -f gdigrab -framerate 6 -i desktop out.mpg` results in "Output file #0 does not contain any stream" what am i doing wrong? windows 8.1 [16:55:05 CET] <xace> http://pastebin.com/RS2ggWC0 [16:57:13 CET] <shincodex> it means your video has no streams audio, ass titles, video. which would seem to indicate your file isnt a file. [16:57:49 CET] <shincodex> oh your doing capture [16:57:52 CET] <J_Darnley> Try reading his paste to see the actual error [16:57:54 CET] <shincodex> it probably is broken. [16:58:13 CET] <xace> shincodex: i took it form the ffmpeg site. i figured those examples should work [16:58:17 CET] <J_Darnley> Rather than what the user thinks is the error because its the last line. [16:58:42 CET] <xace> J_Darnley: are you referring to the [gdigrab @ 00000049bf5cb120] Failed to capture image (error 5) ? [16:58:46 CET] <xace> not sure how to fix that tbh [16:59:03 CET] <kepstin> xace: that means that the windows api being used to grab a frame image is failing [16:59:05 CET] <J_Darnley> Niether am I (but I will look at the source to see the meaning) [16:59:22 CET] <J_Darnley> I mean why wouldn't you paste that in the first place? [16:59:35 CET] <kepstin> need to look up the error number on msdn (with the function that's failing) to find out what's going on :/ [17:00:24 CET] <kepstin> lets see... that's the BitBlt off the screen pixmap failing. [17:01:21 CET] <kepstin> error 5 is ... access denied [17:01:37 CET] <kepstin> however you're running the ffmpeg process, it doesn't have permission to grab the screen image. [17:02:03 CET] <xace> should i run ffmpeg as administrator? [17:02:23 CET] <kepstin> it could be that you're running ffmpeg as a different user than the logged in user, or some running app has restricted screencapture maybe? [17:02:29 CET] <kepstin> dunno what could cause that [17:02:31 CET] <shincodex> run all as administrator/root UAC is not good concept in any os [17:02:41 CET] <xace> yeah, henhce me hesitating on running as admin [17:02:48 CET] <shincodex> huehuehuehue [17:03:03 CET] <kepstin> it should be fine running it as the same user as you logged in with in most cases. [17:04:06 CET] <theFam> Hello everyone. [17:05:00 CET] <J_Darnley> POS ISP [17:07:26 CET] <theFam> I am currently using ffmpeg on Arch Linux ARM. When I use the command "ffmpeg -i ./Comp\ 1.mp4 -c:v libx264 -q:v 1 -c:a copy Tristam\ -\ Once\ Again.mp4" ffmpeg crashes. fish says "fish: ffmpeg -i ./Comp\ 1.mp4 -c:v li& terminated by signal SIGKILL (Forced quit)". What could be the cause? [17:09:35 CET] <kepstin> theFam: something sent a SIGKILL to the ffmpeg process [17:09:50 CET] <kepstin> theFam: check dmesg; the cause might be the OOM-killer (you ran out of memory) [17:10:19 CET] <theFam> kepstin: possibly o.O let me check [17:10:39 CET] <theFam> kepstin: do i just grep? [17:11:00 CET] <kepstin> theFam: just look near the end of dmesg, the oom killer spews a lot of output that's pretty noticable. [17:11:08 CET] <theFam> kepstin: yes, it's an out of memory thing [17:11:22 CET] <theFam> [174712.130106] c0 20486 Out of memory: Kill process 20360 (ffmpeg) score 384 or sacrifice child [17:11:32 CET] <theFam> how do i make it not do that [17:11:44 CET] <kepstin> use a machine with more ram ;) [17:11:56 CET] <theFam> kepstin: No machines available atm [17:12:02 CET] <kepstin> alternately, make sure you're using only one thread in libx264, and reduce the number of reference frames it's using [17:12:21 CET] <kepstin> kill other processes on the machine that you don't need :) [17:12:21 CET] <theFam> kepstin: what arguments? I'm kinda new to ffmpeg [17:12:37 CET] <theFam> --threads 1?? [17:13:04 CET] <theFam> kepstin: is 200MB not enough for ffmpeg? [17:13:49 CET] <kepstin> theFam: modern video encoders (like x264) buffer multiple raw frames in memory to look for places where the compression can re-use data. In high quality modes, this can use a lot of ram. [17:14:02 CET] <theFam> hmm [17:14:16 CET] <kepstin> (and you might need ram for reference frames on the decoding side too) [17:14:26 CET] <theFam> kepstin: I need to google how to lower referce frames, I guess. :/ [17:14:44 CET] <furq> theFam: try using a faster preset [17:14:53 CET] <kepstin> yeah, that's probably easiest. [17:15:39 CET] <J_Darnley> -refs 1 -threads 1 [17:15:49 CET] <theFam> J_Darnley: savior [17:15:58 CET] <theFam> kepstin: thanks for the help. [17:21:55 CET] <theFam> if I want to keep high quality on a h264 video but smaller size, what crf value should i go for? [17:23:00 CET] <kepstin> theFam: you'll really want a more powerful system for that, with that ram limit you can't really use the more efficient encoding modes. [17:23:58 CET] <theFam> kepstin: I understand, what is a more space-efficient encoding method? Just wondering. [17:24:42 CET] <kepstin> to increase efficiency, you'll want to use one of the slower presets (e.g. "veryslow") with no limit on reference frames. [17:25:28 CET] <kepstin> with the reference frame limit you have atm, depending on the source video you can probably choose between 'smaller' and 'about the same quality', but not both at the same time :) [17:25:44 CET] <theFam> i see [17:25:53 CET] <theFam> let me try something [17:26:42 CET] <theFam> hahaha [17:27:01 CET] <theFam> running ffmpeg is a really easy way to clear ram [17:27:14 CET] <theFam> because androids kills everything :^) [17:30:46 CET] <theFam> ffmpeg always dies at 40 frames :( [17:38:47 CET] <EmleyMoo1> I recently acquired a NextBase "Duo" dashcam, and am wondering if ffmpeg could help me do the following (not all together): (1) lop off the black areas top and bottom (2) cut the left or right half off the video (3) include the top, say, 10% of the left half and the bottom 90% of the right half in the output. [17:40:33 CET] <kepstin> EmleyMoo1: yeah, that could all be done with various combinations of the crop, overlay, hstack, vstack filters. [17:45:01 CET] <furq> theFam: if you're on android you'll probably want to use a fast preset anyway so the encode doesn't take forever [17:47:06 CET] <theFam> furq: thanks [17:47:36 CET] <furq> also i guess from your question about crf that you already figured this out, but don't use -q:v with x264 [17:52:03 CET] Action: EmleyMoor is testing "crop" right now! [17:53:39 CET] <EmleyMoor> Nice! [17:56:00 CET] <EmleyMoor> Sadly I have to go out now, but it is probably not going to take me long to get used to this [19:04:09 CET] <shincodex> perhaps you are doing it... breaking pthread_exit [19:04:21 CET] <shincodex> Im wondering iff ffmpeg has broken thread logic [19:04:31 CET] <shincodex> I dont configure in pthread explicitly nor do i disable it [19:04:40 CET] <shincodex> yet i call pthread_exit() in main and it hangs. [19:04:54 CET] <shincodex> All my threads are joined up.... so i wonder if ffmpeg doesnt handle threads correctly [19:08:32 CET] <shincodex> or perhaps hyperthreading is broken? [19:10:55 CET] <furq> yeah it's probably an intel bug and not your code [19:15:33 CET] <shincodex> one is a i7 [19:15:43 CET] <shincodex> another is a i7 but throttled for some rugged environment [19:15:51 CET] <shincodex> so my only option is to what [19:15:53 CET] <shincodex> Abort( [19:15:54 CET] <shincodex> exit? [19:16:25 CET] <shincodex> raise sig div 0? [19:16:25 CET] <kepstin> shincodex: the most likely thing I can think of is that you're not fully flushing/closing some codecs or streams in ffmpeg. [19:16:42 CET] <shincodex> its a network stream [19:16:43 CET] <kepstin> without knowing what's in your code it could be anything, including not related to ffmpeg at all [19:16:48 CET] <shincodex> and i can the stream purposely. [19:17:04 CET] <shincodex> meaning i reboot the machine that does the stream hence av_read_frame returns 0 [19:17:17 CET] <shincodex> i call it a few more times 15 second wait times to keep trying the connection [19:17:20 CET] <shincodex> then i eventually give up [19:17:30 CET] <shincodex> and my close process is this... [19:19:45 CET] <shincodex> http://pastebin.com/7V5wp8cS [19:20:38 CET] <shincodex> it probably has nothing to do with ffmpeg [19:20:42 CET] <shincodex> but i saw pthread_cancel [19:20:51 CET] <shincodex> then somebody bitching on the internet how using the function is wrong [19:21:16 CET] <shincodex> i switched my two threads from cancel to join and can my while loops but i die in pthread_exit() [19:21:25 CET] <shincodex> i assumed it was cause cancel is bad. [19:22:00 CET] <Abbott> I am trying to extract all frames for editing using "ffmpeg -i file.mp4 -r 1/1 $filename%03d.bmp" but this only extracts 5 frames for a video that is ~2 seconds long, where I was expecting something more like 48 frames. Is there some other/different flag I need to use to extract ALL frames? [19:22:37 CET] <kepstin> Abbott: using "-r" as an output option (after -i) causes it to drop frames to convert the rate to 1fps [19:22:48 CET] <kepstin> Abbott: you probably just want to completely remove the -r option [19:23:07 CET] <Abbott> my end goal is to extract frames from a video, edit them in photoshop, then sip them back up into an mp4 or some other container [19:23:24 CET] <Abbott> kepstin: okay so just do "ffmpeg -i file.mpg 1/1 $filename%03d.bmp" ? [19:23:38 CET] <kepstin> remove the argument to the -r option as well... [19:23:52 CET] <Abbott> lol whoops [19:24:21 CET] <shincodex> you know what? Do I even need to pthread_exit from main thread [19:24:26 CET] <shincodex> the program is dieing right here anyways. [19:24:40 CET] <Abbott> kepstin: that looks like it did it. I got 89 frames that time [19:24:40 CET] <shincodex> i know in windows its very nice about humans leaking shit [19:24:47 CET] <Abbott> thank you! [19:26:17 CET] <kepstin> Abbott: if you think the input file might have variable framerate, you might want to use the '-r' option to normalize it, so the timing doesn't get messed up when you turn it back into a video. In that case, you pick an argument to -r that's close to the nominal rate of the file [19:27:11 CET] <Abbott> kepstin: I didn't even think of that. I'll check if my phone encodes with a variable framerate [19:30:21 CET] <shincodex> I figure this now.... [19:30:24 CET] <shincodex> I use C++ [19:30:31 CET] <shincodex> Im wondering if that exit is just crap. [19:30:51 CET] <shincodex> like free(thismemorywasnewedincpluspluss); [19:34:48 CET] <Alina-malina> How to split a large avi file into 3 or 4 parts with ffpmeg? [19:35:36 CET] <shincodex> i ditched pthread_exit() and just allowed main to return 0; which is supposed to be same thing even on main thread [19:35:44 CET] <shincodex> problem seems to go away on box b where process goes defunct [20:05:55 CET] <ChocolateArmpits> Alina-malina: https://www.ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_… [20:09:15 CET] <haroldm> is there a way to apply external filters to an ffplay instance? [20:09:32 CET] <haroldm> such as ffdshow using avisynth [20:10:15 CET] <Alina-malina> olololo thanks ChocolateArmpits [20:11:09 CET] <furq> haroldm: you can use an avs script as input to ffmpeg, maybe it works with ffplay too [20:12:03 CET] <haroldm> right now I'm opening my capture device in media player classic and filtering it through ffdshow http://puu.sh/nak3B/56e5bca8f8.png [20:12:20 CET] <haroldm> but I'd like to just run it through ffplay so I'm a bit confused how it would be set up [20:12:53 CET] <haroldm> mainly because I'm having a ton of issues with mpc adding a ton of extra filters I'm not trying to use [20:13:58 CET] <haroldm> I tried solely using ffplay to capture and apply filters but it had pretty bad slowdown [20:14:41 CET] <furq> haroldm: ffplay -i myscript.avs [20:16:02 CET] <haroldm> @furq that would be included along with the device in ffplay correct? I don't think there's a way to capture from within avisynth [20:18:55 CET] <furq> oh i didn't see that bit [20:19:01 CET] <furq> idk if that's possible then [20:19:30 CET] <haroldm> well could it be something like ffplay -f dshow -i myscript.avs video="DEVICE" [20:19:58 CET] <furq> that wouldn't pass the input to the avisynth script [20:20:05 CET] <haroldm> oh yeah [20:23:02 CET] <haroldm> is there a way to filter the capture without bad slowdown? [20:23:11 CET] <haroldm> using only ffplay? [20:23:40 CET] <haroldm> had something like this [20:23:42 CET] <haroldm> ffplay -f dshow -i video="DEVICE":audio="DEVICE" -top 1 -vf "separatefields, crop=644:224:40:8, scale=600:224:flags=bicubic, scale=600:448:flags=neighbor" [20:23:50 CET] <haroldm> but it would drop frames like crazy [20:24:10 CET] <haroldm> not sure how avisynth can handle it [20:28:46 CET] <Zerowalker> Is it possible to make non-interleaved AVI with ffmpeg? [20:34:58 CET] <kepstin> a non-interleaved "audio-video-interleave" file? ;) [20:35:08 CET] <kepstin> that said, there might be some format options that could do that. [20:38:19 CET] <durandal_1707> Nope, bad idea [20:55:03 CET] <Zerowalker> Virtualdub, though it's kinda controversial. Thanks for answering:) [21:05:03 CET] <durandal_1707> Why you want to do that? [21:08:42 CET] <Zerowalker> trying to figure out a way to get audio from an AVI file without having to load through the entire file, takes awhile when it's over 100gb;p [21:09:58 CET] <furq> remux it to something that's not avi? [21:10:22 CET] <J_Darnley> How are you going to make a not-interlaved AVI file without reading it all (then writing another)? [21:12:06 CET] <Zerowalker> I am recording and it saves to an AVI, but i thought that if i could make that AVI non-interleaved it would be easy to access the audio [21:12:45 CET] <durandal_1707> interesting, buy SSD [21:12:50 CET] <Zerowalker> It's complicated, but i access the audio several times from the file, but it's so damn slow as i need to read the entire file, even though the audio is small. Yes i can extract it, but i am trying to fine a one way solution;p [21:13:12 CET] <Zerowalker> well, recordings several 100 of GB on an SSD isn't that great;p [21:13:42 CET] <Zerowalker> But yeah seems like there isn't much of a solution, was worth looking it up though. [21:13:51 CET] <furq> the solution is to not use avi [21:16:00 CET] <Zerowalker> MKV is worse for my use, the best way would be to have the video and audio separate [21:18:20 CET] <uberushaximus> then just demux the file [21:18:41 CET] <uberushaximus> I mean, you're going to have to read the whole thing no matter what I assume [21:18:49 CET] <kepstin> if it would be best to have the video and audio separate, well, that's simple enough to do with ffmpeg... [21:19:28 CET] <Zerowalker> Yeah i know ,it's just that it basically takes the same amount of time as i usually read it twice. [21:20:37 CET] <Zerowalker> And well it's OBS that's using ffmpeg to encode, so i don't have that option to not mux them, i think. But well it's not a extremely important thing, was just looking for a way to solve it other than demuxing, but it seems there wasn't such a way, thanks:) [22:15:48 CET] <milbarge> Hi, is there documentation for the new protocol whitelist feature in 3.0? I've been looking but can't find any. [22:19:47 CET] <milbarge> I ask because I am getting a "Protocol not on whitelist 'file'!" error when trying to input from an rtp stream via an sdp file. It worked on 2.8.6 and I'm wondering if I'm missing somthing. http://pastebin.com/zvvdxjHs [22:43:01 CET] <d-fens_> hi, i try to animate some parameters like unsharp=luma_amount=sin\(%t) , but i only get parse errors, how is that done correctly? [23:03:35 CET] <d-fens_> nevermind, not possible yet [23:03:55 CET] <d-fens_> each filter has to support expressions individually [23:04:29 CET] <J_Darnley> ah yes [23:04:40 CET] <J_Darnley> I guess that one doesn't then [23:20:28 CET] <NetworkingPro> Hey everyone, I am having a hard time figuring out what I need to know. Specifically, I have an IP Camera using Live555/RTSP, and Im wanting to rebroadcast it. [23:20:41 CET] <NetworkingPro> Im not sure what to set the output to in order to correctly transcode it. [23:20:48 CET] <NetworkingPro> or rebroadcast? [23:21:50 CET] <NetworkingPro> ffmpeg -i rtsp://admin:password@172.31.84.59/streaming/channels/101/ -vcodec libx264 -tune zerolatency -crf 18 -f rtsp -muxdelay 0.1 rtsp://0.0.0.0:51840?timeout=0 [23:26:45 CET] <furq> ffmpeg isn't an rtsp server [23:47:20 CET] <cyphix> Hi. I'm still trying to improve my mediacrush server to be faster. I recompiled ffmpeg with less options, but it still runs at 0.5 fps. Here is the output of the command: https://p.cyphix.org/view/94e63120. Any suggestion on what is causing it to work so slow is welcome... [23:48:24 CET] <furq> single threaded 1080p vp9 is slow [23:48:29 CET] <furq> vp9 is slow in general [23:48:52 CET] <c_14> That's vp8 [23:48:52 CET] <J_Darnley> What CPU does that machine have? [23:48:55 CET] <c_14> Still slow though [23:49:09 CET] <TD-Linux> you're using an ancient libvpx [23:49:23 CET] Action: J_Darnley should patch ffmpeg to always print the cpu flags [23:49:36 CET] <cyphix> TD-Linux: Me? [23:49:44 CET] <TD-Linux> cyphix, yes [23:49:57 CET] <cyphix> TD-Linux: Ok, how can I update it? [23:49:58 CET] <TD-Linux> also -crf 5, that's a bit high [23:50:08 CET] <furq> yeah -crf 5 -b:v 5M seems like a bad choice [23:50:12 CET] <TD-Linux> cyphix, I dunno, update your distro? [23:50:47 CET] <c_14> Or build from source or get a static build [23:51:01 CET] <TD-Linux> cyphix, also you can set speed options to libvpx to make it go faster [23:51:43 CET] <TD-Linux> try -speed 4 or something [23:53:18 CET] <cyphix> On my gentoo machine, which I guess is a bit more up to date, it runs at 4 fps. It's better, but I'm still surprised it's that slow. Am I right to assume that for a 30fps video, it will take about 8 times the length of the video to process? [23:54:59 CET] <TD-Linux> cyphix, yes. if you want it to go faster use -speed or update libvpx or both [23:55:37 CET] <cyphix> ok, the -speed option helps a lot. What about this -crf 5 option? What value should I give it? [23:55:55 CET] <TD-Linux> it's actually probably totally ignored with those settings, it'll just target a bitrate which might be ok for you [23:56:15 CET] <TD-Linux> cyphix, a higher -speed number makes it go faster. so you can just crank that up until it's as fast as you want [23:56:23 CET] <TD-Linux> of course this comes at a loss of quality [23:57:10 CET] <cyphix> Ok, I'll se what's the good balance then [23:59:00 CET] <cyphix> Mhmmm... I can reach 30fps on my gentoo machine, but my debian server goes at 6fps max. Is upgrading libvpx the only remaining solution? Aren't there other options I could tweak (maybe with a loss of quality) to gain speed? [00:00:00 CET] --- Wed Feb 17 2016

1 0

ffmpeg-devel.log.20160215
by burek 16 Feb '16

16 Feb '16

[00:02:55 CET] <cone-139> ffmpeg 03James Almer 07master:73a4589d4b0d: x86: add some more helper macros to check for slow cpuflags [00:02:56 CET] <cone-139> ffmpeg 03James Almer 07master:70d685a77f28: x86: use the new helper macros where useful [00:04:58 CET] <cone-139> ffmpeg 03James Almer 07release/3.0:1e8a75fae479: x86: add some more helper macros to check for slow cpuflags [00:04:59 CET] <cone-139> ffmpeg 03James Almer 07release/3.0:4d9520793825: x86: use the new helper macros where useful [00:12:10 CET] <cone-139> ffmpeg 03Metaksakis Georgios 07master:00c73c475e3d: lavd/gdigrab: mouse dpi awareness [00:20:12 CET] <J_Darnley> What kind of C library API do people here like? Public option struct? Option get/set functions? 1 get/1 set function with key-value pairs? Is there a specific one you find neat? [00:22:46 CET] <Timothy_Gu> i guess the current norm is option get/set func [00:22:49 CET] <Timothy_Gu> like AVOption [00:34:11 CET] <nevcairiel> J_Darnley: i like structs, but they require a rather fixed ABI so its always a balancing act [00:35:01 CET] <nevcairiel> other than that specific get/set functions probably, generic get/set like AVOption I would only use if there is really a million options to control like in ffmpeg [00:48:49 CET] <J_Darnley> I might go with a struct for now. [00:49:06 CET] <J_Darnley> My 1 user thought my original public struct was neat. [01:28:56 CET] <kierank> Timothy_Gu: added multilib [01:32:38 CET] <michaelni> Timothy_Gu, btw, looking at fatebeta, i wonder if in addition to the "Last Good Rev" the "First Bad Rev" could be shown too, this could be useful if someone wants to bisect a bug [01:36:23 CET] <Timothy_Gu> michaelni: indeed it could be added [01:36:48 CET] <Timothy_Gu> michaelni: but I really want to first migrate to a "proper" database system before such features are added [01:37:10 CET] <michaelni> sure ... was thinking about it as i wondered what broke: http://fatebeta.ffmpeg.org/report/ppc64be-RHEL7.0-gcc-4.8.2-ibmcrl/20160214… [01:37:15 CET] <Timothy_Gu> fate.f.o doesn't use SSD, and parsing CSV is fairly slow [01:40:27 CET] <Timothy_Gu> kierank: cool, thanks [01:40:47 CET] <michaelni> Timothy_Gu, btw, do we have backups of fate.f.o ? if not you should probably make backups [01:41:29 CET] <michaelni> also if we need a box with SSDs we could ask if someone would donate one [01:41:35 CET] <Timothy_Gu> michaelni: no [01:41:45 CET] <Timothy_Gu> I don't have 200 GB of free space... [01:42:11 CET] <Timothy_Gu> which again leads to my wanting to migrate this to a proper database [01:42:21 CET] <Timothy_Gu> MongoDB has autobackup ("sharding") [01:42:31 CET] <Timothy_Gu> and is a lot faster [01:46:37 CET] <michaelni> do we have backups of fate.f.o minus the actual "database/csv" ? that should be alot smaller and is more important too [01:46:52 CET] <Timothy_Gu> michaelni: no [01:47:14 CET] <Timothy_Gu> can you do exclusion in rsync? [01:47:39 CET] <michaelni> i think so [01:47:41 CET] <jamrial> anothing thing in fate but not fatebeta is a diff of the previous and latest compilation log when there are new warnings [01:48:03 CET] <michaelni> tar also supports excludes [01:48:12 CET] <jamrial> the ± link next to the number of warnings [01:49:57 CET] <Timothy_Gu> I can probably pipe grep warning | diff to this [02:50:28 CET] <Guest28> Hello I have a question about the use of the private API method "SecIdentityCreate" in http://ffmpeg.org/doxygen/trunk/tls__securetransport_8c_source.html. Is there a reason to keep that and/or an easy way to remove that usage? It prevents ffmpeg from being used in any mac app store app, fwiw. [03:15:20 CET] <Timothy_Gu> ubitux: is there a good reason to keep the tsan and helgrind FATE station even though it's emitting nothing but useless stuff? [03:28:14 CET] <cone-059> ffmpeg 03Michael Niedermayer 07release/3.0:bd0497b28bc2: avcodec/cfhd: Temporary disable frame threading until related bugs have been fixed [03:47:27 CET] <Timothy_Gu> michaelni: does this make sense or no: https://github.com/FFmpeg/FFmpeg/pull/172/files [03:49:28 CET] <michaelni> maybe, but a testcase would be nice [03:51:25 CET] <cone-059> ffmpeg 03Michael Niedermayer 07master:295de3efc53e: fate/source-check.sh: Use "git show" instead of git --version to test for git [03:56:13 CET] <Compn> hmm ydl made a bad mkv file with audio codec "supo" (using old ffmpeg) ... weird. [03:56:46 CET] <Compn> o thats opus lol [03:56:50 CET] Action: Compn stupid. [04:01:59 CET] <cone-059> ffmpeg 03Michael Niedermayer 07release/3.0:c40983a6f631: fate/source-check.sh: Use "git show" instead of git --version to test for git [04:18:46 CET] <cone-059> ffmpeg 03Michael Niedermayer 07n3.0:HEAD: fate/source-check.sh: Use "git show" instead of git --version to test for git [05:03:29 CET] <Timothy_Gu> valgrind drd + helgrind + tsan = 1/4 of all FATE data [05:10:29 CET] <andrewrk> congrats on 3.0 [05:22:56 CET] <rcombs> michaelni: re: dts fix; I'm not sure it's correct, just that it fixes this case [05:23:28 CET] <rcombs> do library users still need to lock around avcodec_close()? [08:15:59 CET] <someonesomewhere> i am having issues with ffmpeg-2.8.6.. I am trying to use it for android developement, and my app requires that ffmpeg should not exit. However, if i make changes to exit_program function in cmdutils.c to not exit, I see that the stack is getting corrupted (as a result, of which, I get a SIGSEGV later on because the return from that function is n [08:15:59 CET] <someonesomewhere> ot proper).. This seems like a bug to me (I've been able to reproduce it on standalone ffmpeg running on mac osx 10.10 also) [08:16:47 CET] <someonesomewhere> and i know things worked ok with 2.2.15 .. so somewhere things have changed which cause this behavior [08:18:00 CET] <someonesomewhere> to reproduce it, just ensure that you don't exit in exit_program, and then rename main in ffmpeg.c to main2 or something like that, and then call that function twice.. and you'll see what I am talking about [08:44:56 CET] <wm4> it wasn't designed for this, so you'll have to go through a lot to change this behavior (and there's no bug) [08:48:07 CET] <JEEB> for requirements like that using the api sounds like a much better proposition [09:50:32 CET] <nevcairiel> Timothy_Gu: the dca decoder requires the parser to be used to split frames appropriately, therefor the patch is not correct and the user should use the parser isntead [09:52:24 CET] <nevcairiel> (its also against the old decoder) [12:02:05 CET] <someonesomewhere> can someone elaborate on wm4's answer earlier: why can't i use ffmpeg as a reentrant library - I am trying to use it for android developement, and my app requires that ffmpeg should not exit. However, if i make changes to exit_program function in cmdutils.c to not exit, I see that the stack is getting corrupted (as a result, of which, I get a [12:02:05 CET] <someonesomewhere> SIGSEGV later on because the return from that function is not proper).. This seems like a bug to me (I've been able to reproduce it on standalone ffmpeg running on mac osx 10.10 also) [12:03:52 CET] <BtbN> Well, it's a bug you made by modifiying some function [12:04:05 CET] <BtbN> ffmpeg.c is not a librariey either [12:06:20 CET] <nevcairiel> indeed, its not designed to function as a library, and if you modify it to be one, any bugs caused by that are also caused by you [12:07:37 CET] <wm4> <BtbN> ffmpeg.c is not a librariey either [12:07:38 CET] <wm4> this [12:08:26 CET] <wm4> and as far as I'm aware, even the broken POS known as android can start processes? [12:08:43 CET] <wm4> or is that some nonsense security BS (that doesn't actually make anything secure)? [12:09:12 CET] <nevcairiel> probably, just like breaking x86 asm on android for no good reason [12:09:16 CET] <someonesomewhere> i shouldn't have used the word library.. [12:09:25 CET] <someonesomewhere> and lets also take android out of the picture [12:09:30 CET] <someonesomewhere> to reproduce it, just ensure that you don't exit in exit_program, and then rename main in ffmpeg.c to main2 or something like that, and then call that function twice.. and you'll see what I am talking about [12:09:42 CET] <wm4> it's not supposed to be called twice? [12:09:42 CET] <someonesomewhere> on any platform.. on mac os x or linux [12:09:45 CET] <nevcairiel> if you modify ffmpeg.c, and it bugs out afterwards, then you caused the bug [12:09:51 CET] <BtbN> "change something in an entirely unsupported way, and it breaks" what a surprise [12:10:04 CET] <BtbN> of course main is not re-entrant [12:10:11 CET] <BtbN> it's only called exactly once [12:10:27 CET] <someonesomewhere> well.. the only change i've made is that i don't exit from the program in exit_program.. and instead return from it [12:10:36 CET] <BtbN> exactly, so? [12:10:39 CET] <wm4> uh [12:10:40 CET] <wm4> read what we wrote [12:10:42 CET] <nevcairiel> our libraries are thread safe and reentrant, the ffmpeg.c application is not [12:10:54 CET] <nevcairiel> you cannot use it in such a way [12:12:03 CET] <nevcairiel> I know that other people have tried before to make ffmpeg.c or ffplay.c into a re-usable library of sorts, but its just not going to be easy, and definitely not supported by us [12:12:36 CET] <BtbN> It's probably easier to write a library that runs the ffmpeg application as an external process [12:12:44 CET] <someonesomewhere> but doesn't it mean that parts of ffmpeg.c (or cmdutils.c) is overwriting over parts of memory it shouldn't [12:12:50 CET] <BtbN> no [12:12:52 CET] <wm4> it would be great to have such a library, but just modifying ffmpeg.c slightly isn't going to do this [12:13:12 CET] <nevcairiel> if you call main twice, who knows what happens [12:13:16 CET] <BtbN> it just means that some code isn't meant to be run more than once [12:13:18 CET] <nevcairiel> since its not designed to be called twice [12:13:42 CET] <someonesomewhere> i haven't even got to the point where it is being called twice.. [12:14:00 CET] <nevcairiel> its also not meant to continue executing after the point where it usually exits [12:14:17 CET] <someonesomewhere> if you don't exit the program in exit_program, and just return.. the program just returns to some random address.. (even before calling main function again) [12:14:17 CET] <nevcairiel> in any case: you are on your own [12:14:37 CET] <someonesomewhere> it doesn't return from exit_program in a secure manner.. it returns to some random address [12:14:45 CET] <wm4> someonesomewhere: exit never returns [12:14:52 CET] <BtbN> it doesn't return from exit_program at all, you made it do that [12:14:52 CET] <nevcairiel> its not meant to ever return from that function [12:15:01 CET] <nevcairiel> its supposed to quit [12:15:17 CET] <someonesomewhere> and it can never be made to return from that function instead of quitting the program [12:15:18 CET] <someonesomewhere> ? [12:15:29 CET] <wm4> sure you can make it, good luck have fun [12:15:34 CET] <wm4> it wasn't written or intended to do so [12:15:35 CET] <nevcairiel> maybe it can, but it will be complicated [12:15:40 CET] <BtbN> do what you want, but don't complain here about bugs you introduced [12:15:43 CET] <wm4> so you're on your own introducing bugs and fixing them [12:16:33 CET] <nevcairiel> the control flow assumes that it will stop executing entirely when those functions are called [12:16:56 CET] <nevcairiel> to make it gracefully return from that function, you would need to write entirely new cleanup routines [12:18:16 CET] <someonesomewhere> cleanup is one thing (which will involve resetting values of some variables, setting some objects to null, freeing up memory etc).. but the usual expectation is that it should return to the callee ... and it doesn't.. and i don't know which cleanup routine can make its return "normal" [12:18:36 CET] <jkqxz> exit_program() is marked with the noreturn attribute. [12:18:51 CET] <jkqxz> So the compiler is free to assume it doesn't return, hence it just crashes if you ever try to do that. [12:19:18 CET] <jkqxz> If you remove that attribute, it will return to the callee (and then die in some other horrible way instead). [12:22:03 CET] <someonesomewhere> thanks jkqxz - that ifnormation helps - so if i just remove av_noreturn from cmdutils.h, it will at least start returning to the callee ? [12:22:25 CET] <BtbN> and then explode because that code doesn't expect that function to ever return [12:22:38 CET] <jkqxz> If you really want to persist in this likely-fruitless endeavour, you will be much better off jumping out of exit_program() with longjmp() to somewhere in your code. That doesn't solve resetting memory back to the initial state, so it will likely still crash when you call main() a second time. [12:23:19 CET] <jkqxz> s/much better off/very slightly less disastrously off/ [12:24:04 CET] <someonesomewhere> allrite, thanks everyone for the warnings, and inputs !! [12:42:41 CET] <cone-435> ffmpeg 03Hendrik Leppkes 07master:ccb94789e296: hevc: support Main10 decoding through dxva2 [12:42:42 CET] <cone-435> ffmpeg 03Hendrik Leppkes 07master:1ec14612a5bd: ffmpeg_dxva2: support hevc main10 decoding [12:42:43 CET] <cone-435> ffmpeg 03Hendrik Leppkes 07master:a655bc834479: ffmpeg_dxva2: add a profile check for hevc [12:44:45 CET] <wm4> nice [12:46:45 CET] <nevcairiel> now it wont break any distros for another half year or so =p [12:47:07 CET] <nevcairiel> i even bumped and changelog'ed it! [12:48:02 CET] <atomnuker> anyone read the latest coverity dump? [12:48:18 CET] <atomnuker> the dirac decoder has a bunch of avpriv_mirror() calls using negative parameters [12:48:20 CET] <nevcairiel> i had a brief look but not indepth [12:48:38 CET] <atomnuker> but coverity seems to think the function should not be able to take negative arguments [12:48:47 CET] <atomnuker> I think it's a false warning though [12:48:58 CET] <wm4> the code casts a negative int to unsigned [12:49:00 CET] <nevcairiel> those are common enough with static analysis [12:49:02 CET] <wm4> make of that what you want [12:50:31 CET] <nevcairiel> i can never remember, was signed -> unsigned cast strictly specified in the spec? [12:52:43 CET] <wm4> isn't it implementation dependent? [12:52:51 CET] <nevcairiel> probably should be since using -1 to init an unsigned to max is used all over the place [12:53:24 CET] <wm4> that's different [12:53:44 CET] <wm4> (unsigned)-1 is fully defined [12:54:03 CET] <nevcairiel> but (unsigned)-2 isnt? [12:54:30 CET] <wm4> *shrug* [12:54:53 CET] <nevcairiel> speaking of such weird things, did ganesh vanish [12:54:54 CET] <jkqxz> Signed to unsigned is completely defined to do the Right Thing. Too-large unsigned to signed is nasal demons. [12:55:32 CET] <wm4> this is signed to unsigned anyway [12:57:46 CET] <durandal_1707> nevcairiel: is missing ganesh patches [13:14:08 CET] <cone-435> ffmpeg 03Rostislav Pehlivanov 07master:7cdea450c67d: vc2enc: fix use of uninitialized variables in the rate control system [13:22:47 CET] <cone-435> ffmpeg 03KO Myung-Hun 07master:346ec917646c: MAINTAINERS: add myself as an OS/2 maintainer [13:23:42 CET] <atomnuker> whoa, OS/2 [13:23:56 CET] <durandal_1707> what the shit [13:26:17 CET] <durandal_1707> the bounty for vf_pad seems no longer active :( [13:30:08 CET] <J_Darnley> what the heck is this "build failed" message? [13:30:13 CET] <J_Darnley> and why do I care? [13:30:44 CET] <J_Darnley> nice reply kierank [13:30:55 CET] <atomnuker> someone's internal CI system went haywire? [13:34:56 CET] <nevcairiel> probably mailed everyone with a commit in the history [13:35:00 CET] <nevcairiel> nice job, random guy =p [13:35:52 CET] <J_Darnley> Perhaps the software is a little better and only emailed everyone with a commit since the last good build. [13:36:14 CET] <nevcairiel> judging from the list, thats still a lot of people [13:36:46 CET] <J_Darnley> Maybe it should learn what a mailing list is (so it can be rejected for being too large) [13:38:36 CET] <BtbN> That's some jenkins plugin that shouts at people who broke the build. [13:38:41 CET] <wm4> it sent the mail to each committer, not a ML [13:39:01 CET] <durandal_1707> I think getting rid of drawutils for vf_pad is best approach [13:39:12 CET] <wm4> so if you argue it should use (private) MLs, that jenkings plugin is broken by design [13:40:25 CET] <nevcairiel> we used that plugin back at my old job, it can be useful if it builds often enough so the number of p eople is limited [13:40:42 CET] <nevcairiel> but of course one shouldnt make it run over some huge repository that you have no control over =p [13:44:19 CET] <durandal_1707> michaelni: is it ok to increase AV_OPT_TYPE_COLOR to 8? [13:45:21 CET] <durandal_1707> currenttly its only useful for 8bit per component colors [13:45:49 CET] <nevcairiel> sounds like a breaking change [13:46:59 CET] <durandal_1707> yes it is [13:47:29 CET] <michaelni> sounds like it would need AV_OPT_TYPE_COLOR64 [13:59:00 CET] <ubitux> https://news.ycombinator.com/item?id=11103016 [13:59:03 CET] <ubitux> first comment ^ [13:59:16 CET] <ubitux> btw, we didn't even mention the abi/api bump? [14:00:22 CET] <ubitux> about the new aac enc, was it in 2.9? [14:00:35 CET] <ubitux> i mean, that's some quite important changes [14:00:45 CET] <nevcairiel> 2.8, and no [14:01:07 CET] <ubitux> would be nice to spend a few minutes to 1 hour to write a proper release note before releasing :/ [14:01:34 CET] <ubitux> we're releasing a major version like it's nothing [14:02:10 CET] <nevcairiel> because it isnt, its an arbitrary commit from master, its not like we did a feature freeze or anything [14:02:25 CET] <J_Darnley> Did michael actually make the release? Last I saw it was just a branch [14:02:35 CET] <ubitux> http://phoronix.com/scan.php?page=news_item&px=FFmpeg-3.0-Released [14:02:37 CET] <nevcairiel> was tagged as well by now [14:02:43 CET] <ubitux> "Supports VP9 VA-API Acceleration" [14:02:48 CET] <ubitux> as if it was the most important thing [14:03:01 CET] <wm4> <ubitux> "Supports VP9 VA-API Acceleration" <- that's in already? [14:03:04 CET] <ubitux> i mean, api/abi break is a major thing, a good native aac encoder too, ... [14:03:08 CET] <nevcairiel> wm4: yes [14:03:28 CET] <nevcairiel> ubitux: i would find abi/api changes implied by a new major =p [14:03:49 CET] <ubitux> it's probably worth mentioning anyway [14:03:57 CET] <ubitux> it's kind of important [14:04:11 CET] <ubitux> anyway... [14:07:20 CET] <michaelni> anyone wants to write a news entry for the 3.0 release for ffmpeg.org ? [14:19:37 CET] <thardin> is it possible to make it so I only get coverity mail about things I maintain? [14:29:23 CET] <BBB> is there a reason AVFMT_VARIABLE_FPS is not set for movenc.c? [14:31:35 CET] <durandal_1707> it doesn't supports it? [14:32:06 CET] <durandal_1707> is it ok to add uint64 to AVOption union? [14:32:07 CET] <BBB> mov has per-packet timestamps, no? [14:34:02 CET] <rcombs> do library users still need to lock around avcodec_close()? [14:34:37 CET] <rcombs> also avcodec_open2() [14:35:19 CET] <BBB> I thought it did that for you [14:36:06 CET] <nevcairiel> rcombs: yes [14:36:16 CET] <nevcairiel> well or specifically, you need to provide a lock manager [14:36:30 CET] <nevcairiel> i think ffmpeg has a default implementation built-in these days though [14:36:40 CET] <nevcairiel> so just verify its actually active in your environment [14:36:51 CET] <rcombs> that sounds like "no" then [14:36:57 CET] <rcombs> is this documented [14:41:34 CET] <nevcairiel> someone once started to think about making all init thread safe [14:41:37 CET] <nevcairiel> but Daemon404 got lazy [14:41:46 CET] <wm4> rcombs: no and no [14:41:51 CET] <rcombs> that sounds like a good idea [14:42:09 CET] <wm4> there are also various other bits with questionable thread-safety [14:45:41 CET] <nevcairiel> i havent had reports of such issues for a while now, and some people use my stuff in parallel apparently [14:46:11 CET] <atomnuker> michaelni: is it alright for avpriv_mirror() to be called with negative arguments [14:46:25 CET] <atomnuker> I noticed the snow_dwt also uses it with negative args [14:46:57 CET] <michaelni> i saw no problem with negative args for x, width must be >= 0 or something of course [14:47:38 CET] <michaelni> but just because i saw no problem of course doesnt mean that there is "guranteed" to be no problem, i could miss something ... [14:51:00 CET] <atomnuker> well, I'm asking because coverity seems to think x shouldn't accept negatives [14:52:26 CET] <michaelni> 50% of what coverity thinks is wrong [14:52:56 CET] <michaelni> which is actually quite good as that also means 50% is right and leads to bug fixes [14:53:59 CET] <atomnuker> ok [14:55:14 CET] <BBB> kierank: I see single-threaded issues in that file you sent me [14:55:41 CET] <kierank> oh [14:55:48 CET] <kierank> I could only get it to crash in multithread mode [14:56:13 CET] <BBB> ==13378== Invalid write of size 2 [14:57:07 CET] <BBB> Im gonna guess this is in the chroma plane when it switches between gbrp12 and yuv422p10 [14:57:23 CET] <BBB> ==13378== Address 0x10eab318e is 353,326 bytes inside a block of size 353,327 alloc'd [14:57:44 CET] <BBB> linesize[1] = 736, height=480, so alloc size is correct [14:58:17 CET] <kierank> oh I guess I need to store the old pixel format as well [14:58:27 CET] <BBB> might relate to the crash with MT also [14:58:47 CET] <nevcairiel> isnt this an intra format? [14:58:54 CET] <BBB> nevcairiel: buffer realloc [14:59:05 CET] <nevcairiel> shares buffers over threads? [14:59:14 CET] <BBB> no, but buffers need realloc on pixfmt/size chage [14:59:25 CET] <BBB> so you need to know the pixfmt/size of the previous frame _in this thread_ [14:59:32 CET] <nevcairiel> sure, but threading shouldnt be hard on intra formats [14:59:32 CET] <atomnuker> michaelni: I'm marking CID1352548 CID1352547 CID1352546 CID1352545 CID1352544 CID1352543 as ignore in coverity then [14:59:34 CET] <BBB> (as opposed to avctx->, which is of the previous thread) [14:59:40 CET] <nevcairiel> ah y eah [14:59:48 CET] <BBB> so you need to store all these variables locally [14:59:48 CET] <nevcairiel> you need to know what format your buffers are allocated for [14:59:49 CET] <michaelni> atomnuker, sure [14:59:56 CET] <BBB> its not hard, just slightly illogical [15:00:10 CET] <BBB> its easy to do it wrong, lets say it like that [15:00:17 CET] <BBB> (I made the same mistake in ffvp9 also, FWIW) [15:00:44 CET] <nevcairiel> vp9 is inter, so thats even worse =p [15:02:05 CET] <BBB> & I guess thats one way to look at it :-p [15:11:53 CET] <Daemon404> [13:41] <@nevcairiel> but Daemon404 got lazy [15:11:57 CET] <Daemon404> i have a WIP branch [15:12:03 CET] <Daemon404> its super tedious to mark all codecs properly [15:12:05 CET] <Daemon404> and boring. [15:12:09 CET] <Daemon404> i dunno how elenril does it [15:12:43 CET] <BBB> he probably sits down and just does it [15:12:44 CET] <Daemon404> https://github.com/dwbuiten/FFmpeg/commit/3d2fc03955348f49f2a6b67a66cc038d1… [15:12:49 CET] <BBB> how else do you think people get boring stuff done [15:13:52 CET] <nevcairiel> divide and conquer, just set yourself incremental goals and reach them =p [15:14:48 CET] <Daemon404> nevcairiel, would be easier if i could push them [15:14:49 CET] <michaelni> Timothy_Gu, theres no v3.0 on http://fatebeta.ffmpeg.org/ [15:14:54 CET] <Daemon404> instead of rebasing for X weeks [15:14:57 CET] <Daemon404> until theyre all done [15:15:14 CET] <nevcairiel> there is no reason you couldnt push the flag additions [15:15:37 CET] <Daemon404> at libav there is [15:15:42 CET] <BBB> procrastrination& [15:15:47 CET] <nevcairiel> i th ought we stopped caring about them [15:16:35 CET] <nevcairiel> in any case this kind of change shouldnt conflict often so its probably not that terrible [15:22:01 CET] <wm4> Daemon404: what speaks against pushing that commit [15:22:12 CET] <wm4> just add the word "some" to the message [15:27:47 CET] <Daemon404> wm4, i feared the diego [15:27:51 CET] <Daemon404> ill submit it today [15:28:08 CET] <nevcairiel> was so nice and quiet while he was gone for months [15:28:16 CET] <BBB> iive: I guess my question for that patch is: what would you use it for that you cannot do today" [15:29:21 CET] <BBB> what does diego have to do with patches? [15:29:27 CET] <Daemon404> ... lmao [15:29:28 CET] <Daemon404> [libutvideo] Is FFMPeg the new home for libutvideo? (#10) [15:29:29 CET] <BBB> hell tell you to add/remove/change spaces [15:29:36 CET] <Daemon404> BBB, "while youre at it..." [15:29:45 CET] <BBB> tell him to send a patch [15:29:49 CET] <BBB> problem_solved [15:31:15 CET] <iive> BBB: print hwaccel capability in the info screen. [15:31:36 CET] <BBB> which info screen? [15:32:55 CET] <nevcairiel> the way I see those flags, if they are not required for behavior, they are not required. info-only flags seem rather pointless [15:33:41 CET] <Daemon404> lmao kierank [15:33:42 CET] <iive> cmdutils.c::print_codec() [15:33:47 CET] <Daemon404> i thought you were a nigerian prince at first [15:33:53 CET] <nevcairiel> haha [15:34:02 CET] <kierank> he played on with the joke as well [15:34:06 CET] <kierank> in his reply [15:34:18 CET] <nevcairiel> should have send him in invoice [15:34:19 CET] <Daemon404> i got no reply [15:34:30 CET] <kierank> yeah he only replied to me [15:34:30 CET] <nevcairiel> s/ in / an / [15:34:46 CET] <kierank> PS. I am sorry to say, but for your request of payment to be accepted you must have an agreement signed with Cyfrowy Polsat. That is not something impossible, but you must be ready to withstand very long and carefully crafted recruitment process. If I might be of any assistance in that, just let me know. [15:35:09 CET] <Daemon404> ... i dont think that is a joke [15:35:12 CET] <Daemon404> sadly. [15:36:52 CET] <wm4> what am I missing out? [15:37:13 CET] <Daemon404> you got the email too. [15:37:23 CET] <Daemon404> Build failed in Jenkins: live-build-ffmpeg #23 [15:37:24 CET] <Daemon404> Build failed in Jenkins: live-build-ffmpeg #31 [15:45:19 CET] <BBB> I [15:45:23 CET] <BBB> Im not getting the follow-ups [15:45:31 CET] <BBB> so clearly Ive been erased from a long CC list, thankfully [15:45:35 CET] <BBB> or my spam filter is working [15:46:53 CET] <kierank> ubitux: something is up with https on ffmpeg.org [15:47:16 CET] <nevcairiel> i would say something is down instead [15:47:18 CET] <kierank> Resolving ffmpeg.org (ffmpeg.org) 178.63.43.86 [15:47:18 CET] <kierank> Connecting to ffmpeg.org (ffmpeg.org)|178.63.43.86|:443... [15:47:56 CET] <ubitux> i'm not really doing any admin on this [15:48:00 CET] <ubitux> just paying for the server :p [15:48:39 CET] <J_Darnley> BBB: think the OP sensibly didn't hit reply all [15:49:43 CET] Action: kierank did [15:49:45 CET] <kierank> as a troll [15:50:06 CET] <J_Darnley> Yes, I didn't object to that. [15:58:52 CET] <BBB> it was a proper troll [15:59:05 CET] <BBB> so kierank, do you have a patch for the format change issue? [15:59:05 CET] <Timothy_Gu> nevcairiel: ok [15:59:17 CET] <kierank> BBB: will have to look at that at home [15:59:24 CET] <BBB> hm... [15:59:33 CET] <BBB> I can just try backing up format, I guess? [15:59:50 CET] <kierank> yes but bear in mind I set format at the beginning [15:59:56 CET] <kierank> because there were some samples without a format tag [16:00:02 CET] <kierank> but appeared to be yuv422p10 [16:04:44 CET] <BBB> ok [16:05:23 CET] <Timothy_Gu> michaelni: now there is [16:06:52 CET] <michaelni> thx [16:07:40 CET] <BBB> any valid cfhd samples? [16:07:43 CET] <BBB> maybe a fate test? [16:07:46 CET] <BBB> to test I didnt break stuff [16:08:06 CET] <BBB> I get no valgrind issues after I fix the format issue, w/ as well as w/o threading [16:08:20 CET] <Timothy_Gu> michaelni: the fate-recv.sh script is still the old one, so stuff like autoadding branch isn't working [16:09:20 CET] <BBB> iive: now, coming back to that info flag& its not that Im against it, Im just not sure what the point is [16:10:05 CET] <BBB> iive: since the flag is just an ifo bit, were doomed to forget to update it everywhere and always, so if its app specific, it could just as well live in the app and lag in uptodateness also [16:10:56 CET] <BBB> iive: e.g. we dont have flags for this codec could output rgb and/or yuv, even though thats a valid thing to wonder in the app& [16:11:31 CET] <BBB> iive: we also dont signal whether codecs are HD optimized or not, or whether the implementation of the audio decoder is float or int [16:11:38 CET] <BBB> all very valid things to signal as an info bit [16:12:03 CET] <iive> then remove all cap flags [16:12:31 CET] <BBB> maybe we should, yes [16:12:44 CET] <BBB> I can only wonder about the amount of flames/trolls that will invoke [16:14:26 CET] <iive> tbh, I didn't expect the amount of controversy this small issue has caused. [16:15:21 CET] <nevcairiel> most of the flags actually are required for some kind of behavior, ie. threading causes the generic code to behave differently [16:17:43 CET] <BBB> iive: I can help you implement a small piece of codec that decides for each AVCodec whether it has accompanying ACHWAccel implementations [16:17:48 CET] <BBB> iive: would that be useful? [16:17:51 CET] <BBB> (to replace this flag) [16:18:53 CET] <iive> codec/code ... [16:19:15 CET] <BBB> hehe :) [16:19:16 CET] <BBB> oops [16:19:21 CET] <iive> ;) [16:20:23 CET] <iive> BBB: how would that code work? [16:21:29 CET] <BBB> similar to find_hwaccel() in libavcodec/utils.c [16:22:17 CET] <nevcairiel> that would probably be more useful information as well, knowing that a codec could do hwaccel on some system doesnt really help you, while checking for an actual hwaccel tells you if it can do hwaccel right here and now [16:22:45 CET] <BBB> and then for pix_fmt, you can add any pix_fmt that you like (AV_PIX_FMT_VAAPI, DXVA2_VLD, D3D11VA_VLD, etc. [16:24:15 CET] <iive> this actually does make sense [16:24:59 CET] <iive> just have one thing in mind... the code would be bigger than 1 bit :) [16:33:22 CET] <BBB> iive: yeah, I know, its not 1 bit& but & its info screen code, not performance-sensitive in the innermost loop of block decoding [16:33:23 CET] <BBB> so thats ok [16:33:34 CET] <BBB> kierank: do you have a fate test or test sample or so? [16:33:38 CET] <BBB> kierank: to confirm I didnt break it [16:33:40 CET] <kierank> yes but at home [16:33:45 CET] <kierank> If you post a patch I will test tonight [16:35:12 CET] <jamrial> atomnuker: backport that vc2enc commit to 3.0, preferably using "git cherrypick -x" [16:35:21 CET] <BBB> kierank: posted to ML [16:35:29 CET] <kierank> thanks [16:35:33 CET] <BBB> kierank: its completely untested with real samples, so be careful :-p [16:37:04 CET] <Timothy_Gu> BBB: your printfs are still in there :) [16:37:27 CET] <BBB> oops [16:37:29 CET] <BBB> anyway [16:37:42 CET] <cone-435> ffmpeg 03Rostislav Pehlivanov 07release/3.0:0aa2fbddb190: vc2enc: fix use of uninitialized variables in the rate control system [16:37:51 CET] <atomnuker> jamrial: done [16:38:08 CET] <jamrial> thanks [16:39:30 CET] <BBB> Timothy_Gu: fixed [16:40:39 CET] <Timothy_Gu> thx [16:52:41 CET] <ubitux> http://b.pkh.me/testsrc2-nv12-bgra-aarch64.jpg ready for upstream! [16:53:07 CET] <ubitux> Timothy_Gu: idk about drd/helgrind/tsan; i think there are issues to fix [16:56:48 CET] <BBB> ubitux: what is that [16:57:07 CET] <ubitux> testsrc2 :( [16:57:31 CET] <ubitux> after a nv12 bgra in aarch64 :p [16:57:42 CET] <jamrial> aarch64 specific asm? [16:57:45 CET] <ubitux> yeah [16:58:00 CET] <ubitux> i'm porting arm/yuv2rgb_neon.S to aarch64 [16:58:32 CET] <jamrial> awesome, we're lacking in the aarch64 asm coders department :p [16:59:01 CET] <ubitux> i just need a debugger now :( [17:01:22 CET] <rcombs> isn't it extremely similar to regular arm [17:01:57 CET] <ubitux> no, actually really different [17:02:16 CET] <rcombs> lacks some conditional execution, register allocations are different& [17:02:29 CET] <rcombs> no thumb? [17:03:02 CET] <ubitux> the most annoying part is that you can't play anymore with high/low part of a simd reg [17:03:12 CET] <ubitux> at least as easily as regular arm [17:03:19 CET] <rcombs> oh :/ [17:03:35 CET] <Timothy_Gu> ubitux: unless the avg. 700 failed tests are all issues to fix I don't really see how you could find the importatn parts [17:03:53 CET] <ubitux> Timothy_Gu: it's a remainder to fix the noise :) [17:04:02 CET] <ubitux> reminder* [17:04:04 CET] <Timothy_Gu> ah :) [17:04:23 CET] <Timothy_Gu> how would you go about doing that though? [17:04:55 CET] <ubitux> check every issue one by one [17:05:10 CET] <BBB> aarch64 [17:05:13 CET] <BBB> what is that again? [17:05:15 CET] <BBB> is that arm64? [17:05:19 CET] <rcombs> yup [17:05:26 CET] <BBB> aha, yes, thats important [17:05:37 CET] <BBB> although Im not sure why anyone would care about testsrc2 on arm [17:05:41 CET] <BBB> but that may just be me [17:05:46 CET] <ubitux> it's just for testing :p [17:05:51 CET] <BBB> ok [17:05:59 CET] <ubitux> yuv/nvx rgb flavor are kinda useful [17:06:04 CET] <BBB> agreed [17:06:17 CET] <ubitux> but damn i hate the arm doc so much [17:06:19 CET] <BBB> I thought it was testsrc2-specific, but I misread, youre essentially doing arm64@swscale [17:06:26 CET] <BBB> so thats super-cool [17:06:28 CET] <ubitux> these guys should read the intel doc one day [17:06:30 CET] <jamrial> where is the tsan slot? i can't find it [17:06:40 CET] <BBB> can you make ffvp9 run on arm/arm64? [17:07:39 CET] <Timothy_Gu> jamrial: it's broken [17:07:42 CET] <Timothy_Gu> http://fatebeta.ffmpeg.org/log/x86_64-archlinux-gcc-tsan/20160215060601/con… [17:08:15 CET] <ubitux> yeah there is a bug on this one [17:08:34 CET] <ubitux> i don't feel like looking much more into it [17:09:13 CET] <ubitux> BBB: maybe one day, i think there are more important thing to actually port first [17:09:25 CET] <ubitux> i'm also waiting for my arm64 board to come... [17:09:38 CET] <ubitux> qemu-aarch64 is fine for testing, but not so much for benchmark [17:10:23 CET] <Timothy_Gu> 15812 www-data 20 0 3649m 3.5g 2184 S 1 45.4 0:14.39 report.cgi [17:10:37 CET] <Timothy_Gu> mem=45.1% [17:11:04 CET] <Timothy_Gu> yeah somebody's looking at the drd/helgrind report [17:11:46 CET] <Daemon404> ... cgi? [17:11:51 CET] <Daemon404> is this old fate [17:12:06 CET] <Timothy_Gu> yes [17:12:52 CET] <Daemon404> yikes [17:13:26 CET] <Timothy_Gu> damn i can't even kill that process [17:32:35 CET] <BBB> ubitux: is it hard to learn? maybe i should aarch64... [17:32:38 CET] <BBB> learn* [17:33:07 CET] <ubitux> well the official doc is shit, so you'll probably have to wander on random slideshow and blogs [17:33:35 CET] <BBB> hm... [17:34:01 CET] <ubitux> the most annoying part to have hw and toolchain anyway :p [17:34:32 CET] <ubitux> the pine64 and a 64b odroid are going out around march iirc [17:35:03 CET] <mateo`> BBB: i'm wondering, are there optimisations to be done in ffvp9 on armv7 ? [17:35:07 CET] <ubitux> if you can't wait, there is the hikey and the poop devices from apple [17:35:18 CET] <ubitux> mateo`: all of them [17:35:36 CET] <ubitux> mc, lpf, dct, ... [17:35:39 CET] <andrey_utkin> Hi, I'm interested in subtleties with H.264 Annex B vs AVCC. Willing to pay for good consulting with explanations why things work. The question is related to joining video clips of different origin. Joining AnnexB (mpegts) files work and with AVCC (MP4 container) it doesn't which I assume is legit. But if you convert this joined file to MP4, it still works. I wonder why. [17:35:47 CET] <mateo`> I should probably give it a try then [18:00:22 CET] <BBB> mateo`: you mean the scalar non-neon type? [18:00:26 CET] <BBB> mateo`: or you mean neon? [18:00:31 CET] <BBB> I guess scalar is armv6 [18:00:43 CET] <BBB> mateo`: for neon, yes, tons. like, its non-existant right now [18:01:40 CET] <mateo`> i mean neon [18:02:19 CET] <BBB> mateo`: basically all simd needs implementing for neon (mc, itxfm/loopfilter, intra pred; in that order) [18:05:47 CET] <jamrial> i found it pretty cool how imgtec wrote complete simd coverage for ffvp9 8bit on mips [18:11:34 CET] <Timothy_Gu> michaelni: I started backing up fate (just the outcome, without the full report) [18:12:07 CET] <michaelni> Timothy_Gu, ok, great, thx [19:08:23 CET] <Daemon404> mediacodec is quite an insane amount of code... [19:09:03 CET] <nevcairiel> its like 3000 LoC without the JNI utility code, that is insane indeed [19:09:13 CET] <Daemon404> yes [19:09:17 CET] <Daemon404> i wasnt including the jni wrapper [19:09:52 CET] <nevcairiel> fucking android people, cant they just use java to access their media [19:09:59 CET] <nevcairiel> why does it need to go through avcodec anyway [19:10:17 CET] <Daemon404> im sure there's A Reason [19:10:52 CET] <Daemon404> same could be said for iOS [19:10:57 CET] <Daemon404> of really any hwaccel [19:11:02 CET] <Daemon404> or* [19:11:24 CET] <nevcairiel> well some APIs are at least simple and straight forward to use [19:11:38 CET] <nevcairiel> but MediaCodec becomes 100x more complicated when using it through JNI [19:11:42 CET] <nevcairiel> or at least I hope so [19:11:52 CET] <nevcairiel> a native java version wouldnt be this terrible, would it [19:11:58 CET] <Daemon404> none of the hwaccel stuff i see in avcodec is "simple" [19:12:34 CET] <nevcairiel> the "classic" hwaccels like dxva, vaapi and vdpau require a decoder to hook into, so using them without at least parts of an actual decoder would be insanely hard [19:12:42 CET] <nevcairiel> because they are slice decoders [19:12:46 CET] <nevcairiel> not bitstream parsers [19:14:15 CET] <mateo`> nevcairiel: we use lavc/lavf as a cross platform backend for audio/video [19:14:40 CET] <nevcairiel> maybe you shouldnt =p [19:18:54 CET] <mateo`> i'm dealing with native code, i could have do the same "shit" outside ffmpeg but I decided otherwise so other can benefit this work. [19:20:49 CET] <cone-435> ffmpeg 03Timothy Gu 07master:5d823709301b: RELEASE: Update to 3.0.git [19:22:09 CET] <Daemon404> java calling c calling java :3 [19:22:17 CET] <Daemon404> i think i forgot an extra 'c' there [19:23:56 CET] <mateo`> Daemon404: it's even better than that "java calling avcodec calling java calling libstagefright calling omx calling avcodec" [19:24:42 CET] <mateo`> in case the implementation behind the codec is a software one. [19:37:06 CET] <Daemon404> mateo`, sounds like quite a lot of overhead for a mobile platform [19:40:44 CET] <rcombs> don't forget all the awkward IPC in there [19:46:46 CET] <nevcairiel> speaking of awkward public API, those quicksync people also disappeared, didnt they [19:47:03 CET] <nevcairiel> someone had the theory that they had a deadline to get it all done and would otherwise lose the contract from Intel [19:49:48 CET] <durandal_1707> contract for what? [19:50:04 CET] <rcombs> which quicksync people? [19:56:14 CET] <nevcairiel> those trying to push a QS vpp filter and other various weird stuff [19:56:26 CET] <nevcairiel> also those responsible for thorougly breaking our QS decoder [20:16:42 CET] <durandal_1707> anyone want to comment on fieldhint filter? [20:45:22 CET] <Timothy_Gu> durandal_1707: how do you use it? [20:48:15 CET] <durandal_1707> write file with line numbers from which frame pick which field [20:48:59 CET] <durandal_1707> inverse telecine pattern [20:49:49 CET] <durandal_1707> similar to avs and vs plugins [20:50:13 CET] <durandal_1707> very old one though [20:50:44 CET] <durandal_1707> to be used where fieldmatch fails [21:18:44 CET] <BBB> I think its totally fine to commit weird filters that nobody else udnerstands [21:18:45 CET] <BBB> I mean [21:18:50 CET] <BBB> I dont understan any of that [21:53:57 CET] <jamrial> seeing how ubuntu has feature freeze three days from now i wondering how likely is 3.0 to get in [21:54:03 CET] <jamrial> it's not even in debian yet [21:54:49 CET] <nevcairiel> and probably wont be because vlcs latest release is nearly 2 years old and is apparently not quite compatible anymore [21:56:32 CET] <jamrial> can't they use a git snapshot? [21:57:02 CET] <jamrial> they do it with x264, and i'm fairly sure they used to do that back in the ffmpeg 0.5 era [21:57:11 CET] <nevcairiel> they could, but probably wont like that very much [21:57:32 CET] <nevcairiel> especially since current vlc doesnt like ffmpeg 3.0 either, sicne they didnt remove the silly configure check [21:58:11 CET] <JEEB> vOv [21:58:15 CET] <wm4> lol [21:58:33 CET] <nevcairiel> also our debian maintainer hasnt been seen for weeks [21:59:31 CET] <nevcairiel> (well. 1.5 qulifies as multiple, right?) [21:59:35 CET] <nevcairiel> qualifies* [22:00:09 CET] <BBB> why does vlc not work with git head? [22:00:21 CET] <jamrial> Andreas? I see an email from him from a week ago [22:00:25 CET] <wm4> hwaccel threading [22:00:34 CET] <nevcairiel> because they added a configure check to blacklist it in response to us disabling hwaccels with threading [22:00:44 CET] <BBB> but we fixed that [22:00:48 CET] <BBB> why is it still disabled? [22:01:05 CET] <nevcairiel> ask them [22:01:07 CET] <jamrial> because we haven't poked j-b about it maybe [22:02:06 CET] <BBB> j-b: whats going on here? you could just poke me if there was a critical issue that needed to be fixed right away... [22:02:12 CET] <BBB> so much goodwill wasted :( [22:02:44 CET] <nevcairiel> BBB: the main problem of course is that noone from vlc ever talked to us directly about this topic [22:02:54 CET] <nevcairiel> they just blacklisted ffmpeg without a comment [22:02:56 CET] <BBB> indeed [22:03:00 CET] <wm4> so much fun [22:03:08 CET] <wm4> and we gave in too [22:13:24 CET] <kierank> BBB: patch breaks one (huge) sample [22:13:32 CET] <BBB> :( [22:13:36 CET] <BBB> can you fix it? :-p [22:13:43 CET] <kierank> looking now [22:21:14 CET] <kierank> BBB: s->coded_format = -1 for some reason? [22:21:17 CET] <kierank> how is that possible [22:21:23 CET] <BBB> AV_PIX_FMT_NONe = -1 [22:21:38 CET] <BBB> why? no idea :-p [22:30:10 CET] <kierank> I don't understand [22:30:13 CET] <kierank> how is it possible [22:30:50 CET] <BBB> depends on where/when [22:33:55 CET] <kierank> if (tag == 4 && data == 0x1a4a && s->coded_width && s->coded_height && [22:33:55 CET] <kierank> s->coded_format != AV_PIX_FMT_NONE) { [22:33:57 CET] <kierank> that check [22:34:03 CET] <kierank> but s->coded_format is set to yuv422p10 [22:34:09 CET] <kierank> and there's no way it can get changed [22:35:32 CET] <kierank> BBB: http://storage.sesse.net/trailer.avi [22:35:35 CET] <kierank> that's the sample [22:35:58 CET] <BBB> so where did it get changed? [22:36:04 CET] <BBB> gdb watchpoint or so? [22:36:16 CET] <Timothy_Gu> michaelni: backup completed. total 5.3 GiB [22:36:33 CET] <kierank> oh bleh [22:36:36 CET] <kierank> init_frame_defaults straight after.. [22:36:37 CET] <kierank> lol [22:41:43 CET] <kierank> BBB: sent updated patch [22:41:53 CET] <BBB> ty [22:42:09 CET] <BBB> does it still fix the crash with the sample in that trac report? [22:45:51 CET] <kierank> nope [22:45:54 CET] <kierank> double free [22:47:21 CET] <BBB> hm& well thats not good [22:47:49 CET] <BBB> need me to look further? or can you fix that yourself? [22:47:54 CET] <BBB> and is that only with mt or with thr=1 also? [22:48:51 CET] <kierank> mt only [22:49:46 CET] <kierank> I guess we need a separate variable for coded pixel format and allocated pixel format [22:49:55 CET] <BBB> I did that, right? [22:49:59 CET] <BBB> I had a_format and coded_format [22:50:15 CET] <kierank> oh you check that [22:50:16 CET] <kierank> ignore me [22:50:23 CET] <kierank> dunno then [22:50:31 CET] <kierank> let me do some more printfs [22:55:51 CET] <BBB> which variable is double free'ed? [22:57:18 CET] <kierank> it all looks fine to me [22:57:24 CET] <kierank> but valgrind and gdb disagree [22:58:54 CET] <kierank> crash still happens because the pixel format changes [22:58:56 CET] <BBB> valgrind should tell you which variable is double free'ed [22:59:15 CET] <kierank> --6908-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting [22:59:15 CET] <kierank> --6908-- si_code=80; Faulting address: 0x0; sp: 0x807136d60 [22:59:20 CET] <kierank> sometimes segfault sometimes double free [23:00:15 CET] <BBB> hm ... [23:00:27 CET] <BBB> let me test your patch [23:00:52 CET] <kierank> I changed one line [23:00:57 CET] <kierank> basically making yuv422p10 the default [23:00:59 CET] <kierank> instead of none [23:01:06 CET] <BBB> yes [23:01:43 CET] <kierank> going to sleep now [23:01:45 CET] <kierank> bye [23:11:49 CET] <BBB> gnite [23:12:37 CET] <BBB> how many threads? [23:12:45 CET] <BBB> I dont see any issues with your patch with 1 or 2 threads [23:14:13 CET] <nevcairiel> moar threads! [23:14:32 CET] <BBB> I dont get any output for that cfhd sample either btw [23:14:35 CET] <BBB> its just a gray screen [23:58:16 CET] <kierank> It's not a grey screen [23:58:22 CET] <kierank> There's video [23:58:37 CET] <kierank> I have 8 threads by default iirc [00:00:00 CET] --- Tue Feb 16 2016

1 0

ffmpeg.log.20160215
by burek 16 Feb '16

16 Feb '16

[03:24:00 CET] <parrot> hello. where can i find the exact command that links x86 asm utilities with the regular C file in libavutil ? thanks [03:27:19 CET] <J_Darnley> Huh? [03:27:43 CET] <J_Darnley> Are you looking for the compile commands? [03:28:14 CET] <J_Darnley> You can use V=1 when running make to have it print the commands it runs. [03:34:08 CET] <parrot> J_Darnley: thanks. Can I just compile libavutil alone? make libavutil V=1 returns "nothing to be done for 'libavutil'" [03:34:31 CET] <parrot> I then cd to libavutil and type make V=1 but it says no targets [03:34:31 CET] <J_Darnley> Try asking for the actual file [03:34:43 CET] <J_Darnley> libavutil/libavutil.a [03:46:58 CET] <parrot> ok..now I see yasm commands so I think I might have gotten what I want. So I take yasm generates an object file from the asm file? [03:47:17 CET] <J_Darnley> Yes. [03:48:13 CET] <J_Darnley> It is the assembler we use for external x86 assembly [03:49:12 CET] <J_Darnley> I use it often so if you have more questions feel free to ask. [03:51:56 CET] <lawrence_> who has what mic pid issue on stabilizer no dit no monitor focus anger Vacation. How can you do this to me? I burned my car to get us out here. I maxed out my credit cards to get us this far. What? Am I supposed to go back by myself? for f in $(find . -type f -follow -name *.MXF); do ffmpeg -i $f -vcodec libx264 -pix_fmt yuv420p -acodec copy $f.mov ; done I am trying to burn subtitles and cant seem to get it [03:52:23 CET] <lawrence_> I am trying to burn subtitles and cant seem to get it to work. The finished output has no subtitles on it. It basically just rewrapped. I have compiled the necessary modules and the .ass file works in VLC. I am hopping it is operator error. Does anyone know what I am doing wrong? [03:53:25 CET] <J_Darnley> From what you posted it looks like you are doing nothing with subtitles. [03:53:36 CET] <lawrence_> http://pastie.org/10722086 [03:54:49 CET] <lawrence_> ./ffmpeg_g -i test.mov -vf "ass=subtitle.ass" outerlimits.avi [03:55:45 CET] <J_Darnley> Are you sure that the 1 line it has actually comes before the end of the video? [03:55:58 CET] <lawrence_> it works in vlc [03:56:58 CET] Action: J_Darnley notes that site as being poor for cutting off lines. [03:57:35 CET] <furq> http://pastie.org/pastes/10722086/text?key=4oixbcim6jdmuglzz7hyzw [03:57:50 CET] <furq> why does it need a key to view raw? who knows [03:57:52 CET] <parrot> J_Darnley: Thanks so much :-) I wonder if ffmpeg does have ssim asm code [03:58:26 CET] <J_Darnley> try looking in libavfilter. I think there's an ssim filter there. [03:59:47 CET] <J_Darnley> furq: I just went to delete the stupid "overflow" style option they have. [04:00:34 CET] <J_Darnley> lawrence_: try increasing the loglevel and see if it prints anything more useful. [04:01:33 CET] <furq> it's fine i'm sure nobody will ever need word wrap [04:01:55 CET] <J_Darnley> better a horizontal scroll than cutting off. [04:02:11 CET] <furq> it does have horizontal scroll but only at the bottom of the div [04:02:47 CET] <furq> actually it's ruby so they're probably using some made up "semantic" html5 element like <paste> [04:03:30 CET] <J_Darnley> Ah. good that I would needto scroll to the bottom before I can scroll across. [04:04:08 CET] <furq> but look at the rounded corners. that's good UX [04:04:25 CET] <J_Darnley> That so 2006! [04:04:53 CET] <furq> check out that pattern on the top bar which is so subtle that you actually can't see it [04:05:18 CET] <furq> but it must be there or else why would it be an 84KB image [04:06:56 CET] <J_Darnley> We plebs probably need to calibrate out displays [04:07:00 CET] <lawrence_> what params do I need to increase the log level to what you need to see? [04:07:10 CET] <furq> -v debug [04:07:16 CET] <lawrence_> OK thanks! [04:07:16 CET] <J_Darnley> try -loglevel verbose first [04:07:23 CET] <furq> yeah verbose is probably better [04:07:29 CET] <furq> i forgot what was between info and debug [04:07:53 CET] <J_Darnley> Some things are a little too verbose on debug. (I'm looking at you matroska muxer.) [04:08:05 CET] <lawrence_> thanks I will do that when I get into work tomorrow [04:08:26 CET] <J_Darnley> If you still have problems you should post the ass file too [04:10:15 CET] <J_Darnley> Ha. 100K page, 85K is that image. [04:10:59 CET] <furq> if only it were possible to create a smaller noise.png [04:11:01 CET] <furq> but it isn't. [04:11:24 CET] <furq> the 3KB one i use on every website is a pale imitation of pastie's artistry [06:12:21 CET] <Shirudo> Hey, is anyone available to help me with an audio conversion problem I'm having? [06:16:41 CET] <TD-Linux> just ask your question [06:19:31 CET] <Shirudo> I'm trying to convert some .dsf files to .flac, an example of the command I was using is ffmpeg -i 01\ -\ Camel\ -\ Aristillus.dsf "01 - Aristillus.flac" . It converts successfully, but the resultant flac files are unplayable. I'm thinking that I may have to change the sample rate possibly, since the .dsf sample rate is 352800 Hz, far above any rate I've seen a flac file have. [06:21:54 CET] <Shirudo> The complete output of that command was ffmpeg version 2.6.8 Copyright (c) 2000-2016 the FFmpeg developers [06:21:56 CET] <Shirudo> built with gcc 5.3.1 (GCC) 20151207 (Red Hat 5.3.1-2) [06:21:57 CET] <Shirudo> configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --optflags='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' --enable-bzlib --disable-crystalhd --enable-frei0r [06:21:59 CET] <Shirudo> --enable-gnutls --enable-ladspa --enable-libass --enable-libcdio --enable-libdc1394 --disable-indev=jack --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-openal --enable-libopencv --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libv4l2 --enable-libvpx --enable-libx26 [06:22:00 CET] <Shirudo> 4 --enable-libx265 --enable-libxvid --enable-x11grab --enable-avfilter --enable-avresample --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-runtime-cpudetect [06:22:02 CET] <Shirudo> libavutil 54. 20.100 / 54. 20.100 [06:22:03 CET] <Shirudo> libavcodec 56. 26.100 / 56. 26.100 [06:22:05 CET] <Shirudo> libavformat 56. 25.101 / 56. 25.101 [06:22:06 CET] <Shirudo> libavdevice 56. 4.100 / 56. 4.100 [06:22:08 CET] <Shirudo> libavfilter 5. 11.102 / 5. 11.102 [06:22:09 CET] <Shirudo> libavresample 2. 1. 0 / 2. 1. 0 [06:22:11 CET] <Shirudo> libswscale 3. 1.101 / 3. 1.101 [06:22:12 CET] <Shirudo> libswresample 1. 1.100 / 1. 1.100 [06:22:14 CET] <Shirudo> libpostproc 53. 3.100 / 53. 3.100 [06:22:15 CET] <Shirudo> [dsf @ 0x1ce75c0] Estimating duration from bitrate, this may be inaccurate [06:22:17 CET] <Shirudo> Input #0, dsf, from '01 - Camel - Aristillus.dsf': [06:22:18 CET] <Shirudo> Metadata: [06:22:20 CET] <Shirudo> title : Aristillus [06:22:21 CET] <Shirudo> artist : Camel [06:22:23 CET] <Shirudo> album : Moonmadness [06:22:24 CET] <Shirudo> genre : Other [06:22:26 CET] <Shirudo> track : 1 [06:22:27 CET] <Shirudo> date : 2014-13-02 [06:22:29 CET] <Shirudo> Duration: 00:01:58.48, bitrate: 5644 kb/s [06:22:30 CET] <Shirudo> Stream #0:0: Audio: dsd_lsbf_planar, 352800 Hz, stereo, fltp, 5644 kb/s [06:22:32 CET] <Shirudo> [flac @ 0x1d5ab60] encoding as 24 bits-per-sample [06:22:33 CET] <Shirudo> Output #0, flac, to '01 - Aristillus.flac': [06:22:35 CET] <Shirudo> Metadata: [06:22:36 CET] <Shirudo> title : Aristillus [06:22:38 CET] <Shirudo> artist : Camel [06:22:39 CET] <Shirudo> album : Moonmadness [06:22:41 CET] <Shirudo> genre : Other [06:22:42 CET] <Shirudo> TRACKNUMBER : 1 [06:22:44 CET] <Shirudo> date : 2014-13-02 [06:22:45 CET] <Shirudo> encoder : Lavf56.25.101 [06:22:47 CET] <Shirudo> Stream #0:0: Audio: flac, 352800 Hz, stereo, s32 (24 bit), 128 kb/s [06:22:48 CET] <Shirudo> Metadata: [06:22:50 CET] <Shirudo> encoder : Lavc56.26.100 flac [06:22:51 CET] <Shirudo> Stream mapping: [06:22:53 CET] <Shirudo> Stream #0:0 -> #0:0 (dsd_lsbf_planar (native) -> flac (native)) [06:22:54 CET] <Shirudo> Press [q] to stop, [?] for help [06:22:56 CET] <Shirudo> size= 196254kB time=00:01:58.47 bitrate=13569.5kbits/s [06:22:57 CET] <Shirudo> video:0kB audio:196246kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.004178% [06:27:39 CET] <luzie> thank you [06:30:14 CET] <situation> wow [06:30:19 CET] <situation> dude, pastebin that shit [06:33:27 CET] <Shirudo> I apologize if I'm causing any problems, I have never used IRC before and am unfamiliar with the procedures here. [06:34:47 CET] <FireFly> Generally for pasting anything longer than a line or two, you'd want to use a pastebin service [06:35:51 CET] <Shirudo> Thanks, I'll keep that in mind. [06:42:53 CET] <Shirudo> I have made a paste at this location, http://pastebin.com/PmhCga3R [06:44:06 CET] <Shirudo> At least I've gotten a new skill out of this, I never knew such websites existed. [06:50:53 CET] <dystopia> your command is wrong [06:51:07 CET] <dystopia> ffmpeg -i "in_filename" -acodec flac -compression_level 12 -y "out_filename.flac" [06:51:18 CET] <dystopia> so in your example [06:51:45 CET] <dystopia> ffmpeg -i "01\ -\ Camel\ -\ Aristillus.dsf" -acodec flac -compression_level 12 -y "01 - Aristillus.flac" [06:52:35 CET] <Shirudo> Thank you, I will amend my command and check whether the result is playable. [07:07:25 CET] <Shirudo> The file I get is still unplayable both in the Exaile audio player, which gives the error "streaming stopped, reason not-negotiated " and the Totem video/audio player, which gives a similar error. [07:08:29 CET] <Shirudo> I tried opening it in Audacity though as an experiment, and it did play. I do not know why it would play only in Audacity and in no conventional audio player. [07:10:52 CET] <Shirudo> The paste for the amended command's output is http://pastebin.com/n5EtAtae [08:03:41 CET] <Shirudo> In Audacity I exported the file as 16-bit 48000 Hz, and it successfully played in Exaile. That lends credence to my theory that the issue was the enormous sample rate of the original converted flac file. Thanks dystopia for taking the time to help me. [08:07:22 CET] <relaxed> Anyone have a recent intel cpu that supports h264_qsv running linux? [08:35:00 CET] <test123`> a [08:41:21 CET] <GreaseMonkey> currently trying to get libavformat/libavcodec/libswscale to behave, it works fine EXCEPT when i try to decode h264 in which case i get the "no frame!" error on every single frame [08:41:42 CET] <GreaseMonkey> i have tried several different approaches and it refuses to work [08:42:37 CET] <GreaseMonkey> vp8's fine, flv video's fine, h264 fails in both mp4 and mkv containers [09:33:14 CET] <GreaseMonkey> ah, got it working now [09:33:55 CET] <GreaseMonkey> protip: it's better to rip the context from the stream than use avcodec_alloc_context3 [11:47:47 CET] <termos> I sometimes get these messages "Buffer queue overflow, dropping." and then my audio/video is out of sync! Is it possible to detect this in the C API? [11:48:21 CET] <termos> av_buffersrc_add_frame_flags does not return <0 when this is happening, very strange [13:03:42 CET] <foolishmonkey> hi, I'm seraching the Internet for the different languages codes list but I faile to find one [13:03:49 CET] <foolishmonkey> does someone have a list? [13:39:35 CET] <dystopia> what do you mean foolishmonkey? [13:40:03 CET] <foolishmonkey> dystopia, to set up metadata, -metadata:s:1 language=eng [13:40:15 CET] <foolishmonkey> I'm searching the code for Cantonese [13:45:31 CET] <J_Darnley> heh [13:45:42 CET] <J_Darnley> The internet suggests there isn't one [13:45:51 CET] <J_Darnley> at leastnot a 3-char one [13:46:19 CET] <foolishmonkey> There is zho for Chinese, but Chinese could be Mandarin or Cantonese or... [13:50:58 CET] <J_Darnley> ISO 639-3 has half a dozen English variants but not Cantonese. LOL [16:48:50 CET] <smdrz> trying to convert with h264_qsv, compains Error initializing an internal MFX session [16:49:01 CET] <smdrz> using ffmpeg 3.0 [17:15:12 CET] <shincodex> if av_read_frame returns < -1 cause i disconnect network... is it save to keep calling av_read_frame? Lets say i pull plug to network stream then plug it back in... Will av_read_frame eventually figure out it has network data? Or because of connection reset by peer i have to redo entire av format connection process? [17:15:18 CET] <smdrz> http://pastebin.com/tiQ0BHWn [17:24:09 CET] <shincodex> so yeah [17:24:16 CET] <shincodex> anyone answer that before i peered myself? [17:25:01 CET] <shincodex> I just tested av_read_frame by plug pull peer [17:25:14 CET] <shincodex> waited 10 minutes [17:25:30 CET] <shincodex> put plug back in and av_read_frame started to return good values [17:25:36 CET] <shincodex> and my video stream doesnt seem corrupted [17:44:02 CET] <smdrz> not using intel media studio [17:52:56 CET] <jkqxz> smdrz: That's basically the "not found" message. What did you do to make that binary? (You built and linked with libmfx?) [18:16:03 CET] <salviadud> I was performing a render operation that involved stretching and changing the aspect ratio from a mp4 file coded in h264 [18:16:21 CET] <salviadud> into the same library, h264 [18:16:53 CET] <salviadud> unfortunately, I left my computer at a stop where my leg unplugged it from the ac/dc adapter [18:17:09 CET] <salviadud> and even more dumb, I didn't reconnect it after 3 hours of laptop battery. [18:17:31 CET] <salviadud> I checked the incomplete .mp4 file and I couldn't open it. [18:17:41 CET] <salviadud> Is that normal? shouldn't I see some sort of progress? [18:19:58 CET] <jkqxz> Yes, that's normal. mp4 files have to be written whole because they write vital data at the end of the process. [18:22:13 CET] <salviadud> Well, I decided to render it again. [18:22:14 CET] <jkqxz> If you want to be able to use a partially-written file you will need a different container, such as mkv. [18:22:18 CET] <salviadud> But I changed the settings abit. [18:22:48 CET] <salviadud> I recompiled the x264 library so that it would support SSE, but not ASM [18:23:00 CET] <salviadud> and I recompiled ffmpeg so that it would only use the SSE flag [18:23:14 CET] <salviadud> I wonder if ffmpeg is able to force ASM [18:23:21 CET] <salviadud> or if that is library dependant [18:23:52 CET] <salviadud> My guess is that it is library dependant, after coding 30 seconds of frames in 27 minutes, I calcuated that it would take about 4 to 5 days [18:24:18 CET] <salviadud> rendering without both sse and asm makes that render take like a month [18:24:27 CET] <salviadud> Maybe I should be glad I stopped it. [18:28:16 CET] <jkqxz> Why are you recompiling it to disable assembly? It is faster and the output is bit-identical: disabling those things is only meaningful for testing. [18:30:12 CET] <Mavrik> O.o [18:30:20 CET] <Mavrik> Also disabling ASM and enabling SSE makes no sense. [18:30:35 CET] <furq> what are you doing that takes 27 minutes to encode 30 seconds of video [18:31:31 CET] <furq> http://s3media.247sports.com/Uploads/Boards/191/22191/153683.jpg [18:31:33 CET] <furq> is this your laptop [18:31:35 CET] <jkqxz> The compiler might be able to autovectorise some of the C code, so it's possible some sse options can help without assembly. [18:33:36 CET] <salviadud> I'll tell you what happens in 4 days. [18:33:41 CET] <salviadud> or 5 [18:33:53 CET] <furq> oh wait are you the guy who's trying to unlock a hidden message in porn using a bucket [18:34:04 CET] <salviadud> sorta, yeah [18:34:06 CET] <furq> there's not much point trying to make sense of your actions then [18:34:21 CET] <durandal_1707> just ignore [18:34:51 CET] <furq> it's been broadly entertaining thus far [18:34:54 CET] <salviadud> I think that my asm question referring to ffmpeg is legit [18:35:32 CET] <furq> well as jkqxz said the output should be bit-identical so there's no point disabling it [18:35:35 CET] <furq> even for your crazy mission [18:35:42 CET] <salviadud> and there are several videos which don't contain a hidden message which can be rendered with all optmizations [18:36:41 CET] <salviadud> oh, and with asm and sse on, it takes like 2 days. [18:36:50 CET] <salviadud> but, I can't decipher it [18:37:57 CET] <furq> haven't you been at this for months [18:38:02 CET] <furq> this hidden message had better be good [18:38:07 CET] <salviadud> it is [18:38:12 CET] <salviadud> it involves sasha grey [18:38:15 CET] <furq> like so good that indiana jones turns up at your house [19:08:07 CET] <xeons> http://stackoverflow.com/questions/35416110/ffmpeg-concat-video-and-audio-o… [20:06:27 CET] <thecount12> Hello I am receiving an ERROR: libzvbi not found when I run ./configure --enable-libzvbi --enable-gpl --enable-memalign-hack --arch=x86 --target-os=mingw32 --cross-prefix=i686-w64-mingw32- --pkg-config=pkg-config [20:06:51 CET] <J_Darnley> Did you install it? [20:06:58 CET] <thecount12> yes [20:07:04 CET] <thecount12> it works when I don't cross compile [20:07:21 CET] <J_Darnley> Did you build it for the right platform? [20:07:35 CET] <thecount12> interesting [20:07:45 CET] <thecount12> i did an apt-get on libzvbi [20:08:08 CET] <J_Darnley> I wonder why that didn't give you a Windows library(!) [20:08:16 CET] <thecount12> doh! [20:08:34 CET] <thecount12> silly [20:38:28 CET] <cyphix> Hi! I'm trying to reproduce the ffmpeg command my mediacrush server is using to encode uploaded videos. According to 'ps aux', this is the run command: 'ffmpeg -y -i /tmp/tmpSXdVCo.mkv -c:v libvpx -c:a libvorbis -q:a 5 -pix_fmt yuv420p -quality good -b:v 5M -crf 5 -vf scale=trunc(in_w/2)*2:trunc(in_h/2)*2 -map 0:v:0 -map 0:a:0 /var/www/server.com/MediaCrush/storage/h18uoUjcQ6o6.webm'. But when I try to run it [20:38:29 CET] <cyphix> manually from a shell, it returns "bash: syntax error near unexpected token `(' ". Would anybody have an idea why the copied command doesn't work? [20:39:19 CET] <BtbN> Because there is an unexpected token near ( [20:39:33 CET] <pzich> Try putting the stuff after -vf in single quotes, like 'scale=trunc(in_w/2)*2:trunc(in_h/2)*2' [20:39:45 CET] <podman> cyphix: what pzich said [20:42:18 CET] <J_Darnley> cyphix: you need to quote or escape special characters [20:42:51 CET] <J_Darnley> And that is a dumb command [20:42:57 CET] <pzich> hah [20:43:49 CET] <cyphix> Oh ok, thanks. Now I have a "Unable to parse option value "0 -map 0" as boolean", but I guess it's an improvement... [20:45:17 CET] <cyphix> J_Darnley: I use the command given by mediacrush. I don't have the knowledge to evaluate this command, but any improvement would be much appreciated, the encoding process is insanely slow... [20:45:38 CET] <J_Darnley> Start with the full output. [20:45:44 CET] <J_Darnley> That might tell us why its slow [20:46:45 CET] <doub__> I'm trying to use ffmpeg to decode/resize a video, and feed it raw-ish to another program through stdout, but after a few hundred frames (exactly how many depending mostly on input video), ffmpeg stops with a broken pipe error. Do I need special options to have it wait for consumption of frames on stdout? [20:46:51 CET] <cyphix> here is the result of my command: https://p.cyphix.org/view/2f3ad3aa [20:47:36 CET] <J_Darnley> You have quoted too much [20:47:40 CET] <pzich> note what I showed you should quote [20:47:43 CET] <pzich> not the -map stuff [20:47:50 CET] <pzich> up to the second *2 [20:48:00 CET] Action: J_Darnley must have missed that [20:48:18 CET] <pzich> > Try putting the stuff after -vf in single quotes, like 'scale=trunc(in_w/2)*2:trunc(in_h/2)*2' [20:48:32 CET] <pzich> granted, "the stuff after -vf" can be confusing [20:48:44 CET] <cyphix> oh ok [20:49:12 CET] <J_Darnley> doub__: I would expect write to block by default but I am no expert. [20:49:15 CET] <pzich> and I did say single quotes, but I think double should work fine in this case too [20:49:37 CET] <pzich> doub__: have you tried writing your raw output to a file, then piping that in with cat to the second program? [20:49:45 CET] <pzich> just to ensure that it's the pipe that's the issue, not either command [20:49:48 CET] <doub__> pzich: dumping to a file works fine [20:50:01 CET] <doub__> and then reading the file, it's in the correct format [20:50:11 CET] <doub__> piping to a file works fine too [20:50:30 CET] <doub__> i also tried piping to cat, and then to a file, and it works fine too (all on Winows) [20:50:44 CET] <pzich> ah, sorry, I'm no help on windows [20:50:57 CET] <pzich> I do something fairly similar at quite a large scale, but on linux [20:51:37 CET] <J_Darnley> Have you set stdin to be binary mode? [20:51:57 CET] <doub__> no, i'm not sure how to do that [20:52:24 CET] <J_Darnley> I'm not sure either so I'll go look at something that does do it. [20:52:33 CET] <J_Darnley> (x264) [20:52:34 CET] <cyphix> ok, the command works, but it encodes at 0.4 fps... Any idea what's slowing it that much? [20:53:07 CET] <J_Darnley> doub__: _setmode( _fileno( stdin ), _O_BINARY ); [20:53:44 CET] <J_Darnley> cyphix: again, we want the whole output. [20:54:03 CET] <doub__> J_Darnley: ok, i'll test that, but it could take a little while, i'm using Lua at the moment and that's not exposed AFAIK [20:54:29 CET] <J_Darnley> :) I was wondering if you were. [20:54:37 CET] <cyphix> J_Darnley: yeah sorry, it's coming. I've issues pasting a moving output [20:54:46 CET] <J_Darnley> ah okay [20:55:19 CET] <J_Darnley> cyphix: stop it then copy [20:57:00 CET] <cyphix> J_Darnley: Yeah but then the last line is all recovered [20:57:05 CET] <cyphix> https://cyphix.org/2016-02-15_20-56-31_scrot.png [20:58:50 CET] <J_Darnley> The progress line really doesn't tell us all that much. [20:59:14 CET] <J_Darnley> I'm going to blame how you compiled ffmpeg and probably libvpx too [21:00:19 CET] <J_Darnley> A mess of a configure line hiding disable-runtime-cpudetect [21:00:31 CET] <cyphix> J_Darnley: Oh you can. I did my best, but it's probably not much. Any advice on that matter would be welcome. [21:01:18 CET] <J_Darnley> Start by dopping every option [21:01:29 CET] <J_Darnley> Then enable what you need. [21:01:42 CET] <doub__> J_Darnley: that works with a basic pipe, now I need to figure out how to do that with a popen [21:01:58 CET] <J_Darnley> The "b" option? [21:02:33 CET] <doub__> i think the Lua binding doesn't let that through, probably time for a patch, thankfully i build my lua interpreter myself [21:02:48 CET] <doub__> do you know why the text mode causes the issue? [21:03:10 CET] <J_Darnley> One of the ascii control chars signals end-fo-stream [21:03:13 CET] <J_Darnley> *of [21:03:28 CET] <J_Darnley> then windows closes the file/pipe/whatever [21:03:41 CET] <cyphix> J_Darnley: I tried to compile it with the minimum required by mediacrush, which are libtheora, libvorbis, libx264, libfdk_aac, and libvpx. But I couldn't encode wmv files. So I have to admit I used a configure file I found somewhere :/ So I don't know what to use... [21:03:46 CET] <J_Darnley> then ffmpeg fails to write [21:04:37 CET] <J_Darnley> Does ffmpeg even have *any* WMV encoders? [21:05:02 CET] <J_Darnley> oh it has versions 1 and 2 [21:05:06 CET] <cyphix> Ah. That I have no idea... [21:05:16 CET] <doub__> J_Darnley: ah, ok, thanks for the info, and rb works in popen, so problem fixed :D [21:05:22 CET] <J_Darnley> :) [21:07:10 CET] <cyphix> J_Darnley: So do you advice me to go back to the version including the minimal requirements, and work from there? [21:07:20 CET] <J_Darnley> Yes. [21:07:42 CET] <J_Darnley> If you have a problem with a specific file we are willing to help. [21:07:59 CET] <cyphix> Ok, I'll do that and see what happens in more details. [21:08:07 CET] <J_Darnley> I would also suggest recompiling libvpx to make sure you didn't do something silly there. [21:10:02 CET] <cyphix> J_Darnley: Hem.... I don't know how to do that :/ [21:10:22 CET] <J_Darnley> Did you not do it before? [21:10:43 CET] <J_Darnley> Or did you just use the version provided by your OS? [21:11:16 CET] <cyphix> Apparently not. I can't find the libvpx package on my debian system. [21:12:02 CET] <cyphix> Oh, I have libvpx1 installed [21:12:18 CET] <cyphix> From the official debian repos. [21:12:33 CET] <cyphix> And I didn't touch it, so I guess it's intact [21:13:58 CET] <cyphix> Is it fine as it is, or should I do something about it? [21:21:23 CET] <J_Darnley> Perhaps the packer did manage to compile it correctly [21:21:29 CET] <J_Darnley> leave it be for now. [21:21:40 CET] <satviewer> Is there some problem with the mailing list? I signed up today and attempted to post a message twice and it never got posted (and I did make sure it came from the same email address I used when signing up). [21:22:04 CET] <J_Darnley> Did you confirm your subscription? [21:22:09 CET] <cyphix> J_Darnley: Ok. I'm compiling the cleaner version now. I'll see what it does. [21:23:53 CET] <satviewer> Anyway I was just wondering if the syntax changed in ffmpeg 3.0. I have been using the technique I found in this article to receive a satellite channel: [21:23:56 CET] <satviewer> https://freetoairamerica.wordpress.com/2015/09/03/fixing-the-audio-on-live-… [21:24:32 CET] <satviewer> But after I installed 3.0 I got no audio at all. Reverting back to 2.8.2 made it work again. [21:25:35 CET] <J_Darnley> odd [21:25:38 CET] <satviewer> It is a pipe command in TVHeadEnd of this form: pipe:///usr/local/bin/ffmpeg -loglevel fatal -i http://127.0.0.1:9981/stream/channelnumber/CHANNEL_NUMBER -c:v copy -c:s copy -c:d copy -c:t copy -filter_complex [0:1][0:2][0:3]amerge=inputs=3,pan=5.1|FL=c0|FR=c1|FC=c2|LFE=c3|BL=c4|BR=c5 -c:a eac3 -f mpegts pipe:1 [21:25:59 CET] <satviewer> I see now they note in the article that it doesn't work in 3.0! [21:26:35 CET] <durandal_1707> what error you get? [21:26:43 CET] <J_Darnley> Perhaps someone with the problem should file a bug. [21:27:16 CET] <satviewer> So I was just wondering if there might have been some change in syntax that would cause that not to work under 3.0. [21:29:34 CET] <satviewer> If you were asking me, I don't see any errors but then because it is run from within TVHeadEnd I wouldn't. I don't really know how or why this works, I just followed the instructions in the article and it does as long as I don't use ffmpeg 3.0 [21:30:18 CET] <J_Darnley> Perhaps you should drop the loglevel option and look at stderr. [21:30:23 CET] <satviewer> Oh and yes I did confirm my subscription. [21:31:51 CET] <satviewer> Well I have already uninstalled 3.0 and put 2.8.2 back. I just wondered if there was anything obvious about the syntax where someone would look at it and say "oh we changed that" or something. [21:32:17 CET] <durandal_1707> nothing changed [21:33:42 CET] <durandal_1707> satviewer: do you know how much channels each stream have? [21:34:29 CET] <satviewer> Well that is weird then. I used the static build of ffmpeg from http://johnvansickle.com/ffmpeg/ which is what I have been using all along, and it's just strange because the video still passes through with no problem in 3.0 but the audio is gone. [21:35:47 CET] <satviewer> That's why I posted thie link, it is a really weird stream. Actually hold on a second I can get you better information. [21:37:03 CET] <satviewer> This earlier article from that site describes the streams in the first couple of paragraphs: https://freetoairamerica.wordpress.com/2014/09/30/fixing-the-audio-on-recor… [21:37:33 CET] <satviewer> Basicall it appears there are four audio streans with two channels in each [21:37:52 CET] <satviewer> And only the first three streams are used to get 5.1 audio. [21:39:18 CET] <satviewer> Also the entire full stream is a "Transport Stream", whatever that is. [21:40:24 CET] <durandal_1707> well perhaps the order of streams changed [21:40:39 CET] <furq> he said it still works in 2.8 [21:41:03 CET] <satviewer> Not in the original, as I said it immediately starts working again if I revert to 2.8.2 [21:41:26 CET] <durandal_1707> mpegts have underdone some changes [21:42:15 CET] <durandal_1707> so you should use ffprobe to report stream numbers [21:42:32 CET] <satviewer> Oh, so does that mean this can't be done anymore in 3.0? [21:42:57 CET] <satviewer> brb door [21:43:01 CET] <durandal_1707> or use better command, 0:a:1 or smth like that [21:43:42 CET] <durandal_1707> it can be done, just info is missing [21:44:32 CET] <durandal_1707> using 0:1 as stream selection is bad idea as order can change [21:47:14 CET] <satviewer> Okay well unfortunately I don't understand any of that., I am just using what was posted on that site and have no idea how they came up with it. And I just found out I need to leave for a while. [21:47:40 CET] <furq> satviewer: replace [0:1] with [0:a:1] etc [21:47:57 CET] <furq> the mpegts demuxer might have changed the way it orders input streams in the update [21:48:15 CET] <satviewer> But I will leave this up while I am gone in case anyone has any other thoughts, but I am so clueless about this I would need a complete url to try similar to what I posted. [21:48:33 CET] <satviewer> Thank you. [21:49:46 CET] <satviewer> furq "replace [0:1] with [0:a:1] etc" doesn't help me unless you can spell out what "etc" means, as I said I am totally clueless about this. [21:49:58 CET] <furq> -filter_complex [21:50:02 CET] <satviewer> Back later. [21:50:03 CET] <furq> ugh [21:50:14 CET] <furq> in -filter_complex [0:1][0:2][0:3]... [21:50:34 CET] <furq> change all the [0:n] to [0:a:n] [22:40:07 CET] <satviewer> furq thank you, I think I understand, I will give that a try later but I will have to install 3.0 again so I can't do it right this second, but I will give it a try. Thank you. [22:51:12 CET] <adc> I've written some code to add sounds to an audio file at a number of given points (example command/output: http://pastebin.com/m6TLauek) and I've gotten it working correctly, but the process seems slow (say, 60-70 minutes for the addition of 1,000~ sounds across an hour of playback time). I was wondering if there was a faster way to do this, or if my expectations are unrealistic and this is the cost of so much re-encoding [23:19:52 CET] <Plorkyeran_> decoding then reencoding flac should be doable at >100x realtime unless you're running it on a toaster [23:20:45 CET] <adc> Running it on a 4790k, so that shouldn't be an issue [23:22:10 CET] <Plorkyeran_> a baseless guess: your filter may be seeking between the insertion points by decoding from the beginning of the file, resulting in it being decoded 1000 times [23:25:18 CET] <adc> That would make sense - I run the command once per delay amount [23:26:32 CET] <adc> Would there be any way to get around that? I don't know much about ffmpeg, and this was the best I could find on Google [23:28:39 CET] <Plorkyeran_> lazy solution is to just decode to pcm first, do all the modifications to that, then only encode to flac at the end [23:30:24 CET] <adc> Is pcm lossless? My original files are in "pcm_s16le" but running that command a few hundred times ended up with massive issues in the output [23:30:46 CET] <adc> With the most recently encoded files sounding fine, but the first ones added sounding horrible [23:31:14 CET] <J_Darnley> If you don't do anything to the audio then it should remain the same data [23:32:51 CET] <Plorkyeran_> as long as you don't do any accidental format conversion or anything it'll literally just be a dump of the decoded audio data with some headers [23:32:51 CET] <adc> I decode it, add a delay to the start and reencode [23:37:19 CET] <eksrow> Hi I just read about 3.0. If I want to compile ffmpeg with mp3 support can I still use this guide (https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu)? I read about the native aac encoder now being the reccomended one, so I should skip the 'libfdk-aac' step? [23:37:52 CET] <J_Darnley> huh? mp3 is not aac [23:38:29 CET] <J_Darnley> While I'm not sure, I think libfdk is still better than the internal encoder. [23:39:37 CET] <JEEB> eksrow: if you only need LC-AAC encoding, just use the internal one [23:39:49 CET] <JEEB> if you need HE-AAC, then you still need fdk-aac [23:40:02 CET] <J_Darnley> ah, noted. [23:43:26 CET] <furq> fdk is better for vbr as well iirc [23:46:25 CET] <eksrow> JEEB: thank you! J_Darnley: I mentioned mp3 support as the reason for compiling, I read on HN about the 3.0 release and in the 'patch-notes' as internal aac encoder being recommended over the others, the compiling step has a step where you add another AAC lib. so I was a bit confused [23:46:45 CET] <furq> eksrow: do you need mp3 encoding support or just decoding [23:47:47 CET] <furq> actually if you're on ubuntu/debian it doesn't matter because 3.0 isn't in the repos yet [23:48:10 CET] <eksrow> furq: decoding definitely, encoding I can do without(I just need to send the output to Youtube) [23:48:27 CET] <furq> ffmpeg from repos can decode mp3 [23:48:40 CET] <furq> the mp3 decoder is builtin [23:49:01 CET] <J_Darnley> have the linux retard s stopped disabling mp3 in everything [23:49:03 CET] <J_Darnley> ? [23:49:21 CET] <furq> iirc the freebsd package doesn't include mp3 [23:49:40 CET] <furq> although at least they make it easy to build it with lame [23:50:34 CET] <furq> oh [23:50:43 CET] <furq> apparently lame is included in the debian package now [23:50:57 CET] <J_Darnley> Wow(!) [23:51:31 CET] <eksrow> furq: do the static binaries on the ffmpeg website also provide mp3 decoding (or only from the repo's)? [23:54:10 CET] <furq> probably? i've never used them [23:54:15 CET] <furq> oh, decoding [23:54:18 CET] <furq> almost certainly then [23:58:26 CET] <eksrow> alright, thank you! [00:00:00 CET] --- Tue Feb 16 2016

1 0

ffmpeg-devel.log.20160214
by burek 15 Feb '16

15 Feb '16

[00:12:14 CET] <cone-621> ffmpeg 03FearThe1337 07master:c33ffc7b21b9: libavdevice/dshow.c: Correct CoGetMalloc check [00:38:57 CET] <cone-621> ffmpeg 03Neil Birkbeck 07master:3b0974d3ef7f: lavc/hevc Parse SEI_TYPE_MASTERING_DISPLAY_INFO and propagate content into the AVMasteringDisplayMetadata side data. [00:39:03 CET] <J_Darnley> When did ffmpeg get a ridiculous tty demuxer and why can't I find it in the docs? [00:41:07 CET] <wm4> it's rather old [00:41:11 CET] <wm4> and indeed ridiculous [00:41:29 CET] <wm4> I have it blacklisted because it tends to probe positively for text files or so [00:41:52 CET] <J_Darnley> Is this what was that big drama over data leaks was a few weeks ago? [00:42:10 CET] <nevcairiel> nah [00:42:53 CET] <wm4> that was concat and hls [00:44:06 CET] <Timothy_Gu> J_Darnley: i believe it was a relic of mplayer era [00:44:28 CET] <J_Darnley> Damn that is *old* [00:48:04 CET] <Timothy_Gu> durandal_1707: can you take a look at "checkasm: Add vf_blend tests" when you get a chance? thanks [00:48:36 CET] <Timothy_Gu> i thought i sent it two days ago but apparently i forgot [01:30:31 CET] <cone-621> ffmpeg 03Timothy Gu 07master:123ff81a45b5: avutil: Remove x86_cpu.h [01:36:38 CET] <cone-621> ffmpeg 03Marton Balint 07master:0250fc2146b3: avformat/img2enc: return error if image rename fails [01:36:39 CET] <cone-621> ffmpeg 03Marton Balint 07master:35890aaa653a: avformat/img2enc: disable atomic file creation by default [01:40:42 CET] <J_Darnley> Timothy_Gu: are you looking for CVTPS2DQConvert Packed Single-Precision FP Values to Packed Dword Integers? [01:41:06 CET] <Timothy_Gu> J_Darnley: no, but rather to make sure that the value is correctly rounded/truncated when converting [01:41:30 CET] <Timothy_Gu> plus, im already using that instruction :) [01:41:39 CET] <J_Darnley> ah [01:41:57 CET] Action: J_Darnley must consult the other half of the manual [01:43:18 CET] <J_Darnley> oh that keeps float [01:48:07 CET] <J_Darnley> I guess I don't have any other suggestions. [01:48:26 CET] <J_Darnley> I haven't done any float simd yet. [02:00:16 CET] <Timothy_Gu> the other option is to change the MXCSR register, but that is ugly and slow [02:02:21 CET] <Timothy_Gu> what happened to the nvenc header bundling patch? [02:03:57 CET] <Timothy_Gu> oh andreas blocked it [02:08:20 CET] <michaelni> nevcairiel, is it ok to apply andreas hwaccel-mt error->warning patch (now after the vp9 fix) ? [02:50:13 CET] <cone-621> ffmpeg 03Marton Balint 07master:3235241061d6: avutil/parseutils: use microsecond precision when parsing "now" in av_parse_time() [02:50:14 CET] <cone-621> ffmpeg 03Marton Balint 07master:f834f0cab60f: avutil/parseutils: accept everything in av_parse_time that ff_iso8601_to_unix_time accepts [02:50:15 CET] <cone-621> ffmpeg 03Marton Balint 07master:e942454daf05: avformat/utils: add ff_parse_creation_time_metadata [02:50:16 CET] <cone-621> ffmpeg 03Marton Balint 07master:ea1bf08a4c5a: avformat/asfenc: use ff_parse_creation_time_metadata [02:50:17 CET] <cone-621> ffmpeg 03Marton Balint 07master:bf0607b6dbca: avformat/dvenc: use ff_parse_creation_time_metadata [02:50:18 CET] <cone-621> ffmpeg 03Marton Balint 07master:83b01ed21239: avformat/ffmenc: use ff_parse_creation_time_metadata [02:50:19 CET] <cone-621> ffmpeg 03Marton Balint 07master:5c20bc8f4726: avformat/gxfenc: use ff_parse_creation_time_metadata [02:50:20 CET] <cone-621> ffmpeg 03Marton Balint 07master:5f64f3d8cf06: avformat/movenc: use ff_parse_creation_time_metadata [02:50:21 CET] <cone-621> ffmpeg 03Marton Balint 07master:ad17cc97446c: avformat/mxfenc: use ff_parse_creation_time_metadata [02:50:23 CET] <cone-621> ffmpeg 03Marton Balint 07master:66e85a180ab3: avformat/matroskaenc: use ff_parse_creation_time_metadata [02:50:24 CET] <cone-621> ffmpeg 03Marton Balint 07master:a573e6c10371: avformat/utils: remove ff_iso8601_to_unix_time [03:01:57 CET] <jamrial> most of those could have been squashed into a single patch [03:03:48 CET] <Gramner> Timothy_Gu: is that float conversion required? what happens if you multiply by 255 first, then divide, while keeping them as integers? [03:04:22 CET] <Timothy_Gu> Gramner: hmm good idea. Why didn't I think of it? [03:04:29 CET] <Timothy_Gu> ah the original C code uses ints [03:04:32 CET] <Timothy_Gu> *floats [03:04:45 CET] <Gramner> the c could be changed as well in that case [03:04:49 CET] <Timothy_Gu> https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_blend.c#L243 [03:04:50 CET] <Timothy_Gu> yeah [03:12:48 CET] <Gramner> hmm, is there even an integer SIMD divide though? never needed to use that [03:13:43 CET] <atomnuker> for integer division? nope [03:13:46 CET] <BBB> nope [03:13:57 CET] <BBB> the integer simd divide is pmulhuw with the inverse [03:14:00 CET] <BBB> its not exacy [03:14:11 CET] <BBB> (see whatever your quantize() does in x264) [03:15:35 CET] <atomnuker> you might as well use FASTDIV if precision's not important though [03:37:30 CET] <Timothy_Gu> jamrial: what do you mean by "these two"? [03:41:29 CET] <jamrial> roundps and minps [03:43:35 CET] <Timothy_Gu> without roundps the cvtps2dq uses the wrong rounding [03:44:25 CET] <Timothy_Gu> without minps the conversion does something weird with divide by 0 (can't remember what) [03:45:09 CET] <Timothy_Gu> "If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned." [03:46:03 CET] <Timothy_Gu> hah! found it: CVTTPS2DQ [03:50:29 CET] <Timothy_Gu> also scratch on the minps comment. seems like it works fine now without it [04:09:30 CET] <Timothy_Gu> hmm minps seems needed again lol [04:24:48 CET] <Timothy_Gu> im feeling my mail frequency is approaching Mats's... [04:28:11 CET] <jamrial> regarding the speed of gcc autovectorization, did you try it again after your "Reduce number of arguments for kernel function" patch? [04:31:46 CET] <Timothy_Gu> jamrial: not really [05:04:20 CET] <Timothy_Gu> jamrial: just tested, doesn't make any difference [05:04:38 CET] <jamrial> ok [05:04:43 CET] <Timothy_Gu> probably because the function already has like 9 args [05:05:45 CET] <jamrial> it was mostly the fact you changed the loop into a simpler one which may be less confusing to gcc's vectorizer [05:07:16 CET] <Timothy_Gu> ah [05:07:48 CET] <Timothy_Gu> gcc can't vectorize integer divide anyway [05:07:51 CET] <Timothy_Gu> neither can I :) [06:22:49 CET] <andrewrk> Timothy_Gu, are you the same one who just accepted my pull request on mxe? [06:48:38 CET] <Timothy_Gu> andrewrk: yes [06:48:49 CET] <andrewrk> heh. nice :) [06:48:53 CET] <Timothy_Gu> :) [09:29:12 CET] <mateo`> xyz: depending on the mediacodec implementations, you are likely to be spammed with this kind of message, does the decoder (h264_mediacodec) output buffers as expected ? [10:30:53 CET] <xyz> mateo`: yes it works fine on videos I've tested [10:36:10 CET] <wm4> mateo`: so is asynchronity a problem? do you have a link to your wip? [10:56:49 CET] <mateo`> wm4: https://github.com/mbouron/FFmpeg/commits/stupeflix-devel [10:57:49 CET] <mateo`> wm4: asynchronity is not a problem atm, the big missing piece of this wip is surface output / hwaccel [11:05:33 CET] <wm4> hm ok [11:06:01 CET] <mateo`> I'm wondering what users would expect from the hwaccel part, do they want to provide their own surface, if so, is it enough if the surface is provided as a jobject (android/view/Surface), as there is not way, afaik, to convert a ANativeWindow to a java Surface object (you can do the other way around). [11:10:23 CET] <mateo`> About the asynchronity, the complexity will be at the user level, ie: if you want to read the texture for a frame you have just renderered onto the surface, you have to listen to a particular callback, and then call the appropriate function [11:10:58 CET] <wm4> personally I'd be interested in gl interop, but no idea how that works, and I heard it's slower [11:11:29 CET] <wm4> wat [11:11:48 CET] <mateo`> you can do that with a fbo copy [11:12:07 CET] <mateo`> so you get a GL_TEXTURE_2D to deal with it in the end [11:12:16 CET] <mateo`> and not an OES texture [11:13:08 CET] <wm4> what's the problem with an oes texture? [11:13:39 CET] <mateo`> if your sink is able to deal with such texture, there is no problem [11:15:55 CET] <fritsch> if it helps, you can have a look in kodi concerning mediacodec surface rendering [11:16:18 CET] <fritsch> works nicely, besides all the shortcomings mediacodec has concerning postprocessing / colors and the like [11:20:06 CET] <mateo`> fritsch: yes, i've looked at the code base in the past to see how the java listener was implemented, but i didn't looked at how the display of the frames were handled. [11:22:08 CET] <mateo`> i've implemented the surface output in gst also, wm4, i think a good start would be that i try to integrate this in libmpv while i develop it so i have a real use case [11:26:17 CET] <wm4> personally I don't have a single android device, but maybe xyz is interested in going further [11:27:11 CET] <fritsch> i implemented the "new" v23 passthrough api lately ... [11:27:15 CET] <fritsch> :-( not fun [11:27:22 CET] <fritsch> they pack themselves [11:27:28 CET] <fritsch> and don't consume IEC frames [11:27:43 CET] <fritsch> so half of the formats they don't recognize, stall the sink [11:29:33 CET] <mateo`> fritsch: what a mess :( [11:30:10 CET] <fritsch> yeah - I am in contact with their chief audio dev [11:30:11 CET] <fritsch> :-) [11:30:24 CET] <fritsch> chances are very good that next stable will have an IEC mode [11:30:43 CET] <fritsch> e.g. 2 channels 192 khz or 2 channels 48 / 44.1 khz for EAC3, AC3, DTS [11:30:49 CET] <fritsch> and 8 channels 192 khz for dtshd, truehd [11:30:59 CET] <fritsch> so you can push those iec frames like you would "normally" do [11:31:07 CET] <fritsch> on all available other normal apis [11:31:34 CET] <fritsch> for now kodi will only use this new api on v23 and later (an on nvidias shield v22, which backports some v23) [11:31:48 CET] <fritsch> we will even use PCM/16bit iec passthrough on v21, v22 [11:31:55 CET] <fritsch> as this other api is useless and overly complicated [11:35:04 CET] <mateo`> :( [11:36:26 CET] <nevcairiel> michaelni: i think the warning could use some clearer wording that its use is discouraged and known to break [11:36:28 CET] <mateo`> wm4: I meant I can help if there's an android project that uses libmpv to design how the hwaccel will work [11:37:07 CET] <mateo`> fritsch: do you use the MediaCodec C API in kodi in some cases ? [11:40:54 CET] <fritsch> https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/V… <- jni for the win :-) [11:41:28 CET] <wm4> m_frameready->WaitMSec(50); [11:41:50 CET] <fritsch> read ... [11:41:56 CET] <fritsch> more properly :-) [11:42:00 CET] <fritsch> it's a max wait [11:42:10 CET] <fritsch> if it was an always wait, would be hard to render more than 20 fps [11:42:41 CET] <fritsch> though I really must admit, that mediacodec not really matches in kodi's rendermanager concept [11:42:47 CET] <fritsch> those bypass renderers do whatever they want [11:42:54 CET] <wm4> I've stared a lot at kodi's mmal wrapper, which has 2 timeouts... they're design faults of the mmal API though [11:42:55 CET] <fritsch> so rendering subs and the like is always off [11:43:10 CET] <fritsch> yeah - the mmal kodi write has written the PI firmware [11:43:15 CET] <fritsch> :-) [11:45:17 CET] <fritsch> I am currently rewriting kodi's AMLCodec (though no timeline - I don't use it all and it's hard to motivate myself ... to do things I don't really care about) [11:59:05 CET] <michaelni> nevcairiel, ok, what should the warning say? "Hardware accelerated decoding with frame threading does require drivers and hw acceleration APIs to be thread save and or requires complex locking to be done by the user application otherwise It can result in artifacts or crashes. This combination is thus discouraged" [12:00:10 CET] <michaelni> or something else ?, nevcairiel you are the expert on this ... [12:13:11 CET] <xyz> mateo`: there's an android project here https://github.com/xyzz/mpv-android (and build scripts at https://github.com/xyzz/mpv-android-build) it's fairly basic and could be broken in some ways since I don't really have any experience with video, or android [12:49:07 CET] <nevcairiel> michaelni: maybe not quite as long, how about "Hardware accelerated decoding with frame threading is known to be unstable and its use is discouraged" [12:52:31 CET] <michaelni> sure, ok [13:17:38 CET] <cone-139> ffmpeg 03Alex Agranovsky 07master:09b8e97ab62d: lavf/mpjpeg: Trim quotes on MIME boundary, if present. [13:17:38 CET] <cone-139> ffmpeg 03Andreas Cadhalpun 07master:5edd1f62ca15: avcodec: only warn about hwaccel with frame threads [13:34:23 CET] <Daemon404> the reign of mats continues [13:34:34 CET] <Daemon404> i can't help but watch with morbid curiosity [13:46:38 CET] <Daemon404> woah what [13:46:45 CET] <Daemon404> did that massive flamethread end? [13:49:18 CET] <nevcairiel> by giving into the stupid flamers, so not really [13:49:29 CET] <Daemon404> i feared as much [13:49:53 CET] <nevcairiel> reasonable people have no chance to win if there is people like that around [13:50:10 CET] <nevcairiel> because you try to be reasonable and compromise, but they dont [13:50:12 CET] <nevcairiel> so.. [13:50:21 CET] <Daemon404> 18:27 <+wm4> nevcairiel: well I'm leaving the debian guy to you [13:50:21 CET] <Daemon404> 18:31 <@Daemon404> the worst part about these sorts of people is that they have infintie energy to argue their side [13:50:24 CET] <Daemon404> 18:31 <@Daemon404> eventually everyone else gets tired / gives up [13:50:26 CET] <Daemon404> 18:31 <@Daemon404> -> shit is pushed [13:50:30 CET] <Daemon404> quoting myself. [13:50:54 CET] <nevcairiel> personally I would just expell such people for the better of the project, but what can you do [13:51:01 CET] <wm4> at least there's still the warning, reducing the probability that unsuspecting new API users run into this [13:51:14 CET] <Daemon404> only if theyre looking at stdout. [13:51:17 CET] <Daemon404> er stderr [13:51:23 CET] <wm4> well they should [13:51:35 CET] <Daemon404> using as a library? to write a plugin? [13:51:37 CET] <Daemon404> seems unlikely [13:52:05 CET] <wm4> if you use it as a lib you should overwrite the log callback (and pray nothing else in your process uses libav*) [13:52:20 CET] <Daemon404> i wager next to no api users do this [13:52:27 CET] <Daemon404> maybe even just you. [13:52:44 CET] <nevcairiel> at least developers should look at the log to see if something is up, even if they dont expose it to users [13:54:20 CET] <nevcairiel> all sane players used it properly already anyway [14:53:49 CET] <cone-139> ffmpeg 03Alex Agranovsky 07master:ddda2cc43c85: lavf/mpjpeg: do not include CRLF preceding boundary as part of the returned frame [15:10:38 CET] <jamrial> so, was that hwaccel revert actually accepted by every person blocking it? [15:11:10 CET] <wm4> kind of [15:13:04 CET] <jamrial> meaning? [15:14:35 CET] <wm4> accepted but not too happy about it [15:14:43 CET] <jamrial> alright [15:22:18 CET] <cone-139> ffmpeg 03Paul B Mahol 07master:e167d4ebace0: avfilter/f_metadata: remove unused headers [15:52:05 CET] <cone-139> ffmpeg 03Carl Eugen Hoyos 07master:593bb50e062f: MAINTAINERS: Add myself as libutvideo maintainer. [15:52:24 CET] <durandal_1707> lol [16:03:57 CET] <jamrial> wm4: why didn't you start the vote? [16:04:15 CET] <jamrial> now carl came up with a bullshit excuse to keep that thing in place [16:07:47 CET] <wm4> I actually dislike drama [16:07:54 CET] <wm4> but maybe I or someone else should [16:14:32 CET] <cone-139> ffmpeg 03Carl Eugen Hoyos 07master:4c44972f9929: avcodec: Fix a typo. [17:16:04 CET] <J_Darnley> Why has vim started trying to remember the last cursor position in files? [17:16:27 CET] <BtbN> it allways did for me [17:17:13 CET] <J_Darnley> I'm sure its started doing that recently [17:17:38 CET] <J_Darnley> Every git commit message now starts where I left the cursor in the previous one. [17:31:34 CET] <c_14> J_Darnley: check /etc/vim/vimrc for something like g'\"" in an autocmd BufReadPost [17:40:03 CET] <J_Darnley> Files in /etc shouldn't be used if I have a ~/.vimrc [17:40:25 CET] <c_14> They are both sourced with options set in ~/.vimrc overriding those set in /etc/vim/vimrc [17:40:53 CET] <J_Darnley> /rolleyes [17:42:12 CET] <J_Darnley> Yes, there would appear to be some things in /etc [17:44:39 CET] <J_Darnley> "When editing a file, always jump to the last cursor position" FUCK YOU /ETC! [17:45:24 CET] <Daemon404> lol carl [17:49:47 CET] <kierank> is there a guide to making and adding fate tests [17:51:07 CET] <kierank> https://trac.ffmpeg.org/wiki/FATE/AddingATest [17:51:12 CET] <kierank> but how do I make a reference value [17:51:28 CET] <kurosu> GEN=1 ? [17:55:18 CET] <Timothy_Gu> kierank: lol at reading my wip wiki page [17:57:17 CET] <cone-139> ffmpeg 03Timothy Gu 07master:ba25936df589: vf_blend: Templatize identity function and use a better name [17:57:18 CET] <cone-139> ffmpeg 03Timothy Gu 07master:ee281b884e2d: vf_blend: Use memcpy when opacity is 0 [17:59:21 CET] <cone-139> ffmpeg 03Timothy Gu 07master:45743239738b: vf_blend: Reduce number of arguments for kernel function [18:00:21 CET] <Timothy_Gu> Gramner: is there a "magic number" for how many bytes one should process in one iteration? [18:00:41 CET] <Timothy_Gu> if not, what factors does that number depend on? [18:00:47 CET] <Gramner> not really, it depends on the circumstances [18:01:01 CET] <Timothy_Gu> like, what circumstances? [18:02:11 CET] <Gramner> can you avoid some overhead by doing more stuff at the same time, how efficient is your cpu at out-of-order executions and other µarch-specifics, etc. [18:02:33 CET] <Timothy_Gu> ok [18:02:44 CET] <cone-139> ffmpeg 03David Monro 07master:4b750104ea2b: lavf/spdifenc: Support MLP encapsulation. [18:02:48 CET] <Timothy_Gu> so basically i'll have to check and see for every circumstance? [18:02:54 CET] <Gramner> in this case for example, the unpacking and packing would be more efficient if you processed more data per iteration [18:03:01 CET] <Gramner> pretty much, yes [18:03:31 CET] <Timothy_Gu> ah [18:03:36 CET] <Timothy_Gu> thanks [18:05:23 CET] <Gramner> Timothy_Gu: another thing, it might be better to do the multiply before converting to float since you could do it with a shift and a sub that way [18:05:40 CET] <Timothy_Gu> hmm true [18:06:03 CET] <Timothy_Gu> and float mul is always slower than integer shifting/subtracting? [18:08:54 CET] <Gramner> multiply is 4-5 clocks latency, basic int logic/arith are 1 clock [18:09:56 CET] <Timothy_Gu> cool [18:12:46 CET] <cone-139> ffmpeg 03Timothy Gu 07master:a678d667816a: vf_blend: Use integers for divide mode [18:14:52 CET] <kurosu> main reason for unrolling is a more parallel execution: when the same insn is executed twice, and its result used slightly later (happens often when there's packing near the end of a loop) [18:15:15 CET] <kurosu> bonus reason: fewer end of loops checks [18:15:42 CET] <kurosu> (ie more stuff done in the loop compared to the loop logic) [18:17:45 CET] <Timothy_Gu> kurosu: ok [18:18:19 CET] <Timothy_Gu> so the cpu doesn't actually execute instr-by-instr but uses some kind of asynchronous logic [18:18:26 CET] <kurosu> usually, it's not that hard to unroll some of those loops, so I often test the 2 versions [18:18:39 CET] <kurosu> yes, the out-of-order execution stuff [18:19:07 CET] <Timothy_Gu> michaelni: you are supposed to apply "[PATCH 1/2] vf_blend: Move C dsp function mapping to separate function" first, although it needs some rebasing [18:20:08 CET] <kurosu> it's somewhat disturbed by conditional flow, but usually it can reorder a notable amount of insn (is it like a hundred, or more?) [18:20:16 CET] <Gramner> modern x86 cpus has multiple execution engines and execute multiple instructions at the same time, and it can reorder instructions if that means it can execute something instead of waiting [18:20:33 CET] <michaelni> Timothy_Gu, yep i forgot to apply that one [18:20:40 CET] <Timothy_Gu> michaelni: you could use https://github.com/TimothyGu/FFmpeg/tree/blend-checkasm [18:21:16 CET] <Timothy_Gu> Gramner: so instructions using different parts of the CPU can be executed at the same time [18:21:22 CET] <kurosu> http://www.realworldtech.com/haswell-cpu/3/ [18:21:39 CET] <Gramner> yes. also on skylake the reorder buffer has 224 entries so it shuffle around instructions quite a lot [18:22:08 CET] <Timothy_Gu> is a µop a cycle? [18:22:36 CET] <Gramner> not really [18:22:41 CET] <kurosu> nop, that's what the processor divides the insn into, if I'm not mistaken [18:23:37 CET] <Timothy_Gu> ok [18:24:59 CET] <kurosu> turtles^risc all the way down [18:26:29 CET] <Gramner> not really true either. you can't really divide modern cpus into risc or cisc anymore since everything is kind of a hybrid [18:27:15 CET] <Timothy_Gu> michaelni: crap, forgot to fix the checkasm func signature [18:40:13 CET] <Timothy_Gu> Gramner: unrolling doesn't help with a 720p sample and a 256x256 sample [18:40:59 CET] <kurosu> what are the cycle counts like? (using START/STOP_TIMER) [18:41:25 CET] <Gramner> Timothy_Gu: can you post code? [18:41:48 CET] <Timothy_Gu> one sec [18:42:27 CET] <Timothy_Gu> http://sprunge.us/WbPI?diff [18:42:40 CET] <Timothy_Gu> (incremental diff) [18:42:47 CET] <Timothy_Gu> also I haven't made the * 255 change yet [18:43:53 CET] <Gramner> you can use movq instead of 2x movd, both for loading and storing [18:44:28 CET] <Gramner> the first set of punpcklbw can be reused for both registers [18:44:51 CET] <Gramner> at the end use packssdw m0, m2 instead of doing them separately [18:44:51 CET] <jamrial> and use a single packuswb with the two registers [18:44:55 CET] <jamrial> lol [18:46:09 CET] <kurosu> can't pshuflw or shufps be used here to save some unpacking ? [18:46:55 CET] <Gramner> no, but you can use pmovzxbd with sse4.1 [18:47:42 CET] <jamrial> or pshufb wiht ssse3 [18:47:53 CET] <Gramner> ah yeah. that too [18:48:55 CET] <Timothy_Gu> how would punpcklbw unpack to dword? [18:50:02 CET] <jamrial> alongside a punpcklwd like you're already doing [18:51:08 CET] <Timothy_Gu> im kind of confused now [18:51:21 CET] <Timothy_Gu> so when i movq i'm loading 8 bytes [18:51:47 CET] <Timothy_Gu> and punpcklbw make these bytes words [18:51:54 CET] <Gramner> instead of 4x punpcklbw + 4x punpcklwd you can do 2x punpcklbw + 2x punpcklwd + 2x punpckhwd [18:51:59 CET] <Timothy_Gu> oh [18:52:01 CET] <Timothy_Gu> h [18:52:12 CET] <Timothy_Gu> yeah I forgot about those :p [19:08:13 CET] <Timothy_Gu> now i got http://sprunge.us/fOBK?diff [19:08:25 CET] <Timothy_Gu> still doesn't make it *significantly* faster [19:08:51 CET] <Timothy_Gu> i also couldn't get rid of the mova at line 36 [19:09:39 CET] <Timothy_Gu> or i could pxor m2 and m3 [19:10:51 CET] <Timothy_Gu> hmm maybe not [19:12:17 CET] <Gramner> the division is probably the bottleneck [19:12:28 CET] <Gramner> division is really slow [19:12:53 CET] <Timothy_Gu> ok well I guess [19:13:15 CET] <Timothy_Gu> I'll try the integer * 255 change [19:14:03 CET] <Gramner> do it before converting to dwords, that way you only need to do it once [19:15:22 CET] <Timothy_Gu> divps is 24%, mulps 11% [19:24:05 CET] <Timothy_Gu> Gramner: doesn't make it faster either, though divps is now 36% according to perf [19:24:14 CET] <Timothy_Gu> so yeah, it's probably divps's fault [19:25:45 CET] <kurosu> is divps really needed, or rcpps' precision enough ? [19:25:49 CET] <cone-139> ffmpeg 03Michael Niedermayer 07master:b65ea6ab4490: avfilter/vf_tinterlace: fix image alignment [19:25:50 CET] <cone-139> ffmpeg 03KO Myung-Hun 07master:22a4046d66f7: compat/os2threads: Improve pthread_cond_xxx() functions [19:25:51 CET] <cone-139> ffmpeg 03KO Myung-Hun 07master:6bf5e7d3e7d8: compat/os2threads: support the return value of joined thread [19:25:52 CET] <cone-139> ffmpeg 03KO Myung-Hun 07master:b8bc6b14a556: compat/os2threads: split long lines [19:25:53 CET] <cone-139> ffmpeg 03Mark Reid 07master:8395b6eeaa27: libavcodec/dnxhd_parser: add parser and probe support raw 444 and dnxhr formats [19:26:00 CET] <Gramner> one round of rcpps is not enough, no [19:26:17 CET] <Gramner> you'd need one interation of newton-raphson as well [19:26:41 CET] <Gramner> which probably makes it a wash [19:27:45 CET] <Gramner> you also need to add 1/256 at the end too because we truncate and rcpps might give a result that's too low [19:28:09 CET] <Timothy_Gu> now I have no idea what you guys are talking about :) [19:28:27 CET] <Gramner> fancy floating point magic, basically [19:28:28 CET] <kurosu> rcpps is an approximation of the reciprocal of the source operand [19:29:01 CET] <kurosu> I'd thought the input might allow this, but I haven't even really looked at how it's used [19:29:49 CET] <Timothy_Gu> kurosu: it has to be bit-exact [19:29:59 CET] <Timothy_Gu> so reciprocal probably doesn't have enough precision [19:31:05 CET] <Gramner> you can get it bit-exact, but then you need one iteration of newton-raphson to refine the reciprocal output and add a small positive bias at the end [19:31:06 CET] <kurosu> yeah, but the output was byte-sized, so I thought there would still be enough precision [19:31:21 CET] <jamrial> Timothy_Gu: is it bitexact as is between x86_64 (sse math) and x86_32 (x87 math) with gcc? [19:31:38 CET] <Timothy_Gu> let me check [19:32:08 CET] <jamrial> i guess that after "vf_blend: Use integers for divide mode" it should be [19:32:59 CET] <Gramner> even before that it should be, since normal float ops has 24 bits of precision [19:33:51 CET] <Timothy_Gu> damn, avdev doesn't have multilib [19:34:23 CET] <kierank> i can install it [19:34:46 CET] <Timothy_Gu> ok that'd be great [19:41:24 CET] <BBB> michaelni: wrong ticket [19:41:29 CET] <BBB> michaelni: he said 5215, not 5125 [19:41:46 CET] <michaelni> ohh ooops [19:41:59 CET] <BBB> no problem :-p I mea, fix whatever issue you want, alls great [19:42:05 CET] <BBB> but its just not the issue he pointed out ;) [19:42:34 CET] <BBB> (theyre cfhd crashes) [19:47:08 CET] <cone-139> ffmpeg 03Timothy Gu 07master:8c56a4a1ed7d: vf_blend: Move C dsp function mapping to separate function [19:47:09 CET] <cone-139> ffmpeg 03Timothy Gu 07master:a953a2991e28: checkasm: Add vf_blend tests [19:48:58 CET] <cone-139> ffmpeg 03Timothy Gu 07master:ebf648d49044: checkasm/vf_blend: Decrease iteration count [19:55:47 CET] <jamrial> Timothy_Gu: couldn't you have waited for durandal_1707's approval before pushing the checkasm test? [19:55:56 CET] <kierank> michaelni: so what do I do about this rgb_to_a magic that's missing? [19:55:57 CET] <Timothy_Gu> jamrial: he did approve [19:56:20 CET] <Timothy_Gu> or wait his mail isn't on the ML [19:56:24 CET] <jamrial> where? [19:57:26 CET] <Timothy_Gu> http://sprunge.us/gZSC [19:57:53 CET] <jamrial> odd, the reply-to field in your email had ffmpeg-devel's address [19:59:31 CET] <Timothy_Gu> /shrug [20:01:36 CET] <michaelni> kierank, see planar_rgb12XX_to_y vs. planar_rgb_to_y and do the same change to planar_rgb_to_a, should be easy to see if that is correct or off in some way if you hava a test case with some alpha [20:02:17 CET] <kierank> I don't that's the probelm [20:02:40 CET] <kierank> where does the shift of 6 come from in planar_rgb_to_a [20:02:55 CET] <kierank> sr [20:03:00 CET] <kierank> surely that is bit-depth dependent or something [20:05:33 CET] <michaelni> yes, i think it should be 2 for 12bit input [20:06:56 CET] <kierank> where does 14 come from? [20:07:00 CET] <kierank> is it a magic number? [20:07:17 CET] <Timothy_Gu> kurosu: the HAVE_MMX_INLINE macro is used to prevent asm being built that are not actually used [20:08:03 CET] <nevcairiel> but inline is the wrong macro for yasm code, isnt it [20:08:11 CET] <kierank> michaelni: and for 16 bit you shift right or what? [20:08:19 CET] <kierank> all confusing and undocumented [20:08:33 CET] <michaelni> for 16 there should be no shift right as that would loose precission [20:10:02 CET] <michaelni> its a bit documented in doc/swscale.txt (the precission between h and v scalers) but this possibly predates later improvments that allow higher precission [20:10:47 CET] <michaelni> also the text predates the changes done in last years GSoC [20:11:32 CET] <cone-139> ffmpeg 03Timothy Gu 07master:bcc223523e68: x86/vc1dsp: Port vc1_*_hor_16b_shift2 to NASM format [20:15:46 CET] <cone-139> ffmpeg 03Marton Balint 07master:ae51f9bd6c18: avutil/parseutils: remove 2112 date from fate test [20:27:24 CET] <kurosu> Timothy_Gu, I see the point now, indeed [20:33:12 CET] <kierank> michaelni: hmm strange crash [20:39:57 CET] <kierank> is it possible to mix frame threading and use multiple threads to decode within a single frame? [20:45:16 CET] <kurosu> kierank, no [20:45:22 CET] <kurosu> (afaik) [20:45:32 CET] <kierank> even with avctx->execute? [20:45:47 CET] <kurosu> maybe, I don't know [20:45:59 CET] <kurosu> I know openhevc has something like this, though [20:46:50 CET] <kurosu> but that they introduced a lot of changes to threading [20:48:57 CET] <kurosu> Timothy_Gu / nevcairiel: I understand Timothy_Gu's point now: if inline asm isn't activated then the callers aren't compiled, so what you build will end up being stripped anyway [20:53:52 CET] <nevcairiel> kurosu: i see [20:58:15 CET] <kierank> michaelni: are you joking? [20:59:14 CET] <michaelni> kierank, about marking cfhd as experimental ? [20:59:23 CET] <kierank> Yes [21:01:36 CET] <michaelni> its a suggestion, i dont have the time to fix the bugs before the release. if you feel its minor and can be released as is then lets drop the patch [21:03:23 CET] <kierank> It's no broken than any other RE'd codec [21:09:06 CET] <mateo`> speaking of the 2.9 release, when is there a release date ? [21:09:30 CET] <jamrial> it will probably be called 3.0 instead [21:20:40 CET] <michaelni> people wanted 3.0 when i asked IIRC, so 3.0, when well ASAP [21:22:35 CET] <mateo`> i'm asking because I'm thinking whether or not it would be a good to include basic mediacodec support in this release (only h264 / no hwaccel), but it might a bit late for that [21:23:02 CET] <jamrial> yeah, leave that for the next release [21:33:42 CET] <cone-139> ffmpeg 03Michael Niedermayer 07master:dcb6d5b831b3: avformat/genh: Mark coef_splitted as av_unused [21:33:43 CET] <cone-139> ffmpeg 03Michael Niedermayer 07master:e5655a32bc74: avcodec/h264_cabac: Check decode_cabac_mb_mvd() for failure [21:33:44 CET] <cone-139> ffmpeg 03Michael Niedermayer 07master:8352f5c80758: doc/protocols: document protocol_whitelist [21:33:45 CET] <cone-139> ffmpeg 03Michael Niedermayer 07master:0eb4092c1bf4: avutil/imgutils: remove special case for aligning the palette [21:33:46 CET] <cone-139> ffmpeg 03Michael Niedermayer 07master:b4018544fbbc: avformat/img2enc: remove unused variable [21:38:44 CET] <michaelni> rcombs, carl says "The one-liner that changes dts calculation in mov.c fixes neither of the tickets." in 0214 21:34 Carl Eugen Hoyo ( 1) [21:40:30 CET] <kierank> michaelni: turn off frame threading if you want [21:40:49 CET] <kierank> the bugs are all resolution changes with frame threading which end up going wrong [21:40:53 CET] <kierank> because frame threads clobbers data [21:42:45 CET] <durandal_1707> fosdem videos are available, yaj [21:43:35 CET] <michaelni> kierank, ok, will disabled frame-mt for cfhd on the release/3.0 branch, i think we can leave it enabled on master [21:43:48 CET] <kierank> is there a proper way to synchronise resolution changes? [21:44:02 CET] <kierank> because one thread clobbers the resolution of another thread [21:45:15 CET] <rcombs> michaelni: yeah, it specifically fixes the issue from the ML, not the tickets [21:45:44 CET] <michaelni> rcombs, ok, i thoght it fixes all 3 :( [21:45:54 CET] <rcombs> nope, I still need to poke at the others more [21:46:24 CET] <michaelni> ok, please do, even if it doesnt make it into 3.0 ill backport it so its in 3.0.1 [21:46:57 CET] <michaelni> also dont hesitate to apply that one line dts fix if you are sure its correct [21:47:07 CET] <kierank> michaelni: is this true still? https://trac.ffmpeg.org/ticket/1312 [21:47:49 CET] <kierank> i.e resolution changes not allowed for frame threads? [21:48:11 CET] <michaelni> resolution changes should work for frame threads but it can be annoying implementation wise [21:48:42 CET] <kierank> what do you have to do [21:49:27 CET] <kierank> can we document this somewhere [21:51:44 CET] <michaelni> if each frame and decoder is fully independant then it should just work i think. otherwise update_thread_context / ff_thread_finish_setup can be used to sync when the next thread starts and the previous finished doing its setup [21:51:56 CET] <kierank> each frame is independent yes [21:52:01 CET] <kierank> but I get data clobbered [21:52:28 CET] <kierank> printf shows that I allocate allocating 720x352 but my s->alloc_width and alloc_height variables are 720x480 [21:52:32 CET] <kierank> which causes all the crashes [21:53:16 CET] <kurosu> kierank, maybe also ask BBB what's needed, because he had to deal with this in ffvp9? [21:58:40 CET] <michaelni> kierank are all pointers in each thread independant or does something end up being shared? also you might have to implement init_thread_copy() [21:58:57 CET] <BBB> ff_set_dimensions [21:59:03 CET] <BBB> youre not using ff_set_dimensions [21:59:07 CET] <kierank> I do [21:59:13 CET] <BBB> hm.... [21:59:18 CET] <BBB> well that was the issue in ffvp9 [21:59:31 CET] <kierank> but I store the allocated width and height elsewhere [21:59:37 CET] <kierank> in my context [21:59:39 CET] <kierank> and that gets clobbered [22:00:50 CET] <BBB> durandal_1707: anything interesting about multimedia projects? [22:01:41 CET] <durandal_1707> I'm watching daala one [22:02:34 CET] <BBB> kierank: is it possible the decoding per-tag makes it go crazy? [22:02:55 CET] <BBB> e.g. you could have a tag that makes you do get_buffer, be followed by a tag that changes w/h, then a tag that makes you update_size [22:03:50 CET] <kierank> yes but it should be handled [22:10:12 CET] <BBB> so, the frame-mt path copies all w/h variables from thread to thread [22:10:29 CET] <BBB> is it possible the ones inside your priv_data and the (copied) generic ones got out of sycn and you need to resync them? [22:10:41 CET] <BBB> like, is it possible some frames do not have a w/h tag? [22:10:44 CET] <BBB> or do each frame have them? [22:12:23 CET] <kierank> the bug isn't that the frame lacks a w/h tag, the bug is that the stored value for the allocated width and height is wrong [22:13:09 CET] <BBB> right, Im just trying to understand from the source how it could happen [22:13:09 CET] <kierank> the code reads the written w/h, compares it with the allocated and frees and alloc's if necessary [22:13:23 CET] <BBB> right, so theres the bug then, no? [22:13:30 CET] <kierank> https://www.irccloud.com/pastebin/hlWb8fet/ [22:13:48 CET] <BBB> if you have 2 threads, a reads 1x1 and allocs, then b reads 2x2 and reallocs, b copies that back to a [22:13:57 CET] <BBB> now internal state of a is 1x1 but external state is 2x2 [22:14:17 CET] <kierank> yes, but how do you deal with that? [22:14:45 CET] <BBB> if internal state size != external state size, call ff_set_dimensions [22:14:46 CET] <BBB> thats all [22:14:54 CET] <BBB> (no realloc necessary of internal buffers) [22:15:17 CET] <kierank> internal state = s->avctx->width? [22:15:27 CET] <BBB> internal state is priv_data->a_width/a_height [22:15:32 CET] <BBB> external state is AVCodecContext->* [22:16:13 CET] <BBB> (not that that matters :-p) [22:17:26 CET] <kierank> hmm ok let's try that [22:21:37 CET] <kierank> I get [avi @ 0x7f25500008c0] Could not find codec parameters for stream 0 (Video: cfhd (CFHD / 0x44484643), yuv422p10le): unspecified size [22:21:42 CET] <kierank> which I don't understand [22:22:58 CET] <BBB> maybe FW the bug to me, Ill look monday [22:23:06 CET] <BBB> I think I have kind of a clue whats going on maybe [22:23:17 CET] <BBB> but Im taking a break today, I work hard enough on weekdays :-p [22:24:35 CET] <kierank> I emailed it to you [22:24:37 CET] <kierank> thanks [22:28:16 CET] <cone-139> ffmpeg 03Michael Niedermayer 07master:bb9f7bf1a21d: Changelog/APIChanges Put 3.0 release marker [22:29:24 CET] <atomnuker> ah, damn it, I should have made a changelog entry for the Dirac stuff [22:29:31 CET] <atomnuker> too late now? [22:30:18 CET] <atomnuker> michaelni: ^^? [22:30:47 CET] <michaelni> atomnuker, not too late, you can still do it [22:31:07 CET] <michaelni> i intend to make a branch first then wait a few hours and then make the release [22:31:42 CET] <BBB> I really dont like that experimental tag [22:32:03 CET] <BBB> well anyway [22:32:06 CET] <BBB> Ill look tomorrow [22:32:19 CET] <atomnuker> michaelni: alright, thanks, I'll append the entries at the bottom [22:34:58 CET] <Timothy_Gu> atomnuker: you should add it where the changes are made [22:35:03 CET] <Timothy_Gu> just to preserve consistency [22:36:37 CET] <atomnuker> well, afaik the CFHD decoder was merged after the new DCA decoder, but the changelog lists CFHD first [22:38:05 CET] <atomnuker> I can't see any chonological ordering tbh [22:38:44 CET] <atomnuker> nnedi was merged after streamselect but the changelog is again showing it the other way around [22:39:05 CET] <durandal_1707> huh? [22:39:32 CET] <atomnuker> the changelog entreis are all seemingly out of order [22:39:50 CET] <atomnuker> s/entreis/entries [22:40:28 CET] <durandal_1707> the entries are in commit order [22:40:48 CET] <durandal_1707> not in author order [22:41:04 CET] <atomnuker> well, no, they're not [22:41:48 CET] <atomnuker> CFHD was added a week after streamselect, but CFHD is first in the changelog [22:44:55 CET] <durandal_1707> you are looking at author date, aren't you? [22:45:25 CET] <atomnuker> I'm looking at commit date [22:51:03 CET] <atomnuker> so do I add the VC-2 entries at the bottom or somewhere else? [22:55:09 CET] <atomnuker> https://0x0.st/XGJ.diff <<- unless this doesn't look right I'll commit it in like half an hour [22:56:39 CET] <jamrial> atomnuker: yeah, it's ok [23:06:46 CET] <cone-139> ffmpeg 03Michael Niedermayer 07release/3.0:HEAD: Changelog/APIChanges Put 3.0 release marker [23:10:45 CET] <cone-139> ffmpeg 03Rostislav Pehlivanov 07master:fbc96c50d72f: Changelog: add entries for the SMPTE VC-2 decoder and encoder [23:12:34 CET] <atomnuker> michaelni: want me to push that commit to release/3.0? [23:12:47 CET] <michaelni> atomnuker, yes, sure [23:13:18 CET] <cone-139> ffmpeg 03Rostislav Pehlivanov 07release/3.0:380980e0d2b3: Changelog: add entries for the SMPTE VC-2 decoder and encoder [00:00:00 CET] --- Mon Feb 15 2016

1 0

ffmpeg.log.20160214
by burek 15 Feb '16

15 Feb '16

[00:01:37 CET] <rocktop> furq: yes this the problem I need to put them in same rosolution and use an image as background for the small one [00:01:39 CET] <J_Darnley> what about: ffmpeg -i concat.txt -vf scale=1280x728 OUTPUT [00:02:07 CET] <J_Darnley> and read http://ffmpeg.org/ffmpeg-formats.html#concat-1 [00:02:38 CET] <J_Darnley> actually that might not work either [00:02:43 CET] <rocktop> J_Darnley: one moment I will try your command [00:02:53 CET] <J_Darnley> TOO MANU FUCKING CONCAT OPTIONS [00:03:47 CET] <rocktop> in the file concat.txt I shoud have for example : file 'C:\inetpub\ati.mp4' [00:04:02 CET] <J_Darnley> Yes I think so [00:04:12 CET] <J_Darnley> And then the next file on the next line [00:04:45 CET] <relaxed> the smaller video has a different aspect ratio, so take that into account [00:05:12 CET] <J_Darnley> Lets get it working forst shall we [00:05:16 CET] <J_Darnley> *first [00:10:32 CET] <rocktop> J_Darnley: ffmpeg -i concat.txt maybe consider the file as input video !!? [00:10:45 CET] <J_Darnley> ? [00:10:46 CET] <rocktop> the generated video show the content of the file [00:10:53 CET] <J_Darnley> Yeah [00:11:01 CET] <J_Darnley> That's what its supposed to do [00:12:08 CET] <rocktop> J_Darnley: when I play the file I see the the text I have concat.tx text instead of concating the videos [00:12:26 CET] <J_Darnley> ? [00:12:50 CET] <J_Darnley> beat me to it [00:12:56 CET] <furq> you forgot -f concat [00:13:06 CET] Action: relaxed holsters [00:14:03 CET] <furq> also if you want to use an image as background for the smaller video then this isn't going to work [00:23:59 CET] <rocktop> J_Darnley: look at this printscreen http://prntscr.com/a2xkxo [00:24:11 CET] <rocktop> furq: ^^ [00:24:33 CET] <J_Darnley> input format "tty"!? [00:24:37 CET] <J_Darnley> WTF is that? [00:24:42 CET] <rocktop> furq: oh yes should be -f not -i let me check [00:25:14 CET] <J_Darnley> No it should be -f concat -i concat.txt [00:25:17 CET] <relaxed> https://trac.ffmpeg.org/wiki/Concatenate [00:25:43 CET] <rocktop> J_Darnley: ok I will try now [00:28:32 CET] <J_Darnley> FYI: to copy text from Windows' cmd.exe first right click on the window and choose mark, then make your selection, press enter, and the text will be on the clip board. [00:29:36 CET] <rocktop> J_Darnley: it take the long time when it is reaching "Input stream #0:0 frame changed from size:1280x720 fmt:yuv420p to size:180x320 fmt:yuv420p4x" [00:32:42 CET] <rocktop> J_Darnley: the method you gave me doesn't work [00:33:28 CET] <J_Darnley> Then I suggest you go read relaxed's link [00:33:53 CET] <J_Darnley> And I would remind you that "doesn't work" is not an error message. [00:35:26 CET] <rocktop> J_Darnley: no it is freez in some point and I always finish the operation with CTRL + C [00:35:35 CET] <furq> brb changing all the error strings in this library to "it doesn't work" to annoy J_Darnley [00:35:50 CET] <J_Darnley> That's a little better [00:37:29 CET] <rocktop> furq: I am sorry but there is no error in std output [00:38:44 CET] <furq> this method won't do what you want anyway [00:39:21 CET] <furq> if you want the smaller video to be the correct size on top of a static image then you'll need to create a 1280x720 image and use the overlay filter with that and the video [00:39:38 CET] <furq> it's probably simpler to do that in a separate pass and then concat the two videos [00:40:12 CET] <furq> doubtless there's some filter_complex wizardry which will do it in one go but i don't have a long enough beard to know it [00:40:35 CET] <rocktop> furq: this what I need exactly I need to have the image with same as the first video foramt to be the background of the small video size [00:41:16 CET] <furq> well you need to create that yourself [00:41:33 CET] <furq> then use https://ffmpeg.org/ffmpeg-filters.html#overlay-1 [00:41:40 CET] <furq> then concat that video with the intro video [00:42:05 CET] <rocktop> furq: yes I will the problem I will have to work with more than one ffmpeg command is it possible to make all work in single command ? [00:42:16 CET] <furq> maybe but i don't know what that command is [00:53:08 CET] <fling> How to merge a thumbnail into a file? [04:20:24 CET] <johnnny22-afk> when encoding 4K content that has the whole background moving, it often studders on the playback because of crappy playback hardware. But is there a way to improve this by changing the way the video is encoded ? [04:21:39 CET] <J_Darnley> What encoder are you using? [04:22:52 CET] <johnnny22-afk> for now ffmpeg!? [04:23:14 CET] <J_Darnley> Shall I assume you're using mpeg1 then? [04:23:20 CET] <johnnny22-afk> haha oh [04:23:41 CET] <johnnny22-afk> right now, simple h264 video in mp4 [04:23:58 CET] <J_Darnley> Try x264's fastdecode tuning. [04:24:23 CET] <johnnny22-afk> humm, using mplayer, not sure how i'd go about doing that. :o/ [04:24:29 CET] Action: johnnny22-afk googles a bit [04:24:33 CET] <J_Darnley> player? [04:24:45 CET] <J_Darnley> I thought you were asking about encoding [04:25:10 CET] <J_Darnley> Do I need to say this again? [04:25:14 CET] <johnnny22-afk> well, i'm wondering if there's some encoding codecs/options/formats that would help resolve what I'm seeing when playing it. [04:25:16 CET] <J_Darnley> x264 is not a decoder. [04:26:20 CET] <johnnny22-afk> basically, help solve jittering cause by the player (i'm aware), but maybe the codec used or some encoder's options would help the cpu+gpu of the decoder ? [04:27:41 CET] <J_Darnley> Yes it is possible to make video streams that are easier to decode. [04:28:03 CET] <johnnny22-afk> i'm assuming mpeg2 is easier than h264 ? [04:28:32 CET] <J_Darnley> Using an option of x264's is a simple way of doing that. [04:28:47 CET] <J_Darnley> Using a different video format is another. [04:29:01 CET] <johnnny22-afk> how would i do that for x264 ? [04:29:14 CET] <J_Darnley> What did I say just a moment ago? [04:29:20 CET] <J_Darnley> "Try x264's fastdecode tuning." [04:29:31 CET] <johnnny22-afk> right right [04:29:32 CET] <J_Darnley> -tune fastdecode [04:30:03 CET] <johnnny22-afk> those this have an impact on the preset or are those unrelated ? [04:30:21 CET] <J_Darnley> preset mostly controls speed [04:30:32 CET] <J_Darnley> Which is why they are named how they are named. [04:30:41 CET] <J_Darnley> encoding speed that is. [04:31:33 CET] <johnnny22-afk> and the tune is how the video gets encoded, (looking at the options of -tune ) [04:31:45 CET] <johnnny22-afk> for it to encode based on the type of content [04:31:48 CET] <J_Darnley> Sort of [04:31:51 CET] <J_Darnley> yes [04:32:09 CET] <J_Darnley> It is a dial for the masses to turn [04:32:37 CET] <johnnny22-afk> zerolatency would give even better decode speed than fastdecode or ? [04:32:43 CET] <J_Darnley> No. [04:33:08 CET] <J_Darnley> zerolatency controls the delay between putting a frame into the encoder and getting one out. [04:33:37 CET] <johnnny22-afk> aaah, so it'll drop frames if it can't hold i guess. [04:33:42 CET] <J_Darnley> No [04:34:19 CET] <johnnny22-afk> neways, i'll give it a try :) [04:34:26 CET] <J_Darnley> Ignore that option [04:34:31 CET] <johnnny22-afk> will do [04:35:35 CET] <johnnny22-afk> also, if I use a preset of ultrafast vs veryslow, wouldn't it affect the decoding performances too ? [04:36:02 CET] <J_Darnley> Only as a side effect. [04:37:02 CET] <J_Darnley> Ultrafast and fastdecode happen to use the same fast feature [04:37:45 CET] <J_Darnley> but ultrafast will also use things that make encoding quick but have much less effect on decoding. [04:41:05 CET] <antiPoP> hi, how can i install ffmpeg in 7.2? [04:41:21 CET] <J_Darnley> ./configure && make [04:41:31 CET] <johnnny22-afk> thanks for the info! [04:41:58 CET] <johnnny22-afk> so, fastdecode kinda generates a bigger file than veryslow or medium, (closer to the size of ultrafast) [04:42:44 CET] <J_Darnley> Yes. [04:43:11 CET] <J_Darnley> Ultrafast and fastdecode both use cavlc insead of cabac. [04:43:31 CET] <J_Darnley> it is quicker to process but results in more bits [04:44:11 CET] <J_Darnley> At a high quality or bitrate this can be the largest effect on speed [04:44:34 CET] <J_Darnley> I wonder if I can find an old, pretty graph [04:45:47 CET] <furq> using cavlc for 4k sounds like a bad time [04:46:07 CET] <J_Darnley> aw no speed graph [04:46:21 CET] <furq> i have an encoding speed graph if that's any use [04:46:25 CET] <furq> although it's not labelled [04:49:00 CET] <J_Darnley> heh, the good old days: http://akuvian.org/src/x264/entropy.png [04:49:45 CET] <furq> is there a graph which shows the difference for things you might actually want to watch [04:50:21 CET] <J_Darnley> It'd be easy enough to create [04:52:59 CET] <J_Darnley> Damn. 5am [04:53:05 CET] <J_Darnley> I'm going to sleep. [05:05:37 CET] <johnnny22-afk> furq: what do you mean by a bad time (using cavlc) ? [06:19:03 CET] <tombbraindamage> I think I found a bug with the way ffmpeg handles hardsubs from mkv sources. [06:19:26 CET] <tombbraindamage> Can someone replicate it for me? http://pastebin.com/eL8kMX5P [06:33:21 CET] <relaxed> tombbraindamage: don't quote the name in the filter [06:38:39 CET] <tombbraindamage> quoted or not it still fails [08:13:27 CET] <Demon_Fox> How do I get yuv4mpeg2 output? [08:18:02 CET] <relaxed> Demon_Fox: -f yuv4mpegpipe output.y4m [08:18:16 CET] <Demon_Fox> thanks [08:23:45 CET] <Demon_Fox> Requested output format 'yuv4mpeg2pipe' is not a suitable output format [08:25:34 CET] <relaxed> There's no "2" in it. What are you trying to do? Do you want yuv4mpeg or mpeg2 video? [08:25:56 CET] <Demon_Fox> oops [08:26:19 CET] <Demon_Fox> Thanks [08:28:49 CET] <Demon_Fox> How do I get progressive interlacing? [08:30:37 CET] <Demon_Fox> and avoid subsampling [10:17:23 CET] <dystopia> hello all [10:17:34 CET] <dystopia> is there anyway to set a proxy for ffmpeg to use [10:22:29 CET] <fritsch> it takes the one you export [10:24:19 CET] <dystopia> ffmpeg -i playlist.m3u8 -vcodec copy download.mp4 [10:24:30 CET] <dystopia> how could i add my socks proxy to this line? [10:34:16 CET] <BtbN> I'm only aware of the http protocol supporting http proxies. So: You don't. [10:34:58 CET] <dystopia> ok [10:35:16 CET] <dystopia> :( [10:38:18 CET] <jaylee1> Hello, I want to make video burn subtitle which file extension is smi, But ffmpeg does not support .smi file for encoding, How can I burn .smi file to video on Mac? [10:41:10 CET] <jaylee1> Now, I convert .smi to .srt using ffmpeg After that I burn subtitle, But i want to burn .smi file directly [17:26:26 CET] <xace> is it possible to setup ffmpeg to stream my sound to my other computer in the same LAN? My goal is to have the audio playing on my laptop be streamed to my desktop which is connected to the stereo. [17:34:03 CET] <furq> xace: you can do that with pulse [17:34:07 CET] <furq> assuming you're on *nix [17:36:38 CET] <xace> furq: the laptop is using windows. and i've already got ffmpeg i figured ffmpeg would have a simple method for this [17:36:55 CET] <xace> like if ffmpeg can use netcast or something [17:39:37 CET] <c_14> xace: I'm not sure if ffmpeg's input devices on windows support grabbing playing audio. [17:40:08 CET] <xace> well i've set the output audio to act as the microphone, so ffmpeg is able to catch it [17:44:43 CET] <c_14> Then it should work, something like ffmpeg -f dshow -i device -f rtp rtp://[remote_ip]:[port] [17:46:39 CET] <xace> c_14: i assume that's the client, how do I receive it on the server side? [17:46:52 CET] <c_14> any decent media player should be able to play it [17:47:46 CET] <xace> c_14: so remoteip could be 192.168.0.24 and port could be 12345 and then I can play it with vlc rtp://192.168.0.24:1234 ? [17:48:01 CET] <c_14> ye [17:49:02 CET] <furq> xace: if the desktop is running pulse you can just create an rtp sink on there and it should work automagically [17:49:22 CET] <furq> emphasis on should because i'm just reading this from the docs [17:49:44 CET] <xace> cool [17:49:46 CET] <furq> https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Net… [17:49:55 CET] <furq> ignore the sender side bit [18:26:22 CET] <Hfuy> Hello. [18:26:59 CET] <Hfuy> I have an uncompressed AVI which has an alpha channel that I'd like to convert to ProRes 4444 quicktime, maintaining the alpha channel. [18:27:14 CET] <Hfuy> Googling around suggests that this may not be possible, or at least only became possible recently. Can anyone advise? [18:48:39 CET] <Hfuy> Oh well, answered my own question. Seems to work fine from bgra .avi to yuva444p10le ProRes .mov [20:02:49 CET] <anynamereally> Hello. Is it possible to operate on video frames (mpegts) without decoding them? I'm trying to overlay without decoding and encoding [20:03:23 CET] <DeHackEd> you can't modify the video without decoding them. you can only copy the video from source to destination [20:16:21 CET] <anynamereally> I'm trying to do something like http://rdist.root.org/2011/09/13/the-magic-inside-bunnies-new-netv/ [21:37:13 CET] <Guiri> Hey everyone. I use a combination of scale, pad, setsar, concat, and map to stream multiple movies at the same resolution to an RTMP server. I really want to play around with ffserver, but I'm a bit confused about where these options go in the configuration. [21:38:05 CET] <JEEB> my condolences [21:38:37 CET] <JEEB> ffserver is something someone made ages ago and the knowledge of it is very limited [21:38:56 CET] <JEEB> if you can get away with what ffmpeg does, I recommend you stay there [21:39:48 CET] <Guiri> k. [21:51:24 CET] <furq> someone should really put "please don't use ffserver" in the topic [21:51:32 CET] <furq> it would save a lot of time [00:00:00 CET] --- Mon Feb 15 2016

1 0