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

[burek]

[00:07:51 CEST] <cone-031> ffmpeg 03Michael Niedermayer 07master:923d5c489fd4: avcodec/utils: fix leak of subtitle_header on error path
[00:48:16 CEST] <tmm1> how feasible would it be to use a bsf to extract h264 reordering information?
[00:51:16 CEST] <mkver> Do you mean simply to extract the value from the SPS's VUI (if it is present)?
[00:51:43 CEST] <iive> about that VLC CVS... how is .mp4 POC for mkv bug?!
[00:52:19 CEST] <mkver> You can rename a Matroska file to .mp4.
[00:52:28 CEST] <jamrial> yeah, it's using the wrong extension
[00:52:34 CEST] <mkver> Or do you want to actually determine the amount of reorder frames from the bitstream?
[00:54:51 CEST] <nevcairiel> knowing some history, sounds like another approach of trying to work with apples insane  hardware decoder API which for some insane reason forgot to re-order frames in its decoder
[00:55:35 CEST] <mkver> So the decoder outputs frames in decoding order?
[00:55:49 CEST] <tmm1> yea the vt decoder in async mode has a long standing problem where frames don't come back in decode order
[00:56:20 CEST] <tmm1> however currently i'm working on something else.. i'm using h264_metadata=a53_cc=extract to pull out caption data and i need to reorder it into picture order before i can decode it
[00:56:54 CEST] <nevcairiel> thats really the same problem though, and not easy. You need a lot of an actual decoder
[00:57:28 CEST] <tmm1> so not a simple field i can pull out of the bitstream, bummer
[00:57:58 CEST] <nevcairiel> CC design is also one of those  insanities that'll haunt us  until the end of time, mostly because its mandatory by US law
[00:58:08 CEST] <mkver> H.264 has several ways of indicating output order, depending on the SPS's pic_order_cnt_type.
[00:59:37 CEST] <mkver> The most flexible only gives you the least serious bits of the pic order count and lets you unwrap them by yourself, thereby generating output order.
[01:01:02 CEST] <mkver> But if the packets have correct timestamps, you could actually avoid taking a look at the bitstream yourself.
[01:01:18 CEST] <tmm1> i see, so the signal to determine order can vary depending on the h264 bitstream features used
[01:01:26 CEST] <mkver> Yes.
[01:02:07 CEST] <nevcairiel> I've long advocated against relying on timestamps for re-ordering, and I'll continue to do so. They are notoriously  unreliable
[01:03:03 CEST] <tmm1> i'm using PTS now and it mostly works, but i've started to hit cases where it no longer does
[01:03:32 CEST] <mkver> Such as?
[01:05:44 CEST] <tmm1> it was reliable on broadcast mpegts streams, but not on some iptv/hls streams i'm testing
[01:06:28 CEST] <tmm1> broadcast streams generally have both PTS and DTS set, but many hls encoder seem to skip DTS and i guess the PTS are also not accurate
[01:06:50 CEST] <tmm1> or maybe there's some other bug in my hls stream handling
[01:07:41 CEST] <mkver> Are the CC specs actually publically available?
[01:08:29 CEST] <tmm1> hm i don't recall. the wikipedia page is pretty good, i used that when i was working on ccaption_dec.c
[11:13:48 CEST] <durandal_1707> kierank: can you apply adxenc patch for me, looks like nobody cares to review it
[11:26:46 CEST] <kierank> durandal_1707: yes in office
[13:08:19 CEST] <durandal_1707> vel0city: perhaps you need to check number of components for mjpeg change, to not break file michealni found
[13:36:14 CEST] <durandal_1707> IRC disrupts
[13:46:29 CEST] <vel0city> @durandal_1707: I'll try that
[13:50:34 CEST] <vel0city> or the precision, 16 vs 8
[13:56:25 CEST] <vel0city> first gotta narrow it down
[13:57:42 CEST] <vel0city> ah was the vpred path
[14:00:34 CEST] <vel0city> k I'll just check for s->bayer which is already s->lossless == 1 && nb_components == 2
[14:04:03 CEST] <Lynne> why was it marked as bayer btw?
[14:05:27 CEST] <vel0city> because it's bayer encoded. mjpegdec.c doesn't do the debayering, but it was the most fitting name I could think of. I could have called it 'dng' to be more specific but I liked bayer better
[14:43:24 CEST] <whiteboard> Hi ! Is it possible to make AVPacket side data persistent ? I mean adding AVPacket side data in a bitstream filter and being able to recover the same AVPacket side data with a different one without chaining the two filters.
[15:38:21 CEST] <mkver> whiteboard: Most bsf just operate on the packet data and just pass through any side data that the packet already had.
[15:46:42 CEST] <Lynne> I think its about attaching side data to the actual data of the packets
[15:47:23 CEST] <Lynne> the answer is it depends on the codec, and you can't be sure that whatever the packets are passed through won't drop it
[16:08:21 CEST] <kierank> durandal_1707: I am leaving irc
[16:08:25 CEST] <kierank> nicholas says is is bad
[16:08:28 CEST] <kierank> it*
[16:11:13 CEST] <kierank> let's move to slack instead
[16:11:20 CEST] <kierank> or fax
[16:12:02 CEST] <jamrial> or google wave. is that still working?
[16:13:23 CEST] <kierank> lol
[16:13:25 CEST] <cone-071> ffmpeg 03Paul B Mahol 07master:cc6a1f141762: avcodec/adxenc: add EOF header
[16:31:16 CEST] <gnafu> kierank, jamrial: Carrier pigeon, of course.
[16:31:20 CEST] <gnafu> Or smoke signals in a pinch.
[16:31:30 CEST] <gnafu> This whole IRC business is aa bit too real-time for my taste.
[16:31:35 CEST] <gnafu> s/aa/a/
[16:58:51 CEST] <Lynne> semaphores are the future
[17:31:36 CEST] <durandal_1707> IRC is past, present and future
[17:32:36 CEST] <durandal_1707> anybody against applying IMM5 decoder?
[17:53:19 CEST] <jamrial_> durandal_1707: is concatenated and decodable h264/hevc packets within imm5 a real world case? have you seen something like that in the wild?
[17:54:06 CEST] <jamrial_> the same could be done to any kind of input. i don't see why we're taking it into consideration for this specific codec
[17:54:34 CEST] <kurosu> jamrial_: dame comment some days ago basically
[17:55:15 CEST] <kurosu> I expect crafted files to change the codec on a frame basis and thus making no sense
[17:56:03 CEST] <durandal_1707> jamrial_: i'm not accepting hacks in demuxer, this is decoder
[17:56:11 CEST] <kurosu> My suggestion was to maybe delay opening the decoder until the first frame and keep it. If it changes, bail out, asking for a sample
[17:56:57 CEST] <durandal_1707> you do not need to delay anything
[17:57:11 CEST] <durandal_1707> opening decoder does not hurt
[21:41:21 CEST] <Compn> durandal_1707,  michaelni says he doesnt think anything is blocking photosensitive filter
[21:41:38 CEST] <Compn> <michaelni> Compnn, i dont think theres anything blocking it, at least nothing i found. There are some areas which can be improved as i mentioned on the ML
[21:49:03 CEST] <durandal_1707> Compn: then i will apply it after i get back from vacation
[21:49:21 CEST] <Compn> enjoy vacation
[21:49:51 CEST] <durandal_1707> can't, must read ffmpeg-devel mailing-list every day
[00:00:00 CEST] --- Fri Jul 26 2019