- 16 Nov, 2012 1 commit
-
-
Matthieu Bouron authored
Also fix playback of ntsc files. Reviewed-by:
Tomas Härdin <tomas.hardin@codemill.se> Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 07 Nov, 2012 2 commits
-
-
Peter Ross authored
Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
Peter Ross authored
wtvenc: do not emit stream2 and DSATTRIB_TRANSPORT_PROPERTY chunks; these are not required for playback Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 16 Oct, 2012 1 commit
-
-
Victor Vasiliev authored
Signed-off-by:
Anton Khirnov <anton@khirnov.net>
-
- 15 Oct, 2012 1 commit
-
-
Clément Bœsch authored
This fixes playback in some circumstances (like webm in firefox). Regression after 2c34367b. It is also matching the Matroska specifications: http://matroska.org/technical/specs/notes.html, "The quick eye will notice that if a Cluster's Timecode is set to zero, it is possible to have Blocks with a negative Raw Timecode. Blocks with a negative Raw Timecode are not valid."
-
- 03 Oct, 2012 1 commit
-
-
Michael Niedermayer authored
The timebases before where only guranteed to be 1/fps precisse and could cause AV sync errors on low fps Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 01 Oct, 2012 3 commits
-
-
Michael Niedermayer authored
While a 25 fps stream can in general store frame durations in 1/25 units, this is not true for the timestamps. For example a 25fps and a 25000/1001 fps stream when they are stored together might have a matching 0 timestamp point but when for example a chapter from this is cut the new start is no longer aligned. The issue gets MUCH worse when the streams are lower fps, like 1 or 2 fps. This commit thus makes the muxer choose a multiple of the framerate as timebase that is at least about 20 micro seconds precise Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
With this, when we use a finer timebase than neccessary to store durations the demuxer still knows what the original timebase was. Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
This way audio frames can be exactly stored even when they are not aligned with timestamp 0 Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 28 Sep, 2012 1 commit
-
-
Michael Niedermayer authored
Fixes Ticket1606 Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 27 Sep, 2012 2 commits
-
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
Clément Bœsch authored
Also factorize the common options for the different mov-based tests. Since the header is now on top in the last generated file, the data offset in the seek test needed some updates as well.
-
- 26 Aug, 2012 1 commit
-
-
Michael Niedermayer authored
The seek test improves in accuracy Fixes Ticket877 Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 26 Jul, 2012 1 commit
-
-
Michael Niedermayer authored
By moving it to a later point relative and unknown timestamps are more likely to have been corrected similar patch reviewed-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> Signed-off-by:
Michael Niedermayer <michaelni@gmx.at> Conflicts: libavformat/utils.c
-
- 25 Jun, 2012 1 commit
-
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 29 May, 2012 1 commit
-
-
Mans Rullgard authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
- 17 May, 2012 2 commits
-
-
Mans Rullgard authored
This fixes a bogus bitrate value in the header of WAV files with alaw/ulaw audio. Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Anton Khirnov authored
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
-
- 04 May, 2012 1 commit
-
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 01 May, 2012 1 commit
-
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 24 Apr, 2012 1 commit
-
-
Justin Ruggles authored
This partially reverts acb17302 which would only have needed to change the checksums if channel mixing had been properly avoided. This changes the output file size reference and the seek test reference back to the previous values.
-
- 23 Apr, 2012 1 commit
-
-
Dale Curtis authored
Reduces the amount of upfront data required for cluster parsing thus decreasing latency on seek and startup. The change in the seek-lavf_mkv FATE test is due to incremental parsing no longer reading as much data as the old parser and thus not having that additional data to generate index entries based on keyframes. Index entries are added correctly as the file is parsed. All FATE tests pass and Chrome has been using this patch for ~6 months without issue. Currently incremental parsing is not supported for files with SSA tracks since they require merging packets between clusters. In this case the code falls back to non-incremental parsing. Signed-off-by:
Aaron Colwell <acolwell@chromium.org> Signed-off-by:
Dale Curtis <dalecurtis@chromium.org> Signed-off-by:
Luca Barbato <lu_zero@gentoo.org>
-
- 20 Apr, 2012 3 commits
-
-
Justin Ruggles authored
Change some lavf tests to avoid resampling and channel mixing.
-
Justin Ruggles authored
This avoids resampling and channel mixing by using a source with the correct channel layout and sample rate.
-
Justin Ruggles authored
Avoids resampling and channel mixing. This only tests the behavior with respect to input and output audio rather than also testing changes to the encoder or muxer that do not affect the resulting decoded output.
-
- 05 Apr, 2012 1 commit
-
-
Ramiro Polla authored
The index must take into account the pre-roll time and must seek backwards, not forwards. Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 20 Mar, 2012 2 commits
-
-
Justin Ruggles authored
Update FATE references due to encoder delay.
-
Justin Ruggles authored
Update FATE references due to encoder delay.
-
- 17 Mar, 2012 1 commit
-
-
Justin Ruggles authored
-
- 16 Mar, 2012 1 commit
-
-
Wolfram Gloger authored
Signed-off-by:
Wolfram Gloger <wmglo@dent.med.uni-muenchen.de> Modify the parser initialization so that parsers can set pict_type themselves. Use this in the mpegvideo parser so that initial frames are not unconditionally I frames. I have had this in my tree for several years. Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 09 Mar, 2012 1 commit
-
-
Michael Niedermayer authored
With this we can always know if a timestamp is based on added durations from an unknown origin or if it is based on a correct timestamp (and possibly added durations) This should fix some bugs where this distinction was mixed up. Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 05 Mar, 2012 1 commit
-
-
Justin Ruggles authored
It is unnecessary. Also, for some codecs we're reading more than 1 frame per packet. Instead we use a private context variable to calculate the bit rate, stream duration, and packet durations. Updated FATE seek test, which has slightly different timestamps due to a more accurate bit rate calculation.
-
- 03 Mar, 2012 2 commits
-
-
Justin Ruggles authored
Also, set the time base based on the sample rate. lavf-voc seek test updated to reflect slightly different seek points.
-
Justin Ruggles authored
Update some demuxing and seeking fate tests.
-
- 26 Feb, 2012 1 commit
-
-
Anton Khirnov authored
-
- 13 Feb, 2012 1 commit
-
-
Reimar Döffinger authored
Seek beyond the end will now directly return an error instead of claiming to succeed and then return EOF immediately on next read. This change is because before 47e015e6 mkv seek incorrectly never failed. Signed-off-by:
Reimar Döffinger <Reimar.Doeffinger@gmx.de>
-
- 11 Feb, 2012 2 commits
-
-
Pavel Koshevoy authored
This is so that TS fragments produced by http://code.google.com/p/httpsegmenter/ would be compatible with JW Player. A new member variable prev_payload_key was added to MpegTSWriteStream to help detect transition from non-key to key frame, so that PAT/PMT would not be produced for every keyframe in intra-only videos. Signed-off-by:
Pavel Koshevoy <pkoshevoy@gmail.com> Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
Justin Ruggles authored
This should have been updated in b590f3a7.
-
- 07 Feb, 2012 1 commit
-
-
Anton Khirnov authored
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.
-
- 02 Feb, 2012 1 commit
-
-
Mans Rullgard authored
There is no point in this test using the RM format. Signed-off-by:
Mans Rullgard <mans@mansr.com>
-