Re: [FFmpeg-user] The Guild

[David Niklas]

On Thu, 1 Feb 2024 14:49:50 -0500
Mark Filipak  wrote:
> On 01/02/2024 14.41, Carl Zwanzig wrote:
> > On 2/1/2024 11:26 AM, Mark Filipak wrote:
> >>
> >> There needs to be an FFmpeg Guild and there needs to be an FFmpeg
> >> industry. You guys/gals need to >> make a living. How can we make
> >> that happen?
> > > Why does there need to be a "guild"?
>
> Because FFmpeg developers need to make a living.
>
> > If you want one, start one.
>
> I'm not an FFmpeg developer.
>
> >> Second, a cloud-based book that people buy. It would have to have a
> >> reader that people buy. The >> reader would read an encrypted cloud,
> >> would be read-only, would resist host >>
> >> probing/capture/screenshots, and would save _nothing_ locally.
> > > Again, why? (And of course a book would have a copyright, but that
> > > has little to do with how > distribution is licensed.) You do not
> > > seem to understand open-source projects at all.
>
> The book and the reader and the private forum would have everything to
> do with FFmpeg but nothing to do with FFmpeg legally.
>
> If FFmpeg is to continue to be free and open source, there needs to be
> a for-profit business attached to FFmpeg. I will contribute to the book
> for free. I will donate pages that I already have and will donate more.
> I'm retired. I already have a guaranteed income.
>
> --Mark.
>
>

Just in case everyone forgot, Richard Stallmen, who founded the GNU
foundation, got kicked from his own foundation not too long ago.

Likewise, the Mozilla foundation's leader was also forced to step
down. And that was just before the amount of features in the browser and
the amount of memory it consumed increased.

So although I agree that ffmpeg's, and a few other FLOSS-s', devs could
really use a financial backing, I'm hesitant to recommend it for any
FLOSS project.

Sincerely,
David
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] The Guild

[Mark Filipak]

On 01/02/2024 16.08, Reindl Harald wrote:

Am 01.02.24 um 21:58 schrieb Mark Filipak:

On 01/02/2024 15.48, Reindl Harald wrote:

Am 01.02.24 um 20:49 schrieb Mark Filipak:

On 01/02/2024 14.41, Carl Zwanzig wrote:

On 2/1/2024 11:26 AM, Mark Filipak wrote:


There needs to be an FFmpeg Guild and there needs to be an FFmpeg industry. You guys/gals need 
to make a living. How can we make that happen?


Why does there need to be a "guild"?


Because FFmpeg developers need to make a living.


If you want one, start one.


I'm not an FFmpeg developer.


so why un the world do you start a topic out of the blue nobody but you don't 
get?

it starts by opening a new thread with a random quote from god knows where


Paul replied to Subject: DTSs & PTSs in MPEG2-TS streams
but it was off-topic.

When he did that, I changed to Subject: The Guild
and replied. Carl replied to that.

Pay attention.


you are even too dumb to operate a mail-client, otherwise that won'thave ended 
in a private thread


I'm not dumb at all. I made my reply to you private because it's off-topic and would only create 
ranker on the mailing list. Now I see you've transferred this rancor back to the mailing list. Oh, well.



i do not need to pay attention when *you* start a random thread with a random 
quote


I don't recall a random quote. To what do you refer?

"Yes ffmpeg is sole problem here. Go use something better and non-free" meant "go and fuck yourself" 
from my point of understanding


Yes, that's how I took it, but I'm trying to be a gentleman. :-)

--Mark.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] DTSs & PTSs in MPEG2-TS streams

[Mark Filipak]

On 01/02/2024 16.09, Devin Heitmueller wrote:

On Thu, Feb 1, 2024 at 1:55 PM Mark Filipak  wrote:

On 01/02/2024 09.54, Devin Heitmueller wrote:

On Thu, Feb 1, 2024 at 1:15 AM Mark Filipak  wrote:


