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

[burek]

[04:08:35 CET] <philipl> BtbN: Thanks for fixing. I can't remember if a fully inline version was discussed at the time but the multiply included file was a pattern used elsewhere. I'm fine with the inline.
[04:09:31 CET] <philipl> so ship it.
[12:57:46 CET] <BtbN> philipl, I wasn't able to reproduct any breakage, but the symbol was exported from two libraries, and someone somehow had an issue with that.
[12:58:16 CET] <BtbN> I still think it's an issue with stale build files, but it's ugly in either case.
[13:04:03 CET] <JEEB> any comments on the libaribb24 patch set dear silent majority? (I hope you're happy that only my SAN points are going down)
[13:07:26 CET] <durandal_1707> j-b: i started writing ac-4 decoder
[13:08:26 CET] <JEEB> durandal_1707: did the samples at DASH-IF actually work btw?
[13:08:43 CET] <JEEB> like, if you demux them the samples seem to make sense as based on the spec?
[13:13:30 CET] <durandal_1707> JEEB: yes, they have sense, have sequence counter increasing to 1020 and than wrapping back to 1
[13:14:11 CET] <JEEB> cool
[13:53:29 CET] <atomnuker> durandal_1707: did you find a binary to re or something?
[14:00:02 CET] <cone-143> ffmpeg 03Carl Eugen Hoyos 07master:0cac68bcf94e: lavu/parseutils: Allow to parse >= 100 hours.
[14:08:32 CET] <durandal_1707> atomnuker: there is spec
[14:08:40 CET] <JEEB> yup
[14:08:45 CET] <JEEB> they're pushing it for ATSC3 I think?
[14:08:49 CET] <JEEB> so they had to kind of publish it
[15:15:41 CET] <kierank> durandal_1707: there is binary as well
[15:24:34 CET] <atomnuker> what's it like? low-overlap mdct like opus? aac-like vector quantization with lots of codebooks?
[15:25:41 CET] <JEEB> the only thing I remember with AC-4 is that instead of having longer audio frames they decided to make P-frames
[15:29:41 CET] <atomnuker> neat, I wonder how many muxers mark audio keyframes correctly
[17:53:38 CET] <durandal_1707> kierank: binary?
[18:18:15 CET] <cone-164> ffmpeg 03Michael Niedermayer 07master:4cde7e62dbaa: avcodec/sbrdsp_fixed.c: remove input value limit for sbr_sum_square_c()
[18:18:15 CET] <cone-164> ffmpeg 03Michael Niedermayer 07master:dfae0e295a6c: tools/target_dec_fate.list: Extend selftests upto issue 2000
[18:27:58 CET] <kierank> durandal_1707: for ac-4
[18:34:05 CET] <cone-164> ffmpeg 03chcunningham 07release/4.1:bcc71f30adc9: avformat/mov.c: require tfhd to begin parsing trun
[18:34:06 CET] <cone-164> ffmpeg 03chcunningham 07release/4.1:00cdf4e4e517: avformat/mov: validate chunk_count vs stsc_data
[18:34:07 CET] <cone-164> ffmpeg 03Michael Niedermayer 07release/4.1:74700e50bf74: Changelog: update
[20:01:55 CET] <cone-164> ffmpeg 03Reto Kromer 07master:5b32f94b97df: doc/ffprobe: fix typo and update URL in man
[20:32:26 CET] <JEEB> ok, does anyone have any further comments on the libaribb24 patch set? does anyone share the issues that carl has?
[20:35:30 CET] <JEEB> the lack of even technical comments after the first one I received for the demuxer is at this point kind of funny. (I'm thankful for the first reviews of course)
[20:55:28 CET] <agrecascino> since nobody told me anything i just went and implemented counting
[20:55:46 CET] <agrecascino> it wasn't difficult nor much code
[20:55:55 CET] <agrecascino> it's just ugly and bad
[21:03:13 CET] <JEEB> michaelni: /62
[21:05:04 CET] <JEEB> uhh, sorry. anyways, can you check the libaribb24 thread if you share any of the fears that carl has.
[21:06:17 CET] <JEEB> I'm mostly asking because right now it looks like I'm pushing my opinion over his (mostly because people from here don't voice their opinion on it way or another)
[21:06:44 CET] <JEEB> I'm really happy I did at least get some technical comments at the beginning, which I then applied changes according to :P
[21:06:53 CET] <JEEB> but after that it's been silent
[21:22:45 CET] <michaelni> JEEB, iam silent because i know very little about the subject and because to me it looks like noone is blocking the patch, i have not looked at the lib before and looking now i see it is less than 3k lines of code in .c which includes some generic code like md5. So from this without any deeper knowledge the question about avoiding the dependancy and implementing this internally is an obvious thought. But i dont know the 
[21:22:45 CET] <michaelni> details so i dont know what is better
[21:24:25 CET] <JEEB> my biggest issue with taking it in currently is that it's LGPLv3 (currently). if I have to push something through the FFmpeg review process then I'd want the result to be LGPLv2.1+
[21:24:44 CET] <michaelni> yes that makes sense
[21:26:11 CET] <JEEB> I did write-up a plan of implementing it internally (given the license doesn't change), but that would be a relatively long process of changing an iconv module into something in libavutil for the text encoding first, and then reviewing/rewriting an anonymous lavc decoder from a person who literally seems to have forked and made custom changes to all the surrounding projects to get it to work (libass 
[21:26:17 CET] <JEEB> for ASS rendering etc)
[21:26:18 CET] <JEEB> yet I got no real comments on that
[21:27:07 CET] <JEEB> so now it's a case of me of course wanting a clear resolution and if possible the stuff I used my free time for in. and since literally no-one voiced an opinion the only other voice in the thread is one that is against the patch (but does not block it)
[21:27:14 CET] <JEEB> I don't meant that you have to voice an opinion
[21:27:18 CET] <JEEB> *mean
[21:27:22 CET] <JEEB> it's just irritating as hell
[21:27:45 CET] <JEEB> since I've generally received positive feedback from people including those who have tested it (and some people here)
[21:29:31 CET] <JEEB> and if people really don't like this patch then I would get a resolution and just separate the AVCodecID/description stuff and then just the demuxing
[21:30:32 CET] <JEEB> right now I'm in a weird state where it looks like I'm pushing over without consensus even though I feel like there's a consensus (which is not necessarily positive but also isn't negative)
[21:32:41 CET] <JEEB> also VLC is using that library (and it's packaged in debian!) and the author has been seen commenting on pull requests again, so while it most likely will go off onto videolan's gitlab at some point for shared maintainership, it's not dead.
[21:33:25 CET] <michaelni> JEEB, you could just post to the ML a patch (if a new one is needed) and then say you will apply it in X days if noone objects
[21:34:49 CET] <JEEB> I already posted something along that way and got an angry response on it. still not blocking it, of course
[21:35:36 CET] <JEEB> because of course my sincerity of trying to get a consensus is being contested because literally no-one else seems to be for the patch set (looking at the responses)
[21:37:23 CET] <JEEB> I hope this explains why I'm feeling frustrated
[21:40:01 CET] <JEEB> and this applies to literally everyone in this community. I am not specifically aiming this towards michael. I just happened to have him highlighted while thinking if I should ask or not :P and then I accidentally /window_id
[21:41:40 CET] <durandal_1707> do not be frustrated with carl
[21:42:27 CET] <michaelni> JEEB, maybe you are thinking too much about this, if noone objects then noone objects, and IIUC this is only intended to be a solution until some internal solution is designed&implemented
[21:42:40 CET] <JEEB> yes, it's a reference
[21:47:53 CET] <JEEB> durandal_1707: seriously, the last thing I want is issues down the line. I'm trying to be a nice person to work with, and I respond to comments that are put out towards my work. but then there are cases where I disagree and then literally no-one else replies
[21:48:28 CET] <JEEB> (on the mailing list of course)
[21:48:50 CET] <JEEB> on IRC I did get positive responses, but as I've been scolded by quoting them on the mailing list before...
[21:49:28 CET] <JEEB> and I'm not specifically frustrated with someone. I'm frustrated over the situation.
[22:35:26 CET] <cone-164> ffmpeg 03Reto Kromer 07n4.1.1:HEAD: doc/ffprobe: fix typo and update URL in man
[23:52:32 CET] <cone-164> ffmpeg 03Carl Eugen Hoyos 07master:5c515b5f7d64: lavf/mpegts: Convert service_name and service_provider to utf-8.
[00:00:00 CET] --- Sun Feb 10 2019