(2014-04-15, 16:32)tuxen Wrote: [ -> ]Nice popcornmix.
What I found odd is all 2.35:1 stereoscopic videos I have is encoded with the black bars to make it look correct, so maybe its a general problem with players based on the same code.
Yes, all my test files are 16:9 (many with encoded black bars) which surprised me, so it may be something that many players get wrong and the encoders avoid.
(2014-04-15, 14:28)popcornmix Wrote: [ -> ]Last night I bit the bullet, and tried to solve this properly. Basically allowing two zoom rectangles to be specified to firmware.
This should allow all custom zoom modes with 3d contents, including things like viewing SBS video in TAB mode.
3D video rendering fixes have been pushed to newclock3 and firmware trees.
(2014-04-15, 16:43)popcornmix Wrote: [ -> ] (2014-04-15, 16:32)tuxen Wrote: [ -> ]Nice popcornmix.
What I found odd is all 2.35:1 stereoscopic videos I have is encoded with the black bars to make it look correct, so maybe its a general problem with players based on the same code.
Yes, all my test files are 16:9 (many with encoded black bars) which surprised me, so it may be something that many players get wrong and the encoders avoid.
Earlier I reported a 3D.TAB 2.35:1 video to look propper (correct ar), well turns out it's 16:9 actually (black bars encoded).
The file I saw the problem didn't have the black bars encoded, it was actually 2.40:1 (the only file in my collection that is like that - was gonna switch this with a better version but I'm gonna keep it for future reference).
With xbmc for windows it looks ok though.
(2014-04-15, 18:27)host505 Wrote: [ -> ]Earlier I reported a 3D.TAB 2.35:1 video to look proper (correct ar), well turns out it's 16:9 actually (black bars encoded).
The file I saw the problem didn't have the black bars encoded, it was actually 2.40:1 (the only file in my collection that is like that - was gonna switch this with a better version but I'm gonna keep it for future reference).
Yep, be sure to test it with next build.
Hi!
Just actualised it and the hifiberry DAC works with that build, but creates an error message while booting "cannot load Kernel modules".
But it works!
I use this hifiberry.conf:
snd_soc_bcm2708
snd_soc_bcm2708_i2s
bcm2708_dmaengine
snd_soc_pcm5102a
snd_soc_hifiberry_dac
Question: Does that build still forces audio to 16 bit?
Greets
Paulchen
(2014-04-15, 19:56)0815Paulchen Wrote: [ -> ]Question: Does that build still forces audio to 16 bit?
You can check the log where the ALSA sink gets opened, but I think HifiBerry defaults to 32-bit audio.
(2014-04-15, 20:14)popcornmix Wrote: [ -> ] (2014-04-15, 19:56)0815Paulchen Wrote: [ -> ]Question: Does that build still forces audio to 16 bit?
You can check the log where the ALSA sink gets opened, but I think HifiBerry defaults to 32-bit audio.
Hello,
i think HifiBerry is still forced to 16Bit Audio
Code:
21:09:57 956.301880 T:3058488400 NOTICE: Enumerated ALSA devices:
21:09:57 956.302002 T:3058488400 NOTICE: Device 1
21:09:57 956.302246 T:3058488400 NOTICE: m_deviceName : @
21:09:57 956.302429 T:3058488400 NOTICE: m_displayName : Default (snd_rpi_hifiberry_dac Analog)
21:09:57 956.302551 T:3058488400 NOTICE: m_displayNameExtra:
21:09:57 956.302673 T:3058488400 NOTICE: m_deviceType : AE_DEVTYPE_PCM
21:09:57 956.302856 T:3058488400 NOTICE: m_channels : FL,FR
21:09:57 956.302979 T:3058488400 NOTICE: m_sampleRates : 8000,11025,16000,22050,32000,44100,48000,64000,88200,96000,176400,192000
21:09:57 956.303101 T:3058488400 NOTICE: m_dataFormats : AE_FMT_S32NE,AE_FMT_S16NE,AE_FMT_S16LE
OpenELEC:~ # lsb_release
OpenELEC (Milhouse) - Version: devel-20140415182817-r18188-gcf7a732
Edit:
I just played around with some 24Bit/192kHz Flac Files but it the playback is only in 16Bit. The Problem is i cant see a 24Bit entry in
"m_dataFormats
Edit2
0815Paulchen
just comment out snd_soc_bcm2708 line in your hifiberry.conf