FFmpeg assigns DTSs & PTSs to P-frames and B-frames in MPEG2-TS streams. How 
does it determine those
DTSs & PTSs?

Since DTSs & PTSs don't actually exist for P-/B-frames in MPEG2-TS streams, 
FFmpeg must have a way
that's unknown to me.


P/B frames can certainly have PTS values.


Well, they _can_ as in they're not prohibited, but I can't recall ever seeing a 
P-/B-frame in
MPEG2-TS supplying a DTS or a PTS. I've parsed quite a few MPEG2-TSs.


If you want to share a sample with me privately, I can take a look and
possibly offer you a better explanation.

P/B frames generally have PTS values.  B frames *must* have both PTS
and DTS since they are different values.  If you're not seeing them
then either your sample is broken or your parser is.


There is no PES extension, so there is no place for DTS & PTS to reside. I realize that FFmpeg is 
creating DTSs & PTSs. That appears to be part of the problem.


I've seen many reports of DTS out of sequence when the original frame, a P-/B-frame, had no DTS. It 
appears that FFmpeg is reporting an issue that it created.



  In fact, you have to have
PTS values in B frames since they differ from the DTS (since with B
frames the presentation order differs from the decoding order).


I don't see DTS or PTS in the PES header. What I do see is 
'PES_extension_flag'=='0' and
'PTS_DTS_flags'=='00', so no PES ext and no dts or pts. That's why I asked my 
question.


The PES extension flag is mutually exclusive of whether the
PTS_DTS_flags field is set.  It's very common for there to
PTS_DTS_flags to be non-zero while PES_extension_flag is false.


Okay. If DTS & PTS are not in the PES extension because there is no PES extension, then where are 
they? There are only a handful of bits in an MPEG2-TS/-PS I haven't figured out. You may know more 
than I do.



Every once in awhile I'll see 'PTS_DTS_flags'=='10' but that's unusual. Mind 
you, this is in
MPEG2-TSs. I don't how to parse anything else.


That shouldn't be unusual.  It means there is a PTS but no DTS in that
PES.  In fact, specifying the PTS without the DTS is generally what
you're supposed to do if they are the same value (which is the norm
for audio streams and video streams without B frames).


There are potentially cases with some streams where the PTS and/or DTS
is not specified for every frame,


I'd say "usually", not "potentially".


in which case libavformat will
interpolate those values based on the frame duration and the prior
packet.


Of course. But why? They're not needed. Once the TS packets are put in correct 
sequence via SCR, the
PS packets transported by those TS packets are in presentation order. The 
process to reorder the PS
in order to decode B-frames and then put the decoded pictures back into the 
original order is
straight forward. It's not "tricky" at all.


Um, I'm not sure what to say here.  The DTS is what defines the order
that the packets are announced to the decoder.  The PTS defines the
order in which they are presented.  The SCR will constantly increment.
I think perhaps you have a fundamental misunderstanding of how PTS/DTS
works.


Yes, the SCR (in the TS) will constantly increment. It's when the _receiver_ of the TS sees SCRs 
that are out of order that it knows when packets are being received out of order and how to put them 
into proper order. That's why TSs are called "fault tolerant".


FFmpeg seems to think that DTS has that function for every frame but where is the DTS if there's no 
PES_ext? I think that DTS & PTS applies to GOPs, not individual frames. I think that FFmpeg is 
misusing DTS.


But I confess that I don't know why an occasional P-frame has a PES_ext with a PTS while P-/B-frames 
generally don't have PES_ext or DTSs or PTSs.



It has become "tricky". That's what I'm trying to investigate, but I can't read 
'C' code.


I'm seeing some strange things. They can't be as strange as they look because 
they look disastrous.
At issue is the cause of non-monotonous DTSs and obviously bogus DTSs for 
P-frames such as
'-9223372036854775808'.


9223372036854775808 is a magic number.  It corresponds to the #define
for AV_NOPTS_VALUE.  If you see that value it means that the packet
did not have a PTS or DTS value assigned to it and thus you may have
to take special measures.


