Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2017

1 participants
62 discussions

ffmpeg-devel.log.20171025
by burek 26 Oct '17

26 Oct '17

[00:00:08 CEST] <jkqxz> nevcairiel: <http://sprunge.us/CfMV> [00:05:54 CEST] <jya> just upgraded to ubuntu 17.10, that wasted space in the top bar is awful :( [00:09:23 CEST] <nevcairiel> jkqxz: seems fine [00:09:26 CEST] <cone-945> ffmpeg 03Jun Zhao 07master:f31478ba1472: lavc/vaapi_encode_h264: correct VUI max_dec_frame_buffering setting [00:09:27 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:5b2c71bb94d7: cbs_mpeg2: Fix type for marker_bit reading [00:09:28 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:79d666aa5751: cbs_mpeg2: Fix format specifier [00:09:29 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:59b00ffea3c9: cbs_h264: Fix format specifier [00:10:48 CEST] <jkqxz> I started the push before you said that, just :P [00:10:56 CEST] <jkqxz> How long do I have to wait for more feedback? [00:11:17 CEST] <cone-945> ffmpeg 03Alexandra Hájková 07master:0b9a237b2386: hevc: Add NEON 4x4 and 8x8 IDCT [00:11:18 CEST] <cone-945> ffmpeg 03James Almer 07master:c0683dce89ec: Merge commit '0b9a237b2386ff84a6f99716bd58fa27a1b767e7' [00:11:19 CEST] <nevcairiel> it seems to runquite regularly [00:12:39 CEST] <jkqxz> Right, yeah, it does. [00:15:21 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:1bd986ed4b0e: hwcontext: Move NONE to the be the first member of AVHWDeviceType [00:15:22 CEST] <cone-945> ffmpeg 03James Almer 07master:4e9dc52a9703: Merge commit '1bd986ed4b0e95ded368a8eeb5c044853c090f9b' [00:18:28 CEST] <cone-945> ffmpeg 03Diego Biurrun 07master:5a969f64b9cf: jack: Drop support for old (2012) JACK versions [00:18:30 CEST] <cone-945> ffmpeg 03James Almer 07master:6821b693ecce: Merge commit '5a969f64b9cf40bad923c73b66c3031b0018e848' [00:20:10 CEST] <cone-945> ffmpeg 03Felicia Lim 07master:c8c995bc1ddc: libopus: Add channel mapping 2 support in libopusdec [00:20:11 CEST] <cone-945> ffmpeg 03Michael Niedermayer 07master:617f0c65e1ba: ffserver: Fix off by 1 error in path [00:20:12 CEST] <cone-945> ffmpeg 03Michael Niedermayer 07master:431eccd61e15: tests/ffserver.regression.ref: update checksums to what ffserver currently produces [00:20:13 CEST] <cone-945> ffmpeg 03Zhong Li 07master:7e294a1f09a2: fate: add a test for mpeg2 issue of ticket #6677 [00:28:13 CEST] <cone-945> ffmpeg 03Martin Storsjö 07master:fbc6f190a618: arm: Always build the hevcdsp_init_arm.c file [00:28:14 CEST] <cone-945> ffmpeg 03Martin Storsjö 07master:e788ca05a796: hevcdec: Use LOCAL_ALIGNED_* for declaring local variables with alignment [00:28:15 CEST] <cone-945> ffmpeg 03Anton Khirnov 07master:6a9e331d79f8: dcadec: remove extra indirection [00:28:16 CEST] <cone-945> ffmpeg 03Diego Biurrun 07master:163cc67beb3e: takdec: Use ISO C printf conversion specifiers where appropriate [00:28:17 CEST] <cone-945> ffmpeg 03Martin Storsjö 07master:26d9b60373bf: hevc: Avoid using LOCAL_ALIGNED for 4 byte alignment [00:28:18 CEST] <cone-945> ffmpeg 03James Almer 07master:d289f3febda2: Merge commit '163cc67beb3ed28aeb500c9a09df47c8df613025' [00:28:19 CEST] <cone-945> ffmpeg 03James Almer 07master:953d55f4439b: Merge commit '26d9b60373bf45bc4f91ff6815f5fa36764d4d7b' [01:15:18 CEST] <atomnuker> is there any way to force ffprobe to output to stdout? [01:15:33 CEST] <BBB> 2>&1 ? [01:15:42 CEST] <atomnuker> doesn't work [01:15:52 CEST] <atomnuker> the { and } are printed on stdout [01:16:11 CEST] <JEEB> if you use one of the output modes that's not the default one those should output to stdout [01:16:12 CEST] <atomnuker> so 2>&1 makes the first output being the ffprobe body output [01:16:15 CEST] <JEEB> like -of json [01:16:24 CEST] <atomnuker> and then it ptints out { and } on new lines [01:16:33 CEST] <atomnuker> they don't [01:16:37 CEST] <JEEB> really? [01:16:42 CEST] <JEEB> I know the default outputs to stderr [01:16:55 CEST] <atomnuker> ffprobe -of json file > /dev/null [01:17:01 CEST] <atomnuker> prints out the body [01:17:05 CEST] <atomnuker> but not the { and } [01:17:09 CEST] <JEEB> huh [01:17:12 CEST] <JEEB> that's weird [01:17:22 CEST] <JEEB> and that really sounds like a boog [01:18:05 CEST] <JEEB> I mean, why would you output incorrect JSON over stdout and then put the curly braces into stderr :D [01:19:32 CEST] <atomnuker> who maintains ffprobe? michaelni [01:19:34 CEST] <atomnuker> ? [01:25:50 CEST] <atomnuker> how is it even outputting to stderr, no references to stderr anywhere in ffprobe.c [01:41:27 CEST] <michaelni> atomnuker, MAINTAINERS: ffprobe.c Stefano Sabatini [01:47:19 CEST] <N0rdell> I am looking for the best way to copy an decode context to an encode context. Right now I use 'avcodec_parameters_to_context': but its incompletely initialized; reference frames are set in the encode context... b frames... etc [01:47:44 CEST] <N0rdell> I would like to somehow use the sps/pps to initialize the encode context completly [01:47:58 CEST] <N0rdell> I wrote code by hand to do this prior to the 3.1 send/receive api [01:48:45 CEST] <N0rdell> 'reference frames are NOT set' I mean [02:00:09 CEST] <jamrial> atomnuker: av_log? [02:06:21 CEST] <BBB> N0rdell: use sps/pps from decoder to initialize encoder? that makes no sense? are you trying to do a streamcopy? [02:11:45 CEST] <N0rdell> @BBB not quite. I am changing the video and want it reencoded with the exact parameters [02:12:29 CEST] <BBB> I dont think thats as straightforward as youd like it to be ;) [02:13:05 CEST] <N0rdell> @BBB yeah... ;) Like I said prior to 3.1 I had hand written code to do this... broken moving to 3.3 [06:43:51 CEST] <wbs> jkqxz: about djgpp; int isn't 16 bit there, I think our code wouldn't even nearly work properly with a 16 bit int. the warnings you've seen probably come from the fact that uint32_t is typedeffed to unsigned long instead of unsigned int, and int != long even though they are the same size [10:15:18 CEST] <nevcairiel> jkqxz: it seems to have passed now, so that seems to have been it [11:00:20 CEST] <jya> who is the maintainer of the ffvp8 decoder? [11:00:24 CEST] <jya> BBB? [12:58:59 CEST] <J_Darnley> Gramner: I recall you talking about commits for Nasm regarding AVX-512 some time ago. Did they all get committed? Did they make it into a released version yet? [13:07:47 CEST] <wbs> J_Darnley: x264 requires nasm 2.13 these days, afaik everything needed should be there [13:08:15 CEST] <J_Darnley> okay, thanks [19:59:46 CEST] <ubitux> https://gopro.com/news/gopro-open-sources-the-cineform-codec [20:03:12 CEST] <jamrial> nice [20:03:37 CEST] <ubitux> just discovered that today, so don't ask me for details ENOIDEA [20:03:45 CEST] <ubitux> i can probably ask some ppl around though [20:03:52 CEST] <TD-Linux> also available under apache 2.0 which includes a patent grant [20:07:08 CEST] <Compn> LOL [20:07:18 CEST] <Compn> wait until someone re'd the damn thing [20:07:22 CEST] <Compn> open source it next week [20:08:31 CEST] <ubitux> don't we already have it RE'd in FFmpeg? [20:08:44 CEST] <JEEB> yea [20:08:45 CEST] <ubitux> (isn't what lavc/cfhd is?) [20:08:50 CEST] <nevcairiel> we do, but support is a bit limited, so maybe that can be much improved now [20:34:05 CEST] <kierank> ubitux: not fully [20:34:20 CEST] <kierank> a few samples not supported [20:35:27 CEST] <kierank> https://github.com/gopro/cineform-sdk/blob/master/Codec/temporal.c [20:35:28 CEST] <kierank> blimey [20:37:22 CEST] <nevcairiel> \o/ intrinsics [20:37:45 CEST] <nevcairiel> using cpu dispatch macros from gcc, never seen those in use [20:45:14 CEST] <kylophone> Anyone already started on getting this into libavcodec?: http://cineform.blogspot.com/2017/10/cineform-goes-open-source.html [20:45:35 CEST] <kylophone> I'm going to take a crack at it unless someone else has already started [20:46:06 CEST] <ubitux> we were just discussing it [20:46:10 CEST] <kierank> Well we already have most of it [20:46:23 CEST] <kierank> Apart from the 3d transform and the film scan stuff [20:46:46 CEST] <kierank> I can send you the samples which don't play if you want [20:48:41 CEST] <kylophone> Yeah, please do: k(a)ylo.ph [20:49:48 CEST] <kierank> They are not emailable iirc [20:50:14 CEST] <kylophone> K, let me know [20:50:26 CEST] <kylophone> I won't have time to look at it until later tonight anyway [20:53:18 CEST] <kierank> I am in the French countryside with near-zero connectivity [21:21:55 CEST] <Compn> does anyone think they opensourced the whole thing that decodes the old samples ? [21:21:59 CEST] <Compn> or just the newer spec stuff ? [21:53:25 CEST] <cone-215> ffmpeg 03Dale Curtis 07master:50e30d9bb71e: Don't use _tzcnt instrinics with clang for windows w/o BMI. [21:53:26 CEST] <cone-215> ffmpeg 03Michael Niedermayer 07master:e6debcaaed22: tools/target_dec_fuzzer: Fix build after FF_INPUT_BUFFER_PADDING_SIZE was removed [21:53:27 CEST] <cone-215> ffmpeg 03Michael Niedermayer 07master:c23209f63d51: tools/target_dec_fuzzer: Fix build after AV_CODEC_CAP_HWACCEL_VDPAU was removed [21:53:28 CEST] <cone-215> ffmpeg 03Kaustubh Raste 07master:2aab7c2dfaca: avcodec/mips: Improve avc put mc 11, 31, 13 and 33 msa functions [21:53:29 CEST] <cone-215> ffmpeg 03Kaustubh Raste 07master:ce0a52e9e929: avcodec/mips: Improve avc chroma copy and avg vert mc msa functions [21:53:30 CEST] <cone-215> ffmpeg 03Kaustubh Raste 07master:736a48901fa0: avcodec/mips: Improve hevc bi weighted hv mc msa functions [21:53:31 CEST] <cone-215> ffmpeg 03Mateusz 07master:50ce2960263d: swscale: use dithering in DITHER_COPY only if not set -sws_dither none [22:02:06 CEST] <durandal_1707> Compn: they opensourced because of your mail you sent to them [22:16:22 CEST] <TD-Linux> Compn, you know you could find out in seconds [22:22:07 CEST] <doublya> Is vaapi_mjpeg decode being added to FFmpeg anytime soon? [22:22:47 CEST] <JEEB> I don't think anyone really cares about it, so unlikely to happen by itself [22:23:08 CEST] <JEEB> mostly because pretty much anything with VAAPI can decode JPEG very quickly [22:23:16 CEST] <JEEB> VAAPI being limited to x86 [22:23:57 CEST] <JEEB> most likely a patch would not be declined, of course. but just saying that it's not seemingly a priority for anyone around [22:25:10 CEST] <doublya> Thanks [23:11:22 CEST] <Compn> To Decode [23:11:22 CEST] <Compn> Reverse all the steps. [23:11:23 CEST] <Compn> lol [23:12:02 CEST] <durandal_1707> Compn: what ? where ? [23:15:01 CEST] <Compn> There are also older bitstream formats supported by the SDK, even a 3D wavelet (volumetric, not steroscopic) from 2003 which compressed two frames into one crazy wavelet. There are old tools for handling interlaced that are quite different than progressive image encoding. [23:15:28 CEST] <Compn> durandal_1707 : https://gopro.github.io/cineform-sdk/ [23:16:57 CEST] <durandal_1707> doesnt it provide full source ? [23:17:13 CEST] <Compn> that was my question [23:17:19 CEST] <Compn> newer cineform or just cfhd only [23:18:11 CEST] <Compn> i mean older cineform or cfhd only [23:19:49 CEST] <Compn> but from the description it looks like all\ [23:22:04 CEST] <durandal_1707> Compn: learn to code, its never late [23:22:28 CEST] <Compn> i bought some books [23:23:21 CEST] <Compn> its kind of hard looking at the code for this as well, since it reuses the same fourcc... [23:29:25 CEST] <kierank> ubitux: dunno how realistic it is but, if you could publicly or privately get samples, would be useful [23:29:49 CEST] <ubitux> what kind of samples are you looking for? [23:30:42 CEST] <Compn> durandal_1707 : but i can look at case 3 and case 4: and case 5: or whatever and see the different code paths. even if i dont know how to code i can read it [23:32:48 CEST] <ubitux> don't try to read too much, write [23:33:14 CEST] <Compn> bonus question [23:33:28 CEST] <ubitux> you can read maths all your life and never be able to do shit; unless you practice, you won't learn how to read [23:33:28 CEST] <Compn> is the gopro code faster than ours, on the parts we reuse with other codecs i mean ? [23:35:50 CEST] <Compn> how do the asm compare : ) [23:36:17 CEST] <kierank> ubitux: mainly ones which use the 3d transform [23:36:43 CEST] <kierank> I think I only have one of those [23:37:16 CEST] <ubitux> so maybe with the 360 files? [23:37:41 CEST] <ubitux> 360° [23:37:57 CEST] <ubitux> or that's unrelated? [23:38:04 CEST] <Compn> unrelated iirc [23:39:56 CEST] <ubitux> kierank: the repository seems to include an encoder [23:40:15 CEST] <ubitux> can't you use it to generate samples with various settings? [23:40:51 CEST] <kierank> it's not clear to me whether you can generate 3d wavelet files with that encoder [23:40:55 CEST] <kierank> but i guess i can ask the author [23:41:09 CEST] <kierank> IRL he told me it was a hack at the time so the files could work on slow HDDs [23:42:42 CEST] <atomnuker> tarkin did it first [00:00:00 CEST] --- Thu Oct 26 2017

1 0

ffmpeg.log.20171025
by burek 26 Oct '17

26 Oct '17

