Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

November 2016

1 participants
60 discussions

ffmpeg-devel.log.20161114
by burek 15 Nov '16

15 Nov '16

[00:09:45 CET] <Chloe[m]> is there a better way of encoding data using huffman coding than: count the frequency of sequences, sort, make a binary tree, then encode data? [00:10:36 CET] <Chloe[m]> maybe a way to incrementally build the tree while counting? [00:12:41 CET] <jya> DHE: big bunny will do.. thanks for pointing that one out [00:15:19 CET] <atomnuker> Chloe[m]: better? as in faster? [00:16:13 CET] <kierank> Chloe[m]: arithmetic coding [00:16:27 CET] <kierank> oh you mean encoding faster with huffman [00:16:29 CET] <kierank> ignore me [00:17:18 CET] <Chloe[m]> atomnuker: yeah [00:20:12 CET] <atomnuker> hardcode the huffman table with whatever sequence occurs the most often? [00:30:16 CET] <Chloe[m]> I was wondering if the method I described is the only way to do it without cheating :P [00:31:55 CET] <iive> Chloe[m]: cavlc ? [00:33:43 CET] <cone-642> ffmpeg 03Carl Eugen Hoyos 07master:b1367f7e5e67: lavc/dpx: Support GRAY12 colourspace. [00:34:44 CET] <Chloe[m]> iive: was just wondering about huffman, haven't started looking at anything else yet [00:35:19 CET] <iive> what you ask sounds like dynamic huffman, aka rebuilding the tree after each symbol encoded. [00:35:51 CET] <iive> or rather, just moving a branch. [01:47:21 CET] <cone-642> ffmpeg 03Simon Thelen 07master:cd5da01daab7: doc/ffmpeg: add documentation for the disposition option [02:14:53 CET] <cone-642> ffmpeg 03Kyle Swanson 07master:83b6b434fffc: lavfi/ebur128: use ff_ prefix [02:38:11 CET] <cone-642> ffmpeg 03Dmitry Kalinkin 07master:dc23e359ef70: lavc/audiotoolboxdec: fix OSX SDK detection [03:35:10 CET] <jamrial_> ubitux: your fate clients haven't run in almost two days [08:45:25 CET] <cone-856> ffmpeg 03Rodger Combs 07master:f8e3ebde56e8: lavf/mux: don't warn about missing timestamps on attached pictures [10:06:16 CET] <cone-856> ffmpeg 03Diego Biurrun 07master:7c55fac7dfa8: fate: Add test for webp [10:06:17 CET] <cone-856> ffmpeg 03Luca Barbato 07master:fe6e5cbea7db: ffv1: Remove version 2 and mark version 3 as non-experimental [10:06:18 CET] <cone-856> ffmpeg 03Luca Barbato 07master:3c08b7bc761b: ffv1: Report additional bitstream information in verbose mode [10:06:19 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:8ef6ba69c7f2: Merge commit '7c55fac7dfa8bad9644dea5d03309da30be69563' [10:06:20 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:5a45f4d2b74b: Merge commit 'fe6e5cbea7dbd5d2c67d79b5570e26debb70e95b' [10:06:21 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:a81b9c60125f: Merge commit '3c08b7bc761b6411f55db68189721638dde2c46a' [10:15:30 CET] <cone-856> ffmpeg 03Diego Biurrun 07master:8c929037ec75: build: Add a new component for H.264 parsing code [10:15:31 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:575e8d11f1eb: Merge commit '8c929037ec75fbe9f367e0a31ee34839e92de481' [10:29:28 CET] <cone-856> ffmpeg 03Carl Eugen Hoyos 07master:3f1b5ca22ec3: lavu/pixfmt: Add GRAY10 [10:33:54 CET] <JEEB> heh,/28 [10:35:46 CET] <cone-856> ffmpeg 03Carl Eugen Hoyos 07master:b5177c7051d1: lsws: Add GRAY10 conversion. [10:38:08 CET] <cone-856> ffmpeg 03Carl Eugen Hoyos 07master:0674d1938ef3: lavc/hevc_ps: Use correct pix_fmt for 10bit 4:0:0. [10:44:39 CET] <cone-856> ffmpeg 03Diego Biurrun 07master:fe27792fd779: build: Move ff_mpeg12_frame_rate_tab to a separate file [10:44:40 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:9b4cc0f35c81: Merge commit 'fe27792fd779ac4cdd5e57be5f6f488483c307b2' [10:51:12 CET] <cone-856> ffmpeg 03Martin Storsjö 07master:67cb2c0f73ec: checkasm: hevc: Iterate over features first, then over bitdepths [10:51:13 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:cd70ffaac8b7: Merge commit '67cb2c0f73ec08bdcecd675c1ffe25c3a5b26ef2' [11:33:05 CET] <cone-856> ffmpeg 03Diego Biurrun 07master:e72d6fa08a3c: build: Move MP2 muxer declaration away from MP3 muxer code [11:33:06 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:a0bc6b51d4f6: Merge commit 'e72d6fa08a3c1876109149401753a8d2c736d418' [12:02:41 CET] <cone-856> ffmpeg 03Diego Biurrun 07master:326d9116936a: build: Drop unnecessary libavcodec <-> libavformat object dependencies [12:02:42 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:444e65299ba5: Merge commit '326d9116936ab61d13ac4142b49c7337daf7c4c0' [12:16:19 CET] <cone-856> ffmpeg 03Vittorio Giovara 07master:eeb6849cedac: rle: K&R formatting cosmetics [12:16:20 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:25004c7e6eaa: Merge commit 'eeb6849cedac099d41feb482da581f4059c63ca7' [12:22:43 CET] <cone-856> ffmpeg 03Vittorio Giovara 07master:d8f3b0fb5846: targaenc: Move size check to initialization function [12:22:44 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:bbd0ebfd8357: Merge commit 'd8f3b0fb584677d4882e3a2d7c28f8b15c7319f5' [12:35:19 CET] <cone-856> ffmpeg 03Vittorio Giovara 07master:9f732e4c9962: tiffenc: Check av_pix_fmt_desc_get() return value [12:35:20 CET] <cone-856> ffmpeg 03Vittorio Giovara 07master:6c445990e641: tiffenc: Check zlib support for deflate option during initialization [12:35:21 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:bebab21176c1: Merge commit '9f732e4c996243c1e57c2bbbec6c8b94c37a7a22' [12:35:22 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:985bc8b49683: Merge commit '6c445990e64124ad64c79423dfd3764520648c89' [12:42:00 CET] <cone-856> ffmpeg 03Vittorio Giovara 07master:029cf99c5166: mov: Save number of stsd elements after stream extradata allocation [12:42:01 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:d8ffdefbdce1: Merge commit '029cf99c5166b36f33381cd8ebfa5f1f1f463d1f' [12:42:13 CET] <nevcairiel> that concludes the month of june. only a "few" more to go [13:33:50 CET] <cone-856> ffmpeg 03Carl Eugen Hoyos 07master:9648ce2a1895: lavf/Makefile: Fix rule for the data muxer. [14:04:21 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:be3e807c8fad: oggparseopus: export pre-skip [14:04:22 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:06136275e59c: Merge commit 'be3e807c8fad1f82766c083073e44396799f155b' [14:25:01 CET] <ElAngelo> hi [14:25:11 CET] <ElAngelo> if i would file a bug with a demo video [14:25:27 CET] <JEEB> that's usually called a sample [14:25:36 CET] <ElAngelo> are there any licenses or legalities on that sample? [14:25:53 CET] <JEEB> depends on a lot of things :P [14:26:22 CET] <ElAngelo> quoting my client: And regarding sharing the file to ffmpeg team, they mentioned that they are not familiar with this organization and enquired is there assurance that these would not be misused? [14:28:41 CET] <durandal_1707> what bug is this about? [14:29:09 CET] <ElAngelo> i have a mov with a av1up stream that i can't get to play/re encode with ffmpeg [14:29:38 CET] <ElAngelo> plays just fine with mplayer if i specify -demuxer mov [14:29:41 CET] <JEEB> I think there are ways of providing samples in a more limited fashion, but generally (if only possible) you create a sample file that doesn't contain real content [14:29:51 CET] <JEEB> or that's so short it doesn't matter [14:30:17 CET] <ElAngelo> i guess i could try to only take the first few seconds [14:30:32 CET] <ElAngelo> well [14:30:40 CET] <ElAngelo> the only thing i can actually do is use dd [14:30:48 CET] <ElAngelo> and cut off a couple of MB [14:30:57 CET] <ElAngelo> but not sure how well this would work as a sample [14:31:02 CET] <ElAngelo> ? [14:31:20 CET] <JEEB> does the same thing happen? [14:31:23 CET] <JEEB> that's the main thing [14:31:30 CET] <JEEB> if you can replicate the thing that you think is a bug [14:31:55 CET] <durandal_1707> For mov that usually not possible to use dd [14:32:10 CET] <JEEB> unless the index is in the beginning of course [14:32:42 CET] <durandal_1707> correct [14:33:38 CET] <ElAngelo> nah it doesn't work [14:33:54 CET] <ElAngelo> even mplayer now reports the file as broken [14:34:55 CET] <jamrial> try qt-faststart maybe [14:37:51 CET] <ElAngelo> problem is i can't re-encode the video with ffmpeg [14:38:14 CET] <ElAngelo> and if i do with mplayer/mencoder, the problem goes away [14:43:20 CET] <ubitux> ElAngelo: jamrial is suggesting to run qt-faststart on your sample, then make a dd cut [14:43:32 CET] <ElAngelo> ah [14:43:39 CET] <JEEB> that moves the index to the beginning [14:43:43 CET] <ubitux> qt-faststart doesn't use ffmpeg api to move things around, it's a braindead memsearch cut & move [14:44:53 CET] <ubitux> jamrial: btw, my fate stuff was stalled in an infinite loop in the ddebug instance on segment thing, it should be fixed [14:45:33 CET] <jamrial> ubitux: cool [14:45:46 CET] <ubitux> at least i restarted it and it doesn't block anymore :p [14:46:35 CET] <jamrial> haha [14:47:11 CET] <jamrial> wonder if it was because -DEBUG -DTRACE makes ffmpeg log an absurd amount of debug lines [14:49:52 CET] <jamrial> ubitux: you could also update it. you haven't run pacman on it for almost a year it seems, seeing how it's still at gcc 5.3 [14:50:08 CET] <nevcairiel> jamrial: since you've been poking mkv for a bit - the current merge i'm working on causes ffmpeg to always write audio bitdepth into mkv files on streamcopy (just because it now sets par->format all the time), even if its kinda pointless info like 32-bit on lossy float codecs, thoughts? just accept it as fact and move on? [14:50:17 CET] <ubitux> jamrial: yeah right, but i'm still trying to figure out the bitrot thing& [14:50:28 CET] <ubitux> and i don't want to mix multiple parameters in [14:50:46 CET] <ubitux> i recently swapped the active drive since i got bitrot with the previous one [14:51:08 CET] <ubitux> if i don't get any more bitrot with that other drive active only i'll move on [14:51:13 CET] <ubitux> but it's too early yet :) [14:51:19 CET] <jamrial> ubitux: ah ok [14:51:51 CET] <jamrial> nevcairiel: yeah, merge it as is. if needed that can be changed afterwards, but not as part of an avconv.c/ffmpeg.c merge [14:54:46 CET] <nevcairiel> if you were encoding it would probably write that today anyway, so its likely just more consistent [15:07:19 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:b55566db4c51: avconv: use avcodec_parameters_copy() with streamcopy [15:07:20 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:166f2c52ace4: Merge commit 'b55566db4c51d920a6496455bb30a608e5a50a41' [15:08:29 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:b7c5f885233a: pixfmt: add P010 pixel format [15:08:30 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:8fee823fe8fb: Merge commit 'b7c5f885233a7b8692140c920d9f43220dc830d9' [15:09:47 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:e78e5b735fd5: swscale: add P010 input support [15:09:48 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:d4509495bfa2: Merge commit 'e78e5b735fd559bc7aa3f5a01e9c8d37dc2ec6d8' [15:15:32 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:2ef87815fec0: hwcontext_dxva2: add support for p010 [15:15:32 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:3dfe97a841fe: Merge commit '2ef87815fec059504370ae3050cc243a53553915' [15:17:12 CET] <cone-856> ffmpeg 03Mark Thompson 07master:4926fa9a4aa0: hwcontext_vaapi: Add driver quirks to the hwdevice [15:17:13 CET] <cone-856> ffmpeg 03Mark Thompson 07master:221ffca6314e: vaapi_encode: Respect driver quirks around buffer destruction [15:17:14 CET] <cone-856> ffmpeg 03Mark Thompson 07master:582d4211e000: vf_scale_vaapi: Respect driver quirks around buffer destruction [15:17:15 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:6ace05beec17: Merge commit '4926fa9a4aa03f3b751f52e900b9efb87fea0591' [15:17:16 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:190254f8810f: Merge commit '221ffca6314ed3ba9d38464ea50cd85251c04e74' [15:17:17 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:745a44ee6130: Merge commit '582d4211e00015b68626f77ce4af53161e2b1713' [15:18:42 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:40f74dc87acb: matroskadec: export CodecDelay [15:18:43 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:15352568132c: Merge commit '40f74dc87acb3f5bbb51f273790a4a7a64201b16' [15:18:56 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:d20c11897522: hwcontext_qsv: add support for p010 [15:18:57 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:e122a725fbe9: Merge commit 'd20c118975220a0256027d1c2410bade94b8534d' [15:20:26 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:536bb17e9659: qsvdec: make ff_qsv_map_pixfmt() return a MFX fourcc as well [15:20:27 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:ce320cf1c4da: qsvdec: use the same mfxFrameInfo for allocating frames that was passed to DECODE_Init [15:20:28 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:92736c74fb16: qsvdec: add support for P010 (10-bit 420) decoding [15:20:29 CET] <cone-856> ffmpeg 03Anton Khirnov 07master:924e2ecd2b7d: qsvdec: when a frames ctx is supplied, use its frame dimensions [15:20:30 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:1bc6cdf2fcbd: Merge commit '536bb17e9659c5ed7576a218d4085cdd6d5742fa' [15:20:30 CET] <trn> /\\/go [15:20:31 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:220e77391552: Merge commit 'ce320cf1c4daab3e2e3726ed7d2e879d10f7b991' [15:20:32 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:3c81fa9a9c5f: Merge commit '92736c74fb1633e36f7134a880422a9b7db14d3f' [15:20:33 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:68b0d7e0be66: Merge commit '924e2ecd2b7d51cca60c79351ef16b04dd4245c3' [15:21:31 CET] <cone-856> ffmpeg 03Martin Storsjö 07master:dc08bbf63a21: vp8dsp: Clarify the first dimension of the mc function tables [15:21:32 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:5a447edd475a: Merge commit 'dc08bbf63a217c839aa4c143f2a1d0b7e2e6d997' [15:22:00 CET] <cone-856> ffmpeg 03Martin Storsjö 07master:e8b96a77010d: arm: Fix a typo in a comment [15:22:01 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:51f5542c776a: Merge commit 'e8b96a77010dd62624c3c65c357d7ae3b397ceaa' [15:29:39 CET] <cone-856> ffmpeg 03Martin Storsjö 07master:f8d17d539570: checkasm: Add tests for vp8dsp [15:29:40 CET] <cone-856> ffmpeg 03Hendrik Leppkes 07master:47f75839e499: Merge commit 'f8d17d53957056c053a46f9320fa7ae6fe1479a5' [17:00:17 CET] <ubitux> note: i'm not going to the internal debate with Nicolas for much longer so anyone caring should probably take over [17:00:26 CET] <ubitux> to continue* [17:05:43 CET] <JEEB> Y [17:15:05 CET] <nevcairiel> any discussions with him are generally always pointless, he has zero capability for compromise [17:15:41 CET] <nevcairiel> should adopt his style of arguments and just go "Rejected." as well [17:32:12 CET] <iive> ubitux: what do you mean by bitrot on hdd? if data is corrupted, then it will give io errors. If not it is most likely that the host has sent the data wrong, aka RAM error. [17:32:54 CET] <ubitux> iive: there is no IO error [17:33:08 CET] <ubitux> the data bitroting is also already written [17:33:23 CET] <ubitux> so there is no reason it would change even with a RAM issue (IMO, but could be) [17:33:48 CET] <ubitux> basically: some FATE samples randomly get bit flips [17:34:00 CET] <ubitux> (and probably other files) [17:34:20 CET] <ubitux> now i'm assuming a firmware issue in one of the disk [17:34:33 CET] <nevcairiel> data stored on hdds can most definiteily bitrot without being read or written, but its usually very rare and for you it happens all the time [17:35:01 CET] <microchip_> nevcairiel: wrong chan, try #ffmpeg :p [17:35:01 CET] <atomnuker> rotational velocidensity's making our lossy fate samples fail! [17:35:21 CET] <ubitux> nevcairiel: "all the time" maybe not, but often yes [17:35:32 CET] <ubitux> at some point it was one or two detected a week [17:35:34 CET] <iive> data is protected with RS sums [17:35:56 CET] <ubitux> it went down a lot when removing one disk from the raid, but it still happened [17:35:56 CET] <microchip_> ubitux: often? i've never seen it here [17:36:03 CET] <ubitux> so now i'm on the second disk [17:36:03 CET] <microchip_> ubitux: doesn't mean much, tho ;) [17:36:06 CET] <iive> so you must get io errors [17:36:15 CET] <ubitux> microchip_: try grep 'ubitux.*bitflip' [17:36:20 CET] <ubitux> iive: no i don't [17:36:33 CET] <microchip_> k [17:36:37 CET] <ubitux> for now my biggest hypothesis is a buggy hd firmware [17:36:59 CET] <microchip_> ubitux: hope you don't use seagate :p [17:37:08 CET] <iive> ubitux: also is it 1 time thing, or when it goes bad, it stays bad? [17:37:13 CET] <ubitux> microchip_: one is a seagate, the other is a WD [17:37:18 CET] <ubitux> microchip_: so yeah, the 2 worst in the world [17:37:24 CET] <microchip_> heh [17:37:33 CET] <microchip_> hitachi! ftw i guess [17:37:38 CET] <ubitux> iive: file stays bitflipped [17:37:54 CET] <nevcairiel> isnt hitachi wd now [17:37:56 CET] <ubitux> (and because fate rsync doesn't check file integrity the file is not corrected) [17:38:12 CET] <microchip_> nevcairiel: it is, but they operate on their own, afaik [17:38:45 CET] <nevcairiel> i think they mostly merged in 2015 or so [17:39:42 CET] <iive> ubitux: does it change files that have been working? [17:39:52 CET] <ubitux> yes [18:06:20 CET] <iive> ubitux: this is very strange, as i said, raw data on hdd is written using RS checksums so it will detect errors. while in theory it is possible that there is damage that somehow produces working checksum, it's not possible for this to happen all the time. [18:06:40 CET] <ubitux> but it does [18:06:52 CET] <ubitux> hence the suggestion that the HD firmware is buggy [18:06:55 CET] <iive> it could only mean that something is overwriting data. [18:07:14 CET] <iive> have you chacked how much data is changed. aka one bit or whole sector? [18:07:29 CET] <ubitux> i haven't, only per-file [18:07:37 CET] <nevcairiel> bitflips on physical drives do happen, or why else would anyone ever bother to implement extra checksums in the file system if the hdd itself does all the work :D [18:08:14 CET] <phh> actually, I think only btrfs (and perhaps zfs?) has data checksum [18:08:26 CET] <phh> and it's optional [18:08:30 CET] <iive> nevcairiel: but bitflips that remain undetected and does not produce ioerrors... is like winning every lotery game. [18:09:22 CET] <iive> it might be possible that a sector is written in the wrong location [18:09:39 CET] <nevcairiel> thats why the specified read error rate of hdds is usually something like 10^14 or so [18:09:58 CET] <nevcairiel> and from what we have seen, it was single bits, in some cases ascii chars turned into another [18:11:19 CET] <iive> i wonder if hdds write individual sectors or whole track at once [18:11:59 CET] <iive> if it is the later, then the hdd would read the track and write it again. during this process it could flip bits. [18:13:55 CET] <iive> ubitux: btw, what filesystem is used and is there llvm? [18:20:00 CET] <ubitux> iive: ext4, no llvm [19:17:08 CET] <cone-856> ffmpeg 03James Almer 07master:2d9433ded9a8: doc/codecs.texi: add new and missing color related options [20:32:39 CET] <llogan> michaelni: do you know the subject of auto generated docs discussion? I have absolutely no memory of this. [20:32:52 CET] <nevcairiel> me neither [20:34:10 CET] <michaelni> its long ago, i dont remember the subject [21:01:07 CET] <michaelni> llogan, nevcairiel maybe it was this: "[FFmpeg-devel] [PATCH 1/2] doc: do not generate doc/avoptions_(codecs|formats).texi" [21:04:01 CET] <llogan> thanks [21:13:48 CET] <llogan> lazy man question: does the Libav auto gen docs allow for manual additions? [21:25:54 CET] <michaelni> i dont remember any manual intervention support but i didnt touch the tool for a long time ... [22:03:13 CET] <cone-856> ffmpeg 03Martin Vignali 07master:d0d6902444ea: doc/filters: add metadata information for blackframe [22:58:12 CET] <cone-856> ffmpeg 03Andreas Cadhalpun 07master:0edd569466eb: softfloat: handle -INT_MAX correctly [23:35:17 CET] <jkqxz> nevcairiel: Could mesa be doing something naughty with the slices there? That sample really does work with both VAAPI and VDPAU on mesa. (On Intel, I get output that looks like only one slice of three or four decoded.) [23:35:36 CET] <nevcairiel> maybe it just parses the start codes in the bitstream buffer [23:35:40 CET] <nevcairiel> it gets all slices in one slice buffer [23:35:41 CET] <jkqxz> I assume a person with an Intel email address can't possibly be testing on only non-Intel... [23:35:42 CET] <nevcairiel> so its possible [23:47:55 CET] <jkqxz> Fun. [23:48:28 CET] <jkqxz> Your dxva2 is Nvidia there? [23:48:52 CET] <nevcairiel> yes [23:49:14 CET] <nevcairiel> but the dxva2 vc1 code isnt even setup to receive multiple slices, i'm trying if i can make it work [00:00:00 CET] --- Tue Nov 15 2016

1 0

ffmpeg.log.20161114
by burek 15 Nov '16

15 Nov '16

