Opened 10 years ago

Closed 9 years ago

#1436 closed defect (invalid)

Panasonic P2 MXFs (at least DVCPRO HD) from camera do not play

Reported by: tbartdev@… Owned by: reimar
Priority: normal Component: vd
Version: HEAD Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

Description

The video only MXF file from a Panasonic P2HD camera does not play (mplayer says end of file after the first frame, which is correctly decoded and shown, although the pixel aspect ratio is not corrected: the camera records them in a rectangular format whereas mplayer plays them square)
Panasonic's way of saving files is the following:

tbart@black_knight ~/orpheus/video_tech/container/mxf/p2/p2cardfromcamera $ ls -lsa CONTENTS/*
CONTENTS/AUDIO:
total 1168

0 drwxr-xr-x 2 tbart tbart 176 26. Feb 15:42 .
0 drwxr-xr-x 8 tbart tbart 192 26. Feb 15:42 ..

292 -rwxr--r-- 1 tbart tbart 297952 26. Feb 15:23 0007WV00.MXF
292 -rwxr--r-- 1 tbart tbart 297952 26. Feb 15:23 0007WV01.MXF
292 -rwxr--r-- 1 tbart tbart 297952 26. Feb 15:23 0007WV02.MXF
292 -rwxr--r-- 1 tbart tbart 297952 26. Feb 15:23 0007WV03.MXF

CONTENTS/CLIP:
total 4
0 drwxr-xr-x 2 tbart tbart 80 25. Mär 13:44 .
0 drwxr-xr-x 8 tbart tbart 192 26. Feb 15:42 ..
4 -r--r--r-- 1 tbart tbart 3057 25. Mär 13:44 0007WV.XML

CONTENTS/ICON:
total 16

0 drwxr-xr-x 2 tbart tbart 80 25. Mär 13:39 .
0 drwxr-xr-x 8 tbart tbart 192 26. Feb 15:42 ..

16 -rw-rw-rw- 1 tbart tbart 14454 25. Mär 13:39 0007WV.BMP

CONTENTS/PROXY:
total 0
0 drwxr-xr-x 2 tbart tbart 48 26. Feb 15:42 .
0 drwxr-xr-x 8 tbart tbart 192 26. Feb 15:42 ..

CONTENTS/VIDEO:
total 38886

0 drwxr-xr-x 2 tbart tbart 80 26. Feb 15:42 .
0 drwxr-xr-x 8 tbart tbart 192 26. Feb 15:42 ..

38886 -rwxr--r-- 1 tbart tbart 39776992 26. Feb 15:23 0007WV.MXF

CONTENTS/VOICE:
total 0
0 drwxr-xr-x 2 tbart tbart 48 26. Feb 15:42 .
0 drwxr-xr-x 8 tbart tbart 192 26. Feb 15:42 ..

whereas:
1) The single audio files (PCM essence wrapped in MXF OP-Atom) play fine in mplayer
2) The video MXF OP-Atom consists of the following:
a) NO separate audio streams *in the MXF*
b) 1 DV-DIF stream consisting of DVCPROHD video *and 4 audio streams* (which are *NOT* referenced by the MXF); this means that EDIUS for example, a Windoze based NLE, only plays the video part of it. This is the way Panasonic wants it to be. I contacted Matt Beard, the MXF specificator himself, about this and he stated that the problem was that DV-DIF cannot exist without audio data. One could pad it with nonsense, but Panasonic seemingly found it more sensible to put actual data into it. So yes, the extra audio MXFs are more or less redundant.
But watch out: I just found out this is only valid for 1080i material; with 720p50 (at least) the sound in the DV-DIF is broken.

EDIUS provides a mechanism to mux the audio files into the video MXF to have only one file that is then also playable in EDIUS, with video and audio.
!!This file plays fine in mplayer as well!!

The original MXF was unwrapped using freeMXF.org's mxfsplit, resulting in the dif stream. It needs to be renamed to .dif or else mplayer will try to decode it as RawDV (the result might be funny while on acid but is barely usable in "productive" environments ;-> )

I'll upload a clip that directly comes from the camera, truncated to 5MB (which might give problems on itself, but the guidelines say to do so) at the following url:

ftp://upload.mplayerhq.hu/MPlayer/incoming/p2mxf/camsvidonly.mxf

(the FTP server acts really strangely; no dir listings there, you have to work "blindly")

!! this is not the same MXF as the one I stated in the other bug report !!
this one is DVCPRO 720p50 and the extracted DV-DIF has audio problems as mentioned above. But the symptom of not playing the video (only the first frame) is just the same

This bug is (somewhat) related to:
http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1435

ah.. and by the way: http://freemxf.org/ has some sample MXF files that also do not play with mplayer...

Just a shot in the dark: clip wrapped vs. frame wrapped at least seems to be included in this problem..

Change History (7)

comment:1 Changed 10 years ago by compn

thank you for the samples. we use ffmpeg (libavformat) to demux mxf
so if you want , we can take these samples and bugs to http://roundup.ffmpeg.org where they will be reviewed properly :)

comment:2 Changed 10 years ago by compn

ok i moved this bug over to ffmpeg:
https://roundup.ffmpeg.org/roundup/ffmpeg/issue953

since the ffmpeg devels dont read the mplayer bugzilla :)

comment:3 Changed 10 years ago by tbartdev@…

(In reply to comment #2)

ok i moved this bug over to ffmpeg:
https://roundup.ffmpeg.org/roundup/ffmpeg/issue953

since the ffmpeg devels dont read the mplayer bugzilla :)

sorry, i forgot to have a look at this bug. I'll continue there, if there's anything I can do...

comment:4 Changed 10 years ago by compn

oops, i got lazy and tried to put three bugs into one report
here is the new bug with your sample file :)

https://roundup.ffmpeg.org/roundup/ffmpeg/issue974

comment:5 Changed 9 years ago by compn

  • Owner changed from r_togni@… to reimar

comment:6 Changed 9 years ago by reimar

Until that ffmpeg bug is fixed (needs a DV parser I guess), this can be played with -lavfdopts format=dv

comment:7 Changed 9 years ago by reimar

  • Resolution set to invalid
  • Status changed from new to closed

INVALID because this is an issue in FFmpeg, not really much we can do about it.

Note: See TracTickets for help on using tickets.