Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2018

1 participants
62 discussions

ffmpeg-devel.log.20180330
by burek 31 Mar '18

31 Mar '18

[00:27:55 CEST] <Chloe> Does ffmpeg support mpeg 4 structured audio? [00:28:13 CEST] <Chloe> I just found out about it, looks pretty crazy [00:28:38 CEST] <nevcairiel> probably not [00:29:06 CEST] <nevcairiel> sounds like one of those pipe-dream formats that never saw any use [00:29:08 CEST] <Chloe> Does anything even use it [01:36:33 CEST] <cone-616> ffmpeg 03Martin Storsjö 07master:847190ebd99f: configure: Don't assume an aligned stack on clang on windows [01:36:34 CEST] <cone-616> ffmpeg 03Zhong Li 07master:3d6e76b953af: qsvenc: Fix a typo of FrameRateExtD/FrameRateExtN [01:36:35 CEST] <cone-616> ffmpeg 03Zhong Li 07master:deefca02c275: qsvenc: add the Access Unit Delimiter NAL Unit support [01:36:36 CEST] <cone-616> ffmpeg 03James Almer 07master:7e3c4d029b8e: Merge commit '847190ebd99ffd57dc89bd568a33bf2d5c424129' [01:36:37 CEST] <cone-616> ffmpeg 03James Almer 07master:20608261f781: Merge commit '3d6e76b953afd36e23ef8532b81aea58a6338931' [01:36:38 CEST] <cone-616> ffmpeg 03James Almer 07master:b065c71e9d2a: Merge commit 'deefca02c275ce4bc5ccbee690463ffef81a18b8' [01:42:50 CEST] <cone-616> ffmpeg 03Martin Storsjö 07master:ea2f72a2c14c: configure: Don't assume a 16 byte aligned stack on BSDs on i386 [01:42:51 CEST] <cone-616> ffmpeg 03James Almer 07master:23f447294487: Merge commit 'ea2f72a2c14c67a3b35dac6426d1e3c0fae33fd5' [02:02:50 CEST] <cone-616> ffmpeg 03Ruiling Song 07master:86499771d122: qsv: align surface width/height to 16. [02:02:51 CEST] <cone-616> ffmpeg 03James Almer 07master:be6749c7190e: Merge commit '86499771d1228d8303c8eb6509e20c0caaa02da5' [02:04:17 CEST] <cone-616> ffmpeg 03Diego Biurrun 07master:5292e97c42b0: configure: Document available options for the --toolchain parameter [02:04:18 CEST] <cone-616> ffmpeg 03James Almer 07master:44df2e858889: Merge commit '5292e97c42b05db7ad4e51c1ea756b12fdf721ff' [02:13:16 CEST] <cone-616> ffmpeg 03Diego Biurrun 07master:b9ea301e0247: configure: Use a more sensible suffix for x86 assembly tempfiles [02:13:17 CEST] <cone-616> ffmpeg 03James Almer 07master:3bbec8e7c20b: Merge commit 'b9ea301e02472d0982b0fa0f80294bd95885bde8' [02:17:38 CEST] <cone-616> ffmpeg 03Diego Biurrun 07master:17ee5b0c13bc: configure: Use indirection for the -o assembler flag also for x86asm [02:17:39 CEST] <cone-616> ffmpeg 03James Almer 07master:91bcf0b8cdb3: Merge commit '17ee5b0c13bc17465b71bc9ca1cde9f0eed8b3ff' [02:29:12 CEST] <cone-616> ffmpeg 03Diego Biurrun 07master:8c7554e6a9b1: configure: Add check_x86asm() helper function to simplify some expressions [02:29:13 CEST] <cone-616> ffmpeg 03James Almer 07master:e46fab0f3cfb: Merge commit '8c7554e6a9b126bd6ee5bf80dae9e11e056db2f1' [02:31:13 CEST] <cone-616> ffmpeg 03Diego Biurrun 07master:434b44cd6fb4: configure: Simplify vararg check [02:31:14 CEST] <cone-616> ffmpeg 03James Almer 07master:75bf51ef87f4: Merge commit '434b44cd6fb4bb9a2bf2bb29ef55ce1a315314b8' [02:59:45 CEST] <cone-616> ffmpeg 03Diego Biurrun 07master:2124a97a4998: configure: Drop unused helper function test_cflags_cpp() [02:59:46 CEST] <cone-616> ffmpeg 03Sven Dueking 07master:a2fc8dbae853: Add Haivision SRT protocol [02:59:47 CEST] <cone-616> ffmpeg 03James Almer 07master:a959e38f7a71: Merge commit '2124a97a4998413c7e81539b16b01ef6ac570ea9' [02:59:48 CEST] <cone-616> ffmpeg 03James Almer 07master:a123e576a485: Merge commit 'a2fc8dbae85339d1b418d296f2982b6c04c53c57' [03:08:44 CEST] <atomnuker> jamrial: dude, libsrt wasn't approved for merging by anyone [03:08:49 CEST] <atomnuker> can you revert it? [03:09:47 CEST] <jamrial> atomnuker: neither was every other module merged during the past seven years. i'm not sure what's special about this one [03:10:55 CEST] <atomnuker> well its one company trying to push their NIH protocol and I'm not sure that's what we should be promoting [03:11:29 CEST] <atomnuker> and I'm not the only one who finds the whole srt thing silly [03:12:55 CEST] <jamrial> ok, if others agree we don't want it i'll revert it [03:13:56 CEST] <atomnuker> kierank and tmatth had some opinions about it [03:14:56 CEST] <atomnuker> in fact just revert it now and lets have this discussion on the ML [03:19:19 CEST] <wm4> lol atomnuker learning what merges from libav are [03:19:36 CEST] <wm4> atomnuker: you can send a patch to remove it [03:19:38 CEST] <atomnuker> fine, I guess it can stay until someone responds as well [03:20:21 CEST] <atomnuker> wm4: that's what they might have been but you don't get a carte blanche to do whatever you want because they merged something [03:20:30 CEST] <jamrial> i mean, if it's really disliked by most devs then i'll revert it [03:21:08 CEST] <atomnuker> jamrial: its a proprietary protocol which hadn't had a proper discussion on the ML and against which I expressed disagreement [03:21:14 CEST] <jamrial> i have zero interest about this thing, i just merged it because it was in the queue and it looked like a pretty standard external wrapper [03:21:54 CEST] <atomnuker> well its a bit more than that, now these companies are going to go around NAB yelling "HEY THEY MERGED OUR CRAPPY NIH TCP OVER UDP ITS REAL NOW, GIVE US MONEY" [03:22:30 CEST] <atomnuker> I mean sure its likely it'll become a widely used standard for some kinda wrong reasons [03:23:14 CEST] <atomnuker> ah well, its kinda like some other protocols we support so its alright [03:23:54 CEST] <wm4> jamrial: so far we have 1 devs [03:24:11 CEST] <atomnuker> who has mixed feelings about it [03:26:46 CEST] <jkqxz> It might be an NIHed package of awfulness with the most unhelpful name ever but that doesn't change the fact that a load of people do use it. [03:27:22 CEST] <jkqxz> (It's already in VLC too.) [03:27:59 CEST] <wm4> lol really [03:28:17 CEST] <wm4> does any site use it? or is it outside of that use case [03:28:38 CEST] <jkqxz> So while it's pretty nasty I don't really think there are grounds for not having it unless there are actual technical objections to the wrapper. [03:28:38 CEST] <atomnuker> vlc will literaly take any wrapper you send patches for [03:28:39 CEST] <atomnuker> they still have a daala one [03:31:56 CEST] <atomnuker> wm4: its not that type of protocol, maybe some websites would use it if it becomes an IETF standard but until then its point to point for programs that support it [03:33:28 CEST] <atomnuker> and its probably not going to become an IETF standard because the IETF still has a few sane people who'll see that the companies who are part of the alliance still hold rights over the patents [03:35:35 CEST] <atomnuker> so as far as I can tell its not really royalty free unlike aom [03:36:00 CEST] <JEEB> I think the two "pro" protocols that popped up recently were NDI (?) and SRT [03:36:49 CEST] <JEEB> and don't we actually have NDI merged already? since I learned of it on #ffmpeg when someone was asking why nobody distributes it in binaries [03:37:02 CEST] <JEEB> (because people want GPL components and Newtek NDI is closed source) [03:37:09 CEST] <JEEB> -> nonfree [03:37:19 CEST] <JEEB> it even has the balls to call it a "standard" [03:37:22 CEST] <JEEB> https://www.newtek.com/ndi/ [03:37:22 CEST] <cone-890> ffmpeg 03James Almer 07master:c42c99c3e5ac: avcodec/libaomenc: use av_assert0() [03:54:02 CEST] <atomnuker> JEEB: we have ndi but isn't that for actual devices? [03:54:10 CEST] <atomnuker> like capture cards [04:20:05 CEST] <philipl> wm4: You happy with the updated movtextenc diff I posted? [04:21:34 CEST] <wm4> philipl: yeah [04:21:45 CEST] <wm4> at least it looks right [05:19:36 CEST] <atomnuker> sent a +3000 line patchset for Vulkan support if anyone's interested [05:38:35 CEST] <jamrial> atomnuker: if it needs the latest Vulkan api, shouldn't the configure check make sure of that? [05:40:02 CEST] <jamrial> either VK_API_VERSION_1_0 or VK_HEADER_VERSION >= $version, whichever works best [05:44:05 CEST] <philipl> wm4: Thanks. I tested it. [05:47:39 CEST] <atomnuker> jamrial: yeah, I was wondering how to do that using check_lib, thanks [05:49:43 CEST] <jamrial> atomnuker: you can use check_cpp_condition() for it [05:51:55 CEST] <jamrial> like, check_lib ... && check_cpp_condition vulkan vulkan/vulkan.h "VK_HEADER_VERSION >= 65" [05:52:24 CEST] <jamrial> also, move it to the correct section, same as opencl and most external deps [05:54:39 CEST] <jamrial> actually, test_cpp_condition ... || die "custom error message" [05:54:40 CEST] <jamrial> much like opencl [05:55:36 CEST] <cone-890> ffmpeg 03Philip Langdale 07master:af043b839c38: movtextenc: fix handling of utf-8 subtitles [10:01:04 CEST] <liyou> what is the mean of 'last_vis_time'? [10:02:47 CEST] <liyou> anyone there? [10:16:51 CEST] <cone-586> ffmpeg 03Paul B Mahol 07master:91bb87137673: avcodec/mpc8: check for overread first [10:16:52 CEST] <cone-586> ffmpeg 03Paul B Mahol 07master:0b86ea03d841: avcodec/ac3: fix out of array access introduced previously [10:20:03 CEST] <cone-586> ffmpeg 03Paul B Mahol 07master:9b22417de680: fate: add eac3_core bitstream filter test [12:02:36 CEST] <cone-586> ffmpeg 03Carl Eugen Hoyos 07master:11f8f9547dbf: fftools/ffmpeg: Remove an unused variable. [13:01:45 CEST] <cone-586> ffmpeg 03Paul B Mahol 07master:cc402282551d: avcodec/mpc8: check for overread earlier and abort decoding frame [13:01:46 CEST] <cone-586> ffmpeg 03Paul B Mahol 07master:e30a37e95e43: avcodec/mpc8: get frame output buffer right before it is actually needed [15:00:28 CEST] <jya> anyhow with access to a h264 analysing tool? wondering what's with the encoding of this file: https://raw.githubusercontent.com/jyavenard/htmltests/master/mediatest/frag… [15:00:40 CEST] <jya> plays fine with ffmpeg, but not Apple Video Toolbox [15:06:09 CEST] <klaxa> atomnuker: carl sent me an email last night stating i definitely need a qualification task, do you know of something that would make sense for me to do? [15:09:49 CEST] <durandal_1707> klaxa: fix mpegts demuxer [15:18:38 CEST] <durandal_1707> or pcm/mlp in mpegps [15:19:41 CEST] <BodecsB> <durandal_1707> I have sent the live switch app into devel mailing list we talked about some days ago [15:19:55 CEST] <durandal_1707> BodecsB: yes, i noticed [15:20:06 CEST] <BodecsB> I revised the code [15:20:22 CEST] <BodecsB> that i originally showed you [15:25:17 CEST] <jya> in that video, the AUD NAL make up for the entire content... never seen that.. why is ffmpeg playing that crap? [15:25:42 CEST] <nevcairiel> AUD NALs have no content, are you sure you're not reading it wrong [15:26:01 CEST] <jya> nevcairiel: I'm fairly sure. [15:27:12 CEST] <jya> the first packet demuxed is a NAL type 9 (AUD) and has a size of 22382 bytes [15:39:39 CEST] <jya> BBB: that looks like a typo in that code: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/vp9block.c#L450 [15:40:13 CEST] <BBB> what is the typo? [15:40:21 CEST] <jya> https://bugzilla.mozilla.org/show_bug.cgi?id=1432857 [15:40:34 CEST] <jya> "(warning) Opposite inner 'if' condition leads to a dead code block." [15:41:04 CEST] <jya> oh sorry, wrong line: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/vp9block.c#L471 [15:41:52 CEST] <BBB> oh, and 464 also [15:41:53 CEST] <BBB> yes [15:42:01 CEST] <BBB> these two leading if statements can probably be removed [15:42:14 CEST] <jya> line 490 and 502 are also there [15:42:26 CEST] <jya> if 490 is true, then you can never get to 502 [15:42:55 CEST] <BBB> you will need some testing to verify results are the same [15:42:57 CEST] <BBB> but yes, possibly [15:43:11 CEST] <jya> well, if "if (td->left_intra_ctx[row7]) {" is true [15:43:25 CEST] <jya> you can never end up in a else where you would need to test if (td->left_intra_ctx[row7]) { again [15:43:46 CEST] <jya> that's just me glancing at the code, with no clue what it's doing :) [15:44:37 CEST] <BBB> 502 is duplicate, yes [15:44:54 CEST] <BBB> I was thinking more of structuring 491 like the block earlier on, as part of the have_l/a condition [15:44:56 CEST] <BBB> and then remove both [15:44:59 CEST] <BBB> but I dont think you can do that [15:45:39 CEST] <BBB> all this stuff is really weird [15:45:44 CEST] <BBB> please submit patch :) [15:45:54 CEST] <BBB> I think youre right, yes, and a simple patch is probably best [15:46:01 CEST] <BBB> to just remove the dead code blocks [15:46:03 CEST] <BBB> 3x2lines [16:44:27 CEST] <atomnuker> durandal_1707: fine, if you want something more interesting you get something more interesting [16:44:33 CEST] <atomnuker> here's a chromatic aberration filter as promised [16:54:28 CEST] <durandal_1707> atomnuker: nice [17:10:03 CEST] <atomnuker> jya: that's messed up [17:10:16 CEST] <atomnuker> you want accessors for every single avctx member? [17:10:33 CEST] <jya> atomnuker: well yes :) [17:10:46 CEST] <nevcairiel> jya: looks like its one of those crazy files where someone muxed h264 annexb into mp4 but blindly assumed that every packet contains only one NAL, find the muxer tht did this and yell at them [17:11:58 CEST] <jya> atomnuker: right now, to support different version of libavcodec (all the way from 53!!) we have a bit of a hacking method using multiple includes for each version, and different class of the loader, so that the ABI mostly work with an independent code. [17:12:05 CEST] <atomnuker> jya: well you can't have 'em, we keep a stable ABI for your convenience and our pain [17:12:34 CEST] <BBB> jya: I think weve tried accessors in the past and they were largely disliked [17:12:34 CEST] <atomnuker> more than 2 years in between breaking is sufficient [17:12:43 CEST] <jya> I'd like to stop doing so in 58... So we can have a single code, the will support multiple future version of libavcodec [17:13:39 CEST] <jya> the current 58, width/height have moved for example... that's okay, there's an accessor [17:13:55 CEST] <nevcairiel> between different major versions, fields arent the only thing that can change, so can constants [17:13:57 CEST] <jya> but some don't.. I didn't make a long list :) [17:14:03 CEST] <nevcairiel> its not something we will invest in our codebase to support [17:14:21 CEST] <nevcairiel> thats the entire point of changing the major version, its inherently incompatible [17:14:47 CEST] <jya> nevcairiel: it's very messed up that video, but ffmpeg plays it, which makes chrome play it... And now I have people whining that chrome can play their video when firefox can't [17:15:22 CEST] <nevcairiel> we try to play files if its not too huge of a hack to do so, and this wasnt [17:15:53 CEST] <jya> nevcairiel: but the issue isn't just a matter of major version, depending on define, the structure can change... so you can't guarantee what the ABI will be [17:16:25 CEST] <nevcairiel> so build against the header file that comes w ith the library [17:16:28 CEST] <nevcairiel> its not rocket science [17:16:48 CEST] <nevcairiel> (also, anyone that publicly ships a library with any of those defines set is probably out for a world of pain) [17:17:11 CEST] <nevcairiel> they are a development tool, not flags for users to change, really [17:17:33 CEST] <jya> nevcairiel: it is unfortunately not possible to ship multiple version of our code, for all version of ffmpeg lib out there. [17:17:45 CEST] <jya> and we can't ship our own copy of ffmpeg [17:17:59 CEST] <nevcairiel> and its not possible for us to accomodate such requirements [17:18:02 CEST] <jya> obviously that would have been my preferred solution [17:18:02 CEST] <nevcairiel> so guess we're stuck [17:18:49 CEST] <jya> you find that the 4 fields I mentioned are unreasonable to provide? [17:18:58 CEST] <jya> (I can do without opaque) [17:19:14 CEST] <jya> I'm happy to submit a patch for those 4 [17:19:29 CEST] <nevcairiel> basically, yes, since we're actively working in the opposite direction [17:19:53 CEST] <jya> and what direction is that? [17:20:12 CEST] <nevcairiel> less accessors, cleaner structs without half-private fields and the like [17:20:31 CEST] <jya> whenever in the past I had mentioned about ABI , the answer as always : use AVOptions, and now you're telling me , don't use AVOptions... can't win [17:21:02 CEST] <nevcairiel> you're free to use avoptions, but those fields there probably dont work through the option api [17:21:09 CEST] <nevcairiel> because its complex data [17:21:12 CEST] <jya> if you guys can't even make your mind about what direction to use or if that fluctuate from one month to the next [17:23:08 CEST] <jya> when is 58 version going to be stable? I'd like to add support for this version and not having to rush because suddenly libavcodec.58 is out. [17:31:41 CEST] <jya> nevcairiel: for the record, this was our bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1435212 [17:55:59 CEST] <jdarnley> https://gitlab.com/J_Darnley/ffmpeg/commits/vc2enc_new_transforms2 [17:56:45 CEST] <jdarnley> kierank: do you know anyone else who might be able to find the issue at the top of the planes? [17:57:10 CEST] <kierank> nope, i can look maybe at the weekend [18:00:09 CEST] <jdarnley> okay, here is an easy way to see the problem [18:01:45 CEST] <jdarnley> ./ffmpeg -f lavfi -i 'testsrc2=hd720, format=yuv422p10' -vframes 1 -vcodec vc2 -wavelet_type 5_3 -y temp.mov [18:03:11 CEST] <jdarnley> ./ffplay -f lavfi 'movie=temp.mov [a]; testsrc2=hd720, format=yuv422p10 [b]; [a][b] blend=all_mode=differencemax:shortest=1' [18:25:30 CEST] <JEEB> was there anyone here versed in how sub2video is designed to work? [18:26:54 CEST] <JEEB> as O [18:27:42 CEST] <JEEB> as I'm not sure which way something should be improved in it to fix overlaying of subtitles after a filter chain re-init/config [18:29:58 CEST] <JEEB> I have one fix, which seems to break the weirdly VFR FATE test (although I do not change the fact that the nullptr packets get pushed forward). then I have two alternative places to stop unwated PTS=INT64_MAX packets from going into the overlay input at all, which doesn't seem to break the FATE test, but on the other hand not sure at which level I should be stopping them [18:49:37 CEST] <jamrial> durandal_1707: want me to add a test for the new eac3 file? similar to the other four existing tests [18:49:52 CEST] <durandal_1707> JEEB: i just fixed 3years old mpeg-ps bug report, so you can do it too [18:50:07 CEST] <durandal_1707> jamrial: that needs pcm file? [18:50:09 CEST] <jamrial> assuming the decoded output is ok and will (hopefully) not change, to avoid having to upload a new .pcm file in the future [18:50:10 CEST] <jamrial> yeah [18:50:52 CEST] <jamrial> durandal_1707: https://pastebin.com/RcPRxkaH [18:51:03 CEST] <durandal_1707> jamrial: go ahead, i have not planned to do it, just because I have no other hw to test [18:51:32 CEST] <JEEB> durandal_1707: I mean I already fixed my sample ages ago :D [18:51:45 CEST] <JEEB> and it works just fine in a 24/7 stream seemingly [18:51:49 CEST] <jamrial> i created the .pcm file on an x86_32 build using no asm functions, so it's all x87 floats [18:52:09 CEST] <JEEB> durandal_1707: basically http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227598.html [18:52:31 CEST] <JEEB> my initial fix didn't change the fact that the subtitle update thing gets pushed to the end [18:52:55 CEST] <JEEB> just that it no longer can push nullptr AVSubtitles which would end up being INT64_MAX [18:53:07 CEST] <JEEB> because that would EOF the filter input [18:53:23 CEST] <JEEB> then there's of course just not pushing those packets out, and there's two possible places to do that at [18:58:32 CEST] <durandal_1707> JEEB: if output of subtitle overlaying is same before and after your patch i see nothing wrong [18:59:14 CEST] <JEEB> with normal stuff it doesn't seem to do anything wrong, although I've only visually verified it with the sample I have [18:59:18 CEST] <JEEB> the test is weirdly VFR and low frame rate [18:59:30 CEST] <JEEB> like, I would expect CFR from a rawvideo source at a set frame rate [19:00:16 CEST] <JEEB> and yes, the test drops one overlayed subtitle at the 5fps mark, but I don't know where the issue is. is it my patch, or is it some underlying issue that my patch is bringing up while fixing something else [19:02:54 CEST] <durandal_1707> JEEB: have you checked is it because pts is now something else? [19:03:39 CEST] <JEEB> I could add some logging at the timestamps of AVFrames pushed into / received from the filter chain, but the primary input is not changed at all with this [19:04:28 CEST] <atomnuker> jkqxz: could you make vaapi drm exporting swap U and V planes for yuv420p? [19:08:54 CEST] <cone-586> ffmpeg 03James Almer 07master:53937c437105: fate: add test for eac3 dependant stream [20:33:56 CEST] <kierank> jamrial: ? [20:34:07 CEST] <kierank> why do I get things I don't have on my system autodetected [20:34:20 CEST] <nevcairiel> you dont anymore anyway [20:34:28 CEST] <nevcairiel> the headers are now required to be installed [20:34:37 CEST] <jamrial> yeah, with nvidia stuff it should be disabled now unless you have the external headers [20:34:47 CEST] <kierank> for cuivid and the other one? [20:34:49 CEST] <kierank> there were two iirc [20:34:58 CEST] <jamrial> yes [20:35:03 CEST] <kierank> ok great [20:45:17 CEST] <cone-586> ffmpeg 03James Almer 07master:f6171471e6cf: avcodec: rename the AV1 profiles [20:45:18 CEST] <cone-586> ffmpeg 03James Almer 07master:ea3320bb8285: libaomenc: fix profile setting [20:45:19 CEST] <cone-586> ffmpeg 03James Almer 07master:0ac379863231: Merge commit 'ea3320bb828553182fb34e164826f95df5743522' [20:47:04 CEST] <cone-586> ffmpeg 03Diego Biurrun 07master:e744281c4949: configure: Revert some incorrect uses of check_cc() [20:47:05 CEST] <cone-586> ffmpeg 03James Almer 07master:05a1ec3374c6: Merge commit 'e744281c49496b0e0a357e9f84c37fbf99215e20' [20:48:55 CEST] <cone-586> ffmpeg 03Martin Storsjö 07master:ab05d3934de8: arm: vc1dsp: Add commas between macro arguments [20:48:56 CEST] <cone-586> ffmpeg 03Martin Storsjö 07master:3a7b4ae62c79: arm: Produce .const_data instead of .section .rodata for Mach-O [20:48:57 CEST] <cone-586> ffmpeg 03James Almer 07master:a7109b82c4ab: Merge commit 'ab05d3934de8e932dbd77979a687e6598e67535c' [20:48:58 CEST] <cone-586> ffmpeg 03James Almer 07master:33bd2b99a1c2: Merge commit '3a7b4ae62c798edbd82bcd8fef863c74ed2acd4a' [20:58:33 CEST] <JEEB> has anyone her tested compilation with NDK r17 yet? [20:58:46 CEST] <JEEB> it seems like some ARM SIMD stuff starts failing to compile [21:09:19 CEST] <wbs> JEEB: I have patches for exactly that coming up [21:09:24 CEST] <JEEB> ah [21:09:49 CEST] <wbs> JEEB: that change has been in upstream llvm since may last year [21:10:04 CEST] <JEEB> oh, so it's not a toolchain bug but rather we're using something incorrectly? [21:10:16 CEST] <JEEB> was about to go derp at NDK devs [21:10:23 CEST] <wbs> it's much more subtle [21:10:59 CEST] <wbs> previously the clang built-in assembler was pretty limited, and the arm assembly requires support for the "altmacro" feature (which only the arm assembly requires, not the aarch64 assembly) [21:11:28 CEST] <wbs> in may last year, it grew support for altmacro, so now configure concludes that it can run clang's assembler directly without needing gas-preprocessor [21:11:35 CEST] <JEEB> aaah [21:11:46 CEST] <JEEB> didn't notice it disabling gas-preproc :) [21:11:51 CEST] <wbs> but then it fails over due to a few other fringe features that clang doesn't support and probably won't [21:12:43 CEST] <JEEB> right [21:12:47 CEST] <wbs> see 59cee42d7d22530e66a155305389e29679b11f78 and d7320ca3ed10f0d35b3740fa03341161e74275ea for related changes in libav [21:14:47 CEST] <wbs> JEEB: out of the 3 changes sent, 1/3 probably is the one you need. the other two are needed for ios targets only [21:15:21 CEST] <wbs> (when targeting apple platforms, clang disables a few more fringe features in the assembler, probably since they conflict with the legacy apple gas macro system) [21:19:19 CEST] <JEEB> sounds nice enough [21:19:28 CEST] <JEEB> cheers for the heads-up [21:23:44 CEST] <wbs> (now the patches made it through the ML) [21:24:17 CEST] <durandal_1707> lol, the aic decoder gave incorrect output all the time, even fate ref files are wrong [21:26:49 CEST] <jamrial> well, fate tests make sure the output is the intended, not that the intended output is correct :p [21:27:17 CEST] <njtze> .-. .-. [21:27:21 CEST] Last message repeated 2 time(s). [21:27:21 CEST] <njtze> / \ / \ [21:28:00 CEST] Last message repeated 2 time(s). [21:50:50 CEST] <wm4> bunny got cut off [21:51:16 CEST] <wm4> (in at least 1 other channel it was successful and in addition annoyingly highlighted some nicks) [21:54:28 CEST] <thardin> /mode +p helps immensely with the spammers [21:55:17 CEST] <iive> what is +p about ? [21:55:34 CEST] <thardin> hides channel from /whois [21:56:00 CEST] <thardin> assuming this server runs inspircd with that module installed [21:56:15 CEST] <iive> how would this help? [21:56:16 CEST] <sfan5> pretty useless without setting +s too [21:58:57 CEST] <thardin> not what we've found on the local network [23:18:33 CEST] <atomnuker> klaxa: not really having any ideas [23:39:39 CEST] <jamrial> TD-Linux: aom commit 2eee346308dd2e26bce206ed233a5523f7d6ce55 did not remove the enums and related aom_image_t fields in aom_image.h [23:41:20 CEST] <TD-Linux> jamrial, ah whoops I missed that [23:41:30 CEST] <TD-Linux> jamrial, related: https://aomedia-review.googlesource.com/c/aom/+/53703 [23:41:47 CEST] <jamrial> oh nice [23:42:02 CEST] <TD-Linux> I'll do a separate one for the RGB formats [00:00:00 CEST] --- Sat Mar 31 2018

1 0

ffmpeg.log.20180330
by burek 31 Mar '18

31 Mar '18

