[Ffmpeg-devel] Re: mpeg transport streams

[Eric L. Hernes]

M?ns Rullg?rd wrote:

>>>are not uncommon at moderate bitrates.
>>>      
>>>
>>That is easy to fix.
>>    
>>
>
>Yes, just split it in multiple PES packets.
>
>  
>
I was thinking more like 'if (pkt_size > 64k) pkt_size = 0;' and going 
with the option that
a video PES in a transport stream can be unbounded.

>My target is ISO-13181-1.
>
>  
>
The current version isn't very close to that.

>  
>
>>The method that I'm using works much better than what's in CVS now.
>>    
>>
>
>It is an improvement, but it is not correct.  I tried that approach,
>and found that it produced streams that were playable by most
>decoders, but a few complained.  A closer inspection revealed
>timestamps wildly out of spec.
>
>  
>
Isn't something that is playable by most decoders (but still not 
perfect), better than something that
completely ignores the PCR issue?

>>So what is the correct way to calculate a PCR?
>>    
>>
>
>You need to count the bits output (including padding, PSI, etc.)
>against the mux rate, and insert a PCR whenever the time is up.
>
>  
>
>>Have packet counters for the audio/video streams and calculate when
>>the next packet needs to arrive?  We still need a clock from
>>somewhere.  If a target mux-rate is specified we can use calculate a
>>PCR from the mux_rate and packet count. If the mux_rate isn't
>>specified we could use (video_bitrate + audio_bitrate +
>>some_mux_overhead), but then it is no longer VBR.  In a VBR stream,
>>the only clock available is the PTS (or frame_number/frame_rate), so
>>we have to somehow derive the PCR from that.
>>    
>>
>
>The audio and video streams shall be assumed to be VBV compliant at
>some known rate.  Use the sum of all the elementary stream rates plus
>some overhead as the total mux rate.  Then push out the elementary
>streams at their respective rates, keeping an eye on the PTS/DTS not
>to let them drift.  If there is no elementary stream packet due for
>delivery when the mux rate calls for a TS packet, insert null packets
>as needed.
>  
>

You are apparently talking about realtime encoding to a network?  Won't 
that require some kind
of async processing (either a thread or a callback) to send the PCRs and 
nulls if no ES packets
are available.

I'm off-line transcoding to a file that will later be sent to a 
network.  So I am counting packets between
PTSs (although these should probably be DTSs), to determine how much to 
null-stuff before the next PES.
 In the case of an un-specified mux_rate, I was doing the same thing, 
just not null-stuffing.  This
would give a transport stream that is ok, except for the absence of 
null-packets.  Then the MPTS
(multi-program) muxer can null stuff or stuff w/ other streams as as 
necessary on the way out.

So one option would be to modify retransmit_si_info() to look at the PCR 
streams and send PCRs
based on bit counts and bit rates.  Since this function has no ES data 
available, these packets would
be just an adaptation field w/ PCR and no payload.  If we send PCRs from 
here, I can't see readily
how to null stuff.  I think we need both a PCR and a DTS to know how 
much to stuff, right?

-Eric