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

[burek]

[00:25:04 CEST] <cone-152> ffmpeg 03Muhammad Faiz 07master:6031e5d1af93: swresample/x86: add support for exact_rational
[04:32:40 CEST] <Zeranoe> I send a patch to the ML on the 18th and haven't heard anything. A few vocal people on my forum really want to use QSV, so I'd like to see this reviewed.
[04:32:51 CEST] <Zeranoe> sent*
[04:45:27 CEST] <jamrial> Zeranoe: looks like ivan uskov asked you to explain what you were trying to do in your original patch but instead you sent a different patch as reply (i guess addressing what he mentioned)
[04:46:14 CEST] <Zeranoe> jamrial: Ah, yeah, sorry for the confusion. I tried to reply to the other email with git, but something didn't work, clearly.
[04:46:40 CEST] <jamrial> i'd say to either do that, or ping the patch or re-send it as a new thread so it's more visible if it doesn't get a reply in a couple days
[04:47:34 CEST] <Zeranoe> Will do
[05:19:18 CEST] <cone-190> ffmpeg 03James Almer 07master:8b5b756c4d78: avformat/oggparsevorbis: use the base64 decode size macro
[05:19:18 CEST] <cone-190> ffmpeg 03James Almer 07master:afd04058bc91: avformat/oggparsevorbis: free base64 encoded data immediately after decoding it
[10:10:49 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:26cfafa52dfb: lavc/h264_slice: mark ref2frm as const pointers
[10:21:38 CEST] <ubitux> [dnxhd @ 0x23463a0] Application has requested 50 threads. Using a thread count greater than 16 is not recommended.
[10:21:40 CEST] <ubitux> u wat m8
[10:24:50 CEST] <cone-161> ffmpeg 03Anton Khirnov 07master:e06527952922: h264: remove an artificial restriction on the number of slice threads
[10:24:51 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:04aefe205b28: Merge commit 'e0652795292223f8bc8e5bac019c1fca7323d23c'
[10:42:21 CEST] <DHE> found a bug in the h264 decoder which reads free'd memory when the input is a little bit corrupted. (caught by valgrind)
[10:43:24 CEST] <DHE> the corruption is an mpegts stream which does not begin at a keyframe and is joined at an otherwise random point in time.
[10:45:20 CEST] <ubitux> i can not test #4977 anymore :((
[10:46:07 CEST] <nevcairiel> why not
[10:47:29 CEST] <ubitux> i get invalid data 
[10:50:34 CEST] <nevcairiel> well sure fuzzed samples can often fail earlier when new checks are otherwise added
[10:50:57 CEST] <nevcairiel> you can probably remove the single threading fallback and just make the check for #4977 bail out entirely
[10:51:06 CEST] <nevcairiel> unless that is actually a valid thing to encounter
[10:53:31 CEST] <ubitux> i'll probably use the nb_slice_ctx instead
[10:58:42 CEST] <ubitux> https://github.com/ubitux/FFmpeg/commit/135534dcf85c373e0c684fb9e27ba9fc0d3b8e3f
[10:58:47 CEST] <ubitux> michaelni, nevcairiel, comments on this ^ ?
[10:59:11 CEST] <nevcairiel> not sure changing nb_slice_ctx is a safe thing to do
[10:59:21 CEST] <nevcairiel> becxause it refers to the actual number of allocated contextx
[10:59:41 CEST] <nevcairiel> hm typing is failing today
[11:00:43 CEST] <nevcairiel> if this check is still needed, it probably requires keeping max_contexts
[11:01:47 CEST] <ubitux> afaiu, max_context was preventing a crash in h264_frame_start() in the linesize loop
[11:01:57 CEST] <ubitux> but now this loop is using nb_slice_ctx instead
[11:02:36 CEST] <ubitux> ah no my bad it was in decode_slice()
[11:02:41 CEST] <nevcairiel> max_contexts is still used to control how many slices are decoded in parallel
[11:02:53 CEST] <nevcairiel> and i dont think you can safely change nb_slice_ctx to do the same
[11:03:16 CEST] <nevcairiel> so if we still need/want the single thread fallback, max_contexts is probably needed still
[11:03:40 CEST] <ubitux> mh ok
[11:06:25 CEST] <ubitux> so what's the politic here? are we bailing out the whiole check or not?
[11:06:29 CEST] <ubitux> -i
[11:07:09 CEST] <nevcairiel> i would just not merge the commit and keep the check
[11:08:03 CEST] <nevcairiel> or as an alternative change the check to bail out entirely instead of using the single thread fallback, then you can get rid of that
[11:08:31 CEST] <nevcairiel> but i do not know if valid streams might use it
[11:13:20 CEST] <ubitux> i'll wait for michael's decision
[11:23:38 CEST] <ubitux> i'll skip it for now so i can make progress on the merge commits, but it would be nice if we could get rid of it
[11:29:46 CEST] <cone-161> ffmpeg 03Anton Khirnov 07master:e3c9041cfe2e: h264: allocate some tables per slice contexts, not threads
[11:29:47 CEST] <cone-161> ffmpeg 03Anton Khirnov 07master:2e5bde956519: h264: eliminate max_contexts
[11:29:48 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:dea0a2b69aef: Merge commit 'e3c9041cfe2e6526802255583d27abf9a921863e'
[11:29:49 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:2c0854f72453: Merge commit '2e5bde956519ae19cedfa482e199518e495bcaf5'
[11:31:58 CEST] <cone-161> ffmpeg 03Luca Barbato 07master:4012fe1ee819: ape: Unbreak adaptcoeffs computation
[11:31:58 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:93a0f4a3cbb8: Merge commit '4012fe1ee819edc7689e182189e66c5401fb4b41'
[11:32:51 CEST] <ubitux> heh
[11:33:04 CEST] <ubitux> and when i just merged all the h264 stuff a new storm arrives
[11:33:07 CEST] <ubitux> :(
[11:33:22 CEST] <nevcairiel> dont worry, there is one in between now and the new one as well
[11:36:20 CEST] <ubitux> yeah...
[11:36:29 CEST] <ubitux> i continue merging for now
[11:36:37 CEST] <ubitux> i'll stop at the next hard one :p
[11:36:54 CEST] <nevcairiel> should be smooth for a while now, i think
[11:37:02 CEST] <ubitux> yep
[11:37:47 CEST] <nevcairiel> just fully noop the current dxva2 fix, it would inrtoduce a warning and we already fixed it, btw .)
[11:38:39 CEST] <ubitux> yes
[11:38:47 CEST] <ubitux> that's exactly what i was doing
[11:38:58 CEST] <cone-161> ffmpeg 03Martin Storsjö 07master:39cdbb12aa21: dxva2_h264: Unbreak compilation after 3176217c6
[11:38:59 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:28dcf1870660: Merge commit '39cdbb12aa2140520246bc4c3e22436b9f8a121a'
[11:39:13 CEST] <nevcairiel> :) just figured i would say something since dxva2 is not in your area of expertise, or testability
[11:39:46 CEST] <ubitux> sure
[11:40:03 CEST] <ubitux> i remember fixing that chunk actually since the issue was raised
[11:56:01 CEST] <michaelni> ubitux, i cant find a file failing with 135534dcf85c373e0c684fb9e27ba9fc0d3b8e3f
[11:57:10 CEST] <ubitux> michaelni: check 2c0854f72453270e958c07b4e886f9f5323cd899
[11:59:12 CEST] <ubitux> do we want to pick 6eb2505855fa832ba7d0a1c2fb9f92c41c5446e3 or keep the fixes from 139cbeb75e0f5e3176b2b09660d2570b1bcc2408 ?
[11:59:20 CEST] <ubitux> i feel like it should be a noop
[12:10:02 CEST] <michaelni> if keeping it doesnt cause a problem it seem keeping makes more sense
[12:10:28 CEST] <ubitux> alright
[12:11:40 CEST] <ubitux> michaelni: btw, the first h264 wave is done, so if you want to patchup things in the decoder (such as dropping max_contexts or do the sei things you were talking last time), now is the time :p
[12:11:56 CEST] <ubitux> there are 2 more waves in the libav history, and more to come
[12:13:55 CEST] <ubitux> (mmh maybe that wasn't sei, i don't remember which thing you were mentioning in one of the previous merge)
[12:14:34 CEST] <ubitux> 2016-06-12 12:35:04     michaelni       ubitux, maybe, i had first changed the return and then fixed the order, the return 0 may be unneeded. It was a try because the calling code skips later SEI if one fails 
[12:14:36 CEST] <ubitux> 2016-06-12 12:36:10     michaelni       (that skip later on fail should be revisited as it doesnt seem optimal and trivial to change) but thats unrelated 
[12:14:38 CEST] <ubitux> ah, this ^
[12:19:02 CEST] <cone-161> ffmpeg 03Vittorio Giovara 07master:6eb2505855fa: dds: Drop gray-alpha swapping
[12:19:03 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:c8b0d2eb8cba: Merge commit '6eb2505855fa832ba7d0a1c2fb9f92c41c5446e3'
[12:20:50 CEST] <ubitux> michaelni: can you upload dds/fate_monob.dds in fate from libav?
[12:20:56 CEST] <ubitux> (don't we have a sync script?)
[12:23:02 CEST] <michaelni> some files differ i think so autosync is trickier
[12:23:33 CEST] <ubitux> ok
[12:28:24 CEST] <michaelni> ubitux, uploaded
[12:28:42 CEST] <ubitux> thanks!
[12:29:34 CEST] <ubitux> some fate instances will fail for a while due to missing sample but i don't want to delay the merges
[12:29:39 CEST] <ubitux> is that ok?
[12:43:34 CEST] <michaelni> ubitux, ok
[12:44:15 CEST] <ubitux> alright, thanks
[12:44:29 CEST] <cone-161> ffmpeg 03Vittorio Giovara 07master:4b2e69397b84: dds: Add support for monochrome images
[12:44:30 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:f36fcf7b6cc4: Merge commit '4b2e69397b84d1c1a29ffae6e9f106f2c32b1869'
[12:51:13 CEST] <cone-161> ffmpeg 03Diego Biurrun 07master:5b1409c75563: fate: Add test for MSS1
[12:51:14 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:7cf4b442cebd: Merge commit '5b1409c75563b4a3aca113c34d09e3b5442de47f'
[13:01:17 CEST] <cone-161> ffmpeg 03Diego Biurrun 07master:f2422b58756b: testprogs: Mark some tables as static const
[13:01:18 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:5605c1b3c025: Merge commit 'f2422b58756ba97e3cbadc190f1ed950aa201ec7'
[13:04:49 CEST] <cone-161> ffmpeg 03Michael Niedermayer 07master:366ba2dee1f2: mmaldec: Use av_assert0() instead of assert()
[13:04:50 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:b5f9f16582d9: Merge commit '366ba2dee1f2b17825b42e2164d3b9879f0271b1'
[13:06:19 CEST] <cone-161> ffmpeg 03Julian Scheel 07master:2689bb115ca6: mmaldec: Fix avpriv_atomic_get usage
[13:06:20 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:5ffbfe38a5d1: Merge commit '2689bb115ca64921789092148deaf213a0d94d2e'
[13:19:01 CEST] <cone-161> ffmpeg 03Julian Scheel 07master:d52208e8d549: mmaldec: Add mpeg2 decoding support
[13:19:02 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:c824c3c47ca6: Merge commit 'd52208e8d549d4c84a2a348aa3790b1a177e779a'
[13:20:50 CEST] <cone-161> ffmpeg 03wm4 07master:9a382f363950: mmaldec: add vc1 decoding support
[13:20:51 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:93c75640c9ce: Merge commit '9a382f363950c0aab1500aa0937f73bf4dde9ee3'
[13:21:28 CEST] <cone-161> ffmpeg 03wm4 07master:46aaad78c3cf: mmaldec: correct package buffering accounting
[13:21:29 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:a92efb5987b0: Merge commit '46aaad78c3cf03d43e7c9ca1d4a8b8a71fb0527d'
[13:22:16 CEST] <cone-161> ffmpeg 03wm4 07master:ce589940c2ca: mmaldec: send only a single EOS packet on flushing
[13:22:17 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:4db44ea76ee6: Merge commit 'ce589940c2cac936891e8bba275580d6efc41e8b'
[13:23:47 CEST] <cone-161> ffmpeg 03wm4 07master:84bba3684687: configure: fix mmal build dependencies
[13:23:48 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:7f2626ccda41: Merge commit '84bba36846870c6269732351c022eeef094c6c83'
[13:24:46 CEST] <cone-161> ffmpeg 03wm4 07master:45a954f5aa35: mmaldec: print the MMAL format FourCC automatically
[13:24:47 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:a826ffb82954: Merge commit '45a954f5aa35161a741fffd6c8bb92e9f91a1720'
[13:34:16 CEST] <cone-161> ffmpeg 03wm4 07master:74beead9bd59: mmaldec: limit internal buffering
[13:34:17 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:ba5100ce8464: Merge commit '74beead9bd596180bcac6108548fc0a86d8eb4ae'
[13:35:26 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:d16aefee5cf3: lavc/mmaldec: reduce some diffs with Libav missed in previous skipped merges
[13:36:21 CEST] <cone-161> ffmpeg 03wm4 07master:33ac77e850ef: mmaldec: autodetect by default
[13:36:22 CEST] <cone-161> ffmpeg 03Janne Grunau 07master:c26741332165: Revert "mmaldec: autodetect by default" since it breaks linking on systems without mmal libraries
[13:36:23 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:60e862c91f1d: Merge commit '33ac77e850efdfd0e8835950c3d947baffd4df45'
[13:36:24 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:59fced9e2695: Merge commit 'c26741332165a049717e6da84db13a24ee8edade'
[13:40:25 CEST] <cone-161> ffmpeg 03Martin Storsjö 07master:33b83d89e372: rtpdec_vp9: Make sure to free the temp buffer on close
[13:40:26 CEST] <cone-161> ffmpeg 03Martin Storsjö 07master:70c77fdfc107: rtpdec_vp9: Update header parsing to spec draft 02
[13:40:27 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:d5fb087e03aa: Merge commit '33b83d89e3720aecc60b4df3d8021cbc5780dd91'
[13:40:28 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:c281028c4d48: Merge commit '70c77fdfc1076fd7f6cd20079237ddc97e1a10bc'
[13:42:06 CEST] <cone-161> ffmpeg 03Martin Storsjö 07master:b55e3633d3f6: rtpdec: Use AVERROR_PATCHWELCOME instead of AVERROR(ENOSYS) for unimplemented features
[13:42:07 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:4e637eb54dce: Merge commit 'b55e3633d3f60cf0f51269f25936409b79d2729e'
[13:43:24 CEST] <cone-161> ffmpeg 03Martin Storsjö 07master:943f4bea37dc: rtpdec_h264: Use avpriv_report_missing_feature instead of a manual av_log
[13:43:25 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:f17c65ed83e2: Merge commit '943f4bea37dc8d510d2f43c0bbe0df59c9b34768'
[13:44:18 CEST] <cone-161> ffmpeg 03Martin Storsjö 07master:375cad096565: rtpdec_vp9: Support parsing the scalability structure
[13:44:19 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:2c2957e23f61: Merge commit '375cad096565b0796df2a307faae7619766f7c49'
[13:45:52 CEST] <ubitux> michaelni: can you upload mts2/ScreenCapture.xesc?
[14:01:45 CEST] <michaelni> ubitux, done
[14:01:54 CEST] <ubitux> thanks
[14:03:06 CEST] <michaelni> anything else i should upload ? 
[14:06:05 CEST] <ubitux> michaelni: maybe samples in the magy directory
[14:06:10 CEST] <ubitux> (see cc58656aca95b5ab517989a9524b9a2b1c5653cf)
[14:06:43 CEST] <ubitux> and duck/tr20* 
[14:06:50 CEST] <ubitux> (see 523c4c5b70994f5cd1f192b68d07cf24b292ca05)
[14:07:14 CEST] <ubitux> i don't see anything else in git log -p -GSAMPLES ..libav/master
[14:11:14 CEST] <michaelni> ubitux, uploaded
[14:11:20 CEST] <ubitux> thanks
[14:15:10 CEST] <cone-161> ffmpeg 03Diego Biurrun 07master:1982d0cc5619: fate: Add test for MTS2/MSS4
[14:15:11 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:72ed8d8bd2e4: Merge commit '1982d0cc561912d685a0c2dbe58bc19f50bae231'
[14:18:32 CEST] <ubitux> michaelni: re: e630ca511 can you confirm me that 64 is actually valid?
[14:18:54 CEST] <ubitux> i'm asking because 74d98d1b0 seems to use >= 64 as exception
[14:22:01 CEST] <cone-161> ffmpeg 03Matthieu Bouron 07master:0cd5e281df3f: lavc/mediacodecdec_h264: use ff_h264_decode_extradata to extract PPS/SPS
[14:22:16 CEST] <michaelni> ubitux, if i knew in which spec to look ...
[14:22:23 CEST] <ubitux> :(
[14:23:00 CEST] <ubitux> michaelni: ok to replace with a >=?
[14:23:11 CEST] <ubitux> or you're afraid of breaking samples?
[14:29:20 CEST] <michaelni> ok to replace with a >=
[14:29:25 CEST] <michaelni> ubitux, ^
[14:29:36 CEST] <ubitux> alright, thanks
[14:29:53 CEST] <ubitux> i'll adjust the error message to request samples in the other cases as well
[14:40:27 CEST] <nevcairiel> ubitux: bit(8) timeStampLength; // must be less than 64
[14:40:40 CEST] <nevcairiel> 14496-1, 10.2.2
[14:40:50 CEST] <nevcairiel> or 10.2.3.1 for the syntax table
[14:41:31 CEST] <ubitux> thanks!
[14:41:48 CEST] <ubitux> nevcairiel: what about ocr and au len?
[14:41:56 CEST] <ubitux> the two following values
[14:41:57 CEST] <nevcairiel> less then 64, less then 32
[14:42:03 CEST] <ubitux> perfect, thanks
[14:43:05 CEST] <ubitux> so i'm not keeping the request for sample
[14:43:10 CEST] <michaelni> ubitux, need to go afk, will be back in a few hours
[14:43:17 CEST] <ubitux> sure
[14:43:44 CEST] <nevcairiel> hm i should really find a newer version of 14496-1
[14:44:02 CEST] <nevcairiel> mine is from like 1998
[14:46:16 CEST] <funman> what about https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.264-201602-I!!PDF-E&type=items ?
[14:46:36 CEST] <nevcairiel> thats another document entirely
[14:47:53 CEST] <nevcairiel> 14496-1 is systems, ie. container, not video
[14:49:14 CEST] <cone-161> ffmpeg 03Luca Barbato 07master:74d98d1b0e0e: mpegts: Validate the SL Packet Header Configuration
[14:49:15 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:82439dec0fbf: Merge commit '74d98d1b0e0e7af444c933ea3c472494de3ce6f2'
[14:52:26 CEST] <ubitux> "Drop pointless assert.h #includes"
[14:52:30 CEST] <ubitux> -#include "libavutil/avassert.h"
[14:52:35 CEST] <ubitux> that's not assert.h :(
[14:53:30 CEST] <durandal_170> heh, why do you care?
[14:53:52 CEST] <ubitux> because i'm merging it
[14:54:30 CEST] <durandal_170> it is just wrong log message
[14:54:53 CEST] <ubitux> yeah but i was only checking the assert() until i actually read the diff
[14:55:18 CEST] <durandal_170> keep our asserts
[14:56:04 CEST] <durandal_170> extra headers are irrelevant
[14:58:44 CEST] <ubitux> ofc i'm keeping them
[14:58:58 CEST] <ubitux> i'm just checking if the includes are still needed in every file changed
[15:26:19 CEST] <cone-161> ffmpeg 03Diego Biurrun 07master:0f40c9098498: Drop pointless assert.h #includes
[15:26:20 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:c01f1157acbe: Merge commit '0f40c9098498ad90dbbd2380eb4269015e84bde4'
[15:32:11 CEST] <cone-161> ffmpeg 03Diego Biurrun 07master:015c2d923902: libopencore-amr: Fix ff_dlog()/av_log() invocations
[15:32:12 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:14762dd3f3bb: Merge commit '015c2d923902fcd562571993eaf1231ce388c7f0'
[15:33:19 CEST] <ubitux> should i merge 5f1c3cbd524728317bf460259aa8f3ef5ec935c6?
[15:36:02 CEST] <ubitux> oh well, the interested parties will put it back if needed
[15:36:29 CEST] <cone-161> ffmpeg 03Diego Biurrun 07master:5f1c3cbd5247: vaapi: Drop pointless debug output
[15:36:30 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:d12cce3fb25e: Merge commit '5f1c3cbd524728317bf460259aa8f3ef5ec935c6'
[15:38:52 CEST] <cone-161> ffmpeg 03Diego Biurrun 07master:c11c693accaa: h264: Drop broken trace debug output
[15:38:53 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:3801060cd028: Merge commit 'c11c693accaad65d3f4afa44c27f2338a2e3bf8f'
[15:39:32 CEST] <mateo`> merging spree ~~
[15:42:46 CEST] <cone-161> ffmpeg 03Alexandra Hájková 07master:5c31eaa9998b: Remove unnecessary get_bits.h #includes and add missing headers where needed.
[15:42:47 CEST] <cone-161> ffmpeg 03Clément BSsch 07master:9204a8499808: Merge commit '5c31eaa9998b2185e0aa04d11adff128498dc14a'
[15:48:27 CEST] Action: mateo` taking a look at the videotoolbox hwaccel regression
[15:49:43 CEST] <ubitux> omfg 41ed7ab45 ffs
[15:51:37 CEST] <nevcairiel> a certain developer makes everyones life so much more fun :p
[15:57:39 CEST] <ubitux> reminds me when someone wanted to stack them until there was enough to justify a commit
[16:15:27 CEST] <ubitux> http://sprunge.us/fJDI :(
[16:16:29 CEST] <nevcairiel> majority applied as is, not too bad
[16:17:50 CEST] <ubitux> "The input is 15-bit" ’ "The input is 15 bits" oh god they did that all over the place
[16:18:39 CEST] <ubitux> and then "Input is either 8-bits width" ’ "Input is either 8-bit width"
[16:18:51 CEST] <ubitux> i'm not sure to get the logic
[16:19:01 CEST] <nevcairiel> lo-what?
[16:21:21 CEST] <BtbN> Why do people even care to fix all these in that way?
[16:23:17 CEST] <nevcairiel> who knows what drives some people
[16:35:59 CEST] <mateo`> I found the source of the videotoolbox regression, the sps/pps data now carry the nal type byte
[16:40:23 CEST] <nevcairiel> all NALs do
[16:40:44 CEST] <ubitux> they didn't before
[16:40:47 CEST] <ubitux> apparently
[16:40:56 CEST] <nevcairiel> internal api is not documented to be stable :p
[16:41:12 CEST] <nevcairiel> but no, this is a new thing
[16:41:50 CEST] <nevcairiel> this allows using a generic parser for h264 and hevc, as the nal type interpretation is different
[16:43:27 CEST] <ubitux> is the construction of the extradata still correct btw?
[16:43:39 CEST] <mateo`> ok (currently working on the fix)
[17:01:47 CEST] <atomnuker> avctx->thread_count is guaranteed to never change during runtime, right?
[17:07:28 CEST] <durandal_170> nope
[17:28:12 CEST] <ubitux> atomnuker: not sure what's the political nowadays wrt to hwaccel software fallback
[17:29:05 CEST] <nevcairiel> changing thread count was never supported for that
[17:43:00 CEST] <atomnuker> hwaccel? nope, I just need to have a per-thread buffer in my decoder
[17:56:18 CEST] <mateo`> rkern: the videotoolbox hwaccel regression is fixed, i've sent the patch to the ml
[17:57:54 CEST] <ubitux> mailman slow again?
[17:58:26 CEST] <mateo`> I wonder, the patch hasn't reached the ml yet :(
[18:00:11 CEST] <rkern> mateo`: I'll try it without my last patch too. Sounds like you fixed the root cause.
[18:01:44 CEST] <mateo`> in case it doesn't reach the ml soon, here is the patch http://sprunge.us/PDhP
[18:03:18 CEST] <mateo`> rkern: ^
[18:03:38 CEST] <rkern> ok, checking it out
[18:42:42 CEST] <rkern> mateo`: works well on OS X. It's probably fine on iOS too - I'm working on something to test, but the decoder inits (didn't before).
[20:19:40 CEST] <ubitux> -    { { 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x05,0x00,0x00 }, 14,   AV_CODEC_ID_RAWVIDEO }, /* Uncompressed Picture */
[20:19:42 CEST] <ubitux> +    { { 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x05,0x00,0x00 }, 14,   AV_CODEC_ID_RAWVIDEO }, /* uncompressed picture */
[20:19:46 CEST] <ubitux> its kinda ridiculous sometimes
[20:20:11 CEST] <thardin> welcome to the wonderful world of mxf
[20:20:37 CEST] <thardin> would you like your cyanide pill now or later?
[20:20:38 CEST] <ubitux> not related to mxf
[20:20:48 CEST] <ubitux> my comment was about the change in... the comment.
[20:22:13 CEST] <llogan> Must have much free time on their hands, and highly motivated for the inane.
[20:22:17 CEST] <thardin> wait, there was a patch changing only that?
[20:22:38 CEST] <thardin> I'm not caught up on the account I have the ML on
[20:22:50 CEST] <ubitux> thardin: no, there was a patch changing many things like that
[20:23:17 CEST] <llogan> on ffmpeg-devel or from Libav?
[20:24:12 CEST] <ubitux> the next commit i'm merging
[20:25:13 CEST] <thardin> my gut feeling says diego
[20:25:32 CEST] <thardin> oh, and the Capitalization is likely from the standard
[20:26:23 CEST] <ubitux> not Diego
[20:27:48 CEST] <durandal_170> ubitux: working on codec?
[20:28:20 CEST] <durandal_170> I meant kierank, sorry
[20:28:53 CEST] <kierank> ?
[20:28:53 CEST] <kierank> no
[20:31:50 CEST] <durandal_170> kierank: no more RE from you?
[20:32:39 CEST] <kierank> no, too much IRL stuff
[20:32:56 CEST] Action: llogan blames Brexit
[21:19:52 CEST] <ubitux> Timothy_Gu: can you check 41ed7ab for updates in https://trac.ffmpeg.org/wiki/ViterbiAlgorithm ?
[21:20:21 CEST] <ubitux> https://git.libav.org/?p=libav.git;a=blobdiff;f=doc/viterbi.txt;h=712fc4b150da309d47bfd6db04a1a568c801fa38;hp=97825462ccf0f36f41e44b159c3ff3ee73b1f961;hb=41ed7ab;hpb=5c31eaa9998b2185e0aa04d11adff128498dc14a
[21:27:36 CEST] <cone-314> ffmpeg 03Aman Gupta 07master:373b82066cd4: avformat/mpegts: include stream type for aac
[21:36:51 CEST] <ubitux> alright i think i'm done with the cosmetic merge
[21:36:57 CEST] <ubitux> what a waste of time...
[21:56:21 CEST] <cone-314> ffmpeg 03Vittorio Giovara 07master:41ed7ab45fc6: cosmetics: Fix spelling mistakes
[21:56:22 CEST] <cone-314> ffmpeg 03Clément BSsch 07master:8ef57a0d6154: Merge commit '41ed7ab45fc693f7d7fc35664c0233f4c32d69bb'
[22:00:44 CEST] <cone-314> ffmpeg 03Diego Biurrun 07master:def03d14687b: vf_frei0r: Drop overly verbose and broken debug output
[22:00:45 CEST] <cone-314> ffmpeg 03Clément BSsch 07master:d0d9dbec2fcb: Merge commit 'def03d14687b9d089950ba8e45083e666de4eb68'
[22:04:43 CEST] <cone-314> ffmpeg 03Diego Biurrun 07master:1f1ad8ace040: configure: Document --enable-libfontconfig
[22:04:43 CEST] <cone-314> ffmpeg 03Clément BSsch 07master:ea80e90e134c: Merge commit '1f1ad8ace040a08edc2646ff638ca42a8828779f'
[22:10:43 CEST] <cone-314> ffmpeg 03Diego Biurrun 07master:5afb94c817ab: Mark read-only tables as static
[22:10:44 CEST] <cone-314> ffmpeg 03Clément BSsch 07master:8df1dbd7980a: Merge commit '5afb94c817abffad030c6b94d7003dca8aace3d5'
[22:11:39 CEST] <cone-314> ffmpeg 03Martin Storsjö 07master:e9443105ea4e: avio: Remove a leftover comment
[22:11:40 CEST] <cone-314> ffmpeg 03Clément BSsch 07master:e276f21f995c: Merge commit 'e9443105ea4e8bc1d826ddceeba2816488c6ce92'
[22:13:55 CEST] <cone-314> ffmpeg 03Michael Niedermayer 07master:283226e11ccf: simple_idct_template: Fix strict aliasing violation
[22:13:55 CEST] <cone-314> ffmpeg 03Clément BSsch 07master:363d4a0e65a7: Merge commit '283226e11ccf50a71d25d150fbbf1743f74c6c49'
[22:16:52 CEST] <cone-314> ffmpeg 03Jan Ekström 07master:1f77e634bb83: colorspace: Add support for BT709
[22:16:53 CEST] <cone-314> ffmpeg 03Clément BSsch 07master:e4c07dc4b7e7: Merge commit '1f77e634bb838f71ff21923b5e9fe3104c831c52'
[22:18:56 CEST] <ubitux> JEEB: merging 885a9d6 currently, they changed the use of "colorimetry" into "colorspace"
[22:18:58 CEST] <ubitux> what do you prefer?
[22:19:23 CEST] <ubitux> (i'll go for colorspace to keep diff small if you don't reply soon, but i can change it later)
[22:19:51 CEST] <JEEB> colorspace is OK so you can keep the diff small, I think koda also raised his eyebrows at the "colorimetry" wording :)
[22:20:00 CEST] <JEEB> so it might actually be more correct even
[22:20:22 CEST] <ubitux> ok
[22:20:25 CEST] <ubitux> thx
[22:22:22 CEST] <cone-314> ffmpeg 03Jan Ekström 07master:885a9d608731: pgssub: Fix subpicture colorspace and range
[22:22:23 CEST] <cone-314> ffmpeg 03Clément BSsch 07master:475a686a0157: Merge commit '885a9d6087315a85d98f7e89656ef01dc7104c4c'
[22:23:35 CEST] <cone-314> ffmpeg 03Mark Thompson 07master:0c1d66a07917: avconv_vaapi: fix double-free with some unsupported streams
[22:23:36 CEST] <cone-314> ffmpeg 03Clément BSsch 07master:91450cda2ee1: Merge commit '0c1d66a07917602303f129f5a5651faeec2415d5'
[22:25:34 CEST] <cone-314> ffmpeg 03Martin Storsjö 07master:9ea78fd00a49: rtpdec: Always check if we have the next packet queued
[22:25:36 CEST] <cone-314> ffmpeg 03Clément BSsch 07master:4873952f886b: Merge commit '9ea78fd00a49f0691c1a5134eb59d4e5bb380a2a'
[22:26:50 CEST] <cone-314> ffmpeg 03Martin Storsjö 07master:bc2a32969eb4: rtsp: Parse SSRC attributes in the SDP
[22:26:51 CEST] <cone-314> ffmpeg 03Clément BSsch 07master:00e122bc0f2a: Merge commit 'bc2a32969eb4db17677971def5ad5b936d9d1648'
[22:42:40 CEST] <cone-314> ffmpeg 03Diego Biurrun 07master:b7e64fba7f37: Reduce the scope of some variables
[22:42:41 CEST] <cone-314> ffmpeg 03Clément BSsch 07master:a4403e49b93a: Merge commit 'b7e64fba7f37cc0399beae844f0a5dbef9219376'
[22:42:52 CEST] <ubitux> psnr() is deprecated in libav?
[22:44:02 CEST] <ubitux> ok i'm tired.
[22:44:30 CEST] <ubitux> anyone is free to take over the merge effort for the next 20 hours or so
[22:46:13 CEST] <ubitux> still 200+ commits to merge btw
[22:47:43 CEST] <Illya> ubitux: D: Good Luck!
[22:47:59 CEST] <ubitux> you missed the important part while away
[22:48:06 CEST] <ubitux> 22:44 <@ubitux> ok i'm tired.
[22:48:09 CEST] <ubitux> 22:44 <@ubitux> anyone is free to take over the merge effort for the next 20 hours or so
[22:48:49 CEST] <Illya> That is some quite critical information :)
[22:49:05 CEST] <CFS-MP3> hi... not trying to start a flamewar, but I'm going to start on ffmpeg development so I'm looking for a recommendation for the development environment
[22:49:25 CEST] <CFS-MP3> probably what I typically use is just to going to cut it for such a large code base
[22:49:33 CEST] <Illya> CFS-MP3 what do you normally use?
[22:50:12 CEST] <CFS-MP3> Illya Visual Studio... not out of love but because Windows compatibility is important for most of my projects...
[22:50:39 CEST] <JEEB> CFS-MP3: you can build FFmpeg with MSVC but MSVS is not the build system
[22:51:12 CEST] <Illya> Hmm. I'm not too familiar with stuff on the windows side, you could try sublime text maybe?
[22:51:12 CEST] <JEEB> I think unless you are building something MSVC specific you will want to have a VM with a modern lunix distro on it
[22:51:25 CEST] <CFS-MP3> JEEB I prefer to just use whatever is going to make my life easier rather than use what I use for other things just because I'm using it for other things :-)
[22:51:50 CEST] <Illya> JEEB: using a linux VM will definitely make your life easier, if you have the computing power for ti
[22:51:52 CEST] <Illya> it*
[22:51:52 CEST] <CFS-MP3> Illya I'm OK with linux, I mean I use VS most of the time because that's what I need for other things, but for ffmpeg I can use anything else
[22:52:06 CEST] <JEEB> CFS-MP3: if you want ease of development, grab either fc24 or ubuntu16.04 and install it into a VM with enough RAM
[22:52:21 CEST] <JEEB> install base development packages (build-essential and valgrind and git)
[22:52:28 CEST] <JEEB> and off you go
[22:52:48 CEST] <JEEB> windows build times (or more like, configuration times) are just out the charts
[22:52:48 CEST] <Illya> CFS-MP3: I think most people use a text editor + debugger
[22:52:56 CEST] <JEEB> and valgrind is a godsend
[22:53:10 CEST] <JEEB> unless you're developing something specific to windows, that is
[22:53:16 CEST] <CFS-MP3> JEEB And what IDE? Such vim for example? Looks like not ideal to browse the code tree
[22:53:36 CEST] <Illya> CFS-MP3: you generally wouldnt be editing the whole tree at once though
[22:53:37 CEST] <nevcairiel> the only thing alow on windows is configure, and you really dont need to run that very often when just developing
[22:53:39 CEST] <llogan> i should close all ffserver tickets as "won't fix"
[22:53:49 CEST] <nevcairiel> so working on windows is fine if you're use dto all the tools there
[22:53:51 CEST] <JEEB> llogan: ^5
[22:54:11 CEST] <JEEB> CFS-MP3: when you are developing within FFmpeg you don't tend to need too much, although you can get clang-based add-ons for sublime text or atom or visual studio code
[22:54:22 CEST] <JEEB> pick  your own poison, or even vim with YouCompleteMe
[22:54:35 CEST] <JEEB> like, whatever lets you develop well enough, stick with that
[22:54:39 CEST] <Illya> CFS-MP3: I use emacs, vim works as well, and I have used sublime text in the past, but generally, just pick a text editor.
[22:54:48 CEST] <Illya> Yeah, JEEB has the right idea
[22:55:11 CEST] <JEEB> if you really need an IDE, there's Qt Creator. Made for C++ but kind of works for C as well
[22:55:33 CEST] <JEEB> plus I remember poking it so that it called a non-qmake build system from it
[22:55:43 CEST] <JEEB> although I have no recollection of that whatsoever any more
[22:55:46 CEST] <CFS-MP3> JEEB I find that vim is great when you know the tree really well, but when you are just looking around, it's not so good. I mean, things like selecting a function and finding all references is essential (for me, anyway) when learning the internals of any large program
[22:56:52 CEST] <JEEB> CFS-MP3: the thing is, if I'm making a decoder I know I'm in libavcodec, if I'm making a demuxer I'm in libavformat. If I'm fixing something I can usually git grep for a function since it shouldn't be called/defined in too many places
[22:57:07 CEST] <Illya> You could also look at the eclipse IDE. There's a guide which is probably a little (although probably very) outdated: https://trac.ffmpeg.org/wiki/How%20to%20setup%20Eclipse%20IDE%20for%20FFmpeg%20development
[22:57:12 CEST] <JEEB> but as I said, if you want a "real" IDE there's Qt Creator. Your Mileage May Vary
[22:59:10 CEST] <CFS-MP3> JEEB you know all that but I don't :-) that's my point. Anyway I'll give Qt Creator a go and see how it works for me :-) Thanks
[23:01:15 CEST] <nevcairiel> I never liked Qt Creater, Visual Studio Code works fine for me on linux, but I prefer to stick to windows instead of switching to linux just  for ffmpeg dev
[23:01:46 CEST] <JEEB> to each his own :)
[23:03:34 CEST] <wbs> JEEB: you tried replacing ism_offset with some proper avconv/ffmpeg options, right? would you care to look those up and reply with them to the ism_offset patch that was sent to the list
[23:03:43 CEST] <wbs> the ism_offset patch is a huge hack and should not be upstreamed
[23:03:56 CEST] <wbs> (I'd be ashamed to have that upstreamed with my name on it)
[23:04:35 CEST] <JEEB> wbs: yeah I should when I get to looking at that. but I do remember getting alright results with the negative timestamp enabler + ts_offset
[23:04:39 CEST] <JEEB> IIRC
[23:04:52 CEST] <JEEB> or actually, I should just grep the logs
[23:05:00 CEST] <JEEB> somewhere during the last N months
[23:06:26 CEST] <CFS-MP3b> I'm preparing a VM With Ubuntu for ffmpeg development... 32, 64 bits or doesn't matter?
[23:06:45 CEST] <JEEB> 64bit is generally better
[23:13:47 CEST] <CFS-MP3b> fflogger I read that but my relationship with Eclipse is complicated
[23:14:30 CEST] <jamrial> fflogger is a bot
[23:19:04 CEST] <Illya> sublime text is probably your best bet imo
[23:20:13 CEST] <ubitux> the trending mac thing with nag screens like winrar?
[23:22:25 CEST] <ubitux> no one found a sysadmin yet btw?
[23:24:17 CEST] <llogan> ubitux: not that i am aware of. my summer time is not a good time for me to do server stuff, so i haven't done nearly anything
[23:45:05 CEST] <DSM_> durandal_170: i'm loving this new IRC client :D
[23:45:18 CEST] <DSM_> re-connects automatically 
[23:46:42 CEST] <iive> DSM_: what client(s) doesn't do that automatically?
[00:00:00 CEST] --- Wed Jun 22 2016