Recherche avancée

Sur d’autres sites (11205)

• ffmpeg h264 interesting bright video fail ?

  23 novembre 2019, par Max Paython

  I am trying streaming with ffmpeg using the information I found here.

  • Server

    ffmpeg -f dshow -i video="john":audio="doe" -vcodec libx264
    
    -preset ultrafast -tune zerolatency -acodec aac -f mpegts udp://localhost:1234

  • Client

    ffmpeg -i udp://localhost:1234?listen test.mp4

  The client will actually live stream the video, but for testing purposes I am writing the output to a file for now.

  Here comes the interesting part. I began the stream(video and audio) in a dark room, everything is fine. I turn on the room’s lights and the client cries with many errors. I later checked the output, it is very corrupted indeed on the light turned-on parts. What could be the reason behind this ? I am posting the errors here if it could be of assistance.

  Some of the errors :

  udp://localhost:1234?listen: corrupt decoded frame in stream 0trate= 845.6kbits/s dup=1250 drop=0 speed=1.08x
  
      Last message repeated 1 times
  
  [h264 @ 0000026c4af69400] Invalid NAL unit 1, skipping.7.61 bitrate= 864.7kbits/s dup=1441 drop=0 speed=1.07x
  
  [h264 @ 0000026c4af69400] Invalid level prefix
  
  [h264 @ 0000026c4af69400] error while decoding MB 18 8
  
  [h264 @ 0000026c4af69400] concealing 911 DC, 911 AC, 911 MV errors in P frame
  
  [h264 @ 0000026c4af4b780] Invalid NAL unit 1, skipping.
  
  [h264 @ 0000026c4af4b780] negative number of zero coeffs at 10 14
  
  [h264 @ 0000026c4af4b780] error while decoding MB 10 14
  
  [h264 @ 0000026c4af4b780] concealing 679 DC, 679 AC, 679 MV errors in P frame
  
  udp://localhost:1234?listen: corrupt decoded frame in stream 0
  
      Last message repeated 1 times
  
  [h264 @ 0000026c4ba1e1c0] Invalid NAL unit 1, skipping.8.21 bitrate= 858.0kbits/s dup=1460 drop=0 speed=1.07x
  
  [h264 @ 0000026c4ba1e1c0] out of range intra chroma pred mode
  
  [h264 @ 0000026c4ba1e1c0] error while decoding MB 34 18
  
  [h264 @ 0000026c4ba1e1c0] concealing 495 DC, 495 AC, 495 MV errors in P frame
  
  [h264 @ 0000026c4bb16840] top block unavailable for requested intra mode
  
  [h264 @ 0000026c4bb16840] error while decoding MB 10 0
  
  [h264 @ 0000026c4bb16840] concealing 160 DC, 160 AC, 160 MV errors in P frame
  
  udp://localhost:1234?listen: corrupt decoded frame in stream 0
  
  [h264 @ 0000026c4bb16cc0] Invalid NAL unit 0, skipping.8.58 bitrate= 853.9kbits/s dup=1463 drop=0 speed=1.06x
  
  [h264 @ 0000026c4bb16cc0] corrupted macroblock 16 28 (total_coeff=-1)
  
  [h264 @ 0000026c4bb16cc0] error while decoding MB 16 28
  
  [h264 @ 0000026c4bb16cc0] concealing 113 DC, 113 AC, 113 MV errors in P frame
  
  [h264 @ 0000026c4bb17140] cbp too large (84) at 12 0
  
  [h264 @ 0000026c4bb17140] error while decoding MB 12 0
  
  [h264 @ 0000026c4bb17140] concealing 160 DC, 160 AC, 160 MV errors in P frame
  
  [mpegts @ 0000026c4aeb8d80] PES packet size mismatch

  Edit : As suggestion, I added these parameters to the server.

  -b:v 1M -bufsize 2M

  Now the errors are mostly gone. Except one time where it seemed like it occured just as I was turning off the lights, although I could not reproduce it after trying 4-5 times.

  Errors :

  [h264 @ 000002646f0d2f80] cbp too large (118) at 23 1422.25 bitrate= 659.5kbits/s dup=368 drop=0 speed=1.33x
  
  [h264 @ 000002646f0d2f80] error while decoding MB 23 14
  
  [mpegts @ 000002646e578d80] PES packet size mismatch
  
  [h264 @ 000002646f0d2f80] concealing 666 DC, 666 AC, 666 MV errors in P frame
  
  [h264 @ 000002646f0d0f80] concealing 160 DC, 160 AC, 160 MV errors in P frame
  
  [aac @ 000002646e64d640] Number of bands (59) exceeds limit (43).
  
  Error while decoding stream #0:1: Invalid data found when processing input
  
  [aac @ 000002646e64d640] Multiple frames in a packet.
  
  [aac @ 000002646e64d640] Reserved bit set.
  
  [aac @ 000002646e64d640] Number of bands (31) exceeds limit (29).
  
  Error while decoding stream #0:1: Invalid data found when processing input
  
  [h264 @ 000002646e5e11c0] concealing 160 DC, 160 AC, 160 MV errors in P frame
  
  udp://localhost:1234?listen: corrupt decoded frame in stream 0trate= 633.1kbits/s dup=368 drop=0 speed=1.35x
  
      Last message repeated 2 times

  The errors decreased because I increased the bitrate ? (I don’t know the default bitrate by the way). Bright decoding fails because it carries more information, data ? (same in raw video, but maybe file is heavier encoded bright frames)

