LINUX.ORG.RU

Монотонный DTS

 , , , ,


0

2

Не могу разобраться с monotonous DTS в h264. Ffmpeg ругается, что DTS увеличивается не монотонно. Также сыпятся сообщения из libx264: non-strictly-monotonic.


ffmpeg -y -loglevel repeat+info -i bad_7s.mp4 -vsync 0 out.mp4

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'bad_7s.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.12.100
  Duration: 00:01:04.33, start: 0.000000, bitrate: 1656 kb/s
    Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 480x270, 1654 kb/s, 24.42 fps, 16k tbr, 16k tbn, 32k tbc (default)
    Metadata:
      handler_name    : VideoHandler
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[libx264 @ 0x6473e80] using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX
[libx264 @ 0x6473e80] profile High, level 2.1
[libx264 @ 0x6473e80] 264 - core 155 r2901 7d0ff22 - H.264/MPEG-4 AVC codec - Copyleft 2003-2018 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=1 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=24 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'out.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.12.100
    Stream #0:0(und): Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 480x270, q=-1--1, 24.42 fps, 1571k tbn, 24.42 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      encoder         : Lavc58.18.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[mp4 @ 0x6475540] Non-monotonous DTS in output stream 0:0; previous: 0, current: 0; changing to 1. This may result in incorrect timestamps in the output file.
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[mp4 @ 0x6475540] Non-monotonous DTS in output stream 0:0; previous: 192993, current: 192993; changing to 192994. This may result in incorrect timestamps in the output file.
[mp4 @ 0x6475540] Non-monotonous DTS in output stream 0:0; previous: 321655, current: 321655; changing to 321656. This may result in incorrect timestamps in the output file.
[mp4 @ 0x6475540] Non-monotonous DTS in output stream 0:0; previous: 771972, current: 771972; changing to 771973. This may result in incorrect timestamps in the output file.
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[mp4 @ 0x6475540] Non-monotonous DTS in output stream 0:0; previous: 900634, current: 900634; changing to 900635. This may result in incorrect timestamps in the output file.
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[mp4 @ 0x6475540] Non-monotonous DTS in output stream 0:0; previous: 1029296, current: 1029296; changing to 1029297. This may result in incorrect timestamps in the output file.
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[mp4 @ 0x6475540] Non-monotonous DTS in output stream 0:0; previous: 1157958, current: 1157958; changing to 1157959. This may result in incorrect timestamps in the output file.
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[mp4 @ 0x6475540] Non-monotonous DTS in output stream 0:0; previous: 1415282, current: 1415282; changing to 1415283. This may result in incorrect timestamps in the output file.
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[libx264 @ 0x6473e80] non-strictly-monotonic PTS
[mp4 @ 0x6475540] Non-monotonous DTS in output stream 0:0; previous: 1801268, current: 1801268; changing to 1801269. This may result in incorrect timestamps in the output file.



Как я понял, DTS должен увеличиваться (что логично). Посмотрел исходники libx264 https://code.videolan.org/videolan/x264/-/blob/master/encoder/encoder.c#L3325

 if( h->param.b_vfr_input && fenc->i_pts <= h->frames.i_largest_pts )
            x264_log( h, X264_LOG_WARNING, "non-strictly-monotonic PTS\n" );



из чего следует(по моей логике), что если текущий PTS меньше или равен предыдущему (точнее самому большому значению всех предыдущих PTS?), то выводится предупреждение

Распарсил свой видеоролик
ffprobe -show_frames -select_streams v:0  bad_7s.mp4


И не увидел там плохих DTS\PTS(они всегда равны в моем случае). Я даже написал простой скрипт, который бы находил эти «плохие» DTS

Выгрузил в json информацию о всех фреймах
 
ffprobe -show_frames -select_streams v:0 -print_format json  bad_7s.mp4 > frames.json


node parse.js
const fs = require("fs");

var data = JSON.parse(fs.readFileSync("frames.json").toString());

var largest_dst;
for(var item of data.frames){
    var dts = item.pkt_dts;
    var pts = item.pkt_pts;

    if(dts !== pts) {
        console.error("error", item);
        process.exit();
    }

    if(largest_dst && dts <= largest_dst){
        console.error(item);
    }

    if(!largest_dst || dts > largest_dst){
        largest_dst = dts;
    }

}


...и скрипт не нашел ничего, вывод пустой. Все DTS увеличиваются!

