September 2019 - Ffmpeg-devel-irc

ffmpeg.log.20190803
by burek 15 Sep '19

15 Sep '19

[01:49:36 CEST] <dastan> hello people [01:50:07 CEST] <dastan> i am searching a way to passthrough one input streaming to a two different ffmpeg process [01:55:34 CEST] <DHE> dastan: could one ffmpeg process produce two different outputs for you instead? [02:10:03 CEST] <dastan> DHE [02:10:24 CEST] <dastan> i know but i need to use h264 for one process and prores to the other [02:10:44 CEST] <dastan> nd the speed of the codecs is different [02:11:43 CEST] <DHE> with a realtime source? [02:11:53 CEST] <dastan> yep [02:11:59 CEST] <dastan> the input is youtube [02:44:49 CEST] <Hello71> weren't you just asking that here [02:50:36 CEST] <martmists> Hey everyone, I'm trying to use ffmpeg to stitch videos together. Half of them are 1080p60, half of them are 640x400 at 25fps. I seem to be unable to convert these 640x400@20 files to 1080p60, no matter what I do. the code for the entire script is here: https://pastebin.com/2hDmkuDy [02:51:12 CEST] <furq> martmists: -filter:v and -vf are the same thing and you can only set it once [02:51:24 CEST] <furq> you want -vf scale=1920:1080,fps=60 [02:51:40 CEST] <martmists> I see [02:51:41 CEST] <furq> and ,setpts as well for the first one [02:52:32 CEST] <martmists> now i'm getting `[NULL @ 0000027cc396dac0] Unable to find a suitable output format for 'scale=1920:1080'` [02:53:00 CEST] <furq> you've got a stray option with no argument somewhere [02:53:19 CEST] <stevessss> I guess I could compile armabi version of libffmpeg in way that logs all library calls and then replace that in my zyplay app that doesnt say how it gets video url [02:55:43 CEST] <martmists> hm, now I specify 1920:1080 and it ssets it to 1920:1072... [02:57:22 CEST] <martmists> also, the original flv files are now sped up like 10 times? [03:01:42 CEST] <martmists> well not the original files, but the parts of the video corresponding to those files [03:04:57 CEST] <martmists> @furq any clue? [03:13:50 CEST] <kepstin> martmists: you added a setpts filter to speed them up... [03:14:39 CEST] <martmists> but that only applies to the generated files, and even if I removed it the flv files were still sped up [03:14:51 CEST] <kepstin> your final concat commmand has a setpts filter [03:15:02 CEST] <martmists> removed that too [03:16:14 CEST] <kepstin> if "ffmpeg -i input.mp4 -vf scale=1920:1080,fps=60 output.mp4" changes the video speed then there's something really weird going on. [03:17:12 CEST] <kepstin> (possibly an issue where it's reading the input file incorrectly) [03:17:40 CEST] <kepstin> if that's the case, i'd want to see the complete output of "ffmpeg -i input.flv" or whatever [03:17:47 CEST] <martmists> no, the last ffmpeg command changes the video speed of the flvs [03:18:58 CEST] <martmists> https://pastebin.com/wHvGf28Q here's one of the files [03:26:23 CEST] <kepstin> hmm, that seems fine. what's the complete command line and output of the last ffmpeg command, as you ran it? [03:27:45 CEST] <martmists> https://pastebin.com/Ek84ZGMC [03:28:25 CEST] <martmists> I terminated it early to see if the file was still sped up, and it was [03:58:05 CEST] <kepstin> hmm. my guess is that the inputs aren't all properly matching [03:58:35 CEST] <kepstin> i note that at least the pixel formats don't match, you should probably be using "-pix_fmt yuv420p" when encoding all the parts. [03:59:36 CEST] <kepstin> really hard to say what's up with all these separate files. [04:04:01 CEST] <kepstin> the concat demuxer is kind of weird to work with, you really want to make sure all your inputs are perfectly matching. [04:05:08 CEST] <kepstin> for this sort of thing, i'd normally recommend using the concat filter instead. You can probably do the whole video building in a single ffmpeg command by programmatically building a filter script, too. [04:05:33 CEST] <martmists> How would I go about doing that? [07:05:52 CEST] <rmmh> How do I get vp8 to output yuv444p? I've tried `-vcodec libvpx -vf format=yuv444p` and `-pix_fmt yuf444p`, but they still use yuv420p. (using ffmpeg 4.1.3) [08:10:51 CEST] <furq> rmmh: i don't think vp8 supports yuv444p [08:10:58 CEST] <furq> the libvpx wrapper in ffmpeg definitely doesn't [08:13:03 CEST] <rmmh> Ah. From the RFC, "VP8 works exclusively with an 8-bit YUV 4:2:0 image format." I found some commits adding yuv444p to the VP9 wrapper, and got confused. [08:15:29 CEST] <furq> https://clbin.com/FUET1 [08:15:31 CEST] <furq> that's the quickest way to check [08:26:27 CEST] <jbaxter> Hello! I'm trying to use the ffmpeg cli to transcode/add AAC audio streams to a bunch of videos. On some videos it errors out. I've stripped out the actual transcoding arguments and I'm having trouble with a few files, just doing a copy: https://pastebin.com/TfbZJfc8 [08:26:40 CEST] <jbaxter> the error is: Could not write header for output file #0 (incorrect codec parameters ?): Invalid data found when processing input [08:26:43 CEST] <jbaxter> any suggestions? [08:31:21 CEST] <jbaxter> Sorry I think the more relevant error is actually this: [adts @ 0x56130eac5720] MPEG-4 AOT 0 is not allowed in ADTS [08:31:45 CEST] <furq> what's $dest set to [08:33:54 CEST] <jbaxter> dest=$file.aac [08:34:00 CEST] <jbaxter> Oh dear [08:34:05 CEST] <jbaxter> I think I see the problem [08:34:34 CEST] <jbaxter> I might be an idiot [08:36:19 CEST] <jbaxter> Well that's now confirmed. Thanks for the help ;) [11:49:34 CEST] <JEEB> Guest48: the command line apps were made for file->file usage originally so they probably require a lot of stuff from the AVFormat/Contexts [11:49:46 CEST] <JEEB> which requires probing [11:49:51 CEST] <JEEB> is the probing the problem for you or what? [11:49:56 CEST] <JEEB> why are you trying to minimize it? [11:50:03 CEST] <JEEB> or more like [11:50:05 CEST] <JEEB> "do you need to" [11:50:31 CEST] <JEEB> also I hope you have posted your command line and full terminal output with -v verbose or so on a pastebin or so [11:50:36 CEST] <JEEB> and linked it here [11:50:42 CEST] <JEEB> to show where the actual problem is :P [11:51:20 CEST] <JEEB> as in, yes you get messages about missing resolution/frame rate etc, but where does it actually fail [12:00:09 CEST] <Guest48> Excuse me for the delay, @JEEB. Had to reset my pass. [12:00:15 CEST] <Guest48> https://pastebin.com/wWxBThDs [12:00:20 CEST] <Guest48> Basically, I have two streams starting at the same time and there is a condition in where it could occur that one stream does not become available after a certain amount of time, so I need to measure the time it takes before that stream actually starts streaming data, measure that time and itsoffset that time to make the videos run sync again later, next to each other. [12:00:37 CEST] <JEEB> right [12:00:44 CEST] <JEEB> sounds like something to use the API for, unfortunately [12:00:54 CEST] <JEEB> also for the record [12:01:03 CEST] <JEEB> framerate is an image input specific option, it's specific to a specific image2 module [12:01:08 CEST] <Guest48> @JEEB; yeah, that's becoming apparent [12:01:29 CEST] <JEEB> -r is the option that sets the frame rate, but in general it does nothing on the input side [12:01:31 CEST] <Guest48> @JEEB; that explains; Could be expanded, if you ask me, but that's a matter of taste. [12:01:48 CEST] <Guest48> @JEEB; -r; yep, figured that out too. [12:01:57 CEST] <JEEB> video_size is also probably specific to some module [12:02:13 CEST] <JEEB> ffmpeg.c or ffprobe.c do not differentiate between module AVOptions [12:02:19 CEST] <JEEB> and options of ffmpeg.c setting general values [12:02:38 CEST] <JEEB> basically what they cannot find in their options, they pass onto all the modules one at a time as AVOptions :P [12:04:24 CEST] <JEEB> anyways, yea. sorry. what you're doing starts sounding where the command line apps no longer cut and you need to start using the API [12:05:16 CEST] <Guest48> Yeah, I hear ya man. I'm using node.js; seems like this would suffice, wouldn't it? https://github.com/Streampunk/beamcoder [12:05:41 CEST] <JEEB> I have no idea to be honest [12:05:54 CEST] <JEEB> I have used FFmpeg's APIs through C, Python and Java [12:05:56 CEST] <Guest48> Yep, that certain seems like it should be able to do the trick. Native API bindings from node.js to FFmpeg. [12:06:12 CEST] <JEEB> but I have never utilized other people's wrappers around it [12:06:19 CEST] <Guest48> https://github.com/Streampunk/beamcoder/tree/master/src [12:06:21 CEST] <JEEB> well, ffms2 I have utilized for frame exact access but yunno :P [12:06:32 CEST] <JEEB> (that's a bit more higher level) [12:06:51 CEST] <JEEB> Guest48: anyways I hope that wrapper is good [12:06:57 CEST] <JEEB> I can't really vouch or not vouch for it [12:07:10 CEST] <Guest48> I hope so too. We're gonna find out, I guess. [12:07:18 CEST] <Guest48> Thanks, @JEEB! [12:07:20 CEST] <Guest48> :) [12:07:30 CEST] <JEEB> np [12:07:54 CEST] <JEEB> upipe had some nice things that I think could be useful in libavformat [12:08:05 CEST] <JEEB> like having three types of PTS in the packets [12:08:29 CEST] <JEEB> original timestamp, sanified timestamp (f.ex. MPEG-TS 33bit wrapping handled) and receipt timestamp [12:08:59 CEST] <JEEB> right now what you get from libavformat is something between the first and the second (it's supposed to be the second but the general wrap-around code seems to bork in some cases) [12:12:01 CEST] <Guest48> @JEEB, yeah, I will have to way my options and discuss here on what's feasible. This explains a lot on what I was struggling with though, @JEEB, so thanks again! :) [20:07:45 CEST] <dastan> hi people.... [20:13:02 CEST] <dastan> is it possible to download a HLS link and pass to multiple ffmpeg process? [20:21:39 CEST] <ChocolateArmpits> dastan, with scripting anything is possible [23:49:58 CEST] <n000g> Hi, I'm trying to set the options (x y w h) for the deshake filter. is -vf deshake=10:10:680:550 correct? Because that doesn't seem to do much on my very slightly shaky video. [23:56:56 CEST] <durandal_1707> have you read filter docs? [00:00:00 CEST] --- Sun Aug 4 2019

1 0

ffmpeg.log.20190826
by burek 15 Sep '19

15 Sep '19

[02:53:24 CEST] <Diag> Ok im frigdickin confused [02:54:17 CEST] <Diag> if i do -vsync 0 and it gives me ~10.5 fps of encoding, then do no vsync and i get 30 fps of encoding, and its coming from a live source [02:54:24 CEST] <Diag> what the happ is hellening [03:22:42 CEST] <Diag> Is it true that according to google, only vertical resolution/40 threads can be used for encoding [03:24:09 CEST] <DHE> depends on the codec. some of them split the frame into segments for encoding (sliced threading) in which case there is a limit to the slicing. some don't [03:24:16 CEST] <Diag> h264, sorry [03:24:24 CEST] <Diag> should have specified [03:24:51 CEST] <DHE> I believe vertical resolution/16 is the limit, but x264 has frame-based threading which is generally better (and the default) [03:24:51 CEST] <pink_mist> there's more than one option for encoding h264 in ffmpeg, it may depend on the specific encoder you're using [03:25:30 CEST] <Diag> theres more than one h264 cpu encoder? [03:25:44 CEST] <DHE> CPU based, I don't think so [03:25:46 CEST] <Diag> im using libx264 [03:26:19 CEST] <Diag> So is it invalid of me to specify -threads and just let it do what it wants to do [03:26:39 CEST] <Diag> I mean doing -threads 44 let me encode with veryslow instead of slow/slower [03:27:05 CEST] <DHE> wow are you using an e5-2699 for a single livestream? [03:27:38 CEST] <DHE> oh wait you had the funky 2696 [03:27:39 CEST] <Diag> 2696, but yeah [03:27:42 CEST] <Diag> im just recording [03:27:43 CEST] <Diag> :V [03:27:57 CEST] <Diag> Im the retard that uses sharex to snag clips of things [03:28:09 CEST] <furq> Diag: there's openh264 as well [03:28:12 CEST] <Diag> oh? [03:28:19 CEST] <DHE> don't use that. it's baseline only iirc [03:28:20 CEST] <furq> but that's baseline only afaik [03:28:20 CEST] <Diag> Is that worth taking a peek at? [03:28:22 CEST] <Diag> oh lol [03:28:22 CEST] <furq> it was until very recently [03:28:30 CEST] <DHE> something about licensing [03:28:31 CEST] <furq> it's cisco's thing for webrtc [03:28:34 CEST] <Diag> kek [03:28:40 CEST] <furq> they have some kind of patent indemnification clause in there [03:29:01 CEST] <Diag> Im lost as to if its the screen capture doohickey thing that sharex uses or ffmpeg being funky [03:29:17 CEST] <Diag> If i set vsync modes i get totally bizarre results [03:29:24 CEST] <furq> honestly for screen capture on windows just use obs [03:29:34 CEST] <Diag> Yeah but i like being able to draw a rectangle and record that [03:29:45 CEST] <Diag> because usually i only record things for 5-10 seconds [03:29:57 CEST] <Diag> Else i just use relive :shrug: [03:30:15 CEST] <Diag> Im going to pull up the capturer as a source and see if thats framerate is going funky or what [03:30:46 CEST] <Diag> Actually, im gonna ask, but i assume that the gdi grab in ffmpeg is so slow its not worth looking at? [03:31:19 CEST] <furq> depends [03:31:33 CEST] <furq> last time i tried it for a game it was not fast enough [03:31:46 CEST] <Diag> I 'never' do anything larger than probably 1280x1024 and mostly everything is just a window on the desktop [03:31:58 CEST] <furq> this was conveniently a 1280x960 window [03:32:05 CEST] <Diag> oh well imagine that [03:32:36 CEST] <furq> i assume it's not a game though because then you'd just use something with ogl/dx hooks for capturing [03:32:40 CEST] <Diag> Correct [03:32:54 CEST] <Diag> I just happen to be capturing an emulator in my test sample [03:33:07 CEST] <Diag> because it has multiple types of motion, and a static background [03:33:13 CEST] <Diag> basically the perfect test vid XD [03:33:45 CEST] <Diag> Framerate of that is 60, and its locked to the desktops refresh rate [03:34:29 CEST] <Diag> Ima give gdigrab a shot here and just see what that yields. The only issue is that i cant get around the beep beep -tune zerolatency in sharex really then [03:39:08 CEST] <Diag> furq: complains about a thread message queue, but it seems to report the proper framerate, ill test it real quick http://tyronesbeefarm.com/images/2019d1eb459d-c503-441f-90ed-692ae5de3a64.p… [03:40:21 CEST] <Diag> :shrug: here goes [03:41:47 CEST] <furq> just tried it on a better computer and it did ok [03:42:15 CEST] <Diag> is the gdigrab whatchamacallit threaded? [03:42:26 CEST] <Diag> obviously i slump a little in single thread performance [03:43:05 CEST] <furq> it'll probably be fine [03:43:17 CEST] <furq> just capture to ffvhuff and then you'll be able to turbo [03:43:18 CEST] <Diag> cool, i was just about to actually test it here [03:43:23 CEST] <Diag> kek [03:43:26 CEST] <furq> https://0x0.st/z4iC.mp4 [03:43:29 CEST] <furq> this is pretty passable [03:43:39 CEST] <Diag> oh wow yeah [03:43:41 CEST] <Diag> thats slammin [03:43:55 CEST] <Diag> I also love tetris [03:45:07 CEST] <furq> i don't think gdigrab got any better so idk why it actually works now [03:45:22 CEST] <Diag> Improvements in gdi? /s [03:45:24 CEST] <furq> probably because windows 10 is a much better operating system [03:45:40 CEST] <furq> sorry i have to go and rinse the sick out of my mouth now [03:45:46 CEST] <Diag> lol [03:50:36 CEST] <Diag> cpu usage appears lower.... [03:52:12 CEST] <Diag> ok, i see why it was slower [03:52:17 CEST] <Diag> its slow as balls [03:52:26 CEST] <Diag> was lower, not was slower* [03:55:03 CEST] <Diag> oh man i may have just realized what the forklift is goin on [04:04:13 CEST] <Diag> furq: what the hell happens if you specify the framerate *before* the input stream [04:04:27 CEST] <Diag> does it do some nonsense with the timestamps to try and pull out some frame timing whatever? [04:04:46 CEST] <furq> it just sets the input framerate [04:04:51 CEST] <furq> you'll presumably want -framerate 60 [04:04:58 CEST] <Diag> Yeah but like, how does it determine what to do [04:04:59 CEST] <furq> it defaults to 30 which i think just means it drops alternate frames [04:05:01 CEST] <Diag> Ah [04:05:02 CEST] <Diag> ok [04:05:22 CEST] <Diag> for some reason i have a feeling that that is whats giving me nonsense, so im trying 60 without specifying it [04:05:29 CEST] <Diag> because the stream is '60' itself [04:05:55 CEST] <Diag> so im gonna do that and vsync 0 and see what happens [04:06:41 CEST] <Diag> getting rid of the input framerate made it stop encoding at 10fps when i set vsync [04:07:03 CEST] <Diag> much like that kid behind the 7-11, my hopes are high [04:08:39 CEST] <furq> $ ffmpeg -framerate 60 -f gdigrab -i "title=HEBORIS C7-EX DirectX9" -c:v ffvhuff out.nut [04:08:42 CEST] <furq> that's all i did [04:08:56 CEST] <Diag> I switched off of gdigrab because gdigrab was horribly slow [04:09:00 CEST] <furq> oh right [04:09:12 CEST] <Diag> http://tyronesbeefarm.com/images/201985b75c16-8476-42e9-a7fc-987503bf7206.m… [04:09:24 CEST] <Diag> this is what i got, and ive got no idea if its zerolatency giving me that or what [04:10:18 CEST] <Diag> it only used like 10% cpu, and before i was using like 25-30 [04:11:20 CEST] <Diag> actually disregard, it DOES seem like its this stupid source thats the issue. gdi [04:11:37 CEST] <nicolas17> doesn't gdi stand for "god damn it"? [04:11:38 CEST] <furq> remember zerolatency turns off frame threading [04:11:45 CEST] <Diag> oh shit yeah [04:11:51 CEST] <furq> so that might explain the bad cpu usage [04:12:00 CEST] <furq> and slice threading is restricted by resolution [04:12:02 CEST] <Diag> Lemme build a command again. I was just trying to be faster [04:12:29 CEST] <furq> zerolatency is slower, perversely [04:12:33 CEST] <Diag> Sure [04:12:38 CEST] <furq> like i said you should never use it [04:12:41 CEST] <Diag> I mean literally me being faster [04:12:58 CEST] <Diag> Its default in sharex and i couldnt be assed to generate a new command for ffmpeg with it so i could get around it [04:13:10 CEST] <nicolas17> zerolatency for creating a video file makes no sense, it's designed for latency-sensitive live streaming [04:13:14 CEST] <furq> it's there specifically for doing realtime livestreaming for cctv or something where you absolutely must have <1sec latency [04:13:22 CEST] <Diag> Oh totally [04:13:27 CEST] <Diag> tell Jaex that [04:13:29 CEST] <nicolas17> video conferencing, cloud gaming... [04:13:31 CEST] <furq> i have [04:13:32 CEST] <Diag> XD [04:13:34 CEST] <furq> he wasn't interested [04:13:46 CEST] <Diag> *shakes fist angrily even though i like the software a lot* [04:14:12 CEST] <Diag> I wonder if theyre gonna be able to put 2 and 2 together and realize i was talking about this in the discord as well [04:16:29 CEST] <Diag> furq: im gonna assume "frame= 1125 fps= 29 q=-1.0 Lsize= 2304kB time=00:00:37.40 bitrate= 504.7kbits/s dup=869" means that the timestamps not changing on the input frames, or am i just stupid [04:22:37 CEST] <Diag> nah, gdigrab is just clunky for me :/ [04:47:04 CEST] <Classsic> Hi, somebody know why get stuttering playback when use "-use_wall_clock_as_timestamp 1"? [04:49:09 CEST] <Classsic> try this command: "ffmpeg -use_wallclock_as_timestamps 1 -probesize 10M -thread_queue_size 2048 -fflags +genpts -i rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov -an -copyts -fflags +genpts -vcodec libx264 -preset ultrafast -crf 27 -f flv -|ffplay -f flv -" [04:49:56 CEST] <Diag> Wouldnt that be because of discrepancies between timestamps on your machine, and timestamps on the source video? [04:50:24 CEST] <Classsic> exist any way to fix that? [04:50:40 CEST] <Diag> Im just talking out of my ass, im really not sure if thats it [04:51:07 CEST] <Classsic> you can try the command, so verify if get the same results. [04:51:17 CEST] <Diag> how big is the video file [04:51:30 CEST] <Classsic> is live rtsp input [04:51:41 CEST] <Diag> ah ok, gimme a sec ill have a go in a minute [04:51:42 CEST] <Classsic> very small resolution [04:51:48 CEST] <Classsic> great [04:57:29 CEST] <Diag> that command does like, sorta nothing [04:57:32 CEST] <Diag> for me* [04:59:14 CEST] <Classsic> play smoothly? [04:59:24 CEST] <Diag> oh nevermind i see what the deal was with mine [05:00:21 CEST] <Diag> Yeah, having that extra flag in there makes mine do nothing at all except bitch and drop frames i guess [05:01:50 CEST] <Diag> Classsic: when i remove the wallclock as timestamps the video plays normally for me [05:02:26 CEST] <Classsic> I need the this parameter for get sync multiple inputs [05:02:31 CEST] <Diag> :shrug: [05:03:26 CEST] <Diag> In that case the stuttering youre getting is very likely exactly what i said it was [05:03:29 CEST] <Diag> discrepencies [05:03:37 CEST] <Diag> how else is it going to sync it? [05:04:07 CEST] <Classsic> right [05:04:24 CEST] <Classsic> I will try transcoding in the same machine [05:06:09 CEST] <Classsic> and try, but I donŽt think this work [05:06:09 CEST] <Diag> Well, as far as my nonsense goes, i think i got it resolved...? [05:09:26 CEST] <Diag> awww yee [05:09:29 CEST] <Diag> we cookin with GAS now [05:09:48 CEST] <Diag> http://tyronesbeefarm.com/images/20199590cdb8-16dc-4fdb-a779-3cc51b434022.p… [05:09:49 CEST] <Diag> im kek [09:22:10 CEST] <WereCatf> How is one supposed to use qsv for decoding under Windows, if the primary GPU is a discrete NVIDIA-one? ffmpeg -hwaccel qsv -c:v h264_qsv crashes with segfault, and using -hwaccel_device either results in the same or complaints about qsv hwaccel not being initialized [09:24:37 CEST] <JEEB> well, first of all you need to enable the iGPU in your UEFI/bios. then I remember stories of having to make the driver get enabled by telling the windows displays thing that there totally, totally is a screen connected to the iGPU that it just can't find automatically [09:25:32 CEST] <JEEB> these could have changed since but I remember poking at this like 4 (?) years ago [09:37:41 CEST] <WereCatf> The funny thing is, encoding with qsv works fine. It's just the decoding-part which doesn't. [09:42:33 CEST] <WereCatf> To clarify: yes, the iGPU is enabled in BIOS and I have an external HDMI-dongle that pretends to be an actual display. Since it's an actual hardware-dongle, nothing on the PC-side can tell that there isn't a display connected. [09:48:00 CEST] <JEEB> ok, then I don't know :P [09:48:23 CEST] <JEEB> I would probably for just decoding utilize d3d11va or dxva2 since after the early 2010s that side should be pretty good on intel as well [09:48:48 CEST] <JEEB> I've personally moved to utilizing those everywhere instead of switching to QSV on intel [09:49:18 CEST] <JEEB> of course you'll probably have to pick the correct device with those APIs, which at least through API should be possible (and if it's AVOptions most likely through ffmpeg.c as well) [10:16:03 CEST] <WereCatf> I just realized what the issue was: Intel's drivers are stupid and won't let me use H/W-decoding if I have the displays in cloned mode instead of expanded in Windows-settings.... >_> [10:16:46 CEST] <JEEB> ayup [10:16:47 CEST] <Diag> why would you have them cloned anyways lol [10:16:50 CEST] <WereCatf> No dxva2, D#D or anything [10:17:02 CEST] <WereCatf> Because why would I want to expand my desktop to a non-existent display? [10:17:11 CEST] <Diag> oh, kek [10:17:22 CEST] <Diag> i havent backread [10:17:34 CEST] <Diag> im assuming youre trying to use intels acceleration with some real gpu present? [10:17:41 CEST] <WereCatf> Aye [10:17:44 CEST] <Diag> kek [10:17:48 CEST] <JEEB> but yea, it had to be a "real display" as far as I remember. I just stuck it somewhere on the side and hoped no windows ended up there [10:17:49 CEST] <Diag> they used to have lucidvirtue [10:18:00 CEST] <Diag> thats apparently dying in september though, so glhf :D [10:18:08 CEST] <Diag> my old mboard supported it [10:18:12 CEST] <WereCatf> The problem isn't having a second display [10:18:22 CEST] <WereCatf> I have an HDMI-dongle that pretends to be one [10:18:30 CEST] <WereCatf> THe problem is that the drivers are stupid [10:18:55 CEST] <Diag> https://downloadcenter.intel.com/download/19993/Lucid-Virtu- [10:19:00 CEST] <Diag> if you havent heard of it [10:19:16 CEST] <Diag> its retarded but it might come in handy some day [10:24:54 CEST] <WereCatf> Hm, still can't get qsv-decoding to work, but dxva2 works now. Oh well, that's good enough. [10:26:42 CEST] <JEEB> yea for decoding I don't really see a proper reason to use QSV any more tbh [10:26:56 CEST] <JEEB> after intel "fixed their shit" with dxva2 and d3d11 [10:26:59 CEST] <JEEB> *d3d11va [10:27:24 CEST] <WereCatf> Well, there's the pixel-format conversion that could be skipped [10:27:52 CEST] <JEEB> uhh, both output NV12 and you can get it as a D3D surface if the QSV encoders take that in [10:28:02 CEST] <JEEB> unless ffmpeg.c can't optimize that [10:28:13 CEST] <JEEB> I've mostly dealt with no-copy hwaccels through mpv for playback [10:28:25 CEST] <JEEB> no-copy just meaning that the texture stays in VRAM [10:28:38 CEST] <WereCatf> I know, I use that with nvenc/nvdec [10:29:56 CEST] <WereCatf> I'm just mostly playing with this stuff, I got curious how nvenc's HEVC-output compares to Coffee Lake iGPU's HEVC-output [10:30:19 CEST] <WereCatf> Now that it's working, Imma check with VMAF [13:21:05 CEST] <rocktop> is there a way to make text sliding from left to right for 5s in this cmd ? https://bpaste.net/show/QtAS [13:23:49 CEST] <pink_mist> I have not looked at your cmd, but it's always possible to include some .ass subtitles that displays text which you have used .ass commands to animate [14:47:05 CEST] <sopparus> hello [14:47:28 CEST] <sopparus> when restreaming ts to hls I eventually get this 'frame=42571 fps= 50 q=-1.0 Lsize=N/A time=00:14:11.39 bitrate=N/A speed=0.995x' [14:47:33 CEST] <sopparus> and ffmpeg suddenly stops [14:47:40 CEST] <sopparus> both video and audio are copy [14:48:30 CEST] <sopparus> ffmpeg -re -user_agent "$header" -i "$stream" -c:v copy -c:a copy -sn -hls_flags delete_segments -hls_time 20 -hls_list_size 360 -hls_wrap 0 -use_localtime 0 ""/storage/disk2/re/index.m3u8"" [14:48:34 CEST] <sopparus> is the command im using [14:49:04 CEST] <sopparus> version is 4.2 [14:52:22 CEST] <sopparus> eh, bad paste [14:52:26 CEST] <sopparus> video:477kB audio:194kB subtitle:0kB other streams:0kB global headers:0kB [14:52:26 CEST] <sopparus> muxing overhead: unknown [14:52:38 CEST] <sopparus> is the last output I see before ffmpeg exits [14:52:59 CEST] <extrowerk> Hi, i am with HaikuPorts here, and i have some questions: [14:53:15 CEST] <extrowerk> We have a woring ffmpeg 4.2 port, everythig fine [14:53:48 CEST] <extrowerk> One have enebled gnutls so smplayer will be able to play youtube videos and things like that [14:54:20 CEST] <extrowerk> but haiku uses openssl, and we would like to switch to openssl, but the configure script says --enable-nonfree required for openssl. [14:54:51 CEST] <extrowerk> The question is: if i pass --enable-openssl --enable-nonfree would it enable other things too, or only openssl? [14:55:36 CEST] <JEEB> enable-nonfree generally leads to binary redistribution problems [14:55:49 CEST] <JEEB> it actually means "not compatible with (L)GPL" [14:55:57 CEST] <JEEB> >license="nonfree and unredistributable" [14:56:14 CEST] <JEEB> the naming could be better, but that's what it means [14:56:30 CEST] <JEEB> generally it means that GPL licensed stuff was enabled [14:56:46 CEST] <JEEB> and now you are trying to utilize openssl which is IIRC not compatible with GPL [14:57:04 CEST] <JEEB> I think most recent openssl might have done something about this, but I think unfortunately this might still be the case [14:57:32 CEST] <JEEB> of course if you always build locally instead of grabbing binaries, then this might be less of a problem [14:57:59 CEST] <JEEB> extrowerk: in other things, if you are afraid of any autodetection try using --disable-autodetect [14:58:15 CEST] <JEEB> it doesn't disable everything (some things deemed "OS" libraries are still autodetected) [14:58:33 CEST] <JEEB> but it will make you actually request additional external features [14:58:47 CEST] <JEEB> and --enable-nonfree will set the license for the whole binary that you are building [15:00:06 CEST] <pink_mist> extrowerk: it would only enable openssl, the only thing enable-nonfree does is change the licensing terms - you now can't redistribute the binary [15:00:48 CEST] <extrowerk> we definetely want to distribute the generated binaries [15:01:02 CEST] <pink_mist> then you cannot enable nonfree [15:01:11 CEST] <extrowerk> no fear from autodetection as we build things in chroot [15:01:53 CEST] <extrowerk> ok, thanks you for the information [15:03:39 CEST] <JEEB> extrowerk: do note that if you think that the openssl license has been updated you can check that and request a change in our configure behavior [15:04:01 CEST] <JEEB> but currently the configure script follows what was valid for the longest time - it's not compatible with GPL :) [15:04:47 CEST] <extrowerk> JEEB: thank you, will make a mental notes about it. [15:06:17 CEST] <JEEB> although wait [15:06:36 CEST] <JEEB> extrowerk: on haiku is the openssl "part of the OS". I wonder how macOS handles that [15:06:44 CEST] <JEEB> (that first one was a question) [15:09:17 CEST] <extrowerk> it is a shared lib [15:10:10 CEST] <extrowerk> not a deeply integrated prt, but haiku needs an ssl implementation to support ssl [15:10:30 CEST] <extrowerk> but you can build haiku without any. [15:12:54 CEST] <JEEB> yea, I think you will want to first check the current license of openssl, and if that still is the one incompatible with GPL you can see if the GPL thing about "system libraries" might be applicable in your case [15:13:03 CEST] <JEEB> but then again, how do you define "part of OS" [15:13:08 CEST] <JEEB> if you have a package manager [15:13:26 CEST] <JEEB> anyways, quickly checking if there's macos specific stuff for openssl [15:13:33 CEST] <JEEB> although I think macOS just has its own schannel [15:13:42 CEST] <extrowerk> we have package manager, [15:14:04 CEST] <JEEB> ah no it was securetransport [15:14:08 CEST] <JEEB> that was the macOS thing [15:14:26 CEST] <JEEB> but yea, check the license of openssl if it's still incompatible with GPL [15:14:49 CEST] <JEEB> if it is no more, you could start poking us for "please make newer versions of openssl no longer require enable-nonfree" [15:17:07 CEST] <pink_mist> it looks to me like openssl is currently licensed under the apache license 2.0 ... which I _believe_ should not require --enable-nonfree [15:17:53 CEST] <JEEB> yea, that should only require version3 [15:18:11 CEST] <pink_mist> yeah [15:21:32 CEST] <extrowerk> JEEB: english is not my mother tongue, and i wouldn't like to be involved in licensing stuff. From my personal viewpoint what is not MIT/BSD or Public license is not open source, but thats private opinion. Will share the gathered info with the haiku devs and they will decide [15:22:16 CEST] <pink_mist> https://github.com/openssl/openssl/commits/master/LICENSE <-- seems this happened in december 2018, so if your openssl is from before then, you might still need to --enable-nonfree [15:25:39 CEST] <JEEB> extrowerk: yea I didn't want you to start reading into it that way. just checking if the license was still the old OpenSSL license [15:25:52 CEST] <JEEB> as pink_mist checked, it seems like they have an apache v2 alternative now [15:26:05 CEST] <JEEB> which is not compatible with GPLv2, but it is compatible with v3 [15:26:17 CEST] <pink_mist> it's not an alternative - the license has been completely replaced by apache v2 [15:26:26 CEST] <JEEB> oh [15:26:41 CEST] <JEEB> that makes it much simpler as long as the version is known when it switched [15:26:44 CEST] <JEEB> that way it could be checked for [15:26:50 CEST] <pink_mist> yup [15:27:47 CEST] <extrowerk> JEEB: our current openssl is 1.0.2s, which released in may 2019, so it should be fine [15:28:16 CEST] <JEEB> https://www.openssl.org/source/license.html [15:28:28 CEST] <JEEB> according to openssl, only 3.0.0 release is apache v2 [15:28:39 CEST] <JEEB> 1.x is still openssl [15:28:51 CEST] <JEEB> so 1.x is still not compatible with GPL [15:29:04 CEST] <extrowerk> Meh [15:30:28 CEST] <pink_mist> yeah, just checked the commits that went into the latest 1.0.2 and 1.1.0 and 1.1.1 branches, and none of them had the new license [15:30:29 CEST] <extrowerk> well, we probably could switch to openssl3, but i have to talk about it with the fellow devs [15:30:32 CEST] <extrowerk> thanks for the info [15:31:37 CEST] <pink_mist> 3.0.0 hasn't been released yet afaik - they're referring to current git master [15:32:30 CEST] <extrowerk> guys, i can't seem to find any openssl3, are you guys sure about the version number? [15:32:56 CEST] <pink_mist> read what I just said [15:33:22 CEST] <extrowerk> ah, ok, thanks [15:34:16 CEST] <extrowerk> gathered the required info and shared with the team, lets see what they think [15:34:22 CEST] <extrowerk> thank you guys [15:35:22 CEST] <pink_mist> I'm an ffmpeg packager myself, so I like to be on top of this stuff too =) [15:37:24 CEST] <pink_mist> unfortunately, libressl seems to still be using the openssl and ssleay dual license for the code they inherited from openssl [16:48:05 CEST] <marso> I'm using ffmpeg and ffplay for a point-to-point audio stream on a local network and I'm looking to get as close to 0 latency as possible. The audio source is direct capture of a headset microphone. Which ffmpeg/ffplay options have the greatest effect on latency reduction for this use case? [16:52:36 CEST] <BtbN> It's almost impossible to get zero latency without a custom application that eliminates all buffer [16:52:47 CEST] <BtbN> the generic ffmpeg.c code favors stability over latency [20:20:10 CEST] <thnee> When using ffprobe normally, it shows this line which includes the fps: Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 540x960, 435 kb/s, 24 fps, 30 tbr, 600 tbn, 1200 tbc (default) [20:21:40 CEST] <thnee> But when running with "-print_format json -show_format -show_streams" (and only using the stdout ofcourse), there is no 24fps to be seen anywhere. The closest I can find is r_frame_rate, but it says "30/1"? [20:22:24 CEST] <thnee> Why is this information not included in the json output? I was kinda expecting it to be the same data, just in a different format? [20:26:13 CEST] <JEEB> it should be the same data [20:26:37 CEST] <JEEB> not sure if you get that value without initializing the decoder context, but I am not sure how much I would trust it [20:26:45 CEST] <JEEB> since you have a time base of 30/1 supposedly [20:27:02 CEST] <JEEB> you can get the timestamps for frames with -show_packets [20:27:06 CEST] <JEEB> before decoding that is [20:30:16 CEST] <thnee> JEEB: -show_packets basically means count all the frames myself? That seems excessive. [20:30:32 CEST] <JEEB> then you can yourself decide how much you want to calculate [20:30:48 CEST] <JEEB> if you're OK with coming up with some sort of average from the first N frames [20:30:49 CEST] <JEEB> etc [20:30:55 CEST] <JEEB> you get the time bases and timestamps [20:30:59 CEST] <thnee> It just seems odd to me that it doesnt show the 24 fps when using -print_format json -show_format -show_streams (and no other arguments) [20:31:10 CEST] <JEEB> probably because that might come from decoder context [20:31:17 CEST] <JEEB> if I had my development VM open I could check :P [20:31:25 CEST] <JEEB> if you don't start decoding you have no decoder context [20:31:57 CEST] <thnee> Could you please elaborate on that? What does ffprobe do differently to initialize a decoder context when its not being told to output as json? [20:32:30 CEST] <kepstin> i'd expect that field in the log to correspond to avg_frame_rate in the json, but i can't actually remember what that log message prints. [20:33:13 CEST] Action: JEEB boots up his VM to be more useful [20:35:09 CEST] <thnee> kepstin: Ah yes, avg_frame_rate is 43470/1811 which comes out to 24. Hmm ok interesting :) [20:35:45 CEST] <kepstin> line 515 in https://www.ffmpeg.org/doxygen/trunk/dump_8c_source.html#l00457 is where that's printed [20:36:13 CEST] <kepstin> that log output shows avg_frame_rate if present, otherwise r_frame_rate, otherwise the container time base inverted, otherwise the codec time base inverted. [20:36:30 CEST] <kepstin> all those info fields should be in the json output. [20:36:33 CEST] <JEEB> yes [20:37:09 CEST] <thnee> Thanks for that! The reason I want frame rate is to calculate the gop size for a conversion to HLS. I am thinking if setting -hls_time to 2 and then set the -g and -keyint_min to 2 * frame_rate. Does that make sense? [20:39:38 CEST] <kepstin> thnee: for constant framerate content, yeah. you might want to add something (fps filter or -r output option) to enforce that your output is cfr, since ffprobe can only guess in some cases. [20:40:59 CEST] <thnee> How do I know if it is CFR to begin with? -_- [20:42:29 CEST] <kepstin> only way to know for sure is by looking at each frame pts and seeing if they go up by the same amount (+- a bit to account for rounding errors) each frame :/ [20:43:16 CEST] <kepstin> in practice, most professionally produced video will be cfr, most webcam and cellphone video will not be. [20:44:13 CEST] <thnee> I see. All my content will be from smart phones, ios and android. So if it's not CFR, the hls_time logic that I said is no good? [20:44:38 CEST] <JEEB> yea mobile video generally tends to be VFR due to the cameras not pushing out pictures at a stable rate [20:44:40 CEST] <kepstin> yeah, since depending on light conditions cell phones will change the framerate over time [20:45:12 CEST] <JEEB> the hls_time logic should be OK since that's time based I guess [20:45:30 CEST] <JEEB> the GOPs will of course become shorter/longer in time [20:45:38 CEST] <kepstin> the problem is that if framerate changes, then the keyint based on framerate will no longer line up [20:45:45 CEST] <thnee> Apparently this is important when doing multi bitrate HLS so that the segments sync up, I read somewhere. [20:46:30 CEST] <JEEB> thnee: not really true. there are some really crappy clients but while looking at android (exoplayer etc) and iOS you definitely don't need to even match GOPs between profiles :P [20:46:32 CEST] <thnee> Ah ok, so the gops will be different, but still sync across the different qualities? [20:46:47 CEST] <JEEB> but of course it makes some things simpler in some implementations if you match GOPs [20:47:02 CEST] <JEEB> but for making sure GOPs match there's two ways of doing that [20:47:21 CEST] <JEEB> 1. you do a pre-pass to figure out where the keyframe points are (or use one of the encoders as your "master") [20:47:44 CEST] <JEEB> 2. set some GOP length with -g XXX and then -x264-params scenecut=0 [20:47:44 CEST] <JEEB> :P [20:47:53 CEST] <JEEB> which disables dynamic scenecuts [20:48:03 CEST] <kepstin> a fixed keyframe interval should work fine, it just means that your hls segments won't be fixed length with vfr. [20:48:05 CEST] <JEEB> of course not optimal which is why 1. is recommended [20:48:56 CEST] <thnee> Yeah I am doing -hls_time, -keyint_min and -sc_threshold 0. Hm ok thanks a lot, prepass sounds nicer, less hard coded logic on my part. [20:50:58 CEST] <thnee> So is that the -pass flag you are referring to? [20:55:26 CEST] <JEEB> not really, but I guess you could generate a frame type file with that [20:56:04 CEST] <thnee> Ok so what did you mean by pre-pass? [20:56:26 CEST] <JEEB> generally people run something like xvid's (yes, lol) keyframe decision algorithm through a clip, and then generate a keyframe list [20:56:31 CEST] <thnee> This is what my current code is https://dpaste.de/LEWO Insert dog-in-lab-coat.jpg here [20:56:49 CEST] <JEEB> scxvid it used to be called I think [20:57:01 CEST] <JEEB> but anyways, not sure how easily that can be done with just the command line app ÖP [20:57:04 CEST] <JEEB> :P [20:57:10 CEST] <JEEB> most people start using the API at some point [20:58:19 CEST] <thnee> Using libav? Yeah I have seriously considered it, but it seems like a big step. But that would make this problem easier you say? [20:59:13 CEST] <JEEB> depending on your needs. [20:59:48 CEST] <JEEB> in theory I guess you could see if you could just run ffmpeg.c for decoding and pipe the decoded video to scxvid and get a keyframe file :P [20:59:55 CEST] <JEEB> then feed that to all encoders [21:01:52 CEST] <durandal_1707> what? [21:02:12 CEST] <durandal_1707> extracting scene changes or? [21:02:16 CEST] <JEEB> yes [21:02:33 CEST] <durandal_1707> just single frame? [21:02:49 CEST] <JEEB> a full keyframe list based on something like xvid's scenecut [21:03:00 CEST] <JEEB> I don't think if the algorithm is actually good, but it's nicely matching actual scenecuts [21:03:03 CEST] <JEEB> unlike x264's [21:03:50 CEST] <durandal_1707> isnt that same as select filter and its scenechange feature? [21:04:07 CEST] <JEEB> could be, can you extract a list nicely out of it into a file you can throw into x264? [21:04:28 CEST] <thnee> But then again, youre saying this doesnt matter for HLS. The segments can actually be out of sync and it will work fine in modern players? [21:04:34 CEST] <JEEB> yes [21:04:35 CEST] <thnee> Would the same be true for dash as well? [21:05:06 CEST] <JEEB> yes, pretty sure each representation can have its own Media timeline [21:05:20 CEST] <JEEB> I've so far found one DASH implementation that sucked at that [21:05:29 CEST] <JEEB> and that was the Microsoft PlayReady SDK on iOS [21:05:34 CEST] <JEEB> and I have no idea why you'd use that [21:07:05 CEST] <JEEB> none of the specs ever required the keyframes to match as far as I can tell, and for a reason. I've also heard this recommendation a *lot* but in the end I've only found a few devices that really require it (And they're never the major ones, thankfully) [21:07:49 CEST] <thnee> Hm allright sounds very promising indeed. Thank you kindly! [21:08:29 CEST] <JEEB> of course if you hit one of those devices (usually TVs [samsung 2015 tizen comes to mind], playread DASH on iOS), then you know what to do. Or you just give those a blank stare :P [21:08:50 CEST] <JEEB> or work around in another way like only giving some clients a single rendition to play with [00:00:00 CEST] --- Tue Aug 27 2019

