Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2016

1 participants
62 discussions

ffmpeg-devel.log.20160330
by burek 31 Mar '16

31 Mar '16

[00:20:02 CEST] <michaelni> atomnuker, have you looked at the gaplessenc-pcm-to-mov-aa failure ? [00:20:20 CEST] <michaelni> gaplessenc-pcm-to-mov-aac [00:23:06 CEST] <michaelni> also aac-fixed-al_sbr_hq_cm_48_2 and others fail on arm [00:26:46 CEST] <atomnuker> I did actually, it was the PNS system doing something weird again [00:27:13 CEST] <atomnuker> I didn't have time to find a fix yet though [00:27:59 CEST] <michaelni> ok, but the number of fate and aac issues is growing and these things must be dealt with [00:30:28 CEST] <atomnuker> clipping the quantization value might work as a temporary workaround [00:30:50 CEST] <atomnuker> will give that a try [00:32:13 CEST] <michaelni> atomnuker, thx, btw, if there are crashes which you cannot reproduce (i think i rememer something like that, not sure which ticket it was) it might help to avoid all uninitialized memory that could make aacenc take more similar codepaths on user & devel system [00:34:33 CEST] <atomnuker> I think that was a long time ago and got fixed by Claudio's fixes, haven't had unreporoducable bugs [00:36:23 CEST] <michaelni> hmm, ok then should these be closed ? http://trac.ffmpeg.org/ticket/4943 http://trac.ffmpeg.org/ticket/4942 [01:40:43 CEST] <atomnuker> av_clip_uintp2(something, 8) should be equivalent to av_clip(something, 0, 256), right? [01:48:59 CEST] <mark4o> atomnuker: av_clip(something, 0, 255) [01:50:05 CEST] <jamrial> atomnuker: for that just use av_clip_uint8(something) [01:51:35 CEST] <atomnuker> I ask because I think clang miscompiles av_clip_uintp2 and causes that fate test to fail [01:54:01 CEST] <jamrial> replace it with uint8 then. worth trying and it's technically the "more correct" choice as well [01:55:20 CEST] <atomnuker> acutally it's av_clip_uintp2(something, 13) so av_clip(something, 0, (1 << 13) - 1) seems more appropriate [02:06:02 CEST] <cone-507> ffmpeg 03Rostislav Pehlivanov 07master:c0918613a0ec: aacenc: use av_clip() instead of av_clip() during quantization [02:06:44 CEST] <atomnuker> michaelni: should be fixed now [02:07:35 CEST] <ubitux> wtf [02:07:51 CEST] <mark4o> av_clip_uintp2_c does look buggy for the case where a == INT_MIN [02:09:23 CEST] <michaelni> didnt the INT_MIN occur due to a float -> int overflow? [02:12:20 CEST] <michaelni> casting out of range float to int is undefined behavior, anything can happen it can fail in any way on any system with any random pattern [02:13:53 CEST] <michaelni> iff the huge float is correct and intended then the cliping must be done before converting to int [02:14:12 CEST] <michaelni> no idea if the float value is correct or not i dont know the code [02:14:44 CEST] <michaelni> atomnuker, ^# [02:14:48 CEST] <michaelni> s/#// [02:17:16 CEST] <atomnuker> the float value might definitely be out of range, and it could happen in any code which touches the spectral coefficients [02:17:37 CEST] <atomnuker> Claudio agreed this would work as a quick fix to find out which one it is [02:18:53 CEST] <atomnuker> though that still doesn't explain why the quantization index is out of range [02:22:08 CEST] <michaelni> so its now not only wrong but covered up ? [02:23:00 CEST] <michaelni> undefined behavior is not ok and is not safe [02:23:22 CEST] <michaelni> this very easily can crash on some platforms [02:23:30 CEST] <atomnuker> still not sure where the issue happens, but the overflow definitely happens in -a >> 31 & ((1<<p) - 1) [02:23:36 CEST] <atomnuker> which is after the float to int conversion [02:23:58 CEST] <michaelni> if float is out of range there is no after the cast [02:24:21 CEST] <michaelni> "after the cast" is like the end of the universe for the program if the cast is undefined beavior [02:25:36 CEST] <michaelni> "-a" is bad if a is INT_MIN but if we end at INT_MIN because float is outside INT_MIN .. INT_MAX then "-a" is after the problem [02:25:55 CEST] <atomnuker> so you think it's best to do the float to int coast separately [02:26:15 CEST] <atomnuker> s/coast/cast [02:29:41 CEST] <michaelni> 6.3.1.4 Real floating and integer: When a finite value of real floating type is converted to an integer type other than _Bool,the fractional part is discarded (i.e., the value is truncated toward zero). If the value of the integral part cannot be represented by the integer type, the behavior is undefined.) [02:31:00 CEST] <michaelni> <-- Thus implicitly or explicitly casting a float value that has a integral part outside INT_MIN..INT_MAX to a int is a bug [02:31:10 CEST] <michaelni> also for example even if that value is not used [02:32:24 CEST] <michaelni> clang has every right to give a negative value to a too large positive float, or terminating the program or calling the ghost busters [02:32:43 CEST] <atomnuker> fair enough, it's a bug [02:35:01 CEST] <atomnuker> for now it's covered up until we can find why it happens to keep FATE happy [03:00:44 CEST] <michaelni> atomnuker, ffmpeg now fails with gcc too "Assertion n <= 31 && value < (1U << n) failed at libavcodec/put_bits.h:157" [03:01:19 CEST] <michaelni> i suggest to revert this patch [03:29:45 CEST] <atomnuker> odd, I did test it with assert level 2 [03:29:48 CEST] <atomnuker> I'll revert it [03:33:04 CEST] <cone-507> ffmpeg 03Rostislav Pehlivanov 07master:7cda7683a547: Revert "doc/filters: remove false claim in sofalizer description" [03:33:05 CEST] <cone-507> ffmpeg 03Rostislav Pehlivanov 07master:02172d93f6b2: Revert "aacenc: use av_clip() instead of av_clip() during quantization" [03:33:57 CEST] <atomnuker> GODDAMNIT IT [03:34:05 CEST] <atomnuker> *GIT [03:34:42 CEST] <atomnuker> sorry durandal... he's not here [03:36:22 CEST] <cone-507> ffmpeg 03Paul B Mahol 07master:974734c98ce4: doc/filters: remove false claim in sofalizer description [03:37:49 CEST] <michaelni> ill post a patch that works around the undefined behavior [03:38:04 CEST] <michaelni> but fixing it is for someone who knows aac [03:38:14 CEST] <atomnuker> I'll get to the bottom of this bug, it's definitely in the coder [03:38:58 CEST] <atomnuker> 600+ lines of code for a single continuous function can't lack a few [03:39:52 CEST] <atomnuker> but I made a large enough mess today to know when to give up and sleep [03:40:45 CEST] <michaelni> atomnuker, also theres somethig else odd coef is cliped to 0.. but 0..15 seem to be faulty in the following put_bits due to them ending in negative values in shifts [03:41:04 CEST] <michaelni> or negative value in put_bits and [03:41:42 CEST] <michaelni> is the puts_sbits intended to store only positive values? [03:41:55 CEST] <atomnuker> also I do remember reading somewhere that put_bits for 0 bits isn't very correct [03:42:05 CEST] <michaelni> yes [03:43:28 CEST] <michaelni> the code smells a bit like the sbits is intended to get a coeff that can be also negative but the code passes one cliped to 0..1<<13 IIUC [03:43:56 CEST] <michaelni> anyway, ill post my patch and the go to sleep too :) [03:44:06 CEST] <atomnuker> definitely odd, I'll check what the specs say about BT_ESC [03:46:07 CEST] <michaelni> yes please do [03:46:40 CEST] <michaelni> after sleeping that is, sleep is important if you are tired :) [04:01:33 CEST] <TheRyuu> michaelni: responded to that mingw-w64 gdb thing and sent in a patch [04:21:35 CEST] <Zeranoe> Interestingly the MFX/QSV hang does not happen when using Intel's "sample_encode" program. It must be in the way FFmpeg is implementing it. [04:28:15 CEST] <cone-507> ffmpeg 03Michael Niedermayer 07master:c7b983249aa4: tests/audiomatch: also print signal vs reference length [04:28:16 CEST] <cone-507> ffmpeg 03Michael Niedermayer 07master:b3ec5b00ce6e: tests/audiomatch: Reduce search window [11:25:07 CEST] <BtbN> Do these HEVC AUDs have any negative effects, or why do they have to be explicitly enabled if some (shitty?) players need them? [11:25:57 CEST] <kierank> AUDs make it *much* easier to parse frames [11:26:07 CEST] <kierank> parse pictures to be more precise [11:26:13 CEST] <kierank> it's mandatory in mpeg-ts for example [11:26:25 CEST] <Mavrik> Not sure about HEVC, but I've seen bunch of players choke and die on AUD streams. [11:26:30 CEST] <Mavrik> iOS 7 was one of those. [11:26:35 CEST] <nevcairiel> containers like mkv and mp4 usually dont have them, but in my experience it usually also has never broken anything if its present [11:26:37 CEST] <Mavrik> H.264 that is. [11:26:53 CEST] <Mavrik> I'd guess HEVC decoders have that fixed by now. [11:26:59 CEST] <BtbN> So just hardcoding them to enabled shouldn't be an issue? [11:27:17 CEST] <nevcairiel> does nvenc differentiate between generating mp4-style and annexb? [11:27:26 CEST] <BtbN> Not that I'm aware of. [11:27:32 CEST] <nevcairiel> if yes, do it with annexb only, imho, if not, just turn it on [11:28:20 CEST] <nevcairiel> BtbN: usually thats controlled by the global_header flag [11:29:14 CEST] <nevcairiel> but it shouldnt really harm anything to generate them always [11:30:47 CEST] <BtbN> "if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {" ? [11:31:53 CEST] <BtbN> that's translated to disableSPSPPS/repeatSPSPPS. And if disabled, the extradata is copied to a buffer once at startup [11:34:54 CEST] <BtbN> I don't think this controls how NVENC writes its NAL stuff, that's probably allways Annex B I'd assume. [11:56:13 CEST] <Guest76821> Hi there. Recently I sent a test but Michael says it's hard to keep updated. He is right. The test is for alphaless_fmt() function, it basically a function with a switch and a lot of cases. I have no idea how to do a good test for this. Any idea? [11:58:39 CEST] <petrurares> In the old test I did the following code for each case: [11:58:53 CEST] <petrurares> result = alphaless_fmt(AV_PIX_FMT_ARGB) == AV_PIX_FMT_RGB24; [11:58:54 CEST] <petrurares> printf("AV_PIX_FMT_ARGB == AV_PIX_FMT_RGB24 ? %d\n", result); [11:59:46 CEST] <wm4> I question the need for such fine grained tests, they probably cause more trouble than they help [12:00:19 CEST] <wm4> and often higher level tests will be better, e.g. it might be better to just test libswscale output with various alpha and non-alpha pixfmts [12:01:36 CEST] <petrurares> ok, surely that is better [12:06:08 CEST] <BtbN> hm, can't see anything breaking with enabled AUD. [12:07:53 CEST] <cone-303> ffmpeg 03Timo Rothenpieler 07master:b3557c79dcd8: avcodec/nvenc: Generate AUD NAL units for better compatiblity [12:08:39 CEST] <wm4> nevcairiel: do you have a sample for the flv metadata case that the not-merged libav commit supposedly broke? [15:04:49 CEST] <cone-303> ffmpeg 03Claudio Freire 07master:c883da6bf461: AAC encoder: fix signed integer overflow [15:52:21 CEST] <kierank> Gramner: is there a way of doing >> 0 with pmulhuw [15:55:42 CEST] <Gramner> maybe not [15:57:06 CEST] <kierank> I think we can do it with PMULHRSW [15:57:08 CEST] <Gramner> pmulhrsw shoule be able to, but only your input is less than 0x0200 or something like that [15:58:14 CEST] <Gramner> because a real no-op would require an src of 0x8000, but that's a negative number so you'll end up multiplying by -1 instead of 1 [15:58:56 CEST] <Gramner> 0x7fff works, but only if the other value isn't too large [15:59:06 CEST] <ubitux> Daemon404: ea9317b8 fixes fate-sub-cc btw [15:59:12 CEST] <kierank> Gramner: I think that's what x264 v210 does [15:59:15 CEST] <Gramner> 0x2000 is probably the limit actually [15:59:54 CEST] <Gramner> yes. x264 also does this fun thing where I merged the vpermd indices in the pmulhrsw mask, because it's evil and why not [16:00:25 CEST] <Gramner> thing about the cache savings! [16:01:03 CEST] <kierank> we don't have avx2 yet [16:01:07 CEST] <kierank> lane problems [16:01:28 CEST] <kierank> but I guess we should add it later [16:03:06 CEST] <Gramner> dug up my pmulhrsw notes. 0x7fff is equal to *1 iff the input is 0x4000 or less [16:05:35 CEST] <Gramner> note that I think using pmulhrsw for variable right-shift requires the msb of the bits to be shifted out to be zero [16:05:57 CEST] <Gramner> unless you want rounding [16:09:58 CEST] <kierank> we can move our mask to before the shuffle though to avoid that [16:14:31 CEST] <j-b> 'morning [16:16:26 CEST] <durandal_170> good afternoon [16:17:22 CEST] <wm4> Daemon404, nevcairiel: I think the h264-conformance failures are only due to timestamp crap in ffmpeg.c? both decode the same number of frames with the same contents, so I don't see how it has to do with has_b_frames [16:17:33 CEST] <wm4> but the way how ffmpeg.c does timestamps is a mystery to me [16:18:11 CEST] <nevcairiel> dont they change DTS only? that smells like a change in codec delay to me [16:18:36 CEST] <nevcairiel> in any case, that property s hould be exported anyway [16:19:05 CEST] <wm4> well according to ffprobe, those samples don't have timestamps at all [16:19:20 CEST] <wm4> but I remember now that ffmpeg.c actually changes the dts packet timestamps to something made up [16:19:22 CEST] <wm4> (blergh) [16:19:22 CEST] <nevcairiel> they are raw files, of course they dont [16:19:33 CEST] <nevcairiel> but something generated timestamps before [16:19:38 CEST] <nevcairiel> probably from codec timebase [16:20:32 CEST] <nevcairiel> since h264 actually carries some sort of timing information, that can allow you to generate proper pts/dts .. if that information is present [16:28:14 CEST] <Daemon404> ubitux, \o/ [16:28:28 CEST] <Daemon404> wm4, i fixed one thing with raw h264 timestamps already [16:28:30 CEST] <ubitux> Daemon404: so basically it doesn't need my commits [16:28:30 CEST] <Daemon404> it was in rawdec [16:28:49 CEST] <ubitux> Daemon404: because we can now use avctx->time_base... [16:29:03 CEST] <Daemon404> ubitux, update codecpar branch as necessary pls [16:29:21 CEST] <ubitux> well, as i said, it doesn't need to [16:29:26 CEST] <ubitux> your commit fixes it [16:29:28 CEST] <Daemon404> nevcairiel, yes but i addressed this in the other fix to rawdec [16:29:32 CEST] <Daemon404> ubitux, ok [16:31:03 CEST] <Daemon404> ubitux, ea9317b8 should be cherry picked? [16:31:24 CEST] <ubitux> ea9317b8 is in codecpar, it's your commit [16:31:31 CEST] <Daemon404> >hashes [16:31:55 CEST] <Daemon404> O_o [16:32:00 CEST] <Daemon404> updating a different fate test fixes it? [16:32:11 CEST] <ubitux> well you are setting avctx->time_base [16:32:20 CEST] <ubitux> so now the timing computation works again :p [16:32:27 CEST] <Daemon404> oh... wtf github [16:32:31 CEST] <Daemon404> was looking at wrong one [16:33:12 CEST] <ubitux> i don't understand the commented av_codec_set_pkt_timebase in that commit though [16:33:25 CEST] <Daemon404> i fixed that in the next one [16:33:29 CEST] <Daemon404> it was accidental debug comments [16:33:57 CEST] <ubitux> ah, missed that [16:36:23 CEST] <Daemon404> wm4, what exactly changes in teh h264 conformance tests? [16:36:35 CEST] <Daemon404> i fixed it gettign no timestamps, iirc [16:37:07 CEST] <wm4> Daemon404: timestamps increase in steps of 2 instead of 1 [16:37:22 CEST] <Daemon404> but same timebase? [16:40:04 CEST] <wm4> AFAIR yes [16:40:39 CEST] <Daemon404> ic [16:45:43 CEST] <Daemon404> wm4, [framecrc @ 0x3906900] Encoder did not produce proper pts, making some up. [16:45:47 CEST] <Daemon404> did you see this [16:45:54 CEST] <Daemon404> or is tha texpected [16:46:29 CEST] <Daemon404> nope looks like it is [16:46:32 CEST] <wm4> yes I see this too [16:46:36 CEST] <wm4> on the pmp test too [16:46:39 CEST] <wm4> whatever the fuck it means [16:47:24 CEST] <Daemon404> //XXX/FIXME this is a temporary hack until all encoders output pts [16:47:26 CEST] <Daemon404> nice [16:47:36 CEST] <wm4> how many years? [16:47:52 CEST] <nevcairiel> encoders generally do [16:47:59 CEST] <Daemon404> too lazy to look [16:48:09 CEST] <Daemon404> i need to trol through refactorings [16:48:25 CEST] <nevcairiel> the problem starts when you use rawvideo which just copies input timestamps, which have no guarantees =p [16:49:43 CEST] <Daemon404> pkt->pts = st->priv_pts->val; [16:49:48 CEST] <Daemon404> ok so its likely from init_pts [16:49:59 CEST] <Daemon404> which had that weird thing [16:50:54 CEST] <Daemon404> i have an idea [16:51:54 CEST] <Daemon404> fixed it. [16:52:03 CEST] <Daemon404> just runnign fate [16:52:14 CEST] <Daemon404> ah... only most were fixed [16:56:08 CEST] <Daemon404> hmmmm [16:56:14 CEST] <Daemon404> so one of teh h264 tests fails with hash changes [16:56:14 CEST] <Daemon404> wtf [16:56:48 CEST] <kierank> Gramner: is there an algorithm for generating the shifts with PMULHRSW [16:57:04 CEST] <Daemon404> wm4, fix pushed for most of the h264 tests [16:58:00 CEST] <Daemon404> pmp still is iffy too [16:58:02 CEST] <wm4> apparently you understand this code [16:58:24 CEST] <Daemon404> wm4, yeah but the next h264 failures arent timestamps [16:58:37 CEST] <kierank> Gramner: ah it uses the lowest bit [16:58:46 CEST] <kierank> ignores the lowest bit [16:59:01 CEST] <wm4> is multiplying these time bases a cheap way to get a common denominator or so? [17:00:27 CEST] <Daemon404> it seems like its just a hack to try and find a "good" value to increment by and start at [17:00:53 CEST] <Daemon404> nothing is particularily correct in the old or new one. [17:02:16 CEST] <Daemon404> -0, 1, 1, 1, 38016, 0xb6261cdd [17:02:16 CEST] <Daemon404> +0, 1, 1, 1, 38016, 0xfcd6aec1 [17:02:21 CEST] <Daemon404> this sort of stfuf is disturbing [17:02:33 CEST] <Daemon404> (on e.g. fate-h264-conformance-caba3_sony_c) [17:03:58 CEST] <Daemon404> [h264 @ 0x2d4d1a0] Increasing reorder buffer to 1 [17:03:58 CEST] <Daemon404> [h264 @ 0x2d4d1a0] Increasing reorder buffer to 2 [17:04:03 CEST] <Daemon404> ok .... has_b_frames [17:04:05 CEST] <Daemon404> ? [17:04:06 CEST] <Daemon404> maybe? [17:04:07 CEST] <wm4> yeah [17:04:12 CEST] <wm4> sounds like it [17:04:56 CEST] <Daemon404> that warning is in avcodec... [17:06:08 CEST] <Gramner> kierank: 0x8000 >> shift_amount is the value to use as the pmulhrsw multiplier [17:06:26 CEST] <Gramner> (with the exeption for shift==0) [17:06:30 CEST] <kierank> ah except for 0 [17:06:54 CEST] <nevcairiel> Daemon404: of course because the h264 decoder is in avcodec [17:07:46 CEST] <Daemon404> yeah [17:07:52 CEST] <Daemon404> but im wondering where it would be set in avf [17:08:02 CEST] <Daemon404> that it no longer is and/or is set differently [17:08:49 CEST] <nevcairiel> if the decoded hashes change, its likely just avcodec missing the has_b_frames flag and discarding a few frames [17:09:37 CEST] <Daemon404> yes thats what it looks lile in the avcodec code [17:09:42 CEST] <wm4> nevcairiel: so basically you're saying the flv demuxer is broken in Libav? [17:11:03 CEST] <Daemon404> found it i think [17:11:45 CEST] <nevcairiel> wm4: to some degree of broken, it probably still plays, but may lack metadata it had before [17:12:31 CEST] <Daemon404> maybe not [17:16:45 CEST] Action: Daemon404 isnt quite sure where to fix this [17:16:54 CEST] <Daemon404> i only see it set in one place, and changing it doesn help [17:17:14 CEST] <fritsch> who is in charge of the neon sws_scale intrinsics? [17:17:26 CEST] <Daemon404> in fact regexing teh entirety of lavf to use codec->has_b_frames seems to not work?! [17:17:39 CEST] <wm4> Daemon404: lol [17:17:51 CEST] <wm4> so did we add it as codecpar field yet or not? [17:17:55 CEST] <wm4> it seems like we really need it [17:18:04 CEST] <Daemon404> well add one for delay or something [17:18:11 CEST] <Daemon404> but id like to figure this out first [17:18:15 CEST] <nevcairiel> we kinda agreeed to do it, with a more generically useful name, but didnt do it yet [17:18:42 CEST] <Daemon404> fix stuff first to even work [17:18:44 CEST] <Daemon404> then worry about that [17:19:10 CEST] <nevcairiel> if it doesnt work because it lacks this property, then wouldnt the fix be to send it over? [17:20:05 CEST] <Daemon404> nevcairiel, [16:17] <@Daemon404> in fact regexing teh entirety of lavf to use codec->has_b_frames seems to not work?! [17:20:21 CEST] <nevcairiel> maybe you should just use has_b_frames [17:20:25 CEST] <nevcairiel> and buy a new regex tool [17:20:46 CEST] <Daemon404> [16:20] <@nevcairiel> maybe you should just use has_b_frames <-- ? [17:21:08 CEST] <nevcairiel> if codec->has_b_frames doesnt work, then make the string smaller =p [17:21:19 CEST] <Daemon404> heh [17:21:32 CEST] <Daemon404> im not sure it will work... [17:21:46 CEST] <Daemon404> hmm... [17:21:51 CEST] <Daemon404> did any of teh copy_proprs things change [17:21:52 CEST] <Daemon404> or stuff [17:22:09 CEST] <Daemon404> or some call to copy props [17:22:56 CEST] <nevcairiel> there is plenty codec->has_b_frames things in avformat btw [17:23:00 CEST] <nevcairiel> your regex must be invalid [17:26:19 CEST] <Daemon404> i diffed against pre-merge not [17:26:30 CEST] <Daemon404> and no uses of has_b_frames have changed after my regex [17:26:33 CEST] <Daemon404> now* [17:26:36 CEST] <Daemon404> so it caght them all. [17:27:59 CEST] <wm4> maybe it's somehow overwritten when copying the codecpar? [17:28:36 CEST] <Daemon404> maybe [17:29:00 CEST] <nevcairiel> where do you think has_b_frames is going to be set [17:29:25 CEST] <Daemon404> i really dont know [17:29:36 CEST] <Daemon404> it has to be moved from teh stream context to the decode context at some point [17:30:17 CEST] <nevcairiel> its deteremined by the decoder in find_stream_info, which used to just decode straight into the st->codec context [17:30:19 CEST] <nevcairiel> but no longer [17:30:21 CEST] <nevcairiel> so its no longer set [17:31:15 CEST] <Daemon404> in fact [17:31:16 CEST] <Daemon404> has_b_frames=1 [17:31:23 CEST] <Daemon404> from ffprobe on the stream [17:31:29 CEST] <Daemon404> (after my regex) [17:31:31 CEST] <Daemon404> and it still fails. [17:31:36 CEST] <Daemon404> so i dont think you are right about what is going on [17:31:59 CEST] <nevcairiel> i have no clue what you are on about with the regex anyway [17:32:41 CEST] <nevcairiel> regexes are no solutions =p [17:32:48 CEST] <Daemon404> its a test [17:36:48 CEST] <Daemon404> nevcairiel, both hard setting has_b_frames before deocding, and also trying to use the stream context directly for find_stream_info do not fix anything. [17:37:58 CEST] <Daemon404> oh what... TIL [17:38:04 CEST] <Daemon404> has_b_frames can be *2*? [17:38:14 CEST] <nevcairiel> it is the number of b frames [17:38:21 CEST] <nevcairiel> not just 1 [17:38:29 CEST] <nevcairiel> but the amount of b-frame delay [17:38:41 CEST] <nevcairiel> it can be up to 16 on h264 [17:38:51 CEST] <nevcairiel> or maybe 15 [17:38:54 CEST] <nevcairiel> i forget how it works [17:39:46 CEST] <Daemon404> fffffff [17:39:50 CEST] <Daemon404> so even the name is a lie [17:39:56 CEST] <Daemon404> *HAS* [17:40:09 CEST] <wm4> lol [17:43:43 CEST] <Daemon404> i think i finally grok this... [17:44:22 CEST] <Daemon404> mmm nope. [17:45:59 CEST] <michaelni> yes, the name has_b_frames is complete nonsense [17:46:08 CEST] <michaelni> its just the delay [17:46:20 CEST] <michaelni> has_b_frames = 1 does not gurantee that there are b frames [17:47:30 CEST] <Daemon404> michaelni, yeah i get that now [17:55:30 CEST] <Daemon404> i wonder if ok i managed to fix the test with a hack, but i guess i need to do it properly [17:55:57 CEST] <Daemon404> s/i wonder if // [17:56:14 CEST] <nevcairiel> the tests would probably start working if you jus set st->codec->has_b_frames = st->internal->avctx->has_b_frames [17:56:27 CEST] <nevcairiel> but it should be exported if its needed [17:57:05 CEST] <Daemon404> nevcairiel, i added this at the end of try_decode_frame: [17:57:05 CEST] <Daemon404> + st->codec->has_b_frames = avctx->has_b_frames; [17:57:11 CEST] <Daemon404> hack, but it 'works' [17:57:27 CEST] <Daemon404> proper fix is to add a codecpar field i suppose [17:57:37 CEST] <nevcairiel> indeed [17:58:25 CEST] <Daemon404> also, try_decode_frame does *not* use the internal avctx [17:58:28 CEST] <Daemon404> but a new one [17:58:51 CEST] <Daemon404> which i suppose could conflict with the internal one [17:59:02 CEST] <Daemon404> it should perhaps use the internal one? [17:59:10 CEST] <Daemon404> and then has_b_frames is copied over properly at the end? [17:59:19 CEST] <nevcairiel> Daemon404: from try_decode_frame, AVCodecContext *avctx = st->internal->avctx; ? [17:59:27 CEST] <Daemon404> oh [17:59:30 CEST] <Daemon404> reading is hard mmkay [18:00:44 CEST] <Daemon404> st->codec->has_b_frames should still be set under deprecation guards too. [18:01:03 CEST] <nevcairiel> if you make codecpar include that, then this will handle that automatically [18:01:10 CEST] <Daemon404> ah [18:03:50 CEST] <Daemon404> nevcairiel, idea for name? [18:03:54 CEST] <Daemon404> michaelni, ^ [18:04:54 CEST] <ubitux> maybe_b_frames [18:05:03 CEST] <wm4> delay? [18:05:17 CEST] <Daemon404> wm4, i currently have it as video_delay [18:05:22 CEST] <wm4> also fine [18:05:37 CEST] <wm4> note that some fields are used for both audi and video, with different meaning [18:05:43 CEST] <wm4> ("format" at least) [18:05:52 CEST] <Daemon404> i dont intend to reuse a field [18:05:59 CEST] <Daemon404> thats asking for trouble later on [18:06:04 CEST] <wm4> ok I agree [18:06:51 CEST] <Daemon404> shouldnt be that hard.... [18:11:06 CEST] <Daemon404> wooo [18:11:12 CEST] <Daemon404> fate-h264 passes with a codecpar field [18:18:40 CEST] <BBB> passing 'uint8_t *[8]' to parameter of type 'const uint8_t **' (aka 'const unsigned char **') discards qualifiers in nested pointer types [-Wincompatible-pointer-types-discards-qualifiers] [18:18:43 CEST] <BBB> what does that mean? [18:19:11 CEST] <nevcairiel> that C const-ness is broken [18:19:21 CEST] <wm4> yep [18:20:47 CEST] <BBB> and why is AVFrame->linesize still int[] instead of ptrdiff_t[]? [18:21:10 CEST] <nevcairiel> because api change is hard and linesizes over 32-bit seem uncommon? [18:23:00 CEST] <wm4> one argument is that them being int is likely to break a lot of code which does "int h; h*linesize..." [18:23:16 CEST] <wm4> which is also why image sizes are restricted to ~16000x16000 [18:23:19 CEST] <BBB> x86-64 simd tends to use linesizes [18:23:25 CEST] <BBB> and we need to sign-extend them [18:23:41 CEST] <BBB> right now we cant use frame->linesize directly as input to the simd function (the array, not the value) [18:23:51 CEST] <BBB> or, well, the simd would have to sign-extend [18:23:53 CEST] <BBB> which is slightly annoying [18:26:08 CEST] <Daemon404> runnign a full make fate on codecpar now;... [18:26:11 CEST] <Daemon404> fingers crossed. [18:31:34 CEST] <Daemon404> fate with -O0 = slow [18:34:33 CEST] <wm4> was the pmp-demux thing fixed? [18:35:56 CEST] <Daemon404> not yet no [18:36:03 CEST] <Daemon404> im running with GEN=1 to see what is left to fix [18:37:59 CEST] <jamrial> i thought you couldn't compile ffmpeg with -O0 because of dce [18:38:25 CEST] <Daemon404> depends on the compiler and version. [18:43:36 CEST] <Daemon404> wm4, updated etherpad [18:43:45 CEST] <Daemon404> most look related to priv_pts insanity [18:44:25 CEST] <Daemon404> except vp6 and wmv [18:44:27 CEST] <Daemon404> er xmv [18:44:32 CEST] <wm4> so those fate tests like pmp-demux still fail? [18:45:05 CEST] <Daemon404> no... only some [18:45:35 CEST] <Daemon404> i never did figure out how pmp demux timestamos came to be [18:45:42 CEST] <Daemon404> -#extradata 0: 4, 0x015a00ad [18:45:46 CEST] <Daemon404> and tehre's this from xmv [18:46:26 CEST] <wm4> short look suggests it might change extradata later [18:46:31 CEST] <wm4> so it doesn't get copied [18:46:55 CEST] <Daemon404> sigh [18:49:15 CEST] <wm4> don't we have side data to update extradata? [19:11:36 CEST] <BBB> wm4: yes [19:15:15 CEST] <fritsch> https://github.com/FFmpeg/FFmpeg/blob/release/3.0/libswscale/arm/yuv2rgb_ne… <- how to force this part of the code on the commandline? [19:15:22 CEST] <fritsch> argh, sorry - was for user's channel [19:23:08 CEST] <Daemon404> i STILL cannot find where dts is set for rawdec stuff [19:36:38 CEST] <wm4> Daemon404: it sets it on the packet [19:37:09 CEST] <Daemon404> where [19:37:14 CEST] <wm4> looking [19:37:22 CEST] <wm4> decode_video [19:37:26 CEST] <wm4> pkt->dts = av_rescale_q(ist->dts, AV_TIME_BASE_Q, ist->st->time_base); [19:37:40 CEST] <wm4> PS: this is insane, and I had my own fun with it, and avconv doesn't do this [19:37:51 CEST] <wm4> or maybe this is not what you're looking for? [19:37:56 CEST] <Daemon404> no [19:38:10 CEST] <Daemon404> im slowly tracing this hevc failure [19:38:32 CEST] <Daemon404> all but the last few frames properly have NOTS set as the val [19:39:19 CEST] <wm4> hahaha [19:39:43 CEST] <wm4> that's probably when ffmpeg.c sets dts on a flush packet? [19:39:53 CEST] <Daemon404> no [19:39:55 CEST] <Daemon404> its in utils.c [19:39:57 CEST] <wm4> and if the codec delay is "wrong" it won't work [19:40:04 CEST] <wm4> hm [19:40:06 CEST] <Daemon404> im checking values returned by av_read_frame [19:40:11 CEST] <Daemon404> unless ffmpeg.c is to blame [19:40:13 CEST] <Daemon404> and im wrong [19:41:41 CEST] <Daemon404> or hkmmm [19:41:41 CEST] <wm4> so it's libavformat timestamp-making-up-code? [19:41:52 CEST] <Daemon404> nope [19:41:53 CEST] <Daemon404> i was wrong [19:42:00 CEST] <Daemon404> NOTS si set properly on the flush packets [19:42:13 CEST] <Daemon404> so dts is done in ffmpeg.c... ? [19:51:17 CEST] <Daemon404> solved it [19:51:18 CEST] <Daemon404> D: [19:53:27 CEST] <nevcairiel> Daemon404: btw they updated clang/c2 today [19:54:17 CEST] <Daemon404> oh? [19:56:17 CEST] <nevcairiel> as part of 2015u2 [19:56:30 CEST] <Daemon404> ah [19:56:54 CEST] <Daemon404> woo fixed hevc [19:58:26 CEST] <wm4> nevcairiel: is it usable yet? [19:58:37 CEST] <nevcairiel> who knows [19:58:40 CEST] <nevcairiel> +will have to find out [20:01:15 CEST] <Daemon404> only 3 fate failures left [20:01:35 CEST] <JEEB> nice [20:04:08 CEST] <Daemon404> wm4, i havent been following the big githbu comment threads. is it possible to fix wmv and pals? [20:05:22 CEST] <ubitux> fritsch: it's triggered by default,-f lavfi -i testsrc2,format=yuv420p,format=rgba should do it [20:05:59 CEST] <Daemon404> ok so vp6 is [flv @ 0x2dd9900] video stream discovered after head already parsed [20:06:21 CEST] <nevcairiel> that warning is "normal" now [20:06:26 CEST] <nevcairiel> should be disabled probably [20:06:34 CEST] <Daemon404> i see [20:06:39 CEST] <Daemon404> but the test is still failing [20:07:02 CEST] <Daemon404> packet size is wrong (wtf?) [20:07:21 CEST] <Daemon404> -0, 0, 0, 1, 81000, 0xcb92962d [20:07:21 CEST] <Daemon404> +0, 0, 0, 1, 135000, 0xc6c0bf8b [20:07:31 CEST] <Daemon404> and so forth [20:07:37 CEST] <Daemon404> and xmv failure is extradata. [20:10:42 CEST] <ubitux> fritsch: there are a bunch of patches pending for that code btw [20:11:08 CEST] <ubitux> (including zomg speed) [20:11:24 CEST] <Daemon404> ok i solved pmp [20:11:35 CEST] <Daemon404> so just the flv / extradtaa stuff left [20:13:15 CEST] <Daemon404> wm4, ^ [20:18:45 CEST] <nevcairiel> also, MS ships a bash shell and various tools now, w onder if that can run configure ... and maybe faster? [20:19:30 CEST] <Plorkyeran> no inherent reason it shouldn't be able to [20:19:41 CEST] <Plorkyeran> might be quirks that need to be dealt with [20:20:09 CEST] <Plorkyeran> I wouldn't really expect it to be faster unless the slowness is actually win32-specific [20:20:24 CEST] <Plorkyeran> (as opposed to an NT thing) [20:21:47 CEST] <Daemon404> slowness is win32 specific (forks) [20:21:57 CEST] <Daemon404> unless you mean something else [20:22:26 CEST] <Plorkyeran> well it's probably a separate subsystem [20:22:30 CEST] <Plorkyeran> since it runs native elf binaries [20:22:49 CEST] <Plorkyeran> so it might have better fork performance [20:23:22 CEST] <Daemon404> runs elf O_o [20:23:37 CEST] <nevcairiel> runs native ubuntu usermode binaries [20:24:28 CEST] <BtbN> The NT kernel has a native (but undocumented) fork call since quite a while, and cygwin uses that to "emulate" fork. [20:24:47 CEST] <TD-Linux> BtbN, I don't think they actually use that last I checked [20:26:20 CEST] <nevcairiel> its a OS feature in the upcoming win10 version though, not something that comes through VS for earlier OSes [20:27:33 CEST] <BtbN> RtlCloneUserProcess isn't new. [20:28:26 CEST] <nevcairiel> noone is talking about that but you =P [20:28:40 CEST] <nevcairiel> it runs native ELF binaries [20:28:50 CEST] <nevcairiel> not some cross-compiled things [20:31:35 CEST] <Daemon404> nevcairiel / wm4, will you be attempting to tackle the xmv/flv stuff? [20:31:40 CEST] <Daemon404> or am i stuck poking it [20:33:41 CEST] <nevcairiel> i can try later [20:34:06 CEST] <Daemon404> all right [20:34:17 CEST] <Daemon404> i spent too much time looking at insane timstamp code today [20:34:21 CEST] <Daemon404> my brain is mush [20:35:35 CEST] <wm4> I don't think I have any time for this [20:38:49 CEST] <Daemon404> well someone's gonna have to, and i still dont fully grok the problem. [20:42:31 CEST] <Daemon404> nevcairiel, in the meantime i am going to start converting some has_b_frame code + missed stuff in lavf to codecpar, since i can actually run fate now [20:43:19 CEST] <Daemon404> unless you think that should wait on this. [21:02:05 CEST] <fritsch> ubitux: it crashes hard if it copes with a non aligned memory adress [21:20:37 CEST] <wm4> it's not really clear if passing unaligned pointers to libswscale is supposed to work or not [21:21:17 CEST] <Daemon404> if (!decode && codec_ctx->codec->caps_internal & FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM) { [21:21:24 CEST] <Daemon404> why do we have a unit test for teh api with this [21:21:33 CEST] <Daemon404> D: [21:21:54 CEST] <Daemon404> is Matthieu Bouron on irc [21:22:33 CEST] <wm4> Daemon404: to avoid decoding pngs and jpgs in lavf [21:22:40 CEST] <JEEB> I think it's mateo`_ [21:22:41 CEST] <Daemon404> thats nice [21:22:45 CEST] <Daemon404> but it's hella illegal [21:22:48 CEST] <Daemon404> youre accessign internal structs [21:22:59 CEST] <wm4> lol patch reviews [21:23:03 CEST] <wm4> that thread was long [21:23:09 CEST] <wm4> and nobody spotted it? (including myself) [21:25:06 CEST] <Daemon404> ill look at it later... [21:25:23 CEST] <Daemon404> did a bunch of conversions now.... im beat... put a ton of work into tep2 the past few days. [21:25:37 CEST] Action: Daemon404 will stop and wait for nevcairiel or wm4 to figure out flv [21:26:03 CEST] <wm4> does flv still make any fate test fail? [21:26:14 CEST] <wm4> or is it not covered [21:26:36 CEST] <Daemon404> vp6 [21:26:40 CEST] <Daemon404> some alpha thing [21:26:46 CEST] <Daemon404> skipalpha [21:26:55 CEST] <wm4> exact name of the test? [21:27:06 CEST] <Daemon404> vp6a-skip_alpha [21:27:13 CEST] <Daemon404> that, and wmv, are the only two failing tests. [21:27:16 CEST] <wm4> ah yeah it's actually on the etherpad [21:27:22 CEST] <Daemon404> we xmv* [21:27:24 CEST] <Daemon404> er* [21:28:59 CEST] <Daemon404> i think ive toiled away on my own in insaity enough for now. im sure you all can find some time in the next few days. [21:29:02 CEST] Action: Daemon404 cracks a beer [21:40:34 CEST] <wm4> I totally love how a "broken" codecpar build actually outputs alpha, while ffmpeg 2.8 doesn't [21:40:37 CEST] <wm4> for this sample [21:41:00 CEST] <Daemon404> the point of this sample is to skip alpha [21:41:08 CEST] <Daemon404> it's a feature (git log on the fate ref( [21:41:10 CEST] <wm4> aha [21:42:09 CEST] <wm4> "useful" [21:43:19 CEST] <BBB> hm, so I think my colorspace filter works now [21:44:02 CEST] <BBB> it has 8/10/12bpp yuv420/422/444 support and supports both a fast (incorrect) colormatrix-style conversion as well as a slow (correct) one that includes primary/gamma correction [21:44:10 CEST] <rcombs> anyone have any objection to my auto-bsf segment patch? [21:45:47 CEST] <BBB> rcombs: looks rather straightforward [21:46:18 CEST] <BBB> its a little hacky/one-off but I dont see why thats a problem for now [21:48:04 CEST] <wm4> Daemon404: that just means the sample _should_ have alpha [21:49:15 CEST] <wm4> ah nevermind it's just me being dumb [21:49:26 CEST] <wm4> so, just -skip_alpha is broken [21:49:44 CEST] <Daemon404> theres a prores skip alpha test too [21:49:46 CEST] <Daemon404> but it doesnt fail [21:49:52 CEST] <Daemon404> my bet is still on flv [21:50:49 CEST] <baptiste> rcombs, auto bsf is nice, wanted that for years [21:51:14 CEST] <rcombs> baptiste: I implemented it a while back and it's in master; this patch is just for handling it in the segment muxer [21:53:27 CEST] <baptiste> make sense :> [22:01:22 CEST] <durandal_170> BBB: how much to pay for source? [22:01:42 CEST] <BBB> huh? [22:03:13 CEST] <BBB> what do you mean exactly? [22:23:06 CEST] <durandal_170> BBB: colormatrix filter [22:25:30 CEST] <BBB> why would I need colormatrix filter source? [22:26:52 CEST] <durandal_170> I meant to replace current gpl version [22:27:40 CEST] <BBB> I already finished it [22:28:03 CEST] <BBB> if you want to delete colormatrix, just delete it [22:30:24 CEST] <durandal_170> I want to replace it [22:30:42 CEST] <BBB> so wait a few minutes for me to send the patch [22:30:45 CEST] <BBB> then approve it [22:30:49 CEST] <BBB> delete colormatrix yourself [22:30:50 CEST] <BBB> and youre done [22:32:04 CEST] <durandal_170> you picked different name? [22:32:22 CEST] <BBB> yes [22:32:58 CEST] <BBB> it works slightly different, I dont care about compatibility or whatever, so I just used a different name [22:33:01 CEST] <BBB> much easier [22:35:28 CEST] <BBB> there you go [22:36:26 CEST] <BBB> so, things to note: no simd yet (lets get base filter in first), and the gamma correction is lut-based. I have an integer version (dont ask) that may be faster but Ill need to revive it from some very old archive and port it over [22:37:57 CEST] <wm4> Daemon404: the failure is caused by -skip_alpha not being propagated somewhere [22:40:27 CEST] <Daemon404> that seems like an odd breakage [22:40:48 CEST] <wm4> or maybe it just looks like that who knows [22:41:02 CEST] <wm4> is there a way to direct an option to a decoder instead of lavf? [22:43:48 CEST] <wm4> adding this to decode_frame() gives a better result: av_dict_set(options ? options : &thread_opt, "skip_alpha", "1", 0); [22:45:14 CEST] <Daemon404> hmm youre right, it seems its not being propgated [22:48:56 CEST] <wm4> another difference is that the codecpar pixelformat is apparently different in both cases [22:49:01 CEST] <wm4> (alpha vs. not alpha) [22:49:09 CEST] <wm4> why didn't ffprobe -show_streams show this [22:49:16 CEST] <Daemon404> yes which it gets from find_stream_info [22:49:20 CEST] <Daemon404> thats what im looking at right now [22:49:25 CEST] <nevcairiel> ffmpeg.c probably sets the option on st->codec, somehow? [22:50:32 CEST] <wm4> oh wait does ffmpeg.c still use st->codec for decoding? [22:50:54 CEST] <Daemon404> i didnt think it did [22:51:12 CEST] <Daemon404> the problem i think is that the pix fmt is set in find_stream_info [22:51:21 CEST] <Daemon404> and the vp6 code checks teh pixfmt [22:51:35 CEST] <wm4> oh ok [22:51:43 CEST] <Daemon404> i think it may not be propogated to that? [22:51:45 CEST] <wm4> yes I think ffmpeg.c creates a separate context [22:52:01 CEST] <Daemon404> i dont know how to dump an avdict to printf debug [22:52:02 CEST] <Daemon404> :V [22:52:09 CEST] <Daemon404> (in try_decode_frame) [22:52:32 CEST] <wm4> so skip_alpha is probably not set on the ffmpeg.c decoder context, but if codecpar pixfmt is non-alpha, it won't decode alphas [22:52:47 CEST] <wm4> so the question is where the heck does the skip_alpha option get "consumed" [22:53:06 CEST] <wm4> it doesn't go to ffmpeg.c's decoder, it doesn't go to lavf's internal decoder either? [22:53:11 CEST] <wm4> maybe I'm just crazy [22:53:51 CEST] <Daemon404> i think the problem is that its not set on the decoder in find_stream_info [22:54:38 CEST] <wm4> if skip_alpha were set on the ffmpeg.c decoder context, the test would probably succeed [22:55:23 CEST] <Daemon404> did you test this [22:55:39 CEST] <wm4> let me [22:56:36 CEST] <Daemon404> hmm nope you dont have to [22:56:43 CEST] <Daemon404> i set it manually in try_decode_frame, and it fixes it [22:56:49 CEST] <Daemon404> so it isnt getting propogated there. [22:56:53 CEST] <wm4> I did that too [22:57:04 CEST] <wm4> I'm wondering about ffmpeg.c's [22:57:19 CEST] <Daemon404> the decode does get the flag [22:57:23 CEST] <Daemon404> otherwise the prores test would fail [22:57:48 CEST] <wm4> huh, still fails if I set it in ffmpeg.c [22:58:08 CEST] <Daemon404> ffmpeg.c makes no diff [22:58:13 CEST] <Daemon404> you only have to set it in try_decode_frame [22:58:41 CEST] <wm4> I know, but the test basically fails because the decoder outputs alpha, so setting skip_alpha on ffmpeg.c's decoder should fix it [22:59:21 CEST] <Daemon404> /* Set AVCodecContext options for avformat_find_stream_info */ [22:59:23 CEST] <Daemon404> looks related [22:59:59 CEST] <wm4> (fuck ffmpeg.c option handling) [23:01:16 CEST] <wm4> could it depend on whether the streams exist before or after find_stream_info? [23:01:52 CEST] <Daemon404> yes [23:02:06 CEST] <Daemon404> because during find_stream_info is when it sets the pix_fmt... i think [23:02:25 CEST] <wm4> I was thinking about how skip_alpha gets consumed [23:02:36 CEST] <BBB> michaelni: your framehash change doesnt register size changes [23:02:42 CEST] <wm4> it works for the prores test, which uses a mov container and not flv [23:02:54 CEST] <wm4> while flv was changed to add streams at a later point (during findf_stream_info) [23:02:58 CEST] <BBB> michaelni: e.g. look at vp8-size-change [23:03:10 CEST] <Daemon404> wm4, i see [23:04:11 CEST] <wm4> so we should change the test to set the option correctly [23:04:16 CEST] <wm4> but I have no clue how that works [23:04:39 CEST] <Daemon404> i think it is setting it correctly? i dont know. [23:04:39 CEST] <nevcairiel> not sure you can really set options to the decoder used in find_stream_info [23:05:02 CEST] <wm4> I mean the API allows it [23:05:25 CEST] <wm4> and setup_find_stream_info_opts somehow uses it [23:07:30 CEST] <michaelni> BBB, didnt think about that, will fix it [23:07:39 CEST] <wm4> if I set the option there it doesn't work (wut) [23:07:41 CEST] <BBB> ty [23:10:48 CEST] <wm4> well maybe I'll try some more tomorrow [23:11:33 CEST] <cone-330> ffmpeg 03Michael Niedermayer 07master:a35a4a5774a1: fate: Add filter-metadata-cropdetect [23:19:40 CEST] <Daemon404> wm4, i think the option cant be applied because the stream hasnt been found before calling find_stream_info [23:20:07 CEST] <wm4> oh right [23:20:11 CEST] <wm4> no way to pass it [23:20:21 CEST] <Daemon404> yea [23:20:55 CEST] <wm4> I still don't get why it doesn't work when setting the option on the decoder [23:22:04 CEST] <wm4> or why the option gets "lost" [23:23:54 CEST] <Daemon404> wm4, the decoder does see it [23:24:07 CEST] <Daemon404> when it is init'd for the actual decoding (not in find_stream_info) [23:24:12 CEST] <Daemon404> the option is correctly set there [23:24:26 CEST] <wm4> also I see "Input stream #0:0 frame changed from size:300x180 fmt:yuva420p to size:300x180 fmt:yuv420p" [23:24:52 CEST] <Daemon404> yes thats why [23:25:06 CEST] <Daemon404> since it changed between init and decode [23:25:20 CEST] <wm4> ooh [23:25:35 CEST] <wm4> and rawenc is fixed to yuva? [23:25:47 CEST] <Daemon404> possible [23:25:55 CEST] <wm4> well uh that sucks [23:26:50 CEST] <wm4> [scaler for output stream 0:0 @ 0x93f200] w:300 h:180 fmt:yuv420p sar:0/1 -> w:300 h:180 fmt:yuva420p sar:0/1 flags:0x4 [23:27:10 CEST] <Daemon404> if i force the pix_fmt it works [23:27:29 CEST] <Daemon404> so it seems to happen due to initing with yuva and selectign the raw output colorspace based on that [23:27:44 CEST] <wm4> but shouldn't the decoder set the right pixfmt during opening, or is that too late too [23:28:25 CEST] <Daemon404> i think ffmpeg.c sets it all up before opening [23:28:29 CEST] <Daemon404> i could be wrong [23:28:36 CEST] <wm4> sigh [23:29:18 CEST] <Daemon404> its not wrong to do so [23:29:22 CEST] <wm4> it is [23:29:27 CEST] <Daemon404> youd think the info you get from find_stream_info is correct [23:29:37 CEST] <Daemon404> for frame 1 at least [23:29:44 CEST] <wm4> yeah, but the pixfmt is one of those things which easily can change from decoder to decoder [23:29:56 CEST] <wm4> or because the parser sets something else etc. [23:30:15 CEST] <Daemon404> maybe nevcairiel has an opinion. [23:31:18 CEST] <wm4> ffmpeg_opt.c line 709 inits it with the lavf pixfmt before opening a decoder, it seems [23:32:40 CEST] <wm4> and forcing the pixfmt on the command line doesn't test what the test is supposed to test [23:34:54 CEST] <wm4> could we remux the sample to some other container? [23:35:06 CEST] <wm4> one that doesn't do delayed adding of AVStreams [23:36:41 CEST] <wm4> vp6a can go into avi and mov and consequently also mkv (jesus christ multimedia is horrible) [23:36:46 CEST] <Daemon404> seems like working around a problem [23:37:07 CEST] <wm4> the problem is that we trigger a ffmpeg.c bug due to slight change in behavior as far as I'm concerned [23:37:37 CEST] <wm4> I also tested with mpv and everything works as expected [23:38:15 CEST] <Daemon404> true. [23:40:04 CEST] <wm4> haha [23:40:14 CEST] <wm4> I remuxed it to mov and adjusted the filename in fate, and it works [23:40:55 CEST] <wm4> both tests which use the file [23:41:15 CEST] <wm4> so we should be able to go with this? [23:41:32 CEST] <Daemon404> i would personally, others may have ~opinions~ [23:41:40 CEST] <nevcairiel> changing the tests are not fixes =p [23:41:55 CEST] <Daemon404> depends if you consider the ffmpeg.c was broken to begin with [23:42:00 CEST] <Daemon404> that* [23:42:13 CEST] <Daemon404> im not sure what a correct fix would be otherwise [23:42:15 CEST] <nevcairiel> where is the option applied anyway? in find_stream_info? [23:42:20 CEST] <BBB> file a bug for the broken file [23:42:23 CEST] <BBB> so it doesnt get lost [23:42:28 CEST] <Daemon404> nevcairiel, the problem is not the option [23:42:29 CEST] <BBB> and then chagne test so it no longer triggers [23:42:45 CEST] <nevcairiel> Daemon404: thats not what i asked :) [23:43:03 CEST] <Daemon404> it used to be applied in find_stream_info and on teh decode context in ffmpeg.c [23:43:08 CEST] <Daemon404> not it is only applied on the latter [23:43:19 CEST] <Daemon404> because it isnt passed to find_stream_info [23:43:24 CEST] <Daemon404> due to tehre being no streams [23:43:26 CEST] <Daemon404> before the call. [23:43:31 CEST] <nevcairiel> so find_stream_info keeps a list of options it couldnt apply, why not re-try to apply it when a new stream shows up? [23:43:59 CEST] <wm4> nevcairiel: because the options are per-stream [23:44:00 CEST] <wm4> shit API [23:44:01 CEST] <Daemon404> i am not sure whether it is find_stream_info of ffmpeg*.c that keeps the list of options for a stream [23:44:05 CEST] <Daemon404> or* [23:44:19 CEST] <wm4> you can't set options on streams which appear during find_steram_info [23:44:20 CEST] <wm4> shit API [23:44:21 CEST] <nevcairiel> so ffmpeg.c just doesnt passs any options? [23:44:29 CEST] <Daemon404> let me check [23:44:33 CEST] <Daemon404> i was pretty sure it passed NULL [23:44:39 CEST] <Daemon404> since it didnt find any streams to apply options to [23:44:48 CEST] <wm4> I'm also pretty sure that effectively happens (and it can't pass any) [23:45:04 CEST] <nevcairiel> right, the API calls for passing an array of dicts that matches the stream size [23:45:18 CEST] <wm4> we could add new API for this [23:45:25 CEST] <wm4> a dict of options to apply to new streams or so [23:45:52 CEST] <nevcairiel> I could fix the trust_metadata option in flv and we just add that to the test [23:46:00 CEST] <nevcairiel> hm wait no that doesnt help [23:46:07 CEST] <nevcairiel> still delayed [23:46:14 CEST] <nevcairiel> since the metadata block isnt part of the header [23:47:05 CEST] <erraunt> Hi. I am wondering how to check which projects from GSoC have been taken? I am wondering if I could do something similar outside of GSoC? I have a university course and probably could also use the code as a basis for my "bachelor thesis". I have some experience in coding in C, last semester I tried to contribute to FreeBSD kernel but I believe I did not do a good job, so I will also welcome [23:47:07 CEST] <erraunt> discouragment if appropriate. [23:47:50 CEST] <Daemon404> nevcairiel, yes im not sure how to handle that [23:48:00 CEST] <nevcairiel> erraunt: You are always free to work on FFmpeg on any project you want, and many of us are happy to help. But note that we cannot pay you like google would in GSoC [23:49:11 CEST] <wm4> erraunt: yeah, the only thing we can't provide is payment (outside of gsoc) [23:49:11 CEST] <erraunt> nevcairiel: of course, I did not mention anything about paying. (taking part in GSoC) [23:49:16 CEST] <nevcairiel> Daemon404: if the test is meant to test vp6a and not flv, then remuxing is probably fine in t his case [23:49:22 CEST] <nevcairiel> erraunt: just making sure :) [23:49:42 CEST] <erraunt> so how can I figure which projects have been taken? [23:49:57 CEST] <wm4> so I vote for remuxing the file to mov, uploading to... whereever the samples are stored, and be done with it [23:50:07 CEST] <Daemon404> nevcairiel, that doesnt really solve the "flv problem" does it? [23:50:12 CEST] <Daemon404> or is it a problem? [23:50:30 CEST] <nevcairiel> Daemon404: its a basic api problem that has always existed, couldnt set it on mpegts either, for example [23:50:32 CEST] <wm4> and yes the tests are in vpx.mak [23:50:44 CEST] <Daemon404> nevcairiel, true good point [23:51:03 CEST] <wm4> ffmpeg.c could just be slightly less dumb, but that's not our job here [23:51:44 CEST] <wm4> any API user who checks the pixfmt after opening will be fine too [23:52:08 CEST] <wm4> (I wonder if the opening call couldn't just be moved in ffmpeg.c?) [23:52:58 CEST] <wm4> erraunt: look around in the wiki, there might be a page about candidates and their progress [23:53:11 CEST] <wm4> erraunt: if everything else fails, mail the mentors [23:53:32 CEST] <Daemon404> wm4, assuming anyone even gives a shit abotu skip alpha. [23:53:33 CEST] <nevcairiel> what status is gsoc in anyway, i think its not quite clear which projects are really assigned, is it [23:53:47 CEST] <nevcairiel> dont think google did that yet [23:54:05 CEST] <wm4> Daemon404: mplayer? [23:54:12 CEST] <Daemon404> lol. [23:54:31 CEST] <Daemon404> anyway... just one fate test left which is xmv. [23:54:40 CEST] <Daemon404> with post-open extradata [23:55:11 CEST] <wm4> nasty [23:55:27 CEST] <nevcairiel> did you fix voc? [23:55:42 CEST] <Daemon404> voc passes, and wm4 made a commit to it [23:55:50 CEST] <Daemon404> so i assume so, nless he says otherwise [23:55:54 CEST] <erraunt> wm4: ok [23:55:55 CEST] <wm4> maybe it's still wrong? [00:00:00 CEST] --- Thu Mar 31 2016

