On Sun, Apr 4, 2010 at 7:23 PM, Stefano Sabatini <[email protected]> wrote: > On date Sunday 2010-04-04 16:16:28 -0400, Brandon Mintern encoded: >> On Thu, Apr 1, 2010 at 9:03 AM, Stefano Sabatini >> <[email protected]> wrote: >> > On date Wednesday 2010-03-31 20:06:17 -0400, Brandon Mintern encoded: >> >> Thanks a lot for the feedback. A new, much cleaner (and actually >> >> similar to what I wrote on my first try before changing it to what you >> >> saw) patch is at the bottom of this post. I still can't see why the >> >> 2nd input is not being output; it seems like everything should be >> >> getting properly propagated. >> > >> > You need to shift the PTSes of the second source, something of the >> > kind: >> > pts += last_pts_of_first_source; >> >> I tried to do this in start_frame: >> >> static void start_frame(AVFilterLink *link, AVFilterPicRef *picref) >> { >> ConcatenateContext *con = link->dst->priv; >> >> if (con->first_input_consumed) >> picref->pts += con->first_input_last_pts; >> else >> con->first_input_last_pts = picref->pts; >> >> avfilter_null_start_frame(link, picref); >> } [snip] > I don't know how are you testing this, but I suppose you're using > ffplay to test this. > > In order to understand what's going on you need to understand the > threading model used by ffplay (hint: from gdb use thread apply all > bt). > > The problem here looks like that when the decode thread stops to > process packets, it doesn't send anymore packets to the queue where it > is waiting the video thread. > > So the video thread doesn't have a way to signal to the filterchain > that the input source ended, and ffplay will simply stop to play the > video. > > Yes maybe this should be fixed in ffplay, patches are welcome of > course :-).
Here is a sample usage: ./ffmpeg_g -y -i input1.wmv -vfilters "movie=0:wmv3:input2.wmv [in2]; [in][in2] concatenate" -r 15 out.wmv I really don't know much about ffmpeg/vfilters at all. I am trying my best to understand it, but I'm clearly missing something. I thought that in this case, the output end of the filter chain would call concatenate's request_frame until it got a nonzero return value. concatenate then propagates the request_frame back either to the input end of the filter chain or to the movie filter (based on how I wrote concatenate). Either way, I was under the understanding that start_frame calls are then propagated forward from the beginning, followed by get_video_buffer, draw_slice, end_frame, and all that other good stuff. So to me, it obviously is not making sense that [in2] is never being processed at all. For me, the point of this filter is to avoid temporarily storing processed segments of video to the filesystem. I was hoping to do a whole bunch of processing (overlay, scale, fade, etc.) to produce a title sequence, and then prepend that title sequence to a long video. If I can't make this work (and it seems like I can't), then I guess I'll just have to write the title sequence out and make a second call to ffmpeg in order to put the two pieces together. Thanks for your bits of assistance, Brandon _______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
