The official samples are 50% smaller
Avoid having reference samples which are strongly linked to the used resampler
implementation. (which for example would require new samples to be used if this
implementation changes)
Also its more correct to use the official samples instead of the current
decoder output
also enable tests
The tests also fully pass as well with the previous samples.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This corrects the bug that caused the checksums to change in
9767d7c092.
It caused the EOS flag to be set incorrectly; the ogg spec does not
allow it to be set in the middle of a logical bitstream.
Signed-off-by: Andrew Kelley <superjoe30@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Before, header information for ogg format files was sent with the
first encoded packet.
This patch makes it so that it is possible for API users to
differentiate between headers and encoded audio. This is useful, for
example, when creating an audio stream where you want to send one set
of headers for every client that connects and then the encoded stream
of audio.
Signed-off-by: Martin Storsjö <martin@martin.st>
Based off the srt encoder. The following features are unimplemented:
- fonts, colors, sizes
- alignment and positioning
The rest works well. For example, use ffmpeg to convert subtitles into the .vtt format:
ffmpeg -i input.srt output.vtt
Signed-off-by: Aman Gupta <ffmpeg@tmm1.net>
Signed-off-by: Clément Bœsch <u@pkh.me>
* commit '6656370b858329ca07a60a2de954d5e90daa0206':
avconv: set the "encoder" tag when transcoding
Conflicts:
ffmpeg.c
tests/ref/lavf/mkv
tests/ref/seek/lavf-mkv
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '93afb6c98df876b15e3d911a9450ad55f92080ce':
avconv: set output avg_frame_rate when known
Conflicts:
ffmpeg.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b70d7a4ac72d23f3448f3b08b770fdf5f57de222':
lavc: add a native Opus decoder.
Conflicts:
Changelog
configure
libavcodec/version.h
Fate tests pass with both avresample as well as swresample based opus decoder, but
are disabled (reference files are very large so i want to think a day or 2 about
if theres an alternative or if they could be avoided, they also dont match the
official samples)
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Use it instead of checking CODEC_FLAG_BITEXACT in the first stream's
codec context.
Using codec options inside lavf is fragile and can easily break when the
muxing codec context is not the encoding context.
Initial implementation by Andrew D'Addesio <modchipv12@gmail.com> during
GSoC 2012.
Completion by Anton Khirnov <anton@khirnov.net>, sponsored by the
Mozilla Corporation.
Further contributions by:
Christophe Gisquet <christophe.gisquet@gmail.com>
Janne Grunau <janne-libav@jannau.net>
Luca Barbato <lu_zero@gentoo.org>
* commit '6072184e702b4b631ac72f1b66b75e5f21e0ce2d':
asfenc: use codec descriptors instead of AVCodecs to write codec info
Conflicts:
tests/ref/lavf/asf
tests/ref/seek/lavf-asf
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Also, stop using AVCodecContext.codec_name as fallback, since it will be
deprecated.
Changes the result of the lavf-asf test (and its associated seektest),
since 'msmpeg4v3' gets written instead of just 'msmpeg4'.
Partially undoes commit 2c4e08d893:
riff: always generate a proper WAVEFORMATEX structure in
ff_put_wav_header
A new flag, FF_PUT_WAV_HEADER_FORCE_WAVEFORMATEX, is added to force the
use of WAVEFORMATEX rather than PCMWAVEFORMAT even for PCM codecs.
This flag is used in the Matroska muxer (the cause of the original
change) and in the ASF muxer, because the specifications for
these formats indicate explicitly that WAVEFORMATEX should be used.
Muxers for other formats will return to the original behavior of writing
PCMWAVEFORMAT when writing a header for raw PCM.
In particular, this causes raw PCM in WAV to generate the canonical
44-byte header expected by some tools.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The rational for this is another issue that plex has exposed. When it is
conducting a transcode of video to HLS for streaming, my father noticed
artifacts when played on his GoogleTV (NSZ-GT1). He sent me a test file
and I reproduced it on my device of the same model. It is important to
note that the artifacts were not present when streaming to VLC or QuickTime
Player. I copied the command-line that plex used, and conducted all of the
following tests using FFmpeg git.
Transcode to HLS: artifacts on playback
Transcode to TS: playback is fine
Cat HLS segments into a single TS: playback is fine
Segment single TS file to segments: artifacts on playback
Segment single TS file to segments using Apple's HLS segmenter: playback is
fine
At this point I carefully examined the differences between Apple's HLS
segmenter output and FFmpeg's. Among the considerable differences, I
noticed that the video PES packets always had a 0 length. So I continued:
Transcode to HLS using FFmpeg with 0 length PES packets: playback is fine.
Segment single TS to segments with 0 length PES packets: playback is fine.
All failures mentioned are only on the GTV since it is the only player on
which I could reproduce artifacts. I only tested the GTV, VLC, and
QuickTime Player though, so my test case is limited. I do not know if
other players exhibit this issue.
Since it was useful last time, I have uploaded the test file as
hls_pes_packet_length.m4v along with its associated txt file which contains
the transcode command-line that was used.
Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '911fa05b514e1be009e00b79d7004b93717c023b':
mvc: Specify the pixel format for the mv-mvc* tests
Conflicts:
tests/fate/video.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Also set the RGBA pixel format correctly as the native endian format,
which is what it returns.
This fixes the tests on big endian.
Signed-off-by: Martin Storsjö <martin@martin.st>
This should avoid slight differences in the output causes by input
size alignment differences between archs
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes conversion of pal8 to rgb formats with alpha.
Updated references for 2 FATE tests which previously encoded fully
transparent images.
Based on a patch by Baptiste Coudurier <baptiste.coudurier@gmail.com>
If 384k is too high for the samplerate, choose the closest
possible
Idea to increase the bitrate from: 46439e1562
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This causes us to favor RGB8 over PAL8 when FF_LOSS_COLORQUANT is used
It probably makes sense to reinvestigate the exact scoring of pal8 when
our pal8 support improves to be supperior to rgb8
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '60fd7d36c47d62d4c603bf16c213b1a924f5cfcf':
fate: correctly set sample rate for mp2 tests
Conflicts:
tests/fate/acodec.mak
tests/lavf-regression.sh
one hunk has been ommited as it breaks fate
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '92b099daf4b8ef93513e38b43899cb8458a2fde3':
swscale: support converting YVYU422 pixel format
Conflicts:
libswscale/input.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* cus/stable:
mpeg12enc: always set closed gop flag on the first gop
mpeg12enc: always write closed gops for intra only outputs
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '66d04c068a30751750818dcfbb6555ab74eb3f6d':
fate: Explicitly use gray16le in fate-sgi-gray16
Conflicts:
tests/fate/image.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Improves compatibility with XDCAM HD formats. It has been set for a long time
in ffmbc.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Marton Balint <cus@passwd.hu>
* commit '3e4e2142d246699a1a3a0045ba7124b18bc34d7a':
fate: Convert the paletted output in the brenderpix tests to rgb24
Merged-by: Michael Niedermayer <michaelni@gmx.at>
