October 2019 - Ffmpeg-devel-irc

ffmpeg-devel.log.20191005
by burek 06 Oct '19

06 Oct '19

[07:33:32 CEST] <Compn> wonder if i should post a patch for webpage [07:33:37 CEST] <Compn> or if anyone wants to review it [07:33:47 CEST] <Compn> news entry [08:58:33 CEST] <Compn> CyberShadow, are the committed photosensitivity defaults the same as your original patch defaults? [08:58:43 CEST] <Compn> seems to be different somehow from my memory [08:59:11 CEST] <CyberShadow> Compn, I'm sorry, I haven't been following [08:59:26 CEST] <Compn> your filter is in ffmpeg now [08:59:42 CEST] <CyberShadow> I noticed, but I haven't found the time for this project lately. [08:59:47 CEST] <Compn> no problem [08:59:58 CEST] <Compn> i am going to post some news about it, hopefully draw some attention :) [09:00:53 CEST] <Compn> do you still have the sample videos and comparisons you made? [09:01:11 CEST] <CyberShadow> Alright. Also, I would still like to try working on an improved version at some point, so if anyone finds videos where it could work better that would be helpful [09:01:21 CEST] <CyberShadow> I do [09:01:37 CEST] <Compn> could you make them available again? i can mirror them on ffmpeg now [09:01:49 CEST] <Compn> i should have done 7 months ago doh! [09:01:54 CEST] <Compn> also i will ask for samples that fail [09:02:01 CEST] <CyberShadow> Yes, but they're non-free. The main thing I was testing against was Cowboy Bebop [09:03:23 CEST] <Compn> thats ok about copyright [09:04:01 CEST] <CyberShadow> Up at http://89.28.117.31:8081/ again [09:06:42 CEST] <Compn> ok i got it all (nice fast speeds) thanks [09:32:04 CEST] <Compn> CyberShadow, ok news entry is up on ffmpeg.org [09:37:06 CEST] <CyberShadow> Compn, I don't know if it matters but I did make the filter for someone with photosensitive epilepsy. The feedback I got was generally "good but not perfect", but also, they have been sometimes much more or less sensitive depending on the time, so there wasn't much data to make sense of [09:38:50 CEST] <Compn> That is good info, I just didnt want to make it sound like we did scientific research on it [09:39:11 CEST] <Compn> if you want i can change it ? [09:39:11 CEST] <CyberShadow> I agree, and for that reason it might be worth leaving the text as is [09:39:20 CEST] <Compn> no problem :) [09:42:03 CEST] <Compn> i went looking for other products or filters like this and did not see any [09:42:20 CEST] <Compn> there was a blue filter for computer monitors, or eye glasses with yellow tint etc [09:42:49 CEST] <Compn> possibly a tool to evaluate flashes in media as well, but not a realtime filter [09:43:17 CEST] <Compn> i think this could be very useful CyberShadow . very happy that you worked on it. [09:43:45 CEST] <Compn> the realtime graph is also a good tool [09:53:11 CEST] <smallishzulu> Hi everyone, I have quick question. about err_detect flag (err_recognition). Is the default value for this is AV_EF_CAREFUL or AV_EF_CRCCHECK ? [10:01:24 CEST] <Compn> smallishzulu, wait for answer :) [10:01:29 CEST] <Compn> for now i need sleep, night [11:22:09 CEST] <cone-911> ffmpeg 03Paul B Mahol 07master:7da57875b570: avformat/mpeg: better fix for MLP versus PCM-DVD misdetection [23:39:15 CEST] <Lynne> holy shit it runs [23:39:20 CEST] <Lynne> an int32 fft! [23:39:23 CEST] <Lynne> and mdct! [23:39:50 CEST] <Lynne> its too quiet because the butterflies are half scale but!!! [23:41:50 CEST] <JEEB> 'grats [23:45:26 CEST] <Lynne> it took 2 defines, BF and CMUL, CMUL of which was already properly done [23:45:50 CEST] <Lynne> and MIPS had to NIH in their FFT instead of properly using the existing templating [23:49:18 CEST] <sparky8251> any able to review https://patchwork.ffmpeg.org/patch/15492/ for me? I work on a project impacted by this bug and a member sent in this fix [23:49:49 CEST] <sparky8251> he didnt make an issue or anything. first time weve contributed to ffmpeg as a project. unsure if we are following proper procedure and such [23:52:36 CEST] <JEEB> well you have a patch on the ML so you have done something right [23:53:56 CEST] <sparky8251> well, thats good to hear! [00:00:00 CEST] --- Sun Oct 6 2019

1 0

ffmpeg.log.20191005
by burek 06 Oct '19

06 Oct '19

[00:02:41 CEST] <DHE> well the second transcodes. the first just copies the existing audio [00:04:40 CEST] <snatcher> DHE: transcodes to what and why? [00:04:56 CEST] <Diag> well arent you adding text? [00:06:59 CEST] <DHE> traditionally transcodes to the default codec as specified by the output file format, and because that's the default and you didn't override it [00:37:41 CEST] <furq> does chromaprint even work with -c:a copy [00:37:49 CEST] <furq> i thought the library required pcm [01:19:27 CEST] <snatcher> /dev/shm/FILENAME doesn't work as value for filename= of signature filter while regular path works, is it bug? [01:19:59 CEST] <snatcher> typo, nevermind [01:57:13 CEST] <snatcher> i give up, don't understand chromaprint muxer at all, how can i get fingerprint of audio stream from video in binary format? tried: ffmpeg -y -loglevel fatal -f mp4 -vn -i FILE -f chromaprint - | base64 -d >BIN, seems doesn't work because outputs incorrect base64, or > Base64 compressed fingerprint (default) [01:57:27 CEST] <snatcher> means something more than base64? [01:59:07 CEST] <snatcher> or chromaprint muxer is broken, can anyone test it please? ffmpeg version 4.2 [02:24:08 CEST] <snatcher> segmentation fault with -f chromaprint -algorithm 2, looks deprecated/broken [02:45:57 CEST] <taliho> snatcher: if you get a segfault you should post a ticket on ffmpeg trac [02:48:35 CEST] <furq> you should probably report -fp_format not working as well [02:50:14 CEST] <snatcher> furq: what about broken base64 output? [02:50:26 CEST] <Atlenohen> Hello [02:50:50 CEST] <Atlenohen> it is possible with FFMPEG to concat many video files but insert text between them directly with ffmpeg [02:51:18 CEST] <Atlenohen> custom text, but filename works as I only want between each video the TITLE of the video [02:51:47 CEST] <Atlenohen> But without having to painstakingly use a video editor to do every video title manually [02:52:23 CEST] <taliho> snatcher: I tried ./ffmpeg -i input_file.mp4 -acodec pcm_s16be -f chromaprint out [02:53:16 CEST] <taliho> seems to work for me, I confirm I got a segfault with -algorithm 2 option [02:54:12 CEST] <taliho> to be clear.. the command above seems to work for me. But, I confirm got a segfault with -algorithm 2option [02:55:26 CEST] <snatcher> taliho: does (base64 -d out >outbin) work for you? [02:58:53 CEST] <furq> are you sure you don't want pcm_s16le [02:59:47 CEST] <snatcher> furq: pcm_s16le doesn't make any difference while ffmpeg outputs incorrect base64 [03:00:45 CEST] <snatcher> *not base64 [03:00:59 CEST] <taliho> my machine is little endian, so yes it makes more sense [03:01:58 CEST] <taliho> snatcher: I'm reading base64 option [03:03:18 CEST] <snatcher> taliho: it's not option, it's shell command where out is your ffmpeg command out and outbin should be valid binary fingerprint [03:05:25 CEST] <snatcher> also i think -acodec doesn't make any difference because i tried on flac file and same flac with some changed bytes and got the same checksum for _broken_ (not base64) output [03:09:59 CEST] <taliho> snatcher: I would have to have a look at what is done in the code [03:10:56 CEST] <taliho> if I pipe output to base64 -d then I get invalid input. becase input is not in base64 [03:11:32 CEST] <furq> https://github.com/ffmpeg/ffmpeg/blob/master/libavformat/chromaprint.c#L143 [03:11:38 CEST] <furq> it's just calling libchromaprint [03:12:08 CEST] <furq> so i guess check if that works first [03:12:19 CEST] <taliho> in ffmpeg options there is a base64 option with chromaprint, which suggests you need to set it to get a base64 output [03:12:47 CEST] <snatcher> taliho: default one [03:12:56 CEST] <furq> yeah that's the last argument to chromaprint_encode_fingerprint [03:14:29 CEST] <snatcher> furq: fpcalc from libchromaprint works(?) [03:15:25 CEST] <furq> fun [03:15:36 CEST] <taliho> but base64 is default value [03:15:49 CEST] <taliho> so something looks off to me [03:16:03 CEST] <snatcher> https://github.com/acoustid/chromaprint/blob/1839652b3ff5aaf124cf20fccc8ecd… [03:16:34 CEST] <furq> i wouldn't be massively surprised if ffmpeg is at fault, it looks like this file has been touched once since it was added four years ago and that was just to update the chromaprint version check [03:17:14 CEST] <furq> but you should obviously triple check before submitting a bug report [03:18:36 CEST] <furq> [chromaprint muxer @ 0x7fffc60deac0] Unable to parse option value "base64" [03:18:37 CEST] <furq> nice [03:24:00 CEST] <taliho> furq: yeah have the same issue [03:24:16 CEST] <snatcher> what will happen with chromaprint support if no one will fix it? removal? [03:25:45 CEST] <furq> someone will probably just fix it [03:40:09 CEST] <snatcher> is there a way to extract all audio streams to separate files automatically? [03:40:33 CEST] <snatcher> *from video [05:06:07 CEST] <taliho> snatcher: furq: I've at least found the bug that doesn't allow to set fp_format options [05:06:24 CEST] <taliho> i'll send it to the mailing list in a bit [07:23:33 CEST] <taliho> snatcher: It's possible that the output chromaprint is in url save version where / are replaced by _ [07:23:57 CEST] <taliho> sorry *safe not save [07:24:43 CEST] <taliho> I tried replacing _ with / in the output of ffmpeg and base64 -d seems to work [15:40:09 CEST] <taliho> :snatcher did you see my message about chromaprint? [16:22:14 CEST] <snatcher> taliho: still base64: invalid input [16:23:07 CEST] <taliho> can you paste the base64 output? [16:24:11 CEST] <snatcher> taliho: https://clbin.com/uyztO [16:27:38 CEST] <snatcher> taliho: generated with: ffmpeg -i 1.flac -acodec pcm_s16le -f chromaprint out [16:31:38 CEST] <taliho> I wonder if it just doesn't like the new line character at the end [16:36:11 CEST] <snatcher> no, same result after: tr -d '\n' [16:38:43 CEST] <snatcher> i think it's not base64 encoded fingeprint somehow, just plain one, if so don't know why ffmpeg plain fingerprint much bigger than fpcalc -plain one [16:51:56 CEST] <taliho> snatcher: i'm quite sure it's something with new lines [16:51:58 CEST] <taliho> try this [16:52:47 CEST] <taliho> echo "hello" | base64 | base64 -d [16:52:50 CEST] <taliho> this works [16:52:55 CEST] <taliho> but [16:54:28 CEST] <taliho> ignore my message above :) [16:57:40 CEST] <taliho> :snatcher another option is that you could do base64 yourself [16:57:50 CEST] <taliho> ./ffmpeg -loglevel trace -y -i input_file.mp4 -vn -acodec pcm_s16le -f chromaprint -fp_format raw - | base64 [16:59:41 CEST] <taliho> :snatcher I posted a patch for parsing raw option, because it doesn't work at the moment [16:59:43 CEST] <taliho> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-October/251029.html [17:01:57 CEST] <taliho> :snatcher if you don't want to apply the patch, you could the same with [17:02:33 CEST] <taliho> ffmpeg -loglevel trace -y -i input_file.mp4 -vn -acodec pcm_s16le -f chromaprint -fp_format 0 - | base64 [17:08:05 CEST] <relaxed> for tidiness you may want ... -fp_format 0 - 2>ffmpeg.log | base64 [17:24:07 CEST] <void09> how to cut at precise time without re-encoding the whole video, just the first and last frames leading to their nearest keyframe ? [17:34:13 CEST] <taliho> :snatcher ok, the issue is that chromaprint is using "URL and filename safe version" of base64 and so it contains "underscore" and "-" [17:34:15 CEST] <taliho> https://tools.ietf.org/html/rfc4648#section-5 [18:22:11 CEST] <Atlenohen> Hello [18:22:27 CEST] <Atlenohen> is it possible to use ffmpeg to insert automatically some kind of text between concated videos? [18:23:16 CEST] <Atlenohen> or if that won't be possible, what if I just insert some transitional effect or a transitional short clip between videos, if not filename title text, at least it separates them apart [18:23:32 CEST] <Atlenohen> they're multiple videos like 30, but short, want them all in one file for convenience [18:24:29 CEST] <tdr> couldn't you make an image/frame, turn that into a very short clip, then use the clip(s) as part of your concat process? [18:25:18 CEST] <tdr> it would be more manual since you'd have to specify order / where to put the middle clips, but should be doable [18:42:29 CEST] <Atlenohen> I'd like to avoid reconversion and painstakingly manually doing the titles one by one [18:43:59 CEST] <relaxed> transcoding will be necessary unless they were encoding the same exact way [18:44:52 CEST] <relaxed> encoded* [18:46:23 CEST] <relaxed> as tdr said, script using the filenames to create a short video with that text to concat in between the videos [18:48:06 CEST] <relaxed> look at the drawtext filter [18:56:18 CEST] <Atlenohen> ah ok will take a look [18:59:05 CEST] <relaxed> Atlenohen: remember to add a silent audio track to them in order to concat with the other videos [19:11:56 CEST] <Atlenohen> concat unsafe filename? [19:11:59 CEST] <Atlenohen> minus signs? [19:14:52 CEST] <Atlenohen> looks like it's about quotes in this case [19:18:32 CEST] <Atlenohen> looking at https://stackoverflow.com/questions/38996925/ffmpeg-concat-unsafe-file-name [19:18:41 CEST] <Atlenohen> i have "file D:\ ... [19:18:44 CEST] <Atlenohen> not sure [19:18:49 CEST] <Atlenohen> not quotes [19:26:44 CEST] <relaxed> you added -safe 0? [20:03:39 CEST] <taliho> :snatcher you can recreate what chromaprint is doing [20:03:51 CEST] <taliho> ffmpeg -loglevel trace -y -i input_file.mp4 -vn -acodec pcm_s16le -f chromaprint -fp_format compressed - 2>/dev/null | base64 [20:04:24 CEST] <taliho> ffmpeg -loglevel trace -y -i input_file.mp4 -vn -acodec pcm_s16le -f chromaprint -fp_format base64 - 2>/dev/null [20:06:20 CEST] <taliho> are the same except "/" -> "underscores" and "+" -> "-" [20:06:46 CEST] <taliho> also base64 in bash adds padding with == at the end [20:14:42 CEST] <Atlenohen> I did try safe too yeah [20:14:48 CEST] <Atlenohen> I'll be back later, gtg [20:43:46 CEST] <taliho> :snatcher I also fixed a bug when writing with raw format... ffmpeg was truncating the output by 4 before [20:43:55 CEST] <taliho> it would be great if you could try this branch: [20:43:57 CEST] <taliho> https://github.com/talih0/FFmpeg/tree/chromaprint_branch [20:44:20 CEST] <taliho> and I'll send the patchset this evening [20:47:32 CEST] <snatcher> taliho: thank you! also is "-acodec pcm_s16le" necessary? [21:12:51 CEST] <taliho> snatcher: I don't think it's necessary. I get the same output with or without it [22:16:01 CEST] <la_mettrie> adding the first piece of music to a video went well, but then i added another one to another time point and it started to complain "Non-monotonous DTS in output stream 0:1;" and the sound became borked. [22:16:08 CEST] <la_mettrie> i used this command: ffmpeg -i hk2.avi -itsoffset 00:00:12.6 -i hk-intro.raw -vcodec copy -acodec copy hk3.avi [22:16:11 CEST] <la_mettrie> what to do? [22:45:34 CEST] <void09> how to cut at precise time without re-encoding the whole video, just the first and last frames leading to their nearest keyframe ? [22:46:04 CEST] <void09> is there such a function ? or do you know of a script to implement it ? encoding should be done with the same settings as the input video [22:46:45 CEST] <DHE> that is not a built-in feature in ffmpeg. it would have to be implemented in code, and something has to be smart to read the parameters of the input video and match the encoding parameters and other things for this to be safe [22:52:12 CEST] <void09> i tried to encode the first 8 missing frames piece with different settings than the rest of the video, and concatenate them with ffmpeg.. the result was bad, gray frame, missing frames [00:00:00 CEST] --- Sun Oct 6 2019

1 0

ffmpeg-devel.log.20191004
by burek 05 Oct '19

05 Oct '19

[05:06:59 CEST] <cone-092> ffmpeg 03Andreas Rheinhardt 07master:581419ea39de: avformat/matroskadec: Fix demuxing ProRes [07:58:57 CEST] <cone-092> ffmpeg 03Daniel Kolesa 07master:1bdb47b73484: swscale: Replace illegal vector keyword usage in altivec code [07:58:58 CEST] <cone-092> ffmpeg 03Daniel Kolesa 07master:e6625ca41f85: swscale: Fix AltiVec/VSX build with recent GCC [15:06:46 CEST] <cone-479> ffmpeg 03Zhao Zhili 07master:7c145b64417f: FATE/dnn: fix stack buffer overflow [16:28:28 CEST] <Lynne> meanwhile twitch still doesn't have vp9 [00:00:00 CEST] --- Sat Oct 5 2019

1 0

ffmpeg.log.20191004
by burek 05 Oct '19

05 Oct '19

[00:05:56 CEST] <c_14> not that I know of [00:06:32 CEST] <brimestone> Not a book, but I found this awesome tutorial. https://github.com/brimestoned/ffmpeg-libav-tutorial [00:12:38 CEST] <pink_mist> found? the link makes it look like something you created [00:13:01 CEST] <brimestone> I forked it just in case it goes away.. [00:13:08 CEST] <pink_mist> ahh [00:13:15 CEST] <brimestone> Originally https://github.com/leandromoreira/ffmpeg-libav-tutorial [03:01:43 CEST] <analogical> does the mp4 container support the vp9 video codec? [03:03:09 CEST] <furq> yes [03:03:13 CEST] <furq> do players support it? probably not [03:53:41 CEST] <Kaedenn> I have an mjpeg video file that I'd like to add a title card to. [03:53:57 CEST] <Kaedenn> Text that fades in, displays for a few seconds, then fades out [03:54:57 CEST] <Kaedenn> Should I just generate the frames using some image program or can ffmpeg generate all this for me? [03:55:16 CEST] <Kaedenn> White text, black background, fixed durations for the fade in, display, and fade out. [13:52:38 CEST] <DanielTheKitsune> Hi there, what should be the ./configure options to allow me to compile/install ffmpeg sources into a custom directory? I already have the binary package provided by Debian, but it lacks some functions I need, and so, I want to have two ffmpeg builds (the Debian one and this custom one). [13:53:02 CEST] <DanielTheKitsune> let's say it's going to sit at /home/joe/ffmpeg/ [13:58:13 CEST] <DHE> well by default you get a static link (of the ffmpeg libraries), so you can just take the ffmpeg binary produced, rename it if need be, and copy it whereever you want and it should just work [13:58:39 CEST] <DHE> do you need more than just the main ffmpeg (and if applicable, ffprobe and ffplay) binaries installed? [13:59:56 CEST] <DanielTheKitsune> do I need to change the prefix or something? [14:00:26 CEST] <DanielTheKitsune> ffmpeg and the included libraries (of which I installed their -dev packages), that's all I need, I think [14:00:26 CEST] <kepstin> DanielTheKitsune: that depends on your answer to DHE's question [14:00:51 CEST] <DanielTheKitsune> only ffmpeg [14:01:18 CEST] <DanielTheKitsune> (and its corresponding tools) [14:01:49 CEST] <kepstin> right, then DHE's answer will work for you. [14:02:04 CEST] <DanielTheKitsune> ok, so no need to touch prefixes at all [14:02:18 CEST] <DanielTheKitsune> just ./configure <and link the proper libraries>, make and make install [14:03:28 CEST] <DHE> or just ./configure, make, cp ffmpeg /usr/bin # or whatever [14:04:17 CEST] <DanielTheKitsune> when I set the prefix to /home/joe/ffmpeg, it gets automatically moved to such directory during make install [14:04:43 CEST] <DanielTheKitsune> however, when I attempt to execute that specific binary, it appears to clash with the existing Debian build [14:05:51 CEST] <DanielTheKitsune> like, WARNING: Library configuration mismatch [14:06:05 CEST] <DanielTheKitsune> first it shows the configure options correctly [14:06:54 CEST] <DanielTheKitsune> after the warning, it shows the configure options of the Debian build instead, exactly 8 times repeated [14:07:06 CEST] <DanielTheKitsune> and it behaves like the Debian build instead [14:07:26 CEST] <DanielTheKitsune> what did I do wrong, exactly? [14:07:45 CEST] <DHE> sounds like a dynamic library build of ffmpeg found the libs from the wrong version it was built against [14:08:28 CEST] <DanielTheKitsune> how can I force it to use its own libraries instead? [14:08:41 CEST] <DanielTheKitsune> (so as not to use the Debian build ones) [14:08:53 CEST] <DHE> well did you run ./configure --enable-shared ? [14:08:58 CEST] <DanielTheKitsune> no [14:09:11 CEST] <pink_mist> you'll either want to build it statically or change the order ld looks through directories for libraries to load [14:09:25 CEST] <DanielTheKitsune> the only "strange" thing I do is to add --prefix=/home/joe/ffmpeg [14:09:27 CEST] <pink_mist> or perhaps use rpath magic, but that would also require rebuilding afaik [14:09:47 CEST] <DHE> I believe it requires a relink at least [14:09:47 CEST] <DanielTheKitsune> how do I build statically? [14:09:57 CEST] <DanielTheKitsune> yeah, I won't mind having to recompile [14:10:02 CEST] <DHE> well that's the thing. I figured it would have been if you didn't specify --enable-shared or --disable-static [14:10:14 CEST] <DHE> the actual installed ffmpeg binary should be fairly large, like 20 megabytes [14:10:58 CEST] <DanielTheKitsune> the executable itself I just compiled is 275 KB, dang [14:11:06 CEST] <DanielTheKitsune> no wonder why is it failing [14:11:07 CEST] <DHE> well that's definitely a shared lib [14:11:51 CEST] <DanielTheKitsune> now, how do I enforce static linking? somehow the shared lib thing was enabled without notice [14:12:36 CEST] <DanielTheKitsune> in fact, neither --enable-shared or --disable-static are found in the configure options when I compiled the thing [14:12:39 CEST] <DHE> in your build dir, is there a .so file or a .a file named libavcodec.* under the directory libavcodec [14:12:45 CEST] <DanielTheKitsune> yeah [14:12:50 CEST] <DHE> this might be the linker selecting system libs over specified libs [14:13:22 CEST] <DanielTheKitsune> wait [14:13:24 CEST] <DanielTheKitsune> hrm [14:13:30 CEST] <DanielTheKitsune> cd .. [14:13:32 CEST] <DanielTheKitsune> ls [14:13:35 CEST] <DanielTheKitsune> oops [14:13:38 CEST] <pink_mist> lol [14:13:44 CEST] Action: DHE needs to have that XKCD on macro [14:14:19 CEST] <DanielTheKitsune> such dir only exists on include/ dir [14:14:48 CEST] <DanielTheKitsune> and then, only .h files are present [14:14:50 CEST] <DanielTheKitsune> *there [14:15:18 CEST] <DHE> that's not the source code to ffmpeg. that's the ffmpeg-dev package contents. you looking in /usr/include ? [14:15:23 CEST] <DanielTheKitsune> libavcodec.so is in the lib directory [14:15:36 CEST] <DanielTheKitsune> DHE: nah, in my own build [14:15:46 CEST] <DanielTheKitsune> so where should I stare at [14:16:16 CEST] <DHE> the directory where you unpacked ffmpeg or checked out some git code. there should be a configure script in front of you [14:16:39 CEST] <DanielTheKitsune> right [14:17:07 CEST] <DHE> ls libavcodec/libavcodec.* [14:17:24 CEST] <DanielTheKitsune> yes, both .so and .a files exist [14:17:52 CEST] <DHE> okay, that's probably why [14:18:07 CEST] <DanielTheKitsune> what should I do with them [14:18:28 CEST] <DHE> what's the timestamps on the files? [14:18:48 CEST] <DHE> are they identical? or is the .so much older? [14:18:55 CEST] <DanielTheKitsune> for the .a file, October 2 [14:19:18 CEST] <DanielTheKitsune> for the .so.58 file (where the .so is symlinked to) is Sep 26 [14:19:47 CEST] <DHE> rm */*.so* ffmpeg_g ffmpeg ; make ffmpeg [14:19:49 CEST] <DanielTheKitsune> the .a file is 103 MB, the .so is 62 MB [14:20:09 CEST] <DanielTheKitsune> oh, should I really destroy every .so file? [14:20:23 CEST] <DHE> in the ffmepg build directory, yes [14:20:28 CEST] <DanielTheKitsune> ok [14:20:38 CEST] <DHE> obviously not from /usr/lib[64] or anything [14:21:02 CEST] <DanielTheKitsune> hrm [14:21:12 CEST] <DanielTheKitsune> ok, removed the specified files [14:21:18 CEST] <DanielTheKitsune> so only make ffmpeg? [14:21:49 CEST] <DHE> for now, yes [14:21:56 CEST] <DanielTheKitsune> ok, nice [14:21:57 CEST] <DHE> just needs a relink [14:22:11 CEST] <DanielTheKitsune> and then, all I needed was to ./ffmpeg (and do my own business there) [14:22:52 CEST] <DanielTheKitsune> yeah, no library clashing anymore, now I just need to test if it encodes amr-nb files (which is what I actually compiled it for) [14:24:24 CEST] <DanielTheKitsune> huh, I appear to forget syntax, -encoders will help [14:25:14 CEST] <DanielTheKitsune> oh, I just needed _ instead of - [14:26:00 CEST] <DanielTheKitsune> yeah, it works, thanks, really, you saved my day :D [14:26:18 CEST] <DHE> /usr/share/Adobe/doc/example/android_vm/root/sbin/ls.jar: Error: Device is not responding [14:26:21 CEST] <DHE> cool that works [14:27:04 CEST] <DanielTheKitsune> how do I disable smart resample dither/noise? [14:27:31 CEST] <DanielTheKitsune> so ffmpeg tries to do a dumb resample instead of smartly introducing noise to hide the effects of resample [14:29:49 CEST] <durandal_1707> see aresample and swresample options [14:29:55 CEST] <furq> -dither_scale 0 [14:30:10 CEST] <DanielTheKitsune> yeah, indeed, amr_nb definitely does what I want: hyper low bitrate and still audible quality [14:30:28 CEST] <furq> did you try opus [14:30:57 CEST] <DanielTheKitsune> yeah, unsupported by my dumbphone [14:30:57 CEST] <furq> or is 6kbps too much [14:31:00 CEST] <furq> oh fun [14:31:31 CEST] <DanielTheKitsune> the same dumbphone records .AMR from microphone, presumably hardware-encoded by the 2G controller [14:32:02 CEST] <DanielTheKitsune> look for "NYX xyn306", that's my dumbphone, appears to be exclusively sold in one country tho [15:16:11 CEST] <phobosoph> hi channel [15:16:15 CEST] <phobosoph> you were very helpful btw [15:16:27 CEST] <phobosoph> the webcam got h264+, but sadly youtube doesn't like the keyframe frequency [15:16:36 CEST] <phobosoph> although it is 60, which means for 30fps, 2 keyframes/sec [15:16:40 CEST] <phobosoph> youtube tells me it wants 4 or less [15:16:51 CEST] <phobosoph> well, I disabled h264+ and now I can manually specify the keyframe freq [15:45:25 CEST] <king09x> is it normal for the length of the adaptation field of an mpegts packet to be reported as larger than the packet itself? Can that field span multiple packets or must it fit within the 188 bytes? [17:41:26 CEST] <snatcher> what's the modern alternative to phash for video comparison? [17:43:32 CEST] <kepstin> snatcher: (joking, but) upload to youtube and see whether you get a content-id match [17:52:44 CEST] <snatcher> https://amiaopensource.github.io/ffmprovisr/index.html#generate_video_finge… hmm [17:56:11 CEST] <snatcher> how does it work? what's the right way to set compression level/get more compressed result? [17:57:38 CEST] <kepstin> huh, that's this filter https://www.ffmpeg.org/ffmpeg-filters.html#signature-1 I've never used it :/ [17:57:45 CEST] <kepstin> it has nothing to do with compression... [18:05:02 CEST] <snatcher> is there a such a thing for audio? [18:13:41 CEST] <kepstin> snatcher: take a look at https://acoustid.org/ maybe [18:20:51 CEST] <snatcher> seems so, ffmpeg supports chromaprint [19:21:57 CEST] <AndyAndyBoBandy> Hello! I'm using -ss and -to to extract segments of video files (with -c copy) and it's all great. But sometimes I'd like to cut a segment that is at the end of the video, and I'd rather not have to try to specify the final timestamp. I thought maybe `-to '-0'` would do the trick, but no. Is there another way to specify the final timestamp? [19:23:52 CEST] <TheAMM> Just don't specify it? [19:25:05 CEST] <AndyAndyBoBandy> TheAMM: ohh, without '-to' at all? Thanks! [19:29:40 CEST] <Diag> can/will ffmpeg do a video source type detection from input devices? [19:42:44 CEST] <kepstin> Diag: depends on the input device [19:43:02 CEST] <Diag> Yknow thats a goodass question [19:43:08 CEST] <Diag> pont* [20:12:07 CEST] <Diag> kepstin: is it possible to attempt to get it to list what the current mode of a dshow device is [20:16:25 CEST] <Diag> oh god im retarded [21:56:23 CEST] <snatcher> what's the difference between filter and muxer concepts? signature is filter while chromaprint is muxer, why? [22:01:45 CEST] <klaxa> a muxer works on bytestreams, a filter works on raw frames [22:03:29 CEST] <furq> you could probably implement a signature muxer or a chromaprint filter if you wanted to [22:04:01 CEST] <furq> i'm guessing chromaprint is a muxer because it sends the data to an external lib rather than doing it internally [22:04:19 CEST] <furq> not like that's a requirement obviously [22:14:27 CEST] <snatcher> https://ffmpeg.org/ffmpeg-formats.html#chromaprint-1 is fp_format option broken? [22:15:14 CEST] <snatcher> doesn't work for me in case: ffmpeg -i FILE -vn -f chromaprint -fp_format raw FILE.raw [22:16:17 CEST] <snatcher> https://clbin.com/XaxGN error related output [22:17:23 CEST] <snatcher> other options like an -algorithm works(? doesn't raise error at least) i think [22:28:55 CEST] <Diag> another stupid question [22:29:03 CEST] <Diag> can you set how the video is scaled in ffplay [22:33:42 CEST] <snatcher> hmm, is chromaprint even worth to compare audio? tried with 1.flac converted to 1.opus and end with different fingerprints between 1.opus and 1.flac [22:46:19 CEST] <snatcher> what's the shortest way to check if video has audio stream? [22:46:34 CEST] <BtbN> define shortest [22:46:44 CEST] <BtbN> least time? Shortest commandline? [22:46:51 CEST] <snatcher> BtbN: both [22:47:05 CEST] <BtbN> You can always just play the video and listen. [22:47:13 CEST] <BtbN> pretty fast, pretty short commandline [22:48:00 CEST] <BtbN> Or just ffprobe it and see if it lists any audio streams. [23:04:24 CEST] <kepstin> Diag: no, it's a super-simple player, it just uses SDL for the video window. [23:04:34 CEST] <kepstin> Diag: if you care, use a real player like mpv :) [23:04:40 CEST] <Diag> wow rude [23:04:44 CEST] <Diag> i want a refund [23:04:58 CEST] <kepstin> Diag: you can of course software scale the video with a filter and then display it with ffplay [23:05:03 CEST] <Diag> thats legit what i did lol [23:05:14 CEST] <Diag> it adds a small amount of latency though which, eh [23:05:35 CEST] <Diag> when im using it for what i want to use it for it wont matter if its scaled with nearest neighbor, so yaknow [23:06:40 CEST] <kepstin> ffplay is intended mostly as a combination of ffmpeg example application and a test program to reproduce issues and narrow down if they're in ffmpeg or a player application. It just happens to also work as a minimal standalone player. [23:07:13 CEST] <Diag> yee, i was just trying to get the lowest dshow latency as possible [23:07:20 CEST] <Diag> which it actually does [23:19:22 CEST] <cehoyos> Diag: I don't see the beginning of the discussion but you can also software-scale with ffplay [23:59:07 CEST] <snatcher> why output different for "-i INPUT -vn -map_metadata -1 -c:a copy -fflags +bitexact -flags:a +bitexact -f chromaprint OUTPUT" and "-i INPUT -vn -f chromaprint OUTPUT"? [00:00:00 CEST] --- Sat Oct 5 2019

1 0

ffmpeg-devel.log.20191003
by burek 04 Oct '19

04 Oct '19

