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

[burek]

[00:21:39 CEST] <Daemon404> michaelni, likely related to the parser change
[00:21:51 CEST] <Daemon404> since ac3 and aac share a parser
[00:49:31 CEST] <michaelni> ubitux, is ticket 2397 worth a regression test (the sample is 2.5mb) codecpar makes that segfault (as i posted to ML already) while nothing in fate cought that
[01:04:50 CEST] <jamrial> michaelni: can't it be cut down a bit? it was created with ffmpeg after all
[01:06:56 CEST] <jamrial> use the same command used to create this 4 second sample (first comment in ticket) and make it 1 second or less, for example
[01:07:38 CEST] <jamrial> and see if it still segfaults with the current codecpar branch
[01:32:25 CEST] <ubitux> michaelni: since it's at least the 2nd time the regression happened, i'd say yes to some test for this
[01:55:48 CEST] <michaelni> jamrial, the subtitle display is close to the end of the file so just cutting its duration down wont result in a file with equal coverage
[01:56:12 CEST] <michaelni> also the previous problem with the file wasnt a segfault
[01:59:34 CEST] <michaelni> i think its no problem to upload the 2.5mb file we have quite a few files that are larger in there, i just always try to keep things small as it adds up
[03:25:54 CEST] <jamrial> lol, pastebin is using comic sans
[05:10:39 CEST] <Zeranoe> Anyone have a vector (SVG preferably) of the current FFmpeg logo?
[06:24:48 CEST] <Daemon404> michaelni, figured thsoe fate failures out. all of fate passes again, with assert-level=2,with your extra check for AV_CODEC_ID_NONE.
[06:31:08 CEST] <Daemon404> exit
[06:31:10 CEST] <Daemon404> woops
[06:31:33 CEST] <Daemon404> ubitux, can you look at that one remaining open problem? (the segfault michael showed you) tomorrow
[06:31:42 CEST] Action: Daemon404 sleep
[10:39:30 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:d38fe9f4930c: lavf/segment: support automatic bitstream filtering
[10:39:30 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:7524b678175e: lavc/audiotoolboxenc: remove unneeded packet metadata
[10:39:30 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:c820e600eac4: lavc/audiotoolboxenc: fix a number of config issues
[10:39:30 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:0667327f3fc7: lavc/audiotoolboxenc: fix iOS build
[10:39:30 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:36770d876937: lavc/audiotoolboxenc: allow setting maxrate with pre-10.9 deployment targets
[10:39:31 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:59a44923711b: lavc/audiotoolboxdec: support ADTS AAC input
[10:39:31 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:1b9e90ee80be: lavc/audiotoolboxdec: fix a number of config and timestamp issues
[10:39:32 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:b4daa2c40fb7: lavc/audiotoolboxdec: add eac3 decoder
[14:05:15 CEST] <kierank> I wonder how hard it is to write a simd crc
[14:07:58 CEST] <fritsch> kierank: http://www.drdobbs.com/parallel/fast-parallelized-crc-computation-using/229401411 <- that you already googled, right?
[14:08:23 CEST] <kierank> yeah but that's only a special crc
[14:08:27 CEST] <kierank> I was thinking more https://www-ssl.intel.com/content/dam/www/public/us/en/documents/white-papers/fast-crc-computation-generic-polynomials-pclmulqdq-paper.pdf
[14:11:07 CEST] <kierank> ah linux has one as well
[14:14:21 CEST] <kierank> probably a lut is faster
[16:24:45 CEST] <cone-609> ffmpeg 03Stefano Sabatini 07master:e8a9b644107a: lavu/base64: add AV_BASE64_DECODE_SIZE() macro
[17:05:32 CEST] <Daemon404> this parser stuff is pissing me off
[17:05:42 CEST] <Daemon404> or rather, ff_read_frame is
[17:05:58 CEST] <Daemon404> it changes codecpar info but only wants it carried over sometimes
[17:06:04 CEST] <Daemon404> what a piece of shit
[17:06:15 CEST] Action: Daemon404 may be getting a little grumpy/burnt out
[17:10:04 CEST] <Daemon404> michaelni, if you post regression can you please actually tell me where the sampels are
[17:10:13 CEST] <Daemon404> its a little tedious to have to hunt them down
[17:14:34 CEST] <wm4> pkt_timebase got to be one of the most broken shit things in libavcodec
[17:14:46 CEST] <wm4> setting it randomly messes with timestamps all over the place
[17:14:58 CEST] <wm4> but not setting it also means some required features are inaccessible
[17:15:21 CEST] <Daemon404> ... ac3-in-wav updates teh coded_id in read_packet
[17:15:27 CEST] <Daemon404> sigh
[17:15:32 CEST] <Daemon404> wav is not a NOHEADER format
[17:16:06 CEST] <wm4> PS: Libav does not have pkt_timebase! what a surprise!
[17:16:32 CEST] <wm4> why is everything so broken in ffmpeg
[17:17:19 CEST] <nevcairiel> pkt_timebase is actually useful
[17:17:30 CEST] <wm4> no it's not
[17:17:44 CEST] <nevcairiel> you have a bunch of pkt_ fields that carry timestamps, but no information what they actually are
[17:18:15 CEST] <wm4> timestamps are meant to be passed through, and libavcodec can't reasonably "fix" or determine timestamps anyway
[17:19:00 CEST] <nevcairiel> watch libav implement something similar, under a different name of course, when they start to care about preskip or tail padding
[17:19:19 CEST] <wm4> you don't need pkt_timebase to handle those
[17:19:38 CEST] <wm4> (I made sure of it)
[17:19:42 CEST] <Daemon404> ah.... fucking spdif
[17:25:44 CEST] <Daemon404> michaelni, fixed your sample, sendign a patch to master, since it was a bug in master.
[17:26:05 CEST] <Daemon404> p. sure
[17:26:28 CEST] <wm4> fixing FATE is often about bug compatibility with ffmpeg itself
[17:29:03 CEST] <durandal_170> source without copyright/license is unrelicensable?
[17:29:24 CEST] <wm4> durandal_170: no, source without information who wrote it is unlicensable
[17:29:27 CEST] <wm4> +re
[17:30:09 CEST] <durandal_170> you sure?
[17:31:03 CEST] <wm4> unless the author died over 70 years ago
[17:31:08 CEST] <Daemon404> (except in the USA)
[17:34:37 CEST] <durandal_170> so it can't be open sourced even its source code is available?
[17:35:05 CEST] <Daemon404> you cant legally use the code, indeed
[17:35:07 CEST] <Daemon404> technically.
[17:40:17 CEST] <Daemon404> nevcairiel, mind applying your two OK'd patches, or shall I?
[17:42:53 CEST] <wm4> ubitux: do you have a checklist for subtitle API changes somewhere? I'd like to add pts timebase handling to it
[17:47:05 CEST] <Daemon404> wm4, do you have time to look at the one outstanding regression (atm) with teh codecpar branch?
[17:47:08 CEST] <Daemon404> it's a segfault
[17:47:18 CEST] Action: Daemon404 actually has to be somewhere today unfortunately
[17:48:38 CEST] <wm4> I can try
[17:51:12 CEST] <Daemon404> thanks
[17:51:21 CEST] <Daemon404> i think i need a break today or im gonna burn out
[17:51:34 CEST] <Daemon404> but it still haunts me to leave it a day with no progress
[17:51:39 CEST] Action: Daemon404 is surely in a healthy mindset
[17:55:43 CEST] <wm4> time for me to get frustrated lol
[17:56:17 CEST] <nevcairiel> time for me to cook lasagna
[17:58:10 CEST] <nevcairiel> this whole codecpar concept is extremely fragile, previously it was easy, everything used the same context, and everything was working on the same data. now demuxers write into one struct, parsers read and write from another, and not even to speak of from the decoding during find_stream_info
[17:58:35 CEST] <wm4> Daemon404: what is failing? fate appears to pass
[17:58:53 CEST] <wm4> nevcairiel: you mean the old code was fragile, and now the shit is even more fragile
[17:59:06 CEST] <wm4> (because it needs to be compatible)
[17:59:12 CEST] <nevcairiel> right now its extreme shit because parsers dont fit into the design *at all* anymore
[17:59:21 CEST] <nevcairiel> this has shit to do with compatibility
[17:59:55 CEST] <Daemon404> wm4, look at the 2nd mail to the ML
[17:59:58 CEST] <Daemon404> from michael
[18:00:11 CEST] <Daemon404> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/192439.html
[18:00:16 CEST] <wm4> nevcairiel: parsers will be rewritten and everything will be bright and beautiful
[18:00:28 CEST] <wm4> except the parser API needs to be compatible too lol
[18:00:44 CEST] <wm4> ~/tickets/2397/242_4.mkv
[18:00:56 CEST] <wm4> michaelni: direct download http url for this?
[18:00:56 CEST] <Daemon404>  http://trac.ffmpeg.org/raw-attachment/ticket/2397/242_4.mkv
[18:01:04 CEST] <Daemon404> i already hunted it donwq
[18:01:04 CEST] <wm4> thanks
[18:01:24 CEST] <wm4> can reproduce
[18:02:05 CEST] <Daemon404> anyway i have a lunch to get to
[18:02:09 CEST] <Daemon404> bbl
[18:02:16 CEST] <Daemon404> patch for wav is on the ML
[18:04:15 CEST] <nevcairiel> strictly speaking, mpegts is violating the API by changing the codecid there, so maybe we should go all the way and just make mpegts also change it in the internal avctx? =p
[18:04:52 CEST] <nevcairiel> no funky random code in read_packet
[18:05:26 CEST] <Daemon404> up to yuo :P
[18:05:32 CEST] <Daemon404> code / patches welcome
[18:05:34 CEST] Action: Daemon404 brb
[18:06:53 CEST] <nevcairiel> i need to make myself a diagram how find_stream_infos dataflow actually works
[18:09:23 CEST] <wm4> it would be nice if we could somehow hide streams which are incomplete, but can become complete?
[18:09:31 CEST] <michaelni> Daemon404, do you still need some files ? i can upload any that arent online/easy findable ? 
[18:09:32 CEST] <wm4> because that would actually fix the API
[18:10:08 CEST] <wm4> (and I don't just mean during find_stream_info)
[18:10:53 CEST] <nevcairiel> wm4: in mpegts case, its not clear when its considered "complete"
[18:11:12 CEST] <nevcairiel> which is why its annoying
[18:11:24 CEST] <wm4> outside of find_stream_info, until all information that can be determined from the .ts is available
[18:11:32 CEST] <nevcairiel> in this case, we have st->request_probe, as long as thats positive, it could still change
[18:11:37 CEST] <wm4> I'm not sure how much that includes, maybe only codec_id?
[18:13:14 CEST] <nevcairiel> the problem cases are not streams which can be unquestionably identified, ie through a pmt mapping or such, but those streams that can't, say because we don't have their stream type in our mapping, or they are designed to use probing because they dont have an "official" stream type
[18:13:24 CEST] <wm4> request_probe is documented as "NOT PART OF PUBLIC API"
[18:13:38 CEST] <nevcairiel> i'm not concerned with public api at this point =p
[18:13:48 CEST] <wm4> true
[18:14:09 CEST] <ubitux> hi
[18:14:09 CEST] <wm4> a bit over that I see interleaver_chunk_size and interleaver_chunk_duration
[18:14:16 CEST] <wm4> not even a doxygen comment...
[18:14:45 CEST] <nevcairiel> with any luck there is a big banner somewhere that says that anything below is private
[18:14:46 CEST] <ubitux> Daemon404: mmh yeah i could have a look i guess
[18:15:11 CEST] <wm4> ubitux: AVSubtitle.pts is in AV_TIME_BASE, and pkt_timebase is used to convert the AVPacket.pts to it, all while the PGS decoder merely reorders pts (and not interpret it)
[18:15:13 CEST] <ubitux> wm4: no, no such list, but i think i mentioned it last time on the ml where there is some kind of rfc
[18:15:24 CEST] <wm4> nevcairiel: not for these fields
[18:15:57 CEST] <wm4> and if pkt_timebase is set, utils.c will make up a value for end_display_time
[18:16:03 CEST] <ubitux> wm4: pgs really reorder them?
[18:16:12 CEST] <wm4> yes
[18:16:14 CEST] <ubitux> i made ccaption dec do something similar iirc
[18:16:15 CEST] <nevcairiel> wm4:  * All fields below this line are not part of the public API. They
[18:16:16 CEST] <wm4> sometimes, rarely
[18:16:17 CEST] <nevcairiel> i see the banner
[18:16:26 CEST] <ubitux> (no reordering, just delay)
[18:16:30 CEST] <ubitux> need to push that patch btw
[18:16:34 CEST] <wm4> nevcairiel: oh ok, I got confused then
[18:16:41 CEST] <ubitux> wm4: you could make it compute the end duration in such case maybe?
[18:17:04 CEST] <wm4> ubitux: it tries to determine end_display_time from the packet duration
[18:17:07 CEST] <wm4> which is bogus
[18:18:45 CEST] <ubitux> wm4: before i look at this, any additional comment on the ccaption-dec patch and the pkt_timebase fallback for deprecated ass with timing thing?
[18:19:27 CEST] <ubitux> wm4: btw, you have a beginning of list/rfc at the end of this mail: http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/191059.html
[18:19:34 CEST] <ubitux> if you want to create a wiki page or whatever
[18:22:41 CEST] <wm4> ubitux: which captions patch?
[18:22:52 CEST] <ubitux> the one you tested the other day
[18:23:05 CEST] <wm4> ah
[18:23:15 CEST] <wm4> well that's a transition hack anyway?
[18:23:17 CEST] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/192260.html
[18:23:56 CEST] <ubitux> wm4: let's say it's a consistency correction and simplification instead :)
[18:34:32 CEST] <ubitux> anyway, going to push soon
[18:56:51 CEST] <wm4> Daemon404: fixed that crash, it was very lame
[18:57:16 CEST] <wm4> maybe something to look out for in other code when adding those anti deprecation guards
[19:12:26 CEST] <cone-609> ffmpeg 03Clément BSsch 07master:d8620158c7ec: lavc/ccaption_dec: remove usage of avctx->time_base
[19:12:27 CEST] <cone-609> ffmpeg 03Clément BSsch 07master:ffd1c3eeb704: lavc/utils: use pkt_timebase for legacy subtitles timing code
[19:16:48 CEST] <cone-609> ffmpeg 03Rick Kern 07master:780166947067: lavc/videotoolboxenc: Fix crash when closing codec after error
[19:16:49 CEST] <cone-609> ffmpeg 03Rick Kern 07master:c9ad357aeb6a: lavc/videotoolboxenc: Workaround encoder error
[20:36:35 CEST] <ubitux> wm4: so is there sth to fix in pgs?
[20:37:03 CEST] <wm4> no, with pgs I merely hit this awkward API artifact
[20:37:40 CEST] <wm4> see mpv commit 7089175d8d for all the cursing
[20:39:38 CEST] <ubitux> aren't you supposed to use av_codec_set_pkt_timebase()?
[20:40:12 CEST] <ubitux> btw, you have AV_TIME_BASE_Q
[20:42:02 CEST] <ubitux> anyway, what's left in codecpar?
[20:44:14 CEST] <JEEB> I think that one thing that michaelni found with ac3-in-wav
[20:44:31 CEST] <JEEB> oh, d404 did that already
[20:45:39 CEST] <ubitux> fate-vp6a-skip_alpha is failing for me
[20:45:55 CEST] <ubitux> fate-samples/flash-vp6/300x180-Scr-f8-056alpha.mov: No such file or directory
[20:46:07 CEST] <ubitux> my samples are rsync-ed thoug
[20:46:09 CEST] <ubitux> +h
[20:46:21 CEST] <wm4> oh, I thought it was uploaded?
[20:47:07 CEST] <ubitux> the flv is present
[20:47:13 CEST] <wm4> yeah, apparently it wasn't
[20:47:13 CEST] <JEEB> vp6 in mov o_O
[20:47:40 CEST] <wm4> for now you can: ffmpeg -i fate//flash-vp6/300x180-Scr-f8-056alpha.flv  -c copy -flags +bitexact fate/flash-vp6/300x180-Scr-f8-056alpha.mov
[21:01:25 CEST] <ubitux> ok so with this codecpar fate passes
[21:04:22 CEST] <nevcairiel> the whole codec id/parser topic is still rather ugly, i've been thinking about a cleaner solution  but its all iffy
[22:27:07 CEST] <jamrial> michaelni: if you haven't made one already, i have an oggopus fate test
[22:29:22 CEST] <cone-393> ffmpeg 03Rodger Combs 07master:44a9395b5acf: lavf/segment: style nit
[22:29:22 CEST] <cone-393> ffmpeg 03Rodger Combs 07master:5b4f44f66ae3: lavf/segment: slight refactor to seg_write_packet
[22:29:22 CEST] <cone-393> ffmpeg 03Rodger Combs 07master:4b150fbe1f39: lavf/segment: add option to write empty filler segments as needed
[22:48:26 CEST] <michaelni> jamrial, great, can you post a patch ? ill test on a few platforms 
[22:50:00 CEST] <jamrial> michaelni: sure
[22:55:17 CEST] <jamrial> michaelni: http://pastebin.com/raw/Y6vCbCzR the sample in base64 since it's small
[23:04:35 CEST] <jamrial> anyone else getting delivery error emails in korean about some nate.com address every time you send an email to ffmpeg-devel?
[23:07:26 CEST] <J_Darnley> No but then I haven't sent one in quite some time.
[23:26:20 CEST] <Daemon404> oh good i am tasked with fixing carl broken code for wav
[23:26:26 CEST] <Daemon404> even though i only want to move it
[23:26:33 CEST] <Daemon404> why was it let in in the first place then
[23:26:51 CEST] <Daemon404> and why does it fall on my plate, in order to "fix" codecpar (even though it just happens to kinda work in master)
[23:28:21 CEST] <michaelni> Daemon404, moving the ff_spdif_probe() to header is probably fine
[23:29:00 CEST] <Daemon404> which header?
[23:29:32 CEST] <michaelni> what your patch did mostly, just think it should be a function and not a macro
[23:29:49 CEST] <Daemon404> ok
[23:29:55 CEST] <Daemon404> that is fine
[23:30:10 CEST] <Daemon404> im running low on steam after soloing codecpar for week(s)
[23:32:32 CEST] <michaelni> could people please help Daemon404 with codecpar 
[23:32:46 CEST] <Daemon404> i saw wm4 and ubitux pushed some fixes oday
[23:44:02 CEST] <Daemon404> michaelni, new patch on ML.
[23:48:36 CEST] <cone-393> ffmpeg 03Hendrik Leppkes 07master:994412fb9b07: avcodec: properly initialize AVCodecParameters profile/level
[23:48:37 CEST] <cone-393> ffmpeg 03Hendrik Leppkes 07master:ce87711df563: exif: take a generic log context
[00:00:00 CEST] --- Sun Apr  3 2016