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

[burek]

[00:13:15 CET] <ricemuffinball> why does x264 have such a crappy version # system
[00:14:09 CET] <furq> did you ask in #x264
[00:14:20 CET] <ricemuffinball> yes, that room is deaed
[00:14:37 CET] <furq> well then keep asking it every five minutes until they answer you
[00:14:48 CET] <ricemuffinball> thank you ffmpeg for not using crappy version # system like x264
[00:20:58 CET] <BtbN> don't they just count up?
[00:23:12 CET] <pink_mist> apparently that's crappy
[00:23:43 CET] <pink_mist> perhaps they should restart at -1 and count down
[00:26:21 CET] <ricemuffinball> lol @  even an user from x264 cannot give me the latest version of x264
[00:27:01 CET] <ricemuffinball> [15:19] <ricemuffinball> why does x264 have such a crappy version # system
[00:27:02 CET] <ricemuffinball> [15:20] <JEEB> in what sense
[00:27:03 CET] <ricemuffinball> [15:21] <ricemuffinball> what is the lastest version of x264 now
[00:27:04 CET] <ricemuffinball> [15:21] <ricemuffinball> i bet most people don't even know
[00:27:05 CET] <ricemuffinball> [15:22] <JEEB> do you mean the master or stable branch?
[00:27:05 CET] <another> linext: if you just want to record, you should put '-c copy' after the input
[00:27:06 CET] <ricemuffinball> [15:22] <ricemuffinball> because of crappy version # system
[00:27:07 CET] <ricemuffinball> [15:22] <ricemuffinball> stable
[00:27:08 CET] <ricemuffinball> [15:23] <JEEB> and yes, the version number is twofold. the most user visible one is just a number going upwards and the hash mentioned there is more useful looking at the history. the number is mostly to see if one version is later in the history than the other
[00:27:09 CET] <ricemuffinball> [15:23] <JEEB> then separately there's API versions which change every time a thing is changed in the API (feature added, removed etc)
[00:27:10 CET] <ricemuffinball> [15:23] <ricemuffinball> lol you can't even name it right now
[00:27:11 CET] <ricemuffinball> [15:23] <ricemuffinball> even you can't even say it
[00:27:12 CET] <ricemuffinball> [15:23] <ricemuffinball> i know latest version of ffmpeg and x265 right now
[00:27:13 CET] <ricemuffinball> [15:24] <ricemuffinball> 4.1.1  3.0
[00:27:14 CET] <ricemuffinball> [15:24] <ricemuffinball> yet you can't even name x264 version #  after 5 min
[00:27:18 CET] <BtbN> can you not?
[00:33:11 CET] <linext> another: added, what's it do?
[00:33:18 CET] <linext> was the video being re-encoded?
[00:33:39 CET] <JEEB> if you don't set an encoder then FFmpeg picks
[00:33:53 CET] <JEEB> you have lists for different containers and it will pick the first that it has an encoder for
[00:34:14 CET] <linext> is it better to let ffmpeg re-encode in case the stream has errors?
[00:43:04 CET] <DHE> I just realized I have patches to submit against ffmpeg still sitting...
[04:04:06 CET] <Felishia> does anyone know how I can use ffmpeg to crop a 3gp file?
[04:04:11 CET] <Felishia> every time I try I get errors
[04:04:32 CET] <Felishia> Automatic encoder selection failed for output stream #0:1. Default encoder for format 3gp (codec amr_nb) is probably disabled.
[04:04:57 CET] <Felishia> The specified picture size of 1920x1080 is not valid for the H.263 codec.
[04:05:10 CET] <Felishia> Valid sizes are 128x96, 176x144, 352x288, 704x576, and 1408x1152. Try H.263+
[04:05:25 CET] <Felishia> Unknown encoder 'H.263+'
[04:11:45 CET] <DHE> you probably want -c copy on your commandline
[04:14:22 CET] <pink_mist> does that work with cropping?
[04:14:56 CET] <klaxa> no
[04:20:44 CET] <Felishia> DHE: it wurked :D
[04:20:48 CET] <Felishia> thanks thanks
[04:34:29 CET] <pink_mist> well okay then
[08:27:40 CET] <cards> Q: When FFMPEG merges an H624 MPEG AVC video with an MPEG AAC (mp4a) audio, it uses Opus Audio codec.  Even changed the sample rate from 44100 Hz to 48000 Hz
[08:27:49 CET] <cards> Why doesn't it just keep the original AAC
[08:56:10 CET] <furq> cards: -c:a copy
[08:56:18 CET] <furq> not sure which container you were using that defaults to opus though
[08:56:41 CET] <cards> It was put into an mkv
[08:56:54 CET] <furq> vorbis is still the default for mkv for some reason
[08:57:01 CET] <furq> maybe it's opus if you don't have libvorbis
[08:57:08 CET] <cards> huh.
[08:57:24 CET] <cards> I thought it should be able to containerize AAC just fine without re-encoding
[09:01:27 CET] <furq> it can, it's just not the default
[09:37:30 CET] <fling> cards: use -c copy to prevent any reencoding
[09:39:02 CET] <cards> fling, thanks.  I'll mention that too for the yt-dl project, which sends the command to ffmpeg
[09:39:52 CET] <fling> cards: you don't need this for youtube-dl
[09:39:58 CET] <fling> cards: youtube-dl does not reencode by the default
[09:40:05 CET] <cards> it does by default
[09:40:18 CET] <fling> cards: give me an example, I never seen this behavior.
[09:40:26 CET] <cards> https://www.youtube.com/watch?v=2ZL0tbOZYhE
[09:40:31 CET] <fling> And the command is?
[09:40:58 CET] <cards> no parameters beside that url
[09:41:09 CET] <fling> No config file also?
[09:42:13 CET] <cards> none
[09:42:46 CET] <fling> cards: no reencode happening here, just merging into mkv with ffmpeg
[09:43:05 CET] <cards> check the audio codec now
[09:43:10 CET] <cards> was AAC now Opus
[09:43:20 CET] <furq> well yeah youtube serves both
[09:43:29 CET] <fling> cards: was?
[09:43:36 CET] <cards> um. that m4a was AAC.  Now it's Opus.
[09:43:41 CET] <furq> youtube-dl has always done that with youtube for some reason
[09:43:49 CET] <furq> it defaults to h264 and opus in mkv
[09:43:51 CET] <fling> cards: what do you mean by was? When you uploaded it?
[09:43:57 CET] <cards> no
[09:44:03 CET] <cards> when you downloaded it, it started off as AAC
[09:44:20 CET] <cards> when it gets packaged into your mkv, it becomes Opus
[09:44:26 CET] <cards> this all happened on your computer
[09:44:41 CET] <furq> what
[09:44:50 CET] <furq> what command did you run
[09:45:13 CET] <cards> youtube-dl.exe https://www.youtube.com/watch?v=2ZL0tbOZYhE
[09:45:20 CET] <fling> cards: it downloads opus -> youtube-dl -x https://www.youtube.com/watch?v=2ZL0tbOZYhE
[09:45:26 CET] <fling> cards: Stream #0:0(eng): Audio: opus, 48000 Hz, stereo, fltp (default)
[09:45:48 CET] <cards> really?
[09:45:54 CET] <furq> yeah
[09:45:59 CET] <cards> When is it deciding to switch between AAC and Opus
[09:46:02 CET] <fling> cards: use ffprobe to check it for yourself
[09:46:05 CET] <furq> are you assuming it's mp4 because it says it's downloading an mp4
[09:46:08 CET] <furq> because that's just the video
[09:46:14 CET] <cards> that's just the video
[09:46:14 CET] <furq> assuming it's aac
[09:46:17 CET] <cards> I'm talking about the audio
[09:46:24 CET] <Mavrik> Yeah, youtube is serving both split for awhile now.
[09:46:26 CET] <furq> well yeah where does it say aac
[09:46:26 CET] <fling> it is downloading opus in webm container
[09:46:31 CET] <cards> i know it's split
[09:46:39 CET] <fling> Not just both but a lot of formats
[09:46:40 CET] <cards> but it downloads the m4a not the webm
[09:46:56 CET] <cards> i'm going to try again with -k so it keeps the downloads
[09:47:00 CET] <cards> after merge
[09:47:14 CET] <fling> cards: try `youtube-dl -F https://www.youtube.com/watch?v=2ZL0tbOZYhE`
[09:47:44 CET] <furq> [youtube] playlist Crew Demo-1 Mission: Collected 2 video ids (downloading 2 of them)
[09:47:47 CET] <furq> huh
[09:47:50 CET] <furq> how is this a playlist
[09:48:07 CET] <furq> the second video, whatever it is, doesn't have opus audio yet
[09:48:08 CET] <cards> spacex does that.  it's "switch view"
[09:48:10 CET] <furq> so that might be the problem
[09:48:50 CET] <cards> so you can switch between video feed and google earth trajectory feed
[09:49:12 CET] <furq> anyway you can just use -f mp4 if you want to force it to use aac for both
[09:49:31 CET] <cards> i don't know if that's the problem.  looking at the console, it doesn't start playing with the 2nd video until the 1st video is already made into mkv
[09:49:37 CET] <furq> the webm is usually higher quality though
[09:49:50 CET] <cards> I want the AAC codec though
[09:55:33 CET] <cards> so if I use --merge-output-format mp4, is it supposed to prefer downloadking the AAC .m4a so that it can be merged into an mp4 container
[10:24:45 CET] <cards> There's nothing I can do to tell youtube-dl which format audio to download.  if it would just download the AAC .m4a, it could be merged into the .mp4 container.  But it's downloading mixed formats which raises a WARNING CANNOT MERGE
[10:25:11 CET] <cards> so I guess this isn't exactly ffmpeg's fault afterall
[10:32:25 CET] <another> cards: of course you can select what to download
[10:32:49 CET] <another> -f
[10:33:57 CET] <another> -f m4a+mp4
[10:35:47 CET] <another> -f bestvideo+m4a
[10:38:14 CET] <another> you might wanna play with the formats a bit. it can be a bit tricky to have youtube-dl always select what you want
[10:52:21 CET] <ricemuffinball> what does these 2 do? strong-intra-smoothing=0:rect=0   and should i use 0 or 1
[13:37:00 CET] <match_it> hi all. A question: Is ffserver still alive ?
[13:39:43 CET] <JEEB> match_it: no. it has been removed quite some time ago. there was a completely separate "proper" API client made which might attempt into the future to be an "ffserver", but it's not the same thing.
[13:40:58 CET] <JEEB> for most use cases you can either utilize ffmpeg.c itself and in cases where something has to be provided to external clients through HTTP or so, some media server (which can be either a separate application or a module in an existing HTTP server)
[13:42:20 CET] <match_it> thanks JEEB - so, what you suggest as media server ?
[13:42:34 CET] <JEEB> what is your use case?
[13:43:43 CET] <match_it> my case is to upstream from some sources to a VPS server and then to broadcast to Web players
[13:44:11 CET] <match_it> some sources are some clients (let's say 12)
[13:44:23 CET] <match_it> broadcast to 200 clients
[13:44:50 CET] <JEEB> well, in theory even ffmpeg.c can itself output HLS or DASH into any HTTP server as long as you white list your encoders to be able to POST/RENAME/DELETE
[13:45:04 CET] <JEEB> so you don't really need any more of a media server there
[13:45:13 CET] <JEEB> if the HTTP "streaming" things are what you need
[13:45:43 CET] <JEEB> for example https://www.ffmpeg.org/ffmpeg-all.html#hls-2
[13:45:51 CET] <JEEB> the output for this can be a HTTP URL
[13:49:20 CET] <match_it> JEEB , in your experience, is a standard VPS suitable for 200 viewers (at 480/320px) over http ?
[13:50:37 CET] <match_it> It's my first experience to output video for so many clients, I would figure out if I'm completely wrong
[13:54:07 CET] <JEEB> no idea, you could use locust or something to script a load test if you want. but you don't really need a lot of CPU for just serving content (since you're not doing dynamic packaging), it's mostly I/O and bandwidth that you should be calculating
[13:54:31 CET] <match_it> infact
[13:54:55 CET] <match_it> thanks JEEB
[13:55:00 CET] <match_it> thanks all
[13:55:45 CET] <BtbN> match_it, you will run into bandwidth issues with way fewer viewers, even if you have a gigabit line for yourself
[13:55:55 CET] <DHE> can confirm
[13:57:07 CET] <match_it> mmmm
[13:57:51 CET] <match_it> p2p protocols can help ?
[13:59:35 CET] <ricemuffinball> why doesn't opus file show bitrate whenever it's muxed into video file?
[14:00:49 CET] <JEEB> ricemuffinball: probably because calculation of the bit rate is not implemented in whatever container you are dealing with
[14:01:14 CET] <ricemuffinball> jeeb it works with other audio codec
[14:01:16 CET] <JEEB> which depending on the file format can mean going through the whole thing start to finish
[14:01:38 CET] <JEEB> ricemuffinball: and my comment still stands. if the value's not there the calculation is not there
[14:01:42 CET] <ricemuffinball> jeeb so are you blaming the container or the opus ?
[14:01:46 CET] <JEEB> no
[14:02:02 CET] <ricemuffinball> i just want to know whose fault it is then
[14:02:15 CET] <JEEB> I have no fricking idea :P
[14:02:31 CET] <ricemuffinball> jeeb i think you do know
[14:02:48 CET] <JEEB> no I do not unless I start digging in the code and to be honest it's a goddamn sunday
[14:03:02 CET] <JEEB> not to mention that it depends on the container 100% and you haven't even told that part
[14:03:16 CET] <ricemuffinball> jeeb mkv
[14:04:52 CET] <JEEB> ok, so at the very least to get an accurate average bit rate you would have to parse all the indexes. not sure what the worst case thing for that is. but anyways, you're welcome to check how other audio formats' bit rate is set in that case in libavformat's matroska related files
[14:05:58 CET] <ricemuffinball> i do remember aac having this issue with mkv as well (but not on mp4)
[14:06:15 CET] <ricemuffinball> but over the years it got fixed
[14:06:33 CET] <BtbN> Why is that issue even an issue?
[14:06:53 CET] <ricemuffinball> btbn because it showed perfectly fine with mp4
[14:07:01 CET] <BtbN> And why does it matter?
[14:07:06 CET] <ricemuffinball> btbn i care
[14:07:59 CET] <furq> if this is mediainfo then it only works for mkv if the audio stream is cbr
[14:08:07 CET] <furq> or if there's only one vbr stream in the file, more accuraetly
[14:08:12 CET] <ricemuffinball> i care if audio i am listening to is 128k or 256k or 80k  etc
[14:08:27 CET] <BtbN> What if it's VBR?
[14:08:37 CET] <furq> if it's vbr it didn't work last i checked
[14:08:39 CET] <JEEB> many players calculate their own averages anyways
[14:08:48 CET] <furq> also yeah your player will tell you the real bitrate if it's any good
[14:08:48 CET] <JEEB> like mpv does if you press big-i
[14:08:59 CET] <JEEB> you get it in the stats over a running window
[14:09:09 CET] <furq> either I works
[14:09:13 CET] <JEEB> because unsurprisingly quite a few things are VBR nowadays
[14:09:25 CET] <JEEB> yes, big-i just keeps it around until you press that around
[14:09:46 CET] <furq> BtbN: mediainfo does it by just subtracting the cbr bitrate(s) from the total bitrate of the file
[14:10:02 CET] <furq> if there's more than one vbr stream then it has no way of guessing
[14:10:11 CET] <JEEB> well, you can do the full file parsing
[14:10:15 CET] <JEEB> or at least indices if it's mp4
[14:10:24 CET] <furq> sure but they understandably don't want to do that
[14:10:26 CET] <JEEB> anyways, in libavformat I have no idea how it sets the AVStreams' bitrate field
[14:10:36 CET] <ricemuffinball> if mediainfo has a way to find this, why doesn't mediainfo work with  opus/mkv
[14:10:43 CET] <furq> because of all of the things i just said
[14:11:30 CET] <ricemuffinball> so whose fault is this
[14:11:42 CET] <ricemuffinball> everybod is blaming each other
[14:11:51 CET] <mux> yours
[14:12:03 CET] <furq> it's both mediainfo and matroska's fault and they both know about it and have no intention of fixing it
[14:12:04 CET] <JEEB> I don't think anyone here is blaming anyone
[14:12:13 CET] <furq> "fixing"
[14:12:22 CET] <JEEB> it's just reasons why some applications would not be doing the full monty
[14:12:27 CET] <JEEB> to get the data
[14:12:42 CET] <JEEB> because getting the overall size of a multiplexed track is not always simple
[14:12:52 CET] <JEEB> + overall duration at hte same time
[14:13:14 CET] <ricemuffinball> furq wow, i like that you are only one here who has balls to say that
[14:13:27 CET] <ricemuffinball> <furq> it's both mediainfo and matroska's fault
[14:13:39 CET] <furq> thanks for omitting the bit where i said it's not a problem
[14:13:48 CET] <ricemuffinball> furq who do you say is more of a fault?
[14:14:06 CET] <furq> 13:11:51 ( mux) yours
[14:14:06 CET] <ricemuffinball> furq, you sure opus has no fault in this?
[14:14:10 CET] <furq> starting to come around to this point of view
[14:14:32 CET] <match_it> JEEB : I think to roll back to ver 3.4 - do you know if ffserver was discontinued for any particular reason ?
[14:14:47 CET] <JEEB> match_it: nobody wanted to maintain it and it was barely working for many use cases
[14:14:47 CET] <ricemuffinball> i remember aac/mkv had this problem too  when  aac/mp4  mp3/mkv mp3/mkv  all worked fine
[14:15:14 CET] <JEEB> if the audio format has a bit rate field that's a possible lead. or the first X megabytes of packets are parsed and a guesstimate is formed
[14:15:38 CET] <JEEB> but neither of those are the actual data because things can change
[14:15:41 CET] <JEEB> of course users don't care :P
[14:15:45 CET] <JEEB> they just want to see a number
[14:15:54 CET] <JEEB> whether that number is the reality or not is whole different
[14:15:55 CET] <ricemuffinball> furq  also if ffprobe cannot acomplish this either, shouldn't you also fault  ffmpeg
[14:17:44 CET] <pink_mist> it's not a fault
[14:17:48 CET] <pink_mist> it's intended
[14:19:22 CET] <JEEB> ricemuffinball: this is basically the reason why often bit rate is omitted: https://megumin.fushizen.eu/screenshots/dvbinspector/2017-05-mx_mux.png
[14:19:35 CET] <JEEB> if you take for example the light blue as audio, and yellow as video
[14:20:15 CET] <JEEB> of course it still doesn't explain apparent randomness in if you get a value or not :P
[14:20:22 CET] <JEEB> which is a bad thing, yes
[14:20:52 CET] <ricemuffinball> jeeb but that doesn't explain why  aac/mp4 worked fine but aac/mkv didn't work  6 years ago
[14:21:10 CET] <JEEB> of course not, see my second/third sentences
[14:21:15 CET] <ricemuffinball> and mp3 always worked
[14:21:23 CET] <JEEB> ahahahahaha
[14:21:24 CET] <JEEB> no
[14:21:36 CET] <JEEB> I'm pretty sure you can feed a raw mp3 file
[14:21:44 CET] <JEEB> and get a completely bogus value out of it
[14:22:02 CET] <JEEB> often mp3 encoders were rather static so you did often get a relatively close value
[14:22:41 CET] <JEEB> you would probably always get *a* value, which is all that matters to a user
[14:22:52 CET] <JEEB> whether that value was bogus or not didn't seem to matter
[14:26:01 CET] <ricemuffinball> i just came across another aac/mkv file that does not show bitrate
[14:26:20 CET] <ricemuffinball> ffmpeg -i R:\a.mkv -vcodec copy -acodec copy -movflags faststart R:\b.mp4
[14:26:32 CET] <ricemuffinball> i did this and ffprobe the b.mp4 and it shows
[14:27:40 CET] <ricemuffinball> i am so confused
[14:27:40 CET] <pink_mist> I'm pretty sure JEEB already explained why to you
[14:28:15 CET] <ricemuffinball> pink_mist not about not working with mkv and working with mp4
[14:28:24 CET] <pink_mist> yes he did
[14:28:29 CET] <ricemuffinball> where?
[14:28:46 CET] <pink_mist> 14:10 <JEEB> or at least indices if it's mp4
[14:29:06 CET] <ricemuffinball> that doesn't explain anything
[14:29:19 CET] <pink_mist> yes it does
[14:34:52 CET] <ricemuffinball> furq  does  ffprobe depend on mediainfo to fix a problem first to get it working
[14:35:28 CET] <JEEB> not at all, but it is highly unlikely to make it any more consistent unless someone cares to make a full parsing mode
[14:36:05 CET] <JEEB> of course, what you care about is not consistness nor correctness of the value. you just want *a* value. or am I incorrect?
[14:36:08 CET] <ricemuffinball> then why did they type:  <furq> it's both mediainfo and matroska's fault
[14:36:41 CET] <ricemuffinball> jeeb of course i care about correctness of the value
[14:37:13 CET] <JEEB> ok, then I'll have to break the bad news to you that it probably is currently bogus in a lot of cases. congratulations.
[14:37:14 CET] <ricemuffinball> Audio: Opus 48000Hz stereo 3072kbps [A: Stereo (opus, 48000 Hz, stereo) [default]]
[14:37:29 CET] <ricemuffinball> that value means nothing
[14:37:49 CET] <JEEB> and not only in FFmpeg or related tools
[14:40:02 CET] <ricemuffinball> i just got this error:  opus in MP4 support is experimental, add '-strict -2' if you want to use it.
[14:40:18 CET] <JEEB> yup, that was never finished. and I hate that message because -2 is "experimental" which is human-readable
[14:40:26 CET] <ricemuffinball> why is that experimental, youtube uses opus mp4 all the time
[14:40:39 CET] <JEEB> yup, and nobody waited for the specification to finsh
[14:40:40 CET] <BtbN> Because there's no spec I assume
[14:40:44 CET] <JEEB> there is a spec
[14:40:46 CET] <JEEB> just never finished
[14:40:54 CET] <ricemuffinball> then why is youtube using opus/mp4
[14:40:59 CET] <BtbN> Because
[14:41:00 CET] <JEEB> http://opus-codec.org/docs/opus_in_isobmff.html
[14:42:09 CET] <JEEB> neither mozilla nor google decided to wait for it to get finished since it was considered "good enough" for the youtube use case. although I think youtube still uses opus in webm (matroska)?
[14:43:01 CET] <ricemuffinball> if the spec is unfinished why doesn't  opus/mp4 have this bitrate issue?   Stream #0:1(und): Audio: opus (Opus / 0x7375704F), 48000 Hz, mono, fltp, 59 kb/s (default)
[14:43:28 CET] <JEEB> because mp4 if it is indexed has an index, and libavformat calculates the average bit rate over the index
[14:43:39 CET] <JEEB> st->codecpar->bit_rate = sc->data_size * 8 * sc->time_scale / st->duration;
[14:43:49 CET] <JEEB> data size * 8 => size of stream in bits
[14:44:00 CET] <BtbN> That 59kb/s looks very inaccurate
[14:44:14 CET] <JEEB> it's an average, that's what it is probably
[14:44:18 CET] <BtbN> And says nothing over the quality really
[14:44:25 CET] <JEEB> of course not
[14:44:34 CET] <ricemuffinball> btbn let me extract just the opus and i will do the ffprobe
[14:44:39 CET] <BtbN> It could be 300kbps during high complexity, but the audio is very simple most of the time
[14:45:08 CET] <JEEB> anyways, I will go enjoy the outside and for a while, it's a nice sunday weather with snow here :P
[14:47:39 CET] <ricemuffinball> i extracted just the audio to a.mka  :  Bit rate                       : 59.7 kb/s
[14:48:20 CET] <BtbN> so?
[14:48:26 CET] <BtbN> Still doesn't mean much
[14:48:29 CET] <ricemuffinball> <BtbN> That 59kb/s looks very inaccurate  : so you are wrong
[14:49:03 CET] <BtbN> I feel like you just don't want to understand...
[14:49:33 CET] <BtbN> That bitrate is the AVERAGE. It says nothing about the quality or really anything important.
[14:49:46 CET] <ricemuffinball> i can always find the audio bitrate if i extract just the audio file and ffprobing it
[14:50:08 CET] <BtbN> I don't get what you're going at, and I don't care anymore. Have a nice day.
[14:50:46 CET] <Blacker47> youtube uses dash where audio and video are not muxed.
[14:51:01 CET] <ricemuffinball> JEEB youtube would never use MKV, since browsers have problem with mkv
[14:52:16 CET] <ricemuffinball> Blacker47 i dbout that
[14:52:35 CET] <ricemuffinball> youtube uses mp4/webm
[14:52:46 CET] <pink_mist> ricemuffinball: hint: webm *IS* mkv
[14:52:54 CET] <pink_mist> ricemuffinball: also, it certainly does use DASH too.
[14:52:54 CET] <bencoh> sorta
[14:52:57 CET] <ricemuffinball> pink_mist no it's not
[14:53:12 CET] <ricemuffinball> mkv does not work on firefox
[14:53:23 CET] <Blacker47> [14:52:46] <pink_mist> ricemuffinball: hint: webm *IS* mkv <-- what?
[14:55:16 CET] <ricemuffinball> webm only supports opus/vorbis audio
[14:55:23 CET] <ricemuffinball> mkv supports a lot of audio
[15:09:31 CET] <another> ricemuffinball: i suggest you read up a bit about webm, mkv, dash
[15:09:41 CET] <another> wikipedia is a good place to start
[15:10:06 CET] <another> also youtube-dl with -F might give you some insight
[15:10:52 CET] <another> and since you seem to be *really* into bitrates: https://megumin.fushizen.eu/screenshots/dvbinspector/2017-05-mx_mux.png
[15:11:09 CET] <another> damn. wrong link. https://github.com/zeroepoch/plotbitrate
[15:11:58 CET] <Mavrik> oh man, where was this project when I needed it :P
[15:15:27 CET] <another> it's sometimes broken
[15:15:32 CET] <another> like on mp3
[15:27:46 CET] <ricemuffinball> somebody in #opus is saying opus supports 44.1khz and 96khz,  is this BS?
[15:28:17 CET] <durandal_1707> nope
[15:28:55 CET] <ricemuffinball> somebody here told me opus only support 48khz
[15:32:33 CET] <durandal_1707> sure, just use mpeg-h then
[15:33:00 CET] <ricemuffinball> huh
[16:01:43 CET] <another> i guess you can make a custom version of opus that does https://wiki.xiph.org/OpusFAQ#What_is_Opus_Custom.3F
[16:02:07 CET] <another> but unless you have really good reasons, you probably shouldn't
[17:03:41 CET] <ricemuffinball> <opus-dev> ffmpeg is unquestionably great software for multimedia, but some of the decisions that were made about its behaviour can only be described as stupid.
[17:04:01 CET] <ricemuffinball> wow
[17:04:59 CET] <ricemuffinball> opus people dissing on ffmpeg
[17:05:10 CET] <Kuukunen> yea, maybe a group of developers who disagree with the decisions should band together and make a fork... it's open source after all!
[17:06:30 CET] <durandal_1707> ricemuffinball: ask him what decisions
[17:06:35 CET] <Ke> if you would fork every software that had some * in it, you even would run out of disk space before going insane
[17:07:46 CET] <Ke> you could just as well go all templeos
[17:09:03 CET] <DHE> I've found some things in ffmpeg that needed changing, but all my diff can fit on a single screen
[17:11:55 CET] <ricemuffinball> durandal_1707  that ffprobe/ffmpeg doesn't properly work with opus and mkv
[17:12:18 CET] <durandal_1707> nonsense
[17:13:45 CET] <ricemuffinball> well they are blaming on ffmpeg
[17:14:13 CET] <ricemuffinball> and they won't take responsibility of birate not showing properly
[17:19:20 CET] <durandal_1707> ricemuffinball: ffmpeg/ffprobe show bitrate only if it is stored in bitstream.
[17:19:41 CET] <ricemuffinball> does mp4 store in bitstream?
[17:19:45 CET] <durandal_1707> ffmpeg may calculate it in some cases too
[17:19:53 CET] <ricemuffinball> opus/mp4  store in bitstream?
[17:20:28 CET] <durandal_1707> ricemuffinball: search source code for bit_rate
[17:20:43 CET] <ricemuffinball> durandal_1707  yes or no
[17:21:36 CET] <durandal_1707> ricemuffinball: no
[17:21:58 CET] <ricemuffinball> then why does  opus/mp4  bitrate show fine with ffprobe
[17:22:33 CET] <ricemuffinball> if it's not stored in bitstream
[17:24:50 CET] <durandal_1707> ricemuffinball: from container or codec itself? there are 2 bit_rates
[17:25:13 CET] <ricemuffinball> from mp4 container
[17:25:16 CET] <durandal_1707> opus as codec itself does not have such metadata
[17:25:34 CET] <durandal_1707> ricemuffinball: that is mp4 feature and not opus one
[17:26:08 CET] <ricemuffinball> then why opus/mkv cannot display audio bitrate
[17:26:33 CET] <ricemuffinball> opus people are blaming on ffmpeg
[17:28:37 CET] <durandal_1707> ricemuffinball: ffprobe with opus/mkv shows bit_rate just fine
[17:28:47 CET] <ricemuffinball> not here
[17:29:01 CET] <durandal_1707> your fault
[17:29:08 CET] <ricemuffinball> how is that my fault
[17:29:15 CET] <ricemuffinball> i am using 4.1.1 binary
[17:29:34 CET] <durandal_1707> and how you got opus/mkv?
[17:29:54 CET] <ricemuffinball> i muxed it using ffmpeg
[17:29:59 CET] <durandal_1707> how?
[17:30:32 CET] <ricemuffinball> using the mux command
[17:30:48 CET] <mux> using the ricemuffinball command
[17:31:00 CET] <ricemuffinball> mux huh?
[17:31:07 CET] <durandal_1707> full uncut FFmpeg console output missing
[17:31:18 CET] <ricemuffinball> durandal_1707 huh?
[17:32:30 CET] <pink_mist> ricemuffinball: he means that if you actually want help with your issue, you need to show the exact commandline you used, and the full output it generated, not just "using the mux command"
[17:33:09 CET] <ricemuffinball> oh
[17:34:01 CET] <ricemuffinball> ffmpeg -i R:\a.mp4 -vcodec copy -acodec copy R:\b.mkv
[17:35:11 CET] <durandal_1707> ricemuffinball: and a.mp4 have bitrate info?
[17:35:18 CET] <ricemuffinball> durandal_1707 correct
[17:35:54 CET] <ricemuffinball> durandal_1707  6 years ago   aac/mkv  had the same issue
[17:36:05 CET] <durandal_1707> can you share/upload a.mp4 somewhere?
[17:36:28 CET] <ricemuffinball> yes if i can cut it
[17:36:56 CET] <CounterPillow> I've heard there's some juicy shit in here
[17:37:22 CET] <ricemuffinball> CounterPillow who told you that
[17:37:42 CET] <CounterPillow> Oh there is the juicy shit in question.
[17:38:44 CET] <ricemuffinball> durandal_1707  how did  ffmpeg  fix the  aac/mkv issue 6 years ago
[17:39:17 CET] <andy1978> How is it supposed to get the object type for a mp4 container from the codec_id? There is a list in isom.c, in my example I'm looking for AV_CODEC_ID_H264 which results in 0x21 which I have to give as fourcc. But isn't there a public API for this?
[17:39:52 CET] <JEEB> andy1978: so what are you trying to do exactly?
[17:40:09 CET] <JEEB> that would then help us help you what you could/should use
[17:40:33 CET] <ricemuffinball> where can i download ffmpeg from 6 years ago
[17:40:45 CET] <CounterPillow> There's a version control system
[17:41:01 CET] <durandal_1707> ricemuffinball: some developer posted patch on mailing list fixing bug and voila...
[17:41:05 CET] <CounterPillow> you can check out any commit of ffmpeg you'd like, going very far back.
[17:41:22 CET] <durandal_1707> yes, even into dark ages
[17:41:35 CET] <ricemuffinball> durandal_1707  and how do i find the name of that dev
[17:41:46 CET] <ricemuffinball> who fixed the aac/mkv bitrate bug
[17:42:21 CET] <CounterPillow> by searching
[17:43:02 CET] <durandal_1707> ricemuffinball: find right commit, by doing bisect
[17:43:22 CET] <ricemuffinball> no idea how to do that
[17:43:48 CET] <durandal_1707> https://git-scm.com/docs/git-bisect
[17:43:57 CET] <ricemuffinball> ffmpeg-3.2.4-win32-static.zip is oldest i can find
[17:44:29 CET] <durandal_1707> you need to build it yourself, if you seek that guy
[17:46:28 CET] <durandal_1707> but i could not reproduce bitrate bug with -c:a copy from mp4 to mka for opus stream created by ffmpeg
[17:46:37 CET] <iive> if you are still after the opus thing, it is probably in libopus
[17:46:58 CET] <ricemuffinball> durandal_1707 are you serious
[17:47:16 CET] <ricemuffinball> durandal_1707 wait, why mka and not mkv
[17:47:25 CET] <CounterPillow> literally the same thing
[17:47:30 CET] <iive> a for audio
[17:47:33 CET] <iive> v for video
[17:47:35 CET] <ricemuffinball> no, mkv has video on it
[17:47:50 CET] <CounterPillow> it's literally the same container
[17:48:00 CET] <ricemuffinball> but mka doesn't have bitrate bug
[17:48:02 CET] <ricemuffinball> only mkv
[17:48:15 CET] <durandal_1707> lets seee...
[17:48:54 CET] <ricemuffinball> durandal_1707  6 years ago   aac/mkv  had the same issue
[17:49:04 CET] <ricemuffinball> when aac/mp4 worked fine
[17:52:35 CET] <andy1978> JEEB: Okay, from the beginning: I want to use CvVideoWriter_FFMPEG to create a video. This expects a fourcc. The format is guessed using "av_guess_format". After that the codec_id is retreived using "av_codec_get_id(fmt->codec_tag, fourcc)". This returns AV_CODEC_ID_H264 if I give "0x21" as fourcc. But I use the opposit way. How to I retrieve the tag for a given container and codec
[17:53:49 CET] <andy1978> The relevant code is here: https://github.com/opencv/opencv/blob/master/modules/videoio/src/cap_ffmpeg_impl.hpp#L2047
[17:56:18 CET] <ricemuffinball> did ffmpeg used to have  libvo_aacenc ?
[17:56:32 CET] <JEEB> yes, but it was found to be crap even compared to the internal encoder, and thus removed
[17:56:40 CET] <ricemuffinball> jeeb , i see
[17:56:47 CET] <ricemuffinball> even worse than faac ?
[17:56:51 CET] <JEEB> yes
[17:56:53 CET] <JEEB> it was very, very bad
[17:56:55 CET] <ricemuffinball> jeeb , i see
[17:57:00 CET] <JEEB> google then licensed fraunhofer's fdk-aac
[17:57:03 CET] <JEEB> which made sense
[17:57:20 CET] <JEEB> (which is why fdk-aac is open source at all - the releases come through GOOG)
[17:57:44 CET] <ricemuffinball> you mean google used  libvo_aacenc  before licensing fdk-aac ?
[17:57:48 CET] <JEEB> yes
[17:57:59 CET] <JEEB> both are extracted from the android code
[17:58:11 CET] <JEEB> as in, someone cuts out the library since it's useful for others
[17:58:15 CET] <ricemuffinball> why didn't google juse use  faac then
[17:58:15 CET] <JEEB> or that's how it felt at first
[17:58:28 CET] <JEEB> because faac had licensing issues among other things. also tried to be GPL if I recall
[17:58:31 CET] <JEEB> GOOG no want GPL
[17:58:57 CET] <JEEB> (basically faac contained reference code which was not compatible with the license under which faac was)
[17:59:02 CET] <ricemuffinball> so google owns fdk-aac now completely ?
[17:59:48 CET] <JEEB> it licenses it and probably has some sort of copyright on what is released as part of android. then any additions on top of that are copyright of the people adding things
[18:00:31 CET] <ricemuffinball> so it it safe to assume  aac codec you see on youtube videos are most likely fdk-aac
[18:01:02 CET] <JEEB> no idea. what youtube does internall can be rather random and have its own reasons
[18:01:03 CET] <ricemuffinball> although i see more and more opus now on youtube
[18:01:18 CET] <ricemuffinball> opus/vp9
[18:01:23 CET] <JEEB> andy1978: ok, do you really mean av_guess_format?
[18:01:28 CET] <JEEB> or is it av_guess_codec?
[18:01:51 CET] <andy1978> JEEB: This would be a workaround what I want: https://bpaste.net/show/0486d72291ec
[18:02:51 CET] <JEEB> for me it sounds like you want the H.264 AVCodec, and then you can get its default values for stuff
[18:02:58 CET] <ricemuffinball> jeeb what do you think about libav people
[18:03:43 CET] <JEEB> I've contributed to Libav as well. They're enjoying their life doing other things mostly now. and then there's people who only use a limited feature set and for them having knowledge of what exactly is there in the code is useful
[18:03:58 CET] <JEEB> there is no animosity between most people from either project. thankfully.
[18:04:14 CET] <JEEB> and at this point why would there be any
[18:05:05 CET] <ricemuffinball> didn't they steal from ffmpeg and created their own
[18:05:08 CET] <JEEB> no?
[18:05:12 CET] <ricemuffinball> traitors
[18:05:14 CET] <durandal_1707> ffmpeg does not parse BPS(-eng/...) as bitrate from matroska stuff
[18:05:21 CET] <JEEB> durandal_1707: and to be honest it shouldn't
[18:05:29 CET] <JEEB> like, that data has nothing to do with reality
[18:05:33 CET] <JEEB> unlike mp4 indexes
[18:05:44 CET] <durandal_1707> but, but it is used
[18:05:47 CET] <ricemuffinball> JEEB are you kidding me
[18:05:58 CET] <JEEB> if we start reading that crap we might as well accept that we just want a value
[18:05:59 CET] <durandal_1707> https://github.com/HandBrake/HandBrake/issues/1609
[18:06:01 CET] <JEEB> not a correct value
[18:06:07 CET] <JEEB> but some value
[18:06:18 CET] <ricemuffinball> jeeb:   then explain this:   6 years ago   aac/mkv  had the same issue and ffprobe couldn't read the bitrate
[18:06:30 CET] <JEEB> fuck if I know and I don't honestly give a fuck.
[18:06:43 CET] <JEEB> I already wasted enough time trying to explain  you how different formats are different
[18:07:02 CET] <JEEB> and that for having an exact average on every clip  you would have to possibly index the whole file
[18:07:11 CET] <JEEB> but I don't know the internal guesstimate logic anyways
[18:07:24 CET] <JEEB> -> when and how FFmpeg decides to set a stream's bit rate is random
[18:07:31 CET] <ricemuffinball> jeeb how is ffprobe  figuring out the birate on aac/mkv then
[18:07:33 CET] <ricemuffinball> now
[18:07:48 CET] <JEEB> I don't care.
[18:07:57 CET] <JEEB> please stop highlighting me
[18:08:20 CET] <ricemuffinball> you are making this channel look bafd
[18:08:27 CET] <JEEB> if someone added a hack I don't really care
[18:08:41 CET] <JEEB> if the AAC bit stream happens to have a bit rate field, I don't really care
[18:08:58 CET] <ricemuffinball> i cared 6 years ago, and i care now
[18:09:10 CET] <JEEB> great for you
[18:09:49 CET] <JEEB> my opinion is that FFmpeg should be honest in giving people numbers like that, which it currently in some cases is - and in some cases isn't. at that point it's just arbitrary and you should never expect the value.
[18:10:04 CET] <JEEB> for mp4 there usually is an index from which you can calculate the full size of a single stream within the container
[18:10:10 CET] <JEEB> thus you get bit rates there
[18:10:21 CET] <ricemuffinball> jeeb are you saying  bitrate info that ffprobe is diplaying now is incorrect?
[18:10:23 CET] <JEEB> why AAC in matroska (with other streams) gets a bit rate? no effing idea
[18:10:45 CET] <JEEB> ricemuffinball: 100% depends, it is everything from calculation (mp4 with an index available) to guesstimates
[18:11:19 CET] <ricemuffinball> jeeb they look pretty accurate to me
[18:11:34 CET] <JEEB> for your specific examples, maybe
[18:11:41 CET] <JEEB> I'm just telling you the whole range of shit in there
[18:12:04 CET] <ricemuffinball> durandal_1707 do you have any idea what jeeb is talking about, because i don't
[18:12:56 CET] <ricemuffinball> jeeb are you saying MKV is flawed container?
[18:13:32 CET] <JEEB> not really, after all being able to get the full accurate size of a stream is not really something really required for playback or seeking
[18:13:59 CET] <durandal_1707> mkv have bunch of statistics that ffmpeg do not write
[18:14:12 CET] <JEEB> because they're not linked to the actual file
[18:14:17 CET] <ricemuffinball> jeeb also webbrowsers does not seem to like mkv
[18:14:37 CET] <JEEB> ricemuffinball: please stop talking to me
[18:14:47 CET] <ricemuffinball> that's harsh
[18:15:12 CET] <durandal_1707> just do: /ignore ricemuffinball
[18:15:41 CET] <JEEB> andy1978: so you have an output file name that leads to an AVFormat format, and then you'd use av_guess_codec to get the default AVCodecID for the format guessed
[18:15:52 CET] <JEEB> and then from that AVCodecID I bet you could get its default 4cc if you really need it
[18:19:18 CET] <JEEB> andy1978: although the fourcc also depends on the output container in some cases
[18:19:34 CET] <andy1978> JEEB: yes, which is the case for mp4
[18:20:18 CET] <JEEB> anyways, I'm still trying to grasp why exactly you need a fourcc for the whole shebang
[18:20:27 CET] <JEEB> other than possibly some 3rd party interface only takes those
[18:20:28 CET] <andy1978> JEEB: for others 4cc is used but for mp4 it's the "object type" as listed here: http://mp4ra.org/#/object_types
[18:20:48 CET] <JEEB> but if you're muxing with libavformat
[18:21:12 CET] <JEEB> then I'm not sure if that's needed as long as you have initialized the muxer and using the correct AVCodecIDs for the AVStreams that you add
[18:21:49 CET] <andy1978> JEEB: I think the best would be to drop the fourcc in the API and directly use the AVCodecID
[18:22:25 CET] <JEEB> andy1978: is this our API or what where you think it's required?
[18:22:29 CET] <JEEB> I'm still kind of confuzzled with that
[18:22:38 CET] <JEEB> since you seem to be opening a new AVFormatContexxt
[18:22:40 CET] <JEEB> *xt
[18:22:56 CET] <andy1978> JEEB: No, the API I'm talking about is the OpenCV one, not the ffmpeg :-D
[18:23:25 CET] <JEEB> ok, so you're initializing the encoder through that instead of libavcodec?
[18:23:31 CET] <JEEB> or what exactly?
[18:23:44 CET] <andy1978> JEEB: But the OpenCV API expects the fourcc (which is really the fourcc for all other container formats than mp4, but the object type for mp4)
[18:24:06 CET] <JEEB> well for something like H.264 I bet it really doesn't matter which you pass it as long as you pass some of the general ones :P
[18:24:19 CET] <JEEB> although I'm still not grasping what exactly is needed here
[18:24:35 CET] <andy1978> JEEB: btw, thank you very much for helping
[18:26:59 CET] <JEEB> andy1978: so something like this most likely http://svn.ffmpeg.org/doxygen/trunk/group__lavf__misc.html#gabe1a7b6824078229c69b75c71053c035
[18:27:53 CET] <andy1978> JEEB: The OpenCV VideoWriter class (which I want to use in a wrapper for GNU Octave) expects a filename and fourcc to initialize the encoder. It internally uses av_guess_format for the format and "av_codec_get_id(fmt->codec_tag, fourcc)" to get the codec_id. And here is the problem: To get a H264 encoded video in a mp4 container I have to pass "foo.mp4" and fourcc=0x21
[18:28:38 CET] <JEEB> yes
[18:28:41 CET] <JEEB> whch should work
[18:28:45 CET] <JEEB> with the function I just posted
[18:29:40 CET] <JEEB> since it takes in the list of tags from your AVOutputFormat
[18:29:48 CET] <JEEB> and then the AVCodecID
[18:30:04 CET] <JEEB> then you pass it a pointer to the unsigned int where you want your tag
[18:31:39 CET] <andy1978> JEEB: wouldn't be this basically the same as https://bpaste.net/show/0486d72291ec ?
[18:31:59 CET] <JEEB> more or less, just a newer interface for it
[18:32:09 CET] <JEEB> also 0x21 doesn't sound like a valid fourcc
[18:33:14 CET] <JEEB> it's just a !
[18:39:03 CET] <andy1978> JEEB: yes, but av_codec_get_id returns AV_CODEC_ID_H264 for this https://bpaste.net/show/79dfc6c64cf0
[18:40:14 CET] <JEEB> uhh, that's the AVCodecID
[18:40:29 CET] <JEEB> and that's 100% dependant on the compiler and version due to how enums can work
[18:40:47 CET] <JEEB> for example looking at what clang came up with AV_CODEC_ID_H264 is 0x1b
[18:40:49 CET] <andy1978> I'm just comparing the IDs, that they are equal
[18:41:53 CET] <andy1978> as you can see, they are both 0x1c here, possible that the would be 0xdeadbeef on arm but thats not the point :-D
[18:42:44 CET] <JEEB> that's because you're getting the AVCodecID from that function, which still has nothing to do with fourccs...
[18:43:31 CET] <JEEB> like, there's "get me the default AVCodecID for this output format"
[18:43:41 CET] <andy1978> JEEB: okay, this is a very valuable info for me. until know I thought "tag" and "fourcc" would be used interchangably
[18:43:46 CET] <JEEB> and then there's av_codec_get_tag2 to get the tag from that
[18:44:07 CET] <JEEB> andy1978: it more or less is, but I'm just failing to see the logic in there that's all
[18:45:33 CET] <JEEB> since usually if you need a tag of the default AVCodecID, you would go 1) get your AVOutputFormat , 2) get the default AVCodecID for that container for video|audio|subtitles, 3) get the tag from the AVOutputFormat.codec_tag list with av_codec_get_tag2
[18:45:45 CET] <JEEB> I forgot the exact function for 2) but I'm pretty sure it's in the doxy
[18:46:32 CET] <JEEB> av_guess_codec
[18:46:34 CET] <JEEB> that was it
[18:46:34 CET] <andy1978> JEEB: for 2) yes, fmt->video_codec
[18:46:46 CET] <andy1978> gives the default codec for that format
[18:47:10 CET] <JEEB> dunno, there's an API function that so I've used it always
[18:47:14 CET] <JEEB> *for that
[18:47:22 CET] <andy1978> JEEB: have you had a look at isom.c around line 37?
[18:47:35 CET] <JEEB> yes but I'm not sure if that has anything to do with that
[18:47:43 CET] <JEEB> you just need a fourcc for H.264 (f.ex.)
[18:47:50 CET] <andy1978> just to be clear that we are talking about the same "oject type"
[18:48:01 CET] <JEEB> you wouldn't be utilizing that fourcc for the muxing since you've already gotten it
[18:48:14 CET] <JEEB> the encoder shouldn't care which fourcc you give it as long as you give it some matching H.264
[18:49:09 CET] <JEEB> and if the FourCC is the only thing passed through, then you could just re-parse that into an AVCodecID in the last part of your chain most likely
[18:49:25 CET] <JEEB> and then you can once again create an AVOutputFormat and just add a stream with that AVCodecID
[18:49:50 CET] <JEEB> either I'm missing something, or you don't actually have a problem
[18:50:13 CET] <andy1978> the problem is, that av_codec_get_id returns 0 is I give h264 as tag: https://bpaste.net/show/3de2ea0aeeda
[18:51:05 CET] <JEEB> so that's the thing after the encoding that receives the FourCC?
[18:51:11 CET] <JEEB> so you've been talking about two parts of it now
[18:51:23 CET] <JEEB> one where you have to get the FourCC for the default AVCodecID
[18:51:34 CET] <JEEB> and another where you receive a FourCC from the encoding part?
[18:51:43 CET] <JEEB> because you seem to be trying to do two different things
[18:52:18 CET] <andy1978> JEEB: let me read your answers again and again, I'm not that fast :-D
[19:02:15 CET] <andy1978> JEEB: hm, even "av_codec_get_tag" returns 0x21 (a single !) for mp4 AVOutputFormat and default video_codec.
[19:02:56 CET] <andy1978> JEEB: I have to read and understand your points and dig deeper into the code, thank you much for your time
[19:04:15 CET] <JEEB> andy1978: anyways AVCodecTag is a struct
[19:04:33 CET] <JEEB> and then there's the "tag" which is something
[19:04:50 CET] <JEEB> the MKTAG thing
[19:05:03 CET] <JEEB> (aka an int)
[19:06:12 CET] <JEEB> andy1978: also I'm still not sure if you need this sort of stuff but there's stuff like avformat_get_riff_video_tags and avformat_get_mov_video_tags (and same for audio)
[19:07:22 CET] <JEEB> andy1978: and I still wasn't sure if you are talking about one side of the puzzle ("I just need to feed a 'fourcc' to an API"), or the other ("I get a 'fourcc' from an API and need to open a muxer to write encoded packets")
[19:07:33 CET] <JEEB> since your code seemed to try and handle both
[19:14:23 CET] <andy1978> JEEB: My initial question was just the first part "I need to get a fourcc to feed into an API" so that I get H264 in a mp4 container
[19:15:44 CET] <JEEB> argh, I'm getting tackled in inconsistencies. you say "feed a FourCC to get H.264 in a specific container", while FourCCs would only decide the format into which/from which to encode/decode
[19:16:17 CET] <JEEB> thus that interface should be the encoder interface, which then probably would pass the FourCC through?
[19:16:29 CET] <JEEB> together with the file name
[19:16:50 CET] <JEEB> anyways, please continue :P
[19:19:22 CET] <andy1978> JEEB: nono, I said "feed into an API to get H264 in mp4". I already described that inside the function av_guess_format is used to guess the container format from the filename and then the fourcc is used to get the codec
[19:19:49 CET] <JEEB> ok, so the interfaces for encoding and muxing are not separate? interesting
[19:20:30 CET] <JEEB> anyways, this still confuses me
[19:20:58 CET] <JEEB> since you've been talking about both generating a FourCC like thing, as well as receiving one and going back to AVCodecID for it
[19:21:37 CET] <andy1978> waht confused me is that "h264" isn't a valid tag for mp4 containers and instead a mysterious object-type has to be used
[19:21:56 CET] <the_gamer> how ro record pulse audio? i tried https://trac.ffmpeg.org/wiki/Capture/Desktop but there is no audio in the output
[19:26:53 CET] <JEEB> andy1978: well ff_mp4_obj_type shouldn't get utilized if you are looking at an mp4 AVOutputFormat's codec_tag list
[19:27:11 CET] <JEEB> it would be utilizing codec_mp4_tags from movenc.c
[19:36:25 CET] <andy1978> ah yes, ff_mp4_muxer
[19:38:19 CET] <JEEB> anyways, I could write a simple test app of trying to neutrally round trip from an avcodecid to codec tag and back
[19:38:22 CET] <JEEB> but :effort:
[19:38:48 CET] <JEEB> it definitely seems possible, even without the format being mixed in there
[23:15:27 CET] <superbia> hello there, can i use ffmpeg to record system audio (what goes trough my speakers) ?
[23:16:15 CET] <JEEB> depends highly on the OS and audio system utilized etc
[23:16:32 CET] <JEEB> for linux there's both an alsa and a pulse module so I would think you could
[23:16:55 CET] <JEEB> for windows there's directshow but you'd have to make sure that your audio output would be exported to that sub-system
[23:16:59 CET] <JEEB> for macos I don't even know
[23:17:05 CET] <superbia> is there an easy way for me to check?
[23:17:18 CET] <JEEB> which thing are we speaking of here?
[23:17:37 CET] <superbia> it's linux, i have alsa and pulse
[23:19:41 CET] <JEEB> alright, then try something like this https://ffmpeg.org/ffmpeg-devices.html#Examples-8
[23:21:22 CET] <superbia> [NULL @ 0x55b1893c4980] Unable to find a suitable output format for 'ffmpeg'
[23:21:35 CET] <superbia> that could be my fault. i probably didn't install all of the codecs yet?
[23:23:01 CET] <superbia> https://bpaste.net/show/bec0f4bc9af7
[23:23:31 CET] <JEEB> yup, you just put "ffmpeg" there twice
[23:23:54 CET] <JEEB> so it parsed it as an output path
[23:24:10 CET] <JEEB> which is why it couldn't figure out which container for output you wanted, because "ffmpeg" has no extension :P
[23:25:03 CET] <superbia> i am listening to the recording, i think it recorded my mic
[23:25:30 CET] <JEEB> check pactl or so what sort of inputs you have
[23:25:37 CET] <JEEB> then you should be able to set that name as the input
[23:27:45 CET] <superbia> whath's the command
[23:27:54 CET] <superbia> i can't find one to list the devices in the manuals
[23:28:37 CET] <JEEB> pactl list sink-inputs?
[23:29:38 CET] <JEEB> or for a full list of things, just pactl list
[23:31:23 CET] <superbia> i think i found it, is this it ? https://wiki.archlinux.org/index.php/PulseAudio/Examples#ALSA_monitor_source
[23:33:45 CET] <superbia> brb reboot to check if it's working
[23:43:17 CET] <superbia> the pulse_monitor device shows in audacity, so atleast i can record it, but i get some weird sound jerkyness
[23:43:24 CET] <superbia> as if my cpu is too slow or something like that
[23:48:43 CET] <superbia> JEEB: this command works perfectly $ ffmpeg -f alsa -i pulse_monitor /tmp/pulse.mp3
[23:49:06 CET] <superbia> after i modified my .asoundrc (linked earlier)
[23:49:09 CET] <JEEB> cool
[23:49:12 CET] <JEEB> glad it's working
[23:51:59 CET] <superbia> i am just not sure if other params are correct, like bitrate and other stuff
[23:52:17 CET] <superbia> since i know pretty much nothing about that stuff
[23:59:01 CET] <superbia> ty for help !, bedtime
[00:00:00 CET] --- Mon Mar  4 2019