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

[burek]

[00:04:56 CEST] <durandal117> ffmbc doesn't have this bug, but its mpegts demuxer is from 2011
[00:18:17 CEST] <nevcairiel> kodi is actually bothering to try to support dts in flac? man, someone needs some smacking with the clue by four =p
[00:22:33 CEST] <iive> nevcairiel: didn't they say that they are just implementing bit-exact spdif output?
[00:23:05 CEST] <iive> so the decoded dts would be "correctly" forwarded to the external reciever.
[00:23:08 CEST] <nevcairiel> he specifically named that case =p
[00:23:48 CEST] <nevcairiel> but if they want truely bit-exact, they should entirely by-pass the resampler
[00:26:05 CEST] Action: TD-Linux considers releasing an album on bandcamp with dts framing as part of the song
[00:28:27 CEST] <nevcairiel> artificially bit-constructed music :)
[00:57:50 CEST] <rcombs> TD-Linux: +1 to this
[00:58:18 CEST] <rcombs> what does a DCA syncword sound like anyway
[02:43:05 CEST] <cone-922> ffmpeg 03Michael Niedermayer 07master:5e1bf9d8c0d2: avcodec/avpacket: clear side_data_elems
[04:51:20 CEST] <cone-922> ffmpeg 03Rodger Combs 07master:1f6d7eb47070: lavf: add a flag to enable/disable automatic bitstream filtering
[04:58:42 CEST] <cone-922> ffmpeg 03Jonathan Campbell 07master:c19da0cfd8f3: avcodec/mpeg12dec: add comments documenting the format of the DVD CC user-data packet.
[08:20:17 CEST] <j-b> 'morning
[08:27:03 CEST] <atomnuker> 19:57 <@durandal_1707> TD-Linux: what you have? <- msssim, fastssim and psnrhvs is what we don't have (look in daala's repo/tools/dump_psnrhvs/msssim/fastssim)
[08:52:48 CEST] <Chloe> hi j-b 
[08:56:23 CEST] <Chloe> ubitux; could you take a look at the first sdl set please, the ffplay patch is already on the ml (the only other thing stopping a full switch to sdl2). If you want to do it incrementally then better get the deprecation patches in sooner rather than later and delay the ffplay patch for a bigger interval. FWIW the first set has been reviewed a few times so it'd just need one last looking over, nothing really in-depth
[09:39:53 CEST] Action: rcombs points nevcairiel at AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL and AV_PKT_DATA_MPEGTS_STREAM_ID (not to say that Existing API is inherently Good API)
[09:40:48 CEST] <nevcairiel> at least those server some kind of purpose other then user information
[09:40:51 CEST] <nevcairiel> -r
[09:41:03 CEST] <nevcairiel> not that i particularly like them
[09:41:05 CEST] <rcombs> I'd be all for a per-stream AVDictionary for stuff that isn't exactly metadata, like this
[09:41:17 CEST] <rcombs> particularly if the codec could write to it as well
[09:41:53 CEST] <rcombs> ("has H.264 scaling matrix" is something I'm using a dumb hack to export right now)
[09:42:52 CEST] <nevcairiel> maybe you should get a proper stream analyzer =p
[09:43:02 CEST] <nevcairiel> or screw broken implementations
[09:44:49 CEST] <nevcairiel> hardware makers will never learn if everyone bends over backwards to accomodate to their stupidity
[09:48:03 CEST] <rcombs> actually y'know what
[09:48:19 CEST] <rcombs> now that I look again I can't actually find any evidence that the platforms this limitation is set on actually break with it
[09:48:23 CEST] <rcombs> this smells like cargo culting
[09:48:26 CEST] <JEEB> classic :D
[09:48:27 CEST] <nevcairiel> lol
[09:51:38 CEST] <rcombs> I think the H.264 scaling matrix thing originated on some old Android version
[09:51:48 CEST] <rcombs> now it's in a bunch of other profiles but that might only be because it's been copypasta'd
[09:52:18 CEST] <JEEB> I would guess that to be the case
[10:20:13 CEST] <rcombs> michaelni: I'm just dropping the matroska side-data patch
[10:20:26 CEST] <rcombs> and having a word with the guy who made me think I needed it
[10:20:44 CEST] <rcombs> and kicking myself for not checking earlier
[10:33:37 CEST] <nevcairiel> lol
[10:34:16 CEST] <nevcairiel> it is not unheard of that some devices barfed at certain compressions
[10:34:20 CEST] <nevcairiel> primarily header stripping
[10:34:39 CEST] <nevcairiel> which mosu intentionally enabled by default to get people to fix their shit =p
[10:59:48 CEST] <michaelni> rcombs, if you drop the patch please update it on patchwork
[11:00:19 CEST] <rcombs> nevcairiel: it used to be broken on Roku but it seems they fixed a while back
[11:02:35 CEST] <rcombs> hmm
[11:02:42 CEST] <rcombs> haven't used this thing before
[11:02:45 CEST] Action: rcombs pokes around a bit
[11:06:16 CEST] <rcombs> what's the procedure around archiving patches?
[11:12:31 CEST] <durandal_17> is there some tool which will show mpegts's packet's pts?
[11:14:05 CEST] <wm4> is utils.c corrupting mpegts timestamps again
[11:15:25 CEST] <durandal_17> wm4: nope, i get nopts from mpegts demuxer, need to find out is that ffmpeg bug
[11:36:31 CEST] <michaelni> rcombs, patchwork "archiving", no idea
[11:38:58 CEST] <michaelni> rcombs, added you to the ffmpeg maintainers at patchwork so you can edit everyones patches. if i missed any developer that has an accunt and doesnt have powers to edit other patches on patchwork ping me
[11:39:09 CEST] <rcombs> OK
[11:45:05 CEST] <omerjerk> do we get "FFmpeg" t-shirts?
[11:56:18 CEST] <durandal_17> omerjerk: no, only pants
[11:58:53 CEST] <omerjerk> lol, xD
[12:13:22 CEST] <durandal_17> what to do if mpegts packet doesn't have pts?
[12:24:04 CEST] <wm4> durandal_17: fix code
[12:27:23 CEST] <durandal_17> wm4: which code?
[12:28:11 CEST] <wm4> all of it
[12:28:50 CEST] <wm4> is it missing timestamps on the lowest level, are they due to parsing, etc.
[12:34:08 CEST] <durandal_17> wm4: mpegts packet may not have pts, as set in pes header
[12:36:42 CEST] <durandal_17> kierank: see above
[13:02:44 CEST] <kierank> durandal_1707: get it from the codec and interpolate
[13:09:20 CEST] <ubitux> michaelni: any idea why only ismv was missing?
[13:09:35 CEST] <ubitux> maybe that was on purpose
[13:10:00 CEST] <michaelni> ubitux, did ismv exist when this was written ?
[13:10:10 CEST] <michaelni> maybe it was added later and forgotten to be added
[13:11:13 CEST] <ubitux> ok
[13:23:29 CEST] <StevenLiu> Hi michael, is saw the ticket 5525 user use tsinfo, do you have the tool?
[13:23:48 CEST] <StevenLiu> i saw the ticket 5525 user use tsinfo, do you have the tool?
[14:03:02 CEST] <StevenLiu> ok, tstools on github
[15:04:36 CEST] <durandal_17> michaelni: h264 parser produce strange frames from mpegts file I have, every 2nd frame is of size 1800 and have no pts, such split frames can not be decoded separately, only if combined together
[16:12:40 CEST] <durandal_17> michaelni: should parser merge those 2 frames into one?
[16:13:08 CEST] <nevcairiel> if both are required for decoding, and they are not two interlaced fields, then it should
[16:14:01 CEST] <nevcairiel> interlaced fields are intentionally kept seperate for parallel decoding, i think
[16:16:41 CEST] <durandal_17> nevcairiel: hmm, but that one breaks stream copy somehow
[16:17:05 CEST] <durandal_17> and yes, it is interlaced crap
[16:26:07 CEST] <cone-456> ffmpeg 03Vittorio Giovara 07master:d41bfa9c0b10: vf_colorspace: Add BT-names for gamma22/28 transfer option
[18:42:50 CEST] <michaelni> durandal117, do you have a sample / testcase ?
[18:48:08 CEST] <durandal_170> michaelni: yes, I have
[19:07:45 CEST] <Chloe> jamrial: thanks, I appreciate you testing it
[23:08:09 CEST] <cone-202> ffmpeg 03Marton Balint 07master:025db5afaf28: avfilter/af_amerge: allow merging 1 input only
[23:49:05 CEST] <cone-202> ffmpeg 03Michael Niedermayer 07master:22ba9a3cb8c0: avformat/hlsenc: Avoid "%T" "%F" in strftime() to improve compatibility
[23:49:06 CEST] <cone-202> ffmpeg 03Michael Niedermayer 07master:9f18a970b2df: avformat/hlsenc: Assume UTC if "%z" is unsupported in strftime()
[00:00:00 CEST] --- Wed Sep 14 2016