Re: [FFmpeg-devel] FFmpeg governance and accusations

[Ali KIZIL]

> Michael Niedermayer (12024-12-30):
> > After months of public harassment and accusations
> > it appears the attacks against me shift to private mail.
> >
> > Iam not sure how to handle this to be honest,
> > It must from the outside look like these mails here and there are a minor
> > thing, but really this is grinding my nerves down, my ability to do
> usefull work is
> > like cut down to a quarter maybe. Everything takes so much more time
> > in this hostile environment.
> >
> > But in an attempt to remove the grand prize and motive behind this.
> > I will never give any power related to FFmpeg to people who continue with
> > attacks/harrassment/accusations.
> > (more clearly, any future democratication will exclude them permanently
> for all times)
> >
> > Also the text quoted from me from years ago saying i would
> > support passing power on, has expired now, the community back then also
> is not
> > the GA now.
> >
> > We today really are much farther away from democratication than back
> then.
> > Theres a bigger divide between people, less tolerance. This has to
> change first
> >
> > also about democratication, its not possible with the GA/CC as it is
> currrently.
> > ATM 3 of 5 seats in the CC are filled by executives or employees of
> FFlabs.
> > That would make FFmpeg a subsidiery of FFlabs and has nothing to do with
> democracy
> > (this could actually give less power to the community than it has now)
> >
> > Not to mention that the CC is judge, jury and executioner while
> pretending
> > to be democratic.
>
> For what it is worth, you have my full support on this, and sympathy for
> the harassment you have been subjected to.
>
> I slowly realized democracy on a project such as FFmpeg is a path
> towards immobilism and irrelevance. And in our case, it is worsened
> because some people have borrowed their definition from Erdoğan, “like a
> tram, you ride it until you arrive at your destination, then you step
> off”.
>
> Regards,
>
> --
>   Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>

Regarding the mention of Erdoğan's statement, I believe it should be
interpreted within the context of the challenging circumstances of its
time, such as military and internal coup attempts or the turbulence caused
by the Arab Spring. These events often necessitated pragmatic approaches to
ensure stability and progress.

While it may seem controversial, I find this explanation reasonable given
the difficult geopolitical and domestic conditions that shaped such
perspectives.

I have been following Michael Niedermayer's work for years as an FFmpeg
fan. It would be right to evaluate the words spoken in the context of that
day rather than today's moment.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: adapt to the new internal encode API

[Ali KIZIL]

Marton Balint , 9 Nis 2020 Per, 01:23 tarihinde şunu yazdı:

>
>
> On Wed, 8 Apr 2020, Philip Langdale wrote:
>
> > On Wed,  8 Apr 2020 14:58:36 -0300
> > James Almer  wrote:
> >
> >> Signed-off-by: James Almer 
> >> ---
> >> This removes the encode2() implementation as it'll never be used if a
> >> receive_packet() one exists, and the flush() implementation since
> >> according to Anton Khirnov avcodec_flush_buffers() is not meant to be
> >> used with encoders, where its behavior is undefined.
> >
> > Nevertheless, there is a use case for flushing an encoder (see 3ea705),
> > and when you call avcodec_flush_buffers() in nvenc, it does the right
> > thing.
> >
> > Removing this will return us to the world before that change where
> > there was no way to flush the encoder, and the original bug reporter
> > was asking about adding an API to do it.
> >
> > It seems the right thing to do is to define the behaviour - which seems
> > reasonable as-is today and documment that encoders can implement flush
> > if necessary. Or we'll just end up adding a new API that flushes
> > encoders but has a different name...
>
> I guess the problem is that avcodec_flush_buffers() does not return a
> result so it can't signal if it is implemented by the encoder, therefore
> the application will not know if avcodec_flush_buffers() is enough or it
> has to create a new encode context. Maybe a capability flag can be added
> to signal support, but a different function might just be cleaner...
>
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Does this patch offer any solution to ticket
https://trac.ffmpeg.org/ticket/8225  ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc: enforce PCR packets without payload

[Ali KIZIL]

Andreas Håkon , 25 Nis 2019 Per, 17:49
tarihinde şunu yazdı:

>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, 25 de April de 2019 16:23, Ali KIZIL 
> wrote:
>
> > Andreas Håkon andreas.ha...@protonmail.com, 25 Nis 2019 Per, 12:07
> > tarihinde şunu yazdı:
> >
> > > Hi,
> > > A patch for a new optional parameter for the mpegtsenc muxer.
> > > Regards.
> > > A.H.
> > > ---___
> >
> > Is this patch related with "[FFmpeg-devel] [PATCH] libavformat: forced
> PCR
> > pid in mpegts muxer" patchwork ?
>
> No. They're complementary, but totally different patches/objectives!
>
> >
> > Is the purpose of the patch to avoid null stuffing in forced pcr pid ?
>
> No. The purpose is to avoid having PCR marks in packets with payload.
>
> >
> > I can not figure out the usage. A texi can be useful.
> > Normally, if PCR in on Video PID, why should I prefer to avoid video
> > payload ?
> >
>
> When you move the PCR marks to empty packets then you can transform the
> Transport Stream without touching the PES packets at all. Imagine a TS
> processor that duplicates or process the PCR packets for other purposes.
> As these packets doesn't have any payload the stream processor is free
> to do it whatever it needs. This is just one example. This option can
> be useful in various scenarios. In my research the target are several
> multi-resolution streams for mobile devices.
>
> In any case I have to say that this patch is completely transparent
> and only adds optional functionality.
>
> Regards.
> A.H.
>
> ---
>

I got the point. Yet, sorry for being curious, would can affect TR101 290
analyze results  and/or null stuffing on CBR mpegts out?
I can do these tests if needed, by tomorrow.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc: enforce PCR packets without payload

[Ali KIZIL]

Andreas Håkon , 25 Nis 2019 Per, 12:07
tarihinde şunu yazdı:

> Hi,
>
> A patch for a new optional parameter for the mpegtsenc muxer.
>
> Regards.
> A.H.
>
> ---___
>

Is this patch related with "[FFmpeg-devel] [PATCH] libavformat: forced PCR
pid in mpegts muxer" patchwork ?

Is the purpose of the patch to avoid null stuffing in forced pcr pid ?

I can not figure out the usage. A texi can be useful.
Normally, if PCR in on Video PID, why should I prefer to avoid video
payload ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mpegenc - reject unsupported audio streams

[Ali KIZIL]

Gyan , 24 Nis 2019 Çar, 07:30 tarihinde şunu yazdı:

>
>
> On 24-04-2019 03:30 AM, Carl Eugen Hoyos wrote:
> > 2019-04-22 13:00 GMT+02:00, Gyan :
> >> On 22-04-2019 01:15 PM, Gyan wrote:
> >>>
> >>> On 22-04-2019 12:30 PM, Carl Eugen Hoyos wrote:
> > Am 20.04.2019 um 11:31 schrieb Gyan :
> >
> >
> > Old patch that was never applied. Rebased.
>  Please return patch_welcome for mlp and truehd.
> >>> Will do.
>  Wasn’t there another comment (not by me): “Why
>  can’t .codec_tag be used?”
> >>> There's no codec_tag member set. This patch is just
> >>> to disallow an invalid muxing to proceed.
> > Wasn't the argument that this is possible with codec_tag?
>
> Not in the present state. If you want to add a codec_tag, that's a
> separate patch.
>
> >> Revised.
> > What about aac?
>
> There's no provision to mux AAC, at present. On demux, the stream is
> detected as mp2.
>
> > And can't you wait more than a few hours for a review?
> This patch is 14 months old, except for the one change you requested.
> And all the patch does is enforce the existing limitations.
>
> Gyan
> ___
>

There are also Dolby Codecs (ac3 & eac3). Will it also throw error for
these codecs ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] News: Removal of libndi

[Ali KIZIL]

On Thu, Mar 21, 2019, 5:54 PM Maksym Veremeyenko  wrote:

> On 20.03.2019 22:13, Dennis Mungai wrote:
> [...]
> > The primary agitator here seems to be kierank:
> > https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10#comment:5
> >
> > What undisclosed history do you have with Newtek (see the reference to
> > "Andrew") above that isn't disclosed above?
> > Secondly, you're quite influential in the broadcast industry:
> > https://www.obe.tv/author/obe/
> >
> > There's an aura of hostility around this commit, and whatever that is
> seems
> > to have spilled over into this.
>
> dropping NDI from ffmpeg can make more efforts to
> https://www.obe.tv/portfolio/interface-conversion/# ?
>
> --
> Maksym Veremeyenko
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Unfortunately, I had the same feeling.

I use NDI for SDI to/from IP conversation at contribution encoding against
J2K at zero cost, which is also compatible with NDI equipments.

I wasn't brave enough like Maksyn to spread the word.

I think the source code itself doesn't violate GPL. It use an external lib,
just like drivers.

Newtek stopped distributing the binary. I don't understand how removing
source code from FFmpeg repo punishes Newtek. It just discourage developers
and took users out of notice for some days.

Anyone can make an external repo with a patch to apply to use it back at a
point where this removal is still under questioning.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] News: Removal of libndi

[Ali KIZIL]

Dennis Mungai , 20 Mar 2019 Çar, 23:20 tarihinde şunu
yazdı:

> On Wed, 20 Mar 2019 at 23:02, Marton Balint  wrote:
>
> >
> >
> > On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote:
> >
> > > On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote:
> > >> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote:
> > >>
> > >> > On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote:
> > >> >> As I described in similar threads before, whether or not the
> project
> > want
> > >> >> closed source support for NDI is a subjective issue, please start a
> > vote
> > >> >> about the removal of libndi if you want to seek this through.
> > >> >
> > >> > The removal of libndi is actually done and committed.
> > >>
> > >> That is just sad an unfair.
> > >
> > > Sad, maybe.
> > > Unfair, I disagree. If NDI wants to be in, they know what to do.
> >
> > It is unfair towards the people who expressied disapproval, yet this
> > change was committed without neither vote nor consensus.
> >
> > Regards,
> > Marton
> >
> >
> >
> At the very best, the lack of consensus on this  implies vindictive intent.
> Is there something that the FFmpeg developers (see below) have against
> Newtek, as a company?
> Clearly, they took down the offending FFmpeg build:
> https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10
>
> We've seen other violations, such as this one by Amazon:
> https://trac.ffmpeg.org/ticket/7214 that were handled in a much more
> graceful manner.
>
> The primary agitator here seems to be kierank:
> https://trac.ffmpeg.org/ticket/7589?cversion=0&cnum_hist=10#comment:5
>
> What undisclosed history do you have with Newtek (see the reference to
> "Andrew") above that isn't disclosed above?
> Secondly, you're quite influential in the broadcast industry:
> https://www.obe.tv/author/obe/
>
> There's an aura of hostility around this commit, and whatever that is seems
> to have spilled over into this.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


The way of removal is not nice. There were an expectation to have a voting
for removal at the previous ML chain.
It feels the feeling of the patch is committed without any notice.
Sad, for the users who follow git-master and get notice for removal after
the commit.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Ali KIZIL]

Gyan , 10 Ara 2018 Pzt, 11:47 tarihinde şunu yazdı:

>
> On 10-12-2018 07:41 AM, Carl Eugen Hoyos wrote:
> > 2018-12-03 17:05 GMT+01:00, Carl Eugen Hoyos :
> >
> >> It appears to me that NewTek abused our willingness to add an optional
> >> external nonfree library, I don't see many better options. See Ticket
> >> #7589 and a blog post by a NewTek engineer confirming the issue.
> >>
> >> Patch untested.
> > After several people have objected claiming NewTek would fix this
> > situation, a week has passed: No visible reaction whatsoever, not
> > even requesting more time.
> >
> > What are those suggesting who were against this patch?
>
> Contact Newtek with your concerns and a deadline and what action you're
> considering beyond the deadline.
>
> Gyan


Newtek released 3.7.1 version of their SDK which does not include ffmpeg.exe

md5sum is:
e2a29174333f20cb6cc66ec5e27ccbf3  Downloads/NewTek NDI 3.7.1 SDK.exe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Ali KIZIL]

On Tue, Dec 4, 2018, 1:14 AM Marton Balint 
>
> On Mon, 3 Dec 2018, Jean-Baptiste Kempf wrote:
>
> > On Mon, 3 Dec 2018, at 19:48, Paul B Mahol wrote:
> >> > On the general idea of this - agreed.
> >> >
> >> > Separately I think we should at least bring up a possible rethink of
> >> > our policy about non-open source nonfree components.
> >> >
> >> > If it's:
> >> > - Not part of the OS
> >> > or
> >> > - Not open source
> >> >
> >> > ...maybe we should not include such a component upstream?
> >>
> >> Yes, remove all hardware stuff +1.
> >
> > Libraries to access hardware, notably those that are talking directly
> with something that was shipped with the drivers, are usually considered
> part of the OS. This is a bit weird, but this extend the Linux way to other
> (broken) OSes.
> >
> > That would make nvenc and such acceptable.
> >
> > NDI is not hardware. (Nor is faac)
>
> I really don't want to troll here, but there is an NDI PTZ camera:
>
> https://www.newtek.com/camera/ndihx-ptz1/
>
> So is it really that different to a USB camera just because the
> singalling is going through ethernet and not USB?
>
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


+1 or PCIe

Just a suggestion: there can be a request from well known brands who are
making contributions to FFmpeg to donate for hiring a lawyer who has
proficiency on OSS subject for both US and EU laws. It will be for their
and community's benefit, as there will be an independent point of view. I
believe there can be donators from community too. Time to time, it is
noticable users as asking for non-free compile subject.

This approach can bring a proper action for similar cases and avoid in
further. The lawyer can be supportive on CoC subject either.

>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Ali KIZIL]

On Tue, Dec 4, 2018, 12:07 AM Carl Eugen Hoyos  2018-12-03 22:00 GMT+01:00, Ali KIZIL :
>
> > Newtek representative says, they will remove the binary from SDK right
> away
>
> Could you please read the sentence you sent?
> Particularly the words "says" and "will".
>
> They did not remove the binariy when informed about the
> license violations!
> (At least, there is no indication they did.)
>
> > Personally, I do not believe they break the license on purpose.
>
> Did you read the post on their support forum where the very
> person claiming now he had no idea it is wrong answered to
> the information that distributing such binaries is illegal?
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


https://trac.ffmpeg.org/ticket/7589

Sent by across:
...
If we have offended anyone then I sincerely apologize and please accept
that it was not our intent. We will remove FFMPEG entirely from our SDK and
get it patched online today.
...

>
> I didn't read the forums, yet I take care of what he is saying and if they
> are going to remove compiled binary from their SDK with an official
> apology.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Ali KIZIL]

On Mon, Dec 3, 2018, 11:41 PM Carl Eugen Hoyos  2018-12-03 21:28 GMT+01:00, Martin Vignali :
> >> > >>
> >> > >> It appears to me that NewTek abused our willingness to add an
> >> > >> optional
> >> > >> external nonfree library, I don't see many better options. See
> Ticket
> >> > >> #7589 and a blog post by a NewTek engineer confirming the issue.
> >> > >>
> >> > >> Patch untested.
> >> > >>
> >> > >> Please comment, Carl Eugen
> >> > >
> >>
> >
> > This patch looks wrong to me.
> >
> > It's seems like removing features for personal opinion.
>
> This is a lie.
> (I don't care.)
>
> > Ticket 7589, mention an incorrect build redistribution.
> >
> > So, right way to fix this ticket, will be (for people interesting in this
> > kind of thing)
> > to indicate, what need to be done, in order to have a licence compliant
> > build.
>
> Again: What message would this send to future license violators?
>
> Since you are throwing accusations:
> Please remind me how many license violations you have worked on.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Newtek representative says, they will remove the binary from SDK right away
and will stop distributing as its current state with passing their
apologies, while accepting their mistake.

I do not understand that how it is being decided to remove a complete work
against a non-free distribution.

I suggest to not to take immediate harsh actions without fully discussing
the side effects.

Personally, I do not believe they break the license on purpose. If so, they
wouldn't announce it. They would fo as some others do, by trying hide. So
personally, I think removal of  code is a very strong decision for this
kind of revertible violation, as Newtek also gets in response asap.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Ali KIZIL]

