Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

November 2019

1 participants
60 discussions

ffmpeg-devel.log.20191124
by burek 25 Nov '19

25 Nov '19

[04:16:57 CET] <lf94> Hey, for some reason av_find_decoder is failing when trying to find h264. Now I have no idea why it would fail because all sources point to me having this format is built in / available [04:17:18 CET] <lf94> I'm guessig that maybe the code I'm looking at doesn't call some function to fill what codecs are available [04:17:35 CET] <lf94> https://www.ffmpeg.org/doxygen/2.7/libavcodec_2utils_8c_source.html <- here I see first_avcodec starts as NULL, but I can't find where it gets initialized. [04:26:01 CET] <lf94> Ah ha!! [04:26:10 CET] <lf94> avcodec_register_all(); [11:47:07 CET] <BtbN> lf94, register_all is deprecated, unless you are using a really old version, it does nothing. [12:03:28 CET] <j-b> Isn't the new codec missing version.h bump? [12:04:04 CET] <durandal_1707> j-b: that is added as last step before pushing [12:05:42 CET] <Lynne> can agree, the vulkan patchset carries the version bump along with it and every pull I have to fix conflicts [12:31:58 CET] <kurosu> regarding the cached bitstream reader (or whatever implementation, either libav or ffmpeg), I did see speed improvements on both x86_32 and x86_64, although the former could have further optimization (like, peeking at 32 bits when < 16 is probaly sufficient - dunno about malformed bitstreams) [12:34:08 CET] <Lynne> I don't understand how it isn't always faster, even in the worst case it should save instructions [12:36:57 CET] <kurosu> current implementation is 64bits cache, which requires compiler being smart in its emulation [12:37:24 CET] <kurosu> but most such codecs (lossless or near lossless) indeed should see such a benefit [12:39:58 CET] <Lynne> it shouldn't be difficult to make it a 32 bit cache though [12:40:20 CET] <kurosu> Yes, just need someone having a reason to do it [12:40:53 CET] <kurosu> Also done in dav1d, but which one is used is unconditional [12:41:17 CET] <JEEB> does the unregistered sei UUID 162,229,107,0,67,99,70,214,162,70,210,91,146,163,98,89 strike anyone as familiar? [12:41:28 CET] <kurosu> *to do it, or publish his patches :D [12:41:31 CET] <JEEB> it's some dolby thing and I am guesstimating it's the dynamic metadata [12:42:29 CET] <JEEB> I have ST.2094-1 and -10 but conveniently neither of them seem to define the SEI message ID [16:19:59 CET] <JEEB> alright. any opinions on where to stick non-ITU AVColorspace entries? either over 255 because the ITU enum is 8bit (currently) or negative (but we already have things indexing with the enum values) [16:20:18 CET] <JEEB> zimg took the negative value approach apparently [16:28:37 CET] <durandal_1707> JEEB: +666 [16:30:05 CET] <JEEB> durandal_1707: I like your positive attitude. noted [16:31:28 CET] <durandal_1707> JEEB: if starting from +666 is to evil to you, use 1707 number [20:16:54 CET] <durandal_1707> Compn: you still awake? [22:50:05 CET] <cone-895> ffmpeg 03Andreas Rheinhardt 07master:4470ab1e0ee1: avformat/matroskaenc: Fix potential leak of cached packet [22:50:05 CET] <cone-895> ffmpeg 03Andreas Rheinhardt 07master:6eb88daed105: avformat/matroskaenc: Remove outdated comment [00:00:00 CET] --- Mon Nov 25 2019

1 0

ffmpeg.log.20191124
by burek 25 Nov '19

25 Nov '19

[00:20:56 CET] <void09> padding [00:21:54 CET] <jemius> 265 is really impressive. Reducing (264) from 9.1 GB to 1.1GB without visible differences. Codecs are black magic [00:23:16 CET] <furq> that doesn't sound representative [00:23:26 CET] <nicolas17> I tried 265 with low quality, and there were artifacts when looking at individual frames, but in motion they were pretty hidden [00:24:03 CET] <nicolas17> "reducing from x to y" doesn't say much though, what if the source video had very high bitrate? :P [00:24:59 CET] <jemius> furq, it is not, typically my stuff is 25% to 50% as large. But this time it apparantly worked very well. Also, the audio stream was transcoded from some apple foo to vorbis [00:30:07 CET] <void09> jemius: try av1 :P [00:30:24 CET] <void09> intel's encoder if you care for reasonable speed [00:30:33 CET] <jemius> void09, the encoder has 0.2 fps on my machine, so: No ;) [00:30:41 CET] <nicolas17> matches my experience [00:30:44 CET] <nicolas17> also terrible multithreading [00:30:47 CET] <void09> 0.2 fps is great speed [00:30:56 CET] <nicolas17> but I heard rav1e is much faster [00:31:04 CET] <jemius> I could draw the bloody frames faster with a pencil [00:31:05 CET] <void09> svt-av1 is good for speed though, and lately i've seen reports that it outmatches x265 at some quality/speed level [00:31:20 CET] <nicolas17> what is svt? I saw the instructions for compiling with svt but no information on what it *is* [00:31:40 CET] <void09> https://github.com/OpenVisualCloud/SVT-AV1/ [00:31:58 CET] <void09> it's intel's open source implementation of an av1 encoder [00:32:06 CET] <JEEB> SVT-AV1 has a crappy rate control but it's the one you use for live streaming proofs of concepts atm [00:32:15 CET] <JEEB> and seemingly netflix also employs some people poking at it [00:32:25 CET] <furq> unless you're on amd obviously [00:32:38 CET] <JEEB> I'm not sure if the perf is much worse on AMD [00:32:39 CET] <nicolas17> is it "just" faster? the "scalable" part made me think it was for SVC [00:32:58 CET] <void09> performance is pretty decent on amd, probably less than intel, but not bad [00:32:59 CET] <JEEB> nicolas17: nah, this is just scaling through cores/NUMA nodes [00:33:26 CET] <JEEB> https://twitter.com/videolan/status/1172811555387432960 [00:33:37 CET] <furq> well it says "highly optimized for Intel® Xeon® Scalable processors and Intel® Xeon® D processors" which i guess nowadays implies "until we had to disable all that through microcode or else your ssh keys would be flashed on screen constantly" [00:33:38 CET] <JEEB> it's the encoder you can make demos like this with with a rack server [00:33:51 CET] <void09> but i plan to use only libaom at the slowest speed setting. or maybe even that VVC codec, i've seen a recent comparison where it's way better than av1 [00:33:53 CET] <JEEB> furq: I have a feeling that is just copypasted marketing wank [00:34:03 CET] <JEEB> furq: they don't actually disable stuff on non-intel [00:34:24 CET] <JEEB> they just always have to have the marketing thing there to remind other people why intel is putting time & money into it [00:34:52 CET] <JEEB> because you can see the same kind of wording with other intel open source projects that don't really have much if anything to do with performance :P [00:35:16 CET] <JEEB> it is the internal sales pitch / reasoning for a non-sales thing to exist, I guess? [00:35:52 CET] <JEEB> the actual open source devs don't really care about making it less performant on non-intel [00:35:59 CET] <nicolas17> well, it depends on what you mean [00:36:06 CET] <JEEB> at least that's what my experience is [00:36:36 CET] <nicolas17> "highly optimized for Intel" is marketing [00:37:05 CET] <nicolas17> "we don't guarantee the effectiveness of optimization for non-Intel processors" is a disclaimer they're forced to add due to a legal settlement [00:37:20 CET] <furq> was that after the whole icc GenuineIntel saga [00:37:36 CET] <nicolas17> I think so [00:37:43 CET] <furq> i guess that was 10 years ago already [00:37:48 CET] <nicolas17> https://github.com/OpenVisualCloud/SVT-AV1/blob/master/NOTICES.md [00:38:05 CET] <JEEB> and yea, ICC was not open source so it's much easier for such projects to add random stuff the management happens to want [00:38:18 CET] <furq> yeah that makes sense [00:38:23 CET] <JEEB> fun fact: according to my info ICC isn't even utilized too much in their open source [00:38:25 CET] <furq> i thought svt was embroiled in that for some reason [00:38:33 CET] <JEEB> SVT is actually bought tech & team [00:38:40 CET] <JEEB> intel bought the company developing it [00:38:44 CET] <JEEB> then made it OSS [00:38:46 CET] <furq> i'm probably getting it mixed up with ipp [00:38:51 CET] <JEEB> kind of like Google bought On2 [00:40:26 CET] <nicolas17> the story is like "google bought on2, released VP8 as-is as soon as they could, and then the internet noticed it sucks"? [00:40:39 CET] <nicolas17> I've read bad stuff about VP8 and libvpx :P [00:40:46 CET] <JEEB> libvpx literally just does what google needs [00:40:55 CET] <JEEB> which is why it's good that AV1 has multiple encoders [00:41:07 CET] <furq> has aom actually got any faster lately [00:41:25 CET] <furq> or have they just resigned it to being some kind of reference encoder already [00:41:32 CET] <nicolas17> furq: dunno about 'lately', but last I tried, master was indeed faster than 1.0 [00:41:44 CET] <furq> i've not really looked into it since 1.0 [00:41:44 CET] <nicolas17> dunno if it got even better since [00:41:45 CET] <furq> so that counts [00:42:05 CET] <nicolas17> the multithreading sucks [00:42:12 CET] <furq> well what else is new [00:42:58 CET] <JEEB> they're optimizing libaom, but it will forever be the google-coder [00:43:08 CET] <furq> i still can't get vpx to use more than ~4 cores on 1080p even with row-mt [00:43:30 CET] <furq> logical, not physical [02:02:26 CET] <void09> what could I use to apply some procedural alterations to a video stream, in real time, without re-encoding it. for example, to view a tv capture with the logo blurred out [02:02:46 CET] <furq> -f nut -c:v rawvideo - | mpv - [02:03:06 CET] <furq> or just mpv --vf if your filtering needs are simple enough [02:03:27 CET] <void09> I have no idea how simple or complex they are [02:03:51 CET] <void09> that's the only one I can think of at the moment, to blur or remove a logo (by using the surrounding pixel info [02:04:34 CET] <void09> what could i use for that ? [02:08:57 CET] <Damme> I feel more stupid now after a few hours playing around with ffmpeg... Does anyone have the patiance to help me get tonemap to work ? I want to map colors so a 10bit -> 8bit conversion doesn't look pale. I am totally lost [02:09:33 CET] <JEEB> I think I just helped someone here with that a few days ago [02:09:52 CET] <Damme> I think I can hear the arrow up key ;) [02:10:02 CET] <JEEB> the fully software tonemap filter (older) requires linear rgb which only the zimg based zscale filter can produce [02:10:18 CET] <JEEB> the opencl tonemap filter (newer) can do the linear'ization [02:10:32 CET] <Damme> ahh, so I really need zscale ? I found a few threads about that on different forumt [02:10:33 CET] <Damme> s* [02:10:34 CET] <JEEB> I looked at the code and it seemed to be relatively simple to add that to the sw one too [02:10:44 CET] <JEEB> Damme: for the older fully software filter, yes [02:11:21 CET] <Damme> ffmpeg -h filter=tonemap_opencl [02:11:22 CET] <Damme> ops [02:11:27 CET] <JEEB> -vf "zscale=transfer=linear,tonemap=mobius,zscale=transfer=bt709,format=yuv420p" [02:11:36 CET] <JEEB> Damme: that then needs opencl and the hwupload thing [02:11:47 CET] <JEEB> look for ffmpeg-all.html on ffmpeg.org for the up-to-date docs [02:11:54 CET] <JEEB> in addition to that of course [02:12:57 CET] <Damme> yep, I'll need to get zscale to work to begin with atleast :) Running arch, donno if there is an aur for that yet [02:17:14 CET] <void09> JEEB: any idea for software that can apply procedurally written alterations/filters to a video stream, that works on both linux /windows? [02:17:47 CET] <void09> without needing re-encode, of course [02:22:48 CET] <nicolas17> what [02:22:56 CET] <nicolas17> you can't do that kind of stuff to a video without reencoding [02:23:04 CET] <nicolas17> unless you mean doing it on the fly while playing it [02:24:03 CET] <furq> void09: do you need to change the filter on the fly while it's running [02:24:27 CET] <nicolas17> looks like mpv uses lavfi filters [02:26:39 CET] <nicolas17> void09: search in ffmpeg video filters how to blur a logo, I think there's a delogo filter [02:29:00 CET] <void09> there's ffmpeg filters for this? [02:30:07 CET] <void09> I was thinking something like some kind of scripting language that works with pixels and coordinates, so you can use it cross platform. I think avisynth has something like this [02:30:57 CET] <Damme> How come ffmpeg doesn't have libac anymore ? what is the idea to use instead? [02:31:09 CET] <Damme> libav* [02:31:10 CET] <furq> void09: https://ffmpeg.org/ffmpeg-filters.html#program_005fopencl-1 [02:31:20 CET] <DHE> what's libav? [02:32:06 CET] <Damme> If I'm not totally wrong, support for zscale (libzimg / libav?) [02:32:31 CET] <furq> it does have support for zscale [02:32:39 CET] <DHE> libzimg is a feature you can import if the library is available [02:32:55 CET] <Damme> aaaha [02:33:06 CET] <Damme> I tought I needed to recompile ffmpeg lol [02:33:09 CET] <JEEB> yes [02:33:11 CET] <DHE> well you do... [02:33:16 CET] <DHE> ./configure detects it [02:33:20 CET] <Damme> ok [02:33:23 CET] <JEEB> the module needs to be enabled and for that you need to have zimg available [02:33:25 CET] <furq> i had to doublecheck that he hadn't actually renamed it libav [02:33:31 CET] <JEEB> lol [02:33:32 CET] <furq> don't worry everyone [02:33:43 CET] <JEEB> nah, he's happy trying to have z.lib [02:33:50 CET] <DHE> haha [02:33:56 CET] <Damme> :| [02:34:14 CET] <void09> https://ffmpeg.org/ffmpeg-filters.html#delogo [02:34:23 CET] <void09> there is a delogo filter indeed [02:34:43 CET] <JEEB> Damme: basically build/install https://github.com/sekrit-twc/zimg [02:35:00 CET] <furq> void09: if you just want a cross-platform avisynth then use vapoursynth [02:35:23 CET] <void09> not sure what i want, i have not researched this domain yet [02:35:29 CET] <JEEB> and then rebuild FFmpeg with --enable-libzimg [02:35:35 CET] <JEEB> and that will enable the zscale filter [02:36:11 CET] <Damme> JEEB, thanks, I understand now :) and I found tons of different zscale examples so I think I'll solve this now :) [02:36:12 CET] <JEEB> Damme: it's in my plans to enable support for yuv420p10 but it's not exactly on the top of my priority. I did check the opencl filter and it *probably* isn't too complex to add the linearization there [02:36:45 CET] <JEEB> zimg itself can do the conversion, but it will not tone map. it will just cut at 100 nits [02:36:53 CET] <JEEB> since tone map is not standardized [02:37:13 CET] <JEEB> but you can use it + one of the tonemap filters to get a proper tone map [02:37:28 CET] <Damme> aah ok. [02:37:53 CET] <JEEB> -vf "zscale=transfer=linear,tonemap=mobius,zscale=transfer=bt709,format=yuv420p" [02:37:54 CET] <JEEB> like this [02:38:14 CET] <JEEB> "convert to linear RGB with zscale, do mobius tonemap, convert to 8bit 4:2:0" [02:38:38 CET] <Damme> ah, now I understand the filter arguments.. It really confused me [02:38:39 CET] <JEEB> anyways, sleep time for me [02:38:48 CET] <Damme> Good night JEEB! [02:38:53 CET] <JEEB> the format at the end is a "meta" filter [02:39:10 CET] <JEEB> it basically sets the output pixel format for the filter before it [02:39:34 CET] <JEEB> that way zscale there ends up outputting yuv420p (8bit, 4:2:0 YCbCr) [02:39:38 CET] <JEEB> anyways, night'o indeed [02:41:12 CET] <void09> delogo=x=0:y=0:w=100:h=77:band=10 [02:41:21 CET] <void09> how would one apply this filter and pipe the output to mpv ? [02:44:29 CET] <furq> -vf "delogo=x=0:y=0:w=100:h=77:band=10" -f nut -c:v rawvideo - | mpv - [02:44:36 CET] <furq> or mpv --vf "delogo=x=0:y=0:w=100:h=77:band=10" [02:45:14 CET] <void09> [lavfi] AVOption 'band' not found. [02:45:32 CET] <void09> they changed the code and didn't update the docs? [02:46:08 CET] <DHE> mpv -vf lavfi=[delogo=....] input.mkv [02:46:08 CET] <furq> it does mention that band is deprecated [02:46:15 CET] <furq> DHE: do you still need that [02:46:26 CET] <DHE> dunno. my build of mpv is actually kinda old... [02:48:35 CET] <furq> yeah you've not needed that for a while [02:49:00 CET] <void09> furq: i removed "band" and it works :D [02:49:07 CET] <void09> also needed to update x,y coordinates [02:49:56 CET] <void09> it did not work with 0. I think they updated the code to begin with pixel number 1? [02:55:04 CET] <void09> now time to try tthe remove logo thingie, seems more advanced [03:04:34 CET] <void09> wow that worked on the first try [03:04:54 CET] <void09> mpv --vf "removelogo=f=nocmlogo.bmp" outputvideo.mkv [03:06:28 CET] <void09> although i expected a bit better results [03:55:35 CET] <Atlenohen> Hey guys [03:56:02 CET] <Atlenohen> someone said ffprobe analyzes a few frames and reports timecodes, but what if I use analyze_duration and the sizes maxed out? [03:56:34 CET] <Atlenohen> And also, I told it to show all frames, and I went manually thoguht the PTS ... [03:57:00 CET] <Atlenohen> Is that really getting to the bottom of it? [04:07:48 CET] <lf94> Hey, is it possible to find out why av_find_decoder is failing? Where it is looking? [04:08:04 CET] <lf94> It can't find H264 on Debian 9. ffmpeg -version shows its built in [04:08:16 CET] <lf94> (I assume libavcodec has it too then) [04:59:52 CET] <Damme> 4k to 1080p, using scale=1920:-1 and -c:v libx264 -crf 16 -preset slow -tune film but I still think the output is a bit too blocky, is two stage to go or go even lower with crf ? [05:02:31 CET] <furq> if you mean 2pass then it makes no difference to quality [05:02:37 CET] <furq> the first pass just picks a crf value for the second pass [05:03:30 CET] <furq> you should probably try a slower preset before lowering the crf more [05:07:00 CET] <Damme> ah thanks [05:09:46 CET] <gp> I was just looking through history and saw opus in mp4 was added as experimental in 2017. What exactly does experimental mean? Does it mean likely someone will be able exploit and rm -rf / my system or that perhaps I git a few bits of audio that aren't exactly right? [05:10:44 CET] <gp> or somewhere in between i am guessing? [07:27:11 CET] <void09> anyone here played with the removelogo filter ? I want to know if it's possible to make a part of the logo completely removed (replaced with black pixels) instead of using dither for those pixels [07:41:07 CET] <Al_nz1> Hello [07:41:58 CET] <Al_nz1> I am trying to create a movie wtih 5ffmpeg.exe -framerate 24 -i 2019-11-2%1d_*.jpg mm2019.mp4 [07:42:42 CET] <Al_nz1> but i get could find no file with path 2019-11-2%1d.jpg and index in the range [07:43:06 CET] <Al_nz1> the directory is full of files 2019-11-21_15_30_10_HVO.jpg [07:44:42 CET] <montana> 5ffmpeg.exe ? [07:44:49 CET] <montana> is that a typo? [07:45:16 CET] <Al_nz1> montana: yes type [07:45:18 CET] <Al_nz1> tpo [07:45:20 CET] <Al_nz1> typo [07:45:25 CET] <montana> can you retype it then [07:45:53 CET] <Al_nz1> I have renamed the files to mm1 (1).jpg to mm1 (654).jpg [07:46:33 CET] <Al_nz1> Could find no file with path 'mm*.jpg' and index in the range 0-4 [07:46:33 CET] <Al_nz1> mm*.jpg: No such file or directory [07:46:52 CET] <Al_nz1> ffmpeg.exe -framerate 24 -i mm*.jpg mm2019.mp4 [07:47:52 CET] <montana> don't put spaces on the name [07:47:57 CET] <montana> that will fix it [07:49:47 CET] <Kadigan> Al_nz1: in general, it helps that the %1d and such others are printf formats, so you can find info on them on the Internet. [07:50:06 CET] <Al_nz1> the file name format is now 2019-11-23_03_55_37.268_HVO.jpg [07:50:11 CET] <Al_nz1> but same error [07:50:35 CET] <montana> what are you typing exactly [07:50:54 CET] <Al_nz1> https://imgur.com/a/0rGOfjo [07:51:28 CET] <montana> don't put * [07:51:37 CET] <montana> on the name [07:52:39 CET] <Al_nz1> what do i put the name as? [07:52:42 CET] <montana> are you trying to batch it? [07:52:54 CET] <Al_nz1> yes - create a video from a series of stills [07:54:17 CET] <montana> i see [07:54:17 CET] <Al_nz1> 2019-11-23_03_55_37.268_HVO.jpg is yyyy-mm-dd_hh_mm_ss.ddd_HVO.jpg [07:54:31 CET] <montana> then you have to type the name of every still image [07:54:52 CET] <montana> ffmpeg won't understand "*" [07:55:04 CET] <montana> or go to use powershell [07:55:13 CET] <montana> or use powershell to script it [07:55:27 CET] <Al_nz1> https://stackoverflow.com/questions/50643085/generate-a-2-fps-mp4-from-imag… [07:55:31 CET] <montana> /join #powershell [07:55:46 CET] <montana> then you have to type the name of every still image [07:56:05 CET] <Al_nz1> or : https://stackoverflow.com/questions/24961127/how-to-create-a-video-from-ima… [07:56:57 CET] <Al_nz1> i dont understand fully all the wild card options like %03d ? [07:57:05 CET] <montana> basically your question is about scripting [07:57:13 CET] <montana> NOT ffmpeg [07:57:33 CET] <montana> Al_nz1 basically you are to lazy to type out every still image file name [07:58:05 CET] <Al_nz1> when there is 600 yes!! [07:58:12 CET] <montana> lol, fair enough [07:58:17 CET] <montana> /join #powershell [07:59:33 CET] <montana> Al_nz1 ask how to script every file name automatically [08:01:26 CET] <montana> Al_nz1 why aren't you asking [08:42:23 CET] <kepstin> fwiw, ffmpeg can do multi-frame picture with glob inputs (using *? wildcards), but i think it only works on linux [08:42:59 CET] <kepstin> and you generally can't put that many file inputs on an ffmpeg command line due to command line length limits. plus it would just be a pain to combine them into a video. [08:45:12 CET] <montana> why doesn't this work? ffmpeg.exe -framerate 24 -i 1.jpg -2.jpg -3.jpg output.mp4 [08:45:30 CET] <montana> why doesn't this work? ffmpeg.exe -framerate 24 -i 1.jpg -i 2.jpg -i 3.jpg output.mp4 [08:47:41 CET] <kepstin> that creates three separate video streams, each containing only one frame [08:47:58 CET] <kepstin> and then since you haven't used any -map options, only one of the three is encoded to the output [09:06:10 CET] <sandreas> Hello... After looking in the documentation, i would like to ask, if it is possible to get the duration of an audio file in accurate milliseconds? I tried a file, that has 22149ms and I always get 00:00:22.15. [09:25:15 CET] <DonRichie> Hey, I have a problem using ffmpeg. I have 320k opus files and want to reencode them with lower bitrate. [09:25:30 CET] <DonRichie> Problem is I want to keep the metadata and cover art [09:26:24 CET] <DonRichie> Copying metadata seems to work mostly. But I have problems copying the mjpeg stream for the album cover [09:27:15 CET] <DonRichie> it says "Unsupported codec id in stream 1" when I say "ffmpeg -i in.opus -map 0 -ab 128k -c:v copy out.opus" [09:28:37 CET] <DonRichie> as you see, I try to keep the mjpeg stream as it is. hope someone knows how to debug that :) [10:12:54 CET] <c_14> DonRichie: https://trac.ffmpeg.org/ticket/4448 [10:14:05 CET] <DonRichie> c_14: lol, nice they know that problem exists [10:14:34 CET] <DonRichie> Isn't there an ignore flag? Since I just want to copy the data without manipulating [10:16:16 CET] <JEEB> nope [10:16:32 CET] <c_14> would map_metadata work maybe? [10:16:44 CET] <JEEB> only if the writing module does the right thing? [10:17:21 CET] <JEEB> but looking at that comment it really seems to be a lack of that [10:17:33 CET] <JEEB> since the muxer doesn't take in "video" streams [10:18:40 CET] <JEEB> DonRichie: the reason why it doesn't work is because it all goes through the "read bits" -> "parse input container and get packets" -> "do stuff" (like decode/encode/just pass through) -> pass packets to a writer -> write bits out [10:19:08 CET] <JEEB> so at the point of the "pass packets to writer", that is a completely different structure since it's 100% controlled by the FFmpeg's writer just receiving your packets o' data [10:21:47 CET] <DonRichie> hmmmm. okay seems like something I can't fix. I am currently trying to extract the album art and use the opusenc program to reinject it after reencoding [10:22:03 CET] <JEEB> should be possible [10:22:56 CET] <DonRichie> the opusenc tool also should be the program which injected the albumart in the first place. [11:56:06 CET] <void09> is there any automated way to adjust the resolution/aspect ratio of a video so that it alligns with another video that is the same thing but has different format [11:56:49 CET] <void09> let's say, to map a dvd 4:3 image to its 16:9 bluray version [11:57:01 CET] <durandal_1707> scale2ref filter? [12:01:20 CET] <void09> hmm can't really tell if that's it, but probably not [12:02:07 CET] <void09> as such a filter would need to have an intelligent way of matching pictures that can be of very different quality, aspect ratio, and colour tones [12:02:36 CET] <void09> well, it would only need to do this once, since the parameters would be constant after that [12:03:46 CET] <void09> what I was thinking of doing, is to fill in the pixels occupied by a logo on a video, with pixels from the same material in a different video, that is of lesser quality, or has logo in a different position [12:05:48 CET] <void09> so i would need a function that could compute the corresponding pixel's value in the other video, so it could replace it [12:05:51 CET] <void09> does that make sense? [13:38:32 CET] <Atlenohen> Hello [13:39:10 CET] <Atlenohen> what would ffmpeg do if resolution changes middle of encoding, could mismatched resolution videos be concated, is that even possible, supported, feely wrong, but just doublechecking? [13:39:22 CET] <Atlenohen> Or it adds "black bars" (canvas) automatically? [13:39:31 CET] <Atlenohen> Or rescales the image? [13:40:35 CET] <pink_mist> uh, how would resolution change in the middle of encoding? I don't know of any codec that supports that [13:41:08 CET] <pink_mist> I'd presume you'd either get garbage out (since you put garbage in), or some form of error [13:46:55 CET] <JEEB> Atlenohen: if you have video filter chain in the middle with a scaler it would most likely get scaled accordingly [13:47:09 CET] <JEEB> Atlenohen: if you don't, it depends on the encoder what it does when it gets an AVFrame of a differing size [13:47:17 CET] <JEEB> libx264 will attempt to reconfigure itself, for example [14:00:19 CET] <Atlenohen> Oh, right, thanks. [16:06:34 CET] <realies> can you append a reversed first second of an audio clip in the same audio clip with a single ffmpeg call? [16:10:32 CET] <TheAMM> Probably, see the concat, atrim and areverse filters and use -lavfi aka -filter_complex [16:12:40 CET] <realies> first three are pretty clear, not sure how should it be all mapped with the filter complex [16:15:53 CET] <durandal_1707> realies: ffmpeg -i audio.wav -af "asplit[a][b],[b]atrim=end=1,areverse[b],[b][a]concat=a=1:v=0" -f null - [16:18:28 CET] <realies> thanks a lot durandal_1707 [17:02:08 CET] <jemius> On desktop computers etc. video streams are typically decoded on the graphics card, using hardware acceleration, correct? [17:02:55 CET] <bencoh> depends on the hardware / platform and software used, but in many cases yeah [17:03:38 CET] <JEEB> many desktops nowadays have hw decoders, but often the default is software decoding [17:03:54 CET] <JEEB> for example an awful lot of youtube playback with VP9 is probably swdec [17:03:55 CET] <bencoh> ffmpeg's default you mean I guess [17:04:02 CET] <bencoh> ah, that [17:04:20 CET] <JEEB> yes, FFmpeg's default and also what I see being utilized w/ firefox/chromium :) [17:04:36 CET] <JEEB> H.264 more often tends to be hwdec since that might go through media foundation [17:04:41 CET] <bencoh> yeah [17:04:46 CET] <jemius> does ffmpeg use acceleration by any means? I think most platforms don't have accelerated encoding [17:04:52 CET] <bencoh> I completely forgot about youtube/vp9 to be honest :) [17:05:18 CET] <JEEB> jemius: there are interfaces that FFmpeg has integrated that let you do hw decoding and encoding [17:05:40 CET] <JEEB> that is not the default, though, as often that stuff requires specific environment and integration [17:05:56 CET] <jemius> I often get the feeling as if in general, Linux computers use the CPU more intense when watching videos [17:06:29 CET] <JEEB> depends. there is a partial reason due to the hw decoding interfaces being more all over the place [17:06:39 CET] <JEEB> intel and AMD have vaapi, nvidia has vdpau *and* nvdec [17:06:47 CET] <JEEB> then you have v4l2_whatever [17:06:56 CET] <JEEB> while windows is mostly content with dxva2 and d3d11 [17:06:59 CET] <JEEB> *d3d11va [17:11:02 CET] <Anderssen> on the topic of (de-)interlacing: can ffmpeg also put together a frame from two separate files? Like file1 contains top field and file2 contains bottom field? [17:12:15 CET] <JEEB> you can interleave two inputs and those in theory can come from different files [17:12:42 CET] <JEEB> just use a complex filter chain and [0:v:0][1:v:0] as inputs to interleave or something? [17:13:18 CET] <jemius> Anderssen, in which situation does one need that? [17:13:24 CET] <kepstin> yeah, i'd expect that to work fine. might be a bit of a pain if the timestamps don't match perfectly, but you could work around that with the -r input option or setpts filter. [17:14:49 CET] <JEEB> setpts or something, yea [17:16:10 CET] <bencoh> I wonder who outputs top/bottom in separate files as well :) [17:17:51 CET] <Anderssen> jemius: in Germany we have some TV networks who encode their material sometimes in HD, and for SD, they slowly but surely have moved to not encode that on it's own anymore, but to encode it from the HD stream, and the HD stream has 50fps; and to encode this down to 25fps -- even though the movie had only 25fps to begin with -- they seem to do it in a somewhat unclever way so that the result has interlace artifacts. [17:17:51 CET] <Anderssen> however, e.g. the filter decomb telecide in avidemux seems to eliminate that very elegantly, however yadif or bwdif in ffmpeg seem to produce some minor artifacts in some situations; not big ones, but visible ones. and i've found out -- through experimenting with bitmaps -- that you can put together the original frame basically perfectly if you use the top field of one frame and the bottom field of the next frame; so [17:17:52 CET] <Anderssen> to speak they have an offset of 1 frame. [17:18:59 CET] <faLUCE> hello. Is it possible to change the volume of an ac3 audio without re-encoding ? [17:19:23 CET] <JEEB> faLUCE: in theory there's some stuff in the metadata of the bit stream, but we do not yet have a bit stream filter for that [17:19:26 CET] <JEEB> so no [17:19:38 CET] <JEEB> you can write a bit stream filter like that like the h.264/hevc things, of course, if you need to [17:20:00 CET] <faLUCE> JEEB: forgive off-topic do you know an utility (linux) for doing that? [17:20:02 CET] <Anderssen> JEEB: gotta look into that how i do that with the complex filter chain, thanks for the tip! [17:20:20 CET] <JEEB> faLUCE: no. I just understand that it should be possible (on *some* level) [17:20:53 CET] <faLUCE> thnks, let's search [17:20:57 CET] <JEEB> faLUCE: if it's just 5.1->stereo downmix woes (because of how 5.1 stuff is mastered), then just throw good ol' loudnorm at it :P [17:21:06 CET] <JEEB> as in, during playback [17:21:34 CET] <JEEB> if it's not that, you'll have to hope that whatever plays the stuff actually reads the metadata :P [17:24:34 CET] <faLUCE> JEEB: is it metadata at the beginning of the file, or is it in other points too? [17:24:46 CET] <JEEB> I don't remember the details, unfortunately [17:24:51 CET] <faLUCE> np [17:25:00 CET] <JEEB> I think the decoder actually extracts some of that stuff as metadata [17:25:09 CET] <JEEB> you could see that plus the A/52 spec [17:25:30 CET] <jemius> As I understood it the whole 1080i@50fps is just a marketing trick, to make the customer believe he receives full HD [17:25:50 CET] <jemius> wheres in the end the quality is about like 720p [17:25:59 CET] <JEEB> faLUCE: https://www.atsc.org/standard/a522012-digital-audio-compression-ac-3-e-ac-3… [17:26:05 CET] <JEEB> together with the libavcodec decoder [17:26:30 CET] <faLUCE> JEEB: thnks, I'm searching an utility firstly (not easy to find [17:26:31 CET] <faLUCE> ) [17:27:00 CET] <JEEB> yea I don't think it's a common use case [17:27:04 CET] <JEEB> not sure you'll find one [17:41:50 CET] <faLUCE> meanwhile I found this utility: "ac3filter". The manual says "You should not use this option instead of player volume or system volume. An overflow and a noticeable decrease of playing quality can take place when there is a high gain. For more information, refer to 7.1. Loudness and dynamic range. http://www.ac3filter.net/files/docs/ac3filter_1_30b/ac3filter_eng.html . Is the same metadata you were saying, JEEB ? [17:49:10 CET] <JEEB> faLUCE: ac3filter was just an old directshow filter for AC3 [17:49:38 CET] <JEEB> but either yes, that is part of it (although usually it's the DRC part) [17:49:45 CET] <JEEB> or just the DRC part next to it is that [17:49:55 CET] <JEEB> but it will not filter the bit stream for you [17:49:56 CET] <JEEB> it's a decoder [17:50:58 CET] <faLUCE> I see [17:51:01 CET] <faLUCE> damn... [17:51:12 CET] <faLUCE> I could not imagine that it was so hard [17:53:04 CET] <JEEB> I am not sure how hard it is to code, but I think it's closer to "your specific use case is just rare" [17:53:16 CET] <JEEB> I mean, even rarer than fixing up H.264 or HEVC parameter sets :P [17:53:31 CET] <JEEB> and we only got a bit stream filter for that relatively recently [18:46:52 CET] <faLUCE> JEEB: I don't understand why my case is rare. Is it because gain can be adjusted during playback ? [18:47:07 CET] <JEEB> yes [18:47:16 CET] <JEEB> or people live with what has been encoded for them :P [18:47:20 CET] <JEEB> or they re-encode it [18:47:44 CET] <JEEB> trying to patch the stream and handle it that way is definitely not the way people would take it generally :P [18:47:54 CET] <JEEB> also I am not fully sure how far you can go with the metadata [18:47:55 CET] <faLUCE> JEEB: but gain doesn't mean volume, right? [18:48:04 CET] <JEEB> well I also meant DRC [18:48:09 CET] <JEEB> aka normalization [18:48:26 CET] <JEEB> which is usually done after you f.ex. downmix from 5.1 to stereo [18:49:15 CET] <faLUCE> JEEB: I'm playing a 5.1 file on headphones or normal stereo. So, which is the proper way to adjust the volume? [18:49:29 CET] <JEEB> with mpv I'd start with something like --af=format=channels=stereo,loudnorm [18:49:40 CET] <JEEB> takes you to stereo, then adds loudness normalization [18:49:59 CET] <JEEB> after that the difference between loud parts (effects) and voices should be much smaller [18:50:13 CET] <JEEB> then you can adjust your volume without getting your ears killed too much [18:50:40 CET] <faLUCE> I thought it did that automatically when recognizing a 5.1 file with 5 tracks [18:50:54 CET] <JEEB> what you get automagically is correct downmix [18:51:04 CET] <bencoh> "correct" :) [18:51:19 CET] <JEEB> I'm pretty sure various specs including dolby's were referenced [18:51:40 CET] <bencoh> ah, if that's what you meant by correct then yes [18:51:43 CET] <faLUCE> this is out topic here, I'm going to ask it to mpv [18:51:47 CET] <sandreas> Hello. After reading the documentation and finding nothing, I would like to ask if it is possible to change the time format of ffmpeg output (i get Duration: 00:00:22.15 for a file that has 22149ms - which is inaccurate) and if not, why does ffmpeg round the time this way? [18:51:49 CET] <faLUCE> channel [18:52:17 CET] <JEEB> bencoh: yes, and then if more adjustment due to the wide dynamic range and the original mixing is required, then that can be added. [18:52:41 CET] <JEEB> 5.1 has a lot more freedom in the mix because it has all those five plus one things :P [19:15:31 CET] <Hello71> ... isn't that called replaygain [19:16:19 CET] <JEEB> not necessarily [22:42:03 CET] <montana> would i able to transcode 10fps video to 4fps using ffmpeg [22:42:15 CET] <montana> it has to be 4 fps [22:48:25 CET] <shibboleth> will i have to be running xorg and ffmpeg as the same user for vaapi accel? [23:03:19 CET] <montana> does ffmpeg support rav1e encoding? [23:06:21 CET] <JEEB> montana: yes. if you build the C library it can be linked against. the mappings got merged right after rav1e started using version numbers [23:06:42 CET] <montana> is that mean "no" for prebuild versions? [23:06:50 CET] <JEEB> I have no idea what the pre-built versions contain [23:07:14 CET] <JEEB> this guy's linux builds at least don't have it https://johnvansickle.com/ffmpeg/git-readme.txt [23:07:17 CET] <montana> https://ffmpeg.zeranoe.com/builds/ [23:07:31 CET] <JEEB> there you have the readme link [23:07:35 CET] <JEEB> and not seeing rav1e there [23:07:48 CET] <JEEB> if you want rav1e, please tell the person since those builds have nothing to do with FFmpeg itself :) [23:08:38 CET] <montana> by person, you mean the binary builder? [23:09:09 CET] <JEEB> yes [23:09:16 CET] <JEEB> pretty sure he has an e-mail there somewhere noted [23:10:20 CET] <montana> okay [23:10:27 CET] <montana> why is libaom-av1 unusable [23:10:35 CET] <montana> it just does not work [23:13:23 CET] <JEEB> I have no idea :P [00:00:00 CET] --- Mon Nov 25 2019

