[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
moment.
Anthony
-----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
way
> (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
potentially
use that.
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/57508/focus=57881
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
function
to give context would be accepted as a patch.
Regards
Joakim
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel at mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
More information about the ffmpeg-devel
mailing list