On Mon, Dec 3, 2018, 9:48 PM Paul B Mahol  On 12/3/18, Jan Ekström  wrote:
> > On Mon, Dec 3, 2018 at 6:06 PM Carl Eugen Hoyos 
> wrote:
> >>
> >> Hi!
> >>
> >> It appears to me that NewTek abused our willingness to add an optional
> >> external nonfree library, I don't see many better options. See Ticket
> >> #7589 and a blog post by a NewTek engineer confirming the issue.
> >>
> >> Patch untested.
> >>
> >> Please comment, Carl Eugen
> >
> > On the general idea of this - agreed.
> >
> > Separately I think we should at least bring up a possible rethink of
> > our policy about non-open source nonfree components.
> >
> > If it's:
> > - Not part of the OS
> > or
> > - Not open source
> >
> > ...maybe we should not include such a component upstream?
>
> Yes, remove all hardware stuff +1.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


>
> While there is a non-free option and while there are lots of HW related
> implementations done by developers in such condition for long time, I
> believe it is not right to remove all thesd valuable work. This will
> definitely break to courage to submit new developments to FFmpeg.


I also think, Newtek is not in a way to hide things as they share the post.
I believe they thought their approach is normal, when considering the
current case examples.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Implement NewTek NDI support

[Ali KIZIL]

2017-08-14 0:00 GMT+03:00 Marton Balint :

>
> On Tue, 8 Aug 2017, Maksym Veremeyenko wrote:
>
> [...]
>>
>
>
>> Check if *avahi* daemon is running and firewall turned off.
>>
>
> Thanks, it works now.
>
> I have some final comments, after addressing those, I guess this can be
> applied, it's been discussed for quite a long time now.
>
> [...]
>
> +static int ndi_set_video_packet(AVFormatContext *avctx,
>> NDIlib_video_frame_t *v, AVPacket *pkt)
>> +{
>> +int ret;
>> +struct NDIContext *ctx = avctx->priv_data;
>> +
>> +ret = av_new_packet(pkt, v->yres * v->line_stride_in_bytes);
>> +if (ret < 0)
>> +return ret;
>>
>
> You are leaking the NDI video frame here on error. Maybe better to put
> NDIlib_recv_free_video into the parent function.
>
> +
>> +pkt->dts = pkt->pts = av_rescale_q(v->timecode, NDI_TIME_BASE_Q,
>> ctx->video_st->time_base);
>> +pkt->duration = av_rescale_q(1, (AVRational){v->frame_rate_D,
>> v->frame_rate_N}, ctx->video_st->time_base);
>> +
>> +av_log(avctx, AV_LOG_DEBUG, "%s: pkt->dts = pkt->pts = %"PRId64",
>> duration=%"PRId64", timecode=%"PRId64"\n",
>> +__func__, pkt->dts, pkt->duration, v->timecode);
>> +
>> +pkt->flags |= AV_PKT_FLAG_KEY;
>> +pkt->stream_index   = ctx->video_st->index;
>> +
>> +memcpy(pkt->data, v->p_data, pkt->size);
>> +
>> +NDIlib_recv_free_video(ctx->recv, v);
>> +
>> +return 0;
>> +}
>> +
>> +static int ndi_set_audio_packet(AVFormatContext *avctx,
>> NDIlib_audio_frame_t *a, AVPacket *pkt)
>> +{
>> +int ret;
>> +struct NDIContext *ctx = avctx->priv_data;
>> +
>> +NDIlib_audio_frame_interleaved_16s_t dst;
>> +
>> +ret = av_new_packet(pkt, 2 * a->no_samples * a->no_channels);
>> +if (ret < 0)
>> +return ret;
>>
>
> Similar to the previous case, you are leaking the NDI audio frame here on
> error. Maybe better to put NDIlib_recv_free_audio into the parent function.
>
> +
>> +pkt->dts = pkt->pts = av_rescale_q(a->timecode, NDI_TIME_BASE_Q,
>> ctx->audio_st->time_base);
>> +pkt->duration = av_rescale_q(1, (AVRational){a->no_samples,
>> a->sample_rate}, ctx->audio_st->time_base);
>> +
>> +av_log(avctx, AV_LOG_DEBUG, "%s: pkt->dts = pkt->pts = %"PRId64",
>> duration=%"PRId64", timecode=%"PRId64"\n",
>> +__func__, pkt->dts, pkt->duration, a->timecode);
>> +
>> +pkt->flags   |= AV_PKT_FLAG_KEY;
>> +pkt->stream_index = ctx->audio_st->index;
>> +
>> +dst.reference_level = 0;
>> +dst.p_data = (short *)pkt->data;
>> +NDIlib_util_audio_to_interleaved_16s(a, &dst);
>> +
>> +NDIlib_recv_free_audio(ctx->recv, a);
>> +
>> +return 0;
>> +}
>>
>
>
> [...]
>
> +static int ndi_create_video_stream(AVFormatContext *avctx,
>> NDIlib_video_frame_t *v)
>> +{
>> +AVStream *st;
>> +AVRational tmp;
>> +struct NDIContext *ctx = avctx->priv_data;
>> +
>> +st = avformat_new_stream(avctx, NULL);
>> +if (!st) {
>> +av_log(avctx, AV_LOG_ERROR, "Cannot add video stream\n");
>> +return AVERROR(ENOMEM);
>> +}
>> +
>> +st->time_base   = NDI_TIME_BASE_Q;
>> +av_stream_set_r_frame_rate(st, av_make_q(v->frame_rate_N,
>> v->frame_rate_D));
>> +
>> +tmp = av_mul_q(av_d2q(v->picture_aspect_ratio, INT_MAX),
>> (AVRational){v->yres, v->xres});
>> +av_reduce(&st->sample_aspect_ratio.num,
>> &st->sample_aspect_ratio.den, tmp.num, tmp.den, 1000);
>> +st->codecpar->sample_aspect_ratio = st->sample_aspect_ratio;
>> +
>> +st->codecpar->codec_type= AVMEDIA_TYPE_VIDEO;
>> +st->codecpar->width = v->xres;
>> +st->codecpar->height= v->yres;
>> +st->codecpar->codec_id  = AV_CODEC_ID_RAWVIDEO;
>> +st->codecpar->bit_rate  = av_rescale(v->xres * v->yres * 16,
>> v->frame_rate_N, v->frame_rate_D);
>> +st->codecpar->field_order   = v->frame_format_type ==
>> NDIlib_frame_format_type_progressive
>> +? AV_FIELD_PROGRESSIVE : AV_FIELD_TT;
>> +
>> +if (NDIlib_FourCC_type_UYVY == v->FourCC || NDIlib_FourCC_type_UYVA
>> == v->FourCC) {
>>
>
> You should give the user a warning here in case of UYVA format, because
> you are
> going to skip the alpha channel.
>
> +st->codecpar->format= AV_PIX_FMT_UYVY422;
>> +st->codecpar->codec_tag = MKTAG('U', 'Y', 'V', 'Y');
>> +} else if (NDIlib_FourCC_type_BGRA == v->FourCC) {
>> +st->codecpar->format= AV_PIX_FMT_BGRA;
>> +st->codecpar->codec_tag = MKTAG('B', 'G', 'R', 'A');
>> +} else if (NDIlib_FourCC_type_BGRX == v->FourCC) {
>> +st->codecpar->format= AV_PIX_FMT_BGR0;
>> +st->codecpar->codec_tag = MKTAG('B', 'G', 'R', '0');
>> +} else if (NDIlib_FourCC_type_RGBA == v->FourCC) {
>> +st->codecpar->format= AV_PIX_FMT_RGBA;
>> +st->codecpar->codec_tag = MKTAG('R', 'G', 'B', 'A');
>> +} else if (NDIlib_FourCC_type_RGBX == v->FourCC) {
>> +st->codecpar->

Re: [FFmpeg-devel] [PATCH v12] - Added Turing codec interface for ffmpeg

[Ali KIZIL]

2017-07-17 14:19 GMT+03:00 Saverio Blasi :

> >> Thanks a lot, this makes sense. I thought that flag was compulsory and
> therefore we only included linking against libraries in "Libs.private" in
> the pc file. I have just pushed a fix to the Turing repo to include that in
> the Libs as well.
> >>
> >> I have tested this and it seems to work fine in my machine and in the
> Docker with Ubuntu and debian with and without the flag now. No changes are
> needed to the actual patch, it should work as long as you update Turing to
> the latest commit.
>
>
> So we have now further tested this extensively in different machines. I
> believe the problems with linking against dynamic libraries are solved in v
> 12 of the patch. In all our tests the patch works correctly with either
> settings of the pkg-config-flags. Could you please help us and confirm that
> this is the case? I think this was the only blocker with this latest
> version of the patch?
>
> Thanks,
> 
> Saverio Blasi
> Senior Research Engineer
> BBC Research & Development
> Centre House|56 Wood Lane|London|W12 7SB
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Is the Turing Codec interface patch going to be pushed after the fix of
flag problem ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc: Make AUD optional for h264_nvenc and hevc_nvenc

[Ali KIZIL]

2017-01-05 13:29 GMT+03:00 Yogender Gupta :

> >> There is BUG in Nvidia NVENC when you use AUD for H264 with B-frames,
> it will return corrupted stream, because NVIDIA is inserting AUD type 0
> (I-frame) before B-frames instead of AUD type 7 (any-frame).
>
> Thanks for bringing this to notice. We have added a fix in the Nvidia
> driver and the newer driver releases will insert the correct AUD type.
>
> Thanks,
> Yogender
>
> 
> ---
> This email message is for the sole use of the intended recipient(s) and
> may contain
> confidential information.  Any unauthorized review, use, disclosure or
> distribution
> is prohibited.  If you are not the intended recipient, please contact the
> sender by
> reply email and destroy all copies of the original message.
> 
> ---
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Yogender, is new driver released for correct AUD type insertion ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc: Make AUD optional for h264_nvenc and hevc_nvenc

[Ali KIZIL]

2016-12-30 12:07 GMT+03:00 Miroslav Slugeň :

> Dne 30.12.2016 v 05:48 Ali KIZIL napsal(a):
>
>> 2016-12-30 0:02 GMT+03:00 Miroslav Slugeň :
>>
>>
>> Somebody changed AUD to active in NVENC by default, which is not very
>>> clever, libx264 also has this future disabled, so we should stay in sync
>>> with libx264 behavior.
>>>
>>> Enabled AUD will work only without B-frames. There is BUG in Nvidia NVENC
>>> when you use AUD for H264 with B-frames, it will return corrupted stream,
>>> because NVIDIA is inserting AUD type 0 (I-frame) before B-frames instead
>>> of
>>> AUD type 7 (any-frame).
>>>
>>> H264 encoded with B-frames and AUD active will not play for example on
>>> Panasonic TX-AS640E, other decoders just ignore wrong AUD type.
>>>
>>>
>>> --
>>> Miroslav Slugeň
>>>
>>>
>>> AUD set to active by default was for LG and Sony like UHD TVs which could
>> not decode NVENC encoded HEVC MPEGTS properly.
>> If patch sets AUD active by default if there is no B-Frames (as so in
>> NVENC
>> HEVC encoding), patch will be ok in common.
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> I checked how libx264 and libx265 works
>
> For libx265 default is off:
>
> void x265_param_default(x265_param* param) {
> param->bEnableAccessUnitDelimiters = 0;
> }
>
> Only for UHD BLURAY is on:
>
> if (p->uhdBluray) {
> p->bEnableAccessUnitDelimiters = 1;
> }
>
> For libx264 default is off:
>
> void x264_param_default( x264_param_t *param ) {
> param->b_aud = 0;
> }
>
> Only for BLURAY and AVC-Intra compat
>
> if( h->param.b_bluray_compat ) {
> h->param.b_aud = 1;
> }
>
> /* 200,100,50 */
> if( h->param.i_avcintra_class ) {
> h->param.b_aud = 1;
> }
>
> So how we should implement this to NVENC? :)
>
> I still think we should default AUD to off and set in on only in special
> cases like BLURAY and AVC-Intra.
>
>
> --
> Miroslav Slugeň
> +420 724 825 885
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

From my opinion, we can set AUD on by default for HEVC as there is no
B-Frames. When AUD is on at HEVC, I checked many TVs (Samsung, LG, Sony,
Philips etc.) all look OK.
It will be better to hear comments from others as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc: Make AUD optional for h264_nvenc and hevc_nvenc

[Ali KIZIL]

2016-12-30 0:02 GMT+03:00 Miroslav Slugeň :

> Somebody changed AUD to active in NVENC by default, which is not very
> clever, libx264 also has this future disabled, so we should stay in sync
> with libx264 behavior.
>
> Enabled AUD will work only without B-frames. There is BUG in Nvidia NVENC
> when you use AUD for H264 with B-frames, it will return corrupted stream,
> because NVIDIA is inserting AUD type 0 (I-frame) before B-frames instead of
> AUD type 7 (any-frame).
>
> H264 encoded with B-frames and AUD active will not play for example on
> Panasonic TX-AS640E, other decoders just ignore wrong AUD type.
>
>
> --
> Miroslav Slugeň
>
>
AUD set to active by default was for LG and Sony like UHD TVs which could
not decode NVENC encoded HEVC MPEGTS properly.
If patch sets AUD active by default if there is no B-Frames (as so in NVENC
HEVC encoding), patch will be ok in common.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] MPEGTS UDP Stream Overflow & Underflow Case Fixes

[Ali KIZIL]

2016-11-14 15:52 GMT+03:00 Carl Eugen Hoyos :

> 2016-11-14 13:24 GMT+01:00 Ali KIZIL :
> > 2016-11-14 15:15 GMT+03:00 Carl Eugen Hoyos :
> >
> >> 2016-11-14 12:41 GMT+01:00 Ali KIZIL :
> >>
> >> > I dont claim anything and I also said it is not written by me.
> >>
> >> In your mail you wrote 'patch is made by "rycius"'.
> >> The git-formatted patch you attached has the following
> >> in its author field: "smallishzulu ".
> >> This is a contradiction.
> >>
> >> I don't know who wrote the patch (I did not look at it
> >> except for the header). No patch can be committed
> >> where the sender claims that the actual author is
> >> different from the author in the commit field of the patch.
> >>
> > The originator is rycius. I saw his diff file and nick on
> > https://trac.ffmpeg.org/ticket/4155
> > I have no clue on his real name or email.
>
> Use rycius as his name (it is the name he chose), his email
> is rycius at ryci dot us
>
> Please remove the mail footer when replying, Carl Eugen
>

Please find the attached updated patch files.


0001-Fix-UDP-MPEGTS-Overflow-Exit-Case.patch
Description: Binary data


0002-UDP-MPEGTS-Fixing-timestamps-while-filling-queue.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] MPEGTS UDP Stream Overflow & Underflow Case Fixes

[Ali KIZIL]

2016-11-14 15:15 GMT+03:00 Carl Eugen Hoyos :

