On 11/11/2011 07:31 AM, Andrea3000 wrote: > John Stebbins <stebbins@...> writes: > >> Clips always have a PCR at the beginning. So if FFmpeg is handling >> PCR discontinuities correctly, there really shouldn't be anything you >> need to do. However, I wouldn't be surprised at all if FFmpeg doesn't >> handle them correctly. I've never been very impressed with how >> FFmpeg handles timestamp processing. That's one of the reasons >> we keep our own TS demux in HandBrake. >> > I was wrong, FFmpeg doesn't seem to parse PCR field at all when using > regular MPEG-TS demuxer. It reads PCR only when it uses raw MPEG-TS > demuxer. But that demuxer doesn't provide proper packet parsing that > is needed to properly decode every frame. Or at least I'm not able to use it.. > > I think I need to implement this on my own, at ffmpeg level or at level > of my app. > But I have to study this MPEG-TS header structure a lot more because > I still don't have a clear understanding of all the necessary pieces. > > One thing that I'm really not able to figure out is how I can handle > seek properly. I mean, when I seek foreward, I > don't know from which clip I am extracting packets after seek. > If it were a stream without discontinuity, it's simply a matter of > realigning to the new PTS and DTS values which are greater than the > previous ones and are proportional to the playback time. bd_tell_time() after the seek. This will give you the absolute time in 90khz ticks of your current position from the beginning of the title. bd_seek() will always seek to the nearest recovery point before the requested seek position.
> But with this type of stream, if I realign to the new PTS and DTS values > I loose the playback time because new clip has its own PTS and DTS which > start over and therefore I loose the actual position in the entire title. > Does also PCR reset itself upon switching clip or it remains monotone? They reset at the beginning of each clip. . > How can I always have an indicator of the relative position in the > movie as long as PTS and DTS are no more suitable for this? You can call bd_tell_time() at any point, but it will not always be 100% accurate. It looks up your current position in the CPI which is an index of recovery points in a clip. So it will return the time of the nearest recovery point. > Have I to use the number of bytes of the actual position compared to > the total number of bytes of the entire title? This seems a dirty hack.. > If I'm understanding your need correctly, bd_tell_time() should be adequate. -- John GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01 83F0 49F1 D7B2 60D4 D0F7
signature.asc
Description: OpenPGP digital signature
_______________________________________________ libbluray-devel mailing list [email protected] http://mailman.videolan.org/listinfo/libbluray-devel
