GNOME Bugzilla – Bug 727731
tsdemux: add support for chinese AVS video codec
Last modified: 2015-06-02 11:52:35 UTC
Created attachment 273689 [details] [review] tsdemux: add support for chinese AVS video codec Some chinese terrestrial broadcasters use CAVS video codec embedded in MPEG-TS file. Since we have a decoder provided by libav, we could handle the stream in tsdemux. At this moment, I wrote a dirty patch which add support of this stream type in tsdemux. However, they use a stream_type id (0x42) which is within the reserved range of the ISO. So it could be better to add a DTMB/CTTB (Chinese standard for broadcasting) specific files like the ones we have for ATSC, DVB-T... But I don't know yet how to determine if the TS stream is DTMB/CTTB or not, since registration_descriptor seems to be empty. Also I "create" a new mime-type: "video/x-cavs" Anyway, I attached a TS file which contains CAVS video track, my dirty patch for tsdemux and a patch for gst-libav to map CAVS codec to video/x-cavs.
Created attachment 273690 [details] [review] avcodecmap: Use video/x-cavs mime type instead of x-gst-av-cavs
Created attachment 273691 [details] Exemple of CTTB stream containing CAVS File may be too short to be decoded, however it contains program list and codec id.
Created attachment 285991 [details] [review] tsdemux: enable Chinese AVS video in MPEG-TS Rebased against master branch.
Created attachment 285993 [details] [review] avcodecmap: Use video/x-cavs mime type instead of video/x-gst-av-cavs Rebased against master branch.
(In reply to comment #4) > Created an attachment (id=285993) [details] [review] > avcodecmap: Use video/x-cavs mime type instead of video/x-gst-av-cavs > > Rebased against master branch. Do you know of any other container format that might contain that codec ? If so we should also update those other demuxer/muxer.
AVS video codec can also be found in AVS transport system. I just found that gst-libav expose a demuxer for AVS, I will update my patch for it. For others containers, I don't know if they can have the codec.
There might also be a mapping for MPEG-PS but we don't support that yet.
yah, looks like both TS and PS use 0x42 as the stream-type identifier. ISO seems to use FOURCC('a', 'v', 's', '2') RIFF(avi) FOURCC ('C', 'A', 'V', 'S') That being said, the patch for adding the definition in the mpeg-ts lib should not add it to the list of official stream types. Create a new enum GstMpegtsMiscStreamType for stream types that aren't in any specifications (I'm sorry, but after digging a lot ... I still haven't seen an official specifications where 0x42 is indicated).
Created attachment 286013 [details] [review] tsdemux: enable Chinese AVS video in MPEG-TS (In reply to comment #8) > That being said, the patch for adding the definition in the mpeg-ts lib should > not add it to the list of official stream types. > Create a new enum GstMpegtsMiscStreamType for stream types that aren't in any > specifications (I'm sorry, but after digging a lot ... I still haven't seen an > official specifications where 0x42 is indicated). Yes, this is not official. So I agreed with your proposal of creating a new type. This patch do it and I move CAVS to the end of the switch case in the tsdemux because I think the official id should have the priority.
Review of attachment 286013 [details] [review]: It doesn't matter where you put the case in a switch/case :) Anyway, looks good, can you just split it in two (one for the lib part, another for the demuxer)
There's another bug #653604 for AVS support in quicktime FWIW. Last time I looked at AVS I was wondering if the different codec IDs need to be differentiated at the caps level (for hardware decoders or somesuch), if they represent different versions/profiles/whatnot.
(In reply to comment #10) > Review of attachment 286013 [details] [review]: > > It doesn't matter where you put the case in a switch/case :) > > Anyway, looks good, can you just split it in two (one for the lib part, another > for the demuxer) No problem for the split. (In reply to comment #11) > There's another bug #653604 for AVS support in quicktime FWIW. > > Last time I looked at AVS I was wondering if the different codec IDs need to be > differentiated at the caps level (for hardware decoders or somesuch), if they > represent different versions/profiles/whatnot. In the other bug, it's seems codec id is AVS2 which is the most recent Chinese AVS video codec and is intended to be a competitor of H265 I take the CAVS name/mime-type from the libav/ffmpeg name and it stands for AVS1-P2 standards. Moreover, libav/ffmpeg use avs mime-type to describe the transport stream.
Created attachment 286018 [details] [review] mpegts: add Chinese AVS stream id to a miscellaneous stream type enum Patch for the mpegts library
Created attachment 286019 [details] [review] tsdemux: enable Chinese AVS video stream Patch for the tsdemux
friendly ping :)
I just added preliminary support to DTMB to dvbsrc. (b0ade1a317206f58) As I understand CAVS it's used in combination with it, pushing this forward would allow testing live capture/playback! I understand there are no further objections on pushing this to master? Edward? Tim?
I think the avcodec patch is fine, and the tsdemux patch would definitely be fine changed to use 0x42 instead of the new enum, and then you could leave the bikeshedding of the new API/enum open. I think it's weird to add that Misc enum. Not sure how likely it is we'll ever get anything official for this, since the whole AVS codec/mux thing is an explicit effort to create something not subject to MPEG licensing (as I understand it) ;) It's on wikipedia ;)
(In reply to Tim-Philipp Müller from comment #17) > I think the avcodec patch is fine, and the tsdemux patch would definitely be > fine changed to use 0x42 instead of the new enum, and then you could leave > the bikeshedding of the new API/enum open. It could be a first step. I will prepared a patch to do it that way. > > I think it's weird to add that Misc enum. Not sure how likely it is we'll > ever get anything official for this, since the whole AVS codec/mux thing is > an explicit effort to create something not subject to MPEG licensing (as I > understand it) ;) It's on wikipedia ;) That's the spirit :) In my opinion, Chinese AVS in MPEG-TS will never be official. The funny fact is that AVS group seems to have a registration id but they don't use it.
Created attachment 300209 [details] [review] tsdemux: enable Chinese AVS video stream (without enumeration) Here is the version of the patch for tsdemux without enumeration
Does this all actually work for you with gst-libav? If I apply the gst-libav patch, I get an avdec_avs with fake caps and no avdec_cavs. If I use CODECID_AVS for the cavs mapping it errors out (not entirely unexpectedly).
(In reply to Tim-Philipp Müller from comment #20) > Does this all actually work for you with gst-libav? > > If I apply the gst-libav patch, I get an avdec_avs with fake caps and no > avdec_cavs. If I use CODECID_AVS for the cavs mapping it errors out (not > entirely unexpectedly). It's a bit tricky but there is a difference in ffmpeg/libav between avs and cavs: the former is a format used in a computer game and the latter is the chinese standard. I just check and in fact cavs decoder is explicitely disabled in gst-libav embedded libav configure command line. I don't find why it has been disabled but I think we can safely enable it.
Created attachment 300260 [details] [review] gst-libav: configure: don't disable cavs decoder Remove the explicit configure command line parameter to disable cavs decoder in embedded libav.
Aurélien, any chance you could make available a sample that actually produces some output ? :)
(In reply to Tim-Philipp Müller from comment #23) > Aurélien, any chance you could make available a sample that actually > produces some output ? :) Of course :) Here is a small capture from China televion: http://www.darkosphere.fr/tmp/gstreamer/727731/27394-extract.ts To play it, you can use following pipeline: gst-launch-1.0 filesrc location=~/public/videos/ts/27394-extract.ts ! tsdemux ! avdec_cavs ! autovideosink
Thanks. I note that mplayer seems to get more frames out of this than we do, we're missing about half a second (1 gop?) or so at the beginning. commit 00ff477f2989d26655e2398708d5571b81a9f784 Author: Aurélien Zanelli <aurelien.zanelli@parrot.com> Date: Fri Sep 12 09:44:16 2014 +0200 avcodecmap: Use video/x-cavs mime type instead of video/x-gst-av-cavs More generic mime-type which can be used by other decoders than libav. https://bugzilla.gnome.org/show_bug.cgi?id=727731 commit 3fe87b31f6785e26e100387ced5ede8d79f41448 Author: Aurélien Zanelli <aurelien.zanelli@parrot.com> Date: Wed Mar 25 10:24:52 2015 +0100 configure: don't disable Chinese AVS (cavs) decoder It enables GStreamer to decode Chinese AVS video streams. Also fix indentation. https://bugzilla.gnome.org/show_bug.cgi?id=727731 commit 633b4db556c7f9eaaa2819df6023013c533e2157 Author: Aurélien Zanelli <aurelien.zanelli@parrot.com> Date: Tue Mar 24 15:17:16 2015 +0100 tsdemux: enable Chinese AVS video stream Chinese broadcaster encapsulate AVS video codec into MPEG2-TS. They use the stream_id 0x42 to identify AVS video streams. It should be noted that this id is currently within the ISO reserved range, hence it's utilisation is unofficial. https://bugzilla.gnome.org/show_bug.cgi?id=727731 commit c0f55ecf4dca509732b8986cf010e99ac4a8dcf2 Author: Tim-Philipp Müller <tim@centricular.com> Date: Tue Jun 2 12:47:50 2015 +0100 pbutils: add description for video/x-cavs caps https://bugzilla.gnome.org/show_bug.cgi?id=727731