[00:32:21 CEST] <lightbulb6> hello, is there a filter in ffmpeg that would inverse the 'tile' filter? [00:32:36 CEST] <lightbulb6> basically I've got a big photo and want to split it into smaller ones [00:32:58 CEST] <Johnjay> lightbulb6: don't know. i would have guessed that's what a filter named tile does [00:33:21 CEST] <lightbulb6> Johnjay: the 'tile' filter takes smaller images and arranges them to create a big one [00:33:35 CEST] <Johnjay> i see [00:33:36 CEST] <lightbulb6> so it's the opposite thing [00:33:42 CEST] <JEEB> source->split (creates X copies of the source)->crop each accordingly->use those cropped ones as encoder input [00:33:53 CEST] <JEEB> some manual math needed but I think this does it :P [00:34:02 CEST] <lightbulb6> okay, gonna try it [00:34:03 CEST] <lightbulb6> thanks [00:34:13 CEST] <Johnjay> JEEB: i've noticed there are lots of tasks needing manual math [00:34:20 CEST] <Johnjay> and you just want to say why can't a filter do this instead lol [02:50:59 CEST] <Compy_> Hey guys and girls. I'm working on a raspberry pi 3, and I'm wondering, does ffplay specifically have playback support using OMX? I'd rather use it compared to omxplayer. [02:51:43 CEST] <Compy_> I _did_ compile ffmpeg enabling omx and omx-rpi. Not sure if it was only for the encoding side though [03:25:02 CEST] <Johnjay> Compy_: well you got farther than i could. Because I couldn't even get ffmpeg to compile. [03:29:30 CEST] <Compy_> oh? [03:54:45 CEST] <Johnjay> Compy_: pm me how you got it work if you had to do anything special [03:55:30 CEST] <Compy_> I just downloaded the ffmpeg master branch from git, did a ./configure --enable-shared --enable-omx --enable-omx-rpi, make, make install [03:55:39 CEST] <Compy_> Not sure what issue you got when compiling, and at what step. [04:12:43 CEST] <Johnjay> well. [04:12:49 CEST] <Johnjay> i don't recall exactly, only that it said missing libraries [04:13:09 CEST] <Johnjay> and no matter what i did i couldn't get it to pass ./configure, it seemed to expect certain libraries that just weren't there [04:13:14 CEST] <Johnjay> and i had no clue how to proceed [05:09:42 CEST] <kode54> I have to wonder what happened to my iTunes Gapless MP3 patch? [05:10:11 CEST] <kode54> I submitted a FATE test for it, but haven't seen the actual patch it depends on appear [05:11:02 CEST] <kode54> simple patch, depended on ID3v2 reading, and then I had to add a patch for ID3v2.2 comment frames, since iTunes on Mac writes 2.2 tags [07:01:31 CEST] <cosven> #mopidy [08:18:36 CEST] <memeka> hi; how are decoded frames sent to the video drivers? profiling gstreamer and mpv+ffmpeg, I get very different results: on my arm board with no dmabuf-import gpu support, gstreamer spends most of the time doing memcpy, and less in the gpu driver, but mpv+ffmpeg spends most of its time in the driver: 72% libmali.so cobjp_neon_linear_to_block_8b_8x8 ; 16% libmali.so cobjp_neon_linear_to_block_16b_8x8, 7% memcpy [10:09:36 CEST] <goodafternoon> hi there [10:09:54 CEST] <goodafternoon> how to convert from .opus to .mp3 please ? [10:21:18 CEST] <DHE> ffmpeg -i input.opus [mp3-options] output.mp3 [10:27:48 CEST] <Rathann> hi [10:28:34 CEST] <Rathann> is it possible to use vdpau or vaapi (with non-Intel gfx) on something else than x86 arch? [10:28:55 CEST] <Rathann> say, arm or ppc? [10:29:57 CEST] <memeka> Rathann: yes, but there are others for e.g. arm [10:30:40 CEST] <memeka> Rathann: from what i know there are vdpau implementations for other archs, so ffmpeg doesn't do anything extra [10:31:38 CEST] <Rathann> ok [10:32:25 CEST] <memeka> is there anything specific you are interested in? [10:38:36 CEST] <Rathann> memeka: no, I just saw that vdpau gets automatically enabled in our ffmpeg package builds in RPMFusion on non-x86 and was wondering if I should disable it explicitly or leave it [11:31:05 CEST] <cosven> #mopidy [11:32:20 CEST] <CoreX> fuck off [12:20:30 CEST] <Dark-knight> hey, whats the CL to combine an audio and video stream into 1 container [12:20:47 CEST] <Dark-knight> audio is .webm and video is .mp4 [12:21:00 CEST] <Dark-knight> do I have to convert video to webm first? [12:21:28 CEST] <Dark-knight> I also want to make sure the audio is synced properly [13:15:58 CEST] <debianuser> Hello. Is there a way to export/import PTS value of each frame? I have a video with changing color balance. And I can fix it by converting video into a bunch of images, then ImageMagick `convert $f -channel all -normalize ../2/$f` and assemble those images back into a video (+audio from original file), but how can I avoid video/audio desync? Can I use PTS values of original video stream somehow? [13:16:43 CEST] <JEEB> not sure if we have such things in the ffmpeg.c command line application [13:17:20 CEST] <Dark-knight> mine was simple [13:18:18 CEST] <Dark-knight> idk nobody can answer it [13:18:43 CEST] <JEEB> `ffmpeg -i input -i input2 -map 0 -map 1 -c copy out_file` is the remuxing side, although most likely most mobile/hardware players will not be able to play the audio [13:18:57 CEST] <JEEB> since most expect certain audio formats in mp4 [13:19:16 CEST] <JEEB> you can add -c:a aac -b:a 192k after -c copy to tell it to re-encode the audio to AAC while at it [13:19:28 CEST] <Dark-knight> will that matter? [13:19:34 CEST] <JEEB> does it matter to you? [13:19:45 CEST] <JEEB> anyways, you can remux and see if anything you use for playback works or not :P [13:19:53 CEST] <Dark-knight> thanks [13:19:54 CEST] <JEEB> and/or if the audio format is not supported [13:19:59 CEST] <JEEB> (by mp4) [13:20:02 CEST] <JEEB> (in FFmpeg at least) [13:20:16 CEST] <Dark-knight> how do I change mp4 to webm [13:20:22 CEST] <Dark-knight> ill just make it easy [13:20:37 CEST] <JEEB> if you are going to be re-encoding video that will take quite a bit more time and you will lose quality [13:20:40 CEST] <JEEB> just keep the video as-is [13:20:44 CEST] <JEEB> re-encoding the audio is simpler as I noted :P [13:21:15 CEST] <JEEB> `-c copy -c:a aac -b:a 192k` is "copy all tracks, but re-encode audio to AAC - oh and I want a bit rate of 192kbps" [13:21:19 CEST] <Dark-knight> what happens if I use cl to change the container without changing content? [13:21:29 CEST] <JEEB> copy you mean? [13:21:35 CEST] <JEEB> that would just put the streams there if possible [13:21:39 CEST] <Dark-knight> yeah [13:21:57 CEST] <JEEB> if the players you care about play the file afterwards, that might be good enough for you [13:21:57 CEST] <Dark-knight> basically just using ffmpeg to change the file extension [13:22:00 CEST] <JEEB> no [13:22:02 CEST] <JEEB> not just extension [13:22:06 CEST] <JEEB> the container is swapped [13:22:13 CEST] <Dark-knight> thats what I mean [13:22:28 CEST] <JEEB> inputs are opened, streams are de-multiplexed, and then not sent for decoding/encoding but just passed into streams of the output [13:22:31 CEST] <Dark-knight> I'm only going to keep it on my computer [13:22:48 CEST] <JEEB> basically try to copy and see if it works :P if it doesn't - add the audio re-encoding [13:22:56 CEST] <JEEB> and that should then work [13:23:02 CEST] <Dark-knight> ok cool thanks [13:23:17 CEST] <JEEB> also you might want to add -movflags faststart just in case if you ever want to read that file over HTTP or something [13:23:26 CEST] <JEEB> that will do a second pass where the index is written at the beginning [13:24:28 CEST] <Dark-knight> I ripped a video from youtube but it split the streams into 2 files for some reason [13:24:43 CEST] <JEEB> you can just remux to matroska instead then P [13:24:44 CEST] <JEEB> :P [13:24:49 CEST] <JEEB> unless you want mp4 for some reason [13:24:54 CEST] <Dark-knight> no [13:24:57 CEST] <Dark-knight> I wanted webm [13:25:06 CEST] <JEEB> then request webm for both video and audio? [13:25:10 CEST] <Dark-knight> I was going to repost it on a website [13:25:13 CEST] <JEEB> also webm is matroska [13:25:19 CEST] <JEEB> (limited set of features of it) [13:25:47 CEST] <Dark-knight> ok, then if I just go back and resave the video as webm will that work? [13:25:55 CEST] <Dark-knight> default save option was mp4 [13:26:08 CEST] <JEEB> yes, just tell youtube-dl to pick webm - search their help etc for the format specifiers :P [13:26:21 CEST] <JEEB> you should then get VP9 video and Opus audio [13:26:22 CEST] <Dark-knight> it wasn't youtube-dl [13:26:30 CEST] <Dark-knight> it was download helper [13:26:37 CEST] <JEEB> then I have no fscking idea :) [13:26:40 CEST] <Dark-knight> lol [13:27:00 CEST] <JEEB> anyways, out of scope for FFmpeg :P [13:28:31 CEST] <debianuser> Dark-knight: Yeah, "youtube-dl" is a great tool (https://rg3.github.io/youtube-dl/download.html) :) Use `youtube-dl http://your-url-to-download` and it should automatically download best video and audio for you and merge them together into a single file. [13:28:47 CEST] <JEEB> and you can control which formats you want :P [13:29:09 CEST] <JEEB> like 99% of all download helpers most likely use youtube-dl in the background [13:29:13 CEST] <JEEB> but anyways, out of topic [13:50:46 CEST] <debianuser> (back to my "use PTS of original video" question... maybe I can do that with some `-vf overlay` magic...) [13:52:11 CEST] <JEEB> not likely, vf overlay is just overlaying stuff on the images [13:52:19 CEST] <JEEB> unless that is what you want to do instead of the PTS stuff [14:07:53 CEST] <debianuser> I thought maybe I can use something like -vf overlay=n=n, like take overlay frame with same number... but, no, "n" is expression parameter, not filter parameter. [14:39:20 CEST] <TheFuzzball> I'm trying to capture a webcam, here's the v4l2 output for valid inputs - https://gist.github.com/anonymous/0ce17b22c2ed33d723336133ca6b3c1b [14:39:26 CEST] <TheFuzzball> I'm using: ffmpeg -f v4l2 -input_format mjpeg -s 1920x1080 -i /dev/video0 -c:v h264_omx out.mp4 [14:39:50 CEST] <TheFuzzball> But ffmpeg fails with: Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [14:40:01 CEST] <TheFuzzball> and "[swscaler @ 0x2f5ec20] deprecated pixel format used, make sure you did set range correctly" [14:40:39 CEST] <relaxed> TheFuzzball: that should be -video_size 1920x1080 [14:41:38 CEST] <TheFuzzball> I thought -s was shortform, ffmpeg -f v4l2 -input_format mjpeg -video_size 1920x1080 -i /dev/video0 -c:v h264_omx out.mp4 also fails with the same error [14:42:28 CEST] <relaxed> this is a rpi3 ? [14:42:31 CEST] <TheFuzzball> Yep [14:44:01 CEST] <TheFuzzball> This is the list-sources output: https://gist.github.com/anonymous/d5547b90cdc76ce3c42cc75b03d23718 [14:44:19 CEST] <TheFuzzball> Looks like ffmpeg doesn't output to stdout, which makes just piping to gist a faff [14:44:22 CEST] <TheFuzzball> Gimme a sec [14:44:37 CEST] <JEEB> TheFuzzball: all multimedia apps output console output to stderr [14:44:39 CEST] <JEEB> so 2> [14:44:48 CEST] <JEEB> because you can use stdout for actually piping content [14:44:54 CEST] <JEEB> like from a decoder to encoder etc [14:45:09 CEST] <TheFuzzball> Ah I see [14:47:03 CEST] <TheFuzzball> https://gist.github.com/anonymous/027f62604319cf19f819c287343df9f1 [14:48:27 CEST] <relaxed> TheFuzzball: try adding -pix_fmt yuv420p after the input [14:50:27 CEST] <TheFuzzball> Hmm, same error [14:52:08 CEST] <relaxed> does "-input_format raw" work? [14:52:43 CEST] <TheFuzzball> Nah, that's not a valid format [14:53:10 CEST] <TheFuzzball> yuyv422 and mjpeg are the only valid formats [14:53:43 CEST] <relaxed> https://www.raspberrypi.org/forums/viewtopic.php?t=105964 [14:53:48 CEST] <TheFuzzball> It seems like it's a problem with the h264 encoder, it's refusing to encode anything it seems. I've got it to work before, tho.. [14:54:05 CEST] <relaxed> that says you need to set gpu_mem=128 [14:54:51 CEST] <TheFuzzball> Ok, I've changed that and rebooted [14:55:23 CEST] <Dark-knight> hey JEEB it didn't work https://pastebin.com/DzmN40vU [14:58:15 CEST] <TheFuzzball> relaxed hmm. that's working.. but the frame rate is 9fps, where the MJPEG output says it should be 30 [14:58:24 CEST] <TheFuzzball> Is the h264 encoder really that slow? [15:00:28 CEST] <TheFuzzball> https://gist.github.com/anonymous/5e651e9f9075bbc6c4e57a63446b0adb [15:00:53 CEST] <TheFuzzball> I guess it must me, the input stream is "mjpeg, yuvj422p(pc, bt470bg/unknown/unknown), 1920x1080, 30 fps, 30 tbr, 1000k tbn, 1000k tbc" [15:16:28 CEST] <rc0r> What's the proper way to build ffmpeg w/o pthread? Using --disable-pthreads breaks the build for me b/c of undefined references to sem_post@glibc :/ [15:17:02 CEST] <jkqxz> References from where? [15:17:53 CEST] <ivan_filho> Hi guys. I need to parse an H264 containing nal units to find only the access unit i need to produce only one frame. I'm parsing an access unit, and by the H264 standard, if i find a access_unit with primary_pic_type == 0, this acces_unit is a complete coded frame, but the problem is, sometimes the encoder encode I-frame as two field pictures where the top field is I-picture and the bottom one is P-picture. And i dont know exactl [15:19:05 CEST] <ivan_filho> an entire access unit (or more) to produce one frame [15:19:28 CEST] <jkqxz> An access unit is a coded picture, not a coded frame. [15:20:52 CEST] <ivan_filho> but a coded picture can ben a coded frame or a coded field, right? [15:20:58 CEST] <jkqxz> If you want to make a frame from two fields, that is two access units (and will have two AUDs). [15:21:01 CEST] <jkqxz> Yes. [15:21:29 CEST] <ivan_filho> My problem is to determine when is a coded frame and when is a coded field [15:21:42 CEST] <ivan_filho> =/ [15:22:00 CEST] <ivan_filho> and, when is a coded field, to find all access unit i nedd to produce the frame [15:22:42 CEST] <jkqxz> If frame_mbs_only_flag, it's all frames. Otherwise look at field_pic_flag in the slice header. [15:23:19 CEST] <jkqxz> Finding all access units to produce a frame is in general a hard problem, because they need not be adjacent in the stream. [15:23:37 CEST] <jkqxz> You would need to look at the POCs and find the matching pair. [15:26:53 CEST] <ivan_filho> so first i find the start access unit? [15:27:18 CEST] <ivan_filho> i mean [15:27:20 CEST] <ivan_filho> the first VCL NAL unit of a primary coded picture [15:27:23 CEST] <ivan_filho> ? [15:30:42 CEST] <ivan_filho> My problem is being finding the matching pair [15:33:22 CEST] <jkqxz> rc0r: <http://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/218489.html>. Builds for me with that. [15:33:58 CEST] <jkqxz> ivan_filho: Why do you want to find it? [15:34:30 CEST] <jkqxz> You'll need to parse at least the SPS and then some of the slice headers to find the information you want. [15:35:19 CEST] <ivan_filho> I have a embbed system moniroting, and a i need to extract one frame to send to server, but i have limited bandwidth [15:37:13 CEST] <jkqxz> It is probably easier to decode the stream, pick the frame you want, and reencode it. [15:37:15 CEST] <ivan_filho> So first, I look at the pic_order_cnt_type in SPS to know the method to decode picture order? [15:38:02 CEST] <ivan_filho> But i'm receiving the a digital tv broadcasting, i just need filter the packets each x times [15:39:38 CEST] <ivan_filho> my hardware has limited architecture, limited memory and process [15:39:55 CEST] <ivan_filho> =/ [15:40:09 CEST] <rc0r> jkqxz: thx, will try that [15:40:50 CEST] <rc0r> jkqxz: /usr/local/bin/ld: libavcodec/libavcodec.a(v4l2_buffers.o): undefined reference to symbol 'sem_post@@GLIBC_2.2.5' in case you're curious [15:41:46 CEST] <jkqxz> Yeah, that's what that patch fixes. [15:47:29 CEST] <ivan_filho> Do you have some tip how to finding the matches access unit? [16:02:57 CEST] <jkqxz> ivan_filho: In general, not really - you just have to read all the slice headers and follow the spec. [16:03:45 CEST] <jkqxz> If you have restricted cases where you know the structure in advance then you may be able to avoid that, though. [16:16:56 CEST] <voltagex> Don't know if anyone cares, but the video converter product currently being promoted by The Humble Bundle appears to be ripping off ffmpeg. [16:17:18 CEST] <JEEB> lol [16:18:01 CEST] <JEEB> how did you verify that is a seeming violation? [16:18:06 CEST] <JEEB> *it is [16:18:09 CEST] <teratorn> are there very many commercial video products left that *aren't* ripped-off ffmpeg? [16:18:28 CEST] <JEEB> because I know at least one app that seemed to actually comply to the LGPL terms [16:18:35 CEST] <JEEB> (it licensed x264 separately from x264 LLC) [16:20:48 CEST] <voltagex> JEEB: no mention of ffmpeg anywhere, "avconvert.dll" has symbols/text [16:20:52 CEST] <voltagex> https://usercontent.irccloud-cdn.com/file/yTXmurtg/image.png [16:30:55 CEST] <ivan_filho> Thanks. [16:31:49 CEST] <Scandy> hello [16:32:45 CEST] <Scandy> can I ask a question here about ffmpeg? [16:33:29 CEST] <JEEB> that's literally what the channel's name is [16:36:29 CEST] <Scandy> ok so here I go! :) I'm running an HLS streaming from a RTSP IP camera as video source, using this simple script: [16:36:39 CEST] <Scandy> fmpeg -i [SOURCE-URL] -acodec aac -vcodec copy -f hls -hls_allow_cache 0 -hls_segment_filename [TRUNK-NAME-BY_SOURCE].ts -hls_time 9 -hls_list_size 0 -hls_flags append_list playlist.m3u8 [16:36:53 CEST] <Scandy> It works, but my result is rather unstable and highly dependent on network performance (acquiring the source from the network). [16:37:25 CEST] <Scandy> What options could I add to my script to make it more "stable" and "network-independent"? [16:38:14 CEST] <Scandy> on BitBucket I found a similar script that uses the following options: [16:38:16 CEST] <Scandy> -bufsize 1M -crf 18 -r 10 -g 30 [16:38:30 CEST] <Scandy> but I can't find description in official docs [16:38:55 CEST] <iive> some of these looks like libx264 options [16:39:15 CEST] <iive> crf is constant rate factor, a way to set quant/quality of the encoder [16:39:41 CEST] <iive> -r is framerate, so 10fps [16:40:17 CEST] <alexp> is there a way to take an MP2 audio track from a video and losslessly copy the right channel to the left channel (effectively turning it into dual mono)? [16:40:18 CEST] <iive> -g is probably gop size, used to set keyframe intervals, so 1 keyframe every 30 frames ( at 10fps, that's each 3 seconds) [16:40:33 CEST] <iive> -bufsize is probably for vbv buffer. [16:40:35 CEST] <blaze> can someone explain me what can be possibly wrong with this code https://github.com/KDE/k3b/blob/master/plugins/decoder/ffmpeg/k3bffmpegwrap… ? [16:40:44 CEST] <blaze> deel free to pm me on taht [16:40:48 CEST] <blaze> *feel [16:41:48 CEST] <zerodefect> Using the C-API to integrate the 'buffer' video filter - is it the case that the input resolution (spatial and temporal) is required at initialisation time? [16:42:55 CEST] <Scandy> thank you very much iive [16:43:31 CEST] <Scandy> but is -framerate option deprecated in ffmpeg 3.3? [16:43:37 CEST] <iive> Scandy: if you are on linux, `man ffmpeg` would give you manual page with all the options. there must be a web page with it on the website [16:44:14 CEST] <Scandy> I'm on Mac and unfortunately there is no man page with my binary [16:44:18 CEST] <zerodefect> I'm getting an error that 'Invalid parameters provided' when using _only_ "time_base=1/25" [16:44:51 CEST] <zerodefect> It seems that if I'm required to specify the spatial resolution, the filters are quite restrictive...which makes me think i'm doing something wrong :) [16:45:23 CEST] <c_14> Scandy: https://ffmpeg.org/ffmpeg.html [16:48:30 CEST] <iive> alexpigment: this sounds way too specific. In theory it should be possible, but I'm not aware of any tool that does it. It is kind of bitstream filter and ffmpeg doesn't have many of these. [16:48:55 CEST] <alexpigment> iive: if I use map channel does it need to re-encode? [16:50:33 CEST] <iive> alexpigment: i think map channel works on pcm data, so yeh. BTW, at least MP3 has a joint stereo mode, where audio is encoded as a center channel (mono) and differenciate channel, that is substracted from the center to get left/right channels [16:50:44 CEST] <Scandy> thank you very much. About framerate option: it's ok if I acquire a 30fps source with -framerate 24 option? [16:51:16 CEST] <alexpigment> iive: yeah, i'm working with actual stereo rather than joint stereo, which is why I was thinking it would be possible to encode losslessly. oh well. thanks for the input [16:51:32 CEST] <iive> Scandy: i don't know. you do "video codec copy" that literally passes through the video without touching it. [16:52:24 CEST] <iive> alexpigment: as I siad, it is quite specific. there might be some project that let's you edit mp2/3 on bitlevel [16:53:20 CEST] <Scandy> iive: yes because it is a H.264 source. Sometimes after a short network error I get a video in "slow motion" while audio is OK, so I wonder if I can somehow fix FPS without reenconding video [16:55:31 CEST] <iive> Scandy: that would need changing the video bitstream, to drop non-reference B-frames and renumber the other frames. [16:56:09 CEST] <Scandy> iive: so I need to re-encode, it is correct? [16:56:35 CEST] <iive> unless there is bitstream filter that already does that... [16:57:45 CEST] <Scandy> iive: about -bufsize option... it is cited but not commented in the docs [16:58:55 CEST] <Scandy> iive: there is a way to "buffer" a video source acquired from network? thank you [17:04:46 CEST] <iive> Scandy: i think it is an encoding option, not cache control. Aka the https://en.wikipedia.org/wiki/Video_buffering_verifier [17:05:23 CEST] <iive> it simply makes the encoder not produce too big or too small packets, so you can use buffer of this size on the player [17:06:11 CEST] <iive> there are more exaples with it in `man ffmpeg-codecs` , strange but libx264 seems to use explicit vbv-buffer option [17:06:21 CEST] <iive> so... no idea [17:07:03 CEST] <Scandy> iive: ok thank you very much ;) [18:29:46 CEST] <Dark-knight> JEEB it didn't work https://pastebin.com/DzmN40vU [18:31:10 CEST] <JEEB> Dark-knight: well you got webms so just use -c copy, and don't set -c:a aac -b:a 192k ? [18:31:13 CEST] <JEEB> that was for mp4 [18:31:26 CEST] <JEEB> also you are only mapping one of the files [18:31:39 CEST] <JEEB> -map 0 only maps things out of the first file, you also need -map 1 [18:41:59 CEST] <Dark-knight> I did -map 1 and it didn't do anything [18:42:04 CEST] <Dark-knight> same error [18:42:38 CEST] <JEEB> did you remove the audio encoding and bit rate? :P [18:42:50 CEST] <JEEB> that was my primary point, and then I just noticed that you weren't mapping the second file :P [18:42:59 CEST] <Dark-knight> yes I already did that [18:43:01 CEST] <Dark-knight> same error [18:43:07 CEST] <JEEB> pastebin the log thank you [18:43:10 CEST] <JEEB> (with command line) [18:46:06 CEST] <Dark-knight> https://pastebin.com/GJHDNZj0 [18:46:32 CEST] <JEEB> uhh [18:46:56 CEST] <JEEB> the video is not webm but a normal matroska [18:47:10 CEST] <JEEB> so it contains video that you can't put into webm [18:47:14 CEST] <JEEB> as the error says [18:47:23 CEST] <Dark-knight> how do I fix this? [18:47:31 CEST] <JEEB> just call the output file something.mkv [18:47:32 CEST] <JEEB> there [18:47:40 CEST] <Dark-knight> ok thanks [18:48:08 CEST] <JEEB> but the error does say what happened, "Only VP8 or VP9 video and Vorbis or Opus audio and WebVTT subtitles are supported for WebM" :) [18:48:15 CEST] <JEEB> and your video file contains H.264 [18:48:56 CEST] <JEEB> oh wait [18:49:11 CEST] <JEEB> your video webm is just renamed mp4 :P [18:49:15 CEST] <JEEB> that is why it has H.264 [18:49:22 CEST] <JEEB> FFmpeg actually picks that up and just works [18:49:31 CEST] <JEEB> instead of kicking you in the face for naming it webm [18:49:33 CEST] <Dark-knight> hmm I guess saving it as webm didn't help [18:49:50 CEST] <JEEB> anyways, just call the output file .mkv and you get yourself a matroska file :P [18:50:05 CEST] <JEEB> or re-add the audio encoding (-c:a aac -b:a 192k) and call it .mp4 [18:50:10 CEST] <JEEB> whatever you want [18:50:29 CEST] <Dark-knight> whats easier to convert to webm. mp4 or mkv? [18:50:42 CEST] <Dark-knight> and is it even possible to convert this? [18:50:51 CEST] <Dark-knight> I got the mkv file already [18:51:07 CEST] <JEEB> why the heck would you be re-encoding the video [18:51:14 CEST] <JEEB> if you can just grab the same thing from youtube again, in VP9 [18:51:15 CEST] <JEEB> :P [18:51:23 CEST] <JEEB> youtube-dl -F "https://youtube.com/something" [18:51:27 CEST] <JEEB> lists all the foramts [18:51:30 CEST] <JEEB> *formats [18:51:33 CEST] <JEEB> and you can then pick [18:51:43 CEST] <JEEB> anyways, out of scope o this channel and you can play that mkv file already :P [18:51:43 CEST] <Dark-knight> lol ok [18:52:31 CEST] <Dark-knight> for the sake of education, lets say in the future I wanted to convert an mkv to a webm. how would I go about doing that? [18:55:14 CEST] <klaxa> https://trac.ffmpeg.org/wiki/Encode/VP8 [18:55:24 CEST] <klaxa> or VP9 if you have time on your hands [18:55:32 CEST] <klaxa> or is VP9 fast now? [18:59:33 CEST] <Johnjay_> how to tell ffmpeg to skip file if it already exists on command line? [18:59:51 CEST] <c_14> -n [19:00:39 CEST] <Johnjay_> thanks [19:01:07 CEST] <Johnjay_> by the way, I was reading about this new firefox update [19:01:18 CEST] <Johnjay_> the one where they are switching to webextension. which might break compatibility [19:01:30 CEST] <Johnjay_> i read that a competitor to firefox wants to use ffmpeg to play media or something [19:01:36 CEST] <Johnjay_> i guess people demand browsers play video so makes sense [19:01:45 CEST] <JEEB> Firefox already uses FFmpeg [19:02:04 CEST] <JEEB> it has the FFmpeg decoder module (mostly used in linux), and they separated the VP9 decoder [19:02:04 CEST] <Johnjay_> right, this is a competitor [19:02:16 CEST] <JEEB> Chromium also uses their own fork of FFmpeg [19:02:17 CEST] <Johnjay_> i was checking them out because firefox 57 might kill extensions [19:02:31 CEST] <JEEB> I'm already on 57 and I'm not really having issues [19:02:35 CEST] <JEEB> https://docs.google.com/spreadsheets/d/1TFcEXMcKrwoIAECIVyBU0GPoSmRqZ7A0VBv… [19:02:39 CEST] <Johnjay_> interesting. yet another bunch of things that rely on ffmpeg [19:02:39 CEST] <JEEB> you can see alternatives here :P [19:02:41 CEST] <JEEB> anyways, off-topic [19:03:24 CEST] <Dark-knight> thanks for the notes [19:03:24 CEST] <JEEB> Johnjay_: heck even the nvidia experience app in nvidia's driver has avcodec-52.dll in it :P [19:03:45 CEST] <Dark-knight> I update my notes everytime I get useful info :) [19:03:47 CEST] <JEEB> (newer one has -55) [19:04:13 CEST] <JEEB> ok, the windows version of Firefox also has mozavcodec.dll [19:04:20 CEST] <JEEB> so it has also some FFmpeg [19:04:33 CEST] <JEEB> Steam has avcodec-56 [19:05:28 CEST] <JEEB> pretty much darn everything has avcodec/format/etc in it :P my TV has it (although they might be using Libav still) [19:05:46 CEST] <Johnjay> eh really [19:05:55 CEST] <Johnjay> that's kind of weird lol [19:06:12 CEST] <Johnjay> TVs in walmart dont' say "USING FFMPEG TECHNOLOGY" in big letters on the front [19:06:24 CEST] <JEEB> easy to check if you grab your stuff's (L)GPL source code release [19:06:38 CEST] <JEEB> since pretty much everything uses linux nowadays, there's at least that to release [19:07:00 CEST] <BtbN> My TV uses some 0.8 version of ffmpeg [19:07:04 CEST] <JEEB> yup [19:07:10 CEST] <JEEB> quite often ancient because bunker development :D [19:07:35 CEST] <JEEB> I think my TV uses at least two pieces of software that I've contributed to [19:07:44 CEST] <JEEB> Libav/FFmpeg being one of them [19:08:10 CEST] <BtbN> I also have no idea how to update them, or get software onto the TV at all [19:08:15 CEST] <BtbN> So no idea if that is GPL compliant [19:08:27 CEST] <JEEB> only v3 tells them to let you switch it [19:08:43 CEST] <Johnjay> tv should be updateable with fully GPL code. #sourcecodematters [19:08:45 CEST] <JEEB> v2 is a-OK with you not being able to actually replace software due to DRM [19:09:02 CEST] <BtbN> There is no DRM. Just no way to get software on the TV, at all [19:09:13 CEST] <JEEB> well that's a technical limitation, no? [19:09:21 CEST] <BtbN> It comes with a pre-baked ROM, no updates intended [19:09:22 CEST] <kepstin> well, if they're using such an old version of ffmpeg, there might be some code execution vulnerabilities in there :) [19:09:42 CEST] <JEEB> kepstin: I'm pretty sure I could try and exploit my TV with some mp4 timed text [19:09:48 CEST] <JEEB> I've seen funky stuff come out of that [19:10:12 CEST] <BtbN> All the Wii U hacks work that way, by making the Browser play mp4 videos to run specific homebrew [19:10:17 CEST] <Johnjay> JEEB: that sounds kind of cool lol [19:10:50 CEST] <JEEB> I think the TV is using Libav/FFmpeg for the mp4 demuxing because it supports E-AC3/TrueHD/DTS-HD MA in mp4 [19:10:51 CEST] <Dark-knight> lol hacking TVs [19:11:38 CEST] <Johnjay> And you converted a video file to TrueHD in mp4 to test this specifically or...? [19:11:58 CEST] <JEEB> I have samples of those audio formats [19:12:21 CEST] <JEEB> Including just grabbing them from the blu-rays I have on my bookshelf [19:13:27 CEST] <Johnjay> now this is odd. [19:13:42 CEST] <Johnjay> I clearly see a webm file in this directory that has not been converted to mp3 [19:13:51 CEST] <Johnjay> I run my for loop to convert webm to mp3 with the -n option [19:13:53 CEST] <Johnjay> but nothing happens [19:16:19 CEST] <Johnjay> the loop clearly hits that webm file. yet ffmpeg isn't producing an output file with -n [19:16:48 CEST] <Johnjay> there we go [19:16:53 CEST] <Johnjay> i had -i -n instead of -n -i [19:16:59 CEST] <JEEB> :P [19:17:09 CEST] <JEEB> yea, "-n" is kind of probably not the file name you wanted to poke [19:17:11 CEST] <Johnjay> i suppose it thought the input file was named -n? :D [19:17:29 CEST] <Johnjay> hehe that one was clearly my fault [19:17:53 CEST] <Johnjay> see i'm fair. when i'm in the wrong i can admit it. but when it's the software that's wrong i'll call it out. [21:23:33 CEST] <timmmit> is there an easy way to do basically "ffmpeg -i %d.bmp out.mp4" in C/C++ where the bitmaps are (unsigned char) buffers of pixels (width and height known)? [21:24:09 CEST] <JEEB> yes, you can do it with the API [21:25:06 CEST] <JEEB> also usually you talk of uint8_t buffers :) [21:26:03 CEST] <JEEB> anyways, you make AVFrames out of that RGB stuff (I will guess it's RGB), then you use avfilter to convert that to YCbCr, and finally feed those post-filtering AVFrames to an encoder of your choice. you get AVPackets out of that, which you push into avformat's mp4 muxer [21:26:05 CEST] <timmmit> can you link me to the api? i cant find something comprehensive [21:26:32 CEST] <JEEB> there's examples in the repo http://git.videolan.org/?p=ffmpeg.git;a=tree;f=doc/examples;h=HEAD [21:26:44 CEST] <JEEB> uh, that didn't work. [21:26:53 CEST] <JEEB> it's under doc/examples in that thing :P [21:27:41 CEST] <JEEB> after that you can google for the generated doxygen documentation if you don't want to generate it yourself [21:27:58 CEST] <JEEB> stuff like this https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [21:29:59 CEST] <timmmit> so is this what im looking for? line 165-180 https://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/doc/examples/e…; [21:30:20 CEST] <JEEB> by the file name, yes [21:30:34 CEST] <timmmit> just need to convert from rgb (yes you guessed right ;)) to YCbCr? [21:30:41 CEST] <JEEB> yes [21:30:53 CEST] <JEEB> libavfilter is the simplest way of going around that [21:31:07 CEST] <JEEB> there's a filtering example as well as far as I know [21:31:17 CEST] <JEEB> the chain would be rather simple :D [21:31:38 CEST] <JEEB> basically "I want this in YUV420P" and then that's almost it [21:31:49 CEST] <JEEB> but it gets you ready for more filtering should you need it [21:32:20 CEST] <JEEB> also libavfilter because it takes in and gives out AVFrames [21:32:28 CEST] <JEEB> which is also what the encoder takes in [23:09:06 CEST] <Johnjay> JEEB: what's the purpose of those doc/examples files [23:09:26 CEST] <Johnjay> is it for vlc people to learn how to use ffmpeg data structures? [23:09:30 CEST] <durandal_1707> to teach you how to code [23:10:20 CEST] <Johnjay> cool [00:00:00 CEST] --- Thu Oct 26 2017

