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

burek burek021 at gmail.com
Wed Jul 30 02:05:02 CEST 2014


[00:11] <cone-572> ffmpeg.git 03Bernhard Übelacker 07master:dc71f1958846: video4linux2: Avoid a floating point exception
[00:11] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:25a20608909f: Merge commit 'dc71f1958846bb1d96de43a4603983dc8450cfcc'
[00:17] <cone-572> ffmpeg.git 03Marc-Antoine Arnaud 07master:c9d982aa11a6: mxf: Detect Vanc/Vbi SMPTE-436M mxf track
[00:17] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:4a4d0258eef2: Merge commit 'c9d982aa11a6267611c3770792f0e04b48438348'
[00:26] <cone-572> ffmpeg.git 03Marc-Antoine Arnaud 07master:259fe7280d0b: mxf: Extract origin information from material and source track
[00:26] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:8b1e920676f6: Merge commit '259fe7280d0b63dc7a8ff017d44f26d3a84cfde8'
[00:34] <cone-572> ffmpeg.git 03Luca Barbato 07master:e4a462e3eafd: configure: Use require_pkg_config for Speex
[00:34] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:621d4089a4cf: Merge commit 'e4a462e3eafdfe336f4d079c3ba72a9cdb4748b0'
[00:40] <cone-572> ffmpeg.git 03Diego Biurrun 07master:4f8cf0dc4ef6: x86: build: Restore ordering of OBJS lines
[00:40] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:a91c5ed00874: Merge commit '4f8cf0dc4ef6110174056df7edd9dc2f2a988b6d'
[01:22] <cone-572> ffmpeg.git 03Diego Biurrun 07master:59ca29a560ba: dump: Use correct printf conversion specifiers for POSIX int types
[01:22] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:60831f441db8: Merge commit '59ca29a560ba0cfe97457de8cedf77db434f0de4'
[01:29] <cone-572> ffmpeg.git 03Diego Biurrun 07master:019a28cd6302: sanm: Use correct printf conversion specifiers for POSIX int types
[01:29] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:d55d8229fb12: Merge commit '019a28cd630286ecb2b06ee62025a17c821b493e'
[01:51] <cone-572> ffmpeg.git 03Diego Biurrun 07master:942269fd00cb: caf: Use correct printf conversion specifiers for POSIX int types
[01:51] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:983109bbd999: Merge commit '942269fd00cb48328e4cffb6e21a0b691ce9f6bc'
[02:03] <trn> Is there a separate channel for NUT discussion or just nut-devel list?
[02:04] <beastd> trn:  http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
[02:05] <kierank> sooo who is going to vdd?
[02:07] <Compn> i might be there, just to annoy everyone again :)
[02:07] <kierank> michaelni: are you going?
[02:08] <beastd> kierank: Not me this year :(  I will be in Shanghai at that time.
[02:10] <Compn> i'd like to visit china one of these days 
[02:35] <trn> BTW, to get my wallclock timecode into NUT, I'm just using the v4 timestamped syncpoint feature.
[02:36] <trn> Is there any sort of documentation as to the memory requirements or what not ... I'm looking at some streams up to 12 hours...
[02:38] <Timothy_Gu> beastd: reallh?
[02:38] <Timothy_Gu> really
[02:39] <Timothy_Gu> I am from Shanghai
[02:45] <Timothy_Gu> shoot beastd quitted
[03:51] <cone-572> ffmpeg.git 03James Almer 07master:4f91bb0ff0bd: x86/hevc_deblock: use psignw instead of pmullw where possible
[04:05] <cone-572> ffmpeg.git 03Christophe Gisquet 07master:65746bfbae3d: hevc_filter: run vertical and horizontal together
[13:36] <cone-104> ffmpeg.git 03James Almer 07master:c74b08c5c60a: x86/hevc_deblock: remove some unnecessary instructions
[14:04] <cone-104> ffmpeg.git 03James Almer 07master:88ba821f23cb: x86/hevc_deblock: improve luma functions register allocation
[14:36] <cone-104> ffmpeg.git 03James Almer 07master:73c4f63ba5a3: x86/hevc_deblock: add add ff_hevc_[hv]_loop_filter_luma_{8, 10, 12}_avx
[15:30] <ubitux> when will we be able to clic on hashes in the trac?
[15:38] <ubitux> btw, does h264 have some kind of pyramidal MV structure?
[15:38] <ubitux> like, saying a large zone is moving from one point to another
[15:39] <ubitux> and inside MV are smaller vectors relative to that larger zone movement
[15:39] <ubitux> ?
[15:44] <mraulet> ubitux: is it x264 or h264?
[15:46] <ubitux> well, i'm asking decode side
[15:47] <ubitux> so h264
[15:52] <mraulet> so i dont get your question, the decoder is not guessing anything, it takes MV predictors and adds deltas on top of it (dmvx, dmy). Those 2 values are given by the parser. 
[15:52] <nevcairiel> he is just wondering if h264 has such a feature, a "semi-global" mv that gets "refined" by local mvs
[15:59] <ubitux> mraulet: yeah as nevcairiel says, i'm asking if in the MV are stored in such structure
[16:00] <ubitux> that actually reveals a larger motion
[16:00] <kierank> are you talking about GMC?
[16:00] <mraulet> the predictors are quite simple in H264
[16:04] <ubitux> kierank: not really
[16:05] <ubitux> or at least i don't know
[16:05] <ubitux> mraulet: so only a vector, not relative to another bigger one?
[16:10] <mraulet> http://vc.cs.nthu.edu.tw/home/paper/codfiles/kcyang/200407191716/H.264_Motion.ppt
[16:10] <mraulet> slide 7
[16:34] <ubitux> mraulet: ok so the answer is... "no" i guess :p
[16:34] <mraulet> :-)
[16:36] <nevcairiel> wonder how complex detection that would be
[16:36] <nevcairiel> i guess you could just look at all the MVs and try to "normalize" them
[16:38] <ubitux> it's strange though
[16:38] <ubitux> would that help to say half of the frame should go to the other half
[16:38] <ubitux> and encode way smaller MV inside that?
[16:38] <ubitux> i would have though h264 had that
[16:39] <michaelni> "<ubitux> when will we be able to clic on hashes in the trac?", is there a plugin that does that or some configuration ?
[16:40] <nevcairiel> ubitux: i would think it would help in something like pans, whole image pans, small parts move in other directions, but apparently it was never considered, maybe not as useful as we might think
[16:42] <cone-104> ffmpeg.git 03Nicolas Martyanoff 07master:0c889da8cb53: avformat/hlsenc: fix cleanup after avformat_write_header()
[16:45] <Plorkyeran> the standard git plugin for trac linkifies hashes
[16:45] <Plorkyeran> you just need a local copy of the repository that's auto-synced
[16:48] <Daemon404> x/g 42
[16:48] <Daemon404> urg
[17:12] <ubitux> mmh
[17:13] <ubitux> .alias = "gray8,y8"
[17:13] <ubitux> :/
[17:23] <nevcairiel> Another hack to please someone's feelings about bad names
[17:24] <Daemon404> AV_PIX_FMT_RACIAL_SLUR
[18:28] <michaelni> ubitux, Plorkyeran i tried enabling git in trac but it doesnt work
[18:30] Action: michaelni is an idiot
[18:30] <michaelni> trac.versioncontrol.* = disabled
[18:30] <michaelni> ill make a break and then ill retry :)
[19:15] <Daemon404> always interesting bug titles
[19:18] <michaelni> ubitux, Plorkyeran, enabling git in trac makes ticket load times increase 6 fold 0.4 sec ->2.4 sec (for ticket 3143 which AFAICS has 1 git hash in it)
[19:19] <kierank> Daemon404: that's truly a mental feature
[19:19] <michaelni> so i left it disabled ATM, unless someone has some idea
[19:20] <Daemon404> kierank, is line 31 anythign special in broadcast land?
[19:20] <Daemon404> i dont recall it being so
[19:20] <kierank> probably he's measuring from a weird offset
[19:20] <Daemon404> yeah cause teletext is not 31
[19:20] <michaelni> ubitux, Plorkyeran, that was with cached_repository = false, with it true its another 0.2 sec slower
[19:20] <kierank> teletext is line 7-22 iirc
[19:21] <michaelni> also repository_sync_per_request empty which AFAIK means disabled
[19:22] <michaelni> ahh, hi beastd, trac+git sucks see above
[19:22] <kierank> Daemon404: oh i think he's counting in literal lines
[19:22] <kierank> and ignoring field 2
[19:22] <Daemon404> o
[19:23] <kierank> that is truly a mental way of detecting subtitles
[19:24] <kierank> isolate a line and run blackdetect on it
[19:24] <Daemon404> :D
[19:28] <beastd> michaelni: I do not remember it being that slow at work. It probably depends on the size of the git repo or sth. Need to check the settings and performance next week.
[19:30] <michaelni> beastd, isnt important at all, we didt had it for 3 years, i just find it ridiculous how everyone manages to write software that is so slow, i mean if this was a 8bit cpu running at 5khz i could understand why doing a single hash table lookup would need a few milliseconds but hey modern multi ghz multi core cpu needing several seconds
[19:32] <Daemon404> michaelni, trac is famously slow
[19:33] Action: Daemon404 remembers it doing 10k db queries per page for one project
[19:33] <michaelni> i know i did spend many hours trying to workaround that and trim all kinds of uneeded stuff away
[19:33] <Daemon404> that doesnt sound fun
[19:33] <Daemon404> its an old php codebase
[19:34] <michaelni> it was more trimming config than looking at trac code
[19:35] <JEEB> Daemon404, trac is python
[19:35] <JEEB> not php
[19:35] <michaelni> for example the search page load time is proportional to the number of columns displayed
[19:35] <JEEB> but yes, it's very awful
[19:35] <j-b> JEEB: no, trac is crap
[19:35] <j-b> JEEB: not python
[19:35] <Daemon404> oh youre right
[19:35] <Daemon404> i keep thinking it is php
[19:35] <Daemon404> because it is so terrible
[19:36] <Daemon404> but less terrible tahn all the otehrs.
[20:01] <jamrial> That Semel88 account also posted another spam attachment in the same ticket six weeks ago
[20:07] <cone-631> ffmpeg.git 03Luca Barbato 07master:e253a9e2b3d6: avformat: Move av_probe_input* to format.c
[20:07] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:e066f01539fd: Merge commit 'e253a9e2b3d683eb51db7c776326eb07de10ad4c'
[20:31] <cone-631> ffmpeg.git 03Luca Barbato 07master:69e7336b8e16: avstring: Expose the simple name match function
[20:31] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:31e0b5d3cb40: Merge commit '69e7336b8e16ee65226fc20381baf537f4b125e6'
[21:10] <cone-631> ffmpeg.git 03Luca Barbato 07master:3a19405d574a: avformat: Use the mime type information in input probe
[21:11] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:80a3a6611fe5: Merge commit '3a19405d574a467c68b48e4b824c76617fd59de0'
[21:11] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:9694695a21d0: avformat: fix probe mime version checks
[21:17] <cone-631> ffmpeg.git 03Luca Barbato 07master:02cf0c9e4296: aac: Register the mime type
[21:17] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:8cad746093db: Merge commit '02cf0c9e42967de1e4d2803bee3573bc5b735fdd'
[21:26] <cone-631> ffmpeg.git 03Luca Barbato 07master:fa38573cd9ce: matroska: Register mime types
[21:26] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:92de4450347c: Merge commit 'fa38573cd9ce4ab727f86f57c03b113cfd4c9d0a'
[21:32] <cone-631> ffmpeg.git 03Nidhi Makhijani 07master:ccbf370f2000: mpegvideo: move vol_control_parameters to the only place it is used
[21:32] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:58eaa95116d9: Merge commit 'ccbf370f2000b9b27f4af259c23007d67f7ea46e'
[21:56] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:6d69503883da: avformat/format: simplify ifdeffery
[21:56] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:4182728c7873: avformat/format.c: remove duplicate include, put libavutil includes together
[21:56] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:d38edeee9b70: avformat/format: fix memleak and error code
[23:11] <wm4> so, there's this nice function av_opt_set_from_string()
[23:11] <wm4> but where's the equivalent for parsing into a AVDictionary?
[23:11] <wm4> since since things like protocols for formats don't allow setting options directly, and you must pass an AVDictionary of options
[23:47] <cone-631> ffmpeg.git 03Christophe Gisquet 07master:a507623bad7e: x86: hevc_mc: fix register count usage
[00:00] --- Wed Jul 30 2014


More information about the Ffmpeg-devel-irc mailing list