Что я делаю\понимаю не так?

Все фреймы в формате csv
https://pastebin.com/B9DtFsPR

★★★★

Сколько ты ещё тредоа создаёшь с твоим bad.ts? Лучше дай ссылку на багтрекер хрома, где нормальные люди обсуждают проблему. Жабаскриптер открывающий новый мир передачи медиаданных утомительно многотреден

anonymous
()
Ответ на: комментарий от anonymous

non-strictly-monotonic PTS

Тогда для чего это предупреждение выводится? Да и в моем случае DTS совпадают с PTS

gobot ★★★★
() автор топика
Ответ на: комментарий от anonymous

Сколько ты ещё тредоа создаёшь

столько, сколько посчитаю нужным

Жабаскриптер открывающий новый мир передачи медиаданных утомительно многотреден

Да, «открываю новый мир передачи медиаданных», тебя это гложет?

Лучше дай ссылку на багтрекер хрома, где нормальные люди обсуждают проблему

Я тут про хром ничего не писал, ты наверное что-то перепутал

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

Ну ок, багтрекер хромиума, хоть почитать, что нормальные люди пишут. PTS не должен увеличиваться это «сильно». Давай, не быкуй, дай ссылку не охото ванговать и грепать по номеру аттачмента

anonymous
()

в h264 нет DTS\PTS, DTS\PTS это свойства контейнера где лежит h264

libx264: non-strictly-monotonic

вы уже гуглили по этому словосочетанию? она должно было вас привести в некоторые места где можно прочитать

Ffmpeg ругается, что DTS увеличивается не монотонно.

ругается не ffmpeg, а mp4 упаковщик ffmpeg

Non-monotonous DTS in output stream 0:0; previous: 1029296, current: 1029296; changing to 1029297. This may result in incorrect timestamps in the output file.

mp4 получает от libx264 закодированное с одинаковым DTS, это бесмыслено, не может быть кадров с одинаковым DTS, поэтому там простая семантика, добавим еденичку, пусть DTS будут разными

почему из libx264 выходит плохое, он пишет: non-strictly-monotonic по этому словосочетанию вы достатчно нагуглите, там многое вам попадется, что вы посчитаете не важным, но штош

посмотрел в соседнем вашем треде bad_7s.mp4, у вас durarion, а значит и pts какие-то странные, откуда вы такое взяли?

возьмите любое эталонное, закодируйте libx264 и посмотрите на dts\pts на выходе и на duration

hizel ★★★★★
()
Ответ на: комментарий от hizel

в h264 нет DTS\PTS, DTS\PTS это свойства контейнера где лежит h264
ругается не ffmpeg, а mp4 упаковщик ffmpeg

Да, это muxer ругается.

mp4 получает от libx264 закодированное с одинаковым DTS

Но я смотрел через ffprobe, там нет одинаковых DTS

non-strictly-monotonic по этому словосочетанию вы достатчно нагуглите

Да не гуглится это. Все ссылки идут на багрепорты ffmpeg и прочую чепуху. Помогают более менее прояснить картину только исходники ffmpeg и libx264

посмотрел в соседнем вашем треде bad_7s.mp4, у вас durarion, а значит и pts какие-то странные, откуда вы такое взяли

Что значит «у вас durarion»?
Ну да, вот pkt_durarion на ~7 сек. 0.001

coded_picture_number pict_type pkt_dts_time pkt_dts 
pkt_duration  (pkt_duration_time)
160 I 6.570000 105120 656(0.041000)
161 P 6.611000 105776 400(0.025000)
162 P 6.636000 106176 912(0.057000)
163 P 6.693000 107088 8880(0.555000)
164 P 7.248000 115968 16(0.001000)
165 P 7.249000 115984 16(0.001000)
166 P 7.250000 116000 16(0.001000)
167 P 7.251000 116016 16(0.001000)
168 P 7.252000 116032 16(0.001000)
169 P 7.253000 116048 16(0.001000)
170 P 7.254000 116064 16(0.001000)
171 P 7.255000 116080 16(0.001000)
172 P 7.256000 116096 16(0.001000)
173 P 7.257000 116112 16(0.001000)
174 P 7.258000 116128 16(0.001000)
175 P 7.259000 116144 16(0.001000)
176 P 7.260000 116160 912(0.057000)
177 P 7.317000 117072 816(0.051000)
178 P 7.368000 117888 480(0.030000)
179 P 7.398000 118368 800(0.050000)
180 P 7.448000 119168 560(0.035000)
181 P 7.483000 119728 288(0.018000)
182 P 7.501000 120016 928(0.058000)
183 P 7.559000 120944 896(0.056000)
184 P 7.615000 121840 288(0.018000)
185 P 7.633000 122128 480(0.030000)

