stopping ffmpeg correctly while piping

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

stopping ffmpeg correctly while piping

Dave Rice-3
Hi all,
With ffmpeg I’m trying to write a file from a device input while also piping out audiovisual data to a separate player. These commands replicate what I’m trying to do:

ffmpeg -f lavfi -i testsrc will_this_file_work.mov -f nut - | mpv -
ffmpeg -f lavfi -i testsrc will_this_file_work.mov -f nut - | ffplay -

When running these commands the video plays (in either ffplay or mpv). When I close the playback window to stop the player, then ffmpeg also stops, but with an invalid output. In this case the file will_this_file_work.mov will have no moov atom. Any suggestions on how to end this so that I can close the player to stop the process and have a valid file.

I notice that this works:

ffmpeg -f lavfi -i testsrc -f nut - | tee >(ffplay -) | ffmpeg -i - this_does_work.mov

but this requires two instances of ffmpeg.
Dave Rice

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: stopping ffmpeg correctly while piping

Moritz Barsnick
On Thu, Jan 11, 2018 at 09:25:53 -0500, Dave Rice wrote:
> When running these commands the video plays (in either ffplay or
> mpv). When I close the playback window to stop the player, then
> ffmpeg also stops, but with an invalid output. In this case the file
> will_this_file_work.mov will have no moov atom.

