Re: [FFmpeg-user] framecrc

2023-11-13 Thread Nicolas George
Mark Filipak (12023-11-13):
> If input PTSs & DTSs shouldn't be changed, then what use is
>  '-bsf:v setts=pts=:dts='?

They are for people who know what they are doing.

-- 
  Nicolas George
___
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] framecrc

2023-11-13 Thread Paul B Mahol
On Mon, Nov 13, 2023 at 12:30 PM Mark Filipak 
wrote:

> On 11/13/23 06:32, Paul B Mahol wrote:
> > On Mon, Nov 13, 2023 at 11:33 AM Mark Filipak <
> markfilipak.i...@gmail.com>
> > wrote:
> >> Then, of what use is '-bsf:v setts=pts=:dts='? Why do they
> exist?
> >
> > You can use expression and that allows numerous possibilities.
>
> Please, stop with the weasel words.
> If input PTSs & DTSs shouldn't be changed, then what use is
>   '-bsf:v setts=pts=:dts='?
>

Where I said that PTS and/or DTS shouldn't be changed?
Only wrote that in your specific usecase you can add constant offset
instead of packet sequential number.


> ___
> 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] framecrc

2023-11-13 Thread Mark Filipak

On 11/13/23 06:32, Paul B Mahol wrote:

On Mon, Nov 13, 2023 at 11:33 AM Mark Filipak 
wrote:

Then, of what use is '-bsf:v setts=pts=:dts='? Why do they exist?


You can use expression and that allows numerous possibilities.


Please, stop with the weasel words.
If input PTSs & DTSs shouldn't be changed, then what use is
 '-bsf:v setts=pts=:dts='?

___
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] framecrc

2023-11-13 Thread Paul B Mahol
On Mon, Nov 13, 2023 at 11:33 AM Mark Filipak 
wrote:

> On 11/13/23 04:04, Paul B Mahol wrote:
> > On Mon, Nov 13, 2023 at 4:33 AM  >> Why are the target PTSs out of order?
> >> Why are there no 0 or 1001 DTSs?
> >
> > DTS is different from PTS.
>
> Indeed: Decoder versus Presentation.
> '-bsf:v setts' is before decoding, so there's both PTS & DTS, right?
> '-vf setpts' is after decoding, so there's no '-vf setdts', right? And
> '-vf setpts' applies to the
> pictures going to the encoder, right?
> Is PTS > DTS? Or is PTS <= DTS? I've seen it both ways in professional
> DVDs.
> What do you say, Paul?
>
> > And you should probably reorder DTS by keeping original order - just do
> > offset and not by using packet number.
>
> Then, of what use is '-bsf:v setts=pts=:dts='? Why do they exist?
>
>
You can use expression and that allows numerous possibilities.


> I designed video hardware/chips at Atari in the early 1980s, so I know
> every detail of PAL & NTSC
> and I designed state machine sequencers to generate the signals -- pretty
> easy, actually. The
> engineers before me screwed the signals up and got Atari a bad name for a
> while.
>
> Maybe I don't understand how 'bit stream filter' got its name. Everything
> is a bit stream, so I
> don't really know to what 'stream' 'bsf' refers to. I've assumed that
> 'bsf' refers to the packet
> stream prior to decoding. Is that right, Paul?
>
> ___
> 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] framecrc

2023-11-13 Thread Paul B Mahol
On Mon, Nov 13, 2023 at 11:33 AM Mark Filipak 
wrote:

> On 11/13/23 04:04, Paul B Mahol wrote:
> > On Mon, Nov 13, 2023 at 4:33 AM  >> Why are the target PTSs out of order?
> >> Why are there no 0 or 1001 DTSs?
> >
> > DTS is different from PTS.
>
> Indeed: Decoder versus Presentation.
> '-bsf:v setts' is before decoding, so there's both PTS & DTS, right?
> '-vf setpts' is after decoding, so there's no '-vf setdts', right? And
> '-vf setpts' applies to the
> pictures going to the encoder, right?
> Is PTS > DTS? Or is PTS <= DTS? I've seen it both ways in professional
> DVDs.
> What do you say, Paul?
>
> > And you should probably reorder DTS by keeping original order - just do
> > offset and not by using packet number.
>
> Then, of what use is '-bsf:v setts=pts=:dts='? Why do they exist?
>
> I designed video hardware/chips at Atari in the early 1980s, so I know
> every detail of PAL & NTSC
> and I designed state machine sequencers to generate the signals -- pretty
> easy, actually. The
> engineers before me screwed the signals up and got Atari a bad name for a
> while.
>

And I'm really Elon Musk and I designed what you can only dream on.


>
> Maybe I don't understand how 'bit stream filter' got its name. Everything
> is a bit stream, so I
> don't really know to what 'stream' 'bsf' refers to. I've assumed that
> 'bsf' refers to the packet
> stream prior to decoding. Is that right, Paul?
>
> ___
> 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] framecrc

2023-11-13 Thread Mark Filipak

On 11/13/23 04:04, Paul B Mahol wrote:

On Mon, Nov 13, 2023 at 4:33 AM 
Why are the target PTSs out of order?
Why are there no 0 or 1001 DTSs?


DTS is different from PTS.


Indeed: Decoder versus Presentation.
'-bsf:v setts' is before decoding, so there's both PTS & DTS, right?
'-vf setpts' is after decoding, so there's no '-vf setdts', right? And '-vf setpts' applies to the 
pictures going to the encoder, right?

Is PTS > DTS? Or is PTS <= DTS? I've seen it both ways in professional DVDs.
What do you say, Paul?


And you should probably reorder DTS by keeping original order - just do
offset and not by using packet number.


Then, of what use is '-bsf:v setts=pts=:dts='? Why do they exist?

I designed video hardware/chips at Atari in the early 1980s, so I know every detail of PAL & NTSC 
and I designed state machine sequencers to generate the signals -- pretty easy, actually. The 
engineers before me screwed the signals up and got Atari a bad name for a while.


Maybe I don't understand how 'bit stream filter' got its name. Everything is a bit stream, so I 
don't really know to what 'stream' 'bsf' refers to. I've assumed that 'bsf' refers to the packet 
stream prior to decoding. Is that right, Paul?


___
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] framecrc

2023-11-13 Thread Paul B Mahol
On Mon, Nov 13, 2023 at 4:33 AM Mark Filipak 
wrote:

> On 11/12/23 04:57, Paul B Mahol wrote:
> > On Sun, Nov 12, 2023 at 8:36 AM Mark Filipak  >
> > wrote:
> >
> >> Previous Subject: "rewrite tags in a source's PES headers -- How?"
> >>
> >> On 11/11/23 13:41, Paul B Mahol wrote:
> >>> On Sat, Nov 11, 2023 at 7:29 PM Mark Filipak <
> markfilipak.i...@gmail.com
> >>>
> >>> wrote:
> >>>
>  Here's what I'm doing:
>  -bsf:v setts=time_base=1/24000:pts=N*1001:dts=N*1001
> 
>  Here's the result:
>  frame  ptsdts
>    00   2002 <= should be 0
>    1 3003 <= should be  10013003 <= should be  1001
>    2 4004 <= should be  20024004 <= should be  2002
>    3 2002 <= should be  30035005 <= should be  3003
>    4 5005 <= should be  40046006 <= should be  4004
>    5 1001 <= should be  50057007 <= should be  5005
>    6 8008 <= should be  60068008 <= should be  6006
>    7 9009 <= should be  70079009 <= should be  7007
>    8 7007 <= should be  8008   10010 <= should be  8008
>    910010 <= should be  9009   11011 <= should be  9009
>  10 6006 <= should be 10010   12012 <= should be 10010
>  1113013 <= should be 11011   13013 <= should be 11011
>  1212012 <= should be 12012   14014 <= should be 12012
>  1314014 <= should be 13013   15015 <= should be 13013
>  1411011 <= should be 14014   16016 <= should be 14014
>  1517017 <= should be 15015   17017 <= should be 15015
>  1618018 <= should be 16016   18018 <= should be 16016
>
> Why are the target PTSs out of order?
> Why are there no 0 or 1001 DTSs?
>
>  The source video is 'NTSC'-soft.
>  Can this be explained?
>  Can it be countered?
> 
>  PTSs in frames 1..5 are +2 +2 -1 +1 -4
>  PTSs in frames 6..10 are +2 +2 -1 +1 -4
>  PTSs in frames 11..15 are +2 +0 +1 -3 +2
>  I'm baffled.
> 
> >>>
> >>> N is packet number, and it goes in different order.
> >>
> >> Oh, yes, out of order/out of sequence.
> >>
> >>> Can be confirmed with:
> >>>
> >>> ffmpeg -i  -c copy -f framecrc -
> >>
> >> Thank you, Paul. Good of you. How do I interpret the framecrc table?
> >>
> >> stream_index  packet_duration
> >> |  packet_dts | packet_size
> >> |  |  packet_pts  | |  0xCRC
> >> |  |  |_  |___  |  |_
> >> 1  0   0  2880768  0xb16c8010
> >> 1   28802880  2880768  0x1b728309
> >> 1   57605760  2880768  0x966977f8
> >> 1   86408640  2880768  0x6e078511
> >> 0  10878   22890  3003  62500  0x5877c6d3
> >> 1  11520   11520  2880768  0xe49b880c
> >> [framecrc@ 02a9b140] Timestamps are unset ... stream 0 ...
> >> 1  14400   14400  2880768  0x0a217046
> >> 0  15382   15382  3003  18300  0xd4f063a2  F=0x0
> >> 1  17280   17280  2880768  0xc13a7e27
> >> 0  18385   18385  4504  17924  0x14ae7839  F=0x0
> >> 1  20160   20160  2880768  0x91017a25
> >> 0  22890  0x8000  4504  37160  0xa54ad420  F=0x0
> >> 1  23040   23040  2880768  0xcd087be2
> >> 0  25893   25893  4504  18920  0x6230931b  F=0x0
> >> 1  25920   25920  2880768  0xca8a79b6
> >> 1  28800   28800  2880768  0x1d5e7a84
> >> 0  30398   30398  3003  17172  0xebbc5af9  F=0x0
> >> 1  31680   31680  2880768  0x1c3e7f7d
> >> 0  33401  0x8000  3003  33636  0x2bf50e31  F=0x0
> >> 1  34560   34560  2880768  0x815d7b63
> >> 1  37440   37440  2880768  0x1ac6762d
> >> 0  37905   37905  3003  16144  0x5fabbc96  F=0x0
> >> 1  40320   40320  2880768  0x7e2f8d29
> >> 0  40908   40908  4504  14960  0xe0a8abb9  F=0x0
> >> 1  43200   43200  2880768  0x951c8f4c
> >> 0  45412  0x8000  4504  34072  0x6bf61d8c  F=0x0
> >> 1  46080   46080  2880768  0xf42e82a7
> >> 0  48415   48415  4504  14788  0xcc5c4f38  F=0x0
> >> :  :   : :  :   :
> >> 0  136171401   136171401  3003  23924  0xe65b80f5  F=0x0
> >> 1  136172160   136172160  2880768  0x3b687c8c
> >> 0  136174404  0x8000  3003  52328  0x7a17da08  F=0x0
> >> 0  136178908   136178908  3003  23932  0x5bee6d60  F=0x0
> >> 0  136181911   136181911  4504  23452  0xc4a6eb3a  F=0x0
> >>
> >> Why is the above so different from the packets VOBEdit shows and that I
> >> manually parse?
> >> I thought all VOB packets were 2048 bytes.
> 

Re: [FFmpeg-user] framecrc

2023-11-13 Thread Paul B Mahol
On Mon, Nov 13, 2023 at 4:33 AM Mark Filipak 
wrote:

> On 11/12/23 04:57, Paul B Mahol wrote:
> > On Sun, Nov 12, 2023 at 8:36 AM Mark Filipak  >
> > wrote:
> >
> >> Previous Subject: "rewrite tags in a source's PES headers -- How?"
> >>
> >> On 11/11/23 13:41, Paul B Mahol wrote:
> >>> On Sat, Nov 11, 2023 at 7:29 PM Mark Filipak <
> markfilipak.i...@gmail.com
> >>>
> >>> wrote:
> >>>
>  Here's what I'm doing:
>  -bsf:v setts=time_base=1/24000:pts=N*1001:dts=N*1001
> 
>  Here's the result:
>  frame  ptsdts
>    00   2002 <= should be 0
>    1 3003 <= should be  10013003 <= should be  1001
>    2 4004 <= should be  20024004 <= should be  2002
>    3 2002 <= should be  30035005 <= should be  3003
>    4 5005 <= should be  40046006 <= should be  4004
>    5 1001 <= should be  50057007 <= should be  5005
>    6 8008 <= should be  60068008 <= should be  6006
>    7 9009 <= should be  70079009 <= should be  7007
>    8 7007 <= should be  8008   10010 <= should be  8008
>    910010 <= should be  9009   11011 <= should be  9009
>  10 6006 <= should be 10010   12012 <= should be 10010
>  1113013 <= should be 11011   13013 <= should be 11011
>  1212012 <= should be 12012   14014 <= should be 12012
>  1314014 <= should be 13013   15015 <= should be 13013
>  1411011 <= should be 14014   16016 <= should be 14014
>  1517017 <= should be 15015   17017 <= should be 15015
>  1618018 <= should be 16016   18018 <= should be 16016
>
> Why are the target PTSs out of order?
> Why are there no 0 or 1001 DTSs?
>

DTS is different from PTS.
And you should probably reorder DTS by keeping original order - just do
offset and not by using packet number.


>
>  The source video is 'NTSC'-soft.
>  Can this be explained?
>  Can it be countered?
> 
>  PTSs in frames 1..5 are +2 +2 -1 +1 -4
>  PTSs in frames 6..10 are +2 +2 -1 +1 -4
>  PTSs in frames 11..15 are +2 +0 +1 -3 +2
>  I'm baffled.
> 
> >>>
> >>> N is packet number, and it goes in different order.
> >>
> >> Oh, yes, out of order/out of sequence.
> >>
> >>> Can be confirmed with:
> >>>
> >>> ffmpeg -i  -c copy -f framecrc -
> >>
> >> Thank you, Paul. Good of you. How do I interpret the framecrc table?
> >>
> >> stream_index  packet_duration
> >> |  packet_dts | packet_size
> >> |  |  packet_pts  | |  0xCRC
> >> |  |  |_  |___  |  |_
> >> 1  0   0  2880768  0xb16c8010
> >> 1   28802880  2880768  0x1b728309
> >> 1   57605760  2880768  0x966977f8
> >> 1   86408640  2880768  0x6e078511
> >> 0  10878   22890  3003  62500  0x5877c6d3
> >> 1  11520   11520  2880768  0xe49b880c
> >> [framecrc@ 02a9b140] Timestamps are unset ... stream 0 ...
> >> 1  14400   14400  2880768  0x0a217046
> >> 0  15382   15382  3003  18300  0xd4f063a2  F=0x0
> >> 1  17280   17280  2880768  0xc13a7e27
> >> 0  18385   18385  4504  17924  0x14ae7839  F=0x0
> >> 1  20160   20160  2880768  0x91017a25
> >> 0  22890  0x8000  4504  37160  0xa54ad420  F=0x0
> >> 1  23040   23040  2880768  0xcd087be2
> >> 0  25893   25893  4504  18920  0x6230931b  F=0x0
> >> 1  25920   25920  2880768  0xca8a79b6
> >> 1  28800   28800  2880768  0x1d5e7a84
> >> 0  30398   30398  3003  17172  0xebbc5af9  F=0x0
> >> 1  31680   31680  2880768  0x1c3e7f7d
> >> 0  33401  0x8000  3003  33636  0x2bf50e31  F=0x0
> >> 1  34560   34560  2880768  0x815d7b63
> >> 1  37440   37440  2880768  0x1ac6762d
> >> 0  37905   37905  3003  16144  0x5fabbc96  F=0x0
> >> 1  40320   40320  2880768  0x7e2f8d29
> >> 0  40908   40908  4504  14960  0xe0a8abb9  F=0x0
> >> 1  43200   43200  2880768  0x951c8f4c
> >> 0  45412  0x8000  4504  34072  0x6bf61d8c  F=0x0
> >> 1  46080   46080  2880768  0xf42e82a7
> >> 0  48415   48415  4504  14788  0xcc5c4f38  F=0x0
> >> :  :   : :  :   :
> >> 0  136171401   136171401  3003  23924  0xe65b80f5  F=0x0
> >> 1  136172160   136172160  2880768  0x3b687c8c
> >> 0  136174404  0x8000  3003  52328  0x7a17da08  F=0x0
> >> 0  136178908   136178908  3003  23932  0x5bee6d60  F=0x0
> >> 0  136181911   136181911  4504  23452  0xc4a6eb3a  F=0x0
> >>
> >> 

