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

[burek]

[00:21:55 CEST] <J_Darnley> BBB: thank you for your incredible efforts
[00:22:41 CEST] <J_Darnley> I will do my best to that patch you made.
[00:23:25 CEST] <J_Darnley> *to check
[00:23:48 CEST] <J_Darnley> Otherwise I will see if I an make wmv1 always use the C
[00:24:40 CEST] <J_Darnley> Failing that I will leave the new code unused with -idct simple
[00:25:23 CEST] <atomnuker> jkqxz: is the hardware vp9 encoder on newer intel systems realtime? so finally there's a way to encode vp9 in real time?
[00:27:12 CEST] <atomnuker> (I think the only way that was doable currently was with one of those old very clockable intels clocked at 7.5Ghz cooled with liquid nitrogen)
[00:27:13 CEST] <jkqxz> It can 4K60.  Is that realtime enough for you?
[00:27:28 CEST] <atomnuker> whoa
[00:27:28 CEST] <BBB> how good is the quality?
[00:27:38 CEST] <BBB> I can make you a realtime encoder in a few minutes, it just will suck
[00:27:51 CEST] <BBB> aka bitstream writer"
[00:28:07 CEST] <jkqxz> Not completely terrible - better than the QuickSync H.264 encoder.  I've never investigated much beyond that, though.
[00:28:16 CEST] <BBB> J_Darnley: happy to make it work :) I hope this was the last of it, though
[00:30:37 CEST] <J_Darnley> It was the last from fate
[00:33:53 CEST] <kierank> jkqxz: i thought 4kp30 max?
[00:34:07 CEST] <jkqxz> atomnuker:  It maintains about 70fps at 4K on my 7500U.
[00:34:31 CEST] <kierank> interesting
[00:34:39 CEST] <nevcairiel> vpx has a re altime mode, no clue how terrible the quality output is though
[00:34:54 CEST] <jkqxz> If someone wants streams to analyse the quality of I can easily make them.
[00:35:17 CEST] <atomnuker> nevcairiel: the realtime mode just disables certain bitstream features AFAIK
[00:36:16 CEST] <JEEB> heh
[01:11:47 CEST] <TMM> Is it possible to submit patches to this page? https://www.ffmpeg.org/developer.html The link to the Signed-Off-By explanation points to nowhere now, it should point to https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
[01:15:31 CEST] <durandal_1707> no need
[01:16:28 CEST] <TMM> ok
[01:18:03 CEST] <atomnuker> TMM: if you want to submit a patch to the website just git clone https://git.ffmpeg.org/ffmpeg-web and submit a patch to ffmpeg-devel as usual
[01:19:05 CEST] <TMM> atomnuker, I'll do that, thanks
[01:20:25 CEST] <durandal_1707> get re other codecs in mean time?
[01:20:42 CEST] <TMM> me?
[01:20:59 CEST] <durandal_1707> who else
[01:21:10 CEST] <durandal_1707> only you left
[01:21:44 CEST] <kierank> lol
[01:21:52 CEST] <kierank> durandal_1707: you are becoming keiler2
[01:22:03 CEST] <atomnuker> !42!#
[01:22:06 CEST] <durandal_1707> who?
[01:22:20 CEST] <TMM> durandal_1707, well, I'm going to port some of the scummvm enhancements to bink to ffmpeg, and implement sprite support for truemotion1
[01:22:55 CEST] <durandal_1707> huh, sprite?
[01:22:57 CEST] <TMM> durandal_1707, We're adding more FMV games to scummvm, so I imagine more codecs will be coming, there's a lot of em in that space
[01:23:19 CEST] <TMM> yeah, truemotion1 has a 'sprite mode' that's currently unknown
[01:23:35 CEST] <TMM> it's used by a lot of the fmvs at the time, like the star trek fmv games
[01:24:22 CEST] <durandal_1707> oh, what about nongame codecs?
[01:25:23 CEST] <TMM> not really my area of interest, but if you have a suggestion for something that's actually used I can maybe put it on the list?
[01:26:24 CEST] <TMM> surely other people are reverse engineering video codecs?
[01:27:05 CEST] <durandal_1707> mostly kierank expertize, ask him for help
[01:27:13 CEST] <kierank> lol
[01:27:31 CEST] <TMM> I'm... confused
[01:27:43 CEST] <kierank> there are not that many video codecs left to RE
[01:28:24 CEST] <durandal_1707> there are many left, but dead
[01:28:42 CEST] <TMM> well, if they are used in games I'll run across them eventually I guess?
[01:29:37 CEST] <durandal_1707> games are very special, there is bunch of audio only formats
[01:30:05 CEST] <TMM> yeah, scummvm has support for quite a few somewhat obscure audio formats
[01:30:20 CEST] <durandal_1707> for video there are bunch of bink variants
[01:30:34 CEST] <TMM> I intend to port all of them to ffmpeg, and then add a libavformat/libavcodec compatibility layer in scummvm to use the codesc from ffmpeg directly
[01:30:49 CEST] <durandal_1707> omg
[01:30:54 CEST] <TMM> scummvm doesn't want to depend on libavcodec/libavformat directly
[01:30:58 CEST] <durandal_1707> you cant be serious
[01:31:55 CEST] <TMM> *shrug* it's the best way I know of how to get the knowledge of scummvm into a more generic form for others
[01:32:25 CEST] <JEEB> some people just have weird ideas about FFmpeg (and if you've never touched the APIs the libs can feel scary)
[01:32:28 CEST] <TMM> I'd rather not have this duplicated and the internal apis for those things are pretty simple
[01:32:39 CEST] <JEEB> although during the last N years the APIs have improved
[01:32:56 CEST] <TMM> maybe, but scummvm tries to run on weird ass hardware
[01:33:26 CEST] <JEEB> if you've seen the FATE suite there's plenty of stuff there, too :)
[01:33:39 CEST] <TMM> I doubt I can get ffmpeg interested in an officially supporting os/2 
[01:33:46 CEST] <TMM> or dreamcast 
[01:33:54 CEST] <JEEB> I thought the koreans were posting patches wrt OS/2
[01:34:08 CEST] <JEEB> dreamcast I'm not sure if it needs special stuff if the toolchain is OK?
[01:34:22 CEST] <jamrial> afaik ffmpeg used to compile on sh4 targets
[01:34:32 CEST] Action: JEEB built FFmpeg for PSP some time ago, which is an older MIPS thing
[01:34:33 CEST] <jamrial> years ago, though. probably not anymore
[01:34:35 CEST] <TMM> I don't know either, but the scummvm project is super paranoid about portability
[01:34:55 CEST] <TMM> I really doubt I'll ever get enough people convinced to add libavcodec/libavformat as an external dependency
[01:35:49 CEST] <TMM> I don't think it'll really matter, I just want to be able to share the interesting codec and demuxer bits between the two projects
[01:36:39 CEST] <TMM> The way I see it, what scummvm does for old games ffmpeg does more generalized for av formats. I think it's important to preserve both in its most useful form
[01:36:51 CEST] <TMM> for games that's I think in scummvm, for av formats that's ffmpeg
[01:36:56 CEST] <durandal_1707> does your mve patches allows to play super mario sample from trac?
[01:37:02 CEST] <TMM> durandal_1707, yes
[01:37:26 CEST] <TMM> durandal_1707, that's a format 0x10 movie, that's supported with my patchset
[01:37:35 CEST] <durandal_1707> great
[01:38:38 CEST] <durandal_1707> so scummvm have support for such games that use this coding?
[01:38:40 CEST] <TMM> the star trek trailer seems to use another unknown opcode, but the movie plays fine
[01:38:56 CEST] <TMM> I'll probably look into that eventually
[01:39:57 CEST] <TMM> durandal_1707, we're currently adding support for a game called "Kingdom: The far reaches" it uses both the 0x06 and 0x10 frame formats. Although, as it turns out, it only uses the 0x10 frame format for the Interplay logo. That was a little disappointing. But at least we can now maybe add support for mario teaches typing :P
[01:43:45 CEST] <TMM> https://trac.ffmpeg.org/ticket/5401 <-- this also plays now
[01:44:45 CEST] <TMM> https://trac.ffmpeg.org/ticket/4740 <-- this too
[01:45:36 CEST] <TMM> should I comment on the trac thing? Or just wait to see if this gets merged?
[01:45:54 CEST] <Shiz> TMM: you may be able to get support in as sh4 is an upstream linux arch too
[01:46:01 CEST] <Shiz> that should lay some basics for dreamcast support
[01:48:35 CEST] <TMM> maybe, if I can get it to build everyhwere... I'll have to ply some developers with beer I think. Actually using libavcodec is going to meet with quite some resistance
[01:50:54 CEST] <jamrial> TMM: wait for the patches to be commited. then those tickets can be closed
[02:01:39 CEST] <cone-289> ffmpeg 03James Almer 07master:3c5a53cdfa09: avformat/oggenc: add ogg_init() and ogg_free()
[03:46:51 CEST] <cone-289> ffmpeg 03James Almer 07master:e229df9478b2: x86/aacpsdsp: add ff_ps_hybrid_synthesis_deint_{sse,sse4}
[03:46:52 CEST] <cone-289> ffmpeg 03James Almer 07master:8bb59e6742ee: x86/aacpsdsp: add ff_ps_hybrid_analysis_ileave_sse
[03:48:47 CEST] <jamrial> single threading decoding of HE-AACv2 went from 533x real time to 548x real time on my haswell i5 with those two patches :p
[03:49:44 CEST] <jamrial> kierank: ^ i think think you were interested in aacps performance some time ago
[03:49:55 CEST] <jamrial> although now with opus maybe not anymore
[03:55:12 CEST] <kierank> jamrial: no not me afaik
[03:58:06 CEST] <rcombs> nice
[04:36:22 CEST] <cone-289> ffmpeg 03Steven Liu 07master:3996ae930256: avformat/hlsenc: donnot show duplicate segment warning at byterange mode
[09:31:18 CEST] <mateo`> I'm working on fixing the checkasm_checked_call on aarch64, it makes the new checkasm float_dsp test fails (but also the future sbrdsp tests that i'd like to add)
[09:32:04 CEST] <mateo`> currently, functions that return a float always return 0
[10:53:46 CEST] <cone-698> ffmpeg 03Nicolas George 07master:d790f18ac0c3: lavfi: print the error message when threading init fails.
[11:15:19 CEST] <Guest69427> Hi, I'm using ffprobe to get the number of frames "nb_frames". Then I use it as input to ffmpegs select filter. Is it possible to get "nb_frames" without using ffprobe, maybe as an input parameter to select? Or is it possible to pipe the stream from ffprobe directly into ffmpeg so I don't need to download the file twice?
[11:16:35 CEST] <nevcairiel> to count the frames you first need to read the entire file, so if you need this information before actually processing the file, reading it twice seems unavoidable
[11:17:15 CEST] <Guest69427> Ok, I see
[11:27:23 CEST] <Guest69427> @nevcairiel Reading the file is not the problem but downloading it twice is. Does ffprobe and ffmpeg share cache or something like that?
[11:46:55 CEST] <wm4> I don't think ffprobe normally actually counts the number of frames
[11:47:00 CEST] <wm4> so this info is likely very unreliable
[11:55:25 CEST] <JEEB> ffprobe -show_frames I think decodes them all?
[11:55:54 CEST] <JEEB> Guest69427: no. you'd have to either use the API or just handling the transfer of stuff separately
[11:57:35 CEST] <thebombzen> Guest69427: by the way, #ffmpeg is the ffmpeg help channel and #ffmpeg-devel is the channel about working on ffmpeg itself, just for future reference
[13:44:24 CEST] <J_Darnley> Hello BBB.  Could I ask you for a brief summary of what the last patch you gave me does?
[13:44:50 CEST] <BBB> disable unquantize shortcuts based on end-of-block positions for wmv1
[13:45:01 CEST] <J_Darnley> Ah
[13:45:05 CEST] <BBB> because the scantable used in the unquantized scantable does not match the one used in wmv1
[13:45:29 CEST] <BBB> I dont know 100% for sure why, it may be because h263_unquantize_intra uses the inter scantable (????????)
[13:45:37 CEST] <BBB> and I believe wmv1 has a specific intra scantable
[13:45:42 CEST] <BBB> but I dont know 100% for sure
[13:46:29 CEST] <BBB> regardless, the bug was in unquantize not dequantizing some coefs, and the reason was that the end-of-block position not making sense, so this works around it
[13:46:42 CEST] <J_Darnley> Okay, I will write a note in the commit message
[13:47:07 CEST] <J_Darnley> Or since this is a 2 line change, a long essay
[13:51:44 CEST] <BBB> hehehe
[13:51:56 CEST] <BBB> someone (michaelni) may actually have ideas on better fixes for this
[13:52:04 CEST] <BBB> my gal isnt so much to provide ideal fixes, but rather to pinpoint the bug
[13:52:09 CEST] <BBB> theres many ways to fix bugs like this
[13:52:19 CEST] <BBB> and Im fine if michaelni chooses to fix it differently or re-do the fix later on
[13:52:29 CEST] <BBB> (or anyone else, for that matter)
[13:52:36 CEST] <BBB> gal->goal
[14:13:12 CEST] <cone-329> ffmpeg 03Paul B Mahol 07master:ca5cf84655f3: avfilter: add superequalizer filter
[14:13:12 CEST] <cone-329> ffmpeg 03Paul B Mahol 07master:b9d0a5fc215f: avfilter: add roberts cross operator
[14:19:21 CEST] <J_Darnley> BBB: sorry to bug you again but do you know how changing the IDCT permutation lead to this being revealed?
[14:20:54 CEST] <BBB> the mmx implementation for unquantize dequants in 4x1 blocks
[14:21:33 CEST] <BBB> so the permutation causes the position of the non-zero-by-unquantized coef to change
[14:21:46 CEST] <BBB> the bug was there before and may or may not have caused quality degradations in wmv1 encoding
[14:21:52 CEST] <BBB> but nobody encodes wmv1 so nobody cares
[14:22:09 CEST] <JEEB> ayup
[14:47:17 CEST] <TMM> What's the preferred way of updating a patch on the mailing list? I was thinking of replying to my original patch with the new version?
[14:47:56 CEST] <atomnuker> I prefer a new post with prefix [PATCH v2]
[14:48:20 CEST] <TMM> should i repost my entire series then?
[14:48:43 CEST] <atomnuker> no, just what you changed with --subject-prefix="PATCH v2"
[14:49:05 CEST] <TMM> OK, I'll see if I get some more reviews and repost the patches that changed then
[14:49:16 CEST] <BBB> michaelni: does ffmpeg have a way of doing encoder/decoder reconstruction buffer matching? (like dump-yuv in x264)
[14:49:17 CEST] <atomnuker> also use git send-email if you can because downloading attachments to view new patches is annoying
[14:49:23 CEST] <BBB> michaelni: that might be incredibly helpful as a fate test
[14:49:55 CEST] <atomnuker> we have vsynth tests...
[14:50:04 CEST] <BBB> they just measure psnr
[14:50:19 CEST] <BBB> they dont measure that the encoder/decoder representations match
[14:50:45 CEST] <BBB> imagine that you have in.yuv
[14:50:53 CEST] <BBB> and we do ffmpeg -i in.yuv -c:v blabla out.avi
[14:51:01 CEST] <BBB> ffmpeg -i out.avi -f rawvideo out-yuv
[14:51:06 CEST] <BBB> measure_psnr in.yuv out.yuv
[14:51:07 CEST] <atomnuker> yes, I know what you mean
[14:51:12 CEST] <BBB> ok
[14:51:40 CEST] <BBB> (for those who dont: I want ffmpeg -i in.yuv -dumpyuv dump.yuv out.avi and then assert that dump.yuv and out.yuv are identical)
[14:51:46 CEST] <atomnuker> what's wrong with testing encoders and decoders separately?
[14:51:54 CEST] <BBB> that should still be done
[14:52:13 CEST] <BBB> but I want to ensure that the encoder representation of the decoder state (reference frame reconstruction etc.) is correct
[14:52:16 CEST] <BBB> I believe right now its not
[14:52:30 CEST] <BBB> at least for wmv1
[14:54:46 CEST] <michaelni> BBB, there was CODEC_FLAG2_MEMC_ONLY, it was removed by a merge (e37f161e66e042d6c2c7470c4d9881df9427fc4a)
[14:55:42 CEST] <BBB> Im not sure Im familiar with that flag :(
[14:55:44 CEST] <BBB> what did it do?
[14:56:00 CEST] <michaelni> what you asked for
[14:56:27 CEST] <michaelni> it wasnt supported by most codecs though
[14:57:08 CEST] <BBB> Im not sure what it does based on the description I find online
[14:59:27 CEST] <BBB> a literal dumpyuv option would not need per-codec support, right?
[14:59:52 CEST] <BBB> I mean, for mpegvideo, it would literally be done at the end of the slice coding loop
[15:00:13 CEST] <BBB> that wouldnt enable it for libx264/vpx, but at least itd work for all mpegvideo-style codecs
[15:00:17 CEST] <atomnuker> the thing is what happens if the encoder's quality changes?
[15:00:27 CEST] <BBB> wdym?
[15:00:46 CEST] <atomnuker> well, the reconstruction would be different
[15:00:55 CEST] <BBB> why
[15:01:02 CEST] <BBB> or: different from what?
[15:01:11 CEST] <atomnuker> from the previous value it had
[15:01:15 CEST] <BBB> thats fine
[15:01:21 CEST] <BBB> but the decoder recon should change along with it
[15:01:25 CEST] <BBB> we dont take a md5 of the yuv
[15:01:31 CEST] <BBB> we just ensure decoder/encoder md5 of the yuv match
[15:01:38 CEST] <BBB> we dont care what their value is
[15:01:42 CEST] <BBB> as long as it matches
[15:01:50 CEST] <BBB> the existing psnr check will make sure that quality is fine
[15:02:00 CEST] <BBB> (ignoring whether psnr is a good quality metric)
[15:02:17 CEST] <atomnuker> I don't get it, they can't ever match unless the codec is lossless
[15:02:26 CEST] <BBB> they have to match
[15:02:30 CEST] <BBB> read x264 --dumpyuv
[15:02:33 CEST] <atomnuker> you're talking about the decoder's output?
[15:02:35 CEST] <BBB> if they dont match, the encoder is buggy
[15:02:36 CEST] <BBB> yes
[15:02:44 CEST] <BBB> run it
[15:03:21 CEST] <BBB> x264 -i somefile dumpyuv bla1.yuv -crf 40 out.x264 && ffmpeg -i out.x264 bla2.yuv && assert(!memcmp(bla1.yuv, bla2.yuv))
[15:03:32 CEST] <BBB> run that, youll see it matches
[15:03:38 CEST] <BBB> it _has_ to match, regardless of options
[15:03:42 CEST] <BBB> if it doesnt match, your encoder is broken
[15:04:17 CEST] <BBB> how can x264 do motion search if it doesnt know what the reference frames reconstruction in the decoder looks like?
[15:04:23 CEST] <BBB> it would never be r/d optimal
[15:04:42 CEST] <atomnuker> oh ffs, be more specific damnit
[15:04:50 CEST] <BBB> I dont understand what you mean
[15:05:10 CEST] <BBB> x264 (or ffmpeg, or whatever) will encode blocks with a particular reconstruction based on prediction and coefficients
[15:05:37 CEST] <BBB> this reconstruction is defined, it has a particular expected form and that is guaranteed to be identical for a given implementation of the decoder
[15:05:38 CEST] <atomnuker> I thought you meant encoder -> packet -> decoder, not encoder -> packet AND ref out -> decoder, etc
[15:06:01 CEST] <atomnuker> I've never used x264's cli tool so I didn't what what its option was
[15:06:07 CEST] <BBB> ah
[15:06:19 CEST] <BBB> dump-yuv is amazing for debugging
[15:06:28 CEST] <BBB> (if youre working on x264 internals and butchering random crap)
[15:06:41 CEST] <BBB> libvpx has a similar feature
[15:06:53 CEST] <TMM> atomnuker, on the new patchset I did use git send-email, the RFC patch was all kinds of wrong, sorry about that.
[15:07:32 CEST] <BBB> (--test-decode=)
[15:30:53 CEST] <BBB> regarding the vaapi patches, does that work on hw decoders?
[15:31:49 CEST] <jkqxz> Does what work on hw decoders?
[15:33:29 CEST] <BBB> show-existing-frame
[15:34:17 CEST] <jkqxz> Why wouldn't it?  It has to be there in the decoded frames to be used for reference.
[15:34:29 CEST] <BBB> I dont think all hw decoders support it
[15:34:31 CEST] <jkqxz> I admit I've only tried the VAAPI hwaccel, though.
[15:34:36 CEST] <jkqxz> What decoders don't?
[15:34:59 CEST] <BBB> what kind of cell phone do you have?
[15:35:02 CEST] <BBB> and your friends
[15:38:02 CEST] <BBB> jkqxz: serious question :)
[15:40:28 CEST] <jkqxz> SnapDragon 430.  I can't tell whether that should have it or not.
[15:41:21 CEST] <jkqxz> This mode isn't enabled by default, so I'm not sure how much I care about incomplete hardware implementations which can't cope with it.
[15:41:55 CEST] <BBB> out-of-order frames/alt-ref frames?
[15:42:13 CEST] <BBB> Ive seen the problem in snapdragon 820, I believe it may exist (from what Ive heard) in others also
[15:42:47 CEST] <jkqxz> What is the observed behaviour?  The reordered frames just never get shown?
[15:43:15 CEST] <BBB> they are corrupted
[15:52:52 CEST] <jkqxz> Hmph.  Supposing it does fail on some devices, what should I do about it?
[15:55:27 CEST] <BBB> jkqxz: now thats a very good question. You could use overlay frames like libvpx does& you could disable alt-ref frames altogether. or just show a warning and use show-existing-frames anyway
[16:02:25 CEST] <BBB> if you dont think any of this matters, you could also ignore it
[16:04:36 CEST] <jkqxz> That means encoding an all-skip frame referring to the non-shown frame encoded earlier?
[16:07:30 CEST] <BBB> thats an overlay frame, yes
[16:07:33 CEST] <BBB> its quite complex TBH
[16:07:46 CEST] <BBB> which is why I said if you want ot ignore this, I get it and its fine
[16:09:36 CEST] <jkqxz> Yeah.  Feeding the frame into the hardware encoder again will probably generate something subtly different (and slow everything down signficantly), while making it in software would be a very non-fun exercise in the entropy coding (especially because it would be necessary to decode quite a bit of the rest of the stream coming from hardware to do that).
[16:14:29 CEST] <jkqxz> Probably also messes with RC.  show-existing-frame is very nice there because it's just one byte.
[16:20:13 CEST] <BBB> I agree
[16:20:15 CEST] <BBB> ok, fine then
[16:20:28 CEST] <BBB> just saying youll probably get a bug report at some point about it
[17:35:23 CEST] <atomnuker> BBB: what happened with the gsoc to implement vmaf?
[17:44:28 CEST] <tdjones> atomnuker: I'm not sure I understand what you mean by determining the optimum residue classbook in the vorbis encoder. The classbook is defined in the header of the stream, before any audio is analyzed
[17:46:38 CEST] <BBB> atomnuker: wdym? yours? or mine (ashish)?
[17:47:00 CEST] <BBB> mine is working on it as we speak, and has some working code for part of the project
[17:52:17 CEST] <atomnuker> cool
[17:52:51 CEST] <atomnuker> tdjones: the header currently goes in extradata which is prepended onto the packet and is static, so you'll have to modify that
[17:53:03 CEST] <atomnuker> (its a weird design choice)
[17:55:45 CEST] <cone-329> ffmpeg 03Michael Niedermayer 07master:f670c13f1399: avcodec: Rename ff_mpv_decode_mb() to ff_mpv_reconstruct_mb
[17:55:46 CEST] <cone-329> ffmpeg 03Michael Niedermayer 07master:cf7edbd6c5d4: avcodec/aacdec_fixed: Check s for being too small
[17:55:47 CEST] <cone-329> ffmpeg 03Michael Niedermayer 07master:5f89747086af: avcodec/wavpack: Fix undefined integer negation
[18:00:37 CEST] <atomnuker> tdjones: give me a moment, I'll give you a patch which does that
[18:01:04 CEST] <atomnuker> (this is absoultely horrible, what idiot thought it was a good idea to put the header in the extradata)
[18:16:19 CEST] <atomnuker> holy fucking shit...
[18:19:02 CEST] <tdjones> All headers in vorbis are defined at the beginning of the stream, not per packet. I'm curious what harm is done putting them in extradata for the context
[18:19:38 CEST] <atomnuker> this is fucked up
[18:20:03 CEST] <cone-329> ffmpeg 03Paul B Mahol 07master:2820c9dfaa1f: avfilter/af_superequalizer: fix out of array access
[18:20:04 CEST] <cone-329> ffmpeg 03Paul B Mahol 07master:53624d62d9a3: avfilter/af_superequalizer: improve description
[18:20:54 CEST] <atomnuker> tdjones: do multiple modes work yet?
[18:21:57 CEST] <atomnuker> so in vorbis, you predefine everything you plan to use at the header in terms of modes and you switch between them at runtime
[18:22:24 CEST] <atomnuker> ...without any knowledge what input you'll get...
[18:22:51 CEST] <atomnuker> this is completely backwards
[18:23:06 CEST] <tdjones> yes, I have multiple modes and windows set up correctly
[18:23:31 CEST] <tdjones> And, yes practically everything is defined at the beginning of the file
[18:26:44 CEST] <tdjones> The offside is that each residue adds more memory the decoder must store when going through the stream
[18:27:53 CEST] <tdjones> I'm not sure how much increase in quality would actually come from switching mappings for anything other than subwoofer channels
[18:34:00 CEST] <TD-Linux> atomnuker, yes, in practice they are fixed per encoder version
[18:35:03 CEST] <TD-Linux> the idea was room for future encoder improvements, however in retrospect it was considered a bad idea, hence why opus went in the opposite direction
[18:35:49 CEST] <cone-329> ffmpeg 03Paul B Mahol 07master:1a4236e025a8: avfilter/af_superequalizer: stop leaking s->out frame
[18:40:44 CEST] <atomnuker> tdjones: bind the number of passes (currently 8) in for (pass = 0; pass < 8; pass++) { to avctx->compression_level and set it to 8 as default again (using AVCodecDefault like opusenc)
[18:44:59 CEST] <atomnuker> after that adjust the encoder to create 2 residues and thus 4 mappings (1 per each frame type, so 2 since you have 1 long and 1 short type x 2 = 4)
[18:47:20 CEST] <atomnuker> after that write a search_for_residues() function which calls residue_encode with different mappings in the main function and measures distortion and bit cost
[18:48:09 CEST] <atomnuker> (use euclidian distance e.g. dist += (x[i] - y[i])^2 and then take the sqrtf of the distortion)
[18:48:22 CEST] <tdjones> atomnuker: That should work
[18:48:34 CEST] <atomnuker> then once you have distortion and bit cost you can do RDO
[19:02:33 CEST] <cone-329> ffmpeg 03Paul B Mahol 07master:ef178f630f79: avfilter/af_stereotools: add 2 more modes
[19:30:02 CEST] <cone-329> ffmpeg 03Paul B Mahol 07master:c7a2a379fd05: doc/filters: fix typo
[20:01:59 CEST] <BBB> J_Darnley: do you know how to add the permutated quant table to mdec?
[20:02:39 CEST] <BBB> J_Darnley: I can write that for you if you dont know how to do it
[20:07:27 CEST] <BBB> J_Darnley: other than the few comments, I think the patch series is pretty cool and I really like how simple no longer means c"
[20:07:34 CEST] <BBB> thats a massive improvement IMHO
[20:09:48 CEST] <KevinM> I have a few patches outstanding from the past week or two. They're relatively minor, in my opinion. Is there any time after which it's acceptable to ping them?
[20:10:11 CEST] <JEEB> 21
[20:10:43 CEST] <kevmark> Three weeks? Gotcha.
[20:11:01 CEST] <JEEB> no
[20:11:04 CEST] <JEEB> that was me typoing
[20:11:05 CEST] <JEEB> sorry
[20:11:14 CEST] <JEEB> anyways, it's OK to ping within 5-7 days
[20:11:35 CEST] <kevmark> Okay, thanks.
[20:11:36 CEST] <JEEB> although sometimes nobody who knows enough about the subject is around
[20:11:45 CEST] <BBB> then just push IMO
[20:11:47 CEST] <JEEB> which is why some even simple patches can lie around on the ML
[20:11:55 CEST] <BBB> esp. if theyre trivial
[20:12:10 CEST] <J_Darnley> BBB: I will probably manage
[20:12:14 CEST] <kevmark> BBB, I don't have push access as far as I know
[20:12:22 CEST] <kevmark> Oh, sorry, wrong convo
[20:13:44 CEST] <kevmark> JEEB, Thanks, makes sense. I believe Michael is familiar with the scale filter that I've been working on so I was just waiting for him to get around to that again. I've had a few patches for that filter accepted from him already.
[20:13:45 CEST] <BBB> kevmark: that one comment was for you :)
[20:14:04 CEST] <BBB> kevmark: didnt I close a bug for you a few days ago?
[20:14:06 CEST] <BBB> anyway
[20:14:08 CEST] <kevmark> BBB, is there an application process I need to go through to have push access?
[20:14:16 CEST] <BBB> kevmark: ask michael :-p
[20:14:20 CEST] <BBB> or really, ask on the m/l
[20:14:28 CEST] <kevmark> I believe it was this? https://trac.ffmpeg.org/ticket/5392
[20:14:35 CEST] <BBB> but youd still need to get approval to push patches, you can just push approved patches yourself
[20:14:43 CEST] <BBB> yes
[20:15:07 CEST] <kevmark> Michael has set me up with a developer trac account (so I can close bugs) but I'm guessing that's separate from the repo
[20:16:02 CEST] <BBB> indeed
[20:19:17 CEST] <kevmark> I'll post to the m/l regarding push access. Thanks BBB, JEEB
[20:19:18 CEST] <BBB> reimar is alive! \o/
[20:19:27 CEST] <BBB> kevmark: sgtm
[20:19:43 CEST] <BBB> kevmark: if you want quick patch push, poke me with a link to the ffmpeg-devel archives patch
[20:21:45 CEST] <kevmark> BBB, Doc change that has a LGTM https://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212271.html
[20:25:23 CEST] <kevmark> BBB, Michael requested a change to the previous patch and this is the updated one although hasn't been specifically given the ok on its own https://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212396.html
[20:26:10 CEST] <cone-329> ffmpeg 03Kevin Mark 07master:5aea18cbd882: doc/filters: Correct scale doc regarding w/h <= 0
[20:26:11 CEST] <kevmark> See previous messages in that thread for discussion.
[20:29:09 CEST] <cone-329> ffmpeg 03Kevin Mark 07master:05feeeb813e9: libavfilter/scale: Populate ow/oh when using 0 as w/h
[20:29:19 CEST] <BBB> done
[20:29:25 CEST] <kevmark> Thank you, I appreciate it
[20:29:34 CEST] <kevmark> I have two other patches outstanding and I believe both could stand to benefit from further review. Michael gave his thoughts on one but hasn't yet gotten back to me on my response to his concerns. The other has not received any discussion yet. I'll ping those two
[20:29:39 CEST] <BBB> anyone have issues with the h264 patches?
[20:29:53 CEST] <BBB> michaelni: re: h264, can I push them or did you want to wait until the fate tests are in?
[20:31:40 CEST] <michaelni> BBB, IIRC i meant they are good to push if tested which IIUC they were 
[20:31:49 CEST] <BBB> yes they were
[20:44:15 CEST] <cone-329> ffmpeg 03Anton Mitrofanov 07master:840b41b2a643: avcodec/h264_cabac: Fix CABAC+8x8dct in 4:4:4
[20:44:16 CEST] <cone-329> ffmpeg 03Anton Mitrofanov 07master:06dda70f1e7c: avcodec/h264_mb: Fix 8x8dct in lossless for new versions of x264
[20:44:17 CEST] <cone-329> ffmpeg 03Anton Mitrofanov 07master:cf231b68da11: avcodec/h264: Fix mix of lossless and lossy MBs decoding
[20:47:55 CEST] <durandal_1707> how are atmos stuff stored in eac3?
[20:56:03 CEST] <durandal_1707> or dts:x in dts?
[20:56:55 CEST] <nevcairiel> dts:x just has a specific startcode, afaik
[20:56:59 CEST] <nevcairiel> like the other dts extensions
[20:57:01 CEST] <atomnuker> what codec do they use, some new one?
[20:58:45 CEST] <rcombs> oh, is atmos in eac3 a thing
[20:58:49 CEST] <rcombs> I thought it was just in truehd
[21:32:53 CEST] <JEEB> oh, atomnuker or so mentioned it yesterday but yea - edison, joule and galileo are getting axed :D
[21:32:59 CEST] <JEEB> (the x86 boards)
[21:33:05 CEST] <JEEB> I am totally not surprised
[21:35:22 CEST] <Gramner> did anyone even use them aside from people getting them for free?
[21:40:18 CEST] <JEEB> Gramner: I actually bought an IoT kit for one of the edisons :D
[21:42:30 CEST] <Gramner> ah
[21:43:05 CEST] <JEEB> I only noticed the kernel patches /afterwards/
[21:43:30 CEST] <JEEB> at my previous job I looked into up-porting some of them from the jenkins-squashed publicly available patch
[21:43:42 CEST] <JEEB> put a ~week into it and gave up
[21:43:57 CEST] <Gramner> also x86 isn't really the first thing that comes to mind when you want some super-cheap low-power low-performance cpu for some purpose
[21:47:14 CEST] <iive> what was the name of that cpu that linus worked on... crusoe?
[21:47:42 CEST] <Gramner> from transmeta? yes
[21:48:11 CEST] <iive> i wish that thing could make a comeback... 
[21:48:32 CEST] <Gramner> the concept was interesting, yes
[21:48:35 CEST] <iive> a lot of people at the time wanted to be able to write native code for it directly
[21:49:12 CEST] <iive> it also did provide x86 cpu with ultra-low power consumption
[21:49:42 CEST] <iive> however at the time other stuff was also big power drain, like the laptop lid.
[21:49:58 CEST] <iive> (backlight)
[21:51:35 CEST] <atomnuker> he later complained he didn't like relying on smart compilers
[21:52:20 CEST] <iive> in what sense?
[22:02:34 CEST] <atomnuker> "So I've come to absolutely detest CPU's that need a lot of compiler smarts or special tuning to go fast. Life is too short to waste on in-order CPU's"
[22:02:39 CEST] <atomnuker> https://linux.slashdot.org/story/15/06/30/0058243/interviews-linus-torvalds-answers-your-question
[22:12:03 CEST] <TMM> atomnuker, that's a pretty interesting read overall
[22:40:09 CEST] <tmatth> atomnuker: makes me think of https://www.sudosatirical.com/articles/theres-eighty-seven-percent-chance-linus-torvalds-hates-your-code/
[22:40:37 CEST] <DHE> in fairness there's only a 13% chance your first submission is good
[22:42:41 CEST] <TMM> my first patch got applied! But it was adding 2 lines :P
[22:44:20 CEST] <atomnuker> my first patch was 1 char
[22:44:32 CEST] <nevcairiel> and still terrible?
[22:44:32 CEST] <nevcairiel> :D
[22:44:51 CEST] Action: J_Darnley goes to check his first patch
[22:44:51 CEST] <Gramner> probably too verbose
[22:45:04 CEST] <atomnuker> yet it quelled the angry voices of ds4 gamepad owners complaining the report rate was crap
[22:48:28 CEST] <TMM> I don't really remember what my first ever patch anywhere was
[22:48:40 CEST] <TMM> I think it was adding a feature to the chat of globulation 2
[22:49:10 CEST] <BBB> J_Darnley: if its helpful, Id go and commit the patches that were lgtmed, just to flush your queue a bit
[22:49:25 CEST] <BBB> J_Darnley: Ill look at the mov file from michaelni
[22:49:57 CEST] <TMM> so I got some fairly small suggestions on my patchset, should I post new versions with just those small things fixed, or wait for more reviews?
[22:51:41 CEST] <durandal_1707> just make sure no overreads happen
[22:52:12 CEST] <durandal_1707> and that it doesnt crash with malicious input
[22:53:46 CEST] <TMM> I use bytestream for everything, that means no overreads can happen, right?
[22:55:11 CEST] <durandal_1707> right. but it can still owervrite happen if you donot check it how and where you write
[22:55:46 CEST] <TMM> There's a check on the motion vectors being processed, I don't think it can write outside the frames
[22:56:16 CEST] <TMM> oh, I did make one fuckup, I increased the size of my ip packet header, but didn't increase the minimum size check
[22:56:25 CEST] <TMM> I should probably fix that :)
[23:18:30 CEST] <TMM> although that shouldn't be possible to happen at all, the demuxer creates the ip packet
[23:18:39 CEST] <TMM> and it always writes a full header
[23:18:54 CEST] <TMM> do I still have to check the full integrity of the ip packet in the codec?
[23:19:00 CEST] <durandal_1707> yes
[23:20:34 CEST] <TMM> ok
[23:22:25 CEST] <TMM> I should also check the total size of the packet then I suppose
[23:26:38 CEST] <TMM> the original code doesn't seem to care about the size of the packet, only that there's a minimum size for the decoding map
[23:26:44 CEST] <TMM> but if there's no pixel data you can still get an overread
[23:26:48 CEST] <TMM> I suppose that should be fixed
[23:28:55 CEST] <TMM> hmm it seems that in some cases the original code returns the size of the ip packet when there's a data problem, sometimes it returns AVERROR_INVALIDDATA
[23:29:08 CEST] <TMM> in what cases should it do what? I currently return AVERROR_INVALIDDATA in almost all cases
[23:29:17 CEST] <TMM> (in my new code)
[23:33:03 CEST] <atomnuker> decoders usually return the size of bytes read from the packet if they can still decode something but print errors
[23:33:13 CEST] <atomnuker> else AVERROR_INVALIDDATA
[23:33:45 CEST] <TMM> well, I could print that there's too little data in this frame and try to move to the next one
[23:33:58 CEST] <TMM> but for this format that will never actually result in a watchable stream
[23:34:07 CEST] <TMM> well, for 0x06 it may work actually
[23:34:16 CEST] <atomnuker> so return AVERROR_INVALIDDATA
[23:34:34 CEST] <TMM> but for 0x10 there's no iframes or anything, a missing frame will just result in the entire movie being garbage most likely
[23:34:44 CEST] <atomnuker> and if decoding is ok return the number of bytes read or the packet size
[23:35:09 CEST] <TMM> ok, I'll just return AVERROR_INVALIDDATA then
[23:35:20 CEST] <TMM> everywhere, also where the previous code returned the buffer size
[23:39:23 CEST] <atomnuker> no, that's when the decoder succeeds in decoding
[23:49:55 CEST] <TMM> oh yeah, of course, I mean whenever there's an error
[23:50:07 CEST] <TMM> not when decoding succeeded :)
[00:00:00 CEST] --- Tue Jun 20 2017