1 0

ffmpeg-devel.log.20191123
by burek 24 Nov '19

24 Nov '19

[11:08:53 CET] <cone-655> ffmpeg 03Paul B Mahol 07master:aaac48fb5027: avfilter/vf_normalize: add support for commands [12:12:06 CET] <cone-655> ffmpeg 03Paul B Mahol 07master:93414ce83186: avfilter: add axcorrelate filter [21:26:14 CET] <durandal_1707> i REd perseus decoder, gonna post patch to ML ASAP! [21:26:41 CET] <JEEB> sounds like a fun endeavour [21:26:47 CET] <JEEB> any nice stories you'd want to blog about? [21:27:00 CET] <JEEB> if you want to get upvotes on the Orange Site [23:16:21 CET] <cone-638> ffmpeg 03Baptiste Coudurier 07master:eafa8e859297: avformat/dvenc: support muxing dvcprohd [23:16:21 CET] <cone-638> ffmpeg 03Baptiste Coudurier 07master:635a5c11a67b: avformat/mxfenc: simplify dv ul handling [23:16:21 CET] <cone-638> ffmpeg 03Baptiste Coudurier 07master:d65aaf8ea986: avformat/mxfenc: simplify d-10 ul handling [00:00:00 CET] --- Sun Nov 24 2019

1 0

ffmpeg.log.20191123
by burek 24 Nov '19

24 Nov '19

