asticode / go-astits

Demux and mux MPEG Transport Streams (.ts) natively in GO

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Q: aac and h264 codecs

ivanjaros opened this issue · comments

In here #9 you have said to use data.PMT.ElementaryStreams to retrieve information about tracks, essentially, and data.PES.Data to get the actual data, which I am used to from https://github.com/nareix/joy4.

But it seems you have no support for h264 video and very small for audio - I can see you have defined only few audio stream types:

// Stream types
const (
	StreamTypeLowerBitrateVideo          = 27 // ITU-T Rec. H.264 and ISO/IEC 14496-10
	StreamTypeMPEG1Audio                 = 3  // ISO/IEC 11172-3
	StreamTypeMPEG2HalvedSampleRateAudio = 4  // ISO/IEC 13818-3
	StreamTypeMPEG2PacketizedData        = 6  // ITU-T Rec. H.222 and ISO/IEC 13818-1 i.e., DVB subtitles/VBI and AC-3
)

so I wonder why not provide the packet parser as well, ie. https://github.com/nareix/joy4/tree/master/codec, since mepgts is mostly used with h264 anyway?

Also what is the difference between data.PES.Header.OptionalHeader.PTS, data.PES.Header.OptionalHeader.DTS and data.PES.Header.OptionalHeader.ESCR?

I would assume that one is the duration "timestamp" of the packet on the media timeline, the other is the duration of the packet itself and the third is the duration since the stream begun(ie. not the data stream, but the connection).

also i do not see indication if the packet is I-frame or not, so i cannot build GOP...but maybe that is encoded in the data itself?

so I wonder why not provide the packet parser as well, ie. https://github.com/nareix/joy4/tree/master/codec, since mepgts is mostly used with h264 anyway?

This library has 2 goals :

  1. provide a transport stream demuxer and (in the future) muxer
  2. all in native GO code

https://github.com/nareix/joy4 is a great project, but like my own https://github.com/asticode/go-astiencoder it relies on libav which is ffmpeg's C library. Implementing codecs in native GO code is HUGE work and it's almost impossible to do a job as amazing as ffmpeg has done (ffmpeg is widely used in production and has been thoroughly tested by big companies).

Therefore I can see this repo implementing a .ts muxer in native GO code, but I don't see it implementing codecs in native GO code. But I may be wrong and more talented people than me may be inclined to contribute.

Also what is the difference between data.PES.Header.OptionalHeader.PTS, data.PES.Header.OptionalHeader.DTS and data.PES.Header.OptionalHeader.ESCR?

  • PTS is the presentation timestamp and is the timestamp at which the frame should be shown
  • DTS is the decode timestamp and is the timestamp at which the decoder should decode the frame
  • I've never used ESCR but based on this link : "The ESCR field indicates the expected arrival time, at the PES stream associated STD, of the byte containing the lastbit of the ESCR base field"

also i do not see indication if the packet is I-frame or not, so i cannot build GOP...but maybe that is encoded in the data itself?

I-frame is an h264 specific information therefore you need to decode the packet first using the proper codec.

thanks for the info. the joy4 does not use ffmpeg/C though. it just demuxes flv and parses the h264/acc packets into separate streams/tracks. there is ffmpeg support but it not used in this part, only in transcoding if one chooses to build it with Cgo. otherwise the library is pure go.

i begun working on C->Go port of ffmpeg's stuff that I need(h264/vp8/vp9 decoder, av1 encoder, flv/mp4/ts demuxer and mp4 muxer) but it is just too much code so i won't be continuing, most likely. the code is simple, easy to translate to go(it is C afterall) but it just takes too much time to do it by hand so you are corect on that, hence i am trying to use your goav instead.

the joy4 does not use ffmpeg/C though

Damn you're right, he/she has implemented an h264 parser in native GO 🤯 Well I won't have the time to do the same here 😜

@asticode i just got recommended this project https://github.com/elliotchance/c2go it would be sweeeet if ffmpeg would be go-native :)