Breaking anamorphic pixel ratio in mp4(avc/aac) if I-cut and copied to mp4 again

[poutnik]

I have reviewed similar threads, but still not sure, what is the reason and easy solution for the issue.
As it seems to me as a Avidemux bug.

For DVB-T MPG archiving purposes, I re-encoded it ( not sure if in Avidemux or MeGUI)
to anamorphic MP4(AVC,AAC) 702x576 DAR 16:9.

But, I  forgot to cut commercials.

When  I tried Avidemux 2.6.8 to cut it at I frames and copy to the new MP4, the anamorphism got lost.
At least when replayed by MPC-BE.

Fact is, I usually avoid to use PAR other than 1:1, as more DAR failure occurred in past in Avidemux,
but I was not sure if I made some mistake in the process flow....


Background:
I frequently record documentary videos from DVB-T as mpg for viewing a/o archiving later.
As no hard disk is big enough, I usually use H264 re-encoding.
For stuff to view and kill, I used batch reprocessing to mp4(avc/aac) by MeGUI on Windows., mostly 640/352, PAR 1:1
Stuff to archive I usually process by fine processing either by MeGUI or Avidemux 2.6.x, sometime keeping original anamorphic 702x576 DAR 16:9

[AQUAR]

I think that issue depends on where the media player looks for PAR info.
I might be wrong, but with AVC/MP4, the stream and the container could convey different PAR's.
Try another media player and see if the DAR changes.

[zakk]

I can't remember Avidemux writing any PAR info in mp4 containers.

[AQUAR]

I think;
Only when using the resize filter, or configuring MKV with the "force display width" flag.
Then either PAR or DAR is set in container metadata.
Else, straight copy mode probably defaults to PAR 1:1.
For avc, some players default to the video stream "metadata".
Can't remember what avidemux does to that info when transcoding (guess it becomes PAR 1:1).

Seems to me the OP probably used MeGUI for the recoding.

[poutnik]

I think that issue depends on where the media player looks for PAR info.
I might be wrong, but with AVC/MP4, the stream and the container could convey different PAR's.
Try another media player and see if the DAR changes.

I am aware container and video strem may contain various apect ratios.
But whatever their values are, should not be the same, video is just copied after cut into the same container ?

It looks to me like if Avidemux did not use or threw away original mp4 file information.

I address this issue by copying the cut mp4t into MKV with forced display width 1024 to achive 16:9 DAR for 704x576 PAL sample,
as was noted in other thread - that I did not know before.

But anyway, Avidemux issue with mp4 copying persists.

[poutnik]

I think that issue depends on where the media player looks for PAR info.
I might be wrong, but with AVC/MP4, the stream and the container could convey different PAR's.
Try another media player and see if the DAR changes.

But the both ratio values in the container and cideo stream
should be the same in both videos, shouldn't they ?

Unless ADM changes them....

[poutnik]

I think;
Only when using the resize filter, or configuring MKV with the "force display width" flag.
Then either PAR or DAR is set in container metadata.
Else, straight copy mode probably defaults to PAR 1:1.
For avc, some players default to the video stream "metadata".
Can't remember what avidemux does to that info when transcoding (guess it becomes PAR 1:1).

Seems to me the OP probably used MeGUI for the recoding.

Yes, I did use MeGUI, I have just checked it on other sample .
It is very convenient way to (optionaly batch) process videos
with predefined parameters of processing and encoding.

The question remains, why copy mode defaults to PAR 1:1 ?

As I can use MKV, it is  not issue for me any-more, if I am aware of that.
But, IMHO it should be fixed.

[AQUAR]

As zak has mentioned, there is no option to set the PAR metadata in the MP4 container.

Avidemux presumes that PAR is 1:1 for all source video's.
So when you do a stream copy into a new MP4 container it has PAR 1:1 meta data.

If you want to preserve the 16:9 DAR of anamorphic video, you need to recode with a configured resize filter. 
Or find a program that lets you set the PAR metadata in MP4's.

Anamorphic video is intended for proper DAR on analog tv's. 
Analog TV's are yesterdays technology and don't equate to square pixels.
All Digital TV's have square pixels, hence its best to recode content for PAR 1:1.
If you just set the container metadata as per your MEGUI work flow, you risk proper DAR and Quality on playback.
1: AVC playback on various media players might fetch different PAR info if container and stream PAR's is set differently.
2: You rely on the scaling functions and consistent PAR transmission across your media player and display. 
3: Using the scaling functions of your media player / TV is an on the fly process and best avoided (by recoding properly).

[poutnik]

Hm....
But then the only aspect ratio information is within AVC video streem, that should be copied through......

Then the same player should treat the same 704x576 16:9 wide screen video stream in the same container the same way.
Either wrong way with PAR 1:1,  or right way with PAR 64:45.

Unless such info is cut away during the cutting.

Is there a reason it may not, that I do not see  ?

OR, is it just matter mp4 and other SW implement ration storage, but Avidemux does not implement it ?
It would explain the reason that MeGUI may include it, but Avidemux ignores it...

The point is, SD DVB-T is , at least in Czech republic, transmitted at 704x576 resolution
regardless to be PAL 4:3 or 16:9. So 16:9 wide screem current recordings are done
has to be always processed as anamorphic MPG PS, unless resampled.

The aspect ratio is in avs2X264 encoding parameters,
so does MPC-HC mediainfo DLL  says it in videostream info.

