Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

August 2019

2 participants
58 discussions

ffmpeg.log.20190828
by burek 29 Aug '19

29 Aug '19

[04:01:24 CEST] <KodiakIT[m]> So, I know this isn't exactly ffmpeg-specific so much as a general programming question, but how does this script look to people here? https://gist.github.com/KodiakIT/b2e5807e7b119098a371eb93ae8152ce [04:08:29 CEST] <KodiakIT[m]> No bone-headedly stupid syntax errors? I still need to work in the bitrate var for any 256k+ files, and any m4a's [04:11:51 CEST] <furq> infile=$(echo $f); [04:11:53 CEST] <furq> what on earth [04:23:21 CEST] <furq> https://clbin.com/5MT5z [04:23:22 CEST] <furq> something like that [04:26:19 CEST] <Hello71> $SHELL doesn't do what you think [04:28:14 CEST] <KodiakIT[m]> furq, now that you mention that, that's mostly left over from the early copies of the script. I think there was some issue with (unescaped?) spaces if memory serves?, AFAIK, the IFS should fix that. [04:28:18 CEST] <Hello71> printf '%s\0' "$@", no need for {}, some other issues [04:29:02 CEST] <furq> what's wrong with printf '%s\0' [04:29:05 CEST] <another> oh goad [04:29:30 CEST] <another> KodiakIT[m]: i highly recommend you run shellcheck on that script [04:30:16 CEST] <Hello71> furq: it's fine, you just don't need a for loop in shell [04:30:44 CEST] <furq> that's the only reliable way i ever found of handling spaces in filenames [04:31:07 CEST] <furq> bearing in mind \n etc are legal in filenames if someone is a real bastard [04:31:17 CEST] <KodiakIT[m]> Feh. Doesn't seem to be in my path (I'm currently on Windows editing this w/ VSCode, stuck waiting on an external drive to finish compressing so I can squeeze a tiny but more space out of it as a network share after I'm done mucking about with some the files on there) [04:32:49 CEST] <KodiakIT[m]> Also, as I thought I'd mentioned here, but apparently actually said elsewhere I'm rusty as hell with any kind of scripting/coding [04:32:55 CEST] <furq> also i know you don't need {} but it looks nicer to me [04:33:00 CEST] <furq> good point about $SHELL though that one is dumb [04:34:20 CEST] <furq> KodiakIT[m]: in short, you don't need any of those subshells except the one for ffprobe [04:34:37 CEST] <furq> including the one where you grep the ffprobe output [04:34:42 CEST] <another> furq: to handle spaces in filenames it's usually enough to do proper quoting [04:34:58 CEST] <furq> also i don't know why you would get the codec from ffprobe and then switch on the file extension [04:37:22 CEST] <furq> my main pet peeve there though is selecting files inside the script instead of passing them to the script [04:37:47 CEST] <KodiakIT[m]> furq: mostly because I've been adding things piecemeal. First converting the FLAC since that was the biggest offender wrt drive space, then I need to sort out the ALAC files, but that's also got an .m4a extension like the AAC-VBR encoded ones, so I needed a bit more info. [04:38:28 CEST] <KodiakIT[m]> And then wav, as those are also on the large side, but my collection doesn't have as many of them... [04:39:34 CEST] <qacky> You converted _from_ flac? Flac is lossless [04:40:17 CEST] <KodiakIT[m]> Yes, I know, but it takes up a fairly large amount of space, and I don't exactly have a ton of it to spare. Hence the down-converting [04:40:43 CEST] <qacky> should zip fairly well though [04:41:24 CEST] <KodiakIT[m]> I'd rather smaller and lossy than large and lossless. [04:42:43 CEST] <qacky> *shrug* to each their own spose. I'd move them offline. Still makes me mad how much content out there is badly encoded mp3s [04:42:48 CEST] <another> KodiakIT[m]: apparantly you can use it online now https://www.shellcheck.net/ [04:43:20 CEST] <KodiakIT[m]> Excellent, bookmarked. [04:44:01 CEST] <furq> i have some awful script somewhere that completely kills shellcheck [04:45:09 CEST] <qacky> that script has quite a few issues heh. you're redefining get_metadata on every loop interation for example [04:45:42 CEST] <KodiakIT[m]> qacky: I hadn't even realized that. [04:45:59 CEST] <Hello71> furq: you literally write printf '%s\0' "$@" [04:46:01 CEST] <qacky> shell escapes aren't really sanitized at all, lots of filenames could break it [04:46:05 CEST] <Hello71> and it does the needful [04:46:22 CEST] <furq> it's been long enough since i wrote the script i stole that from that i forget what i tried [04:47:27 CEST] <qacky> infile=$(echo $f); <-- dafawq? lol [04:48:31 CEST] <KodiakIT[m]> qacky: on that point (sanitizing filenames), apparently a couple of the filenames contain chars that Windows doesn't care for and refuses to delete. [04:49:56 CEST] <qacky> not surprised. Since you're using find, you could just use -print0 [04:50:12 CEST] <furq> well it seems like that works [04:50:37 CEST] <furq> making a note of this [04:51:11 CEST] <furq> i found a script that kills shellcheck but i don't think it's the same one [04:51:39 CEST] <furq> https://clbin.com/1cguG [04:51:40 CEST] <furq> rip [04:53:49 CEST] <qacky> o_O how is that valid syntax at all or is shellcheck mangling the error too [04:53:58 CEST] <furq> why would that not be valid syntax [04:54:28 CEST] <qacky> redirecting stdin inside an if/test? [04:54:39 CEST] <qacky> s/stdin/stderr [04:54:44 CEST] <Hello71> shellcheck doesn't use the shell parser, it's a custom one. otherwise you would just get "premature end of file, expected '" and it wouldn't help [04:54:57 CEST] <furq> [ is a function [04:55:13 CEST] <Hello71> no, [ is a builtin [04:55:27 CEST] <furq> builtins are functions [04:55:36 CEST] <qacky> both though it does exist as a bin on some distros [04:55:40 CEST] <qacky> weird I know [04:55:45 CEST] <Hello71> no. you can export builtins, but not functions. you can unset functions, but not builtins [04:56:01 CEST] <qacky> you can export functions [04:56:07 CEST] <Hello71> um [04:56:09 CEST] <Hello71> other way round [04:56:21 CEST] <furq> either way it's the same as doing `test "$1" -ge 0 2>/dev/null` [04:56:21 CEST] <Hello71> you cannot export a builtin [04:56:29 CEST] <furq> what would you be exporting the builtin to [04:56:30 CEST] <furq> it's built in [04:56:33 CEST] <qacky> ^ [04:56:54 CEST] <Hello71> [ is a "command", or a "utility". it's not a function, except in the most useless sense [04:56:59 CEST] <furq> i guess command would be more correct than function [04:57:02 CEST] <furq> ...yeah that [04:57:21 CEST] <Hello71> tab completion is arguably a function, if you define function to mean feature, but, like, that's not a useful definition [04:57:33 CEST] <furq> i mean something you can call like a function [04:57:37 CEST] <furq> which to me is the most useful sense [04:57:53 CEST] <qacky> still the "[ "$1" -ge 0 2>/dev/null ] " is just weird [04:58:08 CEST] <furq> well the point of that test is to see if the argument is a number [04:58:20 CEST] <furq> so i want to silence the error it prints if it's not [04:58:31 CEST] <furq> (an unsigned number, obviously) [04:58:34 CEST] <qacky> [ x"$foo" == x ] && echo yes [04:59:32 CEST] <qacky> er.. no. ignore that lul [04:59:43 CEST] <furq> ok good i was really staring at that one [05:02:14 CEST] <furq> anyway [05:02:16 CEST] <furq> KodiakIT[m]: https://clbin.com/LpZ32 [05:02:29 CEST] <qacky> t=0; [[ $t == [0-9] ]] && echo yes etc. [05:02:41 CEST] <furq> what if the number is 10 [05:02:56 CEST] <qacky> still in all the years I've used bash I've never seen stderr redirected like that so I stand by it being WEIRD! :) all good though [05:03:20 CEST] <furq> well it's weird enough shellcheck chokes on it [05:03:23 CEST] <furq> so i can't really deny that [05:03:26 CEST] <qacky> furq: you'd need to fix the regex [05:05:21 CEST] <furq> is that a bash thing [05:05:48 CEST] <furq> i normally try to write /bin/sh compatible stuff but i didn't want the poor guy fork bombing himself [05:06:08 CEST] <another> $ type -a [ [05:06:08 CEST] <another> [ is a shell builtin [05:06:09 CEST] <another> [ is /usr/bin/[ [05:06:34 CEST] <furq> i think that was the only part we all agreed on [05:07:38 CEST] <Hello71> if you insist on redirecting [, you should at least put it after the ] [05:07:49 CEST] <Hello71> who does printf fmt >&2 args [05:08:26 CEST] <furq> it would look way weirder after the ] [05:08:44 CEST] <furq> also this script is so old that the variable names are in all caps [05:08:50 CEST] <furq> so there's way more pressing issues to deal with [05:10:15 CEST] <another> jobs=$(grep -c ^processor /proc/cpuinfo) [05:10:25 CEST] <another> jobs="$(nproc)" [05:11:02 CEST] <qacky> please no [05:11:22 CEST] <another> no? [05:11:28 CEST] <furq> nproc is a linux thing [05:11:29 CEST] <qacky> Just because you have that number of cpus doesn't mean you should use them all at once [05:12:42 CEST] <another> fair points [05:21:49 CEST] <Hello71> no, nproc is part of coreutils. pretty sure you can get nproc on mac or whatever if you install coreutils [05:28:28 CEST] <qacky> kinda misses the point though, there's nothing saying those processors are _useable_. The could be offline for example or the host runs out of some other resource like memory, IO, etc. [05:29:08 CEST] <qacky> Drives me nuts when peopel do "make -j" because herpderp it's quicker. Completely missing even -n *shrug* [05:32:25 CEST] <Hello71> "Print the number of processing units available to the current process, which may be less than the number of online processors" [05:34:58 CEST] <qacky> The offline case was just an example. What if you start hammering the processor where X or something else you care about runs? [05:55:07 CEST] <furq> Hello71: sure you can, but it'll be called gnproc [05:56:39 CEST] <furq> obviously procfs isn't portable either though so shrug [06:30:47 CEST] <Diag> yo furq, you messed with av1 much? [06:36:17 CEST] <furq> not really [06:36:23 CEST] <furq> it's too slow to be usable [06:36:28 CEST] <Diag> Thats what im seeing [06:36:40 CEST] <Diag> my cpu usage is just all over the place and i was wondering if thats just the way the codec works [06:37:08 CEST] <Diag> its like one thread queues up a bunch of nonsense, it gets punched through all the cores, then it goes back to one thread [06:40:18 CEST] <furq> vpx has famously bad multithreading and aom is still really badly optimised [06:40:29 CEST] <furq> so it's not surprising [06:40:36 CEST] <Diag> ah ok, i kinda figured as its still relatively new [06:40:50 CEST] <Diag> heh, i guess thats the tradeoff for some impressive results :shrug: [06:41:01 CEST] <furq> i've never seen more than 25% cpu usage from aom on a 6c/12t cpu [06:41:23 CEST] <furq> regardless of threads/tiles/row-mt/cpu-used settings [06:41:24 CEST] <Diag> furq: mine does this http://tyronesbeefarm.com/images/2019ba039d4e-9289-4f2e-8cd8-093eb8cfd6da.p… [06:41:36 CEST] <Diag> i thought i was doing something wrong [06:41:55 CEST] <furq> if you are then i'm doing it wrong as well [06:42:04 CEST] <Diag> hot damn [06:42:14 CEST] <furq> i've never been able to get good multithreading out of vpx but some people claim it works fine [06:42:26 CEST] <Diag> weird? [07:04:38 CEST] <VikeStep> Hi, on a H264 MP4 video, is it expected that you may get an EAGAIN when calling avcodec_receive_frame on an I-frame? [07:18:06 CEST] <Diag> ok, sans encoding speed, im like, really impressed with av1 [07:18:40 CEST] <while> hi, I have a bash script that fabricates an http response for an http request expecting an mp4 file, I have a udp stream that the media is coming from, I am trying to without modifying the codecs, creating an on-the-fly mp4 file, which is being fed to an http client, however, in firefox there is no sound, only video [07:19:13 CEST] <while> would this most likely be a codec issue, and if so, what codecs must the udp stream be using? [07:23:28 CEST] <while> here are my scripts: https://wieldfield.com/ffmpegOpenSourceMediaStream/ [07:38:39 CEST] <JEEB> VikeStep: due to b-frame delay etc yes. also frame threads add delay [07:41:01 CEST] <VikeStep> I should have also mentioned that this is on parsing the very first frame of the video. What are frame threads? [07:41:29 CEST] <VikeStep> can't seem to find anything on google [07:41:34 CEST] <JEEB> the default threading method in lavc [07:42:14 CEST] <JEEB> so that you have one frame handled by each thread. that brings delay (but us fps-wise faster) [07:42:26 CEST] <JEEB> compared to slice threading [07:43:08 CEST] <JEEB> (where each thread works on a slice within a single picture - if the video is coded with multiple slices [07:48:45 CEST] <VikeStep> ah, I was thinking EAGAIN meant that it needed to get the next frame to get enough data to render the current frame. Since I-frames are fully self contained (correct me if wrong), why is it that having it on separate threads means that it still needs more data? [07:48:51 CEST] <VikeStep> or does EAGAIN have a different meaning to that? [07:50:09 CEST] <JEEB> frame threads by their mechanism add latency in the framewoek [07:50:46 CEST] <JEEB> if you need minimal latency (on the expense of speed) use slice threading [07:51:30 CEST] <VikeStep> I see, I guess that makes sense [07:51:53 CEST] <JEEB> also even if you start with an i frame, i think if the stream can have b-frames it might need to delay the stream to begin with to enable reordering proper [07:52:15 CEST] <JEEB> so those two add latency (more input is required before you receive a frame) [07:52:43 CEST] <VikeStep> and a follow on question: When I call av_read_frame, the AVPacket DTS on the first frame is -3000, but the corresponding AVFrame has a DTS of 0. Does the parsing of the frame change the value of the PTS and DTS somewhere? [07:53:31 CEST] <JEEB> yes. usually that negative stuff is to enable reordering without dts being larger than pts [07:53:48 CEST] <JEEB> and the decoder handles that for you [07:54:51 CEST] <VikeStep> sweet, I thought that may be the case [08:03:39 CEST] <while> my http livestream server I'm making, doesn't seem to work specifically in firefox: https://wieldfield.com/ffmpegOpenSourceMediaStream/ [08:03:48 CEST] <while> there is video, but no audio [08:17:19 CEST] <lain98> i have divx file that im drying to demux. libav reports the codec type as AV_CODEC_ID_MPEG4. but i imagine there are other codecs supported by mpeg4 standard. how can i know that the file is using divx codec and not some other codec. [08:18:04 CEST] <lain98> wikipedia says that divx uses mpeg4 part 2. so even if i can know thats its mpeg4 part 2, it solves my problem. [08:18:33 CEST] <ritsuka> AV_CODEC_ID_MPEG4 is mpeg4 part 2 [08:18:45 CEST] <lain98> always ? [08:19:41 CEST] <ritsuka> I'm fairly sure [08:19:58 CEST] <lain98> okay, the problem i was really trying to solve is that divx uses packed b-frames [08:20:21 CEST] <lain98> and i didnt want to waste cycles with using the mpeg4_unpack_bframes filter [08:20:35 CEST] <lain98> for every other file out there [08:20:44 CEST] <lain98> so i guess this will work [08:22:09 CEST] <lain98> i could conserve a few more cycles if i specifically know that its divx because in part 2 there are other codecs [08:27:13 CEST] <JEEB> lain98: basically when AV_CODEC_ID_MPEG4 was set it was the only video format for MPEG-4 :P [08:27:18 CEST] <JEEB> welcome to historical stuff [08:28:37 CEST] <lain98> :) [08:29:58 CEST] <lain98> i think i even found a small issue with the mpeg4_unpack_bframes filter. it sort of assumes youre decoding everything from start to end. if you seek in between, it sort of messes up. [08:30:48 CEST] <JEEB> I actually wonder how many things utilize the bsf [08:30:56 CEST] <lain98> so before seeking freed the old AVBSFContext and used a new one and it worked fine. [08:31:29 CEST] <lain98> JEEB: i think that particular filter was manily so that people would transcode over to other codecs. [08:32:25 CEST] <JEEB> it doesn't seem to be auto-inserted and for example a player I'm poking at doesn't insert it [08:32:52 CEST] <JEEB> so not sure how much it's useful for playback/decoding based scenarios (most likely the decoder takes care of some crappiness?) [08:33:20 CEST] <JEEB> it might for separation of the packets so that they properly re-mux? [08:33:35 CEST] <lain98> yes [08:34:06 CEST] <lain98> its mainly intended if you want to remux to a new container [08:35:05 CEST] <lain98> it needs to see all frames in order so that it can replace n-vop with the corresponding packed b-vop [08:35:37 CEST] <lain98> or maybe i'm completely wrong because i'm new to video but thats what i understood from reading about it [08:35:46 CEST] <mr_lou> Hello. I'm using this command to turn portrait-mode video into landscape. It works fine. Scales and crops. But it always crops the center. How do I tell i to crop at a certain y position? Putting y=whatever produces the same wrong result. [08:35:47 CEST] <mr_lou> ffmpeg -i inputfile.mp4 -filter_complex '[0:v]scale=ih*16/9:-1,boxblur=luma_radius=min(h\,w)/20:luma_power=1:chroma_radius=min(cw\,ch)/20:chroma_power=1[bg];[bg][0:v]overlay=(W-w)/2:(H-h)/2,crop=h=iw*9/16' outputfile.mp4 [08:38:08 CEST] <lain98> mr_lou: crop=h:w:x:y [08:38:20 CEST] <lain98> x and y are top left corner coordinates [08:38:47 CEST] <JEEB> lain98: that more or less matches my understanding of that filter due to how b-frames were put into AVI as a hack :) [08:39:05 CEST] <lain98> :) [08:40:39 CEST] <mr_lou> lain98, Yes I know. But if I put crop=h=iw*9/16:y=<whatever>, it moves the picture down - always to the same place, no matter what value I use. 20 or -20 or 100. Always the same result. [08:40:47 CEST] <lain98> JEEB: so any avi container video can have packed b frames issue ? not only divx ? [08:42:34 CEST] <JEEB> I'd say that would be a correct assumption although I have no idea how other b-frame capable formats such as H.264 or HEVC were put into AVI :P (I have one example of H.264 in AVI at home, and I've only checked that its playback works and not looked any further) [08:57:36 CEST] <lain98> JEEB: okay now im really confused. im not sure when to call the unpack filter. is it a problem specific to avi container or mpeg4 codec or only when the two collide ? [08:59:22 CEST] <JEEB> the bit stream filter is made for MPEG-4 Part 2 [09:32:19 CEST] <lain98> how can i know what ffmpeg version added a particular api. specifically im looking for av_bsf_flush [09:33:22 CEST] <JEEB> doc/APIchanges [09:33:33 CEST] <lain98> oh yeah found it [09:33:36 CEST] <lain98> thank [09:33:38 CEST] <lain98> s [09:41:00 CEST] <fling> How to workaround single thread issue in ffmpeg? [09:41:15 CEST] <fling> It prevents me from using three live sources/outputs at the same time [09:41:26 CEST] <fling> Producing artifacts in video stream [09:50:26 CEST] <Diag> fling: what are you doing that is single threaded [09:51:39 CEST] <fling> Diag: for example copying two video streams into a file works, but copying two video streams and one audio stream does not. [09:52:39 CEST] <Diag> huh [09:52:40 CEST] <fling> Or copying one video steam to a live source works until I mux it with an audio stream [09:53:47 CEST] <fling> I tried to workaround it few years ago with different combinations of pipes and other tricks [09:53:55 CEST] <fling> Looks like it is still the issue nowadays [10:07:25 CEST] <lofo> Hey, i'm wondering if the absence of 'const' on a pointer in a function prototype should be systematically considered as 'the data to which the pointer points to might change as a result to this function call' [10:08:16 CEST] <lofo> or is there another reason i'm not aware of that libav uses const more loosely [10:09:53 CEST] <lofo> sorry, my quoted sentence wasn't right... more like 'the adresse the pointer points to might change as a result to this function call' [10:33:02 CEST] <fling> JEEB: Hello. [11:27:14 CEST] <Diag> mfw handbrake doesnt use gpu decode [11:27:17 CEST] <Diag> is u is retarged [11:59:20 CEST] <DHE> lofo: you have a specific example? [12:10:10 CEST] <squ> lofo: it means function may change contents [12:10:46 CEST] <squ> because otherwise const prohibits change [12:12:10 CEST] <lofo> I get it on a semantical standpoint. What i'm wondering is if its used consciously throughout ffmpeg. [12:12:15 CEST] <lain98> how do i what what container format a file was based on a AVFormatContext that i hold [12:12:46 CEST] <JEEB> lain98: https://ffmpeg.org/doxygen/trunk/structAVFormatContext.html [12:12:52 CEST] <squ> lofo: no idea [12:13:04 CEST] <JEEB> that then references https://ffmpeg.org/doxygen/trunk/structAVInputFormat.html [12:13:19 CEST] <lofo> Or is it possible that ffmpeg's functions asks for non-const parameter while NEVER modifying it [12:13:57 CEST] <JEEB> I'm pretty sure it depends on if the person writing the function remembered to consider whether the thing should be const or not [12:14:16 CEST] <lain98> JEEB: i opened an avi file but iformat.name was "mov,mp4,m4a,3gp,3g2,mj2" [12:14:50 CEST] <JEEB> then it either was mp4-like in reality, or you're poking the wrong context? [12:14:51 CEST] <lofo> so the answer i'm looking for is "it depends" ? [12:15:06 CEST] <lain98> AVInputFormat doesnt have an enum [12:15:19 CEST] <JEEB> no, it's just a name or pointer [12:15:30 CEST] <JEEB> and since you don't hafve the internal pointers I think the name is your best bet :P [12:16:09 CEST] <lain98> JEEB: would you say its a good idea to just rely on the extension in the filename ? [12:16:16 CEST] <JEEB> no [12:16:27 CEST] <JEEB> because someone can name a file mp4 or ts [12:16:29 CEST] <lain98> :( [12:16:32 CEST] <JEEB> but the contents might be vice versa [12:16:51 CEST] <JEEB> I think that's one of the primary reasons why we have probing in lavf :P [12:20:57 CEST] <rocktop> how to use ffmpeg to extract part of video ? [12:21:31 CEST] <rocktop> I use MP4box but it is not starting to extarct from specific time always add extra sconds [12:23:10 CEST] <Rhada> Hello ! i'm trying to use the static build on docker to build a HLS to RTMP container. ffmpeg can't pull my source stream. It fails with "Failed to resolve hostname". I can't achieve to sort out this issue so i'm here for help :D [12:33:53 CEST] <lain98> Rhada: wireshark ? [12:34:03 CEST] <lain98> maybe it really cant resolve it [12:36:31 CEST] <Rhada> i just find a post on internet telling the enbedded glibc result in loosing dns resolution ... :( [12:45:43 CEST] <JEEB> sounds like a bad docker image :P [12:49:26 CEST] <rocktop> anyidea? [12:50:22 CEST] <JEEB> rocktop: you can only cut on random access points without re-encoding [12:50:34 CEST] <JEEB> and ffmpeg.c (the command line app) does not implement partial re-encoding [12:51:05 CEST] <JEEB> thus if your cut point is not at a random access point, you will indeed get more stuff. ffmpeg.c will attempt to write an edit list to skip that stuff, but whtether that actually gets skipped depends on your player's implementation [12:51:25 CEST] <JEEB> for example Firefox doesn't hide things. [12:51:29 CEST] <rocktop> JEEB: I only need to split video from a very specific sec to another specific sec [12:51:46 CEST] <rocktop> with or without encoding [12:51:57 CEST] <JEEB> yea but do you have random access points there? [12:52:05 CEST] <JEEB> if you don't then you need to re-encode (at least partially) [12:52:18 CEST] <JEEB> and as I said, that is a more complex job than what ffmpeg.c does at the moment [12:52:39 CEST] <JEEB> the FFmpeg APIs would let you do it and pretty sure there was an app by someone made to do it, but I don't have an elephant's memory [12:52:56 CEST] <JEEB> mp4box of course can't do it because it's not a decoder/encoder. only does container level stuff :P [12:53:26 CEST] <rocktop> JEEB: so what is the solution [13:52:22 CEST] <OnkelTem> Hi all [13:52:43 CEST] <OnkelTem> Folks, I cannot find a page with a list of supported bitrates for mp2 audio [13:53:09 CEST] <OnkelTem> Is there a way to query this list from the ffmpeg command line program? [14:12:14 CEST] <DHE> OnkelTem: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mpegaudiodata.c the raw data is here, but it's hard to read [14:13:57 CEST] <DHE> for mp2 audio you most likely want the second row of the main avpriv_mpa_bitrate_tab table there [14:15:56 CEST] <OnkelTem> DHE: thank you very much! [14:16:05 CEST] <OnkelTem> exactly what I was looking for [14:36:00 CEST] <Rhada> JEEB: i'm using alpine:latest as base image, it's a known problem that nscd is missing and atm there is no replacement (afaik) ... [14:41:23 CEST] <cousin_luigi> Greetings. [14:41:37 CEST] <cousin_luigi> "[ffmpeg/video] vp9: No support for codec vp9 profile 0." <- what do I need to support this? [14:49:14 CEST] <DHE> use software decoding instead [15:11:06 CEST] <cousin_luigi> DHE: I'm not sure how. [15:12:23 CEST] <JEEB> don't use vaapi? [15:13:20 CEST] <JEEB> --hwdec=no I think? [15:20:23 CEST] <cousin_luigi> JEEB: How is it possible that I have to do it by hand? [15:21:07 CEST] <cousin_luigi> I mean, can't a profile be set somewhere? [15:21:10 CEST] <kepstin> normally you don't, ffmpeg doesn't try to use hardware decoding unless you ask it to [15:21:11 CEST] <pink_mist> because you added hwdec=yes in your config, probably? [15:21:52 CEST] <kepstin> with mpv you should use hwdec=auto [15:22:20 CEST] <pink_mist> err, actually, yes is the same as auto, I just noticed in the manpage [15:22:32 CEST] <pink_mist> so presumably he set hwdec=vaapi or something [15:23:03 CEST] <kepstin> note that even with hwdec=auto, mpv *tries* hardware decoding, prints a message like that, then falls back to software. [15:23:28 CEST] <kepstin> so the real fix to make the message go away is to get newer hardware ;) [15:24:01 CEST] <pink_mist> :P [15:29:54 CEST] <cousin_luigi> k, bbl! [16:42:26 CEST] <aep> is it possible to send x264 over udp directly? there doesnt seem to be a way to set a max size for avcodec_receive_packet to make it fit into a udp packet [16:42:47 CEST] <aep> it kinda works if i drop the ovesized packets [16:50:22 CEST] <JEEB> if you are using libx264 to encode you can define specific max sizes etc [16:50:48 CEST] <JEEB> those are not FFmpeg options but specifically passing libx264 key=value pairs through -x264-params f.ex. [16:50:54 CEST] <JEEB> see x264 documentation on the list of options [17:18:03 CEST] <aep> JEEB: thanks, but whats the api for that? not av_opt_set [17:18:50 CEST] <DHE> av_dict_set(&dictptr, "x264-params", "key=value:something=this:other=that", 0); [17:19:11 CEST] <DHE> and then avcodec_open2() takes the dictionary [17:21:57 CEST] <aep> got it, thanks! [17:28:33 CEST] <bencoh> 41 [17:31:57 CEST] <lofo> i'm having a hard time understanding this error message "Impossible to convert between the formats supported by the filter 'in' and the filter 'auto_scaler_0'" [17:43:12 CEST] <aep> hmm i guess that won't work. "VBV buffer size cannot be smaller than one frame, using 4 kbit" [17:43:35 CEST] <aep> probably a full frame is still bigger than 1kb [17:44:00 CEST] <aep> this is when setting AVCodecContext rc_buffer_size [17:47:55 CEST] <lofo> everything seems to occur inside static int query_formats(AVFilterGraph *graph, AVClass *log_ctx); but i ave yet to understand wat fails [17:48:26 CEST] <lofo> ('h' key on my keyboard is failing, sorry for that) [17:49:37 CEST] <bencoh> aep: 1. why would you use avcodec if you intend to direct x264 output to udp? [17:49:48 CEST] <bencoh> 1. you might want to have a look at nalu_process [17:50:02 CEST] <bencoh> (although I've never tried it myself, I suspect it may help you there) [17:52:09 CEST] <bencoh> oh and, assuming you're ready to use rtp instead of plain old udp (I highly doubt h264 over udp is standard in any way): https://tools.ietf.org/html/rfc6184 [17:58:56 CEST] <aep> bencoh: nah, this is a hightly custom setup, no need for standards :D [17:59:03 CEST] <bencoh> :) [17:59:58 CEST] <aep> in fact, i think rtp would attempt time synchronization, which i need to avoid [18:00:04 CEST] <bencoh> reading it still might help you understanding what is actually needed to send h264 in a semi-proper way [18:00:13 CEST] <bencoh> uh? rtp per-se is just a header [18:00:20 CEST] <aep> ah [18:00:37 CEST] <aep> not sure whats to learn from that then, but i'll have a look [18:01:01 CEST] <bencoh> (of course, that'd depend on what your receiver would do with the data, but you could just choose to ignore that part) [18:02:03 CEST] <aep> currently its just mpv. its fine with raw x264 [18:02:03 CEST] <bencoh> oh, and ... assuming your setup is really 100% setup and you don't care for standards *at all* ... why don't you just chunk it as it comes to fit udp packet size? [18:02:16 CEST] <bencoh> s/100% setup/100% custom/ [18:02:37 CEST] <aep> right. i guess i could do that. i'm just wondering if x264 is more efficient than me [18:02:52 CEST] <bencoh> just ... fill a fifo and push that to network [18:03:47 CEST] <aep> 264 already has ridiculously tiny packets, just the full frame very now and then is oversized [18:03:48 CEST] <bencoh> using nalu_process may be more efficient latency-wise I guess (although from what I'm reading, you may have ordering issue at some point) [18:04:02 CEST] <aep> misordering is fine [18:04:18 CEST] <bencoh> in which way is it "fine"? [18:04:19 CEST] <aep> i need to optimize for latency. quality is irrelevant [18:04:22 CEST] <bencoh> ah [18:05:24 CEST] <bencoh> sounds definitely odd to me (ordering issues are not really tolerable, not just "bad quality stream"), but ... I see what you mean by "optimize for latency" [18:05:40 CEST] <bencoh> and I guess you really should have a look at nalu_process (x264.h) then [18:05:52 CEST] <aep> well, to be more detailed, x64 already has an order flag. i'm just going to drop late frames [18:05:56 CEST] <aep> yeah [18:06:13 CEST] <aep> currently using libav because i might need to migrate to a hardware encoder [18:07:22 CEST] <bencoh> that was quite a long time ago, but I did achieve "low"-latency (down to something like 2 frames total delay) using x264/mpeg-ts and an SDI input [18:07:38 CEST] <aep> hmm mpeg-ts is a good idea [18:07:46 CEST] <aep> i didnt know it can carry x64 [18:08:33 CEST] <bencoh> well, h.264 is probably the most used video format in modern tv broadcast I'd say ;) [18:08:49 CEST] <bencoh> (and mpeg-ts is the de facto standard container for that) [18:09:43 CEST] <bencoh> oh, and ... while mpeg-ts might be a good idea in your case, I wouldn't say the muxer in ffmpeg is fit for it [18:10:02 CEST] <aep> is it bad? [18:12:31 CEST] <DHE> functionally it's fine, but I don't think it's optimized for low latency [18:13:17 CEST] <bencoh> and I'm not certain about compliance (vbv and stuff) either, but I guess you don't really care about that :) [18:14:48 CEST] <aep> aye [18:15:08 CEST] <aep> any suggestions for some code that's a better fit? or i guess i can hack my own [18:16:12 CEST] <aep> i'm not even sure if it does much [18:16:27 CEST] <aep> just seems to be fragmenting the frame plus a whole bunch of multiplexing stuff [18:16:46 CEST] <bencoh> the question is more "why bother?" in your case [18:17:10 CEST] <bencoh> unless you need to transport more than just video, and keep elementary streams in sync [18:17:10 CEST] <aep> yeah [18:17:32 CEST] <bencoh> (oh and, I used upipe-ts back then) [18:17:40 CEST] <bencoh> (but I was also one of the main devs of upipe) [18:17:45 CEST] <aep> i'm just not very experienced in video, so i'm not sure if my dumb approach of just fragmenting the frame is any good [18:18:06 CEST] <aep> oh nice [18:19:03 CEST] <lofo> I'm completely lost into ffmpeg's source code... I don't even know what state i should dump to find whats causing the issue... [18:21:04 CEST] <aep> bencoh: well, it worked. i got below 50ms latency over LTE :D [18:22:39 CEST] <aep> lofo: maybe if you posted your full filter call, someone could check it for obvious mistakes? [18:23:15 CEST] <lofo> i'm trying to run a copy-paste of this https://ffmpeg.org/doxygen/trunk/doc_2examples_2transcoding_8c-example.html [18:23:16 CEST] <bencoh> aep: sounds hacky as well, but cool :) [18:23:43 CEST] <aep> bencoh:yeah well, happy to take any suggestions how to do it correctly [18:24:20 CEST] <bencoh> there is no "correct" way in your case since you're not trying to be standard anyway [18:24:29 CEST] <aep> aye [18:24:55 CEST] <aep> lofo:does that example not work? [18:24:56 CEST] <bencoh> and assuming you really don't care about lost frames and such, then you don't even need a retransmission/correction mechanism, so it's cool :) [18:25:18 CEST] <aep> exactly, i need to NOT retransmit, so all the streaming protocols would probably get in my way [18:25:51 CEST] <aep> h264 seems to deal just fine with packet loss. just a bunch of artifacts [18:27:03 CEST] <lofo> nevermind, it is this one that i copy-pasted. seemingly the same https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/transcoding.c [18:27:23 CEST] <bencoh> avcodec has error concealment options iirc [18:27:39 CEST] <bencoh> you may want to play with those [18:27:55 CEST] <lofo> i first got a 'Necessary encoder not found' tied to the MP3 codec. so i've commented out the branches that deals with AUDIO [18:28:14 CEST] <bencoh> (iirc it can drop damaged frames to avoid showing artifacts) [18:28:44 CEST] <lofo> then i have the error i was talking about with avfilter_graph_config [18:29:05 CEST] <lofo> google gave me fruitless answer tied to hwaccel [18:29:21 CEST] <aep> bencoh: nice, thanks [18:30:06 CEST] <aep> lofo: errr, if you dont have those codecs in the example, maybe start there? [18:30:39 CEST] <lofo> i'm running this piece of code on iPhone [18:30:43 CEST] <aep> oooh [18:31:33 CEST] <aep> well, i'd rather find a video file that works on there first [18:31:42 CEST] <lofo> as far as i know, andling codec is out of my reach [18:41:17 CEST] <nikio_> is there some way for ffmpeg to generate, or to use ffmpeg output to generate data for a frequency histogram? [18:42:17 CEST] <nikio_> i mean an amplitude per frequency bin kind of histogram [18:42:22 CEST] <nikio_> to visualize music [18:44:48 CEST] <nikio_> maybe i should just use the raw pcm data [18:44:57 CEST] <nikio_> and generate everything myself [18:44:59 CEST] <nikio_> it shouldnt be that hard [18:46:35 CEST] <aep> pretty sure it has fft yes [18:47:01 CEST] <aep> somewhere in the examples. [18:47:09 CEST] <nikio_> you mean i should just use the fft to create the frequency bins? [18:47:51 CEST] <nikio_> *use ffmpeg's fft function [18:48:16 CEST] <aep> yes [18:48:19 CEST] <aep> https://trac.ffmpeg.org/wiki/FancyFilteringExamples [18:48:34 CEST] <aep> i mean not "shou;d" [18:48:40 CEST] <aep> just could. fft is pretty trivial [18:49:25 CEST] <nikio_> well its nicer not to repeat functionality if it isnt needed : p [18:49:40 CEST] <nikio_> been googling a bit, and im trying to find how to do it [18:50:38 CEST] <nikio_> i do want the data though, not a picture aep [18:51:06 CEST] <nikio_> just arrays of frequency bins [18:51:28 CEST] <nikio_> i dont think ffmpeg has something like that [18:52:34 CEST] <aep> oh you want to dump it from the ffmpeg binary (not using the library) but not as picture ? [18:52:43 CEST] <aep> not sure if thats's a thing. [18:54:39 CEST] <nikio_> yup [18:54:57 CEST] <nikio_> so i can visualize it myself life [18:55:03 CEST] <nikio_> im coding a music visualizer [18:55:19 CEST] <nikio_> it will receive the frequency bins over a websocket [19:01:31 CEST] <nikio_> found this: https://stackoverflow.com/a/41663511 [19:01:36 CEST] <nikio_> i havent dont fft myself [19:01:39 CEST] <nikio_> *done [19:01:48 CEST] <nikio_> so its a learnin experience [19:02:02 CEST] <nikio_> i like to learn audio theory [20:52:15 CEST] <lyncher> hi. is it possible to change AAC format from LATM to ADTS without transcode? [20:56:35 CEST] <another> afaik no [20:59:06 CEST] <furq> lyncher: maybe ffmpeg -i foo.aac -f adts bar.aac [20:59:13 CEST] <furq> and -c copy obviously [21:06:25 CEST] <lyncher> it doesn't work [21:06:30 CEST] <lyncher> my source: Stream #0:0[0x100](por): Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp [21:06:39 CEST] <JEEB> yes the bit stream is quite different [21:06:41 CEST] <lyncher> with that command I get: [21:06:42 CEST] <lyncher> [adts @ 000001a1d3535540] Only AAC streams can be muxed by the ADTS muxer [21:06:44 CEST] <JEEB> in theory you could have a bit stream filter [21:06:57 CEST] <JEEB> yea, they have different codec ids due to being so different :s [21:07:11 CEST] <JEEB> even though underneath they're both AAC [21:09:28 CEST] <lyncher> so it was never done? only a transcode is able to convert this? [21:11:58 CEST] <cehoyos> lyncher: It is technically possible (and not particularly difficult afair), when the latm decoder was implemented, this path was not taken, therefore the bitstream filter was never necessary. [21:14:16 CEST] <another> i thought about implementing this as a bsf sometime [21:16:20 CEST] <lyncher> another: that will be a very helpful feature [21:16:44 CEST] <durandal_1707> bsf of what? [21:17:28 CEST] <lyncher> something like: aac_latamtoadts_bsf [21:17:33 CEST] <another> aac latm to adts [21:18:44 CEST] <durandal_1707> it doesnt already exist? [21:18:59 CEST] <durandal_1707> whats usage? [21:18:59 CEST] <lyncher> aac_adtstoasc is available [21:19:11 CEST] <lyncher> but it doesn't do what is needed [21:19:29 CEST] <lyncher> DVB-T/DVB-C AAC streams are LATM [21:19:51 CEST] <lyncher> Chrome/Firefox don't support LATM AAC streams [22:34:03 CEST] <ossifrage> Anyone know of a tool that can losslessly (without decoding) top/bottom concatenate jpeg images? Assuming the same quant tables for all images? [22:34:48 CEST] <ossifrage> So say 16 640x360 images would become one 640x5760 image? [22:35:51 CEST] <ossifrage> I don't think doing it would be that bad (maybe using restart markers would make it easier) [23:23:48 CEST] <dastan> hello people [23:24:02 CEST] <dastan> can someone help me whith ffmpeg logs [23:24:04 CEST] <dastan> ??? [23:25:23 CEST] <another> depends on whether you post them [23:56:33 CEST] <dastan> jaja sory [23:57:00 CEST] <dastan> i am forwarding the satndard output of one ffmpeg command [23:57:08 CEST] <dastan> i am saving a video in hls [23:57:29 CEST] <dastan> and i want to show on the screen only the ffmpeg speed and the file its openning [23:58:12 CEST] <dastan> y have the commands separately, one to get the speed information, and other to get the name of the file [23:58:31 CEST] <dastan> but i need all in the same command or in a fcuntion [00:00:00 CEST] --- Thu Aug 29 2019

1 0

ffmpeg-devel.log.20190827
by burek 28 Aug '19

28 Aug '19

[00:00:52 CEST] <lotharkript> are you saying that UB and timeout should not be fixed? or just timeout? [00:00:55 CEST] <nevcairiel> if you feel like you need to count, you are missing the point anyway [00:01:38 CEST] <baptiste> I think you are being stubborn as well [00:02:12 CEST] <baptiste> maybe you should go and fix some fuzzer detected issues [00:02:42 CEST] <lotharkript> For timeout, i agreed that the fuzzer does not make the difference between an infinite loop (DoS) and long time to decode.. So what do you propose? [00:02:57 CEST] <lotharkript> Should we ignore the long time to decode and fix only infinite loop? [00:03:31 CEST] <BtbN> Someone should look at the issue and judge them. [00:03:41 CEST] <BtbN> And not blindly fix everything the fuzzer spits out [00:04:19 CEST] <lotharkript> ok.. So, if the bug is about take too long to decode, should we leave it as Working as Intended? [00:04:47 CEST] <lotharkript> leave it open? [00:04:48 CEST] <nevcairiel> It entirely depends, is the point. [00:05:12 CEST] <BtbN> Obviously a way to make a decoder jump into an infinite loop needs fixing. [00:05:27 CEST] <BtbN> Something that makes it take 2 or 10 seconds longer... very much depends [00:05:35 CEST] <lotharkript> ok.. I agree.. Then when the patch is summited for review, should we talk about the "Take too long to decode" and come up with some solution? [00:05:56 CEST] <lotharkript> or should we ignore a 10s time out for decoding a video frame? [00:06:01 CEST] <nevcairiel> The problem is that "security" is used as an argument to white-wash any patch [00:06:08 CEST] <nevcairiel> because who dare argue against security fixes [00:06:59 CEST] <lotharkript> i understand that.. Right now, I'm trying to find a way about the time out. [00:07:05 CEST] <BtbN> First step would be to move fuzzing off of the very secluded security ml. To a dedicated fuzzing ml, and give every known dev/maint access. [00:07:12 CEST] <lotharkript> What is the best way to deal with timeout found by fuzzer? [00:07:38 CEST] <BtbN> There are a whole bunch of timeouts you can probably just safely ignore [00:08:58 CEST] <nicolas17> BtbN: would it be possible to make fuzz-found timeouts public while fuzz-found crashes stay private? [00:09:09 CEST] <BtbN> Don't ask me [00:09:18 CEST] <BtbN> imo it should just all stay private, but not THAT private as it is right now [00:09:25 CEST] <BtbN> Just treat it the same like the coverity results [00:09:59 CEST] <lotharkript> nicolas17: yes it is possible.. Bu t i was asked to wait before doing the pull request [00:20:38 CEST] <jamrial> the cfr -> vfr qtrle change was indeed to "fix" a fuzzer reported timeout [00:20:59 CEST] <jamrial> something that should no longer be reproducible ever since i made the fuzzer use ref counted buffers [00:21:08 CEST] <jamrial> and even more so is "avcodec/qtrle: call ff_reget_buffer() only when the picture data is going to change" is applied as well [00:21:21 CEST] <BtbN> a fuzzer patch that changes behaviour, even arguable off-spec, is a no-go [00:21:36 CEST] <nevcairiel> and now its being argued for as a generic performance improvement, just to justify it [00:21:38 CEST] <jamrial> so what people complain about is that the output of a decoder was changed to shut up a timeout report [00:22:03 CEST] <jamrial> BtbN: exactly [00:22:06 CEST] <BtbN> This feels the wrong way around to me. There should be arguments about including the patch. Not about reverting it again. [00:22:16 CEST] <BtbN> The revert is obvious, and then you can argue. [00:22:25 CEST] <BtbN> About the if and how to do it properly. [00:22:40 CEST] <nevcairiel> I have been arguing against the CFR changes for months, but in the beginning noone else cared, so it was me against "security" so it went in anyway [00:22:46 CEST] <nevcairiel> I forgot what codec that was even on [00:22:53 CEST] <nevcairiel> At least n ow more people care [00:28:00 CEST] <jamrial> i'm not happy that i had to go and take direct action (aka, write a patch to make the fuzzer use the proper and recommended api myself) to effectively call the wave of silly 2 second timeout reports into question [00:28:23 CEST] <jamrial> it wasn't me who realized the fuzzer wasn't using ref counted buffers. it wasn't me who complained about it for months [00:28:43 CEST] <BtbN> I didn't even realize the code that did that was part of ffmpeg itself [00:28:43 CEST] <jamrial> so why was i the one that wrote a trivial patch to deal with it instead of those who raised the issue? [00:54:21 CEST] <lotharkript> what if we can assign the timeout bug to the owner of the file? And let him decide what to do? [00:58:36 CEST] <lotharkript> It seems I can assign the bug to people. Will it be ok if i CC the maintener of the codec for timeout? at this point, the dev should have access to the reproduce data [00:59:55 CEST] <lotharkript> any one interested to see if this will work? [01:00:02 CEST] <jamrial> the maintainers list is not exactly up to date, or accurate anymore [01:00:23 CEST] <jamrial> you'll probably end up ccing someone that hasn't looked at ffmpeg codebase in years [01:00:31 CEST] <lotharkript> can we then update the list? [01:00:53 CEST] <lotharkript> for example, who is VC1? or MotionPixels? [01:00:59 CEST] <lotharkript> or TAK? [01:01:11 CEST] <lotharkript> pr ARBC? [01:01:19 CEST] <jamrial> tak is durandal_1707 [01:01:22 CEST] <nevcairiel> the majority of those probably don't have an active maintainer [01:01:58 CEST] <nevcairiel> codecs that barely need changes over years don't get adopted when their original authors leave [01:02:10 CEST] <lotharkript> Durandal_1707: do you want me to CC you on one of those time bug? So we can see if you can have access to it? [01:02:19 CEST] <lotharkript> should we then no fuzz them? [01:02:28 CEST] <lotharkript> and maybe fuzz only the one with maintener? [01:04:34 CEST] <nevcairiel> eh security issues can of course still happen in all parts of the code [01:04:34 CEST] <durandal_1707> for tak or arbc timeouts cc me [01:05:01 CEST] <lotharkript> ok.. Let;s try one.. [01:05:12 CEST] <jamrial> i think the above about ignoring timeouts below a given threshold sounds better than skipping stuff from files without maintainer [01:05:35 CEST] <jamrial> but no idea if that should be automated, or someone deciding if it's not worth looking at [01:05:51 CEST] <jamrial> two second timeouts sound silly either way [01:07:13 CEST] <lotharkript> The overall timeout for fuzzer is 25s.. [01:10:02 CEST] <cone-077> ffmpeg 03Aman Gupta 07master:0821bc4eee25: avcodec/vaapi_encode: respect -force_key_frames setting [09:28:26 CEST] <thardin> that doesn't seem like the proper reason to close a ticket [09:31:22 CEST] <Compnn> baptiste makes a rare appearance [09:32:53 CEST] <thardin> so I saw [09:33:15 CEST] <thardin> I had wanted to run that mxf d-10 thing past him [09:33:34 CEST] <thardin> hard to do while asleep [09:34:23 CEST] <durandal_1707> all tickets without samples should be closed asap [09:44:32 CEST] <thardin> why not just assign it to the reporter? [09:47:13 CEST] <thardin> it's marked as an important regression, seems strange to close it [11:02:22 CEST] <rcombs> anyone seen "error registering an input resource: unimplemented (22)" from nvenc? I'm getting it only when pairing nvenc with nvdec, with hwaccel_output_format=cuda [11:04:03 CEST] <rcombs> seems to happen regardless of any filters [11:04:29 CEST] <rcombs> oddly, it seems to happen on the _second_ frame, despite the params being basically identical [11:10:00 CEST] <BtbN> that sounds odd [11:10:05 CEST] <BtbN> never encountered that [11:10:10 CEST] <BtbN> What GPU and Driver? [11:11:31 CEST] <rcombs> Quadro P2000 [11:11:36 CEST] <rcombs> driver, uh [11:11:56 CEST] <rcombs> idk but the date is from july [11:12:02 CEST] <rcombs> this is on windows [11:12:49 CEST] <rcombs> I've also had some very bizarre issues when trying to run this in a 32-bit windows process (segfaults in nvenc; can't tell where because gdb doesn't get any useful function bounds from DLLs) [11:13:28 CEST] <rcombs> (though the segfaults only happen when I have a scale_cuda filter) [11:13:53 CEST] <rcombs> this is in 64-bit, which doesn't crash, but gives this error [11:14:30 CEST] <rcombs> hard to tell if it's an ffmpeg bug or an nvenc driver bug; not sure if I should poke nvidia or not [11:15:51 CEST] <rcombs> making me miss VAAPI and open-source drivers [11:15:59 CEST] <JEEB> yea :/ [11:16:02 CEST] <BtbN> I'd try and get the latest driver first [11:16:04 CEST] <JEEB> you do have the closed blob at the end often [11:16:10 CEST] <JEEB> but still, you have a lot of stuff semi-visible [11:16:34 CEST] <rcombs> the installed driver is newer than the one in the current CUDA installer, at least [11:16:56 CEST] <BtbN> Those are usually super outdated [11:17:02 CEST] <rcombs> also wait the date is actually may [11:17:13 CEST] <BtbN> Current driver for it is 436.02 from a week ago [11:17:17 CEST] <rcombs> windows says "the best drivers for your device are already installed" [11:17:21 CEST] <rcombs> is it lying [11:17:36 CEST] <rcombs> and how do I check the driver version [11:17:38 CEST] <BtbN> Why would Windows be able to tell what the latest nvidia driver is? [11:17:46 CEST] <BtbN> You put the GPU in here: https://www.nvidia.de/drivers/beta [11:18:04 CEST] <rcombs> idk it claims to know [11:18:13 CEST] <BtbN> You must be new to Windows :P [11:18:18 CEST] <rcombs> yes [11:18:21 CEST] <rcombs> please let me stay that way [11:18:22 CEST] <JEEB> that's what windows update has basically [11:18:30 CEST] <BtbN> Not even what Windows Update has [11:18:30 CEST] <JEEB> whatever nvidia pushed to MS at some point in history [11:18:42 CEST] <BtbN> it's what driver it has locally for that device [11:19:17 CEST] <rcombs> this is, uh, 430.86, I guess [11:19:30 CEST] <BtbN> Yeah, you want to update that [11:19:42 CEST] <BtbN> P2000 is a Notebook GPU, right? [11:19:45 CEST] <rcombs> I'll try the newer version but forgive me for not being especially optimistic about this happening to have been fixed in the past few months [11:19:46 CEST] <BtbN> Is it paired with an Intel one? [11:20:15 CEST] <rcombs> not notebook, but there's also an intel GPU in this machine yes [11:20:41 CEST] <BtbN> Cause when I put P2000 into the NVidia Page, it sends me to the mobile driver [11:21:05 CEST] <BtbN> And Laptop-Optimus-Setups often have the video engine in the nvidia GPU partially or entirely disabled [11:21:16 CEST] <rcombs> idk maybe it's a mobile part but it's on a card in this case [11:21:25 CEST] <rcombs> I'm RDP'd into a coworker's machine poking at this [11:21:40 CEST] <BtbN> Yeah, I'd update the driver and reboot [11:21:50 CEST] <BtbN> Nvidia won't accept any bugreports otherwise anyway [11:21:54 CEST] <nevcairiel> quadro P2000 exists both as mobile and desktop part [11:22:36 CEST] <rcombs> the "recommended" one is 431.70, from late july [11:22:45 CEST] <nevcairiel> its (surpsiginly) a pascal part, similar to a 1060 [11:22:48 CEST] <rcombs> I take it I want the beta anyway? [11:22:55 CEST] <BtbN> what do you mean, recommended? [11:23:09 CEST] <rcombs> I mean there's a little "RECOMMENDED" label next to it on nvidia's search page [11:23:39 CEST] <BtbN> 436.02 isn't Beta, it's just quite new [11:23:50 CEST] <BtbN> I'm using it at home and it runs fine [11:24:04 CEST] <nevcairiel> quadro uses different drivers, they dont have 436 yet [11:24:12 CEST] <rcombs> well it's offering me it [11:24:14 CEST] <BtbN> They do, at least on their download page [11:24:23 CEST] <BtbN> https://www.nvidia.de/drivers/results/150305 [11:24:32 CEST] <rcombs> just "recommending" 431 [11:24:44 CEST] <nevcairiel> oh i selected the stable driver instead of the "new features" driver [11:24:56 CEST] <rcombs> it's not listed as "WHQL", whatever that means [11:25:07 CEST] <BtbN> Certified by Microsoft [11:25:13 CEST] <rcombs> how do people actually use this platform to, like, do things [11:25:24 CEST] <nevcairiel> it like, just works for us :D [11:25:41 CEST] <rcombs> [insert joke about shipping your machine] [11:25:45 CEST] <nevcairiel> its always the people that dont use it that somehow attract weird issues [11:25:50 CEST] <BtbN> It gets specially fun when you realize windows 10 has two different GPU driver models [11:26:02 CEST] <BtbN> and depending on which one your driver was initially installed, you need to download different ones [11:26:25 CEST] <BtbN> Classic vs. DCH [11:26:44 CEST] <rcombs> this is not what I would describe as an excellent sales pitch [11:26:54 CEST] <rcombs> installing driver now [11:26:54 CEST] <BtbN> from what I gather, you want to stick with Classic [11:27:17 CEST] <nevcairiel> I dont think it ultimately makes much of a difference [11:27:25 CEST] <BtbN> DCH performs notably worse [11:27:27 CEST] <rcombs> I didn't get an option along those lines [11:27:36 CEST] <BtbN> I don't think Quadro has DCH drivers yet [11:27:46 CEST] <rcombs> but perf doesn't really matter here, I'm just trying to get a setup working that can test this code [11:27:52 CEST] <nevcairiel> from what I can tell the only difference is that you get the control panel from the windows store in DCH mode [11:28:13 CEST] <nevcairiel> the actual driver itself is even t he same [11:28:18 CEST] <nevcairiel> its just packaging that varies [11:28:24 CEST] <rcombs> oh it actually updated the driver without needing a reboot [11:28:38 CEST] <BtbN> you should still reboot [11:28:44 CEST] <BtbN> nvenc is iffy sometimes when you don't [11:29:23 CEST] <rcombs> same error as before, so sure I'll try a reboot [11:31:10 CEST] <BtbN> The driver returning 22 from nvEncRegisterResource is also very likely not an ffmpeg issue [11:31:46 CEST] <rcombs> the weird thing is that it's so specific (only happens if pipelining from nvdec) [11:31:59 CEST] <BtbN> Well, in no other case does nvenc get cuda frames as input [11:32:07 CEST] <BtbN> And that's the codepath where it happens [11:32:18 CEST] <BtbN> You could alternatively try to decode using d3d11va, and pass in d3d frames [11:32:39 CEST] <rcombs> it doesn't happen if I explicitly use a hwupload filter [11:32:50 CEST] <BtbN> Oh [11:32:51 CEST] <rcombs> I checked, it's taking the CUDA-input code path in that case [11:33:21 CEST] <nevcairiel> nvdec and nvenc sharing surfaces has been a bit wonky in the past, iirc [11:33:39 CEST] <rcombs> lemme see what happens if I hwdownload->hwupload, just for shits n' gigs [11:34:18 CEST] <BtbN> Yeah, nvdec frames are a bit special [11:34:28 CEST] <BtbN> but they _did_ work when I made them that way [11:34:29 CEST] <rcombs> oh also, in mintty is there a reasonable way to move the cursor faster [11:34:45 CEST] <JEEB> rcombs: btw I have my first version of TTML-in-MP4 that is not a complete monstrocity boiling up (other than the spec being spörs splräsh wtf) [11:34:47 CEST] <rcombs> (or, I assume this is mintty) [11:34:49 CEST] <BtbN> No idea, I don't use mintty anymore [11:35:22 CEST] <rcombs> JEEB: like, the _code_ isn't a monstrosity? 'cause I'm pretty sure there's gonna be some monstrous shit involved no matter what there [11:35:35 CEST] <JEEB> yes [11:35:40 CEST] <BtbN> I'm at work right now, without a nvidia GPU close [11:35:42 CEST] <JEEB> the code isn't completely evil incarnate [11:35:48 CEST] <BtbN> so I can't test, but will do once I get home [11:35:51 CEST] <JEEB> it's just stupid because you need to squash packets into one [11:36:07 CEST] <BtbN> rcombs, try decoding with the old cuvid decoders [11:36:09 CEST] <rcombs> okay yeah if I hwdownload->hwupload it's fine [11:36:52 CEST] <nevcairiel> if you're on windows anyway and don't care about 12-bit or 444 support, just use d3d11va [11:37:15 CEST] <BtbN> I'm a bit worried nvidia broke the way we operate nvdec in some update :/ [11:37:42 CEST] <nevcairiel> ultimately all you do is copy nvdec output onto a generic cuda array, no? its not directly tied to nvdec anymore after that? [11:37:49 CEST] <BtbN> It is [11:38:03 CEST] <BtbN> There is a special buffer context, that drags the nvdec context along, to avoid a copy [11:38:13 CEST] <BtbN> so the frames coming out of nvdec are the mapped nvdec frame [11:38:53 CEST] <BtbN> Without doing that, nvdec reaches only ~20% of the performce the cuvid decoder has [11:39:19 CEST] <rcombs> nevcairiel: need scale+deint [11:39:35 CEST] <BtbN> rcombs, cuvid might be just what you want then [11:39:37 CEST] <nevcairiel> too bad I was too lazy to finish d3d11va vpp filter [11:39:41 CEST] <JEEB> rcombs: it is just dumb but lol http://up-cat.net/p/6bf94b85 [11:39:44 CEST] <BtbN> the cuvid decoders have scale + deint built in [11:39:59 CEST] <rcombs> fucking [11:40:00 CEST] <nevcairiel> its somewhere on my list to actually write that thing [11:40:04 CEST] <rcombs> you're giving me PTSD flashbacks [11:40:15 CEST] <rcombs> to android shit [11:40:23 CEST] Action: rcombs deep breaths [11:40:33 CEST] <rcombs> at least it's not nvidia's android thing where they put the scaler IN THE ENCODER [11:40:33 CEST] <JEEB> (I love it how track_id 3 gets printed as zero since there is no packets muxed yet so it hasn't decided yet?) [11:40:37 CEST] <BtbN> though deint in the decoder is a bit troublesome, due to a decoder not being intended to double the framerate [11:40:38 CEST] <JEEB> :D [11:40:48 CEST] <BtbN> oh, nvenc absolutely does have a scaler [11:40:53 CEST] <BtbN> ffmpeg just does not utilize it for anything [11:40:58 CEST] <rcombs> good [11:41:15 CEST] <rcombs> believe you me, scalers in lavc encoders were not meant to be [11:41:22 CEST] <rcombs> I have some very evil hacks to support this shit [11:43:02 CEST] <rcombs> but anyway, long-term I'm gonna need more filtering stuff as well (overlay, tonemap, etc), so I don't particularly want to rely on cramming everything in the decoder [11:43:17 CEST] <BtbN> nevcairiel, http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/nvdec.c;h=b60da24… does most of that [11:43:17 CEST] <rcombs> and I've been having decent success with nvdec+cuda filters+nvenc on linux [11:43:49 CEST] <BtbN> I kinda wish there was a way to make OpenCL operate on CUDA frames without a roundtrip copy via system RAM [11:44:37 CEST] <rcombs> same, but I'm considering putting together a sort of compatibility layer that lets you write kernels that work on both [11:44:48 CEST] <rcombs> just a .h with a bunch of #defines for each [11:45:05 CEST] <rcombs> BtbN: same error with the cuvid decoder [11:45:34 CEST] <rcombs> [[aforementioned worries intensify]] [11:45:35 CEST] <BtbN> ok, it's not the weirdly mapped frame then, cause cuvid does not do that. [11:46:04 CEST] <rcombs> lemme try with the download+upload [11:46:28 CEST] <rcombs> yeah it's fine if I do that [11:46:33 CEST] <BtbN> Did something break in ffmpeg that makes nvenc use the wrong CUDA Context? [11:46:48 CEST] <BtbN> I'll have to investigate this later [11:47:06 CEST] <BtbN> Cause yeah: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/cuviddec.c;h=acee… [11:47:31 CEST] <BtbN> cuviddec literally makes a new frame and memcopies the data over. Equivalent to hwdownload+upload without the RAM roundtrip [11:48:44 CEST] <rcombs> I've also got a scaler in the filter chain here, with src=dst res, which is effectively a GPU-side memcpy [11:48:48 CEST] <rcombs> (same error with or without it) [11:48:57 CEST] <rcombs> but any mapping oddities shouldn't survive that, right? [11:49:03 CEST] <BtbN> scale_cuda should detect that case and pass through the frames untouched [11:49:09 CEST] <rcombs> should; afaik it doesn't [11:49:23 CEST] <nevcairiel> oh so cuviddec did the thing i was thinking of [11:49:53 CEST] <BtbN> nvdec mapps the frame and then constructs a frame that unmaps it on free [11:50:04 CEST] <BtbN> cuvid just copies it [11:50:22 CEST] <BtbN> cuvid can do that because it's a full fledged decoder, and thus can delay the copy until the GPU is ready [11:50:39 CEST] <BtbN> nvdec can't, and doing the copy as late as possible is still to early and forces the GPU to sync and stall [11:50:43 CEST] <rcombs> I'm a little behind master, but there doesn't seem to be anything relevant in between [11:50:53 CEST] <BtbN> nah, there hasn't been any changes there lately [11:51:08 CEST] <rcombs> ¯\_(Ä)_/¯ that kind of mapping/free thing is pretty common in these [11:51:19 CEST] <rcombs> it's perfectly reasonable [11:51:22 CEST] <nevcairiel> I think we could devise a way to have delay in the generic code of avcodec before the postprocess callback is called [11:51:34 CEST] <BtbN> Hacking it into a AVFrame is not common though [11:51:34 CEST] <nevcairiel> if it would be useful [11:51:42 CEST] <rcombs> isn't it? [11:51:43 CEST] <nevcairiel> but i suppose this method works [11:52:14 CEST] <BtbN> To keep the frame mapped, the cuvid and cuda context need to stay alive as well [11:52:14 CEST] <rcombs> I've done it on android [11:52:14 CEST] <rcombs> yeah, I've done that [11:52:14 CEST] <BtbN> so the frames also carry a buffer ref to those, so they don't get freed to early [11:52:22 CEST] <rcombs> yup, same with my android thing [11:52:32 CEST] <BtbN> I've never seen anything else do that [11:52:49 CEST] <BtbN> But since it also happens with cuviddec, which does not do any such thing to begin with, that can't be the issue [11:52:51 CEST] <rcombs> though in that case I'm just passing around mapped pointers, not GPU surfaces or anything [11:53:26 CEST] <rcombs> (I'm told there's _some_ way to get surfaces out of mediacodec decoders, and to pass them into mediacodec encoders, but fuck if I can find any decent docs on how) [11:53:46 CEST] <rcombs> (and some of that stuff's only available from java because fuck) [11:54:38 CEST] <rcombs> but yeah, what you said [11:55:14 CEST] <BtbN> Does it also happen if you do just cuviddec -> nvenc without anything in between? [11:55:46 CEST] <rcombs> lemme see [11:56:02 CEST] <BtbN> Cause if not, it has to be something the scale filter does [11:57:17 CEST] <rcombs> yup [11:57:26 CEST] <BtbN> I have an NVidia GPU in my desktop again since yesterday, so I'll be able to test once I get home [11:57:33 CEST] <BtbN> My AMD adventures where short and painful. [11:57:52 CEST] Action: rcombs sighs [11:57:58 CEST] <rcombs> I'll probably have to do some AMF stuff soon [11:58:05 CEST] <BtbN> Do you need a GPU? [11:58:09 CEST] <BtbN> I happen to have two [11:58:31 CEST] <rcombs> possibly, but I can probably expense one if it comes up [11:58:41 CEST] <BtbN> AMD sent me two dev GPUs for free [11:58:49 CEST] <BtbN> so, I can literally just send you one [11:59:01 CEST] <BtbN> One RX5700 and one RX590 [11:59:17 CEST] <rcombs> now I kinda want your dev contacts more than I want your GPUs [11:59:48 CEST] <BtbN> They asked here in this channel a while ago, looking for developers interested in doing AMF stuff, and sent everyone a round of GPUs [12:00:04 CEST] <rcombs> oh, totally missed that [12:00:14 CEST] <rcombs> but yeah I might write an AMF decoder to get around needing to deal with mesa [12:00:26 CEST] <nevcairiel> me too, i bought a 560 earlier this year for $work =p [12:00:27 CEST] <rcombs> (have you tried to build mesa) [12:00:35 CEST] <BtbN> The RX5700 is a hot mess on Windows [12:00:43 CEST] <rcombs> (it DEPENDS ON LLVM) [12:00:44 CEST] <nevcairiel> its an AMD gpu, its expected [12:00:46 CEST] <BtbN> so if you want a RX5700 (non-XT) for free, send me your address. [12:00:58 CEST] <rcombs> (can you imagine shipping something with a runtime dependency on LLVM) [12:01:17 CEST] <BtbN> OpenCL also has that, as you can and do compile C code at runtime? [12:01:19 CEST] <nevcairiel> dont most systems just come with mesa anyway [12:01:32 CEST] <nevcairiel> i mean, the typical graphics stack always has it [12:02:01 CEST] <rcombs> yeah, but I ship libva, and VAAPI breaks the lib<->driver ABI on every release [12:02:10 CEST] <nevcairiel> fun. [12:02:25 CEST] <nevcairiel> which is too bad, since i've been thinking about shipping libva2 [12:02:27 CEST] <BtbN> nevcairiel, it's so bad on Windows that playing a YouTube video on Firefox with hwaccel enabled has a more than 50% chance to send the system into a Bluescreen [12:02:44 CEST] <rcombs> with the intel driver it's nbd, it's an easy build and costs like 5MB [12:03:03 CEST] <rcombs> but the AMD driver is 25MB and the mesa build is awful [12:03:55 CEST] <nevcairiel> I had two options, either change ffmpeg so libva is not linked-in, or ship the linked-in version of libva, so that we can support hwaccel on intel on reasonable modern systems, but still run in software mode on older ones, i figured shipping libva2 would be easier :D [12:05:17 CEST] <rcombs> it is, if you only need intel and not AMD [12:05:42 CEST] <BtbN> libva/vaapi is basically an Intel GPUs interna made into an API [12:05:43 CEST] <nevcairiel> intel is the primary goal, since we care about NUCs a bit [12:05:57 CEST] <BtbN> So for AMD to support libva, they kinda have to emulate an Intel GPU [12:06:17 CEST] <rcombs> though you have to either set an env var to specify the driver path, or use a patch I wrote that's been in PR since forever that adds an RPATH-$ORIGIN-style feature [12:06:39 CEST] <rcombs> and makes libva search for drivers in [its own library path]/dri instead of a hardcoded absolute path [12:06:47 CEST] <nevcairiel> i sorta hope that those vulkan video decoding extensions actually work and give us something for all vendors on linux .... eventually [12:07:06 CEST] <BtbN> Yeah, Vulkan Video Decodce becoming the d3d11va of Linux would be godly [12:07:23 CEST] <rcombs> still needs encode though [12:07:29 CEST] <BtbN> Browsers would probably finally support hwaccel [12:07:35 CEST] <nevcairiel> true, but decode would be a very good start [12:07:40 CEST] <rcombs> fair enough [12:08:00 CEST] <rcombs> and apparently someone in here is working on vulkan->AMF interop on the encode side [12:08:07 CEST] <rcombs> it's on the ML iirc [12:08:11 CEST] <nevcairiel> unfortunately a vendor-agnostic encode API seems not to be s omething anyone is interested in, since the hardware exposes way too different features [12:08:27 CEST] <BtbN> Well, technically Linux has a vendor agnostic encode API [12:08:29 CEST] <rcombs> there's the v4l2 thing! [12:08:30 CEST] <BtbN> but nobody uses it [12:08:38 CEST] <nevcairiel> see not being interested in it =p [12:08:51 CEST] <rcombs> though also, doesn't AMF have OpenCL interop [12:09:04 CEST] <nevcairiel> but regardless encoding is usually easier to get going with vendor-specific APIs [12:09:11 CEST] <nevcairiel> well except intel on windows, qsv is so terrible [12:09:32 CEST] <BtbN> I wonder, with Nvidia UVM... Could you just cast a CUdevptr to a OpenCL one, and it just works? [12:09:48 CEST] <nevcairiel> (not that vaapi encoding is better, its so extremely low level .. but at least it being low level lets you fix what they wont) [12:10:00 CEST] <rcombs> allegedly no, but in practice idk [12:10:17 CEST] <BtbN> You can cast a CUdevptr to a char* and it just works [12:10:23 CEST] <BtbN> even if it's in GPU memory [12:10:43 CEST] <rcombs> do you get ridiculous performance characteristics [12:10:55 CEST] <nevcairiel> isnt there a real interop? [12:11:17 CEST] <nevcairiel> i suppose maybe not, nvidia doesnt like OCL [12:11:28 CEST] <rcombs> if there is, their forums don't know about it [12:11:33 CEST] <BtbN> There is absolutely no OpenCL <-> CUDA interop [12:11:47 CEST] <nevcairiel> at least they are warmer towards vulkan [12:12:03 CEST] <nevcairiel> has interop and everything [12:12:14 CEST] <rcombs> &is there vulkan<->OpenCL interop [12:12:58 CEST] <rcombs> (are you thinking the extremely dumb thing I'm thinking) [12:13:15 CEST] <nevcairiel> obviously, but i reckon it might nto work without copies [12:13:48 CEST] <BtbN> Even CUDA<->OpenGL Interop is so weirdly designed you need to memcpy [12:15:28 CEST] <rcombs> anyway [12:16:19 CEST] <rcombs> lmk if you repro that nvidia issue [12:16:51 CEST] <rcombs> in the interim, I'll poke nvidia about it [12:37:46 CEST] <JEEB> rcombs: and with fragments it gets even more "fun" http://up-cat.net/p/d8fc4f9e [12:37:50 CEST] <JEEB> xD [12:38:27 CEST] <JEEB> yes, adding empty documents to fragments to keep the time line going [12:38:30 CEST] <JEEB> ý(Žü@)Î [12:39:57 CEST] <rcombs> JEEB: heh, I have a segment.c patch somewhere that lets it emit empty segments when necessary (by looping over end/start until it hits the target timestamp) [12:41:38 CEST] <JEEB> and if you have only the subtitle track, this will 100% fail with "fragment at time X" because the packets only get actually added to index at fragmentation or footer writing :P [12:41:53 CEST] <JEEB> unless you add some extra logic to check the queue [15:59:15 CEST] <cone-129> ffmpeg 03James Almer 07master:af70bfbeadc0: avcodec/h2645_parse: zero initialize the rbsp buffer [16:28:38 CEST] <tmm1> is there a good doc on how format negotiation works with hwcontexts [16:58:40 CEST] <jamrial> tmm1: jkqxz may know, but i guess the doxy is expected to be enough? [16:59:33 CEST] <cone-129> ffmpeg 03James Almer 07master:33a53722dc5e: avcodec/qtrle: add a flush() callback [17:14:47 CEST] <tmm1> the filter design document is really good, something like that for hwcontext design would be useful [17:33:36 CEST] <BtbN> I wonder if that package is something I can ask for a refund for. Cause the cheap 16¬ option is kinda shit. [17:33:47 CEST] <BtbN> No insurance and tracking at all. [17:59:14 CEST] <cone-129> ffmpeg 03Michael Niedermayer 07master:dead949a1fbf: avcodec/atrac9dec: Check block_align [18:04:16 CEST] <durandal_1707> jamrial: have checked that after seeking qtrle its not black? [18:15:50 CEST] <jamrial> durandal_1707: no [18:16:34 CEST] <jamrial> durandal_1707: if you want i can remove the memset for the palette, if that's what you're concerned about [18:17:35 CEST] <durandal_1707> hmm, try with ffplay? [18:17:44 CEST] <nevcairiel> the palette should probably stay [18:19:01 CEST] <nevcairiel> it might be constant throughout the entire file and only delivered in the beginning [18:20:15 CEST] <BtbN> michaelni_, I'm not sure who usually handles that, but would shipping costs for a parcel to the US (AMD GPU for AMD devel stuff for rcombs) be eligible for a refund from the ffmpeg foundation? Probably 30~50¬. [18:20:48 CEST] <BtbN> rcombs, "./ffmpeg.exe -hwaccel cuda -hwaccel_output_format cuda -i D:/Cache/enctest.mkv -c:a copy -sn -c:v h264_nvenc -preset slow -rc vbr_hq -b:v 25M -cq 22 -y D:/Cache/test_out.mkv" works great for me on current master [18:21:22 CEST] <BtbN> Same if I add in "-c:v h264_cuvid" [18:23:17 CEST] <BtbN> Also works if I throw in "-vf scale_cuda=800:-2" [18:25:12 CEST] <BtbN> That's on an RTX2070 [18:32:50 CEST] <BtbN> I must say, I'm impressed with turing nvenc [18:34:01 CEST] <nevcairiel> the quality is really a large step up [18:34:13 CEST] <nevcairiel> happy with the 1660 for my streaming PC [18:35:03 CEST] <jamrial> durandal_1707: do you have a qtrle mov sample with more than one sync point and a palette in the bitstream? [18:35:52 CEST] <BtbN> nevcairiel, it's also really good at holding CBR [18:36:00 CEST] <durandal_1707> jamrial: there is ffmpeg encoder [18:36:05 CEST] <BtbN> set it to 6 Mbit CBR, and sure enough, does not devicate one bit from it [18:37:23 CEST] <nevcairiel> did older ones not manage that? it seems like strict CBR was something they always could do [18:38:00 CEST] <BtbN> Not THAT good [18:38:07 CEST] <BtbN> they padded a lot [18:38:15 CEST] <BtbN> turing uses virtually no padding [18:38:30 CEST] <BtbN> Unless nothing is happening, of course [18:38:57 CEST] <nevcairiel> i see, you actually looked into the padding used :D [18:39:10 CEST] <BtbN> Well, I just didn't enable it, and looked at the output :D [18:40:14 CEST] <BtbN> I'm confused why things explode on that P2000 though, and work perfectly here [18:41:02 CEST] <michaelni_> BtbN, i would approve it. But as we IIRC did not had such case before there may be other unforseen obstacles also other developers could in theory objectbut I do not know if there are other obstacles, for example s international shipping will probably be duty/tax [18:41:38 CEST] <BtbN> Yeah, but those won't be on me, but on the receiving end. [18:41:57 CEST] <BtbN> Not sure how that works, I intend to declare it as a gift, which it technically is. [18:42:37 CEST] <michaelni_> here declaring as a gift wont help, i still have to pay full on gifts from china [18:43:21 CEST] <nevcairiel> they also have to believe you :p [18:44:29 CEST] <BradleyS> may i ask which gpu and to what country? i have a spare 570 here i was going to sell but could donate. i'm in the us [18:44:39 CEST] <BtbN> RX5700 from DE to US [18:44:46 CEST] <BradleyS> might be a 580, i have to look [18:44:47 CEST] <durandal_1707> no gifts from me or to me :) [18:45:09 CEST] <BtbN> I got it from AMD for devel work, but it's unlikely I will ever put it to that use. [18:45:15 CEST] <BradleyS> ah, navi [18:45:29 CEST] <BradleyS> definitely newer than what i have, but if he wants mine i can send it too [18:45:44 CEST] <BtbN> They also sent me an RX590 along with it. Which I have no clue what to do with. [18:46:11 CEST] <BradleyS> only bought it for benchmarking hardware encoding for handbrake, the results and comparisons are an article in our documentation [18:46:13 CEST] <BradleyS> not sure what to do with it now [18:46:26 CEST] <durandal_1707> BtbN: why you have so much unused stuff? [18:46:29 CEST] <jamrial> play a game? [18:46:43 CEST] <BradleyS> 1080 ti sc [18:46:49 CEST] <BtbN> durandal_1707, because AMD asked me if I wanted free stuff. And I didn't say no. [18:47:44 CEST] <BradleyS> i would have liked to test a newer gpu's asic but i was assured it wouldn't be that much difference and i didn't want to pay top dollar, got this one on ebay of all places [18:48:16 CEST] <BtbN> RX5700 isn't even that expensive. It's like 300¬ new [18:48:34 CEST] <BradleyS> not awful but i think i paid ~100 USD for the 570 used [18:48:41 CEST] <BtbN> Only porlbme, and reason why I'm not using it: The Windows drivers are an absolute catastrophy. [18:55:40 CEST] <philipl> The new prime offload support for nvidia is pretty snazy. I can do nvdec and vaapi work in the same desktop session. [18:56:09 CEST] <BtbN> I mean, you could always do that, since nvdec does not depend on the desktop session at all. [18:56:09 CEST] <philipl> vdpau shits the bed; that was amusing. [18:56:20 CEST] <philipl> BtbN: but with working opengl/vulkan interop. [18:57:14 CEST] <BradleyS> speaking of, if anyone could provide further comment/review on this, it would be helpful https://patchwork.ffmpeg.org/patch/14319/ [18:57:33 CEST] <BradleyS> we'd like to include it in handbrake but of course, wish to know whether it will be accepted into ffmpeg proper [18:59:18 CEST] <philipl> It's self contained enough that I don't know why anyone would object, but it obviously would not work well if we ever get a vulkan hwcontext in. [19:02:22 CEST] <BradleyS> my understanding is this is directly from amd, so i'm sure that information will be valuable if you would kindly reply [19:03:05 CEST] <BradleyS> fyi this is our pull request from june https://github.com/HandBrake/HandBrake/pull/2151 [19:05:13 CEST] <philipl> BtbN: you have any objection to pushing that change? You did comment previously [19:06:39 CEST] <BtbN> It looks fine to me [19:28:59 CEST] <tmm1> looks pretty reasonable to me too [19:29:49 CEST] <tmm1> i didn't realize amf worked on linux [20:16:49 CEST] <durandal_1707> jamrial: so, tried ffmpeg qtrle encoder and playing output with ffplay? [20:17:23 CEST] <jamrial> durandal_1707: no, was busy doing other stuff [20:17:41 CEST] <jamrial> does it even code in a palette? it's not looking at frame side data, or even frame->data[1] [20:18:26 CEST] <durandal_1707> agh, you mean it does not support pal8? [20:18:34 CEST] <durandal_1707> that sucks [20:19:00 CEST] <jamrial> ah, good point, didn't bother looking at the list of supported pix_fmts [20:19:02 CEST] <jamrial> no, no pal8 [20:20:56 CEST] <jamrial> i'll remove the memset in any case. the mov demuxer seems to read the palette from the header (stsd atom), and then attach it into a single packet [20:31:24 CEST] <cone-129> ffmpeg 03James Almer 07master:8b71cc3363b5: Revert "avcodec/qtrle: Do not output duplicated frames on insufficient input" [20:31:25 CEST] <cone-129> ffmpeg 03James Almer 07master:d70bbdc5fa05: avcodec/qtrle: call ff_reget_buffer() only when the picture data is going to change [20:31:26 CEST] <cone-129> ffmpeg 03James Almer 07master:b319feb05f40: avcodec/qtrle: don't clear the palette when flushing [21:11:43 CEST] <tmm1> decoder codecs list hardware formats first in pix_fmt, then call ff_get_format to negotiate the format [21:12:07 CEST] <tmm1> what about encoders.. looks like they list the hardware formats last? do they have to call something else to negotiate or does the filtergraph do it automatically [22:00:55 CEST] <rcombs> BtbN: huh, well I'll try on master for good measure, and if that doesn't work I suppose I'll blame the drivers on this particular card [22:01:01 CEST] <rcombs> thanks for checking [22:03:11 CEST] <BtbN> definitely worth a message to nvidia [22:03:31 CEST] <BtbN> My video was a 1080p yuv420p video [22:03:42 CEST] <BtbN> Yours wasn't something uncommon by any chance, was it? [22:10:20 CEST] <rcombs> nope, 720p yuv420p [22:11:51 CEST] <rcombs> (just a random file) [00:00:00 CEST] --- Wed Aug 28 2019

