Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Sample data set for Supplement 149 (MPEG-4 AVC/H.264 Transfer Syntax)?

2,236 views
Skip to first unread message

Anders Granlund

unread,
Aug 12, 2013, 9:05:21 AM8/12/13
to
Hi,

I've been trying to find sample data sets for DICOM MPEG-4's (1.2.840.10008.1.2.4.102, 1.2.840.10008.1.2.4.103) without success.

Does anyone have such datasets to share?

Thanks,

/Anders

M1nd0nF1r3

unread,
Sep 15, 2014, 2:37:00 AM9/15/14
to
Dear Andres,

I have the same problem. Did you succeed to find sample data sets for DICOM MPEG-4's (1.2.840.10008.1.2.4.102, 1.2.840.10008.1.2.4.103)?

Kind regards, John

roniza

unread,
Sep 18, 2014, 5:13:22 AM9/18/14
to
We've just release a new build of RZDCX 2.04.2 with MPEG to DICOM functionality if that helps. You can insert an MPEG file to DICOM object in one command like this:

static void CreateVideo(string filename)
{
/// Create a DCXOBJ
IDCXOBJPtr obj(__uuidof(DCXOBJ));

/// Create an element pointer to place in the object for every tag
IDCXELMPtr el(__uuidof(DCXELM));

IDCXUIDPtr id(__uuidof(DCXUID));

rzdcxLib::ENCAPSULATED_VIDEO_PROPS videoProps;
videoProps.width = 352;
videoProps.Height = 288;
videoProps.PixelAspectRatioX = 4;
videoProps.PixelAspectRatioY = 3;
videoProps.FrameDurationMiliSec; // 40 msec = 25 FPS
videoProps.NumberOfFrames = 1600; // 1600 frames
videoProps.VideoFormat = rzdcxLib::MPEG2_AT_MAIN_LEVEL;
obj->SetVideoStream(filename.c_str(), videoProps);

The full example is here: http://dicomiseasy.blogspot.co.il/search/label/DICOM?max-results=7
And the download page is here: http://downloads.roniza.com/downloads/rzdcx/2.0.4.2/

José Antonio Pérez

unread,
Sep 25, 2014, 8:42:54 AM9/25/14
to
Hello,

I prepared just a few MPEG4 DICOM video samples some time ago.

You can download one of them here:
http://dicom.netpatia.com/video/MPEG4_720.dcm

TransferSyntaxUID: 1.2.840.10008.1.2.4.103
This is a 1280x720 HD video.


Hope you will find this one useful,

José Antonio Pérez
LinkedIn: http://goo.gl/lW17d

Mathieu Malaterre

unread,
Mar 25, 2015, 9:07:37 AM3/25/15
to
On Thursday, September 25, 2014 at 2:42:54 PM UTC+2, José Antonio Pérez wrote:
> Hello,
>
> I prepared just a few MPEG4 DICOM video samples some time ago.
>
> You can download one of them here:
> http://dicom.netpatia.com/video/MPEG4_720.dcm

It is missing (0028,0008) Number of Frames (among other things) which makes it non-trivial to support.

José Antonio Pérez

unread,
Mar 25, 2015, 4:53:44 PM3/25/15
to
There was a question recently posted on stackoverflow related to MPEG4 video where I explains the method that I followed in order to create this (and others) sample video.

http://stackoverflow.com/a/28737338/176974

Jörg Riesmeier provides a link to the relevant section in Part 5 of the DICOM standard. The "number of frames" field is not in the required fields.

http://medical.nema.org/medical/dicom/current/output/chtml/part05/sect_8.2.7.html

I provide also a link to the Visible Light Image IOD. You will see that the "number of frames" (0028, 0008) attribute shall be present in the Multi-frame Module (C.7.6.6) but not in the Cine Module (C.7.6.5)

http://medical.nema.org/medical/dicom/2014b/output/chtml/part03/sect_A.32.html#sect_A.32.7

So, in short, I don't think that any of the required attributes is missing in this sample file.

David Clunie

unread,
Mar 25, 2015, 10:34:58 PM3/25/15
to
Hi José

The SOP Class of your file is Video Photographic Image.

http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.32.7.2.html

The Multiframe Module is required.

http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.6.html

It contains Number of Frames, which is also required.

As a general rule, anything with a multi-frame bitstream requires
Number of Frames.

Or to put it another way, if Number of Frames is absent, that means
there is one frame.

BTW. All IODs that use the Cine Module also require the Multiframe Module.

There is no such thing as a Visible Light IOD per se; rather there is
a family of Visible Light IODs, each of which has specific requirements.
Some are named "video" and are multiframe, the others are not and are
single frame (and for the latter, if you sent an MPEG bit stream, it
would only be permitted to have one frame).

David.

PS. dciodvfy reports about MPEG4_720.dcm:

Warning - Missing attribute or value that would be needed to build
DICOMDIR - Study ID
Warning - Value dubious for this VR - (0x0010,0x0010) PN Patient's Name
PN [0] = <Test patient> - Retired Person Name form
Warning - Retired attribute - (0x0008,0x0000) UL Group Length
Warning - Retired attribute - (0x0010,0x0000) UL Group Length
Warning - Retired attribute - (0x0018,0x0000) UL Group Length
Warning - Retired attribute - (0x0020,0x0000) UL Group Length
Warning - Retired attribute - (0x0028,0x0000) UL Group Length
Warning - Retired attribute - (0x7fe0,0x0000) UL Group Length
Warning - Dicom dataset contains retired attributes
VideoPhotographicImage
Error - Missing attribute Type 2 Required
Element=<ReferringPhysicianName> Module=<GeneralStudy>
Error - Missing attribute Type 2C Conditional Element=<Laterality>
Module=<GeneralSeries>
Error - Missing attribute Type 2 Required Element=<Manufacturer>
Module=<GeneralEquipment>
Error - Missing attribute Type 2C Conditional
Element=<PatientOrientation> Module=<GeneralImage>
Error - Attribute present when condition unsatisfied (which may not be
present otherwise) Type 1C Conditional Element=<FrameTime> Module=<Cine>
Error - Missing attribute Type 1 Required Element=<NumberOfFrames>
Module=<MultiFrame>
Error - Missing attribute Type 1C Conditional
Element=<FrameIncrementPointer> Module=<MultiFrame>
Error - Missing attribute Type 2 Required
Element=<AcquisitionContextSequence> Module=<AcquisitionContext>
Error - Missing attribute Type 2 Required
Element=<LossyImageCompression> Module=<VLImage>

Mathieu Malaterre

unread,
Mar 26, 2015, 5:36:56 AM3/26/15
to
Hi David,

On Thursday, March 26, 2015 at 3:34:58 AM UTC+1, David Clunie wrote:
[...]
> The Multiframe Module is required.

Thanks for the help here !

Do you think you can get ETIAM (or others?) to provide DICOM MPEG-2/MPEG-4 samples which would ideally be stored on ftp://dicom.nema.org/MEDICAL/Dicom/DataSets/

I remember an old post where they provided some MPEG-2 samples (BTW there was an issue with the Number of Frames vs the actual number of frames in the MPEG-2 stream).

That would be of tremendous help IMHO.

Regards.

Mathieu Malaterre

unread,
Mar 27, 2015, 4:15:19 AM3/27/15
to
On Wednesday, March 25, 2015 at 9:53:44 PM UTC+1, José Antonio Pérez wrote:
[...]
> So, in short, I don't think that any of the required attributes is missing in this sample file.

José,

Could you also comment on the following (using avprobe):

[...]
Stream #0.1(und): Audio: aac, 44100 Hz, stereo, s16, 192 kb/s
[...]

If my reading of the DICOM standard is correct (http://medical.nema.org/medical/dicom/current/output/chtml/part05/sect_8.2.7.html):

Excerpt:

AAC
Maximum bit rate: 640kbps
Sampling frequency: 48kHz
Bits per sample: 16, 20 or 24 bits
Number of channels: 2 or 5.1 channels

I believe that the sampling rate of 44100 Hz in your sample is illegal as per DICOM. Could someone confirms this ?

Regards
Message has been deleted

José Antonio Pérez

unread,
Apr 7, 2015, 3:56:22 AM4/7/15
to
Hi again,

I have made some changes to the DICOM video test file:

- Added Study ID
- Group Length data elements are not crated anymore
- Added attributes from the MultiFrame module
- Added other missing attributes
- Changed Transfer Syntax UID from 1.2.840.10008.1.2.4.103 to 1.2.840.10008.1.2.4.102 (MPEG-4 AVC/H.264 High Profile / Level 4.1), since this kind of video (1280x720 @29.97 fps) is not present in the table of BD-compatible formats

The resulting file has been tested with dciodvfy (dicom3tools_1.00.snapshot.20150319151618) with no error or warning messages right now. The resulting part 10 DICOM file is available in DropBox:
https://www.dropbox.com/s/0jmh0ob4vftd9o0/test_720.dcm?dl=0

md5sum: 02ffc5341349917a981ae8ad9d53aa2d

The stackoverflow answer has been also updated:
http://stackoverflow.com/a/28737338/176974

On Thursday, March 26, 2015 at 3:34:58 AM UTC+1, David Clunie wrote:

José Antonio Pérez

unread,
Apr 7, 2015, 4:25:00 AM4/7/15
to
Hello,

There are some things that are still not clear for me:

In part 05, sect 8.2.7 (http://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_8.2.7.html) we can find this sentence in "note 2":

"When decompressing, should the characteristics explicitly specified in the compressed data stream be inconsistent with those specified in the DICOM Data Elements, those explicitly specified in the compressed data stream should be used to control the decompression. The DICOM data elements, if inconsistent, can be regarded as suggestions as to the form in which an uncompressed data set might be encoded."

In this test case, I have just removed the audio stream (it was silent, in fact), but in order to generate this type of contents, it would be interesting to know if the audio specifications are normative or rather they are more like suggestions to follow.


Another question that I find a bit confusing:

Note 3: "The frame rate of the acquiring camera for '30 Hz HD' MPEG-4 AVC/H.264 may be either 30 or 30/1.001 (approximately 29.97) frames/sec." ... "This may lead to small inconsistencies between the video timebase and real time. The relationship between frame rate and frame time is shown in Table 8-5."

That table 8-5 shows values of Frame Rate: 30, Frame Time: 33.33

Note 4: "...A frame rate of 29.97 frames per second corresponds to a frame time of 33.367 ms."

So, I am not sure about which ones are the correct values. I have chosen the values FR: 30 and FT: 33.33


And finally, the information about the number of frames:

The information about the number of frames is not present in h264 headers. In order to get such information, is necessary either to estimate it (duration and frame rate are usually known for the original video file) or parse the whole video stream to get the exact number.


What would be the most correct option? Would it be acceptable to have this field empty, assuming just one frame, even knowing this is not right?


José Antonio

Mathieu Malaterre

unread,
Apr 7, 2015, 6:18:46 AM4/7/15
to
On Tuesday, April 7, 2015 at 9:56:22 AM UTC+2, José Antonio Pérez wrote:
> https://www.dropbox.com/s/0jmh0ob4vftd9o0/test_720.dcm?dl=0
>
> md5sum: 02ffc5341349917a981ae8ad9d53aa2d

According to `ffprobe` you are using "High, level 3.1", while only "High Profile / Level 4.1" is legal.

Since your dataset may be scrutinized by DICOM experts, I would change the Acquisition Date/Time to match the value from the MP4 stream (technically this is not require, but since you left the creation time I think this make sense):

In MP4:

Metadata:
creation_time : 2013-08-12 18:38:52

While in DICOM dataset:

(0008,0022) DA [20140505] # 8, 1 AcquisitionDate
(0008,0032) TM [135531] # 6, 1 AcquisitionTime

Thanks for your efforts !

José Antonio Pérez

unread,
Apr 7, 2015, 8:07:32 AM4/7/15
to
Hi,

On Tuesday, April 7, 2015 at 12:18:46 PM UTC+2, Mathieu Malaterre wrote:
> On Tuesday, April 7, 2015 at 9:56:22 AM UTC+2, José Antonio Pérez wrote:
> ...
> According to `ffprobe` you are using "High, level 3.1", while only "High Profile / Level 4.1" is legal.

I will have a look at this. I will try to obtain a video according to the requirements.

> Since your dataset may be scrutinized by DICOM experts, I would change the Acquisition Date/Time to match the value from the MP4 stream

In this case, I will have to change also the "AnatomicRegionSequence", since I coded it as "heart", but the video looks more something like a brain :-)

Thanks for your feedback!

Mathieu Malaterre

unread,
Apr 7, 2015, 10:34:48 AM4/7/15
to
On Tuesday, April 7, 2015 at 2:07:32 PM UTC+2, José Antonio Pérez wrote:
> Hi,
>
> On Tuesday, April 7, 2015 at 12:18:46 PM UTC+2, Mathieu Malaterre wrote:
> > On Tuesday, April 7, 2015 at 9:56:22 AM UTC+2, José Antonio Pérez wrote:
> > ...
> > According to `ffprobe` you are using "High, level 3.1", while only "High Profile / Level 4.1" is legal.
>
> I will have a look at this. I will try to obtain a video according to the requirements.

ffmpeg -i in.mp4 -vcodec h264 -profile:v high -level:v 4.1 out.mp4
ffprobe -show_streams out.mp4 | grep level

(this removes creation metadata BTW)
Message has been deleted
0 new messages