[01:13:29 CET] <utack_> does ffmpeg use dithering when coverting video to gif? [01:22:22 CET] <furq> utack_: yes but it's pretty basic iirc [01:22:31 CET] <furq> you'll probably get better results with something like gifsicle [01:22:37 CET] <utack_> ok thanks [01:42:07 CET] <c_14> utack_: If you're planning on creating decent quality gifs with ffmpeg I highly recommend reading through http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html [01:42:31 CET] <c_14> And ffmpeg supports several methods of dithering gifs through the paletteuse filter [01:43:00 CET] <utack_> thanks [03:34:02 CET] <superguest> Hi! [03:34:03 CET] <superguest> http://codepad.org/zngEAjyh [03:34:22 CET] <superguest> I found the commandline from http://superuser.com/questions/1032643/overlay-video-with-video-time-and-or… [03:34:29 CET] <superguest> which is what I want to achieve. [03:34:43 CET] <superguest> burn in timecode [04:55:59 CET] <dl2s4> superguest, ffmpeg -i input.mkv -vf "drawtext=fontfile=DejaVuSansMono.ttf: text='%{pts \\: hms}': x=(w-tw)/2: y=h-(2*lh): fontcolor=red: fontsize=25: box=1: boxcolor=0x00000099" -c:v libx264 -preset ultrafast -c:a copy output.mkv [04:56:07 CET] <dl2s4> works for me [05:48:16 CET] <superguest> hey dl2s4 [05:48:53 CET] <superguest> dl2s4, do you not have to specify the path to the "DejaVuSansMono.ttf"? [06:10:10 CET] <superguest> dl2s4 yours indeed work. but I would still like to know whether you actually need to specify the fullpath to "DejaVusansMono.ttf" [06:12:55 CET] <dl2s4> does not looks like it. i dont even have DejaVuSansMono.ttf ffmpeg picks /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf instead [06:15:39 CET] <superguest> ffmpeg is very advanced. [06:16:20 CET] <superguest> it makes extensive use of the hw compatibilties. [06:22:30 CET] <dl2s4> actually i dont need to set any fontfile. "FFmpeg -i input.mkv -vf "drawtext=fontfile: text='timecode\:%{pts \\: hms}': fontcolor=white: fontsize=25: box=1: boxcolor=black" -c:v libx264 -preset ultrafast -c:a copy output.mkv" still works [06:24:43 CET] <dl2s4> but i guess you would need to set full path if you want a specific font [06:26:08 CET] <superguest> dl2s4 if you could tell me what I need to get it to do countdown timecode instead, that would really make my day :-) [06:45:48 CET] <superguest> dl2s4, still with me? :-) [06:47:50 CET] <dl2s4> yaah still fiddle around [06:48:15 CET] <dl2s4> have a look at this maybe http://video.stackexchange.com/questions/15556/ffmpeg-video-with-timer [07:00:09 CET] <dl2s4> superdump, "ffmpeg -i input.mkv -vf "drawtext=fontfile=: text='%{eif\:53-t\:d}': fontcolor=white: fontsize=25: box=1: boxcolor=black" -c:v libx264 -preset ultrafast -c:a copy coutput.mkv" works if your video is 53 sconds. and it only shows seconds so it isnt perfect [07:01:15 CET] <dl2s4> sorry i mean superguest [07:02:48 CET] <dl2s4> i am tired now, but it was interesting, maybe i tomorrow.. i just do hit and error ;) [07:03:10 CET] <superguest> dl2s4 okay. [07:03:15 CET] <superguest> goodnight dl2s4 [07:38:58 CET] <t4nk206> Hi,guys [07:39:06 CET] <t4nk206> pCodec=avcodec_find_decoder(codec_id); [07:39:27 CET] <t4nk206> I had a problem in this function,always return NULL [07:39:57 CET] <t4nk206> can anyone help me with that? [12:10:31 CET] <kerio> how do i read a raw ffvhuff bitstream? [13:14:01 CET] <bagbag> hi, how can i specifiy the first audio stream which is english. I thought about something like -map 0:a:m:language:eng:0, but it doesn't work [14:20:15 CET] <JonG> am using the FFmpeg drawtext filter tooverlay a name on a video (e.g. "TEST d"). The name can have any utf-8 characters in it. I have a custom font I have specified. The font only contains commonly used English characters. It seems that FFmpeg ignores characters not present in the ttf file. When used on the web or elsewhere, I guess the character [14:20:15 CET] <JonG> from my font is used if it exists in the ttf. Otherwise a default font is used. Is this possible in FFmpeg? Or do I need to create a custom ttf with that content? [14:20:26 CET] <JonG> I am** [14:20:32 CET] <JonG> http://pastebin.com/qHNsZTvP [14:24:37 CET] <furq> JonG: that's done by fontconfig on *nix, so if that works at all in ffmpeg then i assume you'll need a build with fontconfig support [14:43:14 CET] <bencoh> hmmm iirc (at least one of the) text filters in ffmpeg has support for utf8 input [14:43:41 CET] <bencoh> I remember reading libavfilter code messing with utf8 stuff and freetype [14:43:51 CET] <furq> bencoh: the issue is that the font he's using doesn't have the glyphs and it's not falling back to another font [14:44:14 CET] <bencoh> ah [14:44:22 CET] <furq> fontconfig can do that but i don't know whether ffmpeg supports it [14:44:25 CET] <bencoh> dunno about the fallback mechanism [14:57:58 CET] <JonG> Thanks guys. I am compiling with --enable-fontconfig now and looking into the options. I wonder if it might just be easier to copy and paste a font together that does what I need though. [16:05:38 CET] <antiPoP> Hi [16:06:19 CET] <antiPoP> Can I make thumbnails of a determinate size without resizing the video first? [16:09:29 CET] <Bombo> antiPoP: i don't know, did you try it? adding scale filter when doing the tn? [16:25:35 CET] <antiPoP> Bombo, yes, that can be done, but I was wondering if you can generate thumbnails without resizing te video first, as what I ave found is https://stackoverflow.com/questions/14551102/with-ffmpeg-create-thumbnails-… [16:35:47 CET] <Corun> Hi. I have a program that generates frames that I'd like to output to a video. I've been looking at various examples, and trying to find documentation. But I'm pretty confused on a few things. [16:35:49 CET] <Corun> Particularly: Once Ive found a codec, should I set the codecs fields like bitrate, width/height etc? Then there are other fields in AVCodecContext like time_base. But I only have an AVCodecContext once Ive made the AVStream. And it looks like Im not supposed to set things in the streams underlying codec context anyway. I note that the stream *also* has time_base. But I dont think Im supposed to set that either. May [16:36:04 CET] <Corun> ite_header?, but at this point Im so lost that I thought Id ask. Or maybe is there a current example of how to just write a video? Theres muxing.c which uses stream.codec which is deprecated, and theres decoding_encoding.c which doesnt use avformat. [16:41:20 CET] <Bombo> antiPoP: does that resize the video? i thought it would just resize the output, which is here an image... you could not resize anything, and use imagemagick afterwards to resize the tn ;) [16:42:09 CET] <antiPoP> antiPoP, I haven't checked , but seems that resizes the video, then generates thumbs [16:48:34 CET] <Bombo> antiPoP: the entire video? or just one frame? [16:48:57 CET] <antiPoP> Bombo, the entire video, check the link [16:53:12 CET] <Corun> Hmm, worked it out. May have been reading an old muxing.c [16:53:34 CET] <Bombo> antiPoP: are you sure? did you see the '-vframes 1'? [16:54:54 CET] <antiPoP> Bombo, sorry the link was https://stackoverflow.com/questions/35912335/how-to-extract-a-fixed-number-… [16:56:07 CET] <antiPoP> Bombo, what I need is https://stackoverflow.com/a/35913395 , but with a fixed thumbnail size [17:02:39 CET] <Bombo> antiPoP: how about adding scale= to the thumbnail filter? [17:09:11 CET] <antiPoP> Bombo, ffmpeg -i input.mp4 -vf thumbnail=300,setpts=N/TB,scale=-2:480 -r 1 -vframes 50 inputframes%03d.png [17:19:46 CET] <Bombo> antiPoP: you think that means 'take one frame each 300 frames until we got 50 thumbnails' [17:20:09 CET] <antiPoP> yes, that seems to work [17:21:37 CET] <Bombo> hm i tried it, i got 50x the same frame [17:27:23 CET] <antiPoP> Bombo, works for me [17:27:51 CET] <antiPoP> ffmpeg -i input.mp4 -vf thumbnail=300,setpts=N/TB,scale=-2:90 -r 1 -vframes 50 inputframes%03d.png [17:30:16 CET] <JonG> If FFmpeg exits with an error code 9, and no other messages, what does that mean? Device ran out of memory maybe? http://pastebin.com/znFKSuBX [17:33:06 CET] <microchip_> JonG: yes, most likely http://people.cs.pitt.edu/~alanjawi/cs449/code/shell/UnixSignals.htm [17:35:54 CET] <Bombo> antiPoP: i see, the -r 1 is important, that was missing, works now ;) [17:36:21 CET] <antiPoP> Bombo, great, what does -r 1 does? [17:37:16 CET] <Bombo> antiPoP: sets the frame rate [17:37:36 CET] <antiPoP> ok [17:37:49 CET] <antiPoP> tnx for the help [17:38:16 CET] <Bombo> thx too, i didn't know that this was possible, useful feature ;) [18:10:54 CET] <NapoleonWils0n> hi all [18:11:27 CET] <NapoleonWils0n> im trying to record screen and mic using x11grab and alsa but keep get alsa xrun erros [18:12:10 CET] <NapoleonWils0n> if i record the audio and video seperately i dont get the xrun errors but the video is 10 miutes shorter thn the video [18:13:25 CET] <NapoleonWils0n> tried several diffent combinations of codecs but i always get alsa xruns, tried increasing the tread queue size but that doesnt work either [18:16:35 CET] <debianuser> NapoleonWils0n: What's the ffmpeg command you're using? [18:17:24 CET] <debianuser> It's just alsa xrun usually means that application is processing the buffer slower than alsa's driver/hardware is filling it, i.e. that app is too slow. Maybe you just don't have enough CPU power? Try some faster encoder, something like: `ffmpeg -f x11grab -r 15 -s 320x240 -i :0 -f alsa -ac 2 -ar 48000 -i default -vcodec libx264 -preset ultrafast -tune zerolatency -acodec libvorbis somefile.mkv` [18:17:55 CET] <NapoleonWils0n> these are the commands im using: https://github.com/NapoleonWils0n/cerberus/blob/master/ffmpeg/ffmpeg-aac-sc… [18:18:33 CET] <NapoleonWils0n> but im using hw:1 external usb mic [18:20:21 CET] <NapoleonWils0n> also tried uncompressed video as well [18:22:51 CET] <debianuser> uncompressed video write speed may be limited by your hdd, some fast compression should usually be better. Try my command above :) [18:23:06 CET] <NapoleonWils0n> im just about to give a go cheers mate [18:24:49 CET] <debianuser> (for alsa it's usually better to use card names instead of numbers, e.g. "hw:CardNameHere,0" instead of "hw:0,0", as card numbers may change on reboot, names usually don't change. You can see card names in `cat /proc/asound/cards` and `aplay -l` or `arecord -l` output) [18:25:22 CET] <NapoleonWils0n> cheers got an xrun but im recording 1366x768 at 30 frames [18:27:10 CET] <debianuser> I mean it was just a test. :) Try recording 320x240 at 15 fps and see if you get an xrun. I understand that top left 320x240 square of your screen is not too useful, but it's a test to check if you get xruns with that setup or not. :) [18:27:38 CET] <NapoleonWils0n> yes ill give that a shot, im actually running debian jessie [18:29:05 CET] <NapoleonWils0n> i get thread message blocking for both audio and video, current value 8 but no xruns [18:29:56 CET] <debianuser> "xrun" ("buffer overrun" or "buffer underrun") itself is not a bad thing, it's just a warning, any alsa application must be able to recover from it automatically. Also it should not be a problem if it happens just once when ffmpeg starts. But if xrun happens many times during recording - you may hear it as slight click, and it may also cause you video/audio desync. [18:30:37 CET] <NapoleonWils0n> kept getting xruns after 30 seconds and the audio would cut out completly [18:32:28 CET] <debianuser> Can you copy full command you used and its output to some pastebin? [18:33:00 CET] <NapoleonWils0n> these are the commands i have used to record over 100 videos on arch linux [18:33:02 CET] <NapoleonWils0n> https://github.com/NapoleonWils0n/cerberus/blob/master/ffmpeg/ffmpeg-aac-sc… [18:34:00 CET] <NapoleonWils0n> im using debian and not arch and using external usb mic because interal mic has died [18:35:34 CET] <NapoleonWils0n> i have exactly the same set up on debian as arch, so a bit baffled [18:35:52 CET] <debianuser> Ah, I probably misunderstand you then. :) Were you still getting xruns with `ffmpeg -f x11grab -r 15 -s 320x240 -i :0 -f alsa -ac 2 -ar 48000 -i default -vcodec libx264 -preset ultrafast -tune zerolatency -acodec libvorbis somefile.mkv` ? [18:36:30 CET] <NapoleonWils0n> no xruns with that command just error about thread queue size on audio and video [18:36:51 CET] <NapoleonWils0n> using a mac air running debian with 4 gig of ram [18:37:08 CET] <NapoleonWils0n> so by default 8 threads [18:37:39 CET] <NapoleonWils0n> if i record the audio and video seperatly no xrun errors but video is 10 mins shorter than the video [18:38:30 CET] <debianuser> Does the file encoded with that command looks good? (except being small and not too useful) I mean can you see an expected 320x240 video and hear the audio if you play that "somefile.mkv" recorded with that command? [18:41:19 CET] <NapoleonWils0n> yes that works perfectly [18:41:54 CET] <NapoleonWils0n> increasing screen size to 1366x768 and frame rate 15 [18:44:00 CET] <NapoleonWils0n> no errors at 1366x768 15 frames [18:46:49 CET] <NapoleonWils0n> 25 frames works but 30 frames causes xruns [18:47:15 CET] <NapoleonWils0n> so 1366x768 25 frames with your command works [18:54:45 CET] <NapoleonWils0n> but as soon as i open chrome and some webpages i get alsa xruns at 25 frames [19:54:34 CET] <guille> Hello [19:55:23 CET] <guille> i need some help with ffmpeg compilation options, can someone help me ? [20:04:14 CET] <kurufu> what kind of help with ffmpeg compilation options? [20:07:41 CET] <guille> hello kurufu [20:07:53 CET] <guille> im trying compiling ffmpeg [20:08:04 CET] <guille> and i need two filters, "drawtext" and "drawbox" [20:10:34 CET] <durandal_1707> drawbox is free, drawtext needs fontconfig Iirc it's documented [20:11:25 CET] <guille_> im here again [20:12:01 CET] <guille_> i need two filters [20:12:05 CET] <guille_> drawtext and drawbox [20:12:24 CET] <durandal_1707> fontconfig is installed? [20:14:24 CET] <guille_> i dont know [20:14:43 CET] <guille_> im follow this tutorial [20:14:48 CET] <guille_> ffmpeg.org/wiki/CompilationGuide/Centos [20:16:22 CET] <kepstin> guille_: if you'd followed that guide, both of the filters you want would be available by default [20:17:46 CET] <guille_> yes kepstin, but in theory the --enable-libfreetype add this filters, no? [20:18:52 CET] <kepstin> yes, and that guide installs the freetype devel package, and includes the --enable-libfreetype option on configure [20:22:06 CET] <guille_> but not [20:24:10 CET] <guille_> but not active that filters [20:24:11 CET] <guille_> ? [20:24:44 CET] <furq> guille_: https://www.johnvansickle.com/ffmpeg/ [20:28:38 CET] <guille_> this is a new version? [20:32:22 CET] <furq> yes [20:34:23 CET] <guille_> ok [20:34:28 CET] <guille_> im trying install that [20:34:33 CET] <guille_> wit wget, extract [20:34:35 CET] <guille_> and no¿? [20:34:37 CET] <guille_> now? [20:34:38 CET] <guille_> ./ffmpeg? [20:35:14 CET] <guille_> -bash: ./ffmpeg: Is a directory (error) [20:39:19 CET] <llogan> navigate to the directory containing the executable and then run "./ffmpeg -i ...". or provide the full path the the file: "/path/to/ffmpeg -i ..." or place the file somewhere in your PATH [20:43:35 CET] <_sajko> hi, i'm trying to create a mosaic stream over UDP which i can connect my VLC. FFMPEG starts, but i can't connect. This is what i'm running http://pastie.org/private/ym9ldhb7hjxz522twxexxa [20:43:50 CET] <_sajko> might just be that i've missunderstood the workings of a udp output? [20:44:25 CET] <_sajko> my inputs are 2 http:// ts streams [20:45:37 CET] <llogan> i don't know about the networking, but you can use hstack instead of pad+overlay. and "-strict -2" isn't needed unless your ffmpeg is old. [20:46:11 CET] <_sajko> ah well i ran into some issues when i tried using libx264 and internet said -strict -2 solved it... it just stuck around [20:46:46 CET] <llogan> i can't recall any scenario where -stict -2 was ever needed for any use of libx264 [20:47:12 CET] <llogan> but for the native AAC encoder it used to be required [20:47:39 CET] <_sajko> might have been that then... [20:47:56 CET] <_sajko> i've tried so many different versions i can barely remember which did what :P [20:49:22 CET] <guille_> @llogan in make that [20:49:35 CET] <guille_> and now we have two versions [20:50:29 CET] <furq> _sajko: that command works for me [20:50:43 CET] <furq> you probably want to add -c:v libx264 or else -preset ultrafast doesn't do anything [20:50:49 CET] <furq> the default encoder for mpegts is mpeg2video [20:51:12 CET] <llogan> guille_: in make that you use version which want use you [20:51:40 CET] <guille_> and now, how i said to system what version i prefer? [20:52:02 CET] <furq> http://vpaste.net/N2nkG [20:52:07 CET] <furq> i can connect to that stream with mpv [20:52:31 CET] <llogan> guille_: it depends where you placed it and the order of directories in your PATH. [20:52:46 CET] <furq> and it looks substantively the same as your command [20:53:29 CET] <furq> assuming 10.x.x.x is your local ip [20:53:48 CET] <guille_> llogan can i create a simbolik link like that ln -s /usr/local/bin/ffmpeg/ffprobe /usr/bin/ffprobe #for ffprobe? [20:54:01 CET] <guille_> delete my old simbolic link and replace for that [20:54:03 CET] <furq> don't put directories in /usr/local/bin [20:54:17 CET] <furq> just put the binaries in there directly and remove any ffmpeg stuff in /usr/bin [20:54:29 CET] <llogan> symbolic linking for such use is messy [20:55:06 CET] <llogan> guille_: which distro? [20:55:35 CET] <guille_> Centos 7 [21:00:09 CET] <guille_> I make one first instalation incomplete. And now, with yout link i can make a instalation with all filters that i need. [21:00:10 CET] <guille_> But [21:00:23 CET] <guille_> now, when i excecute ffmpeg comand in ssh [21:00:40 CET] <guille_> show me the first instaltion (incomplete filters, instalation) [21:00:50 CET] <guille_> sorry for my really bad english [21:05:59 CET] <guille_> llogan [21:06:03 CET] <guille_> you understand me? [21:06:05 CET] <guille_> :D [21:06:27 CET] <furq> guille_: run `whereis ffmpeg` [21:06:50 CET] <furq> or `which ffmpeg` [21:08:16 CET] <guille_> ffmpeg: /usr/local/bin/ffmpeg /usr/local/bin/ffmpeg. /usr/share/ffmpeg /root/bin/ffmpeg /usr/share/man/man1/ffmpeg.1.gz [21:14:11 CET] <wuOz> hello, why can't I control ffplay with my keyboard during a ssh session? [21:14:51 CET] <wuOz> + I use screen too [21:16:43 CET] <_sajko> furq: is there something special when connecting vlc to the udp port? cause my vlc won't even show me an error msg [21:16:52 CET] <llogan> guille_: why is there a period in "/usr/local/bin/ffmpeg."? what does "which ffmpeg" show? which is the current user? root? [21:19:11 CET] <furq> _sajko: i don't use vlc so i have no idea [21:19:19 CET] <furq> `mpv 127.0.0.1:9000` worked fine [21:20:32 CET] <_sajko> hum... maybe it's just the player that's the issue then [21:21:46 CET] <_sajko> ah well, another day... i kinda need it to be outputted to http stream so i guess i'll have to get ffserver up and running [21:23:22 CET] <llogan> my condolances [21:37:03 CET] <guille_> llogan yes, i excecute with root user in putty ssh conection [21:38:19 CET] <guille_> "/root/bin/ffmpeg" show: /root/bin/ffmpeg [21:38:25 CET] <llogan> it appears you have a ffmpeg executable in /root/bin which probably takes priority over /usr/(local)/bin. [21:38:52 CET] <llogan> is the one in /root/bin the old one you don't want? [21:39:34 CET] <guille_> yes [21:39:42 CET] <guille_> that is the first installation [21:39:47 CET] <llogan> then delete it if you don't want it [21:40:40 CET] <llogan> and also ffprobe too [21:42:40 CET] <guille_> ok i delete that [21:42:42 CET] <guille_> now [21:42:46 CET] <guille_> -bash: ffmpeg: command not found [21:42:49 CET] <guille_> xD [21:44:51 CET] <llogan> run "hash -r" [21:44:54 CET] <llogan> then try again [21:46:13 CET] <guille_> nothing [21:51:43 CET] <guille_> llogan thak you for you help [21:51:48 CET] <guille_> i continue tomorrow xD [21:51:52 CET] <llogan> guille_: is /usr/local/bin/ffmpeg a directory or an executable? [21:51:54 CET] <guille_> that make me crazy [21:52:09 CET] <guille_> directory [21:52:36 CET] <llogan> like furq said, don't put a directory there. move the ffmpeg executable file there [21:53:07 CET] <llogan> got to go [23:36:51 CET] <markvandenborre> I'm doing ffmpeg -i ~/720p.mp4 -rs -c copy -f mpegts udp://227.0.0.2:9000 [23:37:16 CET] <markvandenborre> because I want to play it back from this multicast ip [23:37:51 CET] <markvandenborre> that works fine to an extent, only ffmpeg pushes things into this multicast address too fast [23:38:36 CET] <markvandenborre> how do I make sure that it pushes its stream into this multicast stream at normal playback speed? [23:38:40 CET] <markvandenborre> any hints? [23:38:45 CET] <furq> add -re before -i [23:38:52 CET] <markvandenborre> thank you [23:39:18 CET] <markvandenborre> does exactly what I want it to do [23:39:21 CET] <markvandenborre> this really helps! [23:39:28 CET] Action: markvandenborre looks it up [23:41:14 CET] <c_14> What does -rs do? [23:41:15 CET] <DHE> markvandenborre: depending on the version, you can specify ?bitrate=7000000 or whatever the bitrate is. you'll also want to use -muxrate to force CBR on the mpegts format though. that'll REALLY smoothen in out. [23:41:18 CET] <c_14> I don't think I've ever seen that option. [23:41:54 CET] <DHE> I don't see it in the help... [23:43:01 CET] <c_14> There's a suboption of the colorbalance filter called "rs" but other than that... [23:48:01 CET] <markvandenborre> DHE: c_14 : much appreciate your help [23:48:13 CET] <markvandenborre> but the -re option does what it needs to do [23:50:30 CET] <t4c0c4t> hello all, i'm having trouble getting h264_nvenc up and running, receiving the following error: https://gist.github.com/smp/9aae1dc9c375cab5035db4e027850c38 [23:51:47 CET] <t4c0c4t> running cuda 7.5 and nvidia driver 352.99 (which is the suggested driver for that version of cuda) [23:51:53 CET] <t4c0c4t> any thoughts? [23:53:16 CET] <c_14> dlsym is failing [23:53:29 CET] <c_14> Do you have the shared object files in your ldpath etc? [23:57:21 CET] <c_14> It's loading the library correctly though, but not finding the symbol [23:57:28 CET] <t4c0c4t> @c_14 sorry, i'm a bit of a noob when it comes to complication of C programs, where might i check? [23:57:38 CET] <kbarry> I am looking thru the documentation, and maybe I don't know what I am looking for. [23:57:56 CET] <kbarry> I am trying to more or less "mute" any sounds that is above a certain frequency, [23:58:02 CET] <c_14> locate libnvidia-encode.so.1 <- t4c0c4t [23:58:15 CET] <c_14> kbarry: lowpass filter? [23:58:18 CET] <kbarry> I see high/lowpass filters, bandreject, etc. I [23:58:41 CET] <kbarry> Hrm. I wasn't able to get that to do what i wanted. I think i just am a newb. [23:58:50 CET] <kbarry> Let me share the syntax i used. [23:59:16 CET] <kbarry> ffplay .\nora_jones_come_away_with_me.flac -af "lowpass=f=2000:width_type=h" [23:59:35 CET] <kbarry> i get a ton of clipping/squeeling [23:59:43 CET] <kbarry> I think I might be missing something else in the filter. [00:00:00 CET] --- Tue Nov 15 2016

1 0

ffmpeg-devel.log.20161113
by burek 14 Nov '16

14 Nov '16