1 0

ffmpeg.log.20190827
by burek 28 Aug '19

28 Aug '19

[00:10:24 CEST] <fling> Where can I find https://roundup.ffmpeg.org/file1098/utils.c.patch ? [00:10:36 CEST] <fling> the one mentioned here -> https://stackoverflow.com/questions/3774853/ffmpeg-av-interleaved-write-fra… [00:12:38 CEST] <BtbN> "8 years, 11 months ago" [00:16:42 CEST] <nicolas17> it's unlikely an 8-year-old patch will apply on current ffmpeg code [00:22:59 CEST] <fling> ok [01:06:15 CEST] <rocktop> how can I scroll text from left to right ? [01:07:18 CEST] <pink_mist> include some .ass subtitles that displays text which you have used .ass commands to animate [01:09:31 CEST] <rocktop> pink_mist: I never used subtitles [01:09:46 CEST] <rocktop> can you show me an example please ? [01:10:02 CEST] <nicolas17> hmm I think you can do it with the drawtext filter [01:10:43 CEST] <rocktop> nicolas17: yes I know but I can't achieve that there are a complex calculations [01:10:50 CEST] <pink_mist> I've never used subs for anything remotely like this myself, so no, I can't - I just know it's possible [02:22:56 CEST] <rocktop> anyidea how to make the text sliding from left to right ? [02:27:28 CEST] <DHE> make the X offset in drawtext a formula involving time or frame number. start big, shrink over time. [02:35:46 CEST] <rocktop> DHE: I only get this x=w-w/3*mod(t\,3*(w+tw)/w) this scrolling fast from the right to the left I want to make reverse it and make it little slow [02:37:18 CEST] <rocktop> any idea ? [03:40:56 CEST] <Aurora_iz_kosmos> Will the use of "-codec copy" for output use compression? Say, going $(ffmpeg -i file.avi -codec copy file.mkv) ? [03:47:18 CEST] <nicolas17> it will use whatever compression was in the original file [03:48:48 CEST] <Aurora_iz_kosmos> So it directly copies over the streams without any transcoding? I see. Would the use of "-map 0:0" similarly keep all streams while transcoding? [03:49:02 CEST] <Aurora_iz_kosmos> Erh, "-map 0" [03:49:38 CEST] <Aurora_iz_kosmos> I have no idea what I'm doing. I just have a bunch of old media I'm trying to shrink without degrading its quality. [04:02:27 CEST] <nicolas17> -map is unrelated [04:02:44 CEST] <nicolas17> it just says picks what streams to use [04:03:17 CEST] <nicolas17> you won't get any shrinking if you copy without transcoding [04:07:04 CEST] <Aurora_iz_kosmos> Okay. [04:09:15 CEST] <Aurora_iz_kosmos> So, would something along the lines of $(find /media/my-old-stuff -type f -iname "*.avi" -print0 | parallel -0 -j 1 ffmpeg -i {} -map 0 {.}.mkv) would do what I think it will? [04:10:06 CEST] <nicolas17> test with one video alone first :P [04:10:21 CEST] <nicolas17> you're not specifying any options there so I think that will transcode with mkv's default codec and default quality/bitrate which probably sucks [04:12:34 CEST] <Aurora_iz_kosmos> Hm. Is there a way to somehow detect each video's input quality and give something similar as output? [04:12:54 CEST] <nicolas17> not really [04:13:01 CEST] <nicolas17> what codec do your input videos have? [04:13:22 CEST] <Aurora_iz_kosmos> I'm not sure. Several different recorders were used over the years. [04:14:20 CEST] <nicolas17> run ffprobe on one and share a pastebin of the result [04:16:52 CEST] <Aurora_iz_kosmos> https://pastebin.com/C0Mze0A2 [04:18:52 CEST] <another> you can probably use some lossless codec to compress this [04:19:04 CEST] <another> mjpeg is not really efficient [04:19:30 CEST] <Aurora_iz_kosmos> I'd surmised as much when I looked into ip-cams. [04:19:41 CEST] <nicolas17> each frame is an independent JPEG image [04:20:06 CEST] <nicolas17> another: I'm surprised *lossless* codecs do better than mjpeg though [04:20:14 CEST] <another> i think the cut off the additional headers or something, but yes [04:21:03 CEST] <another> well, you can use interframe prediction [04:21:59 CEST] <nicolas17> then again I was also surprised when ffv1 did better than h264-lossless in one particular sample... [04:24:37 CEST] <furq> was that with ultrafast or something [04:25:14 CEST] <Aurora_iz_kosmos> what sorta codec would you recommend? [04:25:59 CEST] <furq> you won't shrink any of these without losing quality unless the source is huffyuv or something [04:26:06 CEST] <furq> so the question is how much quality are you prepared to lose [04:27:08 CEST] <furq> something like x264 crf 18 will be a lot smaller and almost indistinguishable [04:27:24 CEST] <furq> you'd really just want to cut some short samples and experiment to see what suits you [04:28:29 CEST] <Aurora_iz_kosmos> I see. Seems like this project is going to take a lot more time than I'd originally thought. I was asking for recommendations mostly because I know very little about codecs. [04:29:38 CEST] <furq> also there's no point using parallel if you go with x264 since it'll multithread anyway [04:29:44 CEST] <furq> unless you're on a dual xeon box or something [04:30:19 CEST] <Aurora_iz_kosmos> I mostly planned to use it because of the syntax-sugar for extension stripping. [04:30:28 CEST] <Aurora_iz_kosmos> (Which xargs lacks) [04:30:56 CEST] <Aurora_iz_kosmos> The "-j 1" flag was meant to keep it linear/serial. [04:31:05 CEST] <furq> oh right [04:32:54 CEST] <another> Aurora_iz_kosmos: what is your goal? [04:33:05 CEST] <furq> well if all of the audio is pcm then you can get one easy win by converting all of that to flac [04:33:10 CEST] <another> lossless archival? [04:33:22 CEST] <furq> it won't be a huge win if it's all 11k u8 though [04:33:27 CEST] <another> or save space while keeping it "good enough"? [04:33:37 CEST] <Aurora_iz_kosmos> another: Ideally yeah. Though I'd settle for not-eye-distinguishable. [04:34:16 CEST] <nicolas17> unfortunately the appropriate quality parameters for "not-eye-distinguishable" have to be decided by your own eye and experimenting [04:34:38 CEST] <another> see here: https://trac.ffmpeg.org/wiki/Encode/H.264 [04:34:44 CEST] <furq> x264 should be good enough and there's only really two settings worth tweaking [04:34:57 CEST] <furq> crf (lower values = higher quality/bigger file) and preset (slower preset = more cpu usage) [04:35:37 CEST] <furq> if it's all 480p then it won't take long to encode test samples [04:35:59 CEST] <furq> this is probably also a good time to do any denoising/deinterlacing or any other cleanup [04:36:53 CEST] <Aurora_iz_kosmos> I see. Any similar links to read up on those you'd suggest? [04:37:31 CEST] <Aurora_iz_kosmos> (I might as well do this properly if I'm to do it at all.) [06:27:32 CEST] <lain98> how do i calculate the frame number at a particular time in seconds. i have stream information. for example i want to know that the frame at 5 seconds is frame number 331. [06:28:08 CEST] <lain98> i know total number of frames and assume cfr [06:36:08 CEST] <Oleg_> how do I re-encode a file into a 10-bit hevc file? [06:36:42 CEST] <Oleg_> I typed: [06:36:45 CEST] <Oleg_> ffmpeg -i input.mkv -c:v libx265 -c:a copy -max_muxing_queue_size 400 file.mkv [06:37:03 CEST] <Oleg_> but I think it's re-encoding it into a 8-bit hevc file [06:37:16 CEST] <lain98> Oleg_: ffmpeg -i pix_fmts. pick one of the 10 bit formats [06:37:47 CEST] <lain98> such as yuv420p10be i think [06:39:22 CEST] <Oleg_> lain98, what do you mean? ffmpeg -i input.mkv followed by what? [06:41:00 CEST] <lain98> ffmpeg -i input.mkv -pix_fmt yuv420pb10e output.mkv [06:42:10 CEST] <lain98> if your file had 8 bit format then just transcode to 10 bit wont magically increase the bit depth [06:42:18 CEST] <lain98> its still the same information [06:42:34 CEST] <lain98> using more bytes [06:43:50 CEST] <Oleg_> I am trying to transcode a 10-bit h264 file into a 10-bit hevc file [06:44:08 CEST] <lain98> Oleg_: then it should work imho [06:44:36 CEST] <Oleg_> I got the message: Unknown pixel format requested: yuv420pb10e [06:44:37 CEST] <lain98> Oleg_: tbh i dont think you even need to specify the pix_fmt [06:45:03 CEST] <lain98> Oleg_: its 10be [06:45:05 CEST] <lain98> not b10e [06:45:25 CEST] <lain98> also check the pix_fmt in your h264 file first [06:47:07 CEST] <Oleg_> yuv420p10be ? [06:47:49 CEST] <lain98> yes [06:48:08 CEST] <lain98> ffmpeg -pix_fmts shows you all the pix_fmts that ffmpeg supports [06:50:21 CEST] <Oleg_> it says "yuv420p10be 3 15" [06:50:51 CEST] <Oleg_> why does it say 15 BITS_PER_PIXEL for yuv420p10be? [06:51:08 CEST] <lain98> because its 420 [06:51:30 CEST] <lain98> uv planes are half of y [06:51:50 CEST] <Oleg_> but it definitely stands for 10-bit transcoding? [06:52:09 CEST] <lain98> y=10 bits and u+v=5 bits [06:52:41 CEST] <lain98> Oleg_: whats the pix_fmt of your h264 file [06:53:00 CEST] <Oleg_> ffmpeg pix_fmt input.mkv ? [06:53:55 CEST] <furq> ffprobe -show_entries stream=pix_fmt input.mkv [06:54:47 CEST] <lain98> Oleg_: dont think you need to bother about pix_fmt. just trancode the file [06:54:54 CEST] <Oleg_> pix_fmt=yuv420p10le [06:55:03 CEST] <Oleg_> that's the output I got [06:55:07 CEST] <Oleg_> from ffprobe [06:55:16 CEST] <furq> use that then [06:56:02 CEST] <Oleg_> if the file has yuv420p10le pix_fmt, that means I gotta use yuv420p10le for transcoding, not yuv420p10be? [06:56:14 CEST] <furq> either should work but le will be slightly faster [06:56:28 CEST] <furq> no point shuffling bits around if you don't need to [06:57:11 CEST] <lain98> q [06:57:30 CEST] <lain98> sorry i thought i was exiting vim [06:57:34 CEST] <lain98> :D [06:57:42 CEST] <Oleg_> if I type [06:57:46 CEST] <Oleg_> ffmpeg -i input.mkv -pix_fmt yuv420p10le -c:v libx265 -c:a copy file.mkv [06:57:57 CEST] <Oleg_> will I lose some video quality in the resulting file? [06:58:02 CEST] <furq> yes [06:58:21 CEST] <furq> if you don't want to lose quality then don't transcode it [06:58:57 CEST] <lain98> why will he lose quality ? [06:59:16 CEST] <lain98> if its the same pixel format and depth [06:59:29 CEST] <furq> because he's transcoding [06:59:34 CEST] <lain98> just different codec ? [06:59:48 CEST] <lain98> oh yeah encoding isnt perfect [07:00:35 CEST] <furq> Oleg_: you'll want to set -crf and -preset to suit your needs [07:00:48 CEST] <furq> you will always lose quality but with a low enough crf value you won't notice [07:01:21 CEST] <lain98> dont think its much either way [07:01:30 CEST] <Oleg_> what's the lowest possible -crf value? [07:01:35 CEST] <furq> 0 [07:02:01 CEST] <furq> encode a test clip at 20 and then tune it from there [07:04:04 CEST] <furq> if the source is hi10p then i assume you also want -tune animation [07:07:29 CEST] <Oleg_> furg, I am re-encoding the file that was already re-encoded with hi10p [07:23:43 CEST] <Oleg_> anyway, thanks, guys [08:32:25 CEST] <lain98> if i have a variable frame rate stream. do avformat_seek_file or av_seek_frame seek to the correct frame ? [08:33:11 CEST] <JEEB> they both work with time [08:33:22 CEST] <JEEB> so as long as your input is actually seekable and indexed, they should be OK [08:33:28 CEST] <lain98> theres flag option that allow to send frame number too [08:33:31 CEST] <JEEB> if your input is not indexed (like mpeg-ts) [08:33:37 CEST] <JEEB> then index it :P [08:34:26 CEST] <lain98> i want to seek somewhere in the middle of a stream and decode n frames from frame number x onwards. [08:34:39 CEST] <lain98> so i seek to the key frame before frame x [08:34:46 CEST] <JEEB> see ffms2, that handles indexing [08:34:51 CEST] <lain98> and then i decode from key frame to next keyframe [08:35:24 CEST] <lain98> vfr sort of breaks this logic and i cant see why [08:35:51 CEST] <lain98> JEEB: that kind of defeats the whole purpose of only wanting to decode some frames. i dont need the whole file [08:36:16 CEST] <JEEB> you don't need to *decode* the whole thing [08:36:20 CEST] <JEEB> that's not what indexing means [08:36:51 CEST] <JEEB> you go through the whole thing once on the *container* level [08:36:55 CEST] <JEEB> then you have an index [08:37:36 CEST] <JEEB> lain98: also not sure but I wouldn't be surprised if the "frame" seek just converts that to time :P [08:37:44 CEST] <lain98> the AVSEEK_FLAG_FRAME doesnt seem accurate under vfr [08:37:49 CEST] <JEEB> which in case of VFR ends up incorrect [08:37:53 CEST] <lain98> yeah [08:38:08 CEST] <JEEB> if you want frame based accurate seeking it sounds like you want ffms2 [08:38:16 CEST] <JEEB> if you don't want to even look at it, sure fine [08:38:43 CEST] <lain98> i saw a patch in some other software. they like go through all key frames and index the byte position [08:39:02 CEST] <lain98> then seek to whatever keyframe corresponds to a frame number [08:39:12 CEST] <JEEB> that sounds like ffms2 [08:39:19 CEST] <JEEB> but sure, have fun [08:40:04 CEST] <lain98> the performance impact of indexing might like defeat the whole purpose of my application [08:40:18 CEST] <JEEB> that's mostly IO [08:40:30 CEST] <lain98> thats why i wanted to have some sort of hack instead of indexing [08:41:33 CEST] <lain98> like ill have to index 10000 frames to decode 5 frames [08:42:01 CEST] <JEEB> I would actually first see if it's really too much overhead to get things right [08:42:16 CEST] <JEEB> since as I noted it's not about decoding, it's about container level indexing [08:42:23 CEST] <JEEB> if it's really too much, then OK [08:42:28 CEST] <lain98> hmm. ill check [08:42:31 CEST] <lain98> thanks JEEB [08:47:50 CEST] <pk08> hi guys, [08:47:51 CEST] <pk08> since JEEB is in this chat and my problem is related to ffmpeg and mpv player so i decided to post here instead of mpv channel. [08:47:51 CEST] <pk08> i am using cuda-copy as hardware decoder and its using cuviddec.c module. [08:47:51 CEST] <pk08> now I want to use different gpu but by default it using gpu 0 even if i pass --vd-lavc-o=gpu=1! [08:47:51 CEST] <pk08> can anyone help me to find a way to use different gpu? [08:47:56 CEST] <pk08> mpv command: https://pastebin.com/5y9mjVXi [08:47:59 CEST] <pk08> log file: https://pastebin.com/tG0CLWpq [08:49:58 CEST] <JEEB> well your problem is not necessarily related to FFmpeg, I listed you the possibilities in #mpv before [08:51:04 CEST] <JEEB> depends on 1) if that lavc option setting actually passes the option to the hwaccel decoder context 2) if the hwaccel has that option that is actually being utilized [08:51:18 CEST] <JEEB> anyways, I'm at $dayjob and can't exactly give thorough help right now :P [08:57:18 CEST] <pk08> sorry i was disconnected for few mins [08:57:32 CEST] <pk08> did anyone reply to my question? [09:00:03 CEST] <Diag> pk08: did you catch http://tyronesbeefarm.com/images/2019c7f26142-0f17-4adb-b3fb-b3290bea7b6a.p… [09:00:19 CEST] <Diag> ima assume that was related to you [09:02:29 CEST] <pk08> Diag: yes, but i dont see lavc passed to hardware decoder in log file [09:03:07 CEST] <pk08> so i dont see anything related to gpu setting option in log [09:43:58 CEST] <lavalike> how to accurately calculate the duration of an aac file? ffprobe tells me it just does an approximation (and the resulting file plays quite a while longer than what's reported by the app playing it) [11:58:38 CEST] <DHE> lavalike: the only sure way is to read the whole thing. otherwise duration is estimated by assuming a constant bitrate and reading a bit to get a bitrate estimate. [13:22:25 CEST] <lavalike> DHE: can I ask ffprobe or another program to do that? [13:23:56 CEST] <JEEB> -show_frames or -show_packets [13:24:06 CEST] <JEEB> then you calculate [13:24:19 CEST] <JEEB> -show_frames decodes, -show_packets is container level [13:29:34 CEST] <GuiToris> hey, I'd like some advice. The majority of my clips are in 29.97 fps and I have a clip from an other source which is 25fps interlaced. I don't know what to do [13:29:58 CEST] <GuiToris> I'm about to deinterlace it with nnedi but which framerate should I choose? [13:30:11 CEST] <GuiToris> should I keep 25 or should I make it 50? [14:31:18 CEST] <lofo> Hey, i'm learning libav by reproducing the remuxing example (https://ffmpeg.org/doxygen/3.3/remuxing_8c-example.html) I get an error on a call to av_interleaved_write_frame : [mpegts @ 0x16f00f728] Packet with invalid duration -9223372036854775808 in stream 0 [14:31:26 CEST] <lofo> For some reason my outputStream's timebase is 0/0... But i cant find in the documentation at which point the timebase is set [14:31:35 CEST] <lofo> should i set the time_base manually ?! but in the example there is no such thing [14:36:57 CEST] <JEEB> you should set it so that the container knows what you'd prefer but then various containers will override you (like MPEG-TS) [14:37:10 CEST] <JEEB> so with MPEG-TS you should get 1/90000 [14:37:16 CEST] <JEEB> and FLV would be 1/1000 [14:41:58 CEST] <lofo> just solved it myself! indeed MPEG-TS gives 1/90000 [14:42:11 CEST] <lofo> i held bad refs to my output streams [14:42:16 CEST] <JEEB> :) [14:42:47 CEST] <lofo> thanks JEEB :) [14:50:03 CEST] <GuiToris> JEEB, can you help me? [14:50:12 CEST] <GuiToris> you must know what I should do [15:10:53 CEST] <DHE> GuiToris: the deinterlacer should be setting its own time_base [15:11:21 CEST] <GuiToris> DHE, but the original is 25 fps [15:11:27 CEST] <GuiToris> it'll never be 29.97 [15:11:45 CEST] <GuiToris> the timeline framerate is going to be 29.97 too [15:12:28 CEST] <GuiToris> I'm afraid the clip will be jerky [15:45:51 CEST] <GuiToris> what do you think about this one : $ ffmpeg -i input -vf nnedi=weights=/usr/lib/vapoursynth/nnedi3_weights.bin:field=af,fps=fps=30000/1001 output ? [15:47:52 CEST] <GuiToris> or should I keep all the 50 frames per sec and let premiere throw them away itself? [15:56:04 CEST] <YellowOnion> Is the "unscaled special converter" meant to look ugly as hell? how do I turn it off... [16:09:40 CEST] <durandal_1707> YellowOnion: post full logs [16:12:05 CEST] <YellowOnion> https://gist.github.com/YellowOnion/f214289c42a4b9e130136d167074c2d3 [16:12:25 CEST] <YellowOnion> line 61 [16:13:26 CEST] <YellowOnion> What is the actual problem is that both Kodi and VLC use this ugly scaler and it's been driving me nuts for years. [16:14:27 CEST] <kepstin> your original video is subsampled (chroma is 1/2 height and 1/2 width), so it's upscaling the chrome with bicubic, a perfectly reasonable option, then performing the yuv to rgb conversion [16:15:04 CEST] <kepstin> if it looks bad, it's because the original video looked bad, for example maybe it has some sharp color edges that can't be represented properly by subsampled chroma. [16:15:14 CEST] <YellowOnion> kepstin, it's not upscaling it with bicubic...bicbuic doesn't make it look like pixelated junk. [16:15:58 CEST] <kepstin> YellowOnion: the scaler isn't the problem, your video just looks bad. [16:16:15 CEST] <kepstin> probably :) [16:16:20 CEST] <YellowOnion> kepstin, why does it look better with a different player? https://imgur.com/a/R9ZWhiT [16:17:09 CEST] <durandal_1707> unscaled scaler is just doing yuv to rgb [16:17:28 CEST] <durandal_1707> but see line above [16:17:42 CEST] <durandal_1707> it uses mmxext [16:17:50 CEST] <YellowOnion> If I enable DXVA in Kodi it look better as well, because ffmpeg is using nearest neighbour [16:17:52 CEST] <durandal_1707> it is 2019 [16:18:19 CEST] <durandal_1707> yes it uses crappy fast scaler [16:18:34 CEST] <durandal_1707> use zscale instead [16:18:50 CEST] <durandal_1707> swscale is piece of crap [16:18:58 CEST] <kepstin> YellowOnion: i wonder if the other player is doing some additional deblocking/post-processing too [16:20:03 CEST] <YellowOnion> It' just a different render method. VLC on "software" does it as well, because it ALSO uses ffmpeg's scaler... [16:20:45 CEST] <durandal_1707> ffmpeg scaler is prahistoric [17:45:10 CEST] <lavalike> JEEB: neat, that works, by adding up the pkt_duration_time! [18:23:56 CEST] <JEEB> lavalike: great [22:01:37 CEST] <SpeakerToMeat> Hello all.... [22:02:24 CEST] <SpeakerToMeat> question, if I have stream 0:0 (video) and stream 1:0 (audio) is there any way to combine both into a file so that stream 0:0 (video) which is shorter is looped the right ammount of times to cover the whole length of stream 1:0? [22:02:58 CEST] <SpeakerToMeat> Aaaand, as usual, after googling, I finally find a question in stackexchange right after I ask... [22:04:30 CEST] <SpeakerToMeat> But, the answer doesn't seem right [22:05:53 CEST] <kepstin> i'd think it should be sufficient to use the `-stream_loop -1` input option on the video stream, combined with the `-shortest` output option [22:12:14 CEST] <SpeakerToMeat> Ok that one didn't work [22:12:54 CEST] <kepstin> please pastebin the command line that you ran and the complete console output. [22:13:09 CEST] <SpeakerToMeat> And this one: ffmpeg -stream_loop -1 -i vid.mp4 -c copy -v 0 -f nut - | ffmpeg -thread_queue_size 10K -i - -i sound.aac -c copy -map 0:v -map 1:a -shortest -y tomvid.mp4 [22:13:21 CEST] <SpeakerToMeat> kidn of works, but at the moment where the video must loop, it gets stuck on a frame [22:13:30 CEST] <SpeakerToMeat> which gets unstuck if I ff the player [22:13:52 CEST] <kepstin> hmm, yeah, it's probably a bad interaction between copy mode and the stream loop option [22:14:11 CEST] <SpeakerToMeat> probably better to reencode... [22:15:21 CEST] <SpeakerToMeat> I also tried this: ffmpeg -stream_loop -1 -i vid.mp4 -i sound.aac -c copy -map 0:v -map 1:a -shortest -y tomvid.mp4 but the output video is the length of the shortest (the video) and the soudn gets cut [22:15:43 CEST] <kepstin> it might be possible to use the concat demuxer for this - create a playlist file that just has the same video a bunch of times, then use that as an input. [22:16:02 CEST] <SpeakerToMeat> Hmmmm [22:16:37 CEST] <kepstin> i suspect that might have a better chance of working with -c copy, too. [22:16:53 CEST] <SpeakerToMeat> I don't mind reencoding if that'll help [22:23:13 CEST] <SpeakerToMeat> Hmm ok reencoding on the receive rin th epipe still has the stuck frame, reencodign on the sender fails [22:25:02 CEST] <SpeakerToMeat> Maybe... [22:25:34 CEST] <SpeakerToMeat> Sigh if I use the single line: ffmpeg -stream_loop -1 -i ../Downloads/20190827_063046.mp4 -i mod.aac -c copy -map 0:v -map 1:a -shortest -y tomvid.mp4 [22:25:57 CEST] <SpeakerToMeat> the end result cuts on the video length (shortest) it's like the length beign use is the original video, not the looped one [22:26:14 CEST] <SpeakerToMeat> I even tried setting loop to a long value (30) instead of -1, same thing [22:27:34 CEST] <SpeakerToMeat> I'll drop this on kdenlive for now [22:29:39 CEST] <SpeakerToMeat> Maybe if I use the loop filter [22:30:21 CEST] <SpeakerToMeat> But I'm unsure how ot combien this with a 2 file input... [22:31:20 CEST] <SpeakerToMeat> I need to do something like this I guess? -filter_complex "[0:v]loop=loop=30[outvid]" -map outvid -map 1:a [22:31:38 CEST] <SpeakerToMeat> that with -shortest for output... [22:33:30 CEST] <SpeakerToMeat> sigh [22:33:51 CEST] <SpeakerToMeat> c:v h264 is slow. I wonder if I can get nvenc to work, and get decent quality from it [22:34:43 CEST] <SpeakerToMeat> aaarrrrgh... even with this it still outs to the length of the video like it were not looped [22:34:54 CEST] <SpeakerToMeat> I think concat.... [22:35:15 CEST] <SpeakerToMeat> kepstin: but if I use a concat demux... do I need to pipe this to another instance to mix with the audio? [22:35:29 CEST] <kepstin> no, there's no reason to use 2 instances at all [22:36:30 CEST] <SpeakerToMeat> How would I do this with the concat demuxer then? to map only the video form the concat and the aduio from the other file... [22:36:31 CEST] <SpeakerToMeat> let me google [22:37:02 CEST] <kepstin> ffmpeg -f concat -i playlistfile -i audio.aac -map 0:v -map 1:a <output options> [22:39:08 CEST] <SpeakerToMeat> thanks, let's try that [22:45:36 CEST] <SpeakerToMeat> It stopped at 9 minutes :/ [22:50:47 CEST] <SpeakerToMeat> Oh it worked with concat... [22:51:15 CEST] <SpeakerToMeat> only, the audio said 20 minutes in ffprobe... but it's actually 9 minutes, which is what was output [22:51:36 CEST] <SpeakerToMeat> So I was expecting more. [22:51:40 CEST] <kepstin> raw aac doesn't store the length anywhere, so ffprobe can't read it accurately [22:51:56 CEST] <kepstin> i think it just makes a guess based on the bitrate near the start of the file [22:51:56 CEST] <another> that's exactly what i suspected [22:52:14 CEST] <kepstin> which in vbr is usually pretty low, so it often guesses too long. [22:52:36 CEST] <another> is there any specific reason why you have raw aac? [22:55:14 CEST] <SpeakerToMeat> That makes sense [22:55:24 CEST] <SpeakerToMeat> so raw aac is sort of like raw pcm in that [22:55:37 CEST] <another> kinda [22:55:50 CEST] <SpeakerToMeat> only pcm is cbr [22:56:03 CEST] <kepstin> raw pcm isn't vbr, it's always an exact number of bits per second, so you can calculate duration exactly from file length. [22:56:20 CEST] <SpeakerToMeat> Yep [22:56:28 CEST] <FooNess> (Assuming "raw PCM" here means just that, without any metadata and container overhead.) [22:56:33 CEST] <kepstin> assuming you know the sample format, sample rate, and number of channels somehow :) [22:56:48 CEST] <SpeakerToMeat> kepstin:You can always start moltiplying/dividing to try and guess ;) [22:56:53 CEST] <SpeakerToMeat> multiplying [23:26:07 CEST] <GuiToris> so are there any suggestions what I should do with my 25fps clip on a 29.97 timeline? [23:30:04 CEST] <pink_mist> use a format that allows vfr and stop worrying? [23:31:59 CEST] <GuiToris> pink_mist, the thing is I need to deinterlace the clip first and I have the opportunity to double the framerate to 50. The actual question is if I should do this or not [23:32:52 CEST] <GuiToris> I've been thinking about this: $ ffmpeg -i input -vf nnedi=weights=/usr/lib/vapoursynth/nnedi3_weights.bin:field=af,fps=fps=30000/1001 output [23:34:17 CEST] Action: kepstin would probably use bwdif rather than nnedi for general content [23:34:57 CEST] <furq> is ffmpeg nnedi usable yet [23:35:08 CEST] <furq> i'm guessing it's still appallingly slow unless someone added frame threading to lavfi [23:35:18 CEST] <kepstin> in theory, you should have slightly less judder going from 50fps to 30/1.001 than from 25 to 30/1.001 [23:35:34 CEST] <furq> it's not going to be great either way but i guess it's better to start with 50 [23:36:11 CEST] <kepstin> use the fps filter to convert to 30/1.001 fps, it has better rounding behaviour than the -r output option [23:36:19 CEST] <GuiToris> should I specify fps=fps=30000/1001, or should i let premier throw away the extra frames? [23:36:32 CEST] <furq> well if you do it with ffmpeg then you can preview it [23:36:53 CEST] <kepstin> i have no idea how premier works, but it's probably not any better than the fps filter [23:36:53 CEST] <furq> i would try with bwdif=1 and bwdif=0 and see which looks better [23:37:04 CEST] <kepstin> (it might be worse) [23:37:24 CEST] <furq> bwdif vs nnedi isn't going to make it more or less juddery [23:37:31 CEST] <GuiToris> isn't nnedi superior to bwdif? [23:37:38 CEST] <furq> yes but they both work in the same way [23:37:41 CEST] <furq> nnedi just uses a better upscaler [23:37:55 CEST] <furq> any judder will be the same for both [23:38:01 CEST] <kepstin> nnedi is just *really slow* in ffmpeg, so you should test with a faster filter [23:38:07 CEST] <furq> yeah mostly that [23:38:15 CEST] <furq> also maybe consider using nnedi through vapoursynth so you can at least multithread it [23:38:32 CEST] <furq> also i think the implementations there are just faster in general (definitely if you have a fast gpu) [23:39:00 CEST] <GuiToris> the speed is not that important now, I'll leave my computer do it all night [23:39:01 CEST] <kepstin> iirc there isn't even any simd in the ffmpeg filter [23:39:25 CEST] <kepstin> you should test it with a fast filter to compare which method looks better [23:39:27 CEST] <furq> GuiToris: do whatever you want for the final export, i'm just suggesting bwdif for previewing [23:39:50 CEST] <furq> any method of deinterlacing and then converting to 30fps will exhibit the same issues [23:40:33 CEST] <GuiToris> :/ got it [23:40:38 CEST] <GuiToris> thank you so much for your help :) [23:41:02 CEST] <kepstin> hmm, someone wrote an opencl port of nnedi3, and it's lgpl3 [23:41:08 CEST] <furq> yeah it's pretty good [23:41:13 CEST] <furq> i use that one in vs [23:41:25 CEST] <furq> there's also znedi3 from the zimg guy [23:41:44 CEST] <furq> i assume the opencl one will suffer less from not having frame threading though [23:41:47 CEST] <kepstin> i should try to get opencl working on one of my systems. [23:44:06 CEST] <kepstin> i guess on radeon stuff i want to use rocm. [23:48:05 CEST] <furq> that or amdgpu-pro [23:49:04 CEST] <furq> iirc you can install the amdgpu-pro opencl stuff alongside the oss driver [23:49:27 CEST] <furq> but if rocm is good now then that's probably less hassle [00:00:00 CEST] --- Wed Aug 28 2019

