search

gigakuma / tstools

Automatically exported from code.google.com/p/tstools
0 stars 0 forks source link

TS seek should be more robust #1

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Currently, seeking in a TS file must exactly seek to the start of a TS packet. 
This is moderately reasonable, but it would be useful to have an option (or a 
different call) which finds the "nearest" (or more convenient!) TS packet 
(should it prefer forwards or back?).

It is probably reasonable to assume one has the start of a TS packet if one is 
at 0x47, and there 0x47 bytes 188 bytes away in either direction (or two of the 
forwards/backwards, etc.).

Was bug 14627 on berlios.de

Original issue reported on code.google.com by t...@tibsnjoan.co.uk on 26 Sep 2010 at 2:08

GoogleCodeExporter commented 9 years ago 
Maybe its my limited understanding of ts stream but beyond that wouldn't you 
want to have the option to seek to an packet where the RAI (Random Access 
indicator) flag is set. This should (to my understanding) bring you to a clean 
audio or video start point?

Original comment by shane.an...@gmail.com on 27 Sep 2010 at 2:34

GoogleCodeExporter commented 9 years ago 
I occasionally work with streams where this would be nice. In particular there 
could be stream corruption where bytes are dropped, or the ts file was clipped 
incorrectly mid-packet where a re-sync to nearest packet would be useful. 
That's somewhat tangential from using RAI for clean seeks...

Original comment by Digik...@gmail.com on 23 Sep 2011 at 6:10