Oh, dear. I guessed that.

Magic number. Fixup. There's a million fixups. I don't see why they're needed. 
That's why my
preliminary finding is that FFmpeg is creating its own faults through fixups.


This is essentially how all demuxers/parsers work.  The PES packet in
the stream doesn't contain a PTS or DTS, the API tells you that, and
thus the application has to use a heuristic to assign a value.


Okay. So the decoder _is_ expecting a 'DTS' & 'PTS' with every frame -- I've put them in quotes 

Re: [FFmpeg-user] DTSs & PTSs in MPEG2-TS streams

[Paul B Mahol]

On Thu, Feb 1, 2024 at 10:09 PM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:

> On Thu, Feb 1, 2024 at 1:55 PM Mark Filipak 
> wrote:
> >
> > Hey Devin,
> >
> > On 01/02/2024 09.54, Devin Heitmueller wrote:
> > > Hi Mark,
> > >
> > > On Thu, Feb 1, 2024 at 1:15 AM Mark Filipak <
> markfilipak.i...@gmail.com> wrote:
> > >>
> > >> FFmpeg assigns DTSs & PTSs to P-frames and B-frames in MPEG2-TS
> streams. How does it determine those
> > >> DTSs & PTSs?
> > >>
> > >> Since DTSs & PTSs don't actually exist for P-/B-frames in MPEG2-TS
> streams, FFmpeg must have a way
> > >> that's unknown to me.
> > >
> > > P/B frames can certainly have PTS values.
> >
> > Well, they _can_ as in they're not prohibited, but I can't recall ever
> seeing a P-/B-frame in
> > MPEG2-TS supplying a DTS or a PTS. I've parsed quite a few MPEG2-TSs.
>
> If you want to share a sample with me privately, I can take a look and
> possibly offer you a better explanation.
>
> P/B frames generally have PTS values.  B frames *must* have both PTS
> and DTS since they are different values.  If you're not seeing them
> then either your sample is broken or your parser is.
>
> > >  In fact, you have to have
> > > PTS values in B frames since they differ from the DTS (since with B
> > > frames the presentation order differs from the decoding order).
> >
> > I don't see DTS or PTS in the PES header. What I do see is
> 'PES_extension_flag'=='0' and
> > 'PTS_DTS_flags'=='00', so no PES ext and no dts or pts. That's why I
> asked my question.
>
> The PES extension flag is mutually exclusive of whether the
> PTS_DTS_flags field is set.  It's very common for there to
> PTS_DTS_flags to be non-zero while PES_extension_flag is false.
>
> > Every once in awhile I'll see 'PTS_DTS_flags'=='10' but that's unusual.
> Mind you, this is in
> > MPEG2-TSs. I don't how to parse anything else.
>
> That shouldn't be unusual.  It means there is a PTS but no DTS in that
> PES.  In fact, specifying the PTS without the DTS is generally what
> you're supposed to do if they are the same value (which is the norm
> for audio streams and video streams without B frames).
>
> > > There are potentially cases with some streams where the PTS and/or DTS
> > > is not specified for every frame,
> >
> > I'd say "usually", not "potentially".
> >
> > > in which case libavformat will
> > > interpolate those values based on the frame duration and the prior
> > > packet.
> >
> > Of course. But why? They're not needed. Once the TS packets are put in
> correct sequence via SCR, the
> > PS packets transported by those TS packets are in presentation order.
> The process to reorder the PS
> > in order to decode B-frames and then put the decoded pictures back into
> the original order is
> > straight forward. It's not "tricky" at all.
>
> Um, I'm not sure what to say here.  The DTS is what defines the order
> that the packets are announced to the decoder.  The PTS defines the
> order in which they are presented.  The SCR will constantly increment.
> I think perhaps you have a fundamental misunderstanding of how PTS/DTS
> works.
>
> > It has become "tricky". That's what I'm trying to investigate, but I
> can't read 'C' code.
> >
> > >> I'm seeing some strange things. They can't be as strange as they look
> because they look disastrous.
> > >> At issue is the cause of non-monotonous DTSs and obviously bogus DTSs
> for P-frames such as
> > >> '-9223372036854775808'.
> > >
> > > 9223372036854775808 is a magic number.  It corresponds to the #define
> > > for AV_NOPTS_VALUE.  If you see that value it means that the packet
> > > did not have a PTS or DTS value assigned to it and thus you may have
> > > to take special measures.
> >
> > Oh, dear. I guessed that.
> >
> > Magic number. Fixup. There's a million fixups. I don't see why they're
> needed. That's why my
> > preliminary finding is that FFmpeg is creating its own faults through
> fixups.
>
> This is essentially how all demuxers/parsers work.  The PES packet in
> the stream doesn't contain a PTS or DTS, the API tells you that, and
> thus the application has to use a heuristic to assign a value.  Some
> implementations may do the interpolation for you, but libavformat
> basically tells you there is no PTS and leaves it to the application
> to decide what to do.
>

