| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
| |
ProRes codes chroma blocks in 444 mode in different order than luma blocks,
so make both decoder and encoder read/write chroma blocks in right order.
Reported by Phil Barrett
|
| |
|
|
|
|
|
|
|
|
| |
r_frame_rate should in theory have something to do with input framerate,
but in practice it is often made up from thin air by lavf. So unless we
are targeting a constant output framerate, it's better to just use input
stream timebase.
Brings back dropped frames in nuv and cscd tests introduced in
cd1ad18a6539bd7fc2dc4c1740fbcbd498c0c0a2
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Right now those muxers use the default timebase in all cases(1/90000).
This patch avoid unnecessary rescaling and makes the printed timestamps
more readable.
Also, extend the printed information to include the timebases and packet
pts/duration and align the columns.
Obviously changes the results of all fate tests which use those two
muxers.
|
| |
|
|
|
|
|
| |
The size check must be updated to take into account both manners
in which v_data_size might be set.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
| |
|
|
|
|
|
|
|
| |
The pixel format is not known until the frame header is parsed.
Guessing it here only causes trouble for the caller if the guess
turns out to be wrong (and actually causes very wrong output by
avconv/avplay).
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
| |
|
|
| |
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
|
| |
|