[00:14:46 CET] <cone-919> ffmpeg 03James Almer 07master:f6f1fc2db1b5: fate: fix fate-api dependencies [00:53:50 CET] <cone-919> ffmpeg 03James Almer 07master:66453b1fba6c: avformat/mov: zero initialize codec_name in mov_parse_stsd_video() [03:13:44 CET] <cone-919> ffmpeg 03Marton Balint 07master:d318e0602443: ffmpeg: add newline to avformat_write_header error message [03:13:45 CET] <cone-919> ffmpeg 03Marton Balint 07master:e20e9b9033b7: lavf/fifo: fix undefined behaviour in deinit when destroying mutex [03:13:46 CET] <cone-919> ffmpeg 03Marton Balint 07master:0f8b852a6428: lavfi/ebur128: specify scaling_factor directly [10:57:07 CET] <cone-582> ffmpeg 03Nicolas George 07master:22aa649c13b4: fate/colorkey: disable audio stream. [10:57:07 CET] <cone-582> ffmpeg 03Nicolas George 07master:183ce55b0de0: lavfi: split frame_count between input and output. [11:38:45 CET] <cone-582> ffmpeg 03Vlad Tarca 07master:2bd83ef26acf: avformat: Add Pro-MPEG CoP #3-R2 FEC protocol [12:00:13 CET] <durandal_1707> is mov support broken? [12:00:36 CET] <JEEB> there are major regressions after the crappy edit list support was added [12:00:51 CET] <JEEB> there was a flag added that disables that so you could try it [12:01:10 CET] <JEEB> -ignore_editlist 1 [12:01:34 CET] <JEEB> although that will not fill in any gapless data that was before [12:08:26 CET] <durandal_1707> is someone working on fixing this? [12:09:15 CET] <nevcairiel> if you have a particular broken case, giving a sample to the guy from google working on this might help him [12:11:16 CET] <JEEB> I think I might just post a question on where one could stick the proper export of that data if it's now properly parsed from the files. it should be implemented on the presentation level, not in lavf only [12:11:55 CET] <JEEB> this whole thing has just dragged for way too long and we have this crapshoot of a thing right now. [12:12:19 CET] <JEEB> but yes, workarounds galore if you post a sample in the thread :P [12:20:00 CET] <cone-582> ffmpeg 03Hendrik Leppkes 07master:0539ff0e1b2f: configure: use check_lib2 for cuda and cuvid [12:27:23 CET] <JEEB> there, now I'm at least not only herping a derp on IRC [12:39:10 CET] <cone-582> ffmpeg 03Andreas Cadhalpun 07master:7112b56a3413: vp9_mc_template: limit assert to SCALED == 0 [14:27:54 CET] <jkqxz> nevcairiel: I don't see a way to make this work without keeping qsv_transcode_init(). The filter stuff can be hacked around easily (e.g. <http://sprunge.us/YVUd>, needed because hw_frames_ctx can't be set on the first init), but the encoder starting before the decoder does anything is just fatal to the hwcontext setup. [14:31:01 CET] <jkqxz> (As far as I can tell, the issues are identical with cuvid.) [15:21:04 CET] <nevcairiel> jkqxz: i'm currently messing with the cuvid stuff to keep it working, and I had to find a new place for the *_transcode_init calls, but i think it should work without the hack in the init filter method in your patch [15:23:23 CET] <nevcairiel> at least something simple like ffmpeg -hwaccel cuvid -c:v h264_cuvid -i <file> -c:v h264_nvenc <file> still works [15:24:33 CET] <nevcairiel> and logging shows it uses cuda pixfmt all around [15:25:29 CET] <nevcairiel> i'll update my branch when i have rebased all the things [15:26:35 CET] <jkqxz> Yeah, you don't need it if you have a way to set resample_pix_fmt before the first filter graph init. I ended up with that because there is no sensible place to set it. [15:27:27 CET] <jkqxz> That is, it made the filter graph setup work, but the whole transcode still didn't because the hardware context propagation was still broken. [15:28:13 CET] <nevcairiel> oh you meant when you were trying t oget rid of the transcode_init calls, makes sense [15:28:14 CET] <jkqxz> Hence the need for *_transcode_init() to hack everything together in one place, which can set resample_pix_fmt and the hardware context. [15:28:17 CET] <jkqxz> Yes. [15:28:35 CET] <nevcairiel> without the cleaned up init ordering thats likely going to be hard indeed [15:29:28 CET] <jkqxz> I'm writing a new qsv_transcode_init() now to use hwcontext but otherwise work mostly as before. [15:29:45 CET] <nevcairiel> probably going to look much like the cuvid one then [15:30:28 CET] <BtbN> the cuvid one is pretty generic now, except for that hack to delay hwframes initialization to the cuvid decoder. [15:31:09 CET] <BtbN> The only catch is that it has to run early enough so all the filters and stuff see the contexts as well [15:31:50 CET] <nevcairiel> thats the trick right now [15:32:32 CET] <jkqxz> Not necessarily, it's better off because the hardware context on the decoder isn't needed until get_format() is called. [15:34:09 CET] <jkqxz> Though it still needs nastiness for the early filter setup, yes. [15:40:27 CET] <nevcairiel> michaelni: i took out the merge commit that broke the sample from 1167, that one needs more work together with the one after it, might skip that for now and do those two together out-of-band [15:40:43 CET] <nevcairiel> i pushed an updated set to my branch with cuvid transcoding remaining functional [15:45:53 CET] <nevcairiel> an interesting side fact: i was transcoding some h264 full hd stream with cuvid/nvenc, and the aac encoding for the audio stream was slowing it down by around half [15:47:08 CET] <nevcairiel> (on a broadwell-e i7 no less) [15:47:30 CET] <nevcairiel> 800-900 fps -> sub 500 [15:47:38 CET] <nevcairiel> using aac_coder fast fixes it =p [16:39:09 CET] <kierank> nevcairiel: put the aac encoding in a different thread :) [16:39:24 CET] <nevcairiel> of course, but this is ffmpeg.c [16:39:33 CET] <nevcairiel> my own transcoder uses threads [16:39:57 CET] <nevcairiel> although if speed is too different, interleaving constraints will limit it eventually either way [16:43:07 CET] <jkqxz> nevcairiel: <http://sprunge.us/bQSV> kindof works, but is horrible. (Also sprunge wins at link choice.) [16:45:02 CET] <nevcairiel> as long as it works and is contained to ffmpeg_qsv.c /me shrugs [16:45:09 CET] <jkqxz> It also fails with default encoder settings, because they include lots of lookahead and you run out of surfaces in the decoder. [16:45:54 CET] <nevcairiel> there was a problem in the old decoder where it preferred to buffer output surfaces instead of input data, usually blowing up the shared surface pool, but i assume thats done for now [16:51:12 CET] <jkqxz> Default lookahead depth seems to be 40 in libmfx. I guess it's easiest to just always give the decoder 64 surfaces for now. [17:20:43 CET] <michaelni> nevcairiel, seems i cant find any more failures with your branch [17:20:56 CET] <nevcairiel> the two commits left in there mostly just move code [17:21:03 CET] <nevcairiel> so i would hope not [17:21:03 CET] <nevcairiel> :D [17:21:33 CET] <nevcairiel> before i have to rebase them again i'll just take that [17:21:59 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:ba7397baef79: avconv: factor out initializing stream parameters for encoding [17:21:59 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:50722b4f0cbc: avconv: decouple configuring filtergraphs and setting output parameters [17:21:59 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:ca7cdffb70c5: ffmpeg_filter: fix hwaccel transcoding [17:21:59 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:6b449a12906c: Merge commit 'ba7397baef796ca3991fe1c921bc91054407c48b' [17:21:59 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:198e8b8e7746: Merge commit '50722b4f0cbc5940e9e6e21d113888436cc89ff5' [17:25:52 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:3e265ca58f05: avconv: do packet ts rescaling in write_packet() [17:25:53 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:a3a0230a9870: avconv: init filtergraphs only after we have a frame on each input [17:25:54 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:232399e3ee21: avconv: pass the hwaccel frames context to the decoder [17:25:55 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:f761d4967053: Merge commit '3e265ca58f0505470186dce300ab66a6eac3978e' [17:25:56 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:7c282d0c758d: Merge commit 'a3a0230a9870b9018dc7415ae5872784d524cfe5' [17:25:57 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:4945343606ec: Merge commit '232399e3ee219d16d0e0d482c9f31a26202d4993' [17:26:37 CET] <nevcairiel> jkqxz: so i assume i just dont merge anything from the avconv_qsv rework and you'll supply a patch on top of ours? [17:29:52 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:02c2761973df: avconv_qsv: use the device creation API [17:29:53 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:93cd6dd48859: Merge commit '02c2761973dfc886e94a60a9c7d6d30c296d5b8c' [17:29:53 CET] <nevcairiel> (thats what i went with) [17:29:54 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:53e116eeeb1b: doc: update merge status for recent additions and skipped merges [17:38:13 CET] <cone-642> ffmpeg 03Clément BSsch 07master:4a081f224e12: libavcodec: fix constness in clobber test avcodec_open2() wrappers [17:38:14 CET] <cone-642> ffmpeg 03Mark Thompson 07master:bd31c61cf94d: avconv: Remove hw_device_ctx output filter reinit hack [17:38:15 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:db854c6c4a6c: Merge commit '4a081f224e12f4227ae966bcbdd5384f22121ecf' [17:38:16 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:c17563c5d3c9: Merge commit 'bd31c61cf94d01dbe1051cf65874e7b2c0ac5454' [17:39:34 CET] <cone-642> ffmpeg 03Mark Thompson 07master:8a62d2c28fba: vaapi_encode: Maintain a pool of bitstream output buffers [17:39:35 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:724a71dced1c: Merge commit '8a62d2c28fbacd1ae20c35887a1eecba2be14371' [17:51:48 CET] <jkqxz> Yes, sure. (Sorry, distracted for a bit.) [17:54:39 CET] <jkqxz> I have <http://sprunge.us/ibSI>. Is there some merge magic I should do to make it base on 02c2761973df? [17:55:35 CET] <jkqxz> (The diff against libav 02c2761973df is much more coherent than the diff against ffmpeg 93cd6dd48859, so I think that makes sense.) [18:19:01 CET] <jamrial> jkqxz: you mean this http://pastebin.com/JG042ReT? [18:30:17 CET] <jkqxz> jamrial: Yes, that would be the other half. It has components from both, so preserving history correctly would be nice. [18:32:58 CET] <nevcairiel> history with merges gets kinda confusing anyway, so just make it a patch as such [18:37:59 CET] <cone-642> ffmpeg 03Vittorio Giovara 07master:f172e22d6aed: pixdesc: Add aliases to SMPTE color properties [18:38:00 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:2d7cf6f72ba2: Merge commit 'f172e22d6aed0bff36e975bafb0183b6779f9444' [18:39:22 CET] <jkqxz> I'm not sure what you mean. How would I make the patch work in that form? (My git knowledge around this is not very good.) [18:40:11 CET] <nevcairiel> i meant just make a normal patch [18:40:52 CET] <jkqxz> And ignore the history. Ok. [18:41:14 CET] <nevcairiel> feel free to mention the commit hash its based on in the message [18:41:30 CET] <jkqxz> Also, how do cherry-picks work wrt that? [18:42:02 CET] <jkqxz> It doesn't get the history now? [18:43:38 CET] <nevcairiel> cherry-picks can use hsitory to resolve conflicts if you do it properly, but they dont record any history otherwise [18:43:57 CET] <BtbN> nevcairiel, does cuvid need some work now, or was that not the breaking set, or is it already fixed for good now? [18:44:04 CET] <nevcairiel> should be fixed [18:44:21 CET] <cone-642> ffmpeg 03Vittorio Giovara 07master:444a36269f85: pixdesc: Fix AVCOL_TRC_BT2020_12 name [18:44:22 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:411ecb0be664: Merge commit '444a36269f853844369af0a9836507e5a2780323' [18:44:29 CET] <nevcairiel> transcode works at least, didnt try libnpp [18:44:37 CET] <nevcairiel> cba to find out how to set that up for building [18:44:59 CET] <BtbN> if you have cuda/cuvid set up for building, it should just work [18:45:13 CET] <BtbN> unless you are already using the dynload patches [18:45:18 CET] <nevcairiel> nah plain master [18:45:23 CET] <nevcairiel> hence why i fixed configure [18:45:26 CET] <nevcairiel> :D [18:45:46 CET] <BtbN> libnpp does not need anything special then. It just has a runtime dep on some libraries [18:46:17 CET] <nevcairiel> anyway i'm done merging for now, will do more tomorrow, should be mostly easy ones for a long time now, only a few avconv changes tha tdon't apply because they are fixes for the one I skipped [18:46:55 CET] <BtbN> libnpp will also allways stay non-free [18:47:12 CET] <BtbN> the libraries are not shipped with the driver, only with the CUDA sdk, and it expects you to ship them with your application. [18:50:15 CET] <RiCON> what's the criteria for being non-free or free for cuvid/cuda [18:50:31 CET] <RiCON> considering the proprietary drivers as system drivers? [18:51:01 CET] <nevcairiel> yeah the driver is usually considered system libraries [18:51:11 CET] <nevcairiel> if a driver wouldnt qualify, what would [18:51:35 CET] <RiCON> even though they're proprietary and not shipped with some distros (?) [18:51:37 CET] <BtbN> RiCON, at this point, only the CUDA SDK header. [18:51:51 CET] <nevcairiel> RiCON: thats not required for that definition [18:52:07 CET] <nevcairiel> windows is proprietary, but its still a big system library [18:52:14 CET] <RiCON> right [18:52:22 CET] <RiCON> for windows it makes sense [18:52:31 CET] <BtbN> I have a re-written implementation of that header, that gets rid of cuda/cuvid being non-free, leaving only libnpp as non-free. [18:52:52 CET] <BtbN> Need to rebase that set after those changes now probably [18:53:08 CET] <nevcairiel> i'm sure someone could construct weird arguments for not considering proprietary linux drivers as system libraries [18:53:32 CET] <BtbN> half of ffmpeg would be non-free then [18:53:43 CET] <BtbN> depending on the system it's running on [18:54:31 CET] <RiCON> making the coreaudio encdecs work with windows itunes would be non-free? [18:55:05 CET] <nevcairiel> that would probably be stretching that definition [18:56:00 CET] <cone-642> ffmpeg 03Mark Thompson 07master:03cef34aa666: ffmpeg_qsv: Fix hwaccel transcoding [19:19:46 CET] <cone-642> ffmpeg 03Andreas Cadhalpun 07master:25012c56448a: filmstripdec: correctly check image dimensions [19:55:00 CET] <BtbN> nevcairiel, scale_npp also still works. [19:55:19 CET] <nevcairiel> cool. thanks for confirming [19:55:36 CET] <BtbN> it seems unusually slow to startup though [19:55:49 CET] <BtbN> it reaches its usual speed after a short while though [21:59:42 CET] <cone-642> ffmpeg 03Mark Thompson 07master:a8d51bb42474: hwcontext_vaapi: Add driver quirks to the hwdevice [21:59:43 CET] <cone-642> ffmpeg 03Mark Thompson 07master:2dee500f4cbf: vaapi_encode: Respect driver quirks around buffer destruction [21:59:44 CET] <cone-642> ffmpeg 03Mark Thompson 07master:1a359e53418f: vf_scale_vaapi: Respect driver quirks around buffer destruction [21:59:45 CET] <cone-642> ffmpeg 03Mark Thompson 07master:8d47d8407569: hwcontext_vaapi: Try the first render node as the default DRM device [21:59:46 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:775a8477b74b: hwcontext_vaapi: add a quirk for the missing MemoryType attribute [22:03:54 CET] <jkqxz> ^ The fourth patch there makes QSV work sensibly on Linux by default without running X. The last one is needed for QSV hwcontext to work properly with a VAAPI subdevice. The first three make the last one sensible to merge. [22:08:02 CET] <nevcairiel> qsv uses vaapi hwcontext? [22:09:39 CET] <jkqxz> On Linux, yes. [22:09:51 CET] <nevcairiel> dont we have a qsv hwcontext [22:10:04 CET] <nevcairiel> or is that some sort of nested deal [22:10:21 CET] <jkqxz> It does allocation and the device management. Direct3D is used for the same purpose on Windows. [22:10:25 CET] <jkqxz> It's nested, yes. [22:32:14 CET] <cone-642> ffmpeg 03Vittorio Giovara 07master:7a745f014f52: options_table: Add aliases for color properties [22:32:15 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:bd0db4a32d85: Merge commit '7a745f014f528d1001394ae4d2f4ed1a20bf7fa2' [22:34:45 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:d2e56cf753a6: avconv: move flushing the queued frames to configure_filtergraph() [22:34:46 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:94ebf5565849: avconv: restructure sending EOF to filters [22:34:47 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:07dcef9bc7a6: Merge commit 'd2e56cf753a6c462041dee897d9d0c90f349988c' [22:34:48 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:cd47bd835a1f: Merge commit '94ebf5565849e4dc036d2ca43979571ed3736457' [22:34:49 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:e3d9bd7102be: doc/libav-merge: add skipped fixup commits to the list of missing changes [22:37:19 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:5fcae3b3f93f: hwcontext: clarify the behaviour of transfer_data() for cropped frames [22:37:20 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:fdfe01365d57: hwcontext: allocate the destination frame for the pool size [22:37:21 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:c3f113d58488: vf_hwdownload: allocate the destination frame for the pool size [22:37:22 CET] <cone-642> ffmpeg 03Mark Thompson 07master:f62bb216ac4c: hwcontext_vaapi: allow transfers to/from any size of sw frame [22:37:23 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:72c38dd66e52: Merge commit '5fcae3b3f93fd02b3d1e009b9d9b17410fca9498' [22:37:24 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:7071924cf230: Merge commit 'fdfe01365d579189d9a55b3741dba2ac46eb1df8' [22:37:25 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:1f8e1c209db2: Merge commit 'c3f113d58488df7594a489bdbb993a69ad47063c' [22:37:26 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:3aa7b0a27326: Merge commit 'f62bb216ac4cfbbff16108c6bac35a0282532972' [22:38:59 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:c67594a2c7fd: qsvdec_hevc: fix a variable name [22:39:00 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:eccfb9778ae9: qsvdec_hevc: add the UID of the HEVC HW decoder plugin [22:39:02 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:a478ae39388b: Merge commit 'c67594a2c7fd4381e6d44246b18487c7e6b75f02' [22:39:03 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:fb40daa7f3b8: Merge commit 'eccfb9778ae939764d17457f34338d140832d9e1' [22:58:00 CET] <cone-642> ffmpeg 03Martin Storsjö 07master:785c25443b56: movenc: Apply offsets on timestamps when peeking into interleaving queues [22:58:01 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:8fad4b4e251b: Merge commit '785c25443b56adb6dbbb78d68cccbd9bd4a42e05' [22:59:55 CET] <cone-642> ffmpeg 03Martin Storsjö 07master:82b7525173f2: Add an OpenH264 decoder wrapper [22:59:56 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:b2554e61e0ba: Merge commit '82b7525173f20702a8cbc26ebedbf4b69b8fecec' [23:00:23 CET] <nevcairiel> so many noops [23:00:26 CET] <cone-642> ffmpeg 03Martin Storsjö 07master:e57de6faa1e7: checkasm: h264dsp: Initialize the padding area [23:00:27 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:af8b174711f3: Merge commit 'e57de6faa1e796099091c9af947d4755edacccaf' [23:02:47 CET] <cone-642> ffmpeg 03Martin Storsjö 07master:e48746deec48: checkasm: h264dsp: Move the x and y variables into the randomize_buffer macro [23:02:48 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:f75035b06f4b: Merge commit 'e48746deec48e9ff195841bc3266b4e153a878cd' [23:23:29 CET] <nevcairiel> jamrial_: why do i foresee a big argument why extra indirections are so bad that we will never get rid of the private-public fields :d [23:27:53 CET] <jamrial_> nevcairiel: heh [23:39:49 CET] <jya> anyone know of a source for h264 4k 60fps videos? [23:41:15 CET] <nevcairiel> i have a couple 50 fps [23:41:48 CET] <nevcairiel> and one 120 [23:41:49 CET] <nevcairiel> :D [23:43:53 CET] <DHE> there's always the Big Buck Bunny videos. 4k 60fps (according to the download page) [23:45:20 CET] <nevcairiel> oh right they released a high frame rate render [23:45:40 CET] <jamrial_> testsrc2 + x264 :p [23:45:47 CET] <nevcairiel> that works too [00:00:00 CET] --- Mon Nov 14 2016

1 0

ffmpeg.log.20161113
by burek 14 Nov '16

14 Nov '16

[01:59:28 CET] <llamapixel> Can ffmpeg link a file from the web before performing an action like saving it as another format. refernce links appreciated if possible. wget / curl has to be added to the mix? [02:00:49 CET] <DHE> ffmpeg can accept http URLs, though it may be best to save to disk with wget/curl anyway [02:01:33 CET] <llamapixel> thanks [02:07:47 CET] Action: llamapixel discovered youtube-dl instead of wget or curl , thanks again DHE. Now I can save tutorials to my local drives. [02:09:15 CET] <DHE> oh, should have mentioned you were using youtube. I would have mentioned that [02:10:10 CET] <llamapixel> np, just needed a nudge mate [05:50:35 CET] <t4nk866> I use this command to stream a single image [05:50:37 CET] <t4nk866> ffmpeg -loop 1 -i hell.png -r 10 -vcodec mpeg4 -f mpegts udp://127.0.0.1:1234 [05:50:50 CET] <t4nk866> but if I make changes to the image, it doesnt appear in stream [05:51:01 CET] <t4nk866> Is there a way to force a reload? [06:12:02 CET] <klaxa> <klaxa> does something like this work? (while true; cat image.gif; done) | ffmpeg -f image2pipe -i - <stuff> ? [06:12:13 CET] <klaxa> t4nk866: ^ [09:09:12 CET] <Nati323> hey someone here? [09:09:27 CET] <Nati323> Which input formats ffmpeg support? [09:13:18 CET] <durandal_1707> pixel or file data? [09:34:08 CET] <Nati323> @durandal_1707 I send you private [14:35:09 CET] <Bombo> hi [14:50:44 CET] <Bombo> i got a feature request: m3u8 as input ;) this would be cool: ffmpeg -i https://zdfvodnone-vh.akamaihd.net/i/meta-files/zdf/smil/m3u8/300/16/11/161… -c copy grab.mp4 [14:55:41 CET] <kerio> ...doesn't that work [14:55:45 CET] <JEEB> HLS as input should work [14:55:50 CET] <furq> yeah that's worked for ages [14:55:57 CET] <JEEB> the only issue there might be if you don't have a TLS library linked in [14:56:05 CET] <JEEB> in which case nothing through HTTPS works [14:56:16 CET] <JEEB> also depending on your version you might have to insert BSFs manually [15:21:59 CET] <Bombo> oh it really works, i didn't even try https:// sorry ;) i just tried -i master.m3u8 [15:22:11 CET] <JEEB> lol [15:22:46 CET] <Bombo> what does aac_adtstoasc do actually? [15:24:02 CET] <furq> https://www.ffmpeg.org/ffmpeg-bitstream-filters.html#aac_005fadtstoasc [15:25:01 CET] <Bombo> ok thx [16:14:23 CET] <Threads> Bombo that video is on youtube if you want something higher https://www.youtube.com/watch?v=GZc8tBtIDhI [16:18:10 CET] <bens218> hello [16:18:41 CET] <Bombo> Threads: yes i know [16:18:45 CET] <Bombo> thx [16:22:17 CET] <bens218> i'm trying to come up with a way to transcode my FLAC music to either mp3 or aac but my sources all have different sample rates [16:22:43 CET] <bens218> i know aac can handle higher sample rates than mp3 can, but not the player that i'm using [16:23:24 CET] <bens218> is there a way to resample with ffmpeg to use half of the existing sample rate? [16:23:45 CET] <bens218> for example 96000 > 48000 and 88200 > 44100 [16:32:46 CET] <Threads> -ar is your friend [16:32:59 CET] <Threads> -ar 48000 [16:33:01 CET] <bens218> yea, but that sets a specific rate [16:33:18 CET] <bens218> which would do 88.2 > 48000 which will work but isn't ideal [16:41:34 CET] <Bombo> you want maths like -vf scale for video? like e.g. oar=iar/2, i don't think that exists, so you would need to get the inputrate before, with a script [16:42:06 CET] <bens218> that's what i was thinking, thanks Bombo [16:42:53 CET] <Bombo> i had a bash script that encodes audio stream just if mp2 br >192k (for dvb recordings) [16:42:59 CET] <bens218> so in theory i could use ffprobe to get the sample rate and based on that info have the script choose the correct rate [16:43:08 CET] <Bombo> right [16:43:44 CET] <Bombo> or you could hack the maths into the source somehow ;) [16:44:05 CET] <bens218> ha, seeing that i'm not good at maths for coding i think i'll pass lol [16:44:22 CET] <bens218> coming up with a script is doable for me, but will take me time [16:46:12 CET] <bens218> *or not for [16:50:42 CET] <furq> bens218: ffprobe -v error -select_streams a:0 -show_entries stream=sample_rate:stream_tags=0:stream_disposition=0 -of default=nokey=1:noprint_wrappers=1 foo.flac [16:54:27 CET] <bens218> thanks furq , always helping me out [17:28:01 CET] <t4nk007> I am building ffmpeg libraries to use in a desktop application. I want to include some 3rd party libraries as well like openjpeg. When I build the ffmpeg libraries, will all the 3rd party libs be included also? Or will I need to include both the ffmpeg libraries and the openjpeg libraries in my application? [17:28:59 CET] <furq> they'll be included if you have static openjpeg libraries and you build ffmpeg with --extra-ldflags=-static [17:35:07 CET] <t4nk007> great, thanks for your help [21:54:51 CET] <Filarius> hm, how to make video show me what is going on pixel format yuv420p ? [21:55:19 CET] <Filarius> like convert to yuv420p but use as rgb [21:55:31 CET] <Filarius> or gray [22:26:51 CET] <Dylan> Hi! I'm running Ubuntu 14.04 and I'm trying to figure out how to use ffmpeg to convert an .ogv file to something that I can drop into a video editing program. Can anyone help me walk through how to set up and use FFmpeg? [22:39:43 CET] <kepstin> what video editing program? I wouldn't be surprised if most on linux can open ogv files natively, since they usually just use ffmpeg to read the input files... [22:41:19 CET] <Dylan> Well, what I want to be able to do first is edit the audio in audacity. [22:41:38 CET] <Dylan> and I'm trying to figure out how to split the video and audio. [22:41:57 CET] <kepstin> well, that's not a video editing program, that's a completely different question. [22:42:20 CET] <Dylan> I'm recording my desktop with RecordMyDesktop, which is creating .ogv files, which audacity can't figure out how to use. I've been going through different video editing programs to see if I can demux the video. [22:42:23 CET] <kepstin> probably easiest to just use ffmpeg to pull the audio out as a wav file, like 'ffmpeg -i video.ovg audio.wav' [22:42:45 CET] <Dylan> That's the sort of thing I want to hear! [22:42:59 CET] <Dylan> I knew I was making this too complicated. [22:43:28 CET] <Dylan> Now... the next issue I'm having, is that I thought I had FFmpeg installed, but when I use the command in the Terminal, I'm told the command isn't found. [22:44:04 CET] <kepstin> hmm, ubuntu 14.04 doesn't have an ffmpeg package (they have libav instead), how did you install it? [22:44:49 CET] <Dylan> That might be my problem right there. I've been attempted to download it from the Terminal (sudo apt-get) and I think I'm getting told I already have it. [22:44:58 CET] <Dylan> Might be time for me to upgrade to 16.10? [22:45:51 CET] <kepstin> or 16.04 if you want to stick with an lts release. (16.04 has ffmpeg 2.8, 16.10 has ffmpeg 3.0) [22:46:32 CET] <Dylan> Got it. [22:46:36 CET] <Dylan> I'll start with doing that. [22:46:54 CET] <kepstin> you could also build ffmpeg yourself or use one of the static builds that are available. [22:47:28 CET] <Dylan> I'll just go with the update. I've been putting it off and now I have a reason to do it. [22:48:29 CET] <Dylan> Thanks for the help. I'll be back in if I can't figure it out after this. [22:48:49 CET] <kerio> audacity uses ffmpeg to extract audio, anyway [22:49:10 CET] <Dylan> I thought so. I was wondering why I couldn't get it to work. [22:49:49 CET] <kepstin> hmm, depends how it's built... iirc depending on the options it will sometimes only open wav, or have a limited number of native decoders? [22:50:09 CET] <kepstin> ... for some reason the audacity on my box doesn't have ffmpeg support enabled. [22:50:43 CET] <Dylan> Let's see if I can keep it simple and start by updating my Ubuntu version. [22:51:44 CET] <kepstin> the audacity in ubuntu 14.04 does not have ffmpeg support enabled, the version in 16.04 and 16.10 does have ffmpeg enabled [22:51:54 CET] <Dylan> Sweet. [22:51:54 CET] <kepstin> so after you upgrade, you can probably just open the ogv right in audacity [22:52:03 CET] <Dylan> Thanks for your help. [22:52:24 CET] <Dylan> Now if I can figure out why the Software Updater isn't opening up... [22:52:40 CET] <kepstin> oh, wait, the version of audacity in 14.04 updates does have ffmpeg (well, libav...) support enabled [22:52:47 CET] <kepstin> weird that it's not working for you [22:53:25 CET] <Dylan> Tell me about it. [22:53:37 CET] <Dylan> It drives me nuts when something I know should be really simply ends up taking me hours to figure out. [22:56:12 CET] <furq> i'm pretty sure the ffmpeg package on 14.04 is a virtual package that points to libav-tools [22:59:04 CET] <kerio> the libav situation is silly [23:01:01 CET] <Filarius> Hello. Any tip how to convert video to yuv420p pixel format AND use it like gray color space ? [23:01:54 CET] <furq> huh [23:03:12 CET] <Filarius> i want to see how yuv420p looks like ) [23:04:02 CET] <Filarius> for kind of research [23:12:46 CET] <thebombzen> Filarius: well yuv420p is a frame of Y, a frame of U, and a frame of V [23:13:13 CET] <thebombzen> most likely you'd want to output it as -pix_fmt yuv420p -c rawvideo -f rawvideo output.raw [23:13:41 CET] <thebombzen> then input it with -f rawvideo -pixel_format gray8 -i output.raw [23:14:28 CET] <thebombzen> however, since yuv420p is progressive (i.e. a frame of Y, then U, then V) you'd probably want to use a -vf select filter before previewing it [23:15:01 CET] <thebombzen> or it'll be very hard to figure out what's going on [23:18:13 CET] <furq> u and v are one quarter the size of y, so i can't imagine that will work [23:18:46 CET] <furq> i'm sure there's a filter which splits colour channels but i can't remember the name [23:20:51 CET] <furq> Filarius: https://ffmpeg.org/ffmpeg-filters.html#extractplanes [23:22:20 CET] <thebombzen> I forgot about chroma sampling [23:22:34 CET] <thebombzen> well if you want to see how yuv works you could use yuv444p and that fixes the problem of chroma subsampling [23:23:06 CET] <thebombzen> yuv420p is the same as yuv444p but the U and V are half the vertical and half the horizontal resolution [23:23:32 CET] <furq> i assume he wants to see how the subsampling works [23:23:45 CET] <furq> extractplanes should do what he wants anyway [00:00:00 CET] --- Mon Nov 14 2016

1 0

ffmpeg-devel.log.20161112
by burek 13 Nov '16

13 Nov '16

