Ffmpeg-devel-irc
Threads by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
July 2019
- 1 participants
- 38 discussions
[02:13:07 CEST] <yuzo555> Hi, is there any news about when FFmpeg 4.2 will be released?
[07:43:21 CEST] <cone-728> ffmpeg 03Calvin Walton 07master:2bd21b960963: vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables
[11:36:27 CEST] <cone-120> ffmpeg 03Paul B Mahol 07master:ca576833e46c: avcodec/cngdec: set .caps_internal
[13:34:40 CEST] <Lynne> lol, youtube provide ttml subs
[14:30:07 CEST] <kierank> durandal_1707: http://samples.mplayerhq.hu/V-codecs/CFHD/
[14:30:12 CEST] <kierank> MT bear one has pframes
[14:31:12 CEST] <durandal_1707> thanks!
[14:31:31 CEST] <kierank> patches are on ml somewhere
[14:35:45 CEST] <durandal_1707> kierank: don't be against bayer in swscale
[14:35:58 CEST] <kierank> durandal_1707: there are so many different variants
[14:36:02 CEST] <kierank> are you going to have new pixel format per camera
[14:36:04 CEST] <kierank> per bitdepth
[14:36:20 CEST] <durandal_1707> there is only 12bit in cineform
[14:36:42 CEST] <kierank> durandal_1707: sure but it's a slippery slope
[14:37:13 CEST] <durandal_1707> i could output it into 12bit gray, and let users do debayer
[14:37:38 CEST] <Lynne> also an issue: what exactly do you do to bayer to make it normal rgb? bilinear interpolation? spline? neural nets?
[14:38:37 CEST] <kierank> exactly
[14:38:49 CEST] <kierank> https://twitter.com/kierank_/status/1147847340134457346
[14:39:06 CEST] <kierank> all the bayer related stuff is a whole library in itself
[14:39:29 CEST] <kierank> probably as big and complex as ffmpeg
[14:40:31 CEST] <kierank> durandal_1707: getting pframes in would be interesting
[14:40:39 CEST] <kierank> I had a whole hard drive of samples somewhere
[20:17:51 CEST] <cone-677> ffmpeg 03Mark Thompson 07master:c1a430885dc7: lavc/h265_profile_level: Fix DPB size calculation
[20:17:51 CEST] <cone-677> ffmpeg 03Mark Thompson 07master:f344bb2466f8: lavc/h265_profile_level: Do not allow high tier at level < 4
[20:17:51 CEST] <cone-677> ffmpeg 03Mark Thompson 07master:c7142875c38c: h265_metadata: Add option to set the level of the stream
[20:17:51 CEST] <cone-677> ffmpeg 03Mark Thompson 07master:e3424575f588: lavc/h265_profile_level: Add unit test
[20:17:51 CEST] <cone-677> ffmpeg 03Mark Thompson 07master:cd3578a8e4e1: lavc/h265_profile_level: Add new profiles
[20:38:08 CEST] <cone-677> ffmpeg 03Mark Thompson 07master:451a51124d5d: lavu/frame: Improve ROI documentation
[20:38:09 CEST] <cone-677> ffmpeg 03Mark Thompson 07master:d76e2aaf0896: libx264: Update ROI behaviour to match documentation
[20:38:10 CEST] <cone-677> ffmpeg 03Mark Thompson 07master:f6c572bd89e6: libx265: Update ROI behaviour to match documentation
[22:40:05 CEST] <cone-677> ffmpeg 03Amir Pauker 07master:70ba8e2fa0d7: avcodec/error_resilience: set AVFrame decode_error_flags in case of decoding error
[22:40:06 CEST] <cone-677> ffmpeg 03Amir Pauker 07master:f6dece864de4: avcodec/h264dec: set AVFrame decode_error_flags in case of decoding error
[23:17:32 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:1e93f5060f6f: cbs: Allow non-blank packets in ff_cbs_write_packet
[23:17:33 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:7549f0ac1baf: av1_metadata: Avoid allocations and copies of packet structures
[23:17:34 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:45fd7e44a4dd: filter_units: Unref packet on failure
[23:17:35 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:83be17cfcdd9: filter_units: Don't use fake loop
[23:17:36 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:57f9bc90ae09: filter_units: Reindent after previous commit
[23:17:37 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:b0810454e473: filter_units: Avoid allocations and copies of packet structures
[23:17:38 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:36fcdc3fbe08: av1/h264_metadata, filter_units: Count down when deleting units
[23:17:39 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:a72cc47a275a: h264_metadata: Avoid allocations and copies of packet structures
[23:17:40 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:3c8a2a1180f0: h264_metadata: Localize code for display orientation
[23:32:23 CEST] <mkver> jkqxz: Mark, looking again at the changes to ff_cbs_delete_unit, I am thinking whether it would not be better to assert that the unit to be deleted actually exists and make ff_cbs_delete_unit not return anything.
[23:33:22 CEST] <jkqxz> I'm wondering roughly the same thing looking at 12.
[23:33:50 CEST] <jkqxz> ff_cbs_h264_delete_sei_message() is thematically equivalent, so them having different styling is kindof weird.
[23:34:31 CEST] <mkver> So you agree to it?
[23:35:04 CEST] <jkqxz> Are there any current callers of ff_cbs_delete_unit() which might fail?
[23:35:56 CEST] <mkver> Not if av1_metadata errors out if the fragment is empty.
[23:38:06 CEST] <jkqxz> Right. You've removed most people who look at the return value, and the odd cases left are all looking at a specific unit.
[23:40:01 CEST] <jkqxz> And s/most/all/, once I look more carefully.
[23:40:20 CEST] <jkqxz> Then yes, making it void and av_assert0()ful sounds good to me.
[23:40:30 CEST] <mkver> Ok.
[23:42:00 CEST] <jkqxz> Can you redo 11 with that?
[23:42:18 CEST] <mkver> Yes, I will do it.
[23:42:48 CEST] <jkqxz> 10 is good anyway, I'll apply it now. Rest I can still look through but some rebasing is probably needed.
[23:43:24 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:3f81cc8c9458: av1_metadata: Error out if fragment is empty
[23:49:54 CEST] <jkqxz> Hmm. On 14, how did that ever work?
[23:52:12 CEST] <jkqxz> Oh, ha. Looks like the bluray streams always have an SEI between the PPS and the slices, which would be the skipped unit.
[23:53:58 CEST] <mkver> Even without the SEI, the slices would have been modified during the same iteration of the loop (there was no continue, after all).
[23:55:01 CEST] <mkver> The change only matters if there are multiple PPS in sequence.
[00:00:00 CEST] --- Mon Jul 8 2019
1
0
[01:24:02 CEST] <iive> Lunchbox, check the "minterpolate" video filter. tbh i'm not sure it is real time one.
[01:24:23 CEST] <iive> oh, you want downscale...
[01:31:36 CEST] <yuzo555> Hi, is there any news about when FFmpeg 4.2 will be released?
[00:00:00 CEST] --- Mon Jul 8 2019
1
0
[00:01:11 CEST] <durandal_1707> NetBeans IDE spam
[01:31:36 CEST] <mkver> nevcairiel: Don't worry, I never intended to read all these 7000 unreadable lines.
[01:42:53 CEST] <kierank> nevcairiel: how can this file format be so insane
[01:42:57 CEST] <kierank> it's like .doc
[01:43:13 CEST] <nevcairiel> I have no idea how some proprietary format can grow so insane
[05:06:25 CEST] <dastan> hello
[05:06:42 CEST] <dastan> someone knows a vlc developper?
[05:07:15 CEST] <dastan> or is some VLC developper here? in vlc channel is dead :)
[05:07:59 CEST] <dastan> i am asking here as i am working with decklink cards and i know vlc use some ffmpeg libraries
[05:08:25 CEST] <dastan> michaelni is mentioned in some of the modules of vlc
[07:54:34 CEST] <cone-147> ffmpeg 03Jun Zhao 07master:3ed0b3f6f709: lavfi/scale: Add sub-options for in_color_matrix/out_color_matrix
[07:54:34 CEST] <cone-147> ffmpeg 03Jun Zhao 07master:feade2b403a7: doc/filters: Document missing options for scale in/out color matrix
[12:05:13 CEST] <cone-214> ffmpeg 03Paul B Mahol 07master:b9a6106842d0: avfilter/af_afftfilt: remove invalid scaling
[13:23:34 CEST] <durandal_1707> who broke MKV?
[17:12:25 CEST] <kierank> durandal_1707: don't be mean to contributors
[17:17:12 CEST] <durandal_1707> kierank: they broke it, fix it now!
[17:17:33 CEST] <kierank> I mean netbeans guy
[18:01:33 CEST] <durandal_1707> kierank: what? i did nothing!
[18:01:51 CEST] <kierank> You rude to him
[18:01:59 CEST] <durandal_1707> no, I'm not
[18:02:24 CEST] <durandal_1707> i simply stated few facts about patch
[18:05:20 CEST] <nevcairiel> some people have social skills, and some are falled paul, what can you do
[19:30:22 CEST] <durandal_1707> someone please ban nevcairiel, he insulted me
[19:44:39 CEST] <durandal_1707> mkver: you are genius! fixing bugs like that very fast
[19:51:02 CEST] <cone-264> ffmpeg 03Andreas Rheinhardt 07master:eb33be188d2a: matroskadec: Fix overflow introduced in a569a7b3
[21:14:50 CEST] <kierank> durandal_1707: have vote
[21:16:10 CEST] <durandal_1707> vote opened: ban kierank!
[21:16:11 CEST] <durandal_1707> +1
[21:16:18 CEST] <durandal_1707> voting closed
[21:16:40 CEST] <kierank> I will ban myself so you cant ban me
[21:16:41 CEST] <kierank> Ha
[21:18:13 CEST] <kierank> YOU LOSE
[21:20:29 CEST] <Lynne> Not so fast, there's always a turn left to buy out the city states
[21:39:01 CEST] <thardin> i thought kierank was well-connected, sounds dangerous
[21:39:47 CEST] <kierank> In the pub at the moment
[21:39:56 CEST] <kierank> Well on the way to the pub
[21:40:16 CEST] <thardin> already got myself an ipa
[22:03:12 CEST] <durandal_1707> i f* hate modern tech
[22:03:32 CEST] <durandal_1707> exp smartphones with android
[22:12:00 CEST] <thardin> computers were a mistake
[22:20:15 CEST] <iive> computers were not a mistake. giving it to regular people is the real mistake ;)
[22:26:29 CEST] <thardin> ah but you see then you have to draw a line somewhere
[22:57:57 CEST] <cone-432> ffmpeg 03Michael Niedermayer 07master:e131568752ad: avcodec/alsdec: Fixes invalid shifts in read_var_block_data() and INTERLEAVE_OUTPUT()
[22:57:57 CEST] <cone-432> ffmpeg 03Michael Niedermayer 07master:51f6870c37cc: avcodec/alsdec: Fix undefined behavior in decode_rice()
[22:57:57 CEST] <cone-432> ffmpeg 03Michael Niedermayer 07master:a3bd4b260eb9: avcodec/alsdec: Fix integer overflow with shifting samples
[22:57:57 CEST] <cone-432> ffmpeg 03Michael Niedermayer 07master:0794494c8f2f: avcodec/alsdec: Check opt_order / sb_length in ra_block handling
[22:57:57 CEST] <cone-432> ffmpeg 03Michael Niedermayer 07master:7f527021df73: avcodec/alsdec: Fixes signed integer overflow in LSB addition
[22:57:57 CEST] <cone-432> ffmpeg 03Michael Niedermayer 07master:5f64f6058e0c: avcodec/alsdec: Fix integer overflow with buffer number
[22:57:57 CEST] <cone-432> ffmpeg 03Michael Niedermayer 07master:b7b6ddd59693: avcodec/alsdec: Add FF_CODEC_CAP_INIT_CLEANUP
[00:00:00 CEST] --- Sun Jul 7 2019
1
0
[00:08:32 CEST] <Hello71> >Windows is stupidly slow
[00:08:34 CEST] <Hello71> I concur
[01:20:55 CEST] <ncouloute> ffmpeg is encoding the wrong frame of video. Even when I use a frameserver like avisynth. It is giving me the frame of video from the previous scene. Anyway around this or to figure out whats going on? Using +flags2 showall + encoding to TS will work but then that file will be vfr. Trying to convert that file to cfr causes the same issue. So I'm stuck.
[02:02:37 CEST] <ncouloute> Interestingly enough if I seek to where the scene begins. It shows the proper frame. It appears like it gets confused when the scene changes.
[04:46:29 CEST] <Saccarab> which videocodec should I use to convert mp4 to avi format so my output works in windows media player
[05:16:02 CEST] <kepstin> ncouloute: not sure what you mean by "wrong frame" - what command are you running?
[05:16:39 CEST] <kepstin> ncouloute: note that if you're converting to cfr by using "-vf fps=XX" or "-r XX" output option, then it will drop or duplicate frames to maintain timing.
[05:19:57 CEST] <ncouloute> So I looked at the original side by side with the converted file and I got a frame of the previous scene instead of what the current frame is suppose to be. I do use fps filter and -r but issue happens regardless.
[05:21:35 CEST] <ncouloute> This is the only command that works but it makes a vfr file that I can't get to cfr without the frame order beeing messed up:
[05:21:37 CEST] <ncouloute> ffmpeg.exe -flags2 showall -copyts -copytb 1 -i "input" -c:v h264 -vsync passthrough -bsf:v h264_mp4toannexb -f mpegts -y "output"
[05:23:05 CEST] <ncouloute> but yeah I have to use one of those commands in order to get it to cfr ? -r or -fps
[05:27:57 CEST] <ncouloute> I even tried to feed it to x264.exe doesnt matter which encoder I use... So I think its a decoder issue.. So I went with the avisynth route.. but even that is showing the wrong frames once I tried to encode it. just playing the avisynth file is okay. hwaccel cuvid works but I dont want to use a gpu decoder.
[05:40:47 CEST] <ncouloute> The video file is in sync but it is showing the wrong frames.. thats the strange part. I get a few "reference picture missing during reorder missing reference picturem default is x" errors. So I'm thinking it is recovering to the last scenes reference frame. Although that doesnt explain why avisynth version also doesnt work...
[05:56:33 CEST] <ncouloute> Any ideas? I'm thinking I'm going to have to try and make sense of the debug_ts output.
[06:26:12 CEST] <ncouloute> welp im going to pick this back up tomorrow. I feel like I'm getting somewheer though digging into the debug_ts
[08:11:07 CEST] <lavaflow_> does FFmpeg have anything for beat detection? maybe an audio filter that could be made to output instantanous beat frequency?
[09:00:13 CEST] <jajaja> is there a way to change order of subtitles in video file?
[09:20:06 CEST] <clarkk> I'm trying to concat 3 mp4 files using ffmpeg. When I watch the final video, the first one is fine, but the second one is a black screen with audio, when I use -c copy, and stuttery and badly out of sync when I don't use -c copy. Could someone suggest what I can do to workaround this? Thanks
[09:23:19 CEST] <clarkk> the separate videos play fine in vlc
[09:33:55 CEST] <clarkk> don't worry - I used kdenlive instead
[11:36:18 CEST] <ossifrage> Anyone know what are the magic things that are needed to get --enable-ffmpeg to build ffmpeg? On my target I'm only using ffmpeg for (de)muxing, so I've turned most stuff off.
[11:36:51 CEST] <ossifrage> I tried turning --enable-ffmpeg on, but it seems to have some other hidden option deps
[11:41:28 CEST] <c_14> ossifrage: avformat, avcodec, avfilter, swscale, swresample should be it iirc
[16:31:00 CEST] <ossifrage> c_14, I'm building avcodec, avformat and avutil, but none of the encoder/decoders are enabled, just a collection of muxers and demuxers
[16:32:56 CEST] <ossifrage> I took quite a few trys to get things to build with this minimal config, but I made the mistake of not including ffmpeg
[16:47:58 CEST] <kepstin> configure script just says it needs avcodec, avfilter, avformat (and the recursive deps of those, which is basically just avutil).
[16:49:16 CEST] <kepstin> (you should be ok to disable all the filters in avfilter, I think the configure script wil re-enable the required ones)
[17:41:55 CEST] <linext> is it possible to allow errors in recording a network video stream?
[17:43:39 CEST] <linext> sometimes if i walk in from of the antenna of my hdhomerun, the video stream gets interrupted
[17:43:51 CEST] <linext> ffmpeg stops recording
[17:46:14 CEST] <linext> i'd rather it wait until there's a usable block of video and append to the file
[17:51:25 CEST] <tdr> linext, may need to loop it to restart if it dies when it fails
[17:52:27 CEST] <linext> tdr, how about this? -err_detect ignore_err
[17:53:56 CEST] <linext> if i wrote a program to restart ffmpeg, can ffmpeg append video to an existing file?
[17:54:19 CEST] <tdr> what type of output file
[17:55:02 CEST] <linext> mkv from an atsc stream, mpg2 video and ac3 audio
[17:59:33 CEST] <tdr> i dont see an "append" .. you could incriment a variable when it restarts file1.mkv file2.mkv ... then concat them when its over
[18:01:34 CEST] <linext> tdr is there a way to prevent ffmpeg from closing even if it encounters a stream error?
[18:03:02 CEST] <tdr> not familiar with how to do that
[18:09:59 CEST] <Thomas_J> Is guile required to build Nettle?
[18:16:23 CEST] <JEEB> sounds like you're building something once again provided by your distro?
[18:16:34 CEST] <JEEB> since at least most people install it from package management
[18:18:43 CEST] <Thomas_J> I'm trying to build ffmpeg from scratch. I want to include libtls for rtmps. To build libtls, I need hogweed present which is included in Nattle which needs libgmp. Without it, Nattle will build but it will not include Hogweed. I noticed while building Nattle that it said that guile is not present. Is Guile actually used in building Nattle?.
[18:19:15 CEST] <Thomas_J> The package available in the raspbian repository is incomplete.
[18:20:24 CEST] <Thomas_J> I wish so much that I could just use apt install and end up with a package I can use.
[18:24:37 CEST] <Thomas_J> Bottom line is that Libhogweed is already installed with a couple of versions but when I try to compile libtls it can't find it.
[18:25:27 CEST] <another> so you're building all dependencies as well? any particular reason?
[18:26:06 CEST] <tdr> Thomas_J, so you're building on/for a pi? which model
[18:29:13 CEST] <Thomas_J> The Raspberry Pi3 B+. This is my working model but if it proves to need more CPU, I will move it to a Rock Pi4 B.
[18:30:23 CEST] <Thomas_J> The Rock PI 4 B looks like it will make an excelent engine for a DVR.
[18:30:44 CEST] <tdr> hrm, i just checked nettle-3.5.1 and it didnt seem to check for guile
[18:31:00 CEST] <tdr> oh you said nattle, let me look fo rthat
[18:31:46 CEST] <tdr> oh it is nettle not nattle
[18:32:22 CEST] <Thomas_J> Sorry, I used to date a girl called Nattle.
[18:32:23 CEST] <tdr> Thomas_J, cant imagine you'd need to compile things like tls
[18:33:57 CEST] <tdr> you prob have a net-libs/gnutls package
[18:34:14 CEST] <tdr> and a dev package of it if you needed to build against it
[18:35:53 CEST] <Thomas_J> Bare minimum, I need an ssl/tls engine for rtmps. The raspbian build includes openSSL but it's prebuilt ffmpeg package doesn't have any ssl/tls library in it.
[18:36:56 CEST] <Thomas_J> As long as I have to build ffmpeg myself, I want to use libtls.
[18:38:42 CEST] <tdr> nettle-dev should be in your repos somewhere too
[18:46:26 CEST] <Thomas_J> nettle-dev is already the newest version (3.3-1). Complie for libtls shows Libhogweed (nettle's companion library) 3.4.1 was not found
[18:47:17 CEST] <Thomas_J> Could this be a version error
[18:48:01 CEST] <tdr> ok that sounds like it is expecting a "testing" version of nettle
[18:48:41 CEST] <tdr> its weird tho, 3.4.1 is the oldest version available for me, with 3.5.1 on testing
[18:49:08 CEST] <tdr> so maybe a very new source code you are attempting to build and a dated OS platform
[18:51:30 CEST] <ossifrage> kepstin, yeah, it looks like the configure script doesn't quite get the deps right
[18:52:02 CEST] <Thomas_J> Debian is always at least a year behind in their repositories.
[18:52:15 CEST] <tdr> Thomas_J, not all branches etc.
[18:52:31 CEST] <tdr> you almost make me want to pull my pi out and flash it and see... but i wont
[18:53:15 CEST] <Thomas_J> I just did a update and I still get 3.3.1 as the latest.
[18:53:58 CEST] <Thomas_J> That's why I am always going to the source website to get the latest stable.
[18:54:00 CEST] <tdr> you have an old version of it then
[19:06:33 CEST] <Thomas_J> I just tried removing the apt installed version of Nettle and running the build over again. The pat version installed the .so files in /usr/bin. My compilation places the ".so"s in /usr/local/bin.
[19:06:58 CEST] <Thomas_J> But it doesn't build libhogweed.
[19:08:49 CEST] <Thomas_J> Which gets me back to why is it not finding libgmp?
[19:09:32 CEST] <Thomas_J> the Config says that it is to use mini-gmp
[19:09:40 CEST] <idlus> Hi, I just noticed the optional @id part of filter descriptions, what is it used for?
[19:10:01 CEST] <DHE> .so files normally go in */lib[64] not in the same directory as the main executable
[19:11:53 CEST] <Thomas_J> The Raspbian build doesn't use a seperate lib64 directory as a normal build there is only /lib subdirectoried as if it was a 32 bit build.
[19:13:25 CEST] <Thomas_J> Have to think about this.
[19:16:54 CEST] <Thomas_J> The Arm7 is a 64 bit processor. I just assume that the Raspbian fork off of Debian stretch is also a 64 bit OS> Could I be trying to compile against a 32 bit version of Debian?
[19:36:26 CEST] <Thomas_J> Ouch! I just found out that my assumptions are incorrect. Raspbian is a port of Debian32, not 64. I have to go back to ground zero to figure out what needs to be adjusted.
[19:37:52 CEST] <Thomas_J> That's probably why all the packages in their repository are not up to date.
[19:38:19 CEST] <furq> yeah armv7 isn't 64-bit
[19:39:23 CEST] <furq> but also the bcm2837 is armv8
[19:41:12 CEST] <Thomas_J> Arm7 is supposed to be a 64 bit processor. there is a long thread in the Raspburry Pi forums about why Raspbian is still 32 bit when their processors are the 64 bit Arm.
[19:42:39 CEST] <furq> well it isn't 64-bit
[19:42:51 CEST] <furq> armv8 is 64-bit and the pi 3 has an armv8 cpu
[19:43:32 CEST] <furq> you probably want to install a proper aarch64 distro on there
[19:46:31 CEST] <furq> it'll probably be quicker in general but also aarch64 distro packages will probably be compiled with the accelerated aes/sha stuff
[19:58:10 CEST] <Thomas_J> I stabd corrected. Arm7 is 32 bit. When I got into using rPIs, The docs and conversations were still floating around talking about the Broadcom Arm7 processor, yet my first pi was a 64 bit processor. So, I guess that explains my confusion and while looking for proper packages, the 64 bit ones support the Arm8.
[20:01:16 CEST] <JEEB> Thomas_J: I think officially even rpi4 is still pretty much 32bit because they had issues with some of the hw decoding stuff?
[20:01:25 CEST] <JEEB> so while the CPU is capable of aarch64, it's all armv7
[20:01:55 CEST] <JEEB> rpi3 was also aarch64 capable but that was also "fun" to set up
[20:05:23 CEST] <Thomas_J> The nice thing about the PIs is that they run Linux OSs which make it fast to prototype with. The Rock Pi4 B (not Raspburry) can be ordered with as much as 4GB memory and can run a 2TB SSD drive directly.
[20:05:47 CEST] <JEEB> welcome to why almost everything uses ARM SoCs nowadays
[20:05:56 CEST] <JEEB> they all more or less come with linux kernel sources
[20:06:07 CEST] <JEEB> albeit not all of them can be booted with a vanilla kernel
[20:06:24 CEST] <idlus> I found in the doc that @id can be used with zmq, is it the only instance where it is useful?
[20:06:39 CEST] <JEEB> @id ?
[20:06:57 CEST] <idlus> in a filter description
[20:07:03 CEST] <JEEB> ah, filter description
[20:07:39 CEST] <JEEB> right, by default you get that stuff somewhat generated with a postfix number I think?
[20:07:47 CEST] <JEEB> if you do -v verbose the filter chain generation is logged
[20:08:07 CEST] <JEEB> (in the command line app, otherwise you'll just have to bump up the log level in the API)
[20:08:12 CEST] <Thomas_J> They will never catch up with a full blown state of the art processor such as the i7 9th gen processor but they are now as powerfull as my i7 laptop I still use I purchased 9 years ago.
[20:08:38 CEST] <idlus> JEEB: all right, but I was wondering what it was used for, I only found zmq from the documentation
[20:09:01 CEST] <JEEB> idlus: I guess it could be useful if sharing an instance? I'm really not sure
[20:10:05 CEST] <JEEB> I've used the API for creating filter chains and there you give a name as one of the parameters (avfilter_graph_create_filter)
[20:10:40 CEST] <idlus> ok, so it isnt really relevant from the CLI
[20:11:26 CEST] <JEEB> I don't think two invocations of the same filter lead to the same instance being utilized so I'd *guess* it's just in case you want to see an exact string in the logging
[20:11:40 CEST] <JEEB> or if you want to utilize the same instance or something, if that even is possible?
[20:12:19 CEST] <idlus> I was wondering that, if it could be used for optimisation
[20:12:27 CEST] <idlus> anyway thanks for the insights
[20:12:33 CEST] <JEEB> idlus: right, zmq because you want to pre-know the names of filters
[20:12:37 CEST] <JEEB> or well, the instances
[20:12:47 CEST] <JEEB> and you're sending commands to specific filters
[20:12:53 CEST] <JEEB> or well, instances of them
[20:13:06 CEST] <idlus> yes I figured that use case
[20:13:08 CEST] <JEEB> in most cases indeed it doesn't really matter how it's called :)
[20:13:23 CEST] <JEEB> since you define in complex filter chains the names of input/output things
[20:13:37 CEST] <JEEB> and in normal filter chains they're implicit
[21:37:37 CEST] <Thomas_J> SO, I have a 32 bit OS running on a 64 bit processor which version of nettle should I use, 32 or 64?
[21:38:14 CEST] <tdr> if your userland is 32 bit you need 32 bit (and prob cant even build 64)
[21:38:17 CEST] <DHE> the OS being 32 bit means you must use 32 bit software. always.
[21:40:59 CEST] <JEEB> raspbian should have its own nettle etc development libraries (SOMETHING-dev), and I don't think there's a choice in raspbian (yet)
[21:41:11 CEST] <Thomas_J> That's what I was thinking but Iit is sooo confusing when my attempt to compile the 64 bit version was effectively looking like it was working other than not finding it's dependencies.
[21:43:58 CEST] <Thomas_J> I can't seem to use them with a current compile. libtls is looking for a newer version of hogweed than whT apt installs. ???Where did the epsum-lorum come from???
[21:44:25 CEST] <JEEB> you seem to be way in the woods by now, sorry for my French
[21:44:29 CEST] <JEEB> *pardon my French
[21:44:52 CEST] <JEEB> you might want to start with what you want to achieve and on which system
[21:45:01 CEST] <JEEB> and then the path there can be looked at :P
[21:45:20 CEST] <Thomas_J> Ohhh lol, That was you? there was no <JEEB> in front of it.
[21:47:57 CEST] <Thomas_J> I have a working ffmpeg command now working on my dedicated server al-be-it I haven't tested rtmps on it yet. I am now trying to achieve the came thing in the RPi where it is supposed to be launched in.
[21:49:16 CEST] <JEEB> ok, so if your rpi is running raspbian that will be armv7 and either built on the device or cross-compiled
[21:50:55 CEST] <Thomas_J> I am now going to do a fresh download and try a fresh install of the latest Nettle from the source once again hoping that it can find the apt install pf the gmp lib.
[21:51:42 CEST] <Thomas_J> of not pf
[21:52:14 CEST] <JEEB> uhhh
[21:52:19 CEST] <JEEB> why would you be compiling nettle etc
[21:52:33 CEST] <JEEB> it sounds like you have "found" a way somewhere, and it's going 45 degrees the wrong way
[21:52:37 CEST] <Thomas_J> I have Raspbian(32bit) running on an Arm8(64bit)
[21:52:53 CEST] <JEEB> effectively with raspbian you can 100% forget the fact that the CPU can do 64bit
[21:53:05 CEST] <JEEB> until they put 64bit kernel etc there :P
[21:53:15 CEST] <furq> you can't run anything 64-bit on a 32-bit kernel and libc
[21:53:18 CEST] <furq> it doesn't matter what the cpu can do
[21:53:27 CEST] <Thomas_J> As I said, the version in the Raspbian repos is to old to compile libtls against.
[21:53:48 CEST] <JEEB> ok, and why do you need libtls?
[21:53:54 CEST] <furq> for rtmps
[21:54:03 CEST] <JEEB> uhh, libtls is not that tls
[21:54:09 CEST] <JEEB> I think it's thread-local storage?
[21:54:13 CEST] <JEEB> or some other thing needed for compilers
[21:54:28 CEST] <JEEB> also FFmpeg's RTMP uses openssl and gnutls for TLS, not libtls
[21:54:50 CEST] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L271
[21:55:20 CEST] <JEEB> right, if you don't want to utilize gnutls or openssl. at this point libtls should be rather minor. it still doesn't explain why the person would want to compile it himself
[21:55:33 CEST] <JEEB> I'm trying to understand the /why/
[21:55:37 CEST] <Thomas_J> Because it is the prefered TLS agent and I don't trust openSSL. Don't ask me why, all tries to do rtmps with openSSL enabled hasn't worked for me.
[21:55:50 CEST] <JEEB> is it the preferred library?
[21:55:55 CEST] <JEEB> I don't think it is
[21:56:05 CEST] <JEEB> we as the FFmpeg project surely make no such assumptions
[21:56:36 CEST] <JEEB> the user can utilize gnutls, openssl or libtls or the library that ARM publishes
[21:56:57 CEST] <JEEB> mbedtls was the last one
[21:57:16 CEST] <JEEB> all of those wrappers in general are supposed to do the same thing
[21:58:33 CEST] <JEEB> they might have bugs but that's the general gist. and since FFmpeg (with GPL components) + openssl cannot be distributed most people utilize either gnutls, schannel (windows), securetransport (macos) or mbedtls (ARM embedded stuff)
[21:59:30 CEST] <furq> the debian ffmpeg builds have gnutls
[21:59:37 CEST] <JEEB> gnutls and openssl were the ones mentioned for async I/O I think when RTMPS was poked
[21:59:37 CEST] <furq> so i assume the raspbian ones do as well
[21:59:59 CEST] <JEEB> (there was a fix for those wrappers applied in like 2017 IIRC)
[22:00:28 CEST] <furq> https://www.johnvansickle.com/ffmpeg/
[22:00:35 CEST] <furq> these also have gnutls in case raspbian doesn't for some reason
[22:01:05 CEST] <JEEB> and yes, the armhf stuff there
[22:01:16 CEST] <furq> although these don't have the pi hwaccel stuff if you need that
[22:04:34 CEST] <Thomas_J> Three days ago when our convrsation was targeted to my trying to compile with librtmp because of not being able to get rtmps working, you mentioned that the later ffmpeg packages worked fine using libtls. I have since seen that the rtmp handler supplied in the ffmpeg package is librtmp. Then that is further confusing in that the ffmpeg docs have explicit instructions using the internal rtmp handler and then a separate entry for the libtls package commands.
[22:05:27 CEST] <JEEB> for the record I have never mentioned libtls because I had even forgotten that's how libressl's thingamajig was named :P
[22:06:01 CEST] <JEEB> I have mostly been mentioning gnutls and openssl in passing because back when looking at the log of changes there was a fix for both of them for the asynchronous I/O fixing RTMPS
[22:11:05 CEST] <Thomas_J> I could be mistaken. After the conversation we had that day I copied our conversation to gedit to save it because of all the good insights you gave. I backed off with what I was doing and used that conversation to formulate a new strategy. I finally throuth the gedit ppage away about 2 hours ago.
[22:14:49 CEST] <Thomas_J> OUCH! gnutls is what I was working toward, yes. I abandoned that because I found that libtls was already in ffmpeg. and I heve been moving forward with the wrong module from there.
[22:15:58 CEST] <Thomas_J> thinking libtls instead of gnutls.
[22:22:37 CEST] <Thomas_J> For the past several weeks I have been chasing rabbits down deep dark holes trying to get a version of ffmpeg that will stream trmps to Facebook. Since I,ve been here in the irc channel, I have found sanity. The ultimate problem will be that there is no help from Facebook. Therir support is only a collection of documents that tell you nothing unless you cross over to their developer's documents. That is another big rabbit hole to jump into.
[22:28:37 CEST] <JEEB> Thomas_J: anyways the stuff that furq linked could be your first quick check :P https://www.johnvansickle.com/ffmpeg/
[22:28:44 CEST] <JEEB> try the armhf binary there for master
[22:28:53 CEST] <JEEB> a) if it runs on your rpi
[22:29:09 CEST] <JEEB> b) check if you can make an RTMP and then RTMPS connection :P
[22:54:15 CEST] <Thomas_J> Okaaaay! I have a stream going to my server with armhf. Now to see if I can get rtmps working.
[23:49:15 CEST] <Lunchbox> is there a way to convert 60fps to 30fps with a blending filter that smooths out motion? i've tried to search for this but i've only found cases where people are trying to increase fps instead
[23:50:20 CEST] <Thomas_J> Just made a test stream @420p to my server on the internet and then played it played to copy that it made back without any frame dropping or appellation. It looks like I may be able to use the Raspberry Pi3 B after all. Next test is to use an IP camera as an rtsp input.
[00:00:00 CEST] --- Sun Jul 7 2019
1
0
[00:16:20 CEST] <rcombs> oh, they left
[00:16:39 CEST] <rcombs> I tried to add HEIF support a while back and ended up deciding it's impossible to reasonably integrate into lavf and gave up
[00:16:59 CEST] <rcombs> because the tiling is stupid
[00:17:22 CEST] <rcombs> it's container-level tiling of codec-level frames, I don't know how you'd sanely present that
[00:17:42 CEST] <rcombs> it's trivial to expose them all as separate streams, but then the API consumer has to stitch them
[00:18:07 CEST] <rcombs> and there's not really a reasonable way to expose the stitching metadata
[00:18:19 CEST] <nevcairiel> I would export them as one stream, one frame per tile, some stream metadata, and thats it for avcodec
[00:18:24 CEST] <nevcairiel> let avfilter then stitch it
[00:18:56 CEST] <rcombs> so avfilter buffers the frames and stitches them based on some opaque-to-user stream meta?
[00:18:59 CEST] <nevcairiel> definitely no stitching in avcodec
[00:19:03 CEST] <rcombs> or, I guess it doesn't have to buffer them at original res
[00:19:05 CEST] <nevcairiel> well not necessarily opaque
[00:19:21 CEST] <nevcairiel> could just be aome openly defined metadata
[00:19:25 CEST] <nevcairiel> which avfilter can consume
[00:19:31 CEST] <nevcairiel> or the user can if he is into that
[00:19:33 CEST] <rcombs> would that be a metadata string, or some sort of side-data attachment?
[00:19:41 CEST] <nevcairiel> sidedata i reckon
[00:20:05 CEST] <rcombs> I guess you could do a stream-level side-data for the overall res, and then a packet-level one for the coordinates of each frame
[00:20:13 CEST] <nevcairiel> i want to say stream level, but i already forsee that it needs to be frame level because someone makes that into more hten one image per container with different tiling setups
[00:20:33 CEST] <rcombs> yeah that's a thing you can do
[00:20:42 CEST] <nevcairiel> fuck those people that made that
[00:21:03 CEST] <rcombs> technically HEIF has a ridiculous number of features that nobody is likely to ever implement
[00:21:08 CEST] <jamrial> can each tile be decoded alone? avfilter expects raw decoded frames
[00:21:10 CEST] <rcombs> it's almost PSD-like
[00:21:14 CEST] <rcombs> jamrial: yes
[00:21:23 CEST] <jamrial> alright
[00:21:25 CEST] <nevcairiel> we'll make an open format thats so complicated that everyone will just pay us to use our implementation, instead of making it proprietary
[00:21:37 CEST] <rcombs> oh actually this is a bit tricky for the single-stream concept: they have separate extradata
[00:21:38 CEST] <jamrial> otherwise, it sounded more like the job for a bsf, that the demuxer can invoke
[00:21:51 CEST] <rcombs> I guess you could return annexb
[00:21:51 CEST] <nevcairiel> throw extradata updates into every frame
[00:21:57 CEST] <Lynne> yep, that's what I suggested, I did look into it and it seems possible
[00:21:58 CEST] <nevcairiel> the decoder wont be too happy but it should cope
[00:22:28 CEST] <rcombs> well, I've got code to parse this (and export separate streams) around somewhere
[00:22:34 CEST] <rcombs> I might give this a go again
[00:22:45 CEST] <nevcairiel> isnt that a GSOC project
[00:22:54 CEST] <nevcairiel> i have no clue if we even got accepted and have students
[00:23:03 CEST] <rcombs> idk I wrote it ages ago
[00:23:12 CEST] <jamrial> maybe that's _bluez
[00:23:16 CEST] <rcombs> and then realized the tiling shit is actually used in practice and gave up
[00:23:35 CEST] <Lynne> thankfully you can disable filtering across tiles in hevc (should really be enabled but obviously blocking artifacts are less important than making everyone's life a misery)
[00:23:57 CEST] <nevcairiel> well most gsoc projects are rather silly, but the people that run that will tell you that we shouldn't complain unless we can provide better ideas .. but the l ack of a better idea doesn't improve the ones they had :P
[00:23:59 CEST] <rcombs> idk why they decided to do container-level tiles, yeah
[00:24:19 CEST] <nevcairiel> I reckon container level tiles exist because in practice hevc decoders have s ize limits
[00:24:58 CEST] <nevcairiel> and decoding x tiles of size/x is a thing they can do, instead of just a frame of full size
[00:25:23 CEST] <nevcairiel> and effing digital camera resolution is going through the sky
[00:26:28 CEST] <nevcairiel> in any case that approach should be workable, and with any luck the decoder wont even need any changes, all in demuxing and filtering
[00:26:51 CEST] <rcombs> yeah, when I tested this out ages ago the individual tiles decoded just fine
[00:27:14 CEST] <rcombs> worst-case the decoder might need some tweaks to make sure the side-data gets passed along? but iirc generic lavc code handles that already
[00:27:22 CEST] <nevcairiel> yeah it should
[00:27:40 CEST] <rcombs> speaking of weird apple HEVC extensions, has anyone looked at the alpha thing yet
[00:27:46 CEST] <Lynne> I don't like the lavfi approach though, stitching them in the decoder would be better
[00:28:07 CEST] <Lynne> obviously a bsf would be the best since you could integrate that into lavf too
[00:28:26 CEST] <rcombs> idk how you'd do it in a bsf
[00:28:43 CEST] <nevcairiel> stitching in decoder would be a nightmare with hwaccel
[00:28:54 CEST] <philipl> That's also a problem.
[00:28:57 CEST] <jamrial> rcombs: the vps extension parsing is a bitch, and the decoder right now downright ignores spatial layers other than 0
[00:29:15 CEST] <rcombs> unless HEVC has some built-in tiling that's extremely compatible with this concept already
[00:29:38 CEST] <philipl> You want to do hw decode & display, you'd have to stitch in GPU side code too.
[00:29:41 CEST] <rcombs> (I know it has tiling but idk if it's close enough to this to reasonably convert between them in a bsf, and then I'd worry about hwaccel, yeah)
[00:29:59 CEST] <nevcairiel> AVIF uses the same tiling with another decoder
[00:30:07 CEST] <nevcairiel> doing it out of decoder gets us that basically for free
[00:30:15 CEST] <rcombs> oh fuck did AVIF actually pull this shit
[00:30:17 CEST] <jamrial> stitching in bsf, if possible, would introduce the decoding size limit nevcairiel mentioned
[00:30:30 CEST] <Lynne> if the tiling in hevc is sane (e.g. byte aligned and completely independent) it should just be a matter of rewriting the header and stitching the tiles
[00:30:33 CEST] <nevcairiel> AVIF is basically HEIF with AV1 without any limits
[00:30:52 CEST] <rcombs> someone asked me about that a while ago and I told them "HEIF is basically alright but it's way over-featured, and in particular the tiling shit is a nightmare and shouldn't be included"
[00:31:05 CEST] <rcombs> and I was hoping they'd take that advice
[00:31:07 CEST] <rcombs> sounds like not
[00:31:10 CEST] <nevcairiel> I didn't see any exclusions in AVIF
[00:31:52 CEST] <nevcairiel> the spec doesnt even contain a format spec, it directly refers to HEIF and just tells you what to set some fields to, like brand etc
[00:35:39 CEST] <rcombs> there's also the "thumbnail" feature
[00:35:47 CEST] <rcombs> which should probably be its own stream
[00:38:39 CEST] <rcombs> does HEVC tiling support overlap
[00:40:50 CEST] <rcombs> >NOTE: In the case of HEVC tile items, the tile information given in the SubSampleItem may match the information in the ImageSpatialRelationBox of a single tile, e.g. horizontal_display_offset (resp. vertical_display_offset ) may be set to ctb_x (resp. ctb_y), but this is not mandated. Especially, if an author wishes to assemble a composition of HEVC tiles from different HEVC images, there will be no relationships between the SubSampleItem and the Imag
[00:40:51 CEST] <rcombs> eSpatialRelationBox.
[00:50:32 CEST] <rcombs> Lynne: so, the BSF route would only work if HEVC tiles can overlap, each have separate headers, and also AV1's tiles meet those requirements
[00:50:50 CEST] <rcombs> if that's all the case then it seems like a reasonable route to take; otherwise I think it's gotta be the filter
[00:52:59 CEST] <rcombs> (most importantly, I don't want to do anything that could result in lavf creating a bitstream that's only readable by lavc)
[00:54:03 CEST] <Lynne> side data does tick that mark since any decoder can just ignore it and decode each tile as-is
[00:54:27 CEST] <Lynne> also each tile in heif would need to not contain any heif tiles
[00:55:26 CEST] <Lynne> and the tiling dimensions used in heif would need to be compatible with hevc's spec
[00:55:53 CEST] <Lynne> well, if it doesn't work there's always the option to disable hwaccel for heif and do the stitching in the decoder
[01:08:18 CEST] <rcombs> jamrial: re: alpha, I'd imagine the bulk of it will just be "store 2 copies of the context and do everything, including hwaccel, twice", but I wonder about VideoToolbox, which I _think_ has support built-in
[01:08:54 CEST] <jamrial> i think that's what we're doing for vp9 alpha
[01:09:30 CEST] <rcombs> oh also, is there an existing pixfmt for this?
[01:09:41 CEST] <rcombs> well, multiple for different bit depths
[01:09:44 CEST] <rcombs> 4204, I guess
[01:10:38 CEST] <rcombs> oh yup AV_PIX_FMT_YUVA420P and co
[01:10:58 CEST] <rcombs> might want a 3-planar format, NV12A or something
[01:11:50 CEST] <rcombs> (assuming it's easy enough to just short-circuit the entirety of chroma decoding for this& though that might be a bit trickier for hwaccels&)
[01:12:31 CEST] <rcombs> fortunately nobody's actually asking me for HEVC+alpha support at the moment
[01:12:53 CEST] <rcombs> so I'm mostly discussing it here to make sure we don't make any decisions around HEIF that would make HEVC+alpha support more difficult down the line
[01:21:59 CEST] <cehoyos> How is alpha stored in hevc?
[01:26:22 CEST] <cehoyos> Found it: The spec say that the alpha layer has to be 4:2:0
[03:47:07 CEST] <electrotoscope> Hi I'm wondering if there's anything I could do about the patch at https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245694.html that is in response to https://trac.ffmpeg.org/ticket/7947
[03:47:37 CEST] <electrotoscope> Should I just reply in the mailing list with the text "ping" apologies for my ignorance of proper procedure
[03:59:57 CEST] <jamrial> electrotoscope: yes, ping asking for one of the two versions to be applied, if no further changes are required
[04:01:15 CEST] <electrotoscope> thanks!
[05:53:55 CEST] <cone-591> ffmpeg 03Steven Liu 07master:a514244319ab: avformat/dashdec: fix code style in dash_read_packet
[06:38:01 CEST] <prem> hi
[12:55:27 CEST] <cone-209> ffmpeg 03Paul B Mahol 07master:0f39ef4db2b8: avfilter/vf_lut: fix regression with >8bit planar filtering
[13:16:26 CEST] <mkver> The IRC logs are working again. Who have we to thank for this?
[13:54:34 CEST] <BtbN> Probably the one who replied on the ML saying to look into it.
[13:56:46 CEST] <durandal_1707> you are so ignorant, i mentioned fflogger here multiple times
[13:57:08 CEST] <nevcairiel> did you fix it? no? then why should we thank you? :P
[13:59:53 CEST] <BradleyS> "you are so ignorant" <- i think everyone will appreciate you not communicating this way, personal attacks are not helpful
[14:00:40 CEST] <BradleyS> you contribute a lot of good code and are appreciated, there's no reason to engage this way
[14:02:02 CEST] <durandal_1707> i'm sick of seeking political correctness
[14:02:20 CEST] <BradleyS> it's not politically correct to avoid attacking people
[15:56:07 CEST] <durandal_1707> why i can't get dehum working with FFT? i'm desperate, this should be trivial, reduce magnitude of static tones
[15:57:23 CEST] <j-b> durandal_1707: buy a brain enhancer :)
[15:57:51 CEST] <j-b> (joke for the people hard to understand)
[16:01:13 CEST] <BradleyS> how are you approaching the problem? targeting 50/60 Hz and harmonics?
[16:01:43 CEST] <BradleyS> a simple notch filter with harmonics would work fine, and you could make it dynamic by measuring the persistence and amplitude of the static tones
[16:08:32 CEST] <Lynne> I'd bandpass it between 40 and 70 hz, autocorrelate to find the peak-peak distance, average that with the last frame's and filter around that
[16:32:22 CEST] <durandal_1707> BradleyS: i just try to locate magnitudes that hardly change across time (comparing previous and current frame) and then reduce it by some factor
[16:33:00 CEST] <BradleyS> i would certainly limit that to low frequencies
[16:33:06 CEST] <BradleyS> probably <= 250 Hz
[16:33:33 CEST] <durandal_1707> yes, i resample audio to 2048 rate, and than FFT that with 2048 FFT
[16:34:20 CEST] <BradleyS> autocorrelation is a great idea Lynne
[16:34:41 CEST] <BradleyS> in fact there are analog stereos from the 70s and 80s that do that for noise reduction in high frequencies
[16:35:20 CEST] <BradleyS> phase linear 1000 and 4000 come to mind
[16:36:02 CEST] <BradleyS> bandpass is more correct, but i would go wider, say 25-250 Hz
[16:36:17 CEST] <durandal_1707> then i filter out so only hum remain and than just do original source - detected hum
[16:36:33 CEST] <BradleyS> so, half mains voltage (50 Hz eur, 60 Hz north am) up to the 4th or 5th harmonic
[16:36:52 CEST] <durandal_1707> if works wonders with static sine audio source provided by ffmpeg
[16:37:18 CEST] <BradleyS> autocorrelate and reduce the fundamental frequency, then do the same for harmonics reduced
[16:37:37 CEST] <durandal_1707> idea is it must be 0 phase so i can output only removed hum
[16:37:52 CEST] <BradleyS> so if you find hum at 50 Hz and reduce by 12 dB, you should reduce 100 Hz by N dB (maybe 6), etc... out as many harmonics as you want
[16:38:36 CEST] <BradleyS> it's really common to have second harmonic hum, so here in north america 120 Hz is bad, sometimes ~240 can also be heard
[16:38:55 CEST] <durandal_1707> harmonics can be all way around - odd or even and at different strength
[16:38:58 CEST] <BradleyS> ideally you would allow to configure how many harmonics and how much to reduce those
[16:39:06 CEST] <BradleyS> cool
[16:39:30 CEST] <BradleyS> probably want to be able to adjust the Q also
[16:39:34 CEST] <BradleyS> (width of filter)
[16:39:34 CEST] <durandal_1707> there is one audio with hum at around 300hz
[16:39:51 CEST] <durandal_1707> no i can not use ugly IIR filtering
[16:41:01 CEST] <BradleyS> here's a visual example of a non-fft method using notch filtering https://imgur.com/a/2mBKeDW
[16:41:14 CEST] <durandal_1707> notch filtering is very limited
[16:41:33 CEST] <BradleyS> anyway, those settings give a lot of control even if you're doing fft, which should sound better
[16:42:31 CEST] <BradleyS> so i guess 4th harmonic for 60 Hz is 300 Hz, that's probably a decent limit
[16:44:58 CEST] <BradleyS> i guess one point i probably have not been clear enough on, is that once you identify the fundamental frequency of the hum, you can automatically filter the harmonics also without further analysis
[16:45:02 CEST] <durandal_1707> 300 is only one present in audio
[16:45:08 CEST] <BradleyS> which, given their signal will be lower, would be less accurate
[16:46:35 CEST] <taliho> /whois mkver
[16:47:35 CEST] <BradleyS> also, durandal_1707... you should upsample the audio to a sample rate with integer relationship
[16:48:21 CEST] <BradleyS> e.g. 48 kHz to 2304 kHz or whatever
[16:49:07 CEST] <durandal_1707> why?
[16:49:11 CEST] <BradleyS> less distortion
[16:50:06 CEST] <BradleyS> most daw use specialized post processing when downsampling also
[16:51:25 CEST] <BradleyS> (realistically, 16x oversampling might be enough)
[18:18:25 CEST] <Lynne> durandal_1707: btw you might make this work with FFT, but you'll need big framesizes (like 100ms or so) to get enough resolution on the bins to do certain frequencies
[18:21:08 CEST] <Lynne> probably even more, but a filter's the right thing to use here
[18:45:51 CEST] <durandal_1707> Lynne: you forgot that i resample audio to 2048 and that I need adaptive filter, fixed filter is of no use
[18:48:00 CEST] <dastan> does someone here know about VLC? i know they have their own channel but it look nobody answer there
[18:49:26 CEST] <dastan> is michaelni alive?
[18:49:48 CEST] <durandal_1707> please do not spam this channel with off-topic stuff, thanks
[18:50:16 CEST] <durandal_1707> also bunch of devs are already on #vlc
[18:50:59 CEST] <dastan> ok, so can we speak about HLS connections?
[18:51:08 CEST] <dastan> i have some buffer problems
[18:51:23 CEST] <dastan> and i dont know how to solve it
[18:52:02 CEST] <dastan> i am sking about FFmpeg
[18:52:05 CEST] <dastan> did i make spam again?
[18:52:54 CEST] <durandal_1707> best place to ask is via ffmpeg-user mailing list
[20:52:56 CEST] <durandal_1707> oh, now, instead of nonsense, i get echoed output for some reason
[20:53:35 CEST] <cone-179> ffmpeg 03Cameron Cawley 07master:dcf3f8b368cd: avformat/rpl: Fix detection of 8-bit linear formats
[20:53:35 CEST] <cone-179> ffmpeg 03Cameron Cawley 07master:1f8336fd985d: avformat/rpl: Allow a file to have audio, but not video
[20:53:35 CEST] <cone-179> ffmpeg 03Cameron Cawley 07master:0cbdedbd2fc2: avformat/rpl: Calculate the duration of the video track
[21:32:12 CEST] <cone-179> ffmpeg 03James Almer 07master:7c644989a5c2: avcodec/hevc_ps: fix range of num_tile_{columns,rows}_minus1
[22:21:26 CEST] <durandal_1707> should I use synthesis window also as analysis window?
[23:32:20 CEST] <Lynne> par?
[23:32:38 CEST] <durandal_1707> par par
[23:43:09 CEST] <Lynne> after some ridiculous amount of digging: "The par file demuxer is just some glue around a non-free library that I don't (yet) have permission to distribute."
[23:43:17 CEST] <Lynne> >ffmpeg-devel ML 2011
[23:44:34 CEST] <Lynne> guess it took them this long to finish it and they still don't distribute the library anyway
[23:45:40 CEST] <durandal_1707> what non-free library does?
[23:48:00 CEST] <nevcairiel> wtf does it modify 20 files for
[23:48:01 CEST] <Lynne> it's libparreader, and with the way its API looks it writes and reads super-secret bytes to make a valid par format
[23:48:12 CEST] <JEEB> hah
[23:48:30 CEST] <JEEB> just by these comments that seems like a winner :P
[23:48:58 CEST] <nevcairiel> the code looks horrible too, and its nonfree to boot
[23:49:11 CEST] <durandal_1707> NAK! NAK! NAK! NAK!!!!!!!!!!!
[23:51:59 CEST] <nevcairiel> if a single proprietary format needs 24 files and 7000 lines of code, and then still depends on an external library, wtf was someone that made it smoking
[23:53:12 CEST] <Lynne> the comment in admime_probe() is fun to read
[23:53:47 CEST] <JEEB> sounds worse than the current Nokia/DVB-H/"next gen broadcast" thing I'm poking at
[23:53:58 CEST] <JEEB> which also includes a lot of "I wish I smoked the same stuff the authors did"
[23:54:45 CEST] <Lynne> this is for some obscure cctv systems from what I read, so no doubt
[23:55:09 CEST] <JEEB> (and actual broadcast input reader module vendors seem to be nope'ing at this format and asking people to internally convert into MPEG-TS according to people who I've discussed with)
[23:55:18 CEST] <nevcairiel> why do such companies believe that a very broken proprietary format is the way to go
[23:55:30 CEST] <JEEB> very good question
[00:00:00 CEST] --- Sat Jul 6 2019
1
0
[00:05:50 CEST] <norbert> hi folks, which "-crf" value should I pick to get a result close to what YouTube provides (at HD) ?
[00:06:59 CEST] <norbert> I started off with 28, but decided the quality wasn't good enough, so I went to 25, but this still seems problematic
[00:07:38 CEST] <norbert> and I'm a bit scared that if I go really low the resulting files will be huge and take up way too much disk space
[00:20:40 CEST] <furq> 25 should be plenty if you're just aiming to match youtube
[00:20:54 CEST] <norbert> really?
[00:21:11 CEST] <furq> youtube 1080p30 is always ~3.5mbit
[00:21:15 CEST] <furq> which is not really very good
[00:21:51 CEST] <furq> obviously i wouldn't actually recommend 25 for archival but it'll look about as good as youtube 1080p
[00:22:49 CEST] <furq> i normally use 20 or 21 for hd but it's really just something you need to experiment with and find a value that works for you
[00:22:54 CEST] <furq> encode a short test clip or something
[00:23:46 CEST] <furq> also keep all the other settings the same because those will affect pq even at the same crf value
[00:37:57 CEST] <friendofafriend> I've got a bunch of silent h264 videos, and I want to cut the framerate in half without reencoding to save space. What's the proper command to use?
[00:38:19 CEST] <DHE> doing so doubles the duration
[00:38:37 CEST] <DHE> and doesn't save space
[00:39:27 CEST] <DHE> "don't reencode" and "save space" is only possible by "cutting"
[00:39:56 CEST] <friendofafriend> Sorry, so I'm after dropping every other frame.
[00:40:15 CEST] <friendofafriend> Say, from 24fps to 12fps.
[00:40:31 CEST] <DHE> that will break playback
[00:40:39 CEST] <DHE> reencoding is required
[00:41:37 CEST] <friendofafriend> That would break playback even in ffplay?
[00:41:52 CEST] <DHE> you can't just skip every other frame and get a video to play correctly
[00:42:11 CEST] <DHE> unless it's an intra codec or in intra mode (aka. every frame is a keyframe)
[00:42:19 CEST] <DHE> in which case I have suggestions to improve size
[00:42:32 CEST] <friendofafriend> Oh, I'd be losing keyframes. I think I understand.
[00:43:35 CEST] <BtbN> Every frame is used as reference
[00:43:38 CEST] <DHE> that's not what I said
[00:43:45 CEST] <BtbN> You can't just randomly get rid of some
[00:44:01 CEST] <DHE> I said the "drop every other frame" trick only works if every frame in the video is a keyframe. (or I suppose gopsize=2)
[00:44:24 CEST] <cehoyos> Or if every other frame is a non-ref frame...
[00:44:31 CEST] <cehoyos> Like B-frames often are
[00:46:10 CEST] <friendofafriend> Aw heck, oh well. I've got a board around here that does h265 encoding by OpenMAX, I guess I'll just feed these files into it.
[00:46:22 CEST] <furq> that's definitely not going to save space
[00:46:43 CEST] <furq> not without murdering the quality anyway
[00:46:43 CEST] <friendofafriend> No? Why not?
[00:46:53 CEST] <friendofafriend> Right, quality murder.
[00:47:01 CEST] <friendofafriend> But I'm going to end up doing that with a reencode anyway.
[00:48:03 CEST] <furq> if it's openmax then i assume it's some kind of sbc
[00:48:09 CEST] <furq> the hardware encoders on those are usually terrile
[00:48:10 CEST] <furq> b
[00:48:20 CEST] <friendofafriend> It's one of these Jetson Nano boards.
[00:48:22 CEST] <furq> at least all the ones i've used are
[00:49:03 CEST] <furq> oh, nvidia
[00:49:09 CEST] <furq> maybe that won't suck quite so badly then
[00:49:37 CEST] <furq> with that said even nvenc hevc is worse than a decent x264 encode
[00:49:53 CEST] <furq> and that's the best consumer-grade hardware encoder afaik
[00:50:02 CEST] <BtbN> Can't you use nvenc on those? Why OMX?
[00:50:27 CEST] <BtbN> nvenc hevc beats libx264 btw.
[00:50:40 CEST] <BtbN> (On Turing)
[00:51:08 CEST] <furq> x264 veryslow?
[00:51:33 CEST] <friendofafriend> Nah, there's no NVENC on those Jetson boards.
[00:51:34 CEST] <furq> i'll be impressed if it does
[00:51:50 CEST] <BtbN> their h264 encoder can compete with x264 veryfast
[00:52:03 CEST] <BtbN> hevc is quite a bit better
[00:52:42 CEST] <friendofafriend> Unfortunately, there's only support for gstreamer with NVIDIA's OpenMAX stuff.
[00:53:01 CEST] <BtbN> Can't install the normal nvidia driver on it?
[00:53:22 CEST] <friendofafriend> Oh not at all. There's no GPU on the PCI bus.
[00:54:13 CEST] <furq> i would guess it's some nvenc asic if it's an nvidia gpu
[00:54:18 CEST] <furq> just a different api
[00:54:28 CEST] <friendofafriend> It's device entries for CUDA, and a prebuilt static library for OMX GStreamer support. They don't supply the headers to build it from source.
[00:54:49 CEST] <furq> does it work with ffmpeg's omx stuff
[00:55:16 CEST] <friendofafriend> Unfortunately not. I did coax ffmpeg into using OMX on the Raspberry Pi, and was pretty happy overall.
[00:55:17 CEST] <BtbN> really makes me wonder why they bothered to implement yet another API just for that board
[00:55:48 CEST] <friendofafriend> I was hot to use it for hardware encoding video by NVENC with xpra, and ended up disappointed.
[00:56:00 CEST] <furq> i guess compat with tools that people use on other sbcs
[00:56:07 CEST] <furq> those great tools that everyone loves
[00:57:50 CEST] <friendofafriend> There's a slot for an M.2 wireless card, so I guess you could put a graphics card onto the bus if x1 was acceptable.
[01:02:24 CEST] <friendofafriend> You guys saved me lots of time. Thank you.
[02:29:18 CEST] <dastan> michaelni, are you online?
[04:45:15 CEST] <microcolonel> howdy
[04:46:30 CEST] <microcolonel> I have some footage that was deinterlaced poorly (I think just by combining the fields as 30p instead of 60i), is there a filter in ffmpeg for reversing that (restoring the alternating fields to 60i)?
[05:05:10 CEST] <furq> microcolonel: not in ffmpeg, but qtgmc will do it
[05:07:20 CEST] <furq> i guess you could also try separatefields if you want 60i output
[08:46:58 CEST] <lain98> i have a crude understanding of how video works. my application is extracting streams from a video file and then sending them to decode. is there a way i could alter rates in the stream such that when i decode, i decode at a different fps than the the one with which the video was encoded.
[08:47:56 CEST] <lain98> i'm using the libraries
[12:24:56 CEST] <DHE> lain98: not sure I understand the problem. decoding is largely independent of the framerate as long as you're receiving the data fast enough (ie. on disk you can read as fast as the hard drive can offer it). it's on the player to show each frame for the intended duration. you're welcome to mess with it yourself.
[12:34:30 CEST] <lain98> DHE: i imagine there is data in the stream that tells us when the present what frame ?
[12:34:38 CEST] <lain98> *to
[12:36:10 CEST] <lain98> i can see that in AVStream structure, theres time_base and duration and avg_frame_rate
[12:47:19 CEST] <DHE> time_base is the units that the pts values in AVPackets are in. If the value of time_base is {1,30} and the pts values go 1,2,3,4,5 then it's basically 30fps material
[12:47:59 CEST] <DHE> but some file formats might use a fixed time_base. eg: mpegts uses a fixed 90,000 value and at 30fps you would see the pts go 3000, 6000, 9000, etc.
[12:54:05 CEST] <lain98> DHE: is it possible to have a 30 fps video and rewrite the pts values, so that it might get 60 frames instead of 30 frames say if the video was only 1 second long
[12:54:30 CEST] <lain98> sorry if the question is dumb
[12:55:26 CEST] <lain98> so the frames might be duplicated when i decode
[12:56:13 CEST] <DHE> if you want the decoder to actually get duplicate frames, you will need to reencode in order to produce noop frames for the decoder
[12:57:31 CEST] <lain98> so essentially not possible before i transcode beforehand
[12:58:40 CEST] <lain98> you cant interpret a 30 fps video as a 60 fps video and produce more frames than encoded
[12:58:46 CEST] <DHE> it'll be on you to tweak the output time_base and the pts values going into the output file, and to feed the encoder the same AVFrame twice in a row with suitable pts values
[12:59:21 CEST] <DHE> some formats may support variable framerate. maybe you can set a time_base of 1/60 but feed pts values of 2,4,6,... don't know if that will report 30fps or 60fps though
[13:05:16 CEST] <lain98> i guess it cant be done after all
[13:06:36 CEST] <lain98> if i make it seem that the frames have timestamps that would be correct if the frame rate was double, no-op frames would be missing
[13:08:12 CEST] <lain98> and thats not even taking into account vfr
[13:19:19 CEST] <lain98> ~
[13:24:40 CEST] <lain98> thanks DHE
[15:43:38 CEST] <microcolonel> furq: it's a real dog's breakfast; terrible artifacts because of the bad deinterlacing, but also because it's been projected onto 720p... from.... 576 fields maybe
[15:44:01 CEST] <microcolonel> (artifacts from the codec struggling to maintain rate with merged fields)
[15:45:12 CEST] <furq> i've had good luck with qtgmc repairing bad deinterlacing but not that bad
[15:45:52 CEST] <furq> i don't know anything else that would give you a chance though
[15:45:52 CEST] <microcolonel> s/fields/lines/
[15:45:57 CEST] <microcolonel> yeah, it's not great
[15:46:15 CEST] <microcolonel> fun to poke at though, I'll probably document it if I managed to get a good result
[15:46:45 CEST] <microcolonel> maybe could roll it into a "reinterlace" filter.
[15:46:54 CEST] <furq> http://avisynth.nl/index.php/QTGMC#Progressive_Input
[15:47:13 CEST] <furq> These modes drop half the fields and recreate an interlaced stream from the others, which is then treated in the normal way.
[15:47:16 CEST] <furq> doh
[15:47:50 CEST] <microcolonel> hmm
[15:47:52 CEST] <furq> short of trying to resize it back to 576p and crossing your fingers i wouldn't know where to start
[15:52:13 CEST] <microcolonel> yeah, I'm going to try it like this: a) linear vertical-only resample at 576 lines b) make two sequences with the alternating lines c) smear that across 576 lines again, and maybe blend a bit vertically d) reassemble it into an interlaced sequence both ways, and see if one looks good.
[15:52:59 CEST] <microcolonel> e) finally do the horizontal resample
[15:54:04 CEST] <microcolonel> vish me luck :- )
[17:17:10 CEST] <N4ppeL> hi
[17:17:22 CEST] <N4ppeL> ah. Now I can send messages :)
[17:19:01 CEST] <N4ppeL> so, I am struggling encoding a video from radiospectrometer data into a single-8-bit-channel. I understand there is no real gain in compression using "pure grayscale" over yuv420p, but since its going to be decoded on mobile devices it would be lovely not to have an additional 50% of zeroes in my decoded framebuffers
[17:19:37 CEST] <N4ppeL> is there any way to achieve this? or is the "solution" to just throw away the last 50% of data i get from the encoder..?
[17:20:50 CEST] <N4ppeL> using H.264
[17:20:56 CEST] <DHE> but the decoder will still want that data. and hardware decoders are often limited in the formats they support.
[17:21:59 CEST] <N4ppeL> ah yeah, sorry, I meant to throw away 50% data i get from the decoder (its all just 0 anyway)
[17:22:36 CEST] <furq> 33%
[17:23:35 CEST] <furq> x264 apparently has 4:0:0 support now but it doesn't look like ffmpeg supports it for libx264 yet
[17:23:52 CEST] <furq> but also i don't think hardware decoders would support that anyway
[17:23:55 CEST] <N4ppeL> furq, no. I get 150% of the data i actually need
[17:24:04 CEST] <furq> well yeah 50% of 150% is 33%
[17:24:09 CEST] <furq> or uh
[17:24:10 CEST] <furq> you know what i mean
[17:24:37 CEST] <furq> 8 bytes instead of 12
[17:24:53 CEST] <furq> ...bits
[17:24:55 CEST] <N4ppeL> ah yeah ok i see where you come frome
[17:25:13 CEST] <N4ppeL> hmm
[17:25:32 CEST] <furq> but yeah if you want to actually use mobile hardware decoders then you're probably stuck with 4:2:0
[17:25:36 CEST] <N4ppeL> so currently i am anyway using a sw decoder since on browsers HW decoding is only available through html5-video element which has its own problems
[17:25:55 CEST] <N4ppeL> but i assume 4:0:0 would probably also not be supported (now) by the js-decoder i am using
[17:26:01 CEST] <N4ppeL> if its not even supported by ffmpeg..
[17:26:12 CEST] <furq> it's just the encoder that doesn't support it
[17:26:15 CEST] <furq> i assume the decoder does
[17:26:41 CEST] <furq> but yeah it's not a commonly used feature
[17:27:00 CEST] <N4ppeL> I see
[17:27:05 CEST] <N4ppeL> well thanks
[17:28:01 CEST] <N4ppeL> would of course be nice to see the support somewhere in the future, but for now I guess I will just throw away the unnecessary part after decoding so framebuffers explode a bit less
[17:29:12 CEST] <furq> you could try piping to the x264 cli
[17:29:17 CEST] <furq> --output-csp=i400
[17:29:26 CEST] <furq> i'd be surprised if it decoded though
[17:31:01 CEST] <N4ppeL> there is a pix_fmt "gray" in ffmpeg
[17:31:13 CEST] <N4ppeL> but it gives me deprecation errors '=D
[17:34:39 CEST] <kepstin> presumably warnings, not errors? Might not be related, afaik the gray pixel format isn't deprecated
[17:35:18 CEST] <kepstin> but yeah, the libx264 wrapper on my ffmpeg lists support for gray and gray10le, I have no idea if it actually encodes 4:0:0 video if passed that, tho.
[17:35:34 CEST] <N4ppeL> warnings resulting in an "error when opening encoder"
[17:36:02 CEST] <kepstin> N4ppeL: you're gonna have to post the complete output of ffmpeg, not bits and pieces
[17:37:42 CEST] Action: kepstin takes a quick look at the ffmpeg libx264 wrapper source - yes, gray and gray10le are wired up to use x264's 4:0:0 support, assuming ffmpeg was compiled against a new enough libx264
[17:38:11 CEST] <N4ppeL> command and output are quite large since I am splitting a 4096x4096 into 85 512x512 videos
[17:38:30 CEST] <N4ppeL> maybe i can first try a simpler case.
[17:41:35 CEST] <N4ppeL> hm, the funniest line is (after 85times "deprecated pixel format used, make sure you did set range correctly") it says "No pixel format specified, yuvj444p for H.264 encoding chosen."
[17:42:01 CEST] <kepstin> that comes from the 'j' in the yuvj444p
[17:42:21 CEST] <kepstin> which is a deprecated way of indicating full-range rather than limited
[17:42:36 CEST] <kepstin> (but the replacement isn't finished, so the message is meaningless to end-users, please ignore it)
[17:43:19 CEST] <kepstin> that's not an error, and would not cause the encoder to fail to initialize
[17:43:21 CEST] <N4ppeL> ok, but I DID specify gray as format? and my ffmpeg does list "gray" as a valid format..
[17:43:35 CEST] <kepstin> N4ppeL: i need to see your complete command line to tell you what's gone wrong there
[17:43:43 CEST] <kepstin> probably you used the wrong option or used it in the wrong place
[17:44:26 CEST] <kepstin> note that if you have multiple outputs, you have to repeat all output options (including -pix_fmt) for all of them.
[17:46:10 CEST] <N4ppeL> i do? original command was "ffmpeg -y -framerate 25 -i %d.jp2 -filter_complex "[0]format=yuv420p, split=85[1_00][4_00][4_01] ......." which worked great although only once specified
[17:48:15 CEST] <N4ppeL> full command and outputs here: https://pastebin.com/CniBt1zz
[17:49:14 CEST] <kepstin> N4ppeL: ok, the issue is that you're setting high profile, but high profile doesn't support 4:0:0 sampling
[17:49:25 CEST] <kepstin> iirc you need to use high444 to get 4:0:0 support
[17:49:39 CEST] <N4ppeL> ohh
[17:50:22 CEST] <kepstin> hmm. but that said, there is something going on weird here, it *is* picking a 4:4:4 pix fmt
[17:50:40 CEST] <kepstin> N4ppeL: please check with "ffmpeg -h encoder=libx264" to make sure your x264 lists "gray" support
[17:51:57 CEST] <kepstin> hmm. i might be wrong about that profile req for 4:0:0 actually
[17:52:02 CEST] <N4ppeL> Encoder libx264 [libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10]:
[17:52:08 CEST] <N4ppeL> so here it does not
[17:52:26 CEST] <N4ppeL> ffmpeg -pix_fmts does list it
[17:52:31 CEST] <kepstin> N4ppeL: if 'gray' is not listed in that output, then you need to recompile your ffmpeg against a newer libx264 to get 4:0:0 support
[17:52:47 CEST] <N4ppeL> I see
[17:53:28 CEST] Action: kepstin checks wikipedia, which notes that monogrpme support *is* in the regular "high" profile
[17:53:33 CEST] <kepstin> monochrome*
[17:54:25 CEST] <kepstin> your ffmpeg version is really old too, you probably need a newer ffmpeg *and* a newer libx264
[17:54:37 CEST] <kepstin> I'd probably suggest downloading the linux static build and using that
[17:54:38 CEST] <N4ppeL> its 3.2
[17:54:57 CEST] <kepstin> current is 4.1...
[17:56:07 CEST] <N4ppeL> yes.. why did I get this old version? installation should not be this old
[17:56:34 CEST] <kepstin> because debian stable.
[17:56:45 CEST] <kepstin> iirc they do have backports available of newer versions
[17:57:03 CEST] <N4ppeL> anyway. I try to update and retry.. if its still not listed re-compile
[17:57:06 CEST] <JEEB> so many things depend on FFmpeg that they generally don't back-port newer versions unless they're ABI compatible
[17:57:25 CEST] <N4ppeL> i am not a linux user usually. but windows CMD has a command limit of 8192 chars :')
[17:57:49 CEST] <kepstin> the ffmpeg libs are usually parallel installable, so it shouldn't be an issue to backport the cli tool i think?
[17:58:49 CEST] <kepstin> and backports aren't installed unless you manually enable them
[18:25:05 CEST] <N4ppeL> hm, on deb-multimedia current version is 3.9 which doesnt list gray either. I will continue on Monday - thanks all for your support and suggestions
[18:25:20 CEST] <furq> N4ppeL: https://www.johnvansickle.com/ffmpeg/
[18:25:20 CEST] <N4ppeL> have a nice WE
[18:25:40 CEST] <N4ppeL> oh, thx :)
[18:25:49 CEST] <furq> it's much easier to just install that in ~/bin or /usr/local than risk ruining everything with backports or deb-multimedia
[18:26:09 CEST] <N4ppeL> still have to leave for an errand :P but yeah, thx
[18:47:24 CEST] <dastan> does someone here know about VLC? i know they have their own channel but it look nobody answer there
[18:53:48 CEST] <dastan> does someone know about ffmpeg HLS problems?
[18:53:56 CEST] <dastan> i get lot of buffer errors
[21:32:41 CEST] <r0x> Hello
[21:35:17 CEST] <dastan> hello r0x
[21:35:41 CEST] <r0x> I'm struggling to find an example of how to flip a video stream
[21:35:42 CEST] <r0x> .
[21:38:13 CEST] <durandal_1707> vertical or horizontal flip?
[21:38:20 CEST] <r0x> both
[21:39:04 CEST] <durandal_1707> use video filters, vflip and hflip
[21:39:27 CEST] <r0x> mmm, I'm using the libraries not the tool
[21:39:36 CEST] <r0x> so I'm looking for a snippet
[21:45:22 CEST] <r0x> https://ffmpeg.org/doxygen/4.0/group__lavu__video__display.html
[21:45:29 CEST] <r0x> This seems to be a good starting point
[21:45:41 CEST] <r0x> But I can't find an example :(
[21:59:31 CEST] <furq> https://www.ffmpeg.org/doxygen/trunk/filtering_video_8c-example.html
[23:21:30 CEST] <BtbN> oh god, -f concat on Windows is stupidly slow
[00:00:00 CEST] --- Sat Jul 6 2019
1
0
[13:44:09 CEST] <cone-116> ffmpeg 03Jun Zhao 07master:9269bccbb340: doc/muxers: fix docs format for DASH muxer
[18:45:28 CEST] <prem> can I do decoding as well as inference using ffmpeg?
[22:12:19 CEST] <_bluez> Hey! I am currently working on implementing tiles in HEIF format... can I get some advice regarding that?
[22:13:23 CEST] <_bluez> First question is should I set each tile to a different stream?
[22:14:03 CEST] <_bluez> Or is it possible to store the tiles as multiple frames in a single stream?
[22:14:48 CEST] <durandal_1707> arent tiles makking one big image?
[22:14:57 CEST] <_bluez> Yeah they are
[22:15:18 CEST] <_bluez> but first I have to decode them individually i guess
[22:15:34 CEST] <durandal_1707> then making multiple streams of it is bad
[22:15:44 CEST] <_bluez> How do I stitch them is another question in my mind...
[22:15:48 CEST] <Lynne> that's not a good solution at all
[22:16:05 CEST] <Lynne> better to just output each tile as a separate frame and let the decoder reconstruct them
[22:16:25 CEST] <Lynne> you'll just need some side data per-frame to tell the decoder what do it
[22:17:18 CEST] <Lynne> we already do this for interlaced streams for some codecs to produce 1 frame from 2 fields
[22:18:24 CEST] <_bluez> Lynne: Okay but how do I do that... can you elaborate a bit?
[22:18:46 CEST] <_bluez> what side data would that be?
[22:19:41 CEST] <Lynne> it should contain the final image resolution, the tile resolution, the tile pixel format and the tile location
[22:20:48 CEST] <Lynne> is there a very specific order in which tiles appear in heif files or are they random?
[22:22:16 CEST] <_bluez> for the samples I have (and a bit of research I did) it looks like they are sequentially arranged from left to right and top to bottom (8x6 grid)
[22:23:41 CEST] <JEEB> thankfully I think the HEIF spec is public
[22:24:05 CEST] <jdarnley> Why do lots of "recent" formats do that?
[22:24:09 CEST] <_bluez> we mentioned we already do something similar... could you tell me where? It will be helpful.
[22:24:34 CEST] <JEEB> well it's not exactly the same
[22:24:45 CEST] <JEEB> but we do wait for multiple fields in H.264
[22:25:02 CEST] <JEEB> so that we create a picture with two fields interleaved, even with PAFF coding
[22:25:07 CEST] <Lynne> _bluez: its similar but not exact, we check if the stream is interlaced, then check each frame's field indicator
[22:26:41 CEST] <Lynne> _bluez: to begin with, just create a new side data type in libavutil/frame.h and make the demuxer produce one frame per tile with the metadata
[22:27:18 CEST] <Lynne> the decoder part shouldn't be too difficult to do
[22:28:55 CEST] <_bluez> Okay I won't say I understood all of what you said but I think I have an idea
[22:29:09 CEST] <Lynne> another idea I've had would be to write a bsf which takes in segmented tiles and combines them to make a single avpacket with a standard tiled hevc stream
[22:29:30 CEST] <Lynne> but I'm not too familiar with the hevc bitstream to know if that's possible
[22:30:43 CEST] <Lynne> the decoder wouldn't need to be modified in that case and would be able to use slice threads
[22:32:38 CEST] <_bluez> do you mean combining all tiles into a single packet first and then decode it?
[22:34:29 CEST] <_bluez> Sorry if I am not making much sense here... still have to know more before I can.. m just starting now ':D
[22:34:31 CEST] <Lynne> yes, if the hevc spec is sane and defines that each tile needs to be aligned to the nearest byte it should be doable
[22:35:25 CEST] <_bluez> but i found somewhere that each tile is a seperate hevc frame and hence needs to be decoded first.. how far is that accurate?
[22:35:27 CEST] <Lynne> especially since we already have an infrastructure to parse and write hevc headers
[22:35:54 CEST] <Lynne> yes, but since each tile in a standard hevc stream is also independent there's no difference
[22:36:15 CEST] <_bluez> okay..
[22:36:35 CEST] <Lynne> for now you just need to write the side data type and make the demuxer output frames from tiles
[22:37:39 CEST] <_bluez> I am using av_append_packet to attach pics to each stream for now... am i doing it right?
[22:39:12 CEST] <_bluez> each attached pic is a tile... that is what i tried doing at first... maybe its not correct though
[22:42:43 CEST] <Lynne> yes, streams are a container level feature, codecs don't care (and they shouldn't) about stream indices and containers
[22:43:13 CEST] <_bluez> Okay, thanks!
[22:44:37 CEST] <_bluez> I'll try to do what you said...
[00:00:00 CEST] --- Fri Jul 5 2019
1
0
[15:54:08 CEST] <alexmarkley> i'm now running ffmpeg 4.1.3 (provided by rpmfusion), latest fedora 30 with updates
[15:54:51 CEST] <alexmarkley> i'm still getting a process hang when doing something like $ pasuspender -- ffplay -f alsa -i 'sysdefault:CARD=BRIO'
[15:55:03 CEST] <alexmarkley> doesn't seem to matter what input i select
[15:57:22 CEST] <alexmarkley> SIGINT / SIGTERM don't have any effect, have to use SIGKILL
[15:57:32 CEST] <alexmarkley> gonna see if i can track down debug symbols
[16:04:04 CEST] <BtbN> You have to send SIGINT 3 times in quick succession to force it down
[16:16:58 CEST] <alexmarkley> BtbN, thanks for the info there
[16:17:05 CEST] <alexmarkley> brb
[16:23:08 CEST] <alexmarkley> so i'm learning that it's apparently quite difficult to discern the quality and capabilities of a USB-C <-> USB A (3.1?) cable just by examining the outside of it
[16:23:55 CEST] <alexmarkley> hardware glitches are dramatically complicating my troubleshooting effort here...
[16:35:24 CEST] <alexmarkley> so it appears to be locked up at alsa.c:304: snd_pcm_drain(s->h);
[16:35:35 CEST] <alexmarkley> in ff_alsa_close()
[16:40:27 CEST] <alexmarkley> oh interesting
[16:41:08 CEST] <alexmarkley> it's definitely not libav, it's a bug in alsa-plugins-pulseaudio
[16:41:58 CEST] <alexmarkley> if i select an audio device which is (apparently) presented by alsa-plugins-pulseaudio, i can trigger the issue... but if i select a real hardware device i can't reproduce the issue
[16:48:13 CEST] <alexmarkley> so, surprise surprise, the mystery is finally solved: pa is a garbage fire once again
[16:48:25 CEST] Action: alexmarkley shrugs
[16:51:22 CEST] <kepstin> alexmarkley: ffmpeg can input directly from pulseaudio rather than the alsa emulation...
[16:51:40 CEST] <alexmarkley> kepstin, true, and i appreciate you pointing that out
[16:51:54 CEST] <kepstin> and yes, if you suspend pulseaudio then attempt to read from a pulseaudio device that would cause a deadlock
[16:52:02 CEST] <alexmarkley> the problem i was / am running into is that libav's pulse support has wildly uncontrollably latencies
[16:52:25 CEST] <alexmarkley> kepstin, yeah i figured the pasuspend deadlock out as a separate issue
[16:52:56 CEST] <alexmarkley> i can reproduce the full backtrace if you're interested, but it's working fine while reading from the device, and locking up inside the pulseaudio code during shutdown
[16:53:08 CEST] <Lynne> ffmpeg -f pulse -fragment_size 512 -channels 2 -wallclock 0 -i default gives me a reliable low latency
[16:53:33 CEST] <pa[m]> I resent being called a garbage fire.
[16:53:50 CEST] <alexmarkley> uh oh, no offense intended pa[m]
[16:54:03 CEST] <alexmarkley> unless you are the personal embodiment of pulseaudio :-P
[16:54:15 CEST] <alexmarkley> in which case, some very small amount of offense might be warranted ;)
[16:54:24 CEST] <alexmarkley> Lynne, i will have to give that a try
[16:55:20 CEST] <alexmarkley> i mentioned last night, i'm working on a program which depends on libav* for media in and out ( https://github.com/markleybros/yer-face if anyone is interested )
[16:56:55 CEST] <alexmarkley> so in my demuxing code, what i observed is that often, while performing av_read_frame() on a pulseaudio format context ( https://github.com/markleybros/yer-face/blob/a4a2ec4e6341ce105441cdb0769a32… ) the call will block for roughly 1200 milliseconds
[16:57:13 CEST] <alexmarkley> and i get back a huge audio chunk, but i want more frequent, smaller audio chunks
[16:57:52 CEST] <alexmarkley> so investigating THAT problem lead me to experimenting with ALSA which lead me to the lockup problem
[16:57:59 CEST] <alexmarkley> :-P
[17:00:49 CEST] <kepstin> alexmarkley: sounds like Lynne's suggestion -fragment_size is exactly what you wanted to adjust then. It's mentioned in the docs as affecting buffering latency in pulseaudio: https://www.ffmpeg.org/ffmpeg-devices.html#pulse
[17:01:04 CEST] <alexmarkley> yeah i think that sounds really promising
[17:01:25 CEST] <alexmarkley> i'll report back once i've chased down another smaller timing issue in my code
[17:03:10 CEST] <alexmarkley> (actually, harking back to an earlier conversational point, it was the pulse/pasuspend deadlock that first lead me to suspect i was inadvertently interacting with pulseaudio virtual PCMs instead of real PCMs)
[18:45:19 CEST] <alexmarkley> kepstin, Lynne, it looks like the fragment_size parameter may have had a significant effect and it's possible my issues with the pulse demuxer are gone
[18:45:31 CEST] <alexmarkley> still testing though
[20:38:28 CEST] <DanielTheFox> hello, where does -bufsize apply to? encoded video or decoded (raw) video side?
[20:39:22 CEST] <DanielTheFox> like, I have a video that targets 256 kbps and I set -bufsize 512k , will it wait two seconds between bitrate checks? or 16 seconds? or much less? (raw video is enormous)
[20:39:52 CEST] <DanielTheFox> (two video output seconds, not real seconds, unless encoding happened at realtime)
[20:50:57 CEST] <DHE> there's a virtual bucket of bits. when encoding, bits are drained from the bucket and written to file. the bucket is filled at a consistent 256k bits per second
[20:51:42 CEST] <DHE> or alternatively, a user with only 256k of bandwidth (assuming a pure video stream) would only need to buffer/cache for 2 seconds prior to being able to play the video cleanly
[20:52:07 CEST] <DanielTheFox> oh, ok
[20:52:09 CEST] <DanielTheFox> that explains my earlier issues
[20:52:11 CEST] <DanielTheFox> I set -bufsize too big
[20:53:01 CEST] <Thomas_J> What does this mean? "Unable to find a suitable output format for 'rtmp://127.0.0.1/live'
[20:53:01 CEST] <Thomas_J> rtmp://127.0.0.1/live: Invalid argument"
[20:53:32 CEST] <DanielTheFox> you can specify -f mp4 (or any container you want)
[20:53:44 CEST] <Thomas_J> Thanks
[20:53:45 CEST] <kepstin> Thomas_J: you'll typically want "-f flv" for rtmp
[20:53:47 CEST] <DanielTheFox> it has no extension, apparently ffmpeg wasn't able to guess
[20:54:18 CEST] <Thomas_J> I get i/o error with -f flv
[20:55:41 CEST] <Thomas_J> I get i/o error with -f mp4 also.
[21:01:11 CEST] <Thomas_J> ffmpeg i/o/error: https://pastebin.com/E4cVa2z0
[21:17:46 CEST] <kepstin> Thomas_J: looks like there's an issue where it can't connect to your rtmp server on localhost
[21:17:50 CEST] <kepstin> check server logs? :/
[21:19:02 CEST] <Thomas_J> you mean nginx log?
[21:28:32 CEST] <Thomas_J> My nginx logs: https://pastebin.com/YWv8Facn
[21:31:48 CEST] <kepstin> what are you using as an rtmp server? do you have the nginx-rtmp module set up?
[21:35:58 CEST] <Thomas_J> Yes. rtmp is the whole point of having nginx on this server. I use apache2 to host port 80.
[21:37:50 CEST] <Thomas_J> I've been using Apache for over 20 years and now I have to learn a new way of doing things. It has been a real struggle.
[21:44:10 CEST] <Thomas_J> IN nginx'x logs. the only entries that are valuable are the ones for this afternoon. I updated my config file a couple of hours ago. These logs don't show any queries from the local host.
[21:47:18 CEST] <kepstin> my guess is that there's a mismatch or configuration error in your nginx configuration for the rtmp endpoint.
[21:50:14 CEST] <kepstin> like, the last thing in your error log is a message saying it couldn't create the directory to store hls segments in :/
[22:05:59 CEST] <Thomas_J> Thanks for pointing that out. I have been trying to figure out what the root directory path is for nginx and how do I set the root. the ftmp module doesn't like the "root" command anyware in the rtmp {} config.
[22:07:23 CEST] <Thomas_J> And are you saying that the i/o error can be a result of being rejected by the receiving end?
[22:10:46 CEST] <Thomas_J> Also, I reloaaded nginx today. That log entry was entered yesterday. Why am I not seeing that error for today after reloading,
[22:11:44 CEST] <steve___> Thomas_J: these are nginx questions, try their channel
[22:12:38 CEST] <Thomas_J> ffmpeg i/o error can be a result of being rejected by the receiving end?
[22:15:38 CEST] <Thomas_J> Is there a list somewhere for error messages derived from interaction with the receiving end?
[22:20:28 CEST] <kepstin> well, i/o error's pretty much the only thing you'll see with rtmp
[22:20:42 CEST] <kepstin> since the usual error case is that the server just drops the connection on errors
[22:22:34 CEST] <Thomas_J> But it is good to know that this is in fact an output error as a result of not negotiating the ingest with the other end. and not a problem with my ffmpeg command line
[22:23:27 CEST] <Thomas_J> It gives me a place to start. So far I have been working blind in black boxes.
[23:05:14 CEST] <Thomas_J> Okay. I finely got nginz configured (not properly but it does run now) and my ffmpeg test string is rtmping to it. Thanks everyone for your help. I now have a start.
[23:06:04 CEST] <Thomas_J> It's the 4th and I am going AFK.
[00:00:00 CEST] --- Fri Jul 5 2019
1
0