[Ffmpeg-devel-irc] ffmpeg.log.20190828

[burek]

[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.png
[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