Ffmpeg-devel-irc
Threads by month
- ----- 2026 -----
- 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
February 2019
- 1 participants
- 56 discussions
[01:07:45 CET] <rcombs> JEEB: I think I was wrong about closed captions not carrying language information
[01:07:53 CET] <rcombs> (or was it someone else who asked about that)
[06:05:43 CET] <kierank> JEEB: any idea if it's possible to overlay side data using ffplay?
[06:17:33 CET] <kierank> atomnuker: wow
[08:01:34 CET] <JEEB> kierank: sorry I've not used or generally looked at ffplay at all
[08:02:13 CET] <JEEB> rcombs: yea in theory us could have en/sp f.ex.
[08:50:54 CET] <cone-379> ffmpeg 03gxw 07master:4571c7c05d84: avcodec/mips: [loongson] mmi optimizations for VP9 put and avg functions
[10:05:57 CET] <JEEB> michaelni: for the record there's two fixes for your sub2video use case on the mailing list. I prefer https://patchwork.ffmpeg.org/patch/12159/ because it's not hard-coding zero as the initializer, but then there's https://patchwork.ffmpeg.org/patch/12142/ which just effectively sets the value to what that struct implicitly got initialized to before
[10:07:39 CET] <JEEB> and for debugging sub2video I've generally utilized this sort of debug logging https://github.com/jeeb/ffmpeg/commit/f1750f489be345f74525f7a2ad89e40c4d7e0…
[10:09:22 CET] <JEEB> I'm currently trying to figure out the least bad way of filtering a blu-ray PGS sample which could be then utilized for testing sub2video in this way :P
[10:09:45 CET] <JEEB> because I could just filter by PIDs but if the PCR is on the video PID then I have to keep the PCR there
[12:10:02 CET] <durandal_1707> YES!, I got basic decoding working without artifacts; no ASPX, so only up to 12k freqs are decoded
[12:10:37 CET] <JEEB> \o/
[12:10:42 CET] <JEEB> that is something already
[12:11:40 CET] <durandal_1707> but it is 0.7-0.9 speed :-)
[12:12:08 CET] <JEEB> that is one fancy codec
[12:12:13 CET] <JEEB> for audio that is
[12:12:16 CET] <durandal_1707> without FFT optimizations
[12:12:27 CET] <nevcairiel> naive FFT is just super slow
[12:12:33 CET] <JEEB> ah
[12:12:51 CET] <durandal_1707> with QMF filtering it would be even slower
[12:16:30 CET] <atomnuker> what do you mean qmf filtering?
[12:19:26 CET] <durandal_1707> Quardature Mirror Filter, filter that converts a PCM sample stream into two sample streams of half the input sampling rate, so that the output data rate equals the input data rate
[12:20:30 CET] <atomnuker> no, I mean is it like mp3?
[12:21:32 CET] <durandal_1707> AC-4 decoders employ a complex QMF analysis/synthesis filter bank pair to enable alias suppressed frequency-domain processing
[12:23:55 CET] <atomnuker> so after the fft? could have been worse
[12:26:20 CET] <durandal_1707> after IMDCT, also have silly companding code - should I implement that at all?
[12:27:31 CET] <durandal_1707> samples I have are very basic, single presentation + max 1 audio substream
[12:27:45 CET] <atomnuker> so the qmfs are optional?
[12:32:46 CET] <durandal_1707> nope, they are mandatory for ASPX
[12:37:57 CET] <atomnuker> right, reading the description makes it sound a bit like sbr
[13:18:46 CET] <durandal_1707> with what sizes our imdct works?
[13:21:30 CET] <durandal_1707> lol there were dolby atmos code on github, taked down before I could look
[13:22:02 CET] <JEEB> :<
[13:22:08 CET] <JEEB> (lol atmos)
[13:27:19 CET] <atomnuker> durandal_1707: only power of twos
[13:28:00 CET] <atomnuker> and even multiples of 15 for mdct15
[16:59:10 CET] <durandal_1707> i've got big headache working today, need to rest now...
[17:05:34 CET] <BradleyS> feel better
[18:03:08 CET] <cone-379> ffmpeg 03Martin Vignali 07master:a3f65f5e9fed: avcodec/proresenc_aw : fix sub_image_with_fill for interlaced encoding
[18:03:09 CET] <cone-379> ffmpeg 03Martin Vignali 07master:b38dd2d219c9: fate/proresenc_aw : add test for interlace and 444 encoding
[18:31:02 CET] <philipl> BtbN: You will merge the nvcc changes?
[18:36:07 CET] <BtbN> yes
[18:36:16 CET] <philipl> thanks
[18:36:20 CET] <BtbN> But I'm not done testing
[18:36:28 CET] <BtbN> And they will still be nonfree
[18:49:05 CET] <philipl> BtbN: sure. small steps.
[18:49:34 CET] <philipl> We'll need to continue arguing about is needed to enable kernels in lgpl builds.
[18:49:40 CET] <BtbN> My MSVC installation decided to dismantle itself, and I'd like to test that as well
[18:49:49 CET] <philipl> Sorry to hear :-)
[18:50:42 CET] <nevcairiel> speaking of that, this "load kernels externally" hack this guy keeps pitching is not really an acceptable solution to me, because if we can't find a way we're confident is within the license, that is only a way to circumvent our own license, and not a good idea
[18:51:11 CET] <BtbN> I hate it because it seems like the by far most user-unfriendly way of doing things
[18:51:27 CET] <BtbN> Like, having to pass a seemingly random file to your filter for it to do things...
[18:51:28 CET] <nevcairiel> that too
[18:51:45 CET] <nevcairiel> if we had a generic thing like "pass video through this cuda filter", loading an external filter would be fine
[18:51:58 CET] <nevcairiel> but something like yadif, which has a lot of support code and will never work out of the box, thats just bad
[18:52:20 CET] <BtbN> Yes, I'd be very open for a generic vf_cuda or something
[18:52:27 CET] <BtbN> that just takes in generic ptx files
[18:53:58 CET] <BradleyS> is there a timeline or roadmap for releases?
[18:54:08 CET] <BradleyS> curious when 4.2 is planned at the very least
[18:54:43 CET] <nevcairiel> there is a rough gap between releases thats targeted, but thats not being enforced very strictly
[18:55:42 CET] <nevcairiel> its supposed to be roughly every half year I think
[18:56:41 CET] <BradleyS> i guess i haven't followed closely enough to know, are point releases cut from master?
[18:56:49 CET] <nevcairiel> no
[18:57:01 CET] <BradleyS> okay, so master is next major then
[18:57:04 CET] <JEEB> yes
[18:57:06 CET] <nevcairiel> 4.1.1 is from the 4.1 branch, which only gets bugfixes backported
[18:59:24 CET] <BradleyS> right, i didn't notice a release/4.2 branch, what will that be based on?
[18:59:34 CET] <nevcairiel> master in a few months time
[18:59:50 CET] <nevcairiel> "4.2" is the major, not just 4
[18:59:51 CET] <nevcairiel> :)
[19:00:04 CET] <BradleyS> ah, okay, i should have said minor release not point
[19:00:12 CET] <BradleyS> thanks for the clarification
[19:00:16 CET] <nevcairiel> there is really no minor or major release
[19:00:22 CET] <BtbN> ok, it also works on msvc
[19:00:22 CET] <nevcairiel> we just make up numbers as we want
[19:00:39 CET] <BradleyS> no worries
[19:00:50 CET] <nevcairiel> ie. 4.0 wasnt that more impactful then 3.3
[19:01:06 CET] <nevcairiel> i think someone once tried to align those changes with soname bumps
[19:01:10 CET] <cone-379> ffmpeg 03Philip Langdale 07master:5f47bfd50ac4: configure: Add an explicit check and option for nvcc
[19:01:11 CET] <cone-379> ffmpeg 03Philip Langdale 07master:7debf4277c29: avfilter/vf_yadif_cuda: Switch to using ffnvcodec
[19:01:12 CET] <cone-379> ffmpeg 03Philip Langdale 07master:2544c7ea67ca: avfilter/vf_scale_cuda: Switch to using ffnvcodec
[19:01:12 CET] <nevcairiel> but not sure if that was strictly followed
[19:01:12 CET] <BradleyS> yeah, sort of a modified semver
[19:01:13 CET] <cone-379> ffmpeg 03Philip Langdale 07master:b4c9c09915de: avfilter/vf_thumbnail_cuda: Switch to using ffnvcodec
[19:01:14 CET] <cone-379> ffmpeg 03Philip Langdale 07master:114ead9735f2: configure: deprecate cuda_sdk dependency option
[19:01:15 CET] <cone-379> ffmpeg 03Timo Rothenpieler 07master:c775410f3183: configure: pass windows-path to nvcc whenever cygpath is available
[19:01:16 CET] <cone-379> ffmpeg 03Timo Rothenpieler 07master:85051febc62e: configure: update minimum required ffnvcodec versions
[19:01:34 CET] <BradleyS> handbrake does that also, we add features in minor releases but aren't too worried about breaking compatibility there
[19:01:57 CET] <BradleyS> the strictest semver interpretation says minor shouldn't have breaking changes but that's not entirely realistic
[19:02:15 CET] <JEEB> well, we have release branches that can have minor versions on their name. then further releases in that branch are always just back-ports of fixes
[19:03:06 CET] <BradleyS> yeah
[19:03:50 CET] <BradleyS> release/<major>.<minor> branch is effectively <major>.<minor>.x in handbrake
[19:03:52 CET] <BradleyS> same concept
[19:03:59 CET] <BradleyS> (just fyi)
[19:04:51 CET] <BradleyS> was just curious because some things in 4.2 will be beneficial for us, but needed to know what it's based on since we normally only update contribs for bug fixes when we're pushing out only bug fixes in a patch release
[19:05:19 CET] <BradleyS> so handbrake 1.2.x will stay on 4.1.x and 1.3.x when released will probably get 4.2 ;)
[19:09:31 CET] <philipl> BtbN: cheers.
[19:09:50 CET] <philipl> nevcairiel: agreed. For us to be comfortable with external loading, we'd need to be comfortable with internal loading.
[19:52:42 CET] <BtbN> Why are all the news sites reporting that OBS just now added nvenc support? oO
[19:53:46 CET] <nevcairiel> i didnt see that anyway, like w here?
[19:54:02 CET] <nevcairiel> anywhere*
[19:54:59 CET] <BtbN> https://www.golem.de/news/nvidia-turing-obs-unterstuetzt-encoder-der-geforc… (German) https://www.phoronix.com/scan.php?page=news_item&px=OBS-Studio-23.0-Released
[19:55:26 CET] <nevcairiel> i guess someone overhyped an update of the video sdk
[19:55:53 CET] <BtbN> They did add a nvenc code, but it only avoid a copy to system RAM and back to the GPU
[19:55:58 CET] <BtbN> nvenc support in itself isn't new
[19:56:05 CET] <BtbN> *add new
[19:56:16 CET] <nevcairiel> the news thing really says "nvenc support for turing enhancements"
[19:56:28 CET] <nevcairiel> but its totally overreported anyhow
[00:00:00 CET] --- Thu Feb 28 2019
1
0
[03:31:06 CET] <YellowOnion> How do I force the filter chain to do a rgb24 -> nv12 -> yuyv422p -> rgb24 conversion?
[03:32:54 CET] <furq> -vf format=rgb24,format=nv12,format=yuv422p,format=rgb24
[03:33:03 CET] <furq> i don't know why you'd want to do that but ok
[03:34:34 CET] <YellowOnion> I want to see the degradation of nv12 -> yuyv422p, and I just want the inputs and outputs as pngs.
[03:35:36 CET] <furq> just -vf format=nv12,format=yuv422p then
[03:35:49 CET] <furq> also there is no yuyv422p, there's yuyv422 and yuv422p
[03:36:44 CET] <YellowOnion> Yeah yuyv422
[03:37:07 CET] <YellowOnion> the output looks identical with that command.
[03:40:16 CET] <YellowOnion> I'm trying to debug this: https://github.com/CatxFish/obs-virtual-cam/issues/43
[07:43:58 CET] <ricemuffinball> i have a video file that was separated into 2, how do i join them back together into one file?
[08:58:31 CET] <goodgrief> Hi! I need to reduce noise in audio record. The length of audio is 5 seconds, it is human voice with white noise. Which ffmpeg filter should I use? I've tryed to read the documentation, but there are a lot of filters, so I'm confused. Please help.
[09:01:38 CET] <Umori> ricemuffinball: ffmpeg -i "concat:input1.ts|input2.ts" -c copy output.ts (https://trac.ffmpeg.org/wiki/Concatenate)
[09:01:48 CET] <ricemuffinball> that doesn't work
[09:01:54 CET] <ricemuffinball> already tried
[09:02:27 CET] <Umori> What error do you get?
[09:04:05 CET] <ricemuffinball> no error
[09:04:28 CET] <ricemuffinball> resulted/create file = just input1.ts
[09:04:32 CET] <ricemuffinball> resulted/create file = just input1.*
[09:07:06 CET] <Umori> Are the sources the exact same a/v codecs, resolution etc?
[09:07:06 CET] <Umori> Have yoi tried with the concat filter?
[09:11:34 CET] <Umori> goodgrief: I don't know much about ffmpeg audio filter but have you checked with audacity? If the white noise is present continuously and you can get a sample of it without the voice, you should be able to use the noise reduction feature.
[09:13:18 CET] <ricemuffinball> umori yes
[09:13:41 CET] <ricemuffinball> umori yes i did, that also created corrupted file without any errors
[09:14:58 CET] <goodgrief> Umori, yeah, I know how to do this in Audacity. But I have too many short audios with voice and white noise and I want to reduce noise programmatically - I want to create a Python script for this.
[09:17:50 CET] <goodgrief> Umori, this noise filter should be working like noise gate, not the noise reduction, which is based on the noise sample free of voice, as you adviced.
[09:28:10 CET] <th3_v0ice> How can I copy over the stream PID using the -map option? In my MPEGTS file with 5 programs and multiple streams I can use -map 0 to copy everything to the UDP output, but the stream PID's change. Is there a way to preserve them?
[09:29:11 CET] <th3_v0ice> Or maybe force FFmpeg to show the new PID's it created in the output file. Either will do the job.
[09:30:28 CET] <JEEB> there's some way of doing multiple programs in mpegtsenc.c
[09:30:41 CET] <furq> goodgrief: check the afftdn and anmldn filters
[09:30:49 CET] <JEEB> also the PID is the "id" of the stream so I'd think the thing is configurable
[09:31:38 CET] <furq> also the compand filter
[09:38:17 CET] <goodgrief> furq, thanks
[09:59:54 CET] <th3_v0ice> JEEB: Are you talking about API or FFmpeg binary? I only needed the stream PID's, programs are not relevant.
[10:04:29 CET] <JEEB> th3_v0ice: in the API it's the id field and I know that it can be set, so I would say it's highly likely that there's an option to either set them, or pass them
[10:06:44 CET] <th3_v0ice> JEEB: For this particular issue I am using the binary, not the API :)
[10:07:08 CET] <th3_v0ice> I am sorry if I didnt made that clear in my question.
[10:08:33 CET] <JEEB> well I noted that most likely ffmpeg.c has that capability as well, and if not you could make an issue about it :P (stream indexes are not set'able as far as I know, but I think IDs are?)
[10:12:29 CET] <th3_v0ice> There is actually -streamid option. Thanks for the help :)
[10:12:50 CET] <JEEB> ok, that's it then
[11:44:17 CET] <Marcin_PL> Hello, does audio AAC stream ripping via ffmped differs to server broadcast software from listening it via Winamp or something else?
[11:53:50 CET] <Accord> hey, I have a lot of mp4 files with both video and audio streams but if I add the duration field reported by ffprobe the resulting duration is different from the duration I get after concatenating all of the files
[11:55:28 CET] <Accord> so let's say I have v1, v2, v3 with durations reported like 5000, 5000, 5000 but after concatenating tem I get 15500
[11:55:59 CET] <Accord> any ideas on how to predict what the concat result will be and why this is happening?
[11:57:03 CET] <cslcm> Marcin_PL: the useragent will be different
[12:37:46 CET] <Accord> also ffmpeg -i doesn't report the same duration as ffprobe
[12:44:30 CET] <Marcin_PL> cslcm: may I fake useragent of ffmpeg somehow?
[12:52:15 CET] <cslcm> Marcin_PL: Yes, -user-agent switch. Google :)
[12:53:52 CET] <cslcm> Marcin_PL: To mimic winamp you probably want "WinampMPEG/5.80"
[13:02:52 CET] <Accord> ah, ffmpeg -i reports format duration
[13:05:13 CET] <Marcin_PL> cslcm: thank you very much, dunno why man ffmpeg and /agent returns nothing for me, but switch works. -user-agent is deprecated, now it's -user_agent but both works, thanks again.
[14:05:20 CET] <ichlubna> Hello, anyone has any experience with av_hwframe_ctx_create_derived? I cannot create any derived context of different device type than the source. Tried running FFmpeg/libavutil/tests/hwdevice.c but none of the tests works.
[15:47:33 CET] <jkqxz> ichlubna: What combination are you wanting to use?
[15:47:42 CET] <alex``> What mean -max_muxing_queue_size?
[15:48:23 CET] <jkqxz> ichlubna: The derived contexts are for interop cases, so it will only work where there is actually interop support.
[15:48:40 CET] <ichlubna> So there is no interop at all? :D
[15:49:12 CET] <jkqxz> Possibly not for whatever device you are using.
[15:49:29 CET] <ichlubna> I tried the libavutil/tests/hwdevice.c test with some (hopefully supported) combinations they prepared but none is working. I am using RTX.
[15:51:34 CET] <jkqxz> As in Nvidia? Noone has written any interop cases for that, though I think in theory it should be able to work with D3D11 at least.
[15:53:01 CET] <ichlubna> Hmm OK well I expected at least the vaapi and opencl to work like mentioned https://trac.ffmpeg.org/wiki/HWAccelIntro#OpenCL here
[15:57:38 CET] <jkqxz> Hmm, that should probably mention drivers. Only the Beignet OpenCL ICD for Intel is supported properly for VAAPI interop.
[16:00:02 CET] <ichlubna> I see OK, thanks for the help. I guess it cant be helped
[16:02:44 CET] <jkqxz> Yeah. Generally the interop methods are all different and each case has to be written/tested individually.
[16:04:27 CET] <ichlubna> OK I thought that some are working everywhere...I hoped :D
[16:06:44 CET] <ichlubna> Anyway thanks!
[17:34:01 CET] <richar_d> on my computer, the example on the wiki for converting a still image and audio file into a video suitable for uploading to YouTube (https://trac.ffmpeg.org/wiki/Encode/YouTube) (the third command) outputs a video that has 00:00:28.80 of silence at the end. the actual length of the audio track I specified is 00:03:46.80. can anyone else reproduce this?
[18:38:19 CET] <cfoch> hi
[18:38:33 CET] <cfoch> is it possible to remove silence at the end of an audio file with a single command?
[18:41:03 CET] <cfoch> I wonder if silenceremove with start_periods=-1 would work
[21:47:00 CET] <piotr> helo
[21:47:15 CET] <piotr> i need to convert files very simple
[21:47:52 CET] <piotr> i do ffmpeg -b:v 256k -i "$fileline" "$filetempconv"
[21:48:17 CET] <piotr> first is file.flac for example and other file.mp3
[21:48:25 CET] <furq> -b:v goes after the input filename
[21:48:39 CET] <furq> also with lame you should probably use -q:v 0
[21:48:41 CET] <piotr> yeah it tells me that
[21:49:36 CET] <piotr> so b is for bitrate and v ? is v option or somethign other?
[21:49:40 CET] <piotr> not sure i get the syntax
[21:49:52 CET] <furq> oh right yeah
[21:49:58 CET] <piotr> I know it's in man but at least simpole hint
[21:49:59 CET] <furq> it should be -b:a
[21:50:03 CET] <furq> bitrate:audio
[21:51:08 CET] <richar_d> the quality will be higher if you use variable bitrate (VBR) encoding
[21:51:24 CET] <piotr> better ? ffmpeg -i "$fileline" -b:a 256k "$filetempconv"
[21:51:31 CET] <piotr> richard and how would i do that ?
[21:51:42 CET] <piotr> im basically writing script to turn all non mp3 to mp3
[21:52:21 CET] <furq> piotr: replace -b:a 256k with -q:a 0
[21:52:31 CET] <piotr> than use mp3gain to have all same volume
[21:52:41 CET] <piotr> I see thankyou
[21:53:24 CET] <piotr> what does q and 0 stand for ?
[21:54:22 CET] <computron> Hey everyone, Looking to see if ffmpeg can do something and wondering if i am looking at the correct software for what i want to do. I have 2 Ip Cameara streams and an audio stream i would like to combine into a Sort of "picture in Picture steam" and then kick that out to a Single stream i can send to a streaming service is FFMPEG capable of this?
[21:54:25 CET] <furq> q is quality, 0 is specific to libmp3lame
[21:54:38 CET] <furq> in this case it does the same thing as lame -V0
[21:55:03 CET] <furq> fwiw if you're doing this for a phone you should probably use a more modern codec like aac or opus
[21:55:11 CET] <richar_d> piotr, https://trac.ffmpeg.org/wiki/Encode/MP3 " `-q:a 0` is the highest quality
[21:55:32 CET] <piotr> this is my computer music ;-)
[21:56:13 CET] <piotr> also i got those
[21:56:31 CET] <piotr> Parse error, at least 3 arguments were expected, only 1 given in string 'ity Hunter Collection (1987-2005)/05 NEVER GO AWAY.flac'
[21:57:04 CET] <piotr> tho seems like bug in my script tbh
[21:57:09 CET] <piotr> ill investigate'
[21:59:42 CET] <richar_d> piotr, I wrote something earlier that may help you. give me a minute&
[22:00:43 CET] <furq> piotr: http://vpaste.net/iZCOX
[22:00:51 CET] <furq> i wrote this for someone else and never tested it so ymmv
[22:02:08 CET] <richar_d> furq, https://dpaste.de/XP5i
[22:02:56 CET] <richar_d> ugh, I feel so dirty when writing Bash scripts
[22:03:18 CET] <furq> is there any benefit to `for file in "${@}"` over `for file`
[22:05:21 CET] <richar_d> yes: 1. you can run the script like this: `./convert-audio ~/Music/Album\ 1/*.flac ~/Music/Album\ 2/*.flac 2. it can process file names that contain spaces
[22:05:49 CET] <furq> mine does that as well
[22:06:13 CET] <furq> the only reason i'm screwing around with -print0 is for multiprocessing with xargs
[22:06:38 CET] <piotr> it blew up because It ask for yes on overwrite also i see on flac it has soem questions
[22:07:16 CET] <richar_d> I didn't even know `for` without `in` was a valid syntax
[22:07:26 CET] <furq> yeah it just iterates over $@
[22:07:32 CET] <furq> or $*, i never remember what the difference is
[22:07:50 CET] <richar_d> `$*` doesn't preserve spaces
[22:08:00 CET] <furq> that's probably it
[22:08:21 CET] <piotr> thx for scripts tho i use ksh
[22:08:34 CET] <furq> bash scripts are still fine as long as you have it installed somewhere
[22:08:56 CET] <piotr> altho probably would work i have mine almost working so just looking on yours from curiocity
[22:10:06 CET] <richar_d> Python is what I use when I want to write something elegant :)
[22:13:46 CET] <computron> Hey everyone, Looking to see if ffmpeg can do something and wondering if i am looking at the correct software for what i want to do. I have 2 Ip Cameara streams and an audio stream i would like to combine into a Sort of "picture in Picture steam" and then kick that out to a Single stream i can send to a streaming service is FFMPEG capable of this?
[22:15:56 CET] <furq> it's capable of it but it'll be a bit fragile
[22:16:07 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#overlay-1
[22:16:43 CET] <furq> if the two IP cameras are on a local network then it should be ok
[22:17:26 CET] <furq> but ffmpeg won't do anything to try to keep the two streams in sync, so if there are dropouts or discontinuities or whatever then things might go wrong
[22:17:31 CET] <furq> there's not really anything you can do about htat
[22:18:47 CET] <furq> you'd want something like -lavfi "[0:v]setpts=PTS-STARTPTS[bg];[1:v]setpts=PTS-STARTPTS[fg];[bg][fg]overlay=..."
[22:19:53 CET] <computron> Furq, thank you yes both are on a local network its for a church the second stream is a power point presentation
[22:20:09 CET] <computron> that is getting kicked through an axis encoder
[22:21:09 CET] <computron> Is there a good Primer, or list of examples for FFMPEG i have never looked at it just doing some research right now
[00:00:00 CET] --- Thu Feb 28 2019
1
0
[00:31:11 CET] <cone-815> ffmpeg 03Mark Thompson 07master:9d5ca71ec2ef: vaapi_encode: Do not zero access unit structures
[00:41:37 CET] <JEEB> hmm, is this valid? http://up-cat.net/p/0fd0b778
[00:42:08 CET] <cone-815> ffmpeg 03Mark Thompson 07master:f4d7bd6cdbcf: vaapi_encode: Support more RC modes
[00:42:09 CET] <cone-815> ffmpeg 03Mark Thompson 07master:f5eb08937e31: vaapi_encode_h264: Enable support for more RC modes
[00:42:10 CET] <cone-815> ffmpeg 03Mark Thompson 07master:d237b6b549f8: vaapi_encode_h265: Enable support for more RC modes
[00:42:11 CET] <cone-815> ffmpeg 03Mark Thompson 07master:1e0fac76639e: vaapi_encode_mpeg2: Enable support for more RC modes
[00:42:12 CET] <cone-815> ffmpeg 03Mark Thompson 07master:2efd63a3158d: vaapi_encode_vp8: Enable support for more RC modes
[00:42:13 CET] <cone-815> ffmpeg 03Mark Thompson 07master:28e619e268cc: vaapi_encode_vp9: Enable support for more RC modes
[00:42:14 CET] <cone-815> ffmpeg 03Mark Thompson 07master:c4c2c4df76e1: vaapi_encode_vp9: Fix whitespace after previous patch
[00:42:15 CET] <cone-815> ffmpeg 03Mark Thompson 07master:fda6dcd0b0a3: vaapi_encode_mjpeg: Use common quality option
[00:42:16 CET] <cone-815> ffmpeg 03Mark Thompson 07master:f948082e5fc2: vaapi_encode_mpeg2: Add missing marker bit in time_code
[00:57:33 CET] <BtbN> JEEB, yes
[00:59:23 CET] <BtbN> JEEB, VAEncMiscParameterBuffer has a "uint32_t data[];" in it.
[00:59:49 CET] <BtbN> So you are very limited in what you can do with that struct without relying on GNU extensions.
[01:00:36 CET] <nevcairiel> its a linux library, so they probably j ust care that it works on clang and gcc and thats that =p
[01:02:49 CET] <jkqxz> That structure definition is just a disaster more generally.
[01:03:26 CET] <jkqxz> Given the content, it is 4 byte and 4-byte aligned. But, they then define things which can go in the data which need 8-byte alignment.
[01:04:25 CET] <jkqxz> So you end up having have to make a new structure with an extra 4 bytes of padding before that structure in order to actually use it.
[01:05:13 CET] <jkqxz> And then you have to copy the whole thing to an unaligned version after writing the fields.
[01:26:26 CET] <uau> nevcairiel: the definition of VAEncMiscParameterBuffer is in no way gcc- or clang-specific though
[01:26:34 CET] <uau> it's perfectly standard C
[01:27:38 CET] <uau> only the part using it in the middle of another struct in libavcodec is non-standard
[01:34:14 CET] <uau> jkqxz: if the data can contain some thing (struct?) which requires 8-byte alignment, wouldn't it be easier to just normally declare that struct, and then memcpy it into a VAEncMiscParameterBuffer data part? (instead of any "extra padding" stuff)
[13:41:07 CET] <BradleyS> ping durandal_1707
[13:46:47 CET] <durandal_1707> BradleyS: ?
[13:50:08 CET] <BradleyS> what is the new feature you speak of regarding that handbrake issue?
[13:50:17 CET] <BradleyS> i'm not sure which commits apply
[13:54:49 CET] <durandal_1707> that file needs dhav demuxer
[13:54:58 CET] <durandal_1707> because it have audio
[14:05:54 CET] <BradleyS> ah, thanks
[15:02:46 CET] <j-b> pfff, nvcc is a mess
[15:05:07 CET] <BtbN> I'll probably just go ahead and merge the series after some testing (And releasing the needed new sdk)
[15:05:14 CET] <BtbN> But putting nvcc back into nonfree
[15:05:54 CET] <BtbN> What it primarily does is getting rid of a dependency on the CUDA SDK, which is good nevertheless
[15:11:25 CET] <BtbN> https://github.com/FFmpeg/nv-codec-headers/pull/5/files just, why?
[15:13:51 CET] <j-b> BtbN: I agree with you: you should merge the series.
[15:14:00 CET] <j-b> Unfortunately, that does not make it non-free, IMHO
[15:14:05 CET] <BtbN> Yes
[15:14:34 CET] <BtbN> As long as the only way to build the filter Kernels remains to register with Nvidia, and accepting a full of 3 EULAs to get the SDK... nope
[15:15:07 CET] <BtbN> Even if you use clang to build them (which is possible), that still needs libraries and other stuff from that SDK to succeed.
[15:15:41 CET] <BtbN> I assume you mean non-non-free. Or, well, free.
[15:16:16 CET] <funman> non-non-free as in non alcoholic free beer?
[15:18:09 CET] <BtbN> It's a bit unfortunate that the option is called non-free. So to indicate it's about it.
[15:18:45 CET] <BtbN> Releasing new SDK versions got more annoying with one additional SDK to maintain.
[15:18:53 CET] <BtbN> Wonder at what point I should drop SDK 8.0
[15:19:40 CET] <j-b> BtbN: ofc. :)
[15:19:58 CET] <j-b> BtbN: I don't understand why nVidia is so blocking open source lately...
[15:20:17 CET] <BtbN> I guess I can already drop it, since the oldest still maintained driver by nvidia (that supports the video codec SDK) is the 390 series, which is SDK 8.1 capable.
[15:20:30 CET] <BtbN> I don't feel like anything has changed in a while?
[15:20:51 CET] <BtbN> hm, well. The Video-Codec-SDK used to be freely available for download.
[15:21:08 CET] <BtbN> But you still has to accept EULAs, just didn't need to register.
[15:21:14 CET] <BtbN> *d
[15:29:25 CET] <j-b> It's less shady than this new Matrox stuff
[15:30:08 CET] <durandal_1707> isn't Matrox dead?
[15:46:57 CET] <durandal_1707> i get small artifacts after imdct and overlapping, (seen as spikes of high frequencies in spectrogram), whats causing this? wrong window numbers?
[15:59:42 CET] <ubitux> extract_extradata bsf is nice
[15:59:50 CET] <ubitux> too bad we don't have the same for width/height :(
[16:00:04 CET] <ubitux> seems like h264_metadata doesn't do it either
[16:00:23 CET] <ubitux> (i need avctx->{width,height} at probing, without a h264 decoder)
[16:00:25 CET] <atomnuker> durandal_1707: yeah, definitely a wrong window
[16:00:55 CET] <atomnuker> or lapping in case it isn't exactly 50% (it should be, the window is kbd after all)
[16:18:22 CET] <philipl> BtbN: https://softwareengineering.stackexchange.com/questions/318503/can-i-releas…
[16:20:05 CET] <BtbN> That answer does not look very on point to the question.
[16:20:08 CET] <philipl> But beyond that, there's also the licencing of the kernel source itself. For an MIT licenced kernel, I think the question of whether the compiler is a General Purpose Tool (and surely it is) can be side-stepped.
[16:20:53 CET] <philipl> The LGPL terms can be complied with if the ptx file is distributed for an MIT licenced kernel instead of the original .cu. The rest of the build can complete correctly without nvcc or the sdk
[16:20:59 CET] <nevcairiel> the licence of the kernel doesnt really matter for the final ffmpeg package, it only has one license that applies to the entire binaries in it
[16:21:06 CET] <BtbN> That might be true if it was only about the kernel, but it's about ffmpeg as a whole.
[16:21:16 CET] <philipl> The kernels are separate programs
[16:22:14 CET] <BtbN> I will apply the series (with ammendmends), but keeping cuda_nvcc as non-free. We can then post a patch that does just make it free, and discuss there.
[16:22:20 CET] <philipl> and while in a GPL build, the MIT licenced parts are implicitly distributed under GPL terms, that would not be true for LGPL because the LGPL licence on LGPL files can be complied with even while MIT files are are distributed under MIT, because you can rebuild.
[16:22:48 CET] <philipl> I read your comments, and I'm fine with that, but I'm now trying to have that discussion.
[16:23:07 CET] <BtbN> Right now things are failing because nvcc on Windows uses cl.exe, which expects Windows-paths, wile ffmpeg gives it a /tmp path.
[16:23:17 CET] <j-b> How does that work, sorry, if nvcc is not usable?
[16:24:13 CET] <philipl> As part of the configure check?
[16:24:27 CET] <BtbN> Does configure have some magic, like cygpath, to convert them? How does it work when it's using cl.exe itself?
[16:25:19 CET] <nevcairiel> careful work has been taken to only use relative paths
[16:25:24 CET] <BtbN> yes, test_nvcc is failing, because "nvcc -ptx -c -o /tmp/ffconf.wqnJSKl5/test.o /tmp/ffconf.wqnJSKl5/test.cu" -> c1xx: fatal error C1083: Cannot open source file: 'C:/tmp/ffconf.wqnJSKl5/test.cu': No such file or directory
[16:26:12 CET] <BtbN> test_cc works the same way as test_nvcc, and it works?
[16:26:39 CET] <nevcairiel> i assume your main compiler is gcc in this, so its not aware that it needs to be especially careful
[16:26:43 CET] <philipl> j-b: was that comment to me? For an LGPL build, if the kernels are not themselves LGPL, then the ptx is a non-original-source form of a non-LGPL part that can be used to enable the rebuild of the LGPL parts, and that is allowed by the LGPL.
[16:27:31 CET] <BtbN> nevcairiel, yeah, probably true.
[16:30:52 CET] <j-b> philipl: but not GPL
[16:32:08 CET] <philipl> j-b: for sure. but i just want to get to lgpl builds with filters. non-free means non-lgpl, not non-gpl in configure
[16:32:27 CET] <j-b> Sorry, but I don't think that it works that way.
[16:32:51 CET] <philipl> What doesn't work that way?
[16:33:48 CET] <j-b> LGPL has upgradibility to GPL, so if it does not work with GPL, it did not work with LGPL.
[16:34:12 CET] <philipl> for source. not for a distributed binary.
[16:34:27 CET] <BtbN> Is it ok to use realpath in configure, given that that part of code will only ever run on Windows and Linux?
[16:34:31 CET] <philipl> clearly, something distributed under lgpl specific terms cannot be distributed under gpl terms.
[16:34:46 CET] <j-b> Also, .cu are LGPL, so why are you saying that the kernels are not LGPL?
[16:35:11 CET] <BtbN> They are MIT
[16:35:15 CET] <philipl> there are three cu files. two are mit licenced and the third is my code that i already posted a diff to relicence.
[16:35:25 CET] <philipl> and which i will apply in due course.
[16:35:43 CET] <BtbN> (I have no idea what's wrong with the patch, but I just can't get it to apply)
[16:35:51 CET] <j-b> vf_yadif_cuda is not based on yadif?
[16:35:59 CET] <philipl> BtbN: i will apply.
[16:36:42 CET] <philipl> j-b: i didn't read yadif to write the kernel. i used a forum post description of the algorithm.
[16:37:04 CET] <j-b> Sorry, but that is very dubious, in the same project that originated yadif
[16:37:26 CET] <nevcairiel> So if I read a GPL algorithm, and write down an explanation of it on a forum, then someone else reads it, then the license is gone?
[16:37:29 CET] <nevcairiel> sounds useful :D
[16:37:43 CET] <philipl> but that's exactly what clean room is.
[16:37:49 CET] <j-b> sure
[16:37:55 CET] <j-b> but there are conditions to do so
[16:38:21 CET] <j-b> but when you commit to the same project, that is very weird and doubtful
[16:39:15 CET] <j-b> but, beside yadif, the other are MIT, and are compiled to ptx asm with nvcc, right?
[16:39:23 CET] <philipl> j-b:right
[16:39:23 CET] <BtbN> yep
[16:40:06 CET] <j-b> and then the ptx is loaded at runtime, right? Like an ARB shader?
[16:40:10 CET] <philipl> yep
[16:40:45 CET] <j-b> but those i****&ts cannot load directly the .cu ?
[16:40:58 CET] <philipl> nope.
[16:41:14 CET] Action: j-b wonders why...
[16:41:18 CET] <nevcairiel> loading source shaders is out of fashion
[16:41:21 CET] <j-b> they are making it painful on purpose
[16:41:26 CET] <j-b> nevcairiel: because?
[16:41:27 CET] <nevcairiel> look at vulkan shaders =p
[16:41:39 CET] <philipl> yeah...
[16:41:51 CET] <BtbN> The nvidia driver just does not come with a C/C++ compiler
[16:41:52 CET] <j-b> why not commit the ptx to the repo?
[16:41:55 CET] <philipl> This is a lot like java and byte code.
[16:42:00 CET] <BtbN> Though it can load OpenCL kernels, which are also essentially C?!
[16:42:10 CET] <philipl> because who wants to write ptx by hand?
[16:42:27 CET] <BtbN> j-b, that's how it initially worked. People hated it.
[16:42:42 CET] <j-b> Sure, but that's the safe way for the *GPL
[16:42:50 CET] <BtbN> It indeed is.
[16:43:02 CET] <BtbN> Just commit .cu and .ptx.
[16:43:10 CET] <philipl> j-b: because it's not original source, I'm not sure it's safe
[16:43:20 CET] <j-b> BtbN: I would do that.
[16:43:24 CET] <j-b> philipl: why not safe?
[16:43:43 CET] <philipl> if you think that using nvcc is non free, then how is it ok to distribute the ptx and say you must do a non-free thing to regenerate it?
[16:43:45 CET] <nevcairiel> plenty projects have "generated" files of some sort, not always very obvious how to even generate them
[16:43:45 CET] <BtbN> You would have to trust the commiter that that .ptx indeed came from compiling the .cu next to it
[16:44:09 CET] <BtbN> philipl, because you can reproduct the ffmpeg build without needing to sign a Nvidia EULA
[16:44:12 CET] <BtbN> *e
[16:45:19 CET] <j-b> philipl: png vs xcf
[16:45:32 CET] <BtbN> philipl, btw., I made a new ffnvcodec release-set. Will bump the version requirement in configure accordingly.
[16:46:52 CET] <philipl> BtbN: I don't see how that would fly in the sense that the downstream consumer must be able to rebuild from original source, and if you say requiring them to use nvcc breaks lgpl, then it's still broken for an lgpl kernel.
[16:47:08 CET] <philipl> or are you implicitly discussing mit kernels?
[16:47:48 CET] <BtbN> From how I understand (L)GPL, it's more about a user being able to build stuff themselves. Which they can when the .ptx is provided.
[16:48:00 CET] <philipl> yes. i did say that originally.
[16:48:08 CET] <philipl> for an mit kernel.
[16:48:38 CET] <philipl> for an lgpl kernel, you must provide original source, which we would, and they must be able to modify and rebuild and replace it.
[16:49:32 CET] <philipl> which they can, if they use nvcc. but you say we cannot require nvcc and be lgpl compliant.
[16:50:59 CET] <BtbN> yeah, an LGPL kernel might be a problem. But I'm too confused about this license mess anyway.
[16:52:13 CET] <philipl> aren't we all. I remain unconvinced by the argument that a proprietary compiler violates gpl. As noted in that link, the first gpl code could only be compiled with proprietary compilers.
[16:52:36 CET] <j-b> they might modify the ptx manually
[16:52:41 CET] <philipl> the licence is clearly intended to allow for gpl code to be usable on such platforms.
[16:53:19 CET] <philipl> j-b: they can, and that would be fine, but you can't require it vs .cu modification.
[17:08:17 CET] <philipl> OK, so we're all exhausted by that discussion. That seems to be what usually happens. :-)
[17:08:58 CET] <BtbN> I think I fixed nvcc in a portable fashion. Assuming GNU coreutils are available on all platforms where nvcc is.
[17:09:27 CET] <philipl> That seems fine by me.
[17:09:40 CET] <philipl> It works on windows, linux, mac, and the mac case is super obscure.
[17:10:22 CET] <philipl> I'm very happy with saying that checking in ptx files alongside cu files satisfies our lgpl compatibility if that's the concensus opinion. I'm also very happy with a solution where I don't have to try justifying relicencing the yadif kernel.
[17:10:23 CET] <BtbN> configure does not support enabling it on OSX anyway
[17:10:27 CET] <philipl> BtbN: even better.
[17:13:07 CET] <BtbN> I also altered configure a little, so it still support --enable-cuda-sdk but throws a warning at you if you use it.
[17:13:50 CET] <philipl> BtbN: thanks.
[17:14:43 CET] <j-b> philipl: still, I would commit both, sorry.
[17:14:53 CET] <BtbN> Now to making a very long pkg-config check
[17:16:52 CET] <j-b> move to meson
[17:17:48 CET] <philipl> j-b: I don't have a problem with committing both. You don't need to apologise. :-) If that allows us to lift non-free, it's a very small price to pay.
[17:18:34 CET] <BtbN> Dropping support for SDK 8.0. Won't make new releases for it either. 8.1 supports driver 390, which is the oldest still supported nvidia driver with video-codec-sdk support.
[17:18:52 CET] <j-b> philipl: it's complex topics.
[17:18:53 CET] <philipl> BtbN: sounds reasonable.
[17:19:02 CET] <j-b> philipl: however, I will ask nvidia to open source nvcc
[17:19:07 CET] <j-b> at my next call with them.
[17:19:20 CET] <j-b> (while there is life, there is hope)
[17:19:21 CET] <BtbN> It's not so much about nvcc, but about the libs it uses.
[17:19:27 CET] <BtbN> nvcc itself can already be replaced with clang.
[17:19:30 CET] <philipl> j-b: if you can have any influence there, it would be great.
[17:26:53 CET] <BtbN> philipl, https://github.com/BtbN/FFmpeg/commits/master intend to push that later today
[17:29:11 CET] <nevcairiel> is there a reason to drop 8.0 beyond saving a line in configure? if not, it would be nice to keep driver support as broad as possible for some distributions
[17:29:53 CET] <nevcairiel> also i don't think the relative-path hack works if tmp is on a different drive
[17:30:34 CET] <BtbN> hmmm
[17:30:37 CET] <BtbN> true
[17:30:49 CET] <BtbN> So I guess checking if cygpath exists and using it it is?
[17:31:02 CET] <nevcairiel> i believe we use that for some other mingw path shenanigans
[17:31:12 CET] <BtbN> I can't fing cygpath anywhere in configure
[17:31:18 CET] <BtbN> *d
[17:31:56 CET] <BtbN> SDK 8.0 is seriously old now.
[17:31:59 CET] <nevcairiel> or just do what we do for msvc anyway, set the tmpdir to . for windows
[17:32:22 CET] <BtbN> It works fine in a full msvc build
[17:32:26 CET] <BtbN> but it fails in cygwin and msys
[17:32:36 CET] <nevcairiel> yes because tmpdir is absolute
[17:33:56 CET] <BtbN> There is no supported driver that doesn't at least support SDK 8.1 anymore
[17:34:02 CET] <j-b> philipl: I might
[17:57:19 CET] <philipl> BtbN: tree looks fine, although no comment on realpath vs cygpath.
[18:08:49 CET] <BtbN> nevcairiel, https://github.com/BtbN/FFmpeg/commit/0281c22088604465737674fccca4eb10e8bce…
[18:09:03 CET] <BtbN> ignore the second hunk, that needs to be rebased into a different patch
[18:11:43 CET] <nevcairiel> Does that actually work of there by is a drive change involved?
[18:12:29 CET] Action: j-b hints meson
[18:12:50 CET] <BtbN> nevcairiel, why wouldn't it?
[18:13:17 CET] <BtbN> Could throw in a -a to be absolutely safe
[18:13:57 CET] <nevcairiel> Because mingw path translation is peculiar and absolute path with a drive letter look like a parameter it wants to translate
[18:14:16 CET] <nevcairiel> Ie. Try? :)
[18:14:25 CET] <BtbN> Well, it's only ever passed to nvcc
[18:14:34 CET] <BtbN> And it seems to understand C:/...
[18:15:30 CET] <BtbN> cygpath -m /tmp gives me C:/Cygwin/tmp which seems sane and works
[20:26:34 CET] <atomnuker> in case someone hasn't seen it: https://bitbucket.org/multicoreware/x265/commits/878541319ea1375be0e981f6ea…
[20:27:31 CET] <atomnuker> were they too bothered to write their own encoder or something?
[20:29:48 CET] <JEEB> most likely they just got paid to makei t possible to use x265 interfaces to encode with SVT-HEVC
[20:30:53 CET] <j-b> Yes
[20:31:04 CET] <j-b> it's not touching the encoder, but just the x265 executable
[20:32:51 CET] <atomnuker> still its like x264.c running libopenh264
[20:35:30 CET] <j-b> true.
[20:57:35 CET] <cone-927> ffmpeg 03Justin Ruggles 07master:69fcc093c124: http: Do not try to make a new request when seeking past the end of the file
[20:57:35 CET] <cone-927> ffmpeg 03Justin Ruggles 07master:97f47fd601d0: mov: Fix start_time for streams with empty edits in the middle
[21:00:25 CET] <kurosu_> Justin Ruggles? Now that's a name I haven't in a long time
[22:55:39 CET] <nevcairiel> He works for some big media company now, occasionally still sends patches
[00:00:00 CET] --- Wed Feb 27 2019
1
0
[00:39:45 CET] <kevinnn> JEEB: hey are you still around?
[00:41:55 CET] <JEEB> kevinnn: no :P I am finishing up as it's almost 2am and getting some sleep
[00:42:25 CET] <kevinnn> JEEB: do you know anything about rfc3984?
[00:42:43 CET] <kevinnn> looks like live555 want's the outgoing packets to follow these standards
[00:42:55 CET] <kevinnn> but the reading for it looks dense...
[00:47:49 CET] <kevinnn> can anyone give me a break down of what exactly is inside of p_payload inside of x264_nal_t?
[01:47:10 CET] <kandinski> I'm using ffmpeg to decode rw bayer8 frames from a camera, and I want to output it to localhost with minimal latency. Size is not a problem, because we won't be sending it over a network. What's the recommended output encoder/format in this case?
[01:57:38 CET] <kandinski> Answering my own question: bmp codec seems to be doing the trick.
[03:59:00 CET] <ricemuffinball> i have a video file that was separated into 2, how do i join them back together?
[04:25:30 CET] <friendofafriend> ricemuffinball: concat.
[04:26:10 CET] <ricemuffinball> you mean this? ffmpeg -safe 0 -f concat -i list.txt -c copy output.mp4
[04:26:47 CET] <ricemuffinball> that creates corrupted file
[06:54:54 CET] <ricemuffinball> i have a video file that was separated into 2, how do i join them back together?
[06:58:06 CET] <TheAMM> You'll have to elaborate a bit
[07:14:39 CET] <ricemuffinball> i have a video file that was separated into 2, how do i join them back together into one file?
[07:20:40 CET] <pink_mist> technically adding "into one file" is elaborating ... slightly
[12:31:00 CET] <vtorri> hello
[12:31:18 CET] <vtorri> i am trying to compile ffmpeg with theora support
[12:31:30 CET] <vtorri> i've installe theora from sources
[12:31:57 CET] <vtorri> i've forgotten to say that it's on Windows using MSYS2 + mingw-w64
[12:32:15 CET] <vtorri> so i passed --enable-libtheora
[12:32:17 CET] <vtorri> i get :
[12:32:32 CET] <vtorri> ERROR: libtheora not found
[12:33:57 CET] <vtorri> from config.log the problem is link error
[12:34:30 CET] <vtorri> E:/Documents/programmes_x64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.4.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -ltheoraenc
[12:34:46 CET] <vtorri> same for -ltheoradec and -logg
[12:35:13 CET] <vtorri> why isn't pkg-config used for theora ? this package provide it
[12:56:30 CET] <DHE> from a linux standpoint, it is but by default a source-compiled package puts its pkg-config data into /usr/local/lib/pkg-config which isn't searched by pkg-config by default. On linux I would "export PKG_CONFIG_PATH=/usr/local/lib/pkg-config" (or whatever is suitable to your shell) and try again
[12:56:46 CET] <DHE> translating that to mingw is an exercise for the user... :/
[12:57:25 CET] <JEEB> cross-compilation you usually want PKG_CONFIG_LIBDIR
[12:57:31 CET] <JEEB> which overrides the full path
[12:57:35 CET] <JEEB> PKG_CONFIG_PATH appends
[12:58:02 CET] <JEEB> right, it's mingw-w64 on msys2 which masquerades as not cross-compiling
[12:58:05 CET] <JEEB> then PKG_CONFIG_PATH
[13:04:36 CET] <ossifrage> So I can do "ffmpeg .... out.ppm" but "ffmpeg .... -f ppm -" doesn't work?
[13:07:51 CET] <ossifrage> Requested output format 'ppm' is not a suitable output format
[13:10:26 CET] <furq> ossifrage: -f image2pipe -c:v ppm -
[13:11:33 CET] <ossifrage> furq, thanks!
[13:13:45 CET] <ossifrage> Sometimes I really love bash: https://termbin.com/pfrp
[13:16:08 CET] <ossifrage> Every time the encoder hits an IDR frame it dumps the h.26[45] elementary stream to /tmp and you can view it with ffplay :-)
[13:29:28 CET] <ossifrage> I wonder how hard it would be to encapsulate a single IVOP into something you could convince chrome/firefox to display as a still image
[13:30:22 CET] <ossifrage> (without any javascript hick, just the image from the urlbar)
[14:31:54 CET] <vtorri> JEEB DHE : actually, theora is not detected with pkg-config
[14:32:10 CET] <vtorri> JEEB DHE : in the configure script :
[14:32:29 CET] <vtorri> enabled libtheora && require libtheora theora/theoraenc.h th_info_init -ltheoraenc -ltheoradec -logg
[14:32:46 CET] <vtorri> while for a lib detected with pkg-config :
[14:33:05 CET] <vtorri> enabled libtesseract && require_pkg_config libtesseract tesseract tesseract/capi.h TessBaseAPICreate
[14:34:00 CET] <vtorri> it's not a problem, i have set CPPFLAGS and LDFLAGS so that theora lib is detected, but it is strange that pkg-config is not used
[14:35:03 CET] <vtorri> vorbis and speex are detected with pkg-config, but theora is not
[15:04:33 CET] <JEEB> vtorri: ok, that sounds like an easy add then
[15:04:49 CET] <JEEB> I've added zlib before because I got tired of adding manual flags with cross-compilation :V
[15:04:55 CET] <JEEB> I just never used theora myslef
[15:30:17 CET] <vtorri> JEEB for what it worth : i have written a package installer (not manager) which compiles from sources all the libraries that are needed for the project i'm involved in.
[15:30:36 CET] <vtorri> JEEB and i'm trying to figure out what are the needed libraries for ffmpeg
[15:31:16 CET] <vtorri> at first i haven't understood why theora was not detected while the other lib with pc files were
[19:31:11 CET] <brimestone> Hey guys, I have a MacPro Ivybridge, it has 2 AMD FirePro500... is there any hwaccels I could use on this hardware? When I do -hwaccels all I get is videotoolbox
[19:36:07 CET] <DHE> from a pure hardware standpoint, ivybridge MIGHT have quicksync support, but it varies by the exact CPU
[19:36:33 CET] <brimestone> Im hoping to let the GPU handle so I can use the CPU for something else
[19:37:22 CET] <DHE> quicksync is additional hardware in the CPU. I think it's related to onboard graphics but don't quote me on that.
[19:37:39 CET] <JEEB> it's usually on the GPU side of the CPU
[19:37:46 CET] <JEEB> not really much more than that
[19:37:50 CET] <JEEB> it's a separate block within that
[19:39:44 CET] <DHE> if it's a laptop, there might be onboard graphics even if you have a discrete GPU. that was a thing back then, right?
[19:47:32 CET] <kepstin> this is a mac pro tho, it might have one of the xeons with igpu disabled. You'd have to check specific processor model.
[19:49:36 CET] <brimestone> How about vaapi will that help me?
[19:52:13 CET] <Hello71> trash can, lol
[19:52:20 CET] <brimestone> HAHAHAHA
[20:05:21 CET] <brimestone> what hardware would be best for transcoding to h264, h264, dnxhd from ProRes, h264, xdcam sources
[23:08:42 CET] <grungies1138> Hello guys. Can anyone here offer any alsa support?
[23:08:57 CET] <grungies1138> Or is there another room I should look into?
[23:09:45 CET] <JEEB> if you are just developing something using alsa, then I would recommend one of the alsa support channels
[23:11:26 CET] <grungies1138> thanks
[00:00:00 CET] --- Wed Feb 27 2019
1
0
[07:33:32 CET] <cone-910> ffmpeg 03Karthick J 07master:ca5ec4cbbcf3: avformat/dashenc: Added option to repeatedly publish master playlist
[07:33:32 CET] <cone-910> ffmpeg 03Karthick J 07master:2e67f751b55b: avformat/dashenc: Added comments
[09:50:54 CET] <JEEB> #7637 sounds like fun with sanity checks :P
[09:52:02 CET] <JEEB> (or just failed duration handling, although the empty initial sample description sounds a bit weird)
[11:23:30 CET] <j-b> 'morning
[11:26:25 CET] <BradleyS> o/
[12:41:09 CET] <atomnuker1> I found out that /usr/bin/mjpeg_simd_helper
[12:41:11 CET] <atomnuker1> is a thing
[12:41:33 CET] <kierank> atomnuker1: what is it
[12:41:51 CET] <atomnuker1> its only job is to tell you what values you can put in MJPEGTOOLS_SIMD_DISABLE to disable certain simd optimizations
[13:08:27 CET] <durandal_1707> do we have KBD window already implemented in AAC?
[13:10:38 CET] <durandal_1707> oh, we have it
[13:13:16 CET] <durandal_1707> :) less work
[13:20:25 CET] <atomnuker1> you can make your own with ff_kbd_window_init in case the coeff is different
[13:20:51 CET] <durandal_1707> yes, very nice
[13:28:48 CET] <durandal_1707> well, i need to modify FF_KBD_WINDOW_MAX to 2048
[13:29:44 CET] <atomnuker1> what window shapes are used for the mod-15 and the other nptwo transforms?
[13:32:11 CET] <durandal_1707> some strange formulas, various combination, look from page 170
[13:32:33 CET] <durandal_1707> it uses KBD_LEFT and KBD_RIGHT
[13:49:00 CET] <durandal_1707> hmm, this is either simplified version (using some math to simplify forumulas) or completely different thing
[13:56:45 CET] <durandal_1707> the bessel stuff is different
[13:58:03 CET] <durandal_1707> hmm, AC3 uses it too, lets see AC3 spec
[14:01:32 CET] <durandal_1707> not useful, its hardcoded single table
[14:13:39 CET] <durandal_1707> ac4 uses same alpha as aac for similar windows, so it must be that thing, or there is another very similar window that allows reversible mdct
[17:12:42 CET] <cone-965> ffmpeg 03Gyan Doshi 07master:cdf17cf92b0f: doc: -report defaults to loglevel debug
[18:04:53 CET] <cone-965> ffmpeg 03Michael Niedermayer 07master:160851bceed7: avcodec/arbc: Check nb_tiles against dimensions
[18:04:54 CET] <cone-965> ffmpeg 03Michael Niedermayer 07master:32d022d26db4: avcodec/mjpegdec: Fix stereo3d memleak
[18:04:55 CET] <cone-965> ffmpeg 03Michael Niedermayer 07master:e4289cb253e2: avcodec/error_resilience: Use a symmetric check for skipping MV estimation
[18:04:56 CET] <cone-965> ffmpeg 03Michael Niedermayer 07master:286a33e42944: avcodec/wcmv: Copy/Init frame later
[18:04:57 CET] <cone-965> ffmpeg 03Michael Niedermayer 07master:976dae8b32f4: avcodec/wcmv: Avoid copying frames if they are unchanged
[20:17:52 CET] <durandal_1707> WOW, I got recognisable audio from ac4 decoder, but it is not realtime speed
[20:17:59 CET] <JEEB> najs
[20:19:49 CET] <thardin> coolers
[21:01:45 CET] <JEEB> wow
[21:01:47 CET] <JEEB> M264
[21:01:50 CET] <JEEB> some matrox encoder
[21:02:16 CET] <nevcairiel> one of those super old 264 variants?
[21:02:33 CET] <JEEB> nah, probably just Matrox's HW encoder
[21:02:41 CET] <JEEB> wonder for which piece of hardware
[21:03:13 CET] <atomnuker1> hey, matrox, they were the name of hard drivers some years ago
[21:03:25 CET] <atomnuker1> actually never, they were crap
[21:34:21 CET] <jkqxz> There is something very weird going on there. It dlopens some libraries, and the symbols it looks for have "ffmpeg" in the names?
[21:34:29 CET] <jkqxz> Also, H.264 4:2:2 only!
[21:35:13 CET] <JEEB> well the added AVCodec is also interesting but I'd just put that under "newbie mistakes"
[21:41:19 CET] <thardin> it's dlopen()ing .so/.dll files
[21:41:35 CET] <thardin> which is a no-no by policy IIRC
[21:43:42 CET] <JEEB> yea that sounds funky
[21:46:56 CET] <thardin> that type punning via union seems like a double-whammy of both being undefined behavior (maybe unspecified), and endian specific
[21:49:17 CET] <jkqxz> It kindof looks they have a (possibly-sensible) patch for lavc support, but it's then had an outer dynload layer quickly hacked in to evade copyright. We're only seeing that outer layer, so it's bizarre.
[21:50:13 CET] <thardin> myeah it reeks of gpl circumvention
[21:50:18 CET] <jkqxz> (Since the symbols it loads are basically the ffmpeg codec implementation functions themselves.)
[21:50:58 CET] <thardin> also I was wrong, type punning is fine in C
[21:51:02 CET] <thardin> not C++ tho
[22:08:45 CET] <j-b> + m264_decoder->init_m264_decoder = dlsym(lib_handle, "m264_ffmpeg_decoder_init");
[22:09:11 CET] <j-b> That feels very very weird
[22:20:11 CET] <thardin> lol
[22:21:23 CET] <thardin> would be funnier if it took AVCodecContext* instead of void*
[22:22:05 CET] <JEEB> :D
[22:22:46 CET] <thardin> that M264DecoderInfo struct just defined in the .c file instead of a header
[22:24:17 CET] <thardin> >If it fails to load, you just continue? Honestly?
[22:24:22 CET] <thardin> hah, I totally missed that
[23:41:48 CET] <kierank> JEEB: wtf
[23:41:57 CET] <kierank> this is someone's blob afaik
[23:42:16 CET] <nevcairiel> it looks very blobish and unpolished
[23:42:51 CET] <JEEB> yes
[23:43:07 CET] <JEEB> I mean, the .so/.dll loading already yells "BLOB"
[23:43:16 CET] <JEEB> and then it just keeps rolling forwards from that
[23:47:22 CET] <kierank> JEEB: why though
[23:48:37 CET] <JEEB> my guess is someone just got told to try and integrate their stuff into FFmpeg
[23:56:58 CET] <BtbN> thardin, well, it's precisely how all the nvidia stuff works as well, to avoid ffmpeg binaries using it to only work on nvidia systems.
[23:59:18 CET] <cone-815> ffmpeg 03Andreas Rheinhardt 07master:c5b452ed2f16: filter_units, trace_headers: Always use fragment from context
[23:59:18 CET] <cone-815> ffmpeg 03Andreas Rheinhardt 07master:b8c45bbcbc20: libavcodec/cbs: Stop needlessly reallocating the units array
[00:00:00 CET] --- Tue Feb 26 2019
1
0
[04:46:41 CET] <ricemuffinball> i have a video file that was separated into 2, how do i join them back together?
[05:03:55 CET] <ricemuffinball> i have a video file that was separated into 2, 1.mp4 and 2.mp4 what is the command to join them back together to 3.mkv
[05:04:23 CET] <ricemuffinball> documentation is confusing
[05:09:43 CET] <ricemuffinball> i have a video file that was separated into 2, 1.mp4 and 2.mp4 what is the command to join them back together to 3.mkv
[06:01:02 CET] <ricemuffinball> i have a video file that was separated into 2, 1.mp4 and 2.mp4 what is the command to join them back together to 3.mkv in cmd.exe
[06:21:00 CET] Last message repeated 1 time(s).
[06:27:40 CET] <ricemuffinball> ffmpeg -i "concat:1.mp4|2.mp4" -c copy 3.mp4 how come this command doesn't work
[06:36:48 CET] <xj> is it possible to detect audio playback stuttering?
[06:42:49 CET] <ricemuffinball> i have a video file that was separated into 2, how do i join them back together?
[07:38:22 CET] <xochilpili> hello everyone
[07:38:59 CET] <xochilpili> im trying to convert .dav file to mp4 or avi, using this: ffmpeg -y -i HCVR_ch1_main_20190224170000_20190224180000.dav -vcodec libx264 -crf 24 -filter:v "setpts=1*PTS" channel_1_1700_1800.mp4
[07:39:49 CET] <xochilpili> first time work, but now im trying to convert a second file and got this: HCVR_ch2_main_20190224170000_20190224180000.dav: Invalid data found when processing input
[07:40:41 CET] <ricemuffinball> what is .dav
[07:40:52 CET] <ricemuffinball> are you trying to reencode or just change container
[07:44:56 CET] <ricemuffinball> xochilpili ??
[07:45:35 CET] <xochilpili> ricemuffinball, dav is a file exported from cctv dvr
[07:45:56 CET] <xochilpili> i did it with one file and works but now im trying another then got that error
[07:46:34 CET] <xochilpili> file HCVR_ch1_main_20190224170000_20190224180000.dav < returns data file
[07:46:53 CET] <xochilpili> du -h HCVR_ch2_main_20190224170000_20190224180000.dav < returns 915MB, data is in there
[07:47:19 CET] <xochilpili> but ffmpeg dont like it and dont know why, i also tried with -v 2 flag for verbose but just do nothing
[07:48:43 CET] <ricemuffinball> are you trying to reencode or just change container
[07:49:44 CET] <xochilpili> change container to mp4 and play with mplayer
[07:50:35 CET] <ricemuffinball> what video/audio codec does .dav use
[07:50:56 CET] <xochilpili> ricemuffinball, no idea, how can i determine that?
[07:51:11 CET] <xochilpili> using -loglevel 40 got this: [AVIOContext @ 0x5557e9aec440] Statistics: 1048576 bytes read, 0 seeks
[07:51:14 CET] <ricemuffinball> send me a sample
[07:51:33 CET] <xochilpili> ricemuffinball, file is too big, how can i send you a sample?
[07:53:06 CET] <ricemuffinball> ffmpeg -i input.dev -vcodec copy -acodec copy -movflags faststart output.mp4
[07:53:13 CET] <ricemuffinball> does this work
[07:53:20 CET] <xochilpili> from the one that i could convert : Input #0, h264, from 'HCVR_ch1_main_20190224170000_20190224180000.dav': Duration: N/A, bitrate: N/A Stream #0:0: Video: h264 (High), yuv420p(progressive), 1280x720, 30 fps, 30 tbr, 1200k tbn, 60 tbc
[07:54:13 CET] <xochilpili> it does not work
[07:54:22 CET] <xochilpili> HCVR_ch2_main_20190224170000_20190224180000.dav: Invalid data found when processing input < same error
[07:54:53 CET] <ricemuffinball> try different output.mkv
[07:54:57 CET] <ricemuffinball> output.ts
[07:55:02 CET] <ricemuffinball> output.mov
[07:55:09 CET] <ricemuffinball> see any of them works
[07:55:29 CET] <xochilpili> none of those: mkv, ts, mov, ogg
[07:55:40 CET] <xochilpili> also tried avi
[07:55:58 CET] <xochilpili> does ffmpeg save some .ffmpeg data of a session ¡?
[07:58:08 CET] <xochilpili> ricemuffinball, output: https://pastebin.com/EdZvCQzL
[08:12:48 CET] <ln-> is there any way to debug what the configure script does? i get "CONFIG_PNG_DECODER 0" in config.h even though I have zlib installed. i would like to find out what configure does to determine it's zero.
[08:14:27 CET] <JEEB> ln-: ffbuild/config.log
[08:18:18 CET] <ln-> i've looked at config.log, but i'm not finding what i'm looking for. could be that i cannot read it properly.
[08:18:59 CET] <ln-> it says among other things: png_decoder='yes' png_decoder_select='zlib'
[08:19:26 CET] <JEEB> and the zlib check passes?
[08:19:38 CET] <JEEB> the tests are towards the end of the file
[08:21:00 CET] <ln-> zlib_decoder='yes'
[08:46:51 CET] <ln-> oh, the relevant part of the log looks like: https://paste.fedoraproject.org/paste/BCRmq2CQIwpTL7Lf0S6McA ... but 'yes' despite that?
[09:15:04 CET] <ln-> eh, the solution was indeed to specify "--cpu=4kc".
[09:15:36 CET] <JEEB> so you were attempting to cross-compile? (couldn't check your logs)
[09:17:42 CET] <ln-> no, native compilation on a system running in qemu.
[09:19:20 CET] <JEEB> interesting, usually native compilation with a compiler works because the default mode of the compiler is to be expected as the native one
[09:19:25 CET] <JEEB> oh well
[09:22:32 CET] <ln-> but curiously, tons of other decoders were enabled by configure, and at least configure itself didn't fail per se. (didn't check whether actual compilation would have failed)
[09:23:44 CET] <JEEB> the configure script is kind of weird due to Hysterical Raisins
[09:23:51 CET] <JEEB> as in, stuff is marked as enabled by default
[09:23:57 CET] <JEEB> but then if they have disabled dependencies
[09:24:09 CET] <JEEB> they then get disabled as the checks go on
[09:24:21 CET] <JEEB> not sure if you get a configure failure if you do --disable-autodetect --enable-zlib
[09:24:30 CET] <JEEB> or if you specifically enable the png decoder
[09:25:54 CET] <ricemuffinball> i have a video file that was separated into 2, how do i join them back together?
[09:26:25 CET] <ln-> i think i tried --enable-decoder=png, and it didn't cause an error either.
[09:27:44 CET] <doitliao> i'm back
[09:28:46 CET] <JEEB> ln-: probably because that's the default state
[09:28:58 CET] <JEEB> in theory there should be two separate states for enabled
[09:29:12 CET] <JEEB> enabled-by-default (and thus if the dependencies are not found, don't fail), and enabled-by-user
[09:29:29 CET] <JEEB> latter of course should fail hard if the user specified what is needed
[11:26:56 CET] <ln-> btw, 09:04 -ChanServ(ChanServ(a)services.)- [#ffmpeg] When asking a question be precise, detailed and patient. If you don't receive a response, try the users mailing list. PASTE TO http://ffmpeg.pastebin.com/ !
[11:27:18 CET] <ln-> Host ffmpeg.pastebin.com not found: 3(NXDOMAIN)
[11:34:44 CET] <durandal_1707> ln-: just send to normal pastebin
[11:36:23 CET] <ln-> durandal_1707: yes, sure, but the welcome message is implicitly instructing us not to do so, IN CAPS, with an exclamation mark.
[11:45:54 CET] <cslcm> Hey - how do I know which release of libx264 will link OK with a particular ffmpeg release?
[12:42:48 CET] <tbrowder> thanks to furq and another, i have successfully produced an mp4 that plays on most browsers on a PC. now I need to make a version that will play on ios if possible. from an internet search i see that i need to specify smaller image size and have no more than 100 Mb in a single file. my current three mp4 files have about 2.7 Gb and run about 30-40 min.
[12:43:36 CET] <JEEB> any modern iOS device (post 2010 or so) can do level 4.1, profile high stuff (includes main and constrained baseline)
[12:43:41 CET] <JEEB> not sure if there really is a size limit
[12:43:57 CET] <JEEB> these things can be rather specific back in ye olden days
[12:44:10 CET] <JEEB> but they also can change overnight
[12:44:38 CET] <tbrowder> the original conversion command was: ffmpeg -i $IN -c:v copy -c:a aac -ac 2 -b:a 192k $MP4
[12:45:05 CET] <JEEB> which leaves the video to whatever it was in the input
[12:45:24 CET] <JEEB> which can be good, of course. but just noting that you're not controlling that there
[12:47:08 CET] <tbrowder> questions: (1) what command should i use for converting the current mp4 files to suitable ios format and (2) how can i split the results up if they are > 100 Mb?
[12:47:33 CET] <JEEB> I'd actually verify if there are size limits altogether. :P
[12:47:42 CET] <JEEB> pretty sure iOS and iTunes has had larger files than that
[12:51:28 CET] <cslcm> i've certainly played mp4s of many gigabytes on an iPhone before
[12:51:37 CET] <cslcm> h264, not sure what profile though
[12:52:56 CET] <JEEB> main or high most likely, but the hwdec limits are on high profile so everything within that is OK
[12:53:05 CET] <JEEB> level should just be within 4.1 or so
[12:53:24 CET] <JEEB> you only hit stricter limits if you try to support iPhone 3G or so?
[12:53:29 CET] <JEEB> which is like 2009 or so I think
[12:54:22 CET] <cslcm> the iphone 4 only supported main profile up to 3.1, and only up to 720p
[12:55:20 CET] <JEEB> not sure of the resolution but I thought it changed already around 3GS or so
[12:55:23 CET] <cslcm> iPhone 3GS and older devices support Baseline Profile level 3.0 and lower
[12:55:56 CET] <tbrowder> realize i know nothing much about the video conversion business, i'm trying to help my brother and his fellow US Marines sjow videos from their 50th reunion, so i need a recipe. the first one worked, on my PC, but not on my iPhone X.
[12:56:28 CET] <JEEB> most likely because you're just copying the input video :P
[12:56:36 CET] <JEEB> use ffprobe -v verbose FILE on it
[12:56:45 CET] <tbrowder> it worked on Win 10 and Debian: Chrome, Firefox, IE, and Edge.
[12:57:24 CET] <tbrowder> JEEB, will do...
[12:57:52 CET] <JEEB> also generally when writing mp4 into a file, `-movflags faststart` is generally recommended
[12:58:04 CET] <JEEB> it does a second pass at the end to write the index at the beginning
[12:59:07 CET] <cslcm> I think that may be exactly what is needed, because the ios video player is quicktime based and quicktime flops about if you don't have the header chunk
[12:59:46 CET] <JEEB> well it is there, just at the end. and IIRC QT doesn't flip at that. it does help in general the players if you are able to move it to the front of the file tho
[13:01:36 CET] <cslcm> I certainly have seen Quicktime freak out with large files when the header is at the end of the file.
[13:02:09 CET] <tbrowder> the outpu is in this gist: https://gist.github.com/tbrowder/142f6fa996ed6d115d25aa3cf14e4862
[13:03:57 CET] <cslcm> tbrowder: definitely try creating the file again with -movflags faststart, imho
[13:05:09 CET] <tbrowder> so i should redo the original with adding "-movflags faststart"? ok, does this look correct:
[13:05:49 CET] <tbrowder> `ffmpeg -i $IN -c:v copy -c:a aac -ac 2 -b:a 192k -movflags faststart $MP4`
[13:06:27 CET] <cslcm> i'd change the audio bitrate to 160k rather than 192k
[13:06:31 CET] <cslcm> based on a google search
[13:06:41 CET] <cslcm> "iPhone Video Formats
[13:06:41 CET] <cslcm> 1. H.264 video up to 4K, 30 frames per second, High Profile level 4.2 with AAC-LC audio up to 160 Kbps, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats. (For iPhone X/8/7/6s /6s Plus)"
[13:07:04 CET] <JEEB> I'd be surprised if that was an actual limitation :P
[13:07:07 CET] <ritsuka> the limits on apple website are ofter not right.
[13:07:27 CET] <cslcm> yeah, but like anyone will be able to tell the difference between 160 and 192 anyway on a phone
[13:07:28 CET] <ritsuka> you probably can use a 7.1 aac track and will just work
[13:08:54 CET] <tbrowder> ok, so i will change 192k to 160k, thanks folks! i'll check back in later.
[13:09:29 CET] <tbrowder> i really appreciate the help, this is a very friendly IRC!!
[13:35:48 CET] <another> considering itunes sells 256k aac, i doubt the 160k limit
[14:22:15 CET] <Accord> I'm transcoding a lot on a 16 core machine using -preset superfast but htop says ffmpeg isn't maxing out all my cores
[14:22:39 CET] <Accord> it spawns a lot of threads but it most of them are utilizing only 20-30% per core
[14:23:21 CET] <Accord> is this an inherent limitation or am I not setting the right options?
[14:24:38 CET] <DHE> x264 (I assume that's what you're using) does have some scaling limits. I think past ~12 cores unless you're running slow presets or 4k inputs (!) you'll see that
[14:25:08 CET] <DHE> at some point the single-threaded process of getting frames in and out of x264 will be substantial enough
[14:25:47 CET] <w1kl4s> isn't it i/o limitation as well with superfast?
[14:27:01 CET] <iive> it might not be using multiple threads for decoding
[15:45:37 CET] <schu-r> I have a problem recoding a HLS Video. (Not Streaming) I want to Record a Video with HLS (done) and recode each individual segment. But the Video is not playable anymore.
[17:04:07 CET] <tbrowder> folks, the mp4 conversion for iPhone doesn't work. the ffprobe for the first file is shown in this gist:
[17:04:09 CET] <tbrowder> https://gist.github.com/tbrowder/95b4d799670f8ea3e0f363893666b3b3
[17:04:59 CET] <tbrowder> that doesn't work on my iphone, but it does work in my PC chrome browser.
[17:07:24 CET] <JEEB> it's 60/1.001fps, anamorphic 16:9 1440x1080 and not sure which level
[17:12:58 CET] <tbrowder> stackoverflow says this: MPEG-4 video, up to 2.5 Mbps, 640 by 480 pixels, 30 frames per second, Simple Profile with AAC-LC audio up to 160 Kbps, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats
[17:14:19 CET] <tbrowder> so how do i change the frame format to 640x480 pixels?
[17:15:24 CET] <cslcm> the iPhone X supports way more than 640x480
[17:17:01 CET] <cslcm> but you can do that with -vf scale=640:480
[17:48:15 CET] <tbrowder> cslcm: thanks!
[18:26:58 CET] <another> tbrowder: that seems to refer to mpeg4 part 2 video
[18:30:51 CET] <tbrowder> another: so do i need to start with the original data? and go another route? let me show everyone the original files i started with. i received three DVDs of about 2,7 Gb or less. Each DVD had one directory with a similar file structure. I'll put the first one in a gist...
[18:36:20 CET] <ricemuffinball> i have a video file that was separated into 2, how do i join them back together?
[18:37:18 CET] <tbrowder> https://gist.github.com/tbrowder/4f09d295b62d6094d183891d6b725488
[18:40:09 CET] <tbrowder> from that first DVD I concatenated the m2ts files into one (and I did the same with the other two DVDs) to get the part-1.m2ts file which I the converted to mp4 following suggestions from this group. the mp4 files have worked fine on a PCD browser, but I would like to get something that works on iphones and othe mobile devices if at all possible.
[18:46:28 CET] <another> ffmpeg -i $IN -c:v libx264 -crf 18 -preset medium -profile:v high -level 4.2 -c:a aac -b:a 160k -movflags +faststart -t 60 OUT.mp4
[18:46:36 CET] <another> tbrowder: try this
[18:46:54 CET] <another> the -t 60 limits to the first 60 seconds
[18:47:07 CET] <another> so you don't have to wait too long for testing
[18:47:20 CET] <tbrowder> another: okay, thnx...
[18:48:48 CET] <another> also, it looks like that video is interlaced. might be a problem for iphone
[18:49:00 CET] <another> can't really find good spec from apple
[18:49:54 CET] <another> in that case you could try:
[18:50:46 CET] <another> ffmpeg -i $IN -c:v libx264 -crf 18 -preset medium -profile:v high -level 4.2 -c:a aac -b:a 160k -movflags +faststart -vf bwdif -t 60 OUT.mp4
[18:51:08 CET] <another> to deinterlace
[18:51:21 CET] <another> anyway gotta go. food you know.
[18:57:20 CET] <tbrowder> another: the first method works on all so far! thanks!
[18:59:15 CET] <tbrowder> .tell another thank you! it works on PC browsers, iPhone and iPad chrome...thank you very much!
[19:01:07 CET] <another> great
[19:16:49 CET] <Aelius> I have a few opus/ogg files, but there appears to be a conflict with replaygain tags and that format. I'm trying to transfer them to the mka container, then, but the tags aren't transferring over.
[19:17:28 CET] <Aelius> ffmpeg can see the tags as part of the opus stream, but -f ffmeteadata isn't exporting it. Not sure what to do.
[19:19:51 CET] <kepstin> metadata in matroska is a mess
[19:20:08 CET] <kepstin> a lot of properties aren't mapped to it, and basically no audio players can read it anyways
[19:20:49 CET] <kepstin> as far as replaygain in opus - the spec says you're not supposed to use the 'replaygain' tags, but in practise it works fine
[19:21:14 CET] <kepstin> just tag them the same way as vorbis and it'll work in almost all players
[19:22:42 CET] <kepstin> (I also wrote a little replaygain tagger script which uses ffmpeg, and writes tags in opus files that work with basically all players: https://github.com/kepstin/regainer/ )
[19:25:21 CET] <Aelius> I'm using foobar2000 on Windows and it applies 2/4 replaygain tags, which apparently my phone's music players specifically looks for
[19:25:33 CET] <Aelius> where opus is concerned*
[19:25:37 CET] <Aelius> mka works fine in both cases.
[19:26:50 CET] <Aelius> specifically, opus seems to support track/album gain, but NOT track/album peak gain
[19:26:54 CET] <kepstin> hmm. i can't remember exactly which tags foobar2000 writes. I think it probably is writing the R128_ALBUM_GAIN and R128_TRACK_GAIN tags rather than replaygain
[19:27:47 CET] <kepstin> the peak levels aren't really super useful, it's usually better if the player applies a limiter rather than reducing volume to avoid peaks.
[19:28:11 CET] <Aelius> unfortunately there are two good players in android so I don't have a lot of choice here :)
[19:28:24 CET] <kepstin> but if you write REPLAYGAIN tags instead of R128 tags (or in addition to), like my regainer tool does, then you can save the peak values
[19:29:50 CET] <Aelius> we're venturing off on a false premise right now
[19:29:57 CET] <Aelius> the issue is with opus and ffmpeg
[19:30:03 CET] <Aelius> I just tried converting it to mp3
[19:30:05 CET] <Aelius> same issue
[19:30:08 CET] <Aelius> tags are not transfered
[19:30:24 CET] <Aelius> the problem is not mka, its opus
[19:30:33 CET] <kepstin> ffmpeg doesn't have any handling for the R128 tags in opus, correct
[19:30:40 CET] <kepstin> it'll handle REPLAYGAIN tags fine
[19:30:43 CET] <Aelius> especially considering I can't seem to get ffmpeg to export any opus tags
[19:30:49 CET] <Aelius> it will read the tags
[19:30:54 CET] <Aelius> it knows they are there
[19:30:59 CET] <Aelius> and I'm talking about
[19:31:01 CET] <Aelius> ALL of the tags.
[19:31:05 CET] <Aelius> artist, album, title
[19:31:06 CET] <kepstin> note that converting R128 tags to REPLAYGAIN tags for non-opus formats requires adjusting by 5dB for the different reference level
[19:31:17 CET] <kepstin> you're usually better off just recalculating after converting
[19:31:18 CET] <Aelius> All. The. Tags.
[19:31:33 CET] <Aelius> the output file has zero metadata
[19:31:55 CET] <kepstin> hmm, well, sounds like a bug then
[19:32:09 CET] <kepstin> I'd expect the replaygain not to be transferred, but everything else should be
[19:33:14 CET] <Aelius> http://sprunge.us/ALTz5D
[19:33:34 CET] <Aelius> the tags are ... trapped in the opus stream?
[19:33:40 CET] <Aelius> not in the container
[19:34:29 CET] <kepstin> matroska metadata is weird, metadata can be attached to various objects in the file at multiple levels
[19:35:00 CET] <Aelius> again- not mka's problem.
[19:35:06 CET] <Aelius> When I convert to mp3
[19:35:13 CET] <Aelius> (convert not copy)
[19:35:21 CET] <Aelius> there just are no tags transfered at all
[19:35:57 CET] <Aelius> it's only keeping the tags in the stream because I stream copy to mka, I think. the faulty behavior lies with ffmpeg/opus
[19:36:43 CET] <kepstin> fwiw, ffmpeg has very limited support for converting metadata between formats, i'd recommend not relying on it in general.
[19:36:48 CET] <Aelius> this is the second problem I've had with youtube downloads- ffmpeg seems to not be able to handle whatever youtube is doing
[19:36:56 CET] <kepstin> but basic stuff like artist, album should work.
[19:37:37 CET] <kepstin> youtube - or youtube-dl?
[19:37:41 CET] <Aelius> both
[19:37:51 CET] <Aelius> the other day I had a video that could not be converted to mp4 properly, I had to convert to flv then to mp4.
[19:40:20 CET] <Aelius> but, I think I just confirmed the file is not the issue, it's an ffmpeg issue
[19:40:46 CET] <Aelius> I took a right and proper flac, converted to opus, converted to another file. opus is swallowing tags
[19:41:48 CET] <Aelius> should be reproducable. try it for me?
[19:44:17 CET] <kepstin> I would have expected ffmpeg's tag handling for opus to have been copied from vorbis, so I dunno why it's being problematic.
[19:44:28 CET] <kepstin> opus and vorbis in ogg container store the tags in identical ways
[19:45:37 CET] <kepstin> i end up having to retag files converted with ffmpeg even when it does copy tags, because I use musicbrainz picard which sets a bunch of custom tag types that ffmpeg ignores.
[19:46:10 CET] <Aelius> yeah I'm looking into using mkvmerge right now, seems like ffmpeg isn't gonna be my friend here
[19:49:12 CET] <Aelius> hmm, no luck there either
[19:49:14 CET] <Aelius> strange
[19:49:30 CET] <GuiToris> hey, can someone give me some advice how to get values for the perspective filter? I'd like to match two separate videos
[19:49:36 CET] <kepstin> fwiw, ffmpeg has *very* limited matroska metadata support, the only tags it supports at the container level are these: https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/matroskaenc.c;h…
[19:50:14 CET] <kepstin> but yeah, i wonder if you have found a weird case where it's copying the vorbistag packet in the opus stream into the matroska container
[19:51:04 CET] <kepstin> vorbiscomment*
[19:52:59 CET] <Aelius> trying your script now, heh
[19:56:58 CET] <kepstin> so https://wiki.xiph.org/index.php?title=MatroskaOpus says that the OpusTags (contains VorbisComment formatted data) header packet from ogg opus "is not used" in matroska, but i wonder if ffmpeg might be including it in the stream in some cases...
[20:00:45 CET] <kepstin> and I have no idea how that page compares to the (as far as I can tell completely undocumented?) way opus is actually stored in matroska by existing tools.
[20:01:52 CET] <Aelius> your script doesn't help, unfortunately. It works, I can see the peak gain in the tags, but again it just seems like opus doesn't support that tag or something? foobar2000 has a special section for replaygain info- the peak gain is displayed with the regular tags, as if opus doesnt support peak gain. and my android player doesn't care that the tags are manually written, either
[20:03:03 CET] <kepstin> Aelius: ogg opus specification explicitly says that the replaygain tags aren't supposed to be used, and that peak values aren't supposed to be stored, see: https://tools.ietf.org/html/rfc7845.html#section-5.2.1
[20:03:11 CET] <Aelius> aha
[20:03:20 CET] <kepstin> (during standardization i asked them to allow replaygain tags, but got overruled...)
[20:03:46 CET] <kepstin> but many players (not all) read opus tags using shared code with vorbis tags, and so will use replaygain tags (including peak values) if present in ogg opus files
[20:04:02 CET] <Aelius> actually I just thought of another reason I want to ditch opus- android doesn't officially support them so they don't get included in the generic media scanner, which means you have to use apps which manually scan for media on their own to find opus
[20:04:25 CET] <kepstin> but that said, in typical pop music when you have replaygain values of -10dB or whatever, it's reducing the volume so much that the peak doesn't matter anyways
[20:05:16 CET] <kepstin> I personally use gonemad player on android, which does do its own library scanning, yeah. Haven't had any issues with replaygain in opus files with it.
[20:06:02 CET] <Aelius> foobar2000 on android also works, I was just frustrated by the way you arbitrarily cannot edit imported playlist files
[20:06:18 CET] <kepstin> the opus spec even has a really weird fixed point encoding of the gain values, that whole section of the spec was ill thought out imo
[20:06:20 CET] <Aelius> So I went to vanilla music player, which is ok
[20:07:42 CET] <kepstin> (most replaygain implementations, including foobar2000, use the ebu r128 algorithm to calculate loudness levels for replaygain tags - they just use a reference level of -18dB to be similar to the older replaygain scanners.)
[20:11:26 CET] <Aelius> kepstin yeah I've decided to lose this format entirely. How do you suggest I convert, and to what? I only have 20 of these I think, but even so I'd prefer to not manually reprocess all the tags
[20:12:49 CET] <kepstin> well, you should never do lossy-lossy transcodes wherever possible.
[20:13:00 CET] <kepstin> if you have an original lossless copy, just start from that
[20:13:22 CET] <Aelius> I know of this, which is why I was just trying to recontain in mka and call it a day.
[20:13:53 CET] <furq> Aelius: what extension are you using for the ogg opus stuff
[20:13:53 CET] <Aelius> But given the level of frustration this stupid endeavor has accrued, I probably woulndt care that some files I downloaded from youtube are slightly worse off.
[20:14:06 CET] <Aelius> furq: .opus
[20:14:13 CET] <furq> android has an ancient bug where it doesn't want anything to do with ogg opus if the extension is .opus
[20:14:14 CET] <kepstin> hmm, yeah, if you rename your ogg opus files to .ogg, the android scanner will pick them up
[20:14:20 CET] <furq> yeah
[20:14:36 CET] <furq> idk if it'll work as you want but it should work better at least
[20:14:41 CET] <kepstin> although whether or not it reads metadata from them depends on the android version, iirc
[20:16:24 CET] <Aelius> well, that allows another player to use the files, yes, but still replaygain doesnt work for them
[20:19:26 CET] <Aelius> Unless I concede to using foobar or that other one, at which point I didn't have to rename them
[20:20:54 CET] <kepstin> I decided I liked having opus support more than having a music player that used android's builtin media library
[20:21:17 CET] <kepstin> ... I really miss my iPod Classic with Rockbox, lost in on the bus several years ago :(
[20:21:56 CET] <Aelius> guess i'll be testing at random different codecs and different conversion tools then, if you have no suggestions there
[20:22:07 CET] <kepstin> (I had replaced the HDD with a 256gb SD card in that iPod, which was worth more than the iPod itself at the time...)
[20:22:24 CET] <Aelius> The only such files in my library are ones I sourced from youtube, it's not a format I chose to use
[20:22:50 CET] <kepstin> if you really must do a lossy-lossy conversion, you'll be most likely to keep tags in a compatible way if you go from ogg opus to ogg vorbis, and ogg vorbis works well in android.
[20:24:26 CET] <kepstin> if you want to try with ffmpeg, start with "-c:a libvorbis -q:a 5" and then adjust the q:a value to taste
[20:24:50 CET] <kepstin> you might want higher values for transcoding from a lossy source, maybe 6 or 7
[20:25:16 CET] <furq> if this is stuff you got from youtube then you could just redownload in aac or vorbis
[20:26:15 CET] <Aelius> Yeah I should just redownload in a new format.
[21:31:39 CET] <MotionVector> @JEEB .. thanks for your help the other day. I knew my codec, but not the file formats :P . The information to compute frame rate was derived from the info in the 'moov' atom (total frame count/total duration). and moov was after 'mdat' atom and I wasn't looking that far down in the file
[21:33:36 CET] <MotionVector> was a newbie issue..
[21:33:42 CET] <JEEB> MotionVector: you can also use l-smash's boxdumper's --box mode etc. to actually look at the structure if you're ever inclined to feel interested into things like that
[21:33:54 CET] <JEEB> atomicparsley is another project that's graphical instead of textual
[21:37:46 CET] <MotionVector> per recommendation, I tried downloading the boxdumper, but looks like it is .sln project to build.. which I don't have unfortunately
[21:37:57 CET] <MotionVector> ?per your recommendation?
[21:38:53 CET] <MotionVector> but, nonetheless.. I am now able to get what I was looking for though
[21:39:35 CET] <MotionVector> now I have a different issue, my ffplay is not getting built (will switch to the #ffmpeg-devel channel)
[21:51:12 CET] <kepstin> MotionVector: that's probably not a development issue. Most likely you just don't have SDL2 development packages installed.
[21:52:38 CET] <JEEB> MotionVector: you can build it just like you build FFmpeg; there's a configure script and then makefile. if you're using visual studio there's the a solution file of course
[21:53:06 CET] <JEEB> MotionVector: and building + using the libraries themselves is on this channel, not the -devel one :)
[22:00:14 CET] <MotionVector> @JEEB .. didn't know the diff between devel and support.. thank you for explaining. Think I was missing the sdl and sdl2 libraries so did a brew install, rebuilding now. I do see that ffplay and all the correct CFLAGS are set in the config.mak
[22:27:45 CET] <MotionVector> that did it.. installing sdl and sdl2 now builds ffplay
[22:28:16 CET] <zumba_addict> Hi all. Can ffmpeg make a nice slow motion from a 30fps footage?
[22:29:39 CET] <JEEB> there's a motion interpolation filter
[22:29:58 CET] <JEEB> so you can first convert your 30fps to, say, 60fps. and then half the speed
[22:30:10 CET] <JEEB> and you have .5x speed
[22:36:49 CET] <zumba_addict> cool
[22:36:53 CET] <zumba_addict> thanks for the tips :)
[22:37:25 CET] <zumba_addict> I want to buy the anafi drone but it only has 30fps on 4k. The mavic air has 120fps but it's too much for my budget
[22:38:50 CET] <zumba_addict> let's say footage is 20 seconds, can we slow down part of the footage only like from 6th second to 9th second?
[22:39:04 CET] <Mavrik> It'll look very very jerky
[22:39:13 CET] <Mavrik> Because you'll be slowing down 30fps to significantly less
[22:39:21 CET] <zumba_addict> when slowing it down, it will look jerky?
[22:39:26 CET] <Mavrik> (which is why slowmo cameras record at such high fps)
[22:39:53 CET] <zumba_addict> i want to achieve like 120fps that mavic air does and makes it slower
[22:42:50 CET] <JEEB> you can't achieve it like that (as in, you can't go as down without interpolation)
[22:43:18 CET] <JEEB> but you can make the thing a bit less jerky (maybe) with interpolation from 30 to interpolated 15 (you can't really call it real 30)
[22:43:51 CET] <GuiToris> hey, does someone have a great idea how to refer to such filenames: 00205.1.0000.png If I had only one folder, I would say ffmpeg -i 00205.1.%4d.png but the filename numbers change in every folder
[22:44:13 CET] <GuiToris> I'm trying to make a 'for' bash script
[22:44:36 CET] <JEEB> you probably can try feeding the images through a pipe
[22:44:43 CET] <JEEB> and then just set the input file to "-"
[22:44:46 CET] <JEEB> which is stdin
[22:45:59 CET] <GuiToris> every file has this syntax #####.#.%4d.png
[22:46:42 CET] <GuiToris> JEEB, do you think this would work: -i ?????.?.%4d.png
[22:47:06 CET] <JEEB> no idea, I'd probably already do the file ordering and feeding outside of ffmpeg.c
[22:47:15 CET] <JEEB> and then feed them in order through stdin
[23:34:58 CET] <kevinnn> hi, does anyone know anything about live555
[23:35:01 CET] <kevinnn> here?
[23:35:50 CET] <JEEB> it's an rtsp library if I recall correctly
[23:35:59 CET] <JEEB> haven't utilized it myself but I think vlc is still utilizing it
[23:37:42 CET] <kevinnn> yes, I am having a bit of trouble with it. It's sample .cpp files actually work great. I used it to send h264 NAL units over UDP fairly effectively. I wanted to add some encryption into the mix so I decided to encrypt the NAL units before sending them out via live555. Unfortunately they stopped being sent for some reason
[23:38:03 CET] <kevinnn> my question is do you know if live555 parses the NAL units before sending them out?
[23:40:17 CET] <JEEB> no idea, but probably yes since RT(S)P probably has various flags which have to be created after parsing the input
[23:43:50 CET] <kevinnn> well darn..
[23:44:02 CET] <kevinnn> got to figure out how to get around that
[23:44:23 CET] <JEEB> I'm pretty sure tehre's a standard mode for encryption in live555 since webrtc uses that
[23:44:42 CET] <JEEB> no idea if live555 supports that and hopefully you will gain more answers by asking those people
[23:45:31 CET] <kevinnn> JEEB: ya, but those people hate all my questions... I think I may have upset one of them
[23:45:47 CET] <kevinnn> also they do have a webrtc mode with encryption
[23:45:48 CET] <kevinnn> but
[23:45:53 CET] <kevinnn> it's closed source
[23:46:02 CET] <JEEB> how unsurprising :P
[23:46:11 CET] <kevinnn> and is to remain closed source until a certain funding goal
[23:46:21 CET] <kevinnn> unsurprising?!
[23:46:25 CET] <kevinnn> do you remember me!!
[23:46:39 CET] <JEEB> to be fully honest - no
[23:47:05 CET] <kevinnn> ah, then why is it unsurprising?
[23:47:16 CET] <kevinnn> because I have upset you many times in the past
[23:47:17 CET] <kevinnn> lol
[23:47:51 CET] <JEEB> you're not alone, I parted this channel yesterday because that's the easiest way to ignore someone who I feel isn't listening anyways
[23:48:06 CET] <JEEB> anyways, it's not surprising that they want to make a living :P
[23:50:16 CET] <JEEB> there's two ways of handling that - if you want to support those developers you support them. or you contribute somewhere else to gain an open source implementation
[23:52:28 CET] <kevinnn> well thank you for the advice... I'll look around elsewhere, see if I can't find anyone else who knows something about live555
[00:00:00 CET] --- Tue Feb 26 2019
1
0
[00:00:10 CET] <JEEB> sometimes it's leaking moderator credentials, sometimes it's just holes in the PHP stuff
[00:07:56 CET] <orlcp440> @durandal_1707: are you for real? Why? paid solutions cost $$ lol
[12:56:40 CET] <durandal_1707> bitstream parsing errors are gone, now to do actual decoding...
[13:04:54 CET] <durandal_1707> atomnuker: when you gonna finish imdct patch? i gonna implement decoding using direct form until FFT variant is implemented
[13:06:38 CET] <atomnuker> direct form?
[13:07:21 CET] <durandal_1707> direct formula
[18:13:21 CET] <durandal_1707> i wonder is way how I derive win_offset[16] array really correct
[18:13:27 CET] <cone-560> ffmpeg 03Philip Langdale 07master:96d79ff5b5c8: avutil/cuda_check: Fix non-dynamic-loader implementation
[20:42:00 CET] <cone-560> ffmpeg 03Steve Lhomme 07master:a2c7702ccf5e: avformat:matroskadec: use a define to mark the EBML length is unknown
[23:07:02 CET] <OmniBlade> I need advice on the appropriate way to handle false positives being identified for a demuxer. I'm trying to extend the old westwood aud demuxer to handle a PCM format found in the Blade Runner game.
[23:07:29 CET] <OmniBlade> However it doesn't use chunks like other file using hte format do, its just a short header followed by a raw PCM stream.
[23:08:15 CET] <OmniBlade> So when I alter the probe function to allow for unchunked PCM files I get false positives during fate incorrectly identifying some of the test files as aud files.
[23:09:11 CET] <OmniBlade> My current approach to get fate to pass is to limit the sample rates that the probe will treat as valid aud files.
[23:09:33 CET] <OmniBlade> For the unchunked PCM format anyhow.
[23:10:22 CET] <OmniBlade> Does this seem reasonable?
[00:00:00 CET] --- Mon Feb 25 2019
1
0
[03:35:15 CET] <mcurran> can anyone help me fix a (mp4) file i got from an embedded facebook video with wget? The moov file and streaming information isn't correct for vlc, so I need to reencode it somehow and was wondering if ffmpeg has that capability.
[03:39:37 CET] <DHE> usually: ffmpeg -i input.mp4 -c copy -movflags faststart output.mp4
[10:20:53 CET] <Paramonins> Why ffmpeg streaming speed is falling below 1x when I am broadcasting to youtube? I have posted more details about the problem here https://stackoverflow.com/questions/54850458/ffmpeg-youtube-streaming-quali… please help
[14:37:46 CET] <jaggz> how do I optimize this video that's mostly a slideshow? but it was streaming so there's some wiggling from encoding.. I want to shrink it down.
[14:38:43 CET] <Hello71> perhaps mpdecimate
[14:39:22 CET] <jaggz> Hello71, hallooo
[14:39:28 CET] <Hello71> no
[14:40:02 CET] <jaggz> Hello71, can it be used with crf?
[14:40:14 CET] <Hello71> wat
[14:40:28 CET] <jaggz> or do I use -b:v ?
[14:41:20 CET] <jaggz> I'm not that familiar with this, but I believe something like -b:v sets a fixed video rate, while -crf sets a quality rate to keep (and the bitrate might vary)
[14:44:08 CET] <jaggz> You cannot combine mpdecimate and mov/mp4 output in a useful way
[14:44:08 CET] <jaggz> because our mov/mp4 muxer only supports constant frame rate, this
[14:44:08 CET] <jaggz> is a known limitation of FFmpeg.
[14:44:12 CET] <jaggz> good to know :)
[14:44:30 CET] <jaggz> https://stackoverflow.com/questions/37088517/ffmpeg-remove-sequentially-dup…
[14:51:04 CET] <jaggz> https://amiaopensource.github.io/ffmprovisr/#about
[14:51:41 CET] <jaggz> cookbook of ffmpeg commands.. I think
[17:32:26 CET] <faLUCE> hello, I'm trying to change the h264 bitrate on the fly, with libav. I found this function: static void reconfig_encoder(AVCodecContext *ctx, const AVFrame *frame), in libx264.c, but it's not in the API. Nor can I extract a X264Context fro the CodecContext, because X264Context is not in the API too. So, Is there a way to get the x264 handler so I can call the reconfig() function of the x264 API ?
[17:34:07 CET] <JEEB> what do you mean with the word libav?
[17:34:12 CET] <JEEB> if you mean libavcodec within FFmpeg
[17:34:15 CET] <JEEB> then call it lavc
[17:34:16 CET] <JEEB> please
[17:34:23 CET] <JEEB> or just avcodec
[17:34:41 CET] <faLUCE> I mean libavcodec
[17:34:50 CET] <JEEB> not because I have anything against the Libav project, because I don't - just because that project exists and named itself libav
[17:35:09 CET] <JEEB> and thus just saying "libav" is in that sentence is not clear :P
[17:35:17 CET] <JEEB> yes, ok
[17:35:34 CET] <JEEB> faLUCE: see where that static function is called
[17:35:44 CET] <faLUCE> in libx264 itself
[17:35:46 CET] <JEEB> I'm pretty darn sure it gets called during when you feed the encoder an AVFrame
[17:35:50 CET] <faLUCE> in libx264.c itself
[17:35:52 CET] <JEEB> in the lavc libx264 wrapper
[17:37:25 CET] <faLUCE> JEEB: it only called in libx264.c, not in an API function
[17:37:42 CET] <JEEB> which is called from the API
[17:37:49 CET] <JEEB> just read what I just said
[17:37:50 CET] <JEEB> please
[17:37:55 CET] <JEEB> stop annoying people by not looking
[17:43:29 CET] <faLUCE> JEEB: if you don't want to answer, nobody forces you to do that. And stop telling me what I have to do with netiquette. That said, X264Context is private too, as said before. And the only way to access a LIBX264 encoder is accessing the X264Context->enc field
[17:43:49 CET] <JEEB> jesus christ
[17:44:17 CET] <JEEB> you are complaining that you cannot access reconfig_encoder in lavc/libx264.c
[17:44:28 CET] <JEEB> yet you have not looked where it's called within that file!
[17:44:28 CET] <faLUCE> JEEB: you did not read well my msg
[17:44:43 CET] <faLUCE> "Nor can I extract a X264Context fro the CodecContext, because X264Context is not in the API too. So, Is there a way to get the x264 handler so I can call the reconfig() function of the x264 API ?"
[17:45:15 CET] <JEEB> why do you need the x264 API context to begin with? you're trying to break through the abstraction
[17:45:26 CET] <JEEB> see where reconfig_encoder is getting called?!
[17:45:46 CET] <JEEB> and if you really are that blind, it's called in "X264_frame"
[17:45:57 CET] <JEEB> which is the encode function where you push a new AVFrame into the encoder
[17:46:11 CET] <JEEB> so you don't need to break through the darn abstractions if you just want to reconfigure
[17:46:18 CET] <JEEB> unless what you need to reconfigure is not supported
[17:46:25 CET] <JEEB> which you can you know - add support for
[17:46:35 CET] <JEEB> I don't get how you can look at lavc/libx264.c and not notice this stuff
[17:47:09 CET] <JEEB> I specifically told you to look at where reconfig_encoder is used in lavc/libx264.c
[17:47:21 CET] <JEEB> and you could have gotten the feeling of "oh, so I can use it like this"
[17:47:33 CET] <faLUCE> X264_frame()
[17:47:56 CET] <faLUCE> which is linked to encode2() (??) function
[17:48:16 CET] <JEEB> see the AVCodec definition for x264 at the bottom
[17:48:22 CET] <JEEB> ff_libx264_encoder
[17:48:35 CET] <faLUCE> I saqw it
[17:48:35 CET] <JEEB> that sets encode2 to ?
[17:49:03 CET] <faLUCE> I just wrote:
[17:49:07 CET] <faLUCE> "which is linked to encode2() (??) function"
[17:49:19 CET] <JEEB> ok
[17:49:27 CET] <JEEB> this is how libavcodec works
[17:49:47 CET] <JEEB> effectively your encoding function calls when you encode stuff end up calling that function with the AVFrame etc
[17:49:58 CET] <JEEB> that's how libavcodec encoders (and decoders) work
[17:50:08 CET] <faLUCE> then the functions names ARE WRONG
[17:50:12 CET] <JEEB> why?
[17:50:43 CET] <faLUCE> because it reconfigures the frame at each encoding
[17:50:55 CET] <faLUCE> it's not "reconfigure", but "configure"
[17:51:40 CET] <JEEB> it checks various values if they have changed that a user might want to reconfigure
[17:51:44 CET] <JEEB> and if they change it reconfigures
[17:51:47 CET] <JEEB> wtf is wrong for that
[17:52:08 CET] <faLUCE> reconfigure means RECONFIGURE. not "reconfigure_if_necessary
[17:52:10 CET] <faLUCE> "
[17:52:26 CET] Action: JEEB facepalms
[17:52:44 CET] <JEEB> ok, you could make the function name even longer but I don't consider it incorrect
[17:52:49 CET] <JEEB> also at that point you're looking at the internals
[17:52:50 CET] <pink_mist> faLUCE: you're welcome to fork ffmpeg and rename the function to reconfigure_if_necessary if you want
[17:52:50 CET] <JEEB> you see the code
[17:53:11 CET] <faLUCE> I consider so. In fact I thought it was a wrap for libx264 reconfigure(). It is not.
[17:53:21 CET] <JEEB> but it is a wrapper oer it
[17:53:28 CET] <JEEB> it just checks if various values have actually changed
[17:54:06 CET] <JEEB> like, by default reconfigurations can be expensive so while you want to support them you generally want to make sure that you've actually changed something
[17:54:10 CET] <JEEB> but whatever
[17:54:31 CET] <JEEB> now you know how you can reconfigure without actually having to break down the abstractions
[17:54:33 CET] <faLUCE> JEEB: I don't want to speak about useless things. It's unclear. stop. And nobody can guess that a "reconfigure" function, without any check before its call could be called at each encoding
[17:54:48 CET] <faLUCE> please stop insisting.
[17:54:55 CET] <faLUCE> now, let's do my job
[17:55:01 CET] <JEEB> no, you do your job
[17:55:15 CET] <pink_mist> brilliant, you made him leave
[20:34:09 CET] <trysten> I don't understand the conflict. Is it really about a function name?
[21:16:11 CET] <faLUCE> trysten: it's because the encode() function always calls a reconfigure() function. Check if the reconfigure must be done is inside that function, then an user can't understand what the function does really (and there's not a ret value check, in addition)
[21:17:45 CET] <faLUCE> trysten: but JEEB is too much sure about his convinctions. I'm not interested in discussing in this useless stuff
[21:20:45 CET] <faLUCE> the x264 reconfig_encoder function is properly written, because it returns a value which tells if the operation is done
[21:20:50 CET] <faLUCE> but the ffmpeg's one is void
[21:21:47 CET] <faLUCE> but JEEB would not admit that
[21:23:58 CET] <durandal_1707> faLUCE: stop talking shit
[22:34:05 CET] <trysten> durandal_1707: seems like they're just expressing their opinion that the function is improperly named while english is not their first language
[22:34:29 CET] <trysten> Seems to be self-contradicting though, saying they don't want to talk about useless stuff then arguging about function names
[22:34:50 CET] <trysten> Sorry, shouldn't have pinged.
[22:54:43 CET] <Hello71> brilliant, you made him leave
[23:04:22 CET] <c3r1c3-Win> They'll be back.
[00:00:00 CET] --- Mon Feb 25 2019
1
0
[08:00:49 CET] <orlcp440> Where can I learn about the software architecture of ffmpeg libraries? I know they have the concept of muxer/demuxer, encoder/decoder, parsers, protocols, filters etc. I would like to learn about the whole architecture so that I can contribute to the library. For example, I would like to know which module is responsible for keeping the streaming rate when sending RTP packets over IP. I am using PCM audio and sending it throug
[13:23:34 CET] <cone-322> ffmpeg 03Martin Vignali 07master:6cc8cfe30c09: avcodec/proresenc_aw : simplify frame flags
[13:23:34 CET] <cone-322> ffmpeg 03Martin Vignali 07master:2016f9c3bc23: avcodec/proresenc_aw : move picture encoding after frame header write
[13:23:34 CET] <cone-322> ffmpeg 03Martin Vignali 07master:8a4a952e45e8: avcodec/proresenc_aw : move scantable to prores context
[13:23:34 CET] <cone-322> ffmpeg 03Martin Vignali 07master:e7cbbb7374c6: avcodec/proresenc_aw : merge funcs subimage_with_fill and subimage_alpha_with_fill
[13:23:34 CET] <cone-322> ffmpeg 03Martin Vignali 07master:132ed206d6b8: avcodec/proresenc_aw : add interlace encoding
[13:23:35 CET] <cone-322> ffmpeg 03Martin Vignali 07master:37e4c226c06c: avcodec/proresenc_aw : indent after prev commit
[17:01:43 CET] <durandal_1707> hurray, today fixed 2 parsing bugs
[17:06:27 CET] <durandal_1707> only small overread from ASPX remains
[17:09:06 CET] <JEEB> najs
[21:28:45 CET] <orlcp440> Where can I find the software architecture for ffmpeg libraries? I am trying to do development on ffmpeg and not just use its libraries. One question I have is what module is responsible to send packets at a fix bitrate into RTP or is the RTP encoder/muxer supposed to do that? I see packets going out to the Ethernet network but they are going out way too fast and not at the rate I want
[21:29:38 CET] <JEEB> libavformat has protocols and muxers
[21:30:34 CET] <JEEB> (and demuxers)
[21:30:46 CET] <orlcp440> What I am doing is converting an audio into a .mkv matroska and saving it into a file with the bitrate, sampling rate and all that good info. However, I am saving raw PCM samples of the music in the .mkv file and no video. Then opening it and sending the audio to RTP
[21:30:47 CET] <JEEB> and libavcodec has the decoders and encoders
[21:32:37 CET] <orlcp440> @JEEB: Cool, is there any documentation online that explains all that? I am interested in the RTP protocol and muxing part. I had figured out a lot by a good tutorial online but I cannot find where is the module that takes care that the data is being sent to the network at a proper bitrate
[21:33:50 CET] <JEEB> rtpenc packets streams within "RTP" encapsulation, and rtpproto is the RTP protocol implementation that then passes the stuff out (or takes stuff in)
[21:33:59 CET] <JEEB> both within libavformat
[21:34:34 CET] <orlcp440> The best document/explanation of the architecture is by ffmpeg I have found is this one https://github.com/leandromoreira/ffmpeg-libav-tutorial but it does not talk about protocols nor parsers
[21:35:10 CET] <JEEB> rtpproto uses the UDP protocol within itself it seems
[21:35:27 CET] <orlcp440> @JEEB ok so far I am following and knew that part
[21:37:53 CET] <orlcp440> @JEEB: In this model you are describing do you think whatever module is passing the data to rtpenc should do it at a certain rate or should the rtpproto read some dictionary entry and learn how fast and at what rate it should send its data to the next module which in this case is UDP?
[21:38:34 CET] <JEEB> the protocol should be the one sending stuff out at some rate
[21:38:50 CET] <JEEB> the UDP protocol already has such a feature, so most likely the RTP protocol just isn't passing those options
[21:40:08 CET] <JEEB> see the AVOptions struct in udp.c
[21:40:26 CET] <JEEB> specifically the bitrate option
[21:40:49 CET] <orlcp440> So, then somehow the module that is sending the data to rtpenc should have a mechanism to tell it at what rate it wants that data to be sent to UDP so that rtpenc can pass along that information to rtpproto right?
[21:41:08 CET] <JEEB> you don't have to take it that far
[21:41:38 CET] <JEEB> just make sure RTP protocol has the way to receive an AVOption, and passes it to the UDP protocol it utilizes inside
[21:41:56 CET] <JEEB> since the RTP muxer shouldn't care about speed at all
[21:42:12 CET] <orlcp440> ohh cool, so the UDP protocol module has a bitrate info and it is the one responsible to send data at a certain rate
[21:43:00 CET] <JEEB> yes, the udp protocol already has options for that. most likely the RTP protocol doesn't, and it doesn't pass the stuff to the UDP protocol underneath
[21:43:01 CET] <orlcp440> You are a life saver @JEEB, I am going to check that out right now
[21:44:21 CET] <JEEB> do note that if the RTP protocol does not utilize all of UDP protocol underneath, then you are kind of in trouble and will have to make the logic required be shared between the UDP and RTP protocols
[21:44:47 CET] <JEEB> because the last thing you - or anyone else wants is to have the same code copypasted in both modules :P
[21:46:01 CET] <JEEB> I would guess ffurl_open_whitelist does handle quite a bit of that inside tho
[21:46:50 CET] <JEEB> yup, that opens one or more UDP protocols underneath
[21:47:11 CET] <JEEB> see rtp_open after it does the option parsing
[21:49:21 CET] <orlcp440> @JEEB: Hmm.... ok let me check that out
[21:49:33 CET] <JEEB> and in rtp_write it then calls ffurl_write
[21:49:45 CET] <JEEB> so yes, it looks like it just utilizes UDP protocol underneath
[21:49:59 CET] <JEEB> -> you should just add the relevant AVOptions to RTP and pass them down to UDP
[21:53:38 CET] <orlcp440> Ok I have to go back and see how that option gets passed by the user. I guess it would be in a dictionary, and then follow it through all the modules to make sure it gets into UDP
[21:55:15 CET] <JEEB> basically add the values for bitrate and burst_bits that are in UDPContext to RTPContext, and add those options to the AVOption list of rtpproto
[21:55:27 CET] <JEEB> that way RTP will be taking in those options, which the user can provide
[21:55:41 CET] <JEEB> since it's just adding something from one protocol to another, it shouldn't be too hard
[21:55:45 CET] <orlcp440> A lot of modules use RTP to send their media over UDP so I am sure all that mechanism is already in place. Maybe the user is not adding that bitrate entry into its dictionary
[21:56:06 CET] <JEEB> just look at the AVOption list in rtpproto :P
[21:56:12 CET] <JEEB> it doesn't have those
[21:56:34 CET] <JEEB> it has some things like pkt_size or connect that are passed through to UDP
[21:56:51 CET] <JEEB> it's just that the ones setting the speed control haven't been added
[21:56:53 CET] <orlcp440> really? so how other things do it?
[21:57:00 CET] <JEEB> wat
[21:57:26 CET] <JEEB> anything that uses the RTP protocol in FFmpeg cannot pass the options to the underlying UDP protocol
[21:57:34 CET] <JEEB> because they are... NOT THERE
[21:57:49 CET] <JEEB> you can just look at the AVOption list in rtpproto.c
[21:58:09 CET] <JEEB> it's at the top of the file together with the RTPContext which contains the variables into which the options are parsed
[21:58:10 CET] <orlcp440> @JEEB: so how are people currently doing it? It seems like a basic requirement for streaming
[21:58:38 CET] <JEEB> currently as far as I know in *FFmpeg* people just do it with raw UDP
[21:58:44 CET] <JEEB> RTP doesn't seem to have rate control
[21:58:52 CET] <JEEB> or they do rate control outside of FFmpeg
[21:59:04 CET] <JEEB> or they patch whatever I'm mentioning locally
[21:59:12 CET] <JEEB> (Because they're lazy to post the patch upstream)
[21:59:45 CET] <orlcp440> @JEEB: lol that is hard to believe for me but I guess you are right. I cannot see any other explanation
[22:00:20 CET] <JEEB> I'm a masochist that does user support on #ffmpeg and trust me 90%+ of all people just use the raw UDP protocol without RTP :P
[22:00:25 CET] <JEEB> just plain MPEG-TS over UDP
[22:00:29 CET] <orlcp440> @JEEB: I guess it will be my responsibility to do just that now
[22:01:12 CET] <JEEB> which is also most likely why the bitrate and burst_bits AVOptions are in the UDP protocol (and haven't been added to the RTP protocol)
[22:01:44 CET] <orlcp440> @JEEB: Wow, that is crazy. Well, you can tell that I am new to this whole world of digital audio/video and these libraries because I am so surprise to hear what you are telling me
[22:04:12 CET] <JEEB> lolwat, do I see correctly that the open function doesn't pass any options to ffurl_open_whitelist
[22:04:20 CET] <orlcp440> When I finished this project i am working on I will definitely send the patch upstream
[22:04:57 CET] <JEEB> ok, so it just passes the options through building a URL
[22:05:03 CET] <JEEB> well, I guess that was the older way?
[22:05:19 CET] <JEEB> nowadays you just fill an AVDictionary with the options that were set and you want to pass on
[22:05:41 CET] <orlcp440> @JEEB: Yes, dictionaries are the way to go now
[22:05:56 CET] <JEEB> orlcp440: if you have means to test quickly I can whip you up a patch
[22:06:01 CET] <JEEB> since this seems simple enough
[22:07:01 CET] <orlcp440> Yeah, but I am not at work today plus this change is a very small change as part of a whole lot of things that I am introducing
[22:08:14 CET] <orlcp440> So, it is not worth it right now for me since I want to test everything very well
[22:15:50 CET] <kierank> orlcp440: honestly anyone who wants to do proper "realtime a/v" doesn't use ffmpeg
[22:15:58 CET] <kierank> realtime as in things like rtp where you don't have 10 second like buffers
[22:15:59 CET] <kierank> like http does
[22:18:45 CET] <JEEB> the UDP protocol does seem to work surprisingly OK, with the bitrate and burst_bits options folk were getting surprisingly burst-less stuff
[22:18:59 CET] <JEEB> and the MPEG-TS muxer did surprise me at how it did indeed create a muxrate-specific mux
[22:19:14 CET] <JEEB> but yes, the defaults are for quite some buffering in various places
[22:19:39 CET] <JEEB> which is why my replies are rather inconvenient for people who ask about low latency setups on #ffmpeg, since I've not drilled into all the possible options in various things
[22:19:44 CET] <JEEB> (to enable low latency)
[22:20:58 CET] <kierank> the "real" way to do it is spin on a high priority thread
[22:21:03 CET] <kierank> you can get quite nice precision with that
[22:21:22 CET] <JEEB> yea, the UDP protocol does spin up a new thread and the whole feature is gated behind PTHREAD ifdefs
[22:22:08 CET] <kierank> the receive, right?
[22:22:10 CET] <kierank> not the send
[22:22:16 CET] <JEEB> send has that too
[22:22:26 CET] <JEEB> otherwise bitrate/burst_bits really wouldn't work that well
[22:22:37 CET] <kierank> ah
[22:22:38 CET] <kierank> interesting
[22:22:55 CET] <JEEB> yea, #if HAVE_PTHREAD_CANCEL
[22:22:56 CET] <JEEB> in there
[22:23:20 CET] <JEEB> and the write()s just keep feeding into the fifo
[22:23:24 CET] <JEEB> which the thread then handles
[22:29:22 CET] <orlcp440> @kierank: So what do people use for proper "realtime a/v" if not ffmpeg?
[22:29:30 CET] <JEEB> upipe is one thing
[22:29:35 CET] <JEEB> (which I do like various parts of)
[22:29:45 CET] <kierank> orlcp440: vlc
[22:31:24 CET] <JEEB> the RTCP thing just for the client<->server comms, right?
[22:32:35 CET] <orlcp440> @kierank: libvlc? Really? I did research on the web and found that most people/projects use ffmpeg and that is why I chose this library instead. By the way, if you are in this channel then you must find ffmpeg useful too
[22:33:05 CET] <JEEB> decoders
[22:38:22 CET] <atomnuker> files too, just not mpegts
[22:39:00 CET] <JEEB> yea but since he was talking RTP I was limiting to whatever was mostly going over UDP if looking at #ffmpeg
[22:39:03 CET] <durandal_1707> mpegts is file
[22:48:38 CET] <JEEB> orlcp440: https://github.com/jeeb/ffmpeg/commit/84c3261dd3cff17eb32aea06391bb6646311c…
[22:48:46 CET] <JEEB> dunno why I did it, but I /think/ that should be it
[22:53:00 CET] <JEEB> (I would rather use some sort of loop for the UDP protocol options since it's just the value and option name that differ in those two av_dict_set_ints - but I was lazy :P
[22:54:18 CET] <cone-350> ffmpeg 03Tristan Matthews 07master:00f54c15f45b: rtpenc_chain: forward strict_std_compliance flags to rtp muxer
[22:54:18 CET] <cone-350> ffmpeg 03Michael Niedermayer 07master:61523683c5a9: avcodec/jvdec: Check available input space before decode8x8()
[22:54:18 CET] <cone-350> ffmpeg 03Michael Niedermayer 07master:177b40890c6d: avcodec/zmbv: obtain frame later
[22:54:18 CET] <cone-350> ffmpeg 03Michael Niedermayer 07master:3f68948cb303: avcodec/pnm: Avoid structure pointer dereferences in inner loop in pnm_get()
[22:54:18 CET] <cone-350> ffmpeg 03Michael Niedermayer 07master:fc32e08941ea: avcodec/mlpdec: Insuffient typo
[22:54:42 CET] <orlcp440> @JEEB: jeez you are fast
[22:57:03 CET] <orlcp440> @JEEB: so, for realtime a/v you use upipe or libvlc?
[22:57:26 CET] <JEEB> I have been looking into upipe but currently my flow is FFmpeg-based.
[22:57:45 CET] <JEEB> and this is regarding I/O and (de)muxing stuff
[22:58:04 CET] <JEEB> you will in any case be using FFmpeg for a lot of your decoding
[22:58:45 CET] <JEEB> for encoding you can either use FFmpeg's encoders, FFmpeg's encoder wrappers (such as the one for libx264), or the other encoder libraries themselves (such as libx264 itself)
[23:06:38 CET] <orlcp440> JEEB: I see, yeah because I read somewhere that even libvlc uses ffmpeg's libraries underneath for certain things
[23:06:54 CET] <JEEB> of course it does
[23:06:57 CET] <JEEB> decoding
[23:07:32 CET] <JEEB> VLC uses its own protocol readers and writers (f.ex. it uses lib555 to do RTSP) and demuxers/muxers where possible
[23:07:42 CET] <JEEB> but then for many a format it just uses FFmpeg for decoding
[23:08:10 CET] <orlcp440> @JEEB: Interesting
[23:11:42 CET] <durandal_1707> avoid ffmpeg at all costs, use paid solutions
[23:58:04 CET] <durandal_1707> doom9 finally hacked, just needs time to get completely offline
[23:59:42 CET] <JEEB> "finally", it has had crap put onto it every now and then
[00:00:00 CET] --- Sun Feb 24 2019
1
0
[04:05:39 CET] <Aelius> I have a video that ffmpeg will not strip the subtitles from and I'm so confused
[04:06:01 CET] <Aelius> using -sn - no dice
[04:06:08 CET] <Aelius> -map 0:0 -map 0:1
[04:06:11 CET] <Aelius> no dice
[04:06:15 CET] <Aelius> the subtitle file is still there
[04:06:44 CET] <Aelius> it's even generating corrupt mp4 files because its including the subtitle as a toggleable thing in the mp4 video
[04:06:53 CET] <Aelius> which afaik is illegal for mp4 container
[04:09:10 CET] <Aelius> nvm I'm drunk
[04:11:09 CET] <Aelius> but somehow firefox still thinks the output mp4 is corrupt
[04:19:32 CET] <Aelius> yeah it's broken and I don't know why
[04:20:00 CET] <Aelius> trying to convert this mkv to mp4, it tells me it cant automatically select a codec for the subtitle file
[04:20:35 CET] <Aelius> so I convert the video without the subtitle and I extract the subtitle and attempt to burn the subs over the mp4
[04:21:43 CET] <Aelius> but actually
[04:21:46 CET] <Aelius> I was right before
[04:21:48 CET] <Aelius> Stream #0:2(eng): Data: bin_data (text / 0x74786574), 0 kb/s
[04:22:10 CET] <Aelius> this is part of the mp4 no matter what I do to tell ffmpeg to not include a damn subtitle
[04:22:11 CET] <Aelius> please help
[04:22:14 CET] <another> -dn
[04:23:30 CET] <another> or -map -0:2
[04:23:52 CET] <Aelius> Why wasn't the inclusive -map working, though?
[04:24:06 CET] <Aelius> shouldnt that only keep what I've explicitly mapped?
[04:24:09 CET] <another> good question, dunno
[04:24:17 CET] <another> should afaik
[04:26:48 CET] <Aelius> Stream map '0:2' matches no streams.
[04:26:57 CET] <Aelius> what is going on
[04:28:12 CET] <Aelius> it clearly says there's a stream 0:2, and then gives me that error when I try to deselect it
[04:28:47 CET] <Aelius> Unsupported codec with id 100359 for input stream 2
[04:29:29 CET] <Aelius> my best guess is that because there's some kind of unsupported ... something... in this file, ffmpeg is just completely not touching it no matter what I attempt
[04:33:43 CET] <furq> Aelius: pastebin the command line and output
[04:51:44 CET] <Aelius> furq: http://sprunge.us/ND9m2m
[04:53:18 CET] <Aelius> http://sprunge.us/zRCoBa ffprobe of the original file, which contains a lot of unsupported errors
[05:07:59 CET] <kandinski> how can I input BayerRG8 images into mmpeg? I'm looking at the ffmpeg.org documentation but can't find how. Is there another keyword I should search for?
[05:10:41 CET] <kandinski> in particular, I'm looking at decoding BayerRG8 images.
[05:13:01 CET] <kandinski> I don't have a video container: the device I'm working with just provides raw bayer frames, no header.
[05:17:20 CET] <kandinski> looking at the output of -pix_fmts, I see a bunch of 8-bit bayer formats, but they are named differently from the way the camera documentation does it.
[05:17:52 CET] <Aelius> what the hell..... I output it to webm and somehow 5s into the video, the width and height resolution swaps
[05:18:01 CET] <Aelius> grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
[05:21:34 CET] <kandinski> ok, I'm going to guess that BayerRG8 is what ffmpeg calls bayer_rggb8
[08:04:41 CET] <orlcp440> I have code that extracts PCM s24be audio from a matroska .mkv file and then send it over IP using RTP. However, I have to send an RTP packet every 1ms but right now it sends it way faster than that. What module is responsible to keep a packet rate (bitrate ?) constant when sending RTP packets
[10:12:34 CET] <Rooli> Hello Guys!
[10:13:48 CET] <Rooli> Does anyone here who know about NVENC and Nvidia Chips?
[10:14:22 CET] <Rooli> I would like to buy an Nvidia Card to make video encoding faster.
[10:14:52 CET] <Rooli> The new Turing chip has new features, like B-fames for x265
[10:16:04 CET] <Rooli> If I buy Pascal based card that does not support. So my question is: Is this HW feature affects ffmpeg in any way or not?
[10:18:35 CET] <Rooli> For example: I buy a Pascal 1060 or 1070, and I want to convert an AVC to x265 with 4 B-frames enabling NVENC. What will be the results? Also Turing chips has 15% quality increase in encoding.
[10:19:14 CET] <Rooli> Are these new features take effects in streaming only, or in ffmpeg too?
[10:21:57 CET] <Rooli> I think if I use ffmpeg with the command I write it has to be used by x265.exe in ffmpeg and using the GPU as a CPU and I have to have the same result no matter what HW I'm using.
[10:22:30 CET] <ritsuka> x265 is a hevc/h.265 encoder
[10:22:48 CET] <ritsuka> the nvidia gpu has its own h.265 encoder
[10:23:04 CET] <ritsuka> unrelated to x265
[10:24:20 CET] <Rooli> so if I use FFMPEG's x265 encoding commands with NVENC enabled, then FFMPEG uses the GPU's h265 encoder instead of the builtin library?
[10:25:02 CET] <Rooli> and also relies on the features of the hardware, no matter what CLI I use?
[10:25:11 CET] <ritsuka> it makes no sense, you either use x265 or the nvidia encoder
[10:25:39 CET] <ritsuka> if you tell ffmpeg to use nvenc, it will use nvenc
[10:26:17 CET] <Rooli> So Nvidia's GPU encoding is totally different than encoding with CPU?
[10:26:40 CET] <ritsuka> right, it's a piece of hardware integrated in the gpu
[10:26:54 CET] <Rooli> so let me give you an example.
[10:28:39 CET] <Rooli> I mentioned B-frames for x265. If I want to encode an x265 video with B-frames I can do it with My CPU with no problem, but it will be very slow. If I want to encode it with GPU, I have to have a Turing Chip inside, (as Pascal doesn't support it) no matter what CLI I Write. Is it correct?
[10:29:28 CET] <ritsuka> first, the video format is h.265, x265 is an encoder that outputs h.265.
[10:29:41 CET] <Rooli> ok
[10:29:52 CET] <ritsuka> And yes, the nvenc encoder will need hardware that supports b-frames
[10:31:52 CET] <Rooli> So If I want to save money and buy a GTX 1060 or 1070 and I try to make h265 videos using the card then I will not be able to produce h265 videos only in the way that the GPU allows.
[10:32:42 CET] <Rooli> Maybe I have to wait for the 1160
[10:33:10 CET] <Rooli> ritsuka, thank you very much for your help!
[13:59:48 CET] <Paramonins> Hello, I can not make a reliable stream from my Icecast server to Youtube with ffmpeg, please help. More details here: https://stackoverflow.com/questions/54841748/ffmpeg-youtube-streaming-issues
[14:01:08 CET] <JEEB> full uncut log from a known set of command line parameters onto a pastebin-like thing kthx
[14:01:11 CET] <JEEB> then link here
[14:01:53 CET] <JEEB> also for the record, -re will force (at least one thread if not all) sleep until the point of the next frame
[14:02:00 CET] <JEEB> that's how it emulates "real time"
[14:02:25 CET] <JEEB> but that's just one thing, I will not do further guesswork without a full uncut -v verbose log at the very least
[14:02:44 CET] <JEEB> (verbose level is the next one from normal, and has some extra info there while not being full-o-spam yet)
[14:02:52 CET] <JEEB> you can 2> ffmpeg.log
[14:02:56 CET] <Paramonins> thanks, can I just remove `-re` for the start?
[14:03:35 CET] <JEEB> not sure if that might go too fast then. usually I utilize something else to make a TCP or UDP stream which is going real-time so as to take the rate control out of ffmpeg.c
[14:03:47 CET] <JEEB> anyways, I'd like to see the full uncut logs with -v verbose
[14:04:16 CET] <JEEB> well you can redact credentials of course
[14:04:19 CET] <JEEB> but you know what I mean :P
[14:04:26 CET] <Paramonins> ok, let me create the log..
[14:09:44 CET] <Paramonins> here you go: https://pastebin.com/Ygh1WHZB
[14:09:53 CET] <JEEB> cheers
[14:10:30 CET] <JEEB> that hasn't finished yet
[14:10:56 CET] <JEEB> at least it hasn't failed yet
[14:11:28 CET] <JEEB> since it should say with -v verbose how many packets were read/decoded/encoded/written
[14:11:32 CET] <JEEB> at the end
[14:12:15 CET] <Paramonins> its a stream so it will not finish , the problem here is that Youtube live stream starts but saying that 65535x65535 is not supported
[14:12:35 CET] <Paramonins> anothe this is that lib
[14:12:55 CET] <Paramonins> sorry, 1 min
[14:14:11 CET] <Paramonins> Another thing is libx264 stops at this line:
[14:14:11 CET] <Paramonins> [libx264 @ 0x55ce63a05ae0] profile Constrained Baseline, level 4.0
[14:14:11 CET] <Paramonins> But if I am using flv format libx264 does initialize, at least I can see lines like
[14:14:11 CET] <Paramonins> [libx264 @ 0x563bdde386a0] 264 - core 152 r2854 e9a5903 - H.264/MPEG-4 AVC codec - Copyleft 2003-2017 - http://www.videolan.org/x264.html ...
[14:14:42 CET] <Paramonins> Can I just press [q] in my console so you can get the full log?
[14:14:53 CET] <JEEB> I'd say yes
[14:15:07 CET] <JEEB> also what is that thing with the flv / not flv?
[14:15:28 CET] <JEEB> you could attach the command to the log :P
[14:16:05 CET] <Paramonins> done https://pastebin.com/ehgD9WBC
[14:16:27 CET] <Paramonins> Please see
[14:16:28 CET] <Paramonins> https://stackoverflow.com/questions/54841748/ffmpeg-youtube-streaming-issues
[14:16:40 CET] <Paramonins> I have tried using `flv` format but it is unstable
[14:16:55 CET] <Paramonins> I have found that `fifo` format has reconnection options
[14:17:02 CET] <Paramonins> so tried that
[14:17:56 CET] <JEEB> I haven't worked with the fifo output and to be honest I'm not even sure if it does the required re-init
[14:18:48 CET] <Paramonins> ok, do you have any idea why "av_interleaved_write_frame(): Broken pipe" may be happening?
[14:18:58 CET] <JEEB> connection was closed from the other side is the most common reason
[14:19:13 CET] <JEEB> for network output that is
[14:19:21 CET] <Paramonins> Yes, I closed it by pressing [q] to get the complete log
[14:19:31 CET] <Paramonins> aha
[14:19:33 CET] <JEEB> no, that closes it from your side
[14:19:50 CET] <JEEB> which leads it to writing left-over frames and the footer if there is one
[14:19:56 CET] <Paramonins> is there a way to tell ffmpeg re-connect automatically?
[14:19:56 CET] <JEEB> and then closing the connection
[14:20:03 CET] <JEEB> no
[14:20:07 CET] <JEEB> also it's protocol specific
[14:20:22 CET] <JEEB> not to mention that since you've thrown random fifo stuff there I'm not even sure if your thing is doing the right thing
[14:20:43 CET] <JEEB> it doesn't help that you are not showing which command you utilized for the pastebin you posted
[14:21:09 CET] <JEEB> I am not sure if the fifo thing you're using is even supposed to work like you're trying to utilize it - and it doesn't help that you don't post the command line
[14:21:23 CET] <Paramonins> command: https://pastebin.com/V8CFrQ19
[14:21:43 CET] <JEEB> (next time please post them together then posting a log)
[14:22:03 CET] <Paramonins> ok, sure
[14:22:05 CET] <JEEB> ok, so the fifo thing at least lets you set up the sub-muxer
[14:22:28 CET] <JEEB> but yea, most likely rtmp_live does not get passed through for example
[14:22:39 CET] <JEEB> or maybe it is if it's the protocol
[14:22:48 CET] <JEEB> this looks messy and I have no idea how much of a hack the fifo thing is
[14:23:08 CET] <Paramonins> I have tried w/o rtmp_live with the same result, let me try one more time....
[14:23:17 CET] <JEEB> yea, that was my bad
[14:23:20 CET] <JEEB> it's a protocol option probably :P
[14:23:39 CET] <JEEB> and your protocol still is rtmp
[14:23:46 CET] <JEEB> although how the flying asdf is that even working
[14:24:00 CET] <JEEB> how is a "muxer" supposed to retry stuff
[14:24:23 CET] <JEEB> so many questions due to how this breaks the layers of abstraction
[14:25:06 CET] <JEEB> and since this doesn't seem to work at all for you to begin with it really sounds like whomever made this never tried rtmp or even thought of it when developing it
[14:25:19 CET] <JEEB> unfortunately we've got quite a few of such "some random person's pet module"s in there
[14:25:33 CET] <JEEB> which do work - for some specific use case :P
[14:25:52 CET] <JEEB> and then we get normal users here attempting to use them like they think it should be usable
[14:25:59 CET] <JEEB> *they should be usable
[14:26:20 CET] <JEEB> Paramonins: I would also recommend testing this with a recent FFmpeg master. I think there's some linux builds linked from ffmpeg.org by someone from this channel
[14:26:32 CET] <JEEB> so you can just try running a binary from your home dir
[14:26:51 CET] <JEEB> as in, instead of /usr/bin/ffmpeg it'd be ./ffmpeg for the current directory, for example
[14:26:52 CET] <Paramonins> my original command w/o using fifo: https://pastebin.com/yQRhET0S - this thing is working, the stream is playable but it randomly stops at diffrent time. Basically yes, I am just trying random command line options... ffmpeg docs are very unclear.
[14:27:14 CET] <JEEB> yea, that looks like normal FLV -> RTMP thing
[14:28:38 CET] <Paramonins> yes, and this just stops playing with "av_interleaved_write_frame(): Broken pipe" and stops with signal 15 caught.
[14:29:27 CET] <JEEB> which means that at some point the other side drops the connection
[14:31:49 CET] <JEEB> if you are OK with spam, look into -debug_ts
[14:31:59 CET] <JEEB> I mean, it spams a whole lot less than -v debug
[14:32:09 CET] <JEEB> but still I think 3-4 lines per frame
[14:33:38 CET] <Paramonins> ok, so `fifo` will not help in this case - when the peer drops the connection. I will try the latest build and use `flv` codec, at least it is working. Weird there is no way to reconnect in case some network error for example.
[14:34:04 CET] <JEEB> s/codec/format/
[14:34:24 CET] <Paramonins> yes, sorry, format
[14:34:32 CET] <JEEB> Paramonins: for various protocols how much you need to do handshaking again would be rather specific to that
[14:34:40 CET] <JEEB> also there usually can be some other reason why it's kicking you off
[14:34:49 CET] <JEEB> and just shrugging that off might not be the right thing to fix
[14:35:53 CET] <Paramonins> agree
[14:37:40 CET] <JEEB> if you're on *nix you might want to stick your process under systemd or upstart or whatever your init system is
[14:37:45 CET] <JEEB> as a one-shot service
[14:37:54 CET] <JEEB> as that will also provide timestamps
[14:37:59 CET] <JEEB> for the log
[14:38:05 CET] <JEEB> esp. if you want to enable stuff like -debug_ts
[14:38:33 CET] <JEEB> then you know when exactly a packet was read from input, when exactly it was passed to decoding/encoding and when it was finally passed on to be written into the FLV writer (That's then connected to the RTMP protocol)
[14:38:50 CET] <JEEB> so you could debug if it's faulty timestamps or a timeout somewhere for some reason
[14:39:26 CET] <JEEB> because both -loop and -re could have interesting interactions if f.ex. loop jumps the input timestamp for some reason
[14:39:27 CET] <Paramonins> I have tried restarting ffmpeg in case of failure - but Youtube live stream URL changes every time, that will not work for me
[14:39:42 CET] <JEEB> and then -re would just sleep() for that large difference
[14:40:06 CET] <Paramonins> testing with ffmpeg-4.1.1 and -v verbose now
[14:40:25 CET] <JEEB> (just grab a master build unless fate.ffmpeg.org is red)
[14:40:31 CET] <JEEB> (for your type of system)
[14:40:44 CET] <JEEB> FATE being the automated test system
[14:41:10 CET] <Paramonins> ok, thanks
[14:42:02 CET] <Paramonins> removed `-re` for testing as well
[14:42:32 CET] <JEEB> since your input is files it might just go too fast in that case
[14:42:48 CET] <JEEB> although it might do better with the audio being live
[14:43:02 CET] <JEEB> so the interleaved writes might just buffer your video frames at encoding speed
[14:44:27 CET] <Paramonins> my video is basically a jpeg file - it always shows a single image
[14:44:32 CET] <Paramonins> as a logo
[14:44:46 CET] <Paramonins> the main content here is audio (music)
[14:45:18 CET] <Paramonins> since its a single image I set `-framerate 1`
[14:45:27 CET] <Paramonins> the minimum framerate possible
[14:45:29 CET] <JEEB> right, it just looked like you had multiple since you had %d
[14:45:32 CET] <Paramonins> saves lots of CPU
[14:45:38 CET] <JEEB> I think you had a pattern there
[14:46:50 CET] <Paramonins> no, that's a single file
[14:48:00 CET] <JEEB> but for a single frame I'm not sure if a generated filter chain would be better that would generate X fps constant input so you wouldn't have to use -loop
[14:48:19 CET] <JEEB> or alternatively you have a HTTP server that never sends out EOF serving the image
[14:48:43 CET] <JEEB> although I'm just thinking aloud at this point
[14:49:16 CET] <JEEB> anyways, test with current version and possibly test with -debug_ts to see if any anomalies in timestamps or so would pop out
[14:49:44 CET] <JEEB> at that point it would be useful to get timestamps in the logs to see the difference of different lines, but for that you'd have to strap your thing into a service system or so
[14:49:45 CET] <Paramonins> yep, thanks a lot! testing now.
[20:31:10 CET] <Guiri> I'm having a bit of trouble understanding the documentation on filters. It looks like I can't use -vf with filter_complex. I'm trying to figure out how to scale down a chain of movies using the concat filter. Here's what I have so far for the CLI chain: https://paste.fedoraproject.org/paste/pT23jIoVGgQMLxS~GKXmhg
[20:31:43 CET] <durandal_1707> Guiri: filters are separated by ,
[20:32:04 CET] <durandal_1707> you can not use -filter_complex and -vf at same time
[20:32:42 CET] <Guiri> So if I use scale with filter_complex is it ,video='scale=...' or ,scale=-2:480?
[20:37:11 CET] <furq> Guiri: if you want to scale after concat then concat=n=3,scale=-2:480
[20:39:08 CET] <Guiri> ty
[22:25:44 CET] <paveldimow219> Hi, is it possible to set profile-iop in cli? I need to set profile-level-id 420e1f when using H.264 with WebRTC
[22:26:32 CET] <paveldimow219> sorry 42e01f
[22:27:17 CET] <paveldimow219> I can set Baseline profile (42) and level 3.1 (1f) however I can't find anything about profile-iop (E0)
[22:32:11 CET] <JEEB> paveldimow219: is that even in the H.264 spec?
[22:32:42 CET] <JEEB> and then again, it's the encoder that needs to support that as well
[22:32:50 CET] <JEEB> it's the one that will be actually writing the profile value
[22:33:57 CET] <furq> what makes you think you need that exact value
[22:34:39 CET] <paveldimow_> well the thing is that my workflow is liek this: encoder -> ffmpeg -> wowza
[22:35:17 CET] <furq> i'm looking at the spec and i'm pretty sure 0x80 and 0xE0 are identical for baseline profile
[22:35:26 CET] <furq> and you should get 0x80 by default if you use constained baseline
[22:35:35 CET] <furq> r
[22:35:37 CET] <JEEB> constrained baseline is the thing that everything supports
[22:35:40 CET] <JEEB> not actual baseline
[22:35:41 CET] <furq> right
[22:35:45 CET] <JEEB> since baseline has some features that are not in main
[22:36:03 CET] <JEEB> because reasons and early 2000s still not having worn off of the stuff they smoked in the late 1990s
[22:36:50 CET] <paveldimow_> but my problem is Chrome and webRTC
[22:36:52 CET] <paveldimow_> they say
[22:37:02 CET] <paveldimow_> Chrome h264 renderer is only supporting the baseline-constrained profile (42E01F)
[22:37:42 CET] <furq> actually nvm
[22:37:55 CET] <paveldimow_> nvm?
[22:40:54 CET] <paveldimow_> I don't know if that means that I wrote something stupid and I am missing something or ?
[22:41:02 CET] <furq> no it means i wrote something stupid
[22:42:09 CET] <paveldimow_> Ah ok
[22:42:25 CET] <furq> E0 definitely seems wrong
[22:42:31 CET] <furq> that's for extended profile
[22:43:41 CET] <paveldimow_> but if I understand what JEEB wrote, I just need to set constrained baseline profile not extended?
[22:45:48 CET] <JEEB> I don't know what webrtc requires
[22:45:57 CET] <JEEB> but I have heard constrained baseline, not extended
[22:46:03 CET] <JEEB> if extended is a thing that exists and is required
[22:46:09 CET] <JEEB> (check both H.264 and webrtc *specs*)
[22:46:39 CET] <JEEB> then you will probably want to make sure the H.264 encoder you're using is creating that (if you are encoding through FFmpeg)
[22:46:57 CET] <JEEB> f.ex. if libx264 doesn't support that, then you will have to send them a patch for it
[22:49:55 CET] <paveldimow_> Ok, I will take a look at the specs. Thank you furq and JEEB for your help!
[23:49:24 CET] <Guiri> I read up on filter_complex and got a basic concat chain working. I'm still having a bit of trouble on scaling and padding the inputs. Could someone take a look? https://paste.fedoraproject.org/paste/QVrIeJznBZn-FRgZ-dCqzQ
[23:49:52 CET] <Guiri> furq's adviced above worked initally, except I was getting a padding error in a few cases with some test videos
[23:50:31 CET] <furq> well first of all you can replace all those [s1];[s1] etc with ,
[23:50:47 CET] <Guiri> ok
[23:51:18 CET] <furq> also define padding error
[23:51:56 CET] <Guiri> this is the error: https://paste.fedoraproject.org/paste/XIZ9XDAVY0A0JQIEaatTuQ
[00:00:00 CET] --- Sun Feb 24 2019
1
0