As a fallout from testing in the topic Crash encoding mpeg2 with the number of consecutive b-frames set to zero (http://avidemux.org/smif/index.php/topic,17645.0.html), it turns out to be that the code in ADM_coreMuxerFfmpeg.cpp
if(fourCC::check(stream->getFCC(),(uint8_t *)"MPEG1"))
{
c->has_b_frames=1; // No PTS=cannot handle CTS...
c->max_b_frames=2;
par->codec_id= AV_CODEC_ID_MPEG1VIDEO;
}
else if(fourCC::check(stream->getFCC(),(uint8_t *)"MPEG2"))
{
c->has_b_frames=1; // No PTS=cannot handle CTS...
c->max_b_frames=2;
par->codec_id= AV_CODEC_ID_MPEG2VIDEO;
}else
always misdetects MPEG (MPEG2) video as mpeg1video, because the check for mpeg1video comes first (otherwise it would always mistedect MPEG1 as mpeg2video). This confuses the MPV video player, which disables hardware accel. if it encounters a MKV with CodecID set to V_MPEG1 where the video is really mpeg2video. ffprobe digs deeper and doesn't allow to be fooled so easily.
Wondering if it could be acceptable to break MPEG-1 which might be almost extinct and assume anything MPEG being mpeg2video? Avidemux seems to mark anything MPEG-2 just "MPEG" (well, there are only 4 chars available).
It would be better to split them, but mpeg2 is indeed a better default
Thank you, I've pushed a band-aid patch.
By the way, Avidemux seems to be incapable to load at least the first MPEG-1 video from http://hubblesource.stsci.edu/sources/video/clips/ (http://hubblesource.stsci.edu/sources/video/clips/). Once repackaged without reencoding with ffmpeg
ffmpeg -i centaur_1.mpg -c copy centaur_1_ffmpeg.mpg
it loads fine (as "MPEG").
It is a mpeg ES (elementary stream)
Not supported in 2.6.x
I see, thanks.