Opened 9 years ago
Last modified 5 years ago
#3233 new enhancement
PSP PMF audio
Reported by: | Carl Eugen Hoyos | Owned by: | |
---|---|---|---|
Priority: | wish | Component: | undetermined |
Version: | git-master | Keywords: | mpegps pmf atrac3 atrac3p videolan |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
(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"
Attachments (3)
Change History (9)
comment:1 by , 9 years ago
Keywords: | mpegps atrac3 added |
---|
by , 9 years ago
Attachment: | 00002_cut.MPS added |
---|
comment:2 by , 9 years ago
Keywords: | atrac3p added |
---|
comment:3 by , 7 years ago
Initial patch is in https://ffmpeg.org/pipermail/ffmpeg-devel/2014-December/166169.html
comment:4 by , 7 years ago
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.
comment:5 by , 7 years ago
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!
comment:6 by , 5 years ago
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?
by , 5 years ago
Attachment: | 0001-Fix-detecting-ATRAC3-audio-from-MPS-files.patch added |
---|
Fix parsing of PSP video with ATRAC-3 audio when no PSMF header is present
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