I could not build libav with vaapi enabled, because my version of libva has no ABGR defined. So I added check for VA_FOURCC_ABGR to check if mapping to ABGR is possible.

The log facility in libav will convert command line parameters to UTF-8 before processing them, but when printing those converted UTF-8 log to windows cmd.exe console, some charactors(such as chinese charactors in file names) will get displayed as garbage charactors because of the mismatch of ANSI encoding in the user's windows environment and UTF-8. This patch will convert them back to windows Unicode strings before output.

Many HEVC TS Stream has stream_type as 0x27. even though gpac has same result, too. but current libav source cannot play those streams which have stream_type as 0x27. This is the modification for playing those HEVC TS Stream by avplay.

Let's hope I'm making it the right way, since I always confuse this. I just want to put the OS2World fork repository at the same level of the original source. I haven't make any change to the source code.

Hi, developer

I want to compile libav 0.7.7 version on windows msvc.

I tried to compile it with Msys2 latest version, mingw32 latest version, MSVC. but I couldn't compile it.

• MSVC compile configuration file has not --toolchain option. So, it fails when i execute this command for configuration. ./configure --toolchain=MSVC it throws error. (toolchain is not available)

• Mingw32 when i compile this in mingw32 environment, it throws error. implicit declaration of function 'strncpy_is_forbidden_due_to_security_issues_use_av_strlcpy' [-Werror=implicit-function-declaration]

Can you please help me?

I'm not 100% sure if the resolution is correct, but the indentation in the original code suggests that something else what intended. I'd welcome advice on the intended behaviour, and I will change the commit accordingly.

Add support for Travis in libav. In this way we could have a first validation of patches, to later submit them to the ML.

I think that this kind of tool automation could help newbies (like me) to contribute to libav.

I'm compiling an old project using libav 0.6 on a recent ubuntu. I got some minor include errors when building libav 0.6.

gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2

I had problems with corrupt AvPacket object buf pointers in the avbin project. This is based on an older version of libav 46a86c61940ec8efdfa90b23f05c38ecc1184a34.

The media is VP8 video in a matroska container. A segfault occurs in vp8_parser.c line 30:

s->pict_type= (buf[0]&0x01) ? AV_PICTURE_TYPE_P : AV_PICTURE_TYPE_I;

buf is NULL. I traced the problem as far as the corrupt AvPacket. I am not sure anyone wants this patch, but it might make testing easier.

Implemented patch by 'anguista' to fix mingw64 compilation, found on this forum post from Feb 2010: http://ffmpeg.arrozcru.org/forum/viewtopic.php?f=8&t=1225&p=4874#p4874

My builds for mingw (win32), Linux (32- and 64-bit) and OS X (32- and 64-bit) all still work after this patch as well.

The new reference.pnm is a freely licensed replacement. The photo has been taken by Reinhard Tartler on August 28 2014, who allows redistribution and usage for any purpose.

The order of the picture formats is inverted in the output.c example. This corrects them, and also replaces numerous direct uses of PIX_FMT_YUV420 with one constant.

This fixes a segfault (originally found in Movian, but traced to libav) when decoding subtitles because only an array of rects is allocated, but not the actual structs it contains. The issue was probably introduced in commit 2383323661f3b8342b2c4d356fcfe8c5d1b045f8 where the loop to allocate the rects in the array was thrown away.

Fix for setting total tracks number in metadata Same issue was fixed in ffmpeg: https://github.com/macoscope/ffmpeg/commit/bb7f71d9b6aedf8e83061e326f09843fd21fcbce