mirror of
https://github.com/CCExtractor/ccextractor.git
synced 2026-02-03 21:23:48 +00:00
Binary metadata extraction way too noisy #76
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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...
@anshul1912 commented on GitHub (Oct 16, 2015):
I did a search in logs and found that print have same priority from start of 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 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 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