Opened 14 years ago
Closed 12 years ago
#8695 closed enhancement (Won't Fix)
Optimize DVBStreamHandler::UpdateFiltersFromStreamData()
Reported by: | Owned by: | Janne Grunau | |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | MythTV - DVB | Version: | 0.23-fixes |
Severity: | low | Keywords: | |
Cc: | Stuart Auchterlonie | Ticket locked: | no |
Description
The current UpdateFiltersFromStreamData?() figures out what pids have changed(added/removed) by comparing two maps. This is a needlessly expensive way of doing it considering it is called quite often by RunTS().
The managing of pid changes could be done better/cheaper by the MPEGStreamData class since it is it already manages the pids, and know when they change.
I have attached a PoC patch that reduces CPU usage of the backend by 20-30% - (active EIT and no frontend) this is on a Geode system. On a faster system this may very well be insignificant.
The patch will change the functionality slightly if a pid is removed and added again in MPEGStreamData.
Current behavior:
UpdateFiltersFromStreamData?() will make no change
The PoC patch:
UpdateFiltersFromStreamData?() will close the filter, and then reopen it.
Attachments (2)
Change History (9)
Changed 14 years ago by
Attachment: | optimize_UpdateFiltersFromStreamData_v1.patch added |
---|
comment:1 Changed 14 years ago by
comment:2 Changed 14 years ago by
Cc: | Stuart Auchterlonie added |
---|
Changed 14 years ago by
Attachment: | optimize_UpdateFiltersFromStreamData_v3.patch added |
---|
fully functional Poc for DVB (other sources are broken)
comment:3 Changed 14 years ago by
I have attached a new PoC patch that is fully functional on DVB. (the patch also contains initial work of joining all the pidmaps into a single pidmap)
Wen I look at the changes needed it is clear it will never get into 0.23-fixes, but what about trunk?
comment:4 Changed 14 years ago by
Status: | new → assigned |
---|
comment:5 Changed 13 years ago by
Status: | assigned → infoneeded |
---|
Rune,
I don't see this ever being applied unless it is out of the proof of concept stage. Are you willing to/able provide a patch which leaves all recorders functional? If not, I don't think we can do anything with this ticket without someone willing to do the work themselves.
comment:6 Changed 13 years ago by
The description is badly worded (my specialty).
I do intend to do the work, I just don't like wasting time on a patch if "you" aren't interested
From one of my comments:
"So the question is: will you accept a patch along the lines the PoC patch? (not necessarily for 0.23-fixes)"
I will be rebasing my patches in the near future, so If "you" are interested I'll see about cleaning it up when I rebase.
And if I could get some constructive critique on the PoC I would be grateful
comment:7 Changed 12 years ago by
Resolution: | → Won't Fix |
---|---|
Status: | infoneeded → closed |
Closing this ticket, please feel free to open a new one if you decide to do the work, I don't think anyone can answer whether a theoretical patch will be accepted.
I just realized that my patch breaks multiple sinks(MPEGStreamData derived classes) with overlapping pids - this can of cause be resolved using ref-counting.
So the question is: will you accept a patch along the lines the PoC patch? (not necessarily for 0.23-fixes)