How do I fix AVC container SAR?

[kuchikirukia]

I have a 16:9 video with an inserted edit that MeGUI decided to set at 32:9 when encoding. I thought I had fixed it by running it through mkvmerge set at 16:9 since the whole thing displays correctly in MPC-HC, but now I see that MPV is displaying that segment in 32:9.

I can adjust the DAR for everything else, but this segment stubbornly refuses to display in anything but 32:9 in mpv. Is there a way to fix this? I tried extracting raw, muxing AVI, MP4, and nothing I do will get rid of it.

And unfortunately I deleted my intermediate files so I don't have access to that segment by itself. Though, since I know the frame numbers I could probably split it out in mkvmerge.

[kuchikirukia]

Ok, I think I've got it split out. But I still don't know how to fix it.
It plays correctly split out like this but when I merge it together it goes back to 32:9.

Mediainfo:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 10@L5
Format settings, CABAC : Yes
Format settings, ReFrames : 10 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 3mn 12s
Bit rate : 18.9 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 3.556
Frame rate mode : Constant
Frame rate : 60.000 fps
Original frame rate : 59.940 fps

[sneaker_ger]

Try muxing with mkvmerge with added command (if possible from raw ES): --engage remove_bitstream_ar_info
Not sure how thoroughly it works, though.

[kuchikirukia]

Thank you! Merging it as 16/9 with that command strips out the wrong DAR.

[Keiyakusha]

kuchikirukia
Do note though that this solution only works in your case because your video is 1280x720. If you had anamorphic video with wrong AR, after doing this operation your video would still remain broken (slightly different kind of broken) and would be displayed incorrectly using some other software or hardware players.
And BTW, your video framerate also looks fishy.

[kuchikirukia]

And BTW, your video framerate also looks fishy.

It seems to be a Mediainfo bug. I haven't seen it detect any 59.94 as anything but 60.

[Keiyakusha]

It seems to be a Mediainfo bug. I haven't seen it detect any 59.94 as anything but 60.

I see. This is certainly a bug, I just verified and got the same issue with what I believe a recent mediainfo. I reported similar issue something like 2 years ago, but don't remember if i covered this particular case. Interesting note though. There are 2 ways in mkvmerge to mux this kind of framerate. as 60000/1001p and 60000/1001i. Both give wrong results in mediainfo. With 1st be as in your case, and second displaying FPS correctly but saying that its a VFR...

[DarkSpace]

Look at this tool (http://forum.doom9.org/showthread.php?t=152419) for a solution that actually fixes the value in the bitstream.

[sneaker_ger]

Since his stream has an SAR of 1:1 that (unmaintained) tool is overkill.

I see. This is certainly a bug, I just verified and got the same issue with what I believe a recent mediainfo. I reported similar issue something like 2 years ago, but don't remember if i covered this particular case. Interesting note though. There are 2 ways in mkvmerge to mux this kind of framerate. as 60000/1001p and 60000/1001i. Both give wrong results in mediainfo. With 1st be as in your case, and second displaying FPS correctly but saying that its a VFR...
Is your "60000/1001i" mux in sync?
Either way, the problems concerning the Matroska format and MediaInfo are known. Matroska cannot store 60000/1001 as perfect as MP4. If you want to read a bit:
http://forum.doom9.org/showthread.php?p=1725177#post1725177

[foxyshadis]

Since his stream has an SAR of 1:1 that (unmaintained) tool is overkill.


Is your "60000/1001i" mux in sync?
Either way, the problems concerning the Matroska format and MediaInfo are known. Matroska cannot store 60000/1001 as perfect as MP4. If you want to read a bit:
http://forum.doom9.org/showthread.php?p=1725177#post1725177

--timecode-scale 166833 or 1668333 should be more than precise enough if you need exact numbers. The default is good enough for all situations, but saying that it can't store as well as mp4 isn't true.

[sneaker_ger]

Not saying it isn't good enough but mp4 can do 100% exact.

[DarkSpace]

Since his stream has an SAR of 1:1 that (unmaintained) tool is overkill.
Indeed it is, and kuchikirukia already mentioned that completely removing the SAR "fixed" the bitstream. Personally, I think that relevant information should be stored as closely to its relation as possible, though, so I'd rather store it in the bitstream (even if it's just 1:1) instead of having to rely on a container.

However, the thread title is generalized, so people may well find it when looking for a solution that isn't 1:1.
kuchikirukia
Do note though that this solution only works in your case because your video is 1280x720. If you had anamorphic video with wrong AR, after doing this operation your video would still remain broken (slightly different kind of broken) and would be displayed incorrectly using some other software or hardware players.

All in all, I mentioned it for the sake of completeness, nothing more.

[Keiyakusha]

Is your "60000/1001i" mux in sync?

Haha, nope. I was mainly concerned about mediainfo output that even in this case makes no sense (why would it be labeled as VFR?) and didn't tried to launch it. But now I see what do you mean. 60000/1001i is basically a synonym to 120000/1001p

--timecode-scale 166833 or 1668333 should be more than precise enough if you need exact numbers. The default is good enough for all situations, but saying that it can't store as well as mp4 isn't true.
What if I'll put --timecode-scale -1 into default commandline? Wouldn't it take care of all the possible cases without having to calculate it manually?
Edit: answering my own question: yes it should be precise enough to cover most (if not all) use-cases since will always be dictated by audio, but is a bit of an overkill.

Also I might be not fully understand the issue, but if there are some rounding errors and mediainfo is not capable of determining framerate precisely, why it defaults to showing 60fps instead of 59.94, which is more likely to be true? As it seem to be always detecting 60000/1000 correctly