[00:19:16 CEST] <wfbarksdale> anyone have general advice for creating a pipeline for realtime rendering of an "edited" video? i.e. combining multiple sections of multiple video files together, possibly doing some openGL transformations on frame output. [00:25:56 CEST] <BtbN> OBS? [00:41:41 CEST] <kepstin> wfbarksdale: it's pretty much impossible to say anything "general" about that [00:42:00 CEST] <kepstin> other than that I suppose handling seeking in realtime playback is hard [00:42:40 CEST] <wfbarksdale> yeah, I am thinking that AVStream is kind of the right entry point, and I keep an AVStream for each "clip" (read videofile + startTime + endTime) [00:43:10 CEST] <wfbarksdale> for realtime playback, the AVStream keeps its start frame buffered [00:45:34 CEST] <wfbarksdale> (working with C API) [00:54:43 CEST] <wfbarksdale> will it be a problem to keep 2 AVStreams to the same video file and use them independently? [04:27:34 CEST] <s5lt> hello [04:30:20 CEST] <s5lt> Hello, I am trying to install FFmpeg-SIXEL and when I do "./configure --enable-libquvi --enable-libsixel" I get an error saying neither are found and it will use pkg-config. However I have both installed. Does anyone know what could cause this error [04:33:53 CEST] <DHE> maybe you need to set PKG_CONFIG_PATH... /usr/local/lib/pkg-config is a common path to set when installing dependencies which are themselves built from source [04:49:28 CEST] <s5lt> 1:m #ffmpeg Hello? [04:54:23 CEST] <s5lt> are you receiving me? [04:55:03 CEST] <DHE> yes... [04:57:27 CEST] <s5lt> sorry just new to IRC stuff [04:57:52 CEST] <s5lt> does any one here know anything about FFmpeg-SIXEL [05:00:14 CEST] <DHE> I gave a (generic) suggestion above [05:05:34 CEST] <s5lt> Thanks, I think I am going to use an alternative [08:32:17 CEST] <brimestone> hello, has anyone tried to send an ffmpeg output to an s3 bucket? [09:59:58 CEST] <random-drop-in> hello? [11:03:49 CEST] <electronorbitals> When will av1 be supported by ffmpeg [11:04:11 CEST] <pmjdebru1jn> encode or decode? [11:06:02 CEST] <ritsuka> the av1 encoder is still a big work in progress, right now it's quite slow [11:06:19 CEST] <pmjdebru1jn> electronorbitals: ..V.L. av1 Alliance for Open Media AV1 [11:06:28 CEST] <pmjdebru1jn> so git already has it [11:07:03 CEST] <pmjdebru1jn> oh wait [11:07:27 CEST] <pmjdebru1jn> DE aren't tagged yet [11:07:31 CEST] <pmjdebru1jn> so I guess it doesn't work yet [11:09:20 CEST] <durandal_1707> pmjdebru1jn: you need aom lib [11:09:30 CEST] <pmjdebru1jn> ah :) [11:15:24 CEST] <zyme> What about JEM previews, any methods on using /testing that? [12:57:30 CEST] <meins> Hello [12:57:43 CEST] <meins> Can someone helps me with the avformat_find_stream_info function? [12:58:22 CEST] <meins> I will use ffmpeg for online Streaming but this function Needs too much time to Change from one to the other Stream. [16:32:49 CEST] <killown> does ffmpeg already support https://en.wikipedia.org/wiki/AV1 ? [16:33:28 CEST] <Mavrik> Not internally. [16:33:40 CEST] <Mavrik> AV1 was not standardized until like a few days ago. [16:33:54 CEST] <Mavrik> It does support libaom I think [16:33:57 CEST] <killown> Mavrik, how could I enable this codec? [16:34:47 CEST] <killown> can this really reduce 40% of the size [16:36:17 CEST] <killown> it will speed up the internet a lot [16:41:40 CEST] <JEEB> killown, Mavrik: AV1 support through libaom is in FFmpeg now. but as far as I know the format is /still/ not frozen [16:41:57 CEST] <Mavrik> Ah. [16:41:59 CEST] <JEEB> the PR piece they put out a few days ago was not managed with the technical folk at AOM [16:42:06 CEST] <JEEB> it's because of NAB most likely [16:42:09 CEST] <Mavrik> I didn't read the PR piece :) [16:42:20 CEST] <killown> browsers doen't support av1 yet, [16:42:22 CEST] <Mavrik> Any deadlines for AV1 standardization? [16:42:27 CEST] <JEEB> https://news.ycombinator.com/item?id=16699481 [16:42:52 CEST] <JEEB> killown: both chromium and firefox added it up so it will hit stable within one-two releases. the primary issue is that the format is not yet frozen [16:43:10 CEST] <JEEB> Mavrik: I heard from someone that there was supposed to be a final crunch on the spec right about now [16:43:18 CEST] <JEEB> until the beginning of april or so [16:43:49 CEST] <killown> JEEB, 2020 will be the year to use it maybe? because there are lots of people using old browsers yet [16:44:27 CEST] <JEEB> whenever the ecosystem becomes good enough for it [16:45:02 CEST] <JEEB> I wouldn't be surprised if some vendors started pushing out VoD video in AV1 for those devices / apps that can support it quicker, like GOOG most likely [16:45:16 CEST] <JEEB> also netflix has been very interested in AV1 as far as I can see. [16:46:01 CEST] <Mavrik> It'll take a bit for everything to catch up tough. [16:46:04 CEST] <Mavrik> Couple of years? [16:46:07 CEST] <JEEB> sure [16:46:11 CEST] <Mavrik> For initial support [16:46:35 CEST] <Mavrik> I wonder if YT guys will drop the annoying VP9.2 requirement for HDR and use AV1 instead. [16:47:12 CEST] <JEEB> as soon as the encoders get usable for some use cases I will guess some sort of adoption will start, and then with time the amount of devices/apps getting AV1 will rise. but the starting point is "usable encoder" [16:47:25 CEST] <transcodeine> Hey JEEB- thanks for the help on ffmpeg stuff days ago [16:47:26 CEST] <JEEB> right now IIRC there's one encoder that's slow as hell and another encoder that's fast as hell but doesn't compress well :D [16:48:01 CEST] <JEEB> and BBB of course is trying to find a business hole for himself so most likely he's making Eve2 for AV1 :P [16:48:27 CEST] <Mavrik> I'd say that we need HW decoders first ? [16:48:42 CEST] <Mavrik> Considering the fact that huge amount of media is watched on mobile/STB platforms. [16:48:56 CEST] <Mavrik> No idea if morern HW video decoders can be reused to accelerate AV1 [16:49:11 CEST] <JEEB> that hasn't stopped VP9 adoption on certain places, and as I noted it will take time for the share of AV1 usage for various devices to rise [16:49:34 CEST] <JEEB> so you will serve the stuff those devices can take for as long as needed [16:49:56 CEST] <JEEB> they did keep some stuff the same as VP9 because the hw people threw a fit [16:50:02 CEST] <JEEB> so most likely they can re-use some tools [16:50:07 CEST] <JEEB> but not a full decoder [16:50:20 CEST] <kiloreux> I am trying to encode a file with libaom-av1 codec but it's super slow. Over 7 minutes for 400kb video and still going. Any idea ? [16:50:27 CEST] <JEEB> it is slow [16:50:30 CEST] <JEEB> like super, super slow [16:50:30 CEST] <kepstin> kiloreux: working as expected [16:50:39 CEST] <JEEB> I mean, they're using it to test the tools [16:50:47 CEST] <JEEB> as in, "how much compression can we get out of this feature" [16:50:52 CEST] <JEEB> before optimizing for speed [16:50:59 CEST] <kepstin> that's typical of reference encoders made during spec development [16:51:03 CEST] <JEEB> yup [16:51:10 CEST] <JEEB> rav1e is the one that has been made to validate the spec [16:51:19 CEST] <JEEB> and that one went over 1000fps on HD last I checked [16:51:20 CEST] <JEEB> lol [16:51:26 CEST] <JEEB> but that is not a high compression encoder [16:51:40 CEST] <kiloreux> kepstin, JEEB , wonderful information. Thank you very much. [16:52:02 CEST] <JEEB> but yea, even if you encode AV1 now [16:52:07 CEST] <JEEB> you might not be able to decode it tomorrow [16:52:12 CEST] <JEEB> (with tomorrow's libaom) [16:52:13 CEST] <kepstin> keep in mind also that the bitstream format isn't finalized, yeah [16:52:19 CEST] <kepstin> what JEEB said :) [16:52:42 CEST] <kepstin> (I'd expect it's probably pretty close at this point, tho) [16:52:45 CEST] <JEEB> yes [16:52:52 CEST] <JEEB> since I heard people talk about the last crunch and all [16:53:26 CEST] <Mavrik> So, since I wasn't following, what made people adopt AV1 but not VP9? [16:54:13 CEST] <JEEB> HEVC being a mess [16:54:25 CEST] <JEEB> not format-wise but the companies deciding they wanted a bigger cut out of licensing [16:54:36 CEST] Action: JEEB actually liked a lot of the sane'ification in HEVC [16:54:45 CEST] <JEEB> Mavrik: the best part was when apple joined AOM [16:54:53 CEST] <JEEB> since usually apple goes the exact opposite [16:55:10 CEST] <kepstin> there's, what, 3 patent pools and at least 2 individual licensors involved in hevc? that we know of, so far. [16:55:12 CEST] <azarus> HEVC is included in macOS? [16:55:17 CEST] <Mavrik> Yeah, I'm familiar with HEVC craziness [16:55:18 CEST] <azarus> so why do they need AV1? [16:55:27 CEST] <Mavrik> JEEB, that actually surprised me a lot [16:55:33 CEST] <Mavrik> since Apple very publicly pushed HEVC [16:55:36 CEST] <Mavrik> and then joined AOM [16:55:42 CEST] <kepstin> the weirdest bit is how Apple is listed as a "founding member" [16:55:51 CEST] <JEEB> that's a level of membership I bet [16:55:54 CEST] <JEEB> not age thing [16:55:55 CEST] <JEEB> lol [16:56:10 CEST] <JEEB> so they joined with the bigger contribution level or so [16:56:33 CEST] <Mavrik> Giving apple the founding member title in exchange for them supporting the format seems like a cheap trade :P [16:58:08 CEST] <JEEB> yea, even if it went like that [16:58:13 CEST] <JEEB> it's good to have them on board [16:58:59 CEST] <JEEB> also I don't really care if corps joined AOM to have a plan B or leverage on the HEVC situation, it's still a show of interest towards having such formats like AV1 [16:59:33 CEST] <JEEB> and AV1 is the next-gen right now, while HEVC is already current gen :) so in that sense "they already have HEVC so why would they want AV1?" gets explained [16:59:44 CEST] <JEEB> companies want to have an alternative at the very least for the next format [18:24:24 CEST] <tansa> hello, where do i download the latest Libavfilter ? [18:24:42 CEST] <JEEB> it's part of FFmpeg [18:24:52 CEST] <JEEB> so you build FFmpeg and one of the libraries you get is libavfilter [18:24:59 CEST] <tansa> i see, thank you [18:25:09 CEST] <JEEB> np [18:25:34 CEST] <tansa> because i was using the command fade=t=in:st=5.5:d=0.5 from the documentation .. and it's saying its not correct [18:25:48 CEST] <tansa> i immagined it's the library .. am i right ? [18:25:58 CEST] <JEEB> unless seomeone disabled that filter, yes [18:26:11 CEST] <tansa> ok [18:28:05 CEST] <tansa> sorry for bothering, but is there a way to fade in the first 2 seconds of the video without rebuilding ffmpeg ? [18:30:08 CEST] <tansa> i'm using it like this and it's giving an error [18:30:11 CEST] <tansa> ffmpeg.exe -i "wonder.mp4" -vf 'fade=t=in:st=5.5:d=0.5' -c:a copy -c:v libx264 -f mpegts udp://127.0.0.1:1234?pkt_size=1316 [18:30:35 CEST] <JEEB> post the full console output with -v verbose onto a pastebin or gist [18:30:36 CEST] <JEEB> and link here [18:30:54 CEST] <DHE> that's probably not going to go very well... mpegts over udp all over again... [18:31:16 CEST] <JEEB> well that shouldn't fail in lavfi [18:31:43 CEST] <JEEB> so if the error is in lavfi filter chain creation then I don't care about the unicast going wee-wee [18:34:17 CEST] <tansa> https://pastebin.com/UjCa0uY7 [18:34:55 CEST] <tansa> what shall i use instead of mpegts for streaming over udp ? [18:35:54 CEST] <TD-Linux> rav1e is now quite a bit slower, but still not any good :) [18:36:27 CEST] <JEEB> tansa: for some reason it's parsing your whole fade thing is a single filter name? [18:36:37 CEST] <JEEB> at least that's who I take No such filter: 'fade=t=in:st=5.5:d=0.5' [18:37:00 CEST] <tansa> im streaming to a scrambler and i'm forced to use udp .. so what other option do i have [18:37:50 CEST] <JEEB> although check if `ffmpeg -filters` returns fade [18:42:21 CEST] <tansa> yes it does [18:42:22 CEST] <tansa> .S. fade V->V Fade in/out input video. [18:42:37 CEST] <tansa> it's working with filter-complex... how weired [18:46:13 CEST] <tansa> but without audio :( [18:46:21 CEST] <tansa> something weired is happening [19:26:17 CEST] <axew3> hello guys, i think to have succesfully install any possible mmpeg library and finally the installer on centos had a start, but when finished, seem that mmpeg executable has been not create, it isn't into usr/bin, nor into any other folder i assume, since find not find out any ffmpe 'green' executable/file. I remember last day i had a folder into home within ffmpeg executable, but i've delete [19:26:17 CEST] <axew3> it. Assuming, that isn't sure, but quite sure, all is installed, how i can resolve this? [19:27:03 CEST] <JEEB> if you compiled FFmpeg then you know what your prefix was [19:27:11 CEST] <JEEB> if you didn't set a --prefix for configure [19:27:15 CEST] <JEEB> then it's /usr/local [19:27:23 CEST] <JEEB> if you set it, then it's what you set [19:27:29 CEST] <JEEB> the binary then goes into <prefix>/bin [19:27:36 CEST] <JEEB> (that is after `make install` [19:29:01 CEST] <axew3> ok i try ... was better i had take a look into shh, before to start 2 days ago ... now i'm quite ok with, but still a newbie [19:29:11 CEST] <axew3> ssh [19:35:04 CEST] <axew3> nothing on /local/bin there are others executable, like, lame, nasm,ndisasm but not mmpeg, the same on usr/bin [19:35:21 CEST] <axew3> ffmpeg sorry [19:35:25 CEST] <JEEB> check ffbuild/config.log [19:35:29 CEST] <JEEB> in your build directory [19:35:43 CEST] <JEEB> that should contain whatever your prefix is [19:35:54 CEST] <JEEB> and if you never ran make install, that will of course mean that the binaries never got installed :P [19:36:30 CEST] <axew3> make install has been done i presume [19:36:53 CEST] <JEEB> so you don't even know? [19:38:17 CEST] <JEEB> but anyways, if you see ffbuild/config.log in the build dir having --prefix set then you know the prefix [19:38:52 CEST] <JEEB> if it's not then it's /usr/local and `make install` just hasn't been run :P [19:43:06 CEST] <axew3> mhh... i'm little confused ... maybe not? only make? [19:43:25 CEST] <axew3> the cat to log file say compilation terminated. [19:43:25 CEST] <axew3> ERROR: libx264 not found [19:43:36 CEST] <axew3> the same of last night [19:43:44 CEST] <axew3> so it has not been changed [19:43:52 CEST] <JEEB> then you never got to compilation :P [19:44:25 CEST] <axew3> ok, before to start cry, i will re-try JEEB! [19:44:46 CEST] <axew3> finally i will pay you to install maybe :) [19:45:27 CEST] <axew3> 2 full days and still nothing [19:45:41 CEST] <axew3> so i will see ... [20:07:47 CEST] <axew3> i've restart so i expect now that make will follow for more then 1 hour to process [20:07:59 CEST] <axew3> like this morning [20:08:33 CEST] <axew3> the command already contain make install after make but maybe wasn't execute [20:09:11 CEST] <axew3> the terminal say in red: C compiler failed test but after start like this morning [20:09:56 CEST] <transcodeine> will ffmpeg allow inbound multicast > outbound unicast to itself on another server across a wan? [20:17:26 CEST] <DHE> it doesn't care. it's a networking thing. [20:21:04 CEST] <axew3> nothing now seem to work finally: i had ffmpeg_g and i had see that install had fail on renaming the file (even i'm not a c programmer) so i've move and rename in /usr/bin into ffmpeg and i've run ffmpeg version ... it return the ffmpeg version now, and not that command not exist so i can assume all is fine finally? [20:21:53 CEST] <JEEB> ffmpeg_g is just the non-stripped version so it's just larger than the "normal" ffmpeg binary [20:22:00 CEST] <JEEB> no idea why the stripping would fail in your case [20:22:23 CEST] <emcoder> Hi, I read in https://trac.ffmpeg.org/wiki/Encode/H.264#twopass about two-pass encoding, and at the end it says "choose the slowest -preset you can tolerate". Should I specify the `-preset` flag in both passes? [20:22:52 CEST] <JEEB> yes [20:22:57 CEST] <JEEB> it's not a flag, it's an option [20:23:13 CEST] <JEEB> also you only want two-pass if you have a specific average bit rate (file size in other words) you want to hit [20:23:52 CEST] <emcoder> Hm, then I don't really need two-pass [20:24:17 CEST] <axew3> it say ffmpeg version N-90489-g759381d Copyright (c) 2000-2018 the FFmpeg developers ... [20:24:23 CEST] <JEEB> if you just have a "quality level" you want to get to [20:24:28 CEST] <axew3> ffmpeg_g is just the non-stripped version so it's just larger than the "normal" ffmpeg binary .... it mean it is not ok? [20:24:38 CEST] <axew3> i should not do it in this way? [20:24:48 CEST] <JEEB> I have no idea why stripping would fail to you but the binary should work [20:24:53 CEST] <JEEB> it's just the one with the debug symbols included [20:25:18 CEST] <axew3> ok ... i'm so happy with this at moment, until not more skilled! [20:25:24 CEST] <JEEB> emcoder: if you just have a quality level you need to hit you use -ss and -t to encode like a few minutes of content that's representative [20:25:32 CEST] <JEEB> and tweak the crf value and preset [20:25:34 CEST] <axew3> if it work, even not so efficetly is ok [20:25:37 CEST] <JEEB> first preset, then crf [20:25:53 CEST] <JEEB> after you've found the slowest preset that is still "fast enough" for your use case [20:25:59 CEST] <JEEB> you start with crf 23 [20:26:08 CEST] <JEEB> then if the result of the test looks bad, you go down [20:26:11 CEST] <JEEB> if it looks good, you go up [20:26:23 CEST] <JEEB> then at some point you will find the highest value that still looks good [20:26:33 CEST] <JEEB> which thus becomes your CRF value for that type of content [20:26:43 CEST] <JEEB> (type, resolution, frame rate) [20:28:53 CEST] <emcoder> That's very helpful, thanks! [20:29:48 CEST] <axew3> JEEB thank you! [21:13:40 CEST] <axew3> to link mmpeg into a wrapper for apache, should i follow this: https://trac.ffmpeg.org/wiki/PHP [21:13:52 CEST] <axew3> or there is something new around? [21:14:09 CEST] <axew3> i need in php [21:14:27 CEST] <axew3> ffmpeg sorry [21:14:36 CEST] <BtbN> what? [21:17:04 CEST] <axew3> hello i've just install ffmpeg into a centos server and now i would like to pass to it streams to convert in mp4, from php [21:19:55 CEST] <axew3> or i could just use exec i assume? [21:20:05 CEST] <axew3> or shell_exec [21:23:29 CEST] <BtbN> Yeah, it's easiest to just run an external process [21:23:36 CEST] <BtbN> but make absolutely sure to sanitize your inputs. [21:23:53 CEST] <BtbN> Putting user arguments into a shell command is otherwise extremely risky. If possible, do not use a shell, but spawn ffmpeg directly. [21:24:39 CEST] <BtbN> "If you want to start an external program without starting cmd.exe use proc_open() with the bypass_shell option set." according to the docs [21:28:50 CEST] <axew3> wow awesome! [21:29:13 CEST] <axew3> this is exactly what was the complete meaning [21:29:13 CEST] <BtbN> seems like even proc_open spawns a shell [21:29:42 CEST] <BtbN> consider dumping PHP while you're at it. There is literally no way to spawn a process directly with it. [21:31:34 CEST] <axew3> deu to my bad eng i've totally underdstand: resuming isn't quite sure to use? [21:32:23 CEST] <axew3> if i let say, trim, passed values before to pass to ffmpeg, isn't sufficient [21:32:28 CEST] <axew3> ?? [21:33:49 CEST] <axew3> http://php.net/manual/en/function.trim.php [21:38:39 CEST] <axew3> i've totally underdstand: WAS i have NOT totally understand ... sorry [21:41:57 CEST] <axew3> p.s bypass_shell (windows only) on php [22:15:40 CEST] <Swervz> Hey anyone know how to fix a video that has the wrong framerate written to the container that has audio desync issues? [22:16:46 CEST] <BtbN> remux the video to raw .h264, and re-mux that back together with the audio, specifying the correct input framerate [22:17:13 CEST] <Swervz> media info says the framerate is 29.970 (30000/1001) and the original framerate is 29.970 (29970/1000) but I'm not sure how I specify the part in the brackets [22:19:55 CEST] <JEEB> pretty sure a lot of things that take in x/y take it as "xxx/yyy" [22:20:11 CEST] <JEEB> but I could be incorrect [22:20:20 CEST] <Swervz> From googling I found results on how to do it for different framerates but I don't understand what that part even means [22:20:50 CEST] <BtbN> it's the exact framerate [22:21:31 CEST] <Swervz> ah okay [22:26:32 CEST] <Swervz> I don't really understand what It means by stream specifier in the documentation [22:29:32 CEST] <furq> Swervz: https://ffmpeg.org/ffmpeg.html#Stream-specifiers-1 [22:30:01 CEST] <Swervz> furq, Oh that's a different site than I was using for docs [22:30:02 CEST] <furq> https://ffmpeg.org/ffmpeg.html#Advanced-options [22:30:06 CEST] <furq> there's some more examples under -map as well [22:30:26 CEST] <Swervz> This one seems to have so much more than the other site I found [22:30:47 CEST] <furq> i should hope so [22:31:25 CEST] <Swervz> Yeah I could only find this one before for some reason https://linux.die.net/man/1/ffmpeg [00:00:00 CEST] --- Sat Mar 31 2018

1 0

ffmpeg-devel.log.20180329
by burek 30 Mar '18

30 Mar '18

[00:00:24 CEST] <nevcairiel> should just work [00:02:06 CEST] <durandal_1707> what about mkvmerge from mkvtoolnix? [00:02:20 CEST] <nevcairiel> no idea. [00:12:12 CEST] <durandal_1707> JEEB: what's so funny with ffmpeg having ocr filter? [00:18:18 CEST] <JEEB> durandal_1707: not funny, I was actually thinking of making one myself if there wasn't one [00:18:34 CEST] <JEEB> I just found myself not having noticed it :P [00:20:52 CEST] <cone-624> ffmpeg 03Marton Balint 07master:60c9a2553041: ffmpeg: fallback to codecpar parameters on input filter eof [00:20:53 CEST] <cone-624> ffmpeg 03Marton Balint 07master:0031eab61c82: ffmpeg: do not finish output streams manually on eof even if no input is provided [00:20:54 CEST] <cone-624> ffmpeg 03Marton Balint 07master:084ef7d7d542: avfilter/af_pan: reject expressions referencing the same channel multiple times [01:32:49 CEST] <cone-624> ffmpeg 03Michael Niedermayer 07master:5c75438b8935: avcodec/tableprint_vlc: Fix build failure with --enable-hardcoded-tables [02:10:30 CEST] <jamrial> atomnuker: ping [02:15:01 CEST] <mypopydev> @jkqxz [02:15:16 CEST] <mypopydev> Hi, Mark [02:16:36 CEST] <atomnuker> jamrial: pong? [02:17:34 CEST] <jamrial> atomnuker: are the av1 profiles the same as vp9? as in, 0 for i420, 1 for i422, i440 and i444, 2 for 0 + high bitdepth, 3 for 1 + high bitdepth [02:21:47 CEST] <atomnuker> jamrial: no, 0 supports 420 at 8 or 10 bits, 1 supports the same but with 444 (!) at 8 or 10 bits and 3 is supports all that + 12 bit support for that + 422 at 8, 10 or 12 bits + monochrom (at 8, 10 or 12 bits) [02:22:11 CEST] <jamrial> 3 or 2 for the last? [02:22:26 CEST] <atomnuker> 3 [02:22:37 CEST] <jamrial> no 2 then? [02:23:00 CEST] <atomnuker> 2 supports 420 @ 8 or 10 and 444 @ 8 or 10 [02:23:32 CEST] <atomnuker> https://aomediacodec.github.io/av1-spec/av1-spec.pdf [02:23:35 CEST] <nevcairiel> 1 is 444 exclusively, and 2 is 0+1? seems like a rather odd choice [02:23:38 CEST] <atomnuker> annex a, page 590 [02:23:52 CEST] <atomnuker> oh damn and blast [02:24:08 CEST] <atomnuker> was looking at the profile names [02:24:25 CEST] <atomnuker> so 1 supports 420 @ 8 or 10 and 444 @ 8 or 10 [02:24:31 CEST] <atomnuker> 0 supports 420 @ 8 or 10 [02:24:36 CEST] <nevcairiel> they named the profiles now anyway [02:24:46 CEST] <Chloe> Why do we have libpostproc? [02:24:48 CEST] <nevcairiel> Main, High, Professional [02:25:08 CEST] <atomnuker> 2 supports 420 @ 8 or 10 or 12 and 444 @ 8 or 10 or 12 and 422 @ 8 or 10 or 12 and GRAY8, GRAY10 and GRAY12 [02:25:26 CEST] <jamrial> mmh, should i remove the i440 references in the decoder wrapper, then? [02:25:32 CEST] <jamrial> the enum values are there in libaom, though [02:25:37 CEST] <nevcairiel> its not mentioned in the profiles anyway [02:25:41 CEST] <nevcairiel> who would use 440 anyway [02:25:48 CEST] <jamrial> *shrug* [02:25:49 CEST] <atomnuker> yeah, I think we removed support for that [02:25:55 CEST] <jamrial> alright [02:26:20 CEST] <nevcairiel> i never understood why they never named the vp9 profiles, numbers are so uninspiring [02:26:24 CEST] <nevcairiel> glad they gave it names for av1 [02:26:36 CEST] <atomnuker> camcoders supported that ages ago apparently, it was just a leftover from vp9 (and vp8 and vp6 and the whole on2 days of nothing) [02:30:02 CEST] <cone-624> ffmpeg 03James Almer 07master:d039d7d4a4a5: avcodec/libaomdec: remove references to yuv440p pixfmt [02:31:49 CEST] <atomnuker> jamrial: could you also change the name [02:31:58 CEST] <atomnuker> I dislike what became of vpx [02:32:02 CEST] <atomnuker> with libvpx-vp9 [02:32:18 CEST] <jamrial> well, libaom is supposed to be reused for av2, whenever that shows up [02:32:35 CEST] <atomnuker> I guess, that would be the google way of doing it [02:59:04 CEST] <jamrial> atomnuker: what about rgb? should i remove that as well and leave only yuv for now? [03:00:47 CEST] <atomnuker> jamrial: looking at the draft, high and pro profiles support it for 444 [03:01:09 CEST] <jamrial> ok, will do the same as libvpxenc then [03:01:27 CEST] <atomnuker> oh you're doing the encoder now? [03:02:11 CEST] <jamrial> yeah, merging the wrapper from libav while also porting some of the changes we have in libvpxenc [03:02:37 CEST] <jamrial> i did the same with the decoder wrapper, which is why the 440 stuff made it in [03:18:57 CEST] <rcombs> remind me, is subsampling still worthwhile from a compression standpoint in AV1 [03:19:10 CEST] <rcombs> or is it just to save memory/bandwidth in raw video [03:27:47 CEST] <TD-Linux> it is still worth it from a compression standpoint [03:28:04 CEST] <TD-Linux> CfL reduced the need but did not eliminate it. also, the memory bandwidth savings remains very significant [03:29:16 CEST] <TD-Linux> jamrial, 440 is actually not allowed at all in av1. [03:29:46 CEST] <jamrial> TD-Linux: yeah, i already removed it from the decoder wrapper [03:29:55 CEST] <TD-Linux> it still has RGB though. [03:30:03 CEST] <jamrial> why did the enum values make it in, though? [03:30:30 CEST] <jamrial> as in, they were not removed after the mass renaming to the new AOM_ namespace [03:30:47 CEST] <TD-Linux> they probably shouldn't have. libaom isn't abi stable yet so we could still drop it [03:31:18 CEST] <jamrial> that'd be nice, if anything to have less confusing headers :p [03:31:34 CEST] <atomnuker> TD-Linux: with spatial domain cfl/general intra it's worth it [03:32:21 CEST] <atomnuker> I'm still quite sure frequency domain intra can remove the need for it [03:34:33 CEST] <TD-Linux> https://bugs.chromium.org/p/aomedia/issues/detail?id=1672 [03:35:29 CEST] <TD-Linux> jamrial, actually it rejects all RGB images too, though it shouldn't. then again RGB images are really the same as a 4:4:4 pixfmt [03:36:02 CEST] <jamrial> well, right now it's also failing when i try to set AV1E_SET_COLOR_SPACE [03:36:08 CEST] <jamrial> so it clearly needs some more work [03:36:34 CEST] <TD-Linux> AV1E_SET_COLOR_SPACE doesn't exist in the current codebase [03:38:07 CEST] <jamrial> i see it defined in aomcx.h [03:38:16 CEST] <TD-Linux> yeah weird. I'm not sure what happened there [03:38:51 CEST] <TD-Linux> so the color primaries / matrix / etc ones all work [03:39:38 CEST] <jamrial> those are the new ones compared to vp9 [03:39:52 CEST] <jamrial> vp9 had color space and color range only [03:41:13 CEST] <TD-Linux> https://bugs.chromium.org/p/aomedia/issues/detail?id=1673 [03:41:37 CEST] <TD-Linux> yeah. "color space" is no longer a syntax element, but described by the individual elements instead, so deleting the ctl is one way to fix it [03:42:01 CEST] <jamrial> how is one supposed to set it now, then? [03:42:47 CEST] <TD-Linux> SET_TRANSFER_CHARACTERISTICS, SET_MATRIX_COEFFICIENTS, SET_COLOR_PRIMARIES [03:43:27 CEST] <jamrial> ah, i see [03:43:42 CEST] <TD-Linux> I can remake the ctl and have it set all 3 at once if you like [03:44:35 CEST] <jamrial> does this mean the aom_color_space_t enum is no longer valid as well? [03:48:16 CEST] <TD-Linux> yes [03:48:36 CEST] <TD-Linux> the patch changed at one point to switch to CICP color numbers and it seems that they didn't delete the old stuff [03:49:27 CEST] <jamrial> ok [03:49:54 CEST] <TD-Linux> would you find the ctl to set all useful? if not I'll just delete it and the aom_color_space_t enum [03:53:12 CEST] <jamrial> nah, remove them [03:54:28 CEST] <jamrial> the new stuff maps the enums in pixfmt.h better [05:24:42 CEST] <cone-624> ffmpeg 03Luca Barbato 07master:43778a501f1b: Support AV1 encoding using libaom [05:24:43 CEST] <cone-624> ffmpeg 03James Almer 07master:99cc3cf7a26c: Merge commit '43778a501f1bfbceeddc8eaeea2ea2b3506beeda' [05:24:44 CEST] <cone-624> ffmpeg 03James Almer 07master:c0f0c9f53187: avcode/profiles: add AV1 profiles [05:25:44 CEST] <jamrial> you're all welcome to fix all the stuff that's probably broken but i couldn't find on this thing :p [05:40:25 CEST] <cone-624> ffmpeg 03James Almer 07master:88e9b616b94a: libavcodec/libaomdec: use the matrix coefficients value from aom_image [05:52:22 CEST] <cone-624> ffmpeg 03James Almer 07master:416d354a576d: libavcodec/libaomenc: fix size specifier in an av_log call [06:06:02 CEST] <cone-624> ffmpeg 03James Almer 07master:97de37da9c29: libavcodec/libaomdec: add support for transfer characteristics and color primaries [06:06:03 CEST] <cone-624> ffmpeg 03James Almer 07master:e5819fa62930: libavcodec/libaomenc: add support for transfer characteristics and color primaries [07:31:25 CEST] <rcombs> > image_copy_16_to_8 [07:31:27 CEST] <rcombs> looks fast [07:35:25 CEST] <rcombs> and oh glad to see the "mastering display metadata" meme made it into AV1 [07:35:29 CEST] <rcombs> (TL note: no I'm not) [10:50:49 CEST] <cone-075> ffmpeg 03Paul B Mahol 07master:ae9297097696: avcodec/eac3: add support for dependent stream [10:50:50 CEST] <cone-075> ffmpeg 03Paul B Mahol 07master:2974b2556b2d: avcodec: add eac3_core bitstream filter [10:50:51 CEST] <cone-075> ffmpeg 03Paul B Mahol 07master:ae1a8b06907e: doc/general.texi: fix warning [11:56:38 CEST] <nevcairiel> rcombs: PQ and its metadata (ie. HDR10) is part of the video world now, a new modern codec not supporting it would be far sader then it existing in the first place [11:57:20 CEST] <JEEB> yup [14:18:32 CEST] <JEEB> michaelni: cheers. I was trying to run that test actually, but it couldn't generate lena for some reason [14:18:52 CEST] <JEEB> (I got a zero-byte lena file basically) [14:19:02 CEST] <JEEB> which of course failed to run the test [14:20:03 CEST] <JEEB> I wouldn't be surprised if the changes are OK, though, since that code has been running with a few things for more than 24h now and visually the result seems OK [14:23:49 CEST] Action: durandal_1707 still waiting for ATRAC9 [15:01:10 CEST] <JEEB> right, that test requires fate-samples even though it's not one of those that doesn't bug you about it [15:05:44 CEST] <atomnuker> durandal_1707: fine, I'll work on it today, waiting for a vulkan bugfix from mesa anyway [15:06:13 CEST] <atomnuker> I can crash any intel gpu with a few lines of glsl [15:06:47 CEST] <wm4> isn't that normal [15:07:57 CEST] <atomnuker> no, never ever happened in all 6 years of using it [15:08:32 CEST] <atomnuker> hmm, maybe 2, it did happen before they made it very stable some years ago [15:11:06 CEST] <Compn> atomnuker : at least you cant brick it, yet :D [15:32:11 CEST] <jdarnley> atomnuker: if you're not too busy would you mind looking at the following links and giving me some advice on how to handle the bottom of the planes? [15:32:16 CEST] <jdarnley> https://gitlab.com/J_Darnley/ffmpeg/commit/35615a5d8debab4c22657b206ae321bc… [15:32:27 CEST] <jdarnley> https://gitlab.com/J_Darnley/ffmpeg/commit/35615a5d8debab4c22657b206ae321bc… [15:33:12 CEST] <jdarnley> Perhaps I should just add more conditions to the loops and ifs [15:40:13 CEST] <atomnuker> no idea what's wrong with them, I can't really recognize them anymore [15:40:22 CEST] <atomnuker> what's up with that progress stuff? [15:42:39 CEST] <jdarnley> I need to know how many lines I have already processed. [15:43:15 CEST] <jdarnley> It might be too verbose but I can clean it up later [15:44:20 CEST] <jdarnley> I should probably reduce it to a single variable [15:46:12 CEST] <atomnuker> oh, so you can know how many lines the next transform will take based on resolution? [15:46:41 CEST] <jdarnley> Yeah [16:12:29 CEST] <cone-616> ffmpeg 03Nicolas Gaullier 07master:95e47654bce3: lavfi/silencedetect: Add mono mode [16:12:30 CEST] <cone-616> ffmpeg 03Nicolas Gaullier 07master:3deb17f9fb47: lavfi/silencedetect: Fix when silence_start=0 [16:12:31 CEST] <cone-616> ffmpeg 03Nicolas Gaullier 07master:cd4756a55819: lavfi/silencedetect: Update test parameters [16:12:32 CEST] <cone-616> ffmpeg 03Nicolas Gaullier 07master:56b2731aae33: lavfi/silencedetect: Fix silence_start accuracy [16:12:33 CEST] <cone-616> ffmpeg 03Nicolas Gaullier 07master:5170ab20e1f5: lavfi/silencedetect: Fix silence_end accuracy [16:12:34 CEST] <cone-616> ffmpeg 03Nicolas Gaullier 07master:759381d96b22: lavfi/silencedetect: Fix missing log at eos [17:45:50 CEST] <durandal_1707> should i write pcm-dvd encoder? [17:51:27 CEST] <jamrial> sure, why not? [17:53:04 CEST] <atomnuker> isn't that just big endian pcm 16? [17:54:19 CEST] <nevcairiel> for 16 yes, 20/24 is a bit weird [18:02:56 CEST] <atomnuker> oh, right, I have some of those here [18:05:11 CEST] <jdarnley> Oh I am so very close now. [18:05:22 CEST] <jdarnley> Just a subtle issue at the top of each plane. [18:37:36 CEST] <durandal_1707> how hard is adding LBRR to native opus decoder? [19:03:15 CEST] <atomnuker> pretty hard and messy [19:03:47 CEST] <atomnuker> lbrr data in frame[n] encodes the data from frame[n-1] again [19:04:18 CEST] <atomnuker> so you'll need to delay all output frames by 1 [19:04:34 CEST] <atomnuker> and then dealing with the fact that the frame size can change at any point [19:04:52 CEST] <atomnuker> and the fact that the spec defines how those transitions should work [19:05:15 CEST] <atomnuker> and the fact that the codec itself may change (and if it does so will the transitions and the delay period) [19:05:21 CEST] <atomnuker> it would be pure masochism [19:07:53 CEST] <atomnuker> I suspect this was added for lazy telecom companies who still use 120 year old telephone lines to send voice data [19:08:44 CEST] <atomnuker> when the transmission theorem was dismissed as rubbish ("why would you deliberately put resistors and inductors on the wires") [19:09:46 CEST] <atomnuker> and the fact it requires a delay of 1 whole frame pretty much undermines one of the goals of opus which is to have a low delay codec [19:11:18 CEST] <atomnuker> can you actually generate a stream with llbr? [20:49:57 CEST] <cone-616> ffmpeg 03Paul B Mahol 07master:a8a751ce9aaa: avformat/mpc8: do not return error on stream end [21:20:11 CEST] <cone-616> ffmpeg 03James Almer 07master:25abaf3545f0: avcodec/libaomenc: minor cosmetics [22:42:42 CEST] <cone-616> ffmpeg 03Michael Niedermayer 07master:ea15915b2dc5: avcodec/wmalosslessdec: Fix null pointer dereference in decode_frame() [00:00:00 CEST] --- Fri Mar 30 2018

1 0

ffmpeg.log.20180329
by burek 30 Mar '18

30 Mar '18

