will mplayer do a 3:2 pulldown on 24 fps video when ofps=29.97?
I have just read through the discussion(s) regarding the reverse telecine filter that Richard is working on. This is cool. But it brings up an issue. In general, reverse telecineing hard telecined material and the ofps adjustment that is done for soft telecined materal are good, if for nothing else, bitrate savings. But what if my output device has a fixed display rate, like a television for instance? I would in that case, when playing back the 24fps material, want to display it with a 3:2 pulldown. Can MPlayer do this (yet)? This need for a 3:2 pulldown on 24fps material almost needs to be automatically detected and employed though. I could have serveral files I want to play, some that really are (recorded at) 59.94 fields/s and some that are 24 frames/s. I don't want to have to manually inspect each file prior to playing it to see if I need to enable (i.e. with command line switches) the 3:2 pulldown. It could be perhaps that if -ofps=29.97[1] and the input is 24 frames/s, 3:2 pulldown is automatically enabled. [1] or even better, an mnemonic like "ntsc" (-ofps=ntsc) so that one could play 24 frames/s video at 29.97 without 3:2 pulldown by specfying 29.97 rather than the "ntsc" mnemonic) Thots? b. -- Brian J. Murrell
On Thu, Feb 20, 2003 at 04:51:22PM -0500, mplayer@interlinx.bc.ca wrote:
24fps material, want to display it with a 3:2 pulldown. Can MPlayer do this (yet)?
Check CVS. I believe I saw some code for that.
This need for a 3:2 pulldown on 24fps material almost needs to be automatically detected and employed though.
I don't think detection is a problem. This is clearly marked in the mpeg headers -- that's how a hardware dvd player knows how to convert 24fps material. b.c.
On Thu, Feb 20, 2003 at 04:51:22PM -0500, mplayer@interlinx.bc.ca wrote:
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
I have just read through the discussion(s) regarding the reverse telecine filter that Richard is working on. This is cool. But it brings up an issue. In general, reverse telecineing hard telecined material and the ofps adjustment that is done for soft telecined materal are good, if for nothing else, bitrate savings.
But what if my output device has a fixed display rate, like a television for instance? I would in that case, when playing back the 24fps material, want to display it with a 3:2 pulldown. Can MPlayer do this (yet)?
This need for a 3:2 pulldown on 24fps material almost needs to be automatically detected and employed though. I could have serveral files I want to play, some that really are (recorded at) 59.94 fields/s and some that are 24 frames/s. I don't want to have to manually inspect each file prior to playing it to see if I need to enable (i.e. with command line switches) the 3:2 pulldown.
It could be perhaps that if -ofps=29.97[1] and the input is 24 frames/s, 3:2 pulldown is automatically enabled.
[1] or even better, an mnemonic like "ntsc" (-ofps=ntsc) so that one could play 24 frames/s video at 29.97 without 3:2 pulldown by specfying 29.97 rather than the "ntsc" mnemonic)
Thots?
It will not be automatic, since 99% of users do not want this ugliness. However, -vop telecine might do what you want. MPlayer does not officially support increasing the fps, but if you're using a -vo driver with vsync support (mga_vid) or DVB output, it'll probably work acceptably well. Personally, I think telecine is horribly evil and that displaying every 4th frame for twice as long looks better than showing two frames a whole 1/24 second apart at the same time... Eventually, mplayer probably will have a -ofps option like you describe. This will make it work with all -vo's, but you'll still need -vop telecine if you want telecine output. Rich
On Thu, Feb 20, 2003 at 02:03:19PM -0800, Brian Craft wrote:
Check CVS. I believe I saw some code for that.
Cool. It was in the last 2 or three VFs added. Is it a true 3:2 pulldown, or just a duplication of 1 in 4 frames? If you don't know, no matter, I will go look at the source.
I don't think detection is a problem.
No, indeed it's not. It's just a comparison between the fps of the video material and what the user has requested the ofps be. That is why I suggested a nice mnemonic to make it explicit that 3:2 pulldown should be used for 24 frames/s material rather than some mathematical based frame repeat rate (i.e. repeat 1 out of 4 frames).
This is clearly marked in the mpeg headers -- that's how a hardware dvd player knows how to convert 24fps material.
Right. But the hardware DVD player can assume the ofps. MPlayer cannot. -ofps=ntsc would tell it that the output is truely an NTSC televsion set. On Thu, Feb 20, 2003 at 05:21:30PM -0500, D Richard Felker III wrote:
It will not be automatic, since 99% of users do not want this ugliness.
No? It's what they are used to when converting 24 frames/s -> 59.94 fields/s.
However, -vop telecine might do what you want.
As Brian Croft has indicated. I will check the source for it and test it out to see if it's really 3:2 pulldown or just a duplicate frame in 4.
MPlayer does not officially support increasing the fps, but if you're using a -vo driver with vsync support (mga_vid) or DVB output,
I am. dfbmga. I don't think any patches have been sent to to support this, because to do it effectively you have to display and wait for vsync in a separate thread (or starve the demuxer/decoder thread) and we all know what A'rpi thinks of threads. In fact I have been meaning to bring up this issue here for a while. Maybe my next message... :-)
it'll probably work acceptably well.
I will give it a try.
Personally, I think telecine is horribly evil and that displaying every 4th frame for twice as long looks better than showing two frames a whole 1/24 second apart at the same time...
I guess this is where subjectivity comes into play.
Eventually, mplayer probably will have a -ofps option like you describe. This will make it work with all -vo's, but you'll still need -vop telecine if you want telecine output.
The only problem I have with having to specify -vop telecine is that I have to select when to use it depending on whether the video material is 24 frames/s or not. This sucks when you are using MPlayer in a PVR like project where material can be both 24 frames/s and 59.94 fields/s. If -vop telecine was smart enough to step out of the way when it's not needed (source material is already 59.94 fields/s) that would be fine though. b. -- Brian J. Murrell
On Thu, Feb 20, 2003 at 05:40:38PM -0500, mplayer@interlinx.bc.ca wrote:
I am. dfbmga. I don't think any patches have been sent to to support this, because to do it effectively you have to display and wait for vsync in a separate thread (or starve the demuxer/decoder thread) and we all know what A'rpi thinks of threads. In fact I have been meaning to bring up this issue here for a while. Maybe my next message...
Yeah, this really is an on-going problem. The xp fork is too far behind to be useful. It's unfortunate that threading wasn't maintained as a patch -- like other notable oss projects that were too intrusive or controversial (low latency patches, uml, etc.), it could have remained relevant that way.
material is 24 frames/s or not. This sucks when you are using MPlayer in a PVR like project where material can be both 24 frames/s and 59.94 fields/s.
I'm considering a digital projector for this purpose. Prices are comparable to hdtvs, they take up less room, they're easier to transport, and they're multisync. I don't really understand the appeal of televisions right now. It seems like the industry is lagging behind what you can do with a pc and a digital display. b.c.
On Thu, Feb 20, 2003 at 05:40:38PM -0500, mplayer@interlinx.bc.ca wrote:
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
On Thu, Feb 20, 2003 at 02:03:19PM -0800, Brian Craft wrote:
Check CVS. I believe I saw some code for that.
Cool. It was in the last 2 or three VFs added. Is it a true 3:2 pulldown, or just a duplication of 1 in 4 frames? If you don't know, no matter, I will go look at the source.
True 3:2 pulldown. Duplication would be totally pointless since you'd get that effect automatically with mplayer using no special options.
I don't think detection is a problem.
No, indeed it's not. It's just a comparison between the fps of the video material and what the user has requested the ofps be. That is why I suggested a nice mnemonic to make it explicit that 3:2 pulldown should be used for 24 frames/s material rather than some mathematical based frame repeat rate (i.e. repeat 1 out of 4 frames).
Telecine (3:2 pulldown) is total nonsense unless the display device is interlaced! And even then it's ugly, IMO.
On Thu, Feb 20, 2003 at 05:21:30PM -0500, D Richard Felker III wrote:
It will not be automatic, since 99% of users do not want this ugliness.
No? It's what they are used to when converting 24 frames/s -> 59.94 fields/s.
Most people aren't doing that. They're displaying 24 fps progressive movies on progressive monitors. If mplayer automatically did some telecine/interlacing crap to movies, it would be VERY annoying!
MPlayer does not officially support increasing the fps, but if you're using a -vo driver with vsync support (mga_vid) or DVB output,
I am. dfbmga. I don't think any patches have been sent to to support this, because to do it effectively you have to display and wait for vsync in a separate thread (or starve the demuxer/decoder thread) and we all know what A'rpi thinks of threads. In fact I have been meaning to bring up this issue here for a while. Maybe my next message... :-)
It has nothing to do with threads. Switching page at vblank is the responsibility of the video driver; however, most of them suck too much to do this. :( mga_vid will do it, and there's an api in the linux fbdev layer for "wait to apply these changes until vblank", but none of the fb drivers implement it. :(
Eventually, mplayer probably will have a -ofps option like you describe. This will make it work with all -vo's, but you'll still need -vop telecine if you want telecine output.
The only problem I have with having to specify -vop telecine is that I have to select when to use it depending on whether the video material is 24 frames/s or not. This sucks when you are using MPlayer in a PVR like project where material can be both 24 frames/s and 59.94 fields/s. If -vop telecine was smart enough to step out of the way when it's not needed (source material is already 59.94 fields/s) that would be fine though.
Video filters can't tell what the framerate is, and anyway, it's possible someone might want to use 3:2 pulldown for any 20% framerate increase, not just 23.976->29.97. For a PVR, you really should run mplayer -info or whatever in advance to get the stream parameters, then use these to configure the second run. There are plenty of other things like size/scaling you need to handle already I'm sure... Rich
On Thu, Feb 20, 2003 at 03:02:29PM -0800, Brian Craft wrote:
Yeah, this really is an on-going problem. The xp fork is too far behind to be useful.
I was thinking about taking a look at it again due to this problem, but maybe not.
It's unfortunate that threading wasn't maintained as a patch -- like other notable oss projects that were too intrusive or controversial (low latency patches, uml, etc.), it could have remained relevant that way.
I guess the problem was that it was so intrusive that keeping up with the mplayer moving target was difficult. But indeed, there are gains to threading to be sure. Like the case of dfbmga. It's possible to sync mplayer's processing of frames to the clock of the output device simply by having the vo driver wait for the vsync from the television/video card. But having it wait and having mplayer decode frames all in the same thread does not work on machines it should work on because too much of the needed decoding time is spend sleeping for the vsync interrupt.
I'm considering a digital projector for this purpose. Prices are comparable to hdtvs,
That means well out of my spending range then.
they take up less room, they're easier to transport, and they're multisync.
All very good reasons to buy one, if you have the budget for it.
I don't really understand the appeal of televisions right now.
They are ubiquitous and cheaper than projectors. Or are they? I dunno. I have not looked at the price of a decent projector lately.
It seems like the industry is lagging behind what you can do with a pc and a digital display.
True. But at a cost. Most of us already have TVs, hence 0 cost. On Thu, Feb 20, 2003 at 06:04:17PM -0500, D Richard Felker III wrote:
True 3:2 pulldown.
Excellent! I can't wait to inverse-telesync some recorded (mjpeg) 3:2 pulldown material and play it back to my television with the 3:2 pulldown filter. :-)
Duplication would be totally pointless since you'd get that effect automatically with mplayer using no special options.
Right.
Telecine (3:2 pulldown) is total nonsense unless the display device is interlaced!
Of course it is. But as I said in my original message at the start of this thread my output device was NTSC television. OK, I guess it could have been a progressive scan television, but I certainly would be in the minority based on that assumption.
And even then it's ugly, IMO.
Right. This is that subjective part I was talking about. Even if you think it's ugly, and that is your right, by all means, it's the established industry standard for playing 24 frames/s at 59.94 fields/s.
Most people aren't doing that.
Actually for certain values of "most people", yes most people are watching 3:2 pulldown where the source is 24 frames/s. Your definition of most people is MPlayer users in front of their computer monitors. My definition of most people is the entire North American home consumer market watching 24 frames/s material on their DVD players and televisions.
They're displaying 24 fps progressive movies on progressive monitors. If mplayer automatically did some telecine/interlacing crap to movies, it would be VERY annoying!
For computer geeks, yes. But as I said, my target is (a) television watching consumer(s). The latter sample of most people is much larger than the former.
It has nothing to do with threads. Switching page at vblank is the responsibility of the video driver; however, most of them suck too much to do this.
DirectFB with the G400 and Ville's CRTC2 work certainly does not. In fact I know of no other TV-Out solution (other than DVB) that works as well.
:( mga_vid will do it, and there's an api in the linux fbdev layer for "wait to apply these changes until vblank", but none of the fb drivers implement it. :(
Take another look at the matrox driver with DirectFB. But I do see your point about the vo driver not having to wait for the actual vsync. This may have been an intermediate step in dfbmga's driver, to maintain field parity. I will check with Ville again on it. His latest changes to DirectFB move the vsync waiting/field parity waiting stuff into DirectFB, so it may no longer be an issue.
Video filters can't tell what the framerate is, and anyway, it's possible someone might want to use 3:2 pulldown for any 20% framerate increase, not just 23.976->29.97.
Right. And somebody that does want to do that can specify -vop telecine. But what I am proposing is that mplayer see that -ofps was set to "ntsc" and then examine the input rate of the video. If it's 29.97 fps, do nothing, if it's 23.976, automatically insert the telecine filter.
For a PVR, you really should run mplayer -info or whatever in advance to get the stream parameters, then use these to configure the second run.
That is an idea, indeed. But having mplayer be more intuitive on it's own is a good thing. BTW: I couldn't seem to find (at first glance) an option to just get a stream's parameters. I will look deeper in a bit.
There are plenty of other things like size/scaling you need to handle already I'm sure...
Actually, I target the recording/encoding process to do as much of that work as possible. But again, you have a point. b. -- Brian J. Murrell
On Thu, Feb 20, 2003 at 07:47:58PM -0500, mplayer@interlinx.bc.ca wrote:
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
On Thu, Feb 20, 2003 at 03:02:29PM -0800, Brian Craft wrote:
Yeah, this really is an on-going problem. The xp fork is too far behind to be useful.
I was thinking about taking a look at it again due to this problem, but maybe not.
It's unfortunate that threading wasn't maintained as a patch -- like other notable oss projects that were too intrusive or controversial (low latency patches, uml, etc.), it could have remained relevant that way.
I guess the problem was that it was so intrusive that keeping up with the mplayer moving target was difficult. But indeed, there are gains to threading to be sure.
Like the case of dfbmga. It's possible to sync mplayer's processing of frames to the clock of the output device simply by having the vo driver wait for the vsync from the television/video card. But having it wait and having mplayer decode frames all in the same thread does not work on machines it should work on because too much of the needed decoding time is spend sleeping for the vsync interrupt.
Sleeping for vsync is a brain damaged approach. Instead, you should inform the video driver (which belongs in the kernel) which page you want selected next time vblank occurs, and the kernel should trap the interrupt and switch pages for you. (This of course requires triple buffering, but you need that for the threaded approach too.) mga_vid already does this. Like I've said, the api is in fbcon too, but it's not implemented by any drivers.
Video filters can't tell what the framerate is, and anyway, it's possible someone might want to use 3:2 pulldown for any 20% framerate increase, not just 23.976->29.97.
Right. And somebody that does want to do that can specify -vop telecine. But what I am proposing is that mplayer see that -ofps was set to "ntsc" and then examine the input rate of the video. If it's 29.97 fps, do nothing, if it's 23.976, automatically insert the telecine filter.
Hmm, on second thought, fps is probably a global variable... :| So, it should be possible to make a the telecine filter accept some sort of 'auto' parameter to control whether it auto-activates according to framerates. This definitely does not belong inside -ofps handling, though.
For a PVR, you really should run mplayer -info or whatever in advance to get the stream parameters, then use these to configure the second run.
That is an idea, indeed. But having mplayer be more intuitive on it's own is a good thing.
BTW: I couldn't seem to find (at first glance) an option to just get a stream's parameters. I will look deeper in a bit.
Ah, it's called -identify! Rich
On Fri, Feb 21, 2003 at 02:25:17AM -0500, D Richard Felker III wrote:
Hmm, on second thought, fps is probably a global variable... :|
So, it should be possible to make a the telecine filter accept some sort of 'auto' parameter to control whether it auto-activates according to framerates.
Now you are talking! :-)
This definitely does not belong inside -ofps handling, though.
If you don't use -ofps, how do you "auto" decide whether telecining needs to be done or not?
Ah, it's called -identify!
Ahhh. Yes indeed. Another question regarding the inverse telecine: Is it smart enough re-sync in the event that the telecine flow breaks? i.e. I have a stream that is telecined and I remove a chunk in the middle, but the chunk removed does not align with the 3:2 pulldown flow. Will detc figure that out? b. -- Brian J. Murrell
On Fri, Feb 21, 2003 at 05:13:33AM -0500, mplayer@interlinx.bc.ca wrote:
This definitely does not belong inside -ofps handling, though.
If you don't use -ofps, how do you "auto" decide whether telecining needs to be done or not?
Well the auto activation in -vop telecine could be based on the value of -ofps. I'm just saying that an option called -ofps should not in itself add filters. So far -ofps doesn't exist anyway.
Another question regarding the inverse telecine:
Is it smart enough re-sync in the event that the telecine flow breaks? i.e. I have a stream that is telecined and I remove a chunk in the middle, but the chunk removed does not align with the 3:2 pulldown flow. Will detc figure that out?
That's the whole idea. You should see the source material I designed it to work with... Rich
On Fri, Feb 21, 2003 at 11:07:49AM -0500, D Richard Felker III wrote:
Well the auto activation in -vop telecine could be based on the value of -ofps. I'm just saying that an option called -ofps should not in itself add filters.
So rather than having mplayer implicity put telecine into the video filter pipe, you prefer the user has to specify it, and it is just a NOOP if no 3:2 pulldown needs to be done to convert the input frame rate to the output frame rate (i.e. they are not the same or output is not 20% > input)? I can live with that.
So far -ofps doesn't exist anyway.
Right.
That's the whole idea. You should see the source material I designed it to work with...
:-) Just as a corner case, have you decided what you are going to do if you have two differently telecined images in the same frame? i.e. the broadcaster is sending an NTSC telecined stream but overlays (like PIP) another telecined image into the original, where the telecining patterns are not in sync. :-) b. -- Brian J. Murrell
On Fri, Feb 21, 2003 at 02:36:28PM -0500, mplayer@interlinx.bc.ca wrote:
Just as a corner case, have you decided what you are going to do if you have two differently telecined images in the same frame? i.e. the broadcaster is sending an NTSC telecined stream but overlays (like PIP) another telecined image into the original, where the telecining patterns are not in sync. :-)
Nope... Unfortunately something similar actually happens in the Lain DVDs I wrote detc for, but it's not quite so bad there, just a blend of progressive and telecine material in the same frames. My filter's still not working perfectly on them, so I just use -vop pp=lb,detc to blur out any remaining interlacing (usually only a couple frames) after removing what I can of the telecine. The output is acceptable, IMHO, but I'd still like to improve it. Any suggestions how? Rich
On Fri, Feb 21, 2003 at 04:57:16PM -0500, D Richard Felker III wrote:
Any suggestions how?
I'm afraid not. I don't think there is a solution (to the stream with mixed telecining). But you would know better than I. I am a newbie at all this video stuff. :-) b. -- Brian J. Murrell
On Thu, Feb 20, 2003 at 06:04:17PM -0500, D Richard Felker III wrote:
True 3:2 pulldown. Duplication would be totally pointless since you'd get that effect automatically with mplayer using no special options.
Is it supposed to actually "mangle" the 4th frame and insert a 5th frame, increasing the output framerate to 29.97 fps? What I am seeing is the first 3 frames come out "normal", and the 4th frame "interlaced" (presumably with frame 3, as per telecining, and then the 5th - 7th frame looking normal again with the 8th frame looking interlaced. So it seems like while it is combining different source frames to make interlaced frame 4, it is not inserting a new 5th frame interlaced from source frames 4 and 5. Is this because a vop cannot increase the output frame rate? If so, what use is the telecine vop anyway? I suppose it could be used to telecine during mencoding. But telecining during playback would be nice. But what happens to the audio in that case? Presumably it goes out of sync unless mplayer were to resample it if it was telecining a 24fps source up to 29.97fps. Am I correct? b. -- Brian J. Murrell
On Fri, Feb 21, 2003 at 08:36:34AM -0500, Brian J. Murrell wrote:
So it seems like while it is combining different source frames to make interlaced frame 4, it is not inserting a new 5th frame interlaced from source frames 4 and 5. Is this because a vop cannot increase the
Yes, and because your -vo sucks. With a vo that syncs to vertical retrace, you'll at least see the extra frame for one refresh period. If you're using DXR3, I would imagine you'd get nice smooth perfect 29.97 fps output.
output frame rate? If so, what use is the telecine vop anyway? I suppose it could be used to telecine during mencoding. But telecining during playback would be nice.
For use with mencoder -- RTFM. Actually I hate telecine, so the main use for me is to make telecined files for testing -vop detc. :) Yes, it would be nice if it worked during playback with all vo's, but for now that's a limitation of mplayer.
But what happens to the audio in that case? Presumably it goes out of sync unless mplayer were to resample it if it was telecining a 24fps source up to 29.97fps. Am I correct?
No. If you increase the framerate of your video from 23.976 to 29.97 fps while adding 20% more frames, the total length of the movie does not change at all, does it?? So why would audio be affected? There is an issue with audio if the original file is 24 fps and you want to make 29.97 fps output, but I've never seen an actual 24 fps file. When this (or 24->23.976) is done by professional studios, they just slightly decrease the rate at which audio is played. Rich
On Fri, Feb 21, 2003 at 11:15:21AM -0500, D Richard Felker III wrote:
Yes, and because your -vo sucks. With a vo that syncs to vertical retrace,
Perhaps we are not talking about the same thing. But I suspect we are. I am saying that dfbmga does (or rather can -- I dunno if it's in the official mplayer version of dfbmga or not) sync to vertical retrace. i.e. vo_dfbmga.c on my working mplayer here does a: vo_flags |= 0x100; in it's preinit(). And mplayer.c does this: //============================== SLEEP: =================================== time_frame/=playback_speed; // flag 256 means: libvo driver does its timing (dvb card) if(time_frame>0.001 && !(vo_flags&256)){ #ifdef HAVE_RTC if(rtc_fd>=0){ ... } else #endif { // -------- USLEEP + SOFTSLEEP ----------- ... } } If that's not what you mean by a vo driver syncing to vertical retrace, what do you mean?
you'll at least see the extra frame for one refresh period.
But if mplayer is only producing 4 frames where it should be producing 5 (3 reguarlar "progressive" frames plus two interlaced/telecined frames), then only 4 will display, no?
If you're using DXR3, I would imagine you'd get nice smooth perfect 29.97 fps output.
I am testing the 3:2 pulldown by using "-fps 1" on my workstation in an Xvideo window and counting the number of good looking frames vs. interlaced frames and it's 3 normal 2then 1 interlaced then 3 then 1...
Actually I hate telecine, so the main use for me is to make telecined files for testing -vop detc. :)
:-)
Yes, it would be nice if it worked during playback with all vo's, but for now that's a limitation of mplayer.
Right.
No. If you increase the framerate of your video from 23.976 to 29.97 fps while adding 20% more frames, the total length of the movie does not change at all, does it?? So why would audio be affected?
You are right of course. I had a brain fart and was thinking audio smaples were related to frames (i.e. 1 audio sample for 1 frame), not time slices. Of course 30 minutes of audio is 30 minutes of audio no matter how many slices you put it into. I will have to go back and do some testing again, where I was seeing serious a/v sync drift. b. -- Brian J. Murrell
On Fri, Feb 21, 2003 at 04:57:59PM -0500, mplayer@interlinx.bc.ca wrote:
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
On Fri, Feb 21, 2003 at 11:15:21AM -0500, D Richard Felker III wrote:
Yes, and because your -vo sucks. With a vo that syncs to vertical retrace,
Perhaps we are not talking about the same thing. But I suspect we are. I am saying that dfbmga does (or rather can -- I dunno if it's in the official mplayer version of dfbmga or not) sync to vertical retrace. i.e. vo_dfbmga.c on my working mplayer here does a:
vo_flags |= 0x100;
in it's preinit(). And mplayer.c does this:
//============================== SLEEP: ===================================
time_frame/=playback_speed;
// flag 256 means: libvo driver does its timing (dvb card) if(time_frame>0.001 && !(vo_flags&256)){
#ifdef HAVE_RTC if(rtc_fd>=0){ ... } else #endif { // -------- USLEEP + SOFTSLEEP ----------- ... }
}
If that's not what you mean by a vo driver syncing to vertical retrace, what do you mean?
I actually mean a more intelligent interrupt-based approach. I have no idea how dfb does it...
you'll at least see the extra frame for one refresh period.
But if mplayer is only producing 4 frames where it should be producing 5 (3 reguarlar "progressive" frames plus two interlaced/telecined frames), then only 4 will display, no?
It IS producing 5, but one of them is only 'visible' for maybe less than 5% of a refresh period.
If you're using DXR3, I would imagine you'd get nice smooth perfect 29.97 fps output.
I am testing the 3:2 pulldown by using "-fps 1" on my workstation in an Xvideo window and counting the number of good looking frames vs. interlaced frames and it's 3 normal 2then 1 interlaced then 3 then 1...
-fps 1 will not do ANYTHING to help you see the extra frame, since it controls the rate at which mplayer decodes them, not the rate at which they get displayed. vf_telecine calls vf_next_put_image twice in a row, with NO DELAY in between, since it can't control the delay. Only if the vo driver somehow prevents the second frame from being displayed immediately after the first will you see two frames! In short, you CANNOT test vf_telecine with mplayer unless you use -vo (x)mga or a hardware mpeg board! Use mencoder instead (or perhaps -vo mpegpes). Rich
D Richard Felker III wrote:
Rich Anyway, what's the 'D' in your name? And the 'III'? :)
-- Gabucino MPlayer Core Team - Debian? - "This is our project and we can do whatever we want with it." Michael Stone <mstone#debian.org>
On Sun, Feb 23, 2003 at 09:20:03AM +0100, Gabucino wrote:
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
D Richard Felker III wrote:
Rich Anyway, what's the 'D' in your name? And the 'III'? :) Dunno, what could be "D", but "III" is imho "third". You know, His father and grandfather were Richards Felkers too.
_______________________________________________ RTFM!!! http://www.MPlayerHQ.hu/DOCS Search: http://www.MPlayerHQ.hu/cgi-bin/htsearch http://mplayerhq.hu/mailman/listinfo/mplayer-users
-- --- Bartek Stalewski <werbat@irc.pl>; IRC: chrumpak on #lublin && #unixpl --- --- "Ja jestem typem skurwysyna, którego kochasz nienawidzić" ---
participants (6)
-
Bartek Stalewski -
Brian Craft -
Brian J. Murrell -
D Richard Felker III -
Gabucino -
mplayer＠interlinx.bc.ca