>On Sat, 2004-07-10 at 10:00 +0200, Fons van der Beek wrote:
>> Would it be possible to do the blackframe detection DURING time
>> shifting?
>
>I've thought a bit about that, and yes, it should be workable.
>
>> This means that timeshift.py a SECOND mplayer proces should be started
>> after the first one. But may never read beyond the buffer, it should
>> be paused if it reaches the buffer
>
>Yes, that's also how I would do it, however ...
>
>> The "player" instance should reread the EDL file when it is altered,
>> thus knowing if there are new markes.
>
>... I would approach it a different way. I don't think the player
>instance should use EDL, because then you'd lose the more precise
>seeking that the timeshift code provides. I think the best way to do
>this is:
>
>1. The timeshift process spawns two MPlayers: one for playback, and
>one for blackframe detection (let's call it BFD for
> convenience), as you said.
>2. The BFD process is controlled by timeshift always to read at the
>end of the buffer. It should never need to be paused, because
> live tv is, well, live. :) BFD should output to stdout parsable
>messages like "BLACK_FRAME=3410" which timeshift process can
> parse and remember.
>3. When the player reaches a black frame, the controlling
>(timeshift) process can tell it to seek to the appropriate place
> (either to the next black frame, or end of buffer, whichever is
>first), and since timeshift also knows what timestamps are where
> in the buffer, seeking will be a lot closer to the mark, since
>MPlayer's mpeg seeking is hopeless.
could this be depending on how the mpeg is made?: the options given to mp1e? or
initialisation of ivtv driver in case of a wintv
250/350
>4. Since the timeshift process knows where the commercials are, it
>can display this in some way on the interface.
Within the blackframe detection logic is applied to how a blackframe gets interpreted:
max commercial lenght, ad_max_lenght.
>I haven't played with the commercial detection stuff, and in fact I've
>never used EDL at all, so the above makes some assumptions as to how it
>works. One issue I can think of right away is that there may be some
>delay when reacting to a black frame this way. I suppose a new
>RINGBUFFER_SET type could be defined to tell MPlayer "pause for further
>instructions when you reach frame XXXX."
>
>If you can send me your latest black frame detection patch, I'll see
>about working this up.
>
>Cheers,
>Jason.
The patch
I applied the patch according to the folowing procedure:
patch -p 0 < MPlayer-1.0pre4-leffakone.patch
> patching file MPlayer-1.0pre4/libmpcodecs/Makefile
> Hunk #1 FAILED at 14.
> 1 out of 1 hunk FAILED -- saving rejects to file
> MPlayer-1.0pre4/libmpcodecs/Makefile.rej
Edit MPlayer-1.0pre4/libmpcodecs/Makefile, find a line starting with
VFILTER_SRCS and add "vf_bfdetect.c" somewhere inside this line, without
breaking the line (i.e. dont let your text editor insert a linebreak).
> patching file MPlayer-1.0pre4/libmpcodecs/dec_video.c
> Hunk #2 succeeded at 327 (offset 5 lines).
> patching file MPlayer-1.0pre4/libmpcodecs/vf.c
> Hunk #1 succeeded at 45 with fuzz 1 (offset 2 lines).
> Hunk #2 succeeded at 123 (offset 9 lines).
> patching file MPlayer-1.0pre4/libmpcodecs/vf_bfdetect.c
> patching file MPlayer-1.0pre4/libvo/sub.c
> patching file MPlayer-1.0pre4/mencoder.c
> patching file MPlayer-1.0pre4/mplayer.c
> Hunk #1 FAILED at 83.
> 1 out of 1 hunk FAILED -- saving rejects to file
> MPlayer-1.0pre4/mplayer.c.rej
Edit MPlayer-1.0pre4/mplayer.c, find the place where there is
int verbose=0;
int identify=0;
static int quiet=0;
and add "int frameno = 0;" on the line after the "static int quiet=0;"
I also noticed that this patch changes the position of the time counter
in mplayer's OSD, so that it fits inside my TV, sorry for putting this
feature into the patch :( You can revert this by replacing
MPlayer-1.0pre4/libvo/sub.c with MPlayer-1.0pre4/libvo/sub.c.orig.
MPlayer-1.0pre4-leffakone.patch
Description: Binary data