[01:28:24 CEST] <jleclanche> I'm trying to record a video with a usb webcam on my laptop, but it's coming out kind of unreliable (always broken halfway through). This is the command line I use: `ffmpeg -f v4l2 -video_size 1920x1080 -i /dev/video1 out.mkv` -- my question: is there a way to stream the raw feed to disk, and do the conversion to mkv later? [01:29:33 CEST] <DHE> you can put "-c copy" before the output file [01:30:22 CEST] <jleclanche> perfect! [01:30:23 CEST] <jleclanche> thank you [01:30:41 CEST] <DHE> the file format doesn't determine CPU usage. it's the codec [01:31:23 CEST] <jleclanche> DHE: I'm not sure how to tune this to come out reliably is the thing. If I have the raw feed then at least i can mess with it later and i dont have to rerecord [01:31:35 CEST] <jleclanche> but if you have a suggestion on tuning this so it comes out good, I'm all ears [01:32:13 CEST] <DHE> start with my suggestion. it may produce a large file but still .mkv. then you can edit that however you want [01:32:24 CEST] <jleclanche> Yes, I'm using that now, it's perfect :) [01:32:32 CEST] <DHE> lacking details I'm making assumptions here though. so give it a spin first and see how it goes [01:32:42 CEST] <jleclanche> just did, it works well [01:43:16 CEST] <spot> Hello, is anybody here? [01:43:51 CEST] <TheAMM> Just 417 users plus some +v and ops [01:46:40 CEST] <spot> OK then. I have developed a set of settings for Handbrake which accomplishes exactly what I want, which is to convert .ts files downloaded from my TiVo unit, to .mkv files suitable for playing in one corner of my computer screen. If I post the complete set of these Handbrake settings, can someone please tell me what the equivalent ffmpeg settings will be, to incorporate into a script, so I don't need to start Handbrake? [01:51:19 CEST] <spot> I take silence to mean yes. Here are the settings: Auto Crop off, Loose Crop unchecked, 0-0-0-0, Optimal for Source unchecked, 722, 406, Anamorphic off, Alignment 2, Keep Aspect checked. [01:51:29 CEST] <spot> Detelecine off, Interlace Detection off, Deinterlace Yadif, Deinterlace preset Bob, Deblock off, Denoise Filter Off [01:51:40 CEST] <spot> H.264, Framerate 59.94, Constant, Bitrate 4160, 2-Pass encoding, Turbo first pass unchecked, preset placebo, Tune none, Profile high, Level 4.1, fast decode unchecked. [01:51:52 CEST] <spot> ref=4:bframes=1:b-pyramid=none:weightp=1:8x8dct=1:me=umh:subme=9:merange=16:direct=auto:b-adapt=2:trellis=2:aq_mode=1:aq_strength=1:psy_rd=1.00,0.15:fast_pskip=0:deblock=0,0:dct-decimate=0:keyint=600:keyint_min=120:rc_lookahead=120:sync_lookahead=120:qcomp=0.45:non-deterministic=1:qpmin=0:qpmax=30:qpstep=5:analyse=i4x4,i8x8:chroma_qp_offset=-1:nr=1 [01:52:06 CEST] <DHE> placebo? really? [01:52:21 CEST] <spot> That's all. What CLI lines for a 2-pass ffmpeg encode will equate to this set of Handbrake settings? [01:52:33 CEST] <TheAMM> I don't know what the files look like [01:53:21 CEST] <spot> Input is .ts files downloaded (via kmttg) from my TiVo unit, they're 1920x1080. Output is 722 x 406 .mkv. [01:53:34 CEST] <TheAMM> Audio? [01:54:13 CEST] <TheAMM> Are you sure you want 2-pass? [01:54:29 CEST] <spot> AC3, bitrate 160, Dolby Pro Logic II mixdown, samplerate same as source, gain 0db, drc off, passthru aac [01:55:21 CEST] <spot> Yes, 2-pass, it produces perfect results. What I am doing is transcribing CNBC daytime shows. I have not found a 1-pass set of settings which makes the ticker across the bottom run smoothly. Two-pass works fine. [01:55:57 CEST] <TheAMM> 2-pass should not affect framerate at all [01:56:23 CEST] <spot> Works fine, that is, with the above settings in Handbrake. I'd like to automate the process with a script called from within kmttg. But to do so, I need to know what the CLI commands are for an ffmpeg 2-pass transcription. [01:56:26 CEST] <TheAMM> Not even decoding speed, if you think your machine would lag on the video [01:57:24 CEST] <TheAMM> So filesize is not an issue per se? [01:57:24 CEST] <spot> I did a lot of trial-and-error to come up with these Handbrake settings, they work. Machine is a dual E5-2696 v3 Xeon. [01:57:49 CEST] <TheAMM> You just want something that'll play in the corner of your screen, right? [01:58:35 CEST] <spot> I am reducing a 10 GB input .ts to a 4GB output .mkv, that's good enough. [01:59:23 CEST] <spot> Output is a 722x406 .mkv file. I have a 24-inch 16:9 monitor so it's plenty good enough. [02:01:40 CEST] <spot> I have found that I can reduce bitrate by half with only slight reduction in video quality, but storage space is not so pressing an issue that I need to be so miserly with kbps. [02:02:55 CEST] <TheAMM> What are you playing the fiels with? [02:03:00 CEST] <TheAMM> files* [02:03:17 CEST] <spot> I am playing the files on the same computer I am encoding them on. [02:04:08 CEST] <TheAMM> I mean are you using vlc, mpv, something else [02:04:17 CEST] <furq> yeah there is absolutely no way that 2-pass affects the smoothness of a ticker [02:04:24 CEST] <furq> the only thing that'd affect that is your deinterlacing method [02:04:52 CEST] <spot> Well, I tried everything I could think of in 1-pass and the results were not as good as I can achieve with 2-pass. [02:04:59 CEST] <TheAMM> Something like 'ffmpeg -i in.ts -vf yadif,scale=722:406 -c:b libx264 -b:v 2500k -preset ultrafast -b:a 144k out.mkv' should maybe work [02:05:04 CEST] <spot> Usually I use vlc, but sometimes smplayer or xine. [02:05:17 CEST] <TheAMM> It should be a whole lot faster than the 2-pass [02:05:21 CEST] <furq> yeah don't do that [02:05:40 CEST] <TheAMM> Raise the bitrate if it's too low, and if you don't need deinterlacing drop the "yadif," [02:05:59 CEST] <furq> if this is from a tv capture box then i assume it can be guaranteed to be 50i [02:06:38 CEST] <furq> -i foo.ts -vf yadif=1,scale=722:-2 -c:v libx264 -crf 18 -preset veryslow -c:a copy bar.mkv [02:06:45 CEST] <furq> would be my quick suggestion [02:07:04 CEST] <furq> not entirely sure why you've picked 722 for width but nvm [02:07:35 CEST] <spot> OK I will try these 1-pass suggestions. But I would still like to know what the exact ffmpeg 2-line 2-pass equivalent would be. [02:08:01 CEST] <spot> 722 uses up approximately 1/4 of my screen, it leaves enough room for a browser in the rest of the screen. [02:08:08 CEST] <TheAMM> There are a lot of unnecessary options in the dump you posted, spot [02:08:21 CEST] <TheAMM> And you should be able to resize your video player [02:08:40 CEST] <furq> actually i'm not sure what's going on with the x264 settings there [02:08:41 CEST] <TheAMM> Although I get encoding a working copy instead of a full 1080p video [02:08:48 CEST] <furq> you mentioned preset placebo but those x264 options are definitely not preset placebo [02:10:01 CEST] <spot> No doubt there are unnecessary options and I wouldn't be surprised if preset placebo conflicts with some settings. As I understand it, Handbrake takes the preset and then modifies in accordance with whatever additional settings you feed it. I am not an expert, I derived this through trial and error! That's why I'm here! [02:10:27 CEST] <furq> well yeah if you want to use those exact x264 options then you can pass them to -x264-params [02:10:34 CEST] <furq> the same string you pasted [02:10:41 CEST] <furq> i would just stick with the vanilla presets though [02:11:28 CEST] <furq> https://trac.ffmpeg.org/wiki/Encode/H.264#twopass [02:11:35 CEST] <furq> if you really need a specific target bitrate then that's how you do 2-pass [02:11:47 CEST] <furq> i would definitely be using crf mode for this though [02:12:05 CEST] <spot> If I play a full 1920x1080 video in vlc, I must resize vlc. Don't need to resize smplayer, it remembers its window dimensions. But on 3-hour shows smplayer sometimes loses its audio-video synchronization. VLC is better at keeping audio and video synchronized. [02:13:09 CEST] <TheAMM> furq: is there any speed difference between crf and cbr? [02:14:00 CEST] <furq> -b is abr, not cbr [02:14:17 CEST] <spot> I tried passing -x264-params and it didn't take them. This is on Fedora Linux 26. Maybe I need to compile ffmpeg myself? [02:14:28 CEST] <furq> also [02:14:36 CEST] <furq> spot: what about mpv --geometry=722x406 [02:14:41 CEST] <spot> I tried crf 17 and even 0 and did not get a smooth ticker. [02:14:54 CEST] <TheAMM> furq: is there any speed difference between crf and abr? [02:15:00 CEST] <furq> not really [02:15:14 CEST] <spot> This machine encodes, in Handbrake given the above settings, at about 105 fps. [02:15:14 CEST] <furq> abr is generally just worse [02:15:29 CEST] <furq> 2-pass is really just crf mode [02:15:42 CEST] <furq> the first pass just selects the correct crf value to hit the target bitrate [02:17:31 CEST] <furq> apparently fc26 has ffmpeg 3.3 so that should be plenty new enough [02:19:08 CEST] <spot> Just a minute... [02:20:45 CEST] <spot> ffmpeg version N-90176-g27cbbbb Copyright (c) 2000-2018 the FFmpeg developers, built with gcc 7 [02:21:23 CEST] <furq> like i said i'd just forget those params anyway [02:21:28 CEST] <furq> just stick with the presets [02:21:47 CEST] <spot> I will try your suggestions and report back. Thanks much. [02:22:00 CEST] <furq> and yeah make sure you're using -vf yadif=1 [02:22:20 CEST] <furq> you could also try bwdif=1, i've had somewhat better results with that [02:23:11 CEST] <furq> but yeah if this is just in the pursuit of your player being the correct size then you should probably just use mpv --geometry [02:23:14 CEST] <spot> Handbrake absolutely requires Deinterlace: yadif and Deinterlace preset: bob to produce an .mkv with smooth ticker scroll. [02:23:21 CEST] <furq> right [02:23:25 CEST] <furq> yadif mode 1 is bob [02:23:37 CEST] <furq> bwdif is a different deinterlacer but it also has a bob mode [02:23:53 CEST] <furq> i don't think bwdif made it into handbrake yet [02:24:53 CEST] <spot> I'll be back tonight to report results. [02:42:41 CEST] <_vince> any tips on repairing a barely playable jerky video with a lot of these errors: top block unavailable for requested intra mode, mb_type 43 in P slice too large at 35 3 [02:43:14 CEST] <_vince> out of range intra chroma pred mode [04:16:21 CEST] <spot> Back again. For comparison screencap, see https://drive.google.com/open?id=1er282wlTBX_jmF24nHN3BGAvMnt0PXUD [04:16:42 CEST] <spot> The one on the left is with 1-pass ffmpeg, the one on the right is 2-pass Handbrake. [04:17:48 CEST] <spot> Smoothness of ticker scroll is acceptable with both, however the 2-pass Handbrake is better quality. Noticeable particularly in the skin details of the interviewee, and sharpness of text. [04:18:08 CEST] <spot> The ffmpeg line was: [04:18:17 CEST] <spot> ffmpeg -i 'Squawk Alley - 03-27-2018 (03_27_2018).ts' -vf yadif=1,scale=722:406 -c:v libx264 -b:v 4160k -preset veryslow -b:a 144k 'Squawk Alley - 03-27-2018.mkv' [04:19:22 CEST] <TheAMM> You can raise the bitrate or replace the -b:v with a -crf 20 or 18 or lower if you want better quality [04:20:38 CEST] <spot> OK I'll try crf 18. [04:23:28 CEST] <spot> Speed of encode was 48-49 fps, however since only 1 pass took about the same amount of time as 2-pass Handbrake. Took 59 minutes (it's a 59 minute video). [04:39:47 CEST] <furq> spot: you can try using a faster preset [04:40:00 CEST] <furq> slower will be noticeably quicker than veryslow [04:43:04 CEST] <furq> also i guess handbrake does this for you, but hdtv and sdtv use different colour primaries, so if it's not signalled in the file then your player will guess based on resolution [04:45:33 CEST] <furq> so you'll want to add -color_primaries bt709 -color_trc bt709 -colorspace bt709 [04:45:35 CEST] <furq> as output options [04:46:36 CEST] <furq> you might want to doublecheck the source is bt709, but if this is an hdtv capture it's a pretty safe assumption [04:57:02 CEST] <spot> furq: mediainfo says Color space: YUV, Chroma subsampling: 4:2:0, Bit depth: 8 bits, I presume this is bt709? [05:00:57 CEST] <beandog> HandBrake guesses, but chooses bt709 by default for two of the colors, but not for the third. [05:00:59 CEST] <furq> if it doesn't explicitly mention color primaries in mediainfo then it'll just be assumed to be bt.709 [05:01:03 CEST] <beandog> I just had to fix mine for DVDs. [05:01:11 CEST] <beandog> furq, what are you encoding? what's the source [05:01:16 CEST] <furq> i'm not encoding anything [05:01:23 CEST] <furq> spot is encoding hdtv to 480p [05:01:24 CEST] <beandog> oh, I meant spot [05:01:43 CEST] <beandog> Anything above 480, the HDTV will assume it's 709 [05:01:46 CEST] <furq> right [05:01:56 CEST] <beandog> you ... probably just said that. [05:01:58 CEST] <beandog> :) [05:02:00 CEST] <furq> i sure did [05:02:03 CEST] <beandog> ll [05:02:08 CEST] <beandog> I'll just crawl back in my cave. [05:02:26 CEST] <furq> thanks for the preset reference page btw [05:02:37 CEST] <beandog> dude that thing is balls out of date [05:02:49 CEST] <beandog> I need to fix it [05:03:01 CEST] <beandog> well. partially out of date. [05:03:14 CEST] <furq> yeah i can't imagine they've changed that much [05:03:43 CEST] <beandog> anyway, if you want HandBrake to force the right color set (from a DVD, which is all my sources), you'd need these x264 opts: colorprim=smpte170m:transfer=smpte170m:colormatrix=smpte170m [05:04:03 CEST] <furq> i wonder if i have any that need fixing [05:04:11 CEST] <spot> The colors all look correct to me. beandog: I'm taking CNBC shows, in .ts format, downloaded from my TiVo using kmttg, and turning them into .mkv files so I can play them on my computer. Reducing them from the original 1920x1080 down to 722x406, so I can view them in one quarter of my monitor's real estate, whilst using a browser on the other half. [05:04:28 CEST] <beandog> dude \o/ [05:04:38 CEST] <beandog> downloading from a tivo. I used to have a Tivo2 I'd rip mine off. Those were the days. [05:04:41 CEST] <beandog> I still have the code. [05:06:02 CEST] <beandog> that's an interesting setup, though. [05:06:13 CEST] <_vince> how to repair a broken video? [05:06:18 CEST] <furq> yeah i still think it's crazy to reencode everything instead of just resizing your player [05:06:34 CEST] <furq> just throwing that out there [05:06:37 CEST] <beandog> that .... is what I was going to ask .. but I figured he had a good response and was tired of giving it :) [05:06:51 CEST] <furq> i think he said something about it not working reliably in vlc [05:06:55 CEST] <beandog> oh [05:06:56 CEST] <furq> if you can imagine something not working reliably in vlc [05:07:01 CEST] <beandog> makes sense. [05:07:02 CEST] <beandog> I never use VLC [05:07:15 CEST] <beandog> So I don't even know what it's like, quality-wise [05:07:19 CEST] <_vince> furq: having a down scaled copy saves processing power in playing [05:07:43 CEST] <furq> yeah but you then burn that saved power 100x by reencoding it in advance [05:07:58 CEST] <beandog> yep [05:08:11 CEST] <furq> unless the target machine is incapable of playing the source smoothly [05:08:18 CEST] <spot> By downsizing it from 1920x1080 to 722x406 I can start it in my preferred player, vlc, and not have to resize the window. It's convenient to watch the shows and take notes on the other half of my monitor. Also reduces file size by about 60%. [05:08:24 CEST] <beandog> that was gonna be my next guess, maybe something related to framerate. [05:08:42 CEST] <furq> if you're actually archiving these and disk space is a concern then sure, that makes sense again [05:09:00 CEST] <beandog> spot, looks good then :) [05:09:22 CEST] <spot> Well, I have 10 TB, so space isn't really a worry. [05:09:41 CEST] <beandog> What are your encoding parameters? [05:09:47 CEST] <beandog> now I'm really curious [05:11:12 CEST] <beandog> I actually go the opposite direction and bump mine up so that I have warm fuzzies. And it looks better. [05:11:23 CEST] <beandog> bump it up size-wise [05:13:23 CEST] <spot> Not sure what you mean by "parameters." Do you mean, what Handbrake settings am I using? [05:14:19 CEST] <beandog> Yeah [05:14:47 CEST] <spot> Wait a sec, I'll post them to Google Drive. I posted them, above, and got ranted at a bit for using so much space. [05:14:51 CEST] <beandog> So you're using HB to re-encode your TS files? That's interesting. [05:15:04 CEST] <beandog> as in, time-saving. [05:15:22 CEST] <beandog> and other reasons. [05:16:00 CEST] <spot> Yes but I want to use ffmpeg instead, that will save even more time, because ffmpeg can be called programmatically from kmttg. So I can download, decrypt, and transcribe multiple shows in one fell swoop. [05:16:35 CEST] <spot> Poor _vince, he is not getting his question answered. Can anyone help him? [05:17:03 CEST] <beandog> _vince, what was the question? broken video? [05:17:26 CEST] <beandog> spot, oh right on, I can translate for you :D being the multimedia nerddom that I am [05:17:31 CEST] <_vince> 16:42 < _vince> any tips on repairing a barely playable jerky video with a lot of these errors: top block unavailable for requested intra mode, mb_type 43 in P slice too large at 35 3 [05:17:35 CEST] <_vince> 16:43 < _vince> out of range intra chroma pred mode [05:17:58 CEST] <beandog> that's above my pay grade. [05:21:35 CEST] <spot> Mine too. beandog: https://drive.google.com/open?id=1TFYbnUsPaEUSR5NkXs8RCSLwRmeBSnEr [05:21:52 CEST] <beandog> yee boi, another distraction from homework [05:22:47 CEST] <beandog> dang, dude, you are turning off *all* the features. [05:22:51 CEST] <beandog> that makes it dead simple. [05:23:56 CEST] <spot> I'm trying various suggested 1-pass ffmpeg command lines. First tried a command line with -b:v 4160k, it was not as sharp as my Handbrake settings. Just finished a second ffmpeg try with -crf 18, will tell you in a minute how it compares. [05:24:03 CEST] <beandog> first knee-jerk reaction: don't use placebo, use slow at the most, don't use two-pass, do a high CRF like ... I dunno ... 18 and it'll look sexy ... I'd dump it at 60fps myself because that's how I roll. [05:24:44 CEST] <beandog> After years, I settled myself on 23 as a general setting, 18 for the shows I like, and 14 for the ones I want to look godly. [05:24:54 CEST] <beandog> like Teen Titans Go [05:25:12 CEST] <beandog> if you really don't care about space, then yeah, use a high CRF [05:25:46 CEST] <beandog> er, if you prefer *quality* over space. that's a better way to put it. [05:26:05 CEST] <beandog> don't set the bitrate yourself, though, that'll just cause gray hairs. [05:26:46 CEST] <beandog> ok plz hold let me translate this thing. [05:26:48 CEST] <spot> I see no difference between -b:v 4160k and -crf 18. For a comparison see https://drive.google.com/open?id=1er282wlTBX_jmF24nHN3BGAvMnt0PXUD [05:26:57 CEST] <spot> The one on the left is with 1-pass ffmpeg, the one on the right is 2-pass Handbrake [05:27:41 CEST] <spot> The Handbrake one has sharper skin detail and crisper text. [05:27:48 CEST] <beandog> well the bitrate is fixed, so you'll lose quality at some points. or use too much space at others. the CRF is quality based. [05:28:36 CEST] <beandog> try a better CRF :) [05:28:52 CEST] <spot> OK I'll try crf 14. [05:28:52 CEST] <beandog> I know what it's like to be picky on quality. [05:30:41 CEST] <beandog> oh, and you could run HandBrakeCLI as well, so you don't have to run the GUI. That's always an option, but you mentioned your app integrates ffmpeg so that probably wouldn't help much. [05:32:14 CEST] <furq> you might want to add -tune film [05:32:19 CEST] <furq> that should help with sharpness on fine detail [05:32:24 CEST] <beandog> that, too ^^ [05:32:38 CEST] <furq> i notice handbrake is using deblock 0:0 so that can't be why that looks sharper [05:32:48 CEST] <spot> Actually, tune=film was one of my experiments and the result was inferior. [05:33:15 CEST] <furq> it will look worse at the same bitrate in abr mode [05:33:25 CEST] <furq> in crf mode it'll bump the rate a bit to compensate [05:35:47 CEST] <furq> you might also want to try bwdif instead of yadif [05:36:05 CEST] <spot> I didn't try HandbrakeCLI because I read somewhere that not all the x264 parameters are obeyed/implemented in it. [05:37:00 CEST] <spot> furq: OK I will. The "b" in "bwdif" stands for Bob and the "w" is his last name, the guy who invented yadif bob, if I remember correctly. [05:37:13 CEST] <beandog> spot, .... wth ... of course it can do all the x264 params [05:37:20 CEST] <beandog> who said that? [05:37:23 CEST] Action: beandog smacks someone [05:37:43 CEST] <beandog> --encopts [05:37:56 CEST] <spot> Eh? [05:38:46 CEST] <beandog> here's me being lazy and showing one of my examples [05:38:52 CEST] <beandog> HandBrakeCLI '--markers' '--detelecine' '--cfr' --title '7' --encoder 'x264' --quality '14' --rate '60' --encoder-profile 'high' --encoder-level '4.1' --encoder-preset 'slow' --encoder-tune 'animation' --encopts 'colorprim=smpte170m:transfer=smpte170m:colormatrix=smpte170m' --audio '1' --aencoder 'ac3' --subtitle '3' --input '/home/steve/Media/Laundry-Basket/1.059.0242.BTMNB.iso' --output '1.059.0242.02020.BTMNB.mkv' [05:39:13 CEST] <beandog> --encopts is where you dump those exact x264 params you had earlier [05:39:51 CEST] <spot> Ah I see. Like -x264-params in ffmpeg. [05:39:55 CEST] <beandog> yee [05:40:04 CEST] <beandog> it's called encopts because it uses other encoders as well [05:40:13 CEST] <beandog> it used to be x264-opts but they just folded it into one option [05:40:30 CEST] <beandog> same with --encoder-level, profile, preset, etc. [05:40:32 CEST] <furq> i don't think bob deinterlacing is named after a guy [05:40:44 CEST] <furq> it's because a naive bob will result in alternate frames bobbing up and down [05:41:28 CEST] <spot> https://github.com/kfrn/ffmpeg-things/blob/master/deinterlacing.md [05:41:35 CEST] <beandog> spot, what's the source audio codec? do you care if you just pass it through? that'd save some time. [05:41:39 CEST] <spot> bwdif: Bob Weaver Deinterlacing Filter [05:41:47 CEST] <furq> yeah, because it combines bobbing and weaving [05:41:56 CEST] <spot> Ah. Of course. [05:41:59 CEST] <furq> it's just a coincidence that it sounds like a guy's name [05:42:23 CEST] <furq> i suspect whoever named it did that on purpose [05:42:36 CEST] <spot> Yeah, prolly. [05:42:56 CEST] <beandog> hmm .. that's interesting ... I gotta check that out. There's some cartoons I have that decombing it makes it look more ugly, but less interlaced. [05:43:04 CEST] <furq> it's all subjective but bwdif is the best realtime option in ffmpeg [05:43:16 CEST] <furq> nnedi is the best quality but it's unbelievably slow [05:43:35 CEST] <beandog> how slow is slow? [05:43:41 CEST] <furq> obviously i said "it's all subjective" and then the bit after that is my opinion, not an absolute fact like i made it look there [05:43:47 CEST] <furq> and uh [05:44:12 CEST] <furq> like single-digit fps for 480p [05:44:22 CEST] <furq> low single digits unless you have crazy clock speeds [05:44:28 CEST] <beandog> spot, are you gonna try handbrake cli out? because if so, I'm not gonna translate this sucker. :) [05:44:38 CEST] <beandog> that is slow. [05:44:38 CEST] <spot> The source audio codec is AC3, Codec ID 129, at constant 384 kbps. So says mediainfo. [05:44:41 CEST] <furq> nnedi is what avisynth/vapoursynth qtgmc uses, and it's multithreaded there so it's not so bad [05:45:02 CEST] <beandog> spot, okay, yeah, you could just leave it there. [05:45:28 CEST] <furq> also honestly those x264 options you pasted look crazy to me [05:45:39 CEST] <spot> First I'm gonna try ffmpeg with a long -x264-params line plus the -tune and -profile. [05:45:40 CEST] <furq> like 1 bframe and 120 lookahead is a bit eye-watering [05:45:58 CEST] <beandog> furq, it's HandBrake just printing out its defaults -- it's not actually overriding *all* of it [05:46:10 CEST] <spot> Yeah I know but I swear bframe=1 looks better than bframe=3 or 4. [05:46:25 CEST] <beandog> spot, okay [05:47:24 CEST] <spot> Ditto the huge values for keyint, keyint_min, rc_lookahead, and sync_lookahead. Primary goal was to get butter-smooth scroll of the ticker, secondary goal was sharpness of text. [05:48:15 CEST] <beandog> fair enough. [05:48:26 CEST] <spot> Just a minute, I'll post mediainfo of the output .mkv to Google Drive so you can see what Handbrake did. [05:48:39 CEST] <beandog> yeah that'd be helpfl [05:49:27 CEST] <beandog> Im gonna try out these other filters on my Superman TAS DVDs [05:49:32 CEST] <beandog> They are grossly horrible interlaced. [05:49:58 CEST] <beandog> and I'll use my sexy dvd_copy program to pipe it right through! woo hoo! or copy it to the hdd. whichever. [05:53:03 CEST] <spot> mediainfo of the .mkv output: https://drive.google.com/open?id=1xRy494MWXOayWEoicARJP7O4GvO5Dr8b [05:53:47 CEST] <beandog> spot, can you throw up a mediainfo output for the source material too? [05:54:00 CEST] <spot> Sure, just a moment [05:55:06 CEST] <beandog> that's an old-ish handbrake install [05:55:24 CEST] <beandog> but *most* development changes they make are for GUI, so you're probably not missing out. [05:56:30 CEST] <spot> mediainfo of the source .ts: https://drive.google.com/open?id=1pYURjyZXbmUzzsBh4ZIgga7iJ61nBKrc [05:56:40 CEST] <spot> It's the standard supplied with Fedora 26. [05:56:45 CEST] <beandog> k thx [05:56:46 CEST] <beandog> ah ok [05:57:35 CEST] <beandog> hmm, only a 50% drop in size .. and if you're picky on quality, I'd actually leave it alone and tell the player to resize it. [05:57:44 CEST] <beandog> but we already went over that :) [05:58:15 CEST] <beandog> okay slightly more than 50% .. but whatevs [06:00:21 CEST] <beandog> what video player *are* you using, anyway? [06:01:28 CEST] <spot> VLC version 3.0.1 Vetinari (3.0.1-0-gec0f700fcc), Compiled by mockbuild on buildvm-03.online.rpmfusion.net (Feb 27 2018 19:59:16), Compiler: gcc version 7.3.1 20180130 (Red Hat 7.3.1-2). Again, the standard issue with Fedora 26. [06:04:48 CEST] <beandog> Hmm. [06:04:52 CEST] <spot> And before you ask...the machine is a dual-E5-2696v3 Xeon. 2 x 18 cores, plus hyperthreading, so 72 virtual cores total. So 36 threads is no worry. [06:05:20 CEST] <spot> Of course I don't know whether Handbrake actually *uses* all those cores. [06:05:28 CEST] <beandog> it can [06:05:36 CEST] <beandog> x264 will use all of them by default [06:05:49 CEST] <beandog> you can see the threads= value in the mediainfo. I think. [06:06:05 CEST] <beandog> threads=36 [06:06:06 CEST] <beandog> yee boi [06:06:18 CEST] <spot> Well, ffmpeg makes my cpu utilization go to 13%, Handbrake goes to 26%. [06:06:30 CEST] <spot> Handbrake encodes at ~105 fps. [06:06:57 CEST] <spot> So a 2-pass encode on a 1-hour show takes about 1 hour start to finish. Actually slightly less. [06:06:58 CEST] <beandog> well they're running completely different arguments [06:08:53 CEST] <beandog> but that does bring up the question of what part does encoding time take into this, priority wise [06:08:56 CEST] <beandog> how fast do you need something [06:09:47 CEST] <spot> I'd like to view it the same day it's broadcast. [06:10:24 CEST] <spot> I'm quite comfortable with a 1-hour show taking 1 hour to encode. Quality is my main objective. [06:12:29 CEST] <beandog> got it [06:12:38 CEST] <spot> I'm quite happy with the quality of the Handbrake encode. Just, I'd like to be able to do it from a cli program. Either ffmpeg or handbrake-cli will serve the purpose. I came here originally tonight to ask if anyone can tell me the 2-line ffmpeg 2-pass equivalent to my exacerbatingly-arrive-at Handbrake setup. [06:12:57 CEST] <spot> arrived-at [06:13:05 CEST] <beandog> right, and I was going to add awhile ago that I didn't have it on my lappy, so I'm waiting for the thing to finish building. [06:13:32 CEST] <spot> It took me *months* of experiments to arrive at settings I was satisfied with. [06:13:43 CEST] <beandog> spot, well your handbrake settings are pretty basic. Very much so. It's just that it's also printing out all these defaults. [06:13:53 CEST] <beandog> hold on though [06:14:39 CEST] <beandog> crap. I don't have ghb installed either. I *think* if you look at the debug window it'll give you the actual command it's running. [06:14:54 CEST] <beandog> maybe not. it's been a while. Hold on. I can get a HB line for you much faster. [06:15:15 CEST] <spot> ghb *is* Handbrake GUI. [06:15:33 CEST] <beandog> right [06:15:35 CEST] <beandog> I only use the CLI [06:15:38 CEST] <beandog> I'm saying I don't have it on my box [06:15:41 CEST] <spot> Ah. I see. [06:15:59 CEST] <spot> I don't think ghb has a debug window. [06:16:31 CEST] <spot> I should note here, I am not a programmer, only an end user. [06:17:16 CEST] <beandog> setting custom width and height is a pain. hb is snotty about that. [06:20:26 CEST] <spot> Another 20 minutes or so, and I should have the ffmpeg 1-pass crf=14 encode finished. That may turn out to be all I need. [06:20:57 CEST] <beandog> okay here [06:21:07 CEST] <beandog> HandBrakeCLI -d bob -w 406 -l 722 -e x264 -r 59.94 --cfr -vb 4160 -2 --no-turbo --encoder-preset placebo --encoder-level 4.1 [06:21:11 CEST] <beandog> I slapped that together [06:21:30 CEST] <beandog> HandBrakeCLI -d bob -w 406 -l 722 -e x264 -r 59.94 --cfr -vb 4160 -2 --no-turbo --encoder-preset placebo --encoder-level 4.1 -i input.ts -o output.mkv [06:22:26 CEST] <beandog> If you wanna play with it, do a 60 second encode and see what you think: --stop-at duration:60 [06:22:43 CEST] <spot> And add the --encopts= followed by my complete Handbrake additional parameters? [06:22:57 CEST] <beandog> no [06:23:00 CEST] <beandog> placebo is setting them. [06:23:05 CEST] <spot> OK hang on. [06:23:05 CEST] <beandog> no touchy [06:23:57 CEST] <beandog> it'll bump the profile to high as well, so I didn't really need that. [06:24:09 CEST] <beandog> Oh. I didn't put it in there. Good for me. [06:26:15 CEST] <beandog> once it runs do a diff or vimdiff on the two mediainfo outputs. That'll give you a clear vision of what it's changing (or not changing) [06:26:18 CEST] <spot> Encoding... [06:28:57 CEST] <beandog> hokay [06:29:44 CEST] <spot> 10 seconds more... [06:31:11 CEST] <spot> Quality looks pretty good. However, it created a 1330 x 722 video, not a 722 x 406 one. [06:31:33 CEST] <furq> -w and -l are flipped [06:31:44 CEST] <furq> assuming -l is "height" [06:32:07 CEST] <beandog> uh [06:32:09 CEST] <beandog> yeah [06:32:10 CEST] <beandog> :) [06:32:20 CEST] <beandog> wait. [06:32:22 CEST] <beandog> Yeah that sounds right. [06:32:33 CEST] <spot> Ticker scroll is a bit fuzzy. [06:32:34 CEST] <furq> is that command deinterlacing [06:32:40 CEST] <beandog> yeah [06:32:49 CEST] <beandog> it's using bob [06:32:56 CEST] <spot> Looks like it's not a yadif bob deinterlace. [06:33:15 CEST] <beandog> Hmm [06:33:18 CEST] <furq> also those settings you were using weren't placebo [06:33:19 CEST] <beandog> my params might be wrong sec. [06:33:34 CEST] <beandog> --encoder-preset placebo [06:33:41 CEST] <furq> yeah i meant the x264 params pasted earlier [06:33:44 CEST] <spot> The crf=14 encode just finished, let me look at that. [06:33:57 CEST] <furq> virtually none of those matched preset placebo [06:34:03 CEST] <beandog> Oh, ok [06:34:06 CEST] <furq> some nice guy made a webpage where you can easily compare them [06:34:16 CEST] <beandog> yee [06:35:08 CEST] <furq> spot: pastebin the full ffmpeg command you're using [06:35:09 CEST] <beandog> Hmm, yeah, I'm not entirely sure I'm doing deinterlacing right. I always do detelecine on mine and let it go. [06:35:14 CEST] <spot> It is my understanding that Handbrake takes the preset you give it as the starting point, then adjusts the parameters individually in accordance with the additional parameters you give it in the "More settings" box. [06:35:23 CEST] <furq> and also bear in mind most x264 options won't actually make any difference given enough bitrate [06:35:36 CEST] <beandog> spot, yeah, it does [06:35:48 CEST] <beandog> what furq said. [06:36:04 CEST] <beandog> I learned that the hard way. [06:36:17 CEST] <furq> i'd be surprised if you can tell the difference between superfast and placebo at crf 14 [06:37:00 CEST] <beandog> Yeah I've done tests on that. You can't. [06:37:00 CEST] <spot> The crf=14 encode is slightly better than the crf=18 encode, but still not as good as the Handbrake encode. [06:37:12 CEST] <furq> pastebin the ffmpeg command [06:39:50 CEST] <spot> Hold on, I have to stitch it together first. [06:41:54 CEST] <beandog> mine keeps want to keep building against x265. le sigh. [06:42:19 CEST] <beandog> oh well [06:45:58 CEST] <spot> https://drive.google.com/file/d/1ICSPFYOji6shV2sY2z6YwYlNK4zZ_VF5/view [06:46:48 CEST] <spot> It's going at 123-124 fps, so should take about 30 minutes. [06:47:11 CEST] <furq> are you encoding the whole thing every time [06:47:25 CEST] <spot> Yes [06:48:01 CEST] <spot> Can I put in a parameter similar to the HandbrakeCLI parameter which stops it after, say, 60 seconds? [06:48:27 CEST] <furq> -t 60 [06:48:35 CEST] <spot> Oh OK, let me restart it. [06:51:09 CEST] <furq> http://vpaste.net/STb3Z [06:51:10 CEST] <furq> try that [06:51:34 CEST] <furq> i should really have remembered earlier that scale will use bicubic by default, which is probably why it looks soft [06:51:46 CEST] <furq> that plus the fixed colour primaries should look much better [06:52:17 CEST] <beandog> Hmm .. I'm playing with other deinterlacing filters, this is already looking good .. thanks furq :D [06:52:28 CEST] <furq> qtgmc is unmatchable for sd stuff [06:52:33 CEST] <furq> for sd sources, i mean [06:52:41 CEST] <furq> but it means going via vapoursynth [06:52:52 CEST] <furq> and also an elaborate and annoying install procedure [06:53:06 CEST] <furq> it's absolutely worth it if you're ripping a lot of dvds though [06:53:09 CEST] <spot> The long-line 1-pass ffmpeg looks identical to the crf=14 encode. Let me try furq's suggested line. [06:54:16 CEST] <beandog> I've got everything nailed down, there's only like 3 or 4 shows that have *nasty* interlacing on it, that any filter on it removes it, but makes other lines look worse. :T [06:54:29 CEST] <furq> yeah qtgmc is excellent for that [06:54:42 CEST] <beandog> ok [06:54:47 CEST] <furq> the one thing it's a godsend for in my experience is a lot of bbc/channel 4 dvds where they've deinterlaced it badly and it has a ton of stairstepping [06:55:00 CEST] <furq> it has a specific mode for repairing that and it works really well [06:55:09 CEST] <beandog> really [06:55:11 CEST] <beandog> that is interesting [06:55:16 CEST] <furq> but yeah it's really slow [06:55:44 CEST] <furq> even multithreaded with vapoursynth, just deinterlacing is slower than encoding with veryslow [06:56:51 CEST] <beandog> I *really* need to look into this. I generally just shrug it off and then get mad. [06:56:56 CEST] <furq> fortunately 1080i stuff tends to benefit less from it because that would take longer than the lifetime of the universe [06:57:01 CEST] <beandog> heh [06:57:12 CEST] <furq> especially because i'm normally resizing that to 720p anyway [06:57:13 CEST] <beandog> I'm happy with 480i thanks [06:57:17 CEST] <spot> furq's line, the crf=14 line, and the very long like-ghb line all give equal results. Handbrake still looks crisper. [06:57:36 CEST] <spot> I mean Handbrake GUI 2-pass. [06:57:45 CEST] <furq> you should definitely notice a difference between default scaling and lanczos scaling [06:57:51 CEST] <furq> and you should also definitely notice the colours are correct now lol [06:57:59 CEST] <furq> unless vlc is being wonky [06:58:35 CEST] <spot> Yeah, you're right, skin tone is a little washed out on the like-ghb encode. Not washed out on yours. [07:02:12 CEST] <spot> The 2-pass Handbrake encode is still just slightly crisper. But not by much. [07:03:53 CEST] <spot> Let me look at the mediainfo diff... [07:03:55 CEST] <beandog> hmm [07:04:13 CEST] <beandog> dude give x264 crf a try :) [07:05:45 CEST] <furq> 4mbit is really high for 480p [07:05:55 CEST] <furq> i guess you could drop the crf some more [07:06:26 CEST] <furq> i've never encoded anything below 18 in my life but if you're really pixel-gazing it might make a difference [07:07:28 CEST] <furq> apparently handbrake uses lanczos scaling by default so i'm now out of ideas as to what the difference could be [07:08:03 CEST] <beandog> In my case, I'm mostly pedantic and obssessed [07:09:02 CEST] <beandog> okay cool, I got some good pngs of the original source that has horrible deinterlacing [07:09:14 CEST] <beandog> er, interlacing. [07:10:01 CEST] <furq> fwiw i think qtgmc is the best deinterlacer in general [07:10:13 CEST] <furq> all the realtime ones leave you with some stairstepping in my experience [07:10:46 CEST] <furq> certainly from a dvd source where you're not resizing it [07:10:48 CEST] <beandog> Yeah I'm just getting a setup where I can actually begin testing some [07:11:16 CEST] <beandog> furq, there you go - source/1.036.0173.TNTTN.iso [07:11:17 CEST] <beandog> gah [07:11:20 CEST] <beandog> stupid buffer [07:11:25 CEST] <beandog> http://dev.beandog.org/superman-tas/ [07:12:13 CEST] <furq> that sort of just looks like a regular telecine [07:13:47 CEST] <beandog> yeah, it is, but detelecing ruins it at the same time [07:13:50 CEST] <beandog> which makes me sad cakes [07:14:05 CEST] <spot> Here's the diff between mediainfo of furq's result and my ghb one: https://drive.google.com/file/d/1Lkkaf043FZntaYKV3IOTv4GRu3l2dqMG/view [07:14:07 CEST] <furq> i'm in a pal region so i never have to deal with ivtc [07:14:28 CEST] <beandog> I hate you. [07:14:35 CEST] <beandog> :D [07:16:14 CEST] <beandog> wait [07:16:18 CEST] <beandog> what encoding preset did you use? [07:16:46 CEST] <beandog> these are totally different [07:19:55 CEST] <spot> oops I did mediainfo on "Squawk Alley - 03-28-2018" not 03-27 as before. Shouldn't make any difference though. Same settings. [07:22:25 CEST] <spot> Er, oops again. Forgot...when I encoded today's Squawk Alley (03-28) I eliminated the threads and lookahead threads settings, as an experiment. Otherwise, should be same. [07:23:32 CEST] <spot> Also dropped me_range from 24 (03-27) to 16. That might make a difference. Let me run the diff again on 03-27 vs. furq's. [07:25:16 CEST] <beandog> do this as well [07:25:40 CEST] <beandog> mediainfo video.mkv | grep "Encoding settings" | head -n 1 | cut -d ':' -f 2- | tr '/' '\n' | cut -d ' ' -f 2- [07:25:46 CEST] <beandog> for both videos, then compare them [07:25:50 CEST] <beandog> that'll show you the x264 changes [07:26:03 CEST] <beandog> then we can actually get a *fair* comparison, since that's all that really matters here. [07:26:24 CEST] <spot> Will do, wait... [07:27:13 CEST] <beandog> You need to get those to match, starting with the one *you like* [07:27:17 CEST] <beandog> and then you're pretty much done. [07:29:34 CEST] <furq> i doubt the encoding settings really matter at all [07:29:42 CEST] <furq> if you really want, you can rule those out entirely by encoding with -crf 0 [07:30:12 CEST] <furq> all settings give identical PQ at crf 0, only the filesize will differ [07:30:32 CEST] <beandog> oh. I guess I already had that online. http://dev.beandog.org/x264_preset_reference.html [07:30:37 CEST] <beandog> I like the new one better. [07:30:49 CEST] <furq> is this not the new one [07:30:49 CEST] <beandog> furq, I'm just wondering if his presets are changing [07:31:08 CEST] <beandog> sorry, I meant that x264 info line [07:31:18 CEST] <beandog> old one: mediainfo video.mkv | grep Encoding | cut -d ':' -f 2- | tr '/' '\n' | cut -d ' ' -f 2- [07:32:09 CEST] <furq> at this point i have to suspect it's some difference between handbrake and ffmpeg's scaler or implementation of yadif [07:32:20 CEST] <furq> assuming handbrake isn't just using swscale and avfilter [07:33:34 CEST] <beandog> if he's using bob like I passed [07:33:53 CEST] <beandog> yeah nvm I thought --help had more info. nvm [07:36:30 CEST] <spot> https://drive.google.com/file/d/1l0cRO7H4Q9w3bpw0Sr84zpVZE0CDvVV0/view [07:39:37 CEST] <beandog> yeah umh vs hex [07:40:07 CEST] <beandog> one's encoding a medium preset [07:40:17 CEST] <beandog> *at [07:40:45 CEST] <beandog> one sec [07:40:48 CEST] <furq> apparently preset slow is hex now [07:41:11 CEST] <beandog> is it? [07:41:12 CEST] <beandog> hmm [07:41:16 CEST] <furq> yeah i just checked [07:41:22 CEST] <beandog> see? my thing is outdated. :) [07:41:22 CEST] <furq> i guess it does change after all [07:41:36 CEST] <beandog> I didn't know that though, I do all mine at slow. [07:41:39 CEST] <furq> anyway yeah like i said [07:41:52 CEST] <furq> spot: if you want to rule out encoding settings, run my command again with -crf 0 [07:42:00 CEST] <furq> and whatever preset you want since it makes no difference [07:42:06 CEST] <furq> might as well go with ultrafast [07:42:24 CEST] <furq> if that still looks different then it's the scaler or deinterlacer [07:42:53 CEST] <spot> OK wait [07:43:20 CEST] <beandog> yeah, that makes sense. [07:43:25 CEST] <beandog> I need to get back to work [07:43:31 CEST] <beandog> these four hour lunch breaks are awesome. [07:43:53 CEST] <spot> Haha I'm in Seattle where it's 10:43 PM. Past my bedtime. [07:43:58 CEST] <beandog> ghb is actually doing lower quality, imo [07:44:35 CEST] <beandog> in my very humble opinion. But, I'm biased, and I'm not the one watching it, so it's a moot point. [07:46:19 CEST] <beandog> spot, can you send me a link again to that original hexchat convo so I can see your original x264 options again [07:49:59 CEST] <spot> Auto Crop off, Loose Crop unchecked, 0-0-0-0, Optimal for Source unchecked, 722, 406, Anamorphic off, Alignment 2, Keep Aspect checked. [07:50:07 CEST] <spot> Detelecine off, Interlace Detection off, Deinterlace Yadif, Deinterlace preset Bob, Deblock off, Denoise Filter Off [07:50:15 CEST] <spot> H.264, Framerate 59.94, Constant, Bitrate 4160, 2-Pass encoding, Turbo first pass unchecked, preset placebo, Tune none, Profile high, Level 4.1, fast decode unchecked. [07:50:23 CEST] <spot> ref=4:bframes=1:b-pyramid=none:weightp=1:8x8dct=1:me=umh:subme=9:merange=16:direct=auto:b-adapt=2:trellis=2:aq_mode=1:aq_strength=1:psy_rd=1.00,0.15:fast_pskip=0:deblock=0,0:dct-decimate=0:keyint=600:keyint_min=120:rc_lookahead=120:sync_lookahead=120:qcomp=0.45:non-deterministic=1:qpmin=0:qpmax=30:qpstep=5:analyse=i4x4,i8x8:chroma_qp_offset=-1:nr=1 [07:51:14 CEST] <beandog> thx [07:53:20 CEST] <spot> The crf=0 encode is...indistinguishable from my Handbrake encode. [07:54:19 CEST] <spot> However, 60 seconds at crf=0 occupies 423 MB. 60 minutes from Handbrake, 1842 MB. [07:56:29 CEST] <beandog> CRF is lossless [07:56:39 CEST] <beandog> er [07:56:44 CEST] <beandog> CRF 0 is lossless [07:56:55 CEST] <beandog> The point was to see if its the video filters that are throwing it off. [07:57:28 CEST] <beandog> anyway I think this is *close* .. [07:57:29 CEST] <furq> fun [07:57:34 CEST] <beandog> ffmpeg -i dvd_track_08.vob -c:v libx264 -preset placebo -crf 18 -x264-params ref=4:bframes=1:b-pyramid=none:weightp=1:8x8dct=1:me=umh:subme=9:merange=16:direct=auto:b-adapt=2:trellis=2:aq_mode=1:aq_strength=1:psy_rd=1.00,0.15:fast_pskip=0:deblock=0,0:dct-decimate=0:keyint=600:keyint_min=120:rc_lookahead=120:sync_lookahead=120:qcomp=0.45:non-deterministic=1:qpmin=0:qpmax=30:qpstep=5:analyse=i4x4,i8x8:chroma_qp_offset=-1:nr=1 -acodec copy -t 1 -r [07:57:34 CEST] <beandog> 59.94 -vf bwdif output.mkv [07:57:47 CEST] <beandog> verbose ftw. [07:58:05 CEST] <furq> yeah my suggestion is to just run mine again but with -crf 14 [07:58:11 CEST] <beandog> Yeah [07:58:12 CEST] <beandog> Do 14. [07:58:23 CEST] <furq> like i said, 4mbit is enormous for 480p [07:58:49 CEST] <furq> you can try with and without -tune film as well, idk how that'll affect text and stuff [07:58:59 CEST] <furq> it's supposed to bias towards fine detail so i figured it'd make edges crisper [07:59:04 CEST] <beandog> Okay I really do need to get to work, good luck spot. Read the output of 'HandBrakeCLI --help' it's not scary and you can build it yourself if you don't wanna go the ffmpeg route [07:59:58 CEST] <beandog> In fact, you can *use* the presets in the GUI. [08:00:25 CEST] <beandog> HandBrakeCLI --preset-list [08:00:31 CEST] <beandog> Yet another thing I should have mentioned hours ago.. [08:00:54 CEST] <beandog> and then just override what you want. [08:01:36 CEST] <spot> I already tried crf=0. It's a little better than crf=18 and about the same as furq's first suggestion, but furq's use of the Lancosz algo then made the colors better. I think the next thing to try will be a 2-pass 2-line ffmpeg encode, from the long line I posted at https://drive.google.com/file/d/1ICSPFYOji6shV2sY2z6YwYlNK4zZ_VF5/view. HandBrakeCLI is available in the Fedora repo's, I already downloaded and tried it. But I like the [08:01:36 CEST] <spot> idea of doing it with ffmpeg a la furq. [08:01:59 CEST] <spot> I mean "already tried crf=14" [08:02:19 CEST] <spot> Need to hit the sack soon. [08:02:29 CEST] <beandog> HandBrakeCLI --preset 'H.264 MKV 1080p30' -i dvd_track_08.vob -o waddup.mkv --stop-at duration:1 [08:02:30 CEST] <beandog> k [08:02:31 CEST] <beandog> good luck :D [08:02:38 CEST] <beandog> I'm outta [08:02:50 CEST] <spot> good night zzzz [08:19:50 CEST] <spot> I of course could not sleep until I made one more try at it. This 1-pass ffmpeg line produces an encode which looks identical to my 2-pass Handbrake encode. Better, because the encode runs at 150+ fps. So this is going to save me quite a bit of time. [08:20:21 CEST] <spot> ffmpeg -i 'Squawk Alley - 03-27-2018 (03_27_2018).ts' -vf bwdif=1,scale=722:406:flags=lanczos,fps=60000/1001 -c:v libx264 -b:v 4160k -preset placebo -profile:v high -x264-params ref=4:bframes=1:b-pyramid=none:weightp=1:8x8dct=1:me=umh:subme=9:merange=16:direct=auto:b-adapt=2:trellis=2:aq_mode=1:aq_strength=1:psy_rd=1.00,0.15:fast_pskip=0:deblock=0,0:dct-decimate=0:keyint=600:keyint_min=120:rc_lookahead=120:sync_lookahead=120:qcomp=0.4 [08:20:21 CEST] <spot> 5:non-deterministic=1:qpmin=0:qpmax=30:qpstep=5:analyse=i4x4,i8x8:chroma_qp_offset=-1:nr=1 -t 180 -r 59.94 -acodec copy 'Squawk Alley like ghb r 5994 - 03-27-2018.mkv' [08:21:06 CEST] <spot> Without the -t 180 in real world use, of course. [08:30:32 CEST] <Ankit> Hi I am unable to build ffmpeg for android can anyone help me out here [08:30:44 CEST] <Ankit> the error comes on the line patching file library.mak patching file libavutil/common.h [08:30:56 CEST] <Ankit> aarch64-linux-android-gcc is unable to create an executable file. C compiler test failed. [09:37:59 CEST] <axew3> hello all, little confused on installing ffmpeg into a centos server, after i execute the last ffmpeg command to install, it return ERROR: vorbis not found using pkg-config, and i note that there are two different folders pkgconfig, one is on /root/ffmpeg_build/lib/pkgconfig and one is on /usr/local/lib/pkgconfig: if i launch th elast install, and i try to set the one or the other, i get ever [09:37:59 CEST] <axew3> the same error ... sorry i'm not so skilled [09:41:45 CEST] <axew3> should i try to copy/paste all files of one into the other, and try out if work in this way? [10:01:45 CEST] <beandog> spot, cool, I'm glad you got it worked out [10:04:32 CEST] <spot> Heh...yeah, but upon closer look, the colors and contrast in the Handbrake encode are better. And, even though Handbrake shows it as encoding at 105 fps and ffmpeg shows 145-155, both take about one hour to encode a 1-hour show. [10:05:33 CEST] <spot> Still, I'm encouraged, and I thank you and furq for helping me. I might try HandBrake-CLI next time I have free time on my hands. [10:06:21 CEST] <spot> Going to bed for real now. [10:08:24 CEST] <beandog> Yeah I noticed you're not setting the colors in ffmpeg. [10:08:29 CEST] <beandog> run a mediainfo diff again [10:08:34 CEST] <beandog> I'm out, too [10:13:11 CEST] <ritsuka> handbrake always sets the color tag (if the original haven't got one, it guesses it), in ffmpeg you have to do i manually [10:26:21 CEST] <axew3> ]# PKG_CONFIG_PATH=/usr/local/lib/pkgconfig [10:26:21 CEST] <axew3> [root@admin573 ffbuild]# pkg-config --list-all [10:26:21 CEST] <axew3> shared-mime-info shared-mime-info - Freedesktop common MIME database [10:26:21 CEST] <axew3> zlib zlib - zlib compression library [10:26:21 CEST] <axew3> freetype2 FreeType 2 - A free, high-quality, and portable font engine. [10:26:22 CEST] <axew3> fontutil FontUtil - Font utilities dirs [10:26:22 CEST] <axew3> systemd systemd - systemd System and Service Manager [10:26:23 CEST] <axew3> udev udev - udev [10:26:23 CEST] <axew3> bash-completion bash-completion - programmable completion for the bash shell [10:26:24 CEST] <axew3> [root@admin573 ffbuild]# export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH [10:26:24 CEST] <axew3> [root@admin57343206 ffbuild]# pkg-config --list-all [10:26:25 CEST] <axew3> systemd systemd - systemd System and Service Manager [10:26:25 CEST] <axew3> fdk-aac Fraunhofer FDK AAC Codec Library - AAC codec library [10:26:26 CEST] <axew3> fontutil FontUtil - Font utilities dirs [10:27:18 CEST] <axew3> pkg-config --exists --print-errors vorbis [10:27:18 CEST] <axew3> Package vorbis was not found in the pkg-config search path. [10:27:18 CEST] <axew3> Perhaps you should add the directory containing `vorbis.pc' [10:27:18 CEST] <axew3> to the PKG_CONFIG_PATH environment variable [10:27:18 CEST] <axew3> No package 'vorbis' found [10:27:19 CEST] <axew3> ERROR: vorbis not found using pkg-config [10:27:48 CEST] <durandal_1707> USE PASTEBIN!!!!!!!! [10:28:11 CEST] <axew3> what i should execute to add also vorbis, which is isntalled, to the PKG_CONFIG_PATH? [10:31:05 CEST] <durandal_1707> it obviously is not installed, or its .pc file is different directory where no utility searches [10:32:31 CEST] <axew3> sorry so what i should do? exactly it is in another directory [10:33:27 CEST] <axew3> What mean use PASTEBIN? please not ban me at this point ... [10:34:01 CEST] <durandal_1707> copy it to directory where are almost all pkg-config files located [10:35:30 CEST] <axew3> @durandal_1707 i will try right now [11:27:55 CEST] <_vince> why is mplayer more popular than ffplay? [11:28:36 CEST] <BtbN> Because it's an actual player [11:28:44 CEST] <BtbN> ffplay is a prove of concept, nothing more [11:29:01 CEST] <_vince> it's slower too [11:29:04 CEST] <BtbN> it's a horrible player though, use mpv instead [11:29:20 CEST] <_vince> as in mplayer is horrible? [11:29:43 CEST] <furq> i wouldn't go that far but you shouldn't be using mplayer [11:30:25 CEST] <_vince> why is that? [11:30:30 CEST] <furq> because mpv exists [11:30:58 CEST] <_vince> does it have more bells and whistles or is it better in performance as well [11:31:13 CEST] <furq> it's just better in general [11:31:53 CEST] <_vince> ill give it a shot thanks [11:32:03 CEST] <_vince> btw can mencoder do anything ffmpeg command cant do? [11:33:09 CEST] <furq> shrug [11:33:11 CEST] <furq> i've never used it [11:33:30 CEST] <durandal_1707> mencoder is unmaintained, it just can use binary codecs, nothing more [11:34:39 CEST] <furq> http://www.mplayerhq.hu/design7/images/left.jpg [11:35:04 CEST] <durandal_1707> old days [11:35:06 CEST] <furq> i always forget about mplayer's fourth-place-at-mekka-&-symposium-2001-ass logo [11:37:22 CEST] <_vince> just tried mpv the track bar lingers for half a second after using the wheel, yuck [11:37:27 CEST] <_vince> it should disappear instantly [11:37:41 CEST] <furq> it's configurable [11:38:16 CEST] <durandal_1707> come one, you complain about players bars? [11:38:22 CEST] <furq> also a few mplayer frontends support mpv as a backend now [11:38:32 CEST] <furq> although it sounds like you're not interested in those [11:39:29 CEST] <_vince> durandal_1707: yeah i'd prefer there were no bar [11:39:36 CEST] <furq> again, that's all configurable [11:39:46 CEST] <_vince> yeah, will look into it now [11:39:57 CEST] <furq> you can disable the osc and/or osd completely if you don't want them [11:44:14 CEST] <_vince> has anyone had success cancelling out machinery noise, especially like washing machine in the background [11:44:52 CEST] <_vince> its not white and cancelling it from a sample also degragess human speech [11:45:39 CEST] <durandal_1707> it doesn't need to be white noise... [12:12:55 CEST] <_vince> so what happened to mplayer2? [12:13:14 CEST] <_vince> i remember a time when people were saying it's the fastest bestest thing [12:13:26 CEST] <_vince> i guess now you reserve that to mpv [12:24:13 CEST] <durandal_1707> _vince: yes, mpv replaced mplayer2 [12:25:37 CEST] <_vince> cool, do you think mpv beats mplayer performance wise [12:26:09 CEST] <JEEB> _vince: basically even the mplayer2 maintainer is now on mpv's development channel, so that was a rather clean switch [12:28:24 CEST] <durandal_1707> _vince: only drawback is that mpv removed binary support from mplayer2 [12:28:37 CEST] <durandal_1707> iirc [12:28:41 CEST] <durandal_1707> might be wrong [12:28:47 CEST] <JEEB> wasn't that already removed with mplayer2? :D [12:28:52 CEST] <JEEB> if not, color me surprised [12:29:38 CEST] <_vince> i dont have a great graphics card and my cpu is pentium 4 so having a speedy player helps a lot [12:29:48 CEST] <_vince> most HD stuff played here lags [12:30:18 CEST] <_vince> i would say mplayer was noticably better than vlc, lets see how mpv goes [12:40:05 CEST] <durandal_1707> _vince: mpv expect modern gpu [12:40:41 CEST] <durandal_1707> not some potato [12:49:31 CEST] <JEEB> there's still some low-end renderers left [12:49:32 CEST] <JEEB> in mpv [12:49:35 CEST] <JEEB> for the dumb devices [13:00:26 CEST] <th3_v0ice> JEEB: Its interesting that transcoding.c example from github is also not transcoding all of the frames. It is missing 2 for the 3.4.2 release. For the latest commit from the master, its missing 9 frames. [14:10:58 CEST] <th3_v0ice> JEEB: I fixed my problem. Thanks for all the help! :) [14:11:23 CEST] <JEEB> cheers [14:11:24 CEST] <JEEB> what was it? [14:19:32 CEST] <th3_v0ice> I was using wrong decoder context to flush :) [14:20:18 CEST] <JEEB> ah [14:20:20 CEST] <JEEB> classic [14:21:59 CEST] <th3_v0ice> Haha, yeah. I knew it was something stupid. [14:22:38 CEST] <th3_v0ice> Decoder contexts are stored in array, was using the wrong index to acess the decoder ctx. [15:48:29 CEST] <joepadmiraal> Hi all. I created a hardware device context with av_hwdevice_ctx_create and decoded a frame with avcodec_send_packet/avcodec_receive_frame. Now I want to use that decoded frame in a cuda kernel. Is this possible? [17:57:20 CEST] <th3_v0ice> joepadmiraal: It is. Decoded frame is just YUV in some specific format (420, 422, 444). Its array of chars if I am not mistaken. [19:49:10 CEST] <SortaCore> hey folks [19:49:36 CEST] <SortaCore> any idea how to boost an MP4's audio volume (without clipping) while retaining the best source quality? [19:49:47 CEST] <furq> replaygain if your player supports it [19:50:33 CEST] <SortaCore> well, I can use 200% in VLC, but I was more wanting the video file boosted itself [19:51:22 CEST] <furq> i mean adding replaygain tags to the file [19:51:30 CEST] <furq> a lot of video players support that [19:51:48 CEST] <SortaCore> how do [19:52:11 CEST] <SortaCore> ah, found it on StackOverflow [19:52:53 CEST] <SortaCore> does replaygain take a value, because I don't know the exact dB to boost it to take it to -0.0dB [19:56:54 CEST] <furq> i don't know if ffmpeg even does it tbh [19:57:01 CEST] <furq> i normally do it in an audio player [19:59:38 CEST] <SortaCore> there's an audio filter called replaygain [19:59:52 CEST] <furq> yeah but filters require reencoding [19:59:59 CEST] <furq> at which point you might as well just change the volume [20:00:50 CEST] <furq> if you're ok with reencoding then -af volumedetect, then -af volume=5dB or whatever value volumedetect gives as max_volume [20:01:51 CEST] <ChocolateArmpits> You should use volumedetect first to determine peak volume, then use the volume filter to compensate accordingly [20:04:32 CEST] <ChocolateArmpits> for true peak display use ebur128 or loudnorm filter [20:06:39 CEST] <SortaCore> re-encoding is ok, just as close to source as possible [20:27:26 CEST] <kepstin> well, re-encoding a lossy file will always have some loss, and it's up to you to figure out codec settings that meet your quality requirements [20:32:26 CEST] <adminjoep> th3_v0ice: Thanks. I tried to feed the AVFrame.data[0] pointer which I received from the avcodec_receive_frame call to my kernel. To thest this I run the kernel with a grid of 5 and simply print a byte from the threadIdx.x position. In order to wait for the kernels to complete I do a MemcpyDtoH. When I run this program it returns this error: MemcpyDtoH failed IllegalAddress. I don't think MemcpyDtoH is the [20:32:28 CEST] <adminjoep> actual problem as when I remove the frame pointer reading from the kernel the program runs without issues. And this includes executing the MemcpyDtoH command. I thought this might be caused by the fact that the kernels run on a different cuda context as the ffmpeg decoder. So I tried to search for ways to retrieve the cuda context from ffmpeg but I did not succeed. Does anyone know if this could be the issue [20:32:30 CEST] <adminjoep> and wheter it is possible to obtain the cuda context? Thanks, Joep. [20:34:56 CEST] <kepstin> adminjoep: which ffmpeg decoder are you actually using? If you're just selecting the default, it's probably just doing a software decode on the cpu. [20:35:37 CEST] <adminjoep> kepstin: I'm using hevc_cuvid [20:38:05 CEST] <kepstin> hmm. Admittedly I haven't done much with hwaccel stuff before, but I was under the impression that you could provide a specific hardware context for the decoder to use when initializing it. [20:39:48 CEST] <BtbN> If you have a CUDA frame, you can get the hw_frames_ctx from it, and the hw_device_ctx from that, and that holds the CUDA context [20:40:09 CEST] <BtbN> Or provide your own hw_device_ctx in the first place [20:56:06 CEST] <SortaCore> hm I boosted by max_volume (6.9dB) but not a very noticeable difference [20:56:16 CEST] <SortaCore> maybe I have to normalise instead [20:59:08 CEST] <ChocolateArmpits> SortaCore, 7db should be pretty evident, unless you expect a very large increase. Open the original and the filtered audio in audacity and compare [20:59:17 CEST] <kepstin> "normalizing" is a bit of an overloaded term, but the standard usage is "increase gain to the max level that doesn't clip" - which is exactly what you just did [20:59:46 CEST] <ChocolateArmpits> kepstin, some software referes to the procedure as "maximizer" [21:01:04 CEST] <SortaCore> hm ok [21:01:14 CEST] <ChocolateArmpits> SortaCore, It could be that there's a single high peak while the rest of the audio is rather quiet, you'd have to compress the audio or increase the volume further -- that single peak may clip but not really sound noticeable [21:01:44 CEST] <SortaCore> actually, the new file is quieter [21:02:16 CEST] <ChocolateArmpits> SortaCore, impossible. Did you input the minus sign rather than a plus sign for the volume filter? [21:02:58 CEST] <SortaCore> no... but i apparently put 6.4d instead of 6.4dB [21:03:03 CEST] <SortaCore> I'll re-run it [21:03:13 CEST] <SortaCore> atm there's no plus or minus [21:03:33 CEST] <SortaCore> now it's noticeably louder,y ea [21:03:34 CEST] <ChocolateArmpits> no sign means additional volume is applied [21:03:52 CEST] <SortaCore> what does d on its own do? [21:04:05 CEST] <ChocolateArmpits> probably nothing, strange it didn't crash [21:04:29 CEST] <SortaCore> no, it just seemed to make it quieter, although not sure to what level [21:10:39 CEST] <apus> while trying to capture vhs content i inevitably run into this error: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1708922 which kills the file. my source is stk1160 the usb video grabber. is there a workaround for this? some patch that i'd need to manually apply to ffmpeg? [21:12:55 CEST] <BtbN> that looks more like a broken driver than anything ffmpeg related [21:14:44 CEST] <apus> as far as i could figure out the problem is in the linux kernel. however, since the issues i found concerning this are sometimes at least 2 years old, i don't expect the solution to come from that side [21:15:34 CEST] <apus> i don't care if i have to disable some if condition somewhere, as long as it works for this problem i'll happily compile a separate ffmpeg [21:15:55 CEST] <JEEB> time to make your own patched version of the kernel module :P [21:16:43 CEST] <apus> if i knew which module was responsible and where i'd need to look, that would be an option. what i can find is the place in the ffmpeg code that outputs the error/warning that ffmpeg throws [21:17:09 CEST] <BtbN> it's a crash, in the driver. Not something you can just "not print". [21:23:07 CEST] <SortaCore> freopen [21:23:21 CEST] <SortaCore> anyway, volume boosted ok, thanks folks [21:23:33 CEST] <SortaCore> catcha later [21:27:22 CEST] <th3_v0ice> adminjoep: Try to copy all of the data and validate that its there. Dont use pointers if you dont know how long they exist. Take a look at this example https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/decode_video.c [22:00:05 CEST] <axew3> running last ffmpeg install step, after addition of all the rest, i hope, it return me ERROR: libx264 not found but i can't find out this file and the final message on terminal return. make [22:00:05 CEST] <axew3> Makefile:2: ffbuild/config.mak: No such file or directory [22:00:05 CEST] <axew3> Makefile:40: /tools/Makefile: No such file or directory [22:00:05 CEST] <axew3> Makefile:41: /ffbuild/common.mak: No such file or directory [22:00:05 CEST] <axew3> Makefile:90: /libavutil/Makefile: No such file or directory [22:00:06 CEST] <axew3> Makefile:90: /ffbuild/library.mak: No such file or directory [22:00:06 CEST] <axew3> Makefile:92: /fftools/Makefile: No such file or directory [22:00:07 CEST] <axew3> Makefile:93: /doc/Makefile: No such file or directory [22:00:07 CEST] <axew3> Makefile:94: /doc/examples/Makefile: No such file or directory [22:00:08 CEST] <axew3> Makefile:160: /tests/Makefile: No such file or directory [22:00:08 CEST] <axew3> make: *** No rule to make target `/tests/Makefile'. Stop. [22:00:09 CEST] <axew3> [root@admin57343206 ffmpeg]# make install [22:00:09 CEST] <axew3> Makefile:2: ffbuild/config.mak: No such file or directory [22:00:10 CEST] <axew3> Makefile:40: /tools/Makefile: No such file or directory [22:26:59 CEST] <apus> are these the kernel modules that cause the problem? are they fixing it at the moment? https://www.mail-archive.com/linux-media@vger.kernel.org/msg128416.html [22:31:47 CEST] <seb_> Hello, I understand not good how to make a multi output with filters (some filter are the same, some are different): ffmpeg -i udp://239.100.0.1:1234 -vf "crop=720:574:0:2, yadif=0, scale=9:8, fps=25" -copyts -f image2 -frame_pts 1 "/tmp/seb/deux/%d.pgm" ffmpeg -i udp://239.100.0.1:1234 -map 0:0 -vf "crop=720:574:0:2, yadif=0, scale=iw/2:ih/2" out.ts [22:32:22 CEST] <seb_> so "crop=720:574:0:2, yadif=0" is the same [22:32:58 CEST] <seb_> I follow https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs [22:33:09 CEST] <seb_> but it doesn't work for me [22:38:43 CEST] <seb_> ffmpeg -i udp://239.100.0.1:1234 -filter_complex '[0:v]crop=720:574:0:2,yadif=0,split=2[out1] [out2]' \ -map 'out1' -vf "scale=9:8, fps=25" -copyts -f image2 -frame_pts 1 "/tmp/seb/deux/%d.pgm" \ -map '[out2]0:0 -vf "scale=iw/2:ih/2" out.ts [22:39:00 CEST] Last message repeated 1 time(s). [22:41:11 CEST] <ChocolateArmpits> seb_, for multiple outputs you need to use a single filtergraph before the first output [22:41:31 CEST] <ChocolateArmpits> not filtergraphs for each output [22:42:06 CEST] <ChocolateArmpits> so place that second scale inside of the initial filter_complex [22:42:22 CEST] <ChocolateArmpits> actually both of them [22:45:11 CEST] <seb_> the first filtre scale is " scale=9:8 " (for the first output) and the for the second output, the filter is "scale=iw/2:ih/2 [22:45:25 CEST] <ChocolateArmpits> so put them both inside the filter_complex [22:45:55 CEST] <seb_> after split? [22:46:17 CEST] <ChocolateArmpits> well yeah because you need them scaled differently [22:46:27 CEST] <seb_> ok thanks [22:46:42 CEST] <ChocolateArmpits> split=2[v1][v2];[v1]scale=...[out1];[v2]scale=...[out2] [22:46:43 CEST] <ChocolateArmpits> like that [22:47:26 CEST] <quint> Is there any information on libaom/AV1 implementation for an ffmpeg release? [22:47:56 CEST] <BtbN> libaom stuff just got merged [22:47:59 CEST] <JEEB> it seems like the libaom wrapper got merged so it will be part of the next release if you really want a release [22:48:06 CEST] <JEEB> (you generally don't want a release with FFmpeg) [22:49:01 CEST] <quint> JEEB: why's that? [22:49:17 CEST] <BtbN> Nobody really cares about releases anyway [22:49:29 CEST] <BtbN> they are arbitrary snapshots, because people and distributions keep asking for them [22:49:37 CEST] <quint> ahh. [22:49:44 CEST] <JEEB> yes, and they get very little attention in general [22:49:59 CEST] <JEEB> which fixes get or get not into a release or releases depends on a whim more or less [22:50:08 CEST] <JEEB> and f.ex. I don't know which releases at this point are supported, even [22:50:14 CEST] <BtbN> security fixes will get in, but other than that... [22:50:24 CEST] <JEEB> possibly not even security fixes [22:50:31 CEST] <JEEB> did the http commit by wm4 get in? [22:50:33 CEST] <JEEB> :D [22:50:49 CEST] <BtbN> There was no release-round since then [22:51:09 CEST] <JEEB> yea but was it back-ported into any release branches? I bet no [22:52:23 CEST] <JEEB> the main thing that get backported are the google fuzzing "security" things which can be useful, but in some cases they are just a pain in a butt. and then the imperfect sanity check can't be removed because of """security""" (and I'd post a patch for a better one but to get the proper limits of all fields for movenc for example is not really easy) [23:02:59 CEST] <seb_> Hello [23:03:25 CEST] <seb_> a little error : "Cannot find a matching stream for unlabeled input pad 0 on filter Parsed_fps_4" [23:03:38 CEST] <seb_> with the command : [23:03:48 CEST] <seb_> ffmpeg -i udp://239.100.0.1:1234 -filter_complex '[0:v]crop=720:574:0:2,yadif=0,split=2[in1][in2];[in1]scale=9:8[out1],fps=25;[in2]scale=iw/2:ih/2[out2]' \ -map '[out1]' -copyts -f image2 -frame_pts 1 "/tmp/seb/deux/%d.pgm" \ -map '[out2]' out.ts [23:38:43 CEST] <spot__> NICK spot [23:38:54 CEST] <spot__> oops [00:00:00 CEST] --- Fri Mar 30 2018

