On Fri, 3 Mar 2017 14:21:37 +0100 Michael Niedermayer <mich...@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 <mich...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
