esreport without -h262 option does not show the first seq header

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Grab a h262 es file - Only been tested with files that start with a seq 
header item starting at byte 0 (i.e. byte 3 is 0xb3).
2. esreport -h262 <filename>
Shows the header including a SEQUENCE HEADER
3. esreport <filename>
Shows the first picture

Original issue reported on code.google.com by jen.a.fr...@googlemail.com on 26 Jul 2012 at 11:57

[GoogleCodeExporter]

I've pushed a tentative fix on branch issue20. I'm not able to test it easily 
this week (I'm not in at work), but if it's possible for you to pull it and 
test it, that would be wonderful.

Original comment by t...@tibsnjoan.co.uk on 2 Aug 2012 at 3:43

• Changed state: Started

[GoogleCodeExporter]

Commit on issue20 seems to work on mpeg2 es files and start with seq header as 
expected. H264 files are unchanged.
Only lightly tested. I've checked stdin as well, it seems to work, but it also 
worked on a previous version.

Original comment by jen.a.fr...@googlemail.com on 2 Aug 2012 at 4:00

[GoogleCodeExporter]

The fault was that for ES files without the -h262 switch, it was reading 
forwards to determine the file type, but not then rewinding. Files read using 
-pes do rewind.

The fix I've done is to use an initial ES context for the read forwards, and 
then delete that, rewind the input stream, and create a new ES context for the 
actual (useful) reading of the file. This makes the "guess file type" case 
behave more like the case where you've told it the filetype.

Reading from standard input will continue to (should, anyway) behave 
differently in the two cases, as we cannot rewind stdin.

I shall merge the issue20 branch into master and mark this fixed (since it 
seems plausible).

Original comment by t...@tibsnjoan.co.uk on 2 Aug 2012 at 4:55

• Changed state: Fixed