> 2016-11-14 12:41 GMT+01:00 Ali KIZIL :
>
> > I dont claim anything and I also said it is not written by me.
>
> In your mail you wrote 'patch is made by "rycius"'.
> The git-formatted patch you attached has the following
> in its author field: "smallishzulu ".
> This is a contradiction.
>
> I don't know who wrote the patch (I did not look at it
> except for the header). No patch can be committed
> where the sender claims that the actual author is
> different from the author in the commit field of the patch.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I see. The originator is rycius. I saw his diff file and nick on
https://trac.ffmpeg.org/ticket/4155
I have no clue on his real name or email.

I can resend the patchs by updating them with his nickname if required.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] MPEGTS UDP Stream Overflow & Underflow Case Fixes

[Ali KIZIL]

2016-11-14 14:31 GMT+03:00 Carl Eugen Hoyos :

> 2016-11-14 12:21 GMT+01:00 Ali KIZIL :
>
> > This patch is to close Ticker 4155: https://trac.ffmpeg.org/ticket/4155
> >
> > Actualy, patch is made by "rycius".
>
> Then why does the patch claim to be written by you?
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I dont claim anything and I also said it is not written by me.
I just got diff file of "rycius" and made 2 git format patch files.

In his diff, there were 2 sections doing the same fixes in a slightly
different way.
I split his diff file for overflow and underflow fixes.
I didnt touch to overflow fix at all.
I modified his underflow fix as it was not working. It was blocking the UDP
MpegTS packet output.
So, I re-placed his timebase suggestions in the while loop.
That's it.

If I did something wrong or missing, I am sorry. There is no bad will.
Just, I shared his trac patch in Devel ML to be applied.

Regards,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] MPEGTS UDP Stream Overflow & Underflow Case Fixes

[Ali KIZIL]

Hello,

This patch is to close Ticker 4155: https://trac.ffmpeg.org/ticket/4155

Actualy, patch is made by "rycius".
I just updated the diff file to date and separated into two parts with
making a small change

a) Overflow fix exit fix
b) Underflow timebase fix

Kind Regards,
Ali KIZIL


0001-Fix-UDP-MPEGTS-Overflow-Exit-Case.patch
Description: Binary data


0002-UDP-MPEGTS-Fixing-timestamps-while-filling-queue.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] TR-03 implementation

[Ali KIZIL]

2016-11-11 0:24 GMT+03:00 Kieran Kunhya :

> >
> > sure, ffmpeg has support for many pixel formats and adding more
> > pixfmts is not a problem.
> >
> > my best answer would be to look at commits which add other pixel
> > formats and just follow how they were added to libswscale. make some
> > fate tests, and it should be done.
> >
> > hopefully you have test samples made of these pixfmts you want to add.
> > that makes testing for us easier, as we can test on multiple cpu
> > arch's to make sure the code is safe and works.
> >
>
> Sorry Compn, nothing personal here, but you are responding exactly in the
> way I thought you would and why I even wrote that certain people would
> encourage in spite of the technical issues.
>
> You don't understand the complexity of this problem either. The pixel
> formats are the least of his problems. Samples don't exist, it's not a file
> based format, it's a network stream etc. Please listen to what Ros and I
> said, we worked on this painfully for months.
>
> Regards,
> Kieran
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Hi all,

I very rarely send patches to FFmpeg. Maybe I am the last one in the row to
say something about the topic, but I belive it is not good idea to break
motivation of contributors even the idea is good or bad or wrong.

If someone wants to try, he can give a try, release a patch, it can be
discussed in a discussion level. I really find saying such comments like "
We don't need more broadcasting shit in ffmpeg." and "and it is why
FFmpeg is full of broken things and has a bad name in the professional
world." annoying. Frankly speaking, as my own, I start to think maybe some
people try to give intentional directions to FFmpeg.

Belive me; Cisco, Ateme, Siemens etc. use FFmpeg in their products and
solutions. For me, FFmpeg is great as its contributors.

-

A part from the topic; there are several useful patches released but not
applied yet, such as:

https://trac.ffmpeg.org/attachment/ticket/4155/underflow_overflow_fix.diff
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/194856.html
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202587.html

I wanted to mention this under contributor's motivation sunbjec, maybe
https://patchwork.ffmpeg.org can be used to upload missed patches.

Kind Regards,
Ali KIZIL
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [Patch] hwaccel transocode broken

[Ali KIZIL]

2016-11-11 14:47 GMT+03:00 Yogender Gupta :

> >>These are merges. Unless you volunteer to do the merges yourself (and
> properly please) you'll have to live with this.
>
> So were there merges that got left and broke the functionality. When do we
> get these merges in ? Please let me know if I can help get this up and
> fixed. There have been various people blocked on this, as  this is a
> functionality broken rather than being a simple bug.
>
> Thanks,
> Yogender
>
>
>
> 
> ---
> This email message is for the sole use of the intended recipient(s) and
> may contain
> confidential information.  Any unauthorized review, use, disclosure or
> distribution
> is prohibited.  If you are not the intended recipient, please contact the
> sender by
> reply email and destroy all copies of the original message.
> 
> ---
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Hi all,

I tested the patch, it fixes the broken. Maybe Timo can push the patch ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Broken libnpp (was working with git snapshot 0779396)

[Ali KIZIL]

Hi All,

I was trying libnpp on Big Bunny video by below command:

./ffmpeg -loglevel debug -y -hwaccel cuvid -c:v h264_cuvid -vsync 0 -i
/root/root/bunny.mp4 -vf scale_npp=1920:1072 -vcodec h264_nvenc
/tmp/tmp0.264 -vf scale_npp=1280:720 -vcodec h264_nvenc /tmp/tmp1.264

This command is working with below Git version:
https://git.ffmpeg.org/gitweb/ffmpeg.git/snapshot/077939626eeaa0c1364065414c18ab9b3a072281.tar.gz

However, today I pulled the latest git updates and noticed now FFmpeg gives
error:

ffmpeg version N-82274-g34aeb5d Copyright (c) 2000-2016 the FFmpeg
developers
  built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
  configuration: --prefix=/opt/ffmpeg --enable-nonfree --enable-gpl
--extra-cflags='-march=corei7-avx -I/opt/ffmpeg/include
-I/usr/local/include -fno-builtin-memcpy' --extra-ldflags=-L/opt/ffmpeg/lib
--bindir=/opt/ffmpeg/bin --extra-libs=-ldl --enable-libx264
--enable-libx265 --enable-nonfree --enable-gpl --enable-nvenc
--enable-libzvbi --enable-libfdk-aac --enable-libzimg --enable-avresample
--enable-libzmq --enable-libfreetype --disable-shared
--enable-hardcoded-tables --enable-cuda --enable-cuvid --enable-libnpp
--enable-version3
  libavutil  55. 35.100 / 55. 35.100
  libavcodec 57. 66.101 / 57. 66.101
  libavformat57. 57.100 / 57. 57.100
  libavdevice57.  2.100 / 57.  2.100
  libavfilter 6. 66.100 /  6. 66.100
  libavresample   3.  2.  0 /  3.  2.  0
  libswscale  4.  3.100 /  4.  3.100
  libswresample   2.  4.100 /  2.  4.100
  libpostproc54.  2.100 / 54.  2.100
Splitting the commandline.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging
level) with argument 'debug'.
Reading option '-y' ... matched as option 'y' (overwrite output files) with
argument '1'.
Reading option '-hwaccel' ... matched as option 'hwaccel' (use HW
accelerated decoding) with argument 'cuvid'.
Reading option '-c:v' ... matched as option 'c' (codec name) with argument
'h264_cuvid'.
Reading option '-vsync' ... matched as option 'vsync' (video sync method)
with argument '0'.
Reading option '-i' ... matched as input file with argument
'/root/root/bunny.mp4'.
Reading option '-vf' ... matched as option 'vf' (set video filters) with
argument 'scale_npp=1920:1072'.
Reading option '-vcodec' ... matched as option 'vcodec' (force video codec
('copy' to copy stream)) with argument 'h264_nvenc'.
Reading option '/tmp/tmp0.264' ... matched as output file.
Reading option '-vf' ... matched as option 'vf' (set video filters) with
argument 'scale_npp=1280:720'.
Reading option '-vcodec' ... matched as option 'vcodec' (force video codec
('copy' to copy stream)) with argument 'h264_nvenc'.
Reading option '/tmp/tmp1.264' ... matched as output file.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option loglevel (set logging level) with argument debug.
Applying option y (overwrite output files) with argument 1.
Applying option vsync (video sync method) with argument 0.
Successfully parsed a group of options.
Parsing a group of options: input file /root/root/bunny.mp4.
Applying option hwaccel (use HW accelerated decoding) with argument cuvid.
Applying option c:v (codec name) with argument h264_cuvid.
Successfully parsed a group of options.
Opening an input file: /root/root/bunny.mp4.
[file @ 0x35597a0] Setting default whitelist 'file,crypto'
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x3558f80] Format mov,mp4,m4a,3gp,3g2,mj2 probed
with size=2048 and score=100
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x3558f80] ISO: File Type Major Brand: isom
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x3558f80] Unknown dref type 0x08206c7275 size 12
Last message repeated 2 times
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x3558f80] Before avformat_find_stream_info()
pos: 673223828 bytes read:446246 seeks:1 nb_streams:3
[h264 @ 0x355b120] nal_unit_type: 7, nal_ref_idc: 3
[h264 @ 0x355b120] nal_unit_type: 8, nal_ref_idc: 3
[h264 @ 0x355b120] nal_unit_type: 6, nal_ref_idc: 0
[h264 @ 0x355b120] nal_unit_type: 5, nal_ref_idc: 3
[h264 @ 0x355b120] user data:"x264 - core 120 - H.264/MPEG-4 AVC codec -
Copyleft 2003-2011 - http://www.videolan.org/x264.html - options: cabac=1
ref=4 deblock=1:1:1 analyse=0x3:0x133 me=tesa subme=11 psy=1
psy_rd=0.40:0.00 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=1
cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=-2 threads=12
sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0
constrained_intra=0 bframes=16 b_pyramid=2 b_adapt=2 b_bias=0 direct=3
weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40
intra_refresh=0 rc_lookahead=60 rc=2pass mbtree=1 bitrate=8000 ratetol=1.0
qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40
aq=1:0.60"
[h264 @ 0x355b120] Reinit context to 3840x2160, pix_fmt: yuv420p
[h264 @ 0x355b120] no picture
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x3558f80] All info found
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x3558f80] After avformat_find_stream_info()
pos: 544489 bytes read:577318 seeks:2 frames:53
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/

Re: [FFmpeg-devel] Memcpy Operation Duration

[Ali KIZIL]

On Oct 18, 2016 11:08 PM, "Ronald S. Bultje"  wrote:
>
> Hi Ali,
>
> On Tue, Oct 18, 2016 at 3:57 PM, Ali KIZIL  wrote:
>
> > 2016-10-18 22:44 GMT+03:00 Sven C. Dack :
> >
> > > On 18/10/16 20:26, Ali KIZIL wrote:
> > >
> > >> Hi Everyone,
> > >>
> > >> Today, I was analyzing memcpy duration in FFmpeg. I noticed that it
is
> > >> taking longer time compared to an optimized SSE, SSE2, MMX, MMX2,
AVX or
> > >> AVX2 based memcpy operation.
> > >>
> > >> I tried march=corei7-avx2 compiled FFmpeg version, it does not change
> > the
> > >> duration of memcpy operation.
> > >> I also folowed https://trac.ffmpeg.org/wiki/C
> > >> ompilationGuide#PerformanceTips
> > >> .Same result. In addition, I tried gcc 6.2 if gcc if gcc is not
> > selecting
> > >> the correct flag. Same result again.
> > >>
> > >> This memcpy operations effect the fps decoding (and probably
encoding)
> > >> rates.
> > >>
> > >> In a case that uyvy422 to p010 3840x2160 unscaled convertion in
> > rawvideo,
> > >> fps rate increased from 44 fps to 52 fps on a Xeon E5 2630 v4.
> > >>
> > >> Do I miss anything when compiling FFmpeg for AVX2 or other flag
> > optimised,
> > >> or there need a fix in FFmpeg to direct some (or all)  memcpy
operations
> > >> to
> > >> a inherited memcpy operation which can decide flag for optimisation ?
> > >> Or there is no such need and I am on a wrong path ?
> > >>
> > >> (As a side note, FFmpeg works performance on i7 Extreme cores
compared
> > to
> > >> Xeon v4 processors.)
> > >
> > > Could be it's gcc's built-in version. It's been said that libc is
> > > occasionally better at it than gcc's built-in version.
> > >
> > > Use -fno-builtin-memcpy and see what difference it makes.
> >
>
> >
> I see, tomorrow morning I will give it a try.
> > Thank you for the good idea. If it increase performance, maybe it will
be a
> > good idea to make a configure option.
>
>
> configure has --extra-cflags=.. and --extra-ldflags=.. options to add
> custom CC CLI arguments.
>
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Hi Ronald,

Yes, I used extra flags to give march=native or march=corei7-avx2.
Tomorrow, I will try -fno-builtin-memcpy option with extra-cflag. I will
update the topic.

Thank you,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Memcpy Operation Duration

[Ali KIZIL]

2016-10-18 22:44 GMT+03:00 Sven C. Dack :

> On 18/10/16 20:26, Ali KIZIL wrote:
>
>> Hi Everyone,
>>
>> Today, I was analyzing memcpy duration in FFmpeg. I noticed that it is
>> taking longer time compared to an optimized SSE, SSE2, MMX, MMX2, AVX or
>> AVX2 based memcpy operation.
>>
>> I tried march=corei7-avx2 compiled FFmpeg version, it does not change the
>> duration of memcpy operation.
>> I also folowed https://trac.ffmpeg.org/wiki/C
>> ompilationGuide#PerformanceTips
>> .Same result. In addition, I tried gcc 6.2 if gcc if gcc is not selecting
>> the correct flag. Same result again.
>>
>> This memcpy operations effect the fps decoding (and probably encoding)
>> rates.
>>
>> In a case that uyvy422 to p010 3840x2160 unscaled convertion in rawvideo,
>> fps rate increased from 44 fps to 52 fps on a Xeon E5 2630 v4.
>>
>> Do I miss anything when compiling FFmpeg for AVX2 or other flag optimised,
>> or there need a fix in FFmpeg to direct some (or all)  memcpy operations
>> to
>> a inherited memcpy operation which can decide flag for optimisation ?
>> Or there is no such need and I am on a wrong path ?
>>
>> (As a side note, FFmpeg works performance on i7 Extreme cores compared to
>> Xeon v4 processors.)
>>
>> Kind Regards,
>> Ali KIZIL
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> Could be it's gcc's built-in version. It's been said that libc is
> occasionally better at it than gcc's built-in version.
>
> Use -fno-builtin-memcpy and see what difference it makes.
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


I see, tomorrow morning I will give it a try.
Thank you for the good idea. If it increase performance, maybe it will be a
good idea to make a configure option.

Kind Regards,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Memcpy Operation Duration

[Ali KIZIL]

Hi Everyone,

Today, I was analyzing memcpy duration in FFmpeg. I noticed that it is
taking longer time compared to an optimized SSE, SSE2, MMX, MMX2, AVX or
AVX2 based memcpy operation.

I tried march=corei7-avx2 compiled FFmpeg version, it does not change the
duration of memcpy operation.
I also folowed https://trac.ffmpeg.org/wiki/CompilationGuide#PerformanceTips
.Same result. In addition, I tried gcc 6.2 if gcc if gcc is not selecting
the correct flag. Same result again.

This memcpy operations effect the fps decoding (and probably encoding)
rates.

In a case that uyvy422 to p010 3840x2160 unscaled convertion in rawvideo,
fps rate increased from 44 fps to 52 fps on a Xeon E5 2630 v4.