1 0

ffmpeg-devel.log.20190824
by burek 15 Sep '19

15 Sep '19

[01:34:29 CEST] <rcombs> is it just me or can avcodec_open2 return while still holding codec_mutex in error cases [01:34:51 CEST] <rcombs> specifically free_and_end [02:09:07 CEST] <cone-124> ffmpeg 03Aman Gupta 07master:c62a1db0ac16: MAINTAINERS: add myself to OMX [02:09:08 CEST] <cone-124> ffmpeg 03Aman Gupta 07master:76c82843ccad: avcodec/omx: add support for -force_key_frames [02:09:09 CEST] <cone-124> ffmpeg 03Aman Gupta 07master:23a3e1460a7a: avcodec/omx: ensure zerocopy mode can be disabled on rpi builds [02:09:10 CEST] <cone-124> ffmpeg 03Dave Stevenson 07master:3d857f219eb9: avcodec/omx: Fix handling of fragmented buffers [02:12:09 CEST] <cone-124> ffmpeg 03Aman Gupta 07release/4.2:e008f89cfa1a: avcodec/omx: ensure zerocopy mode can be disabled on rpi builds [02:12:10 CEST] <cone-124> ffmpeg 03Dave Stevenson 07release/4.2:3dd3e8e24ac9: avcodec/omx: Fix handling of fragmented buffers [07:54:52 CEST] <cone-195> ffmpeg 03Pavel Koshevoy 07master:22a14ee753f3: avcodec/videotoolbox_hevc: avoid leaking cached_hw_frames_ctx [09:34:16 CEST] <cone-195> ffmpeg 03Thilo Borgmann 07master:1cfba7fc7584: fate/als: Add test for conformance file with 512 channels. [16:25:33 CEST] <durandal_1707> looks like nobody except thilo and me wants meeting [16:26:18 CEST] <JEEB> what sort of meeting was it about? the thread seemed long so I didn't actually read through it [16:26:27 CEST] <JEEB> not that I'm a new developer :P [16:29:07 CEST] <durandal_1707> its not about new developers [16:30:08 CEST] <durandal_1707> its meeting where we pick new leader. seriously there is bunch of stuff to decide/do [16:31:04 CEST] <JEEB> ok, the thread title or description that I read in gmail seemed to have something about new developers and it seemed to get long'ish [16:31:30 CEST] <durandal_1707> lol [16:33:13 CEST] <durandal_1707> we have no new devs, we only lose old and new ones per day :( [16:34:03 CEST] <JEEB> well I'm pretty sure we've gained people in our git history during the last year [16:34:13 CEST] <JEEB> of course how active those people become is a different discussion [16:48:48 CEST] <durandal_1707> modern people not interested in reading long threads [16:49:51 CEST] <JEEB> esp. if it doesn't seem to be relevant to me? which you thankfully have noted to be an incorrect assumption [16:50:01 CEST] <JEEB> also nothing modern [16:50:14 CEST] <JEEB> just priorities of where I can or want to put my time into [16:50:52 CEST] <durandal_1707> yea, old story [17:55:22 CEST] <kierank> Meetings are pointless we did it during fork days [17:55:27 CEST] <kierank> Nobody turned up [17:55:41 CEST] <kierank> Was blocked by mplayer people [17:56:28 CEST] <thilo> how to block a meeting? [17:56:53 CEST] <thilo> whatever, jest reply to the thread and more people will notice if it stays somewhere on top the latest msgs [17:58:33 CEST] <thilo> if there will be enough people in favor for that and actually enter there dates of comfort there will be another registration thread anyway - and then even the most lazy should notice [17:58:44 CEST] <thilo> *their [17:59:36 CEST] <thilo> I just wonder the people in favor that already replied to durandals original thread do not reply to the proposal [17:59:56 CEST] <durandal_1707> but where you plan to put actual meeting, on open air? [18:00:13 CEST] <durandal_1707> these need more planning [18:00:27 CEST] <durandal_1707> no rushing needed [18:00:38 CEST] <thilo> conference hotel. we don't need anything else but a room big enough for everyone [18:01:13 CEST] <thilo> no rush needed [18:07:10 CEST] <kierank> They blocked the actions of the meeting [18:07:28 CEST] <kierank> We had so many "fork room" meetings it was boring [18:10:02 CEST] <thilo> have these been like the "fork talks" at later VDDs I witnessed or dedicated meetings just for that purpose? [18:14:54 CEST] <kierank> Fork talks mainly [18:15:53 CEST] <thilo> if they were not dedicated meetings, it would be easy to block because just a bunch of people met somewhere talking something [18:16:22 CEST] <thilo> this time, if enough people want to attend, it will be an announces dev meeting for the project. including decisions [18:16:47 CEST] <thilo> wether or not michaelni is there or not [18:17:41 CEST] <kierank> I don't see how this will be different, the usual suspects (sorry to use that terminology but there is nothing better) will just block or filibuster as they have been used to for decades [18:18:24 CEST] <kierank> I admire your enthusiasm however [18:18:34 CEST] <kierank> But personally I have seen progress dashed time and time again [18:19:59 CEST] <thilo> we all have. i've never seen an announced dedicated meeting, though. just "fork talks" at VDD [18:20:07 CEST] <thilo> has there ever been such one? [18:22:32 CEST] <kierank> No, but this was out of convenience when many developers were in the same place (e.g fosdem) [18:23:08 CEST] <durandal_1707> kierank: apply two dhav patches i just posted if you are bored [18:23:27 CEST] <kierank> Can't, not got laptop [18:24:02 CEST] <kierank> What is dhav [18:24:06 CEST] <BBB> thilo: I organized one 3 years ago I think at VDD [18:24:10 CEST] <BBB> the one in Germany [18:24:18 CEST] <thilo> well then whatever they agreed on is easy to block [18:24:36 CEST] <BBB> we typically have more informal group get-togethers at VDD but not to discuss policy, just to listen to users [18:24:44 CEST] <durandal_1707> dhav is dahua cctv container [18:25:48 CEST] <thilo> BBB: I've been there... this is exactly what I mean - had happened often but could be blocked for being "non-official" easily [18:26:24 CEST] <kierank> What will happen is someone will say "there isn't consensus" based on some arbitrary decision [18:26:37 CEST] <kierank> And then nothing changes [18:26:39 CEST] <thilo> this time we can just make it "official" and announce it on the ML. And since the ML is considered the "official" channel of communication, hard to neglet legitimacy of that [18:27:03 CEST] <kierank> Might work [18:27:20 CEST] <kierank> A step in the right direction I guess [18:27:36 CEST] <thilo> well, finding consensus is a task for all attendees of course [18:28:07 CEST] <kierank> Yes but the people who do not travel say "oh but we should have meeting on IRC or ML or whatever, not official decision, blah blah" [18:28:26 CEST] <kierank> There is no real way to enforce these decisions [18:29:22 CEST] <thilo> yes, at least it would be moving forward and stop being stalled [18:29:50 CEST] <BBB> I think we should try to be proactive with allowing non-attendees to participate also [18:29:57 CEST] <BBB> can we do a live-type out of the discussion? [18:30:00 CEST] <BBB> maybe live-stream it? [18:30:05 CEST] <BBB> and then have irc participation? [18:30:10 CEST] <BBB> (for questions/comments) [18:30:13 CEST] <thilo> that I can very well imagine [18:30:26 CEST] <BBB> I know some ML people hate IRC but you can't have everything... [18:31:28 CEST] <thilo> we might easily screen a freenode channel and stream "live-ish", I guess... that's kierank's job ;) [18:33:04 CEST] <thilo> however most important for me is people actually going there [18:58:19 CEST] <BBB> thilo: I think VDD is your best shot [18:58:30 CEST] <BBB> in other cases you will only have a fraction of people attending [18:59:39 CEST] <durandal_1707> vdd in tokyo!? [18:59:52 CEST] <nevcairiel> Pick a VDD thats closer to the core developers though, and not in Tokyo, really not a fan of 20 hour flights =P [19:09:34 CEST] <durandal_1707> you closed nicolas report [19:10:41 CEST] <durandal_1707> how rude :p [20:38:47 CEST] <durandal_1707> michaelni: you are very rude [20:39:18 CEST] <durandal_1707> still sending patches that break decoders [20:39:44 CEST] <durandal_1707> and not providing speedup numbers at all [20:40:13 CEST] <durandal_1707> why you care for that decoder at all? [20:40:59 CEST] <durandal_1707> making vfr from cfr is unacceptable [20:42:01 CEST] <durandal_1707> thinking about not developing new decoders at all because of your devastating changes [20:43:29 CEST] <durandal_1707> fraps, qtrle, scpr and others too are all victims of your changes [20:44:18 CEST] <durandal_1707> you forgot to ruin msrle [20:44:37 CEST] <thilo> BBB: that would just end up like the examples kierank told about [20:45:54 CEST] <thilo> BBB: we are overdue about having our own, and be it for the lessons of prior VDD talks alone [20:47:04 CEST] <thilo> BBB: we might attach it before or after VDD and share resources, that would be good. but we need something else than one single "FFmpeg" session at VDD [20:47:49 CEST] <jamrial> durandal_1707: are you really against a flag or option to choose between the two modes? [20:48:36 CEST] <durandal_1707> is that covering decoder compatibility? [20:49:07 CEST] <durandal_1707> its about default behavior [20:49:45 CEST] <durandal_1707> and what makes decoder compliant with reference implementation [20:51:37 CEST] <jamrial> we can make crf the default if the decoder is expected to output that to be complaint [20:52:36 CEST] <jamrial> i suggested to map it to -flags2 fast but michaelni_ argued it was not ideal [20:53:09 CEST] <jamrial> i don't really agree because if you care about bitexactness, you use -flags bitexact [20:55:05 CEST] <durandal_1707> i expect from him to show actual numbers [20:58:16 CEST] <BBB> thilo: I like the idea, but nevcairiel's comment about vdd@tokyo being far away is true for all events [20:58:27 CEST] <BBB> thilo: if you do it in croatia, mind you that's far away for me [20:58:36 CEST] <BBB> I don't like flying over just for a one-day or half-day ffmpeg event [20:58:40 CEST] <BBB> and that's not just me :-/ [20:58:55 CEST] <BBB> so ... [20:58:58 CEST] <BBB> it's difficult :) [21:02:22 CEST] <thilo> sure. I like the idea of doing it a day before or after VDD, also for that reason. For this year VDD... well its Tokyo and less people will come anyway [21:04:03 CEST] <thilo> and i guess a day extra just for the FFmpeg people might not be what JB had in mind in his ML post about that [21:05:19 CEST] <thilo> but I can ask him [21:05:59 CEST] <thilo> however, I also want durandal there... then, Tokyo is not an option [21:21:08 CEST] <michaelni_> jamrial, a video with and without bitexact flag looks ok, a video decoded with flags2 fast doesnt neccessarily look ok. [21:24:54 CEST] <jamrial> michaelni_: i see [21:30:35 CEST] <durandal_1707> BBB: what you live in antartica? so tokyo is closer [21:32:39 CEST] <nevcairiel> Personally I would obviously prefer EU locations, but US would be acceptable, but 20 hours flying is just over the top for me [21:35:18 CEST] <cone-420> ffmpeg 03Paul B Mahol 07master:96fd07351a8d: avformat/dhav: gracefully handle corrupted files [21:35:18 CEST] <cone-420> ffmpeg 03Paul B Mahol 07master:45cefca1e799: avformat/dhav: handle files missing data at start [21:42:28 CEST] <durandal_1707> calling for mov timecode reviewers! [21:52:41 CEST] <durandal_1707> i remember days when reviewing was honorable action [22:08:14 CEST] <durandal_1707> but i guess nothing lasts forever [22:32:13 CEST] <thardin> that doesn't look like timecode [22:35:33 CEST] <thardin> croatia, eh? [23:00:38 CEST] <thardin> perhaps I should arrange travel to amsterdam [00:00:00 CEST] --- Sun Aug 25 2019

1 0

ffmpeg-devel.log.20190826
by burek 15 Sep '19

15 Sep '19

[04:59:30 CEST] <cone-193> ffmpeg 03Xuewei Meng 07master:f0c97d613ea7: libavfilter: Add dehaze-filter option in existing derain. [05:08:28 CEST] <cone-193> ffmpeg 03Steven Liu 07master:4ba82ecc12b7: avformat/hlsenc: fix memleak in hls_write_trailer [05:08:29 CEST] <cone-193> ffmpeg 03Steven Liu 07master:80d2a7f5c64f: avformat/hlsenc: fix memleak of filename [05:08:30 CEST] <cone-193> ffmpeg 03Steven Liu 07master:17576fda6546: avformat/hlsenc: remove unused value [05:10:47 CEST] <cone-193> ffmpeg 03Steven Liu 07master:7c2ff06b6e6a: doc/examples/decode_audio: print message about how to play the output file [05:10:48 CEST] <cone-193> ffmpeg 03Steven Liu 07master:6d1009cb9d88: doc/examples/decode_video: add input file format information for usage [07:40:17 CEST] <thardin> morning [09:11:35 CEST] <cone-879> ffmpeg 03Xuewei Meng 07master:59da9dcd7ef6: avfilter/vf_derain: reindent code after last commit [12:37:02 CEST] <durandal_1707> how can i encode dupe frames with h264? [12:37:12 CEST] <JEEB> in what sense? [12:37:22 CEST] <JEEB> you want the headers that say to duplicate or? [12:38:01 CEST] <durandal_1707> in sense that 10 fully black frames in a row are encoded [12:38:51 CEST] <thardin> use a black video source? [12:39:03 CEST] <thardin> like /dev/zero [12:43:50 CEST] <thardin> I smell DoS samples [12:49:50 CEST] <J_Darnley> lavfi color source is another option [12:58:47 CEST] <durandal_1707> no, i mean in way that they are encoded like skip frames, that qtrle "have" [12:59:19 CEST] <J_Darnley> I don't know how you force any encoder to do that [13:00:27 CEST] <durandal_1707> does h264 bitstream have mode to signal skip frames? [13:01:36 CEST] <durandal_1707> ignoring cases when each 2nd is dupe or something similar for softtelecine crap [13:07:22 CEST] <durandal_1707> vel0city_netbook: will you add your entry on trac wiki gsoc page? [13:07:28 CEST] <JEEB> try -x264-params keyint=infinite [13:08:08 CEST] <JEEB> *keyint=infinite:scenecut=0 [13:08:32 CEST] <JEEB> that should force non-keyframes and then you should see libx264 at least output skips if you feed it identical frames [13:08:36 CEST] <JEEB> not sure if you can *force* it [13:08:42 CEST] <JEEB> but that's as close as I could get with it [13:09:12 CEST] <JEEB> might recommend poking #x264 or #x264dev about it if you really need something like that [13:09:18 CEST] <JEEB> (And those options don't budge) [13:14:45 CEST] <durandal_1707> swscale is useless, it does not support bunch of trc [13:15:20 CEST] <rcombs> is there actual "skip" syntax or is it just "a P-frame with every block referencing the keyframe unchanged" [13:20:44 CEST] <JEEB> yea it could just be that [13:21:02 CEST] <JEEB> the AVI thing was on container level I think [13:21:04 CEST] <JEEB> for mpeg-4 patt 2 [13:21:06 CEST] <JEEB> *part 2 [13:21:18 CEST] <thardin> just try encoding some black video and see what happens [13:21:22 CEST] <JEEB> yes [13:21:46 CEST] <JEEB> I kind of recommended that with maknig sure there's no additional I-frames but I'm not sure if he's tried it yet :P [13:21:56 CEST] <thardin> I looked into very low bitrate coding a few years ago. libx264 inserts a bunch of crap that will make the output larger than necessary [13:22:21 CEST] <thardin> so you might want to hack it a bit if you want to acheive the tiniest output possible [13:22:46 CEST] <JEEB> yea, I don't think that's his requirement right now (if you're talking about the additional SEIs and other stuff that's not 100% optimal for size limiting) [13:23:15 CEST] <thardin> yeah the comment and whatever [13:57:32 CEST] <vel0city_netbook> durandal_1707: added, I linked to my blog post [13:58:02 CEST] <vel0city_netbook> Cldfire: hello, haven't read your post yet but fyi the first link you have in it is dead [14:01:51 CEST] <durandal_1707> i did read it [14:02:04 CEST] <durandal_1707> perhaps it died [14:03:18 CEST] <vel0city_netbook> I meant the link he has on the post itself, not on Trac. The one with the text "here" that's supposed to link to an OpenCL filter post [14:46:30 CEST] <JEEB> wbs: whew. I think I have my first crappy version pushing out crappy fragments, but they at least are continuous and all that jazz \o/ [15:30:45 CEST] <Cldfire> vel0city_netbook thanks for pointing that out, i'll fix it here shortly [15:30:58 CEST] <Cldfire> not sure why it's broken, it worked fine on my local server [16:12:09 CEST] <kierank> nevcairiel: good response on CFR issue [16:15:50 CEST] <thardin> which one? [16:16:09 CEST] <kierank> Qtrle patch [16:16:49 CEST] <jamrial> it would be nice as well if you all could also chime in regarding the discard/dispose frame flag suggestion so we can get things moving [16:17:25 CEST] <thardin> don't have my FFlappy on me at the moment [16:18:32 CEST] <kierank> Not easy to bottom post on a phone with long threads [16:22:26 CEST] <thardin> reget_buffer() makes it possible to return the same buffer with different pts, right? [16:25:36 CEST] <jamrial> the duplicate frames sharing the same buffer is already taken care of [16:25:55 CEST] <jamrial> this is about signaling frames as being exact duplicate of previous ones so they may be discarded if desired, instead of forcing the decoder to never propagate them in the first place (thus producing unconditinoal cfr -> vfr) [16:26:11 CEST] <thardin> good point about fade filters and such [16:27:52 CEST] <jamrial> outputting duplicate frames is not a performance concern in decoders. creating buffer references is cheap [16:28:05 CEST] <jamrial> the issue is, as michaelni_ stated, what happens with them later in the process (filters, encoders, etc) [16:29:08 CEST] <jamrial> processing 100 frames instead of 20 will be slower, of course. so having a way to drop the frames at some point should be enough to work around this, and keep decoder behavior complaint [16:29:29 CEST] <jamrial> s/complaint/compliant [16:30:30 CEST] <thardin> either way it's not the job of lavc to decide that [16:32:12 CEST] <jamrial> exactly, it's the lavc user [16:32:53 CEST] <thardin> what's this about bitrate being higher? [16:33:10 CEST] <thardin> surely any decent encoder will detect these duplicated frames, unless they're intra-only [16:39:12 CEST] <thardin> now I've read the entire thread. a "this frame is identical to the last one" flag is something I don't think anyone would be opposed to [16:39:47 CEST] <thardin> smart encoders, filters and whatnot could inspect it and act appropriately [16:40:10 CEST] <thardin> a filter that only depends on input pixels could re-output the same frame for example [16:40:19 CEST] <cehoyos> Please don't use the word "compliant" to argue [16:40:21 CEST] <thardin> whereas one that also depends on time (like a fade) should not [17:10:34 CEST] <durandal_1707> current behaviour with fraps, qtrle, scpr is not compliant [17:11:59 CEST] <durandal_1707> you will not forbid me my right for free speech [18:19:18 CEST] <jamrial> PoC for disposable frame flag in the ml [19:56:57 CEST] <tmm1> is there a moderator queue on ffmpeg-devel? seems some of my emails got stuck [19:57:23 CEST] <durandal_1707> i doubt so [19:57:42 CEST] <durandal_1707> when you sent patches? [19:58:12 CEST] <tmm1> no, replies to existing threads [19:58:54 CEST] <durandal_1707> but when? [19:59:39 CEST] <tmm1> i sent one message 12 hours ago, <CAK=uwuyGBcB+JuXj95ea03im6S9KwNG3aK+Sw+gLBd6qbGZjCQ(a)mail.gmail.com> [20:00:26 CEST] <durandal_1707> ugh, and you are subscribed? [20:00:59 CEST] <tmm1> i'm subscribed as ffmpeg(a)tmm1.net but it looks like some messages i sent as aman(a)tmm1.net and those are the ones that never went through [20:01:52 CEST] <durandal_1707> then you will need to wait for moderator, if any to approve it [20:02:27 CEST] <durandal_1707> dunno if moderators are still actively doing this thing [20:03:29 CEST] <durandal_1707> iirc nobody came around so mails are never approved, i hope i am wrong [20:09:52 CEST] <kierank> Repeat flags are not the same as dropping frames [20:10:04 CEST] <kierank> One is in the presentation plane, one is decoding [20:10:08 CEST] <kierank> Not the same thing [20:25:47 CEST] <tmm1> i need to maintain a queue of AVFrame in a filter, is there any generic implementation i can re-use? [20:27:18 CEST] <durandal_1707> in hw filter? [20:28:35 CEST] <tmm1> works with both sw and hw frames [20:28:37 CEST] <thardin> kierank: you'd also need delays to implement any "repeat this frame N times" solution where N can't be read off metadata [20:31:38 CEST] <durandal_1707> tmm1: see libavfilter/bufferqueue.h? [20:32:11 CEST] <tmm1> perfect, thank you [20:32:21 CEST] <thardin> jamrial: I'd maybe call the flag something else, but the concept is fine. I could update cinepakenc to honor it, maybe something else (gifenc perhaps) [20:32:40 CEST] <thardin> gitenc could just accumulate durations [20:32:44 CEST] <thardin> gifenc* [20:33:49 CEST] <jamrial> thardin: there's a "disposable" packet flag already, so imo using the same name is a good idea [20:34:46 CEST] <durandal_1707> what that flag for packets means ? [20:35:18 CEST] <thardin> * Flag is used to indicate packets that contain frames that can [20:35:18 CEST] <thardin> * be discarded by the decoder. I.e. Non-reference frames. [20:35:23 CEST] <thardin> only used for h265 [20:35:48 CEST] <thardin> jamrial: fair enough [20:36:26 CEST] <thardin> see 00d454ed2ca [20:37:11 CEST] <jamrial> set by libx265 so far, but can also be done with libx264 easily [20:37:16 CEST] <thardin> does this mean "leaf" B-frames could also be marked disposable? [20:37:18 CEST] <jamrial> matroska muxer can also be made to look for it and set a container level flag [20:37:44 CEST] <thardin> I suspect mxfdec could be made to signal this as well [20:47:48 CEST] <cone-906> ffmpeg 03Michael Niedermayer 07master:8f49176e845f: avcodec/alac: Check for bps of 0 [20:47:48 CEST] <cone-906> ffmpeg 03Michael Niedermayer 07master:5af613cc484e: tools/target_dec_fuzzer: Do not corrupt the packet size return [20:47:48 CEST] <cone-906> ffmpeg 03Michael Niedermayer 07master:02a44ed0c802: tools/target_dec_fuzzer: Increase maxpixels threshold for dirac [22:40:44 CEST] <nevcairiel> I really have a hard time figuring out if this is so hard to understand or if its just stubborness to not want to see how its actually very different [22:52:29 CEST] <durandal_1707> maskedsharpen [23:00:30 CEST] <kierank> nevcairiel: people being stubborn ofc [23:00:47 CEST] <kierank> nevcairiel: speaking of which let me remind you what a DoS is [23:00:52 CEST] <kierank> ad nauseam [23:46:28 CEST] <baptiste> kierank, people being stubborn both ways, and I don't think adding to the fire is necessary in this case [23:50:59 CEST] <kierank> baptiste: I think it's very clear who is being stubborn and who is trying to stop the months of awful hacks going in to placate fuzzers [23:51:26 CEST] <baptiste> security issues are security issues [23:51:54 CEST] <baptiste> crashes detected by the fuzzer need to be fixed [23:52:10 CEST] <baptiste> qtrle is a very different issue [23:55:15 CEST] <kierank> exactly they are not crashes [23:55:24 CEST] <baptiste> all I see, people sending patches, people arguing all the time, and people being toxic TBH [23:55:28 CEST] <kierank> they are hacks to stop theoretical long runtimes [23:55:35 CEST] <kierank> on theoretical samples [23:55:52 CEST] <kierank> yes because we will not accept awful hacks to please the fuzzer until the next failing sample [23:56:08 CEST] <kierank> y [23:57:11 CEST] <baptiste> I mainly see crash fixes, correct me if I'm wrong, it seems that long runtimes is not the majority of fuzzer detected issues [23:58:46 CEST] <nevcairiel> recently crash fixes seem not to be in a majority, its UB or "timeouts" [23:59:07 CEST] <baptiste> did you count ? or do I have to go and count ? [00:00:00 CEST] --- Tue Aug 27 2019

1 0

ffmpeg-devel.log.20190914
by burek 15 Sep '19

15 Sep '19

[04:02:55 CEST] <cone-279> ffmpeg 03Daniel Oberhoff 07master:88a26abcc657: hlsenc: flush segments to guarantuee atomic single file hls [04:02:55 CEST] <cone-279> ffmpeg 03Andreas Rheinhardt 07master:1a066d87e3ea: avformat/hlsenc: Fix memleak when using single_file [04:02:55 CEST] <cone-279> ffmpeg 03Jun Zhao 07master:48d96ce29a2d: lavf/hls: refine the log message [04:02:55 CEST] <cone-279> ffmpeg 03Jun Zhao 07master:eada079e718f: lavf/hls: drop unnecessary check before ff_format_io_close [04:02:55 CEST] <cone-279> ffmpeg 03Jun Zhao 07master:90a5bebd19ea: lavf/hls: remove redundancy seekable setting [04:02:55 CEST] <cone-279> ffmpeg 03Jun Zhao 07master:0c5726a33273: lavf/hls: fix memory leak in error handling path for option tmp [06:54:53 CEST] <cone-279> ffmpeg 03Steven Liu 07master:2e82b50bce18: avformat/dashdec: reindent code at parse_manifest [07:10:25 CEST] <cone-279> ffmpeg 03Steven Liu 07master:8efc9fcc5688: avformat/hlsenc: make fix code style of hls_write_trailer [10:51:23 CEST] <cone-442> ffmpeg 03Paul B Mahol 07master:cb8d6a4e3ef3: avfilter/vf_v360: implement diagonal field of view [15:14:40 CEST] <J_Darnley> Hello from the IBC floor. [15:15:04 CEST] <J_Darnley> I finally connected to my vpn and now I have days worth of logs to read. [15:19:27 CEST] <BBB> hi! [15:19:37 CEST] <BBB> hope you're having fun there [15:20:02 CEST] <J_Darnley> meh [15:20:08 CEST] <J_Darnley> been better, been worse [15:39:53 CEST] Action: JEEB was at ibc yesterday [15:40:04 CEST] <JEEB> for a whole of like 40 min :D [15:41:04 CEST] <JEEB> in, check stand, tske official photos, do a minimal roll nearby and then run back [15:55:10 CEST] Action: J_Darnley goes offline again [19:56:29 CEST] <cone-040> ffmpeg 03Paul B Mahol 07master:f78abca0c285: avfilter/vf_v360: call tanf() once [19:56:29 CEST] <cone-040> ffmpeg 03Paul B Mahol 07master:2a672a93d248: avfilter/vf_v360: define variables in for loops consistently [19:56:29 CEST] <cone-040> ffmpeg 03Paul B Mahol 07master:451cee662c37: avfilter/vf_v360: reduce by one cosf call less [19:56:29 CEST] <cone-040> ffmpeg 03Paul B Mahol 07master:45bb80dccc55: avfilter/vf_v360: implement stereo 3D support [19:56:29 CEST] <cone-040> ffmpeg 03Paul B Mahol 07master:197985c5bf0e: doc/filters: add another v360 example [20:25:05 CEST] <scx> What do I need to open YUV4MPEG? [20:25:06 CEST] <scx> YUV4MPEG: video is not in a supported format. [20:26:13 CEST] <scx> I was unable to find any option for YUV4MPEG in configure. [20:55:42 CEST] <durandal_1707> scx: what you use? [20:56:37 CEST] <scx> ffmpeg 4.2.1 [20:56:59 CEST] <durandal_1707> and what file? [20:57:08 CEST] <scx> http://www.sunrayimage.com/examples.html [20:58:08 CEST] <scx> to be more specific, ffms2 compiled with the latest version of ffmpeg [20:58:23 CEST] <durandal_1707> those are rawvideos with no headers [20:58:49 CEST] <scx> is this a problem? [20:59:50 CEST] <durandal_1707> with ffmpeg you set parameters like width and format and use rawvideo demuxer [21:08:22 CEST] <scx> What I really try to do is to verify support for AVS2 (Chinese format, competitive to H.264/H.265) [21:08:48 CEST] <scx> Unfortunately, I was unable to find any samples. [21:09:12 CEST] <scx> So I tried to make one by using xavs2: https://github.com/pkuvcl/xavs2 [21:09:30 CEST] <scx> It requires a YUV input [21:10:06 CEST] <scx> Anyway, I just compiled FFMPEG with DAVS2 support, but it is unable to open that video [21:11:44 CEST] <durandal_1707> im not into that china stuff, ask maintainer of davs2 [00:00:00 CEST] --- Sun Sep 15 2019

1 0

ffmpeg.log.20190914
by burek 15 Sep '19

15 Sep '19

[10:10:36 CEST] <inna> hey [10:11:50 CEST] <egrain> hi. [10:12:43 CEST] <inna> watching someone on youtube spell a damn url for like 1 minute made my brain stick to the idea of a feature that transmits metadata that instructs players to display a textbox with an arbitrary text that is already selected for copying to clipboard in the player rect [10:13:10 CEST] <inna> with modern container formats, this should not be a problem right? [10:45:40 CEST] <snooky> moin [10:49:09 CEST] <inna> a text-selectable forced subtitle [10:49:36 CEST] <inna> quasi-forced [10:52:04 CEST] <furq> that would be trivial to implement in a container and impossible to get anyone to implement in a player [10:52:19 CEST] <furq> so i would probably just use the video description text box [11:04:30 CEST] <poutine> couldn't you stuff it in the private data of the adaptation field? [19:20:08 CEST] <cousin_luigi> Greetings. [19:23:37 CEST] <cousin_luigi> bye [19:25:24 CEST] <cousin_luigi> Re. I quit too soon. [19:27:36 CEST] Action: cousin_luigi downloaded a .m3u8 file and all of the listed segments, then concatenated them with cat and then converted it to mp4 without codec change with ffmpeg. What I can't explain myself is the size: 4.2GB for a 736x414 video. [19:27:41 CEST] <cousin_luigi> h264/AAC [19:59:08 CEST] <dartleader> All of the vob files I am converting to mkv are suffering terrible resolution loss, I can't figure out how to fix it, is there a particular option I am supposed to be passing? [20:00:13 CEST] <klaxa> if you don't want to re-encode, use -c copy [20:02:56 CEST] <cousin_luigi> Can I use amdgpu hevc encoding with ffmpeg < 4? [20:21:38 CEST] <scx> Hello [20:22:25 CEST] <scx> What do I need to open YUV4MPEG? [20:22:27 CEST] <scx> YUV4MPEG: video is not in a supported format. [20:23:42 CEST] <pink_mist> dartleader: and if you do want to re-encode, make sure you change from the defaults, because those are normally horrible [23:31:47 CEST] <wildefyr> does -ss only take input with 00:00:00 format? I have a script produces the time I want in seconds only [23:32:03 CEST] <wildefyr> so in the format "sec.msec" [23:32:17 CEST] <TheAMM> It takes input in multiple formats, 123.456 should work just fine [23:33:07 CEST] <wildefyr> yep as it does, error was with my scripting [00:00:00 CEST] --- Sun Sep 15 2019

1 0

ffmpeg-devel.log.20190825
by burek 14 Sep '19

14 Sep '19

