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

[burek]

[00:07:25 CET] <faLUCE> hello. If I open an ac3 audio 5.1 (6 tracks) with audacity, and compress it to ac3 again (640kbps) with ffmpeg embedded on audacity, resulting audio sounds a little bit different. It seems to have a lower volume. what can cause that?
[00:12:28 CET] <faLUCE> hwo can I debug?
[00:13:16 CET] <nicolas17> no matter how high you set the bitrate, the result will be a bit different; but ear-noticeable lower volume? that's odd
[00:13:51 CET] <faLUCE> nicolas17: why do you think it will be a bit different ?
[00:13:59 CET] <nicolas17> because it's a lossy codec
[00:14:08 CET] <faLUCE> nicolas17: but 640kbps
[00:14:10 CET] <faLUCE> is high
[00:14:20 CET] <furq> six channels is also high
[00:14:30 CET] <faLUCE> furq: right
[00:14:55 CET] <nicolas17> no matter how high you set the bitrate, the result won't be bit-identical to the source audio
[00:14:57 CET] <nicolas17> but
[00:14:57 CET] <faLUCE> well. Instead of encoding again to 6 channels, which raw format can I use?
[00:15:09 CET] <nicolas17> it shouldn't cause something like lower volume
[00:15:11 CET] <faLUCE> (for 6 channels, I mean)
[00:16:26 CET] <furq> what are you doing that requires reencoding
[00:16:52 CET] <faLUCE> furq: I'm modifying some audio which is ac3
[00:17:06 CET] <faLUCE> then, after modifying I have simply to play it
[00:17:16 CET] <furq> if you're just cutting it up then you don't need to reencode for that
[00:17:40 CET] <faLUCE> well, having huge files is not so good, but anyway... this is not the first problem
[00:18:02 CET] <faLUCE> so: which raw format can I use for 6 channels?
[00:18:25 CET] <furq> flac supports multichannel
[00:18:40 CET] <faLUCE> ok, perfect
[00:18:57 CET] <faLUCE> second question: why ac3 is limited to 640kbps ?
[00:20:01 CET] <furq> that's defined in the atsc spec
[00:20:06 CET] <furq> i couldn't tell you why it's defined that way though
[00:20:16 CET] <furq> dd+/eac3 supports higher bitrates
[00:21:51 CET] <faLUCE> tnx again
[00:23:48 CET] <faLUCE> does ffmpeg support eac3 ?
[00:29:09 CET] <DHE> decoding? I believe so...
[00:30:24 CET] <faLUCE> not encoding?
[00:34:21 CET] <nicolas17> ultra high bitrate audio seems pointless, if you care that much about quality, use a lossless format
[00:35:33 CET] <faLUCE> nicolas17: why pointless? I suppose that with a size that is double of ac3 output I can obtain the same result for my ears
[00:35:42 CET] <faLUCE> with much less space occupied
[00:37:00 CET] <nicolas17> did you test how much space flac uses?
[00:40:12 CET] <faLUCE> nicolas17: you are right... more or less double of ac3
[00:48:30 CET] <faLUCE> anyway, if I open an ac3 file with audacity and save it as flac. when I play it it has a lower volume than the original
[00:48:40 CET] <faLUCE> audacity uses ffmpeg for that
[00:49:16 CET] <nicolas17> could be audacity's fault
[00:49:25 CET] <nicolas17> try saving it as wav, that should be audacity alone without ffmpeg
[00:49:57 CET] <faLUCE> nicolas17: 6 wav tracks ?
[00:58:33 CET] <faLUCE> nicolas17: same result for wav
[01:17:50 CET] <Hello71> I'm still going with replaygain
[01:38:54 CET] <kepstin> i bet the volume reduction (or possibly lack of volume increase) is applied when you open the ac3 in audacity rather than anything else.
[01:44:11 CET] <faLUCE> kepstin: this is what I'm noting right now
[01:45:03 CET] <faLUCE> kepstin: in addition, I don't understand if it's normal that 4 on 6 channels have a much lower volume than the other 2
[01:45:31 CET] <faLUCE> (this is what I see when I open the ac3 file with audacity: 4 channels with very low volume)
[04:18:47 CET] <analogical> what is the highest available quality setting when encoding aac ?
[04:19:25 CET] <analogical> -q what?
[04:34:46 CET] <lain98> i want to generate a video where the r,g,b values is the elapsed time. is that possible ?
[04:35:29 CET] <furq> analogical: there is no maximum, but the wiki suggests anything above 2 isn't worth using
[04:35:33 CET] <furq> lain98: https://ffmpeg.org/ffmpeg-filters.html#geq
[04:35:53 CET] <lain98> thanks furq
[04:37:33 CET] <lain98> also this is just way to test my application that demuxes and decodes videos. i couldnt think of a way to test those things other than encode the frame number/time information in the video itself.
[04:37:45 CET] <lain98> does ffmpeg do any such testing and how ?
[04:39:11 CET] <TheAMM> You can also use drawtext to draw frame numbers and timestamps if it's easier to view the demuxed frames rather than parse rgb/whatnot encoded values
[04:39:59 CET] <lain98> i did do that
[04:40:11 CET] <lain98> but i can automate that testing
[04:40:22 CET] <lain98> maybe ocr but thats too much
[04:40:35 CET] <lain98> *cant
[04:40:50 CET] <lain98> i've manually verified it but would like to automate it
[04:41:49 CET] <analogical> furq, what do I type if I want to encode input.wav to cbr 256kbps output.m4a
[04:41:57 CET] <furq> analogical: -b:a 256k
[04:41:59 CET] <analogical> default seems to be vbr
[04:42:08 CET] <analogical> I want cbr
[04:42:11 CET] <furq> that is cbr
[04:42:19 CET] <analogical> constant bitrate
[04:45:03 CET] <analogical> is there a way to force constant bitrate?
[05:28:49 CET] <debiandebian> Hmm, is anyone familiar with H.264 RTP Payload Format?
[07:37:35 CET] <BeerLover> I want to make a static build with libfdk_aac, which needs to run on Amazon linux. Do I need to compile it on Amazon linux? Or can I do it on my manjaro??
[07:48:02 CET] <BeerLover> Unknown option --disable-shared: https://0x0.st/zIf7.txt
[08:01:01 CET] <furq> just --enable-shared is fine
[08:01:10 CET] <furq> you'll also need --extra-ldflags="-static"
[08:01:22 CET] <furq> and static libs for all the dependencies
[08:01:27 CET] <furq> and probably --pkg-config-flags="--static"
[08:01:56 CET] <furq> also i meant --enable-static not --enable-shared obviously
[08:17:43 CET] <BeerLover> furq --extra-ldflags="-static"
[08:17:51 CET] <BeerLover> Unknown option "-enable-static".
[08:20:34 CET] <furq> the first one of those hyphens is an em dash
[08:21:47 CET] <furq> there's one in that paste in --disable-shared as well so no wonder that wasn't working
[08:33:15 CET] <lain98> i used this command to generate a video. i wanted a video that had 256 frames and each frame had r=g=b=time=frame_number. ffmpeg -f lavfi  -i nullsrc=s=512x512:d=256:r=1 -c:v libx264 -pix_fmt yuv420p -vf "geq='r=T:g=T:b=T'" test.mp4
[08:33:22 CET] <montana> which color does best compression for video/picture and which color does worst compression for video/picture?
[08:33:34 CET] <lain98> the first frame doesnt start at zero.
[08:34:28 CET] <furq> N is frame number, not T
[08:34:38 CET] <lain98> yes but i'm using 1 fps
[08:35:14 CET] <lain98> the first frame is 16 r,g,b value not 0
[08:35:28 CET] <lain98> i think it has something to do with bt601
[08:35:34 CET] <lain98> bt709 stuff
[08:35:36 CET] <furq> oh
[08:35:40 CET] <lain98> i want full range yuv
[08:36:10 CET] <furq> -color_range jpeg
[08:36:14 CET] <lain98> i checked ffmpeg -pix_fmts but nothing points to full range
[08:36:23 CET] <lain98> okay furq, thanks let me check that out
[08:36:48 CET] <furq> or -pix_fmt yuvj420p but that's deprecated iirc
[08:38:43 CET] <lain98> still starts from 16
[08:39:15 CET] <lain98> with yuvj420p it does work
[08:39:51 CET] <lain98> is there a way i could maybe avoid this deprecated pix_fmt furq.
[08:39:59 CET] <lain98> color_range didnt give me full range
[08:40:04 CET] <furq> well the replacement is color_range
[08:41:22 CET] <lain98> just to be clear i ran. ffmpeg -f lavfi  -i nullsrc=s=256x256 -c:v libx264 -pix_fmt yuv420p -color_range jpeg -vf "geq='r=T:g=T:b=T'" test.mp4
[08:41:43 CET] <furq> maybe colorspace=range=jpeg,geq...
[08:41:47 CET] <furq> and color_range
[08:41:55 CET] <lain98> okay
[08:42:08 CET] <furq> you don't need a separate -vf with lavfi inputs btw
[08:42:15 CET] <furq> you can just do -i nullsrc,colorspace,geq
[08:42:24 CET] <lain98> okay
[08:43:24 CET] <furq> i guess you actually want colorspace=range=jpeg:format=yuv420p and then drop -pix_fmt
[08:43:41 CET] <lain98> No accelerated colorspace conversion found from yuv420p to gbrp
[08:44:51 CET] <Reinhilde> wew
[08:48:20 CET] <furq> huh
[08:48:23 CET] <furq> that just deadlocks here
[08:48:33 CET] <lain98> yeah same
[08:49:34 CET] <lain98> maybe i'll just use yuvj420p since i'm most likely never to generate that video again
[08:49:37 CET] <lain98> thanks furq
[08:54:42 CET] <furq> geq,scale=out_range=full,format=yuv420p
[08:54:44 CET] <furq> that seems to work
[08:55:04 CET] <furq> there's probably a better way
[09:05:25 CET] <BeerLover> on arch I get libfdk_aac not found
[09:05:33 CET] <BeerLover> but i have it installed
[09:05:59 CET] <c_14> When building or with the system binary?
[09:06:16 CET] <BeerLover> ./configure
[09:06:40 CET] <BeerLover> https://0x0.st/zIOu.txt
[09:06:43 CET] <BeerLover> c_14
[09:07:25 CET] <c_14> does your libfdk_aac come with static libraries?
[09:07:26 CET] <furq> tail -100 ffbuild/config.log
[09:07:33 CET] <c_14> ^ and upload to a pastebin service
[09:07:35 CET] <furq> but yeah it's most likely that you don't have the static library
[09:08:02 CET] <furq> if arch has some equivalent of -dev packages then you'll need that
[09:08:13 CET] <BeerLover> https://0x0.st/zIOS.c
[09:08:44 CET] <furq> /usr/bin/ld: cannot find -lfdk-aac
[09:08:47 CET] <furq> yeah there you go
[09:09:06 CET] <furq> maybe the first time that configure error messages has ever been accurate
[09:09:10 CET] <furq> -s
[09:09:45 CET] <BeerLover> furq will static binary created on any linux work fine on other linux??
[09:10:12 CET] <furq> pretty sure it will if it's the same arch
[09:10:37 CET] <c_14> and depending on what you're liking with as long as the glibc version is similar enough (assuming you linked against glibc)
[09:11:08 CET] <BeerLover> I'll build on a VM
[09:11:19 CET] <BeerLover> doon't think arrch has libfdk-acc-dev
[09:11:32 CET] <furq> it's easy enough to build fdk yourself
[09:12:45 CET] <furq> with that said it's probably bad to build on arch because it doubtless has some ultra bleeding edge glibc
[09:13:20 CET] <c_14> building with an old version is usually not a problem
[09:13:26 CET] <c_14> It's building with too new a version that is
[09:13:34 CET] <furq> well yeah he's building on arch and then running on something else
[09:13:55 CET] <c_14> right, misread your comment
[10:24:51 CET] <BeerLover> why am i getting this error? https://0x0.st/zIO9.loog
[10:25:05 CET] <BeerLover> I built the binary successfullyt
[10:33:16 CET] <Reinhilde> 9/= 249
[10:38:53 CET] <BeerLover> Reinhilde ?
[10:39:09 CET] <Reinhilde> typographic
[10:40:57 CET] <BeerLover> https://0x0.st/zIOy.txt
[10:41:03 CET] <BeerLover> why is this wrong?
[10:42:18 CET] <ritsuka> you can't put aac in a .mp3 file
[10:58:15 CET] <BeerLover> what is pcm_s16le
[11:56:45 CET] <another> pcm signed 16 bit little-endian
[11:57:17 CET] <BeerLover> is that codec?
[11:57:39 CET] <BeerLover> i have a .mp3 file with this stream
[11:57:44 CET] <Mavrik> It's raw audio
[11:58:01 CET] <Mavrik> Not encoded at all... so not sure how you ended up having an mp3 with that >(
[11:58:05 CET] <Mavrik> Sounds like misdetection or a broken file
[11:58:21 CET] <another> well, it's encoded as pcm
[11:58:48 CET] <durandal_1707> another: does it sounds ok when played?
[11:59:40 CET] <another> durandal_1707: wrong highlight
[12:00:26 CET] <BeerLover> Mavrik another https://0x0.st/zIVz.txt
[12:00:30 CET] <BeerLover> here's the info
[12:02:14 CET] <another> looks like a wav file
[12:03:43 CET] <Mavrik> That, although ffmpeg tends to interpret anything it doesn't understand as raw
[12:09:22 CET] <durandal_1707> BeerLover: so does file sounds ok when played with ffplay?
[12:13:56 CET] <BeerLover> yeah file is goood
[14:41:36 CET] <faLUCE> Hello. Is there a way to see, with ffmpeg or ffmproge the *real* maximum volume of each of the 6 tracks on an ac3 file? When I open it with audacity it seems to lower the volume of tracks 2-6 because of the downmixing (not sure of that but it seems so, because I see very low volumes on these tracks)
[15:35:37 CET] <funnybunny2> Is ffmpeg.org down right now?
[15:36:56 CET] <DHE> down for me...
[15:39:14 CET] <funnybunny2> Is there a mirror of the API documentation anywhere?
[15:41:24 CET] <funnybunny2> nvm. archive.org has it
[15:48:57 CET] <Reinhilde> cortana is bonzi buddy
[15:49:35 CET] <funnybunny2> Looks like it's back up
[15:50:40 CET] <funnybunny2> I can't seem to find the documentation for avformat_open_input. I only see it in the source code. Is this an API function? I'm trying to find the right function to use which detects the codec I need to use based on file data
[15:52:27 CET] <funnybunny2> I need the right input to avcodec_find_decoder
[15:53:57 CET] <funnybunny2> nvm
[15:53:59 CET] <funnybunny2> Found it
[15:57:08 CET] <DHE> funnybunny2: you can run doxygen locally and have a faster copy
[16:04:34 CET] <funnybunny2> How do I know how big of a buffer to pass to av_make_error_string
[16:04:55 CET] <funnybunny2> There should be like a MAX_ERROR_STRING constant
[16:05:21 CET] <kepstin> it's actually called AV_ERROR_MAX_STRING_SIZE
[16:05:41 CET] <faLUCE> well. this is weird:  ffmpeg -i file.ts file.flac  <---- the resulting flac file has a lower volume. why ?
[16:06:04 CET] <kepstin> faLUCE: is this still the ac3 stuff?
[16:06:23 CET] <kepstin> there might be some dynamic range metadata in the ac3 which your player is using but ffmpeg discards
[16:07:04 CET] <faLUCE> kepstin: yes
[16:07:10 CET] <faLUCE> kepstin: ffmpeg bug?
[16:07:37 CET] <kepstin> hmm, missing feature maybe. iirc that ac3 feature is considered optional
[16:07:59 CET] <kepstin> it's decoding the audio correctly, and you can manually adjust the volume before re-encoding if you prefer :/
[16:08:22 CET] <faLUCE> kepstin: I'm feared it messes up channels
[16:08:23 CET] <funnybunny2> kepstin: Oh. Sorry. I didn't see it
[16:08:25 CET] <faLUCE> volumes
[16:09:22 CET] <faLUCE> kepstin: I mean: I could set the output volume when producing the file... but what if it messes up all the volumes?
[16:10:08 CET] <kepstin> faLUCE: why are you re-encoding the audio anyways instead of just copying it?
[16:10:23 CET] <faLUCE> kepstin: I need to modify it in some points
[16:10:44 CET] <faLUCE> kepstin: the same problem occurs if I open the file with audacity
[16:10:54 CET] <faLUCE> and even with another audio editor (ocenaudio)
[16:11:08 CET] <faLUCE> it shows the ts file with low volume
[16:11:13 CET] <kepstin> most of those probably use the ffmpeg ac3 decoder, so yeah
[16:11:19 CET] <faLUCE> exactly
[16:11:58 CET] <faLUCE> kepstin: I wonder if is there a version of ffmpeg that fixes this
[16:12:31 CET] <faLUCE> I use 4.1
[16:12:44 CET] <kepstin> nothing's changed regarding the ac3 decoder in years afaik.
[16:12:48 CET] <kepstin> since it works fine
[16:13:03 CET] <faLUCE> damn
[16:13:58 CET] <faLUCE> kepstin: a workaround would be knowing the maximum volume for each track
[16:14:10 CET] <faLUCE> so I can normalize them in the editor
[16:14:12 CET] <kepstin> the relative levels of each track should be correct
[16:14:32 CET] <faLUCE> kepstin: are you sure that the relative levels are correct? It can mess up all
[16:14:46 CET] <faLUCE> I don't thrust on that
[16:15:05 CET] <kepstin> note that in most ac3 tracks, at least for movies and whatnot, the front center channel typically has most of the energy. Also the lfe channel is at a higher gain than the others iirc.
[16:16:34 CET] <faLUCE> kepstin: I don't understand if with   ffmpeg -i file.ts file.flac  ffmpeg lowers the volume for all the tracks or downmixes them
[16:16:50 CET] <faLUCE> if it downmixes, then the relative volumes are different
[16:17:20 CET] <kepstin> it doesn't lower the gains, it leaves them as-is. I can't tell if it's downmixing or not unless you show more output, but since flac can handle 5.1 it's probably not.
[16:17:59 CET] <faLUCE> what kind of output do you need?
[16:18:07 CET] <kepstin> everything's working fine, don't worry about it, turn up the volume knob in your player (or use the volume filter in ffmpeg) if you want it louder.
[16:19:18 CET] <faLUCE> kepstin: I have to do many modifications. I want to be really sure
[16:24:44 CET] <funnybunny2> Is there a page at https://www.ffmpeg.org/doxygen/trunk/modules.html which just lists all the API functions?
[16:24:56 CET] <funnybunny2> I have to keep guessing which page the function is on
[16:29:47 CET] <cre8radix> Ahoy
[16:29:55 CET] <faLUCE> kepstin: I just verified that it's something more than a volume problem. I played both the files (ac3 and flac) and recorded the waveform with audacity when playing. If I normalize the flac waveform to the same level of the ac3 waveform, they are still very different
[16:30:33 CET] <kepstin> what player are you using, anyways?
[16:30:39 CET] <faLUCE> kepstin: mpv
[16:30:54 CET] <kepstin> huh, that should also be using the ffmpeg ac3 decoder
[16:31:47 CET] <faLUCE> this is bad :-(
[16:33:05 CET] <kepstin> i suspect that by default mpv is downmixing the 5.1, unless you've explicitly configured it to use multi-channel output. But i'd expect it to use the same downmix when playing ac3 or flac, huh.
[16:33:41 CET] <kepstin> i wonder if they just have an automatic volume boost on ac3 to compensate for it usually being quiet
[16:34:44 CET] <cre8radix> Hey kepstin
[16:34:54 CET] <faLUCE> kepstin: wait: if I play both of them with ffplay or mplayer they are the same
[16:35:17 CET] <kepstin> faLUCE: as i said, it's the player that's increasing the volume on the ac3.
[16:35:28 CET] <kepstin> i still have no idea why it's doing that.
[16:35:55 CET] <faLUCE> kepstin: not only it's increasing, but it is changing the relative levels
[16:37:07 CET] <kepstin> i suspect mpv is using a different value for the -drc_scale option to the ac3 decoder
[16:37:23 CET] <kepstin> ffmpeg's default is 1, but i think mpv is using something different
[16:37:36 CET] <kepstin> looks like mpv might be using 0 instead
[16:38:09 CET] <faLUCE> kepstin: file1.ts is not produced by ffmpeg, while file1.flac is made with ffmpeg
[16:38:26 CET] <faLUCE> now: file1.ts is played differently by ffplay and mpv
[16:38:38 CET] <kepstin> I have just explained why.
[16:38:39 CET] <faLUCE> while file1.flac is played the same
[16:39:12 CET] <faLUCE> kepstin: do you mean that -drc_scale is not set in file1.ts ?
[16:39:33 CET] <kepstin> that's a decoder option
[16:39:45 CET] <kepstin> it's set to a different value in mpv vs. in ffmpeg cli tool by default
[16:42:06 CET] <faLUCE> let me try by setting drc_scale in the playback
[16:42:17 CET] <kepstin> alternately, you can use the --ad-lavc-ac3drc=1 option to mpv
[16:42:26 CET] <kepstin> which makes it match ffmpeg
[16:43:35 CET] <kepstin> but yeah, if you want to decode without dynamic range compression applied, then you have to use the `-drc_scale 0` input (decoder) option in ffmpeg.
[16:44:01 CET] <kepstin> you lose the drc metadata when transcoding, of course, so you can't get it back later if you want it.
[16:44:52 CET] <faLUCE> kepstin: you were right. I just verified
[16:44:55 CET] <kepstin> note that the ac3 spec requires that drc is enabled by default, so mpv's behaviour is technically noncompliant.
[16:45:30 CET] <kepstin> but disabling drc may sound better on a high end audio system that can reproduce lots of dynamic range.
[16:46:44 CET] <faLUCE> kepstin: can I set drc_scale to 0 without re-encoding, on ffmpeg ?
[16:47:03 CET] <faLUCE> -acodec copy ?
[16:47:10 CET] <kepstin> that's a decoder setting, it applies to the decoder, when decoding.
[16:47:17 CET] <kepstin> so unless you decode it does nothing
[16:48:18 CET] <kepstin> that said, it's theoretically possible for someone to write a bsf that strips the drc metadata from the ac3, so that the drc option does nothing. but such a bsf doesn't exist in ffmpeg.
[16:48:41 CET] <faLUCE> kepstin: are you sure there's not a flag in the ac3 metadata? If I create an ac3 with audacity, even mpv seems to set drc_scale to 1
[16:48:59 CET] <pink_mist> bsf? *guessing* bitstream filter?
[16:49:09 CET] <kepstin> when you encode a new ac3 file, it doesn't have any drc metadata
[16:49:21 CET] <kepstin> the drc metadata is only added by proprietary encoders
[16:49:27 CET] <kepstin> pink_mist: yes
[16:49:40 CET] <pink_mist> thanks
[16:49:58 CET] <faLUCE> kepstin: in fact the original ac3 file is not made with ffmpeg
[16:50:17 CET] <faLUCE> kepstin: then, in the original ac3 file there should be a drc metadata
[16:50:22 CET] <faLUCE> how can I check it?
[16:50:44 CET] <kepstin> faLUCE: if setting the -drc_scale option to 0 vs 1 makes different output, then the file has drc metadata
[16:50:57 CET] <kepstin> if the output is the same, then there is no drc metadata
[16:51:22 CET] <faLUCE> kepstin: so it's not only a decoder setting
[16:51:46 CET] <kepstin> whether the drc metadata is used is a decoder setting
[16:52:03 CET] <faLUCE> ok, but I have to add to the file
[16:52:08 CET] <faLUCE> ok, but I have to add it to the file
[16:52:10 CET] <kepstin> that's what the -drc_scale option is - if set to 0 it means "do not use drc metadata", other values mean "do use it"
[16:52:28 CET] <faLUCE> ok, now I see
[16:52:42 CET] <faLUCE> so: is it possible to set drc metadata with ffmpeg ?
[16:52:45 CET] <kepstin> no
[16:52:54 CET] <faLUCE> why not?
[16:53:50 CET] <kepstin> well, actually, the answer is "technically yes, if you calculate the values yourself and write a custom tool using ffmpeg apis"
[16:54:08 CET] <kepstin> ffmpeg doesn't contain any code to calculate values to use in the metadata.
[16:54:47 CET] <faLUCE> kepstin: I want to use the same metadata of file-original.ts  on file-made-with-ffmpeg.ts
[16:55:11 CET] <faLUCE> is there a program with which I can do that?
[16:55:32 CET] <kepstin> faLUCE: not possible with any tools I know of unless you do the edits without re-encoding (on frame boundaries), which might lead to audio discontinuities :/
[16:56:47 CET] <faLUCE> kepstin: but is this metadata a header at the beginning of the file?
[16:57:38 CET] <kepstin> i'd have to check, but i think it's per-frame.
[16:58:00 CET] <kepstin> since it has to specify for different parts of the audio whether they should be made louder or quieter
[16:59:12 CET] <faLUCE> kepstin: then it could be that mpv enables and disables it depending on the current frame
[16:59:34 CET] <kepstin> no, the decoder option is either "use metadata" or "don't use metadata"
[17:00:00 CET] <kepstin> the metadata then says "adjust the playback level of this frame X louder/quieter"
[17:00:13 CET] <kepstin> or i suppose it can say "don't adjust" too :)
[17:00:17 CET] <cre8radix> your guess from last night& the original was a 21:9 aspect ratio anamorphic widescreen
[17:02:08 CET] <faLUCE> kepstin: then mpv plays the file louder because it ignores all the drc metadata by default, right ?
[17:02:17 CET] <kepstin> hmm, apparently the drc stuff is actually determined based off the dialog level metadata, actually
[17:02:23 CET] <kepstin> interesting
[17:02:31 CET] Action: kepstin found https://www.dolby.com/us/en/technologies/a-guide-to-dolby-metadata.pdf which explains a bit
[17:04:29 CET] <kepstin> dialogue level might actually be a clobal level, but it looks like it can also be set per-frame
[17:04:35 CET] <kepstin> that said, i don't know how to set it
[17:06:05 CET] <faLUCE> kepstin: ffmpeg -i file.ts file2.ts <--- file2.ts sounds at lower volume with mpv too
[17:06:35 CET] <kepstin> faLUCE: and the reason for that is obvious.
[17:06:53 CET] <faLUCE> kepstin: if I add --acodec copy, the volume with mpv is higher
[17:07:06 CET] <kepstin> yes, exactly.
[17:07:53 CET] <faLUCE> kepstin: but you told that mpv uses a default to 0. then, why on the re-encoded file this default is not 0 ?
[17:08:05 CET] <kepstin> because the ffmpeg default is 1
[17:08:17 CET] <kepstin> so when you re-encode with ffmpeg, it decodes with the drc applied
[17:08:50 CET] <faLUCE> kepstin: then it means that mpv is not using a default
[17:08:55 CET] <faLUCE> but it's reading the metadata
[17:09:03 CET] <kepstin> mpv uses a different default from ffmpeg
[17:09:52 CET] <faLUCE> sorry I don't understand. What is the drc metadata of file-original.ts ?
[17:09:55 CET] <kepstin> when you run "ffmpeg -i file.ts file2.ts", ffmpeg decodes the ac3 with drc applied, then encodes a new audio track to mp2 without any drc metadata
[17:10:24 CET] <faLUCE> ah sorry
[17:10:55 CET] <kepstin> when you run "ffmpeg -i file.ts -c copy file2.ts", ffmpeg copies the ac3 from the input to output, preserving drc metadata
[17:12:19 CET] <faLUCE> ok, now I tried ffmpeg -i file.ts -c ac3 file2.ts   <---- file2.ts is played by mpv at a lowe volume
[17:12:35 CET] <kepstin> yes, of course
[17:12:51 CET] <kepstin> take my previous chat message and replace "mp2" with "ac3"
[17:13:32 CET] <faLUCE> I'm confused, sorry. you told that mpv uses a default = 0 for drc metadata of file.ts
[17:13:45 CET] <kepstin> that's why it plays back the original file louder
[17:14:02 CET] <kepstin> mpv uses a default of 0 for the -drc_level option on the ac3 decoder
[17:14:03 CET] <faLUCE> now, given that I play file.ts loudly, this means that this file DOESN'T have drc metadata set
[17:14:15 CET] <faLUCE> right?
[17:14:16 CET] <kepstin> no, it means that the drc metadata was not used
[17:15:10 CET] <faLUCE> <kepstin> no, it means that the drc metadata was not used <--- in this case, mpv should play loudly also file2.ts (file encoded with -c ac3)
[17:15:14 CET] <kepstin> if you do "ffmpeg -drc_scale 0 -i file.ts -c ac3 file2.ts" it will be loud, because then ffmpeg decodes the ac3 with drc ignored, then encodes a new audio track to mp2 without any drc metadata
[17:15:31 CET] <kepstin> the drc was applied when *ffmpeg decoded the audio*
[17:15:38 CET] <kepstin> which is why it's quiet
[17:15:46 CET] <pink_mist> faLUCE: no, because that file was encoded from already-metadata-altered decoded audio
[17:16:48 CET] <kepstin> alternately if you do `mpv --ad-lavc-ac3drc=1 file.ts` it will be quieter
[17:19:08 CET] <kepstin> anyways, if you're gonna be editing the audio after decoding, then you need to choose whether or not to apply drc during decoding, since you won't be able to put the required meta info back later.
[17:19:40 CET] <kepstin> with any tools that i know of - it is in theory possible of course.
[17:20:22 CET] <kepstin> (and if you were going to put the meta info back, then you want to make sure you do all editing on the audio *without drc applied*)
[17:20:39 CET] <kepstin> i.e. with the -drc_scale 0 option to ffmpeg
[17:22:27 CET] <faLUCE> sorry, I really don't get it. let's call the files: file-orig.ts, file-copied.ts, file-reencoded.ts .
[17:23:15 CET] <faLUCE> now, when I play file-orig.ts with mpv, does it ignore metadata, right?
[17:23:24 CET] <pink_mist> no difference between file-orig and file-copied. file-reencoded will play lower by mpv than the other two
[17:23:40 CET] <pink_mist> right
[17:24:05 CET] <faLUCE> ok, now: why does it choose to ignore that metadata?
[17:24:33 CET] <pink_mist> because that's how the authors of mpv decided to write their code
[17:25:07 CET] <faLUCE> well, now: if this is true, then it should ignore metadata also for file-reencoded.ts, right?
[17:25:17 CET] <kepstin> no, because the reencoded file has no metadata
[17:25:20 CET] <pink_mist> file-reencoded doesn't have metadata
[17:25:22 CET] <pink_mist> but yes
[17:25:27 CET] <pink_mist> it would ignore it if it had any
[17:25:32 CET] <kepstin> ffmpeg has already applied the metadata when decoding, before re-encoding
[17:27:23 CET] <faLUCE> kepstin: pink_mist:   so, "ffmpeg -drc_scale 0 -i file.ts -c ac3 file2.ts"  (as kepstin suggested) is the way to produce an encoded file which will sound louder with mpv
[17:27:50 CET] <pink_mist> yes, that makes ffmpeg ignore the metadata too
[17:27:57 CET] <kepstin> yes, but in that file you can't use the `mpv --ad-lavc-ac3drc=1` command to play it back quietly
[17:28:02 CET] <kepstin> because there's no metadata
[17:28:16 CET] <faLUCE> [17:27] <kepstin> yes, but in that file you can't use the `mpv --ad-lavc-ac3drc=1` command to play it back quietly <--- yes, I get this
[17:28:30 CET] <faLUCE> ok, many thanks. now, to be sure for all
[17:28:40 CET] <faLUCE> I should find an ac3 parser
[17:30:58 CET] <faLUCE> well, all is clear, now
[17:33:34 CET] <faLUCE> so, drc_scale is set on the metadata in order to make sure that poor systems can play the file without having bad sounds. But if you have a good system, you can disable it on the decoder, right?
[17:34:20 CET] <pink_mist> sounds right
[17:34:28 CET] <kepstin> "drc_scale" is not the name of any particular metadata, but there is metadata that's used by the drc function
[17:34:52 CET] <kepstin> drc_scale is the name of the ffmpeg decoder option that decides whether to use the metadata, and how strong of an effect to apply
[17:35:54 CET] <kepstin> the dolby document I linked provides more details, apparently the actual metadata used is the dialogue level and a drc profile selection.
[17:36:02 CET] <faLUCE> now, given that, the only
[17:36:22 CET] <faLUCE> ......sorry
[17:37:15 CET] <faLUCE> now, given that, there's no way to re-encode with same metadata on audacity
[17:37:37 CET] <kepstin> no, since after it decodes to pcm, the metadata is lost/forgotten
[17:38:16 CET] <kepstin> audacity also doesn't allow you to configure the -drc_scale option, so it probably defaults to always applying drc.
[17:38:49 CET] <kepstin> (if you don't want that, you should decode with ffmpeg to a different format before importing to audacity)
[17:40:10 CET] <faLUCE> kepstin: yes, right. I only could work-around by importing a file to audacity which has been decoded with drc_scale to 0
[17:40:21 CET] <faLUCE> for example, a raw file
[17:40:41 CET] <kepstin> exactly, although i'd use wav or flac or something :)
[17:41:05 CET] <faLUCE> kepstin: you can't imagine how bad this is for me that. I lost lot of work
[17:43:47 CET] <faLUCE> now, to understand better: does drc_scale = 0 mean  "more dynamic variations?" for example, a sound which changes suddenly from quiet to loud ?
[17:45:20 CET] <kepstin> drc_scale = 0 means "don't apply any dynamic range reduction", so in most audio that will be the case, yeah
[17:45:43 CET] <kepstin> in particular, it makes sound that's significantly louder or quieter than the dialogue level closer to the dialogue level
[17:46:05 CET] <kepstin> if drc is applied, it makes sound [...]
[17:47:14 CET] <faLUCE> in classical orchestral music enhancing the dynamic variations (drc_scale = 0) is more important than enhancing soft sounds (drc_scale = 1)
[17:47:33 CET] <faLUCE> for chamber music, instead, is important the opposite
[17:48:11 CET] <kepstin> unless you're listening on terrible speakers or in a noisy environment, in which case you'd probably have to apply drc to make the whole thing audible
[17:48:29 CET] <kepstin> doesn't matter if there's nice dynamics if you can't hear the quiet bits :)
[17:49:14 CET] <kepstin> hmm. apparently the dialogue level is normally manually set rather than calculated, according to that dolby doc. so it *might* actually be a global header thing? huh.
[17:50:23 CET] <faLUCE> kepstin: [17:49] <kepstin> hmm. apparently the dialogue level is normally manually set rather than calculated, according to that dolby doc.  <--- does it mean that I could save my work?
[17:50:25 CET] <kepstin> in that case, if you can somehow find out the dialogue level from the original, you might actually be able to set it when re-encoding to ac3
[17:50:42 CET] <kepstin> wouldn't help if you've worked on stuff with drc already applied
[17:50:44 CET] <kepstin> can't undo drc
[17:52:03 CET] <faLUCE> kepstin: when I import with audacity, does it apply drc ?
[17:52:10 CET] <kepstin> yes
[17:52:16 CET] <faLUCE> I see
[17:52:18 CET] <faLUCE> no way
[17:52:26 CET] <faLUCE> I have to redo the work
[17:52:27 CET] <kepstin> (almost certainly, since it uses ffmpeg's ac3 decoder, and that defaults to applying drc)
[17:55:33 CET] <faLUCE> so, other than drc_scale, are there metadata options that can improve the quality for good systems?
[18:08:42 CET] Action: kepstin took a poke into ffmpeg's ac3 encoder, and it doesn't support writing the per-block information about dynamic range used by the drc stuff.
[18:21:18 CET] <capin> hello, i'm having difficulty recording both my screen and mic at the same time, when recording just the screen or mic independentaly there isn't an issue.
[18:21:21 CET] <capin> https://gist.github.com/ipatch/8c7dbbcac37ba07b1f46f662921881a2
[18:23:54 CET] <friendofafriend> capin: Maybe ffprobe -v verbose -i "exp27-stock-settings.mkv" and post to a pastebin?
[18:26:15 CET] <capin> friendofafriend: added output of ffprobe to gist
[18:28:58 CET] <friendofafriend> capin: Cool, that shows an audio and a video stream in the output.
[18:31:54 CET] <BeerLover> Why is this command: https://0x0.st/zI4x.txt  wrong? The output: https://0x0.st/zI43.txt
[18:35:27 CET] <kepstin> BeerLover: I'd have to check the specs to confirm either way, but i suspect the issue might be that the names can't start with a digit since they might be confused with indexes.
[18:36:55 CET] <BeerLover> kepstin they can contain name. ffmpeg on mac os does this fine
[18:37:27 CET] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L1969
[18:37:57 CET] <furq> it's complaining about "name:320k", not the actual name
[18:37:59 CET] <furq> idk why though
[18:38:14 CET] <furq> in any event that whole -var_stream_map argument needs to be quoted
[18:38:53 CET] <kepstin> huh, that's really weird. are there any special characters snuck in there somewhere that make it fail to parse, maybe?
[18:39:13 CET] <furq> yeah maybe retype it
[18:39:22 CET] <furq> since you were having some kind of formatted text issue earlier with em dashes
[18:41:42 CET] <kepstin> but yeah, the command as shown in your paste obviously isn't the command as-run, since there's no quoting on the argument containing spaces.
[18:42:20 CET] <kepstin> although if you're running it from a script, it's possible that there was quoting that just didn't get preserved when you printed the command line.
[18:43:08 CET] <BeerLover> kepstin this is happening with my compiled version of ffmpeg (with libfdk_aac)
[18:43:29 CET] <BeerLover> even when I just use -c:a aac, it gives that erroorr
[18:44:20 CET] <kepstin> the error is in the -var_stream_map parameter, not the codec selection
[18:44:57 CET] <kepstin> and your command line paste doesn't match your output, so we can't help debug it further :/
[18:45:15 CET] <BeerLover> What can I paste?
[18:45:41 CET] <kepstin> the exact command line as you ran it copy/pasted out of the terminal, preferably.
[18:46:21 CET] <kepstin> along with the output from the same command line
[18:46:40 CET] <BeerLover> https://dpaste.de/1dcv/raw
[18:47:23 CET] <kepstin> BeerLover: ok, put that in your terminal, hit enter to run it, then include both the command line and the output it produces
[18:47:46 CET] <BeerLover> https://0x0.st/zI40.txt  Works
[18:48:03 CET] <BeerLover> https://0x0.st/zI4G.txt  Doesn't work
[18:48:21 CET] <BeerLover> works is the installed ffmpeg one
[18:48:33 CET] <BeerLover> the static compiled gives errorr
[18:48:35 CET] <furq> ffmpeg version 87201e0 Copyright (c) 2000-2018 the FFmpeg developers
[18:48:41 CET] <furq> why did you build such an old version
[18:49:23 CET] <BeerLover> furq I used this: https://github.com/zimbatm/ffmpeg-static
[18:49:45 CET] <furq> well yeah that option probably doesn't work as documented in a version from a year ago
[18:49:50 CET] <BeerLover> didn't know how to build it
[18:50:26 CET] <BeerLover> i want to build a static binary with all the libs enabled non free as well
[18:51:23 CET] <kepstin> hmm, that scripts hardcoded to use ffmpeg 4.0 downloaded via the tag from github. that's kinda weird, why isn't it at least using a release tarball so it gets the version number right :/
[18:52:58 CET] <kepstin> but yeah, support for "name:" (and a few other things) weren't added until a later release.
[18:54:06 CET] <BeerLover> if i just ./configure with --enable-libfdk-aac
[18:54:17 CET] <BeerLover> will it enable the default flags?
[18:56:11 CET] <kepstin> the default is to have most external libraries disabled, so you'll probably also want to enable libx264, libvpx, and whatever else you might be using.
[18:56:38 CET] <kepstin> you can copy/paste the enable stuff from that build.sh script if you like, it looks mostly ok.
[18:58:23 CET] <BeerLover> ERROR: libass not found using pkg-config
[18:58:26 CET] <BeerLover> kepstin
[18:58:32 CET] <BeerLover> but it is installed
[18:59:04 CET] <BeerLover> https://0x0.st/zI47.txt
[18:59:07 CET] <BeerLover> using this
[18:59:52 CET] <kepstin> you need to make sure the pkgconfig files for the installed libs are in somewhere that pkg-config looks, possibly by setting PKG_CONFIG_PATH if they're in an unusual spot.
[19:11:40 CET] <montana> Psnr or Psychovisual : what is the difference
[19:23:59 CET] <kepstin> psnr is a simple calculation of how much of the "signal" (desired output) there is compared to "noise" (stuff that doesn't match the desired output)
[19:24:51 CET] <kepstin> but that doesn't match how our brains work for video quality, so "psycovisual" refers to any optimizations that try to better match how the human vision system works.
[19:25:10 CET] <kepstin> which might in some cases cause psnr to be worse, even tho the picture looks better to people
[20:05:29 CET] <shibboleth> will i have to run ffmpeg and xorg as the same users for hwaccel?
[20:07:12 CET] <Mavrik> xorg doesn't matter really
[20:11:14 CET] <pink_mist> not even if xorg is hogging the hwaccel? can ffmpeg under a different user coexist in the hwaccel parts?
[20:16:46 CET] <kepstin> for the open-source drivers, most of the hwaccel stuff in ffmpeg access the "render" drm devices directly without any interaction with X, so as long as you have the right permissions on the devices it should be fine. And those devices are world-writable in most distro configs, i think.
[22:08:56 CET] <void09> why would this result in a corrupted video ?  mpv does not play it, vlc plays only audio . ffmpeg -i "inputvideo.mkv" -bsf:v h264_metadata=delete_filler=1,extract_extradata=remove=1 -vcodec copy -acodec copy outputvideo.mkv
[22:10:55 CET] <void09> JEEB: ? :P
[22:12:45 CET] <shibboleth> thanks
[22:13:09 CET] <kepstin> void09: you could narrow it down to which one of those two bsfs is responsible
[22:13:25 CET] <kepstin> (or does it only become unplayable if you use both?)
[22:13:29 CET] <void09> kepstin: i ran the same command on the .ts equivalent and it produced a good file
[22:13:44 CET] <void09> reason i do, is cause it's bloated, file is 7.1gb, using that becomes 3.1GB
[22:13:45 CET] <kepstin> different containers work differently
[22:14:06 CET] <void09> but this is a different copy and i do not have the .ts anymore.. and i get this bad file :(
[22:14:15 CET] <void09> ok i will narrow it down i guess
[22:20:46 CET] <void09> how do i run just hte second option kepstin ?  -bsf:v h264_metadata=extract_extradata=remove=1
[22:20:58 CET] <void09> 0] Option 'extract_extradata' not found
[22:22:06 CET] <void09> running with just delete_filler strips the junk and produces a working file, it was the extract_extradata that screwed it. but how to run that one by itself ?
[22:22:10 CET] <void09> just to test
[22:25:18 CET] <void09> ffmpeg -i "outputvideo_delete_filler.mkv" -bsf:v h264_metadata=,extract_extradata=remove=1 -vcodec copy -acodec copy outputvideo_final.mkv
[22:25:22 CET] <void09> this worked, accidentally
[22:25:31 CET] <void09> produces unplayable file
[22:26:00 CET] <kepstin> void09: you have two different bsfs, separated by a comma
[22:26:16 CET] <kepstin> remove one of them (and the comma)
[22:26:36 CET] <void09> gnn
[22:27:02 CET] <kepstin> pretty much the same syntax as filters.
[22:27:03 CET] <void09> h264_metadata=delete_filler=1,extract_extradata=remove=1
[22:27:25 CET] <void09> h264_metadata=,extract_extradata=remove=1
[22:27:27 CET] <void09> this worked
[22:27:31 CET] <void09> h264_metadata=extract_extradata=remove=1
[22:27:33 CET] <void09> this didn't
[22:27:55 CET] <void09> does that makes any sense?
[22:27:59 CET] <kepstin> please go and re-read what i just said
[22:28:18 CET] <void09> I just did
[22:28:25 CET] <void09> ohh
[22:28:27 CET] <kepstin> then stop, and think about it for a bit. maybe reference some documentation.
[22:28:49 CET] <void09> i thought they were both h264 metadata options
[22:29:02 CET] <kepstin> options are separated by :
[22:29:06 CET] <kepstin> filters are separated by ,
[22:30:36 CET] <void09> ok but this is still confusing:
[22:30:58 CET] <void09> ffmpeg -i "outputvideo_delete_filler.mkv" -bsf:v h264_metadata=,extract_extradata=remove=1 -vcodec copy -acodec copy outputvideo_final.mkv - this works and produces a file 600k smaller
[22:31:40 CET] <kepstin> so that's running the h264_metadata filter with no options, i dunno what it does then? nothing? and then the extract_extradata filter.
[22:31:55 CET] <void09> ffmpeg -i "outputvideo_delete_filler.mkv" -bsf:v extract_extradata=remove=1 -vcodec copy -acodec copy outputvideo_final.mkv - this works with a ton of errors ([AVBSFContext @ 0x55a41fd8f700] No start code is found.) and produces just audio
[22:34:10 CET] <JEEB> sounds like it cannot find a H.264/HEVC bit stream start code
[22:34:42 CET] <JEEB> not sure those bsfs work with non-annex b
[22:34:46 CET] <JEEB> might want to check up on that
[22:35:03 CET] <void09> I do not have the original .ts to test on, but i always used those options you gave me JEEB, on .ts inputs, and no issues so far
[22:35:07 CET] <JEEB> if they don't, there's a bsf that converts avcC and hevcC to Annex B
[22:35:13 CET] <JEEB> .ts is annex b
[22:35:23 CET] <JEEB> that's why I noted that you should check if that bsf supports non-annex b
[22:35:37 CET] <void09> issue came now with using .mkv as input
[22:35:46 CET] <void09> I have no idea what you're talking about :(
[22:36:28 CET] <JEEB> avcC and hvcC are generally utilized in mp4/mkv
[22:36:30 CET] <JEEB> :P
[22:36:40 CET] <JEEB> it's the way in which H.264 and HEVC packets are packaged
[22:36:56 CET] <JEEB> annex b has either 0x00 00 00 01 or 0x00 00 01 in front and no length
[22:37:07 CET] <void09> which  is smaller ?
[22:37:09 CET] <JEEB> avcC/hvcC have <LENGTH><DATA>
[22:37:31 CET] <nicolas17> that can't possibly cause a 50% file size difference o.O
[22:37:41 CET] <JEEB> void09: literally the same size
[22:37:58 CET] <void09> nicolas17: the recording i have has a lot of.. h264 padding I suppose
[22:37:59 CET] <JEEB> since 99% of all cases the size length of a packet is 4 bytes so (´4@)
[22:38:53 CET] <kepstin> padding is common in streams for tv broadcast, because broadcast is a fixed bitrate, so if the video is smaller it has to be padded to fill up the space.
[22:39:02 CET] <JEEB> anyways, if the BSF for filtering only works with annex b, use h264_mp4toannexb or hevc_mp4toannexb
[22:39:04 CET] <kepstin> basically not seen anywhere else tho, as far as i know?
[22:39:23 CET] <JEEB> kepstin: generally that's on the container level, although you can fill the video stream with garbage as well indeed
[22:39:39 CET] <JEEB> (x264 can do that too with the nal-hrd cbr mode)
[22:39:42 CET] <void09> this is the only station where I managed to produce this difference
[22:39:47 CET] <montana> Psnr or Psychovisual : what is the difference
[22:40:00 CET] <kepstin> montana: i helpfully explained that for you the last time you asked.
[22:40:04 CET] <void09> the rest just use higher bitrate
[22:40:44 CET] <kepstin> if another station uses container-level padding instead of codec level, it's likely just dropped on remuxing no bsfs needed.
[22:41:13 CET] <void09> yeah i know
[22:41:24 CET] <void09> but I'd rather use that line just to be sure
[22:41:31 CET] <void09> any more slimming down tricks you knwo of ? :)
[22:41:54 CET] <montana> kepstin sorry i missed it: (just scolled up and read it)
[22:42:08 CET] <montana> kepstin why would anybody use psnr then?
[22:45:03 CET] <kepstin> psnr is fast to calculate, i guess.
[22:45:59 CET] <void09> JEEB: so what do you suggest I do, I kind of missed the point
[22:46:40 CET] <montana> kepstin i also see  ssim and grain
[22:46:53 CET] <kepstin> montana: ah, you're talking about x264 tune values?
[22:46:58 CET] <JEEB> void09: for non-annex b input (not mpeg-ts, AVI or raw H.264), use those two bsfs (one for h264, one for hevc) to convert the bit stream to annex b first :P
[22:47:02 CET] <JEEB> then use the rest
[22:47:06 CET] <montana> kepstin yes
[22:47:16 CET] <kepstin> montana: unless you have special circumstances where you know a specific tune helps, do not set anything.
[22:47:45 CET] <void09> JEEB: sorry I still don't get it
[22:47:53 CET] <kepstin> montana: the "psnr" and "ssim" tunes are only for if you're doing codec testing using psnr or ssim measurements, and should not be used for normal encodes.
[22:48:16 CET] <void09>  h264_mp4toannexb or hevc_mp4toannexb
[22:48:17 CET] <void09> these ?
[22:48:19 CET] <nicolas17> https://trac.ffmpeg.org/wiki/Encode/H.264#Tune
[22:48:37 CET] <nicolas17> they're all very specialized
[22:49:38 CET] <montana> nicolas17 i see, how come i don't see "psychovisual" in that tune list
[22:49:59 CET] <nicolas17> what would that do?
[22:50:15 CET] <montana> use psychovisual
[22:50:22 CET] <kepstin> montana: because that's not the name of a tune, psychovisual optimization is the default and is controlled via other options
[22:50:32 CET] <montana> oh ok
[22:50:43 CET] <kepstin> note that the psnr and ssim tunes *disable* psychovisual optimization.
[22:51:33 CET] <montana> but can an average person even tell the difference between "psnr encodes" vs "ssim encodes" vs "psychovisual encodes"
[22:52:01 CET] <kepstin> if you look at the list of tunes in x264 --fullhelp, some of them are labelled "psy" tunes, those adjust the psychovisual optimization settings. the main reason they're labelled is so you know which ones can't be combined.
[22:52:31 CET] <kepstin> you can only have one "psy" tune active at a time.
[22:52:34 CET] <nicolas17> montana: more likely on lower bitrates I guess
[22:52:55 CET] <montana> nicolas17 you would able to tell the difference on "lower bitrate examples"?
[22:53:45 CET] <nicolas17> well, if the bitrate is high enough, everything looks "identical" to the source to the human eye
[23:02:44 CET] <montana> nicolas17 i see
[23:04:15 CET] <void09> JEEB: h264_mp4toannexb works on mkv input ?
[23:05:35 CET] <JEEB> it should work in general, except for those nonstandard files where someone stuck annex b into mkv/mp4
[23:06:03 CET] <JEEB> matroska and mp4 share the way H.264 and HEVC are packaged into them :P
[23:06:10 CET] <void09> i get a Unknown bitstream filter h264_mp4toannex
[23:06:19 CET] <void09> -codec copy -bsf:v h264_mp4toannex= output.ts
[23:06:23 CET] <void09> without the =
[23:06:34 CET] <JEEB> check the name :P
[23:06:44 CET] <void09> i copied it from the docs
[23:06:59 CET] <void09> oh b
[23:07:00 CET] <JEEB> you just said it correctly on IRC, yet the command you noted has it incorrect
[23:07:26 CET] <void09> man i wish there was a ffmpeg university
[23:07:28 CET] <void09> i'd so sign up
[23:09:35 CET] <void09> yeay that worked JEEB : D
[23:10:21 CET] <void09> can you tldr everything so i make sure i understand.. the original input mkv file had an incorrect .. annex type ?
[23:10:34 CET] <JEEB> it has correct type for that
[23:10:50 CET] <JEEB> the bit stream filter has been made for the other packaging type for the packets
[23:11:00 CET] <void09> so why would i need to conver to annex_b and ts before I can strip it without errors?
[23:11:08 CET] <JEEB> because the bit stream filter requires that
[23:11:26 CET] <JEEB> if you make the bit stream filter work without it, that would make it not need that step :P
[23:11:49 CET] <void09> right.. although I am pretty sure i ran that command on an mkv before and it did not screw it up
[23:11:51 CET] <JEEB> I would guess that it is because the primary use case for such a filter was for raw H.264 (which is annex b)
[23:12:15 CET] <JEEB> (or MPEG-TS, which packages annex b in the streams)
[23:12:18 CET] <nicolas17> I guess mkv can hold either type?
[23:12:28 CET] <JEEB> it is standardized on the mp4 way
[23:12:38 CET] <JEEB> you will find mp4 and mkv files which will contain annex b, though
[23:12:40 CET] <JEEB> because of course
[23:12:52 CET] <nicolas17> if anything can be done two ways, it will be done both ways in the wild
[23:13:02 CET] <JEEB> yes
[23:13:08 CET] <nicolas17> from byte endianness to book spine orientation
[23:13:19 CET] <JEEB> which is why the decoder/parser parts support both
[23:17:17 CET] <void09> how can ic check which type a file has ?
[00:00:00 CET] --- Wed Nov 27 2019