[00:51:47 CET] <cone-426> ffmpeg 03Marton Balint 07master:7b8445f03d10: tools: add loudnorm script example to use loudnorm [00:51:48 CET] <cone-426> ffmpeg 03Marton Balint 07master:005d058f4230: lavfi/loudnorm: add an internal libebur128 library [01:38:27 CET] <cone-426> ffmpeg 03Andreas Cadhalpun 07master:360bc0d90aa6: smvjpegdec: make sure cur_frame is not negative [01:38:28 CET] <cone-426> ffmpeg 03Andreas Cadhalpun 07master:484151df7c8f: pnm: limit maxval to UINT16_MAX [01:38:29 CET] <cone-426> ffmpeg 03Andreas Cadhalpun 07master:cdb5479c9ddc: pnmdec: make sure v is capped by maxval [01:45:57 CET] <nevcairiel> hours later i finally foudn the reason why cuda just wouldnt link, configure wasnt setup properly =p [01:46:16 CET] <nevcairiel> no idea how everyone else used it, probably by generating their own new import libraries without wondering why its not working? [01:51:37 CET] <philipl> BtbN: merge your dynlink changes so nevcairiel doesn't have to suffer :-) [01:52:33 CET] <nevcairiel> i fixed it [01:52:37 CET] <nevcairiel> see ml [02:04:41 CET] <philipl> jolly good [02:05:12 CET] <nevcairiel> no idea how to make it work with mingw though [02:15:45 CET] <RiCON> the import libs from the sdk work with 64-bit [02:15:53 CET] <RiCON> the one time i tried with 32-bit, not so much [02:16:04 CET] <nevcairiel> should work now with msvc [02:16:17 CET] <nevcairiel> well "now" with the ml patch [02:19:53 CET] <nevcairiel> x64 is easier since there is only one calling convention, so it cant mis-match [03:23:27 CET] <cone-426> ffmpeg 03Michael Niedermayer 07master:04bd1b38ee6b: avcodec/htmlsubtitles: Fix reading one byte beyond the array [10:16:31 CET] <cone-875> ffmpeg 03Robert Nagy 07master:c0dc9df2cc63: increment initial_prog_date_time when removing old segments [11:19:26 CET] <BtbN> nevcairiel, that's strange. I tested it with CUDA 8 on MSVC x64 plenty of times, never had any issues [11:19:35 CET] <nevcairiel> x64 is different [11:19:44 CET] <nevcairiel> it has no different calling conventions [11:19:48 CET] <nevcairiel> which is what breaks it here [11:19:53 CET] <nevcairiel> try x86 [11:25:58 CET] <BtbN> hm, I wonder if dynloading also fails then, or if GetProcAddress is smart enough to resolve the correct symbol. I never tried it on x86 [11:26:20 CET] <nevcairiel> that should be fine, i think [11:26:35 CET] <nevcairiel> since it uses the dll, and not the import library [00:00:00 CET] --- Sun Nov 13 2016

1 0

ffmpeg.log.20161112
by burek 13 Nov '16

13 Nov '16

