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

burek burek021 at gmail.com
Fri Mar 7 02:05:02 CET 2014


[02:02] <cone-739> ffmpeg.git 03wm4 07master:636273d3d4a8: http: handle ICY in presence of chunked transfer encoding
[02:09] <cone-739> ffmpeg.git 03Lukasz Marek 07master:f495fbe76a26: lavf/avio: fix ffurl_alloc error checks
[02:09] <cone-739> ffmpeg.git 03Lukasz Marek 07master:4ba6a534dc94: lavf/http: return error on seeking to negative postion
[02:09] <cone-739> ffmpeg.git 03Lukasz Marek 07master:1aa262f460c0: lavf/http: return error from seek on invalid whence
[02:09] <cone-739> ffmpeg.git 03Lukasz Marek 07master:2475fdbd047d: lavd/avdevice: always free detected devices on error
[02:09] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:c832bf0c38a3: Merge remote-tracking branch 'lukaszmluki/master'
[02:11] <michaelni> nevcairiel, should i apply the 2 dxva2_h264 patches or is there something to wait for ? ( the discussion doesnt clearly say apply it nor dont apply it)
[03:37] <cone-739> ffmpeg.git 03Lukasz Marek 07master:bba7b6fc4105: Revert "lavu/buffer: add release function"
[04:41] <Zeranoe> Looks like the downmix/loss of LFE is getting more attention: http://ffmpeg.zeranoe.com/forum/viewtopic.php?t=1851
[08:19] <saigono> nevcairiel: Thank you! Your advice was very helpful :)
[10:05] <cone-884> ffmpeg.git 03Michael Niedermayer 07release/2.1:d87ac93bcad3: avformat/oggparsevorbis: dont use invalid granules
[10:05] <cone-884> ffmpeg.git 03Michael Niedermayer 07release/2.2:124c78fd4449: avformat/oggparsevorbis: dont use invalid granules
[12:48] <cone-884> ffmpeg.git 03Anton Khirnov 07master:bba2a7cc5f7c: lavfi: use the correct filter context for logging an error.
[12:48] <cone-884> ffmpeg.git 03Michael Niedermayer 07master:b76059058aa6: Merge commit 'bba2a7cc5f7c7aaa32a938f3d4edd9f555f39cdb'
[13:08] <cone-884> ffmpeg.git 03Anton Khirnov 07master:599b81ca9a8e: lavfi: add shuffleplanes filter
[13:08] <cone-884> ffmpeg.git 03Michael Niedermayer 07master:2fb0027c267d: Merge commit '599b81ca9a8e04a27ddad94af462171d16063167'
[13:23] <plepere> hmm. having trouble on a simple refactor in ASM : if I replace "r12q" by "rfilterq", I have an "invalid combination of opcode and operands" error. does this ring a bell to anybody ?
[13:24] <plepere> and this error comes on mov and sub instructions. :/
[14:08] <cone-884> ffmpeg.git 03Anton Khirnov 07master:e1f2987b1011: FATE: add tests for the shuffleplanes filter
[14:08] <cone-884> ffmpeg.git 03Michael Niedermayer 07master:7011aab5018a: Merge commit 'e1f2987b10112489f6da5501d4c8735a798c9e3f'
[15:00] <cone-884> ffmpeg.git 03Diego Biurrun 07master:3bfdee00cd92: x86: dcadsp: Fix linking with yasm and optimizations disabled
[15:00] <cone-884> ffmpeg.git 03Michael Niedermayer 07master:2d99de66b7f1: Merge commit '3bfdee00cd92ff07c364d4901c4aefda32780756'
[15:18] <cone-884> ffmpeg.git 03Anton Khirnov 07master:713d3f98c8b0: vf_shuffleplanes: fix the type of the mapping indices
[15:18] <cone-884> ffmpeg.git 03Michael Niedermayer 07master:d168729004a9: Merge remote-tracking branch 'qatar/master'
[15:20] <j-b> 1m
[15:20] <j-b> oops
[16:00] <plepere> BBB : should I expand all the macros in the functions ?
[16:05] <BBB> plepere: for what?
[16:05] <BBB> I don't think so, just take 1-2 functions and disassemble the result and see if that's what you think it should be (regardless of the macros) - i.e. "can I make this faster"
[16:05] <plepere> I see
[16:06] <BBB> macros should do no more than make your life (and thus the final binary) better
[16:06] <BBB> I just want to make sure the macros you're using indeed serve that purpose, think of it as a socratic experiment, nothing more
[16:07] <plepere> a socratic experiment ?
[16:08] <plepere> oh and while I'm talking to you : I can't do the pmullw that you're suggesting. I need to do a pmulhw +pmullw + unpack to full 32bit + pack back to 16bit.
[16:10] <plepere> basically, I can't stop at pmullw.
[16:40] <plepere> ok, I've sent my patch. Again.
[16:42] <plepere> BBB : I know that the fullpel isn't good for you as it is, but that's how it's done in openHEVC, and I'd rather validate things here, merge the ASM back into OpenHEVC and then do the weighting (or qpel_hv, but it will be tricky)
[16:51] <ubitux> plepere: please remove all those "//////////"
[17:07] <cone-884> ffmpeg.git 03James Almer 07master:99b4da73c8fd: lavd/Makefile: Add fbdev_common.h to SKIPHEADERS
[17:07] <cone-884> ffmpeg.git 03Michael Niedermayer 07master:ffe7e7c195c3: avfilter/vf_shuffleplanes: Fix flags / add AV_OPT_FLAG_FILTERING_PARAM
[17:20] <cone-884> ffmpeg.git 03sfan5 07master:69ead9af7519: libx265: Use ctx->vui. instead of ctx-> for some options A recent change in libx265 moved some options such as sar_width into a 'vui' struct.
[19:15] <BBB> plepere: wait why 32bit?
[19:15] <BBB> plepere: for 8bit, which part requires 32bit?
[19:17] <BBB> and I'll review patch "soon", hopefully finish this weekend
[20:01] <Zeranoe> Any comments on the downmix/LFE loss topic: http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=17&t=1851
[20:03] <llogan> i don't see an actual question in that thread
[20:05] <Zeranoe> llogan: I think hes suggesting to make -ac 2 automatically downmix with those options
[20:07] <llogan> submitting a patch would be the best way for comments
[20:36] <cone-884> ffmpeg.git 03James Almer 07master:9e0e1f906743: x86/dsputil: add emms to ff_scalarproduct_int16_mmxext()
[20:59] <burek> I guess you've all heard about this, but it's nice to hear it again :) http://letterboxd.com/blots/film/the-fifth-estate/
[20:59] <burek> Favourite line: “We can use FFmpeg and throw it into Final Cut.”
[20:59] <burek> :)
[21:01] <burek> oh.. this "news" is 2 months old :/ https://twitter.com/FFmpeg/status/422566363467505664
[21:02] <burek> anyway +beer :)
[21:41] <ubitux> "dict: K&R cosmetic refactoring"
[21:41] <ubitux> lol
[21:42] <kierank> where did all these cosmetic people come from
[21:42] <kierank> i've seen 2 in the last few days
[21:42] <ubitux> i don't know :')
[21:46] <llogan> "maybe they were born with it. maybe it's maybeline."
[21:46] <wm4> maybe someone is trolling diego?
[21:47] <wm4> it's the only logical explanation I can come up with
[21:49] <ubitux> well, they have 3 guys full time on cosmetics, it seems they're going to have 2 new guys
[21:49] <ubitux> ready for http://cdn.memegenerator.net/instances/500x/46616414.jpg @_@
[21:49] <ubitux> michaelni: i started checking the hashes & stuff, 'will confirm the APIChanges tonight
[21:50] <kierank> ubitux: 3 guys?
[21:51] <ubitux> diego/luca/koda
[21:51] <kierank> ah koda
[21:54] <llogan> the term is "beautician"
[21:54] <llogan> One skilled in giving cosmetic treatments.
[21:55] <wm4> ubitux: koda seems to make functional cleanups, though
[21:55] <ubitux> lol
[21:55] <cone-884> ffmpeg.git 03Andreas Cadhalpun 07master:64b6164b721c: Correct the FSF address for two avisynth files to '51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA'
[21:55] <cone-884> ffmpeg.git 03Andreas Cadhalpun 07master:eeb3baf7f725: Fix spelling error 'Inconsistant -> Inconsistent'
[21:55] <cone-884> ffmpeg.git 03Andreas Cadhalpun 07master:9898bd9a82ad: Fix spelling errors in texi files: accomodate -> accommodate allows to -> allows one to choosen -> chosen compability -> compatibility explictly -> explicitly overriden -> overridden specifed -> specified Trasmission -> Transmission
[21:56] <wm4> ubitux: and only diego apparently does nothing but cosmetics
[21:56] <ubitux> if you want to be honest, he does some stuff to the build system sometimes
[22:04] <cone-884> ffmpeg.git 03Diego Biurrun 07master:84bf88172061: configure: Split x86 SIMD architecture extensions into separate list
[22:04] <cone-884> ffmpeg.git 03Michael Niedermayer 07master:85d2b0987bae: Merge commit '84bf8817206126dab3c9abf6055b593389bcb241'
[22:12] <cone-884> ffmpeg.git 03Diego Biurrun 07master:d48430c36794: build: Let the SVQ3 decoder depend on the H.264 decoder
[22:12] <cone-884> ffmpeg.git 03Michael Niedermayer 07master:1618f162a9da: Merge commit 'd48430c367947a64647c6959cf472f2c01778b17'
[22:28] <cone-884> ffmpeg.git 03Matthieu Bouron 07master:e118bb1a3388: mxf: Introduce ff_mxf_get_samples_per_frame
[22:28] <cone-884> ffmpeg.git 03Michael Niedermayer 07master:2265212396c1: Merge commit 'e118bb1a33889d4df56f28975b4fd0793b4f5c32'
[22:31] <michaelni> nevcairiel, ok if i apply the 2 dxva2_h264 patches or should i wait ?
[22:31] <michaelni> you are the author of the patches
[22:32] <JEEBsv> t
[22:57] <cone-884> ffmpeg.git 03Matthieu Bouron 07master:5b930092c3af: mxf: Set audio packets pts
[22:57] <cone-884> ffmpeg.git 03Michael Niedermayer 07master:3ce858141309: Merge commit '5b930092c3afd2ae01f1c8aa7fb405911d6ad416'
[23:14] <cone-884> ffmpeg.git 03Matthieu Bouron 07master:570af382eea9: mxf: Handle identification metadata
[23:14] <cone-884> ffmpeg.git 03Michael Niedermayer 07master:5a4852bc4d64: Merge commit '570af382eea902afe09f3562e5e1b483981cca7e'
[23:33] <nevcairiel> michaelni: if noone complains that old GPUs suddenly fail at decoding unless the calling app sets the workaround. IMHO the benefit of newer GPUs starting to work is bigger
[23:39] <Compn> nevcairiel : what old cards fail ?
[23:40] <nevcairiel> any intel GPUs before Sandy Bridge, and possibly Sandy Bridge GPUs if the calling application is a bit stupid :)
[23:40] <Compn> as long as vlc has the workaround , said patches are ok to me :P
[23:40] <Compn> only intel gpu then? not nvidia or ati stuff ?
[23:40] <nevcairiel> (since SNB supports both way)
[23:40] <nevcairiel> no, only intel
[23:40] <Compn> oh, yes then i'd say apply
[23:40] <nevcairiel> the work around is like two lines, one if and one assignment
[23:41] <Compn> scared me i thought you wanted to break nvidia :P
[23:41] <Compn> ehe
[23:50] <cone-884> ffmpeg.git 03Paul B Mahol 07master:f06f6daaf853: mxf: Parse random index pack
[23:50] <cone-884> ffmpeg.git 03Michael Niedermayer 07master:618d2262d71e: Merge commit 'f06f6daaf8538eb8ceeb690b761f1256771b6ba6'
[00:00] --- Fri Mar  7 2014


More information about the Ffmpeg-devel-irc mailing list