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

[burek]

[00:19:13 CET] <cone-020> ffmpeg 03Carl Eugen Hoyos 07master:4313ed511a31: lavc/psd: Interpret DUOTONE as GRAYSCALE.
[00:24:47 CET] <cone-020> ffmpeg 03Martin Vignali 07master:658e626cc0d5: libavcodec/psd : add support for psd bitmap mode
[03:00:34 CET] <cone-020> ffmpeg 03Steven Liu 07master:184c13f64aa5: avfilter/vf_libopencv: fix resource leak in read_shape_frame_filter
[05:02:00 CET] <bofh_> atomnuker: I have some SSE/AVX code for you, sec.
[05:16:22 CET] <atomnuker> bofh_: can you post a patch on the ML?
[05:18:40 CET] <bofh_> atomnuker: on it
[08:44:30 CET] <atomnuker> "Direct Stream Transfer is lossless compression; part of MPEG-4; used for SACD"
[08:45:04 CET] <atomnuker> what were they on when they wrote mpeg-4
[09:02:28 CET] <wm4> really bad stuff, apparently
[10:18:04 CET] <wm4> holy shit what, libavformat changed on an old mp4 file I used for testing the video track from a mjpeg slideshow to coverart?
[10:19:02 CET] <wm4> this one: http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/rtpodcast/Rooster_Teeth_Podcast_191.m4a
[10:19:12 CET] <wm4> (amusingly found it from the ffmpeg-devel IRC logs)
[10:20:27 CET] <wm4> this could be bisected, but that would take too long (I don't know a last working version either)
[10:21:00 CET] <wm4> mplayer and vlc still play it correctly
[10:21:44 CET] <wm4> hm or is it my own fault, because mplayer also uses lavf
[10:24:19 CET] <wm4> works if I ignore AV_DISPOSITION_ATTACHED_PIC in my code
[10:26:16 CET] <wm4> ah, those are considered chapter thumbnails
[10:26:25 CET] <wm4> AV_DISPOSITION_TIMED_THUMBNAILS
[10:26:51 CET] <wm4> not sure why it does that (the file has no "real" video tracks)
[10:27:10 CET] <wm4> or why it thinks it has to set the first frame as AVStream.attached_pic
[10:27:37 CET] <wm4> hm rcombs added this
[10:27:41 CET] <wm4> rcombs: please what?
[10:28:20 CET] <rcombs> wm4: it's for video streams that are flagged as "chapter" streams in MP4s
[10:28:40 CET] <wm4> well whatever it's supposed to be (mov is strange)
[10:28:40 CET] <rcombs> which is supposed to mean it's chapter thumbnails
[10:28:57 CET] <wm4> but I don't think mixing AVStream.attached_pic and streams that return video packets mix
[10:29:37 CET] <wm4> the code setting attached_pic (and maybe AV_DISPOSITION_ATTACHED_PIC) should probably be removed
[10:29:42 CET] <rcombs> attached-pic streams normally return a single packet
[10:29:55 CET] <wm4> yes, but this one can return multiple packet
[10:29:57 CET] <wm4> thus not sane
[10:55:37 CET] <[_T_]> Hey everyone, I noticed that ffmpeg < 3.1.x will dup the first frame when encoding a FSP=23.976 stream
[10:55:51 CET] <[_T_]> do you know what fix I should use ?
[10:55:57 CET] <wm4> and ffmpeg >= 3.1.x?
[10:55:59 CET] <[_T_]> I am stuck on 2.8.x for now ...
[10:56:07 CET] <[_T_]> ffmpeg >3.1.x is fine
[10:56:09 CET] <[_T_]> no dup
[10:56:30 CET] <[_T_]> I wondered if maybe you were aware what fixed it
[11:05:47 CET] <Sesse> [_T_]: you could always bisect
[11:10:21 CET] <wm4> why not use 3.2.x?
[11:23:40 CET] <[_T_]> Sesse: yeah i did with tags, not commits yet :)
[11:23:57 CET] <[_T_]> wm4: because I am using QSV encoding, and I have a better patch on 2.8.x :)
[11:24:19 CET] <[_T_]> well transcoding, which means decoding/vpp/encoding
[11:24:44 CET] <[_T_]> I never managed to run a QSV encoding on master by the way ...
[11:24:50 CET] <[_T_]> it changed from 3.2 apparently ...
[11:43:42 CET] <cone-539> ffmpeg 03Paul B Mahol 07master:45cd50e5e24e: avcodec/psd: fix ugly typo
[11:49:10 CET] <cone-539> ffmpeg 03Paul B Mahol 07master:107b3064d8bf: avcodec/wmaprodec: do not force extradata presence for XMA
[12:18:11 CET] <Sesse> [_T_]: git bisect is your friend :-)
[12:37:23 CET] <ubitux> this merge is going to be tricky actually...
[12:37:41 CET] <ubitux> we're going to have to actually reintroduce the dropped pointer
[12:38:15 CET] <wh> hi, all, how can i get PCR value in mpegts file under ffmpeg ?
[12:43:09 CET] <kierank> you can't ffmpeg doesn't know what a pcr is
[14:51:57 CET] <[_T_]> Sesse: ok thx :)
[15:33:39 CET] <durandal_1707> gonna push speedhq if nobody rings
[15:53:14 CET] <BBB> durandal_1707: sgtm
[15:53:36 CET] <BBB> wbs: I have no particular comments on your vp9/arm patchset, anything we should be wary of, or just apply straight away?
[15:53:58 CET] <BBB> wbs: Im surprised the alt returns give anything, x86 has instructions for that also but in almost all cases, it makes it slower (I dont really know why)
[16:02:59 CET] <Sesse> durandal_1707: \o/
[16:03:39 CET] <durandal_1707> Sesse: i removed empty function
[16:03:59 CET] <durandal_1707> and changed assert to log
[16:04:16 CET] <durandal_1707> as user can change tag easily
[16:14:24 CET] <cone-539> ffmpeg 03Steinar H. Gunderson 07master:eaff1aa09e90: avcodec: move bitswap_32() into a header file
[16:14:25 CET] <cone-539> ffmpeg 03Steinar H. Gunderson 07master:2a293ec7ac72: avcodec: add Newtek SpeedHQ decoder
[16:14:34 CET] <Sesse> durandal_1707: thanks :-)
[16:15:55 CET] <Sesse> I suppose it gets mirrored to https://git.ffmpeg.org/ffmpeg.git eventually?
[16:18:48 CET] <BBB> isnt that the main repo?
[16:19:16 CET] <Sesse> BBB: well, there's no sign of the commit there
[16:19:26 CET] <BBB> https://git.videolan.org/?p=ffmpeg.git;a=summary
[16:19:27 CET] <Sesse> but the irc bot just said it was committed?
[16:19:35 CET] <durandal_1707> i push to source one, videolan thingie
[16:19:36 CET] <Sesse> oh, now it showed up
[16:19:39 CET] <Sesse> some cache
[16:19:46 CET] <BBB> oh its an actual copy
[16:19:51 CET] <BBB> how strange
[16:19:53 CET] <Sesse> ah, videolan's ffmpeg
[16:19:57 CET] <BBB> I thought it was just a symlink
[16:20:04 CET] <BBB> videolan is our master, yes
[16:20:11 CET] <BBB> I didnt know ffmpeg.git was an actual copy
[16:20:17 CET] <BBB> I learned something new today
[16:28:41 CET] <ubitux> h264dec question
[16:29:03 CET] <ubitux> why can't we use cur_pic_ptr in place of next_output_pic in the main decoder function?
[16:29:36 CET] <ubitux> they mismatch, but i'm not sure i understand why; i suppose it might be related to the 2 fields of a picture
[16:30:03 CET] <ubitux> now if that's confirmed, my question becomes: why are we relying on both variable at this point?
[16:30:23 CET] <ubitux> like, we check for both cur_pic_ptr and next_output_pic
[16:30:37 CET] <ubitux> i'm asking because it's causing a lot of trouble in the next merge
[16:31:15 CET] <ubitux> as we are using next_output_pic to help reconstruct the frame at the end, or display its motion vectors and other information not available in the AVFrame
[16:31:29 CET] <ubitux> (next_output_pic being an H264Picture)
[16:31:52 CET] <ubitux> now basically in that scope we only have available cur_pic_ptr and an AVFrame
[16:32:04 CET] <ubitux> but we can't rely on cut_pic_ptr for that kind of information apparently
[16:32:53 CET] <ubitux> i can try to explain the problem better if someone is up for help 
[16:33:13 CET] <Compn> i mean i'm here , but i'm not going to be of much help :P
[16:33:15 CET] <ubitux> but so far the only solution mateo` and i came up with involved restoring an H264Picture
[16:33:36 CET] <ubitux> which kind of defeat the whole purpose of the original commit
[16:34:13 CET] <ubitux> or at least creates an ugly duplication, unless we also drop the output frame introduced, which will actually lead to something very close to pre-commit
[16:35:16 CET] <Compn> how much ugly duplication ?
[16:35:22 CET] <Compn> less than 1000 lines ? do eeet
[16:35:48 CET] <ubitux> it's not in line counts
[16:35:58 CET] <ubitux> it's about logical structure
[16:36:01 CET] <Compn> scattered everywhere ?
[16:36:07 CET] <ubitux> we are going to transmit the same information twice
[16:36:17 CET] <ubitux> like, in two different vars for the same purpose
[16:36:30 CET] <ubitux> which involves different memory management for each
[16:36:34 CET] <Compn> oh
[16:36:37 CET] <Compn> no thats bad then
[16:36:43 CET] <ubitux> ofc that's bad
[16:37:09 CET] <Compn> i thought you were talking about duplicating a function , nevermind
[16:37:14 CET] Action: Compn hides under his rock
[17:05:19 CET] <blb> Sesse: nice job. :]
[17:05:39 CET] <Sesse> blb: thanks! and thanks for your samples, they were extremely useful :-)
[17:26:28 CET] <BtbN> HDCD...
[17:27:07 CET] <philipl> There's irrelevant and there's HDCD.
[17:30:08 CET] <ubitux> michaelni: frame debug info and frame reconstruction are not available for flush frames or i'm missing something? (h264)
[17:30:26 CET] <ubitux> (see the 2 calls to output_frame())
[18:12:38 CET] <michaelni> ubitux, it seems so, i am not sure why though
[18:25:15 CET] <cone-539> ffmpeg 03Derek Buitenhuis 07master:14b9060160e4: hevc: Mark as having threadsafe init
[18:31:02 CET] <cone-539> ffmpeg 03Carl Eugen Hoyos 07master:f55da2200dbf: lavf/dss: Support version 3 files / files with larger header.
[18:53:35 CET] <michaelni> ubitux, do you see any reason why ff_print_debug_info2() is not called fr the 2nd  output_frame() ?
[18:53:47 CET] <michaelni> if not ill post a patch that adds that
[19:05:48 CET] <durandal_1707> kierank: do we have dolby-e decoder?
[19:06:33 CET] <baptiste> :)
[19:06:39 CET] <kierank> mumble mumble mumble
[19:07:44 CET] <durandal_1707> tell more
[19:17:11 CET] <kierank> durandal_1707: see pm
[19:37:19 CET] <ubitux> michaelni: i see no particular reason for both (frame reconstruction and debug info)
[19:37:44 CET] <ubitux> i was looking at refactoring but i got really tired after the merge so feel free to go ahead
[19:43:44 CET] <BtbN> is the coverity webui stuck? It says it detected new defects, but there are no new ones for me since 16.12.2016 listed
[19:46:19 CET] <llogan> works for me
[19:47:59 CET] <BtbN> For example CID#1398567, can't find that at all.
[19:49:11 CET] <BtbN> When sorting by CID, 1397295 is the highest
[19:49:16 CET] <BtbN> For me, that is.
[19:50:28 CET] <llogan> what do you have selected in the menu "hamburger" in upper left?
[19:52:10 CET] <BtbN> ah, "Issues: By Snapshot | Unsaved view"
[19:52:16 CET] <BtbN> that seems messed up
[19:52:49 CET] <BtbN> "
[19:52:49 CET] <BtbN> Issues: Project Scope | All In Project" that looks better
[19:53:58 CET] <llogan> do you also get the "New Defects" emails?
[19:54:03 CET] <BtbN> yes
[19:58:51 CET] <wbs> BBB: the arm/vp9 patches I just sent should be pretty safe; it's just resyncing ffmpeg's version to what has been in libav for a couple of weeks
[19:59:08 CET] <BBB> thats what I thought, ok
[21:42:19 CET] <cone-465> ffmpeg 03Zhengxu 07master:1a79b8f8d2b5: ffmpeg: Add an option "qsv_device" to choose proper node for QSV child device (vaapi or dxva2)
[21:43:17 CET] <durandal_1707> Compn: ugh this codec have many patents
[21:58:28 CET] <durandal_1707> lol
[21:59:41 CET] <durandal_1707> just found out people on reddit use gblur filter to lock screen with screenshot
[23:19:22 CET] <Chloe> durandal_1707: I met someone at an event who did that
[23:19:42 CET] <kierank> durandal_1707: which codec
[23:21:54 CET] <durandal_1707> kierank: iterated clearvideo. i told this other day
[23:22:09 CET] <kierank> ah
[23:22:11 CET] <Sesse> durandal_1707: then you can read the patents to figure out what it does ;-)
[23:22:35 CET] <durandal_1707> yea. just some rough idea
[23:26:48 CET] <durandal_1707> Chloe: which event?
[23:28:50 CET] <Compn> def con ? :P
[23:51:08 CET] <Chloe> durandal_1707: European cybersecurity challenge
[00:00:00 CET] --- Thu Jan 12 2017