Interesting: ffmpeg doesn't close one output correctly, if the other
one fails? (I didn't double check, but that is an undesired limitation,
if you ask me. I'm not using the word "bug" yet. ;-))

> Any suggestions on how to end this so that I can close the player to
> stop the process and have a valid file.

If you can manage to use the "tee" muxer instead of two outputs, it has
the option "onfail" which should control this behavior:

    onfail
        Specify behaviour on output failure. This can be set to either
        abort (which is default) or ignore. abort will cause whole
        process to fail in case of failure on this slave output. ignore
        will ignore failure on this output, so other outputs will
        continue without being affected.

Note that your file will then just continue encoding, you would need to
terminate it separately with a signal or a keypress. I assume the file
would be correctly closed then (untested, as mentioned).


Hope this helps,
Moritz
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: stopping ffmpeg correctly while piping

Moritz Barsnick
On Thu, Jan 11, 2018 at 16:03:08 +0100, Moritz Barsnick wrote:
> Interesting: ffmpeg doesn't close one output correctly, if the other
> one fails? (I didn't double check, but that is an undesired limitation,
> if you ask me. I'm not using the word "bug" yet. ;-))

I just tested this with both testsrc2 and a streaming input on Windows,
and it just works there, the MOV file can be played by mplayer. I can't
test on Linux right now.

Moritz
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: stopping ffmpeg correctly while piping

Dave Rice-3
Hi Moritz,

> On Jan 11, 2018, at 10:19 AM, Moritz Barsnick <[hidden email]> wrote:
>
> On Thu, Jan 11, 2018 at 16:03:08 +0100, Moritz Barsnick wrote:
>> Interesting: ffmpeg doesn't close one output correctly, if the other
>> one fails? (I didn't double check, but that is an undesired limitation,
>> if you ask me. I'm not using the word "bug" yet. ;-))
>
> I just tested this with both testsrc2 and a streaming input on Windows,
> and it just works there, the MOV file can be played by mplayer. I can't
> test on Linux right now.

Could you share the working command you used?

Thanks for pointing out the tee muxer, I haven’t tried it before.

When I run:
ffmpeg -y -f lavfi -i testsrc -filter_complex vflip -c:v rawvideo -f tee "[f=mov:onfail=ignore]will_this_work.mov|[f=nut:onfail=ignore]pipe:1" | ffplay -
or switch the order via:
ffmpeg -y -f lavfi -i testsrc -filter_complex vflip -c:v rawvideo -f tee "[f=nut:onfail=ignore]pipe:1|[f=mov:onfail=ignore]will_this_work.mov" | ffplay -

and then close the ffplay window, ffmpeg stops, and will_this_work.mov still contains no moov atom.

Separate issue with the above command, but if I don’t include a filter_complex then I get an error:
Output file #0 does not contain any stream
pipe:: Invalid data found when processing input

Thanks much,
Dave Rice
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: stopping ffmpeg correctly while piping

Moritz Barsnick
On Thu, Jan 11, 2018 at 10:56:13 -0500, Dave Rice wrote:
> Could you share the working command you used?

I'm sure it was
$ ffmpeg -report -f lavfi -i testsrc2 -f nut - test.mov -y | ffplay -

That was at work, under Windows. Now I'm at home, and "all" I have
access to is Linux. And here, I can reproduce your issue. Even using
"-loglevel debug", ffmpeg doesn't say anything about closing its files,
unlike it did under Windows. Its log just stops right in it:

[libx264 @ 0x14a0020] frame=  83 QP=29.90 NAL=2 Slice:B Poc:166 I:4    P:114  SKIP:170  size=1524 bytes
[rawvideo @ 0x1490040] PACKET SIZE: 115200, STRIDE: 480
[libx264 @ 0x14a0020] frame=  84 QP=26.50 NAL=0 Slice:B Poc:164 I:2    P:98   SKIP:198  size=995 bytes
[rawvideo @ 0x1490040] PACKET SIZE: 115200, STRIDE: 480

So apparently, ffmpeg is getting some different signal under Linux,
and/or handling it differently.

> ffmpeg -y -f lavfi -i testsrc -filter_complex vflip -c:v rawvideo -f tee "[f=mov:onfail=ignore]will_this_work.mov|[f=nut:onfail=ignore]pipe:1" | ffplay -
> Separate issue with the above command, but if I don’t include a filter_complex then I get an error:
> Output file #0 does not contain any stream
> pipe:: Invalid data found when processing input

Apparently, this requires you to explicitly map something ("-map 0"). I
don't recall why, and why not with a filter involved. Too lazy to
contemplate. *shrug*

Moritz
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: stopping ffmpeg correctly while piping

Gyan Doshi

On 1/12/2018 12:14 AM, Moritz Barsnick wrote:
>
> Apparently, this requires you to explicitly map something ("-map 0"). I
> don't recall why, and why not with a filter involved. Too lazy to
> contemplate. *shrug*

My guess is, in absence of map, ffmpeg auto-selects streams for output
based on what the muxer accepts i.e. image2 muxer won't accept audio.
But the tee muxer isn't an actual format and the child muxers aren't
"seen" when configuring output streams, so map is required. And all
filtergraph output sinks are automatically designated for output,
regardless of muxer. This doesn't apply to simple filterchains (vf/af)
which act on - expressly or implicitly - mapped streams.

Regards,
Gyan
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: stopping ffmpeg correctly while piping

Nicolas George
In reply to this post by Moritz Barsnick
Moritz Barsnick (2018-01-11):
> So apparently, ffmpeg is getting some different signal under Linux,
> and/or handling it differently.

SIGPIPE, obviously.

Regards,

--
  Nicolas George

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: stopping ffmpeg correctly while piping

Moritz Barsnick
On Thu, Jan 11, 2018 at 21:11:55 +0100, Nicolas George wrote:
> > So apparently, ffmpeg is getting some different signal under Linux,
> > and/or handling it differently.
>
> SIGPIPE, obviously.

It was originally obvious to me. Except that I don't get what Windows
does differently. But I never engaged with Windows stuff anyway, I'm
Unix.

It wasn't obvious to me, as my addition of a SIGPIPE handler didn't
work. But now it does. Hmm:

Exiting normally, received signal 13.

Nice. Nicolas, do you think adding

    signal(SIGPIPE, sigterm_handler); /* Termination (pipe closed).  */

to ffmpeg.c would be accepted as a patch? I don't know all the
implications, it might be worth a review therefore.

Thanks,
Moritz
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: stopping ffmpeg correctly while piping

Dave Rice-3

> On Jan 11, 2018, at 3:40 PM, Moritz Barsnick <[hidden email]> wrote:
>
> On Thu, Jan 11, 2018 at 21:11:55 +0100, Nicolas George wrote:
>>> So apparently, ffmpeg is getting some different signal under Linux,
>>> and/or handling it differently.
>>
>> SIGPIPE, obviously.
>
> It was originally obvious to me. Except that I don't get what Windows
> does differently. But I never engaged with Windows stuff anyway, I'm
> Unix.
>
> It wasn't obvious to me, as my addition of a SIGPIPE handler didn't
> work. But now it does. Hmm:
>
> Exiting normally, received signal 13.
>
> Nice. Nicolas, do you think adding
>
>    signal(SIGPIPE, sigterm_handler); /* Termination (pipe closed).  */
>
> to ffmpeg.c would be accepted as a patch? I don't know all the
> implications, it might be worth a review therefore.

That solution works for me.
Dave

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".