1 0

ffmpeg.log.20190825
by burek 26 Aug '19

26 Aug '19

[01:08:55 CEST] <dastan> hello people [01:09:24 CEST] <dastan> i created a script with ffmpeg and youtube-dl [01:09:50 CEST] <dastan> The script: https://pastebin.com/RM0cmbNz [01:09:57 CEST] <DHE> what's it do? [01:10:21 CEST] <dastan> it takes a youtube link [01:10:39 CEST] <dastan> get the HLS Link with youtube-dl [01:10:49 CEST] <dastan> insert in a variable [01:11:07 CEST] <dastan> and then send a command with FFMPEG [01:11:10 CEST] <BtbN> Since when does YouTube not use DASH anymore? [01:11:15 CEST] <dastan> but it gives me an error [01:11:30 CEST] <BtbN> Same questions from earlier still apply. [01:11:39 CEST] <DHE> I've seen HLS for live streams, and sometimes videos that were generated from live streams... [01:11:44 CEST] <DHE> at last historically.. [01:11:47 CEST] <DHE> *least [01:11:56 CEST] <nicolas17> what does it do *at a higher level*? [01:12:10 CEST] <BtbN> Also why are you trying to make hls with raw pcm? [01:12:18 CEST] <BtbN> Why are you not just copying the original data? [01:12:29 CEST] <BtbN> Why are you not giving any quality parameters to nvenc? [01:12:49 CEST] <nicolas17> looks like you're converting from HLS to HLS [01:13:30 CEST] <dastan> i am creating a local cache [01:13:32 CEST] <BtbN> Also, why are you not just letting youtube-dl download it? That's its job after all. [01:13:40 CEST] <nicolas17> dastan: why transcode then? [01:13:53 CEST] <DHE> also youtube-dl will call ffmpeg when it needs help [01:14:11 CEST] <nicolas17> you're re-encoding the video in undefined quality and uncompressing the audio [01:14:15 CEST] <FooNess> It's why I have ffmpeg.exe in the same folder as youtube-dl.exe in Windows. [01:14:33 CEST] <BtbN> youtube-dl.exe oO [01:14:37 CEST] <BtbN> now that sounds shady [01:14:40 CEST] <FooNess> ? [01:14:43 CEST] <BtbN> It [01:14:46 CEST] <FooNess> It's a Windows binary ... [01:14:46 CEST] <BtbN> It's a python script. [01:14:46 CEST] <DHE> there is such thing as py2exe [01:14:53 CEST] <DHE> last time I used it was... 2004 maybe? [01:14:54 CEST] <FooNess> .exe is the standard extension for binaries on Windows. [01:15:01 CEST] <FooNess> Why would it be shady? [01:15:01 CEST] <dastan> to then insert it in a SDI device with a second ffmpeg process and with a third ffmpeg process i will create a mov video wirh prores, that is the fmate we use in my company [01:15:01 CEST] <BtbN> It's not a binary though [01:15:05 CEST] <FooNess> It conveniently invokes it when it needs it to put two "incompatible" codecs together. [01:15:41 CEST] <dastan> the problem is that i am getting this error and i dont know why [01:15:48 CEST] <nicolas17> you never said what the error was [01:15:59 CEST] <FooNess> What is "this error"? [01:16:07 CEST] <FooNess> I scrolled up and I can't see you discussing an error. [01:16:09 CEST] <Aerroon> are there any tools that i can feed a video into that will find "weird" frames? ie all red or like >90% pure red or pure green or pure black for multiple seconds [01:16:19 CEST] <Aerroon> basically, frames that show some kind of encoding or other error [01:16:41 CEST] <dastan> "No such file or directory". [01:17:08 CEST] <nicolas17> hlslink=$(echo \"$(youtube-dl -f 95 -g $ylink)\") what the hell is that [01:17:08 CEST] <FooNess> dastan, can you show the whole input and ouput (use a pastebin) [01:17:12 CEST] <BtbN> So if you are using the thing you download as a master for transcoding afterwards. There is zero point to transcoding it right there [01:17:17 CEST] <BtbN> that only kills quality for no good reason [01:17:20 CEST] <nicolas17> why not hlslink=$(youtube-dl -f 95 -g $ylink) [01:18:14 CEST] <dastan> i will run the command with my computer, i need to change some things because i dont have nvidia card in my cmputer [01:18:48 CEST] <BtbN> Again, why are you transcoding at all? [01:19:07 CEST] <nicolas17> just let youtube-dl download the whole video and then feed that to the rest of your chain [01:19:08 CEST] <furq> lol [01:19:11 CEST] <furq> this is going well [01:19:15 CEST] <BtbN> Specially with nvenc, all that does is wreck quality. [01:19:47 CEST] <dastan> furq: no, because i want to create a local HLS repository [01:20:05 CEST] <dastan> i am downloading a the video only to make a local cache [01:20:08 CEST] <nicolas17> use -c:v copy -c:a copy [01:20:31 CEST] <dastan> all what i am doing has four months of research and like 100 hours of tests [01:20:56 CEST] <dastan> does someone saw the error? [01:21:23 CEST] <nicolas17> why not "hlslink=$(youtube-dl -f 95 -g $ylink)"? maybe that's the problem, you're feeding quote signs to ffmpeg -i [01:22:27 CEST] <dastan> nicolas, because the HLS link are hughe, and you need to passthrough the hls link with wuotes, if not can get a extrange reaction of ffmpeg, sometimes it works, sometimes not [01:22:45 CEST] <nicolas17> ffmpeg doesn't interpret quotes [01:22:46 CEST] <nicolas17> your shell does [01:22:57 CEST] <nicolas17> but it won't if the quotes are in the variable value [01:23:22 CEST] <dastan> if i send the command without a script it works fine [01:23:34 CEST] <nicolas17> you mean if you send ffmpeg -i "https://..."? [01:23:40 CEST] <dastan> yep [01:23:42 CEST] <nicolas17> yes because then your shell interprets the quotes [01:23:43 CEST] <dastan> try it [01:24:35 CEST] <nicolas17> I guess if you don't use quotes in an interactive shell, the & gets interpreted as backgrounding [01:25:08 CEST] <analogical> how do I remove the title from an mkv file? [01:25:31 CEST] <nicolas17> if you want to be safe against symbols and even spaces in the URL (which shouldn't happen), do this https://pastebin.com/Gzq67K8B [01:25:59 CEST] <dastan> ffmpeg -hide_banner -hwaccel cuvid -c:v h264_cuvid -f hls -i "YOUTUBE-HLS-LINK -c:v h264_nvenc -r 50 -acodec pcm_s16le -ac 2 -ar 48000 -f hls -hls_list_size 0 /home/build/temp/tn/tn.m3u8 [01:26:16 CEST] <dastan> replace the nvenc and cuvid with compatible codecs in your pc [01:26:48 CEST] <nicolas17> ffmpeg -i "foo" is not the same as ffmpeg -i $var where var contains quotes in its value [01:26:56 CEST] <dastan> and you can get then HLS link with youtube-dl -f 95 -g "youtube.live-link" [01:27:55 CEST] <dastan> i have another command [01:28:02 CEST] <dastan> ffmpeg -hide_banner -hwaccel cuvid -c:v h264_cuvid -f hls -i $(youtube-dl -f 95 -g "https://www.youtube.com/watch?v=-1xif50QMr4") -c:v h264_nvenc -r 50 -c:a pcm_s16le -ac 2 -ar 48000 -f hls -hls_list_size 0 /home/catalan63/Escritorio/m3u8/tn/tn.m3u8 [01:28:22 CEST] <nicolas17> yep that should work too [01:29:19 CEST] <dastan> this one works fine in the shell, bu when you put in a shellscript sometimes gives errors, and is because the HLS link can have things like && or // [01:29:59 CEST] <nicolas17> did you even look at my pastebin [01:30:51 CEST] <dastan> i am accessing right now [01:30:54 CEST] <Classsic> hi, where can upload images to share here? [01:31:45 CEST] <dastan> without ()? [01:32:08 CEST] <nicolas17> without the echo thing [01:32:34 CEST] <nicolas17> your whole problem is more suitable for #bash tbh :P [01:32:34 CEST] <dastan> i need the () because i need to send the command to the background [01:32:56 CEST] <dastan> ok, but i tested without the echo [01:32:58 CEST] <nicolas17> you're not sending any command to the background in your script [01:34:11 CEST] <dastan> no in this one, this is a small part of another one that is bigger [01:36:15 CEST] <dastan> i will try without the echo again [01:37:52 CEST] <dastan> need to connect to the VPN of my company and i will lost connection with irc [01:38:05 CEST] <dastan> i come back in a few seconds [01:39:02 CEST] <nicolas17> furq: at least he got a quick reply and didn't need to highlight everyone [01:39:05 CEST] <nicolas17> *cough* [02:12:58 CEST] <Classsic> hi, is there a way to get multiple inputs streams an get only one output streams, only mapped as channel [02:14:23 CEST] <klaxa> like this? https://trac.ffmpeg.org/wiki/AudioChannelManipulation [02:15:04 CEST] <Classsic> yes, but I need video [02:16:05 CEST] <klaxa> you can just use -map then to map multiple video streams into one file [02:16:34 CEST] <klaxa> your player should then show you that there are two video tracks available and you should be able to switch it [02:16:57 CEST] <klaxa> like so: ffmpeg -i one.mp4 -i two.mp4 -map 0 -map 1 both.mp4 [02:17:02 CEST] <klaxa> note that this ignores audio channels [02:17:26 CEST] <klaxa> this would just also add both audio streams as streams in the final video [02:17:47 CEST] <klaxa> so if both have one video and one audio stream you end up with two video and two audio streams in both.mp4 [02:18:56 CEST] <Classsic> yes, but I need stream ouptut [02:19:03 CEST] <Classsic> like this: ffmpeg -i rtmp://localhost/live/grid -i rtmp://localhost/live/grid -vcodec libx264 -f flv rtmp://localhost/live/grid2 [02:19:19 CEST] <Classsic> doesn`t work. [02:19:35 CEST] <klaxa> flv doesn't support more than one video at once, i guess you want hstack or vstack then [02:19:59 CEST] <Classsic> but I get problem with video sync [02:20:18 CEST] <klaxa> yeah i would have thought so [02:21:13 CEST] <Classsic> yes, I stay looking for a solution, for 3 days, and found some patch, but donŽt work very well [02:22:24 CEST] <klaxa> well, live-streaming, low-latency and synchronization just happen to be some of the hardest things to get right [02:23:01 CEST] <Classsic> yes, I see :( [02:25:14 CEST] <Diag> damn [02:27:33 CEST] <Classsic> my best try was this https://gist.github.com/Classsic/49b00d4e68dc54a342f54a6cffb0823f [02:41:44 CEST] <Diag> huh, im getting weird framerate shifts with ffmpeg but im not seeing it whine about frames dropped [02:42:02 CEST] <Classsic> dropping frame 581 from stream 0 at ts 12533548472 [02:42:10 CEST] <Diag> me, not you lol [02:42:38 CEST] <Classsic> what level log use? [02:43:02 CEST] <Diag> whatever is normal [02:44:27 CEST] <Classsic> I get this from verbose level [02:44:46 CEST] <Classsic> not really, just press + key [02:49:32 CEST] <Classsic> adding -copytb 1 on the output parameters, is smoother, but still not smooth. [02:55:54 CEST] <Diag> this is confusing as hell [02:56:02 CEST] <Diag> http://tyronesbeefarm.com/images/201922ea2b14-0e80-47b6-b56e-0b62a373dcd2.m… [02:56:10 CEST] <Diag> it starts off so butter smooth then just goes to hell [02:58:53 CEST] <Diag> its like its running in and out of sync with the screen [03:38:47 CEST] <Classsic> somebody have example with -use_wall_clock_as_timestamp? [04:49:37 CEST] <cpusage> If it states x265 [info]: HEVC encoder version 2.6+13-6b079854e56e [04:50:06 CEST] <cpusage> does it mean that ffmpeg 4.2 (current stable version) is utilizing x265 v2.6, and not the most recently releases v3.1? [04:50:50 CEST] <furq> yes [04:52:03 CEST] <nicolas17> cpusage: I assume it uses whatever x265 you compiled it with... are you using official binaries? [04:52:16 CEST] <furq> there are no official binaries [04:52:40 CEST] <cpusage> I just grabbed the most recent stable ffmpeg release [04:52:51 CEST] <nicolas17> then it's not "ffmpeg 4.2 uses x265 2.6" but "your particular compiled binary of 4.2, wherever you got it, uses x265 2.6" :P [04:53:16 CEST] <furq> it sure is [04:53:18 CEST] <cpusage> ffmpeg.org :/ [04:54:16 CEST] <nicolas17> "Linux Static Builds"? [04:54:23 CEST] <furq> the linux and windows builds both have 3.1 [04:55:56 CEST] <cpusage> hm, that's weird, (currently on win 10) [04:56:20 CEST] <furq> x265 [info]: HEVC encoder version 3.1+11-de920e0a3183 [04:56:24 CEST] <furq> is what i get with zeranoe 4.2 [04:56:37 CEST] <cpusage> I deleted the old ffmpeg folder and replaced it with 4.2 [04:56:47 CEST] <cpusage> I must have the old binaries somewhere else then [04:56:59 CEST] <furq> ffmpeg -version [04:57:54 CEST] <cpusage> yep, it's the old one. can't recall where I placed the binaries then. I was under the impression it was simply located c:\ffmpeg [04:58:21 CEST] <nicolas17> does modern windows have an equivalent to 'which'? :/ [04:58:37 CEST] <furq> https://www.voidtools.com/faq/ [04:58:39 CEST] <nicolas17> or do you have to check each PATH entry by hand? [04:58:40 CEST] <cpusage> ffmpeg [04:58:40 CEST] <furq> no but it has that [04:59:00 CEST] <furq> which works in msys though [04:59:48 CEST] <nicolas17> "A fresh install of Windows 10 (about 120,000 files) will take about 1 second to index." wtf how [05:00:11 CEST] <furq> "Everything" requires administrative privileges for low level read access to NTFS volumes for NTFS indexing. [05:00:23 CEST] <furq> sadly it only works on ntfs so it's no good for network drives [05:01:30 CEST] <furq> actually i guess it also works on refs since i ill-advisedly have a refs raid1 in my desktop [05:02:32 CEST] <cpusage> found it :) thanks [05:03:32 CEST] <cpusage> x265 [info]: HEVC encoder version 3.1+11-de920e0a3183 [05:03:38 CEST] <cpusage> :D [05:04:56 CEST] <cpusage> any idea why I get drop=x , which I assume are dropped frames, when I'm simply transcoding a h264 vid to h265? [05:05:23 CEST] <cpusage> does it indicate issues with the source (h264)? [09:27:05 CEST] <poutine> If you were de-packetizing MPEG TS packets into elementary streams, With video PES packets, it can say 0 for the PES packet length in the header, I get that if you see another packet in that PID with PUSI set, that you can assume the last PES packet has been fully assembled, but is there a way to determine that otherwise? [10:31:33 CEST] <rtwld> hi to all. I've downloaded ffmpeg-git-20190821-amd64-static, and i'd like to ask why there isn't ffplay [10:48:18 CEST] <durandal_1707> rtwld: you downloaded only source? [11:02:59 CEST] <rtwld> the static git built [11:03:23 CEST] <durandal_1707> from where? [11:04:38 CEST] <rtwld> ffmpeg.org [11:05:25 CEST] <durandal_1707> ffmpeg.org does not provide binaries [11:06:02 CEST] <durandal_1707> it just links to another site [11:06:11 CEST] <rtwld> I must have followed a link. https://johnvansickle.com/ffmpeg/ [11:07:14 CEST] <rtwld> the link was on https://ffmpeg.org/download.html [11:08:33 CEST] <rtwld> ffplay isn't also in deb-multimedia, is there a reason why they aren't interested in ffplay? [11:09:18 CEST] <durandal_1707> maybe its hard to do static build with sdl [11:16:35 CEST] <rtwld> ok, but the deb package of deb-multimedia is not static [11:18:38 CEST] <BtbN> you#re gonnà hàve to àsk the one who uìlt ìt [11:21:36 CEST] <durandal_1707> BtbN: why such style? [11:22:24 CEST] <pink_mist> he's stylish [11:22:32 CEST] <BtbN> Hexchat on Windows sometimes has some kind of seizure and only a restart fixes it... [11:23:20 CEST] <durandal_1707> one of easter eggs? [11:23:52 CEST] <BtbN> Seems more like some weirdness in their input method handling [11:24:08 CEST] <BtbN> Happens mostly if HexChat is started early during boot [18:18:04 CEST] <cpusage> Quick question, does anyone know what restrictions this x265 warning is referring to? [18:18:20 CEST] <cpusage> "limit reference options 2 and 3 are not supported with pmode" [18:19:36 CEST] <furq> https://x265.readthedocs.io/en/default/cli.html#cmdoption-pmode and https://x265.readthedocs.io/en/default/cli.html#cmdoption-limit-refs [18:27:06 CEST] <cpusage> furq so I just need to disable limit-refs=0 [18:27:27 CEST] <cpusage> *by [18:32:13 CEST] <cpusage> :] (y) seems right, great [18:33:16 CEST] <cpusage> is it ill-advised to enable both pmode and pme if cpu utilization is low? [21:20:48 CEST] <Henry151> hi ffmpeg [21:22:03 CEST] <Henry151> I am trying to get my command right... I previously pulled all the subtitles out of a bunch of .mkv files, so that i had .mkv and .srt files, and then was able to burn the subtitles in to the videos while converting them to mp4 [21:22:21 CEST] <Henry151> i understand that this should be possible as a single operation; that just copies the subtitles from the mkv to the mp4 [21:22:52 CEST] <JEEB> burn-in and copying are two different things that you can do with subtitles [21:23:02 CEST] <JEEB> or well, not copying but keeping them as subtitles :P [21:23:19 CEST] <JEEB> (since mp4 only currnetly supports mov_text aka 3gpp text aka mpeg-4 timed text) [21:24:12 CEST] <Henry151> ok, so the right way is to pull them out into .srt files, then burn those into the mp4? [21:24:50 CEST] <JEEB> actually you probably want ASS for the ass filter, but yes. I think the subtitle filter might also take srt but I don't remember that by heart, unfortunately. [21:24:58 CEST] <Henry151> I couldn't control the font size; I was looking here https://stackoverflow.com/questions/21363334/how-to-add-font-size-in-subtit… and tried several times and the subtitles come out with a giant font no matter what i tell it to set the font size to [21:25:11 CEST] <JEEB> http://ffmpeg.org/ffmpeg-filters.html#ass [21:25:26 CEST] <JEEB> yes, then you want the ASS filter and utilize ASS subtitle format which contains styles [21:25:40 CEST] <JEEB> you can then modify the style [21:26:03 CEST] <Henry151> ok [21:26:07 CEST] <Henry151> time to try again :) [21:26:16 CEST] <another> 00018102.png: [21:26:20 CEST] <another> urg [21:26:22 CEST] <another> https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo [21:26:57 CEST] <Henry151> yeah i've spent a bit of time there [21:27:22 CEST] <another> you can use the subtitles in your mkv file directly [21:28:07 CEST] <Henry151> how do i do that? I have struggled with that part [21:28:39 CEST] <another> second example [21:32:53 CEST] <Henry151> thank you for your guidance, but i'm still stuck here [21:32:54 CEST] <Henry151> https://termbin.com/ffen [21:33:08 CEST] <Henry151> [Parsed_subtitles_0 @ 0x556d2675ba80] No filename provided! [21:33:15 CEST] <Henry151> [AVFilterGraph @ 0x556d2662fbc0] Error initializing filter 'subtitles' with args '' [21:33:20 CEST] <Henry151> is what i'm getting. [21:44:35 CEST] <another> hmm.. sounds like a bash error [21:44:51 CEST] <another> can you run: bash -xv script.sh [21:45:56 CEST] <Henry151> https://bpaste.net/show/EAuy [21:49:20 CEST] <Henry151> i think i figured it out with some help from #bash, the filename having the square brackets i think is causing the issue [21:50:01 CEST] <Henry151> i think i have to make it subtitles=\""$f"\" [21:50:13 CEST] <Henry151> so that it will put $f inside of double-quotes [21:55:06 CEST] <Henry151> well it's still not working right. But, I can indeed do it from the command line directly one file at a time, so i think it is a bash issue [22:02:01 CEST] <Diag> I think i need more ffmpeg flags for using more threads on x264 [22:02:23 CEST] <Diag> I saw lookahead threads [22:04:46 CEST] <another> Henry151: it's actually an not a bash issue, but an layer 8 one [22:05:39 CEST] <another> the output you linked does not match the script you posted earlier [22:05:49 CEST] <Henry151> sorry yes i had tweaked it [22:05:54 CEST] <another> your issue is here: subtitles="$f":0:2 [22:05:58 CEST] <Henry151> i can run again [22:06:23 CEST] <another> should be:; subtitles="$f":si=2 [22:06:24 CEST] <another> see https://ffmpeg.org/ffmpeg-all.html#subtitles-1 [22:07:07 CEST] <Henry151> i'm now here: https://bpaste.net/show/ho_r [22:08:30 CEST] <Henry151> i'm pretty sure it's the square brackets in my filenames screwing things up. [22:08:38 CEST] <another> no [22:09:22 CEST] <another> you double double quotes is wrong [22:09:49 CEST] <Henry151> ah fudge [22:09:53 CEST] <another> it leads to no quotes around $f which leads to word splitting [22:09:54 CEST] <Henry151> that's just me floundering around like an idiot [22:09:58 CEST] <Henry151> https://bpaste.net/show/Rasy [22:11:25 CEST] <Henry151> seems to do that same thing whether subtitles="$f" or subtitles="$f":si=2 [22:12:21 CEST] <Henry151> someone over in #bash suggested trying the ffmpeg option "-pattern_type none" [22:12:26 CEST] <Henry151> any merit to that idea? [22:13:05 CEST] <Diag> Is there any way to tell what the limiting factor is in encoding [22:13:49 CEST] <another> huh. i stand corrected [22:14:52 CEST] <another> ah [22:23:02 CEST] <another> apparently it is indeed the brackets [ ] [22:23:28 CEST] <another> but not due to globbing as i thought [22:25:13 CEST] <another> seems the subtitles filter needs those escaped [22:25:52 CEST] <another> subtitles="\[AnimeKayo\] Kaze ga Tsuyoku Fuiteiru Ep 02 1080p Eng Sub HEVC \[Marshall\].mkv":si=6 [22:26:06 CEST] <another> now how to script that.... [22:28:14 CEST] <Henry151> great, i'll just remove the bracketed parts from the filenames i suppose.. thank you for all your time [00:00:00 CEST] --- Mon Aug 26 2019