[00:41:56 CET] <Pie-jacker875> is avc and opus in an mp4 container a thing? [00:42:25 CET] <JEEB> sure [00:42:50 CET] <Pie-jacker875> I'm messing about with obs' ffmpeg output [00:42:58 CET] <JEEB> FFmpeg will only create the opus part with -strict experimental, but effectively all vendors (browsers f.ex.) have added support [00:43:04 CET] <Pie-jacker875> ahh okay [00:43:05 CET] <Pie-jacker875> thanks [00:44:02 CET] <Pie-jacker875> now to just figure out how to format the -strict experimental in obs' encoder settings field [00:44:32 CET] <BtbN> You don't I'm pretty sure [00:44:56 CET] <Pie-jacker875> well just typing "-strict -2" isn't working there [00:45:07 CET] <BtbN> Since it's not CLI options, but directly setting avoptions on the encoder [00:49:37 CET] <Pie-jacker875> alright I'm lost [00:50:46 CET] <BtbN> If they do not have an option to enable experimental stuff, it's straight up not possible. [00:51:36 CET] <Pie-jacker875> it's a text field where you set encoder settings and it doesn't support that option for some reason? [00:51:50 CET] <BtbN> It's not the ffmpeg.c CLI, no [00:52:01 CET] <Pie-jacker875> okay then [00:52:01 CET] <BtbN> it's just parsed by OBS to set avoptions on the encoder. [01:37:16 CET] <slidercrank> hello! I want to combine two videos by placing them next to each other. Unfortunately their sizes, rotation and length (time) do not match. Is it possible to do it in one go? Or should I do it it multiple steps? Cutting the beginning, rotating and then combining with rescaling? [01:38:36 CET] <shibboleth> will i have to run xorg as whichever user is using ffmpeg api to use hwaccel? [02:00:39 CET] <slidercrank> disregard my question. I've figured it out by reading docs, forums and experimenting [02:07:16 CET] <slidercrank> a strange thing. [02:07:19 CET] <slidercrank> $ ffmpeg -ss 00:00:03 -i left.mp4 -i right.mp4 -filter_complex "[1:v]transpose=1,scale=-2:1280,setsar=1[right];[0:v][right]hstack" -t 5 out.mp4 [02:07:52 CET] <slidercrank> the problem I am facing is the left video is shorter (in height) then the right video after combining them [02:07:58 CET] <slidercrank> *than [02:09:10 CET] <slidercrank> the output video has the height of the left video (as needed) but the left video becomes shorter in height (padded with black space above) [02:09:50 CET] <slidercrank> but I don't want this padding. how do I do it? [02:10:49 CET] <furq> slidercrank: pastebin ffprobe -show_streams left.mp4 [02:12:06 CET] <slidercrank> https://paste.ubuntu.com/p/CNJgnRKZQc/ [02:14:31 CET] <furq> this is already portrait, why are you transposing it [02:14:57 CET] <slidercrank> when I play the video, it's in landscape mode [02:14:59 CET] <furq> wait nvm that's right.mp4 [02:15:11 CET] <slidercrank> yes, that's right.mp4 [02:15:15 CET] <furq> yeah ffprobe that then [02:15:56 CET] <slidercrank> that's probe right https://paste.ubuntu.com/p/JmRVs4vW62/ [02:16:57 CET] <slidercrank> the same scene was taken with two smartphones (different manufacturers). so everything is different about the videos (resolution and such). but I need to combine them. [02:17:32 CET] <slidercrank> to show what the users of both smartphones saw at the same time [02:19:40 CET] <slidercrank> I'm using -t 5 because I'm still testing. Before I am ready to convert the whole video(s) [02:20:11 CET] <slidercrank> furq, the padding in the left picture https://i.imgur.com/pf35OkX.jpg [02:23:22 CET] <furq> i don't see anything obvious and none of those filters should introduce padding [02:23:49 CET] <furq> is it still there with -i right.mp4 -vf transpose=1 -frames:v 1 out.png [02:24:46 CET] <slidercrank> why right.mp4? the padding appears for left.mp4 [02:25:14 CET] <slidercrank> when I issue your command (how you wrote it), there is no padding [02:27:54 CET] <furq> sorry i've apparently forgotten how cardinal directions work today [02:28:03 CET] <furq> that's even more confusing that it's happening to the one that isn't being filtered [02:28:57 CET] <slidercrank> thank you for taking your time helping me [02:29:27 CET] <furq> i guess try -i left.png -frames:v 1 out.png and see if the padding shows up [02:29:49 CET] <furq> not sure what you'd do if it does other than crop it [02:31:05 CET] <slidercrank> ffmpeg -i left.mp4 -frames:v 1 out.png produces a black image [02:31:33 CET] <slidercrank> maybe the first frame is black [02:31:40 CET] <furq> yeah add -ss 5 or something [02:32:12 CET] <slidercrank> yes, the padding is added above [02:33:08 CET] <slidercrank> https://i.imgur.com/vyqciuf.png [02:33:28 CET] <slidercrank> that's really strange. because in the video there is no padding [02:34:42 CET] <slidercrank> oh damn! there is. [02:35:07 CET] <slidercrank> what a strange phone that records with a padding :) [02:35:15 CET] <slidercrank> so I'll crop it then [02:35:41 CET] <slidercrank> furq, thank you very much [02:50:24 CET] <slidercrank> ffmpeg rules [03:10:32 CET] <slidercrank> furq, btw, if you are interested what video that was https://imgur.com/a/6050Jyd the result of combining [03:11:34 CET] <slidercrank> indoor navigation with augmented reality [06:15:47 CET] <while> Hi, I am trying to find the correct syntax of ffmpeg/ffplay to decode a UDP mpegts stream with 2 raw streams, one a raw yuv420p video stream, and the other a pcm s16le audio stream [06:16:32 CET] <while> I don't think I am getting the syntax correct to properly classify the 1st stream (containing the headerless raw video) so ffplay/ffmpeg can properly process it [06:19:07 CET] <furq> mpegts doesn't support rawvideo [06:19:28 CET] <furq> going to assume the next question is "how come ffmpeg will mux it into mpegts then" and the answer is i don't know [06:20:04 CET] <furq> nor do i know why nobody has done anything about this in the six years since the mailing list thread about this [06:22:59 CET] <while> so mpegts is not a codec-agnostic blunt solution for containerizing/multiplexing? [06:23:30 CET] <furq> not quite [06:25:10 CET] <while> is there anything like mpegts but more rugged? [06:26:33 CET] <furq> not really if you need it to be streamable [06:26:36 CET] <furq> otherwise mkv or maybe nut [06:27:58 CET] <while> thank you [06:32:26 CET] <while> I found that `ffmpeg -f mpegts -vcodec rawvideo -i udp://127.0.0.1:30000 -map:v 0:0 delete.yuv' properly decodes mpegts stream 0 containing the raw video to properly decode the stream [06:35:52 CET] <furq> i tried that and it didn't work [06:35:55 CET] <furq> so who knows what's going on there [06:36:37 CET] <while> what command did you use to create the udp stream? [06:39:39 CET] <while> I mean, my command only works with my existing udp stream at 127.0.0.1:30000, if you don't have said udp stream, which is specifically mpegts, with the 0th stream being of rawvideo, it shouldn't work [06:40:16 CET] <furq> i didn't make a udp stream, i just made a rawvideo .ts with ffmpeg [06:43:37 CET] <while> with raw video in the 1st stream encapsulated within mpegts? [06:43:43 CET] <furq> yeah [06:45:46 CET] <while> well, my command snipit may be relying on something akin to undefined behavior, I'm using the ffmpeg-bearing package just from the debian repositories [06:51:38 CET] <while> also my example appear to just copy the data, instead of doing any conversion with it, rawvideo is complicated to process beyond copying it, of course [09:20:52 CET] <UserNaem0> i have a question about video filters: how do i apply a filter only to frames that are "similar" to the previous frame (i.e. duplicate frame with slightly different encoding artifacts)? [09:30:15 CET] <UserNaem0> whoops, i logged off accidentally, i hope i didn't miss anything [09:31:57 CET] <Reinhilde> you didnt [10:06:51 CET] <Arnob> test [10:07:11 CET] <Arnob> test 2 [11:20:06 CET] <jemius> [libopus @ 0x5632234b6920] Invalid channel layout 5.1(side) for specified mapping family -1. [11:20:10 CET] <jemius> what might this mean? [14:19:54 CET] <Weasel_> jemius: https://trac.ffmpeg.org/ticket/5718 [20:43:10 CET] <Pie-jacker875> yo I was here last night asking about strict experimental on obs. seems like it works when you put it in the muxer settings field [20:43:13 CET] <Pie-jacker875> it's working [21:11:39 CET] <jemius> when compressing jpegs, what's the difference between -compression_level and -qscale ? [21:12:42 CET] <JEEB> whether you're setting one option or the other in the configuration context? and then if the difference matters at all depends on the module [21:17:06 CET] <JEEB> ok, so q:v or qscale sets the global_quality value in the encoder it seems [21:18:38 CET] <furq> jemius: compression_level is generally for lossless codecs, q/qscale is generally for lossy codecs [21:21:54 CET] <JEEB> I must say, I am surprised now that I stumbled upon ff_mpv_encode_init [21:22:16 CET] <JEEB> this one function encompasses a crapload of formats [21:22:51 CET] <JEEB> it does utilize the qscale flag which q/qscale indeed sets [21:23:30 CET] <JEEB> but yea, I didn't find any notices of the compression_level option anywhere :P [21:23:42 CET] <JEEB> since yes, it seemed to be a lossless compression thing regarding "how hard to attempt to compress this" [21:24:01 CET] <JEEB> but whether a module actually utilizes it or not you'd only figure out by reading the code [21:24:13 CET] <JEEB> unfortunately the encoders do not exactly export the information of which things they actually read/follow [21:27:37 CET] <furq> yeah it's a shame that stuff is so poorly documented [21:30:40 CET] <JEEB> AVOptions let you peek into what a module takes in, but harder to do that for a gigantic structure that is just there [21:30:55 CET] <JEEB> and if you start manually documenting, it might or might not be correct [22:51:58 CET] <void09> JEEB: how did you say I could find timestamps of decoding errors ? [22:52:16 CET] <void09> I forgot what was said, but I think I did not have success with any of the methods suggested [00:00:00 CET] --- Sun Nov 24 2019

1 0

ffmpeg-devel.log.20191122
by burek 23 Nov '19

23 Nov '19

[00:04:28 CET] <cone-417> ffmpeg 03Carl Eugen Hoyos 07release/4.0:5e98ede2da98: lavc/tableprint_vlc: Remove avpriv_request_sample() from included files. [00:04:29 CET] <cone-417> ffmpeg 03Michael Niedermayer 07release/4.0:a6eb5e1f7086: avformat/mp3dec: Check that the frame fits within the probe buffer [00:04:30 CET] <cone-417> ffmpeg 03Michael Niedermayer 07release/4.0:17d5c21b3d12: avcodec/sonic: Fix integer overflow in predictor_calc_error() [00:04:31 CET] <cone-417> ffmpeg 03Michael Niedermayer 07release/4.0:6b430f066b9d: avcodec/apedec: Fixes integer overflow of res+*data in do_apply_filter() [00:04:32 CET] <cone-417> ffmpeg 03Michael Niedermayer 07release/4.0:61620896a1ac: avcodec/qdm2: The smallest header seems to have 2 bytes so treat 1 as invalid [00:04:33 CET] <cone-417> ffmpeg 03Michael Niedermayer 07release/4.0:2850004c6d3a: avcodec/vc1_block: Fix undefined behavior in ac prediction rescaling [00:04:34 CET] <cone-417> ffmpeg 03Michael Niedermayer 07release/4.0:aca0578002d9: avcodec/wmadec: Require previous exponents for reuse [00:04:35 CET] <cone-417> ffmpeg 03Michael Niedermayer 07release/4.0:38cfa9d5f974: avcodec/ralf: use multiply instead of shift to avoid undefined behavior in decode_block() [00:04:36 CET] <cone-417> ffmpeg 03Michael Niedermayer 07release/4.0:ed04ecd2d3c3: avcodec/atrac3: Check for huge block aligns [00:04:37 CET] <cone-417> ffmpeg 03Michael Niedermayer 07release/4.0:70bf2bdf3112: avcodec/iff: Move index use after check in decodeplane8() [00:04:38 CET] <cone-417> ffmpeg 03Michael Niedermayer 07release/4.0:26e1d0d015bb: Changelog: update [04:09:25 CET] <cone-844> ffmpeg 03Andreas Rheinhardt 07master:27c6c925344e: avformat/av1: Fix leak of dynamic buffer in case of parsing failure [11:53:07 CET] <rcombs> okay I have an extremely dumb broadcast case [11:53:33 CET] <rcombs> so SCC files don't have timestamps, they have SMPTE timecodes [11:53:53 CET] <rcombs> which can be either drop-frame or non-drop-frame [11:56:03 CET] <rcombs> as far as I can tell, what that ultimately means is "if the caption timecodes are non-drop-frame, and the video has a fractional frame rate, then they need to be adjusted by adding 2/30 of a second per minute except on minutes divisible by 10" [11:57:03 CET] <rcombs> but if the video has an integer frame rate, then they don't need adjustment, or possibly would need the opposite adjustment if the captions are drop-frame [11:59:01 CET] <rcombs> note that this isn't quite the same as being stretched by 1.001/1 [12:03:22 CET] <Dmitri_Ovch> Hi! I sent the small patch (https://patchwork.ffmpeg.org/patch/16382/) fixing constant QP settings for I, P pictures. I also sent a patch, (https://patchwork.ffmpeg.org/patch/16270/) proposed by Sitan Liu. This is a very small but useful patch that corrects the profile level option on AMF HEVC. Earlier, allowing the user to select the engine for AMF initialisation (https://patchwork.ffmpeg.org/patch/16015/) [12:03:22 CET] <Dmitri_Ovch> Could you review these patches? [12:05:44 CET] <kierank> rcombs: yes [12:06:00 CET] <kierank> what you do is run the video [12:06:02 CET] <kierank> and match the timecodes [12:06:14 CET] <kierank> iirc there is already code to do this in lavu otherwise it's trivial to write [12:06:45 CET] <rcombs> kierank: how would that all fit together in ffmpeg, though [12:06:52 CET] <kierank> doesn't [12:26:47 CET] <rcombs> kierank: so here's one thing I'm not clear on: say if the frame rate is (exactly) 24; are the frame numbers in SCC supposed to be in 1/24s or 1/30s of a second? [12:28:18 CET] <kierank> Whatever the timecode rate is [12:28:18 CET] <rcombs> and who the hell decided to use this batshit format for subtitle timestamps [12:28:33 CET] <rcombs> is that the same as the frame rate or [12:28:47 CET] <kierank> You don't know really [12:29:00 CET] <kierank> This is some 1980s format on floppy disks [12:29:07 CET] <kierank> 5 inch floppies [12:29:31 CET] <rcombs> well for some reason it still exists in 2019 with HD video [12:29:44 CET] <kierank> Yes, you have to know the frame rate a priori [12:30:02 CET] <rcombs> so the timecode rate is the video's frame rate, then? [12:31:00 CET] <rcombs> just, uh, rounded to the nearest integer, I guess???? [12:31:30 CET] <rcombs> trying to wrap my head around NDF timecodes on fractional-frame-rate video [12:32:18 CET] <rcombs> I guess, like, 01:00:00:00 actually means "1*60*60*24 video frames after 00:00:00:00" [12:32:52 CET] <JEEB> oh boy, SCC [12:32:55 CET] <JEEB> I have looked into that once [12:34:24 CET] <rcombs> which is sane for 24fps but for 24/1.001 that ends up actually meaning 01:00:03.06? [12:34:53 CET] <rcombs> so& to get timestamps, you play back the video and just count frames? [12:35:33 CET] <rcombs> and when you hit frame 24, whatever timestamp that has is timecode 00:00:01:00? [12:35:49 CET] <rcombs> mmmmmmmmmmmm [12:37:19 CET] <rcombs> I think I should only have to care about CFR, so I can _probably_ just convert to frame numbers by multiplying seconds by the nearest-integer rate + adding frames, then dividing by the real rate? [12:37:56 CET] <rcombs> if I have this all right, would anyone object to a "video_rate" AVOption in sccdec.c [12:40:47 CET] <rcombs> kierank: ^ sanity-check me? [12:42:07 CET] <kierank> Afaik DF only matters for 29.97 [12:42:15 CET] <kierank> Not sure there is DF for 23.976 [12:43:28 CET] <kierank> But haven't looked at this for years [12:43:46 CET] <kierank> Traditionally some content starts at 01:00:00:00 so you can have a pre slate [12:43:52 CET] <rcombs> I'm dealing with NDF here [12:44:18 CET] <rcombs> or at least the SCC formatting claims it's NDF [12:44:43 CET] <rcombs> I _think_ if it was DF this would mostly just work, with a small amount of periodically-corrected drift [12:44:57 CET] <kierank> NDF is just run as normal [12:44:59 CET] <rcombs> (it'd be dumb, but it wouldn't substantially desync over time) [12:45:19 CET] <kierank> You need to know the start timecode [12:45:28 CET] <kierank> Usually 00:00:00:00 or 01:00:00:00 [12:45:38 CET] <kierank> Many places just assume the former [12:46:16 CET] <rcombs> the problem I'm seeing is that when decoded using lavf's naïve "assume 30fps" demuxer, I get timestamps that desync from the video at a rate of .1% [15:28:35 CET] <cone-210> ffmpeg 03Gyan Doshi 07master:1b78da449e20: doc/filters: complete and correct vmafmotion section [16:07:25 CET] <cone-210> ffmpeg 03Paul B Mahol 07master:c36e72ed279b: avfilter/af_aiir: check for stability [16:07:26 CET] <cone-210> ffmpeg 03Paul B Mahol 07master:e169d3756e92: avfilter/af_aiir: factor out response calculation [16:10:15 CET] <rcombs> how should assenc handle multiple rects? [16:10:58 CET] <rcombs> optimally it'd output multiple packets, but there's no way to do that with subtitles (which still, for some reason, use an entirely different API from audio and video) [17:49:26 CET] <cone-210> ffmpeg 03Paul B Mahol 07master:2f5fb9e60fa6: avfilter/af_aiir: make a/b coefficients array [17:49:27 CET] <cone-210> ffmpeg 03Paul B Mahol 07master:eecc45cea50f: avfilter/af_aiir: add missing normalization of biquads gains [20:25:59 CET] <cone-210> ffmpeg 03Paul B Mahol 07master:f2a01b4c8bf6: avfilter/af_aiir: fix biquads normalization [21:07:12 CET] <cone-210> ffmpeg 03Andriy Gelman 07master:ccc83ff11e07: avcodec/v4l2_m2m_dec: Fix decoding on Odroid XU4 [21:07:13 CET] <cone-210> ffmpeg 03Andriy Gelman 07master:e759fbfbc477: avcodec/v4l2_context: Fix indentation [21:16:03 CET] <cone-210> ffmpeg 03Paul B Mahol 07master:f46b04c4c328: avfilter/af_biquads: add new normalize/n option [21:16:04 CET] <cone-210> ffmpeg 03Paul B Mahol 07master:89aa1342b1e5: avfilter/af_aiir: normalize biquads only if divisor is big enough [22:42:57 CET] <cone-210> ffmpeg 03Paul B Mahol 07n4.0.5:HEAD: avfilter/af_aiir: normalize biquads only if divisor is big enough [23:30:50 CET] <cone-210> ffmpeg 03Michael Niedermayer 07release/3.4:0a4d2b5f674e: avformat/mp3dec: Check that the frame fits within the probe buffer [23:30:51 CET] <cone-210> ffmpeg 03Michael Niedermayer 07release/3.4:c2f81cfc78fe: avcodec/sonic: Fix integer overflow in predictor_calc_error() [23:30:52 CET] <cone-210> ffmpeg 03Michael Niedermayer 07release/3.4:5222756b36fe: avcodec/apedec: Fixes integer overflow of res+*data in do_apply_filter() [23:30:53 CET] <cone-210> ffmpeg 03Michael Niedermayer 07release/3.4:0e96cffff6e4: avcodec/qdm2: The smallest header seems to have 2 bytes so treat 1 as invalid [23:30:54 CET] <cone-210> ffmpeg 03Michael Niedermayer 07release/3.4:313af2294257: avcodec/vc1_block: Fix undefined behavior in ac prediction rescaling [23:30:55 CET] <cone-210> ffmpeg 03Michael Niedermayer 07release/3.4:b385b3476141: avcodec/wmadec: Require previous exponents for reuse [23:30:56 CET] <cone-210> ffmpeg 03Michael Niedermayer 07release/3.4:978aa2ae5087: avcodec/ralf: use multiply instead of shift to avoid undefined behavior in decode_block() [23:30:57 CET] <cone-210> ffmpeg 03Michael Niedermayer 07release/3.4:eabece8639dd: avcodec/atrac3: Check for huge block aligns [23:30:58 CET] <cone-210> ffmpeg 03Michael Niedermayer 07release/3.4:b9735a0271a9: avcodec/iff: Move index use after check in decodeplane8() [23:30:59 CET] <cone-210> ffmpeg 03Michael Niedermayer 07release/3.4:e5baac772ccb: Changelog: update [00:00:00 CET] --- Sat Nov 23 2019

1 0

ffmpeg.log.20191122
by burek 23 Nov '19

23 Nov '19

[00:37:10 CET] <void09> ok so adding debug_ts is pretty useless for getting timestamps of stream errors.. I get a 500MB log file :\ [00:37:15 CET] <void09> any other ideas ? [00:41:30 CET] <void09> how to get timestamps of decoding errors in a file [01:00:32 CET] <void09> anyone still here ? I tried for the first time to convert .ts to .mkv before cutting it.. and this results in the following error being spammed in the terminal: Non-monotonous DTS in output stream 0:0; previous: 6148040, current: 6148020; changing to 6148040. This may result in incorrect timestamps in the output file. [01:03:43 CET] <void09> does that for every 40miliseconds (every frame) [01:31:34 CET] <kingsley> Do you happen to know of a filter that refracts light like looking through a prism? [01:31:39 CET] <kingsley> If so, what is it called? [01:45:08 CET] <Hello71> how would that work exactly [04:30:50 CET] <realies> is there a way to prevent dynaudnorm from boosting quiet sections of a voice recording and amplifying static noise? [05:46:10 CET] <c_14> you could maybe try using agate to try and remove the static noise before using dynaudnorm [06:31:51 CET] <realies> c_14, I was wondering how to estimate the threshold, volume detect only gives the loudest bins [06:36:08 CET] <c_14> you'd probably just have to test. start with the default (0.125) and adjust as necessary [06:38:07 CET] <realies> c_14, trying to make it work automatically for various input files [07:47:38 CET] <kepstin> you could also try loudnorm instead which has builtin noise gating. it'll still boost quiet stuff tho (depending how you configure lra), but that's kind of what both filters are designed for. [08:09:47 CET] <kingsley> Hello71: If your question, "how would that work exactly" was in response to my search for a filter that refracts light, like looking through a prism, here's more detail on how it might work. [08:09:53 CET] <kingsley> For the user' [08:10:29 CET] <kingsley> Oops! I accidentally pressed my <enter> key too soon. Sorry! [08:14:03 CET] <fling> What is the universal way of including a text file into the output? [08:14:15 CET] <kingsley> From the user's perspective, I can imagine the filter accepting 3 arguments: 1.) The file name of the original video, 2.) the angle at which the effect is rotated from the viewer's perspective (like tilting a prism) and 3.) how widely to spread the refracted color spectrum (like how far away the prism is from your eye). [08:14:18 CET] <fling> Should it be put not as metadata but as a separate stream? [08:22:17 CET] <kingsley> (Continuing my elaboration on how a filter might simulate refracting light like a prism...) From a software developer's perspective, and if I recall correctly, code has already exists that can convert a tuple of red, green and blue intensities in a pixel into a full spectrum color histogram. This could be done for each pixel, with the histogram's height translated into the alpha/transparency, and the resulting rainbow line tilted by the [08:22:17 CET] <kingsley> angle defined in 2.) above, and spread across the distance defined in 3.) above. [08:24:15 CET] <friendofafriend> My stream displays at the appropriate framerate in ffplay, but when I use VLC it plays at a much faster rate and then freezes and shows "picture is too late to be displayed (missing xxx ms)" messages until "ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 4648 ms)". Sometimes I see messages like "Could not get display date for timestamp 0". Is there some way to fix it? [08:25:21 CET] <kingsley> fling: If I understand your question correctly, and I may not, maybe you could render text into video by doing something like [08:28:45 CET] <kingsley> -filter_complex "<bla bla bla...>, drawtext=fontcolor=white: text=<(cat /tmp/text.txt):fontsize=30:x=5:y=10,<bla bla bla>... [08:32:01 CET] <kingsley> friendofafriend: I'm not sure if I understand exactly what you're seeing, but your nice, detailed description reminds me of when I tried to watch a video on a slow computer. I wonder if ffplay is faster than vlc. Maybe you could test it by doing something like 1.) trying a 3rd video player, like maybe dragon, and/or rendering to a lower resolution and trying to watch that in vlc. [08:33:45 CET] <fling> kingsley: sounds interesting, otoh I want to keep it as a text file [08:33:47 CET] <friendofafriend> kingsley: It's really weird. It's like the stream caches and then all the frames are displayed at once, then it caches again. ffplay works perfectly, like it always has. [08:34:05 CET] <fling> probably not possible for any container [08:35:33 CET] <kingsley> fling: I happened to notice you wrote that you want to keep "it" as a text file. Whut ezzz deese, humfff, "it", uhf wheeech u speak? [08:36:46 CET] <fling> kingsley: just a text file I want to embed :P [08:36:57 CET] <fling> kingsley: I could put it into metadata in some containers I believe [08:37:03 CET] <fling> or as an unknown stream in others [08:37:09 CET] <fling> thinking of an universal way of doing so [08:38:03 CET] <kingsley> fling: Sorry if I wasn't clear. Please check out "/tmp/text.txt" in my example above. It was my way of indicating your text file. [08:39:51 CET] <fling> your example is irreversible, I will not be able to easily get the file back [08:41:17 CET] <friendofafriend> I'm using this command for ffmpeg. https://paste.debian.net/plain/1117404 When I play in VLC, I have to use vlc "http/h264://example.com/test.h264" or it won't demux the stream as h264, and then I get that weird play-all-the-frames-in-cache-at-once behavior. [08:41:47 CET] <jemius> If I transform a color video to a grayscale one, shouldn't it take up significantly less disk space afterwards? [08:42:00 CET] <kingsley> fling: If it would be convenient, comfortable, and all those good things, maybe you could explain how a file might be irreversible. [08:42:16 CET] <fling> jemius: only if it is lossless already [08:42:55 CET] <fling> kingsley: if I embed a jpeg thumbnail into an mp4 container then I will be able to extract if afterwards. [08:42:56 CET] <kingsley> jemius: I dunno, but maybe the answer depends on whether it's compressed or not. [08:43:39 CET] <fling> kingsley: same with other metadata and streams. If I add a sub stream then I will be able to extract it for example. [08:48:45 CET] <kingsley> fling: Thank you for elaborating. If I understand correctly, maybe you're looking for a video encoding format or container that's reversible. If so, I don't know the answer, but I suppose searching with key words like... video container and reversible might find something like a wikipedia page that describes an open format you might use. [08:59:16 CET] <fling> what? :D [09:08:00 CET] <friendofafriend> Ah, the problem seems to "go away" when I'm not reencoding to a new framerate. Then VLC doesn't complain. It sure would be great to find a way to fix the timestamps (?) on the stream, so I can go back to a low FPS. [09:08:53 CET] <friendofafriend> For some reason, that darn VLC just refuses to play the URL, and needs http/h264://example.com/stream instead. [09:18:59 CET] <Weasel_> friendofafriend: why should vlc demux when your stream is not muxed into container but a raw video stream in h264? [09:19:34 CET] <Weasel_> put it into container so vlc might work better [09:20:57 CET] <friendofafriend> Weasel_: Isn't m4v a container? [09:21:54 CET] <Weasel_> it is, but you were talking about h264 file [09:22:17 CET] <realies> kepstin, loudnorm has built-in noise gating? :o not seeing anything on this in the docs [09:23:32 CET] <friendofafriend> Weasel_: It was just the extension, I think? My command line is over here. https://paste.debian.net/plain/1117404 [09:24:33 CET] <friendofafriend> For some reason, VLC assumes it an MPEG-PS stream until I do that http/h264:// thing. I have the same problem with mpeg4 stuff, I have to use VLC with http/mp4v://. [09:25:35 CET] <friendofafriend> And HTML5 playback? Never seen it work. I've been trying at it for weeks (months). [09:26:13 CET] <JEEB> mp4v and h264 sounds like you didn't mux into a container? [09:26:26 CET] <JEEB> since they sound like demuxers for *raw* H.264 or MPEG-4 Video [09:26:30 CET] <Weasel_> friendofafriend: ffmpeg looks into filename extension to decide what to write. [09:27:03 CET] <friendofafriend> Isn't muxing into a container just a matter of passing -f m4v or something like that? [09:27:29 CET] <JEEB> Muxer m4v [raw MPEG-4 video]: [09:27:36 CET] <JEEB> > raw MPEG-4 video [09:27:52 CET] <JEEB> so you are specifying indeed to just write out raw video :) [09:28:43 CET] <friendofafriend> If I use -f mp4, I get "[mp4 @ 0x560901862040] muxer does not support non seekable output". What container should I use for HTML5 playback? [09:29:08 CET] <Weasel_> mp4 should work [09:29:20 CET] <friendofafriend> (I'm just trying to take some RTSP stream and barf it into Icecast.) [09:31:03 CET] <Weasel_> so you want live... thats a bit more complicated. look into hls/mpeg-dash [09:31:29 CET] <JEEB> friendofafriend: if you want streaming mp4 you will need to do fragmented [09:32:25 CET] <Weasel_> html5 spec doesn't do live [09:32:37 CET] <JEEB> -f mp4 -movflags frag_keyframe+delay_moov [09:32:38 CET] <JEEB> ye [09:32:47 CET] <JEEB> or well, you can write your own MSE [09:32:50 CET] <JEEB> and feed that into the player [09:32:58 CET] <JEEB> but it will not be as easy as <video src="blah.mp4"> [09:33:02 CET] <JEEB> unfortunately [09:33:03 CET] <friendofafriend> What's an MSE, JEEB? [09:33:07 CET] <JEEB> media source extensions [09:33:19 CET] <JEEB> you handle the I/O, and pass buffers to the HTML5 video stuff [09:33:35 CET] <JEEB> for HLS and DASH there are pre-created things like dash.js or hls.js [09:33:53 CET] <JEEB> welcome to HTML5 video where everyone has decided that they want to implement things in JS ;) [09:36:19 CET] <friendofafriend> Those flags are working fine to stream MP4 to ffplay (and thank you), but I get "waiting for VOL" messages out of VLC. And I have to use http/mp4v://example.com/stream to make it work. [09:36:40 CET] <JEEB> that shouldn't work ^^; [09:36:48 CET] <JEEB> you need to force mp4 or whatever the fragmented mp4 demuxer in VLC is [09:36:57 CET] <JEEB> if you don't want to force a demuxer, use an extension [09:37:17 CET] <friendofafriend> Like naming it .mp4, right? [09:37:23 CET] <JEEB> yes, if it is actually mp4 [09:37:40 CET] <JEEB> ffprobe should tell you then what it figures out `ffprobe -v verbose -i URL` [09:37:52 CET] <fling> kingsley: I could put a thumbnail as a video stream and can add the text file as a comment exif field of the thumbnail :> [09:38:16 CET] <JEEB> for random text files in multimedia files matroska had a nice feature called attachments [09:38:22 CET] <JEEB> usually utilized for stuff like fonts for subtitles [09:38:30 CET] <JEEB> but you could utilize that for putting random txt files into stuff [09:38:59 CET] <JEEB> friendofafriend: if you need more idea on the HTML5 video stuff, I recommend reading up on MSE et al from Mozilla's MDN [09:39:36 CET] <montana> what do you people think about vp9 vs x265 [09:40:12 CET] <JEEB> x265 is an encoder, so you probably mean HEVC/H.265 there [09:40:20 CET] <montana> jeeb sorry you are right [09:40:27 CET] <JEEB> anyways, no matter if format is good or bad; the encoders decide [09:40:42 CET] <montana> i guess [09:40:44 CET] <JEEB> I can have an opinion on the format spec, but that doesn't mmean I can utilize the good things in the spec :) [09:40:54 CET] <JEEB> libvpx is notoriously bad [09:40:59 CET] <JEEB> for stuff like rate control [09:41:11 CET] <JEEB> you can clearly see it's google's "throw over all" style of open source :) [09:41:18 CET] <JEEB> "it works for our use case, that's it" [09:41:19 CET] <friendofafriend> I think it's making an MP4 container now? Still no dice with that darn traffic cone. https://paste.debian.net/plain/1117410 [09:41:22 CET] <montana> wow it is? does youtube/google use libvpx ? [09:41:34 CET] <JEEB> yes [09:41:56 CET] <JEEB> VP8/VP9 are google formats (VP8 originally On2's which Google bought) [09:42:13 CET] <montana> if libvpx is notoriously bad, why does google use it [09:42:20 CET] <JEEB> because it works well enough for their use case [09:42:22 CET] <JEEB> which is very specific [09:42:44 CET] <montana> then in what case is it horrible [09:42:48 CET] <montana> can you give me an example [09:43:11 CET] <JEEB> if you want actual psychovisual optimizations and good compression and rate control [09:43:23 CET] <JEEB> rate control and psychovisual optimizations is where libvpx suck [09:43:47 CET] <JEEB> which is why the encoder that one of the FFmpeg developers is selling is getting licensed by corporations :P because it makes prettier output for the same bit rate [09:43:53 CET] <montana> jeeb i see so if you are comparing libvpx vs x265, x265 is superior? [09:44:17 CET] <JEEB> x265 is also a trash can :D but at least it implements a standardized trash can and can utilize some code off of x264 [09:44:29 CET] <JEEB> but yes, I would probably utilize x265 more easily than vpx [09:44:55 CET] <JEEB> basically, lack of community participation in both libvpx and x265 are making it less fun than x264 for example [09:45:22 CET] <JEEB> x265 for example still doesn't properly do psychovisual optimization when utilizing large blocks [09:45:31 CET] <JEEB> as in, larger than x264's 16x16 [09:45:37 CET] <montana> jeeb then why do i see #x265 channel in freenode [09:45:55 CET] <Weasel_> friendofafriend: your problem is that mp4 is not streaming friendly if it is not fragmented, put in into flv if you want to stream it like that the easy way [09:45:57 CET] <JEEB> because it was made? :D I think I used to be there and I even contributed some documentation stuff years ago [09:46:23 CET] <JEEB> Weasel_: how is FLV better than fragmented MP4 over a constant connection? [09:46:43 CET] <Weasel_> I didn't say its better but easy [09:46:48 CET] <JEEB> how is it easier? [09:47:07 CET] <montana> jeeb you don't see #vc1/#wmv channel in freenode [09:47:35 CET] <JEEB> montana: of course not. you have channels around for both libvpx (#vp8 if I recall correctly) and x265 [09:47:52 CET] <JEEB> unless someone made a channel to reverse engineer that stuff (although VC-1 has a specification) [09:48:05 CET] <Weasel_> JEEB: I don't know how to make fragmented mp4 like just changing filename extension [09:48:07 CET] <JEEB> what I mean is that the community never really got into x265 or libvpx [09:48:22 CET] <JEEB> Weasel_: I just posted the flags and the guy is now happily pushing out fragmented mp4? [09:48:30 CET] <JEEB> (Ž4@) [09:48:37 CET] <JEEB> also if you need a real streaming container, there is MPEG-TS [09:48:43 CET] <JEEB> which is standardized [09:48:46 CET] <JEEB> and thus better than FLV [09:49:36 CET] <Weasel_> JEEB: I missed that [09:50:34 CET] <JEEB> FLV is effectively limited to H.264+AAC and single audio and video stream only. and its timestamps are in 1:1000. and it will never be extended because adobe doesn't care [09:50:58 CET] <JEEB> ideas in RTMP were good, but we have better standardized containers to build similar TCP based streaming things [09:51:07 CET] <JEEB> be it MPEG-TS, fragmented MP4 or something else [09:58:51 CET] <friendofafriend> JEEB: MPEG-TS works great! But I don't know what to use as a player for a pointy-clicky-web-browser user. [10:00:15 CET] <Weasel_> friendofafriend: my hls/dash commandline for hls.js/dash.ja, dual stream from ip cam for adaptive stream https://pastebin.com/Y1jmk3qR [10:00:18 CET] <JEEB> friendofafriend: well hls.js does have a JS MPEG-TS parser and parts that pass it through to the media parts [10:00:34 CET] <JEEB> but you would have to implement the live stream as continuous MPEG-TS stream *yourself* [10:00:50 CET] <JEEB> as noted, HLS and DASH is what have pre-existing solutions which you can "just include in a web page" [10:01:44 CET] <montana> jeeb thanks for the info [10:01:47 CET] <friendofafriend> I'm not doing anything terribly complicated. Is there a way to play FLV in the browser? FLV is loading fine in VLC here. [10:02:17 CET] <Weasel_> flv.js via rtmp server [10:03:15 CET] <friendofafriend> Oh, it'd have to be rtmp. I've just got some Icecast server. [10:04:56 CET] <montana> mkv is superior than flv [10:05:35 CET] <montana> mkv is superior than flv/mp4 because mkv can be played unfinished/partially encoded/downloaded file [10:05:55 CET] <montana> not sure about webm [10:06:11 CET] <JEEB> fragmented mp4 works just fine with unfinished [10:06:15 CET] <JEEB> nobody just uses them by default :P [10:06:33 CET] <montana> mkv have one weakness [10:06:49 CET] <montana> audio bitrate doesn't show up correctly on mkv container [10:06:58 CET] <montana> but it shows correctly on mp4 container [10:07:15 CET] <montana> i wonder why that is [10:09:24 CET] <friendofafriend> Must have made the FLV container the wrong way. I found http://bilibili.github.io/flv.js/demo/ , gave it the URL of the stream and it reports " [10:09:38 CET] <friendofafriend> ... Sorry, "[TransmuxingController] > Non-FLV, Unsupported media type!" [10:11:50 CET] <montana> https://mp4repair.org/ is the only website/tool that can repair mp4 file [10:13:20 CET] <Weasel_> friendofafriend: hls.js/dash.js easier if you have a web server you can use to serve those files produced by ffmpeg, no setting up rtmp [10:14:23 CET] <friendofafriend> Weasel_: I think the delay would be sort of a problem, it's ~1min, right? [10:16:09 CET] <montana> if i use this command, what would happen to audio? ffmpeg -i input.mkv -c:v libaom-av1 -crf 30 -b:v 0 output.mkv [10:17:09 CET] <Weasel_> friendofafriend: seems to be ~20 secs, flv ~2 sec [10:19:33 CET] <friendofafriend> FLV seems like a better fit than what I was doing before, especially if HTML5 players don't handle live content anyway. [10:20:44 CET] <friendofafriend> I sure hope I can figure out a way to get flv.js working. The demo of flv.js seems to indicate my FLV file is still somehow pooched. [10:21:31 CET] <Weasel_> friendofafriend: I am testing Node-Media-Server which is able to fetch rstp streams and serve those [10:26:38 CET] <friendofafriend> I guess I'm more confused than ever. That flv.js "works by transmuxing FLV file stream into ISO BMFF (Fragmented MP4) segments, followed by feeding mp4 segments into an HTML5 <video> element through Media Source Extensions API." [10:27:57 CET] <Weasel_> MSE can chew those fragmented mp4 as JEBB said, but problem is getting them there [10:29:29 CET] <JEEB> Weasel_: flv.js I understand why it exists (pre-existing FLV+RTMP crap) but I really dislike recommending it to people xD [10:29:47 CET] <JEEB> but yea, people really haven't focused on MPEG-TS or fragmented MP4 things in .js MSE [10:29:55 CET] <JEEB> as in, outside of DASH etc [10:31:38 CET] <Weasel_> JEEB: just giving options, latency is a bit of a problem with hls/dash for me which I haven't yet found out how to resolve [10:32:38 CET] <friendofafriend> Using an FLV container has already helped a lot, and I really appreciate the direction. [10:34:16 CET] <friendofafriend> Now to discover the weird world of .js players! It seems like a real freak show, outside of that HTML5 stuff. Wish they'd considered live streams. [10:37:39 CET] <montana> i just did ffmpeg -i input.mp4 -c:v libaom-av1 -crf 30 -b:v 0 output.mkv which is 1 minute video and it resulted in 5 second output.mkv [10:37:46 CET] <montana> why is it doing that [10:38:04 CET] <squ> framerate? [10:38:47 CET] <montana> 5 fps [10:39:04 CET] <squ> and the result [10:39:49 CET] <montana> 5 fps but 5 second [10:39:53 CET] <montana> not 1 minute [10:40:12 CET] <squ> what framerate input has [10:40:16 CET] <montana> 5 fps [10:40:27 CET] <squ> idk then [10:41:17 CET] <montana> and how do i modify that command so that it doesn't reencode the audio and just do bypass audio [10:41:29 CET] <squ> -c:a copy [10:41:37 CET] <montana> oh akay thanks [10:59:32 CET] <JEEB> Weasel_: yea, I mean you could do very similar things to RTMP+FLV with TCP/HTTP and MPEG-TS or MP4 pipes. possibly not even much harder than that :D [10:59:44 CET] <JEEB> it's just that at least publicly you don't have orange site posts about stuff like that [11:16:25 CET] <Weasel_> JEEB: hmmh, there seems to be websocket servers and near realtime js players out there. I would still like to be (upcoming) standards compliant so client could be anything that works for one [11:17:04 CET] <JEEB> Weasel_: yea websockets usually pop up because people seem to not be able to drop buffers with XHR [11:17:15 CET] <JEEB> (XMLHtttpRequest or whatever it was in JS) [11:17:25 CET] <JEEB> so if you have a long-running XHR request it will just buffer up and up [11:17:34 CET] <JEEB> I have heard you can work around this, but I have never tested this [11:17:52 CET] <JEEB> another standard thing is webrtc [11:17:58 CET] <JEEB> and there is seemingly a python media server for that [11:19:26 CET] <JEEB> https://github.com/aiortc/aiortc [11:19:35 CET] <JEEB> I haven't tested this, but some people seem to be using this [11:19:42 CET] <JEEB> under the hood WebRTC is "just RTP" which is great :P [11:19:49 CET] <JEEB> because RTP is low latency, UDP [11:20:03 CET] <Weasel_> I have taken a quick look at that but still at testing technologies phase [11:20:31 CET] <JEEB> I think webrtc is already on less testing phase than f.ex. all the mess with low latency HLS and DASH :P [11:20:52 CET] <JEEB> since it will probably tkae half a year or a year until those file based things get settled [11:22:05 CET] <JEEB> and the apple LLHLS is going to wreck people's hopes about being OK with a "dumb" file cache [11:23:23 CET] <JEEB> anyways, as long as your solution works in mobile and browsers and uses standard tools like MPEG-TS/MP4/HTTP/WebRTC it is "good enough" I'd say. [12:09:41 CET] <cluelessperson> I'm looking for a way to reliably transcode media and stream it viea html easily [12:09:46 CET] <cluelessperson> I don't know where to look [12:13:09 CET] <TheAMM> How are there so many people trying to stream currently? Weird [12:13:25 CET] <cluelessperson> TheAMM, it's a common problem/task. [12:13:53 CET] <cluelessperson> I want to stream out security camera footage, or a shared video to my brother, or an animation, or whatever. [12:14:04 CET] <BtbN> "stream vis HTML", so, you mean HLS/DASH? [12:14:09 CET] <TheAMM> Yes, but there's been like four or five people talking about it or nearby subjects within the past few days [12:14:20 CET] <cluelessperson> yes, probably HLS/DASH [12:14:23 CET] <TheAMM> And I personally am writing a security cam thing as well [12:14:24 CET] <cluelessperson> oh weird [12:16:01 CET] <TheAMM> If you don't want to mess with hls, look at fragmented mp4, though you'll have to do extra work if you want multiple viewers (without starting an encode for each) [12:18:22 CET] <TheAMM> Ie. server spawns ffmpeg for fragmented mp4, reads stdout and sends that to client (browser) [12:18:54 CET] <TheAMM> There's lots of ways to stream video though and I'm not the expert, so state your case and someone might help [12:24:56 CET] <JEEB> HLS/DASH is the simplest thing to get rolling [12:25:01 CET] <JEEB> with browsers and mobile [12:25:06 CET] <cluelessperson> TheAMM, I'm hoping for a super simple/easy prerolled solution. [12:25:08 CET] <JEEB> bcause everone has already written the client side [12:25:16 CET] <JEEB> you have hls.js/dash.js for browser [12:25:25 CET] <cluelessperson> "run this thing with this config" "make availble this file or stream and bam, it's distributed" [12:25:27 CET] <JEEB> you have exoplayer for mobile (android) and the iOS thing for HLS [12:26:10 CET] <JEEB> cluelessperson: get an http server out like nginx, enable PUT/POST from specific IPs etc (internal, your encoder), then use the hls or dash module [12:26:22 CET] <JEEB> that will get you a HLS or DASH stream [12:26:30 CET] <JEEB> module in FFmpeg that is [12:27:08 CET] <cluelessperson> JEEB, that sounds doable. [12:27:31 CET] <montana> anybody know which aac encoder youtube/google uses [12:28:05 CET] <BtbN> I'd guess fdk, since that one was ripped out of Googles source tree [12:28:05 CET] <JEEB> cluelessperson: if you need web browser support AND live streaming, that is probably atm the most off-the-shelf thing [12:28:59 CET] <JEEB> BtbN: you'd be surprised how separate from each other those blocks within GOOG are [12:29:10 CET] <JEEB> since fdk-aac comes from AOSP [12:29:19 CET] <BtbN> Google says YouTube might be using FhG AAC, which I have never heard of before. [12:29:30 CET] <JEEB> that's fraunhofer, and fdk-aac is fraunhofer [12:30:15 CET] <BtbN> so Fraunhofer made two entirely separate AAC encoders? [12:30:45 CET] <montana> fdk-aac isn't as good as apple's aac encoder though [12:31:01 CET] <BtbN> I doubt Google is using Apple encoders. [12:31:55 CET] <montana> i just realized youtube is incredibly stupid; i uploaded a 32kbps audio, yet it creates a 96kbps dash audio [12:32:20 CET] <BtbN> Of course it does. It has its standard set of outputs, and it will encode them no matter what. [12:32:48 CET] <montana> btbn i am pretty sure you are even not that stupid to do such thing [12:33:10 CET] <BtbN> I also fail to see why it's stupid. When transcoding, using a slightly higher bitrate to preserve quality isn't unheard of. [12:33:13 CET] <JEEB> it has nothing to do with stupid [12:33:28 CET] <JEEB> you have set outputs, you do them. you do not take what the input was into account. [12:33:36 CET] <JEEB> that way you know exactly what you are getting out [12:33:37 CET] <JEEB> always [12:33:55 CET] <montana> does it make any sense to transcode 32 kbps speech audio into flac? [12:34:19 CET] <BtbN> If flac is your standardized output, sure. [12:34:41 CET] <BtbN> But audio bitrate is usually tiny enough so you don't need to care that much. [12:34:51 CET] <BtbN> If they transcoded every video to 1080p, that'd be a bit of a waste. [12:35:20 CET] <montana> btbn i doubt they do that [12:35:31 CET] <BtbN> Which is what I just said, yes. [12:38:21 CET] <montana> it also transcode 4 fps video to 6 fps [12:38:45 CET] <montana> how does one just add 2 extra from nothing? [12:38:51 CET] <montana> extra frames* [12:38:55 CET] <BtbN> you duplicate frames as usual [12:39:12 CET] <montana> btbn that's a lot of wasted bandwidth [12:40:10 CET] <BtbN> no, it's not. [12:40:19 CET] <BtbN> A duplicated frame will compress to virtually nothing. [12:40:49 CET] <montana> also i uploaded 60kbps video and it creates 400kbps dash video [12:40:58 CET] <BtbN> And bumping the framerate to something that can be smoothly played on 24/30/60/120/144 Hz screens makes a lot of sense [12:41:19 CET] <montana> that's a lot of wasted bandwidth [12:41:25 CET] <BtbN> ? [12:41:30 CET] <montana> also i uploaded 60kbps video and it creates 400kbps dash video [12:41:50 CET] <BtbN> 60kbps video is stupid enough to be ignored in their setup [12:42:19 CET] <BtbN> They will transcode it with their standard set of transcodes for the given resolution no matter what. [12:42:44 CET] <montana> you cannot make magically m ake 60kbps look better by making it 400kbps [12:42:54 CET] <BtbN> Nobody claimed it does. [12:43:03 CET] <montana> so it's pointless [12:43:24 CET] <BtbN> YouTube _always_ transcodes, just to have a standard set of outputs they know their player can deal with. [12:44:05 CET] <BtbN> And for security reasons I suppose. [12:44:26 CET] <montana> what does extra kbps have to do with security? [12:44:43 CET] <BtbN> You do not give user-uploaded data to your viewers. [12:44:52 CET] <BtbN> One zero-day in the decoder, and you're in for a bad time. [12:44:57 CET] <BtbN> So you always transcode. [12:45:25 CET] <montana> i don't understand [12:45:44 CET] <BtbN> That seems to be the case for everything you brought up so far, yes. [12:48:18 CET] <montana> btbn have you actually seen a video that is malicious [12:48:33 CET] <BtbN> There's been plenty of those, yes. [12:48:58 CET] <BtbN> You can completely takeover most Android-Phones that are lacking security updates that way. [12:49:29 CET] <montana> but are they actually legit videos? [12:50:04 CET] <BtbN> They are crafted to run an exploit payload [12:57:43 CET] <montana> i want to encode using av1, what is best way to do this without having issues [12:58:21 CET] <CounterPillow> Not using av1 [12:58:48 CET] <montana> CounterPillow why is av1 giving so much issues [12:59:44 CET] <CounterPillow> Is it? [13:00:29 CET] <montana> i just did ffmpeg -i input.mp4 -c:v libaom-av1 -crf 30 -b:v 0 output.mkv which is 1 minute video and it resulted in 5 second output.mkv [13:01:26 CET] <CounterPillow> Most distributions ship an ancient libaom [13:01:43 CET] <montana> i am using 4.2.1 [13:02:03 CET] <CounterPillow> That does not tell me anything about your libaom version [13:02:11 CET] <montana> sorry you are right [13:02:17 CET] <CounterPillow> Which is what encodes the video here. [13:02:37 CET] <montana> how do i find the version # [13:03:13 CET] <CounterPillow> I'm sure your distribution has some sort of package manager that would tell you this [14:08:32 CET] <Hello71> kingsley: I doubt that this exists in ffmpeg. maybe you can find it as a plugin for some video editing software [14:09:11 CET] <Hello71> did you read man ffmpeg-filters [14:43:50 CET] <realies> can you use ffmpeg to do a classic peak normalisation without the dynamic leveling? [15:00:18 CET] <durandal_1707> realies: yes, volume filter [15:22:49 CET] <realies> durandal_1707, you mean volumedetect + volume? [15:34:50 CET] <Techman> Hmm, had a guy on /r/irc talk about not being able to talk in here. Can you guys consider putting something in the topic that mentions having to be registered to speak? [16:36:48 CET] <TheAMM> You can see that in the channel mode and I expect the server should also warn in the status buffer [16:37:02 CET] <TheAMM> Of course this will all fly over their heads [16:47:05 CET] <pink_mist> TheAMM: you need to /mode #ffmpeg +q to see it [16:47:11 CET] <pink_mist> it's not in the channel mode at all [16:47:47 CET] <DHE> channel doesn't have any mode flags that would prevent talking in a channel without registering.. [16:48:20 CET] <DHE> wait, is there a +q match for unregistered that's set? [16:48:26 CET] <pink_mist> DHE: yes it does, it has +q $~a [17:09:19 CET] <pinky> $ ffmpeg -v verbose -i rtp://@224.0.0.56:46712 -f mp3 udp://172.20.36.128:3000 [17:09:26 CET] <pinky> seems to just sit here and never output anything [17:12:12 CET] <pinky> when i ^C i get [17:12:13 CET] <pinky> [AVIOContext @ 0x55e57c439d00] Statistics: 0 bytes read, 0 seeks [17:12:13 CET] <pinky> udp://@224.0.0.56:46712: Immediate exit requested [17:12:36 CET] <pinky> when i tcpdump i see 16:12:23.010316 IP 172.20.32.10.59464 > 224.0.0.56.46712: UDP, length 1272 [17:24:39 CET] <familiyaF> Hi, how can I verify if the video is 29.97i(59.94 fields) using ffprobe [17:44:32 CET] <JEEB> familiyaF: you can decode a few frames of the video stream and utilize data from -show_streams and -show_frames [17:45:06 CET] <JEEB> I'd think that by decoding like 5 frames you'd probably have enough for a guesstimate [17:51:58 CET] <familiyaF> JEED: Thanks, got the information [17:52:03 CET] <familiyaF> interlaced_frame=1 [17:52:03 CET] <familiyaF> top_field_first=1 [17:52:21 CET] <JEEB> and match that with the PTS difference [17:52:36 CET] <familiyaF> r_frame_rate=19001/317 [17:52:36 CET] <familiyaF> avg_frame_rate=19001/317 [17:52:57 CET] <JEEB> those are different, you can also just compare either pts or pts_time [17:53:00 CET] <JEEB> of the frames [18:01:33 CET] <pinky> how do you set the input sample rate? nothing i do works [18:01:39 CET] <pinky> $ ffmpeg -v verbose -i <(pamon) -ich 1 -och 1 -isf s16 -isr 44100 -f mp3 /tmp/tf.mp3 [18:01:43 CET] <pinky> just getting static [18:05:55 CET] <JEEB> -sample_rate ? before input [18:06:11 CET] <JEEB> also probably want to set sample format too, unless that one is already correct [18:06:26 CET] <JEEB> input related options generally go before -i [18:06:30 CET] <pinky> ah ok [18:06:31 CET] <JEEB> output related go after [18:06:33 CET] <pinky> let me try [18:08:18 CET] <pinky> ugh nothing works [18:08:54 CET] <JEEB> I'm not sure what you're doing with the pamon stuff etc [18:09:03 CET] <pinky> just want to stream an mp3 from pulseaudio [18:09:11 CET] <JEEB> try dumping something you know is actually s16le [18:09:22 CET] <JEEB> into a temp file first (without an extension) [18:09:30 CET] <JEEB> just to make sure we get the parsing of that right [18:09:38 CET] <JEEB> then you can switch the input to your pulse or whatever [18:09:42 CET] <pinky> pamon default according to pamon -h should be 44100 and s16ne [18:09:53 CET] <pinky> ffmpeg doesn't have an s16ne though [18:10:07 CET] <JEEB> that's probably "native endian" which means little endian on most x86 machines :P [18:10:23 CET] <JEEB> so ffmpeg -v verbose -f s16le -ar 44100 -i stuff [18:10:27 CET] <JEEB> that should do it :P [18:10:45 CET] <JEEB> also probably number of channels is useful too :P [18:10:50 CET] <JEEB> -ac 1/2 [18:11:00 CET] <pinky> ah nice [18:11:01 CET] <JEEB> https://trac.ffmpeg.org/wiki/audio%20types [18:11:32 CET] <pinky> Stream #0:0 -> #0:0 (pcm_s16le (native) -> mp3 (libmp3lame)) [18:11:34 CET] <pinky> trying [18:12:06 CET] <pinky> ah! that works :) [18:12:15 CET] <pinky> thanks a lot :) [18:12:18 CET] <JEEB> np [18:12:26 CET] <pinky> nwo i just need to get nginx to stream it [18:12:33 CET] <pinky> hopefully i can write it to a unix socket [18:13:24 CET] <furq> you probably want icecast for that [18:13:36 CET] <pinky> ah yeah might be easier [18:13:44 CET] <pinky> had trouble last time i was trying to do it with nginx [18:13:54 CET] <furq> an icecast url should work fine in an audio tag [18:13:58 CET] <furq> or directly in a browser [18:14:17 CET] <furq> plus nginx can just feed it directly [18:14:20 CET] <furq> er [18:14:22 CET] <furq> plus ffmpeg can just feed it directly [18:21:26 CET] <pinky> ah sweet :) [18:21:30 CET] <Anderssen> to the topic of extracting teletext: I've tried to decode to plain text, and it works, but somehow it doesn't work with bitmap: https://pastebin.com/Mg28EWS0 [18:22:09 CET] <Anderssen> what does work, is when I change to "-txt_format text" and output as .srt, but of course that doesn't preserve colors [18:23:18 CET] <JEEB> Anderssen: -txt_format ass and output to ass [18:23:23 CET] <JEEB> that preserves a lot of the stuff [18:23:29 CET] <JEEB> text is literally just the text part [18:23:51 CET] <JEEB> for the bitmap mode you have to output as images [18:23:58 CET] <JEEB> not exactly going to work in a text-only subtitle format :) [18:24:09 CET] <JEEB> so something like image2 I think? [18:24:21 CET] <JEEB> where you define a pattern and then get the images written out as png or something [18:24:55 CET] <Anderssen> this gives me this error: https://pastebin.com/RCui2GwY [18:26:43 CET] <JEEB> I have no idea how that goes to eval or something [18:27:12 CET] <JEEB> sounds like something really weird is going on in that thing [18:27:18 CET] <JEEB> try with current master FFmpeg? [18:28:41 CET] <JEEB> because txt_format value ass definitely exists [18:29:00 CET] <JEEB> http://up-cat.net/p/93f8bdea [18:29:51 CET] <Anderssen> is the current ffmpeg master available on a SuSe repository; or would I have to compile it manually? [18:30:00 CET] <JEEB> unless... Anderssen `ffmpeg -h decoder=libzvbi_teletextdec` [18:30:08 CET] <JEEB> see if the ass value even exists in your old FFmpeg? [18:30:17 CET] <Anderssen> yes, it says text, bitmap and ass [18:31:01 CET] <JEEB> I have no idea of opensuse package availability. there was someone building 64bit linux binaries and those might include zvbi? [18:31:19 CET] <JEEB> https://johnvansickle.com/ffmpeg/ [18:31:33 CET] <JEEB> yea, has zvbi [18:31:54 CET] <Anderssen> I think zvbi should be installed anyway; the txt_format option is from libzvbi, no? [18:31:59 CET] <friendofafriend> I'm sending h264 video in an FLV container to an Icecast server. There are no errors in the ffmpeg terminal output, but after some time ffplay will only show "Invalid data found when processing input" when playing the stream. Is there any obvious brain damage with my command? https://paste.debian.net/plain/1117489 [18:32:07 CET] <JEEB> Anderssen: I meant the binary which I linked :P [18:32:13 CET] <JEEB> which are static binaries for 32bit and 64bit linux [18:32:45 CET] <JEEB> Anderssen: I had to check the build info document whether the person enables compilation with zvbi or not [18:35:22 CET] <JEEB> Anderssen: alternatively you could build FFmpeg yourself with --enable-libzvbi --enable-zlib [18:35:36 CET] <JEEB> zlib for PNG output, zvbi for ttxt decoding [18:36:04 CET] <Anderssen> hm, let's see, I'm trying to install the master now [18:40:26 CET] <Anderssen> ok, it produced an output .ass file with -txt_format ass [18:46:38 CET] <Anderssen> ok, so, I saved page 100 from teletext and did a .ass file; apparently vlc didn't like that file, it just showed me a black screen as soon as i loaded it and went superfast (according to timestamp). however, smplayer displayed that page properly. I wonder what happens if I do several pages [18:47:15 CET] <JEEB> you might need -fix_sub_duration with teletext and some other broadcast subtitle formats [18:47:28 CET] <JEEB> since the text samples don't contain durations [18:47:50 CET] <JEEB> Anderssen: basically it might end up in a mess because you're going to get it all in a single stream [19:03:49 CET] <Anderssen> ok, what happens is that, when I save 5 pages, in the .ass file all of those pages get a start time code with 0.04 s apart from each other and a duration that is being given by the parameter -fix_sub_duration (otherwise it's a duration of 10 hours, apparently). [19:04:26 CET] <JEEB> Anderssen: yea since the duration gets calculated as the difference of receipt between the AVSubtitles [19:04:39 CET] <Anderssen> the file was at 25 fps, so 0.04 would mean that every frame there would be another subtitle page; except that when the first page lasts 5 seconds, the other's don't overwrite them [19:05:24 CET] <JEEB> generally it's a bad idea to try and pull in multiple subtitle pages into a single output [19:06:03 CET] <JEEB> -fix_sub_duration with a single page should give you proper results [19:08:42 CET] <Anderssen> yeah, though then it appears that i have to either start ffmpeg multiple times (for each page) in order to produce 1 .ass file each, or to produce 1 file and then copy/pase 1 line out of it or delete the rest in order to view just a single page [19:09:20 CET] <JEEB> you can just have multiple inputs (-i BLAH) with a differing page selection in there [19:09:27 CET] <JEEB> unfortunately we don't mark the AVSubtitles with the page [19:09:43 CET] <JEEB> otherwise you could filter them as they come out of the decoder [19:09:49 CET] <JEEB> and not have X decoders :P [19:10:00 CET] <Anderssen> I don't get though why it produces no bmp [19:10:25 CET] <JEEB> with bitmap? [19:10:42 CET] <JEEB> post full command with -v verbose and its terminal output in a pastebin, link here [19:11:22 CET] <Anderssen> yeah , it's still the same output like before though (with master ffmpeg) [19:13:15 CET] <Anderssen> in order to be sure: https://pastebin.com/NXL7iekf [19:20:16 CET] <void09> ok this is weird, making a mkv from a 8.6GB .ts with mkvtoolinks results in 4.4GB, with ffmpeg, 8.4GB, what is going on here :\ . bitrate shows to be about half in the mkvtoolnix generated one, and the file appears complete when playing it [19:20:50 CET] <furq> did you map all the streams [19:20:58 CET] <void09> there's just two, audio and video [19:25:37 CET] <void09> please tell me how to debug this [19:27:14 CET] <void09> 6034kbps video for the mkvtoolnix one, 11.3Mb/s for the ffmpeg one, 11.3Mb/s in the .ts [19:27:37 CET] <void09> I know for a fact it's supposed to be around 11, so what could have happened with the mkvtoolnix one [19:47:04 CET] <DanielTheFox> hi there [19:47:28 CET] <DanielTheFox> is there a way to make ffmpeg perform frameskip if the output target bitrate (for video at least) is too low? [19:47:50 CET] <JEEB> no, that is generally an encoder feature [19:47:50 CET] <DanielTheFox> that is, start skipping frames "dynamically" instead of reducing quality [19:47:53 CET] <DanielTheFox> aww [19:48:03 CET] <DanielTheFox> does either mpeg4 or h263 do that? [19:48:52 CET] <JEEB> not that I can tell [19:48:57 CET] <DanielTheFox> oh [19:49:07 CET] <DanielTheFox> ok, so I'll just stick to manually tampering with framerate [19:49:27 CET] <Hello71> this seems like a bad idea [19:49:33 CET] <DanielTheFox> now, is there a way to make ffmpeg change its output framerate at user request in the middle of a transcoding job? [19:49:51 CET] <JEEB> there was some thing to adjust parameters for video filters, so in theory [19:50:10 CET] <JEEB> although it almost sounds like you want extra logic in the API client [19:50:22 CET] <JEEB> (ffmpeg.c is also an API client of the FFmpeg APIs) [19:50:30 CET] <DanielTheFox> heh [19:51:31 CET] <DanielTheFox> so it's likely that I'll just split the video in many parts, set them varying framerates and then glue them with no framerate changing (and using a container that doesn't mind having changing framerates, such as MP4 or MKV) [19:52:08 CET] <DanielTheFox> then I'll end with a video that in theory should be standard, but some (or many) players, especially hardware ones, will start having troubles playing [19:52:25 CET] <JEEB> thanks to the proliferation of mobile phone camera videos I wouldn't be too worried [19:52:45 CET] <JEEB> I mean, there surely are some plastic boxes that will fail, but that number is becoming slimmer and slimmer [19:52:55 CET] <DanielTheFox> hrm, yeah [19:53:12 CET] <JEEB> but yea, what you mean are timestamp based containers [19:53:12 CET] <DanielTheFox> my user base is extremely specific and known to have to deal with those specific issues [19:53:14 CET] <JEEB> as opposed to frame rate [19:53:20 CET] <DanielTheFox> yeah, MP4 vs AVI [19:53:34 CET] <JEEB> in AVI you could hack it with skip [19:53:42 CET] <DanielTheFox> but then I'm not free either [19:53:54 CET] <GenTooMan> WEBM? [19:54:02 CET] <JEEB> free? [19:54:20 CET] <DanielTheFox> well, hrm [19:54:31 CET] <DanielTheFox> if the container says I'm 30 fps [19:54:44 CET] <DanielTheFox> and I start skipping frames, then I might have 15 fps, 10 fps, 7.5 fps [19:54:47 CET] <JEEB> timestamp based containers have timestamps [19:54:50 CET] <JEEB> not frame rate [19:54:51 CET] <DanielTheFox> but not really 24 or something [19:54:57 CET] <DanielTheFox> oh, yeah, glad MP4 exists [19:55:03 CET] <JEEB> matroska's the same [19:55:06 CET] <JEEB> mpeg-ts as well [19:55:07 CET] <JEEB> etc etc [19:55:12 CET] <DanielTheFox> AVI is gonna have such issues from old days tho [19:55:23 CET] <DanielTheFox> although, again, I might have to deal with these ones as well [19:55:37 CET] <JEEB> yes, AVI is where you used to make the frame rate 120/1.001 and then used skip frames to put various frame rates into it :P [19:55:54 CET] <DanielTheFox> (the issues are related to avoid throwing legacy equipment to trash, which personally I agree with for both economical and environmental reasons) [19:56:58 CET] <DanielTheFox> ok, so, hrm [19:57:03 CET] <GenTooMan> The unfortunate thing is people built things with the replaceable mindset instead of considering how permanent things are. The Cell phone is a classic example. [19:57:42 CET] <DanielTheFox> yeah, I think my time is worth less than throwing expensive stuff to the trash bin [19:58:10 CET] <DanielTheFox> especially because I already do pretty much nothing, so I consider my time very affordable [19:58:51 CET] <DanielTheFox> hrm, so. [19:59:01 CET] <DanielTheFox> I believe I'll experiment with the available filters [19:59:26 CET] <DanielTheFox> see ya boys, you'll know when I have an issue if I come back [19:59:31 CET] <DanielTheFox> thanks for the info. [20:00:29 CET] <GenTooMan> I suspect we all have issues... :D [20:02:56 CET] <void09> JEEB: got a .ts file that turned almost half in size when converted to mkv with mkvtoolnix. ffmpeg shed just around 7% [20:03:23 CET] <void09> I am thinking maybe this station uses some kind of padding in the container, to keep data rate constant even if actual av bitrate can vary [20:03:24 CET] <JEEB> are you sure both included the same streams etc? [20:03:34 CET] <void09> yes, it's just audio + video [20:03:34 CET] <JEEB> yes, padding packets are a normal thing in MPEG-TS for broadcast [20:03:39 CET] <JEEB> but that shouldn't get remuxed [20:03:44 CET] <void09> well, it does [20:03:49 CET] <JEEB> so it can have padding H.264 packets [20:03:59 CET] <void09> that's an awful lot of padding [20:04:12 CET] <JEEB> well, feel free to look at the thing in DVB Inspector? [20:04:17 CET] <JEEB> that has nice graphs n' stuff [20:04:28 CET] <JEEB> (it's my go-to tool to look at insides of MPEG-TS) [20:05:15 CET] <JEEB> basically since you tell me both remuxed the same streams, it must mean that one of them filtered stuff out of the streams :P [20:05:21 CET] <JEEB> or you are misunderstanding wtf the tools are doing [20:05:31 CET] <JEEB> thus, looking at what's inside the MPEG-TS originally might help you understand [20:06:04 CET] <JEEB> and yes, half of the thing being padding is an awful lot, but the container level padding is not passed through in FFmpeg [20:06:10 CET] <void09> JEEB: one .ts recording from 8.6gb went down to 4.4gb in mkvtoolnix, 8.4gb in ffmpeg [20:06:24 CET] <JEEB> thus the only thing where you can have padding is the actual streams [20:06:32 CET] <JEEB> and H.264 are known to possibly have padding packets [20:06:35 CET] <JEEB> *is known [20:06:38 CET] <JEEB> void09: that is not what I mean [20:06:51 CET] <void09> tried other raw recording from the same station, 15.1gb to 11.2gb in mkvtoolnix [20:07:02 CET] <JEEB> you tried to imply that FFmpeg when remuxing somehow copied the input container padding [20:07:05 CET] <JEEB> which it does not [20:07:12 CET] <JEEB> since you do *not* receive the padding through the APIs [20:07:12 CET] <void09> maybe i am remuxing it wrong [20:07:28 CET] <JEEB> thus the only thing where the padding can be are the elementary streams [20:07:41 CET] <void09> I did -vcodec copy -acodec copy outputvideo.mkv [20:07:44 CET] <JEEB> anyways, just take a look at the darn input file in DVB Inspector or so :P [20:07:55 CET] <JEEB> you will then see if it's container level, or the streams [20:08:08 CET] <void09> looking at it, but what am i supposed to look for [20:08:10 CET] <JEEB> if it's container level, the container bit rate is much higher than the included streams' average [20:08:26 CET] <JEEB> while if the streams are actually shown taking most of the space [20:08:39 CET] <JEEB> then the padding or whatever mkvmerge rips out is within the streams [20:08:47 CET] <JEEB> which yes, would get remuxed by FFmpeg most likely [20:09:03 CET] <JEEB> (there are bit stream filters which might help you with that - you just need to apply them explicitly) [20:10:45 CET] <void09> there's transport packets in the .ts with the same data "bx rum IT", repeating [20:11:19 CET] <JEEB> yea, but unless those show up as actual stream content in payload [20:11:25 CET] <JEEB> which padding packets shouldn't [20:11:59 CET] <JEEB> void09: you can easily look at the bit rate graph tab [20:12:21 CET] <void09> it looks mostly blue [20:12:36 CET] <JEEB> it should tell you the legend for what is blue [20:12:42 CET] <void09> bi bykk oacjets [20:12:48 CET] <void09> no NUL packets* [20:13:07 CET] <void09> so as expected, h264 padding [20:13:12 CET] <void09> how to get rid of it with ffmpeg? [20:14:04 CET] <JEEB> I think there was a bit stream filter that let you filter out NAL units of specific type [20:14:32 CET] <JEEB> ah [20:14:56 CET] <JEEB> -bsf:v h264_metadata=delete_filler [20:14:58 CET] <JEEB> that might do it [20:15:04 CET] <JEEB> since that option says > Deletes both filler NAL units and filler SEI messages. [20:15:08 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#h264_005fmetadata [20:16:35 CET] <void09> Undefined constant or missing '(' in 'delete_filler' [20:16:48 CET] <void09> -bsf:v h264_metadata=delete_filler -vcodec copy -acodec copy outputvideo.mkv [20:17:38 CET] <JEEB> try adding =1 at the end? [20:18:42 CET] <void09> that did the trick : ) thanks [20:19:15 CET] <void09> mkvtoolnix still wins by about 1.5MB though [20:19:26 CET] <void09> well, certainly better than 4GB :P [20:20:36 CET] <JEEB> probably the duplicated parameter sets [20:21:08 CET] <JEEB> try h264_redundant_pps,h264_metadata=delete_filler=1 ? [20:21:40 CET] <JEEB> ah no, [20:21:53 CET] <JEEB> extract_extradata,h264_metadata=delete_filler=1 [20:22:07 CET] <JEEB> or the other way so that the extract_extradata thing gets cleaner input? [20:22:18 CET] <JEEB> asdf, forgot the remove=1 [20:22:19 CET] <JEEB> option [20:22:20 CET] <JEEB> :) [20:22:39 CET] <JEEB> h264_metadata=delete_filler=1,extract_extradata=remove=1 [20:23:04 CET] <JEEB> remove filler, extract and remove parameter sets etc from in-band [20:24:25 CET] <JEEB> (broadcast needs to push that with each random access point) [20:25:02 CET] <JEEB> (while in matroska/mp4 you can have it in a single place if you're not planning on streaming it in a way where you lack the spot where you wrote it once) [20:34:33 CET] <void09> ok will try [20:35:54 CET] <JEEB> &41 [20:37:17 CET] <void09> hm ? [20:37:48 CET] <JEEB> typo of /41 :P [21:49:15 CET] <deadbeef84> Hi, I'm trying to extract part of an HLS stream using this command: "ffmpeg -ss 30 -i stream.m3u8 out.mp4" However no frames are extracted. My test file can be generated with this command: "ffmpeg -f lavfi -i "testsrc=duration=60" -hls_time 10 -hls_list_size 10 -hls_playlist_type event -hls_segment_type fmp4 stream.m3u8". Is this a known limitation of the hls-demuxer? Anyone in here willing to help me [21:49:21 CET] <deadbeef84> out? [21:50:44 CET] <void09> what does -ss 30 mean ? [21:52:47 CET] <JEEB> seek to 30s [21:55:03 CET] <deadbeef84> Just found this ticket which seems relevant https://trac.ffmpeg.org/ticket/7359 [22:08:51 CET] <void09> JEEB: I want to ask you whhile you're still around, got any idea why I am getting this message for every single frame, when doing "ffmpeg -i "outputvide.mkv" -ss 00:15:37.651 -to 01:45:05.331 -vcodec copy -acodec copy outputvideo2.mkv" (outputvideo.mkv being the .ts tv cap that i first converted to mkv) [22:08:57 CET] <void09> Non-monotonous DTS in output stream 0:0; previous: 5367520, current: 5367500; changing to 5367520. This may result in incorrect timestamps in the output file. [22:09:21 CET] <void09> when cutting to mkv directly from the .ts I do not get this message spam [22:09:56 CET] <JEEB> seems like timestamps got derped (most likely during the TS->matroska remux) [22:10:28 CET] <JEEB> although usually muxers complain if you went backwards in time... [22:10:37 CET] <JEEB> wonder if it's a reorder thing that got applied wrong [22:10:41 CET] <JEEB> (Ž4@) [22:11:11 CET] <JEEB> void09: also did the stripping of extraneous extradata (parameter sets) get it smaller? [22:16:07 CET] <void09> oh I forgot, let me check [22:20:04 CET] <void09> ffmpeg "input.ts" -bsf:v h264_metadata=delete_filler=1,extract_extradata=remove=1 outputvideo3.mkv [22:20:12 CET] <void09> well this is slow, 3x vs 200x before [22:20:42 CET] <JEEB> ouch [22:20:42 CET] <void09> * ffmpeg -i "input.ts" -bsf:v h264_metadata=delete_filler=1,extract_extradata=remove=1 outputvideo3.mkv [22:21:31 CET] <void09> not sure if that's what caused the mkv to be smaller.. going to take a while to find out now :) [22:21:54 CET] <void09> smaller for mkvtoolnix, which did it very fast, 30 seconds for 10GB or so [22:24:37 CET] <void09> jeeb just tried to run the command that produced the monotonous timestamp errors, but using the mkvtoolnix produced mkv instead of the ffmpeg one as input. no errors this time [22:24:37 CET] <JEEB> that's a pretty creepy slowness [22:24:55 CET] <JEEB> yup [22:25:02 CET] <void09> there must be some esoteric flag somewhere i can use to fix this i bet :D [22:25:17 CET] <JEEB> I've had issues with remuxing mpeg-ts (and probably raw H.264) [22:25:19 CET] <void09> mkvtoolnix seems to have great defaults [22:25:31 CET] <JEEB> that's not defaults, that's just timestamp handling [22:25:47 CET] <void09> default timestamp handling then :P [22:25:56 CET] <JEEB> you shouldn't need any other timestamp handling [22:26:17 CET] <JEEB> if the stuff you push out only becomes OK after you've fed it through a decoder, that's a boog [22:26:28 CET] <JEEB> unfortunately I have not had the time to look into it [22:26:51 CET] <void09> you should, this is very important :P [22:27:10 CET] <JEEB> 1) I need to figure out a sample (because most I've seen be OK?) [22:27:20 CET] <JEEB> 2) it has to be a point where I'm not busy with something [22:27:45 CET] <JEEB> if you have a sample there and can dd a few dozen megabytes off of it and the problem happens within that, that'd be great to have :P [22:28:05 CET] <JEEB> dd bs=1M count=20 if=blah.ts of=blah_cut.ts [22:28:06 CET] <void09> oh so this should not happen with all ts files ? [22:28:10 CET] <JEEB> yea [22:28:29 CET] <JEEB> depends on how it was created and what's the H.264 stuff inside it (or mpeg-2 video, or mpeg-4 video) [22:28:36 CET] <JEEB> (yes I have actually seen the last one in a system) [22:29:00 CET] <JEEB> was quite the "wait what are they really using MPEG-4 Part 2 here?!" [22:29:28 CET] <void09> here you go: https://www55.zippyshare.com/v/leOjaEBL/file.html [22:29:31 CET] <JEEB> not even the studio profile stuff which si 4:4:4 [22:29:51 CET] <JEEB> void09: I may recommend 0x0.st to which you can push with just curl and I think -F or so? [22:29:56 CET] <montana> what happened to .avi container? why don't i see anymore [22:30:01 CET] <montana> it was popular before [22:30:10 CET] <JEEB> it didn't support required things for modern formats [22:30:16 CET] <JEEB> and there were better ones even in the 1990s [22:30:34 CET] <void09> here you go again: http://0x0.st/zI-G.ts [22:30:43 CET] <montana> jeeb which was? [22:31:20 CET] <JEEB> void09: thanks [22:31:42 CET] <JEEB> void09: and that cut file also has the same issue? [22:31:45 CET] <JEEB> if you remux it [22:31:55 CET] <void09> well I did not try that, let's see [22:32:04 CET] <JEEB> it most likely has [22:32:36 CET] <void09> hm simple remuxing with no seeking produces no errors [22:32:52 CET] <JEEB> you probably need to mux into something with proper timestamps first [22:32:54 CET] <void09> well except these which I get pretty much every time: [matroska @ 0x56372ca6f500] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly [22:32:55 CET] <void09> [mpegts @ 0x56372c323280] PES packet size mismatch [22:32:57 CET] <JEEB> then try to remux that [22:33:13 CET] <void09> oh right I forgot, need to .mkv it with ffmpeg then cut it [22:33:42 CET] <void09> fmpeg -i "blah_cut.mkv" -vcodec copy -acodec copy blah_cut2.mkv [22:33:45 CET] <JEEB> but yes, unset timestamps sounds like problems :) [22:33:47 CET] <void09> [matroska @ 0x561079f726c0] Non-monotonous DTS in output stream 0:0; previous: 29611, current: 29591; changing to 29611. This may result in incorrect timestamps in the output file. [22:33:51 CET] <JEEB> yup [22:33:52 CET] <JEEB> thanks [22:34:46 CET] <JEEB> montana: in the 1990s? MPEG-TS and MOV as two? first one is still utilized for A->B streaming use cases, and mov later became mp4 (and matroska was designed in various ways based on it) [22:35:12 CET] <JEEB> the only reason to use AVI was that it was easily'ish understandable, and there were simple enough interfaces for it on windows [22:35:18 CET] <JEEB> (VFW etc) [22:44:37 CET] <void09> you looking into it JEEB or did I miss something ? [22:45:24 CET] <JEEB> void09: I won't do it now, but possibly during the week-end. I've got some other things I'm hoping to get done with regards to mpv too :) [22:45:36 CET] <void09> oh one more little thing. [22:45:43 CET] <JEEB> also I want to review some FFmpeg patches already lying on the mailing list [22:45:45 CET] <JEEB> :P [22:45:53 CET] <void09> why would I get a 0.560 timestamp at the beginning of the video when opening a cut file in mpv ? [22:46:24 CET] <void09> My logic says it should begin at 0 sharp :P [22:46:27 CET] <JEEB> depending on how streams match up the start of the clip might not be zero [22:46:41 CET] <void09> yes but half a second ? [22:46:54 CET] <JEEB> go look at the timestamps with ffprobe or something :P [22:46:55 CET] <void09> i mean first frame is 40ms [22:47:12 CET] <JEEB> I think the best example of this are mp4 files with edit lists to cut off stuff [22:47:34 CET] <JEEB> like when you cut on not exactly a random access point in your input, and then the nice mp4 writer adjust the edit list :P [22:47:41 CET] <void09> JEEB: I do this with the resulting cut files, I skip the extra frames I get by using mkv chapter with mkvtoolnix [22:47:58 CET] <void09> RAP, indeed [22:48:27 CET] <JEEB> anyways, I don't have a magical eight-ball unfortunately so I can't tell you /why/ in your specific case :P [22:48:34 CET] <void09> after applying the chapter mpv reports 0 as the starting timestamp [22:49:23 CET] <JEEB> instead of guesstimating, please just look at the timestamps of that file [22:49:43 CET] <void09> hmm I'll have to google on that [22:49:46 CET] <JEEB> also remember that adding chapters generally tends to also be part of a full remux so what exactly mkvtoolnix does there I' 100% not sure [22:50:09 CET] <JEEB> for matroska you can either -show_packets with ffprobe and -of json (to get something nicely parse'able), or you can use mkvinfo [22:50:25 CET] <void09> I'm adding the chapters myself manually, by watching the exact timestamps of the frames in mpv (with < > keys) [22:50:40 CET] <JEEB> yes but I mean you can't /expect/ an application to not touch the file at all otherwise [22:50:44 CET] <JEEB> when you add the chapters [22:50:48 CET] <JEEB> it /might/ be nice like that [22:50:51 CET] <JEEB> but always verify [22:51:10 CET] <JEEB> but yea, look at the timestamps of the first 20 packets or whatever [22:51:20 CET] <JEEB> preferably both of the primary streams (a/v) [22:51:29 CET] <JEEB> you should then see whatever the fuck you're seeing in there [22:51:47 CET] <void09> mkvinfo outputvide11.mkv [22:51:47 CET] <void09> (MKVInfo) Error: Couldn't open source file outputvide11.mkv (open file error). [22:52:29 CET] <void09> ah nvm, i missed an o [22:52:45 CET] <JEEB> there's an option you pass to mkvinfo if I recall correctly to get the list of timestamps of each packet [22:52:55 CET] <JEEB> (and stuff like the RAP flag etc) [22:53:54 CET] <JEEB> could have been just the -v option to raise verbosity [22:54:07 CET] <JEEB> it will print quite a lot of stuff but you should get a grasp of the timestamps [22:54:21 CET] <void09> Cluster [22:54:21 CET] <void09> | + Cluster timestamp: 00:00:00.001000000 [22:54:21 CET] <void09> | + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:00.001000000 [22:54:21 CET] <void09> | + Frame with size 686 [22:54:21 CET] <void09> | + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:00.022000000 [22:54:45 CET] <void09> oh that's the audio [22:54:58 CET] <void09> Cluster [22:54:58 CET] <void09> | + Cluster timestamp: 00:00:00.001000000 [22:54:58 CET] <void09> | + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:00.001000000 [22:54:58 CET] <void09> | + Frame with size 686 [22:54:58 CET] <void09> | + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:00.022000000 [22:55:03 CET] <void09> there we go, the .460 [22:55:16 CET] <JEEB> sounds like you pasted the wrong stuff :P [22:55:20 CET] <void09> wait no [22:55:21 CET] <JEEB> also recommending pastebin or 0x0.st [22:55:25 CET] <void09> |+ Cluster [22:55:25 CET] <void09> | + Cluster timestamp: 00:00:00.448000000 [22:55:25 CET] <void09> | + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:00.448000000 [22:55:25 CET] <void09> | + Frame with size 679 [22:55:25 CET] <void09> | + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.460000000 [22:55:28 CET] <void09> last one, promise :D [22:56:37 CET] <JEEB> sounds like you only encountered a valid video packet in your input after encountering some valid audio packets [22:56:44 CET] <void09> seems this video is actually 50fps interlaced, not 25, [22:56:52 CET] <JEEB> probably some could have been dropped but ffmpeg.c just takes it all [22:57:01 CET] <JEEB> after seeking that is [22:57:36 CET] <JEEB> sp of that cluster is the first one with a video packet, it just means you had audio come before it [22:57:39 CET] <JEEB> :P [22:58:31 CET] <JEEB> when re-encoding you often get ffmpeg.c duplicating the first frame according to some guesstimated frame rate [22:58:31 CET] <void09> right, and the chapter resets it to 0 [22:58:50 CET] <JEEB> so you kind of get the two closer to each other [22:59:07 CET] <JEEB> (often happens when starting off broadcast MPEG-TS since you most likely do not hit a RAP) [22:59:24 CET] <JEEB> so your audio streams will start getting valid packets first [22:59:49 CET] <JEEB> although with the newfangled audio formats people decided they wanted groups of packets and RAPs as well [23:00:01 CET] <JEEB> not sure how much that helps them [23:00:40 CET] <void09> well this happens after cutting with ffmpeg, so it has nothing to do with mpeg-ts but the way ffmpeg logic works when cutting [23:00:55 CET] <void09> not sure how often spaced is the RAP for AAC audio [23:01:05 CET] <JEEB> AAC and those older formats are all RAP [23:01:09 CET] <JEEB> all packets can be decoded [23:01:52 CET] <JEEB> void09: it has to do with a mish-mash of things. mpeg-ts seek is not exact due to no index, blah blah [23:02:03 CET] <JEEB> just saying it's probably not as simple as you make it out :P [23:02:08 CET] <JEEB> and not just the cutting part [23:02:19 CET] <void09> who would have thought it's such a rocket science to cut a file :\ [23:02:21 CET] <void09> properly [23:02:28 CET] <JEEB> welcome to containers designed for A->B [23:02:48 CET] <JEEB> and it 100% based on the amount of effort the author of the mpeg-ts reader wanted to put into seeking [23:02:56 CET] <void09> well, welcome to ffmpeg not caring about frame exact decoding ? :) [23:02:57 CET] <JEEB> which I'm not surprised is not too much since you have to index to properly seek [23:03:00 CET] <void09> seeking* [23:03:15 CET] <JEEB> yes, that is not a primary use case nor something FFmpeg's primary APIs promise you will get [23:03:26 CET] <JEEB> since FFmpeg's APIs are also supporting A->B [23:03:33 CET] <JEEB> where you have no such thing as a file [23:03:35 CET] <JEEB> for example [23:03:44 CET] <void09> tv recordings processing is not a primary use case? [23:04:01 CET] <JEEB> processing that requires full indexing [23:04:02 CET] <JEEB> is not [23:04:18 CET] <JEEB> and I don't say that this isn't a thing that people don't do [23:04:29 CET] <JEEB> after all, that is why we have ffms2 :P [23:04:39 CET] <JEEB> which of course does not help you since it is for /decoding/ [23:05:26 CET] <JEEB> void09: if you look at things like murdoc cutter, dgindex etc, which are for handling MPEG-TS, all of them pre-index and take a while to do that [23:05:41 CET] <JEEB> they can take that luxury since that is their only use case [23:05:47 CET] <JEEB> they're not gonna get a live stream from UDP [23:05:51 CET] <JEEB> or a TV receiver [23:06:02 CET] <JEEB> this of course doesn't mean that FFmpeg's base APIs couldn't have such a thing [23:06:09 CET] <void09> well it's not such a big deal to decode 10gb h264 on a modern computer [23:06:12 CET] <JEEB> but it most likely wouldn't be the default for such things [23:06:40 CET] <JEEB> I'm basically just trying to explain why your specific use case is not there yet :P [23:06:53 CET] <void09> It should be though. It's sooo basic :) [23:07:15 CET] <JEEB> uh-huh [23:07:49 CET] <JEEB> now time to decide whether you want that feature generally in the libavformat library, or is it gonna be a thing specific to MPEG-TS seeking? [23:08:11 CET] <JEEB> (architecturally since there's multiple non-indexed containers it would be the first one) [23:08:31 CET] <JEEB> and now suddenly you need to design, figure it out and code it [23:09:32 CET] <JEEB> anyways, not saying it's an unneeded feature since you have ffms2 etc which are providing indexed decoding etc for such things like aegisub/avisynth/vapoursynth [23:09:58 CET] <JEEB> but unfortunately it is also much simpler to handle it in its own application/library that specifically serves such a need [23:10:09 CET] <JEEB> since you don't need to give a flying mcdongle about any other use cases [23:10:19 CET] <JEEB> which you'd have to do if you'd add the feature into lavf [23:11:11 CET] <JEEB> anyways I hope you understand the other reason in addition to developer priorities (aka "what hurts their leg" or "what they fancy") why the feature is not there :P [23:12:20 CET] <JEEB> like, if this was a job I'd get a list of crap that needs to be done based on who pays and what and how much business it could bring. in my case, it's what I happen to give a damn about. and I think that's often the case. [23:13:15 CET] <void09> Makes perfect sense. Yet I am amazed how many things you can do with ffmpeg.. and you can'd do this :D [23:13:31 CET] <void09> well, you can, just not bit perfect I guess [23:13:31 CET] <JEEB> you can do what you want /with/ FFmpeg [23:13:41 CET] <JEEB> as in, if you make an application that uses the APIs and indexes [23:13:43 CET] <void09> yeah yeah API vs cli tool [23:13:48 CET] <JEEB> you can do the same thing as ffms2 [23:13:48 CET] <void09> I know I know :D [23:13:55 CET] <JEEB> just not decode, but do packet copying [23:14:00 CET] <JEEB> ffmpeg.c is ffmpeg.c [23:14:06 CET] <JEEB> it's trying to be a jack of all trades [23:14:18 CET] <JEEB> you can get scary far with it [23:15:26 CET] <JEEB> also for the reference, the only productive thing I did during the last 24h in open source was to review a pull requst :P [23:15:29 CET] <JEEB> https://github.com/mpv-player/mpv/pull/7176 [23:17:32 CET] <void09> mpv is nice [23:17:42 CET] <void09> but I never got it to display dvd/bluray menus properly [23:17:50 CET] <void09> I mean, to get their interactiveness [23:18:19 CET] <void09> No idea if it just can't do it right or I am missing some compile options [23:18:28 CET] <furq> didn't they drop dvdnav support [23:19:07 CET] <furq> DVD menus are not supported. [23:19:08 CET] <furq> close enough [23:20:41 CET] <void09> huh, strange [23:32:36 CET] <JEEB> void09: basically since nobody wanted to maintain the stuff it was removed. [23:32:52 CET] <JEEB> effectively VLC is the only one which actually has someone maintaining that stuff [23:33:00 CET] <void09> JEEB: :O [23:33:16 CET] <void09> the stripping run finished and i can't belive this [23:33:39 CET] <void09> cut video is 5.1GB [23:33:54 CET] <void09> cut/remuxed with ffmpeg/mkvtoolnix normally [23:34:12 CET] <void09> on this tv station it seems there's no h264 padding or not significant [23:34:13 CET] <void09> buuut [23:34:58 CET] <void09> the filler and extradata line i added in ffmpeg, produced a 3.1GB MKV file [23:35:12 CET] <void09> from which I still have to cut 30 minutes soi can compare with the 5.1GB one [23:35:13 CET] <void09> WTF [23:35:30 CET] <void09> 3.1 GB is uncut [23:35:44 CET] <void09> from 7.4GB input [23:35:46 CET] <JEEB> just make sure you actually were doing copy codec for video? [23:36:03 CET] <void09> lol you think I did an encode ? :D [23:36:15 CET] <void09> lol I did [23:36:17 CET] <JEEB> just saying it's worth a double-check [23:36:20 CET] <void09> that's why it was so slow [23:36:23 CET] <JEEB> also would explain the slowness [23:36:24 CET] <JEEB> yup [23:36:28 CET] <void09> facepalm [23:39:31 CET] <void09> ok. mkvtoolnix still 3MB smaller even with the metadata strip [23:50:42 CET] <JEEB> can just be a difference of what things it writes as far as the matroska container goes [23:51:00 CET] <JEEB> you could look into it more, but :eff: [00:00:00 CET] --- Sat Nov 23 2019

1 0

ffmpeg-devel.log.20191121
by burek 22 Nov '19

22 Nov '19

[03:03:14 CET] <j-b> thardin: VLC does not have a MXF demuxer (yet) [04:58:46 CET] <mkver> pkt->duration == 0 means "unknown duration"; for subtitles this usually means "display until the next subtitle", but in the past, IIRC a negative duration was also used for this purpose. Is this really a thing of the past or does a muxer still need to check for this? [05:37:27 CET] <byte_> Hi [05:38:03 CET] <byte_> I want to create custom filter in ffmpeg [09:54:59 CET] <mkver> cehoyos: Do you have a sample for which 7a5356c7281d39ee168bfa984ae081969e47da27 fixed HEVC-remuxing from mpeg-ts to Matroska? I am asking because of ticket 8042: Here the fact that the mp4 muxer doesn't check the return value led to the creation of an invalid file (it was annexb in mp4). [10:05:25 CET] <cehoyos> I was under the impression that any file would allow to reproduce the issue this commit fixed: Am I wrong? [10:44:52 CET] <mkver> I have found a file where your commit made it possible to mux; the created file has no extradata and is in annexb, which is against the specifications. This is actually not surprising: ff_isom_write_hvcc only starts writing anything after it has checked that everything is ok. But current ffmpeg can handle this just fine, it finds extradata. Probably the introduction of extract_extradata_bsf fixed this. [10:49:59 CET] <cehoyos> That the bsf fixed something makes sense to me. [10:50:27 CET] <cehoyos> Note that at the time of the commit, nobody could say if the output was against the specification or not. [10:54:06 CET] <mkver> Why not? [10:54:36 CET] <cehoyos> I don't know, I asked and nobody answered. [11:23:11 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:8e2a832a5521: avfilter/vf_median: clip radius instead of erroring out [11:52:43 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:84e9a55d8ed7: avfilter/af_afftdn: simplify changing commands [12:09:54 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:fbcb141c06a7: avfilter/vf_fillborders: add support for commands [12:26:25 CET] <thardin> j-b: I'd use bmx instead of lavf tbh [12:26:50 CET] <durandal_1707> ban him ^ [12:26:53 CET] <thardin> I believe I'm on-record on the mailing list as being opposed to even having our own demuxer for mxf [12:27:03 CET] <durandal_1707> ban him ^ [12:27:25 CET] <thardin> witch! [12:28:48 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:9bd4df16542b: avfilter/vf_chromashift: add support for commands [12:29:10 CET] <thardin> over the years I've learned that pointing out NIH is heresy [12:29:51 CET] <durandal_1707> bmx is crap, and it does not support all what lavf supports [12:30:10 CET] <kierank> sure but it does a lot of stuff that lavf cannot [12:30:26 CET] <thardin> /ignore durandal_1707 [12:30:33 CET] <durandal_1707> cite something sensible [12:31:15 CET] <nevcairiel> the concept of "one thing that does everything" is often how bad things are born, targeted tools that do one thing well, like handling a crazy format like mxf, are fine [12:31:45 CET] <durandal_1707> but bmx does not handle all mxf stuff that lavf can [12:31:52 CET] <thardin> such as? [12:31:57 CET] <durandal_1707> everything [12:32:03 CET] <durandal_1707> prores [12:32:17 CET] <thardin> oh wow adding a codec ul. really hard [12:32:44 CET] <durandal_1707> go hide under a rock [12:35:07 CET] <j-b> thardin: yes, this was the question [12:35:17 CET] <j-b> thardin: bmx seems nice [12:35:21 CET] <j-b> and there was a vlc plugin [12:35:39 CET] <thardin> neat [12:35:52 CET] <thardin> I suspect vlc is better architectured to handle the higher operational patterns [12:35:52 CET] <j-b> but testing lavf vs bmx for MXF is difficult, because of the number of versions of MXF there is [12:36:04 CET] <thardin> like OP3a [12:36:13 CET] <j-b> and things like linked-files [12:36:14 CET] <thardin> ffmpeg sure isn't [12:36:32 CET] <j-b> we have our own DCP plugin [12:36:34 CET] <thardin> yeah no, external files you need a middleware for [12:36:47 CET] <j-b> vlc can support external files, without issues [12:36:53 CET] <thardin> yeah but you need like [12:36:57 CET] <j-b> I think this is hard from within lavf [12:36:58 CET] <thardin> an entire MAM [12:37:55 CET] <thardin> a MAM would keep track of every MXF file by UUID, so that you can open them when referenced by another MXF [12:38:15 CET] <thardin> or by an AAF [12:38:20 CET] <j-b> sure [12:38:27 CET] <j-b> but we have that for MKV already [12:38:39 CET] <j-b> and you look in the same folder [12:39:17 CET] <j-b> anyway, my knowledge of MXF is too light [12:40:31 CET] <j-b> but with the support of TC (DF and NDF) in VLC 4, I fear I need to know more [12:40:43 CET] <thardin> timecode? [12:41:49 CET] <j-b> yes [12:41:59 CET] <thardin> fun [12:42:00 CET] <j-b> HH:MM:SS;FF [12:42:08 CET] <j-b> and other crap that profesional like [12:42:18 CET] <thardin> don't forget skip frame timecodes [12:42:22 CET] <j-b> yes [12:42:25 CET] <j-b> DF [12:42:36 CET] <j-b> supported [12:42:45 CET] <thardin> ah. it's been a while so I'm not 100% up to snuff [12:43:37 CET] <thardin> speed is perhaps the word [12:44:04 CET] <j-b> Drop Frame and Non-Drop-Frame [12:44:21 CET] <thardin> right, thanks [12:45:34 CET] <thardin> hum, ffmpeg only obeys st->start_time for subtitles? [13:00:06 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:f89ebf88a1d1: avfilter/vf_scroll: add support for slice threading [13:10:41 CET] <JEEB> cehoyos: cheers for grabbing the MPEG-H Audio sample [13:10:47 CET] <JEEB> too bad we don't have the decoder :< [13:10:51 CET] <JEEB> or well, a decoder [13:12:57 CET] <JEEB> j-b: linking as such is not hard, it's just that people seem to be opposed to opening files although I'm not sure if it was regarding file names or scanning the `pwd` for a file with matching UUID (latter is what matroska does) [13:13:16 CET] <JEEB> although I might have spotted support for file references in lavf's mov/mp4 demuxer [13:16:33 CET] <durandal_1707> job sucks [13:21:32 CET] <thardin> JEEB: yes, MOV has filenames for references, so mov.c opens those [13:24:10 CET] <JEEB> thardin: so the problem was just with scanning files for UUIDs I guess [13:24:34 CET] <durandal_1707> yes, you need to scan one million files in directory [13:24:53 CET] <thardin> you might get away with looking at just the current directory non-recursively [13:24:58 CET] <thardin> for files that end in .mxf or .MXF [13:25:05 CET] <JEEB> yea, same for matroska [13:25:21 CET] <JEEB> I think the original reasons why segment linking didn't hit was due to some security reasonings [13:25:25 CET] <JEEB> but I'm not sure if those hold any more [13:25:27 CET] <thardin> maybe an option for having it search recursively [13:25:31 CET] <thardin> or not search at all [13:25:38 CET] <durandal_1707> i have million of anime porn in .mkv in same directory [13:25:41 CET] <JEEB> yes, definitely should be controllable [13:25:51 CET] <thardin> maybe default to no searching, then ask the user if a file has references [13:26:11 CET] <BtbN> What kind of broken design even is that, to reference another file by some of its contents? [13:26:26 CET] <thardin> it's the broadcast way [13:26:51 CET] <thardin> what you actually do is query a database [13:27:05 CET] <thardin> that is, you ask your MAM [13:27:07 CET] <JEEB> durandal_1707: I only have dozens but it's a Very Valid Point. that said others have already come up with the default of nonrecursive search by default, and then tick that lets you not go through that [13:31:28 CET] <cehoyos> JEEB: Too bad the Sony guy apparently wanted to meet us;-( [13:32:07 CET] <JEEB> aye [13:34:03 CET] <durandal_1707> he wanted to give decoder code [13:35:27 CET] <JEEB> unlikely [13:35:45 CET] <JEEB> I think the interest in MPEG-H Audio is due to the broadcasters playing with it [13:36:09 CET] <JEEB> and since they have their own proprietary decoders they mostly care about getting demux out of FFmpeg [13:36:41 CET] <JEEB> I just hope that if it gets utilized, there would be work on getting an OSS decoder out there [13:37:09 CET] <durandal_1707> isn't there open available specs? [13:37:29 CET] <JEEB> yes, but they're ISO payware unless you find the final drafts [13:37:44 CET] <JEEB> even the MPEG-H Audio in MP4 spec is not free >:| [13:37:53 CET] <JEEB> like 14496-15 [13:38:01 CET] <JEEB> I don't fully understand the reasoning for making them not free [13:41:29 CET] <JEEB> ah, actually [13:41:29 CET] <JEEB> I wonder [13:41:30 CET] <JEEB> https://mpeg.chiariglione.org/standards/mpeg-h/3d-audio/text-isoiec-23008-3… [13:41:33 CET] <JEEB> if this is the last draft [13:41:48 CET] <JEEB> since the sony guy links https://www.iso.org/standard/69561.html [13:44:01 CET] <JEEB> at least it has no ref to mhm1 [13:45:20 CET] <JEEB> ah, ha! https://mpeg.chiariglione.org/standards/mpeg-h/3d-audio/n15847-thoughts-iso… [13:45:40 CET] <JEEB> this actually seems to contain the related parts [13:45:47 CET] <JEEB> mhm1 and mha1 [13:46:15 CET] <JEEB> > Especially in streaming or broadcast environments based on, e.g. MPEG-DASH or MPEG-H MMT, the MPEG-H 3D Audio configuration may change at arbitrary positions of the stream and not necessarily only on fragment boundaries. To enable this use-case the mhm1 and mhm2 MHASampleEntry provides an in-band configuration mechanism for MPEG-H 3D Audio files. [13:46:21 CET] <JEEB> why am I not surprised :D [13:48:01 CET] <JEEB> so the 'mha*' stuff was defined first and has the MHADecoderConfigurationRecord [13:48:19 CET] <JEEB> while 'mhm*' stuff puts the decoder config stuff in-band [13:50:33 CET] <JEEB> but yea, this means the sony guy's patch can not only be tested with samples but also compared to a reference :) [13:50:48 CET] <JEEB> (spec) [13:51:26 CET] <JEEB> I expect unless we want to put effort into it, we only want to support muxing with the mhm* codec tags if we want to support muxing it at all [13:51:40 CET] <JEEB> since that doesn't require implementing parsing the MPEG-H bit stream... I think? [13:51:48 CET] <JEEB> (and genreating the configuration box) [14:17:41 CET] <perseiver> Hello, [14:18:50 CET] <perseiver> I am new to ffmpeg and trying to use ffmpeg in my C code. [14:19:32 CET] <perseiver> I have written below code to find the AMR-NB parser using below code [14:19:34 CET] <perseiver> codec = avcodec_find_decoder(AV_CODEC_ID_AMR_NB); [14:19:34 CET] <perseiver> if(!codec) { [14:19:34 CET] <perseiver> fprintf(stderr, "Codec not found\n"); [14:19:34 CET] <perseiver> exit(1); [14:19:34 CET] <perseiver> } [14:19:36 CET] <perseiver> parser = av_parser_init(codec->id); [14:19:38 CET] <perseiver> if(!parser){ [14:19:40 CET] <perseiver> fprintf(stderr, "Parser not found\n"); [14:19:42 CET] <perseiver> exit(1); [14:19:44 CET] <perseiver> } [14:19:52 CET] <perseiver> But when I run program, I always getting "Parser not found" [14:20:54 CET] <perseiver> Do, I other codec like AV_CODEC_ID_MP2 found and I have no problem with this. What should I do, so that I can parse AMR file. [14:21:34 CET] <nevcairiel> not ever codec has a parser, and for using ffmpeg, you should ask in #ffmpeg [14:22:34 CET] <BtbN> And please don't spam the channel with code pastes. [14:23:10 CET] <perseiver> ok. thanks [14:23:32 CET] <jdarnley> There are 3 amr demuxers, so I assume you should be using one of those. [14:24:28 CET] <perseiver> yes, My build is already have this. I have look into source code of av_parser_init(), what I see is they matching the codec [14:24:47 CET] <perseiver> number upto 5 only. [14:25:13 CET] <perseiver> And I guess, this result me as "Parser not found" [14:26:04 CET] <perseiver> Or may be its third party library, i will have to find the parser in different way! [14:35:28 CET] <j-b> JEEB: linking is hard, because fopen-ing is hard. [14:53:52 CET] <thardin> hum, is it possible to change username on trac? [14:56:16 CET] <durandal_1707> no, keep username you already have [15:50:47 CET] <JEEB> j-b: true [15:50:51 CET] <JEEB> all the IO layers [15:59:05 CET] <durandal_1707> name all the IO layers: [17:01:58 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:08f7968fc408: avfilter/vf_lumakey: add support for 12bit yuva formats [17:01:59 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:6b9862f6145b: avfilter/vf_lumakey: change options to doubles, so that values are automatically scaled [17:02:00 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:ae6c4168e67c: avfilter/vf_lumakey: add support for commands [17:21:22 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:94c0b2739787: avfilter/vf_chromakey: add support for commands [17:24:54 CET] <j-b> JEEB: fopen on iOS, Android (with the new permission model), WinRT/UWP/Windows10X and so on... [17:25:01 CET] <j-b> sandboxing and such [17:32:31 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:09fd1b18f041: avfilter/vsrc_testsrc: simplify color filter commands parsing [17:40:51 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:d83304d5392e: avfilter/vsrc_sierpinski: fix another typos [17:40:52 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:c98d8b2bf56a: avfilter/vsrc_sierpinski: change seed option type [18:10:02 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:103effebc1f1: avfilter/vf_datascope: add support for commands in oscilloscope [18:36:25 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:55ca21d54e40: avfilter/vf_amplify: add timeline support [21:55:37 CET] <JEEB> j-b: best when you have no listings or file names available. just unique content uris [22:16:42 CET] <cone-417> ffmpeg 03leozhang 07master:4a3aa77d7437: avfilter/avfilter: fix indentation [22:16:42 CET] <cone-417> ffmpeg 03Zhao Zhili 07master:bbb68be0ccf4: avfilter/graphdump: fix use of uninitialized variables [23:40:57 CET] <cone-417> ffmpeg 03Paul B Mahol 07master:9cd56bb94c85: avfilter/af_aiir: fix array length when selecting conjugate poles [00:00:00 CET] --- Fri Nov 22 2019

1 0

ffmpeg.log.20191121
by burek 22 Nov '19

22 Nov '19

[00:00:33 CET] <Atlenohen> it ruins games as well, i mean it's the gaming community and industry that pushed for 60fps so you all got that, but 420 still a big issue [00:00:44 CET] <Atlenohen> chroma subsampling* [00:01:11 CET] <klaxa> isn't it mostly the color range and less the subsampling? [00:01:16 CET] <friendofafriend> I'm looking around for an example of someone using ffmpeg to stream h264 in an mp4 container to Icecast. mpeg4 in an mp4 container works fine, h264 in an MPEG-TS does too. [00:01:24 CET] <furq> subsampling sucks for games that have text on screen [00:01:26 CET] <furq> that's about it [00:01:29 CET] <klaxa> ah true [00:02:01 CET] <klaxa> well, it's not like having to encode sharp edges makes it any easier [00:03:30 CET] <GuiToris> does anyone have some good advice how I could make the video a little bit smaller? [00:03:44 CET] <GuiToris> is it because the source file is huge? [00:03:49 CET] <klaxa> higher crf, slower preset [00:03:49 CET] <GuiToris> ~100G [00:03:49 CET] <Atlenohen> Ah it's not just about text, it makes all the textures look like crap, and makes distant objects invisible [00:03:57 CET] <klaxa> that's about the knobs you can easily turn [00:03:58 CET] <GuiToris> klaxa, 29 and veryslow currently [00:04:12 CET] <GuiToris> +x265 [00:05:36 CET] <klaxa> also it depends on the information content of the input not it's size on disk [00:05:42 CET] <furq> 500MB for 22 minutes isn't that much [00:05:43 CET] <klaxa> what the output size will be [00:05:46 CET] <klaxa> that too [00:05:52 CET] <furq> i mean a film would be about 4x that length and 2GB would be very small [00:05:53 CET] <klaxa> in 1080p no less [00:06:25 CET] <klaxa> although i have seen files ranging in the 100-200 mb for 45 minutes shows in 720p, but there are a lot of artifacts [00:06:47 CET] <furq> i've seen that without artifacts but it's been prefiltered to hell [00:07:05 CET] <furq> GuiToris: maybe upload one of the pngs [00:11:33 CET] <GuiToris> furq, https://www.dropbox.com/s/9yfjp7iynr34meb/rcseq_21040.png?dl=0 [00:12:07 CET] <GuiToris> 30000/1001 framerate [00:13:58 CET] <GuiToris> x265 doesn't have much tune options so I didn't use any [00:16:16 CET] <GuiToris> https://bpaste.net/raw/TCVDA [00:21:59 CET] <GuiToris> furq, does it have the right file size? aren't there any more sane options? [00:22:51 CET] <GuiToris> I've also created one with crf 28 and it's 553mb big [00:23:41 CET] <GuiToris> since it takes ~40 hours to create a video, I haven't tried a lot [00:42:22 CET] <petecouture> Is it possible within ffmpeg to achieve ultra low latency fragmented mp4s for near live streaming quickly? I found this project that uses the ffmpeg libraries but I would like to keep it within my ffmpeg stack. https://github.com/horgh/videostreamer [00:42:51 CET] <petecouture> Goal being to achieve IP Camera to html5 playback. [00:43:17 CET] <BtbN> Any kind of fragmented stuff is always gonna have delay, or look horrible because of ultra short gops [00:43:40 CET] <petecouture> Ive been watching this demo for a while. http://umediaserver.net/umediaserver/demohtml5MSEplayer.html [00:44:07 CET] <petecouture> Not notices any major quality issues [00:44:23 CET] <BtbN> it's 99% static though [00:44:33 CET] <petecouture> Most IP cameras are [00:44:43 CET] <BtbN> and has at least several seconds long GOPs [00:44:45 CET] <petecouture> this is a security camera situation not a motion picture distrubition [00:45:35 CET] <BtbN> If less than 5~10 seconds of delay counts for your "ultra low latency", it's probably gonna be fine [00:45:39 CET] <petecouture> How can you tell? Its using websockets to tunnel the data into a MSE [00:46:03 CET] <petecouture> I could do that within HLS or something [00:46:07 CET] <BtbN> Because I highly doubt a webcam encoder would generate short GOPs [00:46:25 CET] <JEEB> BtbN: all of the low latency HLS/DASH things have moved to chunks that are fragments which don't start a GOP [00:46:36 CET] <JEEB> that way the GOPs can still be longer for compression [00:46:43 CET] <petecouture> ^ I was confused about him saying that. [00:46:56 CET] <BtbN> and you just see garbled stuff if you join at the wrong time? [00:47:15 CET] <BtbN> At least Twitch uses 2 second GOPs, which already hurt the quality quite a bit, and thus manage to get delay down to ~2 seconds. [00:47:17 CET] <JEEB> or nothing, or start at the closest GOP [00:47:29 CET] <petecouture> closest GOP was my experience [00:47:33 CET] <BtbN> But they do use 2 second long segments. [00:47:48 CET] <JEEB> Apple recommends 300ms chunks or so [00:47:51 CET] <petecouture> frags can go down to 30ms chucks [00:47:52 CET] <JEEB> with N second GOPs [00:47:52 CET] <petecouture> I thought [00:48:05 CET] <JEEB> fragmentation can be as often as you want [00:48:16 CET] <JEEB> so it depends on your frame rate if you fragment at each video sample f.ex. [00:48:17 CET] <BtbN> 30ms chunks sound stupid. Half of them will be empty [00:48:32 CET] <petecouture> I dont think web MSE can handle lower then 30ms [00:48:59 CET] <petecouture> JEEB: So no issues with fragmenting within FFMPEG? [00:49:03 CET] <BtbN> MSE does not care about that. YOU do that stuff. In JavaScript [00:49:09 CET] <BtbN> MSE just wants mp4 [00:49:31 CET] <JEEB> petecouture: nope? you can either send fragmentation signals through the API or utilize any of those fragmentation related APIs [00:49:37 CET] <BtbN> petecouture, you will have to write custom software for all this for sure. [00:49:44 CET] <BtbN> FFmpeg can't really output via a websocket [00:49:53 CET] <JEEB> s/APIs/AVOptions/ [00:50:00 CET] <petecouture> oh no [00:50:01 CET] <JEEB> websockets :s [00:50:06 CET] <petecouture> I m not thinking of it handling websockets. [00:50:12 CET] <petecouture> Ill pipe the frags my self [00:50:21 CET] <JEEB> because XHR cannot into continuous connections without growing buffers? [00:50:25 CET] <JEEB> which is sad :P [00:50:56 CET] <petecouture> Just wanted to know if ffmpeg can do it. I havent found any reference to a low latency RTSP to frag MP4 within FFMPEG only its source libraries [00:51:17 CET] <BtbN> you're always gonna get a few seconds of delay, so be aware of that. [00:51:24 CET] <BtbN> there's just too many buffers involved [00:51:29 CET] <petecouture> wat [00:51:47 CET] <petecouture> My understaing is this solution is < 1 sec [00:52:16 CET] <BtbN> If you really want near-realtime streaming, you will need custom software through the entire stack pretty much. FFmpeg is designed for reliability, not for zero latency. So there are buffers. [00:52:30 CET] <petecouture> gotcha thank you [00:52:30 CET] <BtbN> You can get it relatively low, but there is gonna be some buffers. [00:52:35 CET] <JEEB> quite a bit of those can be optimized but definitely not by default [00:52:45 CET] <JEEB> and if it's just remux and fragmentation with movenc [00:52:53 CET] <petecouture> That explains the source libraries being used [00:53:09 CET] <JEEB> well ffmpeg.c itself is also just an API client [00:53:12 CET] <BtbN> But really, what are you expecting that you care about 2~3 seconds of delay? [00:53:53 CET] <petecouture> I suppose I could push back on the < 1 requiremet [00:53:58 CET] <petecouture> since its not live chat [00:54:21 CET] <BtbN> The only thing that really needs this kind of zero latency is stuff like remote-gaming [00:54:27 CET] <BtbN> and even that fails horribly 99% of the time [00:54:53 CET] <petecouture> hah [00:56:30 CET] <petecouture> cool product says 2-3 second delay is fine [00:56:42 CET] <petecouture> Thank you guys! [01:50:47 CET] <friendofafriend> That videostreamer project is pretty neat. Couldn't you invoke ffmpeg from the command line to the same effect? [01:53:02 CET] <klaxa> i think you would need a webserver [01:54:29 CET] <klaxa> and some minimal html like in the repo [01:54:59 CET] <friendofafriend> I've been trying to do basically the same thing. I've got some h264 stream and I'd like it in an mp4 container to play with HTML5. [01:58:47 CET] <furq> friendofafriend: just use hls, it's less hassle [02:01:54 CET] <friendofafriend> furq: Lag seems a little long. I'm not worried about a few seconds, but 30 seems a bit much. [02:03:07 CET] <TheAMM> Neat, people talking about a thing that I'm implementing as well [02:03:34 CET] <TheAMM> Don't have much to comment on though, repo link was nice to see [02:04:19 CET] <friendofafriend> I'm not really sure why trying the "go get" line doesn't work. Wish there was a Makefile like normal. [02:04:24 CET] <TheAMM> I've got extra goals though and will de/mux NUT too which will be f u n [02:08:25 CET] <Retal> guys please remind me, i forgot how to list all available codecs for current build? [02:08:51 CET] <klaxa> ffmpeg -codecs ? [02:09:54 CET] <Retal> klaxa: yes!, thanks [02:11:32 CET] <klaxa> for more detailed information about a single encoder use ffmpeg -help encoder=something, e.g. ffmpeg -help encoder=libx264 [02:26:31 CET] <void09> found this command to check a file for erorrs. fmpeg -v error -i "outputvideo.mkv" -f null - 2>test.log ; but how can I make it so it shows the timestamps at which the errors are found and not 0xabc.. [05:59:11 CET] <drazil100> Does anyone know how to add an additional audio track to a video WITHOUT replacing any existing audio tracks [06:00:45 CET] <drazil100> specific use case is I have a movie that has 2 dubs and I would like to put both dubs in a single file [06:01:52 CET] <drazil100> I have REPLACED audio before but I have never added additional tracks [06:02:13 CET] <furq> drazil100: -map 0 -map 1:a [06:03:43 CET] <drazil100> what if the file has like multiple different tracks already [06:04:13 CET] <furq> https://www.ffmpeg.org/ffmpeg.html#Advanced-options [06:04:29 CET] <drazil100> thank you [06:04:55 CET] <drazil100> that helps a lot [06:17:25 CET] <drazil100> Additional question. [06:17:33 CET] <drazil100> how are these tracks named? [06:17:49 CET] <drazil100> is it just based on the file name? [06:18:13 CET] <void09> how can i find out the timestamp for this ? [h264 @ 0x557ff5a2da40] left block unavailable for requested intra4x4 mode -1 [06:21:48 CET] <furq> drazil100: how do you mean named [06:22:04 CET] <furq> if you mean which file 0 refers to then it's the order you provided them in [06:26:22 CET] <void09> furq please help, i've been googling for half an hour now :( [09:41:16 CET] <drazil100> What does it mean if it says "Starting new cluster due to timestamp" [09:42:41 CET] <drazil100> also most of the audio is muted [09:42:53 CET] <drazil100> in the output [09:44:33 CET] <drazil100> still trying to add an audio track to an existing video without overwriting existing audio [09:44:56 CET] <drazil100> but it keeps ending up muted [10:07:19 CET] <Weasel_> I am trying to get two different h264 rtsp streams from ip cam into mpeg-dash and hlv files for adaptive streaming, it is kind of working, but first input stream is always damaged. Is this supposed to work or am I trying the impossible? [10:08:09 CET] <Weasel_> hlv=hls [10:12:50 CET] <BeerLover> I'm trying to convert a song into hls. I am using this: https://dpaste.de/VMMQ. What is wrong with the command? [10:25:25 CET] <cehoyos> What could be wrong with it? [10:25:31 CET] <cehoyos> (Complete, uncut console output missing.) [10:27:22 CET] <BeerLover> @cehoyos https://dpaste.de/bFRv [10:28:31 CET] <Weasel_> BeerLover: it sayt that dir 320k does not exist [10:28:36 CET] <BeerLover> i want to create 4 different bitrate hls playlist with master playlist [10:30:16 CET] <BeerLover> https://dpaste.de/WvYV this works but it creates 0/segment.. 1/segment... 2/segment... etc [10:30:36 CET] <BeerLover> Can i specify such that I get 320k/segment... 128k/segment... etc [10:30:42 CET] <BeerLover> folders based on bitrates [10:30:54 CET] <BeerLover> and master with those files [10:32:07 CET] <Weasel_> BeerLover: and you have created those dirs 320k, 128k, 64k and 32k? [10:32:21 CET] <BeerLover> no [10:32:43 CET] <Weasel_> why not? [10:33:26 CET] <BeerLover> If i use var_stream_map, it creates the directories if i give "%v/segment%d.ts" as hls_segment_filename [10:33:54 CET] <BeerLover> is there any way i can create 320k/ 128k/ etc [10:36:22 CET] <Weasel_> well, I don't know but in my experiments ffmpeg did not create directories, I had to use mkdir :) [10:36:29 CET] <BeerLover> k [10:36:34 CET] <BeerLover> one more question [10:36:49 CET] <BeerLover> The bitrate I specify and the bitrate in the output is a little off [10:38:01 CET] <BeerLover> I specified 128k and it's 143k [10:38:59 CET] <BeerLover> Codec AVOption b (set bitrate (in bits/s)) specified for output file #1 (128k/index.m3u8) has not been used for any stream. The most likely reason is either w [10:39:00 CET] <BeerLover> rong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream. [10:47:25 CET] <Weasel_> I think you should propably do some encoding with those bitrates so they would be put into those files, your source seems to be ~130k and maybe it was copied straight into your 128k output [10:54:42 CET] <BeerLover> Weasel_ here is the output log for a file with 1411kb/s [10:55:57 CET] <BeerLover> 2 issues that i have are: 1) I need folder structure with <bitrate>/segment. If i do it manually, I have to edit the master.m3u8 also manually and update references. 2) the bitrates are different [11:11:57 CET] <BeerLover> Solved the 1st issue [11:12:36 CET] <BeerLover> used names in variant streams [11:12:45 CET] <BeerLover> but the bitrate problem persists [11:13:05 CET] <BeerLover> I tried using -c:a aac -b:a:0 320k [11:13:30 CET] <BeerLover> but the output is 287k [11:14:44 CET] <cehoyos> Try to encode your input file standalone to find out what the issu eis [11:14:56 CET] <cehoyos> (it could be the silent input cannot reach a high bitrate) [11:30:47 CET] <pagios> good morning community, i am doing a mp4 extraction using index.m3u8 -live_start_index -10 -t 30 -c copy -bsf:a aac_adtstoasc test.mp4 it works well but it is SLOW, it takes 30seconds to give the output, is there a way to make it faster to get the mp4? Thank you [11:46:26 CET] <pagios> will -preset ultrafast apply? [11:47:05 CET] <pagios> i see the problem is in opening the .ts files [11:49:29 CET] <squ> doesn't apply with copy [11:50:07 CET] <Weasel_> pagios: -probesize 32 ? [11:50:11 CET] <cehoyos> pagios: Complete, uncut console output missing. [11:54:32 CET] <Weasel_> can't be, that -probesize 32 solved my corrupt stream problem, I had previously used if with ffplay only [12:22:24 CET] <pagios> Weasel_, same speed [12:27:04 CET] <pagios> cehoyos, https://pastebin.com/krXZ7Ya0 Weasel_ each of these lines takes around 1second to finish, that is what is making it slow, any way to read faster? [12:47:04 CET] <cehoyos> Sorry for being unclear above: I am only able to parse command line including complete, uncut console output, not excerpts. [13:05:13 CET] <Anderssen> Another topic: what would be the correct output format for dvb-teletext if I want plain text? Apparently "txt" is not a valid option, but now I've tried this line: ffmpeg -txt_format text -txt_page 100 -i Star\ Trek.m2t -map 0:0 -c:s mov_text -t 60 -y -v verbose out.mp4 . Indeed it seems to output the teletext page (see https://pastebin.com/Da8juWE4 ), but obviously .mp4 is the wrong format. [13:08:39 CET] <c_14> you probably want srt or ass [13:08:44 CET] <c_14> those are text with timing/styling info [13:09:59 CET] <c_14> though my ffmpeg is listing a "text" encoder for subtitles [13:10:05 CET] <Anderssen> c_14: I think srt is limited to subtitles; I'm rather interested in teletext in general. [13:14:07 CET] <JEEB> if you use the ASS output it will output as text subtitles *all* of the pages that are decoded if you tell the decoder to decode all pages [13:16:36 CET] <BeerLover> @cehoyos Can you elaborate? [13:19:17 CET] <Anderssen> JEEB: would I do that with "-f ass" ? If I add that to the line above I get the error "Exactly one ASS/SSA stream is needed". However, do you mean when I output "as text subtitles" it would treat "regular" (i.e. non subtitle pages) as subtitles? would it change the output format or so? [13:20:53 CET] <Anderssen> I'm not sure if I'm making much sense: I would like to preserve all teletext pages (if possible as plain text) [13:27:21 CET] <Anderssen> c_14, JEEB, I think I just composed the line wrong. I left out "-c:s mov_text" now and I just chose "out.srt" as outputfile, and it did the output as plaint text. thanks! [13:29:16 CET] <cehoyos> BeerLover: You provided a complicated command line that produces several outputs - if you have a problem with audio encoding, test with one input and one output file and see if the issue is reproducible. [13:29:43 CET] <BeerLover> k [13:29:45 CET] <cehoyos> Anderssen: You cannot preserve teletext using subtitles [13:30:10 CET] <Anderssen> you mean using srt? it ouputs plain text though [13:30:42 CET] <cehoyos> If you want to preserve teletext (why??), put the teletext in a transport stream, I suspect this is the only container that accepts it. [13:33:14 CET] <JEEB> you can either get it out as bitmap or ass, which might be "good enough" for your use case [13:33:28 CET] <BeerLover> @cehoyos I tried with one map and 1 var stream [13:33:36 CET] <BeerLover> still bitrate is less in the output [13:33:44 CET] <JEEB> but of course if you want the actual teletext with *everything* as-is [13:33:49 CET] <JEEB> then you need the teletext stream [13:33:51 CET] <JEEB> as-is [13:39:31 CET] <Anderssen> cehoyos, JEEB: that's a possibility I thought about, but the teletext stream is somewhat repititive or redundand; it's more comfortable if I have one text file (or maybe an html file) where I can view the whole thing. [13:39:58 CET] <cehoyos> Then I believe you have already found a solution or not? [13:40:07 CET] <Anderssen> ceyohos: as to why: that's a long story; I like the information in there ;) [13:41:07 CET] <Anderssen> cehoyos: yes, unless of course there is a way to output in html or something (like alevt for example which produces html files which look like the original; that is with all the colors and so on) [13:41:50 CET] <cehoyos> FFmpeg does not support this and once you used FFmpeg to create a text (subtitle) file, it is not possible anymore to create the html (or so) file [13:42:12 CET] <pagios> good morning community resending my question , i am doing a mp4 extraction using index.m3u8 -live_start_index -10 -t 30 -c copy -bsf:a aac_adtstoasc test.mp4 it works well but it is SLOW, it takes 30seconds to give the output, is there a way to make it faster to get the mp4? Thank you [13:42:48 CET] <pagios> , https://pastebin.com/krXZ7Ya0 Weasel_ each of these lines takes around 1second to finish, that is what is making it slow, any way to read faster? [13:43:24 CET] <Anderssen> cehoyos, I'm also happy with it being plain text; preserving the colors etc. would be icing on the cake so to speak. [13:48:57 CET] <JEEB> Anderssen: try the txt_format AVOption with "ass" as the value [13:49:09 CET] <JEEB> and save as .ass [13:49:29 CET] <JEEB> that should contain text, colors and positioning [13:49:38 CET] <JEEB> not perfect, of course [13:49:54 CET] <JEEB> you can then preview the ass with mpv or aegisub or something if it's "good enough" [14:13:00 CET] <pagios> JEEB, any idea? [14:13:10 CET] <pagios> my issue is the segments being generated are small [14:13:13 CET] <pagios> and the playlist is small [14:13:19 CET] <pagios> segment size is 1sec, playlist is 4sec [14:20:20 CET] <Anderssen> JEEB, thanks; can't get it to run right now, have to try later, thanks again! [14:30:49 CET] <perseiver> Hello, I am using av_parse_init() to initialize the parser for AMR-NB codec. But code is not able to find the parser. I have compiled the ffmpeg with amr-nb, amrwb support, what else I have to do? [14:51:11 CET] <Weasel_> pagios: https://ffmpeg.org/ffmpeg-formats.html#toc-hls-2 hls_time & hls_list_size [14:51:52 CET] <perseiver> how ffplay find AMR NB codec and parser [14:57:50 CET] <durandal_1707> easy [14:59:23 CET] <ritsuka> perseiver: probably there isn't a parser, just a demuxer and a decoder. [15:00:28 CET] <perseiver> ok, why is this so? Because it is third party library and is compiled as optional? [15:00:50 CET] <ritsuka> maybe because it doesn't need a parser [15:02:09 CET] <perseiver> thanks ritsuka: I will have to find another way to use AMR. Atleast I want to read AMR file and stream it using ffmpeg library [15:02:12 CET] <durandal_1707> amr codecs do not have/use parsers [15:02:31 CET] <durandal_1707> perseiver: you never provided code you use [15:03:07 CET] <ritsuka> what's wrong with the demuxer? [15:03:44 CET] <perseiver> Actually I am trying to edit decode_audio.c that comes in example directory of ffmpeg. There is code that parse AV_CODEC_ID_MP2, I was try to change it like below [15:03:59 CET] <perseiver> codec = avcodec_find_decoder(AV_CODEC_ID_MP2); [15:03:59 CET] <perseiver> if(!codec) { [15:03:59 CET] <perseiver> fprintf(stderr, "Codec not found\n"); [15:03:59 CET] <perseiver> exit(1); [15:03:59 CET] <perseiver> } [15:04:00 CET] <perseiver> parser = av_parser_init(codec->id); [15:04:03 CET] <perseiver> if(!parser){ [15:04:07 CET] <perseiver> fprintf(stderr, "Parser not found\n"); [15:04:23 CET] <perseiver> But after compile I am always getting output as "parser not found" [15:04:36 CET] <perseiver> but not for other codec [15:05:10 CET] <durandal_1707> perseiver: because amr codecs does not need parsers [15:05:36 CET] <durandal_1707> you can not simply copy and paste code you do not understand [15:07:41 CET] <perseiver> ok. here is my code. what I am trying https://pastebin.com/3Qd7reDQ [15:09:39 CET] <durandal_1707> this is not trivial task, find someone who know how to code [15:12:24 CET] <perseiver> durandal_1707: ok,I need simple guide, how I will use AMRNB, AMRWB and libx264 codec which I have compiled with ffmpeg. As its third party library and first time I know that some codec doesnot require parser. There must be a way to use the current build. As its really interesting to know the ffplay command is successfully able to find the AMR codec and stream it [15:12:57 CET] <perseiver> If anyone can guide me, it will be very useful to me. [15:18:56 CET] <alone-x> hello, is it possible add black border only to the right corner? [15:18:57 CET] <alone-x> ffmpeg -i 123.mkv -filter_complex "scale=7387:900, pad=8580:900:598:0" 124.mkv [15:19:17 CET] <alone-x> i need add border from 7387 to 8580.. [15:19:50 CET] <alone-x> this line it's ok - but i need only to the right.... ;( [15:36:26 CET] <alone-x> . [15:42:01 CET] <pagios> Weasel_, 8 -live_start_index -10 -t 10 -c copy -bsf:a aac_adtstoasc test.mp4 <--- if it runs on timeX, it should extract timeX-10sec up to timeX , in my case it is extracting timeX up to timeX+10 , [15:42:56 CET] <pagios> hls fragment size is 1s and hls_playlist_length is 40sec [16:08:27 CET] <void09> I have 2 video streams that come from the exact same source, but have errors/corruption in 2 different places. They have both been converted to mkv, one by ffmpeg, the other with mkvtoolnix. what is the raw-est format i can use to convert them to (audio/video) so I get the same byte stream so i can try to stich the good bytes from the other one in the places where they are corrupt ? [16:08:58 CET] <void09> I assume the mkv files to differ in the stream, from ffmpeg and mkvtoolnix [16:19:22 CET] <void09> hmm, but if i convert both from ffmpeg, i should get the same stream though, no matter the container i used, right? [16:38:03 CET] <Weasel_> pagios: ok, you were on receiving end... I tried -live_start_index option with hls and it did not seem to have any effect. couldn't try with dash as my ffmpeg seems to miss demuxer for it [16:38:37 CET] <pagios> Weasel_, yea on receiving end [16:38:42 CET] <pagios> i need to client on the viewer [16:38:46 CET] <pagios> clip* [16:44:36 CET] <Weasel_> one could buffer those 10 seconds with gstreamer queue and then save those when triggered. i dont know enough about ffmpeg [16:47:53 CET] <void09> it needs to be a perfect merge [17:45:54 CET] <Weasel_> void09: I would copy streams out of containers and compare those [17:48:05 CET] <void09> how :/ [17:48:40 CET] <Weasel_> ffmpeg -i file.mkv -c copy stream.h264 [17:49:05 CET] <Weasel_> output name depends of the codecs [17:50:56 CET] <cehoyos> For most codecs, you can use -f rawvideo to avoid the naming issue [17:51:19 CET] <cehoyos> (Doesn't work for vorbis, speex, theora) [18:35:49 CET] <alone-x> hello, can i add only one black border to right side of file? [18:36:32 CET] <durandal_1707> alone-x: yes you can [18:36:41 CET] <alone-x> ffmpeg -i 123.mkv -filter_complex "scale=7387:900, pad=8580:900:598:0" 124.mkv [18:36:55 CET] <durandal_1707> read carefully documentation [18:37:03 CET] <durandal_1707> nobody gonna do your work [18:37:18 CET] <alone-x> ok Durandal. thank you [18:47:04 CET] <void09> any good binary files visualizing/compare/merge etc gui tool ? [18:48:19 CET] <void09> need to strip bytes 5-10 from a file [18:49:12 CET] <alone-x> VBinDiff-3.0_beta5.zip [18:49:26 CET] <alone-x> and fc (under windows) [19:03:45 CET] <jemius> I have awkward delays between audio and video of maybe 100-500 ms after filtering some frequencies with audacity. Any suggestions how I might find out where the problem is? I did not cut anything :( [19:06:56 CET] <durandal_1707> phase issues, audacity is far from perfect tool [19:08:26 CET] <jemius> durandal_1707, so it has nothing to do with the stream's exact length being changed? [19:12:44 CET] <alone-x> ffmpeg -i 123.mkv -filter_complex "pad=8580:900:7387:0:violet" 124.mkv [19:12:53 CET] <alone-x> Durandal why it's not ok? [19:13:12 CET] <alone-x> it's adding but from the left corner [19:13:15 CET] <durandal_1707> alone-x: i can not help you, as you never provided input file [19:13:47 CET] <alone-x> 7387*900 [19:13:59 CET] <alone-x> it's all about file [19:14:19 CET] <durandal_1707> alone-x: set width and height of output video [19:14:33 CET] <durandal_1707> and x/y where you need to set input video [19:14:49 CET] <durandal_1707> averything outside will be black [19:15:39 CET] <durandal_1707> jemius: i can not guess, because i do not know what have been done with _filtering some frequencies with audacity_ [19:15:39 CET] <alone-x> i need 8580 from 7387 by adding black to the right corner [19:16:12 CET] <kepstin> alone-x: then adjust the parameters to the pad filter to place the video over on the left. [19:17:21 CET] <alone-x> well, there is no other parameters : w h x y [19:17:59 CET] <alone-x> Add paddings with the color "violet" to the input video. The output video size is 640x480, and the top-left corner of the input video is placed at column 0, row 40 [19:18:00 CET] <alone-x> pad=640:480:0:40:violet [19:18:28 CET] <kepstin> yes, the parameters you've used place the video over on the right side, so the left side has black [19:18:50 CET] <kepstin> so change them to put the video on the left side, then you'll have black on the right [19:19:23 CET] <alone-x> kepstin, how can i add to 7387 ->8580? [19:19:31 CET] <alone-x> at the right corner? [19:20:27 CET] <durandal_1707> how much padding you need from left and from right? [19:20:43 CET] <kepstin> the parameters are, in order, width of the output video, height of the output video, how far from the left side the video will be placed in the area, and how far from the top side the video will be placed in the area [19:20:48 CET] <alone-x> 8580-7387= [19:21:01 CET] <alone-x> 1193 [19:21:02 CET] <kepstin> so if you don't want black on the left, then put the video over on the left - i.e. set x=0 [19:21:57 CET] <alone-x> kepstin i dont understand how can i move adding pad... from left corner to right [19:22:22 CET] <kepstin> this is super simple. do you need me to draw you a picture? [19:22:23 CET] <alone-x> all i need just put 1193*900 to the right top corner of my 7387*900 video [19:22:34 CET] <kepstin> the positions are relative to top left [19:22:51 CET] <kepstin> and the positions set the position of the video within the area, not the position of the padding [19:22:54 CET] <alone-x> well, i now left top = 0 0 [19:23:05 CET] <alone-x> bottom right = 7387 900 [19:23:20 CET] <alone-x> it's a super simple. but i cant do with filter [19:23:42 CET] <jemius> Are there any other recommandable tools or software libraries providing notch and lowpass filters? ffmpeg's filters itself don't suit my needs [19:24:26 CET] <kepstin> alone-x: it's super simple, the filter can do it just fine, you're just not understanding how it works [19:24:51 CET] <alone-x> ok, where is parameter of shift? w:h:x:y right? [19:25:08 CET] <durandal_1707> jemius: really? what are you attempting to do? [19:25:36 CET] <alone-x> kestin thank you - i will try re-read it [19:25:40 CET] <kepstin> so you have an input video that's 7387×900 right? and you want the output video to be 8580×900? And you want to do that by adding a black bar to the right side? [19:25:43 CET] <durandal_1707> ffmpeg have fine notch and lowpass filter, if you need anything higher order use aiir or afir [19:25:47 CET] <alone-x> yes [19:25:52 CET] <alone-x> 7387*900 [19:26:03 CET] <kepstin> alone-x: then you want to use pad=8580:900:0:0 [19:26:05 CET] <alone-x> all i need 8580 * 900 [19:26:27 CET] <alone-x> kepstin in that case will be at the left corner [19:26:35 CET] <kepstin> yes, that's what you asked for [19:26:35 CET] <alone-x> but i need at the right [19:26:40 CET] <kepstin> you want the video to be on the left [19:26:44 CET] <alone-x> no! i need at the RIGHT! [19:26:46 CET] <kepstin> that way the black bar will be on the right [19:27:06 CET] <alone-x> i need add it to the right [19:27:09 CET] <alone-x> is it possible? [19:27:15 CET] <jemius> durandal_1707, the maximum number of poles is limited to 2 (lowpass), what means -40dB/decade. That's not enough [19:27:21 CET] <kepstin> do you want the black bar on the left or the right? [19:27:30 CET] <alone-x> to the right [19:27:33 CET] <alone-x> black bar yes [19:27:38 CET] <kepstin> then i told you how to do that [19:27:47 CET] <alone-x> 1193*900 the w and h of this bar [19:27:52 CET] <alone-x> how? [19:28:08 CET] <alone-x> pad=8580:900:0:0& [19:28:08 CET] <alone-x> ? [19:28:14 CET] <durandal_1707> jemius: if you need IIR filter, then cascading biquad/lowpass(with different q) filter multiple times is all what you need [19:28:20 CET] <kepstin> alone-x: <kepstin> and the positions set the position of the video within the area, not the position of the padding [19:28:42 CET] <kepstin> alone-x: the black bar fills the space where there is no video [19:29:09 CET] <alone-x> kepstin thank you a lot [19:29:12 CET] <alone-x> if will try [19:29:41 CET] <jemius> durandal_1707, I suspected that if there's no switch to do it automatically, cascading manually would do harm [19:29:49 CET] <alone-x> ffmpeg -i 123.mkv -filter_complex "pad=8580:900:0:0:violet" 124.mkv [19:29:56 CET] <alone-x> not it's wrong [19:34:47 CET] <durandal_1707> jemius: https://github.com/nlphacker/Audacity/blob/570c5651c5934469c18dad25db03f050… [19:35:20 CET] <durandal_1707> butterworth lowpass8 is cascade of 4 lowpass2 filters [19:35:30 CET] <durandal_1707> and can be done with ffmpeg lowpass filter [19:36:17 CET] <kepstin> alone-x: i drew a picture for you: https://www.kepstin.ca/dump/padfilter.png [19:36:19 CET] <durandal_1707> alternatively if you know (there are tools that can generate it) coefficients for notch filter, you can use aiir filter [19:37:10 CET] <durandal_1707> kepstin: that picture should be part of our wiki [19:37:13 CET] <jemius> I do know some basics about digital data processing, but maybe not enough to do complex stuff. Anyways, it seems it has to be done manually [19:37:33 CET] <kepstin> i assume someone has made that picture before but better. [19:37:50 CET] <kepstin> but hey, i have a pen tablet that i felt like playing with [19:47:38 CET] <durandal_1707> jemius: something like this: lowpass=f=500:w=0.57622191,lowpass=f=500:w=0.66045510,lowpass=f=500:w=0.94276399,lowpass=f=500:w=2.57900101 f=500 change to some other value [19:49:46 CET] <jemius> durandal_1707, it seems one also would have to design his own notch filter [19:53:45 CET] <durandal_1707> jemius: not if you know its coefficients, need some background is dsp processing and you can use aiir filter [20:05:46 CET] <jemius> durandal_1707, hm, thx, I might have to read some literature first. I've looked into the filters, and they have a ton of parameters I don't fully understand [20:18:27 CET] <durandal_1707> jemius: https://www.micromodeler.com/dsp/ [20:20:11 CET] <durandal_1707> for high order display of coefficients you need to pay, but there is catch, and you can use aiir just fine, as it support zp (zero-poles) format [20:22:03 CET] <alone-x> kepstin thank u [20:23:40 CET] <alone-x> Secure Connection Failed [20:25:09 CET] <alone-x> via TOR it's ok [20:25:15 CET] <kepstin> my site's ssl is fine, either your os/browser are out of date, or you live in a country where it's blocked for some reason :/ [20:25:43 CET] <alone-x> kepstin, no other ssl it's working ;( [20:25:48 CET] <alone-x> i dont know nevermind [20:27:04 CET] <jemius> durandal_1707, uff, thx [20:28:26 CET] <alone-x> kepstin, still dont understand ;) [20:28:49 CET] <alone-x> all i need just add some bar with width [20:29:12 CET] <kepstin> yes, and i told you how to do it, gave you the exact parameters to use even. [20:29:57 CET] <kepstin> remember that the pad filter doesn't add bars - instead it works by making a new empty frame the size you asked for, and then it puts the input video somewhere in that frame [20:30:03 CET] <kepstin> so the space leftover becomes bars [20:30:54 CET] <kepstin> so if you want a bar on the right, you tell it to make an output which is wider than the input, and then put the input video on the left side. [20:31:00 CET] <kepstin> then the leftover space on the right becomes a bar. [20:34:54 CET] <alone-x> <kepstin> alone-x: then you want to use pad=8580:900:0:0 [20:34:56 CET] <alone-x> this one? [20:40:53 CET] <alone-x> thnank you kepstin, it's seems to me i know the reason [20:41:03 CET] <alone-x> why it seems to me not working [20:41:47 CET] <alone-x> i made it with remote admin and was some overlay transferring bug [20:41:49 CET] <alone-x> !!! [20:41:54 CET] <alone-x> locally it's fully ok [20:46:49 CET] <FlipFlops2001> When using the native AAC codec, what is the dB/oct of the -cutoff parameter? [20:52:28 CET] <FlipFlops2001> Note: AAC is a very good lossy codec, however, cutoff, PNS, TNS are not hi-fi, nor do they save a significant amount of bytes. Disabling them actually gives me slightly smaller, better sounding results. [20:53:40 CET] <kepstin> at low bitrates adjusting the cutoff is a tradeoff between muddy sound vs. screechy artifacts, depends on content which is worse :/ [20:54:20 CET] <kepstin> that said, i normally use fdk encoder instead of ffmpeg builtin. [20:56:30 CET] <kepstin> interesting question the lowpass - i have no idea what type of filter is used. i wonder if it might actually be done in the frequency domain (after the mdct?) [20:58:04 CET] <FlipFlops2001> @kepstin: Granted, not interested in bitrates that low, FDK encoder; excellent, but cannot encode at 96k sample rate. The trade off, I feel is worth it. I perform all my audio manipulations (eq, gain, etc.) @ 384kHz rf64/WAV then transcode them back to 96k AAC. [20:58:43 CET] <kepstin> there's no point in 96kHz audio for humans to listen to, and if you're archiving you shouldn't be using a lossy codec :/ [21:00:11 CET] <kepstin> using 44.1 or 48kHz should allow you to use substantially lower bitrate for the same quality without having to worry about disabling the lowpass filter :/ [21:02:02 CET] <kepstin> you want to use a lowpass filter of some sort anyways to remove ultrasonics incase the player has issues with aliasing or the amplifier has distortion [21:02:16 CET] <FlipFlops2001> @kepstin: In a recent listning test, sampling rate had to be in the upper 400kHz before humans could not tell the difference between analog and digital. I agree and I've been an audio eng. for 30+ years. [21:02:38 CET] <kepstin> (i'd expect more good amp setups to already have a lowpass filter builtin to avoid distortion issues) [21:03:10 CET] <kepstin> are you sure you weren't looking at a dsd test or something? comparing sample rates for dsd and pcm doesn't make sense :) [21:06:16 CET] <FlipFlops2001> @kepstin: Where are you getting this info from? The best audio amplifiers are those with a high slew-rate and 100kHz response or better. Humans can't hear above 20k (in most cases 18k) but the overtones produced with responses 20k+ is what enables the perception of transparency. [21:06:50 CET] <kepstin> i assume when they were doing this test with 400kHz sample rates they added a bunch of extra ultrasonic drivers with their own crossovers to reproduce the sounds that humans can't hear? [21:07:26 CET] <kepstin> the ultrasonics don't do anything unless your system is introducing distortion that causes them to become audible :/ [21:07:51 CET] <kepstin> (and if that's the case, you could pre-apply that distortion if you really wanted to) [21:08:52 CET] <kepstin> and also, since i haven't seen this, i hope this listening test was done double-blind, with review to check that people aren't doing something like listening for differences in relay clicks ;) [21:08:59 CET] <kepstin> (a real problem from a past listening test) [21:09:27 CET] <kepstin> otherwise it's completely meaningless. [21:10:34 CET] <FlipFlops2001> @kepstin: This is simple: If a crash cymbal produces frequencies @ 15kHz+, and your response is limited to 20kHz, then the 1st overtone of these frequencies are 0, since the 1st overtone of 15kHz is 30kHz. Therefore anything at 15kHz is a sine-wave. Does that make sense? [21:11:28 CET] <kepstin> crash symbols have lower frequency components than that... [21:11:48 CET] <kepstin> and also aren't pure single tones [21:12:17 CET] <FlipFlops2001> @kepstin: I know that, but they also have upper frequencies. [21:12:32 CET] <kepstin> which people can't hear, and have no effect. [21:16:07 CET] <FlipFlops2001> @kepstin: We'll never agree on this, but running my live mixing console @ a sampling rate of 96kHz, rather than 48kHz while mixing The O'Jays at an arena, sure sounds better. This has nothing to do with the limitations of the human ear. It has to do with what frequencies above 20k does to the lower audible range. [21:16:52 CET] <kepstin> doing intermediate mixing at a higher sample rate can make improvements if doing multiple filters because it gives additional room for filter overshoots or whatnot [21:16:55 CET] <kepstin> i'm not disputing that [21:17:05 CET] <kepstin> has nothing to do with the reproduction of the final sound tho [21:18:03 CET] <FlipFlops2001> @kepstin: Yes it does. Q: Have you ever done analog recording? [21:19:38 CET] <FlipFlops2001> @kepstin: Ever listened to a "Crusaders" analog recording? [21:20:01 CET] <kepstin> I haven't, but my impression was that most analog recording equipment has significantly less bandwidth than modern digital stuff and more distortion. [21:20:26 CET] <kepstin> although you could do things like run tape at half-speed to help it out a bit [21:25:35 CET] <FlipFlops2001> @kepstin: Really? Modern digital stuff? 48kHz cuts off (and I mean done) at 24kHz. Running tape @ 1/2 speed lowers your head-bump frequency and reduces upper freq resp/extends lower freq resp. (Tape speeds: 30 ips or 15 ips) [21:27:37 CET] <kepstin> i mean, you can record at higher sample rates digitally if you really want (with much less noise than the equivalent tape speeds), assuming they're within the range your microphone captures, but what's the point unless you're doing scientific research involving ultrasonics? [21:28:32 CET] <furq> damn kids these days with their zeroes and ones [21:28:49 CET] <FlipFlops2001> @kepstin: By careful biasing and recording eq, I was able to accomplish response on a Studer 2trk 1/4in machine flat beyond 20kHz and significant results @ 30kHz. Live to 2trk recordings sounded great. [21:29:21 CET] <FlipFlops2001> @furq: I'm 52 years old, how 'bout U?! [21:29:47 CET] <kepstin> i'm sure it did, but it would have also sounded great digitally recorded at 48kHz, unless part of what made it "sound great" was distortion added in the recording/mixing which you didn't reproduce in the digital mix. [21:30:58 CET] <FlipFlops2001> I learned with analog, vinyl, noise-floor restrictions. How 'bout U? [21:31:28 CET] <TheAMM> Here's a mellower topic: what properties can vary in a h.264 stream while still allowing the streams to be concatenated safely and without any expected ill effects? [21:31:33 CET] <kepstin> fun fact: apparently bit depth in digital recordings behaves very similarly to noise floor restrictions in analog :) [21:32:08 CET] <TheAMM> I'm going to be creating the files myself with ffmpeg so no random sources - resolution is a given and subsampling, but bitrate/crf? Timing somehow? [21:32:27 CET] <kepstin> TheAMM: hmm, i know x264 has a special option to make files concatable [21:32:34 CET] <kepstin> so it should be as simple as using that. [21:32:34 CET] <furq> TheAMM: pretty sure it's just profile/level stuff [21:32:59 CET] <FlipFlops2001> @kepstin: You hear differently than I. Let's leave it at that. There are a lot of other people in my industry that agree with me. Who have you worked with and what studios have you worked in? [21:33:02 CET] <furq> so frame size, framerate, number of refs [21:33:27 CET] <kepstin> TheAMM: --stitchable in the x264 cli docs, i presume it can be set with -x264opts [21:33:40 CET] <TheAMM> Yeah, looking at that [21:33:46 CET] <furq> maybe also bframes, some players will throw a fit if you have more bframes than set in the initial sps [21:33:59 CET] <furq> pretty sure some players are fine with it though [21:34:31 CET] <kepstin> FlipFlops2001: i'm going by reviewed studies of human hearing range combined with double-blind testing results that i've looked at. "people agree with me" doesn't mean anything without the testing to back it up :) [21:35:03 CET] <FlipFlops2001> @kepstin: Stop looking at studies and start listning. [21:35:11 CET] <TheAMM> I agree with kepstin, qed he wins [21:36:09 CET] Action: kepstin doesn't have any playback equipment rated with frequency responses sufficiently over 20kHz to do any meaningful testing about high sample rate playback. [21:36:34 CET] <TD-Linux> luckily we have this video https://xiph.org/video/vid2.shtml [21:36:35 CET] <kepstin> other than whether playing ultrasonics through my equipment causes audible distortion, i suppose. i could test that. [21:36:53 CET] <furq> TD-Linux: thank you [21:36:59 CET] <furq> i've been sat here waiting for a xiph guy to chime in [21:37:12 CET] <kepstin> that said, there's probably enough lowpass filters in my playback chain that the ultrasonics wouldn't be reproduced at all, and i have no way to check :) [21:42:03 CET] <FlipFlops2001> @kepstin: There is IM distortion and HM distortion. Which are you referring to? [21:42:52 CET] <CounterPillow> hello I am here for the boomer audiophile [21:42:54 CET] <kepstin> intermodulation distortion would be what bad equipment does when given ultrasonics it can't reject or handle. [21:42:58 CET] <FlipFlops2001> @kepstin: And don't forget slew-rate distortion. [21:43:36 CET] <CounterPillow> FlipFlops2001: at 52, your hearing is worse than that of most people in here. [21:44:01 CET] <FlipFlops2001> for everybody: All audio gear has IM distortions. Not having it is like trying to reproduce a pure sine-wave. [21:46:07 CET] <FlipFlops2001> @CounterPillow: This is a quiz: Where (in frequency) does the human hearing first begin to worsen? Since you apparently know how I hear. [21:47:17 CET] <CounterPillow> the upper spectrum of the hearing range, which is why kids can hear your shitty anti-vermin noise device on your car but you can't. [21:47:41 CET] <kepstin> in most people, high frequency dropoff, usually starting not much past teens. listing to loud noise/music makes it go faster. [21:47:53 CET] <FlipFlops2001> @CounterPillow: What is an "upper spectrum"? [21:48:03 CET] <CounterPillow> *upper end of the audible spectrum [21:48:53 CET] <CounterPillow> which for humans ends at 20 kHz. As much as you want to tell people you have a "golden ear" and exceptional bat-like hearing, everyone who has claimed this has never been able to prove it in double-blind tests. [21:49:11 CET] <kepstin> to be specific, the highest frequency which is audible at levels below the pain threshold decreases with age. [21:50:09 CET] <Hello71> FlipFlops2001: the main problem with your argument is that your argument disagrees with all carefully-conducted testing, the entire scientific community, and the fundamental basics of audio encoding known for several decades and used in every single actual audio codec. [21:50:17 CET] <CounterPillow> Feel free to get a hearing test done and confirm this for yourself, good hearing labs will give you a nice plot of where your shitty spots are. [21:50:23 CET] Action: kepstin assumes he can't hear anywhere near 20kHz anymore, but hasn't actually had it tested. [21:50:36 CET] <Hello71> ... lossy audio codec, anyways. [21:50:43 CET] <kepstin> and yeah, individuals may have hearing problems in other areas too of course. [21:51:37 CET] <CounterPillow> inb4 something something quantum physics you can't test my incredibly good hearing!!11!1 [21:51:38 CET] <FlipFlops2001> @Everyone: In a human's coclea, the longest hairs are at the upper-midrange (+- 3kHz). Those are the hairs that become flat first. Therefore, that is where you start to lose your hearing first. That is also the range that we deceminate consonant sounds. That is why people who are losing their hearing often say they can hear but can't understand what people are saying. [21:52:24 CET] <Hello71> so... what? [21:52:56 CET] <Hello71> this is literally a climate change denier argument: deny, distort, redirect [21:53:02 CET] <kepstin> sure, but they can still *hear* those frequencies, maybe compensate for them with an eq bump in the upper midrange or a hearing aid in extreme cases. [21:53:18 CET] <kepstin> (in most cases, obviously "not all" applies here) [21:53:28 CET] <FlipFlops2001> After losing the upper-midrange in your old-fart hearing, then the top-end goes, then everything else. Hope I don't live that long. [21:53:37 CET] <jemius> Is it known yet when AV1 will be fully usable (in ffmpeg) ? [21:53:52 CET] <kepstin> jemius: define fully usable? [21:54:03 CET] <furq> it's already usable in ffmpeg, there's just no internal decoder [21:54:14 CET] <jemius> not experimental anymore, works as intended, meaning it creates usable, unbroken videos [21:54:18 CET] <FlipFlops2001> @kepstin: Yes all. Human physilogic. (is that spelled right?) [21:54:19 CET] <kepstin> iirc the rav1e encoder driver got merged recently, and dav1d works as a decoder. [21:54:34 CET] <Hello71> aom has been available for ages [21:54:35 CET] <furq> it's created usable and unbroken videos for about a year [21:54:42 CET] <furq> which is also how long it takes [21:54:43 CET] <jemius> A Rust encoder in ffmpeg? [21:54:58 CET] <kepstin> it's not in ffmpeg, external library. With a C api. [21:55:02 CET] <Hello71> and one would hope that aom works fine if they're doing all their standards development based on that... [21:55:21 CET] <furq> they froze the spec for realsies this time at least a year ago now [21:55:21 CET] <jemius> kepstin, so where did it get merged to? [21:55:24 CET] <CounterPillow> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2802451/ "Although the rate of change was greater at lower frequencies, the largest absolute changes in hearing thresholds with age were observed at higher test frequencies." [21:55:32 CET] <Hello71> jemius: what? [21:55:35 CET] <FlipFlops2001> I'm done. Just stickn' 'round to see what else is up! [21:56:19 CET] <kepstin> jemius: git master, where else would it go? [21:56:35 CET] <furq> there's been dav1d and aom support for a long time anyway [21:56:47 CET] <jemius> I thought its the ffmpeg philosophy to have all codecs statically linked [21:57:01 CET] <furq> it isn't but why would that make a difference [21:57:03 CET] <Hello71> that is both wrong and unrelated [21:57:06 CET] <furq> you can static link rust libraries if you want [21:57:12 CET] <Hello71> yeah, that [21:57:16 CET] <FlipFlops2001> @CounterPillow: Be specific-What frequencies? 3.5kHz could be considered "higher freq", so could 15kHz. Be specific. [21:57:19 CET] <kepstin> I'm honestly disappointed that the c api for rav1e isn't called crav1e [21:57:29 CET] <CounterPillow> I've literally linked the paper you twat [21:58:14 CET] <jemius> ts ts ts, that's some vocabulary [21:58:26 CET] <FlipFlops2001> @CounterPillow: Just a question, I'll look at the paper U Dickhead. [21:58:40 CET] <CounterPillow> >The frequencies at which threshold changes were greatest depended on the age of participants. For the 4859 and 6069 years age groups, for example, threshold changes were largest at higher frequencies (38 kHz). For the older age decades (e80 years), the greatest changes in thresholds were noted for lower frequencies (0.52 kHz). As noted earlier, the smaller changes in threshold observed at higher frequencies are likely due to [21:58:40 CET] <CounterPillow> the greater baseline hearing loss at higher frequencies for the older adults. Accordingly, the dynamic range for potential change was reduced at higher frequencies. [21:58:43 CET] <JEEB> CounterPillow is not yet in the zen of no care [21:58:45 CET] <kepstin> CounterPillow: everytime we say "high frequencies", we're referring to frequency which is a person's absolute threshold of hearing, aka the highest frequency that is audible when played at levels below the threshold at pain [21:58:53 CET] <kepstin> er, FlipFlops2001 ^^ [21:58:55 CET] <JEEB> may he attain peace soon [21:59:08 CET] <TD-Linux> kepstin, it was briefly crav1e when it was a separate repo [21:59:09 CET] <furq> i won't hold my breath [21:59:10 CET] <kepstin> yeah, i still haven't worked out all my care yet either. [21:59:13 CET] <CounterPillow> JEEB: "soon" as in when this boomer kicks the bucket, which is most likely going to be before me. [21:59:47 CET] <furq> haven't you got virgil texas tweets to top reply to [22:00:01 CET] <CounterPillow> I missed their debate commentary :( [22:13:24 CET] <jemius> Does anyone here know what happened to Daala and Theora back in the day? I only heard one of them got used for the VPx codecs [22:15:34 CET] <JEEB> jemius: daala people work on av1/x [22:15:35 CET] <kepstin> theora was based on one of the old vpx codecs, iirc [22:15:54 CET] <JEEB> and theora is where some people for daals came from [22:15:59 CET] <JEEB> like derf etc [22:17:12 CET] <CounterPillow> Theora was based on VP3 I believe, but I don't think VP8/9 are necessarily based on Theora in any way other than sharing common ancestry. [22:19:49 CET] <jemius> did they reach a point where you could "use" them? (Using means you get proper videos, although with larger size than with MPEG) [22:20:19 CET] <CounterPillow> Most codecs will produce proper videos if you throw enough bits at it [22:20:31 CET] <CounterPillow> Some parts of Daala made it into AoM AV1, which is why #daala is now about rav1e AV1 encoder development, and much of VP10 made it into AoM AV1 too. [22:21:25 CET] <jemius> so, realistically, the only video codecs which are somewhat on the level of the h.2xx family are VPx and now AV1 ? [22:23:03 CET] <CounterPillow> That is correct, but if you are not a company you really don't need to worry about H.264/H.265 patents anyway. [22:23:34 CET] <CounterPillow> Technically there is also that chinese codec davs2 [22:25:23 CET] <jemius> CounterPillow, how does this even work, why doesn't the mpeg foundation sue everyone to the ground for distributing the codec for free everywhere? [22:25:35 CET] <CounterPillow> Because that's not how any of this works. [22:25:58 CET] <jemius> It works this way with conventional industry patents [22:27:31 CET] <klaxa> to build something according to a "conventional industry patent" you usually need more resources than a computer as it is with IP patents [22:27:37 CET] <CounterPillow> H.264/H.265 are international standards ratified by government-sanctioned standards bodies for video compression. It just so happens that some of the industry who have contributed to the specification have patent claims on specific concepts used in the coding. [22:28:23 CET] <CounterPillow> Most devices with hardware decoders get the necessary patent licenses as part of purchasing the decoder chip. [22:29:20 CET] <klaxa> for the pi you can even retroactively purchase a license for the built-in hardware decoder for mpeg2 was it? because h264 was included by default i think? [22:30:01 CET] <CounterPillow> Cisco has OpenH264 available because they pay so much to MPEG-LA they are allowed to ship everyone H.264 encoding/decoding capabilities without paying more licensing fees for it. [22:31:40 CET] <CounterPillow> Also obviously nobody is insane enough to start suing random individuals because 1. lawsuits cost a lot, actual patent trolls are usually just after settlements, and MPEG-LA isn't a patent trol, 2. in various jurisdictions you have to face questions over the validity of software patents and the anti-competitive behaviour you're exhibiting [22:35:36 CET] <furq> now hevc, on the other hand [22:35:49 CET] <CounterPillow> yeah they have 3 patent pools because people got greedy [22:35:53 CET] <furq> isn't it four now [22:36:03 CET] <CounterPillow> possibly 5 by the time I finish typing this sentence. [22:36:13 CET] <jemius> what the heck is a pool? [22:36:41 CET] <CounterPillow> It's several companies with patent claims on a specific technology banding together so you can license all the patents covering that technology from one source. [22:37:06 CET] <furq> mpeg-la, hevc advance, velos, and technicolor [22:37:49 CET] <jemius> these people are annoying. Recently I've seen a presentation about codec2 and it said that he had only to replace 5% of the code of comparable codecs, the rest was already open source / free [22:38:04 CET] <CounterPillow> It's not about open-source/free [22:38:09 CET] <jemius> hey, technicolor. They made the worst router I ever owned [22:38:11 CET] <furq> bear in mind a lot of those patents arguably cover vp[89]/av1 [22:38:27 CET] <CounterPillow> All MPEG codecs are developed on public mailing lists, with an open reference encoder and decoder [22:39:37 CET] <JEEB> at multimedia conferences you have people making jabs at how the "open" media stuff is actually much more closed during development than the formats they're trying to become an alternative to [22:39:39 CET] <furq> google/aom have legal defense funds for licensees but they do not offer full indemnification [22:39:44 CET] <furq> so that's nice [22:40:06 CET] <JEEB> but yes, patent licensing is something you have to take up with a lawyer if you really want to make business [22:40:21 CET] <JEEB> same for VPx/AVx or oen of the ITU/ISO formats [22:41:15 CET] <furq> with that said you can still theoretically get sued for using hevc even if you have four licenses to use it [22:41:27 CET] <furq> so that's even nicer [22:41:36 CET] <jemius> sounds good [22:41:40 CET] <CounterPillow> Well, you can also get sued for using VPx or AV1 [22:41:43 CET] <JEEB> technically that goes for all formats [22:41:44 CET] <furq> basically don't ever do anything [22:41:47 CET] <JEEB> if you go that far [22:41:49 CET] <furq> you'll be fine [22:42:26 CET] <furq> JEEB: i'd say those are equally far away given nobody has yet been successfully sued for using vpx afaik [22:43:14 CET] <JEEB> I am not sure how many legal cases there have been against formats and how many have been settled etc [22:43:20 CET] <JEEB> IANAL as they say [22:43:26 CET] <CounterPillow> Pretty sure that unless you're running netflix/youtube, nobody actually cares lol. [22:43:46 CET] <furq> i know of at least one unsuccessful lawsuit against google for vp8 infringing h264 patents [22:43:49 CET] <furq> i think by nokia [22:44:05 CET] <JEEB> yes, nokia tried to troll around there and I'm not sure how successful that was, yes [22:44:12 CET] <JEEB> although I don't remember how exactly that ended [22:44:23 CET] <furq> anyway yeah you'll probably be fine [22:44:24 CET] <void09> help, how to convert the 0x blabla ffmpeg error reporting offset into timestamp ? [22:44:39 CET] <JEEB> void09: ? [22:44:42 CET] <CounterPillow> ... what [22:44:43 CET] <furq> that's a memory address, not a timestamp [22:44:58 CET] <void09> I scanned a file for errors with ffmpeg and get the errors like: [22:45:10 CET] <void09> [aac @ 0x55b3b5298400] channel element 0.0 is not allocated [22:45:15 CET] <JEEB> yea that 's memory address [22:45:30 CET] <JEEB> you would have to print the dts/pts of the packet you were handling [22:45:39 CET] <void09> ok is there any way i can change it so I get at least a byte offset in the file ? [22:45:57 CET] <JEEB> that'd be around the AVPacket, so not from that message no [22:46:07 CET] <JEEB> also that's not necessarily corruption [22:46:15 CET] <JEEB> that could just be that you're starting a stream in the middle [22:46:23 CET] <void09> I am doing this at the moment ffmpeg -v error -i "outputvideo2.mkv" -f null - 2>test.log [22:46:24 CET] <JEEB> like with broadcasts or live streams [22:46:47 CET] <void09> JEEB: trying to error scan tv recordings that the recording software reported errors in [22:47:09 CET] <JEEB> void09: yea that is not going to give you timestamps unless you do like -debug_ts or something [22:47:13 CET] <void09> after i cut and make the .ts file into mkv sometimes the errors are gone, but sometimes a few still persist when running that command [22:47:15 CET] <JEEB> I recommend just making an API client :P [22:47:29 CET] <void09> what ? ;\ [22:47:32 CET] <JEEB> void09: if it's just in the beginning it just means that you didn't get enough packets to start decoding or whatever :P [22:48:00 CET] <void09> JEEB: this is after cutting 15 minutes from start and end, so no [22:48:14 CET] <JEEB> well even so? if you cut at arbitrary locations? [22:48:34 CET] <JEEB> anyways, -debug_ts will get you timestamps [22:48:36 CET] <void09> arbitrary ? I cut with ffmpeg, it should not produce errors that are not already in the stream [22:48:36 CET] <jemius> Google started with the VP codecs because they wanted to avoid licensing foo, as I understood it. Does anyone know how it works when someone loads up mpeg material there; I assume it's transcoded on their servers? [22:48:53 CET] <furq> void09: if you add -stats it'll print the stats line around the error messages [22:48:59 CET] <furq> which is not a great solution but better than nothing [22:49:15 CET] <furq> on account of it will print the stats line five million times and then there'll be three error messages [22:49:38 CET] <JEEB> debug_ts basically logs everything in the framework, but I do recommend making one's own API client where you can see at which AVPacket the decoding barfs and get whatever data you might need for that [22:50:06 CET] <void09> JEEB: I am really far from that skill level [22:50:31 CET] <JEEB> but I know that you can get with broadcast streams errors for AAC f.ex. if you don't exactly cut at specific packets, and that is 100% OK and doesn't mean the stream is actually broken [22:50:41 CET] <JEEB> of course if it happens in the middle of stream that can be a problem [22:50:51 CET] <JEEB> as in, after you've got some actual audio out [22:50:56 CET] <JEEB> and successfully decoded [22:50:58 CET] <void09> oh, I did not know that [22:51:27 CET] <void09> oh since we're here, is there any way to tell ffmpeg when using -ss -to to cut to the nearest keyframe INCLUDING those timestamps ? [22:51:47 CET] <void09> it just chooses the nearest keyframe which might not include the exact timestamp i gave it [22:51:50 CET] <JEEB> -ss should include the timestamp, but mpeg-ts cutting is inexact [22:51:58 CET] <JEEB> since mpeg-ts is not indexed format [22:52:04 CET] <JEEB> and thus seeks are not exact [22:52:36 CET] <JEEB> there is a flag in the API to include the set value in the seek, as in seek before it and not after [22:52:41 CET] <JEEB> and that is set in ffmpeg.c by default afaics [22:52:44 CET] <void09> it does not include the timestamp, just cuts to the nearest keyframe, so i always have to do -500ms +500ms to make sure it's included [22:53:07 CET] <void09> since the keyframe is abot every 1 second or so [22:53:10 CET] <JEEB> if you have this issue with correctly flagged non-mpeg-ts (mp4, mkv etc) [22:53:26 CET] <JEEB> then it might be an issue, but I know for a fact that mpeg-ts seeking is not exact [22:53:33 CET] <JEEB> I also know that ffmpeg.c does with -ss seek to before [22:53:39 CET] <JEEB> if the exact time doesn't have it [22:54:00 CET] <void09> ffmpeg -i "video.ts" -ss 00:15:22.600 -to 02:19:27.760 -vcodec copy -acodec copy outputvideo.mkv [22:54:05 CET] <void09> this is what I use now [22:54:10 CET] <JEEB> welcome to mpeg-ts [22:54:15 CET] <JEEB> FFmpeg does not index it [22:54:19 CET] <JEEB> thus your seeks are inexact [22:54:21 CET] <JEEB> gg kthx [22:54:38 CET] <void09> but how come i get precise timestamps when seeking it in mpv ? [22:54:42 CET] <void09> or are they not precise? [22:54:45 CET] <JEEB> they are not [22:54:59 CET] <JEEB> same stuff behind the scenes, possibly more trying but same API [22:55:05 CET] <void09> cause i used the milisecond timestamps in mpv to figure out the cutting point [22:55:42 CET] <JEEB> yea, ffmpeg.c uses AVSEEK_FLAG_BACKWARD [22:55:46 CET] <JEEB> I just double-checked it [22:56:01 CET] <void09> so what can i do about this.. use that slow seeking thing so that ffmpeg indexes the file ? [22:56:09 CET] <void09> I think it was to use -ss before -i [22:56:31 CET] <JEEB> there is no indexing, -ss after -i just used to decode until that point [22:56:34 CET] <JEEB> which effectively worked :P [22:56:35 CET] <void09> I got that suggestion here for making screenshots of a bluray m2ts file [22:56:51 CET] <JEEB> ffms2 is an indexing library that utilizes FFmpeg libraries in the background [22:56:56 CET] <void09> since by default they would come out glitchy/gray for some blurays [22:57:20 CET] <void09> oh ok.. so what is the fix for my problem ? :) [22:57:32 CET] <void09> just keep using -500ms +500ms as cutting points? [22:57:40 CET] <JEEB> if you need to do copying of packets, you do your own indexing [22:57:48 CET] <JEEB> if you need decoding, you start using ffms2 [22:58:22 CET] <void09> how do i do my own indexing? [22:58:36 CET] <JEEB> you use the API, like ffmpeg.c (the cli app) or ffms2 do [22:58:47 CET] <JEEB> (ffmpeg.c does no indexing but it uses the API) [22:59:18 CET] <void09> ok that's a confusing answer [23:00:12 CET] <JEEB> the FFmpeg API lets you do indexing, but it doesn't itself keep all the book-keeping for that frame exact use case. that is why things like ffms2 exist [23:00:47 CET] <JEEB> like, FFmpeg has an API for seeking to a point, which is what ffmpeg.c uses - but it depends on how exact the container is [23:00:57 CET] <JEEB> mpeg-ts has no index and thus if you get anywhere close you need to get, you're lucky [23:01:35 CET] <void09> right so are you suggesting converting to mkv first, then doing the cutting ? [23:01:36 CET] <JEEB> but if you only need to decode - ffms2 already does this. it just does not do packet copying :P [23:01:43 CET] <void09> cause i do them all in one step [23:02:02 CET] <JEEB> void09: mkv, mp4 or anything else with an index should get you far more exact seekign yes [23:02:12 CET] <JEEB> mpeg-ts just happens to be an A->B container [23:02:18 CET] <void09> ffmpeg -i "video.ts" -ss 00:15:22.600 -to 02:19:27.760 -vcodec copy -acodec copy outputvideo.mkv [23:02:34 CET] <JEEB> where the best way to seek is through guesstimates based on file size [23:02:34 CET] <void09> but i presume the seeking is still inaccurate, as it's done before mkv-ing it [23:02:35 CET] <void09> right? [23:02:38 CET] <JEEB> yes [23:02:52 CET] <JEEB> if you need exact seeks in mpeg-ts you have to go A->B or index [23:02:55 CET] <void09> ok so mkv first step, cutting second step [23:03:43 CET] <void09> so ffmpeg (the cli client) can't do A->B ? (Frame accurate seeking) [23:03:58 CET] <void09> and this is why ffms2 exists [23:04:12 CET] <JEEB> it can, which is why if you skip -ss and stuff you can probably get a pretty good stream copy [23:04:29 CET] <JEEB> but as soon as you get to -ss you enter av_seek_frame [23:04:44 CET] <void09> ok then how do I do it without using -ss ? [23:04:47 CET] <JEEB> which will attempt to seek to a packet either after or before that point as well as the container can do [23:05:39 CET] <JEEB> void09: by writing an app that discards packets until it hits the random access point? [23:05:53 CET] <JEEB> since I know ffmpeg.c earlier used to do decoding fine, but copying packets less so [23:06:11 CET] <JEEB> since -ss after -i worked for *decoding* but you're doing packet copying [23:06:25 CET] <void09> I am ? I was not aware of that [23:06:43 CET] <JEEB> -c copy is packet copying [23:06:55 CET] <JEEB> input parser gets you packet, output writer receives that packet [23:07:25 CET] <void09> I don't know, its' just stuff i found by googling that worked and i stuck with it : ) [23:07:57 CET] <JEEB> with decoding it used to work that -ss after input (-i BLAH) decoded to that point, and then did whatever [23:07:58 CET] <void09> but yes, I want no encoding, just cutting and making an mkv of the av stream. I don't like encoding much [23:08:20 CET] <JEEB> but with having packets copied -ss only worked before input and thus on the input layer, before decoding [23:08:32 CET] <JEEB> and thus you end up with av_seek_frame [23:09:02 CET] <JEEB> which seeks to either after or before that point you specified depending on flags (I'm pretty sure it sets the flag to havei t be before due to how I've done -c copy) [23:09:28 CET] <JEEB> but it also means that if you have a non-exact container [23:09:42 CET] <JEEB> then both middle fingers up for you trying to get exact seeking [23:09:50 CET] <void09> ok, so this is what the question was about, how to make it cut before or equal to the first point , and >= the end point [23:10:04 CET] <JEEB> it as far as I can tell is supposed to cut before [23:10:25 CET] <JEEB> if not, that is most likely due to inexact seeking in your favourite streaming container [23:10:59 CET] <void09> well, since mpv uses ffmpeg to play files, could it be I am not getting perfectly accurate timestamps when seeking, and thus ffmpeg behaves correctly, I just have the wrong times? [23:11:10 CET] <void09> right.. [23:11:45 CET] <JEEB> mpv also behind the scenes uses av_seek_frame for mpeg-ts. the amount of information the parser has depends on teh I/O layer, but I'd expect it to be similar [23:11:57 CET] <JEEB> although mpv in theory could be using byte wise seeking [23:12:07 CET] <JEEB> i haven't checked if anyone cared to implement that [23:12:20 CET] <JEEB> probably not since mpeg-ts with timestamps going 'round doesn't seek too well [23:12:30 CET] <JEEB> (mpeg-ts goes up to 26.5 or so hours) [23:12:37 CET] <JEEB> and then the timestamps wrap around [23:12:43 CET] <void09> oh I didn't know that [23:12:45 CET] <JEEB> you can guess how fun seeking around that with timestamps is :P [23:13:38 CET] <void09> well, what I did until now, substract/add ~500 something ms from begin/end vs the timestamps mpv shows, always got me the correct result [23:13:46 CET] <void09> and i've done at least 50 cuts [23:14:26 CET] <void09> so I assumed it seesks to the nearest keyframe instead of including it [23:14:29 CET] <JEEB> you can do ffprobe -of json -show_streams -show_programs -show_packets -i INPUT > blah.json [23:14:40 CET] <void09> where can i see the possible flags for this seeking stuff ? [23:14:40 CET] <JEEB> and then see the packets in that JSON output [23:15:38 CET] <JEEB> ah right, ffmpeg.c uses avformat_seek_file [23:15:53 CET] <JEEB> but still with the parameters it utilizes it should seek before [23:16:05 CET] <JEEB> ret = avformat_seek_file(is, -1, INT64_MIN, is->start_time, is->start_time, 0); [23:16:11 CET] <JEEB> start_time is what you put into -ss [23:16:50 CET] <JEEB> and given that -ss has generally worked for me as I expected, I would guesstimate that it actually does that and the container is making it derp [23:16:58 CET] <JEEB> since with mpeg-ts seeking is all sorts of guesstimation [23:17:06 CET] <JEEB> welcome to containers without an index :P [23:17:46 CET] <JEEB> basically this is why ffms2 exists for people who want to do frame exact seeking and decoding [23:18:22 CET] <void09> and to think they put something like that in blurays :\ [23:18:30 CET] <JEEB> yes [23:18:53 CET] <void09> i don't know about the m2ts overhead, but the .ts one is pretty ridiculous [23:19:01 CET] <void09> i've seen 5-10% space overhead [23:19:07 CET] <JEEB> same format [23:19:23 CET] <JEEB> blu-ray just has a 4 byte timestamp after each packet or soething [23:19:27 CET] <JEEB> so 188+4 [23:19:30 CET] <JEEB> as opposed to 188 [23:19:41 CET] <void09> so it has timestamps ? [23:19:50 CET] <JEEB> even standard mpeg-ts has timestamps yes [23:19:52 CET] <JEEB> but no index [23:20:02 CET] <JEEB> neither does the blu-ray 192 byte variant (188+4) [23:20:14 CET] <JEEB> or well, blu-ray has playlists which have chapters [23:20:17 CET] <void09> so when I am recording, and the rec software saves a .ts.. does it write its own timestamps ? [23:20:23 CET] <JEEB> which point towards a BYTE offset [23:20:42 CET] <JEEB> so literally blu-ray playlists say "byte X from file Y" [23:20:43 CET] <JEEB> or so [23:20:44 CET] <JEEB> :P [23:20:48 CET] <void09> I did the json packet thing with ffprobe you mentioned, and the first one i get is an audio packet with : "pts_time": "0.003000", [23:21:15 CET] <JEEB> yes, they come in the order that the parser reads them [23:21:55 CET] <void09> I wonder if it's possible to record tv streams directly to mkv [23:22:13 CET] <void09> probably not since it does not know when it will end? [23:22:13 CET] <JEEB> I don't see any reason not to, although generally I like to dump the broadcast as-is [23:22:22 CET] <JEEB> matroska does not need a duration [23:22:30 CET] <JEEB> you need to write hte index at some point at the end [23:22:33 CET] <JEEB> if you need exact seeking [23:22:42 CET] <JEEB> but you can keep writing it through similarly to mpeg-ts [23:22:47 CET] <kepstin> you don't need accurate seeking for just skipping around in bd playback, just go forward/back some number of bytes based on the estimated bitrate, find the next keyframe, and start playing. [23:22:56 CET] <JEEB> yes [23:22:59 CET] <kepstin> good enough for a consumer player skip feature [23:23:03 CET] <JEEB> it's mostly bit rate based [23:23:10 CET] <JEEB> since all of the blu-rays generally are very static in bit rate [23:23:29 CET] <JEEB> and playlists have byte offsets so those longer seeks work like that [23:27:32 CET] <void09> ok i added the -stats option somebody mentioned before to find errors, and guess what, my error is right in the last second of the file [23:27:58 CET] <void09> [aac @ 0x56310cc43800] channel element 0.0 is not allocatede=N/A speed=27.4x [23:27:58 CET] <void09> Error while decoding stream #0:1: Invalid data found when processing input [23:27:58 CET] <void09> frame=241207 fps=802 q=-0.0 Lsize=N/A time=02:40:48.84 bitrate=N/A speed=32.1x [23:28:03 CET] <JEEB> yea you can also get errors at the end of streams where the decoder expects more packets yet you ran out [23:28:14 CET] <JEEB> I've esp. had that with AC-3 [23:29:05 CET] <void09> yes but it was a cut with ffmpeg stream.. [23:29:28 CET] <void09> oh, so you mean, ac3/aac work like keyframes in videos do ? [23:30:10 CET] <void09> and since the sound follows the video, when copying packets, it might happen to hit a non-key frame sound packet ? :) [23:30:38 CET] <JEEB> well stream copy generally starts with a random access point, but you might stop at a random packet [23:30:38 CET] <void09> I mean, the sound also has its own time stamps, right ? in the .ts [23:30:56 CET] <JEEB> and if you just told ffmpeg.c to stop and decoder is after packet handling [23:31:07 CET] <JEEB> -> you can stop before a full audio frame has been decoded [23:31:31 CET] <JEEB> more likely with mpeg-ts input where you might or might not get a full PES packet [23:31:39 CET] <JEEB> when you stop recording your input [23:33:25 CET] <void09> well, I have 15 minutes of before/after padding in my recordings, cause sometimes they're not right on time (still miss some even with that, but I can't add more as it would be impractical) [23:34:29 CET] <void09> what I do now to remove the <=24 frames or so of possible extra frames i get at the beginning/end after doing the ffmpeg cut and mkv conversion, is add a chapter to the mkv, and specify begin/end timestamps so it ignores the extra frames [23:35:13 CET] <void09> I wonder if ffmpeg ignores chapters present in mkv, unlike players [23:35:39 CET] <JEEB> if I need to process mpeg-ts I would have either indexed or done A->B reading for copying packets [23:35:55 CET] <JEEB> depending on how exact etc cuts have to be [23:36:02 CET] <JEEB> and how much overhead doing A->B always would bring :P [23:36:09 CET] <void09> processing overhead? [23:36:29 CET] <JEEB> indexing is mostly I/O [23:36:31 CET] <void09> not much, I have 3GB/s nvme and 8 core [23:36:49 CET] <JEEB> but yea, you need your own API client to get that doje [23:36:51 CET] <JEEB> *done [23:37:00 CET] <JEEB> ffmpeg.c is not going to do that for you out of the box [23:37:09 CET] <JEEB> I usually copy from mpeg-ts without seeks etc to mp4 [23:37:10 CET] <void09> sigh. such basic stuff missing :) [23:37:17 CET] <JEEB> not really basic is it? [23:37:29 CET] <JEEB> having to index a whole input is not what lavf expects [23:37:30 CET] <void09> of course it is, first use case i have for ffmpeg. and it can't do it (precisely) [23:37:48 CET] <void09> but i will try mkving the whole thing first, and then cutting [23:38:03 CET] <JEEB> most people do either A->B stuff, or use indexed containers [23:38:12 CET] <void09> JEEB: cuts can only really be done on keyframes, no ? without re-encoding [23:38:24 CET] <void09> or I-frames [23:38:34 CET] <JEEB> starting with random access points yes, the flag on ffprobe's packets is keyframe yes [23:38:39 CET] <JEEB> since the naming is from simpler times [23:38:48 CET] <JEEB> when "keyframe" was still a random access point and vice versa :P [23:39:15 CET] <JEEB> void09: keyframe/I frame just means that the single picture can be decoded since it's most likely intra [23:39:23 CET] <JEEB> it gives no promises about latter frames [23:39:36 CET] <JEEB> that is why the wording "random access point" is what people use now [23:39:46 CET] <void09> oh ok [23:39:51 CET] <JEEB> a random access point promises decode'ability of things onwards from that point, too [23:40:01 CET] <void09> so there's no way around it. other option would have been to cut at "random access point" and encode the few frames outside of it [23:40:33 CET] <void09> or the way i do it, ignore the max 50 (average 25) spaced used by extra frames and implement a chapter to skip them [23:41:13 CET] <void09> I looked into the first option but it seemed to be a big hassle, video encoder needing the same encoding parameters used for the rest of the stream [23:42:59 CET] <void09> I just realised that error log I pasted eralier actually told me the total video time, and not the time at which the error occured [23:43:15 CET] <void09> [aac @ 0x56310cc43800] channel element 0.0 is not allocatede=N/A speed=27.4x [23:43:15 CET] <void09> Error while decoding stream #0:1: Invalid data found when processing input [23:43:15 CET] <void09> frame=241207 fps=802 q=-0.0 Lsize=N/A time=02:40:48.84 bitrate=N/A speed=32.1x [23:43:50 CET] <void09> let's try with -debug_ts [23:43:54 CET] <JEEB> void09: for the record, I did write myself a thing that would attempt to get me a specific frame at a timestamp without using ffms2 [23:43:59 CET] <JEEB> a few years ago [23:44:23 CET] <JEEB> that just solidified my understanding of "lol mpeg-ts" [23:44:36 CET] <JEEB> because I could get really nice seeks there :P [23:44:36 CET] <void09> so furq adding -stats did nothing for it [23:44:50 CET] <JEEB> if you need to handle mpeg-ts packet-exact [23:44:52 CET] <JEEB> you do indexing [23:45:11 CET] <void09> I need time-exact :) [23:45:19 CET] <JEEB> well yea [23:45:35 CET] <JEEB> in other words, you either need A->B (if you are sure the time is there in that clip) or indexing [23:45:46 CET] <JEEB> indexing quicker after you go through the whole shebang once [23:46:22 CET] <JEEB> ffmpeg.c does not do this for you since it is just a thin wrapper on the FFmpeg APIs. you can do indexing with the APIs but it's not something that the framework does for you. [23:46:42 CET] <JEEB> (ffms2 is an example of people wanting frame exact access) [23:46:44 CET] <void09> Right, I fully understand now, after much initial confusion [23:47:09 CET] <JEEB> but yea, what writing a test app myself taught to me with mpeg-ts and trying to get to a specific time [23:47:12 CET] <JEEB> is that you should index [23:47:13 CET] <JEEB> :D [23:47:58 CET] <JEEB> also if you think you can handle seeking better in the mpeg-ts module [23:48:04 CET] <JEEB> that is also open source of course [23:48:11 CET] <JEEB> so watches are very much pelcome [23:49:45 CET] <void09> I'm not a coder [23:49:54 CET] <void09> well, i am, but a very noob/slow/limited one [23:52:21 CET] <JEEB> ah, right [23:52:33 CET] <JEEB> libavformat/mpegts.c actually has no seek function [23:52:51 CET] <JEEB> thus it is the general libavformat framework trying to come up with wtf to do [23:52:52 CET] <JEEB> :) [23:53:40 CET] <JEEB> you could in theory add a seek function that then attempts to do things, but that can lead to fun side effects [23:54:34 CET] <void09> [h264 @ 0x5576bbd3f3c0] error while decoding MB 0 30, bytestream 2375 [23:54:47 CET] <void09> ok, what does that mean.. i used debug_ts [23:55:10 CET] <void09> or this: [h264 @ 0x5576bbbc3c80] error while decoding MB 109 63, bytestream 2037 [23:55:12 CET] <JEEB> that is unrelated to debug_ts, just an error while trying to get an image decoded from a video packet [23:55:28 CET] <JEEB> if that happens outside of start and end of stream, it might be bafd [23:55:55 CET] <JEEB> (becuase live stremas can start and stop at random points) [23:56:00 CET] <void09> oh wait you are right.. so debug_ts did NOTHING [23:56:11 CET] <void09> maybe because i ran it on an mkv ? [23:56:24 CET] <JEEB> debug_ts will give you full debug lines of ffmpeg.c passing things around [23:56:34 CET] <JEEB> so you can see with what sort of timestamps it read a packet [23:56:42 CET] <JEEB> how it passed it on/normalized it etc [23:56:55 CET] <JEEB> since at one point you were asking about exact packet logging [23:56:56 CET] <void09> ffmpeg -v error -debug_ts -i "file.mkv" -f null - 2>test2.log [23:56:58 CET] <JEEB> for timestsamps etc [23:57:00 CET] <void09> have i used it wrong ? [23:57:25 CET] <JEEB> void09: a lot of -debug_ts logging is under normal info log level [23:57:35 CET] <JEEB> so if you limit yourself to errors or more important only [23:57:39 CET] <JEEB> you do not get them :P [23:58:14 CET] <void09> ohhh [23:58:21 CET] <JEEB> anyways, g'night. if you need indexing packet copying, do that through either mp4 or mkv in hte middle [23:58:34 CET] <void09> right, thanks a bunch for .nfo [00:00:00 CET] --- Fri Nov 22 2019

1 0

ffmpeg-devel.log.20191120
by burek 21 Nov '19

21 Nov '19

[00:16:41 CET] <cone-157> ffmpeg 03Michael Niedermayer 07master:d73f06270600: avcodec/dvdec: Use av_clip_uint8 instead of ff_crop_tab [03:42:28 CET] <cone-636> ffmpeg 03James Almer 07release/4.2:8da31e9eef6d: avcodec/cbs_av1: fix reading reference order hint in skip_mode_params() [03:42:28 CET] <cone-636> ffmpeg 03James Almer 07release/4.2:252ef2329a53: avcodec/cbs_av1: keep separate reference frame state for reading and writing [03:42:28 CET] <cone-636> ffmpeg 03Mark Thompson 07release/4.2:82a3a623f012: cbs_h264: Fix missing inferred colour description fields [03:57:26 CET] <mkver> Is side data of type AV_PKT_NEW_EXTRADATA actually supposed to be padded like normal extradata? I presume it is intended, but it doesn't seem to be stated anywhere. [03:59:43 CET] <mkver> av_packet_new_side_data() (which is used by av_packet_copy_props() and therefore by av_packet_ref()) at least allocates all side data with padding. [04:11:20 CET] <BBB> mkver: yes, and should probably be documented explicitly that it needs to be padded identical to normal extradata [04:11:54 CET] <mkver> Ok. The only place where this is not so seems to be in libavcodec/tests/avpacket.c [11:26:33 CET] <cone-677> ffmpeg 03Paul B Mahol 07master:e21d4a7ca43e: avfilter/vf_chromakey: add >8 bit support [13:17:50 CET] <cone-677> ffmpeg 03Paul B Mahol 07master:a16de215c917: avfilter/af_rubberband: fix sample overqueueing [15:25:34 CET] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:dbc50f8a9350: avformat/matroskadec: Fix default value of BlockAddID [15:53:07 CET] <cone-677> ffmpeg 03Michael Niedermayer 07master:19b8db2908bf: avcodec/atrac9dec: Check precision_fine/coarse [15:53:08 CET] <cone-677> ffmpeg 03Michael Niedermayer 07master:faea5b4462c4: avformat/vividas: Add EOF check in val_1 loop in track_header() [15:53:09 CET] <cone-677> ffmpeg 03Michael Niedermayer 07master:c8c17b8cef77: avcodec/sonic: Fix integer overflow in predictor_calc_error() [15:53:10 CET] <cone-677> ffmpeg 03Michael Niedermayer 07master:b6abdb1faf81: avcodec/ra288: Check block_align for the assumed value [15:53:11 CET] <cone-677> ffmpeg 03Michael Niedermayer 07master:dc3f327e7403: avcodec/apedec: Fixes integer overflow of res+*data in do_apply_filter() [15:53:12 CET] <cone-677> ffmpeg 03Michael Niedermayer 07master:e36ccb5048f0: avcodec/qdm2: The smallest header seems to have 2 bytes so treat 1 as invalid [15:53:13 CET] <cone-677> ffmpeg 03Michael Niedermayer 07master:7fc1baf0ca83: avcodec/vc1_block: Fix undefined behavior in ac prediction rescaling [15:53:14 CET] <cone-677> ffmpeg 03Michael Niedermayer 07master:c54b9fc42fee: avcodec/wmadec: Require previous exponents for reuse [15:53:15 CET] <cone-677> ffmpeg 03Michael Niedermayer 07master:1b7d02642b20: avcodec/ralf: use multiply instead of shift to avoid undefined behavior in decode_block() [15:53:16 CET] <cone-677> ffmpeg 03Michael Niedermayer 07master:f09151fff9c7: avcodec/atrac3: Check for huge block aligns [15:53:17 CET] <cone-677> ffmpeg 03Michael Niedermayer 07master:a1f8b36cc454: avcodec/iff: Move index use after check in decodeplane8() [17:48:09 CET] <cone-677> ffmpeg 03Paul B Mahol 07master:176ac987aa25: avfilter/f_graphmonitor: output frames in pts gaps [18:36:03 CET] <cone-677> ffmpeg 03Alex Mogurenko 07master:b6571777d28d: avcodec/mjpegbdec: Fix yuv444 pix_fmt detection [19:49:46 CET] <thardin> does VLC use its own demuxers or does it use lavf? or both? [19:50:19 CET] <JEEB> both [19:50:28 CET] <JEEB> for a lot of common things it has its own [19:50:49 CET] <JEEB> but you can also --demuxer=avformat or whatever the parameter was. and less common things will end up in avformat [19:51:08 CET] <JEEB> mp4, matroska, mpeg-ts, etc at least have vlc's internal demuxers [19:51:22 CET] <thardin> I'm going to guess it doesn't have its own mxf demuxer [19:52:39 CET] <JEEB> would initially look like that, yes http://git.videolan.org/?p=vlc.git;a=tree;f=modules/demux;h=7b55ad195c655c5… [22:42:14 CET] <cone-783> ffmpeg 03Paul B Mahol 07master:7ead0daa24f0: avfilter/vf_median: add support for commands [00:00:00 CET] --- Thu Nov 21 2019

1 0

ffmpeg.log.20191120
by burek 21 Nov '19

21 Nov '19

[01:19:51 CET] <jaevanko> 6:11:34 PM - Hello, I am trying to use ffmpeg to copy blu-ray discs and it's doing that job quite well. However, I can't find a way to include the chapters and language tags from the disc in my output. Is there a way to do this? [03:14:29 CET] <gp> Is there a trick to passing -strict experimental through the hls segmenter? https://dpaste.de/jJJ6 [03:15:14 CET] <JEEB> welcome to meta (de)muxers [03:15:32 CET] <JEEB> it's possible, I think the dash one might already pass that value down [03:15:38 CET] <JEEB> but yes, the author needs to remember to do it :P [03:15:58 CET] <gp> Should I file a ticket? [03:16:42 CET] <JEEB> libavformat/dashenc.c: ctx->strict_std_compliance = s->strict_std_compliance; [03:16:48 CET] <JEEB> so the dash thing does it, hls one doesn't [03:17:04 CET] <gp> I seek out trouble =) [03:17:07 CET] <JEEB> although I'm still confuzzled why *both* let you get HLS and DASH [03:17:33 CET] <JEEB> and thus you have two muxers that seemingly do similar htings, but still different things [03:18:07 CET] <JEEB> I think those should be just put into a single code module, and then they should just export both hls and dash from there as synonyms more or less :P [03:18:25 CET] <JEEB> that way if something is broken or fixed, it gets done in both [03:19:18 CET] <gp> can't argue with that [03:20:31 CET] <DHE> <gp> I seek out trouble =) # that does not begin to describe what some people (like me) get into [03:21:14 CET] <gp> DHE: haha the struggle is real [03:44:53 CET] <gp> oops forgot to mention - opened ticket at https://trac.ffmpeg.org/ticket/8388 [04:11:49 CET] <rfer> Does anyone know of a way for ffmpeg or ffplay to error check an encoded H.264 video stream as though the decoder was limited to a specific level or profile? [04:12:22 CET] <rfer> other than checking the field in the SPS [05:37:57 CET] <gp> rfer: You could use ffprobe - It lists the level and profile with json output [05:38:13 CET] <rfer> that just reads the SPS, no? [05:38:32 CET] <rfer> i want to see if specific frames are not respecting what the stream stated in its SPS [05:39:16 CET] <gp> rfer: ah - not sure how to help - you can get a detail frame print out too but I don't think it will give you what you're asking [05:54:31 CET] <rfer> it might indirectly [05:54:47 CET] <rfer> alternatively, is there a way to list out how many reference frames the current frame refers to? [05:55:06 CET] <cehoyos> rfer: FFmpeg is not a stream analyzer [05:55:22 CET] <cehoyos> Stream analyzers exist, they are apparently very expensive [05:55:54 CET] <cehoyos> The information about the number of reference frames is likely trivial to output, patch probably welcome [05:56:15 CET] <cehoyos> I am not sure if it is as easy to check for (complete) level compliance [06:01:28 CET] <rfer> aw damn, was hoping that something might've already existed that I missed in the flag docs [06:03:11 CET] <rfer> in that case i'll probably just end up waiting for a patch from a teammate tomorrow lol, was trying to work around a blocker and test something. thanks for confirming cehoyos [06:05:42 CET] <cehoyos> Hardware developers told me once that they do not garantee real-time encoding for a given level. If this is correct (I cannot know) and given the fact that levels have no relevance for software decoders, I doubt the whole concept [06:06:09 CET] <cehoyos> And especially checking for exact compliance [08:04:19 CET] <BeerLover> When too use -map and when to use -var_stream_map? [08:04:56 CET] <BeerLover> ffmpeg -i song.mp3 -b:a:0 320k -b:a:1 128k -b:a:2 64k -b:a:3 32k -c:a aac -map 0:a:0 -map 0:a:0 -map 0:a:0 -map 0:a:0 -f hls -var_stream_map "a:0 a:1 a:2 a:3" -master_pl_name master.m3u8 -hls_time 10 -hls_segment_filename 'pk/%v/segment%05d.ts' -hls_list_size 0 pk/%v/index.m3u8 [08:05:22 CET] <BeerLover> I want to create 4 bitrate hls playlist and a master.m3u8 [08:18:41 CET] <jemius> What's the best way to extract a single foto from a video stream? Just taking a single frame results in terrible quality [08:20:26 CET] <th3_v0ice> What is the command you used to extract that single frame? [08:26:30 CET] <jemius> ffmpeg -i video.avi -vf scale="320x240" fps=25 frames/c01_%04d.jpeg [08:30:38 CET] <th3_v0ice> Do you need it scaled down? Or why are you using the -vf scale filter? Picture at that resolution cant look that good. [08:32:43 CET] <jemius> Was just an experiment. The resolution is only 560x480 anyways [08:33:24 CET] <jemius> the thing is that video codecs consist of poorer images than a still standing jpeg, because the eye can't see as much details when things moove. I want to have a sharp picture anyways [08:40:16 CET] <th3_v0ice> Well, you are correct about the details and the eye. But whatever decoder gave you is the picture it reconstructed from the available data and, to my knowledge, it can't be better then that. [08:41:12 CET] <jemius> but let's say the camera filmed a statue for 5 seconds without moving. This means I have a lot of frames. Can't I use them to for example reduce noise and increase sharpness? [08:44:37 CET] <pink_mist> I'm sure it's possible to come up with an algorithm for that, sure ... but is there one implemented by regular video codecs? [08:45:30 CET] <pink_mist> and would it waste huge amounts of cpu time calculating such an algorithm without even being told to [08:46:00 CET] <th3_v0ice> Photoshop seems to be able to do that https://www.slrlounge.com/take-high-quality-still-image-video-ease-photosho… [08:46:50 CET] <pink_mist> yeah, the correct tool for this is something other than ffmpeg [08:48:41 CET] <jemius> hmm :( [10:08:30 CET] <squ> exposure does that [10:08:42 CET] <squ> increase it for still object [11:59:51 CET] <kab0m> hi at all [12:00:01 CET] <kab0m> Im trying to wrap my head around one thing and i hope you guys maybe ca help me by this...i have to export ALL tags from one audiofile(flac) and need to import them into another audiofile(m4a) in my bashscript. Does anyone know how this can be done? tia [15:38:01 CET] <Fyr> guys, why does $ffmpeg -h encoder=flac not show compression_level? [15:38:10 CET] <Fyr> is it only my version? [15:41:45 CET] <JEEB> Fyr: looking at master the internal flac encoder does not have such avoption [15:41:48 CET] <JEEB> https://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=blob;f=libav… [15:42:31 CET] <Fyr> JEEB, why is it absent? [15:42:49 CET] <JEEB> wasit ever there? [15:43:33 CET] <Fyr> JEEB, the online FFMPEG help contains such a parameter. [15:45:50 CET] <JEEB> ok, it's a global lavc context property [15:45:56 CET] <JEEB> not an avoption [15:46:30 CET] <JEEB> https://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=blob;f=libav… [15:46:36 CET] <Fyr> I see [15:48:25 CET] <JEEB> unfortunately since all properties are always available to all encoders, you can't really list in the -h encoder what it takesin [15:49:02 CET] <JEEB> did not btw know we had such a lavc context property :D [15:49:11 CET] <JEEB> the more i know [16:33:07 CET] <matto312> Hello! I need some direction. I'm new to video work, but am an experienced developer. [16:33:08 CET] <matto312> From FFMPEG, I need constant HLS output, but sometimes my input may drop so I need to be able to replace inputs on the fly (maintaining constant HLS output.) [16:33:08 CET] <matto312> I know this might not be able to be done in ffmpeg. Does anyone have suggestions on how to approach this requirement? [16:34:31 CET] <JEEB> matto312: your API client (be it ffmpeg.c or otherwise) would have to a) have a concept of time and b) be able to generate a secondary input [16:35:03 CET] <JEEB> libavfilter does have a filter that can switch from one input to another, *but* that lacks any understanding of time or how to switch back [16:35:46 CET] <JEEB> on the other hand, something like upipe has nice realtime support for back-up sources (be it generated or otherwise), but it is geared towards broadcast and thus you would have to write the HLS output in it [16:39:06 CET] <matto312> Thx, upipe sounds interesting [16:40:00 CET] <bencoh> I wrote a hls backend back when I worked for the company that started the upipe project, by the way [16:40:14 CET] <SpiritHorse> bencoh: neat [16:40:21 CET] <bencoh> upipe was definitely comfortable for that [16:41:54 CET] <bencoh> (what was really neat was seeing iOS tablets keep a/v properly synced after days of playback with our streams, while streams produced by industry-standard encoders desynced in a noticeable fashion after a few hours) [16:42:52 CET] <bencoh> matto312: if you're going the upipe way, you should have a look at the upipe-videocont pipe [16:43:42 CET] <bencoh> it basically does what you're looking for (combined with upipe_video_blank, and/or other video sources) [16:43:47 CET] <bencoh> (same for audio by the way) [16:43:50 CET] <matto312> Thx bencoh was just looking at upipe and it may be too complex for me [16:44:21 CET] <bencoh> aww, that's sad then (but I know what you mean ... :) [16:44:51 CET] <JEEB> yes, you have to write your own thing for it. ffmpeg.c is actually something where you can get scarily far with ffmpeg.c, but then when you start getting layers of meta-muxers and I/O [16:45:12 CET] <JEEB> or the fact that FFmpeg by itself as a framework has no concept of real time [16:45:18 CET] Action: bencoh nods [16:46:13 CET] <JEEB> which is why FFmpeg's libraries cannot "buffer for X seconds" for example. you can do that in your API client, but the core libs have no concept of time :P [16:47:48 CET] <JEEB> and yea, ffmpeg.c is a general thing that tries to do a lot of stuff on a general level. that is then why it as an API client doesn't attempt to use time etc [16:48:05 CET] <JEEB> it would actually make sense to have a separate API client which is for live [16:48:16 CET] <JEEB> since the realities of live input(s) is quite different [16:48:48 CET] <JEEB> unfortunately I don't have unlimited free time and energy :D [16:49:02 CET] <bencoh> :) [16:49:42 CET] <matto312> JEEB: stupid question, but what do you mean by "API client" [16:49:51 CET] <JEEB> matto312: FFmpeg itself is a set of libraries [16:50:01 CET] <JEEB> ffmpeg.c which most people know as the `ffmpeg` command is just one API client [16:50:11 CET] <JEEB> just the same way someone can make an API client for their own use case [16:50:18 CET] <matto312> JEEB: understood, thx [16:50:19 CET] <JEEB> there's plenty of stuff that ffmpeg.c does not handle. [16:50:34 CET] <JEEB> like, the API lets you figure out when the stream configuration of an MPEG-TS input changes [16:50:44 CET] <JEEB> ffmpeg.c has no code for that (yet) [16:50:58 CET] <bencoh> well, regarding that, in upipe time management is mostly handled by the eventloop (say, libev, or any user-supplied eventloop assuming it's glued to framework). [16:51:05 CET] <JEEB> partially because that would mean that you'd have to add the concept of "which program are we following right now" [16:51:24 CET] <bencoh> upipe then mostly deals with metadata (timestamps) to keep track of time, apart from source/sink pipes that fire timers (making use of the eventloop again) [16:51:42 CET] <JEEB> bencoh: yea, so I guess you can note that some input hasn't gotten stuff in, say, 250ms [16:51:51 CET] <bencoh> exactly [16:51:55 CET] <JEEB> and then if that happens, you can switch to backup until you start getting stuff from primary [16:52:31 CET] <bencoh> in matto312's case (and mine back then), upipe_blank_source outputs a blank frame (or a picture, whatever) every 40ms [16:52:43 CET] <JEEB> yup [16:52:58 CET] <bencoh> upipe_videocont has a finite number of content inputs, and a 'default' input (which is connected to blank_source output) [16:53:14 CET] <bencoh> the default input acts as a clock source, ie a trigger to output a frame [16:53:35 CET] <matto312> JEEB: for someone with experience using upipe, how low do you estimate would take to set up? [16:53:36 CET] <bencoh> assuming current content input queue is empty, it will output the "default input" latest frame [16:54:15 CET] <JEEB> matto312: I haven't been able to test it yet because of priorities and availability of free time :) [16:54:32 CET] <JEEB> so I only have a slight idea of what upipe can provide [16:55:39 CET] <matto312> nw, doubtful there is enough time on this project for me to learn upipe [16:56:51 CET] <JEEB> do you have your own FFmpeg API client already or are you just (ab)using ffmpeg.c so far? [16:59:57 CET] <matto312> I was just pulled on this project, right now the setup goes: live RTMP input => FMPEG (running on EC2) to transcode into multi-variant HLS stream => send to AWS MediaPackage + AWS Cloudfront ... the RTMP input occasionally will drop and may resume [17:01:44 CET] <matto312> I'm stuck trying to find reliable way to handle input loss [17:03:00 CET] <JEEB> since you didn't reply I will guess you're just (ab)using ffmpeg.c [17:03:23 CET] <JEEB> you will either have to come up with a local thing that provides a constant source that switches between your RTMP and a back-up thing [17:03:32 CET] <JEEB> or you code into ffmpeg.c or so handling of actual real time [17:03:56 CET] <JEEB> as in, "if you didn't receive stuff from this input in f.ex. 250ms, switch to the back-up one which generates a stable stream" [17:03:58 CET] <matto312> I think so, installed latest ffmpeg package on ubuntu [17:04:19 CET] <BtbN> problem with rtmp is, it can be bursty [17:05:13 CET] <bencoh> you'll need to buffer / smooth it out then [17:05:34 CET] <bencoh> ie add a player-like component in between (that outputs at playback rate) [17:05:42 CET] <matto312> We are using RTMP, but I think there is also HLS input that could be used [17:06:06 CET] <BtbN> that's bursty by design [17:06:10 CET] <bencoh> :) [17:06:46 CET] <matto312> :) I'm still learning the domain of video work [17:07:13 CET] <JEEB> but yea, there's literally two alternatives: you build handling of switching of realtime inputs into ffmpeg.c, or you write a separate thing in front of ffmpeg.c, which handles providing a smooth thing to ffmpeg.c that never ends [17:07:19 CET] <Mavrik> Restreaming HLS with HLS just sounds like a recipe for insane amounts of lag :D [17:07:20 CET] <BtbN> It's generally not really sensibly possible to do what you intend to do. Since it's close to impossible to determine if the stream dropped or is just lagging. [17:07:38 CET] <matto312> Mavrik: agreed [17:07:38 CET] <Mavrik> BtbN: unless you have some kind of realtime guarantees [17:07:46 CET] <BtbN> With rtmp or hls? [17:07:52 CET] <Mavrik> With whatever input [17:08:01 CET] <Mavrik> If you're doing live streaming and haven't seen a packet in 500ms [17:08:03 CET] <BtbN> rtmp and hls are very much not realtime [17:08:08 CET] <Mavrik> You can assume that your players will drop that anyway :P [17:08:26 CET] <BtbN> 500ms can be all within the encoders re-ordering delay though [17:08:28 CET] <Mavrik> As protocols no. But it depends on what your source is. [17:08:44 CET] <bencoh> separating it from ffmpeg probably means transcoding twice, though [17:08:49 CET] <Mavrik> If you're restreaming a live TV channel, not seeing data packets for awhile will have the same effect no matter the inherent burstiness of your input. [17:09:16 CET] <BtbN> depends on the size of your local buffer [17:10:31 CET] <JEEB> bencoh: not really. I'd probably do raw video/audio over NUT or something if I really had to have the stuff separate (like localhost UDP multicast or whatever) [17:11:17 CET] <bencoh> I always considered using nut as an intermediate format for that kind of use, but never went for it in the end :) [17:11:47 CET] <JEEB> although I still consider it a bit more eww than handling it in your API client [17:12:02 CET] <JEEB> but raw v/a with NUT is probably the least bad alternative [17:12:03 CET] <bencoh> definitely [17:12:19 CET] <bencoh> (definitely eww :D) [17:12:38 CET] <bencoh> (but yeah, less eww than real transcoding) [17:14:27 CET] <JEEB> yea, doing it locally means you don't have to do transcoding on that layer [17:14:37 CET] <JEEB> since no network involved [17:17:13 CET] <BeerLover> When too use -map and when to use -var_stream_map? ffmpeg -i song.mp3 -b:a:0 320k -b:a:1 128k -b:a:2 64k -b:a:3 32k -c:a aac -map 0:a:0 -map 0:a:0 -map 0:a:0 -map 0:a:0 -f hls -var_stream_map "a:0 a:1 a:2 a:3" -master_pl_name master.m3u8 -hls_time 10 -hls_segment_filename 'pk/%v/segment%05d.ts' -hls_list_size 0 pk/%v/index.m3u8 [17:18:27 CET] <JEEB> BeerLover: var_stream_map is an AVOption exposed by various output modules [17:18:36 CET] <JEEB> in this case the HLS meta-muxer [17:18:52 CET] <JEEB> map is ffmpeg.c's option that maps inputs for an output [17:19:20 CET] <BeerLover> I want to create 4 bitrate hls playlist and a master.m3u8 [17:19:21 CET] <JEEB> easiest to explain is to check the output of `ffmpeg -h muxer=hls` [17:19:41 CET] <JEEB> then you can see that var_stream_map is a HLS module option, not an ffmpeg.c option [17:19:58 CET] <JEEB> so that is the difference between the two things :P [17:20:43 CET] <JEEB> BeerLover: the stream numbers you set in var_stream_map are from those that you have mapped to the HLS muxer output [17:21:57 CET] <BeerLover> JEEB do i need -re option. In examples, they have used -re everywhere. [17:22:08 CET] <JEEB> -re is an ffmpeg.c option that simulates real-time [17:22:22 CET] <JEEB> as in, it makes ffmpeg.c sleep the difference of timestamps of input packets [17:22:32 CET] <JEEB> otherwise ffmpeg.c will go as fast as your input goes [17:22:48 CET] <JEEB> it is also error-prone because timestamps do not always end up going forwards at the point where -re reads them :P [17:29:20 CET] <kepstin> if your input is already realtime, the -re option can make ffmpeg run slower than your input, causing buffering or desync issues, or even connection dropping in some cases. [17:29:52 CET] <BeerLover> for local files, examples are using -re [17:31:30 CET] <kepstin> the -re option is specifically to support streaming local files (or other vod type inputs) as if they were live/realtime inputs, yeah. [17:43:36 CET] <rockyh> hello! [17:44:30 CET] <rockyh> Yesterday we talked about conversions from smpte2084 to bt709. I had now a doubt about another issue: having a video with this features [17:44:39 CET] <rockyh> Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default) [17:44:50 CET] <BeerLover> kepstin i want to convert mp3 to hls and store them in S3. Then clients will pull from there [17:45:15 CET] <rockyh> how is it possible to lower its resolution to 1920x1080, but preserving *all* the other video features? (yuv420p10le(tv, bt2020nc/bt2020/smpte2084)) [17:45:33 CET] <DHE> but are you streaming them to users in realtime, or for their convenience to listen whenever from start to finish? [17:46:32 CET] <JEEB> rockyh: use scale or zscale to just scale it down, and it shouldn't do anything else to the video. then make sure the encoder you're utilizing can flag those things (trc, primaries etc) [17:47:33 CET] <rockyh> JEEB: if I use just `-vf scale=1920:1080', colors are altered, as if ffmpeg picked some defaults which are different from (yuv420p10le(tv,bt2020nc/bt2020/smpte2084) [17:47:53 CET] <BeerLover> JEEB they can listen anytime [17:47:56 CET] <JEEB> please post -v verbose full uncut terminal output and link it here [17:49:00 CET] <JEEB> ok, x264 seems to pass avctx->color_trc as is to vui.i_transfer in libx264, libx265 has some checks but seems to support it too? [17:49:10 CET] Action: JEEB tests by encoding a bit of his godzilla sample [17:51:59 CET] <furq> i've always needed to explicitly set -colorspace -color_trc -color_primaries with ffmpeg and x264 [17:52:24 CET] <JEEB> I've had it work but unfortunately it in various cases currently seems to require that [17:52:45 CET] <JEEB> because it doesn't initialize the encoder with the correct things (when it gets the first AVFrame that would have the correct metadata) [17:52:57 CET] <furq> this was just for downscaling a 1080p bluray, so nothing fancy [17:53:10 CET] <JEEB> this was the same thing [17:53:15 CET] <JEEB> essentially [17:53:17 CET] <furq> fun [17:53:39 CET] <rockyh> it took a little bit: https://pastebin.com/kDE0mxQ3 [17:54:17 CET] <JEEB> ok, seems like either lavfi drops the information, or the encoder gets init too early [17:56:34 CET] <JEEB> http://up-cat.net/p/e7b18b8c [17:56:38 CET] <JEEB> let's see if this looks correct [17:56:57 CET] <JEEB> it indeed did not set the correct metadata for libx264 if I didn't set those [17:57:36 CET] <rockyh> in my case, the original video is x265 (and I would like to keep this also in the output if it's possible) [17:57:57 CET] <JEEB> yea, I just had libx264 around to test in this build :P [17:58:15 CET] <rockyh> ok :) [17:58:23 CET] <JEEB> ok, seems correct enough so FFmpeg didn't quak it too badly [17:58:47 CET] <JEEB> the encoder probably gets initialized too early, and thus there is no data to fill the lavc context with [17:58:59 CET] <JEEB> in theory you could reconfigure it with the first AVFrame received [17:59:10 CET] <JEEB> but I haven't had too much luck trying to get that to work with libx264's reconfigure :D [17:59:21 CET] <JEEB> in theory it should work because nothing has been output yet [17:59:26 CET] <JEEB> since nothing has been fed to the encoder yet [18:00:02 CET] <JEEB> vlc seems to try initializing the encoder in init() (and then breaks it down), and then actually initializes the encoder as the first frame is received [18:02:53 CET] <rockyh> uhm I'm not sure I understood. Is this an ffmpeg problem, or it generate a correct file and then the player "misundertands" it? [18:03:01 CET] <rockyh> s/generate/generates [18:03:55 CET] <JEEB> rockyh: if you look at my example, video wise even if the -color_* were removed the actual content is correct, but the H.264 stream would not have the correct color metadata, and thus players show it as standard BT.709/gamma [18:05:16 CET] <JEEB> ok, tested without the filter chain as well, and even then it doesn't properly propagate [18:05:42 CET] <JEEB> so ffmpeg.c sets the encoder values at a point where it doesn't yet know the colorspace etc of the input [18:06:04 CET] <furq> rockyh: if you already encoded the whole thing then you can set those flags with -bsf hevc_metadata [18:06:10 CET] <JEEB> yes [18:06:27 CET] <furq> https://www.ffmpeg.org/ffmpeg-bitstream-filters.html#hevc_005fmetadata [18:06:33 CET] <JEEB> in other words, it's a metadata problem in the video stream, not actual content [18:07:43 CET] <rockyh> oh, ok, got it and this is already a little relief [18:08:45 CET] <rockyh> BTW using the explicit settings in your paste, `-color_trc smpte2084 -colorspace bt2020_ncl -color_primaries bt2020', the output video is correctly played [18:09:05 CET] <JEEB> yes, because it's now properly flagged in the stream :) [18:09:40 CET] <JEEB> I really think we should support more encoder configuration on the first fed AVFrame :/ [18:09:49 CET] <JEEB> since they contain the metadata as well [18:10:11 CET] <furq> yeah that'd be nice [18:10:17 CET] <rockyh> furq: so IIUC I can set the flags also after the encoding with just `-vf scale=1920:1080', using the linked page and `-bsf' [18:10:29 CET] <furq> yeah [18:10:52 CET] <furq> that filter doesn't support constants though so afaik you need to pull the values from the hevc spec [18:10:55 CET] <JEEB> I looked into this at some point, and it seems like the simplest answer is to just wait with the actual initialization until the first AVFrame [18:10:56 CET] <furq> at least i needed to do that with h264 [18:10:58 CET] <rockyh> wonderful! [18:11:30 CET] <JEEB> I guess lavc context values would be preferred if set to something else than undefined, and otherwise configure it according to the first AVFrame [18:11:42 CET] <furq> https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.265-201906-I!!PDF… [18:12:03 CET] <JEEB> or I get x264/x265 reconfig working [18:12:38 CET] <JEEB> (which I did try once and I didn't get the darn thing to bulge since I think I didn't change something enough - and yes, I was patching x264 as well to try and make sure that would cause a reconfig) [18:13:14 CET] <JEEB> alternatively, only init the lavc context when the frame is to be passed to it [18:13:59 CET] <furq> -i foo.mkv -map 0 -c copy -bsf:v hevc_metadata=colour_primaries=9:transfer_characteristics=16:matrix_coefficients=9 bar.mkv [18:14:02 CET] <furq> i think that should be right [18:15:38 CET] <rockyh> thanks :), I would never had been able to find them in the ITU document (even if I downloaded it!) [18:16:32 CET] <furq> the bsf docs do at least mention the section of the spec to look at [18:16:39 CET] <furq> so that's nice of them [18:18:13 CET] <rockyh> furq: actually it generated this error in my x265 file https://pastebin.com/FZNgHfeD [18:18:30 CET] <furq> oh [18:18:38 CET] <furq> yeah obviously you need h264_metadata for h264 [18:20:26 CET] <rockyh> but my file is h265 [18:20:56 CET] <furq> the pastebin from a minute ago is outputting h264 [18:21:03 CET] <furq> the default encoder for mkv is x264 if you don't set one [18:27:20 CET] <rockyh> oh, ok, I made some confusion during the encoding. I had used `ffmpeg -i input.mkv -vf scale=1920:1080 -c:a copy output.mkv' without specifying x265, so output.mkv had x264 encoding [18:28:37 CET] <rockyh> instead, with `ffmpeg -i ctest.mkv -c:v libx265 -vf scale=1920:1080 -c:a copy output.mkv', I can then use `ffmpeg -i output.mkv -map 0 -c copy -bsf:v hevc_metadata=colour_primaries=9:transfer_characteristics=16:matrix_coefficients=9 output2.mkv' to correct metadata [18:29:18 CET] <rockyh> thank you so much to both! JEEB furq (again, now all it's more clear, even for a newbie like me!) [18:31:55 CET] <furq> rockyh: if you're encoding anyway then just set it up front with -colorspace etc [18:32:01 CET] <furq> there's no need for a second pass [18:32:14 CET] <JEEB> the bsf is just to fix past mistakes [18:32:17 CET] <furq> right [18:33:29 CET] <rockyh> yes, of course, got it [20:04:36 CET] <jemius> is there a shortcut to replace a video's audio stream? My way of first storing without audio and then muxing is a bit slow [20:05:15 CET] <JEEB> two inputs, map what you need from each [20:05:18 CET] <kepstin> jemius: something like "ffmpeg -i original.mp4 -i newaudio.mp4 -map 0:v -map 1:a -c copy output.mp4" [20:05:36 CET] <jemius> kepstin, I have the audio as .flac [20:05:46 CET] <kepstin> add additional maps if needed to preserve subtitle tracks or multiple audio or whatever, change encoder options if needed. [20:06:25 CET] <kepstin> right, then you'll probably need to set -c:a to something that works in your output container, if you don't want to leave it as flac. [20:14:46 CET] <jemius> mhm, mapping isn't exactly intuitive [20:19:59 CET] <kepstin> it's pretty straightforwards? the option is "-map" followed by a stream specifier. Every stream that matches the stream specifier will be included in the output. If you specify -map multiple times, they all apply, in order. [20:20:28 CET] <kepstin> so my command says "grab the video tracks from input 0", then "grab the audio tracks from input 1" [20:24:01 CET] <jemius> and what would happen if file contains more than one audio stream? [20:24:43 CET] <kepstin> read the stream specifiers doc for detail, but my description already says what happens. Note that I pluralized "tracks". [20:25:14 CET] <kepstin> you can use more specific specifiers if you want to grab one particular track. [20:25:45 CET] <kepstin> https://www.ffmpeg.org/ffmpeg.html#Stream-selection is the doc in question [20:42:41 CET] <jemius> awkward, if I mux the files the audio is early by ~0.5 s [20:55:19 CET] <friendofafriend> I'm getting decode_slice_header error" [20:56:53 CET] <friendofafriend> Drat, sorry. I'm getting "decode_slice_header error", "non-existing PPS 0 referenced", "decode_slice_header error", and "no frame!" errors when trying to play video streaming from ffmpeg to ffplay. Why do these error messages occur, and why can ffplay play the resulting stream but not VLC or mplayer? [20:58:25 CET] <JEEB> friendofafriend: that means that the stream you're feeding it hasn't yet given enough information to the decoder to produce an image [20:58:38 CET] <JEEB> usually meaning that there hasn't been initialization data yet [20:58:53 CET] <JEEB> PPS/SPS are those things that contain initialization data for the decoder [20:59:03 CET] <JEEB> so if you don't have those yet the decoder is not going to bulge [20:59:19 CET] <JEEB> alternatively, the stream is broken/corrupted [21:00:10 CET] <JEEB> if these warnings/errors happen at the beginning and then go away it just means that you started from a position where there was not initialization data at first [21:00:19 CET] <JEEB> and then you have to wait for the stream to contain that for the next time [21:02:09 CET] <friendofafriend> Thank you, JEEB! Those messages eventually go away and ffplay doesn't show them again, but other players just seem to hang when trying to load the stream. I can even copy the stream to a file, and ffplay will play it and other players don't. [21:02:56 CET] <JEEB> so yes, you probably started reading the stream not from the very beginning [21:03:21 CET] <JEEB> and the initialization data is first at the start, and later at following random access points [21:03:41 CET] <JEEB> modern video encoders default to like 250 frames max duration between random access points for compression [21:03:53 CET] <JEEB> so that can take very easily seconds [21:04:32 CET] <friendofafriend> Indeed, it does take quite a while to start. Longer then the -g option would suggest. [21:04:46 CET] <friendofafriend> The command I'm using is something like this: ffmpeg -i rtsp://1.2.3.4:5000/example -vsync 1 -content_type video/mp4 -c:v libx264 -g 5 -map 0 -f h264 -preset medium -profile:v main -x264opts "keyint=5:min-keyint=5:no-scenecut" -tune zerolatency icecast://source:password@localhost:8000/test.mp4 [21:05:04 CET] <johnjay> JEEB: not sure if this is ffmpeg but is there a way to convert a file to .SRT? [21:05:27 CET] <JEEB> johnjay: if it is text subtitles and readable by FFmpeg, yes? [21:05:28 CET] <johnjay> the file is like TIMECODE\nSubtitle\nTIMECODE\nSubtitle but this program wont' accept it [21:06:10 CET] <JEEB> ffmpeg -v verbose -i BLAH out.srt [21:06:18 CET] <JEEB> if BLAH is readable by FFmpeg [21:08:15 CET] <johnjay> well i didn't think ffmpeg read subtitle files [21:08:22 CET] <johnjay> but in any event it says no stream [21:09:07 CET] <johnjay> when i try on a modified srt file i made it says Invalid Data found when processing input [21:10:04 CET] <johnjay> ah i see. it does take the original unmodified srt file [22:45:57 CET] <johnjay> well a quick perl script solves that problem [22:48:49 CET] <cehoyos> johnjay: More than a dozen different subtitle file formats are supported by FFmpeg [22:49:34 CET] <johnjay> cehoyos: maybe an existing format matches it, i'm not sure [22:49:57 CET] <johnjay> this file is just like 00:10\n hello there\n 00:15\n how are you?\n [22:50:12 CET] <johnjay> but the player i'm on only accepts srt [22:50:37 CET] <cehoyos> Please provide a sample file if FFmpeg does not support the subtitle format. [22:51:09 CET] <johnjay> you mean like a literal file? [22:51:18 CET] <johnjay> this is the format youtube does all downloaded subs in [22:51:22 CET] <johnjay> so they are all like that [22:51:58 CET] <johnjay> again i might be ignorant and maybe there's a subtitle format that matches that [22:52:05 CET] <cehoyos> If the format is not supported by FFmpeg, please provide a sample file [22:53:52 CET] <johnjay> ok... [22:53:58 CET] <johnjay> for example this is the file given from youtube for this video [22:54:00 CET] <johnjay> https://paste.ubuntu.com/p/gyD9Y4ctfK/ [22:54:06 CET] <johnjay> https://www.youtube.com/watch?v=Pnhxz0learg [22:54:31 CET] <furq> how did you download it [22:54:36 CET] <johnjay> you don't [22:54:44 CET] <johnjay> you click on the ... and choose Open Annotation [22:54:44 CET] <furq> how did you get it then [22:54:49 CET] <johnjay> then you have to highlight the text yourself [22:54:57 CET] <johnjay> er Open Transcript [22:55:13 CET] <furq> what ... [22:55:15 CET] <cehoyos> Which software supports this format? [22:55:18 CET] <johnjay> on the lower right of the video [22:55:25 CET] <johnjay> by the Share and Save buttons [22:55:44 CET] <furq> oh right [22:55:53 CET] <furq> yeah that's not a real subtitle format [22:56:04 CET] <johnjay> i don't know. i think youtube confusingly demands you upload subs in .srt format [22:56:04 CET] <johnjay> so i don't know why they don't provide .srt [22:56:24 CET] <johnjay> is it similar to any existing formats? [22:56:27 CET] <johnjay> i thought maybe webvtt [22:56:31 CET] <furq> use youtube-dl --write-sub for real CCs or --write-auto-sub for the autogenerated ones [22:57:41 CET] <johnjay> furq: i'm trying it on that video. it says it's writing vtt? [22:57:48 CET] <furq> yeah that makes sense [22:58:18 CET] <furq> also --skip-download if you just want the subs [22:58:27 CET] <cehoyos> The format is trivial and could be supported... [22:58:43 CET] <furq> it's not a real format though [22:58:54 CET] <furq> he just copied and pasted it off the video page [22:59:18 CET] <cehoyos> It looks like a format to me... [22:59:32 CET] <cehoyos> I just downloaded it myself [22:59:46 CET] <furq> if you mean the one youtube-dl gives you then that's webvtt [22:59:49 CET] <furq> that's already supported [22:59:52 CET] <johnjay> well youtube does that for all videos [23:00:05 CET] <johnjay> so idk if that makes it a "format" but it it is common [23:00:09 CET] <cehoyos> No, the one that is provided by youtube without using third-party tools;-) [23:00:11 CET] <johnjay> i download transcripts for language learning [23:00:18 CET] <nicolas17> copying formatted text from a webpage and pasting it as plaintext could give different results (whitespace) depending on the browser [23:00:22 CET] <furq> right [23:00:35 CET] <johnjay> i'm using chromium [23:00:40 CET] <cehoyos> We ignore whitespace for subtitles [23:00:43 CET] <furq> if there's a way to actually have it send you a plaintext subs file then i'd consider that a format [23:00:57 CET] <johnjay> well it just displays it in a window on the right i think [23:01:37 CET] <johnjay> my usecase is i'm learning a foreign language so i run the transcript through a translator [23:01:50 CET] <johnjay> then use an extension to show the english subs next to the foreign ones [23:02:00 CET] <johnjay> but the extension only takes srt oddly [23:02:09 CET] <nicolas17> convert from webvtt [23:02:44 CET] <furq> yeah ffmpeg will do vtt to srt no problem [23:02:52 CET] <furq> apparently --sub-format srt will work for some videos but not on this one [23:03:03 CET] <furq> maybe that's an auto captions thing, idk [23:03:12 CET] <johnjay> well now i can do that since furq showed me how. thanks [23:03:15 CET] <johnjay> ! [23:03:24 CET] <johnjay> yes i use auto captions [23:03:33 CET] <johnjay> they aren't perfect but are suitable for the purpose [23:03:51 CET] <johnjay> anyhow i already wrote a perl script to do this so either way i'm set [23:37:30 CET] <GuiToris> hello, a 500mib, 22-minute long, 1080p x265 video is rather big, isn't it? [23:43:38 CET] <furq> depends what's in it [23:43:44 CET] <furq> it's not that big though [23:46:34 CET] <GuiToris> furq, I used -preset veryslow and -crf 29 [23:46:51 CET] <GuiToris> the source is a png sequence [23:47:06 CET] <GuiToris> also -pix_fmt yuv420p [23:47:19 CET] <GuiToris> how could I make it even smaller? [23:47:27 CET] <GuiToris> (without sacrificing the quality) [23:51:05 CET] <GuiToris> I'm not sure but I think video files are smaller when they are created with kdenlive (melt maybe) [23:57:11 CET] <Atlenohen> in before youtube adds yuv444 [23:57:53 CET] <Atlenohen> *whistle* ... [23:58:47 CET] <Atlenohen> But, in seriousness, if there was some thing in one industry, something that would make 420 just not work, maybe they can do enough pressure on youtube for that option [23:59:02 CET] <Atlenohen> heck 422 would be a start [23:59:18 CET] <GuiToris> I'm not going to upload this to yt, if that's what you meant [23:59:45 CET] <Atlenohen> Nah I'm just commenting generally on my lack of mood of youtube's 420 [23:59:54 CET] <GuiToris> oh okay [00:00:00 CET] --- Thu Nov 21 2019

1 0