yua

2013-03-23 04:39:58 pm

The Dork Knight himself.

Quote from nate:

funny because i see mostly bff when it comes to stuff from capture cards, old school avi output (so the field dominance isn't stored). i actually made norichan work that way on purpose to fit in better.

Not sure if this is relevant or not, but everything I record with my Dazzle DVC100 is top field first with no bobbing.

nate

2013-03-23 04:42:00 pm

ultimately it doesn't matter because i'm planning on writing autodetect code for everything and that one should be easy to get with a high probability of correctness.

__sdfg

2013-03-23 05:25:41 pm

D:

Quote from ballofsnow:

"Oh, just offset the audio, that should work!! *plays result in media players - some work, most don't* Shit."

Add Totem/GStreamer, mplayer, and whatever version of Window Media Player comes with Windows 7 to the list of players that don't. Also, any app that uses the hardware decoder on my phone, it seems. MX Player's software decoder got the delay right, but my phone's apparently too slow for even the MQ encode, so the video went in and out of sync in that mode. I tried a couple other players and they either didn't give me the option of using a software decoder or didn't work any better.

Interestingly, mplayer slowly resynchronized the audio and video, and would fix sync immediately if I seeked. So close to working. :/

nate

2013-03-23 08:21:53 pm

(five hours later) i ended up cross-compiling ffmpeg from mingw-w64 (32-bit) instead of mingw (see more about the fork) and that fixed h.264 decoding. unfortunately my qt is built with mingw and i was very lucky to be able to link bringing in two mingw-w64 libraries for the new ffmpeg without any conflicts. was not so lucky when i tried to bring in the aac and h.264 encoders. so i left those as the old mingw ones. so right now yua for windows is pretty grody. but at least it works better than it did this morning. snow, do me a favor and go ahead and download it again. should have full format and codec support (equivalent to os x and linux) now.

ballofsnow

Edit history:

ballofsnow: 2013-03-23 09:13:57 pm

ballofsnow: 2013-03-23 08:56:07 pm

ballofsnow: 2013-03-23 08:55:31 pm

ballofsnow: 2013-03-23 08:54:31 pm

2013-03-23 08:43:28 pm

Load/preview/seek is working for the AVC* files I have. Will re-test.

edit-

I think LAGS + RGB + interlaced is causing a glitch fest. YUV422 is fine. LAGS + RGB + prog is fine. See: LAGS_PCM_720x480i_4x3_2997_RGB_D4F12D---SMBonepixel.avi

Crash on attempt to encode:
AVC_AAC_720x480i_4x3_2997_YUV420_D4F12D---MarioChromaBleedSilentAudio.ts

I think this one is special... Got 2 other m2ts going no crash.

TheThrillness

Edit history:

TheThrillness: 2013-03-23 09:27:45 pm

TheThrillness: 2013-03-23 09:27:07 pm

TheThrillness: 2013-03-23 09:26:21 pm

2013-03-23 09:24:50 pm

thethrillness.blogspot.com

Writing some notes below. Just casual observations.

1. Drag and dropping the video in. I like this.

2. If you hover over progressive or interlaced you get the same "Interlaced video displays...". This might be intentional but I'd rather it said to the user something like "If you have a progressive source you do not need to worry about deinterlacing" when progressive is selected.

3. Is there any indication for the user as to what field dominance to pick?

4. I'd like a note saying in unused space something like "Click the option that does not shake the video as much" when using interlaced video.

5. I like that it shows you a preview window of what is encoding. I'd however also like an option to disable this to decrease CPU load.

TheThrillness

2013-03-23 09:26:16 pm

thethrillness.blogspot.com

Attached an encode from the Intensity Pro if you want to look at it for some reason.

Attachment:

yua_HQ2.mp4

presjpolk

2013-03-23 11:57:28 pm

HELLO!

So was my Exodus run the first Yua encode through SDA verification?

nate

2013-03-24 09:39:48 am

hard to say.

ballofsnow

2013-03-24 09:43:02 am

Might as well share my spreadsheet. I'm still not done as you can see; working on them now.

View-only: https://docs.google.com/spreadsheet/ccc?key=0AqZ-c9XrMkM7dGY5dlFlSnpOWWE0LVRFSzd2dWVicFE&usp=sharing

nate

2013-03-24 09:44:48 am

cool. i'm starting on initial zero-padding to replace initial offset right now.

ballofsnow

2013-03-24 10:08:32 am

So I went to load the dosbox ZMBV clip, and it said unsupported codec, which is strange since it worked yesterday.

For TSCC and ZMBV: Unsupported codec on A4 March 23. Supported on A4 March 18!

nate

2013-03-24 10:09:34 am

thanks ... wonder what i forgot to enable. at least this kind of thing is easy to test.

ballofsnow

2013-03-24 11:37:41 am

First round done. The ones that crashed I re-tested a couple times.

Link again:
https://docs.google.com/spreadsheet/ccc?key=0AqZ-c9XrMkM7dGY5dlFlSnpOWWE0LVRFSzd2dWVicFE&usp=sharing

nate

2013-03-24 05:27:23 pm

it took me most of the day but i finally got leader padding done and full format support back under windows. i'm bumping the version number to alpha 5 because leader padding is significant enough of a change. no more desync on any player hopefully.

i know a lot of people are curious when this is actually going to be useful. right now one question needs to be answered for me to start working on important features (trimming, cropping, appending):

does everything encode with good sync?

there are a couple other things i need to look at (especially the crashes under windows), but i can't really move on until i'm happy with how i'm doing synchronization. reason is it feeds directly in to trimming and appending. i see that almost all of snow's tests apparently encoded with good sync, so i feel like i must be on the right track. i need to try some with this new alpha 5, probably after i finish automation so that snow doesn't feel inclined to go all the way through again manually. i'm also buying a new system today so i can stop living in the ghetto here. haven't upgraded anything that matters in three years and the camel's back broke today.

it took me most of the day but i finally got leader padding done and full format support back under windows. i'm bumping the version number to alpha 5 because leader padding is significant enough of a change. no more desync on any player hopefully.

i know a lot of people are curious when this is actually going to be useful. right now one question needs to be answered for me to start working on important features (trimming, cropping, appending):

does everything encode with good sync?

there are a couple other things i need to look at (especially the crashes under windows), but i can't really move on until i'm happy with how i'm doing synchronization. reason is it feeds directly in to trimming and appending. i see that almost all of snow's tests apparently encoded with good sync, so i feel like i must be on the right track. i need to try some with this new alpha 5, probably after i finish automation so that snow doesn't feel inclined to go all the way through again manually. i'm also buying a new system today so i can stop living in the ghetto here. haven't upgraded anything that matters in three years and the camel's back broke today.

ballofsnow

Edit history:

ballofsnow: 2013-03-24 07:27:02 pm

ballofsnow: 2013-03-24 07:26:43 pm

2013-03-24 07:17:11 pm

Statid sync looks good.

I did get a desync on the LQ of a Kirby video, on A4 and still A5.

LAGS_PCM_640x480i_4x3_3000_YUV422_D1F13D---KirbyDreamland.avi
VFR. LQ playback not synced in MPC-HC, though MQ and HQ are synced. All fine in VLC though. Very strange, same result on a re-test of all qualities.

LQ is desynced from the start without statid... but synced with statid.

IsraeliRD

2013-03-25 08:53:34 pm

Dragon Power Supreme

I've just done a new encode on a new video file (51 secs length) @ 60fps, yet after yua 5 is done with LQ-XQ I get 56.234fps for HQ-XQ and 28.117 in LQ/MQ when checking AviDemux. In VLC: 56.232746 and 28.115863 respectively.
The encodes are perfect and all, it's just this really screwed up fps.

nate

2013-03-25 09:05:19 pm

having trouble reproducing that kirby desync, or at least i think i am. i think the source video has weird timestamps, maybe only at the start, and of course yua just copies them ... sometimes it seems ever so slightly out of sync (audio ahead of the video) and sometimes not, and it usually improves as the video goes on. near the end when kirby flies around and then the menu navigation always seems to have better sync for me. how much desync did you notice and when did you notice it? and it was only with the lq? that's what i'm encoding and it seems the same to me as the other qualities.

Quote from IsraeliRD:

I've just done a new encode on a new video file (51 secs length) @ 60fps, yet after yua 5 is done with LQ-XQ I get 56.234fps for HQ-XQ and 28.117 in LQ/MQ when checking AviDemux. In VLC: 56.232746 and 28.115863 respectively.
The encodes are perfect and all, it's just this really screwed up fps.

so they play back ok with good sync?

i have one idea what caused it (leader padding at a different framerate) but i would need the original file to be sure. think i may rework this either way since making everything vfr doesn't seem very clean.

having trouble reproducing that kirby desync, or at least i think i am. i think the source video has weird timestamps, maybe only at the start, and of course yua just copies them ... sometimes it seems ever so slightly out of sync (audio ahead of the video) and sometimes not, and it usually improves as the video goes on. near the end when kirby flies around and then the menu navigation always seems to have better sync for me. how much desync did you notice and when did you notice it? and it was only with the lq? that's what i'm encoding and it seems the same to me as the other qualities.

[quote="IsraeliRD"]I've just done a new encode on a new video file (51 secs length) @ 60fps, yet after yua 5 is done with LQ-XQ I get 56.234fps for HQ-XQ and 28.117 in LQ/MQ when checking AviDemux. In VLC: 56.232746 and 28.115863 respectively. 
The encodes are perfect and all, it's just this really screwed up fps.[/quote]
so they play back ok with good sync?

i have one idea what caused it (leader padding at a different framerate) but i would need the original file to be sure. think i may rework this either way since making everything vfr doesn't seem very clean.

IsraeliRD

2013-03-25 09:30:35 pm

Dragon Power Supreme

Yeah they play back fine with good sync.
Attached source file.

Attachment:

TPI-Introduction.7z.torrent

Sonikkustar

2013-03-25 09:45:24 pm

The Great Farming Empire

Yep, Now it syncs with the StatID.

Attachment:

yua Test 2.zip

bos

2013-03-26 05:57:21 am

Quote from nate:

having trouble reproducing that kirby desync, or at least i think i am. i think the source video has weird timestamps, maybe only at the start, and of course yua just copies them ... sometimes it seems ever so slightly out of sync (audio ahead of the video) and sometimes not, and it usually improves as the video goes on. near the end when kirby flies around and then the menu navigation always seems to have better sync for me. how much desync did you notice and when did you notice it? and it was only with the lq? that's what i'm encoding and it seems the same to me as the other qualities.

Kirby LQ only, and on MPC-HC, not VLC. Significant desync right from the start, constant throughout the video. Again, only on MPC-HC.

My original notes from A4 still apply:
VFR. LQ playback not synced in MPC-HC, though MQ and HQ are synced. All fine in VLC though. Very strange, same result on a re-test of all qualities.

nate

Edit history:

nate: 2013-03-30 10:12:10 am

nate: 2013-03-30 10:02:47 am

nate: 2013-03-30 09:34:13 am

2013-03-30 09:16:52 am

good stuff happening ... alpha 6 should be coming once i get a bunch of runs encoded. in the meantime though can snow or someone tell me why a video encoded like this has black video in quicktime 7?:

Code:

[libx264 @ 0x1048b7c00] frame I:2461  Avg QP:21.79  size: 14805
[libx264 @ 0x1048b7c00] frame P:438715 Avg QP:25.48  size:  2076
[libx264 @ 0x1048b7c00] mb I  I16..4: 67.4%  0.0% 32.6%
[libx264 @ 0x1048b7c00] mb P  I16..4:  0.7%  0.0%  0.2%  P16..4: 43.6%  6.5%  4.8%  0.7%  0.3%    skip:43.3%
[libx264 @ 0x1048b7c00] coded y,uvDC,uvAC intra: 36.8% 33.0% 29.7% inter: 16.9% 12.0% 7.3%
[libx264 @ 0x1048b7c00] i16 v,h,dc,p: 53% 28% 15%  4%
[libx264 @ 0x1048b7c00] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 21% 24%  5%  8%  6%  7%  4%  7%
[libx264 @ 0x1048b7c00] i8c dc,h,v,p: 61% 23% 14%  2%
[libx264 @ 0x1048b7c00] ref P L0: 13.2% 59.7%  2.2%  6.9%  2.3% 11.3%  1.4%  3.0%
[libx264 @ 0x1048b7c00] kb/s:1029.63

[libx264 @ 0x1048b7c00] using SAR=1/1
[libx264 @ 0x1048b7c00] MB rate (54000000) > level limit (2073600)
[libx264 @ 0x1048b7c00] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
[libx264 @ 0x1048b7c00] profile Constrained Baseline, level 5.2
[libx264 @ 0x1048b7c00] 264 - core 129 r2 bc13772 - H.264/MPEG-4 AVC codec - Copyleft 2003-2013 - http://www.videolan.org/x264.html - options: cabac=0 ref=8 deblock=1:0:0 analyse=0x1:0x131 me=umh subme=10 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=18 lookahead_threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=60 rc=2pass mbtree=1 bitrate=512 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 aq=1:1.00

that's what it gives me as the first pass ends and it starts the second pass. i'm pretty confused atm because i've had other mq be compatible with quicktime 7 with this same build of yua. example of one that is compatible:

Code:

[libx264 @ 0x10683a400] frame I:892   Avg QP:19.01  size:  7142
[libx264 @ 0x10683a400] frame P:55184 Avg QP:26.88  size:  4945
[libx264 @ 0x10683a400] mb I  I16..4: 76.3%  0.0% 23.7%
[libx264 @ 0x10683a400] mb P  I16..4:  0.2%  0.0%  0.2%  P16..4: 39.3% 32.4% 14.4%  3.2%  1.1%    skip: 9.1%
[libx264 @ 0x10683a400] coded y,uvDC,uvAC intra: 39.9% 30.5% 27.1% inter: 42.1% 18.7% 8.7%
[libx264 @ 0x10683a400] i16 v,h,dc,p: 75% 16%  6%  3%
[libx264 @ 0x10683a400] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 12% 13%  8% 15% 12% 12%  8%  5%
[libx264 @ 0x10683a400] i8c dc,h,v,p: 72% 14% 13%  2%
[libx264 @ 0x10683a400] ref P L0: 10.3% 13.2% 26.7%  8.8%  3.8% 27.4%  3.2%  6.5%
[libx264 @ 0x10683a400] kb/s:2387.96

[libx264 @ 0x105812200] using SAR=1/1
[libx264 @ 0x105812200] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
[libx264 @ 0x105812200] profile Constrained Baseline, level 2.1
[libx264 @ 0x105812200] 264 - core 129 r2 bc13772 - H.264/MPEG-4 AVC codec - Copyleft 2003-2013 - http://www.videolan.org/x264.html - options: cabac=0 ref=8 deblock=1:0:0 analyse=0x1:0x131 me=umh subme=10 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=18 lookahead_threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=60 rc=2pass mbtree=1 bitrate=512 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 aq=1:1.00

the rate warning is probably spurious but look at the level - could this be it? if so what level should i constrain it to?

edit: looks like anri constrains mq to level 1.3 ... i will try that. seems a little low though for d4 f1 2d mq.

edit 2: doing some research this morning and it looks like the quicktime situation has changed. going to experiment a bit with my ipod classic. another thing i'm not sure of is the level for non-mq encodes. 4.1 is bluray and it doesn't seem like 5+ is supported on almost anything so i'm probably going to go with 4.1 unless i learn something new.

edit 3: confirmed that baseline profile is still required for playback on my ipod classic even with the new qpmin and refs settings. i don't think itunes even copies main profile video to the device.

good stuff happening ... alpha 6 should be coming once i get a bunch of runs encoded. in the meantime though can snow or someone tell me why a video encoded like this has black video in quicktime 7?:
[code][libx264 @ 0x1048b7c00] frame I:2461  Avg QP:21.79  size: 14805
[libx264 @ 0x1048b7c00] frame P:438715 Avg QP:25.48  size:  2076
[libx264 @ 0x1048b7c00] mb I  I16..4: 67.4%  0.0% 32.6%
[libx264 @ 0x1048b7c00] mb P  I16..4:  0.7%  0.0%  0.2%  P16..4: 43.6%  6.5%  4.8%  0.7%  0.3%    skip:43.3%
[libx264 @ 0x1048b7c00] coded y,uvDC,uvAC intra: 36.8% 33.0% 29.7% inter: 16.9% 12.0% 7.3%
[libx264 @ 0x1048b7c00] i16 v,h,dc,p: 53% 28% 15%  4%
[libx264 @ 0x1048b7c00] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 21% 24%  5%  8%  6%  7%  4%  7%
[libx264 @ 0x1048b7c00] i8c dc,h,v,p: 61% 23% 14%  2%
[libx264 @ 0x1048b7c00] ref P L0: 13.2% 59.7%  2.2%  6.9%  2.3% 11.3%  1.4%  3.0%
[libx264 @ 0x1048b7c00] kb/s:1029.63

[libx264 @ 0x1048b7c00] using SAR=1/1
[libx264 @ 0x1048b7c00] MB rate (54000000) > level limit (2073600)
[libx264 @ 0x1048b7c00] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
[libx264 @ 0x1048b7c00] profile Constrained Baseline, level 5.2
[libx264 @ 0x1048b7c00] 264 - core 129 r2 bc13772 - H.264/MPEG-4 AVC codec - Copyleft 2003-2013 - http://www.videolan.org/x264.html - options: cabac=0 ref=8 deblock=1:0:0 analyse=0x1:0x131 me=umh subme=10 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=18 lookahead_threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=60 rc=2pass mbtree=1 bitrate=512 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 aq=1:1.00
[/code]
that's what it gives me as the first pass ends and it starts the second pass. i'm pretty confused atm because i've had other mq be compatible with quicktime 7 with this same build of yua. example of one that is compatible:

[code][libx264 @ 0x10683a400] frame I:892   Avg QP:19.01  size:  7142
[libx264 @ 0x10683a400] frame P:55184 Avg QP:26.88  size:  4945
[libx264 @ 0x10683a400] mb I  I16..4: 76.3%  0.0% 23.7%
[libx264 @ 0x10683a400] mb P  I16..4:  0.2%  0.0%  0.2%  P16..4: 39.3% 32.4% 14.4%  3.2%  1.1%    skip: 9.1%
[libx264 @ 0x10683a400] coded y,uvDC,uvAC intra: 39.9% 30.5% 27.1% inter: 42.1% 18.7% 8.7%
[libx264 @ 0x10683a400] i16 v,h,dc,p: 75% 16%  6%  3%
[libx264 @ 0x10683a400] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 12% 13%  8% 15% 12% 12%  8%  5%
[libx264 @ 0x10683a400] i8c dc,h,v,p: 72% 14% 13%  2%
[libx264 @ 0x10683a400] ref P L0: 10.3% 13.2% 26.7%  8.8%  3.8% 27.4%  3.2%  6.5%
[libx264 @ 0x10683a400] kb/s:2387.96

[libx264 @ 0x105812200] using SAR=1/1
[libx264 @ 0x105812200] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
[libx264 @ 0x105812200] profile Constrained Baseline, level 2.1
[libx264 @ 0x105812200] 264 - core 129 r2 bc13772 - H.264/MPEG-4 AVC codec - Copyleft 2003-2013 - http://www.videolan.org/x264.html - options: cabac=0 ref=8 deblock=1:0:0 analyse=0x1:0x131 me=umh subme=10 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=18 lookahead_threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=60 rc=2pass mbtree=1 bitrate=512 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 aq=1:1.00
[/code]
the rate warning is probably spurious but look at the level - could this be it? if so what level should i constrain it to?

edit: looks like anri constrains mq to level 1.3 ... i will try that. [url=http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels]seems a little low[/url] though for d4 f1 2d mq.

edit 2: doing some research this morning and it looks like [url=http://mewiki.project357.com/wiki/X264_Encoding_Suggestions#QuickTime_Player_X_compatibility]the quicktime situation has changed[/url]. going to experiment a bit with my ipod classic. another thing i'm not sure of is the level for non-mq encodes. 4.1 is bluray and it doesn't seem like 5+ is supported on almost anything so i'm probably going to go with 4.1 unless i learn something new.

edit 3: confirmed that baseline profile is still required for playback on my ipod classic even with the new qpmin and refs settings. i don't think itunes even copies main profile video to the device.

bos

2013-04-01 03:08:52 pm

Hi. Is the above still a problem?

For everything non-MQ, there's no profile or level limitations in place in Anri 3.3. We discussed and agreed upon this like.. 2 years ago. If you set restrictions, you're going to have trouble at 1080p+ stuff, especially at high framerates.

nate

2013-04-01 03:31:20 pm

problem is that quicktime x is refusing to decode the resulting video. definitely need to check that constraining non-mq to level 4.1 as i've done for alpha 6 doesn't break 1080p+ encodes. 4.1 is bluray so there shouldn't be any problem but who knows. maybe i should just make xq unconstrained and say screw quicktime/hardware decoders for it.

UraniumAnchor

2013-04-01 03:46:31 pm

Not a walrus

I'd be surprised if quicktime really cared about the level that much, but 4.1 isn't technically able to display 1080p at 60fps, you need 4.2 for that. Past that, not sure.