- 29 Jun, 2016 10 commits
-
-
Vittorio Giovara authored
-
Vittorio Giovara authored
In case of bogus input, fail early at codec initialization, rather than at the encode function.
-
Vittorio Giovara authored
-
Diego Biurrun authored
-
Diego Biurrun authored
The MP2 muxer uses none of the code of the MP3 muxer.
-
Martin Storsjö authored
This avoids listing the same feature multiple times in the test output. Previously the output contained something like this: SSE2: - hevc_mc.qpel [OK] - hevc_mc.epel [OK] - hevc_mc.unweighted_pred [OK] - hevc_mc.qpel [OK] - hevc_mc.epel [OK] - hevc_mc.unweighted_pred [OK] Signed-off-by: Martin Storsjö <martin@martin.st>
-
Diego Biurrun authored
It is also used by the Dirac parsing code.
-
Diego Biurrun authored
This fixes standalone compilation of the SVQ3 decoder, which had incomplete dependencies related to H.264 parsing.
-
Luca Barbato authored
Useful to inspect samples.
-
Luca Barbato authored
The encoder produces bitstream compatible with the current specification and version 2 is set as reserved (non-standardizable).
-
- 28 Jun, 2016 13 commits
-
-
Diego Biurrun authored
-
Martin Storsjö authored
This avoids the risk of accidentally clobbering such variables outside of the macro if the same variables are used there. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This fixes valgrind warnings about conditional jumps based on uninitialized data (even though the uninitialized data only ever was compared with a direct copy of the same uninitialized data). Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
While it is less featureful (and slower) than the built-in H264 decoder, one could potentially want to use it to take advantage of the cisco patent license offer. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Anton Khirnov authored
-
Anton Khirnov authored
hevcenc -> hevcdec, this is a _decoder_ plugin.
-
Mark Thompson authored
The hw frame used as reference has an attached size but it need not match the actual size of the surface, so enforcing that the sw frame used in copying matches its size exactly is not useful. Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
Anton Khirnov authored
The reasoning is the same as for the previous commit.
-
Anton Khirnov authored
The source frame may be cropped, so that its dimensions are smaller than the pool dimensions. The transfer_data API requires the allocated size of the destination frame to be the same as the pool size.
-
Anton Khirnov authored
-
Anton Khirnov authored
Be more careful when an input stream encounters EOF when its filtergraph has not been configured yet. The current code would immediately mark the corresponding output streams as finished, while there may still be buffered frames waiting for frames to appear on other filtergraph inputs. This should fix the random FATE failures for complex filtergraph tests after a3a0230a
-
Anton Khirnov authored
This is a more appropriate place for it, and will also be useful in the following commit.
-
- 27 Jun, 2016 3 commits
-
-
Vittorio Giovara authored
All option names now match the ones provided by the av_color_*_name().
-
Vittorio Giovara authored
-
Vittorio Giovara authored
Drop ST from names and symbols, it does not add anything distinctive or descriptive.
-
- 26 Jun, 2016 3 commits
-
-
Mark Thompson authored
Previously we would allocate a new one for every frame. This instead maintains an AVBufferPool of them to use as-needed. Also makes the maximum size of an output buffer adapt to the frame size - the fixed upper bound was a bit too easy to hit when encoding large pictures at high quality.
-
Mark Thompson authored
Not needed any more because we no longer have any useful case which will reinitialise with hardware frames here.
-
Clément Bœsch authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 25 Jun, 2016 10 commits
-
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
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.
-
Anton Khirnov authored
This will be useful in the following commit, after which the muxer timebase is not always available when encoding.
-
Anton Khirnov authored
Currently, a filtergraph will pull in the output constraints from its corresponding decoder context, which breaks proper layering. Instead, explicitly send the constaints on the output parameters to the filtergraph. This is similar to what is done for filtergraph inputs in 30ab4c51a180610d9f1720c75518d763515c0d9f
-
Anton Khirnov authored
Setting the filter input parameters is moved to init_input_stream(), so that it is done before the decoder is opened, potentially overwriting the information from avformat_find_stream_info() with less accurate data. This commit temporarily disables QSV transcoding with hw frames. The functionality will be re-added in the following commits.
-
Anton Khirnov authored
Currently, calling configure_filtergraph() will pull in the input parameters from the corresponding decoder context. This has the following disadvantages: - the decoded frame is a more proper source for this information - a filter accessing decoder data breaks proper layering Add functions for explicitly sending the input stream parameters to a filtergraph input - currently from a frame and a decoder. The decoder one will be dropped in future commits after some more restructuring.
-
Anton Khirnov authored
-
Anton Khirnov authored
This should have no practical effect for now, but will make a difference in the following commits.
-
Anton Khirnov authored
The destination filter might expect the hw frames context to be already set (this is the case e.g. for hwdownload).
-
- 24 Jun, 2016 1 commit
-
-
Martin Storsjö authored
The encode function is supposed to just return 0 on success. This stems from a mixup with the return value of decode functions. Signed-off-by: Martin Storsjö <martin@martin.st>
-