added sws_flags flags and tested against x86_32

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This is needed in order to have different sizes of LUTs according to the
input.

This simplifies following commits.

There is actually a need for the origin and end point not to be defined.
We can not automatically insert them with the y value of the first and
last point as it will influence the curves in a wrong way.

Fixes #5397

If this still doesnt give the same results on all platforms then this should be
disabled

Found-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fix const corectness and zero init the struct. This example code would actually crash when initializing string.

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This ensures that AV_NOPTS_VALUE value is handled
correctly.

Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

dnxhr has variable resolution, 8160 is the mb num for 1920x1080

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The data offset value in the prefix increases as the heights increases.
This test adds a tests for some common dnxhr heights.

can somebody add the following test footage to fate/dnxhd?
https://dl.dropboxusercontent.com/u/170952/fate/dnxhd/prefix-256x1536.dnxhr
https://dl.dropboxusercontent.com/u/170952/fate/dnxhd/prefix-256x1716.dnxhr
https://dl.dropboxusercontent.com/u/170952/fate/dnxhd/prefix-256x2048.dnxhr
https://dl.dropboxusercontent.com/u/170952/fate/dnxhd/prefix-256x2160.dnxhr
https://dl.dropboxusercontent.com/u/170952/fate/dnxhd/prefix-256x3212.dnxhr

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

I've been helping out with the project servers' maintenance and migration
to the new machine hosted in Telepoint's data center in Sofia, BG.

Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

When seeking a file where codec delay is greater than 0, the timecode
can become negative after offsetting by the codec delay. Failing to cast
to a signed int64 will cause the check against skip_to_timecode to evaluate
true for these negative values. This breaks the "skip_to" seek mechanism.

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Avoid a warning for passing an unsigned value to abs(), some compilers
might optimize away abs().

The range field has been introduced in version 1.6.0

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

It should only be done for DEVICE_BUSY/IN_EXECUTION

Include the libmfx error code and its description

Other parameters, like the display size, should still be taken from the
codec context.

This will allow using this function for encoding as well, where the
input format is already the semi-packed version.

Currently it's memset to 0, which is YUV420P. It should be initialized
to none.

Do not hardcode NV12. This allows 10bit decoding with -hwaccel qsv.

This is required e.g. by HEVC.

The setpts filter does not signal to the rest of the filtergraph that
the stream is CFR. Just generate the timestamps manually instead.

Signed-off-by: Anton Khirnov <anton@khirnov.net>

According to the specification on the MSDN [1], 0 is valid for that
particular field, and it should be ignored in that case.

[1]: http://msdn.microsoft.com/en-us/library/windows/desktop/dd757714(v=vs.85).aspx

Bug-Id: 950

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

mpeg4_unpack_bframes_bsf bitstream filters constructs
resulting packet using av_packet_from_data() function.
This function however modifies only buffer (data) and leaves
other fields untouched, so the content of other fields
of the output packet is undefined.
It is working with old BSF API, since old API filters
just data and the packet fields are copied in
av_apply_bitstream_filters from input packet.

This change fixes the behaviour for the new BSF API.

Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Steven Liu <liuqi@gosun.com>
Reviewed-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Found-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

+ the context struct

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Zern <jzern@google.com>

+ the context struct

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Zern <jzern@google.com>