I usually do not play the record on TV, and if records is not to be resamled,
anamorphic encoding needs to be conserved, unless I would upsize to 1024 width.

[AQUAR]

It a complicated topic - over the air analog broadcast transmission vs over the air digital broadcast transmission and compatibility across all TV display types!

SD DVB-T is 576i in counties with 50 Hz power frequencies, and it's true that its PAR isn't 1:1.
Digital TV's scale that broadcast signal to fit their wide screen/resolution.
Set top box to analog TV does anamorphic translation, ie on a 4:3 TV it presents letter boxed widescreen content.
The processing model is determined by how you set up your set top box (dvd player) in terms of matching the display type used.

If you are going to recode with a current codec like AVC, put the content in the "avc" container (MP4), you are kind of implying an all digital domain. Where the PAR of the display/monitor is 1:1 and the content is preferentially coded with a matching PAR of 1:1.

Nothing at all wrong with preserving content as anamorphic (AVC has that provision I think!).
But if you are going to use a digital display on that content then scaling will occur once or twice or even three times depending on your processing chain. I prefer that scaling (resampling) to be under my control whilst I recode to AVC (as opposed to on the fly resampling by playback devices).

For example my TV has a pixel map mode - where if I feed it 1080P the content is mapped pixel to pixel (no scaling at all).
The clarity of that picture is miles ahead in comparison to using the TV's scaler on 1080P due to overscan (and that is on an high end TV!).

Simply put: you need to decide what scaler you want by weighing up the pro and cons between avidemux doing the deed or playback devices doing the deed (or a combination of both!). 

[poutnik]

I use neither digital nor analog TV, just DVB-T USB dongle  and Philips 1920x1200 IPS Panel. I understand PAR 1:1  is better for digital world, but it does not help with PAR 64:45.

Up-sizing to 1024*576 would increase the size and would make re-encoding less justified.
Downsizing to 702*400 would decrease quality. It is matter storage size versus quality versus replying effort.
Considering this, it is better for me to resize on replay.

I consider resize effort 702x576->1024*576 as marginal compared to 1024x576 ->1024*1080 -->1920*1080.
Or even if 1024*576 step is omitted, as it would not make sense for well written player to ever do it.

It almost looks like ADM supports anamorphic ratios very unwillingly, just because X264 and containers support them, but if it finds it and can delete it, it will do so...   :-D

sidenote:
In my experience, ADM made more such implyings as PAR 1:1, that were not very useful.
Like no reason for default extensions or video and audio timing keep always being in sync.

Perhaps partially on my past complains, AVD 2.6 switched to time count approach instead of frame count approach of ADM 2.5. Before ADM 2.6, DVB-T records were problematic to process without ProjectX, what on other hand cancelled the beauty to have all in one solution of ADM.

[AQUAR]

The information in the discussion applies no matter if you use a PC monitor or TV.
Recoding media files is simply more than preserving the SAR of anamorphic content.

You are kind of wrong in "It is matter storage size versus quality versus replying effort".

Example:
File size is related to bit rate.
So upsizing the resolution whilst maintaining the bit rate does not change the file size.

Obtaining video Quality, as you found out, is multi-dimensional.
Quality can be improved whilst maintaining the same file size by minimising process deterioration in your system.
One key factor (of many) is to use the best scaling engines involved in feeding your display (monitor/TV).
Hence upsizing can work out to greatly benefit the quality.

In stream copy mode, ADM does not alter the stream at all.
So if DAR is defined in the AVC stream then it will stay. 
But in stream copy mode there is multiplexing of that media content into a container of choice.
Choose the MP4 container and setting container metadata for DAR is not available in ADM (maybe MP4Box!).

Anyway, that is just my approach.
Nothing wrong if you stick to your way, just need a program that lets you set DAR in MP4.
Maybe ask the developer for adding an MP4 configuration item for PAR!

[poutnik]

Upsizing the resolution whilst maintaining the bit rate does not change the file size, indeed,
but does change the quality with lower bits/pixel ratio.

Sure, better preencoding upsizing , like Spline64Resize or other fine Avisynth algorithms improves quality,
compared to worse postprocess upsizing.

But either encoded size of upsized file is bigger,
or size is same, but encoding quality of better upsized file is worse.

Main purpose of my re-encoding is decreasing the size with comparable quality.

[poutnik]

Choose the MP4 container and setting container metadata for DAR is not available in ADM (maybe MP4Box!).

AFAIK MeGUI uses MP4Box, so it may be the case MP4Box put DAR in MP4,
while ADM ignores this info in original MP4
and does not replicate it in the new MP4 container.

It is a pity.

[AQUAR]

Upsizing the resolution whilst maintaining the bit rate does not change the file size, indeed,
but does change the quality with lower bits/pixel ratio.

That is not true at all!
It's kind off like believing that 2 halfs of an apple is somehow less than the whole apple.

But even aside from that, consider that the picture frame on a monitor has to fit into a fixed number of pixels.
The bit rate is therefore going to be spread to suit that display resolution.
Try mismatching the video card to monitor and see how bad the display becomes ("square pegs into round holes").

Anyway, it's getting too much off topic, You just want DAR metadata for AVC in MP4.
To me that is looking back at the way things were done.
But I understand it and actually do it myself when recoding with older codecs/containers (as my media player does not playback AVC!).

ADM ignores this info in original MP4

Do you not explicitly have to specify anamorphic recode in MeGUI?

One thing is for sure, we don't want ADM to automatically replicate PAR meta data at the container level (things are confusing enough!).