Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2017

1 participants
62 discussions

ffmpeg-devel.log.20170310
by burek 11 Mar '17

11 Mar '17

[00:15:12 CET] <nevcairiel> you can use _ref and afterwards call av_frame_make_writable one the one you want to modify [00:15:23 CET] <nevcairiel> it'll copy the data to ensure existing copies dont get modified [01:17:14 CET] <ZeroWalker> anyone that can help me with writing a frame (encoded package) to a file, i fail at avformat_write_header, http://sprunge.us/BVVL [01:42:43 CET] <ZeroWalker> no one;(? [01:59:38 CET] <reeskm> if i built my own custom ffmpeg and i'm having problems with using libxvid, should I ask my question here or on #ffmpeg? [02:06:32 CET] <reeskm> basically i linked it against libxvidcore but when i try and specify -c:v libxvid it crashes with an illegal instruction. encoding using the builtin mpeg4 succeeds. [02:06:40 CET] <RiCON> in #ffmpeg [02:07:08 CET] <RiCON> this is a channel for developing FFmpeg, not using it [02:08:20 CET] <reeskm> i know how to use ffmpeg, but seem to have hit a bug? [02:12:18 CET] <RiCON> still better to make an issue in the trac [02:13:15 CET] <reeskm> ok i'll do that! thanks [02:21:04 CET] <cone-106> ffmpeg 03Thomas Guilbert 07master:9bbc73ae9fde: avcodec/vp8: Fix hang with slice threads [02:21:40 CET] <nevcairiel> vp8 supports slice threads? [02:22:52 CET] <nevcairiel> guess it does [03:00:27 CET] <BBB> nevcairiel: its strictly speaking partition threading" [03:01:00 CET] <BBB> jamrial: increase the count [03:01:06 CET] <BBB> jamrial: it runs only 1000x [03:01:16 CET] <BBB> jamrial: if you run 5000x, it will be faster [03:01:39 CET] <jamrial> BBB: i took that from BtbN's paste, and he ran 10k [03:01:42 CET] <BBB> oh [03:01:45 CET] <BBB> thats strange [03:02:05 CET] <BBB> no clue then [03:02:45 CET] <jamrial> ryzen has a 128bit execution unit, so i find it strange that it's faster in some functions. i'd expect it to be slower in all [03:03:23 CET] <jamrial> maybe it depends on the instruction. like, once you get into the whole cross lane bullshit that's where it gets hit the most [05:58:11 CET] <rcombs> any objections to https://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/208207.html [06:00:02 CET] <cone-067> ffmpeg 03Aaron Boxer 07master:195784ec9526: libavcodec/libopenjpegenc: enable lossless option, remove layer option, and improve defaults [11:05:36 CET] <durandal_1707> vlc opengl stuff and lavc stuff is really buggy [12:19:45 CET] <kierank> If anyone is merging from libav, please don't merge their cineform. It's full of breaking cosmetic changes [12:35:36 CET] <wm4> don't worry, nobody is merging from libav [12:35:48 CET] <wm4> and if they are they get actively fought [12:45:33 CET] <durandal_1707> kierank: how that possible? [12:53:03 CET] <durandal_1707> wm4: how so? will now get only clusterfu* changes [13:24:49 CET] <durandal_1707> i will merge bitstream stuff [13:28:29 CET] <kierank> wm4: good to see both projects are in batshit insane mode as usual [15:22:43 CET] <BBB> Ive got a second vmaf gsoc task student [15:22:49 CET] <BBB> anyone can think of a good qualification task? [15:23:11 CET] <BBB> Im thinking maybe implement a ansnr filter (like psnr filter), which would probably be the simplest step in the vmaf filter? [16:01:26 CET] <durandal_1707> BBB: a stuff is reserved for audio [16:01:57 CET] <BBB> vf_ansnr [16:02:03 CET] <BBB> that should be non-confusing right? [16:03:56 CET] <durandal_1707> what ansnr stands for? [16:07:51 CET] <BBB> it applies a filter before calculating the snr& the n stands for noise [16:07:58 CET] <BBB> I dont know what the a stands for [16:10:39 CET] <BBB> its essentially a low-pass filter [16:47:12 CET] <nightlingo> hello [16:47:48 CET] <nightlingo> I need to be able to stream to stdout when converting into .mp4 format, for example: [16:47:49 CET] <nightlingo> ffmpeg -i file.avi -f mp4 - > file.mp4 [16:47:50 CET] <nightlingo> However, I get the following error: muxer does not support non seekable output - I get the reason why the mp4 writer doesn't support this. But is there any work around for this? I've beel searching for days! Thank you [16:48:41 CET] <nevcairiel> mp4 is not a format designed for such an output [16:49:23 CET] <nightlingo> yes, but maybe a workaround ? like, writing the moov atom in the and of the file or something? [16:49:51 CET] <DHE> inappropriate question for this channel [16:50:27 CET] <nightlingo> DHE: where could I ask about this? [16:50:29 CET] <Rathann> nightlingo: /j #ffmpeg [16:50:48 CET] <nightlingo> ok thank you [16:50:56 CET] <durandal_1707> he is already there [16:55:30 CET] <nightlingo> is there a channel related to the mp4 format to ask a format-level question? [16:58:45 CET] <BBB> nightlingo: not that I know... [17:34:23 CET] <adeel1> durandal_1707: the image dimensions are: 15x16 and the outer for loop get stuck stack 14; meaning at the last row. Could this have something to do with wroning XPM file formatting? [17:36:34 CET] <adeel1> atomnuker: did durandal_1707 change their nickname? I can't view it in the list. [18:17:25 CET] <atomnuker> adeel1: no, he just disconnected himself [18:18:37 CET] <adeel1> atomnuker: oh, ok. Well, I am having some issues with xpmdec. Could you help me out? [18:19:54 CET] <atomnuker> sure, what's the problem?? [18:24:13 CET] <adeel1> atomnuker: so, I finished the functionality for the decoder. For one example, I'm getting a distored output (purple boundries), and for the other the output window doesn't open and it show 'nan'. [18:24:33 CET] <adeel1> Please let me know if I need to share the latest code [18:35:50 CET] <atomnuker> can you post a screenshot? [19:02:20 CET] <atana> michaelni, after fft overlap total of 9 failures [19:08:17 CET] <adeel1> atomnuker: there you go: https://snag.gy/afNAPT.jpg [19:08:53 CET] <adeel1> durandal_1707: the image dimensions are: 15x16 and the outer for loop gets stuck at 14; meaning at the last row. Could this have something to do with wrong XPM file formatting? [19:12:49 CET] <durandal_1707> adeel1: another student did 99% of qualification task he just need to send patch to mailing list [19:14:05 CET] <adeel1> durandal_1707: you know I completed this as well. The XPM file was getting fully decoded. It's on the other file that I'm having the issue on. [19:14:42 CET] <durandal_1707> nope,where is > 256 colors support [19:21:00 CET] <durandal_1707> adeel1: it could hang if it enters loop but then it should start to consume cpu [19:21:48 CET] <adeel1> durandal_1707: The CPU is idle. yet it still hangs. [19:24:16 CET] <adeel1> durandal_1707: for adding > 256 color support, does the file has somehow to be linked with parseutils.c? [19:24:36 CET] <adeel1> I've noticed new colors were added in the patch file [19:25:49 CET] <durandal_1707> nope, if you look at code you will see that number of colors are read from line in xpm file [19:26:24 CET] <knight___> Hi, I want to send my patches and git send-email is not getting setup, please advise [19:26:40 CET] <durandal_1707> color names from parseutils are just for colors given as name instead of hex [19:27:10 CET] <durandal_1707> knight___: you can attach patch too [19:27:51 CET] <durandal_1707> for send mail via git you need to add 2 lines in git conf file [19:28:09 CET] <durandal_1707> inside relevant git repo [19:28:29 CET] <adeel1> durandal_1707: yes, but that only check if no. of colors are > 256 and logs errors. I assume adding the > 256 support is not as easy as just removing that code block? or is it? [19:28:39 CET] <knight___> Where can I find the those lines? [19:29:01 CET] <durandal_1707> adeel1: not just removing, few lines shoulbe added [19:29:42 CET] <knight___> Attaching patch as in attachement in the mail? [19:29:48 CET] <durandal_1707> knight___: blame doc you read, for time being just attach patches to email [19:30:09 CET] <knight___> patches in git-format patch style? [19:30:16 CET] <durandal_1707> knight___: yes [19:30:31 CET] <durandal_1707> please no git diff [19:33:25 CET] <adeel1> durandal_1707: okay, I've removed it. As for the addition, I'm assuming the for loop that runs for ncolors has to be modified? [19:34:46 CET] <durandal_1707> adeel1: you need to use another pix fmt [19:35:57 CET] <durandal_1707> for loops are only slightly modified [19:36:27 CET] <durandal_1707> adeel1: does it hang with other XPM files? [19:38:19 CET] <adeel1> durandal_1707: I've tried 2 other examples, and it works fine for them [19:42:54 CET] <adeel1> durandal_1707: currenty we're using pal8 which has 4 color channels, sholdn't this already be > 256? [19:47:37 CET] <c3r1c3-Win> adeel1: are you sure that fourth channel is a color and not an alpha channel? [19:47:52 CET] <c3r1c3-Win> adeel1: and what bit depth are you channels? [19:49:07 CET] <adeel1> c3r1c3-Win: bith depth is 8, i'm not so sure about the alpha channel, though. [19:54:53 CET] <durandal_1707> adeel1: pal8 means palette 8bit [19:55:03 CET] <durandal_1707> max 256 colors [19:55:30 CET] <durandal_1707> 2 ^8 is guess what 256 [19:57:00 CET] <durandal_1707> adeel1: it may hang because av parse doesnt check if color is actually found [19:57:57 CET] <adeel1> durandal_1707: okay. Going by this list[http://ffmpeg.org/pipermail/ffmpeg-devel/2007-May/035617.html] only gray16be and gray16le have 16bit depth. Should I use one of these? [19:59:04 CET] <adeel1> so, there's a bug in av_parse_color? [20:04:44 CET] <durandal_1707> adeel1: what? have you ever heard of rgba ? [20:05:00 CET] <adeel1> yes [20:05:30 CET] <durandal_1707> so use it [20:06:23 CET] <durandal_1707> AV_PIX_FMT_RGBA/BGRA [20:06:44 CET] <durandal_1707> am really helping to much [20:06:58 CET] <paras2052> :durandal_1707 hi, thank you for the guidance. I have submitted the patch [20:07:16 CET] <durandal_1707> adeel1: i cannot point you every single step you need to do [20:08:01 CET] <paras2052> :durandal_1707 I want to contribute more. Can you assign me some other task or any bug to fix ? [20:08:17 CET] <durandal_1707> paras2052: you need to simplify colors entry and use uint32t [20:09:29 CET] <paras2052> :durandal_1707 okay, let me do that [20:10:38 CET] <paras2052> :durandal_1707 but after making it uint32, i will have to change all the individual colors defined in color_table [20:11:50 CET] <durandal_1707> paras2052: yes, they were origibally uint32t anyway [20:12:04 CET] <durandal_1707> make them opaque [20:12:18 CET] <durandal_1707> with 0xff for alpha [20:12:29 CET] <paras2052> okay, i am on it [20:12:47 CET] <durandal_1707> and check please dont ignore bsearch return value [20:13:36 CET] <durandal_1707> and improve your code style to be same as file you first opened [20:14:24 CET] <durandal_1707> eg else should be on same line as enclosing } [20:14:48 CET] <paras2052> i am having a confuson there, if there is any error occurs in bsearch, can i return AVERROR_INVALIDDATA or something else ? [20:15:00 CET] <paras2052> yes i will make code style improvements too [20:15:53 CET] <durandal_1707> no just return black [20:16:04 CET] <paras2052> okay, got it [20:16:12 CET] <paras2052> any other suggestions/changes ? [20:16:52 CET] <durandal_1707> paras2052: are you subscribed to ml? [20:17:54 CET] <durandal_1707> to ffmpeg-devel? [20:18:45 CET] <paras2052> yes [20:23:23 CET] <durandal_1707> paras2052: have you tried ppmtoxpm with big images? [20:25:43 CET] <paras2052> durandal_1707: i have not used ppmtoxpm. i was using GIMP to convert images to XPM and i have tested for one 3.3 MB image containing 10^5 colors [20:26:33 CET] <paras2052> durandal_1707: should i test for more larger images ? [20:28:12 CET] <adeel1> durandal_1707: I'm getting a segmentation fault with AV_PIX_FMT_RGBA and AV_PIX_FMT_BGRA. I tried increasing the length of rgba array (not sure why), but that didnt help [20:28:38 CET] <durandal_1707> paras2052: nope [20:29:20 CET] <durandal_1707> adeel1: because it uses only one plane data0 [20:35:36 CET] <adeel1> durandal_1707: okay, fixed. its working now. please let me know what to do next. [20:36:35 CET] <durandal_1707> adeel1: you are too late to the party [20:37:04 CET] <adeel1> durandal_1707: really? I was the first to get started -_- [20:37:40 CET] <durandal_1707> adeel1: show your code [20:37:47 CET] <adeel1> okay [20:39:45 CET] <adeel1> durandal_1707: https://gist.github.com/adl1995/ea13cce3f4dfe3d8198087b4609db76e [20:42:49 CET] <durandal_1707> adeel1: check for 256 is still there [20:43:09 CET] <adeel1> dang [20:43:16 CET] <adeel1> let me remove it [20:43:51 CET] <durandal_1707> adeel1: and try to test it with more than 256 colors [20:45:11 CET] <adeel1> durandal_1707: can't find many xpm images online. should i try to convert regular PNG image and decode that? [20:46:59 CET] <adeel1> durandal_1707: just decoded a 4.9mb xpm file. its working [20:49:50 CET] <durandal_1707> adeel1: really, let me see the code? [20:50:41 CET] <adeel1> durandal_1707: https://gist.github.com/adl1995/9d3e1a310e66a399794e0a89b1f7e69c [20:52:40 CET] <durandal_1707> adeel1: stiil missing skiping comments [20:55:03 CET] <adeel1> durandal_1707: yes, that was my first task, if I remember correctly. I did write some code for it at the time. If the image is getting decoded correctly even with comments in the files, doesn't it mean they're already skipped? [20:56:10 CET] <durandal_1707> nope, just add " middle of comments [20:59:24 CET] <adeel1> durandal_1707: just added this comment /* colors " */ it's still decoding [20:59:48 CET] <llogan> git: 'checkoot' is not a git command. [20:59:54 CET] <llogan> guess it doesn't like scottish [21:00:39 CET] <durandal_1707> adeel1: its important where [21:01:16 CET] <adeel1> durandal_1707: where the " is placed? [21:02:10 CET] <nightlingo> Hello, Im trying to understand how the mp4 format works. I read that ffmpeg cannot write mp4 to stdout because it requires a seekable stream so as to be able to go back and write the header. Is the heaer the moov atom, or the ftyp atom? [21:02:40 CET] <nightlingo> *header [21:09:48 CET] <llogan> nightlingo: wrong channel. try #ffmpeg [21:10:31 CET] <nightlingo> ok [21:11:50 CET] <durandal_1707> adeel1: in middle of [22:49:42 CET] <Guest84632> hii [22:50:01 CET] <Guest84632> I' Mirage [22:51:32 CET] <Guest84632> benchmark result shows lower speedup for AVX2 [22:51:40 CET] <Guest84632> pred16x16_tm_vp8_sse2: 52.5 pred16x16_tm_vp8_avx2: 52.2 [22:55:03 CET] <Guest31122> @BBB hello [22:55:12 CET] <BBB> hi [22:55:23 CET] <BBB> ah good, lets talk avx2 [22:55:27 CET] <BBB> more avx2! more avx2! [22:55:33 CET] <Guest31122> Hi [22:55:52 CET] <BBB> you should choose a real nickname [22:56:04 CET] <BBB> /nick <name> [22:56:13 CET] <BBB> e.g. /nick Mirage [22:56:14 CET] <Guest31122> i ran the benchmark and got pred16x16_tm_vp8_sse2: 52.5 pred16x16_tm_vp8_avx2: 52.2 [22:56:15 CET] <Guest31122> sure [22:56:49 CET] <BBB> in tests/checkasm/checkasm.h, change BENCH_RUNS from 1000 to 5000 [22:57:22 CET] <BBB> then, in tests/checkasm/checkasm.c, disable all modules in tests[] except h264pred [22:58:03 CET] <BBB> and in tests/checkasm/h264pred.c, optionally, disable all tests in checkasm_check_h264pred() except 16x16 tm for vp8 [22:58:13 CET] <BBB> (that just helps speed testing up a bit) [22:58:29 CET] <BBB> and then re-compile and re-run tests/checkasm/checkasm --bench [23:00:52 CET] <Mirage20> pred16x16_tm_vp8_sse2: 90.9 [23:00:53 CET] <Mirage20> pred16x16_tm_vp8_avx2: 49.2 [23:01:10 CET] <Mirage20> is it lower numbers are better? [23:01:14 CET] <BBB> yes [23:01:17 CET] <Mirage20> I thought its speedup [23:01:18 CET] <BBB> its cycle count [23:01:23 CET] <Mirage20> ah ok :) [23:01:29 CET] <BBB> so sse2 takes 90 cycles, avx2 takes 49 cycles [23:01:34 CET] <BBB> ok now lets look at your code [23:01:45 CET] <BBB> your cosmetics need some work [23:01:56 CET] <BBB> cglobal pred16x16_tm_vp8_8, 2,9,5 -> after every comma comes a space [23:02:22 CET] <BBB> I want you to learn to use named arguments. r0/r1/r2 are incomprehensible. use cglobal pred16x16_tm_vp8_8, 2, 9, 5, dst, stride [23:02:26 CET] <BBB> and then instead of r0, use dstq [23:02:31 CET] <BBB> and instead of r1, use strideq [23:02:49 CET] <BBB> you can do the same for r2 etc. but well get rid of those in a bit... [23:03:26 CET] <BBB> vpxor ymm0, ymm0 [23:03:26 CET] <BBB> movdqa xmm0, [r0] [23:03:27 CET] <BBB> vpmovzxbw ymm0,xmm0 [23:03:41 CET] <BBB> the v prefix isnt necessary [23:03:47 CET] <BBB> we do that automatically for most instructions [23:03:52 CET] <BBB> dont use ymm<num> [23:04:01 CET] <BBB> after INIT_YMM avx2, m<num> refers to ymm<num> [23:04:04 CET] <BBB> so use m<num> [23:04:11 CET] <BBB> e.g. pxor m0, m0 is identical to vpxor ymm0, ymm0 [23:04:14 CET] <BBB> but shorter [23:04:35 CET] <BBB> pmovzxbw can read from memory and both undo the result of pxor [23:04:50 CET] <BBB> so the three instructions can be rewritten as: pmovzxbw m0, [dstq] [23:05:00 CET] <Mirage20> how it will identify the registers? [23:05:21 CET] <BBB> what do you mean? [23:05:55 CET] <Mirage20> for example when I want to use both xmm and ymm [23:06:02 CET] <BBB> xm<num> is short for xmm [23:06:19 CET] <BBB> the advantage of xm<num>/m<num> will become apparent later when you start using SWAP [23:06:37 CET] <BBB> you wont be using it for the qualification task, but SWAP allows you to assign a new number to a register [23:06:57 CET] <BBB> look at TRANSPOSE8x8W in libavutil/x86/x86util.asm as an example of why SWAP is so critically important [23:07:31 CET] <BBB> ok, so use a single instruction for loading top& then, do the same for topleft: movzx r3d, byte [r0-1] is silly, dont move it to a GPR [23:07:58 CET] <BBB> juse use vpbroadcastb xm1, [r0-1] and then pmovzxbw m1, xm1 [23:08:27 CET] <BBB> and once you have that, you can psubw m0, m1 to get the intermediate result of top-topleft [23:08:35 CET] <BBB> that means you dont have to do that in the loop anymore [23:09:03 CET] <BBB> and then, using what you just learned, I want you to try and rewrite the inner loop so it takes a quarter of the code that it currently does ;-) [23:10:02 CET] <Mirage20> which inner loop? [23:10:04 CET] <BBB> dont have two registers r0/r2, just assign an extra register stride3 (lea stride3q, strideq*3] and use that, so you can use r0 for all memory addresses [23:10:13 CET] <BBB> .loop: until jg .loop [23:10:41 CET] <BBB> for vpermq, if you choose to use that, dont use literal numbers, instead use qABCD [23:10:45 CET] <BBB> (probably q3120) [23:10:59 CET] <BBB> merge two packuswbs together [23:11:25 CET] <BBB> and then mova from xm + vextracti128 from the same m register [23:12:15 CET] <BBB> after youve done that and it works, you can send the patch to the ML for review [23:12:32 CET] <Mirage20> suree [23:12:51 CET] <Mirage20> can you provide me some good reference for x86 assembly? [23:13:00 CET] <Mirage20> currently I used this https://software.intel.com/sites/landingpage/IntrinsicsGuide/ [23:13:10 CET] <BBB> that should work [23:13:16 CET] <BBB> I usually use the intel handbook [23:14:01 CET] <Mirage20> also how should I debug the ffmpeg code [23:14:04 CET] <Mirage20> ? [23:15:28 CET] <Mirage20> sometimes breakpoints are not working [23:17:58 CET] <Mirage20> used this configuration ./configure --disable-stripping --enable-debug=3 --extra-cflags="-gstabs+" --disable-optimizations [23:18:11 CET] <BBB> breakpoints should work& [23:18:17 CET] <BBB> needmoreinfo :) [23:21:08 CET] <Mirage20> for example I create a breakpoint in the SSE function pred16x16_tm_vp8_8 in the asm file. It brakes in the first line then cant step over because other thread get scheduled and it also hit the same brakepoint [23:22:08 CET] <Mirage20> I tried with --disable-pthreads and also used -thread 1 parameter but no luck [23:25:22 CET] <BBB> how did you step? [23:25:29 CET] <BBB> using "step"? [23:25:40 CET] <BBB> (you need to use stepi) [23:27:10 CET] <Mirage20> I used eclipse ide for debugging [23:30:11 CET] <kylophone> Question about the AVCodec API: If the init function fails, does the close function still get called? [23:30:29 CET] <BBB> kylophone: no [23:30:31 CET] <kierank> Mirage20: https://wiki.videolan.org/X264_asm_intro/ [23:30:35 CET] <kierank> a little bit out of date [23:30:46 CET] <BBB> Mirage20: use gdb/lldb directly, and use stepi to step [23:31:25 CET] <kylophone> BBB: Thanks [23:33:21 CET] <Mirage20> ok thanks :) [00:00:00 CET] --- Sat Mar 11 2017

1 0

ffmpeg.log.20170310
by burek 11 Mar '17

11 Mar '17

[00:50:30 CET] <RossW> Anyone know how to force ffmpeg to use a specific output type of jpg, when writing to a pipe? [00:50:47 CET] <RossW> ffmpeg -i input.jpg -i watermark.png -filter_complex "overlay=10:10" -qscale:v 2 output.jpg writes a jpeg fine. [00:51:00 CET] <RossW> ffmpeg -i input.jpg -i watermark.png -filter_complex "overlay=10:10" -qscale:v 2 -f image2 pipe:1 outputs a file, but not a jpeg. [00:51:29 CET] <RossW> I can't find a -f jpg or -f jpeg type switch, but not through lack of searching! [00:51:39 CET] <relaxed> -f mjpeg [00:51:59 CET] <RossW> *facepalm*. of course, thanks, I'll try that. [00:57:34 CET] <RossW> you're a champ, relaxed. *thumbs up* [00:59:16 CET] <relaxed> \o [05:23:03 CET] <stl1303> anyone know why I might be getting frames out of order out of ffmpeg on h264 decoding? The timestamps of all the frames is out of order [05:25:36 CET] <klaxa> there is a difference between dts (decoding timestamp) and pts (presentation timestamp) [05:27:15 CET] <stl1303> Yeah. The presentation time stamps are out order. the video looks like it's constantly repeating itself [09:53:33 CET] <luc4> Hello! I would like to stream content using multicast RTP but accessing through a RTSP point. I created this conf file for ffserver but I probably did it wrong: https://paste.kde.org/p4lve2fi8. I can play the two rtp streams by using a rtp url, but I can't simply access rtsp://192.168.0.102:5554/bbb.sdp. Is what I'm trying to do possible somehow? [12:00:34 CET] <feliwir> Hey, i get this error when compiling ffmpeg with SDl2: [12:00:36 CET] <feliwir> SDL_config.h(37): fatal error C1189: #error: You should run hg revert SDL_config.h [12:09:02 CET] <feliwir> i think it's because i tried to compile ffplay with msvc [12:09:21 CET] <feliwir> it must be possible somehow or not? [12:33:43 CET] <feliwir> i give up. It's impossible to build ffmpeg with ffplay with visual studio [12:50:57 CET] <faLUCE> ciao Zuccace ;-) [13:09:58 CET] <Zuccace> Hi. [13:55:07 CET] <JEEB> feliwir: I don't think *anyone* has tested that configuration since usually everyone who uses FFmpeg with MSVC just needs the libraries :P [16:47:15 CET] <nightlingo> hi! [16:47:26 CET] <nightlingo> I need to be able to stream to stdout when converting into .mp4 format, for example: [16:47:26 CET] <nightlingo> ffmpeg -i file.avi -f mp4 - > file.mp4 [16:47:27 CET] <nightlingo> However, I get the following error: muxer does not support non seekable output - I get the reason why the mp4 writer doesn't support this. But is there any work around for this? I've beel searching for days! Thank you [16:49:40 CET] <alexpigment> nightlingo: i presume you're wanting to transcode, right? [16:50:11 CET] <nightlingo> alexpigment: not necessarily. most of the times I just want to mux audio and video, or split [16:50:43 CET] <alexpigment> does the same problem happen when you add "-c:v libx264"? [16:51:15 CET] <nightlingo> Ill try now [16:52:57 CET] <nightlingo> alexpigment: yes, same error [16:53:07 CET] <alexpigment> k, so it's not the input video format [16:53:23 CET] <nightlingo> yes, the problem is that ffmpeg cant write .mp4 to stdout [16:54:01 CET] <alexpigment> so this is out of my level of expertise, but the other thing i'd try is adding flags that make it seekable [16:54:28 CET] <nightlingo> alexpigment: but stdout is not seekable [16:54:43 CET] <nightlingo> alexpigment: how would you do that? [16:55:17 CET] <alexpigment> perhaps try "-movflags empty_moov" [16:55:18 CET] <furq> i take it that's not your actual command line [16:56:09 CET] <alexpigment> furq: are you thinking it's just that c:v and c:a arent specified? [16:56:43 CET] <furq> no i'm thinking that if it was then he could just do -i foo bar.mp4 and it would do the same thing except it would work [16:56:53 CET] <furq> but presumably it's not that simple [16:57:28 CET] <furq> if you really need to write to stdout then either use fragmented mp4 (-movflags frag_keyframe+empty_moov) or just use a different muxer [16:57:33 CET] <furq> mkv and mpegts can both handle that just fine [16:58:24 CET] <alexpigment> yeah, i didn't know if "frag_keyframe" mattered in this case, but "empty_moov" directly relates to the seek problem i would think [16:58:26 CET] <nightlingo> furq: I tried the mpegts container, but it doesnt work well on windows media player [16:58:38 CET] <furq> oh wow, windows media player [16:58:57 CET] <nightlingo> furq: yeah :( unfortunately some people still use that [16:59:15 CET] <furq> what works in windows media player depends on an infinite number of things [16:59:18 CET] <furq> including the phase of the moon [16:59:24 CET] <nightlingo> lol [16:59:41 CET] <alexpigment> furq: i won't get into it, but WMP a lot of advantages on Windows over other players. i wouldn't hate on anyone for using it, especially if they have interlaced content, or if they have an Nvidia graphics card [17:00:02 CET] <furq> do you mean advantages like not playing anything properly [17:00:18 CET] <alexpigment> no, advantages like actually doing properly deinterlacing out of the box without having to change settings [17:00:33 CET] <alexpigment> or like assuming the correct color range rather than forcing limited [17:00:36 CET] <furq> i'm pretty sure mpc-hc does that out of the box now [17:00:41 CET] <furq> and mpv does it if you hit d [17:01:04 CET] <alexpigment> sure, but the average person knows about WMP, VLC, and Quicktime. the latter are both horrible pieces of software [17:01:13 CET] <furq> all of those are horrible pieces of software [17:01:25 CET] <alexpigment> yes, but you can agree that WMP is clearly the best out of the three? [17:01:45 CET] <furq> i've not seen wmp since windows 7 [17:01:54 CET] <furq> i assume ms have made it better because it would be impossible for them to have made it worse [17:02:23 CET] <alexpigment> furq: i was really making a tangent. i stand behind my statements completely, but there's no need to go into it here [17:02:53 CET] <alexpigment> nightlingo: what happened when you tried the flags command? [17:03:05 CET] <furq> i have no idea what wmp will make of fmp4 [17:03:31 CET] <furq> i'm not sure that you can expect it to work everywhere that regular mp4 does [17:03:32 CET] <nightlingo> alexpigment: the empty_moov one? I had tried that in the past and it was behaving weird in both vlc and media player but I will try that again now [17:03:44 CET] <furq> you need frag_keyframe as well [17:03:57 CET] <nightlingo> furq: yes with that as well [17:04:09 CET] <nightlingo> it was the combination of those two options [17:04:28 CET] <furq> you do definitely need to output to stdout, right [17:04:47 CET] <nightlingo> furq: unfortunately yes [17:05:00 CET] <nightlingo> furq: its in the requirements [17:07:58 CET] <nightlingo> furq: Im sorry I just realized: I was using -c copy [17:08:20 CET] <alexpigment> -c:v copy or -c:a copy ? [17:09:12 CET] <nightlingo> furq: if I dont use this it works with both frag_keyframe and also the mpegts ways [17:09:23 CET] <nightlingo> furq: -c copy, both audio and video [17:09:54 CET] <alexpigment> oh weird, i didn't know you could do that. learn something new everyday :) [17:11:07 CET] <nightlingo> but I would rather do it using the copy option, otherwise it gets too cpu hungry :/ [17:12:23 CET] <alexpigment> that begs the question: what are the audio and video codecs in your original stream? [17:12:50 CET] <alexpigment> that was really the point of testing c:v libx264 earlier - to see if it was a problem with input codecs [17:14:24 CET] <alexpigment> at any rate, you might try doing -c:v copy and -c:a aac to rule out a problem with just the audio [17:14:38 CET] <nightlingo> alexpigment: Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1280x720 [SAR 1:1 DAR 16:9], 1053 kb/s, 30 fps, [17:14:49 CET] <nightlingo> and Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 125 kb/s (default) [17:14:55 CET] <alexpigment> weird [17:15:22 CET] <alexpigment> everything looks good with the codecs themselves, so i don't know why leaving out -c copy would make any difference [17:16:26 CET] <nightlingo> alexpigment: Im not very familiar with the codecs in general so I wouldnt know. I was hoping to simply copy the data into a different container, but it doesnt work. Maybe a work around would be to convert it with as little processing as possible somehow [17:16:55 CET] <alexpigment> well, you could use -c:v libx264 -preset veryfast [17:17:14 CET] <alexpigment> if quality is not a concern at all, then -preset ultrafast would be even quicker [17:17:54 CET] <alexpigment> and of course, specify your -crf or -b:v values to fit your needs [17:18:18 CET] <nightlingo> alexpigment: I would like to have the same quality as the input stream [17:18:31 CET] <alexpigment> is file size a concern? [17:18:46 CET] <alexpigment> rather, is bitrate a concern? [17:20:28 CET] <nightlingo> alexpigment: Im not sure. What I know is that I want to approximate as closely as possible the input streams quality and filesize [17:20:47 CET] <alexpigment> because a low CRF value would be perceptually identical to the original. try starting at -crf 15 and adjust from there. lower is better quality but increasingly ridiculous bitrates [17:21:26 CET] <alexpigment> well, i guess when you're re-encoding - and re-encoding using a fast x264 preset, getting both the same file size and quality is going to be difficult [17:21:49 CET] <alexpigment> then again, you do have the advantage of being able to use a "-profile:v high" [17:22:13 CET] <alexpigment> your input stream uses Main profile, and so it's a little less efficient with bitrate than it would be with High [17:22:54 CET] <nightlingo> alexpigment: oh so this means that if I do the conversion, Ill end up with a more efficient file than what I began with ? [17:23:06 CET] <alexpigment> not exactly [17:23:11 CET] <feliwir> so i right now someone online that can tell me how to compile ffplay with msvc? [17:23:15 CET] <feliwir> *is [17:24:04 CET] <alexpigment> what i'm saying is that transcoding between lossy formats is always a losing battle. you usually either give up quality or you give up file size. in this case, you want to maintain both the size and quality *and* you want it to be not very CPU intensive [17:24:48 CET] <alexpigment> but since your original video is using Main profile rather than High, you can transcode with High profile, which makes your tradeoffs a little less severe [17:25:06 CET] <nightlingo> alexpigment: oh ok I see. And how can I activate this high profile? [17:25:23 CET] <alexpigment> "-profile:v high" [17:25:47 CET] <nightlingo> alexpigment: should I use it in combination with the -c:v libx264 -preset veryfast options? [17:26:04 CET] <alexpigment> so as a whole, you could try "-c:v libx264 -crf 20 -preset veryfast -profile:v high" [17:26:20 CET] <nightlingo> alexpigment: cool, thanks! [17:26:21 CET] <alexpigment> and adjust the CRF lower if the quality isn't good enough for your needs [17:26:22 CET] <JEEB> profile:v high will do nothing [17:26:50 CET] <JEEB> you are using a preset that will not use high profile features [17:27:08 CET] <alexpigment> i'll defer to JEEB's expertise here [17:27:24 CET] <JEEB> and if you use high profile features then the encoder will pick that profile [17:27:34 CET] <nightlingo> JEEB: so how should I do it then? [17:28:20 CET] <JEEB> the first question is why not main profile if you're not using high profile features? [17:28:44 CET] <JEEB> the encoder is setting the compatibility of your stream according to your settings [17:28:52 CET] <alexpigment> that was my suggestion. i know that High is more efficient than Main to some degree (not to the level that Main is efficient over Baseline, of course) [17:29:25 CET] <alexpigment> i'm also curious to know why High profile features aren't used in this scenario. does veryfast disable them? [17:29:32 CET] <nightlingo> JEEB: Im not sure. What I want to do is to simply -c copy from mp4 -> mpegts. But this results in a file that windows media player has trouble working with. So Im looking for the nearest solution [17:30:12 CET] <JEEB> alexpigment: 8x8dct is pretty much the only feature requiring high profile [17:30:32 CET] <nightlingo> JEEB: do you think this is an indexing problem or something? maybe there is a way to fix it? Id really rather use -c copy than transcode [17:30:43 CET] <JEEB> nfi [17:31:49 CET] <JEEB> also I hope you're converting that mp4's avcc bit stream to annex b [17:32:19 CET] <JEEB> although that would make it pretty much unplayable in many players if you didn't [17:33:47 CET] <nightlingo> JEEB: how do I do that? [17:37:01 CET] <nightlingo> JEEB: my purpose is perform spliting on an .mp4 file and have ffmpeg output to stdout [17:37:43 CET] <nightlingo> JEEB: but without transcoding, it should be done by just copying [17:42:59 CET] <alexpigment> feliwir: i assume the answer's yes, but presumably you've seen these two resources? [17:42:59 CET] <alexpigment> http://ffmpeg.org/platform.html#toc-Microsoft-Visual-C_002b_002b-or-Intel-C… [17:43:04 CET] <alexpigment> https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC [17:43:48 CET] <feliwir> alexpigment, the second resource does never show how to compile ffplay with msvc [17:43:55 CET] <feliwir> it even explicitly disables it [17:44:21 CET] <alexpigment> what happens if you remove "--disable ffplay" [17:44:58 CET] <feliwir> i need to enable ffplay explicitly. And then it complains about missing SDL2 of course [17:45:39 CET] <feliwir> but there is no way for me to link SDL2 at any stage with that cumbersome buildsystem [17:45:55 CET] <alexpigment> gotcha. i just saw your question above and wanted to make sure you'd checked both of those guides. assuming you have, and you've enabled ffplay, i don't know what the problem would be [17:46:38 CET] <feliwir> the problem is that the only way for that buildsystem to find SDL2 is pkg-config. Pkg-config can't find SDL2 installation that was compiled with MSVC [17:48:03 CET] <alexpigment> i went through that a few days ago compiling on linux, specifically with "libass", "fontconfig", "libbluray" etc. i have no idea what the problem was - i just started from scratch and it worked the second time [17:48:35 CET] <alexpigment> having said that, i believe the problem was related to some .rc files being empty [17:48:53 CET] <alexpigment> not sure if that helps at all - i've never worked with Visual C [17:49:05 CET] <feliwir> the problem here is that it is technically impossible that the buildsystem ffmpeg used will allow me to link a correct SDL2 [17:49:46 CET] <feliwir> alexpigment, i can compile FFMpeg with Linux, MinGW and Visual Studio. But with visual studio ffplay is not compilable [17:50:12 CET] <alexpigment> fair enough. i don't have much to offer on this particular issue [17:50:56 CET] <feliwir> i wish ffmpeg would use CMake or something less Unix biased than Autotools [17:51:37 CET] <feliwir> no matter which project, every project that only used autotools is a pain on Windows [17:52:37 CET] <alexpigment> well i *end* up compiling ffmpeg on Linux for Windows because it was a hell of a lot easier (for me) than compiling natively on Windows [17:52:43 CET] <alexpigment> *ended up [17:52:52 CET] <alexpigment> so i can relate to some degree [17:53:27 CET] <feliwir> well it works relative well with mingw, but it's much smoother to work with Visual Studio on windows [18:25:52 CET] <furq> i've said this before, but i would like to extremely vote against cmake [18:25:59 CET] <furq> not that i think it's on the table [18:26:38 CET] <furq> also ffmpeg doesn't actually use autotools, the configure script is handwritten [18:36:26 CET] <c3r1c3-Win> cmake rocks... but I've been told that waf rocks more. ;-) [18:36:43 CET] <c3r1c3-Win> Really it depends on what you're looking for. [18:37:06 CET] <c3r1c3-Win> Do you want something that cross-platform and builds stuff easily on different OSes? Then CMake is pretty good. [18:37:42 CET] <c3r1c3-Win> Not saying that there aren't better solutions. [18:40:45 CET] <riataman> Hey [18:41:18 CET] <riataman> I'm trying to record AND display a rtsp stream. [18:41:31 CET] <riataman> for recording I'm using this line: ffmpeg -i rtsp://192.168.1.2:554/11 -c copy -an -map 0 -f segment -segment_time 10 -segment_format mp4 "out%03d.mp4" [18:41:58 CET] <riataman> Is there any way to "divert" the raw stream to a socket/pipe so I can play that using a video player? [18:42:08 CET] <riataman> while keeping the recording with segmentation? [18:47:26 CET] <riataman> ok, I may have figured that out https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs [19:31:14 CET] <ice9> is it possible to use ffmpeg to remove meta / exif data without making any codecs conversions? [19:58:32 CET] <kepstin> it's kind of hard to answer questions for people when they disappear after only 2 minutes :) [19:59:08 CET] <furq> hey come on [19:59:10 CET] <furq> that was 19 minutes [19:59:12 CET] <furq> a new record for patience [20:04:18 CET] <kepstin> ah, looked at the wrong leave time. [21:10:35 CET] <nightlingo> Hello, Im trying to understand how the mp4 format works. I read that ffmpeg cannot write mp4 to stdout because it requires a seekable stream so as to be able to go back and write the header. Is the heaer the moov atom, or the ftyp atom? [21:13:10 CET] <drv> you can look for avio_seek() in libavformat/movenc.c - all of those places need seekable output [21:17:50 CET] <nightlingo> drv: can you please explain this? is this a way to overcome the mp4 limitation about writting to non-seekable output? [21:48:49 CET] <Pandela> I got this weird error I thought I'd share when trying to use -codec copy with a gif to another gif [21:48:52 CET] <Pandela> Assertion video_par->format == AV_PIX_FMT_PAL8 failed at libavformat/gif.c:130 [21:59:48 CET] <llogan> Pandela: you should report it a bug on trac.ffmpeg.org. [22:00:28 CET] <Pandela> llogan: Will do [22:01:10 CET] <llogan> make sure to: 1) use the most recent ffmpeg you can (see FFmpeg download page for links to recent binaries if you can't compile) 2) show your actual command 3) provide the complete console output from the command. 4) provide the input file if it is required to reproduce the issue. [22:01:36 CET] <llogan> 5) use the code block button to properly format the command and console output. [22:02:03 CET] <llogan> 6) sacrifice a goat during the full moon [22:05:05 CET] <slalom> i always forget the last bit [22:07:32 CET] <llogan> possibly why it the bug was marked as "heretical" by the high inquisitor [22:21:09 CET] <kepstin> nightlingo: no, it's an inherent problem with the design of the mp4 container. [22:21:51 CET] <kepstin> nightlingo: there's a variation of mp4 which allows "fragmented" files, but it's not compatible with all that much iirc [22:22:21 CET] <nightlingo> kepstin: yeah I tried fragmented mp4s and dont work well with some players [22:22:55 CET] <nightlingo> kepstin: my purpose is to be able to stream a piece (split) of an .mp4 video to stdout [22:23:48 CET] <kepstin> nightlingo: why do you want to do that? [22:24:33 CET] <nightlingo> kepstin: im working on a media server [22:25:14 CET] <kepstin> but a "piece" of an mp4 file doesn't make sense [22:25:31 CET] <nightlingo> kepstin: the users of the media server require this functionality [22:26:02 CET] <kepstin> in order to stream an mp4 file for playback, you need some format info at the start of the file. but the mp4 spec is such that the place where this format info is stored also holds some info that can't be written until the entire stream data is known [22:26:06 CET] <kepstin> so... it can't be done [22:26:33 CET] <kepstin> either use a different format, or write the segment to disk temporarily before streaming it [22:26:54 CET] <nightlingo> kepstin: yes I would like to go for the second solution [22:27:14 CET] <nightlingo> kepstin: sorry, I misread [22:29:36 CET] <nightlingo> kepstin: I was thinking to find the mdat atoms that correspond to the requested timesplit and then patch the MOOV atom so that it points only the aforementioned atoms [22:30:17 CET] <kepstin> nightlingo: sure, but now you're in the realm of custom mp4 file manipulation; this isn't something you're gonna use ffmpeg for :) [22:31:19 CET] <nightlingo> kepstin: yeah, it seems like it. I started with ffmpeg that I guess I have to go for a custom solution, and this is the only channel I thought Id find people who would know about this stuff [23:05:21 CET] <obamoose> oh what [23:05:26 CET] <obamoose> there is an ffmpeg channel [23:05:28 CET] <obamoose> oh my [23:05:41 CET] <obamoose> hello! [23:05:53 CET] <obamoose> I'm having issues with looping files in a directory [23:06:16 CET] <obamoose> while true ; do find /home/me/cgn -name "*.mp4" | xargs - 0 -I ffmpeg -y -re -i -vcodec libx264 -preset veryfast -maxrate 3000k -bufsize 6000k -pix_fmt yuv420p -g 50 -c:a aac -b:a 160k -ac 2 -ar 44100 -f flv rtmp://a.rtmp.youtube.com/ ; done [23:06:21 CET] <obamoose> this is what I have right now [23:06:44 CET] <obamoose> and the error i'm getting is an infintely loooping terminal [23:10:16 CET] <diverdude> Hi, this creates a testvideo of resolution 320x240: ffmpeg -f lavfi -i rgbtestsrc -pix_fmt yuv420p -t 30 rgbtestsrc.mp4 I need to make a video of size 4096x3000 instead, it would be good to have some motion in the movie as well. Can i do that in ffmpeg? [23:13:18 CET] <thebombzen> obamoose: you should not be surprised by an infinitely looping terminal [23:13:26 CET] <thebombzen> you have while true; do ...; done [23:13:33 CET] <obamoose> I am new to ffmpeg ;_; [23:13:39 CET] <thebombzen> that has nothing to do with ffmpeg [23:13:59 CET] <thebombzen> while true; do ...; done says "loop what's inside infinitely." It's a shell script thing [23:14:13 CET] <obamoose> Oh that part I understand [23:14:25 CET] <obamoose> but it's supposed to infinitely loop the videos [23:14:39 CET] <obamoose> so I'm guessing I made an error with 'insiding' [23:14:53 CET] <thebombzen> what are you actually trying to do? [23:15:08 CET] <obamoose> Loop videos inside of the cgn directory infinitely [23:15:45 CET] <thebombzen> what does it mean to "loop videos" do you mean stream them one after another, and when you're done go back to the beginning? [23:15:51 CET] <obamoose> yessir [23:16:02 CET] <thebombzen> if that's true then why don't you pre-encode them [23:16:14 CET] <thebombzen> no need to encode them on the fly if you know the encoding settings [23:16:26 CET] <obamoose> aren't they already encoded when .mp4? [23:16:49 CET] <thebombzen> well you're transcoding them on the fly [23:16:49 CET] <obamoose> oh [23:17:02 CET] <obamoose> isn't this '-y -re -i -vcodec libx264 -preset veryfast -maxrate 3000k -bufsize 6000k -pix_fmt yuv420p -g 50 -c:a aac -b:a 160k -ac 2 -ar 44100 -f flv' the one doing the re-encoding? [23:17:13 CET] <diverdude> anyone? [23:17:47 CET] <thebombzen> diverdude: http://ffmpeg.org/ffmpeg-filters.html [23:17:54 CET] <thebombzen> obamoose: well no [23:18:01 CET] <thebombzen> it's not "the one" [23:18:15 CET] <thebombzen> and first of all, -i takes an argument [23:18:41 CET] <thebombzen> it sounds like you copy/pasted from several things without understanding what you're really doing [23:18:48 CET] <obamoose> indeed [23:18:49 CET] <obamoose> ;_; [23:20:54 CET] <thebombzen> I suggest you read this for a basic rundown [23:20:54 CET] <thebombzen> https://ffmpeg.org/ffmpeg.html [23:22:52 CET] <diverdude> this will make a 30 sec file yeah? ffmpeg -f lavfi -i allrgb -t 30 testsrc.mp4 [23:25:08 CET] <alexpigment> diverdude: yes [23:25:14 CET] <alexpigment> -t is the length in seconds [23:25:59 CET] <faLUCE> well, I succeeded in creating a < 100ms latency HTTP-MPEGTS h264 stream, WITHOUT zerolatency [23:26:01 CET] <faLUCE> !!! [23:26:31 CET] <alexpigment> faluce: nice! congrats [23:26:46 CET] <faLUCE> alexpigment: thnks, I'm goingo to publish all [23:27:02 CET] <BtbN> so you set the settings zerolatency would set for you yourself? [23:27:24 CET] <faLUCE> BtbN: what do you mean? [23:27:43 CET] <BtbN> It basically disables B-Frames/Reordering and lookahead. Which is just what you want for low latency [23:28:00 CET] <BtbN> I'd say sub 100ms is impossible without it [23:28:16 CET] <faLUCE> BtbN: yes, in fact I disabled B-frames. But I made many other tunes [23:28:36 CET] <BtbN> So what's the gain from not using lerolatency then? [23:28:41 CET] <BtbN> That's exactly what it exists for [23:28:45 CET] <BtbN> *zero [23:28:51 CET] <faLUCE> BtbN: first of all it's an AUDIO+VIDERO streaming [23:29:11 CET] <BtbN> audio isn't really critical in terms of latency [23:29:11 CET] <faLUCE> I obtained this low latency by making many tunes on the grabbing part [23:29:23 CET] <thebombzen> yea as long as you have opus you're fine [23:29:32 CET] <faLUCE> it's criticall if you don't have a good pollable mechanism in the API [23:29:49 CET] <BtbN> There are no B-Frames or reordering [23:29:53 CET] <BtbN> so nothing to look out for. [23:30:06 CET] <faLUCE> I implemented the alsa and v4l part, instead of using the ffmpeg wrapper [23:30:37 CET] <faLUCE> and I tuned all the buffers [23:31:55 CET] <faLUCE> the non-pollable grabbing part in libav is a big missing feature, IMHO [23:32:24 CET] <BtbN> "non-pollable"? [23:32:29 CET] <faLUCE> BtbN: yes [23:32:39 CET] <BtbN> I'm pretty sure you can just set it to non-blocking mode and then poll it all you want [23:32:57 CET] <faLUCE> BtbN: you can set it to non blocking, but you cant do any poll on it [23:33:21 CET] <BtbN> Of course, it will return instantly, so you can just poll if data is available, and go do other stuff if not. [23:33:41 CET] <faLUCE> BtbN: this means that you have 100% CPU [23:34:00 CET] <faLUCE> if you use non blocking feature [23:34:00 CET] <BtbN> so put some sensible sleep in there if everything returned empty [23:34:09 CET] <faLUCE> BtbN: sleep != polling [23:34:26 CET] <BtbN> polling without sleep is busy waiting, you don't want that [23:34:39 CET] <BtbN> You have a rough idea if when data will arrive, so use like a quarter of that time for the sleep [23:34:41 CET] <BtbN> *of [23:34:59 CET] <faLUCE> BtbN: that's not a fine implementation [23:35:18 CET] <BtbN> That's a pretty standard implementation [23:35:42 CET] <BtbN> And it's how polling works, so I don't see your point...? [23:36:09 CET] <faLUCE> BtbN: not really. Libalsa and v4l use the select() or poll() API. but when they are wrapped by libav this is not possible [23:36:59 CET] <BtbN> of course it's not. being able to use select() on something is a very specific case. libav* offers a generaliced API, which exists even on platforms without those calls [23:37:33 CET] <faLUCE> BtbN: I insist. it's a missing feature of libav, which adds unuseful delay [23:37:51 CET] <faLUCE> BtbN: note that in the recent libav API, the encoding part is pollable [23:37:56 CET] <faLUCE> but not the grabbing part [23:37:57 CET] <BtbN> libav is not going to add API that's specific to a single filter/input on a single OS [23:38:20 CET] <JEEB> it really depends on the use cases, generalize [23:38:22 CET] <JEEB> ability [23:38:28 CET] <JEEB> and care level of people [23:38:39 CET] <faLUCE> BtbN: but libevent is good for all the platforms [23:38:43 CET] <BtbN> I'd be surprised if you can select()/poll() encoders in libavc [23:38:47 CET] <JEEB> if you want to think of a new abstraction, design it and post on ffmpeg-devel [23:39:01 CET] <faLUCE> JEEB: in fact I made a library [23:39:03 CET] <JEEB> and then if people like it, implement [23:39:15 CET] <faLUCE> JEEB: I'll publish it ASAP [23:39:37 CET] <faLUCE> the only problem is that it's in C++, not C [23:39:37 CET] <BtbN> Most people would probably just put it in a thread and fire an event from there if new data arrived from a blocking call [23:39:47 CET] <faLUCE> BtbN: I avoided thread [23:39:58 CET] <BtbN> That's as cross-platform and straight forward as it gets [23:40:02 CET] <faLUCE> threads are weird [23:40:14 CET] <faLUCE> and they should not used for decoupling tasks [23:40:26 CET] <BtbN> Of course they should, that's the whole idea of them [23:40:26 CET] <JEEB> c++ will not go into FFmpeg, but for your own use or research I don't think anyone cares [23:40:50 CET] <faLUCE> BtbN: really not, they are not necessary for decoupling stuff [23:41:01 CET] <faLUCE> threads are conceived for other things [23:41:04 CET] <BtbN> But they make it easy and are convenient. [23:41:16 CET] <faLUCE> BtbN: I don't agree at all [23:41:33 CET] <BtbN> I won't stop you from making your life harder over that. [23:42:05 CET] <faLUCE> BtbN: on the contrary, I simplified all, by makiing a very easy event loop [23:42:19 CET] <faLUCE> anyway, I'll publish all [23:44:30 CET] <JEEB> btw, there's at least one protocol in lavf that does threads in itself [23:44:40 CET] <JEEB> have fun guessing which :P [23:45:47 CET] <faLUCE> JEEB: but it's reasonable that every codec/protocol uses internal threads. What is not reasonable, IMHO, is to use threads for decoupling functions/sources/cycles etc. [23:46:13 CET] <faLUCE> JEEB: for example AFAIK, x264 uses threads [23:46:30 CET] <JEEB> well, d'uh [23:46:31 CET] <BtbN> But that's exactly what they exist for. Let the OS scheduler take care of that stuff, instead of implementing half a scheduler yourself [23:46:42 CET] <faLUCE> BtbN: no [23:46:45 CET] <BtbN> yes [23:47:06 CET] <faLUCE> BtbN: threads are meant when you want to use the multicolre [23:47:09 CET] <faLUCE> multicore [23:47:22 CET] <faLUCE> not when you generally want to decouple functions [23:47:32 CET] <BtbN> That's what they are also usefull for. But they are just for everything that can happen at the same time. [23:47:42 CET] <BtbN> There is no RFC that defines what you are allowed to use threads for. [23:47:48 CET] <faLUCE> BtbN: please..... [23:48:23 CET] <faLUCE> anyway, think what you want. I'm not going to convince anyone [23:48:45 CET] <BtbN> I just think it's stupid to make ones life hard to strive for some weird ideal of not using threads for something they make super easy and clean. [23:49:30 CET] <BtbN> Of course you don't _need_ threads for anything. But they make a lot of stuff easier. [23:50:04 CET] <faLUCE> BtbN: not really, because threads appear to be easier at the beginning, but then they mess up the code. And having a GOOD event driven api is the EASIEST (for the user) and CLEANEST paradygm [23:50:31 CET] <BtbN> If you have a good event driven API(See for example Qt), threads become even better and easier. [23:50:52 CET] <faLUCE> if you have a good event driven API you don't use threads at all [23:51:02 CET] <BtbN> And why? [23:51:05 CET] <BtbN> Because you say so? [23:51:16 CET] <BtbN> If threads make something easier, or faster, you use them. [23:51:22 CET] <faLUCE> BtbN: ok, think what you want, this discussion is completely useless [00:00:00 CET] --- Sat Mar 11 2017

1 0

ffmpeg-devel.log.20170309
by burek 10 Mar '17

10 Mar '17

[00:00:08 CET] <BBB> (excuse my python) [00:01:50 CET] <BBB> nevcairiel: as for fixing fate, why do we print the raw side data buffer? why not create a nice print_spherical_data utility function that checks if the data size is correct and else errors out? and then use that in ffprobe [00:43:48 CET] <noobe1> Hello, anyone here knows of HEVC licensing and support by FFmpeg? I'm having very hard time finding whether HEVC would fall under LGPL or GPL when used with FFmpeg. [00:47:28 CET] <TD-Linux> noobe1, ffmpeg does not provide any patent licenses [00:47:33 CET] <jkqxz> There are quite a few different parts to consider. The ffmpeg decoder is LGPL. The x265 encoder is GPL, so ffmpeg built with support for it is GPL. The various hardware encoders (NVENC, VAAPI) are LGPL for the ffmpeg parts, but require external components which may have other licences. [00:48:53 CET] <noobe1> That clears up things. Do we keep this info documented somewhere in readme or source code? Or is just "known"? [00:50:40 CET] <llogan> LICENSE.md has some info. you can also just view the source code of the particular component you are interested in. the header will contain license info. [00:50:42 CET] <jkqxz> Which part? (I'm not sure whether that was meant to be a patent or a copyright question.) [00:51:18 CET] <noobe1> I'm intereted in decoding part (playback) for now. Which files woudl that be? [00:53:08 CET] <jkqxz> Unless you use hardware, decoding is all part of libavcodec so the top-level LGPL licence applies (i.e. LICENSE.md). [00:53:14 CET] <iive> noobe1: usually GPL portions require you to use --enable-gpl configure option. [00:53:15 CET] <noobe1> BTW, I just downloaded HEVC demo file from http://demo-uhd3d.com/fiche.php?cat=uhd&id=101 and latest FFmpeg release doesn't play it. Is there any suggested test files? [00:54:01 CET] <noobe1> hmm...maybe 3D is a problem...I'll try different files [00:57:14 CET] <jkqxz> Works for me. [00:59:28 CET] <noobe1> looking at license.md, it says "the following libraries are under GPL": - libx264 [00:59:28 CET] <noobe1> - libx265 [00:59:41 CET] <noobe1> are those used for decoding or encode? [00:59:54 CET] <kierank> enode [00:59:56 CET] <kierank> c [01:00:41 CET] <noobe1> alright, how can I tell which H264/H265 *.c file is used for decoding then? [01:02:04 CET] <jkqxz> Primarily libavcodec/hevc*.c, but it depends on a lot of code in other files as well (non-H.265 specific support stuff). [01:02:09 CET] <unholy_me> while registering my filter, running make it says undefined reference to ff_(file name). Any idea why? [01:02:25 CET] <Compn> in which file [01:02:39 CET] <jkqxz> You added it to allfilters.c but didn't add it to the Makefile? [01:02:48 CET] <unholy_me> no I added it to both [01:03:05 CET] <unholy_me> makefile and allfilters.c [01:03:39 CET] <jkqxz> Did you rerun configure so that the config option for it exists? (It is made by parsing allfilters.c.) [01:04:15 CET] <unholy_me> yup when config runs, my new filter is shown on the list of available filters [01:04:30 CET] <jkqxz> Does it get built by make? [01:04:41 CET] <unholy_me> nope, thats the problem [01:05:06 CET] <unholy_me> it says undefined refernce to ff_(my filter) [01:05:35 CET] <jkqxz> You added a line like OBJS-$(CONFIG_BLAH_FILTER) in the makefile, is CONFIG_BLAH_FILTER set in your config.h? [01:06:55 CET] <unholy_me> okay just ran a make -n [01:07:01 CET] <unholy_me> problem solved [01:07:21 CET] <unholy_me> CONFIG_BLAH_FILTER --- didnt write filter :P [01:07:26 CET] <unholy_me> sorry [03:18:15 CET] <RiCON> BtbN: npp doesn't support p010le or is it just scale_npp? [03:37:34 CET] <c3r1c3-Win> BtbN: Are you the same BtbN that hangs (or used to hang out) in OBS chat? [07:20:31 CET] <cone-345> ffmpeg 03Muhammad Faiz 07master:53a5cea47861: swresample/resample: do not allow odd filter_length [07:23:53 CET] <philipl> BtbN: If it's a driver bug, then me on linux vs you on windows would be a big difference. I'll try and verify I can reproduce with the basic sample. [07:28:18 CET] <philipl> BtbN: so, I got it to lock up immediately. [07:28:26 CET] <philipl> ffmpeg -hwaccel cuvid -c:v mpeg2_cuvid -i burosch2.mpg -flags +ilme+ildct -c:v h264_nvenc -preset slow -rc vbr_2pass -rc-lookahead 10 -b:v 2M -refs 7 -bf 0 -c:a copy -c:s copy -map 0 bob.mkv [07:28:44 CET] <philipl> If I do that with -bf 1, I get 'No free surfaces'. [07:28:53 CET] <philipl> Linux, 378.13, GTX1080 [07:40:47 CET] <rcombs> ubitux: remind me what happened to subs-in-lavfi [07:47:00 CET] <ubitux> i got busy with the merges, then i had more important stuff to do [07:56:31 CET] <uu8> I have been able to debug ffmpeg with gdb but when the process become threaded at conversion my debug does not enter to the threads [07:57:02 CET] <rcombs> anything you need from me? [08:01:31 CET] <uu8> so, I can't audit the part of the code I am interested in [08:47:08 CET] <flux> uu8, so have you looked into gdb and threaded debugging? although disabling threading at compile time might be a better alternative. [08:49:41 CET] <wm4> you can just use -threads 1 if you really think that's the problem [10:21:06 CET] <cone-345> ffmpeg 03wm4 07master:fcfc78cbabb6: aacdec: do not mutate input packet metadata [10:53:35 CET] <wm4> is libfdk-aacenc still relevant for anything? [10:55:08 CET] <kierank> He-aac encoding [10:55:25 CET] <wm4> the native encoder doesn't support itß [10:55:29 CET] <wm4> ? [10:59:19 CET] <JEEB> wm4: yea [10:59:37 CET] <JEEB> that said I've not really used HE-AAC for much [10:59:45 CET] <JEEB> although that's probably due to not doing radio yet [10:59:57 CET] <JEEB> (that said for radio I might just bite the bullet and do opus) [11:00:01 CET] <wm4> yeah, who even wants HE [11:00:11 CET] <kierank> Broadcast... [11:00:28 CET] <wbs> isn't it kinda useful for low-bitrate things? [11:00:31 CET] <JEEB> yes [11:00:44 CET] <JEEB> it will rape the sound but you can get similar bit rates out of it as low rate opus [11:01:12 CET] <JEEB> at which point just doing sw decoding of opus in my opinion is a better alternative unless none of the clients can support it [11:01:48 CET] <kierank> JEEB: I have tried to ask your employer to support it [11:02:11 CET] <kierank> A couple of years ago [11:11:50 CET] <JEEB> :D [11:13:02 CET] <rcombs> have there been listening tests of the current native encoder vs FDK at QuickTime? [11:13:30 CET] <rcombs> my impression is that it's thought to be on-par with those, but I don't know if there's data to confirm that [11:14:22 CET] <JEEB> hydrogenaudio kept doing those tests [11:28:29 CET] <nevcairiel> last i heard some claimed fdk was still better, but not by much [11:33:29 CET] <furqan> i want to concatenate multiple video with different format into one singe file format [11:33:46 CET] <furqan> could anyone give me some directions? [11:34:17 CET] <JEEB> this is a development channel, usage is on #ffmpeg [11:35:26 CET] <furqan> no, i am using ffmpeg with c++ [11:38:08 CET] <JEEB> that is still usage [11:38:20 CET] <JEEB> this is for development of the FFmpeg's libraries themselves [11:38:52 CET] <furqan> ok [11:38:59 CET] <furqan> i will go there than [11:39:01 CET] <furqan> thanks [13:28:48 CET] <adeel1> durandal_1707: so, apprently, the code was correct before. The reason that one picture was showing completely black was that it's color was Black. Yes the alphabet A written in black -__ [13:34:34 CET] <durandal_1707> you need to rush, because another student already did what you need to do [13:51:25 CET] <adeel1> durandal_1707: I'm having a few issues moving the code to its previous state. Could you please take a look? https://gist.github.com/adl1995/b19bf5bd0d728abc4e1549ba3cd18fa8 [13:56:19 CET] <stevenliu> Hi ,Mark Thompson here? [13:56:32 CET] <wm4> that's jkqxz [13:57:38 CET] <stevenliu> [hevc_qsv @ 0x22fe140] Initialized an internal MFX session using hardware accelerated implementation [hevc_qsv @ 0x22fe140] Using the constant bitrate (CBR) ratecontrol method [hevc_qsv @ 0x22fe140] Selected ratecontrol mode is not supported by the QSV runtime. Choose a different mode. [13:57:45 CET] <stevenliu> When i use hevc_qsv [13:58:08 CET] <stevenliu> avbr and cbr all of them give me this message, is that mean my cpu cannot support hevc? [13:58:23 CET] <stevenliu> Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz [13:58:41 CET] <stevenliu> I'm using git clone last commit ffmpeg code [14:01:07 CET] <jkqxz> Do you have the plugin? [14:01:28 CET] <stevenliu> ffmpeg_g -v verbose -y -i /home/centos/ffmpeg/10M1080P.mp4 -an -c:v hevc_qsv -load_plugin hevc_hw -b 5M -maxrate 5M -look_ahead 0 out.mp4 [14:02:15 CET] <jkqxz> (I assume it works for you with H.264?) [14:02:17 CET] <stevenliu> when use hevc_sw it cannot load plugin [14:02:17 CET] <stevenliu> Could not load the requested plugin: 2fca99749fdb49aeb121a5b63ef568f7 [14:02:37 CET] <jkqxz> Yeah, you only get the software plugin on windows. [14:02:43 CET] <stevenliu> maybe h264 is soft codec? default [14:03:03 CET] <wm4> wait what, so it uses hw by default, but the plugin provides a sw encoder? [14:03:17 CET] <stevenliu> My system is Linux localhost 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [14:04:54 CET] <stevenliu> 30208 root 20 0 1599508 241328 6336 S 669.0 3.1 2:14.26 ffmpeg_g frame= 682 fps= 27 q=-0.0 size= 16154kB time=00:00:26.88 bitrate=4923.1kbits/s speed=1.06x [14:05:17 CET] <stevenliu> When i run h264_qsv to transcode , the cpu usage is 669% [14:05:18 CET] <jkqxz> It provides software implementations for some of the codecs, yeah. You have to actively pick hardware. [14:06:31 CET] <jkqxz> (The choice is at <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/hwcontext_qsv.c;h=…>, you can pick one explicitly by passing the device argument to av_hwdevice_ctx_create().) [14:07:13 CET] <jkqxz> stevenliu: That sounds like it's always picking software. Does your VAAPI setup work? [14:08:54 CET] <stevenliu> I don't know how to check if vaapi have been setup work :( [14:10:11 CET] <jkqxz> Does running ffmpeg like that give you the stderr output from libva saying it loaded iHD_drv_video.so? [14:10:50 CET] <stevenliu> No, [14:11:02 CET] <stevenliu> configuration: --enable-libmfx [14:11:18 CET] <stevenliu> this is my ffmpeg build configure [14:14:06 CET] <jkqxz> Hmm. Does "./ffmpeg_g -y -c:v h264_qsv -hwaccel qsv -i any_h264_file.mp4 -an -c:v hevc_qsv -load_plugin hevc_hw -b 5M -maxrate 5M out.mp4" do the same thing? [14:15:19 CET] <stevenliu> rebuilding ffmpeg with configure --enable-libmfx --enable-vaapi [14:16:08 CET] <stevenliu> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/root/facebook.mp4': Metadata: major_brand : isom minor_version : 1 compatible_brands: isomavc1 creation_time : 2015-02-02T18:19:19.000000Z Duration: 00:45:02.06, start: 0.000000, bitrate: 2708 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x714 [SAR 1:1 DAR 640:357], 2576 kb/s, 25 fps, 25 tbr, 25k tbn, 50 tbc (default) [14:16:32 CET] <stevenliu> wait [14:16:37 CET] <stevenliu> let me try it [14:17:44 CET] <stevenliu> Press [q] to stop, [?] for help [AVHWDeviceContext @ 0x31a79a0] Cannot open X11 display . [AVHWDeviceContext @ 0x31a79a0] Opened VA display via DRM device /dev/dri/renderD128. libva info: VA-API version 0.99.0 libva info: va_getDriverName() returns 0 libva info: User requested driver 'iHD' libva info: Trying to open /opt/intel/mediasdk/lib64/iHD_drv_video.so libva info: Found init function __vaDriverInit_0_32 libva info: va [14:17:49 CET] <jkqxz> Standalone software encode or decode relies on the library to do the hardware setup. The hwaccel setup does it explicitly with the VAAPI or DXVA2 child device via hwcontext, so it might be better. (I think other people have had this problem in #ffmpeg, though I never go to the bottom of why.) [14:18:00 CET] <stevenliu> [AVHWDeviceContext @ 0x31a79a0] Initialised VAAPI connection: version 0.99 [AVHWDeviceContext @ 0x31a79a0] Matched "16.5.55964-ubit" as known driver "Intel iHD". [AVHWDeviceContext @ 0x2f35ec0] Matched "16.5.55964-ubit" as known driver "Intel iHD". [14:20:03 CET] <jkqxz> (<https://lists.libav.org/pipermail/libav-devel/2017-March/082788.html> (and the following two patches) are trying to fix that by allowing you to set the device explicitly for the non-hwaccel case.) [14:22:36 CET] <stevenliu> ok, let me try it, thank you Mark [14:34:45 CET] <wm4> BBB, ubitux, nevcairiel: would you say disabling merging side data by default needs a major API/ABI bump? [14:34:50 CET] <wm4> because michaelni argues so [14:35:25 CET] <BBB> I would say that adding side data merging should require a major bump [14:35:38 CET] <BBB> if it did, then removing it also needed a major bump [14:35:45 CET] <BBB> if it didnt, then neither does this [14:35:56 CET] <adeel1> BBB: are you also mentoring the XPM decoder/encoder project for GSoC? [14:36:00 CET] <BBB> adeel1: no [14:36:02 CET] <wm4> BBB: there wasn't even a minor bump, but it was in 2011 [14:36:13 CET] <BBB> wm4: 2011 is not an excuse [14:36:29 CET] <wm4> BBB: well, apparently the excuse works for michaelni? [14:36:36 CET] <BBB> lets vote [14:36:59 CET] <ubitux> wm4: i believe that whatever bad decision happened in the past should not encourage any new one in the present: any api/abi break should be protected [14:37:13 CET] <wm4> ubitux: ok, but is it an API/ABI break? [14:37:24 CET] <wm4> especially the claim that it's an ABI break is ridiculous AFAIK [14:37:30 CET] <wm4> also, API users had 6 years to adapt [14:37:41 CET] <wm4> (why do I have to wade through this bullshit...) [14:38:27 CET] <ubitux> i don't know the details of the issue, but figuring out if you're breaking the API or ABI shouldn't be that hard; or is it? [14:38:52 CET] <ubitux> if it changes the behaviour for the apps, yes it's an API break, if some apps needs recompilation, yes that's an ABI break [14:39:01 CET] <stevenliu> Thanks @jkqxz, It's work now [14:39:05 CET] <BBB> its not an abi break by that [14:39:06 CET] <ubitux> i don't think it's rocket science [14:39:21 CET] <BBB> as for api, yes, behaviour changes [14:39:36 CET] <ubitux> well then you have my answer [14:39:55 CET] <ubitux> which is pretty simple API change = protect it [14:40:03 CET] <durandal_1707> adeel1: whats so hard? the task is rather trivial [14:40:13 CET] <wm4> it breaks API users which don't use the API correctly, but only in some minor cases [14:40:26 CET] <wm4> (side data isn't that common, that's part of the concept) [14:40:28 CET] <adeel1> durandal_1707: I was getting confused. Let me give it a try again. [14:41:12 CET] <wm4> ubitux: currently packets from libavformat have AVPacket.side_data unset, even if there's side data... is thia what you expect? [14:41:15 CET] <wm4> *this [14:41:49 CET] <ubitux> it doesn't matter what a developer expect: what matters is what current applications do [14:41:59 CET] <ubitux> is the change going to break some or not? [14:42:14 CET] <ubitux> did we ever warrant such change? [14:42:49 CET] <ubitux> am i being unreasonable? i don't understand why there is a debate [14:43:01 CET] <ubitux> every api change we did was motivated by misdesign from the past [14:43:04 CET] <wm4> I don't understand why there's a debate either [14:43:07 CET] <ubitux> why is this an exception now? [14:43:21 CET] <wm4> the API is that AVPacket.side_data is set if there's side data [14:43:27 CET] <wm4> this was broken with this merge side data hack [14:43:29 CET] <wm4> I'm fixing it [14:43:30 CET] <wm4> that's all [14:44:31 CET] <adeel1> durandal_1707: does changing data[1] to data[0] make any sense? I ask this because we are accessing 0th index in the height width loop and 1st index in when storing rgba. [14:45:38 CET] <durandal_1707> adeel1: 1 holds indexes for pal8 and 0 hold palette colors [14:46:04 CET] <adeel1> durandal_1707: oh, right. [14:46:06 CET] <durandal_1707> other way around actually [14:46:28 CET] <wm4> ubitux: also, API users which wanted to work with Libav had to respect side data anyway [14:46:38 CET] <durandal_1707> this is specific to only pal8 though [14:48:18 CET] <ubitux> wm4: i don't think libav users are a majority, and i think a fix that change API likely to break apps needs special care for the user [14:48:30 CET] <ubitux> because we shit on the users 6 years ago means that we should do it again [14:48:37 CET] <ubitux> doesn't* mean [14:49:03 CET] <wm4> I'm not talking about shitting on users, but _stopping_ shitting on users [14:50:34 CET] <RiCON> it's still different behavior so isn't that still an API break? [14:50:55 CET] <wm4> different behavior is not necessarily an API break [14:51:42 CET] <wm4> also I wonder what's the purpose of this discussion... if you argue that it will break some API users, then that's going to happen at the next major bump anyway [14:51:46 CET] <wm4> and without warning [14:51:48 CET] <wm4> so why delay it [14:52:00 CET] <wm4> just don't backport it to a stable release [15:04:34 CET] <iive> imho, the merge functions should be deprecated first [15:04:46 CET] <iive> and removed/disabled on next major bump [15:05:03 CET] <iive> just like any API change that could break api users. [15:07:28 CET] <wm4> they don't need to be removed [15:15:10 CET] <iive> there is flag to disable them, if the program wants it [15:26:02 CET] <wm4> iive: I know that [16:10:05 CET] <BBB> michaelni: why are you arguing with a real, valid, easily addressable review point? [16:11:22 CET] <BBB> michaelni: just address the review comment as I suggested in my review. this is trivial, quick and makes the code better. why not just do it? why argue [16:14:49 CET] <durandal_1707> but there must be always oposition for every single ugly thing [16:15:10 CET] <microchip_> guys, latest git ffmpeg has the stream mapping placed above. Known bug? http://pastebin.com/g4LnwAiH [16:16:08 CET] <wm4> where's the bug? the first line? [16:16:46 CET] <microchip_> wm4: stream mapping info used to be just above the encode status info. Now it's before init of libx264 and the other info [16:17:53 CET] <BtbN> yes, the init order changed, so the output did as well [16:18:06 CET] <BtbN> Not a bug, the ffmpeg output is in no way standardized [16:18:12 CET] <microchip_> ic [16:18:48 CET] <microchip_> looks strange now, tho [16:28:30 CET] <cone-123> ffmpeg 03wm4 07master:f5da453b068f: concatdec: pass AVFormatContext flags to sub demuxer [16:28:31 CET] <cone-123> ffmpeg 03wm4 07master:597c6b789efb: hls: pass AVFormatContext flags to sub demuxer [16:28:51 CET] <ubitux> wm4: yes, having it an next major bump is fine, as long as it's documented (doc/APIChanges, Changelog, self-doc etc) [16:29:43 CET] <BtbN> microchip_, the input is listed first now. Seems the way more natural order to me? [16:30:57 CET] <microchip_> BtbN: well, now I have to scroll up to see the stream mapping info and the text "Press [q] to stop, [?] for help". Doesn't feel "right" [16:31:15 CET] <BtbN> That message has always been there [16:32:47 CET] <microchip_> i guess i'm used to the old way :) [16:47:12 CET] <philipl> BtbN: I forget - were you still looking for an opinion from me on the resize/crop patch? [16:47:15 CET] <philipl> I'm ok with it [16:47:26 CET] <BtbN> Yeah, specially if I messed up the logic somewhere [16:47:38 CET] <BtbN> It seems to work fine in my tests [16:47:38 CET] <philipl> where's the current version? [16:51:13 CET] <philipl> I can only see Miroslav's original on the list. [16:51:21 CET] <philipl> Yours is on a github branch I assume? [16:58:59 CET] <BtbN> philipl, yes, HEAD on my github [17:00:34 CET] <michaelni> BBB, because your assumtation is wrong, iam not a clown [17:01:34 CET] <BBB> michaelni: assume for a second that there is no assumption... [17:01:53 CET] <BBB> michaelni: assume for a second that Im just trying to do a fair, honest review of a patch and I think theres an issue with it [17:02:51 CET] <michaelni> BBB, iam happy to change it, i just disagree that theres a real issue in the patch [17:03:07 CET] <BBB> I think youre trying to say that problem was there before the patch also, right? [17:03:30 CET] <BBB> but hasnt the agreement always been that if we pick up on an issue in a patch review, and it is trivially addressed, that thats OK to address in the same patch cycle? [17:03:46 CET] <BBB> for the benefit of making the code better overall at virtually no cost to anyone? [17:06:18 CET] <michaelni> BBB you speak about a memory issue "You know very well that this makes the memory issue go away", there is no memory issue in this testcase, its a timeout, taing too much time [17:06:47 CET] <BBB> fine, call it a MC issue then [17:06:55 CET] <BBB> you understand the issue Im pointing out right? [17:06:58 CET] <BBB> or, rather [17:07:06 CET] <BBB> do you agree the issue Im pointing out exists? [17:07:37 CET] <michaelni> BBB, i think i can guess what you mean but i do not know if such a issue exists or not [17:08:20 CET] <michaelni> i assumed there was a "check "somewhere preventing reference frames to missmatch the current frames resolution [17:09:16 CET] <BBB> I dont see such a check in vp56_render_mb() [17:09:32 CET] <BBB> and vp56_conceal_mb() litrally just derives a MV and calls render() [17:10:32 CET] <michaelni> I see checks for VP56_SIZE_CHANGE which run av_frame_unref() [17:10:52 CET] <michaelni> i dumbly assume these kill reference frames on a resoltion change [17:10:54 CET] <BBB> Im also frowning @ if (s->mb_width > 1000 || s->mb_height > 1000) { error } [17:12:06 CET] <michaelni> that seems there since 2006 and the initial implementation it seems [17:14:49 CET] <BBB> why is have_undamaged_frame never unset? [17:16:04 CET] <BBB> if you unset have_undamaged_frame in size_change, doesnt that fix the issue then? [17:16:17 CET] <michaelni> it should [17:16:32 CET] <BBB> sounds nicer? [17:16:35 CET] <michaelni> i l try that, that would be simpler [17:16:50 CET] <michaelni> and nicer, yes [17:18:51 CET] <BBB> ok, I think that addresses my issue also, so no other comments [17:18:57 CET] <BBB> (from me at least) [17:19:13 CET] <michaelni> great, ill post a patch once i tested it [17:34:26 CET] <cone-123> ffmpeg 03wm4 07master:f940492bb241: avcodec: clarify some decoding/encoding API details [17:37:37 CET] <wm4> fritsch: I hope this commit makes it clearer ^ [18:09:50 CET] <cone-123> ffmpeg 03James Almer 07master:58eb0f57f670: avformat/matroskaenc: add support for Spherical Video elements [18:28:55 CET] <BBB> atomnuker: do you want to guide rajesh through the qualification task also? then Ill take care of the other guy (mirage) [18:30:43 CET] <BBB> Gramner: so how do you deal with avx laning in palignr for directional intra prediction? [18:30:50 CET] <BBB> (or pshufb) [18:31:11 CET] <BBB> it seems to me that laning totally destroys the use of palignr :-/ [18:38:34 CET] <philipl> BtbN: looks alrighy. [18:38:54 CET] <BtbN> good, thanks. I'll just go ahead and push. [18:39:36 CET] <BtbN> hm, if configure would be fast on cygwin, this would be so nice for building [18:39:50 CET] <BtbN> make is down to less than one minute, but configure... [18:45:47 CET] <AreaScout> Hi all, if i use FFmpeg > then 2.8 FF_THREAD_FRAME doesn't look to use all my cores on decoding, with <= 2.8 everything is ok, did i miss some API changes in the new versions, is it different to handle ? [18:46:12 CET] <AreaScout> code is here: https://github.com/AreaScout/moonlight-embedded/blob/master/src/video/ffmpe… [18:47:04 CET] <AreaScout> and codec is h264 [18:48:15 CET] <wm4> if nobody knows/replies, it'd be good if you could bisect it [18:48:32 CET] <BtbN> AreaScout, did the speed decrease, or just the CPU usage? [18:49:48 CET] <AreaScout> speed decrease and the cause was less core balance i think [18:51:46 CET] <BtbN> have you tested master? [18:53:36 CET] <AreaScout> yes i am much faster then master because they doesn't use opengles2 on SDL2 like my hardware does and they use slices, and slices are in the case of my hardware much slower [18:54:07 CET] <BtbN> what? [18:55:42 CET] <AreaScout> master uses slice threading and this is slower on my single board computer, well it was now everything higher then 2.8 is also slow [18:56:10 CET] <AreaScout> i use frame threading [18:57:09 CET] <AreaScout> sorry you mean ffmpeg master and i thought you mean moonlight-embedded master ^^ :D [18:57:26 CET] <AreaScout> well yes i tried FFmpeg master also [18:57:53 CET] <wm4> is there slice rendering involved? [18:58:08 CET] <wm4> (via the draw_horiz_band or whatever callback) [18:58:16 CET] <AreaScout> yes but on a lower level [18:58:26 CET] <wm4> huh, meaning? [18:58:31 CET] <AreaScout> the GPU driver does [18:58:44 CET] <AreaScout> but i can feat the driver only with full frames [18:59:05 CET] <AreaScout> thats the reason i do frame threading [19:00:47 CET] <AreaScout> frame threading looks like this with 2.8 http://www.areascout.at/IMG_1364.PNG and everything higher then 2.8 looks like this https://www.areascout.at/IMG_1365.PNG [19:00:55 CET] <adeel1> durandal_1707: I've tried manipulating the data array, but the decoded image still displays distotred. Could you please take a look? [19:02:30 CET] <AreaScout> i have to explain that core 5-8 is a separate CPU A15 and core 1-4 is CPU A7 [19:02:49 CET] <adeel1> durandal_1707: https://gist.github.com/adl1995/b19bf5bd0d728abc4e1549ba3cd18fa8 [19:03:58 CET] <AreaScout> on the first picture FFmpeg runs on the second CPU (A15) well balanced [19:04:21 CET] <AreaScout> on the second also but badly balanced [19:08:43 CET] <cone-123> ffmpeg 03Timo Rothenpieler 07master:5cd3cd5b6872: avcodec/cuvid: add support for cropping/resizing [19:09:26 CET] <durandal_1707> adeel1: how distorted? [19:09:46 CET] <adeel1> durandal_1707: I get purple boundries. [19:10:01 CET] <adeel1> durandal_1707: at one point I got the full image, but I changed some code and it broke. [19:10:07 CET] <durandal_1707> change order of rgba entries in first for loop [19:10:49 CET] <adeel1> durandal_1707: yes, already tried that. It only changes the colour of the distored image. [19:13:22 CET] <atomnuker> BBB: sure, but neither of those have CC'd me in any emails [19:13:42 CET] <BBB> rajesh has [19:14:03 CET] <BBB> emails is from 6 days ago [19:14:03 CET] <atomnuker> since you ran out of qualification tasks what do you plan to give mirage? [19:14:20 CET] <BBB> maybe something avx2 in vp8? [19:14:37 CET] <atomnuker> that'd be cool [19:14:50 CET] <BBB> also mildly useless [19:14:55 CET] <BBB> but I guess its the idea that counts at this point [19:15:36 CET] <durandal_1707> adeel1: it happens with all images? [19:15:40 CET] <BBB> if you want to search your inbox, the name of the student is Rajesh kumar Sahu [19:15:43 CET] <atomnuker> VP8 is massively used still and doesn't have any hwaccel [19:15:44 CET] <BBB> he CCed you [19:15:49 CET] <atomnuker> (yep, I found it) [19:15:51 CET] <BBB> cool [19:15:57 CET] <BBB> what will you give him as a qual task? [19:16:21 CET] <atomnuker> I think a forward haar transform for the vc2 encoder [19:16:49 CET] <adeel1> durandal_1707: for one I get completely black (this might be because the actual image is black), and for the other I get purple boundaries as I mentioned above. [19:17:14 CET] <durandal_1707> and others? [19:17:37 CET] <BBB> atomnuker: cool [19:17:48 CET] <durandal_1707> give link to them [19:22:18 CET] <adeel1> durandal_1707: https://gist.github.com/adl1995/793ee47bdfd6bf4307e63e20ba65c78d (distorted), https://github.com/ifwe/wx/blob/master/samples/sample.xpm (black) [19:31:43 CET] <durandal_1707> adeel1: make colors name first character uppercase [19:31:50 CET] <durandal_1707> and try again [19:34:54 CET] <adeel1> durandal_1707: I have changed "h c #ffffff" to "H c #ffffff", (and remaining), but still same issue [19:36:51 CET] <durandal_1707> not that [19:37:08 CET] <durandal_1707> thats not color name [19:44:22 CET] <adeel1> durandal_1707: Is this it #8c94bd? <- that's the value, I think. [19:44:49 CET] <durandal_1707> not that [19:45:05 CET] <durandal_1707> name like red green.... [19:47:16 CET] <adeel1> durandal_1707: but that is only in parseutils.c file and first char is already uppercase [19:49:53 CET] <durandal_1707> no [19:50:04 CET] <durandal_1707> in xpm files [19:50:24 CET] <wm4> michaelni: so is that ffmpeg.c/ffprobe.c patch agreeable? [19:50:53 CET] <adeel1> durandal_1707: cant find color name in xpm file [19:51:24 CET] <adeel1> wait [19:51:48 CET] <adeel1> color names are only define in one xpm file (the github link) [19:51:52 CET] <adeel1> defined* [19:55:02 CET] <adeel1> durandal_1707: not getting any output: console shows this nan M-V: -0.000 fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0 [19:55:29 CET] <durandal_1707> with window? [20:00:49 CET] <adeel1> durandal_1707: no, not getting any window either [20:01:24 CET] <durandal_1707> then debug where it hangs [20:02:15 CET] <adeel1> durandal_1707: not sure how that's done. [20:02:33 CET] <durandal_1707> learn [20:05:23 CET] <adeel1> durandal_1707: would I have to make a debug version explicitly? [20:05:57 CET] <durandal_1707> code is simple add printfs [20:21:04 CET] <michaelni> wm4, please give me and others some time to look at and test it, you just posted it a few hours ago [20:30:46 CET] <adeel1> durandal_1707: I have added a TEST(i) output at the beggining of each func call and they all seem to get called. [20:31:12 CET] <durandal_1707> and loops? [20:35:39 CET] <adeel1> durandal_1707: just added printf to them. it seems the inner for loop breaks gets stuck at j = 5 [20:52:37 CET] <durandal_1707> adeel1: inspect why [21:07:14 CET] <BBB> Im starting to get the hang of avx2, the magic of ignoring lanes is in using vperm2i128 sparsely and correctly [21:07:25 CET] <BBB> if only they documented this better [21:07:44 CET] <BtbN> You happen to know some tool to bench avx and avx2 stuff? [21:07:55 CET] <BtbN> Want to know what this 1800X is actually capable of with them [21:08:20 CET] <jamrial> BtbN: use ffmpeg's checkasm [21:08:45 CET] <jamrial> see if the avx/avx2 functions are faster or not than the <=sse4 ones [21:09:19 CET] <BtbN> Is it built by default? [21:09:24 CET] <jamrial> yes [21:09:36 CET] <JEEB> too bad ryzen didn't have ECC [21:09:37 CET] <jamrial> bah, as part of fate [21:09:41 CET] <BtbN> JEEB, it does. [21:09:46 CET] <BtbN> And some boards even support it [21:09:58 CET] <BtbN> Or don't you mean ECC RAM? [21:09:58 CET] <jamrial> use make checkasm to build it [21:10:03 CET] <jamrial> then run it with --bench [21:10:06 CET] <JEEB> BtbN: I hear the board manuf that listed ECC support meant the physical hardware, not ECC RAM in that mode [21:10:11 CET] <jamrial> and afaik, Gramner was right. Ryzen has 128bit simd, so avx/avx2 ymm instructions will be slower than on intel [21:10:15 CET] <TD-Linux> JEEB, apparently the asrock ones support real ECC [21:10:28 CET] <BtbN> JEEB, the ASUS X370-Pro one claims to support it as well [21:10:45 CET] <JEEB> TD-Linux: apparently someone actually asked and told that he got a reply from asrock saying it doesn't actually use the ECC functionality [21:11:03 CET] <TD-Linux> JEEB, that was from a different vendor [21:11:03 CET] <BtbN> So they all just support plugging them in there, but don't use the ECC features...? [21:11:40 CET] <TD-Linux> yeah it's the asus one that ignores ECC https://www.asus.com/us/Motherboards/PRIME-X370-PRO/specifications/ [21:12:54 CET] <JEEB> right, https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_… [21:12:57 CET] <JEEB> AMD answer [21:13:19 CET] <JEEB> so yes, technically the boards could support full ECC [21:14:18 CET] <wm4> what kind of bullshit is this [21:14:45 CET] <BtbN> It's a consumer CPU. But AMD was kind enough to not disable ECC. [21:14:58 CET] <BtbN> So it's up to BIOS/Software support from the Mainboard manufacturers. [21:15:04 CET] <BtbN> And from the looks of it, most opted to not support it [21:16:24 CET] <jamrial> BBB: avx512 will fortunately add instructions to properly shuffle across lanes. things like vpermb and vpermi2b (essentially pshufb on all 64 bytes), the latter allowing you to emulate palignr since it takes two regs as input [21:16:37 CET] <BBB> oh nice [21:16:39 CET] <jamrial> but who knows when cannonlake will show up, and if it will have avx512 on desktop [21:16:55 CET] <BBB> but so actually for things like directional intra pred, it seems palignr actually works just fine in avx2 [21:17:19 CET] <BBB> youre a little more restricted but once you get how braindead it is, you can hack your way around it and it works without any slowdown or extra shuffling [21:17:30 CET] <BBB> so you dont have 5 ways to write it, just 2 [21:17:33 CET] <BBB> but thats still >0 [21:31:02 CET] <BtbN> I should probably use gcc 6.3 for ryzen [21:34:59 CET] <BtbN> jamrial, https://bpaste.net/show/e043f90216f5 [21:35:10 CET] <BtbN> I can't find a test where it compares sse4 vs. avx(2) [21:35:52 CET] <BtbN> Oh [21:36:03 CET] <BBB> vp9_inv_dct_dct_16x16_sub16_add_8_c: 3035.4 [21:36:03 CET] <BtbN> vp9_avg_8tap_smooth_16h_10bpp_avx2 is like twice as fast on sse2 than avx2 [21:36:04 CET] <BBB> vp9_inv_dct_dct_16x16_sub16_add_8_sse2: 667.0 [21:36:05 CET] <BBB> vp9_inv_dct_dct_16x16_sub16_add_8_ssse3: 489.3 [21:36:06 CET] <BBB> vp9_inv_dct_dct_16x16_sub16_add_8_avx: 511.2 [21:36:07 CET] <BBB> vp9_inv_dct_dct_16x16_sub16_add_8_avx2: 461.8 [21:36:07 CET] <BBB> that seems logical [21:36:29 CET] <BBB> you probably need a higher number of iterations? [21:37:28 CET] <BBB> the numbers seem fairly random, yes [21:37:35 CET] <BtbN> How do I increase them? [21:37:47 CET] <BtbN> And should I pin it to a single CPU? [21:37:56 CET] <BBB> BENCH_RUNS [21:37:59 CET] <BBB> in checkasm.h [21:38:21 CET] <BtbN> so go to like a million instead off 1k? [21:39:23 CET] <BtbN> the Windows scheduler has some issues with Ryzen atm. [21:39:30 CET] <BtbN> so some randomness might come from that [21:40:06 CET] <BBB> if I change it to 5000: [21:40:07 CET] <BBB> vp9_put_8tap_smooth_32hv_12bpp_c: 20441.9 [21:40:07 CET] <BBB> vp9_put_8tap_smooth_32hv_12bpp_sse2: 2635.6 [21:40:08 CET] <BBB> vp9_put_8tap_smooth_32hv_12bpp_avx2: 1405.7 [21:40:23 CET] <BBB> or: [21:40:25 CET] <BBB> vp9_put_8tap_smooth_32v_8bpp_c: 13050.1 [21:40:26 CET] <BBB> vp9_put_8tap_smooth_32v_8bpp_sse2: 1062.1 [21:40:27 CET] <BBB> vp9_put_8tap_smooth_32v_8bpp_ssse3: 570.1 [21:40:28 CET] <BBB> vp9_put_8tap_smooth_32v_8bpp_avx2: 280.4 [21:41:07 CET] <BBB> I dont think a million will ever finish TBH [21:41:18 CET] <BBB> but maybe you have a massively awesome super-computer [21:41:22 CET] <BtbN> yeah, I noticed, went for 10k now [21:51:10 CET] <BtbN> https://bpaste.net/show/4f662b54f022 that's with 10k [21:51:31 CET] <BtbN> yeah, that seems more reasonable [22:03:25 CET] <TD-Linux> at least it looks like it's not slower, so you won't have to detect ryzen specially [22:05:46 CET] <BtbN> Windows still has massive issues with the NUMA like architecture of Ryzen [22:05:56 CET] <BtbN> And with the asymetric SMT [22:06:53 CET] <jamrial> many of the ymm functions are slower than their xmm/sse counterparts, but apparently not nearly as bad as it was with bulldozer [22:10:10 CET] <jamrial> vp9_avg_8tap_smooth_32v_8bpp_ssse3: 821.0 [22:10:10 CET] <jamrial> vp9_avg_8tap_smooth_32v_8bpp_avx2: 856.4 [22:10:10 CET] <jamrial> vp9_avg_8tap_smooth_32v_10bpp_sse2: 1620.3 [22:10:10 CET] <jamrial> vp9_avg_8tap_smooth_32v_10bpp_avx2: 1536.8 [22:10:22 CET] <jamrial> weird [22:12:26 CET] <BtbN> I blame the scheduler [22:18:30 CET] <JEEB> oh, cool [22:18:36 CET] <JEEB> someone had already started work on bink2 [22:18:38 CET] <JEEB> https://wiki.multimedia.cx/index.php/Bink_Video_2 [22:30:59 CET] <durandal_170> JEEB: thats old [22:33:40 CET] <JEEB> durandal_170: true, only noticed now tho [22:45:50 CET] <michaelni> atana, did you implement the window overlap ? [23:35:39 CET] <cone-106> ffmpeg 03Michael Niedermayer 07master:58dd25f8adb1: avcodec/mpegaudiodec_template: Check for negative e [23:35:39 CET] <cone-106> ffmpeg 03Michael Niedermayer 07master:800d02abe041: avcodec/mjpegdec: Fix runtime error: left shift of negative value -127 [23:35:39 CET] <cone-106> ffmpeg 03Michael Niedermayer 07master:222c9f031de3: avcodec/h264_mvpred: Fix runtime error: left shift of negative value -1 [23:35:39 CET] <cone-106> ffmpeg 03Michael Niedermayer 07master:e2a4f1a9eb2c: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: -135088512 * 16 cannot be represented in type 'int' [23:35:39 CET] <cone-106> ffmpeg 03Michael Niedermayer 07master:bac9c03ed932: avcodec/movtextdec: run mov_text_cleanup() before overwriting pointers [23:44:31 CET] <durandal_170> how to copy avframe contents to another frame? [23:47:51 CET] <DHE> av_frame_ref() if you're doing it without modifying the frame(s) [23:58:12 CET] <durandal_170> i need one frame to be untouched from previous state [23:58:42 CET] <durandal_170> but another frame is going to change [00:00:00 CET] --- Fri Mar 10 2017

1 0

ffmpeg.log.20170309
by burek 10 Mar '17

10 Mar '17

[00:04:41 CET] <blue_misfit> hey guys, why would I get dup and drop frames when transcoding an intra-only format like ProRes? [00:12:23 CET] <blue_misfit> also, what does "clipping frame in rate conversion" mean?\ [00:12:43 CET] <thebombzen> it means you're coercing the framerate [00:12:56 CET] <thebombzen> try using -vsync passthrough or -vsync drop and see what happens [00:13:44 CET] <blue_misfit> very odd [00:14:01 CET] <blue_misfit> this is a 1080p23.98 prores source and I'm trying to transcode it to the same format [00:14:12 CET] <blue_misfit> interesting [00:14:13 CET] <blue_misfit> I'll try [00:18:37 CET] <blue_misfit> so using -vsync drop makes a file that doesn't play properly [00:21:28 CET] <blue_misfit> using -vsync passthrough I get the desired number of frames in the output [00:22:06 CET] <blue_misfit> but it seems to hold lastFrame-1 for the last 2 frames instead of displaying the final frame :) [00:22:13 CET] <furq> does the source have vfr timestamps [00:22:20 CET] <blue_misfit> how can I tell? [00:22:30 CET] <blue_misfit> it shouldn't as it's prores and should be CFR afaik [00:24:31 CET] <blue_misfit> [mov @ 00000000025687a0] Non-monotonous DTS in output stream 0:0; previous: 181181, current: 181181; changing to 181182. This may result in incorrect timestamps in the output file. [00:24:31 CET] <blue_misfit> [mov @ 00000000025687a0] Non-monotonous DTS in output stream 0:0; previous: 181182, current: 181181; changing to 181183. This may result in incorrect timestamps in the output file. [00:24:31 CET] <blue_misfit> [mov @ 00000000025687a0] Non-monotonous DTS in output stream 0:0; previous: 181183, current: 181181; changing to 181184. This may result in incorrect timestamps in the output file. [00:24:31 CET] <blue_misfit> [mov @ 00000000025687a0] Non-monotonous DTS in output stream 0:0; previous: 181184, current: 181181; changing to 181185. This may result in incorrect timestamps in the output file. [00:24:34 CET] <blue_misfit> [mov @ 00000000025687a0] Non-monotonous DTS in output stream 0:0; previous: 181185, current: 181181; changing to 181186. This may result in incorrect timestamps in the output file. [00:24:39 CET] <blue_misfit> [mov @ 00000000025687a0] Non-monotonous DTS in output stream 0:0; previous: 181186, current: 181181; changing to 181187. This may result in incorrect timestamps in the output file. [00:24:42 CET] <blue_misfit> oy sorry guys [00:24:45 CET] <blue_misfit> http://pasted.co/fead7a9c [00:25:32 CET] <blue_misfit> looks like the last several frames have the same dts?? [00:56:30 CET] <blue_misfit> yeah timestamps are crazy at the end of the file [00:56:49 CET] <blue_misfit> all frames leading up to the end have dts values that are 1001 longer than the previous [00:56:56 CET] <blue_misfit> then there's a frame with 7007 [00:56:58 CET] <blue_misfit> then 6 with 1 [02:54:51 CET] <seggil> trying to tract down why ffmpeg when desk recording stop working(record blank video) for me on fedora 25 in last few days, somebody else got this ? [11:39:58 CET] <furqan> i need some starting pointers to make simple program with ffmpeg [11:40:20 CET] <furqan> i want to open video files with different format and concatenate into one format [11:40:34 CET] <furqan> could someone give me directions [11:42:25 CET] <JEEB> see the examples under docs/examples [11:43:43 CET] <furqan> i am still not able to open mp4 file with avformat_open_input [11:44:36 CET] <JEEB> then something is badly wrong :P [11:45:09 CET] <JEEB> anyways, post code so someone can help you, I have a $dayjob to take care of [11:45:15 CET] <JEEB> (in a pastebin, not on the channel) [11:45:21 CET] <JEEB> and link the pastebin or something here [11:46:23 CET] <furqan> https://gist.github.com/furqantariq/7384130b21b1b5c7ea8b4c8f0659a193 [12:26:42 CET] <mcjack> furqan: maybe try to read the actual number avformat_open_input returns& it gives clues about what went wrong& [12:27:02 CET] <furqan> i solved that [12:27:10 CET] <mcjack> cool [12:27:11 CET] <furqan> i used this with another file it worked [12:50:39 CET] <feliwir> hey, how do i compile ffmpeg so it becomes debuggable? "./configure --enable-debug=3" didn't work for me [12:58:40 CET] <flux> I've used --disable-stripping --disable-optimizations --disable-pthreads and I guess I didn't even need --enable-debug [13:07:53 CET] <feliwir> works, thanks [13:13:12 CET] <faLUCE> Hello: ffmpeg -i file -acodec copy -vcodec mjpeg -f mpegts output.ts <--- output.ts doesn't contain any video, but only audio. If I switch to matroska (fmpeg -i file -acodec copy -vcodec mjpeg -f matroska output.mkv) it works. Is there any known issue/bug? [13:42:35 CET] <blackdot> hello. i'm trying to encode my files with the HAP codec (listed here: https://ffmpeg.org/ffmpeg-all.html#Hap ). with regular hap, it works, but when i try to use hap_alpha or hap_q, i get "Unknown encoder 'hap_alpha'". i'm doing it like this: http://pastebin.com/355kcWvn [13:43:11 CET] <blackdot> am I using the syntax wrong? [13:48:17 CET] <furqan> hello, what functions do i look into to remove audio from mp4 [13:49:57 CET] <blackdot> ah niice, my thing works with -c:v hap -format hap_alpha [13:50:32 CET] <blackdot> furqan: you could just add -an before your output file path. that removes the audio completely afaik [13:50:49 CET] <furqan> no using libraries [13:51:10 CET] <blackdot> ah. that's beyond my skill then :) [16:28:41 CET] <Conder> hello, is there some difference between Dolby Atmos and Dolby TrueHD? [16:32:14 CET] <alexpigment> atmos is an extension of truehd but is backwards compatible with it [16:32:35 CET] <alexpigment> the short answer is "yes, there's a difference" [16:33:06 CET] <alexpigment> the long answer is: i'm not terribly familiar familiar with *what* differences there are and how they're implemented (metadata vs actual stream data) [16:34:07 CET] <alexpigment> i want to say you'll only hear a difference when you have more than a 7.1 setup [16:35:16 CET] <faLUCE> Hello: ffmpeg -i file -acodec copy -vcodec mjpeg -f mpegts output.ts <--- output.ts doesn't contain any video, but only audio. If I switch to matroska (fmpeg -i file -acodec copy -vcodec mjpeg -f matroska output.mkv) it works. Is there any known issue/bug? [16:36:22 CET] <alexpigment> faluce: is mjpeg valid for the mpegts container? [16:37:04 CET] <alexpigment> https://en.wikipedia.org/wiki/Comparison_of_video_container_formats [16:39:45 CET] <Conder> thx [16:40:29 CET] <faLUCE> alexpigment: it is valid. And the muxer doesn't give any warning about it.... [16:40:44 CET] <faLUCE> https://en.wikipedia.org/wiki/MPEG_transport_stream [16:41:00 CET] <alexpigment> ah [16:42:12 CET] <alexpigment> i've had trouble before with the mpegts container in FFMPEG before, specifically with H.264 + pcm_bluray [16:42:21 CET] <furqan> http://stackoverflow.com/questions/42699121/how-to-concatenate-videos-and-a… [16:42:25 CET] <alexpigment> rather, pcm_l16be for bluray [16:42:29 CET] <furqan> please [16:42:58 CET] <alexpigment> anyway, point being that i had to do the same thing re: using MKV instead because of a silent failure to include a stream [16:43:40 CET] <furq> furqan: -f concat -i concatlist -i foo.mp3 -map 0:v -map 1:a out.mp4 [16:43:55 CET] <furq> !muxer concat [16:44:24 CET] <furq> er [16:44:26 CET] <furq> !demuxer concat [16:44:26 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-formats.html#concat-1 [16:44:33 CET] <furqan> by using c++ [16:44:43 CET] <furqan> with ffmpeg library [16:44:51 CET] <furq> oh [16:44:54 CET] <furq> you're on your own then [16:45:42 CET] <furq> i assume this is for some kind of programming exercise because you could do this just as well with 10 lines of shell [16:45:53 CET] <furqan> yea something like that [16:46:36 CET] <furq> https://ffmpeg.org/doxygen/trunk/examples.html [16:46:46 CET] <furq> that's about as much help as i can give [16:46:54 CET] <alexpigment> faLUCE: did you also get an error about "deprecated pixel format used, make sure you did set range correctly? [16:47:02 CET] <alexpigment> " [16:47:24 CET] <furq> it's a nick completion minefield in here right now [16:50:09 CET] <faLUCE> alexpigment: which debug option do I have to set in order to check that error? -v debug, -v info or what? [16:50:39 CET] <alexpigment> i'm not sure. i tested using a static zeranoe win64 build from last month or so [16:50:57 CET] <alexpigment> but i see the error there when trying it. i then tested mpeg2video and didnt' get the error [16:51:24 CET] <alexpigment> the thing is, yuvj420p, yuvj422p and yuvj444p are the only ones supported by the encoder [16:51:47 CET] <alexpigment> so i don't know what the problem is [16:52:06 CET] <faLUCE> alexpigment: anyway, you too have an issue, right? [16:52:19 CET] <alexpigment> (and i'm not implying that this warning is important [16:52:24 CET] <alexpigment> just that it shows up [16:52:26 CET] <faLUCE> then, this bug is confirmed... I think [16:52:50 CET] <Tragomox> hello. is it possible to use the display aspect ratio instead of the pixel aspect ratio when extracting a still using the following command? "ffmpeg -i input.flv -ss 00:00:14.435 -vframes 1 out.png" [16:52:50 CET] <alexpigment> well, perhaps [16:53:03 CET] <alexpigment> it also shows up when doing MKV, so...? [16:54:24 CET] <kepstin> Tragomox: if you want to rescale the image so it has the correct dar when using 1:1 pixel aspect ratio, you'll have to ... rescale the image. by adding a scale filter. [16:54:26 CET] <faLUCE> alexpigment: all is unclear... [16:54:47 CET] <alexpigment> faLUCE: maybe this might be relevant, http://stackoverflow.com/questions/23067722/swscaler-warning-deprecated-pix… [16:55:43 CET] <kepstin> all that warning means is that some code is using the old alias for jpeg-range yuv instead of the new method of indicating it - not an error, just a message telling programmers that they should update the code. [16:56:59 CET] <alexpigment> faLUCE: well, to go back to the problem i described earlier with H.264 and PCM not working in mpegts via ffmpeg, i ended up having to use tsMuxeR. have you ever used it, and if so, is it possible that you can incorpate this into your workflow? [17:01:17 CET] <Tragomox> kepstin, ok, thanks. [17:01:49 CET] <faLUCE> alexpigment: the problem is that I obtain the same issue if I mux a native mjpeg stream.... [17:02:10 CET] <alexpigment> ahh [17:02:53 CET] <alexpigment> out of curiosity - why MJPEG? [17:03:30 CET] <alexpigment> rather than, say, AVC in intra-only mode [17:04:25 CET] <faLUCE> alexpigment: I stream from a web camera. And the camera supports MJPEG, other than YUYV422é [17:04:51 CET] <alexpigment> gotcha [17:06:06 CET] <alexpigment> anyway, i've never seen a TS file with MJPEG in the wild, so even if it's technically supported (the wikipedia pages seem to disagree for some reason), it makes sense that it would be either a) unimplemented or b) broken in FFMPEG [17:08:49 CET] <JeffATL> my video files play but won't start picture for a few seconds; ffprobe says "Could not find codec parameters for stream 0 (Video: h264 (avc1 / 0x31637661), none, 720x480, 1920 kb/s): unspecified pixel format". my process is, split audio off and clean it up in audacity, save as flac, recombine v and a using -map. problem starts when i cut up the result with -ss and -to. [17:09:29 CET] <faLUCE> alexpigment: it seems broken, because I see the muxed packets, but they can't be demuxed [17:10:11 CET] <alexpigment> faLUCE: probably so. i consider the mpegts muxer in ffmpeg a work in progress ;) [18:38:43 CET] <AreaScout> Hi all, if i use FFmpeg > then 2.8 FF_THREAD_FRAME doesn't look to use all my cores on decoding, with <= 2.8 everything is ok, did i miss some API changes in the new versions, is it different to handle ? [18:43:05 CET] <AreaScout> codec i am using is h264 [19:25:41 CET] <JEEB> AreaScout: is the amount of threads spawned the same? [19:26:35 CET] <AreaScout> JEEB on <= 2.8 yes on > 2.8 nope [19:27:14 CET] <JEEB> what kind of numbers are we talking about? [19:28:49 CET] <AreaScout> here is a picture with FFmpeg 2.8 running on one CPU ( core 5-8 is a separate CPU arm A15 ) https://www.areascout.at/IMG_1364.PNG [19:29:39 CET] <AreaScout> and FFmpeg runs on core 5-8 on that picture, well balanced as you can see [19:29:44 CET] <AreaScout> everything works fine [19:30:22 CET] <AreaScout> this is on FFmpeg higher than 2.8 https://www.areascout.at/IMG_1365.PNG [19:31:37 CET] <JEEB> well the question was about the amount of threads [19:31:40 CET] <JEEB> not the CPU usage [19:32:02 CET] <JEEB> you should be able to compare [19:32:27 CET] <AreaScout> i only have that picture now on the hand, moonlight is the process [19:33:08 CET] <kepstin> are you actually running into an issue where it's not decoding the video fast enough? [19:33:12 CET] <JEEB> so you can't just check the amount of the threads right now? then I can't really help. because in general I'm not getting any worse perf [19:33:32 CET] <AreaScout> kepstin yes [19:34:19 CET] <kepstin> AreaScout: and it's the same video both times? different videos can have different restrictions on how much parallelism you get [19:34:21 CET] <AreaScout> JEEB, just in 10min i can test, if you are still here [19:34:35 CET] <JEEB> not necessarily at the keyboard but I have my client around 24/7 [19:34:41 CET] <JEEB> so I can see any highlights [19:35:00 CET] <AreaScout> kepstin it's the same game very time, it's an Game Streaming client [19:35:12 CET] <AreaScout> JEEB, ok cool [19:35:31 CET] <kepstin> AreaScout: ok, so different video, but the video encoder is the same, and the content is similar? [19:35:56 CET] <AreaScout> the video encoding is done by NVIDIA [19:36:06 CET] <AreaScout> yes it its always the same [19:36:24 CET] <kepstin> for low latency stuff like game streaming you might want to look into doing sliced encoding which is easier to do multithreaded decoding, but I dunno if that'll help here [19:36:53 CET] <AreaScout> sliced is much slower on my hardware then frame threating [19:36:56 CET] <AreaScout> https://www.youtube.com/watch?v=_uM-pRK6RPY [19:38:04 CET] <kepstin> why are you doing software decoding at all, anyways? don't a lot of these arm chips on e.g. phones and stuff have hardware decoder isps? [19:38:37 CET] <kepstin> i mean, you have enough cpu available that it should be working :/ [19:39:28 CET] <AreaScout> MFC (hardware decoding) runs slower then FFmpeg, the latency is very bad, it's only written for watching a video on TV where it doesn't matter if your video starts 4 or 5 seconds later [19:40:03 CET] <BtbN> frame threading itself seems pretty bad latency wise [19:40:23 CET] <BtbN> as you are bound to have a couple frames delay, so each thread can have one [19:40:35 CET] <kepstin> yeah, that's why slices are better for latency [19:40:43 CET] <AreaScout> but i can reach a latency of 190ms, thats ok for gaming [19:40:56 CET] <BtbN> that's not a very high number of threads then [19:41:06 CET] Action: kepstin knows a lot of gamers who would disagree, but that's another matter :) [19:41:09 CET] <BtbN> and 200ms for gaming doesn't seem ok to me. Usually you go for sub 10ms [19:41:19 CET] <kepstin> what are you setting the "threads" avoption on the decoder to? [19:41:54 CET] <AreaScout> maybe it's my hardware but even a board with HW decoder like the ODROID C2, i can't reach 10ms [19:42:04 CET] Action: kepstin notes that FF_THREAD_FRAME appears to still be respected in the ffmpeg h264 decoder, fwiw., but it's the default so that doesn't really matter. [19:42:31 CET] <AreaScout> i measure this by recording the audio echo effect [19:42:40 CET] <kepstin> er, the default is to allow both slid and frame threading (presumably which is used depends on the input video) [19:43:02 CET] <AreaScout> hmmm didn't try that :) [19:43:27 CET] <AreaScout> i tried this OR that only [19:44:00 CET] <kepstin> the default is FF_THREAD_FRAME|FF_THREAD_SLICE, which means the decoder can use either option depending on whether the input video has slices or not [19:44:08 CET] <kepstin> but yeah - what are you setting as the thread count? [19:44:16 CET] <AreaScout> 4 [19:44:31 CET] <AreaScout> it's 8 core but on two CPU's [19:44:49 CET] <kepstin> big/little cluster thing, so only 4 cores acitve at a time? [19:45:08 CET] <AreaScout> no Heterogeneous Multi-Processing (HMP) [19:45:16 CET] <BtbN> So, Ryzen? [19:46:39 CET] <AreaScout> the HMP decides to switch the most CPU extensive threads to the strongest CPU [19:47:13 CET] <AreaScout> ODROID XU3/4 [19:47:30 CET] <AreaScout> arm exynos 5422 [19:49:27 CET] <kepstin> yeah, that's a big.LITTLE system, using the newer method where the linux cpu scheduler to allocate tasks to cores rather than the older method which swapped between core clusters. [19:50:25 CET] <AreaScout> yep [19:50:44 CET] <kepstin> but the end effect is that you only have 4 high performance cores for video decoding :) [19:51:50 CET] <AreaScout> yes that's enough for 1080p and i am pretty much as fast like the ODROID C2 with HW decoder [19:52:28 CET] <AreaScout> but the C2 can do 2160p [19:52:42 CET] <AreaScout> it's a different soc [19:53:21 CET] <AreaScout> Amlogic with very low latency HW decoder [19:53:22 CET] <kepstin> but yeah, weird that you're seeing a big difference between 2.8 and later versions, I don't thing the frame threaded decoder handling has really changed much if at all. [19:54:03 CET] <AreaScout> strange yes, i have tried everything [19:54:15 CET] <AreaScout> 3.0, 3.1, 3.2 [19:54:28 CET] <AreaScout> each with the same configure switches [19:54:43 CET] <AreaScout> and only <= 2.8 works [20:47:59 CET] <Kirito> What's the simplest way to "center crop" a 1080p video to 720p with ffmpeg? That is, crop out 1280x720 from the center of the video, instead of scaling it [20:50:46 CET] <BtbN> Use the crop filter, and crop equal amounts of pixels from left/right and top/bottom [21:07:37 CET] <llogan> i think crop automatically centers [21:30:10 CET] <Zypho> Does anyone know of an easy way to calculate the bitrate of a video stream where ffprobe is returning N/A on bitrate for both the video and audio stream? [21:30:40 CET] <Zypho> I believe the answer I am looking for is something around using the -show_packets` flag in ffprobe [21:35:27 CET] <alexpigment> Zypho: is this supposed to be an automated process, or is it a 1-time thing? [21:35:38 CET] <alexpigment> i.e. do you just need to calculate the bitrate for one video? [21:36:55 CET] <Zypho> @alexpigment automated [21:37:00 CET] <alexpigment> k, nm [21:37:09 CET] <Zypho> some videos are fine, others I need to expect they won't have bitrate defined [21:38:20 CET] <alexpigment> well, i don't suppose a simple size % length is accurate enough for your needs? [21:38:39 CET] <alexpigment> rather, [size divided by length] [21:39:02 CET] <Zypho> unfortonately not because the container could have both an audio and video stream, both returning no bitrate and I need the bitrate for each individual stream [21:39:48 CET] <alexpigment> yeah, i hear you. i guess you're dealing with a sample set that is unknowable, so the bitrate could be 96kbps aac or 1.5mbps PCM? [21:40:06 CET] <alexpigment> the audio bitrate, i mean [21:40:30 CET] <Zypho> correct [21:41:06 CET] <alexpigment> is ffprobe giving you the duration at all? [21:41:16 CET] <alexpigment> i would think it would be weird that it knows the duration and yet gives N/A for the bitrate [21:42:31 CET] <Zypho> Yeah I get the duration back for each stream [21:43:10 CET] <Zypho> actually no, sorry [21:43:13 CET] <Zypho> just double checked [21:43:21 CET] <Zypho> no duration on the streams are returned [21:43:33 CET] <alexpigment> ok, so i think that's the problem that needs to be addressed [21:43:46 CET] <Zypho> I do have the combined duration, and the combined bitrate [21:44:00 CET] <fengshaun> is there a way to calculate the time range of a media file given the byte-range? I'm trying to on-the-fly transcode a media file, but getting byte-range doesn't help when ffmpeg requires time range [21:44:06 CET] <fengshaun> I'm looking for a way to calculate that [21:44:17 CET] <fengshaun> mostly mp4 files [21:44:46 CET] <fengshaun> ffprobe can do that, but it reads the entire file every time [21:44:50 CET] <fengshaun> http://stackoverflow.com/questions/37134341/web-video-bytes-range-to-time [21:45:55 CET] <alexpigment> zypho: 1/2 of the combined time (assuming there are 1 video and 1 audio stream) divided by the combined bitrate would give you the overall bitrate, for what it's worth [21:46:05 CET] <alexpigment> i suspect that doesn't help though [21:47:27 CET] <Zypho> :( [21:47:47 CET] <alexpigment> https://trac.ffmpeg.org/wiki/FFprobeTips [21:48:01 CET] <alexpigment> have you looked at the "Get duration by decoding" section? [21:49:18 CET] <alexpigment> and i presume you're already using "-select_streams"? [21:49:39 CET] <Zypho> yes I am [21:49:48 CET] <alexpigment> i figured i'd ask just in case [21:50:15 CET] <alexpigment> but the decoding method may be your only option [21:52:01 CET] <Zypho> Still returns me back bitrate N/A [21:52:30 CET] <alexpigment> but it does give you the difinitive time, right? [21:52:37 CET] <Zypho> it does yea [21:52:54 CET] <alexpigment> and are you able to deduce elsewhere what the per-stream file size is? [21:53:58 CET] <Zypho> I could probablt sum the values from show_packets [22:04:52 CET] <alexpigment> Zypho: i tested a random sample of videos, and the only ones that report a bitrate of n/a are ones that don't actually play in players [22:05:01 CET] <alexpigment> WMP/VLC/etc [22:05:56 CET] <alexpigment> what format(s) are you seeing that's giving you N/A for bitrate? i presume they play in your video players [23:00:36 CET] <Maverick|MSG> when specifying ffmpeg's -to (to tell ffmpeg to stop recording at a certain timestamp), can the number of minutes in the timestamp be > 60? [23:01:04 CET] <Maverick|MSG> so rather than writing 01:30:00 I could write 00:90:00? [23:01:47 CET] <BtbN> try it I'd say [23:02:04 CET] <Maverick|MSG> yeah, I would if I could right now but I'm away from my ffmpeg-installed computer [23:02:35 CET] <Maverick|MSG> the documentation says the minutes must be two digits, so it might work [23:17:50 CET] <c7j8d9> when encoding a 30mbps bitrate h264 to hevc should i be telling it to do 15mbps to get similar quality (hypothetical bitrates) at half the size? Am I thinking of this in the right way? [23:19:05 CET] <kepstin> c7j8d9: what encoder are you using? x265? [23:19:40 CET] <kepstin> c7j8d9: if so, you probably want to do a crf encode with the highest crf you can which doesn't cause a noticable quality drop, and the slowest settings. [23:20:06 CET] <kepstin> it will take a long time, but the video will probably be marginally to moderately smaller than original h264. [23:20:27 CET] <c7j8d9> trying to get h265 working with nvidia gpu acceleration [23:20:40 CET] <BtbN> half the size is pretty doable with x265 vs. x264 at comparable qualities [23:20:50 CET] <kepstin> lol hardware encoder [23:20:51 CET] <BtbN> nvenc hevc is even below x264 quality levels [23:21:16 CET] <kepstin> if the source h264 was made with x264, the nvidia hevc encoder will only make it worse, yeah [23:22:07 CET] <haroldp> I have these crappy IP cams that will only do rtsp but I need people to be able to live stream them from a website. [23:22:46 CET] <haroldp> Does it make sense to use ffmpeg to pull the video off the cams and then nginx to publish the live streams? [23:23:04 CET] <haroldp> ....and rtmp for use with a flash player [23:23:32 CET] <kepstin> haroldp: yeah, that should work fine. You can either use nginx-rtmp to run ffmpeg to pull the data, or have ffmpeg generated e.g. hls or dash segments and serve them in plain http for an html5 player [23:24:04 CET] <haroldp> thanks. [23:24:33 CET] <haroldp> so I can use ffmpeg from the command line and just send the output to a .mp4 file, and that works fine [23:25:36 CET] <haroldp> I was looking at using "exec_push" in nginx. does that make sense? [23:25:48 CET] <haroldp> (possibly off topic here, sorry) [23:35:45 CET] <c7j8d9> so just because hardware encoding takes an hour instead of 18 hours its not worth it? [23:36:05 CET] <c7j8d9> for hevc [23:36:12 CET] <RossW> I know it's probably overkill - but I already have ffmpeg on a machine. Can I use it to overlay a PNG over the top of a jpeg, and output a jpeg? (Or better still, output to stdout?) If so, what incantation would I use? [00:00:00 CET] --- Fri Mar 10 2017

1 0

ffmpeg-devel.log.20170308
by burek 09 Mar '17

09 Mar '17

[00:00:44 CET] <durandal_1707> knight___: AVFrame->extended_data[channel][samples] [00:01:37 CET] <durandal_1707> not exactly for >uint8 samples. but thats idea [00:03:20 CET] <knight___> Ok so every Frame has a few channels in it, each channel has its own array of samples (which are tiny bits of data) and the number of channels are determined by the layout, stereo-4 and so on ? [00:04:11 CET] <durandal_1707> yes [00:04:56 CET] <durandal_1707> thats for planar sample formats [00:05:50 CET] <knight___> thats cool [00:09:34 CET] <cone-310> ffmpeg 03Vittorio Giovara 07master:ac8c72f8f1f7: mov: Fix checking layout and loading padding for cubemaps [00:09:35 CET] <cone-310> ffmpeg 03Vittorio Giovara 07master:9ae3506696ba: matroskadec: cosmetics: Rearrange checks for projection-depedendent properties [00:20:39 CET] <knight___> #define AV_NUM_DATA_POINTERS 8:---> why is this 8? [00:25:53 CET] <cone-310> ffmpeg 03Carl Eugen Hoyos 07master:587226ad4594: lavc/libx265: Add gray10 and gray12 encoding support. [00:30:56 CET] <cone-310> ffmpeg 03Carl Eugen Hoyos 07master:a9c20598b505: lsws/input: Do not define unused functions. [00:33:50 CET] <cone-310> ffmpeg 03Carl Eugen Hoyos 07master:851f4255e0e2: lsws/slice: Move a misplaced const. [01:50:09 CET] <knight___> @durandal_1707 I have written a simple square filter, can you verify? [03:58:43 CET] <adeel1> durandal_1707: yes [05:21:12 CET] <cone-980> ffmpeg 03James Almer 07master:dbc932e745fe: Revert "lavu/atomic: add support for the new memory model aware gcc built-ins" [08:06:30 CET] <wm4> ah the spherical fate tests now pass on 64 bit systems [09:59:12 CET] <wm4> can anyone explain to me why "side_data_type" doesn't appear in the ffprobe output (if there's side data), even though it's definitely in the code? [10:01:00 CET] Action: wm4 solves it by using manual printfs, as always [10:16:22 CET] <cone-220> ffmpeg 03Muhammad Faiz 07master:61926b6c3e56: swresample/resample: use uniform normalization [11:51:54 CET] <wm4> michaelni: 946ed78f5f8683229afe778a774c12b3a25aba57 mutates the packet data... [11:53:06 CET] <wm4> that's what breaks -fflags +keepside [11:57:15 CET] <JEEB> funky [14:47:01 CET] <cone-466> ffmpeg 03Thomas Turner 07master:a50ccbd240a9: avutil/tests/lfg.c: added proper normality test [14:47:02 CET] <cone-466> ffmpeg 03Michael Niedermayer 07master:1d0bad421ceb: avutil/tests/lfg: Remove debugging start/stop timer [15:42:35 CET] <BBB> wbs: holy crap patchload [15:42:54 CET] <BBB> wbs: thats all been thoroughly tested on libav right? So no need for extensive review [15:45:40 CET] <BBB> wm4: what is merged side data? [15:47:42 CET] <wbs> BBB: yes, all of those have been in libav for weeks/months, so they're pretty safe. most of them are pretty small couple-of-line tweaks, but some are bigger optimizations. it basically just reduces the diff for the 8bpp things to libav down to the bare minimum [15:48:40 CET] <wm4> BBB: by default, libavformat removes all side data from AVPackets, and adds it to the packet data [15:48:51 CET] <wm4> it appends it to the end of the codec data, using a special marker [15:48:58 CET] <wm4> see av_packet_merge_side_data() [15:49:04 CET] <BBB> wtftftftftftf?!?!?!?!? [15:49:15 CET] <BBB> libavformat touches packet data? [15:49:16 CET] <wm4> in libavcodec, the side data is split again before it's passed to the decoder [15:49:26 CET] <wm4> yes [15:49:31 CET] <wm4> it's supposed to help MPlayer [15:49:32 CET] <wm4> I mean [15:49:38 CET] <BBB> kill it [15:49:44 CET] <BBB> Im going to vomit for a few hours, bbl [15:49:44 CET] <wm4> API users which need to transport packet data and can't keep the side data [15:49:57 CET] <wm4> glad you like it [15:58:12 CET] <cone-466> ffmpeg 03Muhammad Faiz 07master:fe57bf7cd6ac: fate/swresample: fix FUZZ typo [16:09:36 CET] <BBB> Im having a strange feeling that weve discussed this patch before [16:09:39 CET] <BBB> like a flashback [16:10:49 CET] <wm4> I don't remember anything, but I might have complained multiple times on IRC [16:10:55 CET] <wm4> but this time I won't give up [16:10:58 CET] <wm4> because fuck this shit [16:11:20 CET] <iive> is that about subtitles? [16:13:07 CET] <wm4> no [16:18:07 CET] <rcombs> yeah the side data merge/split stuff has never made sense [16:21:52 CET] <iive> hum, MPlayer code that uses the above function have been added at 2016. [16:24:45 CET] <BBB> this seems like one of the most obscure crazy hacks Ive ever seen [16:25:41 CET] <BBB> imagine me adding this to the smtp email delivery standard, attachments shall be added at the end of the message, separated by from the main message [16:27:05 CET] <nevcairiel> isnt that basically how those work? =p [16:27:14 CET] <iive> :) [16:28:09 CET] <BBB> I believe under is the corporate disclaimer, not attachment [16:28:22 CET] <BBB> although we dont ever read either of them, so I guess theyre interchangeable in some ways [16:28:54 CET] <BBB> you know, if you are not the intended recipient of this email, please delete it and confirm in writing that you have done so or YOU WILL GO TO JAIL, YOU FAKE NEWS LIAR!!!!" [16:31:28 CET] <ubitux> yes, the side data split/merge has been discussed several times, at least once a year since 2012 [16:32:40 CET] <ubitux> maybe not in the recent ones [16:59:05 CET] <wm4> iive: which function? [16:59:37 CET] <wm4> anyway, I'm fine with the function itself existing, just their use in ffmpeg code should be fully removed [17:20:16 CET] <rcombs> BBB: attachments are added at the end of the message, separated by "--[separator]", where [separator] is a string defined in a message header [17:20:35 CET] <rcombs> I'm completely serious, this is how MIME multipart works [17:27:54 CET] <wm4> rcombs: and everyone was sad [17:42:54 CET] <wm4> is there a way to set global fate options, that will be passed to all tools (ffmpeg/ffprobe)? [17:52:33 CET] <jkqxz> wm4: Abuse lack of quoting? HWACCEL='none -also other -stuff' [17:54:01 CET] <adeel1> durandal_1707: yes, I get a black screen. [18:00:04 CET] <ubitux> wm4: tests/fate-run.sh in ffmpeg() function maybe; no such thing seems to exist for ffprobe [18:00:36 CET] <ubitux> you probably want to wrap the run ffprobe${PROGSUF} ... into one [18:21:59 CET] <durandal_1707> adeel1: find out why [18:26:23 CET] <adeel1> durandal_1707: for one example it's completely black, and for the other one I get some purple stuff (at one point I got a clear decoded image, but after changing the pointer stuff it changed). [18:33:50 CET] <durandal_1707> adeel1: bacause you cant change stuff out of nowhere [19:31:49 CET] <adeel1> durandal_1707: So, I believe the problem stared when I changed x->frame->data[0] to p->data[0]. Could this be it? [20:02:50 CET] <wm4> jamrial: I can't see anything civil in having to fight for every millimeter, just because it's a cleanup (and michaelni apparently doesn't like this kind of change) [20:03:51 CET] <jamrial> i mean there were argumens and no insults. even if they seem pointless or irritating, it's at least civil [20:04:37 CET] <jamrial> if people start assuming malice from the other party then it's all downhill from there [20:16:32 CET] <wm4> it's already pretty downhill [21:15:48 CET] <cone-362> ffmpeg 03Michael Niedermayer 07master:01a33b835f7a: avcodec/pictordec: Fix runtime error: left shift of 64 by 25 places cannot be represented in type 'int' [21:15:48 CET] <cone-362> ffmpeg 03Michael Niedermayer 07master:3016e919d4e1: avcodec/wavpack: Fix runtime error: left shift of negative value -5 [21:20:54 CET] <ramiro> AVIContext::is_odml is unused in libavformat/avidec.c [21:21:06 CET] <ramiro> but I'm too lazy to send a patch [21:32:41 CET] <BtbN> ffmpeg with libx265 generates more heat than Prime95 in maximum heat mode. Impressive [21:37:32 CET] <philipl> heh. [21:37:40 CET] <philipl> BtbN: did you get a chance to look at the mpeg2 behaviour? [21:38:32 CET] <BtbN> nope, was busy setting up new PC and stuff [21:38:35 CET] <BtbN> But I can give it a go now [21:40:27 CET] <BtbN> Do you have an mpeg2 sample at hand? [21:43:49 CET] <philipl> I admittedly have not tested these recently, but the basic samples are relevant: interlaced mpeg2. [21:43:52 CET] <philipl> http://samples.ffmpeg.org/MPEG2/interlaced/ [21:44:30 CET] <philipl> The main thing I saw was deadlocks in the cuvid/cuda library code on certain occasions. [21:44:53 CET] <philipl> Not always repeatable. It seemed to happen more if I didn't attempt to deinterlace, and I didn't do explicit track mapping. [21:44:54 CET] <BtbN> Just by decoding it? [21:44:58 CET] <philipl> Transcoding [21:45:03 CET] <philipl> with hwaccel [21:45:56 CET] <philipl> Independent of mpeg2, there's the other problem I saw. As soon as I ask for b frames when transcoding, it will return a 'Not enough surfaces' error. [21:46:08 CET] <philipl> Does not happen if I don't ask for the hwaccel (but it's still using cuvid and nvenc) [21:47:07 CET] <BtbN> Also, did you have a chance to look at the scale/crop patch? [21:48:05 CET] <BtbN> ./ffmpeg.exe -r 50 -deint adaptive -hwaccel cuvid -c:v mpeg2_cuvid -i D:/Cache/koncercik.mpg -c copy -c:v h264_nvenc -global_quality 22 -y out.mkv [21:48:10 CET] <BtbN> this is working fine here [21:49:15 CET] <iive> BtbN: talking about deadlocks, what happened with init order and out of memory error when using cuda and nvenc? [21:49:29 CET] <BtbN> it was eventually fixed [21:49:46 CET] <BtbN> Pushing the cuda context before encoding was missing [21:49:58 CET] <BtbN> for some super weird reason, it worked without that before, which shouldn't ever have worked. [21:51:06 CET] <BtbN> philipl, no, even running it a lot of times runs without it locking up [21:52:58 CET] <iive> BtbN: so it was driver bug? [21:53:14 CET] <BtbN> no [22:02:35 CET] <iive> oh, so you push the context by the application. [22:21:12 CET] <furqan> hello guys, i am trying to learn ffmpeg, i want to make an program that takes a mp4 video without audio and mp3 audio and output mp4 video with audio. could you guys suggest some starting pointers or functions that i need to look into? [22:24:16 CET] <JEEB> under docs/examples there's a demux and mux examples, thos are what you'll need [22:24:28 CET] <JEEB> since mp3 audio goes nicely into mp4 you don't need to decode or encode [22:48:46 CET] <shurhat> Hello everyone, I wanted to know whether anyone is already working on the "ambisonic decoder" project or not? [22:49:11 CET] <shurhat> @durandal_1707 [22:50:12 CET] <durandal_1707> shurhat: yes there is already someone [22:50:59 CET] <shurhat> Being late to the party, can you please tell me which projects are currently open? [22:53:11 CET] <durandal_1707> all [22:57:08 CET] <shurhat> @durandal_1707 oh okay. Any pointers on approaching the ambisonic decoder project? [22:58:14 CET] <durandal_1707> shurhat: try to understand other audio filters [22:59:13 CET] <durandal_1707> mixing coefficients are in wikipedia article [23:01:11 CET] <Mornix> Hi! I have an assignment which requires me to document a piece of code. I chose to do a filter in FFmpeg. Is this something that would be of use for me to submit a patch for the documentation changes? [23:07:33 CET] <ubitux> writing filters is documented in doc/writing_filters.txt [23:09:57 CET] <shurhat> @ubitux Thanks a lot. I'll be working on its qualification task. [23:10:41 CET] <ubitux> i was replying to Mornix, i doubt writing filters is going to help you wrt writing a decoder [23:12:47 CET] <shurhat> @ubitux oh okay, thats fine but one of the qualification task for the project I was talking about is implementing a shelf filter. [23:19:36 CET] <Mornix> ubitux: Sorry, the filter already exists (it's the detelecine filter), I've just added some comments/documentation to the code. [23:59:05 CET] <BBB> wm4: I think what michaelni means is that its legal for an application to do for (n = 0; n < 1000; n++) { av_packet_add_side_data(pkt, side_data_type=n, side_data_sz=1, side_data = [ 0 ]); } [23:59:13 CET] <BBB> wm4: since its external API [23:59:36 CET] <BBB> wm4: now obviously that is utterly ridiculous, and the app could probably even do it without using API since AVPacket is also exposed [23:59:48 CET] <BBB> wm4: I think thats what he means [00:00:00 CET] --- Thu Mar 9 2017

1 0

ffmpeg.log.20170308
by burek 09 Mar '17

09 Mar '17

[00:00:07 CET] <alexpigment> i tend to use CRF + VBV for streaming, which allows you to save overall on file size even though it's a bit more unpredictable [00:01:06 CET] <alexpigment> maybe that's a noob move, but i haven't heard any complaints so far and it's been over a year [00:01:54 CET] <ZeroWalker> so, anyone wana lend me a hand in my lost attempt to write encoded frames to a file?;d [00:02:00 CET] <furq> that's pretty much fine [00:04:23 CET] <kepstin> yeah, with crf+vbv you can replace the "perfectly clear still shot that turns into meh when something moves" into "everything's pretty much constant mehness" ;) [00:05:17 CET] <alexpigment> well, to be fair, i go aggressive on the CRF [00:05:45 CET] <alexpigment> and i keep the VBV much higher than, say, YouTube at a given resolution [00:06:08 CET] <alexpigment> so basically i'm hitting the VBV wall anytime it's complex, and then I'm saving bits when it's not complex [00:06:35 CET] <kepstin> hmm, i actually should check whether the h264 decoders used in browsers for webrtc can decode intra-refresh stuff properly. Would be fun to sneak that into production. [00:06:43 CET] <alexpigment> i don't have the luxury of 2-pass, so it's the best i could come up with [00:07:00 CET] <kepstin> annoyingly, flash can't handle it in rtmp, at least as encoded by ffmpeg. [00:07:21 CET] <alexpigment> well, you're in luck - *it's 2017* [00:07:26 CET] <kepstin> and we want to use the same encoding for flash and webrtc where possible :/ [00:07:43 CET] <alexpigment> finding a modern browser that even lets you run flash out of the box is difficult [00:07:57 CET] <TD-Linux> hate to break it to you but chrome has flash built in [00:08:01 CET] <kepstin> you mean, "the standard installation of chrome"? :) [00:08:12 CET] <TD-Linux> the proprietary one ye :) [00:08:35 CET] <alexpigment> as of i think chrome 56, they started preferring HTML5 over Flash when both were available [00:08:38 CET] <kepstin> (when we're doing flash mode, it's a full-page flash application, so it bypasses some of the automatic blocking) [00:08:43 CET] <alexpigment> meaning that it's probably on the way out [00:08:58 CET] <alexpigment> but yeah, if you're in an application, flash is fine [00:09:53 CET] <kepstin> we're doing this stuff all backwards, we have a full-page flash application... which uses webrtc via javascript for audio when the browser can do it. [00:10:03 CET] <kepstin> owell. [00:10:15 CET] <alexpigment> i hear you [00:11:17 CET] <kepstin> the folks behind me are working on the html5 version, it's coming soon" [00:11:39 CET] <alexpigment> we just had to go through our web app this year and rip out all the flash because chrome's dev blog made it sound like flash *wouldn't work* in either v55 or v56 (i think). it turned out that it didn't have as much affect as they said it would, but it at least got us to work harder really quickly :) [00:11:43 CET] <kepstin> the pain point is that we are trying to get video going between flash and html5 clients to have a smooth transition period [00:11:50 CET] <alexpigment> and of course, safari all but blocks it without the user opting in [00:12:02 CET] <alexpigment> firefox prompts the user, i believe [00:12:08 CET] <alexpigment> does Edge even support flash at all? [00:12:16 CET] <kepstin> edge supports flash, yes. [00:12:27 CET] <kepstin> in desktop mode, unclear about metro mode [00:12:44 CET] <alexpigment> gotcha. they were pretty "no plugins" at the beginning. i didn't know if they got away from that or not [00:13:00 CET] <kepstin> it supported flash from the start, but never any other plugins (e.g. java) [00:13:08 CET] <alexpigment> i don't even think it was npapi vs ppapi plugins. i want to say they were against all of them [00:13:17 CET] <alexpigment> i see. maybe they just made a single exception for flash [00:13:37 CET] <kepstin> heh, plugins in IE are activex, no npapi vs ppapi issue at all ;) [00:14:00 CET] <kepstin> (I suspect Edge uses a special sandboxed flash build, similar to chrome) [00:14:40 CET] <alexpigment> sorry, i didn't mean literally npapi. i'm saying it wasn't like old format vs new format [00:15:23 CET] <kepstin> well, they certainly haven't made any public plugin api for Edge. [00:15:52 CET] <kepstin> (there's an extension api based on chrome's extension api tho) [00:16:52 CET] <alexpigment> at any rate, i have mixed feelings about the death of flash. it's got its advantages, but it's just always been a bloated turd [00:19:24 CET] <kepstin> getting live streaming video into browsers is a lot harder without it :) [00:20:12 CET] <alexpigment> yeah for sure [00:20:18 CET] <alexpigment> and you know, copy protection [00:20:54 CET] <alexpigment> (not that i'm necessarily in favor of copy-procting all web video) [01:11:29 CET] <ZeroWalker> JEEB, http://sprunge.us/QPhN i can't get any further;( [01:43:46 CET] <maicod> Hi. my ffmpeg doesn't know the -f concatenate. What build config file do I need to edit to enable this to compile this function in ? [01:45:08 CET] <JEEB> maicod: since that is enabled by default my guess is just that your FFmpeg is old enough to not have it [01:45:26 CET] <maicod> JEEB I recently got it from github [01:45:47 CET] <JEEB> if you're doing disable-everything kind of config then you'll just have to find it by yourself because doing that means that you understand what you are doing [01:46:13 CET] <JEEB> and if you don't, then you start off with a more full configuration [01:46:20 CET] <maicod> I did not [01:46:33 CET] <JEEB> then whatever you got is just old [01:46:46 CET] <maicod> how do I list the version of ffmpeg ? [01:47:02 CET] <JEEB> ffmpeg -version [01:47:28 CET] <JEEB> also do note that all of the concat stuff is most likely in some uses cases broken so you have been warned. I mean, someone made them and they worked for that person's exact use case [01:48:09 CET] <JEEB> heck, I've used the concat video filter myself, mostly because it works on the highest level with all the demuxers and decoders working separately [01:48:26 CET] <maicod> thanks for the warning [01:48:32 CET] <maicod> did you have succes ? [01:48:42 CET] <JEEB> the demuxer and protocol is where it gets funky, esp. if you want to do stream copying [01:49:11 CET] <JEEB> maicod: yes. since in my opinion that is the one where things are least likely to go awry as you don't have demuxers hopping from one thing to another [01:49:33 CET] <JEEB> each demuxer (and decoder) work separately, but the things are just concatenated together *after* decoding [01:49:33 CET] <maicod> root@raspberrypi:/1/a/1080p# ffmpeg -version [01:49:33 CET] <maicod> avconv version 11.8-6:11.8-1~deb8u1+rpi1, Copyright (c) 2000-2016 the Libav developers [01:49:33 CET] <maicod> built on Oct 8 2016 02:37:00 with gcc 4.9.2 (Raspbian 4.9.2-10) [01:49:33 CET] <maicod> avconv 11.8-6:11.8-1~deb8u1+rpi1 [01:49:33 CET] <maicod> libavutil 54. 3. 0 / 54. 3. 0 [01:49:33 CET] <maicod> libavcodec 56. 1. 0 / 56. 1. 0 [01:49:33 CET] <maicod> libavformat 56. 1. 0 / 56. 1. 0 [01:49:34 CET] <maicod> libavdevice 55. 0. 0 / 55. 0. 0 [01:49:34 CET] <maicod> libavfilter 5. 0. 0 / 5. 0. 0 [01:49:35 CET] <maicod> libavresample 2. 1. 0 / 2. 1. 0 [01:49:35 CET] <maicod> libswscale 3. 0. 0 / 3. 0. 0 [01:49:36 CET] <maicod> damn [01:49:46 CET] <maicod> I wanted to paste a pastebin link [01:49:47 CET] <JEEB> yes, that's most likely your packaged version [01:49:55 CET] <JEEB> and yes, please do that in the future [01:50:09 CET] <maicod> I already prepared but the clipboard didnt work :) [01:50:13 CET] <JEEB> but yeah, that's not even FFmpeg :) [01:50:20 CET] <maicod> its avconv huh [01:50:28 CET] <JEEB> from Libav project, yes [01:50:40 CET] <maicod> I see I thought they were idetical [01:50:43 CET] <maicod> identical [01:50:54 CET] <maicod> they say set an alias for ffmpeg=avconv even [01:51:17 CET] <JEEB> well, in some ways they are very similar (after all, current ffmpeg bases on the updates done for avconv), but a lot of features inside the libraries etc are FFmpeg-only [01:51:22 CET] <maicod> btw the hardware encoding on the Rpi works like a charm ! (openmax) [01:51:30 CET] <maicod> I see now [01:51:48 CET] <JEEB> mostly because to get stuff from FFmpeg to Libav someone needs to care enough, but Libav->FFmpeg used to be something done on a weekly basis [01:52:12 CET] <maicod> so there is not other way to combine video files into ffmpeg :( [01:52:13 CET] <JEEB> and you're not sure to get through Libav's review anyways, so f.ex. I mostly gave up at some point :P [01:52:19 CET] <maicod> hehe [01:52:24 CET] <JEEB> maicod: so what's your actual use case? [01:52:36 CET] <JEEB> transcoding, stream copy? [01:53:18 CET] <maicod> just wanting to combine two video files (both from same camera) and then transcode it. Transcoding [01:53:26 CET] <JEEB> ok [01:53:29 CET] <maicod> like this [01:54:01 CET] <JEEB> so yea, Libav doesn't even have the concat VF it seems [01:54:11 CET] <maicod> indeed it seems so [01:54:17 CET] <JEEB> so I recommend you get a rpi cross-toolchain on an actual PC [01:54:24 CET] <JEEB> and build FFmpeg for it [01:54:30 CET] <JEEB> then transfer the binaries back to the rpi [01:54:43 CET] <JEEB> you can use it from your home directory or something [01:55:00 CET] <JEEB> unless you like building on that hunk o' metal :P [01:55:02 CET] <maicod> ok :) [01:55:07 CET] <maicod> heheeh its cute :) [01:55:19 CET] <maicod> JEEB: did you know it can do hardware encoding ? [01:55:24 CET] <JEEB> yes [01:55:30 CET] <JEEB> most ARM SOCs can [01:55:31 CET] <maicod> it uses the GPU (via openmax) [01:55:34 CET] <JEEB> they contain ASICs [01:55:35 CET] <maicod> ok :) [01:55:52 CET] <maicod> it is 12x faster than software encoding :) [01:55:57 CET] <JEEB> well, d'uh [01:56:00 CET] <JEEB> ARM [01:56:03 CET] <maicod> its cool [01:56:22 CET] <maicod> what is so special about that its ARM ? [01:56:31 CET] <maicod> I mean what makes that do such things easier ? [01:56:34 CET] <JEEB> less processing power per clock cycle [01:56:44 CET] <maicod> ah I see [01:56:46 CET] <JEEB> so of course CPU based stuff is gonna be slower [01:56:50 CET] <JEEB> compared to an ASIC [01:57:18 CET] <JEEB> of course doesn't stop people using libx264 with the NEON optimizations in some cases [01:57:38 CET] <maicod> thanks for you making me understand its cause its avconv that I don't have concatenate [01:57:44 CET] <JEEB> (some ASICs or their drivers in the ARM space are just awful, and in that case it's often more useful to drop resolution and encode with CPU) [01:58:11 CET] <maicod> yeah GPU encoding drivers can be a little rough huh [01:58:13 CET] <JEEB> (some well-made mobile apps have sanity checks for that) [01:58:21 CET] <maicod> not developed thorough enoug [01:58:24 CET] <JEEB> garbage out => switch to cPU encoding [01:58:30 CET] <JEEB> *CPU [01:58:42 CET] <maicod> how you call my beloved Pi a piece of metal :) [01:58:54 CET] <JEEB> I'm sorry, it's plastic [01:58:58 CET] <maicod> its fine [01:59:01 CET] <JEEB> and I have one too :P [01:59:03 CET] <maicod> LOL [01:59:08 CET] <maicod> a 3 ? [01:59:17 CET] <JEEB> waiting for me to build a 64bit kernel [01:59:26 CET] <JEEB> so I can poke at the aarch64 mode [01:59:28 CET] <maicod> yeah raspbian is still 32bit huh [01:59:41 CET] <TD-Linux> ugh reminds me I need to do that for mine too [01:59:49 CET] <maicod> but won't the 1GB mem be a bastard for 64bit OS ? [01:59:53 CET] <JEEB> although you lose most of the desktop side of things with the aarch kernel [01:59:55 CET] <TD-Linux> my 64bit kernel doesn't boot and I haven't debugged why yet [02:00:01 CET] <TD-Linux> upstream kernel support is 64bit only [02:00:06 CET] <JEEB> yea [02:00:14 CET] <TD-Linux> and you actually don't lose most of the desktop things [02:00:19 CET] <JEEB> oh [02:00:37 CET] <JEEB> I heard the blob bridge thing wasn't done yet [02:00:38 CET] <TD-Linux> you get kms and mesa instead of blob driver, and I think HDMI audio might not work [02:00:46 CET] <TD-Linux> (vc4 accelerated mesa) [02:00:51 CET] <JEEB> interesting [02:00:59 CET] <TD-Linux> it can actually run gnome-shell (barely) [02:01:03 CET] <maicod> JEEB thanks for the insights again. have a nice day [02:27:44 CET] <r0ute> When stuck on an ffmpeg programming task. Don't do what I did to try and get past the block. 8 pints of beer, followed by 4 coffees in 30 minutes does not put you in good sted. Just a heads up.. [02:28:51 CET] Action: klaxa takes notes [02:31:31 CET] <r0ute> Stage 2 of the brilliant plan is if it's still not working in an hour, malt whisky will help. [02:40:06 CET] <furq> 8 pints of beer in 30 minutes eh [02:41:15 CET] <r0ute> 4 coffes in 30 minutes, the pints took a while longer [02:43:40 CET] <furq> maybe that's the problem [02:44:03 CET] <r0ute> I should have drunk the beer quicker? [02:44:19 CET] <llogan> i found a rye in the office today. now it's on my desk. [02:56:02 CET] <DHE> look up the ballmer peak (xkcd) [02:59:45 CET] <r0ute> That's a good one, hadn't seen that before. The solution to this problem is clear to me now... [03:11:18 CET] <llogan> i'm not much of a mpegts user or broadcast encoder, but a client wants a PAT/PMT interval of 100, but they don't state the unit of measurement and they didn't know what it is supposed to be. any ideas of what unit of measurement it probably is? [03:13:35 CET] <JEEB> 50 frames I guess? [03:13:40 CET] <JEEB> uhh, 100 I mean [03:13:57 CET] <JEEB> although even that is kind of long (4 seconds for 25) [03:18:09 CET] <llogan2> the power went out... [03:19:02 CET] <llogan2> conviently right when i saw that JEEB responded but didn't get to read it fully [03:21:18 CET] <furq> llogan2: http://ffmpeg.gusari.org/irclogs/ffmpeg.log.20170308 [03:22:56 CET] <kiwi_banal> What is a good encoding format suitable for playing video via USB on a Panasonic TH24A400Z television? [03:23:28 CET] <llogan2> furq: thanks. for some reason i assumed the logs were compiled daily [03:23:33 CET] <kiwi_banal> The Panasonic TH24A400Z is a flat-screen PAL TV of about 3 years of age. [03:24:00 CET] <furq> they're rotated daily but the current day's log is updated live [03:24:09 CET] <llogan2> well i'll be damned [03:24:22 CET] <furq> incredible~ [03:24:25 CET] <llogan2> wait, i already am. mpegts. [03:29:10 CET] <kiwi_banal> I am competent with ffmpeg, prefer not to use a *possibly* malware gui with ffmpeg under the hood, but cannot find say, yuv etc. [03:30:00 CET] <klaxa> kiwi_banal: what have you tried yet? just ffmpeg -i movie.avi movie.mp4 ? [03:30:59 CET] <klaxa> they even claim to support mkv [03:31:47 CET] <klaxa> i would assume they support h264 high at least then [03:32:57 CET] <kiwi_banal> I tried a few weeks ago and am back trying (for a computer-illiterate)... [03:33:16 CET] <klaxa> oh then they probably don't care too much about quality too i guess? :/ [03:33:47 CET] <kiwi_banal> h264 with aac/mp3, in mkv and mp4 containers [03:34:01 CET] <kiwi_banal> no :) [03:34:29 CET] <kiwi_banal> I am trying to get youtube etc. videos to convert successfully for him. [03:35:00 CET] <kiwi_banal> I suspect it is the pixel format or color type ?? [03:35:12 CET] <klaxa> if you download them in the right format it should work out of the box [03:36:12 CET] <kiwi_banal> OK, I'll keep trying (sigh) as I catch up maybe once a week, so it is a slow process of trial and error. Thanks all the same :) [03:37:03 CET] <klaxa> otherwise i personally would just throw "ffmpeg -i input.avi -crf 20 -preset slower output.mp4" or so at it [03:37:30 CET] <kiwi_banal> I'll give it a whirl. Cheers, klaxa [03:39:53 CET] <furq> kiwi_banal: do you have a sample that works [03:40:48 CET] <kiwi_banal> furq: Not yet. I will try one file on usb in various formats (once a week!) until I hit the jackpot. [03:41:39 CET] <furq> well yeah i'm sure i don't need to tell you, but hardware media players are notoriously finicky and underdocumented [03:41:47 CET] <furq> and smart tvs are among the worst offenders [03:42:13 CET] <furq> if it's from 2014 then i assume it wants h264 and aac, but who knows [03:43:26 CET] <kiwi_banal> yep, I'd assumed the same. The only file I have got working is mp3 straight audio so far. [03:43:56 CET] <kiwi_banal> I have been trying to convince my illiterate friend to buy a second hand laptop. [03:44:21 CET] <furq> one of those hdmi sticks is probably a better choice [03:44:29 CET] <furq> like the chromecast or something [03:45:32 CET] <kiwi_banal> I'll check out the hdmi stick as you say. I was kind of dreading the free help time with a new laptop ;) [03:45:56 CET] <furq> those things are like $30 or so and will be less hassle for both of you [03:46:14 CET] <furq> if he just wants to watch stuff on his tv anyway [03:46:49 CET] <klaxa> probably [03:48:36 CET] <kiwi_banal> That's all he wants at this point. Cheers, furq [04:47:54 CET] <FishPencil> How much faster *should* ffmpeg be with multithreading? I'm seeing anywhere from 7 to 50% faster depending on the number of cores/threads available [04:48:11 CET] <furq> that depends on a lot of things you didn't mention [04:48:34 CET] <r0ute> Number of CPU's would be quite a big factor there. [04:49:13 CET] <FishPencil> For example, from 1 to 2 cores it was 14% faster, 2 to 3 it was 42% faster, and 3 to 4 it was 7% faster. [04:49:56 CET] <FishPencil> The CPU was an i5, so 2 cores 4 threads [04:51:19 CET] <FishPencil> Hyperthreading is probably playing a big roll here [04:51:21 CET] <furq> i was thinking more of the codec [04:51:26 CET] <furq> and also whether you mean encoding or decoding [04:51:32 CET] <FishPencil> libx264 [04:51:49 CET] <FishPencil> Encoding [04:52:33 CET] <furq> i mean that's a 75% speedup with two cores [04:52:39 CET] <furq> that sounds pretty good to me [04:52:55 CET] <furq> physical cores, that is [04:54:09 CET] <FishPencil> Where are you getting 75% from [04:54:29 CET] <furq> 03:49:14 ( FishPencil) For example, from 1 to 2 cores it was 14% faster, 2 to 3 it was 42% faster, and 3 to 4 it was 7% faster. [04:54:42 CET] <furq> that adds up to 73.2% [04:55:33 CET] <FishPencil> Um... 63? [04:55:47 CET] <furq> https://www.google.co.uk/search?q=(((100%20%2B%2014%25)%20%2B%2042%25)%20%2… [04:55:58 CET] <furq> also you should use 6 threads with x264 if you have 4 logical cores [04:56:09 CET] <furq> that's what it would pick automatically [04:56:26 CET] <FishPencil> It's an i5, two cores, 4 threads total [04:56:31 CET] <furq> yes [04:57:38 CET] <FishPencil> How does one use 6 threads when 4 are available? -threads 6? [04:57:47 CET] <furq> well ideally just get rid of -threads [04:58:04 CET] <furq> but -threads 6 will do the same thing [04:58:07 CET] <FishPencil> It wasn't used, so it would do that anyway [04:58:31 CET] <FishPencil> Does it anyways do n+2? [04:58:37 CET] <furq> n*1.5 [05:00:45 CET] <FishPencil> Is there a reason for the odd dispersion of improvement? I'm not sure how hyperthread is effecting this, but how does that play a roll [05:01:09 CET] <furq> ask intel [05:01:23 CET] <furq> and your os vendor, since they're the one responsible for the thread scheduling [05:02:47 CET] <FishPencil> furq: Thanks for the input [05:03:16 CET] <furq> i assume -threads 2 is using one logical core during this phase of the moon [05:03:32 CET] <furq> one physical core [05:05:42 CET] <FishPencil> I changed the # of threads/cores on an OS level, so I'm not sure if it's doing one core and hyperthreading it to get the one and two, and then the 2nd core comes in at 3 [05:05:50 CET] <FishPencil> That would make the most sense [05:05:58 CET] <furq> probably [05:06:33 CET] <FishPencil> Also explains the jump to 42% faster [05:06:51 CET] <FishPencil> So you could assume a "hyperthread" only helps 7-14% [05:07:05 CET] <FishPencil> Though that might be a jump [05:09:28 CET] <FishPencil> x265 did a similar thing, 18.7, 42.6, and 5.6. [05:20:29 CET] <lindylex> I am trying to crop and slice in time the length of a video and it does not crop it at all. This is what I tried. ffmpeg -i acrobaticyoga_Sara_R_2.mp4 -ss 00:00:00.0 -t 00:01:03.0 -codec:v libx264 -vf "crop=640:640:320:60" -profile:v baseline -preset slow -pix_fmt yuv420p -r 29.97 -b:v 3500k -threads 0 -acodec aac -ar 44100 -filter:v "setpts=.96*PTS" -y o.mp4 [05:34:48 CET] <klaxa> i think -filter:v overwrites -vf [05:39:35 CET] <thebombzen> lindylex: why are you using setpts=0.96*PTS [05:39:59 CET] <lindylex> i was tryng to slow the movie down. But I do not need to. [05:40:09 CET] <thebombzen> then do not do that because that's going to mess stuff up [05:40:18 CET] <lindylex> ok [05:40:18 CET] <thebombzen> especially if you don't slow the audio down too [05:40:39 CET] <thebombzen> remember that with digital hardware we don't need to pulldown [05:41:00 CET] <thebombzen> everything's progressive so we don't need to do weird stuff like that [05:41:51 CET] <lindylex> That worked [05:43:13 CET] <lindylex> how do you recomend I speed up the video so it plays with within 60 seconds instead of 63 [05:43:18 CET] <lindylex> 63 seconds? [05:46:40 CET] <furq> -vf "crop=640:640:320:60,setpts=1.05*PTS" -af atempo=1.05 [05:47:21 CET] <furq> er [05:47:42 CET] <furq> -vf "crop=640:640:320:60,setpts=(60/63)*PTS" -af atempo=1.05 [05:52:03 CET] <lindylex> furq: Thanks [05:52:58 CET] <lindylex> Is -af the audio tempo? [05:54:16 CET] <klaxa> lindylex: https://ffmpeg.org/ffmpeg-filters.html#atempo [05:55:37 CET] <lindylex> Thanks got it now. -vf "crop=640:640:320:60,setpts=(60/63)*PTS" This here the 60 is how long I want the video to play and 63 is the length in seconds of the cut? [06:26:31 CET] <lindylex> Why does this not work for my video after I slice it and copy the audio and video codec? ffmpeg -i o.mp4 -codec:v libx264 -vf "crop=640:640:320:60" -profile:v baseline -preset slow -pix_fmt yuv420p -r 29.97 -b:v 3500k -threads 0 -an -filter:v "setpts=0.95*PTS" -y o2.mp4 [06:28:06 CET] <furq> 04:34:48 ( klaxa) i think -filter:v overwrites -vf [07:03:25 CET] <furq> https://theintercept.com/2017/03/07/wikileaks-dump-shows-cia-could-turn-sma… [07:03:30 CET] <furq> in case you needed another reason to not buy a smart tv [09:13:26 CET] <lindylex> furq: thanks for sharing that article. [14:15:45 CET] <sybariten> oh hai [14:16:34 CET] <sybariten> I have a wmv file and what i want to do, although i don't know if this is really technically possible, is to split it up into its audio and video components (two files) with as little as possible or no re-encoding [14:16:59 CET] <sybariten> Do i need to find out axactly what is inside that wmv container first? [14:18:00 CET] <c_14> depends [14:18:04 CET] <c_14> Just for splitting, no [14:18:12 CET] <c_14> but depending on what you want to do with it afterwards maybe [14:18:28 CET] <sybariten> yeah, my inital attempt must have been wrong in some way, at least. THe original wmv is 156 megs, and i got a 234 mb wma file and a 62 mb wmv video file [14:19:06 CET] <sybariten> I'm guessing were probably dealing with 90 percent vidoe and 10 percent audio in terms of data here [14:19:07 CET] <DHE> ffmpeg -i inputfile.wmv -map 0:v -c copy output-video.mp4 -map 0:a -c copy output-audio.mp4 # adjust extensions to more suitable ones depending on codecs, etc [14:19:34 CET] <c_14> I'd probably use wmv as extension instead of mp4 just because then you'll know the codec'll fit [14:20:00 CET] <DHE> point taken... [14:21:15 CET] <sybariten> i did this, from some web searches... ffmpeg -i $jacob/Webinar_uncut.wmv -map 0:0 -vcodec copy $jacob/tempo/daVideo.wmv -map 0:1 -acodec copy $jacob/tempo/daAudio.wma this is the one that gave a 234+62 Mb file [14:21:30 CET] <sybariten> i mean one of 230 and one of 60 [14:21:58 CET] <c_14> stream 0 might not be video, and stream 1 might not be audio [14:22:08 CET] <c_14> use what DHE wrote just with wmv instead of mp4 [14:23:08 CET] <DHE> that makes a lot of sense. "acodec" won't set a video codec which means mpeg2 video by default, right? [14:23:20 CET] <DHE> mine is more generic and likely to work as intended [14:23:30 CET] <DHE> and hopefully should finish in less time than it takes to sneeze [14:23:32 CET] <sybariten> okay, uh.... i notice now i have probably mixed something up. The 234 mb .wma file i got is actually the video, and the 60 mb wmv files is the audio track . So at least the audio is smaller than the video, thats as expected [14:24:27 CET] <c_14> DHE: msmpeg4v3 apparently [14:24:28 CET] <sybariten> but ill try DHEs advcive [14:26:53 CET] <sybariten> ooh that was a magnitude faster [14:27:06 CET] <sybariten> and the sum of the files match up with my original wmv! [14:27:24 CET] Action: DHE takes a bow [14:27:30 CET] <sybariten> grazie! [14:27:44 CET] <sybariten> What am i doing with the map ... is it "command" ? Argument? [14:28:11 CET] <DHE> it tells ffmpeg which streams (audio, video, etc) you want to go into the output file. from input file 0, stream 'v' (preferred video) [14:28:13 CET] <DHE> and so on [15:10:23 CET] <shincodex> av_dict_set(&options, "profile", "High 10", 0); [15:10:39 CET] <shincodex> if (avcodec_open2(codecContext, codec, &options) > -1) [15:10:44 CET] <shincodex> h264 codec [15:10:47 CET] <shincodex> h264.c [15:10:55 CET] <shincodex> Why does the profile for decoding [15:10:57 CET] <shincodex> not set [15:11:09 CET] <shincodex> trying to fix blocky/pixelation with this codec [15:11:32 CET] <DHE> you don't set a decoding profile. only encoding [15:12:06 CET] <shincodex> So i got no decoding options [15:12:09 CET] <DHE> the profile specifies the capabilities of the decoder. like "Baseline" for the free libopenh264 (?) player, or first generations of phones [15:12:10 CET] <shincodex> to alleviate it [15:12:47 CET] <DHE> it's too late. sounds like the input is either damaged or overcompressed [15:12:52 CET] <shincodex> Some images it contains 30% of the image [15:13:02 CET] <shincodex> then mirrors the bottom scanline [15:13:03 CET] <shincodex> retardedly [15:13:05 CET] <shincodex> other images [15:13:12 CET] <shincodex> ITs like someone took a mixxed bag of ink [15:13:14 CET] <BtbN> so the file is broken [15:13:16 CET] <shincodex> and splooged it on the image [15:13:24 CET] <DHE> broken [15:13:30 CET] <shincodex> So your thinking [15:13:33 CET] <shincodex> fix the encoding [15:13:55 CET] <shincodex> User was lead to believe that VLC somehow handled it better [15:14:01 CET] <shincodex> and I looked at it in vlc do the same effect [15:14:19 CET] <shincodex> i did not turn on libx264 [15:14:42 CET] <BtbN> VLC also just used lavc for decoding h264 [15:14:58 CET] <BtbN> You can't fix a broken file with magic decoder flags [15:16:46 CET] <shincodex> thanks [15:16:52 CET] <shincodex> Its coming to me RTSP [15:17:01 CET] <shincodex> and i believe they just send it h264 [15:17:04 CET] <shincodex> of some recorded file [15:17:08 CET] <shincodex> il ltell them to fix there camera [15:17:11 CET] <shincodex> Any suggestions? [15:17:22 CET] <shincodex> like tell them to do baseline profile or crf 18 [15:17:42 CET] <shincodex> the camera might be 900 years old for all i know too or they have stupid networks [16:04:44 CET] <Guest80384> comr [16:08:36 CET] <Guest80384> shall I have to complete the expected task to work in the community. [16:33:52 CET] <durandal_1707> Guest80384: ? [17:34:11 CET] <kepstin> found out yesterday that the 'concat' filter doesn't handle inputs with different framerates correctly [17:34:39 CET] <kepstin> it doesn't set out framerate on the out links at all, so the default ffmpeg behaviour of "copy from first input" kicks in [17:35:09 CET] Action: kepstin has done the trivial patch for the issue - explicitly setting output frame rate to '1/0' to indicate vfr/unknown [17:35:12 CET] <kepstin> i guess I should post that. [17:40:53 CET] <kepstin> (could probably use a test tho, which is a bit more annoying to write) [17:41:29 CET] <alexpigment> kepstin: tbh that *seems* like a thing that wouldn't work [17:41:55 CET] <alexpigment> probably because 99.99% of users out there are probably using concat on videos encoded with the same parameters [17:42:04 CET] <alexpigment> otherwise, you know, you'd probably be using a video editor ;) [17:42:20 CET] <kepstin> this is the concat filter, it doesn't matter how the video's encoded... [17:42:45 CET] <alexpigment> i'm considering frame rate to be part of the encoding parameters [17:42:59 CET] <kepstin> and my friend who originally hit the issue has verified that it does actually handle the frame rate transitions correctly in the pts values [17:43:23 CET] <kepstin> so it just is missing the bit where it indicates vfr output [17:44:26 CET] <kepstin> (I think the case he was hitting was working with ntsc video with mixed detelecined 24fps content and deinterlaced 30/60fps content) [17:45:03 CET] <alexpigment> interesting. still, that seems like something you'd want to do in Adobe Premiere [17:45:12 CET] <alexpigment> but i guess you can do a hell of a lot with FFMPEG [17:53:53 CET] <furcifer> Hello, everybody [17:54:55 CET] <furcifer> I have a video with very few colors (console output). If it was an image I would save it to a PNG with reduced palette size to make the file length shorter. [17:55:55 CET] <furcifer> I am looking for something like this for videos. I am not sure whether look up tables are the thing I am looking for. [18:02:16 CET] <c7j8d9> I am trying to convert a remux h.264 to a hevc. Is it possible to create a 10bit from this remux which is 8bit? Or is that a waste? [18:02:38 CET] <DHE> don't [18:02:41 CET] <DHE> just don't do that [18:03:46 CET] <kepstin> I suppose if you want a smaller file with slight quality loss you might do that :/ (but obviously it's a re-encode, not a remux) [18:07:00 CET] <BtbN> Is 25~27 FPS for "-c:v libx265 -preset medium -crf 26" a decent result? [18:07:30 CET] <alexpigment> yeah, 25-27 seems pretty good in my experience [18:07:56 CET] <c7j8d9> what advantage does 10bit have over 8bit with hevc? when would it come in handy? [18:08:27 CET] <alexpigment> c7j8d9, it's an expanded color range. in my opinion, it's only important for source content that you're going to be further editing or color grading [18:08:44 CET] <alexpigment> in the consumer sphere, it's a necessary part of 4K HDR [18:09:13 CET] <alexpigment> if you don't know what it is, you probably don't need to use it [18:09:30 CET] <kepstin> c7j8d9: with h264, there's some benefit in some video sources of using 10bit even on 8bit sources, since it improves the accuracy of bases used for predicted frames. Popular with anime encoders, benefit is fairly minimal iirc [18:09:34 CET] <BtbN> I really like this 8 core so far. It's doing what it should. [18:09:40 CET] <c7j8d9> so for storing bluray 1080p 8bit is more than enough? [18:09:54 CET] <alexpigment> blu-ray is inherently 8-bit [18:10:17 CET] <alexpigment> (non-UHD blu-ray, that is) [18:10:31 CET] <c7j8d9> alexpigment: thanks [18:10:36 CET] <alexpigment> np [18:12:10 CET] <alexpigment> furcifer: are you using H.264 CRF already? [18:12:47 CET] <furcifer> I know of crf, but I encode webm. [18:13:05 CET] <alexpigment> webm has a qscale encoding method [18:13:10 CET] <alexpigment> not as good as CRF, but it's there [18:14:15 CET] <alexpigment> last i checked - and it's been several years since i even tried webm - you had to set both a CRF and a bitrate. and the bitrate effectively acted as the maxrate [18:14:20 CET] <kepstin> by 'webm' you mean vp8/vp9? [18:14:23 CET] <furcifer> I use "-b:v 0 -crf whatever", I though qscale is outdatet. [18:14:25 CET] <alexpigment> i suspect that's been changed [18:14:37 CET] <kepstin> the '-crf' parameter in ffmpeg maps to the vp8/vp9 qscale parameter [18:14:59 CET] <alexpigment> kepstin - do you know if you still have to specify a bitrate? [18:15:12 CET] <kepstin> in vp9 you no longer need to set a bitrate when using qscale mode, you can give it '0' for unconstrained [18:15:16 CET] <kepstin> you do with vp8. [18:16:02 CET] <alexpigment> at any rate, you mentioned you wanted it to act more like PNG. if you set the CRF to 1, you'll get lossless and save the bitrate since you only have console output [18:16:26 CET] <alexpigment> are the file sizes currently too large when using CRF [whatever] for VP8? [18:18:00 CET] <furcifer> I only encode VP9. Yes, I want to cut down on altogether video size. [18:18:38 CET] <alexpigment> but you still want color rather than grayscale? [18:18:40 CET] <furcifer> Also I try to find all the knobs and switches to cut down on video size while maintaining the quality, at least kinda. [18:19:00 CET] <furcifer> Yes, console is like 8 bit color output. [18:19:08 CET] <furcifer> But I don't know for sure. [18:19:19 CET] <alexpigment> what's your current command line? [18:19:23 CET] <kepstin> hmm. the change to have the concat filter set output framerate to 1/0 means the pts values in the filter graph output are in AV_TB rather than converted to framerate timebase [18:19:44 CET] Action: kepstin ponders whether he should leave it like that, or try to find a "common multiple" framerate [18:20:02 CET] <furcifer> ffmpeg -i 1.webm -vf scale=240:-1,crop=in_w:in_h*.65:1:1,fps=20 -crf 63 out.webm [18:20:21 CET] <alexpigment> kepstin: if it's 60 & 24 mixed, then 120 is your only common multiple :( [18:20:45 CET] <kepstin> alexpigment: well, it should work with arbitrary framerates and find a common multiple automatically [18:20:46 CET] <alexpigment> then again, 30i does have it's advantages :) [18:21:12 CET] <alexpigment> furcifer: -crf 63? [18:21:40 CET] <furcifer> Makes smaller output size than 1. I figured by trial and error. [18:21:44 CET] <alexpigment> i thought the range was 1-51 [18:21:56 CET] <furcifer> Error output tells about -1 as well. [18:21:56 CET] <alexpigment> i'd guess that it's because it's being ignored [18:22:09 CET] <alexpigment> what if you put it at, say, 20? [18:22:49 CET] <furcifer> "Value 64.00000 for parameter 'crf' out of range [-1 - 64]" [18:22:50 CET] <alexpigment> oh, apparently 63 is the max CRF for VP8. that means it's the absolute lowest quality [18:23:14 CET] <alexpigment> from the wiki "By default the CRF value can be from 463, and 10 is a good starting point. Lower values mean better quality." [18:23:15 CET] <furcifer> *63 is the lowest. My typo. [18:25:01 CET] <alexpigment> anyway, does CRF 10 give you low enough file sizes? [18:26:33 CET] <furcifer> It is bigger than the file with -crf 63. [18:26:37 CET] <alexpigment> it should be [18:26:47 CET] <alexpigment> so you're saying that 63 is too big? [18:26:53 CET] <alexpigment> (file size) [18:27:02 CET] <alexpigment> i mean, i'd imagine is unwatchable, right? [18:27:40 CET] <furcifer> No, console output is still legible. There is not really much moving. Only some counters going up or down. [18:28:17 CET] <alexpigment> the others here may have more info, but it doesn't sound like vp8 is the ideal codec for the job [18:30:21 CET] <kepstin> well, vp8's not really an ideal codec for any job, except maybe video playback in old versions of chrome and firefox :/ [18:30:29 CET] <furcifer> So crf is an encoding option. My initial question was about a filter that reduces colors. [18:31:11 CET] <kepstin> furcifer: with the way these video codecs work, fine detail usually matters more than color [18:31:16 CET] <alexpigment> yes, i get it. i was really just implying that an efficient encoder should take care of that for you since there aren't many colors on the screen [18:31:16 CET] <furcifer> I only can compare to my experience in image editing. Thus I referred to color indexing. I don't know whether there is something comparable in videos. [18:31:22 CET] <kepstin> and text is.. well, lots of fine detail [18:32:39 CET] <alexpigment> if you have, say, 5 colors on the screen, and those 5 colors never change, you're not wasting bits on extra colors. now if you have gradients and they're changing all the time, there might be some validity and reducing the colors [18:32:57 CET] <alexpigment> *validity in [18:34:08 CET] <alexpigment> also, i agree with kepstin's assertion about vp8. i've only used it as an HTML5 fallback, and even then it was just for Firefox on Windows XP [18:45:55 CET] <obamoose> wait what [18:46:01 CET] <obamoose> there is an ffmpeg channel? [18:46:11 CET] <obamoose> hello! [18:46:37 CET] <alexpigment> hey obamoose [18:46:39 CET] <furcifer> Hello, obamoose [18:47:11 CET] <obamoose> this is 2 years old but is it still the right way to loop files in a directory? [18:47:12 CET] <obamoose> http://stackoverflow.com/questions/25320187/how-to-tell-ffmpeg-to-loop-thro… [18:50:35 CET] <c7j8d9> anyone using ffmpeg with nvidia gpu acceleration? [18:50:52 CET] <c7j8d9> for h265 [18:59:42 CET] <alexpigment> cjj8d9: yeah, i have [19:00:14 CET] <alexpigment> it's great for speed [19:00:31 CET] <alexpigment> but there aren't many parameters [19:00:45 CET] <alexpigment> and the quality is probably nowhere as good as libx265, though i haven't done tests [19:01:55 CET] <c7j8d9> what's the command for it? [19:03:06 CET] <DHE> c7j8d9: have done for h264. it's similar. and as noted, not many options for it. [19:06:15 CET] <c7j8d9> So if I was using a gui all options would be useless after I enable it. I would just get what i get? [19:06:19 CET] <obamoose> can anyone help me figure out why my stream is lagging? [19:06:54 CET] <DHE> c7j8d9: the codec tab would be a lot more barren than if you selected a software encoder like x265 [19:09:36 CET] <c7j8d9> DHE: what is the command line for gpu acceleration? [19:11:01 CET] <DHE> start with -c:v nvenc_hevc and then give it your common options like -b:v or -crf [19:11:54 CET] <DHE> you can use -preset slow (highest quality), -profile main[10] as the most likely additionals for quality and output options [19:12:17 CET] <DHE> of course this assumes your ffmpeg is up to date. nvenc's seen a lot of work lately [19:12:59 CET] <c7j8d9> DHE: thanks...and in your experience you lose quality but gain speed? [19:16:25 CET] <DHE> I only use h264. even in slow mode it still does real-time 1080p without issues at 30fps. [19:16:51 CET] <DHE> but if I have the choice, I trust x264 over hardware encoding any day. [19:27:08 CET] <BtbN> alexpigment, I'm pretty sure nvenc_hevc has more than enough parameters: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc_hevc.c#L28 [19:34:30 CET] <persina> What does it mean Movie-Aspect is 3.32:1 - prescaling to correct movie aspect.? [19:40:30 CET] <alexpigment> c7j8d9: hey, sorry for the late reply. CRF doesn't work with nvenc. you have to use "-global_quality" instead [19:41:35 CET] <alexpigment> but yeah, i usually encode for delivery formats, broadcast, or streaming [19:41:40 CET] <alexpigment> nvenc is way too barebones [19:42:06 CET] <alexpigment> having said that, it's probably fine for anyone doing like blu-ray backups [19:46:12 CET] <c7j8d9> alexpigment: thanks [20:11:58 CET] <artista_frustrad> I've got some footage that was supposed to be 24fps but it is actually 23.9fps. Which are the best parameters to convert the frame rate without loosing quality? [20:18:23 CET] <kepstin> artista_frustrad: I bet it's actually "NTSC" style 24fps, which is really 24/1.001 fps. Do you actually need to convert it? The tricky bit is mostly adjusting the audio so it stays in sync. [20:18:30 CET] <DHE> can't just leave it at 23.9? not touching it is always the best choice [20:19:47 CET] <xjmx_> Hi there [20:20:27 CET] <xjmx_> is there anyone who can help to fix audio synchronization on multicast streams ? [20:23:50 CET] <xjmx_> Hello guys? is anyone alive there))? [20:29:00 CET] Last message repeated 2 time(s). [20:29:15 CET] <Cysioland> How can I convert a variable framerate mjpeg stream to a constant framerate one (possibly duplicating frames)? [20:30:20 CET] <kepstin> Cysioland: it should normally just require using the '-r <framerate>' or equivalently '-vf fps=<framerate>' output options. depends on whether the input timestamps are correct. [20:31:33 CET] <kepstin> hmm. I suppose in this case you don't want to re-encode tho? [20:31:53 CET] <kepstin> I don't think ffmpeg can do anything to help you without re-encoding, unfortunately [20:31:57 CET] <Cysioland> kepstin, I'd like to reencode it to a more modern format [20:32:01 CET] <Cysioland> Possibly also delay it [20:33:19 CET] <xjmx_> Guys, who can say how to keep stream be synchronized? A preset that I'm using going to out of synch in 1 or 2 days [20:33:31 CET] <xjmx_> ffmpeg -re -i "udp://xxx.xxx.xxx.xxx?fifo_size=1000000&buffer_size=40000000" -map 0:v -map 0:a -c:a aac -c:v copy -flush_packets 0 -f mpegts "udp://xxx.x.x.xx:1234?pkt_size=8648" >/dev/null 2>&1 [20:33:59 CET] <BtbN> restart it every once in a while [20:34:14 CET] <xjmx_> is it the only one way only ? [20:34:38 CET] <xjmx_> maybe it can be detectable somehow ? [20:35:05 CET] <llogan> if you play the input for a few days is it also out of sync? [20:35:40 CET] <xjmx_> the input is fine [20:35:46 CET] <llogan> that was a quick test [20:35:57 CET] <Cysioland> kepstin, this does not work, it still does not record second-to-second, thus video is sped up [20:36:00 CET] Last message repeated 1 time(s). [20:37:09 CET] <xjmx_> any other ideas ? [20:37:27 CET] <xjmx_> how it can be handled... [20:37:32 CET] <llogan> if you output to a local file then play it does it also go out of sync? [20:37:43 CET] <kepstin> Cysioland: ah, yeah, the mjpeg demuxer assumes a constant framerate. I assume this is from a variable framerate live source? [20:38:47 CET] <Cysioland> kepstin, yup, from a very crappy web cam [20:39:05 CET] <Cysioland> So FPS is dependent on the humors of crappy CPU inside the camera [20:39:06 CET] <xjmx_> llogan yes, already checked this [20:39:19 CET] <kepstin> Cysioland: you'll probably have to retime the frames based on local rtc then. You can do this with the setpts filter, just a moment... [20:40:06 CET] <Cysioland> kepstin, I want this to, finally, go for a restream [20:40:09 CET] <kepstin> Cysioland: try "-vf settb=AV_TB,setpts=RTCTIME-RTCSTART,fps=24" or something like that [20:40:27 CET] <kepstin> that'll set frame timestamps based on local rtc, then redo the stream as cfr 24 [20:40:57 CET] <llogan> xjmx_: i guess that narrows it down a little that it is probably not due to it being a network output [20:41:06 CET] <kepstin> er, typo, -vf settb=AVTB,setpts=RTCTIME-RTCSTART,fps=24 [20:45:34 CET] <xjmx_> so guys maybe you know a sources where I can get any ideas or answers ? [20:47:50 CET] <BtbN> Have you tried -vsync passthrough? [20:48:29 CET] <Cysioland> kepstin, seems to work [20:49:56 CET] <Cysioland> kepstin, now it's unplayable [20:50:35 CET] <DHE> xjmx_: every 26.5 hours? [20:50:42 CET] <xjmx_> BtbN yes, I have tried but maybe you have a ready preset? Is there any debug commands for ffprobe ? [20:50:49 CET] <xjmx_> how to detect asynch [20:51:42 CET] <xjmx_> DHE I'm not sure :( [20:52:09 CET] <Cysioland> kepstin, my cmdline: ffmpeg -f mjpeg -analyzeduration 5000 -probesize 20000 -i http://10.0.0.5/VIDEO.CGI -vf settb=AVTB,setpts=RTCTIME-RTCSTART,fps=24 test.mp4 [20:52:20 CET] <Cysioland> Video seems to be correct length, but is unplayable [20:52:54 CET] <kepstin> Cysioland: unplayable with what player? can you try with e.g. ffplay, give full output? and also the ffmpeg output? [20:53:57 CET] <Cysioland> kepstin, unplayable with Windows 10 one (Groove probably). ffplay cannot try, because currently am doing it on a headless machine. [20:59:47 CET] <Cysioland> kepstin, https://gist.github.com/Cysioland/a1a5e41cec1cc9b86b79a7c1ea115de8 [21:00:33 CET] <kepstin> Cysioland: your problem is probably https://gist.github.com/Cysioland/a1a5e41cec1cc9b86b79a7c1ea115de8#file-gis… [21:02:48 CET] <Cysioland> kepstin, trying that... [21:03:38 CET] <kam187> anyone have experience with flv/rtmp (libavformat i.e. using the library not ffmpeg binary)? I'm trying to do resolution change mid stream. I've sent onMetaData and AVC updates but youtube and twitch both do not change resolution. [21:05:49 CET] <Cysioland> kepstin, works, that camera is utter poop though [21:10:30 CET] <Meins_da> Hello! [21:10:38 CET] <Meins_da> i need help with udp streaming [21:11:46 CET] <Meins_da> my client is a Setupbox with a 100MBit connection. My server has a 1GB. Between the two devices i have 3 switches. the last one before the setupbox can handle igmp snooping [21:12:17 CET] <Meins_da> if i use this setup, i have problems to stream, if i set the server interface to 100MBit half duples, it works... [21:12:37 CET] <Meins_da> it seems that ffmpeg sends the data tooo fast to the client [21:14:41 CET] <BtbN> are you streaming at more than 100Mbps? oO [21:15:02 CET] <Meins_da> Hi BtbN [21:15:05 CET] <thebombzen> o_O [21:15:09 CET] <Meins_da> at the moment i have one stream [21:16:34 CET] <Meins_da> on my pc with 1gb (it is also connected to the last switch) it also works perfect, but it has more performance than the stp [21:27:48 CET] <Meins_da> No idea BtbN? [21:28:03 CET] <BtbN> Well, are you? [21:28:10 CET] <BtbN> Still haven't answered. [21:40:42 CET] <thebombzen> Meins_da: "ffmpeg is sending the data too fast to the client" [21:40:48 CET] <thebombzen> check out the -re input option [21:44:00 CET] <Meins_da> yes the -re is set [21:45:08 CET] <thebombzen> well then you shouldn't be sending data too fast [21:45:14 CET] <thebombzen> if your client can't read realtime data then your client sucks [21:45:41 CET] <Meins_da> ffmpeg -threads 2 -re -fflags +genpts -i samsung_low_1M_2M.ts -vcodec copy -acodec copy -f mpegts "udp://239.2.0.2:1234?broadcast=1" [21:46:00 CET] <Meins_da> thebombzen it is a MAG256 [21:46:28 CET] <thebombzen> that does not actually answer anything [21:46:36 CET] <thebombzen> if you are broadcasting the data in realtime [21:46:39 CET] <thebombzen> but realtime is too fast [21:46:43 CET] <thebombzen> then there's nothing ffmpeg can do about that [21:46:51 CET] <thebombzen> because if realtime is too fast then you can't stream. [21:47:17 CET] <thebombzen> because in order to stream, you have to be able to consume video in realtime [21:47:22 CET] <thebombzen> otherwise there's really no point [21:51:22 CET] <Meins_da> do you mean that the software of the mag has a problem? [21:52:00 CET] <thebombzen> what I"m saying is, if you're producing video in realtime [21:52:03 CET] <thebombzen> but realtime is "too fast" [21:52:10 CET] <thebombzen> then you need to fix whatever is unable to consume video in realtime [21:52:34 CET] <Meins_da> can you check my command line if this is ok? [21:52:50 CET] <thebombzen> your ffmpeg command line is the producer [21:52:59 CET] <thebombzen> your problem is you cannot consume the video in realtime [21:53:07 CET] <thebombzen> you need to fix that problem, or you won't be able to play a livestream [21:53:48 CET] <Meins_da> i don't understand you at the moment. [21:54:08 CET] <Meins_da> do you think i can't read the file fast enouth? [21:55:37 CET] <IntruderSRB> hey guys, do you know if FFMPEG has added support for HLS with fMP4 cbcs encryption support? [21:56:01 CET] <IntruderSRB> I saw some changes regarding encryption and HLS on mailing list but didn't managed to find this one out [22:00:20 CET] <JEEB> IntruderSRB: you can check what encryption mode the cenc thing in movenc.c uses, and if it's not there it's not implemented [22:00:38 CET] <JEEB> if it's not implemented then make a feature request. [22:00:53 CET] <JEEB> normal MPEG-TS HLS encryption is supported, and has been for years. [22:02:57 CET] <JEEB> feature requests go to the trac, just fyi [22:03:17 CET] <JEEB> (also another alternative is that you implement the feature and post a patch on the ML) [22:06:57 CET] <IntruderSRB> nop ... looks like only MOV_ENC_CENC_AES_CTR [22:07:01 CET] <IntruderSRB> is supported now [22:07:27 CET] <IntruderSRB> I'll be the first to share patch once I get my CENC_AES_CBC to work :) [22:39:30 CET] <IntruderSRB> btw. if anyone has any m3u8 playlist that uses fmp4 with cbcs - please share, I fail to find any... [22:42:26 CET] <JEEB> https://tools.ietf.org/html/draft-pantos-http-live-streaming-20#page-14 [22:42:29 CET] <JEEB> probably the relevant part [22:43:03 CET] <JEEB> so it seems to be the same as with "normal HLS" [22:49:04 CET] <bray90820> OF TOPIC: Can any device that can play MP4 play M4V [22:49:32 CET] <thebombzen> what is m4v [22:49:55 CET] <thebombzen> because iTunes' file extension .m4v is not the same as ffmpeg's m4v encoder [22:49:59 CET] <thebombzen> m4v muxer* [22:50:19 CET] <bray90820> Well isn't the only difference that M4 on itunes has DRM? [22:50:25 CET] <thebombzen> apple's .m4v files are just mp4 files (possibly with drm) [22:50:42 CET] <bray90820> thebombzen: Yeah that's what I was talking about [22:50:51 CET] <thebombzen> well then the answer is yes as long as there's no drm [22:51:00 CET] <bray90820> thebombzen: Thanks [22:51:13 CET] <thebombzen> it doesn't matter what the filename is, if it's an mp4 file without drm then it's still an mp4 file even if apple thinks .m4v is cooler than .mp4 [22:51:50 CET] <thebombzen> if it's got drm then you can only play it on iDevices which definitely can play it [00:00:00 CET] --- Thu Mar 9 2017

1 0

ffmpeg-devel.log.20170307
by burek 08 Mar '17

08 Mar '17

[03:08:40 CET] <atomnuker> jamrial: sorry about that, I had a bad week [03:13:40 CET] <TD-Linux> on a semi related note, if this picture is real then swr is well into potentially audible artifacts :/ http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170306/39906029/atta… [03:14:38 CET] <TD-Linux> so bad as to be actually broken [03:17:23 CET] <kode54> you may note that the bright orange in the picture is -80 dB [03:17:58 CET] <kode54> probably fixable by doubling the window size of the resampler [03:18:14 CET] <kode54> or rather, reducible [03:18:45 CET] <kode54> my own extremely low latency resamplers have noticeable artifacts approaching -95 dB [03:18:53 CET] <kode54> if you call that noticeable [03:18:57 CET] <kode54> visible on a spectrogram [03:19:16 CET] <TD-Linux> well 96db is 16bit so that should be fine [03:19:52 CET] <kode54> sox resampler, while bordering on perfect, is not the lowest latency, but LGPL, so it may be possible to make use of it for general purpose [03:19:57 CET] <TD-Linux> I'm all for removing resamplers, if libswr can be set to produce similar quality it's fine, but it's interesting that it's so broken [03:20:08 CET] <kode54> my resampler isn't designed for general purpose signal, but rather multi-channel mixing [03:20:08 CET] <TD-Linux> er not really broken but default settings so bad [03:20:24 CET] <TD-Linux> speex/opus resampler is quite a bit better by default [03:29:47 CET] <kode54> appears to use a filter size of 32 samples by default [03:30:40 CET] <kode54> as does my resampler [03:30:48 CET] <kode54> or one of them does [03:31:10 CET] <kode54> it's designed for low latency software mixing in music reproduction [03:31:28 CET] <kode54> soxr would be better, but also probably harder to make effective use of [03:32:01 CET] <kode54> never mind that I also have linear interpolation, cubic interpolation, and two zero order hold algorithms to please people who want alternatives [04:08:43 CET] <kode54> https://gist.github.com/kode54/d4220e418cd479b753c7 that's my most recent resampler, with makefile that runs tests with sox [04:09:37 CET] <kode54> http://imgur.com/a/SsejT and this is what it generates [04:10:48 CET] <kode54> you have to admit, it looks significantly better in the top image, which has a spectrum range of 0-96 dB [11:09:19 CET] <BtbN> wm4, mpv is litterally the only player that does not lag my entire laptop. [11:10:39 CET] <JEEB> :D [11:12:10 CET] <kierank> wm4: regarding the thread [11:12:12 CET] <kierank> safe patch [11:12:20 CET] <kierank> isn't the idea all the codecs themselves should be threadd safe [11:12:23 CET] <kierank> not the initialiser? [11:12:33 CET] <JEEB> I thought that's how it began at least [11:12:45 CET] <wm4> BtbN: interesting [11:12:45 CET] <kierank> because that seems like a massive hack [11:12:59 CET] <wm4> kierank: codec init safety != codec list safety [11:13:17 CET] <kierank> ok [11:13:27 CET] <wm4> codec inits are not really covered by this (although there's this silly init_static thing that only a few codecs use) [11:14:04 CET] <wm4> 8 codecs [11:14:11 CET] <wm4> nice headache [11:14:27 CET] <kierank> derek send patches iirc [11:14:28 CET] <kierank> sent* [11:14:35 CET] <wm4> yeah [11:14:44 CET] <wm4> e.g. X264_init_static mutates AVCodec.pix_fmts [11:14:52 CET] <wm4> this can't be fixed [11:15:23 CET] <wm4> would probably be best to add some sort of dynamic API to determine codec parameters [11:15:31 CET] <JEEB> yea [11:18:44 CET] <wm4> x264, x265, vpxenc, vpxdec set AVCodec.pix_fmts, openjpegdec sets an experimental flag depending on the library version (wtf), jpeg2000, wmavoice, qdmc init static tables [11:25:16 CET] <nevcairiel> at least static table init could be moved elsewhere [11:25:29 CET] <nevcairiel> the first couple that set pixfmt based on external library version seems like it cant really be avoided [11:25:38 CET] <nevcairiel> or needs re-design [11:31:32 CET] <BtbN> wm4, like, the next best "player" is MS Edge, which still eats 30% CPU. Then MPC-HC with 30-40%, and VLC which can't even keep up, fully using the CPU [11:31:42 CET] <BtbN> mpv is sitting at ~5% right now [11:31:55 CET] <ismail> BtbN: which vo? [11:32:05 CET] <BtbN> No idea, the default, didn't touch any settings [11:32:09 CET] <ismail> oh ok [11:32:24 CET] <ismail> on Windows I had similar good experience with dxva [11:32:30 CET] <BtbN> Has to be something DXVA accelerated I assume [11:32:34 CET] <ismail> yeah [11:32:42 CET] <BtbN> No idea how else it would achive that [11:32:52 CET] <BtbN> Makes you wonder what all the other players are doing [11:32:53 CET] <wm4> BtbN: mpv doesn't enable dxva by default, though [11:33:54 CET] <wm4> ismail: it uses opengl via angle by default (with custom swapchain code) [11:34:08 CET] <nevcairiel> sounds to me like your laptop is having issues if playing some 720p with hwaccel lags it [11:35:49 CET] <j-b> end of cinepack drama. [11:36:04 CET] <JEEB> and good riddance [11:36:31 CET] <ismail> wm4: yeah I manually switched to dxva and < %10 cpu for 2160p h264 decoding [11:37:43 CET] <wm4> j-b: not sure why it's "APPLY MY PATCHES OR DIE", but ok [11:38:01 CET] <j-b> wm4: BECAUSE DIE DIE DIE, YOU HERETIC [11:38:08 CET] <wm4> ismail: try hwdec=auto (that would use d3d11va) [11:38:19 CET] <ismail> wm4: will try, thanks! [12:21:13 CET] <cone-310> ffmpeg 03Aman Gupta 07master:b6eaa3928e19: avcodec/h264, videotoolbox: fix crash after VT decoder fails [12:34:19 CET] <nevcairiel> 3 people respond, and that guy only reads carls confused reply? way to go =p [12:34:42 CET] <wm4> carl being "helpful" again [13:22:30 CET] <kierank> durandal_1707: did you see libav patches to pixlet [13:23:14 CET] <durandal_1707> yes i did [13:38:38 CET] <iive> nevcairiel: what are you talking about? [14:04:53 CET] <cone-310> ffmpeg 03Vittorio Giovara 07master:a6b1180e3909: avcodec/pixlet: fix architecture-dependent code and values [14:26:04 CET] <durandal_1707> iive: he is talking about confused carl [14:29:29 CET] <iive> durandal_1707: your reply contained 0bit of useful information. it just repeated your rants from above. [14:30:51 CET] <durandal_1707> iive: see ml and patch about h2645 [14:30:55 CET] <iive> ok, not your rants [14:31:22 CET] <iive> ok, at least now i know where and what. thank you. [14:47:37 CET] <cone-310> ffmpeg 03Muhammad Faiz 07master:e85e8408802d: avcodec/allcodecs: make avcodec_register_all thread safe [14:47:38 CET] <cone-310> ffmpeg 03Muhammad Faiz 07master:49635f0a4636: avfilter/allformats: make av_register_all thread safe [14:47:39 CET] <cone-310> ffmpeg 03Muhammad Faiz 07master:af7010ad0557: avfilter/allfilters: make avfilter_register_all thread safe [14:47:40 CET] <cone-310> ffmpeg 03Muhammad Faiz 07master:776f289c0fe8: avdevice/alldevices: make avdevice_register_all thread safe [15:12:42 CET] <adit> hi [15:13:33 CET] <adit> I am bent on doing GSoC for this org. As for my vr proficiency is considered, I know quite a bit in that area, so any assistance would be helpful. [15:13:51 CET] <adit> I also won the google powered hackathon two to three days ago where I made a virtual city. [15:15:00 CET] <wm4> pick a topic on the ffmpeg gsoc wiki page, contact the mentor for the project you want [15:15:37 CET] <adit> thank you sir. :D [15:15:51 CET] <adit> can you give to me the link of the page? [15:16:25 CET] <wm4> the general website is in the topic, just look for the wiki [15:17:15 CET] <adit> Yes sir. Thank you so much. :D [15:18:29 CET] <rcombs> (VR? in ffmpeg?) [15:19:10 CET] <adit> :P It was having a tag of VR on GSoC's page [15:19:32 CET] <durandal_1707> topic have only link to code of conduct [15:20:22 CET] <adit> here https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2017 [15:22:03 CET] <durandal_1707> VR stands for Virtual Reality? [15:22:38 CET] <wm4> jamrial: to be specific, he wouldn't have needed to send a patch? [15:23:10 CET] <jamrial> wm4: who? [15:23:22 CET] <jamrial> Faiz? [15:23:26 CET] <wm4> jamrial: yes [15:23:39 CET] <jamrial> patch for what? he sent the updated set that you reviewed [15:24:27 CET] <durandal_1707> reviewing patchset considered harmful [15:24:30 CET] <wm4> I mean, he could have just pushed straight to master, without even sending the first version to the ML [15:24:47 CET] <wm4> because it's an unmaintained file [15:27:42 CET] <jamrial> no, ideally you wouldn't do that. the result would have been the first version without pthreads_once being pushed, which would then probably be replaced once you or someone else mentioned it [15:28:17 CET] <wm4> well, I thought it's fine to just push changes to unmaintained files [15:28:29 CET] <adit> durandal_1707: yes [15:36:32 CET] <jamrial> wm4: it's fine for simple bug fixes, cosmetics and such, but behavior changes or bug fixes that may have more than one solution are IMO better posted to the ml to avoid poinlessly reverting code once people complain or replacing it once people suggest a better solution [15:37:03 CET] <jamrial> i'm not saying that's what always happens, because i think it sometimes doesn't [15:37:05 CET] <jamrial> just what i think is ideal [16:58:44 CET] <BBB> j-b: dude, youre on wikileaks [16:59:07 CET] <BBB> j-b: thats pretty impressive, congrats :D [16:59:48 CET] <BBB> relevant quote of the day: To witnesses, the spy appears to be running a program showing videos (e.g VLC) [..]. But while the decoy application is on the screen, the underlaying system is automatically infected and ransacked. [17:02:07 CET] <j-b> BBB: lolwut? [17:02:26 CET] <BBB> really true :D [17:03:09 CET] <BBB> now of course the relevant question is: what video codec do these decoy videos use? [17:03:21 CET] <durandal_1707> vp13 [17:03:21 CET] <BBB> and if its h264, did they pay the relevant licensing fees? [17:03:32 CET] <BBB> :D [17:07:18 CET] <j-b> I'd say dll hijacking [17:08:11 CET] <j-b> VLC Player Portable [17:08:44 CET] <bencoh> :D [17:30:08 CET] <ubitux> mmh, so we have "aspect" option in ffmpeg cli and lavc [17:30:14 CET] Action: ubitux wonders which one gets set [17:30:23 CET] <ubitux> also, option looks untested for some reason [18:01:01 CET] <atana> michaelni, ping [18:06:51 CET] <michaelni> atana, pong [18:07:23 CET] <atana> I tried applying hamming window to the data by multiplying the data with window entries. [18:07:53 CET] <atana> but I guess I did something wrong as now there is no match found [18:08:36 CET] <michaelni> atana, can you push / or show the code so i can take a look ? [18:08:50 CET] <atana> I will push the code [18:09:40 CET] <atana> pushed [18:18:47 CET] <michaelni> atana, the log2() is incorrect, the window needs to have as many points as the fft, that is if the fft has 1024 points the window needs 1024 points [18:19:26 CET] <atana> so same as transform size. ok [18:25:39 CET] <BBB> michaelni: I guess what Im confused about is what the code is doing that is taking so much time if we usually exit the loop (because input buffer = exhausted) after the first MB anyway [18:27:47 CET] <BBB> michaelni: you have to realize how little information we have, so its hard to discuss this without having a sample. what codec are we talking about here? and why is 0 byte input being converted into (apparently) tons of bitstream inits during (apparently) header parsing time? [18:29:05 CET] <michaelni> BBB, i think it was vp8 and theres a loop we check only per mb row [18:29:30 CET] <BBB> so Im imagining that the width of this sample is really big? [18:29:53 CET] <BBB> I dont think this makes sense& what if the buffer is 1 byte? it will pass your check but still timeout [18:29:54 CET] <cone-310> ffmpeg 03Vittorio Giovara 07master:1b7ffddb3a99: spherical: Add tiled equirectangular type and projection-specific properties [18:29:55 CET] <cone-310> ffmpeg 03Vittorio Giovara 07master:022b4ea5837b: mov: Export bounds and padding from spherical metadata [18:29:56 CET] <cone-310> ffmpeg 03Vittorio Giovara 07master:bde96422686f: mkv: Export bounds and padding from spherical metadata [18:30:09 CET] <BBB> the timeout itself needs to be fixed if that is the issue [18:30:24 CET] <BBB> if that means we need to do that per mb instead of per mb row (for vp8), then maybe thats ok [18:30:35 CET] <BBB> Im assuming the overhead introduced by a per-mb bitstream-end check is minimal [18:31:14 CET] <michaelni> i can try to add a per mb check if you prefer (need to check if that works) ? [18:32:34 CET] <michaelni> are you against the init check or should that go in in addition ? it feels to me that its wrong to init on 0 size [18:33:24 CET] <BBB> (Im thinking :) ) [18:33:34 CET] <atana> michaelni, 9 failures in this case [18:34:00 CET] <BBB> I agree its wrong to init on 0-sized data [18:34:13 CET] <BBB> so its probably ok in that sense [18:34:31 CET] <michaelni> atana, try to overlap the ffts, that is instead of doing a fft with input from 0..1024 then 1024..2048, ... try 0..1024, 512..1536, ... [18:34:31 CET] <BBB> but I dont have a very strong opinion on it, since like I said I dont really think it fixes the true issue youre after here [18:35:24 CET] <BBB> so as long as the per-mb check is there to fix it for the more general case, I guess this patch is OK (unless others object) [18:35:30 CET] <atana> michaelni, ok [18:36:15 CET] <BBB> michaelni: please add return value check to vp9.c also [18:36:25 CET] <BBB> (youre only adding it to vp8.c and vp6.c, not vp9.c) [18:36:36 CET] <michaelni> ok [18:43:23 CET] <nevcairiel> interesting fate failure i got, and curious it didnt fail before [18:44:15 CET] <nevcairiel> fate-mov-spherical-mono dumps the side_data content through ffprobe, which includes the side_data_size field [18:44:28 CET] <nevcairiel> that particular side data includes size_t fields, which vary in size on different platforms [18:44:35 CET] <nevcairiel> ie. 32-bit on 32-bit, 64-bit on 64-bit [18:44:43 CET] <nevcairiel> so logically one might conclude the struct size also varies [18:45:01 CET] <nevcairiel> but it didnt fail before, and it does now on vs2017 [18:45:38 CET] <JEEB> funky [18:45:55 CET] <nevcairiel> maybe they changed default struct packing somewhere [18:46:02 CET] <nevcairiel> still seems like an easy thing to fail [18:46:21 CET] <wm4> uh that would change ABIs... [18:46:29 CET] <nevcairiel> oh wait, that test is new in the patchset from 20 minutes ago, isnt it [18:46:32 CET] <nevcairiel> fate just didnt catch it [18:46:45 CET] <wm4> hm yes [18:47:32 CET] <wm4> (still not sure why we'd use size_t for image dimensions???) [18:48:17 CET] <nevcairiel> probably some diego arguments or so [18:48:38 CET] <wm4> I think it was elenril who argued in favor [18:49:34 CET] <BtbN> So, VC15 releases today? [18:49:39 CET] <nevcairiel> it did already [18:49:54 CET] <BtbN> nice, lets see if it updates itself [18:50:17 CET] <BtbN> yes it does [18:52:44 CET] <wm4> fate seems to fail on linux 64 bit too [18:52:52 CET] <wm4> matroska-spherical-mono [18:53:11 CET] <wm4> seems weird though (missing fields?) [18:53:33 CET] <nevcairiel> failing on 64-bit sounds weird [18:54:15 CET] <wm4> could it be that fate updated files have not been uploaded yet or something? [18:54:28 CET] <nevcairiel> doesnt use external samples [18:54:32 CET] <nevcairiel> no new ones anyway [18:54:56 CET] <wm4> kode54: pls fix [18:54:59 CET] <wm4> err [18:55:01 CET] <nevcairiel> wrong kod* guy [18:55:04 CET] <wm4> he isn't here [18:55:23 CET] <wm4> who pushed those commits? [18:55:29 CET] <nevcairiel> himself [18:59:40 CET] <JEEB> i think koda recently posted some fixes for something although that could have been the pixlet thing [19:01:12 CET] <durandal_1707> i did pixlet commit [19:02:36 CET] <nevcairiel> it appears libav doesnt print side data size [19:02:49 CET] <nevcairiel> maybe we should remove that, it seems fragile with struct alignment and whatnot [19:02:58 CET] <nevcairiel> (and largely irrelevant info) [19:04:38 CET] <durandal_1707> yeah [19:09:46 CET] <BtbN> Hm, after updating it, it now wants a product key. Should have thought about that. [19:09:52 CET] <BtbN> At least the commandline tools still seem to work. [19:09:56 CET] <nevcairiel> shouldve used community [19:09:59 CET] <nevcairiel> its free [19:10:11 CET] <BtbN> I get a key via university, just have to wait until they update [19:10:27 CET] <BtbN> They still list the RC there [19:10:39 CET] <nevcairiel> the versions contain the same things anyway, so unless you use it professionally [19:11:38 CET] <BtbN> I downloaded it via university mirrors, and that gives you Enterprise. [19:12:44 CET] <BtbN> Got a 30 day grace period, and by then MS Imagine should be updated. [19:13:44 CET] <cone-310> ffmpeg 03Michael Niedermayer 07master:5098a6f6275a: avcodec/vp8: remove redundant check [19:16:28 CET] <adeel1> durandal_1707: I've changed this: *(p->data[1] + i * 4 ) = rgba[2]; to this: *(*(x->frame->data[1] + i * 4 )) = rgba[2]; [19:16:55 CET] <adeel1> durandal_1707: but there's still a seg fault [19:18:04 CET] <durandal_1707> frame is null [19:18:15 CET] <BtbN> Is using sscanf fine? Or is there an av_* function for it? [19:20:55 CET] <durandal_1707> adeel1: use p->data[1][i * 4].... [19:21:15 CET] <adeel1> okay [19:25:15 CET] <adeel1> durandal_1707: I'm using this now: (p->data[1][i * 4 ]) = rgba[0]; but still same issue [19:27:17 CET] <durandal_1707> adeel1: give full diff [19:29:10 CET] <adeel1> durandal_1707: https://gist.github.com/adl1995/30b9693822aa18dc627384d19a3b1986 [19:34:07 CET] <durandal_1707> adeel1: remove commented out code, will you [19:34:18 CET] <adeel1> oaky [19:34:22 CET] <adeel1> okay* [19:34:32 CET] <durandal_1707> you use x->frame bellow, use p instead [19:34:40 CET] <durandal_1707> remove printf [19:35:24 CET] <durandal_1707> remove frame from XPMDecContext struct [19:39:09 CET] <adeel1> durandal_1707: yea, it worked :D but only for 1 example. still seg faults on the other one [19:40:22 CET] <durandal_1707> adeel1: give link to that xpm sample [19:41:14 CET] <adeel1> durandal_1707: It fails on this one: https://github.com/ifwe/wx/blob/master/samples/sample.xpm [19:42:42 CET] <durandal_1707> adeel1: what error you get? [19:43:16 CET] <adeel1> 17167 segmentation fault (core dumped) [19:45:10 CET] <durandal_1707> adeel1: give full diff of your current work [19:46:18 CET] <adeel1> durandal_1707: https://gist.github.com/adl1995/b952004d435f5f1a991a9c1e8f839c7a [19:56:07 CET] <durandal_1707> adeel1: the code looks wrong, p->data[0] should be filled with indexes directly, not with pixels stuff [20:04:22 CET] <adeel1> durandal_1707: I'm not sure if I follow. I've changed p->data[0] + i * p->linesize[0]; to p->data[0] + i; but this only changed the dispaly location for working examples [20:04:26 CET] <adeel1> example* [20:08:05 CET] <durandal_1707> adeel1: that was good code [20:08:56 CET] <durandal_1707> adeel1: you need to change to use ascii2index directly [20:11:10 CET] <adeel1> durandal_1707: so I should remove the ascii2index function and use it inline where required? [20:12:37 CET] <durandal_1707> adeel1: nope, you should remove pixels array usage just before it [20:16:02 CET] <llogan> JEEB: would you be willing to add a message saying something like, "x264ops has been deprecated. Use x264-params instead"? I think that should address the "deprecated" concern. [20:17:47 CET] <JEEB> I can do such a patch, sure [20:17:57 CET] <adeel1> durandal_1707: okay, I've change x->pixels[ascii2index(ptr, cpp)] to ascii2index(ptr, cpp), the seg fault is gone now but I get: nan M-V: nan fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0 and there's not output [20:18:02 CET] <llogan> thanks [20:19:18 CET] <BBB> michaelni: patches are OK I think (do you want a reply on ML?) [20:19:30 CET] <durandal_1707> adeel1: show your code [20:21:03 CET] <michaelni> BBB, no need, ill apply [20:24:45 CET] <adeel1> durandal_1707: https://gist.github.com/adl1995/9c3e87596d3460ac4f68719e45c25e6b [20:51:55 CET] <durandal_1707> adeel1: so it shows black? [21:45:29 CET] <cone-310> ffmpeg 03Michael Niedermayer 07master:55d7371fe0c4: avcodec/vp568: Check that there is enough data for ff_vp56_init_range_decoder() [21:45:30 CET] <cone-310> ffmpeg 03Michael Niedermayer 07master:1afd24696020: avcodec/vp8: Check for the bitstream end per MB in decode_mb_row_no_filter() [21:52:09 CET] <JEEB> nevcairiel: did VS2017 work for FFmpeg? [21:58:21 CET] <nevcairiel> yes [22:06:46 CET] <BtbN> Seems like a really good update [22:06:53 CET] <BtbN> the new installer is also nice [22:08:30 CET] <JEEB> man, I should really reinstall this machine at some point [22:08:37 CET] <JEEB> > MSVS 2010, 2013, 2015 [22:09:08 CET] <BtbN> Just uninstall the old ones? [22:09:45 CET] <JEEB> I have really bad recollection of old MSVS uninstallers [22:55:28 CET] <jamrial> koda addressed my reviews for the version he pushed on libav but not for the one he pushed here :p [22:56:17 CET] <jamrial> not like it would have changed the fate failures anyway. but he did push broken cubemap parsing code for mov [23:43:34 CET] <knight___> where is AVFrame defined? [23:44:33 CET] <nevcairiel> libavutil/frame.h [23:45:24 CET] <knight___> can you explain me how sound data is stored in frames? [23:48:12 CET] <durandal_1707> its stored as array [23:49:34 CET] <knight___> is there any place I can read about it? [23:49:38 CET] <durandal_1707> looking at any code in lavc and lavfi could show you how it is manipulated [23:51:48 CET] <knight___> what is lavc? [23:53:23 CET] <llogan> libavcodec [23:56:03 CET] <llogan> damn...made the mistake of clicking "rebuild folder tree" in claws-mail. now it will be 14 years before i can use it again. [00:00:00 CET] --- Wed Mar 8 2017

1 0

ffmpeg.log.20170307
by burek 08 Mar '17

08 Mar '17

[00:00:08 CET] <alexpigment> yeah, i'd made sure and test that parameters on your friend's computer if it failed on QSV. i know that it's required at least up until haswell, and possible on current hardware [00:01:09 CET] <TehEpikDuckeh> It failed on his computer whenever I did CUVID to QSV. But using just the GPU, it was really fast for even HEVC to H264. [00:01:56 CET] <TehEpikDuckeh> NVIDIA should make a dedicated card for just CUVID and NVENC. They could sell the ASIC for very cheap and people would buy it. I'd buy it for the server. [00:02:26 CET] <TehEpikDuckeh> Just installed the drivers again, but nope.avi [00:02:31 CET] <alexpigment> :( [00:02:34 CET] <TehEpikDuckeh> :/ [00:02:40 CET] <alexpigment> well, i'm not entirely sure what else to do [00:02:50 CET] <TehEpikDuckeh> Neither do I. [00:02:51 CET] <alexpigment> have you omitted the cuvid part to see if it's just the decoding that's failing? [00:02:55 CET] <TehEpikDuckeh> I'm probably going to build again. [00:02:59 CET] <TehEpikDuckeh> rebuild* [00:03:07 CET] <TehEpikDuckeh> It's just HEVC_CUVID that's the issue. [00:03:10 CET] <ZeroWalker> hmm, so when i got a packet from x264, should i then sent it to a muxer that will write and append? [00:03:28 CET] <TehEpikDuckeh> I could use H264_CUVID to HEVC, or H264_NVENC and it works just fine. [00:03:46 CET] <ZeroWalker> and which part will do the frame syncing according to the timestamps "so if i receive 20fps but i want it to be 30fps, it will duplicate frames to make it so" kinda thing [00:03:51 CET] <alexpigment> oh i see. hmmm, i haven't tested HEVC cuvid to be honest [00:03:56 CET] <BtbN> There was Crystal HD. It was shit. [00:04:19 CET] <TehEpikDuckeh> alexpigment: Must be extremely new due to issues as such. H264_CUVID is just fine. [00:05:15 CET] <TehEpikDuckeh> Actually, H264_CUVID to HEVC_NVENC is extremely fast. Last night I tested it and it was encoding around 1000 fps. I thought it was a glitch, but it wasn't. Quality was a bit crappy (hence 1000 fps) but it was a cool test. [00:05:50 CET] <alexpigment> yeah, quality is certainly the secondary priority [00:06:04 CET] <alexpigment> (for nvidia, i mean) [00:06:19 CET] <TehEpikDuckeh> How do you mean? [00:06:49 CET] <alexpigment> well, at a given bitrate, nvenc is always worse than x264 or x265 [00:06:56 CET] <alexpigment> but speed is faster [00:07:08 CET] <alexpigment> and of course resources usage is lower [00:07:21 CET] <alexpigment> so it's great for, say, screen recording or teleconferencing [00:07:47 CET] <alexpigment> not great for encoding an optimized file for streaming or disc authoring [00:07:51 CET] <TehEpikDuckeh> Seriously? But let's say we had the bitrate at a certain amount, 4000 KB/s, would NVENC look just as good as x264/5, or would it be a crappier quality? [00:08:04 CET] <alexpigment> nvenc would look worse [00:08:15 CET] <TehEpikDuckeh> Noticeably worse? [00:08:35 CET] <alexpigment> well, there's a threshold at which it stops mattering because you're reaching transparency [00:08:50 CET] <alexpigment> but at 4000kbps and below for HD material, yeah, you'll probably notice the difference [00:08:53 CET] <ZeroWalker> nvenc looks a ton worse compared to x264 on default settings [00:09:04 CET] <ZeroWalker> same with amd vce [00:09:11 CET] <alexpigment> and qsv [00:09:19 CET] <TehEpikDuckeh> Seriously. Wow, had no idea. [00:09:27 CET] <alexpigment> all the hardware encoders are lagging behind x264 in terms of quality [00:09:30 CET] <ZeroWalker> done many tests on especially amd vce, it's really bad compared to x264, but that's to be expected [00:09:31 CET] <TehEpikDuckeh> So all HW transcoding is trash? [00:09:39 CET] <ZeroWalker> in short, yes [00:09:42 CET] <TehEpikDuckeh> Wow. [00:09:51 CET] <ZeroWalker> you only use it for speed, nothing else [00:09:53 CET] <BtbN> it's CPU free encoding. [00:09:55 CET] <alexpigment> no, not trash, really. but you have to have a specific use case to justify using hardware encoding [00:09:57 CET] <TehEpikDuckeh> I only want to use it so I can transcode crap w/o the server dying. [00:10:07 CET] <ZeroWalker> well in that case it's useful [00:10:14 CET] <TehEpikDuckeh> ... and so it looks fairly good. [00:10:24 CET] <ZeroWalker> i mean, like he said, you would never use it for quality per see [00:10:34 CET] <ZeroWalker> if you got the performance, x264 is what you want [00:10:36 CET] <TehEpikDuckeh> Hmmm, strange. [00:10:43 CET] <alexpigment> is this just for streaming to devices, or are you actually using those hardware transcodes as saved copies for posterity? [00:10:59 CET] <TehEpikDuckeh> Streaming mainly. [00:11:05 CET] <ZeroWalker> for example, i use amd vce with like 40mbps, and it's still bad [00:11:06 CET] <BtbN> you can also use them for high quality local second encodes while streaming [00:11:14 CET] <BtbN> when you don't care about the files being a little larger [00:11:21 CET] <alexpigment> zerowalker: to be fair, AMD is not even trying in this field ;) [00:11:24 CET] <TehEpikDuckeh> ZeroWalker: Then something is probably wrong. It probably should look just fine by then. [00:11:29 CET] <ZeroWalker> they aren't? [00:11:44 CET] <ZeroWalker> i mean, i wouldn't say quicksync is any better [00:11:49 CET] <alexpigment> no, they came late to the game [00:11:57 CET] <alexpigment> and ffmpeg doesn't even support VCE yet [00:12:04 CET] <TehEpikDuckeh> BtbN: I'd prefer to save space and have things look nice. Hence why I'm attempting HEVC. [00:12:19 CET] <ZeroWalker> can't say that much for nvenc as i don't have much data on those, or well i got some from maxwell i think [00:12:23 CET] <alexpigment> intel and nvidia have a good head start compared to VCE [00:12:30 CET] <ZeroWalker> yeah i don't get why ffmpeg doesn't support VCE [00:12:38 CET] <ZeroWalker> VCE has existed since 7xxx series [00:12:51 CET] <ZeroWalker> though their support is horrible [00:12:55 CET] <BtbN> If you are aiming for quality at minimum size, use x264 [00:12:56 CET] <ZeroWalker> vce that is [00:12:57 CET] <alexpigment> yeah, but i think it was severely limited then [00:12:59 CET] <TehEpikDuckeh> Damn, and AMD can't make their crap nicer? Gees. [00:13:21 CET] <BtbN> you don't just make a hardware encoder that's on par with software encoding [00:13:24 CET] <alexpigment> having said that, i'm also shocked that 40mbps isn't reaching transparency for 1080p... [00:13:31 CET] <TehEpikDuckeh> I wonder how good Ryzen is at encoding HEVC. [00:13:31 CET] <ZeroWalker> well yeah it was, at least resolution wise, and it was weak [00:14:17 CET] <ZeroWalker> i got r9 380, so i can do 1920x1200 60fps, but i from however have coded for it (i haven't) it seems the SDK etc is just bad and weird [00:14:56 CET] <ZeroWalker> and i wouldn't brag about the capabilities of the VCE encoder, i have had much issues with it, if you play around you can easily make things freeze up or something [00:14:58 CET] <TehEpikDuckeh> I was really pissed off whenever I was trying to use an older card on Linux and AMD had no driver support at all for newer versions of Ubuntu. (now I'm on Debian) [00:15:49 CET] <ZeroWalker> well i heard good things about the encoding quality and performance of Ryzen, though haven't seen any tests, but it should surely be better than what AMD got now, how much however i duno [00:16:02 CET] <alexpigment> yeah, in the not too distant past, everyone used Nvidia for XBMC on low-end hardware because intel and AMD didn't have driver support for harware decoding. intel came next, and then AMD [00:16:23 CET] <ZeroWalker> if they could make it 30% better, it would be quite decent quality wise, though i would want like 50+ tbh, but that's wishful thinking;p [00:16:25 CET] <TehEpikDuckeh> Intel supposedly has some good driver support on Linux. [00:16:37 CET] <alexpigment> they do now [00:16:43 CET] <alexpigment> but this was in like 2010 or so [00:17:35 CET] <alexpigment> i had one of the first gen intel atom systems with an nvidia "ion" graphics card. it could play anything due to having hardware acceleration support on linux at the time. intel and amd didn't have support back then [00:17:46 CET] <alexpigment> so yeah, i guess it's been like 7 years, but it feels like not too long ago ;) [00:18:31 CET] <TehEpikDuckeh> I'd like to get some Ryzen hardware to test and make a YouTube video on it. I'd then get a Black Magic HDMI interface device so I can livestream to YouTube. I need some streaming hardware because people on my channel want a livestream for installing macOS 10.13 when it comes out. [00:18:45 CET] <TehEpikDuckeh> Too much money though :/ [00:18:48 CET] <alexpigment> why blackmagic specifically? [00:19:04 CET] <TehEpikDuckeh> I like their products. I know I can get cheaper stuff, but they have some nice stuff that "works". [00:19:07 CET] <alexpigment> hauppauge and elgato make fairly cheap consumer alternatives [00:19:12 CET] <alexpigment> fair [00:19:27 CET] <TehEpikDuckeh> I've heard of them, but they seem rather crappy and have a weird gamer appeal to them. [00:19:36 CET] <TehEpikDuckeh> Especially Elgato. [00:19:43 CET] <alexpigment> i've been very happy with Elgato over the past few years. they're the only ones who seem to support TV broadcast standards well and "just work" [00:19:56 CET] <furq> does "weird gamer appeal" mean they're covered in useless LEDs and angular plastic panels that look like optimus prime's bra [00:20:00 CET] <TehEpikDuckeh> Yeah, I've seen them whenever I was looking for some TV tuners. [00:20:08 CET] <TehEpikDuckeh> furq: 100%. [00:20:27 CET] <TehEpikDuckeh> Lol, no, but they have colors and cheap plastic on them w/ a USB 2 interface for 1080i. [00:20:35 CET] <furq> and they have a heatsink in the shape of a gun [00:20:41 CET] <TehEpikDuckeh> xD [00:20:41 CET] <alexpigment> haha [00:21:15 CET] <TehEpikDuckeh> If I was going to -waste- spend the money on streaming hardware, I'm going to make sure it's semi bullet-proof. [00:21:25 CET] <alexpigment> anyway, the HD PVR 2 original non-gamer model (model 1512 i think) is my workhorse. it can record 1080i30 with 5.1 audio over HDMI. it's great [00:21:39 CET] <alexpigment> but i have to use an HD PVR 60 for anything that requires 1080p60 [00:21:55 CET] <alexpigment> it's ok, but i prefer the former for its comparatively pro-level features [00:21:56 CET] <TehEpikDuckeh> I want to stream at 1080p60. 1080i is just cheap crap for 2017. [00:22:12 CET] <alexpigment> yeah, i just use it for recording TV and archiving to Blu-ray. so i hear you [00:22:13 CET] <TehEpikDuckeh> ... if it were new. [00:22:41 CET] <furq> don't all the livestreaming services have ridiculously low bandwidth limits that make 1080p60 worthless [00:22:46 CET] <ZeroWalker> http://sprunge.us/JSiT [00:22:46 CET] <TehEpikDuckeh> I'd like to have a 4k30 capture device, but EHHHHH, that money thing isn't cheap to invest into. [00:22:54 CET] <furq> at least for games, which is the only thing where you'd notice the difference [00:22:58 CET] <ZeroWalker> hints on the next step after getting the packet there;) [00:23:02 CET] <TehEpikDuckeh> Actually, YouTube isn't that bad. [00:23:24 CET] <llogan> a $3200 TS anal-yzer that won't let you use it in a VM... [00:23:27 CET] <alexpigment> furq: yeah, twitch is like 3500kbps or less. most people do 720p60 [00:24:16 CET] <ZeroWalker> i stream to youtube at 40mbps [00:25:57 CET] <alexpigment> zerowalker: and then they re-encode it at horrible joke-level quality ;) [00:26:09 CET] <ZeroWalker> indeed;P [00:26:25 CET] <ZeroWalker> but at least it has a non-horrible source, so that's something xd [00:26:32 CET] <alexpigment> i agree with that [00:27:41 CET] <ZeroWalker> i would like to have some way to keep the source like twitch, but with at least higher bitrate, then again i can't stream with x264 so my quality would basically be worse then the youtube re-encode anyway [00:28:07 CET] <alexpigment> yeah, doing twitch on x264 is pretty demanding [00:28:12 CET] <furq> use the tee muxer or stream via a local nginx-rtmp which records a copy [00:28:56 CET] <ZeroWalker> yeah, but sadly that's the only way to achieve decent quality on that bitrate;( [00:29:39 CET] <alexpigment> yep, i had to guide a friend through that process and was ultimately just like "ok, use nvenc, and accept that this is what it looks like" [00:29:46 CET] <furq> i bet a 3.5mbit nvenc 1080p60 encode of a fast fps looks just great [00:29:48 CET] <furq> also i am lying [00:29:52 CET] <alexpigment> haha [00:30:15 CET] <TehEpikDuckeh> alexpigment: What should I configure my FFmpeg build w/? [00:30:20 CET] <alexpigment> 1080p60 at 3.5 looks pretty bad on x264 too, for what it's worth [00:30:24 CET] <furq> last time i did a 720p60 encode of quakeworld with x264 veryslow it ended up at about 11mbit [00:30:29 CET] <alexpigment> since you can't even do 2-pass [00:30:39 CET] <furq> although quakeworld is probably some kind of pathological worst case for a modern video encoder [00:30:50 CET] <alexpigment> did you set a CRF? [00:31:02 CET] <furq> yeah i started at crf 20 and it was hitting 15mbit or so [00:31:06 CET] <furq> i had to step it down a lot [00:31:06 CET] <alexpigment> tehepikduckeh are you compiling on linux? [00:31:13 CET] <alexpigment> yeah, you probably are [00:31:14 CET] <alexpigment> :) [00:31:16 CET] <furq> this was ages ago though so i forget what i actually used [00:31:20 CET] <furq> it looks shit on youtube anyway [00:31:49 CET] <TehEpikDuckeh> alexpigment: Correct. [00:31:50 CET] <alexpigment> tehepikduckeh - used a build script on linux for windows, so admittedly, i'm not sure what you need to build with [00:32:01 CET] <alexpigment> but make sure all the nvidia stuff is enabled if you have a list of available options [00:32:10 CET] <TehEpikDuckeh> alexpigment: Do you still have that script? I might be able to copy the configuration it has. [00:32:12 CET] <thebombzen> how do you have 40 Mbps of internet access lol [00:32:17 CET] <alexpigment> (i'm very new to this, so i'd actually defer to the experts here) [00:32:33 CET] <furq> 40mbps up isn't that impressive any more [00:32:38 CET] <TehEpikDuckeh> thebombzen: You know what's funny, I have 180 down, but 10-15 up ~_~ [00:32:42 CET] <furq> i'm on cable and i could have 20 if i could be bothered to upgrade [00:32:57 CET] <alexpigment> thebombzen: living in austin, the minimum is 100mbps down for most services [00:33:03 CET] <furq> and the FTTC providers round here do 20 up if you're close enough to the cabinet [00:33:05 CET] <thebombzen> I'm referencing up [00:33:10 CET] <thebombzen> I have 150 down [00:33:19 CET] <TD-Linux> I'm 20/2, which is actually quite livable when de-bufferbloated [00:33:26 CET] <TehEpikDuckeh> I understand, but it's just crazy. Fiber-4-America. [00:33:28 CET] <alexpigment> oh yeah, up speed is lower than 40mbps on my end [00:33:29 CET] <thebombzen> "[18:24:16] <ZeroWalker> i stream to youtube at 40mbps" [00:33:29 CET] <furq> yeah i had 20/2 adsl2+ for years [00:33:29 CET] <alexpigment> nm [00:33:35 CET] <furq> it was all right [00:33:36 CET] <alexpigment> yeah, i'm an idiot, it's ok ;) [00:33:38 CET] <furq> i wouldn't go back to it though [00:33:46 CET] <TD-Linux> furq, I can choose between this and bandwidth capped comcast [00:33:53 CET] <furq> what's the bandwidth cap [00:34:00 CET] <furq> isn't it like 1TB a month or something [00:34:06 CET] <thebombzen> yea [00:34:08 CET] <alexpigment> tehepikduckeh: https://github.com/rdp/ffmpeg-windows-build-helpers <-- this is what i used [00:34:15 CET] <TehEpikDuckeh> Thanks! [00:34:19 CET] <thebombzen> I have comcast (competition is for losers) [00:34:22 CET] <furq> actually i guess 20mbps for a month is 6.5TB [00:34:24 CET] <TD-Linux> furq, they were doing 250GB at one point [00:34:28 CET] <thebombzen> so I have a bandwidth cap [00:34:39 CET] <furq> i have 150 down and i don't think i've ever exceeded 1TB down [00:34:41 CET] <thebombzen> I didn't know I had a bandwidth cap tho until I went to some website that wasn't https [00:34:49 CET] <furq> although my router doesn't track it reliably [00:34:57 CET] <thebombzen> and then comcast injected something into the html to tell me that I was close to my cap [00:35:02 CET] <alexpigment> ok guys, gotta head out. good luck duckeh [00:35:21 CET] <thebombzen> but I think I have 1 TB [00:35:26 CET] <TD-Linux> I'd have to check again, I guess it hasn't bothered me enough to reevaluate comcast yet [00:35:28 CET] <thebombzen> my roommate handles the internet bills so I'd have to ask him [00:35:38 CET] <TD-Linux> I think I could get 150/20 [00:35:39 CET] <thebombzen> comcast is a piece of shit [00:35:47 CET] <thebombzen> but it's also my only option [00:35:58 CET] <thebombzen> #natural monopoly [00:36:09 CET] <furq> apparently i have 250GB/150GB down/up in 60 days [00:36:16 CET] <furq> but i've definitely rebooted my router in the last 60 days, so that can't be right [00:36:32 CET] <furq> it's cool that this router can't even track uptime reliably [00:38:19 CET] <thebombzen> it's okay it's using av_gettime_relative [00:38:25 CET] <furq> ;_; [00:39:07 CET] <TD-Linux> >$150/mo nope [00:39:45 CET] <furq> i know someone who gets 1G fttp for £30/month [00:39:54 CET] <furq> although it's in a building where the rent is £2000/month so it probably evens out [00:42:53 CET] <TD-Linux> heh I've only done 40GB the last two weeks [00:43:48 CET] <furq> my isp used to throttle upload to 6 and then 4mbit during peak hours, but they seem to have stopped that now unless you're taking the piss [00:44:02 CET] <furq> since that happened i'm pretty happy with 10mbit up [00:48:29 CET] <thebombzen> I think I have 150 down 10 up [00:48:43 CET] <thebombzen> it might be 100/10 tho [00:48:56 CET] <thebombzen> I've never actually achieved 100 from any server so idk [00:51:27 CET] <thebombzen> that's odd. so apparently I can't get more than like 88 no matter how I try [00:51:30 CET] <thebombzen> and we're paying for 100 [00:51:32 CET] <thebombzen> :P [00:53:25 CET] <furq> is that cable [00:54:27 CET] <thebombzen> it's not cable tv [00:54:36 CET] <thebombzen> it's cable internet yea [00:54:51 CET] <furq> fun [00:54:56 CET] <furq> i routinely get 19MB/s down [01:48:19 CET] <TehEpikDuckeh> alexpigment: Just had time to test out FFmpeg and it still presents the same issue. [01:52:30 CET] <ZeroWalker> a bit lost:( http://sprunge.us/JDPS [02:00:20 CET] <rafasc> can ffmpeg output something like this: http://i.imgur.com/idCuKrY.gifv? [02:00:37 CET] <rafasc> from a list of frames? [02:01:34 CET] <iive> i think this is done by motion stabilization software [02:01:48 CET] <iive> i'm not sure if the one used by ffmpeg could do it... [02:02:24 CET] <rafasc> The motion stabilization I have figured it out. [02:02:47 CET] <rafasc> I have each frame as an image. [02:03:13 CET] <ZeroWalker> well, that's what a frame is;o [02:03:35 CET] <rafasc> i need something like ffmpeg -i frames%3d.tif video.mp4 [02:04:03 CET] <rafasc> but this only shows one frame at a time. I want the frames to persist. [02:06:13 CET] <furq> !filter vidstabtransform [02:06:13 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#vidstabtransform-1 [02:06:15 CET] <furq> maybe that [02:09:50 CET] <ZeroWalker> none that could help me mux and write my encoded frames;d? [15:33:52 CET] <peetah> hi, I came here some days ago about a suspicion of FFmpeg licence violation: I did my homework, and now I'm sure about my claims [15:35:51 CET] <peetah> The company visioforge.com is repackaging FFmpeg binaries compiled from GPLed code (not LGPL since they include libpostproc and the binaries contains the --enable-gpl string) without any licence information whatsoever [15:36:55 CET] <peetah> their last changelog claim for "Fixed FFMPEG source memory leak" (https://www.visioforge.com/video-capture-sdk.html) [15:40:21 CET] <peetah> I checked the bug tracker for previous report of such violation, and it seems you don't take any action, which I can understand given the time and efforts it could require. So I let this information here to be useful for anyone it may concern [15:46:36 CET] <peetah> to their credit, they seem to have "misunderstood" the FFmpeg licence (https://www.visioforge.com/support/717091-Decoding-in-Video-Edit-SDK-with-F…) [16:15:23 CET] <zevarito> hi all, I am looking forward to live convert HLS into RTSP with FFmpeg, is this possible ? [16:44:21 CET] <DHE> zevarito: it's possible, but ffmpeg isn't an RTSP server itself. you need to provide one and ffmpeg can feed it [16:55:57 CET] <zevarito> DHE: cool thanks! [17:28:58 CET] <paperManu> hi there, I have trouble using the h264_nvenc encoder with the libavcodec API. The x264 encoder works well, but the avcodec_send_frame keeps complaining with a AVERROR(EINVAL), which makes not much sense to me. [17:29:11 CET] <paperManu> has anyone experience with the h264_nvenc encoder? [17:37:08 CET] <alexpigment> paperManu: i've used h264_nvenc before [17:37:20 CET] <alexpigment> although i'm not familiar with the error you're getting [17:37:45 CET] <paperManu> by any chance, do you have code using it available somewhere? [17:37:47 CET] <alexpigment> out of curiosity, what nvidia card do you have, and have you updated to the newest drivers? [17:38:19 CET] <paperManu> I tested it only with 670, on Ubuntu 16.04, with the 375.39 drivers [17:38:38 CET] <alexpigment> no - my experience is under Windows 7 64-bit using an Zeranoe compiled build. i used nvidia 650, 750, 970, and 1060 [17:38:50 CET] <alexpigment> unfortunately, i haven't done any testing on linux [17:39:18 CET] <paperManu> ok [17:39:30 CET] <paperManu> do you remember if there was any specific context parameter to set? [17:41:01 CET] <alexpigment> i don't believe so. here's a sample test command i just did: [17:41:38 CET] <alexpigment> ffmpeg -i [input file] -c:v h264_nvenc -global_quality 20 -c:a aac outfile.mp4 [17:41:48 CET] <alexpigment> everything worked fine [17:42:48 CET] <alexpigment> sorry, i guess i can't really help with your specific error [17:43:32 CET] <paperManu> thanks anyway, I'll continue trying to figure this out =) [17:43:38 CET] <alexpigment> k [17:43:59 CET] <alexpigment> it may be worth trying a simple video file - perhaps another sample - to rule out an issue with decoding [17:44:15 CET] <alexpigment> then again, you said x264 worked fine, so that probably isn't the case [17:45:25 CET] <paperManu> yes, and the error is not really informative [17:45:34 CET] <paperManu> the command line works fine for me too [18:19:00 CET] <ZeroWalker> the time has come for ppl to help me [18:19:43 CET] <ZeroWalker> i can't do write header not write interleaved: http://sprunge.us/GbPi [18:57:16 CET] <ctmeece> I have an mp4 file, avc/aac encoded, 960x540. When I play this video with jwplayer, OI get the expected output, a 16x9 video file that plays fine. I am trying to segment this video for hls so I can stream it on the web with jwplayer. The segmenting is succesful and the resultant playlist runs in jwplayer, but the video is squished with black bars on top and bottom. I have added the command I ran to pastebin: [18:57:37 CET] <ctmeece> http://pastebin.com/eGW61xHW [18:58:18 CET] <ctmeece> the resultant segmented video appears to have a resolution of 960x260 [18:58:41 CET] <ctmeece> if I look at any individual .ts, though, it appears to have the correct resolution: [18:59:20 CET] <ctmeece> http://pastebin.com/7A5aP7pq [19:02:18 CET] <ctmeece> I probably have more options to ffmpeg than I need, but I keep adding some to try to troubleshoot this. I have tried many combinations of options but they all seem to produce this squashed video. [19:04:11 CET] <ctmeece> I have the same source video file split with a program called One Click M3U8 that produces the output I want, and here is the mediainfo on one of the .ts files it produced: [19:04:56 CET] <ctmeece> http://pastebin.com/VqD0jTAJ [19:05:17 CET] <ctmeece> and finally, here is the mediainfo data on my source file: [19:05:48 CET] <ctmeece> http://pastebin.com/ny37FRRW [19:36:41 CET] <ctmeece> i transfered 2 of the .ts files, one that works (generated from One Click M3U8) and one from my ffmpeg command back to my local mac, and tried playing them both in VLC [19:37:17 CET] <ctmeece> they both play fine, both have the 960x540 resolution, and both appear o have the same media informaiton in the VLC inspector [19:37:28 CET] <JEEB> uhh [19:37:32 CET] <ctmeece> so, maybe it has somethign to do with the playlist file? [19:37:42 CET] <JEEB> what about you not using the segment muxer [19:37:54 CET] <JEEB> and instead just be a nice guy and set the output file name to something.m3u8 [19:38:15 CET] <JEEB> although I guess the segment muxer can also do hls due to the segment_list_type parameter [19:38:46 CET] <JEEB> also... [19:38:48 CET] <ctmeece> i havent tried just renaming the mp4 but I will try that. [19:38:55 CET] <JEEB> http://pastebin.com/eGW61xHW [19:39:10 CET] <JEEB> under output you have major brand and other random isobmff specific shit [19:39:50 CET] <JEEB> and then it says "copy" at the end?! [19:39:50 CET] <DHE> there's a dedicated `hls` format as well for your consideration. [19:40:13 CET] <JEEB> yeah, that's what I meant with "just set your output file name to 'something.m3u8'" [19:40:24 CET] <JEEB> since that should pick the hls muxer by default [19:40:33 CET] <ctmeece> will that cause jwplayer to do a progressive download of the whole file? [19:40:43 CET] <JEEB> what the flying fuck [19:40:48 CET] <JEEB> are you trolling or just that much out there [19:40:48 CET] <DHE> ow [19:40:49 CET] <ctmeece> oj, you mean during the conversion [19:41:09 CET] <JEEB> also you're using avconv [19:41:15 CET] <JEEB> an ancient version at that [19:41:30 CET] <ctmeece> right, its the most recent version in the ubuntu standard repos [19:41:30 CET] <DHE> speaking of which, "-codec copy -vf 960:-1 -bsf h264_mp4toannexb" is contradictory [19:41:34 CET] <JEEB> I don't care if you utilize FFmpeg or Libav, but it's ancient [19:42:02 CET] <JEEB> ctmeece: it's the "the last release available as of winter 2013-2014" [19:42:09 CET] <ctmeece> i did initially just try a simple name the output file with m3u8 but as that didnt work, I have been adding more and more options [19:42:21 CET] <JEEB> sounds like you just want to stop at that point [19:42:27 CET] <JEEB> go grab a static build of FFmpeg [19:42:34 CET] <JEEB> one of the guys here builds them if I recall correctly [19:42:35 CET] <DHE> but seriously, upgrade to something made in the last 12 months [19:42:53 CET] <JEEB> and then just do `ffmpeg -i input -c copy out.m3u8` [19:43:01 CET] <JEEB> that should "just do what you need" [19:43:07 CET] <JEEB> if not, then add the bsf [19:43:22 CET] <JEEB> but you shouldn't need anything else for segmenting [19:43:32 CET] <ctmeece> i think at the minimu, with my ancient version, it required bsf and map at minimum [19:43:51 CET] <JEEB> yeah, but a lot of the BSF stuff is now automagic [19:43:57 CET] <JEEB> that's a recent improvement [19:44:02 CET] <JEEB> at least for AVC and HEVC [19:44:34 CET] <JEEB> (someone link this poor bastard the static lunix builds) [19:45:16 CET] <JEEB> with those you can just call the ffmpeg with its path unless you add it to your PATH if you know what that is [19:45:20 CET] <DHE> https://johnvansickle.com/ffmpeg/ Is this the one you wanted? [19:45:25 CET] <JEEB> probably that one [19:45:40 CET] <JEEB> you extract that and then /path/to/ffmpeg OPTIONS [19:45:46 CET] <JEEB> that will use the static build [19:45:56 CET] <DHE> or uninstall your existing ffmpeg and install this one in its place [19:46:00 CET] <DHE> (uninstall very important here) [19:47:28 CET] <JEEB> "install", if it's not a deb package don't use that word because the lusers won't know how to do it :P [19:47:55 CET] <JEEB> better to just tell them to extract and then use the full path so they don't have to know about PATH either [19:48:03 CET] Action: JEEB shrugs [19:48:22 CET] <JEEB> (note: you should decide this by the seeming knowledge level of the user) [19:48:32 CET] <JEEB> in this case, though, KISS seems to be a good thing :P [19:48:47 CET] <ctmeece> jesus, this is why I never come to IRC& [19:49:19 CET] <JEEB> well, try out that static binary [19:49:45 CET] <JEEB> and don't worry, by your pastebin that just didn't make any sense I just grasped that you might not have too much knowledge about *nix in general. which might have been incorrect. [19:50:54 CET] <JEEB> (I will still note that "install" is still a misnomer when we're not talking of a distro package) [19:51:14 CET] <JEEB> ctmeece: did it work better with the simple command line? [19:51:24 CET] <ctmeece> no [19:51:32 CET] <JEEB> post command line and terminal output, please [19:51:38 CET] <JEEB> on a pastebin [19:51:40 CET] <ctmeece> oh, you mean with the new binaries? [19:51:45 CET] <JEEB> yes [19:55:15 CET] <ctmeece> that will have to wait a bit. You see, there are reasons that lots of admins like to stick with the standard distro versions of packages that have nothing to do with being noobs, but have to do with corporate governance, change control, ongoing maintenance, integration with local package management etc etc. My life would be much easier without having to install static binaries. But Ive thrown every option at it at this point, so now I have to spin up [19:55:16 CET] <ctmeece> new dev box to test this. Ill let you know how it goes. [19:55:53 CET] <DHE> oh believe me we know. but ffmpeg is one of those projects where running the most up-to-date version of software really makes a huge difference [19:56:26 CET] <ctmeece> ugh, yes, i recall it being a headache for some other reason about 5 years ago. I was hoping repo maintainers had caught up [19:56:40 CET] <JEEB> even if they had, your distro is still three years old [19:56:46 CET] <ctmeece> or features/bugs had stabilized [19:57:02 CET] <JEEB> nah, OSS multimedia is pretty much alway in motion. usually towards better :) [19:57:15 CET] <DHE> repo maintainers have different priorities. for long term support there's an expectation that interfaces, parameters and any already-written user scripts won't break as a result of an upgrade. [19:58:02 CET] <JEEB> ctmeece: if it's better for you to build yourself just install build-essential, git and yasm. you get all the basic features with a simple `./configure && make -jX` [19:58:06 CET] <JEEB> if you don't like static binaries [19:58:26 CET] <JEEB> since you only need re-packaging and not encoding with, say, libx264 [19:59:00 CET] <DHE> JEEB: considering he's trying to rescale the video and output to HLS, I suspect he does in fact need libx264 [19:59:12 CET] <JEEB> I think that was him just adding all sorts of parameters [19:59:26 CET] <JEEB> since he got the wrong size after remuxing [19:59:29 CET] <ctmeece> yeah, i dont want to be building packages [19:59:32 CET] <JEEB> for some weird reason [20:00:08 CET] <ctmeece> well, ftr, i think avtool got the wrong size [20:00:30 CET] <JEEB> ctmeece: nah - not packaging in that sense. taking streams from one container and putting them into another. generally called "remuxing" [20:00:46 CET] <ctmeece> i was referring to building from source [20:00:49 CET] <JEEB> right [20:00:57 CET] <JEEB> I wouldn't make a package in that case anyways [20:01:02 CET] <JEEB> more issues [20:01:05 CET] <JEEB> just keep it in your home dir [20:01:15 CET] <JEEB> and call it specifically when you need it [20:01:23 CET] <ctmeece> its not that simple [20:01:33 CET] <ctmeece> this is not a hobby project [20:01:41 CET] <JEEB> ok [20:01:53 CET] <ctmeece> i have to administer many boxes across many environments across many locations [20:02:07 CET] <ctmeece> so anything i build I eventually have to support [20:02:11 CET] <DHE> neither is what I do. and I'll be honest, I still run from the Git version of ffmpeg and build my own versions. (My name is even in a small number of git commits, these are related events) [20:03:18 CET] <JEEB> yeah, at work I build as well. [20:03:21 CET] <ctmeece> im just saying that put the bins in your home dir only solve a small part of the problem. [20:03:24 CET] <JEEB> we have specific hashes [20:03:31 CET] <JEEB> that are tested [20:03:47 CET] <DHE> make your own packages, host an internal repo and distribute it from there? [20:04:02 CET] <JEEB> also I recommend you don't try to package it in the same way as the system libav [20:04:05 CET] <ctmeece> i do do that for some ssl packages, but ita major pain, tbh [20:04:22 CET] <DHE> well, I'm sorry but you're currently stuck between a rock and a hard place [20:04:41 CET] <JEEB> make it a self-contained package containing just ffmpeg and maybe ffprobe if you want that [20:04:45 CET] <ctmeece> not really. I will get static binaries and distribute those. [20:05:06 CET] <CalimeroTeknik> how can I specify jpeg as the output (to a pipe)? [20:05:13 CET] <JEEB> -f mjpeg ? [20:05:22 CET] <JEEB> or just jpeg [20:05:24 CET] <ctmeece> im just saying that the hassle of that is unfortunate, but that is neither here nor there. [20:05:36 CET] <CalimeroTeknik> Requested output format 'jpeg' is not a suitable output format [20:05:43 CET] <JEEB> ctmeece: yes it's unfortunate that you can't use what comes from the repos [20:06:02 CET] <CalimeroTeknik> the input is a webp image [20:06:02 CET] <relaxed> CalimeroTeknik: mjpeg [20:06:20 CET] <CalimeroTeknik> Output #0, mjpeg, to 'pipe:': Output file #0 does not contain any stream [20:07:12 CET] <CalimeroTeknik> here goes http://sprunge.us/gUJh [20:07:29 CET] <JEEB> ctmeece: btw one quick way of checking which version of FFmpeg you want is to check if the current HEAD is green on FATE for the architectures/operating systems you require [20:07:42 CET] <CalimeroTeknik> oh, the output. http://sprunge.us/NLJF [20:07:51 CET] <JEEB> not a perfect test, but at least every time you think of updating FFmpeg it's a good way to see if something is completely bonkers [20:07:52 CET] <ctmeece> ok, thanks [20:07:58 CET] <ctmeece> right [20:07:58 CET] <JEEB> FATE being http://fatebeta.ffmpeg.org/ [20:08:22 CET] <JEEB> regression tests being run on various architectures and operating systems [20:13:16 CET] <CalimeroTeknik> well, it works fine as long as I don't want to use pipes as the input of ffmpeg I suppose [20:28:34 CET] <llogan> you could just use ffmpeg -i https://... [21:10:57 CET] <oal> I'm looking for a way to cut a video file in Linux without rerendering the whole thing. I found the -ss and -t flags to set start and duration, but can I specify multiple start/stops? Say I want to have a result file with 10s-20s and 40s-60s but not what's before the 10s mark and between 20 and 40? [21:12:44 CET] <thebombzen> pal: if you don't want to transcode, you'll have to cut on keyframes. that being said, check out the segment muxer [21:14:09 CET] <llogan> if you need to re-encode, you can use the trim and concat filters. if you can cut on keyframes, adn therefore possibly avoid re-encoding, you can use the concat demuxer using the inpoint and outpoint options. [21:14:51 CET] <thebombzen> if you're okay with transcoding, then you can do something like this: -filter_complex '[0:v]split[a][b];[a]trim=start=10:end-20,setpts=PTS-STARTPTS[c];[b]trim=start=40:end=60,setpts=PTS-STARTPTS[d];[c][d]concat=n=2:v=1:a=0[v]' -map '[v]' [21:15:22 CET] <thebombzen> essentially, you split it, trim both clips, and concatenate them [21:21:17 CET] <jcay> what does re-encode mean and with which options does it start? [21:22:04 CET] <oal> Thanks, I'll experiment a bit. I just don't want to wait 20 minutes for Pitivi to render my 2 minute clip. :) [21:22:42 CET] <thebombzen> jcay: well the video stream is already compressed using lossy encoding. if you were to decode it and then encode it again using lossy encoding, that's re-encoding [21:22:57 CET] <thebombzen> also known as "transcoding" [21:23:52 CET] <jcay> thebombzen: I see, how can I avoid it? [21:24:30 CET] <thebombzen> -c copy [21:25:07 CET] <jcay> I see, thanks [21:29:30 CET] <thebombzen> pal: I generally find that to do what you're doing is easier with separate commandlines [21:30:00 CET] <thebombzen> like: ffmpeg -ss 10 -i input -t 10 -c:v ffv1 -c:a flac start.nut [21:30:14 CET] <thebombzen> ffmpeg -ss 40 -i input -t 20 -c:v ffv1 -c:a flac end.nut [21:30:43 CET] <thebombzen> ffmpeg -i start.nut -i end.nut -lavfi concat=n=2:v=1:a=1 <output options> output [21:33:50 CET] <ChocolateArmpits> Is there any format that can wrap both uncompressed video and audio stream and send it over udp ? I fear sending rawvideo and s16le two ways may end up in losing synchronization [21:37:28 CET] <kepstin> ChocolateArmpits: rtp? note that setup is a bit tricky, you might need to pass around sdp so both ends know all the codec config. [21:37:45 CET] <kepstin> ChocolateArmpits: also mpeg-ts [21:37:54 CET] <ChocolateArmpits> kepstin, mpegts can't wrap uncompressed [21:37:56 CET] <kepstin> but codec choice is a bit more limited there [21:38:02 CET] <ChocolateArmpits> I mean it does wrap it but I can't read it afterwards [21:38:27 CET] <ChocolateArmpits> so it's more likely the wrapping is botched because of unsupported encoding [21:39:10 CET] <ChocolateArmpits> also I think rtp only allows sending 1 stream [21:39:49 CET] <kepstin> hmm, i guess ffmpeg doesn't support rtp-mux, which allows multiple on same port? But rtp does support syncing multiple streams on different ports. [21:40:30 CET] <kepstin> no idea if you can do that with the 'ffmpeg' command line tool, which is of course not intended for use with realtime streaming applications :) [21:41:26 CET] <kepstin> (the fact that it mostly works most of the time is testament to how fast modern computers are) [21:43:19 CET] <llogan> i always reserved the word "transcode" to refer to re-encoding while re-using info from the input such as motion vectors, etc. whle re-encode is decode input into rawvideo, then encoding that with no additional info from the input. but in reality nobody differentiates between the two words. [21:47:32 CET] <feliwir> hey, i am trying to compile ffmpeg with new MSVC 2017 [21:48:31 CET] <feliwir> but i am failing during configure stage (C compiler test failed) [21:48:43 CET] <feliwir> cl.exe is in path [21:50:12 CET] <JEEB> see config.log [21:50:15 CET] <JEEB> and pastebin it [21:50:27 CET] <JEEB> I think nevcairiel is already running VS2017 FATE [21:50:31 CET] <JEEB> so I would say it should work already [21:51:55 CET] <JEEB> hmm, not yet registered on the global FATE system it seems [21:56:41 CET] <feliwir> JEEB, https://gist.github.com/feliwir/b649d6f8e0067aa23ab562c45a940655 [21:57:11 CET] <feliwir> fails to open LIBCMT [21:57:52 CET] <ZeroWalker> FATE? [22:03:52 CET] <JEEB> ZeroWalker: http://fatebeta.ffmpeg.org/ [22:03:57 CET] <JEEB> automated regression test suite [22:04:10 CET] <JEEB> feliwir: double-checked with nev [22:04:11 CET] <JEEB> 22:52 <+JEEB> nevcairiel: did VS2017 work for FFmpeg? [22:04:11 CET] <JEEB> 22:58 <@nevcairiel> yes [22:04:26 CET] <feliwir> so what did i do wrong? [22:04:33 CET] <feliwir> i followed the ffmpeg guide [22:04:48 CET] <feliwir> but the paths did change for msvc 2017 [22:05:17 CET] <JEEB> I have NFI :) will be installing MSVC 2017 this week myself [22:06:17 CET] <feliwir> okay :) [22:06:54 CET] <feliwir> i am currently writing a vp6 decoder in C# it's a pain :D Does someone here maybe still have the original libvp62 sourcecode? [22:07:04 CET] <ZeroWalker> ah [22:07:09 CET] <JEEB> just use libavcodec's :) [22:07:12 CET] <feliwir> that was on Sourceforge during 2006 [22:07:22 CET] <JEEB> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/207721.html [22:07:26 CET] <JEEB> try applying this? [22:07:31 CET] <JEEB> not sure if relevant [22:08:03 CET] <feliwir> well, problem with libav is that it uses many functions split across many files [22:08:37 CET] <feliwir> JEEB, hm it doesn't seem relevant for a linking error during configure stage [22:08:55 CET] <JEEB> ye [22:10:26 CET] <feliwir> Another question: Is Aurelien Jacobs still active on ffmpeg? [22:11:25 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=author&s=Aurelien [22:11:30 CET] <JEEB> last commit in 2013 [22:11:38 CET] <Kirito> Is there a way to have ffmpeg work with filenames that don't have padded zero's? i.e. frame-1.tiff - frame-999.tiff [22:11:48 CET] <Kirito> instead of frame-001.tiff - frame-999.tiff [22:12:58 CET] <RossW> the way I do it is to pipe the files to ffmpeg (because I'm often wanting to use only a subset of the images, or skip every nth, etc) [22:15:01 CET] <Kirito> Nevermind, I bloody love Directory Opus [22:15:22 CET] <Kirito> https://a.uguu.se/5XIkx1I5VrQ4_dopus_2017-03-07_16-15-22.png [22:16:59 CET] <Kirito> Renamed all the files in %04d format while preserving the natural sorting order, hah [22:17:28 CET] <faLUCE> (I know that this could be off-topic, but I don't know where to ask) hello. Is there a way to demux a MPEGTS http stream with wireshark? I can do that with a mpegts file, but for a living http stream all the packets are generically marked as "TCP" [22:17:44 CET] <feliwir> by any chance someone in here is an expert for vpX codecs? :D [22:18:55 CET] <feliwir> and also i am confused a bit. My video container (electronic arts) does specify the video size, but the vp6 codec does specify a size again. They are equal, but which one would be the relevant one? [22:21:13 CET] <kepstin> feliwir: I'd expect them both to be the same normally. In some cases, containers may specify a display resolution in order to request that players change the display aspect ratio by scaling. [22:21:53 CET] <feliwir> kepstin, the vp6 codec does specify a display resolution aswell :D (presentation dimensions) [22:22:25 CET] <kepstin> feliwir: great! I guess you'll just have to call up EA and ask them which one to use :) [22:22:55 CET] <feliwir> kepstin, hehe if EA see's what i am doing i'll probably get sued :D [22:23:04 CET] <kepstin> (I assume these are game videos, so it probably depends on the game code which value is used) [22:23:47 CET] <feliwir> kepstin, the BFME series was the main one that used the VP6 Codec i think. And thats what i am doing it for [22:29:57 CET] <faLUCE> I just want to compute the network delay for received mpegts packets. Is there a tool that helps me in doing that? [22:42:38 CET] <BtbN> ping [22:45:12 CET] <kepstin> faLUCE: the only thing I can really think of is synchronizing the computer clocks really closely, then logging the times that you see particular packets on both ends. [22:45:19 CET] <kepstin> since it's not a 2-way thing [22:45:56 CET] <kepstin> unless you're using tcp i guess, the tcp stack might have an rtt estimate you could pull out [22:47:20 CET] <faLUCE> kepstin: I can sync the computer clocks, but then... how can I log the times for particular packets? I did not implement a demuxer, so I can't filter anything [22:47:38 CET] <kepstin> faLUCE: you'd have to have a custom app to do that [22:47:45 CET] <kepstin> be tricky :) [22:47:57 CET] <faLUCE> kepstin: in fact I wonder which app could I use [22:48:04 CET] <faLUCE> I don't want to implement it [22:48:47 CET] <kepstin> well, if you're using udp, I'd just take BtbN's suggestion and use ping. It should be pretty close. (returns rtt of course, not 1-way delay) [22:49:32 CET] <faLUCE> kepstin: but ping will give me a generic network delay [22:50:00 CET] <kepstin> yes, which should be equivalent to the delay any particular udp packet has [22:50:10 CET] <faLUCE> I'm using TCP [22:50:34 CET] <kepstin> ok, then on linux? look at the TCP rtt estimate with the `ss -i` command [22:50:45 CET] <faLUCE> but the stream is over HTTP [22:51:00 CET] <kepstin> you're asking about network delay... [22:51:27 CET] <kepstin> any delay other than what's on the tcp connection is application delay on either end (in software), not network delay [22:51:28 CET] <faLUCE> kepstin: you are right. The question changes with: HTTP delay... [22:52:10 CET] <kepstin> so for that you'd want to look at kernel buffers on both end, and userspace application buffers. [22:54:14 CET] <faLUCE> kepstin: the problem is that I can control the mpegts http stream parameters (= all the delays) on the streaming side. But when I receive the stream with a player, all the delays go in a black box and I don't have any control over them [22:54:43 CET] <pclbr> Someone working with ISDB-T ? I? trying to trancoderthe AAC Audio into AC3, but when I do it in a output (MPEGTS UDP mux) start to show artfacts and syncronization are wrong ( Timestamps are not set correctly) I thinks it is a demuxer problem in AAC. but even when I just copy the mux happens in the same way, output get wrong Timestamps. [22:54:46 CET] <faLUCE> I coded the streamer, so I can control that parameters. But I did not code the receiver [22:54:52 CET] <kepstin> faLUCE: most players when streaming off a network connection use fairly large buffers in the player, to smooth over network glitches [22:55:18 CET] <kepstin> faLUCE: nothing you can do about that without tweaking the player side, really. [22:56:02 CET] <faLUCE> kepstin: in fact I wonder if it exists a http demuxer which shows when it receives a ts packet and dump its timestamp [22:56:22 CET] <faLUCE> kepstin: I found some mpegts demuxer, but they don't work over http [22:56:56 CET] <faLUCE> kepstin: I can pipe the output of a http receiver to these demuxers, but it's not a good solution [22:57:51 CET] <kepstin> if you're dealing with players that you don't control over a network connection, you're going to have buffers you don't control. I'm not sure what you're really trying to accomplish. [22:59:14 CET] <faLUCE> <kepstin> if you're dealing with players that you don't control over a network connection, you're going to have buffers you don't control. <---- there should be a good http mpegts player... or at least a good http mpegts demuxer [23:00:13 CET] <kepstin> I'm sure that with some configuration, you could probably get ffmpeg's mpegts demuxer hooked up to an http stream with pretty low latency, fwiw. [23:00:38 CET] <kepstin> but players purposely add buffering to smooth out variations in network speed. it's a feature. [23:01:45 CET] <faLUCE> kepstin: I use ffplay -probesize 500000 http://mystrem. I can have a minimum delay of 0.4 seconds on localhost. This is not enough, because the delay is big and I can't control any param [23:02:41 CET] <faLUCE> but before writing my own demuxer or player, I wonder if is there something better for http mpegts [23:03:49 CET] <faLUCE> kepstin: in addition, I don't understand why these players add buffering out of control, instead of providing the user the choice of dropping frames [23:04:37 CET] <kepstin> dropping frames wouldn't help unless the computer's to slow to decode the video realtime - the buffers are there to compensate for the network not providing frames fast enough [23:05:07 CET] <kepstin> have you tried forcing the input demuxer on ffplay, so it doesn't have to probe? the probing might be adding a fair bit of delay. [23:05:09 CET] <faLUCE> kepstin: I see, but these buffers are completely out of control [23:05:47 CET] <faLUCE> how could I force it so it doesn't have to probe? [23:06:04 CET] <kepstin> use the '-f mpegts' input option [23:06:15 CET] <kepstin> hmm, actually, it still needs to probe that, to find the codecs in use [23:07:18 CET] <kepstin> might still help a bit tho, but probably not that much [23:07:37 CET] <kepstin> to be honest, 0.4s for an http stream is already exceptionally good. [23:07:44 CET] <faLUCE> kepstin: tried, it doesn't help [23:08:20 CET] <faLUCE> kepstin: I know it's good, but skype has a lower delay [23:08:34 CET] <kepstin> skype doesn't use mpegts over http, obviously :) [23:08:52 CET] <kepstin> I assume they use some sort of encrypted rtp, optionally tunneled through tcp only if they can't use udp [23:09:35 CET] <faLUCE> kepstin: I know that I should use rtp, but there's no reason for which http-mpegts can't have a lower delay than 0.4 [23:10:16 CET] <kepstin> faLUCE: if you write custom applications and use it on a high performance network under your control, it's probably possible. [23:10:28 CET] <kepstin> with normal players and over the internet? hah. [23:10:52 CET] <faLUCE> kepstin: I know that too. In fact I could write my application with libcurl and a demuxer (with libav) [23:11:09 CET] <faLUCE> but it appears strange to me that common players don't do that [23:12:17 CET] <kepstin> common players assume that http streams are probably over internet, and are vod, not realtime, so they apply buffering appropriate to that use case. they're doing the right thing by default for most users. [23:12:55 CET] <faLUCE> kepstin: but http with mpegts is even more easy to manage than rtp [23:13:13 CET] <faLUCE> so, I wonder why there are not real time http-mpegts players [23:13:45 CET] <kepstin> faLUCE: because nobody uses mpegts in http for live streaming, because web browsers can't play it at all. [23:13:58 CET] <BtbN> Technically, Twitch does [23:14:22 CET] <faLUCE> kepstin: http-mpegts is much easier to be implemented than rtp [23:14:44 CET] <kepstin> huh, I haven't actually looked at twitch's html5 player. I assume they're rebuilding it into a dash stream to feed into the browser? [23:14:59 CET] <BtbN> They basically implemented their own hls.js [23:15:10 CET] <faLUCE> kepstin: I'm avoiding hls [23:15:12 CET] <kepstin> (and the delay on that would still be in the low seconds, I bet) [23:15:34 CET] <BtbN> HLS has tons of delay anyway, because 3 segments being required [23:15:42 CET] <kepstin> is twitch using segmented files, or a single live stream? [23:15:49 CET] <kepstin> we're talking about a single stream here. [23:15:52 CET] <feliwir> can someone tell me where those values come from: https://github.com/FFmpeg/FFmpeg/blob/415f907ce8dcca87c9e7cfdc954b92df399d3… ? [23:15:53 CET] <faLUCE> I implemented my http-mpegts streamer with v4l2+alsa+libav... but I don't have time to implement the receiver [23:16:11 CET] <feliwir> those tables aren't mentioned anywhere in the vp6 specification: https://multimedia.cx/mirror/vp6_format.pdf [23:16:21 CET] <BtbN> Twitch is using HLS [23:16:40 CET] <kepstin> right, that's kind of boring then. :/ [23:18:08 CET] <kepstin> can't do low delay with HLS, and nothing supports doing low delay mpegts stream in HTTP (chunked encoding, i guess?) [23:22:44 CET] <faLUCE> kepstin: you think that mpegts-http has necessarily some delay because of the container and the protocol. But it's not true [23:23:52 CET] <faLUCE> I think that there's a "fashion" followed by all the players: they think that rtp is the only good protocol for real-time streaming [23:24:15 CET] <faLUCE> but this is nonsense [23:24:30 CET] <kepstin> faLUCE: there's no inherent delay in http+mpegts, no - i didn't say that [23:25:00 CET] <faLUCE> kepstin: but you said [23:08] <kepstin> skype doesn't use mpegts over http, obviously :) [23:25:05 CET] <kepstin> I'm just saying that players in general assume that stuff over http isn't realtime, but is rather vod, so they buffer appropriately. [23:25:26 CET] <kepstin> well, it certainly wouldn't be anyone's first choice [23:25:27 CET] <faLUCE> kepstin: but this assumption is false, IMHO [23:25:47 CET] <kepstin> udp is better in general for live media, and if you're using udp anyways, you'd probably go for rtp [23:26:03 CET] <faLUCE> I don't agree... I used udp and rtp for years [23:26:19 CET] <kepstin> faLUCE: the assumption that content over http is vod (or segmented) is far more often true than false. [23:26:59 CET] <kepstin> and in use cases that have seen media streamed over http or similar (think shoutcast), low latency hasn't generally mattered. [23:28:00 CET] <faLUCE> kepstin: that was true some years ago, with low bandwidth [23:28:15 CET] <faLUCE> today, the http overhead is meaningless [23:28:32 CET] <kepstin> (I mostly deal with flash stuff at work, which means rtmp - another tcp protocol. We have to have *server side* frame dropping in connections to compensate for people with slow/overloaded downlings) [23:28:36 CET] <faLUCE> but people are still convinced that rtp is better in a dogmatic way [23:29:40 CET] <kepstin> i'd really rather use udp so frames just get thrown away in the network, instead of backing up tcp connections :/ [23:29:59 CET] <faLUCE> udp is bad with firewalls [23:30:03 CET] <kepstin> although then you have to have your own bitrate adaptation code, so still a pain... [23:31:58 CET] <kepstin> for a while, we didn't have the server side frame dropping, and instead buffered frames forever... until we started getting OOM issues when sending video to slow consumers ;) best not to do that... [23:35:47 CET] <faLUCE> kepstin: anyway, changing the probesize now I have a delay of 0.3s [23:35:51 CET] <faLUCE> :-) [23:36:20 CET] <kepstin> so that's a delay of around ~10 frames. [23:36:34 CET] <kepstin> not bad. [23:36:42 CET] <faLUCE> kepstin: the x264 delay is about 0.2s [23:37:08 CET] <faLUCE> I used av_write_frame instead of av_interleaved_write_frame [23:39:03 CET] <faLUCE> adding -sync ext improves [23:39:09 CET] <kepstin> what's the final bitrate of the mpegts look like? [23:39:25 CET] <kepstin> i'm wondering if you might hit issues with the tcp slow start behaviour :/ [23:39:33 CET] <kepstin> although I guess that might not show up on localhost [23:41:12 CET] <kepstin> but if you're trying to send e.g. 10mbit or higher, the tcp connection over an actual network interface won't be able to send the full rate immediately due to congestion control [23:41:34 CET] <kepstin> without tuning of course (which you don't want to do if you're in a public network) [23:41:37 CET] <faLUCE> kepstin: I'm streaming at 10000kb/s [23:42:33 CET] <kepstin> although it usually should get up to speed reasonably quick, but it might not be fast enough for this sort of low-latency work [23:43:12 CET] <ChocolateArmpits> Is reducing gop length good for latency reduction ? [23:44:02 CET] <kepstin> ChocolateArmpits: it can reduce time until a picture is shown if people are tuning into the middle of a stream, but it doesn't have a direct impact on latency. [23:48:19 CET] <ChocolateArmpits> oh ok [23:48:45 CET] <kepstin> (some indirect effects - having longer gop in vbr video means more variation in bitrate, which can cause issues with tcp rate control, which means you need more buffering in the player, which increases latency) [23:50:14 CET] <kepstin> of course "time until a picture is shown" is still a type of latency, but it's different from end-to-end latency which is what we're talking about here [23:50:42 CET] <kepstin> e.g. tv channels don't care if you're seeing the picture a few seconds delay, but they do care if you have to wait 10s before your tv shows something after switching channels [23:51:02 CET] <alexpigment> i'm not sure how everyone else works, but i started using GOP = framerate a while back and have been very happy ever since [23:51:30 CET] <alexpigment> seeking just always feels clunky with the default GOP length (250) [23:51:43 CET] <kepstin> gop=framerate means 1s between keyframes, which means pretty quick recovery from lost packets, etc., but far less efficient video encoding. [23:52:05 CET] <alexpigment> yeah, it's not as efficient, obviously. but it feels less janky to me for my own personal encodes [23:52:11 CET] <alexpigment> anyway, sorry for the tangent ;) [23:52:26 CET] <kepstin> short gop is great for intermediate files, particularly if you need to frame step backwards, yeah :) [23:53:04 CET] <alexpigment> yeah, short GOP is good for intermediate, although intra is ideal [23:54:30 CET] Action: kepstin is kind of disappointed that x264's intra refresh mode isn't used more in video streaming. [23:55:27 CET] <alexpigment> yeah i hear you on that (although i was specifically talking about intra-frame compression only, where the GOP is effectively 1 [23:55:51 CET] <kepstin> yeah, unrelated to that discussion :) intra-refresh spreads out bits so that frames are consistent sizes rather than big keyframe + little predicted frames, and gives cool-looking recovery from packet loss. [23:56:02 CET] <kepstin> makes seeking a pain tho :) [23:56:17 CET] <alexpigment> yeah, i think you need to decode certain number of frames still, right? [23:56:48 CET] <alexpigment> in other words, you still have to decode x number of frames before you get a full i-frame? [23:56:49 CET] <kepstin> yeah, you need to decode N frames after you seek to get a whole frame, where N is the number of columns x264 is using [23:57:10 CET] <kepstin> or you can just start watching, and see the video fill in column-by-column :) [23:57:11 CET] <alexpigment> gotcha. that's what i remember when reading up on it a while back [23:57:22 CET] <alexpigment> progressive jpeg comes to mind ;) [23:58:35 CET] <kepstin> the main thing is that it fixes the issue you often see in bitrate-limited (vbv) streams where the keyframes cause noticable drops in quality, and then quality slowly improves until the next keyframe drops. [23:59:24 CET] <alexpigment> yeah, i used a few techniques to get around that at work, although not completely starving the bitrate was also important [23:59:25 CET] <alexpigment> ;) [23:59:56 CET] Action: kepstin last remembers seeing that on some big cisco conferencing system, and he was suitably unimpressed. [00:00:00 CET] --- Wed Mar 8 2017

1 0

ffmpeg-devel.log.20170306
by burek 07 Mar '17

07 Mar '17

[00:06:12 CET] <unholy_me> @durandal_1707 I have written a prototype, how do I test it now? [00:48:50 CET] <philipl> BtbN: are you in a position to test mpeg2 transcode? I'm see a weird thing here where it appears to get wedged in the hardware. [00:49:02 CET] <philipl> Video Engine Utilization goes to 100%. Can't kill ffmpeg binary. [00:49:13 CET] <philipl> This worked before. [01:48:52 CET] <philipl> BtbN: blocked on a futex inside cuEventSynchronize inside cuvidDecodePicture [01:54:06 CET] <philipl> managed to kill the process but leaves the GPU at 100% VEU. Need to reboot [02:37:22 CET] <philipl> Don't get it. Seems to depend on the set of parameters passed or something. I wonder if there's some weird cuda context thing going wrong. [02:37:50 CET] <philipl> Also can't seem to encode with bframes with the current driver version. It's returning an error from EncodePicture. [02:37:58 CET] <philipl> Interested as to your experience. [02:38:28 CET] <philipl> Ok. So bframe error goes away if I don't use hwaccel. [02:38:37 CET] <philipl> So I guess this is somehow related to the filter changes. [02:38:58 CET] <philipl> wm4: Seems like there's more cuvid/nvenc black magic hiding here. [02:43:36 CET] <philipl> In another case I get a "No free surfaces" error if I use hwaccel with bframes and no problem without hwaccel [10:54:55 CET] <cone-032> ffmpeg 03wang-bin 07master:3267e1703b32: avcodec/videotoolbox: set kCVPixelBufferOpenGLESCompatibilityKey for iOS [11:08:19 CET] <cone-032> ffmpeg 03wm4 07master:a755b725ec1d: avcodec: consider an error during decoder draining as EOF [11:08:20 CET] <cone-032> ffmpeg 03wm4 07master:808ab2fd0ba2: ffmpeg: remove unnecessary hack for decoders which refuse to drain [11:08:21 CET] <cone-032> ffmpeg 03wm4 07master:ef86488696a8: avformat/flvdec: remove meaningless warning [11:12:26 CET] <BtbN> philipl, I don't think I have ever tried mpeg2 decoding with cuvid, no. [11:12:32 CET] <BtbN> Will have a look once I get home though [14:07:03 CET] <kierank> wow now the aetey guy brings his own supporters [14:14:02 CET] <wm4> where? [14:16:34 CET] <kierank> kalle blomster [14:20:15 CET] <Compn> atomnuker : put an alias in resample so if someone does -af resample it works ? i guess wm4 already said it [14:21:56 CET] <atomnuker> yeah, I submitted both a patch to rename it and a separate patch to keep af_aresample but provide af_resample [14:22:08 CET] <wm4> kierank: I wouldn't call it supportive [14:22:37 CET] <wm4> I find "aresample" silly, but someone else said it's normal naming, so whatever [14:58:40 CET] <BBB> atomnuker: so we have several applicants for the vp9 tasks now, shall I just tell the rest to do assembly as qual tasks? [14:58:50 CET] <BBB> atomnuker: Im out of other options ATM ... [14:59:05 CET] <BBB> maybe one of them can do something with other decoders [15:25:02 CET] <atomnuker> I dunno which decoders need asm [15:26:47 CET] <jkqxz> Cinepak? [15:27:02 CET] <atomnuker> how SIMDd is FFV1? [15:27:54 CET] <wm4> jkqxz: careful there... [16:05:17 CET] <BBB> wm4: hey come on that was funny ;) [16:05:23 CET] <BBB> wm4: you gotta be able to smile :) [16:05:42 CET] <wm4> you never know what people will take seriously [16:08:20 CET] <BBB> atomnuker: I dont know about ffv1, thats michaelnis territory& jpeg2k might be interesting, but its quite complex and Id like qual tasks to be easier... [16:08:43 CET] <BBB> michaelni: do you think ffv1 has easy stuff left to be simd'ified? [16:09:02 CET] <atomnuker> BBB: dirac lacks any 10bit assembly for any wavelets [16:09:14 CET] <atomnuker> Haar should be easy enough for a quali [16:09:18 CET] <BBB> thats about the same level of compelxity as jpeg2k right? [16:09:20 CET] <BBB> oh, haar [16:09:23 CET] <BBB> yeah that might be easy [16:09:24 CET] <BBB> hm... [16:09:25 CET] <BBB> ok [16:09:36 CET] <BBB> do you want to lead one of the applicants through that? [16:09:48 CET] <BBB> (Im already dealing with a number of them ATM :) ) [16:11:24 CET] <atomnuker> yeah, ok, do they have an IRC handle? [16:11:49 CET] <BBB> not any of the ones whose email I havent answered in the past few days [16:12:03 CET] <BBB> how about you pick ruben and see if hes interested [16:12:03 CET] <atomnuker> you too, huh? [16:12:14 CET] <BBB> :-p [16:12:26 CET] <atomnuker> ok, but first I need to sleep [16:13:04 CET] <BBB> haha ok [16:16:59 CET] <unholy_me> @durandal_1707 I have declared a variable result= w+xcos+ysin, this should be stored in the frame right? [16:18:08 CET] <michaelni> BBB, On the encoder side, i think there are some SIMD possibilities in FFV1, on the decoder side its harder [16:18:34 CET] <BBB> michaelni: ok tnx, probably not quite right target then [16:19:43 CET] <durandal_1707> unholy_me: you store processed samples in frame [16:20:20 CET] <unholy_me> Okay, i have written a prototype how do I test it? [16:21:38 CET] <durandal_1707> unholy_me: do you have b format samples? [16:21:47 CET] <unholy_me> nope [16:21:54 CET] <unholy_me> where can I download it? [16:22:24 CET] <durandal_1707> find them, search on internet for ambisonia [16:24:35 CET] <wm4> lol the CoC is _only_ used to throw supposed rule violations on each others heads [16:25:01 CET] <kierank> only ffmpeg could use a behaviour policy for more misbehaviour [16:26:04 CET] <unholy_me> @duarandal_1707 anyone else working on the Ambisonic project? [16:26:18 CET] <unholy_me> doing the qualification tasks? [16:46:16 CET] <durandal_1707> unholy_me: only you asked this much, others are either not dioing or keeping silent [16:47:24 CET] <unholy_me> @durandal_1707 Sorry sir, this is my first time : [16:48:19 CET] <durandal_1707> unholy_me: np [16:48:49 CET] <cone-032> ffmpeg 03Michael Niedermayer 07master:a9f9b7f5c70e: avcodec/movtextdec: Call mov_text_cleanup() on close [16:48:50 CET] <cone-032> ffmpeg 03Michael Niedermayer 07master:835d9f299cf6: avcodec/x86/cavsdsp: Put MMX code under mmx check [16:48:51 CET] <cone-032> ffmpeg 03Michael Niedermayer 07master:8aa4f3bb4f77: avcodec/proresdec2: Do not discard frames with bad slices [17:46:22 CET] <jamrial> at what point do we put an end to this cinepak madness? the guy spent a month trying to lobby his crap code in instead of using that time to actually fix it [17:46:49 CET] <jamrial> now he's playing policy lawyer and crying about mistreatment. this guy can't be reasoned with [17:46:49 CET] <nevcairiel> the problem is that he thinks he fixed it [17:48:06 CET] <jamrial> that's whay i mean, he can't be reasoned with. the thread has stopped being technical days ago, so if he insists on not fixing his code then he needs to be banned/filtered from the ml [17:48:15 CET] <jamrial> at this point it's noise and very disrupting [18:06:32 CET] <BBB> the danger is that (as michaelni almost accidently did last month) someone will think that us ignoring him means the patch has no further comments and can thus be applied [18:06:54 CET] <BBB> that would be incredibly dangerous, given how hard it is to revert patches in our tree [18:22:07 CET] <Compn> invite him to irc so you can say it to him in real time [18:36:02 CET] <BBB> Compn: but I already told him in one of my earlier emails [19:40:07 CET] <jkqxz> The first rule on the CoC should be "do not attempt to invoke the CoC against other people on the ML". It never helps. [19:45:43 CET] <unholy_me> @durandal_1707 I have written a little buggy code for a square filter, will you have a look at it? [19:46:10 CET] <durandal_1707> yes [19:46:31 CET] <durandal_1707> unholy_me: pm me [19:46:38 CET] <unholy_me> e-mail? [19:47:10 CET] <durandal_1707> unholy_me: no private message over irc [19:47:26 CET] <unholy_me> okay doing [19:50:59 CET] <adeel1> durandal_1707: As the original code was giving incorrect image dimensions, I copied it from XBM. But, after remove it (again), the issue is still open. [19:54:09 CET] <durandal_1707> adeel1: show what you have done? [19:57:54 CET] <adeel1> durandal_1707: https://github.com/adl1995/FFmpeg/commit/9443794ffa6f101b56db2a65e9989e03ad… [20:05:54 CET] <durandal_1707> adeel1: notmal diff,not latest change [20:13:35 CET] <adeel1> https://gist.github.com/adl1995/75e57f99886f6ba6a70315b62e43537c [20:21:28 CET] <durandal_1707> adeel1: what error you get? [20:33:00 CET] <adeel1> durandal_1707: I'm getting this: [xpm @ 0x7ff3dc007480] video_get_buffer: image parameters invalid [xpm @ 0x7ff3dc007480] get_buffer() failed [20:34:26 CET] <durandal_1707> [20:34:59 CET] <durandal_1707> adeel1: get buffer must be called after is pix fmt set [20:38:16 CET] <adeel1> durandal_1707: okay, the errors are now removed, but i'm getting: 18114 segmentation fault (core dumped [20:39:12 CET] <durandal_1707> adeel1: because you need to learn pointers and arrays in C [20:40:42 CET] <adeel1> durandal_1707: oh, let me check. I've actually played around with pointer in my previous courses, but it's been some time. will fix and let you know. [21:00:41 CET] <cone-701> ffmpeg 03Kagami Hiiragi 07master:734d760e2fb2: lavc/libvpxenc: add -row-mt option [21:45:29 CET] <durandal_1707> how much text this guy wrote he could rewrite swscale from scratch [22:12:20 CET] <BtbN> Woah, a MPC-HC Update [22:12:27 CET] <BtbN> Thought that project was dead [22:16:28 CET] <peloverde> Their github has been pretty active for a while lately [22:17:01 CET] <BtbN> Was about time they updated the bundled lavfilters and stuff [22:17:05 CET] <JEEB> DShow is just not as fun as it was before [22:17:21 CET] <BtbN> It still outperforms VLC by a lot for me [22:17:24 CET] <BtbN> So I prefer it [22:18:03 CET] <JEEB> most of my use cases don't require the UI and I got tired of teaching people how to fix the drivers trying to insert their filters into the rendering path [22:18:14 CET] <JEEB> so I just moved to mpv as it finally had windows as a first-class citizen [22:21:09 CET] <jamrial> BtbN: one of their core dev seems to have retired, so they are lacking in manpower [22:21:29 CET] <jamrial> that's why it took them a year and three months to get a release out [22:23:05 CET] <JEEB> most of the core devs left or became busy IRL [22:23:13 CET] <JEEB> I think kasper93 is the only one left semi-active [22:31:28 CET] <nevcairiel> it can probably keep functioning fine by just updating its lav version once in a while [22:44:24 CET] <peloverde> Good support dpi scaling is probably important for windows players these days (and in fact SVG UI is one of the new features) [00:00:00 CET] --- Tue Mar 7 2017

1 0

ffmpeg.log.20170306
by burek 07 Mar '17

07 Mar '17

[01:06:30 CET] <bencc1> I transcoded the same 90 mintues video with preset veryfast (195 MB) and medium (260MB) [01:06:51 CET] <bencc1> isn't veryfast suppose to give larger file? [01:07:50 CET] <JEEB> with CRF? CRF isn't supposed to be the same between different parameters [01:08:07 CET] <JEEB> because what the CRF algorithm "sees" differs quite a bit [01:09:28 CET] <bencc1> JEEB: yes, crf 23 [01:09:37 CET] <JEEB> well there's your answer [01:10:09 CET] <JEEB> CRF was never meant to be comparable between parameters (or encoders for that matter, for those who think that x264 and x265 share CRF values) [01:10:11 CET] <bencc1> there is no way to compare them with the "same" quality? [01:10:25 CET] <JEEB> you need to define "quality" first [01:10:47 CET] <bencc1> true :) [01:11:12 CET] <bencc1> if I'll decrease the crf I'll get better quality with same cpu load? [01:11:21 CET] <bencc1> assuming we know how to define quality [01:11:58 CET] <JEEB> with lower CRF it will try to occur less error onto the source [01:12:10 CET] <bencc1> so it'll use more cpu? [01:12:15 CET] <JEEB> ... [01:12:24 CET] <bencc1> yes? [01:12:25 CET] <JEEB> how the flying fuck did you read that [01:12:56 CET] <JEEB> in any case, more CABAC means more CPU power, so the more data you output from an encoder the more theoretically it is using CPU [01:13:01 CET] <bencc1> when trying to occur less error, does it means just large file size or maybe it requires more work? [01:13:11 CET] <JEEB> it means just more bits [01:13:33 CET] <JEEB> but of course more bits in theory means (on some level) more CPU usage because there is more data to process (and to compress with CABAC) [01:13:46 CET] <JEEB> same thing goes with decoding, more bit rate actually makes the decoding require more CPU [01:14:07 CET] <JEEB> whether or not that is relevant to your scenario on the scale of the difference depends [01:14:52 CET] <bencc1> I'm decoding a large number of 'screen captures' [01:15:13 CET] <bencc1> less CPU load means I can transcode more in parallel [01:15:24 CET] <bencc1> smaller file size means less storage and bandwidth [01:15:59 CET] <bencc1> but preset and CRF are both affecting I'm not sure how to choose [01:16:05 CET] <bencc1> but *if* [01:16:38 CET] <bencc1> not sure if I should go with preset veryfast/medium/slow and what CRF to choose [01:18:43 CET] <JEEB> if you want to maximize the amount of things being done in parallel then you want to use threads 1 anyways, and in that case all that matters is A) how long a single transcode takes and B) how much compression you get [01:19:33 CET] <JEEB> if you really want to start poking around then you can use a metric like SSIM, and use -tune ssim and try to match different presets to the same SSIM [01:19:42 CET] <JEEB> shouldn't be too hard to script [01:19:51 CET] <JEEB> SSIM is not quality, but it's one of the least bad metrics [01:19:54 CET] <bencc1> I have to do it in realtime. I'm actually recording a xvfb display [01:20:31 CET] <JEEB> well then you don't have a large number of 'screen captures', do you? [01:20:44 CET] <JEEB> you have actual screen capture that you want to encode in real time [01:21:04 CET] <bencc1> I'm recording a web browser in a virtual display playing something [01:21:21 CET] <bencc1> so I can have X sessions each with each own virtual display [01:21:55 CET] <JEEB> ok, then to maximize the amount of sessions you can have you need to use threads 1 *and* use a preset that is realtime [01:22:20 CET] <bencc1> "-preset medium crf 23" uses 15% of my cpu [01:22:48 CET] <bencc1> that might give me a very large file, doesn't it? [01:23:01 CET] <bencc1> compared to preset medium for example [01:23:03 CET] <gurki> JEEB: more data to process doesnt neccesarily result in more cpu cycles needed [01:23:13 CET] <JEEB> gurki: with CABAC I'd say it does [01:23:32 CET] <JEEB> whether or not it is a relevant difference is a separate discussion [01:24:07 CET] <gurki> i dont know enough about CABAC to discuss the impacts on that, i just found it neccesary to state that more data doesnt always need more cpu :) [01:24:08 CET] <bencc1> "-preset:v ultrafast -crf 0 -threads 0" works but it gives me a very large file [01:24:09 CET] <JEEB> bencc1: go to sleep - you are clearly writing not what you are thinking [01:24:14 CET] <gurki> sorry for interrupting :) [01:24:16 CET] <JEEB> gurki: this was specific to AVC [01:24:19 CET] <bencc1> :) [01:24:31 CET] <JEEB> and CABAC is the lossless compression scheme in it [01:24:58 CET] <JEEB> there's also CAVLC but that is mostly irrelevant and has similar effect anyways (just compresses less well) [01:28:25 CET] <JEEB> gurki: you can think of CABAC and CAVLC as decompressing or compressing something with huffman or something along those lines - the more data you have coming in to the algorithm the more CPU cycles it will take to finish (dec)compressing that input [03:19:34 CET] <funyun> can ffmpeg handle this? if so, can anyone point me in the right direction? i'm trying to add a 3 minute audio file looped into the background of a 2 hour audio file. so the total length would still be 2 hours. but the 3 minute audio will play looped in the background [04:29:50 CET] <ItWasntM_> share your command if you have one funyun [04:30:04 CET] <ItWasntM_> should be easy to set your audio to loop [04:51:01 CET] <RossW> is there a way to tell ffmpeg to use (request, negotiate, whatever) a higher bitrate (quality) from an RTSP source (camera)? [05:37:02 CET] <ZeroWalker> hmm, okay i seems to somewhat be able to encode2 now, but i don't get the package system. cause i tell it to encode a frame, but it doesn't (got_package == 0), so i just do a while loop till it gets a package, which seems to happen after 51 loops. what's the point of that, can't i just request an encode and it will wait till it's done? [10:05:40 CET] <LongWork> if i want to create a file with an hevc bistreamed binary content, is this the right ffmpeg command : ffmpeg -i test.mp4 -c:v copy -bsf:v hevc_mp4toannexb test.ts ? [10:11:44 CET] <JEEB> LongWork: I think that bsf:v might be automated now with latest FFmpeg [10:40:35 CET] <NaGeL> hello. I'm trying to compile ffmpeg on my ubuntu 14.04.1 server with the folowing command: PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure --prefix="$HOME/ffmpeg_build" --pkg-config-flags="--static" --extra-cflags="-I$HOME/ffmpeg_build/include" --extra-ldflags="-L$HOME/ffmpeg_build/lib" --bindir="$HOME/bin" --enable-gpl --enable-libass --enable-libfdk-aac --enable-libfreetype [10:40:35 CET] <NaGeL> --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-nonfree --enable-openssl --enable-gnutls [10:40:44 CET] <NaGeL> but it fails on this: [10:40:54 CET] <NaGeL> ERROR: gnutls not found using pkg-config [10:41:07 CET] <NaGeL> I installed gnutls with apt-get install gnutls-bin [10:41:12 CET] <NaGeL> so its instaled [10:41:36 CET] <NaGeL> i need that becouse of https support and openssl alone doesnt work sadly :( [10:42:12 CET] <JEEB> you need the dev package for actually developing/building thigns against something [10:42:40 CET] <JEEB> hint: it should have a similar name but ending with -dev :P [10:51:01 CET] <NaGeL> there is no dev package of it.... [11:03:40 CET] <ben___> hi, I'm trying to use the ffmpeg libs to do simple livestreaming. I want to produce h264 and wrap it in mkv. Can anyone recommend a good tutorial on how to do this? So far I've only found tutorials on decoding videos. [11:10:27 CET] <NaGeL> JEEB, cant find any dev packages :( [11:10:35 CET] <NaGeL> or at least not ones that work :( [11:19:46 CET] <ben___> To be a more precise: I'm stuck on setting the right timebases both on the encoder and muxer. Somehow my mkv-output says it has a framerate of 1k, and I have no idea why. Working source code would also help a lot (already checked the muxing.c example from ffmpeg) [14:39:10 CET] <xeche> anybody remember what avcodec_parameters_from_context replaced? [14:39:40 CET] <xeche> having to work with an ancient ffmpeg build (2.4) because of distro [14:40:12 CET] <xeche> except for the codec parameter stuff, I think the API usage is mostly the same in 2.4 and 3.1 though [15:06:52 CET] <DHE> xeche: just using the AVStream->codec field for the parameters [17:41:37 CET] <shincodex> I want to static link all av librarys to have microsoft linker perform further optimization [17:41:47 CET] <shincodex> But LGPL foolishly say taht only dll use [17:41:57 CET] <shincodex> where to have written permission for static link [17:45:03 CET] <nido_> "You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following: d) Do one of the following: 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and unde [17:45:51 CET] <nido_> what probably also works is to not distribute the binaries [17:45:54 CET] <shincodex> That is kinda hard to read [17:46:15 CET] <shincodex> What do you mean not distrubute binaries [17:46:17 CET] <nido_> that's licenses for you. written for lawyers rather then people [17:46:24 CET] <shincodex> (yes) [17:46:34 CET] <shincodex> a exe is a binary [17:46:39 CET] <shincodex> a dll is one sorta [17:46:39 CET] <nido_> i mean you compile however you like to, then you don't give the resulting binaries to other peopel but keep them for yourself only [17:46:41 CET] <shincodex> reall a so is [17:46:58 CET] <shincodex> Whoa what [17:47:07 CET] <shincodex> I compile as static and dont give it out? [17:47:09 CET] <shincodex> the hell? [17:47:14 CET] <shincodex> Teh whole point is to give it out [17:47:17 CET] <shincodex> or do you mean the source [17:48:15 CET] <nido_> i have no idea what yuor plan was; but you said you want to static link for some reason; i figured it was for your own use [17:48:43 CET] <shincodex> Nope. [17:48:49 CET] <shincodex> here is all in one exe [17:49:01 CET] <shincodex> there is no about box [17:49:02 CET] <shincodex> but if you like [17:49:10 CET] <shincodex> exe --about [17:49:24 CET] <shincodex> blah blah blah ffmpeg here is where you can find owner in his apartment blah blah blah [17:50:59 CET] <nido_> I dont understand. whats with the 'about box'? and if you're gonna statically link avcodec and have a problem with lgpl im guessing you dont want to link it with any foss code ( includnig ffmpeg itself)? [17:51:21 CET] <shincodex> only static link 3? av libraries [17:51:31 CET] <shincodex> sws scale i think is another [19:00:43 CET] <faLUCE> I don't understand if this is a missing feature of ffplay. I receive a real time audio+video mpegts stream through HTTP, captured with a web camera. The video framerate is variable, and if it's low, then ffplay increases the latency when playing the stream, in order to keep synced audio and video. But when the video framerate increases, and it goes to 25, the previous latency is not automatically decreased by ffplay, and [19:00:45 CET] <faLUCE> if I want to see the stream with no-latency, I have to stop and start again ffplay. Why? [19:17:17 CET] <alexpigment> does anyone know how to compile ffmpeg for mac with 10-bit h.265? [19:17:33 CET] <JEEB> decoding comes out of the box, `brew install ffmpeg` should do it [19:17:48 CET] <alexpigment> 10-bit hevc encoding [19:17:49 CET] <JEEB> for encoding you will need to build libx265 and enable it in the configure [19:18:04 CET] <JEEB> (plus remember to enable the high bit depth mode in libx265's configuration) [19:18:29 CET] <alexpigment> so i put "--with-x265" and "--with-10-bit" on the build parameters. i take it you're saying that isn't enough [19:19:47 CET] <JEEB> I have no idea to which that latter thing points [19:20:05 CET] <JEEB> you can check if 10bit libx265 is linked against your FFmpeg by checking `ffmpeg -h encoder=libx265` [19:20:17 CET] <JEEB> that should output the capabilities as far as pixel formats go [19:20:22 CET] <JEEB> that should include yuvXXXp10 [19:20:30 CET] <JEEB> the *p10* being the important bit [19:20:36 CET] <JEEB> which means it's 10bit [19:20:56 CET] <alexpigment> yeah, it's only doing 8 [19:21:29 CET] <JEEB> then you'll have to dig further and make sure relevant things got rebuilt [19:21:33 CET] <alexpigment> i guess what i'm wondering is if doing this through brew install ffmpeg [params] is possible [19:21:35 CET] <JEEB> rebuild libx265 and FFmpeg [19:21:48 CET] <alexpigment> and if not, do i need to use xcode or something? [19:21:50 CET] <JEEB> then make sure that `which ffmpeg` shows the right ffmpeg tool [19:21:55 CET] <JEEB> no, no need for xcode [19:22:31 CET] <alexpigment> so just rebuild it with the same parameters? [19:22:41 CET] <alexpigment> i'm confused about what rebuilding it will do [19:23:40 CET] <JEEB> in case you switched params for libx265 or FFmpeg [19:23:47 CET] <JEEB> and it didn't auto-rebuild FFmpeg where needed [19:23:53 CET] <relaxed> alexpigment: my builds have 10bit support, http://johnvansickle.com/ffmpeg/ [19:23:55 CET] <JEEB> (for the updated components to show u) [19:24:21 CET] <relaxed> oh, mac [19:24:35 CET] <alexpigment> relaxed: yeah, i did windows last week [19:24:37 CET] <alexpigment> doing mac this week [19:24:47 CET] <alexpigment> but i do appreciate the link to your builds [19:28:45 CET] <relaxed> alexpigment: you should be able to build libx265 with both 8, 10, and 12bit support. See x265/build/linux/multilib.sh [19:30:44 CET] <JEEB> I think libx265 if you don't want the 8bit only optimizations should be able to build one library that can encode 8-10bit [19:30:49 CET] <JEEB> unlike libx264 [19:31:01 CET] <JEEB> the multilib is only needed IFF you want the 8bit only optimizations [19:31:41 CET] <furq> alexpigment: looks like you should be able to build x265 with --with-16-bit and then rebuild ffmpeg [19:31:44 CET] <furq> with brew [19:32:19 CET] <JEEB> right, that's why I wanted to note what the "--with-10-bit" parameter meant [19:32:22 CET] <JEEB> that ne mentioned [19:32:43 CET] <JEEB> because libx265's cmake parameter is 16bit [19:32:55 CET] <furq> yeah i figured that was for x264 [19:36:39 CET] <bencc1> when encoding h264 ffmpeg use the following cpu features on my server: MMX2 SSE2Fast SSSE3 SSE4.2 AVX [19:36:52 CET] <bencc1> are there other features I need to consider when choosing my next server? [19:37:21 CET] <furq> clock speed? [19:38:54 CET] <alexpigment> sorry back. thanks for the info guys. i'm going to try the --with-16-bit option. i had seen "--with-10-bit" option on a forum post somewhere. as you guys probably know, there is a lot of useful ffmpeg information randomly in small corners of the internet, but it's littered with just as much misinformation. i guess that's the case with any obscure subjects [19:38:58 CET] <furq> haswell and up have avx2 but i don't think that's really a huge deal [19:39:15 CET] <furq> and i'm not aware of anything newer which makes any difference [19:40:39 CET] <alexpigment> bencc1: i presume you're wanting x264 rather than a hardware solution like NVENC or QuickSync? [19:41:26 CET] <furq> well that message comes from libx264, so i assume so [19:54:49 CET] <ChocolateArmpits> I have a single input that can only be called once. What protocol should be used to restream the contents back to localhost so that multiple other ffmpeg processes can pick it up, basically multiplying the same single source? I can't use tee for this. [20:07:57 CET] <furq> i take it you can't use multiple outputs either [20:08:58 CET] <ChocolateArmpits> well in case some of the processes crash I don't want them taking out others [20:09:19 CET] <ChocolateArmpits> Like a destination ending connection [20:10:27 CET] <furq> i'm not sure if any protocols support multiple clients without using an external server [20:59:05 CET] <zipnine> Hi all! [20:59:48 CET] <zipnine> How do you manage/maintain multiple ffmpeg programs? [21:00:34 CET] <JEEB> in what sense? [21:00:40 CET] <zipnine> I know I can create a script and run them in the background but I want to catch any errors or have an convenient place to view all the running threads. Just curious what everyone is doing. [21:01:17 CET] <zipnine> JEEB: I need to transcode 10 incoming (live) streams and want to monitor them in case they have errors or crash. [21:02:15 CET] <JEEB> the simplest thing is to write a service file for systemd for each of them, and log stderr [21:02:26 CET] <JEEB> that also enables automated restart in case of crash or exit [21:02:58 CET] <llogan> or use the fifo muxer to enable recovery of the output in case of disconnection/failure [21:03:08 CET] <zipnine> okay. got it. [21:03:10 CET] <zipnine> what [21:03:28 CET] <zipnine> what's fifo muxer? I'll check the man pages. [21:03:35 CET] <zipnine> err not man..docs. [21:03:37 CET] <llogan> http://ffmpeg.org/ffmpeg-formats.html#fifo [21:04:01 CET] <llogan> it can be a little confusing to use...especially if you use it with the tee muxer [21:33:39 CET] <ZeroWalker> anyone know why encode2 doesn't always return a package? http://sprunge.us/bBBA [21:34:54 CET] <BtbN> because it doesn't have to. [21:35:07 CET] <BtbN> With reordering and delay for lookahead [21:35:59 CET] <JEEB> ZeroWalker: you keep feeding it frames and at some point it will return some packets. and then at the end you will have to "flush" the encoder so that no more packets come out [21:38:40 CET] <ZeroWalker> wait so when you flush, you will get all the frames? [21:39:04 CET] <ZeroWalker> but is it possible to make it instant, cause latency is the key in my case [21:39:31 CET] <kepstin> ZeroWalker: if you want to reduce delay, you need to change encoder or encoder settings to reduce delay [21:39:32 CET] <ZeroWalker> i get quality will be reduced cause of it [21:39:47 CET] <ZeroWalker> but can i make it sleep till the frame is done? [21:39:51 CET] <kepstin> ZeroWalker: e.g. with libx264, use "tune=zerolatency" option. And yes, it will reduce quality [21:40:37 CET] <ZeroWalker> cause i would like to Encode, then after that the frame is done and i do something with it etc [21:40:41 CET] <ZeroWalker> ah yeah that one [21:42:00 CET] <kepstin> ZeroWalker: the normal usage is you just push frames into the encoder, and it eventually starts giving you frames back. You then flush when done (give it "NULL" frames) until the encoder stops returning encoded frames. [21:43:25 CET] <ZeroWalker> hmm, kinda confusing, but then again not used to this kind of async methods [21:44:11 CET] <kepstin> x264, depending on options, can buffer as much as 250 frames in memory before it starts giving you encoded frames. [21:44:39 CET] <ZeroWalker> ah [21:45:08 CET] <kepstin> (the "zerolatency" option switches it into a strict 1-frame-in1-frame-out mode, with noticable quality loss) [21:47:57 CET] <ZeroWalker> ah well then that's what i want probably in my case. [21:48:32 CET] <ZeroWalker> hmm, isn't the x264 options done specially in ffmpeg, trying to find it, not sure if it's the AVDictionary or [21:49:53 CET] <DHE> you can use the standard AVCodecContext settings where they have obvious x264 equivalents, or you can use the AVDictionary to submit them like you would ffmpeg command-line parameters [21:50:24 CET] <ZeroWalker> but tune and preset is one of those that aren't there right? [21:50:40 CET] <DHE> and of course you can use av_dict_set(&dict, "x264opts", "no-scenecut:frameref=5:....", 0); [21:50:44 CET] <ZeroWalker> cause looking at it now, i think you need to do some weird stuff [21:50:48 CET] <DHE> and say "screw it" to the whole standard [21:51:35 CET] <ZeroWalker> ah, hmm that might be easier as i am used to the command lines [21:53:10 CET] <ZeroWalker> or wait maybe not if it comes to defining the pixel formats [21:54:14 CET] <DHE> also I believe x264 doesn't accept tune, profile or preset from x264opts, but ffmpeg will eat them properly if used as av_dict_set(&dict, "profile", "baseline", 0); [21:54:39 CET] <JEEB> x264-params is the thing that pushes stuff straight into libx264 [21:54:50 CET] <JEEB> x264opts is something that should be killed off to be honest [21:54:58 CET] <JEEB> since it just has its own parser and all that jazz [21:55:28 CET] <JEEB> x264-params also has a variant with libx265 with x265-params [21:59:48 CET] <llogan> JEEB: i see no reason for both. does x264opts have any advantage over x264-params? [22:00:11 CET] <JEEB> no [22:00:25 CET] <JEEB> x264-params was added because x264opts was half-assed originally [22:00:53 CET] <llogan> will you submit a patch removing x264opts? [22:01:43 CET] <JEEB> hmm, might even do that [22:02:10 CET] <JEEB> although FFmpeg generally only loses features when people don't notice. like the chinese HLS muxer guy [22:02:19 CET] <JEEB> who just pushes his removals of options etc [22:02:44 CET] <JEEB> but yeah, I guess it's worth a try :P [22:03:10 CET] <llogan> i'll push it if there are no insane objections [22:03:19 CET] <llogan> *sane [22:04:02 CET] <llogan> while you're at it can you merge the prores' too? [22:04:18 CET] <JEEB> and yeah, I just checked what x264opts does in my local repo and it still does the same thing it did before [22:04:31 CET] <JEEB> so I will post a patch to remove it telling people to use x264-params instead [22:04:58 CET] <llogan> thanks [22:05:17 CET] <JEEB> as it seems like it's just setting AVOptions by itself or something (why would you even...) [22:05:48 CET] <JEEB> while x264-params uses x264_params_parse [22:09:52 CET] <llogan> i purged it from the 264 wiki page [22:10:43 CET] <ZeroWalker> so, i should use x264-params;o? [22:11:16 CET] <JEEB> you can use the avcodec options or x264-params [22:11:33 CET] <JEEB> avcodec options open some things (I'd say, most things) on the avcodec side [22:11:54 CET] <JEEB> but x264-params lets you pass things straight to libx264 as key=value pairs [22:12:19 CET] <ZeroWalker> does avcodec support tune, preset? [22:12:36 CET] <JEEB> yes [22:12:44 CET] <JEEB> those are normal avcodec options for the libx264 encoder [22:12:54 CET] <llogan> you can see a list: ffmpeg -h encoder=libx264 [22:13:10 CET] <DHE> AVCodecContext->profile is a field [22:19:15 CET] <JEEB> or wait [22:19:38 CET] <JEEB> llogan: am I reading this incorrectly because it seems like encoders.texi is talking of it as if it does the same thing as x264-params [22:21:16 CET] <JEEB> yea... I don't see it actually touching x4->params [22:22:30 CET] <JEEB> so either the documentation is lying out of its arse or I can't see it happening with OPT_STR [22:22:59 CET] <llogan> I don't know if I would trust documentation that states, "They accept it as well since long ago but this is kept undocumented for some reason." [22:23:53 CET] <JEEB> because what I remember is that x264opts tried to emulate that hard by just adding avoptions with similar names [22:24:05 CET] <JEEB> and that would match with OPT_STR [22:24:18 CET] <JEEB> oh [22:24:29 CET] <JEEB> should have looked at the definition of that macro [22:24:34 CET] <JEEB> d'uh [22:25:09 CET] <JEEB> much less obvious than the x264-params thing, but seems to do primarily the same darn thing :V [22:26:07 CET] <llogan> we still don't need two [22:27:12 CET] <JEEB> you can bet someone will raise a whirlwind because the documentation mentions x264-params coming from Libav [22:27:16 CET] <JEEB> but yeah, I agree [22:27:23 CET] <JEEB> and x264-params and x265-params are a pair [22:27:36 CET] <furq> can you set creation_time with ffmpeg when muxing an mp4 [22:28:00 CET] <llogan> we can just remove that Libav line since it will be moot [22:28:24 CET] <llogan> and +1 on the name pairing [22:29:20 CET] <llogan> furq: i believe so. -metadata creation_time now [22:29:25 CET] <llogan> =now [22:29:39 CET] <furq> neat [22:29:54 CET] <llogan> creation_time=$(date +%FT%T%z) or whatever [22:30:31 CET] <furq> now is fine [22:31:05 CET] <llogan> check that it works. iirc it used to set some oddball time, but it was fixed i think. i can't remember. [22:31:09 CET] <furq> yeah i am doing [22:31:28 CET] <furq> i have a bunch of videos going to google photos and it sets the date on them to the mp4 creation_time [22:31:41 CET] <furq> which i don't care about, i just want them to be in order [22:32:12 CET] <furq> i would just use mp4box but that's bailing out on some of these files [22:32:34 CET] <furq> cue JEEB throwing up in his mouth a little bit [22:33:20 CET] <llogan> humperdinck! [22:33:28 CET] <furq> creation_time : 2017-03-06T21:30:27.000000Z [22:33:29 CET] <furq> perfect [22:33:30 CET] <furq> thanks [22:33:54 CET] <llogan> i wonder if "now" is documented... [22:40:26 CET] <JEEB> furq: GPAC is awful but I do understand that L-SMASH's tooling doesn't yet handle all of the cases that mp4split et al handle [22:41:49 CET] <furq> can l-smash set (or just remove) creation_time [22:44:11 CET] <furq> i already have it installed for boxdumper but i'm not japanese enough to find the docs [22:45:22 CET] <JEEB> I can't see a specific option for it but you could try running remuxer through a file and see if it overrides that or not (possibly not since remuxer might have been made with the idea of minimizing changes) [22:45:28 CET] <JEEB> muxer most likely does set the value, though [22:45:35 CET] <JEEB> API-wise it most likely does it [22:45:59 CET] <furq> i'll have a look next time i've got a batch to remux [22:46:06 CET] <furq> i'm already halfway through doing it with mp4box/ffmpeg now [22:46:17 CET] <JEEB> makes sense [22:46:37 CET] <JEEB> anyways, because the biggest users of L-SMASH are API users the tools aren't bad but limited :D [22:46:41 CET] <furq> or "MP4Box" since i'm on debian [22:46:58 CET] <JEEB> that's the actual binary name in GPAC [22:47:03 CET] <JEEB> they love their CamelCase tools [22:47:17 CET] <furq> yeah but freebsd (hopefully amongst others) has the good sense to rename it to mp4box [22:47:57 CET] <furq> which of course meant i tried mp4box first on debian and it didn't work, and then i tried MP4Box first on freebsd and it didn't work [22:49:04 CET] <JEEB> sounds like when I learned to drive I started with the truck but my first test was on a normal vehicle. there I got told that I was driving it just like a truck. and then the things reversed and I got told that I was driving the truck a bit like a normal car [22:49:32 CET] <furq> i was thinking more like a usb a connector, but that works too [22:52:09 CET] <alexpigment> does the concept of shared vs static ffmpeg apply on OS X, or is that just a Windows thing? [22:52:50 CET] <JEEB> it applies to OS X just fine as well, only relevant if you're building FFmpeg to link against it in your own application [22:52:55 CET] <JEEB> as in, using the libav* APIs [22:53:48 CET] <ZeroWalker> when using stuff like av_frame_alloc, can one just reuse it with just changing the data? [22:55:22 CET] <alexpigment> JEEB: so if i'm building it via brew install ffmpeg, do you know the parameter that makes it a shared library? [22:55:30 CET] <JEEB> no fscking idea [22:55:48 CET] <alexpigment> k. i looked through the help but couldn't find anything. i'll keep googling. thanks [22:59:17 CET] <newbie_> Does anyone have any reading material on how frames, samples etc are working? [23:03:07 CET] <kepstin> ZeroWalker: you should only change stuff in the frame if it's not referenced in multiple places (i.e. reference count is 1 and you hold the only reference). You should consider using a buffer pool (from libavutil/buffer.h) as an allocator and just allocate new buffers each time, which will be recycled automatically. [23:04:12 CET] <bencc1> alexpigment: yes [23:06:02 CET] <alexpigment> bencc1: do you happen to know what the parameter is? in other words, what do i type after brew install ffmpeg --[shared vs static toggle] [23:08:54 CET] <Tatsh> hi, converting and encoding an old xvid file [23:08:56 CET] <Tatsh> [mpeg4 @ 0xc63060] Video uses a non-standard and wasteful way to store B-frames ('packed B-frames'). Consider using the mpeg4_unpack_bframes bitstream filter without encoding but stream copy to fix it. [23:09:03 CET] <Tatsh> is this a warning i can ignore? [23:10:07 CET] <JEEB> yes [23:10:34 CET] <JEEB> it's trying to guilt-trip you because b-pictures in AVI are an abomination [23:10:56 CET] <JEEB> (as AVI is an ooold container and really doesn't lend itself well to the whole b-picture thing :P) [23:13:56 CET] <faLUCE> which is the equivalent option of gop_size for audio encoding? [23:14:50 CET] <kepstin> faLUCE: doesn't make sense which how most audio codecs operate. [23:15:04 CET] <JEEB> not sure any audio encoders let you set the frame size [23:15:08 CET] <JEEB> but that would be the only thing [23:15:17 CET] <kepstin> well, opus does, but other than that... [23:15:51 CET] <bencc1> alexpigment: no, sorry [23:16:10 CET] <kepstin> I don't think ffmpeg's libopus wrapper exposes that, though. [23:17:41 CET] <kepstin> faLUCE: audio codecs generally encode fixed size frames (X samples per frame), and you can decode starting at any frame (usually with a delay - you get back audio starting at some point slightly after where you started decoding) [23:18:41 CET] <faLUCE> kepstin: I see. Then I don't understand why ffplay adds some delay before decoding a http mpegts audio-only LIVE stream [23:20:34 CET] <kepstin> faLUCE: I'd assume most of the delay is just tcp connection setup and network buffering... [23:20:40 CET] <JEEB> llogan: sent the patches [23:20:45 CET] <JEEB> now waiting for the pop corn response [23:21:50 CET] <faLUCE> kepstin: I'm doing all 127.0.0.1... If I stream an audio file with "ffmpeg -i AVLibMP2File.mp2 -listen 1 -acodec copy -f mpegts http://localhost:8080/stream.ts" I don't have any delay [23:22:36 CET] <faLUCE> is there a way to debug what is ffplay doing during the delay ? [23:22:40 CET] <Tatsh> JEEB, i know [23:22:42 CET] <Tatsh> it's long since that time though [23:22:49 CET] <faLUCE> I tried -v debug, but it did not give me useful infos [23:22:53 CET] <Tatsh> 10+ years where everyone thought xvid was cool [23:23:38 CET] <Tatsh> it's too bad almost nothing supports mpeg-4 part 2 natively [23:24:35 CET] <JEEB> my sony console from 2005 supported mpeg-4 part 2 in isobmff [23:25:21 CET] <furq> that sure is a weird way to say "psp" [23:25:22 CET] <Tatsh> so did mine [23:25:26 CET] <Tatsh> my xbox 360 too [23:25:36 CET] <Tatsh> both ps3 and xbox 360 supported it after updates [23:26:02 CET] <TD-Linux> that's a weird way to say "luckily" [23:26:42 CET] <Tatsh> JEEB, was that a psp with hardware support? [23:26:47 CET] <JEEB> yes [23:26:52 CET] <Tatsh> interesting, i had no idea they did that [23:26:56 CET] <JEEB> it had an ASIC for mpeg-4 part 2 and AVC [23:27:11 CET] <Tatsh> ios has AVC and now HEVC but no mpeg-4 part 2 [23:27:17 CET] <alexpigment> didn't most dvd players in the 2000s support MPEG-4 Part 2 (i.e. XviD or DivX logos on the front)? [23:27:23 CET] <Tatsh> not most, a bunch did [23:27:30 CET] <Tatsh> but not the top brands like Sony, JVC, etc [23:27:44 CET] <JEEB> Tatsh: I'm pretty sure there's a part 2 ASIC there on the iDevices as well, just no interfaces [23:27:53 CET] <JEEB> just like the HEVC interfaces have been quietly removed [23:27:54 CET] <Tatsh> most of the brands you never heard of would randomly support things like DivX (or what they really mean) [23:28:23 CET] <Tatsh> they also tended to support VCD despite virtually non-existence of commercial VCDs in the US [23:28:44 CET] <JEEB> I actually have a single 100% official and fuck-expensive VCD [23:28:52 CET] <alexpigment> Tatsch: I think it was more openly and widely supported than that. Not just osbscure chinese brands. (context: i visit goodwill every week to look for electronics. i see that logo on high-end stuff) [23:28:57 CET] <Tatsh> hehe and it's not from Japan or China? [23:29:04 CET] <JEEB> neither of those [23:29:18 CET] <Tatsh> i have some DivX 'DVDs' that are unplayable [23:29:21 CET] <JEEB> also did VCD ever become something in Japan, they went for DVD pretty quickly [23:29:28 CET] <JEEB> and before that laserdisc [23:29:30 CET] <Tatsh> i don't think it ever really took off [23:29:33 CET] <Tatsh> because laserdisc [23:29:34 CET] <TD-Linux> I remember making a VCD when I got my first CD burner [23:29:37 CET] <alexpigment> i think VCD only took hold in China tbh [23:29:52 CET] <Tatsh> VCD was a cheap alternative in china for some reason, probably because of easier pirating [23:29:54 CET] <TD-Linux> and then never again because MPEG-1 at 240p [23:29:56 CET] <alexpigment> because japan cared about quality and VCD's quality was pretty awful [23:29:57 CET] <JEEB> TD-Linux: well yea d'uh, my first back-ups of animoo were VCDs as well [23:30:04 CET] <JEEB> and yes, after that never again [23:30:06 CET] <Tatsh> then SVCD came out and fixed almost nothing [23:30:41 CET] <TD-Linux> JEEB, laserdisc animu is where it's at [23:30:44 CET] <Tatsh> i did backup a number of my DVDs to VCD way back when [23:30:52 CET] <Tatsh> pretty normal to reduce to the lesser size as a backup [23:31:12 CET] <Tatsh> and with a CRT TV you wouldn't care too much [23:31:15 CET] <alexpigment> tatsh: it was poor decisions like that that made me have to re-rip a few hundred DVDs like that in the past year [23:31:20 CET] <Tatsh> alexpigment, same [23:31:28 CET] <Tatsh> i've re-ripped all mine [23:31:40 CET] <Tatsh> a few i still have in xvid because i don't have the disc here [23:31:49 CET] <furq> ironically enough all my dvds are backed up in china now [23:31:53 CET] <Tatsh> i have like almost 100 films in my storage unit [23:31:54 CET] <Tatsh> dvd [23:32:14 CET] <Tatsh> but yeah i think VCD only took in china because piracy :P [23:32:24 CET] <furq> and price [23:32:43 CET] <alexpigment> yeah, CDs were cheap, and if you didn't care about quality, then it was a pretty good format i suppose ;) [23:32:50 CET] <Tatsh> once it was there in pirated form, legit prints were made and the distributors had no choice [23:32:55 CET] <Tatsh> because everyone had a VCD player at home [23:33:10 CET] <TD-Linux> I really want to burn a laserdisc but there's virtually no information on the sync encoding [23:33:12 CET] <Tatsh> still today in china you can find pirated blu-ray so cheap [23:33:18 CET] <furq> they're still somewhat popular in vietnam and places like that [23:33:35 CET] <furq> TD-Linux: do you have an ld-r drive [23:33:41 CET] <Tatsh> TD-Linux, burn a laser-disc? how? [23:33:42 CET] <furq> or are you going to do it by hand [23:33:46 CET] <TD-Linux> furq, no, it would be with a hacked fw CD burner [23:33:55 CET] <furq> you'd have to hack more than the firmware [23:34:09 CET] <Tatsh> laserdisc format is very unusual to me [23:34:23 CET] <alexpigment> yeah, laserdisc is analog [23:34:23 CET] <Tatsh> it's like a disc but then it's like a vinyl [23:34:24 CET] <alexpigment> so... [23:34:33 CET] <faLUCE> "ffmpeg -f alsa -i plughw:2,0 -listen 1 -acodec mp2 output.mp2" <---- Unknown input format: 'alsa' ..... what's wrong? I use 2.8.7 [23:34:39 CET] <Tatsh> faLUCE, update [23:34:46 CET] <furq> you didn't build with alsa support [23:35:09 CET] <furq> ffmpeg -devices [23:35:22 CET] <Tatsh> good old days with the hacked mpeg-4 codec from MS, then DivX, then XviD took over [23:35:25 CET] <kepstin> huh, I thought laserdisc was pcm-encoded composite video, not analog? [23:35:35 CET] Action: kepstin doesn't really know tho :) [23:35:51 CET] <alexpigment> no, the audio could be digital on later releases, but the laserdisc video itself was always analog [23:36:07 CET] <Tatsh> that was a big deal because most VHS decks didn't even support Dolby anything [23:36:24 CET] <Tatsh> and even for VHS, very few films came with high quality audio, even hi-fi was relatively rare [23:36:26 CET] <faLUCE> ok thnks [23:36:37 CET] <Tatsh> where hi-fi means stereo [23:36:44 CET] <alexpigment> i have some really high end VHS decks at home from doing A>D conversions. i don't know if they did anything crazy with audio [23:36:45 CET] <furq> faLUCE: install libasound2-dev before rebuilding if you're on a debian-alike [23:36:57 CET] <Tatsh> most TVs in the US at that time were mono anyway [23:37:05 CET] <Tatsh> alexpigment, same here [23:37:08 CET] <alexpigment> tatsch - if you're talking about when laserdisc first came out, then yeah [23:37:08 CET] <Tatsh> but i have at least a hum remover [23:37:17 CET] <alexpigment> i actually have an HD VCR [23:37:23 CET] <alexpigment> and one or two tapes [23:37:25 CET] <TehEpikDuckeh> Hey guys, having an issue using "hevc_cuvid" and encoding to h264 using "h264_nvenc". I get the error as follows: "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height" [23:37:31 CET] <furq> is that d-vhs [23:37:38 CET] <Tatsh> i have one deck for A-D and a TBC [23:37:38 CET] <alexpigment> yep [23:37:42 CET] <Tatsh> and a hum remover [23:37:59 CET] <furq> you should get a vhd player as well [23:38:00 CET] <alexpigment> teh: yeah i think you have to specific another parameter like -look_ahead 0 or something [23:38:06 CET] <kepstin> huh, so laserdisc is encoded with pulse-width-modulation representing the analog signal. neat. [23:38:07 CET] <alexpigment> lemme see if i have that error in my notes [23:38:14 CET] <TehEpikDuckeh> Sorry, let me send you the commands I used. [23:38:32 CET] <Tatsh> i use the happauge ImpactVCB-e for capturing [23:38:45 CET] <faLUCE> furq: all done. Well, I just checheck that in LOCALHOST, if I do: "ffmpeg -f alsa -i plughw:2,0 -listen 1 -acodec mp2 -f mpegts http://localhost:8080/stream.ts" and try to receive the stream with ffplay, ffplay has a delay of some seconds. Is there a way to reduce this delay ? [23:38:50 CET] <alexpigment> tatsh - yeah i have several TBC VCRs, panasonic and JVC [23:38:55 CET] <furq> shrug [23:39:01 CET] <Tatsh> in general i spent about $600 for AD conversions for my VHS [23:39:05 CET] <alexpigment> tehepikduckeh: lay it on me [23:39:20 CET] <TehEpikDuckeh> alexpigment: Alright, here's the paste: http://pastebin.com/n9tfv96e [23:39:24 CET] <feliwir> i read everywhere that a vp6 decoder is easy, but it is pretty difficult :( [23:39:25 CET] <Tatsh> is there such a thing as playing a VHS at like 4x the speed and capturing it? [23:39:29 CET] <TehEpikDuckeh> alexpigment: The command is first line. [23:39:39 CET] <Tatsh> like, if you play a tape at 4x speed (~120 FPS) and record at 120 FPS [23:39:40 CET] <faLUCE> if I stream a file, there's not any delay when receiving it [23:39:47 CET] <Tatsh> i'm just wondering if such equipment exists [23:39:55 CET] <feliwir> i am trying to write on in C# but Huffman, IDCT and so on is very complicated [23:40:12 CET] <TehEpikDuckeh> Tatsh: I think that'd give you 4 different frames per frame, because of how VHS reads the tape. [23:40:23 CET] <Tatsh> yeah that's the problem [23:40:26 CET] <TehEpikDuckeh> Tatsh: ... that'd be if you were going at 120 fps. [23:40:28 CET] <Tatsh> but how did mass copying work for VHS? [23:40:34 CET] <kepstin> Tatsh: theoretically possible, but i doubt anyone has actually made equipment for it, other than maybe high-speed tape dubbers. [23:40:37 CET] <Tatsh> did they really just play one source to 50 VCRs at the same speed? [23:40:44 CET] <TD-Linux> furq, biggest question is if CLV mode will even accept the pregroove spacing [23:40:47 CET] <Tatsh> at realtime speed * [23:40:59 CET] <feliwir> can anyone take a look if this is a good approach i am going: https://github.com/feliwir/sage/tree/bb22a8e6a62b0f1cbe4383048d430394ffb5dc… [23:41:04 CET] <furq> i thought the biggest question would be how you fit the disc into a cd drive [23:41:28 CET] <Tatsh> TD-Linux, how do you trick your drive into thinking it's a writable disc? [23:41:32 CET] <furq> after all, there's a sticker that says not to take the cover off the drive [23:41:33 CET] <TehEpikDuckeh> Tatsh: I don't know where you live exactly, but you may be able to request the movie/tv show from your local library and rip it. Since it's the same content as VHS, it shouldn't be illegal. [23:41:37 CET] <furq> you wouldn't want to run afoul of a sticker [23:41:42 CET] <TD-Linux> furq, well I'd make a smaller than normal LD. written from the inside out [23:41:51 CET] <Tatsh> TehEpikDuckeh, these are home movies not professional film [23:42:03 CET] <Tatsh> for any of that, i've either bought the dvd or digital [23:42:13 CET] <TehEpikDuckeh> Tatsh: I see. It'd probably be best to record it at normal speeds. [23:42:13 CET] <Tatsh> dvd/bluray/digital [23:42:28 CET] <TD-Linux> Tatsh, copying machines can go faster than realtime, but basically yes [23:42:54 CET] <kepstin> interesting, wikipedia suggests that 12 cm LD was actually something that exists [23:42:56 CET] <TehEpikDuckeh> Tatsh: If it's really important, then you wouldn't want to tape to be damaged. Even though you can fix it, it's not worth it. [23:43:09 CET] <furq> https://upload.wikimedia.org/wikipedia/commons/5/53/CRVDisc.jpg [23:43:11 CET] <furq> oh [23:43:16 CET] <furq> i guess there are writable laserdiscs [23:43:25 CET] <alexpigment> tehepikduckeh: try adding a few parameters. e.g. /var/lib/emby-server/ffmpeg/test/ffmpeg-git/ffmpeg -c:v hevc_cuvid -i /media/HDD/Movies/Whiplash.mkv -c:v h264_nvenc -global_quality 20 -preset slow -profile:v high -level 4.1 -c:a copy test.mkv [23:43:41 CET] <furq> https://upload.wikimedia.org/wikipedia/commons/thumb/1/1f/LaserRecorder.jpg… [23:43:44 CET] <furq> TD-Linux: problem solved [23:43:47 CET] <Tatsh> amazing concept [23:43:48 CET] <furq> i'm sure those are very cheap now [23:43:54 CET] <Tatsh> was laserdisc proposed as a general data storage format? [23:43:56 CET] <TehEpikDuckeh> alexpigment: Hmmm, same exact error as before. [23:44:01 CET] <TD-Linux> furq, yeah those are literal unobtanium [23:44:06 CET] <TD-Linux> and also cheating [23:44:30 CET] <Tatsh> alexpigment, so i guess you saw how horrible VHS quality really can be [23:44:42 CET] <TehEpikDuckeh> alexpigment: There's no difference at all from the "[h264_nvenc @ 0x1f79e40] No NVENC capable devices found" to the "Error while ...". [23:44:54 CET] <furq> Tatsh: looks like they were only used for video editing [23:45:00 CET] <alexpigment> tehepikduckeh: are you sure cuvid and nvenc are supported on your ffmpeg build and also your hardware? [23:45:01 CET] <TD-Linux> kepstin, on CLV you can see the hsync/vsync and scanlines https://people.xiph.org/~tdaede/pics/ld/20170129_0009.jpg [23:45:10 CET] <TehEpikDuckeh> alexpigment: 100% sure. [23:45:17 CET] <alexpigment> do you have recent drivers? [23:45:20 CET] <TD-Linux> on a couple with scrolling credits you can actually read the credits with a microscope :) [23:45:50 CET] <TehEpikDuckeh> alexpigment: It works just fine if I use CUVID and use software encoding, and works just fine w/ "h264_cuvid" to "hevc_nvenc". [23:45:55 CET] <alexpigment> i had to update my nvidia drivers to something fairly recent to get it to work, as i recall. i tested on 600 > 1000 series cards [23:46:06 CET] <TehEpikDuckeh> alexpigment: They are the latest NVIDIA drivers on Debian 8. [23:46:11 CET] <alexpigment> ah debian [23:46:11 CET] <TehEpikDuckeh> Direct from NVIDIA. [23:46:12 CET] <Tatsh> haven't got nvenc to work yet [23:46:23 CET] <alexpigment> i only have experience with NVENC on Win64 [23:46:27 CET] <TehEpikDuckeh> Let me tell you, NVENC wasn't fun when I first was having to compile things. [23:46:35 CET] <Tatsh> haven't really tried it though; gentoo doesn't want to support building nvenc in [23:46:36 CET] <kepstin> Tatsh: wikipedia says sony designed a data laserdisc that could hold >3gb. [23:46:36 CET] <Tatsh> it seems [23:46:46 CET] <Tatsh> so i have to use my own build [23:47:11 CET] <TehEpikDuckeh> alexpigment: I tested this on my friends computer (Win 10), and he has a 1080. If I remember correctly, it worked immediately. [23:47:21 CET] <Tatsh> was it epic? [23:47:23 CET] <BtbN> Tatsh, setting the nvenc useflag is too much? [23:47:47 CET] <TehEpikDuckeh> That 1080 transcoded at 478 fps. [23:47:56 CET] <TehEpikDuckeh> 487 fps* [23:48:07 CET] <Tatsh> BtbN, doesn't seem to work for me and i forget exactly what the syntax means when it has a % on the use flag [23:48:13 CET] <alexpigment> tehepikduckeh: yeah, my 1060 is 300-500 depending on the settings. anyway, maybe there's another problem that i'm not aware of with debian or linux implementations [23:48:20 CET] <BtbN> it means it's new. [23:48:23 CET] <Tatsh> what about 4k? [23:48:29 CET] <Tatsh> anyone tried 4k encoding with nvenc? [23:48:36 CET] <alexpigment> yes [23:48:39 CET] <alexpigment> it's also very fast [23:48:49 CET] <alexpigment> MUCH faster than x264 or x265 [23:49:02 CET] <TehEpikDuckeh> alexpigment: No idea. I've even tried using the backport repository for GPU drivers, but nope.avi when it comes to working. [23:49:06 CET] <alexpigment> in fact, i wish NVENC wasn't so limited, because x265 4K at 10-bit is SLOWWWWWWWW [23:49:09 CET] <Tatsh> the major limitation though is like, no filters? [23:49:13 CET] <kepstin> alexpigment: if it's faster than x264, you just don't have enough cpu cores ;) [23:49:28 CET] <alexpigment> well, i've got 4/8 on this system [23:49:48 CET] <alexpigment> but seriously, NVENC is extremely fast. if speed is your primary concern, i don't know why you'd use x264/x265 [23:49:59 CET] <TehEpikDuckeh> alexpigment: I think it depends on the card you use. Which card you have? [23:50:03 CET] <furq> because speed isn't usually your primary concern [23:50:04 CET] <alexpigment> 1060 [23:50:15 CET] <BtbN> The card doesn't matter. The generation does. [23:50:17 CET] <TehEpikDuckeh> Should work just fine. Weird. [23:50:18 CET] <alexpigment> furq: that was a bit of a joke, but you beat me to it [23:50:22 CET] <Tatsh> i get pretty good speed with my intel 5930k overclocked to 4.2 GHz [23:50:25 CET] <furq> yeah all the 10 series cards have the same nvenc asic [23:50:29 CET] <TehEpikDuckeh> I ask which card as it's easier than thinking about generations and such. [23:50:39 CET] <furq> maybe it'd make a difference to decoding but i can't imagine it'd be significant [23:50:42 CET] <TehEpikDuckeh> Correcct furq [23:51:15 CET] <TehEpikDuckeh> alexpigment: I'm going to try reinstalling the drivers from NVIDIA. [23:51:53 CET] <alexpigment> tehepikduckeh - cool, good luck. i know i've seen the error you mentioned, and i want to say it was driver-related, but it's been a few weeks since i was knee-deep in hardware encoding research [23:51:53 CET] <TehEpikDuckeh> I've asked about this on the Emby forum and someone said the following: "My guess would be that input-output pixel formats don't match and hardware conversion filter should be applied (that is pure speculation)." [23:52:40 CET] <alexpigment> for what it's worth, i think qsv gives the same error if you don't specify -look_ahead 0 [23:52:42 CET] <TehEpikDuckeh> alexpigment: I can also try another build of FFmpeg. How should I go about it: build from source, or someone already have it built so I don't have to waste 15 minutes? [23:52:46 CET] <alexpigment> so perhaps that's what i'm remembering [23:53:10 CET] <TehEpikDuckeh> alexpigment: Where'd I put that at exactly in the command? [23:53:11 CET] <alexpigment> i don't have a linux build [23:53:41 CET] <alexpigment> tehepikduckeh - after the input file, but still, it's specify to intel quicksync. no need to test it on an nvidia machine [23:53:52 CET] <TehEpikDuckeh> I get "Unrecognized option" whenever I use that. [23:54:19 CET] <TehEpikDuckeh> Oh, I see. I wanted to use QSV because it's faster, but a 1050 is SOOO much cheaper than a new mobo/CPU. [23:58:30 CET] <alexpigment> tehepikducken: they can't be used simultaneously either. so if you have an nvidia card, qsv is out [23:58:43 CET] <alexpigment> at least that's how it is on windows [23:59:05 CET] <TehEpikDuckeh> alexpigment: I tried that on my friends computer and saw an error. If I were to get compatible hw, I'd just use QSV. [23:59:08 CET] <alexpigment> and qsv isn't fast in my experience, but then again i haven't tested skylake or newer [00:00:00 CET] --- Tue Mar 7 2017

1 0