Issues for next release

[davep]

Dave: It is supposed to show "-:--:-- / -:-:--" for the first second or two, but it should show numbers before disappearing even on the first play. Are you getting the dashes or is it totally blank?

Yes it does show dashes rather than complete blank. And if I watch very carefully the dashes are replaced by numbers at the same instant the display disappears...

[Harry]

right then...

i think i've found something concerning the progress bar.

pic 01 shows the start of a recording...(everything's still fine)
after a couple of seconds the progress bar gets
confused ...see pic 02.

it MAY have something to do with VDR strangely splitting
the recording. see the files from the recording in my
filesystem in pic 03.

so it's unlikely me

[Schnurps]

There is a bug reported on vdr-portal (http://www.vdr-portal.de/board/thread.php?postid=438886#post438886):

Vomp seems to crash while trying to access a corrupted video file.
(means that the linked video files are not available/accessable).

Cannot say anything to that, just want you to know, Chris/Dave! :-)

Schnurps

[MarkC]

There is a known problem with reading timestamps from the video stream. Sometimes the VDR recording includes data that looks like a video timestamp, but it isn't. This shouldn't happen. I'm investigating and thinking about the best way to fix it, or work around it.

Harry: this is probably the cause of your weird display, and it could be to do with the way VDR has split the files, or just corrupted data in the file. Would it be possible to give me access to the 001.vdr file and the first 4 megabytes or so of 002.vdr? If you don't have any webspace where you can post it then you can email it if you like, provided it's only 8 MB or so:
m dot calderbank at iname dot com

MarkC

[Harry]

hi Mark,

i don't have access (yet) to my linux box from the internet
but will post the requested data ASAP.
thanks 4 your help!

Harry

[edit]
misspelled your name
[/edit]

[MarkC]

Thanks Harry, I received your vdr files.

This is a different problem. Here, the actual timestamps transmitted by the TV station "jump" during the recording. The jump happens when "Hamburg Journal" starts and the music changes. This is also why VDR has split the file into pieces. If you play 002.vdr in mplayer, for example, you'll see that it starts at this point.

I'm guessing that 003.vdr starts when "Hamburg Journal" finishes, and then the timestamps are back in the original sequence. So the total length is correct when you play it, because vomp calculates the length from timestamps in 001.vdr and 003.vdr.

We assumed that timestamps would always be continuous, but it seems that some TV stations don't work this way. Have you seen things like this on recordings from other channels?

Mark

[Harry]

thanks for looking into this!

the thing is... this particular channel broadcasts different programs
for different regions during certain times.
that's why the picture changes so suddenly.

same problem on other channels?
will check tonight!

cheers
Harry

[MartenR]

The pts and dts on DVB transmission are on most channels not continous. All DVB player application look with there is a big jump in the dts pts and, if there is a big jump, they correct the PTS and DTS appropriate.
This is why vdr uses internally the frame number in the cIndex class for calculating the current timestamp.
Why didn't you use for getting the length of the recording at the server side a call to cIndex member function last, which returns the total frame number and divide it by 25 (PAL) or 30 (NTSC) to get the totallength in seconds.


Marten

[Chris]

I will change the code so that it works out the total length from the last frame number. However that doesn't solve the problem of working out where the current playback point is in the recording... At the moment the exact timecode is retrieved from the MVP hardware, but that obviously isn't very useful if the stream PTS jumps about.

[MartenR]

Well, just ignore too big changes in the jumping PTS.  Look on sourceforge at Project guliverkli, then in subversion at file
/trunk/guliverkli/src/filters/parser/basesplitter/BaseSplitter.cpp

Function CBaseSplitterOutputPin::DeliverPacket, it is from a windows demuxer, who can also handle DVB TS Streams. You see if the change between to PTS of two  successive PES Packets is too big, it  just subtracts these Jump in the PTS.  REFERENCE_TIME is  pts*10000/90, see /trunk/guliverkli/src/filters/parser/basesplitter/BaseSplitterFileEx.cpp function Read .

In this way playback of transport streams is synchronized, maybe you get a timecode from this. Maybe you can store also for every second  or every  I-frame  (I think one second accuracy or per I frame is enough for the progress bar) the pts together with the framenumber from cIndex and than if you get the pts from the hardware look into the array, which framenumber it is.

[Harry]

hi Mark,

i seem to only have tested my "Hamburg Journal" recordings 
because all my other recordings are fine!
(checked 4 different recordings from 4 diff. chans)

if it's too much trouble @debugging... i can live with the jump in time.

greetings
Harry