Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transcodes are off by one video frame #154

Closed
j0sh opened this issue Sep 12, 2019 · 0 comments · Fixed by #153
Closed

Transcodes are off by one video frame #154

j0sh opened this issue Sep 12, 2019 · 0 comments · Fixed by #153

Comments

@j0sh
Copy link
Collaborator

j0sh commented Sep 12, 2019

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 -i in.ts -an -vf fps=30,scale=128x96 -c:v libx264 out0.ts 
ffmpeg -i out0.ts -vf fps=30,scale=128x96 -c:v libx264 out1.ts
ffmpeg -i out1.ts -vf fps=30,scale=128x96 -c:v libx264 out2.ts
ffmpeg -i out2.ts -vf fps=30,scale=128x96 -c:v libx264 out3.ts

ffprobe -loglevel warning -hide_banner -count_frames -show_streams out0.ts | grep nb_read_frames=
ffprobe -loglevel warning -hide_banner -count_frames -show_streams out1.ts | grep nb_read_frames=
ffprobe -loglevel warning -hide_banner -count_frames -show_streams out2.ts | grep nb_read_frames=
ffprobe -loglevel warning -hide_banner -count_frames -show_streams out3.ts | grep nb_read_frames=
  • 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant