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

[burek]

[00:12:28 CEST] <cone-716> ffmpeg 03Martin Vignali 07master:7ebd13fc8b2d: libavodec/exr : add support for Y and YA file (ticket #5621)
[00:12:29 CEST] <cone-716> ffmpeg 03Martin Vignali 07master:50747d6b1f25: libavcodec/exr : indent gray support patch
[01:09:59 CEST] <rcombs> OK, weird case to think about
[01:10:40 CEST] <rcombs> right now, the FLAC muxer uses the timestamps from the bitstream, which means they're wrong if you're using the segment muxer or seeked in ffmpeg and are stream-copying or [modified timestamps after the encoder in any other way]
[01:11:22 CEST] <rcombs> I've got a change here that rewrites the frame header to insert the timestamp from AVPacket instead
[01:11:45 CEST] <rcombs> and also modifies STREAMINFO's total duration value
[01:12:04 CEST] <rcombs> what should I do if timestamps don't start at zero, though?
[01:12:38 CEST] <rcombs> right now, I'm setting the STREAMINFO duration by adding all the packet durations, and setting packet timestamps directly from pkt->pts
[01:12:40 CEST] <nevcairiel> its a raw audio format, you should just generate new timestamps
[01:13:07 CEST] <rcombs> but the format does allow for a positive nonzero start time
[01:13:17 CEST] <rcombs> nevcairiel: that seems sane enough
[01:13:41 CEST] <rcombs> nevcairiel: only one thing I'm concerned about; is it possible to have invalid/zero packet durations there?
[01:13:58 CEST] <nevcairiel> its audio, cant you get full durations from it somehow?
[01:14:29 CEST] <rcombs> like, parse the packet header and get it from there?
[01:14:37 CEST] <rcombs> I suppose I could
[01:15:00 CEST] <rcombs> (I'm already doing a reasonable amount of parsing so I can rewrite the timestamps correctly)
[01:15:43 CEST] <nevcairiel> just need to handle variable blocksize and fixed blocksize cases
[01:16:00 CEST] <nevcairiel> iirc the want different info in that field then
[01:16:17 CEST] <rcombs> yeah, I'm handling that for the timestamp rewriting already
[09:05:30 CEST] <ubitux> hey nevcairiel 
[09:05:40 CEST] <ubitux> did you receive some insults from the guy or not yet?
[09:05:55 CEST] <ubitux> just got 2 personal mails full of threats
[09:13:52 CEST] <andrey_turkin> I see no actual threats there. Just 100% full of insults and a bit over the top
[09:15:31 CEST] <nevcairiel> ubitux: nah didnt get anything
[09:15:47 CEST] <ubitux> "a bit over the top"
[09:15:49 CEST] <ubitux> lol
[09:18:36 CEST] <nevcairiel> at first i thought that many people write emotional mail sometimes, but thats another kind of crap
[09:19:32 CEST] <andrey_turkin> I can understand his frustation about apparent rejection he got, and he had some points about factual numbers on speedups gained by using SIMD on x86. Now he was given the measurement, and he was given detailed analysis of his patch, and "overreacted" is not even an understatement to his response
[09:20:42 CEST] <nevcairiel> he could've just answered the questions instead of degrading to personal attacks
[09:21:04 CEST] <nevcairiel> this way he will not get code accepted at all
[09:23:34 CEST] <andrey_turkin> hey, maybe he'll come back with reworked patch addressing those comments and it'll be beautiful and 4x speedup... Good thing conditions of that bounty require to get fixes into main repo - it got to make him more amenable
[09:24:21 CEST] <nevcairiel> you would think so, but he doesnt sound like it
[09:25:16 CEST] <ubitux> was 1df908f33f658979b32599489ca6f1a39821013c ever reviewed btw?
[09:25:20 CEST] <andrey_turkin> He could've thought he did the best job possible. Until review email, that is. Now there are technical objections that needs to be addressed
[09:46:44 CEST] <andrey_turkin> hm, so there's 3 different bounties on various parts of ffmpeg, totalling over $3000
[09:47:45 CEST] <nevcairiel> which really isnt a lot in developer man hours
[09:48:16 CEST] <andrey_turkin> depending on a place it can be plenty
[09:48:31 CEST] <andrey_turkin> my monthly salary is a bit over $1000
[09:48:47 CEST] <nevcairiel> it isnt a lot where IBM comes from, lets put it this way
[09:48:48 CEST] <andrey_turkin> so it woul be worth 3 months of full time work
[09:49:04 CEST] <andrey_turkin> that's true. Probably not many people have power8 just lying around
[09:49:07 CEST] <kierank> interesting double standard in ffmpeg when it comes to insults
[10:07:38 CEST] <mateo`_> hello there
[10:09:28 CEST] <mateo`_> quick question regarding avctx->pkt_timebase, a decoder is not supposed to rely on its value to rescale the pkt->pts as it is not meant to be set if an application is using the new codecpar api, right ?
[10:12:10 CEST] <mateo`_> also, what was the initial purpose of this field ?
[10:13:34 CEST] <mateo`_> s/purpose/use case/
[10:28:07 CEST] <nevcairiel> mateo`_: its really unrelated to codecpar - but decoders should typically have no reason to touch the timestamps at all, some subtitle decoders with in-band timing info not withstanding
[10:30:42 CEST] <mateo`_> nevcairiel: ok, i'm using it in my current MediaCodec hwaccel patch to provided rescaled pts in us to the input packet (so the values are forwared to the output surface and the user gets a chance to get ts in us at this level) but since I switched to codecpar the pkt_timebase is not set anymore
[10:32:04 CEST] <nevcairiel> its not a field guaranteed to be available
[10:32:18 CEST] <nevcairiel> and video decoders should really just forward the input timestamps
[10:33:17 CEST] <nevcairiel> anyway you would need to set pkt_timebase on the avcodeccontext manually during creation from AVStream->time_base
[10:33:18 CEST] <mateo`_> I'll explicitely tell in the documentation that the timestamps forwarded the surface are in fact pts from the input avpackets (and need to be rescaled if the user wants something in us)
[10:34:59 CEST] <mateo`_> nevcairiel: just to confirm what you just said, it is not mandatory to set it, right ?
[10:35:13 CEST] <nevcairiel> its not, but some things need it to function properly
[10:35:30 CEST] <mateo`_> ok
[10:36:13 CEST] <mateo`_> It's better not using it right ?
[10:37:04 CEST] <nevcairiel> unless you absolutely have to do for some things
[10:37:28 CEST] <nevcairiel> it was introduced for a reason, its needed if you need to touch the timestamps
[10:37:41 CEST] <nevcairiel> but thats really just very few cases in audio and a few subtitle things
[10:37:50 CEST] <nevcairiel> video should not have such a reason, usually
[10:38:44 CEST] <nevcairiel> thats what all other video codecs do, just forward AVPacket->pts in AVFrame->pkt_pts
[10:38:54 CEST] <nevcairiel> without changes
[10:41:44 CEST] <mateo`_> In theory I need to feed normalized ts in us to MediaCodec, in pratice I'm not even sure it is used at all by users or the surface itself for rendering. I'll double check this point before dropping the rescaling.
[10:42:27 CEST] <nevcairiel> some external libraries have rather fixed requirements when it comes to timestamps
[10:42:47 CEST] <nevcairiel> its quite unfortunate they cant just passthrough timestamps untouched
[11:29:32 CEST] <rcombs> so, ff_vorbis_comment uppercases keys
[11:30:16 CEST] <rcombs> despite the rest of lavf using lowercase keys
[11:30:19 CEST] <rcombs> ~why though~
[11:32:26 CEST] <rcombs> looks like the VorbisComment spec recommends uppercase keys, so we should be writing uppercase and converting to lowercase when reading
[11:37:15 CEST] <nevcairiel> metadata api is case insensitive, so does it matter?
[11:37:16 CEST] <nevcairiel> :)
[11:37:22 CEST] <nevcairiel> for writing, i guess
[11:37:52 CEST] <rcombs> well we currently write lowercase tags contrary to the spec
[11:39:30 CEST] <rcombs> I guess it doesn't matter much on input since people probably don't use AV_DICT_MATCH_CASE but it's still weird
[14:55:47 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:b450b82514e9: avcodec/exr: Fix mixed declarations and statements
[15:01:16 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vKmfw
[15:01:16 CEST] <KGB> 13FFV1/06master 14c126901 15Jérôme Martinez: Add myself as author
[15:24:46 CEST] <Timothy_Gu> ok this dan parrot guy is THE best I've ever seen, and I've been here for a while
[15:28:32 CEST] <ubitux> the one who started by insulting on the trac and went talking to himself wasn't that bad either
[15:31:55 CEST] <BBB> Im not sure best is the best choice of words here :-p
[15:35:26 CEST] <Timothy_Gu> nah ML is better. More damage.
[16:09:35 CEST] <andrey_turkin> I wonder if measuring benchmarks in cloud environment has any relation to actual speedups on the hardware
[16:13:00 CEST] <Timothy_Gu> Hey! fatebeta actually managed to make a v3.1 branch automatically this time
[16:33:31 CEST] <BBB> andrey_turkin: I really think that questions like that should be left to the person writing the assembly
[16:33:48 CEST] <BBB> andrey_turkin: if he thinks thats an issue, he should provide evidence (data, facts) to support that idea
[16:34:55 CEST] <BBB> andrey_turkin: I dont think we should make a habit out of allowing fud (doubts, etc.) to discredit genuine (e.g. data-driven) concerns
[16:35:09 CEST] <andrey_turkin> It is a more of a general question. I'm genuinely interested
[16:36:05 CEST] <andrey_turkin> say, if I don't have AVX512 hardware but there is a cloud VPS which supports it. Can I get any meaningful results from that or do I have to have bare-metal?
[16:36:41 CEST] <BBB> I dont know...
[16:36:47 CEST] <nevcairiel> if its actual hardware powering that and not some sort of crazy emulation, its probably close enough
[16:38:58 CEST] <jkqxz> Yeah.  Shared machines may randomly do nasty thing to your results, but if you run it lots of times then it should be valid.
[16:39:56 CEST] <andrey_turkin> cool. that's good to know )
[16:40:03 CEST] <jkqxz> (Though VPS type things certainly hide features - even if the underlying CPU supports something, it may not actually appear.  If it's there then it should be fine.)
[16:43:04 CEST] <Gramner> it's usually very obvious if anything weird is going on with performance of instruction sets on a machine due to emulation or whatnot. e.g. if an instruction takes 5000 clock cycles instead of 3
[17:06:26 CEST] <nevcairiel> Timothy_Gu: can you also make fatebeta start automatically so its not down so much? :)
[20:21:12 CEST] <CFS-MP3b> I sent a patch yesterday (first ever) but there's been no reply... don't know if it's good or bad but I'm leaning towards bad :-) 
[20:21:14 CEST] <CFS-MP3b> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-July/196382.html
[20:21:27 CEST] <CFS-MP3b> Could someone comment? Maybe I just didn't send it correctly
[20:25:00 CEST] <jamrial> CFS-MP3b: give people some time. and if you don't get a reply or review after a week then ping the patch
[20:29:08 CEST] <llogan> it's a busy mailing list. sometimes we just forget or miss it.
[20:36:37 CEST] <CFS-MP3b> jamrial @llogan that's fine, I just want to make sure it's not that I sent the patch incorrectly :-) 
[21:53:29 CEST] <JEEB> sure is "clever" spam
[21:55:39 CEST] <bollocks_k> lol
[22:05:44 CEST] <BBB> how do I ban a user?
[22:06:51 CEST] <BBB> well theyre deleted
[22:07:01 CEST] <BBB> but I dont know how to retrieve the users IP so I cant ban the ip :(
[22:07:17 CEST] <jamrial> llogan probably knows how
[22:09:00 CEST] <BBB> he just added it already
[22:09:18 CEST] <jamrial> the filter has reached a point where spammers are forced to mangle their shit so much that i wonder just how effective posting all that is at this point
[22:09:51 CEST] <llogan> persistant bastards aren't they?
[22:10:02 CEST] <BBB> always the quickbooks tech support, also
[22:10:09 CEST] <BBB> llogan: how do I find the ip?
[22:11:13 CEST] <llogan> BBB: i view IP via .org/admin/spamfilter/monitor
[22:11:27 CEST] <llogan> if you don't have access I can add you
[22:11:35 CEST] <BBB> I have access
[22:11:42 CEST] <BBB> crap I just deleted them
[22:11:54 CEST] <BBB> anyway, thanks
[22:12:11 CEST] <BBB> oh wait monitor is still there
[22:12:15 CEST] <BBB> I just deleted the reports
[22:13:16 CEST] <llogan> a trac update removed "mark selected as spam". i need to re-introduce that because "delete selected as spam" is much less useful...also that only deletes the entry in the monitor, and doesn't actually delete the associated post, etc.
[22:14:09 CEST] <llogan> oh, you deleted the spam reports. that's fine.
[22:14:18 CEST] <BBB> llogan: so, you didnt actually add the guys ip to badip, did you?
[22:14:31 CEST] <BBB> (122.177.63.136, according to monitor)
[22:14:57 CEST] <llogan> i guess i missed that one. there were several
[22:15:31 CEST] <llogan> also, i can't recall if entries apply immediately in the badip filtering or not
[22:15:43 CEST] <BBB> we need a button to add selected to badip ;)
[22:16:07 CEST] <llogan> i can add it unless you want to
[22:21:14 CEST] <llogan> i should be taking my lunch break now instead of dealing with these retards
[22:21:29 CEST] <BBB> Ill deal with it
[22:21:46 CEST] <llogan> i wonder how many incoming calls they can handle
[22:29:08 CEST] <llogan> BBB: do you see any results if you do a google site search on trac for quickbooks? i get three. some from may 18. so i don't think they even care if they are deleted here.
[22:29:43 CEST] <kierank> CFS-MP3b: I don't personally see what you want to implement in scte-35
[22:30:03 CEST] <kierank> iirc it needs quite specific timing
[22:30:07 CEST] <BBB> I see only links to deleted pages
[22:30:13 CEST] <BBB> if you click Select similar ones, you get 8
[22:40:38 CEST] <CFS-MP3b> kierank : Take SCTE-35 cues into account when it is cutting video for HLS segmentation and export SCTE-35 data to HLS Playlists are the first goals of this stage of the project
[22:41:00 CEST] <nevcairiel> didnt we have someone want that before
[22:41:21 CEST] <CFS-MP3b> nevcairiel I'm sure it's a recurring thing 
[22:42:25 CEST] <nevcairiel> oh right someone made stream copying of data streams work related to scte-35, which would kinda imply scte35 streams are exposed as data streams already
[22:42:29 CEST] <CFS-MP3b> I even saw some patch that was rejected some time ago... I checked it out and it seemed rushed... for example it missed section 6 of the specs completely (PMT data) 
[22:44:34 CEST] <CFS-MP3b> Anyway my plan is to do a complete implementation, but since I'm new to ffmpeg it doesn't seem like a good idea to do everyhing and come with a large patch that might look to me but be complete shit
[22:45:00 CEST] <nevcairiel> doing smaller parts incrementally is definitely a good idea
[22:45:45 CEST] <CFS-MP3b> @nevcairiel that's why I started with a small thing... add the codec type, prepare a dummy function that receives data if present even if it doesn't do anything just yet
[22:46:47 CEST] <CFS-MP3b> getting this accepted into the mainstream version is a requirement... just having a patch that does the job but that needs to be backported from time to time it's not good enough
[22:51:37 CEST] <kierank> lol
[22:51:58 CEST] <CFS-MP3b> lunch time for me, bbl
[23:10:24 CEST] <ehedeman> Is this the right place to propose or ask for feedback on changes?
[23:11:44 CEST] <ehedeman> I have been working on some changes to the fps video filter, and realized that each filter appears to have it's own symbol table for the command line expression parsing.
[23:13:18 CEST] <ehedeman> Thoughts on having a global symbol table so that things like height/width/fps can be shared across different filter configs?
[23:13:44 CEST] <kierank> how is that thread safe
[23:14:16 CEST] <BBB> or even multi-instance safe
[23:14:55 CEST] <nevcairiel> the thing with those expressions is that they point into a struct, so even though the options are the same, they tend to have different offsets into different structs
[23:24:29 CEST] <ehedeman> Ah, yeah I didn't think about the multi instance implications.
[23:26:02 CEST] <ehedeman> We are just thinking about doing more adaptive transcoding, and it would be nice to not have to add a new field and submit upstream every time we want to add a condition.
[23:33:27 CEST] <KGB> [13FFV1] 15michaelni closed pull request #19: Make rfc format (06master...06make-rfc-format) 02https://git.io/vozkz
[23:53:56 CEST] <CFS-MP3b> back
[00:00:00 CEST] --- Fri Jul  8 2016