libavformat implementation is very low level.


>
> Devin
>
> --
> Devin Heitmueller, Senior Software Engineer
> LTN Global Communications
> o: +1 (301) 363-1001
> w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email

Re: [FFmpeg-user] DTSs & PTSs in MPEG2-TS streams

[Devin Heitmueller]

On Thu, Feb 1, 2024 at 1:55 PM Mark Filipak  wrote:
>
> Hey Devin,
>
> On 01/02/2024 09.54, Devin Heitmueller wrote:
> > Hi Mark,
> >
> > On Thu, Feb 1, 2024 at 1:15 AM Mark Filipak  
> > wrote:
> >>
> >> FFmpeg assigns DTSs & PTSs to P-frames and B-frames in MPEG2-TS streams. 
> >> How does it determine those
> >> DTSs & PTSs?
> >>
> >> Since DTSs & PTSs don't actually exist for P-/B-frames in MPEG2-TS 
> >> streams, FFmpeg must have a way
> >> that's unknown to me.
> >
> > P/B frames can certainly have PTS values.
>
> Well, they _can_ as in they're not prohibited, but I can't recall ever seeing 
> a P-/B-frame in
> MPEG2-TS supplying a DTS or a PTS. I've parsed quite a few MPEG2-TSs.

If you want to share a sample with me privately, I can take a look and
possibly offer you a better explanation.

P/B frames generally have PTS values.  B frames *must* have both PTS
and DTS since they are different values.  If you're not seeing them
then either your sample is broken or your parser is.

> >  In fact, you have to have
> > PTS values in B frames since they differ from the DTS (since with B
> > frames the presentation order differs from the decoding order).
>
> I don't see DTS or PTS in the PES header. What I do see is 
> 'PES_extension_flag'=='0' and
> 'PTS_DTS_flags'=='00', so no PES ext and no dts or pts. That's why I asked my 
> question.

The PES extension flag is mutually exclusive of whether the
PTS_DTS_flags field is set.  It's very common for there to
PTS_DTS_flags to be non-zero while PES_extension_flag is false.

> Every once in awhile I'll see 'PTS_DTS_flags'=='10' but that's unusual. Mind 
> you, this is in
> MPEG2-TSs. I don't how to parse anything else.

That shouldn't be unusual.  It means there is a PTS but no DTS in that
PES.  In fact, specifying the PTS without the DTS is generally what
you're supposed to do if they are the same value (which is the norm
for audio streams and video streams without B frames).

> > There are potentially cases with some streams where the PTS and/or DTS
> > is not specified for every frame,
>
> I'd say "usually", not "potentially".
>
> > in which case libavformat will
> > interpolate those values based on the frame duration and the prior
> > packet.
>
> Of course. But why? They're not needed. Once the TS packets are put in 
> correct sequence via SCR, the
> PS packets transported by those TS packets are in presentation order. The 
> process to reorder the PS
> in order to decode B-frames and then put the decoded pictures back into the 
> original order is
> straight forward. It's not "tricky" at all.

