Re: [FFmpeg-devel] [PATCH 2/3] decklink: new option 'format' to set video format by fourCC
On Thursday, March 16, 2017 3:54:39 PM CDT Marton Balint wrote: > On Thu, 16 Mar 2017, Nicolas George wrote: > > Le sextidi 26 ventôse, an CCXXV, Matthias Hunstock a écrit : > >> I did not find a comparable option for another device in libavdevice, > >> "format" was the initial suggestion of Marton. This is at least > >> consistent with the existing "list_formats" option. > > > > I do not know what the option does, and therefore can not propose a > > better name. > > It selects video standard, field order and frame rate, these fourcc-s are > defined in the BlackMagic SDK. Example: 'Hp50' - HD 1080p50 format. > > > All I know is that we decided not to build an inconvenient > > infrastructure to avoid the collision between global, format, codecs > > options, at the cost of having to be careful when adding said options. > > This is exactly one of these cases: "format" can be added as a global > > option, as a ffmpeg.c option or anything else, because it is very > > generic. > How about “scan_format”, to be act as a collection of sub-elements “scan_width”, “scan_rate” and "scan_type"? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Enquiry re resolving errors reported by stream analysers after transcoding with FFmpeg
> > Errors reported by analysers > > > > * Unable to insert PCR on PES (TR-8 requirement from Sky's VRP video > > spec for PDL) * MPEG and AAC audio buffer overflows (Manzanita) > > * PES header data_alignment_indicator flag not set for video and audio > > (Manzanita) * Failed HRD conformance check (Tektronix Cerify) > > * TB overflows (A/V Codec Analyser) > > * PTS (Presentation Timestamp) interval is not constant in audio > > stream (A/V Codec Analyser) * PTS must occur after end of Access Unit > > (A/V Codec Analyser) > > * PCR discontinuities (A/V Codec Analyser) > > reproducable testcases would very usefull. > Iam sure there are bugs in our mpeg ts muxer but possibly some of these are > also just configuration issues. > > More generally and a maybe this is a little bit a rant ;) > If all these slightly expensive Analysers would have been available to the > wider community then the developers who worked on the related code would > have been aware of the problems with details and would have been able to fix > these when the code was originally written or at least long ago. > As it is, its not unknown there are problems in the code but with no details > and no easy way to test potential fixes, its not so easy to fix for many > developers. There may be a very small number of developers who know mpeg-ts > so well they can understand and fix bugs without any way to test but i > think there are many more people who have a more shallow understaning and > who have more time who could with detailed information of what is wrong and > with the ability to test changes be able to fix these as well I’d like to insert an unsolicited plug for Thierry Lelegard and the TSDuck project. Their FOSS toolset has been invaluable for analyzing and manipulating mpeg-ts streams. https://tsduck.io/ https://github.com/tsduck/tsduck -Reuben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-user] ffmpeg engineer
Well, I’m U.S. citizen, so visa stuff isn’t an issue, but I’ve never been impressed with JVM/JRE enough to take time to learn it. Just FYI, for DASH, you will probably want somebody proficient in C who is somewhat familiar with the ffmpeg code base who can also develop patches for ffmpeg. The ffmpeg DASH implementation, while always being improved, is still not very well polished yet. Various samples provided by members of the Dash Industry Forum don’t play back correctly with ffmpeg, and vice versa. Especially with the live profile. Good luck. -Reuben On Thursday, February 16, 2017 12:57:15 PM CST Batman wrote: > This is a development role for sure - JVM knowledge is a must. (ideally > Scala) > > We could chat about re-lo, but it's a full-time role so visas would have to > be in order already, I don't believe they're looking to sponsor. I believe > they're using DASH but not 100% sure. > > (Mike Cohen - A.K.A. Batman) > > *BatPhone:* 617.999.0818 > > <https://www.linkedin.com/in/gothamtechtalk> > <https://plus.google.com/u/0/101941911483118915714/about> > <https://www.facebook.com/MilesMReVera> > <https://twitter.com/GothamTechTalk> <http://wax-poetic.org/> > <https://www.pinterest.com/milesmrevera/> > <https://instagram.com/milesmrevera/> > > On Thu, Feb 16, 2017 at 12:55 PM, Reuben Martin wrote: > > On Thursday, February 16, 2017 11:05:09 AM CST Batman wrote: > > > Hey All! I'm helping Giphy (our favourite Gif Platform) find an a > > > video-streaming engineer and they'd LOVE someone with some ffmpeg > > > experience. > > > > Riddle me this Batman... “video-streaming engineer” is a rather ambigious > > title. Is this a development role (writing code to integrate streaming > > with > > their stack) or more of an operations role (running it and making it > > function > > correctly)? Or perhaps with a group that small it’s a bit of both? Curious > > because if it’s the former, it would make a bit more sense to post this in > > the > > ffmpeg-dev list. > > > > > NYC - Scala Stack - Pays very well - company has over $150M in funding > > > > and > > > > > just moved to an amazing new office (still under 70 people) > > > > Does it require re-location? Does it require experience with Scala? > > > > I’m EIC (Engineer-In-Charge) for the video crew of a live events > > production > > company that does several live streamed events per month with full > > production > > (lights, video, sound, set design, etc). I also build and maintain our > > ffmpeg > > based RTMP encoding-streaming servers and wrote the Ruby code that glues > > all > > the bits and pieces together. I’m _trying_ to find time to become > > proficient > > in Elixir. > > > > Although, I’m not sure Giphy would have use for live streaming. More > > likely > > they are interested in a segmented format like HLS, DASH or even > > SmoothStreaming? > > > > -Reuben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] dash encoder. Correct generated manifest for MPEG-DASH MPD Validator and calculate current bandwidth for eath chunk. Now works correctly with dash.sj
On Tuesday, September 6, 2016 1:56:57 PM CDT Ligverd Haer wrote: > В письме от вторник, 6 сентября 2016 г. 12:26:49 MSK пользователь Carl Eugen > > Attributes > > profiles > width > height > sar > frameRate > audioSamplingRate > mimeType > segmentProfiles > codecs > maximumSAPPeriod > startWithSAP > maxPlayoutRate > codingDependency > scanType > > Common attributes for AdaptationSet and Representation shall either be in > one of the elements but not in both. > > in particular, the attribute frameRate is duplicated in the node > Representation There is a bug report outstanding for this: https://trac.ffmpeg.org/ticket/5087 -Reuben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Add support for decoding 8-bit RGB formats.
On Sunday, July 19, 2015 02:50:23 PM Chris Spencer wrote:
> On 19 July 2015 at 14:30, Carl Eugen Hoyos wrote:
> > Chris Spencer gmail.com> writes:
> >> > > +} else if (cctx->pixel_format == AV_PIX_FMT_ARGB) {
> >> > > +ctx->bmd_format = bmdFormat8BitARGB;
> >> > > +} else if (cctx->pixel_format == AV_PIX_FMT_BGRA) {
> >> > > +ctx->bmd_format = bmdFormat8BitBGRA;
> >> > >
> >> > > +} else if (ctx->bmd_format == bmdFormat8BitARGB) {
> >> > > +st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
> >> > > +st->codec->pix_fmt = AV_PIX_FMT_ARGB;
> >> > > +st->codec->codec_tag = MKTAG('A', 'R', 'G', 'B');
> >> > > +} else if (ctx->bmd_format == bmdFormat8BitBGRA) {
> >> > > +st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
> >> > > +st->codec->pix_fmt = AV_PIX_FMT_BGRA;
> >> > > +st->codec->codec_tag = MKTAG('B', 'G', 'R', 'A');
> >> >
> >> > I would have expected these to be AV_PIX_FMT_0RGB and
> >> > AV_PIX_FMT_BGR0.
> >>
> >> The Blackmagic documentation is kind of strange on this
> >> one actually. For bmdFormat8BitBGRA it says "alpha
> >> channel is valid". For bmdFormat8BitBGRA it says "alpha
> >> channel may be valid". Not sure how best to deal with
> >> that to be honest.
> >
> > Can you test?
> > Is there a theoretical possibility that the content
> > contains valid alpha? If yes, please use ARGB.
> > If not and if you can confirm that the alpha channel
> > is correctly set to 0xFF, then you may use ARGB but I
> > wonder what the usecase would be (and how probable it
> > is that a future driver would not set it to 0xFF).
> > The codec_tag looks wrong to me because it would be
> > 0x00 for AV_PIX_FMT_ARGB and AV_PIX_FMT_BGRA. I think
> > it should only be set if needed (for YV12 or similar).
>
> Ok so with the HDMI input connected to my graphics card the alpha
> channel is zero with both ARGB and BGRA (which explains why I couldn't
> get the overlay filter to work with it now that I think about it). I
> will add bgr0 and 0rgb, but I wonder if it's worth leaving bgra and
> argb in, as the Blackmagic documentation seems to imply the alpha
> channel might be present in some situation.
>
Alpha channel is valid in the SDI spec, although not widely supported. Perhaps
this can be used in the SDI output from decklink “extream” models that offer
separate sync locked outputs for key and fill? I have access to such a card if
you would want that tested.
-Reuben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Add support for decoding 8-bit RGB formats.
On Monday, July 20, 2015 05:52:25 PM you wrote:
> On 20 July 2015 at 17:41, Reuben Martin wrote:
> > On Sunday, July 19, 2015 02:50:23 PM Chris Spencer wrote:
> >> On 19 July 2015 at 14:30, Carl Eugen Hoyos wrote:
> >> > Chris Spencer gmail.com> writes:
> >> >> > > +} else if (cctx->pixel_format == AV_PIX_FMT_ARGB) {
> >> >> > > +ctx->bmd_format = bmdFormat8BitARGB;
> >> >> > > +} else if (cctx->pixel_format == AV_PIX_FMT_BGRA) {
> >> >> > > +ctx->bmd_format = bmdFormat8BitBGRA;
> >> >> > >
> >> >> > > +} else if (ctx->bmd_format == bmdFormat8BitARGB) {
> >> >> > > +st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
> >> >> > > +st->codec->pix_fmt = AV_PIX_FMT_ARGB;
> >> >> > > +st->codec->codec_tag = MKTAG('A', 'R', 'G', 'B');
> >> >> > > +} else if (ctx->bmd_format == bmdFormat8BitBGRA) {
> >> >> > > +st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
> >> >> > > +st->codec->pix_fmt = AV_PIX_FMT_BGRA;
> >> >> > > +st->codec->codec_tag = MKTAG('B', 'G', 'R', 'A');
> >> >> >
> >> >> > I would have expected these to be AV_PIX_FMT_0RGB and
> >> >> > AV_PIX_FMT_BGR0.
> >> >>
> >> >> The Blackmagic documentation is kind of strange on this
> >> >> one actually. For bmdFormat8BitBGRA it says "alpha
> >> >> channel is valid". For bmdFormat8BitBGRA it says "alpha
> >> >> channel may be valid". Not sure how best to deal with
> >> >> that to be honest.
> >> >
> >> > Can you test?
> >> > Is there a theoretical possibility that the content
> >> > contains valid alpha? If yes, please use ARGB.
> >> > If not and if you can confirm that the alpha channel
> >> > is correctly set to 0xFF, then you may use ARGB but I
> >> > wonder what the usecase would be (and how probable it
> >> > is that a future driver would not set it to 0xFF).
> >> > The codec_tag looks wrong to me because it would be
> >> > 0x00 for AV_PIX_FMT_ARGB and AV_PIX_FMT_BGRA. I think
> >> > it should only be set if needed (for YV12 or similar).
> >>
> >> Ok so with the HDMI input connected to my graphics card the alpha
> >> channel is zero with both ARGB and BGRA (which explains why I couldn't
> >> get the overlay filter to work with it now that I think about it). I
> >> will add bgr0 and 0rgb, but I wonder if it's worth leaving bgra and
> >> argb in, as the Blackmagic documentation seems to imply the alpha
> >> channel might be present in some situation.
> >
> > Alpha channel is valid in the SDI spec, although not widely supported.
> > Perhaps this can be used in the SDI output from decklink “extream” models
> > that offer separate sync locked outputs for key and fill? I have access
> > to such a card if you would want that tested.
>
> That's interesting, I didn't know that. What might be a useful test
> would be to output some ARGB/BGRA video with some data in the alpha
> channel on one output, connect it directly to the other input and
> check whether the alpha channel is preserved. If it is then it is
> probably worth allowing argb/bgra in addition to 0rgb/bgr0 in ffmpeg.
>
> I don't have a card that can do that, so if you're able to test that
> would be super.
>
I applied your patches to latest stable 2.7.2, but I just now realized that
the additional pix formats are only applied to the capture interface, and not
the playout interface. So I really have no means to test it. Is this a
limitation of the SDK, or has the additional pix formats not yet been added to
the playout interface?
-Reuben
** Just noticed this got lost from the official mailing list at some point. Re-
sending for ffdevel...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] which rtmpdump is beter for fmpeg's native rtmp lib and rtmpdump
On Monday, July 11, 2016 3:22:03 PM CDT qw wrote: > Hi, > > I found ffmpeg support two rtmp libs, where one is ffmpeg's native rtmp lib, > and the other is rtmpdump. Which is better? > Native. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI
On Fri, Oct 6, 2017 at 4:31 PM, Devin Heitmueller wrote: > > Ah, I understand now. > > Yes, the decklink device is currently the only SDI device which is supported > by libavdevice. I’ve got a whole pile of patches coming which add support > for a variety of protocols for both capture and output (e.g. EIA-708, > SCTE-104, AFD, SMPTE 2038, etc). But today the decklink module is the only > device supported. > > Would love to see more SDI devices supported and potentially interested in > adding such support myself if we can find good candidates. The DVEO/linsys > cards are largely obsolete and the AJA boards are significantly more > expensive than any of BlackMagic’s cards. If anyone has good experiences > with other vendors I would like to hear about it (and there may be an > opportunity to extend libavdevice to support another SDI vendor). Bluefish has some very nice ($$$) SDI cards with Linux support. I think their SDK also supports v4l2. Have never been able to get my hands on one though. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
