> > Anyways, this seeking bug is the opposite, fine on 3.1.3 but broken on > > 3.1.1 and HEAD. > > You already said so.
I had mentioned it, but I just wanted to show the numbers in case it helped > Please do not top-post here, Carl Eugen Yeah, thanks for the reminder (darn gmail) I ran bisect on the release/3.1 branch between that HEAD and 3.1.1 The commit '309fa24f361f1c9d357f8d152c3b78718d2f870d' seems to have broken the nb_frames count but fixed seeking. ffmpeg -y -loglevel error -ss 00:00:00 -vsync 0 -i 2708-1.m3u8 -f image2 -q:v 1 -vframes 1 dude.png Gives the right image but ffprobe -v error -show_entries stream=nb_read_frames -count_frames -pretty 2708-1.m3u8 gives 150 too many frames (67283). ffprobe from an mp4(codec copy) gives 67133 frames (the expected value) The commit before '3586c68687035225451f57c4e422673cbe6d4377' Is the opposite, seeking is off but nb frames is ok. Louis _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
