[00:00] <BBB> ubitux: no, I meant the caller (in vp9.c) can be changed to mask out non-zero coefficients in a nxn grid [00:00] <BBB> ubitux: instead of just noting the eob position [00:00] <BBB> ubitux: then, if only the topleft 2x2 is nonzero (regardless of which coeffs specifically), we can call your topleft 2x2 specialization [00:01] <BBB> ubitux: will you also write a topleft 4x4 (eob <= 9, I think)? [00:01] <ubitux> dunno, maybe [00:01] <ubitux> but i want to have iadst first :) [00:02] <BBB> hm, 12? [00:02] <BBB> oh, iadst has absolutely no influence on peformance [00:02] <BBB> it's intra-only [00:02] <BBB> so it's like intra prediction assembly [00:02] <BBB> should only be done at the very end :) [00:03] <BBB> idct-idct is much, much, much more important [00:03] <ubitux> ah really? [00:03] <BBB> I'll also have some comments on the assembly, but that will be later tonight [00:03] <BBB> kids are still wake [00:03] <BBB> e.g. line 360 movu -> mova [00:05] <BBB> also idctfull all mova, mot movu [00:05] <ubitux> i can assume block is aligned? [00:05] <BBB> 381-382 also [00:05] <BBB> es [00:05] <BBB> yes* [00:05] <ubitux> ok [00:05] <BBB> actually 360 can be movd [00:05] <BBB> and 381-382 can also be movd [00:05] <ubitux> yep indeed [00:06] <BBB> will look at the rest tonight [00:06] <BBB> kids-time now [00:06] <BBB> but nice work! [00:06] <BBB> can you add some performance measures [00:06] <BBB> in total decoding time, as well as START/STOP_TIMER cycle counts? [00:06] <BBB> (c code versus total assembly) [00:07] <BBB> oh that's in the email, nice [00:08] <BBB> the biggest gain will come from mt, loopfilter and idcts, I think [00:08] <BBB> the rest will be somewhat more minor, but still measurable [00:08] <ubitux> BBB: you'll do the 16x16 and 32x32 anyway [00:08] <ubitux> no? ;) [00:21] <BBB> sure [00:21] <BBB> and t [00:21] <BBB> mt [00:21] <BBB> so you do loopfilter and intrapred and iadst then? [00:24] <ubitux> ok for loopfilter [00:24] <ubitux> i'll ask you again about it next week [00:24] <ubitux> ah mmh actually i might not be available next w-e, 'got another ffmpeg mission :( [00:25] <ubitux> anyway, i'll ask you for lf [00:28] <juanmabc> mmm, no kidding, i get the same issue as in https://github.com/chelyaev/ffmpeg-tutorial [00:28] <juanmabc> advertised in http://www.ffmpeg.org/documentation.html [00:32] <BBB> ubitux: there is no deadline for any of this, it can be done whenever [01:08] <juanmabc> did get_bytes_per_sample change to include channels count or something ? [01:18] <Compn> so we need vc1 mt ? [01:22] <wm4> juanmabc: this tutorial is extremely bad, just look at: https://github.com/chelyaev/ffmpeg-tutorial/commit/916d1a5b7bd65ea6a3dcf9faf... [01:22] <wm4> though I'm not sure if a good tutorial could exist xD [01:27] <juanmabc> mmm, so my issue is the sample_rate, seems to work if i / 2 [02:03] <cone-408> ffmpeg.git 03Diego Biurrun 07master:8b63ebcb0386: build: Remove redundant OBJS declaration intended for programs [02:03] <cone-408> ffmpeg.git 03Michael Niedermayer 07master:1a4ffa5b136a: Merge remote-tracking branch 'qatar/master' [02:30] <cone-408> ffmpeg.git 03Lukasz Marek 07master:398844f09323: lavd/pulse_audio_enc: fix flush return code [02:30] <cone-408> ffmpeg.git 03Lukasz Marek 07master:babf20a215ff: lavd/pulse: add ff_ prefix and fix param type [02:30] <cone-408> ffmpeg.git 03Michael Niedermayer 07master:e1351662063d: Merge remote-tracking branch 'lukaszmluki/master' [02:42] <cone-408> ffmpeg.git 03Ronald S. Bultje 07master:6cf0c4107fbe: Put vp9_scans and vp9_scans_nb in ro_data. [09:55] <cone-910> ffmpeg.git 03Mikulas Patocka 07master:694d997afe07: x86: hpeldsp: Use PAVGB instruction macro where necessary [09:55] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:f3758e8b8040: Merge commit '694d997afe07ec619e61e1c614733796dd01a52b' [10:02] <cone-910> ffmpeg.git 03Anton Khirnov 07master:5cd6513f5be1: pthread: drop avcodec_ prefixes from static functions [10:02] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:3d4dc43259e2: Merge commit '5cd6513f5be14b9744783d3d9e853d3f11065e93' [11:05] <cone-910> ffmpeg.git 03Anton Khirnov 07master:cc14ee03a7b9: lavc: split slice and frame threading functions into separate files [11:05] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:4eea41cba1e1: Merge commit 'cc14ee03a7b91c69343f8d60c9e089a1950eeadb' [11:11] <cone-910> ffmpeg.git 03Anton Khirnov 07master:daa7a1d4431b: pthread_slice: rename ThreadContext -> SliceThreadContext [11:11] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:2a7cbc29a8aa: Merge commit 'daa7a1d4431b6acf1f93c4a98b3de123abf4ca18' [11:29] <cone-910> ffmpeg.git 03Anton Khirnov 07master:38ecc3702dab: pthread: store thread contexts in AVCodecInternal instead of AVCodecContext [11:29] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:3fc26d8073a4: Merge commit '38ecc3702dabbea09230f6d6333f59e74f5d1c12' [11:50] <cone-910> ffmpeg.git 03Anton Khirnov 07master:da6506c607ed: lavc: move AVCodecContext.pkt to AVCodecInternal [11:50] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:ab71be091206: Merge commit 'da6506c607eda585ba4b15430cf3c9a2ce09c3a9' [11:57] <cone-910> ffmpeg.git 03Gian-Carlo Pascutto 07master:454959a5aa73: aacdec: Set the profile during decoding [11:57] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:405ceb181236: Merge remote-tracking branch 'qatar/master' [12:26] <BBB> Compn: no, vc1 can just die [12:27] <j-b> we wish [12:30] <JEEB> iä iä vc-1 f'thagn [12:54] <cone-910> ffmpeg.git 03Clément BSsch 07master:d10b1a200dc3: doc/examples/demuxing: show how to use the reference counting system. [12:54] <cone-910> ffmpeg.git 03Clément BSsch 07master:fb10b43fc42b: doc/examples: rename demuxing to demuxing_decoding. [13:09] <ubitux> hey saste [13:09] <ubitux> [~/src/ffmpeg/doc/examples]- PKG_CONFIG_PATH=pc-uninstalled make filtering_video && valgrind ./filtering_video ~/samples/small.mpg > /dev/null [13:09] <ubitux> can you fix that? :D [13:09] <ubitux> plz :3 [13:10] <ubitux> (i don't understand how the frame reference counting works with lavfi) [13:21] <kierank> for me s/how the frame reference counting works with/ [13:21] Action: kierank stops trolling [13:23] <ubitux> :( [13:24] <ubitux> i guess i'll email nicolas [14:11] <saste> again reindl and his weird mail setup [14:12] <juanmabc> -> anti weirds filter [14:13] <juanmabc> with a polite 'you have been filtered' comeback :D [15:04] <ubitux> wbs: does it work with anonymous struct? [15:04] <ubitux> "struct s { int a, b; } a = { .b = 42 };", aka if you remove the 's' [15:04] <wbs> ubitux: yes, it seems so [15:05] <ubitux> cool ok [15:05] <sspiff> can someone explain me why there is compute_pkt_fields2 and compute_pkt_fields, and what the difference between the two is? [15:06] <JEEB> if something has a number suffix it generally means it's a newer API [15:06] <Daemon404> i find it hard to think where an anonymou struct would be useful... [15:06] <JEEB> and the one with either no number, or a smaller number is either already or will be deprecated [15:06] <Daemon404> but thats just nothing new, re: me ;) [15:07] <ubitux> JEEB: not the case here, it's not public [15:07] <ubitux> JEEB: both are static void, declared in 2 different files [15:07] <JEEB> k [15:07] <JEEB> just did the usual answer because it looked like a public API question >_> [15:08] <ubitux> sspiff: [15:08] <ubitux> static int compute_pkt_fields2(AVFormatContext *s, AVStream *st, AVPacket *pkt) [15:08] <ubitux> oups [15:08] <ubitux> //FIXME merge with compute_pkt_fields [15:08] <ubitux> just above :p [15:09] <ubitux> those functions are full of FIXME and XXX [15:09] <ubitux> hehe [15:09] <ubitux> and HACK [15:10] <ubitux> but well, it's all bout pts/dts magic so& [15:10] <sspiff> ubitux: yeah, but the code is not that similar [15:10] <sspiff> at least at first sight [15:11] <sspiff> ubitux: I'm looking at this for the dvb subtitle decoding, this is the area where it fails [15:11] <ubitux> oh cool :) [15:11] <sspiff> I tried just hooking it to the (seemingly less hacky) compute_pkt_fields, which doesn't return error codes and thus doesn't stop the conversion in its tracks, but still produces an empty output file [15:12] <ubitux> sspiff: ah and btw, since you're working on dvb sub, the only working way of getting dvb subtitles in output is to use dvd subtitles as input [15:12] <ubitux> remux and re-encode of dvb sub won't work, only dvd sub transcode [15:13] <sspiff> my problem is dvb subs as input [15:13] <ubitux> yup [15:13] <sspiff> but outputting as dvd subtitles would be acceptable [15:13] <ubitux> if you're fixing this, you'll have all my benediction [15:13] <sspiff> is this problem related to the decoding or the encoding of dvb sub? [15:13] <sspiff> or both :) [15:14] <sspiff> seems to me decoding is broken (based on the fact that it fails in compute_pkt_fields2 [15:15] <ubitux> assuming transcode from dvd sub works, i'm guessing that's indeed the decode or the demux [15:16] <ubitux> and since remux doesn't work, probably demuxing indeed [15:19] <sspiff> I've convinced my employer to give me some time to work on this, I'm hoping it's enough to learn the code base and figure out the problem :) [15:19] <ubitux> BBB: oh oups i didn't realized i wasn't replying on ffmpeg-devel; most likely because of your initial cc (and my bad habit of using a standard reply) [15:19] <ubitux> sspiff: awesome :) [15:20] <ubitux> sspiff: about compute_pkt_fields magic, you should probably nag michaelni about it [15:20] <ubitux> he's generally familiar with those obscure areas [15:20] <ubitux> otherwise, ask ffmpeg-devel mailing list [15:21] <sspiff> ubitux: I'll do that first then :) [15:21] <sspiff> michaelni: let me know when you're here! [15:26] <michaelni> sspiff, diference between 1 and 2 is that one is for demuxer and 2 muxer side [15:27] <j-b> is libxvid really better than ffmpeg for mp4v encoding? [15:27] <JEEB> it shouldn't [15:28] <j-b> then why do people use ffmpeg with it? [15:29] <JEEB> for encoding? [15:29] <JEEB> oh wait [15:29] <JEEB> you were talking about encoding [15:29] <JEEB> d'oh [15:29] <JEEB> anyways, for encoding libxvid is simpler to use [15:30] <j-b> of course, for encoding [15:30] <JEEB> in theory the mpeg4 encoder could be as good if not better, but good luck and have fun setting the parameters [15:31] <sspiff> michaelni: then are they similar enough to merge? [15:31] <sspiff> by the way, should it be possible to mux a TS with only subtitles with ffmped? [15:35] <michaelni> anything could be merged but i suspect it would turn hard to understand code into harder to understand code in this case [15:35] <ubitux> ow only 8 xmm reg in 32-bit :(( [15:35] <michaelni> i dont think ive tested subs in ts so i dont know [15:43] <sspiff> how do I enable DEBUG in a local build? ./configure --enable-debug doesn't seem to do it [15:45] <Daemon404> michaelni, fate is back [15:45] <ubitux> sspiff: #define DEBUG in the file, otherwise it will enable debug everywhere [15:45] <michaelni> Daemon404, \o/ [15:45] <ubitux> sspiff: but if you really want to do this, --extra-cflags='-DDEBUG' [15:45] <Daemon404> also if anyone wants to help me fix this unchecked alloc in h264.c [15:45] <Daemon404> be my guest [15:45] <Daemon404> i cannot figure it out [15:45] <Daemon404> (repro line is on the ML) [15:45] <ubitux> sspiff: i personally switch the av_dlog to av_log, less pain :p [15:46] <Daemon404> why does av_dlog exist again? [15:47] <ubitux> debug log not being compiled for performance reasons [15:47] <ubitux> i guess [15:47] <Daemon404> 'performance reasons' [15:47] <Daemon404> yeah. [15:47] <ubitux> well that's important in some cases [15:47] <ubitux> calling av_log in a critical loop can be problematic [15:47] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:d0ac60730d26: avfilter/vf_scale: add ov/hsub [15:47] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:85cabf1ca98f: avutil: add av_fopen_utf8() [15:48] <Daemon404> ubitux, its merely annoying [15:48] <nevcairiel> dlog has truely spammy logs in crucial parts of the code, its good that it doesnt always run [15:48] <Daemon404> since it breaks cnsstency [15:48] <Daemon404> with the av_log / AV_LOG_* methods [15:48] <ubitux> i'm fine with //av_log() [15:48] <ubitux> but there are two problems with that [15:48] <ubitux> a certain Diego or similar might drop them randomly [15:48] <ubitux> and you can't test if it compiles [15:49] <ubitux> (fate tests -DDEBUG) [15:49] <Daemon404> didnt reimar have a patch to make only certan av_log levels compiled [15:49] <ubitux> probably yes [15:49] <Daemon404> that seems saner than a separate func [15:49] <nevcairiel> i saw something like that, but it seemed rather hacky [15:49] <Daemon404> probably. [15:49] <ubitux> adding #define DEBUG on top of the file isn't that much trouble while developping [15:50] <ubitux> especially if it's already present and you just need to uncomment [15:50] <ubitux> but... i think they got recently dropped in a random cleanup hystery [15:52] <ubitux> Daemon404: av_dlog has the advantage of being file specific [15:52] <Daemon404> heh [15:52] <ubitux> which is very appropriate which debugging [15:52] <Daemon404> ive never found much usefl in av_dlog myself, though YMMV [15:52] <ubitux> i hate when i'm using -v debug for debugging and it suddenly floods my output with unrelated output [15:52] <Daemon404> exisiting av_dlog calls* [15:53] <nevcairiel> yeah i usually add normal av_log calls to places and remove them when i'm done [15:53] <ubitux> av_dlog are just a way to ease future debug [15:54] <sspiff> ubitux: thanks :) [15:54] <saste> per-component logging level may be useful though [15:54] <ubitux> yes [15:55] <funman> michaelni: http://source.ffmpeg.org/ gives git://git.videolan.org/ffmpeg.git as url [15:55] <funman> and configure complains about git.v.o url [15:55] <ubitux> that's because http://git.videolan.org/?p=ffmpeg.git does [15:56] <ubitux> and that's where you're redirected from that http [15:56] <ubitux> funman: download page points on source.ffmpeg.org git url [15:56] <saste> wm4, what's wrong with setting filters in the getCachedContext? [15:56] <Daemon404> isnt source.ffmpeg.org just a dns redirect [15:57] <funman> ubitux: yes I noticed the redirect [15:57] <funman> http://git.videolan.org/?p=ffmpeg.git gives wrong URL [15:57] <ubitux> not sure it can be changed [15:57] <ubitux> since it's likely auto generated on videolan side [15:59] <nevcairiel> i should've figured out earlier how this ffbisect script works, its really quite useful [16:07] <ubitux> i might try to write some arm simd after i'm done with vp9 x86 [16:07] <ubitux> any board recommendation? [16:07] <JEEB> :o [16:07] <ubitux> or should i just do something with a random phone instead? [16:07] <ubitux> (i'm afraid of android and ios shit) [16:07] <JEEB> you probably will want something NEON-capable ARMv7 [16:08] <JEEB> also funny enough iPhone somethingoranother had a custom implementation of some NEON instruction [16:08] <JEEB> so it crashed x264 :D [16:08] <ubitux> nice [16:10] <Daemon404> ubitux, any number of people could give you access to an arm box [16:10] <Daemon404> myself included [16:10] <nevcairiel> anyone thats knows mp4/mov a bit? does stss also occur for audio? [16:10] <ubitux> i don't want to depend on someone or a remote box [16:11] <funman> qemu-system-arm ;) [16:11] <ubitux> Daemon404: i'll probably buy one, unless you want to offer me one for free [16:11] <ubitux> funman: not really relevant for simd benching [16:11] <Daemon404> funnily enough, i do have extra arm boxes [16:11] <Daemon404> but they arent suitable for dev work [16:11] <JEEB> nevcairiel, I recommend consulting Paranoialmaniac whenever he wakes up again [16:11] <Daemon404> since they have special snowflak kernels [16:12] <nevcairiel> my bisect returned a result \o/ [16:12] <nevcairiel> love when it actually does work :p [16:12] <JEEB> :) [16:12] <JEEB> yeah [16:12] <Daemon404> unless it was fixed [16:12] <Daemon404> and reintroduced later [16:12] <nevcairiel> need to find the proper starting point [16:13] <JEEB> oh, that guy gave you a sample [16:13] <JEEB> nice [16:13] <nevcairiel> anyway i'm so buying a 8 core cpu next year, compiling a bazillion times takes ages [16:13] <Daemon404> i just start at HEAD~1000 [16:13] <Daemon404> er [16:13] <Daemon404> 10000 [16:13] <Daemon404> :D [16:13] <nevcairiel> i knew which version was good [16:13] <Daemon404> i do bisect on a 24 core xeon [16:13] <Daemon404> fro work [16:13] <Daemon404> :P [16:13] <durandal_1707> nevcairiel: which? [16:13] <nevcairiel> which what [16:13] <durandal_1707> version [16:14] <nevcairiel> some random hash :P [16:14] <nevcairiel> from july [16:14] <Daemon404> probably one he used for a release [16:14] <Daemon404> i bet [16:14] <nevcairiel> yea [16:15] <Daemon404> i was finally reading the lav code the other day [16:15] <Daemon404> i am impressed with the massive amount of special cased boilerplate code [16:15] <Daemon404> for stff like h264 [16:15] <Daemon404> :D [16:15] <Daemon404> dat api [16:16] <JEEB> reminds me I should poke the AVCc parser for H.264 in there [16:16] <JEEB> so that it won't try to push stuff forwards as AVCc if it's Annex B [16:16] <JEEB> (yo dawg annex b in mp4) [16:16] <Daemon404> it exists [16:16] <JEEB> or well, the parsing either fails or something [16:16] <JEEB> Daemon404, yes -- I have a sample [16:16] <Daemon404> i see a lot of annexb in mov [16:16] <Daemon404> at work [16:31] <nevcairiel> Daemon404: well, thats mostly because people produce so much crap [16:31] <Daemon404> my job is to consume crap [16:31] <nevcairiel> i wonder if i can get rid of my own "dont show broken frames" code for h264 these days [16:31] <nevcairiel> avcodec got support for that including intra-refresh now [16:35] <nevcairiel> maybe i'll just do that for my next release and try to fix fallout afterwards :p [16:40] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:f21dce60442b: indeo: Refactor ff_ivi_dec_huff_desc [16:40] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:c5da487a38f9: indeo: Refactor ff_ivi_init_tiles and ivi_decode_blocks [16:40] <cone-910> ffmpeg.git 03Michael Niedermayer 07release/0.10:36678748333d: Merge commit 'c5da487a38f93b981c4933d4e0b09c49c319fbb7' into release/0.10 [16:56] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:aedde1a48de4: indeo: Cosmetic formatting [16:56] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:efe710f8a009: indeo: reject negative array indexes [16:56] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:c02b9e6e6338: indeo: Bound-check before applying transform [16:56] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:a0b8f85f2988: indeo: Bound-check before applying motion compensation [16:56] <cone-910> ffmpeg.git 03Michael Niedermayer 07release/0.10:cb297f6ae79b: Merge commit 'a0b8f85f29883f538a32593bc3c6f712c972ff70' into release/0.10 [17:01] <ubitux> why cosmetics on stable branches? [17:01] <ubitux> wtf? [17:29] <nevcairiel> if you happen to have reformated the file you are now fixing a bug in, sometimes its just easier to also merge the cosmetics instead of sorting out the conflict manually :d [17:30] <nevcairiel> of course the lesson is that you should not do the reformat in between actual fixes [17:37] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:7999ff8966e0: indeo: Sanitize ff_ivi_init_planes fail paths [17:37] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:53c76b68036b: indeo: Do not reference mismatched tiles [17:37] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:cd9b0bb07a66: 4xm: validate the buffer size before parsing it [17:37] <cone-910> ffmpeg.git 03Michael Niedermayer 07release/0.10:a5115752cad0: Merge commit 'cd9b0bb07a66d3299bd62922e9dfa742219abe79' into release/0.10 [17:52] <saste> ubitux, becase they messed history so functional changes are a mess to apply without the cosmetic histery [17:53] <Daemon404> still better than inside merge commits! [17:54] <wm4> lol at the merge mess [17:54] <wm4> I wonder if just cherry-picking wouldn't be easier? [17:55] <Daemon404> probably not no [17:55] <Daemon404> bisecting would be utter hell [17:58] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:12dc01bb1f07: 4xm: do not overread the prestream buffer [17:58] <cone-910> ffmpeg.git 03Michael Niedermayer 07release/0.10:1825d6d09610: Merge commit '12dc01bb1f07112cd7eb31e183d75cb3c0fb92ca' into release/0.10 [18:04] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:c25bbb6fdbfb: 4xm: Reject not a multiple of 16 dimension [18:04] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:2da49df19e11: lavc: set the default rc_initial_buffer_occupancy [18:04] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:067713f15989: rtmp: rename data_size to size [18:04] <cone-910> ffmpeg.git 03Michael Niedermayer 07release/0.10:39d76907c9fb: Merge commit '067713f15989dd0b8c0888a3b43fd193819a1058' into release/0.10 [18:19] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:a9ebc17b2dd5: rtmp: Do not misuse memcmp [18:19] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:5312fb828751: 8bps: Bound-check the input buffer [18:19] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:e930b112d14d: oma: refactor seek function [18:19] <cone-910> ffmpeg.git 03Michael Niedermayer 07release/0.10:1c896e865cfb: Merge commit 'e930b112d14d7acd050d5087d11b6dd4c56a8e4e' into release/0.10 [18:56] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:b98a824c3e97: oma: check geob tag boundary [18:56] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:3cc05e0d9d24: oma: correctly mark and decrypt partial packets [18:56] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:cda26ab21eb5: nuv: Do not ignore lzo decompression failures [18:56] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:36fc320747a7: nuv: Pad the lzo outbuf [18:57] <cone-910> ffmpeg.git 03Michael Niedermayer 07release/0.10:e31518e86ee5: Merge commit '36fc320747a768335ae4538a24a5739033b7eb74' into release/0.10 [19:07] <cone-910> ffmpeg.git 03Anton Khirnov 07release/0.10:d2eddcfc833f: nuv: return meaningful error codes. [19:07] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:c1ebdef01b01: nuv: Use av_fast_realloc [19:07] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:abb41f19cc10: nuv: Reset the frame on resize [19:07] <cone-910> ffmpeg.git 03Michael Niedermayer 07release/0.10:048e28420172: Merge commit 'abb41f19cc10fea09fb16d9ecc9967b2a78cf7b0' into release/0.10 [19:10] <durandal_1707> http://forum.doom9.org/showthread.php?t=169686 [19:16] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:4a11d773f9f7: nuv: check rtjpeg_decode_frame_yuv420 return value [19:16] <cone-910> ffmpeg.git 03Reimar Döffinger 07release/0.10:5971631d8454: ogg: Fix potential infinite discard loop [19:16] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:1682c9fb595d: alsdec: Clean up error paths [19:16] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:b8ba48c725dc: dsicinav: Clip the source size to the expected maximum [19:17] <cone-910> ffmpeg.git 03Anton Khirnov 07release/0.10:82978539171f: pictordec: pass correct context to avpriv_request_sample [19:17] <cone-910> ffmpeg.git 03Anton Khirnov 07release/0.10:be8b796f559c: vcr1: add sanity checks [19:17] <cone-910> ffmpeg.git 03Martin Storsjö 07release/0.10:86d0bf0e96bf: mov: Seek back if overreading an individual atom [19:17] <cone-910> ffmpeg.git 03Michael Niedermayer 07release/0.10:7c7239878731: Merge commit '86d0bf0e96bf917e283d24239ce0eed08351da86' into release/0.10 [19:24] <michaelni> durandal_1707, which revission broke that ? [19:29] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:8119336df40f: dsicinav: K&R formatting cosmetics [19:29] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:ef67d8107eb3: aac: return meaningful errors [19:29] <cone-910> ffmpeg.git 03Luca Barbato 07release/0.10:2ed8a550da52: aac: Check init_get_bits return value [19:29] <cone-910> ffmpeg.git 03Michael Niedermayer 07release/0.10:2e57d4ba24b1: Merge commit '2ed8a550da524434deb3b89f7ec62ed833bedac5' into release/0.10 [19:36] <durandal_1707> michaelni: how would i know that? [19:40] <cone-910> ffmpeg.git 03Diego Biurrun 07release/0.10:a1b82c6b1c7b: x86: ac3dsp: Drop mmx variant of ac3_max_msb_abs_int16 [19:40] <cone-910> ffmpeg.git 03Diego Biurrun 07release/0.10:62c8bf00bb0b: x86: fft: Remove 3DNow! optimizations, they break FATE [19:40] <cone-910> ffmpeg.git 03Reinhard Tartler 07release/0.10:d2f484659172: Prepare for 0.8.7 Release [19:40] <cone-910> ffmpeg.git 03Michael Niedermayer 07release/0.10:8528feb13cd3: Merge commit 'd2f4846591727fedcc2b452b688da8da09ee8305' into release/0.10 [19:48] <cone-910> ffmpeg.git 03Reinhard Tartler 07release/0.10:ae9652605a9a: Changelog for 0.8.9 [19:48] <cone-910> ffmpeg.git 03Michael Niedermayer 07release/0.10:5e708b4de3aa: Merge remote-tracking branch 'qatar/release/0.8' into release/0.10 [19:51] <iive> michaelni: Did you really merge fft-remove 3dnow? without even trying to find what the problem is and fix it? [19:51] <michaelni> iive: i do not maintain release/0.10 [19:51] <michaelni> i just merge changes that others do [19:52] <iive> sorry, i'm a little confused. [19:52] <iive> you are backporting changes? [19:54] <durandal_1707> yes, it is prime priority to backport K&R fixes [19:54] <michaelni> iam merging what others backported to that old release ffmpeg 0.10 or libav 0.8 (they originate from about the same time) [19:55] <durandal_1707> nothing new [19:56] <michaelni> if someone wants to maintain release/0.10 that is welcome, also if someone just wants to fix the 3dnow stuff properly as well, every welcome [19:56] <michaelni> s/every/very/ [19:58] <iive> well... you know diego's ninja commits... no discussion, no explanation; bam - no need to maintain it anymore. [19:58] <durandal_1707> exactly [20:00] <michaelni> iive, no doubt that the removial is not the correct solution, but as said i dont maintain that ancient branch, and i dont even have a 3dnow box here so i couldnt even if i wanted [20:01] <michaelni> iive, revert it, solve it better, iam happy to apply your patches or merge from your git repo or whichever way of getting the changes in yuo prefer [20:05] <iive> this is the first time I see this change. You don't expect me to send you fix right now, I hope. [20:10] <michaelni> iive, i can wait with the release, theres no real hurry, if you want to look into it ? [20:11] <iive> no, don't wait for me. [20:11] <iive> but is this commit merged in the main repo too? [20:26] <michaelni> iive, i dont think it has been removed from the main repo, just renamed several times and changed to yasm [20:27] <michaelni> bac0729d9e1dcd4efc63637c7832c8bb013d4284, ca844b7be9c69c91113094ef21d720f1ca80db60 [20:50] <cone-910> ffmpeg.git 03Michael Niedermayer 07release/0.10:d83dff2e0951: update for 0.10.10 [20:53] <llogan> lol. reindl and his stupid spam blockers again. [20:57] <cone-910> ffmpeg.git 03Michael Niedermayer 07release/0.10:4ddbe89d40bd: avfilter/ff_insert_pad: fix order of operations [20:57] <cone-910> ffmpeg.git 03Michael Niedermayer 07release/0.10:58e212c1fbad: avcodec/jpeglsdec: check err value for ls_get_code_runterm() [21:20] <cone-910> ffmpeg.git 03Vittorio Giovara 07master:446e37dc97e5: vf_fieldorder: remove superfluous get_video_buffer [21:20] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:b84cd22a6661: Merge commit '446e37dc97e533e37f6aa0a11355124207e3a7f7' [21:37] <cone-910> ffmpeg.git 03Jan Ekström 07master:cd8f772d0678: lavc: Add colorimetry values for BT.2020, other non-included ones [21:37] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:be41f21a3d6d: Merge commit 'cd8f772d0678a90957f4dfd5ce51af9d22e3f212' [21:42] <cone-910> ffmpeg.git 03Jan Ekström 07master:885ec9242554: hevc: Use parsed VUI colorimetry in avcodec [21:42] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:b906d0488119: Merge commit '885ec9242554ad25922258a595ec5e317922a412' [21:48] <michaelni> mraulet, btw, are there any commits i should cherry pick from openhevc_ffmpeg ? [21:48] <mraulet> not yet [21:48] <mraulet> it has been not yet intensively tested [21:48] <cone-910> ffmpeg.git 03Yusuke Nakamura 07master:3ef9b7ab95cc: hevc_ps: Use AV_PIX_FMT_YUVJ420P if YUV 4:2:0 8-bit full scale [21:48] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:2865c1b905f0: Merge commit '3ef9b7ab95cc703b67a8b658dca45c80df0aaa66' [21:50] <michaelni> mraulet, ok [21:50] <nevcairiel> you are working on combining frame threading and wpp now? [21:50] <mraulet> yes [21:50] <mraulet> it works fine [21:50] <mraulet> but it has been recently finished [21:50] <nevcairiel> considering a 4k movie already gives me 90%+ cpu saturation, is that really going to change much? or only on systems with many more cores? [21:51] <mraulet> you can have a lower latency [21:52] <mraulet> when combining wpp with frame based [21:52] <mraulet> in our cases we can still gain a bit when combining both [21:53] <mraulet> 88fps compared to 65fps [21:54] <nevcairiel> I will certainly do some tests once its in master [21:56] <mraulet> ok [21:58] <cone-910> ffmpeg.git 03Diego Biurrun 07master:e73996954d8e: filtfmts-test: Fix use of deprecated API [21:59] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:4b4a7fcb073e: Merge commit 'e73996954d8e00117056dcefb38ef3d4d2f37967' [21:59] <nevcairiel> I dont suppose its smart enough to automatically reduce the number of frame threads and increase slice threads if wpp is present, and not otherwise? :d [22:00] <mraulet> at the moment this is the nicest way we found to do some experiments :-) [22:01] <mraulet> our idea is to reduce latency on some big frames [22:01] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:97f50e92b5cf: omadec: Fix wrong number of array elements [22:01] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:b1f213a83ae8: Merge commit '97f50e92b5cf3b47a76f75d76ed4340e822030db' [22:03] <mraulet> one question I have regarding interlace coding in H264. how does the decoder manage the 2 fields, it seems that it is done inside the h264 decoder? [22:04] <nevcairiel> it always combines both fields into one frame, yes [22:04] <nevcairiel> how that works in the decoder, michaelni can probably tell you [22:05] <kierank> yes it's scary code [22:05] <mraulet> michaelni why not doing that outside the decoder [22:08] <michaelni> mraulet, libavcodec & libavfilter dont support single fields. its all frames. Its also simpler for the user application that it doesnt have to handle anything but frames [22:15] <michaelni> one could probably add some generic code between decoder & user app to turn fields into frames, doing it without memcpy most of the time might be possibly too dunno how easy that would be though [22:17] <mraulet> this is the problem I have... whether I will be able to do it without memcpy seems not so easy [22:17] <mraulet> I can lost one filed in hevc [22:17] <mraulet> *field [22:18] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:1c736bedd989: omadec: check GEOB sizes against buffer size [22:18] <Compn> BBB : tell that to sony bluray [22:18] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:aeaca3816c26: Merge commit '1c736bedd9891501960ebac0f7c05eb60225e947' [22:18] <Compn> of which i assume there are vc1 blurays [22:19] <michaelni> doesnt hevc need the fields stored as frames anyway for motion compensation of subsequent frames (that is with mixed field pairs and frames) ? [22:19] <mraulet> no I don't need to change the structure of the decoder [22:20] <mraulet> filed are seen as frame in the deocder [22:21] <iive> hevc supports interlace too? [22:21] <mraulet> yes :) [22:22] <mraulet> yes with SEI and VUI messages [22:22] <mraulet> the decoder does not have complex tool at the moment [22:23] <mraulet> SEI messages are used to signal any changes between frame and field coding [22:24] <mraulet> and VUI messages are used to re-align chrominances [22:24] <iive> is there field based motion compensation? [22:25] <mraulet> no (for me the fields as seen as frame in the DPB) [22:25] <iive> interlace should have died long ago... with the crt... [22:26] <mraulet> it should but it is still alive... [22:47] <cone-910> ffmpeg.git 03David Goldwich 07master:0a7fef39fc57: omadec: loosen format probing constraints [22:47] <cone-910> ffmpeg.git 03Michael Niedermayer 07master:bd75651378da: Merge remote-tracking branch 'qatar/master' [23:53] <llogan> someone slap avserver [00:00] --- Tue Nov 5 2013