This reverts commit 04aa09c4
and reintroduces 0ff5567a that
was temporarily reverted due to minor regressions.

It also reverts e5bce8b4 that fixed FATE refs.
The fate-ffm change is caused by field_order now being set
on the output format because the first frame arrives earlier.
The fate-mxf change is assumed to be the same.

<@jamrial> durandal_1707: 04aa09c4 broke fate-lavf-ffm and fate-lavf-mxf
<@durandal_1707> how so?
<@jamrial> one byte changes
<@durandal_1707> jamrial: just update checksums
<@jamrial> durandal_1707: but why did they change at all? the commit you reverted didn't affect them
<@jamrial> why does reverting it affect these tests?
<@jamrial> i don't think updating the checksum without knowing what changed is a good idea
<@durandal_1707> jamrial: the lavfi core is in weird state after removal of recursive code
<@durandal_1707> jamrial: the change is that older ones would get progressive flag set and new one doesnt
<@jamrial> alright

This makes sure the actual stream parameters are used, which is
important mainly for hardware decoding+filtering cases, which would
previously require various weird workarounds to handle the fact that a
fake software graph has to be constructed, but never used.
This should also improve behaviour in rare cases where
avformat_find_stream_info() does not provide accurate information.

This merges Libav commit a3a0230a. It was previously skipped.

The code in flush_encoders() which sets up a "fake" format wasn't in
Libav. I'm not sure if it's a good idea, but it tends to give
behavior closer to the old one in certain corner cases.

The vp8-size-change gives different result, because now the size of
the first frame is used. libavformat reported the size of the largest
frame for some reason.

The exr tests now use the sample aspect ratio of the first frame. For
some reason libavformat determines 0/1 as aspect ratio, while the
decoder returns the correct one.

The ffm and mxf tests change the field_order values. I'm assuming
another libavformat/decoding mismatch.
Signed-off-by: Nwm4 <nfxjfg@googlemail.com>

This would be simpler if codecpar supported AVOptions
modern ffserver should be unaffected by this, older ffserver which required the
muxer to directly access the encoder could have issues with this, but this
direct access is just wrong and unsafe
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

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

This accesses the private encoder context, it should not be used by
the current ffserver it may affect old ffserver versions but i believe
there is consens that accessing the private encoder context from the muxer
is completely wrong.
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

The bits_per_raw_sample represents the number of bits of precision per sample.

The field is added at the logical place, not at the end as the code was just
recently added

This fixes the regression about losing the audio sample precision information

The change in the fate test checksum un-does the change from the merge

Previous version reviewed by: wm4 <nfxjfg@googlemail.com>
Previous version reviewed by: Dominik 'Rathann' Mierzejewski <dominik@greysector.net>
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

Since timecode_frame)start is a private option now, it stays at the default,
and is no longer written to the file.
Signed-off-by: NDerek Buitenhuis <derek.buitenhuis@gmail.com>

The CMP variable seems to have been inherited from fate-api-seek which set it to null

the mxf reference needed a change due to c7e14a27Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

This is a generic solution that will not reqiore modifications when new options are added.
This also fixes problem with current implementation when qmin or qmax=-1.
Only 8 bits was sent and read back as 255.

Fixes #1275
Fixes #1461
Signed-off-by: NLukasz Marek <lukasz.m.luki2@gmail.com>

It has not been properly maintained for years and there is little hope
of that changing in the future.
It appears simpler to write a new replacement from scratch than
unbreaking it.

Improves compatibility with XDCAM HD formats. It has been set for a long time
in ffmbc.
Reviewed-by: NMichael Niedermayer <michaelni@gmx.at>
Signed-off-by: NMarton Balint <cus@passwd.hu>

The bug it was working seems to have been fixed.
This change causes ffmpeg to use the trim filter to implement
the -t option.
FATE tests are updated due to the more accurate handling of
the last packets.

This makes -t sample-accurate for audio and will allow further
simplication in the future.

Most of the FATE changes are due to audio now being sample accurate. In
some cases a video frame was incorrectly passed with the old code, while
its was over the limit.

Currently FFM files generated with one versions of ffmpeg generally
cannot be read by another.
By spliting data into chunks, more fields can saftely be appended to
chunks as well as new chunks added.
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Some of the FATE changes are due to off-by-one different rounding being used
(lrintf vs av_rescale_q).
Some fate changes are due to 1 audio frame less being encoded (the new variant seems
matching what qatar does and according to ffprobe its closer to the requested duration)
the mapchan feature sadly is lost in this commit because it depends on resampling
being done in ffmpeg.c which is now moved completely into the av filter layer
-async is broken after this commit, this will be fixed in subsequent commits
the new filter reconfiguration system is flawed and will drop a frame on each
parameter change which is why the nelly moser checksums need updating.

Conflicts:

	ffmpeg.c
	tests/ref/fate/smjpeg

Update FATE references due to encoder delay.

Deprecate corresponding AVCodecContext fields.

Current code compares the desired recording time with InputStream.pts,
which has a very unclear meaning. Change the code to use actual
timestamps of the frames passed to the encoder.

In several tests, one less frame is encoded, which is more correct.

In the idroq test one more frame is encoded, which is again more
correct.

Behavior with stream copy should be unchanged.

The lavf-ffm test results change because ffmenc writes
AVCodecContext.flags/flags2 and the defaults for those change.

Deprecate AVCodecContext.directpred

Deprecate AVCodecContext.partitions.

AVStream is no place for it and it's unused outside of ffmpeg anyway.

Originally committed as revision 22673 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 22155 to svn://svn.ffmpeg.org/ffmpeg/trunk

This correct the stop point for demuxing with -vcodec copy and -t as well as
packet interleaving. (we already diddrop packets but kept demuxing them
for too long due to opts being wrong)
the change to ffm is due to 2 packets with timestamp 0 being stored
in different order.

Originally committed as revision 21626 to svn://svn.ffmpeg.org/ffmpeg/trunk

With this change, the output is checked immediately after each test
has run.  This means commands like "make regtest-mpeg2" can now be
used to run a single test and get meaningful results.

By default, make will abort if any test fails.  To run all tests
regardless, use make -k.

Originally committed as revision 21254 to svn://svn.ffmpeg.org/ffmpeg/trunk