| Message ID | 20180228122505.30632-1-midicase@gmail.com |
|---|---|
| State | New |
| Headers | show |
On Wed, 28 Feb 2018, Mike Goins wrote: > Signed-off-by: Mike Goins <midicase@gmail.com> > --- > doc/outdevs.texi | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/doc/outdevs.texi b/doc/outdevs.texi > index daf7b1ae62..1ca81ba139 100644 > --- a/doc/outdevs.texi > +++ b/doc/outdevs.texi > @@ -180,6 +180,13 @@ Play video clip with non-standard framerate or video size: > ffmpeg -i test.avi -f decklink -pix_fmt uyvy422 -s 720x486 -r 24000/1001 'DeckLink Mini Monitor' > @end example > > +@item > +Signal Generator mode: > +@example > +ffmpeg -re -f lavfi -i "testsrc=s=1920x1080:rate=30000/1000" -f lavfi -i "sine=frequency=1000:sample_rate=48000" > + -ac 2 -acodec pcm_s16le -pix_fmt uyvy422 -format_code Hi30 -f decklink 'DeckLink Studio 2' You should not need the -re flag, the decklink outdev blocks if it gets too many frames and because of this the "encoding" speed should be limited to realtime even without -re. Or you see something different? Thanks, Marton
>> +ffmpeg -re -f lavfi -i "testsrc=s=1920x1080:rate=30000/1000" -f lavfi -i "sine=frequency=1000:sample_rate=48000" + -ac 2 -acodec pcm_s16le -pix_fmt uyvy422 -format_code Hi30 -f decklink 'DeckLink Studio 2' > > You should not need the -re flag, the decklink outdev blocks if it gets too many frames and because of this the "encoding" speed should be limited to realtime even without -re. Or you see something different? Also, isn’t -format_code a capture parameter? Is it even valid to provide that on output? I had plans to add support for -format_code for output - if it’s already working then that’s great. Devin
On Fri, 9 Mar 2018, Devin Heitmueller wrote: > >>> +ffmpeg -re -f lavfi -i "testsrc=s=1920x1080:rate=30000/1000" -f lavfi -i "sine=frequency=1000:sample_rate=48000" + -ac 2 -acodec pcm_s16le -pix_fmt uyvy422 -format_code Hi30 -f decklink 'DeckLink Studio 2' >> >> You should not need the -re flag, the decklink outdev blocks if it gets too many frames and because of this the "encoding" speed should be limited to realtime even without -re. Or you see something different? > > Also, isn’t -format_code a capture parameter? Is it even valid to provide that on output? Yes, it is capture only indeed. Wonder why does ffmpeg accept it in the first place? > > I had plans to add support for -format_code for output - if it’s already working then that’s great. The decklink outdev finds the correct mode by searching for the properties (frame rate, field order, dimension) of the stream which is provided to it. So specifying the format_code should not be needed. Regards, Marton
> The decklink outdev finds the correct mode by searching for the properties > (frame rate, field order, dimension) of the stream which is provided to it. > So specifying the format_code should not be needed. In principle you are correct that it "should not be needed". However there are numerous cases where the heuristic that chooses the output format may do dumb things. This is particularly the case when dealing with interlaced modes (where it might for example pick 1080/30psf instead of 1080i/59). I've got a list of bugs in that area that need attention, but even with those fixes I want to be able to force the format in an emergency. It's on my TODO list. Devin
On Fri, Mar 9, 2018 at 3:38 PM, Devin Heitmueller <dheitmueller@ltnglobal.com> wrote: > >>> +ffmpeg -re -f lavfi -i "testsrc=s=1920x1080:rate=30000/1000" -f lavfi -i "sine=frequency=1000:sample_rate=48000" + -ac 2 -acodec pcm_s16le -pix_fmt uyvy422 -format_code Hi30 -f decklink 'DeckLink Studio 2' >> >> You should not need the -re flag, the decklink outdev blocks if it gets too many frames and because of this the "encoding" speed should be limited to realtime even without -re. Or you see something different? If don't use -re I get an average of ~31 fps and speed 1.03x, but with -re the status stays at 30 fps and 1x. No idea why the difference. > Also, isn’t -format_code a capture parameter? Is it even valid to provide that on output? > > I had plans to add support for -format_code for output - if it’s already working then that’s great. You are right, -format_code does not appear to do anything for the output. > Devin > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
2018-03-09 21:58 GMT+01:00, Marton Balint <cus@passwd.hu>: > > On Fri, 9 Mar 2018, Devin Heitmueller wrote: >> Also, isn’t -format_code a capture parameter? Is it even valid >> to provide that on output? > > Yes, it is capture only indeed. Wonder why does ffmpeg > accept it in the first place? Output options are not (cannot?) be validated, this is also discussed in several tickets. Carl Eugen
On Thu, 15 Mar 2018, Mike Goins wrote: > On Fri, Mar 9, 2018 at 3:38 PM, Devin Heitmueller > <dheitmueller@ltnglobal.com> wrote: >> >>>> +ffmpeg -re -f lavfi -i "testsrc=s=1920x1080:rate=30000/1000" -f lavfi -i "sine=frequency=1000:sample_rate=48000" + -ac 2 -acodec pcm_s16le -pix_fmt uyvy422 -format_code Hi30 -f decklink 'DeckLink Studio 2' >>> >>> You should not need the -re flag, the decklink outdev blocks if it gets too many frames and because of this the "encoding" speed should be limited to realtime even without -re. Or you see something different? > > If don't use -re I get an average of ~31 fps and speed 1.03x, but with > -re the status stays at 30 fps and 1x. No idea why the difference. I'd say that is due to the initial buffering, it should smooth out to 1.000 in time. So I'd avoid -re because it depends on the local computer clock. Regards, Marton
On Thu, 15 Mar 2018, Carl Eugen Hoyos wrote: > 2018-03-09 21:58 GMT+01:00, Marton Balint <cus@passwd.hu>: >> >> On Fri, 9 Mar 2018, Devin Heitmueller wrote: > >>> Also, isn’t -format_code a capture parameter? Is it even valid >>> to provide that on output? >> >> Yes, it is capture only indeed. Wonder why does ffmpeg >> accept it in the first place? > > Output options are not (cannot?) be validated, this is also discussed > in several tickets. Can you point me to the tickets? Thanks, Marton
2018-03-15 15:39 GMT+01:00, Marton Balint <cus@passwd.hu>: > > On Thu, 15 Mar 2018, Carl Eugen Hoyos wrote: > >> 2018-03-09 21:58 GMT+01:00, Marton Balint <cus@passwd.hu>: >>> >>> On Fri, 9 Mar 2018, Devin Heitmueller wrote: >> >>>> Also, isn’t -format_code a capture parameter? Is it even valid >>>> to provide that on output? >>> >>> Yes, it is capture only indeed. Wonder why does ffmpeg >>> accept it in the first place? >> >> Output options are not (cannot?) be validated, this is also discussed >> in several tickets. > > Can you point me to the tickets? I only found #4184, I believe there was another ticket... Carl Eugen
diff --git a/doc/outdevs.texi b/doc/outdevs.texi index daf7b1ae62..1ca81ba139 100644 --- a/doc/outdevs.texi +++ b/doc/outdevs.texi @@ -180,6 +180,13 @@ Play video clip with non-standard framerate or video size: ffmpeg -i test.avi -f decklink -pix_fmt uyvy422 -s 720x486 -r 24000/1001 'DeckLink Mini Monitor' @end example +@item +Signal Generator mode: +@example +ffmpeg -re -f lavfi -i "testsrc=s=1920x1080:rate=30000/1000" -f lavfi -i "sine=frequency=1000:sample_rate=48000" + -ac 2 -acodec pcm_s16le -pix_fmt uyvy422 -format_code Hi30 -f decklink 'DeckLink Studio 2' +@end example + @end itemize @section libndi_newtek
Signed-off-by: Mike Goins <midicase@gmail.com> --- doc/outdevs.texi | 7 +++++++ 1 file changed, 7 insertions(+)