Do I miss anything when compiling FFmpeg for AVX2 or other flag optimised,
or there need a fix in FFmpeg to direct some (or all)  memcpy operations to
a inherited memcpy operation which can decide flag for optimisation ?
Or there is no such need and I am on a wrong path ?

(As a side note, FFmpeg works performance on i7 Extreme cores compared to
Xeon v4 processors.)

Kind Regards,
Ali KIZIL
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libswscale/swscale_unscaled.c: UHD Resolution Performance Increase for Color Space Convertions / NVENC Related

[Ali KIZIL]

2016-10-03 14:39 GMT+03:00 Carl Eugen Hoyos :

> 2016-10-03 13:11 GMT+02:00 Ali KIZIL :
> > 2016-10-03 14:09 GMT+03:00 Carl Eugen Hoyos :
> >
> >> 2016-10-03 12:48 GMT+02:00 Ali KIZIL :
> >>
> >> > Yes, Alpha channel is not managed.
> >> >
> >> > So it should be;
> >> >
> >> >> +/* yuv422p10_to_yuv420p */
> >> >> +if ((srcFormat == AV_PIX_FMT_YUV422P10) &&
> >> >> +(dstFormat == AV_PIX_FMT_YUV420P))
> >> >> +c->swscale = yuv422p10ToYuv420pWrapper;
> >>
> >> (Apart from "too many parenthesis")
> >> I would prefer if alpha gets handled.
>
> > Got it. I dont have any source with alpha.
>
> This is about conversion of frames without alpha into
> frames with an alpha channel, so I don't think you need
> any source with alpha.
> Just set the opacity to 0xFF.
>
> I suspect you should pay attention to the dithering for
> the moment though.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Hello Carl,

OK, Well noted the info about 0xFF.
I will do it.

You and Hendrik are right. I googled around and understood what you mean by
dithering.
This will happen for function 10bit to 8bit
convertion yuv422p10ToYuv420pWrapper.
Rest 2 functions are 10bit to 10bit and 8 bit to 10bit, so they do not have
dithering problem.

I need to check how to do interpolation. Any example will be helpful.

Kind Regards,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libswscale/swscale_unscaled.c: UHD Resolution Performance Increase for Color Space Convertions / NVENC Related

[Ali KIZIL]

2016-10-03 14:09 GMT+03:00 Carl Eugen Hoyos :

> 2016-10-03 12:48 GMT+02:00 Ali KIZIL :
>
> > Yes, Alpha channel is not managed.
> >
> > So it should be;
> >
> >> +/* yuv422p10_to_yuv420p */
> >> +if ((srcFormat == AV_PIX_FMT_YUV422P10) &&
> >> +(dstFormat == AV_PIX_FMT_YUV420P))
> >> +c->swscale = yuv422p10ToYuv420pWrapper;
>
> (Apart from "too many parenthesis")
> I would prefer if alpha gets handled.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Hello Carl,

Got it. I dont have any source with alpha. Even I do blind coding, I am not
sure if it will be working OK.
So, maybe it will be a better idea that if someone improve code for alpha
channel.

Kind Regards,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libswscale/swscale_unscaled.c: UHD Resolution Performance Increase for Color Space Convertions / NVENC Related

[Ali KIZIL]

2016-10-03 13:28 GMT+03:00 Hendrik Leppkes :

> On Mon, Oct 3, 2016 at 11:35 AM, Ali KIZIL  wrote:
> > Hello,
> >
> > This patch is done for performance increase on UHD or above resolution
> > color space convertions.
> > Some SDI sources provide yuv422p10 for 10bit source and uyvy422 for 8 bit
> > source.
> > To encode these sources with NVENC 10 bits, there is a need to convert
> > these color spaces to P010.
> >
> > Before patch for UHD and above resolutions, convertion could not exceed
> > ~25-30 fps, which can not be used for a 50 fps encoding.
> > This patch fixes this problem.
> >
> > Also, color space convertion speed for 10bit YUV422P to 8bit YUV420P is
> > having the same problem.
> > If anybody wants to encode 10 bits source in 8 bits for UHD or above
> > resolutions could not achive high frame rate ratio as well.
> > This patch also fixes this problem.
> >
> > I think it will be good to apply this patch to avoid performance loss in
> > high resolutions.
> >
>
> These conversion functions butcher quality by using only every second
> row of chroma for 422 -> 420 conversions without any interpolation,
> and they don't dither for 10->8 bit conversions.
> Not sure its a good idea to do that, even more so without an option to
> defeat these low-quality variants with the swscale flags.
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Hello Hendrik,

Also, Can I assume that the problem is for 10 bit to 8 bit convertion ?
Because, other 2 functions do 10bit to 10bit or 8bit to 10 bit operation.
I can dividepatch to 3 sub-patches as well.

Kind Regards,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libswscale/swscale_unscaled.c: UHD Resolution Performance Increase for Color Space Convertions / NVENC Related

[Ali KIZIL]

2016-10-03 13:06 GMT+03:00 Carl Eugen Hoyos :

> 2016-10-03 11:35 GMT+02:00 Ali KIZIL :
>
> > +/* yuv422p10_to_yuv420p */
> > +if ((srcFormat == AV_PIX_FMT_YUV422P10 || srcFormat ==
> AV_PIX_FMT_YUVA422P10) &&
> > +(dstFormat == AV_PIX_FMT_YUV420P) || srcFormat ==
> AV_PIX_FMT_YUVA420P)
> > +c->swscale = yuv422p10ToYuv420pWrapper;
>
> I believe there is something wrong.
>
> The actual wrapper function is missing alpha handling.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Hello Carl,

Yes, Alpha channel is not managed.

So it should be;

> +/* yuv422p10_to_yuv420p */
> +if ((srcFormat == AV_PIX_FMT_YUV422P10) &&
> +(dstFormat == AV_PIX_FMT_YUV420P))
> +c->swscale = yuv422p10ToYuv420pWrapper;

I will get it corrected after collecting all comments.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libswscale/swscale_unscaled.c: UHD Resolution Performance Increase for Color Space Convertions / NVENC Related

[Ali KIZIL]

2016-10-03 13:28 GMT+03:00 Hendrik Leppkes :

> On Mon, Oct 3, 2016 at 11:35 AM, Ali KIZIL  wrote:
> > Hello,
> >
> > This patch is done for performance increase on UHD or above resolution
> > color space convertions.
> > Some SDI sources provide yuv422p10 for 10bit source and uyvy422 for 8 bit
> > source.
> > To encode these sources with NVENC 10 bits, there is a need to convert
> > these color spaces to P010.
> >
> > Before patch for UHD and above resolutions, convertion could not exceed
> > ~25-30 fps, which can not be used for a 50 fps encoding.
> > This patch fixes this problem.
> >
> > Also, color space convertion speed for 10bit YUV422P to 8bit YUV420P is
> > having the same problem.
> > If anybody wants to encode 10 bits source in 8 bits for UHD or above
> > resolutions could not achive high frame rate ratio as well.
> > This patch also fixes this problem.
> >
> > I think it will be good to apply this patch to avoid performance loss in
> > high resolutions.
> >
>
> These conversion functions butcher quality by using only every second
> row of chroma for 422 -> 420 conversions without any interpolation,
> and they don't dither for 10->8 bit conversions.
> Not sure its a good idea to do that, even more so without an option to
> defeat these low-quality variants with the swscale flags.
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Hello Hendrik,

Yes, only every second row of chroma for 422 -> 420 conversions without any
interpolation is used.
Where I can find an interpolation example ? Also, the code is done for
performance criteria for UHD and above resolution in real time encoding.
In myside test, I didnt notice a gap. For sure, I am not a video quality
expert. Can you tell me how to compare quality ?

Can you explain more for "they don't dither for 10->8 bit conversions." I
couldnt understand this.

Kind Regards,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libswscale/swscale_unscaled.c: UHD Resolution Performance Increase for Color Space Convertions / NVENC Related

[Ali KIZIL]

Hello,

This patch is done for performance increase on UHD or above resolution
color space convertions.
Some SDI sources provide yuv422p10 for 10bit source and uyvy422 for 8 bit
source.
To encode these sources with NVENC 10 bits, there is a need to convert
these color spaces to P010.

Before patch for UHD and above resolutions, convertion could not exceed
~25-30 fps, which can not be used for a 50 fps encoding.
This patch fixes this problem.

Also, color space convertion speed for 10bit YUV422P to 8bit YUV420P is
having the same problem.
If anybody wants to encode 10 bits source in 8 bits for UHD or above
resolutions could not achive high frame rate ratio as well.
This patch also fixes this problem.

I think it will be good to apply this patch to avoid performance loss in
high resolutions.

Kind Regards,


0001-For-10bit-SDI-Sources-to-10bit-NVENC-Encode.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] swscale: add unscaled conversion from yuv420p to p010

[Ali KIZIL]

2016-09-05 12:04 GMT+03:00 Carl Eugen Hoyos :

> 2016-09-05 10:53 GMT+02:00 Ali KIZIL :
>
> > Is there any obstacle to release this patch ?
>
> Which patch?
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Sorry Carl, maybe I missed. I mean the patch for "add unscaled conversion
from yuv420p to p010".
I see the one "add unscaled conversion from yuv420p10 to p010" in github,
but I can not see the one "add unscaled conversion from yuv420p to p010".
Lastly it was confirmed that padding zeros were not needed.

Kind Regards,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] swscale: add unscaled conversion from yuv420p to p010

[Ali KIZIL]

2016-09-04 20:34 GMT+03:00 Ronald S. Bultje :

> Hi,
>
> On Sep 4, 2016 5:42 PM, "Timo Rothenpieler"  wrote:
> >
> > On 9/4/2016 4:06 PM, Carl Eugen Hoyos wrote:
> > > 2016-09-04 16:02 GMT+02:00 Timo Rothenpieler :
> > >> The purpose of this patch is to make conversion from
> > >> yuv420p (8 bit) to p010 (10 bit) fast.
> > >
> > > Do I understand you correctly that your patch is
> > > faster without the change I suggested?
> >
> > With the &:
> > [bench @ 0x600045b80] t:0.011178 avg:0.011172 max:0.018297 min:0.010505
> >
> > Without it:
> > [bench @ 0x600045b80] t:0.008455 avg:0.008517 max:0.015815 min:0.007941
> >
> > So it is quite a bit faster.
> >
> > Tested with nvenc hevc10 encoding, and the output is visually identical,
> > and the file size is also exactly the same.
> > So it seems to cleanly ignore the unused bits.
> >
> > Also, given that at least microsoft argues with upcasting to 16 bit, the
> > approach without zeroing the lsb would be more accurate, as
> >
> > t << 8 | t
> >
> > is how one would convert 8 bit to 16 bit.
> >
> >
> > So I'd say going with the faster approach here should be fine.
> > If at some point someone runs into something that chokes on the bits
> > being non-zero, which I think is highly unlikely, it can be changed back.
>
> Sounds good, thanks for testing and confirming.
>
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Hello,

Is there any obstacle to release this patch ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] swscale: add unscaled conversion from yuv420p to p010

[Ali KIZIL]

Hi,

On Sep 4, 2016 5:33 PM, "Ronald S. Bultje"  wrote:
>
> Hi,
>
> On Sun, Sep 4, 2016 at 10:06 AM, Carl Eugen Hoyos 
> wrote:
>
> > 2016-09-04 16:02 GMT+02:00 Timo Rothenpieler :
> > > The purpose of this patch is to make conversion from
> > > yuv420p (8 bit) to p010 (10 bit) fast.
> >
> > Do I understand you correctly that your patch is
> > faster without the change I suggested?
>
>
> We should also consider whether not zeroing out the LSBs affects other
> pieces of code (or hardware) which support p010 as input.
>
> If they all ignore the LSBs as the spec seems to require, I agree with
> Carl. If they break or the output changes, it may be more complicated.
>
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I can test the patch in Monday with and without zeros and report if it
break anything for Nvenc Hevc encoding.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] swscale: add unscaled conversion from yuv420p to p010

[Ali KIZIL]

On Sep 4, 2016 5:02 PM, "Timo Rothenpieler"  wrote:
>
> > Finally, with the change, the function can also be used
> > for P016, note that I tried to object to P010: It does not
> > serve any real purpose, if I remember correctly, the
> > explanation for the commit was that there is a bug in
> > FFmpeg's pix_fmt decision routine that needed to
> > be worked-around ("hacked").
>
> It's the input format to nvenc in 10bit mode.
> The purpose of this patch is to make conversion from yuv420p (8 bit) to
> p010 (10 bit) fast.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Especially for 4K and UHD frames.
You may not notice conversion speed change in HD or SD resolutions.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] swscale: add unscaled copy from yuv420p10 to p010

[Ali KIZIL]

Hi Oliver,

Yes, for same quality I also noticed a bandwidth usage drop like 4-6%. This
is my case.
But as you know it depends on the samples you work.

For CBR, you are right, it should bring a higher quality. I compared decode
of PSNR for CBR 8 bits and 10 bits HD NVENC HEVC encodded content with
motion video. 10 bits encoding is slightly better for a 8-bits YUV420P
source video.

Kind Regards,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] swscale: add unscaled copy from yuv420p10 to p010

[Ali KIZIL]

Hello Timo,

I tested your patch. It increases UHD HEVC 10 bits Main10 encoding
performance a lot while doing YUV420P10LE to P010LE (same level to Oliver's
original 10 bits HEVC encoding patch).

Your patch together with current FFmpeg git source, encoding performance
increase from 40-42 fps to 69-72 fps.

Just one note; encoding from YUV420P to P010LE is still slow. It will be
nice a similar patch is done for YUV420P 8bits to P010LE 10 bits
convertion. (For reason:
http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf)

ffmpeg version N-81508-g99882d0 Copyright (c) 2000-2016 the FFmpeg
developers
  built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
  configuration: --prefix=/opt/ffmpeg --enable-shared --enable-static
--enable-nonfree --enable-gpl --extra-cflags='-I/opt/ffmpeg/include
-I/usr/local/include' --extra-ldflags=-L/opt/ffmpeg/lib
--bindir=/opt/ffmpeg/bin --extra-libs=-ldl --enable-libx264
--enable-libx265 --enable-nonfree --enable-gpl --enable-nvenc
--enable-vdpau --enable-libzvbi --enable-libfdk-aac --enable-libzimg
--enable-avresample --enable-libnpp --enable-cuda
  libavutil  55. 29.100 / 55. 29.100
  libavcodec 57. 54.101 / 57. 54.101
  libavformat57. 48.101 / 57. 48.101
  libavdevice57.  0.102 / 57.  0.102
  libavfilter 6. 58.100 /  6. 58.100
  libavresample   3.  0.  0 /  3.  0.  0
  libswscale  4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc54.  0.100 / 54.  0.100
Routing option err_detect to both codec and muxer layer
Input #0, matroska,webm, from
'/media/usb0/4K_TS/SES.Astra.UHD.Test.1.2160p.UHDTV.AAC.HEVC.x265-LiebeIst.mkv':
  Metadata:
encoder : libebml v1.3.1 + libmatroska v1.4.2
creation_time   : 2015-10-03T13:49:42.00Z
  Duration: 00:01:49.29, start: 0.816000, bitrate: 18484 kb/s
Stream #0:0: Video: hevc (Main 10), 1 reference frame, yuv420p10le(tv),
3840x2160 [SAR 1:1 DAR 16:9], 60 fps, 60 tbr, 1k tbn, 60 tbc (default)
Metadata:
  BPS : 18497251
  BPS-eng : 18497251
  DURATION: 00:01:48.45000
  DURATION-eng: 00:01:48.45000
  NUMBER_OF_FRAMES: 6507
  NUMBER_OF_FRAMES-eng: 6507
  NUMBER_OF_BYTES : 250753360
  NUMBER_OF_BYTES-eng: 250753360
  _STATISTICS_WRITING_APP: mkvmerge v8.0.0 ('Til The Day That I Die')