[00:01:23 CEST] <kierank> thardin: travel is cheap, hotel is not [00:49:58 CEST] <BBB> kierank: depends where you're coming from :) [00:50:11 CEST] <kierank> true [04:15:57 CEST] <cone-254> ffmpeg 03James Almer 07master:21d7eeafc134: avcodec/mlp_parse: move TrueHD channel layout and sample rate related code to the header [04:15:57 CEST] <cone-254> ffmpeg 03James Almer 07master:c300fe13b629: avcodec/mlp_parser: export AVCodecContext frame_size [04:15:57 CEST] <cone-254> ffmpeg 03James Almer 07master:d1409fe95282: avformat/mov: add demuxing support for Dolby TrueHD streams [04:15:57 CEST] <cone-254> ffmpeg 03James Almer 07master:808a6717e0c5: avformat/movenc: add muxing support for Dolby TrueHD streams [04:27:01 CEST] <durandal_1707> kierank: take hostel? [04:27:14 CEST] <kierank> durandal_1707: for business trip? [04:31:06 CEST] <durandal_1707> kierank: its affordable for microsoft :p [04:31:52 CEST] <kierank> durandal_1707: are you drunk [04:32:36 CEST] <durandal_1707> just woken up, after not nice dream [04:36:26 CEST] <kierank> see doctor [04:36:32 CEST] <durandal_1707> who thought life of coder would be so easy [04:36:51 CEST] <kierank> should take vacation without computer [04:37:25 CEST] <nicolas17> easy wat [04:39:46 CEST] <durandal_1707> then i would miss all those nice patches [08:15:48 CEST] <thardin> kierank: I have friends in amsterdam, could probably crash at their place [08:19:32 CEST] <durandal_1707> kierank want to go all cheap [12:12:43 CEST] <durandal_1707> still no reviewers for mov timecode patch [12:14:08 CEST] <cehoyos> durandal_1707: Will you commit the dsd patch? [12:14:45 CEST] <durandal_1707> after vacation, yes [12:16:49 CEST] <durandal_1707> you like to listen dsd music? [12:19:13 CEST] <cehoyos> No, but testing took time and I wondered if you forgot [14:49:40 CEST] <vel0city_netbook> Just finished the write-up for my GSoC work (DNG decoder), if anyone's interested: https://velocityra.github.io/gsoc-2019 [15:00:29 CEST] <BBB> for colorspace and whitepoint correction, I think it's mostly just a signaling thing and then converting in the player [15:00:43 CEST] <BBB> this is hard, because no player does this correctly, but we do provide filters for it (colorspace, iirc) [15:00:57 CEST] <BBB> they do theoretically correct whitepoint conversion etc. and are easy to extend with new formats as required [15:01:08 CEST] <BBB> koda did a whole bunch of additions to it after the initial filter was written [15:01:17 CEST] <BBB> otherwise looks cool [15:02:43 CEST] <BBB> btw I know this is strictly out of scope for your gsoc work, but for the blog to be interesting to a wider audience, it'd be interestig to note where dng files come from in the wild, i.e. what types of cameras generate tjem etc. [16:11:20 CEST] <cone-453> ffmpeg 03Carl Eugen Hoyos 07master:434588596fef: lavc/x264: Also clean-up libx264rgb after init errors. [20:20:41 CEST] <vel0city_netbook> BBB: true, I might add some more general info about DNG to it [20:30:39 CEST] <BBB> that would also be fun, yes [20:35:25 CEST] <vel0city_netbook> BBB: done [00:00:00 CEST] --- Mon Aug 26 2019

1 0

ffmpeg-devel.log.20190808
by burek 14 Sep '19

14 Sep '19

[00:02:07 CEST] <durandal_1707> michaelni: the retry counter breaks multiple pages tiffs? [00:03:54 CEST] <michaelni> durandal_1707, do you have a sample it breaks ? it worked with all files i tried but i did not try all files on this planet obviously [00:09:29 CEST] <durandal_1707> sample can be created with fcpx i think, if you follow path of page extraction, your patch breaks it [00:13:38 CEST] <durandal_1707> https://www.nightprogrammer.org/development/multipage-tiff-example-download… [00:14:13 CEST] <durandal_1707> searched, first result pop ups [00:14:31 CEST] <durandal_1707> cant check, only tomorrow [00:50:07 CEST] <Lynne> oh, so that qp api patch is from google, now it makes sense [01:01:37 CEST] <Lynne> I'll assume they've just learned about adaptive quantization, all the analyzers suck, so obviously they've hacked up ffmpeg, but in google spirit of cooperation they want to upstream their hacks [01:02:12 CEST] <kierank> there used to be (imo) quite clean support for qp extraction [01:03:39 CEST] <Lynne> I hope they go beyond debugging and actually start using adaptive quantization in their encoders, they're decades behind x264 in many ways [01:05:22 CEST] <kierank> Lynne: I would guess they want qp reuse for fast transcoding [01:05:23 CEST] <kierank> or the likes [01:08:14 CEST] <Lynne> how would that help? it shouldn't impact performance much for any decent encoder [01:08:28 CEST] <kierank> like super fast transcoding [01:08:44 CEST] <kierank> skip qp decision step [01:08:55 CEST] <kierank> or maybe that have some magic things they do with the qp data [01:10:02 CEST] <Lynne> the majority of time spent during vp9 or av1 encoding for most encoders atm is for block mode selection [01:12:48 CEST] <Lynne> I also thought they'd abstract aq into some separate library to signal some codec generic pseudo block importance to encoders, and while it'd be the google way, doesn't sound likely [01:13:20 CEST] <kierank> Lynne: maybe just ask the guy [01:14:18 CEST] <jkqxz> The reponse to cropping appears to be that they just want block QPs and don't care which pixels they actually correspond to in the output. I guess that means they're discarding the pixels, so it's purely some sort of analysis case. [01:28:27 CEST] <juandl> jkqxz: Indeed, it is for analysis [01:29:10 CEST] <juandl> I'm available to answer all the questions I can [01:38:37 CEST] <jkqxz> That seems like you don't actually want to run the decoder at all, then? [01:44:58 CEST] <juandl> The frame is decoded and the data structure proposed in the patch is stored as an array in AVFrameSideData [01:54:43 CEST] <lotharkript> they tried to follow the same type of structure as the MV one. [01:55:22 CEST] <lotharkript> he is trying to make it generic enough [01:56:33 CEST] <jkqxz> But you've said you don't want to include information to work out which block in the side data actually corresponds to a given pixel in the frame. [01:56:49 CEST] <lotharkript> i think they will need this. I can talk to them. [01:57:14 CEST] <lotharkript> they will need the pixel [02:04:19 CEST] <lotharkript> they are trying to replace FF_API_FRAME_QP with something similiar with AV_FRAME_DATA_MOTION_VECTORS as FF_API_FRAME_QP is being deprecated. [02:06:19 CEST] <lotharkript> i confirm with some of them. They do need the pixel associated with the QP. [02:08:19 CEST] <juandl> Yes, the purpose was to emulate the MV struct and make it generic enough [02:09:59 CEST] <lotharkript> so the question is: (i think) If the decoder has some notion of cropping, but you already store the pixel for the one to be cropped, what to do with the data? [02:13:40 CEST] <lotharkript> jkqxz: don't we have the problem already for MV? I'm not sure we are removing block from the AV_FRAME_DATA_MOTION_VECTORS after cropping [02:20:54 CEST] <lotharkript> will it be ok, if they offset the pixel based on the crop value, so the first pixel may have a coordinate of -20, -20 for example ? [02:36:52 CEST] <juandl> Alright, we had not considered cropping yet, but yes the origin (0, 0) used as reference for x and y in AVQuantizationParams has to match the "visible" frame, not the coded frame. So the coordinates can have negative values to represent pixels outside the frame. [02:38:58 CEST] <Compnn> >h264 cropping [02:39:01 CEST] <Compnn> yikes :D [02:41:55 CEST] <tmm1> jkqxz: when you get a moment can you peek at http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/247758.html. i think my patch is incomplete and seems to be affecting video quality [02:42:41 CEST] <juandl> About the codec dependent parts of the data structure, should this implementation be moved to avcodec? I have the idea that only encoders/decoders should go in avcodec and that a patch like this belongs more to avutil, despite the codec dependency. [07:43:27 CEST] <durandal_1707> michaelni: are you autistic? i gave you link above to tiff file, and then you reply as you have none [07:43:53 CEST] <durandal_1707> im deeply dissapointed [07:46:07 CEST] <durandal_1707> nah, just ignorant, not autistic [07:46:08 CEST] <michaelni> durandal_1707, please stop these insults, there where 2 files on the page which ffmpeg does not support and some link to software needing a windows machiene [07:49:08 CEST] <durandal_1707> how it is not supported? what ffmpeg gives you as output? [08:02:18 CEST] <michaelni> "[tiff @ 0x7f17b40025c0] JPEG compression is not implemented. ..." maybe it is possible to use these files somehow to test anyway but yesterday before going to sleep in the 30sec i had available i didnt find a way [08:07:41 CEST] <michaelni> yes with modified source code these can probably be used [09:56:28 CEST] <Compnn> durandal_1707, you need to stop with the name calling and insults [09:56:57 CEST] <Compnn> no one here finds it funny [09:57:05 CEST] <Compnn> it makes you look childish or unstable [09:58:42 CEST] <durandal_1707> im not talking with former mplayer devs [09:59:24 CEST] <Compnn> i'm a current mplayer dev. [10:11:42 CEST] <rcombs> durandal_1707: I agree, that wasn't cool [10:12:48 CEST] <rcombs> particularly using neuroatypicality as an insult [10:15:27 CEST] <durandal_1707> he looks only his business [10:25:21 CEST] <durandal_1707> but looks you all love your leader so much, that you can not see real problems at all [10:27:39 CEST] <rcombs> this isn't anything personal, that's just a really shitty insult [10:30:50 CEST] <durandal_1707> oh, this really become personal long ago [10:36:29 CEST] <rcombs> I mean on my part [10:37:21 CEST] <rcombs> I don't particularly care about your beef here, just keep unrelated minority groups out of it [10:49:33 CEST] <kurosu> looking at the "extract QP" thingy, why are quantization implementation details exposed in a header? [10:50:41 CEST] <kurosu> are all those {y,uv}x{ac,dc} actually varying per block or per segment (I think it is the case for VP9, not AV1) [10:51:17 CEST] <kurosu> I mean, mpeg codecs also have chroma qp for one, and this dc/ac business is akin to quantization matrices [10:51:43 CEST] <kurosu> that seems mostly tailored to the vp* familly [10:53:11 CEST] <kurosu> I find this design ugly/easily broken, but then nobody is going to invest much more time to improve it [10:56:26 CEST] <durandal_1707> exact reason why it should not be applied [10:57:12 CEST] <kurosu> I have only read the first psot, mind you [10:58:22 CEST] <kurosu> Inlining patches (instead of attaching it) makes it very difficult to look for the latest patch version (patchwork maybe?) [11:01:37 CEST] <kurosu> I'm not against applying some refined versions (even if still vp*-centric), it just appears to require a lot of work to adapt it later, and not have people complain about how that broke API/ABI/their use of it [11:35:34 CEST] <kurosu> ok, I guess I'm late to the discussion anyway, so... [11:36:33 CEST] <nevcairiel> as long as its not commited yet, just comment on the ML [11:37:09 CEST] <nevcairiel> better to adress it now then have something with very limited functionality in public API [11:50:06 CEST] <jkqxz> Yeah, I'm still quite sceptical there. The definition feels specific enough that it's likely to result in noone else ever using it. Given that, it might as well stay in a private google tree. [11:51:46 CEST] <jkqxz> (My comments so far have mainly been trying to work out what their definition actually is.) [12:20:38 CEST] <cone-971> ffmpeg 03Jun Zhao 07master:5e829262a6a6: lavf/hls: add http_seekable option for HTTP partial requests [12:20:39 CEST] <cone-971> ffmpeg 03Jun Zhao 07master:6f6769f3ec50: lavf/showinfo: support mastering display sidedata [12:20:40 CEST] <cone-971> ffmpeg 03Jun Zhao 07master:e282b7ed7bf8: lavf/showinfo: use error level when get invalid sidedata [12:20:41 CEST] <cone-971> ffmpeg 03Jun Zhao 07master:e512d893bfcf: examples/encode_video: only add sequence end code for mpeg1/2 video [12:20:42 CEST] <cone-971> ffmpeg 03Jun Zhao 07master:e317c255f651: doc/ffmpeg: Document dts_error_threshold option [13:23:21 CEST] <J_Darnley> Is there is single AVX2 instrcution to interleave words from 2 registers across the lane boundary? [13:23:39 CEST] <J_Darnley> punpcklwd is split on the boundary [13:23:57 CEST] <J_Darnley> I don't think there is [13:24:11 CEST] <J_Darnley> So I'll have to do some more shuffling, maybe [13:24:51 CEST] <J_Darnley> oh, maybe I can abuse zero-extend... [14:24:33 CEST] <vel0city> how do I find/generate a FATE test file? I want "tests/data/fate/tiff-fax-g3s" [14:24:42 CEST] <vel0city> I looked at the ftp server with the test files but it's not there [14:26:34 CEST] <nevcairiel> files in tests/data are typically generated [14:27:19 CEST] <mkver> If I'm not mistaken, that file gets generated by the tiff-fax-g3s fate test. [14:27:31 CEST] <mkver> So you would have to make fate-tiff-fax-g3s [14:33:30 CEST] <vel0city> "fate-tiff-fax-g3s requires external samples and SAMPLES not specified" [14:33:43 CEST] <vel0city> it's generated but it still wants a source file I assume? [14:34:03 CEST] <vel0city> do I need to get the sample suite? [14:35:53 CEST] <mkver> Yes. [14:37:28 CEST] <vel0city> hm alright, thanks [14:38:33 CEST] <mkver> More exactly, this test runs framecrc on $(TARGET_SAMPLES)/CCITT_fax/G31DS.TIF, so at least this sample is required. [14:39:39 CEST] <vel0city> I cool I'll just get that then, thanks [15:20:22 CEST] <durandal_1707> vel0city: use rsync to get that tiff file [15:28:10 CEST] <vel0city> @durandal_1707 I got it yeah, regression is fixed now [15:33:15 CEST] <durandal_1707> note @ is not part of my nick, its just mark for irc operators [15:34:58 CEST] <kierank> durandal_1707: mark of leader [15:35:14 CEST] <vel0city> durandal_1707: ah, I know it is but I still thought it's used when replying [15:38:20 CEST] <durandal_1707> when you use @ i will not get notified at all that you sent me something [15:38:35 CEST] <vel0city> I see [15:43:24 CEST] <kurosu> vel0city: most irc clients (even web-based ones) have auto-completion, where by typing the start of a nick, hitting "tab" completes it according to the channel user list [16:03:27 CEST] <gnafu> durandal_1707: You don't have your IRC client configured to highlight you even when someone mentions your name? [16:03:37 CEST] <vel0city> kurosu: didn't know that, thanks [16:03:47 CEST] Action: gnafu has it so even if "gnafu" shows up in the middle of a line, it will notify him. [16:05:24 CEST] <durandal_1707> even with "junkgnafujunk" sorry if that is not political correct [16:05:29 CEST] <kurosu> yeah, I bet a lot of clients do that, but then you sometimes foolishly peek in your teen years a very frequent word, and get highlighted for plenty of things [16:05:49 CEST] <gnafu> durandal_1707: Yep :-P. [16:05:50 CEST] <kurosu> like if I would talk about the Big Buck Bunny sequence (and BBB were here) [16:06:13 CEST] <vel0city> eh, I have it enabled for "velocity" too and I barely get any false positives [16:06:30 CEST] <gnafu> kurosu: It was something I had to configure, if I recall correctly (it was years ago now). It's an extra line in my Irssi config file. [16:06:39 CEST] <vel0city> and I'm in 20 chans (most not very active though) [16:06:53 CEST] <gnafu> But "gnafu" is uncommon enough that I am probably the thing being referred to [16:06:56 CEST] <gnafu> . [16:43:23 CEST] <vel0city> should I be changing a MJpegDecodeContext from tiff.c? the header/struct is already included [16:43:51 CEST] <vel0city> there are alternatives for what I want to do but this is the less hackier one [16:44:09 CEST] <vel0city> a MJpegDecodeContext *field [16:45:17 CEST] <durandal_1707> michaelni: for tiff pages patch, couldnt check that offsets are strictly increasing? [16:46:12 CEST] <durandal_1707> if not, it would be strange and illogical [16:55:03 CEST] <michaelni> durandal_1707, i thought so too but then i do not want to break files just because the offsets go the other direction. [16:59:11 CEST] <durandal_1707> need to check tiff specs [17:12:16 CEST] <durandal_1707> just check for increasing order and otherwise ask for sample? [17:12:41 CEST] <durandal_1707> vel0city: what you think? [18:28:54 CEST] <lotharkript> nevcairiel: regarding the AQ patch, could you please comment on what you would like to see it done. I think they are fine to work on. But it seems there are too many opinion on what it should be doing. [18:29:42 CEST] <nevcairiel> what patch is that? [18:29:49 CEST] <lotharkript> The QP i meant [18:30:17 CEST] <lotharkript> the intern is willing to work with the ffmpeg community to have the feature approve by all of you [18:30:31 CEST] <lotharkript> he even post it a design doc. [18:30:52 CEST] <lotharkript> he just need some guidance from the community to what it should be [18:31:37 CEST] <lotharkript> FF_API_FRAME_QP is going to be deprecated. And they just want to offer an alternative to it [18:31:50 CEST] <lotharkript> the same way the MV was done. [18:32:30 CEST] <lotharkript> nevcairiel: will you be willing to have a chat with them directly? instead of exchanging email? [18:33:25 CEST] <nevcairiel> I've not had a single involvement with that patch, I think you must be looking for someone else [18:34:44 CEST] <lotharkript> sorry, maybe it is jkqxz ? [18:34:58 CEST] <lotharkript> who should be the correct contact to talk about the QP patch? [18:35:28 CEST] <durandal_1707> talk with Lynne and michaelni [18:37:00 CEST] <lotharkript> it looks like also kurosu and jkqxz have some comment or suggestion.. [18:37:16 CEST] <lotharkript> if Lynne is ok with the design, will it be some problem with other? [18:38:31 CEST] <durandal_1707> where is design? [18:38:45 CEST] <michaelni> if others are ok with it, sure iam ok with it too [19:15:09 CEST] <michaelni> durandal_1707, i can check for increasing order but iam not sure the spec requires this. the only text about order i found is "Subsequent images, such as reduced-resolution images, may be in any order in the TIFF file." [19:16:16 CEST] <durandal_1707> yes, but ifd offset order is something else [19:16:57 CEST] <michaelni> yes [19:17:30 CEST] <michaelni> but did you find something in the spec that requires it to be only increasing ? [19:17:42 CEST] <durandal_1707> the stupid spec just mentions that decoder do not need to check for loops [19:17:52 CEST] <michaelni> yes i saw that too [19:18:49 CEST] <michaelni> well if you prefer to check for increasing then ill do that, just saying it would be more robust to not require it [19:19:23 CEST] <durandal_1707> just add request for sample [19:19:39 CEST] <michaelni> yes of course [19:19:49 CEST] <michaelni> thx [19:20:03 CEST] <durandal_1707> so we can know application that writes such files, so we can make jokes about it [19:24:39 CEST] <durandal_1707> vel0city: i think accessing mjpegcontext may make sense, but us usual people tend to respond only when they see actual patch [19:25:11 CEST] <vel0city> durandal_1707: ok [20:03:08 CEST] <asukhanov> Design doc for Extract QP changes: https://docs.google.com/document/d/1WClt3EqhjwdGXhEw386O0wfn3IBQ1Ib-_5emVM1… The design was inspired by AVMotionVector. Juan wanted to make it work for any video codec,that's why he ended up having qp_arr - the list of quanization parameters per block, since codecs like vp9 and av1 provide tools to set different QP for Y/U/V blocks and per AC/DC coefficients. [20:06:42 CEST] <nevcairiel> "for any video codec" and "codec specific things" seems like a contradiction [20:07:55 CEST] <asukhanov> I would like to ask for ffmpeg community help with guidance on API. What would be the best way for him to move forward with this feature given that he has limited time left in his internship? [20:10:01 CEST] <asukhanov> <nevcairiel>, fair point. How would you suggest to modify AVQuantizationParams to resolve this contradiction given that codecs have different number of quantization parameters and some other code needs to distinguish them in AVQuantizationParams? [20:11:11 CEST] <kurosu> jkqxz / lotharkript / asukhanov: yeah, I'm sorry to be a pain to eg an intern, or anybody in fact, about this - I didn't comment publicly (except here) because I can't spend much of my time on this (I'm mostly inactive nowadays) [20:11:55 CEST] <lotharkript> kurosu: no worry.. they just want to do the right thing, [20:11:59 CEST] <kurosu> the issue to me is that each codec has its own way of expressing things, and the user has to know what the data means to make any use of it [20:13:55 CEST] <kurosu> restating my opinion: I'm concerned to have in a header so many details about one specific quantization scheme [20:14:05 CEST] <lotharkript> kurosu: any idea how we can avoid this? [20:14:13 CEST] <asukhanov> no problems, kurosu. I think what can help Juan at this point is comments from ffmpeg community members that 1) all other members agree with, so he does not need to go back and forth with his patches 2) are expressed as simple action times for him (use data struct X instead of data struct Y, etc) [20:14:37 CEST] <kurosu> I'm not an API designer, but a very low level guy (like some of your guys) [20:14:41 CEST] <kurosu> *yo [20:14:43 CEST] <kurosu> *you [20:15:33 CEST] <kurosu> I'd say you need to export the size of the per-unit quantization info (be it per block or anything) and have it flat, and have it versioned maybe ? (in case someone wants to add something) [20:15:35 CEST] <asukhanov> I'm Juan's intern host, Juan is also in this chat. we are open to work on addressing your comments and value your feedback. Thank you [20:15:42 CEST] <lotharkript> the problem is that even within one codec, the QP has different meaning. Should we then try to normlize the QP? or specify which QP schema it is? [20:15:43 CEST] <jkqxz> I feel like the first question to ask is who the intended users are and whether it's actually sensible to include it in FFmpeg. [20:15:44 CEST] <kurosu> but that's maybe over-engineering nobody thought about [20:16:11 CEST] <jkqxz> What you've said so far suggests you are developing a single analysis tool, which might well be better served by using your own branch. [20:16:31 CEST] <lotharkript> we want to replace FF_API_FRAME_QP [20:16:38 CEST] <lotharkript> as FF_API_FRAME_QP will be deprecated [20:16:49 CEST] <jkqxz> Locking down a specific API in FFmpeg will make development of an external tool harder, not easier. [20:16:52 CEST] <kurosu> well, exporting QP info is a very thought-after feature - I think I have seen the same being asked for hevc [20:17:02 CEST] <jkqxz> And it's not clear who the others users are. [20:17:44 CEST] <lotharkript> it was done for MV and vf_codecview.c will be one user [20:20:14 CEST] <asukhanov> To us, extracting Quantization parameter has been the same type of feature as extracting motion vectors. My team needs this feature for our analysis tool, I'm working on rate control and I need QP for debug/analysis. Other teams I talked to also expressed interested in this feature. Having this feature implemented in a local branch is inconvenient, since our teams using different repositories and syncing these branches with [20:20:14 CEST] <asukhanov> upstreams becomes less trivial [20:20:49 CEST] <jkqxz> And who actually uses the motion vectors? It doesn't appear to be supported for any codecs that people actually use nowadays. [20:21:19 CEST] <asukhanov> I hope it answers you question regarding intended users [20:25:19 CEST] <asukhanov> <kurosu>, regarding having the quantization info flat and versioned, do you mind going to Juan's design doc and leaving a proposed data structure in a form of Google doc comment so we could see what exactly you mean? This chat might be hard to use for code. We also can create a separate google doc document that everybody can modify [20:26:12 CEST] <durandal_1707> whats wrong to make another project that exactly this just for codecs you want? [20:29:23 CEST] <asukhanov> I just created a document which everybody can contribute to: https://docs.google.com/document/d/1IxQqvYyjsaGiC5KzYCRl0hlAwKix7I7zvaq1Pc2… [20:30:35 CEST] <lotharkript> durandal_1707: are you saying that even the MV should not have been in ffmpeg? we use to have QP, see https://trac.ffmpeg.org/wiki/Debug/MacroblocksAndMotionVectors will be nice to continue to support it.. [20:31:27 CEST] <asukhanov> durandal_1707, do you mean not using ffmpeg at all? If so, our team already uses ffmpeg/ffprobe to analys video streams (psnr/ssim computation, frame size extraction). ffmpeg has h264, vp9 and (I believe av1) decoders, so it was natural for us to consider extending ffmpeg to extract QP for us. [20:34:50 CEST] <durandal_1707> for av1 decoders qp and mv extraction you need to ask somebody else [20:35:34 CEST] <durandal_1707> as you already know ffmpeg does not have native decoders for av1 [20:43:26 CEST] <Dmitri_Ovch> Hi! i reuploaded a patch with linux support for AMF/VCE (https://patchwork.ffmpeg.org/patch/14319/) Could you please review? [20:44:02 CEST] <asukhanov> It's good to know that, it was suggested to work on H264/VP9 and leave AV1 out for now. [20:47:13 CEST] <durandal_1707> well, at least one FFmpeg dev wants full solution that does not need lot of drastic changes [20:51:49 CEST] <durandal_1707> after each update, dunno if his willimg to write structures [21:12:50 CEST] <kurosu> asukhanov: sorry 9pm here, and I actually can't spend enough time on ffmpeg in the foreseeable future [21:13:32 CEST] <kurosu> I just happened to restart a conversation earlier today [21:18:54 CEST] <tmm1> trac is missing 4.2 in the version dropdown [21:24:58 CEST] <jkqxz> tmm1: Wrt A/53 in VAAPI, I think I'd prefer having the structures in CBS. [21:25:05 CEST] <jkqxz> I haven't looked at that patch in a long time, though. [21:25:51 CEST] <jkqxz> Wrt that bug you just raised, it's the general auto-insert-swscale case. See the suggested "autoscale" option discussion on the ML recently. [21:29:14 CEST] <tmm1> ah, thanks for that pointer. i'll try this autoscale patch [21:29:54 CEST] <tmm1> the a/53 vaapi patch is quite small, and re-uses the same H264RawSEIUserDataRegistered struct that the cbs uses as well [21:31:54 CEST] <tmm1> i can try reviving that a/53 cbs misc patchset, i do think that's worth merging [21:32:32 CEST] <tmm1> jkqxz: can you help me understand what needs to happen for force_key_frames in vaapi. can i simply bring back the logic that used to be in vaapi_encode_truncate_gop() [21:38:09 CEST] <jkqxz> I'm looking at that now. [21:41:23 CEST] <jkqxz> Losing that is a rather stupid error on my part. I actually remember testing its interaction with all the tricky H.264 reference picture stuff, so I'm not sure how I then managed to lose it completely. [21:50:59 CEST] <durandal_1707> which encoder should be done next? [21:52:56 CEST] <jkqxz> tmm1: What is going wrong with your patch for you? It looks right to me, and I don't see any problems from a small amount of testing. [21:53:00 CEST] <michaelni> tmm1, added 4.2, should be there now [21:54:56 CEST] <durandal_1707> michaelni: update topic in #ffmpeg ? [21:55:36 CEST] <tmm1> jkqxz: the video quality got significantly worse [21:55:36 CEST] <michaelni> durandal_1707, done, thanks [21:56:25 CEST] <taliho> /join #ffmpeg [21:56:41 CEST] <tmm1> i thought maybe input_order had to be reset too, or maybe references had to be updated like the old truncate_gop method used to do [21:56:58 CEST] <jkqxz> tmm1: With RC enabled on some particular driver and platform? [21:58:30 CEST] <jkqxz> The old truncate_gop method existed because the code tried to decide in advance what the structure was going to be then find frames to fill it, so it had to mess around with references if the structure changed. [21:59:10 CEST] <jkqxz> The current code only decides what a frame is going to be when it actually has it, so it never needs to modify the references after the fact. [22:02:45 CEST] <tmm1> hmm okay that makes sense. i'm using vbr and comparing quality on 4.0 vs 4.2+patch, so let me bisect a bit more and see if its a unrelated regression [22:07:19 CEST] <jamrial> durandal_1707: improve or fix dts/truehd encoders [22:08:28 CEST] <kierank> durandal_1707: third prores encoder [22:08:41 CEST] <durandal_1707> buhaha [22:11:28 CEST] <durandal_1707> i will try to look again to truehd/mlp as it is lossless and easier to deal with [22:29:11 CEST] <Lynne> durandal_1707: start from the 5-part mlp patchset from last month, they fix things somewhat [22:29:45 CEST] <Lynne> use 24 bit encoding too, then crackling happens more often [22:31:01 CEST] <durandal_1707> is 16bit mlp encoder working fine? [22:33:24 CEST] <Lynne> nope, crackles (checksum fails), but less often [22:35:54 CEST] <Lynne> feed it actual content, so music and such, sine waves and white noise are encoded fine [22:59:01 CEST] <tmm1> jkqxz: it looks like i'm only getting a 300kbps stream even though I configured VBR at 3mbps https://paste.ubuntu.com/p/9tkZQKWQV5/ [23:00:25 CEST] <tmm1> same behavior in ffmpeg 4.1, but ffmpeg 4.0 works [23:08:10 CEST] <jkqxz> What about with iHD? [23:08:17 CEST] <jkqxz> There are weird RC problems in the Intel drivers. [23:12:00 CEST] <tmm1> cbr works as expected, only vbr seems broken [23:15:27 CEST] <tmm1> i'll try switching from i965 to iHD and see what happens [23:15:39 CEST] <tmm1> i did try using the latest i965 with ffmpeg 4.0 and that combination still works [23:17:44 CEST] <jkqxz> The older version makes different choices about how it sets up the VBR parameters. [23:19:40 CEST] <tmm1> i don't really understand the difference between i965 and iHD [23:19:55 CEST] <durandal_1707> Lynne: spotted already huge memory leak [23:21:30 CEST] <Lynne> where? it does a per-frame alloc but frees them unconditionally [23:27:10 CEST] <durandal_1707> Lynne: apply_filter [23:27:33 CEST] <durandal_1707> when it returns -1 [23:27:58 CEST] <durandal_1707> also encoder work internally with 24bit data [23:28:24 CEST] <durandal_1707> thus making check in this function invalid [23:28:58 CEST] <durandal_1707> this was student first and wrong committ [23:30:02 CEST] <durandal_1707> you cant teach student complicated things with student zero previous experience [23:31:01 CEST] <Lynne> most of the work wasn't done by a student though [23:32:00 CEST] <durandal_1707> yes, but still understanding is required [23:38:14 CEST] <durandal_1707> i dunno how much leaks are trigerred [23:46:57 CEST] <tmm1> jkqxz: so if i match the rc_params i should be able to replicate the old behavior? [23:47:08 CEST] <tmm1> trying to compare the values being sent to va now.. https://paste.ubuntu.com/p/M3cwVk4J8v/ [00:00:00 CEST] --- Fri Aug 9 2019

