AW: AW: AW: Serial port interface on frame grabber

[vk_gst]

Hi James,

Thanks for the heads up. 

> So GStreamer worked fine with a serial port that did not lose data? 
 I only tried sending the 1MB file as you mentioned in the other post using
the wireless device both connected to the same PC and then one to imx6 board
and one to PC. The losses were observed in both cases. With the
usb-serial-usb cable, the transfer of file worked fine and the sha256sum
matched. 

Streaming the video from imx6 board to PC was done with the wireless device,
but the GStreamer at the PC was not able to display any video at baud
115200. With the same baud,I performed this with the usb-serial-usb wire and
there was no video displayed. Later I tried with the usb-serial-usb cable
and baud=1MBaud and there was a video popup on PC, but with the error as
mentioned in the file
<http://gstreamer-devel.966125.n4.nabble.com/file/t378365/file2.txt>.  The
frames were missed and the video was distorted, not even close to the
videotestsrc I was sending from the imx6 board.  I also tried using a
bitrate of 5Kbps and 10 Kbps and using both (wireless device  &
usb-serial-usb cable ) to send the videotestsrc and save it to a file. The
file was unreadable. The size of file recieved in both cases were 0 bytes. 
Command to write to file ( gst-launch-1.0 -v filesrc location=/dev/ttyUSB0 !
$CAPS ! h264parse ! avdec_h264 ! autovideosink sync=true) .

With 5/10 Kbps bitrate of encoded stream and 1MBaud, GStreamer displays a
distorted video. But not at lesser Baudrates. With ethernet cable and UDP,
everything works fine, should be the data transfer rate and RTP packet
matching that does the trick.

 

> badly configured flow control; if the firmware is configured to use
> XON/XOFF signalling from the host, it may drop all bytes 0x11 or
> 0x13; so check for those bytes in the output you captured, 

I can see the 0x11 and 0x13 bytes in the received file, so this can be ruled
out. 
However, the other things, I can give it a try, but using the flow control
might increase the latency of the video streaming. 

The idea was to try and use the camera on the board and see if we could
stream live video wirelessly. I am trying to build a FPV system for Drones
that is usable for long range(as compared to short range available in
market)


>-PPP might not help; I've not used it with lossy links for a very long
> time, and I imagine it would become confused

I was considering using PPP, because I was thinking that RTP might help in
reconstructing the encoded packets at the receiver side een with some
acceptable losses. As RTP wiki says, it maintains the sequence numbers of
encoded packets to the UDP packets and helps in reconstructing. Such a
feature is not available in case of UART and hence I guess, GStreamer was
unable to reconstruct the frames from the data received. 


Well now, I guess I need to try and find some other solutions. Perhaps LTE
system with GStreamer video streaming. Any views ? 



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/