| Age | Commit message (Collapse) | Author |
|---|
|
this needs new hardware drivers!!
fixed bug #672
|
|
|
|
|
|
|
|
|
|
filepush thread
|
|
refs bug #587
|
|
|
|
|
|
|
|
demux here
|
|
* My previous code for "slow rewind" (aka "SeekBackHack") is not
required any more. Indeed, since the change in "decoder states"
some time ago my code stopped working and is now only destructively
interfering with the new winding approach, effectively ruining the
speed accuracy for slow rewind. Similarly, the "non-smooth winding"
code ruins the accuracy for high winding speeds. The patch below
removes the "SeekBackHack", and temporarily disables the
"non-smooth winding" code until we know whether the decoder states
will allow simultaneous repeat and skip rates
again. (InfoBarGenerics.py)
* Due to a bug in 'eDVBTSTools::findNextPicture', rewind was always
at the required speed minus one. (The frame just played was counted
as one when skipping backwards.) Fixed below. (tstools.cpp)
* A piece of code to apparently increase precision in seeking, by
always aligning to an i-frame start, had exactly the opposite
effect: GOP single-stepping fails completely on DM7025 and gets
highly unreliable on DM800. The piece of code is removed.
(It destructively interferes with previous code by me to hit frames
somewhat before the GOP start. As an alternative, my previous code
can be removed instead, and the currently removed piece of code
adjusted to work. But then it has to be done differently on the two
platforms.) (dvb.cpp)
* By some reason eDVBVideo::getPTS only returns even numbers on DM800
even when it should be odd. This ruins GOP single stepping in 50%
of the cases. This is easy to compensate for by adding a margin of
1 in getAccessPoint. (pvrparse.cpp)
* After the above, when GOP single-stepping works reliable on both
platforms and on SD/HD, the correct step lengths can be
used. (InfoBarGenerics.py)
|
|
|
|
playback
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- this allows finding iframes for fast forward/reverse more easily
- when in fast forward, strictly just output good (=complete iframes) data (this might break dm7025, we will fix this later)
- draw smaller, fixed-size bar in position gauge
|
|
Conflicts:
lib/dvb/decoder.cpp
|
|
This reverts commit d89a0c3e66c6d4d9785e56e335e864d85ad6dcad.
|
|
|
|
|
|
|
|
|
|
|
|
closes #66.
|
|
|
|
|
|
Conflicts:
lib/dvb/sec.cpp
lib/python/Components/Network.py
lib/python/Components/Playlist.py
lib/python/Plugins/Extensions/DVDBurn/Process.py
lib/python/Plugins/Extensions/MediaPlayer/plugin.py
lib/python/Screens/TimerEdit.py
po/lt.po
po/nl.po
po/tr.po
|
|
|
|
* I have checked the effect on DM800 of the margin before GOP:s,
introduced by the "timing bugs" patch and needed for DM7025. As was
previously noted, the margins are not needed on DM800. Fortunately
it turns out also not to have any significant adverse effects: When
jumping back or forward I expected some flickering, but there are
none at all! There is only one small effect as far as I have found:
When a cut list is used, there are somewhat more flickering at the
cut points than without the margins. Since there are flickering
also without the margins, this may be considered a less serious
effect.
If you consider this effect serious enough though, or think that it
is cleaner to separate the code for DM7025 and DM800 since the
margin is needed for one but not the other, then I can try to
produce such a patch. Otherwise I suggest to wait with this.
* In the original timing bugs patch there were a fix to stop playback
after the last OUT cut. It did this by setting the size of the next
source span to 0. But this turned out not to be a good idea: It
seems that playback stops immediately when the next size is set to
zero, and not when the buffer is used up. Therefore playback may
stop some seconds before the actual end. If instead a jump is made
to the last position in the file and a non-zero size is used there,
then for some reason it plays up the whole buffer. Don't ask me why
it is like this. A modification to this effect is anyway included
below.
* Rewind did not work at all for HD movies on DM800. The picture just
freezes. It is because HD movies have another sequence at beginning
of frames than normal movies. There is a rather simple fix, looking
for both HD and normal sequences, in the trickmode playback code.
(If the HD movie sequence condition seems complicated, it is
because it has to make sure not to be accidentally triggered by
normal movies.)
|
|
|
|
* Undo "sparse-AP-fix"
At March 25 a patch was checked in that makes sure that AP:s closer
than half a second from each other are filtered away. I don't know
the exact purpose of this fix, but I don't think it is a good idea:
Besides being the cause of bugs 4 and 5 above, all seek operations
are based on the AP:s, and it is a pity to cripple the precision
here. And for example, when cutting movies it is important to be
able to reach the right GOP boundary. (And the next fix relies on
all boundaries being available.) (If you wonder, bug 5 was caused by
a destructive interaction of this with the discontinuity handling.)
* Hit GOP:s somewhat before GOP start
It turns out that if you jump exactly to the GOP start, then that
GOP is nevertheless skipped and playback starts from the GOP
thereafter. However, if you jump to (at least) one frame before the
GOP start, playback starts from that GOP. I don't know if this is a
bug in the driver or elsewhere, but the best I can do is this
workaround: Hit the GOP by jumping to half a GOP length before the
GOP start. (By scanning the ts file it is of course possible to find
the exact frame boundaries, but why bother since anywhere between
the previous GOP start and the previous frame start will do.)
Similarly, to show the first frame of a GOP, a few more frames must
be included. Therefore, add half a GOP at the end of each source
span.
* Jump over discontinuities during AP relative seek
The above two fixes together *almost* take care of bugs 1 and 2
above. Now seekRelative(1) moves one forward and seekRelative(-1) one
backwards. However, at discontinuities they may get stuck. This is
remedied by an extra if statement to check for discontinuities when
stepping throught the AP:s in AP relative seek.
* Stop after last source span
In the function eDVBChannel::getNextSourceSpan there was no code to
take care of the case when the seeked-to point is after the last
source span. Currently it just goes on until the movie ends. I have
added code for this, which takes care of bug 3, and as a fortunate
bonus effect bug 6 too. (But please check my code here, I hope I can
use current_offset the way I do, and return 0 size when it should
stop.)
|
|
its now no more possible directly to call new eTimer .. or to embedded
eTimer.
to create a eTimer now eTimer::create must be used... to delete you must
call ->AddRef() after timer creation and ->Release when the timer is no more
needed. Or use ePtr<eTimer> to store the timer reference.. then its enough
to set the ePtr<eTimer> object to 0 when the timer is no more needed
|
|
|
|
now its more easy to build a timer overlap detection or similar
|
|
|
|
tuner and one for playback
|
|
dont export AddRef, Release, ptrref and grabRef to python
some cleanups
|
|
|
|
when the hardware doesn't support it
|
|
systems
|
|
|
|
error message (instead of "no free tuner")
|
|
menu (just with expert usage level)
|