1 0

ffmpeg-devel.log.20190806
by burek 25 Aug '19

25 Aug '19

[00:11:07 CEST] <thardin> if these fuzz fixes are a hassle to port, maybe the way releases are updated needs to be rethought? [00:27:40 CEST] <BtbN> As in, just give up on classic releases, and just tag a commit that's deemed somewhat stable every now and then, like systemd does for example? [00:28:28 CEST] <jamrial> that's what x264 does, and imo it's kinda ugly [00:28:46 CEST] <BtbN> For something like x264 it's probably fine [00:28:58 CEST] <BtbN> but for something as huge and complex as ffmpeg it seems unfitting to me [00:29:45 CEST] <jamrial> yeah, ffmpeg needs bugfix releases for existing branches since LTS distros exist [00:47:24 CEST] <jdarnley> "LTS" distros do their own thing and in the process break stuff so leave to do it [00:48:12 CEST] <kierank> there should be release and stable [00:48:13 CEST] <kierank> and that's it [10:44:20 CEST] <cone-123> ffmpeg 03Michael Niedermayer 07master:6c67c8ca9ae6: Revert "avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation" [13:48:57 CEST] <kurosu> jdarnley_obs: (not about reviewing) does your x86inc patchset relate to code in ffmpeg (existing or being ported eg from one instruction set to another) ? [13:53:15 CEST] <J_Darnley> No, I have no current use for the changes. [13:54:22 CEST] <J_Darnley> I was looking at it because I was updating the shim in another project to see if it would fix an issue there. [14:14:30 CEST] <durandal_1707> who will write release news? [15:32:36 CEST] <durandal_1707> should we ban this guy on user mailing list? [15:35:07 CEST] <mkver> durandal_1707: Which guy specifically? [15:35:29 CEST] <J_Darnley> Who? Reindl? That is how everyone sane eventually reacts to user support. [15:35:53 CEST] <J_Darnley> I don't know how Carl does otherwise. [15:36:16 CEST] <durandal_1707> carl does not use f word [15:37:10 CEST] <J_Darnley> Yeah. I don't know how he manages to not swear at the endless stream of dumb users. [15:39:36 CEST] <durandal_1707> that guy called me multiple times with derogatory term [16:04:02 CEST] <durandal_1707> update topic here too? [16:04:45 CEST] <durandal_1707> so we can get phoronix excited coverage [16:05:33 CEST] <Lynne> we're not gstreamer, we can't get exciting phoronix coverage [16:06:12 CEST] <durandal_1707> why? [16:07:52 CEST] <mkver> Actually, phoronix has just written about 4.2: https://www.phoronix.com/scan.php?page=news_item&px=FFmpeg-4.2-Released [16:08:16 CEST] <durandal_1707> haha [16:11:10 CEST] <nevcairiel> phoronix gets excited about all sorts of minor c hanges [16:13:16 CEST] <thardin> woop [16:15:31 CEST] <durandal_1707> mentioned gif parser in topic, like its very important addition [16:16:50 CEST] <thardin> I certainly have more meme gifs than webms on my machine, so it makes sense [22:05:48 CEST] <Lynne> I also got in the "I agreed with nicolas once" camp! [22:08:29 CEST] <durandal_1707> lol [22:49:08 CEST] <durandal_1707> here. we. go. again. [22:49:23 CEST] <thardin> have I unwittingly instigated this month's bikeshedding session? [22:50:31 CEST] <BtbN> There are _a ton_ of instances of no braces for single line if() in the codebase. And the previous style guideline said the exact opposite. Changing it now seems weird. [22:55:18 CEST] <Lynne> its from someone's company email [22:57:24 CEST] <thardin> it's due to a discussion me and ngaullier had on irc earlier today [22:59:40 CEST] <thardin> of course if I had my way as far as security and correctness is concerned there would be much wailing [23:12:41 CEST] <sfs> hello [23:12:45 CEST] <sfs> are there any problems with ffmpeg and VSX on big-endian POWER? [23:12:49 CEST] <sfs> i ask because in configure, there is [23:12:53 CEST] <sfs> 5535 if ! enabled ppc64 || enabled bigendian; then [23:13:03 CEST] <sfs> 5536 disable vsx [23:13:13 CEST] <sfs> i was wondering why VSX was getting disabled even though i passed --enable-vsx [23:13:54 CEST] <BtbN> I guess nobody wrote SIMD for that combination? [23:14:18 CEST] <J_Darnley> I have no idea but maybe we have no testers. Or maybe that assembly is written for little. [23:16:05 CEST] <sfs> ok, i will try to run make test [00:00:10 CEST] --- Wed Aug 7 2019