Да, как раз на этом участке видео останавливается в хроме с hardware acceleration(но это уже другая беда, из другого треда. В этом же я хочу понять почему muxer ругается на DTS). А в чем странность? DTS увеличивается (таки монолитно?), все нормально.

возьмите любое эталонное, закодируйте libx264 и посмотрите на dts\pts на выходе и на duration

Беру, перекодирую этот же файл, смотрю dts\pts и duratioin. Вижу: duration везде одинаковый, отсюда и DTS стабильный, если кодируешь с постоянным FPS (-vsync cfr). Но у меня кодируется стрим, там FPS vfr (не постоянный).

Я так и не понял что значит «non-strictly-monotonic PTS». Если у меня увеличивается PTS\DTS и нет одинаковых PTS\DTS что же этому зверю нужно ещё?!

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

Все ссылки идут на багрепорты ffmpeg и прочую чепуху.

штош

Но у меня кодируется стрим, там FPS vfr (не постоянный).

зачем так делать? собственно в этом проблема, вы закодировали так что это некому не нравится, не надо так

hizel ★★★★★
()
Ответ на: комментарий от hizel

зачем так делать? собственно в этом проблема

Как - это как? С переменным FPS? Это плохо? Это противоречит стандартам?

вы закодировали так что это некому не нравится, не надо так

Да кому - никому? Только гребаному хрому не нравится с включенным HA. Все абсолютно плееры это видео проглатывают(проверял даже на ffplat, mpv консольных). Если в видео баг - хочу его найти и исправить, если это баг хрома, то ок, это баг хрома. Пока никто внятно не пояснил в чем плох этот видеоролик

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

вы транскодируете, декодируете/ообрабтываете/кодируете обратно, в исходниках ffmpeg легко увидеть, что libx264 энкодер приводит входящие pts к timebase 1/fps на выходе получаются одинковые pts, а за ними и одинаковые dts(судя по media_info bad_7s кодируете без b фреймов), mp4 упаковщик в шоке от таких сюрпризов, да и libx264 страдает от входящих pts

hizel ★★★★★
()
Ответ на: комментарий от gobot

Как - это как? С переменным FPS? Это плохо? Это противоречит стандартам? Да кому - никому? Только гребаному хрому не нравится с включенным HA.

ну ок

hizel ★★★★★
()
Ответ на: комментарий от hizel

libx264 энкодер приводит входящие pts к timebase 1/fps

То есть, сначала libx264 обрабатывает, потом передает в ffmpeg?

на выходе получаются одинковые pts

Почему одинаковые, если на входе они разные? Или ffprobe сначала прогоняет через libx264 и уже выдает канонизированные данные о DTS? Как посмотреть какие DTS\PTS «сырые» на входе?

кодируете без b фреймов

Да, там только P фреймы

timebase 1/fps

Это я ещё не вкурил. Если не трудно «на пальцах» можете сказать что это?

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

одинаковые потому что pkt_pts1 * fps * 1/mux_time_base = pkt_pts2 * fps * 1/mux_time_base

https://htrd.su/blog/2012/11/23/ffmpeg_nemnogo_pro_time-base/

ffmpeg нужно дополнительно описать, что на входе, некоторое vfr, готовое решение вы найдете в интернете в районе «как транскодировать vfr с cfr»

hizel ★★★★★
()
Ответ на: комментарий от hizel

Я не хочу транскодировать vfr с cfr. Я понимаю, что ffmpeg не понимает что у меня vfr и это нужно ему как то донести.

То есть ffmpeg по умолчанию думает что у меня cfr? Постоянный FPS?

Ok, теперь я ставлю -vsync vfr (Frames are passed through with their timestamp or dropped so as to prevent 2 frames from having the same timestamp)

