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

Thu Feb 9 03:05:03 EET 2017

[00:14:14 CET] <ubitux> atomnuker: haha, i have it in a box so it's less annoying here :)
[00:35:21 CET] <Compn> crack it open and cut the wires
[00:35:23 CET] <Compn> cut the blue wire!
[00:37:56 CET] <atomnuker> there is no blue wire, but I have a soldering iron and I'm not afraid to use it
[00:38:47 CET] <atomnuker> though I ran out of tin and I don't think they SELL THAT HERE in a store you can walk in and buy
[00:41:33 CET] <atomnuker> online stores will treat you like someone expecting to buy like 10 000 units and/or make you pay out of your nose for delivery
[01:06:36 CET] <Compn> atomnuker : you dont have amazon in your country ?
[01:06:41 CET] <Compn> or ... ebay
[01:06:52 CET] <Compn> probably can even check craigslist in uk
[01:07:15 CET] <Compn> or just go to a electronics repair store and buy a roll from them ?
[01:07:29 CET] <Compn> if they still have electronic repair stores. thats last century stuff
[01:21:12 CET] <TD-Linux> atomnuker, rs-online probably has it in the uk
[01:41:32 CET] <hyponic> Willing to pay for a quick mod from a dev or a c programmer familiar with ffmpeg. 1 hour job. Please PM me.
[01:49:30 CET] <hyponic> https://trac.ffmpeg.org/ticket/5913 - make libzvbi give a picture format ffmpeg's dvbsub encoder understands or make ffmpeg understand the output libzvbi have now
[02:05:09 CET] <Chloe> Why does it need to be done in 1hr?
[02:06:19 CET] <Chloe> hyponic: *
[02:11:54 CET] <atomnuker> Compn TD-Linux: the point is not having to wait for delivery
[02:14:27 CET] <TD-Linux> you can grab some from me next week :)
[02:14:44 CET] <hyponic> Chloe does not need to be done in 1 hour. it could take as much time as needed. 
[02:14:52 CET] <hyponic> i just had a wild estimation
[02:16:20 CET] <Chloe> hyponic: I can take a look at it tomorrow, if I don't tell you if I want to do it or not tomorrow then ping me (I probably just forgot) 
[02:17:52 CET] <hyponic> Chloe thanks, let's chat more about it tomorrow. but i am not always watching this chat so please pm me tomorrow. or i will ping you if you don't-
[02:46:11 CET] <Compn> heh
[02:46:35 CET] <Compn> just say "threadsafe" and out pops a patch to name 22 codecs already threadsafe :)
[02:46:59 CET] <Compn> communications have broken down :(
[02:49:15 CET] <Compn> Cannot find codec for audio format 0xAAC
[02:49:19 CET] <Compn> oh no, no no no
[04:08:19 CET] <cone-698> ffmpeg 03Matt Wolenetz 07master:fd30e4d57fe5: lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
[04:08:19 CET] <cone-698> ffmpeg 03Matt Wolenetz 07master:2d453188c230: lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
[06:30:48 CET] <wm4> atomnuker: use a hammer
[12:36:44 CET] <Chloe> Is multiple languages in one subtitle stream exclusive to DVB? Does FFmpeg support it at all for anything else?
[12:40:10 CET] <wm4> vobsub files can have multiple streams, but they're represented as separate AVStreams
[12:49:37 CET] <nevcairiel> yeah afaik everything else just has separate streams
[13:25:47 CET] Action: wm4 hates on sub2video
[13:26:53 CET] <JEEB> it is awful
[13:27:03 CET] <JEEB> but at least nowadays it seems to re-init itself
[13:27:04 CET] <JEEB> :)
[14:09:18 CET] <wm4> -#sar 0: 0/1
[14:09:18 CET] <wm4> +#sar 0: 9/10
[14:09:26 CET] <wm4> that looks like a good change rather than a regression
[14:10:21 CET] <wm4> though I have not the slightest idea why this happens (with exr)
[14:43:30 CET] <durandal_1707> wm4: do you change exr code?
[14:46:17 CET] <wm4> no
[14:46:22 CET] <wm4> ffmpeg.c only
[14:50:18 CET] <wm4> jkqxz: kabylake doesn't support 12 bit hevc, right?
[14:52:07 CET] <jkqxz> No, it doesn't.  The only >8-bit codec support is 10-bit H.265 encode/decode and 10-bit VP9 decode.
[14:53:36 CET] <wm4> ok
[14:54:08 CET] <wm4> are they affordable kabylake devices yet? like NUCs
[14:56:07 CET] <BtbN> the NUCs have recently started to become available
[14:57:05 CET] <kierank> wm4: there is a really cheap pentium
[14:57:19 CET] <BtbN> Like NUC7i3BNK
[14:57:34 CET] <BtbN> They are not exactly cheap though
[14:59:43 CET] <wm4> kierank: yeah, but I'd need a computer with it too
[15:00:12 CET] <kierank> buy a motherboard, cheap case and ram
[15:00:26 CET] <wm4> annoying and a waste of space
[15:01:05 CET] <jkqxz> If you only want decode, the Apollo Lake NUC is cheaper and has 10-bit H.265 decode only.
[15:01:05 CET] <kierank> yeah ours is staking up loads of space
[15:10:01 CET] <cone-277> ffmpeg 03Jerry Jiang 07master:884506dfe2e2: Implement optimal huffman encoding for (M)JPEG.
[15:21:49 CET] <atomnuker> BBB: how is ycgco support nonexistant?
[15:22:01 CET] <BBB> maybe I shouldve said was
[15:22:15 CET] <BBB> right now its minimal
[15:22:23 CET] <BBB> swscale cannot convert ycgco to rgb, for example
[15:22:27 CET] <BBB> it will interpret it as yuv
[15:24:42 CET] <BBB> the colorspace filter will convert it correctly (thanks to vittorio), but only outputs yuv, not rgb
[15:24:45 CET] <BBB> so its sort of silly
[15:24:47 CET] <wm4> does libavcodec still print a silly warning?
[15:25:02 CET] <wm4> no
[15:25:03 CET] <wm4> nice
[15:25:37 CET] <BBB> muhahahahahahahhahaha
[15:25:42 CET] <BBB> (this is swscale, not avcodec)
[15:25:44 CET] <durandal_1707> is libp2p going to be part of zscale?
[15:25:53 CET] <wm4> BBB: yes but libavcodec printed it
[15:26:02 CET] <wm4> anyway, I think it would be no problem to make cinepak output a better format than rgb24
[15:27:12 CET] <atomnuker> BBB: how to make vf_colorspace output ycgco? what do the trc/primaries need to be?
[15:27:44 CET] <BBB> atomnuker: AVCOL_SPC_YCOCG
[15:28:12 CET] <BBB> and then whatever trc/primaries are appropriate, I dont think it matters much
[15:28:33 CET] <BBB> wm4: -epatchwelcome :)
[15:30:36 CET] <atomnuker> BBB: don't the trc/primaries need to support the colorspace?
[15:30:54 CET] <BBB> I think its orthogonal
[15:32:30 CET] <wm4> BBB: I mean, the warning was removed
[15:32:45 CET] <wm4> oh, by me
[15:32:47 CET] <wm4> in 2015
[15:32:49 CET] <BBB> hahaha
[15:35:41 CET] <wm4> so, now I only have some fate-lavf- tests failing
[15:35:47 CET] <wm4> the failing formats are ffm and mxf
[15:35:54 CET] <wm4> and I have no idea how to debug this
[15:36:08 CET] <wm4> -f9b570c7b4fbbc2b71f2236b32e7cbb6 *./tests/data/lavf/lavf.mxf
[15:36:08 CET] <wm4> +c61e677b4facc407ca82b1d7c6298484 *./tests/data/lavf/lavf.mxf
[15:36:13 CET] <wm4> what do these numbers mean
[15:36:25 CET] <wm4> (I seriously can't find out how this make mess generates them)
[15:37:14 CET] <durandal_1707> look at differences in output
[15:37:33 CET] <wm4> which output
[15:37:34 CET] <durandal_1707> hexdiff or something like that
[15:37:41 CET] <nevcairiel> the lavf tests just test checksums
[15:38:00 CET] <wm4> and what's the CRC in the line below?
[15:39:28 CET] <durandal_1707> than remove stupid test, check fate invocation and than see output it should usually give
[15:40:04 CET] <wm4> not sure what you're saying
[15:40:58 CET] <jamrial> run make fate-lavf-mxf V=1
[15:41:15 CET] <jamrial> it will show you what command line it runs
[15:41:38 CET] <wm4> I know
[15:41:40 CET] <nevcairiel> the first is the md5 checksum of the generated file, then it generates a second set of crc and file size info, not sure why its duplicated
[15:41:50 CET] <BBB> and then change output file md5:- into /tmp/test.mxf
[15:42:07 CET] <BBB> so you can hexdiff the file instead of just stare at the md5
[15:43:36 CET] <wm4> what was daemon's hexdiff program again?
[15:44:01 CET] <nevcairiel> often you can already see differences in the ffmpeg output
[15:44:07 CET] <nevcairiel> like aspect changes or whatnot
[15:44:29 CET] <wm4> I dumped both files earlier, but they were identical (packets/frames)
[15:44:37 CET] <wm4> I'll retry that just to confirm
[15:45:08 CET] <RiCON> wm4: https://github.com/dwbuiten/bxd
[15:45:16 CET] <wm4> RiCON: thanks
[15:45:58 CET] <wm4> yeah, -show_packets is the same
[15:46:26 CET] <wm4> -show_streams too
[15:46:53 CET] <nevcairiel> i would suggest to start diffing the ffm format instead of mxf, its possible they suffer from the same problem, and ffm is a simpler format to read
[15:47:14 CET] <nevcairiel> its a dumb format, but easy to see differences in =p
[15:48:47 CET] <nevcairiel> are you doing the big one already, or just the small one before that?
[15:49:42 CET] <durandal_1707> atomnuker: push ffserver removal patch. when?
[15:50:17 CET] <wm4> -field_order=unknown
[15:50:17 CET] <wm4> +field_order=progressive
[15:50:21 CET] <wm4> ffm has a simple reason
[15:50:35 CET] <nevcairiel> sounds like a property mxf might store as well
[15:50:50 CET] <wm4> if so, then the mxf demuxer doesn't read it
[15:50:57 CET] <nevcairiel> possible
[15:51:37 CET] <wm4> anyone happens to know how field_order is passed through all the layers?
[15:52:27 CET] <nevcairiel> its just another codec parameter, i woudl think
[15:52:50 CET] <atomnuker> durandal_1707: patch dropped, lol
[15:52:57 CET] <wm4> oh indeed
[15:53:02 CET] <durandal_1707> nooooo
[15:53:32 CET] <durandal_1707> we will never get rid of that crap
[15:55:26 CET] <jamrial> not dropped, just waiting until the next major bump
[15:59:56 CET] <atomnuker> when is that?
[16:00:08 CET] <nevcairiel> BBB: its fascinating that a format nearly 25 years old used YCgCo and yet it never really became popular as a color space
[16:00:33 CET] <BBB> its very interesting, yes
[16:00:35 CET] <jamrial> atomnuker: sometime this year, i hope
[16:01:17 CET] <nevcairiel> it probably only became known like that much later anyway
[16:01:30 CET] <nevcairiel> and whoever made that format just thought it was a simple way to decorrelate
[16:02:09 CET] <BBB> right
[16:02:14 CET] <BBB> I tihnk its actually patented
[16:02:31 CET] <nevcairiel> is it actually fully exact ycgco?
[16:02:34 CET] <BBB> or at least I saw patents about ycgco signaling in sps (h264)
[16:02:40 CET] <BBB> you mean the cinepak format?
[16:02:44 CET] <nevcairiel> yea
[16:02:44 CET] <BBB> I have no idea
[16:04:50 CET] <nevcairiel> but its video stuff, so i'm sure its all patented somewhere
[16:09:26 CET] <wm4>             if (enc->codec->id == AV_CODEC_ID_MJPEG)
[16:09:26 CET] <wm4>                 mux_par->field_order = in_picture->top_field_first ? AV_FIELD_TT:AV_FIELD_BB;
[16:09:26 CET] <wm4>             else
[16:09:26 CET] <wm4>                 mux_par->field_order = in_picture->top_field_first ? AV_FIELD_TB:AV_FIELD_BT;
[16:09:28 CET] <wm4> wat...
[16:10:13 CET] <BBB> hahahahahah :)
[16:11:13 CET] <nevcairiel> these 4 field order values are so confusing
[16:11:32 CET] <nevcairiel> noone cares about coding order, we just want to know which to display first
[16:12:20 CET] <iive> top top ; bottom bottom ??!
[16:33:23 CET] <wm4> ok fate passes now
[16:33:47 CET] <wm4> now I need to fix cuvid and qsv
[16:33:56 CET] <wm4> I can't actually test cuvid
[16:35:12 CET] <jkqxz> Yay!
[16:35:36 CET] <BtbN> wm4, what did you change? Anything I should test?
[16:35:37 CET] <jkqxz> Fixing qsv should just be deleting qsv_transcode_init().
[16:36:39 CET] <wm4> there's much more icky stuff
[16:37:04 CET] <wm4> actually that was in qsv_transcode_init
[16:38:25 CET] <wm4> what about qsv_device_init?
[16:39:16 CET] <jkqxz> Oh, you need to add a hwaccel init function.  Just copy avconv_qsv.c.
[16:39:58 CET] <wm4> cuvid has a similar global init function
[16:40:01 CET] <jkqxz> Oops, no.  It's already there.
[16:40:23 CET] <wm4> -    frames_ctx->initial_pool_size = 64;
[16:40:23 CET] <wm4> +    frames_ctx->initial_pool_size = 32;
[16:40:24 CET] <wm4> wut
[16:40:33 CET] <wm4> (FFmpeg changed it to 64)
[16:40:59 CET] <jkqxz> The surface count is higher because lookahead got enabled by default on the ffmpeg version of the qsv encoder.
[16:41:36 CET] <jkqxz> And I kept that because only half of the rate control modes work on any given version/platform, so it would break existing people.
[16:41:54 CET] <wm4> after restoring minor ffmpeg changes, Libav's literally removes only qsv_transcode_init
[16:42:27 CET] <jkqxz> Good!
[16:42:46 CET] <wm4> cuvid looks much more problematic
[16:43:38 CET] <BtbN> I'd still like to get rid of most of it, but the patch for the hw_device_ctx is still pending
[16:43:39 CET] <jkqxz> cuvid has broken use of the hw_frames_ctx API, that's why libav rejected it in it's current form.
[16:43:54 CET] <jkqxz> Yeah, which we are hoping to fix with hw_device_ctx.
[16:45:18 CET] <jkqxz> I'll push a bit more on that, elenril has yet to express any particular approval.
[16:45:25 CET] <wm4> I can test qsv later, but my cuda drivers or whatever are broken
[16:46:26 CET] <RiCON> git master seems broken: https://i.fsbn.eu/Pwht.txt
[16:47:28 CET] <wm4> pushed my changes so far here: https://github.com/wm4/FFmpeg/commits/filter-merge
[16:47:40 CET] <RiCON> the @ were converted to " at " in 4a23abfa5d
[16:48:04 CET] <wm4> BtbN, philipl: if you could maybe look at ffmpeg_cuvid.c?
[16:48:15 CET] <RiCON> in 884506dfe2  i mean
[16:49:13 CET] <wm4> d2e56cf,94ebf55 are still missing (supposedly needed to prevent random fate failures)
[16:49:49 CET] <BtbN> wm4, I'll have a look. Is it normal that github claims that branch to be 5080 commits behind master?
[16:50:19 CET] <jkqxz> wm4:  I'll test with that later (qsv, vaapi).
[16:50:27 CET] <BtbN> hm, seems to be some kind of glitch on github
[16:50:32 CET] <BtbN> it's definitely up to date
[16:50:36 CET] <wm4> BtbN: my fork is rather outdated
[16:50:38 CET] <jamrial> btw, another commit that was skipped during merges is 5fa255b
[16:50:50 CET] <BtbN> wm4, but not _that_ outdated on that branch.
[16:50:58 CET] <wm4> jamrial: ok
[16:51:27 CET] <jamrial> not sure if it's related to these filter changes, but could be since it deals with frame_rate
[16:51:40 CET] <wm4> not sure
[16:51:52 CET] <wm4> but entirely possible
[16:54:13 CET] <RiCON> atomnuker: http://sprunge.us/AEOi
[16:55:54 CET] <cone-277> ffmpeg 03Ricardo Constantino 07master:dac51d2bbdb0: doc/encoders: fix broken build with 884506dfe2e
[16:56:19 CET] <atomnuker> RiCON: my fault for never building without --disable-doc, tnx
[16:57:27 CET] <BtbN> Why am I getting tens of thousands of this warning when building ffmpeg on msvc 2015 now: "warning C4828: Die Datei enth’lt ein Zeichen, das bei Offset 0x1af beginnt. Dieses Zeichen ist im aktuellen Quellzeichensatz (Codepage 65001) unzul’ssig."
[16:57:55 CET] <BtbN> Not only in config.h, also affects a lot of other files. But due to it being in config.h it shows up _a lot_
[16:58:30 CET] <jamrial> BtbN: related to the utf-8 changes by nevcairiel it seems
[16:58:39 CET] <jamrial> maybe we should mute it
[16:58:48 CET] <BtbN> #define CC_IDENT "Microsoft (R) C/C++-Optimierungscompiler Version 19.00.24218.1 fr x64"
[16:58:53 CET] <BtbN> i blame this one
[16:59:02 CET] <BtbN> that fr x64 should be für x64
[16:59:07 CET] <wm4> such irony
[16:59:16 CET] <wm4> I see boxes instead of umlauts here
[16:59:32 CET] <BtbN> yes, that's the msvc compiler not outputting utf8
[16:59:45 CET] <BtbN> it also shows boxes in my terminal
[17:11:41 CET] <philipl> wm4: You're doing more merges from libav? Up past the big avconv rewrite?
[17:12:20 CET] <BtbN> "[h264_nvenc @ 000001CBA58F7360] EncodePicture failed!: out of memory (10)" ...what? Need to verify if this still works on master.
[17:12:38 CET] <philipl> Reboot :-)
[17:14:38 CET] <wm4> philipl: I'm merging specific commits that have been skipped in past merges
[17:18:17 CET] <philipl> out of memory (10)
[17:18:21 CET] <philipl> so yeah, something changed.
[17:23:21 CET] <BBB> hey jamrial & about huffyuvdsp c code optimizations
[17:23:41 CET] <BBB> jamrial: isnt this a case of wtf premature optimizations learn to write x86 simd or whatever and toss that code?
[17:23:50 CET] <BBB> or am I being overly cautious?
[17:24:27 CET] <Chloe> Optimal huffman coding was only done today??? 
[17:24:32 CET] <Chloe> Added*
[17:25:41 CET] <Chloe> nevcairiel, wm4: I wonder if changing DVB to work similar to vob with streams would be better
[17:26:42 CET] <wm4> Chloe: the vobsubs thing is a container - if dvb does it on the codec level, that probably won't work
[17:27:55 CET] <Chloe> Oh right. Yeah it is done on a codec level. You should be able to add another page to the DVB stream (by reencoding ofc) but that's not possible atm afaik
[17:28:27 CET] <Chloe> So I was wondering the best way to make the DVB pages --map-apable
[17:34:46 CET] <jamrial> BBB: both patches are probably pointless anyway since those c functions should never be used
[17:35:38 CET] <jamrial> but i noticed icc was seemingly not handling the ULL constants right, so i thought it would be a good idea to make sure they are correct
[17:36:59 CET] <jamrial> actually, there are no simd optimized versions of these for several arches
[17:37:04 CET] <BBB> jamrial: I guess my point was that since theyre likely never used (after all: C where SIMD is present and trivial), maybe they shouldnt be so complicated
[17:37:18 CET] <BBB> are these arches where youd be likely to deal with huffyuv?
[17:37:24 CET] <jamrial> including arm
[17:37:28 CET] <BBB> huffyuv on arm isnt common ;)
[17:37:35 CET] <BBB> huffyuv is for screen recording etc., isnt it?
[17:38:01 CET] <JEEB> Chloe: if you're talking about teletext you have to map the same stream N times and setting -txt_page separately for each map I guess?
[17:40:18 CET] <BtbN> philipl, wm4, yeah, _something_ changed that makes nvenc report out of memory somehow.
[17:40:58 CET] <jamrial> BBB: in any case, the code is there so i see no reason to remove it and replace it with a standard non optimized version
[17:41:02 CET] <BBB> ok
[17:41:08 CET] <jamrial> adding new functions is a different story
[17:45:26 CET] <Chloe> JEEB: yeah
[17:46:44 CET] <Chloe> I want to make it so you don't have to do that, but not sure the best way to make it work with other stuff
[17:51:01 CET] <JEEB> exporting streams from lavc is iffy
[17:51:04 CET] <JEEB> *very* iffy
[17:51:12 CET] <JEEB> the AVC closed captions stuff does it
[17:55:26 CET] <nevcairiel> BtbN: thats what you get for installing a compiler in german =p
[17:55:45 CET] <BtbN> nevcairiel, you don't have a choice about its language.
[17:55:51 CET] <BtbN> And you also can't change it.
[17:55:55 CET] <nevcairiel> well mine is english!
[17:56:07 CET] <BtbN> it strictly sticks to the language the OS is installed in
[17:56:16 CET] <nevcairiel> exactly
[17:56:19 CET] <nevcairiel> so its youir choice
[17:56:20 CET] <nevcairiel> :)
[17:56:27 CET] <wm4> I strictly stick to english
[17:56:30 CET] <BtbN> And I'm not going to re-install the entire OS to change the compiler language
[17:56:32 CET] <wm4> localization is always terrible
[17:57:26 CET] <RiCON> BtbN: in win8/10 changing language is just a language pack away
[17:57:40 CET] <BtbN> RiCON, tried that, msvc doesn't care.
[17:57:53 CET] <BtbN> And I also don't really want to change the OS language.
[17:58:25 CET] <RiCON> shouldn't depend on locale, or else mine would be in pt-PT
[17:58:50 CET] <nevcairiel> maybe it can be fixed by calling the compiler with the /utf-8 switch in the place where its gathering the CC_IDENT?
[17:59:03 CET] <nevcairiel> thats probably long before it sets the cflags
[17:59:13 CET] <BtbN> where does it even set that?
[18:00:05 CET] <nevcairiel> probe_cc()
[18:00:19 CET] <nevcairiel> since mine is all ascii i cant exactly test it
[18:00:32 CET] <nevcairiel> but try adding -utf-8 into the call that fills _ident
[18:01:09 CET] <nevcairiel> the msvc case is the second last
[18:01:12 CET] <BtbN> have to find the right one first...
[18:02:36 CET] <BtbN> testing now, give it a few minutes...
[18:04:36 CET] <BtbN> Nope, doesn't change a thing.
[18:04:57 CET] <BtbN> Probably just gets that from some translation table
[18:07:42 CET] <BtbN> Is it save to assume iconv exists?
[18:07:56 CET] <nevcairiel> probably not
[18:08:10 CET] <BtbN> for all the msvc building platforms, that is
[18:10:33 CET] <nevcairiel> you could probably try to call it and only use the value if it worked
[18:10:59 CET] <BtbN> You can just tell it to strip non-utf8 characters
[18:11:08 CET] <BtbN> everything else would be kind of insane
[18:11:26 CET] <BtbN> As it will probably use varying characters sets depending on the language
[18:12:52 CET] <nevcairiel> doesnt iconv have magic modes that depend on the OS locale
[18:13:03 CET] <nevcairiel> not sure if those are reliable on windows
[18:13:08 CET] <BtbN> I wouldn't trust that to work on Windows
[18:14:01 CET] <nevcairiel> you could handle the most common case and ask it to convert from latin1 or something and strip invalid utf-8 otherwise
[18:18:57 CET] <BtbN> it's aparently not even latin1
[18:22:11 CET] <BtbN> It's also not CP1252 and CP65001
[18:22:59 CET] <BtbN> Not ISO-8859-15 or ISO-8859-1 either
[18:25:27 CET] <BtbN> it's no known charset aparently...?
[18:31:39 CET] <cone-277> ffmpeg 03Michael Niedermayer 07master:c03029a83594: avcodec/h264_slice: Clear ref_counts on redundant slices
[18:37:57 CET] <nevcairiel> CP65001 is MS alias for utf-8
[18:39:17 CET] <nevcairiel> should be cp1252
[18:39:41 CET] <nevcairiel> iconv calls that "windows-1252" i think
[18:40:53 CET] <BtbN> it supports both
[18:41:31 CET] <BtbN> https://bpaste.net/show/9769215b5a02
[18:42:00 CET] <nevcairiel> maybe it doesnt pass properly through head or the pipe, who knows
[18:42:36 CET] <BtbN> removing head doesn't help
[18:50:29 CET] <kierank> michaelni: does c03029a835949fc0e68b4c6558ebcdc3ae137087 need backporting?
[18:51:03 CET] <kierank> and can you add me to ffmpeg-security like I asked please
[18:52:09 CET] <wm4> michaelni: I'm asking for being put on ffmpeg-security too
[18:58:40 CET] <jermy> I've got a quicktime file where the first packet in the video stream is not the smallest PTS. Is that ever legal?
[18:59:23 CET] <jermy> It's got an edit list with a single entry, which seems to being pointing at starting at the second frame (which does have the smallest PTS)
[19:16:41 CET] <wm4> jermy: of course it's legal, due to h264 reordering due to b-frames
[19:20:07 CET] <jermy> which would be fine if this wasnt ending up with the keyframe after the two b-frames
[19:21:44 CET] <jermy> problem is the file start time uses the first pts, and there are frames with negative times, but the audio starting at zero
[19:22:04 CET] <jermy> so its out of sync
[19:22:56 CET] <jermy> and the timecode track too
[19:24:46 CET] <wm4> not sure if I get it
[19:27:15 CET] <jermy> Ill see if I can make an example bit of this content tomorrow and what it should be doing
[19:28:42 CET] <wm4> michaelni: be sure we have working mp4 gapless audio again before you release 3.3
[19:29:50 CET] <jermy> it's storing what looks like the packets in presentation order in the file, rather than decode, and has some weied ctts and edit offsets to compensate
[19:31:17 CET] <durandal_1707> why is lcov so slow with fate?
[19:54:13 CET] <durandal_1707> anybody against native ilbc decoder?
[19:56:55 CET] <llogan> crazy person in ticket 6133
[19:59:10 CET] <BBB> thats the reporter
[19:59:17 CET] <BBB> this cinepak discussion is also fun
[19:59:25 CET] <BBB> its not ycgco, its something optimized for conversion to rgb"
[19:59:28 CET] <BBB> that is ycgco
[19:59:30 CET] <BBB> ...
[20:00:40 CET] <wm4> is it ycgco, or something very similar?
[20:02:34 CET] <BBB> it looks like ycgco to me, but what do I know
[20:10:40 CET] <nevcairiel> probably not exactly
[20:10:44 CET] <nevcairiel> but very similar in spirit
[20:10:51 CET] <Chloe> JEEB: not sure if you saw my earlier message: <Chloe> JEEB: what a filter to do dvb tt -> dvb subs? With an implementation which handles the special case of multiple pages
[20:12:36 CET] <JEEB> :/
[20:27:06 CET] <kierank> wm4: do you think michaelni will reply
[20:27:37 CET] <wm4> kierank: if we make it embarrassing for him not to reply, maybe
[20:28:49 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.2:1fd78b9b34b8: Changelog: fix typos
[20:28:50 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.2:29ef35abffa0: ffserver_config: Setup codecpar in add_codec()
[20:28:51 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.2:a1a14982ec5b: avcodec/pictordec: Fix logic error
[20:28:52 CET] <cone-277> ffmpeg 03Matt Wolenetz 07release/3.2:cf8e004a51b0: lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
[20:28:53 CET] <cone-277> ffmpeg 03Matt Wolenetz 07release/3.2:ed2572b9c8f8: lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
[20:28:54 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.2:63637e457c4c: avcodec/h264_slice: Clear ref_counts on redundant slices
[20:30:52 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.2:cbe65ccfa02a: Update for 3.2.4
[20:50:30 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:5b8ee8f0134c: avformat/options_table: Set the default maximum number of streams to 1000
[20:50:31 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:3d9c007b6116: avformat/utils: Print verbose error message if stream count exceeds max_streams
[20:50:32 CET] <cone-277> ffmpeg 03Chris Cunningham 07release/3.1:693288c3445a: avformat/mp3dec: fix msan warning when verifying mpa header
[20:50:33 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:f0862b18c5c7: avutil/random_seed: Improve get_generic_seed() with higher precission clock()
[20:50:34 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:8c3e90f5edd1: avutil/random_seed: Reduce the time needed on systems with very low precission clock()
[20:50:35 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:d5948243f51e: avcodec/mjpegdec: Check for rgb before flipping
[20:50:36 CET] <cone-277> ffmpeg 03Tobias Rapp 07release/3.1:c26cbe6c2e00: avformat/avidec: skip odml master index chunks in avi_sync
[20:50:37 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:25778b2692cd: avcodec/omx: Do not pass negative value into av_malloc()
[20:50:38 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:00bbf3063c9e: avcodec/pngdec: Fix off by 1 size in decode_zbuf()
[20:50:39 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:777f8b9fe1a0: avcodec/mjpegdec: Check remaining bitstream in ljpeg_decode_yuv_scan()
[20:50:40 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:c4a0b84b5886: avcodec/vp56: Check for the bitstream end, pass error codes on
[20:50:41 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:e6b3f3ff8103: avcodec/utils: correct align value for interplay
[20:50:42 CET] <cone-277> ffmpeg 03Frank Liberato 07release/3.1:197e4693f634: avformat/flacdec: Check avio_read result when reading flac block header.
[20:50:43 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:e23768b8ffc3: avcodec/mjpegdec: Check for for the bitstream end in mjpeg_decode_scan_progressive_ac()
[20:50:44 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:c26c8bb23a51: avcodec/dca_lbr: Fix off by 1 error in freq check
[20:50:45 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:1f35ea813d6c: avcodec/interplayvideo: Move parameter change check up
[20:50:46 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:9115acb32680: avcodec/pngdec: Check trns more completely
[20:50:47 CET] <cone-277> ffmpeg 03James Almer 07release/3.1:ff7a4df8acc8: configure: bump year
[20:50:48 CET] <cone-277> ffmpeg 03Chris Cunningham 07release/3.1:a4fb905a14c1: lavf/matroskadec: fix is_keyframe for early Blocks
[20:50:49 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:6c1a2e6bc3f0: avcodec/movtextdec: Fix decode_styl() cleanup
[20:50:50 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:e34cbd1d2b1d: ffserver_config: Setup codecpar in add_codec()
[20:50:51 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:68e9caf16f44: avcodec/pictordec: Fix logic error
[20:50:52 CET] <cone-277> ffmpeg 03Matt Wolenetz 07release/3.1:b6efd022b773: lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
[20:50:53 CET] <cone-277> ffmpeg 03Matt Wolenetz 07release/3.1:02a5e88ebc72: lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
[20:50:54 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:d20200d3035e: avcodec/h264_slice: Clear ref_counts on redundant slices
[20:52:39 CET] <durandal_1707> michaelni: is ffmpeg-security reserved only for elite?
[20:54:09 CET] <michaelni> durandal_1707, no, ill reply but id like to finish what i work on atm
[21:01:08 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.1:384d90f26800: Update for 3.1.7
[21:11:25 CET] <cone-277> ffmpeg 03Chris Cunningham 07release/3.0:be0e26d107e4: lavf/matroskadec: fix is_keyframe for early Blocks
[21:11:26 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.0:4730d0d385a1: avcodec/movtextdec: Fix decode_styl() cleanup
[21:11:27 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.0:bb504aa5eb7e: avcodec/pictordec: Fix logic error
[21:11:28 CET] <cone-277> ffmpeg 03Matt Wolenetz 07release/3.0:4f7064c9da35: lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
[21:11:29 CET] <cone-277> ffmpeg 03Matt Wolenetz 07release/3.0:dc1e099bf281: lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
[21:11:30 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.0:3295d22f3ab1: avcodec/h264_slice: Clear ref_counts on redundant slices
[21:17:38 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/3.0:a5dabd4013d1: Update for 3.0.7
[21:25:29 CET] <durandal_1707> i'm looking for candidates to remove gotos from one decompression algorithm
[21:27:47 CET] <atomnuker> durandal_1707: I'd like an atrac9 decoder more
[21:28:29 CET] <durandal_1707> atomnuker: ask j-b to give bounty for it
[21:29:20 CET] <atomnuker> durandal_1707: which compression algorithm?
[21:29:38 CET] <durandal_1707> some guy wrote goto remover for fortran
[21:30:32 CET] <durandal_1707> atomnuker: lz77 like, it looks for previously decoded pixels
[21:31:04 CET] <durandal_1707> see my fmvc branch on github
[21:35:01 CET] <atomnuker> jeez, that code looks obfuscated
[21:35:44 CET] <peloverde> atomnuker: do you remember the crazy rules about latm alignment, what I'm reading in the spec doesn't seem to agree with reality and I'm wondering if I'm looking at the wrong part or missing a footnote
[21:36:57 CET] <atomnuker> peloverde: as in packet size alignment?
[21:37:25 CET] <peloverde> atomnuker: as in when you byte align within a packet and with respect to what
[21:38:11 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:07ca8300a6d7: avcodec/ffv1enc: Fix size of first slice
[21:38:12 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:a127f51140e9: avformat/oggdec: Skip streams in duration correction that did not had their duration set.
[21:38:12 CET] <peloverde> I recall there being a rule that all byte alignments should be treated w/r/t the start of the raw_data_block
[21:38:13 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:94a0a484b703: avcodec/mpeg4videodec: Fix undefined shifts in mpeg4_decode_sprite_trajectory()
[21:38:14 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:774461ea629a: avcodec/ffv1enc: Allocate smaller packet if the worst case size cannot be allocated
[21:38:15 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:c6fbff135880: avformat: Add max_streams option
[21:38:16 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:2e44b1041825: avutil: Add av_image_check_size2()
[21:38:17 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:2647ca45814a: avformat/options_table: Set the default maximum number of streams to 1000
[21:38:18 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:1825f7670a88: avformat/utils: Print verbose error message if stream count exceeds max_streams
[21:38:19 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:02073b5ab1a0: avutil/random_seed: Improve get_generic_seed() with higher precission clock()
[21:38:20 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:1827fe0989fd: avutil/random_seed: Reduce the time needed on systems with very low precission clock()
[21:38:21 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:8be687a81f9b: avcodec/mjpegdec: Check for rgb before flipping
[21:38:22 CET] <cone-277> ffmpeg 03Tobias Rapp 07release/2.8:3f3ee3e62fd6: avformat/avidec: skip odml master index chunks in avi_sync
[21:38:23 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:1febd817b1d8: avcodec/pngdec: Fix off by 1 size in decode_zbuf()
[21:38:24 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:9f2e4c26a0ed: avcodec/mjpegdec: Check remaining bitstream in ljpeg_decode_yuv_scan()
[21:38:25 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:3aca3f1257de: avcodec/vp56: Check for the bitstream end, pass error codes on
[21:38:26 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:17a9e90d1f89: avcodec/utils: correct align value for interplay
[21:38:27 CET] <cone-277> ffmpeg 03Frank Liberato 07release/2.8:d59582a567cf: avformat/flacdec: Check avio_read result when reading flac block header.
[21:38:28 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:87cc0b0474b1: avcodec/mjpegdec: Check for for the bitstream end in mjpeg_decode_scan_progressive_ac()
[21:38:29 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:c9992efd84e1: avcodec/interplayvideo: Move parameter change check up
[21:38:30 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:3aa8440bafe3: avcodec/pngdec: Check trns more completely
[21:38:31 CET] <cone-277> ffmpeg 03James Almer 07release/2.8:d053b25b59cc: configure: bump year
[21:38:32 CET] <cone-277> ffmpeg 03Chris Cunningham 07release/2.8:b3ae6cfe1104: lavf/matroskadec: fix is_keyframe for early Blocks
[21:38:33 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:61b86ae8ce78: avcodec/movtextdec: Fix decode_styl() cleanup
[21:38:34 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:142c1737e325: avcodec/pictordec: Fix logic error
[21:38:35 CET] <cone-277> ffmpeg 03Matt Wolenetz 07release/2.8:8be3724e55b2: lavf/mov.c: Avoid heap allocation wrap in mov_read_hdlr
[21:38:36 CET] <cone-277> ffmpeg 03Matt Wolenetz 07release/2.8:4adc99ecb6e9: lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
[21:38:37 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:912cb27f73d8: avcodec/h264_slice: Clear ref_counts on redundant slices
[21:39:00 CET] <atomnuker> peloverde: no idea, I first heard of ilbc like a month ago, I still know little about voip codecs other than opus
[21:39:47 CET] <peloverde> huh? I'm talking about aac_latm here, not voip
[21:40:07 CET] <atomnuker> oh latm, sorry, I misread that as ilbc
[21:42:47 CET] <llogan> atomnuker: blame ubitux's lexicon missing stuff
[21:51:09 CET] <atomnuker> peloverde: don't know, looked at the specs and I can't find anything special about latm and alignment
[21:53:33 CET] <cone-277> ffmpeg 03Michael Niedermayer 07release/2.8:523da8eac176: Update for 2.8.11
[22:01:18 CET] <cone-277> ffmpeg 03Mark Thompson 07master:b9514756ba2b: vaapi_h265: Add main 10 encode support
[22:01:19 CET] <cone-277> ffmpeg 03Mark Thompson 07master:37de9ce713eb: vaapi_h265: Fix CFR mode with framerate set in AVCodecContext
[22:01:20 CET] <cone-277> ffmpeg 03Mark Thompson 07master:760f1a772758: vaapi_encode: Fix GOP sizing
[22:01:21 CET] <cone-277> ffmpeg 03Mark Thompson 07master:c667c0979cbc: vaapi_encode: Support forcing IDR frames via AVFrame.pict_type
[22:01:22 CET] <cone-277> ffmpeg 03Mark Thompson 07master:eefa4b76ee5a: vaapi_h264: Scale log2_max_pic_order_cnt_lsb with max_b_frames
[22:01:23 CET] <cone-277> ffmpeg 03Mark Thompson 07master:3b95c7c17de0: vaapi_encode: Add MPEG-2 support
[22:01:24 CET] <cone-277> ffmpeg 03Mark Thompson 07master:ceb28c3cc4c7: vaapi_encode: Support VBR mode
[22:01:25 CET] <cone-277> ffmpeg 03Mark Thompson 07master:2201c02e6dc9: vaapi_h264: Enable VBR mode
[22:01:26 CET] <cone-277> ffmpeg 03Mark Thompson 07master:be6546a4ff59: vaapi_encode: Pass framerate parameters to driver
[22:01:27 CET] <cone-277> ffmpeg 03Mark Thompson 07master:d1acab829305: vaapi_encode: Add VP8 support
[22:05:45 CET] <peloverde> It would be nice if there were some latm conformance files that weren't celp
[22:16:43 CET] <Chloe> found this in a dvb*.c file... /* Not touching AVSubtitles again*/
[22:16:47 CET] <Chloe> and damn, I can see why
[22:52:02 CET] <cone-277> ffmpeg 03Marton Balint 07master:3aae1eff1263: ffplay: change keyboard volume control to logarithmic
[22:54:17 CET] <durandal_170> michaelni: 3.3 when?
[23:22:02 CET] <Chloe> kierank: do you have anything to inspect DVB teletext with?
[23:44:30 CET] <jkqxz> wm4:  There is a missing rescale in the flush sequence, which messes up timestamps at the end of the stream.  Fix: <http://sprunge.us/KcDR>, or at least the same line somewhere nearby.
[23:45:10 CET] <BtbN> I still haven't figured out why nvenc reports oom with that patches. Probably some value that's uninitialized now and some huge random thing
[23:45:23 CET] <BtbN> But I'm too tired to debug it properly, so I'll get to it tomorrow.
[00:00:00 CET] --- Thu Feb  9 2017