Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#6807 closed defect (needs_more_info)

RTSP/UDP is not working in FFPLAY

Reported by: Ben321 Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug: RTSP/UDP is not working in FFPLAY (nor in FFMPEG)
Version: unknown (not standard version number)
Version Reported: "ffplay version N-81154-gfb91143"

How to reproduce:
Not sure which versions of FFPLAY this applies to, or maybe all of them. My system for testing it is Windows.
The command line I'm using is:
ffplay.exe -loglevel trace -rtsp_transport udp rtsp://121.167.43.161/chosun

An important looking line of text displayed in the console says "[tcp @ 05544b20] No default whitelist set". Notice that it says TCP instead of UDP. It seems that it's attempting to use RTSP/TCP instead of RTSP/UDP, even though I manually specified "-rtsp_transport udp" in the command line.

Please fix this. I believe the source of the stream I'm trying to view is using RTSP/UDP, not RTSP/TCP, as it doesn't work in FFPLAY for Windows (and possibly FFPLAY for other platforms as well) only available version of RTSP (which is RTSP/TCP), but by using another player (an app for Android called Stream Player) I can view the stream perfectly. This strongly points to the stream using RTSP/UDP instead of RTSP/TCP.

Tested in FFMPEG as well with this command line, in order to transcode and save the stream into an MP4 file:
ffmpeg.exe -loglevel trace -rtsp_transport udp -i rtsp://121.167.43.161/chosun test.mp4

Same problem. It won't work because it appears to keep trying to use TCP instead of UDP.

Again, please fix this bug.

Change History (3)

comment:1 by Carl Eugen Hoyos, 6 years ago

Component: ffplayundetermined
Resolution: needs_more_info
Status: newclosed

If you believe you found a bug related to FFmpeg, please test current (unpatched) FFmpeg git head and provide the command line you tested together with the complete, uncut console output. If an issue is reproducible with ffmpeg, do not report it with ffplay.
If you need usage support, please post on the FFmpeg user mailing list, also test current FFmpeg git head first, also post your command line together with the complete, uncut console output there.

I created ticket #6808 for a regression that I see with the url you tested.

in reply to:  1 comment:2 by Ben321, 6 years ago

Replying to cehoyos:

If you believe you found a bug related to FFmpeg, please test current (unpatched) FFmpeg git head and provide the command line you tested together with the complete, uncut console output. If an issue is reproducible with ffmpeg, do not report it with ffplay.
If you need usage support, please post on the FFmpeg user mailing list, also test current FFmpeg git head first, also post your command line together with the complete, uncut console output there.

I created ticket #6808 for a regression that I see with the url you tested.

I did not test a copy that I compiled myself. There are several problems with compiling. One is that I don't know how to do it. And the other problem is that it is designed to be compiled in Linux (an OS that I don't have) and is designed to run in Linux (again, I don't have that OS). Since I'm a Windows user, I can only run the Windows binary of FFMPEG. And there is only one place to get that compiled binary of FFMPEG. That one place is the website Zeranoe. I know that may not be seen as the "official" version, but it is as close to the official version as I will ever get, as I'm a Windows user. So it is not right of you to shut down bug reports that I write, just because I didn't compile it myself from the source code.

comment:3 by Carl Eugen Hoyos, 6 years ago

Although compilation on Windows is supposed to work out-of-the-box with both gcc and msvc and FFmpeg is designed to (also) run on Windows I did not ask you to compile yourself.

Note: See TracTickets for help on using tickets.