[FFmpeg-user] Faster ffprobe-based detection of open GOP h264 ?

[Andrew Randrianasulu]

чт, 11 янв. 2024 г., 17:42 Nicolas Gaullier <nicolas.gaullier at cji.paris>:

> >De : ffmpeg-user <ffmpeg-user-bounces at ffmpeg.org> De la part de Andrew
> Randrianasulu
> >
> >But as  it was said in forum post above - ffprobe  a bit slow, few
> minutes for whole video, eating one cpu core completely.
> >
> >Is there faster way to get this info ?
> Closed vs open gop is usually a local "keyframe" matter. It is not clear
> to me what is your intent : do you want to make sure 100% of the keyframes
> are closed gop ?
>

yes, I want to check my pre-existing videos for this, partially for testing
how various tools (avidemux, vidcut, ffmpeg) can cut them, partially
because I suspect this may play some role in how badly mesa's vdpau driver
on vp5 based nvidia hw decoder reacts to seeks (if majority of internet
streams today are closed-gop, then I might trigger some less-common
codepath with my home-encoded videos ).


If so, you have to parse the stream, so indeed, it takes a long time. I
> don't think there is another option. MP4 muxer only has the global
> "keyframe" info. With quicktime/mpeg2 you would have gotten stss/stps =
> closed/open gop distinction, but it is not your use case.
> Only one thing: as you noticed using MediaInfo, when encoding with
> libx264, there is an SEI describing the encoding parameters and you can get
> the "open_gop" field.
> If you get a very fresh (less than 2 weeks) ffmpeg build, there is an
> option to display this with the showinfo filter:
> ffmpeg -i xxx.mp4 -vf showinfo=udu_sei_as_ascii=1 -frames 1 -f null null
>

thanks, I have ffmpeg git as part of mplayer, but also can compile it
separately.

>
> Nicolas
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
>