Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

May 2016

1 participants
62 discussions

ffmpeg-devel.log.20160505
by burek 06 May '16

06 May '16

[00:17:32 CEST] <Shiz> >ff_h2645 [00:17:33 CEST] <Shiz> excuse me [00:23:46 CEST] <wm4> isn't it wonderfully confusing [00:32:49 CEST] <cone-333> ffmpeg 03foo86 07master:bb7c55807090: avformat/dtsdec: detect core-less streams [00:32:50 CEST] <cone-333> ffmpeg 03James Almer 07master:e3df56f5b4d5: avformat/dtsdec: reduce the scope of crctab [01:21:53 CEST] <cone-333> ffmpeg 03Rostislav Pehlivanov 07master:770d3c85afad: vc2enc: do not print the lavc version if the bitexact flag is enabled [02:09:40 CEST] <Compn> [FFmpeg-devel] A Hackathon for Codec Develovers was in the spam dir [02:12:14 CEST] <Compn> at isp level :\ [02:19:18 CEST] <Daemon404> lol. Not My Problem! [02:19:24 CEST] Action: Daemon404 sleeps [02:51:27 CEST] <Daemon404> michaelni, my latest reply seems to have not gotten to the ml [02:51:33 CEST] <Daemon404> and/or llogan [02:51:44 CEST] <Daemon404> spam filter or something? [02:53:38 CEST] <llogan> Daemon404: i only see spam in the queue [02:53:48 CEST] <Daemon404> really? [02:54:08 CEST] <Daemon404> gmail shows it as sent 10 msn ago [02:54:10 CEST] <Daemon404> mins* [02:54:36 CEST] <Daemon404> oh there it is [02:54:40 CEST] <Daemon404> slow... [02:54:41 CEST] <Daemon404> weird [02:54:45 CEST] <Daemon404> anyway sleep [02:54:47 CEST] <Daemon404> 3am [02:54:48 CEST] <Daemon404> 2am* [02:55:15 CEST] <llogan> not sure why it was so slow. timnich probably would. [04:15:04 CEST] <cone-333> ffmpeg 03Michael Niedermayer 07master:e7a9b434c57c: fate: Add test for broken SPS (Ticket 2580) [06:26:43 CEST] <ffuser> Hi [06:28:14 CEST] <ffuser> Anybody couldn't feel libx264 performance drop on recently ffmpeg git? [06:29:50 CEST] <ffuser> I used 09.april build of ffmpeg. Today I was build 05.May ffmpeg [06:30:12 CEST] <ffuser> Then use for rtmp streaming [06:31:14 CEST] <ffuser> When I streaming rtmp libx264 stream, CPU Usage too higher than before build. and too many frame drops [06:31:34 CEST] <ffuser> Do not had framedrop on old version [06:32:15 CEST] <ffuser> Old version CPU Usage avg : 50~70% but today version Usage avg : 70~100% [06:32:28 CEST] <ffuser> at the same encoding option [09:07:26 CEST] <cone-666> ffmpeg 03Muhammad Faiz 07master:d2f73c3daf02: avfilter/avf_showcqt: add . [10:39:10 CEST] <cone-666> ffmpeg 03Paul B Mahol 07master:5b174dd3f133: avfilter/vf_waveform: fix order of graticule scale items [11:45:20 CEST] <ubitux> if i have a video frame where i need to zero the left and right edges (generally a small number of column, somewhere between 0 and let's say 5 or 6), is it more interesting to 1. process the edges in the main loop by inserting 2 small loop around the line processing code, 2. memset zero the whole frame and then process the "inside", 3. make a column pre (or post) processing after processing the inside [11:45:22 CEST] <ubitux> ? [11:46:27 CEST] <atomnuker> so you do postprocessing, right? [11:46:27 CEST] <durandal_1707> what's faster? [11:47:18 CEST] <atomnuker> if you zero it out before you do postprocessing you might get some undesirable effects (e.g. if you blur it'll also blend the black columns) [11:47:53 CEST] <ubitux> atomnuker: i process the frame except i have to make a zero padding of a few pixels; i'm asking what approach is more likely to be optimal to achieve that [11:48:00 CEST] <ubitux> atomnuker: it's a 1:1 pixel processing, no surrounding [11:48:07 CEST] <ubitux> durandal_1707: that's the question :) [11:49:03 CEST] <ubitux> i'm afraid 1 will cause branching slowdown, 2 being "do too much" and 3 will have cache issues [11:49:52 CEST] <wm4> you could allocate the frame with calloc, which will use mmap, which will use a kernel background thread to zero pages [11:50:07 CEST] <ubitux> wm4: i'm reusing that buffer a lot [11:50:27 CEST] <ubitux> should i re-allocate it everytime instead? [11:51:19 CEST] <ubitux> (wm4: btw, av_calloc is calling memset :p) [11:51:30 CEST] <wm4> that's because av_calloc is stupid [11:51:32 CEST] <nevcairiel> for some reason we dont like using actual calloc [11:51:37 CEST] <nevcairiel> probably because no alignment [11:51:46 CEST] <ubitux> yes that's because of align ofc [11:54:30 CEST] <ubitux> i might use a different trick in the end but anyway [11:54:56 CEST] <ubitux> i'm curious of the general consensus on doing this since it looks like common [11:58:33 CEST] <durandal_1707> why not remove libwavpack wrapper? [12:01:19 CEST] <atomnuker> the native encoder was kinda slow and a bit less efficient last time I tested it [12:27:51 CEST] <durandal_1707> you tested only default, with no args [12:27:53 CEST] <durandal_1707> ? [12:41:25 CEST] <durandal_1707> and you compared with wrapper which supports only s32 sample format [12:41:47 CEST] <durandal_1707> or wavpack itself? [12:43:12 CEST] <atomnuker> I did try optimize_mono (file was a 10 second mono sine wave from lavfi) [12:43:26 CEST] <atomnuker> I don't think I tried compression_level though [13:59:50 CEST] <JEEB> hmm, the last time I tried the H.264-in-movlike muxing wasn't completely broken [14:00:02 CEST] <JEEB> unless mov specifically doesn't handle edit lists [14:36:06 CEST] <Daemon404> i wonder how many bug reports can be summed up with "my file sucks, halp" [14:44:48 CEST] <atomnuker> could someone try to convince the libav not to center the new bitstream writing API around reading while there's still a chance? [14:45:11 CEST] <atomnuker> just to have every single function doing reading to have the prefix bitstream_read_xxx() [14:45:57 CEST] <atomnuker> because it's going to bother me quite a lot to one day have the writing API changed and see bitstream_skip and bitstream_write_skip instead of bitstream_read_skip and bitstream_write_skip [14:47:13 CEST] <Daemon404> atomnuker, reply on the ml [14:48:34 CEST] <atomnuker> no subscription [14:49:49 CEST] <Daemon404> "i really dont waht x to happen, but i cant be arsed to do anything" [14:50:04 CEST] <iive> atomnuker: subscribe [14:51:12 CEST] <iive> you could probably try to hang in their irc channel and discuss it there [14:51:43 CEST] <iive> they do prefer more immediate communication methods [14:52:35 CEST] <Daemon404> sometimes irc is better [14:52:40 CEST] <Daemon404> email can sometimes fan flames [14:52:43 CEST] <Daemon404> and misunderstanding [15:00:05 CEST] <BBB> michaelni: ty for review, will fix these [15:00:34 CEST] <BBB> michaelni: as for const in int16_t *rgb[3], its broken const-ness in C which is why its not const [15:00:40 CEST] <BBB> michaelni: Ill fix the other const and comments [15:34:23 CEST] <Daemon404> nevcairiel, pingpong [15:39:05 CEST] Action: nevcairiel is sleepy [15:39:22 CEST] Action: nevcairiel goes back to sleep before Daemon404 spots him [15:40:01 CEST] <Daemon404> nevcairiel, do you have time soon (tm) to help with h2645 nals? [15:40:15 CEST] <Daemon404> i dont think i am capable of doing that without a huge amount of research [15:40:49 CEST] <nevcairiel> tomorrow i guess, going to step out soon [15:41:03 CEST] <Daemon404> ok [16:04:24 CEST] <cone-261> ffmpeg 03Rick Kern 07master:f1560dbb2a00: lavd/avfoundation: use AVCodecParameters [17:09:29 CEST] <roxlu_> Hi, what does ffmpeg use to convert audio samplerates? [17:10:40 CEST] <roxlu_> oh I guess it's the libswresample ? [17:10:46 CEST] <wm4> yes [17:13:27 CEST] <Shiz> you can use that directly or use libavfilter which uses swresample internally [17:15:46 CEST] <roxlu_> Ok, thanks Shiz [17:16:11 CEST] <roxlu_> I was wondering, when I convert van 32hz to 44.1hz will I get noticeable artifacts? [18:00:23 CEST] <JEEB> lol libutvideo [18:12:15 CEST] <Daemon404> BBB, https://hg.mozilla.org/mozilla-central/file/tip/media/ffvpx [18:12:18 CEST] <Daemon404> have you seen this [18:12:26 CEST] <Daemon404> they seem to have forked and cut down to ffvpx [18:12:35 CEST] <BBB> rofl :D [18:12:37 CEST] <BBB> no [18:12:41 CEST] <BBB> but its hilarious [18:13:02 CEST] <Daemon404> (found via JEEB) [18:13:13 CEST] <JEEB> yeah, I was like "wut, why doesn't this thing have libav*.dll [18:13:18 CEST] <Daemon404> "AVX2 must be disabled on Linux due to the use of yasm 1.1 on the build bots." [18:13:21 CEST] <Daemon404> readme has some gems [18:13:31 CEST] <JEEB> then went into the commit logs and found it cut out [18:13:33 CEST] <JEEB> :D [18:13:43 CEST] <BBB> this is utterly amazing [18:13:47 CEST] <BBB> I love it [18:14:14 CEST] <Daemon404> why are they disabling asm on some platforms, its so odd [18:14:18 CEST] <wm4> mozilla never ceases to amaze [18:14:29 CEST] <BBB> yasm 1.1 doesnt support avx2? [18:14:33 CEST] <BBB> (I suppose) [18:14:39 CEST] <JEEB> it's really, really old [18:14:40 CEST] <BBB> you could upgrade yasm, but why would you do that [18:14:42 CEST] <BBB> thats effort [18:14:43 CEST] <JEEB> like 2011 old [18:14:47 CEST] <Daemon404> anyone know what their "unix32" platform is [18:14:59 CEST] <Daemon404> theyre hard disabling posix_memalign, for example, on it [18:15:03 CEST] <Daemon404> which seems all sorts of wrong [18:15:32 CEST] <cone-261> ffmpeg 03Paul B Mahol 07master:c5d2d3dced64: avcodec/alac: fix 20-bit support [18:15:35 CEST] <JEEB> inb4 common unixy 32bit one [18:15:59 CEST] <BBB> isnt posix_memalign mac-only? [18:16:12 CEST] <Daemon404> no it's linux [18:16:29 CEST] <Daemon404> and bsd [18:16:55 CEST] <Daemon404> i wonder if it has to do with mozilla using jemalloc [18:16:59 CEST] <Daemon404> or some custom allocator [18:17:01 CEST] <Daemon404> (probably) [18:18:05 CEST] <Daemon404> https://hg.mozilla.org/mozilla-central/file/tip/media/ffvpx/libavutil_visib… <-- or this [18:18:41 CEST] <wm4> ? [18:19:03 CEST] <Daemon404> it seems odd to say the least [18:20:48 CEST] <BBB> ubitux: mozilla loves you ^^ [18:21:19 CEST] <BBB> theres no darwin32.asm [18:21:41 CEST] <Daemon404> look at the mozilla readme [18:21:43 CEST] <Daemon404> they hard disable it [18:22:19 CEST] <ubitux> BBB: mmh? how so [18:22:32 CEST] <BBB> wth [18:22:38 CEST] <BBB> they disable all assembly on 32bit? [18:22:48 CEST] <Daemon404> for darwin [18:22:51 CEST] <BBB> is that b/c we dont allow relocations (-fPIC) on 32bit? [18:22:59 CEST] <BBB> for linux (unix32) also [18:23:27 CEST] <jamrial> firefox 46 (out for a week by now) supposedly already uses ffvp9 [18:23:40 CEST] <Daemon404> BBB, they also hard disable aligned alloc... [18:23:52 CEST] <Daemon404> im thinking maybe their own allocator (jemalloc) isnt aligned enough on 32? [18:23:55 CEST] <Daemon404> just a guess. [18:23:55 CEST] <BBB> on 32bit linux [18:23:59 CEST] <BBB> strange [18:24:24 CEST] <BBB> well I hope it works for them [18:24:53 CEST] <JEEB> I have completely lost the idea of what's available with which version as I've been on either the nightlies or the dev. edition for so long [18:25:32 CEST] <Daemon404> actually you can maybe ask jya [18:25:38 CEST] <Daemon404> he works on firefox's video stuff iirc. [18:25:40 CEST] <Daemon404> and is in here. [18:26:58 CEST] <BtbN> philipl, did you ever test the lossless nvenc modes? I'm quite sure they don't work at all on Kepler, but aparently they also don't work on maxwell, where they should work? [18:28:20 CEST] <ffuser> not work here too, gtx660 [18:29:54 CEST] <BtbN> that's not maxwell [19:01:53 CEST] <BtbN> hm, was hoping i could get an AWS GPU instance to test with, but it's Kepler. [19:02:53 CEST] <llogan> BtbN: they offer grid k520 or something like that right? [19:03:01 CEST] <BtbN> yep, exactly that. [19:03:09 CEST] <BtbN> or some older Fermi one, which doesn't help. [19:03:50 CEST] <BtbN> My Laptop has a Maxwell GPU, but they removed the video unit, or blocked using it. [19:04:11 CEST] <BtbN> no vdpau, no nvenc. [19:07:14 CEST] <llogan> maybe the project could buy one for dev use [19:07:48 CEST] <kierank> vlc has one iirc [19:08:18 CEST] <BtbN> Unfortunately there is no cheap GT Maxwell card, like i got myself for the initial nvenc stuff. It was like 40¬. [19:10:23 CEST] <Compn> j-b : is there a process or form to get reimbursed for hardware dev purchases? ^^^ [19:11:04 CEST] <BtbN> The problem with a more powerfull Maxwell GTX card is that I'm quite sure my sandybridge-generation mainboard would die. [19:11:27 CEST] <nevcairiel> the cheapest is the gtx750 for around 100 [19:11:50 CEST] <BtbN> 750 is maxwell? [19:11:57 CEST] <nevcairiel> yes [19:12:07 CEST] <BtbN> Does it already have the new nvenc stuff? [19:12:42 CEST] <nevcairiel> i dont know when that was introduced [19:12:56 CEST] <BtbN> there are basically two maxwell generations. [19:13:03 CEST] <JEEB> I think the 750 was released around the time of the 960 [19:13:09 CEST] <nevcairiel> no the 750 is much older [19:13:13 CEST] <JEEB> oh [19:13:14 CEST] <nevcairiel> it was the very first maxwell card ever [19:13:14 CEST] <JEEB> ok [19:13:26 CEST] <JEEB> yeah, then it has an older HWenc [19:13:39 CEST] <BtbN> I'm quite sure for all the new nvenc and vdpau features one needs a GM20x chip [19:13:50 CEST] <BtbN> according to Wikipedia the 750 has a GM107 [19:14:05 CEST] <nevcairiel> for the full decode features you need one specific chip, the GM206, which is only on gtx950 and 960 [19:14:35 CEST] <BtbN> strange stuff. [19:14:50 CEST] <BtbN> There is also a GT930 rumored to be released at some point, with a GM108 [19:14:53 CEST] <BtbN> whatever that is [19:15:00 CEST] <nevcairiel> its just newer then the others, and got the newer media chip [19:15:06 CEST] <llogan> the gtx 950 isn't terribly expensive. ~$140 USD [19:15:06 CEST] <wm4> is here a nvidia chip which actually does 4:4:4? [19:15:13 CEST] <nevcairiel> the next generation will likely inherit this [19:15:18 CEST] <JEEB> wm4: supposedly yes [19:15:32 CEST] <JEEB> the driver has 4:4:4 encoding and decoding modes, IIRC [19:15:35 CEST] <wm4> oh wait the GPU I have pretends to support 4:4:4 [19:15:38 CEST] <nevcairiel> oddly enough there is 444 encoding but not decoding =p [19:16:02 CEST] <wm4> H264_HIGH_444_PREDICTIVE [19:16:31 CEST] <llogan> kierank: how can we get our grubby hands on the vlc one? [19:16:39 CEST] <kierank> ask j-b [19:17:27 CEST] <BtbN> I'll get a new PC this christmas, hopefully Intel and Nvidia have their next generations out by then. [19:17:37 CEST] <nevcairiel> nvidia launches in summer [19:17:50 CEST] <nevcairiel> intel, who knows when [19:17:58 CEST] <BtbN> Yeah, Nvidia isn't the one I'm worried about. [19:18:07 CEST] <BtbN> But Kaby Lake would be nice to have [19:18:20 CEST] <BtbN> 10bit HEVC via VAAPI... [19:19:25 CEST] <llogan> Maybe Agatha will give you an nvidia [19:22:06 CEST] <wm4> BtbN: when is that supposed to come out? [19:22:14 CEST] <BtbN> Kaby Lake? [19:22:38 CEST] <wm4> yeah [19:22:41 CEST] <BtbN> "anticipated to enter volume production towards late-2016" [19:22:54 CEST] <wm4> and wasn't Broxton cancelled or something? [19:23:18 CEST] <BtbN> Cannonlake was delayed [19:23:31 CEST] <BtbN> and they release Kaby Lake instead, which is just some minor refresh of Skylake [19:23:41 CEST] <wm4> meh all those codenames [19:24:02 CEST] <BtbN> Broxton is a SoC Platform iirc [19:24:42 CEST] <Compn> are we supposed to optimize for possible vaporware or flop hard ware ? [19:33:49 CEST] <rcombs> Broxton is supposed to have HEVC Main 10 decoding [19:34:18 CEST] <BtbN> i guess because it contains the Kaby Lake CPU/GPU [19:39:56 CEST] <rcombs> (at least, so says the vaapi intel driver repo) [19:46:45 CEST] <nevcairiel> guess we'll never know that now that broxton is dead =p [19:46:46 CEST] <jkqxz> Apollo Lake (Braswell++) isn't cancelled (yet) and will have it. [19:46:53 CEST] <fritsch> :-( [19:47:24 CEST] <fritsch> i really waited for broxton [19:47:26 CEST] <jkqxz> (Core the same as Broxton, different SoC.) [19:47:29 CEST] <fritsch> great potential as set top box [19:47:34 CEST] <fritsch> and cheap [19:48:13 CEST] <nevcairiel> broxton is smartphone/tablet market, apollo lake always was meant as the braswell replacement for NUCs et al [19:49:45 CEST] <fritsch> ETA? end 2016 right? [19:50:01 CEST] <nevcairiel> probably there abouts [19:54:29 CEST] <wm4> fritsch: so what's the vaapi 10 bit situation? [20:04:13 CEST] <fritsch> wm4: driver has it all [20:04:22 CEST] <fritsch> wm4: ffmpeg needs the 10 bit bits [20:04:37 CEST] <fritsch> wm4: and no one replied to our "we need a 16 bit mesa egl interop" [20:05:37 CEST] <fritsch> the hevc 8 to 10 bit in the driver was just 4 fields iirc [20:05:46 CEST] <fritsch> so that one should not be too much work [20:06:03 CEST] <fritsch> but without hw to test it's not really something one can accomplish yet [20:06:10 CEST] <nevcairiel> Did they define a proper output format yet? [20:06:31 CEST] <fritsch> from the driver they use vaPutSurface with RGB [20:06:47 CEST] <fritsch> they defined some P010 format (i always forget the name) [20:07:33 CEST] <fritsch> a) https://cgit.freedesktop.org/vaapi/intel-driver/commit/?id=daf8f6c76287452f… [20:07:46 CEST] <fritsch> b) https://cgit.freedesktop.org/vaapi/intel-driver/commit/?id=8fadc325d12b86e0… [20:09:11 CEST] <fritsch> #define I_P010 2, 2, 2, {I965_16BITS, I965_8BITS}, 3, { {PLANE_0, OFFSET_0}, {PLANE_1, OFFSET_0}, {PLANE_1, OFFSET_16} } [20:11:07 CEST] <wm4> please not through rgb... [20:11:25 CEST] <fritsch> they need to do that [20:11:33 CEST] <fritsch> as it needs vaPutSurface comaptibility [20:11:46 CEST] <fritsch> but - we want the "real" layoutted surface without vpp processing [20:11:49 CEST] <wm4> yeah, but if that's the only path [20:11:57 CEST] <fritsch> for now - it is, yes :-( [20:12:08 CEST] <fritsch> as we can only map NV12 and RGBA [20:12:19 CEST] <fritsch> in theory from the "bits" it should fit into RGBA [20:12:23 CEST] <wm4> what's the problem with 16 bit support? [20:12:33 CEST] <llogan> that ticket will now never close [20:12:36 CEST] <fritsch> it's not there yet - we only have G8B8 or something [20:12:40 CEST] <fritsch> in the mesa thingy [20:13:48 CEST] <fritsch> 32 bit RGBA should be fine (as transport) but I did not look into detail, if one could "tunnel" the 16 bit layouted buffers that way ... [20:14:03 CEST] <fritsch> though the shaders at our other end don't care (can be made to not care) [20:14:45 CEST] <wm4> same here [20:32:02 CEST] <JEEB> holy... [20:32:15 CEST] <JEEB> would've not thought I'd already see test streams for AC-4 or MPEG-H Audio [20:35:06 CEST] <JEEB> http://dashif.org/test-vectors/#MCA_DOLBY [20:35:15 CEST] <JEEB> and then if one scrolls down there's MPEG-H [20:35:32 CEST] <wm4> wtf is mpeg-h [20:35:42 CEST] <JEEB> where HEVC resides [20:35:56 CEST] <JEEB> there was a theoretical audio format there... I guess it got finalized'ish? [20:37:02 CEST] <JEEB> yeah, seems to have been published late last year https://www.itscj.ipsj.or.jp/sc29/29w42911.htm#MPEG-H [20:37:11 CEST] <JEEB> (Part 3= [20:37:34 CEST] <Shiz> great, a new container [20:37:42 CEST] <Shiz> JEEB: >3D audio [20:37:44 CEST] <Shiz> OUT [20:37:48 CEST] <JEEB> the MMT thing is weird [20:37:53 CEST] <JEEB> like, really weird [20:38:06 CEST] <JEEB> I might have understood it at some point but it seems like a metacontainer [20:38:10 CEST] <JEEB> rather than an actual container [20:38:24 CEST] <JEEB> bases a lot on ISOBMFF [20:38:49 CEST] <Daemon404> object-based audio: for 0 people's home setups [20:38:58 CEST] <Daemon404> unless i replace all my walls with speakers [20:43:45 CEST] <wm4> "finding ways to make money with patented garbage" [20:45:55 CEST] <rcombs> isn't 3D audio aka fancy stereo [20:46:33 CEST] Action: rcombs crosses fingers AC-4 never gains adoption [20:54:35 CEST] <rcombs> JEEB: AC-4: http://puu.sh/oHpDD/348f7d6867.png [20:55:57 CEST] <JEEB> :D [20:55:59 CEST] <JEEB> pretty much [20:57:12 CEST] <TD-Linux> so AC-4 is different than Dolby Atmos Home Theater? [20:57:39 CEST] <JEEB> if it's object based stuff then it's highly likely that one is the marketing name for the other [20:57:49 CEST] <nevcairiel> no its a different format [20:57:53 CEST] <JEEB> ah [20:58:34 CEST] <nevcairiel> they seem to target ac-4 at broadcast more directly [21:00:14 CEST] <TD-Linux> I guess broadcast has different requirements, such as the format not being secret [21:01:16 CEST] <JEEB> it can be very close to that, though. looking at the DTS "specs" :) [21:01:24 CEST] <nevcairiel> who broadcasts dts? [21:01:28 CEST] <Daemon404> america [21:01:32 CEST] <nevcairiel> really? [21:01:37 CEST] <nevcairiel> i though its all ac3 or mp2 [21:02:07 CEST] <TD-Linux> we also use 8VSB. sorry [21:02:18 CEST] <JEEB> they tried to push it at least, but I have no idea if it's actually used [21:02:40 CEST] <JEEB> just saying that getting into the race doesn't require the spec to be complete :) [21:02:41 CEST] <Daemon404> dts is in atsc [21:02:47 CEST] <JEEB> oh lol [21:03:21 CEST] <rcombs> Amos is an extension stream in TrueHD, right? [21:03:25 CEST] <rcombs> *Atmos [21:03:27 CEST] <nevcairiel> isnt A/52 even a ATSC spec [21:03:29 CEST] <rcombs> or can it also be carried separately [21:03:49 CEST] <wm4> I still wonder whether or not atmos passthrough works with the ffmpeg spdif muxer [21:03:53 CEST] <nevcairiel> rcombs: the consumer variant is just an extension on top of an existing 5.1 or 7.1 stream [21:04:03 CEST] <nevcairiel> wm4: works for my users, or so they claim [21:04:09 CEST] <rcombs> "works" [21:04:19 CEST] <rcombs> "turns on the atmos light" [21:04:25 CEST] <wm4> yeah that [21:04:27 CEST] <Daemon404> nevcairiel, who the hell has atmos equpment at home [21:04:29 CEST] <wm4> the light is the important part [21:04:31 CEST] <nevcairiel> dunno [21:04:32 CEST] <nevcairiel> not me [21:04:37 CEST] <nevcairiel> i dont even use a HDMI receiver anymore [21:04:42 CEST] <rcombs> I have a receiver that allegedly supports it [21:04:47 CEST] <rcombs> (for testing the LED) [21:04:56 CEST] <JEEB> :D [21:05:10 CEST] <JEEB> those magical leds [21:05:17 CEST] <rcombs> apparently it supports height channels [21:05:29 CEST] <nevcairiel> yeah consumer atmos is just height channels so far, either 2 or 4 [21:05:32 CEST] <rcombs> (only if you don't use the surround-back channels) [21:05:36 CEST] <nevcairiel> on top of a base surround signal [21:06:45 CEST] <rcombs> iirc they call it 5.1.2 [21:06:53 CEST] <nevcairiel> indeed [21:07:04 CEST] <nevcairiel> the 5.1 signal is just base truehd and untoucehd by the extension [21:07:05 CEST] <rcombs> can't do 7.1.2 'cause that would require more physical equipment [21:07:16 CEST] <wm4> (lol) [21:07:18 CEST] <nevcairiel> there are receivers with full 7.1.4 [21:07:24 CEST] <nevcairiel> you just cheaped out! [21:07:25 CEST] <nevcairiel> :D [21:07:35 CEST] <rcombs> my setup's just 5.1 [21:07:42 CEST] <rcombs> like, y'know, everybody [21:08:05 CEST] <nevcairiel> i have 7.1 [21:08:09 CEST] <nevcairiel> although no height channels [21:08:16 CEST] <nevcairiel> (or an atmos receiver for that matter) [21:08:29 CEST] <rcombs> I have an atoms receiver [21:08:41 CEST] <rcombs> it's made entirely of matter [21:10:01 CEST] <cone-261> ffmpeg 03Petru Rares Sincraian 07master:7a679e4ac099: fate: Add test for vorbis encoder [21:16:00 CEST] <jamrial> why do we still have that encoder? we even discourage it's use everywhere it's mentioned [21:17:45 CEST] <Daemon404> jamrial, in case war breaks out [21:17:49 CEST] <Daemon404> we can use it as a weapon [21:19:02 CEST] <jamrial> i mean, it's apparently so bad that not even the ogg muxer dares using it as a default if libvorbis is missing. it uses FLAC instead [21:32:17 CEST] <durandal_1707> clueless people are clueless [21:35:57 CEST] <RiCON> jamrial: isn't that because it needs -strict or something? [21:47:03 CEST] <jamrial> ah, true [21:51:53 CEST] <TD-Linux> Daemon404, less a weapon and more a doomsday device [22:26:14 CEST] <Daemon404> 42 [22:28:08 CEST] <durandal_1707> yes, answer to universe and everything [00:00:00 CEST] --- Fri May 6 2016

1 0

ffmpeg.log.20160505
by burek 06 May '16

06 May '16

[00:05:50 CEST] <ajsharp> anyone here have experience with overlay? having an issue where the video stops if the main video is shorter than the pip: http://ffmpeg.gusari.org/viewtopic.php?f=11&t=2830&p=8517#p8517 [00:06:17 CEST] <bruber> ajsharp: check the man pages for ffmpeg-filters [00:06:27 CEST] <bruber> ajsharp: there's an option that addresses that [00:06:38 CEST] <ajsharp> yea, i've already tried it to no avail :( [00:06:51 CEST] <ajsharp> you're probably talking about "shortest" [00:07:07 CEST] <bruber> ajsharp: eof_action [00:07:13 CEST] <ajsharp> yea, tried that too [00:07:38 CEST] <ajsharp> "The action to take when EOF is encountered on the secondary input; it accepts one of the following values:" [00:07:44 CEST] <ajsharp> my problem is on the main input [00:07:49 CEST] <ajsharp> when the main input is shorter than the secondary [00:08:02 CEST] <ajsharp> i want the main to freeze and the secondary to continue [00:08:40 CEST] <bruber> ahh.just swap your main and secondary inputs... you'll need to pad your overlay ot the size of the main, which will slow down rendering, and you'll need to alpha mask the overlay where the pip is [00:08:41 CEST] <ajsharp> maybe i need to detect which input is longer and always assign the main input to the longer one? [00:09:30 CEST] <ajsharp> i guess i can just use file size as a proxy for which should be the main and which should be secondary? [00:10:04 CEST] <bruber> I'm assuming you're using bash, or similar?> [00:10:30 CEST] <ajsharp> yea [00:11:20 CEST] <ajsharp> why is there some metadata i can read off the first few lines of the file or something? [00:12:27 CEST] <bruber> ffprobe with a -show_streams and whatever option gets you the best output, pipe it to sed to get the times, pipe it to bc or similar to pick the longest, and keep track of it all w/ bash vars [00:12:41 CEST] <ajsharp> right [00:12:59 CEST] <ajsharp> is there a particular reason i wouldn't just use file size as a proxy if i want to keep it a lil simpler? [00:12:59 CEST] <bruber> or write up a quick-n-dirty python/ruby/etc... script to do the same [00:13:02 CEST] <ajsharp> (and faster) [00:13:23 CEST] <bruber> compression ratio will probably differ, unless all of your sources are CBR [00:13:38 CEST] <ajsharp> sources are uniform from ios devices [00:14:06 CEST] <bruber> uniform codec, probably h.264. differing content will cause varying bitrate [00:14:18 CEST] <ajsharp> hmm [00:14:18 CEST] <ajsharp> got it [00:14:45 CEST] <bruber> ffprobe will report actual length (the actual length that's in the metadata... you can make it count frames, but it's slow) [00:15:09 CEST] <ajsharp> so, why is the pad and alpha necessary? [00:15:30 CEST] <bruber> also, watch out for variable frame rate... don't know about ios devices, but some mobile/embedded video sources ***really*** want to use variable fps for efficiency [00:15:40 CEST] <ajsharp> currently just doing this: [1:v]scale=iw/4:-1[ovrl] [00:16:03 CEST] <ajsharp> @bruber will that crash the encoding? or do i need to normalize the frame rate? [00:16:19 CEST] <ajsharp> b/c you're right, some devices record at different frame rates, or variable in some cases i believe [00:19:21 CEST] <bruber> so, you're picking the longer video, and making it the primary input to overlay. then, overlay can repeat the last frame of or end the secondary when it runs out of time... [00:20:16 CEST] <ajsharp> right yea, the eof_action [00:20:42 CEST] <bruber> ... if it happens that you want the longer video "on top" of the shorter, you'll need to do scale=iw/4:-1, then pad it up to the size of the secondary video (with the appropriate offsets)... [00:22:01 CEST] <bruber> then, because it's primary to overlay, the secondary video, which is the original dimension, needs to have a 0.0 alpha hole in it where the primary will show through [00:22:17 CEST] <ajsharp> right [00:22:39 CEST] <ajsharp> sucks there isn't another way to say which video you want "on top" [00:23:12 CEST] <bruber> on the fly, you can generate a greyscale image, all white with a black square in the place of the PIP, then feed it into the alphamerge filter [00:25:54 CEST] <ajsharp> do i need to do that, or is this possible just with pad?d [00:26:21 CEST] <ajsharp> oh that's the alpha mask you were talking about [00:26:25 CEST] <bruber> don't think it'll work out the way you want w/o alpha [00:26:32 CEST] <kepstin> hmm. maybe I should make a filter that just repeats the last frame of a video at constant fps. I've needed to do that a few times :/ [00:26:53 CEST] <ajsharp> @kepstin yep [00:27:14 CEST] <pfelt> afternoon all. i'm playing with a decklink quad card where i'm trying to crop the video into two halves and outputting half to two outputs. i'm seeing performace issues, however one cpu of 40 (hyperthreaded) is nearly maxed and the rest are empty. is there a way to thread it such that i can spread the load without trying to use named pipes? [00:36:47 CEST] <pfelt> or conversely, i do have to -pix_fmt uyvy422 on both output streams. if i remove that option on one of the two it seems to be able to keep up. is there any good way to do that uyvy convert once and not on both output streams? [00:37:11 CEST] <bruber> Speaking of overlays and multiple inputs... I need to take two videos, time stretch one by a known number of frames, and overlay them... say, it's 20 frames over the course of a 50000 frames... I should be able to do something like setpts=PTS+20*N/50000 ... right? But, when I then use that as an input to overlay, I don't get the drift I'm looking for... [00:39:15 CEST] <bruber> pfelt: the pixel format isn't a conversion. that's the data format being delivered by the decklink. it's also really fast to convert to a planar format, which is probably happening in your filter graph anyway. it's almost certainly not the source of the performance promblem [00:39:50 CEST] <bruber> pfelt: what resolution and bit depth are you using w/ the decklinlk? [00:39:51 CEST] <pfelt> bruber: it's just odd that i can keep up fine up till i add that to my outputs [00:40:10 CEST] <pfelt> 1920x1080. i believe uyvy422 is 8bit ? [00:40:26 CEST] <bruber> pfelt: ahh... sorry.. misread. decklink is the output. [00:40:34 CEST] <pfelt> yep :( [00:41:00 CEST] <pfelt> ideally i could thread output a frame to each decklink, but synchronization might be a problem [00:41:26 CEST] <bruber> still... it's fast to go from planar to packed... just try it rendering out to a nullsink to see the performance difference. [00:41:47 CEST] <pfelt> i think i'm able to get to about 27fps, where i need 30. so i'm only slightly behind [00:41:56 CEST] <pfelt> ok. i can try that. [00:41:59 CEST] <bruber> 30, or 29.97? [00:42:08 CEST] <pfelt> 29.97. /me is lazy [00:42:13 CEST] <pfelt> and i know it matters here [00:42:15 CEST] <pfelt> :D [00:42:24 CEST] <bruber> ok... make sure you're not trying to do 30... use 30000/1001 [00:42:45 CEST] <bruber> or 29.97002997 [00:43:06 CEST] <bruber> otherwise, the NTSC gods will smite you [00:43:30 CEST] <pfelt> Stream #3:0: Video: wrapped_avframe, uyvy422, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn [00:43:47 CEST] <pfelt> that's interesting though. so you were right. when going to /dev/null i'm getting 32fps [00:44:14 CEST] <pfelt> though my proc seems to be about equally utilized [00:44:28 CEST] <pfelt> so maybe this is really an issue with getting frames out to the decklink [00:45:00 CEST] <bruber> I don't know anything about the queue structure of the decklink output driver... I do know that the hardware outputs don't share a phase-locked reference clock [00:45:21 CEST] <bruber> so, your fear of sync problems is valid [00:45:29 CEST] <bruber> s/is/may be/ [00:46:25 CEST] <bruber> I deal with this on a daily basis, but from multiple decklink/intensity devices (separate PCIe cards on the same backplane) [00:46:54 CEST] <bruber> and on the input side... I don't use them for output, but ingest... [00:47:35 CEST] <bruber> the only way do deal with it there, and stay sane, is to align all of the sources to a common reference clock [00:48:29 CEST] <bruber> even frame-sync devices are just cheats, and the jitter they introduce starts to matter with certain types of content [00:54:06 CEST] <bruber> I should have said, the hardware *inputs* don't share a phase-locked clock... They're seen as separate cards at the kernel level, and can even be set to different formats & frame rates... I don't actually know about the outputs [00:55:13 CEST] <bruber> ... and I don't actually use ffmpeg to interface with them... just libavformat/libavcodec to do my heavy lifting... [01:03:21 CEST] <bruber> pfelt: what's your source? [01:12:09 CEST] <rsully> I'm using the compile guide for ubuntu on the site and I added webp to it, but when I run ffmpeg it tells me it can't find libwebp.so.6 - is there something special I need to do to make it statically linked? [01:18:49 CEST] <pfelt> bruber: source is a multicast stream. i've even tried scaling that way up to 3840x2160 so that i don't have to scale the outputs [01:19:10 CEST] <pfelt> bruber: so did you write your ingest code? we've tried, with no luck, to use ffmpeg for ingest over sdi [01:19:18 CEST] <pfelt> (these are actually the new dual quad cards) [01:27:18 CEST] <pfelt> and the more outputs i turn on the more apparently slow the video goes. it really feels like i'm playing about 95% actual speed [01:28:51 CEST] <llogan> rsully: why are you using webp? i've never heard of anyone using that. [01:51:55 CEST] <rsully> llogan I mean the point of having a box with ffmpeg is to have something I can throw literally anything at - if webp is supported why wouldn't I compile with it? [01:53:42 CEST] <c_14> rsully: well, you need to compile libwebp statically [01:54:26 CEST] <llogan> ffmpeg has a native webp decoder [01:56:43 CEST] <llogan> rsully: i assume you're going to try to attempt to enable every conceivable external library then? [01:57:23 CEST] <rsully> llogan not all - but a good amount. compiles fine, so far I've only gotten to libwebp runtime error - not sure if the rest work [01:58:16 CEST] <rsully> using this configure: http://pastie.org/private/yksf3sb6okxj4ls4o2zya [01:58:51 CEST] <rsully> based off of my build on my Mac from homebrew [01:59:19 CEST] <llogan> "--enable-hardcoded-tables" [02:01:06 CEST] <llogan> you don't need --enable-librtmp. the native implementation should be just fine. [02:01:20 CEST] <llogan> --enable-pthreads is autodetected so you don't need that [02:02:32 CEST] <rsully> any pro/con for hardcoded tables? [02:02:36 CEST] <rsully> I'll drop the other 2 [02:04:43 CEST] <llogan> see note in https://trac.ffmpeg.org/wiki/CompilationGuide [02:04:46 CEST] <rsully> and I compiled libwebp with --enable-static [02:05:12 CEST] <rsully> kk so not a big deal [03:03:13 CEST] <rsully> llogan any other ideas? still can't get this to link statically [03:05:43 CEST] <llogan> rsully: you can just skip stupid webpee [03:06:06 CEST] <rsully> libwebp* [03:06:15 CEST] <rsully> does ffmpeg come with good support for encode/decode of that? [03:06:25 CEST] <rsully> not that this should be hard to fix anyways [03:06:54 CEST] <llogan> it comes with a native weburine decoder [03:10:33 CEST] <furq> rsully: you can try adding -Wl,-Bstatic to extra-ldflags to force everything to be static linked [03:11:23 CEST] <rsully> I am trying "--extra-cflags=--static --extra-libs=-static" now, and having to compile some dependencies from scratch since the OS packages do not ship the static files [03:11:41 CEST] <furq> i don't think either of those are things [03:11:50 CEST] <rsully> well it certainly broke my ./configure step [03:11:53 CEST] <furq> -static or -Wl,-Bstatic would go in extra-ldflags [03:12:11 CEST] <rsully> I got those 2 flags from https://ffmpeg.org/pipermail/ffmpeg-user/2011-August/002112.html [03:12:15 CEST] <c_14> theres --pkg-config-flags=--static or something [03:12:28 CEST] <rsully> I already had that one [03:12:38 CEST] <furq> that wouldn't make a difference [03:12:48 CEST] <furq> that just tells pkg-config to also spit out the Libs.private section [03:17:51 CEST] <rsully> I'll try without libwebp for the moment just to see if it actually works, or if there is another problem lurking behind this corner [03:18:59 CEST] <relaxed> you need --extra-ldflags="-L$HOME/ffmpeg_build/lib -static" [03:19:51 CEST] <rsully> ah ok, I will try that next [03:19:59 CEST] <furq> they should both do the same thing here [03:20:15 CEST] <relaxed> both of what? [03:20:23 CEST] <furq> -static and -Wl,-Bstatic [03:20:45 CEST] <relaxed> I don't use the latter [03:20:53 CEST] <relaxed> and --pkg-config-flags="--static" is required [03:21:04 CEST] <furq> yeah it is but it won't solve this problem [03:22:00 CEST] <furq> out of interest, do you static link a libc into your binaries [03:22:10 CEST] <furq> i assume you have to [03:22:18 CEST] <relaxed> I do, glibc [03:22:21 CEST] <rsully> ok so without libwebp, ffmpeg does run without lib errors [03:22:24 CEST] <furq> oh [03:22:27 CEST] <furq> i didn't think that would work properly [03:22:38 CEST] <rsully> I will add libwebp again now and try with the above flags [03:22:46 CEST] <furq> not that i've ever needed to, but i read it on the almighty stack overflow [03:23:14 CEST] <rsully> relaxed is there a benefit to linking glibc static? [03:23:22 CEST] <furq> portability [03:23:49 CEST] <furq> i'm not sure how much difference it makes on OSX, although it wouldn't be glibc there [03:24:16 CEST] <rsully> I'm compiling for ubuntu [03:24:31 CEST] <furq> oh [03:24:35 CEST] <furq> why did i think you were on OSX [03:24:44 CEST] <relaxed> I think he is [03:24:46 CEST] <rsully> I mentioned homebrew, because that is where I copied my configure flags from [03:24:50 CEST] <furq> ah [03:25:13 CEST] <furq> well yeah static linking glibc is only of value if you want to use the binaries on any linux machine [03:25:22 CEST] <rsully> so adding -static to extra-ldflags gives me "libass not founding using pkg-config" [03:25:40 CEST] <furq> did you do --pkg-config-flags="--static" [03:25:41 CEST] <relaxed> rsully: now you're getting somewhere! [03:25:45 CEST] <rsully> now I did compile libass in ~/ffmpeg_build [03:25:50 CEST] <furq> or --pkg-config="pkg-config --static" works too [03:25:51 CEST] <rsully> furq yes I've had that this whole time [03:25:56 CEST] <relaxed> look at config.log [03:25:58 CEST] <furq> ^ [03:26:09 CEST] <rsully> /usr/bin/ld: cannot find -lfribidi [03:26:16 CEST] <furq> fun [03:26:27 CEST] <relaxed> down the rabbit hole you go [03:26:36 CEST] <rsully> libfribid-dev is installed from apt [03:26:47 CEST] <furq> did it install a static lib [03:26:52 CEST] <rsully> mm how can i check [03:27:06 CEST] <furq> https://packages.debian.org/stretch/amd64/libfribidi-dev/filelist [03:27:08 CEST] <furq> apparently not [03:27:09 CEST] <rsully> (though I'm guessing not) [03:27:27 CEST] <furq> find /usr/lib -name libfribidi*.a [03:27:31 CEST] <furq> if you want to make absolutely sure [03:27:40 CEST] <rsully> not found [03:27:44 CEST] <rsully> (i did /) [03:28:00 CEST] <furq> it'll always be /usr/lib if you installed from apt [03:28:08 CEST] <rsully> so next step, compile that? [03:28:13 CEST] <furq> looks like it [03:28:23 CEST] <furq> or file a debian bug, since that should definitely be in the dev package [03:28:28 CEST] <furq> and then wait six months [03:28:31 CEST] <rsully> hehe [03:28:36 CEST] <furq> or even longer, actually, since you're on ubuntu [03:29:16 CEST] <relaxed> you'll need to compile static libs of the dependencies for each external lib you --enable-* for ffmpeg [03:29:27 CEST] <furq> well most of them should be available in apt [03:29:33 CEST] <relaxed> but don't worry, it's really fun :/ [03:30:16 CEST] <furq> i have a makefile (and ~40 sub-makefiles) which does all this, but it's only for mingw [03:30:23 CEST] <furq> i should probably genericise it, if that's even a word [03:30:32 CEST] <rsully> it would sure help people like me ;D [03:31:33 CEST] <rsully> I am documenting all my commands though [03:32:22 CEST] <furq> it wouldn't be that hard, i just lack a decent way of testing the builds [03:32:43 CEST] <furq> it's already enough of a pain doing it for mingw without worrying about other platforms [03:33:51 CEST] <rsully> I'm getting some weird error now [03:34:58 CEST] <rsully> tail of config.log: http://pastie.org/private/61uev6m1dvymq12fmzq [03:37:45 CEST] <furq> you probably need to recompile libzmq with libsodium support [03:37:54 CEST] <rsully> libzmq came from apt [03:38:04 CEST] <furq> yeah i checked and the deb package doesn't depend on libsodium [03:38:07 CEST] <furq> but those are libsodium symbols [03:38:27 CEST] <furq> alternatively you could just not include zeromq because i have no idea what it's even for [03:38:32 CEST] <llogan> are you ever going to use the zmq filter? [03:38:42 CEST] <furq> i've never heard of anyone using it [03:38:48 CEST] <furq> in ffmpeg, that is [03:39:10 CEST] <rsully> I mean I'd like to compile with all available options that I *could* potentially use just for sake of having a single kitchen sink binary [03:40:00 CEST] <llogan> honestly, that sounds like a waste of time [03:40:01 CEST] <furq> that's nice but i can almost guarantee you'll never use zmq [03:40:12 CEST] <rsully> alright I'll comment out that option for now [03:40:12 CEST] <furq> or most of the other libs, for that matter, but if they compile then who cares [03:40:40 CEST] <llogan> you can always re-compile later. and if you're using ffmpeg often then you should re-compile occassionally to kepe up to date [03:40:45 CEST] <rsully> yep [03:41:23 CEST] <furq> out of interest, what's missing from relaxed's builds that you need [03:41:36 CEST] <rsully> I haven't seen his builds [03:41:43 CEST] <furq> http://johnvansickle.com/ffmpeg/ [03:41:59 CEST] <rsully> first thing that stands out of libfdk [03:42:03 CEST] <rsully> is8 [03:42:06 CEST] <furq> ah [03:42:06 CEST] <rsully> is** [03:45:33 CEST] <rsully> removing libzmq makes configure succeed, but make fails near end [03:45:33 CEST] <rsully> http://pastie.org/private/bafbwegpfipa46ieqoqgq [03:53:19 CEST] <rsully> gotta go for the night, I'll be back tomorrow to continue this 'fun'. thanks for the help [04:37:22 CEST] <pfelt> are there any good ways to synchronize streams coming out of multiple ffmpeg commands? [04:53:28 CEST] <pfelt> i suppose i need to provide more information for that question. i'm outputting to 4 decklink cards from 4 different ffmpeg processes. i need to synchronize them somehow [05:13:11 CEST] <zarathushtra> #0:0 (h264 (native) -> h264 (libx264)) -> trying to resize a .mkv... but receiving "Error while opening encoder for output stream #0:0" [05:16:05 CEST] <zarathushtra> also putting some subs [05:18:32 CEST] <zarathushtra> i think it worked [05:18:34 CEST] <zarathushtra> lol [06:39:46 CEST] <Tynach> Hi, I'm having troubles with the last frame of variable framerate files. Everything works great except the very last frame, which has the wrong duration in almost all cases. I'm using '-vsync vfr -copytb 1 -copyts -r 20'. The '-r 20' at the end is needed or it pushes timestamps to the nearest half second or so. I'm working with animated .gif files. [06:40:53 CEST] <Tynach> I'm wanting to encode the .gif files into .mp4 files, with the H.264 codec. [06:47:26 CEST] <Tynach> If there's no way to fix the At the very least, is there a way for me to send the last frame twice, the second time having a pts that's 1/fps (fps being 20 in this case, so 0.05) seconds less than the duration of the input file? [06:47:46 CEST] <Tynach> Wow, the start of that post got messed up. [06:48:55 CEST] <Tynach> "If there's no way to fix the last frame's duration, is there at least a way for me to..." [08:58:32 CEST] <fling> Which preset to use for a noisy webcam? [09:04:55 CEST] <operator> ffmpeg says: Stream #0:1: Audio: none, 48000 Hz, 2 channels, 2304 kb/s [09:05:33 CEST] <operator> and cannot play video. How can say which codec should ffmpeg use? [09:34:51 CEST] <EugenA> how to force ffmpeg to play specific audio codec? any help is welcome :-) [09:50:39 CEST] <durandal_1707> EugenA: you mean decode? -c:v codec_name [09:51:29 CEST] <durandal_1707> -c:a pcm_s24le [09:51:42 CEST] <durandal_1707> for audio [10:15:33 CEST] <EugenA> durandal_1707: http://pastebin.com/awg4DPwm [10:16:43 CEST] <EugenA> durandal_1707: ffmpeg cannot recognize audio codec, but it should be pcm_s24le [10:17:26 CEST] <EugenA> so what can I do? file is corrupted? file is created by blackmagic intensity pro 4k hardware [10:18:23 CEST] <EugenA> it worked before.. oder files are normally convertable by ffmpeg [10:25:51 CEST] <durandal_1707> EugenA: put -c:a pcm_s24le in front of your ffmpeg input [14:05:13 CEST] <Prelude2004c> hey guys.. good morning. can anyone tell me why i am getting the errors at the bottom [14:05:14 CEST] <Prelude2004c> http://pastebin.com/raw/kkX1CESg [14:07:27 CEST] <J_Darnley> You keep pressing c [14:07:40 CEST] <jkqxz> Whatever you are sending to stdin is wrong. [14:08:09 CEST] <topcat> would anyone know if I should be able to run ffmpeg in MS' new cut down nanoServer? I run the latest static x64 exe --help and nothing is returned. [14:10:23 CEST] <J_Darnley> It being Microsoft I bet some error message has popped up on some display you can't see. [14:10:54 CEST] <Prelude2004c> hey .. sorry [14:10:57 CEST] <Prelude2004c> http://pastebin.com/raw/j7Fzx7bP [14:11:01 CEST] <topcat> J_Darnley: lol. [14:11:06 CEST] <Prelude2004c> that is the correct pastebin.. [14:11:43 CEST] <Prelude2004c> i am very stuck.. tried to use vdpaul to decode but keeps crashing the nvidia card.. using the library built by nvidia does not crash it but now i have other errors :( hopping to get some help on it [14:12:00 CEST] <J_Darnley> WTF is all that? [14:12:22 CEST] <Prelude2004c> J_Darnley ? you talking to me ? [14:12:34 CEST] <J_Darnley> Yes. [14:13:05 CEST] <Prelude2004c> btw, the idea is this... i have a list of input files.. i want to loop out into fifo.. because i want the second thing to listen and segment. but i don't want the segmenter to close.. i want it to sit there and listen to the input [14:13:46 CEST] <Prelude2004c> as the input will be in a loop.. so it will just keep shuffling the input files..sending them to nvtranscoder to transcode .. and then back out to segment [14:14:47 CEST] <Prelude2004c> no excuse if you see something silly there with stdin .. i been playing with settings. now i dont know which are correct anymore :) [14:15:48 CEST] <Prelude2004c> i have been really struggling with this for a few days.. tried vdpau too with no success.. i am using nvtranscoder successfully with a UDP source input ( live stream ) but.. .now the issue is when i am trying to serve up static files :( [14:18:15 CEST] <Prelude2004c> any suggestions ? [15:18:25 CEST] <bostonmacosx> Hello there [16:08:53 CEST] <IneedHELP> Good day, I need hopefully simple help. [16:08:53 CEST] <pgorley> From what I've read, if I want to implement hardware acceleration, I have to implement it separately for each codec and for each platform/API I want to support. Is this correct? [16:10:21 CEST] <jkqxz> pgorley: Pretty much yes. The platform-specific elements of everything are just fatally different, however much people try to write "generic" APIs for it. [16:10:35 CEST] <pgorley> Ok, thanks [16:10:52 CEST] <IneedHELP> I have a Canon XF100. it gives a video in several .MXF files. can I use this software to make it into one more popular format such as MP4? [16:13:44 CEST] <relaxed> IneedHELP: yes, see https://trac.ffmpeg.org/wiki/Encode/H.264 [16:15:05 CEST] <relaxed> IneedHELP: and https://trac.ffmpeg.org/wiki/Concatenate [16:25:54 CEST] <Fyr> how to set language for audio track? [16:35:49 CEST] <Prelude2004c> hey, anyne know what this means " Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly " [16:35:58 CEST] <Prelude2004c> getting lots of errors when converting a video [16:36:17 CEST] <Fyr> is your output file zero-sized? [16:36:36 CEST] <Prelude2004c> no, there is data [16:36:41 CEST] <Fyr> cool [16:36:42 CEST] <Prelude2004c> the source is doing this.. [mpegts @ 0x3393b20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 3952800 >= -9223372036854775807 [16:37:20 CEST] <Prelude2004c> still struggling to have this stuff working :( .. been at it for days.. nobody can help me so far [16:42:36 CEST] <Prelude2004c> also tons of these too [16:42:37 CEST] <Prelude2004c> [mpegts @ 0x2156b20] pts (230400) < dts (234000) in stream 0 [16:42:37 CEST] <Prelude2004c> [mpegts @ 0x2156b20] pts (237600) < dts (241200) in stream 0 [16:42:37 CEST] <Prelude2004c> [mpegts @ 0x2156b20] pts (244800) < dts (248400) in stream 0 [16:46:16 CEST] <c_14> Fyr: -metadata:s:a:0 lang= [16:46:34 CEST] <Fyr> ok [16:46:43 CEST] <Fyr> how to embed chapters? [16:47:18 CEST] <c_14> do you have a chapter file or does the source have chapters? [16:47:38 CEST] <Fyr> chapter file [16:50:08 CEST] <c_14> Hmm, not sure if/how ffmpeg supports that. Either try adding it as an input and using -map_chapters or you'll have to use something like mkvtoolnix or mp4box [16:50:50 CEST] <Jepp> Is there a way of encoding a video such that B and P frames will not contain I-macroblocks (and only B and P macroblocks respectively)? [16:51:20 CEST] <kepstin> Jepp: with x264? [16:51:45 CEST] <Jepp> kepstin: with anything [16:51:51 CEST] <kepstin> maybe, but you'd probably have to use their api directly rather than go through ffmpeg, and it would reduce coding efficiency [16:52:44 CEST] <kepstin> that doesn't seem like something that would actually be useful to do - why do you want it? [16:53:00 CEST] <Jepp> using mpegflow for motion estimation [16:53:21 CEST] <Jepp> i'm extracting motion vectors from B and P frames [16:53:33 CEST] <Jepp> and whenever there's an I macroblock in one of those, it just gives no information [16:55:02 CEST] <kepstin> right, but you have to remember that motion vector coding in video is a way of improving coding efficiency - it doesn't follow actual motion, it just points you to blocks that are sufficiently similar that there's a coding efficiency gain if you use one as a base [16:55:44 CEST] <kepstin> if you want motion vectors - and for all frames even, including i-frames, why not just run only a motion vector search over the video? [16:56:14 CEST] <Jepp> what do you mean by "motion vector search"? do you mean something like optical flow? [16:57:08 CEST] <iive> it is usually referred as Motion Estimation [16:59:15 CEST] <Jepp> well, the thing is that optical flow just takes too much time, and i can lose a little accuracy for getting an efficiency gain [16:59:52 CEST] <Jepp> extracting motion vectors using mpegflow gives me just that, but it's too inaccurate because of the I macroblocks, I believe [17:00:42 CEST] <kepstin> hmm, you could probably speed it up by using the estimator extracted from a video codec to find candidate motion vectors rather than run a full optical flow analyzer (codecs have a lot of heuristics to make it fast, limit search area) [17:01:37 CEST] <kepstin> would be faster than doing a full video encode anyways [17:02:09 CEST] <Jepp> by feeding the flow i get from the codec motion vectors as an initial guess to an optical flow algorithm? [17:02:46 CEST] <Jepp> encoding is done server-side for me, so i don't care about processing time there too much... [17:02:47 CEST] <Fyr> c_14, http://pastebin.com/wRdZGDdu [17:02:48 CEST] <Fyr> this command sets English to every audio channel. [17:03:14 CEST] <kepstin> you'd run the codec's motion estimator standalone to replace the step you're currently doing of encoding the video then decoding with mpegflow to get the motion vectors [17:05:08 CEST] <Jepp> so i could get motion vectors for the entire frame without doing the encoding - i see. [17:05:14 CEST] <Jepp> (if that's what you mean) [17:05:43 CEST] <kepstin> yeah. and you'd get them for all frames and all blocks, rather than only predicted blocks on predicted frames [17:07:04 CEST] <Jepp> sounds great! i can use their api for that, right? [17:11:33 CEST] <kepstin> not sure, I don't think most codecs expose that as api since it's an internal implementation detail. You *might* be able to use the mpeg or snow one from ffmpeg? But i dunno if that's public or internal api. [17:13:36 CEST] <Jepp> hmm, i'm kind of lost here. could you give me a hint on how to find how to do that? i'm not that familiar with codecs and ffmpeg :( what should i google? [17:16:15 CEST] <kepstin> hmm. looking at the vf_mcdeint.c code might be interesting, that uses the snow encoder in ffmpeg in a motion estimation only mode. Other than that, you'd probably end up copy/pasting some motion estimation from a codec into your application :/ [17:16:38 CEST] <Jepp> sounds like a lot of fun :) [17:16:47 CEST] <Jepp> thanks a lot, i'll look into that! [17:20:11 CEST] <Workflow> Hi Guys, trying to take snapshots from a mp4 file using fps, but starting at a specific start time using -ss, but it seems just to be dropping everything, -t works in terms of setting a duration, but it starts from 00:00:00 [17:20:14 CEST] <Workflow> Any ideas? [17:21:59 CEST] <Fyr> Workflow, what are you trying to do? [17:22:55 CEST] <Workflow> Fyr, I have a recording which is 2 hours long and i'm trying to take snapshots from the video every 2 minutes in the quickest way possible [17:23:38 CEST] <Workflow> So I thought of splitting up into multiple processes to start at specific times in the video for a number of minutes [17:24:33 CEST] <Fyr> Workflow, http://trac.ffmpeg.org/wiki/Create%20a%20thumbnail%20image%20every%20X%20se… [17:24:35 CEST] <Workflow> Unless there is a quicker way to take snapshots from a mp4 every 2 minutes? [17:27:47 CEST] <__jack__> Workflow: all your process will have to read and decode the movie, won't be efficient [17:29:27 CEST] <Workflow> I see, understood. So just lobbing loads of CPU at the one process is the best way to go? [17:37:03 CEST] <__jack__> yep [17:39:44 CEST] <paperManu> hi, I have updated some code so that it compiles with ffmpeg 3.x (following the deprecation warnings and errors), but I get a very high cpu load when reading a video while compiled against ffmpeg 3.0.2 [17:40:00 CEST] <paperManu> is there a guide or something to move from ffmpeg 2.8 to 3.x ? [18:48:15 CEST] <llogan> paperManu: how can we duplicate this issue? [18:48:48 CEST] <zarathushtra> im reencoding a .mkv into a .mp4... its working the way I want but i need to resize it at the same time... im using "ffmpeg -i $1.mkv -c:a mp3 -vf subtitles=$1.srt:charenc=CP1252 got-s${T}e$1.mp4", i need something like -vf screen=-1:480... how would that go? [18:49:21 CEST] <kepstin> zarathushtra: you can put multiple filters into the -vf list separated by commas [18:49:34 CEST] <zarathushtra> a-ha [18:49:52 CEST] <zarathushtra> -vf subtitles=whatever.srt,screen=xxxx [18:49:57 CEST] <zarathushtra> this way? [18:50:28 CEST] <llogan> scale=-2:480,subtitles=foo.srt [18:50:30 CEST] <Fyr> isn't it rendering subtitles into the video? [18:50:50 CEST] <zarathushtra> scale! yea [18:50:55 CEST] <zarathushtra> whats the difference with -2 and -1? [18:51:07 CEST] <zarathushtra> Fyr: the subs are ok, but i want to resize the video too :) [18:51:14 CEST] <llogan> -2 is like -1, but ensures the values is divisible by 2 [18:51:33 CEST] <JEEB> because we needed even more of non-guessable values \o/ [18:51:36 CEST] <llogan> which is needed when encoding with libx264 with 4:2:0 chroma subsampling [18:51:45 CEST] <zarathushtra> oooh cool [18:52:00 CEST] <zarathushtra> i lost many hours trying to figure out those kind of errors lol [18:52:20 CEST] <zarathushtra> thanks for pointing the right direction! its streaming now... lets see the result in a few minutes, but it should work now! thanksss :) [18:52:52 CEST] <llogan> its possible you can simply stream copy the audio isntead of re-encoding it [18:53:28 CEST] <zarathushtra> i know, but i dont think my TV accepts aac :( [18:58:32 CEST] <t4nk247> Hi guys, I was compiling ffmpeg for android. but I am facing this error arm-linux-androideabi/bin/ld: error: cannot find -lfdk-aac how can I solve it? [18:59:00 CEST] <Mavrik> you need to compile FDK-AAC for Android if you want to use it [18:59:11 CEST] <t4nk247> And it finally terminates with collect2: error: ld returned 1 exit status ERROR: libfdk_aac not found [18:59:50 CEST] <t4nk247> I have compiled fdk-aac and the static library can be found at /usr/local/lib [19:00:09 CEST] <Mavrik> Did you compile it for Android with NDK compilers? [19:00:19 CEST] <Mavrik> For armeabi like the ffmpeg binary? [19:01:21 CEST] <t4nk247> No. I just compiled it with --enable-shared --enable-static flags [19:05:14 CEST] <Mavrik> Well your ARM phone won't run x86 code :) [19:06:23 CEST] <llogan> we need someone to provide ARM ffmpeg binaries [19:07:52 CEST] <JEEB> llogan: but not with something that is non-distributable :P [19:08:02 CEST] <JEEB> (fdk-aac is such) [19:08:17 CEST] <llogan> i wasn't suggesting that [19:08:18 CEST] <Mavrik> llogan, for which flavor? :P [19:08:26 CEST] <Mavrik> armeabi ffmpeg is beyond useless :) [19:08:28 CEST] <JEEB> aand yeah, ARM is a mess like that [19:08:57 CEST] <llogan> Mavrik: whichever one someone gives to me [19:09:18 CEST] <relaxed> I plan to have static arm builds soon. [19:09:18 CEST] <Mavrik> hm? [19:09:34 CEST] <llogan> good news, everyone. [19:09:58 CEST] <JEEB> anyways, I build FFmpeg for my mpv-android builds and it doesn't really get simpler than that. of course if you need something like libvorbis, libopus or libx264 then you'll have to poke that, too :P [19:10:09 CEST] <Mavrik> yp [19:10:32 CEST] <Mavrik> It's still annoying because there's very perceptible performance difference between armeabi, armeabi-v7a + NEON and arm64-v8a builds. [19:10:44 CEST] <Mavrik> And that doesn't even include all those silly people trying to use RPis for video processing. [19:11:25 CEST] <JEEB> I loved how the Rpi1's CPU wasn't fast enough for realtime AAC [19:11:45 CEST] <JEEB> "I can encode this video with the HWenc just fine, but muh audiooo... :<" [19:11:52 CEST] <Mavrik> :P [19:12:11 CEST] <Mavrik> I remember using it for Kodi and it couldn't handle DTS decode. [19:12:19 CEST] <JEEB> exactly [19:29:47 CEST] <t4nk247> This was the command that I used to compile fdk_aac: export CC=arm-linux-androideabi-gcc function build_fdk_aac { ./configure --enable-static --enable-shared make make install make distclean ldconfig } build_fdk_aac [19:30:06 CEST] <t4nk247> but I am still getting ERROR: libfdk_aac not found [19:31:03 CEST] <EugenA> is it possible to write and read video file (for broadcast) [19:37:05 CEST] <furq> writing and reading video files is more or less what ffmpeg does [19:38:35 CEST] <t4nk247> This was the command that I used to compile fdk_aac: export CC=arm-linux-androideabi-gcc function build_fdk_aac { ./configure --enable-static --enable-shared make make install make distclean ldconfig } build_fdk_aac but I am still getting ERROR: libfdk_aac not found [19:38:42 CEST] <t4nk247> Where am I mistaken? [20:01:03 CEST] <zarathushtra> please, how can I pass a -c:v OPTION that would guarantee to use "MPEG-4 SP" or ASP? [20:02:41 CEST] <llogan> -c:v mpeg4 [20:03:29 CEST] <llogan> then check with: ffprobe -loglevel error -show_entries stream=profile input.mp4 [20:04:01 CEST] <zarathushtra> tnx mate [21:22:46 CEST] <qvac> can ffmpeg automatic set a bitrate, if the input is like 128? on file i want to convert? [21:23:15 CEST] <Fyr> qvac, it depends on the encoder. [21:23:34 CEST] <Fyr> usually, FFMPEG sets quality (i.e. VBR). [21:23:50 CEST] <qvac> i gonna convert to m4a [21:25:10 CEST] <qvac> Fyr: [21:25:48 CEST] <Fyr> qvac, don't worry, it will automatically set bitrate. [21:26:28 CEST] <Fyr> 128 kbps [21:26:28 CEST] <qvac> Fyr: i mean.. if i convert a 128 bitrate to m4a, it would be 128 right? :) [21:26:34 CEST] <Fyr> yes [21:26:41 CEST] <Fyr> http://ffmpeg.org/ffmpeg-codecs.html#aac [21:26:55 CEST] <Fyr> the documentation concurs. [21:26:56 CEST] <qvac> ffmpeg -i "input.webm" -c:a aac output.m4a [21:26:57 CEST] <Fyr> (= [21:27:03 CEST] <Fyr> right [21:30:09 CEST] <qvac> Fyr: a fast question, higher volyum on the audio in ffmpeg? [21:31:00 CEST] <Fyr> ffmpeg -i input.mp4 -vn -filter:a volume=2dB -f mp4 output_audio.m4a [21:31:57 CEST] <Fyr> you might want to use -vn option, which disables audio in output. [21:32:36 CEST] <Fyr> some audio players get confused if an m4a file contains video inormation, even an empty video stream. [21:32:55 CEST] <Fyr> *-vn disables video [21:33:24 CEST] <qvac> ok [21:34:16 CEST] <devster31> Hi, I managed to cross-compile ffmpeg with some libraries, I didn't set --enable-shared but ffmpeg complains about missing shared libraries, how can I debug? [21:34:58 CEST] <qvac> is it possible to higher volyme same time i convert? [21:35:08 CEST] <Fyr> yes [21:35:38 CEST] <qvac> but if arent mp4? [21:36:09 CEST] <Fyr> qvac, you should try and if you encounter an error, report it here. [21:36:24 CEST] <BtbN> devster31, that only causes the libav* libs to be static or shared [21:36:43 CEST] <BtbN> you have to supply all the dependencies as static libs if you want a full static build. [21:39:24 CEST] <devster31> BtbN: ok, so if both shared and static libraries are present the shared one are chosen? [23:13:07 CEST] <qvac> is this the same thing what Fyr show me? [23:13:10 CEST] <qvac> https://trac.ffmpeg.org/wiki/How%20to%20change%20audio%20volume%20up-down%2… [23:28:31 CEST] <furq> 20:26:28 ( qvac) Fyr: i mean.. if i convert a 128 bitrate to m4a, it would be 128 right? :) [23:28:41 CEST] <furq> just to be clear, it'll only be 128 because that's the default bitrate for aac [23:28:53 CEST] <furq> the input file's bitrate isn't taken into account [23:29:05 CEST] <furq> because it wouldn't make any sense [23:59:40 CEST] <vade> hello. Im successfully using libswscale to convert YUV AVFrames to RGB AVFrames. Im trying to do the inverse now, and running into some hiccups. is it safe to init a frame as av_frame_init() mark its pixel format and full raster width and height (rather than planar half size for UV) and let av_frame_get_buffer do the work to mark the appropriate linesize, etc? [00:00:00 CEST] --- Fri May 6 2016

1 0

ffmpeg-devel.log.20160504
by burek 05 May '16

05 May '16

[00:36:27 CEST] <cone-282> ffmpeg 03Paul B Mahol 07master:3395ad48fa2f: avcodec/adpcm: replace char/short/long with int8_t/int16_t/int [00:43:09 CEST] <durandal_1707> thardin: not enough magic in ffmpeg to use imagemagick [00:43:57 CEST] <Shiz> magick* [00:44:20 CEST] <llogan> i dont think the servers use it either [01:13:52 CEST] <andrey_utkin> is there a way to automatically apply failing FATE tests' diffs to tests/ref/fate/, without manually re-running "make fate"? [01:29:42 CEST] <jamrial> andrey_utkin: "make fate GEN=1" should regenerate ref files for you [01:32:11 CEST] <andrey_utkin> thank you [11:35:42 CEST] <cone-042> ffmpeg 03Paul B Mahol 07master:66eb5b809add: avcodec/adpcm: fix decoding of stereo non 4-bit ADPCM IMA WAV [14:31:53 CEST] <Daemon404> [FFmpeg-devel] A Hackathon for Codec Develovers [14:31:55 CEST] <Daemon404> what am i even reading [14:34:50 CEST] <Compn> i dont see that mail. [14:35:00 CEST] <petrurares> Hi there, I have a doubt. Any body know how to compute CMP_SHIFT with tiny_psnr? [14:35:32 CEST] <petrurares> *CMP_SHIFT variable is used in tests [14:36:54 CEST] <Daemon404> Compn, i do.. [14:37:12 CEST] <Daemon404> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/193839.html [14:37:15 CEST] <Daemon404> so does the archive [14:38:29 CEST] <Shiz> i'm a develover [14:38:40 CEST] <Shiz> nice urls [14:39:12 CEST] <Shiz> what's with the asterisks [14:45:03 CEST] <BBB> that is really scary [14:45:11 CEST] <BBB> I mean, Im all for REing old codecs and stuff [14:45:41 CEST] <BBB> but to use a hackathon as replacement for interview process, thats scary at best and slavery at worst [14:48:18 CEST] <wm4> isn't that common [14:49:33 CEST] <Daemon404> BBB, thats pretty standard in SF [14:49:44 CEST] <Daemon404> and usually they get to keep anything you write too [14:49:46 CEST] <Daemon404> it's retarded. [14:49:53 CEST] <BBB> right, so slavery [14:50:29 CEST] <BBB> if thats standard, Im clearly doing something wrong ;) [14:50:51 CEST] <Daemon404> .. in SF [14:50:54 CEST] <Daemon404> SF is "special" [14:50:57 CEST] <Daemon404> i mean special in a bad way. [14:52:50 CEST] <BBB> :) [14:52:50 CEST] <BBB> so you lived in NY [14:52:51 CEST] <BBB> whats your opinion of Bloomberg? [14:55:11 CEST] <Daemon404> BBB, the company or the news outlet or? [14:55:21 CEST] <BBB> the dude [14:55:24 CEST] <BBB> michael bloomberg [14:55:26 CEST] <Daemon404> oh [14:55:37 CEST] <Daemon404> i didnt form any opinions on politics since i couldnt vote [14:57:20 CEST] <kierank> our mayoral elections are tomorrow [14:57:26 CEST] <DHE> there's a specific recent news article about him. that what you mean? [15:00:32 CEST] <Daemon404> kierank, i think i CAN vote in the EU vote tho [15:00:35 CEST] <Daemon404> and i definitely will be [15:00:39 CEST] <Daemon404> if possible. [15:00:41 CEST] <kierank> ah commonwealth I guess [15:00:45 CEST] <Daemon404> yea [15:00:54 CEST] <kierank> we are such hypocrites [15:01:09 CEST] <Daemon404> what government isnt? [15:01:18 CEST] <Shiz> what person isn't [15:30:03 CEST] <atomnuker> anyone here who could upload a fate sample? [15:36:03 CEST] <durandal_170> I will reply to that spammer to refrain from posting such stuff on our ml [15:38:07 CEST] <wm4> in theory we allow recruiting posts [15:38:22 CEST] <wm4> atomnuker: maybe michaelni or nevcairiel [15:45:13 CEST] <RiCON> from the way they used an obfuscated URL thrice, it looks more like spam than informative [15:56:35 CEST] <Compn> RiCON : i agree, tracking urls are the devil [16:11:36 CEST] <wm4> rkern: want me to push your patches now? [16:41:48 CEST] <rkern> yeah, sounds good [16:57:20 CEST] <Fyr> guys, sorry to bother, but is it only new version, but the previous versions work [16:57:21 CEST] <Fyr> http://trac.ffmpeg.org/ticket/3339 [16:57:21 CEST] <Fyr> ? [16:57:31 CEST] <Fyr> just met exactly the same problem. [16:57:51 CEST] <Fyr> I 'm not sure should I download the older version. [16:58:08 CEST] <Fyr> if so, then what version should I use? [17:16:43 CEST] <durandal_1707> The hash of commit that introduced bug is clearly mentioned in bug report [17:24:13 CEST] <Fyr> right [17:26:11 CEST] <Fyr> is -c copy 100% saves all the information? i.e. if I do this a thousand times with different containers, the final signal will 100% coincide with the original one? [17:27:28 CEST] <durandal_1707> Only bitstream stuff [17:27:57 CEST] <durandal_1707> metadata and format bits are recreated [17:29:59 CEST] <Fyr> ok [17:30:21 CEST] <Fyr> only delays will make them different. xD [18:41:37 CEST] <cone-880> ffmpeg 03Rick Kern 07master:d7cf3610c2fb: lavc/videotoolboxenc: Use shared pixel buffer pool [18:41:37 CEST] <cone-880> ffmpeg 03Rick Kern 07master:0d4bf3074d33: lavc/videotoolboxenc: Handle hwaccel format as input [18:41:37 CEST] <cone-880> ffmpeg 03Rick Kern 07master:fbe0cf8ca7e2: lavc/videotoolboxenc: Require hardware encoding [18:41:37 CEST] <cone-880> ffmpeg 03Rick Kern 07master:645df431449d: lavc/videotoolboxenc: Add entropy setting [18:41:37 CEST] <cone-880> ffmpeg 03Rick Kern 07master:abe05892bee9: lavc/videotoolboxenc: Fix AVCodecContext.has_b_frames usage. [18:41:38 CEST] <cone-880> ffmpeg 03Rick Kern 07master:2fbf39382dbf: lavc/videotoolboxenc: Fix DTS [18:41:38 CEST] <cone-880> ffmpeg 03Rick Kern 07master:272dd437bc6b: lavc/videotoolboxenc: Handle out-of-memory and fix memory leak [18:41:39 CEST] <cone-880> ffmpeg 03Rick Kern 07master:ca429e725353: lavc/videotoolboxenc: Add realtime encoding property [18:41:40 CEST] <cone-880> ffmpeg 03Rick Kern 07master:4b806081b25f: lavc/videotoolboxenc: add concatentation properties [18:41:40 CEST] <cone-880> ffmpeg 03Rick Kern 07master:9d8a38d20b40: lavc/videotoolboxenc: Support for forced I-frames [18:41:42 CEST] <cone-880> ffmpeg 03Rick Kern 07master:c356b6865d37: lavc/videotoolboxenc: Support pixel aspect ratio [18:41:42 CEST] <cone-880> ffmpeg 03Rick Kern 07master:dc750194b6c9: lavc/videotoolboxenc: Set colorimetry values [20:34:41 CEST] <Daemon404> wm4, is the 0-sized issue with decoding or encoding? [20:35:04 CEST] <Daemon404> woops wrong chan [20:38:26 CEST] <wm4> yeah, decoding [20:39:13 CEST] <durandal_1707> why we have probing of random shit in wav demuxer? [20:39:49 CEST] <wm4> because people put random shit into wav [20:39:51 CEST] <wm4> literally [20:40:00 CEST] <Compn> yes. [20:40:13 CEST] <Compn> ac3, dts, plus a million old codecs [20:40:26 CEST] <durandal_1707> and we need to support idiots and ignore sane [20:41:11 CEST] <wm4> it's what ffmpeg does [20:41:12 CEST] <durandal_1707> file is properly marked as pcm 16 le [20:41:22 CEST] <wm4> sounds like spdif fun [20:41:33 CEST] <Compn> lots of spdif :P [20:41:47 CEST] <durandal_1707> michaelni: ? [20:42:50 CEST] <nevcairiel> the typical case is just dts in wav because people ripped a DTS CD, which is technically the same format [20:42:55 CEST] <nevcairiel> its not spdif or anything like that [20:44:47 CEST] <Compn> if you just want to do a 6 codec ffmpeg (xvid, h264, h265, aac, dts, ac3) i think that project would make things easier :P [20:45:43 CEST] <durandal_1707> somehow ffmpeg thinks pcm is h264 video [20:46:16 CEST] <wm4> that's strange, normally I'd expect it detects it as mp3 [20:46:40 CEST] <michaelni> how can i reproduce the pcm-h264 misdetection ? [20:46:44 CEST] <Compn> raw pcm ? [20:46:47 CEST] <Compn> header pcm ? [20:47:21 CEST] <durandal_1707> michaelni: see user ml list [20:48:14 CEST] <durandal_1707> requesting probe higher than h264 returns fixes it but that is another hack [20:48:55 CEST] <durandal_1707> It shouldnt probe video codecs at all [20:49:43 CEST] <Shiz> +wm4 because people put random shit into wav [20:49:44 CEST] <Shiz> https://shiz.me/junk/code/riffogg.py [20:49:46 CEST] <Shiz> yup [20:55:53 CEST] <wm4> how satanic [20:56:03 CEST] <Shiz> visual novels [20:58:22 CEST] <TD-Linux> I think that might be worse than HDCD [20:59:39 CEST] <TD-Linux> Shiz, at least you had the taste to write a python script instead of sending a patch to ffmpeg :) [21:00:42 CEST] <Shiz> yet here i am trying to write an ffmpeg patch for a format that embeds atrac3+ in mpeg private_stream_1 headers [21:01:31 CEST] <Shiz> s/headers/packets/ [21:02:22 CEST] <durandal_1707> good luck, nobody wants to improve our mpegts demuxer [21:02:29 CEST] <Shiz> neither do i [21:02:32 CEST] <Shiz> (also it's ps) [21:03:42 CEST] <Compn> be happy someone re'd atrac3+ :P [21:03:55 CEST] <Shiz> yes, i looked at the decoder and was not happy [21:04:32 CEST] <wm4> atrac? more like detrac [21:10:54 CEST] <llogan> i removed the "hackaton" from archives [21:11:19 CEST] <durandal_1707> michaelni: have you found sample? [21:11:55 CEST] <durandal_1707> llogan: what about snack and pop spam? [21:12:03 CEST] <llogan> what's the URL? [21:12:17 CEST] <michaelni> durandal_1707, i found the h264-wav file, yes [21:14:18 CEST] <durandal_1707> llogan: [FFmpeg-user] Video Engineer Career Opportunity in Toronto [21:15:44 CEST] <durandal_1707> no gym, only snacks - fat devs [21:20:03 CEST] <llogan> durandal_1707: that one is not as bullshitty but i removed it too [21:20:44 CEST] <durandal_1707> thx [21:31:28 CEST] <Compn> huh i'm not getting any of these mails [21:36:28 CEST] <llogan> probably in your spam [21:37:59 CEST] <BBB> it was definitely spammy [21:51:43 CEST] <wm4> xine... [21:55:11 CEST] <Compn> is xine worse than mplayer wm4 ? [21:55:12 CEST] <Compn> ehe [21:57:47 CEST] <wm4> no clue, last time I used xine must have been 13 years ago? [21:58:47 CEST] <llogan> when was the last time you used RealPlayer? [21:59:27 CEST] <llogan> they still make money by convinsing state/provincial governments to buy their "helix server" then charge $10K USD for "training" [21:59:41 CEST] <llogan> my taxes at work [22:00:15 CEST] <drv> the worst part of xine is the weird name with a dumb pronunciation [22:01:06 CEST] <llogan> "zeen"? [22:01:46 CEST] <wm4> I thought it was like "fine" [22:01:48 CEST] <drv> http://www.xine-project.org/faq#pronounce says "[ksi:n]", which makes no sense to me [22:02:01 CEST] <Compn> last realplayer use was sometime around 2001 probably [22:02:32 CEST] <Compn> they pronounce the x [22:02:35 CEST] <Compn> kyne [22:02:37 CEST] <Compn> ? [22:02:42 CEST] <llogan> drv: Kissy Colon N [22:02:48 CEST] <drv> haha [22:02:51 CEST] <drv> new official name [22:24:17 CEST] <cone-333> ffmpeg 03Michael Niedermayer 07master:3646ef6f7c0c: avformat/h264dec: Check pps_id/sps_id fields from parameter sets [22:24:17 CEST] <cone-333> ffmpeg 03Michael Niedermayer 07master:824906a5416b: avformat/utils: Do not detect video codecs when audio is expected [22:29:13 CEST] <jamrial> michaelni: will golomb work from lavf on shared builds? [22:29:35 CEST] <jamrial> get_ue_golomb_31() apparently uses an ff_ prefixed table from golomb.c [22:30:05 CEST] <jamrial> two, even [22:30:43 CEST] <durandal_1707> something uses it? [22:30:53 CEST] <durandal_1707> it can't work [22:31:10 CEST] <jamrial> durandal_1707: check michaelni's latest h264dec commit [22:34:47 CEST] <Daemon404> yes im not sure how this will work [22:35:10 CEST] <Daemon404> (and to fix a stupid bug none the less) [22:35:12 CEST] <durandal_1707> hmm it works here [22:35:52 CEST] <durandal_1707> dunno about Windows [22:38:10 CEST] <durandal_1707> when to apply lbr decoder? [22:39:30 CEST] <jamrial> i was hoping someone else would comment on it as well [22:39:37 CEST] <jamrial> or try stuff like fuzzing [22:47:15 CEST] <michaelni> jamrial, didnt see that, ill fix it [22:47:31 CEST] <michaelni> that is golomb [22:49:27 CEST] <Daemon404> hmmm it links here too [22:49:30 CEST] <Daemon404> but i dont udnerstand how it does [22:49:35 CEST] <Daemon404> the table is private to avcodec [22:51:31 CEST] <jamrial> same, tried on mingw and it linked [22:51:48 CEST] <Daemon404> "my code works, and i dont know why" [22:52:05 CEST] <jamrial> michaelni: ^ [22:52:13 CEST] <jamrial> it works magically :p [22:53:29 CEST] <Daemon404> sure feels wrong tho [23:00:06 CEST] <jamrial> Daemon404: http://pastebin.com/5uwqYhki [23:00:27 CEST] <Daemon404> i have no context for this paste [23:01:00 CEST] <jamrial> try compiling with hevc decoder disabled and hevc parser enabled [23:01:45 CEST] <jamrial> that function doesn't exist. looks like it should be ff_h2645_packet_split() instead, which does exist [23:02:05 CEST] <Daemon404> ... thats not confusing at all [23:02:12 CEST] <Daemon404> -_- [23:02:27 CEST] <Daemon404> test and send a patch if you can please [23:02:37 CEST] <jamrial> it was called like that before the merge in question i guess [23:02:55 CEST] <jamrial> and sure [23:04:00 CEST] <Daemon404> one thing i dont like about doing merges: half the codebase is my fault [23:04:22 CEST] <jamrial> haha [23:04:58 CEST] <jamrial> commit them as Guy Incognito [23:05:21 CEST] <Daemon404> j-b will hurt me if i use a pseudonym [23:05:26 CEST] <Daemon404> duh [23:08:23 CEST] <drv> Elvis "The King of Merges" Presley [23:17:09 CEST] <michaelni> jamrial, it works due to libavformat/golomb_tab.c, but i think its better if the tables arent used from avformat, ill remove the _31 calls [23:17:43 CEST] <jamrial> oh, no wonder [23:18:07 CEST] <cone-333> ffmpeg 03Michael Niedermayer 07master:03e8c1b84398: avformat/h264dec: Avoid get_ue_golomb_31( ) due to ff_ prefixed table from golomb.c [23:21:20 CEST] <Daemon404> ah [23:21:27 CEST] <Daemon404> why didnt my grep find that [23:21:31 CEST] Action: Daemon404 must be tired [23:27:04 CEST] <cone-333> ffmpeg 03James Almer 07master:fc1c836def08: avcodec/hevc_parser: fix packet_split function name [23:40:28 CEST] <cone-333> ffmpeg 03James Almer 07master:fe483ac42854: avformat/mpegtsenc: fix usage of AVStream.codec [00:00:01 CEST] --- Thu May 5 2016

1 0

ffmpeg.log.20160504
by burek 05 May '16

05 May '16

[00:31:17 CEST] <xxDCDxx> sorry, I got disconnected [00:32:26 CEST] <xxDCDxx> should I try to use LIPO to build universal binaries for the CLI? running the command './build-ffmpeg.sh lipo' after removing '--disable-programs' built universal libs, but not the universal cli [00:35:14 CEST] <c_14> Looking at the script it only does that for the libraries. Are there no binaries at all or do they just not work? [00:37:57 CEST] <xxDCDxx> the libraries seem fine, the thing is I also wanted universal CLI files (that can run on arm7, arm64 and x86_64 [00:38:00 CEST] <xxDCDxx> I tried this: [00:38:48 CEST] <xxDCDxx> http://pastebin.com/m4Ru1fpr [00:39:40 CEST] <xxDCDxx> but I get the error shown there. I suspect the 'lipo' command is only for libraries, not for executables [00:43:54 CEST] <c_14> I don't think there's an equivalent for binaries [01:10:15 CEST] <Plorkyeran> lipo is how you create fat executables [01:12:54 CEST] <Plorkyeran> thin/arm64/share/ffmpeg does not sound like an executable, though [01:13:15 CEST] <Plorkyeran> the executables are in the bin directories [01:13:24 CEST] <neuro_sys> I probably asked this before, but I couldn't find it again. What's the opposite of colorkey? Make anything that is not a particular color transparent? [01:15:30 CEST] <andrey_utkin> neuro_sys, i think you could go just hacking the source code of colorkey filter, should be easy for your case :) [01:20:12 CEST] <neuro_sys> sounds like it [01:20:43 CEST] <neuro_sys> but I might go another way that doesn't require stencil masking [01:20:51 CEST] <furq> 16:07:02 ( neuro_sys) what is a filter that does the inverse of colorkey? [01:20:52 CEST] <furq> 16:08:14 ( c_14) presumably overlay over a color? [01:21:03 CEST] <neuro_sys> furq: ha! [01:25:53 CEST] <llogan> neuro_sys: maybe something like this " "[0:v]colorkey,alphaextract,negate[alf];[0:v][alf]alphamerge[fg];[1:v][fg]overlay" [01:32:25 CEST] <neuro_sys> llogan: looks useful, I'm trying, thanks [01:38:23 CEST] <neuro_sys> I seem to have it wrong: "[1:v]colorkey=color=black[cout];[0:v]colorkey=color=white,alphaextract,negate[alf];[0:v][alf]alphamerge[fg];[fg][cout]overlay[out]" [01:39:53 CEST] <llogan> not much i can say without more constext such as your full command and complete console output pasted into a pastebin site and the link provided here [01:44:04 CEST] <neuro_sys> okay, hold on [01:45:04 CEST] <neuro_sys> llogan: http://imgur.com/a/3XaZG [01:45:15 CEST] <neuro_sys> these are thw two images I'm working on [01:45:58 CEST] <neuro_sys> I was hoping to use colorkeying both ways in order to avoid compression artifacts from being visible [01:46:24 CEST] <neuro_sys> as well as when the base image has the target surface ocluded by various objects [01:47:22 CEST] <llogan> i have to go now, but i think you can get it to work overlaying the top image over the bottom one. no need to colorkey the bottom one [01:49:02 CEST] <neuro_sys> the top image has some artifacts at the top [01:49:08 CEST] <neuro_sys> but yeah I should get rid of them first [02:29:19 CEST] <xxDCDxx> it turns out that I cannot fork new processes from iOS, so compiling the ffmpeg CLI is of no use. Now I'm trying to rename main() to mainFFMPEG() in ffmpeg.c/.h and I'll call that with the proper arguments from my app. Is there any change I need to make to the makefile so it's built as part of the library instead of a standalone executable? [02:32:06 CEST] <pzich> is there a reason you aren't using a static library like https://github.com/chrisballinger/FFmpeg-iOS ? [02:33:20 CEST] <xxDCDxx> yeah, I tried that. The thing is that I want to replicate the command 'ffmpeg -i recording.mp4 -vsync vfr -q:v 9 recording.mjpeg', but I don't know how to do it with the raw lib API [02:33:48 CEST] <xxDCDxx> I'm finding it a little bit complicated using the standalone libs [02:43:52 CEST] <xxDCDxx> so, is it wise to go with the ffmpeg.c route, or should I learn the libraries and replicate the behaviour myself? [02:44:39 CEST] <xxDCDxx> getting some pointers would be much appreciated ;) [03:13:03 CEST] <neuro_sys> would I get a significant performance gain from using libav instead of CLI in my case where I do something like ffmpeg -i %04d.png /* complex filters */ output.mp4 [03:13:20 CEST] <neuro_sys> where I generate png's in memory and write to disk for passing to ffmpeg as such [05:27:35 CEST] <Abbott> is it possible to disassemble a variable bitrate video into it's frames, edit them, and recompile the variable frames correctly back into the original clip? [05:28:32 CEST] <Abbott> or do you have to resample the frames at a constant bitrate, edit, then assemble again? Would there be a loss of data? (is this considered encoding when resampling the frames?) [05:32:13 CEST] <furq> that depends on the codec [05:32:20 CEST] <furq> if it's not an intra-only codec then the answer is probably no [05:32:25 CEST] <furq> although i'm no expert [05:32:48 CEST] <furq> that would apply regardless of bitrate as well [05:39:32 CEST] <kepstin> neuro_sys: you could get a significant speed gain by skipping the whole png thing and just writing the raw, unencoded video into ffmpeg. Using it as a library could help a bit there by reducing the number of data copies done. [11:22:19 CEST] <neuro_sys> kepstin: thanks [11:26:20 CEST] <neuro_sys> btw, what do you think might this masking's purpose? int rowStride = (width * 3 + 3) & ~0x3; [11:31:19 CEST] <xxDCDxx> hi, I'm trying to replicate what the command 'ffmpeg -i recording.mp4 -vsync vfr -q:v 9 recording.mjpeg' does, but using the libraries, any pointers? I have no experience using video libraries [11:35:11 CEST] <neuro_sys> seems like it rounds width to multiples of four [14:16:52 CEST] <Admin7762Frd> good morning everyone [14:22:28 CEST] <Admin7762Frd> anyone around to help me figure out why i am getting these errors " http://pastebin.com/raw/urJhU2AU " Enter command: <target>|all <time>|-1 <command>[ <argument>] ".. it plays the files for a few seconds and then moves on to the next .. these are 1 gig files. not sure why its ending lik ethat [14:24:00 CEST] <BtbN> most of these nvenc options look invalid. [14:25:33 CEST] <Admin7762Frd> really? [14:25:48 CEST] <Admin7762Frd> :( what is wrong with it ? [14:27:52 CEST] <Admin7762Frd> NVENC_OPTS="-preset lowLatencyHQ -qp 21 -numB 1 -goplength 180 -rcmode 32 -fps 30 -ptsdelay 0.0" you mean ? [14:28:07 CEST] <Admin7762Frd> i been using those options forever for the transcoder [14:37:32 CEST] <Fyr> how to show the list of codecs that are available for the specified container? [14:38:06 CEST] <Admin7762Frd> ffmpeg -codecs ? [14:39:06 CEST] <Fyr> Admin7762Frd, I see the output, but I don't see what accounts for mp4. [14:40:10 CEST] <Fyr> Admin7762Frd, what codecs can ffmpeg mux into mp4? [14:44:52 CEST] <Admin7762Frd> Fyr , i wish i knew enough about it .. but you can do mkv ,, and other stuff [14:45:23 CEST] <Admin7762Frd> BtbN > what is wrong with my nvenc options ? [14:45:35 CEST] <Admin7762Frd> its not using the nvenc built into ffmpeg [14:47:14 CEST] <Admin7762Frd> reason i didn't use that is because the nvenc does not decode and using vdpau gives me a bunch of errors too that i have not figured out yet like " Cannot open the X11 display . [14:47:14 CEST] <Admin7762Frd> VDPAU init failed for stream #0:0. [14:47:14 CEST] <Admin7762Frd> vdpau hwaccel requested for input stream #0:0, but cannot be initialized. " [14:52:49 CEST] <Admin7762Frd> ok moved to vdpau & nvenc built into ffmpeg.. but still getting that output error [15:11:39 CEST] <relaxed> Admin7762Frd: did you ever report the differences between NvTranscoder and nvenc on the bug tracker? [15:12:22 CEST] <Admin7762Frd> nope.. i think i got it close enough now that its the same so now i switched.. the problem was always vdpau having problems decoding [15:12:31 CEST] <Admin7762Frd> where is the transcoder does the decoding too which is nice [15:12:55 CEST] <Admin7762Frd> that said i got the vdpau going right now along with nvenc but my error still is coming up [15:12:59 CEST] <Admin7762Frd> let me post a new pastbin [15:13:46 CEST] <Admin7762Frd> http://pastebin.com/raw/MbvbCJe5 [15:14:02 CEST] <Admin7762Frd> see that one.. the error still pops up with " Enter command: <target>|all <time>|-1 <command>[ <argument>] [15:14:19 CEST] <Admin7762Frd> oh and also " Parse error, at least 3 arguments were expected, only 1 given in string 'anada.Movie0020.mp4' " [15:15:27 CEST] <relaxed> quote $lines [15:20:55 CEST] <DEATH> https://trac.ffmpeg.org/wiki/CompilationGuide/WinRT <= needs amending for latest msys64 [15:21:31 CEST] <DEATH> We expect msys64 to inherit PATH from the calling process, that does not work with latest msys64, unless you edit msys2_shell.bat [15:21:32 CEST] <DEATH> rem To export full current PATH from environment into MSYS2 uncomment next line [15:21:32 CEST] <DEATH> rem set MSYS2_PATH_TYPE=inherit [15:29:01 CEST] <Admin7762Frd> death . i did quote the lines but still.. :( [15:29:29 CEST] <Admin7762Frd> > /home/ffmpeg-3.0.1/ffmpeg -y -re -i "$lines" [15:29:37 CEST] <Admin7762Frd> same result [15:34:53 CEST] <Admin7762Frd> must have something to do with the fifo [15:34:56 CEST] <Admin7762Frd> just not sure what [15:56:29 CEST] <Admin7762Frd> any other clues ? [16:34:23 CEST] <Workflow> Guys, is there a way to make snapshotting quicker? For example, i'm exporting every fps=1/120, is it down to CPU? I have 4 cores assigned to a dedicated VM, but only 2 are being used roughly. [16:38:19 CEST] <Fyr> =( [16:40:21 CEST] <Fyr> guys, I receive the following error: [16:40:21 CEST] <Fyr> http://pastebin.com/Zdufa8AY [16:40:21 CEST] <Fyr> what could that be? [16:40:33 CEST] <Fyr> the output file is 790 bytes-sized. [16:52:32 CEST] <xxDCDxx> using the MJPEG codec, what is the equivalent of: "-q:v 9" in code? [16:53:01 CEST] <xxDCDxx> I'm doing transcoding, as in this file: https://ffmpeg.org/doxygen/2.8/transcoding_8c-example.html [17:03:15 CEST] <jkqxz> xxDCDxx: AVCodecContext.global_quality (The scale may be different, though.) [17:06:39 CEST] <xxDCDxx> thanks! [17:07:20 CEST] <Admin7762Frd> getting closer.. now i get " Hardware accelerated decoding with frame threading is known to be unstable and its use is discouraged. " [17:07:31 CEST] <Admin7762Frd> can you tell me.. why would it do that for vdpau ? [17:07:51 CEST] <Admin7762Frd> i tried using threads 1 but then decoding doesn't work [17:18:18 CEST] <xxDCDxx> jkqxz: it doesn't seem to do the trick, quality is the same (quite low). I tried values ranging from 1 to 9*FF_QP2LAMBDA, with no apparent change [17:19:31 CEST] <jkqxz> For MJPEG? The scale should be is 1-100, so 9 will be very low. (Though I admit I don't actually know whether that encoder even respects the quality value at all...) [17:22:35 CEST] <xxDCDxx> I'll try 100 [17:22:47 CEST] <xxDCDxx> there should be a way, given that command line does it, no? [17:23:33 CEST] <jkqxz> Um, yeah. That is quite strong evidence, I agree. [17:24:00 CEST] <xxDCDxx> (e.g., -q:v 30 looks like crap, -q:v 9 looks nice) [17:25:00 CEST] <jkqxz> That seems the wrong way around. Are you sure you are encoding with MJPEG? [17:25:37 CEST] <xxDCDxx> I'm pretty sure. According to this post, that's correct: http://stackoverflow.com/a/32151594/269753 [17:25:57 CEST] <jkqxz> Or maybe it's inverted somehow. JPEG usually has a quality scale of 1-100, but it could be remapped somehow in lavc. [17:26:38 CEST] <xxDCDxx> "You can use -q:v instead. For MJPEG the effective range is a linear scale of 2-31, and a lower value will likely end up with a higher quality output." [17:26:46 CEST] <xxDCDxx> that's what that online dude claims [17:27:18 CEST] <xxDCDxx> "enc_ctx->global_quality = 100" and "enc_ctx->global_quality = 1" seem to produce the exact same results [17:29:25 CEST] <jkqxz> FF_QP2LAMBDA is 118. Try something bigger: 3000? [17:31:12 CEST] <xxDCDxx> tried 3000 and 10000, same results [17:31:17 CEST] <xxDCDxx> the value seems completely ignore [17:31:33 CEST] <xxDCDxx> *ignored [17:31:47 CEST] <xxDCDxx> because "-q:v 30" makes it look way worse than when I tried enc_ctx->global_quality = 1 [17:40:44 CEST] <jkqxz> AVCodecContext.flags |= AV_CODEC_FLAG_QSCALE? [17:45:51 CEST] <xxDCDxx> doing "enc_ctx->flags |= AV_CODEC_FLAG_QSCALE" seems to improve the quality a bit, but global_quality seems to still be ignored [18:06:02 CEST] <xxDCDxx> AVCodecContext.compression_level is also ignored [18:07:43 CEST] <zarathushtra> i have a video and an audio stream that i got with "mkvextract tracks $1.mkv 0:$1.avi 2:$1.ogg", i need to put it on an avi file and i can do it with "ffmpeg -i $1.ogg -i $1.avi -c copy out.avi", but i also need to put a .srt on it... i tried before the ffmpeg using a video filter, is that the correct approach? [18:24:59 CEST] <furq> zarathushtra: -vf subtitles=subs.srt [18:25:08 CEST] <furq> you'd need to reencode for that because it burns the subs into the video [18:25:51 CEST] <zarathushtra> furq: can i reencode using the tracks or the out.avi [18:28:53 CEST] <PlanC> I have a video with varying audio bitrate [18:29:06 CEST] <PlanC> I just want to extract the audio [18:29:26 CEST] <__jack__> PlanC: ffmpeg -i source -map 0:a -c copy output.mkv [18:29:36 CEST] <PlanC> how should I know what to set the audio bitrate of the MP3 to? [18:33:28 CEST] <PlanC> ___jack___: is there a way for me to just the audio bitrate of the video file? [18:34:50 CEST] <PlanC> the reason I'm asking is because I have a shit ton of videos from my lectures but I'm running out of room so I'm trying to remove the videos and just save the audio [18:35:01 CEST] <furq> you don't set the audio bitrate if you're extracting the stream [18:35:19 CEST] <PlanC> furq: some of my files don't have a bit_rate in the stream [18:35:25 CEST] <PlanC> they just have "formats" [18:36:38 CEST] <furq> if the command __jack__ posted didn't work then paste the full output [18:36:51 CEST] <furq> pastebin, rather [18:37:56 CEST] <PlanC> furq: I haev another command that I use though [18:38:19 CEST] <PlanC> ffmpeg -i video.mp4 -b:a 128k -y output.mp3 [18:38:26 CEST] <furq> that's reencoding [18:38:37 CEST] <PlanC> that's what I need to do though [18:38:44 CEST] <PlanC> because MP3 works the best for me [18:38:52 CEST] <PlanC> it's small and the audio quality is good [18:39:09 CEST] <PlanC> (small being really important because I have limited space) [18:40:57 CEST] <zarathushtra> trying to use "-sub_charenc CP1252" i receive: Codec AVOption sub_charenc (set input text subtitles character encoding) specified for output file #0 (teste.avi) is not an encoding option. [18:53:39 CEST] <__jack__> PlanC: best things you can do is something like the command is wrote : is will extract the same audio that you have (meaning: no quality loss, really fast processing) [18:54:53 CEST] <__jack__> PlanC: if you want to reencode the audio, to get more space, please note that it will be lossless; you should use aac or other codec, as the perform really better than mp3 (best quality per size, lower size for the same quality) [18:56:21 CEST] <__jack__> (but, throwing away the video will give you already almost all space back, so you probably don't need the reencode stuff) [19:37:52 CEST] <zarathushtra> what is the difference between H.264 MP and H.264 BP [19:38:31 CEST] <klaxa> sounds like main profile and baseline profile [19:38:33 CEST] <kepstin> that's "main profile" and "baseline profile", see https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles [19:39:15 CEST] <zarathushtra> Phmm [19:39:18 CEST] <zarathushtra> cool [19:39:35 CEST] <zarathushtra> im trying to convert a simple .mkv to a file that my tv can read [19:39:35 CEST] <zarathushtra> http://www.samsung.com/hk_en/consumer/learningresources/TV/contents_lib/ima… [19:41:06 CEST] <kepstin> if you're encoding with libx264, you can use the '-profile main' option, and it'll limit itself to using only features in main profile. [19:42:17 CEST] <kepstin> as long as you also stay within the supported video size, and pick an audio codec it likes, that should be good enough. [19:43:24 CEST] <zarathushtra> mkvmerge shows that the video stream is Track ID 0: video (MPEG-4p10/AVC/h.264) [19:43:46 CEST] <zarathushtra> ffmpeg: Stream #0:0: Video: h264 (High), yuv420p, 1280x720, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default) [19:44:02 CEST] <zarathushtra> (High) means high profile? thus i need to reencode? [19:46:25 CEST] <zarathushtra> oh nvm i was looking at the wrong data... my tv wont support more than 720x480... thats why -.- [21:24:12 CEST] <operator> getting error with ffmpeg: http://pastebin.com/q5eaFak6 [21:24:33 CEST] <operator> is the problem my video file or missing codecs? [21:27:55 CEST] <llogan> operator: did you "Consider increasing the value for the 'analyzeduration' and 'probesize' options"? [21:28:18 CEST] <llogan> can you provide a short input sample? what made the input file? do you know what format the audio is supposed to be? [21:37:54 CEST] <rsully> Is there a particular linux distro or script that makes compiling ffmpeg with options/dependencies far easier? I want to setup a VM for encoding that has up-to-date everything as easy as possible [21:40:05 CEST] <llogan> rsully: as for repository offerings Arch keeps up to date with latest release branch. Debian unstable is a little slower but it is often relatively up to date. [21:40:58 CEST] <llogan> as for compiling, i guess that just comes down to personal preferance: manually, build scripts, user repos, etc [21:44:26 CEST] <operator> llogan: file created by blackmagic intensity pro 4k card [21:46:04 CEST] <llogan> i imagine that should be some sort of PCM audio [21:47:30 CEST] <furq> rsully: it's not quite what you asked for but freebsd makes it very easy to compile a customised ffmpeg [21:47:34 CEST] <operator> llogan: i can give you 1sec example, is it enough? [21:47:39 CEST] <furq> as long as the stuff you want is in make config [21:48:02 CEST] <llogan> operator: if it allows the issue to be duplicated [21:53:00 CEST] <operator> llogan: I'm getting the same error with this file: http://pc.cd/S2DctalK [22:05:17 CEST] <llogan> operator: do you have some from the same hardware where the audio is recognized properly? [22:16:33 CEST] <durandal_1707> llogan: its invalid guid, s24le pcm is stored [22:18:37 CEST] <rsully> furq I essentially want to take my Mac homebrew config options and stick it on my server [22:19:02 CEST] <rsully> llogan I would need to go build script route I think, as I need options that can't be distributed as binaries [22:19:37 CEST] <Fyr> is here anyone who used SubtitleEdit? [22:20:52 CEST] <rsully> furq where would i look for the freebsd options to know if that would meet my needs? [22:25:16 CEST] <c_14> rsully: the options are listed here https://svnweb.freebsd.org/ports/head/multimedia/ffmpeg/Makefile?revision=4… . FreeBSD only has a relatively old version of ffmpeg though [22:25:24 CEST] <rsully> That's no good then [22:27:02 CEST] <furq> oh have they not upgraded to 3.x yet [22:27:13 CEST] <furq> i figured mine was on an old version because i'm still on 9.3 [22:27:30 CEST] <furq> that's disappointing, they were generally only a few days behind with 2.x releases [22:29:16 CEST] <c_14> probably because of the major api changes in 3.0 [22:29:18 CEST] <c_14> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207547 [22:37:14 CEST] <durandal_1707> operator: it looks like audio is pcm_s24le [22:45:27 CEST] <operator> so, audio makes trouble [22:51:42 CEST] <Fyr> audio always brings trouble. [22:51:59 CEST] <Fyr> whithout it's much better. [23:04:20 CEST] <llogan> rsully: you can make your own build script, or use ABS or AUR in Arch Linux [23:04:54 CEST] <rsully> ABS / AUR ? [23:05:17 CEST] <llogan> https://wiki.archlinux.org/index.php/Arch_User_Repository [23:05:23 CEST] <llogan> https://wiki.archlinux.org/index.php/Arch_Build_System [23:06:39 CEST] <llogan> or to be more specific, make your own PKGBUILD [00:00:01 CEST] --- Thu May 5 2016

1 0

ffmpeg-devel.log.20160503
by burek 04 May '16

04 May '16

[01:08:54 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07master:df820af2c502: avcodec/error_resilience: Improve missing slice handling for mpeg2 [01:08:55 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07master:dc34fa6a9e64: avformat/riff: add M702 [03:39:58 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07release/2.6:74b8c4a60bb9: avformat/options_table: Add missing identifier for very strict compliance [03:39:59 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07release/2.6:342b6d371895: avcodec/mjpegdec: Do not try to detect last scan but apply idct after all scans for progressive jpeg [04:09:27 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07release/2.6:063382610fe3: Changelog: update for the last 2 commits [04:13:12 CEST] <cone-273> ffmpeg 03Carl Eugen Hoyos 07release/3.0:e675926a4fa6: lavf/mpegts: Return small probe score for very short transport streams. [04:13:13 CEST] <cone-273> ffmpeg 03foo86 07release/3.0:08c21bcb5dfd: avcodec/dca: fix sync word search error condition [04:25:14 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07n2.6.9:HEAD: avformat/riff: add M702 [09:24:08 CEST] <cone-282> ffmpeg 03Christophe Gisquet 07master:7d453aaf653d: wmalossless: allow calling madd_int16 [10:52:00 CEST] <cone-282> ffmpeg 03Carl Eugen Hoyos 07master:80d14de52db8: lavf/mpegts: Add E-AC3 registered stream specifier "EAC3". [11:05:52 CEST] Action: Daemon404 sees absolutely noone helped merge while he has been busy [11:18:32 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:ad9d3384de08: svq3: move the dequant buffer to SVQ3Context [11:18:33 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:12f13ecb2dcd: svq3: move mb strides/sizes to the SVQ3Context [11:18:34 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:5a5db90edf71: svq3: move pict_type to the SVQ3Context [11:18:35 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:297e2768dab3: Merge commit 'ad9d3384de08f02967d6eb11196ee8c78e8b2dba' [11:18:36 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:1bfbdb8f0b81: Merge commit '12f13ecb2dcddfa3ee930167395370d3c6fff90c' [11:18:37 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:5db920bcb605: Merge commit '5a5db90edf71ef4c60db8ad7b0ebaa9a810c2d9e' [11:29:19 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:939b388383db: svq3: eliminate remaining H264SliceContext usage [11:29:20 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:21b746932241: svq3: eliminate H264Context.cur_pic usage [11:29:21 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:ea6ab02a174b: svq3: move the frame num variables to the SVQ3Context [11:29:22 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:1848a154a49d: svq3: stop using H264Context.gb [11:29:23 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:7bbdae81e895: svq3: move block_offset to SVQ3Context [11:29:24 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:2d3cc682c4c4: Merge commit '939b388383db8d0db5b2ff483e3a197c27b79791' [11:29:26 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:014fb816d104: Merge commit '21b746932241246be846a133abb3c5f91b1cab85' [11:29:27 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:8bba752ae95f: Merge commit 'ea6ab02a174bcc11f3eaa1b840c9a4c895968690' [11:29:27 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:f32a23c84912: Merge commit '1848a154a49d18c1f31f54ee75c7445dc49a7ecc' [11:29:29 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:2a018be10fc8: Merge commit '7bbdae81e895a49125dba58bad01b98389966c39' [11:40:15 CEST] <Daemon404> hmm shit. [11:40:46 CEST] <wm4> shit? [11:43:49 CEST] <Daemon404> trying to merge the last svq3 patch but it crashes [11:43:55 CEST] <Daemon404> probably due to hacks [11:51:13 CEST] <Daemon404> aha got it. [11:52:39 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:a4d126dc59c3: svq3: eliminate remaining H264Context usage. [11:52:40 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:43b7e5aa3204: Merge commit 'a4d126dc59c39bb03e5e444432d1b27af26a45b4' [12:00:29 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:add1467e5e44: svq3: drop the build dependency on the h264 decoder [12:00:30 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:a454ad670c77: Merge commit 'add1467e5e447b79e8743a0b05c54dcf58c61dfe' [12:00:33 CEST] <Daemon404> svq3 = done [12:01:12 CEST] <Daemon404> now, coffee, then maybe more merges whilst i deal with some irl annoyance. [12:10:12 CEST] <wm4> what can I say, thanks for doing this [13:21:41 CEST] <kierank> BBB: https://www.linkedin.com/pulse/another-vp9-codec-former-team-member-rsbultj… [13:27:49 CEST] <BBB> thats true :) [13:54:51 CEST] <thardin> jeez, linkedin is slow [13:59:54 CEST] <Daemon404> thardin, so are the people on it [14:00:01 CEST] <Daemon404> /s [14:00:40 CEST] <thardin> too contrarian [14:00:58 CEST] <thardin> gotta keep it just right [14:11:18 CEST] <Compn> but is ~5x slower. [14:11:21 CEST] <Compn> in the trash it goes [14:11:38 CEST] <Compn> doh he left [14:16:35 CEST] <cone-282> ffmpeg 03Carl Eugen Hoyos 07master:fd0f1442eb78: lavf/mpegtsenc: Fix stream_type for low sample rate MP2/MP3. [14:31:56 CEST] <nevcairiel> gnu did it again, latest binutils (2.26) seems to not build with gcc 6.1 :) [14:32:09 CEST] <Daemon404> -Werror again? [14:32:13 CEST] <nevcairiel> probably [14:32:34 CEST] <nevcairiel> ../../../source/binutils-2.26/gas/config/tc-i386.c: In function 'optimize_imm': [14:32:34 CEST] <nevcairiel> ../../../source/binutils-2.26/gas/config/tc-i386.c:4222:53: error: result of '2l << 31' requires 34 bits to represent, but 'long int' only h [14:32:34 CEST] <nevcairiel> && ((i.op[op].imms->X_add_number & ~(((offsetT) 2 << 31) - 1)) [14:33:22 CEST] <Daemon404> thats some nice operator soup [14:33:27 CEST] <Daemon404> also >long [14:42:50 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:a7829a2a3f8e: h264: reimplement 3aa661ec5 in a more explicit way [14:42:51 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:7966ddfc0bb7: Merge commit 'a7829a2a3f8e6ec0b9f2673c11f56916800aeb33' [14:47:31 CEST] <Daemon404> nevcairiel, ping, need help with a merge [14:47:33 CEST] <Daemon404> or wm4 or ubitux [14:47:37 CEST] <jkqxz> Daemon404: The next commit (ca2f19b9cc37be509d85f05c8f902860475905f8) breaks some hwaccel decodes because it changes the meaning of some parsing that they rely on (fixed later). How do you deal with that sort of thing in merging? [14:47:46 CEST] <ubitux> Daemon404: yes? [14:47:48 CEST] <Daemon404> https://git.libav.org/?p=libav.git;a=commit;h=ca2f19b9cc37be509d85f05c8f902… [14:47:57 CEST] <Daemon404> ^ im nto qualified to do this probably [14:48:02 CEST] <Daemon404> nevcairiel probably is. [14:48:25 CEST] <Daemon404> jkqxz, generally we cherry pick the commit that fixes them [14:48:29 CEST] <Daemon404> and then skip merging it later [14:51:53 CEST] <wm4> I don't think I'm qualified either [14:52:00 CEST] <mike_cook> I have a question about using VDPAU HW accelerated decoding with FFMPEG. May I ask it here? [14:52:03 CEST] <wm4> let me guess, the hard part is ffmpeg specific hacks? [14:52:04 CEST] Action: Daemon404 stares at nevcairiel [14:52:16 CEST] <Daemon404> wm4, i dont know if theyre hacks or just features [14:52:21 CEST] <Daemon404> we have some slicey stuff [14:52:25 CEST] <Daemon404> i dont know h264 very well. [14:52:29 CEST] <wm4> mike_cook: sure, normally API usage questions go on #ffmpeg, but hwaccels are underdocumented and tricky [14:55:12 CEST] <jkqxz> Daemon404: Ok, makes sense. You want <https://git.libav.org/?p=libav.git;a=commit;h=b3051a460cf02a5b86ff0d1e14abb…> to go with that one, then (I can easily test it if you don't have kit lying around to do it yourself). [14:56:07 CEST] <Daemon404> sure [14:56:17 CEST] <Daemon404> ill poke you when i get to it [14:56:25 CEST] <nevcairiel> the same patch should apply to dxva as well, but apparently noone ever bothered to send a patch [14:56:27 CEST] <jkqxz> There was some thought that old dxva2 might be broken as well, but noone could come up with any hardware to test it on. So, maybe, and nothing in libav. [14:56:32 CEST] <Daemon404> waiting on nevcairiel to slap me around a bit about nal parsing first [14:56:39 CEST] <mike_cook> OK. Thank you. I have implemented HW acceleration in my project. And it works OK. I currently use VdpVideoSurfaceGetBitsYCbCr to retrieve YUV data from the VDPAU surface into my app. I see a ~100% CPU usage using this technique. I can retrieve the surface in RGBA format using VdpOutputSurfaceGetBitsNative, and this technique uses only ~2% CPU, but I need the pixels in YUV - not RGBA. Is there a way for me to get the native get bits speed but [14:56:39 CEST] <mike_cook> have it return YUV? [14:57:58 CEST] <BtbN> did you look at how ffmpeg extracts the data? [15:00:35 CEST] <mike_cook> BtbN: is that a question for me? I was not aware that FFMpeg was involved... I am making a call directly to the VDPAU driver. [15:01:07 CEST] <wm4> ffmpeg CLI has its own code to do something similar [15:01:18 CEST] <BtbN> it's in lavu, ffmpeg cli just uses it. [15:01:18 CEST] <wm4> actually, in git, this code was moved to libavutil, so everyone can use it [15:02:01 CEST] <BtbN> from a quick look, ffmpeg just calls VDP_FUNC_ID_VIDEO_SURFACE_GET_BITS_Y_CB_CR [15:02:09 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/hwcontext_vdpau.c;… [15:02:47 CEST] <BtbN> And i don't remember the ffmpeg cli using tons of CPU, so I'd guess you are doing something wrong. [15:04:29 CEST] <mike_cook> It's 100% possible that I am doing something incorrectly. But there's not much to it. :-) [15:05:59 CEST] <nevcairiel> Daemon404: the patch sure is unreadable [15:06:13 CEST] <Daemon404> yes... [15:06:36 CEST] <Daemon404> im really having trouble merging it, and my knowledge of the h264 nal code is not enough [15:07:19 CEST] <BtbN> Will the avconv_vaapi.c be merged to become ffmpeg_vaapi.c, or does someone have to do that manually? [15:08:15 CEST] <nevcairiel> Daemon404: first step, ff_h264_decode_nal had a few special cases the the h2645 version probably lost, so those should be re-added to maintain functionality [15:08:28 CEST] <nevcairiel> then we can see about using it [15:08:43 CEST] <Daemon404> im pretty sure im not qualified to do that [15:24:14 CEST] <kierank> Daemon404: oh lord that patch [15:24:27 CEST] <kierank> if it was me i'd skip it [15:24:33 CEST] <kierank> the libav h264 parsing is awful [15:24:35 CEST] <michaelni> Daemon404, 7966ddfc0bb7ee87dc2606b7b146701db6f6c717 breaks tickets/2580/58af5798-fa2c-42a2-997d-dc8e49de2d8a.flv (can be seen quicker with ./ffplay -ss 13 but happens too without if you wait) [15:26:03 CEST] <Daemon404> how do you even find this stuff [15:26:23 CEST] <Daemon404> anyway, im not sure how exactly to fix it [15:26:27 CEST] <Daemon404> perhaps you do? [15:27:16 CEST] <michaelni> file shuld be here: http://files.cousins-sears.com/0x2m2u110W3H [15:28:33 CEST] <Daemon404> arent you you teh author of the relevant fix? [15:33:27 CEST] <michaelni> yes, but iam not motivated to repair every case where someone reimlpements my fix in a difefrent way [15:34:14 CEST] <Daemon404> thats nice, but im also not an walkign encyclopedia of of magic fixes for every single bug ever fixed in ffmpeg [15:34:24 CEST] <Daemon404> so either give me a hint, tell me to revert, or fix it [15:34:32 CEST] <Daemon404> "here is a file, fix it" is not vali. [15:34:34 CEST] <Daemon404> valid* [15:35:09 CEST] <michaelni> ok ill try to take a look [15:35:33 CEST] <Daemon404> (i am very unfamiliar with h264 parser code) [15:35:42 CEST] <Daemon404> whicg is why i havent done the next merge [15:35:58 CEST] <durandal_1707> get real job with fully-stocked kitchen with snacks, pop and more [15:37:52 CEST] <nevcairiel> do we have an example somewhere how to use the swscale chroma position thingy? [15:38:18 CEST] <Daemon404> kierank's codebase probably has it [15:38:26 CEST] <Daemon404> maybe in ffmpeg.c too [15:38:27 CEST] <Daemon404> ? [15:38:34 CEST] <kierank> nevcairiel: vf_scale has it [15:39:08 CEST] <wm4> on a related note, does anyone know a good test for chroma positioning issues? [15:39:58 CEST] <nevcairiel> kierank: i looked at your patch to overwrite the default chroma position, but i got confused because i think thats the default swscale behavior anyway? Or did your patch only fix interlaced? [15:40:05 CEST] <kierank> fix interlaced [15:40:10 CEST] <kierank> wm4: there's a video somewhere on trac [15:40:17 CEST] <nevcairiel> ok so 128 is the same as default progressive as well [15:47:21 CEST] <wm4> kierank: what should I search for? [15:47:33 CEST] <kierank> interlaced chroma [15:47:45 CEST] <kierank> it's a moving ball iirc [15:53:32 CEST] <wm4> this? https://www.dropbox.com/s/u2lpm6np9re57yi/ffmpeg_chromabug.mpg?dl=1 [15:57:33 CEST] <nevcairiel> these chroma position numbers make no sense, we even have avcodec_enum_to_chroma_pos to generate them, but i still cant make any sense of them [15:58:50 CEST] <nevcairiel> according to that function, mpeg2 is 128:128, and mpeg1 is 0:0 ... but mpeg2 and mpeg1 only differ on one axis, not on both [15:59:04 CEST] <michaelni> Daemon404, posted a patch that fixes the file [16:00:30 CEST] <Daemon404> michaelni, i dont have a problem with the patch, but i also am not qualified to say if is ok or not [16:07:25 CEST] <michaelni> well, the new code doesnt cover the in stream case, only the extradata case, so until that is fixed by some other means the code is still needed [16:08:12 CEST] <michaelni> ill apply the patch unless someone wants me to wait [16:10:31 CEST] <Daemon404> ok [16:10:58 CEST] <Daemon404> wm4, its ffmpeg-specific. av_opt_{gs}et references pix_fmt here [16:11:09 CEST] <wm4> lol [16:11:17 CEST] <wm4> makes sense I guess [17:04:44 CEST] <cone-282> ffmpeg 03Michael Niedermayer 07master:1ef267b83f8b: avcodec/h264: Put the removed SPS handling code back [17:41:00 CEST] <wm4> so it seems some files have "legitimate" 0 sized packets in the middle or (in this case) start of the stream [17:41:24 CEST] <wm4> but the new decode API strictly considers 0-sized input EOF, and won't leave the EOF state [17:41:30 CEST] <Daemon404> like, entries in the index that are 0 sized? [17:41:31 CEST] <wm4> what do [17:41:39 CEST] <Daemon404> or? how else could it happen [17:41:42 CEST] <wm4> ffprobe shows a 0-sized packet [17:41:56 CEST] <Daemon404> what sort of file? [17:41:58 CEST] <nevcairiel> avi uses that for vfr [17:42:01 CEST] <wm4> aac in mp4 [17:42:24 CEST] <Daemon404> i suppose its possible in mp4 [17:42:31 CEST] <Daemon404> though i dont know why it would even be returned by the demuxer [17:42:32 CEST] <nevcairiel> also, shouldnt eof just be NULL, not a 0 sized avpacket [17:42:58 CEST] <wm4> nevcairiel: I'd say so too, but the API considers both EOF [17:43:04 CEST] <wm4> I even had a reason for this, but I forgot [17:43:07 CEST] <nevcairiel> you defined the api =p [17:43:43 CEST] <wm4> it _might_ have been because ffmpeg.c set metadata on drain packets [17:43:48 CEST] <wm4> so they couldn't be NULL [17:59:15 CEST] <nevcairiel> did the old api handle those packets differently or how did it work there? [18:34:14 CEST] <Daemon404> wm4 / nevcairiel - there is a patch in libav-land for dropping memalign hack [18:34:23 CEST] Action: Daemon404 wonders how controversial this will be (it should not be) [18:34:58 CEST] <JEEB> calculate how many things on FATE end up using it and see based on that [18:35:12 CEST] <JEEB> probably close to zero, but just in case [18:35:14 CEST] <wm4> nice [18:36:31 CEST] <jkqxz> Does it make configure mock you for using random configure lines you found on the internet if you pass --enable-memalign-hack? That should be a requirement. [18:37:20 CEST] <Daemon404> lol [18:39:01 CEST] <JEEB> :D [19:05:02 CEST] <kurosu> found the bug in the vc2 encoder, clearly subtle [19:05:28 CEST] <kurosu> I suspect this also means the bitstreams produced may not have been always spec-compliant [19:07:55 CEST] <kurosu> (reorder the words in that last sentence as you see fit) [19:09:07 CEST] <cone-282> ffmpeg 03Thomas Volkert 07master:f591b7b5265f: rtpenc: packetizer for VC-2 HQ RTP payload format (draft v1) [19:10:45 CEST] <wm4> it's strange when a commit has "draft v1" in its subject line when it's pushed to master [19:11:10 CEST] <nevcairiel> those rtp standards are all weird drafts [19:12:53 CEST] <BtbN> have you ever looked at the commit log on android? [19:13:18 CEST] <BtbN> litteraly over half of the commits there have "DO NOT MERGE" in them [19:14:05 CEST] <wm4> isn't there some kind of unintuitive reason for that? [19:16:50 CEST] <atomnuker> kurosu: where's the bug? [19:17:01 CEST] <kurosu> see patchset posted to ml [19:17:15 CEST] <kurosu> atomnuker, ^ [19:17:19 CEST] <JEEB> wm4: probably never rebased to remove it or something? [19:17:33 CEST] <JEEB> although gerrit should let you do that [19:18:17 CEST] <atomnuker> kurosu: I don't see it yet [19:18:24 CEST] <Daemon404> JEEB, you mean amended [19:18:35 CEST] <atomnuker> probably the mail being delayed again [19:18:45 CEST] <Daemon404> i dont like how thinks like gerrit break gits model [19:18:57 CEST] <Daemon404> as in, patch series model [19:20:53 CEST] <nevcairiel> more vsynth tests, that will make for one happy Daemon404 [19:24:31 CEST] <kurosu> except I got the padding wrong and need to generate the patchset :( [19:24:41 CEST] <kurosu> *regenerate [19:29:28 CEST] <atomnuker> kurosu: you'll still get non-bitidentical files if someone bumps the major/minor/micro [19:29:53 CEST] <kurosu> huh, why ? [19:29:58 CEST] <nevcairiel> typically we have the bitexact flag to exclude that information, vc2 should probably obey that if it does not yet [19:30:01 CEST] <atomnuker> you'll need to change aux_data[] = LIBAVCODEC_IDENT; to "ffmpeg" [19:30:05 CEST] <kurosu> it's part of the version string , [19:30:11 CEST] <kurosu> ok [19:30:16 CEST] <atomnuker> problem is that the bitexact flag isn't exposed in avcodeccontext [19:30:24 CEST] <nevcairiel> sure is [19:30:36 CEST] <nevcairiel> aacenc even supports it =p [19:30:43 CEST] <nevcairiel> hence, you should know this! [19:30:43 CEST] <nevcairiel> :D [19:30:59 CEST] <kurosu> so the fate data must regenerated again as the version data will be changed? [19:31:04 CEST] <atomnuker> shit, I was looking at the wrong thing [19:31:10 CEST] <atomnuker> yeah, it's avctx->flags [19:31:56 CEST] <kurosu> maybe I'll not generate again the fate data, if another patch is needed, the writing of which I delegate to the encoder's author :) [19:32:08 CEST] <atomnuker> so just put an if (avctx->flags & AV_CODEC_FLAG_BITEXACT) aux_data = "ffmpeg" else aux_data = LIBAVCODEC_IDENT [19:32:37 CEST] <atomnuker> I could do that, but in 2 hours when I'm home [19:33:14 CEST] <kurosu> I'd prefer that, yes, as you'll probably the reviewer and pusher for that patchset [19:33:41 CEST] <atomnuker> kurosu: pad_c can reach up to quite a few bytes, could you do a quick non-scientific performance test? [19:33:51 CEST] <nevcairiel> so these vsynth tests actually check for the bitexactness of generated bitstreams? doesnt that sound rather fragile, any improvement to the encoder would trip it? [19:34:13 CEST] <kurosu> nevcairiel, that's also part of the plan [19:34:34 CEST] <kurosu> like x264 should produce identical bitstreams given same parameters, whatever the platform [19:34:52 CEST] <kurosu> if there's a change to the format, then updating fate is needed [19:35:02 CEST] <kurosu> everything vsynth follows that principle [19:35:33 CEST] <cehoyos__> kurosu: Did you compiare the speed of the new bitstream reader with and without av_likely()? [19:35:41 CEST] <kurosu> (and there's plently lossy codecs in there, such as jp2K, mpeg2, dnxhd, ...) [19:36:03 CEST] <kurosu> cehoyos__, no, I think I was generous enough with my time on it [19:36:37 CEST] <kurosu> I'd say I haven't been paid back in kindness, so little incentive to pursue that [19:37:29 CEST] <cehoyos__> Too bad to read;-( [19:37:30 CEST] <kurosu> I was kind enough to work on vc2 :) [19:37:45 CEST] <cehoyos__> That was definitely a good idea! [19:38:24 CEST] <cehoyos__> kurosu:x264 multithreading is not reproducible, only single-threading is [19:39:04 CEST] <kurosu> anyway, it was a minor inconvenience not warranting my stoping - the time spent is the reason for stopping [19:39:14 CEST] <kurosu> cehoyos__, I think there's a --deterministic option for that [19:39:33 CEST] <cehoyos__> I didn't know it, ty [19:39:41 CEST] <JEEB> cehoyos__: multithreading is deterministic if VBV is not enabled [19:39:56 CEST] <JEEB> VBV kills determinism [19:40:14 CEST] <JEEB> (and I think but am not sure - changing the amount of threads - although don't quote me on othis) [19:40:54 CEST] <cehoyos__> I was under the impression that threads themselves make it unreproducible but it's been some time I tested (and it isn't really FFmpeg-related anyway). [19:41:45 CEST] <JEEB> and the option actually is non-deterministic :) [19:41:46 CEST] <JEEB> IIRC [19:44:10 CEST] <JEEB> https://mailman.videolan.org/pipermail/x264-devel/2015-April/011036.html [19:44:34 CEST] <JEEB> so yeah, multithreading and VBV is the case where determinism goes out of the window [20:18:15 CEST] <kurosu> atomnuker, regarding the memset, I think it is required because the padding value is 0xFF, unless you check the -strict setting and not do the memset, but somewhat risking writing an invalid bitstream [20:33:38 CEST] <Shiz> so I'm caught in a bit of a pickle here -- I'm dealing with a format which is just MPEG-PS with a custom header, for which I've written the necessary mpeg.c enhancements [20:33:56 CEST] <Shiz> the video is bog-standard h.264 and the audio is AT3 with a custom-ish header in PRIVATE_STREAM_1 packets [20:34:17 CEST] <Shiz> so I've written a parser for these packets, but apparently setting avcodec params in parsers is a No Go [20:34:30 CEST] <Shiz> but this header isn't exactly used anywhere else, and stuffing it in mpeg.c seems not very useful either [20:35:17 CEST] <Shiz> (especially since the headers are repeated per frame, which yes technically can mean the audio format changes per frame) [20:35:43 CEST] <Shiz> does anyone have thoughts on how to best approach dealing with this so that I can actually get it merged and not rejected for doing Bad Things [20:35:45 CEST] <wm4> I think in theory parsers can very well set codec parameters, but I'm not sure about what kinds of interactions you have [20:36:02 CEST] <Shiz> in theory yeah, which is what I'm doing right now [20:36:09 CEST] <Shiz> I'm also told it's a pretty big no-no though [20:36:13 CEST] <JEEB> I think the last ATRAC3+ MPEG-PS support patch got stopped at that point [20:36:22 CEST] <nevcairiel> parsers shouldnt be required to set codec parameters [20:36:27 CEST] <nevcairiel> either the codec does that, or the demuxer [20:36:33 CEST] <JEEB> and since the comment was not clear enough the patch never got new versions [20:36:51 CEST] <JEEB> yeah, so I guess the parser could stop stripping the frame headers and the demuxer would set a field? [20:37:54 CEST] <JEEB> header_included = 1 or so [20:38:05 CEST] <Shiz> stupid_custom_header = 1 [20:38:35 CEST] <JEEB> of course this also means that you have to move some init from init() to decode() [20:38:44 CEST] <JEEB> since it would then init the values during the first frame appearing [20:39:29 CEST] <JEEB> so yeah, currently the decoder is completely dependant on something setting the values before hand :) [20:39:50 CEST] <JEEB> which is why both Shiz and the guy from 2014 tend to add the parameter setting into the parser [20:39:51 CEST] <Shiz> i guess another approach is delegate to the OMA parser if such a thing is possible [20:40:06 CEST] <Shiz> (no clue if you can do that from another demuxer0 [20:40:08 CEST] <Shiz> OMA demuxer* [20:40:15 CEST] <Shiz> and deal with the custom header there [20:40:20 CEST] <Shiz> since it does use some OMA tables [20:41:01 CEST] <JEEB> you can use a demuxer in demuxer but I've never done double track drifting [20:41:19 CEST] <wm4> <nevcairiel> parsers shouldnt be required to set codec parameters <- but they're perfectly in the position to do so [20:41:40 CEST] <Shiz> it seems cleaner architecturally, maybe [20:41:48 CEST] <Shiz> than adding custom header parsing to the AT3+ decoder [20:42:37 CEST] <JEEB> not like we don't already have support for AVCc and Annex B AVC [20:43:17 CEST] <JEEB> and unlike with those you could just set the correct value in the demuxer since the formats don't mish-mash (unlike with AVC where people stuck Annex B into MP4 etc) [20:44:48 CEST] <JEEB> but yes, it means that the decoder would have to be changed which might not be fun [20:45:34 CEST] <Shiz> gotta check how other stuff deals with nested containers [20:45:43 CEST] <Shiz> i mean surely the entire intention of shit like matroska is nested containers [20:45:49 CEST] <Shiz> maybe i should check the matroska dec- *gets shot* [20:46:24 CEST] <wm4> ? [20:46:37 CEST] <wm4> are you talking about mkv avi/qt support? [20:48:09 CEST] <JEEB> yeah, those are generally handled by just having the decoder be able to handle them or so [20:52:33 CEST] <wm4> the packet formats are usually the same, so only the headers need to be parsed additionally [20:53:29 CEST] <Shiz> yeah [20:53:37 CEST] <Shiz> the packets can be passed straight to the at3+ decoder [20:53:59 CEST] <Shiz> with the headers removed ofc [20:54:32 CEST] <JEEB> basically my pick would probably be the have the demuxer tell the decoder which mode it will be and whether a parser is needed [20:54:47 CEST] <JEEB> and then move the value setting to decode() [20:56:46 CEST] <durandal_170> when we gonna apply lbr dts patches? [20:57:34 CEST] <Shiz> JEEB: how would i tell the decoder that? [20:59:32 CEST] <JEEB> set a value in avcodeccontext. or use the extradata field [21:01:22 CEST] <JEEB> side data is another modern way of passing info around I guess [21:04:13 CEST] <wm4> JEEB: actually demuxers should set AVStream.codecpar fields [21:04:15 CEST] <wm4> not avctx [21:04:51 CEST] <JEEB> yes [21:05:04 CEST] <JEEB> gotta get rid of the old calling habits [21:05:33 CEST] <Shiz> lol [21:05:40 CEST] <Shiz> hmm [21:05:51 CEST] <Shiz> actually, adding the info to AVPacket side data doesn't seem bad [21:05:58 CEST] <Shiz> that way the OMA demuxer can do it too [21:06:13 CEST] <Shiz> and the parsing of that can be centralized to the a3+ decoder [21:07:42 CEST] <JEEB> or you duplicate the header structure in extradata or so. and then if extradata is allocated and big enough you use it, otherwise from the stream [21:08:19 CEST] <Shiz> luckily it's just a single byte [21:08:20 CEST] <Shiz> :p [21:08:25 CEST] <Shiz> err, maybe two [21:08:27 CEST] <Shiz> yeah, two [23:25:39 CEST] <pfelt> afternoon all. i think i've cleaned up this code enough for wider comment. what's the proper way to get my patch to src_movie.c into the right hands? [23:26:00 CEST] <pfelt> (i'm expecting comments and changes) [23:27:05 CEST] <nevcairiel> if you think its ready for review, then it should be sent to the mailing list [23:29:49 CEST] <thardin> https://imagetragick.com/ [23:41:08 CEST] <pfelt> nevcairiel: kk. it's definitely ready for more eyes than mine, but i'm positive there'll be modifications to make [23:42:45 CEST] <thardin> don't quite recall if ffmpeg used imagemagick ho [23:42:47 CEST] <thardin> tho [00:00:00 CEST] --- Wed May 4 2016

1 0

ffmpeg.log.20160503
by burek 04 May '16

04 May '16

[00:16:01 CEST] <hyponic> c_14 still nothing. here is the files i am using: https://goo.gl/g1mJSc https://goo.gl/Gf0d4q [00:21:00 CEST] <c_14> Eh [00:21:06 CEST] <c_14> literally none of those subtitle events has a duration [00:21:10 CEST] <c_14> They won't be displayed [00:21:12 CEST] <c_14> ever [00:28:40 CEST] <devster31> hi, where can I get a complete list of the libraries I need to compile ffmpeg? [00:29:12 CEST] <hyponic> c_14 00:00:08,359 --> 00:00:08,359 isn't that a duration? [00:29:27 CEST] <hyponic> those are subs extracted from the stream itself. [00:29:40 CEST] <c_14> Last time I checked 8.359 - 8.359 is 0 [00:30:14 CEST] <hyponic> c_14 hmm... good valid point i didn't see that. but those are extracted from the mkv stream. [00:30:31 CEST] <hyponic> c_14 can i give you a test stream on pm? [00:30:40 CEST] <c_14> sure [00:33:50 CEST] <c_14> devster31: afaik the only library ffmpeg needs is a valid libc [00:34:38 CEST] <c_14> everything else is optional [00:36:22 CEST] <devster31> yes, I meant all the optional ones [00:36:31 CEST] <devster31> the list of supported codecs and whatnot [00:37:26 CEST] <c_14> decoders for most everything is standard [00:37:35 CEST] <c_14> there's a few encoders that you need if you want those [00:37:41 CEST] <c_14> check the output of ./configure --help [00:37:45 CEST] <c_14> That lists everything [00:37:50 CEST] <devster31> alright, thanks [00:38:13 CEST] <furq> devster31: https://ffmpeg.org/general.html#Supported-File-Formats_002c-Codecs-or-Featu… [00:38:36 CEST] <furq> anything labelled with an E requires an external library [00:38:54 CEST] <furq> or most things, anyway, since that wasn't 100% accurate last time i checked [00:39:14 CEST] <c_14> Oh, I didn't know that page even existed [00:39:22 CEST] <devster31> woa that's a long list [00:39:26 CEST] <furq> it's tucked away pretty well [00:39:35 CEST] <furq> i think i found it by chance through google [00:40:06 CEST] <furq> ./configure --help is the right way to go if you just want a big list of supported libs [10:13:33 CEST] <anddam> hello, I'm trying to merge a .srt file with a MKV, I'm doing ffmpeg -i $f.mkv -i $f.srt -map 0:0 -map 0:1 -map 1 -c copy ../$f.mkv [10:14:17 CEST] <anddam> where f is set to the name of the files without the dot and extension, I'm explictly using 0:0 and 0:1 since the input 0 has multiple audio tracks and I only want the 0:1 [10:14:48 CEST] <anddam> I remember merging srt in MKV in past, this time I'm getting "Codec for stream 0 does not use global headers but container format requires global headers" [10:15:02 CEST] <anddam> that I think is a warning since it's yellow in terminal [10:15:09 CEST] <anddam> and then [matroska @ 0x7fd614015c00] Can't write packet with unknown timestamp [10:15:11 CEST] <anddam> av_interleaved_write_frame(): Invalid argument [10:16:55 CEST] <anddam> what is this lack of timestamp due to? [10:31:42 CEST] <halcyforn> hello [10:33:24 CEST] <halcyforn> i cant find this on net how to configure ffserwer and ffmpeg to work like readyshare on router. is this possible? [11:48:47 CEST] <Carlrobertoh> I'm trying to do a screen casting with GDIGRAB. Could anybody tell me which timestamp shall i use? [11:49:04 CEST] <Carlrobertoh> input packet timestamps? [12:13:14 CEST] <Sartsj> does anyone here have any experiences packing a MPEGTS into smoothstreaming? I have a question open on superuser that I could use some help on: http://superuser.com/questions/1072458/ffmpeg-packaging-h264mpegts-into-smo… [12:16:25 CEST] <Fyr> guys, is it possible to mux DTS-HD into mp4 container? [12:16:45 CEST] <Fyr> pediwikia says that MP4 supports DTS-HD. [12:17:48 CEST] <Fyr> but, nowhere can it be found. [12:21:06 CEST] <c_14> I'm pretty sure mp4 doesn't support DTS [12:22:24 CEST] <Fyr> c_14, https://en.wikipedia.org/wiki/Comparison_of_video_container_formats#Audio_f… [12:22:43 CEST] <JEEB> there's a mapping for DTS in ISOBMFF [12:23:09 CEST] <JEEB> although I must say that wikipedia isn't the best source for this sort of stuff [12:23:24 CEST] <JEEB> I think L-SMASH supports it, but not sure about libavformat [12:25:25 CEST] <Paranoialmaniac> libavformat wrongly supports DTS in MP4 which uses mp4a fourcc + ObjectTypeIndication [12:27:08 CEST] <Paranoialmaniac> MP4 does not support DTS audio since there is no spec of the encapsulation [12:28:16 CEST] <Paranoialmaniac> registration of ObjectTypeIndication for a codec does not mean that codec can be encapsulated in MP4 [12:28:22 CEST] <Fyr> ok [12:29:49 CEST] <Fyr> why do people keep using DTS or Dolby, when FLAC has already been implemented and it's free for use? [12:30:45 CEST] <Fyr> FLAC compression, I guess, is almost maximal. [12:31:45 CEST] <Paranoialmaniac> channel layout? i think FLAC does not support all supported channel layout of DTS audio and DolbyDogital [12:32:57 CEST] <Paranoialmaniac> or embedded downmix [12:34:25 CEST] <CruX|> Fyr: hmm why flac why not ape [12:34:31 CEST] <CruX|> both are free [12:34:42 CEST] <Fyr> ok [12:34:50 CEST] <Fyr> let's ape everything. [12:35:10 CEST] <Fyr> why are there so many standards? [12:35:43 CEST] <Fyr> blu-ray uses DTS-HD and TrueHD. [12:36:23 CEST] <c_14> And occasionally pcm [12:36:27 CEST] <Fyr> +some additional. [12:36:27 CEST] <Fyr> a player should support all of them instead of one. [12:38:21 CEST] <ritsuka> actually there are some specs for DTS in ISOBMFF, but I guess they aren't free or public domain [13:29:44 CEST] <Fyr> guys, is it possible to convert DTS-HD to ALAC, keeping all the channels? [13:30:53 CEST] <Fyr> Apple users are so pitiable, I want my video to be playable on every platform. [13:33:53 CEST] <sasos90> hey guys [13:33:57 CEST] <Fyr> hey [13:34:04 CEST] <sasos90> i am developing an android app. and i really want to use ffmpeg [13:34:12 CEST] <sasos90> but i get some output stream file error [13:34:17 CEST] <sasos90> does anyone knows about that? [13:34:27 CEST] <sasos90> more accurate: Output #0, mp4, to 'i /storage/emulated/0/Download/test.mp4': Output file #0 does not contain any stream [13:35:50 CEST] <sasos90> full output: http://pastebin.com/pBsqmRnG [13:47:28 CEST] <sasos90> Fyr: do you know something about it perhaps? [13:47:40 CEST] <Fyr> no [13:47:53 CEST] <Fyr> I've never tried to develop for Android. [13:50:41 CEST] <jkqxz> sasos90: What was the full command line you used to produce that output? [14:19:25 CEST] <RoyK> hi all. I have a USB webcam connected to a banana pi (raspberry pi clone thing), and attempting to read from it with -vcodec copy works, but gives me a bitrate at 184522.9kbits/s, which I somewhat lower than the theoretical limit of USB2, but still a wee bit high [14:20:45 CEST] <RoyK> hm... I thought this camera did some encoding in the first place - doesn't look that way :( [14:22:21 CEST] <RoyK> well, it should support h.264, according to the specs [14:22:33 CEST] <jkqxz> Webcams still give very high bitrates when encoding to MJPEG. They really only do just enough to fit the stream inside the available USB bandwidth. [14:23:40 CEST] <RoyK> any idea how I can tell the camera to store in h.264? it's a logitech C920 [14:27:38 CEST] <jkqxz> You do need to explicitly enable H.264 encoding, because IIRC it's one of the ones which embeds the H.264 stream inside a comment field in JPEG images. (Yay for "compatibility".) [14:27:55 CEST] <jkqxz> I'm afraid I don't know how to do that with ffmpeg, though. [14:28:19 CEST] <RoyK> http://paste.debian.net/679470/ [14:38:14 CEST] <jkqxz> RoyK: "ffmpeg -f v4l2 -video_size 1280x720 -input_format h264 -i /dev/video1 -c:v copy out.mkv" works for me with a C920 (gives me a bit over 3Mbps). [14:38:42 CEST] <RoyK> I only have /dev/video0 [14:39:11 CEST] <RoyK> oh [14:39:17 CEST] <RoyK> --input_format [14:39:18 CEST] <RoyK> sec [14:43:59 CEST] <RoyK> hm [14:44:02 CEST] <RoyK> jkqxz: ffmpeg -f v4l2 -video_size 1280x720 -i /dev/video0 -input_format h264 -c:v copy -c:v copy output$i.mkv [14:44:19 CEST] <RoyK> still no h.264 [14:45:58 CEST] <relaxed> RoyK: -input_format h264 needs to go before the input [14:46:07 CEST] <RoyK> oh :) [14:47:23 CEST] <RoyK> that's more like it :D frame= 934 fps= 36 q=-1.0 size= 11525kB time=00:00:30.90 bitrate=3055.0kbits/s speed=1.18x [14:47:44 CEST] <RoyK> relaxed: thanks :) [14:56:20 CEST] <Tuman> is there anybody here who speaks italian? [15:08:43 CEST] <Fyr> Borkr, are you borkra? [15:09:28 CEST] <Borkr> Fyr: Nope, sorry :) [16:29:22 CEST] <Zitter> hi, I have a .mp4 container (with audio & video inside) and another file with audio only. Now I want to add second_file.m4a to the first_one.mp4 without losing audio from first_one.mp4. Best goal is to set first video's audio to a lower volume than second one. [16:30:25 CEST] <Fyr> Zitter, don't you want to add another audio channel? [16:30:50 CEST] <Fyr> or you want to get rid of the first audio and use only the second m4a file? [16:30:54 CEST] <Zitter> I've tried ffmpeg -i first_video.mp4 -i audio.m4a -map 0:v -map 0:a -codec copy output.mp4 but it is not what I need [16:31:01 CEST] <Zitter> Fyr, no. [16:31:35 CEST] <Zitter> Fyr, I don't want add another audio channel. I want to listen *both*, but first audio with a lower volume [16:31:44 CEST] <Zitter> as a audio background [16:32:13 CEST] <Zitter> it is a meeting in italian, the second audio is english translation. [16:36:45 CEST] <DHE> well, with that map command you're omitting the second file entirely [16:37:07 CEST] <DHE> that can be done, you'll need to use -filter_complex and assemble a multi-stage pipeline [16:42:51 CEST] <Zitter> DHE, yes. But how to take only audio from first container? [16:43:25 CEST] <Fyr> Zitter, http://pastebin.com/hyHyFDQR [16:43:55 CEST] <Fyr> you set the desired volume. [16:43:55 CEST] <kepstin> Fyr: that seems kind of silly, you can do it all in a single command :) [16:44:05 CEST] <Fyr> yes, I know. [16:44:24 CEST] <Fyr> kepstin, but you didn't write a thing. [16:44:34 CEST] <Fyr> I wrote the solution. [16:44:47 CEST] <Fyr> plain and simple [16:44:57 CEST] <Fyr> without finery. ;) [16:46:16 CEST] <kepstin> I just got here. But sure, "ffmpeg -i first_video.mp4 -i audio.m4a -filter_complex '[0:a]volume=-3dB[base];[base][1:a]amerge[mixed]' -map '[mixed]' output_audio.m4a" should do it in 1 command. [16:46:46 CEST] <kepstin> add aac encoding options and adjust volume to taste. [16:46:50 CEST] <Fyr> yeah, it looks like. [16:47:04 CEST] <Zitter> kepstin, I need both audio/video as a result [16:47:31 CEST] <kepstin> Zitter: then add a '-map 0:v -c:v copy' before the output file (and rename it to something.mp4) [16:48:27 CEST] <Zitter> ok... well, ffmpeg is really nice :) [16:48:54 CEST] <Fyr> yeah, but its developers are not. [16:49:08 CEST] <Fyr> they are bad people and they know it. [16:57:04 CEST] <durandal_1707> Fyr: what you are talking about? [16:57:12 CEST] <Fyr> ? [16:57:47 CEST] <Fyr> the developers are not going to fix the delay bug I posted. [16:58:21 CEST] <durandal_1707> whats bug number? [16:58:43 CEST] <kepstin> that doesn't make them bad people.. just, busy? unconvinced? unaware that an issue exists? [16:59:25 CEST] <durandal_1707> Perhaps bug is hard to fix? [17:00:45 CEST] <Fyr> durandal_1707, https://trac.ffmpeg.org/ticket/5290 [17:01:15 CEST] <Fyr> also, I'm very sad about absence of multithreading when converting FLAC. [17:01:15 CEST] <DHE> ffmpeg -i sourcevid.mp4 -i alternate-audio.m4a -filter_complex "[0:a]volume=-10[srcvol];[srcvol][1:a]amix[audioout]" -map [0:v] -map [audioout] -c:v copy output.mp4 [17:01:20 CEST] <kbarry> Typicallu I use RTMP in either a "Pull from me" or "Pushed to you" scenario. [17:01:36 CEST] <kbarry> I can do rtmp "Push", and find example all over. [17:02:00 CEST] <kbarry> Is ffmpeg capable of RTMP (pul), where the signal waits for connections to pick up said video signal? [17:02:02 CEST] <Fyr> 16-core Intel Xeon cluster convert FLAC as fast as my 4-cored phone does. [17:02:09 CEST] <DHE> oh wait that's not how the volume works [17:03:26 CEST] <flux> fyr, I'm not saying that isn't annoying, but I'm certain there are more valuable things on the table than multicore flac conversions :) [17:03:48 CEST] <flux> besides I would really expect the xeon to trump the mobile core even single threaded, did you really benchmark that? [17:04:09 CEST] <Fyr> flux, try to compress 1-hour 24-bit/192 kHz audio. =) [17:04:25 CEST] <kepstin> flac is sufficiently fast that it's really not something anyone cares about... particularly if they're also compressing video [17:04:50 CEST] <flux> well, for one, multithreading the AAC converter would probably be higher priority [17:05:13 CEST] <kepstin> that said, I'm pretty sure individual packets in flac can be compressed in parallel without issue, so if someone feels like it would be useful, it would be great if they implement that :) [17:05:33 CEST] <Fyr> ok, but the delay bug is related to AAC. [17:05:37 CEST] <durandal_1707> Fyr: I have patch for mt flac encoding [17:05:49 CEST] <Fyr> *muxing mp4 [17:06:01 CEST] <Fyr> durandal_1707, where have you been all this time????????????? [17:06:28 CEST] <durandal_1707> Thing is it is missing some stuff [17:06:50 CEST] <Fyr> I wasted a hundred of Vooodooo dolls onto FFMPEG developers. [17:07:01 CEST] <Fyr> some of them must be dead already. [17:07:55 CEST] <flux> you must be in the misguided understanding that FFmpeg developers owe you something.. :) [17:08:03 CEST] <Fyr> they do [17:08:10 CEST] <Fyr> I made a donation. [17:08:16 CEST] <flux> ah, right, a donation [17:08:23 CEST] <fling> How do I properly create a multiangle video from a bunch of files? [17:08:27 CEST] <flux> donation with strings attached? [17:08:32 CEST] <durandal_1707> Of few bucks [17:08:38 CEST] <kepstin> a donation is just that, a donation... it doesn't mean they owe you anything... [17:08:45 CEST] <Fyr> KKKKKKKK [17:09:00 CEST] <flux> next time fyr should make a deal instead of donation :) [17:09:01 CEST] <Fyr> I need more Voodoo dolls. [17:09:09 CEST] <Fyr> flux, been there, tried that. [17:09:10 CEST] <fling> 2. How do I properly convert mjpeg to h264 or even better thing without a noticeable quality loss? [17:09:19 CEST] <Fyr> posted bug, reported onto #ffmpeg-devel. [17:09:28 CEST] <Fyr> they requested donation. [17:09:35 CEST] <Fyr> I made the donation. [17:09:40 CEST] <Fyr> nothing happened. =) [17:09:52 CEST] <DHE> fling: multi-angle as in a video file with lots of distinct video sterams in it? [17:10:10 CEST] <fling> DHE: right. [17:10:13 CEST] <Fyr> they talked like 15 minutes about the bug, then the conversation flawed away. =) [17:10:22 CEST] <flux> fling, I don't think there's a "direct" way avoiding lossiness, just find a nice crf argument for x264 and off you go.. [17:10:32 CEST] <durandal_1707> Fyr : donate until bug is fixed [17:10:32 CEST] <flux> fling, probably something between 10 and 20 :) [17:10:46 CEST] <flux> double the donation each time. that'll get 'em! [17:10:50 CEST] <DHE> fling: ffmpeg -i inputfile0 -i inputfile1 -i inputfile2 ... -map [0:v] -map [1:v] -map [2:v] ... -c:v XX output.mkv [17:10:50 CEST] <fling> DHE: also the video freezes when I capture from multiple webcams at once -> https://bpaste.net/show/6dfe631deddc [17:10:57 CEST] <Fyr> ='( [17:11:07 CEST] <fling> DHE: but it works just fine when I capture with separate ffmpegs. [17:11:22 CEST] <durandal_1707> Fyr: they need to do job for starving family [17:11:36 CEST] <kepstin> fling: hmm. yeah, multiple live inputs with ffmpeg is a bit of a problem, since the whole input code is single-threaded :/ [17:12:02 CEST] <fling> flux: I don't know how to find the proper value for crf, my eyes are not so good for the video quality comparison :> [17:12:27 CEST] <fling> kepstin: do I need to use multiple ffmpegs with pipes then? [17:12:27 CEST] <durandal_1707> Fyr: also spamming devel irc channel now and then [17:12:39 CEST] <kepstin> fling: there is no "proper" value, it's all up to "what quality loss vs filesize tradeoff can you tolerate" [17:13:06 CEST] <Fyr> durandal_1707, if they were good developers, they would not have starving families. [17:13:13 CEST] <fling> kepstin: ahh it also explains why things go wrong when alsa overflows the buffer. [17:13:41 CEST] <flux> fling, I'll give you a value: 15. go ahead and use it ;) [17:13:45 CEST] <kepstin> fling: multiple ffmpegs with pipes might actually work better, since the pipes act as a buffer so the different parts can run asynchronously (note that the default pipe buffer on linux is a bit small for uncompressed video tho) [17:14:00 CEST] <durandal_1707> Fyr: yeah nobody claim open source give you free lunch [17:14:22 CEST] <Fyr> durandal_1707, well, it's obviously not free. [17:14:26 CEST] <fling> kepstin: I want the smallest possible file for the quality I need. But I can't properly compare the video quality with my own eyes& [17:15:13 CEST] <fling> kepstin: what if I will use mbuffers and not uncompressed video? I'm capturing with -c:v copy [17:15:19 CEST] <kepstin> fling: then borrow someone else's eyes, or pick a metric to analyze quality by. [17:15:34 CEST] <fling> what is metric? [17:15:54 CEST] <durandal_1707> Fyr: I Will try to finish that flac mt encoding patch [17:15:54 CEST] <fling> I hoped there is something for seeing the difference between different quality level encoded videos somehow [17:16:35 CEST] <kepstin> fling: there's metrics like 'psnr' or 'ssim' that attempt to quantify quality differences, but neither completely accurately models the human visual system [17:18:04 CEST] <furq> they're also not very useful if you have psy on, which you should [17:18:19 CEST] <fling> kepstin: also I'm capturing with -c:v copy because of the alsa xruns appearing when capturing -c:v libx264 [17:18:38 CEST] <fling> durandal_1707: what is mt? [17:18:49 CEST] <furq> multithreaded [17:18:49 CEST] <fling> DHE: thanks. [17:19:11 CEST] <fling> flux: should be useful. [17:19:39 CEST] <fling> Now I need to align the files somehow& [17:21:48 CEST] Action: kepstin is kind of surprised that aac isn't trimming the codec delay off properly; that's required (and works) for lots of audio codecs like mp3, opus, etc. [17:22:21 CEST] Action: fling is now surprised too [17:23:02 CEST] <kepstin> fling: that's probably not related to your issue :) [17:24:06 CEST] <fling> kepstin: I know, but I also remember the nasty mp3 delays. [17:25:14 CEST] <kepstin> yeah, it's basically fixed now in mp3 - at least if you use lame - since it throws a 'xing' or 'info' tag at the start with the number of samples delay [17:26:21 CEST] <kepstin> but with aac it's still a mess - some early encoders/decoders just assumed that there was a particular delay that all codecs used, iirc there's some itunes specific metadata in mp4 files, and then there's some newer way of specifying it with edit lists or something in the mp4 format [17:26:43 CEST] <flux> edit lists are fine, no? [17:26:45 CEST] <fling> Needs to be fixed! [17:27:10 CEST] <flux> and it's the standard (edit lists that is). [17:27:28 CEST] <kepstin> All I know is that I couldn't get anything to sample-accurate trim any of the aac files that I have tried making with a few different encoders and decoders :/ [17:28:05 CEST] <flux> if you set timescale to something nice, you can get microsecond trims, in theory ;) [17:28:06 CEST] <kepstin> hmm. Not sure I have tried ffmpeg's built-in aac encoder tho; I should give that a whirl. [17:29:20 CEST] <kepstin> my usecase is that I'm making a synchronized audio/video thing that runs in browsers, and for audio to loop correctly it has to have the delay properly trimmed. [17:29:28 CEST] <kepstin> Browser support for various formats kind of sucks :) [17:29:42 CEST] <flux> amazing if they don't support edit lists :( [17:29:54 CEST] <kepstin> I found that vorbis works best - chrome has an off-by-1 trimming bug there, and firefox is sample-accurate [17:30:14 CEST] <Fyr> kepstin, if it's somehow related to [17:30:14 CEST] <Fyr> https://trac.ffmpeg.org/ticket/5290 [17:30:14 CEST] <Fyr> then kick the developers in the nuts. [17:30:28 CEST] <kepstin> and firefox can't trim mp3 properly, but chrome does. I ended up compiling mpg123 with emscripten to get mp3s working in firefox [17:41:40 CEST] <A124> mp3 is inferior and outdated. [17:42:26 CEST] <kepstin> it's a legacy format for which a *lot* of pre-encoded files exist. Sometimes you just have to support it. [17:48:43 CEST] <RoyK> hm.... relaxed helped me finding a way to capture h.264 directly from my cam, but when I try to switch between using 'motion' (the program) and going back to ffmpeg (via a switch connected to the bpi), ffmpeg usually dies with a lot of these errors. any idea how I can reset the cam somehow? I tried an USB reset, but it doesn't work. It helps to wait a while, but I don't know what's really causing this http://paste.debian.net/679604/ [17:48:48 CEST] <Zitter> any hint on why offset doesn't work here: ffmpeg -i first_audio.m4a -itsoffset 00:08:22 -u second_audio.m4a -strict -2 -filter_complex amerge -c:a aac -f mp4 out_audio.m4a ? [17:49:17 CEST] <Zitter> btw, it is a -i and not -u on second output [17:51:21 CEST] <Fyr> I would use -ss and/or -to -t [17:51:33 CEST] <Fyr> and I'm sure it will work. [17:53:36 CEST] <kbarry> A124 What do you like to use instread of mp3? [17:59:07 CEST] <kepstin> I use opus when I can, it's a pretty nice codec (helps that they put the sample trimming right into the container spec, too) [18:14:14 CEST] <A124> kbarry AAC. [18:14:28 CEST] <A124> OPUS is better, of course, but the support is not yet everywhere. [18:14:54 CEST] <A124> And at higher bitrates AAC is pretty close to OPUS. [18:15:48 CEST] <A124> Though I contemplate, kbarry, that OPUS should be supported in browsers already, as youtube switched from AAC to OPUS month or so back. [18:22:05 CEST] <furq> they didn't switch, they use both [18:22:39 CEST] <furq> vp8/9 and opus aren't supported in safari and probably never will be because they are deeply in love with google [18:22:48 CEST] <furq> s/they/apple/ [18:24:36 CEST] <kbarry> A124 fruq I am relatively new to the ffmpeg/audio/video world. All my work currently is in audio, and as such, its been a bit harder for me to get information that is audio-specific. Not everything that applies to video, it would seem, applies to audio ie, keyframes?) [18:25:29 CEST] <A124> kbarry Not at all. But... if you use that audio in video, it is called fragments. [18:26:03 CEST] <A124> So if you use audio in video, you ideally want audio and video synchronized. Aka fps / audio chunks aligned. [18:26:10 CEST] <kbarry> For the foreseeable future, i will be working with audio-only. For thanks for the information. [18:26:24 CEST] <furq> fwiw there's nothing wrong with mp3 if you're not bitrate constrained [18:26:25 CEST] <A124> Also about audio AAC is the choice of modern players, bluray, etc. [18:26:38 CEST] <kbarry> (about what the pieces are called). [18:26:53 CEST] <furq> there's very little to choose between any of the popular audio codecs at rates above 128kbps [18:26:57 CEST] <kbarry> A124: I have been picking that up as I am getting more into it. [18:27:14 CEST] <furq> that's why all the listening tests you'll see are at 96k, so that it's actually possible to find differences [18:27:18 CEST] <A124> I have to disagree with furq, mp3 at 128 is inferior to OPUS at 128 [18:27:24 CEST] <furq> i said above 128 [18:27:34 CEST] <A124> Even above. [18:27:46 CEST] <furq> mp3 v2 sounds about as good as anything else [18:27:49 CEST] <furq> lame v2, that is [18:27:58 CEST] <kbarry> I guess the better question is, would toy "average" listener be able to tell te difference :) [18:28:08 CEST] <kbarry> Depends on the audience, the gear they have avaliable, etc. [18:28:12 CEST] <A124> Everyone has different hearing, and I can hear difference up to 320 kbps. [18:28:41 CEST] <A124> Better chinese phone with headphones. [18:29:03 CEST] <kbarry> One thing I was trying to do earlier was create an RTMP stream that I could pull. [18:29:22 CEST] <A124> I did this to compare the bitrates of OPUS, but it gave also info about the other format qualities obviously. [18:29:26 CEST] <kbarry> I was really trying to pull in my webcam with ffmpeg, then view that stream via ffplay [18:30:14 CEST] <furq> i should probably test with a standard test corpus but i've never been able to hear any difference between lame v2 and flac [18:30:15 CEST] <A124> kbarry mp3 is still inferior even above 128kbps. The other formats are very close. [18:31:01 CEST] <A124> furq I was able to hear difference of 256kpbs OPUS and FLAC, so anothr person also. [18:31:19 CEST] <kbarry> A124 furq do either of yuou have any recommendations for audio/streaming newbs trying to improve my base-knowledge? [18:31:27 CEST] <A124> But the difference was so miniscule, that for almost all audieces 256 OPUS (or say AAC) should be ok. [18:31:39 CEST] <kbarry> ie, sites, blogs, conventions, user groups, videos, etc. [18:31:45 CEST] <furq> as far as i can tell most people can't tell the difference between 128k opus and flac [18:32:01 CEST] <A124> kbarry IDK, read about opus, aac, do not use mp3 for (insert word here) sake [18:32:13 CEST] <furq> there's no reason to use mp3 these days anyway [18:32:24 CEST] <furq> but don't feel like you're doing something awful if you have to [18:32:29 CEST] <kbarry> I use it, because i don't know any better :) [18:32:33 CEST] <A124> furq Often the recording itself is done in lower quality, so depends on the record itself. [18:32:35 CEST] <kbarry> or didn't know any better [18:32:56 CEST] <furq> i still have plenty of music in mp3 [18:33:07 CEST] <A124> But if you got synthesized (real, not fake), at high sample rate that is multiple to the one you downsample, there really is difference. [18:33:21 CEST] <A124> Yeah, I do have a lot in mp3, but when I can I move to FLAC. [18:33:32 CEST] <furq> sure [18:33:36 CEST] <A124> Why? Lossless, and can make any lossy I want, ie OPUS for phone. [18:33:41 CEST] <furq> i can't hear the difference but i've got plenty of space for lossless [18:34:01 CEST] <A124> If I was a "regular" person I would want 128 to 256kbps opus or aac. [18:34:34 CEST] <kbarry> In an attempt to become more familiar with ffmpeg et. al, I have been trying to use it for my listening (ffplay) [18:34:47 CEST] <kbarry> And for recording , ie, music from a video on youtube, etc.) [18:34:48 CEST] <furq> but yeah in my experience the big difference between mp3 and newer codecs is below 128k [18:34:58 CEST] <furq> there is a huge difference between lame 64k and opus/aac at 64k [18:35:06 CEST] <A124> kbarry if you are on nix, opus tools are part of most distros. [18:35:07 CEST] <furq> or even vorbis [18:35:16 CEST] <kbarry> I'm on Windows. [18:35:17 CEST] <A124> kbarry If you worry about compatibility, use AAC. [18:35:31 CEST] <kbarry> (my shop is 60/40 linux/windows [18:35:36 CEST] <furq> the only thing to choose between them is compatibility really [18:35:59 CEST] <A124> Above 192kbps and AAC or OPUS, most people (taking general mass, not audio folks) do not hear difference much. [18:36:24 CEST] <A124> kbarry Btw, you mentioned streaming, any more details? [18:36:39 CEST] <A124> https://upload.wikimedia.org/wikipedia/commons/8/8d/Opus_quality_comparison… [18:36:43 CEST] <A124> https://upload.wikimedia.org/wikipedia/commons/e/ec/Opus_bitrate%2Blatency_… [18:37:09 CEST] <A124> Unless you want lower bitrate or low latency, AAC is today perfectly good. [18:37:24 CEST] <furq> kbarry: http://listening-test.coresv.net/results.htm [18:37:39 CEST] <A124> With opus, music is usable from 48kbps, while at 64kbps it becomes pretty ok [18:37:47 CEST] <furq> that's the best listening test i'm aware of [18:38:34 CEST] <A124> Oh a person I know that works with video and audio for production told me... [18:39:04 CEST] <A124> To use itunes library for aac. (Exctracting installer of itunes and using just the encoder from there) as it has best quality of all encoders. [18:39:21 CEST] <furq> yeah it'd be nice to find a listening test that compares fdk to qaac [18:39:26 CEST] <A124> Given that itunes does use AAC extensively for loooong years and they got ton of money it is believable. [18:39:31 CEST] <kbarry> furq: Wow, that is great. [18:39:36 CEST] <furq> there's one from 2011 which compares fhg to qaac, but nobody really knows how similar fdk and fhg are [18:39:41 CEST] <furq> fhg comes out quite well though [18:39:47 CEST] <kbarry> The comparisons make it a lot easier. [18:39:58 CEST] <furq> do note that the bitrates are a bit different [18:40:00 CEST] <furq> particularly mp3 [18:40:26 CEST] <A124> Some people just hate mp3, cause it sucks. Or some will love you for not using mp3: [18:40:49 CEST] <A124> Just AAC when you can xD I do not know of any crowd that hates AAC below 96kbps. [18:40:53 CEST] <A124> *above. [18:40:58 CEST] <furq> also yeah that chart illustrates well that not all encoders are created equal [18:41:11 CEST] <furq> 96k faac is much worse than 96k qaac or fdk [18:41:25 CEST] <A124> Sadly, yeah. [18:41:26 CEST] <furq> probably much worse than 96k lame [18:41:33 CEST] <furq> if you can imagine such a thing [18:42:21 CEST] <A124> kbarry Btw, we stream tons of audio daily, and use that both for voice and music, using OPUS, or older alternative (CELT MONO) [18:43:18 CEST] <A124> 20ms latency, great masking of lost packets, decent data savings (10-12kB/s per client) [18:43:52 CEST] <furq> this is all moot if you're using rtmp anyway, since your only real choice there is aac [18:44:01 CEST] <A124> If latency was not concern and was music only, aac would be as great. with OPUS you can go down to 5ms for realtime stuff. [18:44:14 CEST] <kbarry> furq see, there is a perfect example of a limit in my knowledge, [18:44:24 CEST] <kbarry> IF one isn't using RTMP, what else would one use? [18:44:31 CEST] <A124> kbarry What you said you are using? [18:44:42 CEST] <kbarry> Well, currently we use RTMP (mostly) [18:44:46 CEST] <kbarry> But are working towards HLS [18:44:53 CEST] <A124> Use AAC, that works almost everywhere. [18:44:57 CEST] <A124> And is great. [18:44:58 CEST] <kbarry> For myriad reasons. [18:45:11 CEST] <furq> latency obviously isn't an issue then [18:45:14 CEST] <DHE> HLS officially only supports h264 and AAC [18:45:30 CEST] <A124> Problem resolved. Solution found. [18:45:31 CEST] <DHE> any other codecs are at the implementation's discretion and not reliable [18:45:55 CEST] <furq> kbarry: you can do rtmp and hls at the same time with nginx-rtmp [18:46:00 CEST] <furq> assuming that's not what you're using already [18:47:11 CEST] <kbarry> typically we are dealing with incoming streams, some live broadcasts (say a concert), and static content (that concert last week), [18:47:26 CEST] <kbarry> were allowing for the scheduling between these two "types" of content. [18:47:35 CEST] <kbarry> i'm going to look up nginx-rtmp [18:47:47 CEST] <furq> https://github.com/arut/nginx-rtmp-module/ [18:48:13 CEST] <kbarry> https://obsproject.com/forum/resources/how-to-set-up-your-own-private-rtmp-… [18:48:48 CEST] <kbarry> question, [18:48:50 CEST] <furq> https://gist.github.com/fur-q/d7028f51c38f7d0bb56e [18:48:54 CEST] <furq> that's more or less the setup that i use [18:49:05 CEST] <kbarry> "Recording streams in multiple FLVs", in that contest, what is 'FLVs' [18:49:13 CEST] <kbarry> context* [18:49:22 CEST] <furq> https://en.wikipedia.org/wiki/Flash_Video [18:49:30 CEST] <furq> that's the only format that rtmp supports [18:49:40 CEST] <kbarry> OK, its just saying different bitrates/? [18:50:11 CEST] <furq> maybe? i've never used the recording stuff [18:51:06 CEST] <kbarry> furq, you are then acting as your own CDN? [19:01:15 CEST] <devster31> is yasm supported on ARM? it's suggested in the compilation build for ubuntu but not for the rpi [19:05:15 CEST] <kbarry> furq why do you use nginx-rtmp instead of something OOTB? [19:05:31 CEST] <kbarry> Maybe this is a newb question but, generally, how are you using nginx? [19:05:38 CEST] <kbarry> (ie, are you providing VOD?) [19:19:25 CEST] <kbarry> Ughhhhh, [19:20:03 CEST] <kbarry> I have not been able to get a "stereo-mix" recoding device (Windows 7). I'm not sure that I have the technical chops to hack it together myself. [19:20:19 CEST] <kbarry> Is there such a thing as ffmpeg capturing audi from a particular browse tab? [19:20:30 CEST] <kbarry> (or maybe from a single application) [19:20:39 CEST] <kbarry> as a sort of pseudo-stero-mix? [19:24:11 CEST] <kbarry> Actually, Do any of you use a VAC? (virtual Audio Cable), There seem to be more than one option. [19:25:16 CEST] <A124> https://i.imgur.com/Stt4MIP.jpg [19:25:19 CEST] <A124> ehm bad chan [19:49:50 CEST] <HeXiLeD> quick and fast question The V4L2 driver changed the video from 1024x720 to 640x480 anyone know what should i be looking for to get higher res ? [20:04:17 CEST] <andrey_utkin> is there anything wrong with encoding h264 video using -pix_fmt yuvj420p? I see "deprecated pixel format used, make sure you did set range correctly" which is widely described as safely ignoreable if you use CLI util, but I also use API-based app. So yuvj is a setting from legacy codebase, should i transition to yuv420p (without j)? Thanks in advance. [20:04:50 CEST] <Fyr> HeXiLeD, -vf scale=3840:2160 [20:05:00 CEST] <Fyr> make it bigger! [20:06:22 CEST] <HeXiLeD> [20:06:23 CEST] <Fyr> andrey_utkin, Google says it's a deprecable format. [20:06:23 CEST] <HeXiLeD> [20:06:29 CEST] Last message repeated 1 time(s). [20:06:29 CEST] <Fyr> use yuv420p instead [20:07:28 CEST] <HeXiLeD> i am looking for something like this ffmpeg -f v4l2 -framerate 30 -video_size 1024x720 -i /dev/video0 -c:v libx264 -b:v 1500k -an -f flv [20:07:31 CEST] <HeXiLeD> for youtube [20:07:38 CEST] <andrey_utkin> Fyr, seems right, but i am searching for some justification of this fact, to report to seniors. And the problem is that i don't know what yuvj thing is. [20:08:03 CEST] <drv> the "j" stands for JPEG as far as I know [20:08:51 CEST] <drv> it has to do with fullrange vs not [20:09:00 CEST] <jkqxz> andrey_utkin: Use yuv420p. If you want to give it specific colour information then set it in the AVCodecContext.colour* fields rather than changing the pix_fmt. [20:09:36 CEST] <Fyr> HeXiLeD, does it work or it doesn't? [20:10:07 CEST] <Fyr> it's not answerable until there's no question. [20:11:00 CEST] <andrey_utkin> jkqxz, i don't know if i want to give special color info, i think no. Now please help me with ridiculous question: what could be a reason behind using yuvj420p earlier in our app :) [20:11:04 CEST] <jkqxz> The effect of using yuvj*p is entirely <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/libx264.c;h=5030d…>, otherwise it is treated identically to yuv420p. [20:11:50 CEST] <HeXiLeD> Fyr: My code no. it falls back to 640 res [20:12:36 CEST] <jkqxz> (And you are better setting it by that AVCodecContext.color_range method if that is what you want.) [20:13:25 CEST] <Fyr> HeXiLeD, what does "$ ffprobe -i /dev/video0" return? [20:14:43 CEST] <jkqxz> HeXiLeD: Are you sure that it supports 1024x720? That's a strange resolution, and generally those things have to come from a fixed list. (Try 1024x768 or 1280x720.) [20:16:37 CEST] <jkqxz> andrey_utkin: They copied it from somewhere on the internet and it worked at the time, maybe? [20:17:34 CEST] <HeXiLeD> http://dpaste.com/3DVJZZG Fyr [20:18:31 CEST] <Fyr> HeXiLeD, you've just answered youself. [20:18:38 CEST] <jkqxz> andrey_utkin: To check, you could just look at the pixels of your input and see if any of the chroma values ever lie outside 16-235 or whatever the range is... [20:18:39 CEST] <Fyr> only through -vf scale. [20:18:53 CEST] <kepstin> HeXiLeD: if you want to see what resolutions that input supports, try running "ffmpeg -f v4l2 -list_formats all -i /dev/video0" [20:19:22 CEST] <andrey_utkin> jkqxz, very probable. I wonder can it have something to do with compatibility with some player vendors, like apple devices or browsers [20:23:59 CEST] <HeXiLeD> http://dpaste.com/3JCNDQ2 [20:24:01 CEST] <HeXiLeD> new cam [20:24:19 CEST] <HeXiLeD> it falls back to the highest compressed [20:24:54 CEST] <HeXiLeD> so if i want 1600x1200 wnat can it be done ? [20:25:10 CEST] <Fyr> HeXiLeD, http://trac.ffmpeg.org/wiki/Capture/Webcam [20:25:18 CEST] <Fyr> "Encoding example" [20:25:36 CEST] <jkqxz> Remove the -framerate 30. You can't carry 1600x1200 raw at 30fps over USB (I assume this is a UVC webcam). [20:25:36 CEST] <kepstin> HeXiLeD: to use the compressed (mjpeg) format, you need to use the "-input_format mjpeg" option, then set the resolution [20:25:56 CEST] <kepstin> that camera doesn't even support 1600x1200 raw at all [20:26:22 CEST] <kepstin> note that using mjpeg mode, even at lower resolutions, will probably enable higher framerates over using the (default) raw [20:28:35 CEST] <HeXiLeD> ummmm... i see that now... what if i use an ip cam ? [20:28:45 CEST] <HeXiLeD> will ffmpeg work well with it ? [20:28:52 CEST] <HeXiLeD> 1080P res cam [20:29:28 CEST] <jkqxz> Why not? It's on the list of resolutions. It'll probably only go at 5fps, though. [20:29:41 CEST] <HeXiLeD> -i http://camera1/video ? right ? [20:29:50 CEST] <HeXiLeD> 5 ? ffmpeg limitation ? [20:30:33 CEST] <jkqxz> In response to kepstin, sorry. [20:30:37 CEST] <HeXiLeD> here is my problem. stream to youtube using linux because windows machines i have around cannot handle the workload with software being used. ie xsplit and others [20:41:14 CEST] <kepstin> jkqxz: HeXiLeD: oh, I got the two mixed up.. the 1600x1200 mode is only on the raw, not mjpeg [20:41:15 CEST] <kepstin> how odd [20:41:32 CEST] <kepstin> I guess the jpeg encoder chip in the camera doesn't support frames that big :/ [20:41:40 CEST] <furq> do you really need more than 960*720 for youtube [20:41:54 CEST] <furq> that's enough to trigger youtube's HD detection, and at 1.5mbps it'll probably look nicer [20:43:06 CEST] <jkqxz> "uvcdynctrl -f" will give you a full list of formats/resolutions/framerates, so you can precisely specify something which is exactly supported without guessing. [20:51:22 CEST] <t4nk858> hi, I'm generating a file with specific requirements using this command "ffmpeg -i recording.mp4 -vsync vfr -q:v 9 recording.mjpeg". This works great, now I want to replicate the same within my own program using libffmpeg. I have never used the library, how might I do that? [20:51:40 CEST] <JEEB> there's no libffmpeg [20:51:45 CEST] <JEEB> there's only the separate libraries [20:51:59 CEST] <JEEB> and you can see how to use them by looking at the examples in the repository [20:52:11 CEST] <JEEB> there are examples on anything from demuxing to decoding to filtering to encoding [20:52:34 CEST] <t4nk858> hmm [20:52:36 CEST] <JEEB> https://github.com/FFmpeg/FFmpeg/tree/master/doc/examples [20:52:40 CEST] <t4nk858> thanks [20:52:55 CEST] <JEEB> the actual repo is on git.videolan.org, but the github preview is just prettier [20:53:05 CEST] <JEEB> that's why I web link there usually when pointing towards code [20:53:31 CEST] <t4nk858> is there an easy way to look at that the ffmpeg cli source code to get a more or less ready chunk doing what the command I pasted does? [20:53:57 CEST] <t4nk858> I guess that wouldn't be too straight-forward... [21:05:18 CEST] <t4nk858> is this the CLI source code? https://github.com/FFmpeg/FFmpeg/blob/master/ffmpeg.c [21:09:31 CEST] <HeXiLeD> jkqxz: [21:09:51 CEST] <HeXiLeD> luvcview ? [21:56:55 CEST] <HeXiLeD> -g brings me help [21:57:34 CEST] <Fyr> help is good. [21:57:54 CEST] <HeXiLeD> i mean no help [21:59:14 CEST] <HeXiLeD> https://bpaste.net/show/d3c9445c5c45 [21:59:27 CEST] <HeXiLeD> that is what i have now [22:00:44 CEST] <fling> https://bpaste.net/show/2211aee26a44 [22:14:58 CEST] <llogan> HeXiLeD: you need to show the complete console output from your command and describe what is wrong [22:17:18 CEST] <llogan> HeXiLeD: why are you using -c:v flv instead of libx264? also, you are using some audio options but using -an [22:40:28 CEST] <HeXiLeD> connects llogan because currently i don't have that support in ffmpeg. compiling at the moment [23:03:16 CEST] <brontosaurusrex> how would I hide libx264 info from stdin? (and just keep the framecounter, ETA stuff) [23:06:47 CEST] <furq> brontosaurusrex: -v quiet -stats [23:09:13 CEST] <brontosaurusrex> furq: thanks [23:20:25 CEST] <brontosaurusrex> another one: do i need any atom movers this days? [23:25:15 CEST] <brontosaurusrex> like qt-faststart [23:31:11 CEST] <llogan> brontosaurusrex: you can just use "-movflags +faststart" option [23:31:35 CEST] <llogan> generally only needed for playbkac via progressive download [23:33:16 CEST] <brontosaurusrex> llogan: and those are not default? [23:34:49 CEST] <llogan> it is not set by default [23:34:58 CEST] <brontosaurusrex> ok, thanks [23:49:58 CEST] <xxDCDxx> hi, how can I compile the ffmpeg CLI from source? [23:50:07 CEST] <c_14> ./configure; make [23:50:31 CEST] <c_14> https://trac.ffmpeg.org/wiki/CompilationGuide [23:51:03 CEST] <xxDCDxx> thanks! I'll give it a try. I'm trying to cross compile it for iOS, using this: https://github.com/kewlbear/FFmpeg-iOS-build-script But it only built the libraries [23:52:57 CEST] <c_14> https://github.com/kewlbear/FFmpeg-iOS-build-script/blob/master/build-ffmpe… line 16 [23:53:03 CEST] <c_14> remove the --disable-programs switch [23:54:16 CEST] <xxDCDxx> trying that now! c_14, you're a lifesaver, thank you very much! [00:00:00 CEST] --- Wed May 4 2016

1 0

ffmpeg-devel.log.20160502
by burek 03 May '16

03 May '16

[00:13:41 CEST] <jamrial_> nevcairiel: ok to push the first two patches from the dts express set? [00:13:54 CEST] <jamrial_> they mostly move tables around [00:14:13 CEST] <jamrial_> foo86 should have created the first patch with the -B (detect rewrites) option to make it more readable [00:34:33 CEST] <nevcairiel> i cant say i looked at them much, but if you think its fine [00:35:23 CEST] <jamrial_> those two should [01:13:18 CEST] <cone-562> ffmpeg 03foo86 07master:2df7d4fa4524: avcodec/dca: move huffman data into separate object file [01:13:19 CEST] <cone-562> ffmpeg 03foo86 07master:1fee770a1cec: avcodec/dca: move channel counter utility into dca.h [04:25:16 CEST] <cone-280> ffmpeg 03Jan Sebechlebsky 07master:0ff3489534ea: avcodec/mjpeg2jpeg_bsf: Check ff_bsf_get_packet success [12:27:03 CEST] <wm4> "mpeg2 with alpha" [12:29:10 CEST] <Compn> wm4 : dont forget "in avi" [13:23:14 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:deaf58abf236: avcodec/mjpegdec: Do not try to detect last scan but apply idct after all scans for progressive jpeg [13:24:41 CEST] <kierank> always nice to see commits without anything on the ml [13:28:09 CEST] <wm4> you have to accept that some devs are above reviews [13:29:24 CEST] <ubitux> i asked michael for that problem [13:29:35 CEST] <ubitux> i can't share the sample unfortunately [13:30:19 CEST] <ubitux> (also, he's the maintainer of that file) [13:45:34 CEST] <durandal_1707> I hate this guy job [13:53:58 CEST] <kierank> durandal_1707: ? [13:54:07 CEST] <kierank> ami_stuff [13:54:08 CEST] <kierank> ? [13:56:11 CEST] <durandal_1707> yes [14:29:30 CEST] <BBB> durandal_1707: I would hate to do his job, but Im happy hes doing it [14:29:40 CEST] <BBB> durandal_1707: I guess thats what you mean? [14:30:29 CEST] <durandal_1707> I hate bugs [14:31:02 CEST] <kierank> durandal_1707: btw I spoke to cfhd author [14:31:35 CEST] <durandal_1707> you are very lucky [14:32:36 CEST] <durandal_1707> I failed to talk with tak and optimfrog authors [14:32:58 CEST] <wm4> (not too surprising) [14:33:29 CEST] <kierank> I spoke IRL [14:37:26 CEST] <durandal_1707> wow [14:37:35 CEST] <kierank> he was a cool guy [14:37:50 CEST] <durandal_1707> was? [14:40:17 CEST] <BBB> haha [14:40:22 CEST] <wm4> durandal_1707: multimedia is a tough business [14:40:34 CEST] <BBB> kierank: arent you the cfhd author? [14:40:41 CEST] <BBB> or you mean the guy that designed the codec? [14:40:45 CEST] <kierank> the guy that made the codec [14:43:25 CEST] <BBB> is this at that las vegas conference last month? [14:43:37 CEST] <BBB> nab, I guess [14:44:27 CEST] <BBB> brb [14:49:55 CEST] <Daemon404> [13:37] <+kierank> he was a cool guy <-- was he at all involved in the 'spec' [14:50:07 CEST] <kierank> yeah he said the spec was a disaster [14:50:11 CEST] <kierank> because of smpte politics [14:50:17 CEST] <kierank> and they've given up on it really [14:50:21 CEST] <Daemon404> lul. [14:50:56 CEST] <nevcairiel> so smpte actively wants those crappy specs for some reason? [14:51:05 CEST] <nevcairiel> i thought its just the companies behind the specs being stupid [14:54:28 CEST] <wm4> what kind of politics lead to a spec disaster? [15:02:23 CEST] <Compn> buzzword warfare [15:22:02 CEST] <ubitux> so BBB posted https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-vp9-encoder-eve-… like nothing happened [15:23:57 CEST] <Shiz> conclusion, vp9 is still slow as shit? [15:23:59 CEST] <ubitux> BBB: you didn't even shared your blog post [15:24:13 CEST] <BBB> what did I just run in to (re: shiz) [15:24:18 CEST] <BBB> ubitux: share where? [15:24:40 CEST] <ubitux> here at least :P [15:24:49 CEST] <BBB> I wondered if it was off-topic for ffmpeg :-p [15:24:51 CEST] <Daemon404> hackew news, reddit [15:24:53 CEST] <Daemon404> probably. [15:24:57 CEST] <Daemon404> ubitux loves karma [15:25:00 CEST] <Daemon404> im sure hell post it [15:25:04 CEST] <BBB> yeah I should probably do that [15:25:04 CEST] <kierank> I look forward to when it gets on streamingmediaeurope [15:25:07 CEST] <kierank> and you get lulz questions [15:25:23 CEST] <ubitux> Daemon404: yeah, just posted on HN [15:25:28 CEST] <Daemon404> ;p [15:25:28 CEST] <BBB> where do I post it on reddit? I never know where to put this kind of stuff& r/linux? [15:25:31 CEST] <BBB> or r/webm? [15:25:35 CEST] <kierank> r/programming [15:25:40 CEST] <BBB> r/vp9 is closed as violating the terms of use (gun-related, I think) [15:25:51 CEST] <ubitux> don't worry, it will be mirrored from HN [15:26:34 CEST] <BBB> ok so I dont need to do anything [15:26:49 CEST] <Shiz> obviously r/x264 [15:26:51 CEST] <mateo`> I think it's relevant here as an encoder using it may land ? [15:26:51 CEST] <Shiz> duh [15:27:15 CEST] <Daemon404> BBB, r/programming like kierank said [15:27:20 CEST] <Shiz> i don't see that happening very soon as long as it's proprietary :p [15:27:23 CEST] <mateo`> by encoder i mean an ffmpeg one [15:27:25 CEST] <BBB> Shiz: so, as for speed, typically if I can gain 5-10% and be faster than libvpx, its not hard to simply copy relevant speed settings for higher speed modes (cpu-used) and get the same speed gains [15:27:43 CEST] <BBB> Shiz: but obviously Im trying to do better than that, so I havent published anything on that subject yet for a reason [15:28:35 CEST] <ubitux> http://www.twoorioles.com/eve-vp9-video-encoder :( [15:31:00 CEST] <Shiz> BBB: well, good luck ;p [15:39:21 CEST] <Daemon404> i wonder how long until the big G attempts to buy out [15:39:46 CEST] <Daemon404> (asusming they even care about encoeer qualiy [15:40:28 CEST] <rcombs> "15-20% better than x264" with VP_9_ [15:43:06 CEST] <wm4> BBB: so uh when will you post a patch for a lavc wrapper [15:43:16 CEST] <BBB> is that useful? [15:43:24 CEST] <Daemon404> i cant imagine it will be accepted [15:44:03 CEST] <BBB> rcombs: 15-20% at 360p, thats not bad (given that vp9/hevc are primarily focussed on 1080p/4k) [15:47:56 CEST] <wm4> well somehow I expected that to become open source, but maybe I'm completely wrong there [15:48:20 CEST] <JEEB> if you can actually pay people's salary with it ;) [15:50:45 CEST] <BBB> ubitux: I fixed the website up with a few sentences on stuff.. Ill add images later, but ... [15:50:50 CEST] <BBB> Id rather code :-p [15:50:53 CEST] <Daemon404> wm4, something that is only useful if you have a commercial sdk is probably not useful to the general punlic [15:50:56 CEST] <Daemon404> public even [15:53:21 CEST] <BBB> wm4: so & yeah, about opensource & I need to figure out ways to make opensource work with paying the rent, and most attempts at that have not been very succesful if theyre purely single software piece based [15:53:29 CEST] <BBB> wm4: so Im not directly intending to opensource it [15:57:42 CEST] <BBB> so I would really like to get comments on the visual comparisons, do you guys think theyre helpful/fair/useful/...? [15:58:08 CEST] <BBB> on-screen visual comparison is easy, but write-down visual comparisons are notoriously hard IMO [15:58:22 CEST] <Daemon404> is it possible to publish webms/mp4s [15:58:38 CEST] <Daemon404> short ones obv [15:59:26 CEST] <Daemon404> [14:34] < maseck> No multithreaded results. I'm guessing that he isn't targeting that. [15:59:29 CEST] <Daemon404> ^ btw from #daala [16:02:20 CEST] <BBB> MT is planned but not yet done, right [16:03:14 CEST] <Daemon404> maybe make a small note [16:30:34 CEST] <kierank> there were a few live vp9 encoders at nab [16:30:35 CEST] <kierank> was quite surprising [16:30:41 CEST] <Daemon404> hw? [16:30:42 CEST] <Daemon404> or sw? [16:30:56 CEST] <Daemon404> and did nay use libvpx [16:32:25 CEST] <kierank> sw i think [16:32:31 CEST] <kierank> dunno [16:39:33 CEST] <BBB> crap I should have gone to nab I guess [16:39:47 CEST] <BBB> kierank: is there a calender of video-related conferences where I should go to? [16:39:49 CEST] <Daemon404> isnt having a booth at nab expensive [16:39:55 CEST] <Daemon404> BBB, IBC is the next biggest [16:40:24 CEST] <BBB> thats around vdd right? [16:40:31 CEST] <Daemon404> right after [16:40:35 CEST] <Daemon404> or rather a week after [16:40:39 CEST] <Daemon404> i think [16:41:35 CEST] <BBB> I can visit my family/friends in NL that week, maybe [16:54:05 CEST] <Daemon404> makes sense [16:54:06 CEST] <Daemon404> ibc is .nl [17:07:26 CEST] <andrey_utkin> Hi! I find it unfortunate that there's "aspect" option for SAR in libavcodec/options_table.h, but ffmpeg_opt.c squats its name with its "aspect" option which stands for DAR. Any comments please, which solution to this would be welcome? Or is there a way to let ffmpeg CLI util know that it shouldn't parse the option, but pass it to libavcodec? I have tried "-aspect", "-aspect:v", it definitely is percepted as ffmpeg_opt.c option which sets DAR. [17:43:40 CEST] <Angus> Good morning folks [17:43:55 CEST] <Angus> Is anyone here familar with H264 byte stream? [17:44:19 CEST] <Angus> I'm running into [h264 @ 0xf9c1a0] decoding for stream 0 failed [17:44:39 CEST] <Angus> where the left is the original file, and the right is the contents being copied into AVIO Buffer: http://i.imgur.com/cZ7pYtE.png [17:45:19 CEST] <Angus> might anyone recognize what the missing bytes are? and if they are relevant to H264 decode? [17:45:57 CEST] <Angus> for reference, once the decoding for frame 1 fails, the rest of the video does play, although running into this error every frame: [NULL @ 0xf9d460] non-existing PPS 0 referenced [17:47:38 CEST] <BtbN> did you try to increase the log level? Also, not a question for this channel. [17:54:55 CEST] <Angus> BtbN: I'm writing the code to call on the FFMpeg API, the cli app isn't being used here. [17:55:07 CEST] <BtbN> still not the right channel. [17:55:53 CEST] <Angus> Oh, should I be in the regular ffmpeg channel? [18:21:49 CEST] <RiCON> BBB: the second graph in CRF says PSNR but the text implies it should be SSIM(?) [18:22:22 CEST] <BBB> yup [18:22:24 CEST] <BBB> let me fix [18:25:01 CEST] <BBB> RiCON: fixed [18:52:20 CEST] <Shiz> I'm trying to write a parser that sets some things like block_size and sample_rate, but it seems the decoder inits before that and bails out because these things... aren't set [18:52:36 CEST] <Shiz> am I doing something architecturally wrong here? the issue is that metadata like that is encoded in the individual frames [18:52:55 CEST] <Shiz> and I don't feel comfortable stuffing that stuff in the mpeg.c demux code [19:07:13 CEST] <JEEB> Shiz: I'm pretty sure the single review for that ATRAC3+ parser back in '14 was that one shouldn't set values in avcodeccontext in the parser, but rather just pass on decode'able packets to the decoder [19:09:55 CEST] <Shiz> well that's a bit of an issue considering the decoder needs these fields filled in [19:09:58 CEST] <Shiz> or it will bail [19:10:16 CEST] <JEEB> so the demuxer was setting them before? [19:10:40 CEST] <Shiz> well, nothing is setting them right now :p but yeah, in OAM stuff the demuxer sets it [19:11:03 CEST] <Shiz> oma* [19:11:17 CEST] <Shiz> see lavf/omadec.c [19:12:56 CEST] <Shiz> specifically around 'case OMA_CODECID_ATRAC3P:' [19:13:13 CEST] <JEEB> I remember poking around ATRAC3+ some time ago [19:14:41 CEST] <JEEB> I think the biggest issue is that it expects avtx->channels to be set [19:14:44 CEST] <JEEB> *avctx [19:14:56 CEST] <Shiz> it expects more to be set [19:14:58 CEST] <Shiz> but yes [19:15:12 CEST] <Shiz> OTOH, setting those valuesi n the mpeg demuxer doesn't seem like a great idea either [19:15:15 CEST] <JEEB> and yes, that's an architectural FU [19:15:46 CEST] <JEEB> Shiz: well I just looked at the init [19:16:43 CEST] <JEEB> and it only seems to require channel count to get through [19:16:49 CEST] <JEEB> init() [19:17:38 CEST] <Shiz> if (!avctx->block_align) { [19:17:40 CEST] <Shiz> also block_align [19:43:45 CEST] <kurosu> So I can confirm that the number of threads spawned considerably slows the dirac decoder on Win64 (with 32x16 slices, that's 4050 threads per image...) [19:44:01 CEST] <kurosu> running per line of slice is a 25% speed improvement for 6 cores/threads [19:47:20 CEST] <Daemon404> it is unfortunate that someone already replied to say "all of libav's code is faster anyway" [19:48:13 CEST] <kurosu> err, I didn't read or understand that from anywhere? [19:48:34 CEST] <kurosu> the decrease I was seeing was just a byproduct of that bad threading [19:48:45 CEST] <kurosu> not because of the new implementation [19:49:09 CEST] <kurosu> *new bitstream implementation [19:49:22 CEST] <Daemon404> https://lists.libav.org/pipermail/libav-devel/2016-May/076493.html [19:49:24 CEST] <Daemon404> i may have misread [19:49:33 CEST] <Daemon404> kurosu, OH, ok [19:50:17 CEST] <kurosu> well, I don't know if the golomb code becomes slower [19:50:25 CEST] <kurosu> on the fixed dirac decoder, it seems faster [19:50:31 CEST] <Daemon404> ic [19:50:42 CEST] <kurosu> so I assume Luca is right, although I haven't tested every and each codec that was ported [19:51:08 CEST] <kurosu> the easy, high bitrate ones probably are improved (confirmed with prores, dnxhd and huffyuv) [19:56:20 CEST] <kierank> kurosu: we have that in our vc2hq tree, yes [19:56:40 CEST] <kierank> it became a nightmare supporting all those ancient variants [20:02:07 CEST] <durandal_170> so they gonna port all 1000 decoders [20:04:59 CEST] <kurosu> kierank, is there only one dirac file in fate? Because I assume it doesn't cover the hq & "normal" low delay variants ? [20:05:13 CEST] <kurosu> and it would be nice having a better coverage in fate [20:05:19 CEST] <kierank> yes, we should probably add more [20:08:27 CEST] <kurosu> kierank, how can one trigger one or another profile ? [20:08:41 CEST] <kierank> use the encoder for hq [20:08:43 CEST] <kierank> the others no idea [20:10:13 CEST] <kierank> we got a bit fed up with the other variants [21:49:04 CEST] <kurosu> kierank / atomnuker, are there restrictions on dimensions with vc2? encoding 640x320 or 352x288 to drc produces content with a few random bytes [21:49:21 CEST] <kurosu> it does decode to the same content though [21:49:29 CEST] <kierank> broadcast resolutions most likely [21:49:43 CEST] <Daemon404> 'random'? [21:49:52 CEST] <kurosu> 480x270, 960x540, 1920x1080 are fine [21:50:03 CEST] <kurosu> Daemon404, different every run [21:50:11 CEST] <kurosu> ie, not good for fate [21:50:14 CEST] <kierank> dunno, non broadcast resolutions was atomnuker's bugbear [21:50:33 CEST] <kierank> and so I am not getting involved in that [21:51:38 CEST] <kurosu> I won't either then [21:51:56 CEST] <cone-273> ffmpeg 03Christophe Gisquet 07master:79e86640ff55: fate: wma: add lossless 24bits tests [21:52:20 CEST] <Daemon404> does this mean 24bit wma lossless works now? [21:52:35 CEST] <Daemon404> i have checks at work to make sure ffmpeg never decoded it (because it was insanely wrong before) [21:53:19 CEST] <kurosu> I suppose, those are files that had problems before and pinpointed various bugs [21:53:33 CEST] <Daemon404> oic [21:53:46 CEST] <Daemon404> it used to e.g. decode to almost-silence sometimes [21:53:48 CEST] <atomnuker> kurosu: I'm not seeing anything wrong at those resolutions with any pixel format [21:53:48 CEST] <Daemon404> users really hate that [21:53:50 CEST] <Daemon404> better to fail [21:56:43 CEST] <kurosu> atomnuker, ran along ffmpeg -f rawvideo -s 640x320 -pix_fmt yuv420p -threads 1 -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact -i vsynth1.yuv -threads 1 -pix_fmt yuv420p -vcodec vc2 -frames 5 -strict -1 -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact -y vsynth1-vc2-420p.drc && md5sum vsynth1-vc2-420p.drc && ffmpeg -i vsynth1-vc2-420p.drc -f crc - 2>&1 | grep CRC [21:57:01 CEST] <kurosu> (actually, edited line generated by fate, but you should see the idea) [21:59:39 CEST] <atomnuker> kurosu: the CRC doesn't change between runs [21:59:44 CEST] <kurosu> no [21:59:53 CEST] <atomnuker> at least on my machine [21:59:55 CEST] <kurosu> but the md5 sum of the input file does [22:00:15 CEST] <atomnuker> vsynth1-vc2-420p.drc? [22:00:33 CEST] <atomnuker> that doesn't vary either [22:01:24 CEST] <kurosu> ah [22:01:31 CEST] <kurosu> atomnuker, work in progress: https://0x0.st/NHt.patch [22:01:50 CEST] <kurosu> varies every run here with these resolutions [22:02:12 CEST] <kurosu> I don't have a memory poisoner/valgrind at hand, so can't say if it's by luck or anything [22:02:48 CEST] <kurosu> when it was failing for mov, I decided to go raw with drc but no change [22:07:11 CEST] <atomnuker> kurosu: what's the fate test name? [22:07:39 CEST] <atomnuker> ah nvm [22:07:57 CEST] <kurosu> $( make fate-list | grep vc2 ) :D [22:08:38 CEST] <kurosu> I can force the resolution but well, that's fragile [22:14:26 CEST] <atomnuker> kurosu: no reference file [22:14:58 CEST] <kurosu> run fate with GEN=1 [22:15:44 CEST] <kurosu> or I'm misunderstanding your sentence [22:19:24 CEST] <kurosu> it may fail with vsynth3 or vsynth_lena but that's not the matter atm [22:20:59 CEST] <atomnuker> nope, none of the pixel formats fail here, no matter how many times I rerun them [22:21:06 CEST] <atomnuker> valgrind doesn't say anything as well [22:21:23 CEST] <atomnuker> I'll try it again with gcc [22:21:34 CEST] <kurosu> oh, that wasn't with gcc [22:21:45 CEST] <kurosu> I'm using 5.1 and Win64 [22:21:59 CEST] <atomnuker> gcc 5.1? [22:22:16 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07master:11db7eee9b00: avformat/options_table: Add missing identifier for very strict compliance [22:22:17 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07master:9fcb59c9bc5c: avcodec/options_table: fix strict compliance constant flags to match the strict field [22:23:05 CEST] <durandal_170> Daemon404: yes, 24bit support should be working, previous hack was just evil and lazy [22:23:46 CEST] <kurosu> yeah, I don't want to bother with various people toolchains, and the one I get allows me to build Win32 binaries by just passing -m32 when needed [22:24:09 CEST] <kurosu> (using msys2, but not their toolchain) [22:24:25 CEST] <kurosu> anyway, I'll just force the resolution [22:26:07 CEST] <kurosu> https://0x0.st/NH6.patch <- should run work, but only tests 1080p [22:26:52 CEST] <kurosu> *fate should work [22:26:55 CEST] <atomnuker> nope, everything still passes with gcc 6.1 [22:27:13 CEST] <atomnuker> if you could somehow get me a valgrind log that'd be nice [22:27:31 CEST] <atomnuker> I don't have a windows system at hand to test with [22:27:36 CEST] <kurosu> I can't, Win64, and then it would be another computer then [22:27:43 CEST] <kurosu> but I'll try to see if I can reproduce [22:28:01 CEST] <kurosu> not for tonight though [22:29:18 CEST] <atomnuker> alright, thanks [22:30:14 CEST] <kurosu> what's the plans for submitting the improved dirac (lowdelay) decoder ? [22:30:20 CEST] <kurosu> *what are [22:30:41 CEST] <kurosu> atm it's not very nice that threading causes that kind of issues [22:34:17 CEST] <atomnuker> it's not yet significantly improved other than it's stable-er, decodes in rows and does the idwt in parallel [22:35:13 CEST] <atomnuker> also it supports decoding field-coded pictures (which definitely didn't use to play nice at all with the rest of the decoder) [22:36:17 CEST] <kierank> I'd like to merge it I guess as a vc2hq decoder [22:36:20 CEST] <atomnuker> the problem is that vc2 and dirac are basically the same codec and you can't really differentiate between them [22:36:25 CEST] <atomnuker> so you'd have to call the decoder from the current dirac decoder [22:36:26 CEST] <kierank> but it's a pain in the arse to say the least [22:36:39 CEST] <atomnuker> which isn't a pretty thing IMO [22:43:36 CEST] <kurosu> well the decoding in rows is a 25% speedup here [22:43:42 CEST] <kierank> yes [22:44:04 CEST] <kurosu> you can probably create a new decoder that calls the same functions, only switching on the codec name [22:44:12 CEST] <kierank> nontrivial to implement for non inra though [22:44:18 CEST] <kurosu> vc2 is intra only ie could use frame threading [22:44:56 CEST] <kierank> yes but perverse to use frame threading for a low delay codec [22:45:18 CEST] <kurosu> yes, once you have implemented (efficiently) slice threading [22:47:32 CEST] <kierank> probably easy to backport yet [22:47:38 CEST] <kierank> s [23:41:18 CEST] <kierank> lol "Resubmitting test file, commands and console as per Carlos' request." [23:59:52 CEST] <cone-273> ffmpeg 03foo86 07master:ce2f9fdb0a92: avcodec/dca: fix sync word search error condition [00:00:00 CEST] --- Tue May 3 2016

1 0

ffmpeg.log.20160502
by burek 03 May '16

03 May '16

[01:55:01 CEST] <Guest62857> word [02:02:23 CEST] <datam0sh> im on ffmpeg 3.0 I'm trying to find a setting to encode a mp4 video that will work on windows and mac/ios with a HTML5 emebd [02:03:55 CEST] <andrew_46> I have a problem accessing ffmpeg from git today: fatal: read error: Connection reset by peer [02:04:15 CEST] <furq> datam0sh: what settings do you have which aren't working [02:04:35 CEST] <andrew_46> Using [02:04:37 CEST] <andrew_46> git://source.ffmpeg.org/ffmpeg.git [02:04:47 CEST] <andrew_46> Just me? [02:05:25 CEST] <furq> not working here either [02:05:50 CEST] <datam0sh> furq should i post the ffmpeg string here? [02:05:55 CEST] <furq> pastebin it [02:06:02 CEST] <furq> and the output as well if possible [02:06:24 CEST] <datam0sh> http://pastebin.com/EQaKXkQ8 [02:06:44 CEST] <furq> add -pix_fmt yuv420p [02:07:06 CEST] <datam0sh> it encodes successfully just fine , but this string only works on Windows/Android - if i swap -vcodec libx264 for mpeg4 - then it works on ios/mac but not windows [02:07:11 CEST] <furq> ^ [02:08:38 CEST] <datam0sh> k trying it now [02:13:44 CEST] <furq> you wouldn't normally need that but you're converting from rgb24 so i assume it's defaulting to yuv444p [02:13:54 CEST] <furq> which won't play in browsers (except maybe chrome) [02:14:55 CEST] <andrew_46> furq: Thanks for confirming [02:15:14 CEST] <furq> andrew_46: i normally just use the snapshot anyway [02:16:46 CEST] <datam0sh> it did play in chrome well - encoding it now with -pix_fmt yuv420p [02:17:33 CEST] <furq> also don't use mpeg4, it's 2016 [02:19:51 CEST] <c_14> But what about the good old xvid days [02:20:14 CEST] <furq> ;_; [02:20:30 CEST] <furq> why can't we just go back to selectavision [02:21:45 CEST] <datam0sh2> thanks furq - it worked! im in heaven [02:21:57 CEST] <furq> i have that effect on people [02:24:19 CEST] <datam0sh2> made me a believer [03:21:41 CEST] <klaxa> the "correct" way to do html5 video is to use webm (with vp9/opus or vp8/vorbis) [03:21:53 CEST] <klaxa> the correctest way to do html5 video is to not do html5 video [03:22:21 CEST] <furq> is that really more correct than mp4 [03:23:18 CEST] <klaxa> i tried to make a html5 video viewer yesterday but it only supports those (on linux with firefox and chromium) [03:42:44 CEST] <Prelude2004c> hey guys [03:42:59 CEST] <Prelude2004c> anyone know what this means.. i am getting my screen scrolling with this " new max_dts_to_pts:7106600 " [03:43:05 CEST] <Prelude2004c> its a satelite source. [04:34:07 CEST] <grublet> furq: lets go back to mechanical televisions and celluloid [04:35:03 CEST] <grublet> but yeah when in doubt -pix_fmt yuv420p ends up being something i throw on the command line out of habit [04:35:30 CEST] <grublet> shame higher bit depth got uptook faster than beter chroma [04:36:06 CEST] <furq> chrome supports 4:4:4 now [04:36:15 CEST] <furq> hopefully firefox will follow suit [04:36:33 CEST] <furq> then that's all the browsers which aren't massive deliberate bastards covered [05:39:41 CEST] <grublet> im still on palemoon 25.6 [10:52:01 CEST] <Fyr> guys, is XAVC a format invented only for Samsung cameras and it has nothing to with PC? [10:52:29 CEST] <Fyr> or XAVS is used when encoding/decoding video and it's somekind of a codec/container? [10:53:04 CEST] <Fyr> pdeiwikia says nothing. [10:58:21 CEST] <relaxed> from wikipedia it looks like the name of their h264 encoder [11:01:31 CEST] <relaxed> well, more of a format like AVCHD [11:01:42 CEST] <Fyr> >>XAVC is a recording format that was introduced by Sony on October 30, 2012. XAVC is a format that will be licensed to companies that want to make XAVC products [11:01:53 CEST] <Fyr> so, it's their H264 encoder? [11:02:07 CEST] <relaxed> but I would guess ffmpeg can decode it [14:04:49 CEST] <Carlrobertoh> Hi ! I'm tring to code a screen casting program in ffmpeg using c++. The raw h264 byte stream can be played by VLC, but if i'm trying to save the file as .mp4 then it wont be played. Any suggestions ? [14:05:13 CEST] <Carlrobertoh> "trying to encode the file as .mp4" [14:05:28 CEST] <Fyr> and not remux? [14:05:44 CEST] <Fyr> encoding is used for codecs, muxing is used for containers. [14:06:43 CEST] <Carlrobertoh> const char* filename = "test.h264"; output_format_ctx->oformat = av_guess_format( NULL, filename, NULL ); [14:06:45 CEST] <Carlrobertoh> works fine [14:06:57 CEST] <Carlrobertoh> but if i change filename to "test.mp4" [14:06:59 CEST] <Carlrobertoh> then it wont work [14:07:29 CEST] <Carlrobertoh> i've found something about annex b [14:07:57 CEST] <Carlrobertoh> that i need to change some NALU header [14:59:12 CEST] <_prcreeper_> Hello [14:59:40 CEST] <_prcreeper_> I don`t understood - how to stream via RTSP using ffserver [14:59:43 CEST] <_prcreeper_> I don`t understood - how to stream via RTSP using ffserver? [15:01:21 CEST] <_prcreeper_> In FAQ and man this is very unclear [15:07:43 CEST] <_prcreeper_> Any body there? [15:47:16 CEST] <Prelude2004c> hello [15:47:29 CEST] <Prelude2004c> anyone know what this means.. i am getting my screen scrolling with this " new max_dts_to_pts:7106600 " how do i get rid of the max_dts_pts errors ? [15:57:35 CEST] Action: penguin42 is trying to convert an rtsp stream (that seems to be h264) from a cctv cam to something a web browser will play but trying not to use too much CPU - currently I'm going to .mp4 and using -f segment to spit out few minute long chunks; my only problem is that it wont play the video until the end fo the segment [15:57:45 CEST] <penguin42> I was looking for some help as to if -movflags can fix that [15:58:20 CEST] <c_14> I'm pretty sure most web browsers won't play fragmented mov, so probably nothing you can do there (besides making the segments shorter...) [15:58:29 CEST] <penguin42> ah [15:58:32 CEST] <c_14> you can try -movflags +frament [15:58:38 CEST] <c_14> *fragment [15:59:01 CEST] <c_14> eh [15:59:16 CEST] <c_14> -movflags frag_keyfram or -movflags frag_size or something [16:00:15 CEST] <penguin42> yeh I'd played with that but without success [16:00:31 CEST] <penguin42> any other alternatives to mp4 that would be better, or is that the best? [16:01:10 CEST] <c_14> Well, if you want a web browser to play it your only choice is mp4 or webm and if you chose webm you'll have to reencode to vp9 or vp8 which takes a decent amount of cpu [16:01:14 CEST] <c_14> and is rather slow [16:01:22 CEST] <penguin42> yeh, that was my previous attempt [16:02:16 CEST] <penguin42> hth designed mp4 without allowing it for streaming.... [16:04:48 CEST] <roxlu> Hey! Can I use ffmpeg as a tool to accept live rtmp data and stream it to a client? (or maybe one of it's utils) [16:06:24 CEST] <penguin42> c_14: Thanks [16:06:54 CEST] <_prcreeper_> Hello [16:06:59 CEST] <_prcreeper_> I don`t understood - how to stream via RTSP using ffserver? [16:07:09 CEST] <_prcreeper_> In FAQ and man this question is very unclear [16:07:26 CEST] <JEEB> ffserver is black magic known by few [16:07:36 CEST] <JEEB> and unless someone steps up to maintain ffserver, it will get removed [16:07:49 CEST] <JEEB> look into other streaming servers if you actually require such [16:08:12 CEST] <_prcreeper_> What? [16:08:54 CEST] <roxlu> JEEB: yeah, I wanted to quickly test a rtmp stream I create; would be nice to have a simple server that doesn't need lots of setup. [16:10:21 CEST] <navlelo_> _prcreeper_: look at the dummy config file for ffserver [16:10:41 CEST] <Prelude2004c> C_14 .. > any idea on i am getting my screen scrolling with this " new max_dts_to_pts:7106600 " how do i get rid of the max_dts_pts errors ? ... not sure what to do [16:11:02 CEST] <navlelo_> _prcreeper_: it shows how to connect and what to set up... it is a little bit of configuration that is needed to make stuff work [16:17:16 CEST] <Prelude2004c> or anyone else? [16:20:28 CEST] <c_14> Prelude2004c: I can't even find that string anywhere in the source (or any subpart thereof) [16:20:44 CEST] <_prcreeper_> Ok, i tries to set the rtsp port in ffsever`s config file, but how to prevent ffmpeg to use the rtsp? [16:21:43 CEST] <navlelo_> _prcreeper_: what do you mean by that? [16:22:28 CEST] <_prcreeper_> How to stream to an rtsp feed via ffmpeg [16:22:43 CEST] <_prcreeper_> Sorry for my English [16:22:54 CEST] <Prelude2004c> really? [16:23:24 CEST] <Prelude2004c> that is odd... i am def. getting that error.. just not sure hwo to deal with it [16:24:42 CEST] <c_14> Can you pastebin the complete output? [16:25:25 CEST] <navlelo_> _prcreeper_: the ffserver docs + the dummy config will explain how it works. Basically ffmpeg does the streaming and outputs the stream into ffserver which serves the stream on a configured port [16:25:35 CEST] <_prcreeper_> Output of what? [16:25:56 CEST] <navlelo_> the stream itself [16:27:06 CEST] <_prcreeper_> Of ffmpeg or ffserver? [16:29:01 CEST] <navlelo_> you call ffmpeg like so: ./ffmpeg -i rtsp://cameraip/stream.sdp http://ffserverip:port/feed1.ffm [16:29:15 CEST] Action: penguin42 wonders how short a segment size on the segment mux makes sense [16:29:35 CEST] <_prcreeper_> ffmpeg -i /dev/video0 rtsp://localhost:5039/feed.ffm [16:30:07 CEST] <navlelo_> that seems reasonable [16:30:43 CEST] <navlelo_> im off now... good luck :) [16:32:05 CEST] <_prcreeper_> Pastebined output here http://pastebin.com/RT3JXQ0y [16:34:02 CEST] <_prcreeper_> rtsp://localhost:5039/feed.ffm: Protocol not found [16:45:38 CEST] <_prcreeper_> And how to stream screen via ffmpeg? [16:59:52 CEST] <Prelude2004c> c_14 sure sorry for the delay [17:01:08 CEST] <_prcreeper_> Who is now how to capture and stream screen via ffmpeg? [17:18:42 CEST] <andrey_utkin> is there an option to drop SAR/DAR info from input file? i have some mp4 files with it, and some without. Of course setting same SAR everywhere is ok, but i wonder can i go discarding SAR info. [17:20:48 CEST] <kepstin> andrey_utkin: if you're re-encoding the video, you can use the 'setsar' video filter to change it to whatever you want [17:21:11 CEST] <kepstin> you can't really "discard it", but setting it to 1:1 (square pixels) is what you probably want to do? [17:21:20 CEST] <andrey_utkin> kepstin, yes i know [17:24:36 CEST] <kepstin> if you want to modify an mp4 file without re-encoding, maybe one of the MP4Box tools can do it? [17:25:38 CEST] <andrey_utkin> kepstin, what i am talking about as "discarding" it, is that file (h264-in-mp4) MAY carry explicit SAR info which is shown e.g. in ffprobe at elementary stream info [17:26:04 CEST] <andrey_utkin> no, i'm actually reencoding [17:26:42 CEST] <kepstin> I suspect that ffmpeg always explicitly sets the sar/par metadata fields when encoding. [17:26:58 CEST] <kepstin> I checked the MP4Box docs, it does have support for changing or removing that [17:32:59 CEST] <andrey_utkin> kepstin, in fact no, unless explicitly asked, ffmpeg does not populate sar, at last in case of mp4 container [17:33:39 CEST] <andrey_utkin> or unless this info is set in input file which is undergoing transcoding [17:39:54 CEST] <tokam> I would like to create a video by a photo and a mp3 file. [17:40:09 CEST] <tokam> which command must I use to have the photo displayed as part of the video for the whole length? [17:40:35 CEST] <Prelude2004c> hey guys.. i found more info " cur_dts is invalid " .. that is what i am getting on start [17:40:40 CEST] <tokam> is it -vframes 1? [17:41:32 CEST] <furq> tokam: -loop 1 -i in.png -i in.mp3 -shortest out.mkv [17:42:21 CEST] <tokam> what does -threads auto do [17:42:26 CEST] <tokam> and -vframes 1 [17:43:03 CEST] <furq> -vframes 1 writes one frame to the output file [17:43:15 CEST] <tokam> -shortest? [17:43:27 CEST] <furq> that command will loop forever unless you pass -shortest [17:43:32 CEST] <tokam> ok thanks [17:43:33 CEST] <furq> in that instance it'll stop processing when the mp3 ends [17:44:08 CEST] <tokam> is avi or mpeg a better format? [17:44:13 CEST] <tokam> I like to upload it on facebook. [17:44:18 CEST] <furq> use mp4 [17:44:30 CEST] <tokam> what is -loop 1 than? I assumed that this is the looping, but you said it is shortest? [17:44:46 CEST] <tokam> [aac @ 0x20ee0c0] The encoder 'aac' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it. [17:44:49 CEST] <furq> -loop loops the next input stream forever [17:44:49 CEST] <tokam> that's what I get for mp4 [17:45:05 CEST] <furq> if you didn't pass -shortest then that command would run forever because one of your inputs is looping forever [17:45:11 CEST] <Mista_D> Any idea on EAC3 decoding please? http://pastebin.ca/3588795 [17:45:15 CEST] <furq> and yeah just add -strict -2 [17:45:20 CEST] <furq> or upgrade to a newer ffmpeg [17:45:35 CEST] <tokam> ok thanks [17:45:45 CEST] <tokam> mp4 seems to encode quicker than avi [17:46:13 CEST] <tokam> but it takes a while also. maybe it is stupid to use an 1,2 MB high resolution image [17:46:42 CEST] <tokam> the file size is only 600kb yet but it only compiled it up to 5 seconds in that entire time [17:47:44 CEST] <tokam> only 9 seconds done yet, is there a way to speed that up? [17:50:52 CEST] <tokam> furq: thanks [18:50:25 CEST] <thebombzen> w00t the bug report I submitted got fixed :D [18:50:58 CEST] <thebombzen> makes you love ffmpeg devs. submit crash bug report, fixed two days later. pretty good [18:56:47 CEST] <thebombzen> hey, I'm trying to figure out how to use -vf scale to force yuv420p. it appears I have to use flags=dst_format=yuv420p but I don't know the integer id for yuv420p. does anyone know (and/or have a better way of doing this)? [18:57:33 CEST] <vade> do all packets that go to a muxer have to have increasing dts timestamps, or only packets destined to go to a particular STREAM associated with a muxer need monotonically increases DTS relative to that stream? [18:57:34 CEST] <vade> I ask because im having an issue where the first frame of video out to an MP4 encoded in h.264 is complaiing that its DTS is less than the LAST audio samples I wrote to the output audio stream [18:57:36 CEST] <pfelt> -pix_fmt ? [18:57:43 CEST] <pfelt> thebombzen: ^ [18:57:44 CEST] <vade> and I am using av_interleaved_write_frame too :X [19:14:51 CEST] <cybrNaut> ffmpeg -vtag xvid -i input.avi -vf 'scale=720:-1' output.avi <= why does that produce an "FMP4" video, and not an "XVID"? [19:16:11 CEST] <cybrNaut> FaQ says "-vtag xvid" is all that's needed, if I understand correctly [19:19:59 CEST] <vade> gah [19:21:42 CEST] <DHE> cybrNaut: order of parameters matters. put it before the output file, not the input file [19:22:01 CEST] <cybrNaut> DHE: thanks! will try that.. [19:22:07 CEST] <DHE> ffmpeg [input1-opts] -i input1 [...] [output1-opts] output1 [...] [19:23:14 CEST] <cybrNaut> ah [19:24:18 CEST] <cybrNaut> i do think it's bizarre that it doesn't automatically give me the same format as the input file (the input file is already Xvid) [19:25:43 CEST] <cybrNaut> ffprobe says it's correct now [19:26:32 CEST] <DHE> I haven't tried it that way, but does it work right? it says the codec is xvid when playing it back and not just that it's labeled xvid? [19:26:44 CEST] <DHE> I normally use the full "-c:v xvid" process [19:27:43 CEST] <timbucii> Hi, What is the command to change the input of my tv card from antenna to composite? [19:27:44 CEST] <cybrNaut> DHE: how can I do a real test? vlc "media info" also says it's XviD, but presumably that's still just the metadata [19:28:14 CEST] <kepstin> cybrNaut: ffmpeg doesn't make any attempt to use the same codecs as the input file. If unspecified, the output codecs are automatically picked only by looking at the output format. [19:28:28 CEST] <DHE> would that include the vtag option? [19:29:01 CEST] <DHE> cybrNaut: ffprobe will do it, but you need to read the full output [19:29:14 CEST] <DHE> also note that you didn't set a video bitrate etc, so you get defaults. [19:32:50 CEST] <cybrNaut> Stream #0:0: Video: mpeg4 (Simple Profile) (xvid / 0x64697678), yuv420p, 720x405 [SAR 1:1 DAR 16:9], 30 tbr, 30 tbn, 30 tbc <= i suppose that's the relevant part? [19:33:02 CEST] <cybrNaut> the metadata section only says "encoder : Lavf54.29.104" [19:33:39 CEST] <cybrNaut> anyway, the result is blocky. [19:34:06 CEST] <cybrNaut> i shrunk the dimensions to 720x-1 (to preserve aspect ratio) [19:34:26 CEST] <cybrNaut> when I play the shrunk version in its native size, it should not be blocky [19:34:46 CEST] <furq> isn't xvid always advanced simple profile [19:34:53 CEST] <furq> or is that just ffprobe not distinguishing [19:36:06 CEST] <cybrNaut> furq: no idea [19:36:34 CEST] <furq> it's not ffprobe, i just checked [19:36:50 CEST] <furq> it's been too long since i used xvid to remember if it encodes SP [19:37:03 CEST] <furq> but it could be that someone's just written the wrong fourcc to your source [19:37:39 CEST] <cybrNaut> ah, i wonder if that's it.. so the source file might have untrustworthy metadata? [19:37:50 CEST] <furq> maybe [19:38:51 CEST] <cybrNaut> The file came from a school teacher, and her classrooms video play complains that the dimensions of her video file are too big, with a max of 720x548 [19:39:28 CEST] <cybrNaut> so I'm merely trying to shrink it to work w/out doing too much transcoding, and without knowing the model of her player [19:39:50 CEST] <furq> oh never mind [19:42:39 CEST] <cybrNaut> i guess the blockyness won't do much harm.. it's just a short video she wants to show and sharpness probably doesn't matter [19:42:58 CEST] <furq> http://sprunge.us/EWZj [19:43:01 CEST] <furq> looks like i'm wrong anyway [19:43:14 CEST] <cybrNaut> i'd just like to know what went wrong, in case I need to do this again [19:44:32 CEST] <furq> oh hang you're reencoding [19:44:54 CEST] <furq> the input codec doesn't affect the output codec selection, it'll use the default for the container if you don't specify [19:45:02 CEST] <furq> which for avi is the internal mpeg4 encoder [19:45:10 CEST] <furq> you'll need to specify -c:v libxvid [19:45:19 CEST] <cybrNaut> furq: right, that's what kepstin mentioned [19:45:29 CEST] <cybrNaut> ah, ok, will try that then [19:45:29 CEST] <furq> oh so he did [19:46:01 CEST] <cybrNaut> furq: DHE said he uses "-c:v xvid" [19:46:09 CEST] <furq> either should work i think [19:46:15 CEST] <cybrNaut> k [19:46:24 CEST] <furq> but yeah if you were remuxing to the same container then afaik it would keep the same fourcc [19:47:26 CEST] <DHE> cybrNaut: okay, I don't actually use xvid specifically anymore, so I may have gotten the exact codec name wrong [19:47:32 CEST] <kepstin> by "remuxing", you mean -c:v copy? I'd expect it to pick a new fourcc based on the codec if it's reencoding [19:47:43 CEST] <furq> yeah exactly [19:49:07 CEST] <cybrNaut> i'm getting errors with the -c:v option. "[libxvid @ 0xbc2a60] Xvid: Could not create encoder reference" [19:49:21 CEST] <cybrNaut> and "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height" [19:50:04 CEST] <furq> use -vf scale=720:-2 [19:50:19 CEST] <furq> -2 is the same as -1 but it'll ensure the height is mod2 [19:50:31 CEST] <thebombzen> pfelt: I'm trying to do it with -vf scale because of a filtergraph [19:50:44 CEST] <thebombzen> furq: do you know the swscale ID for yuv420p? [19:50:52 CEST] <furq> no idea [19:51:28 CEST] <cybrNaut> furq: "Size values less than -1 are not acceptable." (maybe the debian stable version is too old) [19:51:35 CEST] <furq> oh [19:51:36 CEST] <furq> maybe [19:51:43 CEST] <furq> i think jessie-backports has 2.8.6 [19:51:56 CEST] <furq> regular jessie is still using libav [19:51:57 CEST] <cybrNaut> ffmpeg version 1.0.10 [19:52:01 CEST] <furq> yeah that's libav [19:52:17 CEST] <furq> er, no it isn't [19:52:20 CEST] <furq> it's super old either way [19:52:54 CEST] <furq> ffmpeg from backports should be fine [19:53:17 CEST] <cybrNaut> ok, i'll try upgrading to a backport [19:55:13 CEST] <cybrNaut> i hate to get dirty like this.. this will be the first backport i use in jessie [19:55:49 CEST] <furq> mixing stable and backports is officially sanctioned [19:56:10 CEST] <furq> i'd love to tell you it's never broken anything for me but i only ever run testing [19:59:01 CEST] <vade> Im a big confused about writing audio and video to the same muxer - to be clear of some assumptions: I use the same AVOutputFormat and set the audio and video codec, and init an AVCodec* from that - and make an AVFormatContext from my outputFormat, and then attach new AVStreams* and configure them as appropriate via avformat_new_stream(outputFormatContext, codecForStream). I configure the stream and the streams codec, and the avcodec_open2 them [19:59:02 CEST] <vade> and then avio_open my outputFormatXontext, and finally write the header ? [19:59:41 CEST] <vade> once I do that - I should be able to tell my muxer to send a write a packet - and based on the packet stream index, it goes to the write stream? [19:59:46 CEST] <cybrNaut> aptitude -t jessie-backports upgrade ffmpeg <= is that the command? or should I /remove/ followed by /install/? [20:00:22 CEST] <furq> probably better to purge it first so you don't have any old bullshit lying around [20:05:47 CEST] <cybrNaut> so it removed about 2mb of files, and installing the backports version adds 25mb in files [20:05:59 CEST] <cybrNaut> my have you grown, ffmpeg [20:07:47 CEST] <timbucii> Booya! 2016-03-20 12:10:24 :P [20:07:54 CEST] <cybrNaut> now when I do the conversion, it goes to work instead of failing with errors immediately [20:08:19 CEST] <cybrNaut> but i get lots of warnings "Invalid pixel aspect ratio 406/405, limit is 255/255 reducing" [20:09:58 CEST] <cybrNaut> btw, why is "-vtag xvid" inferior to the "-c:v libxvid" option? [20:10:05 CEST] <cybrNaut> should I use both, perhaps? [20:11:09 CEST] <furq> one is the fourcc, one is the encoder [20:11:16 CEST] <furq> the latter ought to imply the former [20:12:32 CEST] <cybrNaut> it's still blocky. I used: ffmpeg -i input.avi -c:v libxvid -vf 'scale=720:-2' output.avi [20:14:38 CEST] <kepstin> it's probably blocky because you didn't set any quality settings... [20:14:51 CEST] <kepstin> you'll probably want to set a bitrate (and with xvid, maybe even do a 2-pass encode) [20:19:12 CEST] <MrSassyPants> how do I enable scene cut keyframes when using libvpx / vp9 ? [20:24:54 CEST] <cybrNaut> kepstin: thanks.. that made a big difference. I used these options => -c:v libxvid -q:v 10 -vf 'scale=720:-2' [20:25:09 CEST] <cybrNaut> i'll try a 2 pass approach next, using => -c:v libxvid -q:v 10 -vf 'scale=720:-2' -pass 2 [20:25:47 CEST] <cybrNaut> Error reading log file 'ffmpeg2pass-0.log' for pass-2 encoding [20:25:58 CEST] <kepstin> using -q:v with 2-pass mode doesn't make sense [20:26:11 CEST] <kepstin> only use it if you're using bitrate (-b:v) [20:26:25 CEST] <cybrNaut> ah, does the qscale incorporate number of passes? [20:26:37 CEST] <cybrNaut> that's what I get for trying to mix different examples [20:26:44 CEST] <furq> you'd need to run -pass 1 first [20:26:52 CEST] <furq> -pass 2 is second pass, not two passes [20:27:15 CEST] <furq> and yeah it only really makes sense if you're targeting a bitrate [20:27:54 CEST] <vade> ah my bad. the AVPacket filled by the encoder doesnt keep the stream_index populated [20:27:57 CEST] <cybrNaut> well, i'll keep with the simpler approach now, which I think qscale gives [20:28:03 CEST] <vade> it was getting set to zero behind my back [20:28:10 CEST] <furq> are you sure that the target player doesn't support h.264 [20:28:14 CEST] <furq> that'd make your life a bit easier [20:28:42 CEST] <cybrNaut> furq: no idea. I just know it's old enough to be limited to 720x resolution [20:29:26 CEST] <cybrNaut> that has to be old.. i mean, even if the output is limited, the device should be able to scale as needed if the input is big [20:40:29 CEST] <cybrNaut> furq: my phone supports h.264. If I want to transcode a video for my phone, what codec option should I used to get h.264? The ffmpeg default? [20:40:45 CEST] <furq> the default settings for .mp4 are pretty ok [20:41:00 CEST] <cybrNaut> cool [20:42:03 CEST] <cybrNaut> i used the default settings and it came out blocky on my phone, but i probably needed to add a qscale, which I'm trying now [20:42:21 CEST] <furq> don't use -q:v for x264 [20:42:23 CEST] <furq> use -crf [20:42:36 CEST] <furq> the default is 23, lower values are higher quality [20:43:26 CEST] <cybrNaut> ok, will try -crf [20:44:31 CEST] <cybrNaut> -crf -vf 'scale=480:-2' <= those options give => Unable to find a suitable output format for 'scale=480:-2' [20:44:41 CEST] <furq> you forgot the argument after -crf [20:44:49 CEST] <cybrNaut> ah [20:45:04 CEST] <cybrNaut> better [20:50:23 CEST] <MrSassyPants> Question: Does 2-Passing do anything for constant-quality encodes? [20:51:50 CEST] <DHE> with -qp ? no [20:51:52 CEST] <DHE> or -crf [20:52:22 CEST] <MrSassyPants> -crf [20:53:01 CEST] <DHE> yeah, no use [20:53:08 CEST] <DHE> 2-pass is for bitrate based outputs [20:55:51 CEST] <MrSassyPants> ok. How to set scene cut keyframes in libvpx / vp9 ? I can't seem to find the right doc [20:56:43 CEST] <BlackBishop> ffmpeg -i file.mkv -codec:s:0:24 srt file.srt ( trying to extract subtitle #24 ( Stream #0:17(kor): Subtitle: hdmv_pgs_subtitle, 1920x1080)) to a separate file ), anyone can tell me what I'm doing wrong ? [20:59:17 CEST] <BlackBishop> or a way to hardcode it in the stream ? [21:32:05 CEST] <DryEagle> hi, does ffmpeg work with wildcards? if i have a directory of 200 files all .aac and i want to wrap them to .m4a is there an easy way to do that? [21:32:54 CEST] <furq> for f in *.aac; do ffmpeg -i "$f" -c copy "${f%.*}.m4a"; done [21:34:53 CEST] <DryEagle> ok, that worked for some of the files, a lot of them returned this: http://pastebin.com/8qQmBgXK [21:35:46 CEST] <hyponic> i have been trying to burn subtitles on a video following the wiki guide but when doing so the subtitles does not show. ffmpeg -i video.mkv -vf subtitles=video.mkv out.avi [21:36:08 CEST] <hyponic> no errors indicating that it's not getting burned but still nothing on the video. [21:36:25 CEST] <pfelt> hyponic: is the option on the subtitles filter supposed to be the file containing the subtitles? [21:37:06 CEST] <Fyr> >>This filter requires ffmpeg to be compiled with --enable-libass. [21:37:13 CEST] <pfelt> it'll have to be the right format too [21:37:52 CEST] <hyponic> pfelt yes. i even tried ffmpeg -i video.avi -vf subtitles=subtitle.srt out.avi after extracting the .srt from the video. [21:38:35 CEST] Action: pfelt would think that would work provided the library is correctly installed [21:38:56 CEST] <hyponic> ffmpeg is compiled with: --enable-libass [21:39:00 CEST] <vade> Hi all - im using libavformat and libavcodec to re-encode a video to AAC + h.264 mp4 - im having an issue where my video is timed perfectly but audio is WILDLY off - I imagine its my PTS handling - are there any examples of conversion between demuxer -> decoder -> encoder -> muxer correctly for both video and audio packets? [21:39:19 CEST] <hyponic> pfelt should i install anything extra? [21:39:20 CEST] <Prelude2004c> hey guys.. any way to take a bunch of input files.. shuffle them and play them one by one .. without using concat ? i don't want the stream to end and sence i am piping the output to the ffmpeg and segmenting .. the segments always start up at 0 after each file.... i want to have one continuous stream that never ends.. but at the end of the file list i would like it to sort again and keep going.. [21:39:49 CEST] <Prelude2004c> do i have to add 2 processes .. like 1 process output to UDP and the other take from UDP ? or can it somehow be done in the script where it can just stdout or somethign [21:40:16 CEST] Action: pfelt is working up changes to the movie filter that would work if you have an external process to decide what to play when [21:40:40 CEST] <pfelt> i couln't find any way to do something similar without coding it [21:46:26 CEST] <Prelude2004c> pfelt , you talking to me about tht ? [21:47:04 CEST] <pfelt> Prelude2004c: yep [21:47:17 CEST] <pfelt> i've got a weird segfault atm [21:47:45 CEST] <pfelt> but it switches files for me fairly well [21:47:48 CEST] <Prelude2004c> oh ic... ya i was trying to find a way to code it to do that.. i mean.. we can take the list of files.. play them one after the other.. i am sure i twill work if i write it out to udp://locallhost:xxxx but i wanted to keep it all in the same file [21:47:55 CEST] <hyponic> pfelt libass-dev is installed and the ffmpeg is compiled with --enable-libass and still nothing. here is the outout. http://pastebin.com/NUnVZaau [21:48:00 CEST] <Prelude2004c> and it doesn't mess up the segmentation ? [21:48:53 CEST] <pfelt> Prelude2004c: so my use case was to switch between live streams and output to a local decklink sdi card. that all works pretty well. i modified movie to have a command and i use zmq with it to tell it what file to read from [21:49:17 CEST] <Prelude2004c> in realtime ? [21:49:42 CEST] <pfelt> Prelude2004c: yep. i'm reading in ffmpeg output through a named pipe on the filesystem and i can realtime swap between them [21:49:59 CEST] <pfelt> i'm hoping to be able to clean up the code and submit back to main [21:50:10 CEST] <Prelude2004c> ya i think if i run a udp listen on localhost and then just push things to that udp port i could kind of do the same thing no ? [21:50:31 CEST] <Prelude2004c> i was trying to avoid doing that because i have to basically run 2 sperate processes.. and i wanted to do it all with stdin and stdout [21:50:33 CEST] <pfelt> it didn't work for me when i tried that [21:50:46 CEST] <pfelt> pts timestamps get all screwed up [21:51:06 CEST] <pfelt> basically if i let the first stream play for 3 minutes, then i swapped, i had to wait 3 minutes before stuff would start showing up [21:57:29 CEST] <pfelt> i can post the patch if you want it [21:57:49 CEST] <pfelt> (i think my segfault is an av_freep() that i'm doing wrong [22:59:53 CEST] <hyponic> Trying to burn subtitles and get this error: No usable fontconfig configuration file found, using fallback. i am on ubuntu and unable to find out where the fonts.conf should be etc.. [23:06:04 CEST] <c_14> /etc/fonts/fonts.conf [23:06:20 CEST] <c_14> ubuntu should have one though... [23:06:25 CEST] <c_14> Also, that's not an error [23:06:27 CEST] <c_14> It's a warning [23:09:40 CEST] <hyponic> c_14 warning.. but could it be the reason why the subs are not showing on the video? [23:10:02 CEST] <c_14> possible, probable even [23:10:11 CEST] <c_14> What does fc-list output? [23:10:19 CEST] <c_14> does it output anything? [23:10:45 CEST] <hyponic> c_14 The program 'fc-list' is currently not installed. [23:11:42 CEST] <hyponic> apt-get install fontconfig now it's showing some fonts [23:12:58 CEST] <c_14> now try burning subtitles again [23:14:15 CEST] <hyponic> c_14 [Parsed_subtitles_0 @ 0x40b7d60] No usable fontconfig configuration file found, using fallback. Fontconfig error: Cannot load default config file [23:19:33 CEST] <c_14> hyponic: install fontconfig-config [23:20:05 CEST] <hyponic> c_14 fontconfig-config is already the newest version. [23:20:22 CEST] <c_14> Then you should have a fonts.conf [23:20:36 CEST] <c_14> At the very least fontconfig-config is listed as the owner of the fonts.conf on the computer I just checked on [23:22:35 CEST] <hyponic> c_14 i do have the fonts.conf but for some reason ffmpeg can't detect it [23:32:56 CEST] <c_14> How did you get your build of ffmpeg? [23:35:05 CEST] <hyponic> c_14 got it off some guy. static build or something [23:39:39 CEST] Action: c_14 has no idea. It should work [23:39:55 CEST] <hyponic> c_14 where should i get it from in ubuntu? i am unable to compile my own though. [23:40:35 CEST] <c_14> Was it the static build from here http://johnvansickle.com/ffmpeg/ ? [23:41:36 CEST] <hyponic> yes [23:41:50 CEST] <c_14> then it should work [00:00:00 CEST] --- Tue May 3 2016

1 0

ffmpeg-devel.log.20160501
by burek 02 May '16

02 May '16

[00:20:00 CEST] <kurosu> well, I'm not blaming them for this - I just hope Alexandra is more interested by the technical aspect than projects' (mis)management [00:22:04 CEST] <kurosu> In case some people want to see what it does in ffmpeg (dirac [bad] + huffyuv [good]): https://github.com/kurosu/ffmpeg/tree/gb [00:28:36 CEST] <atomnuker> I'm not exactly liking the new bitstream API [00:29:09 CEST] <atomnuker> are there plans to also implement put_bits into it? [00:29:51 CEST] <atomnuker> I'm not sure what they find that doesn't make sense: you have PutBitContext and GetBitContext for whether you want to read or write bits [00:30:01 CEST] <kurosu> the bitstream API is almost identical to get_bits, though the implementation details favor it in some cases [00:30:19 CEST] <atomnuker> BitStreamContext doesn't imply whether you're writing bits or reading bits [00:31:00 CEST] <kurosu> no idea about put_bits, though [00:31:09 CEST] <kurosu> yeah, true [00:31:31 CEST] <atomnuker> it's like they just changed the API to an API that has exactly the same functions but with a different, more ambiguious name [00:31:38 CEST] <kurosu> then again, I'm more interested in the technical effect, not what it does to my programming [00:33:12 CEST] <atomnuker> while the lower-level API (SHOW_BITS, SKIP_BITS, etc) was annoying to use it IIRC does speed up prores and dnxhd [00:34:02 CEST] <atomnuker> so yeah, if the new api is faster without having to use macros directly that's fine [00:34:19 CEST] <kurosu> the new API offers the same level of access but I only benchmarked it on huffyuv [00:34:21 CEST] <atomnuker> but in that case they should have just removed the macros and merged the changed to e.g. get_bits [00:34:31 CEST] <kurosu> agreed [00:34:56 CEST] <kurosu> though in case it didn't always work, it's nice to have the 2 still available [00:35:09 CEST] <kurosu> like it slows dirac decoding [00:35:59 CEST] <atomnuker> are you talking about having 2 bitstream writing APIs in libavcodec? [00:36:27 CEST] <atomnuker> that's the opposite of what anyone would want [00:36:31 CEST] <kurosu> I think I know where you are going with this, but yes [00:36:41 CEST] <kurosu> I'd want it just to not have speed regressions [00:36:54 CEST] <kurosu> the gist on the implementation: don't waste your time reloading the cache when it's seldom needed [00:37:12 CEST] <kurosu> except the extra work doesn't pay out when you actually are likely to need reloading [00:37:22 CEST] <atomnuker> I'm working on writing a LUT-based golomb reader for dirac, so it's likely to get faster [00:37:40 CEST] <atomnuker> it doesn't use any part of get_bits [00:38:01 CEST] <kurosu> get_vlc2-based ? [00:38:42 CEST] <atomnuker> nope [00:39:04 CEST] <kurosu> so a local bitstream reading API then [00:39:25 CEST] <nevcairiel> didnt we have lut based golomb readers already [00:39:38 CEST] <kurosu> for the shorter codewords, yes [00:39:54 CEST] <atomnuker> dirac uses different golomb codes [00:40:58 CEST] <kurosu> still lut-based though, yet dissimilar to get_vlc2 [00:41:44 CEST] <kurosu> I thought there were opportunities there to decode 2+ symbols at a time there [00:42:43 CEST] <atomnuker> well, basically, a single function to roll across each byte, and either directly outputting decoded numbers (if they're small) or reconstructing longer golomb codes (which get decoded by a riced function which needs to know their length) [00:43:10 CEST] <kurosu> riced as in optimized or rice-golomb ? [00:43:20 CEST] <atomnuker> optimized [00:43:33 CEST] <kurosu> ok [00:44:40 CEST] <kurosu> anyway, my interest in dirac was really to try out the new bitstream reading API, and I think it shows to be a case where it's slower [00:45:14 CEST] <atomnuker> which is a good thing, if it helps to convince people we do not need to replace our current reader [00:45:51 CEST] <atomnuker> or at least direct attention to optimize it rather than completely replace it [00:46:24 CEST] <kurosu> well, it's most often faster so it's not black or white [00:46:27 CEST] <nevcairiel> what I dislike the most about the change is the "need" to always replace entire APIs instead of just revising their implementation, its like everyone needs to leave their own mark on the API somewhere =p [00:48:20 CEST] <kurosu> so how is hwaccel3 going ? :p [00:48:38 CEST] <nevcairiel> such a thing exists? [00:48:43 CEST] <nevcairiel> i thought someone was still working on 2 [00:48:46 CEST] <kurosu> no, I was just kidding [01:49:17 CEST] <cone-158> ffmpeg 03Michael Niedermayer 07master:390703fcf5cd: avcodec/mpeg12dec: Do not choke on extra m704 alpha data [01:49:17 CEST] <cone-158> ffmpeg 03Michael Niedermayer 07master:cb84c12fa2b8: avcodec/mpeg12dec: Print position in end mismatch error [01:49:17 CEST] <cone-158> ffmpeg 03Michael Niedermayer 07master:9a499e0ae7dd: avformat/riff: add m704 [02:42:31 CEST] <hyponic> i am trying to transcode a stream and burn subtites from that stream. i just have no idea how to get it done. i have been googling for days without bein able to crack it. here is the stream: http://pastebin.com/JnpPYTx2 [04:54:48 CEST] <jamrial> atomnuker: "./ffmpeg -f lavfi -i 'sine=d=0.1' -c:a aac out.ts && ./ffmpeg -i out.ts" fails to detect the resulting file [04:55:35 CEST] <jamrial> started with ffmpeg 3.0 according to https://ci.debian.net/packages/f/ffmpeg/unstable/amd64/ [04:57:34 CEST] <jamrial> also seems to happens with hls [04:59:38 CEST] <jamrial> guess Andreas really just decided to quit after the whole vlc/threads debacle... [05:14:02 CEST] <cone-349> ffmpeg 03KO Myung-Hun 07release/2.5:3b931399eb32: MAINTAINERS: add myself as an OS/2 maintainer [05:14:02 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:a3db73c44dc7: swscale/x86/output: Move code into yuv2planeX_mainloop [05:14:02 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:39664fb6472a: swscale/x86/output: Fix yuv2planeX_16* with unaligned destination [05:14:02 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:e44775580f6c: avutil/pixdesc: Make get_color_type() aware of CIE XYZ formats [05:14:02 CEST] <cone-349> ffmpeg 03Carl Eugen Hoyos 07release/2.5:d8586b7aca36: postproc: fix unaligned access [05:14:03 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:8c40fc62ceb0: swscale/input: Fix GBRAP16 input [05:14:03 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:0b51d15a0e57: swscale/utils: Fix chrSrcHSubSample for GBRAP16 [05:14:04 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:0438cc2bc0ee: avcodec/avpacket: clear priv in av_init_packet() [05:14:05 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:4c6870695859: avcodec/mjpegdec: Fix decoding slightly odd progressive jpeg [05:14:05 CEST] <cone-349> ffmpeg 03Rodger Combs 07release/2.5:b42ade51eb5b: lavf/mov: fix sidx with edit lists (cherry picked from commit 3617e69d50dd9dd07b5011dfb9477a9d1a630354) [05:14:06 CEST] <cone-349> ffmpeg 03Boris Nagels 07release/2.5:1578642853d3: avformat/rtpenc: Fix integer overflow in NTP_TO_RTP_FORMAT [05:14:08 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:59648ab954ca: avformat/concatdec: set safe mode to enabled instead of auto [05:14:09 CEST] <cone-349> ffmpeg 03Martin Cracauer 07release/2.5:3433e52d48ac: avutil/channel_layout: AV_CH_LAYOUT_6POINT1_BACK not reachable in parsing [05:14:10 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:3097c10ee341: avutil/random_seed: Add the runtime in cycles of the main loop to the entropy pool [05:14:11 CEST] <cone-349> ffmpeg 03PrzemysBaw Sobala 07release/2.5:bbc3395a0bb0: avcodec/imgconvert: Support non-planar colorspaces while padding [05:14:12 CEST] <cone-349> ffmpeg 03Luca Barbato 07release/2.5:55937c49df42: indeo2data: K&R formatting cosmetics [05:14:12 CEST] <cone-349> ffmpeg 03Luca Barbato 07release/2.5:d604b84f9191: indeo2: Fix banding artefacts [05:14:14 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:e1d771e8183a: avcodec/resample: Remove disabled and faulty code [05:14:15 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:2cdeb2c4f87a: avcodec/mjpegenc_common: Store approximate aspect if exact cannot be stored [05:14:16 CEST] <cone-349> ffmpeg 03Ico Doornekamp 07release/2.5:f41e7b14db22: avformat/rtpdec_jpeg: fix low contrast image on low quality setting [05:14:16 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:7b551ba7320b: avcodec/libutvideodec: copy frame so it has reference counters when refcounted_frames is set [05:14:18 CEST] <cone-349> ffmpeg 03Aaron Boxer 07release/2.5:eae0a6582df3: avcodec/j2kenc: Add attribution to OpenJPEG project: [05:14:19 CEST] <cone-349> ffmpeg 03Marios Titas 07release/2.5:dc751a55e5ae: avfilter/src_movie: fix how we check for overflows with seek_point [05:14:19 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:1e46629234aa: avcodec/bmp_parser: Ensure remaining_size is not too small in startcode packet crossing corner case [05:14:21 CEST] <cone-349> ffmpeg 03Ivan 07release/2.5:2bb9f5d6074a: avcodec/h264: Fix for H.264 configuration parsing [05:14:22 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:9ae85f1468f4: avcodec/avpacket: Fix off by 5 error [05:14:23 CEST] <cone-349> ffmpeg 03Paul B Mahol 07release/2.5:72b600de29c6: avcodec/apedec: fix decoding of stereo files with one channel full of silence [05:14:24 CEST] <cone-349> ffmpeg 03Paul B Mahol 07release/2.5:e196cd52348d: avcodec/takdec: add code that got somehow lost in process of REing [05:14:25 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:1d3843fc939e: avfilter/vf_drawtext: Check return code of load_glyph() [05:14:26 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:7e5e531ec68b: avcodec/ac3dec: Reset SPX when switching from EAC3 to AC3 [05:14:27 CEST] <cone-349> ffmpeg 03Jan Ekström 07release/2.5:cba830c4636a: pgssubdec: fix subpicture output colorspace and range [05:14:28 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:fb15a0f42af3: avcodec/ttaenc: Reallocate packet if its too small [05:14:29 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07release/2.5:95a8dace5cc7: avformat/ffmdec: Check pix_fmt [05:15:06 CEST] <cone-349> ffmpeg 03foo86 07master:de28e73cce03: avcodec/dcaenc: reuse shared quant levels table [05:15:07 CEST] <cone-349> ffmpeg 03foo86 07master:b286ff69c03e: avcodec/dcaenc: move channel reordering tables to dcaenc.h [06:19:56 CEST] <kierank> maybe we should just revert that patch [06:20:01 CEST] <kierank> there's enough community objection [09:24:51 CEST] <kurosu> atomnuker, kierank, is there an issue with the threading in diracdec.c? On a 6cores machine, for 1-4 threads I get large increases in utime and real over a single thread [09:25:08 CEST] <kurosu> I only get an improvement on "real" for 5+ threads [09:27:04 CEST] <kurosu> also, can anyone confirm? [09:27:23 CEST] <kurosu> On a single thread, the new bitstream api is a wash so far [09:27:35 CEST] <kurosu> (but not the 15% decrease I was seeing) [09:35:22 CEST] <Timothy_Gu> Dammit... deleted /etc/ just after upgrading the entire system to ubuntu 16.04 :((( [10:00:33 CEST] <rcombs> that's recoverable, but not easily [10:51:19 CEST] <cone-163> ffmpeg 03Paul B Mahol 07master:8f4358888f37: avcodec/wmalosslessdec: fix type for coeffs and lms_updates in cdlms struct [11:18:57 CEST] <cone-163> ffmpeg 03Christophe Gisquet 07master:532e9370835d: avcodec/wmalosslessdec: silence a sample request [12:00:25 CEST] <kurosu> durandal_1707, sent the samples to michaelni some time ago [12:00:49 CEST] <kurosu> also before adding it, could you add the sample that helped detect the issue? [12:01:17 CEST] <kurosu> *also before adding these new tests, could you add one for the sample that helped detect the issue? [12:02:31 CEST] <kurosu> I can also send the samples as a zip file to the list (it's 81K) [12:03:40 CEST] <durandal_1707> Yes, I have two very small samples [12:04:28 CEST] <kurosu> that'd be nice, and I would have done it in one go, except I haven't followed at all the trac thread [12:12:01 CEST] <nevcairiel> if you need samples uploaded to fate, i can do that as well [12:33:18 CEST] <durandal_170> michaelni: there is some smc security bug, on Twitter [12:35:13 CEST] <michaelni> durandal_170 link ? [12:36:40 CEST] <durandal_170> CVE-2016-1528 [12:37:18 CEST] <durandal_170> michaelni: ^ [12:38:26 CEST] <michaelni> i know nothing about this, where is information what this is about ? [12:38:53 CEST] <nevcairiel> that cve is some android thing [12:39:35 CEST] <nevcairiel> oh wait wrong one [12:39:38 CEST] <nevcairiel> google tricked me [12:40:07 CEST] <durandal_170> http://www.talosintel.com/reports/TALOS-2016-0043/ [12:41:18 CEST] <nevcairiel> they claim to have tried to establish contact already back in september [12:51:22 CEST] <michaelni> Theres no mail from talos or cisco to ffmpeg-security, there is one mail from cisco to ffmpeg-devel-owner(a)ffmpeg.org on the 13 Jan 2016, thats long after the claimed contact [12:53:22 CEST] <durandal_170> perhaps this was fixed? [12:53:40 CEST] <michaelni> i belive none of the testcases they reported in january where reproduceable when we got them [12:55:14 CEST] <michaelni> the reply in january points to c727401aa9d62335e89d118a5b4e202edf39d905 and d99fbbf4d7e3f6abea0d052849a515730f552608 as potential fixes, our question about if they can confirm that was fixed seems not to have a reply also i cant find a reply to our question about which version they tested [12:57:48 CEST] <michaelni> no mails in my spam folder from cisco either t seems [13:01:22 CEST] <atomnuker> jamrial: it also happens with libfdk_aac at low bitrates [13:03:13 CEST] <atomnuker> kurosu: can you post what you get for different number of threads? [13:03:25 CEST] <atomnuker> also make sure your file isn't a single frame [13:33:44 CEST] <atomnuker> jamrial: it's a ts muxer problem, since it happens with opus and vorbis as well [13:38:33 CEST] <atomnuker> oh, carl already did something to try to fix that [14:41:06 CEST] <kurosu> atomnuker, numbers are threads:real/utime [14:41:12 CEST] <kurosu> master: 1:12.0/11.5 2:13.1/20.6 3:11.5/25.7 4: 7.7/23.2 [14:41:20 CEST] <kurosu> bitstream: 1:11.1/10.6 2:16.6/27.2 3:15.8/36.3 4:13.8/43.3 [14:41:53 CEST] <kurosu> so there might be a bug in the bitstream branch from my own, but the scaling even in master isn't exactly nice [14:42:02 CEST] <wm4> I have to admit I find "bitstream_peek" a much more intuitive name than "show_bits" [14:42:24 CEST] <kurosu> s/show_/peek_/ :D ? [14:44:37 CEST] <durandal_170> you like typing sausages? [14:46:00 CEST] <atomnuker> that's an odd scaling, no idea why bitstream would be slower [14:46:26 CEST] <atomnuker> but the threading is really needed to get anywhere near realtime speed on 1080p even on a fast modern machine [14:47:42 CEST] <kurosu> yes, but I'm wondering if there's no extra work being done [14:48:05 CEST] <kurosu> like: init_get_bits(&slices[slice_num].gb, buf, bufsize); [14:48:24 CEST] <kurosu> that shouldn't be bufsize but 8*bytes as far as I understand [14:48:55 CEST] <kurosu> no consequence iirc, but 2 threads being slower is mighty weird [14:49:04 CEST] <iive> the buffer is in bytes, so there is no need for extra operation. [14:49:18 CEST] <kurosu> although a slice seems to be 32x32, which is a small granularity for a thread and might incur too much overhead [14:49:42 CEST] <kurosu> iive, I'm just wondering if data is not decoded multiple times [14:49:42 CEST] <atomnuker> the current default is 32x16 slices [14:49:51 CEST] <kurosu> ok [14:50:23 CEST] <wm4> clearly you should use a lock-free queue to minimize the overhead of distributing these small units to workerthreads [14:50:28 CEST] <kurosu> I have no idea what's going on, just that those numbers sound fishy [14:51:10 CEST] <kurosu> hence why I asked people to see if they observe similar behaviour [14:51:44 CEST] <kurosu> doing one line of slices at a time could be another option [14:52:07 CEST] <kurosu> but I don't think that alone can really explain those numbers [14:52:33 CEST] <atomnuker> I do that in the "trimmed" dirac decoder I have: https://github.com/atomnuker/ffmpeg_dirac_trimmed [14:52:35 CEST] <iive> kurosu: perf does have statistics of caches, this might be one explanation. [14:52:59 CEST] <atomnuker> it does one slice at a time and also does the idwt in parallel [14:54:04 CEST] <kurosu> anyway, I don't think I want to spend much more time on vc2, my goal was just validating the bitstream reader [14:54:32 CEST] <cone-687> ffmpeg 03Clément BSsch 07master:bbf02f7d2886: lavc: override decode return value only in case of error [14:54:34 CEST] <kurosu> and I think I can't really make any conclusion [14:54:47 CEST] <kurosu> the one-thread performance of the new bitstream reader is better [14:55:54 CEST] <iive> kurosu: you might want to run the tests more times, to calculate a margin of error [15:18:05 CEST] <cone-687> ffmpeg 03Clément BSsch 07master:9f3dd530500e: lavc/srtenc: do not emit any subrip tags with text codec [15:29:31 CEST] <cone-687> ffmpeg 03Carl Eugen Hoyos 07master:47a11ff4574b: lavc/fic: Be less verbose for invisible cursor outside of video. [15:31:02 CEST] <cone-687> ffmpeg 03Carl Eugen Hoyos 07master:00ffbdfb68ca: lavc/fic: Do not warn about empty cursor. [15:40:32 CEST] <cone-687> ffmpeg 03Carl Eugen Hoyos 07master:88a849c714c1: lavf/mpegts: Return small probe score for very short transport streams. [16:05:36 CEST] <durandal_170> why I get connection reset when pulling from git? [16:31:10 CEST] <cone-687> ffmpeg 03Paul B Mahol 07master:423a6a099381: avformat/dsfdec: set bit_rate, fixes duration estimation [16:31:12 CEST] <cone-687> ffmpeg 03Paul B Mahol 07master:25482d5c42cc: avformat/wsddec: set bit_rate, fixes duration estimation [17:48:00 CEST] <rcombs> updating my application to use codecpar, and noticing that it's missing a way to get the stream's max number of ref frames and rc_max_rate [17:48:39 CEST] <rcombs> the former seems reasonable enough just to export; the latter is a bit wonky (mpeg2video exports it instead of bit_rate) [17:49:01 CEST] <JEEB> wait, IIRC you're getting an avcodec context in most cases, no? [17:49:12 CEST] <JEEB> if you're decoding or encoding [17:49:23 CEST] <JEEB> not sure if the codecpar touches at all the general use cases [17:49:32 CEST] <cone-687> ffmpeg 03Michael Niedermayer 07master:52623ef78546: avcodec/smc: Mark pixel pointer as const [17:49:33 CEST] <rcombs> this is in the context of using lavf for media analysis [17:49:54 CEST] <rcombs> just calling find_stream_info and pulling most of what that provides [17:50:00 CEST] <JEEB> right [17:50:38 CEST] <JEEB> I think there was a requires_decoding or so field? [17:50:51 CEST] <JEEB> I remember looking at ffmpeg.c and it was using it [17:51:10 CEST] <rcombs> no matches for that exact string [17:51:11 CEST] <kurosu> durandal_170, so for another fate test, I guess the raw pcm tile one is better [17:51:18 CEST] <rcombs> but there could be something similar [17:51:18 CEST] <kurosu> durandal_170, which stream would that be? [17:51:36 CEST] <rcombs> my problem is that refs and rc_max_rate are on AVCodecContext, and stream->codec is now deprecated [17:51:36 CEST] <JEEB> rcombs: it was decoding_neede [17:51:39 CEST] <JEEB> *needed [17:51:55 CEST] <rcombs> (I'm not sure if properties on stream->codec that aren't in codecpar are even exported anymore) [17:51:56 CEST] <JEEB> it's in the stream [17:52:37 CEST] <rcombs> that's ffmpeg.c-internal [17:52:45 CEST] <JEEB> ok, right [17:52:46 CEST] <rcombs> not sure what it has to do with analysis [17:53:03 CEST] <JEEB> it was just in the streams so I thought that was AVStream-specific [17:53:05 CEST] <JEEB> sorry [17:53:08 CEST] <rcombs> np [17:55:28 CEST] <rcombs> hmm, yeah, the stream->codec data is filled by `avcodec_parameters_to_context(st->codec, st->codecpar);` [17:55:38 CEST] <rcombs> so it's useless for getting data that's not actually in codecpar [17:55:46 CEST] <rcombs> that's an API break [18:23:21 CEST] <durandal_170> kurosu: g2-24bit.wma IIRC [18:24:01 CEST] <durandal_170> Downloadable from ticket [18:26:01 CEST] <kurosu> ok, I'll send an updated patch fate with that (and I guess anyone can add the file to fate-suite) [18:45:26 CEST] <cone-687> ffmpeg 03Michael Niedermayer 07master:3187277ebb7f: avcodec/wmalosslessdec: Fix memset sizeof [19:06:59 CEST] <nevcairiel> rcombs: rc_max_rate is exported using side data [19:07:07 CEST] <rcombs> oh, is it? [19:07:14 CEST] <nevcairiel> max refs is unreliable info at best and using it is probably wrong =p [19:07:28 CEST] <JEEB> yeah [19:07:51 CEST] <rcombs> where? [19:12:43 CEST] <rcombs> nevcairiel: re: rc_max_rate in side data, where is that? [19:13:11 CEST] <nevcairiel> forgot what its called, but its not like the list of packet side data iis infinte, so look at the header :D [19:15:13 CEST] <nevcairiel> cbp something [19:15:22 CEST] <durandal_170> so ffmpeg git will be moved to gitlab? [19:15:54 CEST] <rcombs> closest thing I see is AV_PKT_DATA_CPB_PROPERTIES [19:16:14 CEST] <rcombs> which afaict is for encode? [19:21:59 CEST] <rcombs> nevcairiel: is `refs` unreliable even as an upper bound? [19:22:33 CEST] <rcombs> (I'm probably fine dropping rc_max_rate on decode, since it was used in a field generally intended for average bitrate and thus wasn't particularly useful) [19:32:40 CEST] <rcombs> nevcairiel: we primarily use the refs information for Roku, where older models have a hard limit of 8 ref frames (i.e. they're not-quite-compliant L4.1 decoders) [19:34:21 CEST] <DHE> 8 frames is quite a lot. I know h264 allows up to 15 but doesn't diminishing returns set in quickly? [19:34:34 CEST] <rcombs> DHE: L4.1 allows up to 9 for 720p video [19:34:44 CEST] <nevcairiel> well the key argument here is that avformat is not meant to give you codec level information, but container information [19:35:00 CEST] <rcombs> for that purpose, would you expect the refs field exported by the H.264 decoder to be sufficient as an upper bound? [19:35:20 CEST] <rcombs> it calls the decoder and has historically exported that information from it [19:35:38 CEST] <rcombs> (what container reports ref frame count?) [19:36:03 CEST] <nevcairiel> it doesnt, hence its no longer provided [19:36:27 CEST] <DHE> I don't think it's actually a stored value in the stream though. wouldn't it just be something discovered while decoding? hence a short sample would not be very reliable [19:36:33 CEST] <DHE> or certainly not consistent [19:36:40 CEST] <rcombs> there's a max in SPS iirc [19:37:35 CEST] <DHE> huh... okay then [19:38:13 CEST] <rcombs> but now I'm wondering if it's actually reliable [19:40:43 CEST] <rcombs> generally I expect avformat_find_stream_info to report this sort of information, though it probably makes more sense to get it from the parser instead of invoking the decoder in a lot of cases [19:42:29 CEST] <rcombs> I could call the decoder (or parser) myself, but that's additional work the consumer has to do and ends up being a regression in functionality [19:43:23 CEST] <nevcairiel> generally we want avformat to provide container information, not any codec property, so this information no longer being available is the design going forward [19:44:01 CEST] <rcombs> that makes enough sense, but could you imagine an additional API to do what find_stream_info does now? [19:44:36 CEST] <rcombs> (read packets and parse or decode until all available information is exported) [19:44:49 CEST] <nevcairiel> not likely [19:45:07 CEST] <wm4> it would make sense to request different levels of information retrieval from lavf [19:45:13 CEST] <rcombs> obviously the consumer can do that itself, but it's still annoying to have something that used to be done and no longer is [19:45:28 CEST] <wm4> some API users really care only about the most basic info, some want full analyzation [19:45:31 CEST] <rcombs> wm4: sure [19:45:55 CEST] <michaelni> durandal_170, iam not aware of any git move, why do you think so ? [19:46:32 CEST] <Shiz> seems rather inane [19:47:08 CEST] <Shiz> ffmpeg already has a hosted git, why move to another one [19:47:24 CEST] <durandal_170> michaelni: IIRC videolan is doing it [19:47:27 CEST] <JEEB> probably videolan's gitlab was meant? [19:47:38 CEST] <Shiz> bleh [19:47:39 CEST] <JEEB> since they're moving their own stuff to it IIRC [19:47:50 CEST] <Shiz> their own gl instance or gitlab.com? [19:48:19 CEST] <JEEB> https://code.videolan.org/ [19:49:00 CEST] <Shiz> blank page :D [19:49:09 CEST] <Shiz> oh it finally loaded [19:49:13 CEST] <rcombs> iow everything stays the same except the web UI gets shinier [19:49:29 CEST] <Shiz> and the urls change [19:49:46 CEST] <Shiz> and now you can star repos!! [19:49:57 CEST] <rcombs> stars are shiny [19:50:50 CEST] <Shiz> i like how VLC itself isn't on there yet [19:57:29 CEST] <jamrial_> not sure if fully move, but adding a mirror there may be a good idea [20:01:08 CEST] <DHE> does libavfilter not support unlabeled graphs like the CLI does? [20:14:18 CEST] <wm4> DHE: the cli uses libavfilter [20:14:21 CEST] <wm4> so, yes [20:31:17 CEST] <jsebechlebsky> Hello, found several strange things in av_bsf_alloc, is someone familiar with this code here? [20:32:15 CEST] <jsebechlebsky> it's libavformat/bsf.c [20:32:16 CEST] <durandal_170> what is problem? [20:34:32 CEST] <jsebechlebsky> these are lines 112 - 123 in libavcodec/bsf.c: http://pastebin.com/2a0WBWbG [20:36:07 CEST] <jsebechlebsky> it allocates the private data of size priv_data_size and then copies pointer to priv_class pointer of the filter to the data. [20:36:59 CEST] <jsebechlebsky> So if I understand it right the priv_data field points to allocated pointer to filter->priv_class [20:37:31 CEST] <jsebechlebsky> first issue was I was getting invalid write on line 120 when I was running noise bsf under valgrind. [20:38:11 CEST] <jsebechlebsky> Turns out that priv_data size in noise_bsf.c is set to sizeof(int), so it obviously fails when attempting to store 64-bit pointer [20:39:40 CEST] <jsebechlebsky> but another issue is that av_opt_set_defaults is called on that pointer (which from the documentation should be only called on structure which contains AVOptions * as first member [20:40:35 CEST] <jsebechlebsky> This call is also source of invalid reads/writes [20:43:32 CEST] <jsebechlebsky> I thought maybe someone just forgotten to deallocate *ctx->priv_data, but this is also wrong since AVClass's first member is not AVOptions*. Also this allocation of pointer seems weird (why not to assign pointer directly?), but there can be a reason for that (priv_data is automatically freed at some point and we don't want the AVClass structure to be freed for example?) [20:44:14 CEST] <jsebechlebsky> But since I feel like there are several strange issues concentrated on single place I wanted to ask if someone knows what is going on there :) [20:46:14 CEST] <nevcairiel> the only bug i can see is that noise bsf should use sizeof(NoiseContext) [21:16:46 CEST] <jsebechlebsky> nevcairiel: you're right that is the only problem... the reads/writes I was getting were actually accesses to another members of NoiseContext structure... and I misread the documentation on av_opt_set_defaults :) [21:18:40 CEST] <jsebechlebsky> So sorry for a long post for a small problem :) Should I send the patch or is here someone who can push it directly to repository? [21:36:02 CEST] <DHE> wm4: I was just trying it and got back: Invalid filterchain containing an unlabelled output pad: "aformat=channel_layouts=stereo:sample_fmts=s16;volumedetect;volume=10" [21:36:22 CEST] <DHE> when I put in various [out1] [out2] labels it worked [21:36:33 CEST] <DHE> this is git less than a week old [21:38:23 CEST] <wm4> where? [21:38:37 CEST] <wm4> are you using ffmpeg cli or API? [21:39:22 CEST] <DHE> API [21:39:51 CEST] <DHE> using the template from the examples to build an audio pipeline instead of video. it worked fine for one filter. I tried expanding it and ran into that [21:40:12 CEST] <DHE> not a showstopper, but surprising [21:42:41 CEST] <wm4> huh [21:42:46 CEST] <wm4> let me check what I do [21:43:46 CEST] <wm4> seems like I use avfilter_graph_parse_ptr here [21:44:42 CEST] <wm4> and I pass an input named "in" and an output named "out" to it [21:45:13 CEST] <wm4> oh maybe you should use , instead of ; [21:45:22 CEST] <wm4> (not that I know what the difference is) [21:46:16 CEST] <ubitux> ';' separate parts, ',' is for stacking filter one after another [21:46:41 CEST] <ubitux> and yes you want to use a comma in your example [21:46:48 CEST] <DHE> hmm... that makes sense. [21:47:37 CEST] <wm4> ubitux: what are "parts" [21:47:55 CEST] <ubitux> wm4: independant branches of your graph [21:48:06 CEST] <DHE> for when your filter graph is actually complex [21:48:22 CEST] <ubitux> like, "[a] filter1, filter2, filter3 [b]; [x] filterX, filterY, filterZ [y]" [21:48:23 CEST] <wm4> I thought if there are no labels, the filters are chained implicitly [21:48:40 CEST] <ubitux> here you have 2 sources [a] and [x] and two outputs [b] and [y] [21:48:46 CEST] <DHE> it makes sense that ; and , are interpreted differently. there can be multiple inputs or outputs [21:52:52 CEST] <DHE> yeah you're right, comma is what I did wrong [22:25:50 CEST] <cone-562> ffmpeg 03Paul B Mahol 07master:bc2fe3622842: avcodec/noise_bsf: set correct size of .priv_data_size field [23:02:00 CEST] <durandal_170> atomnuker: still working on ffa1? [23:12:28 CEST] <atomnuker> durandal_170: the fun starts after I port kiss_fft's NxN dimension integer transforms [23:12:47 CEST] <atomnuker> haven't had time to do anything those last few weeks though [23:14:43 CEST] <durandal_170> why would use fft? Isn't it going to be lossless codec? [23:16:03 CEST] <durandal_170> I was thinking about using lpc and arithmetic coding [23:18:59 CEST] <atomnuker> that wouldn't buy you much gains, rice coding already small lpc coeffs and quantized errors is pretty efficient already [23:19:34 CEST] <atomnuker> the problem is that you can't do much prediction in the time domain unless the signal is really really steady or has a sharp single tone [23:20:56 CEST] <atomnuker> but with frequency domain you'd have quite a lot of repetition between each frame [23:21:22 CEST] <atomnuker> at least for the lower frequencies, below maybe 5-6 khz [23:21:59 CEST] <atomnuker> so if you had a very large frame size I was thinking of doing what you usually do with images [23:22:07 CEST] <atomnuker> *video [23:22:53 CEST] <atomnuker> subdivide your frame into blocks, which vary in size (you can do TF switching to switch between predicted coefficients for blocks with different sizes) [23:23:28 CEST] <atomnuker> pick a few blocks to use as a reference to derive similar blocks [23:24:29 CEST] <atomnuker> and yeah, I was thinking of doing the same thing flac does with the residuals to see what efficiency I would get [23:25:13 CEST] <atomnuker> since if your residuals are really small you can't really get much better than rice coding [23:26:20 CEST] <atomnuker> (as they'll be very uniformly spread on the frequency axis it wouldn't be worth using a contexed arithmetic coding, I think) [23:31:27 CEST] <atomnuker> all quantization (level picked by an estimation on how expensive the residuals would be) and prediction would be done using daala's pvq [23:32:48 CEST] <atomnuker> the huge frame size would be just temporary as it would make development easier, and would probably be replaced with P-frames further on [23:35:45 CEST] <atomnuker> LPC would still have its place as a coding tool but in the frequency domain (like AAC's TNS), in case it's cheaper to transmit LPC coefficients to filter a block to derive a new block [00:00:00 CEST] --- Mon May 2 2016

1 0

ffmpeg.log.20160501
by burek 02 May '16

02 May '16

[00:26:52 CEST] <dctrmnhttn> hello everyone [01:15:53 CEST] <hyponic> anyone here? [01:15:58 CEST] <sfan5> no [02:42:26 CEST] <hyponic> i am trying to transcode a stream and burn subtites from that stream. i just have no idea how to get it done. i have been googling for days without bein able to crack it. here is the stream: http://pastebin.com/JnpPYTx2 [02:43:21 CEST] <c_14> Don't post questions in both channels at the same time and especially don't post user-questions in #ffmpeg-devel [02:43:45 CEST] <c_14> Also, if by "stream" you mean live stream then you're currently out of luck [02:44:06 CEST] <DHE> 3 channels is the record for me... [02:44:26 CEST] <c_14> ffmpeg currently doesn't support burning in subtitles from streams (mainly due to the fact of how libavfilter handles subtitles (it doesn't) [02:45:14 CEST] <c_14> ) [02:47:25 CEST] <hyponic> c_14 sorry about that... what would be the workaround? if there is any [02:48:22 CEST] <c_14> you could start 2 ffmpeg processes reading from that stream and have one of them output the subtitles to a named pipe. Then the other process will read the stream and open the named pipe with the subtitles filter [02:48:26 CEST] <c_14> that should potentially work [02:49:50 CEST] <c_14> you could probably even just have the first process dump to an mkv fifo and then have the second read from that and use it in the subtitles filter [02:49:55 CEST] <c_14> That way you don't have to open the stream twice [02:52:41 CEST] <hyponic> c_14 i am not sure how to get something like that done. could you please explain? [02:53:35 CEST] <c_14> mkfifo foo.mkv; ffmpeg -i http://foo -c copy -f matroska foo.mkv& ffmpeg -i foo.mkv -vf subtitles=foo.mkv out.mkv [02:53:38 CEST] <c_14> should do it [02:54:07 CEST] <hyponic> c_14 alternatively what i am trying to do is to do this: http://pastebin.com/HKE6TxkS but it seems that ffmpeg's m3u8 muxer removes the index teletext page. [02:57:44 CEST] Action: c_14 has no clue about teletext or how ffmpeg handles it [03:01:43 CEST] <hyponic> c_14 how about something like this.. would that make it easier? http://pastebin.com/XHJXabbb [03:02:28 CEST] <c_14> Make what easier? [03:04:13 CEST] <hyponic> solve my problem.. pass this through ffmpeg's m3u8 muxer [03:04:29 CEST] <hyponic> or burn it on the video [03:07:43 CEST] <c_14> I'm not sure ffmpeg's hls muxer can handle multiple subtitle streams [03:08:26 CEST] <c_14> you'd have to pick one to keep and throw the others away [03:10:11 CEST] <hyponic> c_14 how would i pick one? [03:10:44 CEST] <c_14> make the -map more specific. I.e. -map 0:s:0 instead of -map 0:s to pick the first one [03:11:01 CEST] <c_14> You can also pick by metadata etc [03:11:19 CEST] <c_14> look in the manpage for examples/info [03:12:05 CEST] <hyponic> c_14 i'd rather transcode the sub on the video if that is doable [03:13:16 CEST] <c_14> 00:53 <c_14> mkfifo foo.mkv; ffmpeg -i http://foo -c copy -f matroska foo.mkv& ffmpeg -i foo.mkv -vf subtitles=foo.mkv out.mkv [03:13:20 CEST] <hyponic> c_14 0:s:2 would that be: Stream #0:6(fra): Subtitle: subrip (default) or does it have to be 0:s:6 [03:13:36 CEST] <c_14> Just change out.mkv to out.m3u8 add the hls options, drop the -map 0:s and add -sn [03:13:57 CEST] <c_14> 0:s:2 would be the fra stream, yes [03:14:10 CEST] <c_14> you can also do 0:6 to get the 7th stream (which would also be the fra one) [03:14:15 CEST] <c_14> *the fra subtitle one [03:18:14 CEST] <hyponic> c_14 sub2video: non-bitmap subtitlee= [03:19:46 CEST] <c_14> hmm? [03:25:13 CEST] <hyponic> c_14 tried another aproach: http://pastebin.com/3Yp2jTdi [03:25:21 CEST] <hyponic> a different error [04:38:05 CEST] <ptomblin> Hi. Im trying to make a green screen background that I can overlay stuff on using Garmin VIRB Edit, using the command `ffmpeg -f lavfi -i color=color=green -s 1920x1080 -t 3600 -r 60 small_green.mp4` but VIRB Edit sees the result as 1440x1080 instead of 1920x1080. Why is that? [04:39:16 CEST] <ptomblin> ffprobe results in http://pastebin.com/bLCUumRx [09:23:36 CEST] <Fyr> guys, how to create something like this: [09:23:36 CEST] <Fyr> https://vimeo.com/85590386 [09:23:36 CEST] <Fyr> ? [09:23:59 CEST] <Fyr> what soft was used to create this video? [09:28:38 CEST] <Betablocker> Fyr: css3 / javascript [09:28:47 CEST] <Fyr> %) [09:28:51 CEST] <Fyr> impossible [09:30:02 CEST] <Betablocker> why ? [09:30:14 CEST] <Betablocker> looks like a css3 animation to me [09:51:14 CEST] <A124> Hello, probably on the net, but cannot find. Can someone sum diffrence between yadif 1 and 3? [09:56:19 CEST] <A124> Quote: And that's where diff is left, if using yadif in mode 2 or 3. But in modes 0 and 1, more is done to the interpolated frame... [09:56:22 CEST] <A124> Quote: And that's all modes 2 and 3 add on top of modes 0 and 1. [09:56:37 CEST] <A124> Unless I do not understand English those two are conflicting. [09:57:56 CEST] <A124> 3 : double frame rate, skips spatial interlacing check. [09:58:12 CEST] <A124> I think that gets me answer (froma visynth port amusingly) [09:59:29 CEST] <durandal_1707> Is hard to read docs [10:03:10 CEST] <A124> I did not find the right docs apparently. [10:03:50 CEST] <A124> Still it seems that filters with avisynth win at deinterlacing. Makes me sad to see it is made for win only. [10:52:48 CEST] <operator> trying to stream a video file to youtube, but getting error. http://pastebin.com/UeeGn5ZH [10:53:34 CEST] <operator> the problem is video codec, do I understand it right? [12:34:58 CEST] <DHE> Is there any examples or means of using the downmix information from available sources to control the downmix process? using libswresample to convert 5.1 to stereo audio but the center channel needs to be turned up a bit [12:39:03 CEST] <debianuser> Hello. What's a good way to silence several audio fragments of the file? `ffmpeg -i input.mkv -c copy -acodec flac -af "volume='if(between(t,10,11),0,1)':eval=frame, volume='if(between(t,12,13),0,1)':eval=frame" output.mkv` kind of works but I thought maybe there's an easier way to do that? [12:39:32 CEST] <debianuser> DHE: Maybe this can help?: https://trac.ffmpeg.org/wiki/AudioChannelManipulation [12:40:53 CEST] <DHE> debianuser: looking at the source code I saw that the AC3 codec provides side data which includes downmix info, like the orginal audio source suggests a downsampling matrix. but libswresample doesn't seem to offer anything to read it or fill in the matrix myself without sticking my hands into "internal" fields [12:46:22 CEST] <DHE> also, API not CLI [12:46:55 CEST] <debianuser> ah! I don't know then, sorry. :( [12:47:41 CEST] <c_14> DHE: there's an option eh [12:48:02 CEST] <c_14> DHE: the drc_scale option on the ac3 decoder maybe [12:48:31 CEST] <c_14> wait, no [12:48:35 CEST] <c_14> That wasn't it [12:49:10 CEST] <DHE> I'm trying to see if there is a way to make AC3 output in stereo directly. It looks like it from the code - that it will use the matrix for itself - but having trouble doing it. So I'm checking both directions [12:49:10 CEST] <c_14> I know it's possible (mpv does it). I'm just not quite sure how [12:53:13 CEST] <c_14> DHE: it looks like you just have to set the request_channel_layout on the avctx [12:53:33 CEST] <c_14> +to a valid AV_CH_LAYOUT [13:00:52 CEST] <c_14> debianuser: you could use -af volume='if(between(t,10,11)+between(t,12,13),0,1):eval=frame' [13:01:10 CEST] <c_14> other than that, probably no [13:08:36 CEST] <debianuser> c_14: Ah, ok, thank you! [13:12:28 CEST] <DHE> c_14: I think that worked... [13:12:38 CEST] <DHE> (request_channel_layout) [15:43:54 CEST] <MrSassyPants> ok how do I enable scene cut key frames in vp9 ? [16:36:23 CEST] <hyponic> anyone that can help me out with a teletext subtitle burning issue? [16:59:17 CEST] <getoo> i am trying to slice a video , used some google searches but wont help .. its in the middle of the video starts at 19:40 and its 5 minutes long [17:07:03 CEST] <c_14> ffmpeg -ss 19:40 -i video -t 5:00 out.mkv [17:15:12 CEST] <getoo> c_14: thank you [17:27:02 CEST] <elichai2> hey [17:27:16 CEST] <elichai2> why Ubuntu repo ffmpeg version is only 2.8.6? [17:28:47 CEST] <c_14> Ask the package maintainer [17:29:10 CEST] <furq> what a nice young man [17:31:38 CEST] <elichai2> is there an easy way to upgrade to 3.x? [17:31:52 CEST] <c_14> download a static build [17:31:53 CEST] <furq> elichai2: http://johnvansickle.com/ffmpeg/ [17:32:45 CEST] <elichai2> furq, yeah, but where should i put the binaries and manpages? [17:35:02 CEST] <furq> /usr/local [18:11:10 CEST] <getoo> how do i rip the audio from a .mkv .. i believe the audio encoding is vorbis [18:11:37 CEST] <furq> -i src.mkv -c copy -map 0:a out.ogg [18:11:50 CEST] <getoo> furq: thank you [18:13:49 CEST] <getoo> that was almost instant :) [20:17:05 CEST] <needALamp> i had video that i download from the internet, it has a subtitle that encode in the container ( checked by ffmpeg), but when i play it, it didn't shown up??? what is going on, thank you. [20:20:26 CEST] <needALamp> hello guys.. [20:26:05 CEST] <c_14> What video player? [20:49:42 CEST] <needALamp> hello [20:49:55 CEST] <needALamp> hello c_14 its vlc [20:51:25 CEST] <needALamp> but i also tested to upload this file to youtube but didnt work too [20:51:48 CEST] <c_14> Can you upload the output of ffprobe of that file to a pastebin service? [20:54:35 CEST] <needALamp_> hello c_14 sorry got bust out. [20:54:54 CEST] <c_14> Can you upload the output of ffprobe of that file to a pastebin service? [20:55:31 CEST] <needALamp_> a moment [20:59:28 CEST] <Anonaly> hi ppl, how do I see what my ffmpeg version is ? [21:00:09 CEST] <c_14> ffmpeg -version [21:37:33 CEST] <anomie__> How can I render subtitles over a still image? Everything I try, only the first subtitle gets burned into the image then that's used for the rest of the video. [21:50:59 CEST] <durandal_170> anomie__: you need to loop image [21:51:42 CEST] <anomie__> Okay. [21:53:01 CEST] <anomie__> I think that's working. Thanks. [22:40:30 CEST] <hyponic> anyone with teletext subtitle experience? i am unable to burn teletext subtiles from a ts stream. any help i greatly appriciated. [23:05:53 CEST] <Illya> how can I extract a specific audio frame of an MPEG-1 layer-3 stream? [23:09:08 CEST] <JEEB> you'd have to use the API for that, so I recommend a tool that specifically outputs information on MPEG-1 Layer 3 streams [23:25:12 CEST] <Anonaly> hey ppl I am about to convert hundreds of videos on my computer from .FLV (h264, ac3) to mp4, because my TV does not play .flv files and serviio does not transcode them [23:25:23 CEST] <Anonaly> http://forum.serviio.org/viewtopic.php?f=5&t=21979 [23:25:29 CEST] <Anonaly> going to use avconv like this [23:25:38 CEST] <Anonaly> avconv -i infile.flv outfile.mp4, [23:26:05 CEST] <durandal_170> this is ffmpeg channel not avconv [23:32:48 CEST] <furq> Anonaly: add -c copy [23:40:11 CEST] <Anonaly> codec copy furq what is this for ? [23:41:32 CEST] <furq> you're converting flv to mp4, you don't need to reencode [23:42:01 CEST] <furq> unless your tv doesn't play h.264 in which case your initial command wouldn't work anyway, and also you should throw your tv in the bin [23:48:28 CEST] <Anonaly> furq, it was a free tv, 55 inch with 3d bla bla. [23:48:49 CEST] <Anonaly> I would end up getting another tv that doesn't play some other type of file anyway [23:49:08 CEST] <Anonaly> because so far no tv's I have experimented with play all files [23:49:14 CEST] <Anonaly> AVI files = garbage, [23:49:21 CEST] <Anonaly> FLV files = garbage [23:50:12 CEST] <Anonaly> I actually blew up a Toshiba tv at london drugs once because the sales rep told me my Toshiba laptop can plug into the TV with a VGA cord, so he took my laptop plugged it in to VGA [23:50:21 CEST] <Anonaly> and my toshiba laptop fried his toshiba tv [23:50:26 CEST] <Anonaly> infront of our eyes [23:50:32 CEST] <Anonaly> vga cord [23:51:02 CEST] <Anonaly> (and it was his fault because he plugged it in) [00:00:00 CEST] --- Mon May 2 2016

1 0