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
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 can't remember Avidemux writing any PAR info in mp4 containers.
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.
Quote from: AQUAR on December 07, 2014, 11:28:57 AM
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.
Quote from: AQUAR on December 07, 2014, 11:28:57 AM
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....
Quote from: AQUAR on December 07, 2014, 12:59:15 PM
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.
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).
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.
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!).
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.
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!
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.
Quote from: AQUAR on December 10, 2014, 01:12:43 AM
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.
QuoteUpsizing 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!).
QuoteADM 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!).
Quote from: AQUAR on December 10, 2014, 10:14:13 AM
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.
QuoteBut 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 ? :-)
QuoteDo you not explicitly have to specify anamorphic recode in MeGUI?
Yes, I do, but it is different case, as it is preprocesed by Avisynth.
QuoteOne 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.
QuoteRather 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.
QuoteHave 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.
QuoteWhat 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.
Quote from: AQUAR on December 11, 2014, 12:15:17 AM
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.
QuoteHave 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 ).
QuoteWhy 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.
QuoteAlso you missed the point of the screen pixel resolution mismatch between video card and monitor.
I have just not commented it.
Quote from: poutnik on December 11, 2014, 06:17:42 AM
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.
QuoteSD 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.
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
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.
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.)
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.
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.
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...
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.
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.
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
Quote from: Jan Gruuthuse on December 28, 2014, 02:44:06 PM
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.