1 0

ffmpeg-devel.log.20180328
by burek 29 Mar '18

29 Mar '18

[00:14:36 CEST] <wm4> seems to be a pattern with shitty dolby things [00:14:58 CEST] <nevcairiel> aac is a dolby thing now? [00:15:19 CEST] <wm4> they have their part in it so it's a good opportunity to hate on dolby [00:15:48 CEST] <nevcairiel> i'm sure they own various patents that play a role (or used to, isnt aac also expiring now) [00:16:08 CEST] <nevcairiel> but its primarily mpeg, not that this is any better [00:16:08 CEST] <wm4> evergreening [00:17:19 CEST] <nevcairiel> dolby has ac-4 and atmos now for making peoples life miserable [00:17:23 CEST] <JEEB> yup [00:17:32 CEST] <JEEB> they even got AC-4 into DASH-IF samples [00:17:51 CEST] <nevcairiel> AC-4 was also adopted by DVB and standardized by ETSI [00:17:56 CEST] <nevcairiel> so it might show up in broadcast some day [00:20:46 CEST] <nevcairiel> object-based audio is so annoying [00:20:53 CEST] <nevcairiel> it might be a nice idea and all, but its just so much work to support [00:21:03 CEST] <nevcairiel> even if someone would make a decoder, still need to figure out a mixer [00:22:10 CEST] <JEEB> yea [00:30:32 CEST] <rcombs> nevcairiel: MPEG-2 AAC is expired [00:30:43 CEST] <rcombs> MPEG-4 AAC-LC is expiring in some countries but not others [00:30:58 CEST] <rcombs> HE and such are evergreen for a fair while [00:32:13 CEST] <rcombs> and the AAC licensing people are owned by Dolby [00:55:28 CEST] <jdarnley> > Windows 7 patch for Meltdown enabled arbitrary reads and writes in kernel memory [00:55:33 CEST] <jdarnley> What a headline! [00:56:11 CEST] <jdarnley> I'm glad I haven't updated Windows since before the telemtry stuff was added. [00:56:41 CEST] <teratorn> hehe when was that? [00:56:57 CEST] <teratorn> jdarnley: earlier versions of windows will send you lots of telemetry if you ask hard enough [00:57:00 CEST] <jdarnley> A couple of years, at least [01:20:57 CEST] <cone-131> ffmpeg 03Mark Thompson 07master:44000b7744a0: hwcontext_d3d11: Fix crash with valid adapter but no device [01:28:08 CEST] <iive> jdarnley, link to the article. Is it the patch that enables read and write? Because Meltdown is about reading kernel memory... [01:28:33 CEST] <TheAMM> https://blog.frizk.net/2018/03/total-meltdown.html [01:28:44 CEST] <iive> jdarnley, can you give a link to the article please... [01:28:51 CEST] <TheAMM> iive: https://blog.frizk.net/2018/03/total-meltdown.html [01:29:01 CEST] <iive> thanks [01:29:03 CEST] <jdarnley> Yeah, that ^ is it [06:33:36 CEST] <cone-105> ffmpeg 03James Almer 07release/3.4:a45ba0881c93: avcodec/mp3_header_decompress: don't free the user provided packet on error [06:47:53 CEST] <cone-105> ffmpeg 03James Almer 07release/3.4:1b9b469cdb1f: avcodec/mpeg4_unpack_bframes: make sure the packet is writable when data needs to be changed [12:03:00 CEST] <JEEB> huh [12:03:20 CEST] <JEEB> I think I just fixed a sample with sub2video [12:03:42 CEST] <JEEB> but I don't have any other way of seeing things other than "umm, this sample I have on hand now works [12:05:07 CEST] <JEEB> also it seems like I just got zero byte file as vsynth_lena.yuv [12:05:28 CEST] <JEEB> when trying to run `make fate-sub2video` [12:51:44 CEST] <Chloe> ./configure --toolchain=llvm-cov doesn't seem to generate gcno files for the fftools on my system, but it generates for all the other objects. Can anyone reproduce? [13:53:34 CEST] <cone-105> ffmpeg 03sanilraut 07master:10d008f0fd9e: avformat/dashdec: Support signaling of last segment number [15:18:38 CEST] <durandal_1707> can i push eac3 patches? [15:40:04 CEST] <nevcairiel> does NEON have 256-bit registers? [15:47:10 CEST] <mateo`> nope AFAIK [18:30:24 CEST] <atomnuker> so rcombs, can you link me the very latest version of your flac image embedding code and the very latest comments for it? [18:36:32 CEST] <jamrial> atomnuker: i sent the last version some time ago. i'll adapt it to use the packet list api i sent to the ml and resubmit it once that's committed [18:37:55 CEST] <jamrial> atomnuker: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220714.html [18:48:17 CEST] <atomnuker> jamrial: oh cool, can't wait [18:48:36 CEST] <atomnuker> would be nice for the cue demuxer to get in as well [18:48:46 CEST] <durandal_1707> looks like there are no reviewers left for my patches, ok i'm leaving [18:54:01 CEST] <atomnuker> durandal_1707: if you so wish for reviews you can still reach the ac3 decoder/encoder author [18:54:11 CEST] <atomnuker> but I'd just apply them [18:57:40 CEST] <durandal_1707> i see three authors, 2 of them missing in action [18:58:19 CEST] <nevcairiel> justin can still be reached if one really wanted to, he just isnt active on his own anymore [18:58:19 CEST] <durandal_1707> and 3rd one is libav developer, who hates us [19:04:57 CEST] <jamrial> https://aomedia.org/the-alliance-for-open-media-kickstarts-video-innovation… [19:06:37 CEST] <atomnuker> that pretty much took all of us by suprise, since on a meeting I thought we agreed the 1st [19:07:37 CEST] <atomnuker> with the 28th - 1st being a period of a few sleepless souls to go over _the entire spec_ to make sure its sane [19:12:58 CEST] <kierank> atomnuker: yes, I still have to fix the vbv documentation [19:15:13 CEST] <atomnuker> yeah, I saw that, someone sent another proposal [19:16:02 CEST] <kierank> yes disregarding everything videolan did [19:16:10 CEST] <kierank> From the people who actually had to implement this (tm) [19:17:15 CEST] <gnafu> Dang, and April 1st release would've been /awesome/. [19:35:52 CEST] <jamrial> everyone would have doubted it was real, heh [19:55:44 CEST] <atomnuker> kierank: https://elpais.com/elpais/2018/03/28/inenglish/1522226565_816740.html?id_ex… [19:55:47 CEST] <atomnuker> justice [19:56:04 CEST] <kierank> atomnuker: but you bring a water bottle and fill it, no? [19:57:22 CEST] <wm4> reminds me how I bought about a glass of water for like 5¬ at munich airport [19:58:13 CEST] <atomnuker> yeah, its out of control in germany, by far the most expensive water anywhere [20:24:10 CEST] <cone-624> ffmpeg 03Diego Biurrun 07master:9c37d765ef28: configure: Add check_cc/require_cc helper functions to simplify some expressions [20:24:10 CEST] <cone-624> ffmpeg 03Diego Biurrun 07master:18dc1ff0fb45: configure: Add check_ld() helper function to simplify some expressions [20:24:10 CEST] <cone-624> ffmpeg 03James Almer 07master:67e8f476b7d3: Merge commit '9c37d765ef28b027414f86b0088b0c282a3c46d8' [20:24:10 CEST] <cone-624> ffmpeg 03James Almer 07master:c00b218a8f75: Merge commit '18dc1ff0fb4572b1d50a44905aa1e76bc3bbb0ad' [20:29:33 CEST] <cone-624> ffmpeg 03Diego Biurrun 07master:31a53ab34e22: configure: Add check_as() helper function to simplify some expressions [20:29:34 CEST] <cone-624> ffmpeg 03James Almer 07master:23ba9b3fd1fe: Merge commit '31a53ab34e22fe1eec902f79ec1f19ab828a7a0c' [20:29:53 CEST] <durandal_1707> i gonna sent improved bitstream filters, so just reply LGTM so I can push both patches and than write fate one for both decoder and bsf [20:32:43 CEST] <durandal_1707> also, should i update Changelog for new bsf and decoder improvement? [20:35:06 CEST] <pgorley> i've been fiddling around with the libx264 wrapper, and found a way to get region of interest coding working. would such a patch be interesting for ffmpeg to have? [20:35:23 CEST] <atomnuker> durandal_1707: yes [20:38:36 CEST] <cone-624> ffmpeg 03Alexander Kravchenko 07master:80a4e6a46f21: amf: Replace writer_id option with LIBAV_AMF_WRITER_ID constant [20:38:37 CEST] <cone-624> ffmpeg 03James Almer 07master:c00579ab32aa: Merge commit '80a4e6a46f21256e9bf508ead686563616945ad5' [20:41:56 CEST] <jamrial> durandal_1707: yes, new bsf and support for new features in eac3 are worth a mention in changelog [20:42:37 CEST] <cone-624> ffmpeg 03Diego Biurrun 07master:dd7e63af93b2: configure: Restore original endianness test [20:42:38 CEST] <cone-624> ffmpeg 03James Almer 07master:18195e570cfb: Merge commit 'dd7e63af93b2430b5d42b87a966160c66736342c' [20:48:21 CEST] <cone-624> ffmpeg 03Luca Barbato 07master:44a1731011e8: ivf: Support VP9 and AV1 as well [20:48:22 CEST] <cone-624> ffmpeg 03James Almer 07master:cbd5e737fee5: Merge commit '44a1731011e87fbf4180d026aefb8bfe85d8c7dc' [20:54:29 CEST] <durandal_1707> i like when some inoccent change in code changes several unrelated fate test, like seeking rm with ac3 - come on! [20:58:02 CEST] <jamrial> ac3 in rm? [21:00:05 CEST] <jamrial> BBB: ping [21:00:39 CEST] <BBB> jamrial: pong [21:01:29 CEST] <jamrial> BBB: i'm about to merge the libaom wrapper from libav. did you make any changes to it that i need to keep in mind? [21:01:41 CEST] <BBB> probably not [21:01:45 CEST] <BBB> not sure [21:01:50 CEST] <BBB> did you check my github version? [21:02:19 CEST] <BBB> https://github.com/rbultje/ffmpeg/commit/d96a0aad4633d22c03e930bc10689c4144… [21:02:31 CEST] <jamrial> yeah, but it's a couple months older than the one commited to libav [21:02:33 CEST] <jamrial> i was wondering if you had made any extra changes to it locally [21:03:45 CEST] <BBB> just API updates [21:03:47 CEST] <BBB> otherwise no [21:04:06 CEST] <jamrial> ok, thanks [21:04:52 CEST] <JEEB> I last did the same thing in feb at FOSDEM and it was just a function signature update thing IIRC [21:05:19 CEST] <JEEB> https://github.com/jeeb/ffmpeg/commit/c695fe54668b3b948a5a754f6b09edc7bdc4a… [21:05:27 CEST] <JEEB> which the libav patch most likely has [21:05:38 CEST] <BBB> right [21:05:44 CEST] <BBB> sorry I havent kept my github uptodate [21:07:28 CEST] <atomnuker> I'm not sure how that will work considering most commits nowadays break the api [21:12:56 CEST] <atomnuker> durandal_1707: does the bsf convert eac3 to ac3? I'm not sure what the core is [21:16:53 CEST] <durandal_1707> atomnuker: nope, this just removes frames marked which depends on previous frame [21:17:06 CEST] <durandal_1707> and it is only for eac3 [21:20:09 CEST] <durandal_1707> eac3 core is also called dolby digital, or shorter DD [21:21:09 CEST] <durandal_1707> eac3 7.1 (only available in wild, even extension make it possible for more channels) is called dolby digital plus, or shorter DD+ [21:52:41 CEST] <Meins> Hello [21:58:49 CEST] <durandal_1707> jamrial: review and 1st patch too [22:02:39 CEST] <jamrial> durandal_1707: can't review that one, but that seek_rm fate change looks funny. it returns a bunch of video packets instead of audio now [22:03:26 CEST] <durandal_1707> its for seeking [22:04:08 CEST] <Mina> Hi, I've made a proposal of my own idea for a project regarding GSoC and thought I'd share it; maybe you'd share my interest. Is this the right place to do so? [22:10:30 CEST] <Chloe> Mina: this? http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227141.html [22:12:18 CEST] <Mina> This is me but not what I mean. I was originally applying for the SRCNN project introduced by FFmpeg GSoC page, and this is the required task for it. [22:13:05 CEST] <Mina> Later I was suggested to apply for another project to have higher chances since lot of people were applying for this specific project. [22:13:18 CEST] <Chloe> Right, so what's your idea? [22:13:40 CEST] <Mina> So I applied with a new project, this: http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227377.html [22:20:18 CEST] <durandal_1707> i think you had better contacted with new ideas first, now it is too late [22:21:02 CEST] <Mina> I was suggested to apply for a new project with 20 hours left, didn't mean to be late. [22:21:28 CEST] <Mina> I thought I'd share the idea in hopes of convincing a possible mentor. [22:22:04 CEST] <rcombs> durandal_1707: s/eac3 core/ac3 core/? [22:22:10 CEST] <Mina> A mentor is already interested in the idea but he was searching for another co-mentor for the project. [22:22:28 CEST] <rcombs> afaik "DD" is ac3 and "DD+" is eac3 [22:22:30 CEST] <Mina> backup mentor* [22:25:09 CEST] <Chloe> Mina: who is the mentor [22:27:05 CEST] <Mina> Mr Thilo Borgmann [22:27:32 CEST] <durandal_1707> rcombs: nope, ac3 does not have extensions [22:27:43 CEST] <rcombs> didn't say it did [22:28:40 CEST] <durandal_1707> rcombs: extension is for eac3, i did not mentioned file name for that reason [22:29:11 CEST] <rcombs> yeah, I'm just referring to the DD/DD+ branding [22:29:16 CEST] <Chloe> Mina: I have no experience in colour correction stuff, otherwise I'd offer to be a backup mentor. Sorry [22:32:02 CEST] <Mina> Thanks for the thought still. Do you know someone who has? I already have strong knowledge and working experience of the field so I wouldn't be a burden. [22:33:22 CEST] <durandal_1707> Mina: what code would use? some other library? [22:34:57 CEST] <durandal_1707> i have some experience with color correction, but i need more info what you gonna do. [22:35:19 CEST] <Mina> I think the only thing I may need other than FFmpeg is a machine learning framework. [22:36:40 CEST] <Mina> The filter mainly exploits low-level image statistics but machine learning can be introduced to improve accuracy to state of art results [22:37:15 CEST] <durandal_1707> what would it to? [22:37:39 CEST] <Mina> What does it refer to? The filter or the framework? [22:37:49 CEST] <durandal_1707> filter [22:38:48 CEST] <Mina> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227377.html this link pretty summarize the idea [22:38:57 CEST] <Mina> But I can write it here if you want [22:39:09 CEST] <Mina> email* [22:39:25 CEST] <Mina> summarize* [22:40:17 CEST] <durandal_1707> is this retinex filter? [22:40:43 CEST] <Mina> That's one variation of the filter. [22:41:02 CEST] <durandal_1707> now i get it [22:41:26 CEST] <Mina> This is still a research filed, so it'd be really great if FFmpeg contributed to it. [22:41:51 CEST] <Mina> New methods and papers are still being published up to date [22:42:17 CEST] <Mina> And I don't think FFmpeg has the simplest variation yet [22:43:10 CEST] <Mina> https://imgur.com/a/hj2ox this link shows a simple example of what this filter would do [22:43:14 CEST] <durandal_1707> actually i have ported retinex from other codebase: http://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178452.html [22:43:27 CEST] <durandal_1707> i just never comitted it to ffmpeg [22:44:27 CEST] <Mina> So you know how useful this filter is for computer vision for example [22:45:08 CEST] <Mina> And introduction of machine learning to this field (color constancy) is fairly recent [22:45:35 CEST] <durandal_1707> so you would also mostly do research? [22:47:10 CEST] <Mina> Yes, most probably. My workflow introduced in the proposal was filtering and ranking variations of the filter and implementing them one by one while researching for ways to improve them if possible [22:48:05 CEST] <Mina> Variations meets different needs like real-time constraint and accuracy, that's why it's not just one algorithm. [22:48:17 CEST] <Mina> meet* [22:49:33 CEST] <durandal_1707> Mina: if you really just need backup mentor, i can be backup mentor. [22:50:48 CEST] <Mina> That'd be really great. As I earlier mentioned, Mr Thile replied to my proposal and I quote:"this sound like a useful filter to me and I'd like to hear more thoughts about that from others. I'd appreciate if someone would be willing to mentor volunteer to mentor that - I can definitely co-mentor this. Thanks, Thilo" [22:50:55 CEST] <Mina> Thilo* [22:52:02 CEST] <durandal_1707> i wonder, why it is sent only to you? was this via mail? [22:52:37 CEST] <Mina> Yes it was. Don't know why it's only sent to me tho. [22:52:57 CEST] <Mina> He also was the one that suggested I'd come here asking for help. [22:53:56 CEST] <durandal_1707> Mina: well, aski him how should you procceed, and mention that you have backup mentor [22:55:00 CEST] <Mina> Great, will send him and email right away. I really appreciate your help. How should I address you in the email? [22:55:05 CEST] <Mina> an* [22:56:32 CEST] <durandal_1707> Mina: well, if you look at that retinex link i posted here, you would know [22:59:12 CEST] <Mina> Great. Thanks :D [23:10:59 CEST] <Mina> Chloe: If I may ask, are you of experience in audio processing then? Because I originally was going for an audio-related proposal featuring machine learning but unlike color constancy didn't have a solid idea for a proposal. [23:11:25 CEST] <Chloe> My experience is mainly in ffmpeg as a project [23:11:49 CEST] <Mina> Okay. [23:12:44 CEST] <Mina> I will leave now and come back when I have Mr Thilo's reply then. [23:13:15 CEST] <Mina> Thanks for your time and effort. [23:14:09 CEST] <cone-624> ffmpeg 03Luca Barbato 07master:c438899a7064: Add AV1 video decoding support through libaom [23:14:10 CEST] <cone-624> ffmpeg 03James Almer 07master:0dc11d8bbd47: Merge commit 'c438899a706422b8362a13714580e988be4d638b' [23:14:17 CEST] <jamrial> BBB: ^ [23:14:22 CEST] <jamrial> if you want to test [23:14:30 CEST] <nevcairiel> where is ffav1 [23:14:46 CEST] <BBB> sweet sweet sweet [23:14:49 CEST] <BBB> what is ffav1? [23:14:54 CEST] <durandal_1707> atomnuker is writing av1 replacement [23:14:56 CEST] <jamrial> nevcairiel: the bitstream isn't evne frozen yet :p [23:16:42 CEST] <nevcairiel> BBB: native decoder [23:16:50 CEST] <BBB> oh, youre writing one? [23:16:53 CEST] <BBB> thats amazing! :-p [23:16:57 CEST] <nevcairiel> of course not [23:16:57 CEST] <jamrial> took me 20 minutes to encode a 20 frame sample using libaom to test the above [23:17:07 CEST] <jamrial> 1280x720 [23:17:09 CEST] <nevcairiel> arent you? its only logical, its the continuation of vp9 =p [23:17:13 CEST] <BBB> thats pretty fast :) [23:17:20 CEST] <BBB> I heard it can take 3 days per frame for higher res [23:17:39 CEST] <jamrial> sounds like a format that will get adoption alright :p [23:18:05 CEST] <kepstin> looks like the bitstream is frozen, as of today [23:18:11 CEST] <kepstin> from the press release they put out [23:18:27 CEST] <jamrial> no, that was a pr stunt it seems. JEEB knows more [23:18:46 CEST] <nevcairiel> yeah thats just PR for NAB [23:19:12 CEST] <BBB> nevcairiel: hm& so& I probably will& but encoder first [23:19:15 CEST] <kepstin> hmm, that's a pretty misleading pr. [23:20:40 CEST] <jamrial> BBB: eve2? [23:20:49 CEST] <BBB> yeah [23:21:10 CEST] <kierank> BBB: what days are you at nab [23:21:14 CEST] <jamrial> in any case, really looking forward to an av1 decoder from you [23:21:18 CEST] <BBB> tue-wed or tue-thu [23:21:18 CEST] <jamrial> ffvp9 is really fucking good [23:21:26 CEST] <BBB> ty ;) [23:21:30 CEST] <BBB> it was fun to do, yes [23:21:35 CEST] <BBB> and av1 needs a better decoder [23:21:38 CEST] <JEEB> ffvp9 - because 2160p60 works fine with just a 4790K [23:21:39 CEST] <kierank> BBB: ok [23:21:48 CEST] <BBB> kierank: whats going on on thu? [23:21:58 CEST] <BBB> jb said hes going on thu but I dont see anything interesting on thu [23:21:59 CEST] <jamrial> when you can decode 1080p 24fps vp9 video without framedrops on an Athlon 64 x2 (no ssse3), you know you did something right [23:22:06 CEST] <JEEB> :) [23:22:08 CEST] <BBB> oh, right [23:22:08 CEST] <kierank> BBB: thursday is useless apart from the av1 announcement [23:22:10 CEST] <BBB> about that [23:22:14 CEST] <BBB> so [23:22:15 CEST] Action: kierank leaving on thursday [23:22:23 CEST] <BBB> ffav1 will probably be avx2 only initially [23:22:30 CEST] <BBB> as in, I dont know if Ill write sse2 again [23:22:35 CEST] <jamrial> that's fine [23:22:39 CEST] <BBB> but maybe at some point later [23:22:43 CEST] <jamrial> i got rid of that athlon a couple years ago :p [23:22:55 CEST] <nevcairiel> as long as you dont make it avx512-only or something crazy =p [23:22:56 CEST] <BBB> that sounds like a morally upright decision [23:23:08 CEST] <BBB> kierank: isnt av1 tue? [23:23:19 CEST] <BBB> kierank: and some chattertychat on wed [23:23:22 CEST] <BBB> but mostly te [23:23:23 CEST] <BBB> tue [23:23:51 CEST] <kierank> erm maybe, that website is annoying [23:23:54 CEST] <BBB> yes [23:23:56 CEST] <BBB> it is [23:24:02 CEST] <BBB> I hate it [23:24:10 CEST] <kepstin> https://aomedia.org/news/aomedia-at-nab/ has the schedule and locations [23:24:10 CEST] <BBB> so if I leave wed night, thats ok? [23:24:24 CEST] <BBB> says tue and wed [23:24:27 CEST] <kepstin> (as an image, because... :/) [23:24:53 CEST] <kierank> BBB: yes thursday is pointless [23:25:36 CEST] <BBB> ok, then, I guess Ill leave wed late in the night, around midnight [23:25:39 CEST] <BBB> so 2 days then [23:29:10 CEST] <BBB> Im starting to dislike asan, which is kind of scary [23:29:44 CEST] <BBB> if an application uses a fair amount of stack, youll get random stack overruns with asan enabled, which isnt helpful at all [23:29:45 CEST] <BBB> :-/ [23:29:50 CEST] <BBB> any solution to that? [23:37:39 CEST] <durandal_1707> i gonna apply eac3 patchset now! [23:37:56 CEST] <nevcairiel> noooooo! [23:38:53 CEST] <wm4> did you figure out the various things [23:39:22 CEST] <wm4> different ways of muxing (split/merged), channel layouts, midstream config changes [23:40:05 CEST] <nevcairiel> if its muxed split in mkv you might need to force the parser to be used [23:40:09 CEST] <nevcairiel> not sure if thats actually the case [23:40:49 CEST] <nevcairiel> the layouts should be fine, and changes should also be fine, since it handles the channel map on every audio frame [23:42:30 CEST] <nevcairiel> if you tried to remux this with ffmpeg before the patch you might get crazy broken files [23:42:37 CEST] <nevcairiel> more broken then just split, probably [23:46:39 CEST] <wm4> heh [23:47:25 CEST] <JEEB> hah, I had completely missed how we actually have an ocr filter [23:47:25 CEST] <JEEB> lol [23:47:33 CEST] <wm4> aren't there muxers which don't even split mp3 streams on packet boundaries? I think eac3 was also affected [23:48:00 CEST] <JEEB> yes, mp4box created some fabulous mp3-in-mp4 [23:49:01 CEST] <durandal_1707> nevcairiel: do you actually have mkv with eac 7.1 in it? [23:49:22 CEST] <durandal_1707> i'm not gonna support invalid files [23:49:40 CEST] <nevcairiel> i have a blu-ray, and i have makemkv, so i can make one in 5 minutes! [23:53:00 CEST] <durandal_1707> what is makemkv command? [23:53:31 CEST] <nevcairiel> it has a gui, what do i know [23:54:25 CEST] <durandal_1707> i'm now very dissapointed [23:54:50 CEST] <nevcairiel> but it makes no difference either way, if its muxed split we'll just need to enable the parser, if its one, nothing to do, its somewhat independent of the decoder commit [23:57:28 CEST] <durandal_1707> wouldn't mkvmerge create invalid files after all [23:59:21 CEST] <nevcairiel> oh the ac3 parser is silly anyway, it doesnt support headers-only mode and always does packet sp litting [23:59:45 CEST] <nevcairiel> it appears its muxed properly in mkv [00:00:00 CEST] --- Thu Mar 29 2018

