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

burek burek021 at gmail.com
Thu Oct 6 03:05:02 EEST 2016


[00:10:12 CEST] <Chloe> michaelni: fix sent
[00:35:22 CEST] <Chloe> michaelni: Thanks. Someone else may push my patch, or I'll do it tomorrow. I'm not having a good day in terms of not fucking stuff up.
[00:46:45 CEST] <cone-960> ffmpeg 03James Almer 07master:3cc9d6d3824f: avformat/matroska: write FlagInterlaced element in WebM
[02:23:22 CEST] <cone-960> ffmpeg 03James Almer 07master:b33369b6128a: avformat/matroskaenc: don't reserve space for stream duration tags if the output is not seekable
[03:29:27 CEST] <cone-960> ffmpeg 03Michael Niedermayer 07release/2.8:69b00a7fb6fa: avcodec/cavsdsp: use av_clip_uint8() for idct
[03:29:28 CEST] <cone-960> ffmpeg 03Michael Niedermayer 07release/2.8:ab737ab31d4f: avcodec/ansi: Check dimensions
[03:29:29 CEST] <cone-960> ffmpeg 03Sasi Inguva 07release/2.8:ca216c71c77d: lavc/movtextdec.c: Avoid infinite loop on invalid data.
[03:29:30 CEST] <cone-960> ffmpeg 03Michael Niedermayer 07release/2.8:a77261310051: avformat/avidec: Remove ancient assert
[03:29:31 CEST] <cone-960> ffmpeg 03Michael Niedermayer 07release/2.8:239f75d6c3df: avformat/avidec: Check nb_streams in read_gab2_sub()
[03:29:32 CEST] <cone-960> ffmpeg 03Ronald S. Bultje 07release/2.8:62b2b2195b7e: videodsp: fix 1-byte overread in top/bottom READ_NUM_BYTES iterations.
[03:57:27 CEST] <cone-960> ffmpeg 03Josh de Kock 07master:5173ffb27f6e: doc/developer: remove duplicate policies and fix error
[04:17:48 CEST] <rcombs> michaelni: thanks for the sample; confirmed and fixed issue (it was because I wrote the patch before the codecpar changes and didn't correctly update it to reflect them)
[05:53:06 CEST] <philipl> BtbN: officially abandoning my crazy project. The complexity in no way justifies the tiny performance gain.
[05:53:13 CEST] <philipl> I'll look at dynlink for nvcuvid next.
[06:55:24 CEST] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/25bafc69e9bb13047cc0f30e31e5044420b7d78e
[07:24:50 CEST] <rcombs> >double-checking that an invalid free() reported on an old version of one of my patches no longer happens
[07:24:58 CEST] <rcombs> >enable malloc debugging and heap checking
[07:25:05 CEST] <rcombs> >get crashes in szone_check_all()
[07:25:20 CEST] <rcombs> >try setting it to sanity-check the heap on _every_ malloc/free
[07:25:23 CEST] <rcombs> >still crashes there
[07:25:28 CEST] <rcombs> >try building with asan
[07:25:33 CEST] <rcombs> >still happens; no warnings from asan
[07:30:04 CEST] <rcombs> tl;dr why me
[10:09:13 CEST] <BtbN> philipl, which C++ leak?
[11:36:27 CEST] <cone-901> ffmpeg 03wm4 07master:40fbf3204208: lavc: set best effort timestamp if unset when using new decode API
[13:50:07 CEST] <cone-901> ffmpeg 03Carl Eugen Hoyos 07master:beb877bae026: lavc/tiff: Print compression debug information.
[15:28:16 CEST] <BtbN> philipl, https://github.com/BtbN/FFmpeg/commits/master was more thinking about something like this.
[15:38:54 CEST] <hawken> oh hey, that's what I'm talking about.. maybe you guys could make sure I don't make mistakes again
[15:39:30 CEST] <hawken> I'll tell you what I'm about to change and you can just stop me if it's not going to be enough
[15:40:02 CEST] <Chloe> hawken; what do you want to change?
[15:40:37 CEST] <hawken> Well https://trac.ffmpeg.org/ticket/5472#comment:9 is the place. I'm about to do what he asks. Run the command, replace the file and this time make a post with everything that ffmpeg said
[15:40:45 CEST] <hawken> that should be enough, right?
[15:41:14 CEST] <hawken> But I feel that this is kind of stupid, because it's been half a year and it would still reproduce on any of your machines if you were to actually try to reproduce it
[15:41:50 CEST] <Chloe> it's probably just because no one has
[15:44:35 CEST] <hawken> There we go.. It should pop up here any second
[15:49:38 CEST] <hawken> Well this must be enough. I guess I'm also spamming here because I'm trying to draw attention to it.. As of now you can't really mux pgs subtitles with ffmpeg..
[15:50:06 CEST] <hawken> And that's a big letdown if you are working with bluray etc.
[15:56:34 CEST] <wm4> can't we make fflogger log to a different channel
[15:56:38 CEST] <wm4> it's distracting
[16:01:32 CEST] <iive> indeed, it might be good idea to log into #ffmpeg, it is the bugreport channel.
[16:05:33 CEST] <hawken> O_o then I'm in the wrong channel.. sorry
[16:08:31 CEST] <wm4> no, I mean fflogger and its issue tracker updates
[16:22:26 CEST] <Chloe> gh
[16:22:38 CEST] <Chloe> ugh* I cant upload samples because they're 500kb too big
[16:30:47 CEST] <philipl> BtbN: yes, that was the other approach. 
[16:31:40 CEST] <philipl> i don't know if you noticed but there is c++ code in their cuviddec.h that isn't ifdef guarded properly. that was the 'leak'
[17:07:09 CEST] <BtbN> philipl, ah. I think I just removed that.
[17:07:18 CEST] <BtbN> all the C++ stuff
[17:07:29 CEST] <BtbN> and some other invalid stuff, like cuvidInit
[17:07:51 CEST] <philipl> Heh.
[17:08:21 CEST] <philipl> Anyway, yours looks fine - although I'd personally do the headers as a single rename change to preserve a bit more history
[17:10:25 CEST] <BtbN> I wanted to make sure every single commit compiles and works.
[17:10:36 CEST] <BtbN> that's why it ended up in this order
[17:10:47 CEST] <philipl> fair enough
[17:11:09 CEST] <BtbN> you can get the history faily easy by calling log on the compat/cuda dir.
[17:15:00 CEST] <philipl> true, true.
[17:28:46 CEST] <cone-901> ffmpeg 03Philip Langdale 07master:e5bbedff826d: ChangeLog: Add latest CUVID changes
[19:57:54 CEST] <cone-901> ffmpeg 03Burt P 07master:de9b23ac1f9d: af_hdcd: add mono as a supported channel layout
[19:57:55 CEST] <cone-901> ffmpeg 03Burt P 07master:7e46bb80efa4: af_hdcd: allow all HDCD sample rates
[19:57:56 CEST] <cone-901> ffmpeg 03Burt P 07master:80d89c19601f: af_hdcd: support s16p (WavPack) directly
[19:57:57 CEST] <cone-901> ffmpeg 03Burt P 07master:4f94f0141468: af_hdcd: hdcd_scan() and hdcd_integrate() handle stereo and single channel
[19:57:58 CEST] <cone-901> ffmpeg 03Burt P 07master:f51ddbf83cb7: af_hdcd: add experimental 20 and 24-bit decoding support
[19:57:59 CEST] <cone-901> ffmpeg 03Burt P 07master:2c3d93648768: af_hdcd: disable auto-convert by default
[21:46:01 CEST] <stephenwithav> how do I build graph2dot from the source code?  (I'm using https://hub.docker.com/r/nachochip/ffmpeg-build/~/dockerfile/ as the base for my build.)
[22:44:46 CEST] <philipl> BtbN: I got my crazy thing working. Also, I don't need to introduce a new hwcontext - just a new pix_fmt
[22:45:04 CEST] <BtbN> just
[22:45:13 CEST] <philipl> heh
[22:45:18 CEST] <philipl> It doesn't look terrible.
[22:45:32 CEST] <philipl> mostly because I'm not bothering to provide a frame pool implementation
[22:45:36 CEST] <philipl> caller must provide it.
[22:46:31 CEST] <philipl> One annoyance is I need an extra hwaccel declaration as those only support one pix_fmt
[23:01:44 CEST] <nevcairiel> didnt you quit working on that hours ago =p
[23:04:12 CEST] <philipl> I did, but then I got inspired again.
[23:04:15 CEST] <philipl> And it works now.
[23:13:45 CEST] <JEEB>  34
[23:23:57 CEST] <philipl> BtbN: https://github.com/philipl/FFmpeg/commits/cuvid
[23:24:00 CEST] <philipl> hopefully acceptable.
[23:24:24 CEST] <nevcairiel> adding yet another pixfmt for something you called 2% performance seems still rather pointless
[23:24:53 CEST] <philipl> If we had the luxury of breaking compatibility, I'd say we should use just arrays all the time, but we don't have that luxury.
[23:25:22 CEST] <philipl> You can argue that without my save-a-copy motivations.
[23:25:29 CEST] <BtbN> I'm not a fan of another pix_fmt at all. Did you actually measure if it's faster at all?
[23:25:50 CEST] <BtbN> Specially for presentation, where you are not memory bandwidth bound, it seems quite pointless
[23:26:17 CEST] <nevcairiel> if its a on-gpu copy its not even bandwidth
[23:26:25 CEST] <BtbN> It is, VRAM bandwidth
[23:26:32 CEST] <BtbN> Not PCIe though
[23:26:46 CEST] <nevcairiel> you have plenty of those when doing video processing
[23:27:02 CEST] <BtbN> I'd guess you can copy frames around in-VRAM at several thousand frames per second, even for 4K stuff
[23:27:32 CEST] <BtbN> So avoiding a copy there should not bring any noticable performance gains
[23:30:02 CEST] <philipl> There's a CPU utilization improvement in my eyeballing-top testing.
[23:30:36 CEST] <philipl> 20%->17% in one example.
[23:32:35 CEST] <philipl> If you guys think it can't justify a new pixfmt, that's fine. I largely did it to prove it could be done.
[23:33:48 CEST] <nevcairiel> doesnt seem worth it to me for the all the noise it causes, and near-duplicates in the API
[23:37:49 CEST] <BtbN> reduced _cpu_ usage?
[23:38:02 CEST] <philipl> yes.
[23:44:55 CEST] <cone-136> ffmpeg 03Florian Diemer 07master:db4c1bee9620: avformat/riffenc: added possibility to set first to ninth audio language for RIFF taged files (e.g. avi files)
[23:44:55 CEST] <cone-136> ffmpeg 03Shivraj Patil 07master:c1cc13cd2a9b: avutil/mips/generic_macros_msa: rename macro variable which causes segfault for mips r6
[00:00:00 CEST] --- Thu Oct  6 2016


More information about the Ffmpeg-devel-irc mailing list