ffmpeg -y -loglevel repeat+info -i bad_7s.mp4 -vsync vfr  out2.mp4
...
Past duration 0.613274 too large
Past duration 1.099602 too large
Past duration 1.218742 too large
Past duration 0.947258 too large
Past duration 1.238274 too large
Past duration 1.308586 too large
Past duration 0.673820 too large
Past duration 1.355461 too large
Past duration 0.816399 too large
Past duration 0.937492 too large
Past duration 0.642570 too large
Past duration 1.496086 too large
Past duration 0.787102 too large
Past duration 1.494133 too large
Past duration 0.638664 too large
Past duration 1.613274 too large
...


Теперь non-strictly-monotonic ушли, но появились Past duration *** too large. Снова не так. В исходниках смотрел, там стоит какое то магическое число, что если delta > 0.6 то выдается это сообщение.

            if (delta0 < -0.6) {
                av_log(NULL, AV_LOG_VERBOSE, "Past duration %f too large\n", -delta0);
            } else



https://github.com/FFmpeg/FFmpeg/blob/b2318c1e537f15c4c23f302a5193d6218dffdde...

gobot ★★★★
() автор топика
Ответ на: комментарий от hizel

Короче... я устал.

Я уже месяц с этом темой парюсь, но чувствую силы на исходе, перепробовал кучу тулз, нет большого опыта, не тяну я. Даже если и вытяну, то для этого нужно время, а его нет.

Поэтому, прошу помочь за деньги, если это возможно

Найти баг в стриме mp4\h264

gobot ★★★★
() автор топика

и что что он монотонный ?

проблема на хроме ?

ок, есть видео с переменным стримом который хром на вашем хв декодее играет и не зависает ?

может тупо баг в хром хв декодере

тогда ваши заявление - мол вам не надо переменный в постоянный пережать - выглядят глупо

для полноты картины нет информации откуда вы берете это якобы бад мп4

anonymous
()

…и скрипт не нашел ничего, вывод пустой. Все DTS увеличиваются!

Ты проверяешь dts во входном файле. Там они нормальные.

[mp4 @ 0x6475540] Non-monotonous DTS in output stream 0:0

А проблемы возникают в выходном потоке. Предупреждения генерируются ещё до того, как поток попадёт в файл. Тогда же происходят исправления. Поэтому в выходном файле dts тоже уже нормальные, и инспектируя его ты ничего не найдёшь.

Возникают проблемы из-за:

24.42 fps, 1571k tbn, 24.42 tbc

Ты кодируешь видео с базой 24.42. То есть все временные метки в выходном видео у тебя кратны 1/24.42 сек. Сохраняются они целыми числами. Но во входном видео у тебя метки времени просто дикие. Есть кадры с длительностью 1 мс. Когда они пересчитываются в целые числа с базой 24.42, там очевидно возникают совпадающие числа. И даже астрономическое значение tbn не помогает, потому что метки времени уже квантованы по tbc.

Что я делаю\понимаю не так?

Самое главное — у тебя дикие входные данные. Ну не верю я, что захват видео внезапно разгоняется до 1000 fps, а потом снова уменьшается до 24 fps. Разберись с входными данными. Они у тебя полный шлак.

Заткнуть ffmpeg ты можешь, добавив -enc_time_base -1 в параметры, вот так:

ffmpeg -y -i bad_7s.mp4 -vsync 0 -enc_time_base -1 out.mp4

Очевидно, это не решение проблемы, потому что дичь с длительностью кадров просто перекочует в выходной поток.

i-rinat ★★★★★
()
Ответ на: комментарий от gobot

моя твоя не понимать

вы программист ?

вы используете часть этого кода ?

как именно ?

показывайте вашу часть исходника

anonymous
()
Ответ на: комментарий от i-rinat

Ты проверяешь dts во входном файле. Там они нормальные.

Как скопировать метки без изменения? Чтобы muxer не изменял их?

Поэтому в выходном файле dts тоже уже нормальные, и инспектируя его ты ничего не найдёшь.

ffprobe выдает уже измененные метки? Как посмотреть оригинальные?

Но во входном видео у тебя метки времени просто дикие.
Ты проверяешь dts во входном файле. Там они нормальные.

Так нормальные или не нормальные? Как это определить?

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

Так нормальные или не нормальные?

Я не смогу тебе объяснить понятнее, чем уже описал.

i-rinat ★★★★★
()
Ответ на: комментарий от gobot

ответь на вопрос, кто выполняет кодирование, того что наклал в mp4 и начал размахивать на багтрекерах

anonymous
()
Ответ на: комментарий от anonymous