1 0

ffmpeg.log.20180328
by burek 29 Mar '18

29 Mar '18

[00:45:43 CEST] <user234234> Hi, I asked 2 days ago about an audio problem with an USB grabber and found out that it is solved in the current git state. Static builds from johnvansickle.com are still to old so I'm simply compiling it myself statically against musl. I do get an error about a missing library (ERROR: libfdk_aac not found) despite having it set via --enable-libfdk-aac --enable-nonfree --extra-ldflags=-L/prefix/lib. The library [00:45:43 CEST] <user234234> libfdk-aac.a and the pkgconfig are there. Could someone with more insight please help? [00:56:18 CEST] <DHE> user234234: your pkgconfig might not be searching the right path. /usr/local/lib/pkg-config (the default for most default compiler installations) isn't on the default [00:57:22 CEST] <furq> user234234: there's probably a more descriptive error near the end of ffbuild/config.log [00:59:51 CEST] <user234234> A lot of "relocation * against symbol `*' can not be used when making a shared object; recompile with -fPIC" messages ... - Thanks for pointing out that log [01:00:36 CEST] <furq> are you building ffmpeg with --enable-shared [01:01:11 CEST] <furq> you need to build all your static libs with -fPIC if you are [01:01:21 CEST] <furq> or alternatively you could just build a static ffmpeg which is way easier [01:01:46 CEST] <user234234> forgot to disable dynamically linked ffmpeg building ... [01:02:26 CEST] <furq> it would be nice if that configure error message was made a bit more verbose [01:02:41 CEST] <furq> granted it does tell you to check config.log but we still get this question an awful lot [01:05:49 CEST] <user234234> that would be cool if it would be mentioned on error of the ./configure script [01:06:36 CEST] <user234234> --disable-shared did nothing. My compiler setup probably already disables it by default. I'll try -fPIC. [01:07:53 CEST] <furq> --enable-static? [01:08:04 CEST] <furq> that should be the default though so shrug [01:09:29 CEST] <furq> you probably also want --extra-ldflags="-static" --pkg-config-flags="--static" [01:09:41 CEST] <furq> for a fully static binary [01:09:46 CEST] <furq> (other than libc) [01:15:08 CEST] <user234234> ok thanks for the help. I probably try tommorow again a bit recompiling all libs. Already late. gn [01:29:57 CEST] <jpabq_> HI all. I want to make use of ff_load_image. I am building ffmpeg from git branch 3.4. It is building libavfilter/lavfutils.c and is showing up in the libavfilter.a , but the libavfilter/lavfutils.h file does not get installed with the other headers. Is ff_load_image considered 'private', or something like that? [01:32:22 CEST] <JEEB> yes [01:32:28 CEST] <JEEB> everything starting with ff_ is private [01:33:01 CEST] <jpabq_> Ah, okay. Thanks. So, if I want to load an image into a frame, what is the correct way? [01:33:53 CEST] <JEEB> open an avformat context, read the AVPacket (most likely singular in the file), then open an avcodec context for it for decoding [01:34:03 CEST] <JEEB> then https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [01:34:11 CEST] <JEEB> follow that for how to decode [01:34:18 CEST] <JEEB> then you will receive an AVFrame [01:34:22 CEST] <JEEB> which is the raw decoded picture [01:34:37 CEST] <jpabq_> JEEB: thank you. I will look at that. [01:36:13 CEST] <JEEB> also take a look at doc/examples, although some examples are not top-notch. see open_input_file in transcoding.c example for example [01:36:55 CEST] <JEEB> also generally it is recommended to deal with master, as everyone is focused on that, if only possible. the releases really get a random() amount of focus [01:37:14 CEST] <JEEB> http://fate.ffmpeg.org/ is a way of checking how things generally seem to be in current master [01:37:23 CEST] <JEEB> it's the automated testing suite [01:37:27 CEST] <jpabq_> Good to know. Thanks again. [01:38:00 CEST] <JEEB> 25 [01:38:11 CEST] <JEEB> but yea, that should get you started :) [09:52:01 CEST] <confusedjoe32> cock [10:46:59 CEST] <meins> Hello [10:48:44 CEST] <meins> i have a Problem with a the avformat_find_stream_info function [12:52:02 CEST] <apus> hi, i would like to convert my vhs tapes. is there a way of using ffmpeg to encode the signal received via usb video grabber directly to x264 or x265 in a way that is as lossless as possible, so that i have enough raw material to be able to postprocess the video afterwards? the format is PAL, 576i [13:04:14 CEST] <DHE> apus: true lossless with x264 means using -qp 0 and a -pix_fmt that is lossless (yuv444, rgb, etc) [13:26:36 CEST] <th3_v0ice> Hi guys. Is it possible that av_interleaved_write_frame is somehow duplicating packets it writes? Because I marked frames with numbers that I am sending to encoder and encoded frames that come out have the same numbers and in same order. But when I write it to .H264 file and decode that same file to YUV it contains first frame two times. Am I doing something wrong or is this some kind of a bug? [13:28:25 CEST] <JEEB> it shouldn't duplicate unless you're sending it the same AVPacket [13:28:53 CEST] <apus> DHE: from what i see this results in really high file sizes. is there a way to get "nearly" lossless when talking about archiving vhs streams while applying a good compression? [13:29:21 CEST] <JEEB> DHE: the pix_fmt should be the same as the source one, no need to make it RGB or 4:4:4 [13:29:34 CEST] <JEEB> because as long as you have no difference in it, you should be OK [13:30:11 CEST] <JEEB> apus: sure, low'ish CRF value instead of qp 0. it's not lossless of course [13:31:16 CEST] <apus> JEEB: something like this a "good" option: ffmpeg -f v4l2 -standard PAL -thread_queue_size 512 -i /dev/video0 -f alsa -thread_queue_size 512 -i hw:2,0 -vcodec libx264 -preset superfast -crf 8 -s 720x576 -r 25 -aspect 4:3 -acodec libmp3lame -b:a 128k -channels 2 -ar 48000 out.avi ? [13:35:18 CEST] <GuiToris> hello, is anyone active now or I should come back later? [13:35:36 CEST] <pmjdebru1jn> just ask and wait around for an answer [13:35:50 CEST] <JEEB> apus: > superfast > expecting compression [13:35:55 CEST] <GuiToris> I'll ask it but I need to leave soon [13:35:56 CEST] <GuiToris> so [13:36:08 CEST] <JEEB> apus: but yes, around that range maybe for CRF? [13:37:08 CEST] <GuiToris> my nephew got a dvd but my sister doesn't have a dvd player, I thought I would rip it by ffmpeg. I did ffmpeg -i /path/to/dvd /path/to/file.mkv but I only got the first chapter [13:37:20 CEST] <GuiToris> which is not the cartoon [13:37:36 CEST] <JEEB> with lossless of course the preset only affects compression ratios [13:37:57 CEST] <JEEB> also not sure how much you'd gain with that sort of content :) [13:38:08 CEST] <JEEB> although superfast *is* rather "dumb" [13:45:48 CEST] <GuiToris> should I use handbrake? [13:50:27 CEST] <iive> GuiToris, yes, if it works for you. [13:50:47 CEST] <apus> JEEB: so just leave that preset option out? i'm trying that command out at the moment and after a few seconds/minutes i always get: Dequeued v4l2 buffer contains 414720 bytes, but 829440 were expected. Flags: 0x00002001. /dev/video0: Invalid data found when processing input This issues seems to be because of the driver stk1160. is there a solution? https://superuser.com/questions/1048637/ffmpeg-video-recording-freezes-afte… [13:50:48 CEST] <apus> processing-input [13:59:55 CEST] <JEEB> apus: oh right, realtime [14:00:17 CEST] <JEEB> also there's more presets than medium or superfast :) [14:00:40 CEST] <JEEB> I would recommend using a faster preset (ultra/superfast) for the lossless capture, and then you can use a slower preset to re-encode that [14:07:56 CEST] <DHE> JEEB: point taken about the source pix_fmt thing [14:13:21 CEST] <GuiToris> thanks iive [14:13:33 CEST] <GuiToris> I need to go now, see you all :) [15:41:50 CEST] <kiroma> Hey, I can't compile ffmpeg [15:42:22 CEST] <kiroma> Just pulled it and it fails with undeclared function [15:42:28 CEST] <kiroma> https://pastebin.com/XsMzeHqK [15:43:43 CEST] <kiroma> Could be related to --enable-hardcoded-tables [15:43:57 CEST] <c_14> could be, wouldn't be the first time that broke [15:44:06 CEST] <c_14> is AV_INPUT_BUFFER_PADDING_MAX defined in the source? [15:44:11 CEST] <c_14> s/MAX/SIZE [15:45:37 CEST] <kiroma> Should be, where do I check that? [15:47:06 CEST] <kiroma> Alright it's defined in avcodec.h [15:48:33 CEST] <c_14> Have you tried compiling without --enable-hardcoded-tables? [15:48:46 CEST] <kiroma> Yes, it's working. [15:50:42 CEST] <c_14> yeah, one of the fate machines with hardcoded tables is also failing [15:50:44 CEST] <c_14> looks like a bug [15:51:05 CEST] <c_14> Can you report it on trac? (and preferably bisect to find the commit that makes it fail) [15:52:09 CEST] <kiroma> Alright, give me a minute to bisect and I'll report it. [15:54:49 CEST] <kalipso> hey guys, i have a webm with a size of about 50mb and want to compress it down to a size of maximal 6mb, is there any command so that ffmpeg reduces resolution, ect automaticly to get to a fixed sizes? [15:58:32 CEST] <kiroma> You can use two pass encoding. [16:01:44 CEST] <kiroma> How do I tell make to compile a specific file? [16:02:38 CEST] <kiroma> oh nvm [16:04:56 CEST] <c_14> kalipso: no, like kiroma said you can use two-pass encoding to get a certain filesize but you have to decide on the resolution yourself [16:13:47 CEST] <c_14> kiroma: it's this commit e529fe7633762cb26a665fb6dee3be29b15285cc it's been reported on the ml already [16:13:51 CEST] <c_14> so there should be a fix soon" [16:14:00 CEST] <kiroma> Oh okay thanks [16:14:13 CEST] <c_14> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227466.html [16:15:28 CEST] <c_14> you can just revert the commit or build one commit before that if you want to build from git with hardcoded-tables [18:14:09 CEST] <th3_v0ice> Hi guys, I am using the new API to decode frames, but even when I send a NULL to avcodec_send_packet, so I can drain my remaining frames, avcodec_receive_frame just returns EOF, and I know there are more frames in the input file because FFmpeg outputs them. 3 frames are missing from the end. Does anyone know what can be the problem? [18:15:27 CEST] <JEEB> which video format out of interest? and FFmpeg version? [18:15:44 CEST] <JEEB> Also ffmpeg.c utilizes the same APIs as far as I know [18:15:49 CEST] <JEEB> the send/receive one [18:21:46 CEST] <th3_v0ice> JEEB: video format is mp4, and FFmpeg version is 3.4.2 [18:25:56 CEST] <th3_v0ice> and is this flag "avctx->internal->draining" supposed to be set to 1? Because its set to 0 even after sending the NULL packet. [18:26:19 CEST] <JEEB> with format I meant the actual avcodec side of things [18:26:31 CEST] <JEEB> and I would recommend testing with master [18:27:06 CEST] <JEEB> although I'm pretty sure my tests from like summer last year had the flushing work [18:27:44 CEST] <th3_v0ice> Its h264 video [18:28:26 CEST] <JEEB> ok, that should have worked but I have not tested 3.4.x specifically [18:33:17 CEST] <th3_v0ice> Well its working in FFmpeg so we can assume that I am doing something wrong :) [18:39:44 CEST] <JEEB> yea, ffmpeg.c is using that API as I can see by decode() in it [18:40:44 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html and https://www.ffmpeg.org/doxygen/trunk/group__lavc__decoding.html#ga58bc4bf1e… / https://www.ffmpeg.org/doxygen/trunk/group__lavc__decoding.html#ga11e6542c4… [18:40:49 CEST] <JEEB> should be enough docs [18:53:58 CEST] <apus> i'm trying to convert VHS content in real time from a usb 2.0 video grabber to x264 (ultrafast) and mp3 (audio). i even tried aac. for whatever reason after a few minutes i always get Non-monotonous DTS ... Any solutions? ffmpeg -f v4l2 -standard PAL -thread_queue_size 512 -i /dev/video0 -f alsa -thread_queue_size 512 -i hw:2,0 -vcodec libx264 -preset ultrafast -crf 12 -s 720x576 -r 25 -aspect 4:3 -acodec libmp3lame -b:a 128k -channels 2 -ar 48000 out.avi [18:55:22 CEST] <th3_v0ice> JEEB: Thanks for the help! [18:55:37 CEST] <dystopia_> crf 12 seems kinda pointless [18:56:27 CEST] <dystopia_> a crf of 21 and a -preset of slow would be better imo and you would probably be able to do it in realtime without issue, [18:57:11 CEST] <apus> i have to post-process the thing afterwards. thought i'd keep the data until that is finished. afterwards i can choose those options [18:57:23 CEST] <dystopia_> also, it's probably 576i [18:57:31 CEST] <dystopia_> so you might want to deinterlace on the fly also [18:57:40 CEST] <dystopia_> -vf yadif=0:0 [18:58:15 CEST] <dystopia_> well doing it after doesn't help when the orignal capture is lossy [18:58:16 CEST] <Meins> can someone help me with streaming. ffmpeg Needs a lot of time to Show me the stream [18:58:52 CEST] <dystopia_> regarding the error "Non-monotonous DTS" i get it occasionally too [18:58:59 CEST] <apus> dystopia_: so i'd better just save it completely lossless and only afterwards use x264 on it? [18:59:05 CEST] <dystopia_> i wouldn't worry about it unless the video is messed up [18:59:34 CEST] <apus> the non-monotonous DTS error appears constantly from some point onward. like 5 per second [18:59:38 CEST] <dystopia_> not completly lossless, but go to your desired output on the fly, it's only sd at 25fps so your pc can more than handle going staight to the output [19:00:08 CEST] <apus> anything else i'd need to handle on-the-fly aside from yadif? [19:00:19 CEST] <dystopia_> crop [19:00:55 CEST] <dystopia_> the original resolution might be 720x576 but that likely has postbox bars that need cropping [19:02:00 CEST] <Meins> the function avformat_find_stream_info Needs toooo much time to analyze the stream [19:02:44 CEST] <dystopia_> -vf crop=desired_width:desired_hight:pixels_cropped_from_left:pixels_Cropped_from_top,yadif=0:0,setsar=1/1 [19:02:49 CEST] <dystopia_> for video filter [19:04:37 CEST] <dystopia_> eg, -vf crop=crop=720:300:0:138,yadif=0:0,setsar=1/1 [19:05:00 CEST] <dystopia_> somthing like that would crop 138 pixels from top and bottom, deinterlace and set sar [19:05:18 CEST] <dystopia_> but you need to work out correct crop value for your video [19:05:31 CEST] <dystopia_> everyone is likely to be slightly diffrent [19:18:12 CEST] <apus> okay. i'll try that. thanks! [20:14:40 CEST] <th3_v0ice> JEEB: I just did a few tests. I had 3 sequences, one with only I frames. This one decoded in full, drain loop working properly. Second one with I & P frames, this one also decoded correctly. But the third sequence which has I & P & B frames doesnt decode last few frames. Does this rings any bells? Thanks! [20:15:39 CEST] <JEEB> th3_v0ice: B-frames and threads are what usually bring in latency in getting back pictures, which is why flushing is so important [20:15:58 CEST] <JEEB> latency as in you are not getting pictures back right away [20:16:36 CEST] <JEEB> with b-frames it's the re-ordering delay, and then you have threads giving you delay [20:16:49 CEST] <th3_v0ice> But I did send a NULL packet, and I did while(ret >= 0) avcodec_receive_frame. Is there something else that I need to do? [20:18:21 CEST] <th3_v0ice> or, how can I know when these pictures are available? What am I missing here? [20:19:09 CEST] <JEEB> if you start flushing that's the end of decoding, and all decode'able pictures should be returned [20:20:58 CEST] <th3_v0ice> The problem is that they are not... [20:21:58 CEST] <JEEB> and if you say that ffmpeg.c works for you... it is using exactly the same API [20:22:45 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=fftools/ffmpeg.c;h=d581b40bf… [20:22:49 CEST] <JEEB> this is from the 3.4 branc [20:22:50 CEST] <JEEB> *branch [20:24:46 CEST] <th3_v0ice> Can this have something to do with av_read_frame? [20:26:51 CEST] <th3_v0ice> The logic is the same between ffmpeg.c and my code, but putting a B frames into the mix avcodec_receive_frames is returning AVERROR_EOF immediatelly after the av_read_frame does. [20:32:20 CEST] <axew3> hello all [20:34:20 CEST] <axew3> is possible to ask a question around here about ffmpeg install into a centos server? [20:35:18 CEST] <kiroma> Don't ask to ask and just ask the question. [20:36:39 CEST] <JEEB> th3_v0ice: out of interest, you're not re-using the avcodecontext from the avformat context, right? that should give you warnings and is not the right way anyways [20:36:46 CEST] <JEEB> although no idea if it would cause this [20:37:04 CEST] <JEEB> av_read_frame is anyways one of the most misnamed functions :P it reads an AVPacket [20:41:58 CEST] <th3_v0ice> JEEB: No, I am opening my own decoder AVCodecContext, based on the parameters from the input AVFormatContext. Haha, yeah, luckily it has a good description :) [21:37:22 CEST] <Fenrirthviti> Is av1 support functional in ffmpeg at this point? Or is that still ongoing? [21:38:30 CEST] <JEEB> do note that the PR stunt the marketing dep of AOM did was bad, it's not finished *yet* although it's close [21:38:45 CEST] <JEEB> there's a patch for AV1 decoding and it might get merged soon as it was just discussed [21:38:55 CEST] <Fenrirthviti> yeah, that's fair, I just wasn't sure if it got merged yet [21:38:57 CEST] <JEEB> (the patch has been around in one way or another for months now) [21:39:16 CEST] <JEEB> but yea, what I am trying to say is that AV1 is not finished. not yet, at least. [21:39:18 CEST] <Fenrirthviti> I saw a few other commits earlier today that have supporting av1 functions is why I was asking [21:39:33 CEST] <Fenrirthviti> like the ivf one [21:39:47 CEST] <JEEB> yea, the muxing commits went in quite a while ago [21:39:55 CEST] <durandal_1707> Fenrirthviti: why do you care for av1? [21:40:15 CEST] <Fenrirthviti> Because rtmp and flv is absolutely awful [21:40:16 CEST] <JEEB> because AOM's PR department just released the news article? [21:40:30 CEST] <Fenrirthviti> I've been interested in it as a potential replacement for streaming video for a while now [21:41:06 CEST] <JEEB> it's the least bad thing coming up it seems [21:41:19 CEST] <JEEB> given that HEVC is just not kosher licensing-wise for corporate use [21:41:22 CEST] <Fenrirthviti> The only other thing is SRT, but they seem even worse at playing with others [21:41:28 CEST] <JEEB> SRT is a protocol [21:41:34 CEST] <JEEB> AV1 is a video format [21:41:57 CEST] <Fenrirthviti> yes, I'm looking for replacements for both rtmp and flv [21:42:10 CEST] <DHE> if the AV1 reference encoder runs at 0.05fps for 1080p I'll considered that good... [21:42:22 CEST] <BtbN> both rtmp and flv won't go anywhere with a new video codec though [21:42:28 CEST] <BtbN> they are containers/transports [21:42:51 CEST] <BtbN> And AV1 is not a replacement for them [21:42:54 CEST] <Fenrirthviti> fair enough I guess. [21:43:28 CEST] <BtbN> AV1 won't be relevant for another 2 years at least [21:44:28 CEST] <Fenrirthviti> sure, not really expecting anything right now [21:44:56 CEST] <Fenrirthviti> just would be fun to start playing with it [21:47:07 CEST] <DHE> if the decoder can improve to the point of realtime playback, some people might be willing to put up with the slow encoder for VOD style playback... [21:47:15 CEST] <DHE> but that's still probably a year out at very best [21:47:51 CEST] <JEEB> the decoder is already realtime 1080p30 [21:47:54 CEST] <JEEB> without threading [21:48:09 CEST] <JEEB> and rav1e is a fast encoder if you want SPEEED [21:48:17 CEST] <JEEB> TD-Linux was doing a live stream with it after FOSDEM [21:48:27 CEST] <DHE> oh? cool... [21:48:40 CEST] <JEEB> rav1e is basically part of the effort to verify the spec [21:48:44 CEST] <Fenrirthviti> What were they using for transport? [21:48:53 CEST] <JEEB> so they wrote another encoder just for that :P [21:49:03 CEST] <JEEB> (and also to see how well/bad you can write an encoder in rust) [21:49:11 CEST] <Fenrirthviti> hah [21:49:33 CEST] <JEEB> AV1 is going to most likely have matroska and ISOBMFF (mp4) mappings from the get-go [21:49:49 CEST] <JEEB> MPEG-TS might follow if someone cares enough. [21:50:49 CEST] <DHE> mpegts would suggest they want it to become a broadcast standard... (format hacks aside) [21:51:07 CEST] <Fenrirthviti> that was in their mission statement at some point [21:52:00 CEST] <JEEB> well AV1 as a video format isn't limited to any specific use case. but MPEG-TS or broadcast isn't a focus point as far as I can tell. thus the "if someone cares enough" [21:52:40 CEST] <JEEB> also reminds me of how opus got registered after paying over 1000 USD, and then the standards body updated its listing+site and opus just disappeared. understandably some people were rather salty. [21:52:44 CEST] <Fenrirthviti> they had a whole subset of goals for streaming though, I thought? unless I'm just misunderstanding [21:53:00 CEST] <JEEB> streaming for web is one of the primary use cases, thus matroska and isobmff [21:53:14 CEST] <JEEB> as in, GOOG and others care about that probably the most [21:53:31 CEST] <Fenrirthviti> ah ok, broadcast meaning something else in this context then (I'm not so great with terminology semantics) [21:53:48 CEST] <furq> Fenrirthviti: if you're looking for an nginx-rtmp replacement then https://github.com/arut/nginx-ts-module might be of interest [21:53:59 CEST] <furq> although it's only really useful if you want to do dash live streaming [21:54:13 CEST] <Fenrirthviti> yeah, the problem is latency [21:54:22 CEST] <Fenrirthviti> rtmp is by far the lowest latency of anything viable right now [21:54:26 CEST] <furq> yeah [21:54:38 CEST] <Fenrirthviti> and that's basically priority one for my purposes [21:54:45 CEST] <Fenrirthviti> it just blows I have to keep supporting flash :\ [21:54:45 CEST] <DHE> and webm by extension... [21:54:56 CEST] <DHE> really? google dropped flash entirely last year [21:55:04 CEST] <JEEB> it still kind of works :P [21:55:13 CEST] <Fenrirthviti> you just have to add the exception manually [21:55:17 CEST] <Fenrirthviti> it still works fine [21:55:19 CEST] <DHE> if your browser doesn't support html5, it doesn't play anything... I've tried. [21:55:36 CEST] <Fenrirthviti> I mean, I do it basically every day, it works. [21:55:53 CEST] <JEEB> also just plain live presentation through HTTP without HLS/DASH does work and with probably similar latency to RTMP etc [21:55:58 CEST] <JEEB> too bad the browsers are stupid [21:56:03 CEST] <JEEB> regarding XHR and other stuff [21:56:05 CEST] <DHE> there was a few weeks during the migration where embedded players supported flash but the main web player didn't... [21:56:14 CEST] <Fenrirthviti> yeah, ingest becomes the issue with that scenario [21:56:27 CEST] <furq> JEEB: does that work well with fmp4 now [21:56:28 CEST] <Fenrirthviti> basically all output clients support is rtmp right now [21:56:34 CEST] <furq> emphasis on "well" [21:56:55 CEST] <JEEB> furq: it should. not that I've tested it with anything else than MPEG-TS back in the days :P [21:56:57 CEST] <Fenrirthviti> DHE: I use video.js and the flash tech plugin [21:57:06 CEST] <Fenrirthviti> not native browser stuff [21:57:07 CEST] <furq> well yeah i specifically mean to browsers [21:57:21 CEST] <BtbN> You are forced to use WebRTC if you want low latency now [21:57:37 CEST] <JEEB> well I heard there's a chunked XHR-like API in webshit browsers now? [21:57:46 CEST] <JEEB> so you could utilize that? [21:57:55 CEST] <BtbN> Just use a websocket? [21:57:56 CEST] <JEEB> so it doesn't buffer the whole received data [21:57:57 CEST] <Fenrirthviti> yup, or SRT, but that's a nightmare to even get working with PoC [21:58:03 CEST] <JEEB> fuck SRT [21:58:11 CEST] <JEEB> you can just KISS it [21:58:25 CEST] <JEEB> like seriously, I don't see why the flying fuck you would use WS or SRT or anything [21:58:36 CEST] <JEEB> if you can just do it with a well-defined thing like an HTTP end point [21:58:45 CEST] <BtbN> Because Websockets are the only thing that allows streaming to JavaScript [21:59:00 CEST] <DHE> Fenrirthviti: and that will integrate with youtube? [21:59:01 CEST] <JEEB> ok, so the chunked API is not around? so yes, webshits are still webshits [21:59:15 CEST] <Fenrirthviti> DHE: Not sure what youtube has to do with anything here? [21:59:17 CEST] <JEEB> I just heard there was a chunked transfer api [21:59:20 CEST] <BtbN> There is no JavaScript API that does not buffer whole http requests [21:59:32 CEST] <JEEB> ok, let me go beat TD-Linux around with a bush [21:59:42 CEST] <JEEB> because he said something about a chunked thing [21:59:42 CEST] <Fenrirthviti> I host my own streaming site, I don't use any public services [22:00:05 CEST] <DHE> Fenrirthviti: I do something similar for limited uses. I'm using hls.js [22:00:19 CEST] <furq> same [22:00:28 CEST] <Fenrirthviti> yeah, I have hls support through nginx rtmp, it's just not viable for my use case because of the latency [22:00:29 CEST] <BtbN> JEEB, you can process the data in chunks, there is an API for that [22:00:40 CEST] <BtbN> But XHR will still buffer the whole thing internally and return it at the end [22:00:46 CEST] <Fenrirthviti> and I don't have anywhere near the skillset to build something custom to get that latency down to any kind of reasonable time [22:00:50 CEST] <JEEB> BtbN: ok [22:01:00 CEST] <furq> Fenrirthviti: i'm pretty sure there's no solution for that that doesn't suck anyway [22:01:06 CEST] <Fenrirthviti> That too. [22:01:16 CEST] <furq> webrtc is the only thing i know of that has hassle-free support in browsers [22:01:19 CEST] <JEEB> to be honest I would bet that MPEG-TS ingesting thing could be pretty well turned into serving MPEG-TS from HTTP as-is or something [22:01:21 CEST] <Fenrirthviti> The major problem is that you have to start with RTMP. [22:01:32 CEST] <furq> and by "hassle-free" i mean the playback, there is still plenty of hassle in actually getting a webrtc stream from a server to a browser [22:01:33 CEST] <JEEB> and then you could stick WS onto that if XHR sucks that much with webshits [22:01:40 CEST] <furq> and also you're then stuck with baseline h264 [22:01:56 CEST] <Fenrirthviti> If I could start with something else, it would be a hell of a lot easier. [22:01:57 CEST] <BtbN> All browsers play high h264 just fine via WebRTC [22:02:02 CEST] <furq> do they really [22:02:03 CEST] <BtbN> They just can't encode it [22:02:16 CEST] <JEEB> it probably uses the same lib for decoding anyways :P [22:02:24 CEST] <JEEB> as normal H.264 content [22:02:31 CEST] <DHE> do browsers even support encoding in the video API? [22:02:37 CEST] <BtbN> yes [22:02:41 CEST] <JEEB> yup [22:02:41 CEST] <furq> i thought chrome still used openh264 for decoding [22:02:44 CEST] <DHE> the only h264 encoder I know of for browsers is libopenh264 [22:02:53 CEST] <furq> in some kind of effort to push webm for webrtc [22:02:59 CEST] <JEEB> yes, the encoder usually is openh264 in browsers [22:03:01 CEST] <furq> unless they changed their mind pretty recently [22:03:06 CEST] <lindylex> Can I use -frames:v to start a slice? This is what I am doing ffmpeg -ss 00:00:11.0 -i leftleg.mp4 -frames:v 200 -vcodec copy -acodec copy -y cartWheel1.mp4 [22:03:06 CEST] <JEEB> the decoder is either lavc or native hwdecs [22:04:01 CEST] <JEEB> but yea, I wish webshits would just give us streaming HTTP request API :P [22:04:07 CEST] <JEEB> so much overly clever bullshit going on [22:04:31 CEST] <JEEB> I did MPEG-TS over HTTP in 2008 to watch .jp TV remotely [22:04:44 CEST] Action: JEEB points at the clouds and acts old [22:06:04 CEST] <JEEB> (webrtc being a thing on top of RTP is kind of OK for the use cases it was made for, just for the record. which isn't normal media streaming as far as I can tell) [22:06:19 CEST] <DHE> I've done things I'm not proud of to get free TV... [22:06:35 CEST] <JEEB> in this case it was my own server with a receiver :P [22:06:41 CEST] <JEEB> and vlc 0.8.6 or something [22:06:53 CEST] <JEEB> because it could serve stuff through http [22:07:16 CEST] <DHE> yep. there's an OTA receiver in my office. I've done something... not identical, but remote viewing nonetheless [22:07:28 CEST] <furq> i successfully used ffserver 0.5 [22:07:29 CEST] <furq> what do i win [22:07:53 CEST] <DHE> howie mandell's haircut (sp?) [22:08:29 CEST] <furq> in case you're wondering, it sucked, it dropped out a lot, and then one day debian updated to ffmpeg 0.7 and my previously working config stopped working forever [22:08:38 CEST] <Fenrirthviti> hurray [22:08:45 CEST] <furq> but i did briefly use it with some degree of success [22:08:58 CEST] <JEEB> in a way I must pay respects to those who got ffserver to actually chooch [22:09:14 CEST] <furq> my place in hell is assured [22:09:51 CEST] <durandal_1707> you will write ffserver config files for rest of eternity [22:10:04 CEST] <furq> sisyphus will envy me [22:10:22 CEST] <furq> wait [22:10:24 CEST] <furq> pity [22:10:28 CEST] <JEEB> durandal_1707: btw how did lavfi reconfig work? I'd like to give a try at fixing the PTS fuck-ups with audio? [22:12:43 CEST] <durandal_1707> there is no reconfig, complete filtergraph is recreated iirc [22:12:51 CEST] <JEEB> oh [22:12:57 CEST] <JEEB> no wonder it loses the state then [22:13:41 CEST] <durandal_1707> i guess you would need to feed frames after new graph with different pts [22:14:45 CEST] <durandal_1707> anyway explain your usage/scenario/issues as RFC and Nicolas may respond [22:15:01 CEST] <durandal_1707> on ml [22:15:15 CEST] <JEEB> sure, although thankfully it doesn't seem to break too much [22:15:31 CEST] <JEEB> you just get a "queue just went backwards" in the audio encoder :D [22:15:56 CEST] <JEEB> (and yes, timestamps fed into the filter chain are going up the whole time) [22:16:12 CEST] <JEEB> it's just that at the reconfig it loses the offset from frame size differences or whatever [22:17:45 CEST] <durandal_1707> what you mean by reconfig? auto inserted filter in graph? [22:20:22 CEST] <JEEB> you can make it happen with just ffmpeg.c for example. "ffmpeg -i INPUT -filter_complex "[0:a:0]aresample=48000[a_out]" -map "[a_out]" -c:a aac -b:a 192k -ac 2 blah.mp4" [22:20:36 CEST] <JEEB> then just go over a thing that switches audio layouts [22:20:45 CEST] <JEEB> it will reconfig the filter chain [22:21:17 CEST] <JEEB> (AC3 or something preferred, since it has different audio sample counts in AVFrames than AAC) [22:26:49 CEST] <durandal_1707> JEEB: i run aresample with eac3 that changes 7.1 -> 5.1 and pts is continuous here, if I run astats i get 2 reports, because, obviously it calls uninit twice [22:27:58 CEST] <JEEB> alright, might have something to do with other factors as well such as start timestamps etc. it happens with an MPEG-TS input I have around [22:29:09 CEST] <durandal_1707> give me sample and command and i will play with it [22:31:21 CEST] <JEEB> only thing I additionally do is :async=1 in that aresample, but the timestamps should be good in the sample I had the issue with. let me try and cut the sample since it's ~300MiB now [23:28:25 CEST] <apus> for x264, if i decrease the crf value the speed will be slower and not reach 1x needed for realtime capture. if i go from preset medium to ultrafast the cpu load goes down but the speed up, however it still doesn't reach 1x unless i increase crf again. is there a way to utilize more cpu while using preset ultrafast to reach 1x speed ? [23:29:19 CEST] <BtbN> sounds more like your bottleneck is somewhere else [23:31:16 CEST] <apus> hm, i'll take a closer look at the rest of the hardware then. thanks for the tip! [23:32:32 CEST] <BtbN> x264 should not have issues fully making use of a cpu with non crazy amounts of cores [23:33:01 CEST] <BtbN> unless you disabled or limited threading [23:34:18 CEST] <kepstin> i don't think the entropy encoder can pe parallelized tho, and in cases with really high bitrate streams, that might be the limit with single-core perf. [23:34:31 CEST] <apus> for preset medium it goes to 100% on all cores. for ultrafast it just uses 70-80% of one. [23:34:53 CEST] <kepstin> ultrafast turns off cabac tho, so hmm. [23:35:11 CEST] <BtbN> if you can't hit 1.0x speed with ultrafast, and the CPU is not at 100%, I really think your slow part is elsewhere [23:35:12 CEST] <kepstin> apus: what kind of bitrate and video resolution are you looking at? [23:35:16 CEST] <BtbN> like, some filter, or the io [23:37:33 CEST] <apus> i'm capturing vhs with -standard PAL, video filter yadif and a black box at the bottom 6 pixels, audio aac 128k with low- and highpass for audio noise. framerate set to 25, 720x576 [23:38:42 CEST] <kepstin> SD video? it's really strange to have a problem like this with SD video :/ [23:39:08 CEST] <kepstin> are you actually seeing problems, or are you just seeing that the "speed" number that ffmpeg cli shows is <1? [23:39:16 CEST] <ChocolateArmpits> apus, over firewire or analog composite ? [23:40:02 CEST] <apus> i'm saving it to external usb 3.0 wd red, so that shouldn't be the problem. i get errors if the buffers i increased already are filled up and speed hasn't reached 1x till then. scart -> composite -> usb 2.0 video grabber stk1160 [23:40:05 CEST] <kepstin> because of weirdness with frame queueing, etc., the speed number that ffmpeg reports probably won't be exactly 1, although it should average to that eventually. [23:40:31 CEST] <kepstin> assuming a live capture source, like v4l or something [23:41:14 CEST] <ChocolateArmpits> apus, have you tried encoding without any output ? [23:44:42 CEST] <apus> ChocolateArmpits: no, i guess i'll try that to make sure the problem is not on that end. then i'll remove the filters one by one. something is off here. Early on i had problems with video/audio sync after only a few seconds, then i set thread_queue_size 512, then 1024, then 4096 for both audio (alsa) and video (v4l) and added rtbufsize 15M. afterwards if it got to 1x speed fast enough, there weren't any issues with corrupt video/audio. [23:45:04 CEST] <apus> could that cause problems? [23:45:49 CEST] <ChocolateArmpits> single-threaded filters can cause frames to not get rendered realtime even if the overall cpu usage isn't maxed out [23:46:26 CEST] <ChocolateArmpits> I had that situation so had to restructure my filtergraph to be "less" heavy [23:48:37 CEST] <apus> are yadif, drawbox and highpass,lowpass single-threaded filters? [23:50:51 CEST] <furq> apus: ffmpeg -filters | grep ^..S [23:50:55 CEST] <ChocolateArmpits> except for yadif they are [23:51:00 CEST] <furq> those are all the filters with threading support [23:51:05 CEST] <ChocolateArmpits> however those two audio filters shouldn't be causing any problems here [23:52:22 CEST] <furq> what cpu is this anyway [23:54:58 CEST] <apus> laptop cpu. i'll just use another system then for the work and see how doing the work over ssh looks like. then the single-core performance problem goes away. didn't expect yadif to be limited to single-threading. that is the problem then i guess. thanks for all your help ! [00:00:00 CEST] --- Thu Mar 29 2018

1 0

ffmpeg-devel.log.20180327
by burek 28 Mar '18

28 Mar '18

[00:14:41 CEST] <cone-891> ffmpeg 03Danil Iashchenko 07master:9f1787513475: libavfilter: Add OpenCL convolution filter [00:14:41 CEST] <cone-891> ffmpeg 03Mark Thompson 07master:213839edffbf: vf_avgblur_opencl: Don't run kernel on pixels outside the image [00:14:41 CEST] <cone-891> ffmpeg 03drfer3 07master:29c663d50cbf: avfilter/vf_avgblur_opencl: fix error when clSetKernelArg fails [00:14:41 CEST] <cone-891> ffmpeg 03Jun Zhao 07master:ac6e27d74f6a: kmsgrab: add category for kmsgrab [00:35:10 CEST] <jkqxz> michaelni: HDMI is not freely available, but you can find PDFs of the older 1.3 and 1.4 versions with Google. [00:56:49 CEST] <cone-891> ffmpeg 03Timo Rothenpieler 07master:3914c8e0e6ba: avformat/hlsenc: initialize saveptrs [01:15:16 CEST] <atomnuker> why are we getting so many emails on the ml now? [01:15:27 CEST] <atomnuker> january + feburary + half of march were quiet [01:18:19 CEST] <Chloe> atomnuker: I wonder how many of those email are under threads I started [01:19:06 CEST] <nevcairiel> not that many [01:19:15 CEST] <nevcairiel> a lot of patches coming in as well [01:19:56 CEST] <Chloe> Itd be interesting to see how it relates to prior years [02:13:27 CEST] <kierank> I don't understand the point of this sei injection code [02:13:43 CEST] <kierank> if the code doesn't understand reordering [03:40:34 CEST] <klaxa> hmm yeah after looking at them i think i'll replace my segment.* and buffer.* by lavutil's segment.h and fifo.h [09:25:36 CEST] <gagandeep> i have sent the patch with updates in cfhd.c and fate reference combined [09:25:54 CEST] <gagandeep> first mail i screwed up combining two commits [09:26:12 CEST] <gagandeep> new mail has been sent just now [09:28:14 CEST] <durandal_1707> gagandeep: have you sent final proposal? [09:28:36 CEST] <gagandeep> yeah i have sent the draft proposal on gsoc, i would have liked if someone had seen it [09:28:46 CEST] <durandal_1707> gagandeep: i asked for FINAL? [09:28:54 CEST] <gagandeep> i have yet to submit final pdf [09:29:01 CEST] <gagandeep> 8 hrs to go [09:34:40 CEST] <gagandeep> kierank: can you look into the proposal draft [09:35:07 CEST] <durandal_1707> so you gonna wait 7 hrs and 59 min? [09:35:36 CEST] <gagandeep> durandal_1707: don't know what you mean by that? [09:36:05 CEST] <gagandeep> it's info should have been provided by gsoc to ffmpeg [09:36:20 CEST] <gagandeep> should i have sent the link to doc on ml last night [09:40:20 CEST] <gagandeep> i just want to confirm if the parties involved have checked the proposal although it sticks to the timeline discussed previously [09:53:08 CEST] <nevcairiel> durandal_1707: bluray eac3 sample, freshly extracted from a disc https://files.1f0.de/samples/ww_eac3.eac3 .. i tried to pick a part with some more action so all the channel hopefully have audio [10:08:23 CEST] <durandal_1707> nevcairiel: i guess i will check only if channel_map is 1A00 and act accordingly - just hardcode stuff [10:08:49 CEST] <nevcairiel> are you sure you're reading it right, the docs seem so easy [10:08:49 CEST] <durandal_1707> are there eac3+ samples with atmos? [10:08:57 CEST] <nevcairiel> technically yes, but i dont have any [10:09:06 CEST] <nevcairiel> it exists on some UHD Blu-rays [10:09:44 CEST] <durandal_1707> nevcairiel: if i had sample with different channel map then 0x1A00 it would help to resolve this [10:10:08 CEST] <durandal_1707> but it appears every single of them is only 7.1 and thus 0x1A00 [10:10:30 CEST] <durandal_1707> it could support 8.1 just fine... [10:10:42 CEST] <nevcairiel> 7.1 is the maximum on blu-ray anyway [10:10:46 CEST] <nevcairiel> but in theory it could be 6.1 [10:10:51 CEST] <nevcairiel> no idea if that exists anywhere tho [10:18:19 CEST] <CounterPillow> Every day until FFmpeg 4.0 is released, I will fart on my cat. Choose wisely. [10:37:36 CEST] <nevcairiel> durandal_1707: i read the spec again and checked the chanmap value from the bitstream, and it seems reasonable to me, i just read it backwards at first [10:38:11 CEST] <nevcairiel> 0001101000000000 is interpeted as bits 3, 4 and 6 set, which indicate left surround, right surround and Lrs/Rrs pair (ie. rear speakers) [10:38:26 CEST] <nevcairiel> basically the exact layout i expected from bluray [10:39:14 CEST] <nevcairiel> so in practice, replace side surround speakers, and add rear speakers [10:40:15 CEST] <nevcairiel> the table is MSB-first, which was confusing me at first [10:43:55 CEST] <nevcairiel> it makes sense if one reads it bit-by-bit, but not when reading it as a 16-bit number :) [10:45:08 CEST] <durandal_1707> yea, i was stripping leading zeros [10:47:08 CEST] <durandal_1707> so how implement this sanely? i mean other cases for which there is no samples. [10:48:57 CEST] <nevcairiel> i dont suppose we have a function to get the index of a specific channel [10:48:59 CEST] Action: nevcairiel checks [10:49:34 CEST] <nevcairiel> actually we do [10:52:36 CEST] <durandal_1707> gagandeep: perhaps you could put more stuff in proposal [10:52:52 CEST] <durandal_1707> gagandeep: like other remaining stuff if time permits [10:54:47 CEST] <kierank> gagandeep: you should delete fate test [10:59:44 CEST] <nevcairiel> durandal_1707: my idea would be to build a final combined channel layout, which should be relatively easy (just need a table to make a channel_layout from chanmap, and OR that with the core), and then iterate over 0..nb_channels and for every channel check if its in the dependent frame and use that, or use the core channel if not in dependent, we have all the av_get_channel_layout* functions to get the required indices and stuff [11:03:46 CEST] <nevcairiel> you already copy channels into the final output anyway, so that should be easy [11:04:02 CEST] <nevcairiel> just need to somehow remember the channel layout of the core before the decoder overwrites it with the dependent frame stuff [11:08:45 CEST] <gagandeep> kierank: delete fate test? [11:09:16 CEST] <kierank> Of course, it's green [11:09:45 CEST] <nevcairiel> wasnt the green just a pixel diff to show the difference [11:11:25 CEST] <gagandeep> kierank: the difference in raw videos generated by ffmpeg i did is this [11:11:26 CEST] <gagandeep> https://imgur.com/a/WbLaz [11:11:56 CEST] <kierank> Ah it's a difference [11:12:21 CEST] <kierank> Iirc libav put a fate test that didn't work [11:12:52 CEST] <gagandeep> well the output had all white with text frames so it wasn't noticable [11:13:09 CEST] <kierank> Ah ok [11:13:10 CEST] <gagandeep> i was also perplexed seeing how the hell output is different with patch [11:17:37 CEST] <gagandeep> durandal_1707: kierank has told me that implementing bayer could be troublesome, so right now i have kept that thing as stuff to be done in last [11:26:45 CEST] <gagandeep> kierank: shall i submit the proposal finally [11:30:20 CEST] <durandal_1707> nevcairiel: what is Lrs and Rrs ? [11:37:44 CEST] <durandal_1707> probably bakc left and right [11:37:59 CEST] <durandal_1707> but other names like Cs and Ts are too cryptic [12:05:00 CEST] <nevcairiel> Left/right rear surround, [12:05:06 CEST] <nevcairiel> so yeah, back [12:05:29 CEST] <durandal_1707> and Cs, Ts [12:06:08 CEST] <nevcairiel> center surround, top surround, not sure we have flags for those [12:06:49 CEST] <nevcairiel> oh center surround is back center [12:06:58 CEST] <nevcairiel> top surround is maybe top center then? [12:08:04 CEST] <nevcairiel> lsd/rsd is Left surround direct [12:08:46 CEST] <nevcairiel> Vhl/vhr is top front [12:09:37 CEST] <nevcairiel> SMPTE 428-3 describes them [12:13:32 CEST] <nevcairiel> apparently we do have flags for all of them [12:29:41 CEST] <durandal_1707> nevcairiel: what order of channels is in dependent substream/frame? [12:30:00 CEST] <nevcairiel> durandal_1707: the order as the bits in the chanmap [12:30:04 CEST] <nevcairiel> for pairs, left first [13:24:22 CEST] <durandal_1707> nevcairiel: i mean in extra 4.0 one, which is which? [13:31:09 CEST] <nevcairiel> durandal_1707: like i said, its coded in the same order as the chanmap table defines the channel [13:31:41 CEST] <nevcairiel> so in those BD streams left/right surround first, followed by left/right rear [13:36:27 CEST] <durandal_1707> it appears it is different [13:38:19 CEST] <nevcairiel> thats what the spec writes anyway [13:48:27 CEST] <durandal_1707> got it [13:56:19 CEST] <durandal_1707> nevcairiel: should i add core option name to decode only independent stream? [13:57:01 CEST] <nevcairiel> someone might want that, not me though [13:58:02 CEST] <durandal_1707> is issue if demuxer still returns 5.1? [13:58:17 CEST] <nevcairiel> its not perfect but can be fixed later [14:52:11 CEST] <durandal_1707> who gonna push those hevc neon asm patches? [15:00:25 CEST] <durandal_1707> nevcairiel: are there any eac3 samples in wild that use multiple non-zero substream ids? [15:13:52 CEST] <gagandeep> 'in the wild' haha [15:21:39 CEST] <durandal_1707> gagandeep: yes on internet or darknet [15:32:11 CEST] <durandal_1707> atomnuker: are you saying if I found in book that c = a^2 + b^2 it can not be used, how that is different from reading disasembled code? [15:36:18 CEST] <atomnuker> durandal_1707: if you have an army of lawyers like nvidia does and even hint they you copied something you're going to jail [15:38:46 CEST] <iive> there used to be a patent on using XOR to draw image cursor. [15:40:39 CEST] <iive> and you may not go to jail, you may just go bankrupt from court and lawyer fees. [15:40:52 CEST] <durandal_1707> atomnuker: so we would get what? DMCA request to remove such code? [15:41:35 CEST] <kierank> gagandeep: on my phone, can't see your application I am afraid [15:42:27 CEST] <durandal_1707> this just seems silly considering how lot of stuff in ffmpeg is already patented [15:43:02 CEST] <gagandeep> Kierank: https://docs.google.com/document/d/1cRnlt8jU6A6n10WAb24fMO8y_E-SweU952FSFKU… [15:43:04 CEST] <gagandeep> See if this works [15:43:04 CEST] <gagandeep> I have stuck to the timeline discussed with you [15:44:02 CEST] <durandal_1707> gagandeep: i read it, and it is looking good [15:44:22 CEST] <kierank> Yes seems ok [15:46:20 CEST] <gagandeep> durandal_1707: thanks , you've also been a lot of help in the past month [15:49:44 CEST] <atomnuker> durandal_1707: its not patent stuff I'm worried about, its copyright [15:50:13 CEST] <tguillem> Hi, did someone already tested the videotoolboxenc for realtime ? I'm trying to use it via VLC for chromecast but I have the feeling that it's even less realtime with the kVTCompressionPropertyKey_RealTime set to true. [16:17:22 CEST] <tguillem> ok, It's really realime and size/bitrate are more than correct for streaming. I guess chromecast doesn't like video encoded by VT. Tweaking some options to identify the issue... [16:28:44 CEST] <cone-284> ffmpeg 03James Almer 07master:d205c8f3bbde: avcodec/avpacket: remove unnecessary check in av_packet_make_writable() [16:35:26 CEST] <nevcairiel> durandal_1707: dont think so, the only error i ever saw was dependent substreams [17:58:03 CEST] <atomnuker> why does (av_)strtok modify the source pointer? tokenization is doable in-place, isn't it [17:58:15 CEST] <atomnuker> *modify the source buffer [18:02:05 CEST] <wm4> because that's how strtok works [18:02:11 CEST] <wm4> there are better ways to parse strings [18:21:12 CEST] <wm4> jamrial: I think a new side data could be added in a compatible way by adding awkward accessors that let the new API access the old one [18:21:29 CEST] <wm4> so the side data code would internally have to access AVPacket/AVFrame etc. [18:21:33 CEST] <wm4> not sure if worth the trouble [18:28:10 CEST] <jamrial> it's worth the trouble if there's no other way to introduce a better side data api while trying to keep the old one working for a while [18:28:30 CEST] <jamrial> wouldn't be the first time awkward compat code is added for something like this [18:34:00 CEST] <wm4> well I have no better idea, but maybe I'm lacking creativity here [18:43:58 CEST] <jamrial> durandal_1707: none of the fate suite eac3 samples are affected by the new bsf. are those "core" already? [18:44:10 CEST] <nevcairiel> they are probably pure eac3 [18:44:25 CEST] <nevcairiel> not the blu-ray variant with core+substream [18:45:07 CEST] <durandal_1707> jamrial: 5.1 is usually core [18:45:32 CEST] <jamrial> right [19:32:38 CEST] <peloverde> Is there a reason why we can't give the two rtmp muxers secondary names so you can use then both from the same binary? [19:54:24 CEST] <peloverde> would people find naming them "rtmp,librtmp" and "rtmp,ffrtmp" respectively acceptable? or is that too icky? [19:55:17 CEST] <nevcairiel> maybe it should stop being a special snowflake and librtmp just always called that [19:55:22 CEST] <JEEB> hmm, noticed that a reset of a filter chain makes the filters forget what their previous output timestamp was :) [19:55:32 CEST] <nevcairiel> all other libraries always have the prefix [19:55:46 CEST] <JEEB> agreed [19:59:15 CEST] <cone-284> ffmpeg 03James Almer 07master:95e33ea56599: doc/APIchanges: fix lavu version for the AVEncryptionInfo addition [20:20:29 CEST] <durandal_1707> JEEB: yes, you call init/uninit [20:21:00 CEST] <JEEB> this was with ffmpeg.c (the monster) [20:21:04 CEST] <JEEB> so I will have to check that one [20:21:27 CEST] <durandal_1707> how do you reset a filter? [20:21:47 CEST] <JEEB> something happens when an ac3 stream switches from 5.1 to stereo [20:21:58 CEST] <JEEB> all of the filter chain reconfigures itself or something [20:22:03 CEST] <peloverde> None of the lib protocols use the lib prefixes they way codecs and containers do [20:22:04 CEST] <durandal_1707> ah [20:23:00 CEST] <JEEB> and since I'm doing AC3->AAC which have different audio packet sizes (1536 vs 1024 was it?) it then proceeds outputting the first audio frame with a PTS that actually goes backwards from the previous one :D [20:23:20 CEST] <JEEB> because after reset it suddenly doesn't remember what PTS it last used [20:23:35 CEST] <durandal_1707> yes, that is bug, pts shouldn't be reset [20:23:54 CEST] <JEEB> also it might return INT64_MAX with the video, but I'll have to oduble-check [20:24:03 CEST] <durandal_1707> JEEB: is that file or something else? [20:24:09 CEST] <JEEB> it's thankfully a file [20:24:16 CEST] <JEEB> so I could just iterate over it [20:24:28 CEST] <JEEB> and see WTF is going on [20:24:40 CEST] <JEEB> although originally that file came from broadcast input [20:28:48 CEST] <durandal_1707> what file to use legally for EAC3 7.1 fate coverage? [20:32:50 CEST] <atomnuker> some short sample from a movie if you can't find anything else [20:34:34 CEST] <peloverde> also renaming a protocol without keeping the old name as a comma separated alternative is effectively an API change [20:39:46 CEST] <atomnuker> can't we drop librtmp? [20:40:19 CEST] <atomnuker> does it support something our native demuxer doesn't? [20:40:34 CEST] <nevcairiel> probably, rtmp is a huge mess [20:42:46 CEST] <atomnuker> worse than dash? [20:44:48 CEST] <wm4> I'd rather drop the native demuxer lol [20:44:56 CEST] <wm4> (no idea if librtmp is good) [20:47:25 CEST] <JEEB> rtmp is actually simpler than DASH and librtmp hasn't been updated in a while afaik [20:47:57 CEST] <JEEB> a lot of the stuff where people can't get things to work is due to librtmp and ffrtmp using different options for things [20:48:20 CEST] <atomnuker> wm4: last release was 2 years ago [20:48:42 CEST] <atomnuker> apparently, according to debian's changelog, probably its more than that [20:48:49 CEST] <JEEB> most likely [20:49:06 CEST] <JEEB> any changes are quite likely to be downstream patches [20:50:12 CEST] <atomnuker> if it proves to have security issues we ought to drop it, neither debian nor arch have it enabled by default anyway [20:54:15 CEST] <durandal_1707> nevcairiel: you used ffmpeg to extract eac3 (your uploaded sampe)? and you used seek? -c:a copy messes up big time [20:54:36 CEST] <nevcairiel> durandal_1707: yeah unpatched ffmpeg with seek and copy into .eac3 file [20:54:50 CEST] <nevcairiel> although i patched it to ignore timestamp issues [20:57:00 CEST] <durandal_1707> nevcairiel: with such file, it get detected as crippled channel layout (missing channels), later it is synced, but ffmpeg does not support upmixing midstream [21:05:53 CEST] <durandal_1707> michaelni: please fetch https://0x0.st/sBGf.eac3 rename it to: the_great_wall_7.1.eac3 and put it to fate server into eac3 directory [21:11:11 CEST] <nevcairiel> durandal_1707: what source format? on mkv you may need to force the parser to be enabled [21:11:16 CEST] <nevcairiel> i used a bluray m2ts [21:13:04 CEST] <durandal_1707> same here [21:13:40 CEST] <nevcairiel> and as said I had to disable some timestamp crap because two frames with the same timestamp drove it crazy [21:13:51 CEST] <nevcairiel> but if the parser does its job now, that should be fixed i would think [21:17:49 CEST] <durandal_1707> it splits after independent frame, parser change does not help [21:18:15 CEST] <nevcairiel> then how does the decoder ever get both [21:18:47 CEST] <peloverde> OBS is the most popular user oriented RTMP broadcast software and it uses librtmp. Which seems to imply people still care about it. [21:23:14 CEST] <durandal_1707> nevcairiel: it gets both, AVSTREAM_PARSE_FULL_RAW vs AVSTREAM_PARSE_FULL [21:23:36 CEST] <durandal_1707> eac3 demuxer use raw parsing, mpegts doesnt [21:23:43 CEST] <nevcairiel> i see [21:23:48 CEST] <nevcairiel> no i dea what raw parsing does [21:25:06 CEST] <durandal_1707> it is for cases when there is no container level timestamps [21:25:21 CEST] <nevcairiel> and i guess the parser screws that up? [21:26:55 CEST] <durandal_1707> ac3 parser is now correct, mpegts demuxer is not [21:27:55 CEST] <durandal_1707> and probably only seeking is screwed [21:28:21 CEST] <nevcairiel> well it has to be able to deal with a case where you start with a dependent frame [21:28:34 CEST] <nevcairiel> bad cuts, seeks, etc [21:28:44 CEST] <durandal_1707> what code? [21:29:12 CEST] <nevcairiel> all teh code [21:29:24 CEST] <durandal_1707> both parser and decoder? [21:29:33 CEST] <nevcairiel> yes [21:29:51 CEST] <nevcairiel> parsers dont drop data, so if it works properly it'll just slice after the dependent frame and then start a proper frame [21:29:59 CEST] <nevcairiel> and the lonely dependent frame still gets to the decoder [21:30:25 CEST] <durandal_1707> so just make decoder drop dependent frame with a warning? [21:30:59 CEST] <nevcairiel> sure [21:54:18 CEST] <durandal_1707> michaelni: please report when you upload that sample [22:07:51 CEST] <Chloe> Does anyone other than michaelni have the target dec fuzz program setup? [22:08:32 CEST] <JEEB> last I remember google's setup was part-closed source or something [22:08:37 CEST] <JEEB> they had an open source version too [22:08:44 CEST] <JEEB> but not sure if strictly related [22:14:47 CEST] <jamrial> durandal_1707, michaelni: just uploaded it [22:27:27 CEST] <wm4> Chloe: just leave it to google to fix it [22:27:45 CEST] <wm4> they're one of the biggest tech companies at all... I'm sure they can bother to spend some time on it [22:27:54 CEST] <durandal_1707> is HEVC fourcc in avi legit? [22:28:01 CEST] <Chloe> wm4: last time google 'fixed' something it broke a ton of things, no? [22:28:11 CEST] <jamrial> durandal_1707: i doubt it [22:28:18 CEST] <nevcairiel> durandal_1707: as legit was h264 was, so basically not, but people insist on putting everything into avi [22:28:21 CEST] <Chloe> (thinking edit lists) [22:28:22 CEST] <JEEB> ^ [22:28:24 CEST] <JEEB> what nev said [22:28:50 CEST] <jamrial> durandal_1707: "./ffmpeg -i the_great_wall_7.1.eac3" still reports the sample as 5.1, even if the decoding process ends up with 7.1 for the output [22:29:02 CEST] <JEEB> I've had the same with DTS-HD MA [22:29:07 CEST] <durandal_1707> jamrial: that is marginal misfeature [22:29:30 CEST] <jamrial> JEEB: can't be, at least not since foo86's changes [22:29:41 CEST] <JEEB> jamrial: could be what's written into mp4 with DTS [22:29:47 CEST] <JEEB> it gets the core channel count first [22:29:51 CEST] <JEEB> then decoded output is full [22:30:05 CEST] <nevcairiel> the ac3 parser would probably need to be updated for that to combine the full layout, but thats a bit annoying and doesnt really stop decoding from working [22:30:27 CEST] <JEEB> jamrial: although I think ffprobe/ffmpeg.c get it right [22:30:28 CEST] <JEEB> let me check [22:30:38 CEST] <JEEB> as in, if they probe they get it right [22:31:13 CEST] <JEEB> yea, it gets it right [22:31:30 CEST] <nevcairiel> both the parser and the decoder properly read dts-hd headers now [22:32:03 CEST] <JEEB> I mostly noticed because my samples from shin godzilla show up as 2ch in mpv first :D [22:32:24 CEST] <JEEB> (it's one of those perverted things with 3.1 audio) [22:32:31 CEST] <nevcairiel> something being 2ch at first and then changing with HD extensions seems unusual [22:32:37 CEST] <nevcairiel> you can put 3.1 in the core afterall [22:33:42 CEST] <JEEB> https://kuroko.fushizen.eu/videos/shin_godzilla_sample.mp4 [22:34:02 CEST] <JEEB> (also if you feed the windows mixer that it will fail fabulously) [22:34:18 CEST] <nevcairiel> thats why i have that magic to add silent channels [22:34:24 CEST] <durandal_1707> well, i can just modify parser to not set channel layout for eac3 instead of doing all parsing stuff [22:36:08 CEST] <nevcairiel> JEEB: i think the 2ch come from the container in that, the dts core is 3.1 [22:36:15 CEST] <JEEB> ok [22:36:23 CEST] <JEEB> yea I did note that I expected that to be the case [22:36:25 CEST] <JEEB> :D [22:36:52 CEST] <JEEB> (and yes, that UHD BD has no HDR metadata for some reason) [22:52:33 CEST] <durandal_1707> i disable setting channels, layout and bitrate from parser for eac3 and it now reports correct duration and layout with basic ffprobe usage [22:52:53 CEST] <durandal_1707> is this correct way to do it? dca does similar [22:53:07 CEST] <nevcairiel> in a perfect world the parser w ould be able to figure it out, but its better then setting wrong things [22:53:41 CEST] <nevcairiel> the ac3 parser is a bit limited in what it can do because it uses this abstracted design that it shares with the aac parser [22:58:01 CEST] <peloverde> IMO working with the parser from the AAC side, they should just be split. There is just as much effort spent fighting the re-use as it saves. [23:02:09 CEST] <durandal_1707> now the only thing missing is sample with dependent frames but without extended channel_map set at all [23:10:21 CEST] <jamrial> both parsers should be split, yeah. especially now that the ac3 one can/should get a couple extra things [23:16:57 CEST] <cone-131> ffmpeg 03Michael Niedermayer 07master:49a0b3f6bc96: doc/examples/hw_decode: Remove useless NULL check [23:16:57 CEST] <cone-131> ffmpeg 03Michael Niedermayer 07master:b3e9f3f5f52d: doc/examples/hw_decode: Remove logically dead code in decode_write() [23:25:14 CEST] <nevcairiel> durandal_1707: technically thats allowed and acmod just replaces it, but its probably not very useful [23:29:37 CEST] <wm4> yeah, aac/ac3 sharing the parser code is just absurd [23:30:49 CEST] <wm4> there's barely any shared code, even the aac_ac3_parser.c source file has a relatively large chunk that is under an if for a codec ID [23:31:10 CEST] <wm4> well, 7 lines out of 99 [23:33:35 CEST] <wm4> could take the opportunity to remove this weird uint64_t state [23:44:07 CEST] <rcombs> nevcairiel: and the AAC parser is limited in what it can do because AAC's bitstream format is insane [23:44:40 CEST] <JEEB> all them extensions [23:44:48 CEST] <rcombs> there's that, sure [23:44:51 CEST] <JEEB> and stuff you need to decode the bit stream for [23:44:57 CEST] <rcombs> but I mean how you can't determine the channel layout without decoding the whole thing [23:45:05 CEST] <rcombs> well, you don't need to decompress, at least [23:45:24 CEST] <rcombs> but you have to read everything because everything's variable-length and there are no high-level length codes [00:00:00 CEST] --- Wed Mar 28 2018

