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

[poutnik]

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.

Rather thinking twice as many apples will not fit the bag, if already full.

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").

But that is not relevant, IMHO. It is resolution versus size versus quality.
Have you tried to resize 720x576 video to 1920 x 1200 to the same bitrate, encoding it by same codec ? :-)

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

Yes, I do, but it is different case, as it is preprocesed by Avisynth.

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

What is confusing on replication ? Is  not confusion refusal of replication ?
But as I said, it is not issue for me, having mkv option.

[AQUAR]

Rather thinking twice as many apples will not fit the bag, if already full.

You missed the point - we are not magically getting any extra apples to fit into the same bag.

Have you tried to resize 720x576 video to 1920 x 1200 to the same bitrate, encoding it by same codec ? :-)

Yes I have. Why not try it yourself and see how different ways of getting to the picture on a screen pans out on your systems.
On a high end PC with a half decent GPU - probably won't pick the difference (hardware accelerated scaling!).
On a stand alone media player coupled to a TV - probably very much easier to pick the difference.
Maybe look at some P2P stuff - plenty of HD/very low bitrates/high spatial resolution stuff to be found there.
Also you misssed the point of the screen pixel resolution mismatch between video card and monitor.

What is confusing on replication ? Is  not confusion refusal of replication ?

It breaks the purpose of a video editor in that you want control from a know baseline.
The automated fiddle will only need to be reversed by most endusers that won't get what happened.
ADM provides you with the media stats so you can manually configure to suit your project (well almost!).
IMHO a configure option for the PAR on MP4 is useful (ie we agree on that!).

Anyway these are just my opinion.
The developer may well be supportive in yours.

[poutnik]

You missed the point - we are not magically getting any extra apples to fit into the same bag.

Why magically ?  SD to HD means  5 times more apples to the same bag, if we have requirement of the same size.

Have you tried to resize 720x576 video to 1920 x 1200 to the same bitrate, encoding it by same codec ? :-)
Yes I have.

With the same bitrate and 5time lower bit/pixel ratio ? I usually use X264 CRF 24-26. The result must be ugly, as by rule of thumb CRF difference of 6 make ratio of sizes about 2,
so it could be about CRF difference of 15 grades, some 40. ( I suppose in  such extreme case rule 6-2 will not be correct ).

Why not try it yourself and see how different ways of getting to the picture on a screen pans out on your systems.

Just for fun I will try to resize some of my 640*352  400 MB movies to 5x more pixels and recode to about same size.

Also you missed the point of the screen pixel resolution mismatch between video card and monitor.

I have just not commented it.

[poutnik]

With the same bitrate and 5time lower bit/pixel ratio ? I usually use X264 CRF 24-26. The result must be ugly, as by rule of thumb CRF difference of 6 make ratio of sizes about 2,
so it could be about CRF difference of 15 grades, some 40. ( I suppose in  such extreme case rule 6-2 will not be correct ).

I agree the difference will not be so big as for 5times more pixels of original, even with good sharpening resizers.
But anyway, will be challenging for encoder.

But not for such extreme, but for 720*576 to 1024*576 PAR 1:1 it can make sense.

[AQUAR]

SD to HD means 5 times more apples to the same bag, if we have requirement of the same size

From a simple perspective - the apples are now 1/5 in size and so still only just fill that same bag!