64bit
  _STATISTICS_WRITING_APP-eng: mkvmerge v8.0.0 ('Til The Day That I
Die') 64bit
  _STATISTICS_WRITING_DATE_UTC: 2015-10-03 13:49:42
  _STATISTICS_WRITING_DATE_UTC-eng: 2015-10-03 13:49:42
  _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
  _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp (default)
Metadata:
  BPS : 124607
  BPS-eng : 124607
  DURATION: 00:01:49.26700
  DURATION-eng: 00:01:49.26700
  NUMBER_OF_FRAMES: 4669
  NUMBER_OF_FRAMES-eng: 4669
  NUMBER_OF_BYTES : 1701940
  NUMBER_OF_BYTES-eng: 1701940
  _STATISTICS_WRITING_APP: mkvmerge v8.0.0 ('Til The Day That I Die')
64bit
  _STATISTICS_WRITING_APP-eng: mkvmerge v8.0.0 ('Til The Day That I
Die') 64bit
  _STATISTICS_WRITING_DATE_UTC: 2015-10-03 13:49:42
  _STATISTICS_WRITING_DATE_UTC-eng: 2015-10-03 13:49:42
  _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
  _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
[graph 0 input from stream 0:0 @ 0x78bfe0] w:3840 h:2160 pixfmt:yuv420p10le
tb:1/1000 fr:60/1 sar:1/1 sws_param:flags=2
[scaler for output stream 0:0 @ 0x78c2e0] w:3840 h:2160 flags:'bicubic'
interl:0
Incompatible pixel format 'yuv420p10le' for codec 'nvenc_hevc',
auto-selecting format 'p010le'
[scaler for output stream 0:0 @ 0x78c2e0] w:3840 h:2160 fmt:yuv420p10le
sar:1/1 -> w:3840 h:2160 fmt:p010le sar:1/1 flags:0x4
[graph 1 input from stream 0:1 @ 0x77f760] tb:1/44100 samplefmt:fltp
samplerate:44100 chlayout:0x3
-async is forwarded to lavfi similarly to -af
aresample=async=1:min_hard_comp=0.10:first_pts=0.
[graph 1 aresample for input stream 0:1 @ 0x7c92a0] ch:2 chl:stereo
fmt:fltp r:44100Hz -> ch:2 chl:stereo fmt:s16 r:44100Hz
[nvenc_hevc @ 0x78da80] This encoder is deprecated, use 'hevc_nvenc' instead
[nvenc_hevc @ 0x78da80] Loaded Nvenc version 7.0
[nvenc_hevc @ 0x78da80] Nvenc initialized successfully
[nvenc_hevc @ 0x78da80] 1 CUDA capable devices found
[nvenc_hevc @ 0x78da80] [ GPU #0 - < TITAN X (Pascal) > has Compute SM 6.1 ]
[nvenc_hevc @ 0x78da80] supports NVENC
[mpegts @ 0x798d80] Using AVStream.codec to pass codec parameters to muxers
is deprecated, use AVStream.codecpar instead.
Last message repeated 1 times
[mpegts @ 0x798d80] muxrate 3000, pcr every 398 pkts, sdt every 9973,
pat/pmt every 1994 pkts
Output #0, mpegts, to 'udp://
233.33.33.1:5001?pkt_size=1316&buffer_size=1500&reuse=1&localaddr=192.168.2.94&bitrate=3000&fifo_size=100
':
  Metadata:
service_n

Re: [FFmpeg-devel] Performance of P010LE/BE pixel convertion

[Ali KIZIL]

>* On 1 Sep 2016, at 14:59, Timo Rothenpieler <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>> wrote:
*

>

>* Am 01.09.2016 um 13:44 schrieb Ronald S. Bultje:
*

>>* Hi Timo,
*

>>

>>* On Thu, Sep 1, 2016 at 7:34 AM, Timo Rothenpieler ><http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>>
*

>>* wrote:
*

>>

>>>>* Hi,
*

>>>>

>>>>* On Thu, Sep 1, 2016 at 7:00 AM, Ali KIZIL >>><http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>> wrote:
*

>>>>

>>>>>* Hi Oliver,
*

>>>>>

>>>>>* I just setup my DDR3 RAM speed to 2133 Mhz on i7 4960x server. It dosnt
*

>>>>>* make a much difference. FPS is still waiving 41-44 fps for UHD P010LE
*

>>>* HEVC
*

>>>>>* Main 10 encoding.
*

>>>>>

>>>>>* Also, rawvideo P010LE encodding waiving 39-42 fps. For your note;while
*

>>>* FPS
*

>>>>>* waves from 39-42 fps for YUV420P to P010LE, YUV420P to YUV420P10LE fps
*

>>>* is
*

>>>>>* like 75-76:
*

>>>>

>>>>

>>>>* I think this is expected, the p010le conversion is C (no SIMD). The
*

>>>>* yuv420p10le conversion is using x86 SIMD (probably AVX).
*

>>>>

>>>>* To fix this, add x86 SIMD implementations of the p010le conversions in
*

>>>>* swscale. Better yet, add direct conversions from yuv420p10 (which I
*

>>>* assume
*

>>>>* is the internal format of your actual source after decoding?) to p010le,
*

>>>>* first C and then later x86 SIMD.
*

>>>

>>>* I think 40-50 FPS is quite a nice result for UHD with the plain stupid C
*

>>>* implementation.
*

>>>

>>

>>* I agree. I didn't mean to offend you for writing bad C code, or for not
*

>>* writing SIMD code. I simply meant to point out that if you want to go from
*

>>* 40-50fps to 100+fps, SIMD is probably the easiest way to move in that
*

>>* direction.
*

>

>* Didn't take it like that, was more a general remark.
*

>* The C implementation is as straight forward as it gets.
*

>* I wonder if re-arranging the code, could make it more efficient though.
*

>* Stuff like moving some if() checks out of the loop, and duplicating the
*

>* loop instead, or other tricks that lead to gcc generating faster code.
*

I’m not sure it’ll make much difference - you may recall my original
patch had code in nvenc.c that took a YUV420P input and converted it
to P010 as it fed the frames into the encoder. Out of curiosity I did
some quick testing of this versus the code that has since been added
in swscale to support P010 conversions and could find no difference in
the time it took to encode my 60s sample. Not an exhaustive test by
any means, but if there was any obvious inefficiency in the swscale
code then I’d have expected to see some difference but I tested my
sample three times with each version of the code and the time taken to
encode was virtually identical every time.

Oliver

Hi Oliver,

I followed your comment and tried your original patch. It works much
much better. FPS goes up to 88 - 92 fps for UHD HEVC Main10
YUV420P10LE.

I attached the nvenc.c file for your check as well (just I added the 2
convertion functions and did the change in YUV420P10LE pixel format
selection part).


ffmpeg version N-81508-g99882d0 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
  configuration: --prefix=/opt/ffmpeg --enable-shared --enable-static
--enable-nonfree --enable-gpl --extra-cflags='-I/opt/ffmpeg/include
-I/usr/local/include' --extra-ldflags=-L/opt/ffmpeg/lib
--bindir=/opt/ffmpeg/bin --extra-libs=-ldl --enable-libx264
--enable-libx265 --enable-nonfree --enable-gpl --enable-nvenc
--enable-vdpau --enable-libzvbi --enable-libfdk-aac --enable-libzimg
--enable-avresample --enable-libnpp --enable-cuda
  libavutil  55. 29.100 / 55. 29.100
  libavcodec 57. 54.101 / 57. 54.101
  libavformat57. 48.101 / 57. 48.101
  libavdevice57.  0.102 / 57.  0.102
  libavfilter 6. 58.100 /  6. 58.100
  libavresample   3.  0.  0 /  3.  0.  0
  libswscale  4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc54.  0.100 / 54.  0.100
Routing option err_detect to both codec and muxer layer
Input #0, matroska,webm, from
'/media/usb1/4K_TS/SES.Astra.UHD.Test.1.2160p.UHDTV.AAC.HEVC.x265-LiebeIst.mkv':
  Metadata:
encoder : libebml v1.3.1 + libmatroska v1.4.2
creation_time   : 2015-10-03T13:49:42.00Z
  Duration: 00:01:49.29, start: 0.816000, bitrate: 18484 kb/s
Stream #0:0: Video: hevc (Main 10), 1 reference frame,
yuv420p10le(tv), 3840x2160 [SAR 1:1 DAR 16:9], 60 fps, 60 tbr, 1k 

[FFmpeg-devel] Performance of P010LE/BE pixel convertion

[Ali KIZIL]

Hi All,

I want to give answers to some questions:

1) @Oliver, thank you for explanations. I tried yuv444p16le, fps is a bit
less to 32-34 fps. Here is a short log:

Stream #0:0(und): Video: hevc (nvenc_hevc) (Main 10), 1 reference
frame, yuv444p16le, 3840x2160 [SAR 1:1 DAR 16:9], q=-1--1, 28000 kb/s, 60
fps, 90k tbn, 60 tbc (default)
Metadata:
  creation_time   : 2013-12-17T16:40:26.00Z
  handler_name: GPAC ISO Video Handler
  encoder : Lavc57.54.101 nvenc_hevc
Side data:
  cpb: bitrate max/min/avg: 2800/0/2800 buffer size: 2800
vbv_delay: -1
Stream #0:1(und): Audio: mp2, 48000 Hz, stereo, s16, delay 481, padding
0, 384 kb/s (default)
Metadata:
  creation_time   : 2013-12-17T16:40:28.00Z
  handler_name: GPAC ISO Audio Handler
  encoder : Lavc57.54.101 mp2
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> hevc (nvenc_hevc))
  Stream #0:2 -> #0:1 (ac3 (native) -> mp2 (native))
Press [q] to stop, [?] for help
[h264 @ 0x1549cc0] Reinit context to 3840x2160, pix_fmt: yuv420p
[AVBSFContext @ 0x15da860] The input looks like it is Annex B alreadyA
speed=   0x
frame= 1225 fps= 34 q=16.0 Lsize=   74899kB time=00:00:20.43
bitrate=30027.8kbits/s speed=0.565x

2) @Timo, I just want to share my test results on the work done to see if
we can catch a chance to increase performance by solving the bottleneck. If
you target to do real time UHD HEVC 10 bits encoding via Nvidia Pascal
GPUs, 50 fps is a need to reach as standart currently stands there.

3) @Ronald, you are totally right 8 bits to 10 bits convertion makes no
sense. I did it as my sample in hand was so. Now, I did the same test from
YUV420P10LE to P010LE as below. FPS waves from 41-42 fps:

root@kizil105:/opt/ffmpeg# /opt/ffmpeg/bin/ffmpeg -loglevel verbose
-ignore_unknown -probesize 1 -async 1 -thread_queue_size 2048
-err_detect compliant   -i
/media/usb1/4K_TS/SES.Astra.UHD.Test.1.2160p.UHDTV.AAC.HEVC.x265-LiebeIst.mkv
 -c:v:0 rawvideo  -c:a:0 pcm_s16le  -f nut -pix_fmt p010le -y /dev/null
ffmpeg version N-81508-g99882d0 Copyright (c) 2000-2016 the FFmpeg
developers
  built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
  configuration: --prefix=/opt/ffmpeg --enable-shared --enable-static
--enable-nonfree --enable-gpl --extra-cflags='-I/opt/ffmpeg/include
-I/usr/local/include' --extra-ldflags=-L/opt/ffmpeg/lib
--bindir=/opt/ffmpeg/bin --extra-libs=-ldl --enable-libx264
--enable-libx265 --enable-nonfree --enable-gpl --enable-nvenc
--enable-vdpau --enable-libzvbi --enable-libfdk-aac --enable-libzimg
--enable-avresample --enable-libnpp --enable-cuda
  libavutil  55. 29.100 / 55. 29.100
  libavcodec 57. 54.101 / 57. 54.101
  libavformat57. 48.101 / 57. 48.101
  libavdevice57.  0.102 / 57.  0.102
  libavfilter 6. 58.100 /  6. 58.100
  libavresample   3.  0.  0 /  3.  0.  0
  libswscale  4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc54.  0.100 / 54.  0.100
Routing option err_detect to both codec and muxer layer
Input #0, matroska,webm, from
'/media/usb1/4K_TS/SES.Astra.UHD.Test.1.2160p.UHDTV.AAC.HEVC.x265-LiebeIst.mkv':
  Metadata:
encoder : libebml v1.3.1 + libmatroska v1.4.2
creation_time   : 2015-10-03T13:49:42.00Z
  Duration: 00:01:49.29, start: 0.816000, bitrate: 18484 kb/s
Stream #0:0: Video: hevc (Main 10), 1 reference frame, yuv420p10le(tv),
3840x2160 [SAR 1:1 DAR 16:9], 60 fps, 60 tbr, 1k tbn, 60 tbc (default)
Metadata:
  BPS : 18497251
  BPS-eng : 18497251
  DURATION: 00:01:48.45000
  DURATION-eng: 00:01:48.45000
  NUMBER_OF_FRAMES: 6507
  NUMBER_OF_FRAMES-eng: 6507
  NUMBER_OF_BYTES : 250753360
  NUMBER_OF_BYTES-eng: 250753360
  _STATISTICS_WRITING_APP: mkvmerge v8.0.0 ('Til The Day That I Die')
64bit
  _STATISTICS_WRITING_APP-eng: mkvmerge v8.0.0 ('Til The Day That I
Die') 64bit
  _STATISTICS_WRITING_DATE_UTC: 2015-10-03 13:49:42
  _STATISTICS_WRITING_DATE_UTC-eng: 2015-10-03 13:49:42
  _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
  _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp (default)
Metadata:
  BPS : 124607
  BPS-eng : 124607
  DURATION: 00:01:49.26700
  DURATION-eng: 00:01:49.26700
  NUMBER_OF_FRAMES: 4669
  NUMBER_OF_FRAMES-eng: 4669
  NUMBER_OF_BYTES : 1701940
  NUMBER_OF_BYTES-eng: 1701940
  _STATISTICS_WRITING_APP: mkvmerge v8.0.0 ('Til The Day That I Die')
64bit
  _STATISTICS_WRITING_APP-eng: mkvmerge v8.0.0 ('Til The Day That I
Die') 64bit
  _STATISTICS_WRITING_DATE_UTC: 2015-10-03 13:49:42
  _STATISTICS_WRITING_DATE_UTC-eng: 2015-10-03 13:49:42
  _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
  _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NU

[FFmpeg-devel] Performance of P010LE/BE pixel convertion

[Ali KIZIL]

Hi Oliver,

I just setup my DDR3 RAM speed to 2133 Mhz on i7 4960x server. It dosnt
make a much difference. FPS is still waiving 41-44 fps for UHD P010LE HEVC
Main 10 encoding.

Also, rawvideo P010LE encodding waiving 39-42 fps. For your note;while FPS
waves from 39-42 fps for YUV420P to P010LE, YUV420P to YUV420P10LE fps is
like 75-76:

Stream #0:0: Video: rawvideo, 1 reference frame (Y3[11][10] /
0xA0B3359), yuv420p10le, 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 60
fps, 61440 tbn, 60 tbc (default)
Metadata:
  creation_time   : 2013-12-17T16:40:26.00Z
  X-Language  : und
  handler_name: GPAC ISO Video Handler
  encoder : Lavc57.54.101 rawvideo
Stream #0:1: Audio: pcm_s16le (PSD[16] / 0x10445350), 48000 Hz,
5.1(side), s16, 4608 kb/s (default)
Metadata:
  creation_time   : 2013-12-17T16:40:28.00Z
  X-Language  : und
  handler_name: GPAC ISO Audio Handler
  encoder : Lavc57.54.101 pcm_s16le
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> rawvideo (native))
  Stream #0:2 -> #0:1 (ac3 (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
