The problem is that we load plane bytes to mm0/1/6 from Y[2index+8], U[index+4], V[index+4] before checking of index's upper limit.

FATE is happy (not sure that code is covered though)

In current versions of ffmpeg, when streaming to an RTMP server, anytime a packet of type RTMP_PT_NOTIFY is encountered, the packet is prepended with @setDataFrame before it gets sent to the server. This is incorrect; only packets for onMetaData and |RtmpSampleAccess should invoke @setDataFrame on the RTMP server. Specifically, the current bug manifests itself when trying to stream onTextData or onCuePoint invocations.

This fix addresses that problem and ensures that the @setDataFrame is only prepended for onMetaData and |RtmpSampleAccess.

http://developer.download.nvidia.com/compute/nvenc/v5.0_beta/NVENC_DA-06209-001_v06.pdf table 5 on page 10 lists 2-pass mode even for high performance and high quality - profiles in addition to the two low latency - profiles, and when tested manually I could verify this myself, too. I am not sure if this was changed with SDK 5.0 as I can't be arsed to check previous SDKs, but at least starting with 5.0 the comments about 2-pass only working with low latency -presets are incorrect.

The readme file has some markdown syntax, for instance the - character one line blow the headings, and the * to make a list. I added .md to readme, now is readme.md and it looks great. See: https://github.com/KonradIT/FFmpeg/blob/master/README.md

Konrad

I have modified the vf_convolution.c filter to be able to use strided convolution. As of now, I have created a new filter convselective.c which supports this feature. I had a few questions:

• Is strided convolutions a useful feature to have?
• If so, would it be better to incorporate the same as options in the convolution filter, or have a new filter?
• I have used if, else statements to check if convolution needs to be performed at a location (separated by stride lengths). Is there a faster way of implementing this in c++, so that it does not slows things down?

(apologies if my questions/implementation seems naive)

Thanks

I needed expressions to work for drawbox, so I went ahead and implemented it using vf_scale and vf_drawtext as models. The expressions are evaluated once in config_input, so filter_frame is unchanged. The expressions are evaluated 5 times to handle expressions that reference other expressions (example: h=w/dar).

cheers, -Mark

Sorry, i'm really not familiar with that, so i hope that this time i did it correctly ?

From contributing.md :

Committing changes to a git clone, for example on github.com or gitorious.org. And asking us to merge these changes.

https://github.com/Matroska-Org/matroska-specification/blob/a2de2b67338fc6f5f64d58e0a65df88850eaca76/codec_specs.md#subtitle-codec-mappings

Add USF, WEBVTT, BMP and KATE to the subtitles list.

When ffserver sends rtp packets via udp, the udp ports of client is got from header of SETUP request.But if the client is behind NAT, the client ports got from header of SETUP request are not ones mapped by NAT but client's private ports. In this case, the client can't get any packets because ffserver still sends that to client's private ports.

In fact, clients(such as vlc, video player on android) send two udp packets to ffserver for punching a hole on NAT after getting reply of SETUP request. So, we should receive the two udp packets, retrieve real client ports mapped by NAT, and send packets to the client via the real ports.

Update value of variable local_rtp_port before checking if it is not less than zero

This bug makes the rtcp port and rtp port are not two successive integers which are sent to client as server ports.

But some video players on Android will not send udp hole punching messages if the rtcp port and rtp port are not two successive integers.So, if the video player is behind NAT, it cannot receive any rtp messages via udp.

This commit finished IDCT NEON optimization for aarch64 HEVC decoder, and many h265 stream test vedio have been tested by the optimed HEVC, the point have be increased 30% according to the org.

This adds an option to set the service type in mpegts as define in ETSI 300 468. I've been using this to pipe internet radio stream (originally as HLS/m3u8) from ffmpeg to tvheadend, when the service type set right tvheadend recognize the mpegts stream as a radio channel. This have been test against master. linuxstb from the hts freenode channel originally written the patch and allowed me to push it upstream.

This is not a real pull request, but a reminder whoever comes across this repository. You should not open pull requests here; most developers don't look at the pull requests, so they will be ignored for the most part. The reason is that FFmpeg development, including code review, happens on the ffmpeg-devel mailing list, not here.

This is what the README.md says:

Patches should be submitted to the ffmpeg-devel mailing list using git format-patch or git send-email. Github pull requests should be avoided because they are not part of our review process. Few developers follow pull requests so they will likely be ignored.

Please read our official documentation on how to contribute.