Hi,
Reinhard Nissl wrote:
>> as some people seem to get messages like the following several seconds
>> (> 60) after switching to a certain channel (or after a recording has
>> switched a device)
>>
>> Sep 2 11:12:49 video vdr[14940]: cAudioRepacker: skipped 911 bytes to
>> sync on next audio frame
>> Sep 2 11:12:49 video vdr[14940]: cAudioRepacker: skipped 785 bytes to
>> sync on next audio frame
>> Sep 2 11:12:50 video vdr[14940]: cAudioRepacker: skipped 221 bytes to
>> sync on next audio frame
>>
>> it may be likely that there is a bug in cAudioRepacker. Therefore I've
>> added some debug output to possibly identify a bug.
>>
>> The attached patch is against vanilla VDR-1.3.31 and contains all my
>> previously released patches since VDR-1.3.31 plus the new debug messages.
>
> I've updated the patch. It stores now up to 100 TS packets, that led to
> a wrong audio header respectively to synchronisation. The files are
> written to /video, as I assume some space at this location ;-) If you
> want to use a different location, just have a look into cTSLogger::Dump().
>
> While adding the dumper to cAudioRepacker, I've discovered a little bug
> which could lead to recognizing an audio frame header too early: after a
> frame is done, at least 4 bytes (which are counted by variable
> skippedBytes) need to be read before scanner can be tested for a valid
> audio header.
>
>> As I experience such messages only rarely it takes quite some time to
>> wait for the next log message and there are only about 30 hours left
>> before VDR-1.3.32 is likely to be released.
>>
>> So I really invite you to help debugging this issue. Please send any
>> such messages to the list or maybe to me privately. But be aware: I'm
>> not interested in the messages that happen immediately after tuning
>> the device! Especially VDR-1.3.31 reports sometimes a lot of them, as
>> waiting for the tuner getting locked was removed. There is nothing
>> special about these messages.
>>
>> To make it clear once more: just send such messages that happen for
>> example 60 seconds after the last tuning activity (log message:
>> "switching to channel X" or "switching device X to channel Y").
>>
>> The sent log messages should also include the lines which allow to
>> identy the thread that drives cAudioRepacker. Typically these log
>> messages (like "transfer thread started" or "recording thread
>> started") follow the switching messages.
>
> Please include the dumped TS logfiles (/video/ts_*.log) too.
>
>> NPTL users: please turn off NPTL for this test (by defining an
>> environment variable: export LD_ASSUME_KERNEL=2.4.1) as it is not
>> possible to indentify the reporting thread otherwise.
Meanwhile I've got a second report. Dumping it like that
od -Ax -w188 -v -t x1 ts_22252_2342936_0xC0_005_36676_100.log | less -S
shows a discontinuity at the end of the file
v
004218 47 00 88 14 d0 a3 e1 59 3a 12 74 0e 49 ca 80 c2 5d 57 58 50 74 ed
4d 2c 5a f5 46 b5 6d a3 16 b5 4a 52 88 46 b5 ad 84 08 4a da 91 9d a5 57
cd cf 9b 9b 2e e6 ed 67 1c 87 27
0042d4 47 00 88 18 b6 b3 63 c3 24 32 22 48 92 d8 b6 31 58 a4 24 20 13 11
eb 38 ae aa 6b 2a e7 3d ef 79 e0 c4 a5 2a 75 18 99 eb 10 e2 c6 d9 59 96
9a 79 a7 96 b5 fe 47 91 e3 51 a9
^
In such a case, cAudioRepacker can do nothing else than synchronize to
the next audio frame header and drop any data up to synchronization.
This is the same as what the decoder did before VDR-1.3.31, except
reporting that it has happened.
Missing TS packets are a matter of digital broadcasting and cannot be
avoided completely, but optimizing the reception system my minimize them.
If you still find issues with cAudioRepacker that are not related to
missing TS packets (use the above command and check the tail), feel free
to report them further. Many thanks to all of you, who supported me by
sending reports or by just running the modified cAudioRepacker with no
unusual behaviour ;-)
BTW: attached you'll find the file remux.c of the upcoming VDR-1.3.32,
which is almost identical to the version contained in last patch, but
with all debug messages removed again.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@xxxxxx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remux.c
Type: text/x-csrc
Size: 68751 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/vdr/attachments/20050906/69ae0e64/remux-0001.c