[h264 @ 0x1c4e940] Reinit context to 3840x2160, pix_fmt: yuv420p
frame= 2289 fps= 76 q=-0.0 size=55279649kB time=00:00:38.16
bitrate=11865083.7kbits/s speed=1.26x

So, bottleneck for P010LE encoding is not coming from RAM. I will do the
tests on a more powerful server as I mentioned before (Dual Xeon E5-2630 v4
with DDR 64 GB Ram)

And is it a mendetoary for Nvidia SDK to work with P010LE for 10bits
encoding HEVC?

Regards,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Performance of P010LE/BE pixel convertion

[Ali KIZIL]

What CPU are you using? It's presumably going to vary wildly from one
CPU to another?

>* On 1 Sep 2016, at 08:52, Ali KIZIL <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>> wrote:
*

>

>* Hi all,
*

>

>* I tested P010LE pixel convertion from YUV420P in NVENC Main 10 HEVC UHD 50
*

>* fps encoding on Nvidia Pascal Titan X GPU:
*

>

>* Nvidia Pascal Titan X GPU can not reach to 50 fps on Main 10 P010LE HEVC
*

>* encoding:
*

>

>* ffmpeg -loglevel verbose -i
*

>* /media/usb1/4k_sampels/Samsung_SUHD_Picture_Quality\ Demo_Nano_Crystal\
*

>* Display_UK-Version.mp4 -c:v:0 nvenc_hevc -preset hp -cbr 1 -2pass 0 -r 50
*

>* -vb 28000k -minrate 28000k -maxrate 28000k -bufsize 28000k -muxrate 3k
*

>* -c:a:0 aac -b:a:0 192k -pix_fmt p010le 'udp://233.33.33.1:5001'
*

>

>* FPS waves around 41-43 fps. If same command with YUV420P, it reaches to 120
*

>* - 130 fps.
*

>

>* GPU NVENC Load:
*

>* nvidia-smi dmon -i 0
*

>* gpu pwr temp sm mem enc dec mclk pclkIdx W C % % % % MHz MHz
*

>

>* 08167 9 241 0  4513  1809
*

>* 08066 9 241 0  4513  1809
*

>* 08167 9 242 0  4513  1809
*

>* 0806710 241 0  4513  1809
*

>* 08167 9 244 0  4513  1809
*

>

>* I think bottleneck is not at GPU side, pixel convertion maybe needs speed
*

>* up improvement.
*

>

>

>* If codec changed to rawvideo to test pixel format convertion performance
*

>* testing, FPS again waves around 39-40 fps
*

>

>

>* I wanted to state these test reults.
*

>

>

>* Kind Regards,
*

>* ___
*

>* ffmpeg-devel mailing list
*

>* ffmpeg-devel at ffmpeg.org <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
*

>* http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 
><http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
*


The test is done on "Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz" with 32 GB
DDR3 (8pcs. x 4GB  Kingston KHX2133C11D3) with Linux kizil105
3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015
x86_64 x86_64 x86_64 GNU/Linux.

For memory dmidecode shows 1333 Mhz. I will check my BIOS settings if RAM
speed set wrong and update the mail list.
sudo dmidecode --type memory
# dmidecode 2.12
# SMBIOS entry point at 0x000f04c0
SMBIOS 2.7 present.

Handle 0x0029, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 96 GB
Error Information Handle: Not Provided
Number Of Devices: 4

Handle 0x002B, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x0029
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: Node0_Dimm0
Bank Locator: Node0_Bank0
Type: DDR3
Type Detail: Unbuffered (Unregistered)
Speed: 1333 MHz
Manufacturer: Kingston
Serial Number: 6A2AF2C5
Asset Tag: Dimm0_AssetTag
Part Number: KHX2133C11D3/
Rank: 2
Configured Clock Speed: 1333 MHz

As a final note, I will test same settings on a server with Dual Xeon E5-
2630 V4 with 64 GB (4 pcs x 16 GB) DDR4 2133 Mhz Ram. I will update for
this as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Performance of P010LE/BE pixel convertion

[Ali KIZIL]

Hi all,

I tested P010LE pixel convertion from YUV420P in NVENC Main 10 HEVC UHD 50
fps encoding on Nvidia Pascal Titan X GPU:

Nvidia Pascal Titan X GPU can not reach to 50 fps on Main 10 P010LE HEVC
encoding:

ffmpeg -loglevel verbose -i
/media/usb1/4k_sampels/Samsung_SUHD_Picture_Quality\ Demo_Nano_Crystal\
Display_UK-Version.mp4 -c:v:0 nvenc_hevc -preset hp -cbr 1 -2pass 0 -r 50
-vb 28000k -minrate 28000k -maxrate 28000k -bufsize 28000k -muxrate 3k
-c:a:0 aac -b:a:0 192k -pix_fmt p010le 'udp://233.33.33.1:5001'

FPS waves around 41-43 fps. If same command with YUV420P, it reaches to 120
- 130 fps.

GPU NVENC Load:
nvidia-smi dmon -i 0
gpu pwr temp sm mem enc dec mclk pclkIdx W C % % % % MHz MHz

08167 9 241 0  4513  1809
08066 9 241 0  4513  1809
08167 9 242 0  4513  1809
0806710 241 0  4513  1809
08167 9 244 0  4513  1809

I think bottleneck is not at GPU side, pixel convertion maybe needs speed
up improvement.


If codec changed to rawvideo to test pixel format convertion performance
testing, FPS again waves around 39-40 fps


I wanted to state these test reults.


Kind Regards,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avformat/udp: replace packet_gap with bitrate option

[Ali KIZIL]

On Mon, 13 Jun 2016, Michael Niedermayer wrote:

>* On Sun, Jun 12, 2016 at 09:30:18PM +0200, Marton Balint wrote:
*

>>* We haven't had a stable release since the packet_gap addition, so probably 
>>it
*

>>* is worth reworking the option to something that makes more sense to the end
*

>>* user. Also add burst_bits option to specify maximum length of bit bursts.
*

>>

>>* Signed-off-by: Marton Balint >>
*

>>* ---
*

>>*  doc/protocols.texi|  9 +++--
*

>>*  libavformat/udp.c | 51 
>>+--
*

>>*  libavformat/version.h |  2 +-
*

>>*  3 files changed, 41 insertions(+), 21 deletions(-)
*

>

>* iam in favor of both patches
*

>

Thanks, pushed both.

Regards,

Marton

It will be great if this patch also applied to RTP output.

Kind Regards,

The contents of this e-mail are confidential to the addressee and are
intended solely for the recipients use. If you are not the addressee, you
have received this e-mail in error. Any disclosure, copying, distribution
or action taken in reliance on it is prohibited and may be unlawful. Please
note that any opinions expressed in this e-mail are those of the author
personally and not your business name who do not accept responsibility for
the contents of the message.

To conserve our resources for the future please reconsider before printing
this e-mail.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Set Audio Stream Specifier to 0x04 for MPEG-1 Layer II Audio

[Ali KIZIL]

For more details see:
http://trac.ffmpeg.org/ticket/5388

The contents of this e-mail are confidential to the addressee and are
intended solely for the recipients use. If you are not the addressee, you
have received this e-mail in error. Any disclosure, copying, distribution
or action taken in reliance on it is prohibited and may be unlawful. Please
note that any opinions expressed in this e-mail are those of the author
personally and not your business name who do not accept responsibility for
the contents of the message.

To conserve our resources for the future please reconsider before printing
this e-mail.

2016-04-21 15:43 GMT+03:00 Ali KIZIL :

> From 019bfcbd781ed98aba17241ed867ab28af1f57d8 Mon Sep 17 00:00:00 2001
> From: smallishzulu 
> Date: Thu, 21 Apr 2016 15:42:48 +0300
> Subject: [PATCH] Set Audio Stream Specifier to 0x04 for MPEG-1 Layer II
> Audio
>
> ---
>  libavformat/mpegtsenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> index f4cb862..7316684 100644
> --- a/libavformat/mpegtsenc.c
> +++ b/libavformat/mpegtsenc.c
> @@ -318,7 +318,7 @@ static int mpegts_write_pmt(AVFormatContext *s,
> MpegTSService *service)
>  break;
>  case AV_CODEC_ID_MP2:
>  case AV_CODEC_ID_MP3:
> -stream_type = STREAM_TYPE_AUDIO_MPEG1;
> +stream_type = STREAM_TYPE_AUDIO_MPEG2;
>  break;
>  case AV_CODEC_ID_AAC:
>  stream_type = (ts->flags & MPEGTS_FLAG_AAC_LATM)
> --
> 1.9.1
>
> The contents of this e-mail are confidential to the addressee and are
> intended solely for the recipients use. If you are not the addressee, you
> have received this e-mail in error. Any disclosure, copying, distribution
> or action taken in reliance on it is prohibited and may be unlawful. Please
> note that any opinions expressed in this e-mail are those of the author
> personally and not your business name who do not accept responsibility for
> the contents of the message.
>
> To conserve our resources for the future please reconsider before printing
> this e-mail.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Define service_type "HEVC digital television service (0x1F) in mpegtsenc.c

[Ali KIZIL]

For more details see:
http://trac.ffmpeg.org/ticket/5455

The contents of this e-mail are confidential to the addressee and are
intended solely for the recipients use. If you are not the addressee, you
have received this e-mail in error. Any disclosure, copying, distribution
or action taken in reliance on it is prohibited and may be unlawful. Please
note that any opinions expressed in this e-mail are those of the author
personally and not your business name who do not accept responsibility for
the contents of the message.

To conserve our resources for the future please reconsider before printing
this e-mail.

2016-04-21 15:42 GMT+03:00 Ali KIZIL :

