Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

June 2017

1 participants
60 discussions

ffmpeg-devel.log.20170614
by burek 15 Jun '17

15 Jun '17

[00:00:01 CEST] <BBB> Im sure theres a reason for it but & who knows [00:00:26 CEST] <BBB> I would suggest to not get into that discussion but change it to 16384 for 8bit and be done with it ;) [00:00:37 CEST] <TMM> durandal_1707, so for the existing decode_map it seems that the demuxer creates another av_new_packet(), which gets read by ipvideo_decode_frame, could I send multiple of these packets to the decoder? [00:00:37 CEST] <BBB> gonna go home, will review patches tomorrow [00:00:42 CEST] <BBB> poke me if you need more help [00:01:09 CEST] <jdarnley> Bye and thank you again. [00:01:27 CEST] <BBB> happy to help [00:01:35 CEST] <BBB> Im really excited that youre doing this [00:01:44 CEST] <BBB> nobody ever wanted to do this, and I genuinely think its important [00:01:48 CEST] <BBB> just very tedious :( [00:01:58 CEST] <BBB> later :) [00:02:06 CEST] <TMM> is there maybe some documentation I should be reading? [00:02:39 CEST] <durandal_1707> multiple at once? [00:02:53 CEST] <wm4> TMM: just append what you need to the packet on the demuxer side [00:03:15 CEST] <wm4> it's not like there's a standard IP packet format, so you can put in there whatever you want [00:03:27 CEST] <durandal_1707> every packet should represent single decoded frame [00:05:49 CEST] <TMM> I don't think I understand where the video data goes [00:07:05 CEST] <TMM> so, there's no knowledge of the structure of IpvideoContext in the demuxer, right? [00:09:14 CEST] <TMM> oh... the codec does know about IPMVEContext [00:09:42 CEST] <TMM> IPMVEContext *ipmovie = s->priv_data; [00:09:56 CEST] <TMM> *sigh* wrong file [00:10:00 CEST] <TMM> nvm, sorry [00:17:57 CEST] <TMM> so this AVPacket->data thing is entirely up to the demuxer/codec to define? [00:18:47 CEST] <nevcairiel> yes and no, best is to stay close to the file format [00:21:54 CEST] <TMM> hmm, ok, but how do I send three different data streams to the video codec if not by placing it all in that field? [00:22:25 CEST] <BBB> is this a tripple video stream? [00:22:26 CEST] <TMM> the current format that's implemented requires 2 bits of data, the pixeldata, and the 'decoding map', I need to also send this 'skip map' [00:22:51 CEST] <BBB> sounds like a job for extradaat or so [00:22:57 CEST] <BBB> but what do I know [00:23:00 CEST] <TMM> the 0x11 format does this by sticking the decoding map into AVPacket->data [00:23:08 CEST] <TMM> BBB, infinitely more than me! :D [00:23:51 CEST] <TMM> ok, I'll see about this extradata thing then, it's not currently used I think [00:23:59 CEST] <TMM> I'll figure it out [00:24:24 CEST] <TMM> there's also AVPacketSideData? [00:32:30 CEST] <TMM> BBB, so this extradata goes into AVStream, right? but these maps change every frame, would it still make sense to stick it in there? [00:32:50 CEST] <michaelni> BBB, i remember tuning the 1638X thing to fix some issue, probably some artifacts caused by idct rounding difference aka greenish/pinkish blocks [00:32:59 CEST] <nevcairiel> if they change every frame then they are part of the frame itself, and should be in AVPacket as part of the frame [00:33:10 CEST] <nevcairiel> extradata is static once for the entire stream [00:33:42 CEST] <TMM> nevcairiel, so, it should just both go in pkt->data then? [00:34:05 CEST] <atomnuker> TMM: no, they get attached to the packet [00:34:38 CEST] <TMM> it seems currently the decode_map gets read into pkt->data [00:35:04 CEST] <TMM> if (avio_read(pb, pkt->data + 2, s->decode_map_chunk_size) <snip> [00:36:19 CEST] <TMM> so, that's wrong then? [00:38:31 CEST] <atomnuker> yep, it seems it does that [00:38:48 CEST] <atomnuker> this was written long before extradata was a thing I guess [00:39:09 CEST] <TMM> but I shouldn't use extradata? [00:39:18 CEST] <TMM> it's per-frame data [00:39:26 CEST] <wm4> (pretty sure extradata was always a thing) [00:40:23 CEST] <wm4> yeah, interplay was added after extradata became a thing [00:40:28 CEST] <TMM> ok, so what do I do? refactor this? The easy way out would be to stick the subcodec in the fourcc field, and just append the skipmap to pkt->data, but I guess this won't necessarily meet with much approval? :P [00:40:42 CEST] <wm4> with that useful fact I disappear again [00:42:27 CEST] <atomnuker> TMM: demuxing and decoding seem not well abstracted with that format [00:42:41 CEST] <nevcairiel> if its per-frame data it should go into the packet, its as simple as that [00:42:46 CEST] <atomnuker> normally a codec packet is very well defined [00:43:31 CEST] <TMM> is there a good example for how this should be done? [00:43:46 CEST] <atomnuker> I guess you should stick it at the end of the packet [00:44:00 CEST] <atomnuker> in this case there doesn't seem to be a nicer way [00:44:02 CEST] <TMM> I don't mind fixing it, I intend to port this to scummvm like we did with smacker for instance, so doing it right now may help [00:45:50 CEST] <TMM> If I know what it should look like at least :) [00:56:06 CEST] <atomnuker> TMM: to make things look as good as possible what you'd have to do is move the decoding map size to the extradata [00:56:22 CEST] <atomnuker> av_packet_new_side_data with type AV_PKT_DATA_NEW_EXTRADATA [00:56:34 CEST] <TMM> atomnuker, but... nevcairiel told me that extradata shouldn't be used for per-frame data? [00:57:07 CEST] <nevcairiel> definitely dont send new extradata with every single frame [00:57:09 CEST] <nevcairiel> thats just bad design [00:57:14 CEST] <TMM> I'd have to [00:57:17 CEST] <nevcairiel> thats just frame data then [00:57:19 CEST] <nevcairiel> not extradata [00:58:01 CEST] <atomnuker> I guess bad segmentation is unavoidable with these old codecs [00:58:01 CEST] <atomnuker> in which case stick it at the end of the packet [00:58:53 CEST] <TMM> OK [00:59:17 CEST] <TMM> I'll prepare a PR then, thanks for your help [01:00:51 CEST] <TMM> atomnuker, what do you mean by 'bad segmentation' btw? this is my first serious foray into reverse engineering a video codec [01:04:31 CEST] <iive> extradata has always been a thing, it exists since avi. Sidedata is more recent. [01:04:52 CEST] <atomnuker> well, muxers mux packets, and there's a very clear line between what parts are those of the container and what parts are for audio and video packets [01:05:35 CEST] <atomnuker> but with those old game codecs containers were only meant to mux very specific things rather than general packets from different codec types [01:05:36 CEST] <TMM> I'll be working on sprite support for truemotion1 support next, having a bit more vocabulary would maybe help [01:06:38 CEST] <TMM> is SideData per frame? [01:06:39 CEST] <nevcairiel> game formats just don't always stick to clear rules, the container is designed to hold one particular format, so it smeares all the typical borders [01:06:46 CEST] <atomnuker> so those codecs tend to treat the entire bitstream, video packets and containers as 1 [01:07:15 CEST] <nevcairiel> just shove whatever is needed to decode a single frame into the avpacket data [01:08:02 CEST] <TMM> yeah, so there are two video frame formats that are currently unimplemented. The 0x06 stream actually sticks the 'decode_map' at the top of the framedata, whereas for 0x10 and 0x11 videos it gets loaded by a separate opcode in a different segment of the file [01:08:05 CEST] <TMM> it's a bit of a mess [01:08:28 CEST] <TMM> but the actual content and meaning of the decode map is identical between 0x06 and 0x10 frame formats, but different between 0x10 and 0x11 [01:09:04 CEST] <TMM> the difference between 0x06 and 0x10 is primarily the addition of this 'skip map' [01:09:25 CEST] <TMM> I'm thinking that for 0x06 I will just generate a static skip map and split out the decode map in the demuxer [01:09:32 CEST] <TMM> that way the code for both frame formats could be the same [01:10:04 CEST] <TMM> in the original implementation there are 4 almost identical implementations of this frame format, for with and without a skipmap and for 8 and 16 bit... [01:10:25 CEST] <TMM> the only difference between the 8 and 16 bit versions being the amount of bits to copy per 8x8 block of pixels [01:10:42 CEST] <TMM> it looks like someone at interplay was having a bad day or something [01:42:39 CEST] <atomnuker> BBB: any plans to improve the performance of the vp56 entropy decoder? [01:43:03 CEST] <atomnuker> having looked at the code last summer I couldn't really find many ways to improve it [01:43:09 CEST] <nevcairiel> is it unsimdable like most smart entropy coders? [01:46:32 CEST] <nevcairiel> can go the cabac way and write some fancy branchless assembly [01:47:15 CEST] <BBB> atomnuker: I think jason looked at that a while ago and what we have now is the best he could come up with [01:47:20 CEST] <BBB> atomnuker: I have no reason to doubt him [01:47:36 CEST] <BBB> nevcairiel: yes its unsimdable [01:53:44 CEST] <atomnuker> well, I guess improving its decoding performance isn't really fixing the issue [01:54:08 CEST] <atomnuker> the issue being the rate control goes batshit and blows the bitrate up [01:54:23 CEST] <nevcairiel> isnt it much faster then cabac anyway [01:54:33 CEST] <BBB> it is [01:54:39 CEST] <BBB> because cabac is adaptive and vp56rac is not [01:54:48 CEST] <BBB> atomnuker: huh what? [01:54:55 CEST] <BBB> atomnuker: is this a specific bug youre looking at? [01:55:09 CEST] <atomnuker> nah, just looking at some 8k youtube videos [01:55:17 CEST] <BBB> lol [01:55:31 CEST] <BBB> hey look, every decoder in the world is slow for 8k content [01:55:33 CEST] <BBB> surprise! :D [01:56:03 CEST] <iive> well... that's why 8k is the new thing [01:56:07 CEST] <nevcairiel> my gpu can do it in hardware! both vp9 and hevc! [01:56:07 CEST] <nevcairiel> :D [01:56:12 CEST] <atomnuker> whats interesting is that some 8k videos have lower overall bitrate than the equaivalent 4k videos [01:56:13 CEST] <BBB> at 8k, every 64x64 block is basically dc intra-predictable with just a dc coefficient and it would still look ok [01:57:04 CEST] <atomnuker> most work fine here as long as the bitrate isn't above 50ish mbps [01:57:29 CEST] <nevcairiel> i have a crazy hevc test clip with 1000mbps [01:57:45 CEST] <nevcairiel> it breaks all sorts of things [01:58:01 CEST] <atomnuker> however youtube's infamous rate spikes bring it up and make the player drop frames [01:58:50 CEST] <atomnuker> what's funny is the rate control system doesn't even think its blown its budget and doesn't bump quantizers after the spikes [01:59:12 CEST] <nevcairiel> bad RCs dont notice momentary spikes as long as the average is fine [01:59:59 CEST] <nevcairiel> if it thought it would blow its budget, it would probably bump the quants to avoid the spike, i nstead of doing it afterwards [02:05:50 CEST] <atomnuker> (yes they even offer 8k h264 still) [02:06:24 CEST] <iive> isn't vbv supposed to handle that? [02:06:50 CEST] <DHE> it's supposed to, but you still have to configure it properly. set a bufsize and so on [02:06:59 CEST] <nevcairiel> clearly their vp9 encoder doesnt have that =p [02:09:22 CEST] <iive> is there more than 1 vp9 encoder out there? [02:12:07 CEST] <DHE> old version? badly configured encoder? [02:13:58 CEST] <TD-Linux> yes there is BBB's encoder as well [02:14:04 CEST] <TD-Linux> libvpx doesn't have a "real" VBV model [02:14:27 CEST] <TD-Linux> you can configure it pretty close, though I don't think youtube does [02:14:49 CEST] <TD-Linux> of course, there's also the people who complain about youtube not using crf, which would be even more spiky... [02:31:44 CEST] <nevcairiel> hey BBB gets to fix crashes in vp9 again [03:05:07 CEST] <BBB> nevcairiel: ah crap [03:05:17 CEST] <BBB> but vp9.c is bug-free! [10:09:54 CEST] <stevenliu_> Hello guys, i have a question, i want get the pict_type in hlsenc.c , the AVCodecContext has deprecated, then i want to check if the stream have b frame, how should i get it? [10:10:35 CEST] <stevenliu_> the AVCodecParameters have no has_b_frames member. [10:11:43 CEST] <nevcairiel> this is not information available to muxers [10:13:40 CEST] <stevenliu_> ok, let me try anther ways :( [10:13:47 CEST] <stevenliu_> another [10:20:22 CEST] <wm4> why would hlsenc need that info? [10:27:10 CEST] <ubitux> ps_stereo_interpolate_c: 72639.9 [10:27:11 CEST] <ubitux> ps_stereo_interpolate_neon: 72637.1 [10:27:13 CEST] <ubitux> ps_stereo_interpolate_ipdopd_c: 117688.2 [10:27:15 CEST] <ubitux> ps_stereo_interpolate_ipdopd_neon: 113633.4 [10:27:17 CEST] <ubitux> wouhou i'm faster T_T [10:37:56 CEST] <nevcairiel> by a hair :p [10:39:20 CEST] <mateo`> I suspect the memory accesses to be the bottleneck [10:39:22 CEST] <wm4> every speedup is good, every speedup is sacred [10:47:33 CEST] <stevenliu_> no ,hlsenc not need it [10:48:05 CEST] <stevenliu_> i get a problem, remux from flv to hls, the hls->duration is loooong than ts file duration [10:49:19 CEST] <stevenliu_> the case because the flv modified fps at recoding stream, rewrite avcC at middle of the flv file. [10:49:35 CEST] <stevenliu_> and the AVStream is not modify timebase [10:50:06 CEST] <wm4> the solution is not to remux to flv [10:50:08 CEST] <stevenliu_> so the compute is wrong, the hls->duration is wrong. [10:50:20 CEST] <stevenliu_> remux from flv to hls [10:52:10 CEST] <wm4> ah [10:52:32 CEST] <stevenliu_> the flv file looks like, cat a.flv b.flv > input.flv a.flv video fps is 30 b.flv video fps is 25 [10:52:53 CEST] <BtbN> I don't think that results in a valid file [10:52:55 CEST] <stevenliu_> or cat a.flv b.flv > input.flv a.flv video fps is 25 b.flv video fps is 30 [10:53:13 CEST] <thebombzen> flv doesn't support concatenation, IIRC [10:53:25 CEST] <thebombzen> concatenating flv files doesn't work the way you want it to [10:53:40 CEST] <stevenliu_> No, not concat [10:53:52 CEST] <thebombzen> that is literally what 'cat' does [10:54:39 CEST] <thebombzen> also should this be in #ffmpeg? not #ffmpeg-devel? [10:55:37 CEST] <stevenliu_> for example, a rtmp server record stream to flv, when user publish rtmp to server, server will record flv, if user modify FPS at living stream dynamic, the recorder always write data in flv file, the file will looks like concat, but not concat [10:56:29 CEST] <stevenliu_> BtbN, you mean that is not ffmpeg problem? [10:57:00 CEST] <thebombzen> stevenliu_: if you concatenate the files together (which is what 'cat' does) then the resulting file will not be a valid FLV file [10:57:02 CEST] <stevenliu_> I want fix it, but i have no idea now [11:05:34 CEST] <stevenliu_> #thebombzen Thanks :) [12:09:00 CEST] Action: J_Darnley sighs [12:09:51 CEST] <J_Darnley> Despite BBB's hard work of tracking down the differences between these different functions it still doesn't work correctly. [12:18:58 CEST] <J_Darnley> I must ask him how he does that. [12:21:43 CEST] <J_Darnley> Speak of the devil [12:22:06 CEST] <J_Darnley> BBB: good morning [12:24:45 CEST] <BBB> hi [12:24:48 CEST] <BBB> what did I do [12:25:38 CEST] <J_Darnley> Nothing, just arrives right after I said I need to ask you how you tracked down those IDCT differences [12:25:48 CEST] <BBB> I gotta make breakfast for kids, Ill explain after that, ok? [12:25:53 CEST] <J_Darnley> Sure [13:19:41 CEST] Action: J_Darnley is afk [13:55:26 CEST] Action: J_Darnley is back [13:56:15 CEST] <BBB> J_Darnley: ok, so [13:56:35 CEST] <BBB> J_Darnley: what I did is that I logged the sumErr per transform block for each idct implementation (C, MMX, SSE2, etc.) [13:56:49 CEST] <BBB> J_Darnley: while running dct-test [13:56:59 CEST] <BBB> J_Darnley: so that gives me a 20k line file per implementation [13:57:07 CEST] <BBB> J_Darnley: I diff the C vs. SSE2 to find which iters give a difference [13:57:21 CEST] <BBB> J_Darnley: then for these iters I log the input and output to see how they are diffrent [13:57:37 CEST] <BBB> J_Darnley: then I wrote a test application that takes one of the difference-generating inputs and directly compare C vs. SSE2 [13:57:52 CEST] <BBB> J_Darnley: then in the C function I log intermediates (e.g. after 1d, or within the 1d) and same in SSE2 [13:58:04 CEST] <BBB> J_Darnley: it was pretty obvious from that that the problem was in the DC [13:58:10 CEST] <BBB> J_Darnley: rest is just code logic and stuff [13:58:26 CEST] Action: J_Darnley nods [13:58:47 CEST] <BBB> like I said yesterday, its not exciting or anything, but it gets the job done ;) [13:58:59 CEST] <BBB> did michaelni say anything about 16384 being ok as a patch? [13:59:13 CEST] <J_Darnley> I haven't asked yet, or submitted a patch [13:59:30 CEST] <BBB> ok [14:00:19 CEST] <J_Darnley> Changing that in the C did lead to a 13 thousand line change to the test reference files [14:00:31 CEST] <BBB> thats not surprising I guess [14:00:45 CEST] <BBB> but the sumErr in the dct-test application does go down, right? [14:01:06 CEST] <J_Darnley> Yes I think so [14:02:21 CEST] <michaelni> <michaelni> BBB, i remember tuning the 1638X thing to fix some issue, probably some artifacts caused by idct rounding difference aka greenish/pinkish blocks [14:03:14 CEST] <BBB> do you remember which sample or bugid or git hash? [14:04:36 CEST] <J_Darnley> git blame on the template file should tell you which commit it was changed in. [14:04:58 CEST] <BBB> can you guys try to figure that out? :) [14:05:08 CEST] <BBB> once I have a sample I can look into it and see if theres other things we can do [14:07:26 CEST] <J_Darnley> Wow. Revision 433 from 2002 [14:07:44 CEST] <J_Darnley> git hash ccf589a8fe [14:08:57 CEST] <J_Darnley> And the revision immediately before it [14:09:14 CEST] <J_Darnley> Unfortunately there is not much in the commit messages [14:09:25 CEST] <BBB> hm... [14:12:03 CEST] <BBB> this is all very complicated, as is usually the case when old code is touched :-p [14:13:28 CEST] <BBB> I personally think we need access to blocks that lead to that change, otherwise its hard to figure out what was going on there and we have to assume it didnt happen [14:13:45 CEST] <BBB> but to each his own opinion ;) [14:32:00 CEST] <BBB> J_Darnley: my suggestion would be to send a patch that reverts ccf5 and the patch before it and open it up for discussion [14:32:33 CEST] <BBB> J_Darnley: alternatively, we can mangle the dc-only patch to also use 16383 instead of rightshift by 14 (which is identical to *=16384) [14:32:42 CEST] <BBB> J_Darnley: but right now results are inconsistent and I dont like it at all [14:33:17 CEST] <J_Darnley> Mangling sounds easy in the C, less so in the MMX (if we care about that) [14:33:52 CEST] <J_Darnley> also a clarification: the sumerr goes down in test 2 of dct but neither of the others. [14:35:14 CEST] <BBB> test 2 is a particular type of stress test [14:35:34 CEST] <BBB> Im also concerned that the C was adjusted to give worse results just to match the MMX, even though the overflow was in the MMX alone [14:35:51 CEST] <BBB> (worse results as measured by maxSumErr in dct-test) [14:38:38 CEST] <J_Darnley> I don't understand that. I thought the MMX doesn't match the C in master so it isn't used for fate [14:38:51 CEST] Action: J_Darnley is going around in circles [14:42:57 CEST] <michaelni> C was likely adjusted because it produced artifacts but its 15years ago [14:44:23 CEST] <kierank> eugh [14:44:41 CEST] <sigdrak> if you change the idct now, and thus the reconstruction, won't that cause error accumulation and then drifts ? [14:44:51 CEST] <michaelni> sigdrak, yes [14:45:27 CEST] Action: kierank wonders if he opened a big can of worms [14:45:28 CEST] <sigdrak> https://guru.multimedia.cx/the-mpeg124-and-h26123-idct/ [14:45:53 CEST] <kierank> J_Darnley: we definitely need to blog about this now [14:47:51 CEST] <BBB> we are merely one implementation [14:47:57 CEST] <BBB> so if we drifted, we need to fix it on our end [14:48:06 CEST] <BBB> some people use ffmpeg to decode and/or encode ffmpeg [14:48:16 CEST] <BBB> but we are by no means the predominant implementation [14:48:22 CEST] <BBB> let alone reference [14:48:58 CEST] <BBB> michaelni: the C code was adjusted to match the C, as can be seen in the commit order; the overflow was in the MMX, not in the C [14:49:15 CEST] <BBB> C code was adjusted to match the MMX, I mean [14:50:21 CEST] <michaelni> c and mmx where likely adjusted because of artifacts in ffmpeg decoder output from non ffmpeg generated files [14:50:42 CEST] <michaelni> i dont think theres an overflow but its long ago [14:51:56 CEST] <BBB> hm& this is all very difficult if we dont have samples to work with [14:52:50 CEST] <BBB> and the professor concluded: And this, my students, is why we have informational commit messages. end of class, please hand in your homework assignment no later than next week friday [14:53:52 CEST] <BBB> gh0st__: https://trac.ffmpeg.org/ticket/6459 is a bug in your code, see http://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212400.html [14:57:14 CEST] <michaelni> samples would give more information and allow reproducing but it would just confirm that the value we have since 15 years work while the vaue before had an issue [14:57:48 CEST] <BBB> it allows investigating alternate solutions [14:57:58 CEST] <BBB> we dont even knwo whether the issue is a drift or an overflow at this point [14:58:17 CEST] <BBB> I also still believe we should fundamentally try to be close to the reference [14:58:29 CEST] <BBB> not to some particularly buggy implementation that used 16383 for who knows what kind of reason [14:58:34 CEST] <BBB> thats called a hack [14:58:46 CEST] <BBB> we could have a special idct that uses 16383 for files that are particularly buggy there [14:58:56 CEST] <BBB> but if that makes us further away from the reference, that shouldnt be the default by any means [14:58:57 CEST] <BBB> right? [14:59:09 CEST] <nevcairiel> that C and MMX dont match is already quite suspicious for hacky things [14:59:09 CEST] <iive> reference doesn't matter [14:59:17 CEST] <J_Darnley> The problem is I bet we can't detect the problem files and then do the Right Thing. [14:59:31 CEST] <iive> it's the error toward the existing implementations that is more important. [14:59:44 CEST] <michaelni> BBB the reference for the decoder IDCT is the encoder IDCT [14:59:44 CEST] <iive> and i guess this includes xvid and divx [15:00:07 CEST] <BBB> michaelni: in the implementation [15:00:11 CEST] <BBB> michaelni: but in the standard? [15:00:20 CEST] <BBB> I know the standard doesnt define an exact idct [15:00:20 CEST] <iive> and the fact that xvid used mpeg2 idct at the start doesn't make things easier. [15:00:21 CEST] <BBB> but it has a target [15:00:47 CEST] <BBB> J_Darnley: we can tell users to use a special option for files that show visual artifacs [15:00:48 CEST] <iive> the standard defines an error range [15:00:59 CEST] <michaelni> BBB if you change the default IDCT you will break alot of things and help noone [15:01:16 CEST] <BBB> I didnt change the default idct from the reference, you did, in 2002 :-p [15:01:21 CEST] <michaelni> BBB no [15:01:25 CEST] <BBB> Im just suggesting putting it back to what it was before that [15:01:28 CEST] <michaelni> no [15:01:50 CEST] <BBB> commit ccf589a8fed254f7395b05beac2ef84e7dd89e6f [15:01:51 CEST] <BBB> Author: Michael Niedermayer <michaelni(a)gmx.at> [15:01:51 CEST] <BBB> no? [15:01:57 CEST] <michaelni> " idct from the reference, you did, in 2002" <-- wrong [15:02:30 CEST] <BBB> you say that patch fixes a particular file [15:02:43 CEST] <BBB> and a particular artifact [15:02:45 CEST] <BBB> right? [15:03:00 CEST] <J_Darnley> kierank: what have we done? [15:03:04 CEST] <BBB> lol [15:03:05 CEST] <michaelni> it probably fixed many files and made the idct work better overall [15:03:12 CEST] <BBB> probably is not definitive [15:03:26 CEST] <BBB> compared to the floating point (which I call reference) idct, it adds error [15:03:32 CEST] <kierank> J_Darnley: i wonder if i have unleashed a beast [15:03:39 CEST] <BBB> maxSumError for dct-test in -i2 is 0 with 16384, but is >0 with 16383 [15:03:56 CEST] <BBB> that suggests to me that 16384 is a better value for reduced round-trip error against independently written idcts than 16383 [15:03:57 CEST] <BBB> right? [15:04:20 CEST] <iive> BBB: why don't you read the standard [15:04:28 CEST] <iive> BBB: it defines an error RANGE [15:06:56 CEST] <michaelni> if we change the idct not only will some files from other encoders show artifacts, ffmpeg generated files will show artifacts from IDCT mismatch and files generated with the new IDCT will show atifacts with other decoders and old ffmpeg [15:07:27 CEST] <BBB> indeed [15:07:39 CEST] <atomnuker> so what's the issue here then? [15:07:55 CEST] <BBB> files generated from still other encoders will also stop showing artifacts since we are getting closer to the reference (floating point) idct [15:08:01 CEST] <BBB> its all very complicated [15:08:14 CEST] <iive> I thought that the issue is that C and MMX differ... but it seems it have drifted somewhere else. [15:08:36 CEST] <iive> BBB: other ecoders also use flawed IDCT [15:08:38 CEST] <BBB> J_Darnley: the alternate solution is to re-do the masking that mmx and C do - for 8 bits only - and use 16384 only in those cases [15:09:36 CEST] <J_Darnley> Hm. I should try that. It might make it faster too [15:09:37 CEST] <michaelni> BBB, i doubt any inter frame encoder with large gop distance uses a 8x8 float idct [15:09:54 CEST] <BBB> J_Darnley: no, itll make it slower :( [15:10:05 CEST] <BBB> J_Darnley: you have to do full idct and dc-only idct for both dimensions [15:10:14 CEST] <BBB> J_Darnley: and then mask them based on each row being dc-only or not [15:10:21 CEST] <BBB> J_Darnley: its hideous if I may say so [15:10:26 CEST] <BBB> but thats what the C code does [15:10:36 CEST] <BBB> so it makes it probably about 20% slower or so [15:10:45 CEST] <BBB> (rough guesstimate) [15:12:58 CEST] Action: J_Darnley grumbles [15:13:22 CEST] <BBB> let me see if I can write an example for you [15:13:28 CEST] <BBB> and yes, again, this is totally hideous [15:13:33 CEST] <BBB> welcome to working with 15-year old code :D [15:13:52 CEST] <BBB> grep x264_build in h264*.c for more fun [15:13:56 CEST] <BBB> and thats not 15 years old yet [15:14:01 CEST] <nevcairiel> you can "thank" BBB later for pulling you into this =p [15:14:12 CEST] <BBB> yikes [15:17:56 CEST] <iive> michaelni: btw, do you know if ffmpeg4 detects old xvid bitstream ans switches to a special idct, or simple_idct is used for them too? [15:18:29 CEST] <iive> i might have at least one xvid sample that shows green tilt [15:19:52 CEST] <BBB> J_Darnley: the basic idea is in the idct_1d, youd por all ac coefficients together, then peqw with a zero register to see if all acs were zero, lets call that res (so res=0xff or 0 for each row/col), then use the dc to calculate dc <<= 3 and mask (pand) the res with the dc and reverse-mask (pandn) with the normal result, por the two together and thats your output [15:20:06 CEST] <BBB> J_Darnley: its a little complicated but thatll give the result you want and matches the current c code [15:20:20 CEST] <BBB> want is subjective obviously [15:22:33 CEST] <michaelni> iive, we switch ti xvid idct if xvid is deteted [15:23:22 CEST] Action: J_Darnley needs water [15:27:51 CEST] <iive> BBB: you want to do full 1D IDCT and DC detect calculations and then pblendv them? [15:28:17 CEST] <iive> isn't the DC detect used to quickly skip the 1D IDCT [15:32:13 CEST] <ubitux> i fixed the very large precision problem in aacpsdsp neon arm code [15:32:19 CEST] <ubitux> but it's not sexy [15:32:43 CEST] <ubitux> http://sprunge.us/XKjJ?diff [15:32:46 CEST] <ubitux> any suggestion? [15:33:11 CEST] <ubitux> basically the offset values are *2 and that initial accuracy drift over time pretty quickly [15:33:33 CEST] <ubitux> main problem is that it adds 2 instruction in the inner loop [15:35:10 CEST] <iive> ubitux: are the original 1* values used somewhere in the functions? [15:35:26 CEST] <iive> you can just double the increments before the loop. [15:36:00 CEST] <ubitux> that's exactly what i'm removing [15:36:13 CEST] <ubitux> the first add on top of the diff is the double of the increment [15:36:28 CEST] <ubitux> but it creates an inaccuracy that increases progressively in the inner loop [15:36:52 CEST] <ubitux> after ~1024 iteration, the inaccuracy reaches a 0.01 error [15:36:57 CEST] <ubitux> which is pretty large [15:37:55 CEST] <iive> stange, the mantisa shouldn't change in *2 [15:38:27 CEST] <ubitux> maybe we should actually fmul by 2 [15:38:32 CEST] <ubitux> instead of adding itself [15:39:06 CEST] <iive> you can try [15:44:53 CEST] <ubitux> doesn't help [15:47:30 CEST] <iive> can i see the whole function? is it in ffmpeg git? [15:49:00 CEST] <ubitux> yes it's the arm code [15:49:05 CEST] <ubitux> libavcodec/arm/aacpsdsp_neon.S [15:51:38 CEST] <kierank> J_Darnley: bloody boiling today [16:59:42 CEST] <ubitux> jamrial: i found the cause of the inaccuracy in the arm [16:59:52 CEST] <ubitux> (arm, not aarch64) [17:00:08 CEST] <jamrial> ubitux: cool, what was it? [17:00:23 CEST] <ubitux> http://sprunge.us/aIKE [17:01:10 CEST] <ubitux> and i'm also "faster" with all the aarch64 code now [17:01:30 CEST] <ubitux> (http://sprunge.us/WKWY) [17:17:20 CEST] <BBB> J_Darnley: muhahahhaha https://pastebin.com/63DQrJH8 [17:17:26 CEST] <BBB> also: dont judge me! [17:17:33 CEST] <BBB> I was in a hurry [17:23:47 CEST] <J_Darnley> Well you beat me to it so I won't [17:26:18 CEST] Action: J_Darnley will read it after caffeine [17:29:14 CEST] <iive> BBB: can't you use pandn and a zero constant? [17:30:09 CEST] <BBB> J_Darnley: hey at least I did one thing right, and also its a hack so itll need some cleanup [17:30:29 CEST] <iive> and once again, isn't it better to use conditional jump ? [17:37:16 CEST] <J_Darnley> As I understand it we can't jump over the idct because we need to perform it even if just one row has one non-zero coeff. [17:38:11 CEST] <cone-177> ffmpeg 03Ronald S. Bultje 07master:d35ff98e270d: vp9: fix overwrite in ff_vp9_ipred_dr_16x16_16_avx2. [17:39:17 CEST] <BBB> right, you need to do both dc-only as well as full 1d idct for the rows [17:39:30 CEST] <BBB> and then and them per-row depending on whether each 1d row was dc-only or not [17:39:35 CEST] <BBB> check c code for details [17:40:01 CEST] <BBB> (the C code is quite well-written and well-documented for something so old) [17:40:48 CEST] <BBB> and I dont mean that in a derogatory way, its just nice to see well-documented code that isnt total spaghetti and be able to predict behaviour just from reading it [17:40:52 CEST] <J_Darnley> I rather like it too. The template works rather well [17:41:13 CEST] <BBB> the mmx, on the other hand, is very obscure :D [17:42:22 CEST] <J_Darnley> pcmpeqb X, X is a quick way to get all ones, right? [17:42:30 CEST] <BBB> yes [17:42:38 CEST] <BBB> theres probably other ways to get that also [17:42:46 CEST] <BBB> like I Said << lazy [17:43:25 CEST] <J_Darnley> Oh of course that is inverting the mask [17:44:45 CEST] <BBB> right [17:53:48 CEST] Action: J_Darnley is afk [17:59:15 CEST] <jamrial> ubitux: would using vmla with a reg containing a 2.0 constant work here? or is it even uglier? [17:59:53 CEST] <ubitux> i tried it, it didn't help, i get the same failure as with the fadd [18:00:46 CEST] <ubitux> http://sprunge.us/gMIF?diff ugly & dumb, dunno if there is a smarter way but that's how i tested it [18:01:52 CEST] <jamrial> no, i mean, instead of replacing the two adds in the loop with four adds, replace them with two vmlas [18:05:09 CEST] <jamrial> ubitux: instead of "vadd q0, q0, q15" do "vmla q0, q14, 2.0" or however it's written [18:06:03 CEST] <BBB> can anyone reproduce any of the issues in 6459/6460/6461/6462? [18:06:12 CEST] <BBB> asan and valgrind are completely clean for me on two platforms [18:06:29 CEST] <BBB> (they didnt even detect that assembly issue I fixed) [18:06:51 CEST] <jamrial> BBB: i can reproduce 6460 on a mingw x64 build [18:07:11 CEST] <BBB> so why cant I? [18:08:18 CEST] <jamrial> let me check again. i could last night at least [18:10:54 CEST] <ubitux> jamrial: doesn't help [18:15:16 CEST] <jamrial> BBB: can't reproduce it anymore [18:15:24 CEST] <BBB> uhm [18:15:25 CEST] <BBB> ok [18:15:32 CEST] <BBB> so maybe 6459 was responsible for the others also? [18:15:38 CEST] <BBB> can you reproduce any of 6460/1/2? [18:16:24 CEST] <jamrial> BBB: if i revert d35ff98e27 i can reproduce the crash [18:17:10 CEST] <jamrial> 6460 i mean. without that commit it crashes, doesn't crash with it [18:17:25 CEST] <BBB> testing.. [18:17:47 CEST] <BBB> yes [18:17:54 CEST] <BBB> I can reproduce 6460/1/2 with that reverted [18:17:56 CEST] <BBB> ok, so all duplicates [18:19:23 CEST] <BBB> tnx for helping :) [18:19:48 CEST] <BBB> yesterday night I was semi-panicking like as if ffvp9 was a total security disaster [18:20:00 CEST] <BBB> always nice to be able to trace that back to a commit just 1 day ago :) [18:27:12 CEST] <gh0st__> BBB: Looks like I made some trouble there, yikes. [18:28:40 CEST] <BBB> its ok :) [22:15:25 CEST] <thebombzen> why is michael the only dev here without op? [22:15:46 CEST] <Shiz> maybe he has set noautoop in nickserv? [22:16:02 CEST] <thebombzen> perhaps? but most of the ops here are not ops in #ffmpeg so idk [22:42:09 CEST] <BBB> J_Darnley: anything more I can do to help get the idct patch pushed? [22:42:36 CEST] <BBB> J_Darnley: as irritating as part of this process may be, I really would like this to go in, I think its great work and helps a lot of use cases [22:57:51 CEST] <kierank> I also would like to see this in because I have something else for J_Darnley to work on [22:59:45 CEST] <atomnuker> tdjones: can you add an option to the encoder like opus_delay? [23:00:18 CEST] <atomnuker> (except make it in samples rather than seconds) [23:00:39 CEST] <atomnuker> I'd like to see the effect of the incredibly long vorbis windows [23:03:12 CEST] <durandal_170> kierank: on mpeg2? [23:03:33 CEST] <kierank> durandal_170: no [23:04:31 CEST] <durandal_170> kierank: then what? [23:04:51 CEST] <jkqxz> How long is the random_seed test meant to take to run? [23:04:53 CEST] <kierank> well updating our internal ffmpeg and working on some NIC stuff [23:11:17 CEST] <jkqxz> Taking ~ten minutes on a desktop skylake surely means it will take absurdly fucklong on embedded stuff? (Or does that mean there is something wrong with my machine?) [23:16:23 CEST] <jamrial> jkqxz: that's definitely not right [23:16:49 CEST] <J_Darnley> BBB, kierank: I hope not too much longer. I confirmed it was working with dct before I went to make dinner [23:17:21 CEST] <J_Darnley> Now I plan to check it against C and MMX using the fate tests. [23:20:05 CEST] <jamrial> jkqxz: i remember not too long ago someone updated the random_seed test and it started to take a crap load of time on windows [23:20:10 CEST] <jamrial> but it was soon fixed [23:20:37 CEST] <BBB> is someone also working on integrating th patches from bugmaster to fix 444 h264 decoding lossless something or so? [23:20:45 CEST] <BBB> or should I do that? [23:21:10 CEST] <durandal_170> do that [23:21:49 CEST] <cone-862> ffmpeg 03Matthieu Bouron 07master:204008354f7f: lavc/aarch64/simple_idct: fix build with Xcode 7.2 [23:22:54 CEST] <jkqxz> I shouldn't be running out of entropy, because it's using /dev/urandom. [23:23:02 CEST] <jkqxz> Also it really did take 10 minutes of CPU time, not just real time. [23:26:31 CEST] <nevcairiel> jamrial: its still relatively slow, mostly because its testing this one mode thats never going to get used in windows either way, and there is a reason we have the mode that uses windows crypto functions instead of relatively inaccurate time seeds [23:26:46 CEST] <tdjones> atomnuker: To let it change the length of encoded windows, or is it just for lookahead in the psy model? [23:28:11 CEST] <jkqxz> nevcairiel: How long do you expect it to take there? [23:30:47 CEST] <atomnuker> tdjones: the latter, make a copy of ff_opus_psy_process() for vorbis and do what it does [23:31:33 CEST] <atomnuker> it sets the window size based on the option value and if its more than the largest possible window keepts it as a lookahead [23:34:55 CEST] <durandal_170> atomnuker: how is audio noise reduction filter going? [23:35:14 CEST] <nevcairiel> jkqxz: expect? takes about 10 seconds on my relatively fast system, which for this simple test is already stupid long, if it takes minutes then its probably still broken and tries to find some entropy somewhere [23:35:57 CEST] <nevcairiel> (it always tests the time-based fallback mode, in addition to the platform-specific entropy source) [23:36:02 CEST] <tdjones> atomnuker: Sure, I'll take a look at it and work it in as soon as I'm able [23:36:29 CEST] <J_Darnley> For the love of god, what now? Why does fate pass on my laptop but not my server? WTF! [23:39:44 CEST] <wm4> why do we need a random seed test [23:39:51 CEST] <wm4> that's utterly stupid [23:39:59 CEST] <J_Darnley> Cock. I bet its harddrive is dying. Deleting the sample then syncing fixed it. [23:40:09 CEST] <wm4> it's not like it's going to be used for something important [23:41:11 CEST] <atomnuker> tdjones: once you get that running I'd like you to write a code which calculates the distortion of the residual and use it to find the best rc->classbook using a greedy search (look through all values) [23:41:33 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:f2e4fb61af4b: hwcontext_vaapi: Try to support the VDPAU wrapper [23:41:34 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:92bd08974541: vaapi_encode: Discard output buffer if picture submission fails [23:41:35 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:b22172f6f353: hwcontext: Add device derivation [23:41:36 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:0b1794a43e10: hwcontext: Make it easier to work with device types [23:41:37 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:06043cc0bc72: ffmpeg: Generic device setup [23:41:38 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:be5107335230: ffmpeg: Enable generic hwaccel support for VAAPI [23:41:39 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:e462ace84b92: ffmpeg: Enable generic hwaccel support for VDPAU [23:41:40 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:527a1e213167: ffmpeg: Document the -init_hw_device option [23:41:41 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:bff7bec1d7d0: vf_deinterlace_vaapi: Add support for field rate output [23:41:42 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:91c3b50d74ba: qsv: Add ability to create a session from a device [23:41:43 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:8aa3c2df1ae6: qsvdec: Allow use of hw_device_ctx to make the internal session [23:41:44 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:28aedeed1961: qsvenc: Allow use of hw_device_ctx to make the internal session [23:41:45 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:b658b5399e5d: vaapi_encode: Use gop_size consistently in RC parameters [23:41:46 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:49ae8a5e87f9: lavc: Add flag to allow profile mismatch with hardware decoding [23:41:47 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:38820631746f: vaapi: Add external control of allow-profile-mismatch [23:41:48 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:7ce47090ce36: ffmpeg: Support setting the hardware device to use when filtering [23:41:49 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:045ff8d30a69: hwcontext_qsv: Support derivation from child devices [23:41:50 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:ec3dbeae8139: hwcontext: Add frame context mapping for nontrivial contexts [23:41:51 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:f82ace71c0d8: hwcontext_qsv: Implement mapping frames from the child device type [23:41:52 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:a97fb14418fd: hwcontext_qsv: Implement mapping frames to the child device type [23:41:53 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:d59c6a3aebc2: hwcontext: Improve allocation in derived contexts [23:41:54 CEST] <durandal_170> spaaaam [23:41:54 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:b2ef1f42badd: vf_hwmap: Add device derivation [23:41:55 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:d81be0a60a6d: vf_hwmap: Add reverse mapping for hardware frames [23:41:56 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:5de38188f82a: doc: Document hwupload, hwdownload and hwmap filters [23:43:25 CEST] <jamrial> jkqxz: did you see my reply about vp9_raw_reorder? converting it to get_bits is trivial. none of the bitstream_read calls read more than 25 bits [23:43:36 CEST] <jamrial> much easier/better than waiting for the new bitstream reader to finally be merged [23:45:04 CEST] <jkqxz> Yeah, I'm about to do it. [23:45:14 CEST] <jkqxz> Just getting that set out of the way first. [23:45:20 CEST] <jamrial> ah cool [23:47:45 CEST] <jkqxz> wm4: For videotoolbox, I think it should be able to use generic hwaccel (though I only have oranges, so can't test). What about VDA? That also uses the ffmpeg_videotoolbox.c file. [23:48:42 CEST] <wm4> fuck VDA, is my reply [23:49:02 CEST] <wm4> I can't even test VDA because newer OSX versions have it fully removed [23:49:15 CEST] <wm4> supporting VDA is a bit like supporting windows xp [23:49:21 CEST] <jkqxz> Oh, ha. [23:49:25 CEST] <jkqxz> So ffmpeg will keep it forever, then? [23:49:30 CEST] <wm4> probably [23:50:16 CEST] <jkqxz> Move videotoolbox to generic hwaccel, rename ffmpeg_videotoolbox.c to ffmpeg_vda.c and remove the ifdefs? [23:50:17 CEST] <wm4> but I don't care, and you shouldn't either... I'd just post a patch (that implicitly removes vda ffmpeg.c support), and see if any trolls appear [23:50:23 CEST] <nevcairiel> my problem is that I need mac binaries that work on 10.7 and up, and IIRC VT is only 10.8 and up, but if VDA doesnt work on newer versions that leaves me with shit =p [23:50:46 CEST] <jkqxz> (Also subtly break it to see if anyone ever uses it.) [23:50:50 CEST] <wm4> not sure when VT support started... it was inofficial for a while [23:51:06 CEST] <nevcairiel> docs say 10.8 anyway [23:56:57 CEST] <jkqxz> "make fate-random_seed" seems to take a random amount of time. [23:58:31 CEST] <kode54> "We require hvc1 codec id for playback. This was communicated during the sessions at WWDC. We have a similar requirement for H.264 playback where we require avc1 codec id." [23:58:31 CEST] <jkqxz> I think it's much faster if other stuff is happening on the same machine. The first run was in the middle of a nonparallel "make check" and took ten minutes, a later run took two minutes, and it's under ten seconds if other stuff is going on. [23:58:43 CEST] <kode54> maybe make a handy stream reformatter for that? [23:59:14 CEST] <jkqxz> So sounds like entropy might well be the problem. [00:00:00 CEST] --- Thu Jun 15 2017

1 0

ffmpeg.log.20170614
by burek 15 Jun '17

15 Jun '17

[04:39:30 CEST] <ac_slater> hey guys. I'm attempting to mux video and data into an mpegts container via the APIs. Is it weird if my data stream's PTS starts at 1 and increments by 1 for every "data packet"? I guess I don't understand if both's stream's PTS values should be interleaved or not [04:52:17 CEST] <ac_slater> Is there a good example or anything for handing remuxing of video data with b-frames? [04:52:24 CEST] <ac_slater> ie - DTS != PTS [07:30:51 CEST] <lullabybunny> Hello, I am very new to the usage of ffmpeg, and I am trying to do a little troubleshooting. I have the Zeranoe ffmpeg shared build and I'm trying to do some QSV troubleshooting. Basically the program that uses ffmpeg is saying that my QSV codecs aren't implemented so I'm trying to use commandline to comfirm they do in fact work. the problem is all the guides i have read on commandline usage basically assume I know what I'm doi [07:30:53 CEST] <lullabybunny> Can someone helpo? [08:02:04 CEST] <lullabybunny> is anyone around, really need some help [09:00:02 CEST] <lullabybunny> hello, i have an i5 4590 and i am getting the error "Error initializing an internal mfx session: unsupported (-3). this was supposedly fixed in ffmpeg 2.8. I am currently using 3.3.1 [09:00:13 CEST] <lullabybunny> can someone please advise [09:03:02 CEST] <lullabybunny> https://puu.sh/wjzPG/11ff3a3e6e.png [09:23:56 CEST] <amey> Hi all. I am working on audio fingerprinting for GSoC project. I want decode audio to PCM then mono channel it and downsample it 5512 Hz. With tutorials on web I tried following, since I don't know how to test if it is correct if anyone of you review, it would be great help. Also I after swr_convert output is in uint8_t form. But I want it in float. How can I do that? [09:23:56 CEST] <amey> https://pastebin.com/dP9W9qw7 [12:23:37 CEST] <pihpah> /usr/bin/ffmpeg -i "$INPUT" -map $VIDEO_STREAM -map $AUDIO_STREAM -c:v libx264 $audio_ops -sn -movflags faststart -strict -2 $crf_ops $filter_ops "$output" [12:24:10 CEST] <pihpah> But for some reason other streams are being copied too, how can I copy only video and audio streams I specify? [13:49:44 CEST] <pihpah> Anyone? [13:51:07 CEST] <pihpah> He who helps me will see my girlfriend's ass, and she is hot! [14:07:35 CEST] <Jonuz> https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRwpeNkZH2rmtHxnny-EOZ… [16:10:25 CEST] <alexpigment> hey guys, I'm looking at doing multiple transcodes with ffmpeg like this: https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs#Differentparalle… [16:11:07 CEST] <alexpigment> unfortunately, my CMD window on Windows is giving me the error "Unable to find a suitable format for '\'" [16:11:20 CEST] <alexpigment> is there a way to chain these together into one line rather than multiple lines like the example? [16:11:36 CEST] <relaxed> yes, use one line and omit the backslash [16:11:53 CEST] <alexpigment> oh gotcha [16:12:00 CEST] <alexpigment> thanks [16:17:19 CEST] <alexpigment> secondly, I'm needing to transcode 1080p into MPEG-1, but I get tons of these "buffer underflow" / "ignoring buffer limits to mux it" messages [16:17:35 CEST] <alexpigment> i tried setting a bufsize and maxrate to the same as the target bitrate, but it's still the same thing [16:17:43 CEST] <alexpigment> is there a way to silence these warnings? [16:18:05 CEST] <DHE> mpeg1? what bitrate? [16:18:09 CEST] <alexpigment> 24mbps [16:18:29 CEST] <alexpigment> i realize it's out of spec, but it's unimportant for my case [16:18:38 CEST] <DHE> you are using a capital M for your bitrate, right? [16:18:45 CEST] <alexpigment> yes [16:18:46 CEST] <alexpigment> well [16:18:52 CEST] <alexpigment> i'm actually just using 24000000 [16:18:53 CEST] <alexpigment> but yes [16:18:58 CEST] <alexpigment> Mbps is what i'm intending [16:23:09 CEST] <dorvan> hi all [16:23:51 CEST] <zack_s_> I want to concatenate two video, without rencoding [16:23:51 CEST] <zack_s_> ffmpeg.exe -f concat -i "video_1.mp4" -i "video_2.mp4" -c:v copy "output.mp4" [16:24:01 CEST] <dorvan> i have problem to trancode a liveview from an ip camera (h264) to a file to be read in (near)realtime [16:24:27 CEST] <zack_s_> however I get following ouptut: video_1.mp4 Invalid data found when processing input [16:27:30 CEST] <kerio> DHE: maybe it's one bit every 41 seconds instead [17:31:03 CEST] <FishPencil> Is there a correct/better/best way to normalize audio? [17:34:03 CEST] <zerodefect> IMX/D10 normally has a height of 608 (720x608), what is the best way to handle this and keep it 576 using the C-API? I don't want to throw the data away because I may use it at a later stage (the raw ancillary data is quite useful). Is there a way to move the data pointers to the pertinent pixels? [17:43:52 CEST] <durandal_1707> FishPencil: normalize means 2 pass processing [17:47:40 CEST] <slowWLAN> is there an easy subtitle format that is text-only? [17:48:18 CEST] <zerodefect> SRT [17:48:26 CEST] <FishPencil> durandal_1707: Right [17:50:19 CEST] <slowWLAN> https://matroska.org/technical/specs/subtitles/srt.html [17:50:33 CEST] <slowWLAN> zerodefect, thx. seems like what i've been looking for :) [17:51:09 CEST] <zerodefect> No problem. [18:04:45 CEST] <kepstin> zerodefect: yeah, if you just adjust the data pointers in the avframe, and adjust the height field appropriately, it should do what you want. This is actually basically what the crop filter does, fwiw. [18:06:15 CEST] <zerodefect> Terrific, thanks @kepstin. I'll give that a go. [18:08:23 CEST] <zack_s_> how can I concatenate multiple videos without specifing a text file? [18:08:40 CEST] <zerodefect> So I have an AVFrame which is a reference to the original IMX/D10 AVFrame. Presumably if I change the data pointers (pixel data pointers) on my shallow copy, it won't affect the AVBufferRef pointers? [18:08:49 CEST] <zerodefect> Just checking that there are no gotchas [18:09:13 CEST] <kepstin> zerodefect: yes, the pointers and lengths for the underlying buffers are stored separately [18:09:21 CEST] <zerodefect> Thanks :) [18:09:52 CEST] <kepstin> zack_s_: start with https://ffmpeg.org/faq.html#How-can-I-concatenate-video-files_003f it shows a few different ways [18:10:34 CEST] <zerodefect> Kepstin, am I one of the few asking C-API related questions? You seem to be one of the few able to answer them :) ! [18:10:52 CEST] <kepstin> zerodefect: I don't even do very much ffmpeg programming :/ [18:11:15 CEST] <kepstin> and yeah, you're one of only a few people. Most of the help in this channel is for the cli tool [18:11:44 CEST] <zerodefect> Ha. You have skillz (notice the 'z'!). Am I in the best place for my Q's? [18:12:42 CEST] <kepstin> zack_s_: but if you're talking about a file, you're probably looking at the concat demuxer - and there isn't really a better way to handle that. If you're on linux and using a modern shell you can probably fake it by using special substitutions, but the file is usually easier. [18:13:43 CEST] <kepstin> zerodefect: I don't really think there's anywhere better. The dev channel is more for talk of developing ffmpeg itself rather than applications using ffmpeg. [18:15:08 CEST] <zerodefect> Yeah, I've observed the dev channel once or twice after you mentioned it to me. [18:16:42 CEST] <zack_s_> kepstin: I need to concatenate mp4 files without re-encoding [18:17:14 CEST] <kepstin> zack_s_: ok, then the concat demuxer is the best option, and the easiest way to use it is with a file. [18:17:16 CEST] <zack_s_> what does "yuv4mpegpipe " do? and the transcoding step is almost lossless? what does almost mean? [18:18:21 CEST] <zack_s_> when I do it described like above it doesnt work, when I do it with the text file it will work ffmpeg -f concat -safe 0 -i concate-file.txt -c copy output.mp4 [18:18:27 CEST] <zack_s_> is this a bug in ffmpeg? [18:18:38 CEST] <zack_s_> I mean doing it with text file or not, should not make a difference [18:20:21 CEST] <kepstin> zack_s_: the different options do different amounts of demuxing and decoding/encoding - for what you asked, the "concat" demuxer (which uses an input text file) will match your requirements best. [18:21:08 CEST] <kepstin> zack_s_: pretty much the only other way to do it would be to convert all your input mp4 files to mpegts (using -c copy), concatenate those, then convert back to mp4 - which seems a lot more annoying to do :) [18:26:19 CEST] <zack_s_> kepstin: and the other concate option what does this do? [18:26:33 CEST] <zack_s_> ffmpeg.exe -f concat -i "video_1.mp4" -i "video_2.mp4" -c:v copy "output.mp4" [18:27:20 CEST] <kepstin> zack_s_: that won't concatenate anything, that'll just give an error. It'll try to open the file "video_1.mp4" with the concat demuxer, but the concat demuxer can only read text files, so you get an error. [18:28:17 CEST] <zack_s_> kepstin: but somebody said, it should work like this: https://superuser.com/a/718041 [18:28:53 CEST] <kepstin> zack_s_: they're wrong :/ [18:29:04 CEST] <zack_s_> okay [18:29:07 CEST] <zack_s_> got it now [18:29:15 CEST] <zack_s_> Anyway, when I use the text file I got following warning: when using the text file I got following warning [mp4 @ 0000000002650560] Non-monotonous DTS in output stream 0:0; previous: -400, current: -400; changing to -399. This may result in incorrect timestamps in the output file. [18:29:24 CEST] <zack_s_> is this critical, what does it mean? [18:31:21 CEST] <zack_s_> kepstin: ? [18:31:57 CEST] <kepstin> zack_s_: it may or may not be an issue. If the audio/video sync is fine in the output file, then don't worry about it. [18:32:41 CEST] <zack_s_> kepstin: okay, thx [18:42:49 CEST] <alexpigment> is there any reason why people disable SSE optimizations when building ffmpeg? [18:43:03 CEST] <alexpigment> is it just for size considerations? or is there a potential for problems? [18:48:00 CEST] <durandal_1707> alexpigment: very low IQ [18:48:43 CEST] <alexpigment> haha [18:48:49 CEST] <alexpigment> ok, so there are no downsides? [18:49:00 CEST] <alexpigment> i just figured I'd ask since there are options to disable them [18:50:18 CEST] <durandal_1707> same with audophiles and various nonsense and alternative facts spreading propaganda [18:51:44 CEST] <alexpigment> well, i'm a bit of an audiophile myself, but i'm not a FLAC-head (although I guess I would be if compatibility was higher and mobile devices had more storage) [18:51:55 CEST] <alexpigment> but yes, I get your point ;) [19:21:14 CEST] <dorvan> i have problems on a lossless rtsp stream acquisition, ffmpeg -y -re -i XXX -movflags isml+frag_keyframe -f ismv -loglevel warning -c:v copy -preset ultrafast -tune zerolatency -crf 0 YYY ...i can solve partially, but it's not a good result. [20:05:37 CEST] <Tatsh> new DVDAs, Rush - Fly By Night and Rush - Moving Pictures [20:05:41 CEST] <Tatsh> sound amazing [20:06:12 CEST] <durandal_1707> share it with us [20:06:20 CEST] <Tatsh> that's teh illEGAL [20:06:31 CEST] <durandal_1707> nope [20:06:43 CEST] <Tatsh> of course i rip these and convert to FLAC; no loss whatsoever :) [20:06:55 CEST] <durandal_1707> thats illegal [20:07:00 CEST] <Tatsh> my xbox one can then play these in VLC, but VLC has to downsample to 48K [20:07:22 CEST] <Tatsh> humans ears can't hear 96K [20:07:26 CEST] <Tatsh> whatever.. [20:45:37 CEST] <Tatsh> very interesting; the bass guitar goes straight to LFE :) [21:33:01 CEST] <Kirito> Whenever I extract frames from a video using ffmpeg and go to re-encode those frames after, the resulting file is always longer than the original despite the files being encoded with the exact same frame rates. Is there any way I can accurately avoid/prevent this from happening? [21:33:49 CEST] <Kirito> I mean you can use setpts to try and guess/"hack" the length to match but that is literally just a horrible hack and can still result in audio sync issues [21:34:21 CEST] <Kirito> I'm not sure if it's because the original source video has a variable frame rate (?) or what [21:35:39 CEST] <styler2go> Hi, i am trying to generate a green vidoe file but i need idt to be 16:9, can someone help what i need to add? i currently have: ffmpeg -f lavfi -i color=color=green -t 5166 red.mp4 [21:37:15 CEST] <Tatsh> styler2go, that's in the metadata or you can set the resolution [21:37:21 CEST] <Tatsh> -aspect 16:9 [21:37:42 CEST] <Tatsh> or you can use -s, -s 160/90 for example [21:37:50 CEST] <styler2go> nice, thank you [21:37:52 CEST] <Tatsh> i'm not sure what will happen if you don't specify -aspect [21:37:56 CEST] <Tatsh> you should specify that regardless [21:37:57 CEST] <furq> don't do either of those things [21:38:09 CEST] <Tatsh> okay listen to furq [21:38:13 CEST] <furq> -f lavfi -i color=color=green:s=160x90 [21:38:25 CEST] <Tatsh> shouldn't he set the metadata for the mp4 file? [21:38:37 CEST] <furq> you don't need to set aspect if the source aspect is 16:9 [21:38:47 CEST] <furq> -aspect is for anamorphic [21:39:03 CEST] <styler2go> well currently the sourc eis nothing [21:39:08 CEST] <Tatsh> i use -aspect where i have a number of videos coming from 720x480 but they are 4:3 [21:39:17 CEST] <furq> well yeah that's anamorphic [21:39:25 CEST] <Tatsh> styler2go, then you just need to give it a size [21:39:30 CEST] <styler2go> anyway, it worked. thanks a lot [21:40:28 CEST] <furq> you also probably shouldn't use -aspect if you're encoding [21:40:32 CEST] <furq> it's better to use -vf setsar/setdar [21:40:51 CEST] <furq> with that said, everything i've ever used has respected dar metadata [21:40:55 CEST] <styler2go> Hmm.. i need it to be in 1920x1080.. but it's pretty slow if i try to create a file with that resolution.. can i speed it up? it's just green anyway [21:41:03 CEST] <Tatsh> -vf setdar=16:9 ? [21:41:09 CEST] <furq> 16/9 [21:41:10 CEST] <furq> but yeah [21:41:11 CEST] <Tatsh> ok [21:41:16 CEST] <Tatsh> will update my encoding scripts [21:41:48 CEST] <furq> i've totally used -aspect when encoding and have no complaints [21:41:58 CEST] <furq> but it's presumably better to do that at the stream level than at the container level [21:42:29 CEST] <Tatsh> styler2go, it's one colour; are you streaming this? [21:42:40 CEST] <Tatsh> wondering if you can use a simple upscaler and it won't look bad [21:42:48 CEST] <styler2go> no i need it as a dummy file with the exact length of 5166s [21:43:15 CEST] <styler2go> pretty much just a greenscreen file to mask out some stuff [21:43:25 CEST] <Tatsh> -f lavfi -i color=color=green:s=1920x1080 [21:43:37 CEST] <Tatsh> stretch it out to the DAR in whatever app you are using [21:43:42 CEST] <furq> maybe -preset superfast will help [21:43:47 CEST] <furq> also that's already the correct dar [21:43:48 CEST] <Tatsh> it will have enough pixels to match [21:43:52 CEST] <styler2go> Tatsh, well this works but it's slow [21:44:01 CEST] <styler2go> in 160x90 it was like 2 seconds [21:44:03 CEST] <Tatsh> but you are only generating this once [21:44:18 CEST] <Tatsh> how slow do you mean? [21:44:20 CEST] <furq> i doubt you'll get any faster than that [21:44:32 CEST] <styler2go> 292 fps [21:44:45 CEST] <furq> yeah that's pretty quick for 1080p x264 [21:44:48 CEST] <furq> even if it is one frame [21:44:57 CEST] <furq> like i said, try using a faster preset [21:45:03 CEST] <furq> or a higher crf [21:45:07 CEST] <furq> it's not like you'll notice any difference [21:45:09 CEST] <styler2go> hmm.. what if i first egenrate 160x90 and then upscale it? woudl that be gast? [21:45:13 CEST] <furq> no [21:45:20 CEST] <styler2go> i just tried superfast, no change [21:45:30 CEST] <Kirito> No one on encoding individual frames? ¯\_(Ä)_/¯ [21:45:37 CEST] <Kirito> I don't understand why it doesn't Just Work [21:45:38 CEST] <styler2go> ok, last question: can i somehow set the framerate for this generated green? [21:45:52 CEST] <furq> s=1920x1080:r=25 [21:45:56 CEST] <styler2go> nice [21:45:59 CEST] <furq> Kirito: how are you extracting the frames [21:46:08 CEST] <furq> styler2go: you probably want to set the fps to 1 or something [21:46:12 CEST] <furq> that'll speed things up [21:46:18 CEST] <styler2go> ok at 1080p60 we'Re at 296 fps... thats good [21:46:26 CEST] <styler2go> i think i need the 60fps [21:46:31 CEST] <styler2go> the program i will use is pretty dumb [21:46:31 CEST] <Tatsh> Kirito, are you hand editing every frame and trying to reconstruct the video? [21:46:45 CEST] <Kirito> furq: https://gist.github.com/FujiMakoto/6c28eaf8581c1ca452af362125d40d20 [21:46:49 CEST] <Kirito> Tatsh: essentially yes [21:46:52 CEST] <Tatsh> by hand editing i mean, using a photo editor [21:47:12 CEST] <furq> why are you setting -r in the first ffmpeg invocation [21:47:52 CEST] <Kirito> Tatsh: essentially, yes; in this case batch editing with Photoshop [21:47:53 CEST] <furq> that whole -ignorefps bit doesn't do anything unless you're trying to drop/dup frames [21:47:56 CEST] <Tatsh> furq, it would make sense if he chooses to encode to a simple framerate like 25 [21:48:06 CEST] <furq> he's not encoding a video [21:48:11 CEST] <furq> a directory of pngs doesn't have a framerate [21:48:27 CEST] <furq> all -r does there is drop frames to maintain the same duration [21:48:27 CEST] <Kirito> the source video does [21:48:34 CEST] <furq> so? [21:48:40 CEST] <Kirito> I want them to be consistent? [21:48:43 CEST] <Kirito> How do I do this? [21:48:48 CEST] <furq> line 19 [21:48:55 CEST] <kepstin> it makes sense to use a constant framerate output (using -r output option or fps filter) when converting to a directory of images, because then you can just use the '-framerate' input option when turning them back into a video to make it the correct timing. [21:49:01 CEST] <Tatsh> if you're getting frames extracted from 29.97 or 23.976 how can you have .976 frames? [21:49:16 CEST] <furq> you know that videos don't have to be .000 seconds long, right [21:49:56 CEST] <furq> kepstin: surely you actually just want every frame, then use -r when rejoining [21:49:58 CEST] <Tatsh> no but if you extract exactly 1 second of a 29.97 video, you'll have 30 separate images [21:50:09 CEST] <furq> he's not extracting exactly one second [21:50:14 CEST] <furq> he's extracting every frame [21:50:16 CEST] <styler2go> Hmm.. So there's no way to speed up that video generation? what's the bottleneck? [21:50:28 CEST] <kepstin> furq: but then if the original video was variable framerate the timing could get screwed up. [21:50:31 CEST] <Tatsh> you'll have lower quality if you do anything else styler2go [21:50:33 CEST] <furq> sure [21:50:38 CEST] <Tatsh> possibly weird artifacts in the video [21:50:39 CEST] <furq> if it's vfr then -r makes some sense [21:50:50 CEST] <furq> although if it's vfr then this is generally going to turn out badly [21:50:51 CEST] <styler2go> Can there be artifacts if there is only green? [21:51:02 CEST] <Tatsh> depends on the quality level probably [21:51:04 CEST] <furq> if it's cfr then running ffprobe is a waste of time [21:51:22 CEST] <Tatsh> i imagine if you do -crf 40 on that video you'll see garbage somewhere [21:51:32 CEST] <furq> i'd be surprised if you noticed any difference [21:51:33 CEST] <styler2go> i'll just tryi it [21:51:35 CEST] <furq> you can probably just use -qp 51 [21:51:45 CEST] <furq> i'd expect -qp to be faster [21:51:47 CEST] <Tatsh> the algorithm is to look for differences and compress them but since there are no differences you get no benefit [21:51:54 CEST] <styler2go> ffmpeg -f lavfi -i color=color=green:s=1920x1080:r=60 -t 5166 -aspect 16:9 -preset superfast -crf 40 red.mp4 [21:52:05 CEST] <furq> styler2go: use -qp instead of -crf [21:52:07 CEST] <styler2go> that's my current line. can i use a different -f which is faster maybe? [21:52:11 CEST] <styler2go> -qp 40? [21:52:13 CEST] <Tatsh> i get 9x on that [21:52:15 CEST] <furq> you might as well use 50 [21:52:30 CEST] <furq> you're not going to get macroblocking on a single colour [21:52:37 CEST] <Kirito> So what commands should I run when extracting frames / re-encooding to prevent a 2 minute 18 second video from turning into a ~2 minute 40 second on re-encode? [21:52:37 CEST] <Tatsh> it's not particularly fast [21:52:43 CEST] <Tatsh> styler2go, do you have hardware encoding? [21:52:44 CEST] <styler2go> Unrecognized option 'qp'. Error splitting the argument list: Option not found [21:53:06 CEST] <furq> er [21:53:08 CEST] <styler2go> Tatsh compiled it myself with cuda support so probably yes [21:53:20 CEST] <kepstin> Kirito: is your source video constant framerate? If so, when turning it back from images to video, use the "-framerate" input option with the framerate from the original video. [21:53:22 CEST] <Tatsh> hmm even with hardware i only get 9x [21:53:23 CEST] <furq> -qp should work [21:53:27 CEST] <furq> are you sure it's using libx264 [21:53:30 CEST] <Tatsh> it's trying to compress but it can't find anything [21:53:50 CEST] <Tatsh> ffmpeg -f lavfi -i color=color=green:s=1920x1080:r=60 -t 5166 -aspect 16:9 -c:v h264_nvenc -rc constqp -qp 51 red.mp4 [21:53:54 CEST] <Tatsh> 9.4x [21:53:59 CEST] <styler2go> My current line is: ffmpeg -f lavfi -i color=color=green:s=1920x1080:r=60 -t 5166 -aspect 16:9 -preset superfast -qp 40 red.mp4 [21:54:18 CEST] <Tatsh> looks good to me though [21:54:20 CEST] <kepstin> Kirito: if your video is not constant framerate, use the "-r" *output* option (after -i) when turning the video into images, then use that same number on the "-framerate" input option when turning the images back to video [21:54:23 CEST] <styler2go> Tatsh: Unrecognized option 'rc'. [21:54:25 CEST] <Tatsh> but it's not fast; it will 5166/9 secnods [21:54:28 CEST] <Tatsh> seconds* [21:54:34 CEST] <Tatsh> you can wait :P [21:54:39 CEST] <imperito> I'm trying to use ffmpeg to create a live stream of an image file. I thought something like "ffmpeg -loop 1 image.png out.m3u8" would work, but it terminates after a short time [21:54:48 CEST] <Tatsh> styler2go, -rc is only for h264_nvenc [21:55:03 CEST] <imperito> Can anybody tell me what I need to add or change? [21:55:39 CEST] <Kirito> kepstin: I am, and I believe it should be constant framerate, but I'll need to check and be sure I guess. This is the command I'm using to re-encode: ffmpeg -threads 16 -f image2 -i "D:\Video\final\%06d.png" -framerate 29.97 -c:v huffyuv -r 29.97 "final.avi" [21:55:48 CEST] <styler2go> so mien doesnt have nvenc anymore.. might have deleted my compiled one [21:55:58 CEST] <Tatsh> styler2go, won't save much time anyway [21:56:17 CEST] <styler2go> are there pre-compiled ffmpegs with nvenc? [21:56:26 CEST] <styler2go> Tatsh i am just curios right now [21:56:30 CEST] <Tatsh> no that's not allowed [21:56:36 CEST] <kepstin> Kirito: you have a bunch of options in the wrong place. Input options go before the input! and remove the -r option on the re-encode. [21:56:39 CEST] <styler2go> hmm [21:56:49 CEST] <styler2go> well i am bored anyway.. why not compile ffmpeg lol [21:56:54 CEST] <Kirito> kepstin: right, okay, thanks @_@ [21:56:58 CEST] <Tatsh> well, it's allowed i think [21:57:05 CEST] <Tatsh> but you may not find any builds [21:57:29 CEST] <Tatsh> legally distributed builds will be lacking things fdk-aac, any other things that are patented [21:57:35 CEST] <kepstin> Kirito: also note that the exact value for the ntsc framerate is "30000/1001", using 29.97 is an approximation. Probably close enough for short videos. [21:57:54 CEST] <Kirito> ahh, thanks [21:58:12 CEST] <styler2go> https://p.styler2go.de/54932/ but it looks like i have nvenc enabled [21:59:58 CEST] <Tatsh> but do you have the hardware? [22:00:12 CEST] <Tatsh> i've got everything except HEVC on my GTX 980 [22:00:24 CEST] <styler2go> i got an 980ti [22:00:29 CEST] <styler2go> si it hsould be same as yours [22:00:54 CEST] <Tatsh> for i in encoders decoders filters; do echo $i:; ffmpeg -hide_banner -${i} | egrep -i "npp|cuvid|nvenc|cuda|vaapi|vdpau|vda|dxva2|nvdec|qsv"; done [22:01:03 CEST] <Tatsh> bash ^ [22:01:06 CEST] <styler2go> i am on windows [22:01:24 CEST] <Tatsh> not sure the equivalent on windows; but you can use powershell's grep perhaps [22:01:26 CEST] <Kirito> I think only the 10xx series GPU's have HEVC decoding capabilities [22:01:26 CEST] <Tatsh> either way [22:01:37 CEST] <Tatsh> ffmpeg -hide_banner -encoders [22:01:52 CEST] <Tatsh> ffmpeg -hide_banner -encoders | grep nvenc in powershell [22:02:00 CEST] <styler2go> Unrecognized option 'hide_banners'. [22:02:01 CEST] <styler2go> lol [22:02:08 CEST] <styler2go> oh ok, misread [22:02:09 CEST] <Tatsh> it's -hide_banner no s [22:02:25 CEST] <Tatsh> on windows you might have findstr in cmd [22:02:29 CEST] <styler2go> https://p.styler2go.de/1973572/ it does have some [22:02:34 CEST] <styler2go> different name tho [22:02:36 CEST] <Tatsh> ffmpeg -hide_banner -encoders | findstr nvenc [22:02:51 CEST] <Tatsh> yup [22:02:56 CEST] <Tatsh> so you even have HEVC [22:02:58 CEST] <styler2go> wow [22:03:04 CEST] <styler2go> nvenc fives me 450 fps [22:03:10 CEST] <styler2go> instead of 290 [22:03:19 CEST] <BtbN> the encoder being listed in -encoders does not mean it works. [22:03:31 CEST] <BtbN> There is no hardware feature detection done before you actually use it. [22:03:38 CEST] <Tatsh> that's true [22:03:43 CEST] <Tatsh> the hevc one fails for me [22:03:51 CEST] <styler2go> But it still doesn't work with rc option [22:03:52 CEST] <furq> yeah i have hevc_nvenc and i don't have an nvidia card [22:03:52 CEST] <Tatsh> some of the decoders fail to [22:04:12 CEST] <Tatsh> styler2go, show the output for [22:04:20 CEST] <Tatsh> ffmpeg -h encoder=nvenc_h264 [22:04:29 CEST] <BtbN> h264_nvenc [22:04:54 CEST] <furq> they both work [22:05:01 CEST] <styler2go> https://p.styler2go.de/9797058/ only those [22:05:02 CEST] <BtbN> all but that are deprecated [22:05:09 CEST] <Tatsh> hmm strange styler2go [22:05:16 CEST] <Tatsh> use -preset or -profile [22:05:31 CEST] <BtbN> you muste be using a very old ffmpeg version [22:05:31 CEST] <styler2go> the hvec is way slower for me [22:05:33 CEST] <Tatsh> or perhaps you can use -cbr 33k [22:05:43 CEST] <styler2go> BtbN ffmpeg version N-76757-g1c3e43a Copyright (c) 2000-2015 the FFmpeg developers [22:05:45 CEST] <Tatsh> the approximate bitrate needed to preserve static green [22:05:48 CEST] <Tatsh> 33k [22:05:48 CEST] <BtbN> yes. [22:05:52 CEST] <BtbN> Update that, it's ancient. [22:06:04 CEST] <styler2go> i don't want to set up all those build tools again :/ [22:06:11 CEST] <BtbN> then download a binary [22:06:23 CEST] <Kirito> kepstin: original file duration: 00:02:18.15, output duration: 00:02:18.13 [22:06:25 CEST] <Kirito> \o/ [22:06:47 CEST] <Kirito> yay doing things the wrong way forever and not realizing it. Helps to actually know how these things works and not just do what some guy on Google said you should [22:06:52 CEST] <styler2go> Tatsh: trying to set -cbr says: Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [22:07:09 CEST] <Tatsh> yea update your ffmpeg before pursuing further [22:07:11 CEST] <styler2go> BtbN theres no windows binary with nvenc sadly [22:07:19 CEST] <styler2go> humm [22:07:24 CEST] <furq> the zeranoe builds have nvenc [22:07:34 CEST] <furq> all builds have nvenc now [22:07:37 CEST] <styler2go> what [22:07:39 CEST] <styler2go> really? [22:07:41 CEST] <furq> yeah [22:07:44 CEST] <styler2go> wooow [22:08:04 CEST] <furq> the nvenc headers have been part of the ffmpeg source for a while [22:08:14 CEST] <furq> you don't need to fuck about with the sdk any more [22:08:32 CEST] <styler2go> but does it have mp3 now? [22:08:37 CEST] <styler2go> i am not sure if it had in the past [22:08:52 CEST] <styler2go> but there was a reason i compiled with enable-nonfree [22:08:57 CEST] <Tatsh> if you need mp3 you can use lame [22:09:02 CEST] <furq> you only need nonfree for fdk-aac [22:09:13 CEST] <furq> as far as audio encoders go [22:09:18 CEST] <furq> and the builtin aac encoder is acceptable now [22:09:22 CEST] <Tatsh> if you're streaming mp4 you're streaming AAC 99% of the time [22:09:38 CEST] <styler2go> cool, thanks [22:09:55 CEST] <furq> fdk is only worth it if you need he-aac [22:09:57 CEST] <furq> and you probably don't [22:10:31 CEST] <furq> it'd be worth it if you were encoding aac for archival, but why would you ever do that [22:10:37 CEST] <furq> for streaming, who gives a fuck [22:13:15 CEST] <styler2go> Tatsh: [nvenc_h264 @ 00000000026d9ee0] Unable to parse option value "33k" as boolean [22:13:26 CEST] <styler2go> so it's not -cbr [22:14:11 CEST] <styler2go> ok, it's running now.. 450fps .. i guess i just have to accept that [22:36:42 CEST] <pgorley> can the h264 decoder output different pixel formats directly (ie without converting the frames after the call to decode)? [22:38:17 CEST] <JEEB> pgorley: decoders are decoders, they output what there is in coded form [22:38:55 CEST] <kepstin> well, in theory the decoder could output in planar or non-planar form, i guess [22:39:25 CEST] <kepstin> but there's no real reason to do that, it's easier to write the decoder to work on one format without internal conversions. [22:40:03 CEST] <JEEB> planar/non-planar usually is just a thing between HW dec and SW dec. HW prefers NV12 and P010 [22:40:20 CEST] <JEEB> while SW stuff usually has things in planar format [22:40:45 CEST] <JEEB> the actual data is the sample of course (just in a different form) [22:40:50 CEST] <JEEB> *same [22:42:27 CEST] <kepstin> the x264 encoder says it accepts both packed and planar formats, but it actually just converts the packed ones to planar internally before encoding, it's just for convenience of people using the library [22:42:51 CEST] <JEEB> I thought x264 internally used NV12 [22:43:22 CEST] <JEEB> http://git.videolan.org/?p=x264.git;a=commit;h=387828eda87988ad821ce30f8188… [22:43:55 CEST] <kepstin> huh, alright then [22:44:13 CEST] <kepstin> turn my statement around "it actually just converts the planar ones to packet internally before encoding" :) [22:46:12 CEST] <imperito> I'm trying to make a live-stream video of an image file. I think I've fixed the issue with ffmpeg terminating after a short time, but I've still got 2 odd behaviors. One is that tht "time" displayed by the encoder advances faster than wall clock time. Is this a problem? [22:46:39 CEST] <kepstin> hmm, maybe not. I haven't looked into the x264 code recently, I wonder if it actually does have different codepaths for packed vs planar. [22:46:44 CEST] <imperito> the other is that the created video is all black on my iphone [22:47:57 CEST] <imperito> (the input image is not all black) [22:49:36 CEST] <pgorley> oh, alright then, thanks [22:49:39 CEST] <imperito> I'm wondering if there is something I need to do to set a frame rate [22:49:53 CEST] <imperito> since the input doesn't really have a frame rate [22:56:22 CEST] <kepstin> imperito: You have an image source? use the "-framerate" input option to set the framerate of the video it generates. I think the default is 25fps. [22:56:31 CEST] <kepstin> huh, so x264 internally uses the 'NV12' format for 4:2:0 and 'NV16' for 4:2:2, and 'I444' for 4:4:4, in 8-bit at least. [22:56:56 CEST] <kepstin> NV12 and NV16 are weird, because they have a separate luma plan, then interleaved chroma planes [22:56:58 CEST] <kepstin> wierd [22:57:07 CEST] <kepstin> I gues it's whatever makes their assembly faster :/ [22:57:41 CEST] <JEEB> basically it puts the data of the two chroma channels closer to each other I guess [22:57:42 CEST] <imperito> kepstin: I'd assume that 25fps would be satisfactory for live streaming? [22:59:04 CEST] <kepstin> imperito: depends what you're doing, but it doesn't seem unreasonable. [22:59:30 CEST] <imperito> the only reason I wondered at the framerate was the time displayed by ffmpeg advancing faster than real time. I wouldn't have expected that [22:59:56 CEST] <kepstin> imperito: what exactly are you trying to do, what "time" are you looking at? [23:01:08 CEST] <imperito> I've got a png file which is created and updated by a separate process. I'm trying to make a live video stream of this file using ffmpeg [23:01:45 CEST] <imperito> The time I'm looking at is the time=xx:xx:xx.xx field of the ffmpeg command line output while it is running [23:02:05 CEST] <imperito> (which may or may not be important, I suppose) [23:02:59 CEST] <imperito> The previous problem I had was that the external process was not updating the source image atomicly, which was causing ffmpeg to abort [23:03:30 CEST] <imperito> I changed that and now it seems to run continuously [23:04:20 CEST] <imperito> though the output is not yet as desired [23:04:57 CEST] <kepstin> imperito: ok, so ffmpeg by default runs its encoder as fast as possible, since it was designed originally as a batch tool - this means it's usually faster than realtime (the status line should have a speed indicator saying what x speed it's running [23:05:23 CEST] <kepstin> imperito: for live streaming from a source on the HD, you want to add the "-re" option to the ffmpeg command line, this slows ffmpeg down to run at realtime [23:05:46 CEST] <imperito> anywhere in particular? [23:06:07 CEST] <kepstin> input option, so before the -i [23:06:41 CEST] <kepstin> it basically makes ffmpeg pretend it's reading from a webcam or something that provides frames at a fixed speed [23:07:16 CEST] <imperito> seems reasonable. It is running that way now, and the fps=25 instead of like 57 as before [23:07:20 CEST] <styler2go> hey, i also need to add a fake soundlane to my generated video. any idea how? [23:07:53 CEST] <styler2go> my current command looks like that: ffmpeg -f lavfi -i color=color=green:s=1920x1080:r=60 -t 5166 -aspect 16:9 -c:v nvenc_h264 -rc constqp -qp 51 red.mp4 [23:07:57 CEST] <imperito> Though still a black screen on my phone [23:09:25 CEST] <kepstin> styler2go: "-f lavfi -i sine" or something like that [23:09:39 CEST] <styler2go> but i already have the input [23:09:51 CEST] <styler2go> i mean, i already set -i color= [23:09:57 CEST] <kepstin> you can have multiple inputs... [23:10:26 CEST] <imperito> I do get a warning about "No pixel format specified, puv444p for H.264 encoding chosen". Could that be the problem? [23:10:41 CEST] <imperito> er, yuv444p rather [23:11:13 CEST] <kepstin> imperito: ah, yes, that would do it. Most hardware encoders can only do 4:2:0. That message should also helpfully tell you what option to add to fix the problem, if you read it :) [23:11:35 CEST] <kepstin> or a nearby message, anyways [23:12:11 CEST] <imperito> There is a suggested alternative for outdated media players [23:12:17 CEST] <styler2go> any other ideas? [23:12:21 CEST] <imperito> I didn't think my phone was that old... :( [23:13:10 CEST] <kepstin> imperito: well, your phone probably can't do 10bit h264 video either, hardware decoders in portable devices are always some ways behind the times ;) [23:13:30 CEST] <kepstin> but yeah, use "-pix_fmt yuv420p" as an output option for max compatibility [23:13:37 CEST] <imperito> I see.Using yuv420p seems to have helped [23:16:07 CEST] <styler2go> Does anyone know how i can add a second simulated input? ffmpeg tells me: color=color=green:s=1920x1080:r=60: Invalid argument when i try ffmpeg -f lavfi -i aevalsrc=0 -i color=color=green:s=1920x1080:r=60 -t 5166 -aspect 16:9 -c:v nvenc_h264 -rc constqp -qp 51 red.mp4 [23:16:07 CEST] <imperito> Doesn't seem to be updating, though... [23:17:24 CEST] <kepstin> styler2go: you need to use -f lavfi again on the second input [23:17:25 CEST] <imperito> If I do something like "ffmpeg -loop 1 -re image.png", would it constantly re-read image.png? [23:17:57 CEST] <furq> no [23:18:18 CEST] <furq> you'd need to do something like while true; do cat image.png; done | ffmpeg -f image2pipe -i - [23:18:39 CEST] <imperito> OK, I'll try that, thanks [23:18:42 CEST] <styler2go> well, that worked already, thanks kepstin [23:18:54 CEST] <furq> and yes, that does suck really badly, but what are you going to do [23:19:35 CEST] <imperito> Eh, I'm not worried about a pretty command line, this is all on a cloud VM anyway [23:20:03 CEST] <imperito> Should I still use -re? [23:20:04 CEST] <furq> i don't just mean the aesthetics of the command line [23:20:11 CEST] <furq> and if you're streaming this then yes [23:21:29 CEST] <imperito> Ah, now it seems to be working as intended [23:25:35 CEST] <imperito> I wonder if I should add a sleep with the cat, so the pipe between the processes tends to be empty rather than full? Would that reduce latency? [23:27:29 CEST] <imperito> Eh, it looks good enough. [23:29:11 CEST] <furq> sleeping will make no difference [23:29:23 CEST] <furq> at least as far as my understanding of unix goes [23:29:33 CEST] <furq> other than that it'll probably cause shit to break if you sleep for too long [23:29:49 CEST] <imperito> Lets not do that, than :) [23:30:37 CEST] <imperito> I'll leave it running like this overnight, hopefully nothing crashes [23:36:30 CEST] <imperito> Heh, python sitting on half my memory, ffmpeg on half my CPU. If I do more streams I'm going to need a bigger VM [00:00:00 CEST] --- Thu Jun 15 2017

1 0

ffmpeg-devel.log.20170613
by burek 14 Jun '17

14 Jun '17

[04:18:41 CEST] <cone-100> ffmpeg 03Michael Niedermayer 07master:db93fd74e4be: avcodec/golomb: Assert that the input is not too large in set_ue_golomb() [04:18:41 CEST] <cone-100> ffmpeg 03Michael Niedermayer 07master:4f9e958b04c6: avcodec/put_bits: Implement put_bits32() in a single pass instead of 2 passes writing 16bits each [12:50:53 CEST] <atomnuker> do we still need libtwolame support? [12:51:10 CEST] <atomnuker> we've had our own encoder for a very long time and its from what I know quite alright [12:53:27 CEST] <nevcairiel> twolame is higher quality then ffmp2 [12:54:33 CEST] <atomnuker> I guess when you're encoding mpeg2 you need all the quality you can get [13:03:19 CEST] <kierank> twolame is better iirc [13:12:35 CEST] <JEEB> was there any OSS bit stream analyzer that would let me check if what I think was set in VUI was indeed set? [13:12:38 CEST] <JEEB> (H.264) [13:13:15 CEST] <kierank> h264parse [13:13:32 CEST] <kierank> or just stick some printfs in ffmoeg [13:14:24 CEST] <JEEB> hmm, there also seems to be something called https://github.com/shi-yan/H264Naked [13:14:39 CEST] <JEEB> which is a Qt based interface on top of libh264stream [13:14:45 CEST] <jkqxz> <https://lists.libav.org/pipermail/libav-devel/2017-May/083758.html> [13:15:35 CEST] <JEEB> funky [13:24:00 CEST] <jkqxz> wm4: Does this rockchip thing have discussion somewhere else? [13:25:04 CEST] <wm4> I think I did most of this in private communication with longchair [13:26:02 CEST] <wm4> jkqxz: should we make him join here? [13:26:38 CEST] <J_Darnley> WTF!? I can apparently fix the problem by removing the perm_type assignment. [13:27:26 CEST] <jkqxz> wm4: Sure, if that's possible. [13:28:12 CEST] <wm4> LongChair: hi, jkqxz is markt [13:28:26 CEST] <LongChair> Hi everyone ;) [13:28:34 CEST] <J_Darnley> WTF?! It isn't even runnig my code [13:28:41 CEST] <LongChair> i think i talked to him already, but that was a while ago :) [13:28:42 CEST] <J_Darnley> WTF?! It isn't even running my code [13:29:33 CEST] <LongChair> jkqxz: available to answer any specific questions if you have any :) [13:29:39 CEST] <jkqxz> Hi. Yeah, I recognised the name, but I couldn't remember exactly what that was about. [13:30:07 CEST] <LongChair> we talked about the framecontext iirc [13:30:16 CEST] <LongChair> but that is out of topic :) [13:30:29 CEST] <jkqxz> My main concern is that adding a new format like this is tying us to a specific format, and will propagate into everything else as people want to add more features. [13:30:49 CEST] <jkqxz> Well, I'd prefer if hwcontext were not out of topic! [13:31:36 CEST] <jkqxz> Because, for example, someone will come along and say "I want to render subtitles on top of this thing", and then add some sort of crazy support in libavfilter. [13:31:45 CEST] <LongChair> Well, the main thing is that outside rockchip specific work, there are some other perspectives that got me try to get something standard [13:31:46 CEST] <jkqxz> With no commonality with anything else. [13:32:47 CEST] <jkqxz> So I'd kindof prefer a hwcontext form, because then you have things like mapping and transfer in a common way which will avoid specific support for this DRM setup in random places. [13:32:58 CEST] <LongChair> drmprime is mostly intended to render to a drm layer which is an overlay. it's the only way to achieve a proper performance on embedded devices [13:33:49 CEST] <LongChair> also when deving this i found out that both drm and egl / dmabuf rendering had a lot of things in common [13:33:49 CEST] <jkqxz> I admit the hwcontext implementation is kindof silly, though, because there isn't a device and the frames context doesn't really contain much. [13:33:54 CEST] <J_Darnley> FUCK! If I assign NULL to those function pointer it then segfaults [13:34:10 CEST] <jkqxz> This will also get used for encode on those devices, though? [13:34:37 CEST] <LongChair> jkqxz: yeah i didn't find any existing pixfmt that would allow to have that type of frame information, that is one that allows renderer to use zerocopy [13:34:53 CEST] <wm4> jkqxz: well I added one for osx anyway [13:34:57 CEST] <jkqxz> (Which probably doesn't support hardware overlays, so you have to actually blend.) [13:35:03 CEST] <wm4> it does almost nothing (dummy device etc.) [13:35:12 CEST] <LongChair> i don't think drm is used for any encoding process [13:35:28 CEST] <jkqxz> It would still be a new DRM pixfmt. [13:35:57 CEST] <LongChair> just that that set of info (fds, strides, offsetts) are used for drm, egl dmabuf, and also v4L2 in some modes [13:36:35 CEST] <LongChair> so it would make sense to have some "standard" pixfmt that can help renderers to handle a single format [13:36:50 CEST] <LongChair> rather than reivneting the wheel for every platform :) [13:37:22 CEST] <jkqxz> Yes, there would still be a new DRM pixfmt. I'm just wanting to set up the metadata so that we don't reinvent other wheels. [13:38:56 CEST] <LongChair> Sorry but i'm not sure to understand what you are meaning with "metadata" :) [13:39:34 CEST] <wm4> the DRM fourcc, strides, offsets, I think [13:39:46 CEST] <jkqxz> Whatever is sufficient to let the existing av_hwframe_map() and related functions work. [13:40:05 CEST] <LongChair> dmabuf can be mmaped [13:40:25 CEST] <LongChair> at least the fds [13:40:47 CEST] <jkqxz> Indeed. So the hwcontext implementation will do that in av_hwframe_map() and then vf_hwmap will work magically for everyone. [13:41:16 CEST] <wm4> jkqxz: do you want to do mpp->drm as mapping between different pixfmts? [13:41:25 CEST] <J_Darnley> I hate this DSP crap. Why is permutation an option?! Why is it not binary? Why can some function be NULL and not others? [13:42:26 CEST] <jkqxz> Not sure? If the MppFrame really is useless then having the decoder output the DRM pixfmt directly is reasonable, but if it has some other use then maybe. [13:43:09 CEST] <wm4> jkqxz: I don't think exporting mpp has any use at this point [13:43:16 CEST] <wm4> but Indon't know details [13:43:44 CEST] <LongChair> MPPFrame is just what comes out of MPP, the av_drmprime forwards the interesting information [13:44:21 CEST] <wm4> do the rockchip guys have any APIs for postproc yet? like deint [13:44:44 CEST] <LongChair> mmaping the av_drmprime fds which are coming from the MPPFrame would allow to get a planar surface that matches the FOURCC format [13:45:20 CEST] <wm4> (just that the 10 bit format is useless) [13:45:35 CEST] <LongChair> true [13:46:47 CEST] <LongChair> their 10 bits format, cannot be really processed as it's packet 10bits [13:46:54 CEST] <LongChair> packed* [13:47:01 CEST] <wm4> (grrr) [13:47:34 CEST] <atomnuker> we have a decoder for packed 10bits now, though only does 422 [13:48:14 CEST] <LongChair> their decoder will basically output standard 8 bits NV12 or that crappy format which is non standard. the reason for this format is that it's memory efficient and allows to significantly reduce the frames footprint in memory and reduces the data transfer. sepcially given 10 bits is mostly used with 4K HEVC :) [13:49:05 CEST] <LongChair> but it's non standard. that one can be processed by the hardware which is behind the drm implementation. but useless in software [13:49:50 CEST] <wm4> I wonder what they'll do with 12 bit data [13:50:15 CEST] <LongChair> packed 12 bits ? :) [13:50:58 CEST] <LongChair> well they could probably move to NV12 with 16bits stuff in later chips, because later chips could use AFBC (Arm FrameBuffer Compression) [13:51:35 CEST] <LongChair> that would release the pressure on memory by gettting compressed frames ... but then we'll have the same issue with reading AFBC buffers :) [13:54:03 CEST] <LongChair> anyways NV12 could probbaly be used easilly mmpaing those fds, NV12 (10bits packed) would imho be useless because of all the processing it would involved [13:54:11 CEST] <LongChair> mmaping* [13:55:11 CEST] <BtbN> You mean P010? NV12 is 8bit [13:55:52 CEST] <wm4> no, mpp uses an actually packed 10 bit format [13:55:53 CEST] <LongChair> isn't P010 NV12 with 16bits per component ? [13:56:02 CEST] <wm4> similar to P010, but packed per plane [13:56:50 CEST] <BtbN> that sounds kinda insane [13:57:03 CEST] <wm4> because it is [13:57:20 CEST] <wm4> and there's some danger theyr're going to use P010 as fourcc for it in the kernel [13:58:18 CEST] <LongChair> it was formerly called NV12_10 in their kernel, not sure how they will upstream that [13:59:55 CEST] <jkqxz> So something like <http://sprunge.us/XIai>. [14:00:44 CEST] <LongChair> that paste doesn't work here :) [14:00:57 CEST] <jkqxz> The DRM pixfmt would then be a single pointer to an AVDRMFrameDescriptor, which is also a buffer reference. [14:01:23 CEST] <jkqxz> The nonempty device and frames contexts are unnecessary for that case, but would let hwupload work. [14:01:28 CEST] <jkqxz> *for the decoder case [14:02:13 CEST] <jkqxz> The decoder can create a trivial frames context and use that, it doesn't really matter (there is no preallocation at all, so you can't map to fixed-pool things anyway). [14:02:48 CEST] <jkqxz> It doesn't work? What would work? [14:03:27 CEST] <jkqxz> <http://ixia.jkqxz.net/~mrt/hwcontext_drm.h> [14:05:51 CEST] <jkqxz> The hwcontext implementation would want to implement at least transfer and map-to-memory, which would give you av_hwframe_transfer() and av_hwframe_map(), allowing a lot of use in lavfi. [14:07:12 CEST] <wm4> in theory [14:07:25 CEST] <wm4> but in practice it's too slow, and the 10 bit format shirts the bed [14:08:17 CEST] <jkqxz> Even just writing subtitles on part of an existing image is too slow? [14:08:42 CEST] <jkqxz> (Is there a cheap SBC with this thing on I could just buy to try it?) [14:10:02 CEST] <LongChair> ASUS Tinkerboard [14:14:56 CEST] <LongChair> jkqxz: well not sure if it's relevant, but we wouldn't use the same image for subtitles on such devices. [14:15:23 CEST] <LongChair> drm has layers that can be combined usually in hardware [14:15:49 CEST] <LongChair> typically in mpv we'd use the primary layer which is used through opengl to render subittles [14:15:58 CEST] <LongChair> the video layer would be in the back [14:16:42 CEST] <LongChair> also on such devices, rendering in high resolution (ie 4K) is usally a bottleneck for performance [14:17:01 CEST] <wm4> yeah, the hw will also do forced rgb conversion and such [14:17:14 CEST] <wm4> which is not nice, but typical primitive hwdec API [14:17:50 CEST] <LongChair> we would usually just have a video layer that is purely renderered by hardware (in rockchip case this doesn't even go thru GPU, but directly from memory to another IP which is used for video scaling) [14:18:15 CEST] <LongChair> GPU on such devices can usually not handle Opengl rendering at proper framerate in 4K [14:19:11 CEST] <LongChair> so we render video to a layer via drm in 4K, for the rest we render GUI / subtitles to primary drm layer which is sized to a lower res (ie 1080) and uspcaled to 4K on top via drm as well [14:19:52 CEST] <LongChair> so GPU will only handle the opengl stuff in 1080p, rest is done by scaler / compositor thru drm api [14:20:43 CEST] <jkqxz> 50GBP on Amazon. Ok, I've ordered one. [14:20:51 CEST] <wm4> jkqxz is (at least currently) mostly concerned with hw transcoding (decoding + encoding), so he's thinking about a way to render subs directly to the surfaces [14:21:00 CEST] <LongChair> in the same area, other devices would use compressed buffers on embedded devices (AFBC is the most common), so adding stuff on top of the buffer would mean decompress / add / recompress [14:21:25 CEST] <LongChair> not mentionning that AFBC compression might be non public stuff (not sure) [14:22:43 CEST] <LongChair> I understand what transcoding required. Although i see a global performance issue there :) [14:24:02 CEST] <jkqxz> When you're transcoding 4K it's probably because you needed to downscale for some weaker device anyway. [14:25:50 CEST] <jkqxz> And I'm still not sure what the performance issue with writing on a small part of the surface is going to be anyway. [14:27:28 CEST] <jkqxz> (Maybe if it turns out to be some sort of crazy uncached memory, but I imagine mobile stuff all using the same memory will try to act sensibly there.) [14:30:40 CEST] <jkqxz> So, is there any reason not to have the hwcontext formulation? For your uses, it shouldn't be any overhead at all (you can just ignore it if you only want the DRM objects from the decoder). [14:35:08 CEST] <wm4> so your point is mostly that we should drop the new libavcodec public header, and move it to hwcontext [14:35:25 CEST] <wm4> but the struct would essentially survive? [14:35:54 CEST] <jkqxz> Yes. [14:36:12 CEST] <cone-228> ffmpeg 03Matthieu Bouron 07master:3839580b7134: lavc/mediacodecdec: switch to the new generic filtering mechanism [14:37:05 CEST] <jkqxz> As I said above, my concern isn't that there is any problem with this method, it's that when people want to extend it it will be horrible if we have separate API everywhere. [14:37:32 CEST] <wm4> yeah [14:40:38 CEST] <wm4> LongChair: can you make a change based on that? [15:07:31 CEST] <JEEB> mateo`: nice, I will have to test out the bsf'ification [15:09:01 CEST] <mateo`> JEEB: I tested on my end and it works as expected (hope i haven't missed anything) [15:09:24 CEST] <mateo`> JEEB: did you find out if ndk r15 was the cause of your issues with mediacodec the other day ? [15:09:59 CEST] <mateo`> I did a quick test and ffmpeg was still working with r15 for me [15:10:29 CEST] <wm4> mateo`: btw. I got a report that mediacodec fails with h264 if avformat_find_stream_info() is skipped on HLS (and presumably .ts) - any real reason for that? [15:10:33 CEST] <kierank> michaelni: can you help J_Darnley if you have time [15:11:20 CEST] <cone-228> ffmpeg 03Paul B Mahol 07master:f85cad799b52: avfilter: properly set SAR for A->V filters [15:11:57 CEST] <mateo`> wm4: because avctx->{width, height, extradata} are mandatory probably [15:12:14 CEST] <wm4> extradata? for annexb? [15:12:20 CEST] <wm4> that would be batshit insane [15:12:28 CEST] <wm4> and I don't understand the need for width/height either [15:12:53 CEST] <michaelni> J_Darnley, can i help somehow ? [15:13:16 CEST] <mateo`> I though at least width/height were mandatory when I started writing the wrapper [15:13:28 CEST] <wm4> I mean the SPS is going to contain that, and a decoder will have to be able to react to SPS and resolution changes too [15:13:50 CEST] <wm4> and if it's really required, why the fuck did Google make it annex b and not avcc [15:13:57 CEST] <kierank> michaelni: seel ml [15:14:01 CEST] <kierank> see* [15:15:00 CEST] <JEEB> mateo`: huh, funky. I do see that el goog failed in other things with r15 looking at the bug reports [15:15:01 CEST] <mateo`> it's not required by MediaCodec, it's required by the wrapper to help us detect at init time if the underlying decoder support the stream [15:15:21 CEST] <JEEB> but if r15 works for you then that's rather funk'ologic [15:15:28 CEST] <wm4> ah [15:15:37 CEST] <mateo`> JEEB: i was not able to compile the whole stack i use at work due to header changes, but ffmpeg did [15:15:40 CEST] <wm4> well you could just fail at runtime [15:16:21 CEST] <mateo`> indeed, I guess it was easier to implement this way at the time [15:17:18 CEST] <mateo`> well recently i had to patch the decoder to remove the requirements of width/height but i had to deduces it from extradata at init times [15:17:40 CEST] <mateo`> because some decoders were asserting when doing their init [15:18:18 CEST] <wm4> they assert if the size is not supported? just how garbage can android get [15:19:30 CEST] <mateo`> because i was setting width=0 height=0 and they were doing something like assert(width*height>=sps_width*sps_height) internally [15:21:37 CEST] <mateo`> i can try to remove the dependency over extradata, width, height if that helps you [15:36:37 CEST] <JEEB> btw, what sort of buffer sizes in HRD are utilized in broadcast usually? I'd guess something along the lines of 0.5-1 seconds? [15:36:58 CEST] <JEEB> (and then CBR filling for a CBR mux) [15:37:50 CEST] <jdarnley> Ah ha. Found something possibly useful. "libavcodec/tests/dct -i 2" shows an obvious difference. [15:41:32 CEST] <DHE> JEEB: I can probably find out... [15:43:09 CEST] <DHE> oh dear, most of what I see around here is mpeg2. still want it? [15:45:04 CEST] <mateo`> mmm, idct8x8-0 now fails on aarch64 [15:45:28 CEST] Action: jdarnley wonders if he managed to cause that too [15:46:11 CEST] <DHE> JEEB: what I extracted from my broadcast sources (not OTA, but close enough) was mpeg2 1080i. video bitrate estimated at 17.3 megabit CBR, buffer size estimated at 3000 kbit [15:48:15 CEST] <kierank> jdarnley: yes 0.5 to 1 second [15:48:18 CEST] <kierank> JEEB: [15:48:19 CEST] <kierank> i mean [15:48:32 CEST] <kierank> sometimes 2 [15:48:59 CEST] <JEEB> DHE, kierank - cheers :) [16:14:53 CEST] <jdarnley> Is there an archive of old coverage reports on the website? [16:16:37 CEST] <mateo`> jdarnley: regarding the aarch64 failure, it's probably due to edf686f089d68092c3b17a23cc48667665b5a069 [16:17:15 CEST] <mateo`> and because the aarch64 simple idct neon code not accurate enough, maybe [16:17:25 CEST] <mateo`> i will investigate [16:38:13 CEST] <jdarnley> mateo`: I was joking when I wondered whether I broke it. I haven't altered arm or the tests. [16:44:10 CEST] <LongChair> @wm4 : sorry was sidetracked, reading back [16:45:38 CEST] <mateo`> jdarnley: I didn't get the joke (but didn't think the breakage was your fault either) [16:49:06 CEST] <jdarnley> :) [16:54:06 CEST] <LongChair> jkqxz: is there any chance that you could give me a few pointers on where to look at for that hwcontext thing. I saw the sample you posted, but i'd need to see how those structs are used and what for maybe in other decoders :) [17:04:50 CEST] <atomnuker> grr, I need to finish adding support for post-skip in ogg/opus files [17:08:11 CEST] <mateo`> jdarnley: i broke it :/ [17:41:06 CEST] <cone-228> ffmpeg 03Michael Niedermayer 07master:d549f026d8b6: avcodec/sbrdsp_fixed: Return an error from sbr_hf_apply_noise() if operations are impossible [17:41:07 CEST] <cone-228> ffmpeg 03Michael Niedermayer 07master:d1992448d37f: avcodec/aacsbr_fixed: Check shift in sbr_hf_assemble() [17:41:08 CEST] <cone-228> ffmpeg 03Michael Niedermayer 07master:4cc2a357f5dc: avcodec/aacsbr_fixed: Fix signed integer overflow in sbr_hf_inverse_filter() [17:47:26 CEST] <cone-228> ffmpeg 03Matthieu Bouron 07master:8aa60606fb64: lavc/aarch64/simple_idct: fix idct_col4_top coefficient [17:48:49 CEST] <cone-228> ffmpeg 03Matthieu Bouron 07release/3.3:20f5e2c17785: lavc/aarch64/simple_idct: fix idct_col4_top coefficient [18:49:22 CEST] <JEEB> mateo`: btw which API level are you using? [18:49:25 CEST] <JEEB> 21 for me [18:50:20 CEST] <mateo`> 19 for me [19:30:27 CEST] <durandal_1707> https://youtube.com/watch?v=nKR44fDM_uc [19:33:01 CEST] <durandal_1707> there is one guy who only fixes security issues, says in podcast [19:53:29 CEST] <cone-228> ffmpeg 03Timo Rothenpieler 07master:21583e936a06: avfilter/unsharp: fix uninitialized pointer read [19:53:30 CEST] <cone-228> ffmpeg 03Timo Rothenpieler 07master:0fbc9bbbbb39: avfilter/vf_scale_npp: fix out-of-bounds reads [19:53:31 CEST] <cone-228> ffmpeg 03Timo Rothenpieler 07master:4b2a2969f3e0: avformat/librtmp: check return value of setsockopt [19:53:32 CEST] <cone-228> ffmpeg 03Timo Rothenpieler 07master:a5b5ce2658bf: avformat/pcmdec: fix memory leak [19:53:33 CEST] <cone-228> ffmpeg 03Timo Rothenpieler 07master:feb13aed794a: avfilter/vf_signature: fix memory leaks in error cases [19:55:36 CEST] <philipl> BtbN: have you looked at how to do generic hwaccel for ffmpeg.c for cuda? Is any work even necessary? [19:55:51 CEST] <BtbN> i'd assume it'd just work? [19:59:36 CEST] <philipl> just rm ffmpeg_cuda.c? [20:02:08 CEST] <BtbN> Is the thing even merged yet? [20:11:33 CEST] <philipl> No. but presumably will be soonish [20:23:11 CEST] <wm4> did anyone ever look at supporting PolarSSL/mbed in ffmpeg? [20:23:26 CEST] <wm4> (I have no idea whether it's license compatible, or technically feasible) [20:25:02 CEST] <wbs> wm4: I had a 2 minute look back when I made the original backends, but back then it was gplv2 which didn't really feel like it was worth the effort [20:25:12 CEST] <wbs> wm4: with apache2 now it might be more useful [20:28:41 CEST] <wm4> yeah, potentially [20:42:56 CEST] <rcombs> how far along is OpenSSL's apache relicense, anyway [20:53:35 CEST] <wm4> apparently it started only in march this year [20:53:46 CEST] <wm4> when they also got bad press for badly worded relicensing mails [21:14:13 CEST] <rcombs> their CLA process is awful [21:14:24 CEST] <rcombs> requires signing a (not easily-located) PDF and emailing it in [21:14:40 CEST] <rcombs> I've got no problem with CLAs for these things but fuck signing PDFs [21:14:52 CEST] <rcombs> that's an excellent way to get people not to bother [21:24:36 CEST] Action: JEEB wonders how much random magic people put in their ARM FFmpeg configure lines [21:26:38 CEST] <JEEB> stuff like extra-cflags="-mfpu=neon" [21:27:52 CEST] <wbs> JEEB: many environments' baseline is armv7 but without neon, so the compiler isn't free to use neon anywhere in normal generated code [21:28:20 CEST] <wbs> JEEB: back before 2012 or something such, you would have needed this in order to build with neon simd, but since then we build the neon code regardless and only enable it at runtime if found [21:28:30 CEST] <JEEB> yea [21:29:02 CEST] <JEEB> I'm just wondering how much extra optimizations you get by specifically enabling mfpu neon etc :V [21:29:15 CEST] <JEEB> I just noticed one of my build scripts had extra-cflags="-mcpu=cortex-a8 -mfpu=neon" [21:29:20 CEST] <JEEB> and I wonder if I should just drop it [21:29:53 CEST] <JEEB> with x86 I just know that the gains you get from any additional flags is so small it doesn't matter [21:29:57 CEST] <wbs> well, it allows the compiler to use neon instructions for some e.g. 16 byte loads/stores and such [21:30:14 CEST] <wbs> especially as long as autovectorization isn't enabled, it probably doesn't gain you anything worthwhile [21:30:25 CEST] <wbs> in general I'd recommend removing any extra custom flags you don't really need [21:30:39 CEST] <JEEB> yea, the autovectorization stuff's been disabled for a long time [21:30:52 CEST] <JEEB> (there was a brief moment of it being enabled IIRC) [21:31:15 CEST] <JEEB> but yea, I guess no voodoo [21:31:20 CEST] <JEEB> also for some weird reason I had enabled thumb [21:31:37 CEST] Action: JEEB stares at his past self [21:32:21 CEST] <wbs> well thumb is pretty commonly on by default in armv7-baseline toolchains, since iirc they all have thumb2 (and thumb2 is not all too bad contrary to thumb1) [21:41:51 CEST] <rcombs> I mentioned a while ago but here's a fun fact [21:42:19 CEST] <rcombs> autoconf inserts -O2 (I think, one of the -O args) in CFLAGS _only if the env variable is empty at configure-time_ [21:42:35 CEST] <rcombs> otherwise it uses whatever you passed and doesn't add an optimization flag [21:43:01 CEST] <rcombs> (found this out when people complained about libopusenc being slow on ARM) [21:43:33 CEST] <wbs> yeah, that's a rather annoying thing. I sometimes inject extra cflags via the CC variable when dealing with autotools [21:44:10 CEST] <rcombs> I sometimes do that when dealing with libtool, since it just _discards compiler/linker flags it doesn't recognize_ [21:44:48 CEST] <JEEB> hah :D [21:58:50 CEST] <BBB> jdarnley: do you need any more help with the idct patch? [22:00:02 CEST] <jdarnley> Yes. [22:00:20 CEST] <jdarnley> Have you seen my two rant-filled emails? [22:01:06 CEST] <jdarnley> Otherwise I can give you a summary of where I am [22:12:57 CEST] <jamrial> ubitux: anything stopping your aacps patches? both the checkasm test and the aarch64 functions [22:14:31 CEST] <jamrial> can't say what to do with that test you found that's failing on arm [22:18:46 CEST] <BBB> jdarnley: well I did see the rants [22:19:06 CEST] <BBB> jdarnley: Im not quire sure what the problem was, maybe you can explain it in less ranty and more technical terms to me? [22:22:32 CEST] <jdarnley> Sure [22:22:57 CEST] <ubitux> jamrial: yeah i guess i need to investigate that bug [22:23:08 CEST] <ubitux> otherwise nothing special is preventing the push [22:23:30 CEST] <jdarnley> The first problem michaelni highlighed (using 3 out of 6 patches) was because the perm_type I set was used for idct add/put functions with different permutation [22:23:42 CEST] <ubitux> jdarnley: then the aarch64 functions need to be optimized, one is still slower [22:23:50 CEST] <ubitux> that's what i'm doing tomorrow [22:24:04 CEST] <jdarnley> I think you mean jamrial ^ [22:24:16 CEST] <jamrial> ubitux: you can look at what i did for deint/ileave (or the arm version for the former) if you want to also port them to aarch64 [22:24:24 CEST] <BBB> jdarnley: uh& wait [22:24:32 CEST] <BBB> jdarnley: you used different perm_type for idct_add/put than for idct?? [22:24:36 CEST] <BBB> how is that even possible [22:24:47 CEST] <ubitux> jamrial: ah yeah i need to write that one, maybe in a next iteration [22:24:52 CEST] <BBB> or you mean it was a typo and you forgot to set it to the correct one? [22:25:47 CEST] <jdarnley> No, letting the old MMX code set the 3 pointer and perm_type correctly, then I overwrote the idct func. pointer and the perm_type. [22:26:04 CEST] <jdarnley> Basically the 3 new functions must be appplied together [22:26:14 CEST] <jdarnley> (I might squash the patches together) [22:26:16 CEST] <BBB> oh right I see what you mean [22:26:19 CEST] <BBB> yes yes indeed [22:26:27 CEST] <BBB> I understand the problem now [22:26:45 CEST] <BBB> so michaelni is it fixed when you apply all patches (including 4/5/6) from the series? [22:26:51 CEST] <jdarnley> No [22:26:59 CEST] <jdarnley> It is still different in that case [22:27:17 CEST] <BBB> do you know what specifically is different? [22:27:25 CEST] <BBB> is it idct, add, put, all 3? [22:27:46 CEST] <jdarnley> Probably all 3 becuase the idct is wrong. [22:27:59 CEST] <BBB> slightly wrong or totally garbage? [22:28:03 CEST] <jdarnley> I discovered the alternative tests of libavcodec/tests/dct [22:28:08 CEST] <jdarnley> Only slightly [22:28:24 CEST] <jdarnley> try running: libavcodec/tests/dct -i 2 [22:28:27 CEST] <BBB> got a tree I can pull for testing? [22:30:45 CEST] <jdarnley> The previous link I gave to Gitlab should be the same [22:31:13 CEST] <jdarnley> Yeah, it's just missing a rebase [22:31:40 CEST] <jdarnley> https://gitlab.com/J_Darnley/ffmpeg/commits/mpeg2_asm2 [22:32:46 CEST] <BBB> is that the remote I use for git also? [22:33:23 CEST] <jdarnley> No [22:34:09 CEST] <jdarnley> https://J_Darnley@gitlab.com/J_Darnley/ffmpeg.git [22:34:14 CEST] <jdarnley> mpeg2_asm2 branch [22:35:05 CEST] <jdarnley> What? Where's that @ come from? [22:35:07 CEST] <jdarnley> https://gitlab.com/J_Darnley/ffmpeg.git [22:35:26 CEST] <jdarnley> sorry [22:35:51 CEST] <BBB> its ok it worked [22:35:52 CEST] <BBB> :-p [22:35:57 CEST] <BBB> Im now signed on as you [22:36:02 CEST] <BBB> <evil> [22:36:08 CEST] <BBB> what do I look for? [22:36:10 CEST] <jdarnley> Oh. I thought that might need login credentials [22:36:19 CEST] <jdarnley> try running: libavcodec/tests/dct -i 2 [22:36:37 CEST] <jdarnley> You should see that the new functions don't produce the same output as MMX [22:37:06 CEST] <BBB> IDCT SIMPLE8-SSE2 vs. IDCT SIMPLE-MMX ? [22:37:11 CEST] <jdarnley> yes [22:37:48 CEST] <BBB> what is -i 2? [22:38:02 CEST] <jdarnley> -i <-- run IDCT tests [22:38:22 CEST] <jdarnley> 2 <-- run "test 2" [22:38:34 CEST] <jdarnley> I think a comment said it was from an mpeg spec [22:39:34 CEST] <jdarnley> Ah no, it's from the help output of that [22:39:46 CEST] <jdarnley> -h [22:40:03 CEST] <jdarnley> brb [22:42:57 CEST] <jdarnley> back [22:59:14 CEST] <BBB> I got a test case, working on it... [22:59:30 CEST] <BBB> cant say this is mega-exciting but Ill see what I can do ;) [23:04:11 CEST] <jdarnley> Ha. I typed up most of an email this afternoon that was supposed to be a reply to michaelni but I never sent it. [23:20:39 CEST] <wm4> so the new bit reader code actually blocks a feature now? (vp9 vaapi encode support or something) [23:22:43 CEST] <jkqxz> Not really, it's very easy to convert. I just didn't really want to bother. [23:25:17 CEST] <jkqxz> philipl: It should just work by removing the ffmpeg_cuvid file and changing the hwaccel table entry. That on its own would change the default behaviour of the hwaccel, though - without -hwaccel_output_format it will download by default. [23:26:11 CEST] <jkqxz> Probably that isn't what you want? Really a consequence of the clumsy fake-hwaccel stuff, though, so I'm not sure how it would want to be fixed. [23:26:19 CEST] <jkqxz> Detect fake hwaccels and default to using the hardware format with them, maybe? [23:28:29 CEST] <BtbN> don't those fake hwaccels only exist because ffmpeg.c is bad in the first place? [23:28:30 CEST] <wm4> might be a problem for "compatibility" maybe [23:32:08 CEST] <TMM> hi all, I've finished the reverse engineering of these extra video formats for ipmovie, I'm trying to figure out how to implement this in avformat/avcodec now [23:32:47 CEST] <TMM> currently ipmovie.c / interplayvideo.c assumes only one type of video format, what would be the best way of adding support for two more distinct frame formats to it? [23:33:03 CEST] <TMM> well, frame encodings I suppose [23:33:44 CEST] <TMM> I can just add a flag to the base structure for the format and handle that in interplayvideo.c, but that's not how it works for, say, avi. Should I rework ipvideo to be a container format somehow? [23:34:17 CEST] <TMM> also; would an encoder be a mandatory part of a patch to ffmpeg? [23:34:25 CEST] <JEEB> no [23:34:31 CEST] <JEEB> decoder-only patches are completely OK [23:34:49 CEST] <JEEB> we have various formats where making an encoder (as in creating /more/ files in a format) just doesn't make sense [23:34:56 CEST] <wm4> either new codec ID, or maybe just switch on codec_tag or make up extradata for parameters [23:35:14 CEST] <TMM> wm4, there are only 3 possibilities [23:35:43 CEST] <wm4> not sure if codec_tag is appropriate for putting in random parameters, but I don't think anyone would mind [23:36:51 CEST] <TMM> ipmovie.c already has several extra fields that aren't non-standard it seems, and I need at least one more (for an extra data stream) [23:37:04 CEST] <TMM> IPMVEContext [23:37:11 CEST] <TMM> I could stick it in there [23:37:42 CEST] <durandal_1707> if stuff is not signalled in bitstream use extradata [23:38:12 CEST] <nevcairiel> you can do whatever you want internally in the demuxer, the question is what information you need to communicate to the video decoder, if any [23:38:49 CEST] <TMM> i need to communicate the frame format, the 'decoding map (already used by the current frame format), and a 'skip map' [23:38:50 CEST] <durandal_1707> eg. demuxer signals via extradata to decoder some info [23:39:00 CEST] <TMM> is that this IPMVEContext struct? [23:39:53 CEST] <wm4> demuxer and decoder are strictly separate [23:40:03 CEST] <wm4> you can't access the IP specific structs from each other [23:40:24 CEST] <durandal_1707> TMM: no, thats private to demuxer/decoder [23:40:37 CEST] <BBB> wtf [23:40:42 CEST] <BBB> the dc in pass 1 is 1 off [23:40:48 CEST] <BBB> how on earth is that possible [23:40:52 CEST] <TMM> ok, I'll have to figure out how this data is handed to interplayvideo.c now then [23:40:56 CEST] <durandal_1707> you can signal frame from demuxer to decoder [23:41:30 CEST] <BBB> jdarnley: -13087 in sse2 vs. -13088 in mmx/c [23:41:35 CEST] <BBB> dc at end of pass=1 [23:41:40 CEST] <TMM> also; if one of you would mind having a look at this fine loop: https://notabug.org/hp/rekingdom/src/master/video.c#L405 <--- this is my implementation. I'm calling this a 'skip map' but perhaps someone recognizes this structure as something that has a real name [23:44:31 CEST] <BBB> oh curse it its the special dc-only behaviour which is broken [23:44:39 CEST] <BBB> I dont think we want to fix that [23:45:17 CEST] <durandal_1707> TMM: skip map is fine [23:45:39 CEST] <jdarnley> BBB: I missed that? [23:46:03 CEST] <jdarnley> oh.. [23:46:51 CEST] <BBB> remember how W4 changed from 16384 to 16383 [23:46:56 CEST] <jdarnley> yes [23:46:58 CEST] <BBB> that should really be 1638 [23:47:01 CEST] <BBB> 16384 [23:47:09 CEST] <BBB> I dont know why it is 16383 in the mmx code [23:47:28 CEST] <BBB> I believe that slightly alters the dc coefficient outputs in the non-dc-only case of the C code [23:47:38 CEST] <jdarnley> Because the 8-bit C code has 16383 [23:48:12 CEST] <BBB> I dont understand why thought [23:48:13 CEST] <BBB> -t [23:48:22 CEST] <BBB> why wouldnt we make it 16384? [23:48:27 CEST] <BBB> theres no overflow at 14bit [23:49:01 CEST] <BBB> anyway [23:49:07 CEST] <BBB> so thats causing the differences between sse2/mmx [23:49:10 CEST] <BBB> or sse2/c [23:49:30 CEST] <BBB> the c code says that if dc-only, do a special case where you just shift it [23:49:40 CEST] <BBB> which is identical to coef which is power-of-two [23:49:42 CEST] <BBB> such as 16384 [23:49:47 CEST] <BBB> then in the non-dconly case, use 16383 [23:49:50 CEST] <BBB> the mmx code does that too [23:49:58 CEST] <BBB> the sse2 code has no special case, it always does a full idct [23:50:06 CEST] <BBB> so in both cases it uses either 16384 or 16383 [23:50:09 CEST] <BBB> that acuses the bug [23:50:22 CEST] <TMM> hum, I'm looking at libavformat/ipmovie.c I don't quite understand how the chunk map gets sent to libavcodec/interplayvideo.c, it seems to appear as a avctx->priv_data. [23:50:30 CEST] <jdarnley> Well that is a comprehensive explaination. [23:50:36 CEST] <TMM> it's a different structure, but I can't figure out where it's being filled [23:51:20 CEST] <nevcairiel> maybe the entire chunk is just part of the video track and decoded [23:51:42 CEST] <TMM> some of it seems to come from avpkt->data [23:52:01 CEST] <TMM> I'd need two of those though? grmbl [23:53:31 CEST] <jdarnley> Okay... new branch, coeff change, see what happens [23:53:39 CEST] <jdarnley> BBB: What about the W3 change? 19266 vs 9265 [23:53:47 CEST] <BBB> not sure yet [23:53:47 CEST] <jdarnley> 19266 vs 19265 [23:53:53 CEST] <jdarnley> okay [23:54:02 CEST] <BBB> but if we change the C code and MMX code to use 16384, it should be fine [23:54:06 CEST] <BBB> that may break other things, not sure [23:54:10 CEST] <BBB> this mpeg stuff is creepy :D [23:54:21 CEST] <TMM> wm4, also, sorry, I didn't realize that IpvideoContext and IPMVEContext were completely different... I should listen better [23:56:50 CEST] <durandal_1707> TMM: demuxer prepares data for decoder [23:57:09 CEST] <BBB> yes, I get 0 maxErr after that for mmx, sse2 as well as C [23:57:13 CEST] <BBB> so they match exactly [23:57:29 CEST] <BBB> I cant really comment on why the value 16383 was there, even the comments say 16384.000 is what it should be [23:57:44 CEST] <jdarnley> A many year old typo? [23:57:52 CEST] <BBB> ... [23:57:58 CEST] <BBB> I wish I knew [23:58:09 CEST] <BBB> Im really quite quite quite sure the value should be 16384 [23:58:22 CEST] <BBB> michaelni: any idea? [23:58:24 CEST] Action: jdarnley goes to his server for this testing [23:58:37 CEST] <BBB> sorry for having to go through this [23:58:42 CEST] <BBB> this is probably not the most fun thing to work on [23:59:29 CEST] <BBB> 19266 vs. 19265, the 19266 may be more correct [23:59:33 CEST] <BBB> the rounded value is 19265.54 [23:59:40 CEST] <BBB> so correct rounding would make that 19266 [23:59:53 CEST] <BBB> I dont know why we made it 19265 for the 10bit case [00:00:00 CEST] --- Wed Jun 14 2017

1 0

ffmpeg.log.20170613
by burek 14 Jun '17

14 Jun '17

[00:00:07 CEST] <momomo> regarding the question of 1s vs 5s for file size output for say 60 seconds ... ( i guess I could test it ) ... would it differ much ... [00:01:11 CEST] <DHE> yes. you would have 60 keyframes rather than 12 [00:01:25 CEST] <DHE> depending on the resolution, a keyframe of 80 to 150 kilobytes is quite normal [00:04:17 CEST] <momomo> ook, good to know [00:04:25 CEST] <DHE> one other question. how are you streaming this? over a local LAN? bandwidth constrained internet? [00:04:26 CEST] <momomo> DHE: have you ever looked into dash? [00:04:50 CEST] <DHE> only briefly. I got into HLS and it's kinda stuck with me [00:04:51 CEST] <momomo> DHE: on both .. but there is not much traffic as of yet ... [00:05:01 CEST] <DHE> even though DASH is technically a standard while HLS isn't [00:05:12 CEST] <momomo> yeah me too, but it appears as if dash is gaining ground [00:05:21 CEST] <momomo> seems to be the best solution, but not sure [00:05:43 CEST] <momomo> since I believe you do not have to segment files and can target byte ranges (?) [00:06:15 CEST] <momomo> if one connects to a hls stream through ffmpeg is the output also segment files ? [00:06:16 CEST] <DHE> depends what you're doing. segmentation with HLS isn't technically necessary either but only if it's a pre-rendered video. doesn't work that way for, say, webcams [00:06:21 CEST] <momomo> many questions :P [00:07:10 CEST] <momomo> hmm... but I guess you still have to serve "segment" files by picking out the right bytes to serve the client ? [00:07:15 CEST] <momomo> i am not sure how to do that in java [00:07:34 CEST] <DHE> HTTP has a Range header which lets a client specify which bytes it wants [00:07:59 CEST] <momomo> yes, isn't that what dash uses? [00:08:18 CEST] <momomo> maybe dash/hls is basically the same .. only the way it's done is different .. [00:08:26 CEST] <momomo> or? [00:08:33 CEST] <DHE> conceptually they are very similar, yes. [00:09:00 CEST] <DHE> I know with HLS you can render the video in a single huge file (plus playlist) but only if you can pre-render it. webcams are live and that doesn't work so well. [00:09:35 CEST] <momomo> DHE: are you the guy behind live jasmine ? :P haha [00:09:52 CEST] <momomo> or what it's called :) [00:09:56 CEST] <DHE> uhh... no [00:10:00 CEST] <momomo> haha [00:10:03 CEST] <momomo> just joking [00:10:14 CEST] <momomo> can I share something with you privately ? [00:10:40 CEST] <momomo> it's not porn related, I swear! [00:10:44 CEST] <Tatsh> nvenc is so sweet if you don't have noisy content [00:11:00 CEST] <Tatsh> progressive dvd -> mp4 in a few minutes [00:11:10 CEST] <Tatsh> my system gets 40x [00:11:33 CEST] <DHE> Tatsh: it's fast, but x264 software mode usually gives better quality/bitrate [00:11:39 CEST] <Tatsh> yes [00:11:45 CEST] <momomo> DHE: i am unable to send you a private message .. you seem to have that turned off in case you wasn't aware [00:11:48 CEST] <Tatsh> and i have to play with it a lot [00:11:52 CEST] <Tatsh> -rc constqp -qp .. [00:11:55 CEST] <DHE> momomo: I am aware. I wrong the block [00:12:00 CEST] <Tatsh> -qp is not some static number you can apply [00:12:07 CEST] <Tatsh> it differs a lot based on the content and size of the content [00:13:35 CEST] <DHE> momomo: what exactly do you want there? [00:14:03 CEST] <momomo> DHE: just show you what you our work. share a link to the "site" [00:14:16 CEST] <momomo> dont want to publicize it here [00:14:45 CEST] <DHE> that's fine. I don't need to see it. I'm a bit busy anyway [00:15:04 CEST] <momomo> DHE: that sound like an expensive task to click a link [00:17:49 CEST] <DHE> well it's going to be more than just clicking a link [00:19:55 CEST] <Tatsh> 4k such hq, you get aliasing errors on live downscale :P [00:20:41 CEST] <buu> Silly question, but does Duration: 03:02:33.66, start: 0.000000, bitrate: 3091 kb/s actually mean kilo*bits* [00:20:46 CEST] <buu> And why does ffprobe write to stderr [00:20:58 CEST] <Tatsh> buu, yes b = bit [00:21:18 CEST] <buu> usually true, yup [00:21:25 CEST] <Tatsh> what you are seeing might be of like, the bitrate on the first frame [00:21:25 CEST] <DHE> also note that ffmpeg is very stingy on "k" vs "ki", and "M" (mega) vs "m" (milli) etc [00:22:25 CEST] <Tatsh> buu, who knows on stderr.. developer preference [00:22:45 CEST] <Tatsh> i was scripting ffmpeg with python and found that out too [00:24:14 CEST] <kerio> how many millibits do you need to encode a 720p30 video [00:24:17 CEST] <buu> Tatsh: Yeah, ffmpeg does it as sort of an error output [00:24:24 CEST] <momomo> DHE: https://pastebin.com/zKTPwwTx .. i have to go now ... but mo @ my username . com if you change your mind [00:24:29 CEST] <Tatsh> kerio, depends on content [00:24:33 CEST] <buu> but I assumed ffprobe might be smarter! [00:27:40 CEST] <buu> kerio: I just did that math, at 1280x720 pixels per frame and 30 frames per second you need at most 108MB/s [00:27:46 CEST] <buu> hope that helps [00:28:01 CEST] <kerio> what pixel format tho [00:28:21 CEST] <buu> I was assuming 4bytes per pixel [00:28:29 CEST] <buu> which honestly might be low [00:28:37 CEST] <kerio> ye i like my videos to be half transparent n shit [00:28:46 CEST] <buu> good point [00:29:05 CEST] <kerio> so make that 5 Bpp [00:29:07 CEST] <buu> a single byte is only 256 values [00:29:20 CEST] <kerio> 10 bit per channel [00:29:42 CEST] <buu> I'm glad we've figured this all out [00:30:50 CEST] <Tatsh> 5.1 britney spears https://i.imgtc.com/A8UWWdj.png [00:37:18 CEST] <Threads> you have me wanting to check 5.1 music even more now [01:02:50 CEST] <DHE> I think I've been burned by momomo... [04:18:20 CEST] <Tatsh> threads even 2.1 sound would be an improvement over the red book quality [04:32:39 CEST] <guest12343> Hi. Looking for help with webm making. [05:36:08 CEST] <Sashmo_> does anyone know of a way to encode say 30 frames of images and cylce them every 30 seconds and create a TS stream with 0 video bitrate, and only burst the video on each realod? for example 0 video bitrate for 30 seconds, burst up to 300k to send the video, and then back down to 0 ? [05:36:36 CEST] <Sashmo_> I've seen it before, but I can't recall how to re-create it [06:02:29 CEST] <thomedy> hello [06:02:39 CEST] <thomedy> can i talk to this room about video file editing [06:02:45 CEST] <thomedy> is this the room for tht [06:38:17 CEST] <guest12343> Hello. Looking for help with webm making. [07:16:36 CEST] <pbgswd> is there a moviepy irc channel? It appears not [07:39:52 CEST] <thomedy> im desperate please someone be here [07:39:59 CEST] <thomedy> i hve raw avi [07:40:06 CEST] <thomedy> ffmpeg -i gives raw video [07:40:15 CEST] <thomedy> right click shows raw [07:41:01 CEST] <thomedy> which means that it should be completely uncompressed right? why when i isolate 5 seconds in the middle and try to play it apart from the rest of the video i cant do it [07:41:52 CEST] <thomedy> Format avi detected only with low score of 1, misdetection possible! new.avi: Invalid data found when processing input [07:42:05 CEST] <thomedy> thata is what im getting [07:42:13 CEST] <kerio> what is "raw avi" [07:42:53 CEST] <thomedy> k [07:43:12 CEST] <thomedy> with whaat i have been reading avi format can hold uncompressed video files [07:43:31 CEST] <thomedy> not every time but can.. my properties say raw [07:43:55 CEST] <thomedy> .avi with uncompressed non-codec or whatever [07:44:12 CEST] <thebombzen> thomedy: because avi is a container format that provides information on things like duration, and seeking [07:44:24 CEST] <thebombzen> and chunks the actual video information into pieces so it can be managed by a video player [07:44:57 CEST] <thomedy> so if i have this right it takes timed frames and describes each frame over and over [07:45:02 CEST] <thebombzen> AVI is a "container format" which means it is specifically just a method of putting multiple media streams together in one file. In your case there's only one stream and it's a uncompressed video stream [07:45:28 CEST] <thebombzen> However, AVI is not like .wav. It's not just a header and then the data [07:45:34 CEST] <thomedy> i remember readding that raw is a consistent stream rate [07:45:44 CEST] <thomedy> lets say i have a mov [07:45:47 CEST] <thebombzen> if you try to truncate the file in the middle it won't work. You'll get a corrupt file [07:45:49 CEST] <thomedy> how do i uncompress that [07:45:59 CEST] <thebombzen> You probably don't want to uncompress it [07:46:02 CEST] <thomedy> and yes that is absolutely getting corrupted [07:46:03 CEST] <thebombzen> what are you actually trying to do? [07:46:19 CEST] <thomedy> i want for example just seconds 30 - 35 [07:46:37 CEST] <thomedy> but i need it competely isolated from the rest and no knowledge of the rest [07:46:39 CEST] <thomedy> when i pay it [07:46:49 CEST] <thomedy> play [07:47:08 CEST] <thebombzen> You can do that with: ffmpeg -ss 30 -i input.mov -t 5 output.mov [07:47:09 CEST] <thomedy> which is why raw [07:47:26 CEST] <thebombzen> this will read the input file (input.mov, or input.avi, doesn't matter, ffmpeg will autodetect the file type) [07:47:41 CEST] <thebombzen> this will read it, seek to 30 seconds, and then encode 5 seconds from there [07:47:55 CEST] <thebombzen> You don't need a raw AVI to do that. [07:48:16 CEST] <thomedy> the problem im having is its starting encrypted.. i want to encrypt decrypt and only decrypt 5 seconds of it.. if i go raw i dont have to anticipate the codec yet which is the eventual goal [07:48:31 CEST] <thebombzen> encrypt/decrypt? Do you mean encode/decode? [07:48:38 CEST] <thebombzen> because FFmpeg will do that for you. FFmpeg will decode the video and then re-encode it. [07:48:48 CEST] <thomedy> nope i mean turn the the video file into total garbarge [07:49:05 CEST] <thebombzen> Then you need to back up and explain exactly what you're trying to do [07:49:07 CEST] <thomedy> and only make for example 5 s to 10 s readable again [07:49:15 CEST] <thomedy> okay i have some files im trying to secure [07:49:38 CEST] <thebombzen> You are trying to encrypt some files but you want a 5-second interval in the middle of the file to be readable? [07:49:45 CEST] <thomedy> absolutely [07:49:52 CEST] <thebombzen> .... why do you want to do that? [07:50:04 CEST] <thomedy> its just something im doing unfortunately [07:50:12 CEST] <thebombzen> Well I suggest you don't do that. [07:50:19 CEST] <thomedy> i dont know if i could convince you of the logic... but i do really want ot... [07:50:28 CEST] <thebombzen> Well that doens't make any sense [07:50:51 CEST] <thebombzen> and as far as I know, what you're describing isn't possible. If you're sure you want to do something weird like that they it makes the most sense to chunk the file into three separate pieces [07:51:23 CEST] <thebombzen> the video before the start of the 5-second interval, the 5 seconds you want to be unencrypted, and then everything after that [07:51:36 CEST] <thebombzen> and then you can use whatever encryption method you want to encrypt the first and the third pieces but not the second [07:51:44 CEST] <thomedy> you were saying it is broken up into pieces right [07:52:08 CEST] <thomedy> i was reading a bit ago and obviously i can only kno wwhat i learn on the web right now [07:52:22 CEST] <thomedy> but that there are seperate frames and the frame is described each time [07:52:33 CEST] <thebombzen> What are you actually trying to do? [07:52:46 CEST] <thomedy> i dont know how to be more clear [07:52:59 CEST] <thebombzen> You do realize that "encrypt" is a term used to scramble data so it can only be decrypted with a key or password, right? [07:53:03 CEST] <thomedy> yep [07:53:07 CEST] <thomedy> and thats whyat im doing [07:53:38 CEST] <thomedy> i m going to stab the dog out o my window... does anyone mind [07:53:41 CEST] <thomedy> he keeps barking [07:53:42 CEST] <thebombzen> You're trying to encrypt every part of a file except for a 5-second interval in the middle? This is not possible with one file [07:54:11 CEST] <thebombzen> The only way to accomplish this is to do it with three separate files [07:54:30 CEST] <thebombzen> have one video file for the first part, one video file for the five-second interval in the middle, and one video file for everything after that [07:54:38 CEST] <thebombzen> and then encrypt the first and the third video files, but not the second. [07:55:41 CEST] <thebombzen> But again, this sort of weird project you're doing for no reason [07:55:48 CEST] <thebombzen> it sounds to me like you're misunderstanding a homework question [07:55:59 CEST] <thebombzen> because I cannot for the life of me think of why you would want to do that [07:55:59 CEST] <thomedy> its not homework i havent been in college in a while [07:56:03 CEST] <thomedy> but thats funny [07:56:13 CEST] <thebombzen> What is this for? [07:58:10 CEST] <thomedy> okay so that you guys dont have to do my work for me im going to do some more research into file codecs, and compression [07:58:21 CEST] <thomedy> cuz i feel like im missing something conceptual [08:02:27 CEST] <thomedy> okay feel free to laugh at me but fuck it all i think im goign to write my own compression algorithm [08:05:55 CEST] <thomedy> you know what nope im probably good off tht for a while i sitll want to but no tyet [08:09:08 CEST] <buu> am I missing insanity [08:09:53 CEST] <buu> thomedy: if you want multiple streams just encode multiple streams into a file [08:10:45 CEST] <thomedy> buu: you might be missing the insanity .... you know that disease where people dont feel pain and its no good... i get that when i disease when i have a goal in mind [08:11:11 CEST] <thomedy> now grnted i dont want to do the worst thing possible just for the sake of it but i want to be able to encrypt. whole files [08:11:15 CEST] <buu> thomedy: http://ffmpeg.gusari.org/viewtopic.php?f=12&t=828 [08:11:35 CEST] <thomedy> and only decrypt and play a portion [08:12:04 CEST] <buu> [container {encrypted video1} {encrypted audio1} {decrypted video2} {encrypted video3}] [08:12:20 CEST] <buu> What's the issue? [08:13:04 CEST] <thomedy> the issues is that my encryption decryption algorithm totallyl kicks ass but i dont know enough about video yet [08:13:11 CEST] <thomedy> so im reading the link you got to me right now [08:13:14 CEST] <thomedy> it looks promising [08:14:55 CEST] <buu> you know, there's a saying about people who write their on encryption algorithms [08:16:00 CEST] <thomedy> nope i dont know it [08:16:12 CEST] <thomedy> im curious to hear it though cuz mines done and getting cooler every time [08:16:17 CEST] <thomedy> done sorry [08:16:21 CEST] <thomedy> cool but growing [08:16:57 CEST] <buu> oh [08:16:59 CEST] <buu> they're idiots [08:17:02 CEST] <buu> that's the saying [08:17:21 CEST] <thomedy> too late im an idiot [08:17:24 CEST] <thomedy> im down [08:17:51 CEST] <thomedy> by the way i think that crap is normally said by people afraid to take a chance and then too lazy to put the work in [08:17:57 CEST] <thomedy> these algorithms come from somwhere [08:19:55 CEST] <buu> It's more that A) there's not really a massive demand B) really, really hard C) major consequences for failure [08:20:50 CEST] <thomedy> hmmm.... 2 really good points specifically the part c... part b ... to me doesn't mean crap.. [08:21:08 CEST] <thomedy> let me hit a more important point.. [08:21:25 CEST] <thomedy> im learnign about codec and reading your article [08:21:40 CEST] <thomedy> but im going to try to bullet point your statement earlier to confirm [08:21:49 CEST] <thomedy> a single vidoe file has multiple streams [08:23:33 CEST] <buu> technically a container, but sure [08:24:05 CEST] <thomedy> okay [08:24:06 CEST] <thomedy> cool [08:24:06 CEST] <buu> thomedy: https://en.wikipedia.org/wiki/Ogg [08:24:12 CEST] <thomedy> oooh cool [08:25:36 CEST] <thomedy> okay thats enough for now im going to go work on something else i hve to be up in the morning [08:25:39 CEST] <thomedy> thanks everyone [08:49:30 CEST] <ArsenArsen> Hello! I've written a universal encoder with libavcodec, libavformat, libswscale, and libavutil. It works for webm, webp, mp4, but for gif it fails to open and gives me `Invalid argument'. I have a feeling that something I set in my AVCodecContext is wrong. Thanks in advance for any help [08:52:12 CEST] <ArsenArsen> https://gist.github.com/ArsenArsen/bfec7872f3366073d07d35cf8714f4da [08:52:16 CEST] <ArsenArsen> Those are my settings [08:58:26 CEST] <ArsenArsen> Oh I figured it out. It's the pixel format. Thanks anyway [09:03:35 CEST] <guest113412> Hello. Looking for help with webm making. [09:12:55 CEST] <ArsenArsen> guest113412, whats up [09:13:44 CEST] <apaul> hi all. [09:14:44 CEST] <apaul> How can I use drawtext filter and vaapi vf 'format=nv12|vaapi,hwupload' together? I am stuck. Please help. [09:14:48 CEST] <guest113412> I have an animated .gif file and audio file. I want to loop gif to achieve audio duration and then create .webm file. The problem is there is no obvious efficient way to do that. [09:16:50 CEST] <guest113412> I tried to convert it directly to webm using -ignore_loop 0; -f lavfi -i "movie=filename=file.gif.webm:loop=0, setpts=N/(FRAME_RATE*TB)", -f concat and many other ways [09:17:34 CEST] <furq> guest113412: if the gif loops then -ignore_loop 0 -i foo.gif -i bar.wav -shortest out.webm [09:17:46 CEST] <guest113412> But t can't reach acceptable performance [09:23:24 CEST] <guest113412> furq, already tried, not really efficient [09:23:45 CEST] <ArsenArsen> Ugh.. This keeps happening and I have no clue why `Provided packet is too small, needs to be 9739` when I try encoding GIF [09:24:13 CEST] <hardening> hi guys [09:24:20 CEST] <ArsenArsen> Oh my packet is empty [09:24:22 CEST] <ArsenArsen> Hmm [09:25:15 CEST] <hardening> I finally managed to get the VAAPI accelerator to work with my C program, anyway I hit something [09:27:49 CEST] <hardening> When the match on the h264 profile is done it is done very strictly, so I was in the case were the stream was H264BaselineConstrained and the hardware was supporting H264Baseline, as it's for decoding I guess that it would be supposed to work (as the constrained version is just a subset of the full version). What do you think ? [09:28:59 CEST] <furq> what does "not really efficient" mean [09:29:57 CEST] <furq> hardening: constrained baseline should work on devices that decode baseline, yeah [09:30:24 CEST] <furq> emphasis on "should" because people are terrible [09:31:02 CEST] <hardening> furq: well I've done some subtle changes to have the profile match less strict and it works [09:33:04 CEST] <hardening> furq: IMHO it makes perfect sense for encoders to have the perfect match, but for decoders we should ignore the contrained flags [09:43:55 CEST] <guest113412> furq, mean there is at least two methods that are faster [09:48:15 CEST] <jkqxz> hardening: Sounds like two driver bugs. As far as I know no hardware supports baseline profile, so that is probably just wrong. Second, VAAPI requires that the driver reports support for profiles which are subsets of others, so it shouldn't be able to declare baseline but not constrained baseline at all. [09:50:00 CEST] <hardening> jkqxz: ok, anyway that's exactly what I have here => https://pastebin.com/fESGMsQv [09:51:53 CEST] <jkqxz> Oh, old mesa. That's fixed in newer versions. [11:13:46 CEST] <thunfisch> hi, slight problem: I'm recording 18 channels from a single alsa interface and want to write every channel out to a separate file with flac encoding. i'm using -map_channel for that, and it's working, but somehow ffmpeg only uses one thread for everything which is too much for that little cpu. [11:14:07 CEST] <thunfisch> https://paste.xinu.at/YncP/ [11:14:43 CEST] <thunfisch> any idea how I might better balance the load? [14:52:07 CEST] <amey> Need a review if the following code is correct. Objective is to down sample an audio frame(PCM) to 5512 Hz. Also suggest me if there is a better way than this. Here is code: https://pastebin.com/sr05rQgm [15:09:42 CEST] <Fyr> is it possible to make libx264 utilize opencl? [15:10:06 CEST] <BtbN> yes [15:10:08 CEST] <BtbN> but it's mostly useless [15:10:18 CEST] <Fyr> BtbN, why so? [15:10:26 CEST] <BtbN> Because there is no noticeable benefit. [15:10:39 CEST] <Fyr> BtbN, is it -x264-params "opencl=1" ? [15:10:45 CEST] <BtbN> no idea [15:10:50 CEST] <Fyr> =( [15:11:01 CEST] <BtbN> It does _not_ use the GPU for encoding [15:11:08 CEST] <BtbN> only for some very specific tasks that a GPU can handle [15:11:15 CEST] <Fyr> I was so happy to use flac opencl encoder. =/ [15:11:20 CEST] <BtbN> and the uploading/downloading of data almost completely negates any performance benefits [15:11:27 CEST] <Fyr> it worked 52 times faster than that of FFMPEG. [15:11:29 CEST] <BtbN> GPUs are bad at video de/encoding [15:13:23 CEST] <Fyr> GPUs are good when unloading CPU for transcoding. [15:13:58 CEST] <Fyr> when I convert with CPU, I use 100% of my CPU; when I convert with GPU, I use 1% of my CPU. [15:14:18 CEST] <Fyr> of course, I notice the quality loss. [15:14:41 CEST] <Fyr> flacCL utilizes 1-2% of my CPU. [15:14:45 CEST] <BtbN> The task of video de/encoding is not something the highly parallel nature of GPUs is useful for [15:14:45 CEST] <Fyr> without quality loss. [15:14:49 CEST] <BtbN> they are really really bad at it [15:14:55 CEST] <BtbN> And flac is not video [15:17:19 CEST] <Mavrik> Well. [15:17:25 CEST] <DHE> note that opencl and nvenc are two VERY different things [15:17:28 CEST] <Mavrik> GPU encoders are actually noticably worse than x264 [15:17:37 CEST] <BtbN> Also, they are not GPU encoders [15:17:44 CEST] <BtbN> they are dedicated silicon on graphics cards [15:17:46 CEST] <DHE> x264 can offload some tasks like look-ahead to the GPU. I've seen performance differences from 20% to -20% (!!) [15:18:13 CEST] <BtbN> It having to shovel all the frame data back and forth negates most of its benefits [15:18:13 CEST] <DHE> at the end of the day I'm sticking with pure software though [15:18:41 CEST] <Mavrik> On nvenc I've seen you need about +20-30% bitrate to get same quality as x264 slower presets. [15:18:45 CEST] <furq> isn't opencl lookahead supposed to also be marginally worse quality [15:18:50 CEST] <Mavrik> So if you actually want to produce good looking videos, use CPU [15:18:55 CEST] <Mavrik> For live stuff it's fine. [15:18:55 CEST] <DHE> furq: probably. didn't actually measure it though [15:18:58 CEST] <BtbN> nvenc is actually a pretty decent hwencoder by now, compared to all the other ones [15:19:03 CEST] <furq> yeah i've used it before and never noticed [15:19:05 CEST] <furq> but i remember reading that [15:19:08 CEST] <BtbN> of course it has no chance against x264 [15:19:12 CEST] <furq> the speedup wasn't worth the risk anyway [15:19:16 CEST] <furq> i was getting like 3-4% [15:19:43 CEST] <DHE> doing real-time captures on my GPU anyway at, say, 40 megabit h264 and then letting the CPU compress it later might be worthwhile. and if you're doing realtime streaming it's nice to offload the graphics [15:19:53 CEST] <Mavrik> Yeah. [15:20:02 CEST] <furq> and yeah it's probably fair to say at this point that nothing will ever touch x264 for h264 encoding [15:20:05 CEST] <DHE> but for a media archive, x264 on slow(er?) preset [15:20:31 CEST] <furq> and we're probably a good few years away from any consumer hardware outperforming it for any codec [15:20:54 CEST] <BtbN> for h264, I doubt any hardware will ever outperform x264 in terms of quality [15:20:58 CEST] <BtbN> for HEVC, maybe [15:21:07 CEST] <BtbN> But then x265 will be the better choice still [15:21:11 CEST] <furq> hardware or software really [15:21:19 CEST] <furq> nobody's going to invest years into making a better h264 encoder in 2017 [15:21:59 CEST] <furq> tbh i'd be way less surprised if hardware hevc started beating x265 [15:22:08 CEST] <furq> still quite surprised though [15:28:38 CEST] <Mavrik> I don't see people investing a lot in x265 anyway. [15:28:48 CEST] <Mavrik> The patent BS will probably mean that VP9 is better choice. [15:30:18 CEST] <Fyr> VP9 almost is not implemented as hardware decoder. [15:30:32 CEST] <Fyr> only the latest NVidia GPU have it. [15:30:59 CEST] <Fyr> VP9 FullHD utilized 10-11% of my CPU when playing video. [15:31:09 CEST] <Fyr> H264 uses only 1-2%. [15:31:46 CEST] <BtbN> Intel also has it [15:32:04 CEST] <Fyr> the latest, perhaps. [15:32:46 CEST] <Mavrik> Bunch of hardware has (and will have) VP9 decoders. [15:32:51 CEST] <Mavrik> Since YT is going full on there. [15:33:46 CEST] <Mavrik> Apparently Intel supports VP9 HW acceleration since Haswell [15:34:03 CEST] <JEEB> yea, my TV can handle 8 and 10 bit VP9 [15:34:24 CEST] <Mavrik> Also 4K/HDR YT will only be available in the new VP9 profile [15:34:31 CEST] <Mavrik> So HW manufacturers will have to roll over :) [15:34:44 CEST] <JEEB> now I just need more HLG samples :P [15:34:47 CEST] <furq> only kaby lake has full vp9 hwdec iirc [15:34:58 CEST] <furq> before that it's "hybrid" which i assume means it doesn't really do anything [15:34:59 CEST] <JEEB> well VP9 decoding is heavily optimized even on CPUs [15:35:05 CEST] <furq> although yeah [15:35:11 CEST] <furq> i've never had any issues doing it in software [15:35:11 CEST] <Mavrik> *shrug* No idea, works fine on my Mac [15:35:16 CEST] <Mavrik> And it's not Kaby Lake [15:35:20 CEST] <Mavrik> And neither nVidia. [15:35:50 CEST] <furq> 14:28:38 ( Mavrik) I don't see people investing a lot in x265 anyway. [15:35:55 CEST] <furq> it is picking up some traction, annoyingly [15:36:07 CEST] <furq> i know some dvb-t2 deployments are using it now [15:36:14 CEST] <Mavrik> Maybe Apple will finnally manage to shove HEVC down peoples throats [15:36:15 CEST] <furq> and obviously netflix [15:36:20 CEST] <Mavrik> So they can collect those sweet royalties :) [15:36:21 CEST] <furq> and yeah apple ;_; [15:36:37 CEST] <furq> i have to wonder how much of a backhander apple got to suddenly announce they're using a new hevc-based image format [15:36:51 CEST] <furq> or if they did it for free just to see the look on google's face [15:37:16 CEST] <Mavrik> They're part of HEVC patent pool :) [15:37:41 CEST] <furq> which one [15:38:01 CEST] <Mavrik> MPEG-LA [15:38:30 CEST] <furq> well then that's still three others they could've got a backhander from [15:38:48 CEST] <furq> although it's been a whole week since i found out about #4, so there's probably two more now [15:39:46 CEST] <Mavrik> Apple == $$$$, everybody jumping on the wagon [15:40:36 CEST] <furq> i found a picture of the hevc licensing bodies [15:40:37 CEST] <furq> https://i2.wp.com/japanesearcade.com/wp-content/uploads/2017/05/wani-wani-p… [15:40:47 CEST] <furq> except there's no hammer [15:41:34 CEST] <Mavrik> You just want to steal their ideas! [15:41:45 CEST] <furq> it's true [15:42:00 CEST] <Mavrik> How would we ever get a good video format without poor hungry corpos being paid for 100 years? :) [15:42:10 CEST] <ritsuka> I don't know what's worse, hevc patents or google making a new video format each year :| [15:42:55 CEST] <furq> if only i could have come up with such great ideas as "Facilitate easier transmission of video by making it smaller somehow" [15:43:56 CEST] <Mavrik> You know how long it took them to think of "how about we look at previous and next images, they might be similar?" ?! [15:44:17 CEST] <furq> ritsuka: do you mean two in nine years [15:44:37 CEST] <ritsuka> vp8, vp9, av1 [15:44:43 CEST] <furq> av1 isn't out yet [15:44:54 CEST] <furq> it'll presumably be three in 10 years [15:45:32 CEST] <Mavrik> There's also VP9 profile 2 [15:45:35 CEST] <Mavrik> Which is new [15:45:41 CEST] <furq> assuming you include vp8, which never really got any widespread deployment [15:45:52 CEST] <furq> i mean i know youtube uses it but does it get served to anyone but windows xp users nowadays [17:07:06 CEST] <alexpigment> hey guys. i'm testing h264_qsv on a 7700K Intel chip, but i'm getting intermittent failures [17:07:19 CEST] <alexpigment> "Error during encoding: device failed (-17)" [17:07:27 CEST] <alexpigment> i couldn't find anything on google about this [17:07:30 CEST] <alexpigment> any ideas? [17:10:24 CEST] <alexpigment> well, i did find this, which *may* be the same issue? https://trac.ffmpeg.org/ticket/5708 [17:10:33 CEST] <alexpigment> they fixed it by updating the graphics driver [17:10:37 CEST] <alexpigment> i'll try that report back [17:15:27 CEST] <kepstin> alexpigment: windows? yeah, sounds like a driver bug [17:16:21 CEST] <alexpigment> yep, windows [17:16:23 CEST] <alexpigment> updating now [17:16:29 CEST] <alexpigment> it was just weird that it was intermittent [17:20:15 CEST] <furq> most of the gfx driver issues i've ever had have been intermittent [17:41:24 CEST] <alexpigment> well, updating graphics didn't fix it, so I uninstalled and then reinstalled and that did the trick [17:41:36 CEST] <alexpigment> (or at least made it much more intermittent to the point where I didn't run into it again) [17:41:37 CEST] <alexpigment> weird [17:41:59 CEST] <alexpigment> i wish drivers weren't so quirky [18:09:13 CEST] <Kadigan> Hey... I'm getting lots of "Truncating likely oversided PPS (9469 > 4096)" on files from a particular camera (Canon XC10). I thought it was my outdated ffmpeg (sometime 2016) but I just built it from scratch and I'm getting the same issue. Anything I can do? [18:09:53 CEST] <Kadigan> (running on macOS 10.12.5) [18:10:27 CEST] <Kadigan> This happens roughly every 12 frames or so. [18:22:02 CEST] <h0par> hello [18:23:11 CEST] <h0par> how can I generate video from "infinite" number of images to stream? [18:24:34 CEST] <h0par> images are being generated on the fly, and there might be delay before next is generated [18:28:04 CEST] <jkqxz> Kadigan: Upload a sample? It's possible the PPS might actually be that size, just unlikely. [18:36:05 CEST] <DHE> h0par: a pipe? [18:38:08 CEST] <zack_s__> I want to concatenate two videos [18:38:30 CEST] <zack_s__> however I recieve following error: Impossible to open 'E:/Testing/ffmpeg-RemuxTest/bin/videos/Trimmed/"E:/Testing/ffmpeg-RemuxTest/bin/videos/Trimmed/video_1.mp4"' E:/Testing/ffmpeg-RemuxTest/bin/videos/Trimmed/concate-file.txt: Invalid argument [18:39:11 CEST] <zack_s__> this is my command: ffmpeg -f concat -safe 0 -i "E:/Testing/ffmpeg-RemuxTest/bin/videos/Trimmed/concate-file.txt" -c copy output [18:39:21 CEST] <zack_s__> this my concatenate file: https://pastebin.com/0a9WGxUB [18:43:52 CEST] <h0par> DHE: yes [18:44:01 CEST] <h0par> no [18:44:14 CEST] <h0par> not real pipe, but like pipe [18:45:10 CEST] <h0par> Can I tell ffmpeg to generate frames based on last image ? [18:59:32 CEST] <Kadigan> jkqxz: I was afraid of that. This isn't the only file from that camera that's throwing these... I also have some grief from Canon C100 cameras. Well, I'll ask the boss to provide me with sample files to upload. [19:17:20 CEST] <thebombzen> BtbN: I've found that hevc_nvenc outperforms x264's superfast etc. presets but not its slower presets [19:17:35 CEST] <BtbN> outperforms? [19:17:38 CEST] <thebombzen> that is in quality per bitrate [19:17:41 CEST] <BtbN> ah [19:17:50 CEST] <BtbN> Would have been surprised if x265 was faster [19:18:01 CEST] <thebombzen> x264, not x265 [19:18:24 CEST] <thebombzen> If you're encoding x264 with superfast anyway it's probably a realtime grab, and nvenc with a low qp works better [19:18:38 CEST] <thebombzen> but if you're using a slow preset x264 still takes the cake [19:19:04 CEST] <BtbN> The hevc encoder in nvenc is basically only using h264 features anyway [19:19:52 CEST] <furq> yeah nvenc over x264 is a no-brainer for realtime/intermediate stuff [19:20:37 CEST] <BtbN> hevc [20:13:00 CEST] <arpu> hello what is the best way to do a live video switch/mix with ffmpeg ? [20:13:16 CEST] <arpu> and the output rtmp stream should not be restarted [20:13:23 CEST] <arpu> i think i should use some fifo? [20:13:34 CEST] <arpu> anyone an idea? [20:25:27 CEST] <kerio> will -tune touhou help if i'm streaming a good game instead [20:28:45 CEST] <furq> what game [20:34:34 CEST] <kerio> idk [20:34:35 CEST] <kerio> dodonpachi [20:36:00 CEST] <furq> then probably [20:36:37 CEST] <furq> i was hoping to be able to disagree with your opinion of a good game but i don't care enough either way about dodonpachi [20:36:56 CEST] <furq> as long as you mean dodonpachi and not one of the new ones [20:37:16 CEST] <furq> anything newer than dai-ou-jou fucking sucks [20:47:01 CEST] <kerio> someone's salty about daifukkatsu [20:50:23 CEST] <furq> i knew it [20:50:32 CEST] <furq> i knew you were hiding something [20:50:32 CEST] <kerio> :> [20:50:51 CEST] <kerio> i'm not even good at bullet hells [20:50:52 CEST] <furq> it would be unthinkable for you to be enjoying something passable [20:51:03 CEST] <kerio> the only one i've ever done vaguely decently at is esp.ra.de [20:51:16 CEST] <furq> esp ra de is weird [20:51:17 CEST] <kerio> and u better not dis esp.ra.de. [20:51:21 CEST] <furq> it's fine [20:51:25 CEST] <kerio> yay :3 [20:51:32 CEST] <furq> it's no dangun feveron though [20:51:57 CEST] <furq> or uh [20:52:02 CEST] <kerio> guwange? [20:52:05 CEST] <furq> yeah [20:52:06 CEST] <furq> how did you know [20:52:13 CEST] <kerio> I'M IN YOUR HEAD [20:52:16 CEST] <furq> that's even weirder though [20:52:57 CEST] <furq> although it does at least have scoring that doesn't mean you have to spend 10 minutes milking every boss [20:52:57 CEST] <kerio> well you were talking about cave games [20:56:56 CEST] <furq> i could've been talking about any of cave's innumerable games from the 90s [20:57:02 CEST] <furq> i could've been talking about uo poko for all you know [21:00:58 CEST] <alexpigment> doing my monthly check-in about VCE [21:01:10 CEST] <alexpigment> has anyone heard of any movements on integrating AMD VCE into FFMPEG? [21:01:49 CEST] <furq> not on windows [21:02:07 CEST] <alexpigment> yeah, sorry [21:02:10 CEST] <alexpigment> i meant windows ;) [21:02:18 CEST] <alexpigment> ok, thanks furq [21:02:19 CEST] <furq> it's theoretically supported through vaapi but i don't think it actually works [21:25:32 CEST] <Abnix> quick question if I may, I have a substantial collection of files I wish to normalize the audio on, I have a script I found that uses ffmpeg and it works fine. Except that I have 16 cores to play with and despite passing '-threads 14' to ffmpeg, it is only running on one core...what am I doing wrong? [21:26:28 CEST] <DHE> audio filtering and audio encoding tends to be not very multi-threadable. [21:27:18 CEST] <Abnix> so 'lol no' ? [21:27:40 CEST] <klaxa> you could work on multiple files in parallel [21:27:53 CEST] <klaxa> i.e. just spawn more ffmpeg instances [21:27:57 CEST] <Abnix> righto [21:28:28 CEST] <Abnix> I had been thinking along that line, but wanted to make sure I wasn't missing something well-known [21:31:24 CEST] <ChocolateArmpits> audio processing is fast enough that multithreading is hardly necessary [21:32:30 CEST] <furq> yeah you'll need to use xargs or something [21:49:48 CEST] <c_14> gnu parallel [21:49:55 CEST] <c_14> doesn't xargs do it sequentially? [21:50:21 CEST] <furq> -P [21:51:19 CEST] <c_14> ah, so it can [21:51:39 CEST] <furq> parallel is slightly more featureful but also usually not installed [21:51:46 CEST] <furq> and also harder to use in my experience [23:00:18 CEST] <necklace> is it possible to split an audio file (ogg vorbis) on silence? I tried silencedetect and filter_complex but it didn't work.. Here's the command I tried https://pastebin.com/NTTKQ4hr [23:01:14 CEST] <furq> silencedetect doesn't split the file [23:01:31 CEST] <c_14> silencedetect just outputs to stderr, you have to parse that yourself [23:01:33 CEST] <furq> if you mean it's not printing messages then you probably need to adjust n [23:03:26 CEST] <necklace> Hm, so it's not possible to split an audio file on silence, then? It's printing a lot of messages but it didn't split where I wanted it to.. [23:03:46 CEST] <furq> it only prints messages [23:04:05 CEST] <furq> you need to split it yourself with the information it prints [23:05:51 CEST] <necklace> but could I make filter_complex and map do that for me? did you see the command? [23:06:03 CEST] <furq> no [23:07:16 CEST] <furq> to the first question [23:08:34 CEST] <c_14> the best you can do is silenceremove [23:10:44 CEST] <kepstin> necklace: in general, the ffmpeg filter system doesn't let you generate multiple outputs where the number isn't known in advance, so there's no real way to build a "split on silence" filter. [23:11:53 CEST] <furq> you could probably do it with a script and -f segment [23:12:53 CEST] <c_14> if you get the times and then segment_times probably [23:13:41 CEST] <c_14> that would still include the silence parts though, unless you remember which segments contain silence and drop those [23:13:55 CEST] <furq> well you get silence_start and silence_end [23:14:14 CEST] <c_14> but segment_times is only a comma separated list [23:14:21 CEST] <furq> oh right [23:14:34 CEST] <necklace> Hm, I'm not afraid to get dirty but I'm no ffmpeg pro; can you give me an example? [23:15:45 CEST] <damano> can ffmpeg/ffprobe used to parse an mp4 file to box level details ? [23:16:01 CEST] <c_14> you probably want l-smash's boxdumper [23:27:05 CEST] <furq> necklace: http://vpaste.net/VFWZ8 [23:27:19 CEST] <furq> you could presumably have awk spawn ffmpeg but i'll leave that as an exercise for the reader [23:28:01 CEST] <necklace> furq: heh, thanks. [23:31:24 CEST] <TMM> hi all [23:31:37 CEST] <TMM> whoops, wrong channel :) [00:00:00 CEST] --- Wed Jun 14 2017

1 0

ffmpeg-devel.log.20170612
by burek 13 Jun '17

13 Jun '17

[00:53:52 CEST] <michaelni> durandal_1707, the "Fix runtime error: left shift of negative value -123" for example is the litteral error from the sanitizer that the commit fixes [01:00:16 CEST] <jamrial> michaelni: i agree though that it would be better as part of the message but not as the subject [01:00:29 CEST] <jamrial> subject could be limited to "fix left shift of negative value" or "fix undefined behavior" [01:01:14 CEST] <michaelni> hmm, ok [01:05:05 CEST] <DHE> I've had the sanitizer point to unaligned access in the past, but since it's behind #ifdefs that do hardware capability checks it should be fine. [01:37:31 CEST] <cone-048> ffmpeg 03Michael Niedermayer 07master:07339a45a04e: avcodec/avpacket: Limit iterations in ff_packet_split_and_drop_side_data() [01:37:31 CEST] <cone-048> ffmpeg 03Michael Niedermayer 07master:f8593c2f492a: avcodec/libvpxdec: Check that display dimensions fit in the storage dimensions [04:02:36 CEST] <alevinsn> anyone here? [04:09:04 CEST] <Fenrirthviti> Usually works better if you just ask your question and be patient for someone to respond. [04:22:22 CEST] <alevinsn> ok, sure, the implementation of avio_close() appears to have a bug--just wanted to confirm my hypothesis with someone else with more experience [04:22:50 CEST] <alevinsn> the code frees s->opaque, and it also assumes that opaque is of type AVIOInternal * [04:23:14 CEST] <alevinsn> but, this is only the case when the AVIOContext is allocated the "standard" route [04:23:43 CEST] <alevinsn> if the user creates a custom AVIOContext using avio_alloc_context(), then opaque, if even passed in, [04:23:51 CEST] <alevinsn> is almost certainly not an AVIOInternal object [04:24:10 CEST] <alevinsn> and regardless, it wouldn't be memory that ought to be freed when avio_close() is called [04:24:45 CEST] <alevinsn> anyway, this should be easy to fix, and I'm going to work on a patch, but I wanted someone else's opinion with more experience in ffmpeg [04:25:41 CEST] <alevinsn> hmm [04:25:54 CEST] <alevinsn> according to the documentation, such a context is supposed to be freed with av_free().... [04:26:18 CEST] <alevinsn> so, its not a bug--its user error [04:26:33 CEST] <alevinsn> and avio_close() is only supposed to be used when avio_open() is used [04:35:14 CEST] <alevinsn> but, it seems in that case, it will leak AVIOContext::buffer if allocated [04:58:17 CEST] <factor> What is the deal in image utilities with image and uncached image utilities? Was wanting to do some uncached image version or reloadable on demand anyway. [05:36:18 CEST] <kevmark> ffmpeg supports inputs over SSH. TIL [11:49:02 CEST] <cone-189> ffmpeg 03Henrik Gramner 07master:aad1b6786e73: x86inc: Add some additional cpuflag relations [11:52:00 CEST] <J_Darnley> There we go. I pushed the 5th in that set now that x264 has added aesni in the same place as ours. [11:53:29 CEST] <nevcairiel> well we did have aesni before [11:53:44 CEST] <J_Darnley> Maybe "re-added" then [11:54:02 CEST] <nevcairiel> apparently all the numbers just got jumbled around [12:00:35 CEST] <durandal_1707> atomnuker: how you plan to detect silence parts in noised audio? [12:03:05 CEST] <atomnuker> just retune the ffopus psy transient detector, which would be simple because all you need to do would be to adjust the filter frequency down [12:03:38 CEST] <atomnuker> thinking more though its not a good idea [12:04:15 CEST] <atomnuker> it requires a large lookahead and I'd like the filter to not have a latency of more than say 30 or 40 msec [12:07:05 CEST] <atomnuker> I'll take the abs of the coefficients and compare them to both the original noise signature and a pink noise distribution with the same energy [12:07:39 CEST] <atomnuker> then a threshold will decide whether to use this as the new signature of stay with the old one [12:08:27 CEST] <atomnuker> response time isn't important so I'll only accept a new one if the last 10 or so frames have been above the threshold [13:31:17 CEST] <J_Darnley> Here's an interesting tidbit: the first pmaddwd after the transpose in simple idct is 3x hotter than any other instruction. [13:39:05 CEST] <iive> J_Darnley: is the code in patch 2/5 [13:40:19 CEST] <J_Darnley> I think so [13:40:25 CEST] <iive> the op been hot usually means that the cpu blocks there, until data dependency is solved [13:41:38 CEST] <J_Darnley> I guess it might be waiting for the transpose to finish. [13:44:38 CEST] <iive> could you give me a direct link to the code in web git or something... [13:49:17 CEST] <J_Darnley> If you really want to look, I think it is this line: https://gitlab.com/J_Darnley/ffmpeg/blob/mpeg2_asm2/libavcodec/x86/simple_i… [14:33:58 CEST] <iive> still looking at it, but while browsing up/down i spotten a sequence of min/max ops [14:35:30 CEST] <iive> it might be faster if you do the min/max in pairs, e.g. m0,m1 ; m2;m3; then m01,m23 ... you get the idea [14:39:58 CEST] <J_Darnley> I think so [15:02:59 CEST] <iive> gah... you are doing a saturation there, not looking for min/max there is no data dependency. ignore what i said. [15:11:01 CEST] <iive> i can't see much room to shuffling instructions around to fill up the latency... [15:15:29 CEST] <J_Darnley> Thank you for looking [15:19:21 CEST] <iive> and punpck usually have very short letencies, 1 or 2. the reason might be elsewhere [15:20:15 CEST] <iive> do you have a free register? try to load the memory operand in it and see where the hot spot would move [15:21:33 CEST] <iive> have in mind that memory operands always add one more micro-op for loading the constant in temp register. [16:13:19 CEST] <Gramner> J_Darnley: is the pmaddwd with a memory arg? if so it's probably cache misses [16:15:04 CEST] <J_Darnley> Yes, an RO constant [16:16:02 CEST] <iive> well, how many times should constant be used in order to remain in L0 cache? [16:16:34 CEST] <Gramner> profiling stuff can be a bit misleading. it can appear that a lot of cycles is spent in some function (or instruction) but you're actually just waiting on memory so making the code itself faster may not improve performance [16:17:06 CEST] <Gramner> if the functions is truly executed a lot it should probably end up in L1 by itself [16:18:33 CEST] <Gramner> optimizing cache usage is probably a whole subsection of comp.sci. by itself [16:20:46 CEST] <Gramner> I like that avx-512 added broadcasts from GPRs, so you can load an immediate to a GPR and broadcast it from there instead of loading constants from rodata when you expect cache misses [16:21:23 CEST] <nevcairiel> thats pretty neat [16:23:15 CEST] <J_Darnley> I wasn't expecting people to go looking for a solution. I was only pointing out something I found curious. [17:09:50 CEST] <wm4> I wonder if anyone RE'd yet how to use HEVC from videotoolbox [17:10:49 CEST] <iive> J_Darnley: what are you using for profiling? [17:11:00 CEST] <durandal_1707> wm4: RE'd ? isnt that thing documented? [17:11:34 CEST] <wm4> durandal_1707: no, apple is very bad at documentation, it's a shit show [17:15:57 CEST] <kierank> wm4: is it a software encoder? [17:16:03 CEST] <kierank> would be interesting to see strings from it [17:16:09 CEST] <kierank> i would guess licensed from ittiam [17:16:11 CEST] <kierank> or ateme [17:16:32 CEST] <wm4> I meant decoder... but surely they'll have an encoder too [17:38:04 CEST] <J_Darnley> iive: perf [17:38:45 CEST] <J_Darnley> perf record ./ffmpeg_g -i FILE -an -f null - [18:10:35 CEST] <cone-069> ffmpeg 03Paul B Mahol 07master:d4d1fc823f99: avfilter: add native headphone spatialization filter [18:10:36 CEST] <cone-069> ffmpeg 03Paul B Mahol 07master:1a30bf60be92: tools: add sofa2wavs [18:49:32 CEST] <cone-069> ffmpeg 03Ilia Valiakhmetov 07master:81fc617c1257: avcodec/vp9: ipred_dr_16x16_16 avx2 implementation [19:01:38 CEST] <ubitux> jamrial: your aacpsdsp hybrid test passes on arm btw [19:02:59 CEST] <jamrial> ubitux: cool [19:04:28 CEST] <jamrial> ubitux: can you test this one as well? https://pastebin.com/hT5dZiKg [19:04:34 CEST] <jamrial> i assume it will fail for most i values since the arm function seems optimized to the values aacdec explicitly uses, but just want to be sure [19:05:01 CEST] <ubitux> isn't it the one you made me test? [19:05:12 CEST] <ubitux> or did you change something? [19:05:14 CEST] <jamrial> no, the one i made you test tried i values 3 and 5 [19:05:27 CEST] <jamrial> this one tests 0 to 63 [19:05:43 CEST] <ubitux> ah, ok [19:07:14 CEST] <jamrial> i'm fairly sure it will fail, at least from reading the arm code, but just want to be sure [19:07:47 CEST] <jamrial> i don't think adapting the arm function to work for all i values is worth it. aacdec is unlikely to be changed [19:10:35 CEST] <ubitux> bus error [19:13:36 CEST] <jamrial> alright, just squash the first one then [20:12:50 CEST] <BBB> J_Darnley: is michaels mpeg problem in patch 3 related to not using patch 6? [20:13:01 CEST] <BBB> J_Darnley: i.e. do you need to invert patch 3 and 6 to make sure stuff never breaks in commit order? [20:13:09 CEST] <BBB> or just put 6 before 3/4/5 [21:03:53 CEST] <J_Darnley> I'm not sure yet [21:05:50 CEST] <atomnuker> jamrial: why the sudden interest in making aacps as fast as possible? it was pretty quick before IIRC [21:06:29 CEST] <atomnuker> or is this the last easy remaining audio asm left :)? [21:06:45 CEST] <jamrial> atomnuker: none in particular. i general just work on what i find interesting or fun [21:07:23 CEST] <atomnuker> yeah, good point, opus assembly isn't fun at all [21:08:07 CEST] <atomnuker> you write it, it works on scalar but the extra code to handle non-multiples of 2 makes you slower than c :( [21:17:33 CEST] <BBB> michaelni: does 6/6 fix the issue youre seeing in 3/6 from j_darnleys patch set? [21:17:47 CEST] <BBB> michaelni: (Im wondering if the patch ordering is just wrong) [21:21:54 CEST] <BBB> J_Darnley: the action in 2/6, its a little confusing, but it just is invoked for 10-bit right? [21:22:00 CEST] <BBB> J_Darnley: i.e. for 8bit action is always absent? [21:22:48 CEST] <BBB> J_Darnley: and can you fix the indenting of simple_idct8_add? within %if cpuflag(sse4) - %endif [21:22:50 CEST] <J_Darnley> No. For the IDCT only it is used as "store" [21:23:03 CEST] <BBB> oh right of course [21:23:04 CEST] <BBB> duh [21:23:11 CEST] <BBB> but for 8bit add/put its nothing, right? [21:23:15 CEST] <J_Darnley> Yes [21:23:17 CEST] <BBB> ok cool [21:23:23 CEST] <J_Darnley> "leave in registers" [21:23:32 CEST] <BBB> right, cool [21:23:35 CEST] <BBB> if this works, passes fate and doesnt break mpeg, its good with me [21:23:38 CEST] <BBB> lets wait for michael also [21:23:53 CEST] <BBB> if you can reproduce the breakage he sees with 3/6 but its gonewith 6/6, Id just re-order the patches [22:12:58 CEST] <J_Darnley> BBB michaelni: I can repoduce the problem with patches 1-3 [22:13:11 CEST] <BBB> cool [22:13:13 CEST] <BBB> does 6 fix it? [22:13:20 CEST] <michaelni> not fully [22:13:26 CEST] <michaelni> sorry for the late reply [22:13:27 CEST] <J_Darnley> Just trying [22:13:35 CEST] <michaelni> make -j12 ffmpeg && ./ffmpeg -i fate-suite/lena.pnm -y test.jpg && xview test.jpg [22:13:41 CEST] <michaelni> shows artifacts with all 6 [22:13:50 CEST] <michaelni> matrix seems ok i think wit 6 [22:13:59 CEST] <J_Darnley> damn [22:15:09 CEST] <cone-069> ffmpeg 03Paul B Mahol 07master:6e09e1264116: tools/sofa2wavs: add license header [22:23:20 CEST] <J_Darnley> Fuck I hate the autocomplete for make that system has! I don't want to make a target I want to make a file! [00:00:00 CEST] --- Tue Jun 13 2017

1 0

ffmpeg.log.20170612
by burek 13 Jun '17

13 Jun '17

[05:51:26 CEST] <thomedy> hello [05:51:34 CEST] <thomedy> if anyone is here [05:51:43 CEST] <thomedy> im having a hard time transcoding to raw [05:51:49 CEST] <thomedy> video [05:52:16 CEST] <guest199203> Hello. What is the most efficient way to loop animated gif to achieve known duration and then convert it to video? [06:35:32 CEST] <grublet> thomedy: can you paste your commandline? [06:35:42 CEST] <grublet> have you tried using -c:v rawvideo? [06:36:12 CEST] <thomedy> so are you thinking ffmpeg -i test.mp4 -c:v rawvideo test.raw [06:36:25 CEST] <thomedy> i have done soooooo many command lines [06:36:32 CEST] <thomedy> and read [06:36:34 CEST] <thomedy> sooooo much [06:36:35 CEST] <grublet> try doing test.avi or test.mkv [06:36:49 CEST] <grublet> i dont know about .raw, never used that extension [06:36:52 CEST] <thomedy> so the last would be test.avi [06:37:01 CEST] <thomedy> im reaad .avi might be right [06:37:10 CEST] <grublet> yes try ffmpeg -i test.mp4 -c:v rawvideo test.avi [06:37:13 CEST] <grublet> or .mkv or something [06:37:19 CEST] <grublet> i think .avi would be most likely to work [06:37:29 CEST] <grublet> ill test it myself on something [06:37:42 CEST] <thomedy> worth a shot [06:38:32 CEST] <grublet> well, i took an MP4 i had and used that commandline, it decodes for me in FFPlay [06:39:01 CEST] <thomedy> thats perfect [06:39:06 CEST] <grublet> works correctly in mpchc and vlc as well [06:39:09 CEST] <grublet> thomedy: did it work for you? [06:39:13 CEST] <thomedy> im building ana eventual cgi [06:39:23 CEST] <thomedy> its transcoding so i havent tested [06:39:27 CEST] <thomedy> but it looks good [06:39:43 CEST] <grublet> you could do something like "ffmpeg -i test.mp4 -t 5 -c:v rawvideo test.avi" [06:39:49 CEST] <grublet> the -t 5 will tell it to only do 5 seconds [06:39:57 CEST] <grublet> so you dont spend as time making a sample to see if it works [06:40:09 CEST] <thomedy> cool [06:40:13 CEST] <grublet> also, whats an eventual cgi? [06:40:29 CEST] <thomedy> its a c++ application delivered over the web [06:40:36 CEST] <thomedy> but im transcoding with ffmpeg [06:41:12 CEST] <thomedy> okay it looks good [06:41:49 CEST] <thomedy> now for my software to process [06:41:50 CEST] <thomedy> lets see [06:41:58 CEST] <thomedy> thanks [06:42:07 CEST] <grublet> np hope it works out [06:42:20 CEST] <grublet> as far as a frontent or web app or w/e, i dont know anything about that stuff but im sure someone else might [06:42:31 CEST] <thomedy> ohp im good there... [06:43:02 CEST] <grublet> alright cool [06:43:13 CEST] <grublet> if it gives anymore problems i may be able to help figure something else out [06:52:03 CEST] <thomedy> okay... that wasnt quite right... i know tht rw isn't quite the same thing s uncompressed [06:53:20 CEST] <thomedy> i need to get completely uncompressed and raw....when i encrypt it and break it apart it doesn't play [06:53:31 CEST] <thomedy> sorry i decrypt it first [06:54:41 CEST] <thomedy> interesting when i run ffmpeg -i test.avi it says its in raw [07:11:43 CEST] <grublet> thomedy: you might want to try "ffmpeg -i test.mp4 -pix_fmt yuv420p -c:v rawvideo test.avi" [07:12:10 CEST] <thomedy> i ws just reading the man page that -f frces output or input format [07:12:39 CEST] <grublet> not sure, im a bit rusty and most of my experience is with older versions of ffmpeg [07:12:49 CEST] <grublet> you shouldnt need -f right now [07:12:55 CEST] <thomedy> okay so let me tell you what im doing [07:13:02 CEST] <thomedy> cuz im missing something... [07:13:14 CEST] <thomedy> im encrypting and decrypting later [07:13:29 CEST] <grublet> idk what you mean by that [07:13:34 CEST] <grublet> decrypting a dvd? [07:13:35 CEST] <thomedy> if im only looking at 30 s - 35 s [07:13:45 CEST] <thomedy> just a video file [07:14:00 CEST] <thomedy> but im only decrypting 30 s - 35 s [07:14:06 CEST] <grublet> i think you mean decoding? [07:14:13 CEST] <thomedy> nope decrypting [07:14:20 CEST] <grublet> decrypt/encrypt is a reference to copy protection [07:14:25 CEST] <grublet> what are you decrypting from? [07:14:25 CEST] <thomedy> yes i agree [07:14:31 CEST] <thomedy> my own algorithm [07:14:36 CEST] <grublet> i mean [07:14:41 CEST] <grublet> where is the source coming from [07:14:55 CEST] <thomedy> right now im testing so im decrypting asmal mp4 [07:15:11 CEST] <grublet> what type of encryption is being used [07:15:14 CEST] <thomedy> but as far as i can tell i need uncompressed footage [07:15:55 CEST] <thomedy> because if you encrypt lets say mpeg... it has its own problems i experienced this with audio but i have that under control now [07:16:05 CEST] <grublet> what form of encryption [07:16:14 CEST] <thomedy> its my own algorithm [07:16:21 CEST] <grublet> i still think you're meaning to say encode/decode [07:16:29 CEST] <grublet> if not, then i can't help you at this point [07:16:40 CEST] <grublet> im clueless on cryptography [07:16:53 CEST] <thomedy> let me ask this because i just need to know is avi raw uncompressed vide [07:17:02 CEST] <thomedy> becuase thats what i had to do with audio [07:17:07 CEST] <thomedy> i had to make it raw first [07:17:17 CEST] <thomedy> so that the encryption would not break the codec [07:17:22 CEST] <grublet> raw should be uncompressed, yes [07:17:26 CEST] <thomedy> hmmm.... [07:17:32 CEST] <thomedy> os im missing something [07:17:35 CEST] <thomedy> okay [07:17:37 CEST] <grublet> still dont see how enceryption would affect that [07:17:58 CEST] <thomedy> well i dont have the proper file extension anymore does tha tmaatter [07:18:02 CEST] <thomedy> it no longer is .avi [07:18:05 CEST] <thomedy> its .myown [07:18:07 CEST] <grublet> on linux? probably not [07:18:09 CEST] <grublet> on windows? yea [07:18:11 CEST] <thomedy> linux [07:18:21 CEST] <grublet> afaik linux doesnt care about the extension that much [07:18:23 CEST] <thomedy> so thts not it then cuz im running ubuntu [07:18:52 CEST] <thomedy> let me try this one sec [07:21:16 CEST] <thomedy> https://pastebin.com/AiL3x2cT [07:21:29 CEST] <thomedy> its the errors im getting from ffplay test.avi.myown [07:23:14 CEST] <thomedy> im going to have to read the whole man page like i did sox [07:23:45 CEST] <furq> what command are you running to get that file [07:24:11 CEST] <thomedy> the errors.. ? [07:24:44 CEST] <thomedy> im trying to play a .avi with a custom file extension [07:24:54 CEST] <thomedy> there should be no header right with raw [07:24:59 CEST] <thomedy> so its just raw binary dataa [07:25:00 CEST] <thomedy> right? [08:06:57 CEST] <c3r1c3-Win> So my audio is already uncompressed, sitting in 2 channels (or 1), and at a set sample rate. Do I still need to call AVCodecContext (or similar) before getting the audio into the abuffer? [08:45:22 CEST] <Fyr> guys, when playing a video with a player, I press at a position, but a player starts from the position 1-5 s earlier than I pressed. [08:45:26 CEST] <Fyr> why does it happen? [08:46:56 CEST] <Fyr> I want to play somwhere between 36 and 42 s, however, it starts playing from either 36 s or 42 s, not from the place I chose. [08:47:10 CEST] <furq> that's where the keyframes are [08:48:00 CEST] <Fyr> furq, the big file is seeked normally, while the small file (cut from the big file) has this thing. [08:48:12 CEST] <Fyr> why does the big file lack of it? [10:06:02 CEST] <hardening> hi guys, I have question about using the VAAPI decoder programmatically from C code. I've read a ML discussion here =>http://www.ffmpeg-archive.org/VAAPI-Decoding-Encoding-with-C-code-td4678436… but let's say it's not crystal clear ;) [10:08:19 CEST] <hardening> I've tried to mimic what is done in ffmpeg_vaapi.c and adapt it to the instruction given in the mailing list thread, but so far it doesn't work [10:31:22 CEST] <Fyr> guys, is there a way to calculate PSNR and SSIM at one command? [10:31:38 CEST] <Fyr> (when comparing video files) [10:31:54 CEST] <Fyr> I know how to calculate PSNR when comparing the videos. [10:32:05 CEST] <Fyr> and SSIM, obviously. [10:32:18 CEST] <Fyr> though, I don't know how to calculate them at once. [10:38:33 CEST] <Fyr> funny thing that it's written in the documentation. [10:40:05 CEST] <hardening> so I'd be interested if someone has an example program to use the VAAPI decoder... [11:43:17 CEST] <Yos> Hi there compiling latest binary i noticed that Rel 3.3.2 Still has support for libschroedinger while the snapshot seem to have dropped it.. why is that? [11:43:58 CEST] <JEEB> it was dropped because the internal stuff supports the format well enough and libschroedinger was found to be unmaintained and having security issues [11:44:05 CEST] <JEEB> a case of "this dependency is no longer useful" [11:44:59 CEST] <Yos> i see, thanks for your explanation [12:30:54 CEST] <jameshowe> Does zeranoe hang around here? [12:58:50 CEST] <vaartis> Heya there~ What's up with ffmpeg's ssl cert? Firefox/wget say that connection is insecure [13:00:41 CEST] <vaartis> Well.. nevermind, seems to be fixed now.. [14:54:15 CEST] <asd> I'm running two instances of ffmpeg (ffmpeg version 3.2.4-1build2 Copyright (c) 2000-2017 the FFmpeg developers built with gcc 6.3.0 (Ubuntu 6.3.0-8ubuntu1) 20170221) at the same time with the segmenter. Segments are only created for one of the instances and and the other creates one large file. Not sure what to check. [14:54:40 CEST] <asd> I'm running through crontab... [14:54:43 CEST] <asd> 0 6 * * * root timeout 5h ffmpeg -i "http://192.168.1.230/videostream.cgi?user=admin&pwd=blah&resolution=32&rate…" -map 0 -c copy -f segment -strftime 1 -segment_time 1200 -reset_timestamps 1 -segment_format mp4 "/opt/dev/00233s/734/hhsd/capture-\%Y-\%m-\%d-\%H-\%M-\%S.mp4" 0 6 * * * root timeout 5h ffmpeg -i "http://192.168.1.8/videostream.cgi?user=admin&pwd=blah&resolution=32&rate=0" -map 0 -c copy -f segment -strft [14:55:04 CEST] <asd> sorry that didn't paste in good [14:55:29 CEST] <asd> here's the first: [14:55:31 CEST] <asd> 0 6 * * * root timeout 5h ffmpeg -i "http://192.168.1.230/videostream.cgi?user=admin&pwd=blah&resolution=32&rate…" -map 0 -c copy -f segment -strftime 1 -segment_time 1200 -reset_timestamps 1 -segment_format mp4 "/opt/dev/00233s/734/hhsd/capture-\%Y-\%m-\%d-\%H-\%M-\%S.mp4" [14:55:37 CEST] <asd> here's the second [14:55:45 CEST] <asd> 0 6 * * * root timeout 5h ffmpeg -i "http://192.168.1.8/videostream.cgi?user=admin&pwd=blah&resolution=32&rate=0" -map 0 -c copy -f segment -strftime 1 -segment_time 1200 -reset_timestamps 1 -segment_format mp4 "/opt/dev/00233s/734/hhsd/lcapture-\%Y-\%m-\%d-\%H-\%M-\%S.mp4" [14:56:40 CEST] <asd> Should the segmenter work with each instance? [17:37:33 CEST] <dreadkopp> hey guys. i am giving x11grab a try using h264_nvenc encoder. CPUs: 2xE5620, GPU : 750ti. i am casting to VLC using ffserver. GPU usage is ~50% ... however CPU usage is near top for all cores ? thought using h264_nvenc encoding would be done by the gpu? [17:43:27 CEST] <kepstin> dreadkopp: encoding should be done with gpu yeah, I'd expect the cpu usage to be a lot lower. Keep in mind that there's still some cpu overhead in the x11grab code, and converting from rgb to yuv, for example. [17:43:36 CEST] <kepstin> also why are you using ffserver? [17:44:00 CEST] <dreadkopp> kepstin_: to cast to vlc (for now) in real time.. [17:44:01 CEST] <kepstin> check which process is actually using the cpu, it might be that your ffserver config is doing an extra transcode or something... [17:44:27 CEST] <dreadkopp> in ffserver conf i set encoding to h264_nvenc [17:44:40 CEST] <kepstin> I wouldn't expect that to work in ffserver, tbh. [17:44:47 CEST] <kepstin> but... ? who knows [17:45:05 CEST] <c_14> you sure the ffmpeg isn't spawning an h264 encoder as well? [17:45:26 CEST] <dreadkopp> so no enconding in ffserver but in ffmpeg, righty? sorry, i am pretty new to this [17:45:39 CEST] <kepstin> dreadkopp: for this config, you'd want the ffmpeg doing the screencap to encode with nvenc, then ffserver should be doing codec copy [17:46:09 CEST] <dreadkopp> kepstin_: okay, righty.. bummer though [17:46:30 CEST] <kepstin> although I've never used ffserver, so I have no idea how exactly that would be set up [17:46:45 CEST] <bencoh> hasn't ffserver been dropped yet? [17:46:51 CEST] <kepstin> you'd probably be better off using ffmpeg with udp sender or something to get video to vlc [17:46:52 CEST] <furq> sadly not [17:47:07 CEST] <bencoh> "impressive" [17:47:22 CEST] <dreadkopp> hoped i could send multiple streams to ffserver from VM without dedicated GPU. ffserver encodes to h264 using GPU and makes streams available [17:47:24 CEST] <furq> apparently someone ported it to the new APIs at the last minute to prevent it from being droppe [17:47:27 CEST] <furq> d [17:47:50 CEST] <bencoh> ohwell ... I guess it means it's still useful to someone at least :) [17:47:55 CEST] <kepstin> dreadkopp: well, how is the video encoded in the stream going from ffmpeg to ffserver? :) [17:48:01 CEST] <furq> are you sure [17:48:13 CEST] <furq> i figured it meant that someone didn't want to not be maintaining something any more [17:48:22 CEST] <dreadkopp> kepstin: not at all. sending rawvideo (as far as i get it:P ) [17:49:23 CEST] <kepstin> dreadkopp: well, start by looking in a top program and figuring out exactly which process is responsible for the cpu usage [17:49:51 CEST] <kepstin> is it ffserver? the sending ffmpeg? overhead from the network interface on the vm sending ridiculous amounts of raw data? [17:51:16 CEST] <dreadkopp> my ffserverconfig and ffmpeg startparameters: https://hastebin.com/ejarocomif.apache @kepstin it's multiple ffmpeg processes eating about ~1200%/1600% CPU [17:51:38 CEST] <dreadkopp> darn.. wrong [17:51:57 CEST] <kepstin> dreadkopp: well, those aren't sending raw video to ffserver, the commands in that file are encoding with x264 in the VM [17:52:00 CEST] <dreadkopp> https://hastebin.com/luyehulumo.apache [17:52:03 CEST] <kepstin> so yeah, that's all your cpu right there [17:52:20 CEST] <furq> asf? [17:52:23 CEST] <dreadkopp> kepstin: sorry, wrong config... tried something and copied wrong line [17:52:46 CEST] <kepstin> dreadkopp: well, look at the logs of the ffmpeg command and check with encoder it's actually using [17:53:20 CEST] <furq> i guess i'd better get the glowsticks and head down to a rave, because it is the 90s [17:53:50 CEST] <furq> hopefully this also means the pills actually have some mdma in them now [17:55:31 CEST] <kepstin> furq: I'm all set for the 90's, I just built myself a new desktop pc: https://www.kepstin.ca/dump/DSC_4562.JPG ;) [17:55:41 CEST] <dreadkopp> hmm... if i get this correct ffmpeg allready sends a h264 encoded video (encoded by CPU) while ffserver reconverts that stream using GPU ? https://hastebin.com/soceboleso.pas [17:55:50 CEST] <dreadkopp> BEAST [17:55:55 CEST] <furq> lol [17:56:13 CEST] <furq> i assumed that was an actual 90s pc you'd built to play carmageddon in its true glide form [17:56:17 CEST] <furq> but then i noticed the zen sticker [17:56:35 CEST] <dreadkopp> how did you make the ryzen run Win98? [17:56:42 CEST] <furq> 95 [17:56:44 CEST] <bencoh> zyren7/win95? huhu :p [17:56:45 CEST] <nido> do i read that right? "IBM(tm) K6(tm) 2<b>5</b>6mhz mmx(tm)-enhanced processor" [17:56:57 CEST] <kepstin> nido: 266 [17:57:09 CEST] <furq> that sure looks like a 5 [17:57:21 CEST] <kepstin> dreadkopp: I don't, but I'm tempted to find a way to boot it into a win95 VM somehow :/ [17:57:35 CEST] <bencoh> win95 vm should be "easy" [17:57:53 CEST] <nido> kepstin: iirc VirtualBox can vm without needing procesor features [17:58:11 CEST] <nido> not saying it will be a _useful_ win95 vm on the system you have, but it will be possible... [17:58:11 CEST] <furq> how did you find a ryzen board with an agp slot for a voodoo2 [17:58:30 CEST] <kepstin> furq: I have a PCI voodoo 2, and using an MSI board with PCI slots ;) [17:58:34 CEST] <furq> nice [17:58:47 CEST] <furq> i actually know someone who has a full 1998 pc for playing 90s games [17:58:47 CEST] <kepstin> (i don't actually have it installed, but that would be hilarious) [17:58:52 CEST] <furq> i don't think he ever uses it any more though [17:59:05 CEST] <furq> but all he talked about for like six months was 3dfx graphics cards on ebay [17:59:10 CEST] <furq> i think he has like four different voodoo5s [17:59:14 CEST] <kepstin> the voodoo 2 didn't do 2d, it was a 3d card only; the voodoo 3 was the first with agp interface [17:59:18 CEST] <bencoh> furq: I no longer do that, but sometimes I wish I did [17:59:30 CEST] <furq> bollocks to that [17:59:32 CEST] <bencoh> (well, not that I really have/take time to play) [17:59:34 CEST] <furq> if i want to play 90s games i've got mame [17:59:41 CEST] <nido> i had a voodoo3 for nintendo64 emulation [17:59:46 CEST] <bencoh> furq: haha, that too. but then I miss my CRT [17:59:50 CEST] <nido> ultrahle was the bomb [18:00:05 CEST] <JEEB> there was a mixed 2D+3D card from 3dfx after voodoo1 I think. banshee or so? [18:00:08 CEST] <thebombzen> what was I now? [18:00:10 CEST] <thebombzen> ultrahle? [18:00:38 CEST] <furq> i think my mate might have had a voodoo 5 6000 [18:00:50 CEST] <furq> there were a few engineering samples on ebay for ridiculous money [18:00:55 CEST] <furq> i forget if he ended up actually buying one [18:01:09 CEST] <thebombzen> why do you need a fancy cpu to do n64 emulation? [18:01:17 CEST] <thebombzen> do no emulators exist to translate it to x86? [18:01:22 CEST] <nido> nintendo64 emulator; one of the first emulators to do 'high level' emulation, e.g. translating from n64 video operations to glide(/directx/opengl) video operations rather then emulating the video chip itself [18:02:01 CEST] <dreadkopp> okay... h264 encoding was never done by the GPU as it seems.... the ~50% load are simply playing the video i used for a test.... [18:02:22 CEST] <furq> dreadkopp: i'd consider just ditching ffserver [18:02:25 CEST] <furq> everyone else has [18:02:39 CEST] <dreadkopp> furq: haha :) [18:02:40 CEST] <furq> if you need to serve multiple clients then use nginx-rtmp or something [18:02:57 CEST] <bencoh> :) [18:02:58 CEST] <nido> thebombzen: you "needed" a gpu because emulation of the n64 video adapter was not fast enough in software; it was up to about 10x slower then real time [18:03:34 CEST] <thebombzen> is this just because no good emulators exist? or because it was actually just not easy [18:04:15 CEST] <bencoh> I guess it was actually not that easy back in the 9x [18:04:24 CEST] <thebombzen> because Dolphin-Emu is able to do GameCube and Wii emulation in realtime [18:04:26 CEST] <dreadkopp> is my approach even possible at all? VM->rawvideo ->Server_with_GPU -> encode to h264 -> Client ? [18:04:33 CEST] <bencoh> CPUs weren't that fast then ;) [18:04:45 CEST] <thebombzen> ah. so nowadays it's not necessary but back then it was [18:04:48 CEST] <thebombzen> that makes more sense now' [18:04:48 CEST] <furq> thebombzen: remember all those times you admitted you should have read the conversation in more detail [18:05:01 CEST] <thebombzen> furq: I'm only in this conversation because someone said "the bomb" [18:05:02 CEST] <kepstin> dreadkopp: I don't see why not [18:05:07 CEST] <bencoh> haha [18:05:29 CEST] <dreadkopp> kepstin: okay :) [18:05:34 CEST] <kepstin> dreadkopp: but you might want to look into having the VM system itself handle the fb capture rather than doing inside the guest os [18:05:35 CEST] <furq> do you get highlighted by "the bomb" [18:05:41 CEST] <furq> that's pretty bad [18:05:41 CEST] <thebombzen> Yes [18:05:44 CEST] <kepstin> dunno if that's possible [18:05:45 CEST] <bencoh> dreadkopp: apart from the rawvideo transfer which looks like a waste [18:06:04 CEST] <thebombzen> furq: yea because people often try to ping me with that [18:06:13 CEST] <furq> those people aren't your friends [18:06:17 CEST] <dreadkopp> bencoh: other suggestions? bandwith doesn't matter, quality and low CPU impact does [18:06:18 CEST] <nido> thebombzen: apologies for bringing you in then [18:06:23 CEST] <thebombzen> lol [18:06:35 CEST] <furq> you should apologise to the rest of us as well [18:07:01 CEST] <nido> the rest of the united states: apologies to you as well [18:07:02 CEST] <nido> happy furq ? [18:07:11 CEST] <furq> that doesn't include me or probably most of the people in here [18:07:26 CEST] <bencoh> dreadkopp: I suppose you don't want to passthrough your gpu to guest so not really, no [18:07:31 CEST] <thebombzen> I apologize to the rest of you for existing, I'm sorry my presence is making it dificult for you to focus [18:07:38 CEST] <furq> that'll do [18:07:52 CEST] <dreadkopp> bencoh: not enough PCIe Slots / GPUs haha [18:07:56 CEST] <bencoh> :) [18:08:05 CEST] <thebombzen> perhaps if I weren't here then you could stop thinking of about my utter supriority, but alas, this is not the case, for I am the best [18:08:22 CEST] <bencoh> I fail to see why you want to do the grabbing from the VM though, as kep.stin mentioned [18:08:23 CEST] <furq> i would say "stop stealing my gimmick" but a big part of my gimmick is good spelling [18:08:49 CEST] <thebombzen> You should have misspelled "spelling" cause then you would have gotten bonus points [18:09:00 CEST] <furq> from whom [18:09:09 CEST] <dreadkopp> bencoh: well that was my first approach... really didn't know how to dump it directly from the vGPU or anything [18:09:14 CEST] <thebombzen> from all the people who say "bonus points for irony" [18:09:32 CEST] <furq> i don't recognise their authority to issue points [18:09:38 CEST] <nido> that's if you care about upboating [19:31:16 CEST] <Substring> Hi [19:31:49 CEST] <Substring> I was wondering how to play youtube videos with ffplay, is it possible without any 3rd party tool ? [19:35:04 CEST] <durandal_1707> Substring: no, need another tool to fetch url [19:35:55 CEST] <Substring> durandal_1707, ok, that's what I guessed, so i already tried with youtube-dl and piping with ffplay, works ok, but i can't have subtitles [19:36:32 CEST] <Substring> i guess the subtitles should be embedded in the stream ? [19:39:40 CEST] <Substring> i can't find how to specify a subtitles file [19:41:51 CEST] <furq> --embed-subs [19:46:18 CEST] <Substring> furq, then i must be missing some other parameters, ffplay doesn't list the subtitles stream [20:55:55 CEST] <Substring> --embed-subs is a post processing option, so it can't work when i pipe youtube-dl and ffmpeg [21:14:32 CEST] <Substring> using ffmpeg, playing a 720p video on a 800x480 screen, i can't resize it using -s 800x480. What wrong have I done ? [21:49:45 CEST] <kazuma_> load a scaler Substring [21:50:18 CEST] <kazuma_> ffmpeg -i input -sws_flags spline -s 800x480 output [21:50:23 CEST] <kazuma_> for example using spline [21:59:36 CEST] <Tatsh> my DVDAs came in [21:59:38 CEST] <Tatsh> Stream #0:0: Audio: mlp, 88200 Hz, 5.1, s32 (24 bit) [21:59:41 CEST] <Tatsh> :) [22:00:08 CEST] <furq> i've never heard of that audio codec and i don't want to google it [22:00:17 CEST] <Substring> kazuma_, thank you i'm going to try [22:00:18 CEST] <Tatsh> it's the format chosen for DVDA [22:00:25 CEST] <Tatsh> it's one of the choices anyway [22:00:32 CEST] <Tatsh> it's lossless pcm [22:00:33 CEST] <kepstin> "meridian linear packing" or something like that iirc? [22:00:36 CEST] <kepstin> probably spelled it wrong [22:00:37 CEST] <kerio> furq: my little pony [22:00:49 CEST] <Tatsh> on SACD it's DSD iirc [22:00:55 CEST] <kepstin> ah "Meridian Lossless Packing" [22:00:57 CEST] <Tatsh> i have a few SACDs coming, and i can decrypt those with my PS3 [22:01:02 CEST] <furq> kerio: thank you for explaining it to me. i hadn't realised [22:01:03 CEST] <Tatsh> :) [22:01:05 CEST] <bencc> what flags do I need to create fragmented mp4 for hls/dash? [22:01:09 CEST] <Tatsh> high fidelity music rules [22:01:19 CEST] <Tatsh> but unfortunately not all albums are equal [22:01:19 CEST] <furq> counterpoint: no it doesn't [22:01:33 CEST] <bencc> -movflags frag_keyframe? and or empty_moov? and or empty_moov? [22:01:39 CEST] <furq> both [22:01:53 CEST] <bencc> furq: there are three [22:02:07 CEST] <furq> i don't think so [22:02:16 CEST] <bencc> I wrote the same twice :) [22:02:21 CEST] <furq> yes [22:02:38 CEST] <bencc> I meant separate_moof but it's probably irelevant [22:02:55 CEST] <bencc> how can I get the byte-range of each keyframe so I can create the manifest? [22:03:00 CEST] <bencc> ffmpeg doesn't support fmp4 yet [22:04:31 CEST] <TD-Linux> Tatsh, how unfortunate [22:04:44 CEST] <Tatsh> TD-Linux, ? [22:04:54 CEST] <TD-Linux> to be cursed with DVDA's [22:04:57 CEST] <TD-Linux> I guess they are 5.1 [22:05:04 CEST] <Tatsh> what do you mean; it's just a means to an end for me [22:05:10 CEST] <Tatsh> getting the 5.1 audio for some of my favourite songs [22:05:13 CEST] <furq> at least it's not sacd [22:05:14 CEST] <Tatsh> how i get it doesn't matter [22:05:32 CEST] <Tatsh> there's only like one site selling 6ch audio and i can't remember it's name [22:05:35 CEST] <Tatsh> but there's not much selection [22:05:41 CEST] <Tatsh> its* [22:06:30 CEST] <Substring> kazuma_, not working. I'm not converting a video, i'm using ffmpeg to output it to framebuffer via SDL2 [22:06:44 CEST] <furq> https://en.wikipedia.org/wiki/Master_Quality_Authenticated [22:06:46 CEST] <furq> wtf is this [22:06:59 CEST] <Tatsh> the DVDA also has a DVD video part where it gives the same content in dolby digital ac3 [22:07:19 CEST] <furq> all the information on this page is really incongruous [22:07:20 CEST] <Tatsh> so if your DVD player won't play DVDA then you're still good but you don't get the lossless version [22:08:03 CEST] <furq> i haven't seen many DVDAs but the ones i have seen just used lpcm [22:08:58 CEST] <Tatsh> the one i have has two VTS, one is for 5.1 MLP and the other is PCM stereo [22:09:12 CEST] <Tatsh> or should i say, ATS as they are in the AUDIO_TS dir [22:11:26 CEST] <Tatsh> columbia did some evil because they sold DVDs that are double-sided for WS and FS, then they printed those with only FS but they left the UPC the same [22:11:52 CEST] <Tatsh> so then from an online retailer, i received an FS copy thinking i would get the double-sided [22:12:00 CEST] <Tatsh> evil [22:12:20 CEST] <furq> a major record label ripping off audiophiles? never [22:12:35 CEST] <Tatsh> well, moviephiles [22:12:45 CEST] <Tatsh> who in their right mind wants a FS copy nowadays [22:13:55 CEST] <kerio> fs? [22:14:05 CEST] <Tatsh> kerio, pan and scan copy of the film [22:14:09 CEST] <kerio> oh lol [22:14:14 CEST] <kerio> idk man i just download my movies [22:14:25 CEST] <furq> don't you know that piracy is a crime [22:14:31 CEST] <Tatsh> lol [22:14:38 CEST] <furq> i have seen what you have done and i am calling the police [22:14:41 CEST] <Tatsh> you wouldn't steal a bobby's cap and then take a crap in it? [22:14:45 CEST] <Tatsh> would you? [22:14:52 CEST] <kerio> you wouldn't download a car [22:15:12 CEST] <Tatsh> that was on IT Crowd [22:16:03 CEST] <kerio> http://i0.kym-cdn.com/photos/images/original/000/451/367/dba.png [22:16:22 CEST] <furq> don't tell me what to do [22:17:38 CEST] <Threads> how can i turn the first 5frames into b frames [22:18:01 CEST] <kerio> btw where can one download lossless movie rips [22:18:06 CEST] <Tatsh> kerio, no such thing [22:18:16 CEST] <furq> Threads: by removing the first frame in a hex editor [22:18:28 CEST] <furq> kerio: lossless in what sense [22:18:40 CEST] <kerio> furq: -c:v copy from a bluray or whatever [22:18:46 CEST] <Tatsh> kerio, the internet [22:18:50 CEST] <furq> yeah, that [22:19:03 CEST] <Tatsh> beware older rips are downscaled [22:19:10 CEST] <furq> from any site that you can download movies from [22:19:17 CEST] <furq> you probably want to search for bdremux [22:19:20 CEST] <kerio> ty [22:19:27 CEST] <Tatsh> because the majority of films out there on dual-layer BD [22:19:35 CEST] <Tatsh> and the groups back in 2011 agreed to downsize to 25 [22:19:37 CEST] <Tatsh> which is lame [22:19:41 CEST] <kerio> 25 what [22:19:44 CEST] <furq> gigs [22:20:04 CEST] <furq> also lol i didn't know that. that's fucking stupid [22:20:05 CEST] <Tatsh> so if you see a ~25 GiB rip, check if it's been re-encoded [22:20:13 CEST] <furq> back to the glory days of dvdshrink [22:20:16 CEST] <Tatsh> yea [22:20:31 CEST] <Tatsh> i used to downscale DVD9's to DVD5 for personal backup before dual layer was cheap enough [22:20:49 CEST] <kepstin> the last blu-ray I bought had really horrible banding, so I did some cleanup and re-encoded before I even watched it :/ [22:20:55 CEST] <kerio> surely a bdremux is just remuxed [22:21:04 CEST] <Tatsh> but furq also in 2011 dual layer BD was either non-existent for home users or was way too expensive [22:21:11 CEST] <Tatsh> i mean the scene rules are really dumb imho [22:21:12 CEST] <furq> well yeah in the same way that DVDR isn't touched [22:21:13 CEST] <TD-Linux> furq, heh maybe I'll fix the MQA page [22:21:15 CEST] <furq> except when it is [22:21:18 CEST] <Tatsh> like getting a DVD to fit on 700 MB [22:21:23 CEST] <Tatsh> just to supposedly burn it to CD? [22:21:28 CEST] <Tatsh> i mean, that was a dumb idea [22:21:40 CEST] <furq> the scene rules are slightly less stupid now [22:21:54 CEST] <furq> the x264 rules broadly make sense [22:22:03 CEST] <Tatsh> yeah but they are still demanding a file size [22:22:05 CEST] <furq> aside from completely unenforceable shit like banning bicubic resizing [22:22:16 CEST] <Tatsh> to fit like 4 30 minute 720p clips on DVD5 [22:22:42 CEST] <Tatsh> but from what i can tell, nobody especially porn groups are following such rules [22:22:51 CEST] <Tatsh> porn groups don't even use mkv container anymore [22:23:11 CEST] <kepstin> huh, what do they do instead, mp4? [22:23:22 CEST] <Tatsh> yeah mp4 high at level 4.1 [22:23:30 CEST] <Tatsh> broadest compatibility [22:23:36 CEST] <furq> the latest x264 sdtv standards don't mention filesize at all [22:23:37 CEST] <Tatsh> iOS, android, xbox one, etc [22:23:39 CEST] <kepstin> mp4 is just the container, saying "mp4 high" doesn't make sense ;) [22:23:53 CEST] <furq> and they've been enforcing using crf for years [22:23:57 CEST] <Tatsh> well good [22:23:59 CEST] <Tatsh> but at one number? [22:24:02 CEST] <kepstin> but I assume you mean mp4 with h264 high + aac. [22:24:05 CEST] <Tatsh> yea [22:24:12 CEST] <Tatsh> porn standards have always been slightly different [22:24:15 CEST] <furq> no [22:24:23 CEST] <furq> 4.4.1) CRF values below 19 and above 24 are never allowed. [22:24:30 CEST] <Tatsh> decent [22:24:38 CEST] <furq> and then it has suggestions for what you should use for what type of content [22:24:47 CEST] <kepstin> weird that they have a min crf, huh [22:24:49 CEST] <kerio> damn, i'm almost at 2TB uploaded on empornium [22:24:51 CEST] <furq> 4.6) Settings cannot go below what is specified by preset (--preset) slow. [22:24:51 CEST] <Tatsh> they should [22:25:04 CEST] <furq> so yeah the actual encoding stuff is broadly sensible [22:25:11 CEST] <Tatsh> i'm happy that they do and -crf 18 is pointless vs 19 for the use case; you're getting it for free [22:25:14 CEST] <furq> anamorphic is banned but that's not a big deal for pdtv [22:25:29 CEST] <kepstin> then again, I'm used to the anime community where people do ridiculous things like crf 14 or so :) [22:25:34 CEST] <Tatsh> ugh [22:25:42 CEST] <Tatsh> because it's cartoon they think they need a *higher* bitrate? [22:25:55 CEST] <Tatsh> i mean i hear in the anime community they are also encoding to 10-bit for no reason [22:25:58 CEST] <kepstin> well, crf 14 on animation still gives a fairly low bitrate [22:26:08 CEST] <kepstin> unless there's a lot of (usually artificial) grain [22:26:14 CEST] <furq> doesn't 10-bit give a noticeable saving for animes [22:26:26 CEST] <furq> it's obviously not for visual reasons because the sources are all 8-bit anyway [22:26:55 CEST] <kepstin> I've heard it does, but haven't seen any actual comparisons. [22:27:27 CEST] <kerio> surely if 10-bit gives a noticeable saving for compression the 8-bit compression algorithm should be updated [22:27:33 CEST] <kepstin> When I did an encode to fix banding, I used the ffmpeg 'deband' filter at 16bit and saved as 10bit, just because why not. [22:28:14 CEST] <JEEB> kerio: they updated 8bit code paths in HEVC [22:28:17 CEST] <kepstin> kerio: the thoughts behind how 10bit improves compression is that it preserves more accuracy in predicted frames, particularly when you have really long chains of B frames like x264 does in animation tune [22:28:19 CEST] <JEEB> AVC is of course AVC [22:28:42 CEST] <JEEB> and one of the streaming people actually tested 10bit against similarly quick 8bit presets [22:28:44 CEST] <kepstin> no idea if that's true or not [22:29:01 CEST] <JEEB> and the end result was "it's awesome but HW decoders don't support it" [22:29:09 CEST] <kerio> :( [22:29:26 CEST] <kepstin> yeah, that's tbh one of the main benefits of hevc - hardware decoders are usually going to support at least 10bit [22:29:30 CEST] <kerio> but it's ok, weebs spend their life at the computer anyway :^) [22:29:56 CEST] <JEEB> my oneplus one handles 1080p24 10bit AVC decoding with ARMv7 nicely [22:30:03 CEST] <JEEB> of course power usage is what it is ÖD [22:30:04 CEST] <JEEB> :D [22:30:10 CEST] <kepstin> JEEB: sure, for what, half an hour? :) [22:30:30 CEST] <JEEB> I actually remember checking that it never went 100% [22:30:32 CEST] <JEEB> so I'm not sure [22:30:32 CEST] <JEEB> :D [22:31:20 CEST] <JEEB> kepstin: the problem with HEVC is the whole licensing mess and lack of encoders where nerds poured their love into them [22:31:53 CEST] <kepstin> yeah. you can tell the lack of passion put into the x265 encoder simply by the fact that it doesn't have an easter egg touhou tune ;) [22:32:13 CEST] <furq> the one good thing about x265 [22:32:24 CEST] <JEEB> well, more like they didn't utilize the moments of good will the possible-to-be community gave to them in 2013 [22:32:37 CEST] <JEEB> at least I remember kind of trying to poke some things in it [22:32:53 CEST] <Tatsh> furq, haha death to touhou? [22:33:15 CEST] <furq> the worst game [22:34:35 CEST] <kepstin> that said, I'm kinda surprised nobody has tweaked that tune a little bit and just renamed it to 'screencast' or something; apparently it handles stuff like scrolling text and mouse cursors fairly well. [22:36:03 CEST] <furq> well yeah but then a nerd wouldn't be able to feel smug about it [22:37:35 CEST] <furq> also i thought the whole point of the tune was that it was very good at encoding 9 year old animes girls screeching incomprehensible, unskippable, wrongly-decoded text at each other for half an hour between every stage [22:38:03 CEST] <kerio> "9 year old animes girls" [22:38:05 CEST] <kerio> you can just say lolis [22:38:19 CEST] <Tatsh> i have some like, hinabita stuff [22:38:23 CEST] <furq> thank you. i've just added you to my list [22:38:24 CEST] <Tatsh> mostly because of video games [22:38:48 CEST] <furq> wait nvm i just remembered you're already on my list on account of the whole radiohead thing [22:38:51 CEST] <kerio> >:c [22:39:01 CEST] <furq> i'll just underline your name then [22:39:07 CEST] <kerio> hey furq [22:39:14 CEST] <kerio> this song from the 90s takes 2.8mbps [22:39:32 CEST] <furq> so you like radiohead and animes. i bet you're popular with the ladies [22:39:41 CEST] <kepstin> I really should play around with vp9 a bit more now that it has working multithreaded encoding. Probably won't actually use it for anything, but good to see how it'll compare at least :/ [22:39:57 CEST] <Tatsh> lot of android devices have hw vp9 [22:39:57 CEST] <kerio> ? [22:39:58 CEST] <furq> it still doesn't have frame threading does it [22:40:03 CEST] <kepstin> well, s/working/usefully scaling/ [22:40:08 CEST] <kerio> don't you fucking dare imply i like anime [22:40:09 CEST] <furq> it's just the slice threading is no longer completely useless [22:40:13 CEST] <kepstin> I think the recent builds do actually have frame threading? [22:40:25 CEST] <furq> this must be very recent [22:40:33 CEST] <kepstin> yeah, no released version with it yet [22:40:35 CEST] <furq> last i heard they'd added row threading, which is better slice threading [22:40:50 CEST] <kepstin> hmm, you're right, it is the row threading stuff not frame threading [22:42:02 CEST] <Tatsh> you know, i'm wondering if this 5.1 music will sound any better when mixed to stereo [22:42:16 CEST] <Tatsh> compared to the official stereo track [22:42:25 CEST] <kepstin> probably not? [22:42:34 CEST] <Tatsh> may not be able to tell [22:42:41 CEST] <furq> i'm also going to say probably not [22:42:56 CEST] <furq> especially if you downmix it with ffmpeg [22:43:00 CEST] <kepstin> depending on the matrix you use to downmix the balance will probably be a bit off, at best [22:43:04 CEST] <Tatsh> are my ears bad? i recorded a song from Dolby B/HX Pro tape in (with proper equipment) and compared it to the FLAC and couldn't hear the difference [22:43:15 CEST] <furq> i'd say they're about average [22:43:27 CEST] <Tatsh> the FLAC off CD of course [22:43:37 CEST] <furq> if average people could tell the difference then mp3s wouldn't still exist [22:44:25 CEST] <kepstin> keep in mind that there's half a chance that the stuff on the CD would also have been transferred from a similar quality tape, particularly for older material... [22:44:41 CEST] <kepstin> well, not cassette tape, I dunno what exactly you have [22:45:23 CEST] <furq> hx pro is specifically for compact cassette isn't it [22:45:24 CEST] <Tatsh> this was richard Marx - Repeat Offender album [22:45:31 CEST] <Tatsh> i have it on tape and CD [22:45:52 CEST] <Tatsh> tried to make serious comparisons and the only difference was the tape was slightly shorter [22:46:01 CEST] <Tatsh> 1% shorter; perhaps you can blame equipment [22:46:23 CEST] <kepstin> Tatsh: probably mostly depends on the accuracy of the speed control on your tape deck :/ [22:46:23 CEST] <Tatsh> if there was any pitch difference, i couldn't hear it [22:46:36 CEST] <Tatsh> i love my tape deck; it's hq [22:46:55 CEST] <Tatsh> JVC TD-W309 [22:47:03 CEST] <kepstin> hmm, 1989 album, could very well have been ADD or even AAD on the CD version. [22:47:12 CEST] <Tatsh> hoping the belts never die [22:47:16 CEST] <Tatsh> :/ [22:47:32 CEST] <Tatsh> i have a broken sony tape deck which i replaced the belts and still didn't work; probably capacitors [22:47:53 CEST] <furq> belts are way easier to repair than direct drive [22:47:56 CEST] <furq> unless you have a 3d printer [22:47:57 CEST] <kepstin> it might even say whether it was AAD, ADD, or DDD right on the cd case, particularly if the cd copy you have is vintage [22:49:06 CEST] <Tatsh> very basic https://www.discogs.com/Richard-Marx-Repeat-Offender/release/1688152 [22:49:46 CEST] <Tatsh> but in any case, the dolby hx pro tapes i do have that haven't degraded sound amazing [22:50:48 CEST] <Tatsh> furq, if i play 5.1 on my system which is only stereo, mpv is just mixing according to that standard anyway? [22:50:53 CEST] <Tatsh> so i'm hearing the effect of that live [22:51:08 CEST] <furq> idk if it uses the same downmixing as ffmpeg, but probably [22:51:12 CEST] <furq> ask durandal_1707 [22:51:25 CEST] <durandal_1707> Tatsh: if you have 5.1 setup [22:51:41 CEST] <Tatsh> that is, the Document A/51 [22:51:46 CEST] <Tatsh> Document A/52 [22:51:53 CEST] <Tatsh> standard for downmixing [22:52:02 CEST] <durandal_1707> what? [22:52:03 CEST] <Tatsh> i have 5.1 setup upstairs i'm going to try with this audio soon [22:52:20 CEST] <Tatsh> https://trac.ffmpeg.org/wiki/AudioChannelManipulation#a5.1stereo [22:52:26 CEST] <Tatsh> By default when using -ac 2 the LFE channel is omitted. See "Digital Audio Compression Standard (Document A/52:2012)", sections 6.1.12 and 7.8 for more downmixing info. [22:52:33 CEST] <Tatsh> my alsa setup is to use 2ch [22:52:48 CEST] <kepstin> Tatsh: it's quite possible that the stereo mix was done separately, and isn't just a downmix of the 5.1 track, in which case they will sound different. [22:52:52 CEST] <furq> well yeah i doubt that'll sound better than a cd that was mastered for stereo [22:52:54 CEST] <furq> but who knows [22:53:01 CEST] <durandal_1707> if you have 2 speakers you are doomed [22:53:04 CEST] <Tatsh> it's hard to compare [22:53:45 CEST] <Tatsh> i read reviews on the DVDAs and SACDs i did buy to make sure they weren't stupidly done [22:53:49 CEST] <Tatsh> a lot of rip-offs [22:53:56 CEST] <durandal_1707> for headphone downmix there is special filter [22:54:23 CEST] Action: kepstin notes that converting stereo to mono is similarly problematic. [22:55:14 CEST] <Tatsh> weird thing about this DVDA; it says 96K on the back, but the actual rate is 88200 [22:55:28 CEST] <durandal_1707> there is incomplete dolby pro logic encoder in libswr [22:56:01 CEST] <furq> yeah i'm sure there are a bunch of upmixed "5.1" releases so they can sell them for £50 to the type of people who spend 100 times that on interconnects made of rhino skin [22:56:16 CEST] <durandal_1707> omg [22:56:22 CEST] <furq> the more endangered the animal, the warmer the sound [22:56:23 CEST] <Tatsh> that stuff pisses me off [22:56:56 CEST] <Tatsh> the studios are not trustworthy [22:57:04 CEST] <Tatsh> whenever you see 'remastered' or whatever you have to question it [22:57:17 CEST] <zleap> hi [22:57:27 CEST] <Tatsh> right now you can buy remastered albums of music from the 90's and i'm like, what? [22:57:33 CEST] Action: kepstin has a few late 80s/early 90s cds, and modern "remastered" releases are generally worse :/ [22:57:40 CEST] <furq> audiophile stuff is totally alien to me, but probably half of all "4k" blu-rays are just upscaled [22:57:43 CEST] <Tatsh> or even 2000s [22:57:48 CEST] <furq> because in their infinite wisdom they decided to shoot it in 2k [22:57:50 CEST] <Tatsh> why would they need to remaster anything from that time period [22:57:59 CEST] <Tatsh> unless there were serious mistakes [22:58:01 CEST] <kepstin> typically remastering 90s stuff consists of loading it in a daw, raising the gain and applying some limiting, and saving. [22:58:07 CEST] <furq> because they didn't compress it enough the first time [22:58:10 CEST] <Tatsh> other than that, i see no reason to remaster anything from the 2000s [22:58:19 CEST] <Tatsh> all they do is increase the volume and it pisses me off [22:58:35 CEST] <furq> or yeah just make it clip [22:58:40 CEST] <furq> hello japan [22:58:51 CEST] <Tatsh> for 80's and below a lot of crap remasters exist [22:58:53 CEST] <zleap> is it possible, using a raspberry pi to use two switches to control ffmpeg,one to start recording and a second to stop recording and save the file [22:59:02 CEST] <kepstin> well, they need to do that, because otherwise it sounds too quiet next to modern stuff, which people interpret as meaning sounding worse. [22:59:03 CEST] <Tatsh> you'd be better off buying the original vinyl [22:59:06 CEST] <Tatsh> or tape [22:59:09 CEST] <kepstin> :/ [22:59:22 CEST] <Tatsh> for movies the issue now is digital [22:59:31 CEST] <furq> well at least for that stuff you can just get the original master [22:59:38 CEST] <furq> i've got a ton of stuff which is 3dB into the red [22:59:39 CEST] <Tatsh> the movies are shot in digital, so there's no way to really upscale without nastiness, but consumers don't care [22:59:48 CEST] <furq> well modern movies are shot at 4k [23:00:02 CEST] <kepstin> modern releases of animation from the mid 2000's are generally just terrible [23:00:04 CEST] <Tatsh> that's fine and all [23:00:05 CEST] <furq> but yeah a ton of stuff from the '00s was wisely shot at 2k [23:00:12 CEST] <kerio> Tatsh: http://www.oknotok.co.uk [23:00:16 CEST] <kepstin> before that, they were typically shot on 16mm film, which could be rescanned [23:00:22 CEST] <furq> this better not be a radiohead [23:00:28 CEST] <kepstin> after that they were often done in at least 720p [23:00:28 CEST] <Tatsh> i thought it was 35mm [23:00:29 CEST] <kerio> it is, in fact, a radiohead [23:00:36 CEST] <Tatsh> and they could rescan that to like, 8K [23:00:50 CEST] <kepstin> but in that one range, you have SD digital animation often with editing done on interlaced content [23:00:52 CEST] <kepstin> and it' [23:00:53 CEST] <Tatsh> that's why the 1080p back to the future looks really good [23:00:55 CEST] <kepstin> s just nasty [23:00:55 CEST] <furq> yeah 35mm film goes way beyond 8k [23:01:07 CEST] <furq> and i expect 16mm film will comfortably go to 8k [23:01:12 CEST] <kerio> oh so quentin tarantino was just thinking of futureproofing [23:01:17 CEST] <kerio> :^) [23:01:22 CEST] <Tatsh> i don't know if there's a 4K back to the future but i'm pretty sure they would've shot it on the best quality film [23:01:35 CEST] <furq> yes, he shot reservoir dogs on film out of a sense of respect for tradition [23:01:36 CEST] <Tatsh> steven spielberg not messing around [23:01:37 CEST] <kepstin> yeah, but that's not typically useful for animation content, not enough detail really for >1080p scans of 16mm to be worth it ;) [23:01:44 CEST] <kerio> furq: i'm talking about hateful eight [23:01:47 CEST] <kerio> which was shot on 35mm [23:01:58 CEST] <Tatsh> george lucas embraced digital pretty early on [23:02:04 CEST] <kerio> wait, it was shot in 70mm :o [23:02:09 CEST] <Tatsh> arguably not a good idea [23:02:11 CEST] <furq> i haven't seen any quentin tarantino film since pulp fiction [23:02:23 CEST] <furq> i assume they're all that insufferable [23:02:25 CEST] <Tatsh> iirc they shot star wars phantom menace on digital [23:02:30 CEST] <Tatsh> and that means, no 4k for you [23:02:41 CEST] <Tatsh> also avatar was all digital [23:02:41 CEST] <furq> well phantom menace was like 90% greenscreen anyway [23:02:51 CEST] <Tatsh> but avatar was probably 4K digital shot [23:02:59 CEST] <furq> and also 100% shit [23:03:04 CEST] <Tatsh> yes it's a shit film i agree :) [23:03:19 CEST] <kerio> furq: in inglorious basterds they kill hitler [23:03:28 CEST] <furq> aren't you missing a u there [23:03:39 CEST] <kepstin> given the amount of digital fx in many modern movies, the stuff actually on film, if still used, is pretty minimal :/ [23:03:52 CEST] <Tatsh> that's true [23:04:02 CEST] <Tatsh> there's no point to record on film if they are just going to add digital fx later [23:04:13 CEST] <furq> it worked in the 90s [23:04:24 CEST] <Tatsh> as long as they start with 4K or above lossless [23:04:30 CEST] <Tatsh> which is what all the digital cameras in studios do now [23:04:35 CEST] <furq> also yeah evidently people will still buy upscaled 4k bluray because they're idiots [23:04:42 CEST] <Tatsh> also 8K cameras available now for like $50K [23:04:46 CEST] <kepstin> well, for stuff like TRON they didn't really have any useful digital storage formats; they rendered directly onto film for that iirc [23:04:46 CEST] <furq> they're obviously idiots because they bought a 4k bluray player in the first place [23:04:47 CEST] <Tatsh> lossless format [23:04:56 CEST] <furq> and then presumably bought a new tv so that they were allowed to connect their 4k bluray player to it [23:04:59 CEST] <Tatsh> kerio, for older theatres without digital equipment? [23:05:07 CEST] <furq> are there such theatres [23:05:21 CEST] <Tatsh> i think the one in my downtown that charges like $2 to see a film from like 10 years ago is not digital [23:05:29 CEST] <kerio> Tatsh: no, hateful eight was shot in 70mm because tarantino is a super nerd [23:05:46 CEST] <Tatsh> furq, i'd have to check [23:05:52 CEST] <furq> i'm pretty sure they stopped distributing new films to theatres with no digital equipment years ago [23:05:54 CEST] <Tatsh> older theatres have two projectors that switch off [23:05:58 CEST] <Tatsh> pretty easy to tell [23:06:26 CEST] <Tatsh> projectionist job must be shitty [23:06:39 CEST] <furq> you get to see a lot of films for free [23:06:43 CEST] <furq> and as we all know, most films are good [23:06:44 CEST] <kerio> *the same films [23:07:04 CEST] <kerio> how do you sync the projectors tho [23:07:06 CEST] <kepstin> isn't projectionist job nowadays basically "plug this hard drive into this projector"? :/ [23:07:07 CEST] <furq> there have only ever been seven bad films [23:07:20 CEST] <kerio> like how does it work [23:07:37 CEST] <furq> you do realise that everyone's knowledge of this is from "fight club", right [23:07:38 CEST] <Tatsh> kepstin, yes [23:07:55 CEST] <furq> which means we're all trying not to think about that bloke's cock [23:08:02 CEST] <Tauromancer> 2002 I spliced real film of major pictures, like Spiderman [23:08:07 CEST] <Tatsh> they receive the decryption keys at the very last second prior to the day of release [23:08:14 CEST] <Tatsh> Tauromancer, nice [23:08:22 CEST] <Tauromancer> and that was in the bad theater no one in town liked [23:08:30 CEST] <Tatsh> was that loud as fuck [23:08:31 CEST] <Tauromancer> I doubt places like those can still pay for movies [23:08:45 CEST] <Tatsh> projectors are loud as shit [23:08:50 CEST] <furq> 2002 definitely qualifies as "years ago" [23:08:56 CEST] <Tauromancer> yeah [23:09:00 CEST] <Tauromancer> and hot [23:09:40 CEST] <Tatsh> so you're saying in 2002 projectionist job still wasn't automated [23:09:48 CEST] <Tatsh> were you in a union that demanded such? [23:10:13 CEST] <Tauromancer> I was in high school, the projectionist didn't give a shit [23:11:56 CEST] <zerodefect> I'm using the C-API to create a "mpegts" output context and transmitting over UDP. Is it possible to programatically set the src port for the UDP socket? [23:13:00 CEST] <kepstin> zerodefect: are you using ffmpeg's udp protocol handling? [23:13:30 CEST] <kepstin> zerodefect: if so, it takes a bunch of parameters on the url, which let you set the local port and some other stuff [23:13:45 CEST] <kepstin> zerodefect: see https://www.ffmpeg.org/ffmpeg-protocols.html#udp [23:13:45 CEST] <Tatsh> i thought theatres would stop existing like 10 years ago [23:13:56 CEST] <Tatsh> but apparently home theatres did not become that popular [23:14:14 CEST] <Tatsh> i hate when i go to other people's houses and they don't have surround sound :P [23:14:22 CEST] <Tatsh> and they are like 'come over here and watch a movie' [23:14:31 CEST] <kepstin> well, the novelty of 3d movies still seems to be fairly strong, and 3d tvs basically went nowhere. [23:14:33 CEST] <zerodefect> Kepstin, I think so. I'm setting something like 'udp://127.0.0.1:10001' when creating the context. Is that what you're referring to? [23:14:34 CEST] <Tatsh> with no surround sound? with a soundbar? are you kidding me [23:14:58 CEST] <kepstin> my dad actually has a 3d TV, mostly uses it for playing gran turismo on the ps3. [23:15:07 CEST] <Tatsh> i have a 3d tv and its' really not that interesting [23:15:41 CEST] <Tatsh> as for 3d films at the theatre it's only slightly better than 2D [23:15:41 CEST] <kepstin> was neat, cause I could hook it up to my radeon and a bunch of pc games worked in 3d on it as well. [23:15:56 CEST] <Tatsh> NES game Rad Racer has a 3D mode [23:16:15 CEST] <kepstin> zerodefect: yep. see my link [23:16:42 CEST] <Tatsh> i'm buying a new surround sound system at my new place [23:16:54 CEST] <Tatsh> it's going to be sweet [23:17:20 CEST] <kepstin> I decided that rather than get surround sound, I'd get better stereo speakers. I mostly use it for music, so yeah. [23:17:33 CEST] <Tatsh> makes sense until you get 5.1 music like i just did [23:17:57 CEST] <zerodefect> Kepstin: Thanks! I missed it the first time :/ [23:18:00 CEST] <Tatsh> but you could hook up 4 speakers instead of just two and get a surround effect [23:18:05 CEST] <Tatsh> which is kind of interesting [23:18:33 CEST] <Tatsh> i've used ffmpeg to 'fix' films to have 4 channels instead of just 2 (for movies without surround), because my receiver will not let me fake this with its own hardware [23:18:54 CEST] <Tatsh> it's kind of annoying if you have those speakers there and they are not outputting anything [23:21:00 CEST] <kerio> ye it's kind of annoying that i have all those pixels at the left and the right of the screen that aren't displaying anythting [23:21:07 CEST] <kepstin> it's kind of odd that most 5.1 systems have a better speaker in the centre channel than any of the others, but I guess that makes sense since most movies have dialogue centre-panned [23:21:13 CEST] <kerio> so i set my tv to "full screen" [23:21:21 CEST] <Tatsh> hehe [23:21:34 CEST] <Tatsh> kepstin, i actually dislike that as i find sometimes they are talking 'behind you' [23:21:41 CEST] <Tatsh> and yet the speech is all in the centre channel [23:21:51 CEST] <kepstin> Tatsh: well, that's just a bad mixing job [23:22:18 CEST] <kerio> nothin personnel, kid [23:22:35 CEST] <Tatsh> kerio, what do you mean? you like stretching 4:3 content? [23:22:47 CEST] <kerio> it was a joke [23:22:52 CEST] <Tatsh> oh [23:22:59 CEST] <kerio> no i don't, it drives me insane [23:23:06 CEST] <Tatsh> well, in any case, if your TV doesn't have a shitty black level then you won't see the sides in the dark [23:23:39 CEST] <Tatsh> people go insane when content doesn't fill the screen [23:23:52 CEST] <Tatsh> that's why 16:10 monitors almost don't exist, they definitely stopped making them for laptops [23:24:24 CEST] <Tatsh> the demand for more pixels for computing is lower than the demand of make 16:9 movies not show black bars [23:31:19 CEST] <Tauromancer> i have almost nothing but 1680x1050 Dells [23:31:22 CEST] <Tauromancer> it's torture [23:32:50 CEST] <vlt> Great for subtitles :p [23:33:04 CEST] <kerio> 2880x1800 here [23:44:00 CEST] <kepstin> the nice think about 4k video is that it does mean higher res pc monitors are becoming available [23:51:19 CEST] <momomo> if one generates hls segment files of length 1,3,5 or 10 seconds ... does that affect the size of the output files? is compression of video, frame to frame affected making 1s segments more expensive since a whole new encoding has to be made in the start of each file? [23:52:18 CEST] <DHE> HLS requires keyframes as the first frame of each file. making too many keyframes has a negative impact on bitrate/quality [23:53:00 CEST] <DHE> also, 1 second seems like a bad idea in general due to the expected latency just in issuing HTTP requests starting to become significant [23:53:41 CEST] <momomo> DHE: sure but more on the technical level here .. not decided on 1s although I am not having any playback issues, does 1s segment files cause more keyframes then? [23:54:06 CEST] <Tatsh> wow, just listened to Dire Straits - Brothers in Arms in 5.1 [23:54:08 CEST] <Tatsh> it sounds amazing [23:54:17 CEST] <DHE> let's assume 30fps.... at 1s, you need -g 30. at 3s, you need -g 90. At 5s, -g 150. 10 s, -g 300 [23:54:29 CEST] <momomo> DHE: i have these options: -r 24 -g 120 -x264opts keyint_min=120 -crf 24 -x264-params scenecut=0 [23:54:51 CEST] <momomo> for 5s [23:54:57 CEST] <DHE> what's the frameratE? [23:55:00 CEST] <momomo> 24 [23:55:05 CEST] <momomo> -r 24? [23:55:05 CEST] <Threads> Tatsh: music in 5.1 good ? [23:55:30 CEST] <momomo> what does scenecut do? and keyint_min? :S [23:55:58 CEST] <Tatsh> Threads, it's good if it's done well [23:56:02 CEST] <DHE> scenecut gives x264 permission to insert keyframes any time it sees that the image changes so dramatically that it thinks reference frames won't help anymore [23:56:11 CEST] <Tatsh> Threads, check reviews on any thing you decide to buy [23:56:24 CEST] <Tatsh> there's not much selection and a lot of things are rip-offs [23:56:28 CEST] <momomo> DHE: is that a good thing then? expensive in any way? [23:56:32 CEST] <momomo> computation wise [23:56:37 CEST] <momomo> or size wise [23:56:49 CEST] <DHE> well turning it off just forces it to not check and only generate keyframes on the schedule [23:57:12 CEST] <DHE> but for HLS it will make the segment files inconsistent in size/duration [23:57:22 CEST] <momomo> DHE: I think some guys here helped me once and possibly suggested that due to getting exact times for hls [23:57:25 CEST] <momomo> segments [23:57:32 CEST] <momomo> ^^ yes, like you said :D [23:58:01 CEST] <DHE> yep. disabling scenecut and forcing the keyframe minimums and maximum to be identical (120 frames) forces everything the way you want [23:58:39 CEST] <DHE> yeah I know a fair bit about HLS.. I have a few webcams converted to HLS so people can view them in their browsers [23:59:33 CEST] <momomo> DHE: yes, you seem to know quite alot [00:00:00 CEST] --- Tue Jun 13 2017

1 0

ffmpeg-devel.log.20170611
by burek 12 Jun '17

12 Jun '17

[02:29:21 CEST] <cone-194> ffmpeg 03Michael Niedermayer 07master:71da0a5c9750: avcodec/ra144: Fix runtime error: signed integer overflow: -2200 * 1033073 cannot be represented in type 'int' [02:29:21 CEST] <cone-194> ffmpeg 03Michael Niedermayer 07master:1197c0489642: avcodec/fft_template: Fix multiple runtime error: signed integer overflow: -1943918714 - 1935113003 cannot be represented in type 'int' [02:29:21 CEST] <cone-194> ffmpeg 03Michael Niedermayer 07master:22a25ab3896c: avcodec/tiff: Fix leak of geotags[].val [03:45:10 CEST] <thebombzen> hmm... how long does it usually take a developer to take a look at a crash bug on TRAC? [10:02:22 CEST] <cone-423> ffmpeg 03Paul B Mahol 07master:29bdcf588f81: avcodec: add Gremlin DPCM decoder [10:02:22 CEST] <cone-423> ffmpeg 03Paul B Mahol 07master:d1c08027d8e4: avcodec: add Gremlin Digital Video decoder [10:02:22 CEST] <cone-423> ffmpeg 03Paul B Mahol 07master:c94841487622: avformat: add Gremlin Digital Video demuxer [10:27:42 CEST] <cone-423> ffmpeg 03Paul B Mahol 07master:9a949cdf8f6c: avcodec/gdv: fix compiler warnings [13:27:03 CEST] <kierank> thebombzen: infinity [13:58:43 CEST] <durandal_1707> kierank: infinity what? [14:10:10 CEST] <kierank> Infinity times to answer ticket [14:52:00 CEST] <thebombzen> I was wondering how long it took on average for devs to analyze bugs [14:52:19 CEST] <thebombzen> I ask because I submitted a bug report 3 weeks ago about a segfault crash [14:53:18 CEST] <JEEB> depends on if someone cares and/or has looked at the trac if that's where you reported an issue [15:23:13 CEST] <cone-965> ffmpeg 03Michael Niedermayer 07master:6d499ecef9c2: avcodec/aacdec_fixed: Fix runtime error: left shift of negative value -1297616 [15:23:13 CEST] <cone-965> ffmpeg 03Michael Niedermayer 07master:2e44126363bc: avcodec/snowdec: Fix runtime error: left shift of negative value -1 [17:32:23 CEST] <thebombzen> JEEB: it's on trac yea [17:32:57 CEST] <thebombzen> a bit disappointed b/c I spent a bit of time trying to run valgrind and all [17:52:23 CEST] <JEEB> thebombzen: well I can't say much not knowing what this thing is :) [17:52:52 CEST] <thebombzen> this is the ticket [17:52:53 CEST] <thebombzen> https://trac.ffmpeg.org/ticket/6413 [17:53:22 CEST] <JEEB> right [17:56:15 CEST] <JEEB> well, I have this feeling that the ssh stuff was just added by someone and nobody has the intent of actually maintaining it. plus not many people actually look at the trac too much. so if you actually have use cases for it, you might want to see if you want to maintain it. [19:51:49 CEST] <thebombzen> this is one of those bugs I would fix provided that I could debug C memory errors [19:51:55 CEST] <thebombzen> but I don't know C well enough for that [19:53:42 CEST] <jamrial> thebombzen: just sent a fix to the ml [19:54:03 CEST] <nevcairiel> the ML doesnt think so! [19:55:02 CEST] <thebombzen> lol okay thanks [19:55:37 CEST] <jamrial> nevcairiel: huh, you're right, it's not in the archives [19:58:44 CEST] <nevcairiel> there it is [19:58:51 CEST] <nevcairiel> was just slow [20:29:11 CEST] <cone-630> ffmpeg 03James Almer 07master:e3887c0a2c57: avformat/mov: add support for reading VP Codec Configuration Box [20:53:58 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07master:c996374d4d86: avcodec/wavpack: Fix runtime error: signed integer overflow: 1886191616 + 277872640 cannot be represented in type 'int' [20:53:59 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07master:d24043e1a2f9: avcodec/jpeg2000dwt: Fix runtime error: left shift of negative value -123 [20:55:26 CEST] <BtbN> oh, nice. Those efforts to not link, not strip and --disable-doc on coverity actually cut off like 12 minutes from the build time [22:45:06 CEST] <BBB> thebombzen: within a couple of days usually [23:37:21 CEST] <durandal_1707> michaelni: having random numbers in logs is not useful [00:00:00 CEST] --- Mon Jun 12 2017

1 0

ffmpeg.log.20170611
by burek 12 Jun '17

12 Jun '17

[00:04:11 CEST] <kms_> i change it by mkvmerge --default-duration 0:60fps in.webm -o out.webm [01:51:24 CEST] <Tatsh> anyone ever blurred faces using only ffmpeg? [01:51:39 CEST] <Tatsh> only for a short portion of the video, they are relatively static [02:09:38 CEST] <thebombzen> is there a way to unset a certain metadata key but otherwise copy the rest? [02:10:00 CEST] <Tatsh> if it's an mp4 you could consider using atomicparsley [02:10:29 CEST] <thebombzen> it's a matroska that I think was originally muxed with libmkv+libebml [02:10:37 CEST] <thebombzen> there's a metadata key that's set: NUMBER_OF_BYTES [02:10:55 CEST] <Tatsh> there's a way to copy the entire metadata, and maybe an argument after that would overwrite [02:11:06 CEST] <Tatsh> and you could set that to blank if that's acceptable [02:11:16 CEST] <thebombzen> this of course is pretty useless if you re-encode but ffmpeg copies it anyway. however I don't want to strip all the metadata [02:11:31 CEST] <thebombzen> the question is how to delete the metadata key [02:13:17 CEST] <Tatsh> well you don't have to re-encode [02:13:23 CEST] <Tatsh> you can always use -codec copy [02:13:53 CEST] <Tatsh> ffmpeg -i somefile.mkv -codec copy -map_metadata 0 [02:14:05 CEST] <Tatsh> with -map_metadata is where you might be able to filter some metadata out? [02:16:56 CEST] <thebombzen> I don't think you understand my question [02:17:23 CEST] <Tatsh> ffmpeg does not modify the input files whatsoever [02:17:28 CEST] <Tatsh> it can only make a copy [02:18:30 CEST] <thebombzen> again, I don't think you understand my question [02:18:54 CEST] <thebombzen> the good news is I figured it out [02:19:25 CEST] <thebombzen> if you use "-metadata:s KEY=" then ffmpeg is smart enough to delete the metadata key rather than set it to the empty string or complain about an error [02:19:34 CEST] <thebombzen> I'm not sure if this is the canonically recommended method but it works [02:20:22 CEST] <thebombzen> Tatsh: to answer your question, it is definitely possible but to do it efficiently or easily? I'd recommend a nonlinear editor [02:21:30 CEST] <thebombzen> the only way I can think to do that with ffmpeg is figure out a bunch of coordinates by hand and then split the stream, crop the copy, pad it, run it through a blur filter, and then overlay it back [02:21:35 CEST] <thebombzen> this is horribly inefficient [02:23:27 CEST] <Tatsh> well, it's about the same amount of time spent in a non-linear editor [02:24:02 CEST] <Tatsh> would be cool if a built-in face detection+blur thing was there, because i don't need to blur out just some faces, but all faces [02:37:49 CEST] <factor> i was trying to figure out how to switch between two overlay images on demand to give me a double buffer to manipulate. [02:38:59 CEST] <factor> Can I change the -i png on demand? Does ffmpeg pull the image again if it has changed? [02:53:39 CEST] <factor> Was looking at zmq , could that do whati wanted like change overlay image on demand. [03:01:18 CEST] <DHE> factor: at least on unix you can atomically replace a file without hassle [03:02:19 CEST] <factor> DHE: So I can change my overlay image in place. [03:05:10 CEST] <DHE> under unix write the new file in its entirety to some other file in the same file system (typically the same directory) and `mv` it over the old/active video. [03:05:27 CEST] <DHE> or in programming languages use the rename() function [03:10:04 CEST] <factor> DHE: I just tried that and it did not work. [03:10:48 CEST] <factor> I root@streamcaster:/opt# cp flame2.png dummy.png root@streamcaster:/opt# cp flame1.png dummy.png [03:11:04 CEST] <factor> using dummy.png as the overlay [03:11:27 CEST] <factor> it kept the same flame1.png image in the stream. [03:12:33 CEST] <factor> DHE: I used this for the overlay mixing. -vf "movie=dummy.png [watermark]; [in][watermark] overlay=10:10 [out]" [03:55:03 CEST] <Tatsh> i got footage of my car going through a car wash and at 4x it's almost like seizure inducing [03:55:07 CEST] <Tatsh> :) [05:51:15 CEST] <Ekho> Hmm, seems when the ffmetadata muxer only uses the first 1023 bytes of each tag (counting the tagname and '=' sign) when reading from file. EX: ARTIST=really_long_name_over_1016_bytes would have nothing after the 1016th byte of the name in the tag. Adding the same tag from with -metadata TAG=VALUE works fine, though after ~100KiB you typically run into the argument length limit. [05:52:27 CEST] <Ekho> Not sure how to get around this [05:54:58 CEST] <Ekho> s/seems when/seems/ [07:58:52 CEST] <factor> Where are sets of good examples for using zmqsend. [08:53:01 CEST] <thomedy> hey im trying to transcode mp4 or webm to raw [10:51:38 CEST] <hendry> by default iiuc ffmpeg re-encodes to the best bitrate for the input? [10:52:02 CEST] <kerio> re-encodes what? [10:52:03 CEST] <kerio> into what? [10:52:05 CEST] <hendry> with a command like https://github.com/kaihendry/recordmydesktop2.0/blob/master/htmlvideo#L36 [10:52:44 CEST] <kerio> no, that will just use the default libx264 settings [10:52:46 CEST] <hendry> so i encode my camera's high bitrate mp4 with -movflags +faststart -pix_fmt yuv420p -c:v libx264 ... the output is about a ~4Mbps bitrate file by default [10:52:58 CEST] <kerio> whether or not they're the correct for you is up to you [10:53:09 CEST] <hendry> the default seems pretty darn good [10:53:40 CEST] <hendry> is it correct to say it's a re-encoding to a more appropriate bit rate? (trying to describe what it does by default) [10:54:22 CEST] <hendry> or maybe a better question is, what is the "default libx264 settings" RE bit rate ? [10:54:25 CEST] <kerio> if the default is a VBR trying to target a specific crf, then sure [10:54:34 CEST] <kerio> idk i'm trying to figure it out [10:55:11 CEST] <furq> the default is crf 23 [10:55:16 CEST] <kerio> D: [10:55:21 CEST] <kerio> so ugly D: [10:55:22 CEST] <furq> which is "ok" [10:55:42 CEST] <kerio> -crf 18 or gtfo [10:55:52 CEST] <furq> i'd use 19-21 for archival, but 23 will be broadly fine [10:56:04 CEST] <furq> 23 at preset medium, i should say [10:56:18 CEST] <furq> since the preset affects the meaning of the crf [10:56:22 CEST] <kerio> oh ;o [10:56:39 CEST] <kerio> wait why would the preset affect the meaning of crf [10:56:47 CEST] <furq> why wouldn't it [10:56:53 CEST] <kerio> isn't crf a check on the resulting image [10:57:16 CEST] <kerio> i'd expect a lower preset to result in a bigger video, not a worse-looking one [10:57:31 CEST] <furq> that is intuitively how it would work [10:57:33 CEST] <furq> but it isn't how it works [10:57:36 CEST] <kerio> :( [10:57:43 CEST] <kerio> why does everything suck [10:58:07 CEST] <furq> i'm pretty sure crf just does a motion analysis to determine what q to use [10:58:12 CEST] <furq> i'm no expert though [10:58:33 CEST] <kerio> hendry: anyway the answer is "yes" [10:58:43 CEST] <furq> more motion = higher q [10:58:58 CEST] <hendry> furq: what is your full archival line again? do you h264 or have you tried others like libx265 ? [10:59:15 CEST] <furq> so you don't end up compressing that hbo logo at q 18 and using 100MB for the first 10 seconds [10:59:36 CEST] <kerio> btw is there a reason to not use +faststart all the time? [10:59:40 CEST] <furq> hendry: normally -crf 20 -preset veryslow -tune film [10:59:47 CEST] <kerio> other than the obvious "don't use mp4" :^) [10:59:54 CEST] <furq> obviously -tune depends a lot on the content [11:00:05 CEST] <furq> kerio: not really but it matters less these days [11:00:33 CEST] <hendry> kerio: +faststart is required to move the MOOV bit to the front so Web players can play it back quickly [11:00:42 CEST] <furq> if i'm parallel batch remuxing to mp4 then i'll disable faststart because it's slow as shit [11:00:45 CEST] <kerio> yes, i'm aware of what +faststart does [11:00:50 CEST] <kerio> furq: oh ;o [11:00:54 CEST] <furq> and then do it sequentially with l-smash [11:01:21 CEST] <furq> or i'll just do the whole thing with l-smash [11:01:28 CEST] <hendry> kerio: sorry, so yes, it should always be done imo :} [11:01:41 CEST] <furq> web players can play it back quickly regardless these days [11:01:52 CEST] <furq> as long as your server supports range requests [11:01:59 CEST] <hendry> i was looking at AWS Elastic Transcoder profiles, and bizaarely, they seem limit resolution and bit rate, e.g. https://s.natalian.org/2017-06-11/aws-web-profile.png [11:02:14 CEST] <hendry> Which I don't like, so now I have come up with my own ffmpeg pipeline. Doh. [11:02:31 CEST] <furq> that's not that bizarre if they charge by media minute [11:02:38 CEST] <furq> which i assume they do [11:02:51 CEST] <furq> obviously 4k60 is going to take much longer to encode at the same settings [11:03:28 CEST] <kerio> furq: what about streaming tho [11:03:39 CEST] <furq> what about it [11:03:39 CEST] <kerio> although i guess fragmented isobmff is a whole different bag of dicks [11:03:48 CEST] <hendry> furq: well option should be there, since that might be what someone wants with a certain input [11:03:48 CEST] <furq> fmp4 isn't faststart [11:03:51 CEST] <furq> that's a whole different thing [11:03:59 CEST] <kerio> still .mp4 tho :^) [11:04:06 CEST] <furq> hendry: i guess they haven't implemented the pricing tier for it yet [11:04:35 CEST] <hendry> furq: what i don't understand is the need to segment videos for Web playback. Why isn't +faststart & httpd with range support work (i think S3+CF support range requests) [11:04:50 CEST] <furq> it does work [11:04:55 CEST] <furq> and you only need one or the other [11:05:27 CEST] <hendry> furq: i'd rather have one file that worry about a bunch of files [11:05:35 CEST] <furq> well good because that works [11:05:44 CEST] <furq> you only need to fragment for live streaming [11:06:03 CEST] <hendry> how come no vendor streaming company seems to do that? [11:06:10 CEST] <furq> and that's only because the wonderful world of web browsers has left us with no alternative for livestreaming than hls and dash [11:06:25 CEST] <kerio> good old https/ip [11:06:28 CEST] <furq> both of which suck massively compared to actual protocols that aren't just a bunch of http requests [11:06:42 CEST] <furq> but also don't require google and apple to agree on anything [11:06:49 CEST] <kerio> well, http2 is pretty efficient [11:06:50 CEST] <furq> and also firewalls i guess but who cares [11:07:19 CEST] <hendry> maybe there is no DRM solution for a one mp4 approach? Just speculating [11:07:30 CEST] <furq> i have no idea when it comes to drm [11:07:33 CEST] <kerio> hendry: the future of HLS is single fmp4 file with playlist [11:07:47 CEST] <furq> i suspect drm is only supported through dash or rtmp [11:07:55 CEST] <furq> and dash usually uses fragments [11:08:37 CEST] <furq> if you're just doing unencrypted vod then all you need is an mp4 with the right codecs [11:08:57 CEST] <furq> it doesn't even really need to be faststart [11:09:01 CEST] <furq> although it's still better if it is [11:09:06 CEST] <hendry> never knew about "fmp4 files" looks like +faststart 2.0. Does ffmpeg support it? [11:09:16 CEST] <furq> yeah although i forget the flags to mux it [11:09:23 CEST] <hendry> and importantly do major browsers support fmp4? [11:09:28 CEST] <furq> yeah [11:09:45 CEST] <furq> any browser that supports mpeg-dash has to support fmp4 [11:11:01 CEST] <hendry> googling how to generate a fmp4 with ffmpeg and i got https://stackoverflow.com/questions/38227301/transcoding-fmp4-to-hls-while-… (an un-answered question) [11:12:02 CEST] <kerio> can you just keep reading the same fragmented mp4 to play it [11:12:05 CEST] <kerio> or do you still have to refresh the .m3u8 [11:12:12 CEST] <furq> -movflags frag_keyframe+empty_moov [11:12:16 CEST] <furq> apparently [11:12:53 CEST] <furq> you presumably want to use that with the segment muxer [11:13:22 CEST] <thebombzen> not even sure why we care so much about making it so DRM is possible [11:13:28 CEST] <kerio> furq: nou D: [11:13:30 CEST] <kerio> single-file [11:13:39 CEST] <kerio> unless the segment muxer can also make the m3u8 with byteranges [11:13:49 CEST] <furq> shrug [11:14:44 CEST] <thebombzen> streaming DRM has the effect of making it slightly more difficult to grab a stream, and making it a pain in the ass for linux users [11:14:49 CEST] <thebombzen> and not much else [11:15:08 CEST] <furq> i also have opinions that everyone else in the room shares [11:15:23 CEST] <hendry> furq: where did you find that? is there no +faststart additionally there ? [11:15:32 CEST] <furq> no [11:15:47 CEST] <furq> there's no moov atom to move [11:16:02 CEST] <furq> that's a sentence i'm glad i was able to type instead of say [11:17:32 CEST] <hendry> furq: i thought there was a moov atom at the end of a camera produced mp4 in any case [11:17:43 CEST] <furq> well yeah but you're remuxing it [11:17:44 CEST] <hendry> and +faststart simply moves that to the beginning of the file?? [11:18:16 CEST] <furq> you're remuxing it to a format that doesn't have moov atoms [11:18:18 CEST] <kerio> "simply" [11:18:19 CEST] <furq> hence empty_moov [11:18:41 CEST] <furq> it's also not that simple, ffmpeg is dumb so it has to remux it, then write a new moov atom, then rewrite the entire file again with the moov atom at the start [11:18:56 CEST] <furq> which is why it's so much slower than using a dedicated mp4 remuxer which just moves the existing moov atom [11:19:35 CEST] <furq> it's also why you should never run multiple faststart remuxes in parallel on a hard disk [11:19:47 CEST] <furq> unless you really want an inoperable computer [11:19:55 CEST] <hendry> [11:20:08 CEST] <kerio> pleb without a SSD :^) [11:21:11 CEST] <furq> they don't make ssds big enough to fit all my radiohead bootlegs [11:21:31 CEST] <kerio> pls no meanie [11:21:55 CEST] <hendry> furq: good info [11:24:03 CEST] <hendry> but why not use h265 for archival ? surely it's better that h264? :} [11:24:18 CEST] <kerio> can't you just leave enough space for the moov atom at the beginning [11:24:20 CEST] <kerio> and then seek back [11:24:55 CEST] <furq> a ferrari f40 is better than a honda civic, but i wouldn't drive to the shops in one [11:25:18 CEST] <furq> it's probably best if you don't analyse that analogy too much [11:32:24 CEST] <hendry> furq: hokay... just trying to come up with some switches to archive wedding and other footage i take [11:32:50 CEST] <kerio> oh so it's very long-term stuff? [11:32:51 CEST] <hendry> furq: i think i'll adopt your settings and try out -movflags frag_keyframe+empty_moov [11:33:06 CEST] <kerio> wait waht [11:33:07 CEST] <hendry> kerio: guess so, guess i won't touch it in a blue moon [11:33:20 CEST] <kerio> fragmented isobmff is for streaming [11:33:22 CEST] <kerio> not archival [11:33:40 CEST] <hendry> i want it to be Web playback-able, I am planning to keep stuff on S3 [11:33:55 CEST] <hendry> don't want to download the file to quickly see what's there [11:36:59 CEST] <furq> then use faststart [11:37:22 CEST] <furq> if you're just remuxing then don't use ffmpeg at all [11:38:44 CEST] <kerio> if you're just remuxing use ffmpeg [11:38:46 CEST] <kerio> and put your stuff into mkv [11:38:56 CEST] <kerio> praise the matroska [11:39:39 CEST] <furq> well you won't be able to view it in a browser then [11:40:03 CEST] <furq> also if it's off a camera then i assume it's 30000/1001 fps, which matroska doesn't understand [11:40:19 CEST] <kerio> wait, really? [11:40:24 CEST] <furq> yes [11:40:25 CEST] <kerio> how did they fuck it up so bad [11:40:30 CEST] <furq> matroska always uses a timebase of 1/10000 [11:40:36 CEST] <furq> or at least it does with ffmpeg [11:40:36 CEST] <kerio> it's like one of the three most used framerates [11:41:00 CEST] <furq> it's always 1/(10^n) iirc [11:41:09 CEST] <furq> but ffmpeg always uses 10000 [11:41:45 CEST] <furq> that still wouldn't let you accurately store 30000/1001 though [11:43:35 CEST] <hendry> furq: remuxing? that means doing the MOOV bit move right? [11:43:46 CEST] <furq> moving the streams into a new container [11:44:05 CEST] <hendry> furq: i want to make sure the MP4 file from the camera is re-encoded to some sane bitrate and not take too much space [11:44:07 CEST] <furq> if you're actually reencoding then use ffmpeg [11:44:15 CEST] <hendry> furq: and make it playable for the Web [11:45:00 CEST] <furq> just use ffmpeg with faststart then [11:45:10 CEST] <furq> fmp4 is only useful for livestreaming [11:47:58 CEST] <thebombzen> furq: ffmpeg always uses 1000 [11:48:19 CEST] <thebombzen> afaik matroska stores 24000/1001 as 2997/125 [11:54:57 CEST] <kerio> still wrong tho [11:55:38 CEST] <kerio> 1001 is 7*11*13, 125 is a power of 5 [12:25:50 CEST] Action: hendry 's power tripped [12:26:55 CEST] <factor> Has anyone used zmq for swapping different watermarks in realtime? [17:19:24 CEST] <bencc> I have 500MB mp4 file that requires loading 35MB in the browser before starting to play [17:19:38 CEST] <bencc> how can I verify that it has the index in the beginning of the file? [17:19:47 CEST] <BtbN> run qt-faststart on it. [17:20:00 CEST] <BtbN> afterwards, it will [17:20:28 CEST] <furq> you can check with l-smash [17:20:43 CEST] <furq> i've got a sh function somewhere that does it [17:22:31 CEST] <furq> http://vpaste.net/C5Pdg [17:22:45 CEST] <bencc> I'm already using 'movfalgs +faststart': [17:22:48 CEST] <bencc> ffmpeg -nostats -loglevel error -i video.mkv -c:v copy -c:a copy -movflags +faststart -threads 1 video.mp4 [17:22:58 CEST] <furq> well then it does [17:23:00 CEST] <bencc> that's why I want to verify [17:23:18 CEST] <BtbN> just look at the output, it even writes a line about moving it at the end [17:23:35 CEST] <furq> if you really want to doublecheck then boxdumper will do it [17:23:42 CEST] <furq> or maybe atomicparsley or whatever it's called [17:23:48 CEST] <furq> if moov appears before mvhd then it's faststart [17:23:56 CEST] <bencc> furq: looking for boxdumper [17:24:05 CEST] <furq> https://github.com/l-smash/l-smash [17:24:06 CEST] <bencc> what about keyframes? can it make a difference? [17:24:26 CEST] <furq> well yeah if it's downloading 35MB before it plays then it's probably some property of the video stream [17:24:33 CEST] <furq> not sure what that would be though [17:24:50 CEST] <furq> if it wasn't faststart and your httpd doesn't support range requests then it'd have to download the entire thing [17:25:27 CEST] <bencc> this is the part that encodes the video: [17:25:28 CEST] <bencc> -vcodec libx264 -pix_fmt yuv420p -preset:v veryfast -crf 23 [17:25:39 CEST] <furq> shrug [17:25:44 CEST] <furq> maybe it's just your browser's video player filling the cache [17:25:45 CEST] <bencc> should I add a flag to add more keyframes? [17:25:45 CEST] <BtbN> -c:v [17:26:17 CEST] <bencc> BtbN: -c:v instead of -vcodec? [17:26:27 CEST] <furq> that won't make a difference but -vcodec is deprecated [17:26:30 CEST] <BtbN> yes, vcodec is kinda deprecated [17:26:32 CEST] <bencc> ok [17:26:42 CEST] <furq> it's redundant anyway, x264 is the default for mp4 [17:27:10 CEST] <bencc> should I specify keyframe interval? [17:27:18 CEST] <furq> i don't think that'll make a difference [17:27:24 CEST] <BtbN> that won't have any effect on startup time [17:27:28 CEST] <furq> if i had to guess i'd say it was your browser's caching [17:27:32 CEST] <BtbN> it always starts with one for obvious reasons [17:27:44 CEST] <furq> yeah [17:30:36 CEST] <bencc> I think I have the wrong c:a and c:v order: [17:30:37 CEST] <bencc> ffmpeg -nostats -loglevel error -i video.mkv -c:v copy -c:a copy -movflags +faststart -threads 1 video.mp4 [17:30:40 CEST] <bencc> instead of: [17:30:47 CEST] <bencc> ffmpeg -nostats -loglevel error -i video.mkv -c:a copy -c:v copy -movflags +faststart -threads 1 video.mp4 [17:30:54 CEST] <bencc> checking in the command line [17:31:08 CEST] <furq> that makes no difference at all [17:31:12 CEST] <furq> also you can use -c copy [17:31:43 CEST] <bencc> ok [17:34:07 CEST] <furq> some pedant will point this out if i don't amend it, so here it is, even though it's of no consequence [17:34:12 CEST] <furq> http://vpaste.net/xD1Qb [17:34:18 CEST] <furq> thank you for your understanding [17:45:04 CEST] <bencc> this is the structure of the file: [17:45:05 CEST] <bencc> https://pastebin.com/raw/kBq91y6C [17:45:28 CEST] <bencc> moov is between 32061684 and 32061716 [17:45:43 CEST] <bencc> what do I have between ftyp and moov? [17:46:42 CEST] <bencc> why is moov so large? [17:55:24 CEST] <ChocolateArmpits> bencc, your file is long that's why [17:55:35 CEST] <ChocolateArmpits> 4 hour video is about 9-10 megabytes [17:55:42 CEST] <ChocolateArmpits> yours is only 3 megs [17:55:58 CEST] <ChocolateArmpits> you can lower it by using -chunk_duration 1000k [17:58:39 CEST] <bencc> 1000k microseconds? [17:58:52 CEST] <bencc> meaning a chunk_duration of 1 second? [17:58:58 CEST] <ChocolateArmpits> yes [17:59:04 CEST] <bencc> what's the default? [17:59:08 CEST] <ChocolateArmpits> the default is something low so it produces more chunks [17:59:28 CEST] <bencc> will large chunk hurt seeking? [17:59:28 CEST] <ChocolateArmpits> idk exactly, maybe 0.1s [17:59:35 CEST] <ChocolateArmpits> at 1 second not at all [17:59:42 CEST] <bencc> thanks [17:59:44 CEST] <bencc> I'll try it [17:59:53 CEST] <bencc> I'll also decrease the video file [17:59:59 CEST] <ChocolateArmpits> I had not problems and encoded countless hours of material using that [18:00:08 CEST] <bencc> it seems that this specific recording should be 80 minutes instead of 400 mintues [18:00:28 CEST] <bencc> where do I put "-chunk_duration 1000k" ? [18:00:30 CEST] <furq> ChocolateArmpits: that's 32MB [18:00:41 CEST] <bencc> this is my command: [18:00:42 CEST] <bencc> ffmpeg -nostats -loglevel error -i video.mkv -c:a copy -c:v copy -movflags +faststart -threads 1 video.mp4 [18:00:44 CEST] <ChocolateArmpits> furq, what's 32mb? [18:00:52 CEST] <furq> 16:55:42 ( ChocolateArmpits) yours is only 3 megs [18:01:05 CEST] <ChocolateArmpits> aww snap [18:01:11 CEST] <furq> that'd explain it anyway [18:01:52 CEST] <ChocolateArmpits> yeah I've never gotten sizes that large [18:01:53 CEST] <ChocolateArmpits> ever [18:02:32 CEST] <ChocolateArmpits> Maybe it balloons due to storing file address too ? [18:02:49 CEST] <ChocolateArmpits> so the bigger the file the lengthier a chunk reference will be ? [18:03:33 CEST] <furq> i would assume so [18:03:52 CEST] <furq> i was going to recommend remuxing with l-smash but i just checked something i remuxed and the moov is 3MB for 45 minutes [18:04:33 CEST] <furq> i know mp4box lets you set the chunk duration but idk if l-smash does [18:05:33 CEST] <furq> also, fuck anything that outputs help text on stderr [18:07:07 CEST] <furq> aha [18:07:16 CEST] <furq> remuxer --max-chunk-duration=1000 -i foo.mp4 -o bar.mp4 [18:16:47 CEST] <bencc> ChocolateArmpits: where do I put "-chunk_duration 1000k" ? [18:17:13 CEST] <DHE> parameters applying to the input file are specified before the input filename, parameters applying to the output file are specified before the output filename [18:18:11 CEST] <bencc> like this? [18:18:13 CEST] <bencc> ffmpeg -nostats -loglevel error -i video.mkv -c:a copy -c:v copy -chunk_duration 1000k -movflags +faststart -threads 1 video.mp4 [18:20:20 CEST] <furq> that should just be 1000 [18:20:26 CEST] <furq> chunk_duration is in ms [18:21:05 CEST] <bencc> ok [18:21:25 CEST] <bencc> chunk_duration is only for the moov atom? doesn't requre re-encoding? [18:21:50 CEST] <furq> no [18:22:13 CEST] <bencc> no? [18:22:57 CEST] <bencc> no is a confusing answer :) you can understand it as either way [18:23:38 CEST] <DHE> never ask a question containing a negative then. english is stupid that way [18:24:25 CEST] <bencc> this give me the same moov atom size: [18:24:34 CEST] <bencc> ffmpeg -nostats -loglevel error -i video.mkv -c:a copy -c:v copy -chunk_duration 1000 -movflags +faststart -threads 1 out.mp4 [18:25:24 CEST] <bencc> do I need to re-encode? [18:27:01 CEST] <bencc> furq: chunk_duration is in microseconds. I need 1000k after all [18:27:12 CEST] <furq> oh [18:27:14 CEST] <furq> that's stupid [18:27:35 CEST] <bencc> that's clever [18:27:40 CEST] <bencc> it make you think :) [18:27:46 CEST] <bencc> be better at math [18:29:58 CEST] <bencc> what does a 'chunk' means? [18:30:15 CEST] <bencc> is it the time between keyframes? [19:26:44 CEST] <holla> hi there, i have a .ts file containing 3 streams: 0.1 vid h264 / 0.2 audio acc / 0.3 'data' ?? what's data? [19:27:43 CEST] <DHE> could be a number of things. sometimes it's key data used for encrypted transmissions. you see that on some satellite receivers' output [19:28:03 CEST] <DHE> in all likelyhood it's not important as long as the video/audio play correctly [19:29:12 CEST] <furq> data is usually a private stream [19:29:24 CEST] <furq> which could be anything, but is often what DHE said [19:30:54 CEST] <holla> is there a way to track it down? [19:31:33 CEST] <DHE> wireshark might be able to help you if you really really care. dump the raw PMT data [19:31:46 CEST] <DHE> (wireshark filter "mpeg_pmt" I believe) [19:32:04 CEST] <DHE> I still vote for "ignore it" though [19:32:07 CEST] <holla> i already dumped the stream to hdd [19:32:21 CEST] <holla> thought there might be something interesting in it [19:32:38 CEST] <holla> but it doesn't seem to be a subtitle, as far as i can say [19:33:00 CEST] <DHE> load wireshark. File, Open, and select this .ts file [19:33:02 CEST] <furq> subtitle streams should be detected properly [19:33:37 CEST] <furq> unless this is atsc in which case they're muxed into the video stream in some fucked up way [19:33:52 CEST] <furq> either way it wouldn't be in a private stream [19:34:01 CEST] <holla> can i dump just that stream? ffmpeg -i foo.ts -map 0:3 out_stream3.suf [19:34:06 CEST] <DHE> a53 closed captions for teh win! [19:34:18 CEST] <furq> yeah i'm glad dvb doesn't do that [19:34:29 CEST] <DHE> holla: are you gonna run wireshark or not? [19:34:32 CEST] <furq> and also that i'm not deaf so i don't care about subtitles anyway [19:34:56 CEST] <DHE> furq: they're nice when you're in an office and have to keep the TV muted [19:35:05 CEST] <holla> actually i don't have it installed on that box iirc - but i could do [19:35:08 CEST] <furq> i guess [19:36:48 CEST] <QH> Hi. Does anyone know where I can get hold of the ffmpeg-20160712-df1dc52-win32-static release of ffmpeg? I know it's now unsupported, but the binaries are useful to me. [19:37:06 CEST] <furq> windows xp is it [19:37:18 CEST] <QH> Vista [19:37:31 CEST] <DHE> oh god I'm sor sorry [19:37:37 CEST] <furq> doesn't look like it's in https://ffmpeg.zeranoe.com/builds/win32/static/ [19:37:56 CEST] <furq> fyi the reason newer builds don't work is because of libmfx [19:38:06 CEST] <furq> if you build it yourself without libmfx then it'll work on <7 [19:38:45 CEST] <QH> Zeranoe tweeted in December "ffmpeg-20160712-df1dc52-win32-static used to be downloaded a lot before it was removed, and I'd like to know what was downloading it." It is apparently the last version supported in XP and Vista. [19:39:27 CEST] <QH> Is there a version already compiled without libmfx? I've never compiled anything before so wouldn't know where to start. [19:39:48 CEST] <c_14> If I remember correctly "a lot" was many many terabytes of bandwidth [19:40:14 CEST] <QH> Ah, so it was a spike? [19:40:37 CEST] <c_14> probably some scripts downloading the release every time for something instead of downloading it once and then keeping a local copy [19:45:25 CEST] <ChocolateArmpits> QH, what about getting a slightly older release? [19:46:12 CEST] <furq> zeranoe isn't hosting any which predate libmfx [19:46:26 CEST] <QH> I have an older release that came with a previous version the software I'm trying to use it with, but I wouldn't mind having the latest version that would work. [19:47:16 CEST] <QH> (mainly because the software has been updated to use a version I can't use on Vista) [19:56:17 CEST] <QH> Out of interest, if libmfx causes ffmpeg to not work on XP, Vista and other older Windows versions, why not create a fork to the main project to compile without it? Or use another library? Or is the library so vital that it shouldn't be compiled without it in case it breaks more? [19:58:58 CEST] <furq> the zeranoe builds aren't official [19:59:40 CEST] <BtbN> Why make an effort to support a dead OS? [20:01:45 CEST] <ChocolateArmpits> Not for support, so older machines could also enjoy ffmpeg [20:02:38 CEST] <QH> According to a number of news sites, versions of Windows prior to 7 seem to still be popular - especially when a particular piece of malware hit the news headlines more recently. But it seems a simple suggestion of "build it yourself without libmfx then it'll work on <7" sounds like supporting many, many additional users isn't onerous. [20:02:43 CEST] <furq> libmfx isn't vital at all, it's for hardware encoding on newer intel cpus [20:02:49 CEST] <furq> you could ask zeranoe to make builds without it [20:02:54 CEST] <furq> i suspect you wouldn't be the first to ask him though [20:04:00 CEST] <BtbN> I can totally understand why devs don't want to invest time to support 15 year old systems [20:04:03 CEST] <BtbN> if it happens to work, fine [20:04:30 CEST] <QH> So if I wanted to send a message to either the official project team or Zeranoe (without Twitter), how would I go about it? Is there an email address or web form? [20:06:16 CEST] <BtbN> A build you downloaded somewhere from the internet is in no way official [20:06:20 CEST] <BtbN> there are no official binaries [20:06:35 CEST] <furq> yeah it has nothing to do with the ffmpeg devs [20:06:45 CEST] <furq> zeranoe comes in here sometimes, idk how else to contact him [20:06:45 CEST] <BtbN> And the official standpoint is that no efforts will be made to support unsupported versions of Windows. [20:06:53 CEST] <furq> like i said, i'm pretty sure he's been asked this before [20:07:12 CEST] <BtbN> it won't be sabotaged either, but will break more and more eventually [20:09:26 CEST] <QH> Well, it looks like my next steps are to find out how I compile ffmpeg source code, then get a copy of the source and compile it without the library. [20:09:48 CEST] <ChocolateArmpits> QH, using msys2 is probably the most straightforward approach [20:09:51 CEST] <BtbN> or stop using an OS that doesn't receive security updates anymore [20:10:22 CEST] <QH> @BtbN - that is definitely not the answer. I asked how to obtain for the OS, not change my OS. [20:11:01 CEST] <ChocolateArmpits> I think workplaces carry a lot of XP hardware, so for more simpler tasks a supported binary would be more optimal than throwing out the machines [20:11:48 CEST] <BtbN> Keeping to use XP or Vista, which do not get security updates, is highly risky and generally a really bad idea [20:12:25 CEST] <QH> @BtbN - This is not a debate on the suitability of an OS I have no control over changing. [20:20:12 CEST] <QH> @ChocolateArmpits - Thanks for your help. I've taken a quick look at msys2 and it seems simple enough, even if I end up only using it for this one task. [20:22:10 CEST] <ChocolateArmpits> QH, just know that if you want to use the binaries outside of msys you'll have to carry all dependent dlls with the ffmpeg binary. [20:23:11 CEST] <QH> Thanks, I'll remember that. [20:25:15 CEST] <BtbN> msys dropped XP support btw. [20:25:25 CEST] <BtbN> binaries built with it no longer run on XP [20:25:32 CEST] <QH> I'm using Vista, so that should be fine. [20:26:07 CEST] <BtbN> I think the last compiler to still support it is msvc, and even there you need to select a special xp toolchain [21:22:00 CEST] <holla> ffmpeg -i IN.ts -map data-re -codec copy -f data OUT.data [21:22:13 CEST] <holla> ^^ output file is empty [21:22:47 CEST] <holla> so there's nothing in that 3rd stream, or is sth wrong with my command? [21:23:59 CEST] <DHE> never answered my question. did you open it in wireshark? [21:24:35 CEST] <BtbN> need to get it out of the .ts for that first [21:24:53 CEST] <DHE> no [21:25:11 CEST] <DHE> wireshark opens and parses mpegts directly [21:27:10 CEST] <holla> DHE: i had to install wireshark first, but i did. it stuck at some 20% and finally crashed :( [21:27:20 CEST] <DHE> too big? [21:27:25 CEST] <holla> maybe [21:27:37 CEST] <holla> 5gb [21:27:53 CEST] <DHE> oh dear... okay. can you truncate the file to, say, 100 megabytes and try again? (make a copy obviously) [21:28:38 CEST] <holla> of course - came to my mind just as i wrote to you ;) [21:29:13 CEST] <holla> but how about my line? shouldn't it extract the data stream as well? [21:31:55 CEST] <DHE> I don't know. what I'm suggesting is to use wireshark to examine the PMT directly and find out what type it is listed to have and what the stream descriptors say (if anything) [21:32:59 CEST] <holla> fyi, ffmpeg -i IN.ts -t 00:05.00 -codec copy OUT.ts says video:24436kb audio:74665kb subtitle: 0kb other streams: 0kb [21:33:23 CEST] <holla> so, it really seems like there's nothing in there [21:33:47 CEST] <holla> but i'll now feed the cut to wireshark [21:34:42 CEST] <BtbN> ffmpeg will most likely drop unknown data streams in a remux [21:34:48 CEST] <BtbN> just cut the first 100MB of the file [21:35:15 CEST] <holla> wireshark 's up now - where to look at? [21:35:32 CEST] <DHE> put the filter "mpeg_pmt" into the filter text box at the top and hit Apply [21:37:10 CEST] <holla> done. next? [21:37:26 CEST] <DHE> click a chunk entry in the top. then expand the PMT info in the bottom. then expand the Stream fields. eg: "Stream PID=0x0420" [21:37:49 CEST] <DHE> each one is one of the streams ffmpeg reports. [21:37:57 CEST] <DHE> eg: "Stream type: AVC video stream as defined in ITU-T Rec. H.264 | ISO/IEC 14496-10 Video (0x1b)" # this means H.264 video in this stream [21:38:55 CEST] <holla> what i see is iso/iec 13818-1 pid=0x1000 cc=0 [21:39:24 CEST] <DHE> next noe is MPEG Program Map Table. that's the PMT [21:39:27 CEST] <DHE> *next one [21:41:20 CEST] <holla> i can't see anything in there which might identify that data? [22:12:04 CEST] <dejdo> good evening everyone [22:12:38 CEST] <dejdo> i am trying to draw text on video i am streaming from a uvc camera through ffserver, without success [22:17:11 CEST] <dejdo> https://pastebin.com/iKu3aeXa [22:17:43 CEST] <dejdo> when i'm streaming the -vf drawtext gets ignored. what am i doing wrong? [22:20:15 CEST] <BtbN> you are very unlikely to find any help with ffserver related things, it's unmaintained and essentially dead. [22:21:33 CEST] <dejdo> erm uh, thats bad news. any alternatives? How the good people stream webcameras nowadays? [22:22:48 CEST] <DHE> I have a webcam running with HLS output, plus HLS.js for playing [22:25:30 CEST] <DHE> ffmpeg converts from rtsp to HLS, obviously [22:26:01 CEST] <dejdo> thanks (noises of frantic googling in the background) [22:26:20 CEST] <BtbN> Or just use nginx rtmp [22:26:57 CEST] <DHE> I stick with HLS out of personal expertise with it and a relative minimal of software required. [22:27:27 CEST] <BtbN> it's pointless delay if you don't need it for browser playback [22:28:17 CEST] <DHE> if you need close to realtime, yes you're right. if you don't, + [22:28:42 CEST] <dejdo> thanks for both of you, i'll look into nginx/rtmp/ffmpeg. I would like to be it close to realtime. [22:29:01 CEST] <DHE> then nginx-rtmp will be the better choice. HLS tends to have long delays, like 10-20 seconds [22:30:53 CEST] <dejdo> thanks. [22:31:04 CEST] <BtbN> it has quite exactly 3*segment_length of delay [22:31:44 CEST] <dejdo> that sounds nice. [22:32:41 CEST] <DHE> maybe, but I would suggest a segment size of around 5 seconds (4-8 range would be my personal preference) hence the 10-20 second delay I mentioned earlier [22:33:30 CEST] <dejdo> but this is for another day, it's quite late here. Asked because of final desperation. [22:33:39 CEST] <BtbN> Twitch uses 2 seconds now, and is pretty much at 6-7 seconds of delay [22:33:45 CEST] <BtbN> they put quite a lot of work into that [22:33:57 CEST] <DHE> wow, that's pretty aggressive [22:35:01 CEST] <BtbN> it's also quite a quality hit due to the small gop [22:49:23 CEST] <DHE> is 60 frames (assuming 30fps) really that bad for quality on h264? [22:50:14 CEST] <BtbN> well, the longer between I frames the better [22:51:02 CEST] <kazuma_> why btbn? [22:51:21 CEST] <BtbN> Because they are big and steal bits [22:51:29 CEST] <DHE> kazuma_: keyframes are large negatively affecting bitrate. and h264 doesn't support from quality deterioration from long periods without keyframes (older mpeg codecs did) [22:51:49 CEST] <kazuma_> ahh ok [22:52:17 CEST] <kazuma_> i assumed less i-frames = picture degradation and encoding artifacts [22:52:31 CEST] <DHE> this is true for mpeg4 part2 (aka Xvid or divx) [22:52:36 CEST] <DHE> but h264 does not [22:52:39 CEST] <kazuma_> cool [22:54:49 CEST] <DHE> I'm curious if there's some point of diminishing returns where paying the bitrate penalty for a keyframe isn't a serious concern for quality [22:55:15 CEST] <BtbN> no [22:55:49 CEST] <BtbN> for applications that can do that, you only send one I frame in the beginning, and then never again, or only on request because of a dropped package [23:00:27 CEST] <DHE> hmm.. yeah I suppose that makes sense... [23:01:45 CEST] <DHE> I mean in the sense of "no". I can't make use of 'smart' recovery [00:00:00 CEST] --- Mon Jun 12 2017

1 0

ffmpeg-devel.log.20170610
by burek 11 Jun '17

11 Jun '17

[00:01:27 CEST] <mateo`> is there is a way to disable the automatic insertion of the bsf by an option for example, we can let the user do that when they use MediaCrypto [00:01:56 CEST] <wm4> you could provide separate AVCodec entries [00:02:10 CEST] <wm4> so you could feed them whatever brainfucked packet data they have [00:04:42 CEST] <mateo`> so we would have h264_mediacodec and h264_mediacodec_nobsf_drm_whatever, right ? [00:06:57 CEST] <wm4> yes [00:07:20 CEST] <wm4> "shit" is shorter than "nobsf_drm_whatever", so I suggest that as name [00:08:10 CEST] <jamrial> or just h264_mediacrypto, so users actually know what's being used :p [00:08:51 CEST] <mateo`> h264_mediacryptoshit then :) [00:09:01 CEST] <JEEB> :) [00:09:25 CEST] <JEEB> oh [00:09:27 CEST] <JEEB> https://github.com/android-ndk/ndk/issues/382 [00:09:29 CEST] <JEEB> maybe related? [00:09:34 CEST] <mateo`> well, i'm sold, i'll port the mediacodec wrapper to the auto-bsf insertion [00:10:28 CEST] <JEEB> although mateo` - you say r14b WorksForYou? [00:11:22 CEST] <mateo`> JEEB: yes r14b works for me, and we don't use the NDK API (at least directly) [00:11:49 CEST] <JEEB> ok [00:11:58 CEST] <JEEB> I will give r14b a fly after I get some sleep [00:49:32 CEST] <cone-524> ffmpeg 03Michael Niedermayer 07master:4bcde26172ba: avcodec/dvbsubdec: Use av_image_check_size2() [00:49:32 CEST] <cone-524> ffmpeg 03Michael Niedermayer 07master:e1b0044c2347: avcodec/dvbsubdec: Check pixel buffer size constraint from ETSI EN 300 743 V1.3.1 [00:49:32 CEST] <cone-524> ffmpeg 03Michael Niedermayer 07master:09096fb68713: avcodec/h264_parse: Check picture structure when initializing weight table [00:57:29 CEST] <J_Darnley> the amount of nested ifs and && and || in idctdsp_init is horrible [01:45:09 CEST] <J_Darnley> Now how did fate not catch that bug? I set idct_put to an idct_add function. [02:28:01 CEST] <KGB> [13FFV1] 15michaelni pushed 2 new commits to 06master: 02https://git.io/vHDGJ [02:28:01 CEST] <KGB> 13FFV1/06master 140ba8a4c 15Dave Rice: expanding on median predictor section... [02:28:01 CEST] <KGB> 13FFV1/06master 149fc9544 15Michael Niedermayer: Clarify where t,l,tl,tr come from.... [09:36:55 CEST] <hanna> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b378f5bd640 does anybody have an example of a file that includes such metadata? [09:37:13 CEST] <hanna> I want to work on mpv's implementation of MaxCLL/MaxFALL and HDR10, but I can't seem to find a test clip [13:17:06 CEST] <J_Darnley> kierank, BBB, atomnuker: after some more work I think I have managed to speed up decoding of a real mpeg2 HD sample from 215 to 235 fps [13:17:16 CEST] <BBB> sweet [13:17:21 CEST] <BBB> with the idct? [13:17:28 CEST] <J_Darnley> Yes [13:17:35 CEST] <JEEB> coolio [13:17:48 CEST] <nevcairiel> almost 10% jus from idct sounds quite neat [13:18:37 CEST] <J_Darnley> I will send an intermediate series of patches because I still need to make a small optimisation by making a large change to the macros in that file. [13:27:18 CEST] <cone-161> ffmpeg 03Michael Bradshaw 07master:50be8f214250: fate: add test for -time_base option [13:29:21 CEST] <kierank> J_Darnley: nice [13:29:42 CEST] <kierank> this is without any sse specific optimisations, right? [13:29:50 CEST] <kierank> I have lost track a bit tbh [13:42:01 CEST] <kierank> We need a newsletter called "weekly ffmpeg drama updates" [13:45:13 CEST] <J_Darnley> :) [13:45:57 CEST] <J_Darnley> You mean early termination for 0 coeffs, right? No. it still none of those. [13:48:06 CEST] <BtbN> Has anyone ever successfully built this new "mysofa" dependency? [13:48:11 CEST] <BtbN> I can't get it to build no matter what [13:48:44 CEST] <JEEB> someone said only the git HEAD or something works [13:48:52 CEST] <BtbN> that's what I'm using [13:49:02 CEST] <JEEB> sounds like fun [13:49:10 CEST] <BtbN> https://bpaste.net/show/e7e1c7e1d347 [13:49:31 CEST] <RiCON> BtbN: i did in mingw, only in static [13:49:58 CEST] <BtbN> this is Linux, Ubuntu 17.04. Just plain cd build, cmake .., make [13:50:58 CEST] <RiCON> i used -G ninja, didn't try with make [13:51:20 CEST] <BtbN> it looks like messed up dependencies to me [13:53:30 CEST] <kierank> J_Darnley: yeah [13:53:43 CEST] <kierank> J_Darnley: i am also trying to understand the SUINT thread [13:53:56 CEST] <kierank> this week has been too full of IRL drama (uk politics) as well [13:54:24 CEST] <BtbN> yeah, it works if I manually make mysofa-static first, and then make [13:55:10 CEST] <RiCON> BtbN: -DBUILD_TESTS=no also works [13:55:23 CEST] <BtbN> yeah, guess I don't need them [13:56:07 CEST] <BtbN> https://github.com/hoene/libmysofa/blob/master/src/CMakeLists.txt#L35 [13:56:08 CEST] <BtbN> this [13:56:10 CEST] <BtbN> this is bullshit [13:58:00 CEST] <RiCON> lol [13:58:18 CEST] <RiCON> https://github.com/hoene/libmysofa/pull/11/files [13:58:29 CEST] <RiCON> looks like he doesn't too hard on PRs [13:58:31 CEST] <RiCON> look+ [13:58:39 CEST] <BtbN> it was broken before the PR [13:58:41 CEST] <BtbN> the PR just moved it [13:58:49 CEST] <BtbN> https://github.com/hoene/libmysofa/pull/11/files#diff-95e351a3805a1dafa85bf… [13:58:50 CEST] <RiCON> oh, right [13:59:08 CEST] <BtbN> I can't think of a sane reason for that [13:59:10 CEST] <BtbN> gonna PR a fix [14:19:13 CEST] <BBB> J_Darnley: patch sounds good to me [15:34:10 CEST] <BtbN> I don't understand what's going on with the coverity container. The moment I update it to the latest Ubuntu or Debian, the build just freezes [15:36:46 CEST] <J_Darnley> "I'm afraid I can't let you use software that new, Dave." [15:36:59 CEST] <BtbN> But which software? [15:37:05 CEST] <BtbN> It works on 16.10, and that also uses gcc-6 [15:37:23 CEST] <J_Darnley> Sorry, I really have no idea. [15:37:35 CEST] <BtbN> oh, nevermind. It continued [15:37:39 CEST] <JEEB> :) [15:37:44 CEST] <BtbN> After like 10 minutes of sitting on the first 4 files [15:38:00 CEST] <BtbN> I guess it downloaded stuff in the background or something [15:52:52 CEST] <BtbN> wow, it spends like 10 minutes on stripping all the binaries. I know what I'm going to disable to save some build time [15:53:21 CEST] <BtbN> hm, I wonder, can I disable linking? As stupid as it sounds. [16:47:35 CEST] <BtbN> --ld=/bin/true will probably do the trick [16:47:49 CEST] <BtbN> at least I hope so [16:47:52 CEST] <cslcm> that's bad and you should feel bad [16:48:06 CEST] <BtbN> why? I just don't want or need to link [16:48:08 CEST] <BtbN> only compile [16:48:16 CEST] <cslcm> it's correct, it's just dirty [16:48:22 CEST] <BtbN> better idea? [16:49:25 CEST] <cslcm> there's gotta be a compile only thing for cmake [16:54:42 CEST] <BtbN> ffmpeg does not use cmake [16:56:21 CEST] <BtbN> libavformat/network.c:234:5: error: implicit declaration of function 'closesocket' [-Werror=implicit-function-declaration] [16:56:22 CEST] <BtbN> what? [16:56:33 CEST] <BtbN> How does using /bin/true as LD trigger that? [16:57:05 CEST] <BtbN> oh, I guess because It breaks configure... [16:57:58 CEST] <JEEB> :D [17:04:05 CEST] <BtbN> sed -i on ffbuild/config.mak after configure! [20:58:31 CEST] <cone-504> ffmpeg 03Michael Niedermayer 07master:54aaadf64807: avcodec/cfhd: Check band parameters before storing them [20:58:31 CEST] <cone-504> ffmpeg 03Michael Niedermayer 07master:90e8317b3b33: avcodec/flicvideo: Fix runtime error: signed integer overflow: 4864 * 459296 cannot be represented in type 'int' [21:28:22 CEST] <ubitux> looks like ff_ps_stereo_interpolate_neon is broken on arm [21:32:09 CEST] <jamrial> ubitux: have access to an arm board, or using qemu? [21:32:30 CEST] <ubitux> i'm testing on an arm board right now [21:32:42 CEST] <ubitux> i have a bunch of them in 32-bit [21:32:54 CEST] <ubitux> it's a decent 64-bit one i'm in need currently [21:32:58 CEST] <uau> hmm wtf does that srt_to_ass() conversion function do with the persistent "an" variable anyway? it looks as if it was letting arbitrary {\foo} tags through but only between the first {\aN} and second??? [21:33:12 CEST] <uau> ubitux: you've at least touched that code, do you have any idea what it's supposed to do? [21:34:45 CEST] <ubitux> arbitrary positioning [21:34:52 CEST] <ubitux> is there something broken with it? [21:35:03 CEST] <ubitux> (wouldn't be a surprise tbh) [21:35:48 CEST] <uau> well what i meant above is that it seems to be letting _any_ ASS tag whatsoever through between {\a1} etc tags [21:36:56 CEST] <uau> what is the purpose of the "an" variable there supposed to be? [21:37:44 CEST] <ubitux> check the comments [21:38:01 CEST] <ubitux> an5 is when the positioning is defined through a rectangle (so it's centered in it) [21:38:15 CEST] <ubitux> and an1 happens when only 1 coordinate is given [21:38:21 CEST] <ubitux> so it's aassuming top-left corner [21:39:18 CEST] <uau> which comment? if you mean the "skip all {\xxx} substrings except for {\an%d} and all microdvd like styles such as {Y:xxx}" one, I don't see how it'd match the code [21:40:55 CEST] <ubitux> wait [21:41:04 CEST] <ubitux> what code are you talking about? [21:41:17 CEST] <ubitux> aren't you refering to lavc/srtdec.c:srt_to_ass() ? [21:42:10 CEST] <ubitux> ah you are in ff_htmlmarkup_to_ass? [21:42:33 CEST] <uau> yes i guess i used the wrong name due to looking at its history [21:42:48 CEST] <ubitux> so you're looking at the an sscanf? [21:43:03 CEST] <uau> yes, and specifically why the code keeps that "an" variable [21:43:05 CEST] <ubitux> yeah i didn't write that code, i think it ages from aurelien after i wrote it in mplayer [21:43:45 CEST] <ubitux> yeah so it's skiping ASS tags present in srt [21:44:17 CEST] <ubitux> and the \an ones are relatively common in srt [21:44:24 CEST] <ubitux> so i think that's the rational behind this [21:45:19 CEST] <uau> yeah, the "skip all {\xxx} substrings except for {\an%d} and all microdvd like styles such as {Y:xxx}" comment mostly makes sense - but i don't see how the behavior of the code would quite match that, and why the "an" variable... [21:46:30 CEST] <ubitux> so an var counts the number of expected an... [21:46:45 CEST] <ubitux> let me try to understand.. [21:47:20 CEST] <ubitux> ok [21:47:26 CEST] <ubitux> i think it's just skipping the first one [21:47:37 CEST] <ubitux> but if there is one in the middle it's assuming it's really wanted? [21:48:07 CEST] <ubitux> wait no [21:48:30 CEST] <ubitux> omfg that len = 0 in the middle [21:50:55 CEST] <ubitux> uau: yeah i guess it honors only the first one [21:51:02 CEST] <ubitux> i think that's it [21:51:13 CEST] <uau> i'm trying to think of what kind of stupidity could result in that code if the effect is not intentional [21:51:35 CEST] <uau> my best guess i that the intent of the persistent variable was to only copy the first {\an [21:51:43 CEST] <ubitux> what you comonly see is an {an} tag at the begining of every subtitle event [21:51:48 CEST] <durandal_1707> atomnuker: have you written filter? [21:51:51 CEST] <kierank> J_Darnley: maybe you should push your changes [21:51:54 CEST] <kierank> and then improve later [21:52:01 CEST] <durandal_1707> push [21:52:15 CEST] <durandal_1707> better than suint [21:52:22 CEST] <uau> and that aurelien missed that it would also allow any OTHER tags while the variable stays at 1 [21:52:32 CEST] <kierank> durandal_1707: can you explain suint drama to me [21:52:41 CEST] <ubitux> uau: so basically i think he wanted to honor subtitles with a "global" alignment at every event, and then ignore any alignment in the middle which would probably be very "ass specific" [21:52:59 CEST] <ubitux> (or anything else ass specific) [21:53:02 CEST] <ubitux> that's my guess [21:53:18 CEST] <ubitux> feel free to rework this [21:53:25 CEST] <durandal_1707> kierank: no, its plan to make ffmpeg code one big mpegvideoenc [21:53:36 CEST] <ubitux> i really don't like that these tags honored at all [21:53:39 CEST] <kierank> durandal_1707: ? [21:54:01 CEST] <durandal_1707> kierank: makes code hard to follow [21:54:13 CEST] <kierank> I agree, i just don't understand what it solves [21:54:21 CEST] <kierank> why not just make it unsigned [21:54:27 CEST] <durandal_1707> and now those weird timeouts [21:54:31 CEST] <ubitux> jamrial: http://sprunge.us/ibaT [21:54:38 CEST] <ubitux> jamrial: do you think these mismatch are legit? [21:54:41 CEST] <durandal_1707> want to make code worse [21:54:55 CEST] <ubitux> jamrial: like, they fail with an eps > 0.01... [21:54:59 CEST] <iive> kierank: some operations need a signed type to work properly, e.g. shifts [21:55:12 CEST] <jamrial> ubitux: try FLT_EPSILON instead [21:55:18 CEST] <jamrial> include <float.h> for it [21:55:22 CEST] <durandal_1707> iive: it just teory [21:55:23 CEST] <iive> kierank: and you need other operations as unsigned to avoid undefined behavior [21:55:33 CEST] <ubitux> jamrial: FLT_EPSILON is really really low [21:55:44 CEST] <ubitux> 0.01 is extremely large [21:55:49 CEST] <ubitux> and it's still mismatching [21:55:54 CEST] <iive> there are 2 gcc options that control how gcc generates code for signed overflow [21:55:59 CEST] <uau> kierank: my understanding is that michael's use case for SUINT is variables that should not ever overflow to get different behavior in different builds in error cases where they DO overflow [21:56:05 CEST] <iive> one makes it handle it as unsigned overflow. [21:56:19 CEST] <iive> this however might make some code slower, e.g. simple loops [21:56:28 CEST] <kierank> uau: i still don't get it [21:56:46 CEST] <kierank> they overflow, we fix, ??? [21:56:54 CEST] <iive> the other option makes signed overflow a fatal error, that would terminate the program [21:56:57 CEST] <kierank> or is this for some kind of overflow accumulation? [21:56:59 CEST] <uau> if you make them unsigned that means there is in undefined behavior even if they do overflow (whether nominally avoiding undefined behavior is actually an improvement over overflow depends, i guess...) [21:57:25 CEST] <kierank> ok [21:57:43 CEST] <uau> but on the other hand he wants to keep them signed because some tooling specifically checks for cases of signed behavior as that indicates bugs [21:57:45 CEST] <kierank> makes more sense [21:58:07 CEST] <kierank> hmm [21:58:30 CEST] <uau> so he wants to run fuzzing or other tests under builds that have those variables signed and with extra checks that detect when signed overflow happens [21:59:15 CEST] <atomnuker> durandal_1707: partly, I don't do anything with the FFT coeffs currently [21:59:54 CEST] <atomnuker> I plan to reuse the ffopus transient detector but tweak it to detect quiet spots and use them as a noise signature [22:00:24 CEST] <jamrial> ubitux: 0.01 or 0.001? the test in your branch has the latter [22:00:28 CEST] <atomnuker> (and make it update the noise signature on the next quiet spot) [22:00:50 CEST] <ubitux> jamrial: yeah i reduced even more, but look at the paste [22:00:57 CEST] <ubitux> there is a clear mismatch > 0.01 [22:01:10 CEST] <ubitux> 0.001 is already pretty high.. [22:01:46 CEST] <jamrial> floatdsp uses 0.005 and 0.008 for some tests [22:02:17 CEST] <jamrial> but yeah, you're right about that paste [22:02:41 CEST] <jamrial> wonder why none of the aac tests fail then [22:03:10 CEST] <jamrial> but then again, the ipdopd test didn't even notice i fucked up one instruction... [22:06:27 CEST] <jamrial> ubitux: wonder if replacing vmla with vmul + vadd would help [22:06:44 CEST] <jamrial> multiply add accumulate tends to be less precise. at least on x86 [22:07:43 CEST] <Gramner> fma is more accurate than mul+add on x86 since it doesn't do intermediate rounding [22:08:49 CEST] <jamrial> really? odd, i remember it as the opposite [22:08:55 CEST] <Gramner> assuming accurate means "as close to infinite precision as possible" and not "as close to IEEE 754 rounding as possible" [22:10:01 CEST] <Gramner> C code does the latter, so it will differ more from C [22:15:07 CEST] <Gramner> "VFMADD132PS: Multiplies [...], adds the infinite precision intermediate result [...], performs rounding and stores [...]" [22:15:16 CEST] <Gramner> from the intel manual [22:17:58 CEST] <jamrial> ok, that's cool [22:33:09 CEST] <jamrial> ubitux: can you test https://pastebin.com/5iyDhRS7 on arm while at it? [22:35:31 CEST] <jamrial> the arm neon version of hybrid_synthesis_deint probably only works with a few values of i (the ones the decoder explicitly uses) [22:35:58 CEST] <jamrial> so making the test try everything from 0 to 63 will probably fail [22:41:14 CEST] <ubitux> jamrial: i'll try that later yeah [22:41:22 CEST] <ubitux> we should probably start merging the checkasm tests btw [22:41:27 CEST] <ubitux> since you're already working on top [22:42:16 CEST] <jamrial> i wrote an x86 version of hybrid_synthesis_deint, btw [22:43:24 CEST] <jamrial> but like with the arm version i kept in mind that aacdec always sets len to 32, and i to either 3 or 5 [22:43:43 CEST] <jamrial> it saved me a bunch of instructions and register use [22:45:00 CEST] <jamrial> making it work for any value of len and any value of i shouldn't be hard, but probably not worth it [22:50:42 CEST] <Gramner> if a value is hardcoded it'd probably be better to actually hardcode it instead of having it as a parameter that doesn't work [22:51:54 CEST] <jamrial> i guess. if someone can adapt the arm version then it could be done [00:00:00 CEST] --- Sun Jun 11 2017

1 0

ffmpeg.log.20170610
by burek 11 Jun '17

11 Jun '17

[00:05:41 CEST] <Tatsh> well, it makes sense that if you affect top, you also have to change bottom [00:20:11 CEST] <kode54> how do I fix a wrong or different codec id in an MP4 video? [00:20:31 CEST] <kode54> I have an HEVC video with the codec id "hev1", but my player wants it to be "hvc1" [00:20:49 CEST] <BtbN> fix your player? [00:20:59 CEST] <kode54> love to, but it's OS provided [00:21:09 CEST] <furq> -vtag hvc1 [00:21:13 CEST] <tdr> find a better os ;) [00:21:15 CEST] <BtbN> Tatsh, not really, it should just work. [00:21:26 CEST] <BtbN> It removes from the display area [00:21:34 CEST] <BtbN> there really should be no green showing up anywhere [00:21:35 CEST] <kode54> it's a fully baked os, so they tell me [00:22:08 CEST] <kode54> that, or it's choking on my 5.1 AAC audio [00:22:12 CEST] <kode54> I'll try removing the audio first [00:22:13 CEST] <tdr> "baked" as in "left in the smokehouse with 50 lbs of burning weed" [00:22:18 CEST] <BtbN> Tatsh, keep in mind that you can only crop multiples of two [00:22:33 CEST] <furq> actually vtag might be ftyp with mp4 [00:22:41 CEST] <BtbN> if you crop an uneven amount of pixels, you will end up with weird rounding [00:23:07 CEST] <BtbN> Can totally see a single green line happening in that case [00:23:50 CEST] <kode54> copying the video to MP4 file, to see if it was just the audio it choked on [00:23:52 CEST] <furq> oh, no it isn't [00:23:58 CEST] <furq> -vtag should work [00:24:41 CEST] <kode54> that gives me a lovely error, the vtag switch [00:24:42 CEST] <kode54> [mp4 @ 0x7fc607809a00] Tag hvc1 incompatible with output codec id '174' ([35][0][0][0]) [00:24:43 CEST] <kode54> Could not write header for output file #0 (incorrect codec parameters ?): Invalid data found when processing input [00:24:50 CEST] <furq> fun [00:24:57 CEST] <kode54> same if I use hev1 [00:25:21 CEST] <kode54> video was created with Handbrake, back when they first added HEVC support [00:33:18 CEST] <kode54> oh [03:39:37 CEST] <kode54> { AV_CODEC_ID_HEVC, MKTAG('h', 'e', 'v', '1') }, /* HEVC/H.265 which indicates parameter sets may be in ES */ [03:39:37 CEST] <kode54> { AV_CODEC_ID_HEVC, MKTAG('h', 'v', 'c', '1') }, /* HEVC/H.265 which indicates parameter sets shall not be in ES */ [03:39:52 CEST] <kode54> how do I convert between the two without transcoding the whole video stream? [03:40:16 CEST] <kode54> or is that just an encode time choice? [03:41:33 CEST] <kode54> aha [03:41:34 CEST] <kode54> 'hvc1' stores SPS/PPS in a specific avcC box while 'hev1' stores SPS/PPS inband. It does not change the stream itself, it separates the metadata from the data (which is a key element of ISOBMF). [05:23:02 CEST] <Coburn> Greetings, just wondering if it's possible to use ffmpeg to act as a "server" which will take a stream from my computer and split it to two endpoints. [05:23:50 CEST] <Coburn> For example, Computer -> FFMpeg Instance listening on specific port -> Simulcast on Twitch/YouTube, etc [05:24:16 CEST] <Coburn> I looked at ffserver but it seems that it's more for streaming files that already exist, rather than listening for a connection and streaming that [05:25:09 CEST] <Coburn> It may not be possible to do what I want, but I thought I'd ask so I could potentially be streaming on both YouTube and Twitch at the same time, rather than having to upload two seperate streams on my PC. I'd let a nearby VPS in a datacenter do the re-encoding and stuff [05:32:20 CEST] <klaxa> Coburn: afaik twitch and youtube use rtmp, you can just specify two outputs for ffmpeg, one for twitch and one for youtube [05:33:10 CEST] <thebombzen> Coburn: you can do that yes, and the stream URLs for ffmpeg and twitch use rtmp as klaxa said [05:34:38 CEST] <thebombzen> Coburn: one way to do that would be to do something like encode your stream as an mpegts. then you could do: ffmpeg -f mpegts -i - -map 0 -c copy rtmp://youtube_url -map 0 -c copy rtmp://twitch_url [05:35:33 CEST] <thebombzen> this will read from standard input. alternatively, ffmpeg could read from a UDP stream, like ffmpeg -f mpegts -i udp://localhost:blah and then have your mpegts stream to go the udp port [05:36:06 CEST] <thebombzen> however you choose to feed the data to ffmpeg, the general command structure would be "ffmpeg -i input -map 0 -c copy rtmp://youtube_url -map 0 -c copy rtmp://twitch_url [05:36:36 CEST] <thebombzen> the -c copy tells ffmpeg not to re-encode, just streamcopy. -map 0 tells ffmpeg to keep all streams from the input. it shouldn't be necessary if the input is just one video and one audio stream [05:36:51 CEST] <Coburn> ok [05:37:23 CEST] <Coburn> So I suppose in OBS Studio I'd make a custom profile and tell it to push the stream to that IP:port [05:37:56 CEST] <thebombzen> are you just trying to stream your desktop to two different sites at once? [05:38:11 CEST] <thebombzen> or is it some other thing. because I think OBS might be able to do that without ffmpeg frippery [05:38:12 CEST] <Coburn> Not desktop, but capture card for SNES/PS4/etc [05:38:27 CEST] <Coburn> The problem is I'm limited to 5Mbps uplink. [05:38:48 CEST] <c3r1c3-Win> Use restream.io then. [05:38:58 CEST] <thebombzen> Is there any particular reason to go to YouTube and Twitch at the same time? [05:39:04 CEST] <thebombzen> it sounds like this is a big deal [05:39:11 CEST] <Coburn> 2Mbps is allocated to YT Gaming, the problem is that anything using 3/4 Mbps constantly causes lag. Blame Australia. [05:39:22 CEST] <Coburn> Probably to cover audience [05:40:02 CEST] <thebombzen> The issue is that what you're doing is very greedy, perhaps a bit too greedy for a 5 Mbps upload link. I'd check out what c3r1c3-Win said [05:40:13 CEST] <Coburn> Well, what I'm planning to do is this [05:40:35 CEST] <Coburn> My PC with OBS -> Singapore Linode running FFMpeg -> YouTube/Twitch/etc [05:40:59 CEST] <c3r1c3-Win> Then I would setup a nginx instance. [05:41:14 CEST] <Coburn> nginx can do video streaming relays? [05:41:28 CEST] <c3r1c3-Win> and maybe use a protocol that isn't so hard on your internet connection... like HLS to stream out. [05:42:20 CEST] <Coburn> Well, I can stream to YouTube Gaming fine with 2Mbps [05:42:28 CEST] <thebombzen> nginx can. nginx is an http server and HLS is http live streaming [05:42:47 CEST] <Coburn> I'm familiar with nginx, but did not know it can do HLS. [05:42:55 CEST] <Coburn> So how would it work? [05:43:00 CEST] <thebombzen> shrug [05:43:15 CEST] <thebombzen> this one I do not know. maybe c3r1c3 can help you with this but I cannot [05:43:28 CEST] <Coburn> ok [05:43:46 CEST] <Coburn> I mean sure, i can use restream.io but if they're going to inject ads and stuff, then no thanks [05:43:59 CEST] <c3r1c3-Win> OBS->Settings-Output->Mode:Advanced->Recording-Type:Custom->Output type: To URL, and do the HLS jiggle. [05:44:20 CEST] <Coburn> Alright. I guess I'll read up with the nginx HLS module then [05:44:46 CEST] <Coburn> So i'd connect ffmpeg into that and let it go to youtube/twitch? Or will nginx do that automatically? [05:44:53 CEST] <Coburn> as specified?* [05:45:36 CEST] <c3r1c3-Win> if you use NGinx and the OBS ffmpeg advanced output to URL option... then you shouldn't need ffmpeg at all. [05:46:32 CEST] <Coburn> yeah, but then how will people on YouTube and Twitch see the stream if I'm using HLS? From what I can see, people would need to connect to the HLS port? [05:46:52 CEST] <c3r1c3-Win> You use NGinX to rechunk the stream and push it out rtmp. [05:47:12 CEST] <Coburn> alright [05:47:28 CEST] <Coburn> I'll grab some lunch and give it a shot. [06:00:19 CEST] <damdai> i upgraded from sandybridge i7 to ivybridge i7 but x265 encoding is still slow [06:03:11 CEST] <c3r1c3-Win> Sandybridge to ivy was only about a 5-10% IPC improvement. [06:03:14 CEST] <thebombzen> x265 is going to be slow for a while [06:03:24 CEST] <thebombzen> it's slow on my skylake i7, so that's not a surprise [06:03:45 CEST] <c3r1c3-Win> Unless you get a ton of fast-ish cores, it takes a while. [06:04:02 CEST] <c3r1c3-Win> Same for VP9 and AV1 as well. [06:04:25 CEST] <kepstin> vp9 in git has a bunch of multithreading improvements recently, so it should be getting better [06:04:43 CEST] <kepstin> before it was really limited in scaling to more cores :/ [06:04:54 CEST] <c3r1c3-Win> LOL, yeah, it'll actually take advantage of said cores. [06:08:03 CEST] <thebombzen> well libvpx-vp9 was slow before because it was just bad. now it'll be slow because vp9 is just a slow codec [06:08:14 CEST] <thebombzen> #improvements [06:12:31 CEST] <grublet> slower means higher quality [06:12:35 CEST] <grublet> :) [06:16:55 CEST] <damdai> <thebombzen> x265 is going to be slow for a while [06:18:23 CEST] <grublet> on the topic of x265 [06:18:39 CEST] <grublet> imo the quality of hevc is worse than that of avc [06:18:48 CEST] <grublet> i dont like the wavelet-y artifacts [06:25:30 CEST] <kepstin> well, that's just an artifact of choices made in the encoder and a lack of psy tuning :/ [06:26:11 CEST] <kepstin> the x264 people worked very hard to make the artifacts look less displeasing :) [06:26:22 CEST] <grublet> isnt the x265 team the same? [06:26:29 CEST] <kepstin> no, completely different people [06:26:39 CEST] <grublet> in that case im showing how out of the loop i am :) [06:27:06 CEST] <grublet> im out of the in-loop deblocking filter [06:27:22 CEST] <grublet> i wonder what the progress on theora has been, if any [06:27:38 CEST] <grublet> er, not theora, daala [06:27:42 CEST] <kepstin> i'd expect it to be mostly abandoned in favour of the newer vpx codecs [06:28:08 CEST] <kepstin> oh, daala? some of the work from that is gonna be used in av1 [06:28:10 CEST] <grublet> i wouldnt be surprised if daala has been abandoned as well [06:28:33 CEST] <kepstin> they're gonna continue to use daala as a research project to test new ideas, but it'll never be a "finished" codec [06:28:49 CEST] <grublet> i can still build it and mess with it myself though, presumable [06:29:53 CEST] <grublet> i kinda lost my enthusiasm for codecs a few years ago [06:30:39 CEST] <kepstin> ever since x264, everything has been pretty much either marginally different or slower :/ [06:31:33 CEST] <grublet> yeah that sounds about right [06:31:53 CEST] <c3r1c3-Win> The hardware encoders are getting better, and I wouldn't be surprised to see a really good one at some point (that is in consumer-pricing land). [06:31:59 CEST] <grublet> x264 was what garnered most of my enthusiasm, especially because i got interested in encoding around when blu-ray was a new format [06:32:02 CEST] <kepstin> hevc's improvements are mostly notable for 4k stuff, where the larger transforms help [06:32:11 CEST] <grublet> that makes sense [06:32:19 CEST] <kepstin> and if you want >10bit depth for some reason, x264 can't do that [06:32:22 CEST] <grublet> i dont have any content over 1080p [06:32:28 CEST] <grublet> i'd rahter have 4:4:4 [06:32:35 CEST] <c3r1c3-Win> ^ [06:32:42 CEST] <grublet> finally someone agrees [06:33:38 CEST] <c3r1c3-Win> Order of likes... HDR, 4:4:4, 4k [06:33:42 CEST] <grublet> i started watching videos on signal processing again recently, sorta out of the blue [06:34:01 CEST] <kepstin> well, x264 can do 4:4:4 just fine, and HDR really needs higher bit depths - 10bit is kinda the min for that [06:34:10 CEST] <kepstin> so, fine for now [06:34:10 CEST] <grublet> c3r1c3-Win: i can see where HDR would be useful internally, same as over 8-bits, but at the display level i dont really have any scenarios that i would benefit from it [06:34:15 CEST] <Coburn> I honestly don't see the point in 4k just yet [06:34:42 CEST] <kepstin> I use a 24" 4k monitor on my desktop, but that's mostly just so my font rendering is sharper [06:34:48 CEST] <kepstin> I have basically no 4k video [06:34:49 CEST] <grublet> HDR makes a pretty obvious difference in video games, where the higher dynamic range is used to tone map and dither down to display bit depth [06:35:16 CEST] <grublet> kepstin: i have a 24" 4k monitor, id rather have something 28"+, because i cant read it at 4k at all [06:35:36 CEST] <grublet> my hdmi cable is old and can only support 4k at 30hz so its useless for games atm [06:36:01 CEST] <kepstin> ... that's what scaling/font size options are for. On windows I normally use 175% scaling, and it's displayport so it does 60Hz fine :) [06:36:09 CEST] <c3r1c3-Win> i bought a good (but cheap) 55" 4K TV for my computer monitor... works really well. [06:36:11 CEST] <Coburn> I have a what... 28" or 32" 1080p curved samsung monitor [06:36:16 CEST] <grublet> not everything scales reliably, however [06:36:19 CEST] <Coburn> good enough for my eyes [06:36:24 CEST] <grublet> especially older programs (which is most of what i use) [06:36:26 CEST] <kepstin> gnome only gives integer scaling multiples, which is annoying, so I use 2x on linux :/ [06:36:41 CEST] <Coburn> can enable virtual super resolution but then everything goes ugly [06:36:44 CEST] <kepstin> grublet: latest win10 update helps a lot there, it adds new scaling mode for old gdi apps [06:36:45 CEST] <Coburn> and blurry [06:36:46 CEST] <c3r1c3-Win> Big enough that I don't have to scale, and clear enough on text that I can have everything on one screen. [06:36:52 CEST] <grublet> kepstin: i use win7 [06:37:00 CEST] <kepstin> grublet: well, there's your probelm [06:37:20 CEST] <kepstin> really need latest win10 if you're gonna use highdpi monitors. [06:37:23 CEST] <grublet> kepstin: indeed, its my problem because im nostalgic and refuse to use any other windows than xp or 7 [06:37:37 CEST] <grublet> im more interested in using the 4k for screen real estate than the dpi [06:37:47 CEST] <grublet> 1 4k for me would be used to replace 4 1080p monitors [06:37:48 CEST] <Coburn> Why not just run Windows 10, then XP / 7 in the VM? problem solved ;) [06:37:52 CEST] <kepstin> I certainly hope you don't have any xp machines connected to the internet :) [06:37:59 CEST] <grublet> Vms are a whole nother can of worms [06:38:02 CEST] <kepstin> that recent patch for wannacry is an exception, not the norm ;) [06:38:05 CEST] <grublet> kepstin: i might... [06:38:34 CEST] <Coburn> I managed to pull off a windows 10 gaming VM, worked ok but suffered issues like USB ports needing to be passthrough'd and other stuff [06:38:44 CEST] <Coburn> was workable, but long term gaming? No. [06:38:50 CEST] <grublet> at this point id probably only use XP in a VM [06:38:58 CEST] <grublet> curiously enough a lot of windows games run perfectly in WINE [06:39:04 CEST] <Coburn> Windows XP refuses to boot inside a VM due to my Ryzen chip :P [06:39:10 CEST] <grublet> so linux is my probably upgrade path should win7 become too antiquated [06:39:17 CEST] <grublet> Coburn: i heard about that issue [06:39:20 CEST] <Coburn> Windows 98SE also craps itself [06:39:25 CEST] <Coburn> DOS works... somewhat [06:39:29 CEST] <grublet> ryzens not having some tpye of instructions i thiunk [06:39:45 CEST] <Coburn> It just causes Windows to hang on boot [06:39:59 CEST] <grublet> so its unusable then yeah>? [06:40:06 CEST] <Coburn> pretty much [06:40:21 CEST] <grublet> i think there was some kind of fix released [06:44:26 CEST] <kepstin> i'm still working through a bunch of stability issues with my ryzen. new beta bios at least means ram posts reliably at 2666mhz now, but I still get some odd hangs/crashes, often when nearly idle :/ [06:45:12 CEST] <grublet> Is the RAM DDR4? [06:45:17 CEST] <c3r1c3-Win> Yeah, I would hold off on Ryzen (for production machines) until the end of the year, esp. on Linux. [06:45:42 CEST] <grublet> This is partly why I use older hardware/OS's. i avoid the instability of new stuff to an extent [06:48:25 CEST] <Coburn> Ryzen is pretty solid [06:48:35 CEST] <Coburn> I'm an early adopter and I had issues with black screens of death [06:48:47 CEST] <Coburn> but the latest BIOS updates have had zero issues [06:48:58 CEST] <grublet> The CPU in my computer is a decade old now [06:49:16 CEST] <grublet> and realistically I doubt I'll be upgrading anytime soon, in part due to being unable to afford upgrading [06:49:23 CEST] <Coburn> Currently on a ASUS B350M (?) motherboard plus an R7 1700 [06:49:31 CEST] <Coburn> Best. Investment. Ever. [06:49:43 CEST] <grublet> my CPU is an i7-950 on an LGA 1366 board... lol [06:49:47 CEST] <Coburn> My Core i5-4590 started getting jealous [06:50:13 CEST] <grublet> my GPU is a GTX 670 [06:50:26 CEST] <kepstin> grublet: heh, you splurged there, my s1366 box is only an i7-920 ;) [06:50:26 CEST] <Coburn> That reminds me [06:50:40 CEST] <Coburn> FFMpeg doesn't use GPU acceleration does it? [06:50:55 CEST] <Coburn> Like it doesn't use OpenCL/CUDA/DirectCompute etc? [06:50:55 CEST] <grublet> kepstin: since i made the mistake of choosing LGA1366, my only upgrade option is a CPU that costs $1000 even today [06:51:14 CEST] <kepstin> Coburn: ffmpeg can optionally use the gpu hardware encoders/decoders rather than software, and there's a few filters that do some opencl or cuda stuff [06:51:15 CEST] <grublet> and the asus sabertooth x58 is a garbage motherboard, imo [06:51:35 CEST] <Coburn> nice [06:51:39 CEST] <kepstin> but, very few filters, and I've never had a reason to use them [06:51:49 CEST] <Coburn> and is that only for windows or *nix provided you have the proper drivers installed? [06:52:11 CEST] <kepstin> works on both, iirc, but i think getting intel to work on windows is painful [06:52:21 CEST] Action: kepstin hasn't tried that [06:52:38 CEST] <Coburn> Intel QuickSync? [06:53:02 CEST] <kepstin> keep in mind that the hardware encoders included on gpus are generally quite bad compared to software - the only benefit is that you can use the cpu+gpu for other stuff at the same time as you're encoding [06:53:20 CEST] <Coburn> AMD's encoder is pretty competent imo [06:54:11 CEST] <kepstin> "competent for a hardware encoder" is pretty far away from what x264 can pull off ;) [06:54:32 CEST] <Coburn> well [06:54:34 CEST] <kepstin> ... if you throw a lot of cpu cores at it [06:54:44 CEST] <Coburn> it's good enough for GPU encoding desktop streams [06:55:33 CEST] <c3r1c3-Win> grublet, Tried ebay? [06:55:34 CEST] <kepstin> like I said - it's useful if your cpu is otherwise occupied - for example doing things like running the applications you're screencasting. [06:55:52 CEST] <grublet> c3r1c3-Win: tried it for what? [06:56:28 CEST] <c3r1c3-Win> grublet: CPU upgrades. [06:56:43 CEST] <grublet> there's only one cpu model about the i7-950 [06:56:53 CEST] <grublet> its more an issue that if im gonna upgrade, i may as well just build a new machine [06:57:02 CEST] <grublet> 1366 is dust in the wind at this point [06:57:16 CEST] <kepstin> nah, there's a few if you can run the extreme edition ones in your board, but those are kinda expensive [06:57:29 CEST] <grublet> yeah the only ones above what i have are expensive [06:57:35 CEST] <grublet> as far as ebay, never thought to look [06:57:41 CEST] <grublet> but im also not that concerned about it really [06:58:13 CEST] Action: kepstin is almost tempted to pick up a 960 or 970 to replace his 920 now. [06:58:31 CEST] <grublet> my 950 is still performing much better than i'd expect for something that's 10 years old [06:58:46 CEST] <grublet> but then again i dont do much different than i did 10 years ago with my computer [06:59:04 CEST] <grublet> most of the games i play are 10+ years old, and i dont really encode much anymore [06:59:13 CEST] <kepstin> until I got this new ryzen box, I still used that as my gaming box yeah [06:59:27 CEST] <kepstin> upgraded the gpu once several years ago, but that was it [06:59:29 CEST] <c3r1c3-Win> My main linux box is a dual x5650s... been thinking about upgrading it to either e5-v1s or x56xx that's a bit higher. [06:59:39 CEST] <grublet> ive had 5 or 6 different gpu's in this system [06:59:55 CEST] <grublet> i'd love to get a dual 8core cpu setup with 32+gb of ram [07:00:04 CEST] <Coburn> I originally had a R9 280 in this rig [07:00:09 CEST] <Coburn> now I'm RX570 [07:00:15 CEST] <grublet> id also like calibrated dual 4k monitors [07:00:51 CEST] <kepstin> i'm still curious about whether AMD threadripper is gonna support registered ram [07:01:09 CEST] <kepstin> probably not if it's their consumer model and they're basing it on the existing ryzen chips [07:01:12 CEST] <grublet> Coburn: my upgrade path (that i can remember) has been 8800GTX, radeon 2950, GTX 260, 4950, 6970, gtx 670 [07:01:17 CEST] <c3r1c3-Win> I could upgrade both CPUs to the x5690s for $239. [07:01:18 CEST] <kepstin> which really limits the max ram capacity [07:01:37 CEST] <Coburn> > nginx_mod_hls - This module is available as part of our commercial subscription. [07:01:43 CEST] <Coburn> really...? [07:01:44 CEST] <grublet> im just happy SSD has become so affordable [07:01:53 CEST] <c3r1c3-Win> ^ [07:02:12 CEST] <grublet> my 480GB ssd cost like $200 when i bought it [07:02:22 CEST] <c3r1c3-Win> That's beenthe biggest QoL-computer upgrade I've done. [07:02:41 CEST] <kepstin> Coburn: the (free) third-party rtmp module can serve up hls, iirc - or just use ffmpeg's segment muxer? [07:03:04 CEST] <Coburn> yeah [07:03:19 CEST] <Coburn> hmm [07:03:36 CEST] <kepstin> heh, I have a first-generation OCZ vertex in my old 1366 box [07:03:45 CEST] <kepstin> still works fine [07:03:52 CEST] <grublet> kepstin: my SSD is an intel i730 [07:03:58 CEST] <kepstin> (got to be one of the only working ones left, i bet) [07:04:24 CEST] <grublet> i bought the intel 730 because i read it was long lasting [07:04:26 CEST] <grublet> so far so good [07:04:30 CEST] <grublet> only had it a couple years thoug [07:04:47 CEST] <Coburn> here comes the gentoo VPS to end all VPS [07:04:50 CEST] <Coburn> compile all the things [07:05:25 CEST] <grublet> nothing must be left uncompiled [07:06:16 CEST] <grublet> i ran a gentoo live-usb once, interestingly enough it was one of the live-usbs i had the least problems with [07:09:22 CEST] <kepstin> i think even now knoppix is still based on gentoo? [07:09:38 CEST] <kepstin> haven't used it in a long time tho :) [07:09:42 CEST] <grublet> no clue [07:33:14 CEST] <Coburn> I thought knoppix was debian? [07:33:22 CEST] <Coburn> I remember when it used KDE3 [07:38:00 CEST] <grublet> i still have a cd with ubuntu hardy heron on it somewhere [07:38:05 CEST] <grublet> was the first linux distro i tried [07:38:27 CEST] <Coburn> holy smokes [07:38:35 CEST] <Coburn> ffmpeg + nginx setup is awesome [07:39:22 CEST] <grublet> i remember watching youtube channels like nixipixel [07:39:25 CEST] <grublet> i wonder if shes still arouind [07:41:33 CEST] <Coburn> so with that setup now, I point OBS to the rtmp port, and then point FFMpeg to the local port and pipe it to youtube/twitch? [07:42:04 CEST] <c3r1c3-Win> Coburn: That reads correctly. [07:42:06 CEST] <grublet> no clue, i guess i wasnt following the convo [07:42:22 CEST] <Coburn> ok [08:07:09 CEST] <Coburn> alright so it's working on twitch [08:07:36 CEST] <Coburn> but I'm not sure if i should be using the http://<ip>:8080/hls/stream.m3u8 URL for ffmpeg... [08:07:54 CEST] <Coburn> It's getting a lot of [http @ 0x1cd1ec0] No trailing CRLF found in HTTP header. [08:08:17 CEST] <Coburn> it is saying "frame= 1018 fps=6.4 q=23.0 size= 3276kB time=00:02:49.99 bitrate= 157.9kbits/s" [08:09:10 CEST] <Coburn> It's just a video of some BGM from a game, I can't hear any stutter etc [08:28:47 CEST] <Coburn> and... it broke [08:28:50 CEST] <Coburn> rip [11:15:31 CEST] <Fyr> guys, I can't copy some videos onto my iPad, because iTunes says: "This video cannot be played on this iPad", while another videofiles encoded with the same codecs were copied. [11:16:12 CEST] <Fyr> are there options I have so set when remuxing with FFMPEG? [11:16:34 CEST] <Fyr> because some of the files are copied and played without a glitch. [11:18:16 CEST] <Fyr> some metadata of unacceptable filesays that its language - Japanese. [11:18:25 CEST] <Fyr> (of the video) [12:15:32 CEST] <Fractal__> Hello, im trying to recover a video using recover_mp4 and one of the steps is to use ffmpeg but i dont have the exe [12:15:45 CEST] <Fractal__> what should i do? [12:16:31 CEST] <furq> Fractal__: https://ffmpeg.zeranoe.com/builds/ [12:17:37 CEST] <Fractal__> thanks ill try that [13:02:32 CEST] <Redadev> Hello, I have two servers A and B that communicate over HTTP, on server A a video file is currently saved by some process, I want to use ffmpeg to encode this file on server B. [13:02:32 CEST] <Redadev> But since server communicate over HTTP, the encoding stops after some time, the reason seem to be that, when i execute the ffmpeg command in server B, HTTP response include the current file in server A and the encoding stops when it reachs this length. [13:02:32 CEST] <Redadev> Is ther a way to tell ffmpeg to ignore this filelength and to continue encoding ? [13:06:10 CEST] <BtbN> no, you generally can't process video files before the file has been finalized, unless you use something like mpegts [13:06:22 CEST] <BtbN> and even then, doing so via a normal http server will give you that issue [13:10:39 CEST] <Redadev> Thanks BtbN, do you think that ffmpeg can be edited to permit this behaviour ? [13:10:54 CEST] <BtbN> no [13:11:14 CEST] <BtbN> don't use a http server for something it's not designed for. [13:11:22 CEST] <furq> you could potentially send it chunked, but probably not with a regular httpd [13:11:27 CEST] <BtbN> It serves static files as, well, static files [13:11:32 CEST] <furq> and if you're going to write code for this then you should probably just use something better [13:11:53 CEST] <BtbN> Could throw a php script on there that omits the content-length and just streams the file out [13:12:09 CEST] <BtbN> But a standard plain httpd can't do what you want. [13:12:33 CEST] <BtbN> And even with that php script you will have to pull tricks inside of the script to read the file while it's growing. [13:13:24 CEST] <BtbN> Just store the video as HLS, you can very easily read the, via a httpd, from the other server, while it's growing. [13:14:55 CEST] <Redadev> Thank you for theses answers, unfortunatly i can't change the format of the source video, i will think about the script omitting the content-length [13:15:03 CEST] <Redadev> "use something better" what do you mean but that ? [13:15:11 CEST] <BtbN> Why can't you do that? [13:15:14 CEST] <BtbN> What format even is it? [13:15:25 CEST] <BtbN> Just change the output of ffmpeg on server A. [13:15:58 CEST] <Redadev> I don't have control over server A, the file ar saved by an other software [13:16:09 CEST] <BtbN> in what format? [13:16:46 CEST] <Redadev> h264 [13:17:50 CEST] <BtbN> it saves a raw .h264 file? [13:18:52 CEST] <Redadev> the source file is .ts [13:18:53 CEST] <Redadev> Stream #0:0[0x727]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k tbn, 50 tbc [13:18:53 CEST] <Redadev> Stream #0:1[0x728](EN): Audio: mp2 ([4][0][0][0] / 0x0004), 48000 Hz, stereo, s16p, 192 kb/s (clean effects) [13:19:12 CEST] <BtbN> yes, so it at least uses a sane format where what you want is possible [13:19:30 CEST] <BtbN> is it an endless stream? [13:20:08 CEST] <Redadev> there is a file per day, the maximum duration is 28hours [14:45:40 CEST] <KresTwo> Why is there no mediaplayer QUALITY shootout. Or, why can't I find it. [14:45:55 CEST] <furq> idk but vlc is in last place [14:46:01 CEST] <JEEB> quality stops being a thing after you get the basics right [14:46:16 CEST] <JEEB> of course, not saying a lot of things don't get the basics right :P [14:46:49 CEST] <JEEB> out of the open source things the opengl renderer in mpv seems to be the least retarded one [14:47:15 CEST] <KresTwo> JEEB I'll have to test that one. [14:48:44 CEST] <KresTwo> furq yup. It plays everything, equally bad. [14:50:03 CEST] <JEEB> vlc does some things very well though [14:50:08 CEST] <JEEB> try feeding it a broadcast MPEG-TS [14:50:13 CEST] <JEEB> with PID switches and such [14:50:25 CEST] <JEEB> you'll see that it was one of the first use cases for it [14:51:29 CEST] <furq> i only ever had vlc installed for network streams [14:51:38 CEST] <furq> which makes sense given its name [14:51:43 CEST] <furq> but i just use mpv for that now [14:51:49 CEST] <ritsuka> mpv is one of the few that at least try to get the right colors [14:51:54 CEST] <KresTwo> JEEB every tool has its uses. But when I want bitperfect audio I use foobar2000 and asio. [14:52:42 CEST] <KresTwo> I just want to find a mediaplayer that does the similar for video. [14:53:13 CEST] <JEEB> ritsuka: granted at least some VOs in VLC did get updated to be less bad. the fact that mpv tries to use a single one everywhere kind of helps :) [14:54:11 CEST] <ritsuka> vlc 3.0 master branch on mac display everything in bt.601 since last year :| [14:55:11 CEST] <JEEB> yea they've been focusing on stuff they're getting money from I think [14:55:23 CEST] <JEEB> such as the mobile ports and the non-playback stuff [14:58:49 CEST] <KresTwo> JEEB thanks. It worked pretty well with 60 fps material too. [15:17:05 CEST] <durandal_1707> bitperdect audiophile with golden ears [19:33:13 CEST] <Filystyn> guys if something is not music i will alway sget format with probing as unspecified ? [19:48:11 CEST] <ChocolateArmpits> Filystyn, what do you mean not music ?? [19:48:35 CEST] <Filystyn> i will open format content of a file [19:48:40 CEST] <Filystyn> it turns out it's not audio [19:48:43 CEST] <Filystyn> what will i get as format? [19:50:14 CEST] <ChocolateArmpits> depends on the file, ffmpeg can try probing for format independent of the extension [19:51:22 CEST] <ChocolateArmpits> really depends on the format, some have a magic number, a unique identifier at the start of the bytestream that lets to guess it more easily, others may have other means. [19:51:59 CEST] <Filystyn> you dont udnerstand i have wrote a function to detect format [19:52:08 CEST] <ChocolateArmpits> well you never explained that [19:52:15 CEST] <Filystyn> it works but i don't know what format is a flag that it is not audio [19:52:30 CEST] <durandal_1707> wut? [19:52:33 CEST] <Filystyn> what will it return as type of audio/codec [19:52:46 CEST] <Filystyn> when file is simply txt file or other not audio fi;e [19:52:53 CEST] <durandal_1707> that does demuxer when reading [19:53:28 CEST] <durandal_1707> it sets type of streams that it adds [20:01:38 CEST] <Filystyn> ok so what is the type of stream [20:01:41 CEST] <Filystyn> that is not audio [20:01:44 CEST] <Filystyn> this is what i ask [20:04:09 CEST] <durandal_1707> video data subtitle unknown attachement [20:04:24 CEST] <durandal_1707> one of these [20:05:01 CEST] <Filystyn> thank you [20:05:06 CEST] <Filystyn> that is big help for me [22:15:55 CEST] <Tauromancer> Can anyone point me to an updated compiling instructions for raspian? I've had varying issues on the last 3 compiles, and feel like I'm falling down a google hole [23:53:07 CEST] <kms_> can i speed up the video without reencoding by doubling fps? [23:53:57 CEST] <kerio> you mean by doubling the timestamps? [23:56:44 CEST] <kazuma_> you can do that in your media player kms_ [23:57:36 CEST] <kms_> no, i want change viceo file [23:57:43 CEST] <kms_> *video [23:58:40 CEST] <kms_> i need double speed 60fps video [23:58:43 CEST] <furq> what codec [23:58:49 CEST] <kms_> vp8 [23:58:54 CEST] <furq> oh [23:58:57 CEST] <furq> that's tricky then [23:59:11 CEST] <c_14> doesn't matroska have container fps? [23:59:11 CEST] <furq> you can do it with h264 by demuxing to an elementary stream and then setting the input fps when remuxing [23:59:25 CEST] <furq> but i don't think ffmpeg has a vp8 elementary stream muxer [23:59:27 CEST] <c_14> you can try setting that with mkvmerge [23:59:36 CEST] <furq> yeah it does but idk if all players respect it [00:00:00 CEST] --- Sun Jun 11 2017

1 0