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

[burek]

[00:01:06 CEST] <Compn> anyways, good email, jamrial :)
[00:01:49 CEST] <Compn> nevcairiel : the wild west of software. if its not broke dont fix it. if it is broken, make a new one.
[00:05:20 CEST] <cone-250> ffmpeg 03wm4 07master:8a60bba0aef7: avcodec: clarify some decoding/encoding API details
[00:05:22 CEST] <cone-250> ffmpeg 03James Almer 07master:a41a5733d1a4: Merge commit '8a60bba0aef77015111570058d5a72f0428dc748'
[00:07:27 CEST] <durandal_1707> Compn: on what are you working on?
[00:07:36 CEST] <jamrial> BtbN: what do you think of libav commit f6790b5e10?
[00:08:14 CEST] <jamrial> mmh, wait, looks like we already have it
[00:08:22 CEST] <Compn> durandal_1707 : investing in stock market :)
[00:08:35 CEST] <Compn> so i can retire before i hit 35 :P
[00:08:37 CEST] <BtbN> jamrial, I'm pretty sure they merged that from us?
[00:08:46 CEST] <BtbN> But I'd need to check
[00:08:49 CEST] <jamrial> yeah, but it's a bit different
[00:09:13 CEST] <durandal_1707> Compn: what exactly?
[00:09:33 CEST] <Compn> durandal_1707 : research on stocks and when to buy/sell 
[00:09:47 CEST] <BtbN> jamrial, 5f44a4a0a97e802479e6ce689d719e5277267f22 is the ffmpeg commit.
[00:09:59 CEST] <BtbN> They pretty much merged the logic after that commit
[00:10:04 CEST] <jkqxz> Does anything use lavf to mux H.265 to MPEG-TS?
[00:10:13 CEST] <durandal_1707> Compn: but you are old, over 50
[00:10:23 CEST] <jamrial> BtbN: ok, will noop it then
[00:10:27 CEST] <Compn> durandal_1707 : ?? i'm under 35 :)
[00:10:43 CEST] <Compn> durandal_1707 : maybe you confuse me with someone else :)
[00:11:14 CEST] <BtbN> jamrial, their logic seems to be very slightly different, but it looks just like style-changes to me
[00:11:38 CEST] <durandal_1707> Compn: hmm, maybe i shifted into different universe
[00:12:42 CEST] <Compn> my long beard makes me look like an ancient wizard , yes
[00:14:01 CEST] <cone-250> ffmpeg 03Konda Raju 07master:f6790b5e1075: add initial QP value options
[00:14:02 CEST] <cone-250> ffmpeg 03James Almer 07master:8f2cc2f1e9ef: Merge commit 'f6790b5e1075133ee39be91105f1135db7afd259'
[00:23:28 CEST] <nevcairiel> libav commit messages seem to go down in quality as well? =p
[00:26:33 CEST] <jamrial> CineformHD decoder commit. it's so heavily refactored the diff is as big as the c file...
[00:27:06 CEST] <nevcairiel> better skip it or kierank is going to murder you
[00:27:20 CEST] <kierank> if you want all samples to break, yeah merge it
[00:27:42 CEST] <jamrial> kierank: so you say i should noop it?
[00:28:07 CEST] <kierank> the refactoring isn't too bad but they of course changed a lot of stuff too
[00:28:11 CEST] <kierank> and broke tons of samples
[00:28:55 CEST] <jamrial> guess i'll merge things like this enum replacing magic numbers, function names and whitespace stuff, then
[00:57:05 CEST] <Emerica> kierank Murder? nah.....
[01:32:08 CEST] <rcombs> stabbing?
[01:47:23 CEST] <cone-250> ffmpeg 03Kieran Kunhya 07master:5f794aa1653a: Add Cineform HD Decoder
[01:47:24 CEST] <cone-250> ffmpeg 03James Almer 07master:6007f7d4665e: Merge commit '5f794aa1653aa04c1da7397e9ccacad947fadf5f'
[01:48:24 CEST] <jamrial> kierank: merged only some cosmetics, but maybe check your samples to be sure they still work
[01:48:53 CEST] <kierank> iirc the definitely hardcoded some values
[01:48:54 CEST] <kierank> they
[01:49:39 CEST] <jamrial> i skipped the whole refactoring of the main decode function, since finding what they broke there would be too much work
[01:50:24 CEST] <kierank> they have hardcoded a coded_format, not sure ffmpeg did that before
[01:51:13 CEST] <jamrial> no, i think not
[01:51:25 CEST] <kierank> oh it did
[01:56:20 CEST] <jamrial> kierank: next commit is a bunch of fate tests. three samples
[01:56:33 CEST] <kierank> iirc some of those samples are not even supported
[01:56:42 CEST] <jamrial> all three decode here
[01:56:45 CEST] <jamrial> with ffplay
[01:56:49 CEST] <kierank> ok they changed it then
[01:56:57 CEST] <kierank> but there was definitely one they pushed that never actually worked
[01:56:59 CEST] <kierank> (lol)
[01:57:05 CEST] <jamrial> two are yuv422p10le, one is gbrp12le
[01:59:08 CEST] <jamrial> michaelni: can you upload the cfhd folder from libav's fate suite to ours?
[01:59:57 CEST] <jamrial> kierank: the one called cfhd_odd.mov might not be working 100%, to be honest
[02:00:13 CEST] <jamrial> seems to be a screen capture of a web browser
[02:00:31 CEST] <jamrial> but the last row of pixels is blurry
[02:01:33 CEST] <kierank> some  cropping thing iirc
[02:02:38 CEST] <jamrial> yeah, they do seem to have some cropping code i skipped
[02:02:54 CEST] <jamrial> you may want to look at it :p
[02:20:41 CEST] <jamrial> kierank: https://pastebin.com/9CwN1Bi8 that's a rough "port" of the cropping code in libav's version
[02:21:00 CEST] <kierank> looks good
[02:46:06 CEST] <michaelni> jamrial, uploaded
[02:46:17 CEST] <jamrial> michaelni: thank you
[02:49:51 CEST] <cone-250> ffmpeg 03Gyan Doshi 07master:df45ea45df18: doc/filters: add note on flite thread safety and update URL
[15:18:48 CEST] <durandal_1707> michaelni: are you happy now? you caused another ffmpeg fork
[15:22:28 CEST] <Compn> remember durandal_1707 , we do not all share this sense of jokery. the stresses on some developers are more than other devs and poking people in the eye like this isnt warranted
[15:29:26 CEST] <jamrial> JEEB: you should have reminded me you didn't have push rights
[15:29:40 CEST] <JEEB> I am just not sure what the procedure is
[15:29:54 CEST] <JEEB> I have the pubkey I could give out
[15:31:01 CEST] <jamrial> JEEB: you show up in the "has git access" list in maintainers...
[15:31:10 CEST] <jamrial> did you send you pubkey to michaelni?
[15:31:23 CEST] <JEEB> yea, that's the part which I was unsure of
[15:31:36 CEST] <JEEB> so the workflow is to send michaelni the key?
[15:32:12 CEST] <jamrial> yes, send him the key, then add the push url to your local git repo
[15:33:11 CEST] <JEEB> well, that part is the obvious part :)
[15:37:08 CEST] <atomnuker> durandal_1707: its wm4s fault for failing to understand how development works
[15:39:50 CEST] <JEEB> alright, got that part rolling
[15:43:18 CEST] <durandal_1707> Compn: are you saying that michaelni is most valuable ffmpeg dev?
[15:43:32 CEST] <Compn> no
[15:43:49 CEST] <Compn> i am saying that singling out developers is not good policy , and goes against the COC
[15:44:08 CEST] <jamrial> stop trolling, durandal_1707
[15:44:44 CEST] <Compn> wm4 and michaelni could make some kind of compromise. ideally a 3rd party comes in to fix the issues stated
[15:45:06 CEST] <durandal_1707> jamrial: now you are offending me
[15:45:23 CEST] <jamrial> i've been calling for third parties on this issue for a while. two showed up but nothing came out of it
[15:45:48 CEST] <jamrial> wm4 should send a new thread with a more eye catching subject to get the attention of more people
[15:46:42 CEST] <jamrial> "merge cuvid stuff" is not an eye catching subject for it, especially when the issue is about AVFrame usage
[15:46:47 CEST] <Compn> we should bribe thilo 
[15:46:50 CEST] <jamrial> plenty of people ignored it
[15:51:10 CEST] <BBB> new fork?
[15:51:11 CEST] <Compn> atomnuker : i'm more curious on why someone would send a patch and ignore the review
[15:52:04 CEST] <Compn> and then threaten to commit anyways
[15:52:09 CEST] <Compn> why not just commit in the first place ...
[15:52:28 CEST] <Compn> unimportant i guess
[15:52:43 CEST] <BBB> five years ago that was the modus operandi, remember? :D
[15:53:01 CEST] <BBB> oh, how things have improved & & ? ...
[15:53:06 CEST] <BBB> yikes
[15:53:14 CEST] <atomnuker> BBB: wm4 is threatening to have an mpv-ffmpeg
[15:53:45 CEST] <BBB> is this the avframe opaque_ref thing?
[15:53:49 CEST] <atomnuker> yep
[15:53:56 CEST] <Compn> maybe BBB can massage said patch
[15:53:57 CEST] <Compn> :P
[15:53:58 CEST] <BBB> Ive ignored it, I hate the discussion as its happening there
[15:54:18 CEST] <BBB> michaelni: youre acting like a child (and so is wm4)
[15:54:26 CEST] <BBB> in that discussion
[15:54:30 CEST] <BBB> shame on both of you
[15:54:37 CEST] <BBB> blegh
[15:55:10 CEST] <Compn> i think its more probable that the pleasantries of english are lost in non-native speakers
[15:56:03 CEST] <BBB> I think its up to the speaker to take a conservative approach in responding if english isnt your native language
[15:56:10 CEST] <BBB> neither of them is doing that right now
[15:56:46 CEST] <thardin> text, vagaries of language hard to communicate, etc
[15:57:17 CEST] <Compn> i wouldnt shame anyone in the discussion because they havent really done anything wrong
[15:57:28 CEST] <Compn> just two differing opinions
[15:58:10 CEST] <Compn> devs could be less emotional, but of course, there is no rule about being emotional :)
[15:59:00 CEST] <Compn> devs could do some extra work and work together to solve a problem, that would be nice
[15:59:10 CEST] <Compn> but that rarely happens
[16:15:37 CEST] <cone-594> ffmpeg 03Diego Biurrun 07master:b57a95d0147b: cfhd: Add FATE tests
[16:15:38 CEST] <cone-594> ffmpeg 03James Almer 07master:d2917501c252: avcodec/cfhd: support cropped height tag
[16:15:39 CEST] <cone-594> ffmpeg 03James Almer 07master:7293248239c4: Merge commit 'b57a95d0147beae746db1c1223d100447f42dced'
[16:20:07 CEST] <cone-594> ffmpeg 03Martin Storsjö 07master:98ee855ae0cc: arm: vp9itxfm: Template the quarter/half idct32 function
[16:20:08 CEST] <cone-594> ffmpeg 03Martin Storsjö 07master:3a0d5e206d24: arm/aarch64: vp9itxfm: Skip loading the min_eob pointer when it won't be used
[16:20:09 CEST] <cone-594> ffmpeg 03James Almer 07master:60aa56fdf0b1: Merge commit '3a0d5e206d24d41d87a25ba16a79b2ea04c39d4c'
[16:38:56 CEST] <cone-594> ffmpeg 03Jan Ekström 07master:247281e80511: configure: add pkg-config check for alsa
[16:39:01 CEST] <JEEB> there
[16:39:06 CEST] <JEEB> one random user on #ffmpeg made happy
[16:39:21 CEST] <JEEB> jamrial: also added comments about static linking (although using pkg-config in general is good (TM))
[16:43:53 CEST] <relaxed> maybe there should be a fate instance where ffmpeg is built statically with the most common external libs
[16:47:53 CEST] <jamrial> ubitux had one like that, i think
[16:48:13 CEST] <ubitux> yes, but it's a shared one :p
[16:48:30 CEST] <jamrial> ah right, archlinux lacks static libraries for most packages :p
[16:48:46 CEST] <JEEB> relaxed: I don't disagree. the problem is that currently to build, say, x265, you have to come up that you need libraries that aren't in the pkg-config file (c++ stdlib, math and thread libraries). and then when you start adding additional parameters you might miss breakage
[16:48:55 CEST] <JEEB> although the math library is going to be added as global :|
[16:49:00 CEST] <JEEB> because so many things miss that one
[16:49:03 CEST] <BBB> Compn: I disagree that theyve done nothing wrong, I think for once we should all be able to agree that if the only result of a discussion was that you pissed off the other side, that YES you did something wrong - both sides are guilty of that in this discussion
[16:49:30 CEST] <BBB> Compn: one of the goals of any mature, reasonable discussion should always be to not annoy the other side. were all grown-ups here, right?
[16:50:15 CEST] <JEEB> jamrial: which reminds me, you had that global math lib patch lying around which I LGTM'd?
[16:50:24 CEST] <JEEB> that should fix LAME I think
[16:50:27 CEST] <JEEB> "fix"
[16:50:32 CEST] <JEEB> that thing doesn't even have a pc file q_q
[16:50:37 CEST] <jamrial> JEEB: i'm waiting a bit before applying that
[16:50:40 CEST] <JEEB> k
[17:44:55 CEST] <winegums> not sure if this is relevant but if I build on macOS 10.12 and I get everything to static link (which I have finally done woo!) it still dynamically links to .frameworks files that seem to be OS based, making it not work when testing on a lesser macOS (such as 10.9)
[17:45:02 CEST] <winegums> @JEEB
[17:45:35 CEST] <JEEB> well d'uh. if there's something needed from the system then that can't exactly be statically linked can it?
[17:45:52 CEST] <JEEB> for macs usually the thing was to build with an older SDK and then use those on newer things as well
[17:46:27 CEST] <winegums> yeah i guess building with older SDK makes sense and is what I am trying to do next
[17:46:32 CEST] <winegums> but why does it need this: 
[17:46:37 CEST] <winegums> `/System/Library/Frameworks/CoreImage.framework`
[17:46:58 CEST] <winegums> and security.framework
[17:50:55 CEST] <JEEB> those should pop up in ffbuild/config.log
[17:51:11 CEST] <JEEB> also if they're something uses that is autodetected, you can do --disable-autodetect
[17:51:18 CEST] <JEEB> (that's an option nowadays)
[17:51:27 CEST] <JEEB> also this ia  question for #ffmpeg, not -devel
[18:05:04 CEST] <nevcairiel> you can't static link the frameworks, obviously. If you want to target a lower OSX version, you should pass something like --extra-cflags="-mmacosx-version-min=10.9", and the --disable-autodetect option can also get rid of all of them, and allow you to selective re-enable those you want to use
[18:23:10 CEST] <winegums> @JEEB ok thanks, and yeah i will move to that channel, sorry I was trying to build for edits made on my end 
[18:35:21 CEST] <winegums> @nevcairtiel thanks!!!!!!!
[19:53:08 CEST] <Compn> BBB : eh, my expectations have been lowered about discorse over these past 2 years in USA history... it certainly does not look like the flamewars of the past
[19:53:37 CEST] <BBB> hah
[19:53:55 CEST] <BBB> but ignore the country for a bit, we can be a professional bunch of folks, right?
[19:57:57 CEST] <Compn> we are all human
[19:58:10 CEST] <Compn> thats about all i'm going to commit to.
[19:58:10 CEST] <BBB> yes, we are
[19:58:15 CEST] <BBB> :-p
[19:58:16 CEST] <BBB> o
[19:58:17 CEST] <BBB> ok
[20:48:02 CEST] <jbreeden> Hello all. I'm interested in developing RTP/RTSP support for H264 Scalable Video Codec(Annex G). Looking for guidance on whether I should modify existing h264 support to include Annex G, or add a new rtpdec module.
[20:50:06 CEST] <jkqxz> Are you also intending to write a decoder for it?
[20:50:54 CEST] <jkqxz> IIRC the RTP format is quite different to normal H.264, so a separate module is probably right.
[20:55:00 CEST] <jbreeden> Unfortunately no, I'm not expert enough to write a decoder. Currently using a licensed, proprietary decoder. Would like to contribute back the pieces that I can, though.
[20:59:03 CEST] <jbreeden> RTP for SVC is very much additive to the format for AVC. There are a couple of additional NAL types to handle, but few(if any) changes to handling of existing NALs
[21:02:26 CEST] <jkqxz> There are more different packetisation formats, and also the PASCI things.
[21:02:45 CEST] <jkqxz> (I should actually go back read it before saying more stuff in case I'm totally wrong...)
[21:05:00 CEST] <jbreeden> To my knowledge you are correct, but my point is that they are all represented by additional NALs that are left reserved in RFC3984/6184, rather than modifying the handling of existing types, unless I am mistaken.
[21:06:35 CEST] <wbs> I would suggest trying to implement it in the existing depacketizer, and if it doesn't turn out to sensible, try doing it separately
[21:09:17 CEST] <cone-505> ffmpeg 03Mark Thompson 07master:624d4739dbfc: cbs_h264: Fix writing streams with auxiliary pictures
[21:09:18 CEST] <cone-505> ffmpeg 03Mark Thompson 07master:d792613badfe: h264_metadata: Fix clearing SEI payload in error case
[21:09:19 CEST] <cone-505> ffmpeg 03Mark Thompson 07master:41272e112b38: cbs_h264: Fix memory leak in error case
[21:09:20 CEST] <cone-505> ffmpeg 03Mark Thompson 07master:03b1470088e6: vaapi_h264: Add missing return value check
[21:09:21 CEST] <cone-505> ffmpeg 03Mark Thompson 07master:32a618a948c2: vaapi_h264: Do not use deprecated header type
[21:09:22 CEST] <cone-505> ffmpeg 03Mark Thompson 07master:242d8c8763d8: opusenc: Fix double-declaration of variable
[21:09:23 CEST] <cone-505> ffmpeg 03Mark Thompson 07master:c37de519202a: vorbis: Reorder conditions to avoid possible overread
[21:10:48 CEST] <jbreeden> And another related question- Given that the SVC base stream is compatible with AVC, does it make more sense to add a new codec id for SVC, or to wrangle it into AC_CODEC_ID_H264 with some other mechanism of identifying the difference?
[21:11:11 CEST] <jbreeden> *AV_CODEC_ID_H264
[21:18:34 CEST] <jkqxz> Right, looking at that RFC again it probably is right to do it with the same code if possible.  (I remember more weird stuff in it for some reason...)
[21:24:35 CEST] <jkqxz> Can someone look at CID 1419837 and tell me whether I'm being stupid?
[21:26:28 CEST] <jkqxz> "32. assignment: Assigning: crop_unit_y = 1 + (sps->chroma_format_idc < 2). The value of crop_unit_y is now 0."  <-  Uhh, no.  crop_unit_y is definitely either 1 or 2 after that assignment, regardless of the value of sps->chroma_format_idc.
[21:26:58 CEST] <BtbN> boolean true is -1 in some variants I think?
[21:28:00 CEST] <jkqxz> No.  C11 says: "Each of the operators < (less than), > (greater than), <= (less than or equal to), and >= (greater than or equal to) shall yield 1 if the specified relation is true and 0 if it is false. The result has type int.".
[21:29:12 CEST] <jkqxz> Some CPU instructions do give you -1 (really, all-ones), but the compiler would know that.
[21:43:32 CEST] Action: JEEB wonders how the s302m "decoder" works
[21:43:41 CEST] <JEEB> it has an option for "decode if possible else passthrough"
[21:43:52 CEST] <JEEB> but I don't see it calling any other decoders or setting formats
[21:44:12 CEST] <JEEB> it was just mentioned on a -devel thread regarding compressed audio in PCM
[21:44:40 CEST] <JEEB> which is something one of the formats I have been working on happens to have (due to capture card roots)
[21:45:32 CEST] <JEEB> so if there's already something that handles the whole "identify compressed format and call decoder" that'd be cool
[21:45:42 CEST] <JEEB> or not even call decoder, just note what it is
[21:45:51 CEST] <JEEB> so that the API client can then create the proper decoder :V
[21:48:30 CEST] <durandal_1707> JEEB: with ffmpeg : no
[21:48:38 CEST] <durandal_1707> with api: yes
[21:49:27 CEST] <JEEB> well yea, the idea would be that my demuxer would be calling that one or something
[21:49:44 CEST] <JEEB> to probe WTF is in the "PCM" stream (AAC or PCM basically)
[21:49:49 CEST] <durandal_1707> you need to manually decripple audio in stream
[21:50:13 CEST] <JEEB> well as far as I got was demuxing the audio packets and feeding them to the AAC decoder with the "Full" parser
[21:50:18 CEST] <JEEB> forcing that worked
[21:50:35 CEST] <JEEB> so I will guess that if the s302m "decoder" does its thing that should work
[21:50:36 CEST] <cone-505> ffmpeg 03Dave Rice 07master:89cc48551bbe: avdevice/decklink_dec: 32 bit audio support
[21:51:22 CEST] <durandal_1707> JEEB: s302m decoder only does pcm stuff
[21:51:43 CEST] <JEEB> it has an option
[21:51:44 CEST] <JEEB> "decode_copy" , "Decode if possible else passthrough"
[21:51:50 CEST] <JEEB> so it doesn't do that?
[21:52:07 CEST] <durandal_1707> it cant decode dolby shit
[21:52:21 CEST] <JEEB> thankfully I only care about AAC and raw PCM in PCM
[21:52:35 CEST] <JEEB> although I guess someone's PS2 captures could have AC3 in PCM
[21:52:42 CEST] <jbreeden> @jkqxz and @wbs thanks for the advice, will work on modifying existing rtpdec_h264
[21:52:50 CEST] <JEEB> and yes, I didn't expect it to decode it for me, just tell me "this is X, here's your packet"
[21:53:31 CEST] <JEEB> and then I would feed it to the X decoder
[21:53:52 CEST] <JEEB> I'm just looking at the code and I don't see it actually doing anything else than parsing some of the stuff in the PCM
[21:54:01 CEST] <JEEB> not even setting codec ids
[21:54:31 CEST] <JEEB> or wait
[21:55:13 CEST] <JEEB> nope
[21:55:34 CEST] <JEEB> ... so if s302m is supposed to be for compressed stuff in PCM I am thoroughly confused
[21:55:46 CEST] <JEEB> unless you're supposed to then probe the buffer yourself
[21:56:35 CEST] <nevcairiel> we have a dolby-e decoder now, but since s302m is a decoder by itself, you would need to chain two decoders, which is not something we can currently do automatically
[21:56:46 CEST] <JEEB> I'm fine with that
[21:57:06 CEST] <JEEB> also I'm mostly thinking of SPDIF AAC or just raw PCM being the two main use cases right now
[21:57:25 CEST] <JEEB> as I want to finish this capture format demuxing with at least audio first.
[21:57:38 CEST] <nevcairiel> personally i've only ever seen pcm or dolby-e in s302m
[21:57:47 CEST] <JEEB> ok, so s302m is something else
[21:57:51 CEST] <JEEB> never mind then
[21:58:03 CEST] <JEEB> just noticed it mentioned on -devel regarding compressed audio in PCM
[21:58:08 CEST] <JEEB> so I got hopeful :P
[21:58:47 CEST] <nevcairiel> i guess there can also be something else in there
[21:58:52 CEST] <nevcairiel> but its a rather special format
[21:59:15 CEST] <JEEB> I just thought it was the fancy name for SPDIF-like bit streaming
[21:59:22 CEST] <JEEB> over raw PCM
[21:59:34 CEST] <nevcairiel> isnt SPDIF the name for that =p
[21:59:49 CEST] <JEEB> there was some SMPTE spec name for it I think
[21:59:54 CEST] <JEEB> and s302m reminded me of that
[22:05:04 CEST] <cone-505> ffmpeg 03Marton Balint 07master:f4090940bd30: ffmpeg: always init output stream before reaping filters
[22:20:09 CEST] <jamrial> jkqxz: wont you add cbs tests for the hevc rext samples?
[22:20:30 CEST] <jamrial> one per type should be enough to increase coverage
[22:57:09 CEST] <jkqxz> Yeah.  Need to go through and pick some, I'll try to do it soonish.
[23:34:17 CEST] <jamrial> michaelni: could you test the merge in https://github.com/jamrial/FFmpeg/commits/mergework? it touches h264/hevc nalu splitting, so even if fate passes I'd rather have some more testing as well
[00:00:00 CEST] --- Thu Oct 19 2017