[mythtv] Understanding the myth source code

[Ed W]

On 29/05/2010 10:18, James Courtier-Dutton wrote:
> If we put aside the profiling and improving performance points.
> I would like to move all the "processing" to after the "recording" stage.
> If I wanted to record a DVB mux that did not contain any recognisable
> video or audio, mythtv would refuse to record it currently as it would
> not see any key frames.
> I.e. It was data in some format that the mythtv backend did not understand yet.
> I want to be able to record this data, and then later process it or
> implement support for it in myth. The important bit, being recording
> the data in its original form.
>
> It is looking to be a rather big task based on the current mythtv
> architecture that relies on the processing being done before
> recording.
>
>    

Well it's not me doing the work, but my thought (without having looked 
enough at the code) is that this isn't a silver bullet.  Consider that 
keyframes are usually seen in under half a second and we can see that 
the worst case latency in the current algorithm is half a second.  So 
clearly there are some other bits causing further latency?

I sincerely think you need to look at this as not having a single thing 
you can "fix" and as a serious of steps that you can shave 0.1s off here 
and there? If you are sure this is the bottleneck then please at least 
show some instrumentation showing how YOUR channel change time is made up?

All you need to do is stick some timers into the code and log the output 
after key steps of the channel change.  With this as your basis we can 
stop theorising about where the time is spent and start getting some 
hard numbers.  It's so important to baseline stuff before you start to 
change things, otherwise you can't possibly measure improvements

Even if your suggestion were fully implemented today, there is still a 
bunch of latency where the backend queue's some data before sending it 
to the frontend, then the frontend queues some data before sending it 
for output.  This latency is almost certainly possible to reduce and 
likely is at least as significant as the changes you are looking at?  So 
I really would suggest starting by adding some timers, measuring the 
various steps (it's quite instructive actually!) and then moving from there

It would actually be very interesting just to get proper benchmarking of 
where the time really is spent... Don't underestimate just how valuable 
that information alone would be?

Good luck

Ed W