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

[burek]

[00:09:42 CET] <atomnuker> smarter_: are golomb codes used in HEVC (and if yes, why?)
[00:19:56 CET] <jkqxz> atomnuker:  Yes, in the headers.  Because doing full entropy coding of headers is a terrible idea (it saves pretty much nothing, and makes every operation which doesn't want to decode the whole bitstream hugely more annoying to do - compare VP8).
[00:20:24 CET] <atomnuker> no, its a great idea
[00:21:19 CET] <nevcairiel> doing entropy coding for headers would be insane on simple bitstream parsers and whatnot
[00:21:20 CET] <atomnuker> in both situations you have to read everything before since you don't know how long they are
[00:21:35 CET] <nevcairiel> its just a complexity we can do without
[00:21:40 CET] <atomnuker> so in both situations you init a bitstream reader and you read
[00:21:45 CET] <atomnuker> where's the problem?
[00:22:05 CET] <nevcairiel> the problem is that I know how to implement golomb and other simple vlc codes, but i have no clue how to do cabac =P
[00:22:29 CET] <atomnuker> easily solved, check the specs lol
[00:22:41 CET] <nevcairiel> what exactly would you gain?
[00:22:46 CET] <nevcairiel> other then some crazy sense of crazyness
[00:22:46 CET] <atomnuker> (which you have to do anyway because there are a million and one ways to encode golomb)
[00:23:05 CET] <atomnuker> uniformity, simplicity and encoding gains
[00:23:07 CET] <jkqxz> The entropy coding is useless unless you have some more information about what the frequencies are going to be, so you are going to have to add dependency on some previous headers in order to exploit the redundancy.  Suddenly you have no idea what a packet is without decoding all previous packets first.
[00:23:18 CET] <atomnuker> you still do
[00:23:33 CET] <atomnuker> opus does it
[00:23:54 CET] <atomnuker> flat probabilities on all flags in the header-like section
[00:24:46 CET] <nevcairiel> simplicity? by using cabac more?
[00:24:49 CET] <nevcairiel> please
[00:24:50 CET] <nevcairiel> :)
[00:24:54 CET] <atomnuker> no no no, you don't get it
[00:25:00 CET] <atomnuker> its _not_ adaptive
[00:25:16 CET] <atomnuker> cabac can be just bac
[00:25:22 CET] <atomnuker> no context adaptive stuff
[00:25:32 CET] <jkqxz> So it's just a slightly different packing method for the headers which saves a few bits at the cost of additional complexity?  Ok, I can live with that.
[00:25:43 CET] <atomnuker> yes, exactly
[00:25:54 CET] <nevcairiel> its video, headers are so small compared to the actual data that its not worth it
[00:26:02 CET] <atomnuker> and you don't waste bits padding when switching between cabac and bac
[00:26:03 CET] <jkqxz> Few bits is not enough to merit the complexity, yeah.
[00:26:33 CET] <atomnuker> it doesn't add complexity, its just as complex or even less complex than golomb
[00:26:48 CET] <nevcairiel> not every header field is g olomb
[00:26:54 CET] <nevcairiel> there is plenty fixed size bit fields
[00:27:03 CET] <atomnuker> they suck and shouldn't exist in packets
[00:28:16 CET] <atomnuker> I just didn't realize hevc had a design old enough not to do that
[00:28:17 CET] <jkqxz> The parameter sets are deliberately only fixed-width fields for the first few bytes so that very stupid devices can extract things like the profile information without even needing golomb decoding.
[00:28:45 CET] <atomnuker> daala, opus, av1, they all have a monolithic bistream you need a reader to read through
[00:28:58 CET] <jkqxz> In some sense, this is a huge waste.  In another, who cares about the few bits there.
[00:29:21 CET] <jkqxz> There are a lot of bits in the headers which you could infer or could be reduced by moving somewhere else, but it increases the complexity enough that it's not merited.
[00:29:23 CET] <atomnuker> depending on the framerate it can be very significant
[00:29:35 CET] <atomnuker> and bitrate
[00:29:45 CET] <nevcairiel> i question that statement
[00:29:49 CET] <nevcairiel> "very significant"
[00:29:56 CET] <nevcairiel> on what, 90s modem rates?
[00:29:58 CET] <atomnuker> opus with 2.5 ms packets at 40kbps
[00:30:11 CET] <TD-Linux> strictly speaking av1 has the uncompressed header too (bitpacked) but yes that's still better than two entropy coders
[00:30:12 CET] <nevcairiel> again, this is video
[00:30:12 CET] <atomnuker> most of that will be header data
[00:30:14 CET] <jkqxz> Sure, those people tho encode H.265 QCIF to send over an ISDN BRI.
[00:30:15 CET] <nevcairiel> it never gets that low
[00:30:51 CET] <nevcairiel> and in such a case maybe you should design a header-skipping feature or something
[00:30:51 CET] <atomnuker> TD-Linux: yes but its constant and it fits in X bytes exactly, not like you have to pad
[00:30:56 CET] <nevcairiel> group frames into GOPs with only one header
[00:31:10 CET] <TD-Linux> when videoconferencing, many frames are nearly all skip and the header does add up to a lot (especially the vp9 compressed header if present)
[00:31:46 CET] <jkqxz> Videoconferencing also has packet loss, which makes any sort of implicit data a disaster.
[00:32:23 CET] <nevcairiel> the all-skip frames are still tiny though
[00:32:35 CET] <nevcairiel> so even if a large precentage of them is header, its overall size is still low
[00:33:01 CET] <jkqxz> The packet overhead is more important at that point.
[00:33:45 CET] <jkqxz> You have to send one packet per frame, and that's already a hundred bytes or more of link-bandwidth used.
[00:33:51 CET] <atomnuker> still, why would you not want the entire packet to not be entropy coded? the outer layer usually carries enough shit to tell you everything
[00:33:54 CET] <atomnuker> e.g. RTP
[00:34:16 CET] <nevcairiel> or it tells you nothing, eg. mpegts
[00:34:42 CET] <TD-Linux> there are a few flags that you might want to be easily readable, like reference picture information, that could go into bitpacked
[00:34:51 CET] <TD-Linux> golomb is kinda the sad middle ground though
[00:35:35 CET] <atomnuker> yes, you have to pad to start an entropy coded bitstream, its usually more complex and slower to read and you still don't know where to start reading
[00:37:01 CET] <atomnuker> or you can avoid padding and instead convert the bits won into more complexity and swear words into your code, as well as hate for the person who designed it
[00:37:37 CET] <nevcairiel> but i dont want to have to swear when i write code
[00:37:48 CET] <nevcairiel> so i prefer easy headers!
[00:37:49 CET] <nevcairiel> :)
[00:38:32 CET] <atomnuker> there you go, you put an *aligned* constant byte header in with the most minimal of information and you entropy code the rest
[00:39:23 CET] <atomnuker> and then when someone wants to code additional parameters because their proprietary HDR needs them and they want that in the uncompressed header you unload on them instead
[00:39:23 CET] <nevcairiel> whats wrong with a few single bits of padding anyway, 1 to 7 bits arent going to hurt you in a large video stream
[00:39:38 CET] <atomnuker> no, that's okay, I was thinking something like 20 ood bytes
[00:39:58 CET] <nevcairiel> what kind of weird alignment does your weird entropy coder need
[00:40:22 CET] <nevcairiel> i have only seen byte-aligned borders in things
[00:40:33 CET] <atomnuker> that's what I'm talking about
[03:14:01 CET] <cone-670> ffmpeg 03Michael Niedermayer 07master:3250d4b39ccf: avformat/oggdec: remove unused parameter of ogg_restore()
[03:14:01 CET] <cone-670> ffmpeg 03Michael Niedermayer 07master:fb6fa48fce3a: avformat/oggdec: Factor free_stream out
[03:14:01 CET] <cone-670> ffmpeg 03Michael Niedermayer 07master:e46ab997506e: avformat/oggdec: fix leak in ogg_restore()
[03:29:09 CET] <cone-670> ffmpeg 03Michael Niedermayer 07master:04c99c8042c8: avcodec/h264idct_template: Fix several runtime error: signed integer overflow
[03:29:10 CET] <cone-670> ffmpeg 03Michael Niedermayer 07master:12c3e120fe8f: avcodec/ituh263dec: Use 0xffff as error code in h263p_decode_umotion()
[03:29:11 CET] <cone-670> ffmpeg 03Michael Niedermayer 07master:f8060ab927f8: avcodec/wavpack: Check value before shift in wp_exp2()
[03:29:12 CET] <cone-670> ffmpeg 03Michael Niedermayer 07master:4bed06637729: avcodec/vp56: Clear dimensions in case of failure in the middle of a resolution change
[03:49:30 CET] <svanheulen> :q
[09:23:30 CET] <wm4> mateo`: you wrote the lavc mediacodec code, right? does it have no support for GPU video frames?
[09:24:19 CET] <mateo`> if by GPU video format you mean output to a surface, it does support it
[09:24:30 CET] <wm4> I mean I only see this terrible releaseOutputBuffer thing, which an idiot must have designed
[09:24:34 CET] <wm4> https://developer.android.com/reference/android/media/MediaCodec.html#releaseOutputBuffer%28int,%20boolean%29
[09:24:47 CET] <wm4> this is pretty much directly exposed by lavc
[09:24:59 CET] <wm4> it appears once the surface is rendered, you can't do it again (????)
[09:25:14 CET] <mateo`> nope you can't ...
[09:25:26 CET] <wm4> also this whole thing is hilariously deadlock-prone, citing another part of the docs: " Specifically, it is possible that a codec may hold off on generating output buffers until all outstanding buffers have been released/resubmitted. "
[09:25:33 CET] <wm4> and this api is NEW?
[09:25:55 CET] <wm4> dxva2 was better a decade ago
[09:26:15 CET] <wbs> I guess it is deliberatly very abstract to make it work with wildly different socs
[09:26:21 CET] <mateo`> and yes, you need to release the output buffers as fast as possible
[09:26:35 CET] <wm4> wbs: so I guess we have to rely on windows phone and iOS to raise the standards
[09:26:48 CET] <wm4> while android is the lowest common denominator of stupid
[09:27:14 CET] <wbs> wm4: on iOS you can't get a gpu frame either iirc, but you can get the data in a gl compatible format
[09:28:02 CET] <wm4> wbs: well on iOS you have CVPixelBufferRefs, which works just like on OSX
[09:28:11 CET] <wm4> (with some unnecessary difference with GLES vs. GL)
[09:28:19 CET] <mateo`> wm4: and depending on the resolution / profile of the stream you decode, the decoder can lock if you retain 1 or 2 buffers ...
[09:28:31 CET] <wbs> wm4: yeah
[09:29:30 CET] <wm4> so while it's probably "ok" that it provides sub-par mechanisms for retarded SoCs, does it not provide better mechanisms for capable hardware?
[09:30:10 CET] <mateo`> wm4: in the application i work for, i render as fast as possible to a GL_TEXTURE_EXTERNAL_OES
[09:30:57 CET] <mateo`> and copy to a GL_TEXTURE_2D if I need to do more things with it
[09:31:44 CET] <wm4> I bet that involves forced RGB conversion too
[09:32:39 CET] <cone-920> ffmpeg 03Carl Eugen Hoyos 07master:3733039610d7: lavf/flacdec: Return maximum score if the streaminfo header is valid.
[09:33:09 CET] <mateo`> not to mention that you need a java listener implementation if you want to copy the surface to the GL_TEXTURE_EXTERNAL_OES, requiring your final app to ship the listener class, and your jni code to use it
[09:33:25 CET] <wm4> fucking terrible
[09:33:38 CET] <wm4> fuck google etc.
[09:33:41 CET] <mateo`> +1
[09:34:12 CET] <wm4> it gets even worse if you want to do transcoding
[09:35:03 CET] <JEEB> now guess why people added neon to x264. hue
[09:35:08 CET] <mateo`> the encoding part is pretty easy if you stay in the java world
[09:35:25 CET] <mateo`> but the quality the encoders output is horrible
[09:35:38 CET] <JEEB> yup
[09:35:48 CET] <wm4> apparently you can only setup decoder->encoder (no control over filtering or even what frames are encoded), unless you copy back to normal RAM
[09:36:35 CET] <mateo`> I have to bump the bitrate to 40mbps to have something ok-ish with complex video footage 
[09:37:17 CET] <mateo`> if you want to control i guess you will want to stay in the gl world
[09:37:30 CET] <mateo`> you get the output to a texture, you filter, you render back to the encoder surface
[09:40:32 CET] <mateo`> JEEB: if there is no licensing issue, i would be tempted to include x264 in the app ... at least the users would have something they can watch in the end
[09:56:28 CET] <wm4> michaelni: new filter-merge patches on the ML, I'll push in 24h
[09:56:39 CET] <wm4> michaelni: unless you approve earlier
[09:57:12 CET] <nevcairiel> did you fix all the things now?
[09:57:34 CET] <wm4> who knows
[09:58:06 CET] <wm4> it's all corner-caseish shit about which nobody knows whether it should or shouldn't work
[09:58:49 CET] <nevcairiel> at least using the input timebase seems to reduce the rounding error issues
[09:59:02 CET] <wm4> yes, some
[10:32:39 CET] <cone-920> ffmpeg 03wm4 07master:554bc4eea8aa: avcodec, avutil, avformat: remove AVOption requirement for some fields
[10:32:40 CET] <cone-920> ffmpeg 03wm4 07master:227f6e1e8d4b: avformat: fix AVStream private fields marker
[10:32:41 CET] <cone-920> ffmpeg 03wm4 07master:ade7c1a2326e: avcodec/videotoolbox: allow not setting the kCVPixelBufferPixelFormatTypeKey
[10:32:42 CET] <cone-920> ffmpeg 03wm4 07master:f07492e7fb66: avcodec/videotoolbox: set kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey
[11:16:27 CET] <wm4> jkqxz: which is your patch that fixes the vaapi frame pool assertion failures I like to hit so often? I'll push it
[11:18:18 CET] <jkqxz> wm4:  <https://git.libav.org/?p=libav.git;a=commit;h=d30719e62de68975cbc7ffd318df03a183037563>
[11:18:49 CET] <jkqxz> (Sorry, I should have done that when you last pointed it out.)
[11:21:09 CET] <cone-920> ffmpeg 03Mark Thompson 07master:2b8151c80690: hwcontext_vaapi: Don't abort on failing to allocate from a fixed-size pool
[11:21:13 CET] <wm4> thanks
[11:23:58 CET] <BtbN> I wonder what the hell VLC is doing on this laptop. It can't even play a 720p60 stream without over-using the CPU so badly that it lags the entire system.
[11:24:52 CET] <BtbN> MPC-HC plays the same stream with like 30% CPU usage. Which is still surprisingly high for something that should be handled by hwaccel.
[11:25:09 CET] <BtbN> And MS Edge plays it without any noticable CPU usage.
[11:25:15 CET] <wm4> and mpv?
[11:25:17 CET] <nevcairiel> did you turn hwaccel on then? :)
[11:25:26 CET] <BtbN> In VLC it's set to automatic
[11:25:33 CET] <BtbN> In MPC-HC it is using it
[11:25:45 CET] <wm4> with vlc I can never tell how to enable hwaccel, and even worse, how to tell whether it's using it
[11:26:02 CET] <BtbN> I guess I could look at a debug log to determine it
[11:26:08 CET] <BtbN> MPC-HC has a H/W indicator
[11:26:16 CET] <ubitux> last time i tried i could tell, it was all green
[11:26:26 CET] <BtbN> And I don't have mpv on Windows
[11:26:27 CET] <ubitux> (but that was long time ago)
[11:27:44 CET] <nevcairiel> h264 i guess?
[11:27:49 CET] <BtbN> yeah, a Twitch stream
[11:28:01 CET] <BtbN> so HLS with h264 and aac
[11:31:01 CET] <wm4> BtbN: can you download and try mpv? just curious what it'll say
[11:31:20 CET] <wm4> though I'd expect some kind of failure
[11:31:25 CET] <BtbN> I guess it supports DXVA/D3DVA?
[11:31:29 CET] <wm4> yes
[11:36:41 CET] <BtbN> wm4, any recommended build for Windows? There seem to be several people offering builds
[11:37:26 CET] <wm4> probably best to use https://mpv.srsfckn.biz/
[11:40:07 CET] <cone-920> ffmpeg 03Kostya Shishkov 07master:a63496cc8824: avcodec: add ClearVideo decoder
[11:42:37 CET] <BtbN> that one outperforms even edge
[11:42:45 CET] <BtbN> And I didn't specify any parameters except for the HLS url
[11:44:08 CET] <BtbN> No idea if it's using hwaccel, but with only 4% CPU usage I'd be surprised if not. This Laptop has a 2.2GHz dual core...
[14:24:40 CET] <wm4> michaelni: just as expected
[14:24:43 CET] <wm4> michaelni: fuck you too
[14:33:13 CET] <kierank> wm4: ?
[14:34:25 CET] <wm4> same shit again
[14:35:19 CET] <wm4> just when I post the patches, he comes up with the same undebuggable failures again (like the valgrind issue with "private" samples), makes me hunt down samples, comes up with bullshut corner cases
[14:35:41 CET] <wm4> nothing over the past 1 or 2 weeks where he had time to mention any failures to me
[14:36:09 CET] <durandal_170> but he likes to solely work on security patches
[14:36:26 CET] <wm4> then why does he care about filter changes
[14:39:30 CET] <BBB> michaelni: share the full sample collection and failure log please
[14:39:34 CET] <BBB> michaelni: this is ridiculous
[14:53:07 CET] <wm4> so the failure is because of sub2video, again
[15:06:25 CET] <BBB> wm4: btw, the fix michaelni uses for The first time you mentioned this. Why didn't you do so a week ago? When I complained that you come up with a new case punctually at exactly the time when I want to merge the patches. is to simply push the patch after amending the comments of the first review round
[15:06:35 CET] <BBB> wm4: you could do that too if you wanted to circumvent it
[15:09:21 CET] <wm4> BBB: so I should use underhanded methods of bullshit to work around our broken development model?
[15:09:41 CET] <wm4> doesn't sound too great to me
[15:10:34 CET] <BBB> Im not saying what you should or should not do, Im just mentioning existing accepted development methods
[15:11:05 CET] <BBB> (in line with your reasoning in doc: clarify development rules)
[15:11:37 CET] <BBB> it is up to you to decide what to do or not do
[15:14:51 CET] <Compn> some samples are available under nda only...
[15:19:11 CET] <Compn> you are upset that a patch review comes at an inopportune time for you. but instead you should be happy that someone took the time to test it out on a lot more samples.
[15:19:25 CET] <Compn> e.g. did you test your filter with all of samples.ffmpeg repo? 
[15:19:35 CET] <Compn> i am guessing not.
[15:20:34 CET] <Compn> you could ask if its a blocker, i doubt crashes without samples is a blocker
[15:20:40 CET] <durandal_170> Compn: keep calm
[15:20:48 CET] <Compn> wm4: but imo this is not something to be insulted by.
[15:21:16 CET] <Compn> durandal_170 : how'd you figure out clearvideo without the encoder ?
[15:21:43 CET] <Compn> durandal_1707 : how'd you figure out clearvideo without the encoder ?
[15:22:19 CET] <durandal_1707> dunno
[15:26:04 CET] <Compn> durandal_1707 : what should i use to generate pure white frame? do you have quick ffmpeg line for it? so when i finally get a windows 95 virtual machine running i can put it into vivo encoder...
[15:30:55 CET] <durandal_1707> Compn: ffmpeg -f lavfi -i color=white output
[15:31:50 CET] <wm4> Compn: I'm just going to tell you that I'll pretend I'm ignoring what you wrote
[15:33:10 CET] <Compn> wm4 : you've broken the code of conduct by saying "fuck you" to michael btw
[15:34:03 CET] <wm4> Compn: michaelni did too... the CoC says "Be considerate."
[15:34:36 CET] <Compn> i dont remember any malice in the patch review... was there some other mail or message you are talking about ?
[15:36:03 CET] <Compn> BBB , kierank : why are you encouraging this ?
[15:36:27 CET] <wm4> why are _you_ encouraging this
[15:36:45 CET] <BBB> Compn: I dont think Im encouraging anything out of the ordinary
[15:36:49 CET] <kierank> wm4: ignore compn
[15:36:58 CET] <BBB> Compn: Im indicating existing development practices
[15:37:15 CET] <BBB> Compn: I also agree that nda samples are great for testing but cannot be used to block patches, which even you seem to agree with
[15:37:25 CET] <durandal_1707> Compn: michaelni said similar by keeping samples of useless content
[15:37:29 CET] <Compn> im not talking about the patch, only wm4's reactions...
[15:37:37 CET] <BBB> Compn: if google or who-ever supplied the sample thinks the sample is important for regression testing, then the sample should be made publicly accessible for all developers
[15:38:16 CET] <durandal_1707> Compn: i would react exactly same as wm4 did
[15:38:19 CET] <Compn> BBB : what about wm4's violation of the CoC ?
[15:38:23 CET] <BBB> Compn: as for wm4s reaction, I totally understand that if youve spent weeks on a particular tedious feature that you would really like to get into the main tree, it sucks if its repeatedly kicked down the lane
[15:38:36 CET] <Compn> thats not a reason to break the coc.
[15:38:38 CET] <BBB> Compn: I agree that fuck you isnt appropriate
[15:38:43 CET] <Compn> thank you
[15:38:46 CET] <wm4> Compn: your CoC argument is bullshit that only detracts from the real issue (which on the other hand you seem not to understand)
[15:38:55 CET] <BBB> wm4: please dont say fuck you, although I understand your frustration
[15:39:14 CET] <Compn> dont blame me, i voted against CoC ...
[15:39:30 CET] <wm4> it's not a substantial "insult", especially because I said "fuck you too" not "fuck you"
[15:39:42 CET] <wm4> (why are we arguing about this... I guess the CoC works)
[15:39:46 CET] <BBB> :)
[15:39:56 CET] <BBB> soooo lets get back on-topic
[15:40:33 CET] <Compn> "thank you for patch review, i cant fix the bugs without samples, so i'
[15:40:45 CET] <Compn> "thank you for patch review, i cant fix the bugs without samples, so i'd like to push this now and fix later when samples appear, ok?"
[15:40:56 CET] <Compn> fair enough ? 
[15:41:01 CET] <Compn> im just trying to help
[15:41:21 CET] <Compn> its easy to type that sentence in a mail (or just copy and paste)
[15:43:51 CET] <BBB> Compn: I think your question why are you encouraging this was directed at me not immediately telling him to not say fuck you (too), right? I think the honest answer is that Im sort of just ignoring those type of comments and instead I just focus on the substance of the issue& whether thats a good thing or not remains to be determined ..
[15:44:33 CET] <Compn> BBB : encouraging some devels to be angry at other devels for a patch review is not helping anything or anyone
[15:44:52 CET] <BBB> I agree
[15:45:36 CET] <BBB> but Im pretty sure that if we go past form into substance, we all more-or-less agree on the technical issues at hand here, right?
[15:45:53 CET] <BBB> even you appear to generally agree that non-public samples cannot be used to block a patch
[15:46:15 CET] <BBB> (maybe minus security/crashes, etc., maybe with nice wording, etc. modulo div)
[15:46:38 CET] <Compn> i guess i cant remember the other thing i thought you were encouraging so i'll drop it
[15:46:48 CET] <Compn> sorry.
[15:46:56 CET] <BBB> I suggested he push the patch after addressing the concerns, maybe that?
[15:47:04 CET] <Compn> yes, kinda
[15:47:18 CET] <Compn> thats maybe not the 100% best suggestion
[15:47:38 CET] <BBB> its not great, but some people already do it, so if he wants to get the patch off his back, he could consider it
[15:47:47 CET] <BBB> I probably wouldnt want to exactly encourage it
[15:47:57 CET] <BBB> but I wouldnt be fundamentally opposed to it either
[15:48:12 CET] <Compn> like i said, i agree with you BBB
[15:48:15 CET] <BBB> maybe I wouldve considered it for the msvc patch
[15:48:26 CET] <BBB> speaking of shitty patches I totally wanted to get off my hard disk ;)
[15:48:34 CET] <Compn> posting one sentence asking if michaels' crashes are a blocker , otherwise push is fine too...
[15:48:39 CET] <Compn> :)
[15:48:53 CET] <BBB> I guess we agree mostly on substance then, so good :)
[15:48:57 CET] <ismail> Compn: btw. can you copy the sample from https://trac.ffmpeg.org/ticket/5998#comment:13 ?
[15:49:01 CET] <Compn> just trying to encourage people to communicate and not be insultee
[15:49:02 CET] <Compn> d
[15:49:09 CET] <BBB> yeah
[15:49:23 CET] <Compn> theres no reason to be insulted 
[15:49:39 CET] <Compn> you may feel insutled , personally, but i dont think michaelni meant to 
[15:49:45 CET] <Compn> i'm not sure if there is a word for this
[15:49:48 CET] <Compn> intent maybe
[15:49:51 CET] <Compn> no malice intended
[15:50:35 CET] <Compn> ismail : downloading
[15:50:44 CET] <ismail> Compn: thanks!
[15:52:26 CET] <Compn> hmm i forgot where they go on ffmpeg box
[15:52:35 CET] <ismail> bah :)
[15:52:38 CET] <Compn> where in samples is trac files ?
[15:52:49 CET] <Compn> samples.ffmpeg.org/???/profit
[15:53:22 CET] <Compn> ah i was in the right spot
[15:54:24 CET] <Compn> ismail : should be here in  30 mins http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket5998/
[15:54:29 CET] Action: Compn afk
[15:55:49 CET] <ismail> nice, thanks.
[16:02:03 CET] <jamrial> michaelni: why is the ffv1 encoder even creating v2 streams if the draft spec specifically mentions such files shouldn't exist and doesn't cover them at all beyond that?
[16:04:06 CET] <Compn> ismail : i forgot, can you post to that bug saying the sample is moved?
[16:04:17 CET] <Compn> if you have trac account, otherwise i'll do it later
[16:04:20 CET] <Compn> if someone reminds me
[17:21:53 CET] <michaelni> jamrial, it shouldnt create them by default or without user explicitly overriding. being able to force their creation makes sense to test the decoder so any files out there continue to be supported in the future
[17:22:12 CET] <michaelni> there may be other reasons that i fail to see as well
[17:37:52 CET] <jamrial> michaelni: alright. just wondering since the spec is very clear about them not being valid files at all
[17:41:13 CET] <michaelni> yes for IETF RFC, its simpler to keep a historic corner case that would complicate the spec and shouldnt exist in the wild out of the doc
[17:52:33 CET] <svanheulen> I have a streaming video format with no timeing/framerate info. Each video frame is meant to be displayed immediately as it's received. I want to make a protocol/demuxer/decoder for it, any advice on how to handle something like that?
[17:53:12 CET] <BtbN> that's not how audio/video works
[17:53:36 CET] <BtbN> pretty sure ffmpeg will do horrible things without somewhat sensible timestamps
[17:54:27 CET] <svanheulen> yeah, it's a pretty annoying format :/
[17:55:14 CET] <svanheulen> I was thinking maybe I could insert timestamps as I receive packets in the protocol... ?
[17:56:35 CET] <jkqxz> I think some of the device things work like that.  If you set a suitably fine time_base and then set pts on packets to the current time as they arrive then it basically works.
[18:07:51 CET] <cone-920> ffmpeg 03Carl Eugen Hoyos 07master:d1bfd19ad196: doc: Link to "Resampler Options" in the aresample documentation.
[18:13:33 CET] <cone-920> ffmpeg 03Carl Eugen Hoyos 07master:46082c2b3f21: lavc/sheervideo: Fix Y prediction for interlaced frames with transparency.
[18:27:46 CET] <wm4> man I spent way too much time of my life to write this shitty email
[18:35:39 CET] <atana> michaelni, ping
[18:36:34 CET] <atana> michaelni, I tried running the script. it says "peakpoints_check.sh: 64: peakpoints_check.sh: Syntax error: Bad fd number" 
[18:37:26 CET] <atana> also in the log 'peakpoints2.log.insert' while printing fingerprint it report MatchInfo Array not allocated
[18:37:39 CET] <atana> *reallocated
[18:39:21 CET] <michaelni> atana, did you adjust the directory names ? the ones on the disc must match the script and should not contain any odd things like ()
[18:42:06 CET] <atana> when I extracted the dataset I got two directories 'genres' and 'mir*' I change 'mir*' to 'mir-10secsnippets' and set DIR=path-to-parent directory of genres
[18:48:18 CET] <michaelni> atana, what exactly in the script fails ? 
[18:48:34 CET] <michaelni> line 64 is "lookupmultiple mir-10secsnippets/classical.     1 10"
[18:48:43 CET] <michaelni> line 63 is "lookupmultiple mir-10secsnippets/blues.        10 10"
[18:48:54 CET] <michaelni> why does 63 work but 64 not ?
[18:49:17 CET] <atana> Don't know it just says 'bad fd number'
[18:50:45 CET] <michaelni> atana, what does it say with "bash -x peakpoints_check.sh" ?
[18:52:15 CET] <atana> seems to work now. I used sh instead of bash 
[18:52:51 CET] <michaelni> ok but the sccript says "#!/bin/bash" at its top
[18:57:40 CET] <atana> 57 failures
[18:58:11 CET] <michaelni> atana, great so we have a way to test it now
[18:59:12 CET] <atana> also 'MatchInfo array not reallocated' in the insert log
[18:59:42 CET] <adeeln_> durandal_1707: I've cleared the master branch, but now git log gives "fatal: bad default revision 'HEAD'"
[18:59:54 CET] <atana> It should happen when enough memory is not present 
[19:00:16 CET] <michaelni> atana,  the found=1 code checks for (count == 7) i dont think that makes sense, does it have fewer failures without that ?
[19:00:19 CET] <durandal_1707> adeeln_: what says git reflog?
[19:00:54 CET] <adeeln_> durandal_1707: same "fatal: bad default revision 'HEAD'"
[19:01:19 CET] <durandal_1707> adeeln_: congrats on breaking git
[19:01:49 CET] <adeeln_> :" what do I do? I created a backup btw
[19:03:22 CET] <michaelni> atana, you check mi_size before its increased i think
[19:04:46 CET] <atana> oh yes, that should be commented out
[19:07:46 CET] <durandal_1707> adeeln_: try get ffmpeg compiling and running and git log working
[19:14:12 CET] <atana> michaelni, what does variable songidpart and count refers to?
[19:16:23 CET] <atana> oh that's id and count is total sample to consider(10 from each)
[19:16:51 CET] <michaelni> yes, i used 10 as it would likely get a bit slow with more
[19:18:09 CET] <atana> michaelni,  the found=1 code checks for (count == 7) ....  I didn't understand this
[19:18:34 CET] <atana> is it in the script you are referring to?
[19:18:57 CET] <wm4> michaelni: crash fixed, pushed a rebased patchset to my github filter-merge branch (latest commit is the fix for your sample)
[19:19:50 CET] <atana> ok it's the peakpoint2 filter I will make it less and check the results
[19:20:10 CET] <wm4> michaelni: feel free to test it until tomorrow, I'll then take a look, but I'll push it at 9 AM CET
[19:21:46 CET] <Compn> wm4 : you know that michaelni said he would not be project leader ,not that he was leaving the project, right ?
[19:22:05 CET] <Compn> although a lot of people took the email to mean the latter.
[19:22:49 CET] <Compn> and it was even reported as such in some disreputable news sites
[19:27:48 CET] <atana> michaelni, with count==4 -> 17 failures however it also print "peakpoints_check.sh: line 29: [: too many arguments" I used `bash peakpoints_check.sh | grep -c "/home*"` to get count
[19:29:12 CET] <wm4> Compn: no I didn't
[19:29:31 CET] <wm4> Compn: I guess not knowing The Truth makes those news sites "disreputable"
[19:29:36 CET] <wm4> and myself too
[19:30:33 CET] <michaelni> atana, i suggest to remove  count==4 thats the loop counter if iam not mistaken
[19:31:10 CET] <michaelni> match_count alone should be enogh
[19:31:33 CET] <atana> with count==3 0 failures
[19:33:12 CET] <michaelni> atana, does the sccript finish in this case? or does it fail with an error?
[19:33:21 CET] <atana> michaelni, count==7 was checking if all 8 freq matched then it should go for matching time diff
[19:34:43 CET] <atana> that's matching all 8 freq in a entry and then try to match timediff
[19:36:36 CET] <atana> michaelni, script finishes in that case
[19:36:41 CET] <adeeln_> durandal_1707: I've cloned a new repository, git log is working now. Can the old compile be used?
[19:37:07 CET] <Compn> wm4 : i  didnt mean to imply it like that
[19:37:15 CET] <Compn> but some people heard about it from those sites which were wrong
[19:38:28 CET] <michaelni> atana,  can you push your version to github ?
[19:38:58 CET] <durandal_1707> adeeln_: ? just use old patch, you cannot use old compile
[19:39:07 CET] <atana> michaelni, with count==3?
[19:39:18 CET] <durandal_1707> adeeln_: please develop in separate branch
[19:40:06 CET] <adeeln_> durandal_1707: okay, I will go through the process as before, in a new branch this time.
[19:40:13 CET] <michaelni> atana, the version that works with 0 failures
[19:40:21 CET] <atana> yes pushed
[19:40:30 CET] <atana> that's the one with count==3
[19:41:19 CET] <atana> which means it only checks 3 frequency matches in a entry and then if all timediff matches then a 'match found'
[19:42:31 CET] <michaelni> atana, doesnt work i just get "./peakpoints_check.sh: line 29: [: too many arguments"
[19:43:00 CET] <atana> also prints OK
[19:43:26 CET] <atana> what does `bash peakpoints_check.sh | grep -c "/home*"` gives
[19:44:23 CET] <michaelni> atana, the script is buggy
[19:44:56 CET] <michaelni> atana, replace 'if [ $found != $expected ] ; then' by 'if [ "$found" != "$expected" ] ; then'
[19:45:18 CET] <michaelni> that was my mistake
[19:52:48 CET] <JEEB> hmm
[19:53:06 CET] <JEEB> so the libvpx decoder has to be enabled for libvpx to be usable?
[19:53:35 CET] <JEEB> I just happened to build libvpx without any decoders
[20:06:28 CET] <jamrial> JEEB: try --enable-libvpx --disable-decoder=libvpx_vp8,libvpx_vp9
[20:08:15 CET] <atana> michaelni, why is it printing /home/atana/music/mir-10secsnippets/rock.00000-snippet-10-0.wav 900 [Parsed_peakpoints2_0 @ 0x41f2f00] Matched Song ID is -1 line?
[20:08:43 CET] <JEEB> jamrial: trying
[20:08:54 CET] <atana> isn't the script supposed to capture integer part from the line "Match Song..."
[20:08:55 CET] <atana> ?
[20:11:47 CET] <atana> also for count==7 `bash peakpoints_check.sh|grep -c "OK"` says 103 matches 
[20:12:36 CET] <michaelni> atana,  i guess with count==3 it fails more fatally
[20:12:39 CET] <JEEB> jamrial: lol I passed with also disabling the vp8 encoder, but then the result is "libvpx enabled but no supported decoders found" :DDD
[20:13:08 CET] <michaelni> atana, what if you remove count==7 and remove the break; after "// this hash no a match, try next hash"
[20:13:23 CET] <jamrial> that means the vp9 encoder was also disabled
[20:14:01 CET] <atana> michaelni, is the current script ok ? as it gives 103 occurrence of "OK" max could be 100
[20:14:45 CET] <JEEB> jamrial: ok, feels like my pkg-config file is borked or something
[20:14:45 CET] <michaelni> atana, there are 100 input files but more short recordings i guess that are looked uo
[20:14:47 CET] <michaelni> uP
[20:14:55 CET] <JEEB> <vpx/vpx_encoder.h> not found
[20:14:57 CET] <jamrial> JEEB: check config.log, look for libvpx_vp9_encoder, see what it says about the checks
[20:15:40 CET] <jamrial> that's not pkg-config then, but your libvpx build not installing that header
[20:16:35 CET] <atana> michaelni,  and printing the [Parsed_. ...] is it suppose to happen? which means found values is that whole string not integer
[20:19:43 CET] <michaelni> atana, i guess that you refer to the case where the lookup fails to find anything
[20:25:30 CET] <atana> 9 failures when removing count and commenting break
[20:25:38 CET] <atana> michaelni, ^
[20:32:44 CET] <michaelni> atana, excellent
[20:39:25 CET] <michaelni> atana, next try to adjust the value below // discard entries with less than 3 peak points
[20:39:42 CET] <atana> ok
[20:58:53 CET] <atana> michaelni,  n>2 -> 8 failures, n > 3 -> 9 failure, n > 4 -> 14 failures, n > 5 -> 45 failures
[20:59:39 CET] <michaelni> atana, n>2 is best then
[21:00:09 CET] <atana> commenting it also gives 8 failures
[21:00:58 CET] <atana> I will make it n > 2 then
[21:01:07 CET] <michaelni> ok
[21:02:03 CET] <atana> pushed
[21:03:24 CET] <michaelni> atana, next thing to try is to apply a window function before the FFT like a Hamming window, this should be more correct and i hope improves the matches but has to be tested to see if it really improves things
[21:05:12 CET] <michaelni> atana, see ff_generate_window_func()
[21:05:25 CET] <atana> ok
[21:45:33 CET] <BBB> what does this mean in yasm?
[21:45:35 CET] <BBB> Undefined symbols for architecture x86_64:
[21:45:36 CET] <BBB>   "", referenced from:
[21:45:51 CET] <BBB>       .. at 11820.branch_instr in filename.o
[21:55:30 CET] <jamrial> BBB: never seen that before. did you make some changes to the x86inc magic, or try to abuse it in some weird way?
[21:55:45 CET] <BBB> I found it by binary search %if 0 around code
[21:55:56 CET] <BBB> I used [rsp*0*mmsize] instead of [rsp+0*mmsize] somewhere
[21:56:13 CET] <BBB> apparently that becomes []
[21:56:20 CET] <BBB> (which is kinda duh, and kinda illogical)
[21:56:28 CET] <BBB> but that causes the linking error
[22:08:11 CET] <unholy_me> hello!
[22:08:26 CET] <kierank> hello
[22:08:44 CET] <unholy_me> XPM decoder implemented in libavcodec: This has to be implemented in:https://github.com/FFmpeg/FFmpeg/tree/master/libavcodec?
[22:10:00 CET] <unholy_me> Any pointers on how to start?
[22:11:36 CET] Action: unholy_me : New to ffmpeg
[22:11:44 CET] <Compn> theres a demuxer/decoder example, i think xpm spec somewhere too, and xpm samples
[22:12:03 CET] <Compn> what programming experience do you have, unholy_me ?
[22:12:19 CET] <unholy_me> I am good in c
[22:12:37 CET] <unholy_me> Coded quite a lot
[22:13:21 CET] <Compn> i think there might be some other people also working on xpm . just letting you know, you may have competition for the same thing 
[22:13:25 CET] <Compn> or they might have dropped out
[22:13:35 CET] <Compn> hard to tell, people dont communicate well these days
[22:14:13 CET] <unholy_me> any suggestion which project to start on?
[22:15:11 CET] <Compn> i am not sure :)
[22:15:17 CET] <Compn> maybe ask durandal_1707 or michaelni
[22:15:37 CET] <unholy_me> Cool! Thanks BTW
[22:15:43 CET] <unholy_me> You a mentor?
[22:16:22 CET] <durandal_1707> unholy_me: see other codecs and commits that add new decoders as example
[22:16:53 CET] <JEEB> I think libav had a wiki article on adding a new decoder, not sure if FFmpeg has one
[22:17:17 CET] <Compn> i am not
[22:17:26 CET] <Compn> we had a demuxer howto
[22:17:32 CET] <Compn> i am not seeing decoder howto
[22:18:00 CET] <Compn> https://wiki.multimedia.cx/index.php/FFmpeg_codec_HOWTO
[22:18:10 CET] <Compn> but probably using wrong / old api hehe
[22:18:25 CET] <JEEB> that does look familiar
[22:18:41 CET] <JEEB> but yeah, looking at some of the newer avcodec decoders should be helpful
[22:21:26 CET] <unholy_me> @durandal_1707 any good,basic ones?
[22:23:17 CET] <Compn> you mean a good basic decoder to look to as an example ?
[22:23:44 CET] <durandal_1707> unholy_me: search fo xbm decoder in logs, xpm is going to be similar
[22:25:50 CET] <unholy_me> XBM decoder? okay :)
[23:05:20 CET] <unholy_me> i am up for the ambisonic project
[23:06:00 CET] <unholy_me> Pointers on where to start?
[23:07:48 CET] <durandal_170> unholy_me: write filter as in project wiki
[23:08:17 CET] <durandal_170> just to do simple square decoder
[23:08:48 CET] <unholy_me> can you give me the link?
[23:09:03 CET] <durandal_170> look how are other filters are done
[23:09:22 CET] <durandal_170> unholy_me: link to what?
[23:10:08 CET] <unholy_me> where the other filters are done
[23:10:28 CET] <durandal_170> it is in ffmpeg repo
[23:10:49 CET] <durandal_170> have you done git clone?
[23:10:55 CET] <unholy_me> yes
[23:11:03 CET] <unholy_me> i have cloned it
[23:11:36 CET] <durandal_170> see libavfilter/af_pan.c
[23:11:45 CET] <unholy_me> yup i am on that
[23:12:57 CET] <durandal_170> unholy_me: for square it would need 4 channels ambisonic input
[23:13:24 CET] <durandal_170> and give 4 channels in output
[23:13:52 CET] <unholy_me> ohkay...
[23:14:12 CET] <durandal_170> read ambisonics info on wikipedia
[23:15:57 CET] <unholy_me> why exactly would it require 4 channels?
[23:16:34 CET] <durandal_170> unholy_me: ambisonics are usually 4 channels
[23:17:40 CET] <durandal_170> there is ambisonic info and additional links on wikipedia
[23:24:52 CET] <unholy_me> so w,x,y,z are the 4 channels?
[23:25:03 CET] <durandal_170> yes
[23:26:56 CET] <unholy_me> okay, so what exactly is FFmpeg/libavfilter/af_pan.c doing?
[23:27:16 CET] <unholy_me> last part is the struct, which is initializing variables
[23:27:24 CET] <unholy_me> i got that
[23:28:12 CET] <durandal_170> panning
[23:28:30 CET] <durandal_170> see doc/filters.texi
[23:30:05 CET] <unholy_me> okay
[23:37:59 CET] <unholy_me> okay i read filters.texi a little bit
[23:38:29 CET] <unholy_me> understood about how signal is splitting
[23:43:55 CET] <unholy_me> went through the code for af_pan
[23:44:49 CET] <unholy_me> what is the function cofig props doing?
[23:46:15 CET] <durandal_170> its setting input and output channel layouts and samplerate and sampleformat
[23:50:12 CET] <unholy_me> let me see if i get this right
[23:51:03 CET] <unholy_me> parse channel name is just removing spaces and then *gets channel layout*?
[23:52:32 CET] <unholy_me> okay
[23:52:43 CET] <unholy_me> what is init() doing
[23:52:44 CET] <unholy_me> ?
[23:53:21 CET] <unholy_me> I think it just rejects wrongly named channels
[23:53:24 CET] <unholy_me> am i right?
[00:00:00 CET] --- Fri Mar  3 2017