題 xawtv / streamer網絡攝像頭快照被“包裹”,但是流式傳輸有效


如果我使用我的網絡攝像頭拍攝快照,請右鍵單擊 xawtv 或通過 streamer -o snapshot.jpeg,圖像失真。最簡單的解釋方法是通過示例圖片:

enter image description here enter image description here

較低的兩個“框架”應交換位置。如果我跑了 xawtv 要么 vlc 要觀看網絡攝像頭的實時信息,這種失真不會出現,視頻也很好。

我不知道這是怎麼發生的。可能有什麼不對?我應該在哪裡開始排除故障

更新:事實證明,圖片的上部“框架”與其餘部分的時間點不同。我添加了第二張圖片來展示這一點。

調試信息

xawtv是xawtv-3.101,在Linux / x86_64(3.6.8-1-ARCH)上運行。上面的圖片是用 streamer -d -o test.jpeg,生成此調試輸出:

checking writer files [multiple image files] ...
  video name=ppm ext=ppm: ext mismatch [need jpeg]
  video name=pgm ext=pgm: ext mismatch [need jpeg]
  video name=jpeg ext=jpeg: OK
files / video: JPEG (JFIF) / audio: none
vid-open: trying: libv4l... 
Using libv4l plugin
v4l2: device caps: 2, required 0
v4l2: open
v4l2: device info:
  uvcvideo 3.6.8 / Video WebCam @ usb-0000:00:1d.7-5
vid-open: ok: libv4l
movie_init_writer start
setformat: JPEG (JFIF) (320x240): failed
v4l2: new capture params (320x240, YU12, 115200 byte)
setformat: 12 bit YUV 4:2:0 (planar) (320x240): ok
v4l2: new capture params (320x240, YU12, 115200 byte)
writer_video_thread start [pid=31119]
movie_init_writer end (h=0x1808bc0)
convert_thread start [pid=31119]
movie_writer_start
convert-in : 320x240 12 bit YUV 4:2:0 (planar) (size=115200)
convert-out: 320x240 JPEG (JFIF) (size=230400)
v4l2: buf 0: video-cap 0xabcdef00+16777216, used 0
v4l2: buf 1: video-cap 0xabcdef01+16777216, used 0
v4l2: buf 2: video-cap 0xabcdef02+16777216, used 0
v4l2: buf 3: video-cap 0xabcdef03+16777216, used 0
v4l2: buf 4: video-cap 0xabcdef04+16777216, used 0
v4l2: buf 5: video-cap 0xabcdef05+16777216, used 0
v4l2: buf 6: video-cap 0xabcdef06+16777216, used 0
v4l2: buf 7: video-cap 0xabcdef07+16777216, used 0
v4l2: buf 8: video-cap 0xabcdef08+16777216, used 0
v4l2: buf 9: video-cap 0xabcdef09+16777216, used 0
v4l2: buf 10: video-cap 0xabcdef0a+16777216, used 0
v4l2: buf 11: video-cap 0xabcdef0b+16777216, used 0
v4l2: buf 12: video-cap 0xabcdef0c+16777216, used 0
v4l2: buf 13: video-cap 0xabcdef0d+16777216, used 0
v4l2: buf 14: video-cap 0xabcdef0e+16777216, used 0
v4l2: buf 15: video-cap 0xabcdef0f+16777216, used 0
v4l2: start ts=47580553178000
rec 0:00.00  -  a/r: -0.00s [0], a/v: -0.00s [0]  
movie_writer_stop
fifo conv: EOF 1/1
fifo video: EOF 1/1
convert_thread done [pid=31119]
writer_video_thread done
v4l2: buf 0: video-cap 0xabcdef00+16777216, used 115200
v4l2: buf 1: video-cap 0xabcdef01+16777216, used 0
v4l2: buf 2: video-cap 0xabcdef02+16777216, used 0
v4l2: buf 3: video-cap 0xabcdef03+16777216, used 0
v4l2: buf 4: video-cap 0xabcdef04+16777216, used 0
v4l2: buf 5: video-cap 0xabcdef05+16777216, used 0
v4l2: buf 6: video-cap 0xabcdef06+16777216, used 0
v4l2: buf 7: video-cap 0xabcdef07+16777216, used 0
v4l2: buf 8: video-cap 0xabcdef08+16777216, used 0
v4l2: buf 9: video-cap 0xabcdef09+16777216, used 0
v4l2: buf 10: video-cap 0xabcdef0a+16777216, used 0
v4l2: buf 11: video-cap 0xabcdef0b+16777216, used 0
v4l2: buf 12: video-cap 0xabcdef0c+16777216, used 0
v4l2: buf 13: video-cap 0xabcdef0d+16777216, used 0
v4l2: buf 14: video-cap 0xabcdef0e+16777216, used 0
v4l2: buf 15: video-cap 0xabcdef0f+16777216, used 0
fifo max fill: audio 0/0, video 1/16, convert 1/16  
v4l2: close

4
2017-12-02 18:49


起源




答案: