Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.
Opened 2 years ago
Closed 2 years ago
#9722 closed Patch - Bug Fix (Fixed)
HTTP streaming
| Reported by: | Jonatan <mythtv@…> | 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 2 years ago by Jonatan <mythtv@…>
comment:1 Changed 2 years ago by markk
- Milestone changed from unknown to 0.25
- Owner changed from janne to markk
- Status changed from new to accepted
comment:2 Changed 2 years ago by markk
comment:3 follow-up: ↓ 4 Changed 2 years ago by 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?
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 in reply to: ↑ 3 Changed 2 years ago by Jonatan <mythtv@…>
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 2 years ago by Jonatan <mythtv@…>
With url_close part of the patch, where RTMP works
Changed 2 years ago by Jonatan <mythtv@…>
Without url_close part of the patch, where RTMP doesn't work
comment:5 Changed 2 years ago by Github
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 2 years ago by Github
TV: Limit fast forward/rewinf if we cannot seek.
Refs #9722
Branch: master
Changeset: 3db7e55ab26e5e01ed6a6cfb83bafed78fba3f5c
comment:7 Changed 2 years ago by Github
TV: Don't show jump options if we cannot jump.
Refs #9722
Branch: master
Changeset: 5bcddfd2769c92fed6001f2f1f3ad493e3606e20
comment:8 Changed 2 years ago by markk
- Resolution set to Fixed
- Status changed from accepted to 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