Кстати, это может быть ответом, автор девой лапкой на жабаскрипте натыкал стриминг и посылает на вход в энкодер одинаковые кадры, там удивляются, но принимают и добавляют к каждому входящему небольшую дельту в pts. Вместо того, чтобы разобраться в своем автор идет моросить на хром и ффмпег

anonymous
()
Ответ на: комментарий от anonymous

это может быть ответом

Зачем гадать, если в логах в заглавном сообщении уже достаточно информации, чтобы понять, что случилось?

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

если смотреть соседние темы автора, то понятно что проблема у автора не в том что он тут спрашивает

anonymous
()
Ответ на: комментарий от anonymous

*не в том что он тут спрашивает в этом топике

anonymous
()
Ответ на: комментарий от i-rinat

Ты кодируешь видео с базой 24.42

Да, пришлось почитать про tbc, tbn, tbr. Наконец то я понял почему pkt_dts отличается от pkt_dts_time

Вот как оформляет ffmpeg пакет мой код

av_init_packet(&pkt);

pkt.data = frame->payload;
pkt.size = frame->length;

pkt.dts = (int64_t)(frame->m_timeStamp / (av_q2d(stream->time_base) * 1000));
pkt.duration =  (int64_t)(frame->m_duration / (av_q2d(stream->time_base) * 1000));

av_interleaved_write_frame(m_context, &pkt);


В представлениях ffmpeg нормальный DTS переводится во внутреннее представление, связанное с timebase. До конца не понял зачем это делать, конвертировать привычный timestamp.

Что я вижу в ffprobe, вот пример отрезка видео
ffprobe -show_frames -select_streams v:0 -print_format csv ~/bad_7s.mp4 | awk -F ',' '{print $8 " " $7" " $12 }'

Input yuv420p, 480x270, 1654 kb/s, 24.42 fps, 16k tbr, 16k tbn, 32k tbc (default)

frame_num pkt_dts_time pkt_dts pkt_duration_time
0 0.000000 0 0.118000
1 0.118000 1888 0.024000
2 0.142000 2272 0.057000
3 0.199000 3184 0.024000
4 0.223000 3568 0.076000
5 0.299000 4784 0.018000




#2#фрейм, pkt_dts=2272
pkt_dts_time = pkt_dts/tbn = 2272/16000(16k tbn) =0,142

Все встало на места(наполовину).

В других видео, закодированных НЕ ffmpeg, лежат нормальные DTS
yuv420p(tv), 640x480 [SAR 1:1 DAR 4:3], 714 kb/s, 17.51 fps, 18 tbr, 1k tbn, 36 tbc (default)

72 3.988000 3988 0.055000
73 4.055000 4055 0.055000
74 4.073000 4073 0.055000
75 4.135000 4135 0.055000
76 4.220000 4220 0.055000
77 4.312000 4312 0.055000

То есть обычные MS, где 4.055000 == 4055/1000(1k tbn). Где то читал, смысл в том, что ffmpeg ввел AVRational, вместо double, чтобы целое число представить без погрешностей. Какую то свою timebase, на основе которой время считается.

tbn = the time base in AVStream that has come from the container
tbc = the time base in AVCodecContext for the codec used for a particular stream
tbr = tbr is guessed from the video stream and is the value users want to see when they look for the video


tbn получено из контейнера? Где в mp4 это прописано?
tbc - не понятно откуда берется
про tbr вообще молчу, определяется из потока...

В гугле нет внятной инфы по этому, все ссылаются на краткий комментарий в исходниках самого ffmpeg. Если не трудно расскажите про timebase, кто на ком стоит

Самое главное — у тебя дикие входные данные

В этом видео да, на 7 секунде есть небольшой участок с маленькими duration. Но только chrome затыкается на нем и только при условии что выбран декодер MojoVideoDecoder (это harware acceleration DXVA), все остальные пллееры\браузеры пропускают его и дальше идут

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

Там нет никакого исходника, видео записывается и потом открывается в хроме

Вот как оформляет ffmpeg пакет мой код

facepalm что ж вы все путаетесь в показаниях ? вы не русский ?

anonymous
()
Ответ на: комментарий от anonymous

автор девой лапкой на жабаскрипте натыкал стриминг

Во-первых, не я натыкал, а Intel (гугли owt-server), во-вторых на «жабаскрипте» написана только некоторая логика, сам стриминг идет через c++, libwebrtc(chromium), avcodec...

