Recherche avancée

Sur d’autres sites (4754)

• Decoding the h.264 stream from a serial port

  18 mars, par Peter

  I would like to know if there is a reliable way to decode an H.264 NAL stream coming through a serial port using software.

  


  So far, I have managed to decode a single frame using a python script. In this script, I first write the incoming data to a file, and when the end-of-frame marker 00_00_00_01 appears, I display the frame using ffplay.

  


  import serial
import subprocess
import os
import time

ser = serial.Serial('COM3', 115200, timeout=1)
output_file = "output.264"

# Variable to store the ffplay process
ffplay_process = None

# Open the file for writing in binary mode
with open(output_file, "wb") as file:

    print("Writing bytes to output.264. Waiting for the end-of-frame marker 0x00000001.")

    buffer = bytearray()
    marker = b'\x00\x00\x00\x01'

    try:
        while True:
            if ser.in_waiting:  # If there is data in the buffer
                data = ser.read(ser.in_waiting)  # Read all available bytes
                buffer.extend(data)

                # Check if the end-of-frame marker is in the buffer
                while marker in buffer:
                    index = buffer.index(marker) + len(marker)  # Position after the marker
                    frame = buffer[:index]  # Extract the frame
                    buffer = buffer[index:]  # Keep the remaining data

                    print(f"Frame recorded: {len(frame)} bytes")
                    file.write(frame)  # Write the frame to the file
                    file.flush()  # Force writing to disk

                    # Close the ffplay window if it is already open
                    if ffplay_process and ffplay_process.poll() is None:
                        ffplay_process.terminate()
                        ffplay_process.wait()  # Wait for the process to terminate

                    # Play the recorded frame, reopening the window
                    ffplay_process = subprocess.Popen(["ffplay", "-f", "h264", "-i", output_file])

    except KeyboardInterrupt:
        print("\nRecording stopped.")
    finally:
        # Close the serial port and the ffplay process
        ser.close()


  


  However, each time a new end-of-frame marker is detected, the ffplay window closes and reopens to show the next frame. It will flicker when transferring the video. Is there a way to display the frames in the same window for seamless playback when streaming video ?

  


  Or is there a better approach or software that is more suited for this task ? I do not know where to start, so I will be glad for any hints.

  


• vulkan : use a single command buffer per command buffer pool

  16 avril, par Lynne

  vulkan : use a single command buffer per command buffer pool
  We violated the spec, which, despite the actual command buffer pool
  
  *not* being involved in any functions which require external synchronization
  
  of the pool, *require* external synchronization even if only the
  
  command buffers are used.
  This also has the effect of *significantly* speeding up execution
  
  in case command buffers are contended.
  

  • [DH] libavutil/hwcontext_vulkan.c
  • [DH] libavutil/vulkan.c
  • [DH] libavutil/vulkan.h

• vulkan_decode : use a single execution pool

  3 décembre 2024, par Lynne

  vulkan_decode : use a single execution pool
  Originally, the decoder had a single execution pool, with one
  
  execution context per thread. Execution pools were always intended
  
  to be thread-safe, as long as there were enough execution contexts
  
  in the pool to satisfy all threads.
  Due to synchronization issues, the threading part was removed at some
  
  point, and, for decoding, each thread had its own execution pool.
  
  Having a single execution pool per context is hacky, not to mention
  
  wasteful.
  
  Most importantly, we *cannot* associate single shaders across multiple
  
  execution pools for a single application. This means that we cannot
  
  use shaders to either apply film grain, or use this framework for
  
  software-defined decoders.
  The recent commits added threading capabilities back to the execution
  
  pool, and the number of contexts in each pool was increased. This was
  
  done with the assumption that the execution pool was singular, which
  
  it was not. This led to increased parallelism and number of frames
  
  in flight, which is taxing on memory.
  This commit finally restores proper threading behaviour.
  
  The validation layer has isses that are reported and addressed in the
  
  earlier commit.
  

  • [DH] libavcodec/vulkan_decode.c
  • [DH] libavcodec/vulkan_decode.h