[10:45:26 CEST] <cone-669> ffmpeg 03Paul B Mahol 07master:d492907e7817: avfilter/af_amix: fix filtering if specified weights are negative [11:24:50 CEST] <cone-669> ffmpeg 03Paul B Mahol 07master:8ca89e52df89: avfilter/f_streamselect: fix memleaks of pad names [12:04:16 CEST] <durandal_1707> when to use av_cold ? [12:06:55 CEST] <J_Darnley> durandal_1707: probably when the function will be called once at start or at end. [12:07:26 CEST] <J_Darnley> I wonder if there's an commnent about ti somewhere [12:09:23 CEST] <J_Darnley> "Did you use av_cold for codec initialization and close functions?" in doc/developer.texi [12:10:57 CEST] <J_Darnley> all I could find though [12:11:37 CEST] <cone-669> ffmpeg 03Paul B Mahol 07master:22f3b6286eaa: avfilter: add av_cold where it is missing [13:49:00 CEST] <kierank> durandal_1707: I think largely voodoo [13:53:14 CEST] <durandal_1707> kierank: av_cold is not voodoo [13:53:23 CEST] <kierank> almost certainly is [14:24:10 CEST] <cone-669> ffmpeg 03Paul B Mahol 07master:d0189f8d976f: avfilter/vsrc_sierpinski: add triangle type [15:07:13 CEST] <psycho_9> re [15:07:27 CEST] <psycho_9> is messaging on #ffmpeg blocked for some reason? [15:13:01 CEST] <thardin> could be freenode requiring registration again, due to spam [15:13:25 CEST] <psycho_9> oh, right... forgot about nick registration ;) [16:50:32 CEST] <atbd> hi, i'm currently working on DVB streams and adding data table (NIT, EPG for now) to ffmpeg. For now support is barebone: a data packet is formed and that's all. But I'd like to add decoding support for those data tables, does ffmpeg wants data decoder for them or do I make this out of ffmpeg ? [16:57:50 CEST] <J_Darnley> What ffmpeg structure could you decode them into? AVDictionary? [17:01:06 CEST] <atbd> I made structures describing tables/subtables/descriptors and store them in AVFrame::side_data for my tests [17:07:10 CEST] <atbd> I store only a pointer to the table which contains the others smaller struct [17:15:39 CEST] <kierank> I don't see how this can fit into ffmpeg at all [17:15:48 CEST] <kierank> they have nothing to do with AVFrame [17:22:01 CEST] <atbd> Can I expose those struct and public functions to parse those data packets through ffmpeg API ? [17:23:07 CEST] <kierank> imo defeats the point of ffmpeg to have MPEG-TS specific structures [17:23:13 CEST] <kierank> should use an mpegts demux library [17:23:31 CEST] <kierank> you could maybe have a demuxer callback api [17:23:36 CEST] <kierank> for metadata that isn't associated with a packet [17:23:40 CEST] <kierank> that could be used generically imo [17:40:47 CEST] <atbd> okay, thanks for the answer [17:41:02 CEST] <atbd> i'll try that [17:56:02 CEST] <mkver> cehoyos: Remember that flac ticket you wanted to open? Well, you don't need to. Both the serious as well as the bogus warnin message have the same cause. [17:56:41 CEST] <durandal_1707> mkver: which cause? [17:58:35 CEST] <mkver> An off-by-one error in find_new_headers: Instead of read_len = search_end - search_start + 1 it should be read_len = search_end - (search_start + 1) + 1; [17:58:54 CEST] <mkver> But only after wraparound. [17:59:23 CEST] <durandal_1707> patch welcome [17:59:54 CEST] <mkver> Yeah, I know and intend to do so. [18:01:08 CEST] <cone-711> ffmpeg 03Paul B Mahol 07master:93ea21f9b7cc: doc/filters: fix typo [18:09:11 CEST] <cehoyos> mkver: Thank you for the analysis! [19:17:46 CEST] <kierank> durandal_1707: wtf [19:17:48 CEST] <kierank> that bug report [21:34:50 CEST] <cone-437> ffmpeg 03Andreas Rheinhardt 07master:c548b0a4c67b: avformat/aiffenc: Use standard packet list functions [21:34:50 CEST] <cone-437> ffmpeg 03Andreas Rheinhardt 07master:c694fc575971: avformat/aiffenc: Fix potential memleak upon failure [21:34:50 CEST] <cone-437> ffmpeg 03Andreas Rheinhardt 07master:be0d3a2df1a1: avformat/aiffenc: Remove wrong and redundant check [21:34:50 CEST] <cone-437> ffmpeg 03Michael Niedermayer 07master:9b533de28eb1: avcodec/wmaprodec: Check if there is a stream [21:34:50 CEST] <cone-437> ffmpeg 03Michael Niedermayer 07master:2f588ccfb70c: avcodec/vc1_block: Fix invalid left shift in vc1_decode_p_mb() [21:34:51 CEST] <cone-437> ffmpeg 03Michael Niedermayer 07master:379e5d29d50e: avcodec/tiff: Set FF_CODEC_CAP_INIT_CLEANUP [00:00:00 CEST] --- Fri Oct 4 2019

1 0

ffmpeg.log.20191003
by burek 04 Oct '19

04 Oct '19