1 0

ffmpeg.log.20160330
by burek 31 Mar '16

31 Mar '16

[01:15:09 CEST] <jackhold> i am trying to make a timelapse from a mix of png and jpg files, first i converted the png filed with mogrify and then i ran the command "ffmpeg -r 20 -i %*.jpg -r 20 -s hd720 vcodec libx264 /indput" but i get this error "mjpeg: unsupported coding type (c8)" and the filed i just converted dosent get added to the .mp4 file... any1 that can give me a hand here?? [01:23:48 CEST] <jackhold> okay just gonner take 1min [01:32:35 CEST] <jackhold> here if the command i use and the output i get from it [01:32:36 CEST] <jackhold> http://pastebin.com/hNmq5aGG [01:35:41 CEST] <llogan> you images change from yuvj422p to yuvj420p. i'm not sure how ffmpeg will handle that. possibly by skipping frames. [01:36:19 CEST] <llogan> change the input -r to -framerate and remove the output -r since with the same value it does nothing [01:37:24 CEST] <llogan> remove -s hd720 because your inputs are already 1280x720. add "-pix_fmt yuv420p" as an output option if you want non-FFmpeg based players to be able to play the output file [01:38:33 CEST] <jackhold> thx llogan im gonner give that a try and see what happens [01:38:38 CEST] <jackhold> :) [01:38:41 CEST] <llogan> change "-i %*.jpg" to: -pattern_type glob -i "*.jpg" [01:45:47 CEST] <jackhold> im still getting the error's after i did those changes [01:46:03 CEST] <ac_slater> Is there a way to tell how much time muxing takes? I guess I want to know how long reading input, encoding, and muxing is taking. Any clues? [01:46:28 CEST] <llogan> jackhold: you may have to find out which image(s) is the culprit [01:49:06 CEST] <jackhold> i allready know :) i converted some pictures from png to jpg and that's the ones that is failing [01:49:51 CEST] <jackhold> there was no error's when i did the converting and i can see them no problem [01:50:26 CEST] <xreal> What's the best way to turn 1080p with 50 fps down to 720p with 25 fps? -vf "scale=1280:-1; fps=fps=50" [01:50:54 CEST] <xreal> or -r 25 -s hd720 ? [01:51:25 CEST] <llogan> jackhold: can ffmpeg decode one of those single jpg images from mogrify correctly? ffmpeg -i input.jpg -f null - [01:53:23 CEST] <ac_slater> xreal: I've used this with success http://superuser.com/a/573753 [01:53:37 CEST] <ac_slater> (for frame skip) [01:54:00 CEST] <ac_slater> -r is for reading the input at a certain rate, which doesn't mean skip frames [01:54:23 CEST] <xreal> ac_slater: thx [01:56:27 CEST] <jackhold> llogan: yep that workes.... [01:58:25 CEST] <llogan> i'll blame the 422 vs 420 difference [02:00:53 CEST] <jackhold> thx for the help im gonner try to find a workaround then thx for the help [02:02:03 CEST] <llogan> you could probably tell mogrify to output the same chroma subsampling values as the other images. or have ffmpeg convert the png [02:03:34 CEST] <xreal> ac_slater: Hmm, this doesn't work with audio, does it? [02:05:18 CEST] <ac_slater> xreal: ah, no sorry [02:05:29 CEST] <ac_slater> well [02:06:00 CEST] <ac_slater> xreal: just half of the video frames are skipped, the length is still the same [02:06:06 CEST] <ac_slater> xreal: meaning, the audio should still be in sync [02:06:19 CEST] <ac_slater> have you tried `-acodec copy` ? [02:06:27 CEST] <xreal> ac_slater: good idea, let me try. [02:06:49 CEST] <ac_slater> (I don't use audio much so I don't know if there should be more than that) [03:47:17 CEST] <Zeranoe> Trying to pipe a yuv420p to ffmpeg but I cannot get it to work with 'ffmpeg -pix_fmt yuv420p -s 1920x1080 -loglevel debug -i -'. What options are needed before -i - ? [03:51:38 CEST] <kepstin> Zeranoe: you're sending it raw yuv420p video frames? [03:51:44 CEST] <kepstin> then you need '-f rawvideo' [03:52:48 CEST] <kepstin> (and you'll also want to use -video_size 1920x1080 -pixel_format yuv420p -framerate 24 or whatever) [03:53:29 CEST] <relaxed> yuv4mpegpipe would work too [03:53:51 CEST] <relaxed> if that's an option [03:53:54 CEST] <kepstin> if you can make the source output that format, sure. [04:25:36 CEST] <sethn> Im trying to use ffmpeg via pyav. Id like to write out lossless video, but I cant figure out the name of the ffv1 codec [04:25:51 CEST] <sethn> Was this included in ffmpeg 2.8? [04:26:15 CEST] <J_Darnley> It has existed for a long time before 2.8 [04:26:37 CEST] <J_Darnley> and it's name to ffmpeg/libavcodec is "ffv1" [04:26:42 CEST] <kepstin> it can be disabled at build-time, of course, but most builds should have it because it's on by default. [04:26:50 CEST] <sethn> weird [04:26:57 CEST] <sethn> And it should work with the matroska container, right? [04:27:03 CEST] <J_Darnley> yes [04:27:21 CEST] <sethn> Is there a way from the command line to list all video codecs? [04:27:27 CEST] <J_Darnley> ffmpeg -codecs [04:28:03 CEST] <sethn> oh, duh :-P [04:28:11 CEST] <sethn> So my ffmpeg command line shows ffv1 [04:28:25 CEST] <sethn> Sorry, this is PyAV, I dont know how directly it translates [04:28:28 CEST] <sethn> But when I try to do [04:28:57 CEST] <sethn> output = av.open(filename, w, matroska) [04:29:10 CEST] <sethn> stream = output.add_stream(ffv1, fps) [04:29:28 CEST] <sethn> It complains that codec ffv1 cant be found associated with the matroska container [04:29:45 CEST] <sethn> (Ive tried with mpeg4 container too) [04:30:17 CEST] <ac_slater> sethn: can you make an ffmpeg command line for what you're doing? [04:30:31 CEST] <J_Darnley> isobmff AKA mp4 won't support it [04:30:35 CEST] <ac_slater> ie - if it doesn't work there, then maybe there are other issues [04:30:36 CEST] <J_Darnley> I wonder whether that message is coming from your/this wrapper [04:30:38 CEST] <sethn> ac_slater: Im outputting an array I generated in code [04:30:57 CEST] <ac_slater> sethn: does that map to an ffmpeg command line? [04:31:08 CEST] <sethn> ac_slater: I dont think so? [04:31:14 CEST] <sethn> I can use the ffv1 codec [04:31:27 CEST] <sethn> J_Darnley: what container would you suggest? [04:31:33 CEST] <J_Darnley> matroska [04:31:38 CEST] <ac_slater> ffmpeg -i xxx -vcodec ffv1 -f matroska .... [04:31:44 CEST] <J_Darnley> My suggestion: write to stdout and have ffmpeg encode it from there. [04:31:46 CEST] <sethn> ac_slater: yeah, I can do that [04:32:01 CEST] <ac_slater> is pyav linked against your system version of ffmpeg? [04:32:09 CEST] <sethn> J_Darnley: What should I use to write out uncompressed video? [04:32:13 CEST] <sethn> ac_slater: yeah [04:32:26 CEST] <sethn> Im actually happy to use any uncompressed codec [04:32:29 CEST] <J_Darnley> NFI. You're the one using python rubbish [04:32:30 CEST] <sethn> Im just ignorant about codecs [04:32:33 CEST] <ac_slater> then it would at least show you what ffmpeg can actually do without having to debug the wrapper [04:32:49 CEST] <sethn> J_Darnley: oh, I meant, what encoding? [04:33:08 CEST] <ac_slater> sethn: you want uncompressed video in a container? [04:33:12 CEST] <J_Darnley> None. Dump the raw bytes [04:33:28 CEST] <J_Darnley> Well, the raw pixels [04:33:45 CEST] <sethn> gotcha, just write out the YUV420p pixels directly [04:34:38 CEST] <sethn> Is there another lossless codec I could try? I just dont know whats a reasonable choice. I really dont care what codec I use as long as its lossless. [04:34:46 CEST] <J_Darnley> libx264 [04:34:49 CEST] <J_Darnley> rawvideo [04:34:55 CEST] <J_Darnley> huffyuv [04:35:00 CEST] <ac_slater> sethn: huffyuv [04:35:02 CEST] <ac_slater> yea [04:35:12 CEST] <ac_slater> x264 doesnt have a lossless mode, does it? [04:35:20 CEST] <kepstin> it does, use '-qp 0' [04:35:23 CEST] <ac_slater> ah yea [04:35:33 CEST] <ac_slater> what profile does this depend on? [04:35:35 CEST] <ac_slater> if any [04:35:41 CEST] <kepstin> high444 [04:35:46 CEST] <sethn> ac_slater: Is there a container that huffyuv is commonly paired with? [04:35:51 CEST] <sethn> I really appreciate this guys [04:35:57 CEST] <sethn> I just dont know a lot about media formats [04:36:16 CEST] <ac_slater> sethn: ya know, I would do libx264 with high444 profile with -qp 0 (as said above), and put it in an MKV or MPEGTS container [04:36:23 CEST] <sethn> sweet :) [04:36:30 CEST] <ac_slater> but kepstin and others know more [04:36:58 CEST] <kepstin> (you obviously don't need to manually set any profile settings with x264 to encode lossless, just say '-qp 0' and let it go) [04:36:59 CEST] <ac_slater> hell, even MP4 I guess [04:40:33 CEST] <sethn> Is -qp shorthand for something? Im having trouble finding docs on -qp& trying to translate this from command-line commands to C api [04:40:55 CEST] <J_Darnley> He means -cqp [04:41:17 CEST] <sethn> tnx [04:41:27 CEST] <J_Darnley> and it stands for constnat quantiser something-or-other [04:41:34 CEST] <ac_slater> sethn: Quantization Parameter [04:41:47 CEST] <ac_slater> sethn: http://www.pixeltools.com/rate_control_paper.html#qua [04:42:08 CEST] <sethn> ah, got it [04:42:29 CEST] <kepstin> no, I mean literally "-qp" [04:42:40 CEST] <J_Darnley> ffmpeg does not have one [04:42:40 CEST] <kepstin> it's a libx264-specific avoption, iirc [04:42:53 CEST] <ac_slater> kepstin: it looks like a codec generic option [04:42:55 CEST] <ac_slater> https://www.ffmpeg.org/ffmpeg-codecs.html#Codec-Options [04:43:17 CEST] <kepstin> shows up in the libx264 avoptions on 'ffmpeg -h encoder=libx264' :/ [04:43:33 CEST] <kepstin> but i guess that includes generic ones too? [04:43:45 CEST] <c_14> It's libx264 specific as well [04:43:54 CEST] <J_Darnley> Then who's been chaning this shit again [04:46:07 CEST] <c_14> I actually can't find it listed as a generic option. [04:46:40 CEST] <J_Darnley> Meh, kepstin's probably right [04:46:44 CEST] <ac_slater> c_14: that link above codec options [04:46:46 CEST] <ac_slater> it's in there [04:46:54 CEST] <c_14> That's only -debug qp [04:46:58 CEST] <c_14> and -qphist [04:47:06 CEST] <J_Darnley> I just stick with things that worked 8 years ago. [04:47:14 CEST] <ac_slater> oh right, it's under debug [04:47:16 CEST] <ac_slater> my bad [05:01:08 CEST] <petecouture> Does anyone have any good links to understand correct use of force_key_frames [05:04:07 CEST] <ac_slater> petecouture: for vpx? [05:04:41 CEST] <petecouture> hls [05:05:16 CEST] <ac_slater> what codec [05:06:01 CEST] <petecouture> libx264 [05:06:54 CEST] <ac_slater> petecouture: I usually set the GOPSIZE and keyint (min-keyint) to firce IDR (IFrame) rate [05:08:04 CEST] <petecouture> I'll look a it [05:08:15 CEST] <ac_slater> your goal is to control the rate of key frames? [05:08:18 CEST] <ac_slater> petecouture: ^ [05:09:02 CEST] <petecouture> I'm a bit new to ffmpeg and coming from Wowza and hardware encoders where you have to set the keyframe rate to be divisble by the segment rate [05:09:14 CEST] <ac_slater> petecouture: I see [05:10:01 CEST] <ac_slater> it's pretty easy to customize the bitstream with libx264 and its options in ffmpeg [05:10:54 CEST] <petecouture> I have a live rtp stream being segmented to hls. [05:11:08 CEST] <petecouture> There's issues like sudden bandwidth droppage [05:11:23 CEST] <ac_slater> I'm completely unfamiliar with HLS, but I know a bit about RTP and h264 [05:11:25 CEST] <petecouture> Also the sometimes the encoding just stops processing frames [05:12:00 CEST] <ac_slater> you should get your bitstream where you want it first ... intrarefresh rate, annex B, rate, etc. [05:12:11 CEST] <petecouture> sec I'll put up my script [05:12:27 CEST] <petecouture> intrarefresh rate and annex B are new terms to me [05:13:12 CEST] <ac_slater> you may need them, maybe not depending on the actual goal [05:15:15 CEST] <petecouture> Thank you I'll look at them. It's mostly working but native apple player doen't like it. Also injected id3 frame metadata isn't firing, that was a week of wasted time. [05:15:34 CEST] <petecouture> Plays in jwplayer and hls.js [05:15:47 CEST] <ac_slater> that's a good start [05:15:52 CEST] <ac_slater> ;) [05:16:44 CEST] <petecouture> I oriignaly built this in wowza using rtmp to hls which was easy. Now I gotta do it using webrtc client to rtp to ffmpeg->hls. Been a long 2 months of hard R&D [05:16:47 CEST] <ac_slater> petecouture: I see some references about annex B in apples HLS documentation [05:16:55 CEST] <petecouture> ahhhh [05:17:05 CEST] <petecouture> Thank you! [05:17:12 CEST] <ac_slater> just a hunch [05:17:53 CEST] <ac_slater> ffmpeg has a bitstream filter for h264_mp4toannexb [05:18:05 CEST] <ac_slater> should be easy to find an example on the official docs [05:18:14 CEST] <ac_slater> https://ffmpeg.org/ffmpeg-bitstream-filters.html#h264_005fmp4toannexb [05:18:56 CEST] <petecouture> ahhhh [09:35:51 CEST] <sspiff> Hi [09:36:13 CEST] <sspiff> I was wondering if it is possible to generate interlaced H264 MPEG TSes with ffmpeg, and if so, how? [09:36:43 CEST] <Mavrik> Do you have an interlaced source? [09:37:44 CEST] <sspiff> Mavrik: yes [09:37:58 CEST] <Mavrik> Well, then the output will be interlaced as well. [09:38:05 CEST] <Mavrik> As long as you don't explicitly deinterlace it. [09:39:53 CEST] <sagax> hi all! where i find mime/type for html5 audio stream? [09:43:41 CEST] <sspiff> Mavrik: how do I explicitely deinterlace it? I don't see a filter for that. [09:44:25 CEST] <sspiff> And if I use the interlace video filter, would that generate interlaced video or would the result just contain progressive frames all the time, but look like they're interlaced? [10:01:56 CEST] <DHE> sspiff: if you need to force interlaced output, -flags ildct with libx264 should do it [10:02:10 CEST] <DHE> eg: the source material doesn't have any interlacing information in the codec [10:03:34 CEST] <DHE> the interlace filter converts progressive into interlaced content by actually modifying the images and reducing the framerate. wouldn't be my first choice [10:42:58 CEST] <sspiff> DHE: thanks, I'll try [10:50:51 CEST] <sspiff> DHE: that did it! But I don't understand what it does :) [10:52:04 CEST] <sspiff> the source is MPEG2, and when I open the stream in an analyzer it clearly marks top and bottom fields etc. [12:19:01 CEST] <raehik> Hiya, I'm trying to trim an audio file 1 second from the start and 1 second from the end. I know about -ss, -t and -to but I can't figure out how trim up to the -1 second i.e. 1 second before EOF. [12:19:30 CEST] <raehik> Trying cmds like this: ffmpeg -ss 1 -i infile.wav -to -1 outfile.wav [12:20:12 CEST] <raehik> but FFmpeg complains that -to is smaller than -ss, so I guess it doesn't take values relative to EOF [12:21:04 CEST] <c_14> you can't (without scripting or patching ffmpeg) [12:21:12 CEST] <c_14> or using the libraries I guess [12:21:23 CEST] <raehik> huh, that's a pain [12:21:31 CEST] <raehik> I know I can use SoX but I prefer FFmpeg for most things [12:22:07 CEST] <raehik> ok, that's fine. Cheers for the help [12:29:29 CEST] <sagax> hi all, [12:30:07 CEST] <sagax> i compiling all codec was i need and ffmpeg and i get normal ffmpeg workspace, great [12:30:28 CEST] <sagax> got* [14:55:39 CEST] <mr_pinc> Does the -crf command line option support decimal values? [14:56:16 CEST] <J_Darnley> yes [14:56:17 CEST] <furq> yes [14:58:00 CEST] <mr_pinc> great thanks [15:03:00 CEST] <mr_pinc> Well this is super useful - http://ubwg.net/b/full-list-of-ffmpeg-flags-and-options [15:22:00 CEST] <brm> hi, ffmpeg -s 352x288 -r 30 -f x11grab -i :0 -f alsa -i hw:0 http://localhost:8090/feed1.ffm [15:22:01 CEST] <brm> but Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height [15:22:14 CEST] <brm> and output to file works.. [15:22:31 CEST] <brm> please help. [15:24:13 CEST] <J_Darnley> mr_pinc: a better source is: ffmpeg -h and ffmpeg -h full [15:24:18 CEST] <J_Darnley> it even has type information [15:25:45 CEST] <brm> J_Darnley https://bpaste.net/show/0d07dde4c3d1 [15:26:41 CEST] <J_Darnley> Try reading the actual errors [15:26:57 CEST] <J_Darnley> They are are highlighted in red for a reason. [15:27:16 CEST] <brm> Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height [15:27:21 CEST] Action: J_Darnley wonders why he ever bothered adding that [15:27:26 CEST] <J_Darnley> OMFG! [15:27:31 CEST] <brm> but it error occur only when adding audio [15:27:34 CEST] <J_Darnley> [mpeg1video @ 0x2226ca0] bitrate tolerance 21333 too small for bitrate 64000, overriding [15:27:34 CEST] <J_Darnley> [mpeg1video @ 0x2226ca0] too many threads/slices (9), reducing to 8 [15:27:34 CEST] <J_Darnley> [mpeg1video @ 0x2226ca0] MPEG1/2 does not support 3/1 fps [15:27:55 CEST] <brm> aaaaaaa..... [15:29:19 CEST] <brm> how audio can affect fps [15:31:24 CEST] <J_Darnley> No idea. [15:31:39 CEST] <brm> how corrent this error.. [15:31:43 CEST] <brm> corerct* [15:31:50 CEST] <J_Darnley> No idea. [15:32:13 CEST] <J_Darnley> You require Arcane Knowledge to use ffserver [15:41:37 CEST] <__z0k__> ls [15:51:15 CEST] <brm> J_Darnley what can u advice to stream screen to dlna [15:55:56 CEST] <debianuser> brm: does adding "-t flv" between "-i hw:0" and "http://localhost:8090/feed1.ffm" changes anything? [15:56:27 CEST] Action: debianuser doesn't know much about ffserver... [15:57:43 CEST] <brm> but what u use ? [15:57:55 CEST] <brm> Invalid duration specification for t: flv [15:58:21 CEST] <brm> but works without it, but i cannot show this stream, also in swf [15:58:31 CEST] <brm> but errors not occur.. [15:59:26 CEST] <brm> i can`t google another tool, except ffmpeg [16:07:28 CEST] <J_Darnley> -t is a duration [16:07:35 CEST] <J_Darnley> perhaps he meant: -f flv [16:07:47 CEST] <J_Darnley> my suggestion about streaming: don't [16:08:12 CEST] <durandal_170> don't use ffserver [16:08:41 CEST] <debianuser> brm: Ah, right "-f flv", sorry :( [16:09:02 CEST] <debianuser> What's the suggested ffserver replacement these days? [16:12:54 CEST] <brm> dont use ffserver, but what use? [16:13:36 CEST] <brm> https://bpaste.net/show/e71032cc89d1 [16:19:22 CEST] Action: debianuser guesses the problem is "Connection to tcp://localhost:8090 failed (Connection refused), trying next address", i.e. something that was supposed to listen to localhost:8090 is not running. [16:27:00 CEST] <brm> debianuser https://bpaste.net/show/ff3a78eb7963 [16:37:33 CEST] <debianuser> brm: "av_interleaved_write_frame(): Connection reset by peer" -- it still drops the connection. Maybe it doesn't like flv? And google suggests it without flv either... Does it work if you write it to the local mpg file? Try `ffmpeg -s 640x480 -r 25 -f x11grab -i :0 -f alsa -i hw:0 -f mpeg testfile.mpg` [16:39:52 CEST] <brm> debianuser ffmpeg -f x11grab -video_size cif -framerate 25 -i :0.0 -f flv file.swf [16:39:55 CEST] <brm> it works.. [16:39:59 CEST] <brm> problem with ffserver [16:44:03 CEST] <debianuser> No, I mean test both `ffmpeg -s 640x480 -r 25 -f x11grab -i :0 -f alsa -i hw:0 testfile.mpg` and `ffmpeg -s 640x480 -r 25 -f x11grab -i :0 -f alsa -i hw:0 http://127.0.0.1:8090/feed1.ffm`, same command line, with target url/file being the only difference. What's the difference in output then? [16:45:07 CEST] <mr_pinc> J_Darnley: Yes but that is not an easy to reference webpage [16:45:25 CEST] <brm> debianuser https://bpaste.net/show/3d3751c07aab [16:45:44 CEST] <brm> and at ffserver.conf format mpeg [16:45:53 CEST] <brm> how option need set that it works... [16:48:01 CEST] <debianuser> [tcp @ 0x25f2440] Connection to tcp://localhost:8090 failed (Connection refused), trying next address [16:48:15 CEST] <debianuser> It's either not running or not listening to port 8090 [16:49:47 CEST] <brm> it running.. [16:50:21 CEST] <brm> https://bpaste.net/show/bda5ca94b67d [16:51:06 CEST] <debianuser> what does `echo -n | telnet localhost 8090` say? [16:51:41 CEST] <debianuser> (by the way, "NoAudio"?) [16:53:00 CEST] <brm> v [16:53:01 CEST] <brm> http://pastebin.com/DwK6EPHT [16:53:25 CEST] <brm> NoAudio .. for simplify [17:02:45 CEST] <debianuser> brm: telnet looks working. Then maybe it's about ffserver setup? I'm not sure if you can have both AudioBitRate/AudioChannels/AudioSampleRate and NoAudio in the same section, maybe you need to comment out one of them? [19:15:27 CEST] <fritsch> Hi [19:15:34 CEST] <fritsch> how to force: https://github.com/FFmpeg/FFmpeg/blob/release/3.0/libswscale/arm/yuv2rgb_ne… this from commandline? [19:15:48 CEST] <fritsch> we have code in kodi that segfaults when ffmpeg is compiled with asm optimizations [19:15:57 CEST] <fritsch> we try to reproduce on the target system with: [19:17:46 CEST] <fritsch> ./ffmpeg -i /usr/share/kodi/addons/audioencoder.xbmc.builtin.aac/icon.png -filter:v scale=256:256 -sws_flags bicubic output.png [19:17:54 CEST] <fritsch> but that seems to use another codepath [19:22:46 CEST] <c_14> Are you sure icon.png is yuv420p? [19:28:32 CEST] <fritsch> c_14: 100% not :-) [19:29:09 CEST] <c_14> Then that would explain why that's not called, wouldn't it? [19:29:15 CEST] <fritsch> exactly [19:29:20 CEST] <fritsch> hehe [19:29:24 CEST] <fritsch> thx, much [19:51:29 CEST] <fritsch> c_14: i supplied external data and that was not proplerly 16 byte aligned [19:51:42 CEST] <fritsch> c_14: so the code fell on its nose [21:22:42 CEST] <mbeacom> Good afternoon everyone! Currently working through an issue with ffmpeg input from RTMP output to FLV format. I have a scaling expression in the form of: "scale='if(gt(iw,ih),480,trunc(oh*a/2)*2)':'if(gt(iw,ih),trunc(ow/a/2)*2,480)'" We are consuming a live RTMP stream from a mobile device. The mobile device changes orientation signaled in the ffmpeg log: http://pastebin.com/VQaq8yq8 [21:25:12 CEST] <J_Darnley> Easy: stop rotating the camera [21:25:17 CEST] <mbeacom> It appears that the output video changes orientation and immediately scales back down? Any thoughts or suggestions on changing this? Full FFmpeg execution: http://pastebin.com/hp1779xN [21:25:19 CEST] <mbeacom> ... [21:26:53 CEST] <mbeacom> J_Darnley: Thank you for the suggestion... I am assuming that the fact it sees the event and attempts to scale... [21:29:05 CEST] <J_Darnley> Then I don't understand the problem. It looks like ffmpeg is keeping it withijn the 480x480 box you asked for. [21:29:49 CEST] <mbeacom> J_Darnley: How is that a 480x480 box? It is checking the input width and height, seeing which is greater and adjusting accordingly? [21:30:16 CEST] <mbeacom> Which it does fine, if the orientation is locked or doesn't change after initiation... [21:31:12 CEST] <J_Darnley> "if input width is greater than input height set width to 480 else adjust 480 for aspect" and vice versa for the height [21:33:50 CEST] <mbeacom> J_Darnley: Right... if the input is 1280x720... the scaler scales that particular output to 480x270. If the input is 720x1280, it outputs 270x480... [21:34:06 CEST] <J_Darnley> yes [21:34:50 CEST] <mbeacom> J_Darnley: So, it works correctly on the initial stream, but attempts to scale it incorrectly following the Reinit event. [21:36:16 CEST] <J_Darnley> Oh my mistake. I thought this was joing landscape->portrait. [21:36:20 CEST] <J_Darnley> *going [21:38:20 CEST] <J_Darnley> You can try making it evaluate the expression every frame to see if that fixes it. [21:38:43 CEST] <J_Darnley> append "eval=frame" to the end of the scale filter [21:39:00 CEST] <mbeacom> J_Darnley: Thank you! I'll try it out and see what happens! [21:43:42 CEST] <mbeacom> J_Darnley: Inside of the "scale=''" ? Like "scale='', eval=frame" ? [21:45:14 CEST] <furq> :eval=frame [21:46:46 CEST] <mbeacom> furq: [AVFilterGraph @ 0x28c5220] No such filter: 'eval' hhmm.... [21:47:23 CEST] <rrva> can I somehow specify PTS durations ffmpeg -f segment ? [21:47:43 CEST] <J_Darnley> There's a segment time option as I recall [21:48:04 CEST] <rrva> https://www.ffmpeg.org/ffmpeg-formats.html [21:48:18 CEST] <rrva> segment_time time [21:48:18 CEST] <rrva> Set segment duration to time, the value must be a duration specification. Default value is "2" [21:49:57 CEST] <rrva> I guess I can use segment_frames option [21:52:05 CEST] <rrva> how do I get the frame numbers to be output with ffprobe -show_frames ? [21:57:15 CEST] <llogan> rrva: what parameter do you actually want to display? [21:57:40 CEST] <rrva> I want to know the frame number of the first i-frame with a certain PTS [21:57:57 CEST] <rrva> so I can pass it to segment_frames [21:58:24 CEST] <rrva> I want to use ffmpeg -f segment, but specify segment breakpoints in PTS [21:59:11 CEST] <J_Darnley> pts is just time scaled by the timebase [22:00:20 CEST] <rrva> what is the unit for segment_time in now? seconds ? [22:00:27 CEST] <J_Darnley> yes [22:00:56 CEST] <rrva> PTS is 90khz [22:01:05 CEST] <rrva> so I want to cut at a specific PTS value [22:01:06 CEST] <rrva> segment [22:01:29 CEST] <rrva> at exactly before a certain i-frame [22:02:22 CEST] <llogan> you can list particular entries like: ffprobe -show_entries frame=foo,bar,etc input [22:05:46 CEST] <rrva> ffprobe -of json -show_frames is ok, I can parse that and increment a counter for each frame, and then search of "pkt_pts" [22:05:51 CEST] <rrva> and "key_frame" = 1 [23:24:23 CEST] <rrva> I got away with using ffprobe -of csv -show_entries frame=key_frame,pkt_pts -select_streams v a.ts > a.csv [23:24:35 CEST] <rrva> and then doing "grep -A10 -n <pts_value>" [23:25:02 CEST] <rrva> this gave me video frame # [23:55:19 CEST] <Taoki> Hi everyone. I have a png sequence and a wav file, which I'm trying to combine into a mp4 file. For some reason, the speed of the video does not seem to match that of the audio, and the two don't sync up. Is there a way to make ffmpeg automatically adjust the frame rate of the video based on the length of the wav file, and have it fit perfectly... instead of using the -r parameter? [23:55:54 CEST] <J_Darnley> I don't think so. [23:56:00 CEST] <c_14> You probably want -framerate instead of -r, and you'll have to do that manually. [23:56:13 CEST] <Taoki> ok [00:00:00 CEST] --- Thu Mar 31 2016