Um, I'm not sure what to say here.  The DTS is what defines the order
that the packets are announced to the decoder.  The PTS defines the
order in which they are presented.  The SCR will constantly increment.
I think perhaps you have a fundamental misunderstanding of how PTS/DTS
works.

> It has become "tricky". That's what I'm trying to investigate, but I can't 
> read 'C' code.
>
> >> I'm seeing some strange things. They can't be as strange as they look 
> >> because they look disastrous.
> >> At issue is the cause of non-monotonous DTSs and obviously bogus DTSs for 
> >> P-frames such as
> >> '-9223372036854775808'.
> >
> > 9223372036854775808 is a magic number.  It corresponds to the #define
> > for AV_NOPTS_VALUE.  If you see that value it means that the packet
> > did not have a PTS or DTS value assigned to it and thus you may have
> > to take special measures.
>
> Oh, dear. I guessed that.
>
> Magic number. Fixup. There's a million fixups. I don't see why they're 
> needed. That's why my
> preliminary finding is that FFmpeg is creating its own faults through fixups.

This is essentially how all demuxers/parsers work.  The PES packet in
the stream doesn't contain a PTS or DTS, the API tells you that, and
thus the application has to use a heuristic to assign a value.  Some
implementations may do the interpolation for you, but libavformat
basically tells you there is no PTS and leaves it to the application
to decide what to do.

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] The Guild

[Reindl Harald]

Am 01.02.24 um 21:58 schrieb Mark Filipak:

On 01/02/2024 15.48, Reindl Harald wrote:



Am 01.02.24 um 20:49 schrieb Mark Filipak:

On 01/02/2024 14.41, Carl Zwanzig wrote:

On 2/1/2024 11:26 AM, Mark Filipak wrote:


There needs to be an FFmpeg Guild and there needs to be an FFmpeg 
industry. You guys/gals need to make a living. How can we make that 
happen?


Why does there need to be a "guild"?


Because FFmpeg developers need to make a living.


If you want one, start one.


I'm not an FFmpeg developer.


so why un the world do you start a topic out of the blue nobody but 
you don't get?


it starts by opening a new thread with a random quote from god knows 
where


Paul replied to Subject: DTSs & PTSs in MPEG2-TS streams
but it was off-topic.

When he did that, I changed to Subject: The Guild
and replied. Carl replied to that.

Pay attention.


you are even too dumb to operate a mail-client, otherwise that won'thave 
ended in a private thread


i do not need to pay attention when *you* start a random thread with a 
random quote


"Yes ffmpeg is sole problem here. Go use something better and non-free" 
meant "go and fuck yourself" from my point of understanding

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] The Guild

[Reindl Harald]

Am 01.02.24 um 20:49 schrieb Mark Filipak:

On 01/02/2024 14.41, Carl Zwanzig wrote:

On 2/1/2024 11:26 AM, Mark Filipak wrote:


There needs to be an FFmpeg Guild and there needs to be an FFmpeg 
industry. You guys/gals need to make a living. How can we make that 
happen?


Why does there need to be a "guild"?


Because FFmpeg developers need to make a living.


If you want one, start one.


I'm not an FFmpeg developer.


so why un the world do you start a topic out of the blue nobody but you 
don't get?


it starts by opening a new thread with a random quote from god knows where

take your pills

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] The Guild

[Mark Filipak]

On 01/02/2024 14.41, Carl Zwanzig wrote:

On 2/1/2024 11:26 AM, Mark Filipak wrote:


There needs to be an FFmpeg Guild and there needs to be an FFmpeg industry. You guys/gals need to 
make a living. How can we make that happen?


Why does there need to be a "guild"?


Because FFmpeg developers need to make a living.


If you want one, start one.


I'm not an FFmpeg developer.

Second, a cloud-based book that people buy. It would have to have a reader that people buy. The 
reader would read an encrypted cloud, would be read-only, would resist host 
probing/capture/screenshots, and would save _nothing_ locally.


Again, why? (And of course a book would have a copyright, but that has little to do with how 
distribution is licensed.)


You do not seem to understand open-source projects at all.


The book and the reader and the private forum would have everything to do with FFmpeg but nothing to 
do with FFmpeg legally.


If FFmpeg is to continue to be free and open source, there needs to be a for-profit business 
attached to FFmpeg. I will contribute to the book for free. I will donate pages that I already have 
and will donate more. I'm retired. I already have a guaranteed income.


--Mark.


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] The Guild

[Carl Zwanzig]

On 2/1/2024 11:26 AM, Mark Filipak wrote:


There needs to be an FFmpeg Guild and there needs to be an FFmpeg industry. 
You guys/gals need to make a living. How can we make that happen?


Why does there need to be a "guild"? If you want one, start one.

Second, a cloud-based book that people buy. It would have to have a reader 
that people buy. The reader would read an encrypted cloud, would be 
read-only, would resist host probing/capture/screenshots, and would save 
_nothing_ locally.


Again, why? (And of course a book would have a copyright, but that has 
little to do with how distribution is licensed.)


You do not seem to understand open-source projects at all.

z!
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] The Guild

[Mark Filipak]

The reader and the book would be copyrighted.

--Mark.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] The Guild

[Mark Filipak]

On 01/02/2024 14.15, Bouke / edit 'B wrote:

  I'd pay $25/month to belong.


I pay 25 bucks for each troll head.

(Or 50 per ball, makes for more fun)

Bouke


Stop playing the Vladimir Putin role. This isn't a movie.

There needs to be an FFmpeg Guild and there needs to be an FFmpeg industry. You guys/gals need to 
make a living. How can we make that happen?


Second, a cloud-based book that people buy. It would have to have a reader that people buy. The 
reader would read an encrypted cloud, would be read-only, would resist host 
probing/capture/screenshots, and would save _nothing_ locally.


--Mark.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] The Guild

[Bouke / edit 'B]

>  I'd pay $25/month to belong.

I pay 25 bucks for each troll head.

(Or 50 per ball, makes for more fun)

Bouke 

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] The Guild

[Mark Filipak]

On 01/02/2024 13.58, Paul B Mahol wrote:


Yes ffmpeg is sole problem here.

Go use something better and non-free.


What's better?

Paul, you're trapped, aren't you? You need to make a living but you can't make a living working on 
FFmpeg.


Shall we discuss how the FFmpeg Guild members can make a living?

First, how about a members-only, private support forum? I'd pay $25/month to 
belong.

--Mark.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] DTSs & PTSs in MPEG2-TS streams

[Paul B Mahol]

On Thu, Feb 1, 2024 at 7:15 AM Mark Filipak 
wrote:

> FFmpeg assigns DTSs & PTSs to P-frames and B-frames in MPEG2-TS streams.
> How does it determine those
> DTSs & PTSs?
>
> Since DTSs & PTSs don't actually exist for P-/B-frames in MPEG2-TS
> streams, FFmpeg must have a way
> that's unknown to me.
>
> I'm seeing some strange things. They can't be as strange as they look
> because they look disastrous.
> At issue is the cause of non-monotonous DTSs and obviously bogus DTSs for
> P-frames such as
> '-9223372036854775808'.
>
> I'm not trying to mysterious. I'm trying to tread carefully because I've
> been accused of being a
> troll. How anyone could think I'm a troll when I've been here for years
> and I've always used my real
> name, everywhere on the Internet, is beyond me. And, no, I'm not writing a
> book. And I'm
> markfilipak.imdb because that's a leftover gmail account that still works
> but is otherwise useless
> to me since imdb closed its forum several years ago. So, please, no flames.
>
> I have been investigating trimming and concatenation problems full time
> for many weeks and will
> present a report here when I'm done. My preliminary finding is that FFmpeg
> is creating its own
> problems due to internal fixups, but that's just preliminary and I really
> hope I'm wrong. I can't
> look at the source code because, though 'C' syntax is no problem for me,
> actual 'C' code is a black
> hole.
>

Yes ffmpeg is sole problem here.

Go use something better and non-free.


>
> Regards,
> Mark.
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] where ffmpeg parses mpeg audio headers?

[Paul B Mahol]

On Thu, Feb 1, 2024 at 5:45 PM Andrew Randrianasulu 
wrote:

> I was looking into https://trac.ffmpeg.org/ticket/1258#comment:12
> (mpeg2 
> multichannel audio in HDV) and reading documents linked  in
> this ticket.
>
> I still have very vague understanding  on where ffmpeg audio (PES?)
> headers read by ffmpeg
>
> somewhere in ffmpeg/libavformat/mpeg.c ?
>
> According to this picture https://ericdevos.be/kask/2BA/2BA
> videoformaten/MPEG-2 description.htm
>
> Figure 2 -- Structure of an MPEG-2 Audio block of data
>
> multichannel extension can be carried (partially!) in IEC 11172-3
> layer II frame. You just need to search in very beginning of ancillary
> data for Multichannel header.
>
> Extension stream,  touched in more details in  "An Implementation of the
> MPEG—2 Audio Decoding Specification by Chad Mikkelson" (p. 38) sounds a
> bit more mysterious to me: mc-capable encoder from dist10 [1] output
> extension stream as separate file only their decoder can read. I
> wonder how it must be interleaved in real system mpeg stream? And how
> it may work in transport stream (as used in HDV) ?
>
> [1] -  https://github.com/Randrianasulu/iso-dist10 (hopefully read
> sox-generated uncompressed multichannel 16 bit AIFF correctly).
>


I wish to reply, but I'm neither FFmpeg developer any more and also
consultation costs money and time.


> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] DTSs & PTSs in MPEG2-TS streams

[Mark Filipak]

Hey Devin,

On 01/02/2024 09.54, Devin Heitmueller wrote:

Hi Mark,

On Thu, Feb 1, 2024 at 1:15 AM Mark Filipak  wrote:


FFmpeg assigns DTSs & PTSs to P-frames and B-frames in MPEG2-TS streams. How 
does it determine those
DTSs & PTSs?

Since DTSs & PTSs don't actually exist for P-/B-frames in MPEG2-TS streams, 
FFmpeg must have a way
that's unknown to me.


P/B frames can certainly have PTS values.


Well, they _can_ as in they're not prohibited, but I can't recall ever seeing a P-/B-frame in 
MPEG2-TS supplying a DTS or a PTS. I've parsed quite a few MPEG2-TSs.



 In fact, you have to have
PTS values in B frames since they differ from the DTS (since with B
frames the presentation order differs from the decoding order).


I don't see DTS or PTS in the PES header. What I do see is 'PES_extension_flag'=='0' and 
'PTS_DTS_flags'=='00', so no PES ext and no dts or pts. That's why I asked my question.


Every once in awhile I'll see 'PTS_DTS_flags'=='10' but that's unusual. Mind you, this is in 
MPEG2-TSs. I don't how to parse anything else.



There are potentially cases with some streams where the PTS and/or DTS
is not specified for every frame,


I'd say "usually", not "potentially".


in which case libavformat will
interpolate those values based on the frame duration and the prior
packet.


Of course. But why? They're not needed. Once the TS packets are put in correct sequence via SCR, the 
PS packets transported by those TS packets are in presentation order. The process to reorder the PS 
in order to decode B-frames and then put the decoded pictures back into the original order is 
straight forward. It's not "tricky" at all.


It has become "tricky". That's what I'm trying to investigate, but I can't read 
'C' code.


I'm seeing some strange things. They can't be as strange as they look because 
they look disastrous.
At issue is the cause of non-monotonous DTSs and obviously bogus DTSs for 
P-frames such as
'-9223372036854775808'.


