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

[burek]

[11:27:18 CEST] <durandal_1707> \o/
[11:27:46 CEST] <durandal_1707> my magicyuv basic encoder is working
[12:19:21 CEST] <VP9-in-MP4> Just some quick Feedback, I'm not staying for a response: I was trying to merge a video-only file & an audio-only file & I got this error msg...
[12:19:47 CEST] <VP9-in-MP4> [mp4 @ 0000000002621400] VP9 in MP4 support is experimental, add '-strict -2' if you want to use it.
[12:20:04 CEST] <VP9-in-MP4> Could not write header for output file #0 (incorrect codec parameters ?): Experimental feature
[12:20:34 CEST] <VP9-in-MP4> ...I tried the "-strict -2" thing, but the file didn't play in VLC, it had the fourcc of vp09 instead of vp90, then I tried to force the fourcc & that didn't help either (not change), then I found that going back to the origianl command (no "-strict -2" & no "-vtag") & simply changing the output file extention to .webm made the command/conversion work without problems.
[12:20:50 CEST] <VP9-in-MP4> I'd like to suggest this error msg suggest that: change the file extension to webm (or any other extension that supports vp9 video, something like: VP9 in MP4 support is experimental, add '-strict -2' if you want to use it...did you mean to use the .webm extension instead?
[12:21:26 CEST] <nevcairiel> update to latest git master, vp9 in mp4 support was only standardized recently and encoding updated as appropriate
[12:22:33 CEST] <VP9-in-MP4> but the thing is, I wasn't even really trying for "vp9 in mp4", I just wanted to merge the files, I don't care which container it's in, I only care if it plays in VLC, if the container/extension is mp4 or webm doesn't bother me
[12:22:54 CEST] <BtbN> you must have told it to put vp9 into mp4 though
[12:23:04 CEST] <BtbN> So it gave the apropiate message
[12:23:04 CEST] <nevcairiel> then use webm, its vp9 support is far more widespread
[12:23:09 CEST] <VP9-in-MP4> the error assumes that I knew I was trying to get vp9 in mp4, I was just defaulting the extension to mp4, I had no idea that wasn't normal
[12:23:48 CEST] <BtbN> If you tell it to create an mp4 file, it will assume that mp4 is what you want. Can't really telepathically guess what you really want
[12:23:49 CEST] <nevcairiel> (also, vp09 seem to be the appropriate tag for vp9 in mp4)
[12:23:51 CEST] <VP9-in-MP4> nevcairiel: I didn't know that before...I didn't even know the source file was vp9 or that webm did support it or that mp4 didn't support it...I was simply trying to "merge files"...
[12:24:05 CEST] <nevcairiel> well we cant fix you not knowing things
[12:24:24 CEST] <nevcairiel> if you want blind operation, you should probably use some GUI tool that hides these details from you
[12:24:29 CEST] <VP9-in-MP4> no, but the error msg could help guide users, couldn't it?
[12:24:39 CEST] <BtbN> There are a million things the user might want
[12:24:51 CEST] <BtbN> There is no way to put all of them in there
[12:25:27 CEST] <BtbN> The user might also want h264 instead, but how would ffmpeg know?
[12:26:19 CEST] <VP9-in-MP4> BtbN: "Can't really telepathically guess what you really want"...actually, it could: it would be helpful if ffmpeg would see the video format & audio format & suggest the best output format based on those...it should suggest webm if my formats are most appropriate for that
[12:26:53 CEST] <BtbN> Why not suggest the most apropiate codecs for the requested container instead?
[12:27:07 CEST] <VP9-in-MP4> that would be a good option too
[12:27:15 CEST] <BtbN> But how would you know which one the user wants?
[12:27:22 CEST] <BtbN> Or even something entirely else?
[12:27:29 CEST] <VP9-in-MP4> I mean having a mode where ffmpeg could suggest 1 or the other
[12:27:42 CEST] <BtbN> and what with the other possiblities?
[12:27:52 CEST] <BtbN> Right now ffmpeg assumes the user knows what he/she is requesting.
[12:27:53 CEST] <VP9-in-MP4> it could use a command like param like --auto-container or --auto-codec
[12:28:02 CEST] <BtbN> So if mp4 is requested, it will to its best to deliver mp4
[12:28:07 CEST] <BtbN> *do
[12:28:19 CEST] <BtbN> If you do not specify a codec, it will default to container defaults already.
[12:28:43 CEST] <BtbN> which is not neccesarily a good choice in all cases
[12:29:33 CEST] <VP9-in-MP4> I'm sorry I'm not a video expert & don't know all the possible combinations of codecs & formats, I'm not an ffmpeg dev (although I am a dev & not a noob with computers)...so I didn't know vp9 wasn't normal in mp4, now I know...I just came here to suggest a slight alteration to that one error msg...
[12:30:04 CEST] <BtbN> It's not as easy as you think
[12:30:20 CEST] <BtbN> Those auto-suggestions would be wrong more often than right, and then make things worse
[12:30:21 CEST] <VP9-in-MP4> also, I wasn't specifying any audio or video codec, I was using -c copy to copy the input, so, then it would be nice if it would also copy the best container from the inputs
[12:30:27 CEST] <BtbN> so it's better to not suggest anything
[12:30:37 CEST] <BtbN> if you speficy -c you specify a codec
[12:30:47 CEST] <BtbN> copy is just a special case that does not transcode at all and keeps the input codec
[12:31:07 CEST] <BtbN> if you omit -c entirely, ffmpeg will transcode to container defaults
[12:31:11 CEST] <VP9-in-MP4> I prefer not transcoding most of the time
[12:31:23 CEST] <BtbN> yeah, then -c copy is fine
[12:33:22 CEST] <VP9-in-MP4> maybe my suggestion could be for ffprobe instead? maybe ffprobe could suggest the possible (or best) extensions/containers for the codecs it finds in the file? ffprobe is already an info-only program...
[12:36:37 CEST] <BtbN> Usually every container is just fine
[12:43:45 CEST] <VP9-in-MP4> BtbN: "So if mp4 is requested, it will to its best to deliver mp4"...I don't think there is, but: is there a way to not "request" any container & let ffmpeg choose? I'm pretty sure if I leave off the output file extension, that won't help. I only "requested" mp4, cuz that's the extension I typed, I didn't know I should've typed webm...
[12:44:15 CEST] <BtbN> I don't think there is.
[12:44:31 CEST] <BtbN> If it can't deduct the format from the extension, it will complain to you to specify a format explicitly
[12:45:03 CEST] <VP9-in-MP4> OK, then, that's my suggestion...have /someway/ to tell ffmpeg to help me choose, like maybe a command line option, or simple using the file extension .auto or something
[12:46:07 CEST] <VP9-in-MP4> I know ffmpeg might not be able to help or guess in all cases, but some cases are semi-easy...like webm & maybe mp4...those containers have "normal" codecs that go in them, even if they might overlap in codec support
[12:50:19 CEST] <VP9-in-MP4> I normally use -c copy, so ffmpeg should always have 2 codecs (audio & video) it knows about, so between those 2, it should have a really good idea of the "default" or "best" container/extension it should use...
[13:00:53 CEST] <BtbN> it really doesn't
[13:01:32 CEST] <BtbN> Usually you pick the container based on your needs
[13:03:20 CEST] <VP9-in-MP4> anyway, thx for the responses, I never stay in IRC very long...(leaving soon)...
[13:19:34 CEST] <VP9-in-MP4> ya know what I just thought of?...in addition to the -c copy option, ffmpeg needs some option like --copy or --preserve-all, so it would read the input & preserve the codecs AND container from the input, even if you specify the wrong output file extension. It already KNOWS the input codec AND container, so it already knows what to suggest (or use) for output, if you could tell it --preserve-all
[13:21:11 CEST] <J_Darnley> An interesting idea but isn't the output file openend/created first?
[13:21:32 CEST] <JEEB> also we do trust our users to actually know what they want
[13:22:12 CEST] <nevcairiel> creating a file with a format not matching the file extensions is just stupid. If you want the files to remain the same, I would expect you to be smart enough to actually pick the same extension
[13:22:34 CEST] <nevcairiel> well he left anyway
[13:54:30 CEST] Action: JEEB starts digging into stuff to get it upstreamed
[14:26:46 CEST] <durandal_1707> JEEB: what stuff?
[14:31:04 CEST] <JEEB> Yet Another Subtitle Format and its ISOBMFF mapping
[14:31:18 CEST] <JEEB> I will also have to verify that it was done according to spec and not according a Random Vendor's Requirements :)
[14:59:35 CEST] <J_Darnley> How does anyone make any progress writing something new?  I keep seeing things I already wrote are wrong.
[14:59:54 CEST] <BBB> just keep going
[15:00:20 CEST] <BBB> during my PhD, I learned the term verbal diarrhea, which means just write stuff
[15:00:33 CEST] <BBB> so the idea is to not get bogged down in self-questioning or doubt, but just keep going
[15:00:44 CEST] <BBB> and when youre finished, itll obviously be wrong, and thats when you start fixing it
[15:00:48 CEST] <BBB> until its correct
[15:00:56 CEST] <JEEB> yea
[15:01:00 CEST] <JEEB> that way you have *something*
[15:01:01 CEST] <BBB> for code, this can be a linear process, since theres only so many variables and states and calculations
[15:01:06 CEST] <BBB> so you just get the first one right
[15:01:09 CEST] <BBB> and then the second
[15:01:19 CEST] <BBB> and after N iterations, you are guaranteed that all N states are right
[15:01:23 CEST] <BBB> and then the function is finished
[15:01:33 CEST] <BBB> (or algorithm, or research, or ...)
[15:01:39 CEST] <JEEB> has anyone here looked into 14496-30?
[15:02:16 CEST] Action: J_Darnley already misses his constrained DSP assembly work.
[15:02:39 CEST] <BBB> assembly is the best example of this, yes
[15:09:03 CEST] <wm4> <J_Darnley> How does anyone make any progress writing something new?  I keep seeing things I already wrote are wrong. <- there are enough scapegoats, just complain about them and then ignore the problems, then add new ones instead
[15:09:28 CEST] <wm4> pretty high chance you'll be "right" anyway
[15:11:46 CEST] <BBB> lol
[15:19:33 CEST] Action: JEEB is trying to understand what exactly 14496-30's timing stuff menas
[15:26:03 CEST] <durandal_1707> J_Darnley: whats wrong?
[15:37:55 CEST] <JEEB> why the fuck couldn't people just have their shit within samples :|
[15:38:02 CEST] <JEEB> instead we have samples with XML samples within
[15:38:09 CEST] <JEEB> with duplicated timing information etc
[15:38:21 CEST] <JEEB> all this shit makes me very fucking sad
[15:40:37 CEST] <iive> JEEB: let me use a quote "just complain about them and then ignore the problems, then add new ones instead"
[15:42:47 CEST] <JEEB> for related laughter
[15:42:48 CEST] <JEEB> https://github.com/Dash-Industry-Forum/dash.js/issues/640
[15:44:18 CEST] <JEEB> so, ok. if I consider the samples within a fragment a solved problem (I'm not just yet 100% sure of that), I will also have to have fun with the timestamps within the samples (because those are TTML documents which also contain timing)
[15:44:29 CEST] <JEEB> now excuse me while I go get some whiskey
[15:54:41 CEST] <J_Darnley> atomnuker: about the order of these orientations/subbands...
[15:55:13 CEST] <J_Darnley> Are they 0=top-left, 1=top-right, 2=bottom-left, 3=bottom-right?
[15:55:27 CEST] <wm4> reaching balmer peak quickly, huh?
[15:58:24 CEST] <J_Darnley> wm4: I do not understand that
[15:59:22 CEST] <wm4> what?
[15:59:37 CEST] <wm4> https://xkcd.com/323/
[15:59:50 CEST] <J_Darnley> ah
[16:03:27 CEST] <durandal_1707> so what to do with golomb and cached reader?
[16:04:13 CEST] <nevcairiel> i dont suppose you can make it so that if the define is set before golomb is included, it'll also use cached then?
[16:04:20 CEST] <nevcairiel> i guess golomb uses the evil macros?
[16:08:32 CEST] <durandal_1707> it can be set with define, but i think its fragile
[16:21:06 CEST] <J_Darnley> Yay!  A colourful messy picture this time
[16:32:25 CEST] <iive> J_Darnley:  you should save this code and turn it into music visualization :D usually you could never think of such effects on purpose :D
[16:33:18 CEST] <J_Darnley> Sounds good but I have no idea how you would have audio change what it does.
[16:33:46 CEST] <J_Darnley> I guess you could run the encoder-decoder as a filter on some other vis source.
[16:34:37 CEST] <J_Darnley> Besides I already have a stalled audio vis project.
[16:37:15 CEST] <iive> :)
[16:39:03 CEST] <iive> you can draw a line that is result of frequency aplitudes, encode and decode the image, and draw new one over the result. 
[16:39:11 CEST] <iive> amplitures...
[17:19:06 CEST] <BBB> ubitux: have you ever seen tsan complain that atomic_int has a race condition? any idea what that could mean?
[17:19:36 CEST] <BBB> it literally just says that an atomic_store write and atomic_load read are concurrently reading and writing into the same variable - which appears to be the whole point of atomic types, right?
[17:19:44 CEST] <BBB> is my tsan just cmpletely b0rk3d?
[17:20:01 CEST] <ubitux> doesn't ring a bell
[17:20:09 CEST] <ubitux> i remember valgrind doesn't support them at all
[17:20:24 CEST] <ubitux> helgrind*
[17:20:52 CEST] <atomnuker> J_Darnley: I think, there are plenty of comments and the spec to tell you the order of LL, LH, HL and HH
[17:20:57 CEST] <ubitux> for tsan, maybe that's just because the lock has a too permissive mode?
[17:22:39 CEST] <BBB> Im just using the default load/store operations
[17:22:40 CEST] <BBB> no explicit
[17:22:53 CEST] <BBB> is that a bug?
[17:23:29 CEST] <ubitux> are you using the C atomics?
[17:24:44 CEST] <ubitux> anyway, maybe try to use explicit + the stricter order constraint
[17:25:12 CEST] <BBB> C atomics, yes
[17:25:15 CEST] <BBB> let me try explicit, tnx
[17:29:47 CEST] <BBB> this is all so complicated
[17:29:54 CEST] <BBB> not the threading, thats easy
[17:29:57 CEST] <BBB> but the atomic types
[17:30:28 CEST] <ubitux> yeah
[17:42:25 CEST] <JEEB> ubitux: I remember you being the subtitle masochist. let's say I'm making a new subtitle encoder+muxer and I need a test, so I need an input file. which FATE sample would you recommend or how else would you handle it? :D
[17:45:18 CEST] <ubitux> JEEB: text subtitles?
[17:45:21 CEST] <JEEB> yea
[17:45:30 CEST] <JEEB> although in theory there can be embedded images but let's not go there
[17:45:45 CEST] <ubitux> i'd say copy subrip and vtt encoders
[17:46:10 CEST] <JEEB> yea, this stuff I'm reviewing/rewriting here is based on the webvtt encoder as far as I can tell
[17:46:17 CEST] <ubitux> fate-sub-webvttenc: CMD = fmtstdout webvtt -i $(TARGET_SAMPLES)/sub/SubRip_capability_tester.srt
[17:46:23 CEST] <JEEB> cool
[17:46:34 CEST] <ubitux> that sample is covering enough features
[17:46:42 CEST] <JEEB> will put that in my notes
[17:47:05 CEST] Action: JEEB is working on upstreaming some stuff part by part
[17:47:30 CEST] <JEEB> first the basic support for encoding it, then movenc support
[17:47:34 CEST] <BBB> even then it still complains :-/
[17:47:37 CEST] <BBB> bah
[17:47:39 CEST] <BBB> stupid tsan
[17:47:41 CEST] <JEEB> the movenc part will be a PITA
[17:47:46 CEST] <BBB> Im going to assume its lying as usual
[17:47:51 CEST] <JEEB> because of the specification being stupid
[17:48:01 CEST] <ubitux> BBB: can i try?
[17:48:27 CEST] <BBB> not yet :( sorry
[17:50:36 CEST] <ubitux> covered by fate, we are using atomics in vp8, and builtin such as pthread_frame or lavu/buffer
[17:50:48 CEST] <ubitux> and tsan doesn't complain on those afaik
[17:53:17 CEST] <J_Darnley> Holy Shit!  Have I done this correctly?
[17:53:22 CEST] <J_Darnley> I don't believe it!
[17:57:48 CEST] <J_Darnley> kierank: can you fetch the dirac2 branch from my Gitlab repo and test the encoder, please.
[17:58:18 CEST] Action: J_Darnley goes afk for a bit
[18:00:47 CEST] <ubitux> do we already have some infrastructure for timed data stream?
[18:00:55 CEST] <ubitux> typically in mov/mp4
[18:02:15 CEST] <kierank> Ok
[18:07:01 CEST] <JEEB> ubitux: I think we had support for MOV timed text, however that was transferred?
[18:07:18 CEST] <JEEB> the whole ISOBMFF part of this subtitle format makes me cry so I hvaen't really looked into it yet, though...
[18:13:24 CEST] <J_Darnley> Ah there's a problem.  The default slice size doesn't work right with 420
[18:28:34 CEST] <JEEB> was there an avutil thing that took in the language metadata and output an RFC4646 thing?
[18:29:37 CEST] <JEEB> or do we just generally trust that the metadata is sane
[18:30:57 CEST] <JEEB> ok, seems like we trust
[18:31:04 CEST] <JEEB> at least my older code does
[18:36:06 CEST] <peloverde> durandal_1707: What do you think of the new SBR turnoff for 960?  aac_isobmff_960.m4a works fine for me now
[18:37:36 CEST] <durandal_1707> peloverde: ok
[18:39:05 CEST] <kierank> J_Darnley: i only care about 4:2:2 10-bit
[18:39:15 CEST] <kierank> so 420 you don't need to worry about
[18:42:44 CEST] <peloverde> durandal_1707: I think there are some merge conflicts about MDCT scale, but otherwise it's good to go
[18:49:26 CEST] <rcombs> JEEB: wait are you looking at VTT in BMFF
[18:49:34 CEST] <rcombs> if so, my condolences
[18:49:51 CEST] <rcombs> I looked into that, declared it unworkable, and yelled at the person who asked me to add it
[18:50:55 CEST] <rcombs> we ended up deciding to use .vtt text segments in some cases and ASS in others
[18:52:40 CEST] <wm4> lol
[18:57:30 CEST] <wm4> kierank: what is black?
[18:57:37 CEST] <wm4> in yuv... 16/16/128?
[18:57:40 CEST] <kierank> wm4: 16
[18:57:41 CEST] <kierank> duh
[18:57:53 CEST] <kierank> the full range neckbears are wrong
[18:57:57 CEST] <kierank> neckbeards
[18:58:09 CEST] <wm4> well I want to add a function to libavutil which fills an image with black
[18:58:33 CEST] <wm4> so I guess it depends not only on AVPixelFormat but also AVColorRange
[18:59:11 CEST] <kierank> makes sense to have a function like that
[18:59:40 CEST] <kierank> if you use picture buffer pools you can have avcodec have packet loss and show uninitialised data which could be porn from another instance using the pool
[18:59:41 CEST] <wm4> I'm also trying to avoid needing to have full handling of colors there, but black seems to be simple
[19:00:06 CEST] <wm4> yes, seems specifically useful for initialization
[19:00:18 CEST] <kepstin> seems like this duplicates some of the lavf drawutils code?
[19:01:04 CEST] <kepstin> although that can do a lot of stuff other than fill a frame with black :)
[19:01:23 CEST] <wm4> I've looked at the drawutils code, but it seems pretty bad, and doesn't even handle all pixfmts
[19:14:37 CEST] <kierank> wm4: you expected good stuff from libavfilter
[19:14:38 CEST] <kierank> lol
[19:15:38 CEST] <atomnuker> it satisfies all but the most autistic needs
[19:17:02 CEST] <wm4> and simple needs
[19:17:59 CEST] <atomnuker> simple is a subset of complex
[19:43:44 CEST] <rcombs> neckbears sound great
[19:44:14 CEST] <durandal_1707> headbears better
[19:44:54 CEST] <rcombs> kierank: did I tell you about the macOS bug where decoding failures or incorrect sizes would give you uninitialized surfaces _from other processes_
[19:45:08 CEST] <rcombs> like, you could see random bits of the Dock in the green mess
[19:45:13 CEST] <kierank> not a surprise
[19:45:34 CEST] <rcombs> apparently they weren't zeroing the buffers in the kernel when allocating hardware-decode surfaces
[19:45:48 CEST] <rcombs> they did fix that
[19:46:17 CEST] <rcombs> it was really easy to do, too: make a 2x2px H.264 stream, and put it in an MP4 with the stream resolution set to 1920x1080
[19:46:38 CEST] <rcombs> it'd allocate+display 1920x1080 surfaces and decode into the top-left corner
[19:46:58 CEST] <rcombs> worked on websites, too, so you could read random bits of vmem in javascript
[19:51:50 CEST] <kierank> lol
[19:54:54 CEST] <wm4> apple and multimedia
[19:57:12 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07master:c28f648b19dd: avcodec/mjpegdec: Clip DC also on the negative side.
[19:57:13 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07master:341f01290c23: avcodec/magicyuv: Check that vlc len is not too large
[20:26:33 CEST] <J_Darnley> Is there a "correct" way to generate an interlaced video stream with any of the source filters?
[20:27:39 CEST] <atomnuker> vf interlace
[20:28:17 CEST] <atomnuker> set the field order on the command line to make the encoder run in interlaced mode
[20:33:33 CEST] <J_Darnley> thank you
[21:14:16 CEST] <J_Darnley> atomnuker: thanks for the help you've provided
[21:14:48 CEST] <atomnuker> do levels != 4 work?
[21:14:59 CEST] <atomnuker> what speed gains did you get?
[21:15:21 CEST] <J_Darnley> I haven't tested speed yet
[21:15:28 CEST] <atomnuker> (you'll also have to make slice sizes different than the default work, crappy fpga decoders support 32x8 only AFAIK)
[21:15:44 CEST] <JEEB> wow
[21:15:46 CEST] <J_Darnley> Nice
[21:15:58 CEST] <atomnuker> and then they only support 3 level LeGall (5,3) wavelets
[21:16:15 CEST] <kierank> atomnuker: we might use 32x8
[21:16:25 CEST] <atomnuker> you probably should
[21:16:49 CEST] <kierank> we'll probably buffer 16 or 32 lines or whatever (omg muh latency the hardware people cry)
[21:17:25 CEST] <atomnuker> 4 levels seems to be the best the format can do, 5 levels and the coefficients get too large and you get overflows and also the image quality suffers
[21:18:11 CEST] <J_Darnley> Okay, I won't test 5 for now
[21:19:17 CEST] <J_Darnley> I do need to see how the encoder is supposed to do a slice height of 8 and wavelet depth of 4
[21:19:36 CEST] <tdjones> This is a 1000hz sin wave that has gone through the vorbis encoder with all short frames: https://0x0.st/GLw.jpg. It is spreading out the energy quite a bit and is only noticeable with pure tones or very resonant sources (stringed instruments). It's my understanding that this is likely something wrong with how the residue being encoded, or is it likely simpler?
[21:19:56 CEST] <atomnuker> tdjones: that's normal
[21:20:59 CEST] Action: J_Darnley curses automatic line wrapping in Vim
[21:21:30 CEST] <J_Darnley> Stop that!  That isn't correct bash syntax anymore!
[21:26:26 CEST] <tdjones> atomnuker: this is longer frames as a reference: https://0x0.st/GLI.jpg
[21:27:28 CEST] <tdjones> It is pretty significant when listening to it. I wouldn't expect to lose that much clarity by using smaller transforms
[21:33:28 CEST] <atomnuker> is that with transients?
[21:33:31 CEST] <atomnuker> on short blocks?
[21:33:35 CEST] <atomnuker> that's completely normal
[21:33:48 CEST] <atomnuker> with smaller blocks you get larger spectral leakage
[21:34:03 CEST] <atomnuker> you trade off frequency precision for temporal precision
[21:34:54 CEST] <atomnuker> (the uncertainty principle in action)
[21:35:18 CEST] <tdjones> Yeah, I knew there would be some leakage, but didn't expect it to be that much. That's why I wanted to ask someone on here before I wasted time trying to fix a nonexistant problem
[21:39:18 CEST] <atomnuker> here's how well opus deals with it: https://pars.ee/temp/opus_sine_10khz_20ms.jpg vs https://pars.ee/temp/opus_sine_10khz_2.5ms.jpg
[21:40:00 CEST] <atomnuker> this is at 510kbps, the max bitrate
[21:42:18 CEST] <tdjones> I see, thank you atomnuker
[21:53:24 CEST] <atomnuker> tdjones: can you get me samples of a 10khz sine wave encoded with 64 sample frames and 8192 sample frames?
[21:56:45 CEST] <atomnuker> curious to see how those ridiculously huge frames would help tonal stuff
[22:00:27 CEST] <tdjones> atomnuker: Let me see if I can, I think the residue and floor setups only work with their specific frame lengths
[22:04:04 CEST] <tdjones> It's not doable right this moment, I have to modify the how the floor and residues are partitioned so that they span the entire frame length rather than just the first 1024 samples
[22:04:52 CEST] <atomnuker> ok, fair enough
[22:05:53 CEST] <tdjones> I think I'm almost able to post this to ML, this madness with how codebooks are selected is the next change so that other lengths can be chosen
[22:09:46 CEST] <durandal_1707> can someone post on doom9 that magicyuv encoder is going to ffmpeg?
[22:11:04 CEST] <tdjones> I'm trying to parse the output of make fate a little better. With normal transient detection, should I expect the stddev from the input wav to increase? I'm getting an output of |654.71 - 296| >= 30 with a PSNR of 40.01. Is this a sign of something wrong in the encoder, or should I expect it? This difference doesn't seem that significant and isn't noticeable when listening
[22:11:44 CEST] <atomnuker> tdjones: is that with all short frames?
[22:12:59 CEST] <tdjones> No, it is with the frame length changing by itself
[22:13:50 CEST] <tdjones> All short is: "stddev: 6367.74 PSNR: 20.25"
[22:15:49 CEST] <tdjones> I'm not sure how to get those values if the test passes or else I could get the all long values too
[22:16:56 CEST] <atomnuker> oh deviation
[22:17:33 CEST] <atomnuker> yep, this looks fine, its lower
[22:18:17 CEST] <tdjones> I'm sure I could make it pass if I made transient detection a little more strict
[22:23:30 CEST] <atomnuker> don't bother
[22:23:37 CEST] <atomnuker> if it sounds fine its right
[22:24:20 CEST] <atomnuker> euclidian distance is not something anyone should be optimizing for
[22:26:10 CEST] <kierank> J_Darnley: you are meant to duplicate pixels I think
[22:26:15 CEST] <kierank> But atomnuker would know more
[22:29:58 CEST] <durandal_1707> so nobody did benchmarks with new bitstreamer, im really very disapointed
[22:30:40 CEST] <J_Darnley> Hm.  I saw that the transform is clearly separated but I wasn't so sure about the rest
[22:31:13 CEST] <atomnuker> durandal_1707: fine, I'll do some tonight
[22:31:23 CEST] <atomnuker> (for real this time)
[22:32:37 CEST] <durandal_1707> atomnuker: but you need to install computer first
[22:40:28 CEST] <durandal_1707> atomnuker: also whats up with audio denoiser?
[23:10:01 CEST] <atomnuker> I have a second less powerful laptop until I figure out kde or gnome
[23:12:48 CEST] <J_Darnley> Rats.  9_7 crashes and 5_3 is corrupt
[23:13:46 CEST] <atomnuker> keep in mind those need to overread into the next slice IIRC
[23:14:35 CEST] <J_Darnley> Ah
[23:14:44 CEST] <J_Darnley> I might have to revert a change I made
[23:15:59 CEST] <J_Darnley> Yes.  I obliterated something which causes an abort in a free
[23:42:43 CEST] <kierank> atomnuker: no, they need interpolation at edges I believe
[23:42:54 CEST] <kierank> In single slice mode
[23:43:05 CEST] <kierank> In full transform it's overread
[23:43:15 CEST] <kierank> The paper proves they are equivalent
[23:45:04 CEST] <atomnuker> ok
[00:00:00 CEST] --- Thu Jul 13 2017