• dnn/vf_dnn_detect.c : add tensorflow output parse support

  6 mai 2021, par Ting Fu

  dnn/vf_dnn_detect.c : add tensorflow output parse support
  Testing model is tensorflow offical model in github repo, please refer
  
  https://github.com/tensorflow/models/blob/master/research/object_detection/g3doc/tf2_detection_zoo.md
  
  to download the detect model as you need.
  
  For example, local testing was carried on with 'ssd_mobilenet_v2_coco_2018_03_29.tar.gz', and
  
  used one image of dog in
  
  https://github.com/tensorflow/models/blob/master/research/object_detection/test_images/image1.jpg
  Testing command is :
  
  ./ffmpeg -i image1.jpg -vf dnn_detect=dnn_backend=tensorflow:input=image_tensor:output=\
  
  "num_detections&detection_scores&detection_classes&detection_boxes":model=ssd_mobilenet_v2_coco.pb,\
  
  showinfo -f null -
  We will see the result similar as below :
  
  [Parsed_showinfo_1 @ 0x33e65f0]   side data - detection bounding boxes :
  
  [Parsed_showinfo_1 @ 0x33e65f0] source : ssd_mobilenet_v2_coco.pb
  
  [Parsed_showinfo_1 @ 0x33e65f0] index : 0,       region : (382, 60) -> (1005, 593), label : 18, confidence : 9834/10000.
  
  [Parsed_showinfo_1 @ 0x33e65f0] index : 1,       region : (12, 8) -> (328, 549), label : 18, confidence : 8555/10000.
  
  [Parsed_showinfo_1 @ 0x33e65f0] index : 2,       region : (293, 7) -> (682, 458), label : 1, confidence : 8033/10000.
  
  [Parsed_showinfo_1 @ 0x33e65f0] index : 3,       region : (342, 0) -> (690, 325), label : 1, confidence : 5878/10000.
  There are two boxes of dog with cores 94.05% & 93.45% and two boxes of person with scores 80.33% & 58.78%.
  Signed-off-by : Ting Fu <ting.fu@intel.com>
  
  Signed-off-by : Guo, Yejun <yejun.guo@intel.com>
  

  • [DH] libavfilter/vf_dnn_detect.c

• Dreamcast Track Sizes

  1er mars 2015, par Multimedia Mike — Sega Dreamcast

  I’ve been playing around with Sega Dreamcast discs lately. Not playing the games on the DC discs, of course, just studying their structure. To review, the Sega Dreamcast game console used special optical discs named GD-ROMs, where the GD stands for “gigadisc”. They are capable of holding about 1 gigabyte of data.

  You know what’s weird about these discs ? Each one manages to actually store a gigabyte of data. Each disc has a CD portion and a GD portion. The CD portion occupies the first 45000 sectors and can be read in any standard CD drive. This area is divided between a brief data track and a brief (usually) audio track.

  The GD region starts at sector 45000. Sometimes, it’s just one humongous data track that consumes the entire GD region. More often, however, the data track is split between the first track and the last track in the region and there are 1 or more audio tracks in between. But the weird thing is, the GD region is always full. I made a study of it (click for a larger, interactive graph) :

  
  
  

  Some discs put special data or audio bonuses in the CD region for players to discover. But every disc manages to fill out the GD region. I checked up on a lot of those audio tracks that divide the GD data and they’re legitimate music tracks. So what’s the motivation ? Why would the data track be split in 2 pieces like that ?

  I eventually realized that I probably answered this question in this blog post from 4 years ago. The read speed from the outside of an optical disc is higher than the inside of the same disc. When I inspect the outer data tracks of some of these discs, sure enough, there seem to be timing-sensitive multimedia FMV files living on the outer stretches.

  One day, I’ll write a utility to take apart the split ISO-9660 filesystem offset from a weird sector.