посылает на вход в энкодер одинаковые кадры

DTS у входного потока разный (то есть увеличивающийся), выше i-rinat ответил (Ты проверяешь dts во входном файле. Там они нормальные.)

в энкодер

Ничего не энкодируется, просто мультиплексируется. Видео уже закодировано

Вместо того, чтобы разобраться в своем автор идет моросить на хром и ффмпег

Где я тут моросил на ffmpeg или хром? Ты темы попутал

gobot ★★★★
() автор топика
Ответ на: комментарий от anonymous

Я тут спрашиваю не про другие темы, а конкретно про DTS логику. Если разберусь с этим, возможно поможет с теми проблемами...

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

Какую то свою timebase

Посмотри документацию на формат H.264. Увидишь там определение time_scale и сопутствующие понятия.

В представлениях ffmpeg нормальный DTS переводится во внутреннее представление, связанное с timebase. До конца не понял зачем это делать, конвертировать привычный timestamp.

Что ты понимаешь под «нормальным» dts? Какое представление «привычное»?

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Посмотри документацию на формат H.264. Увидишь там определение time_scale

Так вроде h264 не отвечает за временные метки?

Что ты понимаешь под «нормальным» dts? Какое представление «привычное»?

Нормальным я считаю, когда pkt_dts_time == pkt_dts/1000. В выводе ffprobe, это же очевидно. А тут получается перерасчет какой то. Сначала ffmpeg переводит обычный timestamp в свои единицы, а потом конвертирует их обратно.

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

Так вроде h264 не отвечает за временные метки?

tbc

Нормальным я считаю, когда pkt_dts_time == pkt_dts/1000.

Так ты не сможешь точно представить метки времени в видео, у которого 24 кадра в секунду. Из-за постоянных округлений до миллисекунд у тебя кадры поедут. В гипотетической ситуации, когда нужно показать рядом два видео, у одного из которых 24 кадра в секунду, а у другого — 25, только второе будет показываться точно. У первого будет ошибка до 0,5 мс на кадр, что за 2000 кадров даст расхождение до одной секунды. А 2000 кадров это всего около полутора минут. Так что твоя идея «нормальности» — так себе.

Возможно люди, которые спецификации писали, имели больший опыт, чем у тебя. Поэтому стоит хотя бы попытаться понять задумку. Ты только сегодня-вчера узнал, как метки времени кодируются. Возможно, про работу с видео ты знаешь ещё не всё.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

У первого будет ошибка до 0,5 мс

Это о чем я писал выше?

Где то читал, смысл в том, что ffmpeg ввел AVRational, вместо double, чтобы целое число представить без погрешностей.

Спасибо за наводку, ещё покурю денек, напишу

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

Видео уже закодировано

кто тебе закодировал? никто не кодирует с переменным fps

видимо ты сам не знаешь откуда у тебя накодировано, создай у owt-server багрепорт, со своей проблемой, да не тот что ты создал, а спроси почему ты сохранил от них поток там duration гуляет и семплом своим помахай, кстати как ты его сохранил, у них есть ручка где можно сдампить поток?

anonymous
()
Ответ на: комментарий от gobot

Это о чем я писал выше?

Нет.

ffmpeg ввел AVRational, вместо double, чтобы целое число представить без погрешностей.

Ты говоришь об этом, как будто это было совсем недавно. AVRational в FFmpeg появился почти 17 лет назад.

i-rinat ★★★★★
()
Ответ на: комментарий от anonymous

видимо ты сам не знаешь откуда у тебя накодировано

Знаю.

Браузер передает rtp поток в h264(без звука) на сервер, который обрабатывается libwebrtc

Далее я даю команду на запись потока:

Фреймы поступают отсюда (libwebrtc)
https://github.com/open-webrtc-toolkit/owt-server/blob/cb4e86d655602694b0b6f0...

Потом сюда
https://github.com/open-webrtc-toolkit/owt-server/blob/cb4e86d655602694b0b6f0...

В итоге libavcodec муксит их в mp4

https://github.com/open-webrtc-toolkit/owt-server/blob/cb4e86d655602694b0b6f0...

создай у owt-server багрепорт, со своей проблемой

Создавал.

да не тот что ты создал

То есть?

duration гуляет

Что в этом плохого?

где можно сдампить поток

есть, можно записать в mp4

gobot ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.