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

[burek]

[00:32] <cone-888> ffmpeg.git 03Christophe Gisquet 07master:9dc45d1f4280: x86: lavc: share more constants
[04:16] <cone-246> ffmpeg.git 03Michael Niedermayer 07master:f906982c9411: avcodec/h264_slice: Do not change frame_num after the first slice
[04:16] <cone-246> ffmpeg.git 03Michael Niedermayer 07master:f111831ed611: avcodec/h264_slice: Check picture structure before setting the related fields
[04:16] <cone-246> ffmpeg.git 03Michael Niedermayer 07master:38d5241b7f36: avcodec/h264_slice: ignore SAR changes in slices after the first
[04:16] <cone-246> ffmpeg.git 03Michael Niedermayer 07master:2fd9ce92af43: avcodec/h264_slice: assert that reinit does not occur after the first slice
[05:20] <cone-246> ffmpeg.git 03Alex Converse 07master:9295d10ea9d1: fate: Add a test for AAC ELD480.
[05:20] <cone-246> ffmpeg.git 03Michael Niedermayer 07master:a40de9ac07fc: Merge commit '9295d10ea9d138462b7f67d16bf95ae9ca76aca6'
[06:01] <cone-246> ffmpeg.git 03Anshul Maheshwari 07master:bf30161a8db1: avcodec/ccaption_dec: Added Roll up functionality
[06:01] <cone-246> ffmpeg.git 03Anshul Maheshwari 07master:5647286e6778: avcodec/ccaption_dec: handle error from ass_sub api
[06:28] <cone-246> ffmpeg.git 03Anshul Maheshwari 07master:f05efd42af37: avcodec/ccaption_dec: Added Debug logs
[13:32] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:c02b8c452786: avutil/pixfmt: Clarify the meaning of the alpha byte in RGB0 and similar formats
[13:32] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:088dd0fd4c8b: avutil/pixfmt: Clarify the meaning of the "alpha" bit in rgb555/bgr555
[13:32] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:dbab5f59849a: avutil/pixfmt: Clarify the meaning of the alpha bits in rgb444 and similar formats
[13:35] <wm4> michaelni: the RGB555 ones still say "most significant bit to 0", is that intended?
[14:06] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:be1cb1e63ae9: avutil/pixfmt: Clarify meaning of the A/X bit in RGB555 / remove wording about significant bit
[15:13] <cone-53> ffmpeg.git 03Timothy Gu 07master:1de742145f58: pixdesc: Include more functions in FF_DISABLE_DEPRECATION_WARNINGS
[15:35] <cone-53> ffmpeg.git 03Christophe Gisquet 07master:46e2afa4dcb5: wmalossless: reset lms_update
[15:35] <cone-53> ffmpeg.git 03Christophe Gisquet 07master:691b7f5e9e29: lavc/lossless_audiodsp: revert various commits
[16:19] <cone-53> ffmpeg.git 03Paul B Mahol 07master:ec8ec999f4a3: avcodec/twinvqdec: use init_get_bits8()
[16:24] <cone-53> ffmpeg.git 03Carl Eugen Hoyos 07master:ac923ed47002: lavf/mlv: Only add streams that are supposed to contain frames.
[17:54] <cone-53> ffmpeg.git 03Christophe Gisquet 07master:ed450d4acfc9: x86: lavc: share more constant through defines
[18:12] <cone-53> ffmpeg.git 03Christophe Gisquet 07master:97996eff4f26: hevc/sao: do in-place band filtering when possible
[18:36] <cone-53> ffmpeg.git 03Paul B Mahol 07master:134e8c73eaaf: avcodec/faxcompr: use init_get_bits8()
[19:31] <michaelni> kurosu, did you see: http://article.gmane.org/gmane.comp.video.ffmpeg.cvs/86347 ?
[19:34] <kurosu> no I hadn't
[19:35] <kurosu> I would expect a crash if 1) somehow there was an incorrect alignment 2) the buffers were large enough
[19:35] <kurosu> for 1), the check "if (((intptr_t)dst | (intptr_t)src | stride_dst | stride_src) & 15)" would seem sufficient
[19:35] <kurosu> but maybe setting it to "if (1)" would help if that's the issue
[19:36] <kurosu> for 2), dst should be large enough as it is the edge_emu buffer
[19:37] <kurosu> unless icc decides to rearrange the buffers?
[19:37] <kurosu> src should be the image, which would crash if not properly aligned, but it's weird
[19:41] <michaelni> kurosu, carl posted gdb output in http://thread.gmane.org/gmane.comp.video.ffmpeg.cvs/86168/focus=86347
[19:41] <kurosu> at worst the patch can be reverted
[19:41] <kurosu> oh ok
[19:44] <kurosu> huh, why does it generate movdqa/u for AV_COPY64 whose code clearly uses movq
[19:44] <kurosu> over-eager optimization by icc?
[19:50] <nevcairiel> icc is evil like that sometimes, personally i would just call it broken and move on, but some people are more stubborn like that
[19:51] <michaelni> maybe it generates that from the C code and not the asm, is the asm used for icc ?
[19:55] <kurosu> well yeah, but is that code so evil that it decides to just miscompiles that one ? I would expect several such places to fail
[20:02] <michaelni> i dont understand why icc is doing that but shouldnt it be AV_COPY64U() ?
[20:11] <kurosu> does it change anything for x86 to push icc into generating this? but yes
[20:11] <jamrial> that can't be the simd version of AV_COPY64() from x86/intredwrite.h
[20:11] <jamrial> x86_64 enables HAVE_FAST_64BIT
[20:11] <jamrial> and that implementation is under a "#if !HAVE_FAST_64BIT && defined(__MMX__)" check
[20:11] <jamrial> it must be icc optimizing the c version
[20:12] <kurosu> what platform distinguishes unaligned and aligned 64bits copies
[20:12] <kurosu> bbl
[20:52] <cone-53> ffmpeg.git 03Christophe Gisquet 07master:626d6184ce74: x86: lavc/hevc_mc: fix comments
[21:00] <cone-53> ffmpeg.git 03Hendrik Leppkes 07master:8029af586fd5: dxva2_hevc: properly fill the scaling list structure
[21:00] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:89c7332b3825: Merge commit '8029af586fd5a5f2a0803001f9eff386e5545fe2'
[21:07] <cone-53> ffmpeg.git 03Luca Barbato 07master:e352520e3ed7: oma: Report a timestamp
[21:07] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:7474ea74952b: Merge commit 'e352520e3ed7f08f19e63cd60e95da6bb6f037c1'
[21:38] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:7c2fa13df9a6: avformat/omadec: only compute timestamps based on bitrate if its set
[21:38] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:29fd3032cc96: avformat/omadec: Subtract headersize in timestamp calculation
[00:00] --- Sun Feb  8 2015