next_dts is used for estimating the dts of the next packet if it's
missing. Therefore, it makes no sense to set it from the pts of the last
decoded frame. Also it should be estimated from the current packet
duration/ticks_per_frame always, not only when a frame was successfully
decoded.
It currently has different meanings at different times (dts of the last
read packet/pts of the last decoded frame). Reduce obfuscation by
storing pts of the decoded frame in the frame itself.
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.
The actual number (1/1000) will probably require some
discussion/tweaking in the future, but should be good enough for now,
since the timestamps in AVSubtitle are in this timebase by definition.
Using threaded decoding by default breaks backward compatibility if
AVHWAccel is used or if an appliction sets threadunsafe callbacks.
Avconv and avplay still use -threads auto if not specified.
The 'fiel' atoms can be found in H.264 tracks clobbering the extradata.
MJPEG supports non field based extradata, and this data should be
preserved when copying.
It's broken and doesn't work anyway.
This patch means that avconv will ignore encoding options from the ffm
file and will instead use whatever is provided on the commandline as for
normal output.
Commit 035af99 made avconv always call an encoder when using the
null muxer. While useful for 2-pass encodes, it inadvertently
caused an extra memcpy of raw frames when decoding only.
This hack restores the old behaviour when only decoding while
allowing use of the null muxer with encoded streams as well.
Signed-off-by: Mans Rullgard <mans@mansr.com>
I.e. on streamcopy set output codec timebase from input stream timebase
(as opposed to input codec timebase). This should be more sane, because
since the stream is not decoded, the input codec tb has no relation to
the timestamps of the copied packets.
At EOF it makes no sense to modify avpkt.{data,size} in output_packet
since no data is consumed. Frame threading with more than 1 threads
hits the segfault.
I.e. if the packet was only partially consumed, pass the rest of it into
the decoder again.
Also simplify the code so it's the same for video/audio/subs.
