GNOME Bugzilla – Bug 583875
[mpegtsmux] Add Blu-Ray and AVCHD variants
Last modified: 2018-11-03 13:04:22 UTC
So in addition to the original normal MPEG TS format there are at least two others in common use. The MPEG TS variant used by AVCHD and Blu-Ray, often using the .m2ts suffix. Cameras supporting HDV also use MPEG TS using a variant. To be able to distinguish between these three on a caps level I suggest we add a 'variant' subcaps to the mpegtsmux element. My suggestion for names would be: variant=original variant=avchd variant=hdv
I'm not sure I am clear on what you're proposing. Are you suggesting that mpegtsmux should produce different the different variants based on an output caps filter or something? It already has the m2ts-mode property to signal that it should produce 192-byte 'bluray' TS packets.
well I want a similar behaviour to the quicktime muxer(s). Which means at a minimum that it should produce different variants based on the output caps filter, but preferably that it creates 3 virtual elements, just like the quicktime muxer does. Its painful for me as an application developer is different elements have different ways to setting their partly incompatible variants (ie. some using caps and some using properties). Using caps seems to be the natural way to set this value.
OK. I don't know enough about the differences between the the MPEG-TS types to decide whether it's really worthwhile having 3 separate elements registered by the plugin. I agree that it's the cleanest approach to this general class of problems though - I like how it's worked out for qtmux. As for the specific variants, I know that m2ts/AVCHD seems to just be standard MPEG-TS with the addition of a 4 byte timestamp (checksum?) between each frame. typefinding detects this and puts it in the caps as 'video/mpegts, systemstream=(boolean)true, packetsize=(int)192'. At the moment mpegtsdemux takes the packetsize from the caps and just ignores these extra timestamp bytes. I've seen some indication that it may fail spectacularly on some streams with this approach. That is, Wikipedia says the extra timestamp bytes are used to for indicating out-of-order packets, and that suggests the demuxer may need to reorder the incoming data stream to correctly demux it: http://en.wikipedia.org/wiki/MPEG-2_transport_stream#Modifications_of_transport_stream_specification_for_random-access_media_.28M2TS.29 I think HDV also uses this 192 byte scheme? I know there is also a 204-byte MPEG-TS variant, 188-byte standard payload plus 16 bytes error correction code, used in DVB-ASI, and a 208 byte variant for ATSC (188-byte payload plus 20 byte forward error correction code): http://en.wikipedia.org/wiki/MPEG-2_transport_stream#Packet If all the above is correct, I think you're talking about 4 possible MPEG-TS muxer variants, only 2 of which we can generate at the moment.
I think the rationale for doing this via caps in the quicktime case was that there could be/are parsers/demuxer which will only accept one of the variant, but not others. Is this the case for these mpeg-ts variants as well, or will a spec-compliant parser/demuxer handle all variants as input?
Well the Playstation 3 demuxer/typefinder fails to recognize the no-AVCHD ts files automatically, so that is at least one example that the different variants are not fully interchangeable.
I knew you were going to say PS3 ;)
Let's not confuse everything here. The packet-size is outside of the scope of mpeg-ts. It's not compulsory (hell, if I want to add 20 bytes of padding after each packet, it's because of my transport medium. mpeg-ts demuxers know how to discard that). it would actually make sense to have a property on the muxer to specify the output packet size (>= 188). As for the variants, the idea is to give a hint as to what internal layout and/or specifications are being used. AVCHD/HDV have specific specifications regarding: * what kind of streams they contain * what bitrate * what layout * what interleave frequency * what private streams * ... That's what the variant means. One could add a variant for bluray meaning that the mpeg-ts stream either comes from a bluray disk/source or that the muxer is outputting mpeg-ts streams which sticks to the bluray mpeg-ts specifications. For info, the HDV specs are iec-61834-11. I have still to find the official AVCHD specifications.
Pasting these two bits of information here from the PS3 compliance bug - not as good as the official specs, but as close as we get atm: Further information on m2ts difference from normal mpeg TS: http://en.wikipedia.org/wiki/MPEG_transport_stream#Modifications_of_transport_stream_specification_for_random-access_media_.28M2TS.29 There is also a remuxing tool with GPL source code here which is supposed to do the right thing: http://forum.doom9.org/showthread.php?t=125447
for M2TS, those 4 extra bytes contain the PCR for out-of-order read/write. It is unclear whether they should apply to the packet before or after. Just checked quickly on some mts files I have here, and the value is monotonically increasing, except for the beginning and end. Having some specs regarding m2ts/avchd/hdv/bluray would *really* be nice to properly implement all of this... wikipedia isn't enough for this.
Preceding makes more sense to me - and the files I have all *start* with a timestamp as the first bytes, which would indicated preceding too.
the 'hdv' variant I suggested might be more properly named 'brv' or something similar as its Blu-Ray video
HDV is not the same thing as bluray. It's a camera standard with specifications. AVCHD is a subset of bluray.
ok, so we need 4 variants then? hdv, bluray, avchd and iso
What would the 'iso' one be ? If you mean the generic one, then it just has no variant.
Based on the discussion in bug 651543 I guess there is a variant setting through the packetsize caps, which do represent at least part of the difference between some of these variants. My suggestion would be that once we get the variants mentioned in this bug, which are more 'human readable', the packetsize one goes away as choosing the packetsize is then handled through choosing one of them.
Added 651805 as a dependency, I think it would be good if we got these variants created right away even if we know some of them might not be 100% correct from the outset. That way we can get fixes and patches for each variant, like in 651805 and have a clear idea how to merge them.
fwiw, I think we should use the official ids for the "variants". Variants are essentially defined by the presence of a REGISTRATION descriptor in the main loop of the PMT. The 32bit value contained in it is a (text) fourcc. Ex: GA94 for ATSC streams HDMV for bluray TSMV/TSHV for HDV DCII for some US cable variants ... which would give for example: video/mpegts, registration="HDMV" The full list of ID is here http://www.smpte-ra.org/mpegreg/mpegreg.html
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/11.