[FFmpeg-devel] Collection of patches

[Thorsten Jordan]

Michael Niedermayer schrieb:
> On Tue, Apr 22, 2008 at 12:36:02PM +0200, Thorsten Jordan wrote:
> [...]
>> So thanks for reading so far and here are the patches:
>>
> 
>> Make AVCHD (mts) files give better PTS values, as PCR packets are
>> scanned ignoring the mts<->ts difference:
>> mts_pcr_parse_syncbyte_check.patch
> 
> mans ?
it may look a bit hackish but shows up a problem when decoding .mts
files, as they are not handled specially by ffmpeg. The TS demuxer just
scans for the next 0x47 startcode, skipping the 4 bytes of the counter
that are stored in each mts-"packet" before the TS part. Since the first
byte of that counter is <= 0x3f, that patch should be valid (it can
never be 0x47). Imho the demuxer should handle mts specially, because
what if any of the bytes 1-3 of that counter are 0x47 by coincidence?

>> Do not split the h264 "headers" off too early, as when a SEI follows a
>> SPS, split must not stop there but also include the following PPS:
>> h264_parser_SEI_ignore.patch
> 
> This is IIRC wrong, correct solution was discussed somewhere on the
> mailinglist.
hmm i haven't searched yet, but when you rip the header of to e.g. write
h264 data to MP4, the split function of the parser is used, and this
doesn't rip off the PPS without the patch. The generated MP4 files didnt
work. Maybe it has been fixed differently meanwhile, but i can't
imaginge how.

>> Set pixel aspect ratio for xvid wrapper:
>> libxvid_set_pixelaspect.patch
> 
> This is missing a check for sample_aspect_ratios validity.
yes, that was the objection on first submission. If anyone wants to take
over...

>> Give name of two-pass-stats file to x264 (ugly solution though):
>> x264_2pass_statfilename.patch
> tabs
right, was just a quick hack, I didnt post this in the past because you
said such a patch wouldnt have the slightest chance. However there is a
similar issue in the tracker meanwhile.

>> undef DEBUG_SEEK in libavformat/utils.c as this causes much computations
>> when opening large TS files (complete parsing of whole file on open
>> instead on demand) - this was once rejected because it would break
>> regression checks - I propose to adapt the check rather or to see why
>> the check won't work when debug code is disabled! :
>> proposal-undef-DEBUG_SEEK.patch
> 
> Why do the regression tests break with that?
Initially submitted on 10/15/2007, you said first "patch ok", Benoit
Fouet applied it, then he replied on 10/16/2007 "this breaks seek
regression test (i missed that) as follows, what should
be done ?" with the following text:

Index: tests/seek.regression.ref
===================================================================
--- tests/seek.regression.ref	(revision 10755)
+++ tests/seek.regression.ref	(working copy)
@@ -3219,8 +3219,7 @@
 ret: 0 st: 0 dts:0.000000 pts:0.000000 pos:394 size:31384 flags:1
 ret: 0 st:-1 ts:-1.000000 flags:0
 ret: 0 st: 1 dts:0.000000 pts:0.000000 pos:31790 size:278 flags:1
-ret: 0 st:-1 ts:1.894167 flags:1
-ret: 0 st: 1 dts:0.975000 pts:0.975000 pos:355089 size:278 flags:1
+ret:-1 st:-1 ts:1.894167 flags:1
 ret: 0 st: 0 ts:0.788000 flags:0
 ret: 0 st: 1 dts:0.975000 pts:0.975000 pos:355089 size:278 flags:1
 ret: 0 st: 0 ts:-0.317000 flags:1

then it was unapplied and never considered again.

I wrote at that time that it caused much seeking when opening a file
because of the debug code that causes index generation when not needed.
With that patch one can open large TS/PS files and indices are generated
on demand, which works nicely. Why would one want to lose that great
feature because of some test, that may be wrong? I dont have the
knowledge of the testcode to change it, or else i would have proposed
that too.

-- 
Regards, Thorsten