PAL & Overscan / Non Square Pixels?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

PAL & Overscan / Non Square Pixels?

Giskard
Hi all,

when I record a transport stream from the satellite (e.g., using
MythTV), it has a resolution of 720x576 pixel. This is not the 4:3
format which I expected. I googled for it and read about overscan and
non square pixels which are the reason for this. My question is what
should I do to have this displayed correctly on a computer monitor after
conversion? Should I, for example, crop the height to 540 pixel?

Many thanks,
Michael

--
icq: 71772353 | skype: daneel1409 | msn: [hidden email]

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: PAL & Overscan / Non Square Pixels?

Mikael Hakman
Hello,

On Sunday, December 16, 2007 9:46 PM Michael Ransburg wrote:
> when I record a transport stream from the satellite (e.g., using
> MythTV), it has a resolution of 720x576 pixel. This is not the 4:3
> format which I expected. I googled for it and read about overscan and
> non square pixels which are the reason for this. My question is what
> should I do to have this displayed correctly on a computer monitor after
> conversion? Should I, for example, crop the height to 540 pixel?

I'm not expert but I think that the number 720 reflects the fact that in TV
broadcasting the pixels are not square but 768/720 wider than tall. One way
to deal with this is to stretch the width from 720 to 768 when you display
on a screen with square (or circular) physical pixels. BTW, it would be nice
to know why broadcasters chose oblong pixels instead of square.

Thanks/Mikael

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: PAL & Overscan / Non Square Pixels?

Giskard
Hi Mikael,

Mikael Hakman wrote:

> Hello,
>
> On Sunday, December 16, 2007 9:46 PM Michael Ransburg wrote:
>  
>> when I record a transport stream from the satellite (e.g., using
>> MythTV), it has a resolution of 720x576 pixel. This is not the 4:3
>> format which I expected. I googled for it and read about overscan and
>> non square pixels which are the reason for this. My question is what
>> should I do to have this displayed correctly on a computer monitor after
>> conversion? Should I, for example, crop the height to 540 pixel?
>>    
>
> I'm not expert but I think that the number 720 reflects the fact that in TV
> broadcasting the pixels are not square but 768/720 wider than tall. One way
> to deal with this is to stretch the width from 720 to 768 when you display
> on a screen with square (or circular) physical pixels. BTW, it would be nice
> to know why broadcasters chose oblong pixels instead of square.
>  

Many thanks for the reply. Does this mean that ffmpeg will automatically
transform these non-square pixels into square pixels when it processes
this video stream? Thus - without the scaling which you propose -
everything would look too (vertically) "too thin" in the video?

So - if I understand you correctly - when processing such a stream in
ffmpeg I should first scale up the with to 768 (or scale down the height
to 540) before I do any other processing in order to work on the correct
aspect ratio - right? Do I have to use any special flag to tell ffmpeg
to transform the non-square pixels to square ones?

How did others deal with this issue? I assume that postprocessing TV
recordings is a pretty wide spread use case for ffmpeg...

Many thanks,
Michael

> Thanks/Mikael
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
>  


--
icq: 71772353 | skype: daneel1409 | msn: [hidden email]

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: PAL & Overscan / Non Square Pixels?

Michel Bardiaux-2
Michael Ransburg a écrit :

> Hi Mikael,
>
> Mikael Hakman wrote:
>> Hello,
>>
>> On Sunday, December 16, 2007 9:46 PM Michael Ransburg wrote:
>>  
>>> when I record a transport stream from the satellite (e.g., using
>>> MythTV), it has a resolution of 720x576 pixel. This is not the 4:3
>>> format which I expected. I googled for it and read about overscan and
>>> non square pixels which are the reason for this. My question is what
>>> should I do to have this displayed correctly on a computer monitor after
>>> conversion? Should I, for example, crop the height to 540 pixel?
>>>    
>> I'm not expert but I think that the number 720 reflects the fact that in TV
>> broadcasting the pixels are not square but 768/720 wider than tall. One way
>> to deal with this is to stretch the width from 720 to 768 when you display
>> on a screen with square (or circular) physical pixels. BTW, it would be nice
>> to know why broadcasters chose oblong pixels instead of square.
>>  
>
> Many thanks for the reply. Does this mean that ffmpeg will automatically
> transform these non-square pixels into square pixels when it processes
> this video stream?

No. ffmpeg (the CLI) maintains the *display* aspect ratio. Example
(using a capture from a French TNTcast):

ffmpeg -i ../fbe/france2-20070829.ts -s 352x288 -vcodec mpeg1video jul.mpg
FFmpeg version SVN-r11006, Copyright (c) 2000-2007 Fabrice Bellard, et al.
   configuration: --enable-gpl --enable-liba52 --enable-libgsm
--enable-libmp3lame
   libavutil version: 49.5.0
   libavcodec version: 51.48.0
   libavformat version: 51.19.0
   built on Nov 19 2007 15:06:05, gcc: 4.1.2 20061115 (prerelease)
(Debian 4.1.1-21)
Input #0, mpegts, from '../fbe/france2-20070829.ts':
   Duration: 00:03:10.1, start: 31624.168367, bitrate: 4414 kb/s
   Program 1
     Stream #0.0[0x100]: Video: mpeg2video, yuv420p, 720x576 [PAR 16:15
DAR 4:3], 15000 kb/s, 25.00 fps(r)
     Stream #0.1[0x200]: Audio: mp2, 48000 Hz, stereo, 192 kb/s
Output #0, mpeg, to 'jul.mpg':
     Stream #0.0: Video: mpeg1video, yuv420p, 352x288 [PAR 12:11 DAR
4:3], q=2-31, 200 kb/s, 25.00 fps(c)
     Stream #0.1: Audio: mp2, 48000 Hz, stereo, 64 kb/s

> Thus - without the scaling which you propose -
> everything would look too (vertically) "too thin" in the video?
>
> So - if I understand you correctly - when processing such a stream in
> ffmpeg I should first scale up the with to 768 (or scale down the height
> to 540) before I do any other processing in order to work on the correct
> aspect ratio - right? Do I have to use any special flag to tell ffmpeg
> to transform the non-square pixels to square ones?

No, just specify -s so that in the messages related to the output video
you get PAR 1:1.

>
> How did others deal with this issue? I assume that postprocessing TV
> recordings is a pretty wide spread use case for ffmpeg...

Depends on what you want to achieve.

--
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:[hidden email]

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: PAL & Overscan / Non Square Pixels?

Mikael Hakman
Michel Bardiaux wrote:

> Michael Ransburg a écrit :
>> Hi Mikael,
>>
>> Mikael Hakman wrote:
>>> Hello,
>>>
>>> On Sunday, December 16, 2007 9:46 PM Michael Ransburg wrote:
>>>
>>>> when I record a transport stream from the satellite (e.g., using
>>>> MythTV), it has a resolution of 720x576 pixel. This is not the 4:3
>>>> format which I expected. I googled for it and read about overscan and
>>>> non square pixels which are the reason for this. My question is what
>>>> should I do to have this displayed correctly on a computer monitor
>>>> after
>>>> conversion? Should I, for example, crop the height to 540 pixel?
>>>>
>>> I'm not expert but I think that the number 720 reflects the fact that in
>>> TV
>>> broadcasting the pixels are not square but 768/720 wider than tall. One
>>> way
>>> to deal with this is to stretch the width from 720 to 768 when you
>>> display
>>> on a screen with square (or circular) physical pixels. BTW, it would be
>>> nice
>>> to know why broadcasters chose oblong pixels instead of square.
>>>
>>
>> Many thanks for the reply. Does this mean that ffmpeg will automatically
>> transform these non-square pixels into square pixels when it processes
>> this video stream?
>
> No. ffmpeg (the CLI) maintains the *display* aspect ratio. Example
> (using a capture from a French TNTcast):
>
> ffmpeg -i ../fbe/france2-20070829.ts -s 352x288 -vcodec mpeg1video jul.mpg
> FFmpeg version SVN-r11006, Copyright (c) 2000-2007 Fabrice Bellard, et al.
>    configuration: --enable-gpl --enable-liba52 --enable-libgsm
> --enable-libmp3lame
>    libavutil version: 49.5.0
>    libavcodec version: 51.48.0
>    libavformat version: 51.19.0
>    built on Nov 19 2007 15:06:05, gcc: 4.1.2 20061115 (prerelease)
> (Debian 4.1.1-21)
> Input #0, mpegts, from '../fbe/france2-20070829.ts':
>    Duration: 00:03:10.1, start: 31624.168367, bitrate: 4414 kb/s
>    Program 1
>      Stream #0.0[0x100]: Video: mpeg2video, yuv420p, 720x576 [PAR 16:15
> DAR 4:3], 15000 kb/s, 25.00 fps(r)
>      Stream #0.1[0x200]: Audio: mp2, 48000 Hz, stereo, 192 kb/s
> Output #0, mpeg, to 'jul.mpg':
>      Stream #0.0: Video: mpeg1video, yuv420p, 352x288 [PAR 12:11 DAR
> 4:3], q=2-31, 200 kb/s, 25.00 fps(c)
>      Stream #0.1: Audio: mp2, 48000 Hz, stereo, 64 kb/s
>
>> Thus - without the scaling which you propose -
>> everything would look too (vertically) "too thin" in the video?
>>
>> So - if I understand you correctly - when processing such a stream in
>> ffmpeg I should first scale up the with to 768 (or scale down the height
>> to 540) before I do any other processing in order to work on the correct
>> aspect ratio - right? Do I have to use any special flag to tell ffmpeg
>> to transform the non-square pixels to square ones?
>
> No, just specify -s so that in the messages related to the output video
> you get PAR 1:1.
>
>>
>> How did others deal with this issue? I assume that postprocessing TV
>> recordings is a pretty wide spread use case for ffmpeg...
>
> Depends on what you want to achieve.

Just to clarify. No software in the world can know the actual form of
physical pixels on your physical screen unless the software communicates
with the screen device, which ffmpeg doesn't do. Therefore it cannot know
the resolution and aspect ratio of your screen device. You have to tell it
that. One way to do this is by using the -s switch on command line.
Therefore if you want to produce a file for display on a screen with square
pixels (as most computer screens are) and you want to see a circle as a
circle, not as oval, then you could use -s 768x576 if you want that
resolution. If the actual broadcast contains 720x576 format and it is 4:3
aspect ratio then you should get perfectly round circles.

Things are getting more interesting when the actual broadcast is 16:9 but
still at 720x576, as often done today (broadcasted pixels are even more
oblong). Should you specify -s 1024x576? Well, that depends on your TS
processor. In the TS stream (the DVB broadcast multiplex stream) there is
information whether the video is in 4:3 or 16:9 aspect. Clever TS
demultiplex/decoder could rescale things so that you always specify 768x576
when your screen has these pixel dimensions. I do not know what ffmpeg does
in this case. Any comments, Michel?

Thanks/Mikael

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: PAL & Overscan / Non Square Pixels?

Michel Bardiaux-2
Mikael Hakman a écrit :

> Michel Bardiaux wrote:
>> Michael Ransburg a écrit :
>>> Hi Mikael,
>>>
>>> Mikael Hakman wrote:
>>>> Hello,
>>>>
>>>> On Sunday, December 16, 2007 9:46 PM Michael Ransburg wrote:
>>>>
>>>>> when I record a transport stream from the satellite (e.g., using
>>>>> MythTV), it has a resolution of 720x576 pixel. This is not the 4:3
>>>>> format which I expected. I googled for it and read about overscan and
>>>>> non square pixels which are the reason for this. My question is what
>>>>> should I do to have this displayed correctly on a computer monitor
>>>>> after
>>>>> conversion? Should I, for example, crop the height to 540 pixel?
>>>>>
>>>> I'm not expert but I think that the number 720 reflects the fact that in
>>>> TV
>>>> broadcasting the pixels are not square but 768/720 wider than tall. One
>>>> way
>>>> to deal with this is to stretch the width from 720 to 768 when you
>>>> display
>>>> on a screen with square (or circular) physical pixels. BTW, it would be
>>>> nice
>>>> to know why broadcasters chose oblong pixels instead of square.
>>>>
>>> Many thanks for the reply. Does this mean that ffmpeg will automatically
>>> transform these non-square pixels into square pixels when it processes
>>> this video stream?
>> No. ffmpeg (the CLI) maintains the *display* aspect ratio. Example
>> (using a capture from a French TNTcast):
>>
>> ffmpeg -i ../fbe/france2-20070829.ts -s 352x288 -vcodec mpeg1video jul.mpg
>> FFmpeg version SVN-r11006, Copyright (c) 2000-2007 Fabrice Bellard, et al.
>>    configuration: --enable-gpl --enable-liba52 --enable-libgsm
>> --enable-libmp3lame
>>    libavutil version: 49.5.0
>>    libavcodec version: 51.48.0
>>    libavformat version: 51.19.0
>>    built on Nov 19 2007 15:06:05, gcc: 4.1.2 20061115 (prerelease)
>> (Debian 4.1.1-21)
>> Input #0, mpegts, from '../fbe/france2-20070829.ts':
>>    Duration: 00:03:10.1, start: 31624.168367, bitrate: 4414 kb/s
>>    Program 1
>>      Stream #0.0[0x100]: Video: mpeg2video, yuv420p, 720x576 [PAR 16:15
>> DAR 4:3], 15000 kb/s, 25.00 fps(r)
>>      Stream #0.1[0x200]: Audio: mp2, 48000 Hz, stereo, 192 kb/s
>> Output #0, mpeg, to 'jul.mpg':
>>      Stream #0.0: Video: mpeg1video, yuv420p, 352x288 [PAR 12:11 DAR
>> 4:3], q=2-31, 200 kb/s, 25.00 fps(c)
>>      Stream #0.1: Audio: mp2, 48000 Hz, stereo, 64 kb/s
>>
>>> Thus - without the scaling which you propose -
>>> everything would look too (vertically) "too thin" in the video?
>>>
>>> So - if I understand you correctly - when processing such a stream in
>>> ffmpeg I should first scale up the with to 768 (or scale down the height
>>> to 540) before I do any other processing in order to work on the correct
>>> aspect ratio - right? Do I have to use any special flag to tell ffmpeg
>>> to transform the non-square pixels to square ones?
>> No, just specify -s so that in the messages related to the output video
>> you get PAR 1:1.
>>
>>> How did others deal with this issue? I assume that postprocessing TV
>>> recordings is a pretty wide spread use case for ffmpeg...
>> Depends on what you want to achieve.
>
> Just to clarify. No software in the world can know the actual form of
> physical pixels on your physical screen unless the software communicates
> with the screen device, which ffmpeg doesn't do. Therefore it cannot know
> the resolution and aspect ratio of your screen device. You have to tell it
> that. One way to do this is by using the -s switch on command line.
> Therefore if you want to produce a file for display on a screen with square
> pixels (as most computer screens are) and you want to see a circle as a
> circle, not as oval, then you could use -s 768x576 if you want that
> resolution. If the actual broadcast contains 720x576 format and it is 4:3
> aspect ratio then you should get perfectly round circles.

