search

MediaArea / MediaInfoLib

Convenient unified display of the most relevant technical and tag data for video and audio files.
https://mediaarea.net/MediaInfo
BSD 2-Clause "Simplified" License
630 stars 171 forks source link

mediatrace and mkv top-level elements #179

Open dericed opened 8 years ago

dericed commented 8 years ago

This sample again: http://samples.ffmpeg.org/A-codecs/AAC/faad2-fail.mkv

When I evaluate it I can an error which may be related: mediaconch --force -mt -mi -fx http://samples.ffmpeg.org/A-codecs/AAC/faad2-fail.mkv | xml fo > /tmp/t.xml E: http://samples.ffmpeg.org/A-codecs/AAC/faad2-fail.mkv, HTTP server doesn't seem to support byte ranges. Cannot resume.

The resulting mediatrace does not reference the second SeekHead at 245057865 or the Cues at 245051761. In the implementation check I already ignore the Clusters doing SeekHead resolution tests with Clusters, but if the first SeekHead references Cues and a second SeekHead is this not feasible to test either? Or should I say only to do a SeekHead resolution test up to a particular byte range into the file?

If possible I prefer to trace all top-level elements (descending into them is another issue) with maybe an exception for non-first Clusters.

JeromeMartinez commented 8 years ago

HTTP server doesn't support byte ranges so I can not seek in the file. test it with a modern HTTP server or local. you can also test it with --ParseSpeed=1and you'll get no more this error (no seek is needed) and you should get all Clusters. this option is expected to be the default one with MediaConch in a near future. But not with MediaInfo.

If possible I prefer to trace all top-level elements

This is more analysis time for MediaInfo without need of that in MediAInfo itself. Maybe a dedicated option for MediaConch.

dericed commented 8 years ago

Sounds fine. Once we have the coverage attribute, then I can set some tests to only work with a minimal coverage level. I think --ParseSpeed=1 as default makes sense.