Recherche avancée

Médias (1)

Mot : - Tags -/belgique

Autres articles (66)

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

  • HTML5 audio and video support

    13 avril 2011, par

    MediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
    The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
    For older browsers the Flowplayer flash fallback is used.
    MediaSPIP allows for media playback on major mobile platforms with the above (...)

  • Support audio et vidéo HTML5

    10 avril 2011

    MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
    Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
    Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
    Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...)

Sur d’autres sites (7093)

  • avcodec_decode_video2 fails to decode after frame resolution change

    10 avril 2021, par Krzysztof Kansy

    I'm using ffmpeg in Android project via JNI to decode real-time H264 video stream. On the Java side I'm only sending the the byte arrays into native module. Native code is running a loop and checking data buffers for new data to decode. Each data chunk is processed with :

    



    int bytesLeft = data->GetSize();
int paserLength = 0;
int decodeDataLength = 0;
int gotPicture = 0;
const uint8_t* buffer = data->GetData();
while (bytesLeft > 0) {
    AVPacket packet;
    av_init_packet(&packet);
    paserLength = av_parser_parse2(_codecPaser, _codecCtx, &packet.data, &packet.size, buffer, bytesLeft, AV_NOPTS_VALUE, AV_NOPTS_VALUE, AV_NOPTS_VALUE);
    bytesLeft -= paserLength;
    buffer += paserLength;

    if (packet.size > 0) {
        decodeDataLength = avcodec_decode_video2(_codecCtx, _frame, &gotPicture, &packet);
    }
    else {
        break;
    }
    av_free_packet(&packet);
}

if (gotPicture) {
// pass the frame to rendering
}


    



    The system works pretty well until incoming video's resolution changes. I need to handle transition between 4:3 and 16:9 aspect ratios. While having AVCodecContext configured as follows :

    



    _codecCtx->flags2|=CODEC_FLAG2_FAST;
_codecCtx->thread_count = 2;
_codecCtx->thread_type = FF_THREAD_FRAME;

if(_codec->capabilities&CODEC_FLAG_LOW_DELAY){
    _codecCtx->flags|=CODEC_FLAG_LOW_DELAY;
}


    



    I wasn't able to continue decoding new frames after video resolution change. The got_picture_ptr flag that avcodec_decode_video2 enables when whole frame is available was never true after that.
    
This ticket made me wonder if the issue isn't connected with multithreading. Only useful thing I've noticed is that when I change thread_type to FF_THREAD_SLICE the decoder is not always blocked after resolution change, about half of my attempts were successfull. Switching to single-threaded processing is not possible, I need more computing power. Setting up the context to one thread does not solve the problem and makes the decoder not keeping up with processing incoming data.
    
Everything work well after app restart.

    



    I can only think of one workoround (it doesn't really solve the problem) : unloading and loading the whole library after stream resolution change (e.g as mentioned in here). I don't think it's good tho, it will propably introduce other bugs and take a lot of time (from user's viewpoint).

    



    Is it possible to fix this issue ?

    



    EDIT :
    
I've dumped the stream data that is passed to decoding pipeline. I've changed the resolution few times while stream was being captured. Playing it with ffplay showed that in moment when resolution changed and preview in application froze, ffplay managed to continue, but preview is glitchy for a second or so. You can see full ffplay log here. In this case video preview stopped when I changed resolution to 960x720 for the second time. (Reinit context to 960x720, pix_fmt: yuv420p in log).

    


  • Running a py script in the Cloud

    12 janvier 2018, par Anay Bose

    I’m new to Google’s cloud & Virtual Machine(VM) instances, and I need some clarifications on a couple of points. I have a python script ; it imports a long range of functions. I need to run those functions in parallel. I’m using multiprocessing and Process, not threads. These functions are basically image and media processors, and they use many other tools like FFMPEG, imagemagick and Avisynth in addition to a wide range of python modules, including moviepy. Now, I would like to run some 50 functions in parallel assigning a CPU for each process. Images, media and avi files are stored in seperate folders. I’m on Windows7 Core-i7 machine. So, need cloud computing power.

    Now, my question can I run such a python script/app in the cloud that requires a very complicated file system and non-python tools i.e. ffmpeg, avisynth and avi files ?

    Can Google VMs emulate my local machine and empower me with more cores and memory to run such a program ? if not, then what are my options ? Is their any tutorials that I can follow ? I need your suggestions. I have given below an example script and some codes to help facilitate your understanding about my situation.

    from __future__ import unicode_literals
    import youtube_dl
    import os
    import time
    import sys
    reload(sys)  
    sys.setdefaultencoding('utf-8')
    from multiprocessing import Process
    from utils import *

    from clip31 import VIDEO31
    from clip32 import VIDEO32
    from clip189 import VIDEO189
    from clip16 import VIDEO16
    from clip39 import VIDEO39


    if __name__== '__main__':

       # 1. CALLING A FUNCTION
       folder = "bodyforce3\\16"
       serial = "16"
       images = get_filepaths("../16")
       videos = get_filepaths("12__media")
       pngs = get_filepaths("../pngs")

       Process(target=VIDEO192, args=(folder, serial, color1, color2, color3, images, videos)).start()


       # 2. CALLING A FUNCTION
       folder = "bodyforce3\\20"
       serial = "20"
       images = get_filepaths("../20")
       videos = get_filepaths("18__media")

       Process(target=VIDEO32, args=(folder, serial, color1, color2, color3, images, videos)).start()


       # 3. CALLING A FUNCTION
       folder = "bodyforce3\\14"
       serial = "14"
       images = get_filepaths("../14")
       videos = get_filepaths("16__media")

       Process(target=VIDEO91, args=(folder, serial, color1, color2, color3, images, videos)).start()

    I copy avi files in functions like this :

    src = "clip50_files"
    src_files = os.listdir(src)
    for file_name in src_files:
       full_file_name = os.path.join(src, file_name)
       if (os.path.isfile(full_file_name)):
           shutil.copy(full_file_name, folder)

    I call ffmpeg commands like this, and they are included within py functions.

    ###########################
    #### FFMPEG OPERATIONS ####
    ###########################

    print "Starting FFMPEG operations ..."

    if os.path.isfile(os.path.join(folder, "bounce-(3).avi")):
       os.remove(os.path.join(folder, "bounce-(3).avi"))


    infile = folder + "/bounce-(3).avs"
    outfile = folder + "/bounce-(3).avi"
    codec = "rawvideo"
    pix_fmt = "bgra"

    try:
       subprocess.call(["ffmpeg",
                        "-i" ,infile,
                        "-c:v" ,codec,
                        "-pix_fmt", pix_fmt,
                        outfile],
                       stdout=open(os.devnull, 'w'),
                       stderr=subprocess.STDOUT)
    except subprocess.CalledProcessError as e:  
       #except subprocess.CalledProcessError as e:
       sys.exit(e.output)
    except OSError as e:
       sys.exit(e.strerror)


    print "FFMPEG operations ended"
  • 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