IllegalArgumentException: Expecting header packet but got org.gagravarr.vorbis.VorbisAudioData@277050d

[THausherr]

Exception in thread "main" java.lang.IllegalArgumentException: Expecting header packet but got org.gagravarr.vorbis.VorbisAudioData@277050dc
at org.gagravarr.ogg.audio.OggAudioStreamHeaders.populate(OggAudioStreamHeaders.java:138)
at org.gagravarr.theora.TheoraFile.(TheoraFile.java:142)
at org.gagravarr.theora.TheoraFile.(TheoraFile.java:77)
at com.mycompany.TheoTest.main(TheoTest.java:23)

Code:

        InputStream is = TheoTest.class.getResourceAsStream("/test1.ogg");
        OggFile ogg = new OggFile(is);
        TheoraFile theora = new TheoraFile(ogg);

MOZILLA-487519-4.zip
file is from https://bugzilla.mozilla.org/show_bug.cgi?id=487519

[Gagravarr]

Do you know the licensing status of test1.ogg from that mozilla zip? Ideally I'd like to write a unit test to go with this fix, just need to work out if I can include that test file or not?

[THausherr]

No, you'd have to ask Lucas Adamski, if he remembers where he got these files 16 years ago.

[Gagravarr]

Looking into this a bit more, it's a pretty broken looking file. mpv can't cope at all

$ mpv test1.ogg 
[ffmpeg/demuxer] ogg: CRC mismatch!
[ffmpeg/demuxer] ogg: CRC mismatch!
[ffmpeg/demuxer] ogg: Header processing failed: Invalid data found when processing input
[lavf] avformat_open_input() failed
[ffmpeg/demuxer] ogg: CRC mismatch!
[ffmpeg/demuxer] ogg: CRC mismatch!
[ffmpeg/demuxer] ogg: Header processing failed: Invalid data found when processing input
[lavf] avformat_open_input() failed
Failed to recognize file format.
Exiting... (Errors when loading file)

ogginfo spits out a lot of warnings

$ ogginfo test1.ogg | grep WARN | wc -l
111

and is generally pretty unhappy with it

$ ogginfo test1.ogg | head -30
Processing file "test1.ogg"...

Note: Stream 1 has serial number 0, which is legal but may cause problems with some tools.
New logical stream (#1, serial: 00000000): type theora
New logical stream (#2, serial: 00000001): type vorbis
WARNING: Hole in data (44 bytes) found at approximate offset 13500 bytes. Corrupted Ogg.
Theora headers parsed for stream 1, information follows...
Version: 3.2.1
Vendor: Xiph.Org libTheora I 20070915 3 2 1
Width: 320
Height: 240
Total image: 320 by 240, crop offset (0, 0)
Framerate 25/1 (25.00 fps)
Pixel aspect ratio 1:1 (1.000000:1)
Frame aspect 4:3
Colourspace unspecified
Pixel format 4:2:0
Target bitrate: 300 kbps
Nominal quality setting (0-63): 0
WARNING: sequence number gap in stream 2. Got page 2 when expecting page 1. Indicates missing data.
WARNING: discontinuity in stream (2)
WARNING: Could not decode Vorbis header packet 1 - invalid Vorbis stream (2)
WARNING: Could not decode Vorbis header packet 1 - invalid Vorbis stream (2)
WARNING: Could not decode Vorbis header packet 1 - invalid Vorbis stream (2)
WARNING: Could not decode Vorbis header packet 1 - invalid Vorbis stream (2)
WARNING: Could not decode Vorbis header packet 1 - invalid Vorbis stream (2)
WARNING: Could not decode Vorbis header packet 1 - invalid Vorbis stream (2)
WARNING: Could not decode Vorbis header packet 1 - invalid Vorbis stream (2)
WARNING: Could not decode Vorbis header packet 1 - invalid Vorbis stream (2)
WARNING: Could not decode Vorbis header packet 1 - invalid Vorbis stream (2)

It feels like IllegalArgumentException may not be exactly the right exception to throw for this sort of situation, but I am leaning towards saying that the library is probably going to want to throw some sort of an Exception for this file when you try to load it through one of the format-specific decoders.

Thoughts / ideas / comments / suggestions?

[THausherr]

Either an ordinary IOException, or just add some mention in the javadoc that IllegalArgumentException is thrown for bad files.

[THausherr]

Also, here's another, same method, but different cause ("Invalid type -124") and different code line.

3H6XSN7A3PGPJKMI42BH2CTQ224T2LRD.zip

[andrm]

Stupid question: In a "stream" situation, i.e. reading from a socket or a gstreamer pipeline, could we recover? Like reading until a valid header comes by?

[Gagravarr]

The underlying ogg structure handles lost / corrupted packets in the underlying stream, and has a way to re-sync. You'd loose some media data, but you can then pick up later. For this kind of thing, the library logs warnings and you'll see jumps in granule position, but things will carry on.

Problem here is corruption at the start of the logical stream within the ogg structure. Most of the ogg stream types put their setup + config info at the start of the stream, eg channel count / encoding type / compression tables. Without that, you can't make sense of the media data packets. So even if you can re-sync a broken stream, you can't decode the media data you then start receiving again

So short answer - you can recovery, except at the start!

[Gagravarr]

Either an ordinary IOException, or just add some mention in the javadoc that IllegalArgumentException is thrown for bad files.

I think it might be better to keep IllegalArgumentException for things that the caller has direct control of

Maybe a custom subtype of IOException for these broken files? Library callers should already be catching that, lets them know a bit more if they're interested but no change if not?

[THausherr]

Yeah a subtype sounds nice.