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

[burek]

[00:46:30 CEST] <Shiz> is that the classic replace-\n-using-sed trick
[00:47:44 CEST] <iive> btw, there is `todos` and `fromdos` for easier conversion.
[00:48:42 CEST] <atomnuker> of course there is since sed does such a horrible job at anything but letters
[00:51:06 CEST] <wm4> atomnuker: why do you think sed has to be sane
[00:51:11 CEST] <wm4> it's old unix bullshit
[00:51:17 CEST] <wm4> like... shell
[00:51:45 CEST] <wm4> it was sane for a brief moment, and then grew feature tentacles
[00:52:40 CEST] <Shiz> shell was never sane
[00:52:42 CEST] <Shiz> dont li
[00:52:45 CEST] <Shiz> e
[00:58:19 CEST] <wm4> come on, everyone agrees that "cp FILEA FILEB" looks sane
[00:58:36 CEST] <wm4> until they learn about filenames that start with "--" or which contain newline characters
[01:01:22 CEST] <Shiz> let's start with arrays in shell
[04:46:27 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:d90c5bf10559: avcodec/wavpack: Fix runtime error: signed integer overflow: 24 * -2147483648 cannot be represented in type 'int'
[04:46:27 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:4020b009d1e8: avcodec/wavpack: Check float_shift
[04:46:27 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:87bddba43b72: avcodec/acelp_pitch_delay: Fix runtime error: value 4.83233e+39 is outside the range of representable values of type 'float'
[10:38:07 CEST] <nevcairiel> neat, AVX-512 confirmed for Skylake-X consumer CPUs (well, HEDT, some people might not consider that very "consumer")
[10:39:45 CEST] <rcombs> the i9s and such?
[10:40:02 CEST] <nevcairiel> yea
[10:40:28 CEST] <rcombs> nice
[10:40:33 CEST] <rcombs> (what's HEDT?)
[10:40:47 CEST] <nevcairiel> High-End Desktop Platform
[10:41:03 CEST] <nevcairiel> what intel calls their X line of CPUs/motherboards
[11:04:59 CEST] <BtbN> Aparently the X299 chip is identical to the Z270
[11:05:02 CEST] <BtbN> Not even USB 3.1
[11:13:46 CEST] <nevcairiel> should have usb 3.1 gen 1
[11:13:50 CEST] <nevcairiel> not gen 2 tho
[11:14:01 CEST] <BtbN> gen1 is just 3.0 anyway
[11:14:56 CEST] <nevcairiel> of course with that amount of PCIe lanes and IO flexibility, board makers are just going to include it anyway
[11:15:15 CEST] <nevcairiel> could even use intels alpine ridge controller
[11:15:19 CEST] <BtbN> sure, but so far every one of those ASmedia controler I came in contact with was hot trash
[11:15:58 CEST] <atomnuker> those controllers really heat up when there's a usb-c device connected
[11:16:06 CEST] <atomnuker> not good for power consumption
[11:16:20 CEST] <nevcairiel> its a system with a 140W+ CPU, noone cares =p
[11:16:31 CEST] <atomnuker> oh yeah, forgot
[11:16:45 CEST] <BtbN> The 140W aren't even that crazy for that many cores though
[11:17:07 CEST] <nevcairiel> rumors have the 14, 16 and 18 core  models at 165W
[11:17:10 CEST] <nevcairiel> but it wasnt confirmed
[11:17:39 CEST] <BtbN> The one I'd be interested in would be the 10 core variant, i9-7900 I think
[11:17:50 CEST] <BtbN> But for now my Ryzen 8 core will work
[11:18:05 CEST] <BtbN> If they ever fix the non-CPU PCIe Lanes, that is
[11:18:06 CEST] <nevcairiel> yeah the 10-core is what I'm looking at
[11:18:46 CEST] <nevcairiel> would be a decent upgrade from my 6 core
[11:19:12 CEST] <nevcairiel> and i can probably put it off as a business expense
[11:19:22 CEST] <nevcairiel> my tax guy keeps telling me to spend more
[11:19:22 CEST] <nevcairiel> :p
[11:21:27 CEST] <BtbN> I just got myself a nice AMD 8 core
[11:21:35 CEST] <BtbN> don't think I'm in need for an upgrade anytime soon
[11:21:47 CEST] <rcombs> does SKL-X need special motherboards, or will it work with regular SKL ones?
[11:22:04 CEST] <nevcairiel> needs a X299 motherboard
[11:22:17 CEST] <nevcairiel> it has a much higher pin count then consumer boards
[11:22:25 CEST] <nevcairiel> 2066 pins vs 1500~ something
[11:22:31 CEST] <nevcairiel> for all the extra PCIe lanes
[11:22:51 CEST] <BtbN> It's a diffrent socket, because 44 instead of just 16 lanes, and more memory channels
[11:23:22 CEST] <BtbN> AM4 has 1300 or something
[11:23:27 CEST] <BtbN> And they still use a PGA...
[11:23:35 CEST] <BtbN> I was very nervous while handling that
[11:23:45 CEST] <BtbN> bend one of them, and 600¬ are gone
[11:24:17 CEST] <nevcairiel> i wonder if the threadripper socket finally gets rid of that
[11:24:26 CEST] <BtbN> it has to
[11:24:47 CEST] <BtbN> unless the casing of the CPU is massively huge, you can't get the required pin density with a PGA
[11:24:53 CEST] <nevcairiel> i guess
[11:25:19 CEST] <BtbN> AM4 is probably about as dense as you can get
[11:27:00 CEST] <nevcairiel> the threadripper SP3r2 socket presumably has 4094 pins, even with a LGA design thats going to be massive of a chip
[11:30:06 CEST] <nevcairiel> interesting will be how the NUMA-like behavior of the intel high core count CPUs will behave in consumer workloads (that affects that 14-18 core CPUs only, which are on a different die design then the 6 to 12 cores)
[11:30:30 CEST] <BtbN> So they also went for an AMD like multi-CCX design?
[11:30:40 CEST] <nevcairiel> not exactly
[11:30:50 CEST] <nevcairiel> intel has had these designs in Xeons for years
[11:31:03 CEST] <nevcairiel> they just moved one design down into the consumer space
[11:31:14 CEST] <BtbN> I just hope AMD fixes the Fabric-Clock being tied to the RAM clock thingy
[11:31:40 CEST] <BtbN> Intel has a 2GHz QPI since forever
[11:31:40 CEST] <nevcairiel> its sitll one huge singular die, but due to the sheer a mount of cores the caching and memory access gets ..complicated
[11:32:01 CEST] <nevcairiel> so the latency can vary depending on which part of the L3 you access
[11:33:00 CEST] <BtbN> You'd need to run Ryzen with DDR4-4000 to be roughly on par with Intel
[11:33:14 CEST] <BtbN> Which is now possible, with the new AGESA code
[11:33:17 CEST] <nevcairiel> i hear they finally actually made it possible to do that
[11:33:28 CEST] <BtbN> But only with 2x8GB single ranked
[11:33:32 CEST] <nevcairiel> also 4000 is quite high
[11:33:52 CEST] <BtbN> I have 2x16GB, dual rank. Impossible to even hit the advertised 3200
[11:34:22 CEST] <nevcairiel> i run 4x8 3200, but i'm on X99
[11:36:11 CEST] <nevcairiel> (now that chipset platform has been getting old)
[11:38:06 CEST] <BtbN> X99 seems still decent to me
[11:38:21 CEST] <BtbN> With the 40 lanes coming from the CPU, you have no real need for PCIe 3.0 from the chipset
[11:38:34 CEST] <BtbN> And it offers USB3.0, the new chipsets don't offer anything more
[11:41:56 CEST] <kierank> Still not pcie 4.0 sadly
[11:44:15 CEST] <Gramner> the PCI-e 4.0 spec isn't even finalized yet so that's hardly surprising
[11:48:46 CEST] <Gramner> it seems to have been delayed for some time. high bandwidth over copper is getting hard
[11:49:36 CEST] <Gramner> wouldn't surprise me if the next gen is optical
[11:49:50 CEST] <BtbN> you'd still need to connect it to copper somewhere
[11:50:15 CEST] <Gramner> of course, but that'd result in much shorter copper wires
[11:50:53 CEST] <BtbN> I really wonder why they went for copper Thunderbolt
[11:50:57 CEST] <BtbN> instead of something optical
[11:51:08 CEST] <Gramner> cost most likely
[11:51:27 CEST] <BtbN> the cost of a fiber optic cable is lower than for a copper one
[11:51:44 CEST] <Gramner> cables yes, everything else no
[11:52:12 CEST] <Gramner> but optics have been getting cheaper steadily
[11:56:25 CEST] <iive> the fiber optic cables are cheap, but the receivers and transmitters are not, and they consume a lot of power
[11:57:10 CEST] <iive> they are great for long distances, but for something inside the computer....
[11:58:10 CEST] <BtbN> you don't need a lot of energy for a few cm of optic wire
[11:58:12 CEST] <atomnuker> they're not cheap, I looked for a 100m cable and prices were around 48 to +150 gbp
[11:58:27 CEST] <atomnuker> also connectors matter a lot, lcs are cheap but the rest
[11:58:31 CEST] <Gramner> the optics you'd use for sub-meter range is vastly different than what you'd use for 10km
[11:59:02 CEST] <atomnuker> for such lengths also grade doesn't really matter so you can get high grade stuff for cheap from china
[11:59:36 CEST] <atomnuker> but the transceivers are really horridly expensive proprietary pieces of shit you can't use if the vendors don't match
[12:00:53 CEST] <Gramner> ethernet stuff (e.g. SFP, SFP+) is standardized. they just hardcode the brand into the id string and refuse to work unless it matches. so you just buy 3rd party ones with the correct id string set and no problems
[12:01:52 CEST] <Gramner> 1st party SFPs are expensive as hell, 3rd party ones dirt cheap and they work just fine
[12:02:03 CEST] <atomnuker> you can't reprogram them though
[12:02:41 CEST] <Gramner> not sure why you'd need to do that unless you decide to swap brand of all your switches for some reason
[12:02:46 CEST] <atomnuker> I think its best to just hunt on ebay for media converters and transceivers from old servers and treat them as one unit
[12:03:02 CEST] <Gramner> and if you do that, just buy new SFPs since that's insignificant compared to the cost of switches
[12:03:19 CEST] <BtbN> The SFP electric connection is standardized
[12:03:20 CEST] <atomnuker> problem is alot of those media converters are +10 years old and don't do gigabit
[12:03:21 CEST] <BtbN> not the protocol
[12:09:04 CEST] <Gramner> never looked into the implementation details of it, all I know is that third party ones work perfectly fine and are cheap enough to just buy hundreds of them at a time
[12:09:37 CEST] <BtbN> You can usually select a compatiblity option with the third party ones
[12:09:45 CEST] <BtbN> to specify in which device they are supposed to run
[12:09:51 CEST] <Gramner> yes, that's what I do
[12:09:53 CEST] <BtbN> https://www.gbic-shop.de/en/products/transceivers/sfp/copper-rj45-sfp/bo08c38s1-bo08c38s1-10-100-1000base-t-100-meter-detail.html
[12:10:31 CEST] <Gramner> ¬49 is expensive though
[12:10:50 CEST] <BtbN> for a gigabit RJ45, yeah
[12:11:32 CEST] <atomnuker> (meanwhile 100m cat5e goes for barely 18 pounds here)
[12:12:03 CEST] <Gramner> I usually go with the fancy WDM ones so only one fiber is needed instead of a pair
[12:29:25 CEST] <rcombs> do the transceivers tend to introduce any significant latency?
[12:29:52 CEST] <rcombs> also optical gives you fun awkwardness if dust gets anywhere
[12:30:22 CEST] <nevcairiel> getting dust inside the connectors can also be awkward with elictrical
[12:30:29 CEST] <nevcairiel> electrical*
[12:30:42 CEST] <BtbN> From my experience the latency with SFP(+) cards is slightly lower than with RJ45 copper
[12:30:43 CEST] <rcombs> yeah, but it's generally not as sensitive, is it?
[12:31:08 CEST] <rcombs> huh, surprising
[12:31:40 CEST] <bencoh> once plugged, you should be fine
[12:31:54 CEST] <rcombs> yeah, it's more a concern when not
[12:32:06 CEST] <bencoh> and I have seen optical equipments in heavily dusty rooms
[12:32:09 CEST] <bencoh> no problems there
[12:32:28 CEST] <bencoh> s/seen/operated/ even
[12:32:30 CEST] <rcombs> even if left unmated and uncapped?
[12:32:44 CEST] <nevcairiel> well dust it off before use? :)
[12:32:51 CEST] <bencoh> iirc some were, yes
[12:33:03 CEST] <rcombs> I guess maybe I'm thinking of the actual fibers
[12:33:11 CEST] <nevcairiel> and equipment needing proper handling (ie. capping them) should be a given
[12:33:21 CEST] <bencoh> (although I usually managed to keep those capped)
[12:33:23 CEST] <rcombs> apparently you've gotta polish them before putting connectors on
[12:33:32 CEST] <rcombs> but that's not a concern for consumer electronics handling
[12:33:40 CEST] <rcombs> nevcairiel: yeah but consumers aren't gonna reliably do that
[12:33:43 CEST] <JEEB> the U-SDI stuff at NHK with fiber stuff was fun
[12:33:45 CEST] <Gramner> you are supposed to have connectors capped and clean them when inserting a patch
[12:34:49 CEST] <Gramner> although normal 1GbE optics are not actually that sensitive generally unless we're talking really large distances
[12:36:59 CEST] <rcombs> I find it hard to imagine optical beating copper on latency over a few cm
[12:37:34 CEST] <rcombs> matching, even, seems difficult
[12:38:45 CEST] <bencoh> rcombs: because of the (supposedly?) added latency of the transceiver?
[12:38:55 CEST] <rcombs> yeah
[12:39:16 CEST] <rcombs> are optical transceivers much simpler than I'm thinking they are?
[12:39:32 CEST] <rcombs> like, literally an LED on one side and a photodiode on the other?
[12:39:34 CEST] <Gramner> which for high-speed transcievers is in the order of a few hundred nanoseconds
[12:40:05 CEST] <Gramner> can probably get it even lower if that's a design goal I guess
[12:40:14 CEST] <bencoh> rcombs: I'd say copper has a transceiver of some sort as well
[12:40:17 CEST] <bencoh> just usually on-board
[12:41:02 CEST] <bencoh> (you know, the PHY at the other end of your (R)(G)MII)
[12:41:16 CEST] <rcombs> keep in mind I have no idea what I'm talking about
[12:41:22 CEST] <bencoh> ah :)
[12:41:44 CEST] <rcombs> most hardware work I've done is hooking an atmega328p up to an N64's controller port
[12:41:55 CEST] <rcombs> 1MHz signaling! waow!
[12:42:03 CEST] <rcombs> much fast
[13:04:41 CEST] <ubitux> in ps_hybrid_analysis_c
[13:04:47 CEST] <ubitux>         INT64FLOAT sum_re = (INT64FLOAT)filter[i][6][0] * in[6][0];
[13:04:49 CEST] <ubitux>         INT64FLOAT sum_im = (INT64FLOAT)filter[i][6][0] * in[6][1];
[13:04:53 CEST] <ubitux> is this really correct?
[13:05:12 CEST] <ubitux> like, shouldn't it be filter[i][6][1] for sum_im?
[13:07:22 CEST] <ubitux> atomnuker: maybe you have an idea?
[13:08:33 CEST] <atomnuker> certainly seems that way, though peloverde wrote that code so he would know better
[13:09:59 CEST] <sigdrak> im*im = re
[13:10:18 CEST] <iive> j*j=-1 ?
[13:11:17 CEST] <ubitux> iiuc it's the simplified equivalent of (INT64FLOAT)filter[i][6][0] * (in[6][1] + in[ 6][1]) + (INT64FLOAT)filter[i][6][1] * (in[6][0] + in[6][0])
[13:11:39 CEST] <ubitux> (the [1] are the im and the [0] are the re)
[13:12:13 CEST] <ubitux> so maybe some properties i'm not aware of cancel things out the same way for both sum
[13:13:01 CEST] <ubitux> sorry i meant sum_im = filter[i][6][0] * (in[6][1] + in[ 6][1]) + filter[i][6][1] * (in[6][0] - in[6][0])
[13:13:52 CEST] <ubitux> and sum_re = filter[i][6][0] * (in[6][0] + in[ 6][1]) - filter[i][6][1] * (in[6][1] - in[6][1])
[13:14:18 CEST] <ubitux> dammit, sum_re = filter[i][6][0] * (in[6][0] + in[ 6][0]) - filter[i][6][1] * (in[6][1] - in[6][1])
[13:18:17 CEST] <ubitux> so, to simplify
[13:18:20 CEST] <ubitux> if we have:
[13:18:22 CEST] <ubitux> sum_re = filter_re[i][6] * (in_re[6] + in_re[6]) - filter_im[i][6] * (in_im[6] - in_im[6])
[13:18:24 CEST] <ubitux> sum_im = filter_re[i][6] * (in_im[6] + in_im[6]) + filter_im[i][6] * (in_re[6] - in_re[6])
[13:18:27 CEST] <ubitux> does it simplifies to:
[13:18:40 CEST] <ubitux> sum_re = filter_re[i][6] * in_re[6]
[13:18:41 CEST] <ubitux> sum_im = filter_re[i][6] * in_im[6]
[13:18:53 CEST] <ubitux> or to:
[13:18:54 CEST] <ubitux> sum_re = filter_re[i][6] * in_re[6]
[13:18:56 CEST] <ubitux> sum_im = filter_im[i][6] * in_im[6]
[13:18:58 CEST] <ubitux> ?
[13:22:36 CEST] <J_Darnley> Is anyone in the middle of doing a merge?
[13:26:00 CEST] <cousin_luigi> Greetings.
[13:27:28 CEST] <wm4> ok I think I'll write a BSF that attempts to fix timestamps of the second field each on interlaced h264
[13:27:33 CEST] <wm4> is that a good or a bad idea
[13:27:51 CEST] <wm4> I need it for proper remuxing of interlaced h264
[13:28:06 CEST] <cousin_luigi> Does ffmpeg 2.8.x still need an external dcadec?
[13:28:20 CEST] <wm4> "fixing" would mean changing broken timestamps or filling in missing ones
[13:31:10 CEST] <kierank> wm4: derek has the same problem
[13:31:34 CEST] <kierank> why has this behaviour changed all of a sudden
[13:31:44 CEST] <wm4> which derek
[13:32:09 CEST] <kierank> daemon404
[13:32:11 CEST] <wm4> I think my immediate problem is that the .ts captured from a tuner doesn't have PTS for the second field
[13:32:18 CEST] <wm4> when, where?
[13:32:20 CEST] <kierank> ah, not a lavf problem then
[13:32:31 CEST] <wm4> lavf fails to remux this anyway
[13:32:47 CEST] <wm4> we had this great idea of setting a random timestamp to make lavf happy
[13:32:52 CEST] <kierank> 4:13 PM <Daemon404> so libavformat outputs two packets per frame with AVC PAFF
[13:32:52 CEST] <kierank> 4:13 PM <Daemon404> it used to be that both these packets had the same PTS (sicne there is only one output frame)
[13:32:52 CEST] <kierank> 4:13 PM <Daemon404> how it interpolates some made up bullshit
[13:32:55 CEST] <wm4> now we have broken files which we also need to deal with
[13:33:06 CEST] <kierank> second field without pts is not illegal
[13:33:26 CEST] <wm4> at the very least it's annoying
[13:33:39 CEST] <ubitux> J_Darnley: not right now, probably tomorrow
[13:33:46 CEST] <wm4> and of course lavf doesn't always detect the correct framerate either (which would making it up make simpler)
[13:33:56 CEST] <wm4> so does MBAFF not have separate slices?
[13:34:07 CEST] <J_Darnley> cousin_luigi: No idea about 2.8 but the current master claims to have a dts/dca codec
[13:34:27 CEST] <J_Darnley> I  suggest you check the changelog
[13:34:38 CEST] <wm4> J_Darnley, cousin_luigi: ffmpeg has replaced the dts decoder with the code from libdcadec since a while ago
[13:34:42 CEST] <wm4> not sure when
[13:34:43 CEST] <cousin_luigi> J_Darnley: IKR, I know it had been integrated, but some distros still package 2.8.x
[13:35:02 CEST] <cousin_luigi> Just wondering if the same had happened with older branches.
[13:35:11 CEST] <BtbN> nevcairiel, https://1.f.ix.de/imgs/18/2/2/1/1/3/7/6/IMG_0440-afac0d91999b29e3.jpeg yep, definitely huge.
[13:35:18 CEST] <kierank> wm4: mbaff has single picture per frame
[13:35:32 CEST] <kierank> J_Darnley: go go go
[13:35:42 CEST] <J_Darnley> cousin_luigi: the changelog says it was added in 3.0
[13:35:51 CEST] <cousin_luigi> J_Darnley: Perfect. Thanks.
[13:36:01 CEST] <J_Darnley> wait a mo
[13:36:01 CEST] <wm4> kierank: man that's horrible
[13:36:17 CEST] <J_Darnley> it also says "DTS decoding through libdcadec" for 2.7
[13:36:18 CEST] <wm4> I had this idea always using separate packets/AVFrame for each fields would make interlacing not a PITA
[13:36:28 CEST] <kierank> you can't that's the problem
[13:36:31 CEST] <wm4> but that sounds like mbaff forces a single packet and frame
[13:36:31 CEST] <kierank> the stream can adapt at will
[13:36:38 CEST] <wm4> and that too
[13:36:40 CEST] <wm4> jesus christ
[13:36:50 CEST] <cousin_luigi> J_Darnley: Yes, so I still need to link against it. That's all I needed to know.
[13:36:56 CEST] <cousin_luigi> Unless it was backported.
[13:37:37 CEST] <cone-326> ffmpeg 03James Darnley 07master:8e89f6fd3735: avcodec/x86: move simple_idct to external assembly
[13:37:37 CEST] <cone-326> ffmpeg 03James Darnley 07master:0dea0114fb29: avcodec/x86/idctdsp_init: reindent
[13:37:51 CEST] <kierank> !!!
[13:38:27 CEST] <wm4> J_Darnley: nice
[13:38:36 CEST] <wm4> is there any important inline asm left?
[13:38:44 CEST] <cousin_luigi> Thanks & bbl.
[13:38:45 CEST] <BtbN> I wonder what that 9th memory slot is for. For some Optane-Persistent-Memory-Thing?
[13:39:30 CEST] <wm4> kierank: so given this pain, why does mp4 mandate separate packets for field slices?
[13:39:38 CEST] <wm4> doesn't that make it worse
[13:42:31 CEST] <wm4> kierank: also do I get this right: PAFF: separate field slices (each which decode on their own, more or less, but can easily decoded to an interleaved frame), MBAFF = single slice that decodes to an interleaved frame?
[13:43:18 CEST] <kierank> correct
[13:45:33 CEST] <wm4> kierank: and it's normal that streams switch between those on demand? somehow I thought that's what MBAFF is supposed to do on the macroblock level
[13:45:50 CEST] <kierank> mbaff helps coding "mostly progressive" pictures
[13:45:58 CEST] <kierank> paff helps with prediction between fields
[13:46:39 CEST] <wm4> hm I guess it makes sense that paff seems to happen more in scenes with actual motion?
[13:46:53 CEST] <kierank> yes
[13:48:00 CEST] <wm4> I guess that's the reason why those second fields don't have PTS - they're missing for MBAFF coded frames anyway
[13:51:52 CEST] <kierank> huh
[13:52:06 CEST] <kierank> they don't have PTS because you don't need PTS in mpegts for some proportion of frames
[13:52:13 CEST] <kierank> and the world is cfr so who cares
[13:52:22 CEST] <kierank> it's only FOSS that's obsessed with vfr
[13:53:28 CEST] <wm4> last I checked mp4 is obsessed with having correct timestamps too
[13:54:54 CEST] <kierank> pts + fps
[13:54:54 CEST] <kierank> done
[14:40:22 CEST] <saulotoledo> Hello all. I need some help to understant the MPEG TS: A TS packet can contain an extended section, used as a "container" for PAT and PMT, for example. In a header of an extended section there are 2 parameters I do not understand: "versionNumber" and "currentNextIndicator". Can somebody help me to understand what they are used for?
[14:41:08 CEST] <saulotoledo> *understand
[14:43:32 CEST] <kierank> you change the pmt, you change the version
[14:43:33 CEST] <kierank> simples
[14:50:29 CEST] <saulotoledo> kierank: thanks! When will you need to change the PMT? It should not be the same for the same program?
[14:50:44 CEST] <kierank> change the language or whatever
[14:51:00 CEST] <kierank> but imo it's meaningless the version
[14:51:05 CEST] <kierank> just check the cc for discontinuity and resync
[14:52:28 CEST] <saulotoledo> kierank: ok :) And about the currentNextIndicator?
[14:52:48 CEST] <kierank> dunno why that's their
[14:52:51 CEST] <kierank> to preroll content i guess
[15:02:37 CEST] <saulotoledo> kierank: kierank: These are the explanations I have about that field: "now or next  either table to be used for current event transmissions or for future"     or yet     "When the values is defined in 1 indicates that the sent Program Association Table (PAT) is valid and applicable in the moment. When the this value is 0 indicates that the sent table is not applicable and the system must await for the next v
[15:03:42 CEST] <saulotoledo> kierank: The strange thing is I do not understand when a PAT is not applicable.
[15:03:53 CEST] <kierank> when they are going to change the pat
[15:05:57 CEST] <saulotoledo> kierank: Why will they send a package that is useless? It makes sense to send a package that will be used for a future PAT?
[15:07:58 CEST] <saulotoledo> kierank: I may be receiving a packet containing a PMT and currentNextIndicator = 0. I still do not understand when this can happen.
[15:08:16 CEST] <kierank> saulotoledo: dunno, it's a theoretical problem
[15:08:19 CEST] <kierank> i doubt anyone uses that
[15:14:11 CEST] <saulotoledo> kierank: ok. So the idea is that the last sent PAT table will be changed and the package will be pointed in a future PAT table?
[15:14:27 CEST] <kierank> dunno
[15:15:50 CEST] <saulotoledo> kierank: ok :) You helped me a lot, anyway. Really thanks!
[15:19:21 CEST] <saulotoledo> kierank: Ah! Just a last question about the version number: If I am receiving another table (AIT? or anything else than a PAT), the version number is related to the last PAT or to the current content?
[16:01:39 CEST] <wm4> Paranoialmaniac: what's the reason matroskadec doesn't parse on hevc? (you added this code)
[16:02:20 CEST] <wm4> not that I have a problem or bug with it, just curious
[17:28:12 CEST] <Paranoialmaniac> wm4: you can extract codec parameters from extradata, and one access unit per packet is guaranteed. so i think the parser is not needed for matroska
[17:29:08 CEST] <wm4> AVSTREAM_PARSE_HEADERS doesn't try to split packets, it only tries to extract information from them
[17:42:49 CEST] <atomnuker> ubitux: seems like a polyfuse got tripped because the odroid works fine now
[17:42:51 CEST] <Paranoialmaniac> wm4: but parameter sets are conveyed out-of-band like mp4. not together with any access unit.
[17:43:41 CEST] <wm4> in theory, but there are all kinds of reasons why libavformat/utils.c wants to look at packet contents anyway
[17:43:44 CEST] <wm4> unfortunately
[17:43:51 CEST] <Paranoialmaniac> :(
[17:46:53 CEST] <wm4> also fuck the timestamp garbage in libavformat/utils.c and ffmpeg.c
[17:48:13 CEST] <kierank> wm4: the undocumented garbage
[17:48:16 CEST] <kierank> that's the probelm
[17:48:21 CEST] <wm4> no, all of it
[17:48:23 CEST] <kierank> if there were comments saying *do x because of y*
[17:48:50 CEST] <wm4> currently I'm dealing with it generating invalid dts from the unreliable mkv framerate field
[17:49:00 CEST] <wm4> which breaks even mkv->mkv remuxing
[17:55:48 CEST] <kierank> ah well that's mkvs fault
[17:55:50 CEST] <kierank> for not having dts
[17:59:42 CEST] <wm4> except for that whole thing that ffmpeg.c wouldn't need DTS in this case
[18:01:03 CEST] <wm4> also didn't you say that timestamps don't matter
[18:01:06 CEST] <wm4> so which is it
[18:07:55 CEST] <wm4> oh, it does not compute dts from durations
[18:08:01 CEST] <wm4> so I'm completely lost
[18:50:07 CEST] <kevmark> Hey everyone. Currently working on this patch: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-May/211719.html My question is what is the best way to submit an updated patch? I tried to do that here: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-May/211786.html By using git send-email with the --in-reply-to option. It seems to work as expected except it created a new patch in Patchwork. Is that the desired behavior?
[18:54:15 CEST] <jamrial> kevmark: the patch subject is different, so maybe that's why
[18:54:59 CEST] <kevmark> jamrial, okay, so when submitting an updated patch it's critical to use the same subject even if the first line of the git commit has changed?
[18:55:17 CEST] <JEEB> no
[18:55:24 CEST] <JEEB> as long as the in-reply-to is correct
[18:55:39 CEST] <JEEB> patchwork can be meh
[18:56:06 CEST] <kevmark> Okay, so how I approached it is fine?
[18:56:08 CEST] <JEEB> since there is no UUIDs in the e-mail I guess
[18:56:38 CEST] <JEEB> well yea, if your in-reply-to was correct then that's all that matters really. patchwork not finding it is unfortunate but I think that's how it has been for me as well
[18:57:50 CEST] <kevmark> Okay great, Pipermail has the original patch as the "Previous message (by thread)" so it looks good
[18:59:45 CEST] <kevmark> Thanks for my help. First patch to FFmpeg (and really any project that uses this form of patch submission) so I'm just trying to familiarize myself with the workflow.
[18:59:50 CEST] <kevmark> *Thanks for the help
[00:00:00 CEST] --- Wed May 31 2017