1 0

ffmpeg.log.20190721
by burek 25 Aug '19

25 Aug '19

[00:38:57 CEST] <yashi> CounterPillow: TF is BLB? [00:39:24 CEST] <CounterPillow> a user in here who gets his name spammed by some kid. [01:47:06 CEST] <nine_milli> blb [02:00:55 CEST] <koz_> I'm getting very bizarre behaviour from ffmpeg when I try to do a FLAC -> Ogg Vorbis conversion. I did a trace here: http://paste.debian.net/1092488/ Am I doing something wrong? [02:24:47 CEST] <DHE> it's trying to convert the poster art into theora, the default video codec for .ogg. you might just want to remove it. add: -map 0:a just before the output filename [02:30:54 CEST] <koz_> DHE: If I wanna keep it, do I have to specify -c:v and -b:v respectively? [02:31:54 CEST] <DHE> I'm not sure, never tried it. but it sounds googlable. ffmpeg copy poster art or something... [02:32:01 CEST] <koz_> DHE: OK, thanks, will try. [02:34:21 CEST] <koz_> DHE: That _still_ blows up. Here's trace: http://paste.debian.net/1092490/ [02:38:25 CEST] <DHE> nope, I've left my area of knowledge. [02:38:53 CEST] <koz_> DHE: Thanks anyway. This is causing me to question my own sanity - I've been using ffmpeg to do this kind of conversion for ages, and I've never had these kinds of issues. [03:31:03 CEST] <nine_milli> blb [03:35:26 CEST] <another> koz_: something rings a bell in my head [03:36:18 CEST] <another> add: -ar 48k [04:01:43 CEST] <Hello71> koz_: I'm going to wager a guess that your encoder actually does have problems [04:02:31 CEST] <Hello71> 96khz is ridiculous too, but I'm pretty sure it's not the problem [04:08:34 CEST] <another> pretty sure it is [04:08:51 CEST] <another> my tests here work [04:11:17 CEST] <another> and i remember stumbling upon it a while ago. something about libvorbis not accepting certain sample rates which ffmpeg doesn't know about [04:39:29 CEST] <nine_milli> blb [05:00:02 CEST] <koz_> another and Hello71: I figured out the issue. I used the wrong -map command and ffmpeg assumed it was a video, not 'audio + cover art'. Fixed it up though. [05:00:10 CEST] <koz_> Thanks for the help everyone! [05:39:31 CEST] <hendry> hi, I tried out hevc_vaapi but it doesn't playback on IOS safari like it should https://caniuse.com/#search=hevc [05:40:18 CEST] <hendry> can someone tell where I went wrong creating this video? https://s.natalian.org/2019-07-21/h-whodis.mp4 log file: https://s.natalian.org/2019-07-21/h-whodis.mp4.log [06:10:25 CEST] <nine_milli> blb [12:33:59 CEST] <viktorg> Hello, how does -init_hw_device work? Where is the "named global device" being created? Is this persistent? Where can I list created named global devices? [12:36:59 CEST] <relaxed> hendry: the frame size is 2688x1520 [12:38:21 CEST] <relaxed> maybe that;s too much for an IOS device? [12:41:23 CEST] <relaxed> viktorg: did you see https://trac.ffmpeg.org/wiki/Hardware/VAAPI ? [12:44:37 CEST] <viktorg> relaxed, I already saw this page. But it doesn't clarify where the "named global device" of the command `ffmpeg -init_hw_device vaapi=foo:/dev/dri/renderD128` ( foo) is being created and where I can delete it (if I want). [12:46:55 CEST] <relaxed> it's created by ffmpeg for use within ffmpeg [12:49:24 CEST] <viktorg> but does it outlive the end of the process? [12:49:46 CEST] <viktorg> so can I access the device foo after e.g. a reboot? [12:50:18 CEST] <JEEB> I don't think any contexts created for the devices outlive a process unless there's a boog somewhere. the device should stay just fine, though? [12:50:37 CEST] <JEEB> FFmpeg itself doesn't create the device [12:51:07 CEST] <JEEB> and if it creates a named context for a device, then that of course is specific to that process [12:51:16 CEST] <JEEB> since the naming is on FFmpeg's side I would guess [12:52:04 CEST] <viktorg> so init_hw_device just creates something like an alias for a device for further usage in the command? [12:52:49 CEST] <JEEB> most likely yes [13:09:31 CEST] <sine0> what is the best format or the most 'safe' for mp3 in these dodgy little players and devices. would it be vbr or cbr [13:12:33 CEST] <JEEB> safest would be to use something in a container, like AAC in mp4 :P [13:12:51 CEST] <JEEB> if you *have* to use MP3, CBR means that seeking is more likely to work [13:13:06 CEST] <JEEB> you have to remember that MP3 is raw bit stream without a container [13:13:21 CEST] <JEEB> for some reason we ended up in a space-time continuum where that was considered acceptable [13:13:40 CEST] <sine0> hmmm cool ok [13:13:42 CEST] <JEEB> so most audio players that are software just index the mp3 files [13:13:54 CEST] <JEEB> and that way you get to seek [13:14:05 CEST] <JEEB> for plastic boxes [13:14:09 CEST] <JEEB> all bets are off [13:18:57 CEST] <sine0> what does ffmpeg use for mp3 encoding by default [13:19:38 CEST] <sine0> im going to fire some questions at you now, I have a few [13:19:49 CEST] <relaxed> libmp3lame [13:20:19 CEST] <sine0> relaxed: so it has used the code from the lame_enc.dll i thought that needed paymet [13:21:09 CEST] <relaxed> nope [13:21:11 CEST] <JEEB> LAME is an open source project, so in that sense you can get the source code for free. what you can do with the source or binary depends on your local juristiction [13:21:33 CEST] <JEEB> because unlike software licensing, patent licensing is a mess :P [13:21:37 CEST] <JEEB> and I'm not a lawyer [13:22:02 CEST] <JEEB> that said, I think Fedora finally enabled mp3 decoding some time ago so they apparently decided that at least decoding related patents in the US have vanished? [13:23:03 CEST] <JEEB> that's btw why various modules for things like mp3 or aac generally from corporations require a payment. patents. :P [13:23:15 CEST] <JEEB> or at least that's how I guess it goes [13:29:21 CEST] <sine0> -ar is the rate so like 44100 etc, -ac is the channels so 1 for mono etc, what is the bit for 192 128 etc is that -aq [13:30:48 CEST] <relaxed> -b:a 192 [13:31:03 CEST] <relaxed> -q:a is for vbr [13:31:39 CEST] <relaxed> er, 192k [13:34:02 CEST] <sine0> ok thanks [13:37:51 CEST] <relaxed> sine0: https://trac.ffmpeg.org/wiki/Encode/MP3 [13:40:42 CEST] <sine0> ffmpeg is a real swiss army knife [16:58:23 CEST] <nine_milli> blb [16:59:49 CEST] <MoziM> what's the point of fractional frame rates? [17:00:48 CEST] <JEEB> hysterical raisins [17:01:18 CEST] <JEEB> xxx/1001 has been in use for ages in broadcast etc [17:01:53 CEST] <JEEB> heck, even blu-rays are mostly 24000/1001 for films etc instead of 24 [17:02:11 CEST] <JEEB> (I've seen like one or two cases of straight 24Hz since it's accepted on blu-rays as well) [17:07:05 CEST] <MoziM> i see... [17:07:27 CEST] <MoziM> i'm asking because a bunch of old cartoons have 24.95587 whatever fps [17:07:58 CEST] <MoziM> and i was wondering what someone would want to do that -_- [17:18:35 CEST] <JEEB> MoziM: more likely to be variable frame rate or offset somewhat and whatever you're looking up the frame rate with does an average [17:28:02 CEST] <[olli]> Re all. I misunderstand command options. This command is wrong: "ffmpeg -i ${dvr_source_stream_file} -codec copy -frames:60:0 ${destination_stream_file}". destination file is not set. I want 60 frames in src be written into dst w/o any transformation - simple "cut". ffmpeg "thinks" that dst is missing. In man I see no option to specify dst stream "-something" - it always autoselected in TLDR easy samples. In result I'm confused - where [17:28:02 CEST] <[olli]> I'm wrong? %) [17:29:26 CEST] <JEEB> you miss spaces after frames since you probably didn't mean it to be limited to whatever is "60:0" [17:29:50 CEST] <JEEB> and thus destination gets parsed as parameter for the -frames option [17:29:51 CEST] <JEEB> :P [17:30:09 CEST] <JEEB> for explicit stream mapping, if you ever need that try searching for -map in ffmpeg-all.html [17:34:31 CEST] <[olli]> JEEB: hmm.. man says I should reference files from 0. 60:0 is 60 frames in file 0 in my mind. I want exactly 60 frames - trying to learn from simple cut. I will dig option -map in man ffmpeg-all. Thanks. [17:37:13 CEST] <JEEB> [olli]: that is usually used with things that map to inputs. with an output you generally have just one and the options after input start again from zero as you put another output in [17:37:34 CEST] <JEEB> so -map 0:v:0 would be "first input, video stream, #0 of previous" [17:37:58 CEST] <JEEB> but in case of output side options you generally just have the stream number [17:38:08 CEST] <JEEB> like -c:v:0 copy [17:38:32 CEST] <JEEB> codec for "video, 0th stream" gets set to copy [17:39:40 CEST] <JEEB> I'm not sure if the frames option is even stream dependent, but in any case -frames:v:0 60 sounds more like it if you mean the first video stream of your output [17:40:22 CEST] <JEEB> (you don't need the stream type specifier but generally simpler than to keep your mind on what got selected as which stream from the input) [18:36:20 CEST] <[olli]> JEEB, thank you and one more question - I don't know how many streams in dvr source file. Is there a simple way how to find out number of streams - what options I should point my attention to? My idea is cut 200 frames and ffmpeg should write all found frames into output files with names like output.stream1 output.stream2 .. output.streamN . Should this work and what option lands stream to file names with autonaming? [18:46:32 CEST] <nine_milli> blb [18:58:56 CEST] <JEEB> [olli]: either make your own API client, or utilize ffprobe with -of json -show_streams -show_programs [18:59:24 CEST] <[olli]> thanks! [22:02:55 CEST] <nine_milli> blb [00:00:11 CEST] --- Mon Jul 22 2019

