m2v mpeg2 issue

[Smyl3]

Hi, Does video-compare support m2v mpeg2 video only media playback? The original source is a DVD. Playback is starting but unable to seek in file as other video player can. It always starts to playback from the beginning. If I start video-compare it shows 720x576, 00:00:00.000, mpeg2video, yuv420p, mpegvideo If I start to compare with itself, both starts playback. If I start it with the m2v and a h264 mkv file, the mkv file playback does not start at all (black screen)

[jonfryd]

Hi @Smyl3,

Well, it depends on what you mean exactly.

I can confirm that video-compare works just fine with random .VOB files (i.e., segments/chapters) from an old DVD. However, video-compare cannot automatically process the whole VIDEO_TS directory by seamlessly joining segments of the main production, as some viewers can. In FFmpeg, you would need to concatenate all the DVD chapters/segments to encode the entire production, as far as I know. The point is that this is not a limitation which is unique to video-compare.

BTW, a duration of 00:00:00.000 would indicate that the duration of the video is unknown (which is a bit weird for an MPEG-2 video file). What is the duration of the mkv file?

[Smyl3]

I already extracted video and audio content from the DVD with PGC Demux, so nothing to do with the VOB files. Their playback is fine in video-compare tho and able to seek as well. After extract got one piece m2v mpeg2 video file and more audio track files, but video-compare has m2v playback issues. My encoded mkv file (based of the mentioned m2v and audio files) playback is fine, its length is 01:35:28.040, h264, yuv420p, matroska,webm. I wanted to compare the m2v file with my reencoded mkv.

[jonfryd]

If your extracted MPEG-2 file can be decoded by FFmpeg's libavcodec, then it should work correctly in video-compare.

Can ffplay or mpv play back the m2v file you extracted with PGC Demux? video-compare is based on the same FFmpeg libav* core libraries as those.

Also, what version of video-compare are you using and what OS are you on?

[Smyl3]

OS: Windows 10 video-compare version: 20230807-win10-x86_64 I downloaded ffmpeg 5.1.2-essentials_build-www.gyan.dev package. m2v file playback with ffplay shows: Duration: N/A, bitrate: N/A I able to seek fine back and forth while playback tho, does not jump to the beginning every time as video-compare. I have a small MediaInfo v22.09 tool which shows duration immediately of the m2v file.

[jonfryd]

Thank you for providing all the information.

I believe there is indeed an issue related to seeking via mouse clicks when the duration is unknown which could explain the behaviour you describe.

Does relative seeking using the arrow keys work as expected?

[Smyl3]

Thanks for the fast reply.

No, in video-compare neither of the seeking options works. It always jumps back to the beginning and preventing the other media files playback either as mentioned.

Tried mpv either and it seeks fine with keys relatively but it shows wrong full length of the media file, so jumping to a certain point capability with a mouse click is buggy and useless.

[jonfryd]

OK, thanks for the info!

I compiled a port of PGC Demux on my Mac and demuxed a file. I was able to reproduce the issue you have reported easily.

It seems that the files produced by PGC Demux are essentially semi-broken when subjected to a deeper analysis. For example, 40% of the frame presentation time stamps are missing (even on I-frames) according to ffprobe -show_frames. Also, while mediainfo 22.09 can display a duration (and FFmpeg, mpv, and video-compare cannot), the value being reported is way off.

That being said, the latest code from video-compare's master branch is actually able to seek correctly (I did some work a couple of weeks ago to increase robustness) using the arrow keys. Jumping to a certain point via mouse clocks does not work since the duration is unknown, though.

I'd suggest we close this issue since video-compare does not have problems with m2v files if they have full integrity, and I've already addressed the seeking issue for "bad" files to some degree.

My recommendation would be to use a different demuxer than PGC Demux that generates proper m2v files.

[jonfryd]

@Smyl3,

I just found a fast way to wrap the video in an MPEG transport stream container (while fixing duration and frame timestamps) using FFmpeg without requiring re-encoding:

ffmpeg -r [fps] -fflags +genpts -i [pgc_demux_output.m2v] -bsf:v setts=pts=STARTPTS+N*90000/[fps] -c copy [fixed_m2v.ts]

Replace [fps] with the frame rate of your file. The fixed output file works fine in the 20230807 build of video-compare.

[Smyl3]

@jonfryd

thanks for your effort. mediainfo is reporting the length fine for me. its the same as the reencoded mkv media. Media Player Classic can handle that m2v but it reports wrong length, although seeking and jumping to a point seems fine, thats why I assumed the video file is good and reencoding works too with preview of synth filters. I confirm that after fixing m2v with your method, seeking, jumping works in video-compare either. However when I tried to use video-compare on the fixed m2v and my reencoded media, it seems they are not in sync for some reason. video-compare wrote in cmd window:

Note: The right video has a start time of 1.440 - timestamps will be shifted so they start at zero!

However their lengths are reported identical.

I tried a different demuxer (DVD decrypter) and it produced same broken m2v per vob.

[jonfryd]

You're welcome, thanks for the update!

It is interesting that mediainfo reports the correct duration on your system. Perhaps it is a bug in the ported version of PGC Demux I'm using which causes the duration to be off by several minutes.

Anyway, the MPEG-TS file I produced on my system starts at 1.440 s, as well. To improve on that you can add the -muxdelay 0 to the ffmpeg command I proposed. If I do that, time stamps will start at 0.04 s instead and you can then use video-compare time-shift options (either on the command line or keyboard) to get the fixed video in sync with your MKV encoding.

BTW, I suspect FFmpeg's libavformat implementation of the raw MPEG-2 video demuxer is somewhat incomplete or buggy, which explains why DVD decrypter's output also does not work as well as you would hope.