Recherche avancée

Sur d’autres sites (11800)

• Parsing avconv/ffmpeg rawvideo output ?

  23 avril 2013, par DigitalMan

  I'm about to begin a project that will involve working with the output of avconv/ffmpeg, pixel-by-pixel, in rgb32 format. I intend to work with a raw byte stream, such as from the pipe protocol. Basic pointer arithmetic (C/C++) will be used to iterate over these pixels, and modify them in arbitrary manners in real-time.

  I've created a very small file using rawvideo format and codec, and opened it up in a hex editor. As expected, it's just a series of pixels, read right to left, top to bottom. No distinguishing between lines - no problem, if you know how wide the video is beforehand. No distinguishing between frames - no problem, if you also know how tall the video is. No file header for frame rate, or even what the encoding (rgb32, rgb24, yuv, etc.) is - again, as long as you already know, it can be worked with.

  The problem occurs when - for one reason or another - some bytes are missing. Maybe the stream isn't being examined from the beginning, which is likely be the case in my project, or maybe something just got lost. All the pre-existing knowledge in the world (besides maybe a byte count of what's been missed, not gonna happen) won't prevent it from happily chugging along, with an incorrect offset of line and frame.

  So, what I'm looking for is an option for rawvideo, or possibly some other format/codec, that will allow me to work with the resulting stream at the pixel level, in RGB, yet still have a clear definition of where a new frame begins, even if it happens to start "looking" in the middle of a frame. (Width, height, and framerate will indeed be known.)

• swscale/utils : add helper function to infer colorspace metadata

  28 novembre 2024, par Niklas Haas

  swscale/utils : add helper function to infer colorspace metadata
  Logic is loosely on equivalent decisions in libplacebo. The basic idea is to try
  
  and be a bit conservative by treating AVCOL_*_UNSPECIFIED as a no-op, unless the
  
  other primaries set are non-standard / wide-gamut or HDR. This helps avoid
  
  unintended or unexpected colorspace conversions, while forcing it in cases where
  
  we are almost certain it is needed. The major departure from libplacebo semantics
  
  is that we no default to a 1000:1 contrast ration for SDR displays, instead modelling
  
  them as idealized devices with an infinite contrast ratio.
  In either case, setting SWS_STRICT overrides this behavior in favor of always
  
  requiring explicit colorspace metadata.
  

  • [DH] libswscale/utils.c
  • [DH] libswscale/utils.h

• Can Linux Buffer UDP Packet to correct Sequence issues

  6 avril 2021, par QuickPrototype

  Good Day,

  


  I am transmitting MP3 audio using UDP through the internet. Yes, it most likely is a bad idea for various reasons, however my use case limits me to this setup.

  


  The issue that I am trying to resolve is that on the receiver server (Linux Ubuntu 18.04), I am seeing all the packets but many times slightly out of sequence. I.e. packet 5 comes before packet 4.

  


  Is there a way in Linux to buffer the incoming UDP stream such that consumers (FFMPEG in my case) is able to get stream in order (being a buffer, with an expected delay, that would be linked to buffer size).

  


  tcpdump example of issue (note : id is out of sequence) :

  


  16:04:48.648448 IP (tos 0x0, ttl 24, id 25335, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80
16:04:48.648503 IP (tos 0x0, ttl 24, id 25334, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:48.884324 IP (tos 0x0, ttl 24, id 25336, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:48.884357 IP (tos 0x0, ttl 24, id 25337, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80
16:04:49.145213 IP (tos 0x0, ttl 24, id 25339, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80
16:04:49.145257 IP (tos 0x0, ttl 24, id 25338, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:49.406068 IP (tos 0x0, ttl 24, id 25340, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:49.406125 IP (tos 0x0, ttl 24, id 25341, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80
16:04:49.667095 IP (tos 0x0, ttl 24, id 25342, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:49.667175 IP (tos 0x0, ttl 24, id 25343, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80
16:04:49.929139 IP (tos 0x0, ttl 24, id 25344, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:49.929200 IP (tos 0x0, ttl 24, id 25345, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80
16:04:50.164307 IP (tos 0x0, ttl 24, id 25346, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:50.164385 IP (tos 0x0, ttl 24, id 25347, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80
16:04:50.425221 IP (tos 0x0, ttl 24, id 25348, offset 0, flags [DF], proto UDP (17), length 1228)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 1200
16:04:50.425285 IP (tos 0x0, ttl 24, id 25349, offset 0, flags [DF], proto UDP (17), length 108)
    xx.xx.xx.xx.2011 > 172.xx.xx.xx.2011: UDP, length 80