I've some hundreds of broken h264 mp4s that have been encoded with nvenc ffmpeg encoder with conflicting options (-vprofile baseline -bf3), these files pretends to be baseline but they really have some B frames inside, but those B frames are marked by the container as P, so that VLC and ffmpeg fails to decode them and keep the previous I frame.
The files are reported by ffprobe as: I - P - P - P - P - P - P - I - P - P - P - P - P - P - I ... but they are really I - B - B - B - B - B - B - I - B - B - B - B - B - B - I ... The curious thing is that: - VLC, ffmpeg, ffplay and the iOS player cannot playback them smoothly (but in a jerky 3/4 fps) - quicktime, windows media player and the android video player can playback them perfectly So I'd like to try to fix them or re encode them if a fix is not possible. Doing a simple step of: ffmpeg -i source.mp4 -acodec copy -vcodec copy dest.mp4 ... but it doesnt work neither: ffmpeg -i source.mp4 -vcodec libx264 -acodec copy dest.mp ... and examining the output of: ffmpeg -i source.mp4 -vframes 100 %04d.png I saw that the problem is that ffmpeg decode all the frames that are not I as the previous I frame, and this is probably correct because ffmpeg trusts the container, while quicktime and co probabily go inside the h.264 data structure... Here is a sample (4MB): https://www.dropbox.com/s/cic295zli9b3z33/sample.mp4?dl=0 There is a way to force ffmpeg to decode the h264 in an alterative way so that the frames are interpreted with their correct type? -- Bye, Gabry _______________________________________________ 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".
