[FFmpeg-devel] rtsp/rtp - blocking loop in udp_read_packet

Anthony Champagne anthony.champagne
Wed Apr 23 12:54:42 CEST 2008

I've started to modify url_*interrupt_cb but the problem is harder that it
seems. I couldn't pass a AVFormatContext because avio.h doesn't know
anything about this struct, and passing URLContext doesn't help because
RTSPStream and RTSPState structures are private (declared in rtsp.c). 

Probably url_*interrupt_cb is defined in the wrong file, and doesn't take
the right name. Perhaps in avformat.h directly in AVFormatContext as a
function pointer field would be a better place ?

A complete implementation of nonblocking reads involve removing hack like
rtp_get_file_handles()/select() call in udp_read_packet() and implement a
url_list_create() url_list_probe_read() or something like that, which manage
blocking/nonblocking URLContext. Am I wrong?

Anyway, thanks for your answer :) I think I'll choose your patch for the


-----Message d'origine-----
De?: ffmpeg-devel-bounces at mplayerhq.hu
[mailto:ffmpeg-devel-bounces at mplayerhq.hu] De la part de elupus
Envoy??: mercredi 23 avril 2008 11:42
??: ffmpeg-devel at mplayerhq.hu
Objet?: Re: [FFmpeg-devel] rtsp/rtp - blocking loop in udp_read_packet

Anthony Champagne <anthony.champagne <at> haxe.fr> writes:

> What do you think of, could it be part of a patch ? or is there another
> (except threadlock entire av_read_packet() call with a previously
> initialized global variable with format context) to achieve my needs ?
> Anthony Champagne

I posted a patch a while back that caused the read function to behave semi 
nonblocking and return EAGAIN if no data was available. You could
use that. 

But as Luca pointed out. It's not entire complete as it could still stall 
during a read + it's not really the correct use for that flag as sockets are

really not nonblocking.

A complete implementation of nonblocking reads or fixing up the abort
to give context would be accepted as a patch.


ffmpeg-devel mailing list
ffmpeg-devel at mplayerhq.hu

More information about the ffmpeg-devel mailing list