Jan 5, 2021, 14:39 by pe...@zebuhr.se:
> 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".
>>
Was going to respond to this but forgot.
Opus can have 0 byte packets to signal silence. So you'll have to fix this for
real.
_______________________________________________
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".