Since as you say ffmpeg doesnt communicate with the screen, what you do
with -s will depend on what you want to do with the converted file. The
examples you give above are pointless: there is no need to re-aspect
until you know you *have* to, that's why the default behavior for ffmpeg
is to maintain the current DAR PAR, OTOH, is allowed to change, since
that is a form of compression).

>
> Things are getting more interesting when the actual broadcast is 16:9 but
> still at 720x576, as often done today (broadcasted pixels are even more
> oblong). Should you specify -s 1024x576? Well, that depends on your TS
> processor. In the TS stream (the DVB broadcast multiplex stream) there is
> information whether the video is in 4:3 or 16:9 aspect. Clever TS
> demultiplex/decoder could rescale things so that you always specify 768x576
> when your screen has these pixel dimensions. I do not know what ffmpeg does
> in this case. Any comments, Michel?

No, because I dont see your point, see above.

--
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:[hidden email]

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: PAL & Overscan / Non Square Pixels?

Mikael Hakman
In reply to this post by Giskard
Michael Ransburg wrote:


> Hi all,
>
> when I record a transport stream from the satellite (e.g., using
> MythTV), it has a resolution of 720x576 pixel. This is not the 4:3
> format which I expected. I googled for it and read about overscan and
> non square pixels which are the reason for this. My question is what
> should I do to have this displayed correctly on a computer monitor after
> conversion? Should I, for example, crop the height to 540 pixel?
>
> Many thanks,
> Michael

Returning to your original question, here is what I do in a corresponding
situation, which may or may not be the same as yours.

I record TS in my DVB receiver. Then I transfer it to my computer. Then I
remove some extra packaging put there by my DVB receiver, using a tool that
I wrote myself. Now I have pure TS, exactly as broadcasted by the channel.
Now, I use a tool called ProjectX (open source, Java) to demultiplex
individual streams from TS and temporarily store them on files. I get one
mpeg2 video stream, one mpeg1 level 2 audio, and sometimes also ac3/dolby
digital audio (surround) if present, and also teletext stream if present.
ProjectX does not touch the contents of these elementary streams, it merely
unpacks them and stores on files. Then I use IfoEdit tool (free, not open
source) to multiplex these streams into PS (program stream = VOB), add DVD
structures (IFO, VTS etc.), and produce an ISO DVD disc image. At last I
burn the image onto a DVD record. Nowhere along the path do I force aspect
ratio or resolution change; on the contrary, I say "keep it as it is". None
of the elementary streams are ever touched - this guaranties the highest
possible quality (every time you recompress video or audio, you loose). When
I play such a DVD record in a stand-alone DVD player everything works ok.
4:3 is 4:3, 16:9 is 16:9, a circle is circular, and a square is square. When
I play such a DVD in a computer then it depends on which DVD player I use.
Some do it right, some others I have to tell what aspect ratio to use.

Sometimes I need to edit (cut) my recordings (remove commercials etc.). I do
that after ProjectX but before IfoEdit using a tool called Cuttermaran
(free, not open source, really pro) which works on a group of elementary
streams (video and audio). Cuttermaran works also without recompressing or
changing aspect or resolution. It is clever enough to cut at I or B video
mpeg and/or audio frame boundary.

The less you do the better it gets, but sometimes doing a little requires
much more work than doing a lot :-)

Thanks/Mikael

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user