[FFmpeg-devel] mpegtsenc T-STD compliance

[Dominguez Bonini, David]

> The fundamental problem with making it T-STD compliant is that it will only
> be ever T-STD compliant in certain cases.

I agree that it is not possible to enforce T-STD compliance for all codecs and all cases. But I think this is perfectly OK. I think we should mostly care about encoders for the main DTV standards that use MPEG-2 systems:

- MPEG-2 Video
- H.264 Video
- VC-1 video (maybe?)
- MPEG-1 Layer 2 audio
- AC-3/EAC3 Audio
- DTS Audio
- AAC/HE-AAC audio

And maybe some others I'm not aware of...

For all other codecs we don't have standard-specified buffer models  to adhere to, so even if we tried, compliance would not be possible.

> FFmpeg has no understanding of VBV-related timestamps (along with the
> necessary offsets for all other timestamps) and some sort of API to pass
> through precise timing information per packet in a remuxer involves writing a
> ton of MPEG-TS specific features to the API. Even more so now that
> streaming uses of MPEG-TS push the false reality that you can remux *any*
> file into a legal MPEG-TS with nonsense such as TS timestamps starting from
> zero.
> 

Well, right now the muxer seems to be capable of generating a valid VBR or CBR transport stream with correct PCRs. Once you are there, enforcing T-STD compliance seems to be a matter of applying the correct offset to each PCR you generate (and add null packets as needed in CBR mode). But of course this may be overly optimistic, I'm sure you have given this much more thought than me.

Regarding invalid inputs, I guess all we can do is error out. The T-STD models are meant to ensure the encoder generates a stream any compliant decoder can handle, so I think being unforgiving with invalid inputs or use cases is the right thing to do.

> It largely depends on what you want to do with the mux - encoding
> MPEG-2 or encoding with x264 is the easiest (x264 has the right VBV output
> information). At the same time you may break Apple streaming and the likes
> which at the moment have more FFmpeg users than professional television
> encoding.


I think adding a configuration switch to enable/disable compliance will be enough to avoid problems with users who don't  need/care about T-STD.

> 
> I can provide guidance for making it T-STD compliant.

That's great. I appreciate it. By the way,  I have seen your ob-encoder project and it seems pretty good. I'm looking forward to giving it a try.