Getting away from the apples analogy:
Conceptually the ability to reproduce a video frame is dictated by:  pixel bit rate X the pixel resolution / codec.
Play around with that equation as each item is a variable, it also demonstrates you can never gain information.
Everything has practical boundaries of course, so no cronic up or down scaling to prove a point.
I am sure You realise that choice of codec and optimising it for each recode scenario also has an impact on the end result
(ignored that and other factors just for simplicity).
As a side note: you can alter the presentation of the information for a perceived improvement (eg gausian blur, edge sharpening).
And since you mentioned it "spline upsampling"may be a bit to much like a dog chasing its tail, as the spline algoritm invents lots of new data (not new information), so requiring extra compression to maintain the bit rate (but worth trying in the playoff against other scaling modes eg avidemux options, media player correction for mismatched PAR's, graphics card HWA scaling etc etc).

All in all its pretty academic for the casual avidemux user.
Shorthand for "There isn't a one approach is best" for all video material.
Luckily, most default/blind recodes will work out just fine for the needs of the typical enduser.

[poutnik]

Let keep scenario of encoding  by a codec of choice ( X264, CRF24 ) of materials listed below.

The more sofisticated procedures of upsampling add more a more artificial data to original material to look better,
so the result is less compresible stuff, ending with larger and larger encodes, ending at large size of originally HD sample.

But if constraining final size is ordered, better upsampled stuff is more deteriorated by limited size.
And using low quality upsampling to minimize deterioration is very close or even worse,
compared to replay upsampling of originally SD sample.
As. e.g. MPC based players can use bilinear or bicubic upsampling ( eventually with usage of GPU pixel shaders ).

( Or, whatever postprocess Avisynth upsampling user wants and CPU can manage.
I was e.g. frequently using GPU based Avisynth FFT postprocess denoising )
-----------------------
a given originally SD material
The same  material upsampled to HD by P2P resize
The same  material upsampled to HD by bilinear resize
The same  material upsampled to HD by bicubic resize
The same  material upsampled to HD by Lanczos, Spline16/36/64 or other line contrast keepers
                          ( or various very sofisticated Avisynth resizing sharpening scripts )
the same material, but originally HD

[poutnik]

E.g., I  tried about 1 minute long SD cut from nature document.

Encoded at original 720x576, it took about 6.15 MB after Yadif deintelace. by AVC CRF 24.   
HD stuff 1920x1080 would have about 30 MB.

when I have the same stuff upsized, it got at same codec settings
20 MB for ADB bilinear resizer,
21.7 MB for ADB bicubic resizer,
22.2 MB for ADB lanczos resizer

When I took lanczos resizing , and encoded it at Q34, I got HD of the same size about 6 MB as SD content,
but visually worse, than when SD was HD upsized during replay.

[AQUAR]

Short Reply: I think we are just approaching the issue at opposing ends.

As I said - "There isn't a one approach is best" for all video material (obviously wrt the system processing chain!).
Here you are using GPU power to upscale with lots of tricks, but see what happens on a simple standalone media player feeding a TV.
But it does demonstrate that lower resolution video typically has a higher compressibility factor (we agree on that!).

There are just a lot of software and hardware variables involved that playoff against one another.
(despite all that: HD full lenght feature films, compressed with AVC to less than 1GB, can give fantastic visual quality on both low and high end playback systems.)

[poutnik]

Of course there is no best approach, as there are different priorities.
Different aproach for quality, for size, different for encoding/decoding effort.

I can agree with you final HD note.
But I never process HD stuff. There are few HD channels in DVB-T here, but for some reasons they have much worse reception quality than SD ones.
And I do not pirate BlueRays, neither have I for it a BR player.

[AQUAR]

Hopefully We have both gained from each others experiences!

In case anyone is confused - for a given playback system:-

A SD video file, with good hardware up-scaling will tend to give a higher bit rate end result (quality) in
comparison to good upscaling by software with compression to maintain the original file size.

Converses are also true (ie poor hardware upscaling compared to good software upscaling).

Break even point for these approaches is of course totally dependent on the playback harware.

And, if maintaining file size is not a constraint then it still is all about the best quality end result.

[poutnik]

I agree if size is not limitation,
good upscaling and processing before encoding - especially if avisynth script function based
provides superior result, compared to simple SW/HW post process upscaling.

BTW - I have noticed ADM MP4--Cut/copy to MP4 wipes out also X264 settings from MP4 by MeGUI, that Mediainfo displays.
I have originally thought they are coded into video stream header...

[AQUAR]

Avisynth is a much underrated super beast.
It gives freedom to decode and pre-process media files in ways that are very hard to find in most video editing programs.

Example:
I was using avisynth with FFDshow to feed decoded AVC frames to avidemux 2.5, way before avidemux 2.6 came along.
Worked perfectly!.
Lots of scripts and plugins available - like for doing fancy deinterlacing.

Glad that avidemux still has the avsproxy component to fetch these avisynth generated frames.

Anyway, thanks for the polite and benign discussion.
It was nice not to be bludgened for a change when presenting an opposing view.

[poutnik]

Exactly. But I am afraid to advice Avisynth usage to people, who just want convert A to B...

I was using e.g.  FFT3DGPU post process denoising, or warp resizing of DAR 4:3 to 16:9.

I was my please to meet sometimes different, but mutually respecting opinions.

[Jan Gruuthuse]

Just revisited a similar issue, due to some hardware media player not respecting DAR info in some containers, 16:9 showing as 4:3.
576i 16:9 mpeg-ts PAL is re encoded by me to:
- 1024 x 576 for acceptable quality on flat screen TV
- 768 x 432 lower quality transmissions by the provider
both showing correctly in 16:9

[poutnik]

Just revisited a similar issue, due to some hardware media player not respecting DAR info in some containers, 16:9 showing as 4:3.
576i 16:9 mpeg-ts PAL is re encoded by me to:
- 1024 x 576 for acceptable quality on flat screen TV
- 768 x 432 lower quality transmissions by the provider
both showing correctly in 16:9

Interesting would be comparing MeGUI versus ADM mp4.
I currently reeencode DVB-T PAL 704/720*576 PAL 16:9 MPG to 854*480 MP4/AVC/AAC High/DXVA profile to view either on PC, either on Sony Xperia M 854*480 screen.