1 0

ffmpeg.log.20180327
by burek 28 Mar '18

28 Mar '18

[00:00:58 CEST] <BenLubar> yep, that was it. escaped by using single quotes around the expression and it worked. [00:06:30 CEST] <Camusensei> Hello guys :) [00:33:51 CEST] <Camusensei> How do I stop an enconding on the windows cmd? [00:34:20 CEST] <Camusensei> I tried hitting ^C but it just made the progress line stop moving [00:35:28 CEST] <pomaranc> isn't ^D on windows? [00:35:34 CEST] <pomaranc> isn't it* [00:35:57 CEST] <drv> hit 'q' [00:36:02 CEST] <TheAMM> ^C should work, or q and then enter [00:36:24 CEST] <pomaranc> guess not [00:36:41 CEST] <Camusensei> it finally noticed my ^C after 2 minutes [00:36:45 CEST] <TheAMM> Mashing ^C should eventually abort the encode, q will try to finish it cleanly [00:39:19 CEST] <Camusensei> okay another question -- are chapters kept when copying video+audio+subs? [00:42:43 CEST] <Camusensei> looks like a no. I need to -map_metadata 0 or something [00:43:26 CEST] <furq> -map_chapters [00:46:15 CEST] <Camusensei> furq: it works, thank you :) [00:48:23 CEST] <Camusensei> actually it works even without it [00:49:16 CEST] <Camusensei> and now it doesn't... I'll just use it and then I'll be sure ^^ [00:56:55 CEST] <BenLubar> I can't figure out why this isn't working: https://pastebin.com/raw/wZrsbgMp [00:57:17 CEST] <BenLubar> it says it's encoded 57 minutes so far, but 0 frames [00:59:53 CEST] <BenLubar> are PREV_INPTS and PREV_OUTPTS per-stream or global? [01:03:46 CEST] <BenLubar> video:0kB audio:83272kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.157503% [01:16:32 CEST] <BenLubar> ah, PREV_* is NaN on the first frame [01:30:05 CEST] <Camusensei> Thank you guys, cya next time :) [02:30:39 CEST] <realies> JEEB, got a working mxf! [02:33:44 CEST] <realies> JEEB, https://dpaste.de/OiB8/raw [02:34:01 CEST] <BenLubar> which -tune setting should I use for a 3D video game (Guild Wars 2) [02:41:09 CEST] <DHE> nothing stands out as completely appropriate. so, none? [02:49:01 CEST] <wfbarksdale> hey guys, i'm working on an ffmpeg cross compile setup, and I was wondering how its possible to target a macOS version >= $x [03:06:54 CEST] <BenLubar> hmm, why doesn't "-hwaccel cuvid -c:v h264_cuvid -i video.mp4" show any "video decode" usage in task manager [03:07:04 CEST] <BenLubar> it shows the encoding using 100% of capacity, but decoding is using 0% [03:07:21 CEST] <BenLubar> Stream #0:1 -> #0:0 (h264 (h264_cuvid) -> h264 (h264_nvenc)) [03:12:30 CEST] <realies> got two mxfs, one of which is broken, any tips on how to extract and replace the missing stream header information from the broken one? [03:13:09 CEST] <BenLubar> here's my ffmpeg command that apparently isn't using any hardware decoding capacity: https://pastebin.com/raw/j2PQFfw5 [03:38:55 CEST] <BenLubar> ok, looks like the driver wasn't reporting video decode properly. it's working now: https://i.imgur.com/YwMFDYt.png [06:05:40 CEST] <roasted> Hi. I'm reading the documentation on ffmpeg and trying to create a montage/mosaic look (2x2 video grid of four total RTSP streams). The documentation example provides an output.mkv in the command, but I don't want to save the video -- I want to simply stream it and view it live. Is there a way I can just pipe this out to ffplay? Everything I tried didn't fly. :( [06:14:36 CEST] <realies> JEEB, let me know if you can help [08:28:23 CEST] <realies> 6 hours later, still can't fix the mxf :| [08:32:35 CEST] <poutine> realies, what's wrong with it? [08:32:51 CEST] <realies> poutine, camera died while recording as far as i know [08:33:02 CEST] <realies> https://dpaste.de/s6uj/raw [08:33:26 CEST] <realies> assuming stream header is missing [08:33:31 CEST] <realies> or stream headers [08:33:31 CEST] <poutine> what's the file size? [08:33:45 CEST] <realies> 23.5G [08:34:41 CEST] <realies> got a working one from which i hope to extract and transplant missing data... https://dpaste.de/OiB8/raw [08:36:05 CEST] <realies> was hexing around for a while, but blindly adding or replacing bits from the start/end of the file was not successful [08:41:36 CEST] <poutine> Not sure, not intimately familiar with mxf, looks like the footer is usually just metadata so it's probably not that, maybe your camera just creates the header at the end [08:42:06 CEST] <poutine> https://sourceforge.net/p/ingex/discussion/531547/thread/05a1d2ee/ [08:42:15 CEST] <poutine> looks like these people had the same problem and fixed it [08:42:54 CEST] <furq> there are apparently commercial tools that will fix it [08:43:09 CEST] <poutine> they used dd, just dumped the elementary streams from the file by offset [08:46:18 CEST] <furq> if that works then great [08:47:16 CEST] <realies> furq, not having the $400 to use those services [08:47:18 CEST] <poutine> looks legit to me, even gives information on finding the offsets [08:47:27 CEST] <poutine> ymmv [08:47:31 CEST] <furq> lol [08:47:39 CEST] <realies> poutine, going through that, not sure if i'd work with xdcam, but i'll give it a go [08:47:42 CEST] <furq> i just generally assume anyone dealing with mxf has money to burn [08:47:54 CEST] <realies> yeah, maybe... [08:48:04 CEST] <poutine> realies, the important thing is the mpeg2video header [08:48:10 CEST] <poutine> finding where that starts [08:48:15 CEST] <poutine> there's actually a program called binwalk [08:48:19 CEST] <poutine> that will probably do this all for you [08:48:47 CEST] <realies> https://github.com/ReFirmLabs/binwalk uh? [08:48:53 CEST] <poutine> https://github.com/ReFirmLabs/binwalk <- possibly, have used it to find embedded files in other files before, not sure what magic numbers it has in it [08:48:54 CEST] <poutine> yup [08:49:28 CEST] <poutine> I meant do it for you meaning find the offsets you need to dd, not cut it all for you [08:50:15 CEST] <realies> sure, that's a better start than my hex attempts [08:51:49 CEST] <poutine> not seeing too much media stuff in their magic numbers db [08:52:20 CEST] <poutine> if that doesn't find anything let me know, might know some alternatives [08:55:12 CEST] <realies> poutine, that's the working file https://dpaste.de/HiNw/raw [08:55:33 CEST] <poutine> Yeah that's no good [08:59:22 CEST] <realies> noticed that the working file has xml metadata in the beginning, while the broken one is missing that data [09:05:41 CEST] <poutine> realies, ffprobe -show_format -show_packets -show_streams <your mxf file> [09:05:44 CEST] <poutine> what does that show? [09:06:01 CEST] <realies> broken or working? [09:06:05 CEST] <poutine> broken [09:06:21 CEST] <poutine> working as well I suppose [09:08:37 CEST] <realies> uh, that 20mb text file :) [09:09:53 CEST] <realies> poutine, https://dev.reali.es/tmp/working.txt and dev.reali.es/tmp/broken.txt [09:31:47 CEST] <poutine> Looks a lot less trivial than I thought :/ [09:31:51 CEST] <poutine> sorry [09:33:27 CEST] <realies> yeah, perhaps not that easy [09:49:09 CEST] <realies> continuing with the blind hex work... [09:54:03 CEST] <Nacht> Anyone happen to know what the codec_tag_string means coming from FFprobes show_streams ? ([27][0][0][0]) [10:07:14 CEST] <realies> "Copying and pasting together existing valid structures (from other playable MXF files) won't work, because every MXF file has a unique Body size, duration, and timecode." [10:07:27 CEST] <realies> well shit [10:22:17 CEST] <JEEB> yes, you'd have to re-generate the structures that actually contain the data you can salvage from non-broken files [10:22:25 CEST] <JEEB> it requires knowledge of MXF structures etc [10:23:39 CEST] <realies> JEEB, scrolled through the specs a few times... and it looks confusing [10:25:08 CEST] <realies> there's some summary of the structures and atom signature http://aeroquartet.com/movierepair/fix-mxf-files [10:26:01 CEST] <realies> i wonder if it would be possible to make ffmpeg recognise the streams and do the re-generation [10:35:51 CEST] <Nacht> realies: I just made a python script to do that [10:36:10 CEST] <Nacht> Cause I haven't found a way to do so [10:36:50 CEST] <realies> Nacht, can you please share? [10:38:42 CEST] <Nacht> Sure, one sec [10:38:50 CEST] <Nacht> It aint pretty tho [10:39:08 CEST] <realies> can't complain [10:45:12 CEST] <realies> meanwhile building bmxlib... [10:45:19 CEST] <Nacht> \https://pastebin.com/EYqzTCxB [10:45:37 CEST] <Nacht> Only need to make something to detect the video codec [10:45:43 CEST] <Nacht> as for now I just fixed it to h264 [10:46:21 CEST] <realies> errm [10:47:05 CEST] <Nacht> same with audio [10:47:34 CEST] <realies> not sure that this will help with a broken mxf [10:47:35 CEST] <Nacht> cause if you probe a h264, it just gives off 'h264', where as for the -c:v you need 'libx264' [10:48:12 CEST] <realies> Nacht, https://dpaste.de/s6uj/raw [10:48:29 CEST] <realies> working mxf: https://dpaste.de/OiB8/raw [10:50:03 CEST] <Nacht> Hmm. Im not too familiar with mxf, but it looks like some header information is broken [10:50:25 CEST] <realies> it is [10:51:39 CEST] <Nacht> Can't help with that mate. I don't know much about MXF [10:51:41 CEST] <Nacht> Sorry [10:52:51 CEST] <realies> that's fine [11:20:27 CEST] <realies> a guess this is a step forward https://dev.reali.es/tmp/mxfwrap.txt [11:23:06 CEST] <confusedjoe32> hey guys [11:23:14 CEST] <confusedjoe32> when i try to view rtsp stream [11:23:20 CEST] <confusedjoe32> the screen is unclear and green [11:23:24 CEST] <confusedjoe32> what does that mean ? [11:26:43 CEST] <realies> JEEB, are you saying that I'd have to extract and rebuild each segment from the broken file? [11:40:42 CEST] <realies> oh, the operational pattern is different for different mxf files, that's great [11:43:23 CEST] <confusedjoe32> please help me [11:43:29 CEST] <confusedjoe32> <confusedjoe32> when i try to view rtsp stream [11:43:29 CEST] <confusedjoe32> <confusedjoe32> the screen is unclear and green [11:43:29 CEST] <confusedjoe32> <confusedjoe32> what does that mean ? [11:44:20 CEST] <realies> confusedjoe32, i wish 'please help me' worked [11:45:07 CEST] <realies> you're probably dropping packets, most likely missing keyframes [11:45:27 CEST] <realies> does that help? [11:45:28 CEST] <Nacht> Green usually indicates the lack of keyframes [11:50:09 CEST] <realies> started to identify different elements within the MXF, still unsure how to rebuild the structures [11:51:17 CEST] <confusedjoe32> Nacht so how to i repair that [11:53:46 CEST] <Nacht> confusedjoe32, what is the source ? [12:16:56 CEST] <confusedjoe32> ip camera [12:17:10 CEST] <confusedjoe32> samsung SND 6013r [14:41:48 CEST] <curiouscart> hi there, i'm looking for a feature on master to be available in a release. could someone please tell me what sort of ETA i would be looking at? i couldn't find any page to track that. thanks [14:42:39 CEST] <c_14> Is it a feature or a bugfix? [14:44:31 CEST] <DHE> ffmpeg is pretty safe to run from git. is there a reason you can't build it yourself? (or use someone else's build) [14:49:47 CEST] <curiouscart> c_14: i'm not sure actually. i've been looking at this issue where a newer ffmpeg is mentioned as a solution: https://github.com/mpv-player/mpv/issues/5352 [14:50:36 CEST] <curiouscart> DHE: i totally can do that for the time being, i simply thought i'd ask in the meantime [14:53:27 CEST] <ritsuka> curiouscart: the solution to that issue is to use mpv 0.28 [14:54:43 CEST] <c_14> curiouscart: I'd assume soonish, there were some things they wanted to iron out before then though afair [14:59:29 CEST] <curiouscart> ritsuka: you're right, this has nothing to do with ffmpeg's master as i initially said [15:06:35 CEST] <curiouscart> jesus, there's been quite a few heated discussions regarding this issue. i didn't mean to open that can of worms again, i hadn't seen them. i'll just build master and wait. [15:10:31 CEST] <Fyr> guys, when using the parameter: -filter:v "filter1,filter2,filter3,etc", does FFMPEG apply them in the order they set or randomly? [15:11:49 CEST] <durandal_1707> Fyr: in order [15:12:17 CEST] <Fyr> durandal_1707, from the filter1 to filter3? [15:12:55 CEST] <durandal_1707> Fyr: it is filtered like you defined graph [15:13:04 CEST] <Fyr> ok, thanks [15:13:04 CEST] <Mavrik> Fyr: it's in that order [15:28:37 CEST] <arcmm> Hello guys, i am having some trouble using H265 with ffmpeg, my input is a sequence of .ppm yuv444p images with the resolution of 1296x964 and my output is a mp4 file, however my output resolution is changed, it is 1296x960 [15:33:00 CEST] <arcmm> i am using this command: "ffmpeg -framerate 7 -i image%04d.ppm -c:v libx265 -strict experimental h265lsmd.mp4 &> output.txt" and my output is this https://pastebin.com/qyF4DKt2 [15:33:45 CEST] <arcmm> Has anyone ever had this problem? [15:35:51 CEST] <Fyr> arcmm, what kind of trouble have you encountered? [15:36:17 CEST] <arcmm> The output file comes out with the wrong resolution, compared to the input [15:36:48 CEST] <arcmm> if i change to x264 the output resolution is fine, however if i use x265 the resolution comes out wrong [15:37:20 CEST] <Fyr> arcmm, why are you using an old version of FFMPEG? [15:37:42 CEST] <arcmm> it is the one on the ubuntu repositories [15:38:13 CEST] <Fyr> arcmm, then, it's a rather old version. [15:39:31 CEST] <Fyr> arcmm, https://launchpad.net/ubuntu/+source/ffmpeg [15:39:40 CEST] <Fyr> FFMPEG 3.3.4-2 [15:40:02 CEST] <arcmm> sorry , i am using ubuntu LTS version [15:40:40 CEST] <arcmm> however i tried using version 3.4.2-64bit-static [15:40:59 CEST] <Fyr> arcmm, https://launchpad.net/~mc3man/+archive/ubuntu/trusty-media [15:40:59 CEST] <Fyr> FFMPEG 3.3.3 [15:41:29 CEST] <Mavrik> Probably related to the fact that the video size isn't divisible by 16 [15:43:35 CEST] <arcmm> Mavrik, I see. does it only have to be divisible by 16 on x265? [15:45:16 CEST] <Mavrik> I think it's in all MPEG formats, it's just that the codec handles that internally. [15:45:27 CEST] <Mavrik> x265 should do that too... but I suspect a bug in that direction :) [15:45:36 CEST] <Mavrik> maybe update x265 if its old? [15:46:22 CEST] <arcmm> If i use another image set with resolution 1624x1224 , the output comes out right, with both x264 and x265 [15:46:36 CEST] <Fyr> arcmm, I tried to reproduce your error on Win7 x64, FFMPEG 3.4.2. [15:46:50 CEST] <Fyr> the video is as the input image. [15:47:19 CEST] <Fyr> 1296x964 [15:47:42 CEST] <Fyr> I tried the following command: [15:47:42 CEST] <Fyr> ffmpeg -f image2 -framerate 7 -i "%d.png" -c:v libx265 -preset:v veryslow -crf 0 -an -sn -threads 3 -y "output.mp4" [15:50:42 CEST] <arcmm> i will try with version 3.4.2-64bit-static and your command [15:50:49 CEST] <Fyr> arcmm, are you trying to create a movie from molecular dynamics snapshots? [15:51:16 CEST] <arcmm> Fyr, no, just a pointgrey camera that i have on a robot [15:52:03 CEST] <confusedjoe32> cock [15:52:18 CEST] <arcmm> pointgrey CMLN-13S2M-CS [15:52:40 CEST] <Fyr> arcmm, you should append the -report option to report errors. [15:53:35 CEST] <Fyr> you used "&> output.txt", you should replace it with "-report" [16:00:30 CEST] <arcmm> Fyr, using the old version it gave this output: https://pastebin.com/T2UTY3Dd [16:01:26 CEST] <FlipFlops2001> Anybody else having trouble opening "ffmpeg-20180326-3eff98c-win64-shared.zip" in Windows? [16:02:54 CEST] <Fyr> arcmm, please add the output for: [16:02:54 CEST] <Fyr> ffprobe h265lsmd.mp4 [16:03:55 CEST] <arcmm> Fyr here: https://pastebin.com/8af9QET6 [16:05:01 CEST] <arcmm> using the static newer version the resolution is still wrong, however the colors come out wrong aswell [16:05:38 CEST] <Fyr> then, I ought to say: try to use the latest version, if the problem remains, post the bugreport, arcmm. [16:06:22 CEST] <Fyr> the colors are wrong because of choosing the wrong pix_fmt. you should set it manually if FFMPEG fails to pick the proper one. [16:08:16 CEST] <Fyr> arcmm, if you are so eager to make the movie, you can send me a few images, I'll try to reproduce it on my computer. [16:08:43 CEST] <arcmm> Fyr, it is for my thesis, "sadly" i must make it :-) [16:09:16 CEST] <arcmm> it is quite big image set however i can zip 10 or so images and send you [16:09:28 CEST] <arcmm> Thank you [16:09:42 CEST] <Fyr> ok, I tried to reproduce it with a few newly created PNG files, the problem wasn't observed. [16:11:40 CEST] <Fyr> arcmm, a few images would good. [16:13:57 CEST] <arcmm> Sent a google drive link with the first 10 images of the set [16:13:58 CEST] <arcmm> Thanks [16:23:50 CEST] <Fyr> arcmm, [16:23:50 CEST] <Fyr> https://pastebin.com/AVKbGAXD [16:23:50 CEST] <Fyr> https://pastebin.com/dzHV7FnT [16:23:50 CEST] <Fyr> https://pastebin.com/1NwM6CKM [16:24:07 CEST] <Fyr> non-reproducible on my platform. [16:25:17 CEST] <arcmm> That probably means that it has something to do with the version of something i am using [16:25:25 CEST] <arcmm> Thanks Fyr, i will try changing versions [16:26:57 CEST] <Fyr> arcmm, the workaround would be to convert it losslessly into H264, then reconvert it into HEVC. [16:27:08 CEST] <Fyr> if H264 works fine. [16:28:07 CEST] <arcmm> Thanks for your time Fyr, i will try that [16:53:54 CEST] <curiouscart> is anybody able to build master? i'm seeing the following: https://pastebin.com/zPhBMDxB [16:55:40 CEST] <durandal_1707> curiouscart: i can just fine, but i use clang [16:58:10 CEST] <curiouscart> thanks, i think i should be able to request homebrew to use it [16:59:07 CEST] <durandal_1707> curiouscart: i mean, you do not need clang to build ffmpeg now [16:59:24 CEST] <durandal_1707> try make clean && make distclean [17:04:02 CEST] <curiouscart> i'm not doing this myself but indirectly through homebrew [17:06:08 CEST] <curiouscart> woops, clang's not an option actually [17:27:51 CEST] <curiouscart> i tried to mimic make clean && make distclean by removing the homebrew cache, but no luck [18:08:05 CEST] <Fyr> durandal_1707, does FFMPEG compiled with clang have advantages over that one compiled with gcc? [18:08:10 CEST] <Fyr> is it faster? [18:09:28 CEST] <JEEB> nope [18:09:36 CEST] <JEEB> or well, difference in either way is generally minimal [18:09:53 CEST] <JEEB> clang is generally utilized on macos because it's shipped with xcode [18:10:09 CEST] <JEEB> (the gcc shipped is a patched 4.2.1 so you really don't want to use that one any more) [18:10:30 CEST] <JEEB> and generally you might just like clang's warnings/errors/analyzer output [18:10:35 CEST] <Fyr> maybe, the developers should use clang on all the platforms. [18:10:46 CEST] <Fyr> since it's present on all the platforms. [18:12:29 CEST] <DHE> and lots of the performance-sensitive bits are written in assembly... [18:13:02 CEST] <JEEB> yes, and automatized vectorization is anyways disabled since every time someone enables it - it breaks binaries generated by some compiler [18:13:27 CEST] <JEEB> anyways, I use both clang and gcc on *nix since I can see the worth of having more analyzation data points [18:13:58 CEST] <JEEB> but you will not gain perf with clang on x86 or ARM at least with regards to FFmpeg [18:23:08 CEST] <FlipFlops2001> Hello and [18:23:14 CEST] <FlipFlops2001> Good Day! [18:23:54 CEST] <FlipFlops2001> Has anyone else experienced a problem opening the latest Nightly FFMPEG zip file (ffmpeg-20180326-3eff98c-win64-shared.zip)? [18:26:59 CEST] <durandal_1707> FlipFlops2001: from where you downloaded that? [18:28:49 CEST] <kevinnn> Hi all! Can anyone point me to example code that'll let me record my x11 screen and output it to h264? I know I can use x11grab with the ffmpeg cli command but I want to do it through c++ and libavcodec so I can potentially stream the frames over a network live. Thank you! [18:31:16 CEST] <FlipFlops2001> Downloaded three times from: https://ffmpeg.zeranoe.com/builds/win64/shared/ [18:31:51 CEST] <kevinnn> FlipFlops2001: downloaded what? [18:33:06 CEST] <FlipFlops2001> Repeat initial message: Unable to open downloaded zip file in Windows -"ffmpeg-20180326-3eff98c-win64-shared.zip" [18:33:31 CEST] <furq> FlipFlops2001: yeah that's broken [18:33:33 CEST] <kevinnn> FlipFlops2001: ah you're not referencing my question [18:33:46 CEST] <furq> it's about 6MB shorter than it should be [18:34:21 CEST] <FlipFlops2001> Guess I'll wait for the next Nightly Release. [18:35:50 CEST] <furq> FlipFlops2001: get ffmpeg-latest-win64-shared.zip [18:36:16 CEST] <furq> that's the same file except it works [18:37:25 CEST] <furq> i'm not really sure what kind of distribution setup zeranoe is running where one isn't a symlink to the other but nvm [18:41:20 CEST] <FlipFlops2001> The ffmpeg-latest-win64-shared.zip is the N-90433-g5b31dd1c6b version which is the previous version (2018-03-25). [18:41:54 CEST] <FlipFlops2001> Already got that version. [18:42:49 CEST] <furq> ffmpeg version N-90441-g3eff98c927 Copyright (c) 2000-2018 the FFmpeg developers [18:42:55 CEST] <furq> looks correct to me [18:43:25 CEST] <FlipFlops2001> I'll try it again. Be back. [18:58:09 CEST] <FlipFlops2001> Just downloaded "ffmpeg-latest-win64-shared.zip" from Zeranoe and upon unzipping it, it's still the N-901433-g5b31dd1c6b version. Where are you downloading the N-90441 version? Other sites like NuGet and VideoHelp also only have the N-60433 version. [18:58:41 CEST] <FlipFlops2001> Correction: N-90433 [19:01:49 CEST] <furq> https://ffmpeg.zeranoe.com/builds/win64/shared/ffmpeg-latest-win64-shared.z… [19:03:05 CEST] <FlipFlops2001> That's where I downloaded it from. [19:08:24 CEST] <FlipFlops2001> Downloaded on 3/27/2018 @ 11:53 AM CDT. Unzipped to the FFMPEG64 directory and windows explorer reports V N-90433. [19:09:04 CEST] <durandal_1707> windows exploder [19:11:28 CEST] <marcurling> Hello, how can I set a (start at) -ss mm:ss and (stop at) -t or -to at the same time? (i.e. 'stop at' never seems to work) Please provide an example or link! [19:12:22 CEST] <furq> marcurling: you need to either set them both as input options or both as output options [19:12:37 CEST] <furq> if you have one either side of -i then it won't work the way you expect [19:13:21 CEST] Action: marcurling thanks furq :) [19:15:06 CEST] <marcurling> furq: one precision, in that case, does -t counts from beginning of file or -ss set time? [19:15:46 CEST] <furq> -t is relative to -ss, -to is absolute [19:16:07 CEST] <marcurling> Thank you verymuch [00:00:00 CEST] --- Wed Mar 28 2018

1 0

ffmpeg-devel.log.20180326
by burek 27 Mar '18

27 Mar '18