1 0

ffmpeg-devel.log.20160329
by burek 30 Mar '16

30 Mar '16

[00:09:51 CEST] <ubitux> BBB: samples.mplayerhq.hu/benchmark/testsuite1/matrixbench_lowdivx_wma.avi has color_primaries=bt470m [00:10:54 CEST] <ubitux> couldn't find anything with bt2020 [00:11:00 CEST] <ubitux> but maybe we simply don't export the meta [00:11:27 CEST] <llogan> dinux5: what are the actual errors? (use a pastebin link) altough it's probably much less priority than other stuff [00:11:50 CEST] <llogan> dinux5: also, i forgot to mention, top-posting on the mailing list is to be avoided. [00:12:08 CEST] <kierank> there isn't much (if any) bt2020 content out there [00:12:32 CEST] <BBB> wheeee cool [00:12:35 CEST] <BBB> ty again [00:12:48 CEST] <kierank> BBB: http://demo-uhd3d.com/fiche.php?cat=uhd&id=113 [00:12:53 CEST] <kierank> that is bt2020 [00:13:06 CEST] <JEEB> yeah, even broadcast specs from ARIB have a thing in there which goes "'cause we require BT.2020, this is how you convert BT.709 footage to BT.2020 correctly" [00:13:38 CEST] <BBB> the picture? [00:13:54 CEST] <BBB> ffmpeg says its bt470 [00:14:03 CEST] <kierank> ? [00:14:18 CEST] <JEEB> there's a link to a mp4 [00:14:18 CEST] <kierank> the download button on the right [00:14:57 CEST] <BBB> oooooooooooo [00:14:57 CEST] <dinux5> llogan: Sure. Right now I can tell only about one such error. [00:14:59 CEST] <BBB> duh :D [00:15:00 CEST] <BBB> sorry [00:15:08 CEST] <BBB> holy crap its 912MB [00:15:48 CEST] <ubitux> % ffprobe -v error -of flat -show_entries stream=color_space,color_primaries 'http://demo-uhd3d.com/files/uhd4k/NEO_Fire_HDR_HEVC_2160p_5994_Main10_45-10…' [00:15:50 CEST] <ubitux> streams.stream.0.color_space="unknown" [00:15:52 CEST] <ubitux> streams.stream.0.color_primaries="bt2020" [00:15:54 CEST] <ubitux> nice [00:17:14 CEST] <dinux5> under heading non doxy comments it gives /* channel meaning */ [00:17:25 CEST] <dinux5> and many comments like these [00:18:57 CEST] <cone-135> ffmpeg 03Lou Logan 07master:06eef96b69d7: fix some a/an typos [00:19:03 CEST] <dinux5> llogan : and under heading inconsistently formatted doxygen comment it gives comments within /** foo*/ [00:19:58 CEST] <ubitux> nice vp9 2560x1440 stress video to youtube-dl @ https://www.youtube.com/watch?v=er416Ad3R1g [00:23:51 CEST] <jamrial> ubitux: https://www.youtube.com/watch?v=MGyaR2sSBkA this one has 4k vp9 60fps [00:27:53 CEST] <ubitux> it looks laggy [00:28:17 CEST] <ubitux> there is a very inconsistent frame dup pattern [00:29:16 CEST] <ubitux> it looks *really* laggy [00:29:53 CEST] <nevcairiel> seems fine here, maybe your playback is just too slow? [00:30:55 CEST] <ubitux> no, try frame per frame [00:31:13 CEST] <nevcairiel> its a video game, so camera movement is never going to be perfectly smooth [00:31:22 CEST] <ubitux> literally unplayable [00:31:42 CEST] <nevcairiel> you must have rather odd definitions of unplayable, or your player is screwing up =p [00:32:05 CEST] <ubitux> unplayable as a game i mean [00:32:08 CEST] <ubitux> :) [00:44:05 CEST] <kierank> Is anyone interested in looking at my assembly to find a bug? [00:56:31 CEST] <kierank> Is there an -f raw so I can dump an encoded bitstream to a file? [00:57:47 CEST] <llogan> -f rawvideo [00:58:07 CEST] <kierank> that will work? [00:58:12 CEST] <kierank> even if it's raw encoded data [00:59:45 CEST] <kierank> seems so [01:00:12 CEST] <llogan> that's good because now i think i misread your question [01:07:31 CEST] <kierank> oh fuck it's a little endian bug [01:44:24 CEST] <kierank> wtf is svag [01:45:11 CEST] <kierank> playstation audio apparently [01:55:48 CEST] <kierank> lol netflix patching zimg [02:27:25 CEST] <Daemon404> kierank, not surprising considering it was written by a netflix guy. [02:34:55 CEST] <cone-135> ffmpeg 03James Almer 07master:d5a3578350a3: avformat/svag: fix division by zero [02:37:34 CEST] <llogan> talking about zscale, how do i use it to convert bgr0 to yuv420p? [02:58:44 CEST] <jamrial> michaelni: is a division by zero fix for a super obscure demuxer worth backporting? [02:59:33 CEST] <michaelni> jamrial, yes [02:59:50 CEST] <jamrial> ok, thanks [02:59:51 CEST] <michaelni> crash fixes are always worth backporting [03:13:16 CEST] <cone-135> ffmpeg 03James Almer 07release/3.0:7b1e020fc5ed: avformat/svag: fix division by zero [03:53:24 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07release/3.0:26d29f0c3dc2: avcodec/h264_slice: Check PPS more extensively when its not copied [03:53:25 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07release/3.0:00b54d4625b0: avcodec/diracdec: check bitstream size related fields for overflows [04:16:49 CEST] <llogan> maybe i'll write a nvenc install/use guide. finally got access to something better than my GT 240. [04:24:54 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07release/3.0:9b1b674ebefd: Changelog: update [04:26:56 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07release/3.0:fda00aa77493: doc/Doxyfile: update for 3.0.1 [04:37:30 CEST] <cone-135> ffmpeg 03James Almer 07n3.0.1:HEAD: avformat/svag: fix division by zero [06:41:29 CEST] <TheRyuu> ok saw this http://mplayerhq.hu/pipermail/ffmpeg-devel/2016-March/191195.html the hilight got buried somehow [06:48:43 CEST] <TheRyuu> I think making it dependent on enable/disable-debug is reasonable [06:50:59 CEST] <Zeranoe> Is there anything else I can do to help resolve http://trac.ffmpeg.org/ticket/4832 ? That backtrace makes me think it isn't FFmpeg, but I would like confirmation [07:42:44 CEST] <TheRyuu> patch sent to ML [14:32:45 CEST] <kierank> BBB: Have I sent you this piece of brilliance before: https://bugs.chromium.org/p/webm/issues/detail?id=701 [14:33:38 CEST] <BBB> nope [14:34:02 CEST] <kierank> my favourite bug ever [14:34:35 CEST] <kierank> "Maybe this should be fixed in VLC?" also hillarious [14:34:50 CEST] <BBB> :) [14:34:59 CEST] <BBB> I think codecs should not deal with timestamps [14:35:02 CEST] <kierank> and the guy reporting is a googler [14:35:27 CEST] <BBB> codecs are 1in 1out so you can work with poc and convert to pts in the caller in whatever precision they want (like a hashmap) [14:35:53 CEST] <BBB> but yes, nice bug :D [14:36:21 CEST] <BBB> so I wrote a new filter yesterday that seems to convert colorspaces correctly taking into account their primaries/gamma [14:36:42 CEST] <BBB> its a little slow so Ill write some integer code (and simd) [14:37:08 CEST] <BBB> I might still finish thomas patch since some people dont seem to mind fast but wrong solutions [14:38:35 CEST] <BBB> thanks for samples yesterday [14:38:48 CEST] <BBB> kierank: do you have broadcast samples that are confirmed correct for from/to testing? [14:39:00 CEST] <BBB> like, not output from -vf colormatrix, but actual reference samples from committees or so [14:39:09 CEST] <wm4> kierank: is it a timestamp range issue? [14:39:30 CEST] <kierank> BBB: the smptebars (sd) is definitely correct [14:39:31 CEST] <BBB> like, a picture like this in bt2020 10bit notation should look like this in bt709 8bit notation [14:39:45 CEST] <BBB> what is smptebars? [14:39:46 CEST] <kierank> I don't have the equipment to verify the hd bars [14:39:50 CEST] <kierank> BBB: color bars [14:39:54 CEST] <BBB> is that a filter? [14:39:56 CEST] <kierank> yes [14:39:58 CEST] <BBB> ah [14:39:59 CEST] <BBB> ok [14:40:57 CEST] <BBB> but how do you specify the colorspace? [14:41:03 CEST] <kierank> it's hardcoded in the filter [14:41:12 CEST] <kierank> (it's SD so it's bt601) [14:41:53 CEST] <BBB> right, so I need content that is confirmed identical on television so I can confirm that when I convert bt601 to bt709, it is correct [14:46:09 CEST] Action: kierank thinks [14:47:42 CEST] <wm4> in mpv we've also implemented bt2020 [14:50:13 CEST] <kierank> wm4: yes, they have an int64_t timestamp but don't allow the entire range [14:50:40 CEST] <kierank> x264 has infinite precision arithmetic for these cases [14:50:49 CEST] <kierank> (hrd) [14:54:26 CEST] <wm4> I bet ffmpeg breaks in various cases if the full bits are used [15:06:15 CEST] <ncopa> hi [15:06:33 CEST] <ncopa> it seems that the FF_SYMVER define is not used any place anymore [15:06:54 CEST] <ncopa> i suppose it can be removed now? [15:08:54 CEST] <wm4> I guess so, API users certainly can't use it [15:09:13 CEST] <ncopa> and it was broken on uclibc too [15:15:54 CEST] <ncopa> somethign like this: http://tpaste.us/AW4Y [15:20:55 CEST] <ncopa> separated the clean up commits: http://tpaste.us/3gjm [15:55:14 CEST] <kierank> Gramner: any ideas if this code be sped up more? https://github.com/kierank/ffmpeg-sdi/blob/master/libavcodec/x86/sdienc.asm [15:55:20 CEST] <kierank> apart from doing avx2 [15:56:02 CEST] <kierank> or J_Darnley if you are around [15:56:55 CEST] <Gramner> kierank: store the constants in registers. then you could also do a 3-arg pmullw [15:56:55 CEST] <durandal_1707> no its already trivial, I guess [15:57:46 CEST] <durandal_1707> tell what speed you got [15:58:20 CEST] <kierank> it's twice as fast on skylake than haswell [15:58:52 CEST] <ubitux> (missing ':' after loop label) [15:59:02 CEST] <Gramner> how large is the size? might be worth unrolling [15:59:04 CEST] <ubitux> (nasm won't like it) [16:03:37 CEST] <kierank> Gramner: 62 bytes for avx [16:03:49 CEST] <Gramner> i mean size of input [16:04:04 CEST] <kierank> ah, it's a frame [16:04:11 CEST] <kierank> so 1920*1080*2*2 [16:04:12 CEST] <Gramner> definitely worth unrolling once then [16:04:47 CEST] <kierank> I was thinking of trying to make it do 15 pixels per iteration but seems a bit tricky [16:07:33 CEST] <Gramner> could maybe do some palignr trickery if you do two iterations per loop and do one movu and one movd. that way only half the stores are unaligned [16:35:26 CEST] <Daemon404> ...... [16:35:33 CEST] <Daemon404> "To unsubscribe from this group and stop receiving emails from it, send an email to google-summer-of-code-mentors-list+unsubscribe(a)googlegroups.com." [16:35:45 CEST] <Daemon404> except gmail complains its not a rfc-compliant email an rejects it [16:35:49 CEST] <Daemon404> lovely. [16:36:10 CEST] <Gramner> what's non-compliant with that address? [16:36:22 CEST] <Daemon404> it isnt [16:36:29 CEST] <Daemon404> i sent the same mail a 2nd time and it worked [16:36:32 CEST] <Daemon404> maybe a gmail hiccuo [16:36:33 CEST] <Daemon404> p [16:37:18 CEST] <Daemon404> (litrally just git send a 2nd time) [16:52:46 CEST] <Daemon404> wm4, did you get a chance to look at the utstanding tep2 crap today? [16:53:44 CEST] <wm4> not yet [16:53:52 CEST] <Daemon404> ok [17:05:45 CEST] <durandal_1707> what not yet? [17:07:48 CEST] <wm4> look [17:08:31 CEST] <durandal_1707> look what? [17:08:35 CEST] <cone-308> ffmpeg 03Vittorio Giovara 07master:7888ae8266d8: cfhd: Do not initialize context size [17:08:36 CEST] <cone-308> ffmpeg 03Jovan Zelincevic 07master:b73c27151eda: avcodec/mips: Optimization synced to the newest code base. [17:09:15 CEST] <durandal_1707> finally tep2 when? [17:09:46 CEST] <wm4> when you fix all the fate tests [17:15:22 CEST] <kierank> Gramner: are there any tricks to do a variable right shift? [17:15:42 CEST] <Gramner> pmulhrsw [17:16:06 CEST] <Gramner> the v210 code in x264 (among other things) uses it [17:16:26 CEST] <Gramner> it has some limitations though [17:16:40 CEST] <Gramner> also pmulhuw [17:16:43 CEST] <flux> - [17:16:49 CEST] <flux> (oops, carry on) [17:17:24 CEST] <Gramner> the latter might be better in this case [17:18:31 CEST] <wm4> so I build the codecpar branch, and my terminal, including all of scrollback, is full of deprecation warnings in ffmpeg CLI tools [17:21:36 CEST] <Daemon404> wm4, those will be fixed in later bits [17:21:41 CEST] <Daemon404> even libav did them in separate commits [17:21:49 CEST] <Daemon404> this merge is for lavf [17:21:58 CEST] <wm4> right [17:22:10 CEST] <Daemon404> its [17:22:17 CEST] <Daemon404> it's also a good way to check API compatability* [17:22:24 CEST] <Daemon404> since the cli tools use the old api [17:22:25 CEST] <Daemon404> currently [17:22:56 CEST] <wm4> do we just convert it to the new API later, or do we keep both? [17:23:03 CEST] <nevcairiel> convert [17:27:17 CEST] <kierank> Gramner: I see, atomnuker is working on the opposite 10-bit bitpack unpack [18:40:59 CEST] <wm4> __MINGW32CE__ [18:41:06 CEST] <wm4> do we support such a configuration [18:41:12 CEST] <Daemon404> libav has such fates [18:41:15 CEST] <Daemon404> wbs runs them [18:41:19 CEST] <Daemon404> no idea if it *does* anything though [20:47:53 CEST] <kierank> Gramner: the next fun one is v210 -> bitpacked and vice versa [20:48:47 CEST] <Gramner> shouldn't those be fairly similar? [21:09:26 CEST] <fritsch> https://ffmpeg.org/doxygen/3.0/structAVSubtitleRect.html <- AVSubtitle uses the deprecated AVPicture [21:09:36 CEST] <fritsch> i am just cleaning up kodi's usage of AVPicture [21:09:50 CEST] <fritsch> and yeah - how to use AVSubtitle without running into this deprecation thingy? [21:12:06 CEST] <Daemon404> it says unused [21:12:13 CEST] <Daemon404> i assume you want to use data and linesize instead [21:13:48 CEST] <fritsch> Daemon404: exactly :-) just got it 2 seconds ago [21:13:49 CEST] <fritsch> thx much [21:15:39 CEST] <fritsch> btw. the transition was quite easy as there are replacements with av_image_fill_* [21:16:38 CEST] <fritsch> the only thing that was not that intuitive after going from AVPicture to AVFrame was the usage of av_frame_get_buffer instead avpicture_alloc [21:18:28 CEST] <wm4> we deprecated it because users kept doing broken stuff like aliasing AVPicture and AVFrame [21:19:02 CEST] <fritsch> most likely I also do that somehow unknowingly [21:19:11 CEST] <fritsch> https://github.com/xbmc/xbmc/pull/9491/commits/bc2bc5e163e2442ec121a5590106… [21:19:50 CEST] <fritsch> it also feels a bit odd that one needs to go the av_image_* method some times and in other cases stick to the frame methods [21:21:41 CEST] <wm4> av_image_ is usually for explicitly layouted stuff [21:22:10 CEST] <wm4> e.g. they often come up if you need to pack a planar image to a continuous buffer (like win32 crap) [21:22:20 CEST] <wm4> or raw files [21:22:42 CEST] <wm4> while the main point of AVFrame is being refcounted [21:23:01 CEST] <wm4> nevcairiel: do you know about the codecpar swf failure? [21:23:29 CEST] <wm4> I see that the only way it can create an audio stream is create_new_audio_stream, and it always sets the channel count, yet ffprobe shows channels==0 [21:23:37 CEST] <wm4> how can that possibly be [21:25:52 CEST] <Daemon404> i think nevcairiel said that it was getting copied to the avctx because it wasnt updated after it was added or something [21:25:55 CEST] <Daemon404> ? [21:26:12 CEST] <wm4> actually I'm very stupid, I guess [21:26:15 CEST] <wm4> flv != swf [21:26:23 CEST] <Daemon404> lol [21:26:53 CEST] <wm4> ok the flvdec code looks much worse [21:27:11 CEST] <Daemon404> i dont think tehre are any outstanding flv issues [21:27:13 CEST] <Daemon404> only swf [21:28:23 CEST] <wm4> fate-acodec-adpcm-swf fails, and it's flv [21:28:37 CEST] <wm4> (the codec is named adpcm_swf) [21:28:41 CEST] <Daemon404> ... why is ic called swf [21:28:41 CEST] <Daemon404> oh. [21:31:06 CEST] <wm4> I guess it's nothing that can be fixed in 5 mins, so I'll stare at it again tomorrow [21:31:21 CEST] <Daemon404> i did say i need help. [21:34:26 CEST] <wm4> elenril fixed this in 09ae7b81ea2051eec2be9964296bd6ef492c6622 I think (it was not merged) [21:36:45 CEST] <Angus> Has AVFormat::destruct been replaced with AVFormat::av_free_packet? [21:37:16 CEST] <wm4> Angus: yes [21:37:23 CEST] <Daemon404> free_packet is deprecated [21:37:37 CEST] <Daemon404> wm4, im not opposed to cherry picking that commit [21:37:51 CEST] <wm4> Daemon404: well it broke something about metadata [21:38:01 CEST] <Daemon404> ? [21:38:03 CEST] <Angus> alright, thanks. [21:38:17 CEST] <Angus> oh, is free_packet also deprecated? [21:38:18 CEST] <wm4> Angus: you should use av_packet_unref [21:38:50 CEST] <wm4> and AVPacket.destruct couldn't be used directly (or shouldn't have) [21:39:15 CEST] <wm4> Daemon404: see 95daa9e09aeccf6ccef4b5c08097f6b5b581de15 (Not merged. The demuxer issues warnings when a new stream is encountered and reading the metadata requires that streams already exist.") [21:39:33 CEST] <Angus> I found this in the code I'm looking through... [21:39:34 CEST] <Angus> if (pPacket->destruct != NULL) { pPacket->data = NULL; pPacket->size = 0; } [21:39:49 CEST] <Daemon404> wm4, so... whats your opinion then on the 'fix' [21:40:15 CEST] <wm4> Angus: broken [21:40:53 CEST] <Angus> Yep, that's a memory leak if(condition is true) [21:42:04 CEST] <wm4> Daemon404: I don't know yet, we probably need to store the metadata somewhere until the AVStream is created? or provide a way for demuxers to update AVStream.codec from changed codecpars [21:42:37 CEST] <Daemon404> how does this work at all in libav then [21:43:59 CEST] <wm4> my guess is it doesn't have this code [21:44:11 CEST] <Daemon404> makes sense i guess... [21:44:48 CEST] <wm4> well I'm not sure, there's also metadata reading code, but I'll look closer tomorrow [21:45:55 CEST] <Daemon404> ok [22:02:14 CEST] <Angus> can av_read_frame(AVFormatContext, AVPacket) be called without calling av_new_packet() first? [22:04:30 CEST] <Angus> (I assume that's correct, as av_read_frame() seems to fill/initialize the AVPacket with stuff?) [22:06:19 CEST] <cone-308> ffmpeg 03Paul B Mahol 07master:4a80a6ad2129: avfilter/vf_waveform: optimize lowpass filter even more [22:16:23 CEST] <durandal_1707> BBB: I'm interested in your filter, how much is it slower than broken colormatrix? [22:16:36 CEST] <BBB> durandal_1707: speeding it up now [22:16:44 CEST] <BBB> durandal_1707: itll be a bit slower but hopefully not terribly much [22:16:59 CEST] <JEEB> there's nothing you can't cover with some nice SIMD :) [22:17:00 CEST] <durandal_1707> because? [22:17:12 CEST] <JEEB> that's also what I learned from zimg regarding proper scaling etc [22:17:46 CEST] <JEEB> and usually in our days it's better to be correct than a bit faster [22:17:57 CEST] <durandal_1707> what swscale is doing is not proper? [22:18:31 CEST] <JEEB> I'd go as far as to say that, yes [22:19:07 CEST] <JEEB> it's built in the times when speed was more important than being accurate [22:20:00 CEST] <JEEB> that said, I still use swscale for some stuff :P [22:21:55 CEST] <wm4> more importantly, it's extremely hard to tell whether libswscale does something correctly [22:22:04 CEST] <wm4> or rather, it's hard to tell what the heck it _does_ [22:22:32 CEST] <wm4> if you want to check correctness by treating it as a black box, you have to test a lot of combinations of input and output [22:26:50 CEST] <ubitux> BBB: so not going to integrate that code in sws? :° [22:26:57 CEST] <ubitux> SWS_CS_* are already there! ;) [22:27:42 CEST] <BBB> Ill show you what Ive got when its ready [22:27:57 CEST] <BBB> we can then try to re-engineer it in whatever beautiful way we want [22:28:05 CEST] <BBB> but at least I have something that works and solves my problem at hand [22:32:28 CEST] <cone-308> ffmpeg 03Paul B Mahol 07master:bf1495d9a991: doc/filters: remove false claim in sofalizer description [22:34:43 CEST] <durandal_1707> swscale design is nightmare [22:45:11 CEST] <rcombs> swscale needs its own duplicates of lavu's colorspace enum because ????? [22:48:33 CEST] <wm4> rcombs: maybe lavu didn't have them in the past, and libswscale and libavcodec were not supposed to depend on one or the other [22:48:53 CEST] <rcombs> and then they moved to lavu and nobody removed the swscale ones, I guess [22:49:26 CEST] <jamrial> rcombs: there's an audiotoolboxenc patch that fixes build failures on iOS. did you see it? [22:49:36 CEST] <rcombs> jamrial: you mean the one I sent? [22:50:59 CEST] <wm4> rcombs: well, removing the sws ones could be non-trivial, who knows? [22:51:06 CEST] Action: rcombs shrugs [22:51:18 CEST] <wm4> but feel free to submit a patch trollol [22:51:34 CEST] <jamrial> rcombs: no, the one by Crossle Song [22:52:14 CEST] <rcombs> oh, I missed that [22:52:32 CEST] <rcombs> it's nearly identical to mine, but does have one minor issue (it accidentally changes some logic) [22:53:04 CEST] <rcombs> (mine came later) [22:53:27 CEST] <jamrial> he resent it after nevcairiel pointed that out. or you mean the second one is also faulty? [22:54:04 CEST] <rcombs> the second one isn't faulty, but does duplicate code unnecessarily [22:56:29 CEST] <rcombs> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/192248.html I don't have anything setup to test or debug on iOS devices, so I'm not sure what's going on here [22:58:26 CEST] <rcombs> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/192249.html and I don't see this issue here [00:00:00 CEST] --- Wed Mar 30 2016

1 0

ffmpeg.log.20160329
by burek 30 Mar '16

30 Mar '16

