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

[burek]

[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/916d1a5b7bd65ea6a3dcf9faff0b734a8a91aec8
[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