[00:04:44 CET] <kerio> levo: ffmpeg -i yourthing.webm -c:v rawvideo -c:a copy out.mkv [00:04:53 CET] <kerio> prepare for humongous file [00:04:54 CET] <kerio> s [03:25:20 CET] <Phi> Can a giant spoon be utilised as a weapon? [03:25:37 CET] <Phi> Also, I need help getting FFMPEG to use the h264_qsv codec [03:25:47 CET] <Phi> C++ style, Windows, MSVC [04:20:57 CET] <Phi> no ideas? [05:14:21 CET] <FishPencil> Phi: You're going to need to be more specific. Massively more specific [05:16:51 CET] <Phi> I'm wearing white socks [05:16:56 CET] <Phi> white cotton [05:17:27 CET] <Phi> also I'm getting "error -40: Function not implemented", and "error initialising internal MFX structure" [05:17:38 CET] <Phi> ffplay with h264_qsv works fine [05:17:48 CET] <Phi> and the same code decodes the H264 fine with libx264 [05:18:11 CET] <Phi> the error -40 appears in avcodec_open2 on the h264 codec [05:19:15 CET] <Phi> correction, "h264_qsv : Error initializing an internal MFX session", "avcodec_open2 failed with error -40: Function not implemented." [05:19:39 CET] <dsc_> have you tried changing socks [05:19:54 CET] <Phi> I wasn't wearing socks earlier, but all that happened was I was a bit cold [05:20:00 CET] <Phi> also Trump got elected [05:20:03 CET] <Phi> is that important? [05:20:15 CET] <dsc_> what did you call my mother? [05:20:28 CET] <Phi> a trumpet [05:20:48 CET] <Phi> so tell me, about this error, how do I trumpet? [05:21:12 CET] <dsc_> videos are an illusion. they're just images played sequentially, your eyes deceive you. 80 years ago we we're still riding horses. [05:22:15 CET] <Phi> I was there when they played the first cinema film [05:22:28 CET] <Phi> there was a stampede when the film of the train was shown [05:22:30 CET] <dsc_> did you also jump away [05:22:41 CET] <dsc_> rightly so.. rightly so [05:24:05 CET] <Phi> this newfangled technology [05:24:13 CET] <Phi> back in my day the world only had two colours [05:24:24 CET] <Phi> and we walked sixteen miles over countryside to get to 'em [05:25:40 CET] <Phi> now it's YUV420P and NV12 in H264 over RTSP in a TCP tunnel and ffmpeg doesn't know how to H264 QSV properly [05:25:57 CET] <Phi> makes me nostalgic [05:26:27 CET] <dsc_> stop insulting my mother [05:26:42 CET] <dsc_> seriously though I have no idea what you're doing and I can't help you [05:26:55 CET] <Phi> seems like this channel alright XD [05:26:59 CET] <dsc_> I just use vlc_player.exe [05:27:05 CET] <dsc_> lol [05:27:11 CET] <Phi> same [05:27:16 CET] <dsc_> jokes on you for not using gstreamer [05:27:20 CET] <Phi> I tried it [05:27:25 CET] <Phi> massively bloated [05:27:29 CET] <Phi> same with OpenCV [05:27:45 CET] <Phi> at least FFMPEG can actually open network streams [05:29:14 CET] <Phi> good thing I'm paid per hour to gaze blankly at generic unhelpful ffmpeg error messages [05:30:47 CET] <dsc_> hey [05:30:55 CET] <dsc_> perhaps you can help me [05:31:55 CET] <Phi> *looks skeptical* [05:32:03 CET] <dsc_> if you wanted to generate thumbnails from a remote .mp4 you know for a fact is $some_codec, what's the most efficient way to achieve that (without generating loads of bandwidth) [05:32:22 CET] <dsc_> because in theory you'd only need the MOOV ATOM and some keyframes right? RIGHT??? RIGHT. [05:32:33 CET] <Phi> um [05:32:38 CET] <Phi> have you tried turning it off and back on again [05:32:48 CET] <dsc_> yes [05:32:52 CET] <Phi> is it plugged in? [05:33:04 CET] <Phi> if so I'm lost [05:33:09 CET] <dsc_> stop insulting my mother [05:33:17 CET] <Phi> you have too many mothers [05:33:22 CET] <dsc_> :( yes [05:33:48 CET] <Phi> same-sex marriage [05:33:53 CET] <Phi> social commentary [05:34:01 CET] <dsc_> hey you're getting paid answer my question please thanks [05:34:08 CET] <Phi> did I mention trump [05:34:09 CET] <Phi> I have a very high rate [05:34:27 CET] <dsc_> you have a very high rate [05:34:47 CET] <Phi> much like your MP4s [05:34:56 CET] <dsc_> rude [05:35:20 CET] <Phi> you may be able to abuse progressive downloading [05:35:20 CET] <Phi> by specifying start/end times [05:35:43 CET] <Phi> if you pass HTTP Keep-Alive with it [05:36:04 CET] <dsc_> lets say my mp4 is not optimized for progressive downloads but the protocol (HTTP, whatever) does support seekable parameters (accept-range) [05:36:24 CET] <Phi> I don't want to say that [05:36:26 CET] <Phi> http://www.adobe.com/devnet/video/articles/mp4_movie_atom.html [05:37:04 CET] <Phi> MP4 uses H264 internally, which is a mix of predictive frames and keyframes [05:37:44 CET] <Phi> you could then abuse the GP size and bitrate of all the streams, and guess at what byte start you need [05:38:17 CET] <Phi> but that's a big ask so you might be better off asking someone more experienced [05:39:12 CET] <dsc_> someone who is not experiencing "avcodec_open2 failed with error -40: Function not implemented." [05:39:15 CET] <dsc_> got it :P [05:39:33 CET] <Phi> stop insulting my mother [05:40:49 CET] <dsc_> mother not implemented [05:41:00 CET] <Phi> you'd just need to guarantee you have a keyframe in x bytes you read [05:41:12 CET] <dsc_> yeah that. [05:41:41 CET] <Phi> for that you'd need keyframe size and num bytes inbetween (GP size tells you how many keyframes are around), plus MP4 header offset [05:42:07 CET] <dsc_> what's GP size again? [05:42:19 CET] <dsc_> and with MP4 header you mean MOOV ATOM? [05:42:37 CET] <Phi> no [05:42:40 CET] <Phi> I mean start of MP4 [05:42:51 CET] <Phi> where it gives jargon about MP4 container details [05:42:55 CET] <dsc_> cool [05:43:00 CET] <Phi> e.g. "here's video/audio streams in this file" [05:43:09 CET] <dsc_> one would hope it contains information about bitrates, keyframes and such, yes. [05:43:15 CET] <Phi> GP size is something to do with number of keyframes per second [05:43:25 CET] <dsc_> cool [05:43:42 CET] <Phi> anyway, bedtime for me [05:43:45 CET] <Phi> it's nearly 5am [05:43:50 CET] <dsc_> 5:39am here [05:43:50 CET] <Phi> which means I should be paid more [05:43:55 CET] <dsc_> lol [05:43:57 CET] <dsc_> oki [05:43:58 CET] <Phi> your clock must be wrong [05:43:58 CET] <dsc_> bye [05:44:00 CET] <dsc_> no [05:44:04 CET] <dsc_> your clock is off [05:44:09 CET] <Phi> it's that Trump effect [05:44:17 CET] <dsc_> silly english people [05:45:20 CET] <Phi> at least the British didn't elect panic so much about Brexit the economy nosedived [05:45:30 CET] <Phi> also electing trump [05:45:33 CET] <Phi> also I'm tired [05:45:47 CET] <Phi> man who runs in front of car gets tired, man who runs behind car gets exhausted [12:12:30 CET] <Filarius22> I need downscale algorithm for x2 smaller what will give average of 2x2 pixels [14:18:19 CET] <Sander^home> Hi. Do anyone know if the apple's aptX sound encoding normally used with bluetooth 4.0 is lossless? it says its destinct lossless on google search, wondering what that means. [14:20:13 CET] <Sander^home> The alternative, which is AAC, is lossy. I guess thats why apple most likely did use aptX [15:01:05 CET] <fred1807> My script use this to show the resolution of video: ffprobe -v error -of csv -select_streams v:0 -show_entries stream=height,width "$i" , problem is that this is not working on a debian machine, I get error: Unrecognized option 'select_streams' . Can I calculate screen resolution of ffprobe version there is on debian wheezy ? [15:03:04 CET] <furq> fred1807: https://www.johnvansickle.com/ffmpeg/ [15:05:20 CET] <furq> i wouldn't bother with the ffmpeg in wheezy, it's ancient [15:05:25 CET] <furq> there are countries which are younger than ffmpeg 0.8 [15:05:36 CET] <vans163> Phi: But did you hear about the man who got run over by the 18 wheeler? [15:07:01 CET] <furq> https://en.wikipedia.org/wiki/South_Sudan [15:07:04 CET] <furq> this country, if you were wondering [15:15:13 CET] <fred1807> those binaries will work on wheezy? I am giving it a try [15:17:55 CET] <furq> wheezy uses linux 3.2 so it should work fine [17:07:39 CET] <Sander^home> Have anyone considered making a installer wrapper which only includes those codecs which compiles? [17:11:47 CET] <Sander^home> I've heard cmake is supposed to be pretty good at that.. and its becoming more and more popular. [17:14:33 CET] <Sander^home> Its always a struggle to remove that single codec with a repository someone had a compilation error in, becouse I wanted to include as many codecs as possible. [17:16:58 CET] <Sander^home> Alernatively, a continuisly updates known working installation from source recepie with history of previously working recepies whould be nice. [17:18:47 CET] <JEEB> what? [17:18:58 CET] <JEEB> I mean, the configure script is exactly for that [17:19:32 CET] <JEEB> also wtf is an "installer wrapper"!? [17:19:58 CET] <JEEB> also cmake has nothing to do with "installers" [17:20:12 CET] <JEEB> it's a yet another build system, with its own good and bad sides [17:21:15 CET] <Sander^home> I tend to run configure a few times to figure out which codecs I need to remove to make it compile. [17:21:29 CET] <JEEB> ... [17:22:03 CET] <JEEB> I mean, that sounds like you don't know what you want and/or you are in no control of what dependencies are installed [17:22:28 CET] <JEEB> you get 99% of all decoders and most of the internal encoders by just doing "./configure" without any parameters [17:22:47 CET] <JEEB> because most stuff is within FFmpeg and do not require 3rd party libraries [17:23:00 CET] <JEEB> then you know that you want AVC encoding with libx264 for example [17:23:12 CET] <JEEB> so you make sure your system has x264 in there in one way or another [17:23:26 CET] <JEEB> since libx264 is GPL you add `--enable-gpl --enable-libx264` [17:23:41 CET] <JEEB> and configure will tell you if you've installed your dependencies incorrectly [17:23:55 CET] <JEEB> the idea is not for the configure script to silently ignore what you specified and it cannot find [17:24:04 CET] <Sander^home> There is always a little known unknown codec library I wanted to include, which dosnt compile. [17:24:35 CET] <JEEB> "doesn't compile" in what sense [17:25:06 CET] <Sander^home> In the sense that the maintainer of that library didnt port it to the newest version of ffmpeg yet. [17:25:07 CET] <JEEB> because there's a difference in "I want it but I do not make sure it is available" and "the wrapper is broken" [17:25:12 CET] <JEEB> eh [17:25:23 CET] <JEEB> that sounds like a dependency that wants FFmpeg instead of an FFmpeg build issue [17:26:04 CET] <JEEB> for example with libx264 if x264 changed its API then it's the FFmpeg wrapper that hasn't been updated if the build breaks (generalization) [17:26:07 CET] <Sander^home> Well, its way too many diffrent codes, which makes it a big chance to get into that problem at any time. [17:26:12 CET] <JEEB> ... [17:26:59 CET] <Sander^home> cmake is the only tool I know of, which can be used as a compiler wrapper. [17:27:07 CET] <JEEB> that is bullshit [17:27:23 CET] <JEEB> this all just sounds like you don't understand (or cannot express) your issue at hand and are looking at incorrect ways of going around it [17:27:30 CET] <JEEB> you might want to think about it a bit more and explain it better [17:27:54 CET] <JEEB> I do btw agree that the build system is not perfect in FFmpeg but whatever you've said right now does not get fixed by any build system [17:28:02 CET] <JEEB> 18 [17:32:45 CET] <Sander^home> Its possible to make cmake generate the right parameters to configure for including the right codecs. [17:33:54 CET] <Sander^home> And if it fails compiling, it can remove one codec at a time. [17:34:06 CET] <JEEB> you're looking at it from the wrong side IMHO. if you really _need_ all of what you're setting to be enabled, then make sure that stuff is available. that's how usually people script this stuff [17:34:13 CET] <Sander^home> Maybe its possible with someting diffrent than cmake too.. [17:34:33 CET] <JEEB> you're talking about something that is not even build system related, plain scripting for eff's sake :P) [17:35:17 CET] <JEEB> if you are OK with building without something then you shouldn't be pushing that option to configure in the first place [17:35:40 CET] <JEEB> trying to find out what the receipient system has or doesn't have like that just doesn't make much sense :P [17:35:50 CET] <JEEB> and enabling a build without something you need [17:44:18 CET] <Sander^home> ffmpeg is pretty special as alot of distributions includes it even if the standar recepie fails, becouse it got so many diffrent optional dependencies. [17:45:13 CET] <JEEB> what you just wrote just makes no sense :P [17:45:44 CET] <Sander^home> There is always some small codec which breaks. [17:46:27 CET] <JEEB> "a lot of distributions include it, even if the standard 'recipe' fails" [17:46:37 CET] <JEEB> ^ this, does not, make sense [17:47:30 CET] <JEEB> also you are giving mixed signals whether something FFmpeg uses has had an API change and either an old or new version breaks, or if something that utilizes FFmpeg breaks. [17:48:04 CET] <Sander^home> x11 is in the same situation. require a manual compilation becouse of too many sublibraries. [17:51:02 CET] <Sander^home> cmake can be used as a testing suite, which can figure out both compile time errors and runtime errors. [17:52:40 CET] <Sander^home> configure can only do compiletime errors I belive. [17:52:44 CET] <JEEB> you're looking at the incorrect solutions for a problem you have still not explained properly [17:53:28 CET] <JEEB> because what you're saying right now for cmake is not something you can't do with the current thing :P or any other goddamn scripted thing [17:58:24 CET] <Sander^home> cmake can be used to build itself. [17:58:58 CET] <Sander^home> thats pretty rarely. [17:59:12 CET] <JEEB> "scripting language X can be used to build the interpreter for itself" [17:59:18 CET] <JEEB> no, it is not [17:59:34 CET] <furq> i don't really understand what's being proposed here but i would just like to say that i hate cmake on a deeply personal level [17:59:54 CET] <JEEB> the person just has no idea and seems to have seen some random buzzwords together with cmake [18:00:04 CET] <furq> and i think the current build system is pretty good [18:00:27 CET] <JEEB> his first idea was to iterate over configurations with cmake to build the least limited build with the stuff a system has already available (?) [18:00:34 CET] <JEEB> even though the goddamn word he then proceeds to use is "need" [18:00:42 CET] <furq> i'm not saying it's my fault that i don't understand [18:00:44 CET] <JEEB> and if you need something you usually try to make it available [18:01:00 CET] <JEEB> instead of trying to provide a build that then doesn't have what you need [18:01:17 CET] <Sander^home> There is a cmake function which can be defined, which can explain how to build any package, including cmake itself. [18:01:36 CET] <JEEB> "a function can be created that explains how a thing is compiled" [18:01:46 CET] <JEEB> that pretty much covers any scripting language [18:02:31 CET] <JEEB> seriously, please try to explain a) what your problem is b) how you are currently thinking of solving it and maybe you will finally be able to explain it so that both sides gain something from it [18:05:01 CET] <pomaranc> I don't think he knows [18:05:40 CET] <dragmore88> IPTABLES: Is there a way to tell iptables that it should ignore eth1 ? [18:06:21 CET] <dragmore88> sorry, wrong window ;) [18:06:49 CET] <Sander^home> cmake add_custom_command [18:06:59 CET] <Sander^home> I belive thats the right thing. [18:10:55 CET] <Sander^home> x11 (windows manager) have too many screencard dependencides and ffmpeg have too many media codec dependencies. Which makes them both abit hard to build. [18:11:25 CET] <Sander^home> sorry, *graphic card* [18:11:25 CET] <furq> x11 isn't a window manager [18:14:29 CET] <Sander^home> windowing system might be a better word according to wikipedia atleast;-) [18:16:36 CET] <Sander^home> X Window System [18:17:36 CET] <DHE> well, ffmpeg can have a huge number of dependencies, sure. but you can build it with very few as well. I have a headless server with ffmpeg installed. no X11, no hardware support whatsoever [18:24:57 CET] <Sander^home> Yep. and cmake is perfect for making recepies for building distribution spesific packages and at the same time havine a test to figure of if a codec does work as intended or not, so it becomes quicker for the maintainer to check if it breaks a given build or not. [18:26:03 CET] <Sander^home> *having* [18:26:47 CET] <Sander^home> The hard thing is to get the framework in place with the first test tho. [18:33:18 CET] <Sander^home> I remember it was a huge debate back in the days to take in ffmpeg in some distros becouse it did break, but they decided to do it anyway, becouse it did "break by design" with a good reputation:) I guess thats why some of the distros which is into contiues integration for building the os dosnt include ffmpeg, Ubuntu's distro spesific wrapper which is called juju might solve it for ubuntu, but not for every other distro tho. [18:36:13 CET] <Sander^home> DHE: Yep, Its pretty amazing how those dependencies and subdepencendies works:) [18:37:15 CET] <DHE> yeah. I still agree with JEEB though. if you want you can build a version of ffmpeg with video encoders supported (decode only). so I don't see what the issue is [18:37:36 CET] <DHE> if you want x264 support in ffmpeg, install x264 (dev libraries if distributed separately) and then build ffmpeg with --enable-libx264. done [18:37:58 CET] <DHE> *without video encoders [18:38:08 CET] <pomaranc> there is actually a cmake for ffmpeg with a lot of the dependecies [18:38:29 CET] <pomaranc> it creates a static build with everything inside [18:41:29 CET] <furq> what does any of this have to do with cmake [18:42:50 CET] <Sander^home> furq: well, cmake can be used to alot of diffrent things, just like awk:) [18:46:52 CET] <DHE> lots of things have lots of uses. an MCSE certificate can be used for kindling when building a campfire for example... [18:47:04 CET] <DHE> (joke) [18:47:31 CET] <markvandenborre> have there been big improvements in webm vp9 encoding between ffmpeg 3.1.x and ffmpeg 3.2.x? [18:47:45 CET] <JEEB> libvpx handles VPx encoding [18:47:47 CET] <DHE> ffmpeg uses libvpx to do the heavy lifting [18:47:50 CET] <furq> ffmpeg doesn't have a builtin vpx encoder [18:47:57 CET] <furq> too slow ;_; [18:48:06 CET] <DHE> JEEB wins [18:48:06 CET] <JEEB> so it really depends on if you also upgrade libvpx while at it [18:48:45 CET] <markvandenborre> hm, it seems like I have 1.3 on Debian stable and 1.6 on debian testing [18:48:59 CET] <markvandenborre> I'll have to look at the libvpx release notes then [18:49:08 CET] <markvandenborre> makes a really big difference at first sight [18:49:28 CET] <markvandenborre> (we want to release the fosdem.org videos for 2017 in webm too as a matter of principle) [18:50:27 CET] <markvandenborre> that's about 500 hours of talks [18:50:48 CET] <markvandenborre> so looking if this is even feasible at all [18:51:32 CET] <DHE> with an E5-2699v4 all things are possible. :) [18:53:11 CET] <JEEB> modern libvpx can be relatively OK speed-wise, but I wish google cared about rate control and bang-for-buck :) [18:54:07 CET] <JEEB> maybe the addition of non-GOOG entities with libaom will help in the future, but we will have to see [18:54:38 CET] <markvandenborre> my laptop running debian testing does multithreaded libvpx it seems [18:54:56 CET] <markvandenborre> but my testing server running debian stable (libvpx) nothing at all [18:55:29 CET] Action: markvandenborre is giving it an upgrade to debian testing (libvpx 1.6.0) [18:55:34 CET] <markvandenborre> curious about speed differences [18:56:05 CET] <JEEB> yeah, they did add some support for mt encoding [18:58:38 CET] <Sander^home> Is there a lossless sound format good for streaming? [18:59:00 CET] <JEEB> flac is being standardized for ISOBMFF so you can utilize it with MPEG-DASH [18:59:02 CET] <Sander^home> Maybe FLAC is that theese days? [18:59:18 CET] <JEEB> also of course if you are just pushing stuff through HTTP without any DASH or HLS or whatever [18:59:28 CET] <JEEB> you can just push FLAC in matroska or even in ogg, maybe :P [19:00:00 CET] <markvandenborre> JEEB: seems the main multithreading code came in libbpx 1.4.0 [19:00:06 CET] <JEEB> something like that, yes [19:00:36 CET] <JEEB> I've been poking at libvpx every now and then and so far mostly been disappointed :/ [19:01:01 CET] <JEEB> that said, I am not limited to formats that supposedly are "patented by people who are OK with people using the format without any payments under all circuimstances" [19:01:17 CET] <JEEB> (because there is no such thing as "patent-free" formats unless they're just ancient) [19:01:52 CET] <Sander^home> Wondering if bluetooth 4.0 SBC will have a free lossless format soon. [19:02:03 CET] <JEEB> (and no, libx265 hasn't really impressed me much more - at least compared to the complexity and high bitrate detail retention) [19:02:10 CET] <JEEB> (of libx264) [19:02:30 CET] <JEEB> but yes, upgrading libvpx if you are going to encode in VP9 sounds like a VeryGoodIdea [19:02:55 CET] <JEEB> at least from the initial version in debian stable you had [19:12:33 CET] <Sander^home> Is there a list of which hardware types likes x86 or arm that flac/ogg/aac compiles on? [19:13:51 CET] <BtbN> everywhere where a C compiler exists? [19:15:28 CET] <DHE> there are no mandatory ASM bits in the codecs. pure C is available everywhere [19:15:29 CET] <Sander^home> I'm thinking about os's which is made for small embedded chips [19:15:43 CET] <DHE> then cross-compile [19:17:41 CET] <furq> markvandenborre: if you have a bunch of videos then you might want to encode them in parallel [19:18:03 CET] <furq> libvpx's multithreading is a bit crap in general [19:20:49 CET] <Sander^home> DHE: any list of already working cross compiles? [19:21:17 CET] <DHE> not off the top of my head. it will depend on the chip. I'm guessing ARM. google can help you out [19:25:47 CET] <markvandenborre> furq: that's the problem... we have full day coverage that we want to split [19:26:14 CET] <markvandenborre> I'm hardly getting to 0.3x realtime on 720p content [19:26:40 CET] <Sander^home> DHE: I know raspbian (raspberry pi) did have to do a small codec elemination last time they did a release. [19:27:11 CET] <markvandenborre> that is on Atom C2750 @ 2.40GHz (4 cores/8 threads) [19:27:36 CET] <markvandenborre> these are our streaming machines [19:28:27 CET] <markvandenborre> maybe we need to cut up first indeed, as you suggest furq, then process the mp4 into webm [19:28:54 CET] <markvandenborre> only we were hoping to survive on pseudo cutting using nginx http mp4 [19:29:32 CET] <markvandenborre> ... in which case processing smaller files would not work of course [19:31:58 CET] <Sander^home> DHE: what about QNX? [19:35:09 CET] <DHE> uhh... I only have ARM and MIPS (on linux) experience at this time. [19:37:06 CET] <ElAngelo> is there any licensing on uploaded media to the bugtracker? [19:42:39 CET] <Sander^home> I belive WEBM was released to public domain, or something, anyone know which type of adaptive sound codec they are using there? [19:42:45 CET] <Sander^home> for streaming. [19:43:30 CET] <Sander^home> Some years back I belive they didnt define any. [19:43:37 CET] <furq> vorbis or opus [19:49:51 CET] <markvandenborre> any other suggestions on how to speed up webm encoding? [19:51:36 CET] <thebombzen> the problem with cmake is that it's generally awful [19:52:13 CET] <thebombzen> I tend to dislike build systems that don't use configure, make, make install [19:56:33 CET] <markvandenborre> furq (or others) [19:56:44 CET] <markvandenborre> do you know if there is anything like HLS for vp9? [19:57:36 CET] <markvandenborre> that would immediately solve much of the problem [19:58:42 CET] <furq> dash supports webm [19:58:47 CET] <Sander^home> markvandenborrie: do you know if webm is figuring out when to turn off adaptive streaming? [20:01:32 CET] <DHE> HLS officially only supports H264 and AAC... that's apple for ya [20:01:45 CET] <DHE> unless it's changed. HLS is still a draft and subject to frequent reviews [20:02:03 CET] <markvandenborre> I was mostly referring to the chunks bit [20:02:18 CET] <Sander^home> encoding is quicker when there is enough bandwith to not have adaptive streaming on, to change that without interuppion migh be a problem. [20:02:52 CET] <markvandenborre> Sander^home: not entirely sure what you mean [20:03:10 CET] <markvandenborre> the streaming machines have plenty of bandwidth [20:04:01 CET] <markvandenborre> this is more about making chunks that can be converted to webm more efficiently, then recombined (or whatever) [20:04:46 CET] <Sander^home> markvandenborre: if both endes have pleny of bandwith, you do want to have adaptive streaming off to speed up encoding. [20:05:28 CET] <markvandenborre> Sander^home: either I don't understand what you want to say very well, or you don't understand what we want to do very well [20:05:52 CET] <markvandenborre> I'm looking into possibilities to add webm as an option for the conference videos we publish [20:05:58 CET] <markvandenborre> as soon after the conference as possible [20:06:05 CET] <markvandenborre> this does not have to be live streaming [20:06:20 CET] <markvandenborre> we simply don't have the encoding to do 25 live webm streams in parallel [20:06:34 CET] <markvandenborre> s/the encoding/the encoding power/ [20:07:04 CET] <Sander^home> Becouse adaptive streaming devides one picture frame up in packages, so its possible that a recieving device with low banwith can drop packages to decide to only decode eg. 70% of one frame, just like jpg's gets abit blurry. [20:11:20 CET] <markvandenborre> Sander^home: thx for the hint [20:14:45 CET] <Sander^home> markvandenborre: if the reciving end have low cpu, then you want adaptive streaming on so a few packages can be dropped before coming to the cpu. [20:15:11 CET] <markvandenborre> there's no issue there really [20:15:41 CET] <markvandenborre> there already is mp4 for that [20:16:10 CET] <markvandenborre> this is purely about giving people who prefer free formats out of principle [20:16:18 CET] <markvandenborre> an alternative: webm [20:16:50 CET] <markvandenborre> and I'm thinking about a good and practical way to do that [20:17:08 CET] <markvandenborre> (if it can be done without piles of effort) [20:17:26 CET] <Sander^home> one format with flow control, another with adaptive streaming, thats why there is in need of two I guess. [20:17:38 CET] <Sander^home> two formats. [20:18:35 CET] <markvandenborre> we are planning to do hls and dash [20:19:01 CET] <markvandenborre> plus hopefully webm files if we can manage to [20:19:34 CET] <markvandenborre> (not webm streaming)[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C [20:20:19 CET] <furq> is there a time constraint here that's preventing you from just encoding them slowly [20:21:38 CET] <furq> also i assume there'll be someone attending fosdem who's willing to donate a few cpu hours on a beefy server [20:22:43 CET] <markvandenborre> we could throw sponsor money at it indeed, but would rather avoid that [20:23:20 CET] <markvandenborre> encoding slowly is not really an option [20:23:56 CET] <markvandenborre> as the use of those videos degrades with every day after the conference itself [20:24:52 CET] <Sander^home> thebombzen: I agree that the cmake script is abit messy, but becouse cmake also can call itself, then its possible to easy have configuration files inside each codec, which defines if it should be included or not on a condition. [20:25:47 CET] <thebombzen> Sander^home: I understand your frustration with doublechecking what works. that is, wanting to include the maximum number of codecs that work just for the sake of having the maximum number, and disabling ones you cannot make work. [20:26:05 CET] <thebombzen> but people who have that sort of idea aren't the target audience of the maintainers. [20:26:56 CET] <thebombzen> It's far more important that you satisfy the people who want extremely consistent results. [20:26:59 CET] <Sander^home> the cmake script is a one time thing to make, each codec's config file needs to be changed when something breaks. [20:27:42 CET] <thebombzen> Also, another thing is you keep saying "something breaks" but realize that if FFmpeg stops being compatible with a library after FFmpeg updates, that's not that library's fault [20:27:50 CET] <thebombzen> that's called an FFmpeg regression. In other words, it's a bug. [20:28:25 CET] <thebombzen> When that happens, submit a bug to trac with the tag "regression" and it'll probably get fixed very fast, cause regressions are high priority. [20:29:52 CET] <thebombzen> You keep saying "FFmpeg breaks all the time" but that's most likely something unstable on your end. I've discovered that in the last few years any time ffmpeg wouldn't find a library, it's because of something wrong with my system and not with the source. [20:29:57 CET] <Sander^home> there can be a cmake codec config directory with a folder for each os arc, everything outside the ffmpeg path. [20:30:26 CET] <thebombzen> Not all systems with the same OS are the same. Every system is different. [20:31:31 CET] <thebombzen> For example, Ubuntu-based systems are really weird and very different from more primitive systems [20:33:21 CET] <thebombzen> but again, people who want their builds to have the maximum possible number of external libraries whose wrappers will compile, those people are not the target audience. [20:33:45 CET] <thebombzen> it's far more important to satisfy people who know exactly what they want, and enable exactly those things, and have an increase in consistency. [20:40:13 CET] <Sander^home> thebombzen: Maybe ubuntu juju is trying to finetune parameters of a codec inside for given cpu on compiletime? [20:40:30 CET] <thebombzen> I have no idea what you just said [20:43:46 CET] <Sander^home> juju is ubuntu's spesific compile wrapper, which is something simular to cmake, but more tied into ubuntu's .deb format, for fitting together complex packages with configuration commands (instead of cmake's configuration files). [20:48:45 CET] <Sander^home> Yeah, I agree, its more important to finetune the paramerers for each invidual case. But its also nice to make it a single downloadable script to install on any distro from source. Makes it easier included in more distro's [20:50:23 CET] <furq> we already have one of those [20:50:25 CET] <furq> it's called configure [20:50:42 CET] <JEEB> which is why usually in that case that script installs dependencies as required... instead of trying to check which configure flags will happen to work on a specific machine [20:59:30 CET] <Sander^home> I guess configure dosnt "include the maximum number of codecs that work just for the sake of having the maximum number, and disabling ones you cannot make work." [21:06:19 CET] <Sander^home> thebombzen: I've submitted a few bugs earlier like that, didnt think about marking it with regression tho.. [21:08:58 CET] <Sander^home> if more people run more regression tests all the time, codec developers will probably get faster feedback on codec bugs after they submit it. [21:10:23 CET] <Sander^home> As long as making packages for several os'es is on by default. [21:13:16 CET] <Sander^home> I guess some distro's have figured that out on its own.. [21:13:33 CET] <Sander^home> raspberry pi havent yet.. [21:14:03 CET] <Sander^home> raspbian. [21:15:06 CET] <zyme> I just call them ardrino's for some reason, [21:15:46 CET] <zyme> But every time I spell check it I find that I've slaughtered it. [21:21:43 CET] <zyme> It's just a SoC made for either use by the people who made Cryix CPU's right? [21:31:18 CET] <Sander^home> Its nice as you can choose between arm avl and intel on arduino, but only run one program at a time without any os. After what I know, there is not any good instructions about if its possible to cross compile the c compiler against it, to be able to compile linux programs on it. [21:46:46 CET] <zyme> I believe there is a sdk to do exactly that, and I've been told there's also a basic Debian build avalible for it if you wan't to make an uber cheap pc out of one. [21:53:07 CET] <Sander^home> Yeah. you can use eg codebender to create c++ apps for arduino. But didnt find out how to compile programs that require c yet for it. [21:55:15 CET] <Sander^home> i'm unsure about if arduino have comparable cpu type so cross compilation can be done. [21:59:06 CET] <Sander^home> if eg raspberry's arm processor is simular enough to support cross compiling of c to arudino's simular arm processor, that could possibly work if those two arm processors is in the family. [22:02:17 CET] <furq> you don't need a similar cpu to cross compile [22:02:19 CET] <furq> that's the whole point [22:04:38 CET] <kerio> how do i start a video at a certain time? [22:04:47 CET] <kerio> i probably want to add black frames at the beginning [22:04:59 CET] <kerio> (compared to the audio) [22:05:17 CET] <Sander^home> furq: You do need a simular cpu when you want to add a new programming language on a cpu where there is no programming language. [22:17:49 CET] <Sander^home> furq: Well, the crosscompilation tools dosnt run on arduino. And to be able to get c on it, I guess it could be possible to get a working crosscompilation tool working on another arm os [22:19:21 CET] <Sander^home> I havent found good instrunctions on how to get a crosscompilation enviroment working on raspberry. [22:21:20 CET] <Sander^home> To cross compile for raspberry i've tried when it first came out. [22:21:47 CET] <Sander^home> I tried to cross compile on it too, but failed. [22:21:59 CET] <JEEB> it's nothing special. install a cross-compiler for the OS you have on it :P [22:22:17 CET] <JEEB> f.ex. if you have debian (raspbian) on it, you install the armv7 toolchain on debian [22:22:20 CET] <JEEB> done [22:30:53 CET] <Sander^home> raspbian have a selected number of packages compeard to debian. Have to check if thats available at a later point I guess:) [22:31:32 CET] <BtbN> isn't raspbian just the debian arm archives + some special RPi software? [22:32:53 CET] <JEEB> BtbN: yes [22:33:10 CET] <JEEB> Sander^home: I mean you'd be cross-compiling on another machine :P [22:33:32 CET] <JEEB> of course you can compile on the ARM thing as well [22:33:36 CET] <JEEB> but that's just slow [22:34:36 CET] <Sander^home> JEEB do you know about an arm motherboard supporting stock debian? [22:34:52 CET] <furq> the rpi [22:37:05 CET] <pprkut> Hi! I have a video file where the timestamp resets to 0 sometime during playback. I'd like to split the video according to those resets. Is there any way I can do this? [22:37:10 CET] <furq> the pi 1 is armv6 so you have to run debian armel, which is less than ideal on a hardfloat cpu [22:37:28 CET] <furq> the 2 and zero are armv7, so regular debian armhf works fine (with a custom kernel) [22:37:41 CET] <furq> and the 3 is aarch64 so that ought to work fine as well [22:38:59 CET] <Sander^home> JEEB, furq: thats right, using Debian armhf on rpi [22:41:58 CET] <Sander^home> furq, JEEB: got any details on any recepie on how to do this? [22:46:35 CET] <relaxed> Sander^home: have you seen https://www.johnvansickle.com/ffmpeg/ ? [22:52:55 CET] <Sander^home> relaxed: nice overview:) [22:56:29 CET] <Sander^home> Whould be nice with something like that for more arcs/os'es, I guess cmake is one way of streamlining it:) [22:59:50 CET] <Sander^home> If there is compiler diffrences between architectures, then a bug can occour on one cpu, but not on another. [23:11:31 CET] <Sander^home> One way of testing if there is a compiler diffrence between two types of cpu's which affects encoding quality, is to encode between two diffrent no loss formats, back and forth, if it becomes the same file on two diffrent cpu types, then the compiler on both platform is bugfree. [23:13:57 CET] <Sander^home> I guess thats only a problem for platforms with few developers. [23:16:44 CET] <Sander^home> A good way of testing if the cpu and compiler have a matching assembler interface. [23:17:08 CET] <Sander^home> FLAC is one such noloss format, is there another one? [23:23:07 CET] <Sander^home> I guess wav and flac is a good match? [23:25:15 CET] <BtbN> why not just do a full fate run? [23:38:29 CET] <Sander^home> Its a good test to see if the compiler mature enough to use in production for a new cpu family. [23:38:42 CET] <Sander^home> is mature enough* [23:38:43 CET] <Filarius22> any way to highlight keyframes (maybe graph on top of video) ? I need to check where exactly on video keyframes of X264 codec is located [23:41:01 CET] <Sander^home> Some lesser used platforms might have a few glitches which is hard to notice at first. [23:46:21 CET] <DeadSix27> Something I don't quite get, is google using a modified avc that breaks the 5.2 level and supports 8k? [23:46:22 CET] <Sander^home> Some few old but very stable embedded platforms have a few assembler bugs by design, which sometimes gets hidden by the programming language and sometimes not. [23:47:00 CET] <furq> Filarius22: -vf "drawtext=text=%{pict_type}" [23:47:16 CET] <DeadSix27> (but then again, i have barely an idea how this works anyway, just assumed that 5.2 really the upper limit here, yet the 8k one magically plays in my player despite breaking the lvl 5.2 limit) [23:48:27 CET] <GuiToris> hello! Could someone help me? I have this interesting phenomenon. If I trim a video, like $ ffmpeg -i input.mp4 -ss 00:00:10 -to 00:00:20 -c copy output.mp4 I will have a new output.mp4 video which doesn't have picture at the beginning. Why is that, and how can I avoid it? [23:52:32 CET] <DeadSix27> nvm was just a weird issue on errors, debugging it showed me x264 couldnt allocate enough memory [23:52:54 CET] <DeadSix27> (which made me realise i didnt use the 64bit version :p) [23:54:08 CET] <DeadSix27> (or better, its a warning (the profile one) but didnt display the libx264 error @normal loglevel, so i assumed that was the error, but it wasnt) [23:56:27 CET] <FishPencil> The libbluray package contains a "mpls_dump" tool that can be used to show chapter information for a mpls(m2ts) stream. It shows the chapter information in "ticks" time, such as "Time (ticks): 524280". Any idea what that unit is, or how I can get it into sec/ms? [00:00:00 CET] --- Sun Nov 13 2016

1 0

ffmpeg-devel.log.20161111
by burek 12 Nov '16

12 Nov '16

[00:04:27 CET] <kierank> wm4: hahahahaha [00:04:36 CET] <kierank> michaelni goes and proves your point [00:05:00 CET] <kierank> we deliberately don't merge our internal pixel procecssing code because it doesn't fit into ffmpeg [00:05:04 CET] <kierank> and then we get [00:05:06 CET] <kierank> "why have these changes not been submitted to ffmpeg-devel ? [00:05:06 CET] <kierank> These changes from a very quick look, look clean" [00:05:24 CET] <kierank> that repo is truly truly awul [00:05:36 CET] <kierank> but at the time was the only way we could do it [00:06:57 CET] <wm4> is this all libswscale code? well what can I say, michaelni maintains this sub-lib [00:07:05 CET] <kierank> no it's not in swscale [00:07:23 CET] <wm4> ok [00:07:26 CET] <kierank> we have 5 broadcast specific pixel formats and we convert (nearly) all combinations [00:10:20 CET] <kierank> but anyway it's going into upipe [00:10:37 CET] <kierank> note that none of these pixel formats except v210 which ffmpeg has exist in the file world [00:10:49 CET] <kierank> and only exist in a very very very niche hardware world [00:11:13 CET] <cone-065> ffmpeg 03Tom Butterworth 07master:48f0e41c3068: doc/encoders: add documentation for the Hap encoder [00:49:17 CET] <cone-065> ffmpeg 03Lou Logan 07master:872b35890395: doc/encoders: sort list into alphabetical order [00:49:31 CET] <DHE> so I made a bitstream filter, would ffmpeg be interested in it? it strips closed captions out of an H264 video stream (requires annexb format) [00:50:23 CET] <rcombs> DHE: just removes them, or exports them in some way? [00:50:48 CET] <CFS-MP3> Strip? As a subtitles guy I got chills [00:51:02 CET] <CFS-MP3> out of curiosity, what's the real life usage? [00:51:44 CET] <rcombs> yeah, does it deal with a particular problem (buggy decoders?), or just save some bandwidth? [00:51:57 CET] <rcombs> (not that saving bandwidth isn't a worthy goal, just a bit less appealing) [00:52:40 CET] <rcombs> I'd love to have a way to get captions out of an H264 stream and stick them in their own AVStream [00:54:47 CET] <CFS-MP3> what's the correct, non-hackish, way to pass data from a avfilter to avformat? Specifically what I need is to send stats generated for example from showinfo (let's say, number of each frame type) to segment so the .csv can include said stats [00:58:15 CET] <rcombs> packet side-data or metadata? [00:58:20 CET] <rcombs> erm, *frame [01:06:52 CET] <DHE> CFS-MP3: the short term goal is to troubleshoot a video player with some kind of memory leak [01:13:03 CET] <DHE> rcombs: it works on the packet itself, identifying the SEI containing subtitles and removing the NAL [01:13:41 CET] <rcombs> ah, makes sense [01:15:52 CET] <CFS-MP3> rcombs frame - such as 4000 I frames, etc [01:16:26 CET] <CFS-MP3> the need I have is more specific but this is the architectural problem I have. Other things, such as exporting to json, is trivial [01:19:17 CET] <DHE> rcombs: also the bandwidth "saved" works out to somewhere around 40 bytes per frame. so, not really worth it. [01:19:28 CET] <rcombs> yeah, figures [01:19:54 CET] <wm4> rcombs: you could it do like mpv... which feeds them back to the demuxer once the decoder gets them [01:20:15 CET] <rcombs> wm4: or parser, optimally [01:20:31 CET] <wm4> the problem is AFAIK frame rordering [01:20:35 CET] <wm4> *reordering [01:20:55 CET] <rcombs> it seems like we might need some general-purpose H264 reordering infrastructure anyway [01:21:06 CET] <rcombs> for e.g. VideoToolbox [01:22:23 CET] <rcombs> DHE: so, I'm not sure if this is really worthwhile to have as an individual filter, but it seems reasonable as a component of a general filter to make adjustments to H.264 bitstreams, or as its own if we had general-purpose infrastructure for that [01:35:24 CET] <kierank> wm4: [01:35:24 CET] <kierank> ye [01:35:25 CET] <kierank> s [01:40:25 CET] <wm4> would what rcombs suggested be reasonable? [01:40:57 CET] <rcombs> jkqxz has some relevant code laying around, I believe? [01:49:55 CET] <kierank> wm4: in a bsf probably [01:50:09 CET] <kierank> not sure if all the reordering types are easy to process though [02:07:24 CET] <DHE> it makes sense, but at this time we only have 2 h264 bitstream filters: convert to annexb, and strip CC (which as I wrote it requires annexb format) [02:16:28 CET] <jamrial> DHE: Anton wrote a bsf to extract NALs and make them available as extradata [02:17:00 CET] <jamrial> you could try extending it instead of adding a separate bsf [02:17:25 CET] <DHE> interesting... [02:17:44 CET] <DHE> well, in my situation I have the tool I need for the job that needs doing, so I'll likely stick with this for myself. we'll see about upstream merging... [02:18:15 CET] <DHE> thing is, I need to REMOVE the nals, not just examine them. my video ends up being a little bit smaller [09:41:11 CET] <nevcairiel> why is everything in ffmpeg.c working so backwards in comparison to avconv.c .. figured out one thing, and the next one is conceptually incompatible, again! [09:45:22 CET] <nevcairiel> since everything is supposed to be initialized as late as possible now, ie. filters only after the first frame is decoded, encoders after that, it now conflicts with the filter graph not knowing the audio frame size early enough because the encoder isnt open yet, and our filtering uses "push" mode for some reason that forces frames through the graph right away [09:50:01 CET] <nevcairiel> after hitting roadblock after roadblock i'm inclined to go back to the thought of skipping and re-implementing it carefully and properly later, instead of inside a merge [10:25:40 CET] <wm4> nevcairiel: huh, why would the filter code need audio frame size? [10:56:17 CET] <nevcairiel> wm4: because you can tell it how big the audio frames are supposed to be it spits out, so it can directly match the encoders requirements [10:56:47 CET] <nevcairiel> and you dont need an extra fifo in your own code [10:58:37 CET] <wm4> wat [10:58:53 CET] <wm4> afaik lavfi can't do this [10:58:59 CET] <nevcairiel> of course it can [10:59:14 CET] <nevcairiel> AVFilterLink has parameters to define min and max audio frame size [10:59:24 CET] <nevcairiel> if both are the same, its a fixed size [10:59:39 CET] <nevcairiel> and the generic lavfi code fifos the audio for you [11:00:01 CET] <nevcairiel> and buffersink has an API to set these values to user-provided data [11:02:12 CET] <wm4> not seeing such a thong, unless it's very new [11:02:20 CET] <nevcairiel> nah its old [11:02:43 CET] <nevcairiel> av_buffersink_set_frame_size controls the frame size for the buffersink [11:03:41 CET] <nevcairiel> AVFilterLink.min_samples/max_samples control the size each link can receive [11:04:34 CET] <nevcairiel> which generally makes sense, audio algorithms often have size requirements, ie. a minimum block size, soimetimes also a max [11:11:54 CET] <wm4> ah looked at buffersrc only [13:09:23 CET] <jkqxz> I'm not sure what to do with that VAAPI-VP8 patch. Backporting it to the legacy infrastructure seems like madness to me. [13:31:43 CET] <BtbN> jkqxz, it also adds new stuff which is already flagged with attribute_deprecated, which seems kinda odd [13:34:02 CET] <BtbN> jkqxz, on top of it, it's also incomplete. [13:34:10 CET] <jkqxz> That bit is just wrong, but I don't think the patch will use it anyway (it's for the old-old version, the same field in FFVAContext is also there). [13:34:20 CET] <jkqxz> Yes, it's missing the important file. [13:34:48 CET] <BtbN> Also, the modification of vp8.c/h should be moved to a seperate patch imo [13:35:37 CET] <BtbN> I tried to do the same thing a while ago [13:35:42 CET] <jkqxz> It was in the original, not sure why it's squashed. [13:35:54 CET] <BtbN> and gave up because the VP8 implementation is just crazy in VAAPI [13:36:14 CET] <BtbN> And when I tested it, it was slower than software decoding, so I didn't bother. [13:38:37 CET] <jkqxz> VP8 decode is fine, tbh (the segmentation / entropy coding state bit was a right pain to get right, but otherwise it's like every other hwaccel). [13:39:22 CET] <BtbN> the ffmpeg code is not at fault for that [13:39:30 CET] <BtbN> I had that essentialy working before as well [13:39:50 CET] <BtbN> But dropped it when it used more CPU and still got a lower framerate than plain ffmpeg software decoding. [13:40:37 CET] <jkqxz> Hmm, odd. Maybe the Intel driver sucked at the time you did it - I found it to be fine. [13:41:25 CET] <jkqxz> (That was only three months ago.) [13:45:13 CET] <jkqxz> Maybe the best thing to do would be to cherry-pick the hw_frames_ctx version now, then VP8 merges trivially. I would need to update vp9 and hevc to do it, but that's straightforward (and has to be done anyway at some point). [13:52:19 CET] <jkqxz> I suppose it depends on what time constraints the Intel person has. I was happy to wait for normal merges; if they aren't (which looks true given the encode merges send at the same time) then picking the whole series of cherries in a consistent way is surely better than weird backporting. [14:08:36 CET] <jkqxz> BtbN: wm4: Any opinion on that? I think you are the only people here with a direct interest in it. [14:09:33 CET] <BtbN> It seems only logical to add VP8 to VAAPI, and from a quick look at it, the patch generally seems fine. [14:09:46 CET] <BtbN> If it's not in the way of anything, I don't see a reason not to merge it [14:11:33 CET] <jkqxz> I was more meaning the libav merges themselves, of which this is a weird case because it's picked from something more recent and backported to an older version of the infrastructure. [14:32:15 CET] <nevcairiel> would the new infra work without the changes to ffmpeg.c for the reinit stuff? [14:34:30 CET] <jkqxz> Yes, it's independent. [14:34:56 CET] <jkqxz> (The new lavc can work with old ffmpeg, too.) [14:36:09 CET] <nevcairiel> i assume this one and the follow ups ? https://git.libav.org/?p=libav.git;a=commit;h=123ccd07c55ccf075cc5daf558123… [14:36:58 CET] <jkqxz> Yes. [14:37:34 CET] <nevcairiel> nothing really preventing you to cherry-pick a set if you want to [14:38:25 CET] <nevcairiel> in any case I should really just call t his ffmpeg/avconv set and skip the huge breaking commit, there is no sane way to simply adapt the changes in the scope of a merge either way [14:38:30 CET] <jkqxz> Is there a way to do a proper cherry-pick which will actually preserve the history? [14:41:10 CET] <jkqxz> BtbN: Does cuvid->nvenc transcode work if you use the 'format=nv12|cuda,hwupload' workaround? (For a suitable value of nv12 if it isn't that.) [14:44:14 CET] <jkqxz> nevcairiel: Yes, that's probably fair. (The qsv change won't be sufficient, but I'll work out how to fix it up afterwards to not be entirely broken.) [14:44:40 CET] <nevcairiel> our filtering infra is way too different [14:48:41 CET] <jkqxz> Adding 'format=sw_format|hw_format,hwupload' at the front of any looks-like-hw transcode path may well be enough to work in the hwcontext world. (And I will only cry a little bit about the reinit.) [14:48:49 CET] <nevcairiel> lets see if i can get cuvid working again without manual hackery in the merge stage [14:49:10 CET] <jkqxz> And *_transcode_init() should die in all cases. [14:52:38 CET] <nevcairiel> that was always a huge hack [14:57:15 CET] <jkqxz> Do just ignore qsv unless you have some important reason not to; I can do that testing and fix it up afterwards. [14:57:37 CET] <jkqxz> And thank you for all your work on this :) [14:57:39 CET] <nevcairiel> just need to grab a cuda sdk to actually see if cuvid works again [14:57:56 CET] <nevcairiel> our hwcontext_cuda.h doesnt work with the dynlink headers in the video sdk, apparently [15:07:55 CET] <wm4> jkqxz: hm so the problem is that people want to implement features, and doing it properly would require libav merges that haven't happened yet? [15:09:35 CET] <jkqxz> Not quite. The problem is that people want to pick libav merges which depend on older ones without taking the older ones. [15:10:09 CET] <jkqxz> Maybe not want. Have done, possibly without realising. [15:10:21 CET] <wm4> huh [15:10:28 CET] <wm4> that's too much for my tiny confused brain [15:17:02 CET] <jkqxz> The choice is between (a) do nothing now, wait for normal merges, possibly annoy the guy who proposed it; (b) merge the proposed backport now, trample it later; (c) cherry-pick the proper changes now. [15:20:16 CET] <wm4> (c) seems fine if it doesn't cause too much chaos [15:20:28 CET] <wm4> normally I'd say (a), but the merges are so behind [15:24:56 CET] <jamrial> the merge backlog is misleadingly bloated anyway. tons of noops [15:25:37 CET] <jamrial> like, easily 15 vp9 commits from Ronald that we already implemented years ago for example [15:25:52 CET] <wm4> heh [15:26:01 CET] <nevcairiel> after the avconv set there is a lot of easy stuff to catch up on [15:26:07 CET] <nevcairiel> its just been blocked on many complex sets [15:29:17 CET] <nevcairiel> speaking of, this branch has 3 merges of the commits leading up to the blocking merge that should be implemented properly instead of merged somehow, https://github.com/Nevcairiel/FFmpeg/commits/merge-avconv .. if anyone wants to test beyond fate [15:29:31 CET] <nevcairiel> (cuvid is still broken, w orking on that) [15:31:41 CET] <ubitux> jamrial: the "noop" are always tricky, because you have to check if there isn't any cosmetics, small fixes or whatever in these commits [15:33:42 CET] <jamrial> ubitux: yeah, but they are not blockers like codecpar, new bsf api and now this [15:33:56 CET] <ubitux> yeah, sure :) [15:34:06 CET] <jamrial> annoying, sure, but it's a matter of finding the lines with diego'd indentations and deal with them :p [16:16:39 CET] <nevcairiel> i must be dumb today, i cant get ffmpeg to link against the cuda library, no matter what combination i try, it just fails to link, even with msvc builds <.< [17:26:28 CET] <wm4> ah I know why that one happens [17:30:52 CET] <kierank> wm4: swresample? [17:33:19 CET] <wm4> actually I was wrong [17:33:33 CET] <wm4> I have no idea wtf is going on there and I'm not interested in it either [18:31:19 CET] <wm4> wasn't openssl API use supposed to be fixed in ffmpeg master? [18:33:14 CET] <wm4> libavformat/rtmpdh.c fails to compile because it accesses a field of struct DH, which is apparently opaque now [18:36:46 CET] <rcombs> huh, I also thought that was supposed to be fixed [18:39:25 CET] <wm4> rcombs: it works if you have GMP or GCRYPT enabled [18:39:59 CET] <wm4> these take priority over using openssl for crypto primitives [18:43:50 CET] <michaelni> nevcairiel, "git merge Nevcairiel/merge-avconv" fails with ./ffmpeg -i tickets//1167/j.asf test.avi [18:46:56 CET] <michaelni> https://trac.ffmpeg.org/attachment/ticket/1167/j.asf [18:47:23 CET] <nevcairiel> michaelni: thanks, i'll check later [18:47:41 CET] <michaelni> np, also please ping me when theres a new revission to test [20:21:18 CET] <jkqxz> nevcairiel: I get <http://sprunge.us/acDe> as another small timing change. [20:21:54 CET] <nevcairiel> on fate? how odd [20:23:12 CET] <nevcairiel> oh thats probably the one that uses iconv, i dont have that on windows [20:26:30 CET] <jkqxz> That would do it. Do you want me to do anything, or shall I just leave it with you? [20:26:45 CET] <nevcairiel> nah its fine, i have a dev linux box anyway [20:27:35 CET] <jkqxz> Ok, sure. I'm going to look at vaapi and qsv next. [20:27:50 CET] <nevcairiel> qsv is definitely broke [20:27:50 CET] <nevcairiel> :D [20:30:39 CET] <nevcairiel> i wonder if it shouldnt skip the commit with the timing changes as well, its rather directly related to the one i'm skipping anyway and will need changes in the future when its re-implemented [20:31:01 CET] <nevcairiel> which might make it cleaner to avoid that mess [20:43:02 CET] <jkqxz> It is completely separable, so sure? [20:43:13 CET] <jkqxz> I don't see that it matters much, though. [20:44:04 CET] <nevcairiel> its probably fine either way [00:00:00 CET] --- Sat Nov 12 2016

1 0

ffmpeg.log.20161111
by burek 12 Nov '16

12 Nov '16

[00:10:43 CET] <FishPencil> Is it possible to get the duration of a media file in milliseconds? [00:12:57 CET] <bens218> thanks again furq [00:13:08 CET] <bens218> i'll try it out and see how it works [00:16:12 CET] <llogan> FishPencil: not that I know of. you can convert it yourself though. [00:16:30 CET] <llogan> ffprobe -loglevel error -show_entries format=duration -of default=nw=1:nk=1 input.foo [00:16:41 CET] <llogan> or stream=duration [00:48:14 CET] <FishPencil> llogan: Thanks I'll work with that [00:49:06 CET] <FishPencil> When including subtitles, the first one is automatically enabled when playing back. How could I include them, but default to the "forced" subtitles? [00:50:24 CET] <FishPencil> The subtitles are in format "hdmv_pgs_subtitle" and I'm -c:s copy ing them [00:51:30 CET] <c_14> FishPencil: -disposition:1 default -disposition:0 0 [00:51:32 CET] <c_14> something like that [00:52:29 CET] <c_14> Where 1 and 0 are stream ids for the output stream you want default/not default [00:52:48 CET] <c_14> so -disposition:s:0 for example [00:52:55 CET] <c_14> (why isn't this documented...) [00:53:44 CET] <FishPencil> c_14: I've had a lot of fun figuring out chapter information and subtitle information. [00:53:53 CET] <llogan> c_14: was just about to say, "this option needs to be documented" [00:54:14 CET] Action: c_14 is working out if that's how it actually works and will submit a patch [00:54:23 CET] <llogan> thanks [00:54:32 CET] <FishPencil> I can test [00:56:34 CET] <c_14> It does appear to work like that [00:56:51 CET] <bens218> time to go home. thanks again for the help furq. i'll try your method tonight when i get free time. [00:59:08 CET] <FishPencil> c_14: It does appear to select to overall track (the language), but not forced. http://i.imgur.com/SIQsCLw.png [00:59:43 CET] <FishPencil> And -disposition:3 0 -disposition:4 0 does not set it to "No subtitles" [01:00:13 CET] <c_14> FishPencil: can you upload the contents of ffprobe on that file to a pastebin service? [01:02:26 CET] <FishPencil> c_14: https://paste.ubuntu.com/23458680/ [01:03:13 CET] <c_14> None of those streams are marked as default (according to that output) [01:04:58 CET] <FishPencil> c_14: Playing from the source using MPC-HC (which uses libbluray as well I believe) results in http://i.imgur.com/OVw7y9G.png [01:05:33 CET] <c_14> I think the disposition is printed (in more detail) with -show_frames as an option to ffprobe [01:06:19 CET] <c_14> eh [01:06:25 CET] <c_14> no, -show_streams [01:06:30 CET] <c_14> Getting confused [01:07:28 CET] <FishPencil> c_14: https://paste.ubuntu.com/23458696/ [01:08:06 CET] <c_14> Both of those have DISPOSITION:default=0 [01:08:19 CET] <c_14> so it should be off [01:09:20 CET] <FishPencil> I'm pretty certain there is a lot of info getting lost from libbluray->libav* [01:09:40 CET] <FishPencil> For example, chapter information is missing. [01:11:34 CET] <FishPencil> https://trac.ffmpeg.org/ticket/3953 [01:11:40 CET] <TheXzoron> https://wiki.freebsd.org/WacomTablet this article apears to be outdated as input-wacom doesn't exist [01:12:00 CET] <furq> i think you're looking for #freebsd [01:12:10 CET] <TheXzoron> yes [01:12:12 CET] <TheXzoron> sorry [01:19:55 CET] <c_14> FishPencil: what's your output format? [01:20:06 CET] <FishPencil> c_14: mkv [01:20:32 CET] <c_14> And setting the disposition for that isn't working? [01:23:09 CET] <FishPencil> c_14: what do you mean by working? I can use it to set a "default" subtitle stream, which does work, but I cannot: select the "forced" stream, or select no stream by using -disposition:3 0 -disposition:4 0 [01:24:32 CET] <c_14> Yeah, I just noticed you can't set no default stream either. [01:24:41 CET] <c_14> But you can't set the forced stream as default? [01:27:25 CET] <FishPencil> c_14: No. Something tells me the subtitle format has some sort of flag for forced subs that MPC-HC is able to pick up on, but VLC and FFmpeg cannot. FFmpeg only sees two subtitle steams in the input, whereas MPC-HC is giving me three (forced being one). [01:29:34 CET] <c_14> hmm, ok. Yeah it's probably missing something then [01:30:43 CET] <FishPencil> c_14: It might also be that if I was able to set no default subtitle stream that MPC-HC would select forced, also achieving the same goal. [01:31:07 CET] <c_14> Either way, it's probably a deficiency in ffmpeg and worthy of a ticket on trac (if there isn't already one). [01:32:57 CET] <FishPencil> I'll take a look at the code to see if I can figure it out. I'm guessing this isn't mkv specific? [01:33:40 CET] <c_14> Probably not (getting similar things with mp4 at least in regards to setting no default stream) [01:36:24 CET] <c_14> FishPencil: https://trac.ffmpeg.org/ticket/2402 probably related [01:43:51 CET] <FishPencil> c_14: Nice find, I'll use that as a starting point. [02:33:02 CET] <kurufu> Maybe someone can point me in the right direction, when using libav I want to demux rtsp wth the "-rtsp_flags listen", so I should be trying to set "listen" in the AVDictionary in avformat_open_input or where should I be looking for setting these demuxer specific flags/settings [02:33:20 CET] <kurufu> Im pretty much entirely new to working with libav, so sorry if im looking in completely the wrong place. [02:38:59 CET] <kurufu> Oooh Mailing list archives sure are a blessing. Looks like I was right. Setting the rtsp options can be done through the AVDictionary parameter. [02:47:19 CET] <DHE> kurufu: loosely speaking any leftover parameters on ffmpeg's command-line go into the AVDictionary of the encoder, container, and so on. [06:00:20 CET] <Ertain> I have built ffmpeg and installed it to a specific directory on my computer. I then built the MLT libraries and installed them on my computer. Now I have one binary, melt, which, for some odd reason, is not linked with the right file. And I haven't a clue why. [11:09:41 CET] <SouLShocK> occasionally ffmpeg 3.2 will generate corrupt mp4 files. when I try to decode them with "ffmpeg -xerror -i file.mp4 -f null -" they will say [aac @ 0000000000980280] channel element 0.0 is not allocated [11:13:15 CET] <SouLShocK> http://pastebin.com/SDfBD0Wz [11:14:39 CET] <BtbN> sounds like it wasn't allowed to finish writing that mp4, so it's broken. [11:14:48 CET] <BtbN> [mov,mp4,m4a,3gp,3g2,mj2 @ 00000000008724a0] Found duplicated MOOV Atom. Skipped it [11:15:22 CET] <BtbN> writing to a network drive sounds like a good reason for that to randomly fail [11:43:22 CET] <SouLShocK> but the first pass says it exited correctly? [11:48:36 CET] <SouLShocK> does that mean that I can't really count on the exit code from ffmpeg? [15:22:32 CET] <pgorley> is this page out of date: https://trac.ffmpeg.org/wiki/HWAccelIntro [15:22:52 CET] <pgorley> it says vaapi decoding is not supported, but hasn't this been implemented a while ago? [15:24:02 CET] <jkqxz> There is no standalone vaapi decoder, it attaches to the normal decoder as a hwaccel. [15:24:18 CET] <pgorley> oh, thanks [15:27:07 CET] <jkqxz> The real hwaccels (dxva, d3d, vaapi, vdpau) are more general and have better support (including transparent software fallback) than the things which require a specific full decoder and then have a dummy hwaccel to attach to it (cuvid, qsv, mediacodec). [15:29:32 CET] <jkqxz> I.e. hwaccel = Y, decoder = N is the "best" case in that table. The page could be clearer about the differences. [15:33:21 CET] <pgorley> that explains it, and yes, it should be clearer [15:44:59 CET] <nyuszika7h> is there a way to take exactly 3 snapshots at specific positions from a file with one command? [15:45:42 CET] <nyuszika7h> ffmpeg -ss 10:00 -i in.mkv -vframes 1 thumb01.png - I want e.g. two more at 20:00 at 30:00, but it won't always be the same time because the snapshot may turn out to be blurry or something in which case I have to change it [16:06:37 CET] <pgorley> is using vdpau on a system with only vaapi support that inefficient? decoding 100 frames takes 2 seconds longer on average than using software decoding... [16:55:55 CET] <c_14> nyuszika7h: ffmpeg -ss 10:00 -i in.mkv -frames:v 1 out.png -ss 10:00 -frames:v 1 out1.png -ss 20:00 out2.png [17:24:12 CET] <ozette> when i google for 'ffmpeg resample' it's like i only find results related to audio, not about resampling video streams. is there a reason for that? [17:25:09 CET] <ozette> only 'ffmpeg resize' will find image (video) stuff [17:26:38 CET] <SchrodingersScat> what is resample? [17:28:35 CET] <ozette> to resample a data signal [17:33:18 CET] <kurufu> well are you trying to work on a video or audio? [17:33:31 CET] <kurufu> Resampling a video is in essence, resizing it. [17:37:07 CET] <ozette> yea, but it's hard to find sources which atually all it resampling [17:37:15 CET] <ozette> call [17:37:46 CET] <ozette> and i wonder why that is [17:38:49 CET] <ozette> even the ffmpeg docs only mention audio [17:39:58 CET] <ozette> so, why is changing ar called resampling, but changing video size called rescaling or resizing [17:41:54 CET] <furq> probably because libswresample is for audio and libswscale is for video [17:42:01 CET] <furq> at least in the context of ffmpeg [17:42:17 CET] <ozette> i see [17:43:13 CET] <ozette> yea, because generally searching for 'video resampling' does provide expected info [17:43:33 CET] <ozette> but 'ffmpeg resampling' (only) provides audio [17:45:35 CET] <ozette> mystery solved, i think [18:08:26 CET] <flappy> hey, anyone got an idea on how to pixelate a video even more than dropping overall bitrate to 80k and scaling to 240p [18:12:28 CET] <DHE> could just use -qp 50 (for h264) [18:12:58 CET] <furq> you could drop the bitrate to 80k and scale it to 1080p [18:25:52 CET] <flappy> rescaling it to 1080 with -b 80k now [18:35:06 CET] <flappy> oh that last mangling broke the file heh [18:53:38 CET] <mrechte> Hello. Trying to publish an HD video on youtube / vimeo or dailymotion gives an horrendous result (pixelization), whereas it looks pretty good on my PC. I used: ffmpeg -i ../$1.avi -codec:v libx264 -crf 21 -bf 2 -flags +cgop -pix_fmt yuv420p -codec:a aac -strict -2 -b:a 384k -r:a 48000 -movflags faststart $1.mp4 to encode it. An extract is here : https://www.youtube.com/watch?v=pkwVe4cBKvk Thanks [18:57:30 CET] <furq> mrechte: what's the source [18:57:40 CET] <furq> if it's small enough to upload then just upload that, youtube will reencode it anyway [18:58:40 CET] <nyuszika7h> c_14: oh thanks [18:58:59 CET] <nyuszika7h> I assume there should be a "-frames:v 1" before out2.png as well? [18:59:56 CET] <furq> nyuszika7h: yes [19:00:19 CET] <c_14> yep, just forgot it [19:01:19 CET] <mrechte> furq: The source is another blender avi/h264 encoded file with "lossless output selected": Stream #0:0: Video: h264 (High 4:4:4 Predictive) (H264 / 0x34363248), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 295235 kb/s, 30 fps, 30 tbr, 30 tbn, 60 tbc [19:01:49 CET] <nyuszika7h> (why would you put H.264 video in .avi? you can, but usually .mp4 or .mkv is used for that) [19:02:51 CET] <furq> i guess that is probably too big to upload then [19:03:49 CET] <mrechte> nyuszika7h: Not very sure. I followed a tutorial on how to encode from blender to youtube (actually it is using handbrake to do the final conversion) [19:05:07 CET] <furq> i wonder if disabling psy and aq would help minimise generation loss [19:05:08 CET] <mrechte> furq: this what I uploaded: Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 36962 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default) [19:05:33 CET] <furq> well yeah youtube's 1080p is about 4mbit [19:05:43 CET] <furq> going from 36mbit to 4mbit is probably going to look bad [19:06:15 CET] <furq> assuming it is actually 36mbit and that's not just ffprobe going crazy [19:07:21 CET] <furq> if you have enough upload then youtube will process the source just fine [19:07:42 CET] <furq> and it should look at least a bit nicer [19:08:33 CET] <mrechte> furq: do you mean I should increase -crf ? and what do you mean by enough upload ? [19:08:52 CET] <furq> enough upload bandwidth to make it viable to upload your source file [19:09:50 CET] <mrechte> furq: I uploaded the video, but the result is not acceptable [19:10:14 CET] <DHE> if the source is lossless, than 36 megabits seems pretty good [19:10:30 CET] <furq> is that the source or the one you reencoded with ffmpeg [19:10:31 CET] <DHE> lower CRF is better quality, with 0 being (close to) lossless [19:13:12 CET] <mrechte> No the source was encoded with blender (probably throug ffmpeg). Then I encoded with ffmpeg cli with above mentioned parameters. That final encoded file looks quite OK on my computer but the uploaded version (I mean after being published by YT and watched online) looks ugly. [19:14:05 CET] <DHE> youtube can take a while to encode all variants. you're sure you were watching the 1080p version? [19:14:20 CET] <DHE> once uploading is finished there might only be a 480p version at that exact instance [19:14:31 CET] <furq> the 720p version looks really bad [19:14:31 CET] <mrechte> Yes: https://www.youtube.com/watch?v=pkwVe4cBKvk [19:14:44 CET] <mrechte> same on vimeo: https://vimeo.com/191156496 [19:15:10 CET] <furq> upload the avi if you can [19:15:21 CET] <mrechte> and dailymotion: http://www.dailymotion.com/video/x51mynu [19:15:33 CET] <furq> how much of that is generation loss and how much is bit starvation i don't know [19:15:38 CET] <DHE> weird, youtube's only giving me 720p but I see a 1080p variant with youtube-dl... [19:15:42 CET] <furq> but if you can eliminate the former then you should [19:16:19 CET] <furq> generally the only reason to reencode before uploading to youtube is if it would take forever to upload the original [19:16:30 CET] <mrechte> AVI is 5.7 GB for 3 minutes ! [19:16:42 CET] <furq> (or your video is hevc, interlaced, etc) [19:17:20 CET] <DHE> well, vimeo makes a ~30 megabyte video for a 6 second segment.. which is also crazy high [19:17:32 CET] <DHE> oh wait, that's the original [19:18:40 CET] <mrechte> Yes 30MB is the size of the file I upload for this test [19:19:00 CET] <DHE> I have to say vimeo does look better by a little bit.. [19:20:50 CET] <mrechte> I am uploading the file to an ftp site [19:21:21 CET] <DHE> well we have the 6 second 30MB file. vimeo offers it straight up [19:27:13 CET] <mrechte> But it looks completely different when watched from their site ! [19:28:03 CET] <DHE> yes, likely because the crazy high bitrate isn't served to users by default. with tools like youtube-dl you can force the variant of your choosing and save it to disk [19:32:45 CET] <FishPencil> What is the fastest way to encode 4 videos? One after another? Two at a time? All 4 at a time? Assuming all conversions use all cores/threads [19:32:54 CET] <mrechte> Published as is here: http://mrechte.free.fr/tmp/0000-0200%28ffmpeg%29.mp4 [19:33:06 CET] <furq> probably all four at a time because then you only have to decode it once [19:33:20 CET] <furq> also using multiple cores doesn't scale linearly [19:33:36 CET] <DHE> if it's the same video 4 different ways, yeah do them all in one shot [19:33:38 CET] <FishPencil> furq: Huh? These are four different input [19:33:39 CET] <FishPencil> s [19:33:45 CET] <furq> oh [19:33:57 CET] <furq> i guess you'll have to benchmark it then [19:34:27 CET] <DHE> too many at a time might be bad for CPU cache, but more than 1 might ensure better CPU utilization [19:35:01 CET] <FishPencil> That was my thought. Without benchmarking it myself I was curious if this was known [19:35:03 CET] <furq> it'll depend on a lot of factors [19:35:22 CET] <furq> e.g. if you're using an encoder with weak multithreading like libvpx then parallel jobs will definitely be faster [19:35:36 CET] <DHE> I have major multi-core CPUs (20 cores + hyperthreading). utilizing all cores doesn't really happen. here there's advantages. [19:35:52 CET] <FishPencil> All four use prettymuch the same encoding settings. x264 and Opus [19:36:28 CET] <furq> i doubt it'll be a big difference either way [19:39:53 CET] <damarusama> I have a mp4 that doesn't play in quicktime, I want to change it with -pix_fmt yuv420p [19:40:25 CET] <damarusama> not sure how to go about it, ffmpeg this.mp4 -pix_gmt yuv420 that.mp4 doesn't work [19:40:43 CET] <damarusama> Output file #0 does not contain any stream [19:40:49 CET] <sstangl> I have a 6GB video file that sometimes contains images of an Excel spreadsheet. I'm looking at using ffmpeg-filters to detect those spreadsheet images, and output jpg. But I can't figure out how to isolate them. They tend to be green in the top-left corner, is there expr syntax where I could select on pixel color? [19:43:38 CET] <FishPencil> sstangl: That's an interesting one [19:43:42 CET] <DHE> damarusama: read the manual. you put "-i" in front of input videos [19:44:09 CET] <damarusama> ._. ho... thanks [19:44:41 CET] <damarusama> it's just that I can't read... [19:44:52 CET] <DHE> also it's going to get a lot more complicated than that. you will need to specify some encoding parameters because there aren't really defaults (or rather, the defaults aren't that good) [19:45:25 CET] <damarusama> hum, even if I'm happy with the mp4 that was created? [19:45:57 CET] <damarusama> I actually don't really understand that the -pix_fmt yuv420p does to the video (apart from making it playable in quicktime) [19:46:32 CET] <FishPencil> sstangl: I don't know if FFmpeg can do this all in one go. You may need to extract the images to process them later [19:47:15 CET] <sstangl> FishPencil: I don't have enough disk space to convert all the keyframes to jpg at once, but if I process them as they come out that would be doable. [19:47:43 CET] <damarusama> sstangl: exporting everyframe to image then using something like imagemagick with a bash script [19:47:53 CET] <damarusama> you could export all keyframe to really low quality [19:48:05 CET] <sstangl> alright, I'll try that. Thanks! [19:49:27 CET] <mrechte> I tried to reduce the bitrate (increased -crf to 32). Now the uploaded file is 10047 kb/s and 8.4MB. Quality has become worse... https://youtu.be/oLmaBxqOzvc [19:50:00 CET] <DHE> damarusama: rather than RGB, pixels are defined by brightness and two colour components. but when encoded several pixels share a single colour parameter. the numbers in yuv420 describe how it's distributed. [19:50:22 CET] <DHE> yuv420 is most common, so some decoders only support that [19:51:44 CET] <damarusama> thanks - that's quite a transfer... that makes quicktime player quite limited isn't it? [19:54:58 CET] <damarusama> DHE: so yeah the video is really mashed up after that transition - [19:56:18 CET] <damarusama> it's plays ok in vlc - but is really grainy in quicktime [20:12:49 CET] <intracube> does anyone know why ffmpeg/libmp3lame reduces the maxiumum volume of an input file when encoding? [20:13:00 CET] <intracube> ffmpeg reports "max_volume: -2.0 dB" for the source .wav [20:13:23 CET] <intracube> but "max_volume: -7.7 dB" for the final encoded video file with mp3 audio [20:22:22 CET] <mrechte> Good bye. Thanks. [20:23:26 CET] <Cheater_> Hi! Players cant start live stream untill i restart ffmpeg process. Here are settings [20:23:27 CET] <Cheater_> sudo ffmpeg \ -f video4linux2 \ -i /dev/video0 \ -filter:v "crop=250:480:195:0" \ -intra-refresh 1 \ -pix_fmt yuv420p \ -framerate 30 \ -c:v libx264 \ -preset ultrafast \ -threads 8 \ -tune zerolatency \ -analyzeduration 0 \ -an \ -s 640x480 \ -probesize 32 \ -x264opts crf=20:vbv-maxrate=12000:vbv-bufsize=100:intra-refresh=1:slice-max-size=1500:keyint=30:ref=1 \ -f [20:24:55 CET] <JEEB> 2/32 [20:42:30 CET] <mwg> hello [20:42:37 CET] <mwg> i am looking for some advice [20:43:01 CET] <mwg> i have a barex device which streams (voice) audio over a network [20:43:08 CET] <mwg> it can stream UDP or RTP [20:43:31 CET] <mwg> i can use ffmpeg to record the audio and record it to wav or mp3 [20:43:46 CET] <mwg> (it's PCM 24-bit from the device) [20:44:08 CET] <mwg> however, it only broadcasts packets when somebody presses the button on the device [20:44:35 CET] <mwg> meaning, the recording does not have the correct timing (e.g. without the pauses where there was no broadcast) [20:45:08 CET] <mwg> is there anyway to record the stream and have it capture the period when there was no broadcast? e.g. fill with silence? so that the time base for the audio is correct? [20:52:35 CET] <mwg> anyone here? [20:53:30 CET] <intracube> mwg: are you just dumping the audio or converting? [20:54:19 CET] <mwg> intracube: i'm converting to mp3 (but i can do either) [20:54:33 CET] <mwg> i'm using the following command: ffmpeg.exe -loglevel debug -y -protocol_whitelist "rtp,file,udp" -i .\foo.sdp foo.mp3 [20:54:54 CET] <intracube> mwg: this is not something I'm familiar with [20:55:02 CET] <intracube> was just looking at the documentation to see if there was something obvious [20:55:10 CET] <mwg> no worries [20:55:13 CET] <mwg> thanks [20:55:45 CET] <xeuari> hello people.. I'm looking for a way to rotate the hue linearly on a short clip, such that hue is proportional to time. Can ffmpeg do this? [20:56:03 CET] <intracube> I was wondering if it could be done indirectly by having an ffmpeg audio filter generate silence and mix this network stream in on top [20:56:16 CET] <intracube> which might be enough to coax ffmpeg to keep encoding throughout [20:56:27 CET] <intracube> I can't find such a silent filter though [20:56:40 CET] <mwg> that's a good idea [20:56:43 CET] <furq> xeuari: https://ffmpeg.org/ffmpeg-filters.html#hue [20:57:46 CET] <furq> intracube: https://ffmpeg.org/ffmpeg-filters.html#anullsrc [20:57:54 CET] <intracube> mwg: ^ :) [20:58:06 CET] <mwg> okay! [20:58:07 CET] <mwg> so [20:58:13 CET] <mwg> ...sorry for being an idiot [20:58:23 CET] <mwg> how do I record both the sdp and the filter? [20:59:20 CET] <furq> presumably something like -i foo.sdp -f lavfi -i anullsrc -filter_complex amix=inputs=2 [20:59:25 CET] <furq> whether that'll do what you want i have no idea [20:59:30 CET] <mwg> ha [20:59:33 CET] <mwg> i'll try it [20:59:37 CET] <intracube> what furq said :P [21:01:36 CET] <intracube> mwg: you might need the -re option (realtime encoding) or the anullsrc might race away as fast as your computer can process [21:01:39 CET] <xeuari> sweet! I'll have a play, thanks. Should have checked there first really :/ [21:02:22 CET] <intracube> -re goes as the very first parameter [21:02:35 CET] <mwg> okay, standby - just brew'ing ffmpeg [21:03:37 CET] <furq> -re is an input option so it'd go before -i anullsrc [21:03:42 CET] <furq> otherwise it'll apply to the wrong input [21:03:50 CET] <xeuari> Am I right to assume that the hue is an offset ie it doesn't sample the video clip? [21:07:55 CET] <xeuari> ..I'm off to find out.. good day to you *doffs cap* [21:08:19 CET] <intracube> furq: ah, yep. it depends which input you specify first [21:22:59 CET] <mwg> it might be working... [21:37:21 CET] <xeuari> hmm .. hope you will be patient with me. My hue rotation command looks like this: hue="h=360*(t/7.018)" ie go from 0 to 360 degrees across the length of the clip. But it throws invalid argument.. [21:37:39 CET] <xeuari> can anyone spot the mistake in there? [21:42:35 CET] <xeuari> I also tried radians, because that can defo deal with floats.. but same error [21:45:27 CET] <dragmore88> Is ffmpeg able to convert SRT file to DVB-TTX and mux it into a TS mux? [21:52:24 CET] <xeuari> does ffmpeg need the hue filter to be explicitly enabled or disable at build? [21:54:11 CET] <intracube> xeuari: not sure, but maybe the doublequote is in the wrong place? [21:54:29 CET] <intracube> what about either: hue=h="360*(t/7.018)" [21:54:54 CET] <intracube> or encompassing the whole video filter set: -vf "hue=h=360*(t/7.018)" [21:56:33 CET] <xeuari> I have followed the syntax in the example on the documentation to see if it works: hue="H=2*PI*t" [21:56:46 CET] <xeuari> and that didn't work .. I'll give those a go [21:57:23 CET] <xeuari> oo is -vf reuired for filtering? [21:57:34 CET] <intracube> if it's a video filter, yep [21:57:40 CET] <intracube> and hue is [21:57:57 CET] <intracube> or -filter_complex [21:58:02 CET] <intracube> but that uses a different syntax [21:58:06 CET] <xeuari> ahh!! well there's my fuckup. Nice one [21:58:28 CET] <intracube> :) [21:58:50 CET] <intracube> and at least one of the examples in the manual page encompasses the whole filter string: [21:58:59 CET] <intracube> -vf "hue=H=2*PI*t:s=sin(2*PI*t)+1" [21:59:07 CET] <intracube> which is what I'd expect [22:00:03 CET] <xeuari> yeah so would I .. certainly makes more sense [22:01:20 CET] <xeuari> Huzzah! it worked like a dream [22:01:32 CET] <intracube> nice :) [22:02:13 CET] <xeuari> ps. that was without globally quoting the string [22:03:14 CET] <intracube> yep, not always needed if there aren't unusual characters or whitespace [22:08:50 CET] <xeuari> cool cool .. reckon it'll take some time for me to figure the workings of this beast [23:11:57 CET] <levo> i have a bunch of webm files, and for all of them there are seeking problems, meaning that most of them time i can't fast forward or rewind and for the occasions I can it goes like 8 minutes forward and that's it, like there is two or three time points i can reach by fast forwarding. is there any way to fix this? [23:13:01 CET] <furq> probably not without reencoding [23:13:34 CET] <furq> you can try remuxing with -i foo.webm -c copy -map 0 bar.webm [23:14:00 CET] <DHE> hope it's not a case of huge GOPs. then you're in trouble and need to reencode it as indicated [23:14:08 CET] <furq> yeah i'm not sure what else it would be [23:14:10 CET] <DHE> well, not with that command [23:14:32 CET] <furq> it's probably worth trying to remux first though because it's basically free [23:22:22 CET] <levo> furq, DHE: it was unsuccessful. what is the fastest encoding around? i tried with -i foo.webm bar.mp4 but the speed was 1x, it's very slow for me [23:23:18 CET] <kerio> what's your hardware? [23:23:54 CET] <kerio> i think that defaults to x264 at default settings, it shouldn't be that slow [23:25:08 CET] <levo> kerio: intel Core 2 Duo, 2GHz. 2GB RAM DDR2 [23:25:22 CET] <kerio> LOL [23:25:30 CET] <levo> don't lol me :)) [23:26:06 CET] <levo> i love it btw although he's a bit old [23:26:40 CET] <kerio> old architecture tho [23:26:43 CET] <kerio> like very old [23:26:57 CET] <kerio> no wonder this super optimized stuff doesn't run that well [23:27:25 CET] <IntelRNG> I am running like that but with twice as much RAM. Show some respect to antiques. [23:28:33 CET] <kerio> levo: you could gpu it up a bit [23:28:40 CET] <kerio> either for the decoding or for the encoding [23:30:21 CET] <levo> kerio: how can i do so? [23:30:40 CET] <kerio> do you have a gpu, first of all? [23:31:29 CET] <kerio> it's usually OS-dependent [23:35:17 CET] <levo> dedicated gpu i don't think so. my graphics is one of those chipsets you can barely do anything other than watching movies with [23:35:27 CET] <kerio> then nope [23:35:42 CET] <FishPencil> Is there a "proper" way to normalize 5.1 audio? Or should I just leave it [23:35:44 CET] <furq> you can use -preset superfast [23:35:58 CET] <furq> you probably also want to keep the audio as it is [23:36:12 CET] <furq> so -i foo.webm -c:v libx264 -preset superfast -c:a copy bar.mkv [23:37:22 CET] <kerio> have you tried remuxing it tho [23:37:44 CET] <furq> i think he just said he did [23:37:44 CET] <levo> kerio: yeah, didn't work [23:37:55 CET] <kerio> try superfast yea [23:38:14 CET] <furq> there's also ultrafast but that turns a bunch of important stuff off [23:38:19 CET] <levo> furq: superfast gave me 1.9x well compared to the previous one seems better [23:38:21 CET] <furq> i wouldn't advise that unless you're really desperate [23:38:47 CET] <furq> i'm not aware of a faster encoder than x264 which gives comparable filesizes [23:39:37 CET] <kerio> ffv1? :^) [23:39:52 CET] <furq> those last four words are there for a reason [23:39:55 CET] <kerio> they're comparable in the sense that they only differ by about two orders of magnitude [23:40:03 CET] <furq> i'd also be surprised if ffv1 was faster tbh [23:40:19 CET] <furq> maybe ffvhuff would beat it [23:43:13 CET] <kerio> levo: also, why does it matter? [23:43:25 CET] <kerio> this is a thing that you'll only do once anyway [23:43:59 CET] <levo> kerio: it's a course like hours ... and files each 10minutes and so [23:44:16 CET] <kerio> how fast is your internet? [23:44:29 CET] <levo> pretty slow [23:44:34 CET] <kerio> rip [23:44:35 CET] <furq> you could upload them to something like google photos [23:44:36 CET] <levo> 512kbit [23:44:39 CET] <furq> or maybe not [23:45:05 CET] <kerio> yeah i was going to suggest some high perf ec2 instance [23:45:41 CET] <furq> google photos will transcode them all for free, but it sounds like it'd be slower than just doing it yourself [23:46:32 CET] <levo> thanks guys for your help [23:46:54 CET] <kerio> levo: is disk space an issue? [23:46:58 CET] <kerio> rawvideo is a thing [23:47:04 CET] <levo> not that much [23:47:18 CET] <levo> although the files are only 20mb max eacch [23:47:19 CET] <furq> you can try with -c:v rawvideo or -c:v ffvhuff [23:47:26 CET] <furq> the files will end up at least 10x bigger [23:47:30 CET] <furq> maybe closer to 100 [23:47:41 CET] <furq> it'll be fast though [23:48:27 CET] <kerio> incredibly snappy to seek through, too [23:49:06 CET] <levo> meaning fast? [23:49:12 CET] <kerio> yeah [23:49:30 CET] <levo> what should i set the output to? [23:49:55 CET] <kerio> are you going to watch them with mpv? [23:50:15 CET] <kerio> .mkv is a good choice [23:50:25 CET] <kerio> .nut is ffmpeg-specific [23:51:41 CET] <levo> gnome-mplayer but i got mpv too [00:00:00 CET] --- Sat Nov 12 2016

1 0

ffmpeg-devel.log.20161110
by burek 11 Nov '16

11 Nov '16

[00:35:50 CET] <cone-299> ffmpeg 03Michael Niedermayer 07master:d736b52a045c: swscale: Drop is9_OR_10BPS() use, its name is not correct [00:35:51 CET] <cone-299> ffmpeg 03Michael Niedermayer 07master:a340cfef8259: swscale/input: Fix alpha bswap for set readAlpPlanar [00:35:52 CET] <cone-299> ffmpeg 03Michael Niedermayer 07master:873d06c76ea5: swscale/output: Fix alpha shift in yuv2gbrp_full_X_c() [00:35:53 CET] <cone-299> ffmpeg 03Luca Barbato 07master:2c7d8cbd666d: swscale: Add the GBRAP12 output [00:35:54 CET] <cone-299> ffmpeg 03Michael Niedermayer 07master:b828788d58cb: swscale: Add GBRAP10 output [01:51:14 CET] <root___10> ls [02:16:35 CET] <cone-299> ffmpeg 03Luca Barbato 07master:638b216d4f54: pixfmt: Add GRAY12 [02:16:36 CET] <cone-299> ffmpeg 03Luca Barbato 07master:19be5fb7286b: swscale: Add GRAY12 [02:16:37 CET] <cone-299> ffmpeg 03Michael Niedermayer 07master:2bc66d9e4320: nut: add gray12 support [03:34:39 CET] <cone-299> ffmpeg 03Steven Liu 07master:863ebe6f83de: avformat/flvenc: add add_keyframe_index option [04:14:21 CET] <atomnuker> a whole 6% performance increase just by moving opus dequantization to a separate file [04:23:37 CET] <rcombs> wat [04:23:41 CET] <rcombs> how even [04:24:13 CET] <rcombs> preventing poor inlining decisions that made functions too big for cache? [04:26:58 CET] <Compn> or he put the stop/start timer in the wrong place :P [04:27:04 CET] <Compn> or magic i guess [08:12:54 CET] <cone-065> ffmpeg 03Carl Eugen Hoyos 07master:edb8af6e9247: lavc/hevc_ps: Use correct pix_fmt for 12bit 4:0:0. [08:24:08 CET] <cone-065> ffmpeg 03Carl Eugen Hoyos 07master:08be65a07557: lavc/hevc_ps: Fix an error message. [10:15:15 CET] <ubitux> covers extraction from mov doesn't seem to work anymore with ffmpeg cli (since mov edit list i suppose?) [10:16:38 CET] <ubitux> oh wait it's a more nasty thing [10:25:15 CET] <ubitux> i guess i'll mail him [10:32:44 CET] <ubitux> so basically there is an edit list on a h264 video stream of 1 frame, with 1 entry: media_time=0 duration=0 [10:33:12 CET] <ubitux> and so ffmpeg drops it (unless ignore_editlist is disabled) [10:34:44 CET] <wm4> lol has the editlist stuff still not been reverted [11:20:09 CET] <wm4> is copying a GetBitContext via assignment allowed? (I want to do that to read ahead without changing the position in an existing GetBitContext) [11:20:16 CET] <wm4> from the source code it looks like that should be ok [11:22:17 CET] <nevcairiel> i think thats used in various places for exactly that [11:51:30 CET] <wm4> should av_reduce(&num, &den, 1, 14112000, 1000000) really return num=0, den=1 [11:57:12 CET] <nevcairiel> not sure how strict it sees the max, there is no way it can express anything useful that would obey it [11:57:42 CET] <nevcairiel> if its a hard limit, invalid is the only reasonable reply [11:58:31 CET] <wm4> maybe so, but INT_MAX isn't a too reasonable parameter either [11:58:42 CET] <wm4> imagine you have a timebase that's close to one second, with a very minor deviation - then both num and den could be very high [11:58:54 CET] <wm4> and then multiplying the timebase with a small integer could overflow [11:58:56 CET] <nevcairiel> well if both are very high, it can reduce them [11:59:15 CET] <nevcairiel> by losing accuracy if need be [11:59:34 CET] <wm4> can it lose accuracy? if so, it could return 1/1000000 in the example above [11:59:56 CET] <nevcairiel> thats probably too much of a loss for it [12:00:40 CET] <nevcairiel> usually it would just round the fractions, so something like 11/50 can turn into 1/5 etc [12:00:41 CET] <jkqxz> It returns the nearest fraction with num and den not exceeding the max. In that case, zero is correct. [12:01:10 CET] <jkqxz> (But not necessarily what you wanted.) [12:01:46 CET] <nevcairiel> also for applying timebases to times, we have overflow safe functions for that [12:04:08 CET] <jkqxz> Yeah, all of the rescale functions are written to get the best representable approximation to the answer in the cases where it overflows. [12:16:47 CET] <atomnuker> wm4: yep, you can do whatever you want to getbitscontetxt or the buffer it writes to [12:28:56 CET] <wm4> back to edit lists, on the ML I see a post: "I've seen a lot (hundreds/thousands) of files broken like this so far." [13:36:06 CET] <kierank> is it possible to do [13:36:10 CET] <kierank> xor ebx,DWORD PTR [rsp+dx*4+0x6e20] [13:36:12 CET] <kierank> instead of [13:36:12 CET] <kierank> xor ebx,DWORD PTR [rsp+rdx*4+0x6e20] [14:44:49 CET] <Gramner> kierank: nope, you can't mix register sizes [15:20:17 CET] <kierank> Gramner: the compiler is doing [15:20:17 CET] <kierank> xor ebp,DWORD PTR [rsp+rax*4+0x4e20] [15:20:17 CET] <kierank> movzx eax,WORD PTR [rsi-0x16] [15:20:17 CET] <kierank> xor ebp,DWORD PTR [rsp+rax*4+0x5e20] [15:20:17 CET] <kierank> movzx eax,WORD PTR [rsi-0x1a] [15:20:35 CET] <kierank> but I would like to do a single larger load and instead just shift to get the right index to the table [15:29:52 CET] <wm4> what exactly happens if you read past a GetBitContext? [15:31:02 CET] <atomnuker> depends if you have --disable-safe-bitstream-reader enabled or disabled [15:31:22 CET] <wm4> is that a configure option [15:31:47 CET] <atomnuker> yep, by default its on (so the safe bitstream reader is enabled) [15:32:26 CET] <wm4> insane as usual... I thought a define (UNCHECKED_BITSTREAM_READER) controlled this [15:32:35 CET] <wm4> anyway, I'm pretty sure this uses the safe reader [15:32:43 CET] <atomnuker> yes, the configure option maps to that define [15:33:12 CET] <atomnuker> but anyway, it'll clip any reads past the end byte to the end byte [15:33:38 CET] <wm4> so what do the read functions return? 0? [15:34:07 CET] <iive> i thought that the bitstream is supposed to be padded with extra bytes. [15:34:44 CET] <cone-065> ffmpeg 03Tom Butterworth 07master:bd6fa80d56fc: avcodec/hap: add "compressor" option to Hap encoder to disable secondary compression [15:35:43 CET] <atomnuker> wm4: the read functions return the bits you attempted to read, the only way to check if you've went past the end is to call get_bits_count and compare it [15:37:15 CET] <BBB> wm4: the unchecked reader can be enabled globally (for speed) or per-decoder (if its known-safe) [15:37:37 CET] <BBB> wm4: e.g. wmavoice uses it (theres really no reason for this, it was just for fun and I did indeed confirm it had no overreads) [15:37:46 CET] <BBB> I believe mpeg also uses it, maybe cavlc/h264 also [15:37:51 CET] <wm4> yeah [17:51:26 CET] <cone-065> ffmpeg 03Sasi Inguva 07master:c8dc11bb9ef9: lavf/mov.c: Fallback to finding non-keyframe in fix_index, if keyframe search fails. [17:51:27 CET] <cone-065> ffmpeg 03Sasi Inguva 07master:18108f361838: lavc/utils.c: Make sure skip_samples never goes negative. [21:03:36 CET] <cone-065> ffmpeg 03Andreas Cadhalpun 07master:1e33035ee7a8: proresdec_lgpl: explicitly check coff[3] against slice_data_size [21:03:37 CET] <cone-065> ffmpeg 03Andreas Cadhalpun 07master:c82b8ef0e4f2: dvbsubdec: fix division by zero in compute_default_clut [21:34:21 CET] <kierank> atomnuker: LOL [21:34:40 CET] <atomnuker> wut? [21:34:53 CET] <JEEB> let me guess, you guys were doing that raw video stuff 8) [21:34:57 CET] <kierank> you wrote basically a carbon copy of what I did [21:35:16 CET] <JEEB> oh, you replied [21:35:39 CET] <atomnuker> damn, you were 8 minutes quicker :) [21:37:20 CET] <kierank> they will get nowhere trying to do it with ffmpeg rtp [21:37:31 CET] <kierank> because iirc ffmpeg rtp is in the main thread [21:37:48 CET] <JEEB> I didn't remember it was like that, but I totally wouldn't be surprised [21:38:02 CET] <kierank> there's a special thread in raw udp [21:38:03 CET] <funman> how can rtp be slow, it has real time right in the name [21:39:12 CET] <atomnuker> the same way "people's rebuplic" is really a synonym for dictatorship :) [21:39:19 CET] <JEEB> :) [21:44:23 CET] <kierank> "A solution would be to repack the samples into a compatible format, eg. [21:44:23 CET] <kierank> planar." [21:44:28 CET] <kierank> i have no idea wtf he means by that [21:44:53 CET] <kierank> is he going to try and do pixel processing in the packed domain or something? [21:44:59 CET] <JEEB> I think if that's the guy who was here a few days ago, then it means poking data around so that it's in planar YCbCr [21:45:06 CET] <JEEB> yuvXXXp [21:45:08 CET] <kierank> implement his own adder perhaps [21:45:10 CET] <kierank> yes [21:45:21 CET] <jamrial> atomnuker: there are more diplomatic ways to tell people no... [21:46:15 CET] <jamrial> your email was absurdly aggressive [21:47:08 CET] <kierank> It was a bit extreme but these people need to be told [21:53:25 CET] <llogan> it did seem quite angry [21:59:15 CET] <funman> i think he got vaccinated broadcast ^_^ [21:59:41 CET] <CFS-MP3> Anyone reading that email is going to stay away from the ffmpeg developer community and with good reason [22:00:04 CET] <CFS-MP3> And "those people" are just developers with a job, which today may be broadcast but tomorrow can be something totally different [22:00:09 CET] <kierank> it's the opposite problem, people who think ideas are nice on a whiteboard [22:00:19 CET] <kierank> but will want other people to maintain their crappy implementation [22:00:32 CET] <kierank> yes they'll bugger off somewhere else and we'll have to fix their bugs [22:00:47 CET] <kierank> and user complaints [22:01:25 CET] <CFS-MP3> well, when there's user complaints there's users, some maybe what is useless for you it's useful for someone else [22:02:12 CET] <kierank> meaningless statement [22:02:34 CET] <CFS-MP3> make read it again if you can't make meaning out of it? [22:02:36 CET] <kierank> some things remain difficult for good reason [22:02:59 CET] <CFS-MP3> Well, being civil to other developers is not difficult [22:03:02 CET] <kierank> it's not ffmpeg's job to do a poor implementation to give people the idea that what is difficult is easy [22:03:19 CET] <kierank> forcing your pet feature into ffmpeg and leaving then having others maintain it is also not difficult [22:03:54 CET] <CFS-MP3> telling someone to fuck off in the mailing list when he just offered to do something is definitely a terrible way to get good contributions in the future from that individual or anyone who just happened to subscribe [22:04:11 CET] <kierank> We've probably saved them thousands of man-hours [22:04:17 CET] <kierank> doing something they wouldn't be able to do [22:04:50 CET] <kierank> ok, maybe hundreds of man hours [22:05:12 CET] <CFS-MP3> that's not really your problem, if they want to try and can somehow figure out a way to do it, maybe even do whatever huge refactoring is needed to get it done in an elegant way why tell them not even try [22:05:28 CET] <funman> but you need to refactor the kernel [22:05:30 CET] <kierank> it is my problem, because when he leaves for his next contract someone has to fix all these bugs [22:05:33 CET] <kierank> that too [22:05:37 CET] <CFS-MP3> why underestimate the resources or cleverness of people you don't know [22:05:43 CET] <cone-065> ffmpeg 03Andreas Cadhalpun 07master:89eb398c7fc4: icodec: correctly check avio_read return value [22:05:44 CET] <kierank> or if he makes breaking changes that I have to deal with [22:06:07 CET] <funman> CFS-MP3: i used to work there [22:06:08 CET] <Compn> CFS-MP3 : kierank knows what he is talking about and he knows ffmpeg code. if he says it cant be done , i trust him [22:06:16 CET] <Compn> also i trust atomnuker abilities as well... [22:06:38 CET] <kierank> "That said some people in the community will encourage you to do it because [22:06:39 CET] <kierank> they don't understand the complexity of the problem and it is why FFmpeg is [22:06:39 CET] <kierank> full of broken things and has a bad name in the professional world." [22:06:52 CET] <Compn> if person on ML wants to do it, let him do it in his own repo, he doesnt need ffmpeg help if hes being paid to work on it [22:07:20 CET] <JEEB> CFS-MP3: I do agree that atomnuker's response was out of the line, but you could read from the e-mail that the person thought that the pixel format was the biggest problem [22:07:33 CET] <kierank> yeah proves that the person has no clue [22:08:08 CET] <CFS-MP3> kierank so what if he doesn't have a clue? You can just list of the top of your head a bunch of other bigger problems that you see but he doesn't [22:08:12 CET] <CFS-MP3> there's no need to be rude [22:08:26 CET] <kierank> had no choice after you're little escapade [22:08:31 CET] <kierank> your* [22:08:31 CET] <Compn> although i think kierank works on competing software to ffmpeg and kierank doesnt want ffmpeg to have 'broadcast' fixes :D [22:08:32 CET] Action: Compn runs [22:08:33 CET] <CFS-MP3> plus expecting people to "have a clue" when they're new to a large problem is not realistic at all [22:08:36 CET] <kierank> certain people don't listen [22:08:42 CET] <kierank> (hint: i'm talking to one now) [22:08:49 CET] <kierank> they think their way or the highway [22:08:54 CET] <kierank> in spite of complex technical problems [22:08:56 CET] <funman> Compn: ahah you haven't seen the light yet! [22:09:02 CET] <Compn> :D [22:09:16 CET] <JEEB> CFS-MP3: kierank actually posted a civil response, just fyi :P [22:09:33 CET] <wm4> nice drama, can I join [22:09:39 CET] <kierank> those guys even called me [22:09:43 CET] <kierank> and I told them not to do it [22:09:48 CET] <kierank> and then they post on the ML wanting to do it [22:10:00 CET] <kierank> and who is going to pick up the pieces of this mess in the end I wonder [22:10:04 CET] <kierank> when they break a ton of stuff [22:10:40 CET] <kierank> multimedia development doesn't take place on a whiteboard [22:10:43 CET] <kierank> this isn't node.js [22:11:13 CET] <wm4> ew advocating upipe (sounds like a nice idea but haven't heard any good about it) [22:11:22 CET] <CFS-MP3> OK, you are by definition right and no one can attempt to contribute without your OK - if you say no then it's no and nothing will change your mind [22:11:24 CET] <CFS-MP3> that's clear [22:11:29 CET] <CFS-MP3> have a nice day [22:11:43 CET] <kierank> nice straw man [22:11:44 CET] <Compn> kierank : dont scare off CFS-MP3 , we need to be friends with kodi [22:11:44 CET] <JEEB> wm4: I heard at least the timestamp fields there are nice [22:12:00 CET] <kierank> wm4: cf what I wrote in the message [22:12:15 CET] <funman> wm4: did you hear anything bad? [22:12:42 CET] <kierank> upipe is complex, sure but it's designed to solve complex multimedia problems [22:12:48 CET] <kierank> not run-of-the mill problems [22:12:54 CET] <Compn> is upipe french made ? [22:12:58 CET] Action: Compn trolls and runssss [22:13:10 CET] <wm4> funman: yes, that it's not actually good and that it's kept alive by people who were unfortunate to rely on it and now have to maintain it as part of their company's software stack [22:13:12 CET] <funman> it also solves a big lack of macros [22:13:24 CET] <funman> wm4: wow who is this? [22:13:26 CET] <kierank> wm4: eh? [22:14:00 CET] <funman> you have to be thinking of something else [22:17:35 CET] <funman> ebail: hello [22:18:19 CET] <wm4> CFS-MP3: they say that saying "no" is a maintainer's job [22:18:46 CET] <kierank> ebail: hello [22:18:49 CET] <wm4> I don't quite understand this case though [22:18:50 CET] <Compn> ebail : although there maybe insults on the replies, please dont be offended, none of the developers can speak for the whole project.... [22:19:11 CET] <wm4> must be a quite dumb protocol if it needs special kernel mechanisms for performance [22:19:20 CET] <kierank> wm4: no, it's just got a LOT of data [22:19:42 CET] <funman> ebail: i worked at sfl on sflphone (when it was still called that way :) [22:19:44 CET] <kierank> several orders of magnitude more than 99.99% of people deal with in ffmpeg [22:22:18 CET] <Compn> note that ebail only mentioned adding pixfmts to ffmpeg. possibly using ffmpeg in a chain or just the swscale in a chain somewhere... no mention of network code. [22:22:21 CET] Action: Compn runs [22:22:56 CET] <wm4> these formats don't sound like a good match for pixfmts [22:24:56 CET] <kierank> pixfmts are orthogonal to the problem [22:26:43 CET] <kierank> btw, if anyone wants anything fuzzed please let me know [22:50:23 CET] <reynaldo> some of whats going on in our mailing list shouldnt be allowed at all. The kind of behavior you see on the "TR-03 implemenation" thread can not be justified by any technical reason. No matter what [22:51:06 CET] <reynaldo> I would like to see a coordinated action to stop this for once and for all [22:54:15 CET] <wm4> can we also put a stop on low quality features once and for all [22:54:36 CET] <wm4> because at this point I'd consider such "rudeness" as necessary evil [22:55:04 CET] <kierank> Regrettable +1 [22:56:28 CET] <ebail> hi funman kierank, Compn, thanks for your comments. We will study carrefully your answers. If you have any other comments, you are welcome ;) [22:57:05 CET] <reynaldo> wm4: I am of the opinion that rudeness and violence have no place in a technical defense [22:57:15 CET] <reynaldo> I would like to think Im not the only one [22:58:43 CET] <wm4> reynaldo: the problem starts if technical concerns are completely ignored [22:58:58 CET] <wm4> which hasn't happened yet in this case, but did often in the past [22:58:59 CET] <dkc> well, if it was the third thread in two days about the same topic then maybe it would be a necessary evil [22:59:31 CET] <reynaldo> wm4: I mentioned a specific thread [22:59:41 CET] <reynaldo> please do not dilute this conversation [23:00:48 CET] <nevcairiel> Well you used terms like "for once and for all", which implies a general topic and not an isolated incident [23:00:58 CET] <reynaldo> this behavior can not be allowed from the project developers, no matter how technically gifted they are or appear [23:01:19 CET] <funman> ebail: btw does Radio Canada have specific use case yet or are they just future-proofing? [23:01:38 CET] <reynaldo> nevcairiel: might be my crude english showing up. Im refering to all the similar cases involving unprovocated and uncalled for rudeness and violence [23:04:01 CET] <reynaldo> littrle can be one about what happened in the past, we cant even "recall" the ofending parts of this thread but I would like to propose that going forward, this behavior its clearly off limits and ppl to be held accountable for it [23:04:57 CET] <ebail> thanks for your kind works reynaldo [23:05:11 CET] <ebail> *words [23:06:43 CET] <wm4> reynaldo: why is rudeness bad anyway? [23:09:17 CET] <kierank> Make FFmpeg great again [23:09:19 CET] <gnafu> wm4: In this case, the rudeness was surprisingly strong to me, and I'm one who usually doesn't mind some strong words and strong opinions. [23:10:10 CET] <funman> we're gonna put a rfc4175 pixel format in FFmpeg and we're gonna make Radio Canada pay for it [23:10:22 CET] <gnafu> funman: :-D [23:10:49 CET] <nevcairiel> Often people are just very passionate about certain topics which makes them a bit thoughtless, instead of meaning to be rude [23:12:45 CET] <gnafu> nevcairiel: I definitely saw that in this case, sure. [23:14:19 CET] <gnafu> (And to clarify: I only saw this because it was mentioned here, and I am probably the least qualified to weigh in on developer discussion etiquette.) [23:14:50 CET] <reynaldo> I dont think violence can be justified just because we think it's comming from passion [23:16:27 CET] <reynaldo> even if you dont get the human implications of this, try to see how this plays out in our interaction with other organizations [23:16:47 CET] <reynaldo> OPW, Google's GSoC, etc [23:17:32 CET] <wm4> these have been always worthless [23:17:42 CET] <reynaldo> it is bad, really bad. I think I've worked on application letter's to these programs in which we state quite clearly that we are able to thread ppl with respect [23:17:56 CET] <ssalenik> funman: to answer your question for eloi (I'm also working on this project), I think its a bit of both... but basically they think broadcasting will be moving to this new IP format and they want to explore libre software solutions to prevent them from having to invest in proprietary solutions... ffmpeg was the first choice since they already use it in other applications [23:18:26 CET] <reynaldo> wm4: again, unless I'm really not understanding you I think you are willing to justify violence on technical merits or lack thereof [23:18:48 CET] <reynaldo> I think this is a fundamental difference I cant really get across [23:19:00 CET] <kierank> ssalenik: this is too naive [23:19:04 CET] <kierank> the world is not a whiteboard [23:20:59 CET] <funman> ssalenik: https://blog.cloudflare.com/how-to-receive-a-million-packets/ [23:23:24 CET] <ssalenik> kierank: I'm not sure what you mean... we're exploring a solution which seems reasonable to us, if it turns out to not be the case, then we'll do something else [23:23:42 CET] <wm4> reynaldo: it's just another tone which some apparently don't like [23:23:48 CET] <kierank> with all due respect you don't know what you are talking about [23:24:05 CET] <kierank> you're talking to a number of people who have gone and done this [23:24:11 CET] <kierank> and who know exactly what they are doing [23:24:24 CET] <wm4> that said even "non-violent" words can make just as much negative and destructive effect on a person as "violent" words so I don't buy this sentiment [23:24:34 CET] <ebail> so please kierank, share your experience [23:24:42 CET] <ssalenik> sure, which is why we were asking for feedback about it from the community/experts [23:24:45 CET] <kierank> ebail: we explained all of this multiple times in the email [23:24:53 CET] <kierank> if you don't like the technical reality that's tough luck [23:24:53 CET] <ssalenik> are* [23:25:08 CET] <kierank> we can't help you build your perpetual motion machine [23:25:19 CET] <ssalenik> and we appreciate your feedback [23:26:23 CET] <kierank> when we implemented it we listened to people who did it before [23:26:30 CET] <kierank> instead of ignoring them [23:28:42 CET] <wm4> ssalenik, ebail: what they actually want to say is that ffmpeg is a really bad match for this task and that there are better projects (which have been pointed out) [23:29:22 CET] <kierank> well I did say that [23:29:42 CET] <ebail> sure wm4. we are not ignoring you kierank. [23:29:46 CET] <ssalenik> yup, thats why we're asking the questions... if it turns out that what we want to do isn't doable in ffmpeg, or the solution won't be upstreamed, thats fine as well [23:30:17 CET] <kierank> this is why we have all the assembly code in a different repo by the way [23:30:22 CET] <kierank> because it doesn't fit upstream [23:30:39 CET] <wm4> ehat also was implicated - it's not hard to get things into ffmpeg, but this is also why ffmpeg has so many low quality features [23:30:50 CET] <wm4> which are half-broken, work only in certain situations, etc. [23:31:06 CET] <wm4> one example would be the PSD "decoder" (not sure if it made it in yet) [23:31:36 CET] <kierank> scte-35 is another example, the web server [23:31:38 CET] <kierank> etc [23:39:36 CET] <ssalenik> yup... I think the reasoning behind trying ffmpeg first was that they already use it for some things and if its possible to have this new format in ffmpeg they would also use other features of it in conjunction, so the natural reaction is to try to contribute to ffmpeg... but the project is in R&D phase so we're just seeing if these functionalities align with the possibilities / vision of the project [23:41:33 CET] <ssalenik> *possibilities / vision of ffmpeg [23:44:02 CET] <nevcairiel> we're of course not opposed to new features - but they should of course match the overall design/philosophy and be technically feasible, which as it seems would be the part thats in question [23:44:53 CET] <nevcairiel> personally I wouldn't call our rtp code very reliable as it is, so shovling gigabits of data per second through there seems very error prone [23:48:46 CET] <kierank> that's actually not the issue [23:48:56 CET] <kierank> the issue is how to get the data reliably into ffmpeg in the first place [23:49:04 CET] <kierank> the "codec" processing is not too hard [00:00:00 CET] --- Fri Nov 11 2016

1 0

ffmpeg.log.20161110
by burek 11 Nov '16

11 Nov '16

[00:04:02 CET] <Phi> so there's no Windows Intel QSV examples? [02:00:28 CET] <Phi> pandas [02:00:49 CET] <Phi> I mean, I'm getting "avcodec_open2 failed with error -40: Function not implemented." for Intel QSV [02:16:39 CET] <Phi> sempai [04:28:09 CET] <Orbstheorem> Hello, I'm trying to apply a bandpass filter on a streamed video. I'd like to build a format-independent command line. Is there anyway to specify the output format to be equal to the input format? [04:28:23 CET] <Orbstheorem> my cmd is youtube-dl -o - "$(xclip -o -selection clipboard)" | ffmpeg -i - -af "highpass=f=200, lowpass=f=3000" pipe:1 | mpv [04:53:09 CET] <c_14> No [04:53:15 CET] <c_14> (t without scripting) [04:53:24 CET] <c_14> Though you'll want to add -c:v copy so the video doesn't get reencoded [04:53:40 CET] <c_14> And if you don't care (much) about format support, just use matroska as that'll support everything [04:53:59 CET] <c_14> And if you really just want to play the video in mpv you can tell mpv to apply a bandpass without piping it through ffmpeg [04:57:41 CET] <c_14> Ah, he's not here anymore. [04:57:43 CET] <c_14> woops [07:04:07 CET] <Dresk|Dev> So what kind of performance can we expect on modern Android devices running 1080p? For example, the NVIDIA Shield Tablet runs the Tegra K1, nowhere near as the X1 (which the Shield TV runs and the Pixel C uses minus 4 cores), should ffmpeg be able to playback a 1080p H.264 video at 60FPS no issues? [07:04:39 CET] <Dresk|Dev> I've been trying so darn hard to see if ffmpeg is feasible on Android, because our software is multiplatform and we use ffmpeg to draw video to arbitrary surfaces in OpenGL [07:04:57 CET] <Dresk|Dev> But it just seems like without hardware decoding we can never do that on Android [07:06:01 CET] <Dresk|Dev> Does anyone have tips for what options I should for x264? What profile? Any optimizations when building ffmpeg for Android? We've got NEON enabled [07:06:55 CET] <Dresk|Dev> We're also using the latest NDK, 13b, which now uses clang over gcc/g++ [11:10:54 CET] <Mavrik> Dresk|Dev, you should always use HW decoders on those devices [11:11:08 CET] <Mavrik> running ffmpeg is just a terrible waste of CPU cycles and will make your software less capable [11:11:21 CET] <Mavrik> (Shield TV can easily do 4K 60fps H.265) [12:35:35 CET] <Pandela> Morning [12:36:31 CET] <Pandela> Anyone know if ffplay supports raw videos with audio? [12:36:48 CET] <Pandela> I'm using "-f rawvideo -pixel_format yuv422p -video_size 1280x720 -framerate 30 -infbuf -i" But no audio is coming through [12:39:34 CET] <BtbN> rawvideo does not have any audio. It's just a plain file with one raw frame after the other. [12:40:44 CET] <Pandela> Darn. Thanks for the clarification. [12:41:29 CET] <BtbN> It's nothing thar ffplay of ffmpeg don't support. It's simply nothing there to support. [12:44:02 CET] <Betablocker> is there a easy move fading 2 rtsp streams to one ? [12:44:31 CET] <Betablocker> i mean live streams&. not vod [12:45:06 CET] <Pandela> BtbN: Also good to know, thanks. [12:45:52 CET] <Betablocker> stream 1 is running &. stream 2 should fade in and replace stream 1 after eg 5 seconds [12:46:56 CET] <Pandela> One more for tonight. Are there any other formats that support the "-pixel_format" option in ffplay/ffmpeg besides rawvideo? [12:56:31 CET] <kerio> i'd guess that most other formats have an indicator of what the pixel format is already [12:56:45 CET] <kerio> what do you think raw_video is? [13:15:49 CET] <Pandela> I'm just trying to force incorrect color formats and palettes for eye candy, was curious if its possible to do with other formats [13:23:30 CET] <kerio> oh hm [13:23:47 CET] <kerio> i wonder if there's a way to override the pixel format [13:23:59 CET] <kerio> (obviously, between compatible bpp formats) [13:31:53 CET] <Pandela> That would be grand haha [13:33:03 CET] <Pandela> Perhaps I should ask in the dev channel too eh? [13:55:22 CET] <utack> i am guessing this is dead for forever? https://trac.ffmpeg.org/ticket/1885 [13:55:30 CET] <utack> VC1 multithreaded decoding [14:05:38 CET] <allx> hi there - is there a limit to the length of a filtergraph string that can be passed via -filter_complex? [14:06:38 CET] <jkqxz> utack: Yeah, very unlikely anyone would bother. Pretty much all modern hardware contains fast VC-1 decode support anyway. [14:06:43 CET] <kepstin> allx: probably limited only by the max length of a command line on your system [14:07:41 CET] <kepstin> allx: if you need a really long one, well, that's what -filter_complex_script is for :) [14:07:54 CET] <furq> i've never seen a system with ARG_MAX less than 32k [14:09:04 CET] <allx> kepstin, furq: great, thank you both [14:09:13 CET] <furq> it's between 256k and 2MB on all the systems i have running atm [14:09:17 CET] <furq> so you'll probably be fine [14:40:30 CET] <utack> jkqxz my phone unfortunately not so much [14:40:48 CET] <ciawal> ok I think I must have hit a bug in ffmpeg [14:40:48 CET] <ciawal> if I switch back to 3.0.2 it sees all 69 frames of my video file, but on the latest (3.2) it sees only 68 [14:45:33 CET] <DHE> don't suppose you could bisect that... [14:46:48 CET] <ciawal> I can try [15:07:43 CET] <ciawal> DHE: here is the debug output with both versions https://gist.github.com/ciaran/1d6a043d13c205f377debeb550eb90b7 [15:07:46 CET] <ciawal> maybe this gives some insight [15:08:09 CET] <DHE> do you know what bisecting is? I suspect not... [15:08:50 CET] <ciawal> I do [15:08:53 CET] <ciawal> it's compiling [15:09:08 CET] <DHE> ah... [15:09:18 CET] <ciawal> it will take some time to do [15:43:52 CET] <zamba> i want to concatenate a four MP4 files (gopro video) and at the same time flip these [15:43:56 CET] <zamba> how do i do that? [15:46:58 CET] <kerio> flip them how [15:48:49 CET] <DHE> recorded upsidedown on the gopro? sounds like you want the concat input type and then use a simple video filter to flip them back [15:49:08 CET] <furq> if you're using the transpose filter then you might as well use the concat filter [15:49:41 CET] <furq> or use the concat demuxer and the rotate metadata to do it losslessly [15:50:11 CET] <kerio> furq: a better question is [15:50:20 CET] <kerio> is it possible to losslessly rotate some but not others? [15:50:26 CET] <furq> some what [15:50:32 CET] <kerio> some of the input files [15:50:46 CET] <kerio> or is the rotate metadata per-stream [15:51:10 CET] <furq> it's set in the container [15:51:34 CET] <BtbN> remux to ts, concat using concat demuxer and -c copy [15:51:35 CET] <furq> if half your files are actually upside down (e.g. not rotated by metadata) then you're screwed [15:51:42 CET] <BtbN> and then figure out how to flit it without re-encoding [15:51:51 CET] <BtbN> *p [15:51:56 CET] <furq> unless the inputs are jpg or something which you can actually rotate losslessly [15:51:59 CET] <furq> although idk if ffmpeg can do that [15:55:49 CET] <kerio> is h264 not losslessly rotable? [15:56:27 CET] <BtbN> I suppose in theory it might be, if someone came up with logic that rotates all the motion vectors and everything else that's involved. [15:56:35 CET] <BtbN> But such a thing for sure doesn't exist. [15:57:41 CET] <furq> mjpeg is the only codec i know of where it's possible in practice [16:12:05 CET] <kerio> BtbN: can't we just put a - in front of everything :D [16:20:20 CET] <zamba> so, what's the command line option to do this? [16:21:59 CET] <furq> depends what you mean by flip and why they're currently flipped [16:23:49 CET] <furq> pastebin the output of `ffprobe -show_entries stream_tags=rotate input.mp4` [16:41:53 CET] <Pandela> Anyone know if the pixel_format option in the "image2" demuxer allows you to force any colorspace? [16:46:51 CET] <dragmore> hi, im trying to to a TS to TS remultiplex, and remove 3 out of 4 DVB-Sub pids as well as set the new language tag on the pid.. Anyone care to share how the syntax would be? [16:47:04 CET] <dragmore> ffmpeg -i org.ts -c:v copy -c:a copy -c:s copy -map 0:v -map 0:a -map 0:s -y test2.ts [16:47:21 CET] <dragmore> but id like to use the stream_id command and use stream 3 [16:48:31 CET] <dragmore> ffmpeg version 3.0.4 [16:48:59 CET] <furq> dragmore: https://trac.ffmpeg.org/wiki/Map#Example8 [16:50:48 CET] <zamba> furq: unrecognized option show_entries [16:51:04 CET] <zamba> oh.. nevermind.. ffprobe, not ffmpeg [16:51:25 CET] <zamba> http://pastebin.com/jM1hgXcg [16:53:27 CET] <dragmore> furq: yep, but it doesn say how to re-stamp the language string [16:53:43 CET] <dragmore> furq: today its unknown, i need to set ENG [16:53:52 CET] <c_14> -metadata:i:id language=eng [16:57:27 CET] <furq> zamba: so what do you mean by flip [16:58:15 CET] <dragmore> c_14: So.. if i understand this correctly : -metadata:0x1 language=nor ? [16:58:39 CET] <furq> zamba: https://ffmpeg.org/ffmpeg-filters.html#concat and https://ffmpeg.org/ffmpeg-filters.html#transpose [16:59:11 CET] <furq> you can either reencode the video the right way up, or use the concat demuxer and set the rotation metadata, which will play it back rotated in (some) players [16:59:22 CET] <furq> the second way is much faster but won't work in all players [17:00:22 CET] <c_14> dragmore: -metadata:i:0x1 language=nor [17:01:32 CET] <dragmore> c_14_ ok let me try [17:02:47 CET] <dragmore> c_14 : got a : Invalid metadata type 0. [17:02:54 CET] <dragmore> ffmpeg -i org.ts -c:v copy -c:a copy -c:s copy -metadata:0:3 language=eng -map 0:v -map 0:a -map 0:s -y test3.ts [17:03:30 CET] <dragmore> havnt figured out how to only copy 1 of 4 subs.. [17:04:16 CET] <furq> -map 0:s:0 [17:04:24 CET] <furq> replace the second 0 as appropriate [17:05:23 CET] <ninja6o4> hey guys. i'm having trouble converting a really old .mov and i'm not sure if it's copy protected. is there any way to tell? [17:05:45 CET] <dragmore> furq: still getting invalid metadata type 0 [17:05:51 CET] <dragmore> ffmpeg -i org.ts -c:v copy -c:a copy -c:s copy -metadata:0:3 language=eng -map 0:v -map 0:a -map 0:s:3 -y test3.ts [17:10:34 CET] <ninja6o4> ffmpeg detects it as svq3 encoded [17:11:21 CET] <ninja6o4> if anyone has a suggestion, please, i'm all ears. here's the output: http://pastebin.com/dA9x9prZ [18:03:54 CET] <dragmore88> anyone know if ffmpeg can fix malformed PES packets for subtitles ? ([mpegts @ 0x20a8d00] PES packet size mismatchme=00:18:51.80 bitrat&) [18:31:35 CET] <ciawal> DHE: ca6cae73db207f17a0d5507609de12842d8f0ca3 [18:31:38 CET] <ciawal> finally [18:50:29 CET] <Croepha> so, im using the ffmpeg api to download from an HLS source, and I only want to play one variant, (ie one video stream and its related audio stream) but the hls demuxer seems to be downloading all the streams, (all quality levels) is there a way to tell it to only download the streams I am decoding? [19:08:36 CET] <kerio> well, the variant is just another hls stream [19:13:37 CET] <Croepha> kerio: so you mean, just pass one of the variant playlists to avformat_open_input, instead of the main one? [19:16:51 CET] <DHE> ciawal: interesting, and unfortunately a rather large commit... [19:17:36 CET] <DHE> well, not so bad if you ignore the fate tests [19:54:26 CET] <Phi> alright, an easier one for you guys [19:54:38 CET] <Phi> "--enable-debug" seems to have options, but I can't find a list of them [19:55:46 CET] <furq> Phi: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html [19:56:03 CET] <Phi> ah, I'm building with MSVC [19:56:24 CET] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L6042 [19:56:52 CET] <furq> $debuglevel is the args to --enable-debug [19:57:33 CET] <Phi> hmm, so it's geared for GCC? [19:59:15 CET] <Phi> so I just have to add_cflags and add_asflags whatever MSVC needs [19:59:59 CET] <Phi> there's --extra-cflags, --extra-cxxflags, but no asflags? [20:01:50 CET] <furq> you can presumably use --yasmexe="yasm -args" [20:02:21 CET] <furq> or --as rather [20:04:48 CET] <Phi> --extra-cflags="/DEBUG" --yasmexe="yasm --DEBUG" ? [21:03:33 CET] <Phi> --extra-cflags="--DEBUG" --yasmexe="yasm --DEBUG" seems to work [21:03:35 CET] <Phi> ima make [22:55:30 CET] <infinito> im trying to rely tcp to udp multicast process in ffmpeg and i get a lot of artifacts [22:56:05 CET] <infinito> im doing that: ffmpeg -i tcp://10.1.0.1:5000?listen -c:v libx264 -c:a copy -f mpegts udp://239.255.255.1:6000 [22:56:52 CET] <infinito> if i check the tcp input, its comes good and its fine. the same if only i send a mp4 file to multicast [22:57:09 CET] <infinito> but that command isnt working [22:59:27 CET] <DHE> infinito: you didn't specify a bitrate for the video so the default is 1 megabit. [22:59:55 CET] <DHE> for mpegts to UDP I'd recommend using full VBV mode and the output bitrate setting (assuming you're up to date with that feature) [22:59:56 CET] <infinito> sorry, i pasted a test, instead of libx264 must be copy too [23:00:17 CET] <DHE> ah, yes, you probably have burst bandwidth problems [23:00:58 CET] <infinito> if i just write the tcp incoming stream to disk its works fine [23:01:17 CET] <DHE> bandwidth burst [23:01:19 CET] <infinito> and the multicast is in the loopback, just for make variants [23:02:34 CET] <infinito> im now reading about vbv, its related to bandwidth burst ? [23:02:50 CET] <DHE> well if you're using -c:v copy then it doesn't matter [23:03:33 CET] <infinito> i am creating the stream in other place, using ffmpeg too [23:03:38 CET] <DHE> UDP is an unreliable protocol, doubly so when going through small-buffer switches and routers. there's an option for the udp output to space the packets out by specifying the bitrate of the video. [23:04:00 CET] <DHE> specifying slightly high a bitrate is also fine. [23:05:24 CET] <infinito> you say i have to re encode the video to a high birtrate to make udp work fine? [23:06:49 CET] <infinito> im encoding the video from the tcp source whit -b:v 2M [23:07:31 CET] <DHE> no. I'm saying you have to tell ffmpeg what the video bitrate is so that packets are evenly spaced and match real-time flow rather than coming out at maximum speed [23:08:48 CET] <infinito> and who can tell ffmpeg that [23:09:07 CET] <DHE> well, you can if you set the bitrate. [23:09:18 CET] <DHE> you might also be interested in the -muxrate parameter for the mpegts muxer [23:10:04 CET] <furq> infinito: https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs#Teepseudo-muxer [23:11:11 CET] <DHE> oh that's cool... [23:12:05 CET] <infinito> furq i checked tee but i really want to use multicast to aviod rewrite code. [23:13:31 CET] <furq> why are you using a separate ffmpeg for multicasting [23:13:35 CET] <infinito> DHE i go to check if -f mpegts -muxrate 2M works [23:14:05 CET] <DHE> Infiltrator: that's not good enough. the video bitrate is 2M, but the audio and muxing overhead are also present. you will get problems. [23:14:33 CET] <infinito> furq , first i get from dvb-t in a place a lot of channels, then i send to azure trought openvpn using tcp and then, in a lot of different nodes i make variants from channels [23:14:52 CET] <DHE> I might do something like: ffmpeg -i input.mp4 -c:b libx264 -b:v 2M -maxrate:v 2M -bufsize:v 1M -c:a copy -muxrate 2.5M -f mpegts udp://239.255.255.1:6000?bitrate=2500000 [23:15:04 CET] <DHE> oops, some typos but I think you can see what I meant [23:15:29 CET] <infinito> yes, i check it now [23:23:01 CET] <infinito> DHE is working! [23:24:35 CET] <infinito> really thanks! [23:33:12 CET] <bens218> would this be good for backing up dvd's? [23:33:20 CET] <bens218> http://pastebin.com/jCLTERwG [23:33:39 CET] <bens218> or is there something i should add/remove/change? [23:34:16 CET] <llogan> 0:0 is not guiaranteed to always be a video stream. use 0:v (or 0:v:0) instead [23:34:34 CET] <bens218> got it, thanks llogan [23:35:16 CET] <llogan> you probably don't need -profile and -level unless you need to support some old device [23:35:52 CET] <bens218> no, playback devices will either be kodi boxes and/or roku [23:36:05 CET] <bens218> no old devices [23:36:20 CET] <llogan> then you can let x264 autochoose those [23:36:39 CET] <bens218> got it [23:36:40 CET] <furq> one vob doesn't necessarily correspond to the thing you want [23:36:58 CET] <furq> you probably want to use something like tccat to extract a title [23:37:01 CET] <bens218> well, that's just an example. i know 1 single vob won't be the whole movie [23:37:12 CET] <bens218> i've already used tccat to get my single vob [23:37:19 CET] <furq> fair enough [23:37:24 CET] <llogan> there is also tools/dvd2concat [23:37:29 CET] <furq> fwiw you can pipe tccat straight into ffmpeg [23:37:38 CET] <furq> as long as you don't care about subtitles or chapters [23:37:48 CET] <furq> you won't get either with that command anyway [23:37:52 CET] <bens218> i'm trying to retain the chapters if possible [23:38:02 CET] <bens218> i can do without subs [23:38:14 CET] <furq> i've not yet found a non-awful way to retain chapters without using mkvmerge [23:38:31 CET] <furq> ffmpeg only supports adding chapters through some wonky ffmetadata file which nothing else supports writing [23:38:51 CET] <bens218> oh man [23:40:13 CET] <furq> you can still pipe tccat straight into ffmpeg anyway [23:40:21 CET] <furq> you'll just then need to extract chapters separately and remux the output mkv [23:40:39 CET] <furq> or write a script that converts some other chapter file format to ffmetadata [23:41:54 CET] <bens218> would you happen to have some examples furq? [23:45:05 CET] <furq> http://vpaste.net/aioZz [23:45:07 CET] <furq> something like that [23:45:37 CET] <bens218> argh, stupid work web filters. won't let me access vpaste [23:45:53 CET] <furq> http://sprunge.us/YZbA [23:46:26 CET] <bens218> got it, thanks [23:47:07 CET] <furq> subtitles may or may not work with that, but last time i tried it i had to tweak analyzeduration/probesize and then the palette was messed up [23:47:20 CET] <furq> but since you need a temp file anyway you can extract them separately if you need them [23:48:20 CET] <ros_rox> hello - i am compiling ffmpeg on windows 8.1 using msvc++ 2008 win32, avcodec57.dll throwing entrypoint not found for calls of the kind: CoTaskMemAlloc(sizeof(VIDEOINFOHEADER)); (from pjsip library) can anyone help ? [23:48:48 CET] <furq> also yadif=mode=1 looks much nicer than mode 0 to me [23:49:13 CET] <furq> i don't normally use yadif for deinterlacing but frame-per-field is generally better [00:00:00 CET] --- Fri Nov 11 2016

1 0