[03:27:18 CEST] <cone-368> ffmpeg 03Michael Niedermayer 07master:e529fe763376: avcodec/get_bits: Make sure the input bitstream with padding can be addressed [03:27:18 CEST] <cone-368> ffmpeg 03Michael Niedermayer 07master:eb60b9d3aaaa: avformat/mov: Move +1 in check to avoid hypothetical overflow in add_ctts_entry() [03:27:18 CEST] <cone-368> ffmpeg 03Michael Niedermayer 07master:db772308941a: avcodec/mpeg4videodec: Use more specific error codes [05:54:36 CEST] <cone-368> ffmpeg 03James Almer 07master:3eff98c92788: avformat/rtpenc_chain: use the proper function to free AVFormatContext [08:59:13 CEST] <durandal_1707> kierank: eac3 or DD+ are there any real samples with > 5.1 layouts that are not test streams? [10:13:04 CEST] <gagandeep> kierank: https://pastebin.com/Bgnd9KZn [10:13:18 CEST] <gagandeep> this is the cfhd3.err i am getting on running fate [10:13:36 CEST] <gagandeep> i don't think this an error stdout [10:14:44 CEST] <gagandeep> https://pastebin.com/NvnRmb60 [10:14:53 CEST] <gagandeep> this is the cfhd3.diff [10:18:50 CEST] <durandal_1707> gagandeep: learn to inspect visual difference with ffmpeg [10:19:27 CEST] <gagandeep> durandal_1707: i mean in the cfhd3.err, i don't think it is an error stdout [10:20:01 CEST] <gagandeep> so as carl has hinted me in mail, if my patch is breaking a fate test, then either the patch is to be fixed or fate test [10:21:51 CEST] <durandal_1707> gagandeep: wtf, fate fails because there IS visual difference, you failed to spot [10:23:03 CEST] <gagandeep> ok, so it is a visual difference based error, i get it [10:23:29 CEST] <gagandeep> i will see what i can do [10:23:49 CEST] <durandal_1707> gagandeep: probably patch is incomplete [10:24:09 CEST] <durandal_1707> it check for one case, but by fixing it breaks another [11:45:43 CEST] <klaxa> wowowowow, my uni really lost that form and now wants me to resubmit it, not even sure if i can get all the acceditations i need for that, lol [11:45:45 CEST] <klaxa> gg wp [12:54:50 CEST] <Compn> CounterPillow : big money [12:55:00 CEST] <CounterPillow> Compn: ? [12:55:12 CEST] <Compn> [08:24] <CounterPillow> Gonna need to get in the middle of this with some good internet comment etiquette [12:55:33 CEST] <CounterPillow> Ah :D [12:55:57 CEST] <Compn> sounds like something big money salvia would say [12:56:12 CEST] <CounterPillow> yes [13:02:46 CEST] <durandal_1707> Compn: from where you get transcript? [13:13:40 CEST] <Compn> durandal_1707 : https://www.youtube.com/user/commentiquette/videos [13:15:35 CEST] <durandal_1707> Compn: i ask, from where you got irc transcript [13:15:49 CEST] <Compn> durandal_1707 : oh, i have a long buffer [13:16:04 CEST] <Compn> and stable internet connection [13:16:10 CEST] <Compn> aaaand power supply [13:17:11 CEST] <Compn> err my dcc not working [13:35:28 CEST] <durandal_1707> Compn: are you attempting to hack me? [14:02:42 CEST] <durandal_1707> i dont understand how is eac3 supposed to be decoded if substream id is always 0 [14:03:05 CEST] <durandal_1707> an stream depends on previous frame [14:07:27 CEST] <durandal_1707> how is you supposed to know there will be such dependent stream upfront? [14:17:53 CEST] <klaxa> atomnuker: good news, i got the documents i need [14:28:27 CEST] <nevcairiel> durandal_1707: you dont, thats the funny part [14:28:42 CEST] <nevcairiel> how do you know a dts core is followed by a dts extension [14:28:46 CEST] <nevcairiel> you just go look [14:39:02 CEST] <gagandeep> kierank: for the fate test, will my patch that is fixing padding give error with one of the test files? [14:40:02 CEST] <gagandeep> i believe the visual difference is the distortion originally present [14:40:49 CEST] <durandal_1707> gagandeep: havent you read reply i gave you on ml? [14:40:51 CEST] <Chloe> michaelni: I dont understand how this https://www.irccloud.com/pastebin/mZepxiIw/omgsoslow.c makes target_dec_fuzzer.c so much slower with the new API, could you elaborate on this and maybe share some statistics on actual impact? [14:41:21 CEST] <durandal_1707> gagandeep: fate is broken with that patch applied [14:41:26 CEST] <gagandeep> i am using blend difference on two raw output files from original ffmpeg and my patched ffmpeg [14:41:54 CEST] <durandal_1707> differences are very subtle [14:42:24 CEST] <gagandeep> yes and i am seeing the last 8 pixel distortion at the bottom [14:42:41 CEST] <gagandeep> you said that fate is matching visual output [14:43:12 CEST] <gagandeep> so if original output is wrong (the present distortion that is subtle and can't be seen just looking at file) [14:43:43 CEST] <durandal_1707> gagandeep: fate decodes file and check if it is different from reference [14:44:03 CEST] <nevcairiel> if you're fixing the decoder, maybe the reference just needs updating [14:45:10 CEST] <gagandeep> referrence is also cfhd encoded [14:45:19 CEST] <Chloe> nevcairiel: of course the new output actually needs to be correct though [14:45:39 CEST] <gagandeep> chloe: what do you mean [14:46:01 CEST] <gagandeep> https://imgur.com/a/WbLaz [14:46:02 CEST] <JEEB> same as reference [14:46:42 CEST] <Chloe> I mean if the output is different (but you expect it to be because you fixed/improved something) you still need to make sure that the output is verified to be correct [14:47:28 CEST] <nevcairiel> not necessarily, if the previous output was wrong, then being "less wrong" because there might still be other bugs is still fine [14:48:26 CEST] <gagandeep> chloe: if you know the last 8 pixel padding bug, the link that i have pasted is the one i am getting using blend diff on the refference with original ffmpeg and my patched version [14:49:00 CEST] <gagandeep> from what i gather, the refference data will need to be checked by someone [14:51:13 CEST] <Chloe> nevcairiel: all I'm saying is that you need to make sure that it is actually less wrong before you update the expected hash [14:51:55 CEST] <gagandeep> chloe: you are correct [14:52:21 CEST] <gagandeep> i have been just freaking out because fate was breaking the output [14:53:26 CEST] <gagandeep> so how will that be done [14:54:57 CEST] <durandal_1707> gagandeep: modify reference hash [14:55:12 CEST] <gagandeep> the diff that i was getting, right? [14:55:41 CEST] <durandal_1707> diff shows difference, no point in modifying it [14:55:52 CEST] <durandal_1707> diff points to reference [14:56:19 CEST] <gagandeep> yeah [14:58:07 CEST] <durandal_1707> nevcairiel: i have local hack that decodes eac3 7.1 all frames, but in wrong order, and i do not understand how and where are extra channels supposed to be used [14:58:45 CEST] <gagandeep> i believe kierank can modify the reference after personally checking the output [14:59:49 CEST] <durandal_1707> gagandeep: you can too, and post patch [15:00:06 CEST] <gagandeep> ok, i will need to find the file first [15:01:56 CEST] <nevcairiel> durandal_1707: afaik you drop the side surround channels from the 5.1 and use the 4 extra channel for side+rear [15:02:26 CEST] <nevcairiel> i think there is metadata that tells you this, though? [15:02:32 CEST] <nevcairiel> been a few years since i looked into this [15:07:37 CEST] <durandal_1707> nevcairiel: thing is channel map is 16bit, and it is always 1101000000000000, so what that means for 7.1 from 5.1 ? there is extra bit [15:08:02 CEST] <durandal_1707> the specs are not clear to me [15:08:59 CEST] <nevcairiel> that bitmask doesnt make any sense to what i see in the spec [15:09:10 CEST] <nevcairiel> unless its maybe read with wrong endianness? [15:11:28 CEST] <nevcairiel> or i'm reading it the wrong way around [15:13:47 CEST] <atomnuker> klaxa: awesome, go and write some proposal (no one will read it but maybe some pencil pushers at google) [15:13:55 CEST] <nevcairiel> section 3.8.2 in the spec seems to explain the behavior quite well to me [15:15:24 CEST] <nevcairiel> if it refers to channels that already exist in the independent substream, replace them, otherwise add them [15:15:34 CEST] <klaxa> atomnuker: i already wrote the proposal, carl-eugen sent me an email (with cc for michael and thilo borgmann) telling me i need a mentor and a qualification task, i replied that i can only confirm if i can even participate today and asked for more comments on the proposal [15:15:52 CEST] <klaxa> ah, that email was on friday [15:16:13 CEST] <klaxa> i also replied that you said you'd mentor me, maybe that was not clearly communicated? [15:16:21 CEST] <nevcairiel> (it seems quite inefficient to code replacement channels, silly dolby) [15:18:11 CEST] <durandal_1707> nevcairiel: yes, 3 channels are replaced, and what remains is 2 channels (ignoring LFE, which is coded differently) [15:19:19 CEST] <nevcairiel> so probably replaces a bunch from the core, and adds 2 more rear surround channel [15:19:23 CEST] <nevcairiel> sounds reasonable? [15:21:44 CEST] <atomnuker> klaxa: ah, yes, I see it [15:22:49 CEST] <atomnuker> klaxa: remove "This far no Qualification Task has been determined." and add some schedule below the about section, should be good then [15:22:51 CEST] <klaxa> i just now submitted the pdf, it said to let the google docs thing open for comments, but if nobody really reads it and it is formality only i guess it should be good enough [15:23:12 CEST] <atomnuker> I've marked myself as willing to mentor you on the interface [15:23:12 CEST] <durandal_1707> nevcairiel: yes, its very ugly [15:25:11 CEST] <klaxa> what would be some good points for the schedule? i think first my project needs to be integrated with libav* stuff given that i reimplemented some structs [15:25:54 CEST] <Chloe> klaxa: whatcha doin? [15:26:04 CEST] <klaxa> make ffserver great again [15:26:52 CEST] <Chloe> Ah I saw your initial work on that, I wanted to look into it [15:29:01 CEST] <Chloe> atomnuker,klaxa: idk how it works but Id be happy to answer any questions related to this as well [15:29:02 CEST] <atomnuker> klaxa: no, we should think about integration really only after the very end [15:29:12 CEST] <klaxa> oh, okay [15:29:12 CEST] <atomnuker> and I don't think it should be [15:29:33 CEST] <klaxa> hmm i looked at least at the segment.c structs and they already do what i did i think [15:29:39 CEST] <klaxa> in libavformat [15:30:48 CEST] <atomnuker> klaxa: as for the schedule, make something up per-week, that's what I've seen most students do [15:31:49 CEST] <klaxa> ok sounds good [15:47:00 CEST] <gagandeep> durandal_1707:should i send my proposal on ml [15:52:19 CEST] <durandal_1707> gagandeep: no [15:53:53 CEST] <gagandeep> ah, ok i see, on gsoc website i will submit a draft proposal [17:52:29 CEST] <cone-049> ffmpeg 03James Almer 07master:3c245707bd48: avcodec/avdct: use the proper function to free AVCodecContext [18:04:07 CEST] <durandal_1707> nevcairiel: the dependent substream is 4.0 - i expected 5.0 [18:13:52 CEST] <nevcairiel> durandal_1707: 4.0 is what I've seen, replacement side channel and new rear channel [18:14:11 CEST] <nevcairiel> But it could be something else if it wanted to [18:14:22 CEST] <JEEB> sr90: btw just ask your question here [18:14:34 CEST] <JEEB> don't privately message me via e-mail or IRC [18:14:52 CEST] <JEEB> you have much higher chances of getting help by asking here about adding a FATE test for the demuxer [18:15:16 CEST] <JEEB> (if it affects the demuxed result then most likely you will want to poke something like `ffprobe -show_packets`) [19:02:15 CEST] <durandal_1707> nevcairiel: how is one supposed to know that there is going to be dependent frame, parser splits frames instead [19:05:07 CEST] <wm4> well make the parser not split frames, or make it stateful [19:05:21 CEST] <wm4> are you trying to decode this garbage? [19:09:09 CEST] <durandal_1707> yes, i have local hack, just need remapping channels and this crap parser fix [19:13:35 CEST] <wm4> so does the decoder buffer two packets? [19:13:40 CEST] <wm4> why is the parser involved? [19:16:25 CEST] <durandal_1707> i think i found it [19:40:01 CEST] <durandal_1707> finally, fixed parser [19:44:33 CEST] <durandal_1707> but it broke normal files :) [19:49:36 CEST] <durandal_1707> does eac3 always have dependent frames? [19:50:55 CEST] <durandal_1707> guess not [19:51:27 CEST] <wm4> no [19:52:10 CEST] <wm4> keep in mind that demuxers randomly return merged or split packets too [19:57:32 CEST] <durandal_1707> there is no single bit in first packet that tells that seconds ppacket depends on first one [20:27:02 CEST] <wm4> durandal_1707: no, but there are such bits a bit later in the frame, obviously? [21:04:12 CEST] <cone-295> ffmpeg 03Gyan Doshi 07master:cfe1a9d311de: avformat/segafilm - fix keyframe detection and set packet flags [21:14:07 CEST] <michaelni> Chloe, not sure i understand what you asked. the fuzzer becomes bigger due to linking. It may become slower too but not sure who said so. The whole set of fuzzers (one for each codec thats XY gigabyte) need to be transfered over the net the way ossfuzz works IIRC [21:15:55 CEST] <wm4> except they don't need to be done this way [21:15:57 CEST] <Chloe> michaelni: I dont understand why would the size be any different? you still link to the library? [21:16:44 CEST] <michaelni> Chloe, it links in every codec, it only linked in one codec before. [21:17:56 CEST] <wm4> we had a lengthy discussion about it [21:18:02 CEST] <jamrial> Chloe: linkers optimize unreferenced symbols out. the new static api always references every codec [21:18:05 CEST] <Chloe> why cant you just link to the single codec? if you dont use any of the functions which use codec_list then they shouldnt get included right? [21:18:37 CEST] <wm4> probably ffmpeg.c misery [21:21:36 CEST] <Chloe> you dont need to call avcodec_register_all() or avcodec_register() you can use ff_whatever_decoder, the linker will optimise out the unused codecs and then it's even smaller than before [21:21:41 CEST] <Chloe> michaelni: do I misunderstand? [21:23:13 CEST] <michaelni> Chloe, maybe its possible. Someone has to try this to see if it works or if something pulls the rest in, it would be good if it works [21:24:48 CEST] <michaelni> ive a headache ATM so i wont try this one today, theres enough already that i need to do [21:31:59 CEST] <Chloe> michaelni: the time it will take me to compile all the things required to test seems to be longer than you to give it a quick look tomorrow (or even the day after). But sure there's no need to do it today [21:39:07 CEST] <atomnuker> I don't really care for the new api, I think the old one was fine [21:39:31 CEST] <atomnuker> I kinda like the suggestion to make the state the user's responsibility [21:39:41 CEST] <atomnuker> rather than some global state which requires locking [21:42:16 CEST] <wm4> like nicolas' malloc list? [21:54:28 CEST] <klaxa> atomnuker: if you have time could you check the schedule i propose and tell me if i'm over- or underestimating the time needed? i'm not too confident in my evaluation of the difficulty of the problems [21:55:11 CEST] <atomnuker> wm4: malloc list? [21:56:44 CEST] <wm4> returning a malloc'ed list of codecs [22:06:29 CEST] <atomnuker> which grows if you add new codecs? I think that's okay, anything's better than linked lists of codecs [22:07:45 CEST] <wm4> I really don't see a problem with the static list though [22:09:05 CEST] <durandal_1707> nevcairiel: you said you have eac3+ samples to share? now is time because i got it working, just need to figure mapping of channels [22:46:29 CEST] <durandal_1707> huh, there is also dolby ac4 [22:56:35 CEST] <atomnuker> wm4: I like the static list more, no global state needed, register functions, etc. [22:58:35 CEST] <atomnuker> jamrial: after you apply the packet list patch to the matroska demuxer would it still be doing various packet copying? [23:00:07 CEST] <nevcairiel> durandal_1707: I'll make a few samples from BluRay disc when I get home [23:01:29 CEST] <jamrial> atomnuker: the data is never copied before or after, just the packet structure. and even after the patch, the packets are still being copied into something [23:01:57 CEST] <jamrial> that something being linked avpacketlists instead of a constantly reallocated array of avpackets [23:06:11 CEST] <atomnuker> I remember wm4 saying the native demuxer was somewhat inefficient, is this still the case? [23:09:45 CEST] <wm4> huh [23:10:20 CEST] <durandal_1707> matroska? [23:17:07 CEST] <atomnuker> yeah [00:00:00 CEST] --- Tue Mar 27 2018

1 0

ffmpeg.log.20180326
by burek 27 Mar '18

27 Mar '18

[00:17:57 CEST] <draetheus> Does anyone have experience syncing multiple inputs in a combined mosaic output applied through a complex filter (like hstack + vstack) [00:21:51 CEST] <kepstin> I do stuff like that pretty regularly, what exactly is the issue you're having? [00:23:09 CEST] <draetheus> So I'm taking in 4 RTMP inputs, applying hstack + vstack + scale down to a single output [00:23:22 CEST] <draetheus> Even if I use the same input 4 times, the feeds always end up out of sync [00:23:39 CEST] <draetheus> I do the same thing in OBS studio and it has no issues, all feeds are in sync [00:24:11 CEST] <kepstin> right, so you're probably just hitting issues with the fact that ffmpeg isn't designed for live sources [00:24:20 CEST] <draetheus> Ah [00:24:32 CEST] <kepstin> it opens the inputs one at a time, and any data from the first will get buffered [00:24:55 CEST] <kepstin> so the end result is that they'll be offset by whatever time there is between opening the inputs [00:27:21 CEST] <draetheus> Argh, oh well, thanks [00:27:32 CEST] <draetheus> I was hoping to have a headless solution [00:28:04 CEST] <kepstin> i've seen people do workarounds like having one ffmpeg per input going to pipes and having a final one read the pipes and do the combining [00:28:15 CEST] <kepstin> that way if you start the inputs at the same time they'll be synced [00:28:39 CEST] <kepstin> but the proper fix is using an app better designed for this (which can use the ffmpeg libraries, of course) [00:32:34 CEST] <draetheus> as far as I have found there is no other CLI/headless solution [00:44:57 CEST] <debianuser> user890104: if by any chance you're user234234 - you have some issue with the driver or hardware. "Input/output error" for arecord means that the driver for some reason couldn't get the audio from the card. Maybe some power or usb bandwidth issue. If the driver detected the reason, it should be in `dmesg` - check if there're any hints in there. [12:05:59 CEST] <barhom> Anyone know of an nvidia patch (nvenc patch) to remove the 2stream limitation? [12:08:37 CEST] <BtbN> no [12:08:49 CEST] <BtbN> It's not ffmpeg imposing that limit [12:09:04 CEST] <BtbN> you need a quadro card to not have it [12:10:09 CEST] <barhom> BtbN: I know it isnt ffmpeg, its the nvidia driver [12:10:19 CEST] <BtbN> Which is closed source. [12:10:27 CEST] <barhom> doesnt mean you cant patch it [12:10:38 CEST] <barhom> (morals are put aside right now) [12:10:38 CEST] <BtbN> That's exactly what it means [12:10:52 CEST] <BtbN> The only thing you can patch is the binding layer that wires it into the Kernel [12:10:57 CEST] <BtbN> And that's not what generates the limit [12:11:26 CEST] <barhom> I have it from a good source it does work, some gdb magic and change some instructions [12:13:11 CEST] <barhom> https://developer.nvidia.com/video-encode-decode-gpu-support-matrix < shows number of chips and such of the tesla/quadro cards. Do we have such info for the desktop ones? [12:13:31 CEST] <BtbN> nope [12:13:35 CEST] <BtbN> but the Chip names match up [12:13:45 CEST] <BtbN> each generation has the same silicon [12:18:46 CEST] <barhom> BTBN: Which comparison NVENC should I look up for the GTX960 4gb then? [12:21:16 CEST] <BtbN> Should be Maxwell [12:22:36 CEST] Action: JEEB double-blinks at scale=w=-2:h=480 not giving expected DAR [12:22:50 CEST] <JEEB> I guess it tries to match the SAR of the input [12:52:42 CEST] <barhom> BtbN: Let assume the 2 stream limitation didnt exist. How much ram you think we need to fully utilize the nvenc chip? 2 or 4gb? [12:52:48 CEST] <barhom> I doubt we need the 6 or 8gb [12:53:11 CEST] <barhom> RAM could be the bottleneck without the 2 stream limitation [13:21:27 CEST] <BtbN> barhom, you need vram [13:21:34 CEST] <BtbN> how much depends entirely on your configuration [13:21:45 CEST] <BtbN> 4K encoding obviously needs more [13:31:44 CEST] <barhom> vram? [13:32:22 CEST] <barhom> BtbN: We're talking about the same thing no? The ram on the GFX, 2,4,6,8gb [14:00:40 CEST] <DHE> does the video encoder, which is discrete silicon, use the same memory as the main GPU? I don't know. it might... [14:04:19 CEST] <BtbN> Of course it does [14:47:47 CEST] <Liam__> Hi [14:47:59 CEST] <Liam__> I need help installing ffmpeg on mac. [14:48:10 CEST] <Liam__> is there somebody who can help me? [14:55:38 CEST] <pmjdebru1jn> Liam__: define "install" [14:56:19 CEST] <pmjdebru1jn> https://evermeet.cx/ffmpeg/ is you get a static binary there, it's just a single executable IIRC [14:57:02 CEST] <pmjdebru1jn> for example https://evermeet.cx/ffmpeg/ffmpeg-3.4.2.dmg [14:57:10 CEST] Action: pmjdebru1jn hasn't got any personal experience with OS X [14:58:54 CEST] <dystopia_> you can add it to your paths so it can be called from anywhere [15:02:55 CEST] <Liam__> thanks [15:02:58 CEST] <Liam__> i got the file [15:03:06 CEST] <Liam__> but i dont know how to make it run [15:04:47 CEST] <pmjdebru1jn> Liam__: ffmpeg is a commandline tool [15:04:51 CEST] <Liam__> yes [15:04:57 CEST] <pmjdebru1jn> so just go the path where you have the binary, and run it from a terminal [15:06:28 CEST] <Liam__> cd ffmpeg [15:06:32 CEST] <Liam__> and a bunch of files [15:06:36 CEST] <Liam__> i opened readme [15:06:42 CEST] <Liam__> and tried to follow instructions [15:07:13 CEST] <Liam__> wants me to use makefile and build a tre [15:07:14 CEST] <Liam__> tree [15:07:50 CEST] <Liam__> i mean install.md [15:08:03 CEST] <pmjdebru1jn> huh? [15:08:12 CEST] <pmjdebru1jn> that sounds like sources? [15:08:14 CEST] <pmjdebru1jn> not a binary [15:08:23 CEST] <Liam__> oh [15:08:31 CEST] <Liam__> so a binary lets me use it instantly? [15:08:36 CEST] <pmjdebru1jn> are you looking inside? https://evermeet.cx/ffmpeg/ffmpeg-3.4.2.dmg ? [15:11:02 CEST] <Liam__> CONTRIBUTING.md README.md libavformat COPYING.GPLv2 RELEASE libavresample COPYING.GPLv3 compat libavutil COPYING.LGPLv2.1 config.h libpostproc COPYING.LGPLv3 configure libswresample CREDITS doc libswscale Changelog ffbuild presets INSTALL.md fftools tests LICENSE.md libavcodec tools MAINTAINERS libavdevice Makefile libavfilter [15:11:10 CEST] <Liam__> thats inside the file [15:11:39 CEST] <Liam__> is this a binary? [15:12:04 CEST] <pmjdebru1jn> find -name ffmpeg [15:15:57 CEST] <Liam__> it says illegal option --n [15:16:20 CEST] <pmjdebru1jn> find . -name ffmpeg [15:16:22 CEST] <pmjdebru1jn> maybe [15:16:33 CEST] <Liam__> command not found [15:16:42 CEST] <pmjdebru1jn> huh? [15:16:42 CEST] <Liam__> oh the dot [15:17:49 CEST] <Liam__> ls CONTRIBUTING.md README.md libavformat COPYING.GPLv2 RELEASE libavresample COPYING.GPLv3 compat libavutil COPYING.LGPLv2.1 config.h libpostproc COPYING.LGPLv3 configure libswresample CREDITS doc libswscale Changelog ffbuild presets INSTALL.md fftools tests LICENSE.md libavcodec tools MAINTAINERS libavdevice Makefile libavfilter [15:18:08 CEST] <Liam__> it looks like the same [15:18:14 CEST] <pmjdebru1jn> I didn't ask ls [15:18:16 CEST] <pmjdebru1jn> I asked [15:18:18 CEST] <pmjdebru1jn> find . -name ffmpeg [15:18:32 CEST] <Liam__> nothing happened [15:18:48 CEST] <pmjdebru1jn> that would imply the DMG hasn't got the binary [15:20:08 CEST] <Liam__> okay.. [15:20:25 CEST] <Liam__> im trying this then, no? ... https://www.npmjs.com/package/ffmpeg-static [15:23:11 CEST] <pmjdebru1jn> Liam__: I just checked the .dmg, it has a single file in it [15:23:14 CEST] <pmjdebru1jn> called ffmpeg [15:23:18 CEST] <pmjdebru1jn> so I have no clue what you're doing [15:24:20 CEST] <pmjdebru1jn> Liam__: just exact the ffmpeg binary from the dmg, and place it where you want [15:24:20 CEST] <Liam__> ^^ [15:24:45 CEST] Last message repeated 1 time(s). [15:24:45 CEST] <Liam__> its a exec file [15:24:59 CEST] <pmjdebru1jn> it's an executable yes [15:25:10 CEST] <Liam__> when i open it [15:25:22 CEST] <Liam__> terminal opens and it says process completed [15:25:47 CEST] <Liam__> but when im in the terminal [15:25:51 CEST] <pmjdebru1jn> it's a terminal application, you need to start if _from_ a terminal [15:25:51 CEST] <Liam__> and try ffmpeg [15:25:57 CEST] <Liam__> it says command not found [15:26:03 CEST] <pmjdebru1jn> because it's not in your PATH [15:26:07 CEST] <pmjdebru1jn> as suggested earlier [15:26:10 CEST] <Liam__> oh [15:26:14 CEST] <pmjdebru1jn> /Applications/whatever/ffmpeg [15:26:18 CEST] <Liam__> so i cd into ffmpeg [15:26:28 CEST] <Liam__> and the ffmpeg blabla [15:26:39 CEST] <pmjdebru1jn> ? [15:26:44 CEST] <pmjdebru1jn> if you in the directory [15:26:48 CEST] <pmjdebru1jn> you need to start it with [15:26:49 CEST] <pmjdebru1jn> ./ffmpeg [15:26:57 CEST] <pmjdebru1jn> as it's still not in your PATH [15:27:45 CEST] <Liam__> oh [15:29:23 CEST] <Liam__> ok thank you [15:29:35 CEST] <Liam__> i think im running it now [15:38:55 CEST] <Liam__> Oh man Pedrosouza it worked :D [15:39:28 CEST] <Liam__> thanks a lot for your help and your patience :D :D [15:47:23 CEST] <colekas> hello friends, I'm looking to do a simple remuxing of packets using mepgts, however I'm kind of confused from the results of setting muxrate before calling the write_header command [15:47:35 CEST] <colekas> is the muxrate in bits? [15:48:18 CEST] <colekas> do I need to set anything else? [15:48:57 CEST] <DHE> mpegts -muxrate setting is in bits per second [15:49:10 CEST] <DHE> with the usual k,M,G suffixes accepted [15:57:38 CEST] <th3_v0ice> Does anyone know how can I force ffmpeg decoder to not care about duplicate frames and just give me whatever it decoded from packets? I am using API. [15:58:46 CEST] <JEEB> the decoder shouldn't duplicate frames if they're not duplicated in the original stream [16:01:10 CEST] <iive> actually i do not remember what ffmpeg12 does with the picture repeat... [16:07:46 CEST] <th3_v0ice> JEEB: It seems that in some videos that I process some frames either have similar timestamps or something and ffmpeg marks them as duplicates and gives me one frame. I want the other one also because I need to do frame to frame comparison between input and output. The interesting thing is that while decoding to YUV FFmpeg is also not displaying those frames. For example x264 bitstream has 1500 frames, FFmpeg while decoding to YUV only gives 1490. [16:09:41 CEST] <JEEB> that sounds like ffmpeg.c logic, not what lavc would be returning [16:09:50 CEST] <JEEB> also are you sure you are flushing the decoder? [16:10:48 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [16:10:55 CEST] <JEEB> related to the flushing part here [16:15:44 CEST] <th3_v0ice> JEEB: I was using avcodec_decode_video2(), not the latest API, is this required for the older API? Because if I saw correctly avcodec_decode_video2() is just calling the new API instead of me. [16:18:11 CEST] <JEEB> yes, you will have to flush the decoder always [16:18:15 CEST] <JEEB> with old or new API [16:18:22 CEST] <transcodeine> howdy. [16:18:41 CEST] <transcodeine> still working on this 'too many packets buffered' error [16:18:41 CEST] <JEEB> and the old API can be buggy, and it's deprecated since more than a year or two. so if possible you should start moving to the push/pull API [16:19:42 CEST] <th3_v0ice> JEEB: Ok, will do. Thanks! [16:19:44 CEST] <transcodeine> cur_dts is invalid (this is harmless if it occurs once at the start per stream) Last message repeated 2040 times [16:20:09 CEST] <transcodeine> this repeats about 25x before it bombs out with the 'too many packets buffered' error [16:21:08 CEST] <th3_v0ice> transcodeine: Are you generating the PTS and DTS for packets? [16:21:22 CEST] <transcodeine> yes sir, JEEB helped me determine that [16:21:36 CEST] <transcodeine> via lboxdumper [16:21:40 CEST] <transcodeine> boxdumper [16:22:07 CEST] <th3_v0ice> I should've asked first, are you using API or CLI? [16:22:15 CEST] <transcodeine> cli [16:22:36 CEST] <th3_v0ice> Did you try with -reset_timestamps? [16:22:48 CEST] <transcodeine> i did not. i will [16:23:10 CEST] <transcodeine> should i leave -max_muxing_queue_size? [16:23:19 CEST] <transcodeine> doesn't seem to help [16:23:47 CEST] <transcodeine> although in the bug description some people have indicated it was a temporary workaround.. [16:23:49 CEST] <th3_v0ice> Try without it first. [16:23:52 CEST] <transcodeine> ok [16:24:30 CEST] <th3_v0ice> Then you can try with that option as well. [16:26:31 CEST] <transcodeine> i don't see that option [16:33:39 CEST] <barhom> BtbN, DHE: Yes it uses the same memory as the GPU. But that was one of my questions. All cards have the same NVENC chip. Question is how much memory you want on the GPU to fully utlize the NVENC chip. 2,3,4gb? [16:34:57 CEST] <th3_v0ice> transcodeine: -reset_timestamps 1 [16:37:10 CEST] <transcodeine> Too many packets buffered for output stream 0:1. [16:37:13 CEST] <transcodeine> same error with that option [16:38:03 CEST] <transcodeine> i'm passing "./ffmpeg -v debug -hwaccel cuvid -c:v h264_cuvid -i src.mov -c:a aac -c:v h264_nvenc -max_muxing_queue_size 9999 test.mp4 -ar 48000 -ac 2 -reset_timestamps 1" [16:38:14 CEST] <transcodeine> with or without max muxing, doesn't matter. [16:39:15 CEST] <DHE> barhom: I don't know enough about the details to make a call. but I would imagine much less than 50 megabytes per video... 1080p with ~4 frames lookahead at 4:2:0 doesn't need all that much RAM [16:42:50 CEST] <th3_v0ice> transcodeine: I assume that audio is 0:1 stream. If you turn it off does it work? I am sorry but that is all that I can think of right now. [16:44:24 CEST] <transcodeine> fwiw it works w/o using hardware encoding if that gives anything away [16:50:21 CEST] <transcodeine> i'm going to dump the debug to pastebin [16:50:52 CEST] <transcodeine> https://pastebin.com/KULCVz1V [16:51:46 CEST] <JEEB> ok, that just sounds like the hw encoder is derping up [16:51:49 CEST] <JEEB> try with -debug_ts [16:51:54 CEST] <JEEB> and see what comes out of the encoder [16:52:00 CEST] <transcodeine> def agree [16:53:34 CEST] <transcodeine> output: [16:53:35 CEST] <transcodeine> https://pastebin.com/2YdCWULk [16:58:04 CEST] <transcodeine> i got a bunch of warnings at compile time, maybe i need to revisit my compile [16:59:38 CEST] <th3_v0ice> If you output to mov again, does it work? [17:00:46 CEST] <confusedjoe32> hey [17:00:50 CEST] <confusedjoe32> can you please help me guys [17:01:04 CEST] <confusedjoe32> im trying to watch a rtsp stream, but the video is messed up [17:01:29 CEST] <transcodeine> negative [17:01:36 CEST] <transcodeine> still bombs [17:02:47 CEST] <confusedjoe32> hello ? [17:46:42 CEST] <colekas> how come none of the muxing/remuxing examples in the source code set the muxrate? [17:47:06 CEST] <colekas> I'm getting PCR errors when trying to use ffmpeg to remux a multicast stream [17:47:18 CEST] <colekas> so I thought setting muxrate in the av_dict before write_output_headers would work [17:47:27 CEST] <colekas> but I'm getting odd behavior, like the write blocking [17:47:32 CEST] <colekas> and getting gigabytes of data [17:50:30 CEST] <JEEB> because the examples really didn't feed into some specific use case other than the most basic that the author made I think [17:58:06 CEST] <transcodeine> Jeeb and Th3_v0ice- so hw encoding works fine for mp4 > mp4. its > mov to mp4 that causes that too many packets buffered error [17:58:35 CEST] <transcodeine> if i remove -hwaccel cuvid it will encode- but no faster than cpu :\ [17:59:14 CEST] <transcodeine> i'm getting 14x when it works- too bad i can't get this mov to transcode [18:01:42 CEST] <JEEB> check the timescale/time base of the input for shits and giggles if the difference is the input file [18:01:53 CEST] <JEEB> and as I noted, start logging stuff with -debug_ts [18:02:03 CEST] <JEEB> 2> long_darn.log [18:02:04 CEST] <JEEB> for example [18:02:12 CEST] <JEEB> will throw the stderr into the long_darn.log [18:02:14 CEST] <JEEB> file [18:04:47 CEST] <moshisushi> transcodeine: good nickname m8! [18:05:51 CEST] <pkeroulas> Hello everyone, I'm trying to add support of the interlaced format in libavformat/rtpdec_rfc4175.c and re-encode the result to h264. I can either keep the received fields separated and make AVFrames from each of them OR I can reconstruct progressive frames (with the help of yadif filter). libx264 seems to work either way. So my question is: which method should I use? Is it a good practice to keep interlaced fields in the decoding [18:05:51 CEST] <pkeroulas> process? [18:07:30 CEST] <JEEB> decoding in lavc for H.264 interlacism gives you two fields in a single picture [19:08:29 CEST] <transcodeine> moshi :) [19:09:05 CEST] <transcodeine> jeeb- def the input file is the issue along with the hw encoding [19:12:06 CEST] <transcodeine> stripping all audio didn't seem to improve things either- e.g. -an -vcodec copy [19:17:59 CEST] <transcodeine> is it possible that what's happening is that the src file which is 4:2:2 is being rejected by the hw encoder? [19:19:05 CEST] <transcodeine> from nvidia: "4:2:2 chroma subsampling is not supported by NVENC hardware (for encoding) or NVDEC hardware (for decoding)." [19:25:38 CEST] <furq> transcodeine: it's probably being rejected by the decoder then [19:28:38 CEST] <transcodeine> can i split off the color conversion to software? [19:38:34 CEST] <JEEB> if it was encoding, yes [19:38:39 CEST] <JEEB> most likely it's the decoding, though :P [19:39:59 CEST] <transcodeine> can you suggest the filter/switch for that to offload decoding to cpu? [19:40:17 CEST] <transcodeine> i'm screwing around but can't seem to find the right mix [19:40:40 CEST] <transcodeine> oh wait..nevermind. you're saying it's the decoder. [19:40:43 CEST] <transcodeine> blah [19:42:33 CEST] <JEEB> or well, it all depends on which part of the process is slow :P but in any case you wouldn't be doing it all pretty all-in-gpu-memory [19:42:39 CEST] <JEEB> which already introduces speed loss [19:43:52 CEST] <transcodeine> i can't tell can i? [19:44:41 CEST] <transcodeine> nvenc won't do 4:2:2 but it will do 4:4:4- so i COULD upsample to 4:4:4 in hw then transcode to 4:2:0- the desired output [19:48:03 CEST] <JEEB> uhh [19:48:10 CEST] <JEEB> what will 4:4:4 support in the encoder help you again? [19:48:25 CEST] <JEEB> if your input is 4:2:2 and that's the part that has to be decoded [19:48:38 CEST] <JEEB> also no, nvidia does not support decoding of 4:4:4 in hardware [19:48:46 CEST] <JEEB> it's an encoding-only feature [19:50:45 CEST] <transcodeine> yeah i'm grasping at straws here [19:52:36 CEST] <JEEB> just decode in software, do the colorspace conversion in software and push either into x264 preset superfast or the darn hw encoder :P [19:55:11 CEST] <transcodeine> right. i'm not certain how to compose that command line to do that. [19:55:28 CEST] <pkeroulas> JEEB, thank you. [20:05:24 CEST] <furq> transcodeine: presumably just remove -c:v h264_cuvid and add -vf format=yuv420p [20:05:42 CEST] <furq> you should still be able to use nvenc after that [20:09:06 CEST] <transcodeine> furq- that bombs at the beginning if replaced [20:12:08 CEST] <transcodeine> ok i got the cmdline right. [20:12:12 CEST] <transcodeine> it's very slow w/o hw [20:12:34 CEST] <transcodeine> bg [20:27:58 CEST] <transcodeine> tweaked it to get about 5.25x [20:32:46 CEST] <mssng_chrs> Hello there, I'm trying to use ffmpeg with the new libndi output. I'd like to stream my USB mic (audio only) over NDI to another machine so I can use it as input in OBS Studio. I was able to find how to get the mic as input using Alsa, but I haven't found anything on the settings for audio-only NDI output. Has anyone played with NDI yet? [21:43:24 CEST] <mssng_chrs> Found a solution to my problem. NDI is working flawlessly :D See you [21:45:40 CEST] <blue_misfit> hey folks! I've been working on a process for ABR encoding of HEVC using ffmpeg + libx265 and I'm trying to get the GOP part of things optimized [21:45:53 CEST] <blue_misfit> I'm using parallel chunk encoding, so the simplest approach is to start with fixed GOP [21:46:15 CEST] <blue_misfit> e.g. keyint=48:scenecut=0 to make 2 second fixed GOPs assuming 24p input [21:47:05 CEST] <blue_misfit> first - is my above assumption correct (that keyint=48:scenecut=0) in the -x265-params will absolutely insert an IDR every 48 frames and no others? [21:47:44 CEST] <blue_misfit> second - is there a good way to guarantee that I get an IDR every 48 frames, but also let the encoder use non-IDR I frames whenever it wants (to improve quality)? [21:48:20 CEST] <blue_misfit> seeing some weird advice online about using force_key_frames, setting keyint to twice what I actually want, and setting keyint-min to waht I actually want, which seems really really strange [22:22:14 CEST] <wfbarksdale> does anyone know the difference between these two compiler options? "--disable-vda disable Apple Video Decode Acceleration code [autodetect]" and "--disable-videotoolbox" ? [22:22:38 CEST] <wfbarksdale> i thought videotoobox WAS the apple hardware acceleration? [22:22:53 CEST] <wfbarksdale> so what is this "vda" ? [22:23:37 CEST] <kerio> The following frameworks are no longer part of the OS X SDK as of version 10.11: VideoDecodeAcceleration. Use VideoToolbox.framework instead. [22:25:59 CEST] <wfbarksdale> thanks kerio! [22:34:09 CEST] <kerio> o no ffmpeg HEAD doesn't build in brew D: [22:34:21 CEST] <kerio> pls halp [22:34:55 CEST] <kerio> use of undeclared identifier 'AV_INPUT_BUFFER_PADDING_SIZE' [23:58:24 CEST] <BenLubar> ffmpeg isn't allowing me to enter this as the filter for setpts or asetpts: https://pastebin.com/raw/ikYSZp3s [23:59:43 CEST] <BenLubar> oh, it's because of the commas, isn't it [00:00:00 CEST] --- Tue Mar 27 2018

1 0