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

[burek]

[01:26] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:fccd85b9f305: avcodec: fix aac/ac3 parser bitstream buffer size
[02:02] <rcombs> what's AVCodecContext::coded_frame for?
[02:10] <iive> avcodec.h contains some documentation
[02:10] <iive> my guess would be that this is the video frame picture
[02:11] <iive> as it is encoded. the encoder need to decode the picture in order to knows how it would look to the decoder.
[02:12] <iive> e.g. you encode video, you put very bad quality. this contains the picture but looking blocky and ugly, because of compression artifacts.
[02:14] <rcombs> most encoders seem to allocate it once, free it when closed, and set a few parameters on it when encoding frames
[02:17] <iive> if it is decoded encoder output, then it should be allocated by get_buffer and be kept for reference.
[02:18] <iive> well, somebody else might know.
[02:18] <iive> i'm off.
[02:45] <wm4> rcombs: many things in ffmpeg are due to legacy reasons; for advance use you pretty much have to use the official ffmpeg code inspection tool (the tool is called "grep" and you use it on source files)
[02:46] <wm4> then you try to make sense out of it and then you fail, and then you don't care
[02:46] <wm4> it's simple
[02:46] <cone-718> ffmpeg.git 03Michael Niedermayer 07master:1b5ec6a0c330: avcodec/fic: Check if a frame is available before using it
[02:48] <rcombs> wm4: that's what I tried to do, and determined that it probably wasn't important but might be slightly useful
[02:48] <rcombs> and figured I'd ask
[02:51] <wm4> basically I'm saying that the docs are bad/incomplete, and it's not surprising if you dig out something that doesn't seem to have much purpose
[04:05] <Timothy_Gu> Finally, I'm back
[04:05] <Timothy_Gu> Any more reviews for the makeinfo stuff?
[06:10] <jamrial> kurosu: just saw your pextrd patch in github. did you bench it?
[06:10] <jamrial> I tried the same in hevc_deblock, and pextrd didn't seem faster than a pshufd + movd there
[06:13] <jamrial> same way i tried replacing a movq + punpcklbw with a pmovzxbw, and the latter was in fact slightly slower, somehow
[06:20] <fionag> yeah, pextrd is 1 shuffle uop + a store
[06:20] <fionag> it's not going to be better than a shuffle + store, in my experience
[06:27] <jamrial> what about pmovzxbw? intel docs mention it's 1 cycle latency, same as a punpcklbw, yet somehow it was slower than the latter + a movq
[06:29] <fionag> well I don'tthink it could be -faster-, because it's a load uop + shuffle uop
[06:29] <fionag> just like movq + punpck
[06:30] <fionag> pengvado's theory if I remember it right was that pmovzxbw required the load and shuffle uops to be more tightly coupled (like e.g. in the same cycle) making out of order execution less effective
[06:30] <fionag> but I think that was relatively wild speculation, nobody really knew why it was slower :<
[07:51] <kurosu> jamrial, exactly, hence why I didn't submit it at all
[07:52] <kurosu> In fact everything there that hasn't been submitted is kind of a failure / useless
[07:52] <jamrial> ah ok
[07:53] <kurosu> well, not failure, but yes, not "benchmarkably" useful
[07:55] <kurosu> I think some of the gprs used as temporary storage could have improved usage with proper shuffling & co
[07:55] <kurosu> but seeing this, I bet it won't have much an impact
[07:56] <kurosu> *the gprs used in the dbf code
[08:01] <kurosu> I'd really like to move on with that mc code
[08:02] <kurosu> I'm planning on "retagging" most functions from sse4 to ssse3, but I don't want conflicts on that work
[12:28] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:ddad09397247: wavpackenc: fix number of samples per block
[12:43] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:e32eddaa51ad: wavpackenc: make assert more thorough
[13:22] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:fb1a98ec5b4e: x86: hevc_mc: assume 2nd source stride is 64
[14:16] <Compn> llogan : so are you back now ? should i stop moderating queue of ffmpeg-devel ? 
[14:25] <wm4> does it need much moderation?
[14:57] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:b9f3912a65ac: hevc: move MAX_PB_SIZE declaration
[15:00] <Compn> wm4 : people postin who arent subscribed
[15:01] <Compn> like 1-3 a week, depending on how many flames are at cc'd lists like deb-devel :
[15:02] <wm4> oh I see, that debian flame must generate lots of emails from unregistered people
[15:02] <nevcairiel> it seemed to have moved off-list now
[15:02] <Compn> yes
[15:02] <nevcairiel> or noone approves them anymore
[15:02] <Compn> but also there are lots of patches from random people who arent subscribed
[15:02] <Compn> i've been approving them, and no, there are less mails now.
[15:03] <Compn> possibly because my strategy of asking ffmpeg devs to not reply to flames worked
[15:21] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:d4f44b66d36c: hevcdsp: remove compilation-time-fixed parameter
[15:25] <kierank> wm4: the best bit is that the libav responses don't cc to ffmpeg-devel
[15:25] <kierank> even though the rest of the thread is
[15:26] <wm4> huh
[15:26] <wm4> guess I'm missing the juicy bits of the thread then
[15:26] <kierank> i gave up tracking the threa
[15:27] <ubitux> you'd better watch https://lists.debian.org/debian-devel/2014/08/ than ffmpeg-devel yes
[15:27] <kierank> probably should have responded to luca's nonsense in the name of balance
[15:27] <kierank> but ubitux mostly di that
[15:27] <ubitux> but not really interesting
[15:28] <Compn> no way, let luca's nonsense sit there
[15:28] <Compn> it looks bad on him
[15:28] <kierank> there was nonsense from michael as well
[15:28] <kierank> mans was an author of swresample you know
[15:30] <Compn> i didnt know that. i guess i didnt really look into who wrote what
[15:31] <Compn> i know mans wrote a lot of fate stuff
[15:31] <ubitux> it seems there are still a lot of demand on dumping vobsubs
[15:31] <ubitux> :(
[15:31] <Compn> lol @ mpv
[15:31] <ubitux> saste: made up your mind on dvd support?
[15:33] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:dad7f155678f: hevcdsp: remove more instances of compile-time-fixed parameters
[15:36] <michaelni> kierank, yes mans is AFAIK the author of some code that is in libswresample
[15:36] <michaelni> some arm code to be more precisse
[15:37] <kierank> see my response to that thread
[15:38] <Compn> oh apparently i've missed quite a few mails from deb-devel. 
[15:38] <Compn> dang my broken eyeballs
[15:43] <Compn> i like this mail in particular https://lists.debian.org/debian-devel/2014/08/msg00760.html
[15:49] <wm4> those are some juicy emails
[15:54] <wm4> this flame war is like kuwait all over again
[16:09] <ubitux> swr_convert_frame() is untested?
[16:17] <michaelni> ubitux, the avframe related swr stuff isnt tested no, i wanted to add some code to test it but had too many other things to do 
[16:17] <michaelni> feel free to add code to test it
[16:17] <ubitux> i was looking for an example in particular, not really important
[16:19] <kurosu> michaelni, what do you think about my comments in "[PATCH] h264: Move AFD to side data to match MPEG-2" ?
[16:19] <kurosu> it's probably work for little to no benefit
[16:19] <kurosu> but I was thinking of sending patches to do what I describe if there's any merit
[16:33] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:2346f2b5db59: x86: hevcdsp: use compilation-time-fixed constant
[16:38] <michaelni> kurosu, maybe the side data code could be left where it is but instead of hard failing would just print a warning. failure to create these sidedata does not appear fatal to me
[16:39] <kurosu> ok, make sense, although an allocation failure is a bad sign at this point
[16:39] <michaelni> yes
[16:39] <kurosu> *it makes sense
[16:43] <kurosu> on the other hand, some users would prefer it to explode rather than go on
[16:44] <kurosu> using "h->avctx->err_recognition & AV_EF_EXPLODE" doesn't make sense here I guess
[16:44] <Daemon404> g 48
[16:44] <Daemon404> woops
[17:23] <saste> ubitux, uhmm...
[17:23] <ubitux> :)
[17:24] <saste> ubitux, i won't have much time for that
[17:24] <saste> ubitux, BTW did you do something about scripting?
[17:25] <ubitux> yes, but my interest drifted to something else
[17:25] <ubitux> sorry :)
[17:27] <saste> ubitux, you don't have to be sorry
[17:27] <saste> i wonder what was the last relevant thing I did for ffmpeg...
[17:28] <ubitux> cb0524f7a02f910ae2df163e655cb495ea9f2493
[17:29] <ubitux> :s
[17:30] <ubitux> saste: i don't do much relevant things either you know :)
[17:30] <ubitux> you actually fix more tickets than i do
[17:31] <saste> yeah i liked that commit :-D
[17:31] <saste> ubitux, did you already commit codecview?
[17:31] <ubitux> i'll do tonight
[17:31] <ubitux> i might add the test at the same time too
[17:33] <ubitux> i also have some pixelutils stuff pending
[17:54] <nexus_6> Hi I've playing with a patch posted on the mailing list that enables hds demuxing: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154612.html
[17:55] <nexus_6> and I have made some modifications to make it work with some hds live streams
[17:55] <nexus_6> particularly hds streams from rte televsion http://livehds.rasset.ie/hds-live/_definst_/rte1/rte1_288p.f4m
[17:56] <nexus_6> should I post this modified patch to the mailing list or should I contact the original author
[17:56] <nexus_6> thanks
[17:57] <ubitux> was that patch applied?
[17:57] <nexus_6> no
[17:58] <ubitux> mmh, maybe you can contact the author first, but if he doesn't reply, i guess you can just cherry-pick his patch, add yours on top, and resend both
[17:58] <ubitux> (or merge them and use signed-off to add your authorship)
[17:58] <ubitux> s/merge/squash/
[17:58] <nexus_6> ok thanks for the info
[18:20] Action: durandal_1707 forces himself to not send K&R patches
[18:49] <cone-195> ffmpeg.git 03Diego Biurrun 07master:b0bfd09f88da: configure: Suppress "potentially uninitialized variable" warnings from MSVC
[18:49] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:de9e0386b2f0: Merge commit 'b0bfd09f88da8b7c7666faf0ac7d5e74559dba9f'
[18:53] <Compn> cool hds support
[18:57] <cone-195> ffmpeg.git 03Janne Grunau 07master:dc4b2e7d3390: rv34: use ff_mpeg_update_thread_context only when decoder is fully initialized
[18:58] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:e356f6c55d46: Merge commit 'dc4b2e7d33903a6b9380e8a84b22b3a20facbb08'
[19:08] <cone-195> ffmpeg.git 03Anton Khirnov 07master:4d6c5152849e: electronicarts: do not fail on zero-sized chunks
[19:08] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:350dd8534575: Merge commit '4d6c5152849e23a4cc0f6a6ac2880c01ebcd301b'
[19:27] <saste> ubitux, timecode display in drawtext only works if you have constant framerate, right?
[19:28] <saste> since the timecode context is configured with a fixed rate
[19:28] <saste> what if you have erratic timestamps?
[19:29] <saste> that is frame PTSs not at regular intervals
[20:47] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:a59f85d1064d: wavpack: check number of channels
[20:47] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:4adad5a19ac8: wavpackenc: reset trailer info on block encoding
[20:59] <cone-195> ffmpeg.git 03Anton Khirnov 07master:7b6aae23e12f: electronicarts: read the framerate for MAD
[20:59] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:ce1059d5c909: Merge commit '7b6aae23e12f41cdfac7f1069debfe44d9a3d136'
[21:06] <cone-195> ffmpeg.git 03Anton Khirnov 07master:cb7b1a2dfb54: electronicarts: set the framerate for TGQ/TQI
[21:06] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:3e07a056a8e6: Merge commit 'cb7b1a2dfb547ab78342a7a9d5cd729d77d90421'
[21:48] <cone-195> ffmpeg.git 03Luca Barbato 07master:051aadeed104: ogg: Provide aliases for Speex, Opus and audio-only ogg
[21:48] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:300d489ac9bb: Merge commit '051aadeed104ecbe8ee4850ec2d7e5394f5e1ccd'
[21:55] <cone-195> ffmpeg.git 03Diego Biurrun 07master:1019b7c4edff: os_support: Undefine lseek/stat/fstat before defining them
[21:55] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:8f3caf52fc0d: Merge commit '1019b7c4edff537499c4a6cb0d65abae04ce58f6'
[22:02] <cone-195> ffmpeg.git 03Diego Biurrun 07master:3526ab891c28: qt-faststart: Undefine fseeko/ftello before defining them
[22:02] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:d2a06242966d: Merge commit '3526ab891c28396ada8b58bf7647309bab30de1d'
[22:29] <cone-195> ffmpeg.git 03Timothy Gu 07master:6e51e746c426: vidstab*: Remove accidentally exported av_2_vs_pixel_format()
[22:29] <cone-195> ffmpeg.git 03Timothy Gu 07master:8495c6086d04: vidstabutils: improve documentation
[23:53] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:aaaf7261b707: avcodec/hevc_ps: fix 1 vs. 0 typo
[00:00] --- Sat Aug 23 2014