Problem capturing udp stream with vlc

[ori9933]

Hello,

I have a dvtel encoder(EA-201-0) connected to my LAN.
I tried capturing its stream output using vlc but failed.

I know the device is working properly as I was able to see the video output through their web interface.

I monitored the network interface to see the packets the device is sending:



This is the command I tried on vlc:

Code: Select all

udp://device_ip:device:port udp://192.168.123.3:5517 (example).

This is the error message returned by vlc:

Code: Select all

qt4 warning: Input option: udp-caching=300 main debug: adding item `udp://192.168.123.3:5517' ( udp://192.168.123.3:5517 ) main debug: socket 1328 polling interrupted main debug: prebuffering done 0 bytes in 128s - 0 KiB/s main error: cannot pre fill buffer main warning: cannot create a stream_t from access main debug: removing module "access_udp" main debug: waitpipe: object killed qt4 debug: Adding a new MRL to recent ones: udp://192.168.123.3:5517 main debug: dying input main debug: thread ended main debug: dead input main debug: thread times: real 2m8.842369s, kernel 0m0.000000s, user 0m0.000000s main debug: processing request item udp://192.168.123.3:5517 node null skip 0 main debug: rebuilding array of current - root Playlist main debug: rebuild done - 3 items, index 2 main debug: starting new item main debug: creating new input thread main debug: Creating an input for 'udp://192.168.123.3:5517' main debug: thread (input) created at priority 1 (../.././src/input/input.c:214) main debug: thread started main debug: using timeshift granularity of 50 MiB main debug: using timeshift path 'C:\Users\me\AppData\Local\Temp' main debug: `udp://192.168.123.3:5517' gives access `udp' demux `' path `192.168.123.3:5517' main debug: creating demux: access='udp' demux='' path='192.168.123.3:5517' main debug: looking for access_demux module: 0 candidates main debug: no access_demux module matched "udp" main debug: TIMER module_need() : 0.000 ms - Total 0.000 ms / 1 intvls (Avg 0.000 ms) main debug: creating access 'udp' path='192.168.123.3:5517' main debug: looking for access module: 1 candidate access_udp debug: opening server=192.168.123.3:5517 local=:1234 main debug: net: connecting to [192.168.123.3]:5517 from []:1234 main debug: using access module "access_udp" main debug: TIMER module_need() : 1.000 ms - Total 1.000 ms / 1 intvls (Avg 1.000 ms) main debug: Using AStream*Block main debug: pre buffering main debug: no fetch required for (null) (art currently (null)) qt4 debug: IM: Deleting the input main debug: TIMER input launching for 'udp://192.168.123.3:5517' : 128872.006 ms - Total 128872.006 ms / 1 intvls (Avg 128872.000 ms) qt4 debug: IM: Setting an input

I will appreciate any help.

Thanks.

[Rémi Denis-Courmont]

There are no errors in your VLC log. No data is coming, so VLC just waits.

[tnariel]

Hello everyone!

I have a question about those cases where vlc is indefinitely idle while waiting for data that may never come. is there an option that could be used in order stop the waiting process ? i mean a kind of timeout ...

Thank you

[Rémi Denis-Courmont]

That is the stop button.

[tnariel]

That's unfortunately an option in my use case. In fact i'm using libvlc in a java swing application, and when the player is in that state, it is unresponsive to all other queries (stop, etc...). That's why I was asking about a timeout-like option to break the idle state, or some kind of way to throw an error so that the player would stop itself.

[Rémi Denis-Courmont]

Waiting for network packet is done in the input thread, not the application thread. You can definitely invoke stop. In fact the VLC own UI does it that way.

[tnariel]

Thanks for your answer, but I guess I must be describing another situation. If you take a look at the logs below :

=============================================================================

qt4 warning: Input option: rtsp-caching=1200
main debug: adding item `rtsp://192.168.1.30:1935/LiveRecord/0080F0B8EC36$$'
qt4 debug: Adding a new MRL to recent ones: rtsp://192.168.1.30:1935/LiveRecord/0080F0B8EC36$$
main debug: rebuilding array of current - root Liste de lecture
main debug: rebuild done - 1 items, index -1
main debug: processing request item rtsp://192.168.1.30:1935/LiveRecord/0080F0B8EC36$$ node null skip 0
main debug: resyncing on rtsp://192.168.1.30:1935/LiveRecord/0080F0B8EC36$$
main debug: rtsp://192.168.1.30:1935/LiveRecord/0080F0B8EC36$$ is at 0
main debug: starting new item
main debug: creating new input thread
main debug: Creating an input for 'rtsp://192.168.1.30:1935/LiveRecord/0080F0B8EC36$$'
main debug: thread (input) created at priority 1 (../.././src/input/input.c:220)
main debug: thread started
main debug: using timeshift granularity of 50 MiB
main debug: using timeshift path 'C:\Users\XXXXXXX\AppData\Local\Temp'
main debug: `rtsp://192.168.1.30:1935/LiveRecord/0080F0B8EC36$$' gives access `rtsp' demux `' path `192.168.1.30:1935/LiveRecord/0080F0B8EC36$$'
main debug: creating demux: access='rtsp' demux='' path='192.168.1.30:1935/LiveRecord/0080F0B8EC36$$'
main debug: looking for access_demux module: 1 candidate
qt4 debug: IM: Setting an input
live555 debug: RTP subsession 'audio/MPEG4-GENERIC'
main debug: selecting program id=0
live555 debug: RTP subsession 'video/H264'
live555 debug: setup start: 0.000000 stop:0.000000

===================================================

After the last line, vlc instance is idle, my guess is that it's waiting for an incoming stream that never comes. The consequences are that the vlc process uses 100% of a core (in the task manager), and when I push the stop button, I get the logs below :
-----------------------------------------------------------------
main debug: incoming request - stopping current input
main debug: dying input
-----------------------------------------------------------------

The process don't stop, and vlc is still up and using 100% of my resources.

Do you have any ideas about what's going on, and may be a solution as to stop it properly without shuting down the process ?

I tried using several timeout options like rtsp-session-timeout, rtp-timeout, netsync-timeout, mms-timeout, ipv4-timeout, sap-timeout, but none of them seems to be working in this particular case.

Ariel.