9223372036854775808 is a magic number.  It corresponds to the #define
for AV_NOPTS_VALUE.  If you see that value it means that the packet
did not have a PTS or DTS value assigned to it and thus you may have
to take special measures.


Oh, dear. I guessed that.

Magic number. Fixup. There's a million fixups. I don't see why they're needed. That's why my 
preliminary finding is that FFmpeg is creating its own faults through fixups.


--Mark.


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] where ffmpeg parses mpeg audio headers?

[Andrew Randrianasulu]

I was looking into https://trac.ffmpeg.org/ticket/1258#comment:12
(mpeg2 multichannel audio in HDV) and reading documents linked  in
this ticket.

I still have very vague understanding  on where ffmpeg audio (PES?)
headers read by ffmpeg

somewhere in ffmpeg/libavformat/mpeg.c ?

According to this picture https://ericdevos.be/kask/2BA/2BA
videoformaten/MPEG-2 description.htm

Figure 2 -- Structure of an MPEG-2 Audio block of data

multichannel extension can be carried (partially!) in IEC 11172-3
layer II frame. You just need to search in very beginning of ancillary
data for Multichannel header.

Extension stream,  touched in more details in  "An Implementation of the
MPEG—2 Audio Decoding Specification by Chad Mikkelson" (p. 38) sounds a
bit more mysterious to me: mc-capable encoder from dist10 [1] output
extension stream as separate file only their decoder can read. I
wonder how it must be interleaved in real system mpeg stream? And how
it may work in transport stream (as used in HDV) ?

[1] -  https://github.com/Randrianasulu/iso-dist10 (hopefully read
sox-generated uncompressed multichannel 16 bit AIFF correctly).
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] DTSs & PTSs in MPEG2-TS streams

[Devin Heitmueller]

Hi Mark,

On Thu, Feb 1, 2024 at 1:15 AM Mark Filipak  wrote:
>
> FFmpeg assigns DTSs & PTSs to P-frames and B-frames in MPEG2-TS streams. How 
> does it determine those
> DTSs & PTSs?
>
> Since DTSs & PTSs don't actually exist for P-/B-frames in MPEG2-TS streams, 
> FFmpeg must have a way
> that's unknown to me.

P/B frames can certainly have PTS values.  In fact, you have to have
PTS values in B frames since they differ from the DTS (since with B
frames the presentation order differs from the decoding order).

There are potentially cases with some streams where the PTS and/or DTS
is not specified for every frame, in which case libavformat will
interpolate those values based on the frame duration and the prior
packet.  This is more common for audio, where you might have multiple
audio AU payloads within a single PES packet.

> I'm seeing some strange things. They can't be as strange as they look because 
> they look disastrous.
> At issue is the cause of non-monotonous DTSs and obviously bogus DTSs for 
> P-frames such as
> '-9223372036854775808'.

9223372036854775808 is a magic number.  It corresponds to the #define
for AV_NOPTS_VALUE.  If you see that value it means that the packet
did not have a PTS or DTS value assigned to it and thus you may have
to take special measures.

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] No frame progress on video stream copy

[Steinar Apalnes]

Hi,

There seem to be a change from 6.0 to 6.1 that cause frame, fps and q to
*not* to be outputted to progress when copying video stream.

Simple minimum way to recreate:

*Using 6.0.1 build from master November 30. 2023:*
*  ffmpeg  -f lavfi -i smptebars -c copy -t 0 -f null -*
  *frame=0 fps=0.0 q=-1.0 Lsize=N/A time=-577014:32:22.77 bitrate=N/A
speed=N/A/s speed=N/A*

*Using 6.1.1 builds from master December 31. 2023 and January 28. 2024.:*
*  ffmpeg  -f lavfi -i smptebars -c copy -t 0 -f null -*
  *size=N/A time=N/A bitrate=N/A speed=N/A*


Is this behavior intentional or caused by a bug? Or is there some new
options I need to turn on in order to get back the missing data?

-steinar
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".