> On 02 Mar 2019, at 18:39, Moritz Barsnick <[email protected]> wrote: > > On Sat, Mar 02, 2019 at 11:02:03 +0100, Bouke / VideoToolShed wrote: >> Next, it is dog slow, sorta kinda defeating the whole idea. > > I thought the whole point was that the "receiving" ffmpeg was too fast, > in relation to the processing "speed" of the sending ffmpeg. And that > the "receiving" side needed a chance not to exit on EOF.
Hi Moritz, Sorry for the late reply, just after testing this my laptop (where I performed the tests and have my e-mail) crashed, and my backup mail machine decided not to play anymore also, I reverted to webmail, and missed some stuff here and there. (One of my accounts bounces a lot of mails from the FF list for some reason.) I understood the original idea, and my tests as done were based on an actual existing input file, to see what happened with speed. > The tail "pipe" shouldn't slow anything down, except that there's the > disk R/W I/O involved. Thus, sadly, not on my system... > There could be a minor issue in "tail" processing in text mode, > buffered line by line. You will find references online to a "bintail", > but I am otherwise at a loss of tools which can ignore EOF. Named pipes > as am alternative probably also transfer EOF. That could have been my issue, I’ve only toyed with ‘tail’ > >> (Since the data is piped at a speed that FFmpeg will never be able to >> catch up with the original…) > > Huh? Gregor wrote: >> 2 - Growing file generation slower than processing >> ffmpeg.exe -i input.mxf growing.mkv >> ffmpeg.exe -i growing.mkv -c copy output.mkv >>> ffmpeg stops when it reaches the current end of the growing file. >>> >>> > > So Bouke, what's to catch up? Did you misread the original poster's > request? Again, no, I did not, but again, the Tail output seemed slow... > >> bouke$ ffmpeg -i /Users/bouke/Desktop/Judith/Harding.mxf -an -s 120x40 -t >> 15 -y /Users/bouke/Desktop/Judith/test.mp4 > > You may have overlooked that /Users/bouke/Desktop/Judith/Harding.mxf is > being created at a slower speed, and not an existing finalized file. Nope, it was finished :-) > >> Stream #0:0 -> #0:0 (mpeg2video (native) -> mpeg4 (native)) >> Press [q] to stop, [?] for help >> frame= 375 fps=136 q=2.0 Lsize= 365kB time=00:00:15.00 bitrate= >> 199.6kbits/s >> video:363kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB >> muxing overhead: 0.674411% >> >> vs >> bouke$ tail -c +1 -F /Users/bouke/Desktop/Judith/Harding.mxf | ffmpeg -i - >> -an -s 120x40 -t 15 -y /Users/bouke/Desktop/Judith/test.mp4 >> Stream #0:0 -> #0:0 (mpeg2video (native) -> mpeg4 (native)) >> frame= 375 fps= 28 q=2.0 Lsize= 365kB time=00:00:15.00 bitrate= >> 199.5kbits/s dup=1 drop=0 >> video:363kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB >> muxing overhead: 0.674757% > > 28 vs 136 fps is certainly peculiar. Let’s blame it on not using Bintail, but… On 02-03-2019 09:57 PM, Marton Balint wrote: > > Another approach is to use -rw_timeout 1000000 and -follow 1 options. is a very elegant solution, so no need to investigate further! But, thanks, you’re always very helpful! Bouke > > Moritz > _______________________________________________ > ffmpeg-user mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
