[Mp4-tech] Timing question

[Nicolas El Hani]

Hi Gary,
Thanks so much for your prompt reply, what you said makes complete sense, basically what you're saying is that the only advantage of using main vs. baseline is that the compression from main will be better, and the same with "high" where compression of "high" will be better than main. But if they are all encoded at the same bit rate, the quality, the actual perceived quality from all different profiles will be the same, it's just that the file size will be smaller (main will be smaller than baseline, high smaller than main)? But at the same data rate they will be the same quality? Thank you so much. I really appreciate it.
Nicolas
----------------------------------------
> From: garysull windows.microsoft.com
> To: nicolas505 hotmail.com; rramani gmail.com; mp4-tech lists.mpegif.org
> Date: Wed, 23 Jan 2024 12:35:47 -0800
> Subject: RE: [Mp4-tech] Timing question
> CC: 
> 
> 
> Nicolas El Hani et al,
> 
> I would strongly suggest to consider the High profile rather than the Main profile.  These two profiles have basically the same implementation complexity, but the High profile has better compression capabilities.  The only reason that the Main profile exists is that it was the best we could come up with at the time (about a year before we developed the High profile).
> 
> The High or Main profile would have substantially better compression capability than the Baseline profile.  However, they would require somewhat more computing resources to implement than the Baseline profile, particularly when considering implementation in software on general-purpose processors.  This seems to be the primary reason that some implementations (mobile devices, videoconferencing systems, etc.) use the Baseline profile.  There are also some issues relating to loss/error robustness capabilities (with Baseline having some advantages over Main/High in that regard), but my impression is that those features are generally considered less important than the compression capability and the computational resource requirements (in fact, implementations of the Baseline profile often do not actually take advantage of those enhanced loss/error robustness features).
> 
> Best Regards,
> 
> Gary Sullivan
> 
> +> -----Original Message-----
> +> From: Nicolas El Hani [mailto:nicolas505 hotmail.com]
> +> Sent: Wednesday, January 23, 2024 12:08 PM
> +> To: Gary Sullivan; Ram; mp4-tech lists.mpegif.org
> +> Subject: RE: [Mp4-tech] Timing question
> +>
> +>
> +> Hello Everyone,
> +>
> +> It's my first time on the mailing list, so excuse me if I'm
> +> emailing the wrong address or something is wrong in my
> +> etiquette, just let me know! I'm currently starting a
> +> business that involves video production. I have a basic
> +> fundamental question that maybe is not a very smart
> +> question, but basically is there inherently an advantage to
> +> encode a video in the "main" profile of h.264 over the
> +> "baseline" profile. I know the complexity of the main
> +> encoding is higher. So basically if you had the same file
> +> encoded in baseline and another one in main, with similar
> +> data rates (say 1500kbps) would the end result be the same?
> +> I'm going to be encoding video mostly in VGA resolution and
> +> start to drift towards 720p. The reason I ask is because
> +> final delivery to clients would be much better if the file
> +> could be viewed both on mobile devices (iphone, ipod,
> +> nokias, etc...) and locally on a computer or TV. But if
> +> encoding in baseline at the same resolution will compromise
> +> quality because of its macroblocks or algorithms at the
> +> encoding stage than it's worth it to use just main and if
> +> need be for mobile viewing deliver a second file in
> +> baseline. But it would really be much simpler and would
> +> streamline the business if baseline could hold up to the
> +> main. Thank you so much and I hope it's  not too much of a
> +> bother! Cheers.
> +>
> +> Nick
> +> ________________________________
> +>> From: garysull windows.microsoft.com
> +>> To: rramani gmail.com; mp4-tech lists.mpegif.org
> +>> Date: Wed, 23 Jan 2024 11:03:02 -0800
> +>> Subject: RE: [Mp4-tech] Timing question
> +>> CC:
> +>>
> +>> "Ram" et al,
> +>>
> +>> It is not really true that "time resolution" is fixed to
> +> 30000 in H.263.   The standard uses a term called the
> +> "picture clock frequency".  The default PCF is 30000/1001.
> +> It is also possible to us a "custom PCF". A custom PCF is
> +> given by 1 800 000 / (clock divisor * clock conversion
> +> factor), where clock divisor can have values of 1 through
> +> 127 and clock conversion factor can either be 1000 or 1001.
> +> There was a very old version of the standard that did not
> +> support custom PCF, but that capability was added about 10 years ago.
> +>>
> +>> Also, PAL does not use 29.97 fps.  It is 25 fps.  NTSC is
> +> 30000/1001 fps (which is approximately, but not exactly,
> +> equal to 29.97 fps).
> +>>
> +>> Best Regards,
> +>>
> +>> Gary Sullivan
> +>>
> +>> ________________________________
> +>> From: mp4-tech-bounces lists.mpegif.org
> +> [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Ram
> +>> Sent: Wednesday, January 23, 2024 7:30 AM
> +>> To: mp4-tech lists.mpegif.org
> +>> Subject: [Mp4-tech] Timing question
> +>>
> +>> Hi Guys,
> +>>
> +>> I primarily work with H263 and MPEG4 video codecs. In all
> +> video codecs thers is this parameters in the stream called
> +> Time resolution. In H263 they say it's fixed to 30000
> +>> so that they can achieve 29.97 fps which equals line
> +> frequencies used in PAL.
> +>>
> +>> What is the best value to choose when someone transcodes
> +> between H263 and MPEG4 in either direction.
> +>>
> +>> 'Thanks,
> +>>
> +>> Ram
> +>
> +> _________________________________________________________________
> +>
> +>
> +>
> 
> _______________________________________________
> NOTE: Please use clear subject lines for your posts. Include [audio, [video], [systems], [general] or another apppropriate identifier to indicate the type of question you have.
> 
> Note: Conduct on the mailing list is subject to the Antitrust guidelines found at http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php

_________________________________________________________________