Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2
These email issues made me forgot to tell an important thing... That new FPS patch is meant to be applied right after this: avformat/psxstr: fix unknown sector type 00/80 a96d556baaf7cb71babad96238eadb532d02f3a6 i.e. not over the previous FPS patch attempt: avformat/psxstr: basic FPS detection instead of fixed value 464243adac7abfa9b926a1faf6f59515661efa7f I think we're good now :) -- Original Message -- >From "aybe aybe" To "FFmpeg development discussions and patches" Date 1/16/2024 3:39:09 PM Subject Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2 >Lol, I told you I was struggling with emClient, it decided to send .eml as >.url... > >Here are the patches, hopefully! > >[FFmpeg-devel] [PATCH 1/2] avformat/psxstr: infer video FPS using sector LBA >https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/319701.html > >[FFmpeg-devel] [PATCH 2/2] avformat/psxstr: update fate checksums >https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/319702.html > >-- Original Message -- >From "aybe" mailto:aybe@hotmail.com>> >To "FFmpeg development discussions and patches" >mailto:ffmpeg-devel@ffmpeg.org>> >Date 1/16/2024 3:32:36 PM >Subject Re[2]: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 >is like STRv2 > >Modern email clients like to do stuff they're told not to... > >The link I meant previously: https://github.com/aybe/FFmpeg-PSX-STR-tests > > >-- Original Message -- >From "aybe aybe" >mailto:aybe.one-at-hotmail@ffmpeg.org>> >To "FFmpeg development discussions and patches" >mailto:ffmpeg-devel@ffmpeg.org>> >Date 1/16/2024 3:27:16 PM >Subject Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is >like STRv2 > >The new patch appears to work, stuff is synchronized, except: >- 30 FPS video still seen as 150FPS by VLC >- 15 FPS video emits tons of "[vost#0:0/rawvideo @ 0269b580] Clipping >frame in rate conversion by 0.199989" > >As for the corrupt samples, been able to find the original sources: > >- the first is good old Descent >- was cut at exactly 2MB >- works in FFmpeg >- the second is Ridge Racer Type 4 >- bad/incomplete extract with a tool that added "RIFFCDXA" header for >whatever reason >- does NOT work in FFmpeg, comprised of 38 audio streams + 2 video streams >(only decodes some audio then aborts) >- but if I extract the relevant section from it, then works in FFmpeg > >New videos, samples, logs: >https://github.com/aybe/FFmpeg-PSX-STR-tests > >-- Original Message -- >From "Michael Niedermayer" >mailto:mich...@niedermayer.cc><mailto:mich...@niedermayer.cc>> >To "FFmpeg development discussions and patches" >mailto:ffmpeg-devel@ffmpeg.org><mailto:ffmpeg-devel@ffmpeg.org>> >Date 1/16/2024 12:42:49 AM >Subject Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is >like STRv2 > >On Mon, Jan 15, 2024 at 04:14:46PM +, aybe aybe wrote: >Hi! > >I just tried what you've suggested, using 150 and setting AVPacket->pts using >sector MSF as LBA. > >The results are somewhat mixed: > >- NTSC video: A/V synchronized but is now seen as 120 FPS by VLC >- PAL video: A/V not synchronized anymore but still seen as 25 FPS by VLC > >can you send the patch for this plus links to one sample for both cases ? > >id like to take a look > >thx > >[...] >-- >Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > >The greatest way to live with honor in this world is to be what we pretend >to be. -- Socrates >___ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >To unsubscribe, visit link above, or email >ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2
Lol, I told you I was struggling with emClient, it decided to send .eml as .url... Here are the patches, hopefully! [FFmpeg-devel] [PATCH 1/2] avformat/psxstr: infer video FPS using sector LBA https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/319701.html [FFmpeg-devel] [PATCH 2/2] avformat/psxstr: update fate checksums https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/319702.html -- Original Message -- >From "aybe" mailto:aybe@hotmail.com>> To "FFmpeg development discussions and patches" mailto:ffmpeg-devel@ffmpeg.org>> Date 1/16/2024 3:32:36 PM Subject Re[2]: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2 Modern email clients like to do stuff they're told not to... The link I meant previously: https://github.com/aybe/FFmpeg-PSX-STR-tests ------ Original Message -- >From "aybe aybe" >mailto:aybe.one-at-hotmail@ffmpeg.org>> To "FFmpeg development discussions and patches" mailto:ffmpeg-devel@ffmpeg.org>> Date 1/16/2024 3:27:16 PM Subject Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2 The new patch appears to work, stuff is synchronized, except: - 30 FPS video still seen as 150FPS by VLC - 15 FPS video emits tons of "[vost#0:0/rawvideo @ 0269b580] Clipping frame in rate conversion by 0.199989" As for the corrupt samples, been able to find the original sources: - the first is good old Descent - was cut at exactly 2MB - works in FFmpeg - the second is Ridge Racer Type 4 - bad/incomplete extract with a tool that added "RIFFCDXA" header for whatever reason - does NOT work in FFmpeg, comprised of 38 audio streams + 2 video streams (only decodes some audio then aborts) - but if I extract the relevant section from it, then works in FFmpeg New videos, samples, logs: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Faybe%2FFFmpeg-PSX-STR-tests=05%7C02%7C%7Cc7debed92bce42a5bcd908dc169f43bd%7C84df9e7fe9f640afb435%7C1%7C0%7C638410120640174537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2Faq1Hcn5X%2FVCvtVi5GO6Jes7mrPUCeZyrIZvDiAj6lw%3D=0 -- Original Message -- >From "Michael Niedermayer" >mailto:mich...@niedermayer.cc><mailto:mich...@niedermayer.cc>> To "FFmpeg development discussions and patches" mailto:ffmpeg-devel@ffmpeg.org><mailto:ffmpeg-devel@ffmpeg.org>> Date 1/16/2024 12:42:49 AM Subject Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2 On Mon, Jan 15, 2024 at 04:14:46PM +, aybe aybe wrote: Hi! I just tried what you've suggested, using 150 and setting AVPacket->pts using sector MSF as LBA. The results are somewhat mixed: - NTSC video: A/V synchronized but is now seen as 120 FPS by VLC - PAL video: A/V not synchronized anymore but still seen as 25 FPS by VLC can you send the patch for this plus links to one sample for both cases ? id like to take a look thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avformat/psxstr: update fate checksums
Signed-off-by: aybe --- tests/ref/fate/psx-str-demux | 178 +-- 1 file changed, 89 insertions(+), 89 deletions(-) diff --git a/tests/ref/fate/psx-str-demux b/tests/ref/fate/psx-str-demux index 18a21b0bb6..0a31c44323 100644 --- a/tests/ref/fate/psx-str-demux +++ b/tests/ref/fate/psx-str-demux @@ -1,4 +1,4 @@ -#tb 0: 1/15 +#tb 0: 1/150 #media_type 0: video #codec_id 0: mdec #dimensions 0: 320x240 @@ -11,200 +11,200 @@ 0, 0, 0,1, 8832, 0x01ad3eeb 1, 0, 0,1, 2304, 0xf0ad1000 1, 1, 1,1, 2304, 0x69269ce6 -0, 1, 1,1, 8968, 0xe0033799 +0, 10, 10,1, 8968, 0xe0033799 1, 2, 2,1, 2304, 0x124a995d -0, 2, 2,1, 9036, 0xd6189ab7 +0, 20, 20,1, 9036, 0xd6189ab7 1, 3, 3,1, 2304, 0x3fc0ca07 -0, 3, 3,1, 9192, 0xb44b9ffa +0, 30, 30,1, 9192, 0xb44b9ffa 1, 4, 4,1, 2304, 0x40a1b447 -0, 4, 4,1, 9404, 0xe94dfd40 +0, 40, 40,1, 9404, 0xe94dfd40 1, 5, 5,1, 2304, 0x150dae9f 1, 6, 6,1, 2304, 0xad16bc63 -0, 5, 5,1, 9492, 0xf73f2541 +0, 50, 50,1, 9492, 0xf73f2541 1, 7, 7,1, 2304, 0xe989b175 -0, 6, 6,1, 9652, 0x243d53f8 +0, 60, 60,1, 9652, 0x243d53f8 1, 8, 8,1, 2304, 0x3c77cd39 -0, 7, 7,1, 9872, 0x83f3ea7a +0, 70, 70,1, 9872, 0x83f3ea7a 1, 9, 9,1, 2304, 0x93f0c2ba -0, 8, 8,1,10052, 0x7604247a +0, 80, 80,1,10052, 0x7604247a 1, 10, 10,1, 2304, 0x6e2ad2d0 1, 11, 11,1, 2304, 0xf8eab90a -0, 9, 9,1,10100, 0x077107fd +0, 90, 90,1,10100, 0x077107fd 1, 12, 12,1, 2304, 0xc039bf0d -0, 10, 10,1,10264, 0xae675eb6 +0,100,100,1,10264, 0xae675eb6 1, 13, 13,1, 2304, 0x0900c7e8 -0, 11, 11,1,10464, 0x428f83ae +0,110,110,1,10464, 0x428f83ae 1, 14, 14,1, 2304, 0x9722d580 -0, 12, 12,1,10580, 0x1bdcd71b +0,120,120,1,10580, 0x1bdcd71b 1, 15, 15,1, 2304, 0x02eec8de 1, 16, 16,1, 2304, 0x4807a2b3 -0, 13, 13,1,10800, 0xde75213a +0,130,130,1,10800, 0xde75213a 1, 17, 17,1, 2304, 0x4643be06 -0, 14, 14,1,11236, 0x9387cc8e +0,140,140,1,11236, 0x9387cc8e 1, 18, 18,1, 2304, 0x5bd9d249 -0, 15, 15,1,11420, 0x3a7d321b +0,150,150,1,11420, 0x3a7d321b 1, 19, 19,1, 2304, 0x4e33c2bc -0, 16, 16,1,11632, 0x7edc9cdf +0,160,160,1,11632, 0x7edc9cdf 1, 20, 20,1, 2304, 0x085ca51d 1, 21, 21,1, 2304, 0xa205b202 -0, 17, 17,1,11936, 0xf0521017 +0,170,170,1,11936, 0xf0521017 1, 22, 22,1, 2304, 0x71b9bcca -0, 18, 18,1,11804, 0x53b22066 +0,180,180,1,11804, 0x53b22066 1, 23, 23,1, 2304, 0xcb769e5f -0, 19, 19,1,11852, 0x9425fb21 +0,190,190,1,11852, 0x9425fb21 1, 24, 24,1, 2304, 0x9322d85a -0, 20, 20,1,12108, 0xc386941d +0,200,200,1,12108, 0xc386941d 1, 25, 25,1, 2304, 0x7f13bf6e 1, 26, 26,1, 2304, 0xd302a5cd -0, 21, 21,1,12796, 0x8b7e5dab +0,210,210,1,12796, 0x8b7e5dab 1, 27, 27,1, 2304, 0x7a7a9e30 -0, 22, 22,1,13316, 0x81235102 +0,220,220,1,13316, 0x81235102 1, 28, 28,1, 2304, 0x6ffccfdd -0, 23, 23,1,13724, 0xe5fc2bca +0,230,230,1,13724, 0xe5fc2bca 1, 29,
[FFmpeg-devel] [PATCH 1/2] avformat/psxstr: infer video FPS using sector LBA
Signed-off-by: aybe
---
libavformat/psxstr.c | 44 ++--
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git a/libavformat/psxstr.c b/libavformat/psxstr.c
index 306a690f52..c718fb6daf 100644
--- a/libavformat/psxstr.c
+++ b/libavformat/psxstr.c
@@ -65,6 +65,9 @@ typedef struct StrDemuxContext {
/* a STR file can contain up to 32 channels of data */
StrChannel channels[32];
+
+/* the index for the first frame (sector, LBA units)*/
+int64_t first_frame_index;
} StrDemuxContext;
static const uint8_t sync_header[12] =
{0x00,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00};
@@ -150,18 +153,51 @@ static int str_read_header(AVFormatContext *s)
str->channels[i].audio_stream_index= -1;
}
+str->first_frame_index = 0;
+
s->ctx_flags |= AVFMTCTX_NOHEADER;
return 0;
}
+static uint8_t bcd_to_dec(uint8_t bcd)
+{
+uint8_t dec = (bcd & 0xF) + (((bcd >> 4) & 0xF) * 10);
+
+return dec;
+}
+
+static int32_t msf_to_lba(uint8_t m, uint8_t s, uint8_t f)
+{
+int32_t lba = 0; /* int because it can be negative! */
+
+m = bcd_to_dec(m);
+s = bcd_to_dec(s);
+f = bcd_to_dec(f);
+
+lba = (((m * 60 + s) * 75) + f) - 150;
+
+return lba;
+}
+
+static int32_t str_get_frame_lba(uint8_t sector[2352])
+{
+uint8_t m = sector[0xC];
+uint8_t s = sector[0xD];
+uint8_t f = sector[0xE];
+
+int32_t lba = msf_to_lba(m, s, f);
+
+return lba;
+}
+
static int str_read_packet(AVFormatContext *s,
AVPacket *ret_pkt)
{
AVIOContext *pb = s->pb;
StrDemuxContext *str = s->priv_data;
unsigned char sector[RAW_CD_SECTOR_SIZE];
-int channel, ret;
+int channel, ret, frame_lba;
AVPacket *pkt;
AVStream *st;
@@ -200,10 +236,12 @@ static int str_read_packet(AVFormatContext *s,
st = avformat_new_stream(s, NULL);
if (!st)
return AVERROR(ENOMEM);
-avpriv_set_pts_info(st, 64, 1, 15);
+avpriv_set_pts_info(st, 64, 1, 150); /* 150 sectors at 2x
speed */
str->channels[channel].video_stream_index = st->index;
+str->first_frame_index = str_get_frame_lba(sector);
+
st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
st->codecpar->codec_id = AV_CODEC_ID_MDEC;
st->codecpar->codec_tag = 0; /* no fourcc */
@@ -223,6 +261,8 @@ static int str_read_packet(AVFormatContext *s,
return ret;
memset(pkt->data, 0, sector_count*VIDEO_DATA_CHUNK_SIZE);
+frame_lba = str_get_frame_lba(sector);
+pkt->pts = frame_lba - str->first_frame_index;
pkt->pos= avio_tell(pb) - RAW_CD_SECTOR_SIZE;
pkt->stream_index =
str->channels[channel].video_stream_index;
--
2.41.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2
Modern email clients like to do stuff they're told not to... The link I meant previously: https://github.com/aybe/FFmpeg-PSX-STR-tests -- Original Message -- >From "aybe aybe" >mailto:aybe.one-at-hotmail@ffmpeg.org>> To "FFmpeg development discussions and patches" mailto:ffmpeg-devel@ffmpeg.org>> Date 1/16/2024 3:27:16 PM Subject Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2 The new patch appears to work, stuff is synchronized, except: - 30 FPS video still seen as 150FPS by VLC - 15 FPS video emits tons of "[vost#0:0/rawvideo @ 0269b580] Clipping frame in rate conversion by 0.199989" As for the corrupt samples, been able to find the original sources: - the first is good old Descent - was cut at exactly 2MB - works in FFmpeg - the second is Ridge Racer Type 4 - bad/incomplete extract with a tool that added "RIFFCDXA" header for whatever reason - does NOT work in FFmpeg, comprised of 38 audio streams + 2 video streams (only decodes some audio then aborts) - but if I extract the relevant section from it, then works in FFmpeg New videos, samples, logs: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Faybe%2FFFmpeg-PSX-STR-tests=05%7C02%7C%7Cc7debed92bce42a5bcd908dc169f43bd%7C84df9e7fe9f640afb435%7C1%7C0%7C638410120640174537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2Faq1Hcn5X%2FVCvtVi5GO6Jes7mrPUCeZyrIZvDiAj6lw%3D=0 -- Original Message -- >From "Michael Niedermayer" >mailto:mich...@niedermayer.cc><mailto:mich...@niedermayer.cc>> To "FFmpeg development discussions and patches" mailto:ffmpeg-devel@ffmpeg.org><mailto:ffmpeg-devel@ffmpeg.org>> Date 1/16/2024 12:42:49 AM Subject Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2 On Mon, Jan 15, 2024 at 04:14:46PM +, aybe aybe wrote: Hi! I just tried what you've suggested, using 150 and setting AVPacket->pts using sector MSF as LBA. The results are somewhat mixed: - NTSC video: A/V synchronized but is now seen as 120 FPS by VLC - PAL video: A/V not synchronized anymore but still seen as 25 FPS by VLC can you send the patch for this plus links to one sample for both cases ? id like to take a look thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2
The new patch appears to work, stuff is synchronized, except: - 30 FPS video still seen as 150FPS by VLC - 15 FPS video emits tons of "[vost#0:0/rawvideo @ 0269b580] Clipping frame in rate conversion by 0.199989" As for the corrupt samples, been able to find the original sources: - the first is good old Descent - was cut at exactly 2MB - works in FFmpeg - the second is Ridge Racer Type 4 - bad/incomplete extract with a tool that added "RIFFCDXA" header for whatever reason - does NOT work in FFmpeg, comprised of 38 audio streams + 2 video streams (only decodes some audio then aborts) - but if I extract the relevant section from it, then works in FFmpeg New videos, samples, logs: https://github.com/aybe/FFmpeg-PSX-STR-tests -- Original Message -- From "Michael Niedermayer" mailto:mich...@niedermayer.cc>> To "FFmpeg development discussions and patches" mailto:ffmpeg-devel@ffmpeg.org>> Date 1/16/2024 12:42:49 AM Subject Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2 On Mon, Jan 15, 2024 at 04:14:46PM +, aybe aybe wrote: Hi! I just tried what you've suggested, using 150 and setting AVPacket->pts using sector MSF as LBA. The results are somewhat mixed: - NTSC video: A/V synchronized but is now seen as 120 FPS by VLC - PAL video: A/V not synchronized anymore but still seen as 25 FPS by VLC can you send the patch for this plus links to one sample for both cases ? id like to take a look thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates 0001-avformat-psxstr-infer-video-FPS-using-sector-LBA.eml.url Description: 0001-avformat-psxstr-infer-video-FPS-using-sector-LBA.eml.url 0002-avformat-psxstr-update-fate-checksums.eml.url Description: 0002-avformat-psxstr-update-fate-checksums.eml.url ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2
Hi! I just tried what you've suggested, using 150 and setting AVPacket->pts using sector MSF as LBA. The results are somewhat mixed: - NTSC video: A/V synchronized but is now seen as 120 FPS by VLC - PAL video: A/V not synchronized anymore but still seen as 25 FPS by VLC Not sure about 150, we assume videos play at 2x CD-ROM, not 100% exact but is likely to be the case for 99% of them. -- Original Message -- >From "Michael Niedermayer via ffmpeg-devel" >mailto:ffmpeg-devel@ffmpeg.org>> To "FFmpeg development discussions and patches" mailto:ffmpeg-devel@ffmpeg.org>> Cc "Michael Niedermayer" mailto:mich...@niedermayer.cc>> Date 1/14/2024 9:38:06 PM Subject Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2 Hi aybe On Sat, Jan 13, 2024 at 02:28:52AM +, aybe aybe wrote: Here are the two STR files I have used when writing this patch: https://github.com/aybe/FFmpeg-PSX-STR-tests ok, i can confirm the version patch fixes these, i will apply it Fanatics would probably say that 30 FPS for NTSC is wrong (i.e. should be 29.97)... However, as the reversed-engineered docs in jpsxdec mentions, it is sort of impossible to figure out which value to snap to from how frames spans across CD-ROM sectors. The sector count per video frame always seem to juggle between two values, e.g. 6 sectors, then 7 sectors, rinse/repeat. i.e. it's never constant. Also, as one can see in the various code samples online on writing a PSX program that plays MDEC videos, it is the responsibility of the coder to present the frames on screen. i.e. there is not definitive way on how to do so, and even if there was, you can be sure some folks did not play by the rules back then. The only way to figure out how a movie was intended to be played is to reverse engineer a game to see what values they did cram in. In short, the computed frame rate is 99% good, not 100%. But for mere mortals, they are unlikely to notice it at all. Well, with the subset of samples i have, i dont feel confident that i could write and test timestamping/fps. The docuemnt you linked says "Data is read from the disc one sector at a time at either 75 sectors per second (single speed) or 150 sectors per second (double speed). The video and audio are spaced out over these sectors so they can be delivered at the appropriate times." what i would suggest to try is: avpriv_set_pts_info(st, 64, 1, 150); (or 75 for single speed) and then set AVPacket->pts to the sector number you never set fps, leave it to libavformat to figure it out. can you try that ? (i assume you have many samples to easily check) As for the movies in the samples repository, they are corrupt and FFmpeg fails at them, obviously. I figured these ones were by checking them in a hex-editor but also by loading them in https://github.com/m35/jpsxdec which has great logging. Not sure why these samples were corrupt in first instance, maybe it was intentional for testing? I can't tell. Thats very strange, anyone remembers where these samples are from originally ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2
I'm afraid I can't tell, I checked the commits before creating patches out of
them; they did not appear to have superfluous whitespace in them.
-- Original Message --
>From "Michael Niedermayer"
>mailto:mich...@niedermayer.cc>>
To "FFmpeg development discussions and patches"
mailto:ffmpeg-devel@ffmpeg.org>>
Date 1/10/2024 3:37:41 AM
Subject Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is
like STRv2
On Tue, Jan 02, 2024 at 02:49:26AM +, aybe aybe wrote:
Hi,
As I understand, support for .STR files is broken for almost 10 years now
(since 161442ff2c4b0dd8a5072c6bbe6bf55303fffccf it seems).
Currently, ffmpeg fails with tons of errors like this on version 1 STRs, e.g.
Wipeout 1:
[mdec @ 027c72c0] ac-tex damaged at 1 9
What happens is that only the audio is present in the video file.
Anyway, that one character patch fixes the problem, video is now rendered.
Signed-off-by: aybe
mailto:a...@users.noreply.github.com>>
---
libavcodec/mdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mdec.c b/libavcodec/mdec.c
index 44b12471a9..c4904216b8 100644
--- a/libavcodec/mdec.c
+++ b/libavcodec/mdec.c
@@ -68,7 +68,7 @@ static inline int mdec_decode_block_intra(MDECContext *a,
int16_t *block, int n)
const int qscale = a->qscale;
/* DC coefficient */
- if (a->version == 2) {
+ if (a->version <= 2) {
block[0] = 2 * get_sbits(>gb, 10) + 1024;
} else {
component = (n <= 3 ? 0 : n - 4 + 1);
--
2.41.0.windows.1
This is how the patch should look: (there are differencs in the whitespace
which git seems to have problems with in above)
not sure where these differences came from
thx
diff --git a/libavcodec/mdec.c b/libavcodec/mdec.c
index 44b12471a9e..c4904216b81 100644
--- a/libavcodec/mdec.c
+++ b/libavcodec/mdec.c
@@ -68,7 +68,7 @@ static inline int mdec_decode_block_intra(MDECContext *a,
int16_t *block, int n)
const int qscale = a->qscale;
/* DC coefficient */
- if (a->version == 2) {
+ if (a->version <= 2) {
block[0] = 2 * get_sbits(>gb, 10) + 1024;
} else {
component = (n <= 3 ? 0 : n - 4 + 1);
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2
Here are the two STR files I have used when writing this patch: https://github.com/aybe/FFmpeg-PSX-STR-tests Fanatics would probably say that 30 FPS for NTSC is wrong (i.e. should be 29.97)... However, as the reversed-engineered docs in jpsxdec mentions, it is sort of impossible to figure out which value to snap to from how frames spans across CD-ROM sectors. The sector count per video frame always seem to juggle between two values, e.g. 6 sectors, then 7 sectors, rinse/repeat. i.e. it's never constant. Also, as one can see in the various code samples online on writing a PSX program that plays MDEC videos, it is the responsibility of the coder to present the frames on screen. i.e. there is not definitive way on how to do so, and even if there was, you can be sure some folks did not play by the rules back then. The only way to figure out how a movie was intended to be played is to reverse engineer a game to see what values they did cram in. In short, the computed frame rate is 99% good, not 100%. But for mere mortals, they are unlikely to notice it at all. As for the movies in the samples repository, they are corrupt and FFmpeg fails at them, obviously. I figured these ones were by checking them in a hex-editor but also by loading them in https://github.com/m35/jpsxdec which has great logging. Not sure why these samples were corrupt in first instance, maybe it was intentional for testing? I can't tell. -- Original Message -- >From "Michael Niedermayer" >mailto:mich...@niedermayer.cc>> To "FFmpeg development discussions and patches" mailto:ffmpeg-devel@ffmpeg.org>> Date 1/10/2024 3:46:02 AM Subject Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2 On Tue, Jan 02, 2024 at 02:49:26AM +, aybe aybe wrote: Hi, As I understand, support for .STR files is broken for almost 10 years now (since 161442ff2c4b0dd8a5072c6bbe6bf55303fffccf it seems). Currently, ffmpeg fails with tons of errors like this on version 1 STRs, e.g. Wipeout 1: [mdec @ 027c72c0] ac-tex damaged at 1 9 where can i find a psxstr file to test this ? the psxstr files i find on https://samples.ffmpeg.org/ seem not affected by this thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4] avformat/psxstr: basic FPS detection instead of fixed value
Sorry mate but I'm currently having a lot of trouble keeping in track with the
mailing list...
I thought emClient would be a savior but it isn't, it's buggy and confusing as
hell.
Have to check mailing list online, find mail in client so I can reply to it,
really boring!
Anyway... for the patch I simply followed what the previous author did
Previous author did put 15 there and when played in VLC you get 15 FPS.
Therefore, I concluded that it is indeed the right place where this should be
updated.
Format itself does not store the FPS, people would know in advance movie
size/speed.
But as mentioned before, it is sort of possible to 'detect' that, what I've
done in the patch.
A good source of information about the format is the following link:
https://github.com/m35/jpsxdec/blob/readme/jpsxdec/PlayStation1_STR_format.txt
My approach differs with the above in the sense that I assume min FPS is
definitely right.
And that works on the movies I have tested so far, it returns 25/30 for
PAL/NTSC versions.
-- Original Message --
>From "Michael Niedermayer"
>mailto:mich...@niedermayer.cc>>
To "FFmpeg development discussions and patches"
mailto:ffmpeg-devel@ffmpeg.org>>
Date 1/10/2024 3:56:39 AM
Subject Re: [FFmpeg-devel] [PATCH 4/4] avformat/psxstr: basic FPS detection
instead of fixed value
On Tue, Jan 02, 2024 at 03:14:19AM +, aybe aybe wrote:
This fourth and last patch is an attempt at removing the hard-coded value of 15
FPS.
In patch 1/4, although it would render video, the audio and video were not
synchronized at all, now there are.
In this approach I kept it simple, grab min/max possible rates, pick min, clamp
to 15/30 just in case.
It appears to work quite well, the right frame rate is picked up and both
streams are in sync.
(tested against Wipeout introduction for both PAL and NTSC versions).
Besides, there have been significant findings over the years regarding that
format, specifically:
https://problemkaputt.de/psxspx-macroblock-decoder-mdec.htm
https://github.com/m35/jpsxdec/blob/readme/jpsxdec/PlayStation1_STR_format.txt
Maybe someone versed in this topic (I'm not) could further improve support of
this format according these docs...
Signed-off-by: aybe
mailto:a...@users.noreply.github.com>>
---
libavformat/psxstr.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/libavformat/psxstr.c b/libavformat/psxstr.c
index 306a690f52..98897acde3 100644
--- a/libavformat/psxstr.c
+++ b/libavformat/psxstr.c
@@ -52,6 +52,9 @@
#define STR_MAGIC (0x80010160)
+#define MDEC_STR_FPS_MIN 15
+#define MDEC_STR_FPS_MAX 30
+
typedef struct StrChannel {
/* video parameters */
int video_stream_index;
@@ -65,6 +68,10 @@ typedef struct StrDemuxContext {
/* a STR file can contain up to 32 channels of data */
StrChannel channels[32];
+ /* trivial FPS detection based on sectors per frame */
+ int fps_min; /* slowest FPS found */
+ int fps_max; /* fastest FPS found */
+ int fps_val; /* nominal FPS value */
} StrDemuxContext;
static const uint8_t sync_header[12] =
{0x00,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00};
@@ -150,6 +157,10 @@ static int str_read_header(AVFormatContext *s)
str->channels[i].audio_stream_index= -1;
}
+ str->fps_min = INT_MAX;
+ str->fps_max = INT_MIN;
+ str->fps_val = 0;
+
s->ctx_flags |= AVFMTCTX_NOHEADER;
return 0;
@@ -161,7 +172,7 @@ static int str_read_packet(AVFormatContext *s,
AVIOContext *pb = s->pb;
StrDemuxContext *str = s->priv_data;
unsigned char sector[RAW_CD_SECTOR_SIZE];
- int channel, ret;
+ int channel, ret, sub_mode, idx_sect, num_sect;
AVPacket *pkt;
AVStream *st;
@@ -178,6 +189,18 @@ static int str_read_packet(AVFormatContext *s,
if (channel >= 32)
return AVERROR_INVALIDDATA;
+ sub_mode = sector[0x12];
+ idx_sect = AV_RL16([0x1C]);
+ num_sect = AV_RL16([0x1E]);
+
+ /* compute FPS from sector count @ each new video frame */
+ if (sub_mode & 0x02 && idx_sect == 0x00) {
+ int fps = 150 / num_sect;
+ str->fps_min = FFMIN(str->fps_min, fps);
+ str->fps_max = FFMAX(str->fps_max, fps);
+ str->fps_val = FFMIN(MDEC_STR_FPS_MAX, FFMAX(MDEC_STR_FPS_MIN, str->fps_min));
+ }
+
switch (sector[0x12] & CDXA_TYPE_MASK) {
case CDXA_TYPE_DATA:
@@ -200,7 +223,7 @@ static int str_read_packet(AVFormatContext *s,
st = avformat_new_stream(s, NULL);
if (!st)
return AVERROR(ENOMEM);
- avpriv_set_pts_info(st, 64, 1, 15);
+ avpriv_set_pts_info(st, 64, 1, str->fps_val);
This is not a FPS value,
avpriv_set_pts_info() sets the timebase in which timestamps are specified
I dont know psxstr but can you explain what information there is in it
about the video frames ?
is there some sort of information that indicates when a frame is to be
displayed ?
that is like a timestamp ?
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Elect y
Re: [FFmpeg-devel] [PATCH 4/4] avformat/psxstr: basic FPS detection instead of fixed value
98, 98,1, 2304, 0xf2a8b9d8 -0, 79, 79,1,15020, 0xe8faa930 +0, 84, 84,1,13420, 0xdf3ec8a4 1, 99, 99,1, 2304, 0x7bc99f71 -0, 80, 80,1,16152, 0x3f004f78 +0, 85, 85,1,14140, 0x0ad8a165 1,100,100,1, 2304, 0x3f199672 +0, 86, 86,1,15192, 0xc55f45cd 1,101,101,1, 2304, 0x4e258c38 -0, 81, 81,1,17224, 0x103f3935 +0, 87, 87,1,12740, 0xa13c85db 1,102,102,1, 2304, 0x5119b909 -0, 82, 82,1,11956, 0x7af9354a 1,103,103,1, 2304, 0xad57a533 -0, 83, 83,1,12644, 0xe113a4b2 +0, 88, 88,1,14416, 0x9e68b57d 1,104,104,1, 2304, 0xe40eb453 -0, 84, 84,1,13420, 0xdf3ec8a4 1,105,105,1, 2304, 0x502cc37e 1,106,106,1, 2304, 0x5b7bae9a -0, 85, 85,1,14140, 0x0ad8a165 1,107,107,1, 2304, 0x0458a92d -0, 86, 86,1,15192, 0xc55f45cd 1,108,108,1, 2304, 0x1529aba8 -0, 87, 87,1,12740, 0xa13c85db 1,109,109,1, 2304, 0x1a52a9d1 -0, 88, 88,1,14416, 0x9e68b57d 1,110,110,1, 2304, 0x76a2a7c9 -- 2.41.0.windows.1 -- Original Message -- >From "Michael Niedermayer" >mailto:mich...@niedermayer.cc>> To "FFmpeg development discussions and patches" mailto:ffmpeg-devel@ffmpeg.org>> Date 1/7/2024 12:44:03 AM Subject Re: [FFmpeg-devel] [PATCH 4/4] avformat/psxstr: basic FPS detection instead of fixed value On Tue, Jan 02, 2024 at 03:14:19AM +, aybe aybe wrote: This fourth and last patch is an attempt at removing the hard-coded value of 15 FPS. In patch 1/4, although it would render video, the audio and video were not synchronized at all, now there are. In this approach I kept it simple, grab min/max possible rates, pick min, clamp to 15/30 just in case. It appears to work quite well, the right frame rate is picked up and both streams are in sync. (tested against Wipeout introduction for both PAL and NTSC versions). Besides, there have been significant findings over the years regarding that format, specifically: https://problemkaputt.de/psxspx-macroblock-decoder-mdec.htm https://github.com/m35/jpsxdec/blob/readme/jpsxdec/PlayStation1_STR_format.txt Maybe someone versed in this topic (I'm not) could further improve support of this format according these docs... Signed-off-by: aybe mailto:a...@users.noreply.github.com>> --- libavformat/psxstr.c | 27 +-- 1 file changed, 25 insertions(+), 2 deletions(-) The fate checksums change with the code change, they need to be updated in this patch, if the changes are intended: make -j32 fate-psx-str-demux --- ./tests/ref/fate/psx-str-demux 2024-01-06 03:38:10.432133150 +0100 +++ tests/data/fate/psx-str-demux 2024-01-07 00:42:26.202312209 +0100 @@ -1,4 +1,4 @@ -#tb 0: 1/15 +#tb 0: 1/16 #media_type 0: video #codec_id 0: mdec #dimensions 0: 320x240 @@ -19,8 +19,8 @@ 1, 4, 4, 1, 2304, 0x40a1b447 0, 4, 4, 1, 9404, 0xe94dfd40 1, 5, 5, 1, 2304, 0x150dae9f -1, 6, 6, 1, 2304, 0xad16bc63 0, 5, 5, 1, 9492, 0xf73f2541 +1, 6, 6, 1, 2304, 0xad16bc63 1, 7, 7, 1, 2304, 0xe989b175 0, 6, 6, 1, 9652, 0x243d53f8 1, 8, 8, 1, 2304, 0x3c77cd39 @@ -28,183 +28,183 @@ 1, 9, 9, 1, 2304, 0x93f0c2ba 0, 8, 8, 1, 10052, 0x7604247a 1, 10, 10, 1, 2304, 0x6e2ad2d0 -1, 11, 11, 1, 2304, 0xf8eab90a 0, 9, 9, 1, 10100, 0x077107fd -1, 12, 12, 1, 2304, 0xc039bf0d +1, 11, 11, 1, 2304, 0xf8eab90a 0, 10, 10, 1, 10264, 0xae675eb6 -1, 13, 13, 1, 2304, 0x0900c7e8 +1, 12, 12, 1, 2304, 0xc039bf0d 0, 11, 11, 1, 10464, 0x428f83ae +1, 13, 13, 1, 2304, 0x0900c7e8 1, 14, 14, 1, 2304, 0x9722d580 0, 12, 12, 1, 10580, 0x1bdcd71b 1, 15, 15, 1, 2304, 0x02eec8de -1, 16, 16, 1, 2304, 0x4807a2b3 0, 13, 13, 1, 10800, 0xde75213a -1, 17, 17, 1, 2304, 0x4643be06 +1, 16, 16, 1, 2304, 0x4807a2b3 0, 14, 14, 1, 11236, 0x9387cc8e -1, 18, 18, 1, 2304, 0x5bd9d249 +1, 17, 17, 1, 2304, 0x4643be06 0, 15, 15, 1, 11420, 0x3a7d321b -1, 19, 19, 1, 2304, 0x4e33c2bc +1, 18, 18, 1, 2304, 0x5bd9d249 0, 16, 16, 1, 11632, 0x7edc9cdf +1, 19, 19, 1, 2304, 0x4e33c2bc +0, 17, 17, 1, 11936, 0xf0521017 1, 20, 20, 1, 2304, 0x085ca51d 1, 21, 21, 1, 2304, 0xa205b202 -0, 17, 17, 1, 11936, 0xf0521017 -1, 22, 22, 1, 2304, 0x71b9bcca 0, 18, 18, 1, 11804, 0x53b22066 -1, 23, 23, 1, 2304, 0xcb769e5f +1, 22, 22, 1, 2304, 0x71b9bcca 0, 19, 19, 1, 11852, 0x9425fb21 -1, 24, 24, 1, 2304, 0x9322d85a +1, 23, 23, 1, 2304, 0xcb769e5f 0, 20, 20, 1, 12108, 0xc386941d +1
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2
Yes, I can see the warnings in patchwork but I don't understand what's
the actual problem.
This is how I've done things over here:
- forked https://github.com/FFmpeg/FFmpeg which is synchronized with
https://git.ffmpeg.org/ffmpeg.git
- made the changes, committed them
- created the patches with 'git format patch' instructions in
https://ffmpeg.org/developer.html#Submitting-patches-1
- posted the .eml files without any editing (as the log is mentioning in
patchwork)
Right now I just synced my fork and it merged new changes since then
with no issues (https://github.com/aybe/FFmpeg/commits/master/).
So I don't know what's going on, maybe someone can shed some light on
it?
-- Original Message --
>From "michael at niedermayer.cc"
To
Date 1/5/2024 9:53:52 PM
Subject [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is
like STRv2
>On Tue, Jan 02, 2024 at 02:49:26AM +, aybe aybe wrote:
>> Hi,
>>
>> As I understand, support for .STR files is broken for almost 10 years now
>> (since 161442ff2c4b0dd8a5072c6bbe6bf55303fffccf it seems).
>>
>> Currently, ffmpeg fails with tons of errors like this on version 1 STRs,
>> e.g. Wipeout 1:
>> [mdec @ 027c72c0] ac-tex damaged at 1 9
>>
>> What happens is that only the audio is present in the video file.
>>
>> Anyway, that one character patch fixes the problem, video is now rendered.
>>
>> Signed-off-by: aybe
>> ---
>>libavcodec/mdec.c | 2 +-
>>1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/mdec.c b/libavcodec/mdec.c
>> index 44b12471a9..c4904216b8 100644
>> --- a/libavcodec/mdec.c
>> +++ b/libavcodec/mdec.c
>> @@ -68,7 +68,7 @@ static inline int mdec_decode_block_intra(MDECContext *a,
>> int16_t *block, int n)
>>const int qscale = a->qscale;
>>
>>/* DC coefficient */
>> -if (a->version == 2) {
>> +if (a->version <= 2) {
>>block[0] = 2 * get_sbits(>gb, 10) + 1024;
>>} else {
>>component = (n <= 3 ? 0 : n - 4 + 1);
>
>This seems not to apply automatically here
>
>Applying: avcodec/mdec: DC reading for STRv1 is like STRv2
>Using index info to reconstruct a base tree...
>error: patch failed: libavcodec/mdec.c:68
>error: libavcodec/mdec.c: patch does not apply
>error: Did you hand edit your patch?
>
>[...]
>--
>Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
>Asymptotically faster algorithms should always be preferred if you have
>asymptotical amounts of data
>-- next part --
>A non-text attachment was scrubbed...
>Name: signature.asc
>Type: application/pgp-signature
>Size: 195 bytes
>Desc: not available
>URL:
><https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240105/fc813de7/attachment.sig>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/4] avformat/psxstr: basic FPS detection instead of fixed value
This fourth and last patch is an attempt at removing the hard-coded value of 15
FPS.
In patch 1/4, although it would render video, the audio and video were not
synchronized at all, now there are.
In this approach I kept it simple, grab min/max possible rates, pick min, clamp
to 15/30 just in case.
It appears to work quite well, the right frame rate is picked up and both
streams are in sync.
(tested against Wipeout introduction for both PAL and NTSC versions).
Besides, there have been significant findings over the years regarding that
format, specifically:
https://problemkaputt.de/psxspx-macroblock-decoder-mdec.htm
https://github.com/m35/jpsxdec/blob/readme/jpsxdec/PlayStation1_STR_format.txt
Maybe someone versed in this topic (I'm not) could further improve support of
this format according these docs...
Signed-off-by: aybe
---
libavformat/psxstr.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/libavformat/psxstr.c b/libavformat/psxstr.c
index 306a690f52..98897acde3 100644
--- a/libavformat/psxstr.c
+++ b/libavformat/psxstr.c
@@ -52,6 +52,9 @@
#define STR_MAGIC (0x80010160)
+#define MDEC_STR_FPS_MIN 15
+#define MDEC_STR_FPS_MAX 30
+
typedef struct StrChannel {
/* video parameters */
int video_stream_index;
@@ -65,6 +68,10 @@ typedef struct StrDemuxContext {
/* a STR file can contain up to 32 channels of data */
StrChannel channels[32];
+/* trivial FPS detection based on sectors per frame */
+int fps_min; /* slowest FPS found */
+int fps_max; /* fastest FPS found */
+int fps_val; /* nominal FPS value */
} StrDemuxContext;
static const uint8_t sync_header[12] =
{0x00,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00};
@@ -150,6 +157,10 @@ static int str_read_header(AVFormatContext *s)
str->channels[i].audio_stream_index= -1;
}
+str->fps_min = INT_MAX;
+str->fps_max = INT_MIN;
+str->fps_val = 0;
+
s->ctx_flags |= AVFMTCTX_NOHEADER;
return 0;
@@ -161,7 +172,7 @@ static int str_read_packet(AVFormatContext *s,
AVIOContext *pb = s->pb;
StrDemuxContext *str = s->priv_data;
unsigned char sector[RAW_CD_SECTOR_SIZE];
-int channel, ret;
+int channel, ret, sub_mode, idx_sect, num_sect;
AVPacket *pkt;
AVStream *st;
@@ -178,6 +189,18 @@ static int str_read_packet(AVFormatContext *s,
if (channel >= 32)
return AVERROR_INVALIDDATA;
+sub_mode = sector[0x12];
+idx_sect = AV_RL16([0x1C]);
+num_sect = AV_RL16([0x1E]);
+
+/* compute FPS from sector count @ each new video frame */
+if (sub_mode & 0x02 && idx_sect == 0x00) {
+int fps = 150 / num_sect;
+str->fps_min = FFMIN(str->fps_min, fps);
+str->fps_max = FFMAX(str->fps_max, fps);
+str->fps_val = FFMIN(MDEC_STR_FPS_MAX, FFMAX(MDEC_STR_FPS_MIN,
str->fps_min));
+}
+
switch (sector[0x12] & CDXA_TYPE_MASK) {
case CDXA_TYPE_DATA:
@@ -200,7 +223,7 @@ static int str_read_packet(AVFormatContext *s,
st = avformat_new_stream(s, NULL);
if (!st)
return AVERROR(ENOMEM);
-avpriv_set_pts_info(st, 64, 1, 15);
+avpriv_set_pts_info(st, 64, 1, str->fps_val);
str->channels[channel].video_stream_index = st->index;
--
2.41.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/4] avformat/psxstr: fix unknown sector type 00/80
This third patch fixes warnings that are false positives (still on STRv1).
That's because these sectors are simply empty ones as can be read in "System
Description CD-ROM XA, May 1991,
4.3.2.3".
Haven't attempted significant refactoring as it just works, left a comment
instead about the situation.
The result is that there are no more false warnings when converting.
Signed-off-by: aybe
---
libavformat/psxstr.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/psxstr.c b/libavformat/psxstr.c
index 72d14b9792..306a690f52 100644
--- a/libavformat/psxstr.c
+++ b/libavformat/psxstr.c
@@ -48,6 +48,7 @@
#define CDXA_TYPE_DATA 0x08
#define CDXA_TYPE_AUDIO0x04
#define CDXA_TYPE_VIDEO0x02
+#define CDXA_TYPE_EMPTY0x00
#define STR_MAGIC (0x80010160)
@@ -274,6 +275,12 @@ static int str_read_packet(AVFormatContext *s,
str->channels[channel].audio_stream_index;
pkt->duration = 1;
return 0;
+case CDXA_TYPE_EMPTY: /* CD-ROM XA, May 1991, 4.3.2.3 */
+{
+/* NOTE this also catches 0x80 (EOF bit) because of
CDXA_TYPE_MASK */
+/* TODO consider refactoring so as to explicitly handle each
case? */
+break;
+}
default:
av_log(s, AV_LOG_WARNING, "Unknown sector type %02X\n",
sector[0x12]);
/* drop the sector and move on */
--
2.41.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/4] avformat/psxstr: fix demuxing I/O error at EOF
This second patch fixes the following error at the end of a .STR stream
conversion:
[in#0/psxstr @ 00681e80] Error during demuxing: I/O error
It's been a bit of trial and error as I've never used ffmpeg, but returning
AVERROR_EOF appears to be the way to go (doesn't complain anymore).
Signed-off-by: aybe
---
libavformat/psxstr.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/psxstr.c b/libavformat/psxstr.c
index bb56b05688..72d14b9792 100644
--- a/libavformat/psxstr.c
+++ b/libavformat/psxstr.c
@@ -165,8 +165,12 @@ static int str_read_packet(AVFormatContext *s,
AVStream *st;
while (1) {
+int read = avio_read(pb, sector, RAW_CD_SECTOR_SIZE);
-if (avio_read(pb, sector, RAW_CD_SECTOR_SIZE) != RAW_CD_SECTOR_SIZE)
+if (read == AVERROR_EOF)
+return AVERROR_EOF;
+
+if (read != RAW_CD_SECTOR_SIZE)
return AVERROR(EIO);
channel = sector[0x11];
--
2.41.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2
Hi,
As I understand, support for .STR files is broken for almost 10 years now
(since 161442ff2c4b0dd8a5072c6bbe6bf55303fffccf it seems).
Currently, ffmpeg fails with tons of errors like this on version 1 STRs, e.g.
Wipeout 1:
[mdec @ 027c72c0] ac-tex damaged at 1 9
What happens is that only the audio is present in the video file.
Anyway, that one character patch fixes the problem, video is now rendered.
Signed-off-by: aybe
---
libavcodec/mdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mdec.c b/libavcodec/mdec.c
index 44b12471a9..c4904216b8 100644
--- a/libavcodec/mdec.c
+++ b/libavcodec/mdec.c
@@ -68,7 +68,7 @@ static inline int mdec_decode_block_intra(MDECContext *a,
int16_t *block, int n)
const int qscale = a->qscale;
/* DC coefficient */
-if (a->version == 2) {
+if (a->version <= 2) {
block[0] = 2 * get_sbits(>gb, 10) + 1024;
} else {
component = (n <= 3 ? 0 : n - 4 + 1);
--
2.41.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
