Re: question about time

On ti, 2012-08-28 at 23:38 -0700, Waitman Gobble wrote:
> Petri Hintukainen <[email protected]> wrote ..
> > On pe, 2012-08-24 at 23:01 -0700, Waitman Gobble wrote:
> > > Hi,
> > > 
> > > using xine-lib-1.2.2 and xine (X11 gui) v0.99.7.
> > > FreeBSD hunny.waitman.net 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sat Aug 11 13:25:18
> > PDT 2012     
> > > [email protected]:/usr/obj/usr/src/sys/KEYSHIA  amd64
> > > 
> > > 
> > > When I play an MPEG video I've notice that the time seems off. For example, 
> > > a video that's just over 6 minutes long - xine gui says has a 33 second duration.
> > > 
> > > If I take a look at the values using the libxine, ie pos_stream, pos_time, 
> > > length_time, the length_time is '33639' (00:00:33.639)
> > >         
> > > MVI_0087.mpeg|201|103|33639|00:00:00.103|00:00:33.639|
> > > MVI_0087.mpeg|490|251|33639|00:00:00.251|00:00:33.639|
> > > MVI_0087.mpeg|9335|4791|33639|00:00:04.791|00:00:33.639|
> > > 
> > > 
> > > here's ffmpeg info for same video:
> > > 
> > > Duration: 00:06:35.94, start: 1.000000, bitrate: 37423 kb/s
> > > Stream #0.0[0x1e0]: Video: mpeg1video, yuv420p, 1280x720 [PAR 1:1 DAR 16:9],
> > 104857 kb/s, 59.96 fps, 59.94 tbr, 90k tbn, 59.94 tbc
> > > Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16, 64 kb/s
> > > 
> > > If there isn't a way around it, maybe I can use the ratio and calculate a time..
> > > for example, 4791/33639 ~ 14.24%, so about 56 seconds into the video. (instead
> > of 
> > > reported "4.791 seconds").
> > > 
> > > Any idea why the reported time seem to be way off? It would be great for me to
> > track this down.
> > 
> > It is calculated from reported bitrate and file size. Looks like bitrate
> > in that mpeg file is incorrect.
> > 
> > Maybe ffmpeg reads first and last timestamp from the file and calculates
> > time from those.
> > 
> > 
> > - Petri
> > 
> > 
> > ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and 
> > threat landscape has changed and how IT managers can respond. Discussions 
> > will include endpoint security, mobile security and the latest in malware 
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > xine-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/xine-user
> 
> Hi Petri,
> 
> Thank you for your reply. I think you're right, bitrate may be off. HD 720p should be around 19 
> Mbit/s, but this was shot at 60000/1001 frame rate, so maybe that's either muffed up the value 
> or the '19' is based on 24000/1001 frames (therefor more data per s) (?). 
> 
> Anyway, I found a 'better' solution to my bigger problem, convert everything to 24000/1001 
> 1.6 Mbit/s H.264 and go from there. I did have to take some time to set up a dedicated server 
> to run through the motion 24/7, there's much to transcode. But for this particular application 
> I decided it makes sense. :)
> 
> I started digging through the xine code to track down the calculation, does appear to be based 
> on bitrate. As I recall the 'main' duration/stream pos is generic and requests the info from 
> each individual decoder, through a function call/interface. I didn't get to look for the bitrate 
> calculation function(s), but when I get more time I'll look at it more closely to see if there's 
> an issue.

In this case bitrate is not calculated, it is parsed from mpeg file
(demux_mpeg.c).
Maybe just remuxing those files with ffmpeg gives more accurate values ?
Also, using some other container format might give better results. Ex.
matroska has embedded timing information and time display should be
correct. Using average bitrate and stream position for time calculation
will always be just an estimate.
Also seeking to some time position inside .mpeg file is difficult as
there is no index. But this should not be big issue (if I remember
right, seeking in xine-ui is always based on relative stream position,
not time).


- Petri


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/