[MPlayer-dev-eng] Re: [PATCH] softpulldown

[Tobias Diedrich]

Arpi wrote:

> > This patch adds a 'softpulldown' video filter. It uses the mpeg2 video
> > header information to make 29.97 fps out of 23.976 fps softtelecined
> > material. This should help especially for dvds which are partly
> > softtelecined.
> 
> Uhh.

Because you can do -vf softpulldown,detc and the detelecine filter
should work better.
In my case I needed it because I wanted to do a field by field compare
of two episodes of the Sailor Moon DVD Box where one episode is partly
soft telecined and the other is completely hard telecined.
(See http://www.sim.uni-hannover.de/~td/smdiff.html)

> > Before I commit it I'd like to know if the way I added the needed flags
> > to mp_image_t is ok.
> 
> Looks ok.

Good :-)

> > BTW, while developing this I noticed that libmpdemux/mpeg_hdr.c does
> > use the data in stream order and does no reordering, which means that
> > the display_time adjustments are often made for the wrong frame.
> 
> mpeg PTS reodrering is done in video.c

Hmm, I see that it does some funky thing to sh_video->pts, but what I
meant was the frame_time value, used in mplayer.c around line 1990:

current_module="video_read_frame";
in_size=video_read_frame(sh_video,&next_frame_time,&start,force_fps);
if(in_size<0){ eof=1; break; }
if(in_size>max_framesize) max_framesize=in_size; // stats
sh_video->timer+=frame_time;
if(sh_audio) sh_audio->delay-=frame_time;
time_frame+=frame_time;  // for nosound

If I have a sequence of frames like the following
(s=short (repeat_first_field not set), l=long (repeat_first_field set)):

slslslslslslslsl
IBBPBBPBBPBBPBBI

It is encoded in the following order in the bitstream:

sllssslllsssllls
IPBBPBBPBBPBBIBB

And if I insert a printf in there I see the latter pattern (well, until
telecine detection kicks in, so it probably really doesn't matter).

> > Two other things I noticed:
> > 1) In mplayer.c, VOCTRL_DUPLICATE_FRAME is only called if
> >    vo_config_count>0, but vo_config_count is not increased by the
> >    yuv4mpeg output plugin.
> 
> it's increased by (and ONLY by) vf_vo.c

Ok I missed that because I only grepped in libvo...
However grepping shows that vo_xvidix and vo_xover increase it
themselves at the end of their config function.

> > 2) This filter does not work properly with vo_yuv4mpeg because
> >    it supports slices and only writes a frame on flip_page.
> >    AFAICS there is no big benefit to slices support in vo_yuv4mpeg
> >    (As far as I understand it slices are needed for direct rendering),
> >    so would it be ok to disable slices support of vo_yuv4mpeg?
> 
> no!
> 
> i don't understand how slices are related to your filter?
> if your filter doesn't support slices, things still should work, vf_vo.c
> does handle this case.

The thing is that I sometimes call vf_next_put_frame twice in my
put_frame function and vo_yuv4mpeg still only outputs one frame because
even though for each call to vf_next_put_frame there is one call to
draw_slice, only one call to flip_page is made for each call of my
put_frame function.

-- 
Tobias						PGP: http://9ac7e0bc.2ya.com
This mail is made of 100% recycled bits
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20030803/1f8a7e4e/attachment.pgp>