Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add muxer #16

Merged
merged 57 commits into from
Mar 24, 2021
Merged

Add muxer #16

merged 57 commits into from
Mar 24, 2021

Conversation

barbashov
Copy link
Contributor

@barbashov barbashov commented Mar 2, 2021

I've created a MPEG-TS muxer based on your demuxer library, as requested in #10 .

I must say here that I had no intention for muxer to support everything demuxer supports. What I'm trying to do is to solve my tasks with the library (I guess that's how open source works anyway). So it's not full-featured, but it still helps a lot.

TODOs and limitations:

  1. Most important: It doesn't really support PSI sections yet. Though it knows how to write tables, each table must fit in one TS packet. Mostly the limitation is there because I don't see the easy and clean way to do it now. And I don't really need it right now.
  2. Only PAT and PMT tables are supported. No SDT, NIT, EIT, etc. Though it won't be hard to add the support if needed.
  3. Muxer doesn't support more than one program (it's not hard to do). Number of elementary streams is not restricted.

Additionally while working on the muxer I added some little things here and there, most notably:

  1. autoDetectPacketSize now knows how to work with bufio.Reader correctly
  2. packetPool.add got an option flushOnPIDChange to overcome behaviour when one-packet tables doesn't get returned to demuxer at once.
  3. I've changed CRC32 API slightly to be able to update it incrementally.

Sorry for the big pull request, but I don't see a way to do it in smaller parts :)

@barbashov
Copy link
Contributor Author

I've removed flushOnPIDChange since it doesn't seem to be necessary - I think I overdebugged something a couple days ago.

FYI you forgot to remove the comment here

Thanks! Cleaned that up

@barbashov barbashov mentioned this pull request Mar 6, 2021
Copy link
Owner

@asticode asticode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few remarks regarding last changes.

data_psi.go Outdated Show resolved Hide resolved
data_psi.go Outdated Show resolved Hide resolved
@barbashov barbashov requested a review from asticode March 10, 2021 10:36
Copy link
Owner

@asticode asticode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In all honesty, this PR is really awesome.

crc32.go Outdated Show resolved Hide resolved
data_pes.go Show resolved Hide resolved
data_pat.go Outdated Show resolved Hide resolved
data_pes.go Outdated Show resolved Hide resolved
data_psi.go Outdated Show resolved Hide resolved
muxer.go Outdated
return nil
}

func (m *Muxer) WritePayload(pid uint16, af *PacketAdaptationField, ph *PESHeader, payload []byte) (int, error) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the public API should be func (m *Muxer) WriteData(af *PacketAdaptationField, d *Data) (int, error) instead. I don't mind implementing it for PES only for now. *Data would be sufficient to pass pid, ph and payload

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I gotta remember why I haven't done that in the first place, will try to remember in next couple of days and will get back to you :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha! I remember now why I haven't done it that way.

  • Data has FirstPacket with PID in its header. At the same time Data has PID as a separate member. While it's perfectly okay and handy for demuxer API user, that is confusing for muxer API user
  • FirstPacket has a bunch of fields which have no effect setting in WriteData case - I will rewrite CC, AF/payload indicators, etc. That could confuse API user as well.

So the main point here is: I've designed WritePayload to require arguments that really make sense here and are really used.

I get your point as well - it's not consistent with demuxer currently. And it's not especially pretty :) Though I don't really know a way to make it perfect now - seems like we're choosing between two tradeoffs (well, a position I constantly find myself in :))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also I think muxer logic is a bit different by its nature.

Demuxer usage is like "tell me everything you can parsing a TS stream".

While muxer usage is more like "okay, I got a bunch of elementary streams, now let's write payloads. And handle all the low level stuff like PAT/PMT for me, I don't want to be bothered by that".

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Love your explanation and I get your point about FirstPacket, that would indeed be confusing.

What about renaming the current Data to DemuxerData and creating :

type MuxerData struct {
  AdaptationField *PacketAdaptationField
  PES *PESData
  PID uint16
}

I think that would be a good compromise.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me think about it a little bit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well I've done it that way and I like it.

Though don't rush to resolve this thread just yet. I'd like to do some additional testing today to make sure I haven't broken anything.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tested new WriteData with my project I'm working on. All is ok, no issues.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! I'll merge the PR then

muxer.go Outdated Show resolved Hide resolved
packet.go Show resolved Hide resolved
packet.go Show resolved Hide resolved
packet_buffer.go Outdated Show resolved Hide resolved
@barbashov
Copy link
Contributor Author

@asticode can you please resolve threads I've already addressed? I'm starting to get confused as there's a lot of them :)

@asticode
Copy link
Owner

@asticode can you please resolve threads I've already addressed? I'm starting to get confused as there's a lot of them :)

Done.

Be careful as there are open threads that Github hides in the middle. You have to load them manually.

@barbashov
Copy link
Contributor Author

@asticode can you please resolve threads I've already addressed? I'm starting to get confused as there's a lot of them :)

Done.

Be careful as there are open threads that Github hides in the middle. You have to load them manually.

Thanks.

Yeap, I'd found that hidden threads yesterday. Quite controversial UX decision if you ask me :)

@asticode
Copy link
Owner

I've resolved threads that are now fixed. Only 3 open threads remaining!

@asticode asticode merged commit 5caf397 into asticode:master Mar 24, 2021
@asticode
Copy link
Owner

As I said previously, it was a very nice PR ❤️

Thanks for sticking with it.

I've created a v1.7.0 tag

Cheers

@barbashov
Copy link
Contributor Author

barbashov commented Mar 24, 2021

Whoa. Finally after two months, 4k lines of code and 57 commits it happened.

Will open a bottle of wine for that on Friday :)

Thanks for the throughout review and nice feedback!

@barbashov
Copy link
Contributor Author

Well I've opened a bottle for that on saturday. I hope you'll appreciate that one even thought it's italian ;)) It was very nice to work with you on that PR, looking forward to write some code in the future :)

IMG_0378

@asticode
Copy link
Owner

Haha hope it was a good one!

It was a pleasure too, let's connect on LinkedIn as well (I've sent you an invite).

Cheers

@tmm1
Copy link
Contributor

tmm1 commented Apr 1, 2021

Congrats! Thanks for all the great work here! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants