[FFmpeg-devel] [PATCH] VFW capture support

[Michael Niedermayer]

On Wed, Mar 05, 2008 at 03:42:58PM -0300, Ramiro Polla wrote:
> Hello Michael,
> 
> Michael Niedermayer wrote:
> > On Mon, Mar 03, 2008 at 01:59:03PM -0300, Ramiro Polla wrote:
> > [...]
> >> static LRESULT CALLBACK FrameCallbackProc( HWND hwnd, LPVIDEOHDR vdhdr )
> >> {
> >>     struct vfw_ctx *ctx;
> >>     AVPacket *pkt;
> >>
> >>     ctx = (struct vfw_ctx *) SendMessage( hwnd, WM_CAP_GET_USER_DATA, 0, 0 );
> >>     if( !ctx )
> >>         return FALSE;
> >>
> >>     pkt = ctx->pkt;
> >>
> >>     if( av_new_packet( pkt, vdhdr->dwBytesUsed ) < 0 )
> >>         return FALSE;
> >>
> >>     pkt->pts = GetTickCount( );
> > 
> > Doesnt vfw provide some timestamp for each frame?
> 
> The timestamps returned are incredibly unreliable (if returned at all, 
> most times I just get 0x00000000).

Could you give me a hint of how they are returned, so i can check the docs
from M$ ?
Use of "get current time" is very problematic as frames will have very
inaccuarte timestamps.
Thus if that is the only kind of time you can get from VFW then i fear
you will need to clean them up somehow so that they are at least stable
to +- 1ms of the nominal frame rate of the video source.


> 
> > [...]
> >>     if( s->flags & AVFMT_FLAG_NONBLOCK ) {
> >>         av_log( s, AV_LOG_ERROR, "Non blocking capture not yet implemented.\n" );
> >>         return AVERROR_PATCHWELCOME;
> >>     }
> > 
> > where is the problem with that?
> 
> I thought we didn't want FFmpeg to block unless the user specifies 
> AVFMT_FLAG_NONBLOCK. Isn't that the purpose of the flag?

Yes, what i was asking, is where the problem is with implementing support
for AVFMT_FLAG_NONBLOCK?


> 
> > [...]
> >> static int vfw_read_packet( AVFormatContext *s, AVPacket *pkt )
> >> {
> >>     struct vfw_ctx *ctx = s->priv_data;
> >>     int ret;
> >>
> >>     ctx->pkt = pkt;
> >>     ctx->grabbed = 0;
> >>
> >>     ret = SendMessage( ctx->hwnd, WM_CAP_GRAB_FRAME, 0, 0 );
> >>     if( !ret || !ctx->grabbed )
> >>         return AVERROR_IO;
> >>
> > 
> > Hmm, cant the grabbing of the next frame be activated before returning?
> > If no, then i think this has to be run in a seprate thread to work
> > reliable.
> 
> IMHO, I think every indev should only start capturing when read_packet 
> is called. So that, for example, I could have an app that only calls 
> read_packet on an indev when some external event occurs, and it won't 
> end up with last minute's image.

Thats a very odd excuse ...
Anyway theres read_play() and read_pause() if you really want that, we
also could discuss adding a flag to change behavior for such single frame
capture.

But default should be normal video capture which is what 99.9% of the users
will use it for.

Also can this patch do full framerate(30/25fps 50/60fields/sec) / full
resolution realtime capture and encoding in realtime with audio? If not
its definitly not well implemented.
Also does VFW buffer frames? If no then a seperate thread is pretty much
required for video capture. OTOH if it does buffer frames then the way
you generate timestamps is just wrong.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080305/b1b54e2e/attachment.pgp>