Recherche avancée

Médias (1)

Mot : - Tags -/berlin

Autres articles (65)

  • Demande de création d’un canal

    12 mars 2010, par

    En fonction de la configuration de la plateforme, l’utilisateur peu avoir à sa disposition deux méthodes différentes de demande de création de canal. La première est au moment de son inscription, la seconde, après son inscription en remplissant un formulaire de demande.
    Les deux manières demandent les mêmes choses fonctionnent à peu près de la même manière, le futur utilisateur doit remplir une série de champ de formulaire permettant tout d’abord aux administrateurs d’avoir des informations quant à (...)

  • Multilang : améliorer l’interface pour les blocs multilingues

    18 février 2011, par

    Multilang est un plugin supplémentaire qui n’est pas activé par défaut lors de l’initialisation de MediaSPIP.
    Après son activation, une préconfiguration est mise en place automatiquement par MediaSPIP init permettant à la nouvelle fonctionnalité d’être automatiquement opérationnelle. Il n’est donc pas obligatoire de passer par une étape de configuration pour cela.

  • Contribute to a better visual interface

    13 avril 2011

    MediaSPIP is based on a system of themes and templates. Templates define the placement of information on the page, and can be adapted to a wide range of uses. Themes define the overall graphic appearance of the site.
    Anyone can submit a new graphic theme or template and make it available to the MediaSPIP community.

Sur d’autres sites (7125)

  • Encoding of two full hd streams in Linux + GPU with Intel HD4000 / VA API / FFMPEG / OpenGL

    30 juin 2016, par qknight

    i want to encode/stream two full hd streams in realtime from my laptop to a remote location using linux/xorg on the host.

    VA API

    for this i’ve been playing with the VA API but the performance is pretty bad with 5.59 fps (see paste below).

    FFMPEG

    using ffmpeg with CPU encoding i get about 200 fps but then all cores of my Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz are busy and the fan turns on.

    future plans

    i want GPU support in encoding and later integrate this into a program which streams a virtual xorg ’screen’, see https://lastlog.de/wiki/index.php/Raspberry_PI_virtual_screen for more details on my plans.

    maybe h264 isn’t even what i want ? so if someone advices towards a different implementation, i’d welcome that.

    besides VA API there seems to be QuickSync but i didn’t experiment with that yet as it is not packaged on NixOS just yet.

    note : i need a library to have a smooth integration into the code.

    h264encode -w 1920 -h 1080 —profile MPSource frame is 1920x1080 and will code clip to 1920x1088 with crop

    INPUT:Try to encode H264...
    
INPUT : Resolution : 1920x1080, 60 frames
    
INPUT : FrameRate : 30
    
INPUT : Bitrate : 14929920
    
INPUT : Slieces : 1
    
INPUT : IntraPeriod : 30
    
INPUT : IDRPeriod : 60
    
INPUT : IpPeriod : 1
    
INPUT : Initial QP : 26
    
INPUT : Min QP : 0
    
INPUT : Source YUV : AUTO generated
    
INPUT : Coded Clip : /tmp/test.264
    
INPUT : Rec   Clip : Not save reconstructed frame
    

    libva info : VA-API version 0.38.1
    
libva info : va_getDriverName() returns 0
    
libva info : Trying to open /run/opengl-driver/lib/dri/i965_drv_video.so
    
libva info : Found init function __vaDriverInit_0_38
    
libva info : va_openDriver() returns 0
    
Use profile VAProfileH264Main
    
Support rate control mode (0x12):CBR CQP 
    
RateControl mode : CQP
    
Support VAConfigAttribEncPackedHeaders
    
Support packed sequence headers
    
Support packed picture headers
    
Support packed slice headers
    
Support packed misc headers
    
Support 1 RefPicList0 and 1 RefPicList1
    
Loading data into surface 15.....Complete surface loading
    
      \00000059(054456 bytes coded)
    

    PERFORMANCE :   Frame Rate : 5.59 fps (60 frames, 10730 ms (178.83 ms per frame))
    
PERFORMANCE :   Compression ratio : 51:1
    
PERFORMANCE :     UploadPicture : 10467 ms (174.45, 97.55% percent)
    
PERFORMANCE :     vaBeginPicture : 0 ms (0.00, 0.00% percent)
    
PERFORMANCE :     vaRenderHeader : 1 ms (0.02, 0.01% percent)
    
PERFORMANCE :     vaEndPicture : 42 ms (0.70, 0.39% percent)
    
PERFORMANCE :     vaSyncSurface : 244 ms (4.07, 2.27% percent)
    
PERFORMANCE :     SavePicture : 7 ms (0.12, 0.07% percent)
    