[06:57:03 CEST] <lain98> i'm trying to generate vp9 profile 1 videos with the command. ffmpeg -f lavfi -i color=c=blue:s=1280x720:d=3:r=60 -c:v libvpx-vp9 -profile:v 1 -vf "format=pix_fmts=yuv420p, drawtext=fontsize=64: fontcolor=white: font=monospace: x=(w-text_w)/2: y=(h-text_h)/2: r=60: text='%{frame_num}'" [06:57:24 CEST] <lain98> it says 420 format requires profile 0 or 2. [06:58:22 CEST] <lain98> oh okay i just figured it out. wikipedia has wrong information [06:58:46 CEST] <Gigabitten> *Where* is this channel publicly logged? [07:03:35 CEST] <furq> Gigabitten: https://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2019-September/date.html [07:04:52 CEST] <Gigabitten> found it myself just before you put that there but thank you very much [10:33:41 CEST] <karanveersingh> Need help with GPU transcoding [10:34:05 CEST] <karanveersingh> I am using tesla T4 GPU and below is the command [10:35:11 CEST] <karanveersingh> ffmpeg -hwaccel_device 1 -hwaccel cuvid -re -i Stranger02.mkv -c:v h264_nvenc -preset fast -b:v 10M -bufsize 20M -x264opts keyint=500 -pix_fmt yuv420p -f flv rtmp://194.167.137.11/live-test/Strange02_4k [10:36:10 CEST] <karanveersingh> Its 4k video than I am using , trying to transcode multiple 4k streams [10:36:39 CEST] <karanveersingh> Issue is I am only able to run 7 streams with no frame loss [10:37:12 CEST] <karanveersingh> As soon as I start 8 video , I start seeing frame loss [10:37:42 CEST] <karanveersingh> can anybody help me with correct parameters [10:37:58 CEST] <karanveersingh> i can also see some CPU utilization , is this expected ? [10:39:16 CEST] <karanveersingh> How many maximum live streams can be run with GPU ? [10:42:34 CEST] <karanveersingh> any help guys ? [11:10:34 CEST] <ponyrider> karanveersingh: maybe check here if you havent already? https://trac.ffmpeg.org/wiki/StreamingGuide [11:17:28 CEST] <karanveersingh> ponyrider , already check , it talks more about CPU codecs like libx264 , I need help with h264_nvenc [14:11:46 CEST] <mlok> Hello, is a python sub process call a good way of implementing ffmpeg in Python? [14:12:16 CEST] <mlok> or would it be preferred to use FFMPEG bindings in Python? [14:14:42 CEST] <c_14> shelling out to ffmpeg is probably easiest if that works for you [14:15:37 CEST] <pink_mist> yeah, use the easiest solution that actually works for your problem [14:15:45 CEST] <mlok> c_14: what would be a better way of doing this? [14:16:29 CEST] <mlok> pink_mist: hmm, would creating a daemon or service for the sub process call script work better? [14:16:35 CEST] <c_14> depends on your problem, if shelling out to the binary works for you it's the easiest way to go [14:16:52 CEST] <c_14> And the easiest one to get help for if/when you need it [14:16:52 CEST] <mlok> c_14: I need the script to be stable and not crash [14:17:17 CEST] <mlok> c_14: e.g. I need to do a large transcoding queue and it cannot crash [14:18:57 CEST] <c_14> I'm not sure I've had issues with ffmpeg crashing, the binary may error out if your input is corrupt or something, but that's up to you to catch the errors in your script [14:21:08 CEST] <mlok> c_14: I've had it freezing when transcoding an RTMP stream to HLS for instance [14:21:17 CEST] <mlok> c_14: when I scripted it in bash [17:38:44 CEST] <phenoxis> Hello.. I'm trying to stream fragmented-mp4 from ffmpeg onto a webpage's <video> tag using MSE. Clients may join inbetween, and should be able to receive the next fragment. To enable this, I'm saving the initialization segment (ftyp+moov) and sending this to all clients when they join. To a new client, the order of boxes they receive is as follows: [17:38:44 CEST] <phenoxis> ftyp->moov->moof->mdat->moof->mdat... However, the video does not play. `chrome://media-internals` reports the following: `Append: stream parsing failed. Data size=56424 append_window_start=0 append_window_end=inf` [17:45:09 CEST] <phenoxis> Is there something specific I need to do to get this to work? [17:45:29 CEST] <phenoxis> My command line at the moment is `-probesize 32 -stream_loop -1 -i sintel_trailer.mp4 -c:v libx264 -preset ultrafast -tune zerolatency -profile:v high -level 13 -g 10 -pix_fmt yuv420p -vsync 2 -c:a aac -ab 64k -strict -2 -f mp4 -profile:v high -movflags +frag_keyframe+empty_moov+omit_tfhd_offset+default_base_moof -reset_timestamps 1 -g 52 [17:45:30 CEST] <phenoxis> -frag_duration 100000 -` [17:53:17 CEST] <brimestone> Hey guys, how can I loop thru the content of AVDictionary? Using av_dict_get requires me to know the key ahead of time... [17:55:46 CEST] <brimestone> Ahh, if I give it black for the key it will output a vector.. [18:19:26 CEST] <brimestone> is there any quick way to get FPS value using AVFormatContext? [18:23:09 CEST] <cehoyos> Typically, there is no such thing;-( [18:23:29 CEST] <brimestone> some video fps are hidden [18:23:42 CEST] <cehoyos> But for some samples, avg_frame_rate is set [18:24:01 CEST] <cehoyos> They are not "hidden", the term is not defined for many formats. [18:24:09 CEST] <brimestone> yeah.. [18:24:21 CEST] <cehoyos> The time_base is always an upper limit for the framerate [18:24:34 CEST] <brimestone> This particular format im working on, its stored on ttime_base [18:24:35 CEST] <cehoyos> but it is 1000 for asf, and also fixed for other formats [18:24:49 CEST] <brimestone> asf? [18:25:00 CEST] <cehoyos> Used to be very common... [18:25:07 CEST] <cehoyos> but it is also fixed for mpegts [18:25:35 CEST] <cehoyos> https://en.wikipedia.org/wiki/Advanced_Systems_Format [18:25:47 CEST] <brimestone> Btw, im super stoked that im finally understanding how to use libav now.. [18:26:00 CEST] <brimestone> Took me years to keep tipping my toes into it [18:27:54 CEST] <kepstin> mkv/webm is technically not fixed, but it does have to be a power of 10 and most muxers use 1000 [18:28:47 CEST] <brimestone> I see [18:42:18 CEST] <brimestone> If want to create an audio level meter for a player application.. can I use libav for that? [20:54:40 CEST] <jpb> hi - question on ffplay - how can i get rid of the wide black borders on the left and right of the display window? [20:55:16 CEST] <jpb> i'm using overlays, and the border is much to wide... [21:04:33 CEST] <kepstin> jpb: ffplay just shows the video as it is - if there's borders, you've either resized the window to be wider than the video (in which case... don't do that) or the video itself has black borders [21:12:25 CEST] <jpb> hmmm... ok, so this is a mosaic (similar to the wiki example, but 3x3 instead of 2x2). i'm using ffmpeg to create the mosaic, but piping it to ffplay to display. https://pastebin.com/jjDLF4fZ [21:14:51 CEST] <jpb> xwininfo shows the resulting display is 1285x725. i'm perplexed :-( [21:15:50 CEST] <durandal_1707> jpb: your fault using overlay for mosaic [21:17:26 CEST] <jpb> is there a better way? [21:18:44 CEST] <durandal_1707> yes [21:39:38 CEST] <kepstin> jpb: the problem is that you've resized the window to be wider than the video. don't do that. [21:39:50 CEST] <kepstin> jpb: remove the -x and -y options from ffplay, those tell it to resize the window [21:44:14 CEST] <jpb> looks like i also want to look at the xstack filter. might be closer to what i want. [21:45:35 CEST] <jpb> kepstin: yep, there's a mistacke right there. i was so focused on the overlay bits i forgot to look at the ffplay command line. [21:45:45 CEST] <jpb> good catch [22:54:41 CEST] <jpb> looks like xstack is the way to go. [22:55:56 CEST] <TheSashmo> Has anyone seen a bug in HEVC decoding library in ffmpeg? I can see using a transport stream analyzer that the ES info is reported back as 1920x1080i but ffmpeg hevc decoder is showing a 1920x540 which would be half the resolution..... in fact even my stream analuzer decodes the video as 540 on the screen, it looks squashed, seems like a progressive/interlaced bug? [22:57:31 CEST] <TheSashmo> https://www.dropbox.com/s/69ueovnt6arjgi7/Screenshot%202019-10-03%2016.33.4… [22:58:53 CEST] <TheSashmo> https://www.dropbox.com/s/td1gnhgrhlrf4in/Screenshot%202019-10-03%2016.33.1… [22:59:14 CEST] <kepstin> TheSashmo: hevc doesn't really do interlaced, the ffmpeg decoder decodes each field as a separate half-height frame [22:59:29 CEST] <kepstin> you're free to combine them back together into a combed frame with a filter [22:59:33 CEST] <TheSashmo> yeah but the video looks sqished [22:59:42 CEST] <TheSashmo> yeah I could do that [23:00:05 CEST] <kepstin> better yet, just don't use interlaced hevc ;) [23:00:33 CEST] <TheSashmo> I dont have that choice [23:00:37 CEST] <TheSashmo> Im not encoding it [23:00:41 CEST] <TheSashmo> its coming to me like that [23:50:30 CEST] <brimestone> Is there a compre [23:51:37 CEST] <brimestone> Is there a comprehensive book, on how to use ffmpeg and all its awesomeness ? [00:00:00 CEST] --- Fri Oct 4 2019

1 0

ffmpeg-devel.log.20191002
by burek 03 Oct '19

03 Oct '19

[00:12:32 CEST] <mkver> cehoyos: Why do you think that ticket #5937 is of minor importance? [00:34:14 CEST] <cehoyos> It looks minor to me - not sure if I understand you? [00:34:39 CEST] <cehoyos> A false warning is hardly a "real" bug, no? [00:35:09 CEST] <BtbN> That looks more like a slightly corrupted but playable file to me [00:35:21 CEST] <cehoyos> Even more so if a work-around exists for those who don't like the message [00:35:35 CEST] <cehoyos> Why do you think so? [00:36:07 CEST] <BtbN> Just from the message. Just needs a single bitflip to cause what it describes. [00:36:15 CEST] <cehoyos> (The flac application has a test function to validate files) [00:36:37 CEST] <cehoyos> I would expect a bitflip to have more effects than a warning message for a lossless format, no? [00:36:47 CEST] <BtbN> Depends on where it occurs [00:41:35 CEST] <BtbN> hm, unrelated, but I found this while looking at the code: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/flac_parser.c#L442 [00:41:53 CEST] <BtbN> passing AV_LOG_DEBUG to the log_level_offset parameter does not seem right [00:43:00 CEST] <BtbN> But yeah, the code path does not look like it's hitting any unepxected code path. It's just informing about it. [00:43:06 CEST] <BtbN> -path [00:45:23 CEST] <mkver> This is not just a bogus warning. Some packets are somehow omitted; so decoding is not lossless and streamcopy doesn't work correctly either. [00:45:43 CEST] <cehoyos> What do you mean with "decoding is not lossless"? [00:45:57 CEST] <cehoyos> And "streamcopy doesn't work correcly either"? [00:46:06 CEST] <cehoyos> Or to say it differently: Which sample are you testing? [00:46:48 CEST] <mkver> This one: https://trac.ffmpeg.org/ticket/5937#comment:4 [00:47:24 CEST] <mkver> Somehow the parser omits some packets, so that both decoding as well as streamcopy doesn't work as it should. [00:47:26 CEST] <cehoyos> But the sample for ticket 5937 is in http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket5937/ [00:47:42 CEST] <cehoyos> I don't think high-jacking tickets should be encouraged. [00:48:16 CEST] <cehoyos> This regression is of course (very) important but it's not what was reported. [00:53:44 CEST] <cehoyos> I will open a new ticket tomorrow. [05:23:20 CEST] <wbs> jamrial: yes, I'm subscribed [07:40:08 CEST] <rcombs> jkqxz: tracking down a weird VAAPI H264 encoder quality issue and it seems to have regressed in 2562dd9e7831743ba6dc5680501fb7d26a2ec62c, but simply reverting that commit on current master doesn't resolve it [07:41:28 CEST] <rcombs> seeing it with resolution 854x480 and params -b 2757k -maxrate 3676k -bufsize 7352k [07:41:57 CEST] <rcombs> the first [decent chunk, maybe to the first scenecut?] of the video ends up severely bitstarved and looks like garbage [07:42:07 CEST] <rcombs> and then after that it behaves more or less normally [07:42:27 CEST] <rcombs> erm, not first scenecut actually& hard to say exactly what the trigger is [08:42:15 CEST] <rcombs> looks like it happens if either of af532c921575eb8ee805cc2c64a914f6302442e1 or 2562dd9e7831743ba6dc5680501fb7d26a2ec62c is applied [08:46:45 CEST] <nevcairiel> i saw reports like that, are you on master? [08:48:53 CEST] <nevcairiel> There is for example this https://patchwork.ffmpeg.org/patch/14454/ which was deemed a driver bug [08:49:48 CEST] <nevcairiel> (also https://patchwork.ffmpeg.org/patch/14453/) [08:54:20 CEST] <rcombs> looks to be related to ctx->va_bit_rate being replaced with avctx->bit_rate [08:54:36 CEST] <rcombs> goes away if I revert that bit in vaapi_encode_h264.c (and 2562dd9e7831743ba6dc5680501fb7d26a2ec62c) [08:56:08 CEST] <rcombs> yeah looks like it's probably that [08:56:11 CEST] <rcombs> cc: tmm1 [08:57:07 CEST] <rcombs> >It could be reproduced when mpeg2_vaapi decode was involved in the transcode pipeline. [08:57:07 CEST] <rcombs> ð 1 [08:57:07 CEST] <rcombs> [08:57:09 CEST] <rcombs> huh wow [08:57:22 CEST] <rcombs> I am indeed using mpeg2 here, but I'd assumed that was irrelevant [08:57:25 CEST] <rcombs> because, y'know [08:57:26 CEST] <rcombs> sanity [08:57:28 CEST] <JEEB> :) [08:57:42 CEST] <JEEB> I remember one random Japanese fork having something regarding MPEG-2 video decoding [08:57:46 CEST] <JEEB> via vaapi [08:58:08 CEST] <rcombs> wonder if it'd go away if I scaled by like 2px [08:58:18 CEST] <JEEB> https://github.com/0p1pp1/FFmpeg/commit/b049b2f232a15d92563ceb9f3bf7f36a830… https://github.com/0p1pp1/FFmpeg/commit/67306b7beaa5dd59ce44af786efb2df9589… [08:58:26 CEST] <JEEB> can't say anything regarding these two [08:58:43 CEST] <JEEB> just remember noticing them when looking through this fork [08:59:18 CEST] <rcombs> ¯\_(Ä)_/¯ I can try 'em and see if they make a difference for kicks [09:00:54 CEST] <JEEB> probably won't, but (Ž4@) indeed [09:02:17 CEST] <rcombs> INTEL [09:03:32 CEST] <rcombs> nope [09:14:29 CEST] <rcombs> so it seems like (a) the rate control is getting reset a lot for no reason, and (b) the ratecontrol _sucks_ after a reset [09:16:43 CEST] <JEEB> yea [09:53:54 CEST] <rcombs> hmm, except it's not actually getting reset constantly [09:55:33 CEST] <rcombs> looks to me like the effect of tmm1's patches (or mine) is actually to force an extra reset on the second keyframe [09:55:56 CEST] <JEEB> vOv [09:56:12 CEST] <JEEB> that would kind of explain the effect [10:03:08 CEST] <rcombs> if you reset constantly, shit's bad, and if you only reset on the first frame, shit's bad [10:03:22 CEST] <rcombs> but if you reset on the second keyframe then only the first GoP's bad [10:03:30 CEST] <rcombs> now& why [10:56:39 CEST] <cone-589> ffmpeg 03Paul B Mahol 07master:9847380f5f5a: avfilter/vf_elbg: stop leaking frame on error [10:59:36 CEST] <JEEB> michaelni: btw what is your opinion on back-porting of fixes? I've heard the opinion that only regressions should be fixed in release branches, which would not (in my meaning of regressions, which are limited to our code) encompass f.ex. bad usage of GnuTLS APIs which depend on how the other side is configured [11:00:46 CEST] <JEEB> f.ex. "connections to nice_streaming_service.org used to work, but after they changed their TLS config it no longer works" would not technically be a regression on our side (since the code was always broken), but it is a regression for the user [11:01:29 CEST] <nevcairiel> imho clear-cut bugfixes should also be backported, the regression "rule" only comes from one person :p [11:01:36 CEST] <michaelni> JEEB, regression and bugfixes should be ok assuming there is nothing odd on the backported patch [11:02:22 CEST] <JEEB> nevcairiel: that was my understanding as well for the "regressions only" opinion [11:02:28 CEST] <JEEB> just wanted another senior opinion on it :P [12:40:33 CEST] <rcombs> so, the key thing is calling gen9_avc_kernel_brc_init_reset an extra time [12:40:38 CEST] <rcombs> even doing it on the second frame works [12:40:55 CEST] <rcombs> (just doing it twice in a row doesn't, though) [12:41:13 CEST] <rcombs> (even if you make it a GEN9_AVC_KERNEL_BRC_RESET) [12:41:33 CEST] <JEEB> :D [12:47:18 CEST] <BtbN> https://gitlab.com/esr/gif2png/commit/a8a761561b2a071e7452a00868efd5bdf795c… well that's one way to deal with "meaningless fuzzer attacks" [12:53:30 CEST] <durandal_1707> haha [12:55:36 CEST] <thardin> lol [13:00:35 CEST] <thardin> is the go version just piggybacking off the name? [13:01:14 CEST] <rcombs> specifically, resetting immediately after the gen9_avc_kernel_brc_frame_update on the first frame works [13:01:19 CEST] <rcombs> but I have absolutely no idea why [13:02:27 CEST] <rcombs> jkqxz: ^ you know more about the driver internals than me, any ideas? this is all in src/i965_avc_encoder.c [15:29:54 CEST] <cone-955> ffmpeg 03Michael Niedermayer 07master:9c84c162e9f9: avcodec/g2meet: Check if adjusted pixel was on the stack [15:29:55 CEST] <cone-955> ffmpeg 03Michael Niedermayer 07master:61dd2e07be7c: avcodec/g2meet: Check for end of input in jpg_decode_block() [17:48:53 CEST] <nevcairiel> jamrial: i revived my fate box, do you have any idea why the fitsdec stuff fails on mingw gcc 32-bit? [17:50:02 CEST] <nevcairiel> although the box feels rather slow after the migraiton, might need to set it up fresh [17:51:45 CEST] <jamrial> nevcairiel: not sure, but i recall fuzzing found issues in some float calculations in it [18:07:09 CEST] <nevcairiel> its odd, mingw-gcc is usually not the one to produce mismatches in float [18:18:50 CEST] <jamrial> nevcairiel: the odd thing is having bitexact fate tests for a decoder using floats [18:19:29 CEST] <nevcairiel> we do that for float audio decoders as well, dont we [18:19:40 CEST] <jamrial> like, michaelni's patch to fix some NaN -> int issue changed the checksums because lrint by default rounds in a different way [18:20:41 CEST] <jamrial> float decoders use tiny_psnr [18:21:09 CEST] <jamrial> i don't think any such fate test use framecrc [18:23:24 CEST] <Lynne> *af_ [18:23:31 CEST] <jamrial> nevcairiel: as expected, using -msse2 -mfpmath=sse fixes the fate failure on mingw32 [18:23:53 CEST] <JEEB> \o/ [18:23:59 CEST] <JEEB> so 64bit just uses SSE2 by default [18:24:10 CEST] <jamrial> yeah [18:24:47 CEST] <nevcairiel> i actually build my own binaries with those flags, but fate doesnt use them [18:24:51 CEST] <jamrial> the fits tests should be replaced. i don't know if we have other float video decoders and how they are tested [18:27:04 CEST] <jamrial> fate doesn't even use --cpu on x86_32 during configure, meaning some build defines are disabled, like fast_cmov and cpunop [18:27:34 CEST] <durandal_1707> x86_32 is dead [18:28:28 CEST] <jamrial> if only [18:28:33 CEST] <JEEB> ^ [18:29:01 CEST] <durandal_1707> yes, it is dead already, now do something else... [18:29:12 CEST] <nevcairiel> i suppose i could add --cpu to the fate line there [18:29:25 CEST] <jamrial> it may be dead, but it's making fate yellow, so it needs to be dealt with :p [18:30:10 CEST] <nevcairiel> hm the fate config file includes cpu=i686, does that not get forwarded properly [18:30:11 CEST] <durandal_1707> fate - old machines not running any tests for months [18:30:40 CEST] <nevcairiel> most of those "old" entries are for release branches, which makes for a terrible overview [18:30:44 CEST] <jamrial> nevcairiel: -mfpmath=sse is not implied by any -march value on x86_32, afaik, so --cpu alone is not enough [18:30:52 CEST] <nevcairiel> why was the fatebeta thing never finished [18:30:54 CEST] <jamrial> you need to add it with --extra-cflags or so [18:31:14 CEST] <nevcairiel> i didnt want to enable sse math as such, just i686 mode for cmov etc [18:31:27 CEST] <nevcairiel> oh but that is actually enabled [18:32:04 CEST] <jamrial> without sse fp math the fits failure will remain, though [18:32:16 CEST] <nevcairiel> good reminder to fix the test! :p [18:32:30 CEST] <nevcairiel> i'm surprised none of the other weirdo systems errored on it [18:32:42 CEST] <nevcairiel> some always seemed more prone to errors on float [18:33:47 CEST] <nevcairiel> i wonder why fate takes sooo long on this new host for the VM [18:34:29 CEST] <jamrial> intel/amd virtualization stuff disabled in the bios? [18:35:26 CEST] <nevcairiel> i dont think so, but i can check later [18:36:47 CEST] <nevcairiel> the host OS says its on [18:38:14 CEST] <nevcairiel> oh well i'll poke it more later [18:38:30 CEST] <nevcairiel> at least it runs again for the time being [19:06:14 CEST] <durandal_1707> cehoyos: hardware filters are useless, repeat that until you learn it [19:32:44 CEST] <cehoyos> I hope I didn't write that, or is that not your point? [21:07:47 CEST] <cone-522> ffmpeg 03Paul B Mahol 07master:2a546fb7d572: avfilter/setpts: switch to activate [21:19:21 CEST] <cehoyos> durandal_1707: Which sample gets fixed by the amr patch? [21:20:26 CEST] <durandal_1707> cehoyos: https://0x0.st/zwrr.bin [21:24:37 CEST] <cehoyos> Valid files are allowed to contain 0, even "00 00" [21:25:55 CEST] <durandal_1707> cehoyos: give such files [21:39:17 CEST] <rcombs> hmmmmmmmmm [21:39:32 CEST] <rcombs> so I guess this only happens on Gen9, maybe Gen8 [21:39:48 CEST] <rcombs> in either case, only devices that support the iHD driver [21:39:57 CEST] <rcombs> so I can probably get away with just switching to that for those [21:43:33 CEST] <cehoyos> Did you try to encode any source? [21:43:38 CEST] <cehoyos> How do I upload to 0x0? [21:44:29 CEST] <cehoyos> http://0x0.st/zwsc.amr [21:44:37 CEST] <cehoyos> http://0x0.st/zwsT.amr [21:47:58 CEST] <durandal_1707> cehoyos: both files are not raw amr [21:51:10 CEST] <cehoyos> http://0x0.st/zwsM.bin [21:51:17 CEST] <cehoyos> http://0x0.st/zwsu.bin [21:51:23 CEST] <cehoyos> Sorry [22:27:52 CEST] <durandal_1707> cehoyos: bunch of zeros decodes to unpleasant noise [22:28:17 CEST] <cehoyos> True. But it does decode [22:28:26 CEST] <cehoyos> And zeros per-se are not invalid [22:28:39 CEST] <cehoyos> I just sent another suggestion that would fix your sample. [22:28:59 CEST] <cehoyos> Sorry: An idea for another solution [22:29:13 CEST] <cehoyos> That I'll implement if you like the idea. [22:29:58 CEST] <durandal_1707> encode few seconds of noise and silence and compare [23:10:29 CEST] <cehoyos> For libopencore_amrnb, the result looks quite similar to your file;-( [23:10:44 CEST] <cehoyos> (amrwb encodes silence to a file with all modes) [00:00:01 CEST] --- Thu Oct 3 2019

1 0

ffmpeg.log.20191002
by burek 03 Oct '19

03 Oct '19

[00:57:17 CEST] <k-man> how do i do something like ffmpeg -i "concat: *.mp3" .... ? [00:57:46 CEST] <cehoyos> Either use the concat demuxer or the concat filter, see the documentation [00:58:16 CEST] <cehoyos> (The concat protocol may work but should lead to audio artefacts for "real" mp3 files with headers) [00:59:19 CEST] <furq> k-man: on linux, printf "file %q\n" *.mp3 | ffmpeg -f concat -protocol_whitelist file,pipe -safe 0 -i - [00:59:32 CEST] <k-man> furq: ah right [00:59:44 CEST] <k-man> so I can't really do the glob in the ffpmeg command directly [00:59:49 CEST] <furq> no [00:59:55 CEST] <k-man> furq: thank you [01:00:28 CEST] <furq> the concat protocol won't work right with mp3 anyway because of id3 tags etc [01:00:44 CEST] <cehoyos> The decoder should "eat" most of the tags [01:00:50 CEST] <k-man> ah good point [01:00:58 CEST] <furq> does the protocol decode [01:01:23 CEST] <cehoyos> But audible artefacts are possible [01:01:35 CEST] <furq> i thought it basically just did cat *.mp3 [01:01:46 CEST] <cehoyos> That's what it does (not just basically) [01:01:55 CEST] <furq> wait nvm i'm dumb [01:02:03 CEST] <cehoyos> But the decoder should have a high error resilience [01:02:04 CEST] <furq> i forgot you don't have to copy [01:02:13 CEST] <furq> right [01:02:33 CEST] <cehoyos> And the original mp3 could be raw... [01:02:44 CEST] <cehoyos> without any tags [01:02:52 CEST] <furq> well you'd still have wrong duration headers etc [01:03:01 CEST] <furq> but presumably the decoder can cope with that [01:03:06 CEST] <k-man> my goal is to convert to m4b also [01:03:12 CEST] <cehoyos> I don't think an original mp3 contains a duration header [01:04:37 CEST] <cehoyos> ffmpeg -i input -vn -acodec mp3 -f rawvideo -map 0:a:0 out [01:04:46 CEST] <furq> oh yeah i guess that's in the xing header [01:04:50 CEST] <cehoyos> produces a nice mp3 file that can be concatenated [01:04:52 CEST] <cehoyos> yes [01:05:14 CEST] <cehoyos> (This does not work for all audio encoders, particularly not for vorbis and friends) [01:05:59 CEST] <furq> i'm not sure how else you'd get an mp3 with no xing header nowadays [01:06:55 CEST] <furq> k-man: -f ipod out.m4b will get you a valid m4b file [01:07:02 CEST] <furq> but it won't have chapters or anything like that [01:07:17 CEST] <k-man> furq: yeah, i'm realising that [01:07:23 CEST] <furq> i don't think you can do that with ffmpeg [01:07:29 CEST] <furq> it's not just standard mp4 chapters or anything [01:07:42 CEST] <k-man> furq: why is that better than -f mp4 out.m4b? [01:07:45 CEST] <cehoyos> And above is identical to: ffmpeg -i input -vn -id3v2_version 0 -write_xing 0 out.mp3 [01:08:15 CEST] <furq> ipod has different defaults than mp4 that are supposed to be for m4a [01:08:20 CEST] <k-man> apparently you can do something with chapters and metadata? https://ffmpeg.org/ffmpeg-formats.html#Metadata-1 [01:08:20 CEST] <furq> i couldn't tell you what any of them are right now [01:08:38 CEST] <k-man> furq, nice, thanks [01:08:45 CEST] <furq> and yeah i think that'll just write standard mp4 chapters [01:08:53 CEST] <furq> (assuming there is a standard and it's not some itunes extension) [01:08:59 CEST] <furq> but m4b metadata is a totally different thing [01:09:08 CEST] <k-man> furq, is it? [01:09:14 CEST] <furq> i'm pretty sure it is [01:12:20 CEST] <furq> i might be thinking of something else actually [01:12:24 CEST] <furq> someone in a forum post claims it works anyway [01:19:28 CEST] <k-man> what am I doing wrong here? http://ix.io/1NEG [01:22:49 CEST] <furq> add -vn after -i [01:23:20 CEST] <k-man> thank you [01:24:19 CEST] <k-man> disable video in the output right? [01:32:58 CEST] <brimestone> how can I use the output of av_dump_format so I can store the the output on Standard Error to a "String" or better yet to a struct [01:34:45 CEST] <klaxa> don't think you can really, it writes to stderr [01:35:06 CEST] <klaxa> with av_log() [01:35:32 CEST] <brimestone> klaxa: how would I access a specific value pair? [01:36:40 CEST] <klaxa> which one? [01:36:59 CEST] <brimestone> Well, fps, fmt_pix, timecode [01:37:31 CEST] <klaxa> i think av_dump_format() just accesses AVFormatContext fields [01:38:20 CEST] <klaxa> and for that stuff you need an AVStream [01:38:46 CEST] <klaxa> see dump_stream_format() maybe? [01:39:52 CEST] <brimestone> im sooooo close... [01:43:05 CEST] <brimestone> I think I found it! [01:45:26 CEST] <klaxa> for pixel format you will need AVFormatContext->streams[i]->codecpar->format [01:47:21 CEST] <klaxa> that will be an int which correspends to an AVPixelFormat Enum [01:47:28 CEST] <klaxa> *enum [01:51:50 CEST] <brimestone> how about timecode? [01:52:09 CEST] <klaxa> what do you mean by that? [01:52:16 CEST] <brimestone> I see some video codec stores timecode on the Format header but some of them stores in on the stream [01:53:04 CEST] <klaxa> what kind of timecode is it though? creation? duration? [01:53:11 CEST] <brimestone> https://gist.github.com/brimestoned/728b975a913c16c74a1c65e31c4ef46a line 417 [01:53:37 CEST] <klaxa> that's metadata [01:54:14 CEST] <klaxa> it's custom to each file [01:54:27 CEST] <klaxa> no idea what it is supposed to represent even [01:54:54 CEST] <klaxa> unless it's a high resolution timestamp :P [01:54:54 CEST] <brimestone> So that's not part of the [Stream] ? [01:55:02 CEST] <klaxa> no [01:55:35 CEST] <klaxa> as you can see each stream has its own "tags" object [01:55:49 CEST] <klaxa> and the format (container) has one as well [01:56:35 CEST] <brimestone> which I'm able to loop thru each stream and output its metadata.. but I don't know how to get to the Format part of it [01:57:11 CEST] <brimestone> Yeah, how would I get a hold of the Format container? [01:57:23 CEST] <klaxa> that's your AVFormatContext [01:57:24 CEST] <klaxa> https://www.ffmpeg.org/doxygen/3.2/dump_8c_source.html#l00132 [01:58:53 CEST] <brimestone> fmtCtx.metadata direct? [01:59:20 CEST] <klaxa> looks like it [01:59:23 CEST] <brimestone> Wow! You're right! Its right there! [04:24:56 CEST] <InkButton> i'm trying to encode a raw video before uploading to youtube, and i'm using the settings suggested here: https://gist.github.com/mikoim/27e4e0dc64e384adbcb91ff10a2d3678 [04:25:06 CEST] <InkButton> the encoding is going at 0.025x speed [04:25:11 CEST] <InkButton> about 0.8 fps [04:25:22 CEST] <InkButton> but its using virtually no CPU [04:26:31 CEST] <InkButton> is there some way to make this faster without compromising quality? i want to get youtube to give me the VP9 codec for my videos, it seems ot always apply VP1 and makes my videos look like trash. [04:29:15 CEST] <InkButton> my processor is i5-8500 [04:29:18 CEST] <furq> weird [04:29:20 CEST] <furq> looks fine to me [04:30:02 CEST] <furq> you can drop -coder 1, -bf 2, -g 30 and -b:a 384k [04:30:09 CEST] <furq> and -profile:v high [04:30:23 CEST] <furq> those are all either implied or just bad recommendations [04:30:38 CEST] <furq> the defaults for all of those are either the same or better [04:30:55 CEST] <furq> oh and -profile:a aac_low is default as well [04:31:20 CEST] <furq> also whether youtube gives you vp9 or not has nothing to do with the source video [04:31:33 CEST] <InkButton> ffmpeg -i /Volumes/Raid/sweetbunsvoiceover_1.mov -c:v libx264 -preset slow -crf 18 -pix_fmt yuv420p -movflags +faststart -c:a aac ~/Desktop/sweetbuns-compressed.mp4 [04:31:37 CEST] <InkButton> > [04:31:42 CEST] <furq> i'm pretty sure you'll get vp9 once the video hits a certain view count [04:32:01 CEST] <furq> based on anecdotal evidence, because obviously google never release any info about this [04:32:17 CEST] <InkButton> its running at 0.4x now which is quite a bit faster. [04:32:26 CEST] <InkButton> still seems to be barely using my CPU [04:32:35 CEST] <furq> yeah none of that would have fixed the cpu utilisation [04:32:53 CEST] <InkButton> its fluctuating around 25% CPU usage nwo [04:33:08 CEST] <InkButton> now* (maybe just using 1 core?) [04:33:15 CEST] <furq> it shouldn't be [04:33:21 CEST] <furq> unless you're getting thermal throttled or something [04:33:42 CEST] <furq> or you have really slow disk read speeds [04:34:00 CEST] <InkButton> thats possible, its pulling this file of a not particularly fast raid. [04:34:27 CEST] <furq> if the bitrate figure in the ffmpeg output is accurate then that's only ~20MB/s [04:34:32 CEST] <furq> so it'd have to be a very slow raid [04:34:55 CEST] <furq> but i assume from the profile that it's lossless so maybe that figure is wrong [04:35:28 CEST] <furq> also your source is aac so you should probably be using -c:a copy [04:52:13 CEST] <InkButton> Hi furq, thanks for your help so far. i tried to reboot and see if that was it [04:53:11 CEST] <InkButton> i'm still getting really low CPU utilization with: -c:v libx264 -preset slow -crf 18 -pix_fmt yuv420p -movflags +faststart -c:a aac [04:53:23 CEST] <InkButton> if i do just: -crf 18 -vcodec libx264 [04:53:30 CEST] <InkButton> it does full 100% CPU utilization [04:53:45 CEST] <InkButton> with the input and output files in the same places both times [04:53:50 CEST] <InkButton> so i guess this rules out a hard drive speed issue [04:56:44 CEST] <InkButton> ok, acutall just confirmed the only flag that matters on whether or not it does the full CPU utilization is: "-preset slow" [04:56:54 CEST] <InkButton> without that it goes at 100% CPU [04:57:12 CEST] <InkButton> its not supposed to just mean "do this slower" is it? [04:57:30 CEST] <InkButton> i figured it was actually doing something more computationally expensive, not just using less CPU [05:01:48 CEST] <InkButton> strangely enough: -preset slower, is actually using 100% CPUn and running at lot FASTER than -preset slow. [05:01:55 CEST] <InkButton> :shrug: [05:04:01 CEST] <InkButton> LOL i spoke too soon. it WAS ripping along at 100% CPU and almost 1x, for the first 40 seconds of the video, now its slowed to a crawl, just like -preset slow. [05:18:20 CEST] <kepstin> yeah, your bottleneck is somewhere other than the cpu, probably storage speed. [05:18:44 CEST] <kepstin> x264 is really good at multithreading and using all the cpu if you aren't bottlenecked elsewhere [05:20:30 CEST] <InkButton> ok. thanks. will try moving source file [05:22:08 CEST] <kepstin> given the last thing you said, it might be the destination that's the issue, not the source [05:22:17 CEST] <kepstin> (or that could have just been a caching effect) [07:09:20 CEST] <InkButton> well thanks again for the advice earlier guys, turns out one of my disks is failing in that raid array [07:09:27 CEST] <InkButton> good think i caught it when I did [13:19:41 CEST] <termos> How would I go about selecting say the first input on the second DeckLink Quad card here? https://www.irccloud.com/pastebin/pexumCL3/ [13:21:56 CEST] <BtbN> iirc more than one card is not supported by the code as it is right now [13:28:22 CEST] <termos> hmm okey, I see there's some querying of a unique name https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/decklink_common.cp… but not sure if it's used, that might even be the one that's printed [13:35:49 CEST] <termos> https://forum.blackmagicdesign.com/viewtopic.php?f=12&t=88995 found this, I can set the card names manually in BlackmagicDesktopVideoSetup and that seems to work well [15:30:03 CEST] <jumping_jack> hello, so im using the following command to stream from my logitech usb webcam c270 : "ffmpeg -f dshow -rtbufsize 64M -i "video=Integrated Webcam" -s 1280x720 -f sdl2 -" ; im very new to ffmpeg so i dont know what all these args stand for but the problem is that the saved video has a resolution of 640 x 480 only. how can i change that [15:30:14 CEST] <jumping_jack> specfically, set it to 1280 x 720 too [15:31:22 CEST] <BtbN> you're telling it to scale whatever res it gets from the device to 720p [15:32:13 CEST] <jumping_jack> BtbN, thank you for responding. but its setting the resolution to 640 x 480 ? [15:32:55 CEST] <BtbN> That's probably what the camera defaults to [15:33:15 CEST] <jumping_jack> BtbN, specifically, during the recording i (apparently) see the window size as the resolution, its the saved video that has the 640 x 480 resolution [15:33:42 CEST] <BtbN> The command you pasted also does not record to anything [15:34:40 CEST] <jumping_jack> BtbN, well yes i added a filename output.mkv to the command later which i forgot to include, the whole command looks like [15:34:54 CEST] <jumping_jack> "ffmpeg -f dshow -rtbufsize 64M -i "video=Integrated Webcam" -s 1280x720 -f sdl2 - output.mkv" [15:35:29 CEST] <BtbN> You are creating a second output file, with no options applied to it at all. [15:35:38 CEST] <BtbN> all the options after -i apply to the sdl2 output [15:36:01 CEST] <BtbN> also, -s will only scale whatever res comes from the camera to 720p, you most likely don't want that. [15:36:36 CEST] <jumping_jack> how do i apply a resolution option to my output mkv [15:38:02 CEST] <BtbN> You set the resolution on the webcam input. Look at the dshow format doc to find out how. [15:39:26 CEST] <jumping_jack> i am new to ffmpeg, i don't know much about video encoding, i just want the output file in 720p [15:40:03 CEST] <BtbN> If the camera only outputs 640x480, there is little point in scaling it to 720p. Doing so will also stretch the image. [15:40:35 CEST] <BtbN> So check the device options if it can record in a higher res [15:41:02 CEST] <jumping_jack> when i recorded from the webcam using vlc, it did so in the resolution of "1280x960" [15:41:35 CEST] <jumping_jack> i am pretty sure that it can record in 720p [15:41:47 CEST] <BtbN> Have you tried reading the Wiki and documentation yet? https://trac.ffmpeg.org/wiki/DirectShow [15:44:29 CEST] <jumping_jack> yes i have it on my screen and im trying to understand [15:44:45 CEST] <jumping_jack> you said above that im ccreating a file with no input options applied to it at all [15:45:12 CEST] <jumping_jack> does that mean i can give it a -s 1280 x 720 argument too after output.mkv ? [15:45:22 CEST] <BtbN> Options always apply to the next input or output on the command line. [15:45:30 CEST] <BtbN> so your Scaling-Command applies to the SDL output. [15:45:42 CEST] <BtbN> And you have given no options for the mkv output, so it will use all defaults. [15:45:53 CEST] <BtbN> But really, you do not want output scaling. You want to set the cameras resolution. [15:47:03 CEST] <jumping_jack> ok, but i dont understand how vlc was able to record in 1280 x 960 by default ? [15:47:35 CEST] <BtbN> You set it to that resolution probably. [15:48:17 CEST] <jumping_jack> BtbN, no i didnt change anything [15:48:23 CEST] <jumping_jack> thats what confuses me [15:48:32 CEST] <BtbN> You must have set a resolution at some point. [15:49:58 CEST] <jumping_jack> no i just went to open media, set device name to my cam and started recording [15:50:38 CEST] <jumping_jack> BtbN, you also said above that i gave the mkv output no options, how do it give it options ? [15:51:07 CEST] <jumping_jack> im sorry to be bugging you but its just that i dont much about video processing and i need to get this done [15:51:36 CEST] <BtbN> You place them before it on the command line, but after any preceeding inputs/outputs [15:52:05 CEST] <BtbN> You'll probably only want to set it to use libx264 and -crf 20 or something. [15:52:32 CEST] <jumping_jack> so the options have to come 'after' output.mkv ? [15:52:51 CEST] <BtbN> No? [15:52:53 CEST] <BtbN> Before [15:53:02 CEST] <BtbN> But after any preceding input or output. [15:53:45 CEST] <jumping_jack> okay so could you please show me how a command giving explicit size to the output.mkv would look like in my case [15:53:55 CEST] <BtbN> I can't, since I don't have dshow available to me. [15:54:08 CEST] <BtbN> But the Wiki has a whole bunch of examples on how to set the devices resolution [15:55:02 CEST] <jumping_jack> okay so i know im asking this thing in another way [15:55:36 CEST] <jumping_jack> "ffmpeg -f dshow -rtbufsize 64M -i "video=Integrated Webcam" -s 1280x720 -f sdl2 -s 1280x720 - output.mkv"; is this where the size fits in ? [15:58:32 CEST] <jumping_jack> nevermind, i figured it out [16:00:06 CEST] <jumping_jack> ffmpeg -f dshow -video_size 1280x720 -i "video=Integrated Webcam" output.mp4 -f sdl2 - [16:00:31 CEST] <jumping_jack> the above command worked for me [16:01:00 CEST] <jumping_jack> i applied all the options to the video file first, then added sdl as a "" [16:01:11 CEST] <jumping_jack> i applied all the options to the video file first, then added sdl as a "secondary output" [16:25:41 CEST] <cards> doesn't ffmpeg have a direct built-in validation tool that only does validation (and so it does it fast)? the only thing i can find is encoding a video to a null device, but this takes a lot more time due to the cpu work [16:26:32 CEST] <cards> i would have figured either ffmpeg or ffprobe have a -validate switch [16:27:07 CEST] <kepstin> i'm not sure what you'd expect a "validate" feature to do [16:28:19 CEST] <kepstin> reading, demuxing, and decoding a file probably makes sense, and that's exactly what running ffmpeg with the null output does (it doesn't encode when using the null output unless you explicitly ask it to) [16:28:54 CEST] <kepstin> (you might also want to add a -map 0 option so it reads all streams from the file instead of a subset) [16:31:55 CEST] <furq> i guess something that just parses bitstreams and makes sure they're not obviously broken [16:32:10 CEST] <furq> validate would be a bit of misnomer though because it would miss most problems [16:32:36 CEST] <cards> i would like to catch bitflips if possible [16:32:52 CEST] <cards> assuming each frame has some checking [16:33:00 CEST] <DHE> sounds like a full decode of the video/audio would be required to do that, or at least enough work that CPU usage would be quite high doing so [16:33:04 CEST] <furq> it doesn't but the hash muxer doesn't decode [16:33:11 CEST] <furq> so you could just store those hashes somewhere and compare them [16:33:35 CEST] <furq> unless "assuming" means you're using a format that does actually have frame checksums [16:34:07 CEST] <cards> hmm. maybe i was using some wrong command switches, because after several minutes it was predicting that it would take several hours to complete. longer than the video's playback length [16:34:59 CEST] <cards> furq: right. if the format has frame checksums, does ffmpeg actually validate them or ignore them? [16:36:02 CEST] <furq> it ignores them unless you set -err_detect crccheck [16:36:20 CEST] <furq> that's a decoder option though [16:36:31 CEST] <furq> so obviously implies decoding [16:36:33 CEST] <cards> ah good to know [16:37:16 CEST] <cards> so what would be a good commandline you recommend i use to validate a file, decoding only [16:37:42 CEST] <furq> -err_detect crccheck -i foo -f null - [16:38:15 CEST] <furq> or like crccheck+bitstream+buffer+explode+careful+aggressive if you want to go hog wild [16:38:47 CEST] <furq> if you're just interested in bit flips and your codec has embedded checksums then just crccheck is fine [16:39:38 CEST] <cards> thanks. [16:39:46 CEST] <cards> i may just need to run this on a better cpu [16:40:10 CEST] <kepstin> cards: share your command line? we can tell you if something's obviously wrong [16:40:21 CEST] <cards> it's the same furq pasted [16:40:39 CEST] <furq> what codec is it [16:40:49 CEST] <cards> h264 [16:40:57 CEST] <kepstin> furq did not paste a complete command line, i want to see the whole thing. [16:41:28 CEST] <kepstin> well, i suppose if you stick an "ffmpeg" on the front that is complete :) [16:42:40 CEST] <cards> ffmpeg -v error -i foo.mp4 -f null - > error.log [16:42:55 CEST] <kepstin> i'd expect that command to either be cpu-limited on the video decoder or io limited on your storage device. [16:43:24 CEST] <cards> meaning it would only decode in realtime? [16:43:35 CEST] <furq> maybe try with 2>error.log [16:43:42 CEST] <furq> mostly because that'll actually work [16:43:50 CEST] <kepstin> no, it should decode much faster than realtime if your cpu and disk are fast enough [16:43:51 CEST] <cards> pardon? [16:43:54 CEST] <furq> but also maybe the stdout file output and then redirect is causing problems [16:44:06 CEST] <cards> sorry, windows here. [16:44:12 CEST] <furq> that should still work on windows [16:44:20 CEST] <cards> why the 2 [16:44:23 CEST] <furq> 2 is stderr [16:44:34 CEST] <furq> - writes to stdout and then > redirects stdout, so the file output, not the ffmpeg log output [16:44:36 CEST] <cards> -v error is no better? [16:44:38 CEST] <furq> ffmpeg always logs to stderr [16:44:52 CEST] <kepstin> ffmpeg's console log output is on stderr, not stdout, since you often pipe video out of ffmpeg on stdout [16:44:56 CEST] <furq> right [16:45:20 CEST] <furq> i'd be surprised if that was causing a slowdown but it is windows [16:45:28 CEST] <furq> i'm often surprised by how their terminal works [16:45:42 CEST] <kepstin> the null muxer doesn't actually write any output, so that *should* cause an issue, but.. :/ [16:45:46 CEST] <cards> hmm [16:45:47 CEST] <kepstin> shouldn't* [16:45:48 CEST] <furq> right [16:46:05 CEST] <kepstin> i think on windows you can use "-f null NUL" [16:46:12 CEST] <furq> if nothing else that'll actually write the error log to a file [16:47:36 CEST] <cards> will ffmpeg also validate mp3 audio? i've been meaning to do a side-by-side compare of other mp3 validators [16:47:48 CEST] <cards> they all seem to catch different errors and not others [17:04:14 CEST] <kepstin> i'd expect most mp3 validators would find errors with the file format, not necessarily with the contents. i'm pretty sure there's changes you can make to mp3s where they'll still decode fine but will have audible issues. [17:04:39 CEST] <kepstin> if your goal is to just detect if something in the file has *changed*, you're probably best off using external checksums. [17:05:21 CEST] <kepstin> (with a few notable exceptions for formats that actually have internal checksums) [17:07:16 CEST] <cards> the 3 validators that i've found useful will each flag all the same mp3s for eggregious errors, and then they variously split off to also covering ID3 tag mishaps and other technical ugly. but not subjective audio quality [17:11:45 CEST] <cards> a good validator will also tell you that there's anomalous data at the end of a file. people like to add hidden ZIP and RAR containers to just about everything. [17:13:05 CEST] <cards> if you want a good time, see which image hosting sites will let you upload an [image][hidden-rar].jpg/png and then serve it for viewing without stripping off the container [19:16:32 CEST] <fred1807> I want to stream over tcp from vps1 to vps2... On source, I ust tcp://destinationip:port ? [19:16:47 CEST] <fred1807> use [19:32:31 CEST] <ChocolateArmpits> fred1807, yeah that's how you use it but you may also want to set -listen 1 so ffmpeg wouldn't crash if no stream was present and would connect immediately when it's there. Additionally make sure the command line loops in case the connection goes down on occasions [19:32:47 CEST] <ChocolateArmpits> ALSO [19:32:58 CEST] <ChocolateArmpits> make sure to specify the format of the input [19:33:12 CEST] <ChocolateArmpits> so place -f [format] before the input. If the input is mpegts then -f mpegts [19:33:20 CEST] <cehoyos> In general, you should never specify the input format with FFmpeg [19:33:35 CEST] <cehoyos> But with tcp, you have to specify the output format as there is no default for tcp [19:35:04 CEST] <fred1807> nice, so in the listening side (vps2).. ffmpeg -f mpegts -i udp:localhost:5000 -listen 1 ........ [19:35:40 CEST] <ChocolateArmpits> you'd have to use udp [19:35:43 CEST] <ChocolateArmpits> whoops [19:35:47 CEST] <ChocolateArmpits> tcp*** not udp [19:36:08 CEST] <ChocolateArmpits> and the address needs to point to the sender, not receiver [19:36:31 CEST] <ChocolateArmpits> also -listen 1 needs to go before the input [19:54:24 CEST] <fred1807> so.. on server (vp1) ffmpeg ........ -f mpegts tcp://localhost:5000 on client (vps2) ffmpeg -listen 1 -f mpegts -i tcp://serverIp:5000 [20:03:22 CEST] <BLZbubba> hi guys i have a transport stream that is misbehaving and I was wondering if someone could help convert it to mkv with ffmpeg copy - http://uberdl.com/tmp/bogus_stream.ts [20:03:33 CEST] <BLZbubba> mpv plays it, vlc & mplayer fail [20:04:52 CEST] <cehoyos> Needs -f mpegts to prove me wrong;-) [20:05:32 CEST] <cehoyos> The reason is that it starts with 1 MB of "0" [20:06:09 CEST] <DHE> pretty... also it has a lot of instances of pts < dts [20:06:54 CEST] <cehoyos> If you cut the "0"s, the detection works fine. [20:13:29 CEST] <DHE> ffmpeg -f mpegts bogus_stream.ts # works with a lot of log/console messages [20:17:14 CEST] <BLZbubba> sweet, you guys are awesome [20:17:23 CEST] <ChocolateArmpits> fred1807, well you'd use the server IP address in first, because the listener can't connect to localhost that's on another system [20:17:35 CEST] <DHE> *ffplay [20:18:03 CEST] <furq> or 0.0.0.0 to listen on all addresses [20:22:47 CEST] <cehoyos> The sample seems pathologic to me: If I cut the first 10.000 (or more) of 950.000 zeros, detection works fine [20:23:02 CEST] <fred1807> tcp://0.0.0.0:5000: Connection refused [20:24:10 CEST] <ChocolateArmpits> cehoyos, what about analyze_duration or probesize or even *GASP* skip_initial_bytes [20:24:33 CEST] <cehoyos> All three do not help [20:24:55 CEST] <cehoyos> The reason is that I believe there is a limit for the initial probing [20:26:11 CEST] <cehoyos> It is apparently ~1M [20:26:29 CEST] <cehoyos> The only question is if ".ts" should be detected [20:27:32 CEST] <cehoyos> ".mpeg" and ".mpg" are not detected for the obvious reason that they are dubious but that may not be true for ".ts" [20:28:36 CEST] <durandal_1707> ffprobe /dev/zero [20:29:38 CEST] <cehoyos> An extension does not help for this case either [20:41:08 CEST] <fred1807> ffmpeg -i 'moviefile.mp4' -filter_complex "scale=iw*min(1\,min(1280/iw\,720/ih)):-1" -c:v libx264 -preset veryfast -crf 30 -r 30 -an -f mpegts tcp://0.0.0.0:9000 Gives me connection refused [20:43:34 CEST] <ChocolateArmpits> fred1807, you need to use the system address there, I have no idea why furq suggested that for output [20:44:05 CEST] <fred1807> what would be a system address? [20:44:20 CEST] <ChocolateArmpits> I suppose the listener process runs on another system, yes? [20:44:30 CEST] <fred1807> yes, another vps [20:44:57 CEST] <ChocolateArmpits> can they communicate otherwise? [20:45:11 CEST] <ChocolateArmpits> are they on the same network? [20:45:38 CEST] <fred1807> maybe I should output to a pipe, and use ssh to cat the pipes ? [20:47:48 CEST] <ChocolateArmpits> I don't know how that works, sorry [20:47:54 CEST] <fred1807> ChocolateArmpits: not the same network... I was expecting to communicate via internet [20:49:02 CEST] <cehoyos> BLZbubba: Do you know how the sample was created? [20:49:49 CEST] <cehoyos> The issue is that the mpegts probing function weighs the probing score against the probe_size which the mpegps (and possibly all other probe functions) do not [20:57:03 CEST] <BLZbubba> "-c copy" is the best feature of all time [20:57:14 CEST] <taliho> ChocolateArmpits: Can you ping the ip address where you are trying to send the stream? [20:57:26 CEST] <BLZbubba> cehoyos: no, the file just fell off a truck in front of my house [20:58:02 CEST] <BLZbubba> tennis stream service of a tournament in china [20:58:40 CEST] <BLZbubba> it is playing perfectly with vlc now. thanks! [20:59:08 CEST] <taliho> fred1807: Can you ping the ip address of where you are trying to stream? [21:06:28 CEST] <taliho> fred1807: if you want to do it properly with ssh you need to setup local forwarding [21:07:57 CEST] <taliho> fred1807: if you don't care about encryption you could just open up a port on your target machine and send data [21:09:34 CEST] <taliho> fred1807: on the target machine get ip address with: $ ip addr a [21:10:56 CEST] <taliho> on target: $ sudo ufw allow 9000/udp #opens port 9000 for udp traffic [21:11:19 CEST] <fred1807> yes I can ping, I just opened the ports [21:11:24 CEST] <fred1807> tcp in this case... [21:11:53 CEST] <taliho> from host: ffmpeg xx -f mpegts udp://ipaddress:port [21:13:04 CEST] <taliho> on target: ffprobe -f mpegts udp://ipaddress:port [21:13:14 CEST] <cehoyos> BLZbubba: I can see what it is, my question was how did you record it? [21:14:25 CEST] <taliho> make sure ipaddress is *not* something like 192.168.x.x because that's local [21:15:31 CEST] <taliho> if you just want to test connection between the two: on target $ nc -l -u ipaddress port [21:15:48 CEST] <taliho> on host $ nc -u ipaddress port [21:16:09 CEST] <taliho> and you should be able to type messages between the two [21:17:31 CEST] <taliho> RE: "yes I can ping, I just opened the ports" -- you only need to open port on the target machine (i.e. where you are binding to port) [21:38:37 CEST] <BLZbubba> cehoyos: bit torrent :P [21:39:00 CEST] <BLZbubba> aka "fell off a truck" [21:39:13 CEST] <BLZbubba> that is an old mafia term [21:54:14 CEST] <cehoyos> Sorry, I misread your message above... [00:00:01 CEST] --- Thu Oct 3 2019

1 0

ffmpeg-devel.log.20191001
by burek 02 Oct '19

02 Oct '19

[00:23:54 CEST] <J_Darnley> I'm glad I could help waste time. [00:28:06 CEST] <tmm1> Illya: looks like the short_event's event_name is what i was using too [00:28:58 CEST] <beastd> J_Darnley: Thanks for wasting my time :) [00:33:10 CEST] <Illya> tmm1: not sure if we should check for short_event's event_name, I guess if we're only checking the first then it might be ok. I'll leave it for now, finish iconv stuff then come back to it [00:58:36 CEST] <BradleyS> i'll share a story that isn't on that site [00:58:48 CEST] <BradleyS> family member works for apple retail [00:59:16 CEST] <BradleyS> some country folk from a relatively isolated community brought their laptop in because it wasn't working [00:59:47 CEST] <BradleyS> the employees opened it up in the back and found liquid damage, seemed coca-cola was spilled on the keyboard [01:00:13 CEST] <BradleyS> so they brought the laptop out to the customer to show them the liquid damage, told them someone spilled coke on it [01:00:33 CEST] <BradleyS> one of the teenage children (essentially an adult) licked the computer [01:00:39 CEST] <BradleyS> "coke taste don't taste, pop" [01:00:45 CEST] <BradleyS> (pop meaning father) [01:00:59 CEST] <BradleyS> then the next child did the same, "coke taste don't taste" [01:01:08 CEST] <BradleyS> and the third child. [01:01:41 CEST] <BradleyS> the father in limited vocabulary stated that coca-cola was definitively not spilled on the computer, it must be something else wrong [01:02:24 CEST] <BradleyS> my family member to this day cannot get over the fact that a customer (three!) licked the inside of a computer in his store [01:02:43 CEST] <BradleyS> high tech diagnostic [01:17:01 CEST] <Lucas93> Hi [01:18:29 CEST] <Lucas93> Is this the right channel to ask/verify a possible memleak in libavcodec/qsvenc.c ? [01:19:02 CEST] <kierank> yes [01:20:34 CEST] <Lucas93> Ok so I believe there's a leak in libavcodec/qsvenc.c when closing the codec. [01:21:22 CEST] <Lucas93> mfxExtAVCEncodedFrameInfo *enc_info and mfxExtBuffer **enc_buf are not free'd by ff_qsv_enc_close [01:24:29 CEST] <BradleyS> a leak, hmm... have you tried licking it to see what's leaking out? [01:24:59 CEST] <BradleyS> (would make more sense if you were here 20 mins ago :P ) [01:25:18 CEST] <Lucas93> Yeah not sure what you are taking about. [01:25:42 CEST] <Lucas93> But I'm pretty sure it's memory. [01:26:20 CEST] <BradleyS> i'm pretty sure you're correct [01:26:21 CEST] <BradleyS> https://i.imgur.com/auXHAT0.png [01:28:26 CEST] <Lucas93> lol [01:28:51 CEST] <Lucas93> memory taste [01:38:04 CEST] <J_Darnley> BradleyS: hah [01:38:17 CEST] <BradleyS> it's your fault, you know [01:38:21 CEST] <J_Darnley> indeed [01:38:24 CEST] <BradleyS> :) [01:38:40 CEST] <BradleyS> i've seen that site before but sure enough, i'm reading it again [01:41:03 CEST] <J_Darnley> I'm wondering whether the newest update it says is before or after I last saw it. [01:41:43 CEST] <J_Darnley> 2013? Could be after. [01:42:04 CEST] <BradleyS> "My husband tried to install a new networking card. He said he opened it up, and all he found was a TV tube and some electronic parts -- no slots at all." [01:42:12 CEST] <BradleyS> some are real gems [01:45:13 CEST] <J_Darnley> I could spend the next couple hours reading more but I need to sleep. [01:45:15 CEST] <J_Darnley> Good night [01:45:45 CEST] <BradleyS> o/ [13:19:17 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:5868e7f562fc: avfilter/vf_alphamere: use the name 's' for the pointer to the private context [13:26:15 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:835fdf48e59b: avfilter/vf_showpalette: fix small cosmetics issue [13:47:46 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:c9473229c9ec: avfilter/af_acopy: check for error cases and handle them [13:47:47 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:a9500441a718: avfilter/vf_copy: check for error cases and handle them [14:59:18 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:9cee8975c3fe: avfilter/asink_anullsink: cosmetics [14:59:19 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:94b155e49bde: avfilter/copy: add forgotten check [14:59:20 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:f66458cfc757: avfilter/vsink_nullsink: cosmetics [17:04:15 CEST] <Chagall> hm, I wanted to write a description for the patch but it seems git sent a second email with it [17:04:45 CEST] <Chagall> should I have written the text after the GIT: [patch metadata] line? [17:51:16 CEST] <cehoyos> jamrial: The original ivf question was "Why is a timebase written that is not x/1?" I suspect other applications always write "x/1" and then write the number of frames as "duration". The difference between time_base and framerate was discussed in the user channel yesterday [17:54:26 CEST] <Chagall> no, I was confused that it did not correspond to the inverse of the framerate because my reference was inaccurate [17:54:31 CEST] <Chagall> not related to this though [18:49:41 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:3bb170e530e3: avfilter/f_streamselect: add check case when nothing is done [19:53:38 CEST] <cone-527> ffmpeg 03Carl Eugen Hoyos 07master:a650e8c8e957: lavf/avio: Print https warning also for avio_find_protocol_name(). [19:56:59 CEST] <cehoyos> durandal_1707: Could you comment on lavfi/movie: Use filter threads as decoding threads ? [20:01:00 CEST] <durandal_1707> cehoyos: nope, i do not see such thing [20:05:02 CEST] <cehoyos> https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248909.html [20:15:57 CEST] <durandal_1707> cehoyos: ask nicolas, i do not want to have more crap with that nicolas "guy" [20:28:37 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:027a53dc4905: avfilter/vf_drawbox: reduce code duplication [20:28:38 CEST] <cone-527> ffmpeg 03Paul B Mahol 07master:1b2ed0c392f1: avfilter/vf_drawbox: implement process_command [20:44:35 CEST] <cone-527> ffmpeg 03Lou Logan 07master:61b7676bd5a6: cmdutils: trailing options may be ignored [21:04:54 CEST] <durandal_1707> nobody cares for MLP/PCM-DVD in MPG? [21:05:31 CEST] <JEEB> wasn't MLP meridian lossless? [21:05:41 CEST] <JEEB> I thought that was primarily in MPEG-TS [21:05:46 CEST] <JEEB> and not MPEG-PS [21:05:54 CEST] <cehoyos> I believe there was a page with a description but couldn't find it yesterday: Wait a day or two and push [21:06:57 CEST] <JEEB> oh... [21:07:03 CEST] <JEEB> so this is bitstreamed MLP [21:07:06 CEST] <JEEB> within PCM [21:07:17 CEST] <cehoyos> DVD-A [21:07:21 CEST] <JEEB> right [21:07:38 CEST] <durandal_1707> JEEB: see mpv bug report about some unwatchable japenese song, it is DVD-PCM within 0xa1 [21:08:24 CEST] <JEEB> yea I saw you replying to a bug report but I thought it was just a demux issue and not a "probe bitstreamed formats" kind of thing [21:12:38 CEST] <cehoyos> It is both [21:13:08 CEST] <JEEB> in the sense that the demuxer does the probing, yes [21:13:37 CEST] <cehoyos> the mpeg-ps demuxing depends on the codec_id [21:13:46 CEST] <JEEB> well yes [21:15:13 CEST] <JEEB> my current understanding just is that this is about probing the contents of the data within the packet as read from the MPEG-PS layer as opposed to reading identifiers in the container itself. for some reason I mostly just differentiate between those two activities [21:16:02 CEST] <cehoyos> Where is the "border" (is that the right word?) between the demuxer layer and the content layer? [21:16:27 CEST] <cehoyos> I ask because arguing that the actual content of pcm has data apart from the audio seems strange to me [21:17:40 CEST] <JEEB> well, generally containers have a way of giving out payloads. such as if I recall correctly PES in MPEG-TS? or when you get samples in MP4 [21:18:26 CEST] <JEEB> and in case of audio DVD or so I wouldn't be surprised if the contents of the payloads would be PCM with bit streaming, in which case yes - the PCM would in itself be a container then [21:18:39 CEST] <cehoyos> I thought this patch has nothing to do with the "payload" but I may misremember [21:18:48 CEST] <JEEB> I might be incorrect as well :) [21:18:56 CEST] <JEEB> with a quick look that's just what first came to my mind [21:19:34 CEST] <JEEB> if it's actual non-payload data then great :) although it'd be great if there was a reference about that stuff [21:19:47 CEST] <JEEB> I will guess H.222 2017 ed. wouldn't have this stuff? [21:20:16 CEST] <cehoyos> But luckily, we are not in a situation where we have a "reference" but no sample but we have samples which should suffice! [21:21:03 CEST] <kierank> there are mlp dvds [21:21:03 CEST] <JEEB> well, I generally like to also know the "why" :) [21:21:04 CEST] <kierank> I could buy one [21:21:14 CEST] <JEEB> kierank: we have samples already I think [21:21:49 CEST] <cehoyos> The why seems trivial to me: There are pcm, pcm-dvd and mlp in dvd-a [21:22:55 CEST] <JEEB> yes, but at least looking at the patch I cannot grasp the structure or flags that are being read [21:23:15 CEST] <JEEB> just that "read 24 bits and check the bottom 8 for being 0x80) [21:23:56 CEST] <cehoyos> If it were simpler, I may have succeeded... [21:24:11 CEST] <cehoyos> As said: There is a page, I didn't find it yesterday [21:25:07 CEST] <JEEB> anyways, I'm not in the business of blocking the patch. I just cannot easily verify it other than "this certain sample now plays" :) [21:25:32 CEST] <cehoyos> I should try to find my aob samples... [21:26:20 CEST] <JEEB> also thanks for replying to that one movenc person. I've been meaning to take a look at his patch for weeks but unfortunately I've had other things pop up that've been taking priority [21:26:41 CEST] <JEEB> thankfully I did have the time back then to note that his cause for needing the patch most likely was the sudden raise in the default ffmpeg.c time base [21:27:08 CEST] <JEEB> many subtitle formats used to have 1:1000 as their time base, but now they're 1:1000000 or so by default [21:27:35 CEST] <JEEB> (and regarding the fate test, which he seems to have made?) [21:29:24 CEST] <cehoyos> I am not sure that this is the (sole) issue, I just wanted to threaten to push this if it fixes the ticket. [21:30:19 CEST] <JEEB> well, if you have an empty subtitle sample until the following thing (be it end or start or so?) it's much harder to hit INT_MAX with the duration if your time base is 1:1000 compared to 1:1000000 [21:30:30 CEST] <durandal_1707> 3rd byte of PCM-DVD header is always 0x80, thats why [21:30:55 CEST] <JEEB> I recently hit that when testing something I've been brewing for a while and hopefully will be able to post on the ML soon :) [21:55:43 CEST] <cone-527> ffmpeg 03Carl Eugen Hoyos 07master:7ffa458d600e: lavfi/movie: Use filter thread count for decoding threads. [21:56:57 CEST] <JEEB> durandal_1707: thanks for that explanation :) is that part of the SPDIF header in the PCM payload of MPEG-PS or is that a container layer thing? [21:57:12 CEST] <JEEB> if it's the bit streaming part that might be simpler to reference, maybe? [21:57:28 CEST] <durandal_1707> it is DVD-PCM headerr [21:58:02 CEST] <JEEB> ok, sorry. then I just don't know enough context [22:02:13 CEST] <wbs> is there some mailing list moderator around? I tried sending one mail to the list two hours ago, but it didn't make it through [22:02:44 CEST] <durandal_1707> you are being banned? [22:07:58 CEST] <cone-527> ffmpeg 03Carl Eugen Hoyos 07master:87b7e141a6fd: lavc/x264: Use FF_CODEC_CAP_INIT_THREADSAFE if x264 is new. [22:18:57 CEST] <cone-527> ffmpeg 03Michael Niedermayer 07master:c4de49edc465: avformat/electronicarts: If no packet has been read at the end do not treat it as if theres a packet [23:51:28 CEST] <jamrial> wbs: are you subscribed? the list is subscriber only now [00:00:00 CEST] --- Wed Oct 2 2019

1 0

ffmpeg.log.20191001
by burek 02 Oct '19

02 Oct '19

[00:00:10 CEST] <kepstin> ztube: well, do you want to write a libdvdread/libdvdnav input format for ffmpeg? :/ [00:02:17 CEST] <ztube> Well I don't have any experience with that ^^ So propably not [00:12:07 CEST] <furq> ztube: tccat from transcode does an ok job [00:12:31 CEST] <furq> a bunch of distros stopped packaging it for some reason though [00:13:14 CEST] <kepstin> furq: do you know if it grabs the audio/subtitle track language metadata? [00:13:39 CEST] <furq> no idea [00:13:57 CEST] <ztube> I'll try [00:15:53 CEST] <ztube> just had a look at the IFO with a hex editor, seems as if it is quite easy for a human to determine the metadata, however the order of the tracks seems to be scrambled by ffmpeg, that's strange. Could this be due to multithreading when repacking into mkv? [00:17:14 CEST] <furq> Stream #0:3[0x20]: Subtitle: dvd_subtitle [00:17:17 CEST] <furq> doesn't look like it [00:17:25 CEST] <furq> i forget if metadata shows up there though [00:18:19 CEST] <fulaphex> hello, I'm trying to stream my desktop to another linux machine, but I find the documentation extremely complicated and I don't know what exactly I'm trying to set up [00:19:49 CEST] <ztube> https://pastebin.com/YedYjDYe This is the important part of an IFO in a hex editor. The first part would match the audio tracks, and the second one the subtitles respectively. Strangely enough there is only one english audio track in the resulting file, whereas in the IFO there are multiple ones [00:19:54 CEST] <fulaphex> what kind of command should I run from the pc that's creating the stream? how should I connect to the stream from another machine? will the stream be accessible on ip:port? or do I need to specify in ffmpeg to which macine I'm streaming? [00:20:09 CEST] <kepstin> ztube: some other fun issues with using ffmpeg to read vob files directly include that it doesn't know the aspect ratio, and it can't handle multi-angle stuff [00:20:56 CEST] <kepstin> ztube: libdvdnav already abstracts all that stuff away, the way to do this properly is to use libdvdnav to read the dvd structure :/ [00:21:17 CEST] <furq> it'll mess up stuff like subtitle palettes as well [00:21:36 CEST] <kepstin> hmm, yeah, the palettes are in the ifo too, aren't they [00:21:39 CEST] <furq> yeah [00:21:50 CEST] <ztube> I typically don't have multiple angles and aspect ratio seems to work properly as well, my only problem is the metadata [00:22:05 CEST] <kepstin> trust me, the aspect ratio is wrong ;) [00:22:32 CEST] <furq> yeah if you're not setting the ar somewhere then it's definitely wrong [00:25:01 CEST] <ztube> Hmm maybe some combination of lsdvd and mkvpropedit, sounds really error-prone though [00:25:18 CEST] <kepstin> i think ffmpeg will just use 1:1 sar when reading vob files? which will make the resulting aspect ratio somewhere in-between fullscreen and widescreen [00:25:49 CEST] <kepstin> (for ntsc, i can't remember how pal aspect ratios work) [00:26:45 CEST] <ztube> Aspect ratio is just metadata aswell for mkv right? then it should be possible to change it quickly [00:27:02 CEST] <kepstin> you can override it at the container level in mkv, yes [00:27:57 CEST] <ztube> Since lsdvd tells me the aspect ratio, I could write a script for that [00:28:47 CEST] <ztube> However I still have the issue of ffmpeg scrambling the subtitles/audio tracks [00:30:47 CEST] <kepstin> i think it normally puts them in the order of their stream ids? but vob is one of those kinda weird formats, so they might be in the order of "whichever stream's packets it sees first" [00:31:30 CEST] <ztube> ffmpeg -analyzeduration 1000M -probesize 1000M -fflags +genpts -i CONCAT.VOB -c copy -threads 4 -map 0:v -map 0:a -map 0:s "/media/video/$TITLE/$TITLE.mkv" [00:32:03 CEST] <kepstin> yeah, checked on a couple files with ffprobe, they're in random order [00:32:25 CEST] <kepstin> your best option might be to check what order they're in the file with ffprobe - that'll match the order that ffmpeg writes them to the mkv [00:32:46 CEST] <ztube> For audio at least the first track is at the right position, however after that it seems to be exactly reversed [00:33:03 CEST] <kepstin> the "id" field in ffprobe -show_streams should match some info from lsdvd, probably [00:56:26 CEST] <furq> ztube: the easiest and probably most correct way of setting ar from a dvd source is -vf setsar=12/11 [00:56:36 CEST] <furq> or whatever it says in https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_com… [00:57:01 CEST] <furq> you can set it in the container but you should only really do that if you already encoded something and don't want to do it again [00:57:10 CEST] <furq> and also remember you need to adjust for any cropping you did [00:59:14 CEST] <furq> it'd be nice to have ITU_PAL_FS = 12/11 constants in setsar [00:59:16 CEST] <furq> or something along those lines [07:22:20 CEST] <TheDcoder> Hello everyone, I am downloading audio from an online video stream and it is encoded in AAC (audio/mp4;codecs=mp4a.40.5), however when I play it back, the audio is feels much deeper (the voice of a female sounds very deep) [07:23:07 CEST] <TheDcoder> I have no idea why, the browser is able to play it back properly, any way I can restore the audio? [07:23:27 CEST] <TheDcoder> The audio also seems to have some degradation in quality... not sure why [12:46:42 CEST] <neildarlow> loudnorm and dual_mono. If I set my single-channel mono podcast target TP to -16 will dual_mono reduce TP to -19? Do I have to specify dual_mono on both passes of loudnorm in two-pass mode? [13:03:30 CEST] <ralphcor> Hi, I want to pluck A&V from the middle of an MP4. I've read https://trac.ffmpeg.org/wiki/Seeking and I'm doing ffmpeg -ss $from -i in.mp4 -t $len -c:v copy -c:a copy -sn out.mp4 I understand why the video starts from the I-frame before the -ss, and that if I transcoded then I would get an accurate cut, but I want to copy. However, I'd be happy to transcode the initial fragment from the -ss to the next [13:03:32 CEST] <ralphcor> I-frame and then copy from then on. I'm surprised that I failed to find how to do this, simply, anyway. Keen to hear learned opinion. Thanks. [13:04:08 CEST] <JEEB> that needs its own implementation and you'd have to be able to match the configuration of the original stream well enough [13:04:25 CEST] <JEEB> so that the parmaeter sets with H.264 or HEVC for example would match what's in the original stream [13:04:44 CEST] <ralphcor> Ah, okay, otherwise the `join' would be noticeable? [13:05:24 CEST] <JEEB> the newly transcoded stuff would have a different required parameter sets and that would cause decoding issues for the newly added stuff [13:06:22 CEST] <ralphcor> Oh, I didn't realise that information flowed across I-frame boundaries. I thought that each run of frame starting with I-frame was self-contained. I see. [13:07:38 CEST] <ralphcor> It's h264 (Main) (avc1 / 0x31637661) BTW. [13:12:24 CEST] <cehoyos> "decoding issues" == it would fail hard [13:12:48 CEST] <cehoyos> Note that while it would work fine for older codecs, the feature was never implemented [13:12:57 CEST] <cehoyos> in FFmpeg [13:13:46 CEST] <JEEB> ralphcor: parameter sets are the initialization data for the stream. while you can have multiple, synchronizing them can be fun and thus generally you keep to a single set of them [13:14:06 CEST] <JEEB> thus your newly transcoded content should in such cases match the original content to make sure there are no issues with decoding [13:16:01 CEST] <ralphcor> Right, so otherwise it would have to be PSets for the transcoded intro and then the original PSets inserted for the following copy. [13:19:08 CEST] <JEEB> yup [17:40:10 CEST] <cehoyos> Is the ivf guy around? [17:40:27 CEST] <cehoyos> Chagall: Are you here? [17:41:29 CEST] <Chagall> yes [17:42:30 CEST] <cehoyos> How did you test your patch? [17:43:39 CEST] <cehoyos> I don't think it works and I think it works without your patch. [17:43:47 CEST] <cehoyos> (as written yesterday) [17:45:15 CEST] <Chagall> ah, I didn't see anything in my log, sorry [17:46:08 CEST] <cehoyos> [23:30:16 CEST] <cehoyos> FFmpeg does write the video duration [17:48:17 CEST] <cehoyos> Note that you are claiming on the mailing list that the file "ivf_parser.h" "handles" a field - header files in general do not handle anything, it seems to me that the corresponding C++ file also does not "handle" the duration (but I may be wrong) [17:48:39 CEST] <cehoyos> Anyway: Please test again without your patch and if you can reproduce the issue you are trying to fix, please tell me how! [17:54:52 CEST] <Chagall> still rebuilding to check [17:55:41 CEST] <Chagall> I lost your message(s) in scrollback so I wasn't careful, mb [17:56:27 CEST] <cehoyos> The duration and the time_base are closely related: It is not useful to write the number of frames if the time_base is not the inverse of the framerate (which it might be) [17:56:43 CEST] <cehoyos> But FFmpeg already writes the duration (unless you kill the application hard) [17:56:58 CEST] <cehoyos> or the output file is not seekable [17:57:04 CEST] <cehoyos> What did you lose? [17:59:01 CEST] <Chagall> about 20 mins around the message you just reposted [17:59:22 CEST] <cehoyos> You mean you lost yesterday's history, not today? [17:59:29 CEST] <Chagall> yes [17:59:44 CEST] <cehoyos> There was no more about the duration than my comment above. [18:15:57 CEST] <Chagall> it seems the program i'm using might not be fetching the number of frames correctly, because i'm getting identical output before and after, though it doesn't seem to be correct. with the master branch just compiled i'm also getting invalid timestamps from mpv, though as you mentioned seeking works so the duration seems coded correctly. again though no visible difference with my patch that I've been able to verify [18:18:54 CEST] <cehoyos> It would make more sense if you run ffmpeg -i on the output file to see if a duration was written and is read by FFmpeg. [18:22:02 CEST] <Chagall> cehoyos: I get a duration of 708:16:00.00 for a clip that's a few seconds converted from mp4 with a time base that's not the framerate's inverse [18:22:08 CEST] <Chagall> same on master, btw [18:22:23 CEST] <cehoyos> So there is a bug, good to know! [18:22:44 CEST] <cehoyos> I only have to reproduce it now... [18:22:46 CEST] <Chagall> I don't think IVF has an actual "duration" field does it? it must be inferred from pts and display rate [18:22:53 CEST] <cehoyos> What do you mean with "same on master"? [18:23:24 CEST] <Chagall> my installed ffmpeg is built from master [18:23:32 CEST] <Chagall> and I test my change with a local build [18:23:42 CEST] <cehoyos> Only master is supported, no other versions [18:23:53 CEST] <Chagall> N-95183-g97450d2b6a [18:24:14 CEST] <Chagall> maybe from yesterday [18:25:08 CEST] <cehoyos> I cannot reproduce... [18:25:29 CEST] <Chagall> cehoyos: with what commands/clips? [18:25:31 CEST] <cehoyos> Remuxing vp9 from mp4 to ivf leads to a file that shows the same duration as the mp4 file (the actual duration) [18:25:52 CEST] <Chagall> can you send the vp9 sample? [18:25:57 CEST] <cehoyos> ffmpeg -i input -vcodec vp9 -an out.mp4 && ffmpeg -i out.mp4 -vcodec copy out.ivf [18:26:23 CEST] <cehoyos> You can use -f lavfi -i testsrc2 to create a vp9 sample which will allow us to test the same thing [18:26:55 CEST] <cehoyos> I used fate-suite/svq3/Vertical400kbit.sorenson3.mov as input [18:26:56 CEST] <Chagall> ok [18:27:16 CEST] <cehoyos> As expected, a timebase of 15360 was written [18:29:22 CEST] <Chagall> still an absurd duration on my end [18:29:44 CEST] <Chagall> um, time base seems wrong actually, it is 25 [18:30:34 CEST] <Chagall> I will rebuild again [18:32:13 CEST] <kepstin> from a quick look, i think ffmpeg might be writing/reading duration from the ivf field header that's supposed to hold frame count? [18:32:28 CEST] <cehoyos> I successfully tested the following: ffmpeg -f lavfi -i testsrc2 -vcodec vp9 -t 3.5 out.mp4 && ffmpeg -i out.mp4 -vcodec copy out.ivf [18:32:46 CEST] <cehoyos> It makes no sense to write the frame count (unless the time_base is 1/framerate) [18:33:17 CEST] <kepstin> sure it doesn't make any sense, but it is what it is [18:34:27 CEST] <cehoyos> The assumption that we should not honour the existing fields but some text makes not much sense in general and is known to be wrong for things related to VPx (where the specification only has an informatioal character) [18:34:33 CEST] <kepstin> libvpx for reference: https://github.com/webmproject/libvpx/blob/master/ivfenc.c#L31 [18:34:40 CEST] <kepstin> writes a 32bit frame count [18:35:25 CEST] <cehoyos> That can lead to a wrong duration [18:36:05 CEST] <cehoyos> Please note the comment! ;-) [18:36:12 CEST] <kepstin> yep, if you read the frame count field from the ivf field as a duration, then you will get the wrong duration [18:36:20 CEST] <cehoyos> Read the comment! [18:37:05 CEST] <cehoyos> Note that I did not say that this will lead to a wrong "length" in libvpx, it would lead to a wrong length if used 1:1 in FFmpeg [18:37:48 CEST] <cehoyos> I suspect that in libvpx, the assumptions time_base == 1/framerate and cfr will hold. [18:41:19 CEST] <kepstin> that appears to be true in most cases, but vpxenc does allow arbitrary rational timebases. [18:41:25 CEST] <kepstin> (and still writes frame count) [18:41:42 CEST] <cehoyos> Then - according to the comment in the code - you have found a bug in libvpx [18:42:11 CEST] <Chagall> "length" is ambiguous, does not imply the same thing as duration IMO [18:42:13 CEST] <kepstin> which comment, the one-word comment "length" that can be interpreted ambiguously as either "length in frames" or "length in timebase units"? [18:43:08 CEST] <kepstin> https://chromium.googlesource.com/chromium/src/media/+/master/filters/ivf_p… explicitly says "number of frames in file" fwiw [18:43:17 CEST] <cehoyos> Please understand that there are (literally) hundred of known and many unknown bugs in FFmpeg that are reproducible and wait for someone to work on them - you have not found a bug today. [18:43:59 CEST] <kepstin> that chromium code also uses a 32bit field, not 64bit. [18:44:38 CEST] <cehoyos> Patch probably welcome! [19:05:21 CEST] <Chagall> cehoyos: sent a patch for that then. [19:05:45 CEST] <Chagall> not going to argue about length but I added a comment to clarify at least can split into 2 commits if preferred [19:06:18 CEST] <cehoyos> Did you test fate with the patch applied? [19:06:21 CEST] <Chagall> yes [19:06:26 CEST] <cehoyos> The comment should be a separate patch. [19:06:43 CEST] <Chagall> ok. [19:06:52 CEST] <cehoyos> The second one is unneeded though [19:07:35 CEST] <kepstin> Chagall: the demuxer should save the frame count into st->nb_frames not st->duration i think [19:07:47 CEST] <Chagall> it's confusing to read the code without it and does not change the line count [19:08:10 CEST] <Chagall> like I said I won't argue about length vs frame count [19:08:17 CEST] <Chagall> leaving that how it is [19:09:27 CEST] <kepstin> i'm too lazy to send it to the ml right now, but here's my more complete fix: https://www.kepstin.ca/dump/0001-ivfdec-ivfenc-Match-behaviour-of-libvpx-an… [19:10:02 CEST] <cehoyos> Breaks the command line I posted above [19:10:24 CEST] <cehoyos> Sorry: Breaks all command lines (no duration) [19:10:33 CEST] <kepstin> exactly, because ivf doesn't store a duration [19:10:53 CEST] <cehoyos> This is not a helpful comment [19:11:17 CEST] <cehoyos> I am not a native speaker but "lenght" is certainly not the number of frames [19:11:28 CEST] <cehoyos> I am not a native speaker but "length" is certainly not the number of frames [19:11:34 CEST] <kepstin> https://chromium.googlesource.com/chromium/src/media/+/1681b9abff73fe0e3d09… has a better comment then [19:11:52 CEST] <kepstin> and "length" is ambiguous - number of frames is one way of counting length [19:12:05 CEST] <cehoyos> No, the world is not cfr [19:12:33 CEST] <kepstin> the ivf format is an extremely simple format where the creators apparently didn't realize that, and so they didn't include a correct duration field [19:13:20 CEST] <cehoyos> You will have to agree to disagree with the FFmpeg developers [19:13:34 CEST] <kepstin> ffmpeg disagrees with libvpx, which is a bigger problem [19:13:42 CEST] <cehoyos> I don't think it does [19:14:01 CEST] <kepstin> libvpx writes a *frame count* field. I've provided references in my commit message in my patch that show that [19:14:13 CEST] <kepstin> chromium's parser explicitly documents a *frame count* field [19:14:25 CEST] <cehoyos> Yes, for libvpx this is the "length" of the stream. In FFmpeg, it wouldn't be [19:14:31 CEST] <cehoyos> Can we stop this? [19:14:41 CEST] <cehoyos> Just send your patch to the mailing list, I may be wrong after all [19:14:51 CEST] <kepstin> libvpx writes a frame count even if you set a timebase which is not 1/framerate [19:15:01 CEST] <kepstin> (specifically, vpxenc.c) [19:15:13 CEST] <cehoyos> As said, please stop it [19:17:34 CEST] <Chagall> kepstin: please do send it to ML [19:18:28 CEST] <kepstin> let me at least compile-check it and make sure it either doesn't break fate or that i update fate tests, first :) [19:32:48 CEST] <Chagall> cehoyos: should avformat patch version increase with the 64-bit to 32-bit field change? [19:33:07 CEST] <cehoyos> Not if you only change the demuxer as requested [19:33:40 CEST] <Chagall> got it [19:33:44 CEST] <cehoyos> You can of course bump micro on every patch but some developers don't like it because it triggers a recompilation of the whole library [19:48:15 CEST] <Diag> hey regarding a few weeks ago when i was gonna build ffmpeg on my ps3 [19:48:52 CEST] <Diag> it was building and something failed because of a missing dependency, got distracted, redid thermal shit and other shit [19:49:19 CEST] <Diag> at some point along the way it randomly decided to stop working and i couldnt be assed to start investigating it yet, so [20:08:27 CEST] <safinaskar> hi. i want to generate raw uncompressed rgb video from my c program without external libs and then feed it to ffmpeg, i. e. i want ffmpeg to convert this raw video to some "normal" format. also i want such raw video to contain very minimal metainformation about this video (in fact, i need frame size only). so, i need some file format (or [20:08:27 CEST] <safinaskar> "muxer" or "container" in ffmpeg term), that should be very simple (so that i can generate it from my program easily) and that should contain frame size. in other words i need something like blind ( https://tools.suckless.org/blind/ ), but blind itself will not go, because it is not rgb and because it is not supported by ffmpeg. "-f [20:08:28 CEST] <safinaskar> rawvideo" will not go, because such rawvideo doesn't contain frame size. "-f yuv4mpegpipe" will not go, because it is YUV, but i need RGB. "-f nut" is good candidate. as well as i know nut supports storing raw video. but nut's spec is too difficult for me. so? [20:09:26 CEST] <cehoyos> You will have to decide: Either "rawvideo" or "metadata" [20:09:40 CEST] <furq> ppm pipe maybe [20:09:58 CEST] <furq> or bmp pipe if you don't mind sending every row backwards [20:12:15 CEST] <furq> http://netpbm.sourceforge.net/doc/ppm.html#format [20:12:31 CEST] <furq> then -f image2pipe -c:v ppm -i - [20:13:30 CEST] <safinaskar> cehoyos: "Either "rawvideo" or "metadata"" - i choose metadata [20:13:42 CEST] <safinaskar> cehoyos: i mean uncompressed video with metadata [20:13:47 CEST] <furq> safinaskar: ^ [20:14:05 CEST] <furq> if you only care about frame size and not framerate etc then ppm pipe is the easiest way out [20:21:12 CEST] <safinaskar> ok, thanks, i choose ppm pipe [21:33:34 CEST] <taliho> Hi, I'm muxing h264 into flv with [21:33:52 CEST] <taliho> ./ffmpeg -f mpegts -i udp://192.168.0.104:6500 -map 0:0 -codec:v libx264 -x264-params keyint=100:scenecut=0 -bsf:v extract_extradata -f flv udp://127.0.0.1:10000 [21:36:29 CEST] <taliho> the resolution of my input can change so that's why I have the bsf filter. My goal is flv to resend the headers when parameter sets change so this can be detected by the server (please ignore desting udp, I'm actually using rtmp) [21:37:16 CEST] <taliho> but it seems that when muxing with flv all the pps/sps parameter sets disappear from the stream, so the bsf filter is actually not inserting any data [21:37:46 CEST] <cehoyos> I don't think ffmpeg supports changing output resolutions [21:37:59 CEST] <cehoyos> And I don't think you need the filter [21:39:57 CEST] <taliho> ok, let me just try to dump raw to udp and if I see a resolution change [21:40:33 CEST] <cehoyos> If you increase verbosity, you should get a message that a scaling filter was inserted [21:45:21 CEST] <JEEB> &25 [21:50:31 CEST] <djp_> looking for advice regards using deinterlacing. i've dumped a dvd to my hard disk and checked it using the mediainfo command. it shows that the dvd is interlaced and its scan order is top field first. i've been using variations of commands with the yadif filter, for example "-vf yadif=1:-1:0". i've also tried "-vf yadif=1:-1:0,mcdeint=2:1:10" but this takes an age!!! is there a recommended solution for deinterlacing a dvd rip or is it best to leave it alone [21:50:31 CEST] <djp_> and let the media player deal with it? [21:53:07 CEST] <cehoyos> mediainfo cannot tell you if the video is interlaced [21:53:11 CEST] <cehoyos> the idet filter can [21:53:26 CEST] <cehoyos> mcdeint is slow [21:56:31 CEST] <furq> djp_: if you're not going to use something incredibly slow then you might as well just encode it interlaced and deinterlace it on playback [21:56:40 CEST] <furq> mpv et al just use yadif anyway [21:56:53 CEST] <djp_> cehoyos, oh i see. so i should ignore the output that reads "Scan type: Interlaced" and "Scan order: Top Field First" when running mediainfo? [21:57:00 CEST] <furq> all dvds say that [21:57:17 CEST] <furq> you're best off just looking at it [21:57:33 CEST] <djp_> furq, ah right. sure. [21:57:40 CEST] <furq> anyway personally i like vapoursynth qtgmc for dvds [21:57:40 CEST] <JEEB> content != coding, unfortunately [21:57:48 CEST] <furq> but that's a whole lot of stuff to set up [21:57:59 CEST] <furq> and also very slow [21:59:31 CEST] <der_richter> and it won't ITVC, which is also likely needed for DVDs [21:59:40 CEST] <cehoyos> If you have many dvd's you don't have to look, you can also use idet [21:59:46 CEST] <furq> well it'll usually be one or the other [22:00:01 CEST] <djp_> furq, so using mcdeint is probably a good option, as long as time is not an issue. otherwise just let the player do the work. [22:00:02 CEST] <furq> ivtc for film, deinterlace for video [22:00:14 CEST] <cehoyos> Mixed telecined and interlaced exists [22:00:26 CEST] <furq> if you're very unlucky, sure [22:00:32 CEST] <cehoyos> yadif should be a lot faster than mcdeint [22:00:38 CEST] <der_richter> there is also mixed DVDs [22:00:59 CEST] <djp_> cehoyos, mixed telecined? i think i have that on some old studio ghibli dvds? [22:00:59 CEST] <furq> i've only ever encountered one [22:00:59 CEST] <der_richter> what cehoyos said [22:01:02 CEST] <furq> perks of living in a pal region [22:01:08 CEST] <taliho> cehoyos: thanks. I think you are right, it seems that a scaling filter is inserted when the input resolution changes. Although, I do not see a log message even with trace [22:01:25 CEST] <cehoyos> Should be verbose [22:01:32 CEST] <djp_> cehoyos, yes, if i use yadif on its own, it is fast. [22:01:36 CEST] <der_richter> pal DVDs can also be kinda cool, like speed up progressive material. easy to fix. [22:01:55 CEST] <taliho> cehoyos: sorry the message is there :) [22:01:57 CEST] <cehoyos> I still like yadif's quality but there may be better filters [22:02:09 CEST] <furq> bwdif is supposedly slightly better than yadif [22:02:17 CEST] <furq> neither is particularly amazing on sd content though [22:02:30 CEST] <kepstin> i find yadif has slightly annoying artifacts on diagonal lines in sd content. [22:02:33 CEST] <furq> yeah [22:02:44 CEST] <furq> i've never used anything other than qtgmc that didn't have those [22:03:01 CEST] <furq> with that said i could never get mcdeint working right [22:03:10 CEST] <furq> and ffmpeg nnedi3 is just a waste of time [22:03:23 CEST] <durandal_1707> shit talk from furq [22:03:53 CEST] <kepstin> well, at least if you leave ffmpeg nnedi3 running in the background on a modern multi-core computer, it won't interfere with anything else you're doing ;) [22:03:55 CEST] <djp_> cehoyos, are my settings correct for yadif? "yadif=1:-1:0". [22:04:23 CEST] <furq> someone should try to convince the nnedi3cl author to relicense it under lgpl [22:05:09 CEST] <cehoyos> djp_: It depends - do you want to double framerate? [22:05:39 CEST] <kepstin> djp_: fwiw, that's equivalent to "yadif=mode=send_field" (all the other options listed are defaults) [22:06:03 CEST] <cehoyos> (doubling framerate likely doubles encoding time) [22:06:11 CEST] <djp_> cehoyos, not sure. is that a good option or should i keep it as is? [22:06:27 CEST] <furq> you generally want to double the framerate when deinterlacing [22:06:36 CEST] <djp_> cehoyos, doesn't make much of a difference in my encoding time. [22:06:40 CEST] <furq> it'll look a lot nicer and it won't hurt the size that much [22:06:47 CEST] <kepstin> it makes motion look smoother - preserves the motion from both fields in the interlaced video [22:06:53 CEST] <furq> it will definitely take longer to encode though [22:07:02 CEST] <djp_> ok [22:07:14 CEST] <furq> you'll get roughly the same fps but obviously there's 2x as many frames [22:07:31 CEST] <durandal_1707> w3fdif [22:07:38 CEST] <djp_> so i need to check that. thanks cehoyos , furq , kepstin and all. [22:09:12 CEST] <kepstin> i normally use bwdif, which in theory combines the strengths of yadif and w3fdif. But you should compare a few, pick the one that looks best on your video. [22:13:04 CEST] <taliho> cehoyos: do you think a resolution change would be an interesting feature to support? I guess just a reset of the all the components down the chain is needed.. It's something that I could work on [22:14:34 CEST] <cehoyos> It was just implemented;-) [22:14:36 CEST] <cehoyos> (iirc) [22:14:41 CEST] <cehoyos> But so far only for vp9 [22:14:56 CEST] <cehoyos> You should test first if it works in your use-case [22:15:03 CEST] <cehoyos> Or maybe it does work for x264? [22:15:06 CEST] <JEEB> hmm, I think libx264 had reconfig for quite a while [22:15:16 CEST] <JEEB> but it didn't work f.ex. for colorspace info changes [22:15:27 CEST] <cehoyos> No [22:15:31 CEST] <JEEB> for example if you don't at encoder init yet know the colorspace etc [22:15:39 CEST] <cehoyos> But test with vpx first [22:15:57 CEST] <taliho> I see, thanks, will look at that code [22:16:25 CEST] <JEEB> but yea, x264 mostly supported dynamic reconfig without major changes? and then you might have to re-init in your wrapper if you needed bigger changes. [22:17:07 CEST] <JEEB> and of course this would mostly work for in-band containers unless you somehow signal the new extradata :) [22:17:47 CEST] <cehoyos> https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/247365.html [22:17:54 CEST] <cehoyos> It seems the patch was not applied yet [22:18:04 CEST] <JEEB> :) [22:18:54 CEST] <taliho> thanks JEEB, cehoyos [00:00:00 CEST] --- Wed Oct 2 2019

1 0