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

[burek]

[00:03] <llogan> "so I see you have no plans to user the users off FFmpeg how said any how i got it fixed with your help".
[00:03] <llogan> ok!!
[00:03] <gnafu> They sure told you!
[00:03] <gnafu> Though what they told you, I'm not sure.
[00:04] <llogan> He is also no sure.
[00:04] <llogan> *not
[00:57] <cone-523> ffmpeg.git 03Pascal Massimino 07master:3c3a8c148979: libvpxenc: add psnr support
[00:57] <cone-523> ffmpeg.git 03Michael Niedermayer 07master:1d178710b429: libvpxenc: dont redundantly zero fields, the whole context is zeroed on init
[00:57] <cone-523> ffmpeg.git 03Michael Niedermayer 07master:e20f2dc048fd: ffmpeg: fix variable name in psnr printing code
[01:59] <Compn> Since September of 2012, Apple Inc.'s stock has plummeted nearly $300 per share. 
[02:06] <Skyler_> Compn: much of the reason IIRC is a lot of hedge funds unloaded billions in apple stock, since it was at a really price and probably doesn't have much potential to go higher
[02:06] <Skyler_> which crashed the price
[02:06] <Skyler_> *really high price
[02:08] <Compn> i thought it was more to do with mr jobs
[02:08] <llogan> it's "only" at $441.40/share now.
[02:10] <Skyler_> There's also the interesting shareholder revolt thing going on now, where a major fund manager is upset that apple is just hording 130 billion dollars in cash
[02:10] <Skyler_> *hoarding
[02:11] <Skyler_> I think the cash is like 140 per share, so the actual company price is about $300/share (i.e. not counting their vast money swimming pool)
[02:11] <llogan> "Next on 'Hoarders: Buried Alive'..."
[02:11] <iive> hoarding cash is the most sane way of hoarding.
[02:12] <Skyler_> it's actually rather amazing, the biggest hedge fund in the world is now apple's cash reserves
[02:12] <Skyler_> ("braeburn capital")
[02:12] Action: J_Darnley groans
[02:13] <Skyler_> that's actually its name XD
[02:13] <llogan> braeburn...apple. consipracy, i tell you.
[02:14] <iive> I don't know about short term, but apple is already showing sings of massive failures. first imaps, now buggy ios update...
[02:15] <Skyler_> I think the ios updates have -always- been buggy
[02:16] <iive> well, i don't have first hand experience. I thought they brick only jail-broken phones. But for the first time I see in the news warnings to avoid specific update.
[02:18] <iive> also... iphone5 was quite an disappointment. I mean, it had nothing really new.
[07:53] <wm4> ubitux: patches welcome :) (as long as they keep the old srt code, and as long as libass is still used natively where it's possible)
[07:53] <wm4> ubitux: I'd like to do it eventually, but now I have other things to worry about, and the subtitle code mostly works
[09:02] <cone-688> ffmpeg.git 03Nicolas George 07release/0.10:eeacc5a7d069: lavf/avio: check for : in filenames for protocols.
[09:02] <cone-688> ffmpeg.git 03Nicolas George 07release/0.11:a8b92c4b3ccb: lavf/avio: check for : in filenames for protocols.
[09:02] <cone-688> ffmpeg.git 03Nicolas George 07release/0.9:cbadebd8ccd0: lavf/avio: check for : in filenames for protocols.
[09:02] <cone-688> ffmpeg.git 03Nicolas George 07release/1.0:8ffe243c85e5: lavf/avio: check for : in filenames for protocols.
[09:02] <cone-688> ffmpeg.git 03Nicolas George 07release/1.1:4f3f2fe14bdf: lavf/avio: check for : in filenames for protocols.
[12:10] <durandal_1707> is there easy and fast way to dump palette?
[12:26] <durandal_1707> what?
[12:26] <durandal_1707> spam bugs!
[12:27] <durandal_1707> no report spam button!
[12:27] <relaxed> durandal_1707: I think you would be a great bookkeeper.
[12:28] <durandal_1707> relaxed: thinking != reality
[12:54] <cone-406> ffmpeg.git 03Martin Storsjö 07master:86611ff123d6: pnm: Use av_pix_fmt_desc_get instead of accessing the array directly
[12:54] <cone-406> ffmpeg.git 03Martin Storsjö 07master:cb6f8245aed2: cmdutils: Allow calling filter_codec_opts without a set encoder
[12:54] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:46f4b468e210: Merge commit 'cb6f8245aed2c26fe95c30cd68c45983277a945a'
[13:03] <cone-406> ffmpeg.git 03Martin Storsjö 07master:df0229a7caa1: avconv: Apply codec options to streams that are copied as well
[13:03] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:41401773d3c2: Merge commit 'df0229a7caa124dcfb84c34b48d316744c467311'
[13:11] <cone-406> ffmpeg.git 03Luca Barbato 07master:7ac6d2423e9b: lls: K&R formatting cosmetics
[13:11] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:fb4b1607561c: Merge commit '7ac6d2423e9bf0f40c67be9a0ca7600b516b0282'
[13:22] <wm4> why is AVSEEK_FLAG_BYTE "not supported by all demuxers"?
[13:23] <wm4> and how do I find out (without actually doing a seek)
[13:25] <cone-406> ffmpeg.git 03Luca Barbato 07master:9d4da474f5f4: lls: move to the private namespace
[13:25] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:76f8d3c8d921: Merge commit '9d4da474f5f40b019cb4cb931c8499deee586174'
[13:27] <michaelni> wm4, AVFMT_NO_BYTE_SEEK 
[13:28] <wm4> michaelni: perfect, thank you
[13:37] <wm4> hm, as far as I can see libavformat's seek API fails completely in the presence of TS resets, unless you use byte seeks
[13:37] <wm4> it could generate linear timestamps or provide a way to do relative seeks to deal with this
[13:37] <wm4> or am I overlooking something?
[13:37] <cone-406> ffmpeg.git 03Luca Barbato 07master:399663be9d4a: lls: mark max_order as unsigned short
[13:37] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:28bb17ca3622: Merge commit '399663be9d4a839b894c48a21b62926eb8497d72'
[13:44] <cone-406> ffmpeg.git 03Diego Biurrun 07master:e8c52271c45e: Revert "Move H264/QPEL specific asm from dsputil.asm to h264_qpel_*.asm."
[13:44] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:1a7166a58d69: Merge commit 'e8c52271c45ec27d783e74238dcfad0c2008731c'
[13:48] <cone-406> ffmpeg.git 03Diego Biurrun 07master:4da950c0ae22: lls: #ifndef --> #if in FF_API_ version guard
[13:49] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:7da1b235e82e: Merge commit '4da950c0ae224b9b8ef952dadf614be2c050023e'
[14:06] <cone-406> ffmpeg.git 03Diego Biurrun 07master:0b311293891e: lls: Do not return from void functions
[14:06] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:4b335e73daca: Merge remote-tracking branch 'qatar/master'
[14:19] <cone-406> ffmpeg.git 03Paul B Mahol 07master:5a232e5078cc: exr: use bytestream functions in pxr24_uncompress()
[14:22] <wm4> oh awesome
[14:22] <wm4> so byte seeking really means byte seeking
[14:22] <wm4> and as consequence, everything shits itself
[14:22] <wm4> so it's not useable for seeking in files with TS resets
[14:22] <durandal_1707> what byte seeking should be instead?
[14:22] <wm4> sane API please?
[14:23] <wm4> durandal_1707: seek a packet by start byte position maybe?
[14:23] <wm4> or, just a sane API for seeking even if there are TS resets
[14:24] <wm4> or, in fact, just a sane seeking API - a single API that works everywhere, and not TWO non-working seek APIs that each work or work not sometimes depending on file format
[14:24] <durandal_1707> patch welcome <---- i could not resist temptation
[14:37] <ubitux> what is the difference between "_deps", "_select" and "_suggest"?
[14:38] <ubitux> i was tempted to add iconv to the avcodec_suggest (because it may help adding the necessary linking option for darwin?)
[14:39] <ubitux> but i have trouble making a distinctions between those 3 kind of lists
[14:41] <michaelni> ubitux, AFAIK/IIRC deps disable "it" when the dependancies arent there, "select" enable the dependancies when "it" is there, suggest enables dependancies when they are not disabled but does not disable "it" when they are disabled
[14:42] <michaelni> again above is from memory so maybe not 100% correct
[14:42] <michaelni> either way its bad design as you have to brute force rename between dep and select when changing defaults
[14:45] <ubitux> ok, thank you
[14:45] <Daemon404> hmm, ffprobe question -- why do i get: Stream #0:0: Video: vp6f, yuv420p, 460x260, 492 kb/s, 25 tbr, 1k tbn, 1k tbc
[14:46] <Daemon404> but
[14:46] <Daemon404> steaminfo has
[14:46] <Daemon404> "width": 464,
[14:46] <wm4> michaelni: in theory, would be be feasible to generate strictly monotonically increasing PTS for formats which can have TS resets?
[14:46] <michaelni> wm4, yes
[14:47] <wm4> michaelni: ok, here you have a feature request
[14:48] <wm4> I suppose it could create byte ranges, and assign pts start/stop/offset based on the file position?
[14:49] <wm4> it would be nice if applications could just do that on their own, but the seeking API still ruins everything
[14:49] <Daemon404> hmmm perhaos avctx->width and stream->width differ
[14:49] <Daemon404> whic his ugly has hell
[14:49] <durandal_1707> what is ugly?
[14:50] <Daemon404> having those widths differ
[14:50] <cone-406> ffmpeg.git 03Rob Sykes 07master:dc666d360b92: soxr: libsoxr 0.1.1 support
[14:51] <durandal_1707> is it bug?
[14:51] <Daemon404> i dont know
[14:51] <Daemon404> read what i wrote above
[14:52] <durandal_1707> what you wrote?
[14:52] <wm4> what is avctx and stream?
[14:52] <burek> Synthesize a voice utterance using the libflite library.
[14:52] <burek> you guys rock :)
[14:52] <Daemon404> ignore teh stream/avctx bit
[14:53] <Daemon404> look farther above
[14:53] <Daemon404> i guess vp6 has visible vs coded width
[14:53] <Daemon404> but we always output visible width
[14:53] <Daemon404> but report teh coded width
[14:53] <Daemon404> in ffprobe's -show_streams
[14:53] <Daemon404> (but not in the summary!)
[14:54] <durandal_1707> michaelni: how Rob send patches?
[14:56] <Daemon404> ubitux: ping
[14:56] <ubitux> Daemon404: i don't think that's a problem with ffprobe :p
[14:56] <Daemon404> i know
[14:56] <ubitux> which one is correct?
[14:56] <Daemon404> well ffmpeg outputs 460
[14:57] <Daemon404> so that is
[14:57] <Daemon404> ubitux, ffprobe should not output different widths in summary vs show_Streams
[14:57] <Daemon404> imho
[14:57] <Daemon404> that wildly violates the principle of least surprise
[14:58] <ubitux> i'm not sure how i am supposed to guess why they differ :p
[14:58] <Daemon404> do they both output from the samev alue
[14:58] <ubitux> lavf is responsibly from printing the summary
[14:58] <Daemon404> i.e. avctx->width
[14:59] <Daemon404> and not avctx->coded_width
[15:00] <ubitux> you think ffprobe should print coded_width instead/additionally to width?
[15:00] <Daemon404> uhhh
[15:00] <Daemon404> ticket 225
[15:01] <Daemon404> yuvj is full range yuv
[15:01] <Daemon404> yuv is limited range yuv
[15:01] <Daemon404> of COURSE you "lose contrast"
[15:01] <Daemon404> -_-
[15:01] <Daemon404> how did that get to 10 replies and nobody who knows that
[15:02] <Daemon404> ubitux, in this case, on of them is wrong
[15:02] <Daemon404> but you didnt answer my question
[15:03] <Daemon404> do summary and -show_streams both print the same thing
[15:03] <Daemon404> (and not one print width, one print coded_width)
[15:05] <ubitux>             snprintf(buf + strlen(buf), buf_size - strlen(buf),
[15:05] <ubitux>                      ", %dx%d",
[15:05] <ubitux>                      enc->width, enc->height);
[15:06] <ubitux> enc being AVCodecContext
[15:06] <ubitux> this is in lavc/utils
[15:06] <ubitux> (avcodec_string())
[15:06] <ubitux> and seems to be used to print the summary by lavf/utils
[15:06] <Daemon404> hmmm
[15:06] <Daemon404> oh lord
[15:06] <Daemon404> what is this...
[15:07] <ubitux> ffprobe seems to display the same thing
[15:07] <Daemon404> vp6.c modifies avctx->width
[15:07] <ubitux> yeah, the codec might be adjusting the size at some point
[15:07] <Daemon404> thats bad
[15:07] <Daemon404> cause its wrong for ffprobe
[15:07] <Daemon404> :/
[15:09] <burek> (what is Greek harmony) ?
[15:09] Action: Daemon404 falls back to mediainfo's width for now
[15:09] <Daemon404> i dream of one day dropping mediainfo
[15:09] <Daemon404> today is not that day
[15:10] <ubitux> not sure how ffprobe is supposed to handle that
[15:10] <ubitux> maybe just fix/change the codecs doing this
[15:10] <ubitux> or make it use the coded w/h
[15:10] <Daemon404> more like why is vp6 doing it at all
[15:10] <Daemon404> coded__w/h will be very wrong
[15:10] <Daemon404> in many cases
[15:12] <Daemon404> hmm
[15:12] <Daemon404> of course
[15:12] <Daemon404> no comments
[15:12] <Daemon404> and git blame shows it from "vp6 decoder" commit
[15:12] <Daemon404> from the olden days
[15:12] <Daemon404> so there is 0 documentation.
[15:12] <Daemon404> \o/
[15:12] <ubitux> ask BBB{,-work}
[15:12] <ubitux> maybe?
[15:12] <Daemon404> he didnt write it
[15:13] <Daemon404> some guy named Aurelien Jacob did
[15:13] <ubitux> no news from him for a while now :(
[15:17] <Daemon404> ubitux, does ffprobe decode a frame for only summary
[15:17] <Daemon404> but not -show_streams
[15:17] <Daemon404> ?
[15:19] <ubitux> the summary is done by a dump thing function at startup
[15:19] <Daemon404> which one calls avformat_find_stream_info
[15:20] <Daemon404> (aka decode a frame)
[15:20] <ubitux> show_streams loops over each fmt->stream and print what's in
[15:20] <Daemon404> well SOMETHING has to be change between the two
[15:20] <Daemon404> r they wouldnt differ
[15:20] <ubitux> avformat_find_stream_info() is always called at first
[15:21] <ubitux> afaik
[15:21] <ubitux> maybe lavf reset some state, dunno
[15:21] <Daemon404> well it's kind of a big problem
[15:21] <Daemon404> :P
[15:22] <Daemon404> i dont now what happens in between sumary and show_Streams
[15:22] <Daemon404> or even if theyre the same contexts
[15:26] <Daemon404> ubitux, meh
[15:26] <Daemon404>  if ((ret = open_input_file(&fmt_ctx, filename)) <-- before show_streams
[15:26] <Daemon404> inb4 re-opens the damn file
[15:27] <ubitux> oh
[15:28] <ubitux> Daemon404: afaict it's only opened once
[15:28] <ubitux> where do you see that code?
[15:28] <Daemon404> hmm, probe_file
[15:29] <ubitux> please check with ffprobe
[15:29] <Daemon404> same deal anyway
[15:29] <Daemon404> the originally checked both
[15:29] <ubitux> but i see that code called only once in both projects
[15:29] <Daemon404> theres so much absraction
[15:29] <Daemon404> its hard to fgure out wtf is going
[15:29] <Daemon404> why i hate diving into the cli util code
[15:29] <ubitux> it's only opened once
[15:30] <Daemon404> well clearly something changes.
[15:30] <ubitux> yeah right
[15:30] <ubitux> maybe within avformat_find_stream_info.
[15:30] <ubitux> (after printing)
[15:30] <Daemon404> thats only called once
[15:30] <Daemon404> during open.
[15:31] <Daemon404> unless im mistaken
[15:31] <ubitux> avformat_find_stream_info() { /* save shit */ /* print shit */ /* restore shit */ } ?
[15:31] <ubitux> (random guess)
[15:31] <Daemon404> no
[15:31] <Daemon404> er well
[15:32] <Daemon404> i dont think avformat_find_stream_info doest hat
[15:32] <Daemon404> the dump function il lcall avcodec_string
[15:32] <Daemon404> iirc
[15:32] <ubitux> then maybe av_dump_format()
[15:32] <Daemon404> which is distinctly after find_stream_info in open_file
[15:32] <ubitux> yes that's what i said
[15:32] <ubitux> 15:06:22 <@ubitux> (avcodec_string())
[15:33] <Daemon404> which in turn calls dump_stream_format
[15:33] <Daemon404> (fro mdump_format i mean)
[15:34] <Daemon404> and i dont see anything destructive there
[15:39] <Daemon404> k im narrowing down where it happens
[15:40] <Daemon404> ubitux / wbs -- found the issue
[15:41] <Daemon404> } else if (avcodec_open2(stream->codec, codec, NULL) < 0) {
[15:41] <Daemon404> inside open_file
[15:41] <Daemon404> after this call
[15:41] <Daemon404> widt is changed
[15:41] <Daemon404> it resets it
[15:42] Action: Daemon404 attempts a fix
[15:43] <Daemon404> " Add FFprobe tool."
[15:43] <Daemon404> old commit is old
[15:46] <durandal_1707> dimensions from container and bitstream differ
[15:47] <Daemon404> avformat_find_stream_info exists for this reason
[15:47] <Daemon404> and show_streams is SUPPOSED to show stream info
[15:48] <Daemon404> ill cc stefano on the patch
[16:03] <cone-406> ffmpeg.git 03Paul B Mahol 07master:6c7d1608dd0c: sgidec: use unchecked bytestream2 functions where it makes sense
[16:05] <cone-406> ffmpeg.git 03Joseph Artsimovich 07master:4a6bd346373b: Handle an invalid extra mpeg2 picture header following a frame-encoded picture.
[16:15] <durandal_1707> why is sgi marked as lossy?
[16:26] <cone-406> ffmpeg.git 03Paul B Mahol 07master:5b802cf567a0: lavc/codec_desc: add/fix .props for SGI/DPX/X-face/BRender PIX image
[16:42] <Daemon404> ubitux, patch on ML
[19:19] <Daemon404> wow
[19:19] <Daemon404> athlon64
[19:19] <Daemon404> i hit a timewarp
[19:22] <Daemon404> hey ubitux, i thought ebur128 as audio normalization alreay?
[19:24] <durandal_1707> it is just scanner as its description says
[19:24] <ubitux> Daemon404: real time normalization is achieved with the volume filter
[19:24] <ubitux> ebur128 injects the volume adjustement metadata
[19:24] <Daemon404> oic
[19:25] Action: Daemon404 thinks ebur128 is interesting
[19:25] <Daemon404> for playback, anyway
[19:26] <kierank> it is or will be mandatory in a lot of countries
[19:26] <kierank> so having it in lavfi is great
[19:26] <durandal_1707> why mandatory?
[19:26] <Daemon404> well im more evil
[19:26] <ubitux> durandal_1707: legally speaking
[19:26] <Daemon404> i like it as a code reference poitn =p
[19:26] <Daemon404> maybe for a sox filter
[19:27] Action: Daemon404 runs
[19:27] <av500> if you are broadcasting
[19:27] <av500> not if you play music at home :)
[19:27] <av500> that'S only for 2014
[19:27] <ubitux> durandal_1707: typically ads volume increase between tv shows or that kind of crap
[19:27] <durandal_1707> ban tv
[19:27] <ubitux> durandal_1707: in France it's now illegal above a certain loudness level, estimated through ebu r128
[19:32] <kierank> internet will kill tv blah blah
[19:34] <kierank> all your entertainment will be provided on one converged device folks
[19:36] <av500> right
[19:36] <wm4> it will use HTML5 technology
[19:37] <av500> right
[19:37] <kierank> that too
[19:38] <durandal_1707> changing stere3d parameters does nothing, filter in lavfi is just broken
[19:55] <durandal_1707> michaelni: fine to remove mp=noise?
[20:00] <michaelni> durandal_1707, if all features are ported and no speedloss yes
[20:02] <Compn> durandal_1707 : cant get stereo3d to work ?
[20:02] <durandal_1707> michaelni: there is no speedloss, because inline asm is never compiled
[20:04] <durandal_1707> Compn: not with ffplay, lavfi code have some code commented out (probably was fast easy hack ...), working on port, so that code will hopefully disapear soon
[20:04] <michaelni> durandal_1707, comparissions should be done against the fully optimized code
[20:04] <michaelni> with all asm
[20:05] <durandal_1707> but that is imposible mission as asm code is never compiled, and noone volunter to port that asm
[20:05] <Compn> michaelni : i think hes saying your wrapper doesnt compile it
[20:05] <durandal_1707> although copy-past could work, i prefer to move it to yasm
[20:05] <Compn> :)
[20:12] <durandal_1707> lol dubois is mistyped dubios
[20:15] <mystica555> how dubious >.<
[20:31] <durandal_1707> lol why is mptestsrc GPL?
[20:32] <durandal_1707> and also swreample-test app?
[20:51] <michaelni> durandal_1707, you can test mpcodecs with asm through mplayer
[22:00] <ubitux> cbsrobot_: still interested in the true peak thing?
[22:05] <cbsrobot_>  ubitux sure
[22:07] <ubitux> i was almost motivated to do it
[22:07] <ubitux> it doesn't look complicated afaiu
[22:07] <ubitux> cbsrobot_: but what's the purpose of it?
[22:08] <cbsrobot_> well I need to do a lot of ebur128 complient stuff
[22:08] <cbsrobot_> and I do not want to use protools or similar things all the time
[22:10] <ubitux> yeah but what useful information does this true peak gives you then?
[22:11] <ubitux> or maybe you just have some "compliance constraints" and check if it matches, whatever the meaning?
[22:12] <durandal_1707> protools?
[22:12] <kierank> it's a professional audio thing
[22:13] <durandal_1707> and what is difference from amateur audio thing?
[22:13] <ubitux> the cost
[22:13] <Daemon404> and functionality
[22:14] <Daemon404> audacity is a piece of shit
[22:14] <durandal_1707> ardour?
[22:17] <Daemon404> ever tried it, but i somehow doubt it lives up to pro tools or audition or soundforge.... (based on no actual facts on my part, of course)
[22:17] Action: Daemon404 is extremly skeptical whenever it comes to editing apps (esp compositing) vs FOSS
[22:18] <cbsrobot_> I think ebur128 specifies values for integrated loudness, loudness range, and true peak
[22:21] <cbsrobot_> we mostly use LMB from nugen ( http://www.nugenaudio.com/LMB_Loudness_batch_processor.php ) which can even correct the audio to make it ebur128 complient - but I prefer the shell if I can
[22:30] <kierank> there are non-ffmpeg ways of doing ebur128
[22:31] <kierank> http://schedule2012.rmll.info/IMG/pdf/Introduction_To_FreeLCS-14.pdf
[22:34] <cbsrobot_> looks interesting
[22:35] <cbsrobot_> btw: anybody knows a good way to upmix stereo to 5.1 ?
[22:36] Action: ubitux doesn't get why so specs is so insane about true peaks while it seems to only be a max(abs(samples))
[22:47] <Daemon404> ubitux, well
[22:47] <Daemon404> because it is a spec.
[22:47] <Daemon404> theyre all insane.
[22:49] <ubitux> :(
[23:19] <ubitux> cbsrobot_: looks like the main issue will be how to display/print that info
[23:19] <ubitux> :(
[23:43] <cbsrobot_> ubitux: :(
[23:44] <cbsrobot_> kierank: freelcs is a hell of a  soft
[23:48] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:bf90ef0314e2: avcodec: add ff_frame_get_metadatap()
[23:48] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:5ade6bfb03d4: doc/examples/demuxing: use AVFrame accessor functions
[23:48] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:3ded235f5932: ffprobe: use AVFrame accessor functions
[23:48] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:e0f716a9d9f5: ac3dec: use AVFrame accessor functions
[23:48] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:f23265913029: tiff: use AVFrame accessor functions
[23:48] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:7d7fb70129a6: cpia: use AVFrame accessor functions
[23:48] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:ff080346c680: gifdec: use AVFrame accessor functions
[23:48] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:f59ff8faa214: pngdec: use AVFrame accessor functions
[23:48] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:30806ddcbc6d: avcodec/rawdec: use AVFrame accessor functions
[23:48] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:cc38ca67482b: avcodec/utils: use AVFrame accessor functions
[23:48] <cone-406> ffmpeg.git 03Michael Niedermayer 07master:ec1d2e2fb04a: ffplay: use AVFrame accessor functions
[23:51] <nevcairiel> hm, is it really required to use these functions for internal code which is always on the same ABI/API anyway?
[00:00] --- Sat Mar  2 2013