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

[burek]

[01:43:52 CET] <Shiz> wm4: you can
[01:43:55 CET] <Shiz> but not with the demo version
[01:43:57 CET] <Shiz> lol
[02:18:32 CET] <J_Darnley> Anyone else geting a PM from someone wanting to write a matroska to mp4 multiplexer?
[02:44:44 CET] <rcombs> J_Darnley: you mean ffmpeg.c? :P
[02:45:02 CET] <J_Darnley> I told him that
[02:45:38 CET] <J_Darnley> Instead he went off to read the Matroska and ISOBMFF specs
[02:45:47 CET] <rcombs> glhf
[02:46:06 CET] <rcombs> can you have NIH syndrome as an individual?
[02:46:12 CET] <J_Darnley> Yes!
[02:46:29 CET] <J_Darnley> But is usually a symptom of ignorance
[02:46:54 CET] <J_Darnley> "I have no idea what libraries exist so I will write my own"
[03:59:40 CET] <cone-809> ffmpeg 03Benjamin Steffes 07master:be482e516525: Fix detelecine filter for patterns containing 1
[03:59:40 CET] <cone-809> ffmpeg 03Benjamin Steffes 07master:c411e90bc3f1: Fix start_frame handling in detelecine filter
[12:41:04 CET] <cone-376> ffmpeg 03Mark Thompson 07master:fbec157ea08f: lavc/hevc: Allow arbitrary garbage in bytestream as long as at least one NAL unit is found.
[12:41:04 CET] <cone-376> ffmpeg 03Michael Niedermayer 07master:48bda6c5f78c: avfilter/vf_detelecine: Remove redundant declaration
[13:25:35 CET] <atomnuker> 4.54s vs 4.58s
[13:26:10 CET] <atomnuker> why do I get the feeling he did a single run before and after and by chance the latter was .04 seconds faster
[13:27:53 CET] <JEEB> lol
[13:28:18 CET] <JEEB> with such differences it always comes down to properly calculating the improvements
[13:29:26 CET] <kierank> should just be a simd function anyway
[13:30:04 CET] <kierank> perhaps even autovectorised
[13:32:15 CET] <kierank> atomnuker: do you want to try simding that function
[13:32:21 CET] <kierank> it's a nice one to learn from actually
[13:34:47 CET] <kierank> 5 instructions i think in total
[13:35:02 CET] <kierank> load, abs, copy, sqrt, sqrt, divide, store
[13:35:04 CET] <kierank> ok 7
[13:35:29 CET] <kierank> oh a multiply, 8
[13:37:30 CET] <atomnuker> inline asm?
[13:39:03 CET] <kierank> Of course not
[13:39:06 CET] <kierank> Yasm
[16:22:35 CET] <cone-807> ffmpeg 03Michael Niedermayer 07master:068026b0f784: avcodec/mjpegenc_common: Store approximate aspect if exact cannot be stored
[18:39:41 CET] <JEEB> ooh-kay... was surprised I had actually set up git send-email on my laptop
[18:40:00 CET] <JEEB> mostly because I didn't remember ever copying my .gitconfig :)
[18:57:45 CET] <cone-807> ffmpeg 03Michael Niedermayer 07master:efa98cdc2ff1: avformat/file: Add crypto to default whitelist
[19:59:50 CET] <J_Darnley> Ampersand is a special character.
[20:04:13 CET] <ubitux> nevcairiel, Daemon404 ; can't we merge a compatible commit and update our demuxer/muxers progressively?
[20:04:43 CET] <ubitux> we're really accumulating a lag in commits
[20:05:28 CET] <nevcairiel> then fix the merge if you care =p
[20:05:52 CET] <nevcairiel> and no, that would end up in a even bigger mess then it already is going to be
[20:06:44 CET] <ubitux> i'll have 2 or 3 hours to kill tomorrow, can you be more specific about how i can help?
[20:06:57 CET] <nevcairiel> make fate pass
[20:07:30 CET] <ubitux> is anyone working on something specific?
[20:07:48 CET] <nevcairiel> figure out why a test fails, see whats different, make it output the same stuff as before
[20:07:57 CET] <nevcairiel> if not possible, make sure to clearly document why output changed
[20:08:12 CET] <nevcairiel> i doubt anyone has been working on anything
[20:08:25 CET] <nevcairiel> i gave up bothering after not even getting responses from people anymore
[20:15:48 CET] <BBB> nevcairiel: I think at some point we just stop caring
[20:15:55 CET] <BBB> why is libav changing stuff for no good reason?
[20:15:57 CET] <BBB> it just adds work
[20:16:04 CET] <BBB> they should work on our tree, or we should stop merging
[20:16:13 CET] <BBB> us doubling down on their work-for-the-sake-of-work is stupid
[20:16:23 CET] <BBB> its a waste of manpower and nobody cares
[20:16:27 CET] <BBB> </troll>
[20:16:36 CET] <nevcairiel> some people seem to like some of the api changes
[20:16:47 CET] <nevcairiel> i nominate them to merge them cleanly =p
[20:16:53 CET] <BBB> then maybe they should do the merging, or they should convince the libav people to work on our tree
[20:17:05 CET] <BBB> it makes no sense that ny on of us spends time on stuff we dont want
[20:17:11 CET] <BBB> that sounds like a terrible job
[20:17:18 CET] <nevcairiel> the thing is, libav went through weeks/months of preparation patches for this api change, changing a few demuxers etc to behave more sanely
[20:17:20 CET] <nevcairiel> we dont have that
[20:17:26 CET] <nevcairiel> and people try to shoehorn that into this merge
[20:18:16 CET] <nevcairiel> those that care can finish it, and if they ask i might help, but i'm certainly not going to drive it all the way myself
[20:18:48 CET] <BBB> gotta go, bbl
[20:19:40 CET] <bencoh> this whole thing is just getting silly (more than ever) ...
[20:30:49 CET] <Daemon404> some people sure do a lot of complaining about something they dont even participate in
[20:32:49 CET] <Daemon404> fyi: ive been sick as balls the last week
[20:32:53 CET] <Daemon404> hence not around
[20:34:45 CET] <jamrial> the codecpar commit on libav's side of things had quite a few fate ref files altered, so it's not unexpected if the same thing happens with some of our own de/muxers
[20:35:17 CET] <jamrial> i think most of the time the differences were pts/dts values
[20:35:19 CET] <Daemon404> is it just fixing up fate + out demuxers now
[20:35:20 CET] <Daemon404> our*
[20:35:51 CET] <nevcairiel> probably not
[20:36:04 CET] <Daemon404> and tbh i think this merge is worth it
[20:36:11 CET] <Daemon404> everything that "broke" so far was shady as fuck
[20:36:30 CET] <jamrial> ffprobe fate tests are going to be a pita to analize, what with the long lines full of key:value stuff
[20:36:43 CET] <Daemon404> theyll all change in the same way jamrial 
[20:36:49 CET] <Daemon404> diffing the json output is easier
[20:36:51 CET] <nevcairiel> just diff the more readable format
[20:36:54 CET] <jamrial> true
[20:39:50 CET] <Daemon404> i wanted to work on it this week, but >projectile vomiting
[20:40:12 CET] <Daemon404> and some guy keeps emailing me about why encrypted hls is not working or smth, and why havent i fixed it
[20:40:30 CET] <nevcairiel> i fixed it
[20:40:51 CET] <Daemon404> i saw stuff for the options, but did that include encryption?
[20:42:09 CET] <nevcairiel> yes
[20:42:15 CET] <Daemon404> ok
[20:42:47 CET] <Daemon404> ubitux, i will poke codecpar tomorrow as well
[20:42:52 CET] <Daemon404> maybe we can finish it out
[20:42:55 CET] <Daemon404> or make some headway.
[20:44:08 CET] <nevcairiel> there is some things to decide, like what to do with has_b_frames, i find it a rather handy property to get after find_stream_info to make decoding smoother after
[20:45:55 CET] <nevcairiel> most other failures are mov and nut related
[20:46:37 CET] <nevcairiel> and some demuxers are not ported at all, primarily those needing external libraries
[20:48:05 CET] <Daemon404> nut is likely nto a big deal
[20:48:10 CET] <Daemon404> mov sounds lulzy
[20:48:52 CET] <Daemon404> what is has_b_frames used for besides delay (which is all sorts of screwed up)
[20:50:36 CET] <nevcairiel> knowing it either avoids dropping frames from the beginning of the stream or reduces decoding delay, both of which are equally useful to me
[20:51:10 CET] <Daemon404> not sure i follow how it can outright eliminate delat
[20:51:12 CET] <Daemon404> delay
[20:51:25 CET] <nevcairiel> i didnt say eliminate, i said reduce =p
[20:51:36 CET] <Daemon404> same diff
[20:51:37 CET] <nevcairiel> it only uses as much delay as it has to, not the maximum
[20:52:04 CET] <Daemon404> i mean... i feel like this should belong in, you know, ->delay
[20:54:56 CET] <wm4> does anything video even use ->delay
[20:54:59 CET] <Daemon404> nevcairiel, does libav codecpar simply entirely ignore the concept of codc delay
[20:55:05 CET] <nevcairiel> Daemon404: yes
[20:55:10 CET] <Daemon404> oh good
[20:55:20 CET] <Daemon404> wm4, it works sometimes, except when it doesnt, when you need has_b_frames
[20:55:22 CET] <nevcairiel> which imho was not the right decision, but what do i care what libav does
[20:55:24 CET] <Daemon404> except when that doesnt.
[20:55:34 CET] <Daemon404> nevcairiel, no i definitely need to know delay
[20:55:39 CET] <nevcairiel> i registered my complaints with them
[20:55:39 CET] <Daemon404> for frame accurate seeking
[20:55:43 CET] <nevcairiel> they ignored
[20:55:45 CET] <nevcairiel> so shrug
[20:55:51 CET] <Daemon404> i registered that multiple times with elenril
[20:56:03 CET] <Daemon404> maybe we can add some delay field to codecpar?
[20:56:10 CET] <Daemon404> makes more sense than bframes
[20:56:50 CET] <nevcairiel> naming and documentation can be whatever it wants, as long as it carries the has_b_frames info from  demux to decode ;)
[20:57:21 CET] <Daemon404> Plorkyeran, you may need to read this ^
[20:57:25 CET] <Daemon404> ffms2 uses this info.
[20:58:06 CET] <Daemon404> ubitux, tomorrow: me. you. one codecpar.
[20:58:37 CET] <ubitux> 20:58 <@Daemon404> ubitux, tomorrow: me. you. one.
[20:58:39 CET] <ubitux> wowowow
[20:58:49 CET] <Daemon404> >context
[20:59:28 CET] <wm4> but isn't has_b_frames determination in lavf quite unclean too?
[20:59:43 CET] <Daemon404> im sure it's all sorts of nuuty
[20:59:45 CET] <Daemon404> nutty
[21:00:13 CET] <nevcairiel> its not that bad, it just has a heuristic to guess how many frames it should decode to determine this value
[21:00:55 CET] <nevcairiel> which is also then used for dts/pts generation in raw streams, i think
[21:01:10 CET] <jamrial> Daemon404: isn't initial_padding the equivalent of avctx->delay?
[21:01:21 CET] <nevcairiel> but thats an audio-only field in codecpar
[21:01:34 CET] <jamrial> ah
[21:01:36 CET] <nevcairiel> (and a different meaning to the pts/dts delay he wants)
[21:01:50 CET] <Daemon404> nevcairiel, so it's pre-roll?
[21:02:21 CET] <wm4> it decodes frames to determine delay?
[21:02:46 CET] <nevcairiel> it could probably do the same by just parsing them, but it has to determine the re-ordering
[21:03:02 CET] <nevcairiel> and our parsers just arent that smart
[21:03:10 CET] <Daemon404> im not very concerned if it decodes or parsers
[21:03:23 CET] <Daemon404> realistically, we are not going to ever get away from needing to decode in lavf.
[21:06:32 CET] <wm4> good thing that "realistic" actually means "pessimistic"
[21:09:48 CET] <Daemon404> not really
[21:09:51 CET] <Daemon404> i dont think i'd want to remove it
[21:09:58 CET] <Daemon404> it's simply not feasible
[21:29:58 CET] <cone-807> ffmpeg 03Paul B Mahol 07master:c91b20c464b6: avfilter/vf_waveform: add subsampling input support for remaining filters
[21:40:33 CET] <Compn> arent we going to merge all the libs anyway? 
[21:40:37 CET] <Compn> :D
[21:41:48 CET] <Compn> lavc + lavf + lavu = VOLTRON
[21:46:17 CET] <cbsrobot> ubitux: ping
[21:46:28 CET] <ubitux> cbsrobot: pong
[21:46:45 CET] <cbsrobot> shoud I send you the subtitle file on your mail ?
[21:47:05 CET] <ubitux> sure, if you want
[21:47:46 CET] <Daemon404> kinky
[21:48:56 CET] <ubitux> ;)
[21:49:08 CET] <cone-807> ffmpeg 03Paul B Mahol 07master:959c7dad88b6: avfilter/vf_waveform: add graticule to aflat filter
[21:53:53 CET] <cbsrobot> ubitux: sent
[21:54:24 CET] <ubitux> the explanation is simple
[21:54:34 CET] <ubitux> tag is not closed, so it's not considered a tag
[21:54:58 CET] <ubitux> it should be improved though
[21:55:24 CET] <cbsrobot> I thought text shoud get rid of all the formatting
[21:55:41 CET] <ubitux> yes, as long as it considered it not text
[21:55:48 CET] <cbsrobot> or is there another way to get rid of all the formatting ?
[21:56:01 CET] <ubitux> but since the tag is not closed, it's probably not a tag, so it's text (that's the logic here probably)
[21:56:15 CET] <cbsrobot> ah
[21:56:21 CET] <ubitux> it works if you close the tag, right?
[21:56:54 CET] <cbsrobot> well in the ass file there is no <font> tag
[21:57:02 CET] <cbsrobot> so not sure where I shoud close it
[21:57:17 CET] <ubitux> wait wait
[21:57:38 CET] <ubitux> my bad then, that's not the bug
[21:58:35 CET] <cbsrobot> I thought it might be a bug becuase there are two styles in the ass file
[22:00:17 CET] <ubitux> forget what i said
[22:00:20 CET] <ubitux> i'll have a look
[22:02:37 CET] <cbsrobot> thanks
[22:59:50 CET] <cone-807> ffmpeg 03Michael Niedermayer 07master:92dfeb5c3100: avformat/wtvdec: Set AVFMTCTX_NOHEADER
[22:59:51 CET] <cone-807> ffmpeg 03Michael Niedermayer 07master:0ffa9e6ebae3: avformat/utils: Do not wait for more than 1 frame on attachments
[00:00:00 CET] --- Sun Mar 20 2016