This very slightly improves compression
Found-by: Christophe Gisquet <christophe.gisquet@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The actual predictor value, set by the trellis code, never
was written back into the variable that was written into
the block header. This was accidentally removed in b304244b.
This significantly improves the audio quality of the trellis
case, which was plain broken since b304244b.
Encoding IMA QT with trellis still actually gives a slightly
worse quality than without trellis, since the trellis encoder
doesn't use the exact same way of rounding as in
adpcm_ima_qt_compress_sample and adpcm_ima_qt_expand_nibble.
Fixes part of Ticket3701
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
adpcm_ima_qt does not produce reproducible results, so it is temporarily
disabled (see #3701).
Signed-off-by: Timothy Gu <timothygu99@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This results in DefaultDuration not being written when the framerate is
not known, but as this field is purely informative, this should not
break any sane demuxers.
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 '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>
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 '92b099daf4b8ef93513e38b43899cb8458a2fde3':
swscale: support converting YVYU422 pixel format
Conflicts:
libswscale/input.c
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>
Improves rgb -> gray16 conversion
Fixes Ticket3422
The pam and png output files look visually similar, in both cases the
dynamics increase to 0x0 -> 0xfffb.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Extrapolate audio timestamps based on the number of samples demuxed.
Deal with some MXF nastiness involving fractional number of
samples per EditUnit when seeking (the specs handwave this away).
Further fixes from Tomas Härdin.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The old one didn't use segmentation. One uses segmentation in all frame
types (--aq-mode=1), and the other uses all segmentation features, but
only in inter frames (mbgraph).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This disables backward probability updates, which makes the codec more
friendly for frame-level multi-threading.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* qatar/master:
fate: force the simple idct for xvid custom matrix test
Conflicts:
tests/fate/xvid.mak
tests/ref/fate/xvid-custom-matrix
See: ef034cbf18
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The original test without a forced idct is still useful since it tests
the switching of the idct algorithm/permutation on x86 with MMX. MMXext
or SSE2. Make sure the test runs only if MMX inline asm is available and
force -cpuflags to all.
Add the required bitexact flag for both tests.
