You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As illustrated in #153 : there is an issue where if we repeatedly transcode an input, we lose a video frame from the result each time. In pathological cases, we'll end up with just one frame as the attached PR exhibits. We should not be losing any frames.
What is known so far:
Preliminary investigation is showing that we typically send N frames to the encoder, and receive (N-1) packets in return. This seems to be the source of the problem. The decoder and filtergraph have been checked and they seem OK.
The FFmpeg CLI itself works fine with an equivalent command, eg
ffmpeg's doc/examples/transcoding program has a similar problem (outputs only ~27 frames when ~31 should be expected), so this is likely an issue that's compensated for within the ffmpeg CLI itself.
This is not specific to an encoder implementation; the same behavior was observed with both libx264 and ffmpeg's H.263 encoder. So if the issue is here, it is with how we use the encoding API.
One possibility is that it is timestamp related. Disabling ts rescaling stops output completely on the second iteration, but that is because we get no frames from the filter, so it may be a different issue completely. Eg:
diff --git a/ffmpeg/lpms_ffmpeg.c b/ffmpeg/lpms_ffmpeg.c
index e9d3350..0d93792 100644
--- a/ffmpeg/lpms_ffmpeg.c+++ b/ffmpeg/lpms_ffmpeg.c@@ -705,7 +707,7 @@ int mux(AVPacket *pkt, AVRational tb, struct output_ctx *octx, AVStream *ost)
{
pkt->stream_index = ost->index;
if (av_cmp_q(tb, ost->time_base)) {
- av_packet_rescale_ts(pkt, tb, ost->time_base);+ //av_packet_rescale_ts(pkt, tb, ost->time_base);
}
// drop any preroll audio. may need to drop multiple packets for multichannel
The text was updated successfully, but these errors were encountered:
As illustrated in #153 : there is an issue where if we repeatedly transcode an input, we lose a video frame from the result each time. In pathological cases, we'll end up with just one frame as the attached PR exhibits. We should not be losing any frames.
What is known so far:
Preliminary investigation is showing that we typically send N frames to the encoder, and receive (N-1) packets in return. This seems to be the source of the problem. The decoder and filtergraph have been checked and they seem OK.
The FFmpeg CLI itself works fine with an equivalent command, eg
ffmpeg's doc/examples/transcoding program has a similar problem (outputs only ~27 frames when ~31 should be expected), so this is likely an issue that's compensated for within the ffmpeg CLI itself.
This is not specific to an encoder implementation; the same behavior was observed with both libx264 and ffmpeg's H.263 encoder. So if the issue is here, it is with how we use the encoding API.
One possibility is that it is timestamp related. Disabling ts rescaling stops output completely on the second iteration, but that is because we get no frames from the filter, so it may be a different issue completely. Eg:
The text was updated successfully, but these errors were encountered: