Binary metadata extraction way too noisy #76

Closed
opened 2026-01-29 16:34:35 +00:00 by claunia · 3 comments
Owner

Originally created by @Liontooth on GitHub (Oct 15, 2015).

The binary metadata extraction for this github version dated 2015-10-15 is really noisy, adding thousands of lines of output like this:

TS continuity counter not incremented prev/curr 0/0

It looks like this output should just be suppressed altogether, as it is in version 0.74:

$ ccextractor-0.74 -ts -pn 4 -out=bin -o /tv/2015/2015-10/2015-10-15/2015-10-15_0100_US_MSNBC_The_Rachel_Maddow_Show.ccx.bin /tv/2015/2015-10/2015-10-15/2015-10-15_0100_US_MSNBC_The_Rachel_Maddow_Show.mpg
CCExtractor 0.74, Carlos Fernandez Sanz, Volker Quetschke.
Teletext portions taken from Petr Kutalek's telxcc


Input: /tv/2015/2015-10/2015-10-15/2015-10-15_0100_US_MSNBC_The_Rachel_Maddow_Show.mpg
[Extract: 1] [Stream mode: Transport]
[Program : 4 ] [Hauppage mode: No] [Use MythTV code: Auto]

[Timing mode: Auto] [Debug: No] [Buffer input: No]
[Use pic_order_cnt_lsb for H.264: No] [Print CC decoder traces: No]
[Target format: .bin] [Encoding: UTF-8] [Delay: 0] [Trim lines: No]
[Add font color data: Yes] [Add font typesetting: Yes]
[Convert case: No] [Video-edit join: No]
[Extraction start time: not set (from start)]
[Extraction end time: not set (to end)]
[Live stream: No] [Clock frequency: 90000]
Teletext page: [Autodetect]
Start credits text: [None]
Creating /tv/2015/2015-10/2015-10-15/2015-10-15_0100_US_MSNBC_The_Rachel_Maddow_Show.ccx.bin


Opening file: /tv/2015/2015-10/2015-10-15/2015-10-15_0100_US_MSNBC_The_Rachel_Maddow_Show.mpg
Analyzing data in general mode
Decode captions from program 4 - MPEG-2 video stream [0x02] - PID: 1024
0% | 00:00

New video information found
[720 * 480] [AR: 02 - 4:3] [FR: 04 - 29.97] [progressive: no]

100% | 59:54
Number of NAL_type_7: 0
Number of VCL_HRD: 0
Number of NAL HRD: 0
Number of jump-in-frames: 0
Number of num_unexpected_sei_length: 0
CC type 0: 38619 (NTSC line 21 field 1 closed captions)
CC type 1: 0 (NTSC line 21 field 2 closed captions)
CC type 2: 0 (DTVCC Channel Packet Data)
CC type 3: 0 (DTVCC Channel Packet Start)

Total frames time: 00:59:54:324 (107722 frames at 29.97fps)

Min PTS: 06:32:06:832
Max PTS: 07:32:00:853
Length: 00:59:54:021

Initial GOP time: 06:39:33:734
Final GOP time: 07:39:28:033 +1F
Diff. GOP length: 00:59:54:299 +1F (00:59:54:332)

Total user data fields: 107722
HDTV type user data fields: 107722
Done, processing time = 6 seconds
Performance (real length/process time) = 599.06
This is beta software. Report issues to carlos at ccextractor org...

Originally created by @Liontooth on GitHub (Oct 15, 2015). The binary metadata extraction for this github version dated 2015-10-15 is really noisy, adding thousands of lines of output like this: TS continuity counter not incremented prev/curr 0/0 It looks like this output should just be suppressed altogether, as it is in version 0.74: $ ccextractor-0.74 -ts -pn 4 -out=bin -o /tv/2015/2015-10/2015-10-15/2015-10-15_0100_US_MSNBC_The_Rachel_Maddow_Show.ccx.bin /tv/2015/2015-10/2015-10-15/2015-10-15_0100_US_MSNBC_The_Rachel_Maddow_Show.mpg CCExtractor 0.74, Carlos Fernandez Sanz, Volker Quetschke. Teletext portions taken from Petr Kutalek's telxcc --- Input: /tv/2015/2015-10/2015-10-15/2015-10-15_0100_US_MSNBC_The_Rachel_Maddow_Show.mpg [Extract: 1] [Stream mode: Transport] [Program : 4 ] [Hauppage mode: No] [Use MythTV code: Auto] [Timing mode: Auto] [Debug: No] [Buffer input: No] [Use pic_order_cnt_lsb for H.264: No] [Print CC decoder traces: No] [Target format: .bin] [Encoding: UTF-8] [Delay: 0] [Trim lines: No] [Add font color data: Yes] [Add font typesetting: Yes] [Convert case: No] [Video-edit join: No] [Extraction start time: not set (from start)] [Extraction end time: not set (to end)] [Live stream: No] [Clock frequency: 90000] Teletext page: [Autodetect] Start credits text: [None] Creating /tv/2015/2015-10/2015-10-15/2015-10-15_0100_US_MSNBC_The_Rachel_Maddow_Show.ccx.bin --- Opening file: /tv/2015/2015-10/2015-10-15/2015-10-15_0100_US_MSNBC_The_Rachel_Maddow_Show.mpg Analyzing data in general mode Decode captions from program 4 - MPEG-2 video stream [0x02] - PID: 1024 0% | 00:00 New video information found [720 \* 480] [AR: 02 - 4:3] [FR: 04 - 29.97] [progressive: no] 100% | 59:54 Number of NAL_type_7: 0 Number of VCL_HRD: 0 Number of NAL HRD: 0 Number of jump-in-frames: 0 Number of num_unexpected_sei_length: 0 CC type 0: 38619 (NTSC line 21 field 1 closed captions) CC type 1: 0 (NTSC line 21 field 2 closed captions) CC type 2: 0 (DTVCC Channel Packet Data) CC type 3: 0 (DTVCC Channel Packet Start) Total frames time: 00:59:54:324 (107722 frames at 29.97fps) Min PTS: 06:32:06:832 Max PTS: 07:32:00:853 Length: 00:59:54:021 Initial GOP time: 06:39:33:734 Final GOP time: 07:39:28:033 +1F Diff. GOP length: 00:59:54:299 +1F (00:59:54:332) Total user data fields: 107722 HDTV type user data fields: 107722 Done, processing time = 6 seconds Performance (real length/process time) = 599.06 This is beta software. Report issues to carlos at ccextractor org...
Author
Owner

@anshul1912 commented on GitHub (Oct 16, 2015):

I did a search in logs and found that print have same priority from start of git

anshul@linux-z9q9:~/Project/Multimedia/ccextractor/src> git --no-pager log -S "mprint(\"TS continuity counter not incremented prev"
commit 617d2d30dc84f8c4075b4546ee6ff9bff89cc916
Author: Anshul Maheshwari <anshul.ffmpeg@gmail.com>
Date:   Tue Oct 7 02:33:20 2014 +0530

    move all code except ccextractor in folder lib_ccx

commit 8980e807a8754b8450a4648d089a13692ff46460
Author: cfsmp3 <cfsmp3@gmail.com>
Date:   Fri May 16 12:35:11 2014 +0200

    Rename everything else to .c

commit 6e0db8aa1daf0b6c0edc9536c5a813cf70b014be
Author: cfsmp3 <cfsmp3@gmail.com>
Date:   Sat Apr 12 12:41:27 2014 +0200

    Initial git.

Do you suggest to lower the priority?
counter problem can also arise if some part of file is not read correctly and missed some packets, does that problem comes in some of your video or you notice it all the time.
if you notice this problem in some of the videos then can you share sample of video, so that i can investigate further to find the problem

@anshul1912 commented on GitHub (Oct 16, 2015): I did a search in logs and found that print have same priority from start of git ``` gitlog anshul@linux-z9q9:~/Project/Multimedia/ccextractor/src> git --no-pager log -S "mprint(\"TS continuity counter not incremented prev" commit 617d2d30dc84f8c4075b4546ee6ff9bff89cc916 Author: Anshul Maheshwari <anshul.ffmpeg@gmail.com> Date: Tue Oct 7 02:33:20 2014 +0530 move all code except ccextractor in folder lib_ccx commit 8980e807a8754b8450a4648d089a13692ff46460 Author: cfsmp3 <cfsmp3@gmail.com> Date: Fri May 16 12:35:11 2014 +0200 Rename everything else to .c commit 6e0db8aa1daf0b6c0edc9536c5a813cf70b014be Author: cfsmp3 <cfsmp3@gmail.com> Date: Sat Apr 12 12:41:27 2014 +0200 Initial git. ``` Do you suggest to lower the priority? counter problem can also arise if some part of file is not read correctly and missed some packets, does that problem comes in some of your video or you notice it all the time. if you notice this problem in some of the videos then can you share sample of video, so that i can investigate further to find the problem
Author
Owner

@anshul1912 commented on GitHub (Oct 17, 2015):

@Liontooth Dont worry about sample, While testing all the samples I found that I am able to reproduce same bug using the.tudors.208-ALANiS.ts sample that I have.

@anshul1912 commented on GitHub (Oct 17, 2015): @Liontooth Dont worry about sample, While testing all the samples I found that I am able to reproduce same bug using the.tudors.208-ALANiS.ts sample that I have.
Author
Owner

@anshul1912 commented on GitHub (Oct 17, 2015):

@Liontooth if it is possible can you share one log with verbose output, it looks like while complaining for continuity counter, previous packet and current packet both have same counter value. which means either we have lost 15 packet or it may mean that we are re reading the same ts packet. But if in verbose logs you have always same current and prev counter then there may be some problem in code

@anshul1912 commented on GitHub (Oct 17, 2015): @Liontooth if it is possible can you share one log with verbose output, it looks like while complaining for continuity counter, previous packet and current packet both have same counter value. which means either we have lost 15 packet or it may mean that we are re reading the same ts packet. But if in verbose logs you have always same current and prev counter then there may be some problem in code
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ccextractor#76