1 0

ffmpeg.log.20190824
by burek 25 Aug '19

25 Aug '19

[00:00:03 CEST] <kepstin> if you're comparing encoders, encoding to precise size is a good idea tho :) [00:00:08 CEST] <Diag> ^ [00:00:33 CEST] <Diag> hey man, going from slower to placebo shaved off an extra 60k from 2.4 megs [00:00:43 CEST] <Diag> thats important bandwidth [00:00:48 CEST] <kepstin> most of that probably came from the slower to veryslow change [00:01:13 CEST] <Diag> I remember yall sayin placebo is redundant almost [00:01:27 CEST] <kepstin> and also changing the preset shouldn't change the size [00:01:30 CEST] <Diag> now to compare it to vce /s [00:01:34 CEST] <kepstin> since you're targetting a bitrate :/ [00:01:43 CEST] <Diag> It did tho :S [00:02:09 CEST] <kepstin> some sort of rate control issue then :/ [00:02:15 CEST] <BtbN> That probably means that the given target bitrate is more than it needs for "perfect" quality [00:02:15 CEST] <furq> preset and size are pretty much never related [00:02:24 CEST] <furq> or they shouldn't be [00:02:29 CEST] <kepstin> yes, but this is a bitrate-target 2-pass encode [00:02:34 CEST] <kepstin> so size should be fixed [00:02:36 CEST] <kepstin> quality changing [00:02:43 CEST] <Diag> obviously yall needa write yo shit better [00:02:53 CEST] <furq> sure, i'm just saying it wouldn't be true in crf mode either [00:03:03 CEST] <furq> any changes in final bitrate are coincidental [00:03:08 CEST] <kepstin> i wouldn't be surprised if the rate control in placebo mode just undershot :) [00:03:12 CEST] <FooNess> Diag, if you have a two-pass encode and you're targetting a specific bitrate and you know how long the stream is, I am not sure where the size difference is coming from. [00:03:29 CEST] <Diag> :shrug: [00:03:36 CEST] <kepstin> probably placebo mode rate control isn't as well tested as the other options [00:03:37 CEST] <Diag> its actually a little more than i thought [00:03:40 CEST] <BtbN> the encoder not needing as many bits as you gave it is the most likely reason [00:03:44 CEST] <furq> it wouldn't surprise me if rc in placebo was less accurate just because those settings have been tested a lot less [00:03:46 CEST] <FooNess> Hmmmm. [00:03:49 CEST] <Diag> 2.43 megs vs 2.34 [00:04:09 CEST] <BtbN> That's so tiny, it's little more than noise [00:04:15 CEST] <furq> yeah [00:04:34 CEST] <Diag> well i did say 60k, jeez [00:04:41 CEST] <furq> i know 60KB of 2.4MB is quite a lot but that's not going to scale as the file gets larger [00:05:33 CEST] <kepstin> hmm, interesting. some stuff in a netflix tech blog post suggest they're using eve-vp9 [00:05:35 CEST] <furq> also bear in mind you'll likely be clamped on refs if you want hwdec compatibility [00:05:47 CEST] <furq> which limits the gains you'll get from veryslow/placebo [00:05:54 CEST] <Diag> heh [00:06:08 CEST] <furq> you get like 3 refs at 1080p for level 4.1 compliance [00:06:15 CEST] <furq> or 4.2 or whatever you're supposed to use [00:06:28 CEST] <Diag> im actually like [00:06:41 CEST] <Diag> really surprised at how "ok" this looks [00:06:44 CEST] <kepstin> https://medium.com/netflix-techblog/performance-comparison-of-video-coding-… has some comparisons including eve that might actually be valid. [00:06:54 CEST] <furq> i know you started with x264 slower hours ago and you don't want to have gone through all of this to end up back there [00:07:01 CEST] <furq> but you really were right the first time [00:07:06 CEST] <Diag> hmm? [00:07:10 CEST] <Diag> Im just experimenting [00:07:21 CEST] <Diag> and im cold so i need cpu load [00:07:25 CEST] <furq> lol [00:07:35 CEST] <Diag> ive already got solidworks rendering [00:07:39 CEST] <furq> what's the use case for this anyway [00:07:48 CEST] <Diag> yes [00:07:54 CEST] <Diag> http://tyronesbeefarm.com/images/20192ca48392-b5ec-410c-94f0-41aa388ae74d.j… [00:07:56 CEST] <Diag> >solidworks [00:08:08 CEST] <Diag> >12690 iterations [00:08:35 CEST] <Diag> there is no 'real' use case [00:08:53 CEST] <Diag> i just wanted to make my little recorded snippits look nicer because ive got too much cpu power to care [00:09:23 CEST] <kepstin> huh, when you zoom in on that you see squares from the edges of the noise texture, it guess it doesn't tile well? :/ [00:09:40 CEST] <Diag> Yeah idunno what that is [00:09:44 CEST] <Diag> its an issue with prorender [00:09:56 CEST] <Diag> thats just a bullshit material slapped on a model i made [00:09:59 CEST] <kepstin> some bad looking stretching (uv issue?) around the bends too. [00:10:05 CEST] <Diag> heh [00:10:07 CEST] <Diag> thats solidworks [00:10:24 CEST] <Diag> you can go through and let it do proper projections but i just needed something to render [00:10:35 CEST] <Diag> http://tyronesbeefarm.com/images/2018195105.jpg [00:10:40 CEST] <Diag> this is a more proper render of that [00:13:24 CEST] <Diag> http://tyronesbeefarm.com/images/2018002304.png [00:13:25 CEST] <Diag> internals [00:13:52 CEST] <Diag> http://tyronesbeefarm.com/images/2018164350.jpg [00:14:01 CEST] <Diag> another quick render with materials just slapped on [15:32:31 CEST] <Fyr> guys, how do I cut a video file into pieces with a single command? I need: [15:32:31 CEST] <Fyr> -i "input.mp4" -ss XX -t Y out1.mp4 -ss ZZ -to WW out2.mp4 [15:32:31 CEST] <Fyr> etc [15:51:20 CEST] <DHE> Fyr: there's a 'segment' muxer you might like [15:51:29 CEST] <DHE> https://ffmpeg.org/ffmpeg-formats.html#segment [15:53:10 CEST] <pink_mist> I mean .. shouldn't what Fyr already showed work fine? [15:53:33 CEST] <DHE> "with a single command" would be the operative bit [15:53:49 CEST] <pink_mist> how is that not a single command? [15:53:56 CEST] <DHE> well that give 1 piece [15:54:05 CEST] <pink_mist> ? [15:54:30 CEST] <DHE> oh I misread it... [16:00:41 CEST] <Fyr> thanks [16:00:54 CEST] <Fyr> but -f segment is a complicated thing. [16:29:49 CEST] <Classsic> Hi, any freelancer expert on -complex_filter? [16:30:06 CEST] <chauffer> what's a freelancer expert [16:30:49 CEST] <durandal_1707> expert that do things for free or underpaid? [16:31:46 CEST] <Classsic> ok somebody interest, please sendme pm. [16:36:37 CEST] <rocktop> I used this to split the video but I have a problem with audio is not synced [16:36:44 CEST] <rocktop> this : /usr/local/bin/ffmpeg -i 'in.mp4' -ss 600 -t 301 -c copy -async 1 'out.mp4' [16:37:06 CEST] <rocktop> anyidea how to fix this issue ? [16:37:28 CEST] <JEEB> depends, in general the things should just work. as the first thing I would disable advanced edit list code by GOOG [16:38:04 CEST] <JEEB> -advanced_editlist 0 before input [16:38:15 CEST] <JEEB> also why are you setting async :P [16:38:26 CEST] <JEEB> I thought that only does something if you actually resample audio [16:38:29 CEST] <JEEB> which -c copy will not be doing [16:51:56 CEST] <dastan> hello people [16:52:07 CEST] <JEEB> ohai [16:53:11 CEST] <dastan> i am creating a shell script with ffmpeg [17:05:58 CEST] <dastan> this is mi script [17:06:02 CEST] <dastan> https://pastebin.com/jTmQDrzZ [17:06:39 CEST] <dastan> but i am receiving a This gives me an error saying "No such file or directory". [17:06:53 CEST] <dastan> can someone help me? [17:08:10 CEST] <Classsic> do you have the url for testing? [17:09:18 CEST] <BtbN> Is raw pcm in hls even supported? [17:09:39 CEST] <BtbN> And nvenc without any quality parameters will not yield something nice [17:09:47 CEST] <BtbN> Can't you just copy? [17:17:12 CEST] <dastan> if i send the command without scripting works ok [17:18:35 CEST] <another> dastan: you are trying to write to /home/build/MSS-ONE/temp/cache/$project-$intnumber [17:18:50 CEST] <another> that directory probably doesn't exist [17:21:29 CEST] <dastan> ok, i missed up the mkdir command [17:27:38 CEST] <dastan> it gives me the same error [17:30:18 CEST] <dastan> https://pastebin.com/mMtX0EVK [20:10:14 CEST] <Classsic> hi everybody. [20:10:43 CEST] <Classsic> is there a way to sync two input rtmp to use with vstack? [20:11:56 CEST] <Classsic> I try use -use_wall_clock_as_timestamps and copyts option, and it works, but get stuttering playback [20:13:52 CEST] <cehoyos> Command line and complete, uncut console output missing / try the buffer filter or a larger network buffer [20:24:33 CEST] <Classsic> how long command I can paste here? [20:24:46 CEST] <JEEB> use pastebin.com or gist or something [20:24:48 CEST] <JEEB> and link here [20:24:54 CEST] <JEEB> that way you can have the command and the full terminal output [20:34:41 CEST] <durandal_1707> vstack expect normal timestamps [20:35:17 CEST] <durandal_1707> rtmp is not generally providing one [21:47:59 CEST] <intrac> I'm encoding an image sequence + audio where the audio is longer. although ffmpeg will extend the last frame to match the audio, it doesn't appear to be repeating it as such [21:48:55 CEST] <intrac> as I'm using the noise filter which becomes static on the last frame of the image sequence [21:49:30 CEST] <intrac> is there a way to get ffmpeg repeat the last input frame so that the noise animates right to the end? [21:49:56 CEST] <durandal_1707> noise filter can be set to temporal [21:55:48 CEST] <intrac> yes, it already is but the grain becomes static when the last input frame is reached (audio continues for some seconds more) [21:56:00 CEST] <intrac> -vf noise=c0s=4:c0f=t [21:56:54 CEST] <intrac> I guess because the noise filter only applies grain to different incoming frames [21:58:01 CEST] <durandal_1707> no, you will need to use tpad filter [21:58:25 CEST] <durandal_1707> in addition with -shortest option [22:00:45 CEST] <intrac> I can't see a mention of tpad. is it a recent addition? [22:00:54 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#tpad [22:01:05 CEST] <furq> new in 4.2 apparently [22:01:21 CEST] <intrac> yep, not recognised as a video filter here. 3.4.4. drat [22:01:33 CEST] <furq> https://www.johnvansickle.com/ffmpeg/ [22:01:42 CEST] <durandal_1707> 3.4.4 is very old [22:05:49 CEST] <intrac> yep. I'm still on suse leap 15.0 [22:06:33 CEST] <intrac> I'll try and plan in an upgrade this weekend [22:06:41 CEST] <intrac> thanks for the tpad suggestion [22:28:36 CEST] <Classsic> cehoyos here get the command+log https://gist.github.com/Classsic/49b00d4e68dc54a342f54a6cffb0823f [22:32:00 CEST] <cehoyos> Looks like a performance issue [22:46:45 CEST] <cpusage> Hi [22:47:13 CEST] <cpusage> I have a quick question in regards to optimizing ffmpeg for a 3900x (12 core, 24 thread) [22:47:46 CEST] <cpusage> for some reason, when I was utilizing a 1800x and a 3800x, the CPU usage would be at 100% [22:48:17 CEST] <cpusage> when I switched to the 3900x, CPU usage lingers around 60% [22:48:46 CEST] <cpusage> (using the same transcoding/encoding commands) [22:49:42 CEST] <furq> pastebin the command [22:49:46 CEST] <furq> and output [22:53:14 CEST] <cpusage> the command is extremely simple, just transcoding/encoding some h264 content into h265 [22:53:50 CEST] <cpusage> https://pastebin.com/KVWCYWgt [22:54:44 CEST] <ritsuka> you've got too many cores [22:55:38 CEST] <cpusage> so, it's a limitation of ffmpeg? [22:58:15 CEST] <furq> it's a limitation of whatever encoder you're using [22:59:02 CEST] <cpusage> ah, so it's a limitation of libx265 [22:59:42 CEST] <cpusage> any idea why there are random frame drops as well? [22:59:43 CEST] <cpusage> https://imgur.com/a/wsr9vRx [23:04:43 CEST] <cehoyos> (The command line withoutthe complete, uncut console output is useless and FFmpeg does not contain a hevc encoder) [23:05:07 CEST] <cehoyos> The x265 developers once wrote a patch that raises the cpu consumption for cases like yours to 100% [23:05:18 CEST] <cehoyos> The patch had a disadvantage though: [23:05:39 CEST] <cehoyos> It reduced overall encoding speed, the decision was therefore not to include the patch [23:20:25 CEST] <cpusage> cehoyos would this suffice? [23:20:55 CEST] <cpusage> https://pastebin.com/TC4muXjF [23:22:37 CEST] <cpusage> Any suggestions or advice to fully utilize the 3900x during encodes, and to stop the dropping of frames would be much appreciated [23:24:19 CEST] <cehoyos> Again: Not using the full cpu power is a property of a sane encoder [23:24:31 CEST] <cehoyos> Frame dropping is of course not encoder-related. [23:24:58 CEST] <cehoyos> (No, very obviously not) [00:00:00 CEST] --- Sun Aug 25 2019

1 0

ffmpeg-devel.log.20190729
by burek 24 Aug '19

24 Aug '19