[00:17:08 CEST] <Psi-Jack> I'm having an issue with ffmpeg I can't seem to resolve. I've got a .flac file I'm trying to convert to m4a with the libfdk_aac module. [00:18:00 CEST] <Psi-Jack> ffmpeg -y -i "08-Elastic Heart.flac" -c:a libfdk_aac -b:a 256k "08-Elastic Heart.m4a" -- Results in this error: Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [00:18:33 CEST] <JEEB> the error is somewhere before that [00:18:41 CEST] <JEEB> just pastebin the whole command and command line output [00:18:43 CEST] <JEEB> and link here [00:19:24 CEST] <jkqxz> andrey_utkin: So you've got a stream with some failing frames in it; now you want to work out what's special about those frames. (Looks like the decoder chokes most of the way through those frames (~1100/1350); maybe you have some fixed buffering somewhere which is being exceeded?) [00:20:24 CEST] <Psi-Jack> Okay. Will do. [00:24:23 CEST] <Psi-Jack> https://paste.linux-help.org/view/645140af [00:24:58 CEST] <jkqxz> andrey_utkin: You might also want to extract the elementary stream ("-i input.mkv -c copy output.264"), which you can then do more with. [00:28:02 CEST] <JEEB> Psi-Jack: add -vn after input file name [00:28:21 CEST] <JEEB> it's trying to encode the JPEG in there as AVC... with CUDA [00:28:36 CEST] <Psi-Jack> Heh, sheash... [00:28:38 CEST] <JEEB> which fails :P [00:28:50 CEST] <Psi-Jack> Alrighty! Yep. That's working alrighty [00:28:53 CEST] <JEEB> vn tells it that no video should be encoded [00:29:00 CEST] <Psi-Jack> Right, I looked it up. :) [00:29:04 CEST] <JEEB> also you should most probably update that ffmpeg [00:29:21 CEST] <Psi-Jack> I wish I could, it's actually amazing that I have this version at all, on CentOS 7. [00:29:29 CEST] <Psi-Jack> WITh the fdk_aac support. [00:29:47 CEST] <Psi-Jack> I could compile a new version, sure, but I prefer not to if I don't /need/ to. :) [00:31:58 CEST] <Psi-Jack> Looks like that also handles tagging copies too, which is VERY nice, compared to my previous method, which was to use ffmpeg to output WAV, then use neroAacEnc to stream that to AAC in-line. [00:32:07 CEST] <Psi-Jack> (aka: through pipes) [00:50:31 CEST] <Psi-Jack> Heh. [00:50:34 CEST] <Psi-Jack> This is totally wierd... [00:53:44 CEST] <Psi-Jack> My script is running through multiple files converting everything from .flac to .m4a that isn't in the working directory or the library directory itself, but doing the ffmpeg by the CLI directly on a specific file, no problem. Doing it in my bash script, "very odd things" (tm) happen, where it.... [00:53:47 CEST] <Psi-Jack> Well, https://paste.linux-help.org/view/801dd066 [00:54:03 CEST] <Psi-Jack> It's hard as hell to explain what's going on here... [00:54:37 CEST] <Psi-Jack> Most of all, I have no clue what that whole Enter command: <target>|all <time>|-1 <command>[ <argument>] is all about. [00:55:41 CEST] <Psi-Jack> Or why it has Press [q] to stop, [?] for help... [00:56:53 CEST] <Psi-Jack> Huh.. -nostdin solved that issue... [00:56:58 CEST] <llogan> Psi-Jack: maybe you need -nostdin [00:57:04 CEST] <Psi-Jack> heh [01:04:53 CEST] <Psi-Jack> Hmm interesting. [01:05:28 CEST] <Psi-Jack> It doesn't /entirely/ seems to copy the metadata over to the new format fully, for some odd reason. I'd thought it would but running musicbrainz on it shows a lot of metadata isn't. [01:54:35 CEST] <andrey_utkin> jkqxz, hard to imagine a fixed buffer size issue when I-frames are passed perfectly on full framerate, and even low quality low framerate P-frames even on single channel get broken instantly [01:55:47 CEST] <andrey_utkin> also it's interesting that ffmpeg dumps just few decoding errors, but in fact all the time of P-frames being enabled is distorted [01:56:33 CEST] <andrey_utkin> so maybe distortion happens before encoding, and decoding errors are unrelated to this (i.e. there are at last two separate issues) [01:57:39 CEST] <andrey_utkin> jkqxz, I appreciate your help very much, would you be so kind to hear the whole story and to help with fixing specific issues? Not for free of course. [02:37:45 CEST] <kepstin> Psi-Jack: yeah, ffmpeg doesn't copy multi-value fields properly, unfortunately [02:38:10 CEST] <Psi-Jack> Hmm yeah... [02:38:16 CEST] <kepstin> Psi-Jack: and it doesn't translate fields - picard uses different tag names in different formats in some cases, and ffmpeg tries to copy them as-is [02:38:40 CEST] <kepstin> (it translates some fields, but only the obvious common ones) [02:38:53 CEST] <Psi-Jack> Well, it does a better job than my ffmpeg to wav to stdout piped to neroAacEnc, and then going and using neroAacTag to tag it, one thing at a time. [09:50:12 CEST] <sagax> hi all! [09:50:44 CEST] <sagax> how to check that codecs and formats write? [09:50:51 CEST] <sagax> in ffmpeg [09:51:50 CEST] <sagax> i see codecs with ffmpeg -codecs and i see formats with ffmpeg -formats, but i wish check that ffmpeg see codecs and work, [09:51:55 CEST] <sagax> how to check this? [13:28:51 CEST] <jkqxz> andrey_utkin: All P frames are wrong, even if they don't get decode errors? That probably means your header is wrong somehow (maybe there is some flag not used for IDR frames which isn't right in the parameter sets, or maybe the fixed-QP isn't quite as fixed as you thought, or something else). [13:33:07 CEST] <lmeadors> \quit [13:33:37 CEST] <jkqxz> The reference decoder output made it look like there weren't any errors there, but I don't precisely remember how that works. (The trace option I was talking is compile-time in JM/ldecod/inc/defines.h. You probably want to cut the file down a bit before trying to use it, though, because the output is enormous.) [15:13:47 CEST] <frenda> Hey there [15:13:53 CEST] <frenda> for i in *.vtt; do ffmpeg -i $i $i.srt; done [15:13:59 CEST] <frenda> that does not work! [15:14:14 CEST] <ncopa> somethign like this: http://tpaste.us/AW4Y [15:15:08 CEST] <c_14> ncopa: that link went into the wrong channel, paste it again in -dev [15:15:16 CEST] <c_14> frenda: define "does not work" [15:15:31 CEST] <frenda> c_14: http://paste.ubuntu.com/15551607/ [15:15:45 CEST] <ncopa> c_14 it did. sorry [15:16:07 CEST] <frenda> -i A.vtt A.srt --> works, but, that loop does not [15:17:33 CEST] <c_14> Try enclosing $i in quotes like "$i" ? [15:19:30 CEST] <c_14> But this seems like a problem with your shell. [15:19:39 CEST] <c_14> Try replacing ffmpeg with echo and seeing what happens [15:21:12 CEST] <frenda> Ah, solved by enclosing $i; Thanks man [15:26:12 CEST] <frenda> Oops, it keeps the 'vtt' in file name! [15:26:26 CEST] <frenda> files are converted from A.vtt to A.vtt.srt, while I need A.srt [15:30:22 CEST] <c_14> "${i%%vtt}srt" [15:35:18 CEST] <frenda> c_14, Ah, life is simple now. [15:35:38 CEST] <frenda> %% or just one %?! [15:44:36 CEST] <Noturno99> hey guys, is there a way to stop ffmpeg trying to read rtmp? I get this message continuously: Trying different position for server digest! [16:01:56 CEST] <LuisM> hi folks [16:05:14 CEST] <lukesan> sorry guys, is there a way to use ffmpeg to recover an mp4 corrupted file ( "moov atom not found")? [16:06:28 CEST] <JEEB> no [16:07:00 CEST] <JEEB> it can't be automated without having a library of how different things (usually pieces of hardware) write it [16:07:09 CEST] <JEEB> and even then it's quite up to the luck :P [16:07:18 CEST] <JEEB> use movie fragments or another container than mp4 [16:14:13 CEST] <lukesan> thanks a lot JEEB [17:29:01 CEST] <fred1807> I want to write a script, that will scan a folder of videos and rename the filenames with the video resolution of each file. Can I use ffmpeg for this? What would be a ffmpeg command to return the Video Resolution only, as a single string, so I can use it as a variable ? [17:30:35 CEST] <JEEB> use ffprobe and its json output [17:30:41 CEST] <JEEB> then parse the json for the video track(s) [17:30:51 CEST] <JEEB> that would contain the resolution [17:36:48 CEST] <furq> fred1807: ffprobe -v error -of csv -select_streams v:0 -show_entries stream=height,width foo.mkv | cut -d, -f2,3 | tr , x [17:44:42 CEST] <fred1807> furq: Perfect, thank you! [17:54:01 CEST] <gnome1> nice. I've been using ffmpeg -i when I need to get some information quickly ,maybe I should be using ffprobe instead? [17:55:11 CEST] <kepstin> ffprobe can show more detailed information, and it outputs a machine-readable format useful for scripting. [17:55:45 CEST] <mr_pinc> When FFMPEG is outputing a line like - frame= 5438 fps=143 q=30.0 - what does the q= stand for? [17:56:24 CEST] <DHE> quantizer. a measure of the image quality at that moment. it's meaning is codec dependent [17:56:39 CEST] <kepstin> nominally, the quantizer picked for the frame. But it's pretty meaningless on modern codecs like h264 since it can use different quantizers for different parts of a frame. [17:57:17 CEST] <mr_pinc> Ok so if I specify - -c:v libx264 -crf 25 - how does my '25' relate to the q=300.0? [17:57:22 CEST] <mr_pinc> err q=30.0? [17:57:37 CEST] <kepstin> mr_pinc: it doesn't really relate at all. [17:58:18 CEST] <mr_pinc> ok good to know. [17:58:28 CEST] <mr_pinc> thank you [18:22:46 CEST] <xreal> What's the highest possible AAC quality to get with the GNU version ? [18:24:08 CEST] <xreal> I mean, the settings ;) [18:32:57 CEST] <kepstin> xreal: you mean, with ffmpeg's internal aac encoder? [18:34:47 CEST] <kepstin> xreal: I think you probably want to stick with the defaults for the most part, and just set a bitrate. [18:36:10 CEST] <xreal> kepstin: I've read the experimental AAC would be nice ? [18:36:15 CEST] <xreal> AAC encoder* [18:36:36 CEST] <c_14> It's not experimental anymore [18:36:49 CEST] <xreal> oooh: but it is no longer experimental and these options are unnecessary since 5 December 2015 ;) [18:36:52 CEST] <xreal> c_14: thx [18:38:01 CEST] <xreal> Trac says, VBR settings (-q:a) are experimental and likely to get even worse results than the CBR. Is this also true since 5th December ? [18:40:01 CEST] <c_14> I think that's still accurate, but am not sure. [18:45:33 CEST] <slylock105> hi guys [18:46:19 CEST] <slylock105> I am trying to convert mp3 to wav(8000hz) using ffmpeg but in one instance it truncates the wav file [18:46:32 CEST] <slylock105> can anyone suggest what I could be doing wrong [18:47:02 CEST] <slylock105> ffmpeg -i $MP3FILE -acodec pcm_s16le -ac 1 -ar 8000 $WAVFILE [18:51:28 CEST] <xreal> Hehe, playback Full HD 50i video material on an i5 is ... incredible unwatchable :) [18:51:35 CEST] <xreal> raw imagery [18:51:40 CEST] <xreal> RGB24 :) [18:55:17 CEST] <kepstin> well, 1080i50 raw should be perfectly watchable... as long as you don't want it to be deinterlaced ;) [18:58:28 CEST] <xreal> kepstin: oh yeah, playback was set to deinterlace ,) [18:58:30 CEST] <xreal> ;) [19:05:10 CEST] <xreal> Hmm.. I want to create 1080i50 mp4 from my cutting application using ffmpeg. Is it best to output uncompressed RGB24 from the application or shall I use MJPEG at 100% ? [19:34:18 CEST] <momomo> why does java redirect the ffmpeg output to the error stream ? [19:47:04 CEST] <xreal> kepstin: can I get your ideas on that ? [19:49:30 CEST] <kepstin> xreal: well, ideally your app would be outputting raw yuv420p video, since that's the format that you probably want to encode the video to. [19:49:55 CEST] <xreal> kepstin: oh, I thought RGB24 is the best format... 1 sec [19:50:19 CEST] <kepstin> if you can't do that, raw rgb and doing the conversion to yuv420p in ffmpeg would be next best, but you have to do some stuff with filters to get it to do an interlaced conversion, I think. [19:51:27 CEST] <xreal> kepstin: I can select ffmpeg video encoder in the application, but can't set yuv420p as colorspace. [19:52:57 CEST] <furq> which application [19:53:10 CEST] <xreal> furq: Magix Video Deluxe Premium 2016 [19:54:38 CEST] <xreal> The application is very acceptable for its price, but of course not "high end". [19:55:38 CEST] <furq> rgb24 might be better, it depends what you intend to do with the video [19:55:50 CEST] <furq> if you want it to be playable everywhere then you probably want yuv420p [19:56:51 CEST] <xreal> furq: Actually, I'd like to upload it to Vimeo and watch it on my Raspberry [19:57:13 CEST] <furq> there's no point using rgb then [19:57:21 CEST] <kepstin> well, vimeo's gonna re-encode it anways, but there's no benefit, yeah [19:57:28 CEST] <furq> exactly [19:57:31 CEST] <furq> it'll just make the upload take longer [19:57:49 CEST] <xreal> furq: My problem is, you CAN NOT select a color space on output. [19:57:59 CEST] <xreal> uncompressed AVI is RGB24 only. [19:58:00 CEST] <furq> can you set ffmpeg options [19:58:26 CEST] <xreal> furq: but not inside magix, only when exporting uncompressed avi using ffmpeg encoder. [19:58:38 CEST] <furq> that's what i meant [19:58:44 CEST] <xreal> furq: let me create a screenshot [19:59:08 CEST] <furq> it seems like you should be able to but i've seen a few cheap commercial NLEs and it doesn't surprise me if you can't [19:59:28 CEST] <furq> i'm not sure why i said cheap, that applies across the board really [19:59:37 CEST] <xreal> furq: http://fs5.directupload.net/images/160329/nd4nruh6.png [20:00:14 CEST] <kepstin> xreal: pick YV12, that's basically the same as yuv420p (has the u/v planes switches, but ffmpeg handles that fine) [20:00:26 CEST] <furq> i'm glad someone had that committed to memory [20:00:42 CEST] <xreal> kepstin: Thanks! [20:01:23 CEST] <furq> i420/iyuv is exactly the same as yuv420p i think [20:01:28 CEST] <kepstin> hmm, actually, you could use I420/IYUV instead, that uses the same plane order as yuv420p [20:01:35 CEST] <kepstin> either way it doesn't really make a difference [20:02:15 CEST] <xreal> Hmm... Why it bad to export to rgb24 and convert to mp4 with yuv420p later? [20:02:20 CEST] <furq> are you uploading the uncompressed video directly or is this an intermediate video for editing [20:02:36 CEST] <xreal> furq: intermediate. Magix MP4 encoder isn't THAT good ;) [20:02:41 CEST] <furq> ok good [20:02:44 CEST] <kepstin> xreal: it depends what your sources are and how the editor works internally [20:02:58 CEST] <furq> it's not bad as such, there's just no point having an rgb intermediate file if your final file is yuv420p [20:03:05 CEST] <xreal> kepstin: I think, it uses RGB24, since the native AVI export without a filter is RGB24. [20:03:07 CEST] <kepstin> if the editor works internally in rgb, then it doesn't make a difference. if the editor works internally in yuv, the conversion to rgb then back can be a bit lossy [20:03:08 CEST] <furq> yuv420p will be smaller [20:03:21 CEST] <xreal> Okay. [20:03:27 CEST] <xreal> I think, I need to do some tests for the future. [20:03:49 CEST] <xreal> Let me check what format my input material is in [20:04:27 CEST] <kepstin> (the only reason I remember that YV12 thing is that old versions of the x264 command-line encoder only supported yv12 as the raw input format) [20:06:17 CEST] <xreal> Video: MPEG4 Video (H264) 1920x1080 50fps [V: h264 high L4.2, yuv420p, 1920x1080] [20:06:24 CEST] <xreal> Wrapped in MPEG-TS [20:07:13 CEST] <furq> i should have probably guessed that from the fact that it's 1080i50 [20:07:24 CEST] <furq> i don't know where you'd find an rgb 1080i source [20:10:22 CEST] <Kuroonehalf> Hi! I need some help please. Recently I switched my streaming setup from regular OBS to OBS studio, and turns out I set different settings for my local recording than before, and it's making ffmpeg error when trying to reencode (might not be the right word here) the flv files into mp4 [20:11:54 CEST] <xreal> I'll be back in some minutes. THanks for your input ! [20:18:06 CEST] <Kuroonehalf> these new OBS settings are -> https://vgy.me/u83Xtv.png , and the command line stuff -> https://vgy.me/4HH2Zw.png [20:18:42 CEST] <Kuroonehalf> let me know if there's important information missing and/or how to obtain it [20:18:50 CEST] <furq> what options are there for video encoder in obs [20:19:04 CEST] <furq> flv seems to be flv1, which you don't want to use unless you live in 2003 [20:19:26 CEST] <Kuroonehalf> I see [20:19:36 CEST] <furq> also you were right about reencoding not being the right word, you're remuxing [20:19:56 CEST] <Kuroonehalf> ah, okay, I thought that might be the case :p [20:20:11 CEST] <Kuroonehalf> is there a way to salvage this footage? [20:20:34 CEST] <furq> does it need to be mp4 [20:21:00 CEST] <Kuroonehalf> ideally yes, as it's for use in Premiere [20:22:03 CEST] <furq> well if premiere can't import flv1 then you'll have to reencode it, presumably to h264 [20:22:25 CEST] <Kuroonehalf> could you instruct me on how I could do that? [20:23:07 CEST] <furq> ffmpeg -i src.flv -c:v libx264 -c:a copy dest.mp4 [20:23:41 CEST] <furq> assuming the source is worth salvaging, i can't imagine 1000kbps flv1 is watchable [20:24:07 CEST] <Kuroonehalf> it's from drawing streams, so 1k bitrate works fine [20:28:35 CEST] <Kuroonehalf> Kay, reencoding now. Thanks for the help o/ [20:33:03 CEST] <Kuroonehalf> By the way, do you reckon I should use one of the tuning options available? Since it's drawing, only small portions of the screen are being modified at a given time. Once every few seconds or minutes I might pan the canvas, but otherwise it's fairly static [20:34:51 CEST] <Kuroonehalf> I also have a music track overlay that updates every second with the current play time in the track [20:35:02 CEST] <Kuroonehalf> but it's really small [20:36:49 CEST] <furq> tune animation might make sense [20:58:03 CEST] <melzza> Is there a way to save directly to .ts format? I am trying to concatenate videos made from .png files. for testing purposes, i used half of the pngs to make video one and half to make video two. [20:58:42 CEST] <melzza> i followed the process from the ffmpeg website for concatenating, using 2 intermediate files. please see http://pastebin.com/iQYA3W3N [20:59:16 CEST] <melzza> but it seems like this is another step that i could avoid if i had the .ts file created instead of the .mp4 in the first steps [20:59:44 CEST] <kepstin> melzza: sure, change the file extension of the output to .ts instead of .mp4 [21:00:16 CEST] <melzza> oh, it's the easy. eek! okay [21:00:18 CEST] <melzza> thank you [21:00:23 CEST] <melzza> it's that easy* [21:00:59 CEST] <llogan> melzza: you can do it all in once command with the concat filter [21:03:01 CEST] <melzza> well, normally, i don't have the second movie available. i am making the movie based on png output that is accumulated over ~1hr of simulation. so i will make potentially one movie from N .png files. at the next hour, i would make another movie from M .png files, etc.... until I concatenate them at the end. [21:03:12 CEST] <melzza> i could not think of an easier way to do this, though i am open to ideas [21:03:24 CEST] <melzza> i am very new to ffmpeg [21:04:31 CEST] <llogan> melzza: then you can make the video segments as you did in the first two commands then use the concat demuxer to concatenate them all [21:05:32 CEST] <llogan> fewer steps [21:07:45 CEST] <melzza> hm.... okay. i apologize but totally new to this stuff. would i write a script that just busy-waits for new .png files to come into the directory and then streams them onto the end? [21:10:34 CEST] <melzza> i had looked into the demuxer, but i wasn't entirely sure how to use it for my use case -- hence i used the protocol [21:21:44 CEST] <melzza> i think that is where my confusion comes in. so say, as an example, the script sleeps for ~1hr [it's on a queuing system, so better if it just wastes a core or so]. it creates an mp4 based on the PNG files accumulated over the last 60 minutes. my confusion is where to use the demuxer. do i wait until the very end of the script and then pass it all of the mp4s, or is there a way to do it incremently? [21:22:30 CEST] <furq> use it at the very end [21:23:14 CEST] <furq> there's not really any benefit to doing it incrementally, it should be very fast even with hours of footage [21:25:08 CEST] <melzza> so are you saying just let the sim generate all of the .pngs and then call ffmpeg once at the end? Or are you saying I can still call the intermediate steps to make an .mp4 and then just concatenate once at the end? sorry - just need clarification. [21:25:48 CEST] <melzza> in this case, making the intermediate .mp4s provides the benefit that the .pngs associated with it can be deleted [21:25:53 CEST] <furq> concatenate once at the end [21:26:28 CEST] <melzza> okay -- so using the demuxer, i can keep everything in the .mp4 format? rather than doing the .ts conversion? [21:26:44 CEST] <furq> sure [21:26:56 CEST] <furq> you could just use ts for the segments though [21:28:29 CEST] <melzza> okay! is there any intuition if the protocol or the demuxer is faster (for the last step)? not sure what it's calling underneath the hood [21:29:24 CEST] <furq> the protocol is pretty much just doing cat file1 file2 > file3 [21:29:36 CEST] <furq> which is why it only works with certain containers [21:29:45 CEST] <furq> i would expect that to be faster since afaik it doesn't have to decode [21:30:20 CEST] <melzza> okay -- thanks so much for your help [21:30:58 CEST] <kepstin> well, neither the protocol or demuxer have to decode. In the protocol case, one demuxer is run over the resulting stream; in the demuxer case it opens each stream separately with its own demuxer. The perf difference should be negligible, other than differences due to the container used. [21:31:08 CEST] <xreal> furq kepstin: The file is 2 MB smaller with y420 :) [21:32:06 CEST] <xreal> furq kepstin: But it's still RGB24 1920x1080 50fps :( [21:32:16 CEST] <xreal> Seems like the app can't do the export correctly. [21:38:07 CEST] <xreal> AH! I made it work! IYUV 1920x1080 50fp [21:49:26 CEST] <Kuroonehalf> Hey Furq. I reencoded the first of those vods I asked for help with (flv1 -> libx264), and the final file size ended up 600MB. Usually these chunks of 5 hour footage, after remuxing from normal flv -> mp4, end up taking up 2 gigs. Is it normal that it became so much smaller when reencoded? :O [21:52:12 CEST] <Kuroonehalf> I think it was furq who helped me. Apologies if I mixed up the name [21:53:23 CEST] <kepstin> Kuroonehalf: h264 is a much better codec than flv1, so it's normal for the file to be smaller for the same quality [21:53:39 CEST] <Kuroonehalf> I see [21:54:09 CEST] <kepstin> (of course, you should actually check that the quality is comparable) [21:54:15 CEST] <Kuroonehalf> is there perhaps some way I could save to flv from OBS using some other better codec? Or is the flv format restricted to that? [21:54:30 CEST] <Kuroonehalf> I did, and I didn't notice any differences [21:55:08 CEST] <furq> if you can normally remux flv to mp4 then i assume it's using h264 already [21:55:10 CEST] <kepstin> Kuroonehalf: possibly. check the "Video Encoder" dropdown and see what other options are available [21:55:23 CEST] <furq> but from that options screen it looks like it's using vbr [21:55:39 CEST] <Kuroonehalf> it's constant bitrate [21:55:47 CEST] <furq> or false cbr, sure [21:55:56 CEST] <furq> for a screencast that'll be wasting bits a lot of the time [21:56:22 CEST] <Kuroonehalf> kepstin: it has this https://vgy.me/bukGvs.png [21:56:33 CEST] <Kuroonehalf> x264 encoder option [21:56:53 CEST] <kepstin> Kuroonehalf: well, that would be better than flv1 for sure :) [21:57:14 CEST] <furq> if you want the same filesize as you got from ffmpeg then disable cbr and add "-crf 23" to the x264 options [21:57:15 CEST] <kepstin> it's a program designed for streaming, so it doesn't appear to let you do crf encoding, which is a pity [21:57:19 CEST] <furq> although i think it defaults to that anyway [21:57:31 CEST] <furq> that obviously won't be cbr but i don't think it really matters that much [21:58:14 CEST] <kepstin> furq: from that screenshot, it appears to default to 1-pass vbr bitrate mode :/ [21:58:16 CEST] <furq> actually nvm that won't work [21:58:17 CEST] <furq> yeah [21:58:21 CEST] <Kuroonehalf> this won't change how flv works, right? As in, the reason I use flv is because if there's a power outage or some such disaster where the computer is shut down without warning, the video archive survives [21:58:46 CEST] <kepstin> Kuroonehalf: yeah, unlike mp4 where if the file end is missing, the video's unplayable :) [21:58:52 CEST] <Kuroonehalf> yeah [21:58:55 CEST] <furq> that's a property of the container so it'll make no difference [21:58:58 CEST] <kepstin> Kuroonehalf: that's a quirk of the mp4 container, it's unrelated to the codec [21:59:02 CEST] <Kuroonehalf> okay, just making sure [21:59:13 CEST] <JEEB> also you can go around that limitation if you use movie fragments [21:59:24 CEST] <JEEB> which makes every GOP go into its own fragment [21:59:28 CEST] <furq> assuming OBS supports that, which it probably doesn't [21:59:28 CEST] <JEEB> within the container [21:59:43 CEST] <JEEB> if it uses one of the major muxers the feature is available for it [21:59:53 CEST] <JEEB> if it has hidden it, then bad for it [22:00:17 CEST] <furq> anyway you can probably reduce the bitrate a bit, especially if you use a slower profile [22:01:19 CEST] <Kuroonehalf> usually when I stream with CPU usage = veryfast & profile = high, I average 13% CPU usage during stream [22:01:29 CEST] <furq> profile makes no difference [22:01:44 CEST] <Kuroonehalf> do you think I could increase the preset a few notches without much impact to performance? [22:01:48 CEST] <kepstin> furq: you said profile originally, did you mean preset? [22:01:53 CEST] <furq> oh [22:01:54 CEST] <furq> so i did [22:01:57 CEST] <furq> yeah i meant preset [22:02:09 CEST] <furq> try preset faster and tune animation [22:02:19 CEST] <Kuroonehalf> gonna try medium and tuned to animation next time [22:02:33 CEST] <furq> or medium, sure [22:05:05 CEST] <Kuroonehalf> hm, it seems that I can have different streaming settings than local recording. So I can do CBR for streaming but save in VBR. Would that be preferable? [22:05:53 CEST] <furq> there's no reason at all to use cbr for local recording [22:06:10 CEST] <kepstin> Kuroonehalf: x264 doesn't really support cbr, I have no idea what that checkbox does. I guess it probably sets up some vbv buffer constraints :/ [22:06:22 CEST] <furq> there's no reason to use 1-pass bitrate mode over crf either, but you don't seem to get the option [22:06:32 CEST] <Kuroonehalf> okay. CRF 23 yes? [22:06:43 CEST] <furq> i don't think that'll work [22:06:45 CEST] <hpp> there is really no need to go higher than very fast when streaming. faster preset can use twice cpu time. [22:06:57 CEST] <furq> there's no option to disable bitrate mode [22:07:19 CEST] <kepstin> for sure, enabling that 'CBR' box for a local file is probably a bad idea; would only reduce quality since bandwidth isn't an issue. [22:08:48 CEST] <xreal> Should be okay? ffmpeg -i "test.avi" -c:v libx264 -preset medium -crf 22 -c:a aac -b:a 160k test.mp4 [22:09:54 CEST] <kepstin> xreal: depends what for, but that should give you reasonable/moderate video quality at an ok encoding speed with decent audio. [22:10:39 CEST] <xreal> kepstin: the incoming quality isn't thaaat good... Panasonic Lumix, but acceptable. Thanks for your support. [22:11:33 CEST] <xreal> "rame= 3993 fps=5.6 q=30.0 size= 77593kB time=00:01:19.80 bitrate=7964.6kbits/" - why does it say q=30 ? [22:11:45 CEST] <furq> because q has nothing to do with crf [22:11:55 CEST] <xreal> oooh, I am stupid. [22:18:35 CEST] <needmorespeed> Are there H.264 encoders other than x264 that can be used with FFmpeg? [22:19:17 CEST] <xreal> Interesting. The encoded video is stuttering and the quality is worser than the direct export from Magix. Seems like crf 22 is too low [22:20:47 CEST] <JEEB> needmorespeed: yes but most likely you won't gain what you nickname says you want :P [22:20:57 CEST] <JEEB> xreal: you mean too high? [22:21:31 CEST] <JEEB> because higher = higher quant ranges are used, lower = lower quant ranges are used. and the lower you go in quants the more bits you use. [22:22:23 CEST] <xreal> JEEB: The file has less the size from Magix export. On playback of the mp4 file from FFmpeg, the CPU (i5) is at more than 65%. On playback the other file, it's around 30% [22:25:31 CEST] <xreal> Seems like there is a problem with rawvideo. [22:25:47 CEST] <xreal> Don't know if it's a problem of Magix (the outputting application) or ffmpeg [22:28:25 CEST] <carli> Hi, any way to use ffmpeg server for routing to some rtmp server? [22:31:20 CEST] <xreal> kepstin JEEB furq: rawoutput from the application seems to make the trouble. [22:49:05 CEST] <petecouture> Using ffmpeg to encode a live rtp stream into m3u8 / .ts fragements. Has anyone ever run into an issue of the system stop generating .ts fragments and then suddenyl it catches up by creating a several empty frags. Almost like the uploading speed isn't very fast. [23:05:25 CEST] <relaxed> carli: https://trac.ffmpeg.org/wiki/StreamingGuide [23:13:56 CEST] <carli> relaxed: thanks for the link, I know how to stream, I searching for some solution where webrtc is used as source for ffmpeg [23:14:28 CEST] <carli> I'm searching even .. [23:16:22 CEST] <petecouture> carli: ffmpeg can't accept webrtc as a source [23:16:49 CEST] <petecouture> You need a webrtc streaming server which converts the stream to rtp then you have ffmpeg connect ot that stream [23:16:52 CEST] <petecouture> kurento.org [23:16:57 CEST] <petecouture> is the server I'm currently using [23:19:59 CEST] <carli> petecouture: thanks [23:20:29 CEST] <petecouture> wowza is also a solution which has a lot better support but doesn't scale cost wise [23:20:53 CEST] <carli> petecouture: but if I would like tu use ffmpeg for streaming :D [23:20:56 CEST] <relaxed> carli: but you can send video to webrtc via ffmpeg [23:21:33 CEST] <kepstin> can you? does ffmpeg do dtls? [23:21:35 CEST] <carli> relaxed: I would like to send from browser to ffmpeg ... so I can save it or stream .. [23:21:59 CEST] <petecouture> relaxed: I don't think that's right. [23:22:16 CEST] <relaxed> I know it's right [23:22:47 CEST] <petecouture> how is the peer connection maintained [23:22:47 CEST] <relaxed> you can have a v4l loopback device and have ffmpeg encode to it, then webrtc will just do it's thing [23:24:01 CEST] <kepstin> carli: to send from browser to a server to record, you need to have something on the server that the browser can connect to for signalling (a webserver app, basically), and then something that handles the media bits of setting up the webrtc channel that ffmpeg doesn't support yet (this includes ICE and DTLS). after that, this app can just hand off the [23:24:01 CEST] <kepstin> decrypted rtp to ffmpeg somehow to save it. [23:24:46 CEST] <petecouture> ? but is that ffmpeg encoding directly to webrtc or is the v4l handling it. [23:25:07 CEST] <relaxed> petecouture: v4l loopback is just the proxy [23:25:29 CEST] <relaxed> oh, yes, webrtc still does the encoding [23:25:49 CEST] <kepstin> petecouture: you can do ffmpeg -> v4l loopback, then the web browser reads from the virtual loopback webcam and re-encodes the video and sends to webrtc. [23:26:08 CEST] <petecouture> Right but ffmpeg isn't doing the webrtc work [23:26:13 CEST] <petecouture> that's all I ment [23:26:15 CEST] <relaxed> correct [23:26:19 CEST] <kepstin> yeah, the browser does in that case. [23:27:22 CEST] <kepstin> there's enough corner cases and weird interop things in webrtc that if you want to send to webrtc from a app that's not a browser, you probably want to do it via the webrtc library extracted from chromium :/ [23:28:39 CEST] <carli> Ok, back to start :( [23:28:43 CEST] <petecouture> carli: Just a heads up, the webrtc to ffmpeg output is a bit of a pain to get right. [23:29:12 CEST] <petecouture> Very little documentation on it out there. Let me know if you want some pointers [23:29:12 CEST] <carli> petecouture: i need webrtc in input ... [23:29:37 CEST] <carli> petecouture: not output [23:29:47 CEST] <petecouture> That's what I'm taking about [23:29:50 CEST] <petecouture> webrtc source [23:30:01 CEST] <carli> petecouture: ok [23:30:21 CEST] <carli> Thank you all! [23:30:24 CEST] <petecouture> but you have to have a webrtc streaming server that converts webrtc to rtp [23:30:30 CEST] <petecouture> then you can use that as the source for ffmpeg [23:31:02 CEST] <petecouture> with rtp you'll need to understand sdp and offer/response hand shaking [23:31:21 CEST] <petecouture> Kurento and Wowza are the two everyone is using these days [23:31:40 CEST] <carli> petecouture: ye I understand that, well if I use some streaming services, I don't need ffmpeg :D [23:31:59 CEST] <petecouture> if you're just looking to save the media to disk [23:32:02 CEST] Action: kepstin uses freeswitch for some of that stuff - it can accept a webrtc call, and record to a local file using ffmpeg as a library. [23:32:13 CEST] <kepstin> (but that might be more complicated than you need) [23:32:20 CEST] <petecouture> I'd recommend looking at kurento. It's pretty easy to setup a save to disk from a webrtc feed [23:32:49 CEST] <carli> petecouture: well all of them offers some space there, so they save streams directy to files ... [23:33:57 CEST] <petecouture> kepstin: thanks for that. I'm having issues with my stream being recorded right via kurento. [23:36:14 CEST] <carli> kepstin: so you can stream that call to rtmp :D [23:37:12 CEST] <kepstin> carli: freeswitch can in fact do that; they have their dev calls in a webrtc conference that's broadcast live on youtube :) [23:39:20 CEST] <carli> kepstin: Need to check this :D Thanks! [23:41:20 CEST] <Zeranoe> Is it possible to cat/type a file to FFmpeg so that it is not doing the file reading itself? [23:42:21 CEST] <kepstin> Zeranoe: yes. [23:42:29 CEST] <andrey_utkin> Zeranoe, cat file | ffmpeg -i - ... [23:43:14 CEST] <carli> One other question, for streaming mp4 file to rtmp size: Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080, 4218 kb/s, 25 fps, 25 tbr, 25k tbn, 50 tbc (default), what are CPU requirements ? [23:43:41 CEST] <kepstin> carli: you don't need to re-encode that, so cpu requirements are minimal [23:44:30 CEST] <Mavrik> yeah, no point in reencoding that [23:45:23 CEST] <carli> Damn so I need to find out what takes my CPU to the sky ... [23:45:27 CEST] <carli> Thanks! [23:46:48 CEST] <kepstin> carli: if you're not using -c:v copy, it will re-encode it... you need to show us your complete command line if you want more help :) [23:48:41 CEST] <carli> kepstin: ye here is the line: ffmpeg -re -i inputfile.mp4 -f flv -vcodec libx264 -r 20 -c:a libfdk_aac -b:a 128k -ac 2 rtmp://server.com [23:49:24 CEST] <carli> I tester with 10fps and it's the same thing .. [23:49:28 CEST] <carli> tested even [23:50:06 CEST] <llogan> the encoding is what makes your CPU work so hard [23:51:09 CEST] <carli> flv or ? [23:52:07 CEST] <relaxed> you can copy the audio/video streams while only changing the container [23:52:24 CEST] <relaxed> ffmpeg -re -i inputfile.mp4 -f flv -c copy rtmp://server.com [23:52:27 CEST] <petecouture> I think you can just copy each codec instead of reencoding. Seems like a waste there [23:52:31 CEST] <petecouture> damn relaxed beat me to it [23:53:41 CEST] Action: relaxed holsters [23:54:10 CEST] <carli> Let me test this .. [23:54:18 CEST] <carli> Thanks! [23:55:48 CEST] <carli> Huh! It works, so it's better that I convert other files before stream! [23:55:56 CEST] <carli> Thank you all! [23:56:09 CEST] <relaxed> you're welcome [00:00:00 CEST] --- Wed Mar 30 2016

1 0

ffmpeg-devel.log.20160328
by burek 29 Mar '16

29 Mar '16