PERFORMANCE :     Others : -31 ms (71582787.75, 40027653.91% percent)
    
(Multithread enabled, the timing is only for reference)

    i’ve seen https://www.reddit.com/r/linux/comments/1qk1yu/is_there_currently_opensource_software_to_encode/ though but i’m not sure what do do with it.

  • Cortex-A7 instruction cycle timings

    15 mai 2014, par Mans — ARM

    The Cortex-A7 ARM core is a popular choice in low-power and low-cost designs. Unfortunately, the public TRM does not include instruction timing information. It does reveal that execution is in-order which makes measuring the throughput and latency for individual instructions relatively straight-forward.

    The table below lists the measured issue cycles (inverse throughput) and result latency of some commonly used instructions.

    It should be noted that in some cases, the perceived latency depends on the instruction consuming the result. Most of the values were measured with the result used as input to the same instruction. For instructions with multiple outputs, the latencies of the result registers may also differ.

    Finally, although instruction issue is in-order, completion is out of order, allowing independent instructions to issue and complete unimpeded while a multi-cycle instruction is executing in another unit. For example, a 3-cycle MUL instruction does not block ADD instructions following it in program order.

    ALU instructions Issue cycles Result latency
    MOV Rd, Rm 1/2 1
    ADD Rd, Rn, #imm 1/2 1
    ADD Rd, Rn, Rm 1 1
    ADD Rd, Rn, Rm, LSL #imm 1 1
    ADD Rd, Rn, Rm, LSL Rs 1 1
    LSL Rd, Rn, #imm 1 2
    LSL Rd, Rn, Rs 1 2
    QADD Rd, Rn, Rm 1 2
    QADD8 Rd, Rn, Rm 1 2
    QADD16 Rd, Rn, Rm 1 2
    CLZ Rd, Rm 1 1
    RBIT Rd, Rm 1 2
    REV Rd, Rm 1 2
    SBFX Rd, Rn 1 2
    BFC Rd, #lsb, #width 1 2
    BFI Rd, Rn, #lsb, #width 1 2
    NOTE : Shifted operands and shift amounts needed one cycle early.
    Multiply instructions Issue cycles Result latency
    MUL Rd, Rn, Rm 1 3
    MLA Rd, Rn, Rm, Ra 1 31
    SMULL Rd, RdHi, Rn, Rm 1 3
    SMLAL Rd, RdHi, Rn, Rm 1 31
    SMMUL Rd, Rn, Rm 1 3
    SMMLA Rd, Rn, Rm, Ra 1 31
    SMULBB Rd, Rn, Rm 1 3
    SMLABB Rd, Rn, Rm, Ra 1 31
    SMULWB Rd, Rn, Rm 1 3
    SMLAWB Rd, Rn, Rm, Ra 1 31
    SMUAD Rd, Rn, Rm 1 3
    1 Accumulator forwarding allows back to back MLA instructions without delay.
    Divide instructions Issue cycles Result latency
    SDIV Rd, Rn, Rm 4-20 6-22
    UDIV Rd, Rn, Rm 3-19 5-21
    Load/store instructions Issue cycles Result latency
    LDR Rt, [Rn] 1 3
    LDR Rt, [Rn, #imm] 1 3
    LDR Rt, [Rn, Rm] 1 3
    LDR Rt, [Rn, Rm, lsl #imm] 1 3
    LDRD Rt, Rt2, [Rn] 1 3-4
    LDM Rn, regs 1-8 3-10
    STR Rt, [Rn] 1 2
    STRD Rt, Rt2, [Rn] 1 2
    STM Rn, regs 1-10 2-12
    NOTE : Load results are forwarded to dependent stores without delay.
    VFP instructions Issue cycles Result latency
    VMOV.F32 Sd, Sm 1 4
    VMOV.F64 Dd, Dm 1 4
    VNEG.F32 Sd, Sm 1 4
    VNEG.F64 Dd, Dm 1 4
    VABS.F32 Sd, Sm 1 4
    VABS.F64 Dd, Dm 1 4
    VADD.F32 Sd, Sn, Sm 1 4
    VADD.F64 Dd, Dn, Dm 1 4
    VMUL.F32 Sd, Sn, Sm 1 4
    VMUL.F64 Dd, Dn, Dm 4 7
    VMLA.F32 Sd, Sn, Sm 1 81
    VMLA.F64 Dd, Dn, Dm 4 112
    VFMA.F32 Sd, Sn, Sm 1 81
    VFMA.F64 Dd, Dn, Dm 5 82
    VDIV.F32 Sd, Sn, Sm 15 18
    VDIV.F64 Dd, Dn, Dm 29 32
    VSQRT.F32 Sd, Sm 14 17
    VSQRT.F64 Dd, Dm 28 31
    VCVT.F32.F64 Sd, Dm 1 4
    VCVT.F64.F32 Dd, Sm 1 4
    VCVT.F32.S32 Sd, Sm 1 4
    VCVT.F64.S32 Dd, Sm 1 4
    VCVT.S32.F32 Sd, Sm 1 4
    VCVT.S32.F64 Sd, Dm 1 4
    VCVT.F32.S32 Sd, Sd, #fbits 1 4
    VCVT.F64.S32 Dd, Dd, #fbits 1 4
    VCVT.S32.F32 Sd, Sd, #fbits 1 4
    VCVT.S32.F64 Dd, Dd, #fbits 1 4
    1 5 cycles with dependency only on accumulator.
    2 8 cycles with dependency only on accumulator.
    NEON integer instructions Issue cycles Result latency
    VADD.I8 Dd, Dn, Dm 1 4
    VADDL.S8 Qd, Dn, Dm 2 4
    VADD.I8 Qd, Qn, Qm 2 4
    VMUL.I8 Dd, Dn, Dm 2 4
    VMULL.S8 Qd, Dn, Dm 2 4
    VMUL.I8 Qd, Qn, Qm 4 4
    VMLA.I8 Dd, Dn, Dm 2 4
    VMLAL.S8 Qd, Dn, Dm 2 4
    VMLA.I8 Qd, Qn, Qm 4 4
    VADD.I16 Dd, Dn, Dm 1 4
    VADDL.S16 Qd, Dn, Dm 2 4
    VADD.I16 Qd, Qn, Qm 2 4
    VMUL.I16 Dd, Dn, Dm 1 4
    VMULL.S16 Qd, Dn, Dm 2 4
    VMUL.I16 Qd, Qn, Qm 2 4
    VMLA.I16 Dd, Dn, Dm 1 4
    VMLAL.S16 Qd, Dn, Dm 2 4
    VMLA.I16 Qd, Qn, Qm 2 4
    VADD.I32 Dd, Dn, Dm 1 4
    VADDL.S32 Qd, Dn, Dm 2 4
    VADD.I32 Qd, Qn, Qm 2 4
    VMUL.I32 Dd, Dn, Dm 2 4
    VMULL.S32 Qd, Dn, Dm 2 4
    VMUL.I32 Qd, Qn, Qm 4 4
    VMLA.I32 Dd, Dn, Dm 2 4
    VMLAL.S32 Qd, Dn, Dm 2 4
    VMLA.I32 Qd, Qn, Qm 4 4
    NEON floating-point instructions Issue cycles Result latency
    VADD.F32 Dd, Dn, Dm 2 4
    VADD.F32 Qd, Qn, Qm 4 4
    VMUL.F32 Dd, Dn, Dm 2 4
    VMUL.F32 Qd, Qn, Qm 4 4
    VMLA.F32 Dd, Dn, Dm 2 81
    VMLA.F32 Qd, Qn, Qm 4 81
    1 5 cycles with dependency only on accumulator.
    NEON permute instructions Issue cycles Result latency
    VEXT.n Dd, Dn, Dm, #imm 1 4
    VEXT.n Qd, Qn, Qm, #imm 2 5
    VTRN.n Dd, Dn, Dm 2 5
    VTRN.n Qd, Qn, Qm 4 5
    VUZP.n Dd, Dn, Dm 2 5
    VUZP.n Qd, Qn, Qm 4 6
    VZIP.n Dd, Dn, Dm 2 5
    VZIP.n Qd, Qn, Qm 4 6
    VTBL.8 Dd, Dn, Dm 1 4
    VTBL.8 Dd, Dn-Dn+1, Dm 1 4
    VTBL.8 Dd, Dn-Dn+2, Dm 2 5
    VTBL.8 Dd, Dn-Dn+3, Dm 2 5

  • arm64 : Fix wrong BTI landing pad

    25 avril 2022, par Andre Kempe
    arm64 : Fix wrong BTI landing pad

    This patch fixes a wrong type of BTI landing pad when branching to
    
functions instantiated via the fft*_neon macro.
    

    Although the previously employed paciasp instruction serves as a landing
    
pad, for the ways that this function is invoked it is the wrong type, resulting
    
in an unexpected termination of the running process.
    

    Signed-off-by : André Kempe <andre.kempe@arm.com>
    
Signed-off-by : Martin Storsjö <martin@martin.st>
    • [DH] libavcodec/aarch64/fft_neon.S

Navigation