Repair a video with changing SAR

[gddpb]

I have a video for which the SAR value changes from 1280/720 (16:9) into other ratios, making rescaling in Handbrake go wrong.
The weird thing is that nothing looks wrong when I watched the unscaled source.
How can this video be repaired i.e. forced to use one SAR (1280/720)?
I tried without success:
mp4box -add input.mp4#video:par=none -add input.mp4#audio output1.mp4
mp4box -add output1.mp4#video:par=16:9 -add output1.mp4#audio output2.mp4
or
mp4box -add output1.mp4#video:par=w16:9 -add output1.mp4#audio output2.mp4
or
mp4box -par 1=16:9 output1.mp4
I use mp4box, ffmpeg, and Handbrake.

[johns0]

Post a mediainfo text pasted in a reply,hard to see what's going on.

[ProWo]

Try ffmpeg -i input.mp4 -aspect 16:9 -c copy output.mp4

[gddpb]

Post a mediainfo text pasted in a reply,hard to see what's going on.

General
Complete name : C:\Users\herwi\Desktop\X\input.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 1.94 GiB
Duration : 58 min 48 s
Overall bit rate mode : Variable
Overall bit rate : 4 723 kb/s
Writing application : Lavf58.45.100

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.2
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 58 min 48 s
Bit rate : 4 587 kb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 50.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.100
Stream size : 1.88 GiB (97%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Codec configuration box : avcC

Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 58 min 48 s
Bit rate mode : Variable
Bit rate : 128 kb/s
Maximum bit rate : 133 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 53.8 MiB (3%)
Language : English
Default : Yes
Alternate group : 1

I already looked at this but it appears to be normal to me.
The problem video is this one:
https://www.bbc.co.uk/iplayer/episode/m000g6mj/age-of-the-image-series-1-2-power-games
The other three parts in that series are ok.
And no, nothing went wrong while downloading as I tried to download it from different servers - all offer the identical faulty file.

[gddpb]

Try ffmpeg -i input.mp4 -aspect 16:9 -c copy output.mp4

Makes no difference, still wrong.

[ProWo]

How do you know the SAR is changing if there is no problem playing it?

[gddpb]

How do you know the SAR is changing if there is no problem playing it?

When I split it up into chunks, up to a certain point it shows the correct SAR and this scales as expected, but after that chunks appear with different SARs, and so the whole file refuses to be rescaled correctly. Weird. The URL of the page where to find it is in another post here.

[ProWo]

Post a small chunk (60secs) of a problematic part here.

[DB83]

When you say "split it up into chunks" you just want certain sequences ?


Well there are various AR's present since not all the clips in the video are native 16:9. Maybe the borders are fooling handbrake which will remove them unless you tell it not to.

[gddpb]

Post a small chunk (60secs) of a problematic part here.

This is a 10-second fragment where the SAR is no longer 16:9 :
https://app.box.com/s/2oonf3v07twwm7fkv39nsm0xjcrofng3
I want to know how to change the SAR to a fixed one for the whole file - without changing the bitstream obviously.

[gddpb]

Well there are various AR's present since not all the clips in the video are native 16:9. Maybe the borders are fooling handbrake which will remove them unless you tell it not to.

I have downloaded many videos from the BBC and rescaled them always to 960/540 without problems in Handbrake, this is the only one that won't do that.
So it must definitely be faulty.

[DB83]

Post a small chunk (60secs) of a problematic part here.

This is a 10-second fragment where the SAR is no longer 16:9 :
https://app.box.com/s/2oonf3v07twwm7fkv39nsm0xjcrofng3
I want to know how to change the SAR to a fixed one for the whole file - without changing the bitstream obviously.

Nothing wrong with that segment >> 1280*720 16:9. Displays correctly in vlc. Maybe it is your player.


And always load samples as attachments in the topic and not as external sources. They will last longer for others reading if they also have similar issues.

[ProWo]

Rescaled to 960x540 without problems here. Maybe a problem with Handbrake.

[DB83]

Here is a Handbrake version of the rescale. As suspected, Handbrake wanted to crop many pixels both left and right so that had to over-ridden first.

[gddpb]

Here is a Handbrake version of the rescale. As suspected, Handbrake wanted to crop many pixels both left and right so that had to over-ridden first.

And HOW did you override this unwanted crop, that's what I'd like to know?!

[gddpb]

vlc[/url]. Maybe it is your player.

You didn't read my post through, I know it plays i.e. displays fine... but it's cropped when I try to rescale it.

[DB83]

Select 'custom' instead of 'automatic' on the cropping dialog and reset the numbers to 0





[Attachment 57287 - Click to enlarge]

[gddpb]

Select 'custom' instead of 'automatic' on the cropping dialog and reset the numbers to 0

Indeed this works!

Now I also understand why this happened.
The video contains a mixture of normal 16:9 video and old black & white movies which obviously were not filmed at 16:9.
Handbrake by default is set to automatically crop black bands.
The 10-second fragment I put online only contained a sequence with black bands to the left and right...
To the left it crops till it reaches the left edge of the broadcaster's logo, to the right it varies according to the aspect ratio of the inserted black & white source material, hence the SARs vary. Unfortunately it crops everything, also the normal 16:9 sequences, to the right probably up to the widest black band it could find, squeezing the overall result horizontally. It's just the consequence of the algorithm in Handbrake to automatically crop black bands, even if, in this case, it shouldn't have done so.
The chunks which I tested and were normal indeed only contained 16:9 material, the problematic chunks contained a mixture, and consequently their SARs varied.
Conclusion: Disable Automatic cropping and set eveything to 0 with the Custom option when the source video to be rescaled/recompressed contains a mixture of material with varying aspect ratios.

Thanks for the assistance!