[01:15:44 CEST] <cone-965> ffmpeg 03Timo Rothenpieler 07master:665c05f7cb70: configure: Fail if CUDA enabled but not found [01:48:44 CEST] <BtbN> wow, merging even a single trivial commit is a pain. [01:59:28 CEST] <jamrial> where? [02:08:05 CEST] <BtbN> Already sorted it, cherry-picking was a bit easier than merging. [02:08:22 CEST] <BtbN> Want to mess with this a bit: https://git.libav.org/?p=libav.git;a=commit;h=07a844f32ebb78503981df017fa3e… [02:09:23 CEST] <nevcairiel> merging is hard because it requires everything to be merged in order [02:09:30 CEST] <nevcairiel> getting single commits, thats what cherry-pick is for [02:09:53 CEST] <BtbN> Pushing that single one would mess with the merges though? [02:38:50 CEST] <BtbN> Great: "In the current version, the cuda context MUST be created from a D3D device, using cuD3D9CtxCreate function." [02:38:54 CEST] <BtbN> So much about that [02:41:46 CEST] <BtbN> http://docs.nvidia.com/cuda/video-decoder/ says otherwise... so the docs in their headers are outdated i guess? oO [02:42:21 CEST] <jamrial> BtbN: you can send a patch based on a libav commit to the ml for review and apply it. once it comes out in the merge queue it will simply get no-op'd [02:42:49 CEST] <BtbN> I primarily want this because it gives downloading of CUDA frames. [02:43:17 CEST] <BtbN> I'm fine with keeping it in my own branch for now. [02:43:36 CEST] <BtbN> Those two patches are probably somewhat controversial [05:03:36 CEST] <cone-192> ffmpeg 03Michael Niedermayer 07master:8f2a1990c06d: avcodec/diracdec: check bitstream size related fields for overflows [08:10:05 CEST] <midgetspy> Could somebody please do me a favor and forward http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/192207.html to the thread author (me, nic(a)wolfeden.ca)? I mistakenly thought I'd receive replies to my thread without being subscribed to the list, now I've subscribed but I can't figure out how to reply to that thread without having received the message originally. Thanks. [10:15:58 CEST] <cone-702> ffmpeg 03Matthieu Bouron 07master:308d3ed5aa3a: lavc/mediacodec: use ternary operator to set slice-height value [10:32:00 CEST] <Gramner> midgetspy: click on the e-mail address mailto link at the top of that page to reply with the correct headers [10:53:20 CEST] <cone-702> ffmpeg 03Paul B Mahol 07master:ff982e02b547: avcodec: add dca core extraction bsf [10:56:32 CEST] <nevcairiel> durandal_1707: you should really wait until someone reviews your code before pushing it, its only been about half a day and its the easter holidays... [10:57:06 CEST] <durandal_1707> its trivial code [10:57:44 CEST] <durandal_1707> jamrial have tested it [10:58:32 CEST] <durandal_1707> so only name can be changed if you prefer something else... [11:51:26 CEST] <ethe> michaelni: coc looks fine now [12:17:27 CEST] <JEEB> wow [12:17:43 CEST] <JEEB> just noticed the dict API change [12:18:59 CEST] <Mavrik> The one with duplicate key support? [12:22:27 CEST] <JEEB> yeah, or well the thread about it [12:23:04 CEST] <JEEB> > someone voices concerns > still pushed purely based on time (Ž4@) [12:23:56 CEST] <Mavrik> Yeah that's... fun. [12:24:10 CEST] <Mavrik> I'm now looking at the mediacodec patch... and I see much fun with AllWinner and MediaTek crap in the future. [12:24:15 CEST] <JEEB> yeah [12:24:19 CEST] <JEEB> I chuckled when I saw that [12:25:10 CEST] <nevcairiel> thats why mediacodec is crap [12:25:14 CEST] <nevcairiel> its api gets violated so much [12:25:40 CEST] <JEEB> also how things fail is completely dependant on the layer implementing it [12:25:48 CEST] <Mavrik> I think it's quite telling about the skill of Google devs that we got API to check for number of HW decoders in Android N :P [12:26:24 CEST] <JEEB> I totally understand why things have their own profile/level checks before passing stuff to the hwdec at all [13:30:26 CEST] <ubitux> mmh [13:30:39 CEST] <ubitux> i'm thinking of using av_codec_get_pkt_timebase() in lavc/ccaption_dec [13:30:47 CEST] <ubitux> instead of avctx->time_base [13:30:54 CEST] <ubitux> which seems to do the trick in the codecpar branch [13:31:02 CEST] <ubitux> would this be ok? [13:49:30 CEST] <ubitux> ooh i can do much better [14:17:18 CEST] <ubitux> huh, one patch didn't reach the ml [14:17:56 CEST] <ubitux> ah now it did [14:20:15 CEST] <ubitux> Daemon404: ccdec fixed in codecpar [14:22:03 CEST] <JEEB> nice [14:22:54 CEST] <ubitux> (as soon as the patch on the ml are applied and cherry-picked back into codecpar) [14:39:17 CEST] <durandal_170> BBB: whar have you done with colomatrix filter? [14:39:29 CEST] <BBB> context? [14:40:09 CEST] <durandal_170> BBB: patches on ml [14:40:40 CEST] <BBB> I didnt do anything, someone else sent patches and Im commenting on them, right? [14:40:46 CEST] <BBB> like, review [14:40:53 CEST] <BBB> and I havent approved any yet, have I? [14:45:15 CEST] <durandal_170> BBB: guy said that he will not work on it anymore [14:45:26 CEST] <BBB> yeah I just noticed that [14:45:32 CEST] <BBB> how about I finish the patch? [14:45:47 CEST] <BBB> his approach was mostly OK, I can do the templating and DSPization myself [14:45:57 CEST] <durandal_170> you mentioned something about simd [14:46:12 CEST] <JEEB> also you can test it against the zscale filter which also has colorspace conversions between, say, BT.709 and BT.2020 [14:46:31 CEST] <durandal_170> so just go ahead and finish it [14:46:33 CEST] <BBB> ok, so, a few things [14:46:37 CEST] <BBB> durandal_170: yes boss [14:46:51 CEST] <BBB> A) I am not testing against zscale, I want external libs to die, especially libxyz ones [14:46:57 CEST] <BBB> I fundamentally dont believe in them [14:47:03 CEST] <BBB> I dont want to install crap like that on my system [14:47:08 CEST] <JEEB> ok [14:47:20 CEST] <BBB> B) colormatrix is fundamentally broken, it doesnt convert between RGB spaces [14:47:21 CEST] <durandal_170> BBB: I'm not your boss [14:47:38 CEST] <BBB> i.e. it assumes that all matrix coefficients between XYZ/RGB are equal between colorspaces, which they are not [14:47:45 CEST] <BBB> not to mention gamma differences [14:48:10 CEST] <BBB> C) ideally all of this would live in swscale, if it wasnt for the fact that swscale is rotten as hell [14:48:13 CEST] <JEEB> zimg basically replaced swscale in vapoursynth [14:48:17 CEST] <BBB> so& more constructively [14:48:20 CEST] <durandal_170> mpv have code that does it correctly [14:48:21 CEST] <JEEB> which is what zscale uses [14:48:37 CEST] <BBB> I have a lot of code that corrects the XYZ/RGB issue [14:49:04 CEST] <BBB> its not finished but I guess I should just finish it [14:49:43 CEST] <BBB> it would still make it a two-stage process to convert from any to any, youd need both swscale as well as colormatrix [14:49:50 CEST] <BBB> but at least it does the theoretically correct thing [14:49:55 CEST] <JEEB> yeah [14:50:07 CEST] <BBB> at some point years ago I wrote a complete scaling library that replaced swscale to do all of this in one place [14:50:12 CEST] <BBB> I actually called it avscale also :-p [14:50:15 CEST] <BBB> but that name is taken now [14:50:38 CEST] <JEEB> well that never saw the light of day as far as I've seen so people made their own things for that [14:50:46 CEST] <BBB> but I forgot where I put that code. it was pretty good but particular optimized paths were not as fast (by design) as swscale and fixing that would involve lots of hacks, so I eventually lost interest [14:51:04 CEST] <BBB> and now I dont remember where it is anymore [14:51:15 CEST] <BBB> I might have deleted it& I probably have backups but I cant be bothered [14:51:18 CEST] <JEEB> and in the end zimg seemed to be the least retarded and generic [14:51:59 CEST] <BBB> what you want is a any-range | any-colorspace | any-size < to > any-range | any-colorspace | any-size, right? [14:52:21 CEST] <JEEB> the author is a troll of course, so I can understand not wanting anon32 code on one's machine :D (also he seems to be against enabling x86 SIMD by default for whatever reason) [14:52:25 CEST] <BBB> with optimal precision, least rounding artifacts, little intermediates, etc. [14:53:35 CEST] <JEEB> https://github.com/sekrit-twc/zimg but yeah, this seems to do the general cases [14:54:01 CEST] <BBB> so you want to use zscale? or you want to extend colormatrix? or you want to rewrite avscale? [14:55:22 CEST] <JEEB> I would at this point say that it should be looked into if zimg could be used or just taken into FFmpeg on the longer run. on the shorter run I guess fixing colormatrix could be a good thing [14:56:03 CEST] <JEEB> and my original comment regards testing against zscale meant that you could check the results against it if you wanted - without any further meaning :P [14:56:16 CEST] <JEEB> since "hey, there's another filter that can do that stuff probably too" [14:56:50 CEST] <BBB> I dont think we should take zimg [14:57:02 CEST] <JEEB> yeah, it's basically herecy due to C++ [14:57:02 CEST] <BBB> zimg is just another swscale piece of shit that will end up being unmaintained and hated [14:57:25 CEST] <JEEB> ok [14:57:30 CEST] <BBB> well c++ doesnt help either :-p [14:57:34 CEST] <BBB> let me start with colormatrix [14:57:58 CEST] <BBB> shall I work on top of thomasz patches? [14:58:11 CEST] <BBB> its only fair we attribute him for the work he did, I mean, he did put in quite some effort it seems [14:58:16 CEST] <JEEB> yeah [14:58:42 CEST] <BBB> but so, a funny thing about colormatrix is that youre alreading seeing its design limitations: every colorspace needs new functions [14:58:43 CEST] <Gramner> I've never looked at the swscale source code, what's the problem with it? poor design, or just generally code quality issues? [14:58:45 CEST] <BBB> its not generic at all [14:58:54 CEST] <BBB> Gramner: why dont you have a look :-p [14:59:07 CEST] <BBB> I recommend starting with the rgb2yuv or yuv2rgb code paths [15:00:22 CEST] <BBB> I recommend trying to figure out the difference between (or the need for) SWS_FULL_CHR_H_INP and _INT, and then figuring out where yuv/rgb conversion coefficients are stored, how a user sets them and when they are honoured vs. when they are not (bonus points if you can do this for the mpegrange/fullrange flag) [15:00:32 CEST] <kierank> BBB: colormatrix is gpl so maybe not the best place to start [15:00:38 CEST] <BBB> ??? [15:00:40 CEST] <BBB> really [15:00:43 CEST] <BBB> I didnt know that [15:00:58 CEST] <kierank> iirc yes because it came from avisynth origianlly [15:01:07 CEST] <BBB> ok so thats not happening then [15:01:11 CEST] <BBB> let me start from scratch [15:01:18 CEST] <BBB> I can probably rewrite it in a few minutes [15:07:10 CEST] <durandal_170> I wanted to rewrite it too [15:07:30 CEST] <durandal_170> using mpv as reference [15:09:52 CEST] <durandal_170> it uses primaries for constructing matrix [15:10:36 CEST] <durandal_170> It's smile matrix operations [15:10:44 CEST] <durandal_170> *simple [15:41:20 CEST] <kierank> J_Darnley: ping [15:44:04 CEST] <kierank> https://www.irccloud.com/pastebin/Q5chYDZK/ [15:44:12 CEST] <kierank> is it possible to SIMD that? [15:49:03 CEST] <J_Darnley> oh my, 10-bit packing [15:49:04 CEST] <nevcairiel> looks possible, although maybe not incredibly efficient [15:49:06 CEST] <J_Darnley> maybe [15:49:17 CEST] <J_Darnley> someone did manage to write it for v210 [15:49:30 CEST] <kierank> yeah but v210 has some level of alignment [15:49:34 CEST] <kierank> raw 10-bit doesn't [15:49:39 CEST] <J_Darnley> oh [15:50:00 CEST] <J_Darnley> yes 2 bits of padding for every 3 samples [15:51:13 CEST] <kierank> I also don't need to worry about interleaving chroma actually because the actual pixelformat is uyvy422-10bit [15:51:19 CEST] <kierank> but I don't want to add that to libavutil [15:56:10 CEST] <kierank> I guess I should do it in groups of 15 bytes [15:56:36 CEST] <kierank> 120-bits so 12x 10-bit words [16:14:12 CEST] <Daemon404> ubitux, cool [16:22:03 CEST] <midgetspy> Gramner: Thanks, I did see that link but in Outlook and gmail it didn't set my In-Reply-To header correctly and I couldn't find any way to force it. Forwarding the actual message preserves the In-Reply-To/References headers which should work. [16:32:56 CEST] <wm4> ubitux: heh, I think your timebase patches would break mpv? [16:33:37 CEST] <wm4> it doesn't copy the whole avcodeccontext from an AVStream, only select fields [16:34:57 CEST] <durandal_170> kierank: have you tried zoneplate source filter? [16:35:56 CEST] <kierank> I will do it at work [16:40:34 CEST] <ubitux> wm4: what would break? [16:40:39 CEST] <ubitux> ccaption? [16:41:01 CEST] <ubitux> or the legacy timing? [16:41:29 CEST] <wm4> I'm not sure [16:41:46 CEST] <ubitux> i mean which patch you think is going to break? [16:42:06 CEST] <wm4> currently my code sets the AVCodecContext.time_base [16:42:19 CEST] <wm4> if your patch changes it to pkt_timebase, wouldn't that break? [16:42:38 CEST] <wm4> at the very least it'd error-out [16:43:29 CEST] <ubitux> pkt_timebase is already used everywhere in the subtitles rescaling [16:43:52 CEST] <ubitux> do you set AVCodecContext.time_base to sth different than the stream tb? [16:44:04 CEST] <wm4> which stream tb [16:44:09 CEST] <ubitux> stream->time_base [16:44:26 CEST] <wm4> I send packets with timestamps according to AVCodecContext.time_base if you mean that [16:45:57 CEST] <ubitux> when a demuxer create a new stream and set the timing info, it seems to actually set the pkt_timebase [16:46:00 CEST] <ubitux> this is what i use now [16:46:22 CEST] <wm4> well I'm not using the API like ffmpeg.c does... [16:46:42 CEST] <ubitux> sure, but, what timebase value are you setting then? [16:46:52 CEST] <wm4> AVCodecContex.time_base [16:46:59 CEST] <ubitux> yes but to what value? [16:47:04 CEST] <wm4> 1/1000 [16:47:09 CEST] <ubitux> ah [16:48:23 CEST] <ubitux> why :( [16:48:29 CEST] <wm4> why not? [16:48:39 CEST] <wm4> I think I even asked whether it's right to set time_base [16:49:38 CEST] <ubitux> are you still using the old ass timing or you switched that? [16:49:48 CEST] <wm4> still the old one [16:49:52 CEST] <ubitux> mmh [16:50:12 CEST] <wm4> (no reason to switch until I actually get all timings in the correct time base) [16:50:33 CEST] <ubitux> so, so far, it seems there is only 2 remaining usage of avctx->time_base for subtitles [16:50:47 CEST] <ubitux> and that's the 2 things i changed in these patches [16:51:34 CEST] <ubitux> (1. the timing rescale for the deprecated ass payload 2. ccaption dec) [16:51:44 CEST] <ubitux> everything else is using pkt_timebase [16:52:05 CEST] <ubitux> it's strange that you get it working as expected with 1/1000 [16:52:54 CEST] <wm4> why is it strange? [16:53:15 CEST] <ubitux> because most of the subtitles code is using pkt_timebase [16:59:08 CEST] <ubitux> wm4: typically for bitmap subs your avctx->time_base will be ignored for instance [16:59:22 CEST] <ubitux> (afaict) [17:00:18 CEST] <wm4> that's because they either pass through the timestamp, or use a fixed timebase [17:00:33 CEST] <wm4> the only place where I have this problem are subtitle converters [17:01:32 CEST] <kierank> J_Darnley: seems to be possible in the same way as v210 [17:02:02 CEST] <kierank> load, copy, variable shift (pmullw), pxor [17:02:07 CEST] <kierank> 4:01 PM <"kierank> J_Darnley: seems to be possible in the same way as v210 [17:02:42 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/4M1Ff8nt/ [17:02:49 CEST] Action: kierank writes enterprise simd [17:05:20 CEST] <J_Darnley> good [17:05:36 CEST] <J_Darnley> and sorry for the disconnects [17:05:59 CEST] <J_Darnley> This is the level of service my ISP provides during "business hours" [17:10:25 CEST] <kierank> going to be headache inducing though [17:10:29 CEST] <kierank> three loads for every store [17:10:40 CEST] <kierank> loads of 128*3 bits to write 120bits [17:12:52 CEST] <wm4> just wondering, would it be easier to generate such code with a script? [17:13:47 CEST] <kierank> dunno maybe [17:14:25 CEST] <kierank> a two loads per store, not so bad [17:46:04 CEST] <cone-033> ffmpeg 03Paul B Mahol 07origin/release/3.0:HEAD: avcodec: add dca core extraction bsf [17:49:11 CEST] <atomnuker> michaelni: which branch do I backport the aacenc fixes for 3.0.1? [17:49:53 CEST] <michaelni> to release/3.0, also use cherry-pick -x so the hash from the source commit is in it [17:58:52 CEST] <cone-033> ffmpeg 03Ganesh Ajjanagadde 07release/3.0:7c2576e15d32: lavc/aacenc_utils: replace sqrtf(Q*sqrtf(Q)) by precomputed value [17:58:53 CEST] <cone-033> ffmpeg 03Reimar Döffinger 07release/3.0:1cbe4ff2acdd: aacenc: avoid double in quantize_bands. [17:58:54 CEST] <cone-033> ffmpeg 03Reimar Döffinger 07release/3.0:b176ab055691: aacenc_utils: Use temporary variable. [17:58:55 CEST] <cone-033> ffmpeg 03Ganesh Ajjanagadde 07release/3.0:f281cb4ea93d: lavc/aacenc_utils: replace powf(x,y) by expf(logf(x), y) [17:59:46 CEST] <cone-033> ffmpeg 03Rostislav Pehlivanov 07release/3.0:6cb5bbc66024: Changelog: update for 3.0.1's aacenc optimizations [18:02:08 CEST] <kierank> Gramner: are the variable shifts in avx2 any good? [18:02:24 CEST] <kierank> instead of pmullw (2^n) [18:03:56 CEST] <Gramner> they accomplish the same thing essentially in most cases, assuming the shift amount is constant [18:04:12 CEST] <Gramner> they're useful if you have calculated shift amounts though [18:05:30 CEST] <cone-033> ffmpeg 03Rostislav Pehlivanov 07release/3.0:f01919b57af0: vc2enc: correctly zero out coefficient array padding [18:05:31 CEST] <cone-033> ffmpeg 03Rostislav Pehlivanov 07release/3.0:3d9ebfd27264: Changelog: update for 3.0.1's vc2enc fixes [18:08:56 CEST] <Angus__> Is anyone here familar with struct URLProtocol? [18:10:03 CEST] <cone-033> ffmpeg 03Paul B Mahol 07master:c2bbcf16077b: avfilter/vf_waveform: optimize 16bit lowpass filter [18:20:37 CEST] <ubitux> Daemon404: so mov is supposed to be fixed? [18:21:04 CEST] <ubitux> binsub-movtextenc is still failing, i'm wondering if the issue is within mov or the encoder [18:21:16 CEST] <ubitux> or maybe demux/decoder [18:22:15 CEST] <Daemon404> ubitux, i bet it is the same as all the other mov failures [18:22:17 CEST] <Daemon404> fiel atom [18:22:27 CEST] <Daemon404> nevcairiel explained it a few days back. [18:22:36 CEST] <ubitux> ok i'll grep my logs [18:22:38 CEST] <ubitux> thx [18:23:33 CEST] <ubitux> it seems to be in the tkhd atom though [18:23:55 CEST] <Daemon404> ubitux, easy way to check is to use boxdumper [18:23:58 CEST] <Daemon404> and diff outout [18:24:01 CEST] <Daemon404> thats what i did [18:24:22 CEST] <Daemon404> boxdumper oldfateoutput.mov > src.txt [18:25:04 CEST] <JEEB> yeah, boxdumper is quite useful [18:25:06 CEST] <Daemon404> you could simply be seeing the atom size changes due to nesting [18:26:14 CEST] <ubitux> lol, it's width/height [18:27:30 CEST] <ubitux> so width/height are missing for the subtitles track [18:27:39 CEST] <ubitux> meh. [18:28:28 CEST] <Daemon404> er what? [18:30:33 CEST] <ubitux> the original mp4 has a tx3g stream with width=400 height=60 [18:30:41 CEST] <ubitux> when transcoding, this information is now lost [18:30:51 CEST] <ubitux> maybe codecpar->{width,height} are copied only for video? [18:31:01 CEST] <nevcairiel> check the code and add it if needed [18:31:03 CEST] <nevcairiel> its possible [18:31:11 CEST] <nevcairiel> subtitle support is pretty limited in libav afterall [18:42:20 CEST] <BtbN> Hm, if I cherry-pick a new file from libav, do I keep their file-header, or do I replace it with the ffmpeg one? (Keeping license and author of course) [18:42:37 CEST] <Daemon404> :%s/Libav/FFmpeg/ [18:42:59 CEST] <Daemon404> since the file is now a part of a different project [18:43:14 CEST] <ubitux> can we get done with codecpar asap? :( [18:43:39 CEST] <Daemon404> ubitux, after subtitles, most of what's left is slightly over my head [18:43:51 CEST] <Daemon404> like voc [18:44:23 CEST] <ubitux> we're now 150+ commits behind [18:44:37 CEST] <Daemon404> behind libav? [18:44:38 CEST] <Daemon404> or ffmpeg? [18:44:54 CEST] <ubitux> libav has 150+ commits not merged [18:45:11 CEST] <ubitux> in ffmpeg [18:45:16 CEST] <Daemon404> wm4 / nevcairiel - can we hunker down then? [18:45:32 CEST] <Daemon404> i really am not capable of figuring out one or three of some stuff [18:45:41 CEST] <nevcairiel> i dont see how the number of commits makes any difference [18:45:55 CEST] <nevcairiel> 30 of those are cleanup of svq3, etc [18:46:08 CEST] <Daemon404> sure [18:46:13 CEST] <Daemon404> but i still would lik to get tep2 done [18:46:18 CEST] <Daemon404> it haunts me [18:46:30 CEST] <nevcairiel> like I said the other day, libav prepared for this over months, dont expect to get it done quickly [18:46:41 CEST] <Daemon404> there's a difference bteween not doing it quickly [18:46:43 CEST] <Daemon404> and nothing for weeks [18:50:25 CEST] <Daemon404> booting my dev vm for ffmpeg, will hack on some stuff [18:52:10 CEST] <ubitux> st->codecpar->{width,height} are properly set in the demuxer, but aren't in the muxer [18:52:15 CEST] <ubitux> any idea where that information could be lost? [18:52:39 CEST] <nevcairiel> it translates to avctx in between, check the translation code, like Daemon404 said, its probably not set for subtitles [18:52:51 CEST] <nevcairiel> (or copied for that matter) [18:53:30 CEST] <nevcairiel> its in avcodec/utils.c [18:53:55 CEST] <ubitux> ah, perfect [18:53:57 CEST] <ubitux> thanks [18:54:45 CEST] <nevcairiel> Daemon404: there is a few "simple" open questions, like what happens with has_b_frames, could introduce a new element with a more appropriate name in codecpar that conveys the decode delay information that has_b_frames previously included [18:55:06 CEST] <Daemon404> i thought we agreed on that [18:55:15 CEST] <Daemon404> but there's als oa bunch of work unrelated to bframes [18:55:25 CEST] <nevcairiel> i dont remember anyone agreeing, just people throwing around ideas [18:55:35 CEST] <Daemon404> im perfectly fine with some sort of delay entry [18:55:41 CEST] <Daemon404> i thought wm4 was too [18:56:03 CEST] <nevcairiel> fiel will probably be annoying [18:56:18 CEST] <Daemon404> i know [18:56:26 CEST] <nevcairiel> could add some ugly hack to check avctx [18:56:32 CEST] <nevcairiel> under deprecation guards [18:56:41 CEST] <Daemon404> because we change stream-level stuff after alreadfy muxing some packets, if i understand? [18:56:47 CEST] <nevcairiel> yes [18:56:56 CEST] <nevcairiel> which kind-of works for mov since it writes headers at the end [18:56:59 CEST] <Daemon404> we could queue some packets after reading some in ffmpeg.c [18:57:03 CEST] <Daemon404> and then set it [18:57:06 CEST] <Daemon404> and then write the header [18:57:18 CEST] <nevcairiel> any changes to ffmpeg.c would be bad [18:57:22 CEST] <nevcairiel> breaks api still for anyone else [18:57:34 CEST] <Daemon404> that's only true if the api was actually validand documented [18:58:18 CEST] <nevcairiel> you could also just ignore it then, as it fixes itself when ffmpeg.c siwtches to codecpar [18:58:35 CEST] <Daemon404> does it? [18:58:39 CEST] <nevcairiel> of course [18:58:56 CEST] <Daemon404> i did switch field_order to codecpar (you had me revert it), but i didnt fix it [18:58:58 CEST] <nevcairiel> the problem only exists because the compat code that generates codecpar is only run once [18:59:06 CEST] <Daemon404> right [18:59:10 CEST] <ubitux> is it ok to copy sar in addition to width/height for subtitles? [18:59:28 CEST] <wm4> never seen sar applied to subtitles [18:59:34 CEST] <Daemon404> ubitux, if it's in codecpar, i dont see why it would be wrong. [18:59:35 CEST] <wm4> (although the _video_ sar might matter) [18:59:37 CEST] <Daemon404> but yeah what wm4 said [18:59:40 CEST] <nevcairiel> Daemon404: thats because https://github.com/dwbuiten/FFmpeg/commit/435bc7ff51c9bba5bd475486ab8c45417… was wrong in many ways. ;) [18:59:58 CEST] <Daemon404> it's reverted ;) [19:00:02 CEST] <nevcairiel> i know [19:00:08 CEST] <nevcairiel> but it didnt fix anything because you switched it only half [19:00:09 CEST] <Daemon404> this is also why i said i need help [19:00:28 CEST] <Daemon404> for now, ill ignore fiel then [19:00:34 CEST] <ubitux> even for bitmaps? [19:00:37 CEST] <nevcairiel> would be nice to get those fails out of the list [19:00:40 CEST] <Daemon404> true [19:00:49 CEST] <Daemon404> but i am not qualified to fix ffmpeg.c [19:00:54 CEST] <Daemon404> as you have shown. [19:01:01 CEST] <ubitux> anyway, i fixed binsub-movtextenc, thanks for the hints [19:01:30 CEST] <Daemon404> ill take a look at the ogg one [19:01:33 CEST] <Daemon404> which i am sure ill regret [19:01:34 CEST] <nevcairiel> maybe it would be best to just add some magic code movenc to re-read fiel from the deprecated avctx before writing headers [19:01:35 CEST] <Daemon404> because ogg [19:02:01 CEST] <nevcairiel> slightly ugly but preserves behavior [19:02:04 CEST] <Daemon404> nevcairiel, under deprecation guards? [19:02:07 CEST] <nevcairiel> of course [19:02:15 CEST] <Daemon404> i am not opposed [19:02:22 CEST] <Daemon404> since it is then deprecated properly [19:02:24 CEST] <nevcairiel> anyway dinner time [19:02:31 CEST] <nevcairiel> i might have time to work on things tomorrow [19:02:34 CEST] <Daemon404> ok [19:02:36 CEST] <nevcairiel> nto tonight tho [19:02:39 CEST] <Daemon404> i have time all week. [19:02:48 CEST] <Daemon404> i can dedicate some work time to it. [19:03:30 CEST] <Daemon404> i will add movenc.c stuff today then [19:03:48 CEST] <Daemon404> then most of the failures left will be odd one-offs [19:03:49 CEST] <Daemon404> i think. [19:04:46 CEST] <ubitux> oh it fixed sub2video too [19:04:53 CEST] <Daemon404> :) [19:06:08 CEST] <Daemon404> ubitux, btw do you mind helping out with merges once tep2 is in, to get caught up [19:06:15 CEST] <Daemon404> a good chunk of them will just be monkey work [19:06:17 CEST] <ubitux> yes [19:06:38 CEST] <Daemon404> there's a few important ones [19:06:44 CEST] <Daemon404> hwaccel stuff [19:06:45 CEST] <ubitux> i'm in holiday tomorrow and the day after [19:06:54 CEST] <ubitux> but i suppose codecpar won't be in? [19:06:56 CEST] <ubitux> :( [19:07:17 CEST] <Daemon404> probably not, but if we can make fate pass, maybe nevcairiel will get motivated again [19:07:20 CEST] Action: Daemon404 runs [19:07:51 CEST] <ubitux> wm4: can you check if the ccaption patch (only) is breaking something for you? [19:07:58 CEST] <wm4> btw. one thing I noticed about fate is that not all it testes and expects is actually sane [19:08:12 CEST] <wm4> ubitux: git branch? [19:08:14 CEST] <ubitux> for the legacy rescaling i might just make a fallback to pkt timebase if avctx tb isn't set [19:08:19 CEST] <Daemon404> wm4, yes thats why i updated several tests [19:08:24 CEST] <ubitux> wm4: will push somewhere, just a moment [19:08:25 CEST] <Daemon404> the reslt after codecpar was *more* correct [19:10:06 CEST] <ubitux> wm4: https://github.com/ubitux/FFmpeg/compare/ccaption-tb [19:17:06 CEST] <ubitux> keeping our HEAD chunks from fate-wtv-demux test makes fate pass here [19:17:11 CEST] <ubitux> so i'll commit that [19:17:15 CEST] <wm4> ubitux: still seems to work [19:17:36 CEST] <Daemon404> ubitux, HEAD chunks? [19:17:59 CEST] <Daemon404> merge conflict in the fate test? [19:18:03 CEST] <ubitux> http://sprunge.us/iXfe [19:18:10 CEST] <Daemon404> ok [19:18:14 CEST] <Daemon404> if HEAD is fine, it's not a problem [19:18:51 CEST] <ubitux> wm4: cool; i'm going to pick the 2nd commit and ask you to try if it breaks; if it does i'll try to amend something and ask for a test again [19:18:53 CEST] <ubitux> if you don't mind [19:19:23 CEST] <Daemon404> nevcairiel / wm4 / ubitux - btw, i am assumign we will just noop all the 10ish+ commits after the TEP2 commit in libav which are switching e.g. avconv to codecpar [19:19:27 CEST] <Daemon404> since well do that [19:19:48 CEST] <ubitux> ? [19:19:56 CEST] <Daemon404> avconv: convert to codecpar [19:19:59 CEST] <Daemon404> commits like that [19:20:08 CEST] <Daemon404> not useful to us, sinde we'll have to fix it ourselves [19:20:09 CEST] <wm4> I don't think they'd apply anyway [19:20:14 CEST] <Daemon404> exaxtly [19:21:13 CEST] <ubitux> you don't want to fix ffmpeg.c in the avconv.c merge? [19:21:37 CEST] <Daemon404> ubitux, im fine with fixing it in a spearate merge [19:21:44 CEST] <Daemon404> but im saying i can noop the libav ones. [19:21:55 CEST] <Daemon404> because it wont even been close to a clean merge [19:22:03 CEST] <ubitux> sounds weird not to do it in the merge commit [19:22:08 CEST] <ubitux> wm4: can you try https://github.com/ubitux/FFmpeg/compare/sub-time-base ? [19:22:11 CEST] <Daemon404> maybe [19:22:26 CEST] <Daemon404> ubitux, we can still push the lavf commit/merge first [19:22:32 CEST] <Daemon404> it helps us make the branch less... hge [19:22:33 CEST] <Daemon404> huge [19:22:36 CEST] <ubitux> yes ofc [19:22:50 CEST] <ubitux> btw, you'll have to squash everything before doing a rebase or a re-merge [19:23:01 CEST] <ubitux> (because i cherry-picked stuff from master) [19:24:10 CEST] <Daemon404> im going to make a new branch based off HEAD and cherrypick/squash stuff [19:24:16 CEST] <Daemon404> once it builds/works [19:24:30 CEST] <Daemon404> probably a 1-3 hrs work [19:25:45 CEST] <wm4> ubitux: cc_dec: packet time base not set [19:26:01 CEST] <wm4> ubitux: same for any other text subtitle format [19:26:16 CEST] <ubitux> but it worked with the commit in cc? [19:26:18 CEST] <ubitux> strange [19:26:30 CEST] <ubitux> but OK, let me try something then [19:31:19 CEST] <ubitux> wm4: can you pull & retry? [19:31:34 CEST] <ubitux> it will prefer pkt_timebase over avctx->time_base though [19:31:59 CEST] <ubitux> (if set) [19:32:17 CEST] <wm4> ubitux: appears to work [19:32:21 CEST] <ubitux> ok [19:32:29 CEST] <ubitux> do you think i should test for avctx->time_base instead? [19:32:58 CEST] <wm4> don't know, some other API user might have set both to different values? [19:33:08 CEST] <wm4> this was never a well-defined API [19:33:16 CEST] <ubitux> you think other people managed to make subtitles work? [19:33:18 CEST] <ubitux> @_@ [19:39:26 CEST] <Daemon404> nevcairiel, fiel stuff is all passing now. [19:40:14 CEST] <Daemon404> i think all of vsynth* works now [19:40:15 CEST] <Daemon404> running it. [19:40:42 CEST] <kierank> Prores spec is out [19:40:53 CEST] <Daemon404> spec or "spec" [19:42:55 CEST] <ubitux> timestamps are now set in fate-mxf-demux, should we just keep that change? [19:43:13 CEST] <Daemon404> i mean, that sounds better to me [19:43:29 CEST] <Daemon404> also: yes, all of the vsynth tests pass [19:43:30 CEST] <Daemon404> \o/ [19:44:30 CEST] <ubitux> http://sprunge.us/XZFK basically this (after keeping our local chunks) [19:44:57 CEST] <Daemon404> that looks more correct me [19:45:18 CEST] <ubitux> the reason it mismatch with libav change is because we have F=0x0 in the output [19:45:20 CEST] <ubitux> afaict [19:45:25 CEST] <Daemon404> ah [19:45:28 CEST] <Daemon404> yeah, ship it, [19:47:37 CEST] <ubitux> done [19:48:51 CEST] <ubitux> exact same thing with fate-nc-demux [19:49:11 CEST] <ubitux> http://ubitux.fr/pub/pics/fate-nc-colordiff.png [19:49:16 CEST] <ubitux> so going to ship it as well [19:52:12 CEST] <wm4> huh why does the diff not render this minimally [19:52:17 CEST] <Daemon404> ? [19:52:40 CEST] <wm4> I mean, the CRC is highlighted twice, but it doesn't change [19:53:26 CEST] <nevcairiel> probably only stops highlights on spaces [19:53:32 CEST] <nevcairiel> and this adds a , after the crc [19:54:09 CEST] <ubitux> same for fate-lmlm4-demux, pushed [20:01:38 CEST] <Daemon404> fate-movenc fixed [20:01:42 CEST] <Daemon404> it was all expected changes [20:02:01 CEST] <Daemon404> nevcairiel / wm4 - what is concat in the fate list? [20:02:04 CEST] <Daemon404> i dont see a concat test [20:02:56 CEST] <nevcairiel> there is various concat tests [20:03:36 CEST] <nevcairiel> concat-demuxer-extended-lavf-mxf etc [20:04:30 CEST] <Daemon404> hmm ok [20:04:51 CEST] <Daemon404> ubitux, ffprobe_*- just codec_time_base differs [20:04:56 CEST] <Daemon404> i wasnt sure what to do about this [20:11:33 CEST] <omerjerk> Hi everyone. [20:12:30 CEST] <omerjerk> So i need to perform Masked LZ Decompression at a place in ALS decoder. [20:13:02 CEST] <omerjerk> is by any chance this algorithm already present somewhere in the ffmpeg codebase ? [20:13:23 CEST] <omerjerk> else I'll need to write it myself. [20:19:14 CEST] <michaelni> ubitux, http://sprunge.us/XZFK <-- the mpeg4 in this is not marked as low_delay so dts==pts at least from codec level would be wrong [20:23:52 CEST] <Daemon404> michaelni, even if it is intar-only? [20:23:54 CEST] <Daemon404> intra* [20:29:40 CEST] <Daemon404> hmm, where are audio timestamps set during demux? [20:29:45 CEST] <Daemon404> for packets [20:32:44 CEST] <Daemon404> nevcairiel, the concat failures are the same as the ffprobe ones (concat tests use ffprobe output) [20:32:55 CEST] <nevcairiel> it seemd more broken before [20:33:06 CEST] <Daemon404> yeah before i fixed the rest [20:33:14 CEST] <Daemon404> now it's just codec_time_base beign reported as 0/1 [20:33:27 CEST] <Compn> hmm wasnt there some kind of file analyzer out there [20:33:27 CEST] <michaelni> Daemon404, intra only doesnt matter the VO type does for non coded low_delay, we arent checking that though currently and assume all VOs can contain B frames [20:33:35 CEST] <Compn> i thought someone wrote it ... maybe kierank [20:34:01 CEST] <Daemon404> nevcairiel, any opinion on ffprobe "codec timebase" output? [20:34:11 CEST] <Compn> theres a couple of forensic mpeg4/h264 file analyzers out there too. they count frame numbers and scan for mpeg frame startcodes etc [20:34:33 CEST] <Daemon404> let's see. [20:37:45 CEST] <Daemon404> think i might know what to do [20:43:15 CEST] <Daemon404> woo fixed [20:57:28 CEST] <Daemon404> nevcairiel, concat and ffproeb fixed. [20:57:44 CEST] <Daemon404> i think theres not a ton left to fix for fate now [20:59:11 CEST] <Daemon404> nevcairiel / ubitux / wm4 - do you mind if i trim down the etherpad to now have 9000 fied things in it? [20:59:35 CEST] <nevcairiel> i wanted to trim the todos anyway to only open items [20:59:40 CEST] <Daemon404> ok [21:09:09 CEST] <Daemon404> done [21:24:57 CEST] <cone-135> ffmpeg 03Kirill Gavrilov 07master:f3ec8ac0f422: lavc/mediacodec: fix zero stride for OMX.allwinner.video.decoder.avc [21:28:13 CEST] <cone-135> ffmpeg 03Paul B Mahol 07master:a55c953ef00c: avfilter/af_sofalizer: allow user to setup custom virtual speakers positions [21:34:18 CEST] <ubitux> Daemon404: sure [21:35:04 CEST] <ubitux> michaelni: ah... [21:35:21 CEST] <ubitux> so i should revert these commits? [21:37:06 CEST] <ubitux> michaelni: so it's actually supposed to be NOPTS? [21:38:49 CEST] <ubitux> ah you sent a patch [21:40:03 CEST] <michaelni> my patch improves low_delay (and thus has_b_frames) setting for mpeg4, the values posted where wrong for low_delay=0 / has_b_frames=1 [21:40:35 CEST] <michaelni> my patch is very unlikely to fix whatever problem caused the quoted values [21:41:12 CEST] <michaelni> it fixes a long standing mistake on the mepg4 header interpretation [21:41:47 CEST] <michaelni> mpeg4 header -> low_delay/has_b_frames -----libavformat---> timestamps [21:41:55 CEST] <Daemon404> nevcairiel, not much left, mostly the stuff you explained to be re: voc and swf. take a look tmr if you have time. [21:42:00 CEST] Action: Daemon404 forgets exactly what to fix [21:42:24 CEST] <kierank> BBB: so prores doesn't specify a specific idct [21:42:27 CEST] <Daemon404> michaelni, i think the idea is to add a delay field into codecpar [21:42:28 CEST] <kierank> which is very interesting [21:42:44 CEST] <BBB> is prores defined at all? [21:43:16 CEST] <michaelni> Daemon404, yes, something with a sane name that does what has_b_frames_ does now is needed [21:43:21 CEST] <kierank> BBB: yes spec released today [21:45:25 CEST] <jamrial> great oportunity to clean our duplicate decoders and encoders. whichever ended up being closer to spec shall stay :p [21:45:37 CEST] <JEEB> woah, spec for prores [21:45:42 CEST] <JEEB> my head just blew [22:03:33 CEST] <Daemon404> whyone know which func audip timestamps are generated in for packets? [22:03:35 CEST] <Daemon404> anyone* [22:09:55 CEST] <kierank> JEEB: a reference implementation too [22:11:40 CEST] <JEEB> and just a year or two ago it was all "proprietary stuff only for proper licensors, do not steal" [22:12:36 CEST] <kierank> it still is [22:12:45 CEST] <JEEB> :D [22:12:48 CEST] <kierank> they will threaten you if you implement it [22:13:11 CEST] <JEEB> sounds like dolby, although I only know that dolby goes against non-licensed payware distributors [22:13:15 CEST] <Compn> they threatened everyone who was using ffmpeg prores iirc :D [22:13:28 CEST] <Compn> in a commercial setting that is [22:20:17 CEST] <Daemon404> ok wm4 / nevcairiel / ubitux - ive done literally all i can do now without help, so please do have a look at a thing or two and hit me up. [22:20:28 CEST] <Daemon404> etherpad is updated - not much left [22:28:56 CEST] <wm4> will look tomorrow if I can do anything [22:29:09 CEST] <Daemon404> ok [22:47:13 CEST] <durandal_170> all demuxers not present in libav where converted? [22:57:28 CEST] <BtbN> hm, this CUVID decoder might prove difficult if not impossible. At least without pulling the frames to system memory right in the decoder. [22:58:10 CEST] <BtbN> The frames need to be mapped/unmapped to cuda surfaces, so the frames would need some kind of custom cleanup [22:58:31 CEST] <BtbN> And CUVID also only allows a certain number of mapped output frames, which might be only exactly one [23:00:23 CEST] <ubitux> durandal_170: git grep -- '->codec[^p_]' libavformat still has a few match [23:01:27 CEST] <ubitux> chromaprint, electronicarts, ffm{dec,enc}, libnut, microdvdenc, mov*, mux, nut{dec,enc}, oggdec, sdp, and utils [23:05:25 CEST] <BBB> this sucks so much [23:05:34 CEST] <BBB> Im trying to do some colorspace conversion tests [23:05:49 CEST] <BBB> and I have no content which is actually marked for anything else than colorspace unknown trc unknown and primaries unknown [23:06:04 CEST] <BBB> why does software suck so much? [23:06:25 CEST] <kierank> BBB: parkjoy sources i think are done correctly [23:07:08 CEST] <kierank> kinda big though [23:07:08 CEST] <BBB> is there a x264-encoded source somewhere? [23:07:14 CEST] <BBB> like, I only need a few frames [23:07:32 CEST] <Shiz> go to nyaa, pick literally anything [23:08:11 CEST] <BBB> nyaa? [23:09:00 CEST] <ubitux> nyaa.eu [23:09:09 CEST] <ubitux> or .se [23:09:17 CEST] <JEEB> lemme see if my bt.709=>bt.2020 thing had colorimetry info [23:09:24 CEST] <BBB> pff... [23:09:39 CEST] <BBB> I need something sfw [23:09:50 CEST] <BBB> and illegal torrents that are not porn are not sfw just because they are not porn [23:10:08 CEST] <ubitux> i can check my samples [23:10:12 CEST] <ubitux> is that info exported by ffprobe? [23:10:23 CEST] <JEEB> and ffmpeg as well IIRC [23:10:25 CEST] <BBB> should be in the frame, yes [23:10:45 CEST] <ubitux> what field? [23:10:49 CEST] <JEEB> ok, so I have my Japanese rugby sample [23:11:01 CEST] <JEEB> it's MPEG-TS so you can grab the first N megabytes of it [23:11:40 CEST] <BBB> that would be wonderful [23:11:45 CEST] <ubitux> - ffprobe -v error -of flat -show_entries stream=color_space,color_range ~/samples/big_buck_bunny_1080p_h264.mov [23:11:47 CEST] <ethe> JEEB: I have a raw of the Japan Vs South Africa game lying about somewhere [23:11:47 CEST] <ubitux> streams.stream.0.color_range="tv" [23:11:49 CEST] <ubitux> streams.stream.0.color_space="bt709" [23:11:51 CEST] <ubitux> so stuff like this? [23:11:53 CEST] <BBB> yes [23:11:56 CEST] <JEEB> https://kuroko.fushizen.eu/samples/Japanese_Rugby_Game-4K_Channel.ts [23:12:00 CEST] <JEEB> this is BT.2020 [23:12:31 CEST] <BBB> holy shit that is big [23:12:39 CEST] <BBB> how much do I need? [23:12:41 CEST] <ubitux> BBB: http://b.pkh.me/classics-in-lego-26.jpg [23:12:42 CEST] <ubitux> bt470bg [23:12:59 CEST] <Shiz> nice prompt [23:13:16 CEST] <ubitux> it's a red on error :X [23:13:17 CEST] <JEEB> BBB: it's MPEG-TS so a dozen megabytes or so should be OK even with that bit rate [23:13:24 CEST] <BBB> [hevc @ 0x7ff931833000] SPS 0 does not exist [23:13:26 CEST] <BBB> ... [23:13:31 CEST] <JEEB> https://kuroko.fushizen.eu/samples/bt2020_to_bt709.mp4 [23:13:37 CEST] <JEEB> downscaled and bt.709 [23:13:58 CEST] <JEEB> BBB: well yeah it was not cut exactly on an IRAP [23:14:13 CEST] <BBB> ah cool that works [23:14:16 CEST] <BBB> ty [23:14:27 CEST] <ubitux> streams.stream.1.color_space="smpte170m" [23:14:30 CEST] <ubitux> do you want this one? [23:14:52 CEST] <ubitux> http://b.pkh.me/PSDOP.mp4 [23:15:11 CEST] <BBB> JEEB: can you downscale the 4k one to lower resolution and cut the first few seconds out? Id love a bt2020 sample also [23:15:25 CEST] <BBB> ubitux: ty, downloading also [23:15:37 CEST] <BBB> now I need to figure out how lavfi works again [23:15:56 CEST] <ubitux> so what do you have now, bt709, bt470bg, smpte170m? [23:16:45 CEST] <BBB> just smpte170m and bt709 [23:17:03 CEST] <ubitux> you have bt470bg with the jpg [23:17:21 CEST] <BBB> oh right [23:18:32 CEST] <BBB> so I guess I need bt2020 and smpte240m then [23:18:36 CEST] <BBB> that should be about it [23:18:43 CEST] <ubitux> look for some [23:23:49 CEST] <ubitux> BBB: did you check fate samples? [23:27:58 CEST] <BBB> not yet, no [23:28:05 CEST] <BBB> I checked a handful of h264 conformance samples [23:28:10 CEST] <BBB> and theyre all unknown afaics [23:28:21 CEST] <ubitux> can't find anything matching bt2020|smpte428|smpte240m|bt470m|film [23:28:25 CEST] <ubitux> (so far) [23:29:02 CEST] <ubitux> oh there is one with fcc in fate [23:31:33 CEST] <ubitux> BBB: fate-samples/ea-mpc/THX_logo.mpc [23:31:36 CEST] <ubitux> for fcc [23:31:47 CEST] <BBB> cool! ty [23:32:30 CEST] <BBB> so can anyone explain to me how format negotiation works in lavfi? [23:32:38 CEST] <cone-135> ffmpeg 03Lou Logan 07master:cd76eb8f4adb: lavd/dshow_crossbar: remove trailing whitespace [23:32:38 CEST] <ubitux> yes [23:32:40 CEST] <ubitux> magically [23:32:43 CEST] <BBB> lets say Im writing a filter that changes colorspace from bt2020 to bt709 or so [23:33:03 CEST] <BBB> Im assuming the frame->color_primaries etc. fields are writable by me in the output frame, right? [23:33:14 CEST] <BBB> where output frame is the thing received from ff_get_video_buffer [23:33:22 CEST] <BBB> so, how do I set format? [23:33:33 CEST] <durandal_170> Yes [23:33:41 CEST] <BBB> lets say my filter is bitdepth-agnostic, and my input frame is yuv420p& how do I set the output to yuv420p12? [23:33:56 CEST] <BBB> (assuming I have some property bitdepth in my filter) [23:34:07 CEST] <durandal_170> query_formats [23:34:08 CEST] <BBB> (which maps to the variable s->bit_depth) [23:34:15 CEST] <BBB> what does query_formats do? [23:34:59 CEST] <ubitux> it specifies which pixel format you support as input and output [23:35:11 CEST] <BBB> but what if I dont care what the input is? [23:35:25 CEST] <ubitux> then you only set the output one [23:35:36 CEST] <BBB> like, I want to say input can be yuv420p10, 12 or 8, but output is yuv420p10 because the user said so [23:35:40 CEST] <BBB> oh [23:35:51 CEST] <BBB> how do I do that? [23:35:59 CEST] <ubitux> but then it means you're suppose to support any pixel format, right? [23:36:03 CEST] <BtbN> well, you most likely still want to define a range of supported input formats? Otherwise RGB and stuff would also be valid [23:36:32 CEST] <BBB> right, so the input will be a list like various filters have [23:36:35 CEST] <BBB> and the output will be 1 [23:37:38 CEST] <BBB> I see ff_set_common_formats [23:37:44 CEST] <BBB> does that set it on input and output? [23:38:23 CEST] <ubitux> yes [23:38:31 CEST] <durandal_170> yes [23:39:51 CEST] <durandal_170> see zscale/scale filters [23:45:43 CEST] <ubitux> BBB: if you have a db of samples, you can try find samples -type f -exec ffprobe -v 0 -of flat -show_entries stream=color_space,color_primaries {} \; -print > colorspace.log [23:45:48 CEST] <ubitux> and grep stuff in that [23:45:49 CEST] <cone-135> ffmpeg 03Marton Balint 07master:99f2a59c2f29: avcodec/utils: fix packet duration of frames with discarded paddings [23:46:03 CEST] <ubitux> i'm running this on my stuff, will see if sth comes up [23:47:42 CEST] <ubitux> i should write a script create a sqlite db based on ffprobe output [23:47:56 CEST] <ubitux> so we can do fun queries to find particular type of samples [23:49:35 CEST] <BBB> ok the filter format setting works now, nice [23:57:00 CEST] <dinux5> what to do to remove doxy and non doxy comment error message in patcheck ? [00:00:00 CEST] --- Tue Mar 29 2016

1 0

ffmpeg.log.20160328
by burek 29 Mar '16

29 Mar '16

[00:13:23 CEST] <J_Darnley> What software gives those two messages about the files? [00:13:31 CEST] <J_Darnley> stemid ^ [00:16:38 CEST] <stemid> ffprobe? [00:16:57 CEST] <J_Darnley> No, the two from your first message [00:17:07 CEST] <stemid> file(1) [00:17:27 CEST] <stemid> I'll try a different id3 version [00:17:32 CEST] <stemid> I found the option to set that [00:17:46 CEST] <stemid> but it feels like a stretch [00:20:27 CEST] <J_Darnley> Did I miss anything after my last message? [00:21:08 CEST] <stemid> I said I used the file(1) utility to get that data. and also that I'm trying to set the id3 version to 2.3 to see if that'll make a difference. [00:21:26 CEST] <J_Darnley> ah [00:22:13 CEST] <stemid> apparently google music can stream to sonos directly, but it won't help if it can't discover the music first. [00:26:03 CEST] <J_Darnley> ha! results from my own library [00:27:10 CEST] <stemid> wow changing the id3 version solved it! [00:27:32 CEST] <stemid> so that might be good to know, the ffmpeg default makes songs unplayable in popular music apps. [00:27:38 CEST] <J_Darnley> Ah. I guess I'll stop looking for more difference [00:28:20 CEST] <J_Darnley> They must be pretty poor if they can't handle v2.4 [00:28:32 CEST] <stemid> yes of course it's bad of them but still good to know, something fitting for an FAQ [00:28:36 CEST] <stemid> imo [00:28:45 CEST] <stemid> anyways, this is the command I used, from the manpage basically ffmpeg -i "$file" -id3v2_version 3 -f mp3 "`basename "$file" .wav`.mp3" [00:29:18 CEST] <J_Darnley> FYI You probably want -c copy in there [00:29:44 CEST] <stemid> thanks will check what that does [00:30:01 CEST] <J_Darnley> Copies instead of encodes [00:30:19 CEST] <J_Darnley> I thought you were starting with mp3 files though [00:30:25 CEST] <stemid> I had both wav and mp3 [00:30:32 CEST] <stemid> so copy would be good if I went from mp3 to mp3 I assume [00:30:40 CEST] <J_Darnley> Yes, definitely [00:30:42 CEST] <stemid> but I decided to encode from wav to mp3 [00:31:57 CEST] <J_Darnley> Also: ${file%.wav}.mp3 [00:32:19 CEST] <stemid> yeah I normally prefer parameter expansion but I just wanted to get my song played quickly. [00:32:30 CEST] <stemid> #bash nazis are in here :) [00:32:35 CEST] <J_Darnley> huehuehue [00:43:49 CEST] <stemid> found threads about the id3 version on google product forums. known issue for them at least. [00:46:00 CEST] <J_Darnley> I'm glad you'reatisfied. [00:46:11 CEST] <J_Darnley> Ew. Who turned on overwrite? [00:46:16 CEST] Action: J_Darnley hits insert [07:42:30 CEST] <parrot1> I tried to link against ffmpeg libraries but I got error undefined reference to symbol 'avfilter_graph_alloc@@LIBAVFILTER_6' . Any idea? [08:54:08 CEST] <HiRo__> hello everyone, I use ffmpeg to restream a rtsp link to ffserver, my CLI is: "ffmpeg -rtsp_transport tcp -probesize 2147483647 -analyzeduration 2147483647 -loglevel 48 -i "rtsp://myurl" -rtsp_transport tcp -y -flags +global_header -c:v http://localhost:8090/feed.ffm". ffmpeg output a error "Could not find codec parameters for stream 0 (Video: h264, 1 reference frame, none(left)): unspecified size", can anyone help me to fix it? [09:10:04 CEST] <thebombzen> HiRo__: it looks like you're doing -c:v followed by a URL? -c:v is output video codec [09:14:17 CEST] <HiRo__> sorry, full CLI is "ffmpeg -rtsp_transport tcp -probesize 2147483647 -analyzeduration 2147483647 -loglevel 48 -i "rtsp://myurl" -rtsp_transport tcp -y -flags +global_header -c:v copy http://localhost:8090/feed.ffm" [11:54:11 CEST] <Guest16296> Heelo. Is this the place to get help with ffplay? [11:56:32 CEST] <Guest16296> When I run "ffplay -report" the log seems to be printed to both the logfile and the screen. How can I have it print only to the file [11:56:33 CEST] <Guest16296> ? [12:03:22 CEST] <c_14> add -v quiet [12:12:32 CEST] <Guest16296> c_14 Thank you. I had assumed that would affect the report file too. I should have tested it [12:50:08 CEST] <hoodedfigure> Hey folks. Is there a way to add a selective brightness filter which keeps bright areas as they are and increases brightness of dark areas? [13:13:30 CEST] <hoodedfigure> Is there some kind of a 'levels' function to adjust luma? [13:17:06 CEST] <hoodedfigure> found it, thanks [13:17:13 CEST] <hoodedfigure> https://ffmpeg.org/ffmpeg-filters.html#colorlevels [13:17:15 CEST] <hoodedfigure> bye [14:40:41 CEST] <jmack> thebombzen: I compiled everything as stated in the link llogan sent me, and the only thing that didn't go well was x265. The one thing I noticed right away was the 'audacity' is experiencing problems and has a tendency to crash after having a captured audio file from ffmpeg inported and played more than one. [14:42:57 CEST] <jmack> thebombzen: May be a bug, but I suspect it might have something to do with 'avconv' not being removed from my system. [14:47:45 CEST] <jmack> thebombzen: As I said, x265 was the only thing that didn't install as easy as the others. The PATH used might be the problem or maybe it's just me...whatever the case I had to physically move the program to the $HOME/bin, it seems fine with the exception that ffmpeg complains it can't use it! LOL [15:06:04 CEST] <jmack> anyone: Got any ideas? [15:20:57 CEST] <bencoh> jmack: ffmpeg needs libx265 (the library), not x265 (the tool) [15:21:38 CEST] <bencoh> so you need to install the lib (and you might need to tell the build system to do so) [15:22:44 CEST] <jmack> bencoh: sorry bout that...yes, I did install the library. [15:24:10 CEST] <jmack> bencoh: I'm not an expert, "tell the build system to do so" ? [15:24:49 CEST] <jmack> bencoh: Please explain... [15:25:18 CEST] <J_Darnley> For example: when compiling x264 you need to explicitly enable a library otherwise you only get the command line encoder. [15:25:27 CEST] <bencoh> if you can see libx265 in your lib folder then it should be fine [15:25:59 CEST] <bencoh> if you installed to a non-standard folder you need to tell that to ffmpeg's configure as well [15:26:50 CEST] <jmack> OK, how do I do that? [15:27:59 CEST] <furq> --extra-cflags="-I/path/to/x265/include" --extra-ldflags="-L/path/to/x265/lib" [15:28:06 CEST] <jmack> Yes, I installed to $HOME/bin... [15:28:48 CEST] <jmack> furq: This will fix it? [15:28:57 CEST] <furq> that depends on what it is [15:29:15 CEST] <jmack> Or do I need to recompile the whole ffmpeg? [15:30:47 CEST] <jmack> Do I need to recompile the ffmpeg with those options? [15:31:25 CEST] <furq> well the fact that it compiled in the first place implies you didn't compile with --enable-libx265 [15:31:42 CEST] <furq> so you probably want to do that as well [15:31:56 CEST] <jmack> OK, you might have something there [15:34:33 CEST] <jmack> Hold on a minute. I'll check to see if I compiled with "--enable-libx265" [15:36:52 CEST] <jmack> furq: Your right I didn't use --enable-libx265, damn it.. [15:37:34 CEST] <jmack> Like I said i'm not an expert... [15:39:18 CEST] <jmack> So has anybody else ran into trouble with 'audacity' after installing ffmpeg? [15:46:06 CEST] <jmack> Is there a conflict between ffmpeg and avconv that causes problems in 'audacity' ? [15:46:19 CEST] <thebombzen> jmack: Audacity uses the libav in the repositories [15:46:30 CEST] <thebombzen> put simply, libav sucks. [15:46:41 CEST] <thebombzen> my best guess is that bug was fixed in ffmpeg eight months ago [15:46:52 CEST] <thebombzen> and libav devs were too arrogant to pull it [15:48:03 CEST] <jmack> OK, i agree with the "libav sucks" part [15:48:49 CEST] <jmack> How do i get audacity to use ffmpeg lib? [15:49:19 CEST] <jmack> Or can it be fixed at all? [15:50:07 CEST] <c_14> jmack: if it uses the libraries you'll probably have to recompile, if it uses the ffmpeg binary you'll have to check if it has a config option for the path to it [15:51:11 CEST] <jmack> Recompile Audacity? [15:51:15 CEST] <c_14> yes [15:51:30 CEST] <c_14> recompile it to link against FFmpeg's libraries [15:52:06 CEST] <c_14> and if you compiled FFmpeg with shared libraries you'll probably have to make sure your RPATH is set correctly when linking and/or set LD_LIBRARY_PATH before running audacity [15:54:09 CEST] <jmack> OK. i used the software manager to install Audacity and it has sh*t the bed the bed again... [15:55:35 CEST] <mr_pinc> Hello I have a command line that i'd like to have some of the command line parameters explained - can anyone help? -c:v libx264 -crf 25 -profile:v high -r 30 [15:55:49 CEST] <mr_pinc> Mainly I understawnd everything before '-profile' [15:56:05 CEST] <mr_pinc> So really it's the -profile:v high -r 30 part [15:56:58 CEST] <c_14> The profile option sets the H.264 profile to use, in this case high. -r 30 sets the output framerate (fps) to 30 [15:57:15 CEST] <__z0k__> hi, dont know if anyone can help with a probl i'm having transcoding an rtmp to rtmp stream [15:57:29 CEST] <__z0k__> im'm using the cmd ffmpeg -re -i rtmp://184.72.239.149/vod -map 0:0 -map 1:1 -acodec copy -vcodec copy -f flv rtmp://localhost:1935/dash/test [15:57:36 CEST] <mr_pinc> ok does that relate at all to the crf 25 command? Like if I am specifying the quality with -crf 25 how does high profile fit in? [15:57:45 CEST] <__z0k__> and getting the following error: Server error: Failed to play ; stream not found. [15:57:48 CEST] <__z0k__> rtmp://184.72.239.149/vod: Operation not permitted [15:57:50 CEST] <mr_pinc> c_14 is there a way to specify same source frame rate? [15:58:02 CEST] <JEEB> don't override frame rate and input timestamps are used [15:58:05 CEST] <c_14> just don't set the option, same is default [15:58:21 CEST] <JEEB> profiles = features, levels = how much memory the decoder requires in modern video formats [15:58:42 CEST] <JEEB> the x264 presets also limit features and high is the highest for 8bit 4:2:0 picture encoding [15:58:54 CEST] <JEEB> so essentially -profile high is pretty much a no-op in many cases :P [15:59:20 CEST] <JEEB> x264 by default selects the profile according to your preset, and generally you use profile to limit the features to a specific profile [15:59:37 CEST] <JEEB> so f.ex. if your preset doesn't use 8x8dct, which is high profile specific, you will get main profile selected [15:59:59 CEST] <JEEB> so generally you set the profile when you want something lower than high in all cases [16:00:02 CEST] <JEEB> like baseline or main [16:00:31 CEST] <c_14> And if you don't care, just don't set it. [16:01:13 CEST] <JEEB> yes, x264 by default selects the profile required by your features enabled in the preset you're using [16:02:06 CEST] <mr_pinc> c_14: Very helpful thank you [16:03:33 CEST] <c_14> __z0k__: can you play the stream using a media player? It might be firewall/access restriction on the server side. [16:09:29 CEST] <gnome1> JEEB: what about the level? so if I don't touch these settings, I won't get a bigger file or something like that? [16:12:38 CEST] <bencoh> if you dont set level/profile, x264 will decide based on other encoding options, and/or preset [16:16:25 CEST] <jmack> I noticed that when i import a captured audio file into Audacity it seems offset from the zero line, is that normal? [16:17:12 CEST] <kepstin> that depends on hardware. Means you have a dc offset in the analog side [16:24:57 CEST] <jmack> I thought that's what it was, but running 'normalize' with 'remove dc offset' doesn't get rid of it, thanks for your help kepstin :) [16:26:00 CEST] <thebombzen> jmack: check in #audacity [16:27:01 CEST] <kepstin> jmack: iirc, the usual way to remove dc offset (particularly if it shifts over time) it to apply a high pass filter at an inaudible low frequency, something around 1-5Hz maybe [16:27:16 CEST] <jmack> OK, sorry, its just when you find someone who knows you just want to get as many answers as possible... [16:28:11 CEST] <jmack> kepstin: thanks man [16:28:24 CEST] <jmack> thebombzen: sorry again [16:29:20 CEST] <thebombzen> jmack: and stop apologizing every other message [16:29:33 CEST] <jmack> OK [16:57:01 CEST] <lmat> Why is the vertical scale on ffplay linear instead of logarithmic? [16:58:11 CEST] <lmat> oh... scale=log maybe... checking [16:59:43 CEST] <lmat> my goodness... https://ffmpeg.org/ffplay-all.html [16:59:48 CEST] <lmat> I see a lot of work has gone into this... [16:59:56 CEST] <lmat> And I thought I was (mis-)using a debugging tool [17:00:06 CEST] <c_14> lmat: I'm pretty sure it just inserts a default showspectrum filter [17:00:55 CEST] <c_14> And the default scale should be sqrt [17:01:11 CEST] <thebombzen> lmat: I find ffplay most useful because it's really really fast and configurable with a commandline. compared to mplayer which is slightly slower but the default options are better suited for long playback and has more keyboard shortcuts [17:01:47 CEST] <thebombzen> i.e. in ffplay you specify which streams to play, with switches and in mplayer you use a keyboard shortcut once you've run it. [17:04:23 CEST] <lmat> thebombzen: I play music to which I work using ffplay. [17:04:53 CEST] <lmat> thebombzen: I've created a script to play recursively, optionally shuffling, optionally showing the (default) showspectrum, etc. [17:05:02 CEST] <__z0k__> c_14: hm it might be, let me check my firewall [17:05:08 CEST] <lmat> c_14: thanks [17:05:23 CEST] <thebombzen> lmat: then you're using the right tool :D [17:06:02 CEST] <lmat> c_14: How would I write the command to reproduce the default? [17:06:14 CEST] <lmat> c_14: ffplay file.flacc 'showspectrum'; for instance doesn't work. [17:11:02 CEST] <durandal_170> ffplay doesn't support a->v filters [17:11:24 CEST] <kepstin> lmat: the default is "-showmode rdft" (if there's no video), which sets up the filter internally. [17:14:57 CEST] <lmat> kepstin: Ahh, I see. Can you help me get started with a command to "showspectrum"? [17:15:23 CEST] <lmat> I normally do ffplay audio.wav; [17:15:47 CEST] <kepstin> lmat: not sure what you mean... you can't manually use the showspectrum filter in ffplay, since it doesn't support a->v filters as durandal_170 said [17:16:34 CEST] <kepstin> but it's the default in ffplay, so why do you even need to set it? [17:17:27 CEST] <durandal_170> use mpv [17:17:35 CEST] <lmat> kepstin: I want to modify its behaviour. It shows the frequency on a linear scale (as far as I can tell) and I prefer a logarithmic scale. [17:17:37 CEST] <bencoh> :] [17:18:01 CEST] <lmat> kepstin: What should I make of the 'showspectrum' part of this page: https://ffmpeg.org/ffplay-all.html#Syntax [17:18:24 CEST] <lmat> well... https://ffmpeg.org/ffplay-all.html#showspectrum-1 [17:18:25 CEST] <kepstin> lmat: you can't do that with ffplay. [17:18:59 CEST] <lmat> kepstin: What tool is that webpage documenting? [17:19:19 CEST] <kepstin> lmat: that page is autogenerated, and just includes all the filters - even ones you can't use with ffplay [17:19:32 CEST] <lmat> kepstin: Thanks. So I guess I come back to my original question ^_^ [17:19:33 CEST] <kepstin> (unless you feel like recoding ffplay to support the -filter_complex option like the ffmpeg command line tool does) [17:19:40 CEST] <lmat> Why is the vertical scale on ffplay linear instead of logarithmic? [17:20:25 CEST] <kepstin> it should be sqrt, actually, since that's the filter default [17:21:00 CEST] <lmat> kepstin: That would make sense, but based on my experience, it doesn't seem to be... Screen shot coming. [17:22:57 CEST] <lmat> Here is a logarithmic sweep: http://i.imgur.com/xPSZcll.png [17:23:05 CEST] <lmat> I'll generate a linear one, too... [17:23:55 CEST] <kepstin> oh, wow, the ffplay showmode isn't actually using the showspectrum filter internally [17:24:02 CEST] <kepstin> it's actually a separate implementation [17:25:11 CEST] <kepstin> looks like it is using sqrt scaling as well, though. [17:25:25 CEST] <kepstin> if i'm reading this correctly [17:25:57 CEST] Action: lmat cries [17:26:16 CEST] <lmat> Maybe the showspectrum filter was too processor intensive? [17:27:11 CEST] <kepstin> nah, it should be about the same. They're both using the same rdft implementation, of course. [17:28:24 CEST] <kepstin> hah, according to the comments, the 'showspectrum' filter was actually made by extracting the rdft code from ffplay and turning it into a filter. [17:30:39 CEST] <lmat> hah [17:44:03 CEST] <kepstin> lmat: if you're in a particularly horrible mood, here's a horrible hack: ffmpeg -nostdin -i awesomemusic.ogg -filter_complex 'asplit[a][b];[a]showspectrum=scale=log:color=fruit[c]' -map '[b]' -map '[c]' -c:a pcm_s16le -c:v rawvideo -f nut - | ffplay - [17:44:31 CEST] <lmat> ^_^ [17:45:10 CEST] <c_14> kepstin: want an even worse hack? use -f sdl and -f alsa (or -f pulse) [17:46:22 CEST] <c_14> And you don't need the asplit, you can just -map 0:a instead [17:46:33 CEST] <lmat> What color mode matches ffplay default? [17:46:35 CEST] <JEEB> I'd just see if you could do the same with mpv [17:46:41 CEST] <kepstin> lmat: channel [17:47:23 CEST] <c_14> JEEB: I've tried and it's a pain, I think the only way I got it working was using the lavfi input device with the movie filter... Not much fun [17:47:30 CEST] <c_14> Might have missed something though, or something might have changed [17:47:36 CEST] <JEEB> ah [17:47:41 CEST] <JEEB> that's possible, sure [17:48:11 CEST] <kepstin> when playing with filters in mpv, i found a lot of lavfi filters don't really work properly, particularly if they rely on frame metadata (e.g. the interlaced flag isn't passed through) [17:48:46 CEST] <lmat> With kepstin 's hack: http://i.imgur.com/N1utPb4.png just ffplay awesomemusic.ogg; http://i.imgur.com/G3byUmq.png [17:49:01 CEST] <lmat> kepstin: thanks! [17:49:42 CEST] <c_14> Oh, cool. nvmd. the --lavfi-complex option does exactly what I want [17:49:46 CEST] <lmat> (What is this awesomemusic.ogg that shakes and wiggles so much!? Renee Fleming.) [17:53:13 CEST] <c_14> lmat: if you have mpv you can use mpv --lavfi-complex='[aid1]asplit[ao][foo];[foo]showspectrum=scale=log[vo]' awesomemusic.ogg [17:53:21 CEST] <c_14> should incur less overhead [17:55:35 CEST] <kepstin> huh, that renders at a lower framerate for me [17:57:54 CEST] <c_14> Probably because it reads input at realtime? Maybe add -re to the ffmpeg command? [17:58:28 CEST] <kepstin> no, I mean the mpv one does; it's kind of jerky [17:58:34 CEST] <kepstin> the ffmpeg hack was perfectly smooth [17:59:28 CEST] <lmat> c_14: cool! [18:00:09 CEST] <kepstin> i guess something in that filter chain messes with mpv's frame timing :/ [18:04:27 CEST] <c_14> Hmm, both look the same to me. It gets a bit jittery for me if I render at 1080p, but it does that for both. [18:11:01 CEST] <lmat> yeah, I think ffplay uses linear... Here's a log sweep from 200 to 20,000 hz, 10 seconds: http://i.imgur.com/emtO76g.png and a linear sweep with the same parameters: http://i.imgur.com/QuzdVVm.png [18:11:54 CEST] <lmat> oh well. Thanks for all the suggestions! [18:17:18 CEST] <lmat> you know... the "crazy hack" given by kepstin has the same behaviour :o [18:17:23 CEST] <lmat> The linear sweep looks... linear [18:21:53 CEST] <lmat> Ah! I was doing it wrong! [18:22:23 CEST] <lmat> I was running ffmpeg -autoexit -vn -; X-| [18:25:25 CEST] <lmat> hmm, still, changing scale=log to scale=sqrt and scale=lin looks basically the same. Maybe I'm [18:25:41 CEST] <lmat> well no wonder. rtfm: scale = "intensity color values" [18:30:22 CEST] <lmat> showcqt does it logarithmically.but... [18:31:19 CEST] <lmat> heh, Apparently Il mio tesoro is in Eb... [18:31:48 CEST] <lmat> Of course, I assume this showcqt is using A=440. [18:31:56 CEST] <lmat> And that Placido Domingo is using the same reference. [19:11:58 CEST] Action: kepstin is too lazy to add 'showspectrum' support to his player, so he uses a silly ffmpeg command to hook it to the pulseaudio monitor input and give a spectrum of whatever's playing :) [19:36:49 CEST] <explodes> Does the ffmpeg library load codecs from disk? [19:37:31 CEST] <explodes> i.e. if i run the ffmpeg (as built libraries) on an iphone vs. an android vs. a PC or mac, they might have different codecs available? [19:37:44 CEST] <explodes> iphone: [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8c3d833400] moov atom not found [19:37:49 CEST] <explodes> android: plays just fine [19:38:49 CEST] <pzich> different devices definitely may have different codecs [19:38:54 CEST] <pzich> if that's what you're asking [19:39:09 CEST] <explodes> nooouuu ok ok [19:39:28 CEST] <pzich> welcome to the fun world of video and streaming :D [19:42:54 CEST] <kepstin> explodes: if you're getting a 'moov atom not found' error, that usually means that your mp4 file is incomplete (missing the end) or corrupted [19:43:03 CEST] <kepstin> that's unrelated to codecs. [19:44:27 CEST] <explodes> well, it plays on android just fine. the same ffmpeg binaries do not play the video on ios [20:02:25 CEST] <markamillia> hello, I'm trying to combine 2 videos into one that plays them both side by side [20:02:35 CEST] <markamillia> I'm having trouble with the example online [20:08:08 CEST] <durandal_170> what trouble? [20:09:58 CEST] <kepstin> explodes: according to that error, the problem isn't that the libraries are different - it's that the file is different. [20:26:04 CEST] <fturco> hello. i'm transcoding some dvds with the vp9 codec (-c:v libvpx-vp9). i have a dual core cpu. [20:26:27 CEST] <fturco> i read somewhere that vp9 doesn't automatically detect the number of cores yet. is that true? [20:26:46 CEST] <fturco> if so, how can i tell ffmpeg to use both cores to increase speed? [20:27:16 CEST] <kepstin> fturco: you could try manually setting -threads 2 and see if it makes a difference. But libvpx doesn't seem to make use of multithreading very well, particularly for standard definition sources. [20:28:16 CEST] <fturco> here (http://wiki.webmproject.org/ffmpeg) it says "recommended value : number of real cores - 1)" [20:28:26 CEST] <fturco> why? [20:29:51 CEST] <kepstin> it's probably implemented as "the number of threads in addition to the main thread" [20:32:12 CEST] <fturco> so i could use -threads 1 [20:32:31 CEST] <kepstin> try a couple values, see if you get any improvement [20:32:43 CEST] <kepstin> I suspect it'll be marginal differences at best [20:33:57 CEST] <fturco> i cannot try right now because my cpu is already busy with an encoding process. it will take all the night for it to finish. tomorrow i'll try re-running the same ffmpeg command plus the -threads 1 option [20:35:05 CEST] <fturco> the system monitor currently doesn't show 100% usage for both cpu. [20:38:27 CEST] <fturco> here (http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide) it says: "Multi-threaded encoding may be used if -threads > 1 and -tile-columns > 0." [20:38:40 CEST] <fturco> so i guess -threads 1 won't work [20:39:16 CEST] <fturco> i find documentation on the internet to be lacking in this case.. [20:39:21 CEST] <kepstin> and tile-columns can reduce the encoding efficiency, particularly on SD material (it doesn't hurt as much on HD or 4K stuff because the tiles are bigger) [20:39:57 CEST] <fturco> that guide seems to be tailored for HD material [20:40:29 CEST] <kepstin> yeah, the newer codecs like H.265 and VP9 all have HD+ and 4K material as the design target [20:41:08 CEST] <fturco> i guess the -b:v 1000k bitrate option is also tailored for hd material. what i should use for a DVD? [20:41:12 CEST] <furq> i wouldn't bother with vp9 unless you have some issue with mpeg-la [20:41:46 CEST] <fturco> just like the idea of using a completely free format/codec instead of proprietary one [20:42:21 CEST] <kepstin> 1000k is actually a bit low for hd stuff, I'd think... but I don't have much experience with using vp9. You'd probably want to use the quality based mode (-crf in ffmpeg) for most stuff instead of bitrate control, though. [20:43:27 CEST] <fturco> i have even more difficulties at choosing wich -crf value to use. at least the bitrate is something tangible.. [20:43:41 CEST] <pzich> -crf is even better than bitrate [20:43:55 CEST] <pzich> bitrate is completely arbitrary based on the content and codec [20:44:01 CEST] <kepstin> bitrate is a meaningless number uncorrelated to how good the video looks, and in non-quality modes 1-pass bitrate will even make quality vary over time [20:44:03 CEST] <furq> crf is better when sensible values are well documented [20:44:05 CEST] <pzich> at least -crf is a stab at quality [20:44:14 CEST] <furq> i haven't really found any consistent information on what to use for libvpx [20:44:34 CEST] <furq> and i'm not spending ten million years trying out multiple values [20:44:45 CEST] <pzich> ...you'd be doing the same for bitrate, no? [20:45:00 CEST] <fturco> can -crf mode be use with two-pass encoding too? [20:45:04 CEST] <kepstin> sure, but crf is faster because you don't need to wait for two passes [20:45:16 CEST] <kepstin> with vp8, crf mode was a bit wonky because you also needed to set a bitrate (which was used as a "max bitrate" value), and it did give improvements with 2-pass mode [20:45:21 CEST] <kepstin> dunno how much of that applies to vp9 [20:45:43 CEST] <furq> you still need to set a bitrate but you can set it to 0 to disable the bitrate cap [20:46:23 CEST] <fturco> do you suggest me to ask on the #vp8 irc channel? [20:46:34 CEST] <furq> is there such a thing [20:46:37 CEST] <kepstin> with x264, crf mode is basically equivalent to the second pass of a two pass mode in most cases, so 2pass doesn't really make a difference there. [20:46:37 CEST] <fturco> yes [20:46:46 CEST] <kepstin> dunno about x265, might be similar? [20:47:05 CEST] <furq> 2-pass makes a difference if you're targeting a filesize [20:47:14 CEST] <furq> i expect x265 and vp9 are the same but i've not used them enough to say for sure [20:47:22 CEST] <kepstin> if you're targetting a file size, you're not using crf mode :) [20:47:49 CEST] <furq> nvm i misread that [20:48:47 CEST] <furq> i'm sticking with 10-bit x264 for now anyway [20:49:09 CEST] Action: kepstin has to deal with browser decoders, so he still used 8bit most of the time :/ [20:57:33 CEST] <TD-Linux> libvpx VBR with 2 pass is very similar to CRF [20:59:24 CEST] <kepstin> with x264, a crf encode and a vbr mode with the same bitrate as the crf encode used should be basically identical [20:59:45 CEST] <kepstin> with vpx, i'd expect it to be close, but it uses different codepaths iirc so it won't be exactly the same... [21:00:22 CEST] <TD-Linux> yeah, in libvpx, Q mode is more like constant quantizer [21:01:31 CEST] <Filarius> just short question if somebody know - RTMP stream link is "URL/secret_key" like rtmp://1.1.1.1/some/some2/secret_key ? [21:01:49 CEST] <mrmenacex> Has anyone succesfully made a webm dash manifest file using ffmpeg using the vp9 codec ? I have been trying for a day to make one and i keep getting errors . here is my pastebin http://pastebin.com/DhuKbddy [21:02:12 CEST] <kepstin> Filarius: it depends exactly how that's implemented on the server. can't really say - the key might be part of the path, it might be an rtmp parameter... [21:02:39 CEST] <Filarius> well, i meam link to stream to server, like Twitch [21:02:48 CEST] <kepstin> Filarius: best idea might be to search "name of video streaming site ffmpeg" on google and see if someone else has figured out the exact syntax already [21:02:58 CEST] <kepstin> it'll vary between services [21:06:09 CEST] <kepstin> https://trac.ffmpeg.org/wiki/StreamingGuide actually has a twitch example there, the url format looks like "rtmp://live.twitch.tv/app/live_********_******************************" [21:06:54 CEST] <kepstin> I think youtube's live feature gives you the full url rather than separate url and stream key. [21:20:38 CEST] <mrmenacex> Anyone used DASH with vp9 yet ? [21:27:06 CEST] <kepstin> mrmenacex: youtube does :) [21:27:18 CEST] <kepstin> (no idea if anyone here uses it tho) [21:32:26 CEST] <mrmenacex> kepstin: is youtube here ? lol [21:33:34 CEST] <mrmenacex> kepstin: i probably should have said "anyone in here" haha [21:40:34 CEST] <mrmenacex> Well after some further googling i see a mail group post that says that ffmpeg can't make DASH manifest files if the video uses the vp9 codec , but it's from 2015 does anyone know how to check if this is fixed in the latest stable version ? [21:43:18 CEST] <JEEB> it's quite a bit more different than that, since you're going out of the things specificed by MPEG-DASH (container is matroska/webm and all) [21:43:36 CEST] <JEEB> so how is the GoogleDASH even specified!? [21:44:05 CEST] <JEEB> we have just gotten random patches from Google that supposedly create the kind of webm they want [21:44:20 CEST] <JEEB> but nothing in relation to manifests :P [21:45:02 CEST] <JEEB> the only DASH manifest writer is in movenc.c [21:45:19 CEST] <JEEB> because while you can do DASH with mpeg-ts, pretty much no-one does that :P [21:45:24 CEST] <mrmenacex> JEBB: in the mail group it said that it does work with vp8 ? [21:46:25 CEST] <JEEB> I have no idea, the only thing I know is that the DASH manifest stuff for Google's matroska subset/fork is not really defined because only youtube uses it :P [21:47:19 CEST] <TD-Linux> mrmenacex, if it doesn't work you might want to file a ticket in trac about it [21:47:44 CEST] <JEEB> if you can find actual specifications etc it might be implemented [21:49:04 CEST] <JEEB> but I'm not even sure if there's a player for WebM DASH other than youtube's [21:49:59 CEST] <JEEB> for HLS and actual specified DASH there are some JS implementations and MS's Edge browser can even natively support DASH manifests [21:50:16 CEST] <JEEB> but the stuff you're talking of is very muchos Google-specific stuff [21:51:38 CEST] <gnome1> and then google changes the format :-D [21:52:41 CEST] <Mavrik> fun part about DASH [21:52:52 CEST] <Mavrik> Safari supports it but it's only whitelisted if domain is netflix.com :P [21:52:57 CEST] <JEEB> hah [21:55:12 CEST] <Mavrik> Also it's a horrible spec that should be taken behind the shed and shot. [21:55:26 CEST] <Mavrik> I have no frigging idea why Google refuses to support HLS in Chrome. [21:55:41 CEST] <mrmenacex> what is hls ? [22:00:45 CEST] <mrmenacex> i'm not that good with c but here is a link talking about the problem . http://ffmpeg.org/pipermail/ffmpeg-user/2015-September/028610.html [22:02:02 CEST] <mrmenacex> so it works with vp8 but not with vp9 ? Also afaik only h265 and vp9 codecs do resolutions higher than 1080p ? and h265 has no browser support at all? [22:03:34 CEST] <gnome1> mrmenacex: the currently widely used "streaming" protocol that relies heavily on HTTP, "playlists" served over HTTP [22:03:42 CEST] <kepstin> mrmenacex: hmm? you should be able to do >1080p video just fine with h264/vp8. The newer codecs are just more efficient at it. [22:03:49 CEST] <gnome1> designed by apple, stands for or some people call it HTTP Live Streaming [22:04:12 CEST] <gnome1> the benefit of it so far is that it has become so widespread that many flash-based players are just HLS players and you can easily play it outside of the browser [22:04:56 CEST] <gnome1> meanwhile, I think some of the players I use rely on ffmpeg for hls support, and sometimes the support is not perfect (I have to switch between players sometimes), which is expected, I guess some HLS implementations are just broken [22:06:21 CEST] <Mavrik> gnome1, there are corner cases which aren't well documented or specified which cause problems [22:06:49 CEST] <Mavrik> like where IDR frames have to be when doing quality switching, length of segments, etc. [22:06:59 CEST] <gnome1> yeah, corner cases are something I'd expect [22:08:44 CEST] <gnome1> and there's caching, I've seen streams that stutter, or that show delays when changing segments, or longer delays when starting up apparently because one of the variants is down [22:08:59 CEST] <gnome1> and most of the time I'd just like to sit down and be able to enjoy the stream :-) [22:09:13 CEST] <gnome1> it's already good that it can be played somehow without running any browser [22:15:19 CEST] <TD-Linux> Mavrik, the reason is IPR as usual. [22:16:04 CEST] <gnome1> doesn't make sense, but in this world I've seen enough not to question lack of sense [22:16:20 CEST] <gnome1> like suing pocket music player manufacturers because they can be used to play music [22:17:18 CEST] <furq> i can't help but notice that you have an "o" in your nick [22:17:24 CEST] <furq> that might infringe on my patent for rounded corners in nicks [22:17:40 CEST] <furq> please cease & desist [22:18:05 CEST] <Mavrik> ö? [22:18:35 CEST] <furq> i was thinking more like ¡ [22:34:59 CEST] <andrey_utkin> jkqxz, you have consulted me about debugging of broken h.264 stream, would you be so kind to look at my results? https://gist.github.com/andrey-utkin/73fb8975b8f18178a43a https://gist.github.com/andrey-utkin/1e0a2a85e4f039fe5ae3 [23:17:28 CEST] <lmeadors> i'm trying to create encrypted HLS content from an unencrypted m4a file and failing miserably [23:18:19 CEST] <lmeadors> i have a 128 bit key: `openssl rand 16 > my.key` [23:18:50 CEST] <lmeadors> i created a key info file with a url and a reference to that key in it [23:19:28 CEST] <BtbN> I still wonder what the point of encrypting video with a well known AES key is. [23:19:38 CEST] <lmeadors> i found a couple of SO posts where people were telling how to do it, but neither seem to be working quite right [23:21:42 CEST] <lmeadors> one of them creates a beautiful m3u8 file, but no encryption is applied (even less useful than encrypting video with a well known AES key) [23:21:54 CEST] <Mavrik> BtbN, content provider requirements :P [23:22:16 CEST] <lmeadors> the other appears to encrypt yhe content, but only includes the last 5 segments :| [23:28:19 CEST] <lmeadors> i can post my script somewhere if anyone has time to look at it - i'm hoping it's just me missing something dumb [23:31:21 CEST] <lmeadors> the command is this: [23:31:22 CEST] <lmeadors> ffmpeg -i test_source/tin_pan_ally.m4a -c:a libmp3lame -b:a 128k -map 0:0 -f segment -segment_time 30 -hls_key_info_file output/tin_pan_ally.keyinfo -segment_list output/tin_pan_ally.m3u8 -segment_format mpegts 'output/output-%03d.ts' [23:31:40 CEST] <lmeadors> the key info file looks like this: [23:31:54 CEST] <lmeadors> http://my_host_prefix/output/tin_pan_ally.key [23:31:54 CEST] <lmeadors> output/tin_pan_ally.key [23:32:44 CEST] <lmeadors> but the m3u8 file hos no reference to that url in it :/ [23:32:59 CEST] <lmeadors> but the m3u8 file has no reference to that url in it :/ [23:54:41 CEST] <lmeadors> this is using ffmpeg version 2.8.6, btw [23:56:57 CEST] <lmeadors> i guess i can try to ghetto it out and manually encrypt the ts files and add the line to the m3u8 file [23:57:04 CEST] <lmeadors> seems lame, but it might work [00:00:00 CEST] --- Tue Mar 29 2016

1 0

ffmpeg-devel.log.20160327
by burek 28 Mar '16

28 Mar '16

[00:10:21 CET] <cone-609> ffmpeg 03Marton Balint 07master:8ff0f6ae8253: avformat/segment: set format options for all segments [05:05:22 CEST] <cone-186> ffmpeg 03Michael Niedermayer 07master:c50be7a52bc1: avcodec/h264_slice: Check PPS more extensively when its not copied [05:21:54 CEST] <cone-186> ffmpeg 03Kieran Kunhya 07master:e259dc86a803: avcodec: Remove libdcadec, we already have it merged internally [05:33:47 CEST] <llogan> kierank: is libfaac next on your list? [05:33:54 CEST] <kierank> probably [05:34:14 CEST] <llogan> anything else? [05:39:20 CEST] <jamrial_> wasn't there a reason we didn't remove libfaac last time we cleaned house with external aac encoders? [05:40:18 CEST] <llogan> none that i can recall [05:56:17 CEST] <llogan> kierank: add x264opts vs x264-params to the list [05:56:33 CEST] <kierank> make a wiki page =p [05:56:46 CEST] <llogan> I don't know how [05:58:37 CEST] Action: llogan hopes the lie will allow current level of laziness/worthlessness to continue [06:40:35 CEST] <llogan> what's the difference between prores and prores_lgpl decoders? [06:49:53 CEST] <dinux5> How should I use tools/patcheck? Please help. :) [06:51:05 CEST] <llogan> dinux5: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-March/192192.html [06:52:12 CEST] <llogan> or you could probably do "tools/patcheck 0001-Mlp-encoder-addition.patch" [06:55:16 CEST] <dinux5> llogan: Alright. Thanks! :) [06:56:17 CEST] <llogan> dinux5: also, take a look in patcheck and read the paragraph that describes it [06:59:14 CEST] <dinux5> Sure. [07:56:49 CEST] <llogan> dinux5: the "Frequently ignored answer" paragraph in Michael's email was just a "signature" and was not a direct message for you [08:10:39 CEST] <dinux5> Oops. Ok :D [11:35:38 CEST] <cbsrobot> Very off topic but maybe some anime folks like it: https://opentoonz.github.io/ [11:38:38 CEST] <JEEB> ok, so they finally did the release [11:39:26 CEST] <JEEB> oh, dwango owns it [11:39:29 CEST] <JEEB> funky [11:40:12 CEST] <cbsrobot> and it's bsd licensed [11:46:02 CEST] <ubitux> interesting stuff @ https://github.com/opentoonz/opentoonz/tree/master/toonz/sources/image i suppose [17:47:43 CEST] <atomnuker> jamrial: will backport all the AAC patches to 3.0 tommorow (they were all relatively unobtrusive) [17:54:49 CEST] <jamrial> atomnuker: tell michaelni so he waits before tagging the 3.0.1 release :p [21:17:43 CEST] <durandal_170> anyone gonna review dca_core bsf? [21:19:28 CEST] <wm4> durandal_170: it doesn't even say what it does anywhere, why would anyone review it? [21:21:37 CEST] <durandal_170> it extracts core of dts frames [21:28:52 CEST] <andrey_utkin> Hi! Could anybody interested please look, confirm or comment - is that a bug or not, that H.264 concatenation using MPEG TS format is broken? http://trac.ffmpeg.org/ticket/5380#comment:4 Maybe I should file a different ticket? [21:29:40 CEST] <andrey_utkin> and what is supposed to work, and what is not. If there's a bug, what to fix. [21:30:31 CEST] <Compn> are you talking about mpegts or mp4>mpegts ? [21:31:07 CEST] <Daemon404> some of that bug is a bit wtf [21:31:08 CEST] <Daemon404> > -i orig.mp4 -c copy -bsf:v h264_mp4toannexb -y bsf.mp4 [21:31:11 CEST] <Daemon404> why would yu ever do this [21:31:15 CEST] <Daemon404> this isnt even a legal mp4 [21:31:28 CEST] <Compn> lol [21:32:27 CEST] <Daemon404> and concating mp4 files is not legal either [21:33:36 CEST] <andrey_utkin> Daemon404, what i want is to join videos. Initially I was going to "precache" everything (and that's a lot for out application) in MPEG TS, but then I thought, "why wouldn't we just bitstream-filter that so that extradata is duplicated in each keyframe, because MP4 -> MPEGTS -> concat (MPEGTS) -> MP4 works" [21:34:24 CEST] <andrey_utkin> apparently at MPEGTS -> MP4 conversion different extradata at IDRs doesn't get thrown away so that merged videos from different encoders doesn't break playback [21:34:37 CEST] <Daemon404> concatting h264 in any format which does not allow multiple sps/pps is very error prone (the clips must have the exact same properties) [21:34:41 CEST] <Daemon404> mp4 is one of those formats [21:35:01 CEST] <andrey_utkin> properties - like framerate and resolution? [21:35:10 CEST] <Daemon404> the entirety of the extradata [21:35:11 CEST] <Compn> take h264 raw [21:35:18 CEST] <Compn> then use mp4 tools to mux it [21:35:22 CEST] <Compn> dont use ffmpeg. [21:35:31 CEST] <andrey_utkin> extradata - yes, tricky, but it kinda works in practice [21:35:41 CEST] <Daemon404> it cant work if it difefrs for mp4 [21:35:47 CEST] <Daemon404> because mp4 stores it *once* for the whole clip [21:35:54 CEST] <Daemon404> itll be broken if it differs between concat'd clips [21:36:18 CEST] <Daemon404> watchign a concatted mpegts is fine however. [21:36:32 CEST] <Daemon404> remuxing said mpegts is nto guaranteed to work if it has multiple diffring sps/pps. [21:36:41 CEST] <Daemon404> to mp4, i mean. [21:37:47 CEST] <andrey_utkin> how could i learn what is in extradata, and what isn't? [21:37:59 CEST] <Compn> read mp4 sepc\ [21:38:00 CEST] <Compn> spec* [21:38:13 CEST] <Compn> if you havent read mp4 spec you shouldnt be playing. [21:38:17 CEST] <Daemon404> if you are generating your own encodes, x264 has an option to allow concatenation [21:38:27 CEST] <Daemon404> suppposing you encode using the exact same settings. [21:41:55 CEST] <andrey_utkin> Daemon404, could you please give a hint what's that x264 option? [21:42:11 CEST] <Daemon404> --stitchable [21:43:24 CEST] <andrey_utkin> would anybody of you, gentlemen, consider consulting me time to time on such questions of h264 concat? not for free. [21:46:44 CEST] <Compn> andrey_utkin : stick around, some dev may take you up on your consulting offer. [21:47:08 CEST] <Daemon404> keep in mind is is easter sunday [21:47:11 CEST] Action: Daemon404 is in fatc leaving now too [21:47:23 CEST] <andrey_utkin> sure :) [21:48:11 CEST] <andrey_utkin> thank you Daemon404 and Compn, you helped a lot [21:48:26 CEST] <andrey_utkin> have a nice Easter [21:55:54 CEST] <andrey_utkin> funny, with -x264opts stitchable=1 results of my weird test stay the same. "illegal" mode is the only which works :) all other have artifacts [21:56:21 CEST] <andrey_utkin> -x264opts stitchable=1 was used at creation of input video clips of course [22:03:12 CEST] <jamrial> durandal_170: the dca_core bsf seems to work wih every sample i tried, and the output is the same as eac3to's [22:04:16 CEST] <durandal_170> I wonder where to find le and 14 variants [22:06:03 CEST] <jamrial> those are usually dts in wav [22:07:12 CEST] <Daemon404> andrey_utkin, do NOT concat mo4 files directly [22:07:22 CEST] <Daemon404> concat the elementary annexb streams, and mux that t mp4 [22:07:23 CEST] <Daemon404> to* [22:08:31 CEST] <andrey_utkin> Daemon404, by concat the ES you mean to make .h264 container-less files? [22:08:59 CEST] <andrey_utkin> like ffmpeg -i 1.mp4 -c copy -bsf:v h264_mp4toannexb 1.h264 ? [22:09:14 CEST] <Daemon404> what? [22:09:31 CEST] <andrey_utkin> could you please elaborate what exactly are you proposing to do? [22:09:31 CEST] <Daemon404> cat 1.h264 2.h264 > out.j264 [22:09:34 CEST] <Daemon404> mux out.h264 [22:09:44 CEST] <Daemon404> why on earth would you have x264 output a mp4 [22:09:58 CEST] <andrey_utkin> ok, and in order to obtain 1.h264 i should do what i have written above? [22:10:06 CEST] <Daemon404> ... [22:10:15 CEST] <Daemon404> i thought you were encoding the damn files yourself [22:10:22 CEST] <Daemon404> output to an elementary stream [22:11:56 CEST] <andrey_utkin> fine, it's just that there are legacy 'deployments' with mp4 files. So I guess it is legal to do what i supposed for mp4 -> h264. [22:13:27 CEST] <andrey_utkin> ok, so you think concat on containerless h264 files should work better. Thanks for the idea, will try now. [22:19:58 CEST] <andrey_utkin> yep that works cleanly. I wonder why that doesn't happen correctly in case of using containers. MP4 (please don't kill me) should carry the same amount of media information, and concat demuxer passes all H.264 streams through h264_mp4toannexb BSF internally. [23:42:39 CEST] <cone-965> ffmpeg 03Paul B Mahol 07master:0b9957c3019a: avfilter/vf_waveform: move mirror variable into function argument [23:42:39 CEST] <cone-965> ffmpeg 03Paul B Mahol 07master:48be92e5b684: avfilter/vf_waveform: optimize lowpass 8bit filter [00:00:00 CEST] --- Mon Mar 28 2016

1 0

ffmpeg.log.20160327
by burek 28 Mar '16

28 Mar '16

[00:01:37 CET] <_Timon> it started with ~2000kbps but then after 5 minutes it dropped down to 139kbps? [00:01:41 CET] <_Timon> How does that work [00:03:14 CET] <Mavrik> It adjusts according to complexity of the scene. [00:03:19 CET] <Mavrik> To keep constant quality. [00:03:40 CET] <Mavrik> If you have a static image then there's nothing to encode. [00:07:59 CET] <_Timon> "ffmpeg -i 1.mp4 1_fix2.mp4 -vf "yadif=1:1,hqdn3d=2,format=yuv420p" -deinterlace -crf 23" [00:08:15 CET] <_Timon> input file = 4:2:2@L# output file is the same [00:08:27 CET] <_Timon> seems like it's not catching the "format=yub420p" part? [00:08:55 CET] <_Timon> yuv* [00:09:31 CET] <_Timon> I think i'm double deinterlacing with that line aswell [00:09:59 CET] <_Timon> yadif is also deinterlace it seems [00:14:09 CET] <_Timon> neither format=yuv420p nor -pix_fmt yuv420p is changing the pixel format... im done for tonight, gn. [01:02:35 CET] <krompus> hey all! I'm trying to record some screencasts, but the compressionis really high, and I could stand to have slightly larger filesize. I'm not sure what settings I should use. My bitmap fonts' colours look awful. [01:03:10 CET] <krompus> I'm using Teiler, if it makes a difference [01:03:24 CET] <krompus> https://github.com/carnager/teiler [01:04:26 CET] <krompus> right now, the profile is set to encopts="-r 60 -vcodec libx264 -pix_fmt yuv420p -s $res -acodec libmp3lame" [01:05:02 CET] <krompus> also, is there a way to get it to play nice with compton, or should I just disable it before? I get visual glitches. [01:07:57 CET] <sfan5> i'd suggest adding a crf to that command line [01:08:17 CET] <krompus> crf? [01:09:23 CET] <sfan5> controls the quality x264 aims at [01:09:29 CET] <krompus> ah [01:09:40 CET] <krompus> example number for high quality? [01:09:50 CET] <J_Darnley> default is 23 [01:10:02 CET] <sfan5> you have to try yourself [01:10:02 CET] <krompus> higher = higher quality? [01:10:04 CET] <J_Darnley> good/high quality is around 18 [01:10:12 CET] <sfan5> lower -> higher q. [01:10:14 CET] <krompus> gotcha [01:10:19 CET] <sfan5> 20 might be a good start [01:10:28 CET] <krompus> yeah, i intend to tinker with it. [01:15:00 CET] <krompus> sfan5: alright, it's much better, but the colours are still washed out [01:15:22 CET] <krompus> probably because I'm using bitmap fonts; doesn't compress well [01:15:43 CET] <krompus> considering that they are 1 pixel thick, lol [01:16:05 CET] <sfan5> you could try -pix_fmt yuv444p [01:16:20 CET] <sfan5> uses a higher resolution for some color channels, should look better [01:17:10 CET] <krompus> sfan5: AH! [01:17:12 CET] <J_Darnley> Better a bitmapped font rather than subpixel anti-aliasing. [01:17:14 CET] <krompus> much better! [01:17:41 CET] <krompus> yeah, i had have crf set to 0, lol [01:17:52 CET] <krompus> ...i'll work it down a little bit. [01:18:08 CET] <sfan5> 0 is lossless so it should look perfect [01:18:11 CET] <J_Darnley> Although if the text isn't black/white then AA makes less difference. [01:18:17 CET] <krompus> yeah, that's what I was testing [01:18:33 CET] <krompus> the colours are still off a little bit. Light red looks orangey, for example [01:18:39 CET] <krompus> it's acceptable though [01:19:43 CET] <J_Darnley> ooh [01:20:14 CET] <J_Darnley> now it sounds like you need to read about colour matricies [01:20:49 CET] <J_Darnley> Video is a never ending rabbit hole if you actually care about quality [01:22:19 CET] <krompus> haha [01:22:22 CET] <krompus> uh oh [01:22:40 CET] <krompus> yeah, I've already got one leg in the hole [01:23:01 CET] <krompus> I've already switched to FLAC and BrRips [01:23:34 CET] <krompus> and I converted my little brother who used to watch shitty 700MB movies [01:23:47 CET] <krompus> :P [01:24:20 CET] <krompus> He kept telling me he didn't care, and then I showed him. His reaction: "OHHHHHHHHHH!" [01:25:14 CET] <krompus> hmm [01:25:37 CET] <krompus> so, i'm chatting with the teiler dev, we're trying to work out some profiles [01:25:53 CET] <krompus> he says: "a little warning: yuv444p wont work with every video size [01:25:55 CET] <krompus> " [01:26:05 CET] <krompus> "it needs a factor of 8" [01:26:07 CET] <krompus> hmm [01:27:21 CET] <krompus> any other suggestions to get the colours slightly better? It's still a little washed out [01:27:40 CET] <krompus> MUCH better though! I'm just seeing how far I can take it. [01:29:26 CET] <J_Darnley> 444 has no subsampling [01:29:39 CET] <J_Darnley> it will work with more video sizes than 420 [01:30:06 CET] <J_Darnley> 420 reduces the size of both chroma planes by half vertically and half horizontally [01:31:20 CET] <J_Darnley> My ultimate suggestion for colours is to know what ffmpeg is doing and make sure your player is doing the same in reverse [01:31:26 CET] <J_Darnley> The first is hard [01:31:55 CET] <J_Darnley> You have RGB input, right? [01:32:00 CET] <J_Darnley> Some sort of screen cap? [01:32:51 CET] <J_Darnley> In that case ffmpeg is probably doing a conversion to TV levels [01:33:14 CET] <J_Darnley> you must ensure that the player converts back to full range [01:33:33 CET] <krompus> oh gosh. I know some of these words [01:33:35 CET] <J_Darnley> The usual symptom with this is poor contrast [01:34:02 CET] <J_Darnley> Follow the white rabbit, Neo. [01:34:06 CET] <krompus> :P [01:34:14 CET] <J_Darnley> low contrast in typical video [01:34:38 CET] <J_Darnley> with bold colours I guess "washed out" might describe that too [01:35:07 CET] <krompus> well, my display is pretty high contrast https://ptpb.pw/FmOF.png [01:35:32 CET] <krompus> i'm not sure what you're referring to [01:35:52 CET] <krompus> here, I'll scrot the video during playback [01:36:14 CET] <krompus> https://ptpb.pw/KsBj.png [01:36:32 CET] <krompus> A/B those. [01:36:35 CET] <krompus> see what I mean? [01:36:37 CET] <krompus> it's close [01:37:16 CET] <krompus> it's like it's "rounding" the colours [01:37:41 CET] <J_Darnley> Yes, I see it in the pink text in the top-right [01:37:50 CET] <krompus> yep yep. it's pretty obvious there [01:38:21 CET] <J_Darnley> I don't think this is TV vs PC levels [01:38:23 CET] <krompus> anyways, not a huge deal, but it would be nice if I could "enhance" so to meme [01:38:38 CET] <J_Darnley> I think it is a difference in colour matix being used. [01:38:53 CET] <krompus> (disclaimer: I'm not very familiar with ffmpeg, so please ELI5) [01:38:58 CET] <krompus> well [01:39:01 CET] <J_Darnley> i'm getting there [01:39:09 CET] <krompus> not ELI5, but talk to me like a layperson [01:39:11 CET] <krompus> hahaha [01:39:20 CET] <krompus> you don't have to explain everything [01:39:23 CET] <krompus> :) [01:39:47 CET] <J_Darnley> In the very old days ffmpeg would always 601 for yuv<->rgb conversion. [01:40:01 CET] <J_Darnley> ( If you really want to know: https://en.wikipedia.org/wiki/YCbCr ) [01:40:21 CET] <J_Darnley> 601 is the usual matrix used for SD content [01:40:33 CET] <J_Darnley> 709 is usually usef ror HD content [01:40:37 CET] <J_Darnley> *used [01:41:01 CET] <krompus> ahh [01:41:14 CET] <J_Darnley> I can't remember whether the choice of colour matrix was ever added to ffmpeg (specifically swscale) [01:41:31 CET] <J_Darnley> I would guess that ffmpeg is using 601 [01:41:47 CET] <J_Darnley> Then you player is using 709 because it is HD [01:42:00 CET] <krompus> ahh [01:42:10 CET] <J_Darnley> libx264 has a methos for signalling which matrix should be used by the player/decoder [01:42:14 CET] <J_Darnley> *method [01:42:26 CET] <krompus> yeah, i'm all hd; it would be nice to use 701 [01:42:31 CET] <J_Darnley> let me look that up [01:42:37 CET] <krompus> awesome; brb [01:44:18 CET] <J_Darnley> Perhaps the scale filter does let you control it: http://ffmpeg.org/ffmpeg-filters.html#scale-1 [01:45:29 CET] <J_Darnley> specifically the in/out_color_matrix options [01:47:40 CET] <J_Darnley> Oh god. Why is there both x264opts and x264-params? [01:49:09 CET] <J_Darnley> Anyway, I think you want to pass the colormatrix option to one of those. [01:49:51 CET] <krompus> how do? [01:51:03 CET] <J_Darnley> Possibly: -x264opts colormatrix=bt709 [01:52:33 CET] <J_Darnley> Well that does not result in an error [01:53:35 CET] <krompus> http://img2.wikia.nocookie.net/__cb20100427134246/half-life/en/images/b/b8/… [01:54:08 CET] <J_Darnley> Basically, yes [01:54:22 CET] <J_Darnley> We even red text in ffmpeg [01:54:31 CET] <J_Darnley> (Which people still ignore) [01:56:10 CET] <krompus> y u no read error [01:56:55 CET] <J_Darnley> ah. "This option is functionally the same as the x264opts, but is duplicated for compatibility with the Libav fork" [01:57:04 CET] <J_Darnley> That explains that. [04:28:23 CEST] <squarecircle> ohai [04:28:45 CEST] <squarecircle> Does someone can tell me where I'm lost? [04:29:03 CEST] <squarecircle> I try to understand the difference between height and coded_height [04:40:32 CEST] <J_Darnley> At a guess: the height of the video/content vs the height produced by the encoder/decoder [04:41:32 CEST] <squarecircle> so if I decode it, I get the coded_height? [04:41:58 CEST] <squarecircle> because actually I'm creating a raw stream [04:42:26 CEST] <squarecircle> and its quite important to know exactly how many bytes I have to read [04:46:55 CEST] <squarecircle> well I'll try [04:47:00 CEST] <squarecircle> tomorrow [04:47:05 CEST] <squarecircle> thanks [05:01:00 CEST] <Guest_24552> does anyone in here have any clue on how I could detect steganography in a recompressed video? [05:01:33 CEST] <Guest_24552> I have an issue right now where I want to tell if a video has hidden information within its pixel data [05:01:52 CEST] <Guest_24552> and I have an ad-hoc approach that works for slow moving videos [05:02:00 CEST] <Guest_24552> if the algorithm is known [05:02:18 CEST] <Guest_24552> but generally what features of a video are "normal"? [05:04:05 CEST] <Guest_24552> like I know people add intentional modifications to videos; special effects, blurring, lighting and video composition [05:04:25 CEST] <Guest_24552> but how do I separate such intentional effects from unintentional ones [05:04:38 CEST] <Guest_24552> ones that may be malicious [05:04:53 CEST] <Guest_24552> blindly [05:05:43 CEST] <jmack> Is there a specific version of FFMPEG for Mint: Rosa? [05:06:21 CEST] <thebombzen> jmack: I'd just compile it from source. that's what I did on my mint box [05:07:27 CEST] <jmack> So v3.0 just needs to be compiled ans then run? [05:11:28 CEST] <jmack> Should I install in main filesystem or in portable mode i.e. /home/username/sources ? [05:24:03 CEST] <thebombzen> jmack: just run ./configure <options>, make, sudo make install [05:24:06 CEST] <thebombzen> you know [05:24:07 CEST] <thebombzen> the normal way [05:24:31 CEST] <thebombzen> keep in mind that stuff from the repos linked to libav will not see ffmpeg's stuff. so if you want mplayer for example I'd build that from source too [05:25:43 CEST] <jmack> thebombzen: Thanks, this is my first time on any kind of chat [05:34:55 CEST] <jmack> thebombzen: I'm so tired of trying to capture /Desktop with avconv, I get nothing but errors (segmentation fault) and frustration [05:36:08 CEST] <llogan> jmack: you could just download a binary http://johnvansickle.com/ffmpeg/ [05:36:27 CEST] <llogan> oh, wait, that probably doesn't have x11grab support [05:36:32 CEST] <llogan> i can't remember [05:36:52 CEST] <llogan> or see http://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [05:38:22 CEST] <jmack> llogan: your right it doesn't have non-free support [05:44:39 CEST] <jmack> llogan: I saw that page and book marked it I think it'll come in handy [05:45:41 CEST] <jmack> thebombzen: Where would I get the source for mplayer? [05:46:26 CEST] <jmack> thebombzen: Do you have a link on hand? [05:47:20 CEST] <llogan> you can probably just use the repo "ffmpeg" to provide the dependencies for other repo junk, and use your compiled ffmpeg binary for capturing the desktop [05:49:55 CEST] <thebombzen> just google "mplayer" and poke around a bit [05:50:01 CEST] <jmack> thebombzen: Is there an easyway to link stuff like mplayer to FFMPEG? [05:50:19 CEST] <thebombzen> yea. if you compile it from source then it'll look in /usr/local/lib before /usr/lib [05:50:41 CEST] <thebombzen> so if you compiled ffmpeg from source (make sure you do the dynamic build, not static) then build mplayer it should automatically use that one [05:51:01 CEST] <thebombzen> if you want to be extra careful, don't install the development files for libav. that way pkg-config will only see ffmpeg [05:52:30 CEST] <llogan> jmack: maybe Mint isn't the best fit for you if you want newer stuff and are wanting to compile. [05:53:46 CEST] <jmack> thebombzen: But what if I want to use libmp3lame, don't you have to install libmp3lame-dev files? [05:54:45 CEST] <jmack> llogan: What would be a better linux for newer stuff? [05:55:42 CEST] <thebombzen> llogan: although he seems like a Linux beginner, so I'd say mint is alright [05:56:03 CEST] <thebombzen> jmack: Arch Linux always has the latest stuff. but it's not for Linux beginners [05:56:22 CEST] <thebombzen> and yes, you'd have to install lame-dev [05:57:02 CEST] <thebombzen> but LAME is not libav. I meant don't install libavcodec-dev and related packages. [05:58:56 CEST] <jmack> thebombzen: Ok, I've been tinkering with Linux Ubuntu since 6.06 and before that Suse, Redhat, Slackware and some others [05:59:15 CEST] <thebombzen> odd that you haven't built stuff from source then [06:00:48 CEST] <llogan> jmack: Arch keeps up with upstreams well. but it takes work to setup and slightly more work to maintain. [06:01:33 CEST] <jmack> thebombzen: I'm not a MOTU or Mr. Moneybags, (or I'd have a $200 Windows 10 maybe) I just need some minor stuff... [06:02:18 CEST] <thebombzen> either way, Arch requires you to build stuff from source all the time [06:02:26 CEST] <jmack> thebombzen: I never said I haven't compiled stuff, it's just been a while since I needed to... [06:03:09 CEST] <thebombzen> anyway you can build ffmpeg the way you build everything else then [06:03:23 CEST] <thebombzen> just do yourself a favor and disable the static libraries [06:03:39 CEST] <jmack> thebombzen: I looked into Arch but it didn't seem as organized as the rest of the distro's out there [06:04:11 CEST] <jmack> thebombzen: Disable static, roger that! [06:05:16 CEST] <jmack> thebombzen: Arch seems to be very hands on and right now I don't have a lot of free time to [06:05:54 CEST] <jmack> thebombzen: Do everything everybodu wants me to do. [06:09:32 CEST] <jmack> thebombzen & llogan: Thanks guys...I really appreciate your help. [06:19:34 CEST] <jmack> thebombzen: Well it looks like I'm going to have to get my hands dirty if I hope to get anything done, this stuff has changed so much since I first started doing this. This is what I get for getting to used to that stupid "Software Manager" Aarg! [06:24:56 CEST] <deweydb> I can't figure out what i'm doing wrong here, i'm trying to strip the audio from this file and re-encode as mp4. my command line output is: http://pastebin.com/mDjKFHRv and the input file is: https://www.dropbox.com/s/vbrtjodlo7fjqj4/C31-8x14.AVI?dl=1 and my output is always a broken (unplayable) video: https://www.dropbox.com/s/8ukfrcwfhzjiklg/1459052554-no-audio.mp4?dl=1 [06:28:31 CEST] <deweydb> hmmm added -pix_fmt yuv420p and seems to play now. ok. [06:28:35 CEST] <deweydb> i guess i'm just dumb [06:28:56 CEST] <c_14> Then I guess your player is just shitty [06:29:08 CEST] <deweydb> ehhh i was testing with just spacebar in osx [06:29:15 CEST] <deweydb> which i guess is kinda a shitty player [06:29:25 CEST] <c_14> Most non-ffmpeg based players only support yuv420p [06:29:32 CEST] <c_14> Also most hardware players/mobile etc [06:29:56 CEST] <deweydb> good to know. thanks [06:30:12 CEST] <llogan> i'm not aware of any non-FFmpeg that do support other than 420 [14:59:24 CEST] <kszere> Hi, I need convert multiple file from *.ts to *.mkv with multiple source audio and video. Output file must be cut start and end time. How I do it? [15:05:43 CEST] <gnome1> I've been transcoding to 768x576, but in some places people mention 720x576 for PAL, which is not 4:3. Does it matter that much if I use 768 instead, is there some reason not to use 768x576? it's mostly to view in a computer, although it'd be nice if it could be played in a TV somehow. [15:07:53 CEST] <J_Darnley> 720x576 is not 4:3 thanks to the glory of anamorphic video. [15:35:07 CEST] <kszere> Hi, I need convert multiple file from *.ts to *.mkv with multiple source audio and video. Output file must be cut start and end time. How I do it? [15:48:07 CEST] <J_Darnley> I still have no clue what half of that means. [15:48:28 CEST] <J_Darnley> to convert ts to mkv: ffmpeg -i input.ts -c copy output.mkv [15:51:30 CEST] <furq> gnome1: 720*576 is anamorphic pal dvd [15:52:01 CEST] <furq> if you're ripping dvds then you're best off not resizing at all and setting the aspect ratio in the container [15:54:10 CEST] <Filarius> how to fix "non-monotonous DTS in output stream" ? [15:59:35 CEST] <DHE> Filarius: using stream copy? or re-encoding? [15:59:44 CEST] <gnome1> furq: nah, I'm downscaling wider videos, mostly "HD" frame sizes [16:00:53 CEST] <gnome1> perhaps the rescaling should be seen in a case-by-case basis for each source, to make sure it's done in the best way possible, but I doubt it will cause a big problem unless I'm watching less than 1m from the screen? [16:01:24 CEST] <furq> shrug [16:01:30 CEST] <furq> i just use spline16 for everything [16:01:42 CEST] <furq> or bicubic for blocky sources [16:02:00 CEST] <gnome1> hm, I'm using the default, whatever that is [16:02:12 CEST] <gnome1> IIRC the help said it'd be 4, and that seemed to be "experimental" [16:02:39 CEST] <gnome1> experimental or nearest neighbor, depending if you start counting from 1 or 0 [16:09:30 CEST] <furq> the default with sws is bilinear or bicubic, i forget now [16:09:39 CEST] <furq> zscale is better if you have that compiled in [16:11:18 CEST] <gnome1> is that the zimg-based scaler? I could enable that. how does it perform speed-wise and quality-wise compared to bilinear and bicubic? [16:12:58 CEST] <furq> it seems roughly as fast as swscale [16:13:18 CEST] <furq> swscale has spline/lanczos etc but zscale is apparently better [16:13:30 CEST] <furq> according to the people in here who can tell the difference [16:18:23 CEST] <Filarius> DHE, "non-monotonous DTS" error while re-encoding HLS stream, what was recorded by ffmpeg with "copy" encoder, and its also have some related error [16:18:41 CEST] <Filarius> also here "past duration too large" errors [16:25:50 CEST] <gnome1> I can't find zscale, so I probably need to enable something, now I wonder what, the zimg option I saw doesn't seem to be there for this version [16:30:03 CEST] <kszere> @J_Darnley Thanks. [16:33:36 CEST] <kszere> How files cut start and end time also with convert to *.mkv from *.ts? What I can add to this command: "ffmpeg -i input.ts -c copy output.mkv"? [16:36:58 CEST] <relaxed> kszere: read about the -ss, -t, and -to [17:53:17 CEST] <andrey_utkin> Hi! we have some hardware which generates h264 stream which is sometimes broken, and we generate frame headers manually. Sometimes the garbage sent by hardware confuses mplayer/ffplay/whatever, and decoder likely doesn't recover from that (despite we send I-frames quite frequently). What could be done to stream to make decoder to recover? Maybe declare IDR point? How to do that? By sending SPS&PPS again? [18:29:05 CEST] <jkqxz> andrey_utkin: Are your I frames actually IDR frames there or not? (They aren't the same thing; an I frame on its own isn't necessarily sufficient to recover.) [18:30:53 CEST] <jkqxz> If they are actually IDR frames they should generally be immediately preceeded by SPS and PPS NAL units; if they aren't then adding them will make it definitely-recoverable at that point. [18:31:44 CEST] <andrey_utkin> jkqxz, thanks [18:32:20 CEST] <andrey_utkin> jkqxz, that's why i asked - i don't quite know what's diff between I and IDR. The code which generates headers is this, you may take a look https://github.com/bluecherrydvr/linux/blob/tw5864/drivers/staging/media/tw… [18:32:43 CEST] <andrey_utkin> jkqxz, is it correct that SPS+PPS+Iframe = IDR? [18:32:57 CEST] <andrey_utkin> or SPS+PPS+Iframe-with-something-special? [18:39:01 CEST] <jkqxz> IDR frames are made up of IDR slices (NAL unit type 5), all other frames are made up of non-IDR slices (NAL unit type 1). The type there affects the slice header encoding. [18:41:19 CEST] <jkqxz> Writing the NAL unit type there, you have "**buf = (frame_seqno_in_gop == 0) ? 0x25 : 0x21;". So you begin every GOP with a IDR [18:51:18 CEST] <jkqxz> The stream from this device is fixed-QP? [18:52:05 CEST] <jkqxz> (If not, you'll need to set slice_qp_delta to something other than zero.) [18:55:05 CEST] <andrey_utkin> yes, i set QP once and don't change the value [18:55:26 CEST] <andrey_utkin> so i have IDR type NAL? [18:56:09 CEST] <andrey_utkin> i think i send SPS+PPS just once [18:57:47 CEST] <jkqxz> The code looks like it does the right thing, as far as I can tell. But yes, you should send the SPS+PPS before every IDR frame. [18:58:35 CEST] <andrey_utkin> jkqxz, thank you so much [19:05:10 CEST] <jkqxz> For the other part of your problem, where something causes it to go wrong initially, I suggest capturing the stream from the beginning to the point where it fails. Then you can examine it offline to work out what the problem is. [19:11:23 CEST] <andrey_utkin> jkqxz: that is good advice, but i have repeatedly asked during last year for help with debugging h264 stream issues - for stream analysis tools and for personal paid support, with no success. I always had stream dumps when i was asking :-) [19:14:23 CEST] <jkqxz> If you wrote the code you just showed yourself, you should have sufficient knowledge to do it. ffmpeg and the reference decoder are the only tools you actually want here. [19:19:58 CEST] <andrey_utkin> jkqxz: i disagree. At last wireshark-alike parser/presenter would help a lot [19:39:55 CEST] <jkqxz> If your stream is obviously broken, then reading the trace output of the reference decoder at the point where it fails is exactly what you want to do. [20:04:22 CEST] <Mavrik> jkqxz, is there a reference decoder implementation somewhere in ffmpeg source tree? [20:09:03 CEST] <jkqxz> No. It would be certainly nice if the reference decoder could be called directly from ffmpeg, but right now you can just dump the elementary stream and then feed that to the reference decoder (and if you can't get that far then you have more obvious problems to pursue). [20:18:24 CEST] <andrey_utkin> jkqxz, are you talking about this software? http://iphome.hhi.de/suehring/tml/download/ [20:20:29 CEST] <jkqxz> Yes. [21:17:35 CEST] <fturco> hello. i'm trying to back up my dvds with ffmpeg. [21:17:45 CEST] <fturco> my current command is: ffmpeg -i alien-1.vob -map 0:0 -map 0:2 -metadata:s:a language=ita -codec copy test.vob [21:18:16 CEST] <fturco> the problem is the resulting audio track is not marked as italian when i play it with mplayer [21:18:43 CEST] <fturco> it says 128 unknown [21:25:49 CEST] <andrey_utkin> fturco, what's the point on coverting if you can just copy? you are not changing the format as I see [21:26:12 CEST] <andrey_utkin> of you are trying to enhance it? [21:27:02 CEST] <fturco> i don't want to re-encode my dvds. just copy video and audio streams as-is and eventually remux them in a different container format [21:27:10 CEST] <fturco> i would choose mkv but i have problems with it [21:28:00 CEST] <fturco> original vob file contains extra audio tracks and subtitles that i don't want [21:30:34 CEST] <andrey_utkin> fturco, i meant why not "cp alien-1.vob backup/alien-1.vob" [21:31:07 CEST] <fturco> andrey_utkin, that is not good because alien1.vob contains extra audio tracks and subtitles that i want to remove [21:31:10 CEST] <andrey_utkin> throwing away unneeded stuff, ok, understand [21:32:11 CEST] <fturco> i'm not sure about how to properly use the -metadata option [21:35:20 CEST] <fturco> i originally tried mkvmerge but it causes audio-video desync [21:48:37 CEST] <J_Darnley> fturco: I would guess that you don't set language with the generic metadata option. [21:49:43 CEST] <fturco> J_Darnley, i also tried with -metadata:s:a:0 language=ita, to no avail [21:50:19 CEST] <J_Darnley> Although I also wonder whether the vob muxer supports metadata/language at all [21:50:50 CEST] <furq> i'm pretty sure that metadata is in the ifo [21:51:32 CEST] <fturco> J_Darnley, i would prefer to use matroska, but i get the following error message with it: Can't write packet with unknown timestamp [21:51:54 CEST] <fturco> that error goes away if using the -fflags +genpts options [21:52:01 CEST] <fturco> but then the process is very slow [21:52:58 CEST] <fturco> i can't think of any other container i could use [21:54:55 CEST] <J_Darnley> Sorry. I don't have any useful suggestions. [21:55:13 CEST] <fturco> J_Darnley, no problem [21:58:13 CEST] <J_Darnley> Well the massive ffmpeg help page does suggets that using metadata is the right way [21:58:38 CEST] <J_Darnley> Either it is unused by the muxer or it belongs in the ifo as furq suggested. [21:59:56 CEST] <furq> fturco: mpegts should work, although i don't really recommend it [22:00:57 CEST] <furq> i'm not sure why -fflags +genpts is causing a slowdown for you, it doesn't here [22:01:20 CEST] <fturco> the output file size is not growing constantly [22:01:26 CEST] <fturco> it is stuck [22:01:35 CEST] <furq> with mkv? [22:01:36 CEST] <furq> weird [22:01:40 CEST] <fturco> yes [22:02:05 CEST] <fturco> i had to stop it [22:03:07 CEST] <fturco> it is stuck at 240mb [22:03:31 CEST] <furq> that sounds like a bug if it works with other muxers [22:04:25 CEST] <fturco> now it stopped at 784mb [22:04:43 CEST] <fturco> it doesn't continuously update progress [22:31:10 CEST] <jasonsu> Hi. I want to use ffmpeg to single-line generate sine wav test tones into mp3 files. I need a given frequency, 30 secs long, 44.1KHz sampling rate, normalized to 0Db. I've been trying to piece together various bits and keep stumbling :-( [22:31:11 CEST] <jasonsu> Right now I try: [22:31:21 CEST] <jasonsu> ffmpeg -f lavfi -i "sine=frequency=1000:sample_rate=44100:duration=30:volume=0dB" -acodec mp3 -b:a 192k out.mp3 [22:31:27 CEST] <jasonsu> But it complains about "Option 'volume' not found". Can anyone lend a hand? just want to get this working. [22:32:40 CEST] <J_Darnley> It doesn't have one. [22:33:09 CEST] <jasonsu> J_Darnley: Sorry, what doesn't have what? [22:33:20 CEST] <J_Darnley> sine does not have a volume option [22:33:33 CEST] <jasonsu> How do I normalize to 0db? [22:34:04 CEST] <J_Darnley> Juding from the docs: apply a gain of 8x [22:34:33 CEST] <jasonsu> J_Darnley: ? Would you mind point me at that? [22:34:37 CEST] <jasonsu> ing [22:34:51 CEST] <J_Darnley> http://ffmpeg.org/ffmpeg-filters.html#volume [22:38:31 CEST] <jasonsu> sorry, don't see anything about gain = 8x there. I do see "level [22:38:31 CEST] <jasonsu> Auto level output signal. Default is enabled. This normalizes audio back to 0dB if enabled. " [22:41:31 CEST] <J_Darnley> volume=8 if I read it correctly [23:47:23 CEST] <stemid> hey I'm in a weird situation with some old mp3 files that show up as just "Audio file with ID3 version 2.3.0" and work in my android, and then I have some other files show up as "Audio file with ID3 version 2.4.0, contains: MPEG ADTS, layer III, v1, 64 kbps, 44.1 kHz, Stereo" and not work. [23:47:28 CEST] <stemid> how can I replicate the first type? [23:47:50 CEST] <stemid> doing just ffmpeg -i file.wav -f mp3 gives me the second type [23:48:33 CEST] <Mavrik> What does ffprobe say on both? [23:48:38 CEST] <stemid> let me see [23:48:40 CEST] <andrey_utkin> i'd check encoder & muxer settings [23:48:49 CEST] <J_Darnley> I think there's an option for controlling the ID3 version [23:51:43 CEST] <stemid> https://paste.fedoraproject.org/345867/91154531/ this is the file that my android cannot discover in spotify/google play/sonos apps. https://paste.fedoraproject.org/345868/15456145/ this one works everywhere. [23:54:06 CEST] <Mavrik> Strange. [23:54:23 CEST] <stemid> yeah I'm not an audio wiz but I can't see any weird differences [23:54:58 CEST] <stemid> Ghost Commander app can play the first mp3 file btw. so maybe it's DRM [23:55:01 CEST] <stemid> I wouldn't rule that out [23:55:17 CEST] <stemid> because I've only tried major apps, not vlc for example. [23:57:04 CEST] <stemid> yup works in vlc [23:57:19 CEST] <stemid> this is sad, I wanted to play it on my Sonos speaker. must be stupid DRM [00:00:00 CEST] --- Mon Mar 28 2016

1 0

ffmpeg-devel.log.20160326
by burek 27 Mar '16

27 Mar '16

[00:00:01 CET] <nevcairiel> that looks fine [00:11:23 CET] <atomnuker> oh wow, huge vf_colormatrix and swscale patches [00:12:31 CET] <michaelni> Theres a student searching for a mentor for "Integration of Subtitles into libavfilter" (https://summerofcode.withgoogle.com/dashboard/organization/6504812191416320…) [07:09:08 CET] <Timothy_Gu> ethe: https://gist.github.com/TimothyGu/23ec15872465cd295444 [07:12:09 CET] <Timothy_Gu> ethe: partially done translation: http://sprunge.us/SRJB. it doesn't work fully yet, and I can't find time to fix it [08:23:42 CET] <relaxed> is Carl Hoyos in this channel? [10:02:50 CET] <wm4> relaxed: he rarely is [10:20:30 CET] <cone-180> ffmpeg 03Martin Vignali 07master:495f08edb444: avcodec/exr: add support for B44 and B44A compression [11:04:04 CET] <cone-180> ffmpeg 03Michael Niedermayer 07master:c06bdc60c90d: avformat/rtpdec: Remove stray debug av_log() [11:20:01 CET] <Gramner> apparently someone dumped all the internal facebook iOS headers. there's some quality enterprise design principles there, like https://github.com/quellish/Facebook-iOS-Internal-Headers/blob/master/Heade… [11:20:38 CET] <Gramner> also 18.000+ classes in one app, because it's web-scale [11:32:36 CET] <sfan5> does it use node.js? [11:32:40 CET] <sfan5> otherwise it's not true web-scale [11:32:42 CET] <sfan5> also mongodb [11:53:38 CET] <wm4> Gramner: holy shit what [11:53:52 CET] <wm4> that's truly enterprise [12:18:17 CET] <thardin> looks like I was right about that bad mxf file [12:24:49 CET] <ethe> thanks Timothy_Gu [12:55:11 CET] <Compn> relaxed : cehoyos is his irc nick, but he frequently reads the irc logs [12:55:14 CET] Action: Compn waves at carl [14:50:49 CET] <cehoyos> Hi, did we already inform vlc that the mail-hunk is not working? [14:51:02 CET] <cehoyos> (Or our mail-admins?) [14:56:48 CET] <michaelni> cehoyos, what ? [14:57:38 CET] <cone-180> ffmpeg 03Carl Eugen Hoyos 07master:de1a0d43595b: lavc/flicvideo: Implement padding in COPY chunks. [14:58:05 CET] <cehoyos> michaelni: http://ffmpeg.org/pipermail/ffmpeg-cvslog/2016-March/date.html does not show todays commits. [15:08:44 CET] <michaelni> who messed with the ffmpeg-cvslog filter rules last time ? [15:10:42 CET] <michaelni> either way ive disabled the rule that i belived caused this [15:12:30 CET] <RiCON> michaelni: 19:10:37 < llogan@> due to spam the cvslog entries for web commits may be delayed because messages "from" ffmpeg-cvslog are not set to go to queue until i make an appropriate filter [15:18:32 CET] <michaelni> what spam ? [15:19:31 CET] <michaelni> also it blocked everything not just web [15:23:21 CET] <ethe> cehoyos: the attachment for "[PATCH] remove the hls_wrap option" looks fine [15:23:39 CET] <cehoyos> michaelni: [15:24:06 CET] <cehoyos> michaelni:http://ffmpeg.org/pipermail/ffmpeg-cvslog/2016-March/098804.html http://ffmpeg.org/pipermail/ffmpeg-cvslog/2016-March/098930.html [15:24:43 CET] <cehoyos> ethe: It looks broken here: http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/192157.html [15:24:51 CET] <michaelni> ahh, i guess my spam filter filters these [15:25:00 CET] <cehoyos> And here: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/212297 [15:25:34 CET] <ethe> cehoyos: the attachment is fine though [15:26:04 CET] <ethe> cehoyos: https://gist.github.com/joshdekock/4fc616b2de2f500a4db5 [15:28:08 CET] <cehoyos> Three applications here believe that the mail has no attachments... [15:29:19 CET] <cehoyos> Ok, found the patch in one of the mail parts, I still believe it can look better in pipermail with little effort. [15:35:32 CET] <ethe> cehoyos: odd. I'm using thunderbird and it said there was an attachment [15:51:11 CET] <cehoyos> ethe: Yes, I just missed it, sorry! [16:36:34 CET] <cone-180> ffmpeg 03Dan Dennedy 07master:28688d7c2b53: avcodec/audiotoolboxenc: Fix compile error on OS X 10.8. [17:34:38 CET] <cone-180> ffmpeg 03Michael Niedermayer 07master:d4424d7de2c9: fate: Modify a random h264 test to also test the -framerate option [17:34:39 CET] <cone-180> ffmpeg 03Michael Niedermayer 07master:5a19506088c3: fate: Remove vsync drop from some h264 tests [18:08:30 CET] <durandal_1707> whats tep2 merge status? [18:08:50 CET] <durandal_1707> have all demuxers been updated? [18:35:50 CET] <wm4> durandal_1707: see etherpad [18:39:34 CET] <Compn> did anyone ever want to mail a hd with samples ? [18:39:41 CET] <Compn> i forgot if i ever got a response. [18:39:58 CET] <Compn> for money of course [18:40:08 CET] <Compn> for some reason we get requests for samples on hd [18:40:15 CET] <Compn> once in a while [18:41:42 CET] <ethe> As in, people ask FFmpeg for sample outputs on a hard drive? [18:42:00 CET] <JEEB> probably something like the FATE samples archive [18:42:02 CET] <Compn> for a copy of http://samples.ffmpeg.org on a hd. [18:42:08 CET] <ethe> oh right [18:42:25 CET] <Compn> i asked this guy what price he wants to pay and what country he is in [18:58:52 CET] <J_Darnley> Last time you asked I lacked a spare harddrive, the samples, and you never said how quickly the guy wanted it. [18:58:59 CET] <J_Darnley> I still lack those first two. [19:30:42 CET] <rcombs> what, throttled internet service? [20:21:47 CET] <Compn> J_Darnley : the person never responded. [20:21:59 CET] <Compn> rcombs : mostly i'd guess people are just confused by the README file [20:22:05 CET] <Compn> into thinking thats the only way to get a copy [20:22:09 CET] <Compn> some people are just weird though [20:22:13 CET] Action: rcombs points at wget [20:22:35 CET] <rcombs> (this I say without looking at the readme) [20:22:44 CET] <Compn> i'd be more afraid of not having the actor age information on any porn clips ... which is why i dont send hds full of clips :P [20:22:50 CET] <Compn> from the uuusssayyy [20:49:32 CET] <RiCON> rcombs: the readme says "if you're thinking of downloading the whole thing, please limit yourself to 50kB/s" [20:58:19 CET] <ethe> rcombs: rsync is suggested as well (over wget I presume) [21:33:00 CET] <wm4> lol drama [21:34:38 CET] <J_Darnley> now what? [21:38:12 CET] <llogan> wm4: does it have to do with a CoC? [21:38:24 CET] <atomnuker> nope [21:39:25 CET] Action: llogan is too hungover to care about drama [21:42:50 CET] <llogan> michaelni: Can you take a look at "Spam Filter Rule 3" in cvslog? I think if I set it to Discard then that should stop spam. i had it set to hold just for testing. [21:45:55 CET] <michaelni> llogan, i suggest to leave it on "hold" for a bit longer to ensure nothing valuable gets discarded [21:46:45 CET] <llogan> i'll give it a week on Hold then. [21:46:54 CET] <michaelni> thx [21:49:49 CET] <llogan> michaelni: also, i removed ffmpeg-cvslog@ffmpeg from auto hold due to filter #3 [21:55:25 CET] <kierank> BBB: https://software.intel.com/en-us/articles/google-vp9-optimization [21:55:27 CET] <kierank> (lol) [21:57:12 CET] <JEEB> intel poking libvpx, I see [21:59:42 CET] <wm4> is it still slower than lavc? [22:00:46 CET] <kierank> ah they are optimising for atom [22:00:50 CET] <kierank> where pshufb is sloooooow [22:03:29 CET] <BBB> hm... [22:03:31 CET] <BBB> so... [22:03:39 CET] <BBB> where is the numbers? [22:03:52 CET] <BBB> I mean, all I see is car sales terms like very, significant, impressive and lasting" [22:03:58 CET] <kierank> The team improved user-level performance by up to 16 percent (6.2 frames per second) in 64-bit mode and by about 12 percent (1.65 frames per second) in 32-bit mode. [22:04:00 CET] <BBB> horizon, expanded" [22:04:10 CET] <BBB> ah, ok, so its hidden somewhere [22:04:15 CET] <BBB> 32bit? omg [22:04:17 CET] <BBB> poor people [22:04:24 CET] <BBB> so wheres the results versus ffvp9? :-p [22:04:39 CET] <BBB> last time I checked we were 30% faster on x86-64 [22:04:41 CET] <JEEB> they were probably just told to optimize chromium's decoding [22:04:47 CET] <JEEB> so welp [22:05:06 CET] <BBB> chromeos? [22:05:11 CET] <kierank> no it's for android [22:05:11 CET] <BBB> I mean, why else bother with 32bit [22:05:13 CET] <kierank> in software [22:05:15 CET] <BBB> ah [22:05:17 CET] <kierank> on atoms on phones [22:05:33 CET] <JEEB> yeah, android is IIRC 32bit user space + 64bit kernel on intel atm [22:05:36 CET] <BBB> then use ffvp9 *ding ding* [22:05:54 CET] <JEEB> that would make sense and require actual work on switching components in Chromium :D [22:07:03 CET] <BBB> hiring intel to optimize libvpx is less effort than switching chrome to ffvp9 as they did for ffvp8? [22:07:11 CET] <BBB> maybe [22:07:26 CET] <nevcairiel> maybe intel volunteered to push atom performance [22:09:23 CET] <jamrial> maybe they could do the same for ffvp9. all of the atom optimized simd functions were added some time ago for a couple decoders, then nobody with it bothered again [22:10:17 CET] <jamrial> "pmaddubsw xmm1, xmm16" uhh [22:10:21 CET] <jamrial> wonder if whoever wrote that article has been playing with avx512 too much :p [22:12:12 CET] <BBB> atom :-p [22:17:12 CET] <jkqxz> That's the first time I've ever seen the name "Tremont". [22:18:23 CET] <jkqxz> Ha, and Google agrees <https://www.google.co.uk/#q=intel+goldmont+%22tremont%22>... [22:20:50 CET] <Gramner> possibly the 10nm shrink then [22:24:08 CET] <jkqxz> Or just another "we haven't managed to make any significant changes yet but marketing demands a new version" release. [22:24:56 CET] <BBB> I remember talking to some intel engineers at the vp9 summit last year [22:25:09 CET] <Gramner> true. could be a "refresh" with some minor bug fixes/tweaks and a new codename slapped on [22:25:16 CET] <BBB> I tried to explain to them some of the techniques that make ffvp9 much faster than libvpx (they were generally working on libvpx optimizations back then) [22:25:26 CET] <BBB> they didnt understand all too much of it, sadly :( [22:36:15 CET] <cone-609> ffmpeg 03KO Myung-Hun 07release/3.0:9e4d297ba74c: MAINTAINERS: add myself as an OS/2 maintainer [22:36:15 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:c3e7a7ef3f85: swscale/x86/output: Move code into yuv2planeX_mainloop [22:36:15 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:be5acd6cb1f3: swscale/x86/output: Fix yuv2planeX_16* with unaligned destination [22:36:15 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:c4765a41b956: avcodec/h264: Execute error concealment before marking the frame as done. [22:36:15 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:bd79dbfa2b8f: avutil/pixdesc: Make get_color_type() aware of CIE XYZ formats [22:36:16 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:ca5c6394461e: swscale/input: Fix GBRAP16 input [22:36:16 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:fb8676eb1cdd: swscale/utils: Fix chrSrcHSubSample for GBRAP16 [22:36:17 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:0d7343f8ddf6: avcodec/mjpegdec: Fix decoding slightly odd progressive jpeg [22:36:17 CET] <cone-609> ffmpeg 03Rodger Combs 07release/3.0:bf8f2fae2ad8: lavf/mov: fix sidx with edit lists (cherry picked from commit 3617e69d50dd9dd07b5011dfb9477a9d1a630354) [22:36:18 CET] <cone-609> ffmpeg 03Rodger Combs 07release/3.0:3b179b630253: lavf/mov: downgrade sidx errors to non-fatal warnings; fixes trac #5216 (cherry picked from commit 22dbc1caaf13e4bb17c9e0164a5b1ccaf490e428) [22:36:19 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:b4be953c5596: avformat/cache: Fix memleak of tree entries [22:36:20 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:27a61302b792: fate/aac: Increase fuzz from of fate-aac-pns-encode from 72 to 74 for Loongson [22:36:21 CET] <cone-609> ffmpeg 03foo86 07release/3.0:da6ccfe18ebb: avcodec/dca: clear X96 channels if nothing was decoded [22:36:22 CET] <cone-609> ffmpeg 03Boris Nagels 07release/3.0:56c4dca5ae78: avformat/rtpenc: Fix integer overflow in NTP_TO_RTP_FORMAT [22:36:23 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:756f4b586ae7: avformat/utils: fix dts from pts code in compute_pkt_fields() during ascending delay [22:36:24 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:64f2b48be062: avformat/concatdec: set safe mode to enabled instead of auto [22:36:25 CET] <cone-609> ffmpeg 03Martin Cracauer 07release/3.0:934bc32accae: avutil/channel_layout: AV_CH_LAYOUT_6POINT1_BACK not reachable in parsing [22:36:26 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:c8977ec6e9b0: avutil/random_seed: Add the runtime in cycles of the main loop to the entropy pool [22:36:27 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:e1589367128a: avformat/hlsenc: Fix passing options, regression since bc9a5965c815cf7fd998d8ce14a18b8e861dd9ce [22:36:28 CET] <cone-609> ffmpeg 03Luca Barbato 07release/3.0:b0e836466f2a: indeo2data: K&R formatting cosmetics [22:36:29 CET] <cone-609> ffmpeg 03Luca Barbato 07release/3.0:53fffc9fc4f2: indeo2: Fix banding artefacts [22:36:30 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:bf80b1d88d39: avcodec/resample: Remove disabled and faulty code [22:36:31 CET] <cone-609> ffmpeg 03Mark Thompson 07release/3.0:d6adcab84280: lavc/hevc: Allow arbitrary garbage in bytestream as long as at least one NAL unit is found. [22:36:32 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:50a639a62aa3: avcodec/mjpegenc_common: Store approximate aspect if exact cannot be stored [22:36:33 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:0fae52d7e37a: avformat/file: Add crypto to default whitelist [22:36:34 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:e15a48d35afa: avformat/mpegtsenc: Keep track of the program for each service [22:36:35 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:6e5648ad42b7: avformat/mpegtsenc: Fix used service [22:36:36 CET] <cone-609> ffmpeg 03Ico Doornekamp 07release/3.0:daa6dc0a3b39: avformat/rtpdec_jpeg: fix low contrast image on low quality setting [22:36:37 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:2d0e415482ca: avcodec/libutvideodec: copy frame so it has reference counters when refcounted_frames is set [22:49:37 CET] <cone-609> ffmpeg 03Michael Niedermayer 07release/3.0:526c7b21865f: Update for 3.0.1 [22:55:05 CET] <jamrial> atomnuker: you didn't backport any of the aac or vc2 patches yet [00:00:00 CET] --- Sun Mar 27 2016

1 0

ffmpeg.log.20160326
by burek 27 Mar '16

27 Mar '16

[01:40:23 CET] <deweydb> hey guys, i was wondering if anyone could give me some tips. i am taking a couple stills from video clips programatically using ffmpeg. right now i have been just grabbing the frames at % intervals through the video. but often they are kind of blurred with motion. i was thinking maybe i could somehow only grab the screenshot at the nearest keyframe. is there a way to search for keyframes? [01:42:45 CET] <furq> deweydb: https://ffmpeg.org/ffmpeg-filters.html#Examples-95 [01:43:09 CET] <deweydb> is an I frame the same thing as a keyframe? [01:43:15 CET] Action: deweydb is a bit of a video noob [01:44:23 CET] <furq> it's close enough [01:46:41 CET] <TD-Linux> for your purposes, you actually want I frames not keyframes [01:49:10 CET] <deweydb> yeah that worked pretty good. there's still the odd frame thats motion blurred. perhpas i could do some sort of image analysis to check if its a motion blurred frame and discard it. [01:49:27 CET] <deweydb> ffmpeg -i IMG_0583.MOV -vf "select=eq(pict_type\,I)" -vsync vfr -qscale:v 1 thumbnails-%02d.jpeg [01:49:31 CET] <deweydb> was what i tried. [01:51:17 CET] <furq> you can try select='gt(scene\,0.5)' if you only want scene cuts [01:51:26 CET] <furq> tweak 0.5 as needed [01:52:45 CET] <deweydb> the input is always one long shot. [01:53:22 CET] <deweydb> i'm guessing by scene cuts you mean if it is a bunch of clips put together. [01:53:58 CET] <furq> 0.5 is the fraction of the frame that has to have changed from the previous frame [01:54:24 CET] <furq> but yeah that doesn't sound like it'll work [02:00:50 CET] <deweydb> this seems to work pretty good [02:00:51 CET] <deweydb> https://gist.github.com/shahriman/3289170 [02:01:06 CET] <deweydb> i can just pick out the best ones based on blurextent [02:59:11 CET] <yongyung> If movies (or, ehem, "films") have 2:35 aspect ratio, why are so many people encoding them in 1920x800 instead of 1920x816? Oo [02:59:42 CET] <furq> because people are bad [03:00:14 CET] <furq> that is also my answer for most other questions [03:01:59 CET] <furq> https://en.wikipedia.org/wiki/Anamorphic_format#2.35.2C_2.39_or_2.40.3F [03:02:01 CET] <yongyung> I mean that just seems monumentally weird to me. 816 is: divisible by 16 (and 8 obviously), 1920/816 is almost exactly 2.35, and perfectly enough it's even just slightly more (or, slighly less pixels than would be needed) so that even if movies have a not perfectly even cut on the black bars you'll probably still get an even cut out of it [03:02:11 CET] <furq> maybe it's because of that as well, but that also goes back to my previous answer [03:02:12 CET] <yongyung> Just seems super weird that people use 1920x800 [03:02:31 CET] <deweydb> yongyung: difference between movies and hdtv [03:02:56 CET] <deweydb> ohhh wait i see what you are saying now [03:02:59 CET] <deweydb> yeah, its pretty dumb. [03:03:21 CET] <deweydb> i guess maybe because most people have 1080p screens [03:03:28 CET] <deweydb> or 16:9 screens i should say [03:03:49 CET] <deweydb> not sure what happens when you try to open a 1920/816 video full screen in vlc. [03:03:56 CET] <deweydb> on a 1080p screen [03:04:04 CET] <deweydb> does vlc put bars there for you? [03:04:09 CET] <furq> yes [03:04:17 CET] <deweydb> heh. well then i guess its just stupidity [03:04:29 CET] <deweydb> maybe because source video is already at 1080p [03:04:39 CET] <furq> no i'm pretty sure it's because of that wikipedia link i just pasted [03:05:30 CET] <yongyung> deweydb: Notice I wrote 1920x800 not 1920x1080 [03:05:30 CET] <deweydb> that is like pure gibberish to me [03:05:39 CET] <deweydb> that link [03:05:41 CET] <deweydb> wooosh [03:05:59 CET] <deweydb> yongyung: i did notice that. [03:06:16 CET] <deweydb> ohhh wait [03:06:18 CET] <deweydb> no i didn't [03:06:18 CET] <deweydb> lol [03:06:20 CET] <yongyung> furq: So is that link supposed to tell me that modern films are actually shot in 2.39 not 2.35 or? [03:06:43 CET] <furq> The initial SMPTE definition for anamorphic projection...is 2.3468&:1 which rounded to the commonly used value 2.35:1. A new definition was issued in October 1970 (PH22.106-1971) which specified a slightly smaller vertical dimension of 0.700 in. for the projector aperture...This new projector aperture size, 0.838 × 0.700 inches (21.3 × 17.8 mm), aspect ratio 1.1971&:1, made for an un-squeezed ratio of 2 [03:06:45 CET] <yongyung> If that's the case 1920x800 would make sense [03:06:49 CET] <furq> .39:1 (and commonly referred to by the rounded value 2.40:1 or 2.4:1). [03:09:38 CET] <furq> i can't imagine the encoders do anything other than a straight crop [03:10:05 CET] <furq> unless the scene still mandates mod16 [03:10:35 CET] <furq> which wouldn't surprise me because, as i've mentioned, people are bad [04:08:29 CET] <brick> so sad, i hope you find one IHAVENONICK [07:39:33 CET] <deweydb> is this answer correct? http://stackoverflow.com/questions/5930296/adding-repeated-background-audio… [07:39:40 CET] <deweydb> it is not possible to loop audio input stream? [07:39:51 CET] <deweydb> without using external application? [13:06:21 CET] <kannan> Hello [13:07:26 CET] <kannan> do ffmpeg support RTMP feeds ? [13:08:17 CET] <hpp_> Hi guys. I want to convert .mpg video to .mkv using constant quality 25 (h.264) and opus audio codec 128Kbps. how to do this in console? (windows 10) [13:10:45 CET] <furq> kannan: yes [13:11:27 CET] <furq> hpp_: -i src.mpg -c:v libx264 -q:v 25 -c:a libopus -b:a 128k out.mkv [13:14:48 CET] <kannan> Hi furq, I am trying to sent feed from my Open Broadcast software to ffserver, but getting error :info: [rtmp stream: 'adv_stream'] Connecting to RTMP URL rtsp://xx.xx.xx.xx:5454/feed1.ffm... [13:14:48 CET] <kannan> info: Unknown protocol! [13:15:20 CET] <furq> that's not an rtmp url [13:15:30 CET] <furq> also i have no idea if ffserver supports rtmp, it's old and unmaintained [13:16:16 CET] <furq> if you want to rebroadcast an rtmp stream then you probably want https://github.com/arut/nginx-rtmp-module [13:17:01 CET] <kannan> ok.. let me check that, thanks [13:21:59 CET] <Azrael_-> hi [13:22:47 CET] <Azrael_-> is there a windows-build available which can encode aac? i tried the standard build and it tells me "Unknown encoder 'libfdk_aac'" [13:23:05 CET] <J_Darnley> "-acodec aac" [13:23:11 CET] <furq> binaries containing fdk-aac can't be distributed due to licensing issues [13:23:35 CET] <furq> the builtin encoder is acceptable quality if you have a recent build [13:23:45 CET] <Azrael_-> k, thx [14:36:00 CET] <Azrael_-> i try to stream a video to an rtmp-server. on linux the command works fine but on windows with the same command i get this error output: ffmpeg -re -i test264.mp4 -c copy -f flv rtmp://myuser:mypw@somedomain.com:1936/live2/_mystream_ error: Problem accessing the DNS. (addr: live2) the connection it self works from the windows-machine, verified with openbroadcaster. any ideas how to proceed? [14:36:53 CET] <Azrael_-> *itself [14:39:51 CET] <Azrael_-> how can i run it on windows? [14:53:19 CET] <furq> Azrael_-: change the url to "rtmp://abc.de:1936/live2/streamname pubUser=live2 pubPasswd=mypassword" [14:53:25 CET] <furq> including the quotes [14:53:36 CET] <furq> apparently that url format doesn't work on windows [15:02:34 CET] <Azrael_-> thanks, now the connection seems to start. but now i get this error: RTMP_ReadPacket, failed to read RTMP packet header this only happens on windows, onlinux it is fine [15:02:53 CET] <Azrael_-> i'm using the same video-file on both instances [18:54:13 CET] <andrey_utkin> regarding http://trac.ffmpeg.org/ticket/5380 . I am concat-ing h264 videos of different origins, and what I was trying to achieve is to prepare MP4 files with all extradata duplicated in each keyframe, as it goes in MPEGTS. When I concat MPEGTS (generated from input MP4s), then remux the resulting MPEGTS to MP4, it works fine. So what I'm trying to achieve is to save remuxing to and from MPEGTS. I wonder if it is possible with bitstream filter [18:56:02 CET] <Dariush> Hi, guys. I'd like some help. I have two videofiles, a.mp4 and b.mp4 . Both are completely valid and play in all videoplayers. I want to concat them. If I make input.txt with only "file 'a.mp4'" in it, the file gets copied as expected. If I do the same with "file 'b.mp4'", ffmpeg dies with "input.txt: Invalid argument". Here is the complete output of both commands: http://pastebin.com/RpuX7BrM Why [18:56:03 CET] <Dariush> is this happening? [18:57:00 CET] <andrey_utkin> Dariush, haha [18:57:04 CET] <andrey_utkin> see http://trac.ffmpeg.org/ticket/5380 [18:57:11 CET] <andrey_utkin> have reported just today [18:57:27 CET] <andrey_utkin> Carl Eugen Hoyos has submitted a patch for it today [18:57:53 CET] <Dariush> the videos weren't created with ffmpeg, but recorded with OBS [18:58:25 CET] <Dariush> moreover, with the same OBS version and the same settings on two consecutive days [19:00:38 CET] <andrey_utkin> Dariush, doesn't matter [19:00:44 CET] <Dariush> hm, I see it: [mov,mp4,m4a,3gp,3g2,mj2 @ 00000000004acd00] Auto-inserting h264_mp4toannexb bitstream filter [19:00:46 CET] <andrey_utkin> just apply the patch [19:00:55 CET] <andrey_utkin> let me find it for you [19:01:25 CET] <andrey_utkin> Subject: [FFmpeg-devel] [PATCH]lavc/h264_mp4toannexb: Do not fail if frame [19:10:28 CET] <sagax> hi all [19:11:17 CET] <sagax> i try set metadata with -i metadata.txt -map_metadata 1 but not get metadata in output [19:11:54 CET] <sagax> how to set metadata with text file? [19:12:57 CET] <sagax> i try this http://jonhall.info/how_to/dump_and_load_metadata_with_ffmpeg but this don't working [19:14:54 CET] <sagax> ok, one moment [19:16:09 CET] <sagax> http://susepaste.org/86432143 [19:16:53 CET] <sagax> 19 string it's my meta [19:16:54 CET] <J_Darnley> Well I think you have the right idea. [19:17:04 CET] <sagax> in input stream [19:17:20 CET] <sagax> but in output metadata don't have [19:17:33 CET] <J_Darnley> I don't know whether ffserver will actually output any metadata [19:17:38 CET] <sagax> and i not see metadata in ffprobe, [19:18:14 CET] <J_Darnley> Oh, are you looking to get "STREAMTITLE" copied aswell? [19:18:47 CET] <J_Darnley> I think you need to use somemore advanced specifier for that. [19:19:24 CET] <sagax> i paste, one moment, [19:20:29 CET] <sagax> http://susepaste.org/55728568 [19:20:48 CET] <sagax> :D [19:21:39 CET] <J_Darnley> You can read about how you might do it by reading the map_metadata help here http://ffmpeg.org/ffmpeg.html [19:22:05 CET] <sagax> ok, try read more, thanks [19:22:11 CET] <J_Darnley> Since you're outputting ogg then I think I recall that you do need stream-based metadata [21:03:55 CET] <deweydb> is this answer correct? http://stackoverflow.com/questions/5930296/adding-repeated-background-audio… [21:04:01 CET] <deweydb> it is not possible to loop audio input stream? [21:04:05 CET] <deweydb> without using external application? [21:14:54 CET] <llogan> deweydb: that's an old answer. try -stream_loop input option. [21:15:41 CET] <deweydb> ok i just don't quite get where to add -stream_loop so it applies to only the audio but not the video [21:15:46 CET] <deweydb> say my blend command is: ffmpeg -i songs/short.mp3 -i 1459022124-output-no-audio.mp4 -c:v copy -c:a aac -strict experimental 1459022124-output.mp4 [21:16:09 CET] <deweydb> where do i put -stream_loop ? [21:16:17 CET] <llogan> before the first -i [21:16:26 CET] <llogan> so it applies to that input [21:16:48 CET] <llogan> -strict experimental is no longer needed [21:17:29 CET] <deweydb> Unrecognized option 'stream_loop' [21:17:32 CET] <deweydb> ma¥be i'm outdated [21:18:25 CET] <deweydb> http://pastie.org/10774746 [21:18:50 CET] <llogan> "Sorry, there is no pastie #10774746 or it has been removed." [21:19:53 CET] <deweydb> weird [21:20:08 CET] <deweydb> pastie glitchin out [21:20:31 CET] <deweydb> http://pastebin.com/Um8xrfF6 [21:21:06 CET] <llogan> the 2.8 release branch is probably too old for stream_loop [21:21:51 CET] <llogan> download a build from here: http://evermeet.cx/ffmpeg/ get the snapshot, not the release [21:24:49 CET] <deweydb> that worked but it looks like we proved the SO thread was correct [21:24:50 CET] <deweydb> http://pastebin.com/gBPw3yR0 [21:25:15 CET] <deweydb> "cannot be applied to output file songs/short.mp3" [21:25:23 CET] <llogan> you need to give it a value [21:25:30 CET] <llogan> http://ffmpeg.org/ffmpeg.html [21:25:41 CET] <llogan> search for stream_loop [21:26:50 CET] <durandal_1707> if that doesn't work use loop filters [21:27:26 CET] <llogan> IIRC, some users had trouble with stream_loop. i can't recall any details though. [21:27:54 CET] <deweydb> it stopped giving me errors but just doesn't actually loop. lol. [21:28:16 CET] <llogan> try the loop filter instead http://ffmpeg.org/ffmpeg-filters.html#loop_002c-aloop [21:37:23 CET] <mrmenacex> When making a DASH Manifest file with ffmpeg should that take a long time ? [21:44:28 CET] <mrmenacex> Ok another question when doing DASH playback does the audio track have to be separate ? [21:50:04 CET] <colde> mrmenacex: i don't believe it is stricktly required, but pretty much everybody does it that way, so you might find some clients can't handle them if they arent seperate [21:52:06 CET] <mrmenacex> colde: ok i'll try encoding just the audio and making another file. Thanks [21:56:52 CET] <colde> mrmenacex: well, depending on your workflow, you can encode them both and then split them later [21:57:03 CET] <colde> Some mpeg-dash segmenters ville also split it out from one input file [21:57:27 CET] <mrmenacex> colde: oh i forgot to say i'm using webm and the vp9 codec [21:58:01 CET] <mrmenacex> although i do want to do the same with h264 [21:58:25 CET] <mrmenacex> no browsers support h265 yet ? [22:08:28 CET] <colde> Not afaik. [22:42:00 CET] <_Timon> I have a ton of mp4 files here who dont work inside my video editing programs and dont work when playing them back on my pi with xbmc installed on it. Here's the video specs http://pastebin.com/PKx8Szfd [22:42:23 CET] <_Timon> What would be a more open codec/format what works on most devices that I can convert to with ffmpeg? [22:43:06 CET] <_Timon> These files do work when playing them back on my pc with vlc ofcurse [22:45:18 CET] <_Timon> This is the closest irc channel I know related to encoding things... [22:50:05 CET] <Mavrik> Your pixel format is causing the issues. [22:50:30 CET] <Mavrik> Only YUV 4:2:0 must be supported by H.264 players, while your video is 4:2:" [22:50:34 CET] <Mavrik> *4:2:" [22:50:37 CET] <Mavrik> eh... 4:2:2 [22:51:08 CET] <_Timon> I thought most modern playback devices could scale video? [22:51:46 CET] <Mavrik> Scale? [22:52:06 CET] <_Timon> nvm [22:52:09 CET] <Mavrik> It's not about the size. [22:52:14 CET] <_Timon> can I encode it to a different pixel format? [22:52:22 CET] <Mavrik> It's about the hardware decoding chip not supporting the pixel format. [22:52:29 CET] <Mavrik> Yep, add -pix_fmt yuv420p [22:52:52 CET] <_Timon> I'll try, thanks [23:04:34 CET] <llogan> _Timon: don't forget to stream copy the audio so you don't have to re-encode it: -c:a copy [23:05:07 CET] <_Timon> ill add that in the next batch :) [23:05:15 CET] <llogan> are these from VHS tapes? [23:05:23 CET] <_Timon> even older [23:05:58 CET] <llogan> interlaced? [23:06:03 CET] <_Timon> well, I think they fall under the vhs category [23:06:09 CET] <_Timon> but they're not these original large tapes [23:06:30 CET] <_Timon> p5 90mp 8mm [23:06:43 CET] <_Timon> casettes [23:07:01 CET] <llogan> Hi8 [23:07:16 CET] <_Timon> yep [23:07:23 CET] <llogan> you may want to deinterlace, maybe also denoise a little [23:07:59 CET] <_Timon> yes, they're quite heavily interlaced when looking at them [23:08:00 CET] <_Timon> is that fixable? [23:08:05 CET] <llogan> sure [23:08:21 CET] <Mavrik> Enable deinterlacer in player or deinterlace video when encoding :) [23:09:28 CET] <llogan> also, is there a weird discolored 7-10 pixel band on the bottom of the video? [23:09:58 CET] <Mavrik> Teletext? :P [23:10:12 CET] <_Timon> lol yep[ [23:10:14 CET] <_Timon> but I cut that out [23:10:16 CET] <llogan> head switching noise [23:10:27 CET] <_Timon> which is why I had the strange resolution [23:10:33 CET] <llogan> i usually just cover it [23:10:54 CET] <_Timon> This is my ffmpeg line when capturing [23:10:56 CET] <_Timon> ffmpeg -f dshow -i video="SMI Grabber Device":audio="Line In (Realtek High Definitio" -ac 1 -filter:v "crop=699:558:7:9" 1.mp4 [23:11:04 CET] <_Timon> if it interested you [23:11:32 CET] <_Timon> could I add that -pix_fmt yub420p during the capture? [23:11:37 CET] <Mavrik> probably wanna set quality settings for audio an dvideo. [23:11:41 CET] <llogan> vf "yadif=1:1,hqdn3d=2,drawbox=w=iw:h=10:y=ih-h:t=max,format=yuv420p" will deinterlace, apply some denoise, cover the noise, and deal with pixel format [23:11:42 CET] <Mavrik> bitrate and whatnot [23:12:05 CET] <_Timon> the file sizes are 'okay' atm [23:12:13 CET] <_Timon> about a gb per 60 minutes [23:13:05 CET] <llogan> i just put "2" there in denoise as an example, but i'm not sure if that's valid, so of course you'll want to tweak the values i put in the filters [23:13:16 CET] <_Timon> I'll do another transcode with that added logan [23:14:21 CET] <llogan> you may also want to compare yadif with other deinterlacers: w3fdif and bwdif. i haven't tried those yet. [23:16:41 CET] <_Timon> I'm not quite able to use your line logan [23:16:49 CET] <_Timon> does "vf" need to be included? [23:17:04 CET] <_Timon> doesnt seem like an ffmpeg suffix as far as I know [23:17:27 CET] <llogan> -vf is the same as -filter:v [23:17:33 CET] <_Timon> ah "-vf" [23:17:49 CET] <_Timon> yup my fault [23:19:31 CET] <_Timon> it's currently ~3450kbit/s [23:19:39 CET] <_Timon> I dont think it needs that much [23:20:23 CET] <llogan> it will use -crf 23 by default when encoding with libx264. you can increase the value to get fewer bits [23:20:44 CET] <_Timon> any value you recommend for these type of tapes? [23:21:03 CET] <llogan> use the highest value that still gives an acceptable quality. [23:21:06 CET] <Mavrik> _Timon, is it actuall 3.5Mbit on output? [23:21:12 CET] <_Timon> yep [23:21:16 CET] <Mavrik> Because crf 23 really shouldn't be that high on SD content :/ [23:21:24 CET] <_Timon> http://i.imgur.com/YvK2PKA.png [23:21:40 CET] <llogan> probably lots of noise [23:21:57 CET] <llogan> these old tapes are falling apart (i mean all of them in general) [23:22:04 CET] <_Timon> yep [23:22:08 CET] <_Timon> bad stuff [23:23:17 CET] <Mavrik> Ah, yeah [23:23:22 CET] <llogan> if you have another deck or player it may be able to play the tape better. some are just better at time base correction [23:24:02 CET] <_Timon> I'm not looking for the best of the best [23:24:18 CET] <llogan> home videos of your beagle? [23:24:38 CET] <_Timon> lol no [23:25:08 CET] <llogan> it may be worth cleaning the head and guides on the player [23:26:02 CET] <llogan> and watch for mold in the tape itself. you can see it through the clear plastic. white fuzz. it can inoculate the others if you play it [23:26:55 CET] <_Timon> "-deinterlace" would work? [23:27:01 CET] <_Timon> or do I need something specific [23:27:28 CET] <llogan> does that still exist? i think that maps to yadif. i prefer to keep all filtering confined to the filtergraph [23:27:51 CET] <llogan> so i can more easily apply the filters in the order i want [23:27:57 CET] <_Timon> yep seems to be working [23:28:05 CET] <_Timon> ok, now ill add the -crf [23:29:27 CET] <_Timon> crf 23 ~2700kbps [23:29:53 CET] <_Timon> somewhat better [23:30:34 CET] <_Timon> could I do all these filters in real time or do I need to transcode afterwards? [23:30:53 CET] <Mavrik> What do you mean? [23:31:09 CET] <Mavrik> If you added the filter to commandline they're already applied. [23:36:05 CET] <_Timon> yeah I'll just digitalise them first and apply filters afterwards [23:36:09 CET] <_Timon> otherwise im dropping frames [23:37:00 CET] <llogan> sounds like you're going to be performing two lossy encodes? [23:37:41 CET] <_Timon> I guess? [23:39:01 CET] <Mavrik> might wanna do losless capture then :) [23:39:35 CET] <_Timon> nvm it seems like my i7 is managing it [23:40:44 CET] <J_Darnley> POWAH! [23:40:49 CET] <_Timon> ffmpeg -f dshow -i video="SMI Grabber Device":audio="Line In (Realtek High Definitio" -ac 1 -filter:v "crop=699:558:7:9,yadif=1:1,hqdn3d=2,format=yuv420p" -crf 23 test.mp4 [23:40:57 CET] <_Timon> delivers a quite shaky output...? [23:41:07 CET] <llogan> J_Darnley: don't forget to press the "Turbo" button. [23:41:19 CET] <J_Darnley> :) [23:41:51 CET] <llogan> _Timon: shaky? [23:42:11 CET] <_Timon> going to test on another part of the tape, then ill confirm [23:45:12 CET] <_Timon> 4800 kbps? [23:46:03 CET] <_Timon> im removing the denoising etc see if that changes it [23:47:15 CET] <_Timon> bitrate went down, thats good [00:00:00 CET] --- Sun Mar 27 2016

1 0