PSP PMF audio

[Carl Eugen Hoyos]

(videolan ticket 10184)
PMF files apparently contain audio (the file size compared to the size of the video stream also indicates this), FFmpeg does not support decoding audio.
Samples are in ​http://samples.ffmpeg.org/PSMF/

$ ffmpeg -i EV01_01_0500D.PMF
ffmpeg version N-59262-g70d6ce7 Copyright (c) 2000-2013 the FFmpeg developers
  built on Dec 21 2013 10:08:10 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl --enable-libx264
  libavutil      52. 58.101 / 52. 58.101
  libavcodec     55. 45.103 / 55. 45.103
  libavformat    55. 22.100 / 55. 22.100
  libavdevice    55.  5.102 / 55.  5.102
  libavfilter     4.  0.100 /  4.  0.100
  libswscale      2.  5.101 /  2.  5.101
  libswresample   0. 17.104 /  0. 17.104
  libpostproc    52.  3.100 / 52.  3.100
Input #0, mpeg, from 'EV01_01_0500D.PMF':
  Duration: 00:00:12.95, start: 1.000000, bitrate: 1130 kb/s
    Stream #0:0[0x1e0]: Video: h264 (Main), yuv420p(tv, smpte170m), 480x272 [SAR 1:1 DAR 30:17], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
At least one output file must be specified

The mpeg startcode of the unidentified audio stream is 0, packet size is (nearly) constant 2019 bytes, the packets start alternating with "0x00 0x00", "0x00 0x01" and "0x00 0x02"

[Carl Eugen Hoyos]

JEEB (also) believes that the audio is either ATRAC3 or ATRAC3+.

For the sample I will attach, the second byte of the audio packets alternates (randomly?) from 0x00 to 0x05

[Carl Eugen Hoyos]

Initial patch is in https://ffmpeg.org/pipermail/ffmpeg-devel/2014-December/166169.html

[bazz]

Regarding the patch, I have tried it with an old commit ~Dec 2014 and also with the latest master branch on the FFmpeg github. I seem to get the same results on both versions.

The FFMPEG PMF samples appear to play fine. But, I have my own samples that do not *fully* play with the patch. However, if you watch my PMF file on an unpatched version of ffplay, you can see the full video (without audio of course), so there is some issue in the ATRAC3P "process" (for lack of better words) that is causing ffplay to lock up.

See for yourself!
​http://botb.club/~bazz/vid8.pmf

Running ffplay with -v debug did not reveal any hints as far as I could tell.

I don't know much about ATRAC3(P) so I hope this helps someone move further in solving this issue. I for one, will try to add further debug printouts to the ATRAC3P code to maybe provide a hint.

Lastly, thank you to the patch author for getting us this far!

I understand this patch is rather old, but I'm glad it still works (somewhat) and I hope we can move this further along.

[bazz]

PMF freeze fix, ffmpeg fail fix

[bazz]

Solution Found for PMF Freezing

I have discovered why the ATRAC3+ parsing failed on my PMF sample and have made a solution.

The problem was that the ATRAC3+ parser did not properly process a buffer that only contains one full header.

I am attaching both a complete patch (parser.diff), and a partial patch that shows only my changes from Maxim's original patch (https://ffmpeg.org/pipermail/ffmpeg-devel/2014-December/166169.html)

ffmpeg Mod to Transcode PMF

Using the latest FFmpeg from Github (7d17d31db4322b0c5e89f889ebf32af9ca2d91a9),
ffplay works out of the box with the PMF patch. But, I found that I have to modify one more thing for the ffmpeg tool to work. Let me detail the issue, then provide the solution.

Here is a log of an attempt to transcode a PMF to avi.

bazz@awesomesauce ~/Code/FFmpeg $ ./ffmpeg -i ~/3rd/008.pmf -vcodec copy /tmp/derp.avi 
ffmpeg version git-2016-09-23-ae2cd8a Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.9.3 (Gentoo 4.9.3 p1.5, pie-0.6.4)
  configuration: 
  libavutil      55. 30.100 / 55. 30.100
  libavcodec     57. 57.101 / 57. 57.101
  libavformat    57. 50.100 / 57. 50.100
  libavdevice    57.  0.102 / 57.  0.102
  libavfilter     6. 62.100 /  6. 62.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
[atrac3plus @ 0x3fbedc0] block_align is not set
Input #0, mpeg, from '/home/bazz/3rd/008.pmf':
  Duration: 00:00:50.48, start: 0.945211, bitrate: 1320 kb/s
    Stream #0:0[0x1e0]: Video: h264 (Main), yuv420p(tv, smpte170m), 480x272 [SAR 1:1 DAR 30:17], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x1bd0]: Audio: atrac3p, 44100 Hz, stereo, 128 kb/s
[abuffer @ 0x404db40] Unable to parse option value "(null)" as sample format
    Last message repeated 1 times
[abuffer @ 0x404db40] Error setting option sample_fmt to value (null).
[graph 0 input from stream 0:1 @ 0x404da40] Error applying options to the filter

The issue stems from the fact that block_align is not set, because in libavcodec/atrac3plusdec.c:147 atrac3p_decode_init() will fail in this case. I can say that commenting out the block_align return statement allows ffmpeg to once again apparently run flawlessly with PMF. Let it be known here that the PMF parser constantly updates the block_align anyways.

Thus, I'm not sure if removing the logic check produces issues for other users of ATRAC3+, but it at least provides with me a usable latest version of FFmpeg for the purpose of working with these PMF videos.

Anyhow, I'm attaching this patch as "ffmpeg.diff"

Note: Using a ~Dec 2014 commit of FFmpeg did not require this modification, but
I did not discover why.

Closing Remarks

Check out the new attachment I added to this ticket bazz_patches.zip Remember, I'm using the latest FFmpeg from Github (7d17d31db4322b0c5e89f889ebf32af9ca2d91a9)

EDIT: I forgot to mention this technical note; The reason why I no longer fail the new ATRAC3P parser on a "2nd frame portion found but the 1st one is missing!" error, is because this frequently occurs when "skimming" through the video in ffplay (using the left/right arrow keys). By not forcing the parser to fail in this circumstance, the video successfully seeks to the new position without quitting. In another note, Video (not audio) will be slower for a second or two after "skimming" in ffplay, but it syncs up appropriately perfectly every time in my experience. IIRC, this kind of slowdown is not a surprise when seeking in other formats via ffplay anyways.

Thank you for reading!

[Misty De Meo]

I noticed that the original patch in this ticket fails on parsing MPS files, which is a related format also used on the PSP. MPS files are MPEG files used on PSP Video discs. They lack the PSMF header used by .pms files, and so the special casing in the original patch fails to support their audio. I've attached a patch that fixes this by unconditionally reading a new byte for the startcode for PRIVATE_STREAM_1 sections, and doing the comparison on that to find ATRAC-3 streams. In my testing, it works fine for both MPS and PSMF files.

Is there anything else that devs would like to see before these patches can be accepted?

[Misty De Meo]

Fix parsing of PSP video with ATRAC-3 audio when no PSMF header is present