Comment 28 for bug 327872

Revision history for this message
Edward Hervey (bilboed) (bilboed-deactivatedaccount) wrote :

To remove (hopefully) some confusion from (amongst other things) the GStreamer side of things.

* HDV/AVCHD in this context means the camera with the 'official' HDV or AVCHD specifications. People linked to those above. Both those formats use mpeg-ts as the container format. If your camera does not record to mpeg-ts... it's not an HDV- or AVCHD- compliant camera.
* The problems aren't that you can't playback the files, but that the support isn't pristine.
* HDV files *playback* fine with latest GStreamer module releases.
* most AVCHD files *playback* fine with latest GStreamer module releases.

The problem here is 'perfect'/'fast' seeking support for those two variants of mpeg-ts. The current gstreamer mpeg-ts demuxer (mpegtsdemux in gst-plugins-bad) was never designed with random-access in mind (it was developed for DVB/streaming support), and that's the root of the issue with those files.

The HDV/AVCHD specifications extend the mpeg-ts usage in very subtle ways making the poor seeking handling in mpegtsdemux even more visible (and in some cases creating A/V sync issues :( ).
Those issues have been known for over a year... but mpegtsdemux is alas tricky code to meddle with and past efforts have only resulted in poor man's seeking capability.

An attempt was started by Zaheer Merali and myself to create a mpeg-ts demuxer from scratch reusing the, much cleaner, mpeg-ts parse codebase which takes into account all those issues and provide a base class for all mpeg-ts variants/use-cases. Problem is... this is low on our respective tasklists :(

P.S. And yes, poor seeking support => reallllly bad support of HDV/AVCHD in PiTiVi and any other gst-based applications who need proper seeking behaviour in mpeg-ts.