1 0

ffmpeg-devel.log.20171024
by burek 25 Oct '17

25 Oct '17

[00:06:29 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:3f128fc4a3fa: vf_showinfo: Simplify reporting stereo3d information [00:06:30 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:883ce264d9ff: vf_showinfo: Display spherical properties [00:06:31 CEST] <cone-318> ffmpeg 03James Almer 07master:69bb3f7bffa2: Merge commit '3f128fc4a3fa1ef8a87974eb5484a997a84868fe' [00:06:32 CEST] <cone-318> ffmpeg 03James Almer 07master:0acb18d29872: Merge commit '883ce264d9ffc5bdaf477e09ee155b03339c46a6' [00:16:27 CEST] <cone-318> ffmpeg 03Luca Barbato 07master:8c616b3b8996: avplay: Use the named syntax for buffersrc arguments [00:16:28 CEST] <cone-318> ffmpeg 03James Almer 07master:6a426693cce0: Merge commit '8c616b3b8996bd4f9b117496b66b16cc625d7d24' [00:18:38 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:083ea8768121: APIchanges: Update bump dates [00:18:39 CEST] <cone-318> ffmpeg 03James Almer 07master:a60fb1f88f49: Merge commit '083ea8768121ee800893e124b08483011b798919' [00:45:10 CEST] <cone-318> ffmpeg 03Diego Biurrun 07master:d6390090c4db: configure: Skip check for inline assembly capabilities when explicitly disabled [00:45:11 CEST] <cone-318> ffmpeg 03James Almer 07master:4e6c85b3bae0: Merge commit 'd6390090c4dbd766b77353553d9cb4fb4fb41ebd' [00:55:32 CEST] <cone-318> ffmpeg 03Ricardo Constantino 07master:d4f3c26b700a: rtmpproto: send swfverify value as swfurl if latter is unused [00:55:33 CEST] <cone-318> ffmpeg 03James Almer 07master:cd541de9dc27: Merge commit 'd4f3c26b700ae847433ba3c67dc99c32bc1fd4a1' [01:00:18 CEST] <cone-318> ffmpeg 03Sean McGovern 07master:fe6eea99efac: nsvdec: don't ignore the return value of av_get_packet() [01:00:19 CEST] <cone-318> ffmpeg 03James Almer 07master:ce1b1f00bdbe: Merge commit 'fe6eea99efac66839052af547426518efd970b24' [01:48:15 CEST] <cone-318> ffmpeg 03Diego Biurrun 07master:75ef91543422: configure: Disable inline assembly for PathScale compilers [01:48:16 CEST] <cone-318> ffmpeg 03James Almer 07master:acf70639fb53: Merge commit '75ef91543422049a01b594925fcdb182ea12eb09' [10:06:58 CEST] <korean-developer> hello ~~ [10:08:19 CEST] <korean-developer> Is there anyone who has made timelapse with FFMPEG, and know about setting PTS limited ? [10:14:31 CEST] <korean-developer> hey~ [10:14:41 CEST] <korean-developer> is there anyone ?? [10:15:30 CEST] <JEEB> that sounds like using/developing *with* FFmpeg and not FFmpeg development [10:15:34 CEST] <JEEB> please move to #ffmpeg [15:38:04 CEST] <BBB> Im a little concerned that the discussion regarding FF_DEBUG_MV bump is so quiet& does everyone just think its ok to delay it with no plan to actually address it at all? [15:39:37 CEST] <ubitux> BBB: plan would be to set up a dead line just like ffserver [15:39:45 CEST] <ubitux> s/would/can/ [15:39:56 CEST] <BBB> thats what I proposed, but I havent had any positive reactions to that [15:40:06 CEST] <BBB> I did get some private insults from certain people accusing me of dark magic etc. [15:41:49 CEST] <BBB> if other people think an ffserver-style approach is ok, then I can live with that, but Id like it set in stone and agreed upon by everyone; I dont want to see another delay 6 months from now (or whenever) [15:42:36 CEST] <BBB> also, that plan needs to be assigned to someone; if nobody is assigned, ffserver demonstrates nothing will happen and were just delaying for the sake of delaying [15:43:13 CEST] <BBB> e.g. [insert name here] will be responsibe for doing X Y and Z so we can invoke removal of code under FF_DEBUG_MV by [insert date for next abi bump here] [15:43:31 CEST] <BBB> without that [insert name here] part, I can guarantee you that nothing will happen adn were just delaying for no reason [15:43:39 CEST] <BBB> in that case, the code should just go [15:44:41 CEST] <nevcairiel> comparisons to ffserver don't really fit very well, there is actual technical reasons for wanting ffserver to go, this MV stuff doesn't harm anyone, and if it were never deprecated in the first place, noone would even care [15:45:46 CEST] <BBB> kierank: is that true? [15:46:07 CEST] <nevcairiel> i have not once seem anyone mention this MV stuff ever [15:46:29 CEST] <BBB> its because nobody dares touch mpegvideo with a ten-mile pole [15:46:46 CEST] <nevcairiel> and thats not because of MV, so, q.e.d? [15:46:47 CEST] <nevcairiel> :D [15:47:06 CEST] <BBB> that should be posed as a question, not a statement [15:47:21 CEST] <BBB> is MV part of the swamp? [15:47:32 CEST] <nevcairiel> its really not even that much code [16:04:25 CEST] <jamrial> ubitux: ping [16:04:40 CEST] <ubitux> jamrial: pong [16:05:36 CEST] <jamrial> ubitux: can you give 0b9a237b23 a look? [16:05:55 CEST] <jamrial> i don't have arm hardware to bench and choose between keeping our version or replacing it with this [16:06:38 CEST] <ubitux> meh... [16:07:03 CEST] <ubitux> i don't think i can do that today [16:07:06 CEST] <jamrial> there's a 16x16 version a few commits ahead we don't have, so that one's nice :p [16:07:20 CEST] <ubitux> is it present in checkasm? [16:07:51 CEST] <jamrial> yeah [16:08:06 CEST] <ubitux> mmh maybe i can give it a try tonight then [16:08:15 CEST] <jamrial> ok, thanks [16:11:28 CEST] <wbs> fwiw, iirc the libav version should be equivalent or faster on the cores I tested. the ffmpeg one does show some signs of support for skipping parts of the idct for a sparse one, but it didn't actually ever seem to be triggered by the calling C code [16:12:05 CEST] <wbs> (I tried adding checkasm support for testing the partial idcts, but I wasn't able to figure out exactly what the parameter means or how it works, while it was straightforward for vp9) [16:12:36 CEST] <wbs> and given my testing of the calling C code in hevcdec, it actually never passes such values that would make it skip something of the transform [16:13:47 CEST] <jamrial> it's that why alexandra rewrote it? [16:15:57 CEST] <wbs> no, that's just because she didn't know about it; at the point in the review when I noticed you had this version I tried to make sure it wouldn't be worse in some aspect; I think it should be equal or better but it's of course good to check for yourselves [16:17:25 CEST] <wbs> I'm not totally satisfied with the code style/structure of the libav hevc idct asm, but I didn't have time to spend on making it more idiomatic and/or the way I would have written it, but the total performance should be acceptable [17:49:44 CEST] <kierank> BBB: sorry, been on a plane, is what true? [17:50:56 CEST] <BBB> does removing the code under FF_DEBUG_MV help in making mpegvideo more accessible for the changes youre trying to make, or do you think its ok to keep it? [18:16:15 CEST] <jya> BBB: hi [18:17:11 CEST] <jya> BBB: working on resyncing our copy of ffvp9, do I need to worry about the VP9 superframe filter? [18:42:38 CEST] <nevcairiel> vp9 superframe is only needed for (re)muxing [18:44:56 CEST] <jamrial> unless you're talking about the superframe split bsf, which is currently not being used by the decoder, but supposedly will once BBB gets on it :p [18:45:45 CEST] <atomnuker> jya: just curious, why do you need to cut out the decoder? couldn't you just use git submodules and a configure script which only enables it? [18:46:03 CEST] <jamrial> the parser is doing a good job in that regard for the time being [18:47:12 CEST] <jya> atomnuker: you're assuming that ffmpeg source code provides sufficient flexibility to only include the binary portion we need (and can ship) [18:47:16 CEST] <JEEB> atomnuker: I think they don't even use lavc *not sure though), also it might be like Fedora - that they need to get a lawyer to OK the whole code of the dependency, even if during the build only a small portion of it is enabled [18:47:28 CEST] <jya> jamrial: the later.. so it's not used by the decoder yet... good to know [18:48:23 CEST] <jamrial> jya: no, vp9 decoder only needs the vp9 parser for now (and "videodsp" according to configure) [18:48:55 CEST] <atomnuker> JEEB: why would they need a lawyer? firefox isn't being sold [18:49:09 CEST] <jya> atomnuker: now if you find a method that can automate extracting the vp9 decoder, and configure only that, then I'm all for it [18:49:26 CEST] <jya> atomnuker: we ship binaries from the US. [18:49:40 CEST] <jya> it has nothing to being sold or not [18:50:20 CEST] <atomnuker> I thought you had to sell something in order to get permission for patents [18:50:25 CEST] <JEEB> no [18:50:46 CEST] <atomnuker> how disgustingly retarded [18:50:50 CEST] <jya> I so wish :) [18:51:43 CEST] <jya> damn, who came up with this idea of max_pixels in AVCodecContext.... with no functions to set it :( [18:51:45 CEST] <atomnuker> jya: why not distribute binaries from someplace else? [18:52:12 CEST] <jya> mozilla is a not for profit that is based in the US [18:52:33 CEST] <atomnuker> so? your servers can be anywhere [18:52:44 CEST] <atomnuker> you can't change the system if you blindly comply with it [18:52:47 CEST] <atomnuker> boycot it [18:52:54 CEST] <jya> you think the patent holders will care about that details ? :) [18:53:24 CEST] <jya> that's exactly what we do, we don't ship code that contains patent encumbered code [18:53:44 CEST] <atomnuker> well, you don't ship code period. you ship binaries [18:54:03 CEST] <jya> riiiiight [18:54:45 CEST] <JEEB> reality sucks. you're a thing in the US and even if you distro *from* somewhere else you're still a US entity distributing things. anyways, I don't think this is something a normal coder has much leeway over :) [18:54:48 CEST] <atomnuker> just host the servers in the antarctic somehow, in some unclaimed area [18:55:17 CEST] <atomnuker> they can't get you there, there's no government, its international waters [18:55:55 CEST] <jya> atomnuker: yeah, because you know... a US entity (physical or moral) doing something illegal in the US in another country is known as the best way to get around the law [18:57:31 CEST] <atomnuker> how utterly horrible [18:57:35 CEST] <JEEB> in theory if you made Mozilla LLC only produce the source code and say, French VideoLAN Assoc would be doing the binaries and binary distribution that *might* get through something, but still [18:57:59 CEST] <JEEB> generally simpler to just keep away from the mess and enjoy a picnic [18:58:58 CEST] <atomnuker> yarr [18:59:17 CEST] <atomnuker> just code whatever you want and let others distribute binaries [18:59:33 CEST] <atomnuker> its what we do (though because we're lazy to provide official builds I think) [19:00:49 CEST] <jya> michaelni: any chance we can have a AVSetMaxPixelCount(AVCodecContext*, int64_t); type of functions? that would allow to check at runtime if AVCodecContext needs to have max_pixels set ... (referring to your change revision 2f07830e69b ) [19:01:46 CEST] <jya> I don't see how we can make our code get around knowing if this value needs to be set or not (the major version hasn't changed so we can't detect such code) [19:02:07 CEST] <jya> atomnuker: ffmpeg isn't based in the US [19:02:16 CEST] <nevcairiel> either you want to set it, or you don't, i dont see how such a function would help? [19:02:56 CEST] <michaelni> jya, you should be able to use AVOptions to set it without knowing if its in the struct or not if thats what you want [19:03:01 CEST] <jya> nevcairiel: we load dynamically the libavcodec library at run time, we then use templates to determine which version of ffmpeg has been loaded [19:03:14 CEST] <nevcairiel> oh right your batshit insane setup [19:03:23 CEST] <nevcairiel> but yeah use avoptions [19:03:53 CEST] <jya> right now we differentiate the code based on the major version, that allows to determine which avcodec.h to use for compiling the code [19:04:22 CEST] <jya> testing if a method exists in the code is the easiest [19:04:43 CEST] <BBB> jya: \o/ [19:04:47 CEST] <jya> we don't have support for any of AVOptions :( we don't set things up that way... I guess we should [19:05:06 CEST] <JEEB> yea, it's been around for a while :) [19:05:15 CEST] <michaelni> should be simply a single call to av_opt_set_int() for setting this singe param [19:05:28 CEST] <JEEB> yup [19:05:45 CEST] <jya> a pity that the default of max_pixels has been set at 0... that causes current version of firefox to always fail to decode with current version of ffmpeg [19:07:06 CEST] <nevcairiel> 0 means the feature is disabled, why would that cause any failure [19:07:12 CEST] <jya> ubuntu 17.10 ships with 3.3.4 , that makes firefox not work with the version they ship [19:07:18 CEST] <nevcairiel> actually, teh default is INT_MAX [19:08:23 CEST] <jya> nevcairiel: if you initialise via AVOptions yes, avcodec_alloc_context3 returns it with a value set at 0 [19:08:55 CEST] <jya> so that always fails the test later when opening the codec calls ff_set_dimensions [19:09:05 CEST] <kierank> BBB: can't remember, hard to check on my phone. Will check later. [19:09:05 CEST] <jya> as av_image_check_size2 returns an error [19:09:16 CEST] <nevcairiel> i use avcodec_alloc_context3 and it gets inited fine [19:10:01 CEST] <nevcairiel> i checked right after that call, and its set to INT_MAX [19:10:08 CEST] <nevcairiel> so something in your code must be bonkers if its 0 [19:10:46 CEST] <jya> we simply call avcodec_alloc_context3 [19:10:56 CEST] <nevcairiel> with a valid codec? [19:11:46 CEST] <jya> https://github.com/FFmpeg/FFmpeg/commit/2f07830e69b [19:11:49 CEST] <jya> with vp9 codec [19:12:24 CEST] <jya> I don't see any places that would set the value at int_max there unless you called av_opt_set_int [19:12:51 CEST] <nevcairiel> as long as its part of the options_table.h, its defaults values are applied to the struct on creation, always [19:13:15 CEST] <jya> nevcairiel: are you sure you're only using libavcodec here? [19:13:21 CEST] <jya> (and libavutil of course) [19:13:39 CEST] <jya> hmmmm... interesting [19:13:46 CEST] <nevcairiel> how would that matter? I just call avcodec_alloc_context3, put a breakpoint right on the next line, and checked the struct [19:13:47 CEST] <nevcairiel> and its set [19:18:36 CEST] <nevcairiel> just make sure to pass a proper AVCodec to alloc [20:11:03 CEST] <ubitux> jamrial: libav has a faster version, and the 10-bit version [20:11:19 CEST] <ubitux> dunno if they are compatible (and if checkasm actually tests accuracy) [20:11:44 CEST] <ubitux> our: [20:11:46 CEST] <ubitux> hevc_idct_4x4_8_c: 394.1 [20:11:48 CEST] <ubitux> hevc_idct_4x4_8_neon: 126.6 [20:11:53 CEST] <ubitux> with their simd: [20:11:59 CEST] <ubitux> hevc_idct_4x4_8_c: 384.2 [20:12:01 CEST] <ubitux> hevc_idct_4x4_8_neon: 109.2 [20:12:03 CEST] <ubitux> hevc_idct_4x4_10_c: 406.7 [20:12:05 CEST] <ubitux> hevc_idct_4x4_10_neon: 109.2 [20:12:28 CEST] <ubitux> (fluctuating due to various params) [20:12:33 CEST] <ubitux> (also, using perf here) [20:12:58 CEST] <ubitux> here is another run: [20:13:00 CEST] <ubitux> hevc_idct_4x4_8_c: 389.1 [20:13:01 CEST] <ubitux> hevc_idct_4x4_8_neon: 126.6 [20:13:03 CEST] <ubitux> our ^ [20:13:07 CEST] <ubitux> hevc_idct_4x4_8_c: 389.3 [20:13:09 CEST] <ubitux> hevc_idct_4x4_8_neon: 107.8 [20:13:11 CEST] <ubitux> hevc_idct_4x4_10_c: 418.6 [20:13:13 CEST] <ubitux> hevc_idct_4x4_10_neon: 108.1 [20:13:15 CEST] <ubitux> libav ^ [20:13:30 CEST] <ubitux> so yeah, we can probably trash our versions here [20:14:44 CEST] <ubitux> tested with http://sprunge.us/UWfP?diff [20:15:24 CEST] <ubitux> and checkasm --bench=hevc_idct [20:26:48 CEST] <nevcairiel> out idct prototypes should be mostly compatible, i think [20:36:21 CEST] <jamrial> yeah, they changed the mc ones only afaik [20:37:03 CEST] <jamrial> ubitux: will merge into my github repo so you can make sure it works before i push then [21:00:45 CEST] <JEEB> can anyone else chime on the EOF thing, if we want to either A) leave things as they are and just break old clients with an API behavior change B) add an option for the new behavior , or C) revert the 0 != EOF thing [21:01:25 CEST] <JEEB> because while those people that are on IRC have most likely adapted their stuff, we will have quite a bit of breakage due to this :P [21:04:04 CEST] <BBB> ... [21:04:18 CEST] <BBB> Ive stayed quiet lately because I have this creeping feeling that it doesnt matter [21:04:28 CEST] <BBB> we have no rules [21:04:39 CEST] <BBB> people just do whatever they want and will make up rules on the fly to justify their behaviour [21:05:11 CEST] <BBB> so I dont know how to deal with it [21:05:56 CEST] <BBB> its not about what broke, its about who broke it; if its a good person, its fine, and if its a bad person, its not fine. its all political [21:06:13 CEST] <BBB> so Im afraid that likely (A) is your only option :( [21:06:33 CEST] <jamrial> BBB: who broke it is a casual dev, i think, so no politics [21:06:46 CEST] <JEEB> yea [21:06:54 CEST] <jamrial> and it was unintended [21:07:08 CEST] <JEEB> I'd probably go for B but I'm not sure how many places I'd have to poke to add the option [21:07:56 CEST] <jamrial> maybe a temporary option to recover the old behavior should be added for the usual period of ~2 years, and a notice about it being removed eventually added [21:08:32 CEST] <jamrial> basically, deprecating the old behavior and leaving a compat mode for it [21:08:43 CEST] <JEEB> yes [21:08:50 CEST] <jamrial> library users will nontheless have to update their code to enable said option [21:09:04 CEST] <jamrial> then again to remove it two years from now :p [21:09:05 CEST] <jamrial> so dunno [21:09:45 CEST] <jamrial> is this change, unintended breakage aside, a good one? because if it doesn't really bring any worthwile benefit maybe we should just revert it [21:11:51 CEST] <JEEB> the requirement for the change was zero-byte UDP packets which seem to be valid. originally the code was added into the UDP lavf module, but then it was requested to be moved into lavf general [21:12:07 CEST] <JEEB> which thus broke the API behavior [21:12:47 CEST] <nevcairiel> jamrial: i have always questioned the usefulness of the change, but apparently there is obscure crazy things that might use it [21:13:11 CEST] <JEEB> yes, most users don't find that stuff on their networks [21:13:12 CEST] <nevcairiel> and re: flag, if anything it should be inverted, or its still an API break =p [21:13:23 CEST] <JEEB> well flag to have the NEW behavior [21:13:29 CEST] <JEEB> so that the default behavior is the old one [21:13:33 CEST] <JEEB> that's what I meant [21:13:35 CEST] <jamrial> yeah, probably [21:13:35 CEST] <BtbN> It should behave as it used to, which is imo a bit broken, with some flag somewhere to flip it to sane behaviour [21:13:36 CEST] <JEEB> opt-in for the new stuff [21:13:47 CEST] <JEEB> BtbN: agreed [21:14:04 CEST] <BtbN> And it should throw a depercation warning if the flag is unset [21:14:44 CEST] <wbs> alternatively, only throw a warning if the flag is unset _and_ you return 0? [21:15:11 CEST] <wbs> then you can write code that uses AVERROR_EOF for older lavf versions without any ifdefs for the new flag, while still running without warnings on the new lavf as well [21:21:39 CEST] <jamrial> ubitux: https://github.com/jamrial/FFmpeg/tree/mergework [21:51:53 CEST] <ubitux> jamrial: why not else if for bitdepth? [21:52:12 CEST] <ubitux> i guess it's to follow libav's version [21:52:14 CEST] <jamrial> that's how it is in the file i'm merging [21:52:18 CEST] <jamrial> yeah [21:52:38 CEST] <jamrial> i can change it if you want. i'm already merging it into a file with a different name after all [21:52:48 CEST] <ubitux> src/libavcodec/arm/hevcdsp_init_arm.c:31:9: error: implicit declaration of function 'ff_hevcdsp_init_neon'; did you mean 'ff_hevc_dsp_init_neon'? [-Werror=implicit-function-declaration] [21:55:25 CEST] <jamrial> figures [21:55:44 CEST] <ubitux> aside from this it seems to work [21:56:10 CEST] <ubitux> i'll have a deeper look in a moment [21:56:12 CEST] <jamrial> ok [21:56:19 CEST] <jamrial> pushed a fixed version, fwiw [21:56:23 CEST] <ubitux> like, checking the prototypes and running the actual hevc tests [21:56:59 CEST] <ubitux> if you can wait a little, i can't do it right now, probably in about an hour or two [21:57:21 CEST] <jamrial> sure [22:03:12 CEST] <JEEB> jamrial: btw sorry for the quoting but I was just trying to do something about this :P [22:08:32 CEST] <JEEB> and yes, "The road to hell is paved with good intentions" [22:36:57 CEST] <cone-945> ffmpeg 03Carl Eugen Hoyos 07master:3c14547eb75c: lavfi/tests/filtfmts: Constify a variable. [22:52:08 CEST] <cone-945> ffmpeg 03JULIAN GARDNER 07master:df95f145be15: lavc/dvbsub: Do not fail hard in the region block for 256-colour encoding. [22:52:09 CEST] <cone-945> ffmpeg 03Carl Eugen Hoyos 07master:6e1654768585: lavc/dvbsub: Add the missing line separator to dvb_encode_rle8(). [22:56:28 CEST] <jbreeden> Working on developing an SVC decoder module. Unsure of the correct way to deal with frame size changes. When a different-sized frame is decoded, I update the avctx height & width, and reinitialize AVFrame, but I get the following error: https://pastebin.com/VahNYAcp . Is there something else I must do to handle size change? [22:57:01 CEST] <JEEB> as I noted, that sounds like an avfilter issues rather than a decoding issue [22:57:11 CEST] <JEEB> jbreeden: so you're outputting the AVFrame sizes correctly? [22:59:09 CEST] <jbreeden> Yes. When I get the frame back from the decoder library, I use the dimensions provided by the decoder to set both the avctx->width & height and the AVFrame (void *data from decode function cast as AVFrame) width and height) [22:59:58 CEST] <JEEB> jbreeden: then it might just be your test filter chain's stuff not being re-evaluated at each frame [23:00:10 CEST] <JEEB> there's IIRC a parameter for that in certain filters [23:00:50 CEST] <JEEB> jbreeden: so check if any of the filters you're using has an 'eval' option which you can change to 'frame' [23:01:02 CEST] <JEEB> anyways, interesting that someone is having an interest in SVC :) [23:01:21 CEST] <atomnuker> yeah, because its awful and wasn't used anywhere [23:02:01 CEST] <jbreeden> So I'm not manually using any filters. inputting SVC over RTP, then transcode/remuxing to mpeg2 ts. [23:14:04 CEST] <TD-Linux> I think the VP9 decoder can handle frame size changes [23:14:16 CEST] <jbreeden> TD-Linux: Thanks, I'll check that out [23:17:40 CEST] <ubitux> jamrial: alright, testing soon; took a while to build all that stuff on a board [23:25:37 CEST] <jya> is ffmpeg 3.4 known to compile on windows ? I get a compilation error that stdatomic.h can't be found. It's always included, even though HAVE_STDATOMICS is 0 [23:25:37 CEST] <jya> https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/buffer.c#L19 [23:28:20 CEST] <JEEB> jya: last I checked I could compile master on mingw-w64, MSVC I haven't tested recently [23:28:44 CEST] <jya> JEEB: when is "last I checked" ? :) [23:28:55 CEST] <JEEB> 41d6d62702 [23:29:05 CEST] <JEEB> also I think we have FATE machines for both mingw and MSVC [23:29:29 CEST] <JEEB> http://fate.ffmpeg.org/report.cgi?slot=x86_32-mingw-w64-dll-windows-native&… [23:29:36 CEST] <JEEB> mingw-w64 succeeded [23:29:38 CEST] <jkqxz> It should use compat/atomics/win32/stdatomic.h, I think. [23:29:40 CEST] <JEEB> http://fate.ffmpeg.org/report.cgi?time=20171024042436&slot=x86_32-msvc15-wi… [23:29:46 CEST] <JEEB> MSVC succeeded [23:30:30 CEST] <JEEB> (with compilation, there are failing tests for MSVC) [23:30:34 CEST] <jya> is that with mingw ? [23:30:43 CEST] <jya> hmmmm weird [23:30:45 CEST] <JEEB> the first one is mingw-w64 for 32bit it seems [23:30:56 CEST] <JEEB> the latter on is 32bit MSVC [23:31:05 CEST] <JEEB> so both windows toolchains [23:31:18 CEST] <jya> with VS2017 that gives me "z:/build/build/src/media/ffvpx/libavutil/buffer.c(19): fatal error C1083: Cannot open include file: 'stdatomic.h': No such file or directory " [23:31:54 CEST] <JEEB> you probably miss the compatibility header like jkqxz notes [23:32:08 CEST] <JEEB> that gets added into the include path [23:32:30 CEST] <jya> maybe I missed a file then [23:33:10 CEST] <jya> I see : ./compat/atomics/win32/stdatomic.h [23:33:21 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=7a53bc76c75e0be2…> [23:33:37 CEST] <jya> JEEB: thanks for the pointers [23:33:39 CEST] <jkqxz> Is ATOMICS_WIN32 set? [23:34:14 CEST] <jkqxz> And has the include path ended up on your compile lines? [23:36:35 CEST] <jya> don't use configure ... [23:36:48 CEST] <jya> pthread's stdatomic? that's curious [23:38:58 CEST] <nevcairiel> its a last resort fallback using mutexes, not actually atomic [23:39:14 CEST] <jya> nevcairiel: yeah, just looked at the code [23:39:19 CEST] <nevcairiel> but any sane platform should either have C99 atomics, gcc atomics or win32 atomics [23:45:01 CEST] <nevcairiel> jkqxz: our glorious djgpp fate box found some issues in your cbs stuff related to string format argument type mis-matches, if you want to check that out http://fate.ffmpeg.org/report.cgi?slot=x86_64-freedos-djgpp&time=2017102421… [23:49:12 CEST] <nevcairiel> (there is also a bunch of other warnings regarding type mismatches) [23:49:21 CEST] <jkqxz> Um, int is 16-bit there? [23:49:33 CEST] <JEEB> it's DOS [23:49:40 CEST] <jkqxz> How does that even work to build ffmpeg at all? [23:49:55 CEST] <JEEB> because djgpp exists [23:49:58 CEST] <jkqxz> s/build/run/ [23:50:07 CEST] <jkqxz> I guess building might work. [23:50:12 CEST] <nevcairiel> it doesnt run [23:50:13 CEST] <thardin> interesting that someone cares about it [23:50:24 CEST] <nevcairiel> but its good for finding those format mismatches [23:51:40 CEST] <jkqxz> The warnings are all the macro containing <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/cbs_mpeg2.c;h=d13…>, which should be uint32_t to pass to that pointer. [23:52:15 CEST] <nevcairiel> no harm in exactly using the same type the function wants, tho! :) [23:52:39 CEST] <jkqxz> The printf ones are indeed wrong. [23:52:57 CEST] <jkqxz> Is it building with Werror to make those mismatches actually kill it? [23:53:03 CEST] <nevcairiel> probably [23:53:18 CEST] <nevcairiel> that was the basic purpose to set it up, to find those [23:53:32 CEST] <nevcairiel> -Werror=format [23:53:34 CEST] <nevcairiel> so yeah [23:55:06 CEST] <jkqxz> I feel like coverity or similar should catch that sort of thing. [23:57:40 CEST] <ubitux> jamrial: as said on github, LGTM, thanks [23:59:13 CEST] <jamrial> ubitux: ok, thanks for testing [00:00:00 CEST] --- Wed Oct 25 2017

1 0

ffmpeg.log.20171024
by burek 25 Oct '17

25 Oct '17

[11:47:20 CEST] <heftig> is it legal to resume feeding a decoder after flushing it? [11:48:06 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [11:48:09 CEST] <JEEB> goes through that I think [11:48:26 CEST] <JEEB> yes, it does [12:16:58 CEST] <Guest17399> Hi there, how are you? Hey I was trying to read the ffmpeg output and then I saw this pattern: "encoder: Lavc57.89.100 <videoenc>" [12:17:10 CEST] <Guest17399> I would like to know what is Lavc57.89.100 [12:17:28 CEST] <Guest17399> what this does reference? (lib av? v 57 ?) [12:17:42 CEST] <_julian> is it allowed to change AVCodecParameters of an AVStream at runtime? [12:17:45 CEST] <Guest17399> because I saw this for both audio and video. [12:17:47 CEST] <BtbN> The libavcodec version. [12:17:57 CEST] <Guest17399> encoder : Lavc57.89.100 libx264 [12:18:03 CEST] <_julian> inside a libavdevice input module [12:18:04 CEST] <Guest17399> encoder : Lavc57.89.100 libfdk_aac [12:18:31 CEST] <Guest17399> thanks BtbN and _julian [12:20:22 CEST] <Guest17399> BtbN: is it an internal version? because when I look at the official docs it seems that libavcoded is on 3.2 https://www.ffmpeg.org/doxygen/3.2/index.html [12:20:44 CEST] <BtbN> It's the libavcodec version, not the ffmpeg project version. [12:21:21 CEST] <BtbN> And the latest ffmpeg version is 3.4. [12:22:43 CEST] <Guest17399> BtbN: thanks, I took that (now I know it's wrong) conclusion by just looking at the official docs. [12:26:21 CEST] <memeka> hi; how are decoded frames sent to the video drivers? profiling gstreamer and mpv+ffmpeg, I get very different results: on my arm board with no dmabuf-import gpu support, gstreamer spends most of the time doing memcpy, and less in the gpu driver, but mpv+ffmpeg spends most of its time in the driver: 72% libmali.so cobjp_neon_linear_to_block_8b_8x8, 16% libmali.so [12:26:21 CEST] <memeka> cobjp_neon_linear_to_block_16b_8x8, 7% memcpy [12:26:43 CEST] <Guest17399> I saw where it's defined thanks a lot BtbN https://ffmpeg.org/doxygen/trunk/libavcodec_2version_8h.html#ab85a906b062b0… [14:57:31 CEST] <armegeden> hello: I'm trying to figure out the syntax to take any media file, strip all metadata, then insert a custom Title and Comment metadata. i have this so far: ffmpeg -i "input.mp4" -c copy -map 0 -map_metadata -1 -metadata title="TITLE" -metadata comment="TEST" "output.mp4" --- but it doesn't appear to be taking the arguments. Am i missing some [14:57:31 CEST] <armegeden> thing? [15:17:30 CEST] <memeka> hi; how are decoded frames sent to the video drivers? profiling gstreamer and mpv+ffmpeg, I get very different results: on my arm board with no dmabuf-import gpu support, gstreamer spends most of the time doing memcpy, and less in the gpu driver, but mpv+ffmpeg spends most of its time in the driver: 72% libmali.so cobjp_neon_linear_to_block_8b_8x8, 16% libmali.so [15:17:30 CEST] <memeka> cobjp_neon_linear_to_block_16b_8x8, 7% memcpy [15:19:54 CEST] <jkqxz> mpv uses GL to do rendering for display (colour conversion and overlays). No idea what gstreamer does, but presumably not that. [15:48:06 CEST] <IamTrying> http://paste.ubuntu.com/25809471/ - Why not converting? [15:50:23 CEST] <c_14> need a -i before the input file [15:50:33 CEST] <c_14> and you probably want -c copy if it'll work [15:50:37 CEST] <c_14> If you just want to remux the files [15:50:41 CEST] <c_14> so you don't reencode everything [15:59:41 CEST] <IamTrying> Oh boy. thank you c_14, very difficult to remember all those. [17:21:57 CEST] <_julian> can h264_vaapi be configured to cbr mode? [17:26:55 CEST] <jkqxz> Set rc_max_rate (-maxrate) equal to bit_rate (-b). [17:27:18 CEST] <_julian> jkqxz: thanks :) [17:27:22 CEST] <jkqxz> (You also get it automatically on old driver versions with no VBR support.) [17:27:28 CEST] <_julian> ok [18:18:25 CEST] <N0rdell> Why the change in 3.1 from the decode_video/audio api to send/receive packet/frame api? [19:09:35 CEST] <pgorley> N0rdell: it decouples input and output, other than that, i wouldn't know [19:10:28 CEST] <JEEB> N0rdell: lets format do separation of the two things better (not every feed call gets a decoded frame, and you don't need to feed another packet to get stuff out of the decoder [19:10:34 CEST] <JEEB> basically as a design I prefer it [19:10:56 CEST] <DHE> there were some other changes, such as the old API occasionally not consuming all input... [19:11:30 CEST] <JEEB> N0rdell: https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [19:11:44 CEST] <JEEB> this document explains how this stuff works and replaces some legacy functions [19:11:47 CEST] <JEEB> also one thing I forgot [19:11:53 CEST] <JEEB> it normalizes behavior between video and audio [19:12:05 CEST] <JEEB> they both now have the same functions [19:15:43 CEST] <N0rdell> I see more clarity in what is considered a frame and what is considered a packet [19:17:38 CEST] <N0rdell> I was seeing some behaviour - the send api was causing the receive api to buffer a lot of frames. receive packet never returned any encoded frames until I entered flush mode - and then I received all the frames [19:17:54 CEST] <N0rdell> I wonder if there is way to configure how many frames are buffered by the format [19:19:16 CEST] <JEEB> the decoder shouldn't buffer more than it needs [19:23:26 CEST] <N0rdell> Thank you JEEB [19:24:10 CEST] <JEEB> so it's either a bug or something else. I would always recommend trying the latest master's HEAD if FATE looks green [19:24:19 CEST] <JEEB> FATE being http://fate.ffmpeg.org/ [19:24:25 CEST] <JEEB> which is the automated testing suite [19:24:41 CEST] <N0rdell> Another problem I am running into; I had some of my own code that did what avcodec_parameters_to_context is doing. So I pulled it out because the deprecated codec object. But the problem I am seeing now is I cant configure details such as reference frames [19:25:10 CEST] <N0rdell> I would love to hand off an SPS and get back a fully configured context [19:25:23 CEST] <N0rdell> Now it looks like I am going to have to rewrite that code [19:26:40 CEST] <JEEB> yea, for AVC/HEVC you shouldn't have to set any values before hand (although you can indeed move info from a demuxer to a decoder via that helper from codecpar thing [19:26:53 CEST] <JEEB> if you feed it parameter sets and then video it should JustWork (TM) [19:27:05 CEST] <JEEB> (in AVPackets of course) [19:27:15 CEST] <JEEB> and then you get an AVFrame which then contains the state of the decoded video at that point [20:18:32 CEST] <N0rdell> JEEB: sorry - I missed there. Where is the api where you can feed a parameter set and get an encode context? I have always done it by hand... [20:20:00 CEST] <JEEB> N0rdell: if you really want to do the parsing yourself you can make AVPackets out of NAL units and push them to the decoder [20:20:16 CEST] <JEEB> there is also an AVC and HEVC parser [20:20:30 CEST] <N0rdell> Ill need to get an encode context from those packets tho [20:20:37 CEST] <N0rdell> not a decode context [20:20:47 CEST] <JEEB> packets are already coded data [20:21:10 CEST] <JEEB> avpacket -> decoder -> avframe -> encoder -> avpacket [20:21:37 CEST] <JEEB> coded data -> decoder -> raw data -> encoder -> coded data [20:21:39 CEST] <N0rdell> So you are saying... feed an encoded frame to the encoder and the encoder will automagically configure itself [20:21:52 CEST] <JEEB> you were talking of SPS/PPS [20:21:57 CEST] <JEEB> which is decoding [20:22:12 CEST] <JEEB> so something is definitely lost in translation :P [20:22:47 CEST] <N0rdell> Yeah I have a video I want to decode... make some changes and reencode using the same SPS/PPS [20:25:38 CEST] <N0rdell> In other words... lets say the input video used 3 reference frames and 1 bframe. It should be relatively straight forward to pass the encoder the SPS as all that information is encoded in the SPS. But its not that simple. avcodec_parameters_to_context must be used between the decode and encode context and its still not complete [20:26:08 CEST] <N0rdell> So avcodec_parameters_to_context is a step in the right direction but is incomplete [20:26:41 CEST] <JEEB> well it's not meant for that kind of stuff I think. it's usually used to initialize the decoder from the demuxer's decoder instance I think [20:26:45 CEST] <N0rdell> it would be cool to have avcodec_sps_pps_to_context [20:26:49 CEST] <JEEB> although I'm not 100% sure :P [20:27:32 CEST] <JEEB> anyways, I wish I remembered the code I wrote some time ago encoding things so I'd remember the current correct flow [20:27:36 CEST] <JEEB> I mostly do internal development [20:28:08 CEST] <N0rdell> Just work on ffmpeg? [20:28:58 CEST] <JEEB> the libraries [20:29:13 CEST] <JEEB> I do code API clients as well but it's been a few months since I've written my last full encoder :P [20:30:11 CEST] <pgorley> can AVCodecContext->get_format be called twice in a row with different pixel formats? [20:31:43 CEST] <N0rdell> JEEB thanks for the help [20:31:43 CEST] <JEEB> N0rdell: I think we nowadays have parameter set parsing functionality in the libraries (unless that thing didn't get merged yet), but I am not sure how much that is usable externally [20:32:16 CEST] <JEEB> and yes, with encoding you set AVOptions and touch the AVCodecContext [20:33:25 CEST] <pgorley> for decoding, i mean [20:41:25 CEST] <evelynzx> http://bit.ly/realgirlz - Meet REAL cosplay girls, women, couples, gay, bi and more for Free! check it out [21:36:29 CEST] <JASTON> Hey gang, having issues with the HLS muxer, looking for some guidance. I'm trying to extract audio tracks from a file, with segment time set at 10. The resulting audio segments seem to honor -hls_time, but the resulting m3u8 is all over the place with durations: https://pastebin.com/qjPutLtk [22:51:10 CEST] <jbreeden> Working on developing an SVC decoder module. Unsure of the correct way to deal with frame size changes. When a different-sized frame is decoded, I update the avctx height & width, and reinitialize AVFrame, but I get the following error: https://pastebin.com/VahNYAcp . Is there something else I must do to handle size change? [22:53:19 CEST] <JEEB> that sounds like an avfilter issue. I know that the AVC, HEVC and mpeg-2 decoders should support resolution changes [22:53:33 CEST] <JEEB> not sure if exactly what you're doing is correct, but yunno [22:53:48 CEST] <JEEB> jbreeden: also if you're doing SVC for libavcodec I recommend you pop over to the -devel channel [22:53:56 CEST] <JEEB> that's the FFmpeg internals development stuff [22:55:57 CEST] <jbreeden> JEEB: Okay, thanks, I'll post it over there. I've been searching through h264 and hevc modules trying to understand what they're doing, I'm still in a little over my head. [22:56:10 CEST] <JEEB> :) [00:00:00 CEST] --- Wed Oct 25 2017

1 0

ffmpeg-devel.log.20171023
by burek 24 Oct '17

24 Oct '17

[00:47:36 CEST] <cone-518> ffmpeg 03James Almer 07master:1eb01cca6f70: avutil/hmac: remove gap in AVHMACType enum values [01:27:11 CEST] <cone-518> ffmpeg 03James Almer 07master:90eb0a2180fd: avutil/tests/hmac: remove superfluous loop [01:55:15 CEST] <cone-518> ffmpeg 03James Almer 07master:0cb8369bce32: avcodec/tak: make buf const in avpriv_dca_parse_core_frame_header() [03:13:10 CEST] <Compn> "The contents of SMPTE ST 2073 looked sane" [03:13:11 CEST] <Compn> ahaha [03:13:45 CEST] <Compn> thanks kierank for writing up https://medium.com/@kierank_/reverse-engineering-the-gopro-cineform-codec-7… , i like reading these things [06:04:03 CEST] <jamrial> ubitux: http://fate.ffmpeg.org/log.cgi?slot=armv7a-android-gcc-4.4-shared&time=2017… [06:04:14 CEST] <jamrial> andriod ndk doesn't seem to have linux perf [06:51:51 CEST] <Compn> so whats the filter command to generate an ffmpeg zigzag logo ? :) [06:51:55 CEST] <Compn> theres got to be one [10:44:59 CEST] <ubitux> alright, time to drop vda [10:50:51 CEST] Action: nevcairiel waves goodbye [10:55:19 CEST] <durandal_170> Compn: geq [10:55:40 CEST] <JEEB> ubitux: is this one of those cases where you whirl your magical wand and go "In the name of the Moon, begone!" [10:57:49 CEST] <ubitux> btw, can we remove the pixel format or not? [10:57:57 CEST] <ubitux> like, i'm not sure what state we are in? [10:58:13 CEST] <ubitux> breaking api/abi for a week or 2 is fine, right? [10:58:30 CEST] <nevcairiel> you can break ABI for a month or so, API should follow the usual rules, 2 year deprecation [10:58:42 CEST] <nevcairiel> but vda probably was deprecated [10:59:07 CEST] <ubitux> yeah i mean, if i'm dropping the pixel format it's going to shift everything [10:59:11 CEST] <ubitux> that's why i'm asking [11:06:04 CEST] <ubitux> libavutil/utils.c: av_assert0(AV_PIX_FMT_VDA_VLD == 81); //check if the pix fmt enum has not had anything inserted or removed by mistake [11:06:06 CEST] <ubitux> meh [11:14:34 CEST] <nevcairiel> these stupid ABI checks need to be updated anyway [11:17:22 CEST] <rcombs> can always leave a dummy entry [11:17:45 CEST] <nevcairiel> its abi changing time, no dummy entries needed [11:17:45 CEST] <ubitux> yeah i'm going to leave it with... FF_API_VDA [11:17:59 CEST] <rcombs> I mean I'm all for ABI breaks when necessary but enums are a really easy one to avoid [11:18:17 CEST] <nevcairiel> the offsets already changed anyway, all those old vdpau ones are dead code right now [11:18:46 CEST] <ubitux> mmh [11:49:44 CEST] <cone-318> ffmpeg 03Carl Eugen Hoyos 07master:3605b312f65c: lavf/avio: Print the https warning also for missing tls protocol. [11:56:31 CEST] <cone-318> ffmpeg 03Clément BSsch 07master:2b320318273b: lavc: drop VDA [12:11:05 CEST] <sfan5> ^ JEEB [12:42:12 CEST] <cone-318> ffmpeg 03John Stebbins 07master:4a9d32baca3a: mov: fix decode of fragments that overlap in time [12:42:13 CEST] <cone-318> ffmpeg 03Michael Niedermayer 07master:2c9fa4162b34: ffmpeg: add -bitexact flag to simplify enabling bitexact mode in (de)muxer and (de/en)coder [12:46:06 CEST] <JEEB> sfan5: cheers [12:46:18 CEST] <nevcairiel> does anyone know if sws in slice mode works correctly these days? [13:01:18 CEST] <ubitux> nevcairiel: the slice mode is very confusing in sws [13:01:39 CEST] <ubitux> it's definitely not designed for threading, and i'm pretty sure a bunch of optimizations do not handle it well [13:02:06 CEST] <nevcairiel> i really need threaded scaling though, and creating multiple contexts all processing a different slice sounded like something that might work in theory [13:30:45 CEST] <cone-318> ffmpeg 03Martin Storsjö 07master:f1fd12ef858c: lavu/arm: Check for have_vfp_vm instead of !have_vfpv3 for float_dsp_vfp [13:31:53 CEST] <cone-318> ffmpeg 03Martin Storsjö 07release/3.4:587fadaef1e8: lavu/arm: Check for have_vfp_vm instead of !have_vfpv3 for float_dsp_vfp [15:59:30 CEST] <cone-318> ffmpeg 03James Almer 07master:8c2b82912334: avutil/frame: remove unneccessary metadata pointer getter [18:23:52 CEST] <JEEB> nevcairiel: yup. it's an api break :D [18:24:09 CEST] <JEEB> re the read thing [18:24:11 CEST] <JEEB> 33 [18:24:24 CEST] <jamrial> good thing it was committed after 3.4 was branched, then [20:40:27 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:8933ac207964: lavc: Drop deprecated debug mv functionality [20:40:28 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:0c7986df4442: lavc: Drop deprecated workaround bugs options [20:40:29 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:c06e73929199: lavc: Drop deprecated extended aspect ratio symbol [20:40:30 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:0871e2337777: lavc: Drop deprecated architectures symbols [20:40:31 CEST] <cone-318> ffmpeg 03Diego Biurrun 07master:dcc39ee10e82: lavc: Remove deprecated XvMC support hacks [20:40:32 CEST] <cone-318> ffmpeg 03James Almer 07master:d8a124e7ebc0: Merge commit '8933ac2079644fb09916f1875c569103aefe84b1' [20:40:33 CEST] <cone-318> ffmpeg 03James Almer 07master:51b88c3d4eb5: Merge commit '0c7986df444273b0e53d3992ba9cc1108bd6a386' [20:40:34 CEST] <cone-318> ffmpeg 03James Almer 07master:b13e61d6296e: Merge commit 'c06e73929199c4bdbb32ffb3d81c27ea57dd1458' [20:40:35 CEST] <cone-318> ffmpeg 03James Almer 07master:c381f6a483e0: Merge commit '0871e2337777d9161e7f3554bcad19dabc9e15e1' [20:40:36 CEST] <cone-318> ffmpeg 03James Almer 07master:b46613dd9b8b: Merge commit 'dcc39ee10e82833ce24aa57926c00ffeb1948198' [20:40:37 CEST] <cone-318> ffmpeg 03James Almer 07master:7bbe33b05267: avcodec/libx264: add me_method alias to set X264Context->motion_est [20:52:32 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:72dc7ddd18fe: lavc: Drop deprecated error rate option [20:52:33 CEST] <cone-318> ffmpeg 03James Almer 07master:400ecd8e4059: Merge commit '72dc7ddd18fe54ee68aec71590c3202ad009a8fc' [20:58:04 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:cbebc3251bc2: lavc: Drop deprecated public symbols [20:58:05 CEST] <cone-318> ffmpeg 03James Almer 07master:0b79fdeb9a81: Merge commit 'cbebc3251bc2544b469e0dcb176bc04779d8866c' [21:00:13 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:da5ba26b9e25: lavc: Drop deprecated macroblock type symbols [21:00:14 CEST] <cone-318> ffmpeg 03James Almer 07master:f7eb1c9ac55b: Merge commit 'da5ba26b9e25f408e8d2f9428c9eca699f11a7db' [21:01:34 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:06c20d3e32c3: lavc: Drop deprecated av_fast_malloc() compatibility [21:01:35 CEST] <cone-318> ffmpeg 03James Almer 07master:d658e04337c5: Merge commit '06c20d3e32c33c4da6d9fbc43aebaeb38c45b859' [21:06:54 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:b3739599bda7: lavc: Drop deprecated emu edge functionality [21:06:55 CEST] <cone-318> ffmpeg 03James Almer 07master:7b550c5f84f2: Merge commit 'b3739599bda740ac12d3dde31a331b744df99123' [21:10:47 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:302554835e39: lavc: Drop deprecated unused public members [21:10:48 CEST] <cone-318> ffmpeg 03James Almer 07master:6e69525e6984: Merge commit '302554835e39b79b977ed60c9afe81b44590dfef' [21:27:39 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:bb45d11282d9: lavc: Drop deprecated codec flags [21:27:40 CEST] <cone-318> ffmpeg 03James Almer 07master:b79a7da36faa: Merge commit 'bb45d11282d93af0e8d4c8fd6bc6405f7439a940' [21:29:51 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:4476027d9368: lavc: Drop deprecated avctx codec name [21:29:52 CEST] <cone-318> ffmpeg 03James Almer 07master:5a2e581879b8: Merge commit '4476027d93680cd88d2f75ef1cef5b0c276a8704' [21:34:43 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:5182a28b5de0: lavc: Drop deprecated global afd field [21:34:44 CEST] <cone-318> ffmpeg 03James Almer 07master:2ccd00dabd5a: Merge commit '5182a28b5de060c51c21b36053ab205bfbbbbe31' [21:39:06 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:48bb0da05032: lavc: Drop deprecated way of setting audio delay on encode [21:39:07 CEST] <cone-318> ffmpeg 03James Almer 07master:d2484639bc20: Merge commit '48bb0da050329e5111b00a12dfc154b7e78fb3a3' [21:53:02 CEST] <cone-318> ffmpeg 03James Almer 07master:eb5f84633991: avcodec: drop deprecated vismv option [21:57:44 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:c43a96fe16e6: lavc: Drop deprecated time_base variable for decoding [21:57:45 CEST] <cone-318> ffmpeg 03James Almer 07master:3e0a16f00333: Merge commit 'c43a96fe16e6a6ea091e64ca271f0788f4a0bea9' [22:22:00 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:94eed68ace9f: lavc: Drop deprecated options moved to private contexts [22:22:01 CEST] <cone-318> ffmpeg 03James Almer 07master:fb41bad7e051: avodec/vaapi: drop deprecated vaapi_context fields [22:22:02 CEST] <cone-318> ffmpeg 03James Almer 07master:bfab4308560c: Merge commit '94eed68ace9f2416af8457fcbf142b175928c06b' [22:25:37 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:0648dec19db8: lavc: Drop deprecated stream codec tag [22:25:38 CEST] <cone-318> ffmpeg 03James Almer 07master:c17f638565c6: Merge commit '0648dec19db83bc8c87814d195e32cbad5698a40' [22:37:31 CEST] <jamrial> iive: ping [22:37:54 CEST] <iive> jamrial: pong [22:40:41 CEST] <jamrial> iive: i already removed all the dead xvmc code, but i noticed the xvmc_pix_fmt struct in the xvmc.h header is still used by the hwaccels you added [22:40:54 CEST] <jamrial> does it need to stay in that header, or can it be moved to xvmc_internal.h? [22:42:27 CEST] <iive> it must be public header since it is used for communication with the application [22:43:51 CEST] <jamrial> so the hwacells need the struct to be public? ok [22:44:05 CEST] <jamrial> wouldn't it make sense to remove the deprecated attribute, then? [22:44:38 CEST] <iive> yes, unless/until surface allocation is moved inside ffmpeg [23:01:06 CEST] <cone-318> ffmpeg 03Mateusz 07master:f192f2f061d9: swscale: more accurate DITHER_COPY macro for full and limited range [23:16:58 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:dd343fd98645: lavu: Drop deprecated VDPAU pixel formats [23:16:59 CEST] <cone-318> ffmpeg 03James Almer 07master:b773a8d8c1df: Merge commit 'dd343fd986459f467a2d1d70c26101dff1d47d68' [23:18:55 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:619a433eca2c: lavu: Drop deprecated option type [23:18:56 CEST] <cone-318> ffmpeg 03James Almer 07master:c0cfc0ce11c1: Merge commit '619a433eca2c5655c41b799e0b06380020fb1498' [23:21:03 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:35cf146a33ce: lavu: Drop deprecated av_dlog macro [23:21:04 CEST] <cone-318> ffmpeg 03James Almer 07master:572b7a0b8562: Merge commit '35cf146a33ce41a1adb6c9bd5a0827eacb1b6bfc' [23:48:10 CEST] <cone-318> ffmpeg 03Vittorio Giovara 07master:5f90ad99bb7e: spherical: Change types of bounding and pad to uint32_t [23:48:11 CEST] <cone-318> ffmpeg 03James Almer 07master:2f4677a11fd9: Merge commit '5f90ad99bb7e53383fefab5107b861e4c4600700' [00:00:00 CEST] --- Tue Oct 24 2017

1 0

ffmpeg.log.20171023
by burek 24 Oct '17

24 Oct '17

[00:04:52 CEST] <thebombzen> macroblocks [00:11:27 CEST] <MilanDierick> Got a quick question: is it just me or is the link to download windows build packages offline? [00:16:28 CEST] <SonicTheHedgehog> MilanDierick: I just downloaded the nightly git build, 64-bit, static from here https://ffmpeg.zeranoe.com/builds/ [00:16:33 CEST] <SonicTheHedgehog> MilanDierick: Seems to download fine. [00:17:16 CEST] <MilanDierick> Oh, now I can acces the site properly again. Seems like the problem was on my side... [00:17:52 CEST] Action: SonicTheHedgehog nods. [00:31:02 CEST] <arpu> when i read a rawvideo from a pipe can and set the frame rate with -15 and -vsync cfr the frame rate is not constant 15fps [00:31:38 CEST] <arpu> how can i get a costant 15fps input ? (dublicate or drop frames to get the 15fps) [00:35:40 CEST] <marcurling> Hello, while trying to use -ilme (no video codec specified but h264/AVC ok for me) I get "Unrecognized option 'ilme'. [00:35:40 CEST] <marcurling> Error splitting the argument list: Option not found" [00:36:20 CEST] <JEEB> what are you trying to do? enable interlacism? [00:36:31 CEST] <marcurling> (I'm willing to encode interlaced MPEG2 to interlaced AVC) [00:36:38 CEST] <marcurling> yup [00:36:57 CEST] <JEEB> the docs say MPEG-2 and MPEG-4 only [00:37:32 CEST] <marcurling> so output.mp4 should work? [00:37:49 CEST] <JEEB> uhh, that's the container [00:38:48 CEST] <marcurling> What should be the -vcodec , please? [00:39:11 CEST] <JEEB> I mean, that option doesn't work for any other encoders than such that you don't want to use [00:39:20 CEST] <JEEB> since you want to use H.264/AVC (and thus most likely libx264) [00:39:38 CEST] <JEEB> just checking if there's a way to enable but not force field order [00:39:44 CEST] <JEEB> so it might get used from the input :P [00:46:17 CEST] <maicod> hi can I use ffmpeg or ffprobe to run through an entire mp4 file to determine the peak bitrate used ? [00:48:31 CEST] <JEEB> maicod: with -of json and -show_packets you can get some sort per-packet byte size, which you can then take together with the DTS/PTS and calculate some peaks, although I am not 100% that'd get you correct. for proper VBV/HRD you'd need to actually make sure that those things are the NAL units' sizes etc [00:48:52 CEST] <JEEB> basically "peak bit rate" sounds like a simple thing, but what does one actually mean with it is the most important thing [00:49:28 CEST] <JEEB> is it just maximum bits over a single sample used or over something else like VBV/HRD [00:53:02 CEST] <maicod> thanks jeeb I'm not at all good with ffmpeg so your information dazzles me. I'm testing out a wifi connection and during a high action scene in a movie file I'm getting breaks in the playing while my wifi connection is 100 percent (wifi N at 1 meter distance from wifi router) and when trying copying files it usually does not go under the 3000 Kilobyte per second speed [00:53:19 CEST] <maicod> so I was wondering what is the highest bitrate in that action scene [00:56:18 CEST] <maicod> mediainfo gives 4500 Kbps as average which needs to be divided by 8 to get KBps so thats around 550 KBps only [01:01:19 CEST] <marcurling> JEEB Did I get something wrong or should I wait from some more info from you? [01:01:41 CEST] <marcurling> or may be it's no use encoding interlaced? [01:02:14 CEST] <JEEB> x4->params.b_interlaced = avctx->flags & AV_CODEC_FLAG_INTERLACED_DCT; [01:02:33 CEST] <JEEB> marcurling: well *you* should know if it's any use encoding interlaced [01:02:38 CEST] <JEEB> since you requested it [01:02:47 CEST] <JEEB> now to see if anything sets that flag [01:03:03 CEST] <JEEB> marcurling: -flags ildct [01:03:07 CEST] <JEEB> try that out with libx264 [01:03:16 CEST] <JEEB> if you really need interlacism [01:03:44 CEST] <marcurling> For sure, encoding an interlaced source 'inretlaced' preserves quality [01:04:03 CEST] <marcurling> ^trying out, thank you [01:04:23 CEST] <JEEB> yea, if you don't want to deinterlace then of course for interlaced content that makes sense [01:05:31 CEST] <JEEB> marcurling: libx264 should be dumping its internal parameters into the log as a long string at some point so you can keep your eye out for anything interlacism-related [01:08:14 CEST] <inter123> Is someone of the ffmpeg users around here? I really need some help, would really appreciate it... [01:09:10 CEST] <marcurling> inter123 on IRC just ask: Don't ask if you can ask [01:10:43 CEST] <inter123> I am trying to download through a link, while it works on my windows version, it doesn't work on my linux static version(ubuntu 16.04): here's a screenshot: [01:11:16 CEST] <inter123> https://i.imgur.com/6Zveobh.png [01:12:15 CEST] <inter123> So, I get the "HTTP error 403 Forbidden", whereas it works perfectly fine in my windows version [01:12:42 CEST] <inter123> Btw, I get the link from a kodi application(NBA League Pass) [01:19:49 CEST] <marcurling> inter123 Can you give your whole command line? I'll give it a try on my Mint with recent ffmpeg [01:20:52 CEST] <inter123> this is the whole command: [01:20:53 CEST] <inter123> ffmpeg -i "https://nlds291.cdnllnwnl.neulion.com/nlds/nba/okc/as/live/nlncp/okc_hd_600… [01:21:13 CEST] <inter123> but that link is already dead, so I will provide a new link: [01:22:11 CEST] <inter123> here's the command with a working link now: [01:23:23 CEST] <inter123> Actually, the link is too long to fit into the message, here's a pastebin link: https://pastebin.com/BH5vUtiP [01:32:45 CEST] <marcurling> got the same error with ffmpeg 3.2.3, installing 3.4 and trying but I'm not shure it comes from ffmpeg itself [01:35:51 CEST] <inter123> the links are only active for 1 minute tops, so I am afraid you tried too late already [01:37:42 CEST] <inter123> as you can see, it works on my windows version: [01:37:42 CEST] <inter123> https://i.imgur.com/qxZHpHq.png [01:38:44 CEST] <inter123> Here's the whole command, plus the message from ffmpeg(in my windows version): [01:38:45 CEST] <inter123> https://i.imgur.com/7HP6FqO.png [01:38:56 CEST] <inter123> https://i.imgur.com/kBbfksk.png [01:41:57 CEST] <marcurling> I was able to download a .ts file using the hhtps link but even mediainfo does not recognize it as a video file. [01:42:52 CEST] <marcurling> But what we should do is check the compile options of the Win and linux version [01:43:37 CEST] <inter123> How do I check the Win compile options? [01:44:03 CEST] <marcurling> just 'ffmpeg' in the command line [01:44:48 CEST] <inter123> win: https://i.imgur.com/ylTqhqw.png [01:45:17 CEST] <inter123> and about linux, I have this static build: https://www.johnvansickle.com/ffmpeg/ [01:47:22 CEST] <inter123> here's a screenshot for linux also: https://i.imgur.com/eyMOczz.png [01:47:37 CEST] <marcurling> make both outputs a text file (ffmpeg 2> ffmpeglinux.txt under linux) and compare with diff or any nice text editor (notepad++ can do it uner win) [01:48:01 CEST] <marcurling> Sorry but got to leave you: it is way late here [02:26:34 CEST] <jiffe> so I've ripped all my tv shows to disk, I'm looking for an automated way to find the intros and credits [02:27:29 CEST] <jiffe> I'm thinking something that will find sections of videos of N+ seconds which are exactly the same between them all [02:27:40 CEST] <jiffe> I don't know if something like that exists [02:30:26 CEST] <jiffe> I don't know if you can just create a hash of the last X frames to compare them or if the encoded content would still be slightly different [02:31:06 CEST] <DHE> not that easy. it would need to be a hash that can cope with encoding variants. the video won't be pixel identical each time [02:31:28 CEST] <DHE> you might do better with black detection and timing to identify the black screen between transitions [02:32:35 CEST] <jiffe> hmm I see [10:12:08 CEST] <rabbe> hey.. just got a better WHDL transmitter/receiver.. now my ffmpeg command which creates an rtmp for nginx produces too large speed, so that when i receive the (flv over) rtmp i get slow motion. what to do? should i paste the command here? [10:13:06 CEST] <teratorn> rabbe: it wont hurt [10:13:24 CEST] <rabbe> just a second.. it's on another puter [10:14:25 CEST] <JEEB> usually the thing is to paste the command and logging with your RTMP credentials hidden onto a pastebin-like site [10:14:28 CEST] <JEEB> and then link here [10:14:33 CEST] <JEEB> but uhh [10:14:38 CEST] <JEEB> so you have a faster-than-realtime input? [10:15:31 CEST] <rabbe> ffmpeg -r 30 -f v4l2 -video_size hd1080 -i /dev/video0 -c:a aac -ac 2 -b:a 128k -c:v libx264 -pix_fmt yuv420p -preset ultrafast -tune zerolatency -x264-params "nal-hrd=cbr" -b:v 3000k -minrate 3000k -maxrate 3000k -bufsize 3000k -g 60 -f flv rtmp://192.168.0.16/live/test [10:15:46 CEST] <rabbe> probably a crappy command :) [10:16:07 CEST] <rabbe> ah, sorry.. well, already pasted [10:16:18 CEST] <JEEB> well at least that isn't too long [10:16:37 CEST] <JEEB> and if that's supposed to be live then I can't see how it's going too fast [10:16:42 CEST] <JEEB> since that seems like live input [10:17:52 CEST] <rabbe> ffplay -fflags nobuffer gives me slow motion.. [10:18:20 CEST] <JEEB> are you sure your encoder is going fast enough :P [10:18:44 CEST] <JEEB> or many other things, also no idea what ffplay can f' up [10:19:14 CEST] <rabbe> now i get the stream from gorpro hero5 into capture card magewell HDMI->USB3 [10:19:29 CEST] <JEEB> for RTMP reference flash is unfortunately the reference :P [10:19:43 CEST] <rabbe> this worked fine with the cheaper WHDL transmitter/receiver [10:20:04 CEST] <furq> when you say "slow motion" do you mean like exactly half speed [10:20:05 CEST] <JEEB> anyways, just read the log and try with -v verbose f.ex. [10:20:19 CEST] <furq> or just choppy or something [10:20:25 CEST] <rabbe> in ffmpeg side or ffplay side? [10:20:31 CEST] <JEEB> ffmpeg [10:20:46 CEST] <JEEB> and start capturing the log with 2> ffmpeg_log.txt or so [10:21:05 CEST] <furq> also does it play back correctly if you write to a file [10:21:13 CEST] <JEEB> yea [10:21:28 CEST] <JEEB> you can just write FLV locally and try playing that [10:21:37 CEST] <rabbe> will check [10:21:39 CEST] <JEEB> with mpv for example (although that does use the same lavf library) [10:21:49 CEST] <furq> if it is exactly half speed then maybe the camera isn't playing nice with v4l and sending 60fps [10:21:53 CEST] <JEEB> if you want a "reference" play then you have to grab a flash-based player :P [10:22:02 CEST] <furq> that's my only guess based on that command [10:22:10 CEST] <JEEB> could be [10:22:21 CEST] <JEEB> although slow speed should desync [10:23:06 CEST] <furq> yeah i'm not going to say it's a good guess [10:23:53 CEST] <rabbe> ah, setting -r 60 instead gives me speed 1 [10:24:08 CEST] <furq> nice [10:24:44 CEST] <furq> maybe it was a good guess after all [10:25:11 CEST] <rabbe> i wonder if setting -r higher than 60 will show me the future :) [10:25:23 CEST] <rabbe> thanx [10:25:35 CEST] <furq> you can set -r 30 after -i if you want to drop alternate frames [10:26:01 CEST] <rabbe> alternate frames? [10:26:28 CEST] <furq> if you want a 30fps output from a 60fps input [10:26:35 CEST] <furq> which you probably do at that bitrate [10:26:36 CEST] <rabbe> ah, okay [10:27:10 CEST] <rabbe> but i keep the -r 60 to get the stream input ok [10:27:17 CEST] <furq> yeah [10:27:32 CEST] <furq> -framerate 60 or -r 60 before -i, -r 30 after [10:28:18 CEST] <rabbe> yeah, because we had robot functionality running on the same computer which lagged so we figured ffmpeg was hogging too much CPU [10:28:32 CEST] <rabbe> we had 5000 instead of 3000 [10:28:56 CEST] <rabbe> does it make sense to change all of those 5000 to 3000? [10:29:26 CEST] <rabbe> bufsize + all bitrate parameters [10:30:03 CEST] <furq> depends how much bandwidth you've got really [10:30:10 CEST] <furq> with those settings you probably want it as high as you can get away with [10:31:51 CEST] <rabbe> i'm planning on using uv4l instead so i won't need to specify this.. but what kinda settings would give me better quality? [10:32:12 CEST] <rabbe> at the same bandwidth? [10:33:21 CEST] <furq> if you actually need preset ultrafast and tune zerolatency then there's not really much you can do [10:33:32 CEST] <furq> those two disable pretty much everything good [10:34:16 CEST] <rabbe> ah, okay.. [10:34:37 CEST] <furq> i'm not sure if you actually need ultrafast to reduce latency, so maybe try stepping that up if you have the cpu time [10:34:52 CEST] <rabbe> does these settings specify a specific h264 baseline also? [10:35:02 CEST] <rabbe> i mean, baseline main etc [10:35:16 CEST] <rabbe> okay.. [10:35:21 CEST] <JEEB> those are profiles, x264 sets it according to your settings' features used [10:35:22 CEST] <furq> not explicitly but i'm pretty sure that'll be baseline [10:35:23 CEST] <JEEB> and other things [10:35:49 CEST] <JEEB> profiles = features required from decoder, levels = amount of memory required from decoder [10:36:05 CEST] <furq> i'm guessing you need zerolatency and fastdecode, in which case you've got no bframes or cabac [10:36:12 CEST] <furq> so tuning anything else is probably a waste of time [10:36:21 CEST] <furq> it's not something i've ever messed with though [10:36:23 CEST] <JEEB> CABAC already would be a nice thing [10:36:28 CEST] <furq> yeah [10:36:40 CEST] <rabbe> -preset fastdecode? [10:36:44 CEST] <furq> tune [10:36:48 CEST] <furq> you can have multiple tunes [10:36:52 CEST] <JEEB> well it's pretty much already set :P [10:36:53 CEST] <rabbe> ah [10:36:55 CEST] <JEEB> because of ultrafast [10:36:59 CEST] <furq> yeah [10:37:00 CEST] <JEEB> CABAC is not used etc [10:37:11 CEST] <JEEB> do you really need ultrafast? [10:37:18 CEST] <JEEB> that really cripples compression [10:37:21 CEST] <rabbe> not sure [10:37:23 CEST] <JEEB> it's really made for >200fps+ [10:37:27 CEST] <rabbe> oh [10:37:30 CEST] <JEEB> on any relatively sane thing [10:37:47 CEST] <furq> i'm not sure if fastdecode actually helps with latency [10:37:49 CEST] <rabbe> no, i think the quality is a bit bad [10:37:49 CEST] <JEEB> of course it depends how powerless your thing is, and if you've found a binary that's somehow compiled without hand-writtem SIMD enabled [10:37:53 CEST] <JEEB> furq: it doesn't [10:37:55 CEST] <furq> or if it's just there for toasters [10:38:00 CEST] <JEEB> it's just for toasters [10:38:10 CEST] <JEEB> zerolatency does the things that help latency (disables lookaheads, b-frames etc) [10:38:27 CEST] <JEEB> ultrafast is for "I need faster and don't care about anything else" [10:38:36 CEST] <furq> good to know [10:38:42 CEST] <Archer> hey [10:38:54 CEST] <furq> well yeah if the encoding box can deal with cabac then you definitely want that on [10:38:59 CEST] <furq> try -preset superfast [10:39:41 CEST] <rabbe> ok [10:39:55 CEST] <Guest51818> I wanted to see if there was a way to search video for a specific color using ffmpeg. I'm trying to get the times of kills in multiple hours of PUBG footage and it always displays reddish-orange text whenever there is a kill [10:40:17 CEST] <Guest51818> I'd like to not manually go through the videos [10:42:08 CEST] <hendry> given a m3u8 URL, is there a tool to download the manifest and the referenced .ts? I feel youtube-dl should do it, but it seems to assemble all the segments, which I don't want. [10:42:55 CEST] <furq> Guest51818: there's no simple way [10:43:01 CEST] <furq> maybe you could do it with crop and signalstats [10:44:11 CEST] <furq> hendry: maybe youtube-dl --keep-fragments [10:44:23 CEST] <furq> afaik that'll still assemble but it'll keep the fragments after it's done [10:44:45 CEST] <furq> there's probably another option somewhere that'll prevent the final muxing [10:46:03 CEST] <furq> failing that, grep and curl [10:46:05 CEST] <furq> bye [10:46:13 CEST] <Guest51818> huh okay gonna have to read up on that [10:46:21 CEST] <furq> !filter signalstats @Guest51818 [10:46:21 CEST] <nfobot> Guest51818: http://ffmpeg.org/ffmpeg-filters.html#signalstats-1 [10:46:24 CEST] <Guest51818> spin up a linux VM too [10:47:09 CEST] <Guest51818> probably run it across a kill clip and see how the numbers differ from normal non-kill footage [10:47:20 CEST] <furq> basically crop to the area where the hud message appears, run signalstats and look for frames with HUEAVG in a certain range [10:47:41 CEST] <furq> you should be able to script that once you know what to look for [10:48:07 CEST] <Guest51818> thanks man you just saved me hours of document reading, easy [10:53:13 CEST] <Guest51818> hah there is a Windows x64 build, hurrah for not having to go to a linux VM [12:02:24 CEST] <Guest51818> okay ive got the ffplay command with the crop on the kill essage [12:02:29 CEST] <Guest51818> *message [12:39:58 CEST] <Guest51818> hey furq you were bang on, HUEAVG is spiking at 250 on killmsg in cropped area [12:41:05 CEST] <Guest51818> can probably get something up with gnuplot [12:41:10 CEST] <Guest51818> or Excel [20:23:05 CEST] <lagzilla> is it possible to pipe a merged audio stream? ffmpeg -i input1.wav -i input2.wav -filter_complex "[0:a][1:a]amerge=inputs=2,pan=stereo|c0<c0+c1|c1<c2+c3[aout]" -map "[aout]" - | ffplay [20:23:09 CEST] <lagzilla> isn't working for me [20:28:09 CEST] <ChocolateArmpits> lagzilla, well there's no format specified [20:28:34 CEST] <ChocolateArmpits> and I think ffplay needs a "-" for pipe input too [20:32:38 CEST] <lagzilla> how would I set the format? I can't find any example [20:32:48 CEST] Action: lagzilla sucks at google [20:34:33 CEST] <relaxed> lagzilla: -f wav [20:34:41 CEST] <DHE> you choose based on the content type, but it should be something that can be streamed [20:34:58 CEST] <DHE> being audio, yeah wav is probably a good start [20:35:09 CEST] <lagzilla> thanks! [23:40:25 CEST] <durka42> Hi, I have a question about -progress. The man page says "-progress url (global) Send program-friendly progress information to url." But what's a URL in this context? Can I have it use a named pipe or unix socket etc, with some syntax? [23:44:52 CEST] <c_14> yep [23:45:12 CEST] <c_14> any file or url that ffmpeg knows how to open and write to [23:45:33 CEST] <durka42> ok, so just mkfifo and give the filename [23:46:49 CEST] <c_14> ye [00:00:00 CEST] --- Tue Oct 24 2017

1 0

ffmpeg-devel.log.20171022
by burek 23 Oct '17

23 Oct '17

[00:01:58 CEST] <atomnuker> so like the old vdpau stuff wm4 was complaining about? [00:02:58 CEST] <durandal_1707> im depressed why nobody picks prores removal thing [00:03:55 CEST] <jamrial> atomnuker: afaik, that stuff is currently disabled since the bump [00:06:02 CEST] <atomnuker> I don't know what that stuff is but would be nice if someone like jkqxz submits a patch to remove them [00:06:16 CEST] <atomnuker> durandal_1707: what was the issue again? [00:07:26 CEST] <jkqxz> What do you want me to remove? [00:07:49 CEST] <atomnuker> the old vdpau stuff (the one which doesn't use the hwcontext IIRC) [00:07:50 CEST] <durandal_1707> atomnuker: removal of dupe decoder at least [00:08:33 CEST] <jamrial> atomnuker: i assume the removal FF_API commit for vdpau is in the merge queue [00:08:37 CEST] <jamrial> but i didn't check [00:08:40 CEST] <jamrial> it's dead code anyway [00:13:56 CEST] <atomnuker> I wasn't sure if it was behind FF_API defines [00:14:29 CEST] <atomnuker> durandal_1707: ask around for which one is better and submit a patch [00:15:15 CEST] <jamrial> atomnuker: maybe there are parts that aren't, i can't say [00:15:20 CEST] <jamrial> i just know some parts are [00:16:52 CEST] <jamrial> durandal_1707: with prores the problem wasn't that nobody had made tests to know which one was faster/better? [00:17:10 CEST] <jamrial> did anyone ever sent a patch to remove the worse of the two? [00:21:33 CEST] <durandal_1707> they are same performance wise [00:22:21 CEST] <durandal_1707> just one have better code, more user friendly [00:23:17 CEST] <jamrial> send a patch then [00:23:44 CEST] <durandal_1707> no [00:24:07 CEST] <durandal_1707> im busy with re [00:40:08 CEST] <jamrial> michaelni: regarding setdar, it used to give this warning: "[Parsed_setdar_0 @ 00000000026ca9c0] num:den syntax is deprecated, please use num/den or named options instead" [00:40:16 CEST] <jamrial> using num/den gives the expected result [00:40:50 CEST] <durandal_1707> ahh, thats it, warning is gone [00:42:04 CEST] <jamrial> warning and behavior are both gone, yes [01:32:40 CEST] <kierank> durandal_1707: over christmas I plan to rip out mpeg4video from mpegvideoencctx [01:32:43 CEST] <kierank> and add 10-bit idct [01:33:05 CEST] <JEEB> nice [01:33:43 CEST] <kierank> afaik adding 10-bit to mpegvideo.c is impossible [01:34:14 CEST] <JEEB> kierank: btw just saw your talk @ demuxed. quite a nice primer into how video over IP is done for those use cases [01:36:03 CEST] <kierank> JEEB: thanks [01:36:06 CEST] <kierank> i don't dare watch it [01:38:14 CEST] <kierank> lots of people have emailed me about it which is unusual for a conference [01:50:55 CEST] <michaelni> jamrial, about vis, codecview does not replace it, i mistakely tested with a version prior the bump [01:52:52 CEST] <jamrial> michaelni: i can't do anything about it [01:52:56 CEST] <jamrial> michaelni: either see with ubitux if you can fix it within a month or suggest postponing the API until the next bump to have time to come up with an useful replacement [01:54:07 CEST] <michaelni> jamrial, i have no interrest in replacing APIs just to replace them [01:55:47 CEST] <michaelni> there are 2 things one is vissuaizing mvs that has been moved to codecview [01:56:25 CEST] <michaelni> the 2nd is vissualizing mb types and maybe other things [01:56:32 CEST] <michaelni> the bump removed both [01:56:58 CEST] <michaelni> we can remove what has been move to codecview [01:57:07 CEST] <michaelni> moveD [02:03:04 CEST] <michaelni> jamrial, ill see what need to be postponed for this and will post a patch [03:09:15 CEST] <cone-255> ffmpeg 03James Almer 07master:d4d2e9fe4e1e: avformat: Drop deprecated feof() AVIO fuction [03:48:00 CEST] <cone-255> ffmpeg 03James Almer 07master:32e18dbfe8e4: Revert efb79cabb2 and 75bd215727 [03:55:34 CEST] <cone-255> ffmpeg 03Vittorio Giovara 07master:0337adfab5d1: lavc: Drop deprecated missing sample log function [03:55:35 CEST] <cone-255> ffmpeg 03James Almer 07master:24a8603a8e0f: Merge commit '0337adfab5d14a17bf4d5060aa0425e4049a9862' [04:25:26 CEST] <cone-255> ffmpeg 03James Almer 07master:8f483108b503: avcodec: Drop deprecated audio resample API [04:25:27 CEST] <cone-255> ffmpeg 03James Almer 07master:43befa68263b: avcodec: Drop deprecated audio convert API [04:27:56 CEST] <cone-255> ffmpeg 03Vittorio Giovara 07master:b748c280e59c: lavc: Drop deprecated lowres option [04:27:57 CEST] <cone-255> ffmpeg 03James Almer 07master:b48ed0040360: Merge commit 'b748c280e59cac468ed36cbbe5e71d5ebd434020' [04:42:00 CEST] <cone-255> ffmpeg 03Vittorio Giovara 07master:7b9170411848: lavc: Drop deprecated VDPAU codec capability [04:42:02 CEST] <cone-255> ffmpeg 03James Almer 07master:c68a3ab96ec0: Merge commit '7b917041184874e7d7cba4450813de7e0bb28a33' [04:49:41 CEST] <cone-255> ffmpeg 03Vittorio Giovara 07master:5c1585c4c3b5: lavc: Drop deprecated VDPAU buffer fields [04:49:42 CEST] <cone-255> ffmpeg 03James Almer 07master:17487f11bb68: Merge commit '5c1585c4c3b5281835d784c5daef0069915ccd57' [04:56:10 CEST] <cone-255> ffmpeg 03James Almer 07master:5ad1a989b67d: avcodec: Drop deprecated VIMA codecid [04:58:06 CEST] <cone-255> ffmpeg 03Vittorio Giovara 07master:1146bb3babca: lavc: Drop deprecated voxware codec entry [04:58:07 CEST] <cone-255> ffmpeg 03James Almer 07master:898349d70206: Merge commit '1146bb3babca3973e88005d267cd06210d6ac075' [05:01:42 CEST] <cone-255> ffmpeg 03Vittorio Giovara 07master:6dca24cd1d57: lavc: Drop deprecated way of setting codec dimensions [05:01:43 CEST] <cone-255> ffmpeg 03James Almer 07master:90000f15ec41: Merge commit '6dca24cd1d570b806b5a3fdaef9d3c8608942a81' [05:31:05 CEST] <cone-255> ffmpeg 03James Almer 07master:417d473bde22: avcodec: remove ABI portion of the side data merging API [05:37:00 CEST] <cone-255> ffmpeg 03James Almer 07master:657ce888e852: postproc: Drop deprecated qp typedef [05:45:31 CEST] <cone-255> ffmpeg 03James Almer 07master:382aaa3312a5: avutil/crc: remove gap in AVCRCId enum values [06:30:23 CEST] <cone-255> ffmpeg 03James Almer 07master:ca4df37f06f8: avformat: remove ABI portion of the side data merging API [06:37:01 CEST] <cone-255> ffmpeg 03James Almer 07master:b89081e01be7: avformat: remove dead av_stream_get_side_data() cruft [15:14:28 CEST] <cone-753> ffmpeg 03James Almer 07master:72c3d9ae4528: avcodec/libavcodec.v: remove obsolete exports [15:35:06 CEST] <BtbN> Damn, getting proper subtitles in a Browser is hard work [15:35:16 CEST] <BtbN> turns out the best way is to compile libass via emscripten. [15:35:22 CEST] <BtbN> WebVTT is a bad joke [17:16:44 CEST] <RiCON> jamrial: could you confirm if -lgomp is added somewhere when libsoxr is used as external lib? [17:28:32 CEST] <nevcairiel> why would libsoxr use gomp [17:28:56 CEST] <nevcairiel> i guess for its MT thing which i rather stay away from [17:34:11 CEST] <RiCON> i guess you can just disable it to prevent issues [17:42:29 CEST] <JEEB> if it writes it into its own pc file then adding a pkgconfig check should be simple [17:44:56 CEST] <RiCON> it does have a .pc, but isn't created/install in windows/mingw unless you patch cmakelists.txt [17:45:54 CEST] <JEEB> kek [17:48:12 CEST] <RiCON> and even then, it doesn't include optional libs like openmp [17:48:36 CEST] <JEEB> even in Libs.private? [17:49:42 CEST] <RiCON> nowhere: https://notabug.org/RiCON/soxr/src/master/src/soxr.pc.in [17:49:57 CEST] <JEEB> (Ž4@) [17:53:29 CEST] <nevcairiel> many projects seriously cheap out on pc files [17:55:05 CEST] <JEEB> and with shared libraries it even tends to work [17:57:51 CEST] <nevcairiel> which is how most linux distros distribute and link stuff anyway [18:02:44 CEST] <jamrial> arch almost doesn't distribute static libraries [23:41:57 CEST] <cone-518> ffmpeg 03Carl Eugen Hoyos 07master:06899863a82c: lavc/bitstream_filter: Make a cast explicit. [00:00:00 CEST] --- Mon Oct 23 2017

1 0

ffmpeg.log.20171022
by burek 23 Oct '17

23 Oct '17

[07:48:18 CEST] <Srini> hello i am looking for downloading the dash live segments [07:49:30 CEST] <Srini> and when i run the ffmpeg command it downloads one recent segment and quits, is there any way i can continue to download the segments the way it is done in hls m3u8? [07:52:03 CEST] <Srini> i am using the base url in my ffmpeg command [08:16:03 CEST] <Srini> DHE: ^^ [10:48:40 CEST] <johnny_|_> Hi. I am using ffmpeg.js. Is it possible to input live stream (h.264) and get transcoded (vp8) stream on the output? [11:43:26 CEST] <blap> it's 2017 and we don't have auto voice translation of movies yet [14:42:43 CEST] <Pandela> Has anyone had any luck with piped svg sequences? 3.4 says it has an svg_pipe format now, but piping in svg's just makes ffplay/ffmpeg hang [15:31:12 CEST] <Gaulois94> Hello [15:31:56 CEST] <Gaulois94> I have few question about ffmpeg and RTP video stream. I am reading a .sdp file using ffmpeg in C/C++, and my question is about reading : how do you manage to handle the time synchronization ? [15:32:58 CEST] <Gaulois94> WIll av_read_frame be in pause while there is no images ? [15:34:02 CEST] <DHE> av_read_frame may block on network activity, but as long as sufficient data is available it will return the next AVPacket to you [15:34:19 CEST] <DHE> the ffmpeg CLI tool uses all these same APIs [15:34:43 CEST] <Gaulois94> Ok, I don't have in the client size handle the time synchronization, av_read_frame does it for me [15:34:59 CEST] <Gaulois94> have to* [15:36:16 CEST] <DHE> no it doesn't. if you're using the network, you're just experiencing the flow of data from the remote side [15:36:32 CEST] <jamesl> I'm trying to stream the output of a uv4l webcam (/dev/video0) to Twitch.tv . I am using this command: https://pastebin.com/raw/TciAbst1 and it sends packets successfully, but the Twitch.tv stream is offline. What is causing this? [15:36:56 CEST] <Gaulois94> Ok, that is good enough for me [15:37:16 CEST] <Gaulois94> (I do the synchronization in the remote side), thank you [15:37:32 CEST] <DHE> unless the network is highly trusted (ie. local LAN) that's still not considered good enough [15:37:43 CEST] <DHE> there should be at least some buffering on the client side [15:38:32 CEST] <Gaulois94> It is indeed in local LAN [15:39:26 CEST] <jamesl> When I change the stream key it goes from "offline" to "authentication failed" so I know the twitch URL and stream key are correct [15:39:45 CEST] <jamesl> https://trac.ffmpeg.org/wiki/StreamingGuide I followed this but it's for x11grab, not v4l [16:25:30 CEST] <JnvSor> Is there a way to set which audio/subtitle track is default? I can do it with -map and remapping all the tracks, but some files have upwards of 20 streams and then I have to map them all individually... I'd rather just say "Mark this stream as default" [16:26:53 CEST] <JEEB> if it's the actual selection that you're not OK with then I think map is the only way to do it with ffmpeg.c, which goes into manual mode and thus requires you to map everything you need [16:27:03 CEST] <JEEB> because tehre is a separate metadata of "default track" in some containers :P [16:27:15 CEST] <JEEB> which you might have also been meaning [16:27:21 CEST] <JEEB> "I want X to be the default one in the output" [16:28:06 CEST] <JnvSor> Yeah that's what I mean. Does mkv container have a way to mark a stream as default for output? [16:29:41 CEST] <JEEB> there's a default flag yes [16:29:53 CEST] <JEEB> no idea how you set it in ffmpeg.c [16:29:55 CEST] <JEEB> vOv [16:31:42 CEST] <JEEB> ok, it was in the examples for the disposition parameter [16:31:45 CEST] <JEEB> "-disposition:a:1 default" [16:31:55 CEST] <JEEB> would set disposition for the second audio stream to 'default' [16:32:26 CEST] <JEEB> see https://www.ffmpeg.org/ffmpeg-all.html [16:37:38 CEST] <jamesl> I'm trying to stream the output of a uv4l webcam (/dev/video0) to Twitch.tv . I am using this command: https://pastebin.com/raw/TciAbst1 and it sends packets successfully, but the Twitch.tv stream is offline. What is causing this? [16:42:58 CEST] <JnvSor> I read that and it didn't work... Just realized I have ffmpeg pointing to a custom build I set up years ago... Yay... Stupid me, never mind :/ [17:11:07 CEST] <beastd> JnvSor,JEEB: I think setting default is not really controlable via ffmpeg. I switched to using mkvmerge for the task of marking the default track. [17:12:45 CEST] <beastd> Because unfortunately it wasn't trivial to add functionality to ffmpeg. Some time has passed and I forget the details... Though I think i can at least dig out the mkgmerge syntax I used... [17:23:48 CEST] <jamesl> Why would a ffmpeg command work with x11grab but not with a uv4l webcam? Here's the command: https://pastebin.com/raw/TciAbst1 [17:26:05 CEST] <JnvSor> beastd: Worked for me, just needed to mark the first track disposition none as well [17:27:31 CEST] <beastd> JnvSor: Ah ok. That is great to hear. I don't know why it didn't work for me back then... [17:39:24 CEST] <furq> beastd: i'm pretty sure that didn't work until relatively recently [18:47:51 CEST] <srini> logger url [19:12:28 CEST] <jamesl> Why would a ffmpeg command work with x11grab but not with a uv4l webcam? Here's the command: https://pastebin.com/raw/TciAbst1 [19:14:12 CEST] <c_14> what's the error? [19:18:18 CEST] <jamesl> c_14: the stream appears to be blank [19:18:35 CEST] <jamesl> the stream to Twitch works when it used x11grab [19:19:13 CEST] <c_14> are you sure that v4l2 source input is working? [19:19:27 CEST] <jamesl> yeah, I recorded it to a file [19:19:31 CEST] <jamesl> the webcam works [19:19:32 CEST] <c_14> and that works? [19:19:57 CEST] <c_14> maybe the framerate/gop size isn't stable [19:20:06 CEST] <c_14> or the bitrate is wrong [19:20:14 CEST] <c_14> twitch has a bunch of things it cares about [19:20:50 CEST] <jamesl> the bitrate is 95.4 kbit/s and is reasonably stable [19:23:22 CEST] <BtbN> streaming something that low to Twitch might just not be supported [21:42:10 CEST] <Gaulois94> Hi, do you know why sws_getContext send the signal "abort" ? It stopped if my debugger is correct at sws_setColorspaceDetails [21:43:07 CEST] <Gaulois94> Or maybe I am stupid and I didn't checked if my codec was correct [22:01:00 CEST] <dystopia_> is there someway to convert latm aac headers to adts without re encoding the file [22:45:15 CEST] <DHE> dystopia_: if there is, it'll be a bitstream filter (ffmpeg -bsfs) [22:46:43 CEST] <furq> there's an adts to asc bsf, but i don't see the inverse [22:47:34 CEST] <furq> actually nvm i guess latm is something different [22:48:46 CEST] <furq> dystopia_: there's a -latm 1 switch, so i guess -c copy out.aac with no -latm set will do it? [22:48:56 CEST] <furq> not checked though [23:01:09 CEST] <long-klong> hello ! [23:01:24 CEST] <long-klong> I am a student who is working on a super resolution algorithm [23:01:43 CEST] <long-klong> and I am fidgeting around with the motion estimation part [23:02:10 CEST] <JEEB> you might want to talk to hanna I guess? [23:02:19 CEST] <long-klong> is familiar with the following papers ? [23:02:59 CEST] <hanna> I'm not that familiar with the subject either [23:03:05 CEST] <hanna> but I'd be interested in implementing this sort of thing in GLSL [23:03:26 CEST] <JEEB> that's mostly why I noted, since CPU implementations tend to be zomg zufall slow [23:03:59 CEST] <long-klong> https://www.researchgate.net/profile/Horst_Bischof/publication/248964741_A_… [23:04:35 CEST] <long-klong> https://vision.in.tum.de/_media/spezial/bib/mitzel_et_al_dagm09.pdf [23:04:49 CEST] <blap> i approve of this nick [23:05:21 CEST] <long-klong> http://www.caam.rice.edu/~zhang/caam699/opt-flow/horn81.pdf [23:05:25 CEST] <long-klong> these are the papers [23:06:48 CEST] <long-klong> so if there is someone who can help me with the optical flow.. I will be grateful [23:07:12 CEST] <JEEB> oh, I thought you had something kind of working :D [23:08:08 CEST] <hanna> I've never looked at optical flow [23:08:15 CEST] <hanna> The only methods I'm familiar with are block estimation and convolution [23:08:40 CEST] <hanna> doesn't optical flow have issues due to lack of training data and occlusion etc.? [23:10:50 CEST] <long-klong> I do not know why I got signed out from the network [23:10:54 CEST] <long-klong> I am still here [23:12:13 CEST] <JEEB> http://up-cat.net/p/bb86140d [23:12:15 CEST] <JEEB> long-klong: ^ [23:13:14 CEST] <long-klong> thank you JEEB [23:13:16 CEST] <long-klong> ! [23:13:18 CEST] <long-klong> mised that part [23:13:28 CEST] <long-klong> I do not know [23:13:35 CEST] <long-klong> I am just a sstudent hanna [23:13:45 CEST] <long-klong> can you elaborate please on what you know ? [23:13:58 CEST] <hanna> I don't know much more [23:14:01 CEST] <hanna> I am also just a student [23:14:06 CEST] <long-klong> I read something related to occlusion [23:15:12 CEST] <long-klong> did you do convolution of images or signals and systems stuf ? [23:35:00 CEST] <hanna> I read a paper about doing motion estimation using convolutional neural networks [23:35:20 CEST] <hanna> which handles occlusion very well and doesn't have any issues with training data [23:35:26 CEST] <hanna> but it's too slow for realtime [23:35:44 CEST] <long-klong> hmm... cool [23:36:40 CEST] <long-klong> I am interested in copmputer vision at the moment...maybe later in Artificial intelligence (PhD ?) . [23:37:29 CEST] <long-klong> I am an electronics and telecommunications student that wants to do an image processing algorithm for his bachelor thesis , implemented on an FPGA [23:37:39 CEST] <long-klong> :) [23:38:07 CEST] <long-klong> I am going to die probably in the next 6 months [23:38:09 CEST] <long-klong> lol [23:43:37 CEST] <long-klong> hey hanna ... what was block estimation ? [23:44:06 CEST] <hanna> long-klong: block estimation is what MVTools, SVP etc. do [23:44:16 CEST] <hanna> basically block motion search (like what encoders do) [23:44:24 CEST] <hanna> + algorithms to do pixel reflowing based on the motion vectors [23:47:25 CEST] <thebombzen> hanna: how is that better than like [23:47:30 CEST] <thebombzen> exhaustive searching [23:47:50 CEST] <hanna> exhaustive search is an example of a block motion search strategy [23:48:09 CEST] <thebombzen> oh you mean this doesn't use MBs to estimate motion vectors [23:48:17 CEST] <thebombzen> sounds cool [23:59:21 CEST] <hanna> MBs? [00:00:00 CEST] --- Mon Oct 23 2017

1 0

ffmpeg-devel.log.20171021
by burek 22 Oct '17

22 Oct '17

[00:00:22 CEST] <durandal_1707> what a price? [00:01:47 CEST] <JEEB> ok, no - it seems like they added i7-8550U [00:01:55 CEST] <JEEB> to the available CPUs for the 13 [00:02:15 CEST] <durandal_1707> pricing? [00:03:29 CEST] <JEEB> https://www.computeruniverse.net/en/products/90707596/dell-xps-13-9360-9986… [00:03:35 CEST] <JEEB> in the EU around that price I guess [00:03:43 CEST] <JEEB> (that's with 16GiB of RAM and 512GiB SSD) [00:03:51 CEST] <JEEB> wait what [00:03:56 CEST] <JEEB> that's with HD screen?! [00:03:59 CEST] <JEEB> blasphemy [00:04:49 CEST] <durandal_1707> because of SSD [00:05:57 CEST] <atomnuker> I'm glad I bought my xps 15 back in january of last year, I got a good deal for a 4k + 16gb of ram + the 8 core cpu + 1 tb hdd [00:06:24 CEST] <JEEB> 8 core? [00:06:31 CEST] <atomnuker> 4 core, 8 cpu [00:06:31 CEST] <JEEB> or do you mean 4+HT [00:06:36 CEST] <JEEB> right [00:07:27 CEST] <JEEB> https://www.computeruniverse.net/en/products/90707598/dell-xps-13-9360r-002… [00:07:31 CEST] <jkqxz> Pre-brexit pricing ftw? [00:07:32 CEST] <JEEB> ok, this one is the 3200x1800 one [00:11:30 CEST] <JEEB> hmm, what's this HP Spectre 13 thing? [00:39:31 CEST] <cone-302> ffmpeg 03Anton Khirnov 07master:b76f6a76c631: h264dec: initialize field_started to 0 on each decode call [00:39:32 CEST] <cone-302> ffmpeg 03Anton Khirnov 07master:83b2b34d06e7: h2645_parse: use the bytestream2 API for packet splitting [00:39:33 CEST] <cone-302> ffmpeg 03James Almer 07master:f898df60bca3: Merge commit 'b76f6a76c6312dc551d7c37c6ded36bea7973c74' [00:39:34 CEST] <cone-302> ffmpeg 03James Almer 07master:07cf202614a8: Merge commit '83b2b34d06e74cc8775ba3d833f9782505e17539' [02:05:13 CEST] <atomnuker> jamrial: does the v2 of that side data buf patch look okay? [02:08:52 CEST] <atomnuker> michaelni: does the opus decoder have any unfixed integer overflows? [02:13:58 CEST] <jamrial> atomnuker: if it keeps the frame and user provided buffer intact on failure, then yes [02:14:23 CEST] <jamrial> i still think it should use data array like we do with packet and stream side data, though [02:14:57 CEST] <jamrial> and not an user allocated avbufferref, which in most use cases for this function will have to be allocated specifically for it [02:24:42 CEST] <michaelni> atomnuker, iam not conciously aware of any [02:25:39 CEST] <atomnuker> I guess they have been fixed then, opus released an update to the rfc (8251) [02:25:56 CEST] <atomnuker> which fixes a few of those to the original reference implementation [02:27:31 CEST] <atomnuker> but I couldn't find any code we'd need to update here, we don't use a silk resampler, the decoder's float only and we reinit properly on channel change [02:36:00 CEST] <cone-302> ffmpeg 03Michael Bradshaw 07master:279dc407163e: lavc: drop support for OpenJPEG 1.3-2.0 [03:50:02 CEST] <cone-302> ffmpeg 03Dale Curtis 07master:a5fd8aa45b11: avformat/mov: Set start_pad correctly in mov_fix_index() [04:13:36 CEST] <jamrial> jkqxz: https://pastebin.com/eAWvrTTu https://0x0.st/srQ4.h264 [11:38:08 CEST] <ubitux> https://twitter.com/johnregehr/status/920691341738123264 [11:38:14 CEST] <ubitux> that's a nice way of deprecating an API [11:38:32 CEST] <nevcairiel> just make it slow [15:00:10 CEST] <jamrial> michaelni: what do you think of libav commit 522d850e68? [15:00:35 CEST] <JEEB> anyone else noted regressions in seeking/files ending with http://git.videolan.org/?p=ffmpeg.git;a=commit;h=858db4b01fa2b55ee55056c033… ? [15:00:46 CEST] <jamrial> it applies, but i can't reproduce the invalid reads with the sample from the ticket mentioned in it [15:02:32 CEST] <jamrial> JEEB: what kind of regressions? eof never being signaled? [15:03:09 CEST] <JEEB> seeking never finishing and being in a loop within lavf and then EOF never gotten [15:04:00 CEST] <jamrial> sounds like the kind of regressions that were reported with previous versions of the patch [15:04:30 CEST] <JEEB> I posted on the ML a log from a user who had just built latest FFmpeg+mpv. it could of course be mpv's API usage but if such internal semantics change has an effect on the API clients then that's not good, either :/ [15:05:57 CEST] <JEEB> I mean, the idea of the change in general is valid (you can get zero byte packets from a network protocol), but it seems like some other parts didn't work completely well with the semantics change [15:52:58 CEST] <michaelni> jamrial, if theres an issue it should be fixed by enlarging the scantable (as its faster) or maybe you can even drop the if/else and use vlcs that are never returning a out of range value. Id say the FFMIN is wrong in all cases, it should be a error return if a check is added not silently continuing [16:06:02 CEST] <jamrial> michaelni: i'll skip it then. if you think there's something to fix or change in it then feel free to [16:06:05 CEST] <jamrial> I'm not familiar enough with this code to make such changes myself [16:22:11 CEST] <michaelni> jamrial, i think the mb_padding stuff we have makes it unneeded but we can possibly improve it beyond what we have [17:27:03 CEST] <cone-583> ffmpeg 03Anton Khirnov 07master:522d850e68ec: h264_cavlc: check the value of run_before [17:27:03 CEST] <cone-583> ffmpeg 03Diego Biurrun 07master:994c4bc10751: x86util: Port all macros to cpuflags [17:27:03 CEST] <cone-583> ffmpeg 03James Almer 07master:ede5ddb58683: Merge commit '522d850e68ec4b77d3477b3c8f55b1ba00a9d69a' [17:27:03 CEST] <cone-583> ffmpeg 03James Almer 07master:2904db90458a: Merge commit '994c4bc10751e39c7ed9f67ffd0c0dea5223daf2' [17:39:26 CEST] <cone-583> ffmpeg 03Diego Biurrun 07master:307eb1a8ee36: x86: vp8dsp: port FILTER_BILINEAR macro to cpuflags [17:39:27 CEST] <cone-583> ffmpeg 03James Almer 07master:53eea3a5693a: Merge commit '307eb1a8ee363db1fcf869e427a8deb6d9538881' [17:41:32 CEST] <JEEB> lol, seems like latest ubuntu comes with a opencv version that doesn't work with our C code since they're actively breaking the C API [17:41:36 CEST] <JEEB> https://github.com/opencv/opencv/issues/8438 [17:43:02 CEST] <cone-583> ffmpeg 03Diego Biurrun 07master:e9bb77fb1012: x86: h264: Simplify DEQUANT macro with cpuflags [17:43:03 CEST] <cone-583> ffmpeg 03James Almer 07master:11f5ffd33005: Merge commit 'e9bb77fb1012cba1951a82136df7071f71bce8fb' [17:49:51 CEST] <cone-583> ffmpeg 03Diego Biurrun 07master:681a86aba6cb: x86: fft: Port to cpuflags [17:49:52 CEST] <cone-583> ffmpeg 03James Almer 07master:b7c16a3f2c49: Merge commit '681a86aba6cb09b98ad716d986182060c7795d20' [17:51:59 CEST] <cone-583> ffmpeg 03Luca Barbato 07master:0d8013b88b1c: configure: Replace -no_weak_symbols with -Werror=partial-availability [17:52:00 CEST] <cone-583> ffmpeg 03James Almer 07master:13c84b077ace: Merge commit '0d8013b88b1cb7d65da891a8819d3beebafb9bb5' [18:23:45 CEST] <cone-583> ffmpeg 03James Almer 07master:827a05eaa948: matroskaenc: add support for Spherical Video elements [18:23:46 CEST] <cone-583> ffmpeg 03James Almer 07master:fd59207c1c86: Merge commit '827a05eaa9482e9ac2a17f7f2e42ead07c1d7574' [18:25:54 CEST] <cone-583> ffmpeg 03Martin Storsjö 07master:7995ebfad120: arm/aarch64: vp9: Fix vertical alignment [18:25:55 CEST] <cone-583> ffmpeg 03James Almer 07master:a86e11521334: Merge commit '7995ebfad12002033c73feed422a1cfc62081e8f' [18:28:48 CEST] <cone-583> ffmpeg 03Diego Biurrun 07master:cfee5e1a0fa8: build: Add missing object dependency for extract_extradata bitstream filter [18:28:49 CEST] <cone-583> ffmpeg 03James Almer 07master:0814f4f720e8: Merge commit 'cfee5e1a0fa892fadd19b8848545d62f2386a6e7' [18:33:55 CEST] <cone-583> ffmpeg 03Diego Biurrun 07master:b864230c4908: rtmp: Move RTMP digest calculation to a separate file [18:33:56 CEST] <cone-583> ffmpeg 03James Almer 07master:5f84ad3ecce3: Merge commit 'b864230c49089b087eef56988a3d6a784f6f9827' [18:40:18 CEST] <jamrial> michaelni: what do you think of bd805964f4? [18:40:26 CEST] <jamrial> since you have jack installed [18:40:47 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:b266ad56fe0e: hwcontext: Add device derivation [18:40:48 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:b7487f4f3c39: hwcontext: Make it easier to work with device types [18:40:49 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:d2e6dd32a445: avconv: Generic device setup [18:40:50 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:62a1ef9f26c6: avconv: Enable generic hwaccel support for VAAPI [18:40:51 CEST] <cone-583> ffmpeg 03wm4 07master:16a163b55a65: lavc: Add hwaccel_flags field to AVCodecContext [18:40:52 CEST] <cone-583> ffmpeg 03wm4 07master:1a7ddba5762b: lavc: vdpau: add support for new hw_frames_ctx and hw_device_ctx API [18:40:53 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:aa6b2e081c50: avconv: Enable generic hwaccel support for VDPAU [18:40:54 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:303fadf5963e: avconv: Document the -init_hw_device option [18:40:55 CEST] <cone-583> ffmpeg 03James Almer 07master:9cfdf0e3322b: Merge commit '303fadf5963e01b8edf4ba2701e45f7e9e586aeb' [18:43:28 CEST] <ubitux> all work and no play makes jack a dull boy ~ [18:46:09 CEST] <ubitux> jamrial: removing jack from the autodetected lib probably makes sense yes [18:46:18 CEST] <ubitux> (IMO) [18:46:43 CEST] <jamrial> ok [18:46:50 CEST] <ubitux> OTOH, we have --disable-autodetect now so it doesn't matter much [18:46:54 CEST] <jamrial> ubitux: less than ten commits until the major bump :D [18:47:01 CEST] <ubitux> yay [18:47:36 CEST] <ubitux> btw, shouldn't sndio be handled the same? [18:47:44 CEST] <ubitux> as in "not autodetected"? [18:47:47 CEST] <jamrial> we'll finally be back to minor versions in the single and double digits :p [18:47:53 CEST] <ubitux> :) [18:48:22 CEST] <jamrial> libavcodec reaching minor 100 for this major version was a first i think [19:06:17 CEST] <jamrial> ubitux: i'll look at sndio later [19:06:57 CEST] <jamrial> but yeah, being used for an indev guess it should probably not be autodetected [19:13:51 CEST] <cone-583> ffmpeg 03Luca Barbato 07master:bd805964f40f: configure: Do not treat JACK as a system library [19:13:52 CEST] <cone-583> ffmpeg 03James Almer 07master:a2a7b02fbd9d: Merge commit 'bd805964f40f7af83da64645ba83d1e8060a1214' [19:16:03 CEST] <cone-583> ffmpeg 03Luca Barbato 07master:ca960161f087: rtsp: Move message parsing to a separate function [19:16:04 CEST] <cone-583> ffmpeg 03James Almer 07master:12b6166bcfb4: Merge commit 'ca960161f087ca38267b88ce90592010c59584f1' [19:17:51 CEST] <cone-583> ffmpeg 03Konda Raju 07master:3df77b58e35a: nvenc: Allow different const qps for I, P and B frames [19:17:52 CEST] <cone-583> ffmpeg 03James Almer 07master:2c966481091a: Merge commit '3df77b58e35a30ed550f99936a308f6bd2f47a20' [19:20:05 CEST] <cone-583> ffmpeg 03Luca Barbato 07master:e245d4f45ca5: dca: Validate the channel map [19:20:06 CEST] <cone-583> ffmpeg 03Luca Barbato 07master:a46a4f722d2f: dca: Refactor dca_filter_channels() a little [19:20:07 CEST] <cone-583> ffmpeg 03James Almer 07master:157dc1495135: Merge commit 'a46a4f722d2fac07c57990f0f548777622599f59' [19:22:42 CEST] <cone-583> ffmpeg 03Martin Storsjö 07master:3aa9c523e9cf: libavutil: Define the noreturn attribute for clang in MSVC mode as well [19:22:44 CEST] <cone-583> ffmpeg 03James Almer 07master:1ba5e456dd6e: Merge commit '3aa9c523e9cf4f4a5e239ac737281e096c884907' [19:26:49 CEST] <cone-583> ffmpeg 03Martin Storsjö 07master:8e2346154e6d: libavutil: Hook up the rest of the gcc specific attributes to clang as well [19:26:50 CEST] <cone-583> ffmpeg 03James Almer 07master:072b14f39047: Merge commit '8e2346154e6d58b733fd20326ce706f82fd91b3e' [19:35:41 CEST] <cone-583> ffmpeg 03Carl Eugen Hoyos 07master:628ce8b8b6b8: flvdec: Set avg_frame_rate for video streams [19:35:42 CEST] <cone-583> ffmpeg 03James Almer 07master:4c0a8ff0610c: Merge commit '628ce8b8b6b80cb3985d39e195b71b9d7fad9008' [19:58:42 CEST] <michaelni> jamrial, iam the wrong one to ask about configure and system libs, thats not my area [19:59:14 CEST] <jamrial> michaelni: ah ok. i thought about you since you noticed the jack regression the other week during a configure merge [19:59:21 CEST] <jamrial> will keep that in mind, thanks [20:07:08 CEST] <ubitux> jamrial: so, are we bumping or what? :p [20:07:19 CEST] <jamrial> ubitux: running fate :p [20:07:25 CEST] <ubitux> :o [20:07:40 CEST] <jamrial> since the last time i ran it with the bump applied was september :p [20:11:00 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:07a2b155949e: Bump major versions of all libraries [20:11:01 CEST] <cone-583> ffmpeg 03James Almer 07master:69b5ce64d226: Merge commit '07a2b155949eb267cdfc7805f42c7b3375f9c7c5' [20:11:23 CEST] <jamrial> :D [20:11:29 CEST] <ubitux> and now, the storm [20:12:32 CEST] <jamrial> I'm hoping we can just start cleaning without major issues :p [20:16:28 CEST] <jamrial> whooo wants to deal with some of the private-but-not-really fields stuff in public headers? [20:17:14 CEST] <jamrial> i'll be cleaning dead code as part of the following merges for a bit [20:24:11 CEST] <cone-583> ffmpeg 03Carl Eugen Hoyos 07master:535117d1f6de: lavd/lavfi: Constify two variables. [20:25:50 CEST] <cone-583> ffmpeg 03Carl Eugen Hoyos 07master:ea049ad862a4: lavfi/graphparser: Constify a variable. [20:27:49 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:88fd836a015a: lavfi: Drop deprecated way of passing options for a few filters [20:27:50 CEST] <cone-583> ffmpeg 03James Almer 07master:0ed61546c459: Merge commit '88fd836a015a5f3380df74592e440e7d1e5b8000' [20:29:32 CEST] <ubitux> jamrial: you reached a < 400 commits left checkpoint [20:29:34 CEST] <ubitux> :) [20:29:49 CEST] <jamrial> neat [20:29:59 CEST] <jamrial> to me the real milestone is reaching the bump, though :p [20:30:08 CEST] <jamrial> it was way too overdue [20:31:06 CEST] <ubitux> about end of march, yeah [20:33:45 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:c5c7cfd5e80d: lavfi: Drop deprecated functions to open a filter or a filterchain [20:33:46 CEST] <cone-583> ffmpeg 03James Almer 07master:7c4f63d05b33: Merge commit 'c5c7cfd5e80d4c36568c01cc40abfde341657ad9' [20:36:16 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:52067b3c0e5d: lavfi: Drop deprecated filter initialization [20:36:17 CEST] <cone-583> ffmpeg 03James Almer 07master:5045cf27aacb: Merge commit '52067b3c0e5ddbcf7021a093420798420351a9e2' [20:38:33 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:8e18328b18e6: lavfi: Drop deprecated filter registration [20:38:34 CEST] <cone-583> ffmpeg 03James Almer 07master:de0b26ce2886: Merge commit '8e18328b18e69b38a5feae5d10ad01b403a205b6' [20:45:07 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:96a47364d1cf: lavfi: Drop deprecated non-const filter retrieval [20:45:08 CEST] <cone-583> ffmpeg 03James Almer 07master:d1b1a65662e3: Merge commit '96a47364d1cf346a5d0437e054b1b10d44d8d969' [20:49:25 CEST] <atomnuker> jamrial: how does the removal of FF_API_ stuff happen? [20:49:56 CEST] <atomnuker> does someone need to do each manually? [20:50:04 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:5e71299758d3: lavf: Drop deprecated bitexact functionality [20:50:05 CEST] <cone-583> ffmpeg 03James Almer 07master:f02bda3a03c1: Merge commit '5e71299758d3aa7c93c3cca618a8e048a9483794' [20:50:46 CEST] <jamrial> not really. all the dead code inside these wrappers could be removed in one commit, but doing it separately is cleaner i guess [20:51:03 CEST] <atomnuker> are you going to do those eventually? [20:51:51 CEST] <jamrial> i'm doing that right now [20:52:08 CEST] <jamrial> these merges are dropping most (if not all) of them [20:53:24 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:263358e0c9e7: lavf: Drop deprecated AVFract type and related field [20:53:25 CEST] <cone-583> ffmpeg 03James Almer 07master:a295fee28496: Merge commit '263358e0c9e7ffaa965fdbe986c8b18381d2b24a' [20:54:58 CEST] <atomnuker> jamrial: I've just sent a v2 of your favorite patchset to the ml [20:55:54 CEST] <atomnuker> (and do remember to remove url_feof from libavformat/libavformat.v) [20:56:23 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:63fe79a3368c: lavf: Drop deprecated hint to set muxer timebase [20:56:24 CEST] <cone-583> ffmpeg 03James Almer 07master:1198e34e1189: Merge commit '63fe79a3368cc53e6faf7fa265a9a1a8bec46a88' [21:00:38 CEST] <cone-583> ffmpeg 03Vittorio Giovara 07master:bc143ce1ac3f: lavc: Drop deprecated chroma subsample function [21:00:39 CEST] <cone-583> ffmpeg 03James Almer 07master:c060ed02a865: Merge commit 'bc143ce1ac3f8cd851a7e6be69d9a1fbe6b633b6' [21:01:05 CEST] <jamrial> atomnuker: eh, i would have rather waited a bit for that [21:02:27 CEST] <jamrial> as i mentioned in the bump patch i sent to the ml, ffserver can be removed once the month grace period is over since until then we're still able to stop exposing all the internal api [21:07:37 CEST] <jamrial> sigh, as i expected, your patchset once again touched people's nerves [21:13:02 CEST] <michaelni> src/fftools/ffserver_config.c:294:15: error: AVCodecContext has no member named rc_eq [21:16:20 CEST] <ubitux> jamrial: seems you got a new friend [21:16:22 CEST] <atomnuker> jamrial: maybe cut the month to say, a day or so-ish ^^? [21:16:34 CEST] <jamrial> atomnuker: i really wish you wouldn't have sent that [21:16:50 CEST] <jamrial> why the fuck didn't ANYBODY report this ffserver build failure? [21:16:58 CEST] <jamrial> I sent the fuckign bump patch a month and a half ago [21:17:15 CEST] <jamrial> i can't deal with this shit [21:17:43 CEST] <jamrial> why did nobody read it or test it? holy fucking shit i'm mad [21:17:49 CEST] <michaelni> jamrial, i didnt realize that the bump was imminent [21:17:50 CEST] <atomnuker> everyone tested with --disable-ffserver? [21:18:12 CEST] <jamrial> michaelni: it was in the merge queue, and my intention was even to commit before reaching that point [21:18:15 CEST] <jamrial> and i instead waited [21:20:57 CEST] <jamrial> now, how to put this field back [21:21:07 CEST] <jamrial> michaelni: what FF_API removed it? [21:21:22 CEST] <michaelni> seems FF_API_MPV_OPT [21:21:31 CEST] <jamrial> i'll just put that back in place until a month passes when we can remove it alongside ffserver [21:21:42 CEST] <michaelni> agree [21:22:48 CEST] <jamrial> michaelni: does ffserver build with it back in place? [21:23:31 CEST] <michaelni> iam atm just testing with the single field in avcodeccontext back in place, it buils but ffmpeg looks very broken [21:24:12 CEST] <jamrial> how so? fate passes [21:25:39 CEST] <jamrial> that FF_API has a lot of code in mpegvideo_enc, so the field alone wouldn't do much [21:26:03 CEST] <michaelni> yes i need to retest with FF_API_MPV_OPT reenabled [21:28:25 CEST] <atomnuker> jamrial: wouldn't it be easier to just remove the rc_eq field usage from ffserver? its only used in a single place [21:28:56 CEST] <jamrial> atomnuker: can you do that? [21:28:58 CEST] <michaelni> FF_API_MPV_OPT wasnt even sheduled to be removed a day ago [21:29:00 CEST] <jamrial> i have never touched ffserver [21:29:57 CEST] <atomnuker> jamrial: yeah, just remove the 7 lines it uses to read rc_eq from the config file and set the value in avctx [21:29:57 CEST] <jamrial> michaelni: the deprecation is older than two years, that's why it was removed [21:30:09 CEST] <atomnuker> it would act as if rc_eq wasn't specified in the configure file [21:30:45 CEST] <michaelni> jamrial, anyone testing bumping would not have noticed breakages in code that was not sheduled to be removed before today [21:31:08 CEST] <jamrial> michaelni: the patch i sent and ultimately commited it disables it [21:32:54 CEST] <jamrial> the deprecation is from 2013, i have no idea why it was listed with version 59, probably someone thinking a lot more bumps would happen during these four years and wanted to avoid having to constantly edit the line before two years passed [21:33:21 CEST] <michaelni> i guess somehow noone tested it or maybe i tested and discarded it when it didnt build beliving tat this was work in progress i dont remember [21:35:44 CEST] <jamrial> i'll reenable it for now if you can confirm ffserver builds with it [21:36:22 CEST] <jamrial> a month from now we can decide what to do with it. but since it's a four years old deprecated api... [21:36:59 CEST] <atomnuker> just change a few lines in ffserver_config [21:38:29 CEST] <jamrial> atomnuker: then please do it. if anything to get ffserver back up while michaelni checks if this api can be safely removed [21:40:14 CEST] <michaelni> jamrial, fate-api-mjpeg-codec-param fails with FF_API_MPV_OPT toggled back [21:40:35 CEST] <jamrial> michaelni: that's because the field is readded to avcodec.h [21:40:44 CEST] <michaelni> yes it needs to be updated [21:41:00 CEST] <michaelni> build works [21:41:40 CEST] <jamrial> did removing that api do anything else aside from breaking ffserver build? [21:41:52 CEST] <michaelni> i dont know [21:44:59 CEST] <jamrial> atomnuker: can you cook up a patch? if so we can apply that instead [21:46:14 CEST] <michaelni> are any codecs loosing rc_eq support with this or any other options ? [21:46:49 CEST] <michaelni> anything supporting the rate control code can use rc_eq [21:47:17 CEST] <jamrial> the deprecated field mentions codec private options should be used [21:48:00 CEST] <jamrial> nothing but ffserver was using the avcodeccontext field. anything else was alledgedly already using code private options for the same purpose [21:48:25 CEST] <atomnuker> jamrial: https://pars.ee/temp/ffserv_remove_rc_eq.patch [21:48:32 CEST] <michaelni> f02bda3a03c1103a1c293ad030e6bcf089b21902 <-- breaks bitexact i suspect [21:49:12 CEST] <michaelni> so i cant test anything anymore as i used this [21:49:52 CEST] <jamrial> michaelni: that API remove is the one that made -flags +bitexact also trigger -fflags +bitexact [21:50:02 CEST] <michaelni> or maybe another change broke it [21:50:07 CEST] <jamrial> it's been deprecated for more than two years and a big warning issued eveyr time it was used [21:50:37 CEST] <jamrial> the bump disabled it, that merge just removed the dead code cruft [21:51:09 CEST] <jamrial> all the fate tests were updated to include -fflags +bitexact when required [21:52:31 CEST] <jamrial> atomnuker: that doesn't make it use the codec private option... [21:52:42 CEST] <jamrial> i'll just reenable the API and remove it a month from now [21:52:53 CEST] <atomnuker> jamrial: what do you mean? [21:52:53 CEST] <jamrial> I'd rather not touch ffserver at all to being with [21:53:01 CEST] <atomnuker> yeah, ok [21:53:08 CEST] <jamrial> read the field's deprecation notice [21:53:29 CEST] <atomnuker> but please make sure that it won't be forgotten to be removed [21:53:44 CEST] <atomnuker> so it won't become a 6 year old deprecated field by the time it has to be removed [21:54:31 CEST] <cone-583> ffmpeg 03James Almer 07master:75bd2157272a: avcodec/version: re-enable FF_API_MPV_OPT until the open ABI period is over [21:54:55 CEST] <michaelni> jamrial, so much gets removed and broken at the same time, its hard to deal with [21:55:36 CEST] <jamrial> nothing is supposed to be broken... just deprecated API being dropped [21:55:38 CEST] <JEEB> -34 [21:56:16 CEST] <jamrial> the point of the wrappers is to simply being able to flip a value to disable said deprecated API without breakign anything. FATE passing is what guarantees this [21:57:06 CEST] <jamrial> admitedly, each API could have been disabled one by one, then the bump made effective [21:57:13 CEST] <jamrial> wonder why libav didn't do that... [21:57:23 CEST] <michaelni> that would make bisect also alot easier [21:57:24 CEST] <jamrial> it was also something that could have been suggested to the patch i sent... [21:58:04 CEST] <jamrial> anyway, ffserver builds again now that i put rc_eq back in place for the time being [21:58:09 CEST] <jamrial> sorry for the unintended breakage [21:58:24 CEST] <atomnuker> jamrial: you fixed it in the worst possible way, now when it gets removed someone will complain you didn't wait [21:58:25 CEST] <michaelni> i thought (at some point at least) someone would implement a -bitexact option for ffmpeg before -flags +bitexact is droped [21:58:36 CEST] <atomnuker> you should have just defined it to be 1 with a TODO comment [21:58:58 CEST] <jamrial> atomnuker: maybe [21:59:52 CEST] <atomnuker> jamrial: I'm adding a comment, I can't stand and leave it like that [22:00:03 CEST] <jamrial> ok [22:00:31 CEST] <jamrial> just keep it simple and obvious that it's in place for a short while [22:02:15 CEST] <jamrial> atomnuker: maybe also make it 1 if you want [22:03:23 CEST] <jamrial> michaelni: -flags +bitexact wasn't dropped. it just doesn't imply -fflags +bitexact anymore [22:03:51 CEST] <michaelni> jamrial, yes, bad wording from me [22:04:21 CEST] <cone-583> ffmpeg 03Rostislav Pehlivanov 07master:efb79cabb2c8: libavcodec/version: add a comment about FF_API_MPV_OPT deprecation [22:04:43 CEST] <jamrial> i can't say if anyone ever intended to add a -bitexact option that enables both format and codec flags [22:07:07 CEST] <michaelni> this changes: ./ffmpeg -f lavfi -i testsrc -vcodec libxvid -vframes 2 -flags +bitexact -fflags +bitexact file-new.mov [22:08:02 CEST] <jamrial> in what way? [22:08:18 CEST] <michaelni> thats a good question [22:08:22 CEST] <michaelni> file size differs [22:09:27 CEST] <michaelni> 2nd frame crc changes on decode [22:10:15 CEST] <michaelni> 0, 512, 512, 512, 194, 0x54ca7b72, F=0x0 vs. 0, 512, 512, 512, 257, 0xbefca5bc, F=0x0 [22:11:05 CEST] <michaelni> Reading option '-vismv' ...Unrecognized option 'vismv'. [22:11:17 CEST] <michaelni> i guess that was deprecated too ? [22:11:22 CEST] <jamrial> yeah [22:11:34 CEST] <jamrial> version.h evne mentions the docs should be updated once it's dropped [22:11:59 CEST] <michaelni> whats the replacement for -debug 16384 -vismv 7 ? [22:12:13 CEST] <jamrial> i have no idea, i didn't deprecate any of these APIs [22:13:14 CEST] <jamrial> looks like ubitux depreacted it in f888331769d [22:13:20 CEST] <jamrial> three years ago [22:13:46 CEST] <jamrial> seems the codecview filter is the replacement [22:21:06 CEST] <michaelni> ok, codecview seems working not bit identica to before but it looks correct for the files i tried [22:21:56 CEST] <jamrial> michaelni: i think the xvid thing is a default that changed after dropping me_method [22:22:40 CEST] <jamrial> since default me_method value was 5, and the private codec option default is 0 [22:23:02 CEST] <jamrial> i'll make sure its that and update the private option default [22:27:11 CEST] <michaelni> me_method option for snow is failing -motion_est works, theres no warning shown with -me_method previously [22:29:00 CEST] <jamrial> i don't think any of the deprecated options in options_table-h ever triggered warnings... [22:29:15 CEST] <jamrial> the deprecation warnings were in the avcodecontext fields [22:29:56 CEST] <jamrial> and yes, motion_est works after i fixed it last month before sending the bump patch [22:30:17 CEST] <jamrial> it was one of the preparation fixes for this bump i worked with [22:30:46 CEST] <michaelni> mpeg2video -me_method fails too the same way [22:31:38 CEST] <jamrial> yes, me_method was a global option that was deprecated in favor of codec private options [22:31:56 CEST] <jamrial> it's all stated in the @deprecated doxy for each field... [22:31:56 CEST] <michaelni> it should have shown a warning if it was to be removed [22:32:12 CEST] <jamrial> it never did, and how would it anyway from withing options_table.h? [22:33:14 CEST] <michaelni> yestarday the -me_method command line option worked with no hint on changes, today it fails with no hint for a replacement [22:33:19 CEST] <michaelni> this is not ideal [22:33:51 CEST] <jamrial> this is not the first time options_table.h options are removed [22:34:12 CEST] <jamrial> i don't get why it is an issue now [22:34:57 CEST] <michaelni> users use case and scripts show no warnings yestarday and today stop working with no hint for what the replacement is [22:35:08 CEST] <michaelni> its not an issue for me to update my stuff [22:35:26 CEST] <jamrial> why wasn't this concern raised in previous bumps? or even when deprecations are made effective? [22:35:35 CEST] <jamrial> scripts are broken all the time [22:35:43 CEST] <jamrial> we can't handicap development because of that [22:36:22 CEST] <michaelni> i think handicap is not the right term here [22:38:21 CEST] <michaelni> options that are going to be removed should have printed a warning, and removed options should tell the user the replacement to use if the removed option is used [22:38:31 CEST] <michaelni> that IMO of course [22:39:19 CEST] <jamrial> ok, but that's something to keep in mind for future deprecations [22:39:50 CEST] <jamrial> can't say how to make options_table.h options do that, though [22:42:15 CEST] <michaelni> a flag could be added that prints the options help text on use, the help text would then be a deprecation warning pointing to te new option [22:47:22 CEST] <durandal_1707> come on [22:55:39 CEST] <michaelni> this changes too: ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -vcodec libxavs -t 1 -flags +bitexact -fflags +bitexact new.avi [22:56:31 CEST] <jamrial> michaelni: probably motion est defaults again. will take a look [22:58:03 CEST] <durandal_1707> xavs is dead tech [22:59:29 CEST] <michaelni> ./ffmpeg -analyzeduration 1M -y -i ~/videos/matrixbench_mpeg2.mpg -vf setdar=16:9 -vframes 3 test.avi [22:59:58 CEST] <jamrial> what changes there? [23:00:15 CEST] <michaelni> DAR 16:9 vs. DAR 9:1 o the output [23:00:23 CEST] <michaelni> shown in te printout and with ffprobe [23:06:38 CEST] <jamrial> i have no idea what could generate that [23:07:11 CEST] <jamrial> and i still wonder why fate is so incomplete [23:08:06 CEST] <durandal_1707> abi breach? off by one in struct? [23:12:09 CEST] <cone-583> ffmpeg 03James Almer 07master:d3a3ee9c7a73: ffserver: remove usage of deprecated rc_eq option [23:19:47 CEST] <cone-583> ffmpeg 03James Almer 07master:5ae972f63b76: avcodec/v4l2_m2m_enc: fix usage of deprecated codec flag [23:20:32 CEST] <jkqxz> Heh, I was about to push that one too. [23:21:21 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:4dee92f6bc8b: hevc: Fix aligned array declarations [23:21:22 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:e0a967a40546: cinepakenc: Move declaration out of for initialisation statement [23:21:23 CEST] <cone-583> ffmpeg 03Mark Thompson 07master:e7d20d5e3500: movtextdec: Move declaration out of for initialisation statement [23:22:28 CEST] <jamrial> jkqxz: ah, sorry [23:23:14 CEST] <jkqxz> Doesn't matter (it did merge exactly, after all). [23:28:28 CEST] <jkqxz> Wrt your leak above, the problem is that it's slightly unclear who should free the partial data if reading fails. [23:29:03 CEST] <jkqxz> On the one hand, it might be useful to get partial output in some case, so the caller could get it and therefore would have to free it. [23:29:17 CEST] <jamrial> what leak? [23:29:40 CEST] <jkqxz> On the other, none of the current callers want it and therefore that would just add an extra cleanup call to them for no particular benefit. [23:30:09 CEST] <jkqxz> The cbs one you posted this morning. [23:30:15 CEST] <jamrial> oh [23:31:16 CEST] <jkqxz> So, <http://sprunge.us/MJFL>. [23:31:20 CEST] <jamrial> michaelni: i fixed the ffserver issue with rc_eq, so i'll undo the patch that put the field back in the struct [23:31:39 CEST] <jamrial> but i'll do it later in case you're still testing the current tree [23:38:17 CEST] <jamrial> and i need a break. i'm way too stressed right now [23:38:28 CEST] <cone-583> ffmpeg 03James Almer 07master:e08897619e0e: avcodec/libxvid: make 4 the default for me_quality [23:38:29 CEST] <cone-583> ffmpeg 03James Almer 07master:88e2e31d3460: avcodec/libxavs: make dia the default for motion-est [23:58:34 CEST] <ubitux> jamrial: so can i trash vda now or i should wait? [23:58:47 CEST] <jamrial> ubitux: you can [23:59:07 CEST] <ubitux> cool, i'll do that maybe tomorrow or on monday [23:59:48 CEST] <jamrial> and you don't need to ask me if you can do it. after the bump we have a month or two to make this kind of changes [00:00:00 CEST] --- Sun Oct 22 2017

1 0

ffmpeg.log.20171021
by burek 22 Oct '17

22 Oct '17

[03:52:03 CEST] <Johnjay> i can tell you it's a royal pain the but butt to operate on directories in windows with ffmpeg [03:52:34 CEST] <Johnjay> some way to apply the command to all files in a directory would be cool. Or like files matching a wildcard [03:53:16 CEST] <Johnjay> maybe interpret ffmpeg -i "*.mp4" as a valid input file [04:57:52 CEST] <jcjordyn120> Doesn't the shell interpret wildcards? [05:06:05 CEST] <Johnjay> on windows it only interprets * and ? [05:06:26 CEST] <Johnjay> for example if you want to loop over only .m4a and .webm files you have to write the for loop twice [05:06:55 CEST] <Johnjay> there might be a way to do it in powershell, dunno [05:15:49 CEST] <jcjordyn120> Hmm [05:16:03 CEST] <jcjordyn120> That's solved with a better shell, or two for loops. [05:24:32 CEST] <Johnjay> jcjordyn120: yeah well good luck with that. let me know when you find one that comes with the OS [05:25:14 CEST] <jcjordyn120> Windows 10 has WSL [05:25:45 CEST] <jcjordyn120> Even then if you're using windows can't you afford a better shell? [05:27:57 CEST] <Johnjay> well yes i can. but for perspective I didn't know msys2 was able to compile ffmpeg until a few weeks ago [05:28:22 CEST] <Johnjay> I didn't know about WSL until a few days ago either. [05:28:38 CEST] <Johnjay> The average person is not going to get that far trying to use ffmpeg to encode a video or two [05:32:42 CEST] <jcjordyn120> We're talking about the command line interface to ffmpeg.. right? [05:33:14 CEST] <Johnjay> i don't know. does it have a GUI interface? [05:34:34 CEST] <jcjordyn120> No clue, most of my uses of ffmpeg are from the cli. [05:34:41 CEST] <jcjordyn120> Or another program calling it [06:54:57 CEST] <mozzarella> guys [06:55:56 CEST] <mozzarella> how do I convert a video to h265 [07:33:55 CEST] <Johnjay> ffmpeg -i video.mp4 -c x265 output.mp4? [07:34:57 CEST] <Johnjay> well apparently that's not a valid encoder [07:46:28 CEST] <Johnjay> hmm so using -c hevc doesn't work [07:46:34 CEST] <Johnjay> but using -c:v hevc does work [08:06:25 CEST] <jcjordyn120> Makes sense [09:42:12 CEST] <Toba> hey... so I'm using multiple drawtexts to create titles that are center justified [09:43:34 CEST] <Toba> I'm using text_h in expressions to do multi line spacing, since I intend to make my font size settable on my titles generator [09:43:49 CEST] <Toba> https://stackoverflow.com/a/22719247 - I'm using a formula similar to "Multiple drawtext instances [09:43:55 CEST] <Toba> " from this stack overflow answer [09:44:04 CEST] <Toba> text_h though, refers to the height of the current drawtext [09:44:42 CEST] <Toba> so my lines of text are a little jumbled up vertically, since some of the lines have tall glyphs in them and some don't [09:45:20 CEST] <Toba> Any ideas about how to center justify a paragraph of text while avoiding this issue? [12:28:02 CEST] <Spioune> Hi everyone [12:28:06 CEST] <Spioune> can someone help me? [12:31:37 CEST] <Spioune> I get "ERROR: OMX_Core.h header not found" when I do "./configure --enable-gpl --enable-nonfree --enable-mmal --enable-omx --enable-omx-rpi" [12:31:48 CEST] <Spioune> on a raspberry pi 3 [12:55:40 CEST] <Spioune> alright [12:57:14 CEST] <Spioune> people? [13:14:25 CEST] <furq> Spioune: do you have that header in /opt/vc/include/IL [13:14:43 CEST] <furq> if not then you probably need to run rpi-update [13:14:52 CEST] <furq> bye [17:30:52 CEST] <FurretUber> Hi, I am trying to build ffmpeg in Xubuntu 17.10, but I'm having trouble with opencv. The libopencv-dev is installed but apparently the tests are having errors [17:31:10 CEST] <JEEB> see ffbuild/config.log [17:31:23 CEST] <JEEB> (you can also pastebin it for easier visibility) [17:31:26 CEST] <JEEB> and link here [17:31:44 CEST] <FurretUber> Here is it: https://pastebin.com/ud4G1hGG [17:32:03 CEST] <FurretUber> It's the snapshot from today [17:32:56 CEST] <JEEB> seems like the pkg-config file doesn't contain all things to link against [17:33:04 CEST] <JEEB> you can see those undefined references [17:33:12 CEST] <JEEB> or the pkg-config file has them in the wrong order or so? [17:33:36 CEST] <JEEB> because there's a use_pkg_config check for it [17:33:53 CEST] <JEEB> then it falls back to a manual one and that fails too, unsurprisingly [17:34:33 CEST] <JEEB> if you can find out which library contains cvRound you can start piecing together what's missing [17:34:48 CEST] <FurretUber> The system was upgraded from 17.04 so the packages installed should be the same (this is not 100% accurate, as something may have been removed) [17:35:09 CEST] <JEEB> not same, but newer versions usually [17:35:55 CEST] <JEEB> anyways, as I said. two alternatives: 1) the pc file doesn't contain what is required to link against it or 2) we are missing a library that we're supposed to also look at through pkg-config [17:36:03 CEST] <JEEB> in this newer version you got with 17.10 [17:36:57 CEST] <JEEB> seems like opencv got updated from 2.4.9 to 3.1.0 [17:37:00 CEST] <JEEB> not a small jump [17:37:41 CEST] <FurretUber> I've found a GitHub issue page: https://github.com/opencv/opencv/issues/8438 [17:37:51 CEST] <FurretUber> It says the reference is in a different file now [17:38:11 CEST] <FurretUber> And C++ should be used, and not C, if I understood correctly [17:38:36 CEST] <JEEB> ok, that just means that they're dropping support for the C API that we're using [17:39:00 CEST] <JEEB> FurretUber: you're out of luck then [17:39:11 CEST] <JEEB> blame the upstream :) [17:40:18 CEST] <FurretUber> Should I report this somewhere as a bug in ffmpeg then? [17:40:27 CEST] <JEEB> opencv stuff (which I'm not even sure what it does if anything) in FFmpeg was someone's research thing, that got in. [17:40:36 CEST] <JEEB> and this is upstream (opencv) breaking compatibility with that code [17:40:50 CEST] <JEEB> so, uh, I think unless you find someone willing to rewrite this [17:41:02 CEST] <JEEB> it will get removed eventually [17:42:35 CEST] <JEEB> FurretUber: you can make an issue like "OpenCV components require rewrite in C++ due to OpenCV upstream changes" [17:43:03 CEST] <JEEB> but since nobody seems to care about OpenCV (as far as I know), and the original author has since moved onto other research (most likely), I think it's not likely to get fixed [17:44:05 CEST] <JEEB> FurretUber: do you actually need the opencv stuff and thus know WTF it does? :D [17:44:18 CEST] <JEEB> or is this you just following some random compilation guide :P [17:44:25 CEST] <FurretUber> I am using this huge configure command from the Ubuntu's ffmpeg build plus some additional options I needed. From my tries yesterday, opencv is used for the spice protocol, so without it it could break virtual machines (they would boot but it would not be possible to see the graphics. [17:44:41 CEST] <JEEB> uhh [17:44:50 CEST] <JEEB> why would it have anything to do with VMs? [17:45:04 CEST] <JEEB> also FFmpeg doesn't even support that [17:45:17 CEST] <FurretUber> This I don't know, but it's what apt says if I try to purge opencv [17:45:21 CEST] <JEEB> if you just want to build your own copy of FFmpeg, just don't enable opencv [17:45:29 CEST] <JEEB> remove --enable-opencv [17:45:53 CEST] <JEEB> and you can remove the libopencv-dev package if you never expect to be building something with opencv [17:45:58 CEST] <JEEB> by yourself that is [17:46:06 CEST] <JEEB> you don't need to remove opencv altogether you know :P [17:46:18 CEST] <JEEB> you're specifically forcing opencv to be enabled and thus it fails during configure [17:46:23 CEST] <JEEB> (of FFmpeg) [17:49:46 CEST] <FurretUber> The Ubuntu's default config has opencv enabled, as I wanted to replace the Ubuntu's default by the version I built, I suppose it must have everything Ubuntu's configuration has, at least. If I try without opencv it works, but then I have to keep a parallel install [17:50:41 CEST] <FurretUber> Where should I make an issue? [17:52:44 CEST] <JEEB> uhh, I'm pretty sure ubuntu had to disable it [17:52:47 CEST] <JEEB> or they patched it [17:54:21 CEST] <JEEB> ok, their libavfilter seems to still link against opencv-core and imgproc [17:54:25 CEST] <JEEB> so they probably patched it [17:54:39 CEST] <FurretUber> When using their ffmpeg (with no options) it prints "WARNING: library configuration mismatch". They had some trouble, apparently, but still have --enable-libopencv [17:55:06 CEST] <JEEB> no, that just means that something you built is getting grabbed as libraries go [19:41:56 CEST] <AEP197_2> oi [19:51:51 CEST] <kiroma> Hey, I have issues when compiling ffmpeg with nvecn [19:51:54 CEST] <kiroma> *nvenc [19:52:09 CEST] <kiroma> "ERROR: nvenc requested, but not all dependencies are satisfied: cuda" [19:52:18 CEST] <kiroma> Even though --enable-cuda is specified. [19:54:40 CEST] <kiroma> Ah, wait, it's not finding cuda [19:58:21 CEST] <dystopia_> im setting "-preset slow" but in my mediainfo i see "me=hex" instead of "me=umh" [19:58:24 CEST] <dystopia_> anyone know why? [20:05:12 CEST] <furq> what's the full command [20:05:44 CEST] <dystopia_> ffmpeg -t 10 -y -i in.ts -sws_flags spline -vf yadif=1:0,scale=720:-4,setsar=1:1 -c:v libx264 -preset slow -profile:v high -level 3.1 -crf 24 -r 50 -x264opts force-cfr=1:colormatrix=bt709 -sn -acodec copy out.mkv [20:07:14 CEST] <furq> weird [20:07:25 CEST] <furq> i just checked and i get the same thing [20:07:29 CEST] <furq> maybe they changed the presets recently [20:08:10 CEST] <furq> either that or this preset reference site has always been wrong [20:08:26 CEST] <dystopia_> https://pastebin.com/drrtf3XM [20:08:27 CEST] <kiroma> --arch=native breaks configuration [20:08:35 CEST] <dystopia_> :( [20:09:00 CEST] <furq> i'm pretty sure i remember slow being umh [20:09:02 CEST] <furq> so i guess it was changed [20:16:34 CEST] <kiroma> What gcc compilers are supported by cuda? [20:16:35 CEST] <dystopia_> so is there some way to manually set me=umh? [20:18:17 CEST] <DHE> dystopia_: you can use -x264opts to specify options manually [20:18:18 CEST] <CoreX> me=hex has been default for months now under preset slow [20:18:40 CEST] <dystopia_> default in x264.exe also? [20:18:44 CEST] <CoreX> yes [20:18:50 CEST] <dystopia_> ok :) [20:19:10 CEST] <dystopia_> thank you corex/furq or the info [20:19:15 CEST] <dystopia_> for the info* [20:37:09 CEST] <kiroma> Is there such thing as a libffmpeg.so [20:37:10 CEST] <kiroma> ? [20:46:08 CEST] <DHE> it's a collection of libraries such as libavcodec.so, libavformat.so, etc [20:53:54 CEST] <kiroma> How can I get it? What config flag does it need? [20:57:05 CEST] <thebombzen> the libraries are built by default [20:57:25 CEST] <DHE> if you want the .so files, --enable-shared but the defaults are static-only [20:57:42 CEST] <thebombzen> the headers and libraries also come with the ffmpeg installed by your package manager (probably) so you don't necessarily need to build it yourself [20:58:13 CEST] <thebombzen> depending on your system, you might need to install ffmpeg-devel, ffmpeg-dev, etc. [21:02:58 CEST] <kiroma> I compile my ffmpeg with --enable-shared but I never got that library. [21:03:36 CEST] <kiroma> There's all libs from libav, but I've never seen libffmpeg.so being compiled. [21:10:09 CEST] <thebombzen> there is no "libffmpeg.so" [21:10:16 CEST] <thebombzen> the name of the libraries is libavcodec, libavformat, etc. [21:10:38 CEST] <thebombzen> there's more than one library. the functionality of the FFmpeg project is fragmented into several libraries because they do different things and not all applications need all libraries [21:11:27 CEST] <thebombzen> the library names of libavcodec, libavformat, libswscale, etc. predate the existence of the Libav fork. The Libav fork of FFmpeg project is named thus to intentionally confuse you [21:11:49 CEST] <kiroma> Then what the hell is the thing that's in Discord's share folder? [21:12:01 CEST] <thebombzen> huh? [21:12:58 CEST] <kiroma> There is a file in /usr/share/discord that's called "libffmpeg.so" and nobody knows what it is. [21:13:31 CEST] <kiroma> I tried searching it up but nothing came up. [21:13:35 CEST] <thebombzen> DiscordApp has its own custom build of ffmpeg [21:14:17 CEST] <thebombzen> the Discord developers basically smashed it all together internally. many non-FOSS pieces of software don't like using the system libraries for some weirdass reason. [21:14:33 CEST] <kiroma> Ah, I see. [21:15:09 CEST] <thebombzen> you, however, should use the standard method of linking [22:06:49 CEST] <srini> Hello [22:08:10 CEST] <srini> i am looking to segment the static video files from youtube into mpegts files [22:10:01 CEST] <DHE> there's a segment driver. you might also be able to use the HLS driver since it outputs to mpegts segments by default anyways [22:10:01 CEST] <srini> any idea how can i use byte ranges and produce the ts files, something similar to hls [22:10:55 CEST] <DHE> mpegts is special in that it's a streaming format. it's designed so that you can join it at any point (even non-byte boundaries) and playback with no seek capability. by contrast youtube uses mp4 and webm [22:11:43 CEST] <srini> DHE: Thanks, thats right [22:12:01 CEST] <DHE> for 10 second segments (and abusing the HLS muxer to do the heavy lifting), something like: ffmpeg -i input.mp4 -c copy -f hls -hls_time 10 output.m3u8 [22:12:20 CEST] <DHE> oh, add -hls_list_size 0 [22:18:04 CEST] <srini> DHE: But this needs the video to be downloaded, i am looking to connect to the base url from the mpd.xml and then download the segments and create the ts files [22:18:51 CEST] <DHE> ffmpeg will accept URLs for the input(s). even with SSL if it was built with SSL support [22:31:02 CEST] <srini> DHE: Thanks appreciate your response [23:57:13 CEST] <kerio> DHE: hold on, non-byte boundaries? [23:57:19 CEST] <kerio> how does that even work [23:58:09 CEST] <DHE> there's a sync byte every 188 bytes. in theory it's possible [23:58:36 CEST] <DHE> remember mpegts is what's carried over the air. your TV can tune into it at any instant [23:59:17 CEST] <kerio> fair enough [00:00:00 CEST] --- Sun Oct 22 2017

1 0