Ping!
I would appreciate some input on this, a bit more digging and I have found that
in the lavf-ogg flake test the last packet that arrives and causes the
regression with my patch looks like this:
(AVPacket) $1 = {
buf = 0x0000000103105740
pts = 44100
dts = 44100
data = 0x0000000103105c40 ""
size = 0
stream_index = 0
flags = 1
side_data = 0x0000000103105ff0
side_data_elems = 1
duration = 0
pos = -1
convergence_duration = 0
}
Currently wondering if it makes sense to send in a zero sized packet for muxing
or not. That is, should I try to fix that or should I rather try to compensate
for this in oggenc.c?
Regards,
Peter
> On 15 Dec 2020, at 14:35, Peter Zebühr <pe...@zebuhr.se> wrote:
>
> Hello!
>
> I have stumbled on an issue with the ogg page termination in a probably quite
> rare case.
> If the last page ends up full (255 segments) and the last packet that is
> written is an even multiple of 255 that needs to be terminated with a lacing
> value of zero that spills over to the next page, then oggenc fails to write a
> last page that contains the zero lacing value and libogg will fail to detect
> the end of stream when parsing the produced file. Example:
>
> 1. Last page contains 253 segments
> 2. Packet arrives of size 510 bytes
> 3. Packet it split into three segments of sizes [255, 255, 0]
> 4. Page gets the two segments [255, 255] and is full
> 5. A new page is created containing only the [0] lacing value but no actual
> data
> 6. The last page is ignored when completing the stream (because it contains 0
> bytes data)
>
> I have a patch that fixes this (attached) in the case that I had, but... one
> of the fate tests fail (lavf-ogg) and I need some help to reason about what
> the right thing to do is.
>
> The reason the test fails is because one extra page is created with my patch.
> The reason why one extra page is created is because the previous page is
> completed as it hits the "pref_duration" setting of 1 second
> (https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/oggenc.c#L261) and
> then write_packet is called with one more packet of size 0 bytes. The
> questions I have are:
> * Is this a reasonable regression? From the ogg perspective it sounds kind of
> reasonable that a 0 byte packet would result in a 0 byte segment but not sure
> why write_packet is even called with a 0 byte packet.
> * If this is not a reasonable regression I could either:
> - short circuit handling of a 0 byte packet and make it produce 0 segments
> in ogg_buffer_data
> OR
> - tweak the logic in the proposed change to write_trailer to make it
> consider segment_count only if the ongoing page is a continuation of the
> previous page.
> (OR perhaps it is another bug that a 0 byte packet is written?)
>
>
> / Peter
>
> <0001-Fix-ogg-page-termination-on-even-last-packets.patch>_______________________________________________
> 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".
