Opened 14 years ago
Closed 14 years ago
#9722 closed Patch - Bug Fix (Fixed)
HTTP streaming
Reported by: | Owned by: | markk | |
---|---|---|---|
Priority: | minor | Milestone: | 0.25 |
Component: | MythTV - Video Playback | Version: | Master Head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
I had some troubles getting HTTP streaming to work reliably and managed to come up with a patch. If it's not a good solution, maybe it will at least give the devs a clue of what the problem might be.
RTMP also works (except seeking) if configured with --enable-librtmp.
Changes:
- Changed url_read() to url_read_complete(). This got rid of logs from RingBuffer:Seek() complaining about reads returning less than requested.
- Reopened the stream by calling url_close() followed by url_open() prior to calling av_open_input_stream(). This got rid of various decoding errors.
- Added call to url_seek() in StreamingRingBuffer::Seek() to support seeking in HTTP streams
Attachments (3)
Change History (11)
Changed 14 years ago by
Attachment: | streaming.patch added |
---|
comment:1 Changed 14 years ago by
Milestone: | unknown → 0.25 |
---|---|
Owner: | changed from Janne Grunau to markk |
Status: | new → accepted |
comment:2 Changed 14 years ago by
comment:3 follow-up: 4 Changed 14 years ago by
Jonatan
Can you explain what the url_close element of the patch is adding? I'm not seeing any issues with decoder errors. Under what conditions are you seeing errors?
As far as the rtmp support is concerned, I'll hold off on this for now. Few people will have librtmp available and without any core integration, it is unlikely to be utilised for some time.
comment:4 Changed 14 years ago by
Replying to markk:
Jonatan
Can you explain what the url_close element of the patch is adding? I'm not seeing any issues with decoder errors. Under what conditions are you seeing errors?
Good news is that HTTP now seem to be working fine even without the url_close element of the patch. RTMP still doesn't work without it though. I'll attach logfiles for when it works and when it doesn't.
As far as the rtmp support is concerned, I'll hold off on this for now. Few people will have librtmp available and without any core integration, it is unlikely to be utilised for some time.
Sure, no problem.
Changed 14 years ago by
Attachment: | with_patch.log added |
---|
With url_close part of the patch, where RTMP works
Changed 14 years ago by
Attachment: | without_patch.log added |
---|
Without url_close part of the patch, where RTMP doesn't work
comment:5 Changed 14 years ago by
Disallow seeking in http:// streams.
Seeking backwards in http streams will always fail and seeking forward only works on a small minority of files, with no obvious rationale for success. Attempting to allow seeking will almost certainly lead to a raft of user issues once UPnP Media Server support is added.
A further fix is needed to disable rewinding and limit fast forward to 3x or less (i.e. avoid actually seeking).
Refs #9722
Branch: master Changeset: 33be4fc94b2c9bc7cbd08e01df0c7d93853300d6
comment:6 Changed 14 years ago by
TV: Limit fast forward/rewinf if we cannot seek.
Refs #9722
Branch: master Changeset: 3db7e55ab26e5e01ed6a6cfb83bafed78fba3f5c
comment:7 Changed 14 years ago by
TV: Don't show jump options if we cannot jump.
Refs #9722
Branch: master Changeset: 5bcddfd2769c92fed6001f2f1f3ad493e3606e20
comment:8 Changed 14 years ago by
Resolution: | → Fixed |
---|---|
Status: | accepted → closed |
Jonatan - I'm not going to add rtmp:// functionality yet. I suspect we are going to have our hands full supporting http:// in the near future, there is no UI support for rtmp, it adds a dependency on librtmp that needs additional configure support and in my limited testing, rtmp streaming was highly unreliable.
If you have code that requires rtmp functionality, feel free to open another ticket.
Partly applied in 0078315fdac33cffe4e9