1 0

ffmpeg-devel.log.20190913
by burek 14 Sep '19

14 Sep '19

[00:34:51 CEST] <kylophone> in libavcodec, can I set pix_fmt directly during init? [00:35:32 CEST] <kylophone> usecase: don't know which pixel format is required until i see avctx->profile [08:25:05 CEST] <cone-683> ffmpeg 03Gyan Doshi 07master:09933279396e: cmdutils: promote report level if loglevel is higher [11:35:22 CEST] <cone-683> ffmpeg 03Paul B Mahol 07master:2b3094d61de8: avfilter/vf_v360: fix flat projection field of view calculation [12:36:09 CEST] <cone-683> ffmpeg 03Paul B Mahol 07master:ed4ad6e1ed97: avfilter/vf_v360: use always float version instead of double floating-point function [19:48:10 CEST] <klaxa> when doing consulting work, how much do you usually charge? a start-up my brother works at asked for help with their ffmpeg stuff [19:49:52 CEST] <klaxa> nothing too in-depth, they are using fluent-ffmpeg (a js wrapper for calling ffmpeg) [20:39:00 CEST] <cone-683> ffmpeg 03Paul B Mahol 07master:de125a09424a: avformat/sccdec: remove not needed code [23:07:34 CEST] <cone-683> ffmpeg 03Michael Niedermayer 07master:2006e5ccb6db: avcodec/mjpegdec: Only allow 0x11110000 pix_fmt_id for bayer mode [23:07:35 CEST] <cone-683> ffmpeg 03Michael Niedermayer 07master:3b5ce76b1a68: avcodec/mjpegdec: Restore non bayer checks in ljpeg_decode_rgb_scan() [00:00:00 CEST] --- Sat Sep 14 2019

1 0

ffmpeg.log.20190913
by burek 14 Sep '19

14 Sep '19

[00:00:17 CEST] <KodiakIT[m]> kepstin: I'm fine with using ffmpeg, I was just using handbrake to get it off the dvdbackup dumps [00:04:12 CEST] <KodiakIT[m]> And used CQ0 to make sure they were as close to the originals as I could get so I could then transcode those when I got around to it/if I needed to free up disk space [00:04:32 CEST] <kepstin> KodiakIT[m]: if you're doing multipass - and you should always do multipass with libvpx vp8/vp9 to work around the encoder not being greate - theyn consider using -speed 4 for the first pass [00:05:05 CEST] <kepstin> KodiakIT[m]: note that the cq scale doesn't match between vp8 and vp9, but either way cq 0 is probably a waste of space. You might as well just copy the original video without re-encoding :/ [00:05:37 CEST] Action: KodiakIT[m] shrugs [00:06:10 CEST] <KodiakIT[m]> A ~2GB VP8 encoded mkv is an improvement on an ~8GB disc image [00:07:21 CEST] <kepstin> KodiakIT[m]: anyways, x264 encoder is faster and easier to configure and better quality than vp8 (probably close to vp9 in this sort of circumstance), so I recommend it for this type of use case normally [00:07:30 CEST] <kepstin> KodiakIT[m]: unless you really want to avoid h264 for some reason [00:10:51 CEST] <KodiakIT[m]> kepstin: I'll keep that in mind, I guess I just kinda felt like it was the FLOSSier option of the two and ran with it for that (that and I'd thought they were both designed to be more efficient than 264 anyway) [00:11:17 CEST] <kepstin> vp9 in theory can compress more efficiently than h264 [00:11:30 CEST] <kepstin> x264 in practise is a better encoder than libvpx [00:11:32 CEST] <cehoyos> VP8 cannot be more efficient than x264 [00:11:33 CEST] <kepstin> so ... :/ [00:12:40 CEST] <kepstin> KodiakIT[m]: anyways, x264 for this purpose will get you a result almost as good as what libvpx-vp9 can do, but will be much faster at doing so. [00:13:12 CEST] <kepstin> (a lot of vp9's enhancements focus on higher resolution video, so it doesn't help as much on SD stuff like DVD sources) [00:14:21 CEST] <KodiakIT[m]> kepstin: Good points [00:39:54 CEST] <DHE> yeah, as a codec vp8 is kinda in the same "weight class" (whatever you want to call it) as h264 but x264 is just such a good encoder... [00:46:23 CEST] <BtbN> And libvpx is a particularily BAD one [02:29:19 CEST] <analogical_> I need an ffmpeg ninja who can extract the debate video stream from https://abcnews.go.com/ [03:21:08 CEST] <klaxa> analogical: if you open it in a browser and use the web-console, you can find something with the type: vnd.apple.mpegurl, that's hls afaik and can be fed to ffmpeg or mpv [03:22:08 CEST] <analogical> klaxa, web-console? [03:22:45 CEST] <klaxa> in firefox ctrl+shift+i [03:22:55 CEST] <klaxa> in chrome i think the same? [03:23:05 CEST] <klaxa> or maybe f12 [03:28:27 CEST] <klaxa> of course i meant the web-developer tools [03:28:38 CEST] <klaxa> i'm really tired right now, sorry [03:33:21 CEST] <furq> it's f12 in firefox [03:33:28 CEST] <furq> search for m3u8 in the network panel [03:33:51 CEST] <furq> also it probably won't work because anyone halfway competent will prevent you from watching it without the right cookies or something [03:34:28 CEST] <furq> youtube-dl doesn't support it and it's a usa broadcast network so i assume there's no simple way around it [03:35:00 CEST] <furq> just vote for bernie, it'll be fine [03:40:58 CEST] <klaxa> well it worked for me just right-click copy-url and paste the really long url to mpv [03:41:20 CEST] <klaxa> and from my home connection as well from europe [03:43:26 CEST] <furq> i would have tried it but then i'd have had to actually watch it [03:43:43 CEST] <klaxa> i also accidentally watched for a few minutes [03:43:52 CEST] <klaxa> but now i will go to bed, good night [05:21:34 CEST] <intrac> could someone suggest the best way to take the audio from a source file, then split into two copies in a complex_filter chain [05:21:50 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#split_002c-asplit [05:21:52 CEST] <intrac> apply audio filter(s) to one copy and pass through the other. [05:22:01 CEST] <intrac> https://i.imgur.com/TVbAVBU.png [05:22:34 CEST] <intrac> a moment, checking [05:22:58 CEST] <furq> -lavfi "[0:a]split=2[out1][tmp];[tmp]...[out2]" -map "[out1]" -map "[out2]" [05:23:17 CEST] <furq> asplit=2 rather [05:24:56 CEST] <intrac> furq: thanks. will give that a go. I was overthinking it [05:38:37 CEST] <intrac> furq: thanks, that got it! [08:07:57 CEST] <bneff> I'm trying to open an RTSP stream with avformat_open_input and passing an options dictionary with "allowed_media_types" set to "video". However, I'm still receiving the audio stream. Any suggestions? I'm using ffmpeg 4.2. [08:48:22 CEST] <voldial> can I get ffmpeg to exit on the first error? I dont want to parse the entire file, I just want to know if there's any errors, so I am doing this: http://dpaste.com/3NN64VB but ffmpeg spawns more than one process, so there's still more children of $! to kill: http://dpaste.com/3P9T67P [11:30:23 CEST] <solrize> is there a decent way to extract closed captions from an mp4, where there doesn't seem to be an srt stream? the stuff i've been able to find assumes srt format [11:31:03 CEST] <Radiator> Hi all, I was browsing avutil and the pixfmt.h file to be precise. I haven't found any function or tools that can give the specification of a format. Do you know if there such a thing ? Like from a AVPixelFormat get a bpp and linesize or so ? [11:32:24 CEST] <BtbN> You haven't searched very well then, there is a whole massive structure with that data. [11:32:51 CEST] <BtbN> linesize is unrelated to the pix_fmt though, so you won't get that from the format. [11:34:15 CEST] <Radiator> BtbN: There's comments only, I'm looking for something in the runtime like a function [11:34:25 CEST] <BtbN> Yes, that exists. [11:35:00 CEST] <Radiator> For real ? I must have missed it [11:35:05 CEST] <Radiator> Which file ? [11:35:21 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/pixdesc.c [11:35:56 CEST] <Radiator> Oh wow [11:36:03 CEST] <Radiator> Thanks a lot [11:36:19 CEST] <Radiator> I feel dumb passing by such evident information [11:38:34 CEST] <Mavrik> ;3C [11:43:06 CEST] <Radiator> BtbN: What do you mean by "linesize is unrelated to the pix_fmt though, so you won't get that from the format." ? I though the line size depended entirely on the format. RGB24 is bpp*width for example [11:43:36 CEST] <BtbN> The linesize depends on hardware alignment constraints [11:44:07 CEST] <BtbN> So like AVX-512 might need a larger align than AVX2 [11:45:29 CEST] <Radiator> Ooooh ok ! [13:57:11 CEST] <Radiator> Is it possible to scale a frame though a device ? Like it is possible for decoding ? [13:57:19 CEST] <Radiator> *through [14:37:28 CEST] <DHE> there is a cuda rescaler listed in the filter list... [14:38:01 CEST] <Radiator> Thanks [14:54:47 CEST] <nilshi> Hello, I am looking for a way to generate a video that just shows a time code or clock. minutes:seconds. Is this possible with ffmpeg? [15:02:52 CEST] <DHE> yes, you can build a video entirely out of filters including drawtext [15:04:45 CEST] <nilshi> Thanks, I will investigate this further [15:35:58 CEST] <DHE> you'll probably want the color filter to generate just a blank rectangle to start with, then drawtext to put some text onto it. [15:37:01 CEST] <DHE> you can experiment with: ffplay -f lavfi -i color=c=black,drawtext=[...] # I believe this works [17:43:32 CEST] <bneff> I'm trying to set options when calling avformat_open_input() to only pull the RTSP video streams, and not audio. This is how I'm doing it based on looking at examples: https://pastebin.com/vPn2unvX This method isn't working and the audio stream is still being requested. Does anyone know how to accomplish this? [17:58:30 CEST] <Radiator> Anyone knows why av_frame_copy doesn't really works ? I had a bit of a struggle and found this : https://stackoverflow.com/questions/38808946/copying-a-decoded-ffmpeg-avfra… but I still have an issue to make it work. The dest buffer is empty once I free the source frame [17:59:42 CEST] <Radiator> I'm using the dest frame on sws_scale a bit later that manipulation and sws_scale break [18:01:54 CEST] <kepstin> Radiator: you probably shouldn't be calling av_frame_copy [18:02:23 CEST] <kepstin> Radiator: frames buffers are reference counted, you need to make sure that if you're accessing the data in a frame, then you have a reference [18:02:35 CEST] <Radiator> Ok [18:02:48 CEST] <Radiator> av_frame_move_ref would do the trick then ? [18:02:53 CEST] <kepstin> and if you're writing to a frame, then you call av_frame_make_writable and it copies it automatically only if needed [18:03:16 CEST] <Radiator> Good to know but I'm only reading [18:04:09 CEST] <kepstin> dunno why you'd call move_ref when unless you have something weird like a stack-allocated avframe [18:05:44 CEST] <kepstin> normally you'd use av_frame_ref and av_frame_unref only [18:06:04 CEST] <kepstin> somewhere that wants to keep a frame to use later for some purpose should use av_frame_ref [18:06:36 CEST] <kepstin> and when you're done with the frame, you use av_frame_unref (or _free) [18:15:47 CEST] <Radiator> I'm in C++ and I have a temporary frame in my class to then allow conversion and so on with it. av_frame_move_ref did worked. THe problem is that I don't want any memory leak, and to do so I must ree the frame that are decoded etc... I'm doing some hardware acceleration at the same time so I have two frames to do it. But it works now. Thanks a lot [18:15:47 CEST] <Radiator> :) [18:16:10 CEST] <Radiator> *i must free [20:47:45 CEST] <Heart_And_Chops> hi guys [20:48:27 CEST] <Heart_And_Chops> On my tiny little go pro knock off there is a setting "Lens Distortion Correction" which makes the 150 degree wide angle fish eye lens video into NOT fish eye. [20:48:33 CEST] <Heart_And_Chops> im assuming this is done with software. [20:48:43 CEST] <Heart_And_Chops> is it possible to do such a transformation with ffmpeg? [20:49:35 CEST] <Heart_And_Chops> oh: http://www.stjhimy.com/posts/2016-10-27-ffmpeg-lens-correction/ [20:49:36 CEST] <Heart_And_Chops> neat [20:49:37 CEST] <Heart_And_Chops> nevermind then [20:56:01 CEST] <LaserEyess> using vf/filter_complex is it possible to use the output of one filter as the input to the next? the usecase I'm trying to think of is autocrop + scaling, while keeping aspect ratio, but depending on if the video is letter/pillarboxed I have no idea whether to fix the height or width on resize [20:56:32 CEST] <LaserEyess> ideally what I'd like to do is get the crop values form cropdetect and use them to inform what my scale should be [20:58:29 CEST] <LaserEyess> right now my idea is to parse the output of a separate ffmpeg command where I just do cropdetect and output to null, then compare that with the size of the video and adjust accordingly, but that's hard to automate and kinda prone to error if I pick a scene that's dark enough for cropdetect to have trouble [21:20:24 CEST] <solrize> anyone know what it means when a video stream has closed captioning? the file doesn't seem to have an srt stream [21:21:08 CEST] <DHE> there's a standard for the video stream to carry embedded auxiliary data including closed captions [21:21:46 CEST] <DHE> many of the h264 encoders (including libx264) have an option -a53cc which will copy captions from source to destination so they are at least preserved [21:28:03 CEST] <solrize> DHE thanks, i'm trying to find a way to extract the captions to a text file and not having any luck. any suggestions would be welcome [21:30:46 CEST] <DHE> while ffmpeg includes some code to help do that, it's not built into ffmpeg afaik. the data comes out as AVSideData from the video stream and needs to be processed into a new subtitle stream [21:31:30 CEST] <DHE> I know mpv is capable of doing this and will export such a closed caption stream as one of its subtitle options for playback [21:34:20 CEST] <cehoyos> solrize: ffmpeg -f lavfi -i "movie=yourinputfile[out+subcc]" -map s out.srt [21:49:35 CEST] <solrize> cehoyos, thanks, will try [21:55:16 CEST] <solrize> seems to be decoding through the file and making occasional warning messages but has not written any output. maybe being buffered? it's a big file so it will be a while before decoding finishes [21:55:54 CEST] <solrize> anyway will wait for it to finish. thanks! it's doing much more already than anything else i had tried [22:04:19 CEST] <kepstin> LaserEyess: in order to pass the result from e.g. cropdetect to crop, you have to run the video through the filter chain twice. Which basically means decoding+filtering the whole video, throwing out the result, then going back to the start and decoding+filtering the video again. [22:04:44 CEST] <kepstin> LaserEyess: the ffmpeg cli tool doesn't support this. It's theoretically possible if all the inputs are files, but it can't work if any of the inputs are live streams, so... :/ [22:05:08 CEST] <solrize> cehoyos, thanks, it is working!!! [23:13:26 CEST] <LaserEyess> kepstin: that's what I figured, for now that's what I do, just run 10ish seconds of the video through cropdetect, then parse out the crop and run it again with the correct crop= and scale= and then encode [23:13:28 CEST] <LaserEyess> it's a bit hacky but it works [23:13:32 CEST] <LaserEyess> thank you [00:00:00 CEST] --- Sat Sep 14 2019

1 0