> From 20c0ac586cf5056bcc057e7664a64ddfdc0e13f9 Mon Sep 17 00:00:00 2001
> From: smallishzulu 
> Date: Thu, 21 Apr 2016 15:40:09 +0300
> Subject: [PATCH] Define service_type "HEVC digital television service"
>  (0x1F) in mpegtsenc.c
>
> ---
>  libavformat/mpegtsenc.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> index f4cb862..9222665 100644
> --- a/libavformat/mpegtsenc.c
> +++ b/libavformat/mpegtsenc.c
> @@ -67,7 +67,8 @@ enum {
>  MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_RADIO = 0x0A,
>  MPEGTS_SERVICE_TYPE_MPEG2_DIGITAL_HDTV   = 0x11,
>  MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_SDTV  = 0x16,
> -MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_HDTV  = 0x19
> +MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_HDTV  = 0x19,
> +MPEGTS_SERVICE_TYPE_HEVC_DIGITAL_HDTV= 0x1F
>  };
>  typedef struct MpegTSWrite {
>  const AVClass *av_class;
> @@ -1814,6 +1815,9 @@ static const AVOption options[] = {
>  { "advanced_codec_digital_hdtv", "Advanced Codec Digital HDTV.",
>0, AV_OPT_TYPE_CONST, { .i64 =
> MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_HDTV }, 0x01, 0xff,
>AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
> +{ "hevc_digital_hdtv", "HEVC Digital Television Service.",
> +  0, AV_OPT_TYPE_CONST, { .i64 =
> MPEGTS_SERVICE_TYPE_HEVC_DIGITAL_HDTV }, 0x01, 0xff,
> +  AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
>  { "mpegts_pmt_start_pid", "Set the first pid of the PMT.",
>offsetof(MpegTSWrite, pmt_start_pid), AV_OPT_TYPE_INT,
>{ .i64 = 0x1000 }, 0x0010, 0x1f00, AV_OPT_FLAG_ENCODING_PARAM },
> --
> 1.9.1
>
>
> The contents of this e-mail are confidential to the addressee and are
> intended solely for the recipients use. If you are not the addressee, you
> have received this e-mail in error. Any disclosure, copying, distribution
> or action taken in reliance on it is prohibited and may be unlawful. Please
> note that any opinions expressed in this e-mail are those of the author
> personally and not your business name who do not accept responsibility for
> the contents of the message.
>
> To conserve our resources for the future please reconsider before printing
> this e-mail.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Set Audio Stream Specifier to 0x04 for MPEG-1 Layer II Audio

[Ali KIZIL]

From 019bfcbd781ed98aba17241ed867ab28af1f57d8 Mon Sep 17 00:00:00 2001
From: smallishzulu 
Date: Thu, 21 Apr 2016 15:42:48 +0300
Subject: [PATCH] Set Audio Stream Specifier to 0x04 for MPEG-1 Layer II
Audio

---
 libavformat/mpegtsenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index f4cb862..7316684 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -318,7 +318,7 @@ static int mpegts_write_pmt(AVFormatContext *s,
MpegTSService *service)
 break;
 case AV_CODEC_ID_MP2:
 case AV_CODEC_ID_MP3:
-stream_type = STREAM_TYPE_AUDIO_MPEG1;
+stream_type = STREAM_TYPE_AUDIO_MPEG2;
 break;
 case AV_CODEC_ID_AAC:
 stream_type = (ts->flags & MPEGTS_FLAG_AAC_LATM)
--
1.9.1

The contents of this e-mail are confidential to the addressee and are
intended solely for the recipients use. If you are not the addressee, you
have received this e-mail in error. Any disclosure, copying, distribution
or action taken in reliance on it is prohibited and may be unlawful. Please
note that any opinions expressed in this e-mail are those of the author
personally and not your business name who do not accept responsibility for
the contents of the message.

To conserve our resources for the future please reconsider before printing
this e-mail.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Define service_type "HEVC digital television service (0x1F) in mpegtsenc.c

[Ali KIZIL]

From 20c0ac586cf5056bcc057e7664a64ddfdc0e13f9 Mon Sep 17 00:00:00 2001
From: smallishzulu 
Date: Thu, 21 Apr 2016 15:40:09 +0300
Subject: [PATCH] Define service_type "HEVC digital television service"
 (0x1F) in mpegtsenc.c

---
 libavformat/mpegtsenc.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index f4cb862..9222665 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -67,7 +67,8 @@ enum {
 MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_RADIO = 0x0A,
 MPEGTS_SERVICE_TYPE_MPEG2_DIGITAL_HDTV   = 0x11,
 MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_SDTV  = 0x16,
-MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_HDTV  = 0x19
+MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_HDTV  = 0x19,
+MPEGTS_SERVICE_TYPE_HEVC_DIGITAL_HDTV= 0x1F
 };
 typedef struct MpegTSWrite {
 const AVClass *av_class;
@@ -1814,6 +1815,9 @@ static const AVOption options[] = {
 { "advanced_codec_digital_hdtv", "Advanced Codec Digital HDTV.",
   0, AV_OPT_TYPE_CONST, { .i64 =
MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_HDTV }, 0x01, 0xff,
   AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
+{ "hevc_digital_hdtv", "HEVC Digital Television Service.",
+  0, AV_OPT_TYPE_CONST, { .i64 = MPEGTS_SERVICE_TYPE_HEVC_DIGITAL_HDTV
}, 0x01, 0xff,
+  AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
 { "mpegts_pmt_start_pid", "Set the first pid of the PMT.",
   offsetof(MpegTSWrite, pmt_start_pid), AV_OPT_TYPE_INT,
   { .i64 = 0x1000 }, 0x0010, 0x1f00, AV_OPT_FLAG_ENCODING_PARAM },
--
1.9.1


The contents of this e-mail are confidential to the addressee and are
intended solely for the recipients use. If you are not the addressee, you
have received this e-mail in error. Any disclosure, copying, distribution
or action taken in reliance on it is prohibited and may be unlawful. Please
note that any opinions expressed in this e-mail are those of the author
personally and not your business name who do not accept responsibility for
the contents of the message.

To conserve our resources for the future please reconsider before printing
this e-mail.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Patch for Trac Tickets 5388 & 5455

[Ali KIZIL]

Please discard this patch, I will split the patches.

The contents of this e-mail are confidential to the addressee and are
intended solely for the recipients use. If you are not the addressee, you
have received this e-mail in error. Any disclosure, copying, distribution
or action taken in reliance on it is prohibited and may be unlawful. Please
note that any opinions expressed in this e-mail are those of the author
personally and not your business name who do not accept responsibility for
the contents of the message.

To conserve our resources for the future please reconsider before printing
this e-mail.

2016-04-21 14:42 GMT+03:00 Ali KIZIL :

> Sorry the patch file was missing:
>
> From 1d10dc062da7eb51c749e321b419018deed79151 Mon Sep 17 00:00:00 2001
> From: smallishzulu 
> Date: Thu, 21 Apr 2016 13:28:10 +0300
> Subject: [PATCH] For trac tickets 5455 & 5388
>
> ---
>  libavformat/mpegtsenc.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> index f4cb862..12ccc70 100644
> --- a/libavformat/mpegtsenc.c
> +++ b/libavformat/mpegtsenc.c
> @@ -67,7 +67,8 @@ enum {
>  MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_RADIO = 0x0A,
>  MPEGTS_SERVICE_TYPE_MPEG2_DIGITAL_HDTV   = 0x11,
>  MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_SDTV  = 0x16,
> -MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_HDTV  = 0x19
> +MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_HDTV  = 0x19,
> +MPEGTS_SERVICE_TYPE_HEVC_DIGITAL_HDTV= 0x1F
>  };
>  typedef struct MpegTSWrite {
>  const AVClass *av_class;
> @@ -318,7 +319,7 @@ static int mpegts_write_pmt(AVFormatContext *s,
> MpegTSService *service)
>  break;
>  case AV_CODEC_ID_MP2:
>  case AV_CODEC_ID_MP3:
> -stream_type = STREAM_TYPE_AUDIO_MPEG1;
> +stream_type = STREAM_TYPE_AUDIO_MPEG2; //KIZIL
>  break;
>  case AV_CODEC_ID_AAC:
>  stream_type = (ts->flags & MPEGTS_FLAG_AAC_LATM)
> @@ -1810,10 +1811,13 @@ static const AVOption options[] = {
>AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
>  { "advanced_codec_digital_sdtv", "Advanced Codec Digital SDTV.",
>0, AV_OPT_TYPE_CONST, { .i64 =
> MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_SDTV }, 0x01, 0xff,
> -  AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
> +  AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" }, //KIZIL
>  { "advanced_codec_digital_hdtv", "Advanced Codec Digital HDTV.",
>0, AV_OPT_TYPE_CONST, { .i64 =
> MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_HDTV }, 0x01, 0xff,
>AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
> +{ "hevc_digital_hdtv", "HEVC Digital Television Service.",
> +  0, AV_OPT_TYPE_CONST, { .i64 =
> MPEGTS_SERVICE_TYPE_HEVC_DIGITAL_HDTV }, 0x01, 0xff,
> +  AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
>  { "mpegts_pmt_start_pid", "Set the first pid of the PMT.",
>offsetof(MpegTSWrite, pmt_start_pid), AV_OPT_TYPE_INT,
>{ .i64 = 0x1000 }, 0x0010, 0x1f00, AV_OPT_FLAG_ENCODING_PARAM },
> --
> 1.9.1
>
>
> The contents of this e-mail are confidential to the addressee and are
> intended solely for the recipients use. If you are not the addressee, you
> have received this e-mail in error. Any disclosure, copying, distribution
> or action taken in reliance on it is prohibited and may be unlawful. Please
> note that any opinions expressed in this e-mail are those of the author
> personally and not your business name who do not accept responsibility for
> the contents of the message.
>
> To conserve our resources for the future please reconsider before printing
> this e-mail.
>
> 2016-04-21 14:32 GMT+03:00 Ali KIZIL :
>
>> Hi All,
>>
>> With help of cehoyos, I created a patch file for Tickets 5388 & 5455. (My
>> first patch file.)
>> Patch targets to add HEVC digital television service type (0x1f) to
>> FFmpeg and fix audio stream specifier for MPEG 1 Layer II Audio to 0x04
>> (currently it is 0x03 and causes decode problem in some STBs.)
>>
>> Ticket links:
>> http://trac.ffmpeg.org/ticket/5455
>> http://trac.ffmpeg.org/ticket/5388
>>
>> Kind Regards,
>> Ali KIZIL
>>
>> The contents of this e-mail are confidential to the addressee and are
>> intended solely for the recipients use. If you are not the addressee, you
>> have received this e-mail in error. Any disclosure, copying, distribution
>> or action taken in reliance on it is prohibited and may be unlawful. Please
>> note that any opinions expressed in this e-mail are those of the author
>> personally and not your business name who do not accept responsibility for
>> the contents of the message.
>>
>> To conserve our resources for the future please reconsider before
>> printing this e-mail.
>>
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Patch for Trac Tickets 5388 & 5455

[Ali KIZIL]

Sorry the patch file was missing:

>From 1d10dc062da7eb51c749e321b419018deed79151 Mon Sep 17 00:00:00 2001
From: smallishzulu 
Date: Thu, 21 Apr 2016 13:28:10 +0300
Subject: [PATCH] For trac tickets 5455 & 5388

---
 libavformat/mpegtsenc.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index f4cb862..12ccc70 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -67,7 +67,8 @@ enum {
 MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_RADIO = 0x0A,
 MPEGTS_SERVICE_TYPE_MPEG2_DIGITAL_HDTV   = 0x11,
 MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_SDTV  = 0x16,
-MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_HDTV  = 0x19
+MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_HDTV  = 0x19,
+MPEGTS_SERVICE_TYPE_HEVC_DIGITAL_HDTV= 0x1F
 };
 typedef struct MpegTSWrite {
 const AVClass *av_class;
@@ -318,7 +319,7 @@ static int mpegts_write_pmt(AVFormatContext *s,
MpegTSService *service)
 break;
 case AV_CODEC_ID_MP2:
 case AV_CODEC_ID_MP3:
-stream_type = STREAM_TYPE_AUDIO_MPEG1;
+stream_type = STREAM_TYPE_AUDIO_MPEG2; //KIZIL
 break;
 case AV_CODEC_ID_AAC:
 stream_type = (ts->flags & MPEGTS_FLAG_AAC_LATM)
@@ -1810,10 +1811,13 @@ static const AVOption options[] = {
   AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
 { "advanced_codec_digital_sdtv", "Advanced Codec Digital SDTV.",
   0, AV_OPT_TYPE_CONST, { .i64 =
MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_SDTV }, 0x01, 0xff,
-  AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
+  AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" }, //KIZIL
 { "advanced_codec_digital_hdtv", "Advanced Codec Digital HDTV.",
   0, AV_OPT_TYPE_CONST, { .i64 =
MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_HDTV }, 0x01, 0xff,
   AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
+{ "hevc_digital_hdtv", "HEVC Digital Television Service.",
+  0, AV_OPT_TYPE_CONST, { .i64 = MPEGTS_SERVICE_TYPE_HEVC_DIGITAL_HDTV
}, 0x01, 0xff,
+  AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
 { "mpegts_pmt_start_pid", "Set the first pid of the PMT.",
   offsetof(MpegTSWrite, pmt_start_pid), AV_OPT_TYPE_INT,
   { .i64 = 0x1000 }, 0x0010, 0x1f00, AV_OPT_FLAG_ENCODING_PARAM },
-- 
1.9.1


The contents of this e-mail are confidential to the addressee and are
intended solely for the recipients use. If you are not the addressee, you
have received this e-mail in error. Any disclosure, copying, distribution
or action taken in reliance on it is prohibited and may be unlawful. Please
note that any opinions expressed in this e-mail are those of the author
personally and not your business name who do not accept responsibility for
the contents of the message.

To conserve our resources for the future please reconsider before printing
this e-mail.

2016-04-21 14:32 GMT+03:00 Ali KIZIL :

> Hi All,
>
> With help of cehoyos, I created a patch file for Tickets 5388 & 5455. (My
> first patch file.)
> Patch targets to add HEVC digital television service type (0x1f) to FFmpeg
> and fix audio stream specifier for MPEG 1 Layer II Audio to 0x04 (currently
> it is 0x03 and causes decode problem in some STBs.)
>
> Ticket links:
> http://trac.ffmpeg.org/ticket/5455
> http://trac.ffmpeg.org/ticket/5388
>
> Kind Regards,
> Ali KIZIL
>
> The contents of this e-mail are confidential to the addressee and are
> intended solely for the recipients use. If you are not the addressee, you
> have received this e-mail in error. Any disclosure, copying, distribution
> or action taken in reliance on it is prohibited and may be unlawful. Please
> note that any opinions expressed in this e-mail are those of the author
> personally and not your business name who do not accept responsibility for
> the contents of the message.
>
> To conserve our resources for the future please reconsider before printing
> this e-mail.
>


0001-For-trac-tickets-5455-5388.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Patch for Trac Tickets 5388 & 5455

[Ali KIZIL]

Hi All,

With help of cehoyos, I created a patch file for Tickets 5388 & 5455. (My
first patch file.)
Patch targets to add HEVC digital television service type (0x1f) to FFmpeg
and fix audio stream specifier for MPEG 1 Layer II Audio to 0x04 (currently
it is 0x03 and causes decode problem in some STBs.)

Ticket links:
http://trac.ffmpeg.org/ticket/5455
http://trac.ffmpeg.org/ticket/5388

Kind Regards,
Ali KIZIL

The contents of this e-mail are confidential to the addressee and are
intended solely for the recipients use. If you are not the addressee, you
have received this e-mail in error. Any disclosure, copying, distribution
or action taken in reliance on it is prohibited and may be unlawful. Please
note that any opinions expressed in this e-mail are those of the author
personally and not your business name who do not accept responsibility for
the contents of the message.

To conserve our resources for the future please reconsider before printing
this e-mail.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Problem Still Exists on avcodec/vdpau_hevc: Remove experimental flag

[Ali KIZIL]

Hello,

I wanted to inform interleaving problem still exisits even with Nvidia 
355.06 driver. More info here:

https://github.com/FFmpeg/FFmpeg/commit/aa10f0aab0e2729e0a5edbd7b6838658d6
3421e1

Kind Regards,
Ali

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] NVENC HEVC Profile Settings Errors

[Ali KIZIL]

Timo Rothenpieler  rothenpieler.org> writes:

> 
> > When setting level of HEVC in NVENC, FFmpeg gives error:
> >
> > root  encoder:~# /opt/ffmpeghw/bin/ffmpeg -i /root/bunny.mp4 -
aspect 16:9
> > -s 3840x2160 -vcodec nvenc_h265 -preset hp -fflags +genpts -vb 
25000k -
> > minrate 25000k -maxrate 25000k -bufsize 75000k -muxrate 25000k -r 50 
-an
> > -flush_packets 0 -packetsize 188 -level 5.1 -y -f mpegts /dev/null
> ...
> > [nvenc_h2650xee0080] InitializeEncoder failed: 0x8
> 
> That simply means that the requested encoding options are 
> unsupported/invalid.
> The requested level is just passed to nvenc, it doesn't support every 
> single one of them in every mode.
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel  ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

I think this section needs to be as below:

static const NvencValuePair nvenc_h265_level_pairs[] = {
{ "auto", NV_ENC_LEVEL_AUTOSELECT },
{ "6"   , NV_ENC_LEVEL_HEVC_6 },
{ "6.0" , NV_ENC_LEVEL_HEVC_6 },
{ "6.1" , NV_ENC_LEVEL_HEVC_61},
{ "6.2" , NV_ENC_LEVEL_HEVC_62},
{ NULL }
};


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] NVENC HEVC Profile Settings Errors

[Ali KIZIL]

Timo Rothenpieler  rothenpieler.org> writes:

> 
> > When setting level of HEVC in NVENC, FFmpeg gives error:
> >
> > root  encoder:~# /opt/ffmpeghw/bin/ffmpeg -i /root/bunny.mp4 -
aspect 16:9
> > -s 3840x2160 -vcodec nvenc_h265 -preset hp -fflags +genpts -vb 
25000k -
> > minrate 25000k -maxrate 25000k -bufsize 75000k -muxrate 25000k -r 50 
-an
> > -flush_packets 0 -packetsize 188 -level 5.1 -y -f mpegts /dev/null
> ...
> > [nvenc_h2650xee0080] InitializeEncoder failed: 0x8
> 
> That simply means that the requested encoding options are 
> unsupported/invalid.
> The requested level is just passed to nvenc, it doesn't support every 
> single one of them in every mode.
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel  ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

Yes, agree. Maybe a fix to give info massage that NVENC does not support 
levels 1, 2, 2.1, 3, 3.1, 4, 4.1, 5, 5.1, 5.2, 6 in HEVC ?


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Accept 0x000001 as startcode for hevc in mpegts

[Ali KIZIL]

Hello All,

There is ticket #4194:
https://trac.ffmpeg.org/ticket/4194

On the below link, there is already working solution:
https://ffmpeg.org/pipermail/ffmpeg-devel/2014-December/166753.html

-- next part --
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index a32c6d6..ff15d16 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1207,7 +1207,7 @@ int ff_check_h264_startcode(AVFormatContext *s, 
const AVStream *st, const AVPack
 
 static int check_hevc_startcode(AVFormatContext *s, const AVStream *st, 
const AVPacket *pkt)
 {
-if (pkt->size < 5 || AV_RB32(pkt->data) != 0x001) {
+if (pkt->size < 5 || (AV_RB32(pkt->data) != 0x001 && 
AV_RB24(pkt->data) != 0x01)) {
 if (!st->nb_frames) {
 av_log(s, AV_LOG_ERROR, "HEVC bitstream malformed, no 
startcode found\n");
 return AVERROR_PATCHWELCOME;

This update fixes many unnecessary (according to me) log info.

(I am not expert on commiting changes, so I wrote here.)



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] NVENC H.265 4K Uncatchable 60fps Performance

[Ali KIZIL]

Timo Rothenpieler  rothenpieler.org> writes:

> 
> > I have a few questions.
> > I will be grateful is someone can give an idea / reply.
> >
> > 1) On nvenc.c under libavcodec, is it possible to create more than 
one
> > instance of nvenc to perform 4K 60 fps encoding using
> > nvEncodeAPICreateInstance ?
> 
> You could encode two independend video streams at 30 fps each. There 
is 
> no way two encode sessions can work on the same video stream.
> 
> > Is there any way to stack videos without re-encoding ?
> 
> No, that's not possible.
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel  ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 


BTW I got below email from Nvidia:

"My apologies… I made a mistake in my earlier response. I checked with 
the team, and confirmed that GM204 (GTX 980) should be able to do 60 fps 
H.264 at 4K x 2K (3840 x 2160) resolution.
 
I have a few questions. Are you using the nvencoder application with the 
NVENC SDK with HP preset and single pass rate control mode? Or some 
other settings?
 
How are you reading YUV file? Have you ensured that the code is 
pipelined such that there is no extra time spent in reading YUV frames 
into the video memory?"

Than I made a test:

4krun.sh file:
/root/NvEncoder -i /root/bunny.yuv -o /root/hevc -size 3840 2160 -codec 
1 -rcmode 2 -preset hp -fps 50 -goplength 50 -bitrate 4000 -
vbvMaxBitrate 4000 -vbvSize 12000

I run the above command as below:

time ./4krun.sh

Here is the output:

Encoded 1077 frames in 20533.26ms
Avergage Encode Time :  19.07ms

real0m21.821s
user0m16.157s
sys 0m5.207s

It means depending on NvEncoder time measurement FPS is 52.45 (1077 / 
20.533), depending on Linux time measurement FPS is 49.35 (1077 / 
21.821).

However, FFmpeg can go up to 32-34 fps. There may be a memory management 
issue. If I succeed on comparing of code NvEncoder and nvenc.c, I will 
write here.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] NVENC HEVC Profile Settings Errors

[Ali KIZIL]

Hello,

When setting level of HEVC in NVENC, FFmpeg gives error:

root@encoder:~# /opt/ffmpeghw/bin/ffmpeg -i /root/bunny.mp4 -aspect 16:9 
-s 3840x2160 -vcodec nvenc_h265 -preset hp -fflags +genpts -vb 25000k -
minrate 25000k -maxrate 25000k -bufsize 75000k -muxrate 25000k -r 50 -an 
-flush_packets 0 -packetsize 188 -level 5.1 -y -f mpegts /dev/null
ffmpeg version N-71430-g4d74c8d Copyright (c) 2000-2015 the FFmpeg 
developers
  built with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
  configuration: --prefix=/opt/ffmpeghw --enable-shared --enable-nonfree 
--enable-gpl --extra-cflags='-I/opt/ffmpeg/include -I/usr/local/include' 
--extra-ldflags=-L/opt/ffmpeg/lib --bindir=/opt/ffmpeghw/bin --extra-
libs=-ldl --enable-libx264 --enable-libx265 --enable-nonfree --enable-
gpl --enable-nvenc --enable-libopenjpeg --enable-vdpau
  libavutil  54. 22.101 / 54. 22.101
  libavcodec 56. 34.100 / 56. 34.100
  libavformat56. 30.100 / 56. 30.100
  libavdevice56.  4.100 / 56.  4.100
  libavfilter 5. 14.100 /  5. 14.100
  libswscale  3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc53.  3.100 / 53.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/root/bunny.mp4':
  Metadata:
major_brand : isom
minor_version   : 1
compatible_brands: isomavc1
creation_time   : 2013-12-17 16:40:26
title   : Big Buck Bunny, Sunflower version
artist  : Blender Foundation 2008, Janus Bager Kristensen 
2013
comment : Creative Commons Attribution 3.0 - 
http://bbb3d.renderfarming.net
genre   : Animation
composer: Sacha Goedegebure
  Duration: 00:10:34.53, start: 0.00, bitrate: 8487 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 
3840x2160 [SAR 1:1 DAR 16:9], 8002 kb/s, 60 fps, 60 tbr, 60k tbn, 120 
tbc (default)
Metadata:
  creation_time   : 2013-12-17 16:40:26
  handler_name: GPAC ISO Video Handler
Stream #0:1(und): Audio: mp3 (mp4a / 0x6134706D), 48000 Hz, stereo, 
s16p, 160 kb/s (default)
Metadata:
  creation_time   : 2013-12-17 16:40:28
  handler_name: GPAC ISO Audio Handler
Stream #0:2(und): Audio: ac3 (ac-3 / 0x332D6361), 48000 Hz, 
5.1(side), fltp, 320 kb/s (default)
Metadata:
  creation_time   : 2013-12-17 16:40:28
  handler_name: GPAC ISO Audio Handler
Side data:
  unknown side data type 7 (4 bytes)
[nvenc_h265 @ 0xee0080] InitializeEncoder failed: 0x8
Output #0, mpegts, to '/dev/null':
  Metadata:
major_brand : isom
minor_version   : 1
compatible_brands: isomavc1
composer: Sacha Goedegebure
title   : Big Buck Bunny, Sunflower version
artist  : Blender Foundation 2008, Janus Bager Kristensen 
2013
comment : Creative Commons Attribution 3.0 - 
http://bbb3d.renderfarming.net
genre   : Animation
Stream #0:0(und): Video: hevc, none, q=2-31, 128 kb/s, SAR 1:1 DAR 
0:0, 50 fps (default)
Metadata:
  creation_time   : 2013-12-17 16:40:26
  handler_name: GPAC ISO Video Handler
  encoder : Lavc56.34.100 nvenc_h265
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> hevc (nvenc_h265))
Error while opening encoder for output stream #0:0 - maybe incorrect 
parameters such as bit_rate, rate, width or height


FYI: If I run;

root@encoder:~# /opt/ffmpeghw/bin/ffmpeg -i /root/bunny.mp4 -aspect 16:9 
-s 3840x2160 -vcodec nvenc_h265 -preset hp -fflags +genpts -vb 25000k -
minrate 25000k -maxrate 25000k -bufsize 75000k -muxrate 25000k -r 50 -an 
-flush_packets 0 -packetsize 188 -level 6.1 -y -f mpegts /dev/null

It works fine.

These values give error: 1, 2, 2.1, 3, 3.1, 4, 4.1, 5, 5.1, 5.2, 6,

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Add support for H.265 encoding

[Ali KIZIL]

Philip Langdale  overt.org> writes:

> 
> On 2015-03-26 04:30, Ali KIZIL wrote:
> > 
> > It works fine now Phil. One more comment:
> > 
> > I have a GTX 980. It can encode upto 30-33 fps for 4K 60fps YUV Raw
> > input file using nvenc_h265 avcodec with FFmpeg. First a side, It 
> > looked
> > to me like lack of performance of card. However; after I split the 
> > video
> > with crop filter into 2:
> > 
> > /opt/ffmpeghw/bin/ffmpeg -video_size 3840x2160 -framerate 50 -i
> > /Projects/YUV/soccer.yuv -vcodec nvenc_h265 -an -filter:v
> > "crop=in_w:in_h/2:0:0" -r 50 -g 50 -preset hp -f hevc top.hevc
> > 
> > /opt/ffmpeghw/bin/ffmpeg -video_size 3840x2160 -framerate 50 -i
> > /Projects/YUV/soccer.yuv -vcodec nvenc_h265 -an -filter:v
> > "crop=in_w:in_h/2:0:in_h/2" -r 50 -g 50 -preset hp -f hevc 
bottom.hevc
> > 
> > When I run them at the same time, both can be encoded with 50 fps. I
> > tried to joing output files with padding but FFmpeg needs re-
encoding
> > and it makes no sense.
> > 
> > Do you have any comment or idea to use full performance of the card 
> > over
> > a single ffmpeg nvenc_h265 instance ?
> > 
> > Additional note: GTX cards can suport up to 2 HEVC encoding at the 
same
> > time (as limitation.).
> 
> I honestly don't know. The hardware performance may not scale linearly 
> with
> frame size, so you might see a disproportionate slowdown past a 
certain 
> size,
> perhaps reflecting the need to use multiple buffers, etc.
> 
> Do you see any evidence that you're CPU bound? That might happen if 
our 
> buffer
> management is too inefficient, but I'd be surprised.
> 
> --phil
> 

CPU is fine. I have 2 x Intel(R) Xeon(R) CPU E5-2640 v2 @ 2.00GHz on 
server and Mem Total 49413456 kB, MemFree: 32030320 kB. So, mem is not 
an issue also. Here is top output on run:

top - 23:39:18 up 1 day, 21 min,  2 users,  load average: 0.08, 0.03, 
0.05
Tasks: 371 total,   3 running, 368 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu1  :  0.0 us,  0.3 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu2  :  0.3 us,  0.0 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu3  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu4  :  0.0 us,  0.3 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu5  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu6  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu7  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu8  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu9  :  0.0 us,  0.3 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu10 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu11 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu12 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu13 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu14 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu15 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu16 : 29.1 us, 20.3 sy,  0.0 ni, 50.7 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu17 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu18 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu19 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu20 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu21 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu22 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu23 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu24 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu25 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu26 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu27 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu28 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu29 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu30 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu31 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
KiB Mem:  49413456 total, 19607392 used, 29806064 free,   106188 buffers
KiB Swap: 50282492 total,0 used, 50282492 free. 16826488 cached 
Mem

  PID USER  PR  NIVIRTRESSHR S  %CPU 

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Add support for H.265 encoding

[Ali KIZIL]

Philip Langdale  overt.org> writes:

> 
> On Wed, 25 Mar 2015 21:52:54 + (UTC)
> Ali KIZIL  gmail.com> wrote:
> 
> > 
> > The update broken the general usage:
> > 
> > ./ffmpeg -loglevel info -re -i /root/bunny.mp4 -vcodec nvenc -preset
> > hp -fflags +genpts -vb 24000k -minrate 24000k -maxrate 24000k
> > -bufsize 48000k -muxrate 26000k -cbr 1 -2pass 0 -r 50 -g 100 -
pix_fmt
> > yuv420p - acodec aac -strict -2 -ac 2 -ar 48000 -ab 256k
> > -flush_packets 0 - packetsize 188 -y -f mpegts out.ts
> > 
> > ./ffmpeg -loglevel info -re -i /root/bunny.mp4 -vcodec nvenc_h265 -
> > preset hp -fflags +genpts -vb 24000k -minrate 24000k -maxrate 24000k 
-
> > bufsize 48000k -muxrate 26000k -cbr 1 -2pass 0 -r 50 -g 100 -pix_fmt 
> > yuv420p -acodec aac -strict -2 -ac 2 -ar 48000 -ab 256k
> > -flush_packets 0 -packetsize 188 -y -f mpegts out.ts
> > 
> > FFmpeg stucks, does not work for both. 
> > 
> > Before with nvenc work working fine with above commands. It looks
> > like - g parameter, -muxrate, -flush_packtes stuck FFmpeg with this
> > update. 
> > 
> > Below line works:
> > 
> > ./ffmpeg -loglevel verbose -i /root/bunny.mp4 -vcodec nvenc_h265
> > -preset hp -r 50  -y -f mpegts out.ts
> 
> Yes - it's because I tried to share the class instance between the two
> encoders, which doesn't work. I'm about to push a fix. Thanks for the
> heads up.
> 
> --phil
> 

It works fine now Phil. One more comment:

I have a GTX 980. It can encode upto 30-33 fps for 4K 60fps YUV Raw 
input file using nvenc_h265 avcodec with FFmpeg. First a side, It looked 
to me like lack of performance of card. However; after I split the video 
with crop filter into 2:

/opt/ffmpeghw/bin/ffmpeg -video_size 3840x2160 -framerate 50 -i 
/Projects/YUV/soccer.yuv -vcodec nvenc_h265 -an -filter:v 
"crop=in_w:in_h/2:0:0" -r 50 -g 50 -preset hp -f hevc top.hevc

/opt/ffmpeghw/bin/ffmpeg -video_size 3840x2160 -framerate 50 -i 
/Projects/YUV/soccer.yuv -vcodec nvenc_h265 -an -filter:v 
"crop=in_w:in_h/2:0:in_h/2" -r 50 -g 50 -preset hp -f hevc bottom.hevc

When I run them at the same time, both can be encoded with 50 fps. I 
tried to joing output files with padding but FFmpeg needs re-encoding 
and it makes no sense.

Do you have any comment or idea to use full performance of the card over 
a single ffmpeg nvenc_h265 instance ?

Additional note: GTX cards can suport up to 2 HEVC encoding at the same 
time (as limitation.). 



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Add support for H.265 encoding

[Ali KIZIL]

Philip Langdale  overt.org> writes:

> 
> On Tue, 24 Mar 2015 09:54:13 +0100
> Timo Rothenpieler  rothenpieler.org> wrote:
> 
> > Yes, I did exactly that in my implementation:
> > 
> > https://github.com/BtbN/FFmpeg/commits/nvenc
> > 
> > The code i wrote there is completely untested(Except that h264 still 
> > works), because i don't have any compatible hardware, so the one you 
> > tested is clearly the one that should be prefered.
> > 
> > Dropping SDK <5 support is fine with me, as long as it's not
> > backported to 2.6. The primary gain from supporting the old SDK is
> > that it works with much older nvidia driver versions.
> > 
> > I'll submit the patch that drops the old API support, so you can
> > rebase your patch on top of it.
> > 
> > Looks good to merge otherwise.
> > 
> 
> I've taken your logic to check the SM version - I had been
> wondering how old hardware should be detected and excluded.
> 
> I've also noticed that the profile handling code is completely broken 
-
> you can't set a profile using -profile:v - it appears we're handling
> this in an incorrect way - but I'm not sure what correct is. libx264
> has its own profile option which appears to be necessary but then I
> don't understand what sets avctx->profile.
> 
> Anyway, that's a separate problem we can solve independently of h.265.
> 
> Thanks!
> 
> --phil
> 

The update broken the general usage:

./ffmpeg -loglevel info -re -i /root/bunny.mp4 -vcodec nvenc -preset hp 
-fflags +genpts -vb 24000k -minrate 24000k -maxrate 24000k -bufsize 
48000k -muxrate 26000k -cbr 1 -2pass 0 -r 50 -g 100 -pix_fmt yuv420p -
acodec aac -strict -2 -ac 2 -ar 48000 -ab 256k -flush_packets 0 -
packetsize 188 -y -f mpegts out.ts

./ffmpeg -loglevel info -re -i /root/bunny.mp4 -vcodec nvenc_h265 -
preset hp -fflags +genpts -vb 24000k -minrate 24000k -maxrate 24000k -
bufsize 48000k -muxrate 26000k -cbr 1 -2pass 0 -r 50 -g 100 -pix_fmt 
yuv420p -acodec aac -strict -2 -ac 2 -ar 48000 -ab 256k -flush_packets 0 
-packetsize 188 -y -f mpegts out.ts

FFmpeg stucks, does not work for both. 

Before with nvenc work working fine with above commands. It looks like -
g parameter, -muxrate, -flush_packtes stuck FFmpeg with this update. 

Below line works:

./ffmpeg -loglevel verbose -i /root/bunny.mp4 -vcodec nvenc_h265 -preset 
hp -r 50  -y -f mpegts out.ts




___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Test Result

[Ali KIZIL]

Yestday, I got the latest snaphot from GIT and tested the case.
On a CBR test, if outpur bandwidth rate is high, some decoders/TS analyze SWs 
give PCR accuracy and repetition error (very rare).

Example:
ffmpeg -i pipe -aspect 16:9 -fflags +genpts -vcodec libx264 -preset ultrafast 
-vb 25000k -minrate 25000k -maxrate 25000k -bufsize 2500k -muxrate 27000k -
tune stillimage -qmin 20 -pix_fmt yuv420p -vbsf h264_mp4toannexb -strict 
experimental -acodec libfdk_aac -ab 128k -flush_packets 0 -f mpegts 
'udp://225.2.1.1:1234?pkt_size=1316'

This works fine. Time to time on some decoders (like Ericsson) make black 
frame. But no PCR error.

ffmpeg -i pipe -aspect 16:9 -fflags +genpts -vcodec libx264 -preset ultrafast 
-vb 5k -minrate 5k -maxrate 5k -bufsize 1k -muxrate 54000k -
tune stillimage -qmin 20 -pix_fmt yuv420p -vbsf h264_mp4toannexb -strict 
experimental -acodec libfdk_aac -ab 128k -flush_packets 0 -f mpegts 
'udp://225.2.1.1:1234?pkt_size=1316'

In this case, it reports PCR accuracy and repetition error and decoders gives 
alarm as well.

BR,

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel