Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

November 2016

1 participants
60 discussions

ffmpeg-devel.log.20161124
by burek 25 Nov '16

25 Nov '16

[00:56:28 CET] <cone-728> ffmpeg 03Moritz Barsnick 07master:0700d02a697e: lavfi/pan: allow negative gain parameters also for other inputs than the first named [01:51:35 CET] <cone-728> ffmpeg 03Andreas Cadhalpun 07master:995512328ed8: pgssubdec: only set w/h/linesize when allocating data [02:00:13 CET] <Chloe[m]> atomnuker: why wait? [02:01:21 CET] <atomnuker> Chloe[m]: he told us that he needed "a few days" to move it to an external repo [02:01:30 CET] <atomnuker> like, 3 weeks ago [02:31:11 CET] <jya> what's the rationale behind http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=5702416c57afb2bb062eb6… ? I can understand not attempting to seek if the stream isn't seekable. But duration and size can certainly be updated. This has broken mythtv flash streaming [03:20:58 CET] <Timothy_Gu> michaelni: So I'm seeing that https://www.ffmpeg.org/ still uses a certificate from StartCom CA [03:21:24 CET] <Timothy_Gu> But apparently their CA had some pretty serious messup Mozilla, Google, Apple, etc. are distrusting them [03:21:31 CET] <Timothy_Gu> for future certs [03:21:33 CET] <Timothy_Gu> https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-sta… [03:21:54 CET] <Timothy_Gu> https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html [03:34:24 CET] <michaelni> Timothy_Gu, reimar is the one who does/did the cert stuff [03:34:42 CET] <michaelni> please tell him [10:47:18 CET] <Chloe> atomnuker: sure, well, the current FFserver is in git history. No reason why he couldn't do that even after it's removed [10:56:01 CET] <Chloe> michaelni: how are you sending signed mail? My client seems to be sending it in a way which results in a bad signature [11:00:25 CET] <Chloe> Ah, I think I was using PGP/MIME which I guess won't work [11:00:29 CET] <wm4> merges are behind by 600 commits and 4 months [11:04:34 CET] <wm4> that makes me even want to consider helping out with the merges, but the next commits to merge are already quite intrusive and complicated [11:05:16 CET] <nevcairiel> i havent checked yet [11:42:47 CET] <nevcairiel> philipl: have you tested what happens if you try to to decode 12-bit on older hardware? does it just refuse to create the decoder? [12:49:17 CET] <matija> trying to build ffmpeg with libnpp, using latest cuda toolkit but ther eis no libnpp there only libnppc,s and i, tried 3.2 and latest git, same result - ERROR: libnpp not found [12:49:23 CET] <matija> any ideas? [13:15:16 CET] <superware> I'm using ffmpeg 3.1.4, avformat_open_input is calling my interrupt_callback, but when the callbak returns 1 (I verified that it's actually being called and returns 1) then avformat_open_input doesn't abort but rather keeps blocking, any idea? [13:17:23 CET] <superware> (the url being opened is "udp://224.0.19.0:40004/" [13:23:34 CET] <superware> anyone alive? :| [13:28:34 CET] <superware> ok, this seems to be the same issue from 6 months ago https://trac.ffmpeg.org/ticket/5615 [14:44:46 CET] <wm4> superware: try to find out where it hangs [14:46:38 CET] <superware> wm4: unfortunately it might be too complex for me to understand exactly where, keep in mind it can be stuck in a specific state and not a specific position/line. [14:49:01 CET] <superware> wm4: it's very easy to reproduce, it can be any UDP url (eg. udp://127.0.0.1:8000) in fact it shouldn't even exists, because if it does exist the stream will be opened and not have a chance to hang :) [16:32:24 CET] <philipl> nevcairiel: i have not, but i assume so based on how it behaved with 12bit on the old driver which didn't support it. [16:33:58 CET] <cone-784> ffmpeg 03Paul B Mahol 07master:8f5a2bed5eab: ffmpeg_filter: fix several logic failures [17:43:34 CET] <jamrial> BtbN, philipl: is this ok? http://pastebin.com/raw/bjqMkQFm [17:44:12 CET] <BtbN> "check_header cuda.h"? [17:44:18 CET] <BtbN> There is no cuda.h used anymore [17:44:37 CET] <jamrial> it's used by hwcontext_cuda.h [17:44:50 CET] <jamrial> and it's making make checkheaders fail [17:45:16 CET] <jamrial> http://fate.ffmpeg.org/log.cgi?time=20161124053746&log=compile&slot=x86_64-… [17:45:20 CET] <BtbN> oh right, the fallback. [17:45:44 CET] <jamrial> that patch fixes it by making sure to not test that header if the Cuda Toolkit is not installed in the build system [17:45:59 CET] <jamrial> the _internal one can be tested fine since it includes the compat header [17:46:02 CET] <BtbN> it can test that header though, it just has to include the header from compat first [17:46:38 CET] <nevcairiel> checkheaders is specifically meant to test if every header works standalone [17:46:38 CET] <jamrial> that's what hwcontext_cuda_internal.h does, but hwcontext_cuda.h can't [17:46:43 CET] <nevcairiel> so including something first goes against its entire idea [17:47:02 CET] <nevcairiel> and if some headers depend on some external library, they need to be excluded [17:47:14 CET] <BtbN> ah, so that's what that configure check does [17:47:24 CET] <BtbN> Looked like it makes cuda depend on cuda.h again [17:47:34 CET] <BtbN> Yeah, that's fine then [17:47:35 CET] <jamrial> no :p [17:47:43 CET] <jamrial> it just adds a check for a header if cuda is enabled [17:49:03 CET] <jamrial> ok, thanks [17:52:33 CET] <cone-784> ffmpeg 03James Almer 07master:d1de725beed3: cuda: check for cuda.h when enabled [21:11:07 CET] <cone-784> ffmpeg 03Wan-Teh Chang 07master:dceac9a4a754: avfilter/tests/.gitignore: add integral [21:11:08 CET] <cone-784> ffmpeg 03Wan-Teh Chang 07master:048b46b4e294: avutil/tests: add cpu_init to .gitignore and tests/fate [21:16:27 CET] <michaelni> Timothy_Gu, http://fatebeta.ffmpeg.org/v3.2 doesnt seem to exist [21:23:18 CET] <cone-784> ffmpeg 03Muhammad Faiz 07master:ebb4c783d025: fate/swresample: add resample exact_lin and exact_lin_async test [21:23:19 CET] <cone-784> ffmpeg 03Muhammad Faiz 07master:06f94149c61f: swresample/resample: optimize exact_rational=on:linear_interp=on case [23:00:57 CET] <wm4> nevcairiel: does dxva2 (or d3d11va) have a mechanism to check max. video size? [23:01:57 CET] <nevcairiel> Try to create a decoder, see it fail? [23:02:26 CET] <nevcairiel> I do thay [23:02:48 CET] <nevcairiel> It needs no bitstream params or anything, just the dimensions [23:03:00 CET] <wm4> well I heard that LAV has an option to enable UHD decoding [23:03:28 CET] <nevcairiel> Some hardware just sucks despite supporting it [23:03:48 CET] <wm4> slower than sw dec, or failure to decode correctly? [23:03:59 CET] <nevcairiel> Especially with 4k it was very very slow on first gen [23:04:32 CET] <nevcairiel> And AMD had broken 4k until they figured it out and blacklisted it in the driver [23:04:55 CET] <nevcairiel> Half the image was green :) [23:05:00 CET] <wm4> eh [23:05:27 CET] <wm4> mpv and google chrome still have issues with normal d3d11va direct rendering on amd [23:05:45 CET] <nevcairiel> In general it can autodetect the dimensions, but the options are workarounds for bugs [23:05:57 CET] <nevcairiel> And AMD is just terrible on hwaccel more or less [00:00:00 CET] --- Fri Nov 25 2016

1 0

ffmpeg.log.20161124
by burek 25 Nov '16

25 Nov '16

[00:00:28 CET] <JEEB> oh, tapt contains enof which is "Track Encoded Pixels Dimensions Box" [00:00:31 CET] <JEEB> never saw that one before [00:00:46 CET] <JEEB> or noticed [00:00:52 CET] <Jan-> this is a bit odd as the video track in this should be 3840 by 2160 but I'm seeing 3840 and 2048 in the tkhd [00:02:00 CET] <Jan-> plus the aspect ratio in pasp should be about 1.33:1 and it's like... well, 1.328 [00:03:45 CET] <Jan-> I guess that's near enough [00:12:35 CET] <Jan-> If I have a "tkhd" followed by an "edts" box, the four bytes before the letters e, d, t, s will be the last 32 bit value in the "tkhd", right? [00:13:36 CET] <Jan-> dohhhh *facepalm* big endian! [00:21:16 CET] <Jan-> hmm the hardware recorder doesn't seem to set "enof" [00:25:34 CET] <Jan-> OK well that all makes sense, thanks JEEB [00:31:46 CET] <Jan-> you know I never looked at quicktime files this closely before but they seem pretty much like RIFFs [01:47:06 CET] <raulp> If anyone is alive and can take a look at this http://stackoverflow.com/questions/40774967/ffmpeg-stream-chrome-kiosk-mode… and provide any help .. would be cool - thanks [03:16:22 CET] <Mysoft> ok so assume i'm reading from webcam, i have a target 30fps... but the encoding takes too long [03:16:37 CET] <Mysoft> how i can force it generate correct output timestamp considering the drops? [03:16:57 CET] <Mysoft> currently it's generating a output that the motion acts as if it was accelerated [09:18:20 CET] <yorkie> Hi, when i use ffmpeg to send an avi file to my ffserver, it occurs the following error: Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height [09:18:36 CET] <yorkie> does anyone know how to fix and where to fix? [11:45:35 CET] <squ> an error about streams [11:49:11 CET] <dystopia> http://pastebin.com/w0PFTPAW [11:49:34 CET] <dystopia> anyone know whats up? the file "E:\Decomb.dll" exists [11:50:48 CET] <tdr> maybe its not whether it exists, maybe its not the correct version [11:51:17 CET] <furq> sounds like a 64-bit dll with 32-bit avisynth [11:51:57 CET] <tdr> or vice versa [11:52:18 CET] <dystopia> ok will see if i can find a 64 bit version of avisynth [11:52:19 CET] <dystopia> thanks [11:52:35 CET] <furq> you need the one which matches ffmpeg [11:53:01 CET] <tdr> whatever the winderz equiv of ldd is should help [11:53:05 CET] <furq> probably easier to find a matching decomb.dll [11:53:10 CET] <tdr> ffmpeg site has the dll's for it i thought [11:53:21 CET] <furq> or use vapoursynth, it's less dumb with this sort of thing [11:57:21 CET] <dystopia> switching to 32bit ffmpeg got it running [11:57:23 CET] <dystopia> thanks guys [11:58:22 CET] <tdr> oh all the apps to actually use 64 bit, ffmpeg would be one i'd pick [11:58:27 CET] <tdr> s/oh/of [12:44:36 CET] <matija> hello, i'm trying to build ffmpeg with libnpp [12:44:48 CET] <matija> i have instelled cuda toolkit 8.0.44 [12:45:02 CET] <matija> and ther eis no libnpp , but there are libnppc, s and i [12:45:18 CET] <matija> do you have any idea how to fix it [12:45:26 CET] <matija> i tested it against 3.2 and latest git [13:18:40 CET] <squ> what is npp? [13:19:42 CET] <matija> squ: nvidia pascal something [13:20:08 CET] <matija> NVIDIA Performance Primitives core runtime library [13:20:39 CET] <squ> is this nvidia related? [13:20:48 CET] <matija> yes [13:20:53 CET] <squ> I mean its not ffmpeg library [13:21:34 CET] <superware> Using ffmpeg 3.1.4, avformat_open_input for "udp://224.0.19.0:40004/" is calling my interrupt_callback, but when the callbak returns 1 (I verified that it's actually being called and returns 1) then avformat_open_input doesn't abort but rather keeps blocking, any idea? [13:21:50 CET] <matija> it's not but it's blocking ffmpeg setup, i might be doing something wrong really [13:22:19 CET] <squ> so if it is not then figure out how to install nvidia drivers on your system properly [13:22:25 CET] <matija> let me post config.log somewhere [13:22:28 CET] <squ> no [13:22:36 CET] <matija> squ: they are installed [13:22:58 CET] <matija> i'm reading http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2016-August/003763.html [13:23:10 CET] <matija> similar issue really [13:23:18 CET] <matija> but won't work here [13:23:30 CET] <squ> if it is not ffmpeg related [13:23:32 CET] <squ> why are you here [13:24:20 CET] <matija> but it is ffmpeg related, code is unable to find libs [13:24:31 CET] <matija> and is searching for correct ones [13:24:40 CET] <squ> if it is not ffmpeg library, then how ffmpeg is relevant [13:29:46 CET] <superware> ok, this seems to be the same issue from 6 months ago https://trac.ffmpeg.org/ticket/5615 [14:00:19 CET] <henning_> how can i use ffmpeg to convert any video into an rgb video? [14:02:58 CET] <kerio> define convert [14:13:28 CET] <Mysoft> hello people, so i have a situation where i have it encoding a realtime input, but i'm using a "medium" preset so it doesnt reach the target fps... and as result of that the output video plays at lightspeed instead of normal speed... is there any way to normalize the output timestamp under such conditions? [14:27:39 CET] <DHE> any reason you can't go to "fast" instead? [14:28:17 CET] <DHE> there are options that may help, including -vsync and -copyts. never tried them for this particular purpose so experiment a bit first [14:43:27 CET] <ffmpeg721> how can i convert a video in yuv colorspace to rgb colorspace using ffmpeg on command line? [14:46:04 CET] <kerio> define convert [14:46:53 CET] <ffmpeg721> i have a video file which uses yuv color space and i want the same video to use rgb color space [14:48:09 CET] <sam> are you sure the codec in that video supports RGB colorspace? [14:48:22 CET] <ffmpeg721> no [14:48:46 CET] <ffmpeg721> its h264 [14:50:00 CET] <kerio> then i don't really understand your goal [14:50:16 CET] <kerio> by converting the color space you only stand to lose information [14:50:44 CET] <ffmpeg721> i don't care. i just need any video with rgb color space for testing purposes [14:51:24 CET] <kerio> rawvideo :D [14:52:47 CET] <kerio> -c:v rawvideo -pix_fmt rgb24 [14:56:08 CET] <ffmpeg721> option pixel_format not found? wtf? [15:15:13 CET] <Haze_Ortner> Anyone have any experience in extracting timecode on h264 mp4 files with FFprobe? For some reason FFprobe calculates the time wrong with a 59.98 fps movie with 29.97 timecode track in it. [15:17:04 CET] <BtbN> you mean the duration? [15:19:53 CET] <Haze_Ortner> BtbN: No, the Timecode Track Eg, timecode of first frameš. It works with PAL framerates but calculates wrong in NTSC. [16:04:50 CET] <dam> Hi, I am using ffmpeg v3.2 to transcode audio in video from ac3 to mp3. During the transcoding I receive following message: [ac3 @ 0x4065ba0] incomplete frame and Error while filtering: Operation not permitted. Is first of those messages causes 2nd one? Is the 'incomplete frame' warning or error? [16:20:22 CET] <superguest> https://ffmpeg.org/ffmpeg-filters.html#Text-expansion [16:27:14 CET] <superguest> It is said that 2ndArg in %{pts\:localtime\:2ndArg} is an offset added to the timestamp. [16:28:11 CET] <superguest> By default, YYYY-MM-DD HH:MM:SS format will be used. [16:28:52 CET] <superguest> I want to know how and in what format this 2ndArg is in. [16:31:12 CET] <superguest> Say i want to offset the current timecode by +1 day [16:31:40 CET] <superguest> How do I specify the 2ndArg? [16:57:27 CET] <dmfrey> Hi all. Not sure if this is the right channel, but is it possible to use one of the libraries, like libavcodec, through JNI on android to decode mpeg2? [16:57:32 CET] <dmfrey> i can build it and am already using it to play back ac3 audio [16:57:38 CET] <dmfrey> I plan on writing an extion to ExoPlayer (https://github.com/google/ExoPlayer) that will allow my app to provide native mpeg2 ts playback from within my app [20:12:42 CET] <dystopia> i have a video thats 59.940fps and full of duplicate frames, it should be 23.976, im trying to decimate it with decomb.dll in an avs script using selecteven() to drop the framerate to 29.97, then decimate() to restore it to 23.976 [20:13:14 CET] <dystopia> the output now at 23.976 has an ocasional dupe frame, maybe 1 every 2 to 3 seconds [20:13:40 CET] <dystopia> is there anyway to fix this or an alternate deimation technique i can try [21:04:45 CET] <durandal_1707> dystopia: use libavfilter, this is ffmpeg channel [00:00:00 CET] --- Fri Nov 25 2016

1 0

ffmpeg-devel.log.20161123
by burek 24 Nov '16

24 Nov '16

[00:00:00 CET] <wm4> seems like you have to parse the whole file [00:00:23 CET] <microchip_> wm4: enjoying mpv, btw. thx! ;) [00:00:44 CET] <wm4> k [00:01:14 CET] <wm4> parsing the whole file as in skipping over all frames, skipping being relatively simple [00:01:15 CET] <j-b> wm4: not sure. [00:07:23 CET] <wm4> I guess there's no other way than practically demuxing the entire file [00:07:26 CET] <wm4> what a vile format [00:25:31 CET] <philipl> BtbN: I think cuvid/nvenc transcoding is broken again. [00:25:44 CET] <philipl> the frame width/height values are reaching nvenc as 0/0 [00:26:44 CET] <philipl> i thought it was a problem doing p010 transcoding but now I see nv12 doesn't work either [00:27:33 CET] <wm4> rocky merge seas [00:41:59 CET] <cone-763> ffmpeg 03Andreas Cadhalpun 07master:fdb8c455b637: mxfdec: fix NULL pointer dereference in mxf_read_packet_old [00:42:48 CET] <jya> BBB: the avx2 idct optimisation, how much would you expect this to improve performance playback? I can't say I notice much difference with our benchmark test... I may gain 1 extra decoded frame per second (on this machine, that translates to 219fps vs 220fps) [00:43:00 CET] <jya> and that may just be standard variation [00:48:28 CET] <michaelni> philipl, fate-source is failing due to compat/cuda/dynlink_* [00:49:04 CET] <michaelni> random example: http://fatebeta.ffmpeg.org/report/x86_32-mingw-w64-dll-windows-native/20161… [00:55:45 CET] <cone-763> ffmpeg 03Michael Niedermayer 07master:4e5049a2303a: avformat/mpeg: Adjust vid probe threshold to correct mis-detection [01:01:03 CET] <philipl> BtbN: I think that one's for you :-) [01:10:07 CET] <Kuroe> [22:52:16] <rcombs> (I'm doubtful many people will spend money on TV for the sake of object audio) [01:10:13 CET] <Kuroe> you'd be surprised... [01:10:50 CET] <Kuroe> People lap up buzzwords, and if something has more of them then it must be better--and they only want the best ofc. [01:12:22 CET] <TD-Linux> object audio from 2 speakers? [01:13:19 CET] <wm4> obviously you want to use it with a VR headset, with audio mixed according to head direction, in realtime [01:14:08 CET] <TD-Linux> I mean, that is presumably what google is doing, but they are using ambisonics not object based [01:14:16 CET] <TD-Linux> because it is actually possible to sanely record ambisonics [01:15:24 CET] <TD-Linux> also YT HDR is actually HDR10, not HLG [01:15:42 CET] <TD-Linux> (also HDR10 mandates HEVC so it's the VP9 equivalent) [01:21:56 CET] <cone-763> ffmpeg 03Andreas Cadhalpun 07master:946ecd19ea75: smacker: limit recursion depth of smacker_decode_bigtree [01:21:56 CET] <cone-763> ffmpeg 03Andreas Cadhalpun 07master:de4ded06366e: rmdec: validate block alignment [01:21:57 CET] <cone-763> ffmpeg 03Andreas Cadhalpun 07master:dbefbb61b785: sbgdec: prevent NULL pointer access [01:31:12 CET] <microchip_> sorry guys, shouldn't have started this who AC-4 thing... but I'm curious about new audio/video things :) [01:31:18 CET] <microchip_> whole* [02:02:37 CET] <cone-763> ffmpeg 03Michael Niedermayer 07master:2f935baa7d86: avutil/opt: Add AV_OPT_TYPE_UINT64 [02:02:38 CET] <cone-763> ffmpeg 03Michael Niedermayer 07master:69f7dd3524d9: avcodec/options_table: make channel_layouts uint64 [02:38:01 CET] <BBB> jya: what kind of machine? [02:59:46 CET] <jya> It's a MacPro, Xeon E5 8 core, 3GHz [03:00:13 CET] <jya> BBB: AVCodecContext is configured with a thread count of 7 [03:00:27 CET] <BBB> what year mac pro? [03:00:31 CET] <BBB> what chipset? [03:21:40 CET] <drv> the latest Mac Pro has an Ivy Bridge Xeon, so no AVX2 [03:29:21 CET] <cone-763> ffmpeg 03Sam Hocevar 07master:3115550abe96: doc/examples/muxing: Fix av_frame_make_writable usage [03:46:43 CET] <BBB> drv:I expected sth. like that, just wanted to make sure [03:46:51 CET] <BBB> jya: try the new macbook pro (2015 or 2016) [03:58:43 CET] <jya> BBB: how would they make a difference there? [03:58:58 CET] <jya> the E5 is a v4 intel, it has full avx2 support [03:59:00 CET] <BBB> the cpu supports avx2, unlike yours :-p [03:59:08 CET] <BBB> there are no macbook pros with avx2 [03:59:18 CET] <BBB> er [03:59:22 CET] <BBB> there are no mac pros with avx2 [03:59:27 CET] <jya> no? [03:59:49 CET] <BBB> cat /proc/cpuinfo|grep -i avx2 [03:59:50 CET] <BBB> ? [04:00:03 CET] <BBB> or as a control: cat /proc/cpuinfo|grep -i avx [04:01:06 CET] <jya> ah right [04:02:17 CET] <BBB> sorry [04:02:28 CET] <BBB> good excuse to get a new macbook pro? ;) [04:02:35 CET] <jya> gonna see the difference on my laptop (i-6700hq) [04:02:53 CET] <jya> I have a gigabyte laptop with the same processors as in the new macbook pro [04:03:04 CET] <jya> and twice the battery size for almost the same weight :) [04:04:14 CET] <BBB> nice [04:04:27 CET] <jya> (gigabyte aero 14) [04:08:02 CET] <rcombs> above the FAA limit? [04:36:21 CET] <jya> rcombs: nope, just under [04:37:07 CET] <jya> I doubt anyone would ever check anyway. I've taken my electric unicycle on board once (260Wh battery) [04:40:12 CET] <rcombs> there are two limits [04:41:01 CET] <rcombs> one that you can only have 2 of beyond (100Wh), and one that you can't have any of beyond (160Wh) [04:41:46 CET] <rcombs> you're right that nobody checks individual packs, but selling things with batteries past the limit is liable to get you some questions from regulators [04:55:54 CET] <cone-763> ffmpeg 03James Almer 07master:42ae9c66545e: fate: update fate-source ref file [04:57:21 CET] <jamrial> philipl, BtbN: pushed the above fix for fate-source since it was painting the whole fate page yellow [05:15:09 CET] <Compn> do any of you take precautions for the possibility of a cell phone battery burning a hole near your sensitive parts ? [05:15:26 CET] <Compn> like removable pockets or fire extinguisher ? [05:19:14 CET] <rcombs> I own fire extinguishers, but don't really take specific precautions against phone fires [05:19:27 CET] <rcombs> they're so extremely unlikely unless you own a Samsung [05:19:46 CET] <rcombs> far less likely than any number of other household fire scenarios [05:19:55 CET] <rcombs> (yes I know it's not all Samsung models) [05:19:57 CET] <Compn> i hear garage fires are common [05:20:09 CET] <Compn> due to automobile fires [05:20:21 CET] <rcombs> yup [05:20:26 CET] <rcombs> you get a lot due to smoking materials [05:20:29 CET] <Compn> faulty wiring too [05:20:36 CET] <rcombs> often those are literal trash fires [05:20:47 CET] <rcombs> kitchen fires are the most common, though [05:21:34 CET] <rcombs> you get a few per year due to candles [05:22:02 CET] <rcombs> Compn: http://www.nfpa.org/~/media/images/research/report-page-graphics/homestruct… [05:22:54 CET] <rcombs> cooking equipment fires are relatively unlikely to kill you, since you tend to be alert and in the room when it starts [05:23:01 CET] <rcombs> and thus in a good position to put it out [05:23:45 CET] <rcombs> smoking or heating equipment fires kill more people because they often go up while people are asleep, and/or start in a different room [05:24:39 CET] <rcombs> btw, for li-ion fires, ABC dry-chem might do the job, but it's not always reliable in that scenario, and your best bet is dowsing with water [05:24:54 CET] <rcombs> CO2 is not likely to be effective there [09:38:04 CET] <wm4> wat.... https://github.com/kuscsik/FFmpeg/commit/2e260e4e8e5432d44551c0923cc59bda69… [09:40:19 CET] <wm4> (this adds a macro-block packed "nv12t" pixfmt for v4l) [12:15:47 CET] <Kuroe> is h261 always 4:2:0 only? [12:17:53 CET] <jkqxz> Yes. [12:20:54 CET] <thardin> so it seems [12:22:52 CET] <thardin> aw, firefox doesn't support h.261 [13:10:47 CET] <wm4> trying to come up with a way to make libswresample do better upmix [13:10:59 CET] <wm4> by adding data from other channels, instead of just silence [13:11:22 CET] <wm4> but it's complicated [13:11:46 CET] <nevcairiel> upmixing is hard [13:11:50 CET] <wm4> especially because upmix and downmix can happen at the same time [13:11:52 CET] <nevcairiel> just copying channels sounds rather weird [13:12:17 CET] <wm4> I thought about doing the same thing that downmix does [13:12:20 CET] <nevcairiel> any good upmixers use more smart tools [13:12:27 CET] <wm4> aha [13:12:41 CET] <wm4> such as? [13:14:22 CET] <nevcairiel> phase shifts at least [13:15:12 CET] <wm4> huh, what for [13:17:49 CET] <nevcairiel> as if i fully understand the audio theory, i just know that copying stereo into other channels sounds odd and doesn't give much of an impression of surround [13:19:58 CET] <wm4> the question is whether it's better or worse than just silence [13:20:06 CET] <nevcairiel> imho worse [13:20:07 CET] <nevcairiel> :) [13:20:17 CET] <cbsrobot_> wm4: I guess you already saw http://forum.doom9.org/archive/index.php/t-152034.html [13:21:01 CET] <cbsrobot_> I tried all the profiles Selur posted and in general the grezen is satisfying [13:21:26 CET] <nevcairiel> arent they mostly posting downmix profiles there [13:21:40 CET] <cbsrobot_> just search for "grezen" on this page and you will see the sox example [13:23:41 CET] <nevcairiel> at least there is a delay in those conversions, that makes it sound a bit more real [13:24:27 CET] <nevcairiel> but its not something swr can do [13:24:31 CET] <wm4> durandal_1707: well, there you have a filter request ^ [13:26:09 CET] <nevcairiel> you can probably do that with complex lavfi things [13:26:11 CET] <nevcairiel> just not in one filter [13:27:37 CET] <wm4> now if only lavfi had something like functions that can build certain filter sub-graphs [13:27:45 CET] <wm4> instead of this inflexible madness [13:31:33 CET] <wm4> I suppose one could just create a filter which creates a "private" second filter graph [13:40:35 CET] <Kuroe> wm4: lavfi lavfi filter! [13:47:32 CET] <wm4> I mean lavfi doesn't have a good separation between use cases (what a user wants to do to a video) vs. low level mechanism (what filters actually do) [13:47:42 CET] <wm4> so you end up with ridiculous filter graph strings [13:48:06 CET] <wm4> just to do something which should be simple [13:54:53 CET] <durandal_1707> wm4: i did smth like that, private filtergraph filter, named it conditional [14:09:50 CET] <durandal_1707> those up mixes on doom9 use reverbs [15:37:19 CET] <MZ_> Hello, I have a question about x264. the absence of references and documentation take me here. Can I ask you here? I know it is off-topic but I do not know where can I ask (on #x264 noone answered me) [15:37:44 CET] <MZ_> I cannot understand what the last parameter of x264_encoder_encode funciton is for. ( x264_picture_t* pic_out ) thank you in advance [15:46:25 CET] <BBB> I think its the reconstructed image [15:47:28 CET] <MZ_> BBB, but I've the original image and I'm encoding it. Why I need to have back again the same image? [15:47:45 CET] <iive> it might be optional [15:47:46 CET] <BBB> it gives you the pts/dts/poc of the output image [15:47:48 CET] <bencoh> you'd still need it to get the dts [15:47:53 CET] <BBB> it allows you to do encoder/decoder comparison [15:47:59 CET] <iive> aka, if you want to check how much uglier is the encode [15:48:02 CET] <BBB> theres a whole bunch of reasons why youd want the output [15:48:06 CET] <bencoh> (or opaque, or any field that you might need) [15:49:11 CET] <MZ_> ok, so it can be the decompressed ( compressed ( originalImage ) ) ? and isn't it more time consuming? [15:49:23 CET] <kierank> No because the encoder is doing it anyway [15:49:32 CET] <MZ_> ok, thank you a lot! [15:49:34 CET] <kierank> In order to use the exact reference frame [15:49:50 CET] <BBB> pic_out is indeed decompress(compress(original_image)) [15:49:58 CET] <BBB> but without having to do the decompression manually [15:50:03 CET] <BBB> since the encoder already had to do it anyway [15:50:23 CET] <BBB> it also sets frametypes (is_keyframe) etc. if youre interested in that for container purposes [15:50:46 CET] <BBB> (pic_out->b_keyframe) [15:52:45 CET] <MZ_> ok, and I've another question. Encoding in H.264 it may be the case that some frame exploit information redundancy with future frame. How it can be possible that anytime I call the encoder_encode function it generates the encoded data? [15:53:21 CET] <nevcairiel> it doesnt [15:53:36 CET] <nevcairiel> if you use a mode that would use future data, it would d elay output [15:54:09 CET] <MZ_> oh ok, but the output remain ordered? [15:54:20 CET] <nevcairiel> yes [15:54:28 CET] <nevcairiel> in decoding order, not input order [15:55:02 CET] <bencoh> (meaning input order != encoded order) [15:55:16 CET] <MZ_> yes, I'm thinking about that now... [15:55:32 CET] <bencoh> (which is why dts != pts, btw) [15:55:38 CET] <nevcairiel> when you decode, you get the same order back from the decoder as your input images used to be [15:55:46 CET] <nevcairiel> in the middle between those, there can be reordering [15:58:39 CET] <MZ_> I'm a little confused. On the web i found this snippet: http://pastebin.com/TxvXHx8j each time this function is called, a frame is decoded. This is only because the parameters are setted so that no interFrame redundancy is exploited? [15:59:33 CET] <BBB> if !frame_finished return false [15:59:49 CET] <BBB> so if you decode frame 0, then frame 2, on frame 2, frame_finished will be false and no frame was output [16:00:03 CET] <BBB> then when frame 1 is decoded, it will return frame 1, and then later on subsequent calls it will actually return frame 2 [16:00:08 CET] <BBB> (which was cached internally) [16:00:21 CET] <BBB> this is called delay :) [16:00:37 CET] <funman> so i guess no other changes are needed [16:00:37 CET] <MZ_> ok, it was quite simple. sorry [16:00:49 CET] <funman> hm this is not my shell window, is it? [16:01:39 CET] <MZ_> ok, thank you a lot! [16:02:39 CET] <MZ_> you've really helped me. but why there is not a documentation? [16:03:13 CET] <BBB> its an opensource project [16:03:20 CET] <wm4> BBB: no excuse at all [16:03:27 CET] <kierank> x264.h is heavily documented [16:03:37 CET] <BBB> kierank: pic_out is undocumented :-p hes right [16:03:38 CET] <wm4> ok, user error [16:03:43 CET] <wm4> ok, not user error [16:03:46 CET] <BBB> :D [16:04:01 CET] <wm4> if you can't take 1 minute to document your API your API is probably shit [16:04:22 CET] <BBB> MZ_: wm4 is right, its not a valid excuse, but as a practical matter, youll often find that not all opensource projects have excellent documentation; Im not saying thats how it should be, Im jut saying thats unfortunately how it is [16:04:23 CET] <wm4> (too complicated, does too many things, does nothing well-defined, etc.) [16:04:38 CET] <BBB> MZ_: if you want to contribute to x264 and fix/improve their documentation, I think theyd really appreciate it [16:05:29 CET] <MZ_> heavily documented.... looking in encoder_encode function you will not find that you have to copy the nals before recall the function. It is written in the struct definition.... I damn for it XD [16:07:14 CET] <MZ_> BBB, yes but maybe i need to study a lot for doing that... I know nothing about that :( [16:07:38 CET] <BBB> a small patch to add copy nals and pic_out is for & wouldnt require too much study [16:07:45 CET] <BBB> Im not saying fix everything; just fix this small thing [16:08:43 CET] <MZ_> BBB, yes you're right. I'll do it! [16:09:39 CET] <bencoh> I suppose most people willing to use x264 end up reading either x264 implementation or other projects (ffmpeg, vlc, ...) wrapper code ... [16:09:53 CET] <kierank> x264.c [16:09:53 CET] <bencoh> (I personally did back then) [16:09:57 CET] <bencoh> kierank: yeah :) [16:10:13 CET] <kierank> but x264.c is quite complex actually [16:13:39 CET] <BBB> MZ_: cool! tnx [16:13:58 CET] <wm4> bencoh: just like most people trying to use the ffmpeg API will probably look at some other project [16:14:03 CET] <wm4> or try to use the broken ffmpeg examples [16:14:14 CET] <BBB> and then scream on stackoverflow that its not working [16:15:18 CET] <wm4> these stackoverflow posts will get old fast [16:20:08 CET] <MZ_> is there a way to know, foreach nal, at what frame refers to? suppose I've a counter that count all input frames [16:21:32 CET] <kierank> pts [16:21:47 CET] <kierank> and perhaps i_frame, if that's still there [16:22:01 CET] <kierank> i think I use the opaque flag for that [16:24:08 CET] <MZ_> I'm looking at x264_nal_t struct. where can I see the opaqueFlag? [16:29:15 CET] <bencoh> wm4: indeed [16:29:25 CET] <BBB> MZ_: x264_picture_t->opaque [16:30:25 CET] <MZ_> so, first I set the opaque in the picture_t and than, after decoding, I will have the flag again? [16:31:10 CET] <bencoh> yup [16:31:46 CET] <bencoh> (but that part is actually documented in .h ;) [16:34:18 CET] <MZ_> bencoh, I found this: /* private user data. copied from input to output frames. */ void *opaque; [16:34:26 CET] <MZ_> but how many bytes can I use? [16:34:39 CET] <bencoh> the opaque is the pointer [16:34:56 CET] <bencoh> the void* is copied. not the pointed data [16:37:01 CET] <MZ_> but... the sizeof(void*) is platform dependent... I'm confused about that [16:37:18 CET] <nevcairiel> does that matter? you know the size on your platform [16:37:38 CET] <nevcairiel> its always the size of a pointer, so you can allocate whatever much data you need to pass [16:38:24 CET] <MZ_> ok, so if I use ffmpeg to decode, how can I read that value whatever size it have? [16:40:01 CET] <nevcairiel> i dont know whats so confusing about that, its a pointer to data you allocated, so you would know how to read it [16:40:50 CET] <nevcairiel> and it doesnt get passed through to the decoder [16:41:00 CET] <nevcairiel> its only for encoding [16:41:22 CET] <nevcairiel> you pass it in x264_picture_t, and when you get the picture back out in an encoded form, the same value is given to you [16:41:37 CET] <nevcairiel> so you c ould use it to associate some extra data with the picture and have x264 track it for you [16:42:02 CET] <MZ_> ah! I was looking for a something to know, foreach nal at what frame belong. Because I need it on the receiver side [16:42:36 CET] <MZ_> also, in the frame is good. But I need it on the receiver machine [16:42:51 CET] <nevcairiel> it doesnt go into the encoded image, no [16:44:02 CET] <MZ_> so there is not a way to add some kind of information to be sent to the decoding machine? [16:44:30 CET] <kierank> there is poc [16:44:45 CET] <kierank> but identifying frame is out of scope [16:45:29 CET] <MZ_> where can I find something about poc? (i looked in the x264.h but I didn't find it) [16:46:15 CET] <kierank> it's a bitstream field [16:46:26 CET] <kierank> there's also timecode but we don't implement that [16:48:08 CET] <MZ_> kierank, what does it means "it's a bitstream field"? sorry but I've missed the meaning [16:48:23 CET] <kierank> there is a field in the h264 data stream that's an incrementing counter [16:48:41 CET] <kierank> but frame identification is something you should do somewhere else [16:50:09 CET] <MZ_> ok, now I will start coding without taking into account this problem. I will look at that later, thank you again [19:03:59 CET] <cone-728> ffmpeg 03Paul B Mahol 07master:b96a6e2024fa: avfilter/vf_zscale: add support for some recent new additions [20:52:31 CET] <philipl> BtbN: My change broke the transcoding. Setting the pix formats in the callback is too late. [20:52:41 CET] <philipl> Not sure what the solution should be. [20:52:56 CET] <BtbN> it worked when I tested it? [20:53:06 CET] <philipl> What can I say. [20:55:04 CET] <BtbN> hm, doesn't the pre-parser already give information about the bit depth? [20:55:09 CET] <BtbN> So it is already known at init time? [20:56:12 CET] <philipl> It's more subtle than that. [20:56:20 CET] <philipl> The sw_pix_fmt doesn't need to be right. [20:56:31 CET] <philipl> I'm not sure what the minimum set of information required is yet. [20:56:58 CET] <BtbN> so it is enough to decide wether it is CUDA frame output or not? [20:57:14 CET] <philipl> I think so [20:57:45 CET] <BtbN> so just call ff_get_format in init, with only NV12 as option, and it will upgrade to a 10 bit format later on [20:57:50 CET] <philipl> The hw sub fmt set in ffmpeg_cuvid decides on NV12 [20:57:56 CET] <philipl> Yes. That's what I think will work [20:58:53 CET] <BtbN> also keep in mind the hack ffmpeg_cuvid.c does [20:59:08 CET] <BtbN> it hardcodes the sw_format to NV12, so that's what filters and stuff might expect [20:59:19 CET] <philipl> Yes, the hack is the thing that actually controls it. [20:59:27 CET] <philipl> If I change the hack to P010, I can do 10bit->10bit transcoding. [20:59:49 CET] <BtbN> do we already know the bit depth at the time it sets it to NV12? [21:00:04 CET] <philipl> Dunno. I need to see when the callback fires relative to that. [21:08:45 CET] <cone-728> ffmpeg 03Michael Niedermayer 07release/3.2:e9f3cc7fc784: avcodec/ass_split: Change order of operations in ass_split_section() [21:08:46 CET] <cone-728> ffmpeg 03Michael Niedermayer 07release/3.2:dff4f58107cd: avformat/mpeg: Adjust vid probe threshold to correct mis-detection [21:12:27 CET] <jkqxz> BtbN: Do you have any interest in the VAAPI H.265 scaling list patch from yesterday? (You wrote that file.) If not, I would just apply it as-is - it works on Skylake for me. [21:13:38 CET] <BtbN> https://patchwork.ffmpeg.org/patch/1380/ this? [21:13:53 CET] <BtbN> ah, no, that's the encoder. [21:14:19 CET] <BtbN> ah, this: https://patchwork.ffmpeg.org/patch/1526/ [21:15:21 CET] <philipl> BtbN: So, the decoder won't know the underlying format until the callback, and that happens inside the first decode_packet call. That's way to late for transcode initialization. By that point, nvenc has already allocated its surface pool. [21:15:41 CET] <BtbN> So that's what was wrong with SLIST content, interesting. [21:15:56 CET] <BtbN> jkqxz, yeah, feel free to apply. [21:16:56 CET] <philipl> BtbN: Hmm. So nvenc_register_surface looks like its being lazy. [21:17:02 CET] <philipl> reg.bufferFormat = ctx->surfaces[0].format; [21:17:15 CET] <philipl> Why not map from the frame's actual format? [21:17:53 CET] <jkqxz> BtbN: Ok, will do soonish. Thank you! [21:21:12 CET] <BtbN> philipl, because it was written before that would have made sense, as it was allways NV12 [21:32:07 CET] <philipl> BtbN: So, roughly speaking, that register_surface call should get the sw_format from the frames_ctx. That value is correct today. [21:32:22 CET] <philipl> In practice, it doesn't immediately work if the ffmpeg_cuvid.c value isn't the same. Dunno why yet [21:35:14 CET] <philipl> the answer to that is likely the profile init. That looks at the pix_fmt early when it's not necessarily correct. [21:36:38 CET] <philipl> Yeah. so the value in ffmpeg_cuvid.c dictates the profile, I think. And then if the frames are mismatched later, you get an 'invalid param' error back at registration time [21:37:04 CET] <philipl> also setting of pixelBitDepthMinus8 [21:44:05 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/5d621f439885397245ef185e0e95fa65a5… [21:44:14 CET] <philipl> That fixes the regression. Doesn't help make 10bit transcode work [21:45:19 CET] <BtbN> does the sw path still work, with switching to a non-NV12 format later on? [21:45:49 CET] <philipl> Yes. I've tried it out. I can do a 10bit transcode without hwaccel (with or without that change) [22:07:11 CET] <BtbN> I guess it's the best solution for now. But does the h264/hevc parser not write the information about the bit depth somewhere, so it can just be used directly? [22:07:57 CET] <nevcairiel> you cant rely on input data [22:08:12 CET] <nevcairiel> h264/hevc can be called without anything set [22:08:37 CET] <BtbN> you can't rely on it, but you can use it was hint for the initial format [22:08:43 CET] <BtbN> *as [22:08:46 CET] <nevcairiel> seems ugly [22:08:49 CET] <nevcairiel> fix ffmpeg.c instead [22:08:50 CET] <nevcairiel> :D [22:15:52 CET] <atomnuker> BBB: I'll send a new patch to remove ffserver soon [22:16:09 CET] <BBB> I dont think the patch is the issue [22:16:15 CET] <BBB> the issue is people keep bikeshedding the patch [22:17:45 CET] <durandal_1707> it's awesome feature every body understand [22:19:14 CET] <llogan> it's a dingleberry that we just can't shake [22:20:21 CET] <atomnuker> BBB: only reynaldo did [22:21:12 CET] <philipl> BtbN: You could, of course, make it the user's problem and add an explicit command line option. [22:22:19 CET] <BtbN> Nah [22:23:13 CET] <philipl> You good for me to push the regression fix? [22:23:21 CET] <BtbN> yep [22:23:30 CET] <BtbN> For now it at least gets working what worked before [22:23:35 CET] <philipl> Yep [22:23:53 CET] <cone-728> ffmpeg 03Philip Langdale 07master:dd10e7253abf: avcodec/cuvid: Restore initialization of pixel format in init() [22:25:09 CET] <philipl> BtbN: we might need to restructure nvenc to push as much initialization as possible to when the first frame is received. [22:25:53 CET] <BtbN> hmm [22:26:07 CET] <BtbN> I'll have a look at that stuff tomorrow, don't really have too much time right now. [22:26:21 CET] <philipl> sure [22:36:21 CET] <cone-728> ffmpeg 03Wan-Teh Chang 07master:29fb49194bed: avutil/cpu: remove the |checked| static variable [22:36:22 CET] <cone-728> ffmpeg 03Wan-Teh Chang 07master:d84a21207ea8: avutil/tests: Add cpu_init.c to check whether the one-time initialization in av_get_cpu_flags() has data races. [22:40:10 CET] <cone-728> ffmpeg 03Jun Zhao 07master:584eea5bf3e4: lavc/vaapi_hevc: fix scaling list duplicate transfer issue. [23:07:48 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/c16a86222f611efda85d7ec46e0439182c… [23:08:30 CET] <BtbN> oh, nice. When did they get rid of that? [23:16:12 CET] <philipl> I guess in 7.0 [23:16:20 CET] <philipl> although I'm only testing now with 7.1 (375.xx) [23:16:29 CET] <philipl> if you're still running on a 7.0 driver, you could check. [23:17:29 CET] <BtbN> 375 everywhere as well [23:17:35 CET] <philipl> oh well. [23:17:58 CET] <philipl> It seems like the kind of change you'd make in a major update :-P [23:18:23 CET] <BtbN> I'd send it to the ML, as the people who originally introduced might want to say something about it. [23:18:27 CET] <BtbN> +it [23:18:43 CET] <philipl> As in the nvidia folks? I added the de-compensation code originally. [23:18:57 CET] <BtbN> Wasn't that quite a bit of discussion originally? [23:19:13 CET] <BtbN> Don't remember who participated anymore [23:19:36 CET] <philipl> yes, but that was around whether it was right to de-compensate in a decoder as a matter of principle. I won out pointing out that the compensation in the deocder was equally inappropriate. [23:20:30 CET] <philipl> anyway, I'll send it. Doubt we'll see a response. [23:21:03 CET] <BtbN> Yeah, should be fine to push in a day or two. [23:31:02 CET] <jya> BBB: i know it's not your code, but if there's one who knows it you :) Still about the vp9 alpha channel. You mentioned that libvpx simply took both data (plain and alpha) and simply output a decoded yuva [23:31:22 CET] <jya> but the vpx_codec_decode simply takes a pointer to the data+size. [23:32:39 CET] <jya> oh it seems it's just how the libvpx ffmpeg decoder does it [23:43:02 CET] <nevcairiel> iirc the alpha part was added by the google guys to our libvpx wrapper [23:43:08 CET] <nevcairiel> but yeah its handled in there, not in vpx [23:52:31 CET] <BBB> jya: yes, thats what I meant [23:52:55 CET] <BBB> jya: so if you see ffvp9 as equivalent to libvpx, then the fflibvpx wrapper is what firefox should do to get the alpha channel, if that makes any sense ;) [23:53:38 CET] <jya> BBB: yeah, we only use ffmpeg to use with ffvp9. We have a separate libvpx decoder that uses it directly [23:54:14 CET] <BBB> dont you use ffvp8 and fftheora also? [23:55:01 CET] <jya> nope [23:55:10 CET] <jya> oh, we do use ffvp8 [23:55:17 CET] <BBB> I thought so [23:55:19 CET] <jya> we use libtheora directly [23:55:23 CET] <BBB> oh [23:55:34 CET] <BBB> well, I dont know how ffmpegs theora decoder compares to libtheora TBH [23:55:43 CET] <BBB> I mean, that format is so old, I wouldnt mind if it just died :-p [23:55:54 CET] <jya> remember that all those decoders (opus, libvpx, openh264, vorbis etc) long predate our use of ffmpeg [23:55:59 CET] <BBB> yeah [23:56:14 CET] <jya> and we still use libvpx for webrtc [23:56:18 CET] <BBB> right [23:56:35 CET] <BBB> I wish I could be bothered to write reference frame management and error resilience/recovery in ffvp8/9 [23:56:37 CET] <jya> the webrtc folks had concerned about latency in ffvp9 as we only use it in multi-threaded mode [23:56:56 CET] <BBB> ffvp8 implements slice threading, so thats just a setup thing [23:57:01 CET] <BBB> ffvp9 doesnt implement tile threading yet [23:57:39 CET] <jya> I'd be keen to remove libvpx alltogether [23:57:41 CET] <BBB> but obviously right now libvpx is the tested baseline [23:57:45 CET] <BBB> you need an encoder [23:57:52 CET] <jya> maintaining two sets of code to do a similar thing is a bit silly [23:57:57 CET] <jya> and that [23:58:12 CET] <jya> i mean maintaining two code path [00:00:00 CET] --- Thu Nov 24 2016

1 0

ffmpeg.log.20161123
by burek 24 Nov '16

24 Nov '16

[00:00:17 CET] <furq> i can tell you what my favourite tetris piece is though [00:00:23 CET] <kerio> http://cdn.bulbagarden.net/upload/7/74/722Rowlet.png http://cdn.bulbagarden.net/upload/d/d8/728Popplio.png [00:00:48 CET] <markvandenborre> :-) [00:00:57 CET] <kerio> popplio = retarded clown seal [00:01:04 CET] <kerio> rowlet = cute spherical owl [00:01:04 CET] <furq> i did a google image search for "l block" and the first match is a j block [00:01:09 CET] <furq> fucking sort it out google [00:01:40 CET] <kerio> hey furq [00:01:45 CET] <kerio> i have another question for you [00:02:01 CET] <furq> what is it my nephew [00:02:08 CET] <kerio> has anyone really been far even as decided to use even go want to do look more like? [00:02:12 CET] <furq> yes [00:02:31 CET] <furq> george stockliffe did it in 1907 [00:05:56 CET] <markvandenborre> somehow, I feel this is not the time for more questions from me :-) [00:06:10 CET] <markvandenborre> thanks a lot, all, and have a good night! [00:06:34 CET] <markvandenborre> (or whatever time of day it is at your place) [00:57:29 CET] <markvandenborre> ok, couldn't sleep, so here I am again [00:58:02 CET] <markvandenborre> mediainfo shows relevant info about an flv file that ffmpeg says "protocol not found" about [00:59:14 CET] <saintgermain> On Debian Stable with ffmpeg 3.2.2, I tried the command "ffmpeg -hwaccel vaapi -i castle.mp4 -f null -" and it works without problem. But with ffmpeg static (3.2 or git) I have a bunch of errors "No VA display found for device: ." and "Failed to create a VAAPI device". Did I use hwaccel incorrectly or is it a regression ? [00:59:20 CET] <markvandenborre> I did the same with this flv as I did before with an mp4: kill -9 the process that feeds the nginx-rtmp server [00:59:54 CET] <markvandenborre> is there a way to force ffmpeg to use a specific protocol to handle this file? [01:00:08 CET] <markvandenborre> mpv plays it back without a glitch [01:00:51 CET] <markvandenborre> vlc too [01:01:12 CET] <markvandenborre> the ff* suite doesn't find protocol info [01:02:25 CET] <markvandenborre> obviously, enough information is present in the file to play it back to the same extent as other players than ffplay [01:03:55 CET] <markvandenborre> ok, that was a dumb question of mine [01:10:37 CET] <FlyingIT> hello community! is anyone around who has set up a raspberry pi 3 to stream to twitch with ffmpeg? I've been trying to get it work for a few days now, closest I got was to get it to stream with speed=0.5x, so not quite... [01:18:37 CET] <markvandenborre> FlyingIT: https://datarhei.github.io/restreamer/ [01:18:46 CET] <markvandenborre> might help? [01:18:53 CET] <markvandenborre> as inspiration I mean [01:20:59 CET] <saintgermain> On Debian Stable with ffmpeg 3.2.2, I tried the command "ffmpeg -hwaccel vaapi -i castle.mp4 -f null -" and it works without problem. But with ffmpeg static (3.2 or git) I have a bunch of errors "No VA display found for device: ." and "Failed to create a VAAPI device". Did I use hwaccel incorrectly or is it a regression ? [01:25:02 CET] <jkqxz> saintgermain: libva does not work when statically linked. [01:25:38 CET] <saintgermain> jkqxz: so I cannot use the ffmpeg static and I have to compile myself ? [01:29:32 CET] <jkqxz> You must be dynamically linked to libva. That doesn't necessarily mean you have to compile it yourself on the target system (after all, the Debian version does work), but in practice it may be the only way of using a specific version. [01:31:07 CET] <FlyingIT> hey markvandenborre thanks for the link!! You know what, I just changed the fps to half of before and then the speed issue got resolved. I can't believe it was such a simple fix. Wow, I really could have thought about that earlier... [01:31:33 CET] <saintgermain> jkqxz: Ok thanks ! [01:31:56 CET] <FlyingIT> But often even just asking helps find the solution :D [01:31:56 CET] <furq> FlyingIT: what command are you using [01:36:03 CET] <FlyingIT> oh wow, the datarhei restreamer looks cool running on docker! [01:36:24 CET] <FlyingIT> furq hold on; I'll write it, 1mo [01:40:53 CET] <markvandenborre> this is strange... [01:41:58 CET] <FlyingIT> the basic one I got to work now is: [01:41:59 CET] <FlyingIT> ffmpeg -thread_queue_size 1024 -f v4l2 -r 15 /dev/video0 [01:42:47 CET] <markvandenborre> my debian stable server recognises the .flv file that my debian testing desktop complains about with "protocol not found" [01:43:05 CET] <markvandenborre> both are using _very_ similar versions of ffmpeg it seems [01:43:22 CET] <markvandenborre> (my server a backported package from testing) [01:44:33 CET] <markvandenborre> 7:3.2-2 on testing versus 7:3.2-2~bpo8+2 for stable with backports [01:44:52 CET] <markvandenborre> (~bpo8+2 meaning a backported version) [01:50:09 CET] <furq> FlyingIT: that doesn't look like a valid command [01:50:20 CET] <furq> markvandenborre: those are identical versions aren't they [01:51:13 CET] <FlyingIT> well I'm running it from a bash file [01:51:30 CET] <FlyingIT> also I'm running Arch Linux, if that makes any difference, wasn't too happy with raspberian [01:51:48 CET] <furq> put echo in front of the command in the script [01:51:59 CET] <FlyingIT> what would this do? [01:52:07 CET] <FlyingIT> *output? [01:52:07 CET] <furq> it'll print the actual command [01:52:12 CET] <FlyingIT> oh, I see [01:52:40 CET] <markvandenborre> furq: looks like it, yes [01:52:52 CET] <furq> what's the filename [01:53:20 CET] <markvandenborre> pingu-23-Nov-16-00:42:19.flv [01:53:44 CET] <furq> i remember [01:53:47 CET] <furq> dsf [01:54:00 CET] <furq> there's some mailing list issue about that error showing up if you have colons in the filename [01:54:21 CET] <furq> apparently it goes away if you prefix the filename with "file:" [01:54:30 CET] <FlyingIT> oh yeah! I had the whole output left out of the command, soz. -vcodec libx264 -pix_fmt yuv420p -acodec libmp3lame -threads 2 -preset ultrafast -f flv -ar 22050 rtmp://$INGEST.twitch.tv/app/$STREAM_KEY" [01:54:40 CET] <furq> yeah don't use x264 on an rpi [01:54:45 CET] <FlyingIT> no? [01:54:52 CET] <furq> there's an onboard hardware h264 encoder which sucks, but it should at least run fast [01:54:53 CET] <markvandenborre> furq: yes, it doesn't [01:55:07 CET] <furq> -c:v h264_omx [01:55:11 CET] <markvandenborre> fall over anymore [01:55:13 CET] <furq> you'll need to compile ffmpeg with it though [01:57:31 CET] <FlyingIT> oh, so h264_omg is preferable, I'll try now. Also I don't quite understand the threads parameter. 2 seem fine, but I'd have thought 4 would be better? [01:58:08 CET] <furq> well on a pi 3 you probably want 6 [01:58:15 CET] <furq> with libx264, anyway [01:58:20 CET] <furq> that option makes no sense with omx [01:58:56 CET] <markvandenborre> furq: you potentially saved us several hours of fiddling [01:59:52 CET] <markvandenborre> and you helped us build something more reliable and _simpler_ for FOSDEM. Thanks a lot! [02:07:02 CET] <FlyingIT> if I use h264_omx I get this warning: [02:07:03 CET] <FlyingIT> Codec AVOption preset (Set the encoding preset (cf. x264 --fullhelp)) specified for output file #0 (/storage/.kodi/userdata/addon_data/service.emby/transcoding-temp/44802c6446da28c773b15182d74143b1.m3u8) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream. [02:07:33 CET] <FlyingIT> The stream works fine though, but that was the reason why I switched back to libx264 [02:08:51 CET] <voip_> hello guys [02:09:20 CET] <voip_> i have problem on ubuntu : bind failed: Permission denied [02:09:54 CET] <voip_> when i trying to execute witout sudo [02:10:36 CET] <furq> you need to be root to bind a port below 1024 [02:11:20 CET] <furq> or you could give ffmpeg CAP_NET_BIND_SERVICE [02:16:52 CET] <FlyingIT> WOW, when I use libx264 the bitrate=~2000kbits/s and with h264_omx it's ~200kbits/s. Does this mean libx has 10x higher upstream? [02:17:03 CET] <voip_> furq, thank you [02:17:09 CET] <furq> no it means they have different defaults [02:17:22 CET] <FlyingIT> oh! hehe, I see [02:17:24 CET] <furq> you need to set -b:v to set the bitrate with omx [02:17:37 CET] <FlyingIT> okay :) [02:17:39 CET] <furq> it'll probably look worse than x264 ultrafast, but it won't touch your cpu [02:17:53 CET] <FlyingIT> omx will look worse? [02:17:57 CET] <furq> yeah [02:18:09 CET] <FlyingIT> but it'll be more stable? [02:18:38 CET] <furq> yeah it's a hardware block on the rpi gpu [02:19:29 CET] <saintgermain> jkqxz: I tried compiling FFmpeg master and "-hwaccel vaapi" works with a reduce CPU load. However I tried compiling FFmpeg branch 3.2, and I got the errors "No VA display found for device: ." and "Failed to create a VAAPI device". In addition "-hwaccel vaapi" works on Debian FFmpeg 3.2.2, but the CPU load is really heavy. Something strange is going on. Any idea ? [02:19:31 CET] <FlyingIT> okay nice! And does the one warning I get when using omx mean anything? [02:19:37 CET] <furq> what warning is that [02:19:49 CET] <FlyingIT> Codec AVOption preset (Set the encoding preset (cf. x264 --fullhelp)) specified for output file #0 (/storage/.kodi/userdata/addon_data/service.emby/transcoding-temp/44802c6446da28c773b15182d74143b1.m3u8) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream. [02:19:57 CET] <furq> oh [02:20:01 CET] <FlyingIT> forget the kodi part [02:20:02 CET] <furq> you're specifying an option which doesn't do anything [02:20:20 CET] <FlyingIT> I copied that from somewhere, but the error is pretty much the same [02:20:29 CET] <furq> probably -preset ultrafast [02:20:34 CET] <furq> just get rid of that [02:20:43 CET] <furq> oh yeah it says it's preset [02:20:45 CET] <FlyingIT> oh, yeah. That's only needed for libx264 [02:21:05 CET] <furq> also you probably want to use aac for streaming over rtmp [02:21:15 CET] <FlyingIT> oh yeah xD. I thought it meant something with preset... Getting late here I suppose :) [02:21:25 CET] <furq> and there's no reason to use 22khz unless you're starved for bandwidth [02:21:43 CET] <FlyingIT> for the audio you mean? [02:21:55 CET] <furq> y [02:21:56 CET] <FlyingIT> and I'd have to check if twitch takes aac [02:22:09 CET] <furq> it should [02:22:14 CET] <FlyingIT> just a mo [02:26:04 CET] <FlyingIT> so instead of '-acodec libmp3lame' it's '-acodec aac'. Not complaining and streaming fine :) [02:26:22 CET] <FlyingIT> furq do you stream stuff? [02:31:24 CET] <furq> not regularly [02:32:42 CET] <FlyingIT> same here [02:37:34 CET] <markvandenborre> furq: wasn't libfdk_aac considerably faster and better quality too? [02:37:48 CET] <markvandenborre> (although that might require a recompile of the source package with the option enabled) [02:38:00 CET] <markvandenborre> FlyingIT: might be interesting to you [02:38:04 CET] <furq> idk about faster but it is higher quality [02:38:10 CET] <furq> but yeah it's nonfree so it needs a rebuild [02:38:40 CET] <FlyingIT> does nonfree mean you need a licence or you need to rebuild your ffmpeg? [02:38:50 CET] <furq> it means you can't distribute binaries with fdk linked in [02:39:03 CET] <furq> you technically need a license for a lot of ffmpeg encoders but nobody cares unless you're making money from it [02:39:25 CET] <FlyingIT> hehe, okay. Makes sense! ^^) [02:45:02 CET] <shout> Greetz, is there an api or best practices available for a non CLI way to define ffmpeg's inputs? Looking for source or docs. Thanks in advance. [02:46:49 CET] <c_14> https://ffmpeg.org/doxygen/trunk/index.html https://ffmpeg.org/doxygen/trunk/examples.html [02:50:40 CET] <saintgermain> Debian ffmpeg (3.2) and ffmpeg github checkout "master" have working vaapi hwaccel (but Debian ffmpeg is very slow). Static ffmpeg "git", static ffmpeg "3..2" and ffmpeg github checkout "3 [02:51:18 CET] <saintgermain> Debian ffmpeg (3.2) and ffmpeg github checkout "master" have working vaapi hwaccel (but Debian ffmpeg is very slow). Static ffmpeg "git", static ffmpeg "3..2" and ffmpeg github checkout "3.2" gives error "No VA display found for device: .". Has somebody an explanation ? [02:55:07 CET] <c_14> Didn't somebody just tell you that libva doesn't work when statically linked? [02:56:24 CET] <saintgermain> c_14: indeed but I tried compiling FFmpeg 3.2 myself and it doesn't work either. However compiling FFmpeg master works. So there is something else going on. [02:56:59 CET] <c_14> Then open a bugreport? [02:57:18 CET] <c_14> Sounds like something was fixed and not backported [02:57:56 CET] <saintgermain> c_14: But FFmpeg 3.2 from Debian works (albeit slow). That's what is puzzling me. [02:58:19 CET] <c_14> same build configuration? [02:58:22 CET] <c_14> same subversion? [02:58:27 CET] <c_14> does debian patch their release? [02:59:13 CET] <saintgermain> c_14: good idea, I don't know, I'll check ! [03:01:25 CET] <saintgermain> c_14: nothing in the changelog about vaapi except perhaps "Build static libraries without -fPIC as required by policy 10.2" [03:06:08 CET] <FlyingIT> thanks furq for your help! :) I'm almost off too sleep now, cya around o/ [03:06:23 CET] <FlyingIT> have a nice night everyone [03:27:49 CET] <FlyingIT> okay, tried out one more thing. 1 camera running for stream works perfectly, but 2 cameras seem to be too much for the raspberry pi 3... Maybe I'll find a way around this to tweak it, but not tonight xD. [03:28:12 CET] <FlyingIT> Maybe I can set -threads? [03:28:29 CET] <FlyingIT> Anyways, safe! I'm off now for sure [04:12:17 CET] <Sircle> Can anyone help me with this? https://pastebin.mozilla.org/8930716 [07:44:53 CET] <LongChair1> Hello :) [07:45:34 CET] <LongChair1> i found tracks of some v4L2 m2m work for ffmpeg in mailing lists https://ffmpeg.org/pipermail/ffmpeg-devel/2014-November/165630.html [07:45:53 CET] <LongChair1> doesn anyone knows if this work is still going on ? [08:37:20 CET] <Sircle> Can anyone tell how to get all frames via this snippet? This is only getting the first frame http://stackoverflow.com/a/15736494 [09:52:41 CET] <alexvf> hi, is this the right place to ask about ffmpeg libraries usage? [09:52:59 CET] <enyc> alexvf: "Welcome to the FFmpeg USER support channel" [09:53:09 CET] <alexvf> :) [09:53:22 CET] <enyc> alexvf: I don't see why not, but clearly define your question and be patient... I probably can't help but somebody may beable to eventually. [09:53:40 CET] <alexvf> enyc: ok, thank you [09:54:25 CET] <alexvf> i'm trying to write a program that outputs hls preview images [09:54:43 CET] <alexvf> i know i can do it with ffmpeg command directly [09:55:00 CET] <alexvf> but i'm trying to do it more efficiently [09:55:23 CET] <alexvf> basically avoid having to initialize all for each fragment [09:56:10 CET] <alexvf> so i start the program with a fragment, which is detected by avformat_open_input and avformat_find_stream_info [09:56:43 CET] <alexvf> and then i pass other fragments to the program, hopefully not needing another avformat_find_stream_info [09:57:42 CET] <alexvf> but it crash when i try to reuse the AVCodecContext from the previous fragment [09:58:12 CET] <alexvf> is what i want possible at all? [10:00:17 CET] <markvandenborre> alexvf: I have no idea about exactly what you are asking, but... [10:00:30 CET] <markvandenborre> did you have a look at the nginx-rtmp source code for inspiration? [10:01:10 CET] <markvandenborre> it has exactly the functionality you are asking for (at least from an flv container) [10:01:15 CET] <alexvf> no, i started with the famous dranger tutorial, part 1, which outputs a .ppm image and extend it [10:01:39 CET] <alexvf> idoes nginx-rtmp take hls previews? [10:02:04 CET] <markvandenborre> have a look at it, I can't help you any further [10:03:21 CET] <alexvf> ok, thank you [10:03:39 CET] <alexvf> what i want is very easy, but i'm not good explaining myself [10:03:41 CET] <furq> nginx-rtmp isn't based on ffmpeg [10:03:50 CET] <furq> if that matters to you [10:04:07 CET] <alexvf> i have a HLS stream (several fragments) and i want a preview image for each of them [10:04:24 CET] <alexvf> but i want to save preview in a efficient way [10:04:46 CET] <alexvf> if i do it through ffmpeg command it takes more than a second for each one [10:05:12 CET] <alexvf> and i think it could take much less, since i don't event need to download all the fragment, just to the point of decoding a frame [10:06:09 CET] <alexvf> furq: do you mean it does not use ffmpeg? [10:06:27 CET] <furq> it doesn't use the ffmpeg libs for hls [10:06:32 CET] <furq> i also don't think it has an hls demuxer [10:06:43 CET] <furq> it has a muxer but it only takes rtmp input [10:07:13 CET] <alexvf> furq: main problem is that i want to use ffmpeg libraries, that's why i am here :) [10:18:09 CET] <haspden> Hi, whilst installing FFmpeg, I get issues when running the OPUS installer... I took the install code from https://trac.ffmpeg.org/wiki/CompilationGuide/Centos however get the error on the # make line [10:18:33 CET] <haspden> tests/test_opus_decode.c:139: error: #pragma GCC diagnostic not allowed inside functions [10:18:51 CET] <haspden> tests/test_opus_decode.c:140: error: #pragma GCC diagnostic not allowed inside functions [10:18:56 CET] <haspden> tests/test_opus_decode.c:144: error: #pragma GCC diagnostic not allowed inside functions [10:19:08 CET] <haspden> make[2]: *** [tests/test_opus_decode.o] Error 1 [10:19:32 CET] <tdr> youre building all those from source on centos? [10:19:47 CET] <tdr> (all the packages on that page i mean) [10:19:57 CET] <haspden> yea [10:20:07 CET] <tdr> must like pain [10:20:17 CET] <tdr> your centos version may matter, gcc versions change [10:21:18 CET] <haspden> all I want it ffmpeg to run haha but it's taken me all night here ha [10:21:21 CET] <haspden> pain indeed [10:21:39 CET] <haspden> running centos 6 [10:22:04 CET] <tdr> i get it, when useing old old RH i used to rebuild all my media stuff to unbreak it, but it always sucked [10:22:48 CET] <haspden> 6.8 sorry [10:22:48 CET] <spaam> 6!? that is like 5 years old [10:24:23 CET] <haspden> its so frustrating... I want to do something so simple, but have it run server side... seems ffmpeg would be the only way to go however [10:24:41 CET] <haspden> I want to take a jpg and turn it into a video file [10:24:48 CET] <haspden> preferably .mp4 [10:25:07 CET] <haspden> a night of trying to install ffmpeg and i'm still no futher forward haha [10:25:16 CET] <furq> haspden: http://johnvansickle.com/ffmpeg/ [10:44:36 CET] <haspden> well thats far easier [11:57:41 CET] <alexvf> is there a way of setting up an AVCodecContext without calling avformat_find_stream_info? [13:20:30 CET] <JonG> This line in FFmpeg's configure help: https://github.com/FFmpeg/FFmpeg/blob/master/configure#L139 ... Does that mean that by default network support is on or off? I am a bit confused by --disable- paired with [no]. How should I read the output to figure out the defaults? [13:21:24 CET] <BtbN> It's not disabled by default. [13:24:52 CET] <dragmore88> hi. Anyone that could suggest a syntax taking 2 mono channels out from a prores file and encode them to AAC 2 channel ? [13:25:06 CET] <dragmore88> this one fails: [13:25:10 CET] <dragmore88> ffmpeg -i Everest2015_Theatrical_5min_TestClip_HDR_UHD_PRORES.mov -filter_complex "[6:a][7:a]amerge=inputs=2[aout]" -map "[aout]" output.wav [13:25:20 CET] <dragmore88> that was for pcm [13:25:33 CET] <dragmore88> Invalid file index 6 in filtergraph description [6:a][7:a]amerge=inputs=2[aout]. [13:27:14 CET] <JonG> BtnB: Thanks. So what is the significance of "[no]". I.e. how does "--disable-network disable network support [no]" differ from "--disable-dct disable DCT code"? [13:27:25 CET] <JonG> BtbN sorry [13:28:19 CET] <BtbN> from looking at the configure scripts, "network" is just a dummy target that all network protocols like tcp, http, sftp and so on depend on. [13:28:33 CET] <BtbN> So if you want to get rid of all of them at once, you just disable network. [14:26:29 CET] <Guest34390> Hi friends, someone already have problems to encode multiple bitrates using ffmpeg and blackmagic with ubuntu, and using CentOS 7 its works? Same compilation, same hardware, but different distros [14:27:24 CET] <Guest34390> had* [14:28:24 CET] <DHE> no errors displayed? [14:29:04 CET] <DHE> if it's the same binary, you may have problems with shared libraries. maybe get a static build of ffmpeg, or strip the features down to just basic things like glibc and zlib [14:29:13 CET] <Guest34390> yes, the error is: [decklink @ 0x2a187c0] > Decklink input buffer overrun!39kB time=00:00:07.82 bitrate= 41.2kbits/s speed=0.537x [14:30:28 CET] <DHE> at a speed of 53.7% realtime, yeah you're going to have a bad time with realtime processing [14:30:42 CET] <Guest34390> yep :'( [14:31:49 CET] <Guest34390> but with centos its ok! I tryiing to see if there is some tuning that is built in in centOS 7 and isnt in ubuntu... but i not really sure if the main problem is this, I really appreciate suggestions! [14:39:28 CET] <BtbN> Your CPU is too slow for the encode and filter settings you choose. [14:39:37 CET] <BtbN> Either get a faster machine, or use faster settings. [14:40:58 CET] <DHE> or something like a GPU to do accelerated encodnig? [14:46:26 CET] <Guest34390> The hardware in both machines are identical! [14:46:45 CET] <Guest34390> but with centos 7 its works great, but with ubuntu, the problem persist! [15:10:16 CET] <DHE> CPU busy with other things perhaps? [15:10:43 CET] <Guest34390> nope DHE , this machine is only for this usage! [15:11:05 CET] <Mysoft> if i set max bitrate limit...... and set maximum crf, it will reduce framerate (skip frames) to try to achieve the desired bitrate? [15:11:42 CET] <JEEB> depends on the encoder how it deals with "cannot spend bits" [15:11:47 CET] <JEEB> x264 never removes pictures [15:12:02 CET] <JEEB> theora if I recall correctly was infamous for dropping pictures [15:12:21 CET] <Mysoft> i see... that's kinda of a problem [15:12:46 CET] <DHE> hmm.. seems unlikely for a kernel difference to affect CPU usage so dramatically... which might suggest a hwaccel difference between systems? [15:12:48 CET] <Mysoft> i would prefer a framerate drop in cases the encoding is too hard (too much motion) instead of a drop in visual [15:14:35 CET] <Guest34390> we are using libx264 pra vídeo [15:14:52 CET] <Guest34390> and libfdk_aac for audio [15:15:26 CET] <BtbN> there is no hwaccel in decoding and encoding with ffmpeg.c unless it's explicitly requested [15:15:54 CET] <DHE> well, that's software encoding. x264 does have some opencl support, but the effect isn't strong enough to double the speed [15:16:21 CET] <BtbN> isn't it like 3% faster, at best? [15:16:33 CET] <DHE> it does vary. I've seen +20%, I've also seen -10% [15:16:48 CET] <DHE> so, yeah... [15:16:50 CET] <Mysoft> depends on how much the lookahead is necessary :) [15:17:40 CET] <Mysoft> but i think hw accs should be doing more... (not that i would benefit me... since other than cuda/opencl) no other hwacc works here [15:18:15 CET] <Mysoft> unless someone make a shader based x264 encoder :D [15:19:58 CET] <Guest34390> I'm really trying to think how to solve or just tunning ubuntu to run like centOS7 but still haven't worked! [15:20:04 CET] <Guest34390> work* [16:47:21 CET] <persina> what does "-vf scale=7680:4320,setdar=22:9 " mean? [16:50:55 CET] <durandal_1707> rescale and change display aspect ratio [16:52:37 CET] <persina> durandal_1707: If I want to change aspect ratio but not rescale...what would the argument be? [16:56:36 CET] <durandal_1707> just sample aspect ratio? [16:58:22 CET] <JonG> persina: Does this help? https://trac.ffmpeg.org/wiki/Scaling%20(resizing)%20with%20ffmpeg [16:58:34 CET] <skcustibrc> can someone help me understand how to decimate correctly [16:59:26 CET] <skcustibrc> i have a video at 59.940 fps, but it should be 23.940 to have each rame unique [17:16:38 CET] <JEEB> hmm, /21 [17:22:28 CET] <pgorley> hi all, which function do i need to use to apply a filter on a frame? [17:22:39 CET] <pgorley> i'm looking at ffmpeg.c and i can't seem to figure it out [17:23:30 CET] <pgorley> specifically, i'd like to apply format=nv12 and hwupload in that order [17:31:21 CET] <jkqxz> hwupload is quite trivial. Unless you have other filters you want to apply at the same time, it may be simpler to make the hwframe context and transfer directly. [17:36:21 CET] <pgorley> alright, thanks [17:43:11 CET] <kerio> would mpeg2 be preferrable to mjpeg? [17:50:25 CET] <kepstin> kerio: for video? yeah, it supports P/B frames so the result should be quite a bit smaller at the same quality. Obviously it would be better to use a newer coded if possible tho. [17:50:49 CET] Action: kepstin suspects it would be almost the same as mjpeg if used intra-only? [17:51:02 CET] <kerio> kepstin: the issue is encoding cpu time [17:51:15 CET] <kerio> the 3ds is really bad [17:51:36 CET] <kerio> and the wifi chip it uses is also really bad, so you can't go with raw video either [17:52:03 CET] <kepstin> maybe you should look at, i dunno, ffvhuff or something like that? [17:52:33 CET] <kerio> would that really save much, tho [17:53:04 CET] <kepstin> it's really fast, and depending what the video content is it might save a good chunk... [17:53:08 CET] <jkqxz> MJPEG is pretty standard as the easiest thing which still gives enough compression to be usable over a slightly-limited channel. Hence use by every webcam ever, for example. [17:54:17 CET] <Mavrik> Then again, these days most stuff uses H.264 since every SoC and it's mom has a HW encoder [17:57:21 CET] <kerio> sadly, the 3ds has nothing of that sort, and the n3ds only has a h264 decoder [17:57:28 CET] <kerio> otherwise it would've been my first choice [18:03:38 CET] <kepstin> but yeah, i'd expect mpeg2 to be a bit slower than mjpeg since it's doing more work per frame to detect motion, etc - on the other hand, depending on video content, that work can save encoding work later, so... :/ [18:03:59 CET] <kepstin> have to test and see, really [18:04:26 CET] Action: kepstin expects that neither the jpeg or mpeg2 encoders in ffmpeg are well optimized for arm [18:04:50 CET] <kerio> right now this weird thing is using libjpeg i believe [18:05:01 CET] <persina> I have 2 PNG's with 3840x2880 when i try to make a video from them all i get is a black screen...command and output: http://pastebin.com/7XMgBHCQ [18:05:21 CET] <kepstin> kerio: which libjpeg? you probably want to use libjpeg-turbo if possible [18:07:25 CET] <durandal_1707> persina: ffplay plays last two images just fine? [18:08:42 CET] <persina> durandal_1707: Yes. [18:08:56 CET] <persina> durandal_1707: Does my media player have a resolution limit? [18:13:17 CET] <durandal_1707> persina: dunno [19:41:32 CET] <pgorley> how di convert from one pixel format to another using the libav* libs? [20:11:43 CET] <dmfrey> Hi all. Not sure if this is the right channel, but is it possible to use one of the libraries, like libavcodec, through JNI on android to decode mpeg2? [20:12:15 CET] <dmfrey> i can build it and am already using it to play back ac3 audio [20:13:37 CET] <dmfrey> I plan on writing an extion to ExoPlayer (https://github.com/google/ExoPlayer) that will allow my app to provide native mpeg2 ts playback from within my app [21:42:03 CET] <Guest78> hey guys . i have a strange question that i need help with. We're trying to stream live from a linux server. The flow that we use is: start Xvfb, start pulseaudio, start chrome, start ffmpeg to flv to youtube. Now, all is cool, but, when ffmpeg starts exactly after the chrome loaded, there is a 3s delay between the audio and video into the youtube video. And now the strange part: restarting FFMPEG or delaying it's start with let's say [21:42:03 CET] <Guest78> 10s (kind of a buffer for chrome to really fully start) -> 0s delay between audio and video. Any ... ideas ? [23:11:51 CET] <Guest78> http://stackoverflow.com/questions/40774967/ffmpeg-stream-chrome-kiosk-mode… [23:22:58 CET] <Jan-> hihi all [23:23:47 CET] <Jan-> I just had someone from a big video equipment company tell me that Quicktime doesn't define a way to set an aspect ratio. [23:23:59 CET] <Jan-> Surely this is drivel [23:24:04 CET] <Jan-> you can totally do it with -aspect foo [23:24:08 CET] <Jan-> and that will be respected by players [23:26:42 CET] <furq> isn't that set in the h264 sps [23:27:29 CET] <JEEB> there's multiple things [23:28:00 CET] <JEEB> video stream -> PASP -> width/height in whatever video info thing there was in ISOBMFF [23:28:09 CET] <JEEB> and if it's about QTFF then you look at the qtff.pdf [23:28:18 CET] <JEEB> (QTFF being what we usually call MOV) [23:28:45 CET] <Jan-> I don't know what the -aspect option sets, to be honest. [23:28:59 CET] <Jan-> I know that when we set -aspect on *.mov it is respected by VLC, Quicktime and Adobe Premiere. [23:29:04 CET] <furq> whatever -aspect does doesn't show up in ffprobe -show_format [23:29:09 CET] <Jan-> I have no idea. [23:29:12 CET] <JEEB> just saying that there's multiple places aspect ratio can be set in ISOBMFF or MOV [23:29:19 CET] <JEEB> well, MOV I don't know of :P [23:29:24 CET] <JEEB> ISOBMFF I've looked through [23:29:29 CET] <Jan-> I do know that sometimes there's a SAR set in the codec data. [23:29:35 CET] <Jan-> which can be confusing. [23:29:36 CET] <JEEB> yes [23:29:37 CET] <JEEB> https://social.technet.microsoft.com/Forums/windows/en-US/fed910ba-0b25-48f… [23:29:48 CET] <JEEB> I actually wrote down the ways to store aspect ratio there [23:29:55 CET] <JEEB> in ISOBMFF (aka colloquially mp4) [23:30:18 CET] <JEEB> for mov it's likely similar, but one would have to confirm @ qtff.pdf that apple gives out [23:30:40 CET] <Jan-> Ultimately though, what this guy was saying has to be BS [23:30:43 CET] <JEEB> (the useful part of that post is the 1/2/3) [23:31:07 CET] <Jan-> is "box" in a MOV like "chunk" in a RIFF AVI? [23:31:10 CET] <JEEB> so you have width/height in tkhd, pixel/sample aspect ratio in pasp, and then the video stream can have it [23:31:29 CET] <JEEB> Jan-: I recommend building L-SMASH and testing out its boxdumper tool [23:31:33 CET] <Jan-> these files are apple prores, so the spec for that isn't public and we don't really know if it has pixel aspect. [23:31:35 CET] <JEEB> `boxdumper --box file.mov` [23:31:47 CET] <JEEB> Jan-: well the mov container is what's it in [23:31:48 CET] <furq> yeah i just checked boxdumper [23:31:53 CET] <furq> looks like ffmpeg sets it in tkhd [23:32:00 CET] <JEEB> yeah, tkhd is uber alles [23:32:13 CET] <JEEB> pasp is just if you want to override what's in the video stream [23:32:22 CET] <JEEB> and yes, tkhd is likely to be the same in mov [23:32:34 CET] <JEEB> anyways, apple does give out mov specs and that's what really matters [23:32:44 CET] <JEEB> that's the QTFF spec [23:32:48 CET] <JEEB> (QT File Format) [23:35:51 CET] <Jan-> hm these files out of this hardware recorder do have a "pasp" [23:37:13 CET] <Jan-> and it is set to 1, 1 [23:37:34 CET] <Jan-> ehh I wonder if I can hack it in the hex editor [23:37:47 CET] <JEEB> pasp is a funny thing because it in most cases gets overridden by tkhd's width/height [23:37:54 CET] <JEEB> I mean, if they differ [23:38:08 CET] <JEEB> usually tkhd's width/height are set to the presentation size [23:38:34 CET] <Jan-> tkhd is a bigger structure [23:38:50 CET] <JEEB> true [23:38:56 CET] <Jan-> I'm not sure where the PAR/DAR stuff is [23:39:12 CET] <JEEB> it's just width/height in tkhd [23:39:23 CET] <JEEB> which is post-AR-applied [23:39:58 CET] <JEEB> anyways, poking the pasp can lead to interesting results [23:40:19 CET] <JEEB> although most things I know in case of tkhd being there would then just present it according to tkhd :) [23:41:22 CET] <Jan-> you'd expect there to be a four byte long "3840" and a four byte long "2160" in a UHD file. [23:41:24 CET] <Jan-> in tkhd [23:41:26 CET] <Jan-> but I can't find one [23:41:54 CET] <furq> there should be width and height keys [23:42:16 CET] <Jan-> actually I guess this may not be the picture track [23:43:27 CET] <Jan-> does anyone know the layout of tkhd? [23:43:51 CET] <JEEB> just grab a copy of either qtff or isobmff spec and ctrl+f for tkhd ;) [23:44:13 CET] <JEEB> http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html [23:44:16 CET] <JEEB> 14496-12 [23:44:19 CET] <JEEB> for isobmff [23:45:32 CET] <Jan-> it's the last two u32s [23:45:54 CET] <Jan-> wouldn't it be wierd to munge the track dimensions to change DAR though? [23:46:09 CET] <JEEB> not really [23:46:17 CET] <JEEB> that's how it's done in ISOBMFF [23:46:34 CET] <JEEB> track width/height are with aspect ratio applied, after all [23:46:42 CET] <JEEB> not coded dimensions [23:46:44 CET] <JEEB> :D [23:47:30 CET] <Jan-> okay. [23:47:43 CET] <Jan-> It's a bit odd, I can't find the actual dimensions in tkhd [23:52:27 CET] <Jan-> hmm. For film and TV work it might make sense to use pasp rather than tkhd [23:52:56 CET] <Jan-> theoretically tkhd should make quicktime scale the video track before it gets presented to the application that wants the video. [23:52:58 CET] <Jan-> this is possibly not great. [23:54:25 CET] <JEEB> well, what would the thing show if it had a pasp of X:Y and tkhd values according to the actual sample counts? [23:54:29 CET] <JEEB> if that's what you mean [23:54:43 CET] <JEEB> if I recall correctly that will just end up being shown as if it's a 1:1 SAR [23:55:20 CET] <Jan-> I'm not sure. [23:55:29 CET] <Jan-> I have discovered that ffmpeg sets pasp when you use -aspect. [23:55:36 CET] <Jan-> at least, there is a pasp box and its values are certainly not 1:1 [23:55:41 CET] <JEEB> with the caveat of course that I've mostly looked and worked with ISOBMFF, not QTFF. they can have minor differences :P [23:55:48 CET] <JEEB> Jan-: check the values in tkhd as well :P [23:55:53 CET] <Jan-> I will. [23:56:04 CET] <JEEB> boxdumper should tell you that stuff [23:56:29 CET] <Jan-> Problem is that I can't find sensible values in tkhd at all. [23:56:54 CET] <JEEB> even with boxdumper? [23:57:00 CET] <Jan-> I'm pretty sure I'm looking at the right tkhd as it has "apch" in it and that's the ProRes fourcc [23:57:13 CET] <Jan-> well I'm just using a hex editor [23:57:59 CET] <JEEB> feed the output of boxdumper --box to less or so [23:58:15 CET] <Jan-> I'm not sure I can, on windows [23:58:33 CET] <JEEB> in that case you can dump into a file with > file.txt [23:59:06 CET] <JEEB> ok, the proprietary prores sample I have does indeed contain 720x480 in the tkhd [23:59:12 CET] <JEEB> and 40:33 in pasp [23:59:45 CET] <Jan-> I guess they're "longints" in the language of this hex editor [00:00:00 CET] --- Thu Nov 24 2016

1 0

ffmpeg-devel.log.20161122
by burek 23 Nov '16

23 Nov '16

[00:11:51 CET] <cone-568> ffmpeg 03Jun Zhao 07master:e72662e131e5: lavc/vaapi_encode_h264: fix poc incorrect issue after meeting idr frame. [00:11:52 CET] <cone-568> ffmpeg 03Mark Thompson 07master:f242e0a0ff0d: vaapi_encode: Fix format specifier for bitrate logging [03:05:12 CET] <cone-568> ffmpeg 03James Almer 07master:0b8df0ce48e6: avformat/utils: add missing brackets around arguments in av_realloc() call [03:19:19 CET] <cone-568> ffmpeg 03Steven Liu 07master:d316b21dba22: avformat/flvenc: add no_metadata to flvflags [07:23:01 CET] <jya> BBBB: the 65% improvement of avx2 IDCT optimisation, how much does that translate in actual decoding speed? [07:29:24 CET] <atomnuker> jya: as in, the latest patch of all of the previous ones as well? [07:30:40 CET] <jya> atomnuker: in reference to commit f0a2b6249bb2426befa4c03247361268e45b13af. BBB had mentioned that libvpx having those avx2 optimisations, is what closed the gap speed-wise between libvpx and ffvp9 [07:31:13 CET] <jya> but i'm wondering what in real-word use it translates to, [07:35:29 CET] <atomnuker> well, ffvpx9 was already faster, but the gap probably increased [07:35:36 CET] <atomnuker> he isn't online atm though [09:51:19 CET] <[-T-]> hi all [09:51:41 CET] <[-T-]> I'm trying VAAPI encoding on the latest master code, on a Skylake, and I get: [AVHWDeviceContext @ 0x1b43500] Failed to query surface attributes: 20 (the requested function is not implemented). [09:51:55 CET] <[-T-]> is Skylake supported ? [09:57:40 CET] <jkqxz> You are trying to use the proprietary iHD driver from the media SDK? Don't do that, use the normal driver. [09:59:48 CET] <[-T-]> nope [09:59:49 CET] <jkqxz> (You can kindof hack it into working, but it has weird problems and is unlikely to be worth it. It's easiest to just consider it a backend to libmfx.) [09:59:54 CET] <[-T-]> the normal one from i965-intel [10:00:01 CET] <BtbN> What Kernel are you on? [10:00:17 CET] <[-T-]> i tried both 4.4 and 4.4 patched with MSDK [10:00:26 CET] <[-T-]> what kernel is recommended ? [10:00:29 CET] <BtbN> those are both too old for Skylake iirc [10:00:44 CET] <[-T-]> well the 4.4 patched works with skylake and MediaSDK 2017 [10:00:52 CET] <[-T-]> but i guess it's not relevant ? [10:01:08 CET] <[-T-]> i can easily try a newer one [10:01:11 CET] <BtbN> You should forget that abomination even exists, makes your life a lot easier [10:01:15 CET] <[-T-]> lol [10:01:17 CET] <[-T-]> well well [10:01:37 CET] <[-T-]> i also so that the h264_qsv imp changed completly [10:01:44 CET] <[-T-]> between 3.2 and master [10:01:56 CET] <[-T-]> so you recommend to use the vaapi one ? [10:02:11 CET] <BtbN> With vaapi working fine, there is no reason to deal with the horrible patch-everything-fest QSV on linux requires. [10:02:36 CET] <[-T-]> yes, but does it support VPP scaling for instance ? [10:02:41 CET] <[-T-]> and deint etc [10:02:52 CET] <BtbN> vaapi does, yes [10:02:57 CET] <BtbN> no idea if it's implemented in ffmpeg though [10:03:18 CET] <[-T-]> ok [10:03:27 CET] <[-T-]> I have one extra question for you please [10:03:47 CET] <[-T-]> could you confirm how layers ares actually ordered [10:04:02 CET] <[-T-]> is it LIBMFX->VAAPI->HW [10:04:08 CET] <[-T-]> for the MediaSDK imp [10:04:15 CET] <[-T-]> and VAAPI->hw for the vaapi one ? [10:04:34 CET] <BtbN> as the media-sdk one is closed source in most parts, onlx Intel knows [10:05:32 CET] <[-T-]> ok [10:05:46 CET] <[-T-]> i will try this VAAPI imp again [11:44:25 CET] <BtbN> is stdcall == cdecl on x64? [11:45:23 CET] <BtbN> Cause I'm getting (unrelated) warnings about "NVENCSTATUS (__cdecl *)(NV_ENCODE_API_FUNCTION_LIST *)", and that function should be stdcall [11:50:55 CET] <nevcairiel> x64 only has one calling convention [11:51:03 CET] <nevcairiel> stdcall/cdecl only applies to x86 [11:52:27 CET] <BtbN> interesting that it explicitly marks it as cdecl then [12:10:40 CET] <cone-500> ffmpeg 03Timo Rothenpieler 07master:5c02d2827bef: compat/cuda: add dynamic loader [12:10:41 CET] <cone-500> ffmpeg 03Timo Rothenpieler 07master:e6464a44eda9: avutil/hwcontext_cuda: use dynamically loaded CUDA [12:10:42 CET] <cone-500> ffmpeg 03Timo Rothenpieler 07master:d9ad18f3b4db: avcodec/cuvid: use dynamically loaded CUDA/CUVID [12:10:43 CET] <cone-500> ffmpeg 03Timo Rothenpieler 07master:a0c9e76942ed: avfilter/vf_scale_npp: use dynamically loaded CUDA [12:10:44 CET] <cone-500> ffmpeg 03Timo Rothenpieler 07master:a66835bcb16c: avcodec/nvenc: use dynamically loaded CUDA [12:10:45 CET] <cone-500> ffmpeg 03Timo Rothenpieler 07master:b0ca90d7cbcc: avfilter/vf_hwupload_cuda: use new hwdevice allocation API [12:10:46 CET] <cone-500> ffmpeg 03Timo Rothenpieler 07master:0faf3c3a25ed: avfilter/vf_hwupload_cuda: check ff_formats_ref for errors [12:10:47 CET] <cone-500> ffmpeg 03Timo Rothenpieler 07master:8228b714be25: configure: cuda is no longer nonfree, enable and autodetect by default [12:10:48 CET] <cone-500> ffmpeg 03Miroslav SlugeH 07master:c4aca65a42eb: avcodec/nvenc: maximum usable surfaces are limited to maximum registered frames [12:10:49 CET] <cone-500> ffmpeg 03Miroslav SlugeH 07master:de2faec2faf3: avcodec/nvenc: better surface allocation alghoritm, fix rc_lookahead [12:10:50 CET] <cone-500> ffmpeg 03Miroslav Slugen 07master:10db40f37430: avcodec/cuvid: allow setting number of used surfaces [13:02:47 CET] <wm4> jkqxz: how do you gpu memcpy on CPUs that don't support SSE4? [13:04:03 CET] <BtbN> slowly [13:05:06 CET] <wm4> eh [13:08:54 CET] <BtbN> wm4, http://git.videolan.org/?p=vlc.git;a=blob;f=modules/video_chroma/copy.c;h=4… [13:11:34 CET] <nevcairiel> basically you just use generic memcpy [13:11:53 CET] <nevcairiel> (any modern memcpy shouild use vector instructions) [13:12:18 CET] <nevcairiel> just not the special ones for gpu surfaces, but if you dont have those.. [13:12:50 CET] <jkqxz> Or get the GPU to do it for you. It can see some of CPU memory. [13:15:29 CET] <wm4> nevcairiel: does "modern" mean "not mingw's"? [13:15:40 CET] <wm4> since mingw-w64 might still use msvcrt's [13:15:45 CET] <wm4> (the ancient one) [13:16:07 CET] <nevcairiel> msvcrt isnt ancient as such, it gets updated [13:16:27 CET] <nevcairiel> its the baseline the OS was build against [13:32:07 CET] <wm4> anyway, I'm getting reports of slowness when not using the sse copy, so that's still somehow a problem [13:33:29 CET] <nevcairiel> well of course its a problem, there is a reason these special instructions are used, no optimized generic memcpy cant fix that without them [13:33:44 CET] <nevcairiel> the only other option is what jkqxz said, get the GPU to copy it for you if the API supports it [13:36:27 CET] <wm4> would that imply use of staging textures? [13:36:55 CET] <nevcairiel> Depending on the api, perhaps [13:39:23 CET] <jkqxz> The GPU can only see some of CPU memory, so you need to tell it at allocation time that you want that. (On Linux libdrm allocates such things.) [13:40:03 CET] <wm4> nevcairiel: well, dxva2 [13:40:08 CET] <jkqxz> If you need to be able to copy to arbitrary places then you need to copy twice, once with the GPU and once with normal memcpy. This is still 9001 times faster than CPU access to the GPU memory without magic memcpy. [13:40:14 CET] <wm4> d3d11va always forces staging textures, which also makes it slower than dxva2 [13:40:19 CET] <wm4> (for copy-back) [13:41:10 CET] <wm4> unfortunately I can't even test this stuff, because on my laptop with intel gpu a normal memcpy is just as fast [13:43:38 CET] <jkqxz> Doesn't that mean it's cheating and giving you a copy of the surface in CPU memory? [13:44:08 CET] <wm4> I don't know, I'm just locking the texture [13:56:31 CET] <nevcairiel> Some drivers do that, yes. [13:59:14 CET] <jkqxz> That's actually rather nice because it (presumably?) gives you the right two-step copy with the first one being implicit. [13:59:23 CET] <jkqxz> It does rather mess with testing, though. [14:04:28 CET] <wm4> wouldn't you just end up copying 3 times? [14:12:27 CET] <BtbN> But with an Intel GPU, it doesn't even have real vram, it's all just system ram [14:26:09 CET] <wm4> doesn't it depend how the cache is configured? but dunno [14:27:42 CET] <BtbN> I'm quite sure an Intel Linux dev told me that the split you configure in the BIOS is useless and you can set it to minimum without worrying, as it uses the system ram anyway [14:28:02 CET] <BtbN> No idea how the situation is on Windows [14:37:34 CET] <BtbN> philipl, dynload set is merged now, in case you missed it. [14:43:24 CET] <DHE> So everyone talks about how ffmpeg (the CLI tool) is single-threaded. Do you think there's a benefit to adding threaded processing to it? [14:45:20 CET] <DHE> (Yes, I'm offering to [try] doing the work) [14:54:26 CET] <BtbN> It would definitely be beneficial if it would run all the things in parallel [14:54:35 CET] <BtbN> it would be one hell of a synchronization nightmare though [14:56:19 CET] <DHE> what i had in mind was that the avcodec_{en,de}code_{video,audio} calls would be wrapped in threads and have a small buffer limit (maybe 2 or 3 frames). the main thread would just focus on moving the data around, PTS work, etc while the threads deals with the en/decoders [14:56:39 CET] <DHE> so the codecs wouldn't bottleneck the whole process [14:57:10 CET] <DHE> my main motivation is that I do have multiple outputs in most of my jobs so it seems that I might benefit from something like this [14:57:19 CET] <BtbN> I highly suspect that it's not that easy, and there's a lot more stuff to considder [14:57:50 CET] <BtbN> It might even be easier to implement some kind of auto-fork and pipe logic [14:58:14 CET] <BtbN> Where it spawns multiple ffmpeg processes, with one of them handling the decoding and common filtering, and one per-output process [14:58:50 CET] <Compn> so ffmpeg, if using multiple outputs, just uses one thread? hmm [14:58:57 CET] <DHE> that could be a cross-platform nightmare [14:59:00 CET] <Compn> that would be nice to multithread [14:59:05 CET] <Compn> win32 uses pthreads [14:59:20 CET] <Compn> or can use pthreads... lavc threading works on windows [14:59:25 CET] <DHE> Compn: in the main ffmpeg cli, yes. the codecs may be multi-threaded wihch improves things, but I'm guessing not much. [14:59:25 CET] <Compn> so i dont think much problem there [14:59:37 CET] <DHE> I meant cross-platform nightmare for "forking" which isn't really a windows thing. [14:59:40 CET] <Compn> ah [14:59:49 CET] <Compn> so i'd say copy how lavc does it :) [14:59:57 CET] <Compn> to avoid cross-plat nightmares [15:00:37 CET] <DHE> oh libav already has threading utility functions... [15:02:32 CET] <wm4> DHE: actually ffmpeg.c already uses threads [15:02:37 CET] <wm4> for input (for whatever reason) [15:02:50 CET] <BtbN> because it can block and stall the whole thing probably [15:03:02 CET] <wm4> also, decoding is already multithreaded, so adding a threaded buffer as you suggested will in most cases help little [15:03:13 CET] <DHE> wm4: that is true, yes [15:03:21 CET] <BtbN> it still runs the decoders sequentialy though [15:03:28 CET] <BtbN> it's only multi threaded in the decoder itself [15:03:46 CET] <wm4> on the other hand, this kind of buffer could just be added to libavcodec itself (for things which aren't threaded, like some dumb codecs) [15:04:10 CET] <BtbN> Running filters and encoder in parallel would be much more interesting [15:04:19 CET] <wm4> well the fact that decoders are threaded means the decode call returns almost immediately [15:06:03 CET] <wm4> on the other hand, some cases might benefit from this [15:06:27 CET] <wm4> e.g. hevc decoding is going to be very slow, while not saturation all used threads [15:06:45 CET] <DHE> there's actually a lot of places I've wanted to put multi-threading that don't exist yet. filtergraphs would be one possibility. a long filtergraph could probably run each individual filter in a thread. complex graphs with [a]split filters could handle multiple paths simultaneously for example... [15:07:02 CET] <DHE> but making a simple work queue on the decoder/encoder in the ffmpeg cli is the lower hanging fruit [15:07:21 CET] <wm4> that's a whole different issue... though I bet running every single filter in its own thread would make things much slower [15:10:34 CET] <Compn> so we're going to have cpu with 128 cores in the future? :\ [15:10:45 CET] <Compn> hehe [15:11:17 CET] <microchip_> Compn: there are already CPUs with at least that many threads overall [15:11:41 CET] <DHE> well, I have a machine with 20 cores + hyperthreading (per CPU) and I have an itch to put it to good use. multiple ffmpeg instances only scales so far [15:12:14 CET] <microchip_> Xeon? [15:12:17 CET] <DHE> (bottleneck is actually IO) [15:12:22 CET] <DHE> yes, xeon e5-2698 v4 [15:12:27 CET] <microchip_> nice! [15:15:48 CET] <jkqxz> DHE: What is your use-case where multiple ffmpeg instances isn't the answer for maximising throughput? [15:16:26 CET] <jkqxz> To me it seems like a rare case that you would want to get as much parallelism as possible with only one instance (the parts where it matters are generally already covered by the individually threaded components). [15:17:02 CET] <DHE> jkqxz: the disks are spindles and there's a lot of seeking going on to keep the ffmpeg processes fed alongside writing out the (multiple) outputs [15:17:20 CET] <DHE> I suspect that's a big part of why it's not scaling as well as I would hope... [15:18:36 CET] <DHE> arguably that's my fault for not specing the machine out properly [15:59:25 CET] <philipl> BtbN: yay. can you review the p016 changes now? :-) [16:12:57 CET] <BBB> 20 cores wtf [16:12:59 CET] <BBB> I want that also [16:21:06 CET] <BtbN> philipl, They kind of depend on the P016 pixel format to exist first [16:22:23 CET] <philipl> BtbN: I sent that review too [16:23:32 CET] <BtbN> One thing I'm not sure about is weather calling ff_get_format outside of the init function is even supported [16:25:07 CET] <wm4> it is [16:25:15 CET] <wm4> the native decoders do it on stream changes [16:25:17 CET] <wm4> and even on seeks [16:26:15 CET] <BtbN> Ok, so that should be fine then. [16:26:28 CET] <BtbN> Only thing is that the hwupload_cuda changes should be in their own commit [16:26:39 CET] <philipl> I'll split that out [16:27:14 CET] <BtbN> I'm also still not sure how good of an idea it is to implement this without any kind of official statement or documentation from nvidia about it even existing. [16:27:31 CET] <philipl> A question: Should I mark decoded 10bit content as P010? It might make interoperability easier. [16:27:55 CET] <BtbN> Does cuvid even give that information? [16:28:22 CET] <BtbN> ah, yeah. It has bit_depth_luma_minus8 [16:28:27 CET] <philipl> It doesn't. The only output format they added is P016 but you know that decoded 10bit content in P016 is indistinguishable from P010 [16:28:45 CET] <wm4> did you check bitexactness? [16:29:01 CET] <philipl> No, actually, I can do that. [16:35:17 CET] <DHE> BBB: not when you see the price tag you won't [16:36:05 CET] <philipl> wm4: So, 10bit ends up bitexact in framemd5 if I report it as P010. if I report it as P016, it does not. That might be a sign my swscale code is bad :-P [16:36:08 CET] <philipl> Need to check 12bit [16:36:24 CET] <wm4> neat [16:36:34 CET] <wm4> libswscale might just randomly mangle the data, that's normal [16:37:50 CET] <philipl> How do I control the output format for framemd5? -pix_fmt? [16:40:15 CET] <wm4> no idea... probably [16:42:17 CET] <philipl> So, right name framemd5 really wants the data to be in the same format as the initial input format (yuv420p12le in the 12bit case) so it does a conversion. [16:42:24 CET] <philipl> That should be lossless, in theory [16:42:36 CET] <philipl> but it's b0rked. I expect it's my sws code. [16:44:35 CET] <BtbN> I wouldn't be surprised if nvidia actually documents the new pix format as P01x or something like that [16:44:54 CET] <BtbN> So using the correct P010 format depending on the bit depth seems reasonable to me [16:45:25 CET] <philipl> Yeah. [16:46:56 CET] <philipl> Ehh. So it's auto-inserting a scaler and then deciding it can't convert to p016 up front, rather than waiting until it learns the decoder is outputting p016 [16:47:48 CET] <JEEB> that's always fun [16:47:50 CET] <BtbN> The path of least resistance for that is probably adding output support for p016 [16:47:58 CET] <philipl> Yes. [16:48:17 CET] <philipl> Funnily, if I declare output support, it will get past that point then see it doesn't need to and then it works. [16:48:21 CET] <philipl> that's with no actual conversion code. [16:48:38 CET] <philipl> Of course, if I want the software decoder to do framemd5 in p016, I need to write output conversion code. [16:48:39 CET] <nevcairiel> it shouldnt need to convert to p016, only from =p [16:49:01 CET] <philipl> If I want framemd5 values in p016 to compare, I do :-) [16:49:03 CET] <BtbN> well, unless at some point nvenc can encode that [16:49:11 CET] <philipl> yeah. [16:49:28 CET] <nevcairiel> why not just convert the p016 down [16:49:35 CET] <nevcairiel> instead of the software decoder up [16:49:38 CET] <philipl> Ok, so P010 was confirmed bitexact with a conversion back to yuv420p10le. [16:50:18 CET] <philipl> When I converted the same content in P016 down to yuv420p10le it was not bitexact. [16:50:26 CET] <BtbN> is the nvenc patch even needed if cuvid outputs actual P010? [16:50:27 CET] <philipl> So I think it's safe to say my swscale code is wrong. [16:50:39 CET] <philipl> BtbN: It's needed for decoded 12bit [16:50:48 CET] <nevcairiel> not necessarily, sws may try to do some aggressive dithering when you reduce bitdepth [16:50:51 CET] <philipl> You don't want to force a software 'conversion' [16:51:07 CET] <philipl> Hmm. Fair. [16:51:20 CET] <philipl> Let me try to force yuv420p16 [16:51:54 CET] <philipl> Nope. [16:52:22 CET] <philipl> argh. I was using the 10bit sample again for the software framemd5 :-( [16:53:18 CET] <philipl> but nope. [16:53:20 CET] <philipl> Still not the same [16:54:47 CET] <philipl> but again, hard to prove it didn't try and do something smart as the swscale conversion is not the same in each case. [16:59:30 CET] <philipl> BtbN: hrm. you explicitly needed to add unscaled conversion from 8bit to p010. So I probably am getting screwed by scaling here, even going from 12 -> 16bit? [17:00:17 CET] <BtbN> I added them because the automatic one was horribly slow [17:01:21 CET] <philipl> but were they bitexact before? [17:01:50 CET] <philipl> you had to change test hashes [17:02:32 CET] <BtbN> The results do differ [17:02:39 CET] <BtbN> but I have no idea which of them is bitexact [17:03:15 CET] <philipl> heh. [17:03:38 CET] <philipl> Ok. so we've gone around a couple of circles here. [17:03:55 CET] <philipl> 1) 10bit content, declared as P010 is bitexact in framemd5. [17:04:27 CET] <philipl> 2) 10bit content declared as P016 and 12bit content (obviously P016) are not bitexact in framemd5 but I strongly suspect that's swscale making a mess of things. [17:05:18 CET] <BBB> your code isnt necessarily wrong [17:05:27 CET] <BBB> swscale may have a fast p010-to-yuv420p10 codepath [17:05:31 CET] <BBB> that doesnt handle p016 [17:05:33 CET] <philipl> It does [17:05:39 CET] <philipl> btbn added it [17:05:43 CET] <BBB> oh [17:05:46 CET] <BBB> <- stupid [17:05:57 CET] <philipl> actually, it's the other way around. [17:06:06 CET] <BtbN> there is fast yuv420p to p010 [17:06:17 CET] <nevcairiel> yuv420pbXX is sws internal format [17:06:40 CET] <philipl> yes, I see it. [17:06:40 CET] <BtbN> or was it nv12? [17:06:43 CET] <philipl> both [17:07:19 CET] <philipl> anyway. [17:07:23 CET] <philipl> So, question: [17:07:36 CET] <philipl> I'll update the diff to report 10bit as P010. [17:07:46 CET] <philipl> Are we ok with the unclear nature of the 12bit stuff? [17:08:00 CET] <cone-763> ffmpeg 03Timo Rothenpieler 07master:5ea8f7062300: avcodec/libx264: fix forced_idr logic [17:28:30 CET] <philipl> BtbN: I've dropped the nvenc patch now that I'm calling 10bit content P010. [17:53:09 CET] <wm4> philipl: what happens on older drivers? [17:58:19 CET] <philipl> wm4: You'll get an error initializing the decoder with the unknown output format. [17:59:34 CET] <wm4> sounds good [17:59:58 CET] <wm4> what happens the other way around if the input video's profile is not supported by the decoder? [18:00:33 CET] <philipl> You get another form of initialization error. [18:01:03 CET] <philipl> 12bit is new in 375 as well, so you'd get that error on an older driver. [18:03:07 CET] <wm4> or older hw I suppose [18:03:54 CET] <philipl> Yes. [18:06:09 CET] <wm4> that sounds pretty good [18:17:28 CET] <gabrieliv> warning: avcodec_decode_video2 is deprecated, what should I use instead? [18:21:50 CET] <jamrial> gabrieliv: avcodec_send_packet() and avcodec_receive_frame(). read the doxy in avcodec.h [18:24:50 CET] <BtbN> philipl, where does the avctx->sw_pix_fmt come from? It's used to initialize the hwframes ctx, but it's never set. [18:25:29 CET] <philipl> Heh. It's set by ff_get_format. Which is insane, but there you go. [18:33:04 CET] <BtbN> what? So it has logic to also negotiate a software format, in case the pixel format is a hw one? [18:33:39 CET] <BtbN> Also, wouldn't it be easier and shorter to only have one pix_fmt enum array, and set the second element, instead of 3 full arrays? [18:34:11 CET] <BtbN> Would also be more future proof in case another format gets added [18:35:44 CET] <philipl> ff_get_format doesn't do the right thing if there are multiple softwware formats [18:35:49 CET] <philipl> It *always* chooses the last one [18:36:07 CET] <philipl> So it can choose between hw and sw correctly but does nothing smart about the sw value [18:36:39 CET] <philipl> Oh, I see. Change the second value. [18:36:41 CET] <philipl> Yeah, I can do that. [18:41:17 CET] <philipl> BtbN: https://github.com/philipl/ffmpeg/tree/cuvid [18:41:23 CET] <philipl> I'll just keep updating that until you're happy with it [18:46:34 CET] <BtbN> have you tried enum values higher than 1, btw.? [18:46:39 CET] <BtbN> For the cuvid pixel format, that is [18:47:45 CET] <BtbN> But what I meant is: https://github.com/philipl/FFmpeg/commit/d6a40c8f5ec5b849821bfc56dee5e005dd… [18:48:01 CET] <BtbN> where is that sw_pix_fmt set? Does ff_get_format really do that, if the primary format is a hw one? [18:48:34 CET] <philipl> BtbN: I have tried 2, and 2 doesn't work. I didn't try higher this time, although I did in the past. [18:48:47 CET] <philipl> Yes, ff_get_format really does it. [18:49:27 CET] <philipl> https://github.com/philipl/FFmpeg/blob/master/libavcodec/utils.c#L1122 [18:49:33 CET] <philipl> It's insane, but there it is. [18:50:03 CET] <BtbN> allways hardcoded to the last, wow [18:50:55 CET] <BtbN> but yeah, otherwise this looks fine to me now. [18:51:17 CET] <wm4> this code is basically designed for hwaccels [18:51:23 CET] <wm4> doesn't make too much sense for hw decoders [18:52:18 CET] <wm4> uh it even sets sw_pix_fmt for non-hwaccels [18:52:26 CET] <wm4> so correction: this code doesn't make too much sense [18:52:43 CET] <philipl> yep [18:52:57 CET] <philipl> It's... highly predictable... [18:53:34 CET] <BtbN> it would seem like a good idea to add a check for the selected format being a hwaccel one [18:54:41 CET] <philipl> BtbN: So, if you're using the software read-back path, it won't be an hwaccel one. [18:54:59 CET] <BtbN> hm? [18:55:01 CET] <philipl> That's the value here, it's able to choose AV_PIX_FMT_CUDA vs AV_PIX_FMT_NV12 (or whatever) [18:55:20 CET] <philipl> depending on how its being used. yeah? [18:55:27 CET] <philipl> or are you asking a different question? [18:55:56 CET] <BtbN> I mean just moving the setting of sw_pix_fmt to the end of the function, surrounded by an if(is_hwaccel_pix_fmt(ret)) [18:57:12 CET] <philipl> yeah. [18:57:47 CET] <philipl> Ok, so I'll push the p016 pix fmt (but not the swscale input part) and then the cuvid changes. [18:57:54 CET] <philipl> No one's reviewed the swscale part yet. [19:08:02 CET] <philipl> BtbN: is this a micro version bump for avcodec? [19:08:22 CET] <BtbN> yes [19:08:26 CET] <philipl> and avutil for the hwcontext_cuda? [19:08:45 CET] <BtbN> hm, if in doubt, it's allways a micro bump. [19:08:55 CET] <philipl> heh [19:09:05 CET] <BtbN> I wonder if it'd make sense to also add support to hwupload_cuda [19:10:30 CET] <philipl> presumably - but for nvenc more than anything else. [19:11:06 CET] <philipl> one line change? [19:11:43 CET] <BtbN> haven't looked at it, but as it mostly just forwards to the hwcontext functions, it can't be much more [19:13:24 CET] <cone-763> ffmpeg 03Philip Langdale 07master:237421f14973: avutil: add P016 pixel format [19:13:25 CET] <cone-763> ffmpeg 03Philip Langdale 07master:8d6c358ea8ec: libavutil/hwcontext_cuda: Support P010 and P016 formats [19:13:26 CET] <cone-763> ffmpeg 03Philip Langdale 07master:81147b5596ea: avcodec/cuvid: Add support for P010/P016 as an output surface format [19:20:39 CET] <gabrieliv> I need to compile and run some ffmpeg code on a remote machine where I don't have root access to install ffmpeg-devel package. I've copied the ffmpeg source code snapshot to the remote machine and tried to compile my code with gcc -I/path/to/snapshot but, however, this fails due to the missing .so libraries (e.g. libavformat.so, libavcodec.so etc) that need to linked together with the object files into my executable. Is there any way I could ge [19:20:39 CET] <gabrieliv> t the ffmpeg .so files in order to successfully build my code? [19:21:49 CET] <llogan> wrong channel. see #ffmpeg [19:24:12 CET] <gabrieliv> OK [20:33:04 CET] <cone-763> ffmpeg 03Alex Converse 07master:3ee59939a1c1: libvpxenc: Support targeting a VP9 level [21:11:20 CET] <microchip_> anyone working on AC-4 support? Is that even doable atm? [21:19:44 CET] <JEEB> the "spec" is around [21:19:51 CET] <JEEB> but I don't think anyone has worked on it [21:19:58 CET] <JEEB> there are some DASH samples with it I hear [21:20:14 CET] <microchip_> ic [21:21:13 CET] <JEEB> http://testassets.dashif.org/#feature/details/57cd83dfb626efae4d44d458 [21:21:29 CET] <JEEB> the AC-4 test vectors at dashif [21:26:48 CET] <microchip_> apparently 192 kbps is enough for 5.1 AC-4.... O.O [21:27:02 CET] <microchip_> how the hell did they pull that off? [21:27:59 CET] <llogan> cp opus AC-4 [21:28:09 CET] <microchip_> lol [21:42:31 CET] <wm4> I surely hope AC-4 has so little success that it'll be the biggest embarrassment to its creators ever [21:44:34 CET] <nevcairiel> is that the object based format [21:44:44 CET] <wm4> oh some broadcasters already picked it up... looks like mankind is the embarrassment [21:44:53 CET] <j-b> You mean ATSC picked it up? [21:46:04 CET] <wm4> and ETSI according to wikipedia [21:46:32 CET] <nevcairiel> so basically all the broadcasters? :p [21:46:40 CET] <wm4> I'm not sure what kind of BSE these people have [21:46:46 CET] <j-b> No, ETSI does not pick anything [21:46:57 CET] <wm4> fuck them anyway [21:46:57 CET] <j-b> They standardize what they are given [21:47:09 CET] <j-b> They standardized a lot of things that never went in prod [21:47:13 CET] <j-b> like DVB-CSA2 [21:47:14 CET] <nevcairiel> whats so bad about ac-4 anyway [21:47:47 CET] <TD-Linux> other than it probably costing $$$$? [21:47:59 CET] <nevcairiel> well so do practically all other formats they use [21:48:01 CET] <TD-Linux> one good thing: it can't be as bad as ac3 [21:48:07 CET] <wm4> maybe because its only merit is that it's patented [21:48:11 CET] <TD-Linux> though ac3 is expiring / has expired [21:48:18 CET] <TD-Linux> actually ^ is probably its main merit [21:50:36 CET] <microchip_> i use currently e-ac-3 for my movies [21:50:39 CET] Action: microchip_ runs [21:51:35 CET] <wm4> microchip_: I'm so sorry [21:51:39 CET] <microchip_> :D [21:51:49 CET] <nevcairiel> i just leave the movies in whatever format they come in [21:54:59 CET] <microchip_> nevcairiel: i would too, but a) i don't have high-end gear to hear the diff, so I thought since i can't tell the diff between DTS/TrueHD lossless and 768 kbps e-ac-3, I'd go for the latter to save space and b) DTS core needs too high a bitrate to sound like e-ac-3 [21:58:09 CET] <TD-Linux> looking at the spec it's not an opus copy, but not very novel either [21:58:24 CET] <TD-Linux> atomnuker will enjoy the 960 and 1920 sample dcts [21:58:35 CET] <microchip_> :D [21:59:39 CET] <atomnuker> not baffled at all, ac-3 used messed-up 512 windows and even more messed up 256 windows [22:00:42 CET] <atomnuker> they're getting at fucking up the most fundamental parts [22:01:21 CET] <TD-Linux> (or maybe he won't because no one cares about ac-4) [22:01:39 CET] <nevcairiel> once it starts showing in actual user-facing broadcasts, people might care [22:01:59 CET] <atomnuker> like, I dunno, 2 organs responsible for hearing require more than channels [22:02:02 CET] <microchip_> wait till yamaha/onkyo/denon adapt it [22:03:13 CET] <llogan> Don't forget Coby [22:03:34 CET] <microchip_> ;) [23:40:56 CET] <jkqxz> BtbN: Do you want to make any comment on the VAAPI H.265 scaling list patch? (You wrote that file.) [23:47:06 CET] <jkqxz> BtbN: I would intend to just apply it as-is - it looks right and works on Skylake for me. (And I doubt anyone else will be interested in commenting.) [23:49:40 CET] <rcombs> why would broadcasters want to use AC-4 instead of Opus [23:49:43 CET] <rcombs> idgi [23:50:09 CET] <rcombs> I get why the fuckers at Dolby would want to come up with a new profit center, but I don't get why anyone would bite [23:50:38 CET] <kierank> rcombs: object based audio [23:50:54 CET] <rcombs> broadcasters care about that shit? [23:51:02 CET] <kierank> yes [23:51:10 CET] <rcombs> also doesn't Google have a free spec for that now [23:51:15 CET] <kierank> they've been told people will spend money on tv for that [23:51:22 CET] <kierank> no [23:51:44 CET] <j-b> Opus can do Object-Based Audio. [23:51:48 CET] <rcombs> I think they've heard wrong [23:52:16 CET] <rcombs> (I'm doubtful many people will spend money on TV for the sake of object audio) [23:52:25 CET] <rcombs> j-b: well there you go [23:52:27 CET] <j-b> They will buy new TVs for 3D /s [23:52:28 CET] <kierank> j-b: afaik object based audio != ambisonics [23:52:36 CET] <j-b> kierank: correct. [23:52:38 CET] <wm4> yeah, got to invent some new consumer gimmick [23:52:42 CET] <kierank> j-b: so what does opus support [23:52:56 CET] <kierank> http://www.pocket-lint.com/news/139452-bt-launches-dolby-atmos-sound-with-4… [23:52:57 CET] <wm4> just to create a reason to buy new expensive hw [23:52:59 CET] <j-b> kierank: various "layouts" [23:53:09 CET] <kierank> j-b: fixed layouts, no [23:53:13 CET] <j-b> kierank: you have a stereo layout, a multichannel layout, an ambisonic layout [23:53:24 CET] <j-b> kierank: but opus allows any layout, up to 255 channels [23:53:34 CET] <kierank> afaik dolby atmos is dynamic layout or something [23:53:36 CET] <kierank> based on the room [23:53:42 CET] <j-b> so it's trivial to put 255 objects in Opus [23:53:52 CET] <kierank> but the mixing data isn't there [23:53:52 CET] <j-b> the dynamic can be done in the metadata [23:53:55 CET] <rcombs> so you'd transmit location information in sideband data [23:54:00 CET] <j-b> rcombs: yep [23:54:01 CET] <kierank> j-b: where, opus doesn't have metadata? [23:54:06 CET] <rcombs> and do mixing at a higher level? [23:54:09 CET] <rcombs> that actually sounds sane [23:54:21 CET] <wm4> +in [23:54:24 CET] <kierank> you've already lost with sideband data in broadcast [23:54:35 CET] <rcombs> wm4: well, sane compared to atmos [23:54:39 CET] <j-b> like HDR10 vs HLG [23:54:44 CET] <j-b> or Dolby Vision [23:54:53 CET] <j-b> Broadcast people are so sloooow to react [23:54:56 CET] <rcombs> Dolby Vision, bahahahaha [23:55:12 CET] <rcombs> and isn't HDR10 just a fancy name for HEVC Main 10 + BT2020 [23:55:18 CET] <microchip_> why all the Dolby hate? :P [23:55:18 CET] <j-b> they want HLG when all TVs have Dolby-Vision, and HDMI and Windows/Android is HDR10 [23:55:30 CET] <j-b> rcombs: + metadata [23:55:35 CET] <kierank> in my live transmission, how do I transport this metadata [23:55:55 CET] <j-b> where you want :) [23:56:07 CET] <j-b> you have the same issue for HDR [23:56:16 CET] <kierank> hlg is backwards compatible [23:56:53 CET] <j-b> too late... I'm afraid. [23:56:58 CET] <wm4> microchip_: because they're shitty assholes with bad tech? [23:57:14 CET] <microchip_> wm4: better than DTS imho :p [23:57:15 CET] <j-b> But no, the broadcaster will use AC-4 and get us 20 years of Dolby Patents [23:57:24 CET] <kierank> only the french [23:57:30 CET] <j-b> lol [23:57:31 CET] <j-b> touché [23:57:44 CET] <wm4> the french? [23:57:46 CET] <j-b> but also the american, who are going with AC4 and MMT [23:58:03 CET] <kierank> well atsc3 won't go anywhere [23:58:04 CET] <kierank> so that's fine [23:58:59 CET] <j-b> kierank: may $deity make you correct! [23:59:52 CET] <wm4> apropos awesome tech... is there really no good way to determine the duration of gifs? [00:00:00 CET] --- Wed Nov 23 2016

1 0

ffmpeg.log.20161122
by burek 23 Nov '16

23 Nov '16

[00:05:19 CET] <voip_> unkmar, yes i need audio and video. I am using Linux servers without GUI. So I need grab videos form YouTube, (maybe transcode) and sent live strams to my Wowza server [00:10:32 CET] <markvandenborre> voip_: if you can grab the dash fragments from youtube, you may be able to concat them using ffmpe [00:10:35 CET] <markvandenborre> g [00:10:45 CET] <markvandenborre> then throw them at nginx-rtmp [00:11:09 CET] <iive> voip_: you can embed youtube video on any site, the browser would play it from youtube [00:12:22 CET] <markvandenborre> voip_: it _would_ help if you would explain what you are really trying to accomplish though [00:13:34 CET] <voip_> markvandenborre, how to grab dash framgents and live stream with ffmpeg ? [00:14:28 CET] <voip_> iive, i cant, my users dont using browsers (iptvbox) [00:24:14 CET] <llamapixel> raking youtube for iptv users sounds like you are running a little media station of sorts. [01:11:06 CET] <maletor> How do I send a stream directly to ALSA? For example, I have a receiver that can decode proprietary formats like Atmos/DTS:X and I just want to send them directly to the receiver. How can I use ffmpeg to do that/ [01:19:08 CET] <llogan> ffmpeg has an ALSA output device. not sure if that's what you want or not [01:19:28 CET] <maletor> perhaps it is [01:19:31 CET] <llogan> http://ffmpeg.org/ffmpeg-devices.html#alsa-1 [01:20:01 CET] <maletor> llogan: thx [01:42:52 CET] <fling> [nut @ 0x55602754bb60] decoding for stream 2 failed [01:43:06 CET] Action: fling is trying to remux a nut file without an index [01:43:17 CET] <fling> But it plays fine in mpv! [01:53:55 CET] <llogan> try a newer ffmpeg [01:55:06 CET] <llogan> if it still fails try with "--enable-libnut" (not sure what is any different compared to native nuts) [01:57:24 CET] <fling> Is not it because of the interesting stream order? [01:58:29 CET] <fling> #0:0: Video, #0:1: Audio, #0:2: Video [01:58:35 CET] <vayvanne> hello ppl. my "read and copy to null" test setup survives only 4 h 28 secs of run. then I get [RTMP_ReadPacket, failed to read RTMP packet header] message. what could be the reason for this? [01:59:22 CET] <fling> llogan: but the resulting video is missing stream #0:0 from the original and it has #0:2 intead of it! [02:00:32 CET] <llogan> fling: hard to say much else without seeing your command & complete console output (via pastebin), and a link to an example file. [02:01:33 CET] <vayvanne> no note, that is not the network or media server or stream issue. it is ffmpeg because I run multiple instances and the run time is always 4h 28s. or about 400k frames. [02:01:43 CET] <vayvanne> to note, that is not the network or media server or stream issue. it is ffmpeg because I run multiple instances and the run time is always 4h 28s. or about 400k frames. [02:09:54 CET] <AssPirate> vayvanne: when I was running long streams I ran out of memory and got oom killed. If it consistently dies at the same time that might not be the case though [02:11:57 CET] <vayvanne> @AssPirate thanks for responce. memory consuming is all right, less than 18MB all the time. I run zeranoe 3.2 version build. the media server is adobe [02:12:26 CET] <vayvanne> *response [02:25:22 CET] <vayvanne> after RTMP_ReadPacker error I get also this: Larger timestamp than 24-bit: 0xfffffea0 [02:26:14 CET] <vayvanne> but guess that it is the follow-up of dropped stream [02:52:25 CET] <fling> llogan: http://dpaste.com/2HAHYER [03:20:35 CET] <catsup> what is a 'video size abbreviation' (language from here: http://fountainheadfund.se/localdoc/ffmpeg/ffmpeg-devices.html#Options ) ? is there a video size abbreviation for fullscreen? [03:24:02 CET] <catsup> or more directly... how can i get 'ffmpeg' to behave like 'ffplay -fs' ? [03:25:51 CET] <DHE> catsup: there's a number of macros for certain image sizes, like "hd1080" for 1920x1080 and so on... [03:26:17 CET] <furq> https://ffmpeg.org/ffmpeg.html#Options [03:26:20 CET] <furq> why aren't you using this [03:30:21 CET] <catsup> furq: that's the same thing [03:30:54 CET] <catsup> furq: i had just searched the string 'video size abbreviation' after seeing it in the man page, and then i had gone to the second page of the google search by the time i pasted a random url with the man page on it [03:31:09 CET] <catsup> DHE: none for fullscreen? [03:32:01 CET] <DHE> catsup: it lets you specify weird resolutions by name instead of numbers. like "4k" or "xga". its' not related to full-screen mode [03:32:27 CET] <catsup> btw to be clear, i have it in fullscreen mode, but if i don't specify a resolution i get a fullscreen window that contains a box [05:47:53 CET] <ItWasntMe2013> does anyone know if I can frame count when doing draw text? '%{localtime\:%T}' [05:48:01 CET] <ItWasntMe2013> I can get the local time, but I cant get frames [05:50:59 CET] <c_14> ItWasntMe2013: n the number of input frame, starting from 0 [08:43:19 CET] <bencc> for streaming h264 in a browser, should I use crf or min/max bitrate? [08:43:35 CET] <bencc> quality is less important for me. I prefer smooth streaming [08:44:03 CET] <furq> probably crf and the vbv [08:44:11 CET] <JEEB> one is a primary rate control, the other is an additional rate control mechanism [08:44:44 CET] <furq> yeah if you meant the vbv and not -b:v then you can use them both together [08:44:51 CET] <furq> there's no point setting minrate though [08:45:15 CET] <bencc> how does -bufsize work? [08:45:22 CET] <bencc> does it force the viewer to buffer? [08:45:27 CET] <furq> no [08:46:20 CET] <furq> afaik if you have maxrate 1000k and bufsize 5000k then every 5000k of video will average out to be no more than 1000k [08:46:32 CET] <furq> 1000kbps, obviously [08:47:09 CET] <furq> it's rare that you actually need it if you have plenty of bandwidth [08:47:23 CET] <bencc> this is reasonable? [08:47:26 CET] <bencc> ffmpeg -i input.mp4 -c:v libx264 -preset slow -crf 28 -vf "format=yuv420p,scale=960:-1" -r 24 -c:a aac -strict experimental -b:a 96k -movflags +faststart out.mp4 [08:48:04 CET] <furq> seems fine, but don't set -r unless you need to [08:49:15 CET] <bencc> I want to lower the bitrate as much as possible. if the input is 30fps I'm adding -r 24 to make it 24fps [08:49:30 CET] <bencc> unless I don't understand how -r is used [08:49:53 CET] <furq> that works [08:49:59 CET] <bencc> thanks [08:50:15 CET] <furq> i doubt you'll get a worthwhile bitrate saving from it though [08:50:29 CET] <bencc> I'll test [08:50:38 CET] <bencc> can it have negative effect? [08:50:52 CET] <bencc> I mean noticeable negative effect [08:50:55 CET] <furq> i doubt it [08:54:28 CET] <bencc> 29 fps gives me 402kbps while 24fps gives me 388kbps [08:54:44 CET] <bencc> not a big difference but I'll take every bit :) [08:54:54 CET] <bencc> 100 viewers will watch the video at the same time [08:59:13 CET] <Sircle> Hi [08:59:23 CET] <ritsuka> is the video still smooth? dropping 6 fps should be noticeable [09:00:40 CET] <Sircle> it seems I have a problem with ffmpeg and I cannot read videos https://pastebin.mozilla.org/8930460 [09:02:27 CET] <bencc> ritsuka: I'll check. in my case 100 users will view it at the same time so I prefer speed over quality [09:02:39 CET] <Sircle> maybe this is the issue? https://github.com/bytedeco/javacv/issues/68 [09:02:51 CET] <Sircle> is there a way to split a video via ffmpeg? [09:02:55 CET] <ritsuka> you could just increase the crf to 29 [09:02:59 CET] <Sircle> split its frames to pictures [09:03:54 CET] <furq> Sircle: -i foo.mp4 out%04d.png [09:04:12 CET] <bencc> ritsuka: better to increase the crf than changing the frame rate/ [09:04:16 CET] <bencc> ritsuka: why not do both? [09:04:57 CET] <ritsuka> because changing frame rate is harder to do right [09:05:09 CET] <furq> 30 to 24 will just drop every sixth frame [09:05:20 CET] <furq> if it doesn't look jerky to you then i guess that's fine [09:06:09 CET] <bencc> ok. I'll try to keep the frame rate [09:06:13 CET] <bencc> and just increase crf [09:06:18 CET] <furq> every fifth frame, even [09:06:47 CET] <furq> use a slower preset if you can tolerate it [09:07:05 CET] <furq> veryslow gives significant improvements on some sources [09:07:06 CET] <bencc> I'm using "-preset slow" [09:07:14 CET] <bencc> great. I'll use veryslow [09:11:20 CET] <bencc> HLS with 3 separate bitrates will ensure all the viewers have a decent experience? [09:11:42 CET] <furq> only if 388kbps is your lowest target bitrate [09:12:08 CET] <bencc> ok [09:12:34 CET] <bencc> why 388kbps? is it a magic number? [09:12:53 CET] <furq> 07:54:28 ( bencc) 29 fps gives me 402kbps while 24fps gives me 388kbps [09:13:15 CET] <bencc> ok [09:13:50 CET] <furq> if that's your lowest bitrate then sure, otherwise there's not much point [09:15:06 CET] <bencc> I'll increase crf as much as I can while still having good enough quality [09:17:50 CET] <bencc> furq: should I change the profile? [09:18:02 CET] <bencc> furq: I currently don't set it so I think it's baseline by default [09:18:25 CET] <furq> depends what people are viewing the stream in [09:18:37 CET] <furq> pretty much anything modern will be fine with high [09:18:55 CET] <bencc> furq: most will be on desktop. some on laptop/mobile [09:19:04 CET] <bencc> but there could be old devices. not sure [09:19:11 CET] <furq> old phones might need main or really old phones might need baseline [09:19:45 CET] <bencc> old desktop and laptops will be fine with high? like a computer with XP [09:20:03 CET] <furq> should be fine if it's sd [09:20:11 CET] <furq> baseline will fuck up compressibility really badly [09:20:33 CET] <bencc> ok [09:43:26 CET] <Sircle> furq: ever used opencv or javacv? [09:59:33 CET] <furq> can't say i have [10:13:05 CET] <Sircle> furq: I used opencv in java as javacv and I guess there ffmpeg i snot working via jars. Is there an alternative? https://pastebin.mozilla.org/8930460 [10:47:05 CET] <kerio> how do you even watch 388kbps video [10:47:23 CET] <kerio> i have some vbr mp3s that are higher than that i think [10:54:37 CET] <Mavrik> Good thing the video codecs are significantly better than mp3 :P [10:55:29 CET] <furq> i expect you take what you can get if you've got 512k dsl [11:15:13 CET] <Mavrik> or ya know [11:15:14 CET] <Mavrik> 3G. [11:15:29 CET] <Mavrik> or crappy thing that masquerades as LTE in some parts :P [11:29:32 CET] <Sircle> anyone? https://pastebin.mozilla.org/8930460 [11:54:49 CET] <termos> when printing out output information with av_dump_format I see that framerate is set MetaData, but when I rtmpdump my stream it's no longer set. Is this somehow removed during muxing? [12:02:47 CET] <termos> it's as if the framerate metadata is removed by the flv muxer [12:04:27 CET] <BtbN> Does flv even carry a framerate? [12:08:10 CET] <termos> https://github.com/FFmpeg/FFmpeg/blob/d316b21dba227fa2a2bce0daf02a62f118212… [12:08:37 CET] <termos> these were the lines causing the issue, my AVStream.avg_frame_rate was not set by me before av_write_header [13:10:33 CET] <JetbOo> Hi there [13:10:47 CET] <JetbOo> When encoding with ffmpeg I get "100 buffers queued in output stream 0:0, something may be wrong." [13:11:00 CET] <JetbOo> When playing the resulting video, it stays fixed like a picture ... [13:12:07 CET] <JetbOo> Here is the pastebin http://pastebin.com/v1KvtWdZ [13:13:12 CET] <JetbOo> An idea of whats wrong out there ? [13:33:12 CET] <termos> I had this issue when the filter in my filter graph could not process frames fast enough. Do you have the same problem without the scale filter? [13:34:14 CET] <termos> also your fps filter looks wrong, it will default to 25 fps though [13:53:30 CET] <JetbOo> termos: without the scale filter I cant encode because the resolution cannot be divided by 2 [13:54:45 CET] <JetbOo> termos: when I input fps=fps=2 the error disapears [13:55:01 CET] <JetbOo> but the video remains like an image [14:54:15 CET] <Eiken> when outputting an image sequence how can i make it not start on frame 0001? [14:54:25 CET] <Eiken> ideally i want it to keep the frame numbers from the input image sequence [14:58:11 CET] <ozette> hi i'm trying to troubleshoot something here [14:59:07 CET] <ozette> what does it mean when ffprobe $file outputs: [h264 @ 0x1df5370] Increasing reorder buffer to 1 [15:00:35 CET] <ozette> i have a bunch of video files on my workstation, and my server can serve them all, except for the latest two which were uploaded [15:01:00 CET] <ozette> my server just does not respond, and i don't see why [15:02:08 CET] <ozette> when i give the name of the problematic video to an OK video it CAN be requested and replayed [15:02:33 CET] <DHE> could be a corrupted stream. the number of frames the h264 decoder had to buffer changed unexpectedly [15:02:49 CET] <DHE> or maybe someone combined two videos together that didn't have matching parameters [15:06:10 CET] <ozette> interesting, because i CAN view the video locally on the workstation, and it does show two seperate angles [15:06:15 CET] <ozette> as if it's meant for VR or something [15:07:05 CET] <ozette> output of ffprobe with a working video, bearing the name of the problematic one: https://paste.fedoraproject.org/488465/79823534/raw/ ;; output of the problematic video: https://paste.fedoraproject.org/488464/82347714/raw/ [15:07:28 CET] <ozette> so it may be because it's some kind of combined video? [15:11:21 CET] <ozette> but why would my server refuse to serve the video? [15:15:41 CET] <Eiken> no one? must be more people that want same frame numbers [15:18:52 CET] <ozette> this is what the two videos look like https://s18.postimg.org/7h9nt1uop/situation.png [15:40:51 CET] <ozette> i think i found out the roblem [15:40:57 CET] <ozette> problem* [15:41:12 CET] <ozette> my server tries to determine the mime type [15:41:27 CET] <ozette> with magic numbers [15:41:56 CET] <ozette> but, it can't seem to determine the mime type of this type of video, so the request is never answered [15:48:41 CET] <ozette> my server uses this file to determine mime type https://github.com/sindresorhus/file-type/blob/master/index.js [15:48:43 CET] <ewl> I have a question; Can I convert .MXF to .MP4 with ffmpeg? [15:49:10 CET] <ozette> there's quite some in there to determine .mp4, but it seems 'this' video is not in there [15:53:37 CET] <kerio> ozette: seems like a garbage way of doing things [15:53:46 CET] <kerio> ewl: can you ffprobe the .mxf? [15:55:20 CET] <ewl> kerio; ffprobe? [15:55:29 CET] <kerio> ffprobe whatever.mxf [15:55:36 CET] <ewl> Hold [15:55:40 CET] <kerio> also, when you say "convert" [15:55:55 CET] <kerio> do you mean remux to change the container [15:56:00 CET] <kerio> or actually transcoding video and/or audio? [15:56:43 CET] <ewl> I need the whole video to be a playable mp4-file instead of .mxf. [15:57:03 CET] <ewl> At work, we are going to have a Movie festival and one of the files we got was a xmf file. [15:57:14 CET] <ewl> And our media player doesnt support that format. [16:01:15 CET] <ewl> kerio: I did the ffprobe. [16:01:25 CET] <ewl> What do you need from it? [16:08:29 CET] <kerio> ewl: pastebin the output [16:08:33 CET] <kerio> it's mostly about the codecs [16:08:37 CET] <kerio> ...meh actually [16:08:39 CET] <kerio> you know what [16:08:54 CET] <kerio> ffmpeg -i whatever.mxf -codec copy whatever.mp4 [16:08:56 CET] <kerio> see if it works [16:08:59 CET] <kerio> it should be fast [16:09:08 CET] <ewl> Okay, hold. [16:09:21 CET] <ewl> The file is ~40GB. Should it still be fast? [16:10:32 CET] <kerio> ...well [16:10:39 CET] <kerio> as fast as a 40gb file copy i guess [16:10:58 CET] <kerio> a bit less than that [16:11:27 CET] <ewl> http://pastebin.com/FQxaj9gY [16:11:29 CET] <ewl> The ffprobe [16:22:38 CET] <kerio> it expired already? [16:22:43 CET] <ewl> hold [16:24:55 CET] <ewl> kerio: http://pastebin.com/rhTYL4jB [16:24:58 CET] <ewl> There you have [16:25:30 CET] <kerio> that's mpeg2 and raw audio [16:25:41 CET] <kerio> oh god it's split 7.1 audio [16:25:59 CET] <kerio> who uses mpeg2video in 2016 [16:26:03 CET] <ewl> Dunno. [16:26:20 CET] <ewl> It's a new Movie that was released to theaters this year. [16:26:29 CET] <kerio> anyway, it should maybe kinda work [16:26:39 CET] <ewl> with copy? [16:26:40 CET] <kerio> but you need to merge the audio or it's not going to sound good at all [16:26:44 CET] <kerio> yeah you can copy the video [16:26:55 CET] <kerio> ...but honestly, just transcode it to h264 [16:27:17 CET] <kerio> https://trac.ffmpeg.org/wiki/AudioChannelManipulation [16:27:58 CET] <kerio> i mean, it's apparently very high bitrate mpeg2 [16:29:22 CET] <ozette> kerio: why? [16:29:35 CET] <ozette> you have to determine the mime type somehow [16:29:48 CET] <kerio> ozette: how's failing to do anything a good idea for a web server? [16:29:54 CET] <ewl> Hm, transcode the whole Movie tho h264 or just the audio and then merge it with the copy? [16:30:03 CET] <ozette> it's not really failing [16:30:04 CET] <kerio> ozette: application/octet-stream [16:30:07 CET] <kerio> ez [16:30:07 CET] <ozette> it's just not part of the list [16:30:15 CET] <ozette> octet-stream has never ever worked for me [16:30:38 CET] <ozette> i could transcode the uploaded video, and use some mime type i always know will be true [16:30:45 CET] <ozette> but i currently don't [16:31:14 CET] <ozette> well, i actually do, but not on this particular workstation, it's a branch of my original server [16:31:24 CET] <kerio> ewl: transcoding will be expensive, cpu-wise [16:31:30 CET] <kerio> but it will result in a reasonable size for your video [16:31:58 CET] <ewl> size doesn't matter at all. I just need a functional .mp4-video that the media player can play. [16:32:02 CET] <ozette> i can expand the list to include the magic number of this video, and send a pull request to the devs of this lib [16:32:55 CET] <ewl> copy didn't work. [16:33:05 CET] <kerio> ewl: what was the error? [16:33:08 CET] <kerio> because it should've worked [16:33:19 CET] <kerio> other than the fact that the audio is going to be borked [16:33:39 CET] <ewl> [mxf @ 0000000000f66680] index entry 145177 + TemporalOffset 1 = 145178, which is out of bounds [16:33:58 CET] <kerio> is that an actual fatal error [16:34:43 CET] <ewl> [mp4 @ 0000000002874c80] Could not find tag for codec pcm_s24le in stream #1, codec not currently supported in container [16:34:44 CET] <ewl> Could not write header for output file #0 (incorrect codec parameters ?): Invalid argumentStream mapping: [16:34:44 CET] <ewl> Stream #0:0 -> #0:0 (copy) [16:34:44 CET] <ewl> Stream #0:1 -> #0:1 (copy) [16:34:44 CET] <ewl> Last message repeated 1 times [16:34:50 CET] <ewl> And that one. [16:35:28 CET] <kerio> that is the error [16:35:48 CET] <kerio> ewl: why do you keep putting out pastebins with expiration times [16:35:50 CET] <kerio> jesus christ [16:36:14 CET] <ewl> Sorry. Because it's workstuff, don't wanna forget to delete it [16:36:57 CET] <ewl> http://pastebin.com/J03Cu0qd [16:37:04 CET] <ewl> That's a new one, 1 hrs expiration [16:37:23 CET] <kerio> anyway, as i told you [16:37:28 CET] <kerio> https://trac.ffmpeg.org/wiki/AudioChannelManipulation [16:37:56 CET] <kerio> you'll have to figure out how those 8 mono channels fit in a 7.1 audio stream [16:38:07 CET] <kerio> and if they're actually 7.1 [16:38:14 CET] <ewl> Okay. [16:38:18 CET] <kerio> rather than 4 different stereo languages or something [16:38:50 CET] <kerio> after you do that, transcode that to aac or somethign [16:38:59 CET] <kerio> you can keep the video as-is without transcoding [16:40:13 CET] <ewl> Checked the audio, it ain't different languages, some background noice without voices and stuff [16:41:08 CET] <ewl> I have to go for a while. I'll be back a bit later. Thanks for the help for now, kerio. I appriciate it very much. [16:41:27 CET] <kerio> so it's probably 7.1 audio [16:41:54 CET] <kerio> use the merge filter to put the channels together in the correct "place", transcode the audio to aac or something that can fit in a mp4, copy the video or transcode the video to h264 [16:55:48 CET] <MichaelVB> any news on a replacement for ffserver? [16:56:49 CET] <joaopinto> Hello good afdternoon [16:57:13 CET] <joaopinto> I am using ffplay in a demo and I detected a problem that might be a known issue for you [16:57:24 CET] <joaopinto> when playing a video [16:57:39 CET] <joaopinto> it is no able to detect its end [16:57:49 CET] <joaopinto> and tpo stop ffplay I must CTRL+C [16:58:05 CET] <joaopinto> and then in order to use ffplay again I have to restart the platform [16:58:13 CET] <durandal_1707> hmm, share sample? [16:58:13 CET] <joaopinto> is this a known issue for you? [17:18:11 CET] <ozette> does anyone know this type of mp4 container? "MSNV MPEG-4 (.MP4) for SonyPSP" is that actually a video meant for the sony psp? [17:21:47 CET] <joaopinto> ffplay: I make CTRL+C, and that aborts the application leaving the SDL mutex, from what I check in the code [17:22:01 CET] <joaopinto> what is the right way to exit gracefully from ffplay? [17:25:49 CET] <drv> hit 'q' [17:42:55 CET] <ozette> kerio: have you ever played video over the web succesfully providing application/octet-stream as mime type? [17:46:55 CET] <ozette> i can hardly believe it [17:56:51 CET] <ozette> i've been streaming and videos over the web for months, never has providing application/octet-stream worked for playback of videos in any major browser [17:58:42 CET] <ozette> determining by magic numbers is the only way, if you don't chose to transcode [18:10:03 CET] <ozette> i have a video file, when i use --mime-type on it, it only shows audio/mp4, how's this possible? is the video stream not recognized? [18:48:04 CET] <anime_ir1> Hi, I would like to ask a question regarding filter chains. [18:49:11 CET] <anime_ir1> Lets say I have a "mpeg2video (Main), yuv420p(tv, top first), 720x576 [SAR 64:45 DAR 16:9], 25 fps, [18:50:09 CET] <anime_ir1> and wanted to deinterlace with yadif and then convert with hevc_vaapi [18:53:26 CET] <Kafan> I cannot figure out how to google this properly, I just keep getting unrelated things. I'm encoding from a DVD, using -vf crop. ( command line: http://sprunge.us/DTRd ) [18:53:38 CET] <Kafan> This results in the subtitles being in the middl eof the video, however, instead of the bottom [18:53:45 CET] <Kafan> Presumably because their offset was not adjusted in the cropping process. [18:53:48 CET] <Kafan> How can I fix them? [18:54:05 CET] <Kafan> They are image-based subtitles, given that they are dvdsub [18:54:41 CET] <Kafan> Or, how do I google this properly. [19:10:24 CET] <Kafan> Ok, so I can maybe use -filter_complex crop on the subs, but I think this turns them into video streams. can I change them back somehow, or define the output codec of individual streams like that? [19:43:20 CET] <gabrieliv> Hi, I need to compile and run some ffmpeg code on a remote machine where I don't have root access to install ffmpeg-devel package. I've copied the ffmpeg source code snapshot to the remote machine and tried to compile my code with gcc -I/path/to/snapshot but, however, this fails due to the missing .so libraries (e.g. libavformat.so, libavcodec.so etc) that need to linked together with the object files into my executable. Is there any way I could some [19:43:20 CET] <gabrieliv> how obtain the .so files so that I'd could just use gcc -L and tell the compiler where to look for them and successfully build my code? [19:45:41 CET] <Kafan> You can probably copy them from any compatible system. [19:45:58 CET] <Kafan> If you have another system that's the same type (x86_64, etc) as the remote [19:46:09 CET] <Kafan> as long as you're certain about getting the same version [19:48:37 CET] <gabrieliv> OK, gonna have to try that [19:49:50 CET] <Kafan> ->lunch [19:49:50 CET] <Kafan> afk [19:53:39 CET] <jmaister> Hi [19:54:16 CET] <jmaister> Is it possible to start capturing a USB input device when video starts playing on the device, and trigger a script when video stops on the device? [19:56:31 CET] <BtbN> don't capture devices allways output a stream, but just a black one or a no signal screen when nothing is coming in? [19:57:42 CET] <jmaister> Yeah [19:57:55 CET] <jmaister> So, I guess I need to "listen" for a non-black frame [19:58:13 CET] <jmaister> then do the same for when the screen has been black for x seconds [19:59:39 CET] <BtbN> well, but what if the thing you catpture is actually black for a moment? [20:00:31 CET] <jmaister> Say, I set end-of-stream to 30 seconds. That should do it [20:00:45 CET] <jmaister> Then just trim the last 30 seconds of the recording [20:01:30 CET] <jmaister> Then reset and wait for another stream to start [20:03:41 CET] <jmaister> Preferably trigger a script as well [20:29:08 CET] <jmaister> Maybe it isn't possible to achieve [20:51:54 CET] <styler2go> Hey everyone. I am trying to compile ffmpeg but get the error libmp3lame >= 3.98.3 not found. But i just downloaded, compiled and installed the latest libmp3lame from sourceforge. any idea? [20:52:56 CET] <llogan> which OS? where did you install it? what is your ffmpeg configure? [20:53:52 CET] <furq> styler2go: the actual error will be near the end of config.log [20:54:01 CET] <furq> probably a header in the wrong place or something [20:54:07 CET] <styler2go> os is ubuntu, cross compiling to mingw32_64. cconfigure is: https://p.styler2go.de/42420/ also tried something like: https://p.styler2go.de/1807862/ [20:57:04 CET] <styler2go> furq: seems to be: /tmp/ffconf.8FDZowF1.c:1:23: fatal error: lame/lame.h: No such file or directory [20:57:16 CET] <llogan> you're using a patched source. FFmpeg does not have --enable-nvresize. nvenc does not need nonfree. [20:57:39 CET] <styler2go> llogan: yes, it's patched [20:57:53 CET] <llogan> officially we don't support unofficial sources [20:58:01 CET] <styler2go> that sentence sounds funny [20:58:09 CET] <styler2go> but i understand [20:58:39 CET] <styler2go> but i don't think it's a problem with the patch.. more like some lame issue... [20:58:54 CET] <llogan> what's the difference between nvresize and the supported scale_npp? [20:59:45 CET] <styler2go> i don't need nvresize, all i need is nvenc [21:00:03 CET] <llogan> then you don't need whatever outdated patch you used [21:00:11 CET] <styler2go> i've removed nvenc and git reset [21:00:27 CET] <styler2go> but yeah, i also need to checkout master again [21:01:12 CET] <llogan> where did you install lame to? [21:01:40 CET] <styler2go> ok, cleaned up that mess with the outdated nvidia patchfile [21:02:28 CET] <styler2go> when i use locate libmp3lame.a it tells me: /usr/lib/x86_64-linux-gnu/libmp3lame.a [21:02:55 CET] <furq> you need to compile all the dependencies with mingw [21:03:26 CET] <styler2go> oh god... ok thanks [21:05:29 CET] <llogan> you may find this helpful/intimidating: https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tediou… [21:07:11 CET] <styler2go> ok that's too much for me.. but thanks anyway [21:08:57 CET] <llogan> i mean you can pick and choose [21:09:23 CET] <furq> you're only building with two external libs [22:41:02 CET] <markvandenborre> is there any difference in forgiveness between an flv and an mp4 container, both with the same h264 video and aac audio [22:41:22 CET] <JEEB> ISOBMFF has much better support with regards to timestamp timebase [22:41:29 CET] <JEEB> FLV is always 1/1000 [22:42:30 CET] <furq> flv is a streaming container, mp4 usually isn't [22:42:49 CET] <furq> although if you don't need rtmp support then mpegts is probably a better choice than flv [22:45:08 CET] <JEEB> welcome to questions that aren't specific or aren't well worded :P [22:45:21 CET] <JEEB> you get a lot of randomness that might not be what you were asking about [22:46:21 CET] <furq> bless me, flv, for i have sinned [22:47:59 CET] <markvandenborre> thing is, we do our distribution of streams to our streaming backends for fosdem using nginx-rtmp, so flv by definition [22:48:22 CET] <markvandenborre> we then use nginx-rtmp to offer our users hls [22:48:35 CET] <markvandenborre> which is rather well supported on most FOSS platforms [22:48:48 CET] <markvandenborre> I want to make a dump of what we get there, and nginx-rtmp also provides for that [22:49:21 CET] <markvandenborre> but it would be much more useful to have it in mp4 format immediately than to first save it as flv, then convert it [22:49:46 CET] <markvandenborre> nginx-rtmp provides for fairly robust execution of external commands (ffmpeg...) [22:50:45 CET] <markvandenborre> but if my stream dies hard (simulated it by sigkill on the process that feeds rtmp into the nginx-rtmp based streaming backend) [22:51:09 CET] <markvandenborre> then even if ffmpeg closes properly with sigterm [22:51:45 CET] <markvandenborre> it will in some/most/all? cases get a truncated, useless mp4 stream [22:52:10 CET] <markvandenborre> JEEB: furq: hence my question if flv would be more robust than mp4 [22:53:02 CET] <markvandenborre> furq: your comment about flv being a streaming container seems to suggest that it will be a bit more forgiving [22:53:02 CET] <JEEB> fragmented mp4 will give you everything but the last GOP if you fragment at IRAPs [22:53:22 CET] <JEEB> (if a thing gets killed off suddenly) [22:53:28 CET] Action: markvandenborre starts searching for GOP and IRAP [22:53:29 CET] <JEEB> FLV depends on how the muxer writes it [22:53:41 CET] <JEEB> Group Of Pictures, IRAP to the next IRAP [22:53:49 CET] <JEEB> Intra Random Access Picture [22:53:54 CET] <markvandenborre> cool, thx [22:54:31 CET] <markvandenborre> so no idea why this sometimes gives me garble instead of something useful [22:55:07 CET] <markvandenborre> JEEB: this is the ffmpeg command called from nginx-rtmp: exec_push ffmpeg -i rtmp://localhost/stream/$name -codec copy /tmp/$name.mp4; [22:55:21 CET] <JEEB> because you don't fragment [22:55:39 CET] <JEEB> without movie fragments you get a single index after the file has been fully written [22:55:45 CET] <markvandenborre> I see [22:56:01 CET] <markvandenborre> strange that I could get this to play then anyway... [22:56:07 CET] <markvandenborre> in some circumstances [22:56:22 CET] <markvandenborre> trying to understand where my thinkos are [22:56:36 CET] <JEEB> you can only play that if the process finished in one way or another [22:57:04 CET] <JEEB> -movflags empty_moov+frag_keyframe [22:57:12 CET] <JEEB> will fragment at each IRAP [22:57:28 CET] <markvandenborre> k, thx [22:57:35 CET] <JEEB> you can actually do it even shorter so your loss is less if the process gets killed suddenly [22:57:37 CET] <markvandenborre> ah, yes, I killed it with SIGTERM [22:57:51 CET] <JEEB> yeah, if you let it do a proper stop then all's good [22:58:05 CET] <JEEB> it will flush the muxer and write index [22:58:05 CET] <markvandenborre> JEEB: suggestions welcome about this even shorter loss [22:58:46 CET] <markvandenborre> trying out with the options you just suggested [22:58:53 CET] <markvandenborre> really really thankful for your hints! [22:59:17 CET] <furq> you could also use mpegts in that exec_push and then remux to mp4 for streaming [22:59:35 CET] <JEEB> use -max_frag_duration of a single video frame if you're dealing with constant frame rate [22:59:48 CET] <JEEB> that way each video frame gets its own fragment [22:59:51 CET] <furq> fragmented mp4 is probably ok though [22:59:53 CET] <JEEB> perverse, but works :P [22:59:58 CET] <markvandenborre> :-) [23:00:23 CET] <markvandenborre> you are both amazing! [23:00:46 CET] <markvandenborre> JEEB: aaah, I love it when perversity works :p [23:01:06 CET] <furq> what's wrong with nginx-rtmp's recording stuff [23:01:19 CET] <JEEB> and frag_duration is in microseconds according to ffmpeg-all [23:01:21 CET] <furq> i take it you'd rather not have to remux separetely [23:01:27 CET] <JEEB> (it wasn't max_frag_duration) [23:01:30 CET] <furq> separately [23:01:39 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#Options-38 [23:01:51 CET] <markvandenborre> furq: it only records to flv [23:02:18 CET] <markvandenborre> and if we can, we want to use the nginx-http-mp4-module [23:02:33 CET] <markvandenborre> to allow proper pseudocutting throughthe browser [23:02:53 CET] <markvandenborre> for which we would need faststart [23:03:00 CET] <markvandenborre> on mp4 files [23:03:20 CET] <markvandenborre> so we would need to go through some kind of conversion anyway [23:03:28 CET] <JEEB> fragments pretty much give you faststart :P [23:03:43 CET] <JEEB> unless that module doesn't habla movie fragments [23:10:07 CET] <markvandenborre> JEEB: I'm not claiming to understand it all, but... will the flags you just suggested to me (and that work brilliantly btw) [23:10:31 CET] <markvandenborre> be mutually exclusive with -movflags +faststart in any way? [23:10:45 CET] <markvandenborre> I understand that this moves the MOOV atom to the front [23:10:57 CET] <markvandenborre> so I would expect that this might be problematic [23:11:00 CET] <markvandenborre> or not so much? [23:11:06 CET] <furq> i don't think fragmented mp4 has a moov atom [23:11:15 CET] <furq> it has a moof atom in each fragment which does the same thing [23:11:16 CET] <markvandenborre> I see [23:11:48 CET] <JEEB> MOOV is the index, and fragments pretty much have their own smaller indexes [23:12:00 CET] <JEEB> MOOF being movie fragment thing [23:12:18 CET] <axdds34> hello [23:13:33 CET] <markvandenborre> JEEB: so I would need to reindex the resulting file separately in any case [23:13:42 CET] <JEEB> umm [23:13:49 CET] <JEEB> fragmented ISOBMFF doesn't really need an index [23:14:08 CET] <JEEB> the only issue is if your thing that you feed it to later doesn't support proper fragmented ISOBMFF [23:14:12 CET] <markvandenborre> but we need it for this pseudocutting is relying on it [23:14:17 CET] <markvandenborre> indeed [23:14:35 CET] <JEEB> well, I recommend you try it first and then see [23:14:42 CET] <markvandenborre> just did :-( [23:14:47 CET] <JEEB> oh well [23:15:12 CET] <JEEB> (*Ž [23:15:16 CET] <axdds34> hello someone can help me with ffmpeg instalation? [23:18:36 CET] <markvandenborre> axdds34: sorry mate, haven't used anything but linux in the last 20years... [23:19:02 CET] <axdds34> no problem mark, thank you! ;) [23:19:11 CET] <markvandenborre> so unless you are using a linux distro (in which case ffmpeg should be trivially available using your package manager, I won't be able to help you) [23:20:31 CET] <furq> assuming he's using a newish distro [23:21:02 CET] <axdds34> some one can send me simple code for try ffmpeg in ssh? [23:21:05 CET] <unkmar> markvandenborre: not entirely. [23:21:47 CET] <axdds34> im install it with yum install ffmpeg [23:22:02 CET] <axdds34> maybe work ok, and now need some code for try :) [23:23:11 CET] <markvandenborre> unkmar: ? [23:28:45 CET] <markvandenborre> JEEB: I'm trying to understand conceptually what I could do to get to a reliable MOOV atom at the beginning of the file in as few steps as possible [23:28:55 CET] <markvandenborre> (if that is possible at all) [23:29:31 CET] <markvandenborre> without fragmenting, I will have an unreliable truncated mp4 with I suspect the MOOV atom somewhere near the end and garbled [23:29:40 CET] <markvandenborre> with fragmenting, I get something usable [23:30:27 CET] <markvandenborre> in the sense of technically ok mp4 container [23:30:49 CET] <unkmar> I've had compatibility issues with... [23:30:58 CET] <unkmar> I don't know what a MOOV atom is. [23:30:59 CET] <markvandenborre> but the information I need is spread all over the file [23:32:23 CET] <unkmar> I've had compatibility issues with my Debian 8. Forced to use backports, and I get .. Eh, Probably could fix things if I just download and compile. Right, Compile. Because nothing should ever have to be compiled in a completed project. Wait, apparently everything needs to be compiled every time. Eh, Whatever. I'll just run gentoo. It always compiles. [23:32:41 CET] <unkmar> Seriously. I have plenty of rants. This ffmpeg problem of mine is just one of them. [23:34:44 CET] <markvandenborre> unkmar: are you a trollbot, or just don't know how to behave in an irc channel yet? if the second thing is the case: when asking a question, please be specific, listening and respectful [23:36:00 CET] <markvandenborre> your ranting fails on all three criteria [23:36:46 CET] <unkmar> Neither. I'm a veteran to IRC and just absolutely tired of being burned by so many problems. I'm not currently asking for help about a problem. I don't have time to attempt to fix my ffmpeg issue at the moment. It may be days before I get around to that again. [23:37:16 CET] <unkmar> And furq has been exceptionally helpful. [23:37:40 CET] <unkmar> I often have problems that just don't get fixed easily. It is me, I should be a beta tester or something. [23:37:44 CET] <markvandenborre> in that case, sorry to hear you had a bad day, and my hopes for the best [23:37:58 CET] <markvandenborre> that they may get solved eventually [23:38:27 CET] <markvandenborre> unkmar: https://webvideo.wikischolars.columbia.edu/H.264+HTTP+Web+Notes says something at least about the MOOV atom [23:39:02 CET] <unkmar> markvandenborre: Thank you. My most recent issue is with cordova and just getting the thing to use MY icon for the smartphone app instead of Cordova's default. I managed to brute force past it for the moment. But my fix is clearly the wrong way to do it. [23:39:40 CET] <unkmar> And the #cordova channel has been.... Uh, Silent. I guess they don't get many visitors. [23:41:17 CET] <unkmar> markvandenborre: Holy crap. Looks like you take on problems as big as I do. Web streaming is why I'm here. Well, a part of my problems I hope to fix. [23:41:59 CET] <unkmar> Well, good luck with the MOOV atom. [23:42:14 CET] <markvandenborre> :-) [23:51:24 CET] Action: markvandenborre is looking up how I can distinguish a MOOF based/fragmented mp4 versus a MOOV based one [23:51:49 CET] <markvandenborre> mediainfo and ffprobe seem not to yield any relevant info [23:52:23 CET] <kerio> markvandenborre: cant you just -movflags +faststart [23:57:58 CET] <markvandenborre> kerio: yes, that would work as a single, rather cpu and disk intensive postprocessing step [23:58:10 CET] <markvandenborre> (I did have a look with qt-faststart) [23:58:11 CET] <kerio> how's it cpu intensive? [23:58:22 CET] <kerio> it's a remux [23:58:30 CET] <furq> it's not cpu intensive but it does thrash your disk [23:58:32 CET] <markvandenborre> sorry, meant disk intensive [23:58:43 CET] <furq> running several at once on spinning rust is a good way to have a bad time [23:58:56 CET] <kerio> the solution is obviously to use mkv in the first place :^) [23:59:02 CET] <furq> ask me about my ill-advised xargs remuxing script [23:59:10 CET] <kerio> hey furq [23:59:13 CET] <kerio> i have a question for you [23:59:20 CET] <furq> what is it my child [23:59:27 CET] <markvandenborre> "what about your ill-advised xargs remuxing script"? [23:59:30 CET] <kerio> what's your favourite gen 7 starter and why is it rowlet [23:59:38 CET] <furq> it's popplio [23:59:44 CET] <kerio> get the fuck outta here [23:59:47 CET] <furq> i don't know what that is but i heard some people say it recently [00:00:00 CET] --- Wed Nov 23 2016

1 0

ffmpeg-devel.log.20161121
by burek 22 Nov '16

22 Nov '16

[12:18:31 CET] <j-b> wm4: sorry, but we receive way more requests for pps and ppsx than doc. :D [14:03:52 CET] <FernetMenta> ping @michaelni [14:04:30 CET] <FernetMenta> we, kodi, tracked down an issue to this change http://ffmpeg.org/pipermail/ffmpeg-devel/2013-May/143953.html [14:05:26 CET] <wm4> what does that even mean [14:05:33 CET] <wm4> the commit description I mean [14:05:38 CET] <FernetMenta> after a seek in a file with subtitles demuxer reads up to 80MB until it returns first packet [14:06:12 CET] <FernetMenta> decrementing index_min-- seems not correct to me [14:06:21 CET] <wm4> why can't the demuxer just do things right [14:06:59 CET] <wm4> it's full of idiotic hacks and shit... I guess I'll keep my own demuxer for the time being [14:10:06 CET] <wm4> I think it's some sort of hack to get subtitles show up if you seek to a specific position [14:15:29 CET] <nevcairiel> probably, should just dump those hacks and use the matroska cues for that [14:15:35 CET] <nevcairiel> and if a file doesnt have any, too bad [14:15:54 CET] <wm4> this hack works only for parts of the file libavformat has indexed [14:16:09 CET] <wm4> (so parts that have been demuxed, or if the seek index is fully missing) [14:16:36 CET] <wm4> so in theory it could do the right thing (though not sure what it does) [14:16:53 CET] <FernetMenta> currently it results in a long stall when the file is on a network drive [14:18:10 CET] <wm4> does it happen when there are actually subtitles overlapping with the seek target? [14:19:01 CET] <FernetMenta> http://trac.kodi.tv/ticket/15935 [14:19:17 CET] <FernetMenta> ^^ there is a sample attached close to last post [14:20:23 CET] <FernetMenta> well looking at the code decrementing index_min seems wrong [14:20:53 CET] <FernetMenta> reverting this change fixes the issue [14:21:16 CET] <wm4> it's not clear what the commit is supposed to do in the first case [14:21:27 CET] <wm4> and it was also done without "testcase" [16:16:00 CET] <philipl> anyone willing to review the P016 format patches? They're pretty much carbon copies of nevcairiel's original P010 ones. I'd like to get the cuvid stuff unblocked. [16:44:34 CET] <kierank> stupid hardware and MSB packed video [17:47:59 CET] <kierank> who is datenwolf [17:49:19 CET] <wm4> some guy who got trolled by the pulseaudio creator [17:58:27 CET] <nevcairiel> philipl: as long as you took out the shifts when copying the sws stuff :D [18:24:57 CET] <philipl> nevcairiel: I did :-) [18:31:31 CET] <cone-568> ffmpeg 03Ludmila Glinskih 07master:5f4e555dc7ca: MAINTAINERS: add myself as an API tests maintainer [18:38:00 CET] <DHE> opinion question. would a patch to ffmpeg (the main cli app) to enable threading of output streams be well received? I have a workload that I believe would benefit from it (multiple outputs from a single input) [18:56:10 CET] <atomnuker> yay, my opus encoder works: https://pars.ee/temp/128k_960.opus [18:56:52 CET] <atomnuker> pretty decent for something without a psychoacoustic system yet, 1 transform size and fixed bit allocation [19:05:20 CET] <durandal_1707> nice [19:54:23 CET] <cone-568> ffmpeg 03Matthew Gregan 07master:7dc4200c3828: Add experimental muxing support for FLAC in ISO BMFF (MP4). [19:54:24 CET] <cone-568> ffmpeg 03Matthew Gregan 07master:2d73d25670ce: Add experimental demuxing support for FLAC in ISO BMFF (MP4). [20:08:34 CET] <cone-568> ffmpeg 03Matthew Gregan 07master:156fbbb562f3: avformat/movenc: Restrict experimental VP9 support to MODE_MP4. [22:54:27 CET] <atomnuker> BBB: would it be a good idea to maybe encourage that? [22:54:50 CET] <BBB> why? [22:54:53 CET] <atomnuker> I haven't heard of anything not using 32 bits for unspecified size ints but you know, you never know [22:55:09 CET] <BBB> ffmpeg requires 32bit for int and unsigned [22:55:24 CET] <atomnuker> huh, okay [22:55:32 CET] <BBB> it wont work without it [22:55:57 CET] <BBB> the advantage of letting a system use native size is that if unsigned is for whatever stupid reason 64bit, we dont force truncation after every instruction [22:56:11 CET] <BBB> which is ofc why it only works for non-array items [22:56:38 CET] <BBB> (otherwise arrays grow to sizes they were never intended to grow to; but for scalars, you dont care) [22:56:51 CET] <atomnuker> uint32_t's looks neater though :) [22:56:55 CET] <BBB> btw congrats on your opus encoder [22:56:58 CET] <BBB> encoders suck :-p [22:58:39 CET] <atomnuker> wut, encoders rule [22:59:37 CET] <atomnuker> although if whatever comes after opus uses non-power-of-two framesizes I will research a way to send tapeworms over standard email/whatever comes after email [23:01:13 CET] <wm4> sounds useful [23:02:55 CET] <BBB> using encoders is awesome [23:03:04 CET] <BBB> writing encoders is painful [23:03:11 CET] <BBB> theres so much you need to get right [23:03:33 CET] <BBB> its fun, dont get me wron [23:03:45 CET] <BBB> but it feels endless :) [23:06:45 CET] <wm4> not much different with libraries gluing together and such [23:12:05 CET] <wm4> (except the fun part) [23:14:41 CET] <atomnuker> it's fun because it's just numbers so you can fprintf your way [23:14:59 CET] <atomnuker> it's even more fun with opus because celt is hardcode cbr but I'll make it as vbr as possible [23:19:07 CET] <cone-568> ffmpeg 03Mark Thompson 07master:06d73d002e7f: vaapi_h264: Fix HRD bit_rate/cpb_size scaling [23:19:08 CET] <cone-568> ffmpeg 03Mark Thompson 07master:c8241e730f11: vaapi_encode: Refactor initialisation [23:19:09 CET] <cone-568> ffmpeg 03Mark Thompson 07master:478a4b7e6d3e: vaapi_encode: Check packed header capabilities [23:19:10 CET] <cone-568> ffmpeg 03Mark Thompson 07master:94f446c628bb: vaapi_encode: Sync to input surface rather than output [23:19:11 CET] <cone-568> ffmpeg 03Mark Thompson 07master:ee1d04f970b0: vaapi_h264: Set max_num_ref_frames to 1 when not using B frames [23:19:12 CET] <cone-568> ffmpeg 03Mark Thompson 07master:ded1859df17f: vaapi_encode: Decide on GOP setup before initialising sequence parameters [23:19:13 CET] <cone-568> ffmpeg 03Mark Thompson 07master:658c5afaa010: vaapi_h264: Fix CFR mode with frame_rate set in AVCodecContext [23:19:14 CET] <cone-568> ffmpeg 03Mark Thompson 07master:6796e6ea84f0: vaapi_h264: Write bitstream restriction fields [23:19:15 CET] <cone-568> ffmpeg 03Mark Thompson 07master:ae0230cc3e24: vaapi_h265: Fix slice header writing [23:19:16 CET] <cone-568> ffmpeg 03Mark Thompson 07master:30ebabca7c3a: vaapi_h265: Fix buffering parameters [23:22:24 CET] <jya> BBB: ping [23:22:36 CET] <BBB> jya pong [23:22:59 CET] <jya> BBB: we're looking at adding transparency support with webm/vp9 [23:23:14 CET] <BBB> oh, thats easy [23:23:25 CET] <BBB> wait didnt we have a patch for that already? [23:23:28 CET] <BBB> I dont remember [23:23:31 CET] <BBB> maybe Im imagining things [23:23:45 CET] <wm4> does vp9 have an alpha pixfmt or is this about the vp8 hacks [23:23:50 CET] <BBB> its trivial, just instantiate a second instance of the decoder in the first if theres an alpha side-data in the input AVPacket [23:23:55 CET] <BBB> wm4: hacks again [23:24:03 CET] <jya> the structure appear rather non-obvious. So we alpha channel needs to be decoded separately from the rest, so we need a second AVCodecContext? [23:24:23 CET] <BBB> let me see if I can get you an example [23:24:53 CET] <wm4> "it's trivial, just add a mess" [23:25:47 CET] <jya> wm4: sounds like a fairly good description :) [23:26:12 CET] <BBB> huh, the alpha patch is missing from libvpxdec [23:27:21 CET] <BBB> oh I was in branchy mode [23:27:24 CET] <BBB> erase that [23:27:28 CET] <wm4> (would be nice though if libavcodec could just transparently do the alpha decoding mess behind the scenes, but I guess it's not feasible?) [23:27:49 CET] <BBB> its AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL [23:28:12 CET] <BBB> jya: look at how libavcodec/libvpxdec.c handles AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL [23:28:25 CET] <BBB> jya: and then just replicate that exactly in vp9.c and vp8.c [23:28:54 CET] <BBB> jya: Im happy to lend a helping hand in details etc., itd be cool to support even if that way its implemented is a little hacky [23:29:03 CET] <BBB> dont want to be too purist about it [23:30:56 CET] <BBB> jya: and I personally think its fine if VP9Context just has an additional VP9Context in it that is the alpha channel or something like that, or even a AVCodecContext& I dont know what the easiest way to do this is, dont want to duplicate too much but also dont want to re-write half the decoder, right? [23:31:12 CET] <wm4> BBB: isn't that a big problem due to frame threading? [23:31:32 CET] <BBB> why? [23:31:43 CET] <BBB> the decoder returns a single AVFrame containing YUVA420P data [23:31:53 CET] <BBB> it should be transparent to the threading layer [23:32:22 CET] <wm4> I mean doesn't the threading layer distribute the input packets to the worker threads (I may have forgotten or never known how exactly this works at all) [23:33:15 CET] <BBB> it does, but the blockadditional is there also [23:36:33 CET] <voip_> Hello guys, I have problem with retrieving video from YouTube: [tls @ 0x55f43a0] The TLS connection was non-properly terminated. [23:37:04 CET] <Chloe> voip_: wrong channel [23:37:14 CET] <Chloe> #ffmpeg [23:37:19 CET] <voip_> ok [23:38:00 CET] <jya> BBB: ok, so simply avec a 2nd AVCodecContext, and decode the alpha bit separately, and then combine all that later for display in a magic soup. [23:38:11 CET] <BBB> avec :D [23:38:23 CET] <jya> is it missing any piece of code in ffvp9? [23:38:30 CET] <kierank> wow people actually use that functionality [23:38:39 CET] <BBB> ffvp9 needs to instantiate the second avcodeccontext, right? [23:38:46 CET] <BBB> this should be transparent to the user [23:39:01 CET] <BBB> its a little strangely recursive in that it means ffvp9 internally actually has a second instance of itself [23:39:05 CET] <BBB> but thats just how life is [23:39:06 CET] <TD-Linux> kierank, last step to replace gif [23:39:10 CET] <jya> BBB: ah it's all done internally ? cool [23:39:20 CET] <kierank> TD-Linux: Hello guys, I have problem with retrieving video from YouTube: [tls @ 0x55f43a0] The TLS connection was non-properly terminated. [23:39:22 CET] <kierank> that one [23:39:23 CET] <BBB> well its not yet, but youll provide a patch to do that :-p [23:39:35 CET] <jya> so just need to add the logic to add the alpha channel to the AVPacket being decoded [23:40:32 CET] <jya> BBB: uh what ? I'm confused now... [23:41:00 CET] <BBB> libavcodec/libvpxdec.c handles the alpha channel provided as AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL [23:41:05 CET] <wm4> there are 2 ways how you could implement it [23:41:05 CET] <BBB> libavcodec/vp9.c does not yet [23:41:17 CET] <wm4> either outside of ffmpeg by just creating two decoders manually [23:41:22 CET] <BBB> so you need to add the code to libavcodec/vp9.c to do that [23:41:25 CET] <wm4> or creating a second decoder within ffvp9 [23:41:45 CET] <wm4> and the second choice is nicer for the API user [23:42:55 CET] <wm4> (and BBB is talking about how to add the second one) [23:43:14 CET] <BBB> right [23:43:48 CET] <BBB> if you do the first, it just works with no effort whatsoever, but its not transparent, that is, users that use the plain API wont get this feature, and if someone eventually implements it, this will break your code :-p [23:44:16 CET] <wm4> even with the second one you have to awkwardly match frames from the 2 decoders [23:45:41 CET] <BBB> wait what? [23:45:45 CET] <BBB> I dont think you do [23:45:53 CET] <BBB> vp9 has no delay its 1-in-1-out [23:46:16 CET] <BBB> so the internal alpha decoder just decodes one frame for every input, merges that into the existing 420 data as new alpha plane [23:46:19 CET] <BBB> and & were done! [23:46:20 CET] <BBB> right? [23:47:41 CET] <wm4> vp9 at least discards superframes or whatever they're called, so it's 1-in-0-or-1-out... then add threading, and what if decoding a frame fails? still seems all sorts of annoying and fragile [23:49:02 CET] <BBB> alt-ref frames :-p [23:49:27 CET] <BBB> superframes are structures that combine alt-ref frames and subsequent visible frames in one AVPacket so that to the container level it looks like 1 frame [23:49:47 CET] <BBB> but the alt-ref would consist of one alt-ref 420 and one alt-ref alpha blockadditional [23:50:08 CET] <BBB> (I assume?) [23:50:41 CET] <jya> BBB: at this stage, I prefer to do it all outside of ffvp9, and simply have two decoders setup. much easier. Remember that we build our own AVPacket, we don't use ffmpeg demuxer, so the alpha channel will never be found in the AVPacket unless we decide to [23:50:57 CET] <BBB> hm& ok [23:51:05 CET] <BBB> then yes you shouldnt need to do anything special [23:51:20 CET] <jya> BBB: well, it's not always 1:1, if you have multi-threading enabled no? [23:51:26 CET] <BBB> just read the blockadditional data from the webm container, send that into a second instance of the decoder, and merge them together [23:51:32 CET] <wm4> it wouldn't be hard to build an avpacket with the blockadditional [23:52:08 CET] <BBB> (merge them together being add the y plane of the alpha decoder as a plane of the i420 decoder and you have yuva420p! [23:52:09 CET] <BBB> ) [23:52:34 CET] <BBB> anyway well add alpha decoder support inside ffvp8/9 later& just not very urgent [23:52:39 CET] <BBB> its kind of & a fringe feature :-p [23:53:15 CET] <wm4> it's a "wtf was google thinking" feature (though AFAIK they came up with 3 different ideas) [23:53:46 CET] <BBB> there was - at some point - code to do variable plane counts in libvpx [23:53:50 CET] <BBB> I dont know what happened to that [23:53:53 CET] <atomnuker> it's the mpng school of development, except with only 1 thing written [23:54:17 CET] <BBB> (the intention of that was indeed to code the alpha plane inside the i420 vp9 bitstream) [23:55:03 CET] <BBB> gotta run home, bbl& jya: if you have issues getting it to work, feel free to poke me. but it should be fairly simple [23:55:18 CET] <jya> BBB: i will thanks for the pointers [23:55:44 CET] <jya> may look at doing it from the ffvp9 side of things. [23:55:55 CET] <jya> that would be more beneficial for the community than hack around it [00:00:00 CET] --- Tue Nov 22 2016

1 0

ffmpeg.log.20161121
by burek 22 Nov '16

22 Nov '16

[02:03:16 CET] <issfd> Hi guys, [02:05:12 CET] <issfd> Hi guys, I'm wondering if there is a way to use ffmpeg to concatenate several pics specifying the time stamp where they should start. [02:05:33 CET] <issfd> reading the path and time from a .txt [02:10:37 CET] <DHE> not like that I don't think, but maybe with complex filters you could build a "pipeline" [05:20:43 CET] <Hasan> HELP [05:21:23 CET] <furq> what a nice young man [05:23:12 CET] <dsc_> hALP [11:04:09 CET] <yanzay> Hi guys, I'm trying to set up live streaming (FullHD, H.265) using ffmpeg. First, video stream goes to nginx-rtmp, then it launches ffmpeg and final destination is ffserver. I have a problem with latency here, it's about 4-5 second, any tips how I can improve it? Ideally latency should be less then 1 second. Launch command and ffserver.conf: http://pastebin.com/UcBFWtaS. Maybe there is a way to trace where delays are? [11:06:37 CET] <markvandenborre> yanzay: why all these intermediate steps? [11:06:53 CET] <markvandenborre> why not just throw the ffmpeg rtmp at nginx-rtmp and be done with it? [11:07:10 CET] <markvandenborre> I might not understand what you are trying to accomplish [11:08:18 CET] <BtbN> 4-5 seconds is quite good. Also, forget about ffserver. [11:08:31 CET] <yanzay> nginx-rtmp does not accept H.265 encoded video, as I understand. It consumes H.264 and when I try to push transcoded to H.265 it just doesnt publish anything [11:08:33 CET] <BtbN> And you need one hell of a CPU to encode hevc in real time. [11:09:24 CET] <yanzay> I have the biggest amazon instance on it, c4.4xlarge, CPU load is about 70% [11:09:42 CET] <BtbN> And why the whole effort? There are barely any clients capable of playing it. [11:09:47 CET] <BtbN> Just go with h264 [11:10:22 CET] <yanzay> h265 is a requirement, so I cant go with h264 [11:10:46 CET] <BtbN> good luck finding compatible software then. There is no h265 in flv specified nor supported [11:11:04 CET] <yanzay> yeah, thats why I use mpegts [11:11:12 CET] <BtbN> rtmp is flv. [11:12:36 CET] <markvandenborre> yanzay: what kind of client is going to consume your h265 stream? [11:12:48 CET] <yanzay> is there any other servers so I can replace ffserver to stream h265? [11:13:06 CET] <yanzay> VLC, for example [11:13:41 CET] <BtbN> Your clients will also need a very powerful CPU to play that [11:13:52 CET] <BtbN> hevc is just not ready for wide usage yet. [11:49:30 CET] <kerio> how do you stream mpegts one-to-many? [11:49:52 CET] <kerio> BtbN: can you do HLS with hevc? [12:00:12 CET] <markvandenborre> kerio: you could under some circumstances do udp multicast [12:00:25 CET] <markvandenborre> depending on what you need [12:00:26 CET] <kerio> markvandenborre: no but like [12:00:29 CET] <kerio> on the internet [12:00:46 CET] <markvandenborre> throw it at nginx-rtmp? [12:00:56 CET] <kerio> i thought rtmp was only flv [12:01:04 CET] <kerio> and there was no hevc in flv [12:01:11 CET] <markvandenborre> correct [12:01:18 CET] <markvandenborre> you didn't ask about hevc? [12:01:35 CET] <kerio> i asked about mpegts [12:01:39 CET] <kerio> for the specific purpose of avoiding flv [12:01:51 CET] <markvandenborre> well, you use that as your transport [12:02:04 CET] <markvandenborre> then use the nginx-rtmp hls functionality [12:02:19 CET] <markvandenborre> so you end up with hls fragments published by nginx-rtmp [12:02:27 CET] <markvandenborre> ts fragments [12:02:50 CET] <markvandenborre> what we do is exactly that [12:02:52 CET] <kerio> how do i send the video to nginx tho [12:02:57 CET] <markvandenborre> rtmp... [12:03:07 CET] <markvandenborre> from ffmpeg [12:03:57 CET] <markvandenborre> kerio: you may want to have a look at https://github.com/FOSDEM/video for inspiration [12:04:20 CET] <markvandenborre> we're still finishing the ansible deployment, but it might give you some ideas [12:04:33 CET] <kerio> markvandenborre: i still don't understand how nginx-rtmp will help me publish hevc through hls [12:04:40 CET] <kerio> since the only ingest is rtmp, aiui [12:26:19 CET] <markvandenborre> it won't [13:32:20 CET] <Mockarutan> I wrote here yesterday, but got no response. I'll try again: AAC encoding, I'm stuck. My code http://pastebin.com/5Tvs19Am . It procudes a file with no sound in it. Feel free to point out anything tha might be wrong. A great start would be to make sure my synthetic sound is generated and transfered to the AVFrame correctly. Anybody who could help? [14:44:41 CET] <Nacht> Hey. I seem to have an issue which is driving me mad. We got a couple of HLS streams which we take the TS files from and merge a few together. Only, one of the HLS streams seems to have severe lipsync problems. Using async 1 -reset_timestamps 1 -fflags +genpts seems to help a bit, but not enough. Are there any ways to analyse where the lipsync problem may originate from ? [17:21:57 CET] <Guest27954> Hi friends, somebody already got this error? "[decklink @ 0x2a187c0] > Decklink input buffer overrun!" and know how to solve it? [17:36:08 CET] <BtbN> read the input buffer faster [17:51:56 CET] <dviola> hi [17:52:02 CET] <dviola> is there a way to capture from a pulse stream? [17:52:22 CET] <dviola> and output to a file [18:26:44 CET] <kepstin> dviola: sure, something like 'ffmpeg -f pulse -i default recording.opus' [18:26:55 CET] <kepstin> replace 'default' with the name of the stream/device to use [18:27:32 CET] <dviola> thanks [18:59:41 CET] <dviola> how can I get a list of streams? [19:00:02 CET] <dviola> I think it would be monitor or something like that [19:05:03 CET] <yury-linux> Hello, I'm trying to automate building ffmpeg and having problems with specifying output directory of relevant files after build. I tried --prefix=$PREFIX, but it seems like it is for install... [19:05:42 CET] <JEEB> it's for make install, yes. for when you want to put files into the place where you want to utilize them from [19:05:59 CET] <JEEB> for build time stuff just call configure from another dir [19:06:09 CET] <JEEB> that will then create required things for out-of-tree build [19:06:32 CET] <yury-linux> hm, lemme try [19:11:45 CET] <yury-linux> JEEB, I'm getting Out of tree builds are impossible with config.h in source dir. [19:11:58 CET] <yury-linux> JEEB, I'm getting "Out of tree builds are impossible with config.h in source dir." [19:12:05 CET] <JEEB> why would you have that? configure would create that [19:12:13 CET] <yury-linux> sorry, thought it would edit it [19:13:11 CET] <JEEB> if you have nothing in the source dir you want to keep, `git clean -dfx` is your friend if you want to clean things up [19:15:18 CET] <yury-linux> yup, that worked [19:15:29 CET] <yury-linux> I mean removing config.h [19:38:21 CET] <yury-linux> JEEB, how do I list/find all possible target-os values? [19:46:45 CET] <dviola> `ffmpeg -f pulse -i 1 recording.opus' worked fine [19:46:56 CET] <dviola> not sure if I should use 1 or something else, though [19:47:55 CET] <_Vi> FFmpeg can successfully encode animated webp with libwebp. Can it also decode it? [19:48:04 CET] <furq> yury-linux: https://github.com/FFmpeg/FFmpeg/blob/master/configure#L1674-L1770 [19:48:06 CET] <_Vi> Normally I just get "[webp @ 0x698220] skipping unsupported chunk: ANIM" [19:48:26 CET] <yury-linux> thanks [19:51:44 CET] <furq> yury-linux: https://github.com/FFmpeg/FFmpeg/blob/master/configure#L4644-L4900 [19:51:48 CET] <furq> apparently i can't read today [19:54:42 CET] <dviola> oh, pavucontrol will show the device it's recording it from [19:54:44 CET] <dviola> cool [19:57:21 CET] <Guest27954> Hi friends, somebody already got this error? "[decklink @ 0x2a187c0] > Decklink input buffer overrun!" and know how to solve it? [19:57:50 CET] <Len> hello guys [19:58:33 CET] <Len> can I somehow ignore this "av_interleaved_write_frame(): Immediate exit requested" ? I have script which is spawning workers and it seems like my whole script is blocked on this event [20:15:12 CET] <yury-linux> furq can I somehow cross-compile the thing for macos from linux? [20:16:20 CET] <furq> probably, i cross-compile for windows on linux [20:16:26 CET] <furq> i don't know what toolchain you'd need for osx though [20:18:09 CET] <yury-linux> I was able to build it for win and linux (untested yet), but osx does not even builds [20:51:39 CET] <unkmar> yury-linux: I have been writing a Smartphone app that is suppose to available for Andriod and iPhone. I can build Android from any OS. The iPhone build requires signatures and XCode to build, and is only available via Mac OS. [20:53:08 CET] <unkmar> Either through a hackintosh, virtual machine, or real Mac. Unless you have incredible amounts of time available, simply buying the Mac and required license appears to be the quickest, easiets, and cheapest way to go. [20:55:20 CET] <unkmar> In this case, you would be trading your time for money. Spend the money, or the time. The time to money ratio can easily drop well below minimum wage. [20:57:04 CET] Action: unkmar is now known as that previously bitter guy that has gone overly verbose to releave the stress build up from all the projects that don't work. [20:58:06 CET] <unkmar> furq: When will you be at a linux box again? [21:27:57 CET] <yury-linux> unkmar maybe I can spin up a Travis CI machine and try to upload build artifacts somewhere? [21:28:06 CET] <yury-linux> should work [21:28:55 CET] <yury-linux> this way I don't have to buy anything [21:34:55 CET] <ibisr> ffmpeg -ss 72.072 -i http://localhost:3020/static/35_4_A97mov.mov -copyts -to 84.084 -an -dn -c:v libx264 out.ts [21:35:35 CET] <ibisr> oops, sorry about that [21:37:04 CET] <curioususer> Is there a way to specify the client cert and key file when using an https url as the input source? [22:18:45 CET] <Guest63318> Hello guys, how can i grab vieo from youtube and create live stream ? [22:51:47 CET] <voip_> Hello guys, how can i grab vieo from youtube and create live stream ? [22:52:39 CET] <llamapixel> so voip_ I know you can use youtube-dl to get the files off the site but I dont know how to stream that afterwards. ffmpeg newbie [22:54:37 CET] <voip_> i con i can donload as file then start live streaming, but i dont need to download [22:55:42 CET] <furq> youtube-dl -o - | ffmpeg -i - ... [23:04:28 CET] <llamapixel> Technically that is still saving it to a cache or downloading it. [23:04:53 CET] <furq> well yeah [23:05:01 CET] <furq> i'm assuming he doesn't own youtube, so that'll be required [23:05:59 CET] <voip_> thank you [23:09:37 CET] <voip_> https://www.youtube.com/watch?v=q82Guo5HPRw [23:09:55 CET] <voip_> The TLS connection was non-properly terminated. [23:09:55 CET] <voip_> https://www.youtube.com/watch?v= [23:35:32 CET] <wCPO_irssi> Is there any selfhosted ffmpeg queue solution with web api? [23:37:07 CET] <DHE> like uploading to a remote system for bulk processing? [23:37:35 CET] <voip_> guys, I have problem with retrieving video from YouTube: [tls @ 0x55f43a0] The TLS connection was non-properly terminated. [23:37:55 CET] <wCPO_irssi> DHE: Yes, just wondering if someone has already created something [23:41:57 CET] <llogan> voip_: AFAIK you can't directly download video from youtube using ffmpeg alone. [23:44:12 CET] <wCPO_irssi> voip_: youtube-dl is the eastiest solution I think.. [23:45:07 CET] <voip_> hi llogan, how i can live stream video form YouTube without downloading whole file, on fly ? [23:45:24 CET] <llogan> you can't [23:45:25 CET] <voip_> wCPO_irssi, i cant donload whole file [23:45:37 CET] <voip_> llogan, thanks [23:46:46 CET] <iive> if it is http, some players can do partial downloads in memory [23:47:01 CET] <iive> mpv, vlc [23:47:33 CET] <wCPO_irssi> voip_: Sorry, I don't understand? I can download the whole video including audio with youtube-dl without issue? [23:50:55 CET] <voip_> wCPO_irssi, i meant for example for downloading big YouTube file I will need time and space on my servers. I cant download too much files. If it possible i want download with same portions and directly live stream [23:58:33 CET] <unkmar> voip_: Are you wanting both the audio and video? Is screen or window capture an option? Is audio only reasonable? Which OS are you trying to use? [00:00:00 CET] --- Tue Nov 22 2016

1 0

ffmpeg-devel.log.20161120
by burek 21 Nov '16

21 Nov '16

[00:14:49 CET] <cone-137> ffmpeg 03James Almer 07master:0ffea3565700: avformat/utils: check for overflow before reallocating side data [00:28:07 CET] <cone-137> ffmpeg 03James Almer 07master:574929d8b6de: avcodec/avpacket: fix leak on realloc in av_packet_add_side_data() [00:28:08 CET] <cone-137> ffmpeg 03James Almer 07release/3.0:492bbe58902d: avcodec/avpacket: fix leak on realloc in av_packet_add_side_data() [00:28:09 CET] <cone-137> ffmpeg 03James Almer 07release/3.1:c3f97bf54496: avcodec/avpacket: fix leak on realloc in av_packet_add_side_data() [00:28:11 CET] <cone-137> ffmpeg 03James Almer 07release/3.2:3bd7ad58a7e1: avcodec/avpacket: fix leak on realloc in av_packet_add_side_data() [01:53:27 CET] <philipl> Weird. I've moved the setting of pix_fmt to the callback and everywhere I check the format, it's the right value at the right time, yet my 10bit is mangled. [01:54:51 CET] <philipl> hah. got it. [02:12:16 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/faa7b2256d41bfb1a3ef03403d8fef9b85… [03:52:24 CET] <cone-230> ffmpeg 03James Almer 07release/3.2:ee5677737942: avcodec/rawdec: check for side data before checking its size [13:00:46 CET] <cone-946> ffmpeg 03Michael Niedermayer 07master:ac206bb1756d: swscale/options: Use AV_OPT_TYPE_PIXEL_FMT [18:00:00 CET] <kierank> dammit please please please don't put in a psd decoder [18:04:20 CET] <RiCON> kierank: might want to say so in the ML then [18:04:28 CET] <RiCON> only atomnuker said anything against [18:04:31 CET] <kierank> atomnuker has already said what I wanted to say [18:04:45 CET] <kierank> objections are not a quantity over quality thing [18:05:58 CET] <JEEB> is it due to the fact that it only supports the "preview" picture? [18:06:25 CET] <kierank> well it's a nightmarishly complex format of which ffmpeg will only support a tiny subset [18:06:36 CET] <JEEB> yes [18:06:54 CET] <kierank> Not to mention that close to 90% [18:06:54 CET] <kierank> of the features it has are unsupported by the framework, be it vectors, the [18:06:54 CET] <kierank> colorspaces, layers, etc [18:10:12 CET] <JEEB> yup [18:11:42 CET] <durandal_1707> what about fits decoder? [18:12:26 CET] <durandal_1707> what about eia-608 Iirc scanner? [18:12:47 CET] <wm4> PSD is a format of which AFAIK 99% can't be supported [18:12:51 CET] <durandal_1707> as filter of course [18:12:54 CET] <wm4> so it's very dumb to add "support [18:12:55 CET] <wm4> " [18:13:01 CET] <wm4> what's next, .doc? [18:13:07 CET] <wm4> .html? [18:13:13 CET] <durandal_1707> gimp format [18:13:23 CET] <wm4> well for .html you could at least add a webkit wrapper [18:13:32 CET] <wm4> which would actually be more sane than this psd "support" [18:13:47 CET] <wm4> and that's crazy [18:13:55 CET] <durandal_1707> exr is already supported somehow [18:14:30 CET] <durandal_1707> and raw text via awesome demuxer [18:40:30 CET] <tab1293> are there any resources on how to implement an ffmpeg protocol? [18:41:29 CET] <durandal_1707> tab1293: explain? [18:42:00 CET] <tab1293> like the http protocol for instance, https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/http.c [18:42:16 CET] <tab1293> I would like to try to implement a protocol for websockets [18:42:34 CET] <tab1293> is there any high level documenation on how to do this? [18:42:46 CET] <BtbN> no, look at the other protocols. [18:43:37 CET] <tab1293> does http inherit the url protocol? [18:44:01 CET] <JEEB> it utilizes a URLContext [18:44:37 CET] <JEEB> it then checks if the url starts with http:// (and a few other things) [18:45:14 CET] <JEEB> you can look at the functions the protocol registers for the callbacks [18:45:21 CET] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/http.c#L1663 [18:45:30 CET] <JEEB> and yes, http is a URLProtocol [18:45:45 CET] <JEEB> oh wait, that's the "use proxy" one [18:45:57 CET] <tab1293> yeah I saw the regular one about it [18:46:00 CET] <JEEB> this one is the base http https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/http.c#L1527 [18:46:22 CET] <tab1293> okay thanks, im going to try to go through a couple of these protocols [18:46:33 CET] <tab1293> see I can find the general pattern [18:47:50 CET] <JEEB> the process is somewhat similar to demuxers, although not exactly https://wiki.libav.org/Internals/DemuxerHowTo [18:48:13 CET] <JEEB> you define your context, and then add your thing into a few files [18:48:32 CET] <JEEB> the functions you define for the callbacks then get utilized by the framework [18:51:36 CET] <tab1293> cool, yeah I see whats happening [18:51:56 CET] <tab1293> where is urlcontext defined? I dont see it in libavformat/url.c [18:52:08 CET] <JEEB> url.h gets included so I guess it's there [18:52:24 CET] <JEEB> git grep is one of your best friends [18:52:24 CET] <tab1293> ah [20:32:23 CET] <cone-946> ffmpeg 03Andreas Cadhalpun 07master:1c7da19a4b45: ffmdec: validate codec parameters [22:26:31 CET] <cone-946> ffmpeg 03Carl Eugen Hoyos 07master:322568c079d6: lavc/ffv1: Support YUV4xxP12 and GRAY12. [22:40:00 CET] <cone-946> ffmpeg 03Michael Niedermayer 07master:748ce9d70286: avutil/opt: Fix setting int64 to its maximum [23:32:16 CET] <cone-946> ffmpeg 03James Almer 07master:ee888cfbe777: avformat/matroskaenc: postpone writing the Tracks master [23:32:17 CET] <cone-946> ffmpeg 03James Almer 07master:8c1342e631d6: avformat/matroskaenc: write updated STREAMINFO metadata for FLAC streams if available [23:59:09 CET] <cone-946> ffmpeg 03Marton Balint 07master:58af48f1c3cc: ffplay: add support for negative RGBA linesize [23:59:10 CET] <cone-946> ffmpeg 03Marton Balint 07master:28d87899e33f: ffplay: allow fallback to software renderer [00:00:00 CET] --- Mon Nov 21 2016

1 0

ffmpeg.log.20161120
by burek 21 Nov '16

21 Nov '16

[01:59:32 CET] <fling> What to use as a replacement for ffserver? [01:59:53 CET] <fling> I need to capture what is sent to the server from a splitcam app [02:01:07 CET] <tdr> fling, ffserver can be built if you built your ffmpeg from source too [02:01:27 CET] <tdr> ffserver version 2.8.8 Copyright (c) 2000-2016 the FFmpeg developers [02:01:27 CET] <tdr> built with gcc 4.9.3 (Gentoo 4.9.3 p1.5, pie-0.6.4) [02:02:24 CET] <fling> tdr: do I need ffserver for the task? Not sure how to capture the stream. [02:04:40 CET] <tdr> ffserver your app for your cams already streams .. or whats its output options? [02:07:50 CET] <fling> umm? :D [02:07:55 CET] <tdr> if it can output to any number or normal framebworks ffserver could catch it, but so could alot of other things [02:09:32 CET] <tdr> ffserver is primarily for streaming tho, so if you were piping through it something else would likely be "playing" the stream to dump it to disk, so at that point i'd just use ffmpeg attached to whatever framework your app outputs to, use ffmpeg directly to dump to disk etc [02:23:12 CET] <fling> tdr: it cound output to several streaming services, right. The task is to capture on the server, not on the client. [02:24:38 CET] <fling> tdr: so I need a software to run on the server. [02:43:29 CET] <fling> tdr: it is like streaming but vice versa. The server app, not the client one. [02:43:40 CET] <fling> So don't I need ffserver, right? [05:04:13 CET] <tomed> why does so many dvd-videos has black bar on all 4 sides [05:42:28 CET] <tyng> what would be the most complete libpng reference encoder? ffmpeg, imagemagick, gimp.. or something else? [05:43:21 CET] <tyng> libpng provides a lot of references http://libpng.org/pub/png/pngaped.html [05:51:33 CET] <c_14> ffmpeg doesn't use libpng [05:51:35 CET] <c_14> so [05:51:37 CET] <c_14> eh [05:51:55 CET] <tyng> libavcodec uses its own implementation? [05:51:58 CET] <c_14> yes [05:52:09 CET] <tyng> why? is it better? [05:52:15 CET] <c_14> Because it can [05:52:18 CET] <c_14> less dependencies [05:52:37 CET] <c_14> better integration [05:52:40 CET] <tyng> is it based on the iso reference? [05:58:22 CET] <tyng> gimp isn't based on libpng either [05:59:15 CET] <tyng> i am rather asking about png encoders based on the open standard [06:00:30 CET] <c_14> I would presume the encoder/decoder are based on some version of the png specification though I don't know which it is [06:03:59 CET] <c_14> Why are you looking for "the most complete png reference encoder"? [06:04:32 CET] <c_14> You're probably better off figuring out what exactly you need your png encoder to accomplish and then testing a couple of the more common ones to see if they do what you want. [06:16:09 CET] <tyng> i want to encode a lot of data for long term storage so i am looking into the available codecs [07:22:00 CET] <fling> (security-camera)-->--[ffmpeg-on-a-streamer-box]-->--[?-on-a-storage-box] [07:22:13 CET] <fling> 1. which app to run on the storage box? ^ [07:22:28 CET] <fling> 2. How to only save parts of videos containing movement? [11:10:55 CET] <fling> How to put the current date to a file metadata? [11:11:03 CET] <fling> Without using `date` (on windows) [12:03:05 CET] <wouter> DHE: thanks (for your reply yesterday :) [13:46:43 CET] <fling> seeking mostly not working if ffmpeg was wrongly killed while writing to the file. How to fix this? [13:47:07 CET] <somaReverse> hello [13:47:16 CET] <somaReverse> what's wrong with this option " -r 16 -c:v libx264 -preset ultrafast -crf 30 -c:a libvorbis " [13:47:18 CET] <JEEB> fling: remux :P [13:47:41 CET] <fling> JEEB: sure but is not there a magical option for encoding in something like a stream mode? [13:48:11 CET] <fling> somaReverse: what is the error message? [13:48:11 CET] <JEEB> that doesn't help for seeking [13:48:21 CET] <JEEB> I mean, you write an index after the thing's done [13:48:25 CET] <fling> JEEB: what does help then? [13:48:27 CET] <fling> ahhh ok [13:48:38 CET] <JEEB> if you kill shit in the middle then no index for you [13:49:08 CET] <fling> it is running on windows and windows is rebooting killing everything the wrong way [13:49:13 CET] <JEEB> the best you can get is isobmff with movie fragments I guess? which means that every GOP will be in its own little indexed thing and just the last one goes the way of the dodo :P [13:49:42 CET] <fling> hmm hmmm [13:49:47 CET] <kerio> mpegts? [13:49:57 CET] <JEEB> mpeg-ts is only exact in seeking if you index it [13:50:04 CET] <JEEB> if you are OK with "close enough" [13:50:09 CET] <JEEB> then mpegts or nut would be OK [13:50:16 CET] <JEEB> or matroska I guess :V [13:50:23 CET] <fling> I'm writing to nut [13:50:33 CET] <JEEB> and that's why you can play the file [13:50:42 CET] <fling> Right. [13:50:44 CET] <JEEB> seeking index isn't getting written so you're getting funkyness there [13:51:00 CET] <fling> Right, rewind works but not ff [13:51:19 CET] <JEEB> anyways, you can generally fix such stuff with a remux [13:51:23 CET] <JEEB> -c copy and all that jazz [13:51:27 CET] <fling> Sure! I know [13:51:40 CET] <fling> But I want to make it playable out of the box& [13:51:51 CET] <somaReverse> fling: I cannot get the error message [13:51:52 CET] <fling> How to isobmff? [13:51:59 CET] <fling> somaReverse: what is the issue then? [13:52:00 CET] <somaReverse> it's inside a gui program [13:52:06 CET] <somaReverse> it's not working [13:52:14 CET] <fling> somaReverse: run it on the outsize [13:52:19 CET] <fling> s/z/d/ [13:52:24 CET] <somaReverse> the script looks like this [13:52:31 CET] <somaReverse> if [[ -z $ffaudio ]]; then $encoder -f x11grab ${border} -s "$W"x"$H" -i $ffmpeg_display+$X,$Y $rect_encopts "${vid_path}/${filename}" & [13:53:32 CET] <fling> JEEB: I cant find what it is :P [13:54:01 CET] <JEEB> fling: -f mp4 -movflags empty_moov+frag_keyframe [13:54:10 CET] <JEEB> ISOBMFF is the fancy name for what is colloquially called mp4 [13:54:16 CET] <JEEB> ISO Base Media File Format [13:54:29 CET] <fling> So it is not useable for nut right? [13:55:00 CET] <somaReverse> ah I get the output https://ptpb.pw/2kX3 [13:55:04 CET] <JEEB> well nut works better out of the box so it doesn't need that :P [13:55:14 CET] <JEEB> but as you can see the seeking perf lacking an index sucks [13:55:57 CET] <fling> somaReverse: and now we need the command :> [13:56:17 CET] <fling> JEEB: don't I need to try mkv right? [13:56:25 CET] <fling> I will probably leave this as is for a while& [13:56:36 CET] <fling> I still need to figure out how to motion detect [13:57:11 CET] <somaReverse> hmm [13:57:19 CET] <somaReverse> how can I get the command [13:57:29 CET] <fling> somaReverse: you have specifiend -i twice or you have a weird -map [13:58:18 CET] <fling> somaReverse: try putting "set -x" before the funny part [13:58:30 CET] <fling> if it is bash or something [13:58:37 CET] <somaReverse> ok [13:58:39 CET] <somaReverse> the command ffmpeg -f x11grab -show_region 1 -s 523x303 -i :0+266,232 -r 16 -c:v libx264 -preset ultrafast -crf 30 -c:a libvorbis /home/amos/Videos/Screencasts/vid-2016-11-20-205818.gif [13:59:06 CET] <fling> JEEB: why is not there opus in nut btw? :P [13:59:46 CET] <JEEB> nobody cared enough? do note that most people using nut in production only utilize it to pipe raw video/audio with timing information from one thing to another [14:00:01 CET] <JEEB> I mean, as you can see it works for other stuff as well but yunno [14:00:20 CET] <JEEB> you can add a thing about it if you want opus in nut for your use case :D [14:00:32 CET] <fling> somaReverse: `ffmpeg -f x11grab -show_region 1 -s 523x303 -i :0+266,232 -r 16 /home/amos/Videos/Screencasts/vid-2016-11-20-205818.gif` [14:00:43 CET] <fling> somaReverse: if you are writing to this gif [14:01:11 CET] <somaReverse> so I need to remove " -c:v libx264 -preset ultrafast -crf 30 -c:a " ? [14:01:18 CET] <somaReverse> how can I make it fast then? [14:01:26 CET] <fling> somaReverse: what are you doing? [14:01:33 CET] <somaReverse> screencast [14:01:44 CET] <fling> somaReverse: do you need gif? [14:01:47 CET] <somaReverse> yes [14:01:56 CET] <somaReverse> damn ios don't support webm [14:02:10 CET] <fling> somaReverse: then I provided the proper command. [14:02:16 CET] <somaReverse> thanks [14:02:49 CET] <fling> yw [14:03:58 CET] <fling> somaReverse: also try putting -framerate 16 before -i instead of using -r 16 after -i [14:04:07 CET] <fling> somaReverse: it could speedup things [14:04:43 CET] <fling> and maybe the same for -video_size [14:05:33 CET] <fling> JEEB: "add a thing about it" ? Like add it to the muxer? :P [14:06:12 CET] <JEEB> or a thing on the issue tracker so that someone else might add it [14:08:04 CET] <fling> Which codec should I use for a slow fps screencast? [14:08:09 CET] <somaReverse> fling: hmm [14:08:14 CET] <fling> Like 1fps [14:08:16 CET] <somaReverse> this gif size is so big [14:08:24 CET] <somaReverse> how can I make it smaller [14:08:29 CET] <fling> somaReverse: try using less fps [14:08:48 CET] <somaReverse> -r 8? [14:08:51 CET] <jj15> Ive released the Facebook Live Reactions script. Uses ffmpeg and PHP. Includes live shoutouts too. https://github.com/JamesTheHacker/Facebook-Live-Reactions [14:09:51 CET] <fling> somaReverse: ffmpeg -f x11grab -show_region 1 -s 523x303 -framerate 1 -i :0+266,232 /tmp/test.gif [14:13:33 CET] <somaReverse> fling: ok, gif is so not a choice now. [14:18:22 CET] <fling> somaReverse: gif > ffv1 > mjpeg > x264 [14:18:57 CET] <fling> somaReverse: x264 looks good by the default (if you dont specify preset and crf) but it is 10 times smaller than the default gif [14:21:01 CET] <fling> somaReverse: I'm now capturing with this -> ffmpeg -f x11grab -r 1/6 -s 1280x800 -i :0 -c ffv1 /tmp/screen.ffv1.mkv [14:21:40 CET] <kerio> fling: why not ffvhuff [14:21:43 CET] <kerio> it's not much bigger [14:21:46 CET] <kerio> but it's MUCH faster [14:22:16 CET] <somaReverse> fling: is mkv supported by all the browsers? [14:23:53 CET] <fling> kerio: somaReverse: http://dpaste.com/2NZNE6F [14:24:10 CET] <fling> somaReverse: use webm for browsers [14:24:57 CET] <kerio> fling: that's like only a factor of two [14:25:23 CET] <kerio> safari doesn't support webm [14:25:40 CET] Action: fling is using wget. [14:25:58 CET] <fling> lunchtime! [14:26:03 CET] <somaReverse> fling: ok [14:26:10 CET] <fling> somaReverse: good luck with your encoding, read the docs. [14:26:15 CET] <somaReverse> could you give a webm capture options? [14:27:34 CET] <schlurke1> hello together,i have got a question here http://pastebin.com/QaaFezjN maybe someone knows what I make wrong? [14:27:35 CET] <fling> somaReverse: http://wiki.webmproject.org/ffmpeg [14:27:56 CET] <fling> somaReverse: this one has examples https://trac.ffmpeg.org/wiki/Encode/VP8 [14:28:11 CET] <somaReverse> thanks [14:28:38 CET] <fling> kerio: x264 produces really fancy image I will use it for the screencast [14:28:50 CET] <fling> gif and mjpeg look really bead [14:33:43 CET] <kerio> fling: i assumed the lossless capture was to then be processed [14:38:24 CET] <fling> Can ffmpeg also capture subtitles from what I type? [14:38:49 CET] <fling> kerio: turned out x264 looks good for me and it is fast. [15:07:57 CET] <fling> JEEB: I have a video with an audio perfectly in sync but audio gets out of sync when I add a second video stream with the lower fps. How to fix this? [15:08:05 CET] <fling> They are all live sources. [15:20:50 CET] <fling> JEEB: fixed specifying fps for the first video codec [15:20:52 CET] <fling> wtf :P [15:24:27 CET] <fling> Does stream order mean? Should not I put all the video streams first then all the audio streams? [15:30:54 CET] <fling> JEEB: fps applied also to the second stream because I have only one -c:v this is why it got fixed [15:32:42 CET] <fling> ff does not work when playing the second stream :< [15:56:32 CET] <Atlas69> hi [15:58:30 CET] <Atlas69> Is their anyone able to help me? [15:59:15 CET] <Atlas69> oh [15:59:17 CET] <Atlas69> ok [16:19:40 CET] <durandal_1707> Atlas69: ask [16:19:53 CET] <Atlas69> Right... [16:20:04 CET] Action: Atlas69 clears their throat [16:20:40 CET] <Atlas69> So I'm trying to compile ffmpeg with the libopenmpt demuxer. [16:21:21 CET] <Atlas69> I don't have libopenmpt on my system [16:21:37 CET] <Atlas69> What do I do? [16:22:06 CET] <durandal_1707> install libopenmpt [16:22:20 CET] <Atlas69> ok, then? [16:24:28 CET] <durandal_1707> configure ffmpeg with libopenmpt support [16:24:39 CET] <Atlas69> how? [16:24:52 CET] <Atlas69> I know I need o [16:25:34 CET] <Atlas69> ...to do those two steps, but I don't know how I configure it. [16:27:48 CET] <durandal_1707> ./configure --help from ffmpeg directory [16:47:57 CET] <porton> How to check programmatically whether a given .mp4 file is mpeg or h.264? [16:49:00 CET] <JEEB> mpeg is a group in ISO that has published a series of specifications :P [16:49:29 CET] <bencoh> I suppose he meant "using ffmpeg/libav* api:" :) [16:49:49 CET] <JEEB> he probably meant mpeg-1 or mpeg-2 or mpeg-4 part 2 I guess? [16:49:56 CET] <JEEB> since H.264 aka AVC is MPEG-4 Part 10 [16:49:57 CET] <bencoh> most probably yeah :) [16:50:02 CET] <porton> JEEB: I was ordered to convert all mpeg -> h.264 (but not to touch files which are already h.264) [16:50:23 CET] <JEEB> porton: on a higher level the simplest way to check is probably to parse ffprobe's json output [16:50:30 CET] <JEEB> that way you don't have to go down and dirty [16:50:36 CET] <JEEB> unless you want, of course [16:51:30 CET] <furq> porton: ffprobe -v error -i foo.mp4 -select_streams v:0 -show_entries stream=codec_name:stream_tags=0:stream_disposition=0 -of default=nokey=1:noprint_wrappers=1 [16:52:47 CET] <porton> furq: tahnks [17:00:00 CET] <markvandenborre> porton: mediaprobe might also be useful [17:00:44 CET] <porton> markvandenborre: `apt-file search mediaprobe` outputs nothing on Debian [17:00:51 CET] <furq> mediainfo [17:01:08 CET] <furq> it's a good tool to have but it's not going to tell you the codec name any better than ffprobe can [17:01:33 CET] <markvandenborre> furq: mediainfo indeed [17:02:25 CET] <porton> markvandenborre: does it make any sense when the long command line by furq already works? [17:11:00 CET] <walterav1984> question:ffmpeg/ffplay using firewire/1394 (h)dv input using "iec61883" with multiple camcorders doesn't work as expected single device work [17:12:39 CET] <walterav1984> iec61883 has an option "dvguid" to select a specific firewire device when multiple active are connected, this option is not working for me on ubuntu 16.04 amd64 with repo version and compilled ffmpeg of today [17:17:55 CET] <walterav1984> To test multiple dv/hdv device capture on ubuntu 16.04 linux with "dvgrab -noavc -guid 0x1234567etc -f raw cameraA" and "dvgrab -noavc -guid 0x1234567etc -f raw cameraB" works fine at the same time on the same FW interface [17:18:47 CET] <JEEB> better to post on the trac [17:18:50 CET] <JEEB> as an issue [17:19:18 CET] <walterav1984> The previous written example using dvgrab has a typo in it since the guid has to be different for a different camera [17:19:40 CET] <walterav1984> <JEEB> don't know if its a issue or me specifying the wrong syntax [17:20:11 CET] <JEEB> well you will get told but in this case I'd be surprised if someone utilizing firewire would be here at this point of time [17:20:27 CET] <JEEB> just note that you're not sure if you're just DoingItWrong or if it's a boog [17:22:20 CET] <walterav1984> <JEEB> true about people having old FW devices will probably not be here in the active IRC channel, I'll try filling a bug with the notion that it might be wrong syntax usage [17:25:50 CET] <JEEB> sounds good [17:31:02 CET] <hmir> Hi guys. I have a ffmpeg x.265 CRF question. In the ffmpeg x.265 documentation, it says X.265 CRF 28 is roughly equally X.264 CRF 23. So, would a X.265 CRF 30 be roughly equal to X.264 CRF 25? [17:31:15 CET] <JEEB> no [17:31:22 CET] <JEEB> their ranges are completely different [17:31:35 CET] <JEEB> and instead of them being similar it should say that those are the default values (I think) [17:31:48 CET] <JEEB> libx265 defaults to crf 28, and libx264 defaults to crf 23 [17:31:57 CET] <JEEB> and the encoders are completely different inside [17:32:00 CET] <hmir> According to https://trac.ffmpeg.org/wiki/Encode/H.265 - "The CRF of 28 should visually correspond to libx264 video at CRF 23" [17:32:03 CET] <JEEB> so the results *will* be different [17:32:33 CET] <hmir> So, you're saying that webpage/information is wrong? [17:34:12 CET] <JEEB> it's misleading if you expect anything from it [17:34:20 CET] <JEEB> like you were just trying :P [17:35:31 CET] <cerion> hi; how can I amek ffmpeg ignore chapter errors ? [17:35:42 CET] <hmir> Alright, thanks. [17:36:05 CET] <furq> cerion: -map_chapters -1 [17:36:14 CET] <cerion> furq: thanks [17:36:31 CET] <furq> that'll disable chapters entirely, you'll need to edit the source file with an appropriate tool if you want to fix them [17:36:37 CET] <walterav1984> Filling a track ticket/bug report thank you <JEEB> for suggestions. [17:44:48 CET] <Jimmyon> Hello guys and girls! I am new to using ffmpeg command line, now i have ~60 video files (.mov) that i want to SHARPEN using the convolution filter. How would i go about that? Can someone guide me through it? [17:47:51 CET] <DHE> you'll have to run a loop using your shell. [17:48:36 CET] <durandal_1707> why to sharpen it? [17:49:38 CET] <Jimmyon> Does the why even matter? :D I have a video im working on and some of the footage is just slightly blurry. I want to make those clips a little more crisp [17:50:04 CET] <Jimmyon> and i dont even know what a shell is :D consider me to be about as new to the topic as can be [17:50:19 CET] <Jimmyon> i know how to call a command line in a folder, thats about it [18:05:53 CET] <SchrodingersScat> Jimmyon: so, linux? [18:06:58 CET] <Jimmyon> im on Windows 10 schrodingersScat [18:12:34 CET] <SchrodingersScat> with bash? [18:13:38 CET] <Jimmyon> i dont even know what that means :( [18:13:52 CET] <Jimmyon> i thought it might be relatively simple to write in a .bat? :S [18:17:17 CET] <tab1293> is it possible to output what byte ffmpeg would start processing input at if the -ss flag is passed? [18:18:46 CET] <BtbN> no. [18:19:12 CET] <BtbN> Also, it probably start processing at the very beginning [18:19:43 CET] <DHE> Jimmyon: the program providing your command-line is called your shell. that's why the newest version is called "powershell" [18:22:00 CET] <tab1293> Does ffmpeg support any kind of remote resource seeking BtbN [19:04:11 CET] <unkmar> I need the simpliest example of a functioning ffmpeg screen grab video to file. something like ffmpeg -f x11grab test.flv [19:05:04 CET] <unkmar> I'm so tired of rewriting the same script over and over because of tiny changes to ffmpeg and the differences with avconv. [19:06:46 CET] <c_14> ffmpeg -f x11grab -i :0 out.mkv [19:09:51 CET] <unkmar> both vlc and ffmpeg display 1 frame and then crash immediately on that example. [19:09:57 CET] <unkmar> I mean, mplayer. [19:10:08 CET] <c_14> When playing out.mkv? [19:10:15 CET] <unkmar> yes. [19:10:56 CET] <c_14> works for me... [19:10:57 CET] <unkmar> Full disclosure: I'm using the much older ffmpeg from the debian 8 repos. [19:10:59 CET] <c_14> What version of ffmpeg? [19:11:22 CET] <unkmar> 3.2-2 [19:11:41 CET] <c_14> That's not that old [19:11:50 CET] <unkmar> More percisely, ffmpeg version 3.2-2~bpo8+2 Copyright (c) 2000-2016 the FFmpeg developers [19:13:20 CET] <unkmar> Just for testing, I switched my test.flv to test.mkv. File extension made no differenct. I didn't expect it would. [19:13:40 CET] <c_14> Can you play this without crashing? https://dl.c-14.de/t/out.mkv [19:15:06 CET] <unkmar> No! mkv demux error: No tracks supported cannot find any cluster, damaged file ? [mp3 @ 0x7f23a0050a40] Header missing [19:15:47 CET] <unkmar> and mplayer says. No stream found to handle url https://dl.c-14.de/t/out.mkv [19:16:29 CET] <c_14> Download with wget/curl and try again? [19:16:57 CET] <c_14> But I'm going to guess that vlc/mplayer are linked against some old/broken version of libav* [19:17:00 CET] <c_14> Do you have ffplay installed? [19:17:12 CET] <c_14> (should be part of the ffmpeg package) [19:17:32 CET] <unkmar> ffplay plays it fine. [19:20:25 CET] <unkmar> Okay, at least I now have something to work *forward* from. [19:20:46 CET] <c_14> Check the output of ldd `which mplayer` [19:23:01 CET] <unkmar> broken version of libav. I'm sure they are. Since libav had to be removed in order to install ffmpeg according to debian. [19:24:22 CET] <unkmar> I don't know what the output from "ldd `which mplayer`" meains. [19:25:05 CET] <unkmar> I can tell you, it dumped a long list of what appears to be symlinks. [19:25:14 CET] <c_14> There should be a line libavformat.so >= /path/to/libavformat.so [19:25:20 CET] <c_14> Where is that path? [19:25:29 CET] <c_14> And then check with dpkg to which package it belongs [19:27:37 CET] <unkmar> I don't know how to check with dpkg. [19:27:48 CET] <unkmar> libavformat.so.56 => /usr/lib/x86_64-linux-gnu/libavformat.so.56 (0x00007f28f5dd8000) [19:34:08 CET] <devsnd> Hi ffmpeggers! Does anybody know if it is valid in MP3 for the sample rate to change from frame to frame? [19:35:27 CET] <SchrodingersScat> there's variable bitrate yes? [19:35:41 CET] <SchrodingersScat> is, is that the same? [19:35:43 CET] <furq> unkmar: dpkg -S /usr/lib/x86_64-linux-gnu/libavformat.so.56 [19:37:07 CET] <unkmar> furq: libavformat56:amd64: /usr/lib/x86_64-linux-gnu/libavformat.so.56 [19:37:22 CET] <furq> ffmpeg from jessie backports uses libavformat 57 [19:37:39 CET] <furq> backports are generally a bit wonky at sorting this sort of thing out [19:38:51 CET] <furq> mplayer's libavformat is apparently from libav 11.8, which isn't that old [19:39:19 CET] <unkmar> that would explain why I see both 56 and 57 installed. [19:39:48 CET] <devsnd> SchrodingersScat, bitrate may vary in a MP3, yes. But I would like to know if it is valid that the sample rate changes, e.g. from 22050 to 44100 hz [19:41:30 CET] Action: SchrodingersScat is in over his head [19:48:31 CET] <devsnd> Well, even worse, may mp3s change between layers from frame to frame? [19:49:20 CET] <devsnd> I've got this mp3 that plays on mplayer, but my own parser doesn't get it right :( [19:59:43 CET] <unkmar> OMG, this is just NEVER going to work. Why do I torture myself so? I'll never get something that SHOULD be so simple to Freaking work. [20:00:18 CET] <unkmar> And no! I haven't spent about an hour at it. It has been multiple days at no less than 3 hours each attempt to get this to work. [20:04:33 CET] <bencoh> furq: err ... mplayer uses ffmpeg afaict (?) [20:04:40 CET] <bencoh> (not libav) [20:05:12 CET] <furq> it uses libavcodec/libavformat etc [20:05:23 CET] <furq> on debian stable those are the ones from libav, on testing they're the ones from ffmpeg [20:05:41 CET] <bencoh> ah you didn't been the builtin ffmpeg tree [20:05:44 CET] <furq> stable backports has ffmpeg with the latest libs, but only packages from backports are linked against them [20:05:58 CET] <furq> which evidently doesn't include mpv, mplayer or vlc [20:07:04 CET] <furq> i would probably upgrade to testing, but all my debian boxes already run testing so that's easy for me to say [20:18:36 CET] <unkmar> I'm not even fighting the vlc mplayer issue. [20:19:33 CET] <unkmar> Its the rewrite of my script that originall used ffmpeg. That I had to rewrite to use avconv. That I'm having to rewrite to use ffmpeg, That is sending the first frame and then freezing and currently not supporting audio at all. [20:20:18 CET] <unkmar> I have to work out all the various bug details that are preventing it from working in ANY player. vlc, mplayer, and even ffplay. [20:24:41 CET] <furq> pastebin the ffmpeg command that the script calls (or failing that, the script) [20:46:29 CET] <Mockarutan> Hello ppl! Having some issued with AAC encoding in c++. I'm quite new at this stuff. Is this the place to ask? Most forums look really unactive. [20:53:51 CET] <DHE> yes. first suggestion, there's demonstrations in /doc/examples/*.c you might want to check first [20:56:04 CET] <Threads> anyway to add 100ms of blank audio to a mp3/aac/ac3 with ffmpeg ? [20:56:12 CET] <unkmar> http://paste.debian.net/897049/ [20:56:14 CET] <Threads> want to add it at the start [20:59:19 CET] <bsenftner> I am seeking advice on compiling ffmpeg. I am on Win10, and I can compile fine using the steps outlined herehttp://stackoverflow.com/questions/38634424/building-ffmpeg-for-visual-…, but the dlls end with .dll.a <- is that wrong? [20:59:47 CET] <BtbN> that's the implib. [21:00:49 CET] <bsenftner> Will the av*.dll.a libs work as .dlls? there are .libs created, which I assume are for linking. [21:02:43 CET] <BtbN> They are import libraries, not DLLs. [21:03:11 CET] <furq> if you built with --enable-shared you should have dlls as well [21:03:26 CET] <furq> i think the makefile puts them in bin/ [21:03:33 CET] <BtbN> if you have the implibs, you have the DLLs [21:04:47 CET] <bsenftner> okay. Thanks. I thought the .libs were the import libraries. I've been looking in the parallel directories, and tried a search with everything.exe. I did use the --enable-shared. I'll try again, for the nth time... [21:13:49 CET] <unkmar> So... Nothing input about the pastebin ? [21:13:58 CET] <unkmar> *No input about the pastebin ? [21:18:26 CET] <bsenftner> thanks for the help furq and BtbN. I found the dlls. Apparently, exerything.exe needs to be quit and relaunched to locate newly created files... [21:20:37 CET] <furq> that sure doesn't sound right [21:28:53 CET] <furq> unkmar: i can't see anything obvious but you probably want to remove -loglevel 0 [21:29:19 CET] <furq> i don't have a box with x11 i can test on [21:35:28 CET] <unkmar> Soooo..... You are on a windows machine? [21:38:26 CET] <unkmar> ffmpeg gives me: [flv @ 0x7f19f00008c0] video stream discovered after head already parsed [21:38:30 CET] <unkmar> [flv @ 0x7f19f00008c0] Could not find codec parameters for stream 0 (Video: h264, none): unspecified size [21:38:33 CET] <unkmar> Consider increasing the value for the 'analyzeduration' and 'probesize' options [21:38:55 CET] <unkmar> And no video feed at all. [21:39:21 CET] <unkmar> Sorry, I meant to say that is what ffplay tells me. [21:39:57 CET] <unkmar> And that otherwise, ffmpeg appears to be running along smoothly. Just nothing I have can play back the output. [21:40:15 CET] <furq> do you get any warnings/errors from ffmpeg if you remove -loglevel 0 [21:40:36 CET] <unkmar> even without removing it. I get: Warning: data is not aligned! This can lead to a speedloss [21:40:59 CET] <furq> that's a libswscale error iirc, i don't think that matters [21:41:10 CET] <furq> s/error/warning/ [21:41:14 CET] <unkmar> And a big dump of Version numbers, and configuration settings. [21:42:19 CET] <unkmar> So, No! I don't really see anything that looks like an error or warning that might explain my problems. [21:43:23 CET] <unkmar> Honestly, I can't tell if my stream is broken, my players are broken, or both. Or is it my settings? After all.. The strictest base version of the test does work with ffmpeg and ffplay. [21:45:50 CET] <Mockarutan> I have looked though most examples I can find. Sort of stuck. The biggest issue I have now is that I need to generate some synthetic audio and place it in a AVFrame with AV_SAMPLE_FMT_FLTP formating. And think i'm going in circles now and messing up my code by the minute. The different data types and conversons in c++ is giving me a headace as a spoiled c# programmer :P So here is where I'm [21:45:50 CET] <Mockarutan> at: http://pastebin.com/5Tvs19Am [21:49:37 CET] <Mockarutan> 4 years of c# coding really makes you rusty in c++ :( [22:16:59 CET] <MrMonkey31> do's and don'ts for making my videos pb smoother? right now I change the framerate on home movies from 30 to 25 with -r 25. hevc is the codec, crf is the mode [22:18:26 CET] <Mavrik> Hmm, that's a strange thing to do. [22:18:46 CET] <Mavrik> You'll lose some smoothness in any case, can't you avoid changing FPS? [22:20:57 CET] <Mavrik> Is it interlaced? [22:22:32 CET] <MrMonkey31> Mavrik: no, all my footage is new shiny and progressive. well, I thought I would save on encode size and also, if I were to splice in another source here and there, that kind of thing [22:22:50 CET] <Mavrik> Ahh, well you won't really save much on encode. [22:22:58 CET] <Mavrik> Intraframe compression and all that. [22:23:04 CET] <Mavrik> And you'll have severe juddering. [22:23:14 CET] <Mavrik> I strongly suggest against it if you want your videos smooth :) [22:23:45 CET] <Mavrik> There's a telecine filter in ffmpeg that can do pulldown, but it's meant for NTSC <=> PAL conversions [22:23:46 CET] <MrMonkey31> understood. I'm at a point in my understanding where it's really nothing's taken for granted but that's as I thought [22:23:51 CET] <Mavrik> And even that's not perfect :/ [22:24:08 CET] <Mavrik> (And assumes interlaced content) [22:24:59 CET] <MrMonkey31> my other q regarding encoded using x264 and x265 is, are the frames generally diplayed at as constant a rate as the playback platform can do? or will it fudge intentionally? [22:26:00 CET] <MrMonkey31> I have seen some content reporting a rate of say, 23.9760089, instead of 23.976000, and am wondering if that's all bubkiss or should I take note of it [22:26:38 CET] <MrMonkey31> tho I guess knoiwing that isn't hugely important for me [22:27:55 CET] <Mavrik> Umm, thing is, H.264 and H.265 aren't formats that demand (or have) constant framerate [22:28:17 CET] <Mavrik> Every frame just has a timestamp on it when it needs to be displayed and that's it. [22:28:36 CET] <Mavrik> That's why you sometimes get those non accurate calculations when tools try to calculate framerate [22:29:11 CET] <Mavrik> So the devices are going to display the frame when it needs to be displayed, not when set framerate demands it. [22:29:16 CET] <Mavrik> If you get what I mean O.o [22:29:30 CET] <MrMonkey31> oh I getcha bud. thanx! [22:30:11 CET] <Mavrik> Phones for example don't record in constant framerate :) [22:30:53 CET] <MrMonkey31> I so getcha I'm gonna rwd myself wit ha cookie. yeah I had gathered as much from the otherwise meaningless (to me) documentation, and also from having had real unexplained problems when splicing [22:32:11 CET] <MrMonkey31> I have worked around the latter with the parameter force_key_frames 0, iirc in addition to the trim video filter [22:33:32 CET] <MrMonkey31> ...and that's my ffmpeg story, folks! [22:34:24 CET] <furq> MrMonkey31: you can't accurately represent 23.976 in a double anyway, since the actual value is 23.976(023976)... [22:41:12 CET] <MrMonkey31> eh well, there goes the neighborhood! [22:41:34 CET] <kerio> furq: surely that should be 23.(976023) [22:43:12 CET] <furq> that would have been better wouldn't it [22:48:19 CET] <MrMonkey31> one concept I don't quite understand is timestamps in audio. it falls apart right away, for me. but the main concern is, when I do choose to change fr's, are there any extra steps which may be *required* to avoid desynching the audio? [22:51:57 CET] <bencoh> why would it fall apart? [22:52:51 CET] <bencoh> well, sure, if you consider that your stream is just one big chunk of audio meant to be played with no interruption, then .... it kinda defeats the purpose of timestamps [22:52:57 CET] <furq> if you're changing framerate with -r or -vf fps then no [22:53:23 CET] <furq> if you're changing it in some way that changes the duration of the video stream then sure [22:53:42 CET] <bencoh> but then what about live streams and/or packet loss or interruptions, or whatever [22:54:19 CET] <furq> if you go from 30fps to 25fps then some video frames may be a few ms out of sync with the audio but not enough that you'd notice [22:56:14 CET] <MrMonkey31> oh so no worries, in other words! well, only cause it seems like the playback end ought to... but I hadn't even considered streaming. I guess I presumed it would be no different than just playing back a file locally [22:58:26 CET] <MrMonkey31> I was in fact considering a change in the overall length, but one that might not be noticed till it compounds over the course of hours [22:58:48 CET] <MrMonkey31> as I've said: can't take anything for granted! [23:09:25 CET] <MrMonkey31> off I go! [23:26:18 CET] <ago> Hello all. [23:27:03 CET] <ago> while "ffmpeg -i $FILE -f null -" returns [NULL @ 0x61b00001ea80] Requested output format 'null' is not a suitable output format, what I need to enable to make it work? [23:27:55 CET] <sfan5> works fine here with "ffmpeg-git r82260.0e66dcd-1" [23:29:04 CET] <furq> ago: pastebin the full command line and output [23:29:36 CET] <furq> i'm guessing it's either an old version or a build with --disable-everything [23:30:51 CET] <ago> furq: the build has --disable-everything (for a reason). So I don't know what to enable. [23:31:10 CET] <furq> --enable-muxer=null [23:31:59 CET] <ago> that's what I'm trying now.. [23:35:14 CET] <ago> furq: it worked, thx [23:59:36 CET] <DHE> ago: --disable-everything is not recommended for new users. a lot of things will mysteriously break. for example you might not be able to resize frames now if you didn't correct for that. [00:00:00 CET] --- Mon Nov 21 2016

1 0