[00:23:29 CEST] <cone-233> ffmpeg 03Mark Thompson 07master:338714786058: vaapi_encode: Add ROI support [00:23:29 CEST] <cone-233> ffmpeg 03Mark Thompson 07master:20fed2f0ab19: lavfi: addroi filter [02:59:42 CEST] <rcombs> does anyone know why cuda_nvcc is marked as a nonfree library dependency? [03:00:02 CEST] <rcombs> I'm not super familiar with the details but it seems like a build-time tool to me [03:01:12 CEST] <rcombs> and it looks as if the output should be dynamically linked against ffnvcodec, just like other non-nonfree stuff [03:06:42 CEST] <rcombs> (contrast with libnpp, which is a hard runtime dep) [03:44:20 CEST] <rcombs> is it something about nonfree headers that NVCC implicitly includes? [03:49:26 CEST] <rcombs> the only actual uses of those headers seem to be fairly trivial [03:59:05 CEST] <rcombs> also, the output of NVCC is a text shader file to be run on the GPU, not CPU-executable code [04:04:48 CEST] <rcombs> one could also argue that the graphics API is a "Major Component" [05:12:42 CEST] <rcombs> https://twitter.com/yukihohagiwara/status/1155632012692271105 [05:29:54 CEST] <rcombs> erm, that is the wrong channel [08:51:10 CEST] <rcombs> well, I'm gonna reach out at Nvidia and see if they can clarify the license situation [09:18:10 CEST] <cone-420> ffmpeg 03Gyan Doshi 07master:43891ea8ab28: avfilter/fade: don't allow nb_frames == 0 [09:58:38 CEST] <nevcairiel> rcombs: i believe the reason was that nvcc itself is hidden behind a signup wall and EULA, as well as it including some nvidia cuda library functions in the output which may be licensed awkwardly [09:59:15 CEST] <rcombs> you don't actually need to signup to download it, there's a public downloads page with regular links [09:59:58 CEST] <rcombs> and it doesn't look like the PTX output contains any actual library code, but it _is_ derived from the headers (also publicly downloadable) [10:00:18 CEST] <rcombs> I'm asking for an explicit EULA exception on compiling those headers [10:02:13 CEST] <rcombs> (something like the linux or GCC GPL exceptions) [10:04:37 CEST] <rcombs> also you can compile .cu files with clang, so long as you have the headers [10:05:24 CEST] <rcombs> none of ffmpeg's .cu files use much, one could probably make tweaked versions that work in clang without the headers [10:12:16 CEST] <nevcairiel> you should talk to BtbN and philipl, they considered all sorts of methods to get portable builds with cuda stuff included, with various downsides [10:22:47 CEST] <durandal_1707> why i get slower decoding with slice threading and DSD/DST? [10:25:40 CEST] <rcombs> it's basically a couple typedefs and the Tex2D function (a 1-liner) [10:30:00 CEST] <rcombs> and tex2D is just a thunk to asm("__itex2D_uchar"); or the like [11:08:42 CEST] <rcombs> nevcairiel: this is all the header required to build vf_scale_cuda.cu using clang: https://gist.github.com/12215f97e7de29033db6dad848141a3e [11:08:59 CEST] <rcombs> clang -c -v -S -o out.ptx libavfilter/vf_scale_cuda.cu -nocudalib -nocudainc --cuda-device-only -O3 [11:11:34 CEST] <rcombs> I think there's a pretty solid argument to be made that struct declarations and a single template that simple are trivial enough to be fair use regardless [11:18:30 CEST] <BtbN> rcombs, there was no public download site last time I checked. You need an account and accept their EULA to get NVCC and the required libs. [11:18:46 CEST] <rcombs> BtbN: then you haven't checked sufficiently recently [11:18:51 CEST] <BtbN> Unless that recently changed? Then we might be able to reconsidder the nvcc license situation. [11:18:59 CEST] <rcombs> https://developer.nvidia.com/cuda-downloads [11:19:43 CEST] <rcombs> I think it gives a EULA prompt during installation? I've been manually unpacking the .debs mostly [11:19:43 CEST] <BtbN> Yeah, that's new [11:20:47 CEST] <BtbN> I like how https://developer.nvidia.com/FFmpeg has a GitHub link for ffmpeg that links to git.ffmpeg.org [11:24:01 CEST] <durandal_1707> nobody knows answer to my question? [11:24:26 CEST] <rcombs> the EULA lists a bunch of files that are allowed to be redistributed, and most of the headers aren't on it, but there's a decent chance that a derivative work of simple header files like these aren't subject to the EULA anyway [11:24:34 CEST] <rcombs> durandal_1707: slice threading, as opposed to frame threading? [11:24:46 CEST] <rcombs> or as opposed to single-threaded [11:29:42 CEST] <durandal_1707> rcombs: i added slice-threading to process several channels at once on dsd/dst audio decoders, and when its enabled its approx 2x times slower [11:30:00 CEST] <durandal_1707> compared to single threads [11:30:19 CEST] <rcombs> oh, DSD as in the audio codec [11:31:11 CEST] <rcombs> isn't DSD decoding basically trivial? shouldn't that be memory-bound? [11:31:14 CEST] <durandal_1707> why its becomes 2 times slower than 1 threads [11:32:07 CEST] <nevcairiel> DST at least should benefit from threading [11:32:15 CEST] <durandal_1707> rcombs: its pretty slow here on intel celeron N3050 crappy cpu [11:32:45 CEST] <durandal_1707> nevcairiel: it should not be 2x slower, at leaast it should be little slower than single thread [11:33:30 CEST] <durandal_1707> both should benefit, because its doing conversion from DSD to PCM [11:33:42 CEST] <durandal_1707> and this is quite slow [11:34:49 CEST] <rcombs> durandal_1707: well, post your code? [11:34:55 CEST] <rcombs> and profile it? [11:35:25 CEST] <durandal_1707> rcombs: see ML patches [11:35:53 CEST] <BtbN> rcombs, it's also a bit of the issue that you cannot reproduce the shader blobs without getting a compiler that's behind an EULA [11:35:55 CEST] <durandal_1707> i'm now on crappy windows 7 so dunno how to profile it [11:36:08 CEST] <rcombs> BtbN: you can build with clang, as demonstrated above [11:36:18 CEST] <rcombs> (but then the headers are behind EULA, yes) [11:36:25 CEST] <BtbN> Not without still getting the same SDK, for the libs. [11:36:32 CEST] <rcombs> you don't need the libs [11:36:40 CEST] <rcombs> just the headers [11:36:50 CEST] <BtbN> You need the libs to link the kernel [11:36:51 CEST] <rcombs> (but yes they're under the same EULA) [11:36:59 CEST] <rcombs> only at runtime, via ffnvcodec [11:37:49 CEST] <BtbN> pretty sure nvcc insists on having the libs for the linker step [11:39:36 CEST] <BtbN> I won't oppose removing non-free from it, given that the CUDA SDK is now a simple download [11:39:37 CEST] <rcombs> there's no linker step here [11:39:55 CEST] <rcombs> NVCC is just generating a .ptx, which is a text ASM file [11:40:14 CEST] <rcombs> the build scripts then wrap that in a string literal in a .c [11:40:30 CEST] <rcombs> which is passed to the CUDA lib via ffnvcodec at runtime [11:40:43 CEST] <BtbN> I know, I wrote the build scripts for that. But nvcc is weird. [11:41:21 CEST] <rcombs> I guess NVCC might be doing something dumb, I haven't tested it with the scripts missing [11:41:29 CEST] <rcombs> *libs [11:41:32 CEST] <rcombs> but clang's fine without them, at least [11:42:25 CEST] <nevcairiel> does clang produce identical output? [11:51:44 CEST] <rcombs> tried a couple of optimization levels and nope [11:52:09 CEST] <rcombs> (though GPL doesn't require that the user be able to produce a bit-identical replication build, just a functionally-equivalent one) [11:53:29 CEST] <rcombs> honestly though I might prefer making a little header file that just declares the stuff ffmpeg uses and building these with clang by default [11:54:28 CEST] <nevcairiel> is the image output identical, and the performance s imilar? [11:54:58 CEST] <nevcairiel> beause that would classify as "functionally equivalent" [11:55:00 CEST] <rcombs> I'll need to have someone with an actual nvidia card test that [11:55:12 CEST] <rcombs> I'd be pretty surprised if it wasn't, though [11:55:34 CEST] <nevcairiel> i could easily see performance going wrong, tbh [12:11:42 CEST] <durandal_1707> Lynne: what delays SIMD for tx? i need it for showspectrum, to remove power of 2 size limitation [13:39:35 CEST] <durandal_1707> looks like slowdown is because of crappy CPU [13:40:48 CEST] <durandal_1707> can anybody confirm? just apply dsd patch and test with http://www.2l.no/hires/ dsd files (take one of 5.1) [13:41:15 CEST] <JEEB> I can test when I get home [13:43:07 CEST] <durandal_1707> JEEB: concentrate on chair and your job :) [13:51:25 CEST] <cone-420> ffmpeg 03Steven Liu 07master:23678462c0a3: avformat/hlsenc: Fix overflow of int for durations compute [13:54:28 CEST] <rcombs> nevcairiel: alright when building with the actual headers, clang emits some questionable code involving function calls for 1-instruction externs, and extern data symbol accesses for stuff you can get from a special register [13:54:47 CEST] <rcombs> https://gist.github.com/f714d2531e00275b4c9aaf05801f9bdf <-- this variant fixes all that, it now generates code that looks pretty similar to NVCC's [14:01:43 CEST] <nevcairiel> using assembly to make a compiler behave doesnt inspire confidence in said compiler [14:19:39 CEST] <Lynne> durandal_1707: dunno, worked on it last night and got pretty far with the 2x4 point fft [14:20:29 CEST] <Lynne> still need to do the pass macro to combine them and then rewrite the 15-point fft, but not feeling good right about now [14:33:36 CEST] <black> Hello ! How can I save AVPacket side_data in a persistent way (using h.264 in .mp4) ? [16:35:25 CEST] <cone-420> ffmpeg 03Paul B Mahol 07master:630ea6b07f88: avcodec/cfhd: add bayer support [16:58:41 CEST] <kierank> durandal_1707: should I open ticket for transform-type=2 [17:07:05 CEST] <durandal_1707> kierank: feel free to do it, i have working patch at home, but still do not understand why every 2nd frame is only 24bytes and actually null frame [17:07:17 CEST] <kierank> durandal_1707: skip frame I guess? [17:07:36 CEST] <durandal_1707> pointless waste of resources [17:07:45 CEST] <kierank> needed maybe for cfr avi [17:08:27 CEST] <durandal_1707> dunno, i havent encountered real P frame, all frames are I but different transform [17:35:16 CEST] <cone-420> ffmpeg 03Guo, Yejun 07master:df8db345523f: dnn: add layer pad which is equivalent to tf.pad [17:35:16 CEST] <cone-420> ffmpeg 03Guo, Yejun 07master:3805aae47966: fate: add unit test for dnn-layer-pad [17:35:18 CEST] <cone-420> ffmpeg 03Guo, Yejun 07master:ccbab41039af: dnn: convert tf.pad to native model in python script, and load/execute it in the c code. [18:08:23 CEST] <durandal_1707> cehoyos: you should also list cfhd improvements into your speech, not just vc1 [18:08:40 CEST] <cehoyos> I will test them;-) [18:08:50 CEST] <cehoyos> Do I misremember the limitations of direct rendering? [18:21:27 CEST] <durandal_1707> cehoyos: what are limitations of DR? [18:21:48 CEST] <cehoyos> I thought you could either not read or only write once or not read and write again. [18:22:10 CEST] <cehoyos> Because that's how graphic card hardware surfaces worked once upon a time [18:23:28 CEST] <cehoyos> gtg [19:21:09 CEST] <kierank> durandal_1707: i have no idea what carl is talking about [19:21:12 CEST] <kierank> write only memory [19:21:37 CEST] <durandal_1707> kierank: old libavfilter had something like nonsense, write only once [19:22:32 CEST] <j-b> wut? [19:29:15 CEST] <durandal_1707> actually it have nothing to do with previous FFmpeg code, its just something taken out of wild [21:03:30 CEST] <cone-420> ffmpeg 03Mark Thompson 07master:f9b8503639c0: cbs_h264: Fix missing inferred colour description fields [21:03:31 CEST] <cone-420> ffmpeg 03Mark Thompson 07master:b123d0780ec2: h264_metadata: Support overscan_appropriate_flag [21:03:45 CEST] <durandal_1707> anyone tried dsddec patch to make sure it is faster on modern CPU? [21:30:52 CEST] <BtbN> nevcairiel, nvidia themselves use clang now iirc, so I doubt there is a problem [21:33:59 CEST] <taliho> Hello, I'm working on ZMQ option for URLProtocol. [21:34:26 CEST] <taliho> Am I right in understanding that it's not possible to control the minimum size of the buffer in the read operation: int (*url_read)( URLContext *h, unsigned char *buf, int size) ? [21:34:47 CEST] <taliho> I see that there is a min_packet_size in URLProtocol, but from what I can tell, it only affects the write operation. [21:39:18 CEST] <taliho> I plan to use AVFifoBuffer with a read operation running in a separate thread, but I wanted to do a simple example first that avoids mutexes [22:59:35 CEST] <cone-420> ffmpeg 03Michael Niedermayer 07master:009ec8dc3345: avcodec/eatgv: Check remaining size after the keyframe header [22:59:37 CEST] <cone-420> ffmpeg 03Michael Niedermayer 07master:5ffb8e879389: avcodec/eatqi: Check for minimum frame size [23:11:35 CEST] <cehoyos> So direct rendering does not imply restrictions on accessing the destination frame? [23:11:37 CEST] <cehoyos> I find that surprising [23:17:59 CEST] <BBB> cehoyos: I don't think it's defined as such [23:18:31 CEST] <cehoyos> You mean there were never any restrictions on accessing destination frames when doing direct rendering? [23:18:35 CEST] <BBB> yes [23:18:46 CEST] <BBB> it may be intended as such by some people using it [23:18:47 CEST] <BBB> but [23:18:49 CEST] <cehoyos> Historically speaking, I am quite sure this is not correct. [23:18:51 CEST] <BBB> codecs don't do it that way [23:19:30 CEST] <BBB> I understand why you'd want to reduce read access if it were in distinct memory on GPU [23:19:33 CEST] <cehoyos> I believe a bug was introduced (possibly a long time ago) and spread within FFmpeg... [23:19:46 CEST] <BBB> but that's not how most decoders I've looked at and/or worked on use it [23:19:57 CEST] <cehoyos> Iirc, you simply cannot read data from (some) hardware surfaces [23:20:10 CEST] <BBB> I understand [23:20:53 CEST] <BBB> my expectation is that if such memory locations were used with the user-supplied frame-buffer API (request-frame), then things would work pretty shittily [23:21:06 CEST] <BBB> particularly with more modern codecs such as h264/vp8 etc. [23:21:11 CEST] <BBB> ("""modern""") [23:21:14 CEST] <cehoyos> So what does "direct rendering" mean if not that gpu hardware may be accessed? [23:21:34 CEST] <BBB> it means that data becomes available on a line-by-line basis [23:21:46 CEST] <cehoyos> If h264 supported direct rendering, I am sure it did work [23:21:47 CEST] <BBB> "we are now done up until mby=16" [23:22:15 CEST] <cehoyos> And I thought libavcodec only returns frames? [23:22:30 CEST] <BBB> there's a callback to indicate lines being done [23:23:06 CEST] <cehoyos> So basically an existing flag changed its meaning at some point? [23:23:54 CEST] <Lynne> you're both wrong and confused [23:24:40 CEST] <BBB> I don't know whether it changed meaning, I just now how I interpreted it and how (afaict) it was used in codecs I looked at [23:24:45 CEST] <Lynne> direct rendering just lets the user give memory to decode into, there were nevery any special requirements but alignment [23:25:04 CEST] <Lynne> it doesn't imply gpu, access order or anything like that [23:25:04 CEST] <BBB> but if you say that's previously it was used in a different way (this may or may not be true, I don't know), then yes [23:25:10 CEST] <Lynne> for that we have hardware frames [23:25:49 CEST] <Lynne> it wasn't used in a different way, there wasn't a "way" specified in the first place [23:26:07 CEST] <BBB> the callback is draw_horiz_band [23:26:35 CEST] <BBB> vp3 uses it, for example [23:26:52 CEST] <BBB> I was under the impression vp8 used it also, but that was probably removed when it started supporting slice threading [23:26:59 CEST] <BBB> (or anyway, it currently does not use it) [23:27:32 CEST] <Lynne> that callback also gives no guarantees about writes [23:27:39 CEST] <cehoyos> Lynne: Could you stay out of this? This is about a flag introduced a long time before you became active here so it is unlikely that you know what this is about [23:28:00 CEST] <Lynne> well, no, because I've used the API enough to know exactly all about it [23:28:06 CEST] <cehoyos> That's unlikely [23:28:52 CEST] <Lynne> you can choose to not believe me too, that works [23:30:01 CEST] <BBB> Lynne: my udnerstanding is that the callback basically says "I'm done with data up until this vertical point now, this will not be modified further" [23:30:19 CEST] <BBB> so the "guarantee" is that we will not write above some vertical location after that callback is called [23:30:31 CEST] <jkqxz> BBB: That is AV_CODEC_CAP_DRAW_HORIZ_BAND, which is orthogonal to AV_CODEC_CAP_DR1. [23:30:38 CEST] <Lynne> yes, but we can write below [23:30:43 CEST] <BBB> yes we can [23:31:40 CEST] <Lynne> hence we can skip pixels, hence in general, we can write and seek to arbitrary locations [23:32:28 CEST] <Lynne> only imposed order is when the callback is active and used [23:32:56 CEST] <Lynne> its the same type of confusion someone else had when they didn't understand memory in packets [23:33:24 CEST] <Lynne> until you submit a packet to output you can seek the bit writer to the start and write whatever you've missed [23:33:34 CEST] <BBB> jkqxz: hm... maybe I mis-remember then [23:33:46 CEST] <BBB> (trying to go through git history to see, but not having an easy time ...) [23:37:23 CEST] <kierank> 22:30:33 <"jkqxz> BBB: That is AV_CODEC_CAP_DRAW_HORIZ_BAND, which is orthogonal to AV_CODEC_CAP_DR1. [23:37:23 CEST] <kierank> yes [23:38:04 CEST] <kierank> DR1 is just, "here use your own memory". In the past you had to allocate edges as well but most codecs are EDGE_EMU now [23:57:13 CEST] <rcombs> nevcairiel: it's more like, the official headers define some basic function calls and extern data accesses, and the NVCC compiler magically transforms those to specialized instructions, but clang doesn't have whatever hardcoded magic that is, so I just have to define the relevant intrinsics for it [00:00:00 CEST] --- Tue Jul 30 2019

1 0

ffmpeg-devel.log.20190823
by burek 24 Aug '19

24 Aug '19

[00:00:04 CEST] <thardin> how long does getting to/from greenland by boat take? [00:00:43 CEST] <durandal_1707> small or big boat? [00:01:09 CEST] <thilo> durandal_1707: whats you travel limit? Front door, your city, your country? expenses can be paid for [00:01:46 CEST] <durandal_1707> my city, the current location [00:02:25 CEST] <thilo> is there an airport in that city? [00:02:44 CEST] <durandal_1707> i just do not like traveling [00:02:45 CEST] <Compnn> can still make a product off gpl code too [00:02:49 CEST] <Compnn> no reason to even relicense [00:03:09 CEST] <durandal_1707> thilo: yes [00:03:16 CEST] <thardin> Compnn: possibly, but proprietary vendors can hide it behind a cloud [00:03:32 CEST] <thardin> of course there's always adapting it to clients' needs [00:04:08 CEST] <thilo> so if it is not Kiev and somehow not the smalles airport, that meeting might happen in your city. mind to reveal which one it is? [00:05:01 CEST] <durandal_1707> http://www.zagreb-airport.hr/en [00:07:32 CEST] <thilo> I find direct flights from Berlin, Paris, London, Vienna [00:07:47 CEST] <thilo> And the civil war is over, isn't it? [00:07:58 CEST] <durandal_1707> i do not fly [00:08:00 CEST] <thilo> Zagreb seems like a totally doable location [00:08:17 CEST] <thilo> We might do the meeting in Zagreb, that's what I'm saying [00:08:44 CEST] <durandal_1707> you do not have resources [00:09:10 CEST] <thilo> I'll have someone pay for it [00:15:06 CEST] <durandal_1707> ok then, maybe ask other people for opinions [00:15:31 CEST] <thilo> good, I'll send a proposal to the ML tomorrow [00:16:02 CEST] <TD-Linux> durandal_1707, prores is a pretty simple format. he can't be doing anything terribly complicated [00:16:05 CEST] <kierank> durandal_1707: there is not much point unless michaelni_ comes [00:16:10 CEST] <kierank> and for years we wanted michaelni_ to come to vdd [00:16:13 CEST] <kierank> and it never happened [00:16:17 CEST] <kierank> so i think it's pointless [00:16:20 CEST] <thilo> michaelni_ will never come anywhere [00:16:50 CEST] <thilo> so FFmpeg devs are checkmate by that? [00:17:05 CEST] <durandal_1707> so organize meeting in his place/room [00:17:15 CEST] <thilo> not gonna happen either [00:17:35 CEST] <thilo> are we spinning about michaelni's no-meeting policy again? [00:17:48 CEST] <kierank> well it seems paul is unhappy with the fuzzing patches which are all from michaelni_ [00:17:56 CEST] <thilo> lets just accept that, nothing will change it [00:18:06 CEST] <durandal_1707> since when is that policy? [00:18:21 CEST] <thilo> well many people are unhappy about many things, which is why we want to meet, right? [00:18:49 CEST] <thilo> I don't know, its not my policy but michaelni's [00:18:50 CEST] <durandal_1707> we can meet remotely also [00:18:59 CEST] <Compnn> thilo, spinning spinning [00:19:11 CEST] <Compnn> who is unhappy ? [00:19:16 CEST] <thilo> Compnn: dizzy already [00:19:36 CEST] <Compnn> that was other project idea, to meet in person [00:19:44 CEST] <Compnn> meet in person didnt really help that project in vdd either [00:20:09 CEST] Action: Compnn meets everyday in irc and email :p [00:20:36 CEST] <Compnn> "if we meet in person we can all be friends" is a nice ideal [00:21:11 CEST] <durandal_1707> Compnn can only meet himself?! [00:21:21 CEST] <Compnn> i was at a few vdd durandal_1707 [00:21:26 CEST] <Compnn> you can always drive there :P [00:21:35 CEST] <Compnn> or take the bus, train, etc [00:21:50 CEST] <durandal_1707> through oceans [00:22:02 CEST] <thilo> driving through croatia? even i wouldn't do that [00:22:14 CEST] <Compnn> i think i am on an island further away from you durandal_1707 :) [00:23:02 CEST] <thilo> we will see how many people would like an actual meeting. if more people really prefer remote, than so be it. in my eyes, we are long overdue for an annual meeting [00:23:14 CEST] <Compnn> where is next vdd? :P [00:23:21 CEST] <durandal_1707> tokyo [00:23:30 CEST] <Compnn> i could actually do tokyo [00:24:18 CEST] <Compnn> bleh still 10 h flight [00:24:36 CEST] <durandal_1707> which vlc devs live in japan? [00:32:53 CEST] <Compnn> not many i'd guess [00:40:48 CEST] <thardin> https://multun.net/obscure-c-features.html [02:00:06 CEST] <cone-438> ffmpeg 03Jarek Samic 07master:d3cd33ab1b23: lavfi: add utilities to reduce OpenCL boilerplate code [02:00:06 CEST] <cone-438> ffmpeg 03Jarek Samic 07master:5b5746b1e0d2: lavfi: modify avfilter_get_matrix to support separate scale factors [02:00:06 CEST] <cone-438> ffmpeg 03Jarek Samic 07master:b29c7bcbf6bc: lavfi: add deshake_opencl filter [02:41:56 CEST] <kierank> durandal_1707: none [05:12:20 CEST] <Compnn> durandal_1707, pretty much i am the only person who wants a binary codec loader in ffmpeg :D [05:12:33 CEST] <Compnn> well probably youtube would use it too [08:37:15 CEST] <JEEB> ok, so we already have an AVPacketList [08:39:43 CEST] <JEEB> but I remember we recently got some general list structure from which one could just push and pull from [08:41:53 CEST] <JEEB> ok, I guess AVPacketList works for me [12:24:36 CEST] <kurosu> I suspect I know what to do about the prores encoders (parts of the quantization are a bit wtfy) but I'd instead try to nerd-snipe Daemon404 as he is getting the experience needed atm for other reasons [12:30:02 CEST] <durandal_1707> patch welcome [12:31:46 CEST] <kurosu> My point [12:36:22 CEST] <durandal_1707> why quantization is wtfy? [12:37:48 CEST] <durandal_1707> whe should kill 2 encoders of prored by supreme one written by elvis [12:46:36 CEST] <kurosu> 1) eob 2) dead zone 3) lagrangian 4) RDO [12:48:53 CEST] <durandal_1707> please explain in details each of these points [13:00:52 CEST] <kurosu> Not going to spend that much time over this, thus why I mentioned Derek [14:40:41 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:ac77c5492f5f: tools/target_dec_fuzzer: Do not increase max_pixels [14:40:42 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:c9fcf881e69e: avcodec/idcinvideo: Add 320x240 default maximum resolution [14:40:43 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:48b86dd8a6bf: avcodec/aacdec: Add FF_CODEC_CAP_INIT_CLEANUP [15:32:39 CEST] <JEEB> wbs: first "d'uh, I'm dumb." the whole moov_written thing 8) [15:35:22 CEST] <JEEB> but at least for basic fragmentation we seem to be rolling http://up-cat.net/p/e605863c [15:46:09 CEST] <JEEB> wbs: also I am already seeing how many time-based things this would be breaking since the entries are no longer done as they get buffered first and only written when flushed xD [16:10:24 CEST] <cone-124> ffmpeg 03James Almer 07master:92c32b0f0c3e: tools/target_dec_fuzzer: use refcounted packets [16:10:44 CEST] <jamrial> durandal_1707: ^ [16:20:12 CEST] <thardin> \o/ [17:28:56 CEST] <cone-124> ffmpeg 03Jun Li 07master:0b34cdf424d6: avcodec/h264_parse: retry decoding SPS with complete NAL [19:43:18 CEST] <tmm1> shared code between avcodec and avfilter has to go into avutil? [19:46:26 CEST] <nevcairiel> could be in avcodec as well if it fits there [19:53:02 CEST] <tmm1> oh ok, so avfilter dependency on avcodec is ok [19:53:13 CEST] <tmm1> i want to add a vf_scale_{omx,v4l2} [19:54:46 CEST] <nevcairiel> ideally we abstract hardware access through the hwcontext though [20:11:24 CEST] <cone-124> ffmpeg 03elliottk 07master:711c59bc571c: Change libaom default to crf=32. [20:14:58 CEST] <kierank> durandal_1707: I need to restart my threaded fuzzing [21:42:58 CEST] <durandal_1707> kierank: ask google to do it [22:06:55 CEST] <thardin> can we fuzz google? [22:32:10 CEST] <cone-124> ffmpeg 03leozhang 07master:b2bb09bcc330: avformat/flvdec: delete unused code [22:32:12 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:965e766e4892: avcodec/rl2: set dimensions [22:32:12 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:4d4734bdc881: avcodec/lcldec: Check mthread_inlen instead of cliping [22:32:13 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:77abf3145344: avformat/mpsubdec: Check pts / duration before cast [22:32:14 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:1a0f106232f5: avcodec/pnm: Check magic bytes directly without pnm_get() [22:32:15 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:68f30567df56: avcodec/pnm: skip reading trailing bytes in get_pnm() [22:32:16 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:8a24d2cc304c: avcodec/parser: Optimize ff_combine_frame() with massivly negative next [22:32:17 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:34f6d1a7d785: avcodec/pnm_parser: Use memmove() to handle "overread" [22:32:18 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:5231e89eb9ee: avcodec/pictordec: Optimize picmemset() for single plane full lines [22:32:19 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:1c9a56b13965: avcodec/smacker: Check that not all tables are skiped [22:32:20 CEST] <cone-124> ffmpeg 03Michael Niedermayer 07master:ae3d6a337ad2: avcodec/alac: Fix multiple integer overflows in lpc_prediction() [23:13:24 CEST] <cone-124> ffmpeg 03Marton Balint 07master:6f499ae3904b: avformat/mpegtsenc: rename pcr_period variable to pcr_period_ms [23:13:25 CEST] <cone-124> ffmpeg 03Marton Balint 07master:8bf732cda69b: avformat/mpegtsenc: add support for setting PCR interval for VBR streams [23:13:26 CEST] <cone-124> ffmpeg 03Marton Balint 07master:5c119bf189c3: avformat/mpegtsenc: move some code around and simplify a bit [23:13:27 CEST] <cone-124> ffmpeg 03Marton Balint 07master:2fb550893f75: avformat/mpegtsenc: get rid of packet counting for sdt/pat/pmt [00:00:00 CEST] --- Sat Aug 24 2019

1 0

ffmpeg.log.20190807
by burek 23 Aug '19

23 Aug '19

[00:06:35 CEST] <TheAMM> Can someone quickly elaborate what the "GIF parser" in 4.2 is about [00:06:45 CEST] <TheAMM> I'm not seeing any recent major changes in gifdec [00:08:57 CEST] <BtbN> It's probably about faca28c264bee8ff93637ae69b62d5e974eee8a8..ec8502f9cb96a83704c45e94d11f2434253f9231 [00:10:12 CEST] <BtbN> if in doubt git blame the changelog [00:10:49 CEST] <furq> https://github.com/FFmpeg/FFmpeg/commits/master/libavcodec/gif.c [00:11:48 CEST] <furq> is that support for per-frame palettes i see [00:12:56 CEST] <TheAMM> hmh [00:13:02 CEST] <TheAMM> Alright, thanks [00:21:56 CEST] <durandal_1707> see lavc/gif_parser.c [04:50:55 CEST] <Dotz0cat> i have to say thanks what yall said got it working [04:51:25 CEST] <Dotz0cat> now all i have to worry about is the rain clouds and lighting [11:54:26 CEST] <Spring> are there any docs I could check out about the 'GIF parser' mentioned in the ffmpeg 4.2 changelog? [11:54:49 CEST] <Spring> as in, what has been added/changed with GIF support with this release [12:22:16 CEST] <another> relaxed: https://johnvansickle.com/ffmpeg/release-readme.txt could use some update [12:55:32 CEST] <durandal_1707> Spring: gif support was removed due patents [13:06:59 CEST] <Spring> durandal_1707, ? The patents expired years ago last I read [14:18:04 CEST] <rswarbrick> Hi all! A question about the -shortest flag. I'm running a build from master (N-94482-g6c67c8ca9a). I want to use the libvmaf binding to compare two videos with something like 'ffmpeg -i A.y4m -i B.y4m -lavfi "[0:v][1:v]libvmaf" -f null -'. This works if A and B are the same length, but gives low numbers if (say) A is shorter. Adding -shortest to the command doesn't seem to have any effect if I also use the -f flag. Is this by design? [14:18:04 CEST] <rswarbrick> If so, how to I write out a null video and also use the shorter of the two inputs? [14:20:16 CEST] <kepstin> -shortest works by pulling all the videos through the filters until one returns an eof, so the filters will see a little past the point where the final video stops [14:21:00 CEST] <kepstin> i don't know any way to do what you want other than check the video lengths in advance and trim them before the filter [14:21:02 CEST] <rswarbrick> Incidentally, this command sort of works: "ffmpeg -i A.y4m -i B.y4m -lavfi "[0:v][1:v]libvmaf" -shortest foo.y4m", except that it writes a zero-length file and gives a "conversion failed" error message. [14:21:30 CEST] <rswarbrick> kepstin: Hmm, I see. So the command above might be passing some other random rubbish to libvmaf for the start of the N+1'st frame? [14:21:46 CEST] <kepstin> no, it passes an end of file indicator to the filter. [14:21:54 CEST] <kepstin> i dunno what the filter itself does with that [14:22:04 CEST] <kepstin> (might be configurable) [14:22:20 CEST] <rswarbrick> Oh, so libvmaf will get "frame, frame, frame, EOF, some-rubbish"? [14:22:27 CEST] <rswarbrick> Or "frame, frame, frame, some-rubbish, EOF"? [14:22:40 CEST] <kepstin> ah, vmaf filter uses framesync options: https://www.ffmpeg.org/ffmpeg-filters.html#framesync [14:22:48 CEST] <kepstin> default on eof is it repeats the last seen frame [14:22:52 CEST] <kepstin> you should change that [14:22:54 CEST] <rswarbrick> Ahah! [14:23:41 CEST] <rswarbrick> Hmm. Now I have to work out the syntax... :-/ [14:24:06 CEST] <kepstin> -filter_complex [0:v][1:v]libvmaf=shortest=1 [14:24:17 CEST] <kepstin> but do read the filter syntax documentation. [14:25:26 CEST] <rswarbrick> Ah, thanks. So that means: "There is just one node in the filter graph, using libvmaf. It takes video from input streams 0 and 1. Also, it sohuld be configured by setting "shortest" to 1".? [14:25:34 CEST] <rswarbrick> *shoult [14:25:38 CEST] <rswarbrick> **should. [14:25:40 CEST] <rswarbrick> Oh dear. [14:28:25 CEST] <rswarbrick> Brilliant, it works! Thank you very much for the help. [14:32:08 CEST] <Freneticks> I try to copy a stream in mp4 format, with segmenter or hls segmenter but the output file seems always corrupt : ffprobe say : Invalid data found when processing input [14:32:25 CEST] <Freneticks> Of course i wait the segment is finished [14:32:53 CEST] <Freneticks> What I'm missing ? [15:53:44 CEST] <Freneticks> Maybe I found my problem : is mpeg-ts can be remuxed in pure h264 ? or need to be rencoded ? [15:56:17 CEST] <DHE> you may need -bsf:v h264_mp4toannexb [18:57:38 CEST] <Saccarab> what is the best way to batch merge audio files where each file has a specific start timestamp [18:57:47 CEST] <Saccarab> adelay works great but I would rather not re encode [19:04:03 CEST] <Saccarab> I've also tried demux concat and added silence between each file instead of start timestamps but that after some count of files I get synchronization issues [19:34:39 CEST] <relaxed> another: updated, thanks [20:24:14 CEST] <julesverne> .bet 12% [20:25:06 CEST] <julesverne> sorry. wrong chat [22:13:47 CEST] <ossifrage> I'm doing some experiments with trying to send video over websockets and I was wondering if someone could recommend a Media Source Extension player that is both hackable and not excessively bloated [22:15:21 CEST] <ossifrage> I gave up on every getting reasonable latency out of dash/hls, but I'm hoping that maybe some websocket horror would be able to approach what I get with rtsp [22:31:33 CEST] <ocrete> ossifrage: if you want really low latency (video call grade), then you need to go webrtc instead... [22:32:47 CEST] <ossifrage> ocrete, I'm looking for 300-500ms (which is what I get from rtsp over both udp and tcp) [22:32:55 CEST] <ocrete> yeah then that's webrtc.. [22:33:36 CEST] <ossifrage> I'm going to see what I get with websockets first before having to deal with the extra complexity of webrtc [22:58:01 CEST] <ossifrage> I can get ~1GOP of latency just serving an infinite mp4 file over http, but that sucks because it is bursty [00:00:00 CEST] --- Thu Aug 8 2019

1 0