[vlc] Re: optimum bitrate for streaming Mpeg2-ts

[Derk-Jan Hartman]

This has been a long standing issue in ffmpeg. People who are trying to  
author DVDs are also affected by this problem. Basically, there is no  
such thing as MPEG-2 CBR, just a very close approximation to it. NULL  
packets and 2 pass encoding have been suggested, the latter being the  
best alternative. I'm not sure what the current status for this in  
ffmpeg is. the ffmpeg-devel list archives should have some information.

DJ


On 27 okt 2004, at 15:55, Jechiam Gural wrote:

>
> The problem with VBR files is that not all MPEG-2 servers will be able  
> to handle that format. If you whish to deploy your content on multiple  
> streaming platforms TS CBR is a more safe strategy. The question  
> remains if there are any optimal MPEG-2 transcoding settings known for  
> a a streaming bitrate of 5 Mbps (CBR) for full screen display using  
> VLC  or FFMpeg.
>
> Regards,
>
> Jechiam
>
> At 07:16 PM 10/26/2004, Jean-Paul Saman wrote:
>> Peter Maersk-Moller wrote:
>>
>>> Hi Jean-Paul
>>>
>>> Jean-Paul Saman wrote:
>>>
>>>> Jeroen Heijhoff wrote:
>>>>
>>>>> Hello,
>>>>> I'd like to know if there is a optimum bitrate for streaming  
>>>>> MPEG2-ts streams.
>>>>> I want to go streams MPEG2-ps to MPEG2-ts and I just want to know  
>>>>> if streaming
>>>>> 5Mbps streams instead of (for instance) 4Mbps really does add  
>>>>> something to quality etc.
>>>>
>>>> To make matters even more confusing:
>>>> A general bitrate of about 3.5MBps / 4MBps (like in DVB streams)  
>>>> can easily go upto 8 MBps temporarily when using VBR (Variable  
>>>> Bitrate encoding). Which is general more used then CBR (Constant  
>>>> Bitrate encoding).
>>>
>>>
>>> Hmm, how does it work on a transponder with a fixed bandwidth ?
>>>
>>> I assume that a generic satellite transponder has a fixed bandwidth
>>> of approx 45Mbps ? Since the transponder usually (not always) has
>>> mutiple TV-channels and audio channels, they can not all peak
>>> at 8-9 Mbps at the same time. Is there some reserved common
>>> pool of spare bandwidth that they can share and use if available.
>> In the rare occasion that this happens one of the streams is going to  
>> suffer. Or all are going to suffer slightly. I can imagine that if  
>> the satellite encoder/packetiser can predict it it will either delay  
>> some packets a bit or just do not encode/packetize all details for a  
>> scene. I do not know how these algorithmes work.
>>
>>> If yes, then I assume they sometimes can not use the extra bandwidth
>>> leading to a temporary corruption in a stream ?
>> That could happen indeed. It will show up as lost packets I guess.
>>
>> --
>>
>> Many greetings,
>>     Jean-Paul Saman
>>
>> ====================================================================== 
>> ====
>>           VLC iPAQ maintainer (http://www.videolan.org)
>>          RedHat Certified Engineer (RHCE: 807202745005548)
>> ====================================================================== 
>> ====
>>
>>
>
> -- 
> This is the vlc mailing-list, see http://www.videolan.org/vlc/
> To unsubscribe, please read http://www.videolan.org/support/lists.html
>
>
---
Universiteit Twente
Derk-Jan Hartman (d.hartman at student.utwente dot nl)
http://home.student.utwente.nl/d.hartman

-- 
This is the vlc mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/support/lists.html