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

[burek]

[00:00:10 CET] <another> yes
[00:01:27 CET] <ricemuffinball> how is that different from this then?  ffmpeg -i input.mkv -vcodec copy -acodec copy R:\output.ts
[00:02:22 CET] <another> should be the same as the bsf should be inserted automatically
[00:02:49 CET] <ricemuffinball> what is bsf?
[00:03:13 CET] <another> bitstream filter
[00:05:04 CET] <ricemuffinball> and what does bitstream filter exactly do
[00:05:24 CET] <another> https://ffmpeg.org/ffmpeg-bitstream-filters.html#h264_005fmp4toannexb
[00:06:02 CET] <JEEB> basically the packaging of the AVC stream is different between MP4/MKV and MPEG-TS
[00:06:09 CET] <another> basically it moves a few bits and bytes to different positions, so that they fit the standard
[00:06:31 CET] <ricemuffinball> i see
[00:06:39 CET] <JEEB> before /33
[00:06:51 CET] <ricemuffinball> is that mean  ffmpeg -i input.mkv -vcodec copy -acodec copy R:\output.ts    this command will create corrupted ts file since  i didn't use  bsf option?
[00:07:02 CET] <JEEB> no
[00:07:19 CET] <JEEB> with old FFmpeg it would fail, with new FFmpeg it would auto-insert the bit stream filter
[00:07:28 CET] <ricemuffinball> jeeb i see
[00:07:36 CET] <ricemuffinball> what is considered old
[00:07:40 CET] <ricemuffinball> and new
[00:08:22 CET] <JEEB> seems like automatic bsf was added in 2016
[00:08:30 CET] <JEEB> late 2016
[00:08:38 CET] <JEEB> so if your FFmpeg is older than that it would error out
[00:08:49 CET] <ricemuffinball> another  WOW  that method worked
[00:08:54 CET] <JEEB> if your FFmpeg is newer than that it would attempt to auto-insert
[00:09:14 CET] <another> nice
[00:09:52 CET] <ricemuffinball> what does "-bsf:a aac_adtstoasc" do
[00:10:05 CET] <JEEB> same thing for AAC
[00:10:14 CET] <JEEB> ADTS packaging to ASC packaging
[00:10:45 CET] <JEEB> I think ADTS is what's used in MPEG-TS?
[00:10:57 CET] <ricemuffinball> what if i don't add the "-bsf:a aac_adtstoasc" option  then does it create corrupted file?
[00:10:59 CET] <JEEB> or was this the MPEG-4 AAC vs MPEG-2 AAC thing?
[00:11:07 CET] <JEEB> no
[00:11:24 CET] <JEEB> it will either error out or auto-insert if needed
[00:11:39 CET] <another> JEEB: "Convert MPEG-2/4 AAC ADTS to an MPEG-4 Audio Specific Configuration bitstream." -- https://ffmpeg.org/ffmpeg-bitstream-filters.html#aac_005fadtstoasc
[00:11:58 CET] <JEEB> ok, so I remembered it correctly'ish :)
[00:12:29 CET] <ricemuffinball> i wonder why  ffmpeg -safe 0 -f concat -i list.txt -c copy output.mp4  created corrupted file
[00:12:57 CET] <ricemuffinball> but ffmpeg -i "concat:intermediate1.ts|intermediate2.ts" -c copy -bsf:a aac_adtstoasc output.mp4   DID WORK
[00:16:00 CET] <ricemuffinball> what does -safe 0  do
[00:19:30 CET] <another> https://ffmpeg.org/ffmpeg-all.html#Options-35
[00:21:30 CET] <ricemuffinball> another any idea why one method didn't work but ts method worked
[00:22:06 CET] <another> nope. had the same problem before
[00:22:37 CET] <ricemuffinball> another exact same problem?
[00:22:54 CET] <ricemuffinball> where it created garbage video @  second video mark
[00:23:00 CET] <another> something similar. can't remember what exactly
[00:23:14 CET] <ricemuffinball> another and ts method worked for you ?
[00:23:41 CET] <another> yes.
[00:27:05 CET] <ricemuffinball> another do you remember if the video showed up like this:  https://imgur.com/a/U9ISgXA
[00:27:54 CET] <another> it's been too long
[00:28:18 CET] <another> i just know it worked with ts
[00:29:25 CET] <ricemuffinball> why isn't  vob/ts container popular
[00:29:47 CET] <ricemuffinball> like mp4/mkv/avi
[00:33:26 CET] <Hello71> it sucks
[00:34:22 CET] <ricemuffinball> how does it suck
[00:35:01 CET] <Hello71> according to wikipedia, vob is ps
[00:35:04 CET] <Hello71> and mpg is certainly popular
[00:35:10 CET] <ricemuffinball> PS ?
[00:35:33 CET] <Hello71> bus I assume mp4 provided some benefits over mp2
[00:36:33 CET] <ricemuffinball> Hello71 what is "ps"?
[00:36:45 CET] <Hello71> google it.
[00:37:27 CET] <ricemuffinball> no luck
[00:41:32 CET] <ricemuffinball> hello program stream
[01:27:00 CET] <ricemuffinball> how do i tell mp4 file i have  has  mov atom in the beginning or end
[02:33:02 CET] <ricemuffinball> is it stupid to encode a 8bit video source to 10 bit video  ?
[02:33:27 CET] <another> why would you do that?
[02:34:23 CET] <ricemuffinball> i didn't, that's why i asked
[02:35:15 CET] <another> i see no benefits in there
[02:36:41 CET] <ricemuffinball> [17:35] <iive> encoding 8bit source as 10bit prevents a rounding error in motion compensation
[02:36:41 CET] <ricemuffinball> [17:35] <iive> that allows the encode to get smaller, sometimes up to 30%
[02:36:41 CET] <ricemuffinball> [17:35] <iive> that's why it got so popular with h264 at first.
[07:14:27 CET] <errl> hi everyone, having some problem with the cli in this paste is the command and the error message: https://pastebin.com/raw/yhU1CGpy
[07:15:10 CET] <errl> when i'm attempting to apply the filters on my input, sometimes the command completes successfully, but other times the command fails with the message there
[07:15:24 CET] <furq> errl: it's getting oom killed
[07:15:58 CET] <furq> not really sure why, i don't see any filters in there that would use a ton of memory
[07:16:18 CET] <errl> are you sure? how could that be, I am monitoring htop and it doesn't seem as though ffmpeg is using much memory at all
[07:16:40 CET] <furq> shrug
[07:16:44 CET] <furq> "signal: killed" is an oom killer message
[07:17:14 CET] <errl> i've just tried running the command again and htop reports the process is using 300M
[07:18:29 CET] <errl> i am using 4.1.1 if that means anything, perhaps downgrading is a solution?
[07:18:41 CET] <furq> you could try
[07:18:45 CET] <furq> i'm not sure it'd make any difference
[07:18:56 CET] <furq> if you're sure you're not running out of memory, you have swap etc then it's worth a try
[07:19:23 CET] <furq> you should be able to see in dmesg whether it got oom killed
[07:19:46 CET] <errl> the vm i'm using actually doesn't have swap, but it has plenty free ram, could that be the culprit?
[07:20:12 CET] <furq> maybe
[07:20:54 CET] <errl> ok, i will try that
[08:40:57 CET] <cn2348> Hi, I've got a file recorded by a mobile phone that changes its dimensions during the runtime (landscape -> portrait and then back portrait -> landscape), is there a way to normalize this to only landscape?
[08:42:13 CET] <cn2348> Using the cclock transpose filter with landscape passthrough results in non monotous dts warnings and the output is chopped?
[08:43:51 CET] <cn2348> Just passing the file to ffmpeg and letting it reencode with no other options also results in a somewhat weird output
[08:44:33 CET] <cn2348> During the orientation change there are shortly no frames and reencoding adds some kind of weird looking slur during that period
[10:00:04 CET] <ricemuffinball> is it stupid to encode a 8bit video source to 10 bit video  ?
[10:03:57 CET] <furq> usually yes
[10:06:13 CET] <ricemuffinball> why not "always yes"
[10:06:22 CET] <furq> sometimes the space savings are worth it
[10:06:34 CET] <furq> animation usually benefits an appreciable amount
[10:06:47 CET] <furq> the problem with 10-bit h264 in particular is that nothing supports it
[10:07:08 CET] <ricemuffinball> even on computer playback ?
[10:07:17 CET] <furq> it's supported in software obviously
[10:07:21 CET] <furq> but nothing else will play it
[10:07:50 CET] <ricemuffinball> what  about on smartphone with software?
[10:08:08 CET] <furq> that will either run badly or kill your battery
[10:08:20 CET] <ricemuffinball> i see
[10:09:27 CET] <ricemuffinball> even if  there is lack of support  why would it cause "space savings"  when it's going from 8 bit to 10bit
[10:10:01 CET] <furq> https://gist.github.com/l4n9th4n9/4459997
[10:11:25 CET] <ricemuffinball> furq is the "space saving" also happen for  8 bit x265 to 10 bit x265
[10:11:56 CET] <furq> probably
[10:12:02 CET] <furq> i know very little about x265
[10:12:12 CET] <furq> 10-bit h265 is actually better supported than 10-bit h264 though
[10:12:16 CET] <furq> a lot of newer phones etc can decode it
[10:13:52 CET] <ricemuffinball> yes, a lot of other people said the same thing
[10:51:14 CET] <useri0> hello everyone, i get this message sometimes :  Last message repeated 130046 times
[10:51:25 CET] <useri0> how do i reduce the number of repeated times ?
[10:51:58 CET] <durandal_1707> useri0: and actual message is?
[10:52:25 CET] <useri0> durandal_1707, http://prntscr.com/mrqyir
[10:54:01 CET] <durandal_1707> you can not do much about it
[10:55:56 CET] <useri0> how so ?
[10:56:11 CET] <useri0> is there a way to counter attack it at least?
[10:56:51 CET] <useri0> durandal_1707, https://video.stackexchange.com/questions/24462/timestamps-are-unset-in-a-packet-for-stream-0-this-is-deprecated-and-will-stop
[10:57:01 CET] <useri0> how right that solution is ?
[10:58:23 CET] <durandal_1707> it is not always perfect
[10:58:31 CET] <durandal_1707> you can try....
[11:00:28 CET] <useri0> i would better avoid it then
[11:00:37 CET] <useri0> but what does the error actually means ?
[11:03:18 CET] <useri0> someone said in the comments at this link, to use -re, would that be efficient enough maybe?
[11:03:57 CET] <durandal_1707> dunno, cant do guessing
[11:06:42 CET] <useri0> okay thanks
[11:25:48 CET] <useri0> durandal_1707, if i want to place :'-use_wallclock_as_timestamps 1' , where should i place it here : ffmpeg '-loglevel', 'warning', '-i', xx.mp4, '-codec', 'copy', xx_.mp4
[11:26:25 CET] <durandal_1707> before -i  i think
[11:26:57 CET] <useri0> okay thanks
[11:30:35 CET] <useri0> says : http://prntscr.com/mrri61
[13:41:09 CET] <th3_v0ice> What are the steps to convert audio that has 1536 samples (AC3) to 1024 samples (AAC). I am using swr_convert() now and I am not sure that this is the right approach.
[13:42:42 CET] <BtbN> There should be no special steps to that really
[13:44:06 CET] <Mavrik> FIFO queue? :)
[13:44:09 CET] <th3_v0ice> So just a fifo buffer?
[13:44:55 CET] <th3_v0ice> If FIFO buffer is the right answer, what would be best way to handle timestamps?
[15:38:43 CET] <brejeiro> Hello, I'm recording my screen using ffmpeg on windows, and it works great. The thing is, I'll need to create chapters in my video at certain times. I know I could just create a Metadata file afterwards, but precise time and automation are needed for the task. So let's say I started recording my desktop, then I started a program, and at some point I finish one task and will start another one. This is the time actually need, and nee
[15:39:28 CET] <brejeiro> Is it possible that I could run some command at that point to get the precise time/frame of the video? Or even create the chapter there?
[15:39:36 CET] <brejeiro> Was I clear?
[15:53:48 CET] <goodgrief> Hi!
[15:54:08 CET] <goodgrief> Does anybody have an example with using of afftdn filter?
[15:54:56 CET] <goodgrief> Documentation is poor, and I haven't found examples in google :(
[16:08:26 CET] <durandal_1707> goodgrief: you can use it in one go, or two pass
[16:10:30 CET] <durandal_1707> goodgrief: do you want examples?
[16:11:03 CET] <goodgrief> durandal_1707: it will be nice if you have one
[16:12:03 CET] <durandal_1707> it depends on audio noise
[16:12:13 CET] <goodgrief> white noise
[16:12:40 CET] <durandal_1707> what kind of audio music or speech?
[16:12:51 CET] <goodgrief> human voice
[16:15:39 CET] <svara> Hi all, I wrote some C++ code that dumps a h265 stream to a file. I can convert this into an mp4 by using ffmpeg from the command line (simply with "-c copy"); but I would like to include this functionality directly in my own program. It seems like this should be possible with, e.g., libavformat (?), but I can't really find documentation or just some starting point for this. Can anyone point me in the right direction?
[16:15:45 CET] <durandal_1707> goodgrief: you could use ladspa or lv2 filters? but they are less or no configurable
[16:16:44 CET] <durandal_1707> goodgrief: https://github.com/werman/noise-suppression-for-voice
[16:17:11 CET] <durandal_1707> so you would use ffmpeg -i noise.wav -af ladspa=....
[16:17:51 CET] <Mavrik> svara: there's examples of API usage in examples/ subdir of ffmpeg source
[16:18:46 CET] <durandal_1707> goodgrief: for afftdn, you just adjust noise floor, nf option and than nr noise reduction option
[16:19:26 CET] <durandal_1707> that is basic usage, there is more complex one
[16:24:08 CET] <svara> Mavrik: perfect, thanks - for reference, the relevant example is https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/muxing.c
[16:28:54 CET] <goodgrief> durandal_1707: it works now! Thank you for help!
[20:39:25 CET] <ChocolateArmpits> Has anyone encountered any performance issues pertaining to running multiple powershell sessions and executing "cmd /c ffmpeg" commands? I have found that by running 8 or more powershell sessions with ffmpeg getting executed via cmd /c  the cpu usage of each instance of ffmpeg would go up way beyond than if cmd /c wasn't used
[20:40:19 CET] <ChocolateArmpits> This is the first time that I'm seeing this, of course I didn't have to run 10 instances of ffmpeg at once, but this still is awfully odd
[20:41:19 CET] <ChocolateArmpits> don't even know how to report this
[20:45:40 CET] <DHE> but launching ffmpeg 10 times via other methods is better?
[20:46:23 CET] <ChocolateArmpits> If I launch it directly in powershell, not via "cmd /c", but start-process cmdlet, then it performs as expected
[20:46:49 CET] <ChocolateArmpits> I initially used "cmd /c ffmpeg [parameters]" to more easily pass complex strings without requiring escaping
[20:47:07 CET] <ChocolateArmpits> I didn't think there would be any problems
[20:47:24 CET] <ChocolateArmpits> But upon going to a higher number of processes the problems started showing up
[20:47:46 CET] <ChocolateArmpits> It should be known the cpu usage of ffmpeg increases, not of powershell or cmd
[20:48:01 CET] <ChocolateArmpits> across all active instances running the same manner
[20:48:12 CET] <ChocolateArmpits> And only starts creeping up with 8 or more processes
[20:49:19 CET] <ChocolateArmpits> Normally the utitlization would be at about 50%, but with the """bug""" it can easily skyrocket to 100% when realtime processing is concerned
[20:49:32 CET] <DHE> so it's not powershell-specific
[20:49:50 CET] <ChocolateArmpits> I'd say there's maybe some combination of running ffmpeg inside cmd and that inside of powershell
[20:50:05 CET] <ChocolateArmpits> but the cpu usage problems happen with ffmpeg
[20:51:31 CET] <ChocolateArmpits> Actually, even running the processes in that sequence already produces somewhat worse performance than just running ffmpeg in either cmd or powershell, but, as I said before, starting with 8 processes it completely shits itself
[20:52:31 CET] <ChocolateArmpits> so I do have a workaround, but the issue is something that maybe could get some conclusion
[20:53:02 CET] <ChocolateArmpits> I guess the situation is unique enough that it's only on me to carry on
[20:55:54 CET] <kepstin> only things I can think of is either that console output is handled differently causing load issues, or it's not actually running the same ffmpeg command in the end.
[20:56:35 CET] <ChocolateArmpits> The commands were identical, I ran the tests manually both times
[20:57:22 CET] <ChocolateArmpits> Could ffmpeg performance spike because of the shell environment?
[21:01:07 CET] <kepstin> console environment shouldn't matter, but try running with the "-nostats" option to make sure.
[21:04:38 CET] <ChocolateArmpits> okay I'll try that when I have the time
[21:05:22 CET] <ChocolateArmpits> btw stopping any of the 8 processes so only 7 are active, sees the cpu usage drop across all others
[21:25:49 CET] <ricemuffinball> does youtube use FLV or mp4 or something else
[21:30:39 CET] <kepstin> mp4 and something else, yes
[21:31:00 CET] <ricemuffinball> isn't mp4 horrible for streaming
[21:31:10 CET] <kepstin> nah, it's fine if used correctly
[21:31:37 CET] <kepstin> but note that youtube serves stuff up with dash to modern browsers, i think?
[21:31:48 CET] <ricemuffinball> dash?
[21:32:00 CET] <ricemuffinball> what is that
[21:32:09 CET] <kepstin> a segmented adaptive streaming system
[21:33:01 CET] <ricemuffinball> but regular mp4 doesn't have that
[21:33:27 CET] <kepstin> no, the dash stuff is mostly important if you want to be able to switch quality levels dynamically during playback
[21:34:04 CET] <ricemuffinball> i see, is that what dash does?
[21:36:28 CET] <kepstin> dash metadata, along with a set of specially prepared webm, mp4, or mpeg-ts files, allows a player to pick quality formats dynamically and switch seamlessly.
[21:37:11 CET] <kepstin> the individual webm or mp4 files from the dash streams can also be downloaded and played individually in most cases.
[21:38:08 CET] <ricemuffinball> i always use mkv because i can playback the mkv file during encoding process, i cannot do that with mp4
[21:38:28 CET] <kepstin> yes, that's a design issue with mp4.
[21:38:47 CET] <kepstin> that's fine for VOD use cases like youtube, because the video is fully encoded before anyone starts watching it
[21:38:48 CET] <ricemuffinball> right, wouldn't it be easiler for youtube to just use mkv
[21:39:42 CET] <kepstin> browsers don't play mkv (well, they do, but only in the form of webm which has restricted codecs)
[21:39:43 CET] <ricemuffinball> did youtube used FLV in the past?
[21:40:14 CET] <kepstin> youtube used to use a flash player, I don't remember which codecs/formats they used at the time.
[21:40:36 CET] <kepstin> but flash could play mp4 files for quite a long time, iirc.
[21:41:27 CET] <TheAMM> FLV and certain MP4s, iirc there might've been some h264 level limit
[21:41:32 CET] <ricemuffinball> kepstin  browser don't like mkv? really? i didn't know that
[21:41:45 CET] <ricemuffinball> i wonder why that is
[21:41:53 CET] <TheAMM> RTMP (or was it RTSP?) too, but I don't know about that
[21:42:20 CET] <TheAMM> ricemuffinball: chrome can play mkv in <video> if the codecs are proper
[21:43:08 CET] <TheAMM> But for reasons unknown, won't play video/x-matroska inline
[21:43:17 CET] <TheAMM> not even audio/flac
[21:43:46 CET] <ricemuffinball> video/x-matroska inline ?? what is that
[21:44:04 CET] <kepstin> ricemuffinball: browsers implement a restricted set of containers and codecs, mostly to limit exposure to possible security issues, and as a way to influence people to use specific codecs that the browser makers want to promote
[21:44:15 CET] <ricemuffinball> kepstin i see
[21:44:32 CET] <TheAMM> Here's H.264 and Opus in mkv playing with <video> https://mygi.ga/IHt/adSLI.mkv/embed
[21:44:33 CET] <ricemuffinball> so browsers like mp4 and webm ?
[21:45:06 CET] <ricemuffinball> it doesn't play
[21:45:35 CET] <TheAMM> :shrug:, works for me on linux chrome
[21:46:05 CET] <ricemuffinball> theamm do you have another mkv link
[21:46:21 CET] <kepstin> yeah, if you want support across multiple browsers, you need to stick with mp4 or webm
[21:46:35 CET] <kepstin> (or sometimes both)
[21:46:44 CET] <kepstin> (but usually just mp4 is enough)
[21:46:51 CET] <TheAMM> https://mygi.ga/iXk/aecmI.mkv/embed This is just h264
[21:47:38 CET] <kepstin> 'epiphany' (the gnome webkit-based browser) used to just use gstreamer to play <video> tags, it would play anything you had plugins installed for. It would even render ass subtitles and stuff :)
[21:47:40 CET] <ricemuffinball> theamm so no sound?
[21:47:58 CET] <kepstin> i dunno if that's still the case
[21:48:27 CET] <TheAMM> libmpv for blink when
[21:49:09 CET] <ricemuffinball> TheAMM plays fine on  edge browser but doesn't work with firefox
[21:49:24 CET] <ricemuffinball> firefox doesn't like mkv i guess
[21:49:30 CET] <TheAMM> That's what I've heard people say a lot
[21:49:32 CET] <kepstin> firefox is the most restrictive, it explicitly whitelists specific containers and codecs.
[21:49:38 CET] <TheAMM> firefox doesn't like 4:4:4 webms either
[21:49:47 CET] <ricemuffinball> what is 4:4:4 mean
[21:49:51 CET] <TheAMM> It should, someone said, but last I tried, it didn't
[21:50:02 CET] <TheAMM> YUV 4:4:4, subsampling (or the lack of)
[21:50:10 CET] <kepstin> hmm, I was sure I had 4:4:4 webms with vp9 working in firefox at some point.
[21:50:21 CET] <TheAMM> Most video is YUV 4:2:0
[21:50:37 CET] <TheAMM> Wikipedia has explanations unless someone here wants to tldr
[21:50:52 CET] <TheAMM> I'm gonna do the daily hibernation now
[21:50:57 CET] <ricemuffinball> is 10bit x264/x265  also YUV 4:2:0
[21:51:20 CET] <TheAMM> Likely, but yuv420p10 instead of yuv420p
[21:51:48 CET] <kepstin> the 4:4:4 and 4:2:0 syntax is kinda strange / hard to understand - but the basic idea is that the human eye is less sensitive to certain colour information, so that information is sent at lower resolution than the rest of the signal.
[21:51:54 CET] <ricemuffinball> what is the point of using 4:4:4 over 4:2:0 then
[21:52:06 CET] <TheAMM> All the data?
[21:52:06 CET] <kepstin> with 4:4:4 it's sent at full resolution, with 4:2:0, the colour data is sent at 1/4 resolution
[21:52:09 CET] <kepstin> saves a lot of space
[21:52:23 CET] <kepstin> well, 4:4:4 is a lot bigger
[21:52:38 CET] <ricemuffinball> bigger as in file size?
[21:52:42 CET] <kepstin> yes
[21:53:09 CET] <ricemuffinball> can average people tell the difference between 4:4:4 and 4:4:2
[21:53:15 CET] <ricemuffinball> 0 i mean
[21:53:41 CET] <kepstin> on most "natural" video content, no.
[21:53:50 CET] <TheAMM> Depends on the scene
[21:54:12 CET] <TheAMM> Since most video you see is 4:2:0 and you're not going "why does all video look bad", it's fine
[21:54:15 CET] <kepstin> on artificial content (cg, screen capture, etc.) it's noticable as colour fringes on sharp transitions, especially diagonal.
[21:54:21 CET] <TheAMM> But say if you're recording your monitor
[21:54:27 CET] <TheAMM> yeah, like kepstin said
[21:54:39 CET] <kepstin> if you have coloured small text in a screen capture, it's really noticable.
[21:54:49 CET] <TheAMM> Especially red edges are obvious
[21:55:35 CET] <ricemuffinball> if 4:2:0 is most used, what is second most used
[21:55:37 CET] <kepstin> because of how YUV works, green (which your eyes are more sensitive to) is effectively sent at higher resolution than red and blue when using 4:2:0
[21:56:00 CET] <kepstin> ricemuffinball: 4:2:0 is so common that "second most used" is basically meaningless, everything else is niche
[21:56:14 CET] <ricemuffinball> kepstin i see
[21:56:28 CET] <TheAMM> Depends on the definition
[21:56:32 CET] <kepstin> but it's probably either 4:4:4 (no subsampling) or 4:2:2 (1/2 sampling, used for interlaced media as a compromise)
[21:56:43 CET] <ricemuffinball> so 4:4:4 a lot rarer/niche than 10bit video ?
[21:57:01 CET] <TheAMM> eh
[21:57:11 CET] <ricemuffinball> becuse most videos are 8bit video
[21:57:16 CET] <kepstin> 10bit is going to be more common than 4:4:4, since it's going to be used for HDR video
[21:57:22 CET] <kepstin> but that hdr video will still be 4:2:0
[21:57:58 CET] <kepstin> but that's "is going to be"... not "is right now"
[21:58:06 CET] <kepstin> right now I have no idea which is less popular :)
[21:59:32 CET] <ricemuffinball> does it save a lot of file space by using 4:2:0 over 4:4:4
[22:00:26 CET] <kepstin> *before* compression, 4:2:0 video is ½ the size of 4:4:4 video
[22:00:35 CET] <kepstin> after compression, the difference isn't as big
[22:00:52 CET] <ricemuffinball> i see
[22:01:21 CET] <ricemuffinball> so for raw , it's twice as big: that's big difference
[22:02:07 CET] <kepstin> this is also an interesting thing with TV screens and HDMI - some TV screens can play 4K video with 4:2:0 sampling at 60Hz, but if you switch to RGB or 4:4:4 sampling, they can only do 30Hz.
[22:02:19 CET] <kepstin> since the video's twice as big :)
[22:04:19 CET] <ricemuffinball> i thought raw video file size =   bit x resolution x resolution x fps x duration
[22:04:57 CET] <ricemuffinball> where do you calculate the  4:4:4
[22:05:13 CET] <kepstin> it's in the "bit" video, which should actually be "bit per pixel"
[22:06:04 CET] <ricemuffinball> so for 1 second 10 bit 1920-1080 30 fps  =   10 x 1920 x 1080 x 30 x 1
[22:06:16 CET] <kepstin> 8-bit 4:4:4 video is 24 bit per pixel. 10-bit 4:4:4 video is 30 bit per pixel (sometimes rounded up to 32 or even 48). 8-bit 4:2:0 video is 12 bit per pixel.
[22:07:34 CET] <ricemuffinball> 8-bit 4:2:0 video  is not  8 ?
[22:07:39 CET] <ricemuffinball> when doing calculation?
[22:07:48 CET] <kepstin> For 4:2:0, that's 8 Y + ¼×8 U + ¼×8 V
[22:08:07 CET] <kepstin> since the U and V are subsampled, to ¼ resolution
[22:08:50 CET] <ricemuffinball> oh you are right   people use  24bit  for  8 bit
[22:09:02 CET] <ricemuffinball> 3 x 8
[22:09:28 CET] <kepstin> that's for 8 bit per channel, 3 channels, no subsampling, yes.
[22:10:17 CET] <ricemuffinball> i remember when windows let me choose on display settings   24bit color or 16bit color or even 32bit color
[22:10:43 CET] <kepstin> those are RGB colour modes, which are a different thing from YUV, but the ideas are basically the same
[22:11:02 CET] <ricemuffinball> you can easily tell the difference choosing  24 and 16bit on windows settings
[22:11:17 CET] <kepstin> 16 bit RGB colour is kind of neat, actually, since it's 5 bit of red, 6 bits of green, 5 bits of blue
[22:11:30 CET] <ricemuffinball> i see
[22:11:34 CET] <ricemuffinball> why more green?
[22:12:05 CET] <kepstin> same reason as why YUV 4:2:0 has higher resolution for green - human eyes are more sensitive to it
[22:12:12 CET] <ricemuffinball> i see
[22:12:22 CET] <ricemuffinball> what is 32bit color then on windows settings
[22:12:38 CET] <kepstin> 8R + 8G + 8B + 8 nothing
[22:12:52 CET] <ricemuffinball> huh? so it's pointless
[22:13:05 CET] <kepstin> it's just rounding it to even 32bits with padding, because that's faster to work with
[22:13:20 CET] <ricemuffinball> i don't get it
[22:13:27 CET] <kepstin> then a single pixel is an aligned 32bit read, rather than 3 separate 8bit reads.
[22:14:07 CET] <ricemuffinball> so it has to do with how computer likes the number 32 than 24 ?
[22:14:10 CET] <kepstin> it's just an implementation detail of computer processors - you can make some times of image processing faster, but you have to waste 8 bits per pixel
[22:15:05 CET] <ricemuffinball> did it really make it faster though by choosing 32bit color over 24bit color
[22:15:06 CET] <Foaly> well, if you're working with lots of data, packing may actually be faster
[22:15:24 CET] <Foaly> because more fits in the cache
[22:15:33 CET] <kepstin> ricemuffinball: depends on the image processing in question and the computer processor
[22:15:56 CET] <ricemuffinball> with newer windows, i don't have a choice to choose the color depth
[22:15:58 CET] <kepstin> windows decided on using 32bit for most stuff, and memory and bandwith have been increasing, so.. :/
[22:16:47 CET] <kepstin> the overhead on the array index calculations for 24bit image data may or may not be worse than the cache problem. depends on the processor :)
[22:17:54 CET] <kepstin> (then there's the difference between planar and packed formats, each of which behaves better or worse for different operations)
[22:20:44 CET] <ricemuffinball> kepstin this one website is saying extra 8bit is for alpha
[22:20:55 CET] <ricemuffinball> whatever that is
[22:21:11 CET] <ricemuffinball> 32-bit color
[22:21:11 CET] <ricemuffinball> Like 24-bit color, 32-bit color supports 16,777,215 colors but has an alpha channel it can create more convincing gradients, shadows, and transparencies. With the alpha channel 32-bit color supports 4,294,967,296 color combinations.
[22:22:26 CET] <Foaly> screens can't display alpha
[22:22:41 CET] <kepstin> ricemuffinball: if you're making a semi-transparent image, you can use the extra 8-bits for an alpha channel, which says how transparent each pixel is
[22:22:42 CET] <Foaly> there are 10 bit per channel screens though
[22:24:04 CET] <kepstin> ricemuffinball: alpha doesn't add new colours, it just is an instruction on how to blend colours when you draw one image over top of another image.
[22:32:11 CET] <ricemuffinball> what is best lossy audio codec these days?
[22:32:58 CET] <klaxa> opus
[22:32:58 CET] <another> depends on your definition of best
[22:33:06 CET] <another> or what klaxa said
[22:33:30 CET] <ricemuffinball> best quality per bitrate
[22:33:37 CET] <klaxa> opus
[22:33:57 CET] <ricemuffinball> klaxa are you just saying opus because it's "free"
[22:34:02 CET] <durandal_1707> ac4
[22:34:40 CET] <ricemuffinball> ac4 ? never heard of it
[22:35:04 CET] <Foaly> free is a good reason though
[22:35:07 CET] <klaxa> same, but it seems to exist
[22:35:28 CET] <ricemuffinball> klaxa i don't know about quality of opus  but opus never seem to able to display bitrate correctly
[22:35:31 CET] <klaxa> ricemuffinball: opus out-performs all other formats at the time of opus release (afaict)
[22:36:04 CET] <ricemuffinball> klaxa that's the downside of opus
[22:36:18 CET] <klaxa> that it's better than everything else?
[22:36:28 CET] <ricemuffinball> but opus never seem to able to display bitrate correctly
[22:36:38 CET] <durandal_1707> huh?
[22:36:39 CET] <klaxa> https://opus-codec.org/comparison/
[22:36:48 CET] <klaxa> https://auphonic.com/blog/2012/09/26/opus-revolutionary-open-audio-codec-podcasts-and-internet-audio/
[22:37:06 CET] <ricemuffinball> youtube seems to like to use opus a lot
[22:37:43 CET] <another> it's basically the default on yt
[22:38:05 CET] <kepstin> ricemuffinball: it sounds like the issue is that the player you're using can't display opus bitrate correctly, which isn't opus fault :/
[22:38:11 CET] <ricemuffinball> does youtube use opus because it's free?
[22:38:23 CET] <klaxa> no, because it's the best quality per bitrate
[22:38:25 CET] <klaxa> just what you want
[22:38:29 CET] <ricemuffinball> keptstin true but it does that for every player
[22:38:50 CET] <durandal_1707> ricemuffinball: https://www.dolby.com/us/en/technologies/AC-4.html if you want costly solution
[22:38:58 CET] <ricemuffinball> if every player has problem, shouldn't that be opus's fault
[22:39:05 CET] <kepstin> ricemuffinball: it's a vbr codec, maybe it's just not behaving like you expect?
[22:39:07 CET] <klaxa> or rather, it's more acceptable at lower bitrates than mp3 or aac
[22:39:54 CET] <kepstin> ricemuffinball: depending on the player, it should show either an "average" bitrate over the entire file length, or the bitrate indicator may update as the file plays, showing the current bitrate at that moment
[22:40:23 CET] <ricemuffinball> https://github.com/HandBrake/HandBrake/issues/1944
[22:41:05 CET] <kepstin> well, that's certainly a handbrake bug alright.
[22:41:25 CET] <ricemuffinball> they are blaming on opus
[22:41:33 CET] <ricemuffinball> handbrake people are blaming on opus
[22:42:00 CET] <ricemuffinball> what should i type then
[22:42:08 CET] <ricemuffinball> if they are trying to blame on opus
[22:42:26 CET] <kepstin> no, they are having buggy handling of a particular codec implementation which doesn't report a bitrate for vbr data.
[22:42:47 CET] <kepstin> they either need to calculate it themselves e.g. by averaging based on stream size, or just not show it.
[22:42:48 CET] <ricemuffinball> isn't aac also VBR
[22:43:06 CET] <klaxa> dunno man, vanilla music on android is showing me 137kbps for an opus file
[22:43:09 CET] <klaxa> ffmpeg reports that as well
[22:43:10 CET] <kepstin> aac can be vbr or abr, you might get different results
[22:43:14 CET] <klaxa> i created that with ffmpeg
[22:45:01 CET] <ricemuffinball> ffprobe has problem with this too
[22:45:09 CET] <ricemuffinball> i just noticed
[22:45:20 CET] <ricemuffinball> this is definitely OPUS fault
[22:45:21 CET] <klaxa> well it's using the same library calls as ffmpeg
[22:45:28 CET] <klaxa> then explain why my files work
[22:45:29 CET] <klaxa> please
[22:45:57 CET] <ricemuffinball> Stream #0:1: Audio: opus, 48000 Hz, stereo, fltp (default)
[22:46:15 CET] <ricemuffinball> what is fltp ?
[22:47:05 CET] <another> floating point
[22:47:20 CET] <ricemuffinball> what is that exactly
[22:47:28 CET] <durandal_1707> aliens
[22:48:05 CET] <klaxa> numbers are not integers but floating points
[22:48:26 CET] <klaxa> they can represent numbers between integers, but have drawbacks
[22:48:34 CET] <ricemuffinball> ffprobe is not displaying bitrate on opus either
[22:49:18 CET] <durandal_1707> afaik opus does not have such info stored in its bitstream it needs to be manually calculated
[22:49:44 CET] <ricemuffinball> durandal_1707 i see, is opus the only audio format that has this issue?
[22:50:11 CET] <ricemuffinball> where it does not have such info stored in bitstream
[22:50:16 CET] <durandal_1707> ricemuffinball: nope, there are others for sure, it is just metadata
[22:50:28 CET] <klaxa> ricemuffinball, i queried you a link
[22:50:31 CET] <klaxa> with a file that works
[22:50:34 CET] <klaxa> would you try that?
[22:51:20 CET] <ricemuffinball> sure let me try
[22:51:24 CET] <ricemuffinball> sorry didn't see the PM box
[22:51:29 CET] <klaxa> no problem
[22:52:05 CET] <another> could also be related to the container
[22:52:20 CET] <ricemuffinball> Duration: 00:03:46.89, start: 0.000000, bitrate: 137 kb/s
[22:52:20 CET] <durandal_1707> yes...
[22:52:22 CET] <klaxa> oh yeah
[22:52:32 CET] <another> opus in mp4 has per stream bitrate information
[22:52:53 CET] <another> Duration: 00:06:53.43, start: 0.000000, bitrate: 96 kb/s Stream #0:0(und): Audio: opus (Opus / 0x7375704F), 48000 Hz, stereo, fltp, 94 kb/s (default)
[22:53:41 CET] <klaxa> in the end, this metadata is nothing but stream_size/stream_duration
[22:53:45 CET] <klaxa> and can be calculated on the fly
[22:53:52 CET] <durandal_1707> ac4 have bitrate info in its bitstream - but that is also optional and not mandatory to have such metadata....
[22:55:08 CET] <ricemuffinball> durandal_1707 you seems to really like ac4
[22:55:22 CET] <ricemuffinball> durandal is it better than opus?
[22:55:27 CET] <klaxa> paid shill, get out lol /s
[22:55:33 CET] <durandal_1707> lol
[22:56:13 CET] <klaxa> well it's not wrong comparing to the latest money-bought tech
[22:56:17 CET] <durandal_1707> ricemuffinball: dunno, i cant do blind ABX as there is no encoder available freely
[22:56:43 CET] <durandal_1707> but it is current trend in broadcast
[22:57:00 CET] <ricemuffinball> i cant do blind ABX ?  what is that even mean
[22:57:26 CET] <durandal_1707> https://en.wikipedia.org/wiki/ABX_test
[22:59:30 CET] <ricemuffinball> so whose fault is that opus doesn't display bitrate properly
[22:59:40 CET] <ricemuffinball> somebody needs to get blamed
[22:59:46 CET] <durandal_1707> nobody
[22:59:47 CET] <another> why?
[23:00:08 CET] <ricemuffinball> <kepstin> well, that's certainly a handbrake bug alright.
[23:00:25 CET] <ricemuffinball> because people are blaming eachother
[23:03:12 CET] <ricemuffinball> how comes this doesn't work:  ffmpeg -i input1.wmv -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate1.ts
[23:03:15 CET] <another> i think you're taking this a bit too seriously
[23:03:59 CET] <ricemuffinball> another, i want to know what bitrate opus is using since opus is getting more and more popular now
[23:05:59 CET] <klaxa> take the stream-size divide it by the stream-length
[23:06:03 CET] <klaxa> you get the average bitrate
[23:07:20 CET] <ricemuffinball> if it's that simple, why can't players/ffprobe get it right
[23:07:35 CET] <ricemuffinball> and handbrake
[23:08:27 CET] <ricemuffinball> Audio: Opus 48000Hz stereo 3072kbps [A: Stereo [eng] (opus, 48000 Hz, stereo)]
[23:08:53 CET] <ricemuffinball> that's wrong by the way
[23:10:40 CET] <klaxa> metadata is used if available and if not, then... not, correctness is not verified (usually impossible)
[23:10:53 CET] <klaxa> whoever muxed that did a bad job
[23:14:32 CET] <kepstin> hmm, i'm actually kind of surprised that ffprobe doesn't calculate per-stream bitrates when you use the -count_frames option
[23:14:44 CET] <kepstin> guess nobody ever wrote that code.
[23:15:31 CET] <ricemuffinball> and nobody has filed a bug report on ffmpeg?
[00:00:00 CET] --- Sat Mar  2 2019