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

burek burek021 at gmail.com
Sat Jan 7 03:05:04 EET 2017


[00:03:05 CET] <iive> does it matter? he wants to work on something he finds fun and easy
[00:03:15 CET] <iive> why do you have to second guess his motives
[00:12:31 CET] <llogan> why do you have to second guess that he is second guessing? ACTIVATE IMMEDIATE SCORN & DOUBT!
[00:14:28 CET] <Chloe> 19:50:12 <@Compn> Sesse : you need a hex rays license? ask kodi , they can probably buy you one
[00:14:36 CET] <Chloe> guess it's time to do some reversing for kodi
[00:15:16 CET] <Sesse> haha
[00:15:26 CET] <Sesse> I doubt kodi would buy random people hex-rays licenses
[00:15:33 CET] <Sesse> they're... expensive
[00:16:48 CET] <Chloe> I guess I'm a random people now
[00:17:09 CET] <Sesse> I am
[00:17:12 CET] <llogan> urandom
[00:20:48 CET] <JEEB> oh nice, MS fixed the MSVC 2015U3 optimizer wrt the failing FATE test
[00:20:53 CET] <JEEB> https://support.microsoft.com/en-us/kb/3207317
[00:22:49 CET] <BtbN> And nvidia fixed a bug in nvenc that was mentioned on the ml!
[01:10:32 CET] <blb> Sesse: here's some more shq files http://heapify.org/tmp/shqx.7z
[01:11:08 CET] <Sesse> blb: thank you!
[01:12:34 CET] <Sesse> blb: are these redistributable for ffmpeg's test suite?
[01:12:40 CET] <blb> that's fine
[01:13:08 CET] <Sesse> thanks. I have no idea how FATE works in practice, but others can probably explain to me later
[01:14:07 CET] <Sesse> great, shq[0-579] samples
[01:14:18 CET] <Sesse> I had no idea shq1 even existed in the wild
[01:14:35 CET] <blb> the ones with alpha have a real alpha channel as well
[01:14:48 CET] <blb> if you bring into an editor or something, you can overlay it
[01:14:51 CET] <Sesse> very nice
[01:18:19 CET] <Sesse> hm, I messed up shq4 somehow
[01:18:43 CET] <Sesse> I suppose the chroma macroblocks are ordered slightly differently
[01:18:47 CET] <Sesse> so that the codec can be more general
[01:19:14 CET] <Sesse> yup
[01:19:17 CET] <Sesse> reordering them helped
[01:20:52 CET] <Sesse> so shq4 works
[01:24:06 CET] <Sesse> shq0 works
[01:24:33 CET] <blb> that's awesome :D
[01:28:21 CET] <Sesse> alpha will definitely wait for tomorrow
[01:28:23 CET] <Sesse> time to sleep now :-)
[02:08:36 CET] <Compn> blb : aww , you helpful :)
[02:32:11 CET] <Compn> QDMC compatible decoder
[02:32:12 CET] <Compn> lol
[02:33:06 CET] <Compn> like aac bitstream writer 
[04:38:55 CET] <BBB> Compn: hey thats unfair, we have a lot of decoders for relatively impopular codecs, thats totally fine
[04:39:00 CET] <BBB> Compn: its not an encoder ;)
[04:49:57 CET] <Compn> i was just making fun of the title of the decoder
[04:50:03 CET] <Compn> i fully support having decoders for these formats
[07:13:39 CET] <Compn> and durandal_170 is awesome for working on them
[09:20:26 CET] <atomnuker> peloverde: do you know how the scale parameter to ff_mdct_init() is derived for different codecs?
[09:41:30 CET] <Sesse> uhm. what pixel format do I want to tell ffmpeg for alpha?
[09:41:45 CET] <Sesse> the only alpha formats I can find are gray+alpha
[09:44:24 CET] <Sesse> ah, YUVA422P
[12:31:09 CET] <cone-956> ffmpeg 03Paul B Mahol 07master:520c0736fd20: avfilter/vf_shuffleframes: allow also dropping frames
[15:47:05 CET] <bofh_> atomnuker: I believe it's just 1/norm or 1/(framesize*norm), where norm is the largest possible magnitude of the codec to output according to thebspec for it
[15:47:23 CET] <bofh_> the*
[15:47:41 CET] <Sesse> does anyone know what audio codec could have a fourcc of fowt?
[15:47:51 CET] <Sesse> supposedly sowt is regular 16-bit little-endian pcm
[15:49:28 CET] <kierank> Sesse: didn't we figure this one out?
[15:49:30 CET] <kierank> not that i can remember
[15:49:32 CET] <Sesse> kierank: no
[15:51:18 CET] <BBB> f implies float
[15:51:33 CET] <Sesse> that was my guess, too
[15:51:36 CET] <bofh_> Sesse: kierank: https://wiki.multimedia.cx/index.php/PCM#Apple_QuickTime_Identifiers
[15:51:53 CET] <Sesse> bofh_: no fowt there
[15:51:55 CET] <bofh_> it's Quicktimese for s16le LPCM
[15:52:07 CET] <kierank> sowt, yes
[15:52:12 CET] <kierank> but fowt?
[15:52:50 CET] <bofh_> https://sourceforge.net/p/libquicktime/mailman/message/6133327/
[15:53:08 CET] <bofh_> er wring link
[15:54:38 CET] <bofh_> I'd likely bet on little-endian floats though
[15:54:39 CET] <BBB> Sesse: so Im going to guess that you may have to write a simple 16bit float to 32bit float unpacking decoder or so
[15:55:01 CET] <Sesse> hm, fp16 would be an interesting guess
[15:55:02 CET] <Sesse> so perhaps
[15:55:24 CET] <kierank> 16-bit float is a bit odd
[15:55:50 CET] <BBB> & a bit ...?
[15:56:04 CET] <Sesse> it's completely fine in graphics
[15:56:26 CET] <Sesse> half the bitrate, no big disadvantages
[15:56:26 CET] <Sesse> s/bitrate/memory bandwidth/
[15:58:18 CET] <BBB> yeah
[16:06:54 CET] <bofh_> BBB: I've on record many times stated I'd rather have to use 16-bit floats to implement an audio codec than 32-bit fixed-point. For storage it's even more reasonable, you get double the memory throughput compared to f32 and better use of dynamic range compared to s16.
[16:07:30 CET] <bofh_> (this is assuming it's not just a typo/bitflip of 'sowt' in the first place)
[16:08:17 CET] <BBB> s=0x73, f=0x66, so a bitflip seems & unlikely
[16:08:36 CET] <BBB> also its exactly f, not any other random letter& f has a very specific meaning in quicktimese as well as generic audio processing
[16:08:50 CET] <BBB> its possible its random& but Id be genuinely surprised
[16:11:38 CET] <bofh_> I was thinking more 'one is 0b01110011 & the other 0b01100110"
[16:14:04 CET] <BBB> they dont look very much alike do they? :)
[16:16:07 CET] Action: kierank shoots a cosmic ray at BBB
[16:16:14 CET] <bofh_> shift left by one, mask to 7 bits, but I blame working on decoding highly lossy channels for warping my brain
[16:16:20 CET] <bofh_> (decoding space probe telemetry)
[16:19:39 CET] <BBB> we should place a bet :-p
[16:20:59 CET] <kierank> i've been meaning to use my 2.4m dish to downlink deep space stuff
[16:24:46 CET] <bofh_> you should be able to get some stuff from a bunch of the stuff in the L1/L2 Lagrange points easily. (well if you integrate over a long enough time even, say, Juno's carrier will be picked up on that, assuming you track it. but I'm assuming you want Eb/N0 high enough to get data bits out :P)
[16:25:46 CET] <JEEB> satellite stuff reminds me that NHK started airing "8K" with TLV+MMTP over UDP from one of their satellites
[16:26:14 CET] <kierank> JEEB: I am so sorry
[16:26:30 CET] <JEEB> I've got a morbid curiosity at how that shit looks
[16:26:30 CET] <kierank> they are literally on crack
[16:26:34 CET] <JEEB> overcomplicated to hell
[16:26:55 CET] <JEEB> kierank: yes - or doing a "who gets the most pants-on-head retarded thing into production"
[16:26:56 CET] <Sesse> JEEB: wait, udp on top of mpeg-ts?
[16:26:59 CET] <JEEB> drinking game
[16:27:10 CET] <kierank> Sesse: no a new format
[16:27:14 CET] <kierank> instead of mpegts
[16:27:18 CET] <kierank> with lots of xml and lots of patented crap
[16:27:21 CET] <Sesse> well, less overhead
[16:27:24 CET] <kierank> multiple timelines
[16:27:29 CET] <JEEB> IP over broadcast and then MMTP over UDP on top of that
[16:28:18 CET] <JEEB> Sesse: https://www.itu.int/rec/R-REC-BT.1869-0-201003-I/en this is the thing that's called TLV methinks
[16:28:34 CET] <Sesse> I love standards that come in word 2007 format
[16:28:38 CET] <Sesse> itu ftw
[16:28:40 CET] <JEEB> and then the complexity keeps on going higher
[16:29:33 CET] <JEEB> Sesse: see page 7 http://www.arib.or.jp/english/html/overview/doc/6-STD-B62v1_2-1p2-E1.pdf
[16:29:39 CET] <JEEB> the protocol stack(s)
[16:29:51 CET] <JEEB> the MMT one is what they actually put there
[16:30:53 CET] <Sesse> monomedia comding!
[16:31:03 CET] <Sesse> opposite of multimedia
[16:37:39 CET] <bofh_> JEEB: oh my god this reads straight out of, like, the multimedia necronomicon
[16:38:03 CET] <bofh_> "well our link budget is somewhat restricted. let's use a protocol that has high overhead, and then add bullshit!"
[16:41:23 CET] <kierank> bofh_: adding bullshit is what gets you patents
[16:41:45 CET] <kierank> TS overhead is high for framing reasons but back then they didn't have all the cpu in the world to play with so they actually made it simple
[16:42:21 CET] <kierank> mmt is gratuitous adding by committee
[16:43:02 CET] <JEEB> yup
[16:50:27 CET] <cone-594> ffmpeg 03Michael Niedermayer 07master:bc6b53ae99cd: avfilter/asrc_flite: Fix textbuf leak
[17:56:18 CET] <durandal_170> michaelni: fine to push qdmc?
[18:11:38 CET] <cone-594> ffmpeg 03Kevin Wheatley 07master:09905c412ddb: libavcodec/exr: Fix blank output when data window != display window
[18:13:40 CET] <michaelni> durandal_170, ok
[19:16:26 CET] <Sesse> shq7 and shq9 work
[19:26:19 CET] <Compn> Sesse : any reason why working on those codecs ? 
[19:26:28 CET] <Compn> we are curious if money or job etc
[19:27:22 CET] <Sesse> no commercial interest, but if anyone wants to give me money, my account is always open :-P
[19:33:45 CET] <Compn> ehe
[19:34:53 CET] <Compn> kierank : whatever happened to redcode stuff? is it on ignore because r3d cameras use a different/better codec now ? or ... im asking because you are close to the 10bit mpeg4 , why not do the bayer red stuff ? :D
[19:35:19 CET] <Compn> next i mean
[20:00:53 CET] <cone-594> ffmpeg 03Andreas Cadhalpun 07master:d74c471a39db: omadec: fix overflows during bit rate calculation
[20:04:13 CET] <peloverde> atomnuker: In practice, play with it until you get the scale you need. In theory, dig through the codec's spec/source for the scaling on their mdct and divide by the one on ours.
[20:11:02 CET] <bofh_> peloverde: what is the rationale behind dividing by the frame size of the MDCT transform?
[20:11:15 CET] <bofh_> oftentimes it seems values are already in a sensible range without that.
[20:11:35 CET] <bofh_> yet a lot of codecs will scale by 1/1024 for size-1024 MDCT frames on output, etc
[20:38:41 CET] <cynn> hellp
[20:38:46 CET] <cynn> *hello
[20:38:50 CET] <cynn> anyone here :P
[21:47:33 CET] <cone-594> ffmpeg 03Paul B Mahol 07master:49633f9f7498: avcodec/iff: add support for vertical word compression in ILBM
[21:54:05 CET] <durandal_170> Sesse: videolan may give bounty for it
[22:10:19 CET] <cone-594> ffmpeg 03Paul B Mahol 07master:90ac9f4094af: avcodec: add QDMC decoder
[22:20:28 CET] <Sesse> durandal_170: ha, you're right
[22:21:26 CET] <Sesse> durandal_170: unclear price, though
[22:22:03 CET] <durandal_170> ask j-b 
[22:24:48 CET] <kierank> j-b: xavc-s files decode fine
[22:27:58 CET] <Chloe> durandal_170: did you collect the pixlet bounty then? (doesn't seem to be ticked off)
[22:29:38 CET] <durandal_170> I need to know exact amount first and then sent patches to vlc and invoice
[22:35:35 CET] <atomnuker> WE DID ID
[22:35:38 CET] <atomnuker> https://0x0.st/fH2.jpg
[22:35:44 CET] <atomnuker> ffmpeg_TempleOS
[22:38:25 CET] <rcombs> wat even
[22:38:38 CET] <rcombs> >&single-address-space, ring-0-only&
[22:38:50 CET] <rcombs> there are bad ideas, and then there's this
[22:42:29 CET] <durandal_170> funny
[22:42:55 CET] <atomnuker> (actually that's probably just a script to record a qemu window)
[22:43:33 CET] <atomnuker> either way, a step closer to heaven
[22:43:42 CET] <durandal_170> lol
[22:44:40 CET] <rcombs> oh this tangentially reminds me
[22:45:09 CET] <kierank> atomnuker: jesus wept
[22:45:11 CET] <rcombs> there was an episode of Elementary a while back where the characters pull up the metadata on a media file (to find more info about the camera that recorded it)
[22:45:23 CET] <rcombs> and it shows the muxing app was lavf
[00:00:00 CET] --- Sat Jan  7 2017


More information about the Ffmpeg-devel-irc mailing list