you can always just timestamp each text file so it writes a new file on each
iteration of ffmpeg running
out.mp4 2> $(date +%Y-%m-%d_%H-%M-%S).txt
> On Jun 4, 2018, at 5:48 57PM, Sana Tafleen wrote:
>
> What I am trying to achieve here is to get the number of I,P and B frames
> at the end of
I understand now that there is no new ffmpeg process starting. But I do
have one doubt, is there any possibility that the P or B frames may be
converted to one another during encoding process? Because I find the same
total number of frames at both ends, but the number of P and B frames
differ.
R
What I am trying to achieve here is to get the number of I,P and B frames
at the end of streaming. When the disconnection happens, the ffmpeg process
at the sender stops at the terminal and when I connect it back, it starts
sending the frames. Doing this, the number of frames at the receiver is
hig
On Mon, Jun 4, 2018 at 6:36 PM, robertlazarski
wrote:
>
>
> On Mon, Jun 4, 2018 at 6:06 PM, Sana Tafleen
> wrote:
>
> I would not expect ffmpeg to create a new process in that loop but I have
> no experience with mpegts. I would try -stdin since I have seen unexpected
> behavior without it in lo
On Mon, Jun 4, 2018 at 6:06 PM, Sana Tafleen wrote:
> Hello,
>
> I am sending a UDP stream to the destination and saving the contents of the
> FFMPEG output to a text file. I run the ffmpeg command in a loop as
> follows,
>
>
> while :
> do
> echo `ffmpeg -hide_banner -f v4l2 -i /dev/video0
Hello,
I am sending a UDP stream to the destination and saving the contents of the
FFMPEG output to a text file. I run the ffmpeg command in a loop as follows,
while :
do
echo `ffmpeg -hide_banner -f v4l2 -i /dev/video0 -c:v libx264 -f
mpegts tcp://ip:port -c:v libx264 /path/to/.mp4 2> out