[FFmpeg-user] Growing file processing

[Bouke / VideoToolShed]

> On 02 Mar 2019, at 18:39, Moritz Barsnick <barsnick at gmx.net> 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
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
> 
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".