Re: [FFmpeg-user] framecrc

2023-11-12 Thread Mark Filipak

On 11/12/23 04:57, Paul B Mahol wrote:

On Sun, Nov 12, 2023 at 8:36 AM Mark Filipak 
wrote:


Previous Subject: "rewrite tags in a source's PES headers -- How?"

On 11/11/23 13:41, Paul B Mahol wrote:

On Sat, Nov 11, 2023 at 7:29 PM Mark Filipak 
Here's what I'm doing:
-bsf:v setts=time_base=1/24000:pts=N*1001:dts=N*1001

Here's the result:
frame  ptsdts
  00   2002 <= should be 0
  1 3003 <= should be  10013003 <= should be  1001
  2 4004 <= should be  20024004 <= should be  2002
  3 2002 <= should be  30035005 <= should be  3003
  4 5005 <= should be  40046006 <= should be  4004
  5 1001 <= should be  50057007 <= should be  5005
  6 8008 <= should be  60068008 <= should be  6006
  7 9009 <= should be  70079009 <= should be  7007
  8 7007 <= should be  8008   10010 <= should be  8008
  910010 <= should be  9009   11011 <= should be  9009
10 6006 <= should be 10010   12012 <= should be 10010
1113013 <= should be 11011   13013 <= should be 11011
1212012 <= should be 12012   14014 <= should be 12012
1314014 <= should be 13013   15015 <= should be 13013
1411011 <= should be 14014   16016 <= should be 14014
1517017 <= should be 15015   17017 <= should be 15015
1618018 <= should be 16016   18018 <= should be 16016


Why are the target PTSs out of order?
Why are there no 0 or 1001 DTSs?


The source video is 'NTSC'-soft.
Can this be explained?
Can it be countered?

PTSs in frames 1..5 are +2 +2 -1 +1 -4
PTSs in frames 6..10 are +2 +2 -1 +1 -4
PTSs in frames 11..15 are +2 +0 +1 -3 +2
I'm baffled.



N is packet number, and it goes in different order.


Oh, yes, out of order/out of sequence.


Can be confirmed with:

ffmpeg -i  -c copy -f framecrc -


Thank you, Paul. Good of you. How do I interpret the framecrc table?

stream_index  packet_duration
|  packet_dts | packet_size
|  |  packet_pts  | |  0xCRC
|  |  |_  |___  |  |_
1  0   0  2880768  0xb16c8010
1   28802880  2880768  0x1b728309
1   57605760  2880768  0x966977f8
1   86408640  2880768  0x6e078511
0  10878   22890  3003  62500  0x5877c6d3
1  11520   11520  2880768  0xe49b880c
[framecrc@ 02a9b140] Timestamps are unset ... stream 0 ...
1  14400   14400  2880768  0x0a217046
0  15382   15382  3003  18300  0xd4f063a2  F=0x0
1  17280   17280  2880768  0xc13a7e27
0  18385   18385  4504  17924  0x14ae7839  F=0x0
1  20160   20160  2880768  0x91017a25
0  22890  0x8000  4504  37160  0xa54ad420  F=0x0
1  23040   23040  2880768  0xcd087be2
0  25893   25893  4504  18920  0x6230931b  F=0x0
1  25920   25920  2880768  0xca8a79b6
1  28800   28800  2880768  0x1d5e7a84
0  30398   30398  3003  17172  0xebbc5af9  F=0x0
1  31680   31680  2880768  0x1c3e7f7d
0  33401  0x8000  3003  33636  0x2bf50e31  F=0x0
1  34560   34560  2880768  0x815d7b63
1  37440   37440  2880768  0x1ac6762d
0  37905   37905  3003  16144  0x5fabbc96  F=0x0
1  40320   40320  2880768  0x7e2f8d29
0  40908   40908  4504  14960  0xe0a8abb9  F=0x0
1  43200   43200  2880768  0x951c8f4c
0  45412  0x8000  4504  34072  0x6bf61d8c  F=0x0
1  46080   46080  2880768  0xf42e82a7
0  48415   48415  4504  14788  0xcc5c4f38  F=0x0
:  :   : :  :   :
0  136171401   136171401  3003  23924  0xe65b80f5  F=0x0
1  136172160   136172160  2880768  0x3b687c8c
0  136174404  0x8000  3003  52328  0x7a17da08  F=0x0
0  136178908   136178908  3003  23932  0x5bee6d60  F=0x0
0  136181911   136181911  4504  23452  0xc4a6eb3a  F=0x0

Why is the above so different from the packets VOBEdit shows and that I
manually parse?
I thought all VOB packets were 2048 bytes.
Are the packets above a different type of packet?


Again, lacks of deeper understanding of FFmpeg subject.


So, what are the answers? Does anyone know?


The above command demuxes all packets, including audio/video/subtitle.


I knew that of course. Stream 0 is video. Stream 1 is audio. There are no 
subtitles.
The framecrc table makes no sense unless its 'packets' and the source's TS packets are much 
different things. Is the framecrc table from the MP4 muxer instead of from the source frames?



The video is 'NTSC'-soft (24/1.001fps). '3003' means ffprobe 'sees'
30/1.001fps.
How can I stop the decoder doing telec

Re: [FFmpeg-user] framecrc

2023-11-12 Thread Paul B Mahol
On Sun, Nov 12, 2023 at 8:36 AM Mark Filipak 
wrote:

> Previous Subject: "rewrite tags in a source's PES headers -- How?"
>
> On 11/11/23 13:41, Paul B Mahol wrote:
> > On Sat, Nov 11, 2023 at 7:29 PM Mark Filipak  >
> > wrote:
> >
> >> Here's what I'm doing:
> >> -bsf:v setts=time_base=1/24000:pts=N*1001:dts=N*1001
> >>
> >> Here's the result:
> >> frame  ptsdts
> >>  00   2002 <= should be 0
> >>  1 3003 <= should be  10013003 <= should be  1001
> >>  2 4004 <= should be  20024004 <= should be  2002
> >>  3 2002 <= should be  30035005 <= should be  3003
> >>  4 5005 <= should be  40046006 <= should be  4004
> >>  5 1001 <= should be  50057007 <= should be  5005
> >>  6 8008 <= should be  60068008 <= should be  6006
> >>  7 9009 <= should be  70079009 <= should be  7007
> >>  8 7007 <= should be  8008   10010 <= should be  8008
> >>  910010 <= should be  9009   11011 <= should be  9009
> >> 10 6006 <= should be 10010   12012 <= should be 10010
> >> 1113013 <= should be 11011   13013 <= should be 11011
> >> 1212012 <= should be 12012   14014 <= should be 12012
> >> 1314014 <= should be 13013   15015 <= should be 13013
> >> 1411011 <= should be 14014   16016 <= should be 14014
> >> 1517017 <= should be 15015   17017 <= should be 15015
> >> 1618018 <= should be 16016   18018 <= should be 16016
> >>
> >> The source video is 'NTSC'-soft.
> >> Can this be explained?
> >> Can it be countered?
> >>
> >> PTSs in frames 1..5 are +2 +2 -1 +1 -4
> >> PTSs in frames 6..10 are +2 +2 -1 +1 -4
> >> PTSs in frames 11..15 are +2 +0 +1 -3 +2
> >> I'm baffled.
> >>
> >
> > N is packet number, and it goes in different order.
>
> Oh, yes, out of order/out of sequence.
>
> > Can be confirmed with:
> >
> > ffmpeg -i  -c copy -f framecrc -
>
> Thank you, Paul. Good of you. How do I interpret the framecrc table?
>
> stream_index  packet_duration
> |  packet_dts | packet_size
> |  |  packet_pts  | |  0xCRC
> |  |  |_  |___  |  |_
> 1  0   0  2880768  0xb16c8010
> 1   28802880  2880768  0x1b728309
> 1   57605760  2880768  0x966977f8
> 1   86408640  2880768  0x6e078511
> 0  10878   22890  3003  62500  0x5877c6d3
> 1  11520   11520  2880768  0xe49b880c
> [framecrc@ 02a9b140] Timestamps are unset ... stream 0 ...
> 1  14400   14400  2880768  0x0a217046
> 0  15382   15382  3003  18300  0xd4f063a2  F=0x0
> 1  17280   17280  2880768  0xc13a7e27
> 0  18385   18385  4504  17924  0x14ae7839  F=0x0
> 1  20160   20160  2880768  0x91017a25
> 0  22890  0x8000  4504  37160  0xa54ad420  F=0x0
> 1  23040   23040  2880768  0xcd087be2
> 0  25893   25893  4504  18920  0x6230931b  F=0x0
> 1  25920   25920  2880768  0xca8a79b6
> 1  28800   28800  2880768  0x1d5e7a84
> 0  30398   30398  3003  17172  0xebbc5af9  F=0x0
> 1  31680   31680  2880768  0x1c3e7f7d
> 0  33401  0x8000  3003  33636  0x2bf50e31  F=0x0
> 1  34560   34560  2880768  0x815d7b63
> 1  37440   37440  2880768  0x1ac6762d
> 0  37905   37905  3003  16144  0x5fabbc96  F=0x0
> 1  40320   40320  2880768  0x7e2f8d29
> 0  40908   40908  4504  14960  0xe0a8abb9  F=0x0
> 1  43200   43200  2880768  0x951c8f4c
> 0  45412  0x8000  4504  34072  0x6bf61d8c  F=0x0
> 1  46080   46080  2880768  0xf42e82a7
> 0  48415   48415  4504  14788  0xcc5c4f38  F=0x0
> :  :   : :  :   :
> 0  136171401   136171401  3003  23924  0xe65b80f5  F=0x0
> 1  136172160   136172160  2880768  0x3b687c8c
> 0  136174404  0x8000  3003  52328  0x7a17da08  F=0x0
> 0  136178908   136178908  3003  23932  0x5bee6d60  F=0x0
> 0  136181911   136181911  4504  23452  0xc4a6eb3a  F=0x0
>
> Why is the above so different from the packets VOBEdit shows and that I
> manually parse?
> I thought all VOB packets were 2048 bytes.
> Are the packets above a different type of packet?
>
>
Again, lacks of deeper understanding of FFmpeg subject.
The above command demuxes all packets, including audio/video/subtitle.


> The video is 'NTSC'-soft (24/1.001fps). '3003' means ffprobe 'sees'
> 30/1.001fps.
> How can I stop the decoder doing telecine?
>

No decoder does telecine.


>
> Cheers
> --Mark.
>
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ff