[FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

[wm4]

On Fri, 3 Mar 2017 14:21:37 +0100
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Fri, Mar 03, 2017 at 09:53:17AM +0100, wm4 wrote:
> > On Thu, 2 Mar 2017 20:31:53 +0100
> > Michael Niedermayer <michael at niedermayer.cc> wrote:  
> [...]
> 
> > 
> > You seem to do everything to slow them down. Or that's what it looked
> > like to me.  
> 
> I just test the code and report bugs.
> 
> also this is not new, i tested the code similarly when i did the merges
> long ago ...
> 
> also theres something else i keep wondering about and thats
> for example in this case here many people wanted
> this patchset and it was a gigantic amount of work you did to get it
> working and i belive others also helped and its not completely finished
> yet, users will find bugs noone of us thoight of to test for.
> Isnt it easier considering we have so many developers interrested in
> this kind of refactoring that we do this ourselfs on ffmpeg
> at some point in the future ?

People were just going to throw hacks on it (see how the qsv and cuvid
code turned out, or what people do to get a full-hwaccel pipeline going
with ffmpeg.c). Libav did the work, isn't it logical to take it?

> And yes thats a question iam not implying that i prefer such step or
> prefer the opposite. I cannot even have such preferrance as i did not
> look at some of the patches here, i just tested them and you know
> how many issues the code had
> 
> 
> > 
> > Anyway, I've pushed the patches now, with some local modifications.
> > I've had this sitting on my mind for 3 weeks or so, and now someone
> > wants to get my push rights revoked, so I'll leave it to others to fix
> > the final regressions. Sorry to sound like a dick again, but I'm done
> > here.  
> 
> the patches break this:
> ./ffmpeg -itsoffset 2 -re -i ~/videos/matrixbench_mpeg2.mpg -vcodec h263 -s cif -an  -t 3 -f rtp rtp://127.0.0.1:19955 >h263.sdp </dev/null & sleep 1 ; ./ffmpeg -protocol_whitelist file,rtp,udp -i h263.sdp -y  -t 0.9 out-h263.avi
> 
> It appears that h263.sdp is written later than previously
> and the sdp is needed at the receiving side so this might
> impact some real users
> 
> the example above works with a sleep 2 instead of sleep 1
> 
> [...]

Then use a sleep 2 instead of sleep 1. There, fixed.